#43 2026년, 업계는 AI를 위해 「고삐(Harness)」와 「바퀴(Loop)」라는 이름을 붙였다 —— 내가 로컬에

이 글을 쓰려고 준비하던 중, 나는 무척이나 사용하고 싶어지는 숫자 하나를 발견했습니다.

「어떤 2026년의 논문에 따르면, AI 모델을 변경하지 않은 채 『주변 컨테이너』만을 변경했을 때 최대 10배의 성능 향상을 보여주었다.」

도입부의 갈고리(Hook)로서 완벽합니다. 다음에 설명할 「harness(컨테이너)」의 위력을 단번에 보여줄 수 있기 때문입니다. 하지만 정보원을 한 번 확인해 보았을 때, 이 숫자는 출처가 불분명했습니다. 논문은 실제로 존재했지만, 인용된 저자 이름과 「10배」라는 숫자는 그 논문에 존재하지 않았습니다. 그래서 나는 이 숫자를 폐기했습니다.

왜 이렇게 부정적인 이야기로 시작할까요? 그것은 「폐기」하는 행위야말로 내가 이 글에서 가장 전달하고 싶은 것이기 때문입니다.

눈에 띄는 숫자를 보았을 때, 스스로 이겼다고 생각하기 전에 반드시 그 내부 구성을 의심해야 합니다. 하나의 정보원에 닻을 내리세요.

똑똑한 AI는 자신이 모르는 일조차 유창하게 떠들 수 있습니다. 만약 무심코 명령을 내린다면, AI는 똑똑하기 때문에 멋대로 내용을 보충하여 당신의 의도와는 전혀 다른 곳으로 전력 질주할 것입니다. 그렇기에 인간 측에는 「이곳은 아직 검증되지 않았다」라는 경계선을 그을 수 있는 눈이 필요합니다. 이 글은 바로 그 눈을 가진 사람이, 2026년 AI 엔지니어링의 「다음 이름」을 발로 뛰며 검증해 나가는 이야기입니다.

(폐기된 숫자에 대한 상세한 검증은 제2장 이후의 독립된 절에서 모두 공개하겠습니다. 이 방식을 먼저 약속해 두고 싶기에 결론만 서두에 배치합니다.)

본론에 들어가기 전, 지도를 먼저 펼쳐보겠습니다.

2025년, AI 업계의 슬로건은 prompt engineering (프롬프트 엔지니어링) —— 「LLM에 어떻게 명령을 내릴 것인가」를 다듬는 기술이었습니다. 머지않아 이는 context engineering (컨텍스트 엔지니어링) —— 「LLM이 사전에 무엇을 보게 할 것인가」를 설계하는 기술로 확장되었습니다.

그리고 2026년에 이르러, 업계에는 두 개의 이름이 더 추가되었습니다.

harness engineering (고삐 엔지니어링 / 패키징 레이어 엔지니어링) …… LLM을 감싸는 「결정론적 런타임 레이어(Deterministic Runtime Layer)」를 설계하는 기술.

loop engineering (루프 엔지니어링 / 순환 엔지니어링) …… 에이전트(Agent)를 「자율적으로 작동하는 순환 구조」로 설계하는 기술.

여기서 먼저 밝혀둡니다. 「이것들을 발명한 것은 AI가 아니라 인간(업계)입니다」. 제목에 「AI가 발명했다」라고 쓰는 의인화된 충동은 사실을 왜곡할 수 있습니다. 명명한 주체는 다음에 소개할 인간 엔지니어들입니다.

이 글의 핵심 이념은 다음과 같습니다.

업계가 명명한 이 두 가지를 나는 이미 개념 증명(PoC) 단계에서 내 손 곁(로컬)에 두었습니다. 다만, 나의 설계도에는 업계의 모델 중심 해설도에는 나타나기 어려운 「또 다른 축」이 하나 더 있습니다.

그 축은 바로 항상 고삐를 쥐고 있는 인간, 그리고 부하 직원처럼 육성되는 AI입니다. 본문은 내가 실제로 실행 중인 구현체인 —— RAPTOR (안전 에이전트), llloop (자작 순환 harness · alpha), RAD (말뭉치) + LLM Wiki (자체 연구 지식) —— 를 통해 (A) harness, (B) loop, (C) 이 둘을 지탱하는 지식 기반이라는 세 가지 주제를 검증할 것입니다.

이 글은 긴 글(약 2만 자, 20분 분량의 강의)입니다. 중요한 지점마다 용어의 쉬운 설명 (Breakdown), 잠시 쉬어가기 (Interlude), **정직한 내부 공개 (Honest Disclosure)**를 섞어 넣겠습니다. 지치신다면 장과 장 사이에서 숨을 고르시기 바랍니다.

