Loop Engineering: 이제 Claude에게 프롬프트를 쓰지 마세요. 루프를 설계하세요

Loop Engineering: 이제 Claude에게 프롬프트를 쓰지 마세요. 루프를 설계하세요

지난 2년 동안 우리는 코딩 에이전트에게 프롬프트를 쓰고, 응답을 기다리고, 다시 프롬프트를 쓰는 방식으로 일해왔습니다. 그런데 몇 주 전 Anthropic의 Claude Code를 만든 Boris Cherny와 OpenAI의 Peter Steinberg가 같은 이야기를 했습니다. "이제 프롬프트를 쓰지 마세요. 루프를 설계하세요." Builders Central의 이 10분짜리 영상은 Loop Engineering의 실체를 코드와 데모로 보여줍니다.

1. Boris Cherny의 폭탄 발언: "나는 이제 Claude에게 프롬프트를 쓰지 않는다" (00:00:00)

Claude Code를 만든 Boris Cherny가 최근 이렇게 말했습니다. "나는 이제 Claude에게 프롬프트를 쓰지 않는다. 나에게는 실행되는 루프들이 있고, 그 루프들이 Claude에게 프롬프트를 쓴다. 내 일은 루프를 쓰는 것이다." Peter Steinberg 역시 같은 이야기를 했고, 이 트윗은 수백만 조회수를 기록하며 바이럴되었습니다. 그런데 사람들의 첫 반응은 대부분 이랬습니다. "그게 도대체 무슨 뜻이야?"

2. Loop Engineering이란? 조립공에서 공장 소유자로 (00:00:41)

이것을 Loop Engineering이라 부릅니다. 비유하자면, 당신은 이제 공장의 조립 라인 노동자가 아니라 공장의 소유자입니다. 다음 지시를 직접 타이핑하는 대신, 지시를 대신 타이핑하는 시스템을 설계합니다. 예전 모델: 프롬프트 → 에이전트 → 응답 → 다시 프롬프트. 새 모델: 루프 설계 → 루프가 에이전트에게 프롬프트 → 에이전트 작업 → 루프 검증 → 필요하면 루프가 다시 프롬프트 → 완료.

3. 루프의 4단계: Discovery, Execution, Checking, Deciding (00:01:20)

루프는 결국 반복되는 4가지 단계일 뿐입니다. ① Discovery — 할 일을 찾는다 (실패한 테스트, 새 이슈, 대기 중인 태스크). ② Execution — 실제로 작업을 수행한다. ③ Checking — 잘 되었는지 확인한다. ④ Deciding — 끝인가, 아니면 한 번 더 돌 것인가. 이것이 스크립트와 루프의 결정적 차이. 스크립트는 "A→B→C" 고정 시퀀스지만, 루프는 현재 상태를 읽고 판단합니다.

4. 루프의 계보: ReAct → AutoGPT → Ralph loop → /goal (00:01:56)

사실 이 개념은 새로운 것이 아니라 새롭게 상품화된 것입니다. 2022년 Princeton과 Google의 ReAct 논문(reason-act-observe-repeat), 2023년 AutoGPT (영원히 스핀만 돌던 그 실험), 2025년 Ralph loop (테스트 통과할 때까지 Claude를 도는 bash one-liner), 2026년에는 마침내 `/goal` 명령이 코딩 에이전트의 1급 기능으로 탑재되었습니다.

5. 루프의 5가지 필수 구성 요소 (00:02:34)

제대로 동작하는 루프는 반드시 5가지 구성 요소를 갖습니다. ① Trigger — 루프를 시작하는 것 (스케줄, 웹훅, /goal 입력). ② Worktrees — 병렬 에이전트가 서로 충돌하지 않도록 격리된 git 브랜치. ③ Skills — 매 실행마다 에이전트가 읽는 프로젝트 지식(컨벤션, 스택, 사고 이력). ④ Connectors — MCP 도구로 GitHub, Slack, Linear, DB 접근. ⑤ Memory — 실행 간에 살아남는 상태(to-do.md, progress 파일). 핵심 통찰: 모델은 실행 사이에 모든 걸 잊지만 레포는 잊지 않는다.

