프롬프트 입력에서 루프 설계로의 작업 방식 전환

매 세션마다 프로젝트 컨텍스트와 코딩 규칙을 다시 설명하는 번거로움이 사라진다. 에이전트에 직접 지시하는 프롬프트 방식 대신, 에이전트를 구동하고 관리하는 '루프(Loop)' 시스템을 설계하는 '루프 엔지니어링'이 그 자리를 대체한다. 루프는 사용자가 목적을 정의하면 AI가 완료될 때까지 작업을 반복 수행하는 재귀적 목표(recursive goal) 체계다. 지난 2년이 한 턴씩 응답을 주고받는 도구적 활용의 시대였다면, 이제는 작업 분배와 검증, 기록을 자동화하는 작은 시스템이 에이전트를 제어하는 시대로 바뀐다.

피터 스타인버거(Peter Steinberger)는 이제 에이전트에 프롬프트를 입력하는 행위를 멈추고, 프롬프트를 실행하는 루프를 설계하라고 조언한다. 앤스로픽(Anthropic)의 클로드 코드(Claude Code) 책임자 보리스 체르니(Boris Cherny) 역시 무엇을 할지 정하는 루프를 작성하는 것이 현재의 핵심 업무라고 정의한다. 이는 에이전트 작동 환경을 만드는 '에이전트 하네스 엔지니어링'과 소프트웨어 생산 체계인 '팩토리 모델'을 포괄하는 개념이다. 사람이 수행하던 입력자의 역할을 시스템이 대체하며 레버리지 지점이 설계의 영역으로 옮겨간 것이다.

루프를 구성하는 5가지 핵심 요소와 상태 관리 체계

루프 시스템은 Automations, Worktrees, Skills, Plugins·connectors, Sub-agents라는 다섯 가지 요소와 상태 저장을 위한 메모리로 구축된다. 클로드 코드와 코덱스(Codex)는 이 구성 요소를 모두 탑재했다. 먼저 Automations는 루프의 심장 박동이다. 코덱스는 Automations 탭에서 실행 프롬프트와 주기를 설정하며, 클로드 코드는 `/loop` 명령어나 cron 작업, GitHub Actions와 연동해 노트북을 닫은 상태에서도 작업을 지속한다.

Worktrees는 여러 에이전트가 동시 작업할 때 발생하는 파일 충돌을 막는다. git worktree를 통해 동일 저장소 히스토리를 공유하면서도 브랜치별로 작업 디렉터리를 격리한다. 코덱스는 이 기능을 내장했고, 클로드 코드는 `--worktree` 플래그와 `isolation: worktree` 설정으로 헬퍼 에이전트가 독립된 환경에서 작업 후 스스로 정리하게 만든다. Skills는 매번 지식을 다시 설명해야 하는 '금붕어 현상'을 해결한다. `SKILL.md` 폴더에 컨벤션과 빌드 단계를 기록해두면, 에이전트가 실행 때마다 이를 읽어 의도의 빈틈을 메운다.

Plugins·connectors는 MCP(Model Context Protocol)를 통해 에이전트를 외부 도구와 연결한다. 이슈 트래커 읽기, DB 질의, API 호출, 슬랙(Slack) 전송 등이 가능해진다. Sub-agents는 코드 작성자와 검사자를 분리한다. 코덱스는 `.codex/agents/`의 TOML 파일로, 클로드 코드는 `.claude/agents/`를 통해 에이전트 팀을 구성한다. 여기에 마크다운 파일이나 Linear 보드 같은 메모리 체계를 더해, 단일 대화창을 넘어선 작업의 연속성을 유지한다.

검증 가능한 정지 조건과 엔지니어의 판단 기준

실무 생산성은 이제 단순한 프롬프트 작성 능력이 아니라, 에이전트 간 역할 분담(Maker-Checker)과 상태 관리 설계 능력에서 갈린다. 특히 `/goal` 명령어는 설정한 조건이 참이 될 때까지 작업을 반복하는 '검증 가능한 정지 조건'을 만든다. 코드를 쓴 에이전트가 스스로 채점하는 오류를 막기 위해, 별도의 작은 모델이 투입되어 완료 여부를 검사한다. 예를 들어 "test/auth의 모든 테스트 통과, lint clean"이라는 조건을 걸면, 루프는 메이커(Maker)와 체커(Checker)가 턴을 주고받으며 조건 충족 시까지 작동한다.

다만 루프가 고도화될수록 엔지니어는 세 가지 위험을 관리해야 한다. 첫째는 검증의 책임이다. 무인 루프의 "완료(done)"는 증명이 아니므로 최종 검증은 여전히 사람의 몫이다. 둘째는 이해 부채(comprehension debt)다. 루프가 짠 코드를 읽지 않고 출하할수록 개발자의 이해도와 실제 코드 사이의 간극이 벌어진다. 셋째는 인지적 굴복(cognitive surrender)이다. 자동화의 편안함에 익숙해져 결과물을 비판 없이 수용하는 위험이다.

결국 루프 엔지니어링의 성패는 시스템을 구축하면서도 엔지니어로서의 판단력을 유지하는 데 있다. 루프는 반복 작업을 자동화해 레버리지를 높이는 도구일 뿐, 제품 품질의 하향 나선을 막는 것은 직접 코드를 리뷰하고 동작을 확인하는 엔지니어링 본연의 역할이다. 이제 개발자의 역량은 '어떤 프롬프트를 쓰느냐'가 아니라, '어떤 역할 분담과 상태 관리 루프를 설계하느냐'로 판단된다.