[Agent] 에이전트에게 한 시간 맡기려면 — 앤드류 응이 말한 세 개의 루프

코딩 에이전트에게 작업을 맡기면, 전에는 반나절 걸리던 구현이 한 시간 안에 끝나는 순간이 있다. 코드를 쓰고, 테스트를 돌리고, 실패를 고치고, 브라우저로 결과를 확인하는 반복을 에이전트가 혼자 수행할 수 있기 때문이다.

그런데 제품은 빨리 만들었는데도 멈춘다. 기능은 늘었지만 사용자가 원하는지 모르고, 테스트는 통과했지만 화면의 흐름은 어색하다. 에이전트가 빨라졌는데 병목이 사라진 것이 아니라 다른 층으로 옮겨 간 것이다.

Andrew Ng은 2026년 6월 The Batch에 실은 글에서 이를 세 개의 중첩된 루프로 설명했다. 핵심은 새 유행어가 아니다. 같은 ‘반복’을 누가 닫고, 얼마나 자주 돌며, 무엇을 근거로 고치는지 구분하자는 제안이다.

속도가 다른 세 개의 루프

루프	주로 누가 닫나	대략적인 시간 축	다음 반복을 바꾸는 근거
에이전트 코딩 루프	코딩 에이전트	수분	명세, 테스트, 평가 기준
개발자 피드백 루프	개발자·디자이너·제품 담당자	수십 분~수 시간	실행된 제품을 보고 내린 판단
외부 피드백 루프	사용자·시장	수 시간~수 주	인터뷰, 베타 테스트, 실제 사용 데이터

안쪽 루프가 바깥쪽 루프 안에 들어간다. 사용자의 반응은 제품의 방향을 바꾸고, 방향은 명세를 바꾸고, 새 명세는 다시 에이전트의 구현 반복을 바꾼다.

사용자 반응 → 제품 방향 → 명세와 평가 기준 → 에이전트의 코드·테스트 반복
     ▲                                                        │
     └────────────────── 배포된 결과 ──────────────────────────┘

이 그림에서 코드 생성은 끝점이 아니다. 가장 빠른 안쪽 루프의 입력일 뿐이다.

1. 에이전트 코딩 루프: 명세 안에서 빠르게 닫기

안쪽 루프에는 비교적 명확한 종료 조건이 있다. “이 화면을 만든다”, “이 API가 이 형식으로 응답한다”, “이 테스트를 통과한다”처럼 확인 가능한 기준이다. 에이전트는 코드를 수정하고, 테스트나 실행 결과를 읽고, 다시 고치는 일을 여러 번 할 수 있다.

여기서 중요한 것은 에이전트에게 오래 일하라고만 주문하는 것이 아니다. 무엇이 완료인지 판정할 기준을 함께 주는 일이다.

막연한 지시	루프를 닫을 수 있는 지시
“로그인 화면을 좋게 만들어 줘”	“모바일 360px에서 버튼이 가려지지 않고, 잘못된 비밀번호에는 오류 문구를 보이며, 이 세 시나리오 테스트를 통과하게 해 줘”
“버그를 고쳐 줘”	“재현 절차, 기대 결과, 실제 결과, 수정 뒤 통과해야 할 회귀 테스트”

명세와 평가 기준이 빈약하면 에이전트는 빈약한 기준을 아주 빠르게 만족시킬 뿐이다. 그래서 긴 자율 실행의 전제는 더 많은 자유가 아니라, 관찰 가능한 완료 조건이다.

2. 개발자 피드백 루프: 테스트가 말하지 못하는 것

테스트가 통과했다고 제품 판단까지 끝난 것은 아니다. 기능의 우선순위, 화면에서 사람들이 헷갈릴 지점, 이번 버전에서 의도적으로 하지 않을 일은 대개 자동 테스트에 들어 있지 않다.

이 층에서 사람은 단순 QA 담당자가 아니라 명세를 고치는 사람이 된다. 구현물을 직접 보고 다음 질문을 던진다.

