애자일 이야기 : NHN 개인커뮤니티팀과 애자일

NHN 개인커뮤니티팀과 애자일

작년에 NHN 개인커뮤니티팀(사실 NHN에 정확히 이런 명칭의 조직은 없는 것으로 알고 있습니다만)에서 코칭을 했습니다. 개발자들과 기획자들의 협업에 특히 초점을 맞추었습니다. 다른 곳에선 좀처럼 보기 힘든 기획자와 개발자 간의 협력 욕구와 가시적 노력을 보면서 발전 가능성을 보았습니다. 아, 이 팀 뭔가 한 건 할 수 있겠군! NHN 개인커뮤니티 PM이신 정현주님도 그 때 뵙게 되었지요. 기획자이시지만 개발자와 협력을 위한 노력, 열린 마인드 등에서 많은 점을 배울 수 있었습니다.

월간 웹 2007년 5월호 기획자 컬럼에 정현주님의 글이 실렸네요. 애자일을 언급하신 부분이 있어서 부분 인용을 합니다.

그렇다면, 나를 둘러싼 기획/개발자들은 어찌하여 협업을 본인을 규정하는데 과감하게 들여오게 되었을까? 곰곰이 이를 따져보니 근 1년 동안 우리가 '애자일'이라는 협업의 언어를 체득하게 되었다는 데 생각이 미치게 되었다. 내가 정의하는 애자일이란 '서비스를 만들기 위해 모인 사람들이 공통의 언어를 사용해 서비스 가치를 정의하고 측정하고 개발하는 방법'인데, 여기에는 서비스를 사용하게 될 이용자까지 포함한다. 작년 이 즈음, 블로그 기획 개발자가 모두 모여 상대에 대해 칭찬하고 싶은 점, 고쳐주었으면 하는 점을 이야기하고 개발이 진행되는 단위 단위마다 공유할 수 있는 형식을 세우고 실행을 약속했는데 그것이 어느새 1년이 지난 것이다.

처음에는 낯선 형식이 속도를 제한할 뿐 아무런 가치를 주지 못하고 있다고 생각하기도 했지만 '업무를 주 단위로 쪼갠다', '주 단위로 진행속도를 체크한다', '사용자가 경험하는 가치로 개발단위를 구분한다' 등의 약속한 '형식'을 지켜가다 보니 좋은 서비스라는 가치를 얻게 되었고 서로간에 '신뢰하는 마음'을 갖게 되었고 그래서 본인의 직업적 정체성을 그와 같이 표현하게 되었다고 내 마음대로(?) 뿌듯해 하면서 해석해 보았다.

--정현주, 월간 웹 2007년 5월호 p.40

보통 사람들은 생각하기에 소프트웨어 조직의 최대 병목은 개발 속도라고 생각하기 쉽습니다. 저도 예전엔 그렇다고 믿었습니다. 그런데 경험을 하다보니 그렇지 않은 경우도 많았습니다. 오히려 최대 병목은 개발 속도나 기획 속도 등 단일한 기능조직 내에서의 속도가 아니라 개발과 기획의 연결 고리에서 찾을 수 있었습니다.

제약조건 이론(TOC)이라는 것이 있습니다. 간단하게 말하면 쇠사슬의 강도는 그 쇠사슬에서 가장 약한 연결고리가 결정한다는 이야기입니다. 여러개의 고리 중 하나가 플라스틱으로 되어 있다면 다른 나머지를 모두 강철로 바꾼다고 해도 전체 강도는 나아지지 않습니다. (제약조건 이론의 입문 서적으로는 "더 골"을 권합니다. 너무 재미있어서 밤샘을 할지도 모르니 조심하시길.)

(이미지 출처는 알라딘)

바꿔말하자면, 개발팀의 속도가 최대 병목이 아닌데 그 팀의 속도를 높히는 것이 조직의 성과에는 크게 도움이 되지 않는 상황이 종종 있었다는 것이죠. 그래서 저는 이제 어떤 소프트웨어 개발 조직을 처음 컨설팅할 때 "기술적 문제"라고 클라이언트가 이야기를 해도 우선은 의심을 해봅니다. 정말 개발팀의 기술적 문제이고 개발 속도의 문제일까. (물론 개발 속도가 빨라지면 조직이 더 많은 학습을 더 빨리 할 수 있다는 장점이 있긴 하나, 충분 조건은 아닙니다. 개발 속도가 빨라지는 것이 조직의 학습으로 직결되지 못하는 조직이 많습니다.)

그런데 TOC 이론에서는 현 시스템의 최고 병목을 해결하고 나면 끝이 아니고, 새로운 전체 병목이 부상한다고 말합니다. 그래서 항상 시스템의 병목을 찾고 해결하는 노력을 놓치지 말아야 한다고 합니다. 분명 개인커뮤니티팀도 새로운 병목들을 만났을 것이고 그 병목을 해결하느라 땀을 흘리고 있으리라 생각합니다.

개인커뮤니티팀이 지금까지 보여준 성과를 바탕으로 앞으로도 더 많은 성장과 발전을 기대하겠습니다. 화이팅!

--김창준

# by 애자일컨설팅 | 2007/05/03 21:01 | 트랙백(3) | 덧글(9)

트랙백 주소 : http://agile.egloos.com/tb/3371549
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]

Tracked from 상상할 수 있는 힘이 .. at 2007/05/04 11:42

제목 : TOC 화들짝 하게 했던 그 이야기.
TOC 화들짝 하게 했던 그 이야기가 NHN 개인커뮤니티팀과 애자일 가 여기서도 등장합니다. 강력한 추천 도서인 The Goal 과 함께 말이죠. 전 The Goal 을 너무 재미있게 읽어서 연속 세번을 읽었습니다. 그 다음 씨리즈인 It's not luck 과 Necessary But not sufficient 까지도요. 부분최적화는 순간에는 좋아 보일지 모르지만 전체적으로는 크게 도움이 되지 않습니다. 게다가 최적화라는 환상에 ......more

Tracked from 기차니즘 초절정 고수 .. at 2007/06/05 01:11

제목 : The Goal
제약조건이론 : TOC(Theory of Constraints)흐름을 막는 곳(제약조건)을 찾아 통과하는 흐름을 모든 의사결정의 기준으로 삼는다.(http://pm.chonnam.ac.kr/toc/toc.asp)애자일 이야기에서 소개한 이 책을 보고 싶었다. 더욱이 Paromix 님이 '재밌다'는 말을 해주셔서 우선순위를 앞땅겨 보았다.TOC는 생각의 출발점을 제시하고 있다. 문제가 생겼을 때 그 문제를 어떻게 풀것인가의 실마리다.소......more

Tracked from GomSun2, 생각,.. at 2008/04/30 01:50

제목 : Flextronis사와 제약조건, 소프트웨어 고고학..
개인적인 의견, 개인적 견해가 담긴 설명은 괄호()로 묶었습니다. 잘못된 점이나 잘못된 표현등은 알려주시면 정말 고맙겠습니다. 2004년 NHK에서 제작한 글로벌 마켓이라는 다큐를 보는중에 관심내용을 정리했습니다. 글로벌 마켓이라는 다큐는 총 7부작으로 구성되어 있는데요, 4부 - "베일에 가려진 거대기업의 세계"중일부의 내용을 발췌했고 개인의 의견을 덧데어 구성된 포스트 입니다. 다큐는 Flextronix사와 최고 결정자 마이클 막스(능력이 ......more

Commented by 카페모카 at 2007/05/03 22:22

어느 교수님께서 하신 말씀이 생각납니다.
독일 속담에 "천천히 완벽하게 하는 것이, 사실은 가장 빠른 길이다."

Commented by 찬욱 at 2007/05/03 23:09

정말이지 The goal은 강추하고 싶은 서적입니다!

Commented by 플루 at 2007/05/03 23:56

재작년, 작년을 거치면서 회사 내에서도 애자일하게 일을 하려는 움직임이 많이 생겨났습니다. '우리는 애자일이다.'라는 표어를 당당하게 외치는 그런 느낌은 아니더라도 사내 전도사들의 노력과 사람들의 애자일에 대한 관심 덕분에 이제는 어딜가나 애자일향을 맡을 수 있게 된 것 같습니다. 비록 그 향이 옅은 곳도 있고 짙은 곳도 있지만요. ^^

제 업무 환경의 경우 2005년과 달라진 점이 있다면 QA가 소프트웨어 개발 과정에서 차지하는 비중이 커지면서 테스터들도 중요한 커뮤니케이션의 대상이 되었다는 겁니다. 흔히 볼 수 있는 기획자-프로그래머의 구도에서 기획자-프로그래머-테스터라는 삼각 구도가 형성된 것이죠.

처음에는 많은 어려움이 있었지만 다행히 기획자, 프로그래머, 테스터 모두가 개선에 대한 의지가 있었기에 지금은 서로 꽤 만족스럽게 일을 하고 있습니다. 앞으로도 좋은 Practice들을 계속 발굴해야겠지만, 지금까지는 '커뮤니케이션 주도 개발'이라고 해도 과언이 아닐 정도로 서로 커뮤니케이션의 기회를 많이 가지는 것에 집중을 해왔고, 괜찮은 성과를 얻은 부분도 있습니다.

정착시키길 잘 했다고 저희가 생각하는 한 가지 Practice는 기획자 혼자 기획을 하는 것이 아니라 기획자, 디자이너, 프로그래머, 테스터 모두가 기획에 참여를 하는 것입니다. 사실 모두가 참여를 한다고 하더라도 기획자를 제외한 나머지 인원들은 전문가가 아니기에 기획의 완성도가 눈에 띄게 올라가거나 특별한 아이디어가 포함되는 경우는 그다지 많지 않더군요. 오히려 그런 부분보다는 디자이너, 프로그래머, 테스터 등의 비기획자들이 기획에 참여함으로써 일종의 동기부여를 얻는다는 데에서 더 많은 것을 얻는 것 같습니다. 기획자의 주문서대로만 그리고 코딩하고 테스트하는 것보다는 자기의 아이디어가 들어간 것을 하는 게 더 재미있으니까요. ^^

동기부여 측면 이외에도 자기가 무엇을 해야하는지 미리 알 수 있고, 우리가 무엇을 하는지 미리 공유할 수 있다는 점도 좋다고 생각합니다. 기획서를 전달 받고 나서야 설계하고 코딩하고 테스트 케이스를 작성하는 경우에 비해 하루라도 먼저, 그리고 최소한 머릿속에서라도 설계를 해보거나 테스트 케이스를 만들어 볼 수 있으니 좀 더 좋은 결과물을 내는 데 도움이 되더군요. 후자의 경우에서 얻은 이점이라고 생각하는 건 '업무 문의와 관련된 인터럽트'가 상당히 줄었다는 겁니다. 적어도 테스터가 '저... 여쭤볼 게 있는데요...'라면서 전화, 메신저, 메일 등을 보내는 일은 요즘은 거의 없죠..^^;

요즘은 새로 발견된 문제를 고민하고 해결책을 고민하고 Practice를 세우는 재미에 행복합니다. 본문에서 말씀하신 최고 병목을 해결하고 나면 새로운 전체 병목이 부상한다는 것... 하지만 그것을 해결하는데 땀을 흘리는 보람이 얼마나 큰 것인지를 보다 많은 사람들이 알 수 있으면 좋겠습니다. ^^ -웹개발팀 이의호

Commented by 박PD at 2007/05/04 00:49

게임 쪽에도 어서 컨설팅 하시길 바랍니다. :)

Commented by 태현 at 2007/05/04 02:00

좋은 책 추천 감사드립니다. 내일 학교 도서관에서 한 번 읽어보고 도움이 되면 구입해야겠습니다. =)

