AI 도입 전에, 먼저 팀을 가치 흐름에 맞춰 재구성하라

회사에 AI를 도입하기 전에, 도구 선택이나 모델 선택보다 보상이 훨씬 큰 일이 하나 있다. 가치 흐름에 맞춰 기술 팀을 재구성하는 것이다. AI 도구를 사고, 모델을 배포하고, 사람까지 교육했는데도 납품은 여전히 느리고 직원은 더 지쳐 있는 기업을 너무 많이 봤다. 근본 원인은 거의 예외 없이 AI가 약해서가 아니라, 팀이 기술 계층 — 프론트엔드, 백엔드, 알고리즘, 운영, 보안 — 으로 잘려 있다는 데 있다. 엔드투엔드 기능 하나가 네다섯 팀을 넘나드는데, 인수인계 때마다 뭔가 떨어진다. 요구사항이 조금, 맥락이 조금, 책임감이 조금씩. 팀 경계를 바로잡아야 AI가 증폭할 토양이 생긴다. 경계가 틀리면 AI는 그냥 잘못된 구조 위에서 부채를 더 빨리 쌓을 뿐이다.

이 글에서는 바로 쓸 수 있는 조직 설계 방법론을 소개한다 — Team Topologies(Skelton & Pais, 2019). 핵심은 세 가지다. 가치 흐름별로 팀을 나누기, 각 팀의 인지 부하 관리하기, 내부 플랫폼을 제품으로 다루기. 제조업의 실제 사례로 풀어 설명하겠다.

한 제조업 CIO(사례는 실제 프로젝트를 익명화한 것)가 이런 말을 했다. 스마트 품질검수 AI 기능을 출시했는데, 기술 자체는 어렵지 않았다. 카메라가 결함을 식별하고, 모델은 이미 성숙한 걸 쓰면 됐다. 어려운 건 납품이었다. 프론트엔드 팀이 UI를 만들고, MES 팀이 작업오더 흐름을 고치고, 알고리즘 팀이 모델을 배포하고, 운영 팀이 서버를 관리하고, 보안 팀이 또 검토해야 했다. 기능 하나에 5개 팀, 정식 인수인계 4번, 3개월이 걸렸다. 아무도 빈둥거리지 않았다. 그런데 인수인계 때마다 뭔가 빠졌다.

하나, 콘웨이 법칙은 절반만 말했다

콘웨이 법칙은 이렇게 말한다. 시스템의 아키텍처는 팀의 커뮤니케이션 구조를 복제한다. 프론트엔드와 백엔드로 팀을 나르면, 프론트엔드와 백엔드가 분리된 시스템이 나온다. 팀이 소통하는 방식대로 시스템이 자란다. 이 법칙은 실증적으로 반복 검증됐다.

하지만 콘웨이는 “이렇게 된다”고만 말했을 뿐, 좋은 아키텍처가 저절로 자라나도록 팀을 어떻게 설계해야 하는지는 말하지 않았다. 2019년 Skelton과 Pais의 『Team Topologies』가 이 빈칸을 채웠다. 팀에는 네 가지 기본 유형이 있고, 세 가지 상호작용 방식이 있으며, 이 모든 것을 관통하는 원칙 하나가 있다 — 인지 부하를 관리하라.

둘, 네 가지 팀: 재구성 옵션으로 쓰되, 용어로 외우지 말라

이 네 가지 유형을 “재구성 때 꺼내 쓸 수 있는 옵션”으로 다루겠다. 정의를 외우게 하려는 게 아니다.

가치흐름 팀(Stream-aligned Team) — 조직의 주력이며, 대다수를 차지해야 한다. (원서의 표현은 most, 구체적 비율은 주지 않았다.) “흐름(stream)”이란 지속적인 가치 흐름이다. 가치흐름 팀은 이 흐름의 한 구간을 엔드투엔드로 책임진다 — 요구사항을 이해하고, 개발하고, 출시하고, 운영한다. 가치흐름 팀인지 판단하려면 딱 하나만 보면 된다. 외부 팀에 의존하지 않고 가치를 사용자에게 전달할 수 있는가. 앞서의 CIO로 돌아가자. 그의 스마트 품질검수 기능이 하나의 “품질검수 흐름 팀”에 귀속됐다면 — 프론트엔드를 아는 사람, MES 연동을 아는 사람, 알고리즘 배포를 아는 사람, 운영을 아는 사람이 한 팀에 함께 있다면 — 이 기능은 한 팀이 해결하고 인수인계는 제로가 된다. 이것이 있어야 할 모습이다.