• 이 기능은 지금 필요한가, 아니면 다음 배포로 미룰까?
• 사용자가 처음 보는 화면에서 무엇을 이해하지 못할까?
• 에이전트가 맞게 구현했지만, 우리가 애초에 잘못 요청한 것은 무엇일까?
• 같은 문제가 반복된다면, 다음부터 자동으로 확인할 평가 기준은 무엇일까?

사람의 역할을 막연히 ‘감각’이라고 부르면 재현하기 어렵다. 더 정확한 표현은 맥락 우위다. 담당자는 사용자와 조직의 제약, 과거의 실패, 이번 출시의 목적처럼 에이전트의 입력에 아직 담기지 않은 정보를 알고 있다. 그 정보를 명세와 우선순위로 바꿔 안쪽 루프에 넣는 것이 개발자 피드백 루프다.

3. 외부 피드백 루프: 가장 느리지만 생략할 수 없는 루프

친구에게 써 보게 하기, 알파 테스터를 모집하기, 운영 환경에서 지표를 보기, A/B 테스트를 하는 일은 코드 수정보다 느리다. 그래서 빨라진 구현 속도 앞에서 가장 쉽게 건너뛰게 된다.

하지만 이 루프만이 “정확하게 만들었는가”가 아니라 “만들 가치가 있는가”를 알려 준다. 내부에서 완성도 높다고 평가한 기능이 실제 사용자에게는 필요 없을 수 있고, 반대로 작은 불편 하나가 이탈의 원인일 수 있다.

외부 피드백을 받았다고 루프가 저절로 닫히는 것도 아니다. 반응을 제품 방향의 수정으로 옮기고, 그 방향을 다음 명세와 평가 기준에 반영해야 한다. 설문 결과를 모으기만 하고 다음 작업의 조건이 바뀌지 않는다면, 그것은 기록이지 피드백 루프는 아니다.

빠른 루프가 느린 루프를 대신하지 않는다

세 루프를 한 줄로 줄이면 이렇다.

에이전트는 “정해진 일을 제대로 했는가”를 빠르게 반복할 수 있지만, “정할 일이 맞았는가”는 개발자와 사용자 피드백이 닫아야 한다.

그래서 에이전트 도입 뒤의 실무 질문도 달라진다. “한 번에 얼마나 긴 작업을 맡길 수 있나?”만 묻기보다, 각 루프가 돌아갈 증거와 책임자를 정해야 한다.

확인할 것	빈약한 상태	루프를 살리는 산출물
구현	자연어 요청만 있다	명세, 완료 조건, 자동 테스트
개발자 검토	결과를 감으로 본다	데모, 변경 내역, 결정 기록, 재현 가능한 이슈
사용자 검증	배포 뒤 반응을 기다린다	대상 사용자, 관찰할 행동, 성공·실패 기준

이 표는 성과를 보장하는 처방전이 아니다. 팀의 규모나 제품의 위험도에 따라 루프의 길이와 증거는 달라진다. 다만 안쪽 루프만 극도로 빠르게 만들고 바깥쪽 둘을 비워 두면, 더 빠르게 잘못된 방향으로 갈 가능성도 커진다.

정리: 맡기는 시간보다 돌아오는 신호가 중요하다

한 시간짜리 에이전트 실행은 인상적이다. 그러나 그 시간을 늘리는 것만으로 좋은 제품이 생기지는 않는다. 에이전트가 코드를 고칠 신호, 개발자가 명세를 고칠 신호, 사용자가 제품 방향을 고칠 신호가 차례로 있어야 한다.

에이전트에게 길게 맡기기 전에 다음 세 가지만 적어 두면 충분하다.

1. 에이전트는 무엇을 통과하면 멈추는가?
2. 사람은 언제 결과를 보고 어떤 결정을 내리는가?
3. 실제 사용자의 어떤 반응이 다음 명세를 바꾸는가?

이 세 질문의 답이 있으면, 코딩 에이전트는 막연한 자동화가 아니라 제품을 배우는 과정의 가장 안쪽 엔진이 된다.

참고

• Andrew Ng, Three Key Loops for Building Great Software — The Batch — 2026-06-26. 세 루프의 원문 프레임과 시간 축의 출처입니다.
• DeepLearning.AI The Batch: Letters from Andrew Ng — 원문 제목·발행일·요약을 확인한 공식 목록입니다.