에이전트가 여섯 시간 동안 돌아갔다. 그리고 아무것도 작동하지 않았다. 로그는 있었다. 커밋도 있었다. PR도 열렸다. 하지만 원래 버그는 그대로였고, 관련 없는 테스트 세 개가 사라져 있었다. 이걸 '실패'라고 부르기도 어렵다. 에이전트는 뭔가를 했으니까. 문제는 그게 조용한 실패였다는 것이다.
에이전트 루프의 구조는 단순하다. Goal → Plan → Execute → Evaluate → Adjust → Repeat. dev.to에 연재 중인 agentic loop 분석 시리즈가 지적한 것처럼, 대부분의 엔지니어가 놓치는 건 이 루프 자체가 아니라 각 단계마다 실패 모드가 다르다는 사실이다. 루프 전체가 터지는 건 눈에 띈다. 한 단계에서만 조용히 비틀리면 팀은 한참 뒤에야 알아챈다.
가장 위험한 단계는 Plan이다. 잘못된 플랜은 잘 실행된다. 논리적으로 일관된 실행 시퀀스가 완전히 틀린 문제를 해결한다. 결과물이 그럴듯해 보이기 때문에 리뷰를 건너뛰기 쉽다. 실제로 이 시리즈는 명시적으로 경고한다. "플랜을 검토하지 않고 실행을 허용하지 말라." 이건 에이전트에 대한 불신이 아니라, 플랜을 외부에서 검증하는 구조를 팀이 설계해야 한다는 뜻이다.
Execute 단계에서는 가역성 설계가 핵심이다. 에이전트는 실제 파일을 쓰고, 커맨드를 실행하고, 코드를 커밋한다. 이 행동들은 되돌리기 어렵다. 체크포인트마다 git 커밋, 스테이징 환경 격리, 명시적 롤백 경로—이것들은 에이전트가 터졌을 때 손실 범위를 제한하는 설계다. 없으면 여섯 시간치 작업이 통째로 날아간다.
Evaluate 단계는 더 교묘하다. 에이전트는 자기 출력물을 스스로 평가한다. 명백한 오류는 잡는다. 하지만 미묘한 오류는—자신을 만든 훈련 분포와 같은 방향으로 편향된 오류는—놓친다. AI 코딩 에이전트의 할루시네이션 제어를 다룬 또 다른 분석에서 이 문제를 'process theater'라는 표현으로 짚었다. 에이전트가 뭔가를 하는 척 하는 루프. 진짜 검증이 아니라 검증처럼 보이는 행동. 팀이 외부 검증 훅을 설계하지 않으면, 에이전트의 자기 평가를 그대로 믿게 된다.
이 세 가지 실패 지점—플랜 오염, 비가역 실행, 자기 평가 맹점—을 제어하는 실용적인 접근이 Harness Engineering이다. 복잡한 오케스트레이션 코드가 아니다. 저장소 로컬에 심는 마크다운 기반 규칙 레이어다. AGENTS.md로 에이전트가 처음 읽을 우선순위와 동작 제약을 정의하고, TERMINAL_AND_GIT_RULES.md로 git add -A 같은 위험한 명령을 원천 차단하고, SESSION_HANDOFF_RULES.md로 세션 간 컨텍스트 누락을 막는다. Andrej Karpathy의 autoresearch에서 차용한 이 철학의 핵심은 단순하다. 에이전트의 행동 반경을 코드가 아니라 규칙으로 제한한다.
여기서 컨텍스트 윈도우 문제를 빼놓을 수 없다. 모델의 지식에는 훈련 컷오프가 있다. Claude Opus 4.6 기준 1백만 토큰의 컨텍스트 윈도우가 리포지토리 전체를 한 번에 넣을 수 있게 해줬지만, 그게 최신 문서를 안다는 뜻은 아니다. RAG—Retrieval-Augmented Generation—가 필요한 이유다. 6개월 전 문서를 읽은 동료가 아니라, 지금 막 풀업한 동료와 일하는 구조를 시스템이 보장해야 한다. 이건 모델 선택의 문제가 아니라 워크플로우 설계의 문제다.
Cursor로 VS Code에서 전환한 개발자의 솔직한 경험이 이 맥락에서 의미 있는 이유는 생산성 수치 때문이 아니다. 그가 "툴 체인지는 쉬웠다. 습관 체인지가 진짜 작업이었다"고 말한 지점이다. 인라인 편집이 빨라지고, 코드베이스를 컨텍스트로 가진 채 질문할 수 있게 됐지만—여전히 모든 diff를 PR처럼 리뷰해야 했다. 에이전트가 자신감 있게 틀린 코드를 쓴다는 사실은 Cursor를 써도, Claude Code를 써도 변하지 않았다. 도구가 날카로워질수록 팀의 검증 습관이 더 중요해지는 역설이다.
팀 실행 관점에서 지금 당장 할 수 있는 건 세 가지로 수렴된다. 첫째, 플랜 리뷰 게이트를 스프린트 프로세스에 박아넣기. 에이전트가 실행 전 플랜을 외부에 노출하고, 사람이 승인하는 단계를 명시적으로 설계한다. 둘째, 저장소에 Harness 레이어 추가. 2000자 시스템 프롬프트보다 저장소 로컬 규칙 파일이 에이전트의 행동을 더 안정적으로 제어한다. 셋째, 에이전트의 침묵을 신호로 처리. 진행을 보고해야 할 에이전트가 조용하면, 그건 완료가 아니라 조사가 필요한 신호다.
에이전트 루프는 멈추지 않는다. 목표가 달성되거나, 해결할 수 없는 것에 막혀 당신에게 올라오거나. 문제는 '조용히 잘못된 방향으로 달리는' 세 번째 경우다. 팀이 설계해야 할 것은 에이전트를 얼마나 빠르게 도입하느냐가 아니라, 에이전트가 조용히 실패할 때 그걸 얼마나 빨리 알아챌 수 있느냐다. 그 감지 구조를 먼저 설계한 팀이 에이전트를 실제로 믿고 쓸 수 있다.