Phase 1515-5

루프 엔지니어링 — 프롬프트 치는 사람에서 루프 설계하는 사람으로

5단 진화의 정점, 루프 엔지니어링을 배웁니다. 매번 직접 지시하는 대신 AI가 스스로 일감을 찾고 실행하고 검증하는 루프를 설계하는 방법, 5가지 구성요소, effort·종료 조건·상태 관리, 그리고 노무사무소에 적용하는 실전 패턴을 다룹니다.

Execution Kit

실습 중 막히지 않기 위한 진행표

Phase 15

준비

강의 전 현재 폴더, 계정, 설치 상태를 확인합니다.

실행

루프엔지니어링은 '프롬프트를 주는 사람 역할 자체를 시스템으로 대체'하는 5단 진화의 정점으로, 프롬프트→컨텍스트→하네스→에이전트의 마지막 단계입니다.

검증

명령 결과, 파일 변화, 브라우저 화면 중 하나로 성공 여부를 확인합니다.

기록

잘 된 명령과 막힌 지점을 다음 실습을 위한 로그로 남깁니다.

막혔을 때 Claude Code에 붙여넣을 양식

나는 코딩 경험이 많지 않은 실무자입니다. "루프 엔지니어링 — 프롬프트 치는 사람에서 루프 설계하는 사람으로" 강의를 따라 하고 있습니다.

현재 상태:
- 사용하는 컴퓨터:
- 방금 실행한 명령:
- 화면에 나온 결과 또는 오류:
- 내가 만들고 싶은 업무 결과물:

요청:
1. 지금 상황을 초보자 기준으로 진단해줘.
2. 다음에 실행할 명령을 한 줄씩 제시해줘.
3. 각 명령이 무엇을 하는지 쉬운 말로 설명해줘.
4. 성공 여부를 확인할 체크 포인트를 정리해줘.
5. 실패하면 다시 붙여넣을 오류 보고 양식을 만들어줘.

루프 엔지니어링이란? — 레버리지가 이동했다

이제 5단 진화의 정점에 도착했습니다. 프롬프트엔지니어링(무슨 말을 할까) → 컨텍스트엔지니어링(무슨 정보를 줄까) → 하네스엔지니어링(어떤 시스템을 만들까) → 에이전트엔지니어링(누구에게 맡길까). 그 다음이 루프 엔지니어링(Loop Engineering)입니다. 핵심 문장은 이것입니다. "에이전트에게 프롬프트를 주는 사람 역할 자체를 시스템으로 대체한다." 지금까지는 노무사가 매번 Claude Code를 열고, 지시하고, 결과를 보고, 다음 지시를 했습니다. 루프엔지니어링에서는 '무엇을 시킬지 결정하고, 실행하고, 결과가 괜찮은지 판단하는' 그 사이클 자체를 자동 시스템으로 만듭니다. 프롬프트엔지니어링이 한 번의 지시문을 다듬는 일이라면, 루프엔지니어링은 '언제, 무엇을, 어떤 기준으로 지시하고 종료할지'를 설계하는 일입니다. 구글 엔지니어링 리더 Addy Osmani가 2026년 6월 정리한 이 개념은 발표 직후 AI 업계의 표준 용어로 자리잡고 있습니다. 비유하자면 이렇습니다. 지금까지 여러분은 유능한 직원(AI)에게 일을 '시키는' 관리자였습니다. 루프엔지니어링은 그 직원이 매일 아침 스스로 할 일을 찾고, 처리하고, 검수받고, 보고서를 올리는 '업무 체계'를 만드는 일입니다. 노무사가 자문 사업장에 인사관리 시스템을 설계해주듯, 이제 AI에게 업무 시스템을 설계해주는 것입니다.
TIP: 프롬프트를 잘 쓰는 능력은 여전히 루프의 부품으로 필요합니다. 패러다임이 바뀐 게 아니라, 그 능력을 담는 그릇이 5단계에 걸쳐 점점 커진 것입니다. 15-1부터 여기까지가 하나의 연결된 이야기입니다.

루프의 5가지 구성요소

