AI 에이전트 팁 – PM을 위한 루프 종료 조건 설계

에이전트 루프는 “반복 실행”이 아니라 “검증 가능한 조건이 충족될 때까지 반복하는 작업 계약”이다. PM에게 중요한 지점은 코드를 얼마나 잘 쓰느냐가 아니라, 무엇을 완료로 볼지와 누가 그 완료를 검증할지를 명확히 정하는 데 있다.

루프, 워크플로, 루틴을 구분한다

루틴은 정해진 단계를 실행한다. 워크플로는 발견한 상태에 따라 분기한다. 루프는 실행 결과를 다시 읽고, 성공 조건을 검사하고, 실패하면 다음 시도를 한다. 따라서 좋은 루프는 다음 네 가지를 갖는다.

/goal 형태의 프롬프트는 이 구조를 드러내기 좋다. “PRD를 더 좋게 만들어줘”가 아니라 “두 엔지니어가 독립적으로 읽어도 같은 구현을 만들 수준까지 애매한 요구사항을 제거하라”처럼 완료 조건을 작업물 밖에서 확인 가능하게 둔다.

루프의 핵심은 프롬프트 문장이 아니라 수용 기준(acceptance criteria)이다. PM은 이미 기능 정의에서 이 일을 한다. 에이전트 루프에서도 같은 능력이 필요하다.

루프	완료 조건 예시
PRD 하드닝	독립 검토자가 “서로 다르게 구현될 수 있는 애매함”을 찾지 못한다
피드백 클러스터링	새 패스를 돌려도 주요 테마와 심각도 태그가 바뀌지 않는다
경쟁사 모니터링	가격·기능·포지셔닝 변경이 출처 URL과 함께 분류된다
출시 체크	릴리스 노트, 분석 이벤트, 롤백 플랜, 지원 문서가 모두 체크된다
프롬프트 개선	출력물이 아니라 프롬프트 버전을 반복 수정하고, 검증 세트에서 통과율이 오른다

가장 흔한 실패는 루프가 멈추지 않는 것이 아니다. 멈췄지만 틀린 결과를 그럴듯하게 내놓는 것이다. 비용도 모델 단가보다 반복 횟수에 의해 커진다. “생성된 결과 중 실제 채택된 비율”을 보지 않으면 루프가 생산성을 높이는지, 리뷰 부하만 늘리는지 알 수 없다.

긴 루프는 컨텍스트가 썩기 쉽다. 한 루프에 여러 목표를 넣기보다, 입력과 완료 조건이 선명한 작은 루프를 여러 개 두는 편이 낫다. PM의 판단은 자동화 대상이 아니라 자동화 경계다.