박상길
Sang-Kil Park

Home > Articles

Working Together In War Rooms


contents image
via erehwon

대부분의 IT기업 개발팀은 높은 파티션으로 둘러쌓인 조용한 개발환경을 선호합니다. 전화벨조차 울리지않는 사적인 영역에서 오로지 개발에만 집중하겠다는 소위 해커리즘을 지향합니다.

하지만 여러명이 한곳에서 함께 작업하는 워룸(War Rooms)형태의 근무환경이 2배의 생산성을 높인다는 미시건대학의 연구결과가 있습니다.

한술 더 떠 매킨토시의 아버지 제프 래스킨은 매킨토시 프로젝트를 진행할때 팀원들에게 각자의 크리에이티브를 적극적으로 표현할 것을 장려했다고 합니다.

사무실은 엔지니어 연구실이라고 보다는 거의 놀이방 분위기였다. 주기적으로 팀원들은 일을 잠시 멈추고 (어쩌다 오는 근방의 방문객들을 포함하여) 단체 놀이를 했는데 제프 래스킨과 브라이언 하워드가 주축이었다.

그중 가장 인기 있었던 것은 너프볼(Nerf Balls)로 했던 일종의 술래잡기 놀이였고, 최소한 하루에 한번은 벌어졌다. 사무실 안은 선명한 색깔 너프볼 수 십개가 흩어져 있었다. 규칙은 그때마다 즉홍적으로 만들었고, 술래가 된 사람은 다른 사람을 너프볼로 맞혀야 했는데 방어를 위해 팀원들이 종이판자로 바리케이드를 치는 법석 때문에 전체 사무실이 마치 종이판자로 만든 미로 같았다.

출처: (unix)4mac: 매킨토시 팀의 사무실 일호

굳이 XP 와 같은 토론식, 흥미로운(exciting) 방법론을 거론하지 않더라도 21세기가 요구하는 개발환경은 더이상 해커리즘이 아니라 대화, 토론 그리고 재미있는 환경입니다. 그리고 이것이 생산성을 높여주고 더욱 더 품질높은 산출물을 만들어 냅니다.


트랙백

코멘트

1.kr 2005년 4월 4일 오전 11시 49분, 박상민 작성:

멋지네요. :)
하지만, 회사게시판에 올려놓으면 사람들이 싫어하겠네요. ^^;

2.kr 2005년 4월 4일 오후 12시 24분, Tokigun [TypeKey Profile Page] 작성:

즐거운 환경이 조용한 환경보다 낫기는 한데... 그래도 둘 다 즐겁지 않고 시끄럽기만 한 환경보다는 낫다고 생각합니다. -_-; 그나저나 favicon이 생겼네요.

#kr 2005년 4월 4일 오후 1시 46분, likejazz [TypeKey Profile Page] 작성:

favicon 이 예전부터 있긴했는데 무단으로 따 쓴거라 시간을 내서 만들어보았습니다. 여러모로 디자인해봤는데 도통 마음에 들지않아 심플하게 정사각형으로 밀기로 했어요 ^^

3.kr 2005년 4월 4일 오후 12시 29분, cesia 작성:

하지만, 'Peopleware' 같은 고전이나 Paul Graham 같은 많은 해커들이 독립된 개발환경을 옹호한 것도 사실이지요. 21세기라고 그게 갑자기 달라질 이유도 명확치 않은 것 같고..

문득 든 생각입니다만, 개발의 '어떤' 단계냐 하는 점도 중요한 팩터라는 생각이 드네요. 마켓이나 요구사항 분석 단계라면 위에서 보인 것 같은 개방된 환경이 더 나을 수도 있겠지만, 설계 이후의 단계는 전통적인 독립적 개발환경이 나을 것 같은데요. 사실 재프 래스킨의 매킨토시 개발팀의 업무도, 설계보다는 훨씬 이전 단계가 아니었을까요?

#kr 2005년 4월 4일 오후 3시 36분, likejazz [TypeKey Profile Page] 작성:

확신하는 문체를 좋아해서 "~해야한다"고 말했지만 아직도 반신반의한것은 사실입니다. 어느것이 효과적인 방법이다라는것은 책마다 다르게 언급하고 있고 분명한것은 말씀하셨듯이 때에 따라 또는 구성원의 특징에 따라 달라질수있다는 점입니다.