2026년 현재, AI 엔지니어링의 「성숙도」는 대략 다음과 같은 단계로 서술할 수 있습니다.

prompt engineering …… 일회성 명령문을 다듬는 단계.

context engineering …… LLM의 시야(컨텍스트 윈도우)에 무엇을 담을지 설계하는 단계.

harness engineering …… LLM의 「외부 컨테이너」를 설계하는 단계. 도구 호출(Tool Call), 권한, 실행, 결과 회신을 담당하는 레이어.

loop engineering …… 이 컨테이너를 「자율적으로 작동하는 순환 구조」로 설계하는 단계.

어떤 해설 매체는 이를 「제4 패러다임」이라 부르며, LangChain (에이전트 개발 라이브러리)은 이를 **Agent = Model + Harness (에이전트 = 모델 + harness)**라고 요약합니다 (augmentcode.com의 해설을 통해 확인한 2차 정보입니다. 1차 출처인 LangChain 원문은 아직 확보하지 못했기에 상쇄를 위해 명시합니다. 이후 이 공식을 다시 인용할 때도 「2차」라고 표기하겠습니다).

harness라는 영어 단어는 원래 「마구(말의 장구)」 또는 「(아기나 암벽 등반가를 안전하게 매다는) 안전벨트」를 의미합니다.

LLM은 매우 똑똑하지만, 방치하면 멋대로 날뛰며 가야 할 곳이 아닌 곳으로 달려가거나, 때로는 바닥이 없는 곳으로 발을 내디딜 수도 있습니다. 마치 「힘이 아주 센 말」처럼 말이죠. 그 말에게 **마구 (harness)**를 채워주면 —— 말이 어디로 갈 수 있는지, 어떤 도구를 사용할 수 있는지, 결과를 어떻게 가져올지가 마구 쪽에서 '딸깍' 하고 결정됩니다. 이것이 harness engineering입니다.

마구라는 비유는 편리하지만, 어디에서 한계가 있는지도 명확히 해야 합니다. 진정한 마구는 단순히 「물리적으로 동작을 구속」할 뿐이지만, LLM의 harness는 「구속」뿐만 아니라 「결과를 정형화하여 말의 눈앞으로 되돌려주는」 역할도 겸합니다. 마구에 「다음은 여기를 봐」라며 말에게 풍경을 보여주는 기능이 부착되어 있다고 생각하면 됩니다. 이 층까지 포함하면 비유가 다소 좁게 느껴질 수도 있습니다.

이곳이 바로 loop engineering의 핵심입니다. 제목에서 저는 loop를 「바퀴(Loop)」라고 번역했는데, 이는 「동일한 일련의 단계를 끊임없이 돌고 있는 바퀴」라는 이미지에서 따온 것입니다. 하지만 이것은 단순한 바퀴가 아닙니다. 2026년 6월의 한 가이드라인은 이 차이를 아주 날카롭게 정의했습니다.

"automation은 일련의 단계를 실행합니다. loop 내부에는 의사결정(decision)이 포함되어 있습니다. 에이전트(Agent)가 목표에 도달했는지 스스로 능동적으로 판단합니다."

(Data Science Dojo, Agentic Loops Explained: From ReAct to Loop Engineering (2026 Guide), 2026-06-09 / 링크)

쉽게 말하자면—

automation (레시피): 「계란 깨기 → 섞기 → 굽기」. 단계가 고정되어 있습니다. 도중에 「아, 계란이 상했네」라고 발견하더라도, 레시피 자체는 멈추지 않습니다.

loop (순환): 매 회전마다 「지금 상황은 어떻지?」, 「목표에 도달했나?」, 「위험하지는 않은가?」를 스스로 확인하며 앞으로 나아갑니다. 상한 계란을 발견하면 그 즉시 「중단」을 판단할 수 있습니다.

여기서 논리적 함정 하나를 미리 제거하겠습니다. 「loop는 의사결정 지점(decision point)을 갖는다」와 「loop는 안전하다」는 별개의 문제입니다. automation이 상한 계란 앞에서도 멈추지 못하는 것은 automation의 본질이라기보다, 「의사결정 지점을 설정하지 않은」 설계의 빈약함에 가깝습니다. 반대로, loop라 할지라도 의사결정 로직에 허점이 많다면 똑같은 사고가 발생할 것입니다. 의사결정의 '지점'을 갖는 것과 의사결정의 '품질'을 보장하는 것은 다른 문제이며, 후자를 책임지는 것이 후반부에 등장할 safety(안전) 층입니다. 이 차이는 본문에서 여러 차례 중요하게 작용할 것입니다.

