이 메모는 장기 관측소에서 발췌한 내용이며, 규모 확장에 있어 건축가의 역할에 대한 개인적인 의견이 뒤따릅니다.
맨해튼 도시 계획에서 배우는 점 Link to heading
맨해튼 남부의 좁고 불규칙한 거리들은 예측할 수 없는 이름과 온갖 각도로 교차하는 교차로들로 가득 차 있어, 폭이 넓고 직각으로 교차하는 거리(퍼스트 스트리트부터 220번가까지)와 대로(퍼스트 스트리트부터 12번가까지)로 이루어진 격자형의 뉴욕 나머지 지역과는 극명한 대조를 이룬다.
그 이유는 역사적인 배경에서 찾을 수 있습니다. 17세기 초 뉴욕이 네덜란드의 무역항 역할을 하기 시작했을 당시에는 도시 계획이라는 것이 존재하지 않았습니다. 거리들은 주민들이 다니는 길을 따라 나 있거나 필요에 따라 추가되었을 뿐, 체계적인 구상이 없었습니다. 따라서 뉴욕은 교통이 불편하고(특히 외국인 관광객에게), 공공사업 계획도 어렵고, 도시 성장을 체계적으로 관리하기도 힘듭니다.
맨해튼 남부는 (당장의 필요를 다루는) 배관공들에 의해 설계되었고, 뉴욕의 나머지 지역은 (교통 수요에 대한 장기적인 비전과 단순성 및 전반적인 효율성에 대한 고려에서 영감을 받은) 건축가들에 의해 설계되었습니다.

디지털 시스템 Link to heading
행정 시스템에도 마찬가지입니다. 어떤 시스템은 추가적인 아키텍처 설계 노력을 감수하더라도 사용자의 시간을 최적화하도록 설계되었습니다. 또 어떤 시스템은 마치 누수 지점을 이리저리 뛰어다니는 배관공처럼 형식적인 절차와 일관성 없는 문서를 쌓아 올려 규칙 제정자의 노력을 최소화합니다.
싱가포르는 첫 번째 범주에서 ‘공학적 접근 방식’을 채택하여 주도적인 위치를 차지하고 있습니다. 이 접근 방식은 사용자를 위해 ‘효율성을 극대화’하는 방식으로 공공 정책을 설계하고 관리하는 것을 목표로 합니다. 모든 새로운 규정은 충분한 이점을 입증해야 하며, 기존 규정은 정기적인 효율성 검토를 거쳐 최적화되고 더 이상 필요하지 않을 경우 폐지됩니다. 기능적인 ‘아키텍처 규칙’은 사용자를 위한 문서 및 절차의 ‘효율성 최적화’를 위해 적용됩니다. 이러한 규칙에는 공통 데이터 표준, (표준 데이터를 기반으로 하는) 사전 입력 양식의 광범위한 사용, 그리고 (예: 결제 또는 데이터 수집을 위한) 공통 소프트웨어 구성 요소의 의무적 사용 등이 포함됩니다.
디지털화 담당 기관은 ‘총괄 설계자’로서 핵심적인 역할을 수행하며, 표준 구현을 담당하는 각 부처의 ‘기능별 설계자’들에게 의존합니다. 디지털 기술은 종종 프로세스를 간소화하거나 ‘조화’하는 데 중요한 역할을 합니다. 절차를 디지털화할 때, 이러한 절차나 필요한 정보 및 문서의 지나친 다양성으로 인한 비용이 명확해집니다. 디지털화 이전에는 이러한 복잡성으로 인한 부담이 사용자에게 전가되었습니다. 디지털화를 통해 이러한 다양성으로 인한 비용이 분명해지는 동시에, 부서 간 서로 다른 프로세스를 조화시킴으로써 얻을 수 있는 이점 또한 명확해집니다.
(이미지 출처: 에이전트 디자인 패턴)
노멀스코프 Link to heading
프랑스에서는 기업과 사용자들이 유럽에서 가장 높은 수준의 행정적 복잡성으로 인한 시간적 손실을 겪고 있으며, 장기관측기구(Observatoire du Long Terme)는 이를 GDP 6포인트(약 1,700억 유로) 손실로 추산하고 있습니다. 과거의 간소화 노력은 대개 일회성으로 그쳤는데, 법률 개정(대개 새로운 법률 제정으로 그 효과가 상쇄됨)이나 법전 개정(대개 이후 추가적인 복잡성을 야기하는 개정안으로 이어짐) 등이 그 예입니다.
이러한 노력을 확대하고 장기적으로 정착시키는 데에는 두 가지 방안이 있습니다. 첫 번째는 싱가포르처럼 소프트웨어/IT 도시화에서 영감을 받은 건축적 원칙과 사용자 중심적 접근 방식(행정 중심적 접근 방식과 반대)을 도입하여 행정 생산 구조를 재편하는 것입니다.
두 번째 방안은 ‘시간세’를 평가하고 목표치를 설정하는 것입니다. 예를 들어 500억 유로 감축을 목표로 삼을 수 있습니다. 우선 제한된 수단으로 시작할 수 있는데, 가장 중요한 100가지 절차에 소요되는 시간을 표본 추출하는 방식입니다. ‘노름스코프(normoscope)‘와 같은 협업 도구를 활용하여 사용자들이 겪는 절차상의 문제점을 공유할 수도 있습니다. 프랑스 가계의 경제적 여건이 그 어느 때보다 어려운 만큼, 삶의 질 향상에 도움이 되지 않는 부담에서 벗어나도록 도와야 합니다.
행정적 복잡성 측면에서 보자면, 이는 구조는 더 많이, 배관은 더 적게 필요하다는 것을 의미합니다.

