어느 조직이든 조직도가 있습니다. 도구도 있습니다. 그런데 “우리 회사에서 일이 실제로 어떻게 흐르는가”를 그려 달라고 하면, 그릴 수 있는 조직은 드뭅니다. 구조(조직도)와 수단(도구)은 있는데, 그 사이 — 일이 흐르는 방식 자체 — 는 설계된 적이 없기 때문입니다.

운영체계라는 관점

컴퓨터의 운영체제는 앱이 아닙니다. 앱들이 돌아가게 하는 규칙의 층입니다. 메모리를 어떻게 나눠 쓰는지, 프로그램끼리 어떻게 신호를 주고받는지 — 사용자 눈에 보이지 않지만, 이 층이 없으면 아무 앱도 돌지 않습니다.

조직에도 같은 층이 있습니다. 결정이 내려지는 방식, 정보가 사람 사이를 이동하는 경로, 반복되는 일이 표준이 되는 절차, 경험이 기록으로 남는 습관. 저는 이 층을 조직의 운영체계(Operating System)라고 부릅니다. 이 층은 설계하지 않아도 존재합니다 — 다만 설계하지 않으면, 우연과 관성으로 만들어진 채 존재합니다.

설계되지 않은 운영체계의 증상

증상은 익숙합니다. 같은 질문이 계속 반복됩니다. 특정한 사람이 자리를 비우면 일이 멈춥니다. 새 사람이 와서 한몫을 하기까지 반년이 걸립니다. 지난번에 분명히 해결했던 문제가 다시 발생합니다. 이것들은 사람의 문제처럼 보이지만, 실은 지식과 판단이 사람 안에만 있고 체계 안에 없다는 구조의 문제입니다.

운영체계를 구성하는 다섯 요소

운영체계를 설계한다는 것은 다섯 가지를 함께 설계한다는 뜻입니다. 워크플로 — 일이 흐르는 경로. SOP — 반복 업무의 표준. 의사결정 — 판단이 만들어지고 위임되는 구조. 자동화와 AI — 사람이 개입하지 않아도 되는 지점. 지식 축적 — 경험이 자산이 되는 체계. 이들은 별개의 주제가 아니라 하나의 층을 이루는 부품들입니다. 하나만 고치면 반드시 다른 곳에서 새는 이유가 여기에 있습니다.

이 관점을 방법론으로 정리해 가는 작업이 OSDF(Operating System Design Framework)입니다. 완성된 이론이 아니라, 연구와 실무를 오가며 공개 상태로 다듬는 중인 문서입니다.

도구를 바꾸는 조직은 많고, 조직도를 바꾸는 조직도 많습니다. 그러나 성장의 병목은 대개 그 둘 사이의 보이지 않는 층에 있습니다. 그 층에 이름을 붙이는 순간, 비로소 설계할 수 있게 됩니다.