동일한 가이드라인은 에이전트 순환(agent loop)의 내부를 **Perceive (인지) → Reason (추론) → Plan (계획) → Act (실행) → Observe (관찰)**라는 다섯 단계의 반복으로 묘사하며, 순환이 성립하기 위해서는 「트리거(trigger, 계기)」와 「검증 가능한 목표(verifiable goal)」라는 두 가지 요소가 필요하다고 지적합니다.

'검증 가능한 목표'라는 표현을 기억해 두십시오. 후반부에서 이 용어는 Claude Code의 /goal 명령어와 제가 직접 만든 harness의 안전 층에 그대로 적용될 것입니다.

loop engineering 주변의 출처들(Data Science Dojo, Medium 기사, 각종 블로그)은 동료 검토(peer review)를 거친 논문이 아니라 실무 블로그입니다. 각 정의(automation vs loop, P-R-P-A-O)가 여러 출처에서 일관되게 나타나므로, 저는 이를 「2026년 실무에서 통용되는 용어」로 취급하겠습니다. 다만 「이것이 권위 있는 학술적 정의는 아니다」라는 적절한 거리감을 유지하겠습니다.

타임라인이 중요하기에 정보원을 한 번 더 대조해 보았습니다.

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월 전후로 업계에서 명명되기 시작한 호칭」 정도의 수준에서 다루겠습니다.

그가 설명하는 harness engineering의 핵심 원칙은 장인의 기술처럼 구체적입니다.

"에이전트가 실수를 발견할 때마다, 매번 시간을 들여 에이전트가 다시는 같은 실수를 반복하지 않도록 하는 솔루션을 엔지니어링(engineering)합니다."

(동일 문헌, 원문 확인 완료)

그 후, 2026년 2월 11일 OpenAI는 Ryan Lopopolo 씨가 작성한 기사를 공개했습니다. 해당 글은 「직접 작성한 코드가 0줄인 상태에서 프로덕션급 애플리케이션을 인도한 경험」을 바탕으로 harness engineering을 형식화한 것으로 알려져 있습니다. 그 슬로건은 **"Humans steer. Agents execute." (인간은 조종하고, 에이전트는 실행한다)**입니다.

하지만——여기서 솔직하게 고백하겠습니다. 제가 이 글을 작성할 당시 OpenAI의 공식 문서(openai.com/index/harness-engineering/)에 접속했을 때, HTTP 403 에러가 반환되어 본문을 직접 가져올 수 없었습니다. 따라서 날짜, 저자, 슬로건, 「0행」에 관한 이야기, 그리고 "Humans steer. Agents execute."라는 문장은 모두 2차 정보(augmentcode / latent.space / zenml의 일치된 내용)에 기반한 것입니다. 본문에서 이 슬로건을 다시 인용할 때마다 「(2차 정보)」라고 표기하겠습니다. 「100만 행 · 1500 PR · 일일 10억 토큰」과 같은 실험 규모의 수치는 2차 정보뿐이며 아직 확인되지 않았기에, 본문의 논증 소재로 사용하지 않고 이곳에서 「보도에 따르면 ~」라고 짧게 언급하고 넘어가겠습니다.

먼저 타임라인을 정리해 보겠습니다. Andrej Karpathy 씨(OpenAI 공동 창립자, 전 Tesla AI 책임자)는 2025년 2월 2일의 트윗을 통해 **"vibe coding"**이라는 용어를 전파했습니다(원문 트윗, URL 및 날짜 확인됨). 이는 「AI에게 맡겨, 느낌(vibe)대로 코드를 작성하는」 스타일을 의미합니다.

이 개념은 harness engineering(2026년 2월 전후로 용어화됨)보다 앞서 등장했습니다. 두 개념은 서로 다른 계보를 가진 개념입니다. 후반부에는 저만의 표현이 등장할 예정인데, 이것과 "vibe coding"의 관계에 대해서는 본문 전반에 걸쳐 신중하게 구분하여 서술하겠습니다(이유는 1-4절 참조).

추상적인 논의는 여기까지 하겠습니다. 이제 실물을 보여드리겠습니다.

저는 로컬에서 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을 통한 취약점 검증, 익스플로잇(exploit) 생성, 패치 생성을 하나의 워크플로우로 연결합니다.

