7장. 애자일팀의 탄생#6

#7-6페어 기획, 페어 디자인, 페어 프로그래밍

#7-6 페어 기획, 페어 디자인, 페어 프로그래밍 

P사와의 2주간 디자인 단계를 진행하고, 개발자들이 투입된다. 그리고 본격적으로 개발자들이 함께 엮여 기획, 디자인, 개발이 어떻게 이루어지는지를 이번 글을 통해 볼 수 있다. XP, 스크럼, 디자인 싱킹, 린스타트업 등을 섞어서 활용하여 크로스펑셔널 애자일 팀이 어떻게 일하는지 알아보자. 

3주 차 (15년 7월 27일) 개발자 인셉션   

수행: 기존에 있는 기획자 2명, 디자이너 2명에 개발자 4명이 추가되어 전체 팀원이 8명이 되었다. 이 8명이 함께 개발자 인셉션을 수행했다. 개발자 인셉션은 개발자들에게 현재까지 진행된 내용을 공유하고 개발에 바로 착수할 수 있도록 도와주는 절차이다. 먼저 투입되어 2주간 프로젝트를 준비해온 기획자와 디자이너는 그동안 준비해 온 것들을 새로 투입된 인력들과 공유했다. 우리가 개발할 전체 제품에 대한 개괄적인 설명과 더불어 제품의 디자인에 대해 설명했다.  그리고 프로젝트의 목적에 대해 설명했다. 설명은 주로 기획자가 진행했다. 사용자에 대해서 설명할 때는 디자이너가 나섰다. 사용자들이 어떠한 특성을 가지고 있고, 그들이 주로 수행하는 액티비티와 시나리오에 대해 설명했다. 그리고 기획자와 디자이너가 첫 번째 해피 패스를 실제 상황이라고 가정하고 새로 투입된 개발자들 앞에서 역할을 나누어 연기를 했다. 그리고 사용자 스토리의 업무량을 개발자들과 함께 추정했다. 스토리의 업무량은 기획자와 디자이너의 설명을 듣고 개발자들이 추정했는데, 상/중/하를 각각 3점, 2점, 1점으로 추정하고 3점보다 높은 스토리에 대해서는 스토리를 쪼갰다.  

개발자: 페어 프로그래밍 방식으로 환경을 꾸미기 시작했다. 트래비스로 지속적인 통합 환경을 꾸미고, 로보레트릭(Robolectric) 테스트 라이브러리로 테스트 코드를 짤 수 있는 환경을 만들었다. Hello World 해당 뷰가 잘 뜨는지 확인했다. 코드 커밋 시마다 테스트 케이스를 돌리도록 설정했다. 작성된 사용자 스토리를 살피다가 실제 사용자 스토리에 있는 내용은 회색인데 디자이너가 준 이미지 파일이 검은색인 것을 확인했다. 예전 같으면 디자이너에게 색깔을 달리 해달라고 했을 테지만, 기획자에게 앉은자리에서 회색이 맞다는 것을 확인한 후 개발자들끼리 바로 회색으로 바꾸어 작업하자고 결정하여 수정했다. 개발자 인셉션이 8시간을 채우지 못하고 7시간 20분 정도 걸렸다. 근무시간 중 40분 정도의 남은 시간이 있었는데, 거의 퇴근시간이 다가와 업무가 마무리될 줄 알았는데, 이들은 40시간 동안 열심히 일하는 것을 주장했다. 바로 개발을 시작했다. 힘든 하루였다. 

[개발자 인셉션]

3주 차 (15년 7월 28일) 필드 리서치, 페어로 개발환경 구성    

기획자/디자이너: 디자이너와 필드 리서치를 함께 진행했다. 두 사용자를 만나 업무 수행 프로세스를 관찰하고 인터뷰를 수행했다     

개발자: 페어 프로그래밍은 우리가 알던 것과 다르게 수행했다. 익스트림 프로그래밍에서 말하는 드라이버와 네비게이터로 나누는 것이 아닌 누구나 언제든 코드를 짤 수 있고 페어가 코딩을 하는 중에도 내가 이건 짜 보겠다고 이야기하고 치고 들어갈 수가 있다. 꼭 시간을 정해서 순서를 바꾸는 게 아니다. 테스트 주도 개발에 아직 익숙하지 않아 주로 P사 개발자들이 수행하는 것을 보고 있다. 트래비스를 버리고 젠킨스로 CI를 변경했다. 모두 새로운 지속적인 통합 툴을 좀 써보자고 해서 트래비스를 써봤던 건데, 세팅에 문제가 발생했다. 실리콘 밸리 개발자가 구글링 하며 삽질하는 것을 보니 역시 이런 건 만국 공통인 것 같다. 결국 젠킨스로 다시 세팅했다. 하루 종일 페어 프로그래밍을 해본 것은 이번이 처음이다. 너무 지치고 힘들다. 이렇게 집중력을 가지고 8시간 내내 일해본 게 마지막으로 언제인지 궁금할 정도다. 시차 적응도 힘들었지만 열심히 적응 중이다.     