여담: 규모 확장에 따른 복잡성 관리 Link to heading
저는 종종 어떤 스타트업은 성공적으로 규모를 확장하는 반면, 어떤 스타트업은 어려움을 겪는 이유가 궁금했습니다. 그 이유는 대개 적재적소에 적합한 인재를 배치하는 데 있습니다. 이를 위해서는 아키텍트가 실제로 어떤 역할을 해야 하는지 이해하는 것이 중요합니다.
수프, 주방, 그리고 메뉴 Link to heading
수프를 파는 레스토랑을 예로 들어 스타트업을 생각해 보세요. 첫 번째 수프가 큰 인기를 끌면서 사업이 성장했습니다. 레스토랑이 확장됨에 따라 요리사가 늘어나고, 레시피가 추가되고, 모든 것이 더 복잡해졌습니다. 요리사가 늘어나고 레시피가 추가될 때마다 주방은 점점 느려졌습니다. 이 문제를 해결하기 위해 스타트업 창업자들은 프로젝트 관리 사무소(PMO)를 설립하여 업무 효율을 높이기로 했습니다.
PMO 팀은 곧 중요한 무언가가 빠져 있다는 것을 깨달았습니다. 바로 주방 운영 방식에 대한 명확한 계획이 없었던 것입니다. 그들은 각 요리사에게 구체적인 책임을 부여하고, 상세한 작업 지시서를 통해 작업을 정리하고, 예상 소요 시간을 바탕으로 마스터 플랜을 수립하는 등 여러 가지 방법을 시도했습니다. 하지만 아무 소용이 없었습니다. PMO 팀은 그 이유를 알 수 없었습니다. 모든 것이 문서로 작성되어 있었는데, 왜 제대로 작동하지 않는 걸까요?
문제는 그 책이 수프 만드는 법은 설명했지만, 어떤 수프를 만들어야 하는지는 설명하지 않았다는 점입니다. PMO 팀은 더 이상 한 가지 수프만 만드는 것이 아니라, 제품 제작자(PM)가 만든 메뉴에 따라 다양한 요리를 만들 수 있는 육수를 가지고 있다는 사실을 깨닫지 못했습니다. PMO 팀은 근본적인 문제를 해결하는 대신, 마치 계획 없이 도로를 더 건설하는 것처럼 단순히 프로세스를 “연결"하는 데만 급급했습니다.
PMO에 정말 필요했던 것은 북부 맨해튼의 도로처럼 모든 것이 원활하게 운영되고 시간이 지남에 따라 확장될 수 있도록 잘 설계된 시스템이었습니다. PMO의 실수는 복잡성을 체계화하기 위한 청사진을 만들어 줄 아키텍트가 필요하다는 사실을 인식하지 못한 것이었습니다.
많은 스케일업 기업에는 아키텍처 설계뿐만 아니라 팀의 성장 마인드셋(고정 마인드셋과 같은 사고방식) 함양까지 책임지는 엔지니어링 디렉터 한 명만 있습니다. 목표는 효율성을 강요하는 것이 아니라 팀원들이 스스로 효율성을 책임지도록 권한을 부여하는 것입니다. 이러한 단계를 모두 거쳐야만 비로소 스케일업을 시작할 준비가 된 것입니다!
프로젝트 중심 조직 Link to heading
최근 HBR에 실린 프로젝트 중심 조직이라는 기사를 접했습니다. 조직 설계, 리더십, 가치 창출이라는 세 가지 핵심 요소에 대한 체계적인 접근 방식이 마음에 들었습니다. 하지만 한 가지 아쉬운 점이 있습니다. 바로 아이디어를 수익성 있는 제품으로 전환하는 전략이 빠져 있다는 것입니다.
아래 다이어그램은 원래 개념을 재구성한 것으로, 아이디어를 수익성 있는 제품으로 전환하기 위한 전략이라고 할 수 있는 “로드 플랜"이라는 요소를 추가했습니다. 또한, 여러 팀을 연결하는 역할을 하는 “엔지니어링 팀"도 추가했습니다.

이 그림에서 건축가가 도로 계획에 의견을 제시하는 것일까요? 아니면 도로 계획이 건축가에게 입력값으로 제공되는 것일까요? 아니면 건축가가 프로젝트 팀에 의견을 제시하는 것일까요? 맥락에 따라 모든 답변이 맞습니다. 중요한 것은 엔지니어링 팀이 도로를 건설할 것이고, 그들에게는 따라야 할 계획, 즉 ‘구체화’할 건축 설계가 필요하다는 점입니다.
프로젝트를 수익으로 전환하기 Link to heading
아래 그림은 주방의 설계와 구성이 얼마나 잘 되어 있는지를 보여주는 것일까요? 아니면 PMO를 통해 얼마나 효율적으로 운영하고 수익을 창출할 수 있는지를 보여주는 것일까요?
결론 Link to heading
상황이 너무 복잡해지고 통제 불가능해질 때는 다음 두 가지 간단한 규칙을 통해 복잡성을 정리하는 것을 생각해 보세요. 더 많은 구조적 설계와 더 적은 세부적인 계획!
(이미지 출처: