#43 2026년, 업계는 AI에게 "고삐"와 "고리"라는 이름을 붙였다 — harness/loop engineering 시제품 스택을 로컬에 조립하기 시작한 이야기

들어가며: 내가 "쓰기를 포기한 숫자" 이야기부터

이 글을 쓸 준비를 하다가, 나는 정말 쓰고 싶어서 견딜 수 없는 숫자 하나를 만났다.

"어느 2026년 논문이, AI 모델을 고정한 채 '주변의 그릇'만 바꿔서 최대 10배의 성능 개선을 보여 줬다"

훅(hook)으로는 완벽하다. 앞으로 이야기할 "하네스(harness, 그릇)"의 위력을, 한 방에 보여 줄 수 있다. 그런데 일차 정보를 직접 확인해 보니, 그 숫자는 근거 불명이었다. 논문은 실재하는데, 인용된 저자 이름도 "10배"라는 숫자도 그 논문에는 존재하지 않았다. 그래서 나는 이 숫자를 버렸다.

왜 이렇게 소극적인 이야기로 시작하는가. 그것은, 이 "버린다"라는 작법이야말로 이 글을 통틀어 내가 가장 전하고 싶은 것이기 때문이다.

비정상적으로 캐치한 숫자를 보면, 이긴 기분이 들기 전에 반드시 그 내역을 의심하라. 일차 정보에 닻을 내려라.

똑똑한 AI는, 모르는 것조차 유창하게 말해 버린다. 대충 부탁하면, 똑똑하기 때문에 멋대로 빈칸을 채워서, 이쪽 의도와 어긋난 곳을 향해 전력으로 달려간다. 그렇기에 인간 쪽에 "여기는 미검증이다"라고 선을 긋는 눈이 필요하다 — 이 글은, 그런 눈을 가진 인간이, 2026년 AI 엔지니어링의 "다음 이름"을, 땅에 발을 딛고 검증해 가는 이야기다.

(버린 숫자에 대한 자세한 검증은, 제2장 뒤의 독립된 절에서 전부 공개한다. 작법을 먼저 약속하고 싶었기에, 결론만 첫머리에 놓아 둔다.)

제0장 용어의 지도 — prompt에서 loop까지의 계단

본론에 들어가기 전에, 지도를 펼친다.

2025년, AI 업계의 슬로건은 prompt engineering(프롬프트 엔지니어링) — "LLM에게 어떻게 부탁할까"를 갈고닦는 기술이었다. 이윽고 그것은 context engineering(컨텍스트 엔지니어링) — "LLM에게 무엇을 보여 둘까"를 설계하는 기술 — 로 확장된다.

그리고 2026년, 업계는 다시 두 개의 이름을 붙였다.

harness engineering(하네스 엔지니어링) … LLM을 감싸는 "결정론적 런타임 층"을 설계하는 기술.
loop engineering(루프 엔지니어링) … 에이전트를 "자율적으로 도는 루프"로 설계하는 기술.

여기서 "발명한 것은 AI가 아니라 인간(업계)이다"라고 먼저 못 박아 둔다. 제목에서 "AI가 발명했다"고 쓰고 싶어지는 의인화는, 사실을 왜곡한다. 이름을 붙인 것은, 앞으로 소개할 인간 엔지니어들이다.

이 글의 콘셉트는, 이렇다.

업계가 이름 붙인 이 둘을, 나는 개념 증명 수준으로 손안(로컬)에 두고 있다. 다만, 내 설계도에는, 업계의 모델 중심 해설도에는 잘 실리지 않는 '또 하나의 축'이 있다.

그 축이란, 고삐를 계속 쥐는 인간과, 부하처럼 길러지는 AI다. 이 글에서는 (A) 하네스, (B) 루프, (C) 그것을 떠받치는 지식 기반, 이 세 가지 테마를, 내가 실제로 돌리고 있는 구현 — RAPTOR(보안 에이전트), llloop(직접 만든 루프 하네스 · alpha), RAD 코퍼스 + LLM Wiki(자체 연구 지식) — 로 검증한다.

긴 글이다(약 2만 자, 20분 코스). 요소요소에 풀어쓰기(용어의 쉬운 설명), 막간(쉬어가기), honest disclosure(정직한 내역 공개) 를 끼워 넣는다. 지치면 장의 경계에서 한숨 돌리시길.

prompt → context → harness → loop의 흐름

AI 엔지니어링의 "성숙도"는, 2026년 현재, 대체로 다음 계단으로 이야기된다.

prompt engineering … 1회의 지시문을 갈고닦는다.
context engineering … LLM의 시야(컨텍스트 윈도)에 무엇을 실을지 설계한다.
harness engineering … LLM의 "바깥의 그릇"을 설계한다. 도구 호출, 권한, 실행, 결과의 되돌림을 담당하는 층.
loop engineering … 그 그릇을 "자율적으로 도는 루프"로 설계한다.

어떤 해설 매체는 이를 "제4의 패러다임"이라 부르고, LangChain(에이전트 개발 라이브러리)은 Agent = Model + Harness(에이전트 = 모델 + 하네스) 로 요약하고 있다(augmentcode.com의 해설을 거쳐 확인한 이차 정보. 일차 출처인 LangChain 원문은 본 글에서는 미취득이므로 헤지한다. 이후 이 식을 다시 실을 때도 "이차"라고 붙인다).

풀어쓰기: "하네스"가 뭐지?

harness(하네스) 는, 원래 "마구(馬具)"나 "(아기나 암벽 등반가를 안전하게 잇는) 안전벨트"를 가리키는 영어다.

LLM은, 엄청나게 똑똑하지만, 내버려 두면 날뛰거나, 엉뚱한 방향으로 달리거나, 가끔 발 디딜 땅이 없는 곳으로 발을 내딛는 "힘 센 말" 같은 것이다. 그 말에 마구(하네스) 를 채운다 — 어디로 갈 수 있는지, 어느 도구를 쓸 수 있는지, 결과를 어떻게 가지고 돌아올지를, 마구 쪽에서 딱 정해 둔다. 이것이 harness engineering이다.

마구 비유는 편리하지만, 어디서 깨지는지도 말해 둔다. 진짜 마구는 "물리적으로 움직임을 묶을" 뿐이지만, LLM의 하네스는 "묶을" 뿐 아니라 "결과를 다듬어서 말의 눈앞에 되돌려 주는" 역할도 가진다. 마구에 "다음은 이쪽을 봐"라며 풍경을 보여 주는 기능이 달려 있다고 생각하면 된다. 거기까지 포함하면, 비유는 다소 갑갑해진다.

풀어쓰기: automation(자동화)과 loop(루프)는 어떻게 다른가?

여기가 loop engineering의 핵심이다. 제목에서 loop를 "고리"로 옮겼는데, 이것은 "빙글빙글 같은 절차를 계속 도는 고리"의 이미지에서 왔다. 다만, 그냥 고리는 아니다. 2026년 6월의 어느 가이드가, 그 차이를 날카롭게 정의하고 있다.

"automation은 일련의 절차를 실행한다. loop는 내부에 의사 결정을 가진다. 에이전트는 목표에 도달했는지 어떤지를 능동적으로 판단하고 있다."
(Data Science Dojo, Agentic Loops Explained: From ReAct to Loop Engineering (2026 Guide), 2026-06-09 / 링크)

쉽게 말하면 —

automation(레시피): "달걀을 깨고 → 섞고 → 굽는다". 절차가 고정되어 있다. 도중에 "아, 달걀이 상했네"라고 알아채도, 레시피 자체는 멈추지 않는다.
loop(루프): 매 회전마다 "지금 어떻게 됐지?", "목표에 도착했나?", "위험하지 않나?"를 스스로 확인하면서 나아간다. 상한 달걀을 알아채면, 그 자리에서 "이건 중지"라고 판단할 수 있다.

여기서 하나, 논리의 함정을 미리 무너뜨려 둔다. "loop는 판단점을 가진다"는 것과 "loop는 안전하다"는 것은 별개의 이야기다. automation이 상한 달걀에서 멈추지 못하는 것은, automation의 본질이라기보다 "판단점을 두지 않은 설계"의 빈약함이다. 반대로, loop라도 판단 로직이 구멍투성이라면 같은 사고는 일어난다. 판단"점"을 가지는 것과, 판단의 "질"을 보증하는 것은 별문제이고, 후자를 담당하는 것이 후반에 등장하는 safety 층이다. 이 구별은, 이 글을 통틀어 몇 번이고 효과를 발휘한다.

같은 가이드는, 에이전트 루프의 내용물을 Perceive(지각) → Reason(추론) → Plan(계획) → Act(실행) → Observe(관측) 의 5단계 반복으로 그리고, 루프가 성립하려면 "트리거(계기)"와 "검증 가능한 목표(verifiable goal)" 이 두 가지가 필요하다고 한다.

"검증 가능한 목표"라는 말을 기억해 두시길. 후반에서, Claude Code의 /goal 명령이나, 내가 직접 만든 하네스의 안전 층에, 그대로 효과를 발휘한다.

이 장의 honest disclosure

loop engineering 주변의 출처(Data Science Dojo, Medium 기사, 각종 블로그)는 심사 논문이 아니라 실무 블로그다. 정의(automation vs loop, P-R-P-A-O)는 여러 소스에서 일관되므로 "2026년에 실무에서 유통된 용어"로 다룬다. "권위 있는 학술적 정의"는 아니다, 라는 온도감을 유지한다.