3주 차 (15년 7월 29일) 서버 세팅   

기획자: 업무 관련 매뉴얼을 공부하며 해피 패스 다음에 집중해야 할 업무의 프로세스를 익혔다. 개발자들이 구현한 내용을 스토리에서 확인하고 인수 테스트를 했다. 의존관계가 있는 시스템에 대한 적용 방법을 고민했다.     

디자이너: 또 다른 사용자를 만나 업데이트한 디자인에 대한 인터뷰를 수행했다.     

개발자: 루비 온 레일즈로 서버를 세팅했다. 가장 빠르게 서버를 구성할 방법을 찾다가 루비를 쓰게 됐다. 개발 환경 관련된 일에 이틀 정도를 소모했다. 하지만 한국에서 했던 것에 비하면 정말 빠르게 개발환경을 꾸밀 수 있다. 개발자로서 코드를 거의 쓰지 못하고 있다. 세팅 부분에 P사 인력들이 주로 리딩을 한다. 답답하다. 내가 더 많이 코드를 쓰고 싶다. 일하다가 잠시, 이 세팅 부분은 개발이 아니잖아 라는 생각을 잠시 하고 이내 뉘우쳤다. 개발은 주어진 환경에서만 하는 게 아니다. 이 환경을 만들 수 있는 것도 개발이다. 지속적인 통합, 지속적인 딜리버리 환경을 나도 만들 줄 알아야 한다. 코드는 코멘트가 없이 바로 읽어서 이해할 수 있을 만큼 명확히 짜야한다. 페어 개발자가 내가 이해하지 못한 부분이 있으면 잘 설명해준다. 뭔가 해보고 싶다고 하면 해보라고 한다. 뭔가 탐탁지 않은 것 같기는 한데 못하게 하진 않는다. 우리 회사에서도 선배-후배 페어로 이런 게 가능할까? 이 사람들도 자기들끼리 페어 할 땐 뭔가 다르지 않을까? 궁금증이 많이 남는다.   

[스탠드업]

3주 차 (15년 7월 30일) 페어 프로그래밍   

기획자: 업무 문서, 매뉴얼들을 보고 분석을 계속 수행했다.     

디자이너: 해피 패스에서 조금씩 대안 흐름과 예외 흐름을 추가했다. 사용자 검증과 기획자에게 들은 정보를 기반으로 조금씩 디자인을 추가했다.     

개발자: 루비 온 레일즈를 잠시 써본 적이 있었는데, 오랜만에 하려니 기억이 안 나 힘들었다. 사실 페어 프로그래밍을 하고 있는 P사 개발자도 마찬가지인 것 같았다. 그는 안드로이드 개발의 주종목이라고 한다. 오전에는 둘 다 삽질을 많이 했다. 오후에는 안드로이드 개발을 함께 했다. P사 개발자의 전문분야가 맞는 것 같다. 거침없이 멋지게 치고 나갔다. 하지만 페어 코딩을 하기에 둘의 실력이 차이가 나는 것은 크게 문제가 되지 않았다. 옆에서 보는 것만으로 공부가 되고 금세 내 실력도 높아질 수 있다. 하지만 둘 다 모르는 상황에서는 페어 프로그래밍은 좀 아닐 수도 있을 것 같다. 코드 리뷰에 관한 얘기를 잠시 나누었다. 코드 리뷰를 따로 하지 않는다고 한다. 왜냐하면 모든 코딩이 페어로 이루어지므로 일하는 것 자체가 코드 리뷰이다. 그렇다면 다른 사람이 짠 코드가 이상하면 어떻게 하는지 물었다. 바로 가서 왜 이렇게 했냐고 물어본다고 한다. 상대방이 기분 나쁘지 않겠느냐고 물었다. 왜 그러는지 이해를 못하는 분위기였다. 다 잘하자고 하는 건데 왜 그런 생각을 하겠느냐고 반박한다. 그렇다. 다 잘하자고 하는 것이다. 좀 더 고민해봐야겠다.  

3주 차 (15년 7월 31일) 업데이트된 화면 공유   