그리고 여기서, 사후적으로 개념을 덧씌워 보니 harness engineering의 정의와 매우 매끄럽게 대응되었습니다. 미리 밝혀두자면, RAPTOR의 이 이중 구조는 설계자가 「harness engineering」이라는 업계 용어를 인지한 상태에서 설계된 것이 아닙니다. 이는 제가 사후에 부여한 해석입니다(즉, 관찰자 효과가 포함되어 있습니다). 그럼에도 불구하고 대응이 놀라울 정도로 자연스럽습니다. RAPTOR의 README는 스스로를 명확히 「이중 구조(two-layer architecture)」라고 부르고 있습니다.

「
RAPTOR is two layers. (RAPTOR는 두 개의 레이어로 구성됩니다)
」

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)를 우선 처리할지, 결과를 어떻게 해석할지, 공격 시나리오는 무엇인지, 해당 익스플로잇(exploit)이 현실적으로 가능한지 등을 결정합니다. 「makes the calls (판단을 내린다)」 (upstream README "Architecture" 섹션, L236-250, 본문 대조 완료)

이를 harness engineering의 업계 정의에 대입하면 다음과 같이 대응됩니다. harness(＝Python 실행 레이어)는 스키마(schema) 검증, 권한, 실행, 결과 주입을 담당하고, LLM(＝Claude Code 결정 레이어)은 판단에 집중합니다.

설계 원칙은 저장소의 CLAUDE.md에 더욱 간결하게 규정되어 있습니다.

「
Python orchestrates everything. (Python이 모든 것을 오케스트레이션합니다.)
」

「
Never circumvent Python execution flow. (절대 Python 실행 흐름을 우회하지 마십시오.)
」

또한 「원격 OLLAMA 서버의 위치를 유출하지 말 것」, 「sys.path에 ...」와 같은 규칙들을 강제하고 있습니다.

리스트에 RAPTOR_DIR를 추가하는 것

이외의 것(설정되지 않았다면 즉시 KeyError로 중단 = fail-fast, 폴백(fallback) 없음)과 같은 보안 측면으로 기울어진 규율입니다.

fail-closed는 「확실하지 않으면 허용하지 않는다」는 설계 방침입니다. 반의어는 fail-open(확실하지 않으면 허용한다)입니다.

예를 들어, 차단기(gate)가 고장 났을 때를 가정해 봅시다.

fail-open: 고장 나면 계속 열려 있음 (사람은 통과할 수 있지만, 부정 행위자도 통과할 수 있음).
fail-closed: 고장 나면 계속 닫혀 있음 (아무도 통과할 수 없지만, 부정 행위자도 통과할 수 없음).

이 비유가 어디에서 어긋나는지도 덧붙이겠습니다. 차단기의 경우, 「통과하지 못하는 사람」의 불편함은 일시적일 뿐입니다. 하지만 AI 에이전트의 fail-closed는 「안전하지만, 때로는 정당한 조작까지 함께 차단해 버리는」 대가를 수반합니다. 이 균형을 누가 조율할 것인가—후술할 「인간 확인(CONFIRM)」이 바로 그 완충 장치입니다.

보안의 세계에서는 원칙적으로 fail-closed를 따릅니다. RAPTOR는 여러 곳에서 이를 구현하고 있습니다.

untrusted(신뢰할 수 없는) 저장소를 스캔할 때, RaptorConfig.get_safe_env()는 TERMINAL / EDITOR / VISUAL / BROWSER / PAGER와 같이 「shell이 값을 평가(evaluate)할 가능성이 있는 환경 변수」를 제거합니다. 파일 경로 또한 shell 문자열에 삽입하지 않고 **리스트 인자(list argument)**로 전달합니다 (이는 core/config.py의 get_safe_env 및 CLAUDE.md의 "SECURITY: UNTRUSTED REPOS" 섹션에서 확인할 수 있습니다).

/validate(취약점 검증)의 각 단계 출력은 JSON schema 검증을 거쳐야 하며, 유효하지 않으면 exit 1로 중단합니다 (libexec/raptor-validate-schema).

또한, RAPTOR에는 governance(거버넌스) 패키지가 있으며, @govern 데코레이터가 실제 코드에 구현되어 있습니다 (packages/governance/policy.py). GovernancePolicy는 선언적(declarative) 방식으로 「허용된 도구 / 금지된 도구 / 금지된 패턴 / 요청당 최대 호출 수 / 인간 승인 필요 여부」를 보유하며, check_tool은 다음과 같이 동작합니다—

• 금지 목록에 해당하면 DENY(거부)
• 인간의 승인이 필요하면 REVIEW(보류)
• 허용 목록에도 없다면 DENY (= 알 수 없는 것은 허용하지 않음)