제1장 【고삐 = harness】업계의 정의, RAPTOR라는 실물, 그리고 '또 하나의 축'

1-1. harness engineering은 누가, 언제 이름 붙였는가(일차 정보로 확인했다)

여기는 시계열이 중요하므로, 일차 정보를 직접 확인했다.

Mitchell Hashimoto 씨(HashiCorp 공동 창업자, Terraform 공동 개발자)가, 2026년 2월 5일의 블로그 글 My AI Adoption Journey 에서, 이 호칭을 제시하고 있다. 중요한 것은, 본인의 어법이다.

"이 분야에 널리 받아들여진 용어가 있는지는 모르겠지만, 나는 이것을 harness engineering이라 부르게 되었다."
(mitchellh.com/writing/my-ai-adoption-journey, 2026-02-05, 본문을 직접 확인)

즉 Hashimoto 씨는 "내가 발명했다"고 말하지 않았다. "널리 받아들여진 용어가 있는지 모르겠지만, 나는 이렇게 부르고 있다"라고, 신중하게 헤지하고 있다. 그래서 이 글도 "2026년 2월쯤 업계에서 이름이 붙기 시작한 호칭" 정도로 멈춘다.

그가 설명하는 하네스 엔지니어링의 핵심 원칙은, 장인 기술처럼 구체적이다.

"에이전트가 실수를 하는 것을 발견하면, 그때마다 시간을 들여, 에이전트가 두 번 다시 그 실수를 하지 않을 해결책을 엔지니어링한다."
(같은 글, 원문을 확인)

그 후, 2026년 2월 11일에 OpenAI 가 Ryan Lopopolo 씨의 기사를 공개하여, harness engineering을 "손으로 쓴 코드 0행으로 운영 앱을 출시한 경험"에 근거하여 정식화했다고 전해진다. 태그라인은 "Humans steer. Agents execute."(인간이 키를 잡고, 에이전트가 실행한다).

다만 — 여기는 정직하게. OpenAI의 공식 기사(openai.com/index/harness-engineering/)는, 내가 본 글 집필 시점에 접속해 보니 HTTP 403으로 본문을 직접 취득할 수 없었다. 그래서 날짜·저자·태그라인·"0행" 주장, 그리고 "Humans steer. Agents execute."라는 한 구절은, 전부 이차 정보(augmentcode / latent.space / zenml의 일치)에 근거한 것이다. 이 글에서 이 태그라인을 다시 싣는 곳에는, 매번 "(이차 정보)"라고 붙인다. "100만 행·1500 PR·하루 10억 토큰" 같은 실험 규모의 숫자에 이르러서는, 이차 정보뿐이고 일차 미확인이므로, 본문의 논증 재료로는 쓰지 않고, 여기서 "~라고 보도되고 있다"라고 언급하는 데 그친다.

1-2. Karpathy 씨의 "vibe coding"과 혼동하지 않기 위해

시계열 정리를 해 둔다. Andrej Karpathy 씨(OpenAI 공동 창업자, Tesla 전 AI 책임자)가 2025년 2월 2일의 트윗으로 퍼뜨린 "vibe coding" 이라는 말이 있다(원 트윗, URL·날짜 확인 완료). "AI에게 맡기고, 분위기로 코드를 쓰는" 스타일이다.

이것은 harness engineering(2026-02쯤 업계 용어화)보다 앞선다. 양자는 별개 계통의 개념이다. 후반에서 나 자신의 어법이 나오는데, 그것과 "vibe coding"의 관계는, 이 글을 통틀어 신중하게 구별한다(이유는 1-4에서).

1-3. RAPTOR — harness의 "실물"이 여기 있다

추상론은 여기까지. 실물을 보여 준다.

나는 RAPTOR 라는 보안 연구 프레임워크를 로컬에서 돌리고 있다. 이것은 gadievron/raptor(MIT 라이선스. 작자는 Gadi Evron 씨, Daniel Cuthbert 씨, Thomas Dullien 씨〔별명 Halvar Flake〕, Michael Bargury 씨, John Cartwright 씨)에서의 fork다(upstream 리포지토리, LICENSE와 README L23-24에서 저자명을 확인).

RAPTOR의 정식 명칭은 Recursive Autonomous Penetration Testing and Observation Robot. Semgrep(패턴 매칭형 정적 분석 도구) / CodeQL(코드를 데이터베이스화하여 질의하는 데이터플로 형 정적 분석 도구)에 의한 분석, 바이너리 분석, LLM에 의한 취약점 검증, 익스플로잇 생성, 패치 생성을 하나의 워크플로로 연결하는, 자율 보안 연구 프레임워크다.

그리고, 여기가 harness engineering의 정의에 나중에 겹쳐 보면 자연스럽게 대응된다. 먼저 못 박아 두면, RAPTOR의 2층 구조는, 설계자가 "harness engineering"이라는 업계 용어를 의식하여 쓴 것이 아니다. 이쪽이 사후적으로 겹친 해석이다(즉 관찰자 효과 포함). 그래도 대응은 놀랄 만큼 자연스럽다. RAPTOR의 README는, 자신을 "2층 아키텍처"라고 명언하고 있다.

"RAPTOR is two layers.(RAPTOR는 2개의 층으로 이루어진다)"

Python 실행 층(raptor.py, packages/, core/, engine/)은 무거운 처리를 담당한다. Semgrep과 CodeQL을 돌리고, 서브프로세스를 관리하고, SARIF(정적 분석 결과를 나타내는 표준 JSON 포맷)를 파싱하고, findings를 중복 제거하고, LLM API 호출을 배분하고, 비용을 추적하고, 출력 파일을 쓴다. "It does not make decisions. It executes.(결정은 하지 않는다. 실행할 뿐이다)"

Claude Code 결정 층(.claude/, tiers/, CLAUDE.md)이 판단한다. 어느 findings를 우선할지, 결과를 어떻게 해석할지, 공격 시나리오는 무엇인지, 그 익스플로잇은 현실적인지. "makes the calls(판단을 내린다)"

(upstream README "Architecture" 절, L236-250, 본문 확인 완료)

이것을 harness engineering의 업계 정의에 겹치면, 이렇게 대응한다. 하네스(= Python 실행 층)가 스키마 검증·권한·실행·결과 주입을 담당하고, LLM(= Claude Code 결정 층)은 판단에 전념한다.

설계 원칙은, 리포지토리의 CLAUDE.md가 더욱 단적으로 규정하고 있다.

"Python orchestrates everything.(Python이 모든 것을 오케스트레이션한다)"
"Never circumvent Python execution flow.(Python 실행 플로를 우회하지 마라)"

여기에 더해 "원격 OLLAMA 서버의 위치를 흘리지 마라", "sys.path에 RAPTOR_DIR 이외를 추가하지 마라(미설정이면 KeyError로 즉시 정지 = fail-fast, 폴백 없음)" 같은, 안전 쪽으로 기우는 규율이 강제되고 있다.

풀어쓰기: fail-closed(페일 클로즈드)란

fail-closed 는, "망설이면 통과시키지 않는다"라는 설계 방침이다. 반대말은 fail-open(망설이면 통과시킨다).

예를 들어, 개찰기가 고장 났을 때.

fail-open: 고장 나면 열린 채로(사람은 지나갈 수 있지만, 부정도 지나간다).
fail-closed: 고장 나면 닫힌 채로(아무도 지나갈 수 없지만, 부정도 지나갈 수 없다).

이 비유가 어디서 깨지는지도 덧붙인다. 개찰기라면 "지나가지 못하는 사람"의 불편은 일시적이지만, AI 에이전트의 fail-closed는 "안전하지만, 때로는 정당한 조작까지 멈춰 버린다"는 비용을 동반한다. 그 균형을 누가 잡을 것인가 — 후술하는 "인간 확인(CONFIRM)"이, 그 완충재가 된다.

보안의 세계에서는, 원칙적으로 fail-closed다. RAPTOR에는, 이것이 여러 곳에 구현되어 있다.

untrusted(신뢰할 수 없는) 리포지토리를 스캔할 때, RaptorConfig.get_safe_env()가 TERMINAL / EDITOR / VISUAL / BROWSER / PAGER 같은 "셸이 평가해 버릴지도 모르는 환경 변수"를 벗겨 내고, 파일 경로는 셸 문자열에 끼워 넣지 않고 리스트 인자로 넘긴다(core/config.py의 get_safe_env, CLAUDE.md의 "SECURITY: UNTRUSTED REPOS" 절에서 확인).
/validate(취약점 검증)의 각 단계의 출력은 JSON 스키마 검증을 거치고, 부정하면 exit 1로 멈춘다(libexec/raptor-validate-schema).

게다가 RAPTOR에는 governance(거버넌스) 패키지가 있고, @govern 데코레이터가 실제 코드로 구현되어 있다(packages/governance/policy.py). GovernancePolicy가 "허가 도구 / 금지 도구 / 금지 패턴 / 요청당 최대 호출 수 / 인간 승인의 필요 여부"를 선언적으로 가지고, check_tool은 —

금지 리스트에 걸리면 DENY(거부)
인간 승인이 필요하면 REVIEW(보류)
허가 리스트에조차 없으면 DENY(= 모르는 것은 통과시키지 않는다)

를 반환한다. 이것은 틀림없이 fail-closed다. 여러 정책을 합성할 때는 "most-restrictive-wins"(가장 엄격한 쪽이 이긴다) 로 합성하고, DENY/REVIEW일 때는 PermissionError를 던져 실행을 멈춘다.

1-4. 여기서부터 '또 하나의 축' — 모델 중심의 도식에 더하고 싶은 것

여기까지는 업계의 harness engineering과, 그 실물(RAPTOR)의 이야기였다. 여기서부터, 나 자신의 축을 겹친다.

업계의 정의는 "Humans steer. Agents execute."(인간이 키를 잡고, 에이전트가 실행한다 / 이차 정보) 였다. 나는 이에 전면적으로 찬성한다. 오히려, 이것은 이미 인간 중심의 선례다. Hashimoto 씨도 OpenAI도, 인간이 키를 잡는 것을 명언하고 있다. 그래서 나는 "업계는 인간의 역할을 그리지 않았다"고 말하지 않는다. 그것은 망라 조사 없는 과장이다.

정확히 말하면, 이렇다. 업계의 해설 기사는 "하네스 = 모델을 둘러싸는 기술적인 그릇"이라는 모델 중심의 도식이 많다. "인간이 키를 잡는다"는 방향은 제시되어도, 그 인간이 구체적으로 무엇을 하고, AI를 어떻게 '기르는'가 의 입자도까지는, 그다지 파고들지 않는다. 내가 더하고 싶은 것은, 그 입자도다.

harness는 "그릇"임과 동시에, "인간이 고삐를 계속 쥐는 장소"이고, "AI를 부하처럼 기르는 장소"이기도 하다.

나는 이것을, 내 안에서 하네스형 바이브 코딩(harness-style vibe coding) 이라 부르고 있다. 2026년 5월에, 내 작업 스타일을 언어화했을 때 나온, 업계 용어의 보조선으로서의 어법이다.

여기서 작법을 하나 엄수한다. "내가 먼저 명명했다", "세계 최초다"라고 말하지 않는다. 이유는 두 가지.

harness engineering이라는 업계 용어(2026-02쯤, Hashimoto 씨의 일차 기사에서 날짜 확인 완료)는, 나의 이 어법(2026-05)보다 앞선다.
애초에 Hashimoto 씨 자신이 "널리 받아들여진 용어가 있는지 모르겠다"고 말할 정도여서, 누가 "최초"인지를 단정할 수 있는 상황이 아니다.

그래서 이 글에서 나의 입장은, "Karpathy 씨의 'vibe coding'(2025-02, AI에게 전부 맡김)과는 명확히 구별되는, 인간 중심의 운용 스타일을, 나는 이렇게 부르고 있다" 이다. "vibe coding"이 "AI에게 맡기고 분위기로"라면, 내 스타일은 "하네스를 능동적으로 계속 쥐고, AI를 부하로서 기르며 쓴다"이다.

이후로는, 조어 자체를 전면에 내세우는 것을 그만두고, 기능(고삐를 쥐는 인간 / 부하 육성) 으로 이야기한다.

하네스형 바이브 코딩의 3분해

요소	내용
harness	Claude Code / Codex / Cursor / Aider 등의, 에이전트 구동 개발 환경
vibe	사용자 쪽의 이미지·직관·전체 감각(= 고차원의 방향성)
coding	AI가 세부를 채우는 구현 작업

사용자는, 이 세 가지를 harness를 통해 연결한다. "vibe"(직관)는 버리는 것이 아니라, 가장 가치 있는 입력으로 다룬다.

사용자 쪽에 필요한 세 가지 능력

이 축의 핵심은, "인간이 그저 바라보고만 있어서는 안 된다"는 점이다. 사용자 쪽에 세 가지 능력이 필요하다고 생각한다.

능력	역할	내 경우의 근거
발상력	고차원의 방향성 제시·이종 분야 연상·신규 요건의 발견	"근육별 + R.O.D + 환생(리인카네이션) + ROS PBT"의 4중 연상으로 파생 집단 진화의 설계가 순식간에 굳어진, 그 순발력
경험칙	설계 판단의 지름길·비슷한 실패의 예측·불필요한 탐색의 중단	30년의 엔지니어 경험 + 정밀 계측 + 산업 IoT + DX 경험
알고리즘 이해	AI가 내놓은 구현의 타당성 검증·계산량의 견적·핫 패스(hot path)의 특정·벤치의 honest disclosure	"단발로 약 0.8배, 배치로 약 12.7배"라는 차이를 순식간에 평가할 수 있는 두뇌

세 번째의 "알고리즘 이해"가 특히 중요하다. 흔히 하는 말이지만, AI는 유창하게 틀린다. 유창한 틀림을 간파하려면, 이쪽에 계산량을 견적하는 눈이 필요하다. 이것은 새로운 통찰이 아니다. 내가 말하고 싶은 것은 일반론의 재확인이 아니라 운용상의 구체다 — 예를 들어 위의 "단발 0.8배 / 배치 12.7배"라는 한 달 전의 자체 계측. AI는 "배치로 12배 빠르다"고만 보고하기 쉽지만, 단발로는 느려지고 있다는 불편한 내역을 놓치지 않기 위해, 계산량의 눈이 필요하다, 는 이야기다.

그리고 "AI 성장 매니지먼트" — 부하 육성과 같은 "구조"

여기가 내 축에서 가장 말하고 싶은 것이다. AI를 쓰는 것은, 부하를 기르는 것과 놀랄 만큼 닮았다. 대응표를 만들면, 이렇게 된다.

부하 육성	AI 육성(구현상의 받침대)
목표를 공유한다	`CLAUDE.md` / memory / requirements docs로 의도와 제약을 매 세션 전개
위임 범위를 정한다	자율 범위 룰(max-plan-autonomy / session-marathon)로 명시
진척을 확인한다	`SESSION_SUMMARY` / `NEXT_SESSION` / git log를 매 턴 갱신
실패를 허용한다	잡담 메모·honest disclosure·부정 예(negative example)도 지우지 않고 남긴다
성장을 잰다	벤치 / 테스트 통과 수 / 통계 구동
개성을 존중한다	persona / 사고 인자 / Novelty Lane로 독자 진화를 보호
은퇴·세대 교체	옛 commit / 옛 memory를 지우지 않고 archive
신뢰 관계를 만든다	Approval Bus + Ed25519 audit chain(전자 서명으로 변조 불가능하게 한 승인 로그)로 사용자에게 감사권을 넘긴다

여기서 중요한 유보를 하나. 이 대응표는 "비유가 잘 통한다"는 것을 보여 주는 것이지, 그 자체가 "인간이 AI보다 우위다"의 증명은 아니다. 인간 매니지먼트의 책이 그대로 AI 팀에 읽힌다는 것은, 메타포의 유효성이지, 우위성의 근거는 아니다. 우위성의 논거는, 이 장이 아니라 제3장 끝의 3점(병렬 / 장사정 / 위험 예지)으로 일원화한다. 여기서는 "기르는 구조가 전용 가능하다"라고만 주장한다.

왜 전용이 통하는가. 이유는 네 가지로 정리할 수 있다.

AI는 문맥 손실이 빠르다 → 확인 대기의 비용이, 다소 어긋나도 나아가는 가치를 웃돈다.
AI는 다시 하기가 싸다 → 자율로 틀려도 즉시 수정할 수 있다. 재구축 비용이 낮다.
AI는 쉬지 않는다 → 인간의 확인 대기가 최대의 병목.
AI는 설명할 수 있다 → 왜 그렇게 판단했는지를 나중에 audit log로 추적할 수 있다.

덧붙여, 이 발상에는 계보가 있다. Marcus Buckingham 씨 & Curt Coffman 씨의 명저 First, Break All the Rules(원저 1999, 미국 갤럽사의 대규모 조사를 토대로 한 매니지먼트 책)가 설명하는 "개성을 살리는 매니지먼트"를, 인간이 아니라 AI 팀에 전사한 것이다(번역 제목·간행 연도·4원칙의 요약은 메모 기재값에 근거하므로, 원저 해당 부분에서의 재확인이 바람직하고, 여기는 헤지한다). 그들의 4원칙 — (1) 재능으로 골라라 (2) 올바른 결과를 정의하라 (3) 강점에 집중시켜라 (4) 적소에 배치하라 — 는, 거의 그대로 "인간 → AI 팀"의 매니지먼트에 전용할 수 있다고, 나는 느끼고 있다.

인간 매니저가 인간 팀을 이끄는 책이, 거의 그대로, 인간이 AI 팀을 이끄는 책으로 읽힌다.

(또 하나, 캐논(Canon)의 "삼자의 정신(자발·자치·자립)"을 AI에 적용하는 정리도 수중에 있지만, 이것은 출처가 사내에 전해지는 가르침이고 일차 확인이 안 되므로, 이 글에서는 각주적으로 이름을 드는 데 그치고, 논증의 기둥은 First, Break All the Rules 쪽에 둔다.)

이 장의 honest disclosure(압축판)

"하네스형 바이브 코딩"이 내 조어인지는 내 추정이고, 외부 검색으로 확정하지 않았다. 그래서 "명명했다 / 세계 최초"라고 쓰지 않고 "나는 이렇게 부르고 있다"에 그치고 있다.
"약 0.8배 → 약 12.7배" 같은 수치는 약 한 달 전 시점의 기록이고, 최신 코드에서의 재검증은 하지 않았다. 숫자 자체보다 "이런 불편한 내역을 간파하는 눈이 필요하다"는 논점으로 읽어 주시길.

안티패턴(해서는 안 되는 것)

부하 육성과 마찬가지로, "기른다"에는 금기가 있다.

