왜 나는 웹의 개발을 불편해하는가. (불편해하지 않게 하기 위한 질문)

왜 나는 웹의 개발을 불편해하는가. (불편해하지 않게 하기 위한 질문)

첫번째 이유로는 완성품의 정의를 명확하게 정의하기 어렵기 때문에, 결국 많은 混乱と遅れ를 반복하기 때문입니다.
Refactorying, 명확하지 않거나 모호한 요건은 가능한 다음 Iteration에서 대응하는 방법도,
Iteration이 반복될 수록, 고객(또는 사업부)쪽에서 이번기회에 요구되는 기능이 확 추가해버리고자 하면 더욱 곤란해집니다.
->
스스로 pseudo를 작성하고, 완성하면 이것을 함께 제출하는 방법을 써봐야겠습니다.


두번째 이유는 테스트.
아무리 최신 DI, ORM, Test framework을 사용해 코드를 멋지게 우아하게 작성했다고 해도,
결국 브라우저에서 입력하고 클릭해가며 하는 테스트를 수행해야하는데, 정말 재미가 없습니다.
기능 업데이트나 변경이 있으면 그 테스트를 반복해 수행해야 합니다.
->
각 브라우저별 플러그인이나 익스텐션등을 제작해서 하는 자동화라도 생각해 봐야겠습니다.

더있을까요?
흠.

개발 방법론? xp? 애자일? 우리 팀장 이야기를 들어보세요

우리 팀장은 경력 19년입니다.
나이는 43세이고 2010년이면 한살이 더 많아집니다. 대학을 졸업하고 줄곧 개발라인에서 있어왔습니다.

19년전이면 1990년이군요. 제가 91학번인데, 제가 입학할 때쯤 부터 사회에서 활약한 것 같습니다.
이때는 당연하지만 윈도우즈95가 없던 시절입니다. 대학 1학년때 허큘레스나 cga 그래픽 환경에서 디스켓을 교환해가며 아래아 한글을 배우던 시절입니다. wikipedia를 보니 윈도우즈 3.1이 92년에 발표되었다고 하는군요.

정식 직급은 팀장이나 과장이라는 명칭이 없기 때문에 '매니저'라는 타이틀이 있습니다.
다들 그러한지 모르겠지만, 이 회사에서는 본부장-부장-매니저-어시스턴트 매니저- 라는 타이틀을 사용합니다.

우리 팀장은 제가 일하는 회사에 들어온지 8년정도 되었습니다. 내년이면 9년이 됩니다.
일본회사이다보니 그런지(모든 일본회사가 다 그런 것은 아닐것입니다만) 임원진이 아니면 승진은 근속년으로 정합니다. 그래서 훨씬 젊은 30대의 10년근속(내년이면 11년이 되는) 부장 밑에 있습니다.

인물의 소개는 이쯤으로 하고, 제가 소개하고 싶은 것을 말씀드리자면 이 팀장이 팀을 꾸러나가는 방법입니다.

---------

소개하기 전에 앞서, 저도 일본회사에 들어오기 전, 한국회사에서 과장 2년차까지 지내다 왔고, 저 또한 개발매니저의 역할이라던지, XP니, 애자일이니, 스크럼이니 하는 방법론들에 대해 연구를 많이 하고 경험해 보았기 때문에, 한 쪽으로 치우친 의견만은 아니라는 것을 언급해 두고 싶습니다.

각 장점, 단점, 그리고 지금도 많이 토론되고, 개선방법등 연구되어져 가고 있는 것을 잘 알고 있습니다만, 이런 방식도 있구나 하는 것으로 들어봐 주세요.

---------

우리 팀장의 방식을 서머라이즈 해보면,

1) 작업은 개인 능력차를 고려하여 4시간 분량정도 단위로 배분합니다.
2) 개발 팀원은 기획회의에 참여하지 않습니다.
3) 큰 로직은 텍스트나 엑셀로 적어 팀원들에게 전달합니다.
4) 반드시 제출된 코드를 읽어보고, 승인한 개발물의 책임은 매니저가 집니다.

가 특징입니다.

1) 작업은 개인 능력차를 고려하여 4시간 분량정도 단위로 배분합니다.

