[번역] WeWork 대신 iWork에서! "내가 생각한 최고의 개라지 오피스" 구축기

 이 글은 전 AWS Japan 마케팅 헤더이자 현재는 커뮤니티 마케팅 전문가로서 일본의 여러기업에서 왕성한 활동을 이어나가고 있는 Ojima Hideki씨의 블로그 글을 본인의 허락을 받아 번역한 것 입니다. 

Ojima씨는 현재 여러 회사에 동시에 적을두고 활동하고 있으며 이러한 근무 방식을 글 안에서 '병렬 경력(Parallel career)'이라고 표현하고 있습니다.

리모트 워크가 일반화된 시대가 되었습니다. 사무실에는 좀처럼 갈 수가 없지만 그렇다고 해도 집은 장시간의 업무에 적합하게 설계되어 있지 않습니다. 이러한 이유로 WeWork가 아니라 '내가 생각한 최고의 사무실'을 직접 만들어 보았습니다!

코로나 사태 이전부터 가지고 있었단 사무실 구상(이라고 쓰고 망상이라고 읽는다)

자신의 사무실을 가지려는 생각은 지금 일을 시작했을 때 부터 가지고 있었으며 실제로 집을 보러 다니고 있었습니다. 뒤돌아 보면 저는 2018년,  마이크로소프트 테크서밋에서 니시와키씨, 사킨씨와 가졌었던 패널 토론에서도 'iWork를 만들겠다!'라고 선언한 바가 있습니다. 

그러나 이 구상이 좀처럼 구체화 되지 못한 가장 큰 이유는 '바이크를 실내에 둘 수 있는 집이 없다'라는 것 입니다. 개라지 오피스는 남자의 로망입니다. 기왕에 나만의 사무실을 만든다면 그것만큼은 양보할 수 없다고 생각했는데 여기에는

• 1층의 도로에 접한 건물
• 집주인이 바이크를 건물 내에 주차하는 것을 허락할 것
• 현실적으로 임대 가능한 물건

이라고 하는 세 가지 장애물이 있어서 이를 충족하는 물건은 좀처럼 찾을 수 없었습니다. 특히 집주인의 허락을 받는것이 어렵더군요. 특히나 집주인들은 임대해준 집에 휘발유로 움직이는 바이크를 주차한다는 것에 난색을 보였습니다.

또한 현재 적을 두고 있는 회사의 대부분이 도쿄 중심지에 멋지게 꾸며진 사무실을 가지고 있었습니다. 그곳을 사용한다면 편안하게 작업 할 수 있기 때문에, 솔직히 자신만의 사무실에 대한 필요성도 그다지 크지 않은 것도 사실이었습니다. 이러한 이유로 차고를 지닌 사무실을 갖고 싶다는 망상은 좀처럼 실현되지 않는 상황이었습니다.

코로나사태로 인한 리모트워크 퍼스트와 갑자기 실현된 iWork구상

제 주변에 외국계 IT회사에 근무하는 사람이 많은 탓도 있지만, 코로나 대유행으로 인해 올 3월 무렵 대부분의 작업이 리모트 워크로 전환되게 됩니다. 그리고 이 상황은 2020년9월인 현재에도 이어지고 있습니다. 리모트 워크로 인해 전철등의 출퇴근에서 해방되는것은 물론 환영할만한 것이었고, 집의 인터넷 환경도 비교적 쾌적했기때문에 이러한 흐름에 반감이 들지는 않았지만, 역시 집이라는 공간은 장시간 업무를 하기엔 적합하지 않았습니다.

한동안 나는 침실에서 일을 하고, 두 아이는 각자의 방에서 온라인 수업을 듣는 생활을 했습니다. 세 명 모두 각자의 방에 틀어박혀 있는 동안 아내는 거실밖에 있을 수 있는 공간이 없었는데, 각자의 방을 청소하는 타이밍을 잡기도 어려웠습니다. 그런데, 도심의 수많은 멋진 사무실에 갈 기회가 없어진 바로 이 타이밍에, 갑자기 나의 iWork 구상을 실현시켜줄 집이 눈앞에 나타난 것 입니다!

뼈대로부터 시작

이번 물건은 원래 타코야키 배달 전문점에서 사용하던 것으로, 1. 도로에 접해 있으면서 폭이 넓고(바이크 출입이 쉽다!), 같은 건물에 바이크 가게가 들어온 적이 있어서 2. 바이크를 실내에 주차하는것에 대해 주인의 허락을 받기 쉬웠고, 3.물건이 10~15년 후 재건축을 검토하고 있는 낡은 건물이다보니 집세도 비교적 저렴했습니다.

사실 오랫동안 이 물건은 공실로 되어 있는것을 알았기에 "저기라면 싸게 빌릴 수 있을것 같고, 집에서도 가깝기 때문에 좋을텐데..."라고 생각했습니다만, 10년 후에 있을 재건축 전 까지만 임대가 가능하다는 계약조건 때문에 음식점에서는 실내 인테리어 비용등을 회수하는데 있어서 부담을 느껴 잘 나가지 않고 있었던것 같습니다. (역자 주: 한국 기준으로는 이상하게 들릴지 모르겠지만 일본은 같은 자리에서 10년 이상 음식점을 하는 경우가 매우 흔하다)

제가 맺은 계약도 10년 계약으로서 최악의 경우 계약 만료 전에 건물이 철거될 가능성도 있지만, 제 경우 어차피 사무실로 이용할 것 이기 때문에 비용처리가 가능하므로 ROI를 그렇게까지 엄격하게 따질 필요는 없었다는 것과, 10년 후에는 내 나이도 60을 지나고 있을테니 우선은 그 때 까지만 쓸 수 있으면 좋지 않을까 라고 생각했습니다.

그리고 집에서 근처 역으로 가는 길에 있었기 때문에 집에서의 출퇴근 뿐만이 아니라 사무실에 가기 전이나 후에 들럿다 가기에도 좋은 위치적으로 편리한 물건이라는 점에서 저에겐 딱 맞는 물건을 만나버린 느낌이었습니다.

앞서 언급했듯이, 이전에는 타코야키집이었지만, 당시의 시설과 인테리어는 완전히 철거되어 있어서 블럭과 콘크리트에서 시작해야 했습니다.

이것이 바로 물건을 보러 갔을 때의 사진입니다. 전기도 들어오지 않는 상태에다 바깥쪽 셧터도 열지 않은채 어둠속에서 물건을 확인했습니다. 하지만 충분한 넓이(약 15평)가 있었으며, 완전히 뼈대만 남겨놓은 상태였기에 비록 한정된 예산이긴 했지만 내 취향의 인테리어가 가능했기에 계약 의사가 굳어져 갔습니다.

개라지 오피스를 만드는데 있어서 물건 찾기보다 힘든것이 사실은 시공 업자 선정입니다. 대부분의 인테리어 업자들은 개라지 오피스를 만든 경험이 없으며, 원래 바이크를 좋아하는 사람이 담당자가 되는 경우도 흔치 않으므로 말이 통하지 않는 경우가 많습니다. 그래서 나의 구상을 설계와 목공에 강한 이벤트 시공업자 분들에게 이번 사무실 공사를 의뢰하기로 했습니다. 이러한 업체 분들과의 대화는 나 또한 많은 경험이 있기 때문에 편하다 라는 것과 코로나 사태로 인해 이벤트 수가 급감하여 결과적으로는 제 사무실 만들기에 시간을 내어주실 수 있었습니다. 아래 사진은 인테리어 공사를 담당한 팀이 처음 사무실 자리를 방문한 사진입니다. 이때 처음으로 셔터를 열고 바이크를 주차하기에 충분한 공간이 있는지와 출입이 가능한지를 확인 했습니다.

제가 시공 팀에게 제시한 요구 사항들은 다음과 같습니다.

• 여러대의 바이크 보관
• 헬멧이나 바이크 수트의 보관
• 캠핑장비, 자전거 관련 용품의 수납
• 작업 공간은 곡면의 대형 모니터와 넓고 높낮이 조절이 가능한 책상
• 방송 제작에 충분한 조명
• 유튜브와 웨비너를 위한 크로마키 벽면
• 풍부한 전원 콘센트
• 초고속 인터넷
• 바 카운터로 사용 할 수 있는 미니주방

기본적으로 나만을 위한 작업 공간이지만, 지금까지 자신이 모아온 캠핑도구와 바이크들, 주차된 바이크, 자동차를 감상할 수 있어야 할 것, 그리고 4~6명정도 앉을 수 있는 바 카운터와 유튜브 스트리밍이 가능한 스튜디오 공간이라는 것이 저의 요구사항이었습니다.

전체적인 분위기는 까페 보다는 미국식 개러지를 지향하기로 했습니다.

그리하여 초기에 나온 계획이 이것 입니다.

이것으로 위 요구사항들이 포함되어 있는것을 확인 할 수 있었으므로, 나머지는 시공을 진행하면서 그때그때 디자인, 위치, 조달되는 자재등을 확인하는, 마치 이벤트 부스를 인터렉티브하게 설계, 시공하는것과 비슷한 느낌으로 진행해 갔습니다. 대략 디자인과 예산을 정하는데 한달 반 정도, 시공에 한달 정도가 걸렸습니다.

현지 확인을 통한 애자일한 진행

작업 첫날인 8월3일의 모습입니다. 바로 앞에 작업 및 자재 반입을 위한 트럭 주차가 가능하다는 것도 이 물건의 장점중 하나 입니다.

인테리어 공사에 들어가기전, 우선은 철저하게 청소를 합니다.

인테리어도 실물을 현지에서 확인하면서 결정해 가는 방식입니다.

벽면 인테리어가 진행된 것 만으로도 단번에 이미지가 달라졌습니다.

영상 촬영과 웨비너의 배경으로 사용될 부분도 현지에서 결정했습니다.

이번에는 바이크의 실내주차 관련해서 소방소에 신고하는 절차입니다. 소방서 분들이 작접 오셔서 현지 확인도 마쳤습니다.

책상이나 조명등이 들어서자 상당히 모양이 갖춰지기 시작했습니다.
(사진 준비중)

자전거는 벽에 걸어두었습니다.

폭이 제법 있기 때문에 바이크가 주차된 상태에서도 낮잠을 잘 수 있는 접이식 대형 해먹을 놓을 자리도 나옵니다.

Still Day One!

인터넷등 아직 일부 작업이 남아 있긴 하지만 거의 시공이 완료된 덕분에 2020년 9월 1일 부터 사무실 운용을 개시 했습니다!

9월1일은 이전 직장인 AWS Japan을 2016년 8월 31일에 퇴직하고 지금의 경력을 시작한지 딱 4년째가 되는 시점이었습니다. 이거야 말로 Still Day One을 다시 확인시켜준 하루가 되었네요. 앞으로 이 사무실에서 보낼 10년동안 또 어떤 새로운 일을 만날지 두근두근 합니다.

작금의 코로나 사태로 인해 여러모로 신경이 쓰입니다만, 여러분을 사무실에 초대할 수 있는 시기가 온다면 꼭 방문해 주시길 희망합니다.

그 전 까지는 스트리밍과 웨비너를 통해 온라인으로 방문해 주셨으면 합니다. 웨비너를 원하시는 분은 연락 주시기 바랍니다!

소프트웨어 엔지니어 육성법으로서 패턴 언어의 가능성

디자인 패턴의 기원

일반적으로 GoF의 디자인 패턴이라는 이름으로 잘 알려진 디자인 패턴은 원래 건축가 크리스토퍼 알렉산더가 설계자와 사용자의 단절을 해체하기 위해 도입한 패턴 언어에 그 뿌리를 두고 있다.

여러 단어들이 모여 한 문장이 되고, 여러 문장들이 모여 하나의 글이 되듯이, 여러 패턴이 모여 하나의 패턴 언어가 되어 사람들이 기분 좋다고 느끼는 환경에 대한 분석을 가능하게 한다. 크리스토퍼 알렉산더에 의하면 각각의 패턴은 세계 각국의 아름다운 도시 및 주거 공간에 공통적으로 적용되는 보편적인 것으로, 예전에는 누구나 알고 있었던 것이지만 급격한 근대화로 인한 현대 도시 계획이 진행되면서 점차 잊혀져 버린 것이라고 한다. 각각의 패턴은 현대 도시 계획의 발상과는 정반대의 발상을 갖고 있으며, 인간적 척도 요소가 중시되고 있다.
바람직한 사회 전체를 한 번에 설계 및 건설 하는 것은 불가능하지만, 각각의 패턴에 따라 하나 하나의 진행되는 과정에서 일종의 커뮤니티를 형성하여 간다. 이러한 각각의 패턴을 찾아내는 것은 해당 도시 및 주거 공간에 거주하는 주민 자신이며, 건축가는 그들이 패턴을 찾아가는 것을 도와주고, 실제 모양이 되도록 설계 및 시공 감리를 하는 역할을 맡는다.     출전: 위키백과 패턴 언어페이지

크리스토퍼 알렉산더는 오늘날의 건축이 사용자를 위한 건축이 아닌 시공자를 위한 건축이 되어버린 원인을 설계에 대한 모든 권한이 건축가에게 일임 되는 건축설계 과정에서 발생하는 불완전한 커뮤니케이션에서 찾았고, 이를 해소하기 위해 일반인인 사용자를 건축의 설계에 참여시키기 위한 아이디어로서 패턴 언어를 생각해 내었다.

건축에 있어서 디자인 패턴은 이러한 패턴 언어를 지원하기 위해 과거 이루어졌던 건축이나 도시설계를 분석하여 패턴을 수집 하고 이를 바탕으로 패턴 언어를 구축하기 위한 어휘들을 지칭한다.