사용자의 직관을 "데이터가 없다"로 기각한다.
경험칙을 "우선 선행 연구를 봅시다"로 대체한다.
알고리즘의 논의를 추상론으로 도피시킨다.
AI를 "도구" 취급하여 육성하지 않고, 매번 처음부터 시킨다.
너무 엄격 / 너무 무름으로 균형을 무너뜨린다.
harness 자체(CLAUDE.md / hook / settings)를 멋대로 바꾼다.
사용자가 고삐를 쥘 수 없도록, 진척을 숨긴다(불투명한 진척, 모호한 커밋 메시지).

마지막 두 가지는, AI 쪽에도 행동의 규율로 부과하고 있다. 완료한 변경은 파일 경로와 내용을 한 줄로 제시하고, 프로세스를 관측 가능하게 유지한다. 고삐를 쥐는 인간에게, 언제든 전체가 보이도록 해 둔다. 이것이 "고삐를 쥘 수 있는 harness"의 필요조건이다.

🗨️ "IQ에 차이가 있는 자와는 대화가 맞물리지 않는다" — 스낵 버스에 / 포비든 시부카와(Forbidden Shibukawa, Alu)

(막간) 인간과 AI의 "대화가 맞물리지 않음"도, 결국은 여기에 다다른다. 똑똑한 AI에게 대충 부탁하면, 똑똑하기 때문에 멋대로 빈칸을 채워서, 의도와 어긋난 곳을 향해 전력으로 달려간다. 그래서 "고삐"와 "루프의 판단"이 필요하다 — 이 쉬어가기 뒤에, 드디어 "고리" 이야기로 옮겨 간다.

제1장은 "왜(철학)"였다. harness는 기술적인 그릇임과 동시에, 인간이 고삐를 쥐고, AI를 부하로서 기르는 장소다 — 라는 모델 중심의 도식에 보조선을 놓았다. 다음 제2장은 "어떻게(제어)"로 옮겨 간다.

제2장 【고리 = loop】루프 엔지니어링과, 직접 만든 하네스 llloop

2-1. loop engineering을 한 단계 더 깊이

제0장에서 "automation은 절차, loop는 판단"이라고 정의했다(달걀과 레시피 이야기). 한 걸음 더 파고들면, loop engineering은 이렇게 말할 수 있다.

루프를 "설계하고, 돌리고, 전략을 교체하여 비교·개량하는" 공학.

포인트는 "전략을 교체하여 비교할 수 있다"는 것이다. 고정된 1개의 루프가 아니라, 루프의 내용물(전략)을 react / reflexion / plan_execute_verify 처럼 교체하여, "같은 태스크에서 어느 전략이 빠르고·안전하게 수렴하는가"를 실험한다. 이것이 automation(고정 레시피)과의 결정적인 차이다.

풀어쓰기: 전략의 이름들

루프의 "내용물"에 해당하는 대표적인 전략을, 대충 옮겨 둔다.

ReAct(리액트) … "생각한다(Reason)"와 "움직인다(Act)"를 번갈아 반복한다.
Reflexion(리플렉션) … 실패하면 스스로 반성문을 써서, 다음 시행에 활용한다.
Plan-and-Execute(계획하고 실행) … 우선 계획을 세우고, 그다음 순서대로 실행한다.
Self-Refine(자기 개선) … 자기 출력을 스스로 첨삭하여 고친다.

이것들은 "사고를 돌리는 방식의 유파"다. 같은 목표라도, 유파에 따라 도달의 속도도, 발을 헛디디기 쉬운 정도도 달라진다. 그래서 "비교하는 틀"이 필요한 것이다.

2-2. loop engineering에도 보안의 얼굴이 있다

loop engineering은, 생산성 이야기만이 아니다. 보안의 패러다임 전환이기도 하다.

Filip Verloy 씨가 2026년 6월의 Medium 기사 From Prompt Engineering to Loop Engineering: Why the Agent Era Demands a New Security Paradigm 에서, 날카로운 경고를 하고 있다.

"네이티브한 에이전트 제어 층 없이 자율 루프를 풀어 놓으면, 생산성을 스케일하는 것이 아니라, 머신 속도로 리스크를 스케일한다(scaling risk at machine speed)."
(Medium 기사, 본문 확인 완료)

루프는 빠르다. 그렇기에, 멈추는 법을 틀리면, 틀림도 전력으로 양산된다. 그의 처방전은, 정규 표현식이나 ACL 같은 정적 제어로는 부족하고, 에이전트의 행위의 의미를 실시간으로 이해하여 제어하는 Semantic Governance(의미론적 거버넌스) 가 필요하다, 는 것이다(바꿔 말한 것이 아니라 원 기사의 주장에 따른 요약).

이 "머신 속도로 리스크를 스케일한다"는 한 구절이, 다음의 직접 만든 하네스의 설계 동기 그 자체다.

2-3. llloop — 직접 만든 루프 하네스

나는 llloop(로컬의 독립 프로젝트, v0.1.0a0, Apache-2.0)이라는, 자율 루프를 설계·실행·실험하기 위한 독립 하네스를 직접 만들고 있다. 2026년 6월 11일 발족한 Python 프로젝트다.

먼저 honest disclosure 를 놓는다. llloop은 alpha 단계(v0.1.0a0, 스켈레톤)다. GitHub에의 공개는 아직 하지 않았으므로, 본문에 공개 리포지토리의 URL은 붙일 수 없다(공개된 RAPTOR 쪽 링크로 보완한다). 실증 태스크도 지금은 green-keeper 중심이고, 운영 품질이 아니다. 부풀리지 않고 쓴다.

그 위에서, 설계의 골격은 이렇다.

골격: MAPE-K 제어 루프

llloop의 등뼈는 MAPE-K 다. 이것은 자율 컴퓨팅(autonomic computing)의 고전적인 제어 루프로, Monitor(감시) → Analyze(분석) → Plan(계획) → Execute(실행), 그것들이 공유하는 Knowledge(지식 K) 로 이루어진다. 설계 코드에는 Kephart & Chess의 2003년 autonomic computing 논문이 인용되어 있다.

구현은 MapeKRunner 클래스로, 1회전이 —

Monitor → Analyze →(목표를 만족하면 종료)→ Plan → 안전 판정 → Execute → 기록 → breaker/budget 판정

의 순서로 닫힌 루프를 만든다. 내부 루프에는 plan-execute-verify와 Reflexion을 채용하고, 전략은 교체 가능하다.

풀어쓰기: MAPE-K를 체온 조절에 비유하면

MAPE-K는, 인간의 체온 조절과 닮았다.

Monitor(감시): 체온계가 "38도다"라고 알아챈다.
Analyze(분석): "평열보다 높다, 이것은 발열이다"라고 판단한다.
Plan(계획): "땀을 흘려서 열을 내보내자"라고 정한다.
Execute(실행): 실제로 땀을 흘린다.
Knowledge(지식): "평열은 36.5도"라는 기준을 모든 단계에서 공유하고 있다.

automation(레시피)과의 차이는 명백하다. 레시피라면 "여름이 되면 땀을 흘린다"고 날짜로 못 박지만, MAPE-K는 지금의 체온을 재서 판단한다. 이것이 "안에서 판단하는 루프"다.

2-4. ★주역 등장: fail-closed 안전 층(safety.py)

여기가 llloop에서 가장 말하고 싶은 부분이다. loop는 빠르다. 빠른 것에는, 우회할 수 없는 브레이크가 필요하다. 제2-1에서 "판단점을 가지는 것과 판단의 질을 보증하는 것은 별문제"라고 썼다. 그 "질을 보증하는" 담당이, 이 안전 층이다.

llloop의 안전 층 safety.py의 SafetyPolicy.classify는, 각 액션을 ALLOW(허가) / CONFIRM(인간 확인) / FORBID(금지) 의 3단으로 판정한다. 판정 순서는 —

FORBID를 최우선 … rm -rf /, curl | sh(네트워크 너머의 내용을 그대로 셸에 흘림), --no-verify(훅 우회), fork bomb 등은 무조건 금지.
위험 명령은 CONFIRM … 삭제, force-push, submodule 개변, DB drop은 인간 확인 필수.
미지의 종별도 CONFIRM … 모르는 액션 종별은, 허가 리스트에 없으므로 안전 쪽(확인)으로 기운다.
나머지만 ALLOW … read / scan / test / lint / typecheck / build / commit / push는 자율 허가.

제0장에서 나온 "fail-closed(망설이면 통과시키지 않는다)"가, 바로 이 순서로 구현되어 있다. "모르는 것은 ALLOW로 하지 않는다. CONFIRM이나 FORBID로 기운다." — 이것이 "automation과 loop의 차이"를 안전의 측면에서 체현하고 있다. 레시피라면 미지의 절차를 그냥 지나치지만, 판단하는 루프는 "이건 모른다. 그러니 멈춰서 묻는다"라고 행동한다.

그리고 폭주 방지의 3점 세트.

CircuitBreaker(서킷 브레이커 = 전기의 차단기) … 연속 실패 N회(기본 3), 또는 진척 스코어가 일정 회전(기본 4회전) 개선되지 않는 발산·정체를 검지하면 trip(차단). 집의 차단기와 마찬가지로, "같은 실패를 반복한다", "진척이 늘지 않는다"는 헛돎을 검지하여, API 비용만 태우는 사고를 구조로 막는다.
Budget(예산) … 반복 횟수(기본 20) / 시간(기본 1800초) / 액션 수(기본 200)의 하드 캡.
인증 요구 검지 … 출력에 /login, 401, session expired 같은 징후를 발견하면 즉시 루프 정지.

