이 글을 쓸 준비를 하면서, 나는 정말 사용하고 싶어 견딜 수 없는 숫자 하나를 만났습니다.

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

도입부로서 완벽합니다. 이제부터 이야기할 '하네스(Harness, 그릇)'의 위력을 단번에 보여줄 수 있으니까요. 그런데 1차 정보를 찾아보니, 그 숫자는 근거 불명이었습니다. 논문은 실재하지만, 인용된 저자명도 '10배'라는 숫자도 그 논문에는 존재하지 않았습니다. 그래서 나는 이 숫자를 버렸습니다.

왜 이런 부정적인 이야기부터 시작하는 걸까요. 그것은 이 '버리는' 작법이야말로, 본 기사를 통해 내가 가장 전달하고 싶은 것이기 때문입니다.

이상할 정도로 매력적인 숫자를 보았다면, 승리했다고 느끼기 전에 반드시 내역을 의심할 것. 1차 정보에 닻을 내릴 것.

똑똑한 AI는 모르는 것조차 유창하게 말해버립니다. 대충 부탁하면, 똑똑하기 때문에 알아서 보완하여 우리의 의도와 어긋난 곳으로 전력을 다해 달려가 버립니다. 그렇기에 인간 측에서 "이곳은 미검증 상태다"라고 선을 긋는 눈이 필요합니다. 이 글은 그 눈을 가진 인간이, 2026년 AI 엔지니어링의 '다음 이름'을 땅에 발을 붙이고 검증해 나가는 이야기입니다.

(버린 숫자에 대한 자세한 검증은 제2장 이후의 독립된 절에서 모두 공개하겠습니다. 먼저 작법을 약속하고 싶었기에 결론만 서두에 두었습니다.)

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

2025년, AI 업계의 구호는 prompt engineering (프롬프트 엔지니어링) —— "LLM에 어떻게 부탁할 것인가"를 연마하는 기술이었습니다. 이윽고 그것은 context engineering (컨텍스트 엔지니어링) —— "LLM에게 무엇을 보여줄 것인가"를 설계하는 기술 ——로 확장됩니다.

그리고 2026년, 업계는 여기에 두 가지 이름을 더 붙였습니다.

harness engineering (하네스 엔지니어링)… LLM을 감싸는 '결정론적인 런타임 계층 (deterministic runtime layer)'을 설계하는 기술.

loop engineering (루프 엔지니어링)… 에이전트를 '자율적으로 돌아가는 루프'로 설계하는 기술.

여기서 "발명한 것은 AI가 아니라 인간(업계)이다"라고 미리 밝혀둡니다. 제목에 "AI가 발명했다"라고 쓰고 싶어지는 의인화는 사실을 왜곡합니다. 이름을 붙인 것은 이제부터 소개할 인간 엔지니어들입니다.

이 글의 컨셉은 다음과 같습니다.

업계가 명명한 이 두 가지를 나는 개념 증명(PoC) 수준으로 수중에(로컬에) 두고 있다. 다만, 나의 설계도에는 업계의 모델 중심 해설도에는 잘 나타나지 않는 "또 다른 하나의 축"이 있다.

그 축이란, 고삐를 계속 쥐고 있는 인간과 부하처럼 길러지는 AI입니다. 본 기사에서는 (A) 하네스, (B) 루프, (C) 그것을 지탱하는 지식 기반이라는 3가지 테마를, 내가 실제로 구동하고 있는 구현 —— RAPTOR (보안 에이전트), llloop (자작 루프 하네스 · alpha), RAD 코퍼스 + LLM Wiki (자체 연구 지식) ——로 검증합니다.

긴 글입니다 (약 2만 자, 20분 코스). 곳곳에 풀어쓰기 (용어의 쉬운 설명), 한담 (휴식), honest disclosure (정직한 내역 공개) 를 배치하겠습니다. 지치면 장의 구분에서 잠시 숨을 돌려주세요.

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

prompt engineering… 1회의 지시문을 연마한다.

context engineering… LLM의 시야 (컨텍스트 윈도우)에 무엇을 실을지를 설계한다.

harness engineering… LLM의 "외부 그릇"을 설계한다. 도구 호출, 권한, 실행, 결과 피드백을 담당하는 계층.

loop engineering… 그 그릇을 "자율적으로 돌아가는 루프"로 설계한다.