대기업에서 가장 흔한 문제는, 시스템은 엔드투엔드인데 팀은 횡단적 기술 계층으로 잘려 있다는 것이다. 매 엔드투엔드 납품마다 여러 팀의 보고 경계를 통과해야 한다. 산업을 바꿔도 증상은 같다. 금융의 신용 리스크 통제 기능은 App·핵심시스템·리스크모델·데이터 네 팀을 넘나든다. 이커머스와 통신도 마찬가지다 — 이커머스의 프로모션 기능은 상품·거래·마케팅·물류를, 통신의 요금제 변경은 채널·과금·CRM·네트워크를 넘나든다. 횡단으로 잘린 팀이 세로로 선 가치 흐름을 받으니, 필연적으로 곳곳에서 인수인계가 생긴다.

플랫폼 팀(Platform Team) — 가치흐름 팀을 위해 길을 깔아준다. 플랫폼 팀은 인프라, CI/CD, 공통 서비스를 제공해서 가치흐름 팀이 “셀프서비스”로 능력을 가져갈 수 있게 한다. 매번 작업오더를 올려 사람에게 부탁하지 않아도 된다. 판단 기준은 하나다. 당신의 내부 플랫폼이 제품으로 운영되고 있는가 — 사용자가 있고, 로드맵이 있고, SLA가 있는가. 아니면 작업오더를 받는 “내부 외주”로 전락했는가. 대기업 IT 부서 대부분은 후자의 악순환에 빠진다. 플랫폼을 지어놓아도 아무도 안 쓰고, 사업 팀은 우회해 제각각 따로 만들고, 플랫폼 팀은 외주로 퇴화한다. Netflix의 Spinnaker(지속적 배포)와 Spotify의 Backstage(개발자 포털)가 플랫폼을 제품으로 운영하는 교과서적 사례다. 이 둘은 자주 섞인다 — Spinnaker는 Netflix, Backstage는 Spotify다. 보고 자료에서 헷갈리지 말 것.

지원 팀(Enabling Team) — 가치흐름 팀의 역량 상승을 돕되, 목표는 자신이 필요 없어지는 것이다. 지원 팀은 직접 사업을 납품하지 않는다. 가치흐름 팀의 역량을 끌어올려 준다 — 새 기술을 도입하는 코치, DevOps 전환을 이끄는 파실리테이터, 보안 컴플라이언스 자문. 가치흐름 팀과의 관계는 멘토와 멘티이지 갑을이 아니다. 대기업에서 외부 동행 컨설턴트가 가장 많이 맡아야 할 역할이 바로 이것이다 — 의존을 만드는 게 아니라 역량을 이전하는 것.

복잡 하위시스템 팀(Complicated-Subsystem Team) — 깊은 전문성이 필요한 난제를 해결한다. 어떤 하위시스템이 극도로 깊은 전문성을 요구한다면 — 리스크 엔진, 추천 알고리즘, 암호학, 비디오 코덱 — 별도로 떼어 전문가 팀에 맡기고, 가치흐름 팀의 인지 부하가 폭발하지 않게 하라. 이런 팀은 드물어야 한다. 한 조직에서 복잡 하위시스템 팀이 많이 솟아난다면, 그것은 보통 본래 플랫폼이어야 할 능력이 굴뚝(silo)으로 쪼개진 것이다.