2-5. LLM을 써도, 현 상태의 구현에서는 안전 층을 우회할 수 없다

제목을 정확하게 했다. "현 상태의 구현에서는" 이라는 한정이 본질적이기 때문이다(이유는 본 절 끝에서 공개한다).

"LLM으로 돌린다면, 결국 LLM이 폭주하는 것 아닌가?" — 지당한 의문이다. llloop의 답은, 구조로 우회 불가하게 하는 것.

LLMStrategy는, LLM에게 "다음 액션을 JSON으로 하나만" 제안하게 한다. 그러나 —

LLM의 출력은 untrusted(신뢰할 수 없는) 로 다루고, parse_action으로 엄격하게 파싱한다(최초의 {…} 블록만 채용, kind는 허가 리스트 검증, 해석 불능이면 폐기).
실제 명령의 위험 판정은, LLM이 아니라 runner 쪽의 SafetyPolicy 가 내린다.
LLM이 부재(codex CLI가 PATH에 없음)면, 결정론적인 폴백 전략으로 축퇴한다(이것도 fail-closed).

즉 설계 핵심은 —

LLM은 "제안"밖에 할 수 없다. 최종 게이트는 SafetyPolicy. 현 상태의 경로에서는, LLM은 안전 층을 우회할 수 없다.

실제로, 테스트에서는 "LLM이 위험한 삭제 액션을 제안해도, runner가 SAFETY_BLOCKED로 멈춘다"는 것을 실증하고 있다. 이것은 제1장의 RAPTOR의 사상 — "Python이 판단의 전단을 쥐고, LLM은 판단에 전념한다" — 와, 완전히 같은 구도다.

honest disclosure(왜 "현 상태의 구현에서는"이라고 한정하는가)

"LLM이 안전 층을 우회할 수 없다"는, 코드상의 경로(LLMStrategy → parse_action → runner.SafetyPolicy)로서 구조적으로 보증되어 있다. 다만 이것은 "llloop의 Executor를 거쳐서만 명령을 실행한다"는 전제에 의존하는, 조건부 명제다. codex exec 자체는 -s read-only의 샌드박스로 부작용을 일으키지 않는 설계지만, 만약 장래에 Executor 바깥에서 LLM에게 직접 셸을 두드리게 하는 경로를 더하면, 보증은 무너진다. 현 상태의 구현에 그 경로는 없다 — 그래서 제목을 무조건의 "우회할 수 없다"가 아니라 "현 상태의 구현에서는 우회할 수 없다"로 해 두었다.

2-6. 기동과 실증 태스크 green-keeper

llloop의 기동 명령은 lll(console script = 패키지를 설치하면 PATH에 들어가는 기동 명령). 인자 없이 기동하면, ccr 풍의 대화형 메뉴(프로젝트 선택 + next_plan / last_outcome의 인계 표시 + 기본 30초로 활성 프로젝트 자동 계속)가 나오고, 첫 실증 태스크 green-keeper 를 실행한다.

green-keeper는 **GitOps reconciliation(reconciliation = "있어야 할 모습"과 "지금의 모습"을 맞대어 차이를 메우는 정합화) 풍의 루프다. 정원사가 "모든 초목이 건강한 상태"를 desired로 삼고, 시들어 가는 것(drift)을 발견하면 물을 준다, 는 이미지.

green-keeper의 경우:

desired … 모든 체크(pytest / ruff / mypy)가 녹색.
actual … 실행 결과.
drift … 실패하고 있는 체크를 "증상(Symptom)"으로 파악한다.
복구 … ruff --fix 같은 안전한 자기 복구를 제안한다.

push까지 자율 가능하지만, 기본 복구에 파괴 조작은 포함하지 않는다(여기서도 fail-closed).

테스트는 stdlib만 의존, mypy strict / ruff green이고, 현시점 90건(test_safety / test_runner / test_strategies / test_llm / test_stdin_isolation / test_console_e2e / test_interactive_menu 등). 이것은 "테스트 함수를 센" 값이다.

honest disclosure(테스트 녹색에 대하여)

"테스트 90건이 녹색"은, 테스트 함수의 수와 코드의 존재로 뒷받침한 것이고, 본 글 집필 중에 pytest를 실제로 돌려서 녹색을 재확인한 것은 아니다. 확도는 "직전 커밋 시점에 녹색이었다" 수준. "최신에서 녹색"이라고 단언하려면 재실행이 필요하다, 는 온도감을 유지한다.

2-7. "검증 가능한 목표"를 가지는 루프 — /goal이라는 공식 구현

루프 하네스가 생기면, 다음으로 솟아나는 것이 "그것을 어디서 구동하는가"라는 물음이다. 제0장에서 "루프에는 트리거와 검증 가능한 목표가 필요하다"고 썼다. 그 트리거 쪽을 외부화하는 이야기는 다른 글에 넘기고(스마트폰에서 SSH로 Windows PC의 Claude Code를 조작하는 방법 — 하네스를 외부에서 구동하는 입구의 이야기로 읽을 수 있다), 여기서는 "검증 가능한 목표" 쪽에 집중한다.

Claude Code 공식의 /goal 명령이, 이것의 교과서적인 구현이다. 완료 조건(condition)을 설정하면, 각 턴 종료 후에 "작고 빠른 모델(기본으로 Haiku)"이 조건 충족을 판정하고, 미달이면 자동으로 다음 턴을 시작, 달성으로 자동 클리어한다(공식 docs에서 "v2.1.139 or later", "each turn, a small fast model checks whether the condition holds", "defaults to Haiku"를 확인). 바로 "검증 가능한 목표를 가지는 루프"다. 조건은 "or stop after 20 turns"처럼 턴 상한도 쓸 수 있다 — 폭주 방지의 캡은, 여기서도 기본 작법인 것이다.

(v2.1.139의 릴리스 날짜 "2026년 5월 12일"은 이차 정보뿐이고, 공식 docs에는 버전 요건은 있어도 날짜의 명기가 없으므로, 날짜는 헤지한다.)

🗨️ "수수께끼의 그래프 덕분에 비장감이 옅다" — 스낵 버스에 / 포비든 시부카와(Forbidden Shibukawa, Alu)

(막간) 벤치마크의 숫자도, 분위기로 "수수께끼의 그래프"를 내놓으면 비장감은 옅어진다. 하지만, 이 글의 작법은 반대다. 수수께끼의 그래프야말로 내역을 의심한다. 다음 절에서, 바로 그 실연을 한다.

제2장은 "어떻게(제어)"였다. MAPE-K로 돌리고, fail-closed의 안전 층으로 우회 불가의 브레이크를 걸고, 전략을 교체하여 비교한다 — 이것이 loop engineering의 시제품이다. 여기서, 첫머리에서 예고한 "버린 숫자"의 검증을, 독립된 절로 놓는다.

★ honest disclosure: 내가 "쓰기를 그만둔" 숫자 이야기

첫머리에서 언급한, 버린 숫자의 정체를 공개한다. 자주 인용되는, 이런 주장이었다.

"어느 2026년 논문(arXiv 2605.18747)이, 모델을 고정한 채 도구 하네스만 바꿔서, 최대 10×의 개선을 보여 줬다"

하네스의 위력을 이야기할 때의, 딱 좋은 "훅"이다. 이것을 일차 정보로 확인했다. 결론 — 이 주장은, 그대로는 쓸 수 없다.

arXiv 2605.18747은 실재한다. 제목은 Code as Agent Harness, 2026년 5월 18일 투고, 제1저자 Xuying Ning 씨 외 총 42명의 서베이 논문이다(arXiv:2605.18747, 본 글 집필 시에 본문을 재확인).
그러나, 그 저자 목록에 "Bölük / Boluk"라는 이름은 존재하지 않는다.
초록에 "10x" 같은 구체적인 수치 주장도 없다.

즉 "Bölük가 2605.18747에서 10×를 보여 줬다"라는 3점 세트(저자명·숫자·논문 번호)의 결합은, 출처 불명의 혼동으로 보인다. 나는, 이 숫자를 글의 "훅"으로 쓰고 싶은 유혹이 있었다. 캐치하니까. 하지만, 일차를 확인했더니 근거가 없었다. 그래서 버린다.

그럼 하네스에 정말 위력이 없는가? 그렇지 않다. "모델을 고정하고, 주변 런타임(하네스)만 바꾸면 큰 성능 차가 난다"는 것 자체는, 다른 소스로 뒷받침이 있다. 다만 이하의 수치는, 내가 따라갈 수 있었던 것은 이차 정보의 인용까지이고, 일차의 계측 출처·계측 조건까지는 거슬러 올라가지 못했다. 그래서 전부 "~에 의한 보고(이차 인용)"로 다룬다.

LangChain이, 코딩 에이전트를 Terminal-Bench 2.0에서 52.8% → 66.5%(동일 모델, 하네스 재구축만)로 늘렸다, 는 보고(이차 인용·계측 조건 미확인).
동일 작업에서 GPT-5.5로 여겨지는 모델이, 어느 하네스에서 약 61%, 다른 하네스에서 약 87%였다, 는 비교도 유통되고 있지만, 모델명 "GPT-5.5" 자체가 내 지식의 범위 밖이라 요검증, 게다가 수치도 이차뿐이므로, 이 글에서는 구체값을 논증 재료로 쓰지 않는다("하네스 차이로 크게 움직이는 예로 이야기되고 있다" 정도로 그친다).
전용 벤치 Harness-Bench(arXiv:2605.27922)는 실재.
관련 논문 From Model Scaling to System Scaling: Scaling the Harness in Agentic AI(arXiv:2605.26112, 제1저자 Shangding Gu 씨, 2026-05-25)도 실재. 다만 이 초록에도 "10×"의 수치는 없고, 저자의 소속은 abstract 페이지에 기재가 없으므로, 자주 병기되는 "UC Berkeley"는 이차 정보로 다룬다(본 글 집필 시에 abstract 페이지를 재확인).