Commented by 이봉석 at 2007/05/04 09:42

참 재미있는 책입니다. The Goal 두번째 이야기도 추천해드립니다. ^ㅅ^

Commented by nexus11 at 2007/05/04 13:49

병목을 '개발속도' 라고 생각한다면, 바꿔 말해서 '개발자가 병목을 해결할 수 있다' 라고 생각합니다. (저도 개발자이긴 합니다.^^)
물론 저 또한 병목이 '개발속도' 라고는 생각하지 않습니다.
저는 그보다 저 중요한게 커뮤니케이션 이라고 생각하거든요.
개발자가 병목을 해결할 수 있다.. 라는 말엔 동의 합니다.
누군가 나를 개발자라고 부른다는것은 나는 개발자이기 때문입니다. 개발자면 개발을 하는건 당연한것이고, 그외에 할일은 커뮤니케이션을 잘 해야 한다고 보고 있습니다.
기획자와 개발자간의 연결고리는 바로 개발자가 되어야 한다는거죠..
개발자분들도 한번쯤은 기획자가 되보시는걸 추천합니다. 물론, 직군을 바꾸라는 이야기는 아니고 그들의 생각속에 무임승차를 한번쯤은 해보는게 커뮤니케이션에 상당한 도움이 되거든요..^^

매번 좋은글 읽고 가네요..

cf) The Goal은 밤샘이 아깝지 않게 해줍니다. :)

Commented by sanghyun at 2007/05/07 20:33

the goal의 2권이 뭔가 해서 찾아봤더니 It's not luck 이라는 제목이군요. 읽기만 해놓고 써먹질 못했는데 이 글을 읽고 다시 생각이 났습니다. it's not luck도 보고싶어지네요.

Commented by 김신 at 2007/05/08 11:06

커피 & 도넛이라는 어느 광고 문구처럼

병목과 커뮤니케이션을 뗄 수 없는 것은 '부분 최적화' 때문이 아닐까 싶습니다.

자기에게 명명된 프로그래머, 기획자, 디자이너 라는 타이틀에 맞는 작업만 하면 끝이라고 생각하기 때문에 부서간 병목이 발생합니다.

병목뿐만이 아니라 가치있는 기업, 업무가 되기 위해서는 커뮤니케이션을 통해 이를 완화해야 합니다.

부분최적화를 늘 머리에 생각하시고 나와 연관된 사람들의 공정을 생각하신다면 보다 Goal 근접하지 않을까 합니다. ^^

< 이전페이지

다음페이지 >