크리스토퍼 알렉산더의 이러한 주장은 건축분야에서는 큰 반향을 일으키지 못했지만 여기에서 영감을 받은 소프트웨어 개발자들의 연구에 의해 등장한 디자인패턴으로 소프트웨어 개발에 있어서는 큰 반향을 불러일으키게 된다.

프로그래밍에서의 패턴언어

소프트웨어 개발에 있어서 프로그래머 개개인간에 엄청난 생산성의 차이가 존재하는것은 익히 알려진 사실인데, 이러한 차이의 상당부분은 경험의 차이에서 오고 있다.
1994년 애릭감마를 포함한 네명의 저자에 의해 발표된 [디자인 패턴: 재활용 가능한 객채 지향 요소]는 소프트웨어 장인이라 불리우는 저자들의 수많은 성공과 실패의 경험속에서 축적된 노하우를 정제하여 스물세가지 패턴을 제시하였다. 초판 발간으로부터 20년이 흐른 오늘날에도 이 스물세가지 패턴은 꾸준히 이용되고 있으며, 오늘날에 와서는 이러한 패턴들을 기반으로 하여 앤터프라이즈 어플리케이션, 멀티스래드, UI, 데이터 구조, 아키텍쳐에 이르기까지 다양한 분야로 패턴을 확장하려는 노력이 꾸준히 시도되고 있다.

태권도 품새

디자인패턴을 익히고 사용하는것은 태권도에 있어서 품새을 익히고 사용하는 것과 동일하다. 태권도의 품새는 수많은 실전을 겪은 고안자가 수비와 방어 이동등에 있어서 이상적인 몸의 움직임을 정리하고 이를 패턴화 시켜 초보자가 이를 따라 함으로서 혼자서도 쉽게 익힐 수 있도록 한 것이다. 하지만 실전이나 겨루기에서는 품새의 형태대로 싸우지는 않으며, 그때그때 상황에 맞추어 대응하지만 기본이 되는것은 평소에 익혀둔 품새가 바탕이 된다.

패턴 랭귀지 3.0의 등장

물리적인 건축에서 시작된 패턴 랭귀지는 버전 2.0으로 불리우는 추상적인 소프트웨어의 디자인 패턴을 거쳐 교육이나 협력에 있어서 개인의 경험을 효과적으로 공유하기 위해 인간 행동을 대상으로 하는 버전 3.0이 등장하였다.

출전 :  패턴랭귀지:창조적인 미래를 만들기 위한 언어(Iba Takashi, 2014)

소프트웨어 개발자라면 디자인패턴의 유용성에 대해 잘 알고 있을것이다. 패턴 랭귀지는 대상을 소프트웨어 구현에서 인간 행동으로 확장 함으로서 개인의 경험을 효율적으로 공유하고 커뮤니테이션을 돕는 것을 목적으로 한다.

사실 패턴 랭귀지에서 다루는 패턴 그 자체는 대부분 전혀 새로울것이 없이 이미 존재하고 사용해 오고 있는 것 들이다. 패턴 랭귀지는 존재하는 패턴을 찾아내어 이름을 붇이고 일반적으로 적용하기 쉽게끔 언어를 정제하는 작업을 거친후에 마지막으로 각각의 패턴들간의 연관성을 찾고 연결함으로서 하나의 맵을 만드는 과정을 통해 완성된다.

프로그래머의 육성과 패턴 랭귀지

필자는 오래전부터 소프트웨어 개발자의 육성에 있어서의 패턴의 역할에 주목했다. 베테랑 개발자의 모든 습관에는 그 나름의 이유가 있으며 이를 패턴으로 정립하여 신입개발자들이 익혀서 따라해 볼 수 있게 한다면 이른바 도제 방식의 개발자 양성을 넘어 개발자 육성에 좀 더 효과적이지 않을까? 태권도의 품새와 같이 얼마간의 연습 기간을 통해 익히게 한 후 이것들이 일과 생활에서 효울적으로 사용 될 수 있도록 하면 효과적이지 않을까? 달인이라 불리우는 사람들이 저술한 설계와 구현, 매니지먼트 패턴은 이미 여러 책을 통해 세상에 나왔고 충분히 검증된 상태이다. 하지만 이 외에도 좀 더 패턴들이 있지 않을까?

예를 들자면 다음과 같은것들이 있다

학습패턴 : 우수한 개발자들은 끊임없이 변화하는 기술트렌드에서 뒤처지지 않게 나름의 학습패턴을 지니고 있다.
커뮤니케이션 패턴 : 주석을 포함한 문서화나 각종 메일, 프레젠테이션, SNS, 블로그 뿐만 아니라 일상의 대화나 회의등이 여기에 속한다.
네고시에이션 패턴 : 작업범위조정, 일정조정, 예산조정등 개발과 관련된 사항들에 대한 이해관계자들과의 조정능력.
품질 관리 패턴: 우수한 프로그래머들은 코드를 포함해 문서화등의 품질을 관리하는 나름의 방법론을 확립한 경우가 많다. 정밀 코드 레뷰나 믿을 만한 동료를 이용한 크로스 체크등 다양한 품질 관리의 패턴이 존재한다.
이 밖에도 일정관리/추정, 문서작성등은 물론이요 식사나 운동 습관, 구직/이직과 같은 사실상 인간 생활의 모든 분야에서 패턴을 찾을 수 있을것이다.

이러한 패턴을 찾아낸다면 그 다음엔 이름을 붙이고 사람들과 공유하고 토의해 보자. 아직도 세상에는 수많은 이름 없는 패턴들이 이름을 붙여주길 기다리고 있다.

회고에 대한 고찰 - KPT 진행의 노하우에 대하여

나프다Q&A에 동료에게 피드백을 주고받는 좋은 방법에 대해서 문의하는 질문이 올라왔다.

동료에게 피드백을 주고 받는 좋은 방법은 무엇입니까?

결론부터 말하자면 동료에게 좋은 피드백을 주기 위해서는 진심으로 동료를 아끼고 배려하는 마음이 가장 중요하다. 좋은 약은 입에 쓰다는 오래된 속담만 믿고 거친 말로 자극을 주려 하면 오히려 마음의 담만 쌓게 될 수도 있다. 이해하고 받아들일 수 있을 적절한 방법과 타이밍을 찾아내는것이 중요하고, 그 이전에 나의 말에 상대방이 귀 기울일 수 있도록 평소에 쌓아 놓은 신뢰관계가 무엇보다 필요하다.

이제 본론으로 들어가서 오늘은 회고에 대해서 이야기를 해 보자.

피드백에 대한 질문으로 회고에 대한 이야기를 시작한것은 회고야 말로 피드백을 가장 부담없이 그리고 효괴적으로 전달 할 수 있는 이벤트 이기 때문이다.

하지만 안타깝게도 많은 조직에서 회고를 실시하고 있지만 제대로된 회고를 진행하는곳을 찾아보기 어렵다.

회고 자체가 어려운것이 아니라 회고에서 다루어야 할 포인트를 잘못 짚고 있기 때문인데 오늘은 그에 대한 좋은 두개의 글을 소개해 볼까 한다.

맨 먼저 경영컨설턴트이신 유정식님의 글을 소개한다. 정말 좋은 글 이기 때문에 직접 링크를 따라가 본문을 꼭 읽어 볼 것을 권한다.

조용하다고 당신의 조직이 건강한가

이 글의 결론은 다음과 같다.

 조직이 사람들로 이뤄진 이상 크고 작은 실수가 생기지 않을 리 없다. 그러므로 실수와 문제가 없는 조직일수록 무언가 감추는 것이 많다고 생각해야 옳다. 시끄러울 정도로 실수를 드러내고 지적하는 조직이 조용한 조직보다 성과가 높을뿐더러 높은 성과가 오래도록 유지된다. 실수를 ‘실패’로 보지 않고 환경에 적응해 가는 ‘진화’의 과정으로 인식하기 때문이다.  

 그렇기 때문에 조직의 건강성은 무결점의 ‘정적인 상태’가 아니라 문제를 끊임없이 제기하고 그것을 고쳐 나가려는 동적인 과정에서 찾아야 한다. 조용한 조직은 성과를 높일 수 있는데도 그렇게 하지 못하는 조직이다. 조용한 조직은 성과 향상이 끊임없는 ‘학습과 적응’을 통해서만 가능하다는 것을 알지 못한다. 사실, 조용한 조직은 위험한 조직이다. 그들이 억누르고 있는 실수가 언제 큰 파국으로 번질 지 모를 일이다.

 공자는 말했다. “지혜란 무엇을 아는지 그리고 무엇을 모르는지를 아는 것이다.” 이 말은 실수는 잘못이나 죄가 아니라, 모르는 게 무엇인지 깨닫는 과정이라는 뜻으로 해석될 수 있다. 실수를 용인하고 권장한다는 말이 더 이상 듣기 좋은 구호로 끝나지 않도록 실천에 옮기는 것이 지혜로운 리더의 의무다. 당신의 조직은 조용한가, 아니면 시끄러운가?

다음은 CTO파견업이라는 비즈니스 모델로 일본에서 주목받고 있는 일본 소닉가든의 CEO이신 쿠라누키(倉貫義人)씨가 쓴 "자율적으로 현장을 개선해 나갈 수 있는 회고의 진행방식 - KPT 진행에 대한 노하우"를 번역하여 소개해 본고자 한다. 기사의 번역을 흔쾌히 허락해 주신 쿠라누키씨에게 감사의 말씀을 드린다.

(여담이지만 필자는 쿠라누키씨의 QCon Tokyo 2015강연에서 사회를 담당한 인연이 있다.)

자율적으로 현장을 개선해 나갈 수 있는 회고의 진행방식 - KPT 진행에 대한 노하우

현장의 운영을 개선하기 위해 먼저 착수한다면 뭔가? 고 물으면 항상 ‘회고’ 부터 시작하자 라고 대답 합니다. 과거에 카오스상태의 프로젝트에 들어 갔을 때 에도 가장 먼저 시작한 것은 '회고'에서 였습니다.

‘회고’는 말 그대로 현장의 활동을 되돌아보고 개선 작업을 생각하는 것입니다. 반성 회처럼도 보이지만, 모든 것이 끝나고 나서 반성하는 것은 아니고, 현상 분석을 실시하고, 잘 계속하기의 미래를 향한 활동입니다.

이 기사에서는 ‘회고’라는 문화, 그리고 회고를 실천함에 있어서 진행 방식과 포인트를 소개합니다.

회고의 진행 방식 "KPT"에 대해서

위의 사진은 우리 소닉 가든에서 ‘회고’를하고있는 모습입니다. 소닉 가든에서는 도제식 사원 육성 제도를 실시하고 있는데, 이 광경은 사수와 부사수(역자주:군대용어라서 죄송)가 참여하는 회고의 풍경입니다. 이처럼 특별한 도구는 아무것도 필요하지 않습니다. 필요한 것은 화이트 보드 하나면 충분합니다.

역자주) 소닉가든은 CTO 파견업이라는 비즈니스 모델을 가진 일본의 회사입니다. 나중에 기회가 된다면 자세히 소개를 하겠지만 혼자서 프로젝트를 진행하는 사원을 1대1 도제식 교육으로 5년에 걸쳐 육성하는 것을 목표로 한다 합니다.

사진 속 화이트 보드를 보면 그 회고의 내용이 적혀 있습니다. 3 개의 지역으로 나누어 져있는 것이 보이시나요? 소닉 가든에서 실시하고 있는 회고 방법은 "KPT"라고하는 것으로, 회고에서 주로 쓰이는 방법 입니다.

KPT는 Keep / Problem / Try의 약자로, 「Keep = 좋았던것」  「Problem = 나빴던 것」 「Try = 다음 시도 할」의  세 가지 프레임워크로 나누어 생각하는 방법입니다. 방금 보신 화이트 보드는 3 개의 구역인 Keep와 Problem와 Try으로 나누어 져 있습니다.

화이트 보드를 좌우로 나누고, 그 왼쪽을 더 아래로 나눕니다. 왼쪽을 Keep 왼쪽 하단을 Problem 오른쪽 절반을 Try를 내보낼 장소로 제공합니다. 자 우선 회고 시작해 봅시다.

역자주) T에 가장 큰 영역을 할당하고 있는것에 주목합시다.

회고 "KPT"의 구체적인 진행 방식

회고의 논의 대상은 '일하는 방식'에 대해서 입니다. 일의 진행 상황과 보고는 여기서 논하지 않습니다. 평소의 일을 할 때보다 조금 관점을 바꾸어 자신들의 업무 방식을 제3자 입장에서 객관적인 시선으로 보는 느낌을 가지고 진행합니다. 따라서 진척 회의는 별도로 가져가는 것이 좋습니다.

역자주) 진척회의와 회고를 분리해야 합니다.

먼저하는 것은 Keep와 Problem을 명확이 하는 것 입니다. 이 둘의 원천은 이전에 진행하였던 KPT의 Try입니다. Keep와 Problem을 정리할 때 중요한 것은 일어난 사건 자체 뿐만 아니라 좋았거나 나빴던 일에 이르는 과정에 대해 쓰는 것이 좋습니다.

이 때 중요한 것은 일단 논의를 뒤로 하고 생각 나는 것을 모두 꺼내 놓는것 입니다. 하나 하나 논의를 하고 있자면 끝이 없습니다. 우선 모두 발언하여 칠판에 적어나갑니다. 이렇게 화이트 보드에 꺼내 놓음으로써 비로서 개인 안고 있던 K와 P가 팀 K와 P로 변화하게 됩니다.

Keep와 Problem이 모두 나온 다음은, 나온 것 들을 일단 팀과 공유 한 후 Try(개선책)에 대해서 생각합니다. Try을 고려할 때 포인트는 구체적인 액션에 까지 구체화 시키는 것이 중요합니다. 예를 들자면 "○○를 조심" 이라고 하는 것은 Try가 될 수 없습니다.

