에이전트 개발, 잘 만든 코드와 운영에서 도는 코드는 다르다

Thoughtworks의 CTO 레이첼 레이콕은 최근 글에서 숙련 개발자들이 코딩 에이전트를 전면적으로 받아들이지 않는 이유를 짚었다. 그가 내린 결론은 단순하다. 무언가를 만들어내는 일과 그것이 운영 환경에서 안전하게 돌아가게 만드는 일은 전혀 다른 문제라는 것이다. 새 도구를 누구보다 먼저 시험해 온 사람들이 오히려 조심스러워하는 데에는 이런 경험에서 나온 판단이 자리 잡고 있다는 설명이다.

계기는 Thoughtworks가 격월로 준비하는 Technology Radar 작업 중 열린 논의였다. 여기서 나온 구체적인 사례가 유럽 지역 CTO인 자일스 알렉산더가 진행한 일주일짜리 실험이다. 시니어 엔지니어, 인프라 컨설턴트, 제품 담당자를 한자리에 모아 놓고 코드는 단 한 줄도 직접 쓰지 않게 했다. 애플리케이션 구축은 전부 에이전트가 맡았다. 결과물은 목표의 80% 수준까지 도달했고 애플리케이션은 실제로 실행됐다.

문제는 그다음이었다. 애플리케이션은 돌아갔지만 빌드는 자주 실패했다. 팀은 전체 시간의 약 3분의 2를 화이트보드 앞에서 보냈다. 도메인을 정리하고 경계를 그으며 다음에 무엇을 해야 할지, 에이전트가 실행할 수 있는 계획을 세우는 일이었다. 나머지 3분의 1은 테스트, 계약, 아키텍처 검사, 배포 파이프라인처럼 에이전트의 작업을 검증할 장치를 설계하고 그것을 하네스에 반영하는 데 쓰였다. 흥미롭게도 최종적으로 가장 많은 기능 코드를 커밋한 사람은 제품 담당자였다.

이 실험의 배경에는 Thoughtworks가 지속적 통합, 페어 프로그래밍, 자동화 테스트, 지속적 배포, 마이크로서비스 같은 관행을 비교적 이른 시기에 도입하고 확산시켜 온 역사가 있다. 이들이 추구해 온 것은 유용하고 변경 가능하며 운영에서 무너지지 않는 소프트웨어다. 반면 초기 코딩 에이전트는 운영에 쓸 수 없는 코드까지 손쉽게 대량으로 만들어냈다. 도구의 성능은 크게 좋아졌지만, 숙련된 개발자들은 여전히 같은 질문을 던진다. 이 동작이 의도한 것이 맞는지, 경계 설정이 적절한지, 나중에 변경할 수 있는지, 실패하면 무슨 일이 벌어지는지, 다른 팀이 이 코드를 감당할 수 있는지에 대한 답이 필요하다는 것이다.

그 아래에는 더 근본적인 물음이 깔려 있다. 이런 방식으로 시스템을 만들어 본 경험이 아무에게도 없는데, 그 시스템을 얼마나 신뢰할 수 있느냐는 문제다. 현재 운영 중인 대부분의 시스템은 사람이 직접 손으로 만든 것이고, 지금 새로 만들어지는 시스템은 아직 그 방식으로 오래 살아본 적이 없다.

이런 불안이 통계로도 확인된다. DORA의 2025년 연구는 AI 도입이 배포 처리량 증가와는 연결되지만 배포 안정성 저하와도 연결된다고 보고했다. 저자는 이것이야말로 지속적 배포와 DevOps가 애초에 해결하려 했던 문제가 되살아난 것이라고 본다. 실제로 실험 팀 내부에서도 테스트 주도 개발이 어떤 역할을 해야 하는지, 인수 테스트와 계약 테스트를 어디에 두어야 신뢰를 얻으면서도 깨지기 쉽지 않을지, 에이전트에게 작업을 맡기기 전에 설계를 얼마나 해야 하는지에 대한 논쟁이 이어졌다. 작업 단위의 크기도 쟁점이다. 스토리에서 에픽 단위로 옮겨가는 팀이 늘고 있지만, CI 파이프라인이 그 크기의 작업을 병렬로 감당할 수 있는지는 별개의 문제다.

실무적으로 달라지는 지점은 분명하다. 키보드 앞에서 코드를 치는 시간이 줄어드는 대신, 무엇을 만들지 정의하고 검증 체계를 설계하는 일이 개발자의 핵심 업무로 올라온다. 에이전트에게 어디까지 자율성을 줄지, 어떤 검사가 통과해야 신뢰할 수 있는지를 정하는 능력이 속도만큼 중요해진다는 뜻이다.

다만 이 글은 일주일 동안 극단까지 밀어붙인 실험을 바탕으로 한 관찰이다. 빌드가 실패한 원인도 병렬 에이전트 간 충돌, 시스템 모듈성 부족, 검사 속도보다 빠른 변경 유입 등 여러 가능성으로만 제시될 뿐 확정되지 않았다. 저자 자신도 마지막 구간의 문제를 어떻게 풀어야 할지는 아직 정리 중이라고 밝히고 있다.