루프 엔지니어링

루프란

루프는 재귀적인 목표다. 목적을 정해 두면 AI가 끝날 때까지 스스로 반복한다.

코딩 에이전트를 쓰는 기본 방식은 한 턴씩 프롬프트를 주는 것이다. 루프 엔지니어링은 그 대신 일을 찾고, 맡기고, 검증하고, 진행을 기록하고, 다음 단계를 고르는 시스템을 설계한다. 프롬프트는 시스템이 대신 넣는다.

루프는 사람이 없을 때도 돌기 때문에 토큰 비용이 쓰는 방식에 따라 크게 달라진다. 간격, 서브에이전트 수, 종료 조건을 정해 비용을 관리한다.

어디에 위치하나

과거에는 루프를 bash 스크립트로 직접 짰지만, 지금은 핵심 부품이 Claude Code나 Codex 같은 에이전트 도구 안에 기본으로 들어 있다.

구성 요소: 다섯 가지 + 메모리

모델은 실행 사이에 기억을 잃는다. 하지만 저장소는 잊으면 안 된다.

끝날 때까지 돌리기: Claude Code의 /goal <조건>은 매 턴이 끝날 때 별도의 작은 모델이 "정해 둔 조건이 충족됐는가"를 판정하고, 아니면 다음 턴을 이어 간다. 충족되거나 불가능하다고 판정되면 멈춘다. 코드를 쓴 에이전트가 자기 채점을 하지 않게 하는 장치다. 평가 모델은 대화에 드러난 것만 보므로, 조건은 "npm test가 0으로 끝난다"처럼 출력으로 증명할 수 있게 쓴다.

실천 원칙

• 만드는 쪽과 검사하는 쪽을 분리한다. 코드를 쓴 모델은 자기 결과물의 좋은 리뷰어가 아니다. 흔한 분업은 탐색 → 구현 → 스펙 대비 검증. 가능하면 검증자는 다른 모델이나 다른 지시로 돌린다.
• 토큰은 의도적으로 쓴다. 서브에이전트는 토큰 사용량을 몇 배로 늘린다. 두 번째 의견이 그 값을 하는 곳에만 쓴다.
• 병렬 작업엔 워크트리. 파일 충돌은 막아 주지만, 동시에 몇 개를 돌릴 수 있는지는 결국 리뷰하는 사람이 병목이다.
• 의도는 스킬에 새긴다. 컨벤션, 빌드 절차, 지난번에 배운 교훈을 스킬로 남겨야 루프가 매번 프로젝트를 처음부터 다시 파악하지 않고 지식이 쌓인다. 스킬 description은 영리한 문장보다 짧고 평범한 문장이 잘 먹힌다.
• 상태는 디스크에 둔다. 시도한 것, 결과, 남은 일을 상태 파일에 적어 다음 실행이 멈춘 곳에서 이어 가게 한다.

예시 루프

flowchart TB
  n1["매일 아침 자동화 실행"] --> n2["트리아지 스킬로 지난 CI 실패·열린 이슈·최근 커밋을 읽음"]
  n2 --> n3["발견한 것을 마크다운 파일 / Linear 보드에 기록"]
  n3 --> n4["손댈 가치가 있는 항목마다"]
  n4 --> n5["격리된 워크트리 생성"]
  n4 --> n6["서브에이전트 A: 수정안 작성"]
  n4 --> n7["서브에이전트 B: 스킬·테스트 기준으로 리뷰"]
  n4 --> n8["커넥터로 PR 열고 티켓 갱신"]
  n1 --> n9["해결 못 한 것은 사람의 트리아지 인박스로"]

한계와 위험

• 검증은 여전히 내 몫이다. "완료"는 주장이지 증명이 아니다. 지켜보는 사람이 없는 루프는 실수도 지켜보는 사람 없이 한다.
• 이해 부채(comprehension debt): 내가 쓰지 않은 코드를 배포할수록, 존재하는 코드와 내가 이해하는 코드 사이의 간극이 벌어진다.
• 인지적 항복(cognitive surrender): 판단 없이 루프 결과를 받아들이면 루프의 이점이 사라진다. 같은 루프가 이해를 넓히는 도구도, 이해를 피하는 수단도 될 수 있다.

정리

• 루프 설계는 프롬프트 엔지니어링보다 어렵다. 힘을 줘야 할 지점이 옮겨 갔을 뿐, 일이 사라진 건 아니다.
• 직접 프롬프트하는 방식도 여전히 쓸모가 있다. 어느 쪽을 쓸지는 작업에 따라 다르다.
• 똑같은 루프를 만들어도 결과는 정반대일 수 있다. 차이는 그 일을 이해하고 있는가에서 난다.

루프는 만들되, 엔지니어로 남는다.

관련 노트: 내 일을 줄이는 하네스 만들기, Claude 스킬 만들기 가이드, Claude Code 활용 가이드, 디자인 시스템을 아는 화면 생성 에이전트 설계하기, 프롬프트에서 하네스로: 에이전틱 패턴의 진화