8개의 AI 에이전트가 각자 완벽한 코드를 만들었다. CDK 타입 체크는 통과했고, Spring Boot는 컨벤션을 지켰으며, React UI는 깔끔했다. 그런데 실제로 연결해보니 17개의 버그가 터졌다. AWS Dev.to에 공개된 이 실증 사례는 단순한 해프닝이 아니다. AI 협업 개발의 구조적 취약점을 가장 선명하게 드러낸 장면 중 하나다.
문제는 코드 품질이 아니었다. 데이터베이스 컬럼명을 한 에이전트는 passenger_id로, 다른 에이전트는 id로 정했다. API 경로를 한 쪽은 /approve로, 다른 쪽은 /voucher/approve로 구현했다. 같은 사용자를 세 에이전트가 각각 pax-, PAX-, 접두사 없는 UUID로 식별했다. JSON을 내려주는 서비스 앞에서 클라이언트는 XML을 파싱했다. 각 에이전트는 자신의 영역에서 '올바른' 결정을 내렸지만, 그 결정들이 서로 맞닿는 경계—이른바 Seam—에서 전부 어긋났다.
인간 개발자라면 작업 기억 속에 '컬럼명은 passenger_id'라는 사실을 유지하며 모든 레이어에 일관되게 적용한다. 하지만 병렬로 실행된 AI 에이전트들은 서로의 구현 결정을 볼 수 없다. 높은 수준의 계획서는 공유했지만, 그 계획이 실제 코드로 구체화되는 순간의 세부 사항은 공유하지 않았다. 터널을 양쪽에서 동시에 파되, 서로 위치를 확인하지 않은 셈이다.
해결책은 놀라울 만큼 명쾌했다. 에이전트를 실행하기 전에 모든 공유 계약—컬럼명, URL 경로, 파라미터 형식, 식별자 규칙—을 단 하나의 참조 파일로 추출해 모든 에이전트에게 필수 컨텍스트로 제공한다. 그리고 생성이 끝난 후, 리뷰 에이전트 하나가 사용자 로그인부터 다운스트림 서비스 호출까지 실제 데이터 흐름을 추적하게 한다. 이 단일 패스로 17개 버그가 한 번에 잡혔다. 핵심은 AI가 아니라, AI를 묶는 계약 설계가 인간의 몫이라는 것이다.
Dev.to의 'Cyborg Developer' 글은 이 문제를 더 넓은 패러다임으로 짚는다. '바이브 코딩'의 실패 패턴은 정확히 이 지점에서 발생한다. AI에게 마이크로서비스 구현을 통째로 맡기고, 일주일은 마법처럼 돌아가다가, 비즈니스 요구사항이 바뀌는 순간 무너진다. 개발자가 시스템 설계를 내면화한 적이 없기 때문에, 컨텍스트가 흘러버린 AI가 완전히 다른 상태 관리 패턴을 만들어낼 때 속수무책이 된다. 결국 기계가 만든 블랙박스를 역엔지니어링하는 데 며칠을 소비한다.
'Agentic Software Engineering'을 다룬 Infinite Loop Part III는 이 역학을 한 문장으로 압축한다. "AI는 증폭기이지 교정기가 아니다." 좋은 방향으로 가고 있다면 더 빠르게 가고, 나쁜 방향으로 가고 있다면 더 빠르게 망한다. Discovery를 건너뛰는 팀은 이제 잘못된 제품을 기록적인 속도로 출시한다. AI 이전에 쌓이던 기술 부채는 이제 두 배 속도로 쌓인다. 속도 자체가 리스크다.
세 사례를 프론트엔드 개발자 시각으로 종합하면, AI 협업에서 인간이 반드시 개입해야 하는 세 지점이 선명하게 드러난다.
첫째, 생성 이전의 계약 정의. 컴포넌트 간 인터페이스, API 스펙, 데이터 스키마는 AI가 코드를 쓰기 전에 인간이 확정해야 한다. 에이전트에게 '알아서 맞춰줘'를 기대하는 순간 Seam 버그가 시작된다.
둘째, 생성 이후의 흐름 검증. 각 컴포넌트가 독립적으로 동작하는 것과, 실제 사용자 흐름에서 함께 동작하는 것은 완전히 다른 문제다. 통합 지점을 추적하는 리뷰 레이어—사람이든 에이전트든—는 배포 전에 반드시 존재해야 한다.
셋째, Discovery의 강화. 구현이 빨라질수록 '무엇을 만들 것인가'에 대한 판단력이 병목이 된다. 사용자 맥락과 비즈니스 목적을 이해하지 못한 채 AI에게 방향만 위임하면, 기술적으로 완벽하지만 아무도 원하지 않는 제품이 완성된다.
결국 AI가 코드 생성을 가속할수록, 설계의 무게중심은 오히려 인간 쪽으로 이동한다. 타이핑에서 조종으로, 구현에서 판단으로. 에이전트들이 병렬로 터널을 파는 속도가 빨라질수록, 양쪽이 만나는 지점의 좌표를 정확히 잡는 것—그 역할은 여전히, 그리고 점점 더, 사람의 일이다.