이상의 결과를 반환합니다. 이것은 의심할 여지 없이 fail-closed입니다. 여러 정책을 합성할 때는 "most-restrictive-wins" (가장 엄격한 규칙이 우선) 방식으로 합성하며, DENY/REVIEW 시 PermissionError를 발생시켜 실행을 중단합니다.

지금까지는 업계의 harness engineering과 그 실체(RAPTOR)에 대해 이야기했습니다. 이제부터 나만의 축을 덧붙이려 합니다.

업계의 정의는 **"Humans steer. Agents execute." (인간이 조종하고, 에이전트가 실행한다 / 2차 정보)**입니다. 저는 이에 전적으로 동의합니다. 아니, 오히려 이것은 본래 **인간 중심의 선례(precedent)**입니다. Hashimoto 씨나 OpenAI 모두 인간이 조종한다는 점을 명확히 언급했습니다. 따라서 저는 「업계가 인간의 역할을 묘사하지 않았다」라고 말하지 않겠습니다. 그것은 조사를 충분히 하지 않은 과장입니다.

정확히 말하자면 이렇습니다. 업계의 해설 문서들에는 「harness = 모델을 감싸는 기술적 컨테이너」라는 모델 중심의 도식이 다수를 차지합니다. 설령 「인간이 조종한다」는 방향성을 지적하더라도, 그 인간이 구체적으로 무엇을 하는지, 어떻게 AI를 「육성(cultivate)」하는지에 대한 입도(granularity)는 대부분 깊게 다루지 않습니다. 제가 보완하고자 하는 것이 바로 그 입도입니다.

harness는 「컨테이너」인 동시에 「인간이 지속적으로 고삐를 쥐고 있는 곳」이며, 더 나아가 「AI를 부하 직원처럼 육성하는 곳」입니다.

저는 이것을 마음속으로 harness형 vibe coding이라 부릅니다. 이는 2026년 5월, 저의 작업 스타일을 언어화할 때 튀어나온, 업계 용어의 보조선으로서의 표현입니다.

여기서 저는 한 가지 원칙을 엄격히 지키고자 합니다. 저는 「내가 먼저 명명했다」거나 「이것이 세계 최초다」라고 말하지 않겠습니다. 이유는 두 가지입니다.

• harness engineering이라는 업계 용어(2026-02 전후, Hashimoto 씨의 글에서 날짜 확인됨)가 저의 이 표현(2026-05)보다 앞서 존재합니다.
• 게다가 Hashimoto 씨 본인도 「널리 받아들여지는 용어인지 확실치 않다」라고 말했으므로, 누가 「최초」인지 단정할 수 있는 상황이 아닙니다.

따라서 본문에서 저의 입장은 다음과 같습니다. **「Karpathy 씨의 "vibe coding"(2025-02, AI에게 전권을 위임)과는 명확히 구분되는, 인간 중심의 활용 스타일을 나는 이렇게 부르기로 했다」**는 것입니다. 만약 "vibe coding"이 「AI에게 맡기고 느낌대로 하는 것」이라면, 저의 스타일은 「능동적으로 harness를 계속 꽉 쥐고, AI를 부하 직원처럼 육성하며 사용하는 것」입니다.

이후 저는 이 신조어를 전면에 내세우기보다, **기능(고삐를 쥔 인간 / 부하를 육성)**의 관점에서 서술하고자 합니다.

요소	내용
harness	Claude Code / Codex / Cursor / Aider 등 에이전트(Agent) 기반의 개발 환경
vibe	사용자 측의 이미지 · 직관 · 전체적인 느낌 (=고차원적인 방향성)
coding	AI가 세부 사항을 채워 넣는 구현 작업

사용자는 harness를 통해 이 세 가지를 연결합니다. "vibe"(직관)는 버려야 할 것이 아니라, **가장 가치 있는 입력(Input)**으로서 다루어져야 합니다.

이 축의 핵심은 「인간이 그저 방관만 해서는 안 된다」는 점에 있습니다. 저는 사용자 측에 세 가지 능력이 필요하다고 생각합니다.

능력	역할	개인적인 근거
구상력	고차원적인 방향 제시 · 분야를 넘나드는 연상 · 새로운 요구사항의 발견	「Muscular Star + R.O.D + 윤회(Reincarnation) + ROS PBT」라는 네 가지 연상을 통해, 파생 그룹이 진화하는 설계가 순식간에 완성되는 듯한 폭발력
경험칙	설계 판단의 지름길 · 유사한 실패에 대한 예측 · 불필요한 탐색의 중단	30년의 엔지니어 경험 + 정밀 계측 + 산업 IoT + DX 경험
알고리즘 이해	AI가 제시한 구현의 적절성 검증 · 계산 복잡도(Computational Complexity) 추산 · 핫스팟 경로 파악 · 벤치마크의 정직한 공개 (Honest disclosure)	「단일 실행 시 약 0.8배, 배치(Batch) 실행 시 약 12.7배」라는 차이를 즉각적으로 평가해낼 수 있는 지적 능력