기획자: 디자이너, 개발자와 함께 디자인 리뷰를 하며, 해피 패스에 상세 내용으로 추가된 내용에 대해 함께 검증했다. 경쟁사의 제품을 사용해보며, 우리가 만드는 제품이 어떤 점에서 나은지와 부족한지 함께 고민해봤다. 스토리마다 포인트를 작게 나누게 되니 속도감 있게 스토리를 종료해나가는 것을 느낄 수 있다. 이 성취가 포인트를 작게 나누는데 큰 이유 같다. 나름 한국에서 테스트 주도 개발을 하려고 노력했다고 생각했었는데, 착각이었거나 테스트 주도 개발을 잘못 이해한 것 같다. 지금도 어떻게 다른지를 표현하기 힘들다. 앞으로 시간을 두고 이해해야겠다. 오전에 디자인 리뷰를 했는데 매우 좋은 경험이었다. 개발자도 마음껏 사용자 입장에서의 의견을 낼 수 있었고 개발자로서의 힘든 점도 얘기를 할 수 있는 분위기였다. 아직 초반이라 그런 건지 원래 그런 건지 웃으면서 마음껏 의견을 나누는 모습이 보기 좋았다.    

디자이너: 기획자와 개발자들과 지금까지 수정된 디자인 버전을 공유했다. 개발자들과 디자인을 공유하니 구현할 수 있는지에 대한 아이디어를 더 많이 얻을 수 있었다. 현 디자인의 이슈, 궁금점, 문제점을 포스트잇에 적어 공유했다.     

개발자: 8시간 동안 스토리를 쳐냈다.     

[개발자들의 페어 프로그래밍]

4주 차 (15년 8월 3일) 우리끼리 페어 프로그래밍   

기획자: 새로운 시나리오에 대해 개발자들이 개발할 수 있는 사용자 스토리를 쓰고, 디자인된 화면과 매핑시켰다. 남는 시간에 다른 업무에 대해 분석했다.     

디자이너: 또 다른 사용자를 만났다. 일주일에 두 번 정도는 늘 사용자를 만나 인터뷰하고 있다.     

개발자: 우리끼리 첫 페어 프로그래밍을 해봤다. 커뮤니케이션의 중요성을 다시금 느낀다. 한국어로 서로 이해하면서 하다 보니 코딩의 양이 지난주와 비교 안되게 늘었다. 그리고 P사 개발자들끼리 페어 하는 것을 지켜보았다. 쉬는 시간도 함께 협의해서 가지는 듯하고, 계속 무언가 토론을 하듯이 진행한다. P사에는 앵커(Anchor)라는 역할자가 있다. 앵커는 개발자 중에 정해지는데, 일반적인 회사처럼 개발 리더는 아닌 것 같다. 대신에 앵커는 팀이 더 좋은 커뮤니케이션을 할 수 있도록 도와주는 역할을 한다. 이 프로젝트에는 P사의 가장 젊은 여성 개발자가 이 역할을 하고 있다. 개발 실력이 가장 뛰어난 것은 아니지만, 늘 필요한 때에 팀에 도움이 될 대화의 시작점을 만드는 능력이 있다. 이러한 역할이 팀에 명시적으로 존재하는 것은 매우 중요해 보인다. 이 역할자를 통해 필요한 커뮤니케이션이 일어난다.     

[기획자와 디자이너의 협의]

4주 차 (15년 8월 4일) 이터레이션 계획 미팅   

기획자: 레거시 서버 연계 정책에 대해 개발자들과 논의했다. 그리고 이터레이션 계획 미팅을 진행했다. 사용자 스토리를 리뷰하고 스토리가 명확하지 않으면, 그 자리에서 수정하며 진행하고 스토리가 너무 크면 개발자들과 이야기 중에 스토리를 쪼갰다. 남는 시간에 디자이너와 함께 다른 기능에 대한 협의를 진행했다. 스토리를 명확히 하면 커뮤니케이션 오류 없이 원하는 기능을 만들어 낼 수 있다. 가능하면 직관적으로 만들어야 한다. 이 미팅은 10명 이하의 작은 팀으로 수행하는 강력한 미팅이라고 생각한다. 모두가 함께 하여 확인함으로써 빠진 부분, 챙겨야 하는 부분에 대한 공감대를 가질 수 있다. 여기 개발자들도 문서와 회의를 싫어한다고 한다. 주요 툴을 기반으로 최대한 공유한다.

디자이너: 이터레이션 계획 미팅에 함께 들어가 기획자가 사용자 스토리에 대해 설명할 때 디자인 콘셉트에 대해 함께 이야기해 주었다.     

