8명이 못 푼 문제, 혼자서는 왜 3일이면 됐을까

요약 — 8명이 투입된 SI 프로젝트가 못 풀고 끝낸 문제를 혼자 3일에 해결했다. 비결은 개인기가 아니다. 얽힌 커뮤니케이션 경로와 책임 분산, 결정 마비가 사라진 자리에 순수한 문제 해결 시간만 남았기 때문이다. 같은 조직 역학이 Assessment와 마이그레이션, 리아키텍처링을 내부에서 멈추게 한다. 부족한 것은 기술이 아니라 전담 주체다.

8명이 투입된 SI 프로젝트가 있었다. 몇 가지 핵심 이슈를 해결하지 못한 채 프로젝트는 종료됐고, 나는 그 문제를 혼자 맡아 3일 만에 해결했다. 이 이야기를 하면 보통 "실력 차이"라는 반응이 돌아온다. 편한 해석이지만 틀렸다. 그 3일을 설명하는 것은 개인의 능력이 아니라 조직행동론이다. 그리고 이 설명은 왜 Assessment Review나 리아키텍처링 같은 구조 개선 작업이 구축 조직 안에서 번번이 멈추는지까지 이어진다.

경로는 제곱으로 늘어난다

브룩스가 『맨먼스 미신』에서 정리한 대로, n명 사이에 가능한 커뮤니케이션 경로는 n(n-1)/2다.¹ 8명이 모든 쌍으로 이어진다면 이론상 최대 28개다. 실제 팀이 그 전부를 쓰지는 않지만 방향은 분명하다. 사람이 늘수록 조율할 경로는 제곱 스케일로 늘고, 혼자면 0개다. SI 프로젝트에서는 문제를 푸는 시간보다 문제를 조율하는 시간이 길어지기 쉽다. 회의, 설명, 재설명, 승인, 담당 구분, 리뷰. 여기에 사회심리학의 고전적 현상들이 얹힌다.

어느 항목도 누군가의 잘못이 아니다. 사람이 모이면 구조적으로 발생하는 비용이다. 혼자 일한 3일은 개발 시간이 길었던 게 아니라, 이 오버헤드를 전부 뺀 순수 문제 해결 시간이었다.

그래도 3일은 설명이 더 필요하다

조율 비용이 0이어도 문제를 못 풀면 소용없다. 나머지 절반은 방법이 설명한다. 문제를 모듈 단위로 쪼개 보는 대신 사용자, API, 로드밸런서, DB, 캐시를 하나의 흐름으로 놓고 원인 후보를 좁혔다. 로그를 다 읽는 대신 유력한 가설부터 세워 실험으로 하나씩 제거했다. 그리고 회의가 없는 3일은 몰입이 끊기지 않는 3일이기도 했다.

단서를 하나 달아야 정직하다. 이 사례는 "혼자가 항상 낫다"는 증거가 아니다. 혼자가 이긴 것은 네 조건이 겹쳤기 때문이다.

• 한 사람이 끝까지 추적할 수 있는 규모의 문제였다.
• 필요한 권한과 정보 접근이 충분했다.
• 병렬 작업보다 깊은 분석이 중요한 유형이었다.
• 조율 비용이 기술 난이도보다 큰 병목이었다.

대규모 기능 개발이나 장기 유지보수, 품질 보증처럼 병렬화와 상호 검증이 중요한 일에서는 여전히 팀이 이긴다.

구축을 잘하는 조직이 개선 앞에서 멈추는 이유

여기까지는 흔한 회고담이다. 흥미로운 것은 이 역학을 시스템의 다음 단계에 대입할 때다. 시스템은 구축(Build), 운영(Operate), 구조 개선(Transform)의 단계를 밟는다. 개발사는 구축에 강하다. 그런데 Transform, 곧 Assessment Review와 마이그레이션, 리아키텍처링 앞에서는 멈추는 조직이 많다. 못해서가 아니다. 각자의 KPI에 충실한 결과다.

