맨먼스 미신

+


맨먼스 미신 (원제 : The mythical man-month, essays on software enginnering) 을 읽으며 강하게 와닿았던 구절들을 발췌하여 10년간 개발자로 일해왔던 내 개인의 경험과 소프트웨어공학의 지식을 바탕으로 미숙하게나마 정리의 글을 쓰고자 한다.

==첫번째 글==

2장 맨먼스 미신

" 소프트웨어 구축작업은 내재적으로 시스템적인 노력, 즉 복잡한 상호관계의 실행이기 때문에 커뮤니케이션 노력이 많이 필요하며, 이는 분할에 의하여 줄어든 개별적인 작업시간을 순식간에 잡아먹게 된다. 그래서 인력을 추가하면 일정이 단축되기보다는 오히려 연장되는 것이다."

  -[번역서 39p]-

나는 2004년에 당시 증권가를 떠들석하게 했던 N모 인터넷 회사에서 다크호스로 떠오른 한 어플리케이션을 새롭게 확장하는 P프로젝트를 수행한 적이 있다. 이 프로젝트는 (내 기억이 정확하다면) 리더 1명과 기획자 1명, 개발자 9명으로 시작되었는데 진행도중에 리더 1명이 더 추가되고 2명의 기획자, 3명의 개발자가 더 충원되었다. 이 프로젝트를 가장 괴롭혔던 문제는 구성원들간의 커뮤니케이션과 시장성에 대한 불화였는데 한번 회의가 소집되면 모여있는 모습이 강의실을 방불케했다. 한사람이 1분씩만 이야기해도 17분이 소요되었으며 합의점을 찾기가 무척 어려웠다. 결국 파트를 쪼개고 책임과 역할을 분할했지만 각 파트간의 커뮤니케이션이라는 새로운 비용이 들어갔다. 결국 이 프로젝트는 2년 가까이 지나서 접히고 말았다.  

 그 시절을 다시 되돌아 보면 우리가 커뮤니케이션 비용을 너무 많이 지불한 것이 실패요인 중 하나였다고 본다. 이로인해 서비스를 릴리즈하기 까지 많은 시간을 허비해버렸고 사용자는 우리를 기다려주지 않았다. 또 구성원들의 의견들이 다양하게 반영된 결과 무게없고 밀도가 낮은 서비스가 만들어졌다. 시장의 반응은 냉담했다. 만약 그때 커뮤니케이션 속도가 더 빠르고 효율적이었다면 일정이 더욱 단축되었을 것이다. 그리고 사용자들도 새로운 확장판 서비스를 기다리다 지치지 않았을 것이다.

 지금 생각해보면 그 프로젝트는 1명의 리더, 2명의 기획자, 8명의 개발자 정도의 규모가 적합했던 것 같다. 일정 수준 이상의 인력이 추가됨으로 인해 일정은 단축되기보다 오히려 연장되는 현상이 목격되었던 프로젝트였다. 요즘 나는 필요 이상의 인력투입을 인력부족 만큼이나 경계하고 있으며 가급적 작고 민첩한 조직을 선호하고 있다. 또 한 개발자가 자신의 역량 틀 안에서 다양한 일을 맡도록 일을 배분하려고 노력하고 있다. 이러한 시도는 자칫 업무강도가 필요이상으로 강해지는 문제를 수반할 수 있으므로 이를 뒷받침하기 위해서는 팀원 개인의 역량과 성격을 미리 파악하는 것이 필요하다. 말처럼 쉽지는 않지만 적절한 업무강도로 적절한 수의 인력을 유지한다면 일정이 늘어나는 위험을 감소시킬 수 있을 것이다.

[출처] '맨먼스 미신' 노트 (1)|작성자 태권브이


+

==두번째 글==

4장 귀족정치, 민주주의 그리고 시스템 설계

" 개념적 무결성을 이루려면 시스템에 하나의 철학이 반영되고 사용자 입장에서 본 명세는 소수의 두뇌가 고안한 것이어야 한다. "

  -[번역서 76p]-

* 개념적 무결성 * 

멋진 성당 건축물을 보며 감동과 찬탄을 자아내게하는 것은 설계의 무결성이며 소프트웨어 시스템에 있어서도 개념적 무결성이 설계에서 가장 중요하다는 것이 이 4장의 핵심이다. 브룩스가 말하는 개념적 무결성은 '사용의 쉬움' 이다. 애플의 iPod 은 다른 player 대비 모양과 작동법이 단순해서 사용하기가 쉽다. 하지만 iPod 에는 여타 Player 못지않은 다양한 기능들이 내제되어 있으며 모든 기능이 하나의 센서와 몇개의 버튼만으로 동작된다. 브룩스의 주장에 따르면 iPod 은 개념적 무결성이 설계와 구현에 잘 반영되어 있다고 할 수 있겠다.

