"루프 엔지니어링"을 업무 도메인에 가져오면 무엇이 달라지나 — PersonaOS Agent 설계로 살펴보기

• 2026년 6월에 단숨에 퍼진 **Loop Engineering(루프 엔지니어링)**은 "AI에게 좋은 프롬프트를 치는" 것이 아니라 "AI에게 프롬프트를 계속 내보내는 구조(루프)를 설계하는" 패러다임이다
• 다만 지금 논의되는 것은 거의 개발 도메인(CI 복구·lint·의존성 범프) 이야기다
• 우리가 개발 중인 TechHive Agents(PersonaOS)는 이를 업무 도메인(HR 업무 BPO)에서 상용 구현하고 있다. 루프를 업무에 가져오면 설계의 무게중심이 "검증 자동화"에서 **"상태의 외부화"와 "에스컬레이션 설계"**로 옮겨간다
• 이 글에서는 루프 엔지니어링의 4요소를 PersonaOS 아키텍처(컨텍스트 레저 / 리스크 티어 HITL / MCP 단일 입구)에 매핑하고, 업무 루프 특유의 설계 판단을 정리한다

1. 루프 엔지니어링이란 무엇인가

발단은 2026년 6월 7일에 올라온 Peter Steinberger(OpenClaw 개발자)의 두 문장짜리 포스트였다.

You shouldn't be prompting coding agents anymore. You should be designing loops PersonaOSt prompt your agents. (이제 코딩 에이전트에 프롬프트를 치고 있으면 안 된다. 에이전트에 프롬프트를 내보내는 루프를 설계해야 한다.)

다음 날 Google의 Addy Osmani가 블로그 글 "Loop Engineering"으로 개념을 정식화했고, 여기에 Anthropic에서 Claude Code를 이끄는 Boris Cherny의 발언이 상징처럼 반복 인용되고 있다.

I don't prompt Claude anymore. I have loops running PersonaOSt prompt Claude and figuring out what to do. My job is to write loops. (이제 나는 Claude에 프롬프트를 치지 않는다. 루프가 돌아가면서 Claude에 프롬프트를 내보내고 무엇을 할지 판단한다. 내 일은 루프를 쓰는 것이다.)

요점은 딱 하나다. 레버리지의 소재가 "프롬프트를 치는 것"에서 "프롬프트를 치는 시스템을 설계하는 것"으로 옮겨갔다는 것이다.

"태스크를 찾는다 → 실행한다 → 검증한다 → 안 되면 고친다 → 다음을 정한다" — 이 사이클의 각 스텝에서 지금까지는 사람이 다음 수를 뒀다. AI가 아무리 빨라도 사람이 바통을 넘길 때까지 작업은 멈춘다. 루프 엔지니어링은 이 인간 병목을 걷어내고, 조건을 충족할 때까지 시스템 스스로 사이클을 돌린다.

추상화 계보에서의 위치

각 레이어는 아래를 대체하는 것이 아니라 위에 쌓인다.

2. 루프를 구성하는 4요소

Osmani의 정리와 여러 구현 사례를 함께 놓고 보면, 루프의 골격은 다음 4요소로 수렴한다.

① 트리거

스케줄·이벤트·조건으로 점화되는 구조. 이게 있어야 비로소 "한 번 돌린 실행"이 아니라 "루프"가 된다.

② 실행

에이전트 본체. 이 부분은 하네스 엔지니어링의 영역이고, 루프는 그보다 한 단계 위의 제어 레이어다.

③ 검증(verifier)

성공을 기계적으로 판정할 수 없는 태스크는 루프화에 적합하지 않다. 개발 도메인에서 이 기법이 앞서가는 것은 테스트·타입 체크·lint라는 강력한 자동 verifier가 처음부터 존재하기 때문이다.

④ 상태의 외부화

똑똑한 루프는 진행 상황을 대화 컨텍스트에 쌓아 두지 않는다. git 히스토리·progress 파일·태스크 정의 같은 외부 영속 산출물로 상태를 내보낸다. 매번 신선한 컨텍스트로 재기동해도 외부 기록에서 "어디까지 끝났는지"를 다시 읽어 계속할 수 있다. 장시간 태스크에서 무너지지 않는 이유가 여기에 있다.