잘 설계된 루프에는 다섯 가지 부품이 들어갑니다. 모두 이 강의에서 이미 배운 것들의 조합입니다. [1. 자동화(Automations) — 일감을 스스로 발견] 일정 기반으로 작업을 찾아 분류합니다. Claude Code의 /loop, 예약 작업(스케줄), cron이 여기 해당합니다. 예: 매일 아침 8시, 어제 들어온 자문 메일을 분류하고 답변 초안 작성. [2. 워크트리(Worktrees) — 병렬 작업의 충돌 방지] 여러 에이전트가 동시에 일할 때 각자 독립된 작업 공간(git 분기)에서 작업해 서로 간섭하지 않게 합니다. Phase 10·13의 워크트리와 울트라코드가 내부적으로 쓰는 방식입니다. [3. 스킬(Skills) — 매번 다시 가르치지 않기] 프로젝트 지식을 SKILL.md로 문서화해두면, 루프가 돌 때마다 처음부터 학습할 필요가 없습니다. Phase 5에서 만든 /임금계산, /취업규칙검토가 루프의 부품이 됩니다. [4. 플러그인·커넥터(MCP) — 제안이 아닌 실행] MCP로 이메일·캘린더·법령 DB(korean-law)·블로그를 연결하면 루프가 '초안을 제안'하는 데서 끝나지 않고 실제 행동(발행·등록·전송)까지 수행합니다. [5. 서브에이전트(Sub-agents) — 작성자와 검증자 분리] 글을 쓰는 에이전트와 검증하는 에이전트를 분리합니다. 15-4에서 배운 '작성 → 검증 분리'가 루프 안에서 자동으로 돌아가는 것입니다. 자기가 쓴 글을 자기가 검수하면 오류를 못 잡기 때문입니다.

종료 조건과 상태 관리 — 루프가 폭주하지 않으려면

루프 설계에서 초보자가 가장 많이 빠뜨리는 두 가지가 종료 조건과 상태 관리입니다. [종료 조건(Goal)] "언제 멈출 것인가"를 명확히 정의해야 합니다. Claude Code의 goal 메커니즘은 "모든 테스트 통과 + 린트 통과"처럼 검증 가능한 정지 조건을 설정하고, 매 턴마다 별도의 소형 모델이 충족 여부를 판단해 자동 종료합니다. 노무 업무로 번역하면: "신착 판례 5건 요약 완료 + 사건번호 전부 korean-law 검증 통과"가 종료 조건입니다. "적당히 잘 정리되면"같은 모호한 조건은 루프를 무한히 돌게 하거나 엉뚱한 데서 멈추게 합니다. [상태 관리(메모리)] 에이전트는 세션이 끝나면 기억을 잃습니다. 그래서 루프는 진행 상황을 외부 저장소(마크다운 파일, 작업 보드)에 기록해야 합니다. 오늘 루프가 "사업장 A·B 검토 완료, C는 자료 대기"라고 파일에 남기면, 내일 루프는 C부터 이어서 시작합니다. 15-2에서 배운 컨텍스트 관리와 옵시디언 볼트가 바로 이 역할을 합니다. 볼트의 memory 폴더에 루프가 일지를 쓰게 하면, 사람 직원의 업무일지와 똑같은 구조가 됩니다.
TIP: 종료 조건은 반드시 '기계가 판정 가능한' 형태로 쓰세요. '품질이 좋으면'(판정 불가) 대신 '검증 도구 통과 + 분량 800자 이상 + 사건번호 0건 오류'(판정 가능)로.

비용 설계 — effort와 Task Budget으로 루프를 통제

루프는 자율적으로 돌기 때문에 토큰 비용이 들쭉날쭉합니다. 이를 통제하는 두 가지 장치가 2026년 모델에 있습니다. [effort — 작업 깊이 조절] 13-9에서 배운 effort(low/medium/high/xhigh/max)는 루프 설계에서 비용 레버가 됩니다. 정석은 '루프 본문은 중형 모델·낮은 effort로, 최종 검증만 상위 모델·높은 effort로'입니다. 모든 단계를 max로 돌리면 비용이 폭발합니다. [Task Budget — 토큰 예산 통보] Task Budget은 "이 작업 전체에 토큰을 얼마까지 쓸 수 있다"를 에이전트에게 미리 알려주는 기능입니다. 에이전트는 남은 예산을 보며 스스로 작업을 조절하고, 예산이 줄면 우선순위가 높은 일부터 마무리합니다. 노무사 적용: 매일 도는 '신착 판례 정리' 루프는 낮은 effort + 예산 상한으로, 가끔 도는 '중대재해 전방위 분석' 루프는 높은 effort로. 일상 루프와 핵심 루프의 비용을 구분 설계하는 것이 운영의 핵심입니다.

실전: 한동노무법인식 아침 루프 설계