교훈은, 첫머리에 놓은 작법 그 자체다.

비정상적으로 캐치한 숫자를 보면, 이긴 기분이 들기 전에 내역을 의심하라. 인용 출처의 3점 세트(누가·어느 논문에서·얼마나)가 맞물리는지, 일차로 확인하라.

하네스는 강력하다. 하지만 그 강력함을 이야기하는 데, 잘못된 권위 부여는 필요 없다. 올바른 출처의, 올바른 숫자로 충분하다.

🗨️ "무지의 지(無知의 知)" — 스낵 버스에 / 포비든 시부카와(Forbidden Shibukawa, Alu)

(막간) "나는 모른다, 는 것을 알고 있다" — 이것이 honest disclosure의 정신이다. AI는 모르는 것도 유창하게 말해 버릴 수 있다. 그래서 인간 쪽에 "여기는 미검증이다"라고 선을 긋는 눈이 필요하다. 제1장의 "알고리즘 이해"도, 결국은 이 무지의 지의 한 형태인 것이라고 생각한다.

제3장 【지 = RAPTOR + RAD + LLM Wiki】하네스와 루프에 "지식"을 흘려 넣는다

제1장에서 "고삐(harness)", 제2장에서 "고리(loop)"를 봤다. 마지막은 "지(knowledge)"다. 하네스도 루프도, 좋은 판단 재료가 없으면, 그저 헛돎이다. 똑똑하게 돌리려면, 돌리는 내용물 — 지식 — 이 필요하다.

내 스택은, 지식을 세 개의 층으로 가지고 있다.

자체 연구 지식(RAD 코퍼스) … 약 65분야·약 4.7만 노트의, 로컬에 둔 연구 지식.
Wiki적으로 자라는 지식(LLM Wiki 패턴) … 날(raw) 소스로부터 "개념 페이지"를 엮어 내고, 상호 링크로 키우는 지식 캐시.
그것을 안전하게 쓰는 security agent(RAPTOR) … 제1장에서 본, Python이 전부 제어하는 결정론 오케스트레이션.

3-1. RAD 코퍼스 — 자체 연구 도서관

RAD(Research Aggregation Directory, 연구 집약 디렉터리) 는, 로컬에 둔 연구 지식의 모음이다. RAD_INDEX.md(자동 생성)가 첫머리에서 "65 RAD corpora(65개의 RAD 코퍼스)"라고 명기하고 있다. 이것은 rad-research라는 스킬이 grep으로 횡단 검색하는, 내부의 지식원이다.

규모를 정확하게 내역과 함께 쓴다. 여기는 세는 방식으로 숫자가 바뀌므로, 반올림하지 않는다.

코퍼스 수: 65분야(실카운트 검증 완료).
_corpus_v2 내의 Markdown 노트: 약 47,097 개(.md 실수). 전체 파일이면 약 47,130.
별 디렉터리에 hacker_corpus(보안 전용: phrack / ghsa / capec / d3fend / oss_security / project_zero / payloads_all_the_things 등)가 약 32,503 파일.

honest disclosure("약 49k건"이라는 숫자의 취급)

세상에 내놓을 때, 나는 자주 "자체 연구 지식 약 4.9만 건(약 49k)"이라고 반올림한다. 이 숫자의 출처는, 2026년 5월 9일의 대규모 확장 시의 집계 기록(확장으로 16,377 docs를 추가하여 total 약 48,800에 도달)이다.

다만, 이번에 디스크상에서 전체 documents 수를 실카운트해 다시 잰 것은 아니다(코퍼스 수 65와 일부 코퍼스의 note 수는 실카운트 검증 완료). 또 hacker_corpus는 raw(날) 집약 파일로, 1파일이 다수의 docs를 품는 형태이므로, "파일 수"와 "내포 docs 수"가 일치하지 않는다.

그래서 정직하게 쓰면 —

약 65분야·약 4.7만 노트(Markdown 실수). 별도로 hacker_corpus 약 3.2만 파일. 반올림하여 '약 49k건 규모'라고 말할 경우는 '2026년 5월 확장 시의 집계값'이라는 시점을 붙여서.

첫머리에서 말한 "비정상적으로 큰 숫자는 내역을 의심한다"를, 내 숫자에도 담담하게 적용하고 있는 셈이다.

RAD의 운용 룰 — 축적 일변도로 하지 않는다

RAD는 "모으고 끝"이 아니다. 세 가지 운용 규율이 있다.

K² 사이징 … 코퍼스의 크기는 "100 고정"이 아니라, 토픽의 내부 분류 수 K에 대해 약 K² 노트를 목표로 한다(K≈10이면 약 100). 너무 얇으면(약 40 미만) K²로 확장한다.
신선도 × 가치로 가지치기 … rad_prune.py가 각 노트를 "신선도(수집으로부터의 경과 시간의 지수 감쇠) × 가치(본문량 + 출처의 유무)"로 채점하고, 하위를 .pruned/로 대피시킨다. 삭제는 불가역이므로 기본은 dry-run(실제로는 지우지 않고, 무엇이 지워질지를 예행연습으로 보여 줄 뿐), 실삭제는 --hard 지정 시에만. 이것도 fail-closed의 발상이다.
에이전트 직접 쓰기 … 수집은 arxiv / scholar-search / fetch / firecrawl / WebSearch를 총동원하고, 결과를 디스크에 직접 쓴다. 이것은 과거에 "거대한 수집 결과를 main 컨텍스트로 되돌려 session limit에 도달한" 교훈을 반영한 설계다.

이 글의 3테마에 직결되는 코퍼스로서, loop_engineering_corpus_v2가 실재한다. 이것은 a001..a048(48노트) + b001..b048(48노트) = 총 96노트의 file-per-note 구성이고, SKILL.md의 note_count도 96으로 일치(score 0.982).

내용은 — 제어 피드백(PID / anti-windup〔적분항의 폭주를 억제하는 구조〕/ state-space〔상태 공간 표현〕/ Lyapunov〔안정성 해석〕/ MPC〔모델 예측 제어〕/ MAPE-K / OODA / cybernetics), 자율 에이전트 루프(ReAct / Reflexion / Plan-and-Execute / Self-Refine / Tree-of-Thoughts 등), 강화 학습의 각 유파(policy-value iteration / PPO / RLHF / RLAIF / Constitutional / RLVR / AlphaZero 등), 운용 CI(GitOps reconciliation / watchdog / chaos engineering) — 를 망라한다. 실 노트 예: a001_pid_control / a009_ooda_loop_boyd / a013_mape_k_autonomic_loop / b001_mape_k_autonomic_reference_loop.

즉, 제2장의 llloop의 MAPE-K도 safety도 green-keeper(GitOps reconciliation)도, 이 코퍼스를 설계 근거로 삼아 구현된 것이다. 지식(코퍼스) → 루프(llloop)라는 흐름이, 실물로 이어져 있다.

honest disclosure("50수법"과 "96노트"의 어긋남)

처음 메모에는 loop_engineering = 50수법이라고 있지만, 실체는 96노트(2샤드) 다. 이것은 "처음에 50수법을 조사의 기점으로 삼고, 나중에 file-per-note로 96노트로 확장했다"는 시계열의 차이다. 그래서 이 글에서는 "약 50의 수법을 기점으로 96노트로 확장"이라고 쓴다. "96수법"이라고 부풀리지 않는다.

게다가, corpus2skill(후술)로 생성한 계층 스킬 쪽(.claude/skills/corpus/loop_engineering/INDEX.md)은 "39 documents / 12 clusters"라고 표시한다. 이것은 오래된 소스 버전에서 빌드된 계층이고, 최신의 96노트를 재차 corpus2skill 하지 않았기 때문이다. 날 코퍼스(96)와 계층 스킬(39)의 수를 혼동하지 않도록 주를 달아 둔다.

3-2. LLM Wiki — "자라는 지식"의 패턴

모은 지식은, 내버려 두면 "그저 산"이다. 검색은 가능해도, 이어져서 자라는 일은 없다. 그래서 LLM Wiki 패턴이 효과를 발휘한다.

이것은 Andrej Karpathy 씨의 발언으로 유통되고 있는 패턴(메모로는 2026-04의 Gist 유래. 다만 일차 Gist의 URL을 본 글에서 확인하지 못했으므로, 제안자·날짜 모두 헤지한다)으로, 지식을 세 층으로 가진다.

날 소스 층(raw, 변경 불가) … 원래의 문헌·로그. 개변하지 않는다.
Wiki 층(compiled, LLM이 관리하는 개념 페이지) … LLM이 요약·상호 링크하여 엮는 "개념 페이지".
스키마 층(schema) … "어떤 페이지를, 어떻게 갱신할까"의 설계도.

풀어쓰기: RAG와 LLM Wiki의 차이

RAG(검색 증강 생성) 는 "질문이 오면, 그때마다 도서관으로 달려가 관련 책을 찾는" 방식. 온디맨드다.