"조심"이 왜 안 되는가? 그것이 구체적으로 무엇을 할 것인지, 다음 KPT의 때 제대로 할 수 있었는지 여부를 판정 할 수 있는 것이 아니면 안 되기 때문입니다. Try라는 정도이므로 이게 정답 이라는 게 나오기 힘들기 때문에 가설을 설정해서 이야기 합니다.

회고 기간과 그 효과

회고는 1 주일 단위 정도에서 실시하면 좋습니다. 첫 회고의 경우 전회의  Try도 없을 뿐더러 지금까지 진행해 온 방식도 있기 때문에, 길어지리라고 생각 합니다만, 1 주일 단위가 정착하면 회고 자체를 짧은 시간에 할 수 있습니다.

회고을 지속적으로 진행시켜 나가면 서서히 회고 방법 자체도 능숙해 지게 됩니다. 지난주보다 이번주, 이번주보다 다음주에 점점 더 잘 하게 되는 것 입니다.

회고는 혼자 해도 효과는 있지만, 기본적으로는 팀 임 함께 하는 것이 더욱 좋습니다. 개개인이 자신의 내면에 가지고 있던 "좋았던 것" 과  "나빴던 것"을 팀원들과 공유하여 함께 "다음 시도”에 대해 생각한다는 것은 팀워크에도 큰 도움이 됩니다.

함께 팀을 개선하기 위한 아이디어를 생각하는 것을 계속하는 것을 통해 멤버들이 한 팀이 되어가는 느낌을 가질 수 있습니다.

또한 만약 팀에 새로 들어온 멤버가 있었다 하면, 그 멤버에 문화를 전하는 가장 효과적인 방법이 이’회고'가 되는 것이 아닐까 라고 생각합니다.

회고의 '습관화'에서 '일상화'를 목표로

회고을 계속 이어 가면, 팀은 스스로 현장을 개선해 나갈 것이다라는 의식이 싹 트게 됩니다. 그렇게되면, 스스로 회고을 실시하고  개선을 거듭해 나갈 수 있게 됩니다.

정기적 인 '회고'를 습관화 한다. 이것이 목표로 1 단계입니다.

다음 단계가 되면, 회고 자체가 당연하게 되어, 일상 업무 속에서 항시적으로 할 수 있게 됩니다. 평소의 일에서 뭔가가 진행되거나 변화가 필요하다고 생각되는 시점에서 자연스럽게 조금씩 회고를 하게 됩니다. 이 단계까지 가능해 지면 일주일이라는 기간은 의미가 사라집니다.

즉, 일부러 일주일에 한 번 타이밍까지 기다릴 필요가 없게 됩니다. 이렇게 일상 속에서 회고를 할 수 있는 단계에 이르면, KPT를 해도 아무것도 나오지 않게 될 것입니다. 그렇게 ‘회고 '를 일상화 해 버리는 것이 두 번째 단계입니다.

회고가 정기적 이벤트에서 상시화 되는 것 입니다.

소닉 가든은 평상시는 이벤트로서 회고를 하지는 않습니다. 잘게 나누어 모두가 당연하게 일상적으로 회고를 하고 있기 때문입니다.

그러나 중도 입사 한 사원에게는 멘토가 붙어 이벤트로 회고을 정기적으로 실시합니다. 이는 습관화 된 일상으로 회고을 할 수있게 될 때까지 계속됩니다. 소닉 가든은 정해진 규칙 등은 없지만, 회고을 한다는 것이 거의 유일한 룰 입니다.

회고을 하면 사람도 팀도 성장할 수 있습니다. 회고을 익힌 사람이나 팀은 자율적으로 성장해 나갈 수있을 것 입니다. 성장이 없는 일을 계속하는 것은 평생 같은 일을 계속하는 것입니다. 글을 읽는 여러분도 회고를 통해 조금씩 이라도 성장 해 나갈 수 있으면 좋겠습니다.

덤 : 회고에서 일어나는 일반적인 문제

회고을 시작하여 익숙해지기 전에는 여러가지 문제가 발생합니다. 그리고 이러한 문제들은  대체로 비슷한 고민을 안고 있습니다. 여기서 덤으로 회고 진행시에 자주 발생하는 문제를 사례별로 소개하고 대응 방법을 생각해 보겠습니다.

"Keep이 나오지 않는다"

자신의 프로젝트에 좋은 점은 하나도 없고, 문제 투성이 라는 것입니다. 이상이 너무 높거나 너무 금욕적인 것 인지도 모릅니다. 그러나 이전 진행했던 회고보다도 좋지 않은 점이 나오지 않는 것은 심각한 문제 입니다.

원래 이전 회고에서 나온 Try가 전부 제대로 되지 않았다면 Try를 낸 방법 자체에 문제가 있는 것 입니다. 우선 그것 부터 개선 하도록 합시다.

"Problem이 고민 상담이 되는 경우"

Problem을 낼 때 단순히 고민하고 있는것을 말하는 것으로 Try가 도출 되지는 않습니다. 실제로 일어나지도 않은 문제를 걱정 할 필요는 없습니다. 지나간 일은 "나빴던 일"로 내면 좋을 것입니다.

"Try가 구체적이지 않다"

Try를 생각할 때 "기분"을 반영시켜 버리는 것은 해서는 안될 일 입니다. 기분에 의존해서 진행 하다 보면 다음에 무얼 해야 할지를 모르게 되어버립니다. 무엇보다 다음 KPT의 회고때 무엇이 되어 있고 무엇이 안되어 있는지 명확하게 판정 할 수 없습니다.

Try는 "시도하는 것"이​​므로, 그것이 반드시 정답이 아니어도 좋습니다. 다음 회고까지 시도하여 좋은 것이라면 계속하면 되고, 좋지 않다면 방법을 바꿔야 합니다. 이를 위해서는 Try의 내용이 구체적인 조치 여야만합니다.

"생산성을 따져보자”

Problem를 발행 할 때 자주있는 것이 「늦었다」 「잔업했다」같은 것입니다. 그 자체가 엉켜 버린 문제이기 때문에 Problem에 올리는 것은 좋습니다. 그러나 회고의 Try에서 생산성을 따져서는 안됩니다.

만약 본인이 한껏 노력한 과정에서 늦게까지 작업을 한 것 이었다 하면 놀면서 한게 아니기 때문에 더 이상의 극적인 생산성 향상은 기대하기 어렵습니다. 이 경우는 시간을 들여서 생산성을 높일 수 밖에 없습니다. 본인의 노력이 아닌 프로세스와 방법에 있어서의 개선안을 생각합시다.

또한 비슷한 이야기로​​ "일정을 낙관했다"도 NG입니다. 일정은 원래 낙곽적이 되기 쉽습니다만  만약 문제 자체를 "일정의 낙관”'탓으로 돌려 버리기 시작하면 해결책으로는 일정에 대한 버퍼를 쌓게 되는 것이 되어버리고 결국 그 앞에는 지옥이 기다리고 있습니다.

"진척 회의가 되어 버린다"

회고를 진행하다보면 왕왕 진적회의로 변질되어 버리는 경우가 있습니다. 그러나 회고 라는 것은  "어떤 의식으로 일을 수행하고 있는가?" "어떻게하면 효율적으로 일할 수있는 것인가?” 라는 일의 진행 방식에 대해 논하는 것 입니다. 진척 회의는 반드시 별도로 진행 합시다!

또한, 자칫 Problem을보고, 리더가 설교에 들어가 버릴 수 있지만, 그것도 좋지 않습니다. 회고에서 목표로하고 싶은 것은 스스로 회고을 하고 스스로 개선해 나가는이라는 의식을 갖게하는 것입니다. 설교를 하고 정답을 말해 버리면 스스로 생각할 없게 되어 버리고, 결국은 발전도 성장도 기대할 수 없게 됩니다.

일본경제신문 자체개발 전환사례 소개

 오늘날 모든 기업활동과 사회활동에서 IT는 이미 핵심 영역으로 자리를 잡은지 오래이다. 특히 2010년대에 들어서며 등장한 스마트폰은 IT를 생활과 완전히 한 묶음으로 만들어 버렸다. 그 결과, 과거의 IT가 기업활동이나 공공서비스의 핵심영역을 보조해주는 역할에 불과했다면, 오늘날에는 비즈니스 핵심영역과 결합되거나 아예 핵심영역 그 자체가 되어버린 경우도 쉽게 찾아볼 수 있다.

 특히 TV와 라디오, 신문, 잡지, 출판과 같은 미디어 영역은 스마트폰이나 타블렛과 같은 인터넷과 결합된 스마트 기기가 빠르게 생활속에 자리잡아감에 따라 플랫폼 자체를 변화 시켜야만 하는 선택의 기로에 놓여있다.

 이러한 가운데 주목받고 있는 흐름이 바로 인하우스 개발(=자체개발)로의 회귀이다.
 초창기 기업들의 IT시스템은 자체개발로 시작한 곳이 많았으나 점차 전문 IT서비스 기업들이 등장함에 따라 비 IT기업들은 비용과 전문성, 지속성의 문제로 시스템 개발을 외주에 의존하여 개발하는것이 서서히 일반화 되었다. 하지만 최근들어서 속도와 품질, 그리고 비용이라는 측면에서 IT부서의 규모를 확대하고 개발자를 사원으로 채용하려 하는 움직임이 표면화 되기 시작한 것이다.

 이번 포스팅에서는 일본의 대표적인 경제전문 미디어인 일본경제신문사(이하 닛케이)의 디지털 편성국에서 근무하는 스즈키 요스케씨가 2015년 8월 15일 BPStudy에서 발표한  인하우스 개발 전환 사례를 통해 자체개발로의 전환에 필요한 요소들과 주의해야 할 위험 요소들에 대해 살펴보고자 한다. 포스팅의 내용은 Speaker Deck에 올라온 슬라이드에 기반하고 있으며, 한국내 개발자들이 이해하기 쉽도록 약간의 해설을 가미하였다.

 본격적으로 이야기에 들어가기 앞서 번역을 허락해 주신 닛케이의 스즈키 요스케씨께 감사의 말씀을 전한다.

닛케이전자판의 자체개발화에의 도전

원문: 日経電子版　開発内製化の取り組み

• 자기소개

• 스즈키 요스케(鈴木陽介)
• 일본경제신문사 디지털편성국 소속
• 2001년 입사
• NIKKEINET의 컨텐츠 운영, 산업부기자, 인터넷판 컬럼의 편집자등을 거쳐 2009년경 부터 디지털판 기획/개발 담당
• Python을 중심으로, JavaScript(Coffee), Go등을 일과 개인적인 용도로 사용하고 있습니다. Pebble로도 즐기고 있습니다.

• 앱 자체개발에 대한 이야기를 공개했었습니다.

• 닛케이디지털판 자체개발 비화 by Natsuki Akama
• 특히 신문 업계의 반향이 엄청났습니다

• 일본경제신문(닛케이)에 대해서

• 1876년 설립, 2016년으로 140주년을 맞이하는 미디어 전문회사
• 1000명 이상의 기자와 편집자가 근무
• (역자주) 특히 인터넷과 IT에 관련한 신문,잡지,서적등의 출판을 활발히 펼치는 미디어로서 일본내에서 독보적인 위치에 있음.

• 닛케이디지털판에 대해서

• 40만명이 넘는 유료회원
• 유료 뉴스서비스로서 세계4위
• 아이폰과 안드로이드에 대응하는 모바일 서비스를 강화
• 서비스계의 개발부문은 약 40명 정도가 근무

• 닛케이의 시스템개발 역사

• 1972년 세계최초의 신문제작 시스템을 개발
• 1984년 데이터베이스 서비스 '닛케이텔레콘' 개시
• 1996년 인터넷 서비스인 NIKKEINET개시
• 2010년 닛케이전자판 창간

• NIKKEINET시절에는 내부개발이 주로 이뤄졌었습니다

• 영문기자출신이신분이 비주얼 베이직으로 만든 CMS가 애용되고 있었습니다
• Perl로 억세스로그의 집계,분석 툴을 개발
• CloudFusion으로 서비스용 서버어플리케이션 제작
• PHP와 비슷한 녀석입니다
• 의외로 성능이 좋았습니다
• 결국 사람에 의존한 개발 체제였기 때문에 점차 외주개발로 바뀌어가게 됩니다
• (역자주) 사내의 개발에 열정을 지닌 사람들이 시작한 프로젝트였으나 퇴사나 근무처 이동등에 의해 지속성을 지니기 힘든 구조였을듯 합니다.

• 닛케이전자판의 개발(창간무렵까지)

• 초거대SI업체가 대거 참여하여 개발
• 성능(레스폰스)는 좋았음
• 변경 비용이 증대
• 테스트는 기본적으로 수동, 테스트 비용의 증가로 예산이 오버되어 계획이 실현 되지 않았던 경우도 있었음

• 내부개발화로의 흐름

• 2010년 당시
• 자그마한 변경에도 꾀나 번거롭고 시간과 돈이 들어가는 구조

버튼 하나 추가에 2주의 기간과 수십만엔의 비용이 발생하는 비효율적인 구조 

• 기획을 올려도 아주 작은부분만이 실제 구현되었음 
• 이대로 괜찮은건가? 라고 초보처럼 생각했다
  (이러저러한 이유가 있었으나 당시엔 알지 못했음)

• 거의 맘대로 두사람으로 개발을 시작해 보았다

• 처음에는 PHP+Ruby+MySQL로 사내 서버를 만들었다
• 2010년 여름경
• 성능은 그저그랬음
• PC판의 일부 페이지ㅡ를 구현함
• 1개월 반정도 소요
• UI는 바꿔 보았다
• 결국 이 버전은 창고행으로...

