코딩 에이전트 시대에도 팀 협업은 중요하다

일리야 라젠슈테인(Ilya Razenshteyn)은 여러 기업의 엔지니어와 연구자를 인터뷰해 코딩 에이전트의 실제 업무 활용과 부작용을 살폈다. 그의 결론은 코드 생성이 쉬워져도 신뢰성과 유지보수, 팀의 소통은 저절로 해결되지 않는다는 것이다.

인터뷰에서 가장 흔한 방식은 Claude Code나 Codex로 계획을 세우고 구현한 뒤, 에이전트와 사람의 검토를 거쳐 병합하는 흐름이었다. Claude와 GPT 모델을 함께 쓸 때는 한 모델이 다른 모델의 결과를 검토하기도 했다. 여러 에이전트를 묶은 복잡한 워크플로는 비용이 들고 실익이 크지 않다는 이유로 널리 쓰이지 않았다.

코드를 일일이 살피지 않아도 되는 경우는 시연용 결과물이나 일회성 스크립트, 원하는 동작을 시험으로 명확히 확인할 수 있는 코드 등으로 제한됐다. 탐색적 머신러닝·데이터 과학·연구 작업은 결과가 대체로 맞으면 유용할 수 있지만, 오류가 쌓일 위험이 있어 속도와 신뢰성 사이의 균형을 잡기 어렵다고 라젠슈테인은 설명했다. 장기 유지보수나 신뢰성이 필요한 코드, 고객이 사용하는 제품에서는 코드와 테스트를 어느 정도 검토해야 한다는 견해다.

그가 우려하는 조직 차원의 문제는 충분히 이해하지 않은 채 만든 코드·문서가 퍼지는 ‘슬롭’과, 쉽게 만들 수 있다는 이유로 비슷한 내부 도구를 쏟아내고 방치하는 ‘과잉 구축’이다. 에이전트에 의존하면서 동료와 덜 소통하거나, 동료보다 모델을 더 신뢰하고, 아이디어의 다양성이 줄어드는 현상도 문제로 꼽았다. 라젠슈테인은 팀 단위 업무에서는 개인의 산출량뿐 아니라 의사소통과 협업을 중시하고, 조직도 이에 맞는 기준과 보상 체계를 마련해야 한다고 주장한다.

실무에서는 작업을 작은 단위로 나누고 계획 단계에서 예외와 제외 범위를 명시하는 방법을 권한다. 프로토타입과 장기 유지할 코드를 구분하고, 생성된 테스트와 코드를 살피며, 린터·정적 분석·지속적 통합을 활용하는 것도 제안했다. 여러 작업을 병렬로 진행하더라도 각각을 충분히 검토할 수 있도록 개수를 제한하라고 덧붙였다.

라젠슈테인은 이 글의 계획 과정에 AI를 일부 사용했지만 본문은 직접 썼다고 밝혔다.