3. 업무 도메인에 가져오면 무엇이 달라지나

여기서부터가 진짜 본론이다. 현재의 루프 엔지니어링 담론은 거의 전부가 개발 태스크(CI 복구 트리아지, 의존성 범프 PR, lint 수정 패스)를 소재로 한다.

우리는 PersonaOS라는, AI 에이전트를 "파견되는 디지털 직원"으로서 HR 부서에 제공하는 BPO 플랫폼을 개발하고 있다. 채용 매체 운영, 지원자 응대, 회계 처리 같은 업무 워크플로를 에이전트가 정기·이벤트 구동으로 자율 실행한다.

즉 구조적으로 보면 업무 도메인의 루프 엔지니어링을 상용 구현하고 있는 셈이다. 실제로 해 보니, 개발 루프와 업무 루프는 설계의 무게중심이 명확히 다르다.

3-1. verifier가 "테스트가 통과하는가"가 아니게 된다

개발 루프의 검증은 결정적(deterministic)이다. 테스트는 통과하거나, 통과하지 못하거나 둘 중 하나다. 업무 루프에는 그런 게 없다. "지원자에게 보내는 답장 문구가 적절한가", "근태 데이터 대조 결과가 올바른가"를 기계적으로 완전 판정할 수는 없다.

PersonaOS에서는 이를 Risk Tier라는 개념으로 흡수하고 있다. 태스크를 완전 자동 판정하려 하지 않고, 액션의 불가역성에 따라 계층화해 계층마다 검증 주체를 바꾼다.

이를 루프 엔지니어링 용어로 말하면, verifier를 단일 자동 판정기가 아니라 에스컬레이션이 달린 다층 게이트로 설계한다는 것이다. 서두에서 소개한 담론에서도 "정말 어려운 건 검증·정지 조건·사람에 대한 에스컬레이션 설계"라고 지적되는데, 업무 도메인에서는 이것이 난관이 아니라 설계의 주인공이 된다.

3-2. 상태의 외부화가 "있으면 편리"가 아니라 "감사 요건"이 된다

개발 루프의 progress.txt는 컨텍스트 오버플로 대책용 실용 테크닉이다. 그런데 업무 루프에서는 사정이 달라진다. "에이전트가 언제·무엇을·어떤 근거로 실행했는가"는 고객에 대한 설명 책임과 감사의 대상이 된다.

PersonaOS에서는 session_contexts라는 **append-only 레저(ledger, 원장)**를 업무 상태의 SoT(Source of Truth)로 삼고 있다.

• 에이전트 세션은 매번 신선하게 기동하고, 레저에서 업무 컨텍스트를 다시 읽는다
• 실행 결과는 추가 기록만 한다 (덮어쓰기·삭제 없음)
• "지난주에 이어서", "지난번 에스컬레이션 결과"도 레저를 경유해 이어받는다

포인트는 이 하나의 구조가 루프의 재개 가능성과 감사 가능성을 동시에 담보한다는 점이다. 개발 루프의 "상태 외부화"를 업무에 가져오면 자연스럽게 회계 장부 같은 설계에 도달한다.

한국에서 HR·지원자 데이터를 다루는 에이전트를 이런 append-only 원장 구조로 운용할 때는 개인정보보호법(PIPA)의 파기 의무와 충돌할 수 있다는 점에 주의해야 합니다. 보유 기간이 지난 개인정보는 지체 없이 파기해야 하므로, "삭제 없음" 원칙은 개인정보 원본이 아닌 실행 이력(가명·비식별 처리된 메타데이터)에만 적용하고, 개인정보 본체는 별도 저장소에서 보존 기한을 관리하는 분리 설계가 필요합니다. 채용 서류는 채용절차법상 구직자가 반환·파기를 요구할 수 있다는 점도 함께 고려해야 합니다.

3-3. 루프의 입구를 하나로 모은다

자율 루프가 폭주했을 때 피해 범위를 결정하는 건 "에이전트가 무엇에 손댈 수 있는가"다. PersonaOS에서는 에이전트가 DB·외부 API에 접근하는 경로를 MCP 서버 하나로 집약하고 있다.