팀 유형만 구분해서는 부족하다. 팀 간에 어떻게 소통할지도 정의해야 한다. Team Topologies는 세 가지 상호작용을 제시한다. 협업(collaboration) — 두 팀이 깊이 함께 일하는 방식, 불확실한 새 상황에 적합하지만 에너지가 많이 들어 단기만 써야 한다. 서비스 제공(X-as-a-Service) — 한 팀이 능력을 제품으로 내놓고 다른 팀이 셀프로 소비하는 방식, 가장 효율적이며 상태가 되어야 한다. 촉진(facilitating) — 지원 팀 전용. 조직 설계가 풀어야 할 핵심 질문은, 가능한 많은 상호작용을 “서비스 제공”으로 밀어가는 것이다. 장기적으로 “협업”에 의존한다면, 플랫폼화가 안 된 것이다. 앞서의 CIO 상황으로 보자. 품질검수 흐름 팀과 플랫폼 팀 사이는 서비스 제공이어야 한다. 플랫폼이 셀프서비스 CI/CD 입구를 열어주면, 품질검수 팀이 알아서 쓰고 인사할 필요 없다. 매 배포마다 플랫폼 팀을 끌어들여 회의하며 “협업”해야 한다면, 그것은 플랫폼화가 안 된 것이다 — 문제가 태도가 아니라 플랫폼이 제품으로 안 됐기 때문이다.

셋, 왜 “사람 추가”와 “프로세스 추가”로는 살 수 없는가: 인지 부하

이것이 Team Topologies의 가장 과소평가된 공헌이다. “인지 부하(cognitive load)”를 조직 설계의 중심에 놓았다.

한 팀(5~8명)의 인지 부하는 제한되어 있다. 한 팀이 동시에 열 개 넘는 무관한 시스템을 유지보수하고, 육칠 개의 업스트림과 연동하고, 세 벌의 새 프레임워크까지 처리한다면 필연 과부하된다. 품질은 떨어지고, 납품은 느려지고, 사람은 타진다.

이것이 그 CIO의 또 다른 의문을 설명한다. “세 명을 더 줬는데 왜 여전히 느릴까?” 뿌리는 이 일단의 사람들이 동시에 너무 많은 무관한 일을 짊어지고 있다는 데 있다. 사람은 사실 충분하다. 사람을 추가하는 것은 그저 더 많은 사람이 같은 혼돈 속에서 빙글빙글 도게 만들 뿐이다. 프로세스 추가는 더 나쁘다. 프로세스는 인지 부하를 또 한 겹 먹어치워서, 원래 일을 할 수 있던 사람들이 표를 채우고 회의하고 결재를 받는 데 더 많은 시간을 쓰게 만든다.

대기업이 가장 줄이기 쉬운 살은, 조직 스스로 더한 부담이다 — 팀 간 실랑이, 잦은 컨텍스트 스위칭, 결재 밟기. 이를 덜어내는 데 새 기술은 전혀 필요 없다. 다만 덜 괴롭히면 된다.

구체적인 예를 하나. 어느 은행 핵심시스템 팀 리더의 팀은 7명이 동시에 리스크·고객센터·감리보고·마케팅 네 업스트림과 연동하며 서로 무관한 세 모듈을 유지보수한다. 매일 팀 간 회의·정렬·컨텍스트 스위칭을 처리하는 것만 팀 정력의 절반 가까이를 잡아먹는다. 이런 팀에 아무리 좋은 AI 도구를 쥐여줘도 소화하지 못한다. 사람에게 새 것을 배우고 프로세스를 바꿀 여분의 인지 대역폭이 없기 때문이다. 살리려면 먼저 부담을 빼라. 무관한 모듈을 밖으로 떼어내고, 팀이 하나의 가치 흐름만 책임지게 하라.

아마존의 “투피자 팀”이 말하는 것은 커뮤니케이션 비용이다 — 사람이 많아지면 구성원 간 커뮤니케이션 채널 수(n(n-1)/2)가 폭등해 의사결정이 느려진다. Team Topologies는 한 층 더 깊이 설명한다. 8명 안팎을 넘기면 인지 부하도 관리가 안 된다. 조직 설계가 진정으로 하는 일은, 직능별로 보고선을 긋는 것이 아니라 인지 부하에 따라 팀을 나누고, 각 팀의 부담이 감당 가능한 범위 안에 떨어지게 하는 것이다.

대기업을 위한 한 줄 진단. 당신 조직의 “가장 바쁜 사람들”이 동시에 5개 이상의 무관한 일을 짊어지고 있지 않은가? 그렇다면 사람을 아무리 더 보태고 프로세스를 아무리 더 보태도 살릴 수 없다. 다시 나누어야 한다.