↑ 단계를 올라갈수록 "LLM의 외부"를 설계한다. 2025년의 prompt / context (무엇을 부탁할지 · 무엇을 보여줄지)에서, 2026년의 harness (외부의 그릇) / loop (자율적인 고리)로. 본 기사는 이보다 2단계 위 단계의 이야기.

어느 해설 미디어는 이를 "제4의 패러다임"이라 부르며, LangChain (에이전트 개발 라이브러리)은 Agent = Model + Harness (에이전트 = 모델 + 하네스) 라고 요약하고 있습니다 (augmentcode.com의 해설을 통해 확인했습니다.

2차 정보. (1차 출처인 LangChain 원문은 본고에서 확보하지 못했으므로 헤징(hedging)합니다. 이후 이 식을 재게재할 때도 「2차」라고 표기합니다).

**harness (하네스)**는 본래 '마구(馬具)'나 '(아기나 암벽 등반가를 안전하게 연결하는) 안전벨트'를 뜻하는 영어입니다.

LLM은 굉장히 똑똑하지만, 그대로 두면 날뛰거나 엉뚱한 방향으로 달려가거나, 때로는 발밑에 땅이 없는 곳으로 발을 내디딜 수도 있는 '힘이 센 말'과 같습니다. 그 말에게 **마구 (harness)**를 채우는 것 —— 어디로 갈 수 있는지, 어떤 도구를 사용할 수 있는지, 결과를 어떻게 가져올지를 마구 측에서 딱 정해두는 것. 이것이 harness engineering입니다.

마구 비유는 편리하지만, 어디서 한계가 있는지도 말씀드리겠습니다. 진짜 마구는 '물리적으로 움직임을 구속'할 뿐이지만, LLM의 하네스는 '구속'할 뿐만 아니라 '결과를 정형화하여 말의 눈앞에 다시 제시하는' 역할도 가집니다. 마구에 '다음은 여기를 봐'라고 풍경을 보여주는 기능이 달려 있다고 생각하십시오. 거기까지 포함하면 비유가 다소 답답해질 수 있습니다.

이 지점이 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단계 반복으로 묘사하며, 루프가 성립하려면 「트리거 (trigger, 계기)」와 「검증 가능한 목표 (verifiable goal)」 두 가지가 필요하다고 합니다.

「검증 가능한 목표」라는 말을 기억해 두십시오. 후반부에서 Claude Code의 /goal 명령어와 제가 직접 만든 하네스의 안전 계층에 그대로 적용됩니다.

loop engineering 주변의 출처(Data Science Dojo, Medium 기사, 각종 블로그)는 동료 검토(peer review)를 거친 논문이 아닌 실무 블로그입니다. 정의(automation vs loop, P-R-P-A-O)는 여러 소스에서 일치하므로 「2026년에 실무에서 유통된 용어」로 취급합니다. 「권위 있는 학술적 정의」는 아니라는 온도감을 유지합니다.

이 부분은 시계열이 중요하므로 1차 정보를 찾아보았습니다.

Mitchell Hashimoto 씨(HashiCorp 공동 창업자, Terraform 공동 개발자)가 2026년 2월 5일의 블로그 기사 My AI Adoption Journey에서 이 명칭을 제시했습니다. 중요한 것은 본인의 표현 방식입니다.

「
이 분야에 널리 받아들여진 용어가 있는지는 모르겠지만, 나는 이것을 harness engineering이라고 부르기 시작했다.
」

(mitchellh.com/writing/my-ai-adoption-journey, 2026-02-05, 본문 직접 확인)

즉, Hashimoto 씨는 "내가 발명했다"라고 말하지 않았습니다. "널리 받아들여진 용어가 있는지는 모르겠지만, 나는 이렇게 부르고 있다"라며 신중하게 헤징(hedging)하고 있습니다. 따라서 본 기사도 "2026년 2월경 업계에서 이름이 붙여지기 시작한 호칭" 정도로 제한하겠습니다.

그가 역설하는 harness engineering (하네스 엔지니어링)의 핵심 원칙은 장인 정신처럼 구체적입니다.

"

에이전트가 실수를 하는 것을 발견하면, 그때마다 시간을 들여 에이전트가 두 번 다시 그 실수를 하지 않도록 해결책을 엔지니어링한다."

(해당 기사, 원문 확인)

그 후, 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."라는 문구는 모두 2차 정보(augmentcode / latent.space / zenml의 일치 내용)에 기반한 것입니다. 본 기사에서 이 태그라인을 재인용하는 곳에는 매번 "(2차 정보)"라고 덧붙이겠습니다. "100만 행·1500 PR·하루 10억 토큰"과 같은 실험 규모의 수치는 2차 정보일 뿐 1차 확인이 되지 않았으므로, 본문의 논증 자료로는 사용하지 않고 여기서 "~라고 보도되었다"라고 언급하는 데 그치겠습니다.

시계열을 정리해 두겠습니다. Andrej Karpathy 씨(OpenAI 공동 창업자, Tesla 전 AI 책임자)가 2025년 2월 2일 트윗으로 퍼뜨린 **"vibe coding"**이라는 용어가 있습니다(원문 트윗, URL·날짜 확인 완료). "AI에게 맡겨서, 분위기(vibe)로 코드를 작성하는" 스타일입니다.

이는 harness engineering(2026-02경 업계 용어화)보다 선행합니다. 두 가지는 별개의 계통을 가진 개념입니다. 후반부에 저 자신의 표현이 나오지만, 그것과 "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의 2층 구조는 설계자가 "harness engineering"이라는 업계 용어를 의식해서 작성한 것이 아닙니다. 제가 사후적으로 덧씌운 해석입니다(즉, 관찰자 효과를 포함합니다). 그럼에도 대응은 놀라울 정도로 자연스럽습니다. RAPTOR의 README는 스스로를 "2층 아키텍처"라고 명시하고 있습니다.

"

RAPTOR is two layers. (RAPTOR는 두 개의 층으로 구성된다)"

Python 실행층 (raptor.py, packages/, core/, engine/...

）는 무거운 처리를 담당한다. Semgrep과 CodeQL을 실행하고, 서브프로세스 (subprocess)를 관리하며, 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 실행층)가 스키마 검증·권한·실행·결과 주입을 담당하고, 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이다.

예를 들어, 개찰구가 고장 났을 때:

• fail-open: 고장 나면 열린 상태 유지 (사람은 통과할 수 있지만, 부정 승차도 허용됨).
• fail-closed: 고장 나면 닫힌 상태 유지 (아무도 통과할 수 없지만, 부정 승차도 막을 수 있음).

이 비유가 어디서 어긋나는지도 덧붙인다. 개찰구라면 "통과하지 못하는 사람"의 불편은 일시적이지만, AI 에이전트의 fail-closed는 "안전하지만, 때로는 정당한 조작까지 막아버리는" 비용을 수반한다. 그 균형을 누가 맞출 것인가——후술할 "인간 확인 (CONFIRM)"이 그 완충재 역할을 한다.

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

• untrusted (신뢰할 수 없는) 리포지토리를 스캔할 때, RaptorConfig.get_safe_env()가 TERMINAL / EDITOR / VISUAL / BROWSER / PAGER와 같이 "셸(shell)이 평가할 가능성이 있는 환경 변수"를 제거하며, 파일 경로는 셸 문자열에 삽입하지 않고 **리스트 인자 (list arguments)**로 전달한다 (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를 던져 실행을 중단시킨다.

여기까지는 업계의 harness engineering과 그 실체(RAPTOR)에 관한 이야기였습니다. 이제부터는 저만의 관점을 덧붙이고자 합니다.

업계의 정의는 "Humans steer. Agents execute." (인간이 조종하고, 에이전트가 실행한다 / 이차 정보) 였습니다. 저는 이에 전적으로 동의합니다. 오히려 이는 이미 존재하는 인간 중심의 선례입니다. Hashimoto 씨도 OpenAI도 인간이 조종한다는 점을 명시하고 있습니다. 따라서 저는 "업계가 인간의 역할을 묘사하지 않고 있다"라고 말하지 않겠습니다. 그것은 전수 조사가 결여된 과장입니다.

정확히 말하자면 이렇습니다. 업계의 해설 기사들은 "harness = 모델을 둘러싼 기술적인 그릇"이라는 모델 중심의 도식을 많이 사용합니다. "인간이 조종한다"는 방향성은 제시되지만, 그 인간이 구체적으로 무엇을 하며, AI를 어떻게 "육성"하는가에 대한 세밀한 수준(granularity)까지는 깊이 파고들지 않습니다. 제가 추가하고 싶은 것이 바로 그 세밀함입니다.

harness는 "그릇"인 동시에, "인간이 고삐를 계속 쥐고 있는 장소"이며, "AI를 부하 직원처럼 육성하는 장소"이기도 합니다.

저는 이것을 스스로 **harness형 바이브 코딩 (harness-style vibe coding)**이라 부르고 있습니다. 2026년 5월, 저의 작업 스타일을 언어화했을 때 나온, 업계 용어를 보조선으로서 활용한 표현입니다.

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

• harness engineering이라는 업계 용어(2026-02경, Hashimoto 씨의 1차 기사에서 날짜 확인 완료)는 저의 이 표현(2026-05)보다 선행하고 있습니다.
• 애초에 Hashimoto 씨 스스로도 "널리 받아들여진 용어가 있는지 모르겠다"라고 말할 정도이기에, 누가 "최초"인지 단정할 수 있는 상황이 아닙니다.

따라서 본 기사에서 저의 입장은, "Karpathy 씨의 "vibe coding"(2025-02, AI에게 전적으로 맡김)과는 명확히 구분되는, 인간 중심의 운영 스타일을 나는 이렇게 부르고 있다" 입니다. "vibe coding"이 "AI에게 맡겨서 분위기로" 하는 것이라면, 저의 스타일은 "harness를 능동적으로 계속 쥐고, AI를 부하 직원으로서 키워가며 사용하는 것"입니다.

이후에는 조어(造語) 자체를 전면에 내세우지 않고, 기능(고삐를 쥐는 인간 / 부하 육성) 관점에서 이야기하겠습니다.

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

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

세 번째인 "알고리즘 이해"가 특히 중요합니다. 흔히들 말하듯 AI는 유창하게 틀립니다. 유창한 오류를 간파하려면 우리에게는 계산량을 추정할 수 있는 눈이 필요합니다. 이것은 새로운 통찰이 아닙니다. 제가 말하고자 하는 것은 일반론의 재확인이 아니라 운영상의 구체적인 사례입니다. 예를 들어 위에서 언급한 "단발 0.8배 / 배치 12.7배"라는 한 달 전의 자체 측정 결과처럼 말입니다. AI는 "배치로 실행하면 12배 빠르다"라고만 보고하기 쉽지만, 단발 실행 시에는 느려지고 있다는 불편한 내역을 놓치지 않기 위해서는 계산량을 보는 눈이 필요하다는 이야기입니다.

이 부분이 제 관점에서 가장 강조하고 싶은 점입니다. AI를 사용하는 것은 부하 직원을 육성하는 것과 놀라울 정도로 닮아 있습니다. 대응표를 만들면 다음과 같습니다.

여기서 중요한 유보 사항이 하나 있습니다. 이 대응표는 "비유가 잘 들어맞는다"는 것을 보여주는 것이지, 그 자체로 "인간이 AI보다 우월하다"는 증명이 아닙니다. 인간 매니지먼트 서적이 그대로 AI 팀에 읽힐 수 있다는 것은 메타포(metaphor)의 유효성이지, 우월성의 근거가 아닙니다. 우월성의 논거는 본 장이 아니라 제3장 끝의 3가지 포인트(병렬성 / 장기 사정 / 위험 예측)로 일원화하겠습니다. 여기서는 "기르는 구조를 전용(transfer)할 수 있다"라고만 주장합니다.

왜 전용이 효과적인가? 이유는 4가지로 정리할 수 있습니다.

• AI는 문맥 손실(context loss)이 빠르다 → 확인을 기다리는 비용이, 다소 어긋나더라도 진행하는 가치보다 크다.
• AI는 재작업 비용이 싸다 → 자율적으로 실수해도 즉시 수정할 수 있다. 재구축 비용이 낮다.
• AI는 쉬지 않는다 → 인간의 확인을 기다리는 것이 최대의 병목(bottleneck)이다.
• AI는 설명할 수 있다 → 왜 그렇게 판단했는지를 나중에 감사 로그(audit log)로 추적할 수 있다.

또한, 이 발상에는 계보가 있습니다. Marcus Buckingham 씨 & Curt Coffman 씨의 명저 First, Break All the Rules (원저 1999년, 미국 Gallup사의 대규모 조사를 바탕으로 한 매니지먼트 서적)가 설파하는 "개성을 살리는 매니지먼트"를 인간이 아닌 AI 팀에 전사(transcription)한 것입니다 (일본어판 제목 · 간행 연도 · 4대 원칙의 요약은 메모된 값에 기초하므로, 원저의 해당 부분을 재확인하는 것이 바람직하며, 여기서는 유보합니다). 그들의 4대 원칙——(1) 재능으로 뽑아라 (2) 올바른 결과를 정의하라 (3) 강점에 집중시켜라 (4) 적재적소에 배치하라——는 거의 그대로 "인간 → AI 팀"의 매니지먼트로 전용할 수 있다고 저는 느낍니다.

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

(또 하나, 캐논의 "삼자 정신(자발·자치·자립)"을 AI에 대입하여 정리한 내용도 가지고 있습니다만, 이는 출처가 사내에서 구전되는 훈계라 1차 확인이 되지 않았기에, 본 기사에서는 각주 정도로 이름만 언급하고 논증의 기둥은 First, Break All the Rules 측에 두겠습니다.)

• "하네스형 바이브 코딩(harness-style vibe coding)"이 저의 조어인지 여부는 외부 검색으로 확정하지 않았습니다. 따라서 "명명했다 / 세계 최초"라고 쓰지 않고 "나는 이렇게 부르고 있다"라고만 남겨둡니다.
• "약 0.8배 → 약 12.7배" 등의 수치는 약 1개월 전 시점의 기록이며, 최신 코드에서의 재검증은 하지 않았습니다. 숫자 자체보다 "이런 불편한 내역을 꿰뚫어 보는 눈이 필요하다"라는 논점으로 읽어주시기 바랍니다.

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

• 사용자의 직관을 "데이터가 없다"며 기각하는 것.
• 경험칙을 "우선 선행 연구를 봅시다"로 대체하는 것.
• 알고리즘 논의를 추상론으로 회피하는 것.
• AI를 "도구" 취급하며 육성하지 않고, 매번 제로 베이스에서 시키는 것.
• 너무 엄격하거나 너무 관대하여 균형을 깨뜨리는 것.
• harness 그 자체(CLAUDE.md / hook / settings)를 마음대로 바꾸는 것.
• 사용자가 고삐를 쥘 수 없도록 진척을 숨기는 것 (불투명한 진척, 모호한 커밋 메시지).

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

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

（잠깐의 잡담）인간과 AI 간의 '대화가 맞지 않는 것' 역시 결국 여기에 달려 있습니다. 똑똑한 AI에게 아무렇게나 의존하면, 똑똑하기 때문에 스스로 보완하며 의도와 어긋난 곳으로 전력 질주하게 됩니다. 그래서 '고삐(harness)'와 '루프 판단(loop judgment)'이 필요합니다. 이 잠깐의 잡담을 끝내고, 드디어 '고리(loop)'에 대한 이야기로 넘어가겠습니다.

제1장에서는 '왜(철학)'였습니다. harness는 기술적인 도구인 동시에, 인간이 고삐를 잡고 AI를 부하 직원으로 키우는 장소라는 모델 중심의 다이어그램에 보조선을 그었습니다. 다음 제2장은 '어떻게(제어)'로 넘어갑니다.

제0장에서 'automation은 절차(procedure)이고, loop는 판단(judgment)'이라고 정의했습니다 (달걀과 레시피 이야기). 한 단계 더 나아가면, loop engineering은 다음과 같이 말할 수 있습니다.

루프를 '설계하고, 돌리고, 전략을 교체하여 비교 및 개선하는' 공학입니다.

핵심은 '전략을 교체하며 비교할 수 있다'는 것입니다. 고정된 1개의 루프가 아니라, 루프의 내용물(전략)을 react / reflexion / plan_execute_verify 와 같이 바꿔 끼우면서, '같은 태스크에서 어떤 전략이 더 빠르고 안전하게 수렴하는지'를 실험합니다. 이것이 automation (고정된 레시피)과의 결정적인 차이입니다.

루프의 '내용물'에 해당하는 대표적인 전략들을 대략적으로 번역해 드리겠습니다.