콘웨이의 법칙 — 조직에서 출발하면 조직을 닮습니다

이론과 현장 - 1

시스템을 여러 개 쓰는 회사에서 자주 보는 모습이 있습니다.
시스템 경계가 부서 경계와 똑같습니다. 연구가 쓰는 것, 품질이 쓰는 것, 생산이 쓰는 것이 따로 있습니다. 그리고 그 사이는 사람이 옮겨 적습니다.
우연이 아닙니다. 조직에서 출발해서 만들었기 때문입니다.
이 글은 왜 그렇게 되는지, 그리고 어디서 출발해야 하는지에 대한 이야기입니다.

콘웨이의 법칙

1968년에 멜빈 콘웨이가 쓴 문장이 있습니다.

소프트웨어 쪽에서 오래 인용되어 온 말입니다. 부서가 셋이면 시스템도 세 덩어리가 되고, 그 사이에 부서 간 회의가 있으면 시스템 사이에도 인터페이스가 생긴다는 것입니다.

의도해서 그렇게 되는 것이 아닙니다. 각 부서에 요구사항을 받아 만들면 자연히 그렇게 됩니다.

왜 트랜잭션 업무부터 시스템이 되었나

여기서 오래 묵은 질문 하나가 풀립니다.

지금까지 시스템화가 잘 된 영역이 있습니다. 회계, 구매, 급여, 재고. 모두 트랜잭션 업무입니다.

트랜잭션 업무(Transaction)는 정해진 규정과 절차대로 처리하면 되는 일입니다. 계약이 체결되면 계약을 기록하고, 지급이 일어나면 지급을 기록합니다. 무엇을 할지 판단할 여지가 적습니다.

그리고 잘 안 된 영역이 있습니다. 어느 방향으로 갈지, 무엇을 접을지, 지금 무엇이 막혀 있는지.

흔히 기술 문제로 설명합니다. 정형 데이터는 담기 쉽고 비정형은 어렵다고요. 그런데 그것만이 아닙니다.

트랜잭션 업무는 부서 안에서 닫힙니다

계약을 기록하는 일은 한 부서 안에서 시작해서 끝납니다. 다른 부서와 소통 구조를 새로 만들 필요가 없습니다.

그래서 조직을 안 건드려도 시스템이 됐습니다. 콘웨이의 법칙이 문제가 되지 않았습니다. 부서별로 만들어도 부서별로 완결됐기 때문입니다.

전략과 프로젝트는 회사 전체에 걸립니다

판단이 필요한 일은 범위가 다릅니다.

어느 기술로 갈지, 어느 과제에 자원을 더 넣을지, 무엇을 접을지. 이건 한 부서의 일이 아니라 회사가 어디로 갈지를 정하는 일입니다.

그리고 되돌리기 어렵습니다.

계약 하나를 잘못 기록하면 그 건을 고치면 됩니다. 어느 과제를 계속할지 잘못 정하면 몇 년이 걸립니다.

그런데 영향이 큰 쪽이 시스템에 안 담겨 있습니다. 규정대로 처리하면 되는 일은 다 담겼는데요.

왜 그랬을까요

판단은 여러 부서를 오갑니다.

연구가 제안하고, 영업이 고객사 요구를 전하고, 품질이 검토하고, 경영진이 정합니다.

그런데 그 오감이 대부분 문서 밖에 있었습니다. 회의에서, 전화로, 오래 같이 일한 사람들 사이에서요.

콘웨이의 법칙대로라면 시스템에는 그 오감이 담기지 않습니다. 소통이 문서 밖에 있었으니, 시스템에도 안 남습니다.

트랜잭션 업무가 먼저 시스템이 된 것은 쉬워서만이 아닙니다. 조직을 건드리지 않아도 됐기 때문입니다.

구현이 쉬워지면 무엇이 남는가

고급 기술은 시간이 지나면 일반화됩니다. 예전에는 큰 회사만 하던 것이 지금은 흔한 일이 됐습니다.

지금 AI로 그 일이 한 번 더 일어나고 있습니다. 만드는 일의 난이도가 내려갑니다.

다만 오해하면 안 됩니다. AI가 그것을 해주는 것이 아닙니다. 만드는 일이 쉬워진 것입니다.

정리되지 않은 것을 넣으면 도구가 좋아져도 정리되지 않은 채로 나옵니다.

그러면 무엇이 남을까요.

무엇을 만들 것인가가 남습니다. 그리고 그 답은 기술 쪽에 없습니다.

지금까지 "어려워서 못 한 것"이었다면, 앞으로는 "정하지 않아서 안 한 것"이 됩니다.