넷, 어떻게 착수할까: 역콘웨이(Inverse Conway) 수법

이것이 가장 실행 가능한 한 수다. 먼저 아키텍처 다이어그램을 그리고 팀을 바꾸는 게 아니라, 먼저 팀 구조를 바꿔서 아키텍처가 저절로 원하는 모양으로 자라나게 하라.

전통적 방식은 아키텍트가 목표 아키텍처 다이어그램을 그리고(“우리는 마이크로서비스로 간다!”), 팀에게 그에 맞춰 바꾸라고 요구하는 것이다. 이는 거의 항상 실패한다. 기존 팀 구조가 아키텍처를 줄곧 자기 모양으로 끌어당기기 때문이다. 바로 콘웨이 법칙이 작동하는 것이다.

역콘웨이 수법은 반대다. 먼저 가치 흐름에 따라 팀을 재구성한다 — 가치흐름 팀을 그어내고, 플랫폼 팀을 세운다. 팀 경계가 곧 미래의 서비스 경계가 되게 한다. 그러면 아키텍처는 저절로 합리적인 서비스 분할로 수렴한다. 팀 간에 자연스럽게 API로 통신하게 되고, 하나의 데이터베이스를 공유하지 않기 때문이다.

앞서의 CIO로 돌아가자. 나는 그에게 먼저 마이크로서비스 프레임워크를 고르게 하지 않았다. 내가 시킨 것은 더 소박한 일이었다. “품질검수”라는 흐름을 별도의 팀으로 독립시키고, 기존의 프론트엔드 팀·MES 팀·알고리즘 팀·운영 팀에서 각각 한 명씩 뽑아 6인 규모의 품질검수 흐름 팀을 꾸려, 품질검수 기능을 엔드투엔드로 책임지게 했다. 3주 안에 세 일이 일어났다. 첫째 주, 그들은 원래 MES 작업오더 흐름의 한 단계에 걸려 있던 부분이 사실 알고리즘 팀의 개입이 필요 없다는 것을 발견했고, 팀 내부에서 고쳤다. 둘째 주, 그들은 스스로 모델 배포를 “운영 팀 줄 서서 기다리기”에서 팀 내 셀프서비스로 바꾸기로 했다 — 플랫폼 팀이 CI/CD 셀프서비스 입구를 열어줬기 때문이다. 셋째 주, 그들은 첫 번째 엔드투엔드 소 기능을 출시했고, 어떤 팀 경계도 넘나들지 않았다. 사람은 안 더했고, 도구도 안 바꿨다. 횡단으로 잘린 층을 세로로 선 흐름으로 세웠을 뿐이다. 납품 주기는 3개월에서 3주로 돌아왔다. 예상치 못한 수확도 있었다. 이 팀이 개선을 스스로 제안하기 시작한 것이다. 그들이 처음으로 자기 흐름의 전모를 파악할 수 있게 됐고, 결과에 대해 온전히 책임지게 됐기 때문이다. 예전 5개 팀을 넘나들 때는, 누구도 자신이 품질검수 흐름 전체를 책임져야 한다고 느끼지 않았다.

의사결정자에게 이것은 직관에 반하지만 레버리지가 높은 결론이다. 아키텍처 다이어그램 위에서 반복해 고민하는 것보다, 조직도 위에서 칼을 대는 것이 낫다. 아키텍처를 바꾸는 것은 결과이고, 조직을 바꾸는 것이 레버리지다.

누가 쓰고 있나

