콘웨이의 법칙

같은 자리에서 같은 종류의 문제가 되풀이되는데 원인을 짚지 못하는 상황이 있습니다. 결제와 알림이 맞물리는 지점에서만 버그가 반복되고, 담당자를 바꿔도 다음 분기에 비슷한 장애가 또 납니다. 코드 품질이나 개인 역량으로 설명하려 들면 답이 나오지 않습니다. 그 자리를 거쳐 간 사람이 이미 셋인데 증상은 그대로이기 때문입니다.

페이지덱에서도 결제 실패 알림이 늦게 나가는 문제가 1년 넘게 이어졌습니다. 결제는 한 팀이, 알림은 다른 팀이 맡고 있었습니다. 두 팀 모두 자기 쪽 코드는 깔끔하게 유지했지만 둘을 잇는 부분은 어느 팀의 일도 아니었습니다. 태오가 원인을 정리하다가 알아차린 것은, 시스템이 끊기는 자리가 팀이 갈라진 자리와 정확히 겹친다는 사실이었습니다.

1967년에 멜빈 콘웨이가 논문에서 같은 관찰을 내놓았습니다. 시스템을 설계하는 조직은 그 조직의 소통 구조를 그대로 옮긴 설계를 내놓는다는 것입니다. 이 문장이 쓸모 있는 이유는 원인을 사람에서 구조로 옮겨 놓기 때문입니다. 누가 실수했는지를 묻는 대신 어디에 경계가 그어져 있는지를 묻게 만듭니다.

두 부분이 맞물리려면 그 부분을 맡은 사람들이 말을 맞춰야 하고, 말을 맞추기 어려운 곳에는 설계상의 경계가 생깁니다. 이 흐름이 세 단계로 굳어집니다.

1. 소통 비용이 자리마다 다릅니다. 옆자리 동료와는 30초면 합의가 끝나지만 다른 팀에 걸친 일은 회의를 잡고 일정을 조율해야 합니다. 팀 경계를 넘는 대화는 같은 내용이라도 며칠이 듭니다.
2. 설계는 소통이 가능한 범위 안에서만 나옵니다. 매일 말을 섞는 사람들끼리는 서로의 코드를 깊이 얽어 짜도 굴러갑니다. 반대로 대화가 드문 쪽과는 자잘한 조율이 필요 없도록 API처럼 규격을 정해 놓고 그 너머를 들여다보지 않는 쪽을 택합니다. 규격은 두 프로그램이 주고받기로 약속한 창구를 뜻합니다.
3. 그래서 남는 구조가 조직도를 닮습니다. 팀이 넷이면 크게 네 덩어리로 갈리고, 팀 사이가 먼 쪽일수록 연결이 성기고 이음매가 약합니다.

여기서 나오는 실무적 결론이 하나 있습니다. 원하는 시스템 구조가 있으면 조직을 먼저 그 모양으로 만들라는 것입니다. 기능별로 따로 배포하는 구조를 원하면서 한 팀이 전부를 맡고 있으면 경계가 흐려지고, 반대로 팀을 먼저 갈라 두면 경계가 자연히 선명해집니다. 이 접근을 역콘웨이 전략이라 부릅니다.

뒤집어 읽으면 진단 도구가 됩니다. 시스템에 설명되지 않는 이음매가 있으면 그 자리에 예전 조직도가 남아 있을 가능성이 높습니다. 2년 전에 합쳐진 두 팀의 경계가 코드에는 그대로 남아 있는 경우가 그렇습니다. 새로 들어온 사람이 "이 둘은 왜 따로 있죠" 하고 물었을 때 아무도 기술적인 이유를 대지 못한다면 답은 대개 옛 조직도에 있습니다.

