어느 회사에서 세 팀이 함께 프로그램 하나를 만들었더니, 완성된 프로그램이 정확히 세 덩어리로 나뉘어 있었다는 이야기가 있습니다. 누가 그렇게 하자고 정한 것도 아닌데, 팀이 나뉜 모양이 그대로 소프트웨어의 모양이 된 것입니다.

이처럼 시스템을 설계하는 조직의 소통 구조가 그 시스템의 구조에 그대로 비친다는 관찰을 ‘콘웨이의 법칙(Conway’s Law)’이라고 부릅니다. 개발자들 사이에서는 “조직도를 보면 소프트웨어 구조가 보인다”는 말로도 자주 인용됩니다.

본 자료에서는 콘웨이의 법칙이 어디에서 나왔는지, 왜 이런 일이 생기는지, 실제로 어떤 모습으로 나타나는지, 그리고 이 법칙을 거꾸로 활용하는 방법까지 차례로 살펴보겠습니다.

콘웨이의 법칙의 이해

콘웨이의 법칙은 어디에서 나왔을까

이 법칙의 이름은 미국의 컴퓨터 과학자 멜빈 콘웨이(Melvin Conway)에게서 왔습니다. 그는 1967년 「위원회는 어떻게 발명하는가(How Do Committees Invent?)」라는 글을 썼고, 이 글은 한 경영 잡지에서 실리지 못한 뒤 1968년 컴퓨터 잡지 「데이터메이션(Datamation)」에 실렸습니다.

콘웨이는 글에서 “시스템을 설계하는 조직은 그 조직의 소통 구조를 그대로 본뜬 설계를 만들어 낼 수밖에 없다”고 주장했습니다. 여기서 시스템은 소프트웨어만이 아니라 사람들이 함께 설계하는 모든 것을 넓게 가리켰습니다.

이 생각을 ‘콘웨이의 법칙’이라는 이름으로 널리 알린 사람은 프레더릭 브룩스(Frederick Brooks)였습니다. 그는 1975년 소프트웨어 개발 고전으로 꼽히는 책 「맨먼스 미신(The Mythical Man-Month)」에서 이 관찰을 소개했고, 그 뒤로 콘웨이의 법칙은 개발 현장의 상식처럼 자리 잡았습니다.

왜 조직의 모양이 설계에 비칠까

큰 시스템은 한 사람이 혼자 만들 수 없기 때문에 여러 사람과 팀이 일을 나누어 맡습니다. 일을 나누면 각 부분이 서로 맞물리는 지점, 곧 연결부를 정해야 하고, 이 연결부를 정하려면 담당자들이 서로 이야기를 나누어야 합니다.

그런데 사람 사이의 대화는 아무 데서나 똑같이 일어나지 않습니다. 같은 팀 안에서는 수시로 묻고 고칠 수 있지만, 다른 팀이나 다른 부서와는 회의를 잡고 문서를 주고받아야 합니다. 그래서 대화가 쉬운 곳은 하나로 단단히 묶이고, 대화가 어려운 곳은 딱딱한 경계로 갈라지게 됩니다.

결국 시스템의 경계선은 기술적으로 가장 알맞은 자리보다 사람들이 소통하기 편한 자리를 따라 그어지기 쉽습니다. 콘웨이의 법칙은 설계자의 의지가 부족해서 생기는 문제가 아니라, 함께 일하는 방식이 만들어 내는 자연스러운 결과에 가깝습니다.

시간이 지나면 이 경계는 더 단단해집니다. 한번 나뉜 부분마다 담당 팀이 생기고, 팀마다 자기 몫을 지키려 하다 보니 구조를 바꾸려면 조직까지 함께 바꿔야 하는 상황이 됩니다. 그래서 오래된 시스템일수록 그 회사가 걸어온 조직 개편의 흔적이 화석처럼 남아 있다는 말이 나옵니다.

콘웨이의 법칙이 드러나는 모습

흔한 예로 회사 웹사이트를 들 수 있습니다. 방문자는 한 회사의 사이트를 본다고 생각하지만, 메뉴를 옮겨 다니면 부서마다 디자인과 말투가 제각각인 경우가 많습니다. 사이트가 고객의 필요가 아니라 회사 안의 부서 구분에 맞춰 짜였기 때문입니다.

여러 회사가 함께 참여하는 큰 사업에서도 비슷한 일이 생깁니다. 업체마다 맡은 부분을 따로 만들다 보면 각 부분은 잘 돌아가는데, 서로 이어지는 곳에서 자료 형식이 맞지 않거나 같은 기능이 두 번 만들어지는 문제가 자주 드러납니다. 경계가 많을수록 그 틈을 메우는 데 드는 시간과 비용도 함께 늘어납니다.

이 법칙은 연구로도 확인되었습니다. 2012년 미국 하버드 경영대학원 연구진은 같은 기능을 하는 소프트웨어들을 비교해, 긴밀하게 모여 일하는 회사 팀이 만든 제품보다 여러 곳에 흩어진 오픈소스 개발자들이 만든 제품이 더 잘게 나뉜 구조를 보인다는 결과를 내놓았습니다. 연구진은 이를 조직과 제품이 서로를 닮는다는 ‘거울 가설’의 근거로 보았습니다.

콘웨이의 법칙을 거꾸로 활용하기

콘웨이의 법칙을 피할 수 없다면, 오히려 원하는 설계에 맞춰 조직을 먼저 짜는 방법도 있습니다. 이를 ‘역콘웨이 전략(Inverse Conway Maneuver)’이라고 부르며, 2010년대 들어 소프트웨어 업계에서 널리 이야기되었습니다.

예를 들어 서비스를 작은 독립 단위로 나누고 싶다면, 각 단위를 처음부터 끝까지 책임지는 작은 팀을 따로 꾸리는 식입니다. 아마존이 피자 두 판으로 식사를 해결할 수 있을 만큼 작은 팀을 강조했다는 이야기도 이런 생각과 맞닿아 있습니다.

다만 조직을 바꾼다고 모든 문제가 저절로 풀리지는 않습니다. 팀을 너무 잘게 나누면 팀 사이의 조율이 오히려 늘어날 수 있으므로, 시스템의 구조와 사람의 구조를 함께 놓고 꾸준히 점검하는 태도가 필요합니다.

콘웨이의 법칙은 기술의 문제처럼 보이는 일 뒤에 사람의 문제가 숨어 있다는 사실을 일깨워 줍니다. 좋은 시스템을 만들고 싶다면 코드만이 아니라 그 코드를 만드는 사람들이 어떻게 대화하는지부터 살펴보아야 합니다.

우리가 함께 일하는 모습을 먼저 돌아보는 것, 그것이 더 나은 시스템을 만드는 일의 첫걸음입니다.