은행업(TT 공식 핵심 산업 + 강규제 참조): teamtopologies.com에 전문가 칼럼 『When DORA metrics meet governance in banking』이 있다. 거기서 인용된 DORA 연구의 결론은 단단하다. 외부 결재(external approvals)는 리드타임·배포 빈도·복구 시간과 부정 상관 — 팀 간 사후 결재가 많을수록 납품은 느려지고, 장애 복구도 느려진다. 이는 본문의 주장을 정확히 뒷받침한다. 컴플라이언스 요구를 흐름 팀에 내장하고, 결재를 전진시키며, 사후에 팀 간 회의를 돌리지 말라. ClearBank 등 영국 디지털 은행이 공식 생태계에서 반복 인용되며, 은행업은 “강규제하에 가치 흐름 재구성을 하는” 가장 참고가 되는 시나리오다.
Zalando(이커머스, 플랫폼을 제품으로 삼은 모범): 내부 개발자 플랫폼이 가치흐름 팀의 셀프서비스 능력으로 자리잡은 것은, TT 커뮤니티가 자주 인용하는 플랫폼화 벤치마크다.
AutoTrader UK(자동차 분류 플랫폼): TT 공식이 반복 인용하는 실제 도입 사례, 가치 흐름 재구성 + 내부 플랫폼 제품화.
KPMG UK(2024년 TT 공식 솔루션 파트너가 됨): TT를 대기업/금융 고객에게 전달 — TT가 이미 주류 기업 컨설팅에 진입했다는 신호.
Netflix / Spotify(“플랫폼을 제품으로”의 정신적 모범, TT 도입 사례는 아님): TT가 출간된(2019) 이전부터 플랫폼을 제품으로 운영했고 이 원칙을 뒷받침하지만, TT 네 팀 모델의 도입 사례로는 간주하지 않는다.

참고: teamtopologies.com/examples(공식 사례 라이브러리) · teamtopologies.com/news-blogs-newsletters/when-dora-metrics-meet-governance-in-banking(은행업 DORA 전문가 칼럼)

다섯, 언제 통하지 않는가

Team Topologies는 은총알(silver bullet)이 아니다. 네 가지 흔한 실패가 있고, 각각은 대기업의 실제 병소에 대응한다.

이름만 바꾸고 구조는 안 바꾼다. “프론트엔드 팀” 이름을 “가치흐름 팀”으로 바꾸고, 보고 관계는 그대로, 여전히 기술 계층별 — 콘웨이 법칙은 이름 바꾸기 따위에는 거들떠보지도 않는다. 이것이 대기업 “겉만 바꾸는” 개혁의 가장 흔한 결말이다.

플랫폼 팀이 제품으로 대우받지 못한다. 플랫폼 팀에 로드맵도, 사용자 경험도 없으면, 가치흐름 팀은 계속 우회하고, 플랫폼은 작업오더를 받는 외주로 퇴화한다.

모든 팀이 “협업”하고 있다. 협업은 고에너지 상호작용으로, 불확실한 새 상황에만 단기로 써야 한다. 장기적으로 협업에 의존한다면, 플랫폼화가 안 된 것이다. 겉보기엔 “협업 문화가 좋다”이지만, 병인은 플랫폼화의 부재다.

KPI가 따라 바뀌지 않았다. 조직도는 바꿨는데 여전히 직능별로 평가하고(프론트엔드 코드량, 버그 수), 팀 행동은 빠르게 옛 모습으로 퇴행한다.

이 네 조항은 하나의 판단에 대응한다. 조직 구조, 인센티브 구조, 기술 아키텍처 — 이 셋 중 하나를 바꾸고 나머지 둘이 따라 움직이지 않으면, 변혁은 반드시 실패한다.

강규제 산업의 변형. 금융·통신은 묻는다. 보안, 컴플라이언스, 기술 리스크 같은 직능은 규제가 독립(segregation of duties)을 요구하므로, 흐름 팀에 단순히 끼워 넣을 수 없다. 이는 법적 강제이지 조직의 관성이 아니다 — 억지로 뜯지 말라. 하지만 횡단 결재로 되돌아갈 필요도 없다. 두 길이 있다. 하나는 흐름 팀에 컴플라이언스/보안 담당을 내장하는 것 — 그 담당자가 팀 안에 있으면서 동시에 컴플라이언스 라인으로 점선 보고를 해, 가치 흐름에 붙어 있으면서도 독립성을 만족시킨다. 다른 하나는 컴플라이언스를 지원 팀으로 만들어, 흐름 팀이 규제 요구를 프로세스에 내장하도록 돕는 것 — CI에서 컴플라이언스 검사를 돌리듯, 결재를 팀 내부로 전진시키고 사후 팀 간 회의로 돌리지 않는다. 규제 요구가 흐름 팀의 내장된 품질이 되고, 외부 감사 관문이 되지 않는 것 — 이것이 강규제 산업이 “흐르게” 되는 열쇠다.

