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

8명이 투입된 SI 프로젝트가 있었다. 몇 가지 핵심 이슈를 해결하지 못한 채 프로젝트는 종료됐고, 나는 그 문제를 혼자 맡아 3일 만에 해결했다. 이 이야기를 하면 보통 "실력 차이"라는 반응이 돌아온다. 그 해석만으로는 충분하지 않다. 개인 역량과 함께 조율 구조와 집중 조건을 봐야 한다. 이 렌즈는 Assessment Review나 리아키텍처링 같은 구조 개선 작업이 구축 조직 안에서 자주 우선순위에서 밀리는 이유를 검토하는 데도 도움이 된다.

경로는 제곱으로 늘어난다

브룩스는 『맨먼스 미신』에서 팀에 사람을 더할 때 커뮤니케이션 비용이 늘 수 있다고 지적했다.¹ 모든 구성원이 서로 1:1로 연결된다고 가정하면 n명 사이에 가능한 경로는 n(n-1)/2이고, 8명은 이론상 최대 28개다. 실제 팀이 그 전부를 쓰지는 않지만, 가능한 경로 수는 인원에 따라 제곱 규모로 늘 수 있다. SI 프로젝트에서는 문제를 푸는 시간보다 문제를 조율하는 시간이 길어지기 쉽다. 회의, 설명, 재설명, 승인, 담당 구분, 리뷰가 모두 그 비용에 들어간다. 아래 사회심리학 연구가 이 프로젝트의 원인을 입증하는 것은 아니지만, 책임과 기여가 팀 구조 안에서 달라질 수 있는 방식을 해석하는 데 참고할 수 있다.

이 항목들은 개인의 잘못이라기보다 조건에 따라 나타날 수 있는 구조적 비용이다. 이 사례에서 혼자 일한 3일은 개발 시간이 길었던 게 아니라, 팀 내부 조율 오버헤드의 상당 부분이 줄어든 문제 해결 시간이었다.

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

조율 비용이 낮아도 문제를 풀 방법이 없으면 소용없다. 방법도 중요한 설명이다. 문제를 모듈 단위로 쪼개 보는 대신 사용자, API, 로드밸런서, DB, 캐시를 하나의 흐름으로 놓고 원인 후보를 좁혔다. 로그를 다 읽는 대신 유력한 가설부터 세워 실험으로 하나씩 제거했다. 회의 일정이 거의 없었던 3일은 몰입을 이어 갈 수 있는 시간이기도 했다.

단서를 하나 달아야 정직하다. 이 사례는 "혼자가 항상 낫다"는 증거가 아니다. 혼자 작업이 유리했던 데에는 네 조건이 겹쳤다.

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

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

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

여기까지는 한 프로젝트의 회고다. 여기서는 시스템의 일을 구축(Build), 운영(Operate), 구조 개선(Transform)으로 나눠 본다. 보편적인 수명주기라기보다 오너십을 살피기 위한 분석 틀이다. 우리가 본 여러 SI 조직은 구축의 계약과 책임은 명확했지만 Assessment Review와 마이그레이션, 리아키텍처링 같은 Transform 작업은 전담 주체가 모호해지기 쉬웠다. 기술 부족만의 문제가 아니라, 각자의 KPI가 구조 개선의 우선순위와 충돌할 수 있기 때문이다.

개발사가 구조 문제를 근본까지 파려면 자신이 만든 설계를 다시 검토해야 할 수 있다. 이 작업이 계약 범위에 포함되지 않았다면 프로젝트 종료가 가까울수록 투입 우선순위가 낮아질 수 있다. 고객 조직도 예산과 일정 제약 속에서 "우선 오픈하자"고 판단할 수 있다. 각각 합리적인 선택이어도, 이런 조건이 겹치면 구조 개선의 오너가 모호해질 수 있다.

내부 Assessment가 부딪힐 수 있는 세 가지 제약

"우리 개발팀이 점검하면 되지 않을까"는 자연스러운 생각이다. 다만 세 가지 제약을 점검할 필요가 있다.

1. 거리. 내부 팀은 기존 설계의 배경을 가장 잘 안다는 장점이 있다. 동시에 현재 선택을 기준점으로 삼고 이를 유지하는 쪽으로 기울 수 있다. 명시적인 평가 기준과 독립된 리뷰어가 이런 경향을 줄이는 데 도움이 된다.
2. 질문의 정치학. "왜 이런 구조가 됐는가", "이 컴포넌트는 제거할 수 있는가" 같은 질문은 내부에서 사람에 대한 판단으로 받아들여질 수 있다. 그러면 질문이 완곡해지고 논의 범위가 좁아질 수 있다.
3. 시간. 운영팀은 오늘의 장애를, 개발팀은 다음 스프린트를 우선한다. 시스템 전체를 처음부터 다시 이해하는 며칠짜리 작업은 다른 업무와의 우선순위 경쟁에서 밀릴 수 있다.

마이그레이션도 비슷한 제약을 받는다. 기존 시스템 유지와 새 시스템 구축, 데이터 검증, 컷오버 계획을 동시에 굴려야 하고 운영팀에는 추가 업무가 된다. 리아키텍처링은 코드를 고치는 데서 끝나지 않고 "왜 이 서비스가 존재하는가"부터 다시 검토하므로, 개발 경험뿐 아니라 시스템 관점의 분석이 필요하다.

공백을 메우는 자리

그래서 우리가 서는 자리는 개발사의 대체재가 아니다. 고객 조직과 함께 시스템을 과거 설계에서 한 걸음 떨어져 분석하고, 개발사와 개선 방향을 설계하는 제3의 주체다. 효율을 높일 여지는 역할과 시간을 별도로 확보하는 데서 나온다. 과거 설계의 직접 당사자가 아니어서 대안을 비교하기 쉽고, 스프린트와 종료 일정 밖에 진단 범위를 두면 부분뿐 아니라 전체를 검토할 수 있다. 8인 프로젝트 사례에서 드러난 조율 부담을 줄이고 오너십을 명확히 하는 구조를 의도적으로 만드는 접근이다.

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

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

판단

우리가 본 많은 프로젝트에서 구조 개선이 지연된 이유는 기술 역량 하나로 설명되지 않았다. 개발 파트너와 고객 조직의 목표 사이에서 구조를 다시 평가하고 다음 단계를 설계할 전담 오너가 모호했다. 8명과 3일의 사례는 보편 법칙이 아니라, 조율 부담을 줄이고 오너십을 분명히 할 때 문제 해결 조건이 어떻게 달라질 수 있는지를 보여준 한 사례다.

시스템 진단부터 리아키텍처링, AI 전환까지의 여정이 고민이라면 AX 컨설팅에서, 마이그레이션과 인프라 전환은 클라우드 & 인프라에서 시작할 수 있다. 레거시 코드·데이터·연동을 함께 진단하고 전환 웨이브를 실행하는 범위는 애플리케이션 현대화에서 다룬다.

참고 자료