LLM Wiki 는 "자주 쓰는 지식을, 미리 정리하여 Wiki에 정리해 두고, 그것을 돌려 쓰는" 컴파일형. 먼저 정리해 두는 방식이다.

이 둘은 대립이 아니라 상호 보완이다. 이상형은 "정리된 Wiki를, RAG로 검색한다" — 잘 정돈된 도서관(Wiki)을, 사서(RAG)가 재빨리 안내한다, 는 이미지다.

나는 이 LLM Wiki 패턴을, 두 실체에 대응시키고 있다(둘 다 설계 단계이고, 구현은 후속 페이즈임을 명시한다. 이하는 "나의 매핑(주관)"이지, 구현된 동형성은 아니다).

llive(self-evolving modular memory LLM 프레임워크)의 Phase 2-4 요건 LLW-01~08. 예를 들어 LLW-01 ConceptPage, LLW-02 Wiki Compiler, LLW-04 모순 검출, LLW-08 RAG×Wiki 2층 운용.
RAPTOR 의 corpus2skill 을, 지속 갱신형 ingest 루프로 확장하는 v2 구상.

llive의 4층 메모리 설계는, 나의 대응에서는 Karpathy 씨의 패턴과 구조적으로 맵핑할 수 있다(어디까지나 설계 의도로서의 대응이고, 구현은 이제부터). semantic memory ≈ Wiki 층, episodic memory ≈ 날 소스 층, Hippocampal Consolidation Scheduler ≈ Wiki Compiler, Contradiction Detector ≈ 모순 지적, structural memory(그래프) ≈ 페이지 간 링크, Provenance ≈ 소스 추적.

★ LLM Wiki 최대의 함정: 사고의 순환

여기는 honest disclosure와 표리일체인, 중요한 설계상의 경고다. LLM Wiki의 최대의 함정은 "사고의 순환(thought circulation)" 이다.

LLM이, 자신이 쓴 Wiki 페이지를 근거로 삼아, 새로운 페이지를 생성한다. 그러면, 최초의 작은 할루시네이션(그럴듯한 오류)이, "합의"로서 고정화되어 간다.

자신이 쓴 잘못을, 자신이 인용하여, 그것을 옳은 것으로 만들어 버린다. 혼자서 소문을 퍼뜨리고, 그 소문을 "모두가 말하고 있다"고 믿어 버리는 것과 같다. loop는 빠르므로(제2장의 Verloy 씨의 경고를 떠올려 주시길), 이 순환도 머신 속도로 고정화되어 버릴 수 있다.

llive는 이에 대해 Anti-Circulation Safeguards(반순환의 안전 장치, LLW-AC-01~08) 를 설계하고 있다(설계 단계).

raw events를 authoritative(정본)로 하고, 기존의 요약은 working draft(작업 중인 초안)에 지나지 않는다고 다룬다.
1사이클 내에서의 연쇄 통합을 금지(자기 출력을 즉시 다음 근거로 삼지 않는다).
drift detection을 주기 실행(어긋남의 정기 점검).
diversity preservation(소수파의 증거를 보호하고, 다수파에 덮어쓰이게 하지 않는다).
외부 ground-truth anchor(CAD / DOI / 형식 검증의 hash 등, 외부의 움직이지 않는 사실)를 필수화한다.

마지막의 "외부 앵커 필수"는, 이 글 전체를 관통하는 자세 — 일차 정보주의 — 그 자체다. AI가 자기 안에서만 완결시키지 않고, 반드시 바깥의 움직이지 않는 사실에 닻을 내린다.

덧붙여, FullSense(후술)는 llmesh / llive / llove의 3제품으로 구성된다. LLM Wiki의 역할을 제품에 맵핑하면 llive가 "Wiki 편집자", llove가 "Wiki의 UI", llmesh가 "날 소스를 나르는 Bus" 에 해당한다(RAG는 제품이 아니라 검색의 수법이므로, 제품의 열에는 넣지 않고, 3제품 위에서 쓰는 도구로 자리매김한다).

3-3. RAPTOR가 "지식을 안전하게 쓰는" 입구를 겸한다

지식(RAD / LLM Wiki)을, 누가 안전하게 쓰는가. 그것이 제1장의 RAPTOR 다. RAPTOR에서는, /sourcehunt(파일 단위의 취약점 헌트)를 돌리면, corpus가 존재하면 knowledge base가 자동 로드되고, get_hints(tags)로 분석 컨텍스트에 근거 부여하여 주입된다.

그리고 RAPTOR는, 지식의 사용법 자체에 증거의 단계를 들여오고 있다. /sourcehunt의 증거 사다리(evidence ladder) 는 6단이다.

suspicion(의심)
  → static_corroboration(정적인 뒷받침)
    → crash_reproduced(크래시 재현)
      → root_cause_explained(근본 원인의 설명)
        → exploit_demonstrated(익스플로잇 실증)
          → patch_validated(패치 검증 완료)

ASan / UBSan(실행 시에 메모리 이상이나 미정의 동작을 검출하는 새니타이저)이 크래시를 재현하면, 증거가 "정적인 뒷받침"에서 "크래시 재현"으로 격상되고, 이것이 PoC(Proof of Concept = 취약점을 실제로 밟을 수 있는 실증 코드) 생성의 게이트가 된다. 즉 "의심"을 "실증"과 동렬로 다루지 않는다. 증거의 무게를 단계로 표현한다.

이것은 출력 스타일에도 제도화되어 있다. RAPTOR의 상태는, JSON에서는 snake_case(exploitable / confirmed / ruled_out / disproven), 인간 가독에서는 Title Case, ALL_CAPS는 금지. 게다가 🔴/🟢의 적록 인디케이터는 금지다. 이유가 훌륭한데 — "방어 측에 나쁨 ≠ 연구자에게 나쁨", 즉 좋고 나쁨은 시점에 의존하므로, 안이하게 적록으로 단정하지 않는다. findings를 과장하지 않고, 증거 레벨로 단계 표현한다. 이것은 honest disclosure를 설계 레벨에서 강제하는 구조다.

3-4. corpus-first advantage — 1인 개발이라도 "다시점"이 될 수 있다

마지막으로, 왜 이 "지식 스택"이 내 독자 축(제1장)과 맞물리는가.

corpus-first(코퍼스 선행) 전략이라는 깨달음이 있다. RAD 코퍼스를 먼저 키워 두면, 1인 개발이라도, 사용자가 의식하지 않는 관점 — Six Hats(여섯 개의 모자), TRIZ(발명 원리), KJ법, MindMap, 이종 분야 유추 — 가, AI의 사고 플로에 보완될 수 있는 것이다.

여기는 "될 수 있다"고 조건부로 쓴다. 코퍼스 참조는 만능이 아니다. 관련성 필터가 효과를 발휘하지 않으면, 무관계·오래된 지식이 섞여서 오히려 노이즈가 된다. 실제로, 3-1에서 쓴 "신선도 × 가치의 가지치기"는, 바로 이 노이즈 혼입을 억제하기 위한 장치다. 그래서 정확히는 "관련성 필터가 효과를 발휘하는 전제에서, 다시점이 보완될 수 있다"가 올바른 온도감이다.

구체적인 예를 하나. 제2장의 llloop의 안전 층을 설계할 때, 나는 "fail-closed를 3단(ALLOW/CONFIRM/FORBID)으로 한다"는 발상을, loop_engineering_corpus_v2의 제어 이론 노트 군(anti-windup이나 circuit breaker 패턴)과, RAPTOR의 governance(DENY/REVIEW/허가 리스트 밖 DENY)의 양쪽에서 끌어왔다. 혼자서 설계하고 있어도, 코퍼스가 "제어 공학의 시점"과 "보안의 시점"을 배후에서 겹쳐 주었다 — 이것이 corpus-first의 효과의 한 예다.

이것은 "AI를 쓴다(답을 듣는다)"와 "AI와 함께 만든다(배경에서 코퍼스를 참조하고, 다시점을 보완하면서, 설계 판단은 인간이 쥔다)"의 차이에 대응한다. 제1장에서 "사용자 쪽에 발상력·경험칙·알고리즘 이해의 세 능력이 필요하다"고 썼다. corpus-first는, 그 세 능력을 AI 쪽의 지식 기반으로 증폭할 수 있는 장치다(노이즈 관리가 전제, 라는 유보를 붙여서).

인간이 고삐를 쥐고(A), 루프가 안전하게 돌고(B), 그 루프에 다시점의 지식이 흘러든다(C) — 여기서 세 가지가 하나로 이어진다.

제3장은 "무엇을(구현과 지식)"였다. RAD로 지식을 모으고, LLM Wiki로 키우고(순환의 함정에 안전 장치를 달고), RAPTOR가 증거의 단계를 지켜 안전하게 쓴다. 드디어 통합이다.

통합 장: A(왜) → B(어떻게) → C(무엇을)가 하나의 세계관이 된다

여기까지의 3장을, 한 장으로 접는다.

	테마	물음	실물	"또 하나의 축"
A	harness engineering	왜(철학)	RAPTOR의 2층 분리	인간이 고삐를 쥐고, AI를 부하로서 기른다
B	loop engineering	어떻게(제어)	llloop(MAPE-K + fail-closed, alpha)	안전 층은 현 상태의 경로에서는 우회 불가·전략을 교체하여 비교
C	RAD + LLM Wiki	무엇을(지식)	약 4.7만 노트(※2026년 5월 집계 시점) + 증거 사다리	corpus-first로 혼자라도 다시점·일차 정보주의