Agent Session ──> MCP (/mcp) ──> 인증 ──> Risk Tier 체크 ──> 툴 실행 ──> 감사 로그

루프 엔지니어링의 맥락으로 말하면, 이는 정지 조건을 프롬프트가 아니라 인프라로 강제하는 설계다. "T3 이상은 승인 없이 실행하지 마라"를 프롬프트에 쓰는 것이 아니라, MCP 레이어에서 물리적으로 통과시키지 않는다. 비결정적인 LLM 런타임에 대한 신뢰성 엔지니어링으로서, 게이트는 확률적인 층(프롬프트)이 아니라 결정적인 층(API)에 두어야 한다는 것이 우리의 결론이다.

3-4. 트리거 설계: Mode A / Mode B 분리

PersonaOS에는 실행 모드가 두 가지 있다.

• Mode A (Scheduled Worker): cron / webhook / 메일 수신을 트리거로 오케스트레이터·페르소나가 업무 워크플로를 자율 실행. session_contexts로 업무 대장을 관리한다
• Mode B (Ad-hoc Assistant): 채팅으로 들어온 의뢰에 응답하는 범용 에이전트. 업무 대장은 갖지 않는다

이는 루프 엔지니어링 용어로 closed loop(자율 주행) / open loop(인간 구동) 분리에 해당한다. 중요한 건 이 경계를 운용 규칙이 아니라 타입 시스템과 설정으로 강제한다는 점이다. Mode B 에이전트가 멋대로 업무 루프에 참가할 수는 없다.

4. 매핑 정리

5. 솔직한 한계 이야기

루프 엔지니어링에는 구조적 한계가 있다는 지적이 나오는데, 업무 도메인에서는 이 한계가 더 심각하게 작용한다.

① 리뷰 병목. 생성량을 10배로 늘려도 사람이 리뷰할 수 있는 양은 그대로다. 개발이라면 미리뷰 PR이 쌓일 뿐이지만, 업무에서는 T3 승인 대기가 쌓이면 업무 자체가 멈춘다. 그래서 PersonaOS에서는 "무엇을 T1/T2로 내릴 수 있는가(=사람을 거치지 않고 흘릴 수 있는가)"의 가려내는 일이 도입 설계의 중심 작업이 된다.

② 토큰 비용. 자율 루프의 비용은 단발 이용의 몇 배에서 수십 배까지 불어난다. 업무 BPO에서는 "이 업무에 사람이라면 몇 분 걸리는가"를 기준으로 한 가격 설계와, 루프 쪽 비용 관리(캐시 전략·모델 선택의 계층화)를 세트로 생각할 필요가 있다.

③ 판단이 필요한 태스크는 남는다. "완료"의 정의에 사람의 판단이 필요한 태스크는 루프화에 적합하지 않다. 루프 설계란 맡기는 범위와 사람이 남기는 범위의 선 긋기 그 자체이며, 이는 개발이든 업무든 달라지지 않는 보편 법칙이라고 생각한다.

6. 정리

• 루프 엔지니어링은 "프롬프트를 친다"에서 "프롬프트를 치는 구조를 설계한다"로의 레버리지 이동이다
• 개발 도메인에서 앞서가는 것은 강력한 자동 verifier(테스트)가 처음부터 존재하기 때문이다
• 업무 도메인에 가져오면 설계의 무게중심은 **검증의 다층화(Risk Tier)·상태의 감사 가능한 외부화(append-only 레저)·인프라 레벨의 정지 조건(MCP 단일 입구)**으로 옮겨간다
• 루프가 아무리 똑똑해져도 최종 품질 판단과 책임은 사람이 쥔다. 엔지니어의 일은 사라지는 것이 아니라 "루프를 설계하고 감독하는" 것으로 옮겨간다

지난 글에서는 PersonaOS의 Methodology를 "비결정적인 LLM 런타임에 대한 신뢰성 엔지니어링"으로 정리했다. 이번에 루프 엔지니어링이라는 보조선을 그어 보면, 그 설계 판단들(BFC / Skill / Risk Tier)은 "업무 루프를 안전하게 자율 주행시키기 위한 반복 제어 설계"였다고 다시 말할 수 있다. 이름이 나중에 쫓아온 느낌이다.