가장 자주 인용되는 자리는 구조를 갈아엎는 논의입니다. 마이크로서비스로 옮기자는 제안이 나오면 반드시 따라붙습니다. 기능별로 쪼개 따로 배포하는 이 구조는 팀이 그만큼 나뉘어 각자 책임지고 있을 때만 유지됩니다. 조직은 그대로 둔 채 코드만 열 조각으로 나누면, 배포는 열 번 해야 하는데 결정은 여전히 한 회의에서 나는 상태가 됩니다.

조직 구조를 손볼 때도 같은 무게로 다뤄집니다. 직군별로 묶인 조직을 제품별 교차 기능 팀으로 재편하면 시스템도 그 방향으로 서서히 끌려갑니다. 그래서 조직 개편은 기술 결정이기도 합니다. 누가 누구에게 보고하는지를 정하는 회의에서 반년 뒤 시스템이 어느 선을 따라 갈라질지가 함께 정해집니다.

진단에도 씁니다. 일정이 늘 같은 지점에서 밀린다면 원인이 담당자의 실력이 아니라 조직을 가른 선에 있을 수 있습니다. 두 팀이 매번 서로를 기다리는 블로커가 반복된다면 처방은 사람을 바꾸는 쪽이 아니라 두 기능을 한 팀으로 합치거나 둘 사이에 합의된 규격을 두는 쪽입니다.

"지금 조직 그대로 마이크로서비스로 가면 분산 모놀리스만 됩니다."

코드는 나뉘었는데 팀이 안 나뉘어 결국 하나처럼 묶여 돌아가는 상태를 경고하는 말입니다.

"이건 콘웨이의 법칙이에요. 저 이음매가 옛날 팀 경계입니다."

기술적으로 이상해 보이는 설계가 조직의 흔적이라는 설명입니다.

"이번 개편은 아키텍처 결정이기도 합니다."

팀을 나누는 선이 나중에 시스템의 경계가 된다는 뜻입니다.

페이지덱이 결제 알림 문제를 푼 방식도 여기서 나왔습니다. 태오와 지현은 담당자를 교체하는 대신 두 가지를 놓고 골랐습니다. 결제와 알림을 한 팀으로 합칠지, 아니면 둘 사이에 규격을 정해 두고 어느 쪽이 무엇을 책임지는지 문서로 못 박을지였습니다.

선택은 후자였습니다. 두 팀을 합치기에는 다루는 도메인이 너무 달랐기 때문입니다. 대신 결제 쪽이 알림에 넘기는 정보의 형식과 시점을 규격으로 고정하고 그 규격의 주인을 한 사람으로 정했습니다. 반년 뒤 같은 종류의 장애는 나오지 않았습니다.

조직을 바꾸면 코드가 따라 바뀐다고 읽는 경우가 많습니다. 법칙이 조직과 구조를 이어 주니 조직 쪽 손잡이를 돌리면 반대쪽이 움직일 것처럼 보입니다. 하지만 이 관찰이 말하는 것은 앞으로 만들어질 설계가 지금의 소통 구조를 닮는다는 것이지, 이미 쓰여 있는 코드가 저절로 재배치된다는 것이 아닙니다. 팀을 나눠 놓고 코드를 옮기는 작업을 따로 잡지 않으면, 새 팀 셋이 여전히 같은 덩어리를 함께 건드리면서 충돌만 늘어납니다.

법칙이라는 말 때문에 예외 없는 규칙으로 읽는 것도 흔합니다. 콘웨이가 내놓은 것은 오래 관찰된 경향이지 실험으로 증명된 공식이 아닙니다. 의식적으로 거스르는 팀도 있습니다. 다만 거스르려면 팀 경계를 넘는 소통에 의도적으로 비용을 들여야 합니다. 두 팀이 매주 같은 자리에 앉아 설계를 맞추는 식인데, 그 노력을 멈추면 구조는 다시 조직도 쪽으로 돌아갑니다. 같은 갈래인 브룩스의 법칙이 사람을 더해 일정을 당기려는 시도를 막아 세우듯, 이쪽도 손대지 않아도 되는 자리를 알려 주는 역할을 합니다.