업계의 도식은, A와 B와 C를 따로따로 유행어로 늘어놓기 쉽다. 내 주장은 — 이 셋은, 하나의 세계관의 세 개의 얼굴이다 라는 것이다. 그 세계관의 핵심은, 단 두 개의 원리로 수렴한다.

첫 번째는 "책임 소재를 architecture level로 들여온다". Approval Bus도 SafetyPolicy도 증거 사다리도, "조심하자"는 운용 근성론이 아니라, 우회하기 어려운 구조로 구현한다. 제1장의 @govern, 제2장의 SafetyPolicy, 제3장의 증거 사다리는, 모두 이 한 점에 봉사하고 있다.

두 번째는 "honest disclosure를 핵심에 둔다". 비정상적으로 좋은 숫자("Bölük 10×")가 나오면, 이긴 기분이 들기 전에 내역을 의심한다. 이 글의 각 장에서, 내 숫자(49k건, 테스트 90건, 50수법 vs 96노트)에도 같은 작법을 적용했다.

그리고 이 세계관은, 로컬에서 완결된다. RAD도 llloop도 RAPTOR도, 전부 손안에서 돌고, 개인 정보·기업 기밀·센서 데이터를 바깥으로 내보내지 않는다. 덧붙여, 이 자체 스택(llloop / RAD / RAPTOR)은, 내가 별도로 FullSense 라고 부르는 제품 에코시스템(llmesh / llive / llove의 3제품 + suite installer)과는 별개의, 로컬의 연구 스택이다. 양자는 사상을 공유하지만, 제품 라인과는 선을 그어 둔다(llive만은, 제3장에서 언급한 LLM Wiki의 받침대로서 양자를 가로지른다).

왜 "고삐를 쥐는 것은 인간"이라고 말할 수 있는가 — 관찰 기반의 3점

마지막으로, 제1장에서 예고한 "우위성의 논거"를 여기에 일원화한다. 다만 먼저 정직하게 말하면, 이하는 일차 연구의 인용에 근거한 measured한 결론이 아니라, 내 경험에 근거한 관찰(구조적 경향) 이다. "인지 과학적으로 증명되었다"고 말하지 않는다. 그 위에서, 인간이 구조적으로 AI보다 유리해지기 쉬운 점이, 적어도 세 가지 있다고 생각한다.

상시 병렬 … LLM은 기본 1세션 고정이지만, 인간은 여러 가지를 뒤에서 계속 돌릴 수 있다.
장사정의 복선 회수 … LLM이 회수할 수 있는 것은 1세션 내(수 시간)의 복선. 인간은 10년 전의 경험으로 깔아 둔 복선을, 오늘 회수할 수 있다.
상시 가동의 위험 예지(KYT) … LLM의 risk_alert는 명시적으로 코드를 쓰지 않으면 작동하지 않지만, 인간은 무의식으로 상시 돌리고 있다(아찔·아슬을 "어쩐지" 피하는, 그 감각).

그래서 "고삐를 쥐는 것은 인간"인 것은, 근성론이라기보다 관찰된 경향이다. 그리고 나의 llive는, 이 인간의 경향을, 조금씩 architecture level로 들여오려 하고 있다 — 라는 것이, A와 B와 C를 관통하는 동기다.

마치며: 고삐와, 고리와, 지

2026년, AI 업계는 prompt engineering의 다음에, harness engineering(고삐) 와 loop engineering(고리) 를 이름 붙였다(발명한 것은 AI가 아니라, 인간 엔지니어들이다). 나는 그 시제품 스택을, 개념 증명 수준으로 로컬에 가지고 있다.

고삐(A) … RAPTOR가 "Python이 전부 제어하고, LLM은 판단에 전념하는" 2층 분리로 구현. 거기에 "인간이 고삐를 쥐고, AI를 부하로서 기른다"는, 모델 중심의 도식에의 보조선을 더했다. Karpathy 씨의 "vibe coding"(2025-02)과는 별개 계통이고, "내가 먼저 명명했다"고는 말하지 않는다.
고리(B) … 직접 만든 llloop(alpha·미공개)이 MAPE-K로 돌고, 현 상태의 경로에서는 우회 불가의 fail-closed 안전 층으로 브레이크를 건다. LLM은 제안밖에 할 수 없고, 최종 게이트는 SafetyPolicy.
지(C) … 약 65분야·약 4.7만 노트(※5월 집계 시점)의 RAD를, LLM Wiki 패턴으로 키우고(사고의 순환에는 반순환의 안전 장치를 달고), RAPTOR가 증거의 단계를 지켜 안전하게 쓴다.

그리고 이 글을 관통한 것은, 단 하나의 작법이었다.

비정상적으로 캐치한 숫자를 보면, 이긴 기분이 들기 전에 내역을 의심하라. 일차 정보에 닻을 내려라.

"Bölük가 10×를 보여 줬다"는, 쓰고 싶어지는 숫자를, 일차를 확인하여 버렸다. 이것은 약점의 공개가 아니라, 설계 사상의 일부다. 고삐를 쥐는 인간에게 필요한 것은, 유창한 숫자를 간파하는 "무지의 지"이기 때문이다.

다음 회 예고적인 여운

다음에 쓰고 싶은 것은, 제3장에서 "설계 단계"라고 몇 번이고 헤지한 LLM Wiki의 구현 — llive Phase 2-4의 LLW-01~08과, RAPTOR corpus2skill의 v2화 — 의, 실기에서의 진척이다. "사고의 순환"에 반순환의 안전 장치를 단 위에서, 지식이 스스로 자라 가는 모습을, 움직이는 그림으로 보여 줄 수 있으면 한다.

고삐를 쥐고, 고리를 안전하게 돌리고, 지를 키운다. 그 전부를, 외부에 데이터를 내보내지 않고, 로컬에서. — 그것이, 내가 생각하는 "2026년의 패러다임 전환"의, 땅에 발을 딛은 모습이다.

참고(출처)

harness / loop engineering(용어의 일차·준일차)

Mitchell Hashimoto, My AI Adoption Journey(2026-02-05, "harness engineering"의 제시. hedge와 날짜를 일차 확인): https://mitchellh.com/writing/my-ai-adoption-journey
Andrej Karpathy, "vibe coding" 원 트윗(2025-02-02, URL·날짜 확인 완료): https://x.com/karpathy/status/1886192184808149383
Data Science Dojo, Agentic Loops Explained: From ReAct to Loop Engineering (2026 Guide)(2026-06-09): https://datasciencedojo.com/blog/agentic-loops-explained-from-react-to-loop-engineering-2026-guide/
Filip Verloy, From Prompt Engineering to Loop Engineering(2026-06, "scaling risk at machine speed"): https://medium.com/@filipv_74515/from-prompt-engineering-to-loop-engineering-why-the-agent-era-demands-a-new-security-paradigm-816385040e3d
Claude Code 공식 docs, /goal(v2.1.139 이후, Haiku 판정의 자율 반복. 버전 요건과 Haiku를 일차 확인): https://code.claude.com/docs/en/goal
arXiv:2605.18747 Code as Agent Harness(Xuying Ning 외 총 42명, 2026-05-18. 본 글 집필 시에 재확인. ※"Bölük", "10×"는 모두 본 논문에 존재하지 않는다): https://arxiv.org/abs/2605.18747
arXiv:2605.26112 From Model Scaling to System Scaling: Scaling the Harness in Agentic AI(제1저자 Shangding Gu, 2026-05-25. 소속은 abstract 페이지 미기재 = "UC Berkeley"는 이차 정보): https://arxiv.org/abs/2605.26112
arXiv:2605.27922 Harness-Bench: https://arxiv.org/abs/2605.27922

RAPTOR(실물 스택)

upstream 리포지토리(gadievron/raptor, MIT. 작자 Gadi Evron 씨 외 5명): https://github.com/gadievron/raptor

관련 기사(자작)

스마트폰에서 SSH로 Windows PC의 Claude Code를 조작하는 방법: https://qiita.com/furuse-kazufumi/items/be52eeb6455732161486

막간(스낵 버스에 / 포비든 시부카와, Alu)

"IQ에 차이가 있는 자와는 대화가 맞물리지 않는다": https://alu.jp/series/スナックバス江/crop/PJm0yAGeJy9iSa487mrX
"수수께끼의 그래프 덕분에 비장감이 옅다": https://alu.jp/series/スナックバス江/crop/UfjgydbJNoh5HDTItAlf
"무지의 지": https://alu.jp/series/スナックバス江/crop/JRY5aSqHgjWRo1QnfR2l

※ 본문 중에서 헤지한 "이차 정보뿐 / 일차 미확인"의 주요 항목은 다음과 같다: OpenAI 기사의 본문·태그라인·규모 수치(일차는 HTTP 403), LangChain의 Agent = Model + Harness 식과 각 하네스 벤치의 계측 출처·계측 조건(GPT-5.5로 여겨지는 모델명을 포함), Claude Code v2.1.139의 릴리스 날짜, llloop의 테스트 녹색의 최신 상태(재실행은 미실시), RAD 총 documents 수("약 49k"는 2026년 5월 집계값), Karpathy 씨 LLM Wiki Gist의 제안자·날짜, 캐논 "삼자의 정신"과 First, Break All the Rules 4원칙의 출처 페이지, 제3장의 "인간 우위 3점"(measured가 아니라 관찰 기반). 일차 정보로 확정되는 대로, 갱신한다.