기능에서 출발하면 달라집니다

그래서 조직을 바꿔야 할까요.

바꾸자는 것이 아닙니다. 조직에서 출발하지 말자는 것입니다.

무엇을 먼저 놓느냐

시스템을 설계할 때 대개 부서별로 요구사항을 받습니다. 연구는 이게 필요하고, 품질은 저게 필요하고.

그러면 부서 경계가 그대로 시스템에 새겨집니다. 콘웨이의 법칙 그대로입니다.

순서를 바꾸면 됩니다.

과제를 수행하려면 반드시 해야 하는 일들이 있습니다. 그것을 먼저 늘어놓습니다. 배합을 설계하고, 시험하고, 안정성을 보고, 규제를 확인하고, 생산으로 넘깁니다.

그리고 그다음에 누가 할지를 붙입니다.

기능은 부서를 가로지릅니다

안정성 평가는 어느 부서의 것이 아닙니다.

연구가 조건을 잡고, 시험이 진행되고, 품질이 판정하고, 그 결과가 생산으로 넘어갑니다. 하나의 기능에 여러 부서가 걸립니다.

기능에서 출발하면 이 걸침이 먼저 보입니다. 부서에서 출발하면 각자의 조각만 보입니다.

그리고 기능은 조직보다 안정적입니다

조직은 개편됩니다. 사람은 옮깁니다. 그런데 "안정성을 평가한다"는 일은 그대로 있습니다.

부서 이름이 바뀌어도, 담당자가 바뀌어도, 그 일은 계속 누군가 합니다.

변하는 것 위에 설계하면 변할 때마다 흔들립니다.

그다음이 주고받는 지점입니다

기능을 정하고 누가 할지를 붙이면, 여럿이 걸리는 자리가 드러납니다.

일은 한 줄로 흐르지 않습니다

여기서 흔한 오해가 하나 있습니다. 일이 부서에서 부서로 차례로 넘어간다는 생각입니다.

실제는 동시에 돕니다.

처방을 짜는 동안 규제도 보고, 원가도 맞추고, 설비도 확인하고, 고객사와도 조율합니다. 한 갈래가 끝나야 다음이 가는 것이 아니라, 여러 갈래가 나란히 가면서 서로를 기다립니다.

규제에서 걸리면 처방을 고쳐야 하고, 처방을 고치면 원가가 바뀌고, 원가가 안 맞으면 고객사와 다시 이야기해야 합니다.

그래서 물어야 할 것이 "누가 다음인가"가 아닙니다. "지금 무엇이 어디서 어떻게 돌고 있는가"입니다.

지금까지는 사람이 그 자리였습니다

여러 갈래가 동시에 돌면 누군가 가운데서 다 알고 있어야 합니다.

어디까지 갔는지, 무엇이 막혔는지, 지금 누구를 기다리고 있는지. 연구책임자나 담당자가 그 자리였습니다.

그래서 그 사람이 없으면 아무것도 안 굴러갑니다. 물어볼 데가 그 사람뿐입니다.

그리고 그 사람이 옮기면 통째로 나갑니다.

시스템이 그 자리에 들어가야 합니다

사람을 대신하는 것이 아닙니다. 사람이 머릿속에 갖고 있던 것을 시스템이 갖는 것입니다.

그러면 각자 자기 자리에서 지금 상태를 봅니다. 규제 검토가 어디까지 왔는지, 원가가 맞는지, 고객사 회신이 왔는지. 물어볼 사람이 없어도 됩니다.

그리고 여기서 콘웨이의 법칙으로 돌아옵니다.

지금까지 부서 사이를 사람이 이었습니다. 그래서 시스템은 부서 단위로 갈라진 채로 남았습니다.

그 자리를 시스템이 맡으면, 시스템이 부서를 가로지릅니다.

조직도를 안 건드려도 됩니다

부서는 그대로 두면 됩니다.

바꿔야 할 것은 그 사이에 오가던 것을 어디에 둘 것인가입니다. 사람의 머릿속과 말에 있던 것을 같은 자리에 두면, 조직을 안 바꿔도 구조가 달라집니다.

콘웨이의 법칙을 뒤집는다는 것이 조직을 바꾼다는 뜻은 아닙니다.

조직에서 출발하지 않는 것. 그리고 조직 사이의 자리를 설계의 중심에 놓는 것입니다.

관련 글

• [현장의 질문들] R&D 과제 계획의 단위 — 무엇을 온톨로지의 클래스로 잡을 것인가
• [현장의 질문들] 지식관리시스템은 왜 대부분 실패했습니까
• [현장의 질문들] 시스템을 도입했는데 아무도 안 씁니다