* 무결성 성취 *

그는 개념적 무결성을 이루는 강력한 방법이 '설계' 와 '구현'을 분리하는 것이라고 말한다.  설계는 사용자의 이익을 대변하는 입장이며 개념적 무결성을 유지하기 위해서 설계자는 소수여야 한다고 주장한다. 즉, 구현과 분리된 소수의 설계자를 통해 개념적 무결성을 성취할 수 있다고 보고있다. 흥미로운 점은 공유와 협력을 강조하는 Agile approach 가 개념적 무결성을 성취하는데 용이할까 라는 의문이다. 시스템에 대한 설계를 소수 설계자의 철학과 신념에 의존하지 않고 다수의 의견과 합의에 의존했을 때 개념적 무결성을 지키기 위해서 소요되는 비용은 설득과 합의에 소요되는 마찰의 엔트로피와 시간일 것이다. 그리고 그 합의점이 과연 다수의 집단적 지능의 산물로 볼 수 있는가에도 의문이 든다. 왜냐면 다수의 합의라는 것도 결국 다수속의 강한 소수가 가진 철학이 다수를 설득한 결과라고 볼 수 있기 때문이다. 그렇다면 남는 것은 합의의 절차가 민주적이었다는 점이며, 그것이 조직에서 얼마나 가치있는 비중인지를 따져보아야 할 것이다.

* 설계와 구현 *

 "설계는 어떤 일이 일어나는지를 말해주고, 구현은 그 일이 일어나게 하려면 어떻게 되어야 하는지 말해준다"  -블라우(Gerrt A. Blaauw)-

 브룩스는 블라우('제4세대 컴퓨터' 저자)의 말을 인용하여 설계와 구현을 '시계' 에 비유하였다. 어린이라도 시계를 읽고 초침을 맞출 수 있다. 문자판, 시침, 태엽감개와 같은 단순한 구조를 통해 누구나 시계를 읽을 수 있는데 이 구조를 만드는 것이 '설계' 라고 말한다. '구현'은 이와 다르다. 시계가 그와 같이 동작하기 위해 시계속에 있는 어떤 메카니즘이 구현이라고 말한다. 인터넷 비지니스 회사의 소프트웨어 개발은 크게 '기획' 과 '개발' 로 나뉘어진다. '기획'은 사용자에게 전달되는 서비스의 기능과 동작 방식을 정의하는 행위이다. '개발' 은 '기획'의 내용을 실제 사용가능한 소프트웨어로 제작하는 행위를 말한다. '블라우'의 '시계' 에 따르자면 '기획'이 곧 '설계' 라고 볼 수 있다. 하지만 서비스 기획은 소프트웨어 개발 지식에 근간하지 않고 순수하게 사용자나 사업자의 입장에서 작성되어지므로 어떻게 개발할 것인가에 대한 부분에서 개발과의 괴리가 존재하는 것이 현실이다. 나는 이것을 극복할 수 있는 개념이 '소프트웨어 아키텍처' 라고 생각한다. 아키텍트는 '기획' 과 '개발' 사이에서 '기획'이 제시하는 개념적 무결성을 훼손하지 않고 개발이 구현할 수 있는 형태의 소프트웨어 설계를 제시하고 그것을 유지할 수 있는 역할이라고 생각한다.

* 귀족주의와 민주주의 *

 브룩스는 설계자가 소수여야 한다고 주장한다. 이 주장이 엘리트주의라는 시각에서 자유롭지 않다는 것을 인정하고 있지만 개념적 무결성을 지니려면 어쩔 수 없이 전체 개념을 통제하는 사람이 필요하다고 말한다. 이 경우 설계에 참여하지 못하는 구현자의 불만이 발생할 수 있다. 그는 구현자의 아이디어를 존중하면서도 아무리 좋은 기능이나 아이디어라도 시스템의 기본 개념과 일관성을 저해한다면 제외하는 것이 좋다고 말한다. 대신 구현은 설계와는 다른 창조적인 작업임을 강조하고 설계 만큼이나 구현자의 역할과 비중이 중요하다고 말한다. 나는 설계자와 구현자를 모두 경험해보면서 이러한 문제가 현실적으로 존재한다는 것을 깨달았다. 내가 구현자였을 때는 보다 많은 설계적 의사결정에 참여하지 못하는 것이 불만이었고, 설계자 였을 때는 구현자가 설계에 참여하면서 설계적 방향성을 훼손하지는 않을 까 걱정을 하게 되었다. 하지만 지금 돌이켜 보면 이 역할이 잘 분리되었을 때 양쪽 모두가 긍정적인 결과를 낼 수 있었던 것 같다. 다만, 무우 자르듯 설계와 구현을 분리하기 보다는 구현이 설계에 의사전달을 할 수 있는 통로를 열어놓고 공론의 장이 될 수 있도록 하는 것이 좋을 것 같다. (여기서 말하는 설계는 클래스 설계와 같이 구체적인 구현을 어떻게 할 것인가에 대한 설계가 아니라 사용자 입장에서 소프트웨어 시스템이 어떻게 동작하는가에 대한 설계이다. 개인적으로는 이것이 아키텍처 설계로 대치되는 것이 좋다고 보며, 아키텍처 설계는 사용자의 입장 뿐만 아니라 개발과 구현의 입장에서 시스템을 관조하고 구조와 방향성을 제시하는 설계라고 생각한다.)