여섯, 당신이 묻고 싶을 만한 것

“우리는 십 년 동안 기술 계층별로 잘라왔는데, 재구성이 영향이 크지 않을까?” 영향은 있지만, 당신이 생각하는 것보다 훨씬 가볍다. 회사 전체를 허물고 다시 시작할 필요는 없다. 먼저 가장 막히는 가치 흐름 — 보통 모두가 가장 많이 불평하는 그것 — 을 골라, 별도의 가치흐름 팀으로 시범 삼아 세우라. 앞서의 CIO처럼, 4~8주, 작은 팀 하나로 납품 속도의 뚜렷한 변화를 볼 수 있다. 결과로 다음 라운드를 설득하는 것이 PPT로 설득하는 것보다 효과적이다.

“이게 내가 하고 있는 AI 전환이랑 무슨 상관인가?” 직접적 상관이다. AI는 잘못 짜인 조직을 고치지 않는다. 오히려 기존 조건을 증폭시킨다. 고성과 팀이 AI를 얻으면 더 빨라지고, 잘못 짜인 팀이 AI를 얻으면 부채를 더 빨리 만들 뿐이다. 그러니 조직 진단은 도구 조달 앞에 와야 한다. 이것 역시 내가 “역량 평가”를 시그니처 방법론 『AI 전환 7단계 코칭 프레임워크』의 아주 앞쪽에 둔 이유다 — 먼저 조직과 사람을 보고, 그 다음에 도구를 논한다.

“네 가지 팀을 우리는 다 갖추지 못하는데 어떡하죠?” 대부분의 조직은 갖추지 못하고, 또 갖출 필요도 없다. 가장 먼저 있어야 할 것은 가치흐름 팀(엔드투엔드 납품을 보장)과 플랫폼 팀(바퀴의 재발명을 막는다)이다. 지원 팀과 복잡 하위시스템 팀은 필요에 따라 두면 되고, 많은 조직이 처음에 없어도 정상이다. 네 가지 유형을 다 갖추려고 팀을 억지로 만들지 말라 — 그것은 본말이 전도된 것이다.

일곱, 의사결정자를 위한 시사점

시사점 하나: AI를 도입하기 전에, 먼저 팀 토폴로지 맵을 그려라. 당신이 최근 AI 도구를 도입하기 전에 팀 토폴로지를 그려본 적이 있는가? 팀이 기술 계층별로 잘려 있으면, 아무리 강한 AI도 그저 잘못된 구조 위에서 부채를 가속해 만들 뿐이다. 이 조항 하나가 대기업의 무효 IT 투자 적어도 절반을 막아준다. 구체적 행동 — 모든 팀을 나열하고, 각 팀이 어느 가치 흐름을 엔드투엔드로 책임지는지 표시하라. 표시할 수 없는 것이 곧 기술 계층별로 잘린 것이며, 우선 재구성 대상이다.

시사점 둘: 인지 부하 건강검진을 한 번 하라. “사람이 충분한가”를 더 보지 말라. 어떤 팀이 동시에 5개 이상의 무관한 시스템을 유지보수하는지, 어떤 사람이 동시에 3개 이상의 업스트림과 연동하는지를 보라. 이것을 드러내는 것이 사람을 더하고 프로세스를 더하는 것보다 훨씬 유용하다. AI가 부하의 일부를 떠안을 수는 있다 — 코드 작성, 자료 조사, 초안 스크리닝. 단, 전제는 당신이 의식적으로 부하를 재분배하는 것이지, 과부하된 팀에 “AI 착지”라는 임무를 하나 더 짊어지게 하는 것이 아니다.

시사점 셋: 내부 플랫폼을 제품으로 다루고, 그렇지 않으면 반드시 외주로 전락한다. 플랫폼에는 사용자가 있고, 로드맵이 있고, SLA가 있어야 하며, 채택률에 책임지는 사람이 있어야 한다. AI 시대에 이 플랫폼은 또한 모델 게이트웨이, 프롬프트 라이브러리, 에이전트 실행 환경을 끌어안아야 한다 — 이것은 뒤에 “도입 프레임워크” 편에서 펼칠 기반이다.