개발자: 이터레이션 계획 미팅 후 페어 페어 프로그래밍으로 업무를 지속했다. 오래된 습관은 쉽게 바뀌지 않는다. 먼저 이 습관들부터 바꿔야 한다. 그들의 말을 나의 잣대에 맞춰 이해하려고 하면 안 될 것 같다. 뭔가 Context부터가 다른 느낌을 많이 받는다. 계속 관찰하고 나를 바꿔야겠다. 그리곤 한국에 가면 다시 바꿔야겠지만. 한국에서 개발할 때 늘 쓰던 축약어를 쓰지 말자고 이야기했다. 대신에 WhenSomethingDo_andthenBlahBlah 식으로 언제까지 내가 이 코드를 수정할 것이 아니기 때문에 다음 사람이 왔을 때 최대한 이해하기 쉽게 코드를 짜는 방법을 고민했다. 이렇게 짜면 데이터 사전 같은 건 필요도 없을 것 같다. 그동안 관습적으로 이게 최선이다라고 생각했던 일이 너무 정형화되고 소모적인 일이 많지 않았나 하는 생각이 들었다.     

4주 차 (15년 8월 5일)    

기획자: 기획자의 역할은 어디까지 일까? 디자이너, 개발에 필요한 부분을 해결해 주기 위해 기술적인 부분, 잡일 등 여기저기 뛰어다닌다. 페어로 일하는 P사 기획자의 개인적인 성격인지 원래 그런 건지 시간 날 때, 물어봐야 한다. 나 또한 기존 시스템에 대한 데이터베이스 인터페이스 단말기에 대한 문의를 해결하고 있다. 이게 진정 기획자의 역할인지 모르겠다. 프로젝트 매니저와도 중첩이 되는 것 같고, 그냥 알고 있는 사람이 하는 건지, 일이 너무 많다.     

디자이너: 가끔씩 느끼는 건 여기는 쉬는 시간이 따로 없어 보인다. 쉬는 시간이라기보다 정확하게 업무 외 다른 일을 하는 시간이 전혀 없다. 시스템, 결재 등 정말 꼭 해야 하는 업무 이외에 잡일이 전혀 없어 보인다. 심지어 개인 피시도 그대로 켜고 다니기 때문에 도착하여 자리에 앉는 순간 업무가 바로 시작이다 어떻게 보면 참 효율적으로 보이기도 한다    

개발자: 오늘도 우리끼리 페어 프로그래밍을 했다. 미국에 와서 피로가 축적된 건지, 오늘 하루가 힘들었는지는 잘 모르겠으나 점점 피곤해진다. 페어 프로그래밍 에너지 소모가 심하다. 내가 하고 싶어도 상대방 때문에 기다려야 할 때도 많고 상대방도 마찬가지이다. 이건 P사 인력과 페어를 해도 마찬가지다. 가장 중요한 건 수평적인 페어 프로그래밍을 하는 것이다. 누구 한 명이 주장이 강하고 한 명이 약하면 결국 코딩 방향이 정해져 버릴 것 같다. 어떻게 적용할지 감이 잘 안 온다. 어쨌든 누우면 잠은 잘오니 좋다. 불면증 치료에 페어 프로그래밍은 적절한 치료법이다. 페어 프로그래밍이기 때문에 정말 8시간을 집중해서 일한다. 물론 그만큼 체력도 많이 떨어진다. 어느 정도냐고 물어보면 SI시절에 밤샘 작업을 여러 번 했었는데, 거의 다음날 아침 같은 느낌이다.     

4주 차 (15년 8월 6일) 19일 차   

기획자: 고민이 너무 많다. 한국에 돌아가 기획자, 디자이너, 개발자가 한 팀이 아닌 경우 어떻게 적용해야 할지 모르겠다. 그렇지 않으면 이 구조가 제대로 돌아가지 않을 것 같다. 

디자이너: 처음으로 사용자 인터뷰에서 가장 만족스러운 결과를 보았다 간단한 프로토타입을 만들어 테스트하여 보았더니 단순하게 인터뷰할 때보다 훨씬 더 많은 이야기를 끌어낼 수 있어 의미 있었다    

개발자: 기존에 만들어놓은 소스를 수정할 때  처음부터 이런 식으로 만들면 됐을 텐데 새로운 사용자 스토리를 시작하면서 리팩터링을 한다. 예전 같으면 미리 생각을 해서 그렇게 만들어 놨어야지라고 소리쳤을 것 같았다. 그런데 테스트 코드가 있으니 꼭 그렇지는 않은 것 같다. 언제나 기존에 작성해놓은 코드들의 문제점을 검증할 수 있다. 모래성을 쌓는 것이 아니라 테스트 코드를 통해 착실한 건축물을 쌓는 곳이었다.    