우선 이 내용은 팀장이 자신의 매니징 방법등을 공식적으로 설명한 것이 아니라, 제가 멤버로서 함께 일하며 경험해 '아-! 이런 방식이구나.'하고 느낀 것입니다.

작업의 단위는 크게 주어지지 않습니다. 한국에서의 경험으로 말하자면 어느 모듈, 어느 메뉴의 한 부분등을 한 개발자가 맡아서 3-4일이나, 일주일등의 어느 정도 기간을 할당하여 맡기지 4시간 정도로 맡기지는 않지 않습니까.

우리 팀장은 4시간이면 끝낼만 하겠다 싶게끔 일을 줍니다.
그리고 끝나면 보고해 달라고 합니다.
만일 예상한 시간보다 더 짧은 시간내에 끝내면, 다음번은 조금 난이도를 높여서 줘봅니다.
반대로, 만일 예상한 시간보다 더 오래 걸렸다면, 다음번에는 난이도를 낮춰서 줘봅니다.

4시간이면 하루 8시간 근무의 절반의 시간입니다.
메신저를 많이 했다던가, 회사일 이외의 개인적인 일이나, 업무에 집중하지 못해서 4시간 분량의 일을 퇴근할 때쯤 8시간을 사용해 다 했습니다 하고 보고하는 경우에도, 다음번에는 난이도를 낮춰서 줘봅니다.
이것이 반복되면 일의 단위가 소스 몇줄을 고치는 정도의 일 정도의 단위로 나오게 되다가, 나중에는, 소스가 아닌 브라우저로 테스트하고, 결과를 엑셀에 적어서 제출하는 일을 하게 되기도 합니다. (실제 중국인 여성의 개발자가 그렇게 되었었던 적이 있습니다.)

일을 다 하면 보고합니다. 4시간 정도의 분량을 4시간정도에 끝내면 하루에 2번은 팀장과 작업에 대해 커뮤니케이션 하는 것이 됩니다.

이 방법을 사용하면, 제가 옆에서 보기에도 확실히 프로젝트나 인력(리소스)등의 매니징이 됩니다. 프로젝트가 현재 어디까지 진행중이고, 완료 예정일을 확실히 잡을 수 있습니다. 팀원이 낮에 집중하지 못하고 일하다가 습관적으로 야근하며 일하게 하는 것도 방지됩니다.

또, 팀원들의 개별 실력파악도 이것으로 확실히 할 수 있습니다. 사분기로 나눠서 하는 평가에도 그대로 반영됩니다.

2) 개발 팀원은 기획회의에 참여하지 않습니다.
이 팀장의 방식 이야기를 누군가에게 했더니, '회의라던지 가면 어떻게 4시간내에 끝낼 수 있느냐..' 라고 질문을 받은 적이 있습니다. 답은. '일반 개발자는 기획회의에 참여하지 않는다' 입니다.

회사 전체가 이러한 방법을 취하고 있는 것은 아닙니다. 우리 팀원의 팀장의 방식입니다.
이것은 여러가지 의미가 있습니다.
기획을 담당하는 사업부와 개발부간의 창구의 일원화. 팀의 개발자들에게 집중할 수 있는 환경을 제공. 그리고 로직의 결정등 사공이 여럿이 생기지 않는 것 등. 장점이 큽니다.

그러나 저도 한국에서 이렇게 하지 않았고, 회사의 다름 팀도 대게는 이렇게 하지 않는데, 그 이유는 회의에 참석한 사람에게 전달된 내용의 구현의 책임이 주어지게 되는 것이기 때문에, 로직을 생각하는 것과 구현의 책임을 팀장 혼자서 책임 지는 것과 같은 부담을 피하기 위해서입니다.

그러나 우리 팀장은 혼자서 참석하고, 들은 내용의 로직을 생각해 적어서, 변수명이나 파라메터 설정값등도 생각나는 범위의 한에서 적어서 메일로 전달합니다. (큰 내용을 전달하더라도 4시간 분량의 작업범위만큼을 정해서 이정도 까지 되면 보고해 주세요. 그 뒤 그 다음의 세부 내용을 말로 설명하겠습니다 하고 작업을 냅니다.)