세 번째인 「알고리즘 이해」가 특히 중요합니다. 흔히 말하듯, AI는 유창하게 틀립니다. 유창한 오류를 꿰뚫어 보려면, 당신에게는 계산 복잡도를 추산할 수 있는 눈이 있어야 합니다. 이는 새로운 통찰이라기보다, 활용 측면에서의 구체적인 이야기입니다. 예를 들어, 한 달 전 제가 직접 계측한 「단일 0.8배 / 배치 12.7배」와 같은 사례가 그렇습니다. AI는 흔히 「배치 실행 시 12배 빠르다」라고만 보고하곤 합니다. 하지만 「단일 실행 시에는 오히려 느려졌다」는 불편한 내부 구성을 놓치지 않으려면, 복잡도를 추산할 수 있는 눈이 필요합니다.

이것이 제가 이 축을 통해 가장 말하고 싶은 점입니다. AI를 사용하는 것은 부하 직원을 육성하는 것과 놀라울 정도로 닮았습니다. 대조표를 만들면 다음과 같습니다.

부하 직원 육성	AI 육성 (구현상의 승계 지점)
목표 공유	CLAUDE.md / memory / requirements docs를 통해 매 세션마다 의도와 제약 사항을 전개
...

여기서 중요한 유보 사항을 하나 덧붙여야 합니다. 이 대조표는 「비유가 효과적임」을 보여주는 것이지, 그 자체로 「인간이 AI보다 우월함」을 증명하는 것은 아닙니다. 인간을 관리하는 책을 AI 팀에 그대로 적용할 수 있다는 것은 은유의 유효성을 의미하는 것이지, 우월성의 근거가 아닙니다. 우월성에 대한 논거는 본 장이 아니라, 제3장 끝부분의 세 가지 포인트(병렬성 / 장거리 사정거리 / 위험 예측)에서 통합적으로 다뤄질 것입니다. 여기서 저는 오직 「육성의 구조는 전이(Transfer)될 수 있다」는 점만을 주장합니다.

왜 전이가 효과적일까요? 그 이유는 네 가지로 정리할 수 있습니다.

• AI는 컨텍스트(Context)를 빠르게 잃는다 → 확인을 기다리는 비용이 「다소 편차가 있더라도 앞으로 진행하는 것」의 가치보다 커질 수 있습니다.
• AI는 다시 만드는 비용이 저렴하다 → 자율적으로 작업하다 실수를 하더라도 즉시 수정할 수 있습니다. 재구축 비용이 낮습니다.
• AI는 쉬지 않는다 → 인간의 확인을 기다리는 것이 가장 큰 병목(Bottleneck)입니다.
• AI는 설명할 수 있다 → 왜 그렇게 판단했는지 사후에 감사 로그(Audit log)를 통해 추적할 수 있습니다.

또한, 이 생각에는 계보가 있습니다. 이는 Marcus Buckingham 씨와 Curt Coffman 씨의 명저 First, Break All the Rules(원작 1999년, 미국 Gallup사의 대규모 조사를 바탕으로 한 경영서)에서 설명하는 「개성을 발휘하는 관리」를 인간에서 AI 팀으로 전사(Transcribe)한 것입니다. 그들의 네 가지 원칙—(1) 재능을 바탕으로 인재 선발 (2) 올바른 결과 정의 (3) 강점에 집중하게 함 (4) 적재적소에 배치—은 「인간 → AI 팀」의 관리에도 거의 그대로 전이될 수 있다고 느꼈습니다.

인간 매니저가 인간 팀을 이끄는 책은, 거의 그대로 인간이 AI 팀을 이끄는 책으로 읽힐 수 있습니다.

(덧붙여, 제 수중에는 캐논의 「삼자 정신(자발 · 자치 · 자립)」을 AI에 적용해 정리한 자료도 있으나, 이는 기업 내부에서 구전되는 훈계로서 출처를 한 번에 확인할 수 없기에, 본문에서는 각주 형태로 이름만 언급하겠습니다. 논증의 기둥은 여전히 First, Break All the Rules에 두겠습니다.)

