AI 코딩 에이전트 루프 설계: 실전 코드베이스에서 통하는 센서·컨트롤러·액추에이터

핵심 메시지

• 프롬프트와 루프를 코딩 에이전트에 그냥 연결하면, 아무도 리뷰하지 않는 수만 줄짜리 PR만 쌓이기 쉽다.
• 'Ralph'로 불리는 단순 루프는 혼자 작업하거나 비핵심 시스템엔 잘 맞지만, 실제 고객·규제·SLA가 걸린 팀 환경에는 부족하다.
• 실전 루프는 제어이론처럼 센서(측정)·컨트롤러(점진적 변경 결정)·액추에이터(적용)로 나눠 설계할 수 있고, 에이전트가 이 역할들을 겸하기도 한다.
• 핵심 질문은 세 가지다: 측정할 대상을 찾을 수 있는가, 변경을 점진적으로 적용할 수 있는가, 변경 품질에 대한 피드백을 받을 수 있는가.
• 루프마다 PR에 라벨을 붙여 '열린 PR이 있으면 실행을 멈추는' 적응형 흐름 제어로, 아무도 못 읽는 작업이 계속 중첩되는 것을 막는다.

쉽게 이해하기

발표자는 대규모 언어 모델이 강력한 도구인 것은 맞지만, 그것을 둘러싼 담론 상당수가 과장이라고 지적하며 시작한다. 업계에는 '프롬프트와 루프를 코딩 에이전트에 흘려보내면 소프트웨어가 만들어진다'는 막연한 기대가 있지만, 검증 에이전트를 여럿 붙여도 결국 아무도 읽고 싶지 않은 4만 줄짜리 PR이 나온다는 것이다.

이른바 'Ralph' 같은 단순 루프 방식은 날카롭고 특정 문제에는 잘 통하지만, 혼자 작업하거나 비핵심 시스템일 때에 한한다. 대부분의 개발자는 실제 사용자·고객·규제 의무·SLA가 걸린 팀에서 일하며, 검증 없이 4만 줄 PR을 프로덕션에 바로 올릴 수 없다. 그래서 발표의 주제는 '현실 세계에서 동작하는 루프를 어떻게 설계하는가'다.

핵심 틀은 제어이론이다. 루프를 센서(무엇이 문제인지 측정·탐지), 컨트롤러(어떤 점진적 변경을 할지 결정), 액추에이터(그 변경을 실제로 적용)로 나눈다. 에이전트를 쓰면 이 경계가 흐려져, 코드 문제를 진단하면서 우선 고칠 항목까지 짚어 주는 하이브리드 센서-컨트롤러가 되거나, 하나의 에이전트가 변경을 결정하고 같은 맥락에서 바로 적용하는 컨트롤러-액추에이터가 되기도 한다.

실제 사례로, 발표자의 팀은 RPC API를 새로운 방식으로 점진 마이그레이션한다. 우선 언어에 구애받지 않는 정적 분석 도구(ast-grep 계열)로 아직 마이그레이션되지 않은 코드를 찾는다. 이런 도구를 TypeScript 설정이나 ESLint '밖'에 두는 이유는, 에이전트가 인라인 주석으로 린트 규칙을 꺼 버리는 일이 흔하기 때문이다. 스캔 결과를 결정적으로 정렬·필터링한 뒤, 한 번에 하나(또는 소수)만 골라 각각 독립된 맥락에서 변경한다.

마지막으로 두 가지 실전 장치가 소개된다. 하나는 적응형 흐름 제어로, 각 루프의 PR에 라벨을 붙이고 실행 전에 그 라벨의 열린 PR이 있으면(아직 사람이 리뷰하지 않았다는 뜻) 실행을 중단해 루프당 열린 PR을 최대 1개로 유지한다. 다른 하나는 속도 향상으로, 컨트롤러가 여러 건을 고르되 각 변경을 별도 컨텍스트 창에서 처리하거나 워크플로를 여러 번 돌려 팀원에게 나눠 주는 방식이다.

주요 인사이트

• 코딩 에이전트의 실패는 모델 능력보다 '루프 설계'의 부재에서 온다. 측정·점진성·피드백이라는 세 축이 없으면 자동화는 금세 통제 불능이 된다.
• 정적 분석을 TypeScript 설정·ESLint '밖'에 두는 이유는, 에이전트가 인라인 주석으로 린트 규칙을 스스로 비활성화해 버리기 때문이다.
• 한 번에 하나(또는 소수)만, 각 변경을 별도 컨텍스트 창에서 처리하면 더 저렴하고 안정적이다. 큰 변경을 루프에 넣으면 잘못될 위험이 빠르게 커진다.
• '열린 PR이 있으면 멈춤'이라는 규칙 하나가 리뷰 부담 폭증·중복·충돌을 막아 자동화의 지속 가능성을 좌우한다.
• 속도는 컨트롤러가 여러 건을 고르되 각기 독립 실행하거나, 워크플로를 여러 번 돌려 팀원에게 분배함으로써 안전하게 끌어올릴 수 있다.

자주 묻는 질문

관련 AI 소식