소프트웨어 개발자 김수보님의 글을 모비인사이드에서 소개합니다.
시스템은 조직의 모습을 반영한다.
(내용=위키피디아) 1968년 멜빈 콘웨이는 “모듈 프로그래밍 국제 심포지움”에 가서 논문을 하나 발표합니다. 그 핵심 내용이 이렇습니다. (논문은 1967년에 작성)
“모든 시스템은 그 조직의 의사소통 구조와 동일하게 만들어진다.”
“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”
(논문 요약) 이 법칙은 소프트웨어 모듈이 제대로 동작하려면 개발자들이 서로 자주 대화해야 한다는 사실에 기인한다. 결과적으로 소프트웨어의 인터페이스 구조가 그 조직의 사회적 경계선들을 반영하게 된다는 것. 그리고 그 경계선을 넘으면 소통은 매우 힘들어게 된다.
멜번 콘웨이는 당시 컴퓨터 과학자였는데 컴파일러를 개발하던 분이었습니다. UNISYS 전신 어셈블러를 개발했습니다. 맥파스칼의 전신도 개발합니다. MUMPS라는 의료용 언어도 만들었습니다. 쉽게 말하면, 이 분은 유물 중의 유물, 레전드 오브 레전드, 만랩 중의 만랩인 개발자입니다.
1968년은 실리콘밸리에서 대형 컴퓨터 수요가 높아지던 시기였습니다. 투자가 몰리면서 인텔이 설립되기도 한 해입니다. “멜빈”은 컴퓨터 과학자로 일하면서 컴퓨터가 만들어질 때 “조직의 의사결정구조”를 반영한다는 것을 알게 되었습니다.
그가 이 법칙을 만든 것은 “효율적인 작업”을 위해서 “유연한 조직구조”가 필요하다는 것을 주장하기 위해서였습니다. 참고로 1967년에는 C.J 미들튼이 “프로젝트 조직 셋업하기”라는 논문을 내기도 했습니다. 요즘으로 치면 “프로젝트학 개론” 정도. 즉, 당시 멜빈 뿐 아니라 많은 과학자들이 경직된 조직구조 때문에 꽤 고생했음을 짐작할 수 있습니다.
소프트웨어도 마찬가지.
지금은 “소프트웨어 시스템” 이야기입니다. 당시 “하드웨어”가 하는 일을 지금은 “소프트웨어”가 하니까요. 본질도 크게 다르지 않습니다. 좀 더 빨라지고 유연해졌을 뿐.
논문 제목은 “How do committees invent?“입니다. Committee. 요즘으로는 “프로젝트 팀” 정도 됩니다. 그런데 1968년이면 IT 역사에서 청동기 시대입니다. 트랜지스터가 진공관을 한창 대체하던 시대. 이전에 없던 물건을 만들기 위해 “사람”을 모으고, 만들어진 “모든” 것이 “발명”이던 시기였습니다. 그래서, “어떻게 일을 할 것인가?”에 대한 고민도 “처음”이던 시절이었습니다.
이 “법칙”은 소프트웨어 시스템이 “태생적”으로 “공학”을 벗어나, 회사의 “조직구조”나 “개발문화”와도 밀접하다는 것을 증명하고 있습니다. 참고로 “개발문화”란, 개발팀에 국한된 이야기가 아닙니다. 사업적 의사결정과 기술 투자, 일정수립과 성과관리를 어떻게 할 지 모든 것을 일컫는 말입니다.
“프로그래밍”은 공학의 영역입니다. 하지만, “개발”은 인문학의 영역입니다. “비즈니스”를 이해하지 못하면 굉장히 엉뚱한 것을 개발할 수 있습니다. 그리고, “시스템의 획득과 운영”은 경영의 영역입니다. 물론 순수 경영이 아닌 “IT 경영”입니다. IT 경영? 산업현장에서는 이미 하고 있지만, 아직 “학문적으로는” 없습니다. 그래서 가르치는 곳도 없습니다. 사례를 통해서 학습할 뿐. IT 분야의 정책은 더더욱 그렇습니다.
[IT의 중심에서] 시리즈
– (9) 스타트업 개발자
– (8) 개발자 역할의 변화
– (7) 스타트업, 서비스 개발자가 되자
– (6) 페이스북은 어떻게 성장했을까
– (5) 유니콘 기업들의 핵심 경쟁력, 채용전략
[fbcomments url=”http://ec2-13-125-22-250.ap-northeast-2.compute.amazonaws.com/2017/09/14/subokim-conways-law/” width=”100%” count=”off” num=”5″ countmsg=”wonderful comments!”]