시사점 넷: AI가 잘못된 경계를 굳히지 않게 하라. 이 조항은 특별히 AI 에이전트를 도입하고 있는 조직에 드리는 말이다. 팀에 AI 에이전트를 더할 때, 잘못된 팀 자르기는 증폭된다 — 에이전트는 기존의, 잘못된 경계에 따라 자동화하여, 잘못된 구조를 더 견고하게 만든다. AI 에이전트를 도입하기 전에, 먼저 팀 경계가 올바른지 확인하라. 이것은 시리즈 제11편의 핵심이다.

역방향 자기 점검(대답할 때 미화하지 말 것): 당신의 팀은 가치 흐름별로 잘려 있는가, 아니면 프론트엔드/백엔드/운영/보안별로 잘려 있는가? 당신의 가장 바쁜 사람이 동시에 3개 이상의 무관한 일을 짊어지고 있지 않은가? 내부 플랫폼을 아무도 안 쓴다면, 그것이 플랫폼화 실패의 적신호다. 두 조항 중 하나라도 대답이 마음이 불편하다면, AI를 도입하기 전에 먼저 팀을 재구성하라 — 이것이 보상이 가장 큰 선행 작업이다.

다음 단계

이것이 “AI 시대 소프트웨어 엔지니어링 변화” 시리즈의 제2편(“천천히 배우는 AI” 코너 제172호)이다. 콘웨이(조직이 아키텍처를 결정한다)에서 Team Topologies(조직을 어떻게 설계할 것인가)까지 걸어왔다. 다음 편(제3편)은 더 기초적인 문제를 본다. AI가 코드 생산을 사실상 공짜로 만들 때, 소프트웨어 엔지니어링의 병목은 어디로 옮겨가는가?

시리즈 안내: 본 시리즈는 AI 프로그래밍 도구, 조직 아키텍처, 소프트웨어 엔지니어링 패러다임의 최신 전개를 계속 추적합니다 — 이를테면 2026년 AI 에이전트 시대에 콘웨이 법칙의 새로운 변화, 최신 도구 생태계의 성숙도 등. 본 시리즈를 팔로우해 지속적으로 갱신되는 통찰을 얻으세요.

본 시리즈에 대하여

“AI 시대 소프트웨어 엔지니어링 변화”는 통신·금융·제조·이커머스 등 산업의 CIO/CDO/CTO 및 디지털 책임자를 위해 쓴 심층 연구 시리즈로, 모두 15편이다. 200여 편의 학술 논문과 산업 보고서에 기반해, 증거 위계 표시가 붙은 의사결정 참고를 제공한다.

나는 전 IBM 엔지니어이자 ICF 인증 코치이며, 통신사와 대기업의 AI/디지털 프로젝트 구현을 해왔다. 여기에 쓴 것은 모두 기업과 함께 실전에서 겪은 판단이다.

다 읽고 “우리 회사도 이런 모양 아닐까”를 떠올렸다면 — 나는 「팀 토폴로지 20문 자가진단표」를 준비했고, 30분 1:1 진단 대화도 제공한다. 가장 먼저 재구성해야 할 가치 흐름이 무엇인지 찾아준다. 필요하다면 — 공식계정 「AI 의사결정자 인사이트」에 메시지를 남기거나, coach@iaiuse.com으로 메일을.

참고 출처

Skelton, M. & Pais, M. (2019). Team Topologies. IT Revolution Press. (네 팀 / 세 상호작용 / 인지 부하의 원출처, 1급 출처)
Conway, M. (1968). How Do Committees Invent? Datamation.
Forsgren, Humble & Kim (2018). Accelerate. IT Revolution Press.
IT Revolution (2024). Team Topologies: Five Years of Transforming Organizations. (다수 조직 도입 복기, 2급) https://itrevolution.com/articles/team-topologies-five-years-of-transforming-organizations/
Netflix Spinnaker / Spotify Backstage — 내부 플랫폼 제품화 모범
AutoTrader UK — TT 공식 인용 도입 사례 (세부 링크 teamtopologies.com 보충 예정)
공식 사례 라이브러리: https://teamtopologies.com/examples