• 「harness형 vibe coding」이 제가 만든 용어인지, 혹은 저의 추측인지 외부 검색을 통해 확인하지는 못했습니다. 따라서 「명명했다/세계 최초다」라고 쓰지 않고, 「나는 이렇게 부른다」라고만 기술하겠습니다.
• 「약 0.8배 → 약 12.7배」와 같은 수치는 약 한 달 전 시점의 기록이며, 최신 코드에서 다시 검증하지는 않았습니다. 숫자 자체보다는 「이러한 불편함의 내부 구성을 꿰뚫어 볼 수 있는 눈이 필요하다」라는 논점을 염두에 두고 읽어주시기 바랍니다.

부하를 육성하는 것과 마찬가지로, 「육성」에도 금기사항이 있습니다.

• 「데이터가 없다」는 이유로 사용자의 직관을 부정하는 것.
• 「선행 연구를 먼저 살펴보자」며 경험칙 (Heuristics)을 대체하는 것.
• 알고리즘에 대한 논의를 추상론으로 회피하는 것.
• AI를 「도구」로만 취급하며 육성하지 않고, 매번 처음부터 다시 시키는 것.
• 너무 엄격하거나 너무 느슨하여 균형을 깨뜨리는 것.
• harness 자체를 임의로 수정하는 것 (CLAUDE.md / hook / settings).
• 사용자가 고삐를 쥐지 못하게 하고 진행 상황을 숨기는 것 (불투명한 진행 상황, 모호한 커밋 메시지).

마지막 두 가지는 저 또한 AI 측에 행동 규율로 부과하고 있습니다. 완료된 변경 사항은 파일 경로와 내용을 한 줄로 명확히 작성하여 프로세스를 관측 가능 (Observable)하게 유지해야 합니다. 고삐를 쥔 인간이 언제든 전체를 볼 수 있도록 말이죠. 이것이 바로 「고삐를 쥘 수 있는 harness」의 필요조건입니다.

🗨️ 「지능 차이가 있는 사람과는 대화가 늘 어긋난다.」 — Snack Bus-e ／ Forbidden Shibukawa (Alu)

(사담) 인간과 AI의 「대화가 어긋나는」 이유는 결국 이 지점에 있습니다. 똑똑한 AI에게 막연하게 명령을 내리면, AI는 똑똑하기 때문에 임의로 내용을 보충하여 의도와는 전혀 다른 곳으로 전력 질주해 버립니다. 그래서 「고삐」와 「순환적 판단 (Loop judgment)」이 필요한 것입니다. 이 밑반찬 이야기를 마치고, 드디어 「바퀴 (Loop)」라는 주제로 들어갑니다.

제1장에서는 「왜 (철학)」를 다루었습니다. 저는 모델 중심의 도식으로 향하는 보조선을 하나 내려놓았습니다. harness는 기술적인 컨테이너인 동시에, 인간이 고삐를 쥐고 AI를 부하처럼 육성하는 장소입니다. 이어지는 제2장에서는 「어떻게 (제어)」로 전환합니다.

제0장에서 저는 이를 「automation은 단계(step)이고, loop는 판단(judgment)이다」라고 정의했습니다 (달걀과 레시피에 관한 이야기). 여기서 한 걸음 더 나아가면, loop engineering이라고 부를 수 있습니다.

순환을 「설계, 운용하고, 전략을 교체하며 비교·개량」하는 엔지니어링입니다.

핵심은 「전략을 교체하며 비교할 수 있어야 한다」는 점에 있습니다. 고정된 단일 루프가 아니라, 루프의 내부(전략)를 react / reflexion / plan_execute_verify와 같이 교체함으로써 「동일한 태스크 하에서 어떤 전략이 더 빠르고 안전하게 수렴하는가」를 실험하는 것입니다. 이것이 바로 automation (고정된 레시피)과의 결정적인 차이입니다.

'루프 내부'에 대응하는 대표적인 전략들을 대략적으로 번역해 보겠습니다.

• ReAct…… 「사고 (Reason)」와 「행동 (Act)」을 교대로 반복합니다.
• Reflexion…… 실패하면 스스로 반성문을 작성하여 다음 시도에 활용합니다.
• Plan-and-Execute (계획 후 실행)…… 먼저 계획을 세운 뒤 순서대로 실행합니다.
• Self-Refine (자기 개선)…… 자신의 출력을 스스로 검토하고 수정합니다.

이것들은 「사고 운용 방식의 유파」입니다. 동일한 목표라도 유파에 따라 도달하는 속도와 헛디딜 확률이 달라집니다. 그래서 「비교를 위한 프레임워크」가 필요한 것입니다.

loop engineering은 단순히 생산성에 관한 주제가 아닙니다. 그것은 안전한 패러다임 전환이기도 합니다.

