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

지금까지의 진화를 복기해봅시다. 프롬프트엔지니어링(무슨 말을 할까) → 컨텍스트엔지니어링(무슨 정보를 줄까) → 하네스엔지니어링(어떤 시스템을 만들까). 2026년 중반, 그 다음 단계가 왔습니다. 루프엔지니어링(Loop Engineering)입니다. 핵심 문장은 이것입니다. "에이전트에게 프롬프트를 주는 사람 역할 자체를 시스템으로 대체한다." 지금까지는 노무사가 매번 Claude Code를 열고, 지시하고, 결과를 보고, 다음 지시를 했습니다. 루프엔지니어링에서는 '무엇을 시킬지 결정하고, 실행하고, 결과가 괜찮은지 판단하는' 그 사이클 자체를 자동 시스템으로 만듭니다. 프롬프트엔지니어링이 한 번의 지시문을 다듬는 일이라면, 루프엔지니어링은 '언제, 무엇을, 어떤 기준으로 지시하고 종료할지'를 설계하는 일입니다. 구글 엔지니어링 리더 Addy Osmani가 2026년 6월 정리한 이 개념은 발표 직후 AI 업계의 표준 용어로 자리잡고 있습니다. 비유하자면 이렇습니다. 지금까지 여러분은 유능한 직원(AI)에게 일을 '시키는' 관리자였습니다. 루프엔지니어링은 그 직원이 매일 아침 스스로 할 일을 찾고, 처리하고, 검수받고, 보고서를 올리는 '업무 체계'를 만드는 일입니다. 노무사가 자문 사업장에 인사관리 시스템을 설계해주듯, 이제 AI에게 업무 시스템을 설계해주는 것입니다.

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

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

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

# 한동노무법인식 아침 콘텐츠 루프 (개념 설계)

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

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

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

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

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