AI가 아키텍처를 짰을 때 실제로 벌어진 일
"Claude가 설계한 백엔드를 물려받은 적이 있다." dev.to에 올라온 한 포스트의 첫 문장이다. 내용을 보니 낯설지 않았다. 사용자 200명짜리 CRUD 앱에 이벤트 소싱이 붙어 있고, PostgreSQL 연결 하나를 감싸는 추상 레이어가 세 겹이었다. 커스텀 DI 컨테이너까지 있었다. 아무도 왜 이게 여기 있는지 설명하지 못했다.
같은 기간, 대형 금융 엔터프라이즈에서 AI 코딩 에이전트를 도입한 팀은 다른 종류의 고통을 겪고 있었다. GitHub Copilot을 쥐어줬더니 개발자마다 로컬 컨텍스트 파일이 달랐고, MR에 올라오는 코드는 누가 썼는지 알 수 없는 스타일이었으며, 리뷰어는 로직 검토 전에 '이 코드가 안전한가'부터 확인해야 했다. 팀 내 신뢰도는 눈에 띄게 하락했다.
공통된 실패 패턴: AI를 설계자 자리에 앉혔을 때
두 사례가 공유하는 구조적 문제는 하나다. AI에게 판단을 요청했다는 것이다. "애플리케이션 아키텍처를 설계해줘", "어떤 데이터베이스를 써야 해", "프로젝트 구조를 어떻게 잡을까"—이런 질문들이다.
AI는 이 질문에 기꺼이 답한다. 그리고 기술적으로 완전한 답을 준다. 문제는 '완전함'의 기준이 훈련 데이터 안에 있다는 점이다. 팀 규모, 예산, 규제 환경, 유지보수 주체—이 변수들은 모델의 가중치 안에 없다. 그래서 500명 사용자 앱에 Segment→Snowflake→dbt→Mixpanel 파이프라인이 제안되고, 단순 쿼리 하나를 위해 IRepository<T> 4파일짜리 제네릭 추상화가 생성된다.
엔터프라이즈 현장 보고서는 이 패턴을 '요구사항 표류(requirement drift)'라고 부른다. AI가 일반적으로 옳은 방향을 제시하지만, 프로젝트 고유의 제약과 계속 어긋난다. "프로덕션 레디 코드를 써줘"라는 지시는 구체적 경계 없이는 아무것도 보장하지 않는다.
Claude Code 병렬 에이전트가 드러낸 또 다른 경계
Claude Code의 sub-agent 패턴은 이 문제를 다른 각도에서 보여준다. 리드 에이전트가 작업을 분할하고 여러 서브 에이전트를 병렬로 조율하는 구조인데, 실제로 두 개의 독립 서비스를 29분 만에 동시 생성한 사례가 나왔다. 생산성 수치만 보면 매력적이다.
그런데 이 패턴이 제대로 작동하려면 설계는 인간이 먼저 해놓아야 한다. 어떤 서비스가 독립적인지, 어떤 파일을 공유하면 안 되는지, 통합 단계는 어디서 끊어야 하는지—이 판단이 선행되지 않으면 서브 에이전트들은 같은 설정 파일을 동시에 수정하고, 유틸리티 함수 이름이 충돌하고, 스타일이 제각각인 코드를 리드 에이전트에게 가져온다. 리뷰 표면적은 에이전트 수만큼 선형으로 늘어난다.
이 패턴의 핵심 교훈을 한 문장으로 정리하면: "A 태스크를 B 태스크 언급 없이 설명할 수 있는가?" 그래야만 병렬화할 수 있다. 이 판단은 AI가 아니라 테크 리드가 내려야 한다.
역할 경계를 설계에 반영하는 법
세 사례가 수렴하는 지점은 명확하다. AI에게 맡겨도 되는 일과 맡기면 안 되는 일 사이의 경계는 컨텍스트의 소재지로 결정된다.
AI에게 맡겨도 되는 작업: - "내가 설계한 스키마로 SQL 마이그레이션 작성해줘" - "이 콜백 코드를 async/await로 변환해줘" - "이 Python 코드와 동일한 Go 스니펫 만들어줘" - 독립적이고 경계가 명확한 서비스 구현
인간이 직접 해야 하는 판단: - 팀 운영 역량이 있는가 (셀프호스팅 vs 매니지드) - 규제 환경이 어떤 제약을 부과하는가 - 이 코드가 5년 후에도 유지보수될 수 있는가 - 서비스 간 의존성이 어디서 끊기는가
엔터프라이즈 사례에서 CLAUDE.md 같은 공유 컨텍스트 파일이 팀 레벨에서 필요한 이유도 여기 있다. 개발자마다 다른 로컬 컨텍스트를 갖고 있으면 AI 출력이 불일치하고, 리뷰 비용이 늘어나고, 결국 팀 신뢰가 무너진다. 팀 단위 설계 원칙을 문서화해서 모든 에이전트 세션의 기준점으로 삼는 것이 선행되어야 한다.
AI가 생성한 코드, 어떻게 리뷰할 것인가
이미 AI가 설계를 주도한 코드베이스를 물려받았다면, 해체 방법도 있다. 핵심은 AI로 해체 작업을 도울 수는 있지만, 목표 상태 설계는 인간이 해야 한다는 것이다.
- 아무도 요청하지 않은 추상화부터 제거한다. '나중에 유용할 수도 있다'는 이유로만 존재하는 레이어는 지운다.
- 제네릭을 구체적인 것으로 교체한다.
IRepository<T>는 앱이 실제로 필요한 named function으로 바꾼다. - 현재 요구사항 기준으로 문서화한다. 2년 후 예측이 아니라 오늘의 실제 동작을 기준으로 아키텍처를 정리한다.
- AI에게는 마이그레이션 구현을 맡긴다. 목표 구조를 인간이 정한 다음, 그 구조로 가는 코드 변환을 AI에게 요청한다.
AI-First 팀에서 개발자의 역할 재정의
"코드를 짜는 것에서 코드를 짜는 시스템을 설계하는 것으로." Claude Code sub-agent 글이 2026년의 변화를 이렇게 요약했다. 맞는 말이지만, 절반만 맞다. 시스템을 설계하는 사람이 있어야 한다는 전제가 빠졌다.
내가 AI-First 팀을 리빌딩할 때 가장 중요하게 보는 역량은 프롬프트 작성 능력이 아니다. 어떤 결정을 AI에게 위임할 수 있고 어떤 결정은 자신이 소유해야 하는지 구분하는 판단력이다. AI 도구가 빨라질수록 이 판단력의 가치는 올라간다. 도구가 빠르게 실행할수록 잘못된 방향으로 빠르게 달릴 수 있기 때문이다.
"AI를 운전석에 앉히지 말고 조수석에 태워라"—세 기사가 각자 다른 방식으로 같은 결론에 도달했다. 현장 사례가 이만큼 일관되게 수렴할 때는, 이것이 이론이 아니라 실무 원칙이 됐다는 신호로 읽어야 한다.