개발사가 구조 문제를 근본까지 파려면 자신이 만든 설계를 의심하고 때로는 부정해야 한다. 계약 범위 밖의 일이고, 종료가 가까울수록 조직의 관심은 문제 해결에서 프로젝트 종료로 이동한다. 발주사도 마찬가지다. 예산은 소진됐고 일정은 굳었고 서비스는 열어야 하니 "우선 오픈하자"는 합리적인 결정이다. 양쪽 모두 나쁜 결정을 하지 않았는데, 구조를 개선할 주체만 사라진다.

Assessment가 내부에서 멈추는 세 가지 이유

"우리 개발팀이 점검하면 되지 않을까"는 자연스러운 생각이고, 대개 세 가지에 걸린다.

1. 객관성. 자신이 만든 시스템을 자신이 평가하면 기존 설계를 유지하려 하고, 근본 원인보다 증상을 먼저 고치려 든다. 능력의 문제가 아니라 누구에게나 작동하는 인지 편향이다.
2. 질문의 정치학. "왜 이런 구조가 됐는가", "이 컴포넌트는 제거할 수 있는가" 같은 질문은 내부에서 사람에 대한 평가로 번역되기 쉽다. 질문이 무뎌지고 논의가 얕아진다.
3. 시간. 운영팀은 오늘의 장애를 살고, 개발팀은 다음 스프린트를 산다. 시스템 전체를 처음부터 다시 이해해야 하는 며칠짜리 작업이 끼어들 자리가 없다.

마이그레이션이 어려운 이유도 같다. 기존 시스템 유지와 새 시스템 구축, 데이터 검증, 컷오버 계획을 동시에 굴려야 하는데 운영팀에게 이것은 전부 추가 업무다. 리아키텍처링은 한 단계 더 나아간다. 코드를 고치는 작업이 아니라 "왜 이 서비스가 존재하는가"부터 다시 검토하는 작업이라, 개발 경험보다 시스템 사고가 먼저 필요하다.

공백을 메우는 자리

그래서 우리가 서는 자리는 개발사의 대체재가 아니다. 발주사를 대신해 시스템을 객관적으로 분석하고, 개발사와 함께 개선 방향을 설계하는 제3의 주체다. 효율은 앞서 본 조직 역학에서 나온다. 과거 설계에 이해관계가 없으니 특정 선택을 방어할 필요가 없고, 스프린트와 프로젝트 일정에 묶여 있지 않으니 부분이 아니라 전체를 본다. 8인 프로젝트에서 혼자가 빨랐던 그 구조를 의도적으로 설계해 가져오는 셈이다.

우리 프로그램은 이 순서로 움직인다.

1. Assessment Review: 시스템 구조와 기술 부채, 운영 방식, 병목을 진단하고 개선 우선순위를 도출한다.
2. Architecture Review: 현재 아키텍처가 앞으로의 비즈니스·기술 요구를 수용할 수 있는지 검토하고 개선 시나리오를 설계한다.
3. Migration Strategy: 클라우드·플랫폼·DB·애플리케이션 이전의 리스크와 단계별 전환 전략을 세운다.
4. Re-Architecture: 리팩터링이 아니라 서비스 경계와 데이터 흐름, 운영 모델까지 포함한 구조 재설계를 수행한다.
5. AX: AI를 기능으로 덧붙이는 대신 업무 프로세스와 시스템 구조를 AI 친화적으로 재설계한다.

판단

많은 프로젝트가 구조 개선을 못 하는 것은 기술이 부족해서가 아니다. 개발사와 발주사 모두 각자의 목표에 충실하기 때문에, 구조를 객관적으로 재평가하고 미래 관점에서 설계할 전담 주체가 존재하지 않는 것이다. 8명과 3일 사이의 간극은 그 공백의 크기였다.

시스템 진단부터 리아키텍처링, AI 전환까지의 여정이 고민이라면 AX 컨설팅에서, 마이그레이션과 인프라 전환은 클라우드 & 인프라에서 시작할 수 있다.

참고 자료