4주 차 (15년 8월 7일) 20일 차   

기획자: 작은 팀이기에 모두가 몰입해서 회의도 가능한 것 같다. 회의 문화에 대해서는 더할 나위 없다. 누구도 말하지 않아도 회의실에 핸드폰을 보는 이도, 다른 이야기를 하는 이도 없다. 그들은 회의에만 집중한다. 그래서 회의는 40분~1시간을 넘어가지 않는다.     

디자이너: 이들의 가장 큰 장점은 투명성이다. 서로가 서로에게 무엇을 진행하고 있는지 어떤 방향으로 가고 있는지 무엇이 문제인지를 항상 공유하고 나눈다. 많은 시간을 서로의 일, 생각, 방향을 공유하는데 할애하기 때문에 가끔 이렇게 해도 될까 싶지만 이들은 이게 가장 중요한 것이라고 한다. 이를 통해서 한 팀이 어떤 방향으로 가고 있는지 무엇을 하고 있는지 이해할 수 있으며 궁금한 점이 생기면 서로에게 물어가며 맞춰간다. 이전에 내가 경험한 디자이너와 개발자의 회의는 거의 전쟁이었다. 개발자는 어떤 의도와 어떤 이해로부터 이렇게 만들었는지 디자이너 스스로도 모르는 상태에서 결과만 주니, 그림만 그리고 일을 내게 넘겨버린다는 느낌을 받았다. 이는 감정적인 문제로 번졌다. 개발자들이 못한다는 반응을 보이면 디자이너는 우리도 승인받은 내용이라 바꿀 수 없다고 이야기했다. 여기 와서 가장 크게 느끼는 차이점은 기획자, 디자이너, 개발자가 한 팀이라는 사실, 서로가 어떻게 하면 더 좋은 제품을 만들 수 있을지를 함께 고민하고 서로의 이야기를 귀담아 들어주고 어려운 문제를 함께 해결하고자 한다. 내가 봤을 때 고민하는 문제는 동일하지만 서로의 자세가 다르다고 생각된다. 가능하면 신뢰하고 믿어주며 함께 해결하고자 하는 고민이 긍정적인 결과를 도출한다고 생각된다. 이전으로 돌아간다면 이것이 과연 가능할까 가 고민이다. 개인적인 생각으로 가장 큰 문제는 좋은 제품을 만들겠다는 생각보다 빨리 만들겠다는 생각이다. 기업이라면 어쩔 수 없이 빠르게 만드는 게 중요하지만 빨리 만들고 버리느니, 제대로 만들고 조금 찬찬히 가는 것도 정말 의미 있는 일이라 생각된다. 여기 오기 전 린이라는 것은 빠르게 진행하는 것이라 생각했는데 여기 와서 생각되는 건 빠른 프로세스가 아니라 명확하게 집중해야 할 것과 서로 공유하여 한 방향을 맞추는데 많이 집중하고 나머지 시간은 최대한 줄이는 게 린이 아닐까 생각한다.    

개발자: 페어 프로그래밍에 대해 자꾸 적게 된다. 잘못 알고 있던 점이 있어 수정한다. 페어 프로그래밍을 할 때 한 명이 자리를 뜨면 일을 멈춰야 하는 줄 알았다. 아니다. 계속 진행해도 된다. 가장 중요한 것은 페어가 돌아왔을 때 자신이 무엇을 했는지 공유하는 것이다. 제일 중요한 것은 마음을 여는 것이다. 자꾸 물어보고 자꾸 대답하고 자꾸 고민해야 한다. 알아보지 못한 코드를 넘기면 발전이 없을 것 같다. 아는 척은 금물이고 관용을 베풀어야 한다. 자신이 더 알면 선생님처럼 가르쳐주고 모르면 제자처럼 배운다. 수평적인 구조가 아니면 힘들지 않을까? 페어 코딩의 또 다른 장점은 하나의 코드를 자연스럽게 여러 명이 보게 되면서 자연스럽게 리팩터링 된다. 얼마나 좋은가. 한국에 있었을 때 항상 하던 말이 있다. 자신이 남들보다 2배의 일을 하면 2인분을 하는 것이지만 남들이 2배 빠르게 할 수 있는 코드를 짜면 100인분도 할 수 있다는 말이었다. 생각이 바뀌었다. 내 옆의 페어를 2배 잘하게 하는 게 낫다. 페어 프로그래밍을 하면 가능할 것도 같다.