제프래스킨이 항상 그런식으로 업무에 임했는지는 확실치않지만(ilovja님이 답변해주실지도 ^^) 제 생각은, 적어도 agile methodology 에 따르면 핵심적인 개발작업에서도 항상 대화하고 토론하며 Pair 로 만들어나가는것이 효율적일 수 있다는 점입니다. 실제로 임베디드소프트웨어를 개발하는 소위 core-development 에 agile methodology 를 적용한 사례도 있습니다.

http://xper.org/wiki/xp/AgileMethodology
http://xper.org/wiki/xp/JamesGrenningInterview

물론 agile methodology 가 위에서 언급한 근무환경과는 조금 거리가 있지만 일반적으로 XP 방법론이 War Rooms 에서 진행하는것을 추천함을 고려할때 전혀 관계없는 얘기는 아닌듯합니다.

4.kr 2005년 4월 4일 오후 2시 5분, 백일몽 작성:

개인적인 성격 탓인지는 모르겠지만
혼자 골똘히 일 하기 보다는
짝 프로그래밍을 할 때 열심히 떠들고 열심히 일 하는 것이 더 재미있었습니다.
회사를 옮기고 나서 짝 프로그래밍을 못 하는게 아쉬워요.

#kr 2005년 4월 4일 오후 4시 0분, likejazz [TypeKey Profile Page] 작성:

저도 짝 프로그래밍에 한표 던집니다. 저랑 일몽님이랑 같이하면되겠네요. 저는 옆에서 졸께요.

5.kr 2005년 4월 4일 오후 3시 20분, yser 작성:

별로 관계 없는 내용인데, 궁금해서 올려 봅니다.
likejazz 님은 해외 문서에도 강하신 것 같아서.. ^^

http://www.welie.com/patterns/showPattern.php?patternID=faceted-navigation

diamond wiki 에서 도입하는 면의 개념인데, 제겐 뭔 말인지 와닿지가 않더라구요.. 어디선가 저게 획기적인 분류 방법이라고도 하던데, 제껄로 소화가 안되서 전에 보고 말았다가, 생각이 나서...

google 의 label 을 보다가 저걸 보게 되었는데, 그거랑 다른 뭔가가 있는 걸까요? 예제 페이지도 봤는데, 뭐가 뭔지 모르겠더군요;;

#kr 2005년 4월 4일 오후 4시 39분, likejazz [TypeKey Profile Page] 작성:

inglish 의 i 자도 제대로 모르지만 살펴보니 조건으로 제한을 두는 고전적인 형태의 분류체계네요.

저기서 지칭하는것은 정확히는 Multiple Faceted Navigation 이고 여러가지조건으로 범위를 좁혀나가 결과값을 도출해내는 방식입니다. 이미 일반화된 방식이라 획기적이라 언급하긴 좀 그렇고 ^^; 아마도 오래된 문서가 아니었나 생각합니다.

Faceted Classification/Navigation 에 대해서는 http://www.webdesignpractices.com/navigation/facets.html 이곳에 예제와 함께 상세한 자료가 있습니다.

6.kr 2005년 4월 4일 오후 5시 16분, 김창준 작성:

>하지만, 'Peopleware' 같은 고전이나 ...(중략)... 독립된 개발환경을 옹
>호한 것도 사실이지요. 21세기라고 그게 갑자기 달라질 이유도 명확치
>않은 것 같고..

http://xper.org/wiki/xp/PeopleWare 참고하세요.

7.kr 2005년 4월 4일 오후 5시 24분, yser 작성:

답변 주셔서 감사합니다. 이제야 속이 좀 시원하군요. ^^;
고딩 때 영어 수업 놀아서;;

8.kr 2005년 4월 4일 오후 5시 26분, 김창준 작성:

> 설계 이후의 단계는 전통적인 독립적 개발환경이 나을 것 같은데요.

설계가 완벽하고, 커뮤니케이션의 필요가 거의 없다면(즉 정보의 이동, 확산이 필요 없다면) 그럴 것 같습니다.

