Conway’s law (콘 웨이의 법칙)
If you have four groups working on a compiler, you’ll get a 4-pass compiler
당신이 하나의 컴파일를 만들기 위해 4개의 팀을 만든다면, 당신은 4단계(four-pass) 컴파일러를 얻을 것이다.
이 말은 시스템의 구조는 시스템을 설계한 조직의 구조(형태)를 그대로 반영한다는 것입니다. 보면 볼수록 묘한 감정과 예전 기억들이 떠오르는 법칙입니다.
성공적인 회사생활을 하기 위해서는 순수한 개발 능력외에 많은 변수들이 우리를 따라 다닙니다.
- 사내 정치에 승리하기 위한 명분 만들기
- 서로간의 책임을 회피하기 위한 일 덜 가져오기
- 영업 / 기획 / 개발 부서 간의 대화 단절
- 직급 문화가 가져오는 대화의 단절 (상명하복의 의사 전달)
등등 복잡한 문제가 아주 많을 겁니다. 물론 이러한 변수를 전혀 신경쓰지 않는 회사도 있겠죠 ^^ .. 하지만 이러한 문제는 큰 조직일수록 더 합니다.
만약 여러분의 조직이 이러한 문제들을 가지고 있다면 과연 좋은 소프트웨어를 만들수 있을까요? 우리나라는 특히 소프트웨어를 제조업/건설업에서 많은 프로세스/관리 방식등에서 가져왔기 때문에. 사람이 많아지면 더 좋은 소프트웨어를 만들수 있을거라는 양적인 접근으로 해결하는 경우가 아주 많습니다.
이러한 양적인 접근 방식으로는 좋은 소프트웨어를 더 만들기 어려우며 사람과 조직이 많아질수록, 더 많은 단계와 복잡한 프로세스가 생기는 함정을 만들게 됩니다. 오히려 팀간의 정치로 인해 더 복잡한 구조를 가진 Software가 만들어질 확률이 높아진다는 것입니다.
거기다 같은 팀의 개발자간에 쉽게 대화를 나눌수 있고, 협력, Pair Programing 할수 있는 환경이 주어지지 않는다면, 팀 내부에서도 서로 간의 책임 소지를 따지며, 통일성 있는 모델 기반의 모듈(라이브러리)조차 구성하기 힘들게 됩니다.
이 시나리오가 과연 몇몇 회사에만 적용될까요? ….. 전 대부분이 아닐까 생각이 듭니다.
이런 상황에서 Architect가 자라난다는 것은 불가능하지 않을까요? Architect는 끊임없는 학습 역시 중요하지만 도메인, 플랫폼 특화된 지식에도 밝아야 합니다. 하지만 책임을 따지며 소극적인 일을 할수 밖에 없는 문화에 있는 우리에게는 너무나 먼 애기로 느껴집니다.
Conway의 해결책 - Clean State Approach
Conway는 “Clean State” 접근법 이라 명하고 이러한 문제의 해결책을 4단계로 제시했습니다.
- Define the business mission (비지니스 미션을 정의해라)
- Learn the business processes from business owners (비지니스 오너로 부터 비지니스 프로세스를 배워라)
- Re-engineer these business processes to fit the mission; (미션에 맞게 비지니스 프로세스들을 재구성해라)
- Structure the IT organization to support the reengineered business processes. (재구성된 비지니스 프로세스를 지원하기 위한 IT 조직을 구성해라)
자 이 접근법을 읽고 우리는 한가지의 교훈을 다시 배우게 됩니다.
결국 윗사람이 비지니스 목적에 맞게 조직의 구성에 대해서 염려하고 구성을 해야만 비로서 합리적인 Software Architecture가 나올수 있는 기본환경이 조성될수 있다. 라는 것을요.
그 다음 사내정치에서는 기술,능력, 합리라는 명분이 가장 최우선이 되는 문화가 될때 비로서 Business Owner가 생각하는 Software에 적합한 Architecture가 나올 수 있다는 것입니다.
결론은 우리가 할수 있는 일은 매우 적다는 것이고, 정치에 희생당하지 않게 최대한 노력하는 것이라고 보입니다.
우리나라에서는 그리 유효한 방법은 아닌거 같네요 ^^.
조언..
부족하지만 도움이 되길 바라며, 회사 생활에 도움이 될 만한 책을 하나 소개시켜 드리도록 하겠습니다.
만약 여러분의 회사에 팀원들이 계속나간다면 윗분들에게 이 책을 추천해 주길 바랍니다. 윗분들은 제목을 보고 혹 하고 읽으실 수 밖에 없을 겁니다 .
이 책은 똑똑한 개발자를 뽑는 방법을 알려줌과 동시에
반대적으로 좋은 개발 엔지니어를 뽑기위해서
회사의 환경을 어떻게 구축해야 되는지 좋은 조언을 해주는
책입니다. 제가 노리는 것이 바로 이것입니다.
아마 이 책을 통해 윗분들이 회사에 조금이라도 변화를 가져와 준다면 매우 기쁜일이 아닐까 생각이 드네요.
비판만 하다가 끝나기 보다는 결국 나와 다른 사람( 윗분)들을 변화시키지 않으면.. 바뀌는 것이 없다는 진리를 깨닫고 조금씩 실천해 나가시지 않을렵니까?
전 이책의 역자도 아니며, 이 책의 출판사와 아무런 인연도 없으니 ^^;; 오해 마시길 바랍니다. 단지 좀더 나은 여러분의 회사 생활을 바랄 뿐입니다…
출처 :http://arload.wordpress.com/2008/05/07/politicsswarchitecture/
'소프트웨어 > 실용주의 프로그래머' 카테고리의 다른 글
| 강승식 교수의 형태소분석기를 Python에서 활용하기 (1) | 2008.07.30 |
|---|---|
| 오픈소스 Lucene을 활용한 DB Full-text 검색엔진 개발 (0) | 2008.07.30 |
| 슬라이드 공유 사이트 (0) | 2008.07.01 |
| 뉴욕의 프로그래머 ★★★★ (0) | 2008.06.25 |
| 아무도 가르쳐 주지 않는 ‘구글’의 5가지 비밀 (0) | 2008.06.24 |