• 스마트폰 브라우저 버전(베타)의 개발

• 창고에 넣어 두었던 버전은 존재의미가 그다지 없었다
• 2011년 당시, 스마트폰 브라우저 버전이 없었던 관계로 그것을 만들어 보기로 함
• Google App Engin(이하GAE)을 사용해서 인프라를 포함해 단 두명이 만들었음
• HTML5의 기능을 풍성하게 집어넣은 엣지있는 서비스가 만들어졌다

• 자체개발한 서비스가 정식으로 서비스됨

• 2012년에 윈도우8용 앱을 자체 개발
• 2013년에 인프라, 프론트엔드 모두 새로만든 모바일 브라우저 버전을 공개
• 프론트엔드의 자바스크립트는 당시 신입사원이 자체 개발했다
• 지금은 다른 신입사원이 개발중
• 도급형이 아닌, 외부 개발자가 사내에 상주하며 개발하는 스타일도 늘었다
• 아직 주류는 아니지만 자체 개발에 대한 분위기가 슬슬 나오기 시작함

• 좀 더 모던한 개발이 하고싶다!

• 자체 개발을 좀 더 발전시켜보고 싶었음
• 2013년 12월경 한 스터디 모임에서 naoya씨(역자주:일본의 유명 개발자로 AB테스트 플랫폼인 Kaizen platform의 개발자로 유명)에게 기술고문을 부탁했더니 OK해 주셨습니다!
• 이걸로 삐까뻔쩍모던한 개발이 바로 시작될줄 알았으나...

• 하지만, 기술이 문제가 아니었다!

• 우선 개발팀의 체제를 변경
• 눈이 튀어나올것 같은 엑셀 어사인표에 직면
• 여러 업무에 대한 겸임을 가능한 해소함
• 자체 개발의 범위를 좁힘
• 우선은 프론트엔드를 중심으로
• 개선팀을 만들어 적극적으로 활동
• 정보를 공유함
• 회의 아젠다를 시간을 들여 작성함
• 회의 참석 인원은 최소한으로
• 맴버들의 자기 주장이 부족함
• 등등, 나오야씨에게는 기본적인것에서 많이 꾸중을 듣기도 했습니다만
• 내부의 인원만으로는 타성에 젖기 쉬웠으므로 감사한 마음으로 받아들였습니다

• 개선팀의 운영에 도전한 결과

• 정보공유
• 엔지니어 채용
• GitHub&Pull Request도입
• 프로퍼티 자동화
• 자동 테스트
• 내부적으로는 문제에 대처해 나가면서, 매번 테마를 정해 naoya씨와 토론을 진행해 나갔습니다

• 커뮤니케이션 툴의 도입

• 슬랙
• 사내외 맴버를 포함해 270명이 넘는 인원이 사용
• Qiita:Team(역자주: 일본에서 인기있는 개발자대상 정보공유 플랫폼인 Qiita의 기업용 버전. Markdown을 지원하며 코드를 손쉽게 글 안에 포함시킬 수 있는것이 특징임. 아틀라시안의 컨풀루언스와 마찬가지로 KM플랫폼으로 주로 사용되고 있음)
• 사내외의 100명이 넘는 인원이 참가
• 회의에서 'Qiita에 적혀져 있습까?'라고 말해지는 경우가 늘어났다
• 1000개가 넘는 게시물이 등록!
• 처음에는 좀체로 사용해 주시지 않았습니다만 끈질기게 침투시켰습니다

• 합숙 워크샵을 개시

• 3~4개월에 한번씩 합숙워크샵을 개최
• 로드맵등을 공유

몰입적 사고를 위한 진지한 워크샾을 통해 성공에 대한 이미지를 공유

• GitHub

• 자체개발을 진행하고 있는 팀과 프론트엔드 주변 팀의 도입은 거의 완료
• 모바일앱, 인프라의 Ansible Playbook, Django의 API개발은 Pull Request로 개발
• 디자이너도 Pull Request를 이용하고 있음

• CI와 테스트자동화

• GitHub에 대한 push를CircleCI와 연동
• 모바일 앱의 유닛&e2e테스트 실시
• 인프라의serverspec실행

• 채용 블랜딩

• 스터디 모임에서 발표한다
• 지금 이 자료
• iOS 자체 개발담
• 스터디 모임의 회장 포스트를 이용
• Gocon(Go언어 개발자 컨퍼런스)
• Rebuild Meetup
• Ansible Meetup
• 해커톤
• Cookpad와 공동으로 개최

• 돌이켜 보니 중요했던 부분들

• 비전을 내걸고 그곳을 향해 팀을 개혁한다
• 특히 오래된 조직은 움직임이 느리고 방해가 끼어들기 쉬움
• 하지만 모두들 효율이 나쁜것을 하고싶다고 생각하지는 않음
• 열의를 가지고 이상을 향해 노력한다
• 생각하는 방식은 모두 다를 수 밖에 없다. 반복해서 정보를 발신한다
• Qiita등을 이용해 이러저러한 내용을 적으면, 제대로 읽고 건설적으로 코맨트를 해 주는 사람도 많았음
• 모던 기술의 도입도 중요하지만, 그것을 모두를 위해 실시하는것이 중요함 

• 일단 시작해 본다!

• 생각만 하고 있으면 앞으로 나갈 수 없다
• 타사의 사례같은것을 모아도 그것만으로는 진행 할 수 없다
• 어떻게 하면 가능한가? 가아니라 일단 시작 해 보자
• 우선은 손을 움직여서 실적을 만들어 내는것도 중요
• 무언가 만들어 자체개발이 가능한것을 증명했다
• 두사람만 있어도 의외로 가능하다
• 코드는 엉망이어도 우선 가능하다는것을 보여준다
• 사내 체제가 자체개발이 가능하게 되면 그때부터 코드리뷰를 도입한다
• 오히려 세세한걸 모르는 덕에 가능한것도 있다

• 왜 자체개발을 하려는지 제대로 설명한다

• 목적과 수단은 거꾸로되기 쉽다
• PDCA사이클을 고속으로 반복할 수 있는것이 자체개발의 강점임!
• 외주작업으로는 이것이 가장 어려움
• 사양검토->견적->발주작업등등
• 엔드유저의 의견이 다이렉트로 오는 프론트엔드를 우선적으로 자체개발 대상으로
• 사내에 노하우가 쌓인다
• 비용이 줄어든다
• 쓸데없는 회의가 줄어듦
• 낮시간에는 회의만 줄창 하다 저녁이 되어서야 작업하는 상황이 사라짐

• 맨토를 부른다

• 노하우가 없는 상태에서 자력으로 모든것을 개발하는것은 무리임
• 하지만, 통채로 외주를 해 버리면 사원에게는 노하우가 쌓이지 않음
• naoya씨의 '외부인의 의견을 듣는다'에서
• 외부인의 시각을 통해 무의식적으로 해 왔던 것들에 대해 수정/개선하는것이 가능해짐
• UI나기술에 대해서도
• 앱의 UI에 대해서는 fladdict씨
• 파이선의 개발에 대해서는 hirokiky씨
• 그외, 과거에 몇번인가 멘토를 불렀었음

• 어쨋거나 진흙탕은 피할 수 없다!

• 프론트엔드부터 한다
• 특히 모바일쪽
• 새로운것 부터 한다
• 새로운API군
• 뜯어 고치는 것 부터 한다
• 인프라의 AWS 이행시에 Ansible을 도입
• 운용을 강화
• 내부개발화에는 역시 우수한 엔지니어가 필요함
• 엔지니어 대상의 브랜드이미지를 개선한다
• 상층부와 이미지를 공유