[출처] 맨먼스 미신 정리[2]|작성자 태권브이


+

==세번째 글==

제 5장  두 번째 시스템 효과

5장은 설계자의 실수에 대한 이야기이다. 크게 두가지 실수에 대해서 이야기 하는데 첫번째가 '설계자의 독재' 이고, 두번째가 '설계자의 과도한 욕심' 이다. 둘 다 정말 현실적인 문제이지 않는가? 이러한 현실적인 문제들은 소프트웨어공학이 채워줄 수 없는 사람의 문제, 사회과학적인 문제의 영역이다. 좋은 소프트웨어를 만들기 위해서는 소프트웨어공학적 노력과 함께 '사람' 문제에 접근하는 노력도 동시에 필요하다. 나는 지난 10년간 실패한 프로젝트를 다수 수행한 경험을 갖고 있는데, 대부분 공학적이거나 기술적인 한계보다는 '사람'의 문제로 인한 유기적 한계가 더욱 무섭고 치명적인 독이 되었다는 점을 부인할 수 없다. 오늘은 그 '사람'의 문제중에서 '설계자' 의 문제점이 무엇인지 브룩스의 텍스트와 함께 이야기 해 보고자 한다.

 

"구축 담당자가 구현에 대하여 발명적이고 창조적인 책임을 지고 있다는 것을 기억하여야 한다. 즉, 설계자는 구현작업에 대하여 독재자 노릇을 하는 것이 아니라, 단지 제안하는 역할이라는 점을 기억해야 한다." 

-번역서 80p-

1. 설계자의 지위

 대중들에게 설계자라는 말은 왠지 개발자보다 레벨이 높고, 높은 지위에 있으며 개발자들을 지휘하는 듯한 늬앙스를 갖고 있는게 사실상 통념이다.  이런 통념이 왜 가능한 것일까? 그 것은 개발자로서 경력을 쌓은 다음에야 설계자가 될 수 있다는 생각에 기인한다고 볼 수 있다. 생각해보자. 오늘날의 개발자가 그런 경력이 없는 설계자를 믿고 따를 수 있을까? 개발을 해본 적이 없지만 소프트웨어 설계를 전문적으로 배운 사람을 오늘날의 현업에서 개발자들이 인정하고 받아들일 수 있는가? 답은 No 이다. 아직 현실적으로 받아들이기 힘들다. 따라서 설계자는 개발자들 보다 높은 레벨이라는 통념에서 벋어날 수 없는 것이다.