6. /goal vs /loop: 두 명령의 결정적 차이 (00:03:37)

Claude Code에는 두 개의 루프 명령이 있습니다. `/goal`은 조건이 충족될 때까지 계속 작업합니다. 예: `/goal all tests pass` → 테스트 실행, 실패 확인, 수정, 재실행, 전부 통과할 때까지 반복 후 자동 정지. 단, 목표는 반드시 검증 가능해야 합니다. "코드를 더 좋게 만들어라"는 안 됩니다(측정 불가). `/loop`은 스케줄로 반복 실행, 사용자가 종료할 때까지 계속됩니다. `/goal`은 결승선 주도, `/loop`은 시계 주도입니다.

7. 데모 ①: /goal로 실패한 테스트 4개를 26초에 자동 수정 (00:05:00)

화자는 자신이 만든 인도용 전화번호/OTP 유틸리티 라이브러리를 예시로 사용합니다. 5개 테스트가 실패 중(OTP가 6자리 대신 5자리, 4자리 요청에 3자리 반환 등). 평소라면 오류 읽기 → Claude에게 수정 지시 → 재실행 → 다시 반복. `/goal`로는 한 번의 명령으로 Claude가 모든 소스를 읽고, 버그를 주석으로 표시하고, 수정합니다. 결과: 15개 테스트 전부 통과, 4개 버그 수정, 소요 시간 26초. 좋은 목표는 지루하게 들립니다 — "테스트 통과, 린트 에러 없음, 빌드 성공." 이것이 루프가 실제로 검증할 수 있는 것입니다.

8. 데모 ②: 매일 아침 CI/이슈 트리아지를 자동화하는 /loop skill (00:06:07)

두 번째 데모는 매일 아침 자동 실행되는 트리아지 루프. 화자는 daily-triage skill 파일을 하나 작성합니다. 이 skill은 GitHub 이슈에서 bug/enhancement 라벨 확인 → 최신 CI 실행 상태 조회 → 우선순위 정렬된 액션 리스트로 to-do.md를 재작성 (CI 실패가 최상단, 최대 10개, 하단에 타임스탬프). Claude가 어제 실행의 to-do.md와 오늘의 상태를 비교합니다 — 이것이 Memory 프리미티브의 실전 사용입니다. 이 skill을 매일 오전 9시 IST에 클라우드 스케줄로 등록하면, 노트북을 닫아둬도 매일 아침 우선순위 리스트가 준비되어 있습니다.

9. Prompt → Context → Loop Engineering (00:08:20)

우리는 Prompt Engineering으로 시작해서 Context Engineering을 거쳐 이제 Loop Engineering 시대에 도착했습니다. 각 층은 이전 층을 감쌉니다. 프롬프트는 좋은 응답 하나를 얻게 해주고, 컨텍스트는 윈도우에 올바른 정보를 넣게 해주며, 루프는 전체가 스스로 돌아가게 만듭니다. Boris가 "내 일은 루프를 쓰는 것"이라고 말한 진짜 의미는 레버리지 포인트가 이동했다는 것입니다. 이제 스킬은 완벽한 프롬프트를 쓰는 게 아니라 프롬프트를 쓰는 시스템을 설계하는 것입니다.

10. 언제 루프를 써야 하고, 언제 돈만 태우는가 (00:09:39)

주의: 감시받지 않는 루프는 실수도 감시받지 않은 채로 쌓입니다. 목표는 밤새 마법같이 일하는 에이전트가 아니라, 명확한 결승선 + 검증 단계 + 결과를 실제로 읽는 사람이 있는 좁은 자동화입니다. 시작 팁: ① 측정 가능한 것부터 시작(테스트 통과, 린트 에러 없음, 빌드 성공). ② 밤새 도는 루프로 시작하지 마세요. 3분짜리 지켜볼 수 있는 루프부터. ③ 그게 되면 skill을 추가. ④ skill이 되면 스케줄링. 이것이 당신의 첫 공장입니다.

이 리포트는 Builders Central의 "I Stopped Prompting Claude Code. Now Loops Do It For Me" 영상(약 10분)을 요약한 것입니다. 원본 영상: YouTube에서 보기