• 닛케이전자판((닛케이본사)는 엔지니어 채용중!

• 편안한 마음으로 사내 견학도 OK!
• dg_lab@nex.nikkei.co.jp 으로 연락 주세요.
• 학생분들은 hack.nikkei.com으로 인턴 응모도 가능합니다.

• 닛케이전자판팀의 좋은점은?

어떻게 하면 사람들이 즐겁게 테스트를 작성하도록 할 수 있을까?

프로젝트에서 프로덕트로

 제임스 루이스와 마틴 파울러는 마이크로서비스에 대한 논문에서 마이크로서비스의 특징의 하나로 프로젝트에서 프로덕트로의 패러다임 전환을 꼽고 있다.

 하지만 이는 마이크로서비스에 대한 것 만은 아니다. 소프트웨어의 품질과 기능 그 모든면에서 프로젝트에서 프로더트로의 관점 전환은 대단히 중요한 요소이다. 오늘 소개할 InfoQ의 기사는 바로 그러한 관점의 전환이 소프트웨어 개발과 테스팅을 어떻게 바꿔 놓을 수 있는지를 보여준다.

 자동화 테스트는 메트릭스의 모피어스가 건네주는 알약과도 같아서 일단 처음 어느 정도 고통스러운 시기를 거치게 되지만 한번 제대로 동작하기 시작하면 자동화 테스트가 없는 개발로는 두 번 다시 돌아가지 못한다. 하지만 그 첫 걸음을 어떻게 하면 고통 없이, 또는 적은 고통으로 성공시킬 수 있을까?

 자신의 개발 조직에 자동화 테스트를 도입하려고 하고 있거나 이미 도입하였지만 제대로 정착 시키는 데에 어려움을 겪고 있다면 이 기사가 큰 도움이 되리라 생각한다.

www.workyouenjoy.com

어떻게 하면 사람들이 즐겁게 테스트를 작성하도록 할 수 있을까?

원문 링크 : Leading a Culture of Effective Testing


 저는 제가 개발에서 운영까지 책임을 맞았던 최초의 시스템을 지금도 잘 기억하고 있습니다. 다행히도 설계에서 지원까지 모두 맡았습니다. 몇 년 후, 그 시스템 중 하나의 하위 시스템이 자주 사용되게 되었습니다. 지속적인 기능 추가 요청이 오기 시작했고 복잡성은 증가했습니다. 변경을 할 때마다 나는 주의 깊게 기존의 기능을 확인 했습니다 만 수작업으로 하는 검사는 시간이 걸리고 기능 추가에 따른 복잡성의 증가는 폭발적으로 늘어났습니다.

 다른 사람들과 마찬가지로 나는 자동 테스트에 대해 들어 본 적이 있었지만, 그 방법을 배울 시간이 없었습니다. 그러다가 시간적 여유가 생겼을 때, 나는 몇 가지 책을 읽고 그 방법을 배웠습니다. 그 방법을 현실의 일에 적용 한 결과, 성장함에 따라 변경이 어려워 졌던 서브 시스템의 문제를 해결하기 위해 자동화 된 테스트는 완전한 방법이라고 느꼈습니다. 어느 날 오후, 나는 자동차 드라이브 나가고 있었습니다. 시간에 여유가 생겼던 겁니다. 인터넷에 연결되지는 않았지만 테스트를 작성하는 데 필요한 모든 도구를 가지고 있었습니다. 며칠 후 수동으로 실시하고 있던 검증의 세세한 부분 대다수를 자동화했습니다. 시간 절약 효과는 엄청난 것 이었습니다. 몇 시간 이나 필요했던 테스트가 불과 몇 초 만에 끝나버렸습니다.

 그러나 시간 절약은 두 번째 효과였습니다. 내 머릿속의 모든 시나리오가 크게 변화했습니다. 만든 것에 대한 신뢰의 감각이 되살아 난 것입니다. 아직 복잡성이 증가하지 않는 새로운 시스템에 대한 신뢰와 비슷합니다. 새 릴리스를 할 때 마다 불안감이 머리속을 떠나지 않았습니다. 여러 번 확인 했음에도 불구하고 불안은 사라지지 않았습니다. 응용 프로그램의 릴리스에 따른 지원은 만든 사람이 책임을 져야 했기 때문에 본능적으로 릴리스를 꺼리게 되었습니다. 이러한 상황에서 자동 테스트의 도입은 불안감을 안심으로 바꿔주었습니다.

 테스트에 누락이 있으면, 간단하게 테스트를 추가하고 다시 누락 되지 않도록 했습니다. 자신감이 생기자 위험을 감수하고 새로운 기능을 추가 할 수 있게 되었습니다. 또한 더 이상 문제를 무서워하지 않고 가치를 제공하는 데 주력 할 수 있었습니다.

 수동 테스트의 경우 테스트 시나리오는 수동으로 주의 깊게 설계하고 수동으로 실행하며 수동으로 확인 해야 합니다. 게다가 머리 속에 남아 있는 시간은 길지 않아 쉽게 잊혀집니다.

 자동 테스트의 경우, 시나리오, 실행, 검증은 모두 프로그램에 의해 문서화 되고 자동화됩니다. 유일한 수동 절차는 실행 버튼의 클릭 뿐입니다. 기억에 의존 할 필요도 없으며, 유통 기한이 지난 문서를 의지하여 시나리오를 쫓아 수동으로 수행 할 필요가 없습니다.

 대부분의 개발자가 테스트 자동화의 가치를 인정하면서도 그 혜택을 향유 하는 데 에는 실패했습니다만, 나는 다행히도 장점을 누리기 위한 올바른 방법을 찾을 수 있었습니다.

책임

 만약 제가 테스트에 대해 책임을 지지 않았다면, 테스트를 자동화하는 시간은 없었을 것입니다. 이것은 매우 간단한 것입니다. 자신이 개발을 지원하는 시스템의 사후 지원을 담당하는 것으로, 나는 소프트웨어가 제대로 작동하는지 보장하는 데 큰 관심을 갖게 되었습니다.  오전 5시 전화 받고 일어나 시스템 장애를 해결하는 사태를 막기 위해 나는 문제점이 이월 되지 않도록 꾸준히 노력해 왔습니다.

 개발자야 말로 만든 것을 어떻게 확인 해야 할지 가장 잘 알고 있습니다. 어느 부분에 자신이 없거나 어디에 복잡성이 존재하는지 어디에 문제가 포함될 여지가 있는지 잘 알고 있지요. 개발자 이외에 이처럼 포괄적인 관점을 가지고 있는 사람은 없습니다. 개발자는 작업 자동화 전문가이며, 검증 작업 자동화의 적임자입니다.

 많은 개발자들이 개발 한 시스템의 사후 지원이 가능하며, 그 책임을 다른 사람에게 전달하고 싶어하지 않습니다. 뭔가를 만든 사람은 그것이 성공하는 것을 희망합니다. 우리가 할 수 있는 것은 개개인이 어떠한 것에 대하여 공헌하고 싶어 하는지 묻는 것입니다. 책임을 공유하고 개발자가 시스템의 사후 지원에 기여할 수 있도록 하는 것이 효율적인 테스트의 이점을 누리는 방법입니다.

제각각인 팀을 융합하다

 만약 조직이 소프트웨어 개발의 책임을 여러 팀에 분산 시키게 되면 테스트를 하는 것은 힘든 작업이 됩니다. 불행히도, 고객의 납품이 완료된 이후의 시점부터는 이러한 어려움이 일상화되어 버리게 됩니다.

 테스트가 다른 팀에 맡겨진 경우 대부분의 경우 수동 테스트입니다. 자동화되어있는 경우에도 유지 보수하기 어려운 엔드 - 투 - 엔드 테스트입니다. 엔드 투 엔드 테스트는 운영 환경과 동일한 환경을 설정 해 줘야 합니다. 또한 개별 부분을 잘라낼 수 없습니다. 또한 뭔가 잘못되면 많은 테스트에 영향을 주고, 의미있는 피드백을 실패로 부터 얻을 수 없게 됩니다. 응용 프로그램 업데이트를 비활성화 버리는 취성 엔드 투 엔드 테스트 코드를 정기적으로 업데이트한다면, 수동 테스트에 회귀하는 것은 자연스러운 것입니다.

 분리 된 테스터가 응용 프로그램의 낮은 수준을 테스트 하기 위한 능력과 지식을 가지고있는 것은 드문 경우입니다. 특히 효과적인 검증 될 필요가 있는 단위 테스트 수준의 것은 알 수가 없습니다. 단위 테스트는 시스템을 작은 단위로 분리하고 확인합니다. 이 수준에서는 코드와 애플리케이션에 대한 깊은 이해가 필요 합니다 만, 개발자 만이 이에 대한 지식을 가지고 있습니다. 만약 개발에서 분리 된 테스터가 이러한 단위 테스트에 대한 지식을 지니고 있다면, 그 테스터가 개발팀이 아닌 것은 이상한 일입니다.

 또한, 테스트의 책임이 전가되어 버리면 개발자에게 소프트웨어를 성공적으로 움직이는 것에 대한 책임이 없다 라고도 할 수 있습니다. 하지만 그러면 개발자에게 신뢰하지 않는다는 메시지를 보내 버리게됩니다. 이것은 최악의 마이크로 관리입니다. 우리는 확인 사항이 줄을 설 정도로 많은 새로운 기능을 개발하고 있습니다. 실제로 테스트를 하고 피드백을 하는 데 몇 일, 몇 주 가 소요될 것입니다. 작은 문제가 숨어 있던 것 만으로도 새로운 기능의 구현에 장애가 될 수 있습니다. 그리고 기능 구현이 지연하면 급격하게 진행이 악화되고 마는 것입니다.

 이렇게 개발과 테스트를 분리하는 것은 자연스러울 지도 모릅니다 만, 결과적으로는 테스터의 레이어가 두꺼워지고, 몇 번이나 확인을 하게 되어 버립니다. 나는 3 개 이상의 분리 된 테스트 단계를 가지고 조직을 알고 있습니다. 이 경우 전체 프로세스가 멈추었습니다. 하나의 경쟁 상대가 책임을 직접 개발자와 공유하는 방식의 장점을 발견 하게 되면, 상대적으로 다른 기업에 불리한 위치에 서고, 결국 경쟁에서 질지도 모릅니다.

 책임과 권한의 명확화는 효율적인 테스트를 하는 데 매우 중요합니다. 하나의 팀이 테스트 지원에 책임을 갖게 합니다. 책임 여러 팀에 분산 되어 있다면, 하나의 팀으로 통합 해야 합니다. 테스터가 개발자의 옆에서 일을 하게 하는 겁니다. 또는 각각의 멤버들이 테스터와 개발자 모두의 역할을 서로 확인하고 편견을 제거합니다. 개발자가 일부 단위 테스트를 작성하고 다른 테스트 팀에 전달하는 것이 아니라, 단위 테스트와 엔드 - 투 - 엔드 자동화 된 테스트를 할 것인지, 아니면 수동 테스트를 할 것 인지를 상황에 따라 전체적인 의견을 통해 결정 하도록 합니다.

 새로운 팀의 업무 초첨은 단일 기능 또는 관련된 몇 가지 기능에 한정 시키는 것이 좋습니다. 이렇게 하면, 전원이 함께 일하고 하나의 기능을 개발하고 테스트 할 수 있습니다. 서로 상관 없는 변경 요소를 한 팀에 처리 시킨 다던지, 대규모 변경의 대응을 개발 팀 테스트 팀, 지원팀 사이에서 몇 달에 걸쳐 이동하는 것이 아니라 하나의 팀으로 작은 릴리스에 필요한 모든 것을 수행 하고 1 에서 2 주 기간으로 작업합니다. 이 제한적인 포커싱에 의한 개발 방법은 실제로 생산성을 향상 시키고 있습니다.

 작은 변경을 실시하는 것으로, 고객의 의견을 신속하게 받을 수 있게 됩니다. 변화가 작기 때문에 테스트 환경이나 스테이징 환경도 쉽게 준비 할 수 있고, 외부 고객의 리뷰에 더욱 포커싱 할 수 있게 됩니다. 고객이 확인할 내용에 대해서도 모호함이 줄어듭니다. 피드백이 오는 것도 빠르게 되어, 피드백에 대한 대응도 늦지 않게 됩니다. 큰 덩어리보다 작은 변화가 더 테스트하기 쉽기 때문입니다. 빠르게 피드백을 받고 빠르게 변경하고 출시하여 다음의 작은 기능 세트로 이동합니다.

자동 테스트의 가치를 보여주다

 팀 개개인이 개발, 테스트 및 시스템 지원의 책임을 가지게 되면 두 가지 선택이 있습니다. 하나는 팀이 수동으로 테스트가 효율적이고 않는다는 것을 깨달을 때 까지 기다리는 것. 다른 하나는 도박을 피하고 팀을 교육하는 방법 입니다. 적당한 지침 없이 자동 테스트를 실시하는 데 몇 년이 걸립니다. 개개인이 일상적인 업무량에 치이고 있는 경우에는 특히 그렇습니다. 자동 테스트를 도입한다고 해도 학습하는 데 몇 년이 걸립니다. 그러나 전문가의 도움을 받아 테스트 자동화의 가치를 알리는 것으로,이 기간을 단축 할 수 있습니다.

 자동 테스트에 완전히 매료되어 충분한 성과를 올린 후, 나는 다른 사람들도 동참 시키고 싶다고 생각 하게 되었습니다. 먼저 데모를 실시하여 자동화 된 테스트 도구의 활용 방법을 설명했습니다. 하지만 이 방식은 실패 였다고 생각합니다. 직접 실제 프로젝트에서 자동 테스트를 실시 할 수 있도록 지원하는 것이 아니라 시험 방법을 가르쳐 버린 것입니다. 가르치는 것 만으로는 부족합니다. 테스트의 가치를 증명하는 유일한 방법은 팀이 실제로 책임 지고 있는 일에 대해 테스트를 통해 자신감을 키우는 것을 도와주는 방법 뿐 입니다.

 가장 효율적인 것은 자동화 된 테스트 기법을 실천할 수 있는 기회를 만들고, 복잡하고 오류 나기 쉬운 응용 프로그램에 적용해 보는 것입니다. 개발자는 모두 까다롭고 다루기 귀찮은 시스템을 최소한 하나는 가지고 있습니다. 경험을 통해 불안감을 자신감으로 바꾸는 체험만이 자동화 테스트가 개발의 일부로서 받아지도록 하는 유일한 방법입니다.

개인 개발자가 다음과 같은 것을 경험하면 도입은 더 수월하게 진행 되겠지요.

• 복잡성을 자동으로 테스트하는 것에 대한 신뢰.
• 테스트 주도 개발의 경우 코드를 작성하기 전에 테스트를 작성하여 소프트웨어 개발을 진행해 나가는 것.
• 의미 없는 테스트에 대해서 테스트를 자동화하는 것은 역효과. 이 트레이드 오프를 깨닫기 위해 몇 년을 낭비한다. 많은 자동화 된 테스트를 포기하게 되는 큰 원인.
• 도구가 자동 테스트의 부하를 획기적으로 낮출 것.
• 테스트는 소프트웨어의 변경과 기능 추가가 쉬워 기존 기능도 심플하게된다는 것.
• 기존 문제의 근본 원인 분석 수정에 테스트가 도움이된다는 것.
• 외부의 실시간 시스템과의 통합 등 수동 테스트가 불가능한 영역에서 자동 테스트가 효과를 발휘한다는 것.

개발자 툴 킷 중에서도 자동 테스트에 큰 가치가 있음을 증명하는 것은 간단합니다. 개발자가 자동​​ 테스트가 일을 개선해주는 것을 한번 경험하면 그 이후로는 단번에 가치에 대해 깨닫게 됩니다.

강제로 요구 하지 않기

 데모를 실시하고 자동화 테스트의 전파에 실패한 후, 나는 적어도 팀이 나를 따라 올 수 있는 상태를 만들고 싶다고 생각했습니다. 여기서 저는 또 다른 실패를 저지릅니다. 그것은 응용 프로그램의 일부에 대한 테스트를 쓰는 것을 의무화 한 것입니다. 이것이 실패한 것은 다음의 두 가지 이유에서 입니다.

•  제 자신이 너무 많은 책임을 지고 말아 버렸습니다. 뭔가 좋지 않은 일이 일어 났을 때, 늦게까지 남아있는 역할 이었는데, 그에 따라 많은 테스트가 내 부담이 되었습니다. 나는 잘 작동하지 않을 것 같은 시스템의 일부에 대한 테스트를 선택했습니다. 하지만 테스트 케이스를 전달 하는 과정에서 본래의 의미는 사라져 버렸습니다.
•  의미가 희석 되어 버렸으므로, 가치도 느껴지지 않습니다. 그리고 성급하게 테스트 케이스를 만들었습니다. 그 결과, 테스트 케이스의 질이 희생되었습니다. 이해하기 어렵고, 대충 적당한 , 때로는 부정확 한 사례가 되어 버렸습니다. 룰을 강제 하여 많은 테스트가 만들어 졌지만, 그 테스트가 쓸모 없다는 사실을 깨달았습니다. 목적을 잃어버린 테스트 작성은 벌칙 게임 같은 것입니다. 쓸모없는 테스트는 프로젝트에 유해한 요소가 되어 유지 보수 해야 할 코드의 양만 늘려버립니다. 또한 사용할 수 없는 시험은 장기적으로는 혼란의 씨앗입니다. 시간이 흐르면 의미 없는 테스트가 본래 시스템이 가져야 할 모습을 묘사하고 있는 것으로 둔갑하게 되기 때문입니다.

 책임을 공유하고 테스트 케이스의 장점을 근본부터 이해하게 된다면 그 이후로 프로그래머는 가치가 있는 테스트를 작성하기 시작합니다. 교훈은 매우 간단합니다. 즉, 강제하는 것은 피하라.

그 밖에도 몇 가지 피해야 할 사항들이 있습니다.

• 코드 커버리지 수준을 강제한다.
• 테스트 코드 커버리지는 테스트 케이스가 커버 하는 코드의 양을 측정합니다. 범위가 80 %라면 20 %의 코드는 테스트를 실행하여도 호출되지 않습니다.
• 코드 커버리지는 테스트하지 않은 영역을 손쉽게 찾을 수 있는 긍정적인 면이 있기도 합니다. 그러나 테스트의 품질을 보장​​하는 것은 아닙니다. 테스트 케이스의 효과는 수치로 측정 할 수 있는 게 아닙니다. 또한 응용 프로그램은 테스트 할 가치가없는 영역도 있습니다. 따라서 100 %의 커버리지를 제공하도록 지시를하는 것은 현명한 생각이 아닙니다.
• 코드 커버리지 수준을 강제하는 것은 쓸데없는 테스트를 많이 낳아 버립니다.
• 코드를 작성하기 전에 테스트를 작성하도록 지시한다. 즉 테스트 주도 개발 (TDD).
• TDD는 매우 중요한 기술입니다. 그러나 강제하는 방식으로는 진행하지 말아야 합니다. 응용 프로그램에는 TDD가 유효하지 않은 부분이 존재 하게 마련입니다. TDD의 가치를 나타내는 것은 좋은 것입니다. 그러나 개개인이 자신의 판단에 따라 실천 해야 합니다.
• 테스트 수를 강제한다.
• 이것은 코드의 라인 수를 지시하는 것과 같습니다. 의미가 없습니다.
• 시스템에 불필요한 테스트가 있다면, 과감히 제거해 나갑시다. 테스트 코드는 유지 보수 해야 하는 코드의 양을 늘립니다.

 이러한 강제에 의해 개발자는 난처한 상황에 빠지고, 쓸데없는 테스트가 태어나 시스템의 유지 보수 용이성을 저하 시킵니다.

장애물을 제거

 개발자가 한 번 자동 테스트의 가치를 실감 한 후에는 실천에 들어가는데 걸림돌이 되는 장애물을 제거하는 것이 중요합니다. 장애를 제거하여 수동 테스트의 단점을 제거 할 수 있습니다. 테스트를 자동화하는 것을 어렵게 하고 있는 원인은 어떤 것이 든, 자동 테스트 구축을 실시하지 않는 이유 중 하나에 지나지 않습니다.

장벽을 제거하기위한 도구는 많이 있습니다.

• 테스트 러너
• 테스트 러너를 사용하면 신속하게 테스트 할 수 있습니다. 개발자가 사용하는 개발 환경과 통합하면 좋을 것입니다. 개발자가 TDD를 실천하고 있다면, 코드를 작성하는 만큼 테스트를 쉽게 하고 싶어할 것 입니다.
• 코드 커버리지 측정
• 코드 검사는 개발자가 응용 프로그램을 얼마나 테스트하고 있는지 알려줍니다. 한층 더 테스트를 추진하기에 훌륭한 도구입니다.
• 지속적인 통합 (CI) 서버
• 개개인이 테스트 케이스를 실행하는 이외에, CI 서버를 사용하여 변경이 발생할 때마다 자동으로 테스트를 실시합니다.
• 테스트 전체를 실시 하는 것을 잊어서는 안됩니다. 안전망을 구축하는 것이 테스트의 가치를 높이는 것입니다. 안전망이 없어서 테스트가 무시 된 환경을 여러 번 본 적이 있습니다. 테스트가 작동 하고 있는지 않는지 조차 인식하지 못하는 경우도 있습니다.
• 테스트가 실패하면 즉시 알려주기 때문에 문제를 빠른 시간 안에 바로 잡을 수 있습니다.
• 개발자가 CI 서버를 신뢰하여 만든 테스트에 더 큰 가치를 인정하게 된다면 그 가치를 만끽 하기 위해 테스트를 빨리 만들고 싶어지게 됩니다.

 이러한 도구의 구입 비용을 가지고 고민하는 기업들을 여럿 보아왔습니다. 아이러니하게도 많은 도구의 비용은 개발자의 몇 시간 분 시급보다 낮을 것입니다. 효율적인 테스트를 실현하는 중요한 역할을 하는 도구의 이점에 대해 논하는 것은 시간 낭비입니다.

 지금 바로 실천을 통해 도구를 사용하여 오류를 제거합시다. 시작이 늦으면 늦을수록 손에 들어오는 가치도 작아 져 버립니다.

여유

 기법을 배우고 실천하는 데 필요한 여유도 테스트에 대한 장애 중 하나 입니다. 개발자가 여가 시간에 테스트를 테마로하고 배워주는 기대해야할까요? 아니면 일 동안 시간을​​ 확보하고, 이러한 학습을​​ 지원하는 편이 좋은 것일까 요.

 나는 오랫동안 다양한 테스트 기법의 학습과 적용에 종사하여 "자동 테스트 도구"어떤 때 유용 어떤 때 쓸모 있는지 본능적으로 알게 되었습니다.

개인에게 여유를 주고, 자동 테스트 기술의 연마를 지원합시다.

• 고 부하 일정을 피합니다. 바쁜 와중에 학습을 동시에 진행 하기는 쉽지 않기 때문입니다.
• 불필요한 작업은 중단합니다. 예를 들어, 수동으로 실시하는 테스트 케이스를 문서화하는 것입니다. 이렇게 하면 자동화 하는 인센티브도 생깁니다.
• 자동 테스트를 낭비라고 느끼는 고객 및 이해 관계자도 있을지도 모릅니다. 미신은 추방합시다. 이런 이야기에 의욕을 잃어서는 안됩니다.
• 무엇이 성공하고 무엇이 실패 했는 지를 자주 되돌아 봅시다. 모두가 배운 것을 공유하고 성과를 서로 치하 할 수 있도록 합시다.

성과에 주목하자

 내가 참가한 가운데 가장 효과적인 테스트가 행해진 프로젝트는 모두가 소프트웨어의 성과에 주목하고 있던 프로젝트였습니다. 어떤 보고서를 작성해야 할지 지시를 받는 것이 아니라 내가 원하는 비즈니스 성과를 이해하고 어떠한 보고서가 필요한 지를 결정하는 데 도움이 될 수 있었습니다.

 시스템의 어느 부분이 가장 비즈니스 성공에 기여하는지 이해하고 있었기 때문에 그 부분에 주력했습니다. 비즈니스의 바람직한 성과를 바탕으로 테스트 우선 순위를 정하고있었습니다. 또한, 성과의 관점에서 테스트를 설계하고 있었으므로, 테스트의 기대 값에 대해 고객이나 사용자에게 직접 설명 할 수있게되어있었습니다.

 이것은 테스트에서 최대한의 가치를 끌어낸 예입니다. 이것을 목표로 해야만 합니다. 비즈니스에 가치를 추가하지 않는 코드와 테스트를 억지로 만들어야 하는 것 처럼 우울한 것도 없습니다.

신뢰

 복통을 일으켰다고 합시다. 병원에 도착했을 때, 당신은 접수 계원에게 증상을 설명합니다. 접수 계원은 맹장 상단의 복부를 절개하는 의사에게 진찰을 요구합니다. 그리고 맹장을 절제하는 것을 전문으로 하는 의사도 부릅니다. 또한 절개 한 복부를 봉합 의사도 부릅니다. 당신은 회복실로 옮겨진 이후 의사로 부터 연락이 끊깁니다. 아직 복통이 있습니다. 다시 진찰 해 보니 하면 통증은 담낭이 원인이었습니다. 맹장은 문제 없었습니다.

 다행히도 우리는 이러한 세계와는 무관합니다. 의사의 업무는 내장을 제거하는 것이 아닙니다. 무엇보다 이렇게 하는 전문 능력은 가지고 있지만. 그들은 진찰 부탁 받아 주의 깊게 분석 한 후 해결책을 처방합니다. 수술의 경우 절개를 하고 배운 것을 바탕으로 진단을 확인합니다. 어떤 경우에도 올바른 길을 확보합니다. 수술 후에도 수술이 완벽하다는 것을 알 때까지 환자를 돌봅니다. 그리하여 안전하다는 확신이 들면 회복실로 보내집니다. 회복시에도 상황을 확인하고 회복을 지원하기 위한 조언을 준비합니다. 의사가 아닌 사람도 환자의 용태를 확인하고 있지만 궁극적으로는 의사가 환자의 회복을 담당합니다.

 만약 의사에게 자신의 생명을 맡길 수 있다면, 마찬가지로 자신이 사용하는 소프트웨어 개발자를 신뢰 하는 것도 가능하지 않을까요?

저자에 관하여

 Wes McClure 씨는 기술과 소프트웨어로 기업이 눈부신 성과를 달성 하는 것에 열정을 가지고 지원하고 있습니다. 소프트웨어 개발의 폭 넓은 경험을 바탕으로 비즈니스 목표에 부합하는 소프트웨어를 개발하는 방법의 개선을 실시하고 있습니다.  Full City Tech를 시작해 전문성을 활용하여 고품질의 소프트웨어를 신속하게 제공하고자하는 기업을 지원하고 있습니다.

일본IBM의 'Bluemix 여자 사람 미팅' 레포트 - 번역기사

Server Side Architecture Group에서 진행하는 Bluemix에 대한 블로그 이벤트로서 IBM Bluemix에 대한것을 구글링 해 보다가 흥미있는 기사가 있기에 소개해 보고자 한다.

시작하기전에 이 글의 일체의 저작권은 원저자인 Impress사에 있음을 밝혀둔다.

일본IBM의 'Bluemix 여자 사람 미팅' 레포트

원제 : クラウドでも女子会？！　日本IBM「Bluemix女子会」レポート


PaaS 서비스 "Bluemix"관련 이벤트 "Bluemix 여성 모임"이 일본 IBM에 의해 7 월 8 일 저녁에 개최되었다.

 IT 계 스터디 그룹에서는 최근 여성이 주최하는 여성 엔지니어를위한 이벤트 이름에 "여성 모임" 라고 붙이는 케이스를 볼 수있게되어 왔으며, 여성 엔지니어가 전문적인 지식을 교환하며 서로 친목을 다지고 있다.

 처음에 일본 IBM의 미야 사카 마유미 씨 (소프트웨어 사업 본부 소프트웨어 파트너 사업부 파트너 솔루션 사업 개발 부장)가 인사말로 "IBM에서 여성 모임 이벤트를 여는 것은 처음"이라고 말했다. 미야 사카 씨는 IBM 본사의 현재의 사장 겸 CEO 인 버지니아 M·로멧티 씨가 여성임을 소개하며 일부 국가에서는 여성이 더 많은 거점도 있고, 다양성을 중시하는 문화라고 참가자들에게 어필했다.

 이벤트에는 31 명이 참가하였고 그 중 60 %가 대학생, 40 %가 사회인이라는 비율이다. 대부분의 참가자가 Bluemix을 처음 접한다고 하며 이번 이벤트는 Bluemix에서 응용 프로그램의 작성과 배포를 체험하는 형식으로 진행되었다.

이벤트 회장으로 사용된 IT계 모임을 위한 이벤트 공간
21cafe(시부야).  은은한 전구 조명이 멋진 느낌 있는 공간이다.

이벤트 시작. 인사말과 Bluemix해설.

 우선 미야사카씨가 Bluemix를 소개 했다. IBM의 IaaS서비스 "SoftLayer"상에서 동작하는 PaaS서비스로 2월에 베타버전이 공개되었고 미국에서 6월30일 정식버전의 서비스가 출시되었다. 또한, 당초에는 BlueMix라고 표기되었지만 정식버전에서는 Bluemix(M이 소문자로)로 표기가 변경되었다.

 Bluemix는 VMware가 개발한 오픈소스 PaaS구축 플랫폼 Cloud Foundry를 베이스로 하고있다. 따라서 응용 프로그램이 특정 플랫폼에 종속되지 않고 Cloud Foundry 기반 PaaS라면 어디든 이식이 가능하다.

 Bluemix의 특징은 Clud Foundry위에서 당양한 구성 요소가 되는 서비스를 제공하고, 그것들의 전형적인 Web 시스템의 패턴을 정의하여 템플릿으로 제공하고 있는 점이다. 다양한 어플리케이션이 자동으로 설치되어 사용자측은 간편하게 사용할 수 있다고 미야사카씨는 어필한다. 얼마전 퀴즈프로그램에서 우승해 화제를 모았던 인공지능 Watson도 API에서 사용할 수 있다. 또한 서비스 마켓 플레이스도 있으므로 모두에게 즐거운 비즈니스가 되었으면 좋겠습니다 라고 말했다.

 실습은 IBM연구소의 타카하시씨의 사회로 진행되었다. 참가자는 사전에 Bluemix계정과 절차를 설명하는 자료가 배포되었고 각자 소지한 노트북 PC를 이용해 실습하며 필요한 경우 직원이 서포트 하는 형식으로 진행하였다.

 첫번째 세션은 Bluemix서버 환경을 구축하는것으로 시작했다. Bluemix의 Web화면에서 Node.js를 선택하여 응용 프로그램 템플릿을 선택하면, 기반이되는 응용  프로그램이 만들어진다. 또한 데이터베이스 템플릿을 선택하고 응용프로그램을 지정하기만 하면 응용 프로그램과 데이터 베이스가 연결되는 곳을 실습했다.

 두번째 세션은 통합 개발 환경 Eclipse에 Bluemix 플러그인을 추가하여 공개 된 샘플 응용프로그램을 Bluemix에 배포하는것 이었는데, 일부 참가자들은 이클립스 환경구축에 애를 먹기도 하였다.

 세번째 세션은 Bluemix의 Web화면의 GUI조작으로 Web어플리케이션이나 모바일 웹을 개발하는 도구 "RapidApps"를 이용하여 준비된 표 데이터를 RapidApps로 가져와서 데이터 간이나 데이터와 화면 요소 사이의 연관을 GUI에서 설정하여 모바일 Web응용 프로그램을 개발하고 RapidApps 모바일 브라우저 시뮬레이터로 동작을 확인하였다.

실습중인 모습

실습 내용에 대한 설명

자료를 보면서 실제로 자신의 Bluemix환경을 조작

IBM직원 도우미 (누구냐 넌?)

체엄이 끝난 후에는 도넛을 먹으면서 일본 IBM 토쿄 기초연구소의 에노키 미키씨에 의해 "연구소와 클라우드와 나"라는 타이틀로 발표가 이어졌다. 에노키씨는 일본 IBM에 근무하면서 오차노미즈 여자대학의 박사과정에 재학중이라고 한다. 자신의 연구 내용이나 세계의 IBM기초 연구소 및 연구를 소개하고, IBM의 클라우드 비젼 "Cloud V3.0"을 설명했다.

또한 이번 행사에는 오차노미즈 여자대학 정보 과학과 교수 이토 타카유키씨가 협력했다. 이토씨는 일본 IBM출신으로 학생들에게 실습의 장으로서 자교 학생 참가자를 모집했다고 한다.

한입만 깨물어도 다이어트따윈 개나줘버려를 외치게 된다는 악마의 도너츠가 제공되고...

간식과 함께 발표를 듣는 참가자들

 여자들만 모아서 진행하는 이벤트가 무슨 의미가 있겠냐고 물을지도 모르지만 프로그래머의 세계에서는 여성 엔지니어가 그 수에 있어서 절대적으로 적다. 이에따라 여성 엔지니어분들도  남성 엔지니어들과 마찬가지로 신기술에 대한 관심도 있고 배워보고자 하는 의욕도 강하지만 현실적으로는 남자들만 득실거리는 스터디나 세미나에 나가기가 꺼려진다는 의견이 상당히 많은것도 사실이다.

 일본의 경우 외국계 기업을 중심으로 꾸준히 여성 IT엔지니어 인력을 적극적으로 활용하려는 움직임이 퍼지고 있으며, 그 결과 근무중에 다도를 즐길 수 있게 한다던지 여성 엔지니어만의 모임을 활성화 시키는등 다양한 형태의 시도가 진행되고 있다. 하지만 무엇보다 여성 인력이 IT업계에서 안정적으로 오래 일 할 수 있게 하려면 승진/급여에 대한 차별이나 출산/육아에 대한 부담을 줄여야 한다는 과제가 반드시 해결 되어야한다. 기업과 사회 전체의 더 많은 투자가 필요한 까닭이다.

 한국 IBM이나 다른 기업에서도 여성 엔지니어들을 적극적으로 포용하는 이러한 세미나를 개최해 보는것은 어떨까?

TDD는 벌거벗은 임금님의 투명옷인가? (3) - TDD는 UT가 아니다.

TDD는 벌거벗은 임금님의 투명옷인가?

• 1. TDD는 죽었다. 테스트여 영원하라!
• 2. TDD의 사망에 대한 검증
• 3. TDD는 UT가 아니다

 각종 커뮤니티에서 난리가 나고 업계의 거두가 모여서 현피맞장까지 뜬 TDD를 둘러싼 일련의 소동에 대한 핵심은 다음의 한문장으로 요약될 수 있을것이다.

테스트를 먼저 작성하고 코드를 적는것이 정말로 개발에 그만큼의 가치를 가져다 주는가? 

 그리고 당연하게도 이 물음이 TDD. 즉 테스트 퍼스트 개발을 둘러싼 논쟁의 핵심이 되었어야만 했다.

 TDD의 창시자는 누구이던가? 오늘날의 개발자에게 있어서 십계명이나 다름없는 그 유명한 애자일 선언에 참여한 맴버중에서도 맨 첫머리에 이름을 올린 Kent Beck선생이 아니시던가! 하지만 이러한 '이름의 권위' 앞에서 TDD는 자동화 테스트와 동일시 되어 버려 그 가치를 올바로 평가받을 기회를 잃어버렸던게 아닐까?

 하지만 TDD에만 포커싱을 했으면 좋았을 DHH의 지적질에 애먼 유닛 테스트(이하 UT)가 포함되는 순간, 토론의 목적지는 저 멀리 안드로메다로 재 설정 되어 버리고 만다. Mock오브젝트에만 의존하는 생각없는mindless UT에 대한 반감은 TDD옹호론자라고 해도 공감하는 부분이지만, 엄연히 TDD와 UT에 대한 논쟁은 구분되어 이루어져야 만했었다.

 결론적으로 Martin Flower가 주최한 6회에 걸친 토론중에서 순수하게 TDD자체의 유용성에 대한 토론은 얼마 되지 않았으며, UT에 대한 유용성은 지금와서 이야기 하는것 자체가 무의미할 정도로 업계 전반에서 이미 상식으로 받아들여지고 있는 상황 이므로 아무런 의미가 없었다.

 나름 업계의 존경을 받는 머리 좋은 양반들이 그 귀중한 시간을 내어서 공개적으로 진행한 이벤트 치고는 참으로 어처구니 없는 전개가 아닌가? (그런데 토론을 자세히 보면 능구렁이 같은 Kent Beck이 덩치에 어울리지 않는 애교를 섞어가며 TDD에 대한 논점을 교묘히 흐리는 장면을 자주 볼 수 있다.)

 다시 TDD의 이야기로 돌아와 보자. 

 UT와 뒤섞여 버린 진흙탕 싸움에서 TDD에 관련된 쟁점을만을 분리해 보면 다음의 세가지로 요약된다.

1. TDD는 오버헤드가 너무 크다  TDD는 커버리지를 중시하지는 않는다고 하면서도 모든 코드에 대한 테스트코드의 작성을 의무화 함으로서 이에 위배되는 모습을 보인다. 결국 개발자는 쓸데 없는 UT작성에 많은 시간을 빼앗길 수 밖에 없다. 하지만, 어느정도 비용이 소요된다 하더라더 테스트 코드가 없는 코드 보다야 훨씬 나을수도 있지 않을까?
2. TDD가 설계를 망친다  테스트를 먼저 작성해야만 본 코드를 작성하도록 강제하는 룰은 시간에 쫒기는 개발자에게 유닛 테스트를 작성하기 쉬운 설계를 은연중에 강요하게 된다. 이는 결국 유닛테스트를 작성하기 어려운 시스템 횡단적인 기능을 기피하게 만들고 시스템의 설계를 기형적인 모습으로 만들것이다.  
3. TDD가 테스트를 망친다  1,2와 관련하여 결국 UT만이 너무 강조되는 상황에서는 mock에 의존한 하나마나한 형식적인 테스트로 흐르기 쉬우므로 우리는 이 점을 경계해야만 한다. 또한 UT만큼이나 시스템테스트, 시나리오 테스트도 자동화에 힘을 기울일 수 있어야 할 것이다. 

Tip 요즘 많은 프로젝트들에서 빠르게 실행되는 UT와 시간이 걸리는 DB를 사용하는 결합테스트, 또는 시스템 테스트를 분리해서 구성하고 있다. UT는 커밋시에 개발자 스스로 체크하도록 하고 시간이 걸리는 DB나 그 밖의 미들웨어를 사용하는 테스트는 UT와 함께 젠킨스 등의 CI툴을 이용해 코드 변경시에 실행되도록 해 놓으면 개발자의 시간을 절약하는데 많은 도움이 될 것이다. 아울러 특정 DB에 종속되지 않는 퍼시스턴스라면 UT에도 인메모리 DB를 사용해 테스트 속도를 고속화 할 수 있다.

 TDD가 유용한지 아닌지는 현재 작성하는 프로그램의 성격과 내용, 그리고 작업자의 숙련도에 따라 달라지겠지만 어느정도 오버헤드를 감수해야 함에는 틀림없는 사실이다.

 그리고 여기서 한가지 간과하지 말아야 할 사실은 TDD의 태생이다. TDD는 초기 에자일 프로세스중 하나인 eXtreme Programming과 함께 2000년대 초반에 등장하였는데, 당시엔 오늘과 같이 xUnit테스트가 일반적이지 않았고 대부분의 테스트가 수작업에 의존하던것이 당연하던 시절이다. 이러한 당시 상황속에 UT의 작성을 의무화 하기 위한 하나의 충격요법으로서 XP와 함께 탄생한 TDD를 오늘날에 와서까지 굳이 이를 따라야 할 필요가 있을까?

 필자는 UT가 실행코드와 함께 필수로 받아들여지고 있는 현 시점에서 TDD가 더이상 큰 역할을 하기 어렵다는 DHH의 주장에 동감한다. 이상적인 자동화 테스트 코드는 맹복적인 코드 커버리지보다는 프로그램이 어떻게 움직여야 할지를 기술하는 문서화의 한 형태여야만 하기 때문이다. 반대로 자동화 테스트가 프로그램의 동작을 충분히 설명해 주지 못하고 있다면 추가나 보완이 필요하다고 봐야 한다.

 TDD의 채택여부는 프로젝트의 내용이나 구성원의 취향에 따라 충분히 어느쪽도 선택 가능할 것이다. 하지만, 어떠한 경우라도 자동화 테스트가 없는 개발만큼은 피해야 한다. 이것이야 말로 현대 소프트웨어 개발에 있어서 의심할 여지가 없는 진리이다.

똑똑한 프로그래머를 멍청이로 만드는 방법

知之者는 不如好之者요, 好之者는 不如樂之者니라. 
지지자는 불여호지자요, 호지자는 불여락지자니라.
알기만 하는 사람은 좋아하는 사람만 못하고,좋아하는 사람은 즐기는 사람보다 못하다.
천재는 노력하는사람을 이길수없고, 노력하는사람은 즐기는자를 이길수없다.
- <논어(論語)> 옹야편(雍也篇) -

한국사회의 오래된 논의중 한가지는 인재가 우수하기로는 둘째가라면 서러운 대한민국에서 왜 과학기술 분야의 노벨상 수상자가 나오지 않는가 이다. 이 논의에서 주범으로 지목되는것은 입시 위주의 교육인데, 어려서 부터 부모의 기대에 부응하기 위한 수단으로서 의 공부는 결국 좋은 성적을 거둬 좋은 대학, 좋은 직장에 취직하는것을 이루기 위한 수단일 뿐 목적이 될 수 없다. 하지만 인류의 지성이 아직 발견하지 못한 새로운 과학적 사실을 발견하기 위해서는 단순히 '열심히'만으로는 부족하다. 온 정신을 내 던지는 몰입이 이뤄질 수 없기 때문이다. 몰입적 사고를 주장하는 황농문 교수의 책 '몰입'에서도 비슷한 이야기가 나온다. '몰입'에서는 인생의 나머지 모든것들이 시시하게 느껴질 정도의 순수한 지적 활동이 가져오는 쾌락에 대해서 상세히 언급되고 있으며, 순수한 '앎'에 대한 열정만이 자신의 한계를 넘어서 새로운 발견을 이끌어내는 원동력이 될 수 있다고 서술하고 있다. 즉, 한계를 넘어서는 무엇인가를 하게 만드는것은 그 행위 자체가 가져오는 기쁨을 포함하지 않으면 안된다. 마치 즐기는 자를 노력하는자가 이길 수 없다고 하는 말 처럼 말이다.

뉴턴과 아인슈타인의 공통점은 ‘몰입’

이제 프로그래머에 대한 이야기를 해 보자. IT서비스를 포함한 성공한 프로그램은 예외없이 한가지 공통점을 가진다. 품질이 좋다. 단순히 기발한 아이디어를 구현했다던지, 독자적인 무엇인가를 가지고 있다는 레벨이 아니다. 요즘같이 아이디어가 오픈되어 있는 시대에서는 기능면,성능,편의성,안정성. 어느것 하나 뚜렷한 약점이 존재해서는 성공하기 힘들다. 만약 어느 한 영역에 뚜렷한 약점이 있다면 반짝 히트는 가능할 지라도 롱런하기 힘든 제품이 될 것이다. 그만큼 소비자의 기준은 엄격하고 취향은 까다롭다. 이러한 높은 품질의 프로그램을 만들어 내기 위해서는 노력만으로는 감당이 안된다. 발상의 전환과 같은 창의적인 문제 해결 능력이 필요 하다. 노벨상에 비할바는 아니지만 좋은 소프트웨어를 만들어 내는 작업은 단순히 시키는 것을 열심히 하는것 만으로는 부족 하다는 것은 자명하다. 끊임없이 스스로 배우고 생각하고 적용해 나가는 선순환의 루틴을 만들어 낼 수 있어야만 하는 이유다.

즉, 개발자의 무한 희생이 아니라 '개발'자체가 개발자에게 기쁨과 즐거움이 될 수 있어야 한다.

이는 비단 일반 유저를 대상으로 하는 B2C에만 해당되는것은 아니다. 사내 업무 시스템과 같은 B2B프로젝트 또한 엄연히 요구사항이 정의되어 있기는 하지만 모든 사항을 사전에 파악하고 문서로 정의할 수는 없을 것이다. 그 보다는 시스템을 만들어가는 개발자가 사용자의 입장에서 시스템을 바라 보고 보다 나은 시스템을 만들려는 노력을 멈추지 않는 자세가 필요하다. 그리고 모두가 잊고 있었던 당연한 이 사실을 다시한번 일깨워 준 것이 바로 애자일 선언이다.

오늘은 개발자의 동기부여라는 주제로 이야기를 해 보고자 한다.

양초의 법칙 : 프로그래머를 지적 노동자로 만들것인가 단순 노동자로 만들 것인가?

인센티브는 동기 부여에 도움이 될까?
결론부터 말하자면 일의 성격에 따라 도움이 될 수도, 그 반대가 될 수도 있다.

Candle problem
현대 심리학계에 지대한 공을 세운 인물중 한명인 Karl Duncker는 1945년 실시한 실험을 통해 선입견에 대한 연구를 진행하였다.

Duncker는 피험자들에게 테이블 위에 압정이 가득 든 상자와 양초, 그리고 성냥을 주고는 "테이블에 촛농이 떨어지지 않게 양초를 벽에 고정시키시오"라는 과제를 제시하였다.

이 문제에 대한 해법은 상자안의 압정을 모두 쏟아내고 압정 한개만을 이용해 상자를 벽에 고정시키고 양초에 불을 붇이는 것 이었다.

Duncker는 피험자를 두 그룹으로 나누고 상자안에 압정이 있는 경우와 상자 밖에 압정을 모두 쏟아낸 두가지 상황의 제시를 통해 "상자"가 가지는 선입견이 문제 해결에 미치는 영향을 입증해 내었다.

상자를 단순히 압정을 담는 도구로만 인식할 경우 이 문제는 풀 수 없으나 발상을 전환이 가능할 경우에만 문제를 풀 수 있게 된 것이다.

그로부터 17년후, 뉴욕대학의 대학원생이었던 Glucksberg는 이 실험을 응용하여 포상과 문제해결 사이의 상관관계를 찾아내었다. 그는 피험자를  A, B 두 그룹으로 나누고 A그룹에는 그냥 문제를 풀고 시간을 알려 달라고만 했고 B그룹에는 문제를 푼 사람에게 5달러를, 가장 빨리 문제를 푼 사람에게 20달러를 지급한다 설명했다.

한쪽은 무상으로 문제를 풀도록 하고 다른 한쪽은 인센티브를 제시한 것이다.

결과는 A그룹이 평균 7분, B그룹이 평균 10.5분이 걸렸다. 상금이 걸린쪽이 무려 35%나 낮은 성과를 낸 것이다.

이 결과는 다음과 같이 설명되었다. "난이도가 높은 문제의 경우 해결에는 시행 착오와 발상의 전환이 필요하다. 그러나, 보상이나 벌칙에 압받을 받게되면 인간은 사고의 유연성을 잃어버리고 하나의 생각에 집착하는 경향을 보인다. 결과적으로, 창의력을 요하는 문제의 경우 부담없이 임하는 것이 오히려 빨리 답에 도달하게 된다."

이 실험의 또 다른 버전이 있다.
스텐포드 대학의 Michael C. Frank과 Michael Ramscar는 Glucksberg의 실험과 거의 동일한 실험을 진행하였다. 이들이 진행한 실험에서는 압정을 상자안에서 모두 꺼내어 상자에 대한 선입견을 제거했다. 즉, 문제에 대한 난이도를 낮춘것이다. 그 결과는 인센티브를 제시한 그룹이 25%에서 50% 빨리 문제를 해결하는 성과를 내었다. 창의력이 배재된 단순 작업의 경우, 인센티브가 효율적으로 작동한다는 우리가 익히 알고 있는 비즈니스 세계의 룰의 효용성이 증명된 것이다.

성과에 대한 집착은 오히려 일을 더디게 만들고, 일에 대한 스트레스를 가중시킨다.

자 이제 다시 프로그램의 세계로 돌아오자.
인센티브를 통해 프로그래머에게서 높은 성과를 뽑아내려 한다면 어떤 결과가 올까? 
스스로 "생각"을 하기 보다는 눈에 보이는 결과를 낼 수 있는 "행동"에 집착할 것이다. 눈에 보이는 부분에 대해서 열심히는 하겠지만 창의적인 업무 처리와는 점차 거리가 멀어지게 된다. 더욱 나쁜것은, 상사나 외부로부터 "평가"되지 않는 행동들에 대해서는 더이상 신경쓰지 않게 된다는 점 이다. 

공부 못하는 아이를 반장으로 임명하는 것 과 같이, 우등생으로 대접하면 성적이 오른다는 교육이론이 있다. 이 이론을 위의 문제 난이도와 인센티브간의 상관관계에 접목시키면 창의력을 요하는 프로그래머 를 인센티브로 길들이는 것 과 같이 단순 노동자 취급을 하면 정말로 단순 노동자가 되어버린다는 사실이다. 그리고 스스로 생각하는것을 그만 둔 프로그래머는 당연히 생산성이 낮아진다. 낮아진 생산성은 낮은 평가와 낮은 급여 그리고 이직으로 이어지며 이렇게 떠나간 사람이 회사에 대해서 좋은 감정을 가지고 있을리 없다. 회사에 대한 나쁜 소문이 퍼지기 시작하고 좋은 인재가 기피하는 회사가 된다. 악순환의 완성이다.

창의적인 업무처리와 생산성은 어떠한 상관관계를 가질까? 예를 들어 수십개의 테이블에 대한 단순 입출력과 검색을 구현하는 화면을 작성하는 작업이 있다고 해 보자. 성실히 구현해 나간다면 당초 예상보다 일정을 앞당길 수도 있을것이다. 품질개선에도 신경을 쓴다면 좋은 품질을 유지 할 수도 있을것이다. 하지만 Rails와 같은 프레임워크를 생각해 낸다면 이러한 노력의 절약과 품질의 향상에 극적인 변화를 기대 할 수 있을것이다. 이러한 발상의 전환은 어느정도 재능은 필요하겠지만 천재성을 필요로 하진 않는다. 오픈소스 시대에서 모든 지식이 공개되어 있기 때문이다. 따라서 사고의 전환을 할 수 있을 만한 여유와 스스로 계획할 수 있는 권한, 그리고 실패에 대한 관용의 문화가 있다면 개발자들은 얼마든지 창의적으로 일 해 나갈 수 있다.

비단 프로그래머가 아니어도 경영학적 관점에서 차등 보상에 기반한 성과주의가 실패하는 것은 논리적으로 증명된 사실이다.

다음은 '착각하는 CEO(유정식 저,2013)'에 소개된 내용이다.

차등 보상이 실패하는 논리적 이유

경영 컨설턴트이자 심리학 박사인 폴 마르시아노는 차등보상프로그램이 직원들의 동기를 전반적으로 떨어뜨린다는 점을 논리적으로 증명해 보였다. 차등 보상이 실행되었을 경우, 직원을 성과 평가 결과에 따라 우수성과자, 저성과자, 중간성과자로 구분해서 각각의 경우에 어떠한 영향을 미치는지 살펴보자. 

우수성과자의 경우

우수성과자는 이미 98점을 획득한 학생에 비유 할 수 있다. 즉, 성과를 더 높일만한 여지가 없다. 따라서 차등 보상은 우수성과자의 성과를 더 높이지 못한다. 

저성과자의 경우

영향을 미치지 않거나 부정적인 영향을 미친다.우수성과만 인정받는 상황에서 저성과자는 차등 보상 프로그램에서 소외된다. 이들 입장에서 차등보상 프로그램은 그들만의 리그로 인식되며 자신이 얼마나 인정받지 못하는지, 또 얼마나 상대적 박탈감을 느끼고 있는지 확인시켜 줄 뿐이므로 결과적으로 이들의 동기는 더 떨어진다. 따라서 차등보상은 저성과자의 성과를 끌어올리지 못한다. 

중간성과자의 경우 

부정적인 영향을 미친다. 평가가 진행되는 동안에는 중간성과자 중 많은 이들이 '당근'을 받기 위해 자발적으로 노력한다. 하지만 위에서 살펴봤듯이 당근의 대부분은 우수성과자에게 돌아가므로, 심리학적으로 당근을 못 받은 중간성과자는 '외 받지도 못할 당근을 위해 애써야 하지?'라고 생각하며 태도를 바꾼다. 자발적으로 노력하려 하지 않고 차등 보상 프로그램 실시 전에 비해 동기가 더 떨어지는 것이다. 따라서 차등 보상은 중간성과자의 성과를 높이지 못한다.

필자의 경우 성과주의도입을 직접 주도해 본 경험이 있다. 처음엔 대부분의 직원들은 성과주의 도입에 찬성했다. 자신이 주변 동료들보다 낮은 평가를 받을리 없다고 생각했기 때문이다. 평가가 끝난후엔 어떻게 되었을까? 낮은 평가를 받은 사람은 평가를 올리기 위해 노력했을까? 아니다. 그들의 노력은 관리자의 무능력을 공격하고 고성과자의 성과를 깎아 내리기 위해 사용되었다. 모든것이 폴 마르시아의 증명대로였다.

그렇다면 어떻게 해야 프로그래머에게 동기부여를 할 수 있을까?

필자가 생각하는 가장 좋은 방법은 동기부여가 이미 되어 있는 사람을 채용하는 것 이다. 호기심이 많고 배움에 대한 열정이 가득한 사람이라면 지금 가진 업무에 대한 지식이 약간 부족하다 할 지라도 크게 문제가 되진 않는다. 일 자체를 즐길 수 있기 때문이다. 어차피 빠르게 변화해 가는 기술 트렌드 속에서 지금 얼마나 알고 있는가는 그다지 중요하지 않다. 이러한 사람의 경우 나이가 많고 적음을 떠나 남과 구별되는 무언가를 이뤄낸 경우가 많다. 면접관은 이러한 부분에 대해 주의 깊게 관찰하고 질문하여 판단하여야 한다. 필자의 경험상으로는 탑코더식의 코딩시험도 많은 도움이 된다.

내가 프로젝트의 주인이다

능동적인 일의  진행은 프로그래머 뿐만 아니라 프로젝트 구성원에게 큰 동기 부여가 된다. 팀 안에서 자율적으로 결정하고 결정된 사항에 대해서 책임을 지는것. 이것은 많은 전 현직 구글 직원들이 꼽는 구글의 성공비결중 하나이기도 하다. 고객이 제시한 가이드라인을 따라야 하는 SI프로젝트라해도 일 자체의 진행에는 많은 융통성이 존재한다. 팀원들에게 최대한의 자율권과 그에 따르는 책임을 부여하라. 상명하복에 길들여져있는 조직이라면 이것은 말처럼 쉽지 않다. 전술한 내용을 도입하려는 리더라면 자율성의 도입에 많은 고민과 노력을 기울여야만 할 것이다. 비슷한 경험을 가진 사람의 조언을 받거나 조직 문화 개선에 대한 책을 읽는것도 좋지만, 제일 중요한 것은 사람들의 의견을 듣고 대화해 나감으로서 공감대를 형성하는 것 이다.

능동적 개발을 가능하게 해 주는 티켓주도 개발 

SI에서 적용 할 수 있는 능동적인 프로젝트 진행의 팁을 한가지 소개하겠다. 아마 대부분의 SI현장에서 비교적 도입이 쉬우면서도 효과적이리라 생각한다. 바로 Redmine이나 Trac과 같은 이슈 트레커를 이용한 티켓주도 개발(TiDD)의 도입이다.

티켓주도 개발

원리는 간단하다. 폭포수형 개발의 경우라면 WBS에 의해 테스크가 분할될 것이며, 반복형 개발이라면 이터레이션 별로 구현해야 할 유저 시나리오나 성과물이 존재할 것이다.
초기에는 관리자가 필수 작업으로서의 티켓을 주로 등록하게 되지만 티켓주도 개발이 제대로 정착하게 된다면 마일스톤에 직접적으로 관련이 있는 작업들만 관리자가 등록을 하고, 이하 세부적인 티켓들은 프로젝트 구성원들이 능동적으로 등록할 수 있게 된다. 구성원들은 자신의 업무를 등록된 티켓 안에서라는 제한적 범위이긴 하지만 스스로 정할 수 있게 되고 일정 또한 스스로 산출한다. 리팩토링이나 모델링의 수정, 테스트 케이스의 추가와 같은 기술적 채무에 대한 사항들도 일정상의 여유가 없다면 미리 등록만 해 놓고 여유가 생겼을 때 작업 할 수 있게 된다. 관리자 입장에서도 이슈트레커의 기능을 이용해 작업의 배치상태와 진척사항등을 빠르게 체크할 수 있고, 이에 대한 보고서 작성시간 또한 크게 단축 할 수 있다.

티켓 주도 개발은 비록 제한적이기는 하나 개발자들이 주어진 환경 속 에서 최대한 자율적으로 일 할 수 있게 도와 준다.

필자는 대부분의 프로그래머들은 배움에 대한 열망이 높고 스스로의 일에 대해 강한 책임감과 자부심을 가지고 있다고 생각한다. 경영진이나 관리자는 이들이 가진 이러한 열망을 정확하게 이해하고 해소해 줌으로서 성과급을 지불하는것 보다 훨씬 많은것을 얻을 수 있을것 이다. 

다시한번 말하지만 당근과 채찍으로 개발자를 다루려 하지 마라. 어떻게 하면 일 자체가 당근이 될 수 있을까를 고민하라. 즐겁고 쾌적하게 일할 수 있는 환경을 제공하라. 빠른 작업용PC와 맘에 드는IDE로 작업 할 수 있게 허락하라. 개발자의 개성과 선택을 존중하라. 관리자는 이에 대해 책임이 따른다는 점을 주지시키기만 하면 된다. 특히나 요즘 들어 개발자들을 가장 많이 괴롭히는 보안관련 사항에 있어서도 같은 해법이 적용 가능할 것이다. 

급여향상은 생산성 향상의 열쇠

성과급 제도와는 별도로 급여는 다른 의미에서 매우 중요한데, 바로 생산성에 직접적으로 연관이 있기 때문이다. 2011년 LGCNS의 연구원인 이강배씨가 발표한 논문 "IT 노동과 자본의 총 산출에 대한 직,간접 효과"에 의하면 IT노동자에게 지급하는 임금은 매출 증가에 직접적으로 영향을 미치며, 구체적으로 IT노동자에게 임금 1억원을 추가지급할 경우 5.55배 이상의 부가가치가 새롭게 창출된다고 한다. 이는 비IT 노동자 급여 대비 7.5배 높은 수치로 게임이나 인터넷 서비스와 같은 비제조IT산업의 경우는 1억원에 대한 추가 부가가치가 무려 8.45배에 달하는 것으로 나타났다. 생산성과 부가가치 창출이 전적으로 인적자원의 운영에 달려있는 SW산업에 있어서 이러한 결과는 어떻게 보면 당연하다고 도 할 수 있다. 게다가 좋은 대우를 해 주면 회사의 평판이 저절로 올라가고, 이는 다시 좋은 인재의 채용으로 이어진다. 이것이 바로 인재 채용에 있어서의 선순환이며 IT기업 생산성 향상의 핵심 열쇠이다.

빠른 개발이 가져다주는 선순환에 대하여 by Randy Shoup

결론

자 이제 타이틀에 대한 답을 제시하는 것으로 이 글을 마무리 짓고자 한다.

똑똑한 프로그래머를 멍청이로 만들고 싶은가?
그럼 멍청이로 대접하라. 
아마도 회사를 그만두던지 아니면 멍청이가 될 것이다.

선순환과 악순환의 시작은 개발 작업에 대한 관점의 차이에서 시작한다.
개발을 창조적인 작업으로 볼 것인가 아니면 단순 노동으로 볼 것인가?
당신의 선택에 달려있다.

참고자료

착각하는 CEO (유정식 저, 2013)

Dan Pink: The puzzle of motivation
Candle Problem
마음대로 해봐. 대신 책임져
'IT 엑소더스' 청년이 사라진 SW 업계