지금까지 배운 5단계를 모두 조립해 실제 루프를 설계해봅시다. 시나리오: 매일 아침 노무사가 출근하기 전, AI가 콘텐츠 업무를 준비해두는 루프. [아침 7시, 루프 가동] 1. 자동화: 예약 작업이 루프를 깨움 2. 일감 발견: 어제 고용노동부 보도자료·신착 판례를 수집해 블로그 소재 후보 3건 선정 3. 워크트리: 소재별로 독립 작업 공간 생성 4. 작성 에이전트: 스킬(블로그 작성 규칙)을 불러 초안 작성 5. 검증 에이전트: 사건번호·법조문을 korean-law MCP로 교차 검증, 실패 건은 반려 6. 상태 기록: 옵시디언 볼트에 "초안 2건 통과, 1건 반려(판례 미확인)" 일지 작성 7. 종료 조건 충족 → 루프 종료, 노무사에게 요약 보고 [아침 9시, 노무사 출근] 완성 초안 2건을 검토하고 발행 여부만 결정합니다. 4시간짜리 작업이 20분 검토로 줄었습니다. 여기서 중요한 설계 원칙: 루프는 '발행' 직전에 멈춥니다. 외부로 나가는 최종 결정(발행·전송·제출)은 반드시 사람이 합니다. 루프엔지니어링은 사람을 빼는 기술이 아니라, 사람의 판단을 가장 가치 있는 지점에 배치하는 기술입니다.
# 한동노무법인식 아침 콘텐츠 루프 (개념 설계)

  ## 트리거
  매일 07:00 예약 실행

  ## 루프 본문 (낮은 effort로 비용 절감)
  1. 신착 수집: 고용부 보도자료 + 신착 판례 검색
  2. 소재 선정: 자문 고객 관심사 기준 상위 3건
  3. 각 소재마다:
     - 작성 에이전트: 블로그 초안 (블로그 스킬 적용)
     - 검증 에이전트: verify_citations로 인용 검증 (높은 effort)
     - 실패 시: 1회 재작성 → 재실패 시 반려함으로
  4. 볼트 memory/에 작업 일지 기록

  ## 종료 조건 (기계 판정 가능)
  - 통과 초안 >= 2건 OR 후보 소진
  - 모든 사건번호 검증 통과

  ## 사람의 자리
  - 발행 결정은 노무사만 (루프는 초안까지)

주의점 — 루프가 빠를수록 생기는 빚

루프엔지니어링의 함정도 분명합니다. Addy Osmani가 경고한 세 가지를 노무사 버전으로 옮기면: [1. 토큰 비용의 예측 불가능성] 루프는 자율적으로 돌기 때문에 토큰 사용량이 들쭉날쭉합니다. 특히 Fable 5처럼 단가 높은 모델로 루프를 돌리면 비용이 빠르게 누적됩니다. 루프 본문은 중형 모델·낮은 effort로, 최종 검증만 상위 모델로 설계하는 것이 정석입니다. [2. 이해도 부채(Comprehension Debt)] 루프가 빨라질수록 '내가 검토하지 않은 산출물'이 쌓입니다. 노무사에게 이것은 치명적입니다. 내 이름으로 나가는 의견서의 논리를 내가 설명하지 못하는 상황은 있어선 안 됩니다. 루프 산출물의 정기 표본 검토를 루틴에 넣으세요. [3. 인지적 항복(Cognitive Surrender)] 루프 설계를 '생각을 피하는 수단'으로 쓰면 품질이 무너집니다. 같은 자동화도 '검토 시간을 핵심 판단에 재배치'하려는 의도면 무기가 되고, '귀찮은 일을 안 보려는' 의도면 부메랑이 됩니다. 결론은 한 문장입니다. 루프는 노무사를 대체하지 않습니다. 루프를 설계하는 노무사가, 설계하지 않는 노무사를 대체할 뿐입니다.
TIP: 첫 루프는 작게 시작하세요. '매일 아침 신착 판례 요약 1건'처럼 실패해도 무해한 루프로 감을 잡은 뒤, 검증 단계를 붙이고, 그 다음에 실행 권한을 넓히는 순서가 안전합니다.

핵심 정리

  • ✓루프엔지니어링은 '프롬프트를 주는 사람 역할 자체를 시스템으로 대체'하는 5단 진화의 정점으로, 프롬프트→컨텍스트→하네스→에이전트의 마지막 단계입니다.
  • ✓루프의 5대 부품은 자동화(일감 발견)·워크트리(병렬 격리)·스킬(지식 재사용)·MCP 커넥터(실제 실행)·서브에이전트(작성-검증 분리)입니다.
  • ✓종료 조건은 기계가 판정 가능한 형태로 정의하고, 진행 상황은 외부 파일(옵시디언 볼트)에 기록하며, effort와 Task Budget으로 루프 비용을 통제합니다.
  • ✓발행·전송·제출 같은 최종 결정은 반드시 사람이 하며, 이해도 부채를 막기 위해 루프 산출물의 정기 표본 검토를 루틴화합니다. 루프는 노무사를 대체하지 않고, 루프를 설계하는 노무사가 그렇지 않은 노무사를 대체합니다.

이 강의가 어떠셨나요?