2. 독재적 설계

 위 브룩스의 말을 좀 더 적나라게 표현하자면  "설계자는 개발자를 무시하지 마라. 설계는 개발자들에게 하는 제안일 뿐이다." 와 같다. 어느 개발자라도 시키는데로 코드만 작성하는 일을 좋아하지는 않는다. 그것은 마치 단순작업처럼 반복되는 루틴이라서 지루하고 따분한 작업이다. 개발자들은 창조적이고 도전적인 작업을 좋아한다. 적어도 아직까지는 그렇다. 이런 성향의 개발자가 다수인 현실에서 설계자가 개발자에게 '이러 이러하게 설계 했으니 이렇게 코딩해주세요' 라고 말하는 것은 장작불에 휘발유 뿌리는 격이나 다를 바 없다. 그러한 요청은 부탁이 된다 하더라도 개발자를 기분나쁘게 하고 사기를 바닥에 떨어뜨린다. 그런데 이것은 유기적인 문제이기도하다. 쉽게말해 설계자와 개발자가 인간적으로 친밀하고 유대가 있으면 큰 문제가 안되기 때문이다. 그리고 설계자와 개발자의 기술적 격차가 클 때에도 문제가 안된다. 이 경우 개발자는 배우는 입장이기 때문에 큰 마찰없이 설계를 편안하게 받아들이기 때문이다. 하지만 안타깝게도 모든 설계자가(설계 역할을 하는이가) 인간적으로 좋은 성품을 가지고 모든 개발자와 좋은 인간관계를 유지할 수는 없다. 또 아무리 뛰어난 설계자라도 개발자와의 기술적 격차가 항상 월등할 수는 없는 법이다. 그래서 설계는 '제안' 이 되어야 한다. 제안이라는 것은 강요가 아니다. 제안을 받은 개발자는 그 설계를 받아들일 수도, 자신의 설계를 덛붙일 수도, 혹은 거부할 수도 있다. 그렇다면 오히려 설계가 문제가 된다. 설계자는 '제안' 이라는 느슨한 수단만을 가지고 어떻게 전체 시스템에 대한 일관된 설계를 유지할 수 있는가? 내가 생각하는 해법은 두가지다. 첫째, 설계를 잘개 쪼개어 권한을 분산시키는 것이고. 둘째, 설계의 적용을 점진적으로 확대하는 것이다.

 첫번째. 한 시스템의 설계를 통으로 유지하는 것은 보기에는 직관적일지 몰라도 현실적으로 그 설계를 관철시키기에는 많은 저항이 따르기 마련이다. 그 설계의 완성도를 떠나서 개발자(구현자)와의 마찰을 극복하는 것이 문제가 된다. 한 통으로 된 설계가 견고하면 견고할 수록 마찰은 커진다. 그리고 그 마찰은 유기적 문제, 이른바 설계자와 개발자 사이이의 불화로 옮겨붙어 프로젝트는 걷잡을 수 없이 리스키해진다. 이 마찰은 덩어리가 크면 클 수록 집중적으로 분명하게 나타나서 해결하기가 힘들지만, 작은 조각으로 나뉘어지면 극복하기가 용이하고 전체적으로 하나의 문제로 보여지지 않기 때문에 마찰력은 희석된다. 한 시스템에 대한 설계를 하나의 통으로 유지하기 보다는 설계의 철학이 잘 반영된 느슨하고 추상적인 상위의 설계만 유지하면서 세부적이고 개발에 직접적인 영향력이 미치는 설계들은 요구사항별, 이슈별, 문제별, 모듈별 등등의 단위별로 쪼개어 충분히 단순한 상태에서 '제안' 되면 설사 마찰이 있다고 하더라도 규모가 작아서 극복하기가 용이해진다.

 두번째로 설계의 적용을 점진적으로 확대하는 것을 고려해볼 수 있다. 설계자들끼리 모여서 수개월동안 밀실에서 설계를 완성한 뒤 짠~ 하고 개발자들에게 들이밀게 된다면 설령 그것이 '제안' 이 된다고 하더라도 개발자들에게 받아들여지기는 힘들다. 일단, 설계에 대한 이해를 하는데 많은 에너지가 소모되기 때문에 시간과 비용이 소모될 뿐만 아니라 설계자의 생각을 개발자가 일방적으로 이해해야하는 분량이 많아서 심적 거부감이 커지게된다. 그리고 그 거부감은 필연적으로 유기적인 문제로 전이되어 인간적인 불화를 일으켜 프로젝트를 위험에 빠뜨린다. 따라서 한방에 설계를 공개하기 보다는 설계의 철학과 방향성을 세운뒤 청사진을 공유하는 것을 시작으로 개발자와 설계 공유를 시작하는 것이 좋다. 설령 설계자가 그리고 있는 구체적인 그림이 뚜렷하다고 하더라도 처음에는 추상적이고 상위적인 그림부터 공유하고 제안하는 것이 좋다. 그 다음 점진적으로 구체적인 설계로 옮겨간다. 그리고 그 과정중에는 항상 개발자와 공유를 해서 개발자의 의견을 반영하는 방법으로 마찰을 점진적으로 극복한다. 그렇게 함으로써 개발자는 자연스럽게 설계의 철학을 이해하고 거부감을 줄이게 되어 점점 구체화 되는 설계 '제안' 에 대해 받아들 수 있는 마음의 여유를 갖게된다.

 오늘날 현실적으로 볼 때 설계자는 개발자보다 높은 레벨이라는 통념이 있다. 그렇기 때문에 개발자 입장에서는 설계자의 설계를 일방적으로 구현해야 한다는 피해의식을 가지지 않을 수 없다. 이 문제는 소프트웨어 공학적 문제가 아닌 인간의 유기적인 문제로 나타나게 되며 프로젝트를 위험하게 만드는 요인이 된다. 이를 극복하기 위해서 브룩스는 설계는 '제안' 이 되어야 한다고 주장한다. 그런데 '제안'하는 방식은 도리어 일관된 설계를 유지하기 힘든 문제를 야기할 수 있는데 그것을 극복하는 방법으로 '설계를 잘개 쪼개어 권한을 분산시키는 방법' 과 '설계의 적용을 점진적으로 확대하는 방법' 을 소개하였다.

[출처] 맨먼스미신 정리[3]|작성자 태권브이