Filip Verloy 씨는 2026년 6월 Medium 기사 From Prompt Engineering to Loop Engineering: Why the Agent Era Demands a New Security Paradigm에서 날카로운 경고를 던졌습니다.

「네이티브 에이전트 제어 계층(Agent control layer) 없이 자율 순환을 풀어놓는 것은 생산성을 확장하는 것이 아니라, **기계의 속도로 리스크를 확장하는 것 (scaling risk at machine speed)**이다.」

(Medium 기사, 본문 확인 완료)

순환은 매우 빠릅니다. 그렇기에 브레이크를 밟는 방식이 잘못되면, 오류 또한 전력으로 양산됩니다. 그의 처방은 이렇습니다. 정규 표현식이나 ACL 같은 정적 제어로는 부족하며, 에이전트 행동의 의미를 실시간으로 이해하고 제어하는 **Semantic Governance (의미론적 거버넌스)**가 필요합니다 (이는 재작성이 아니라 원문의 주장에 따른 요약입니다).

「기계의 속도로 리스크를 확장한다」는 문장은, 바로 다음에 이어질 이 자체 제작 harness의 설계 동기 그 자체입니다.

저는 llloop (로컬 독립 프로젝트, v0.1.0a0, Apache-2.0)라는 이름의, 자율 순환을 설계 · 실행 · 실험하기 위한 독립적인 harness를 직접 만들었습니다. 이는 2026년 6월 11일에 시작된 Python 프로젝트입니다.

먼저 **솔직한 공개 (honest disclosure)**를 하겠습니다. llloop는 알파 단계(alpha stage, v0.1.0a0, 골격)에 있습니다. 아직 GitHub에 공개되지 않았기 때문에 본문에 공개 저장소 URL을 붙일 수 없습니다 (대신 이미 공개된 RAPTOR 측 링크로 대체합니다). 검증 작업은 현재 green-keeper를 중심으로 이루어지고 있으며, 프로덕션 품질은 아닙니다. 과장 없이 작성하겠습니다.

그 위에 설계된 골격은 다음과 같습니다.

llloop의 중추는 MAPE-K입니다. 이는 자율 컴퓨팅 (autonomic computing)의 고전적인 제어 루프(control loop)로, Monitor (모니터링) → Analyze (분석) → Plan (계획) → Execute (실행), 그리고 이들이 공유하는 **Knowledge (지식, K)**로 구성됩니다. 설계 코드에는 Kephart & Chess의 2003년 자율 컴퓨팅 (autonomic computing) 논문이 인용되었습니다.

구현은 MapeKRunner 클래스이며, 한 주기는 다음과 같은 순서로 폐쇄 루프 (closed loop)를 형성합니다.

Monitor → Analyze → (목표 달성 시 종료) → Plan → 안전 판정 → Execute → 기록 → breaker/budget 판정

내부 루프는 plan-execute-verify 및 Reflexion을 채택하며, 전략은 교체 가능합니다.

MAPE-K는 인간의 체온 조절과 유사합니다.

Monitor (모니터링): 체온계가 "38도임"을 발견합니다. -
Analyze (분석): "평소 체온보다 높으므로 발열 상태임"을 판단합니다. -
Plan (계획): "땀을 흘려 열을 배출하자"라고 결정합니다. -
Execute (실행): 실제로 땀을 흘립니다. -
Knowledge (지식): "평소 체온은 36.5도"라는 기준이 모든 단계에서 공유됩니다. -

자동화 (automation, 레시피)와의 차이점은 명확합니다. 레시피는 "여름이 되면 땀을 흘린다"라고 날짜를 기준으로 고정하지만, MAPE-K는 현재의 체온을 측정하여 판단합니다. 이것이 바로 "내부에서 판단하는 루프"입니다.

이 부분이 llloop에서 제가 가장 말하고 싶은 부분입니다. 루프(loop)는 매우 빠릅니다. 빠른 것에는 반드시 **피할 수 없는 브레이크 (brake)**가 필요합니다. 2-1에서 "의사결정 지점을 갖는 것과 의사결정의 품질을 보장하는 것은 별개의 문제"라고 쓴 적이 있습니다. 그 "품질 보장"을 담당하는 것이 바로 이 안전 계층 (safety layer)입니다.

llloop의 안전 계층 safety.py에 있는 SafetyPolicy.classify는 각 동작을 **ALLOW (허용) / CONFIRM (인간 확인) / FORBID (금지)**의 3단계로 분류하여 판정합니다. 판정 순서는 다음과 같습니다.

FORBID (금지)가 최우선입니다…… rm -rf /, curl | sh (인터넷의 내용을 그대로 shell에 주입하는 행위), --no-verify