AI 코딩 에이전트 피드백 루프: 에이전트가 스스로 검증하게 만드는 법

핵심 메시지

• AI 코딩에 대한 극과 극의 후기는 '신규(greenfield) 프로젝트냐, 기존(brownfield) 코드베이스냐'의 차이에서 상당 부분 갈린다.
• 핵심 차이는 에이전트가 자기 작업을 실제로 검증할 수 있는 '피드백 루프'의 유무다.
• 에이전트가 '다 됐다'고 말할 때 그 뜻은 '내가 받은 정보 안에서는 될 것 같다'에 가깝다 — 검증 없이는 신뢰할 수 없다.
• 엔지니어의 새 역할은 제품 자체보다 'AI가 제품 위에서 잘 일하도록 만드는 것'으로 옮겨간다.
• 에이전트가 스스로 테스트하도록 만드는 투자는 당장은 느려 보여도, 에이전트를 밤새 돌리거나 여러 개로 늘릴 때 비로소 값을 한다.

쉽게 이해하기

발표자는 자체 파운데이션 모델과 코딩 에이전트를 만드는 Poolside 소속으로, 왜 사람마다 AI 코딩 경험이 극과 극으로 갈리는지를 짚는다. 한쪽은 '이제 코드를 거의 안 건드린다'고 하고, 다른 쪽은 '실제 프로덕션에 넣어보니 쓰레기 같은 결과가 나온다'고 말한다.

흔한 설명은 '신규 프로젝트는 쉽고, 레거시는 어렵다'는 것이다. 하지만 발표자는 레거시 애플리케이션에서도 AI가 잘 작동한 경험이 있다며, 진짜 차이는 다른 데 있다고 본다. 신규 프로젝트에서는 에이전트의 '직관'이 대체로 맞지만, 기존 코드베이스에는 죽은 코드나 에이전트가 미처 보지 못한 부분처럼 '예상 밖의 함정'이 숨어 있다.

그 함정을 메우는 것이 피드백 루프다. 에이전트가 '새 인증 흐름을 완벽히 구현했다'고 말해도, 그것은 대개 '내가 아는 한, 받은 정보 안에서는 될 것 같다'는 뜻이다. 검증 없이 이 말을 그대로 믿으면 회의론자는 '거짓말한다'고, 낙관론자는 '다시 해보라'며 로그를 확인시킨다 — 이 지점에서 두 부류의 사용자 경험이 갈린다.

해법으로 발표자는 에이전트가 자기 작업을 직접 테스트하게 해주는 사내 CLI 도구를 만들었다. 화면 스크린샷, 토큰을 아낀 압축 스냅샷, 백엔드·프런트엔드 로그 추출, 서비스 재시작, '특정 메뉴 접근', '메시지 전송 후 응답 대기' 같은 고수준 명령을 조합해, 에이전트가 마치 웹페이지를 다루듯 VS Code 확장 같은 자사 제품과도 상호작용하게 한다. 무엇보다 버그를 고치기 전에 먼저 '재현'하게 만드는 것이 신뢰의 출발점이다.

발표자는 이 도구 자체를 쓰라는 게 아니라 각자 자기 것을 만들라고 강조한다. 엔지니어의 새 역할은 'AI가 일하기 쉽게 만드는 것' — 도구를 붙이든, 코드베이스를 정리하든, 지식 베이스를 개선하든, CLI·스킬·MCP 어떤 형태로든 문제와 사람에 따라 다를 수 있다.

주요 인사이트

• AI 코딩 성패는 모델 성능만이 아니라 '에이전트가 결과를 스스로 확인할 수 있는 환경을 얼마나 갖췄는가'에 크게 좌우된다.
• 버그 수정을 맡길 때 에이전트가 먼저 버그를 재현하게 하면, 사람이 일일이 검증하는 시간을 줄이고 에이전트를 자율적으로(밤새) 돌릴 수 있는 신뢰가 생긴다.
• 속도만 좇으면 오류가 복리로 불어난다 — 검증을 쉽게 만드는 것이 속도의 함정을 피하는 길이다.
• 경직된 자동화 테스트보다, 사람이 하듯 제품을 직접 만져보는 방식의 검증을 선호할 수 있다. 발표자는 문제를 발견하면 'AI가 스스로 그 문제를 깨닫게 하려면 어떻게 할까'를 먼저 고민한다.
• 로그를 되짚어 'sleep(15)를 곳곳에 넣는' 같은 반복 패턴(코드 냄새)을 AI에게 찾게 하는 회고 루프가 유용하다. 제품 특성에 맞는 표현(예: 3D 세계를 위한 아스키 표현)을 고민하는 것도 엔지니어의 새 몫이다.

자주 묻는 질문

관련 AI 소식