콘웨이의 법칙, 시스템은 조직을 닮는다.

01. 시스템은 조직의 모습을 반영한다.

1968년, 멜빈 콘웨이가 논문 하나를 발표합니다.
“모듈 프로그래밍”이라는 국제 심포지움에서였죠.

핵심내용은 이렇습니다.

“모든 시스템은 그 조직의 의사소통 구조와 동일하게 만들어진다.”

"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 미들튼”의 “프로젝트 조직 셋업하기”

요즘으로 치면 “프로젝트학 개론” 정도 아닐까요?
즉, 당시에는 멜빈 뿐 아니라 많은 과학자들이 조직 때문에 고생했음을 알 수 있습니다.

02. 소프트웨어도 마찬가지.

지금은 “소프트웨어 시스템” 이야기입니다.
당시 “하드웨어”가 하는 일을 지금은 “소프트웨어”가 하니까요.
본질도 크게 다르지 않습니다.
좀 더 빨라지고 유연해졌을 뿐.

논문 제목은 이렇습니다.

“How do committees invent?“. – 위원회는 어떻게 발명을 하는가?

Committee…
의역하면 “프로젝트 의사결정팀”, “팀장 모임” 정도 됩니다.

1968년이면 IT 역사에선 청동기시대쯤 됩니다.
트랜지스터가 진공관을 한창 대체하던 시대였죠.
이전에 없던 물건을 만들기 위해 “사람”을 모으고,
만들어진 모든 것이 “발명”이던 시기였습니다.

“어떻게 일을 할 것인가?”

이런 고민조차 “처음”이던 시절이었습니다.

이 법칙은 “소프트웨어 시스템”이 “태생적”으로 “공학”을 벗어나,
회사의 “조직구조”나 “개발문화”와도 밀접하다는 걸 증명하고 있습니다.

참고로 “개발문화”란, 개발팀에 국한된 이야기가 아닙니다.
사업적 의사결정과 기술 투자, 일정수립과  성과관리를 어떻게 할지 모든 걸 일컫는 말입니다.

“프로그래밍”은 공학의 영역입니다.
하지만, “개발”은 인문학의 영역입니다.
“비즈니스”를 이해하지 못하면 굉장히 엉뚱한 걸 개발하게 됩니다.

“시스템의 획득과 운영”은 경영의 영역입니다.
물론 순수 경영이 아닌 “IT 경영”입니다.

IT 경영? 산업현장에서는 이미 하고 있지만, 아직 “학문적으로는” 없습니다.
그래서 가르치는 곳도 없습니다.
사례를 통해서 학습할 뿐.
IT 분야의 정책은 더더욱 그렇습니다.

03. 시사점

• 시스템은 비즈니스와 그 조직의 역사를 간직한다.
• 모든 상황을 만족시키는 하나의 시스템은 없다.
  비즈니스에 잘 맞는 시스템을 만들자.
• 천년만년 변하지 않는 시스템은 없다.
  비즈니스가 변하면 적절히 재개발할 수 있도록 미리 블럭을 잘 나누자.

끝.