3) 큰 로직은 텍스트나 엑셀로 적어 팀원들에게 전달합니다.

전달은 팀 전원에게 CC로 전달합니다. 이것은 팀장의 특별한 방식이 아니라, 대게의 일본의 회사가 그러합니다. 만일 팀원이 결원되더라도, 다른 팀원도 메일박스를 조사해보면, 이 부분의 작업이 어떻게 흘러가고 있었는지를 알 수 있습니다.
작업은 메일로 전달하고, 반드시 구두로도 다시 한 번 전달합니다. 일본에서는 認識間違い라고 하는, 하나의 내용을 서로 다르게 이해하고 있는 것을 피하게 하기 위해서 입니다.


4) 반드시 제출된 코드를 읽어보고, 승인한 개발물의 책임은 매니저가 집니다.

예전에는 사용하는 곳이 드믈었지만, 지금은 어디서나 SVN이나 VSS같은 소스 관리 툴을 사용하는 것이 상식화되어 있습니다. 커밋된(또는 체크인된) 소스는 반드시 팀장이 읽어봅니다.
Connection.close를 잊었었다던지(또는 더 빨리 할 수 있는 것을 발견했다던지), transaction걸고 에러나면 rollback되는 처리를 빠뜨렸다던지, 불필요한 변수 선언이 남아있었다던지, 퍼포먼스가 나쁜 부분을 발견했다던지 하면 수정해 달라고 다시 요청합니다. 반복 요청된 만큼 소스관리툴에서는 그 개발자의 커밋또는 체크인이 기록되기 때문에, 이는 또 창피한 요소가 됩니다. 말은 안하고 있지만 당연히 평가에도 반영되고 있을 것입니다.

'OK입니다'라고 말을 들었더라도 그것으로 완전히 끝난 것이 아닙니다. 자신이 작업한 부분의 검증이 다른 팀원에게 할당되기도 합니다.

매니저는 매우 바쁩니다. 기획 회의에 참석하고, 개발자들에게 작업을 내고, 결과를 받고 피드백을 줘야 합니다. 참석한 회의에서 들은 내용의 구현 로직을 생각해 적어야 하고, 팀 보고의 매니저 회의에 참석해야합니다. 자잘한 업무보고도 취합해 부장, 본부장에게 적어서 내야하고, 휴가등의 스케쥴 관리도 해야합니다. 분기별 새로운 기술공유를 위해 매니저들에게 내는, 연구과제 숙제도 해야합니다. 결제와 관련된 Batch가 잘 동작하고 있는지 주말에도 한번쯤 확인해야하고, 월말이면 더욱 많아집니다. 캠페인이라도 있는 날이면, 서버 부하도 한번씩 살펴봐야 합니다.
소스관리나, Deploy는 보안과 관련된 것이어서 함부로 팀원에게 맡길 수도 없기 때문에 직접합니다. 팀원이 개발의 구현을 헤매고 있으면 도와주기도 하고(절대 코드를 대신 짜주는 것은 아닙니다만), 스케쥴에 맞추기 위해 그중에서도 개발을 합니다.

그런데, 절대 운용상 큰 오류를 내거나, 납기를 맞추지 못한 적이 없습니다.

이것은 XP, 애자일, 스크럼등의 새로운 방법론과 확실히 대조가 되는 방법입니다. 전통적이라고 해야할까요. 중요한 것은 굉장히 안정된 개발과 팀 운영이 되고 있다는 점입니다.
단점도 분명히 있습니다.
예를 들면 매니저에게 너무 막강한 Role이 주어져있는 것, 팀원이 많으면 이 방법을 사용할 수 없는 것(우리팀은 팀장포함 4명입니다). 후임을 양성시키기에 불편한 방식이라는 점등.

그런데 야근도 없고, 개발팀원은 개발에 집중할 수 있습니다. 잘만 운영되고 있는 것을 보면 신기합니다. 저라면, 제가 매니저가 된다면, 저도 이 방법을 취할 것만 같습니다. 그래서 한번쯤은 소개해야겠다라고 생각이 들었습니다.

여러분도, 한번 생각해 보세요.
뭔가 질문이 있으면 보충하겠습니다.

이상.