제 지인의 경험을 적습니다.
----
회사에서 전통적인 큐비클 환경에서 일을 하시던 분입니다. 앉은 자리에서 앞자리 사람의 얼굴이 보여서 그 자리에서 질문도 하고 토닥토닥 다투기도 하고 했답니다. 그런데 어느날 칸막이를 높히게 되었다고 합니다. 이제는 앉은 자리에서 일어나도 바로 앞자리 사람의 머리가 잘 보이지 않을 정도가 되었다고 합니다.

발견된 변화:

싸우는 일이 줄었다고 합니다. 대신 한번 싸울 때 엄청 크게 싸우게 되었다고 합니다. 팀 전체 관점에서 보았을 때 칸막이가 높아져서 결국 손해를 보게 되었답니다.
----
구현 단계에서 워룸을 써보니, 제 경험으로는 팀 전체의 학습속도가 무척 빨라지고 문제를 미연에 찾아내 대응, 적응하는 능력이 높아지는 것 같습니다.

9.kr 2005년 4월 4일 오후 10시 0분, firefox 작성:


일종의 KLDP CodeFest 같은 분위기(?)를 말하는 것이군요.

확실히 여러사람이(너무 많으면 곤란하겠지만.) 같이 하는 것이 능률적이긴 한 것 같습니다.

10.kr 2005년 4월 15일 오후 11시 25분, 세라비 작성:

cecia님의 comment 중, "하지만, 'Peopleware' 같은 고전이나 Paul Graham 같은 많은 해커들이 독립된 개발환경을 옹호한 것도 사실이지요."

제가 요즈음 Peopleware를 읽고 있습니다만, DeMarco가 꼭 one person offices를 고집하지는 않습니다. 인용하면,

"The two- or three- or four-person office makes a lot more sense, particularly if office goupings can be mad to align with work groups."

DeMarco가 강조하는 것은 "noise와 interruption이 productivity에 치명적이다 이 점을 Manager가 인식하고 Worker가 개선을 요구할 필요가 있다" 정도입니다.

따라서, 사실 WarRoom도 DeMarco의 주장에서 크게 벗어나보이지는 않습니다. 팀은 식사도 함께하고, 회의도 함께 하게되기 때문에, 일의 페이스도 비슷하고, 따라서, 팀 범위 내에서는 noise나 interruption의 문제는 크지 않다고 봅니다. 제 경험적으로도, 시끄러워서 일을 그만두고 쳐다볼 수 밖에 없었던 것은 주로 다른 팀의 노이즈였습니다. 팀 내에서는 놀땐 같이 놀죠.

주기적인 놀이를 해주는 것은 경험적으로도 좋아보입니다. 일의 집중도가 낮아질 때는, 계속 억지로 일하는 것보다 다른 팀원들과 함께 기분전환을 하는 것이 훨씬 좋더군요.

그리고, cecia님 말대로, 어떠한 일을 하고 있느냐에 따라, communication의 빈도는 다르고, 따라서, 어떠한 공간이 최적이다라고 하는 것에는 무리가 있으리라고 생각합니다.

참, 그리고 지적인 노동에 있어서 "재미"가 중요하다는 것은 20세기부터 계속 강조되어왔던 사실입니다. (예를 들어, Brooks나 Drucker)

11.kr 2005년 4월 15일 오후 11시 35분, 세라비 작성:

대화와 토론 또한 마찬가지지요.

업무 환경의 문제에 대해서는 해커리즘을 고발할게 아니라, DeMarco가 주장하는대로, Office Police에게 책임을 돌리는 것이 더 옳다고 생각됩니다. 그러한 업무 환경에 대해서 아무런 생각이 없거나 잘못된 생각을 가지고 있는 책임자들 말이죠.

#kr 2005년 4월 16일 오전 0시 9분, likejazz [TypeKey Profile Page] 작성:

좋은의견 감사합니다. cesia님께도 알려드렸습니다.

한가지만.

우리말로 할 수 있는 표현은 가급적이면 우리말을 사용하면 어떨까요?
http://www.likejazz.com/29458.html

이글에 대한 트랙백과 코멘트는 더이상 지원하지 않습니다.

| 다음 글