결정론적 검증
reins의 '턴'이란 무엇인가
reins의 최소 실행 단위인 턴(turn)을 해부한다. 기록되지 않은 것은 턴이 아니다 — 이 정의 하나에서 드라이버 무관성, 재시작 내성, 감사 가능성이 전부 따라 나온다. 2026년 6월의 Loop Engineering 담론과 비교해, 턴이 그 권고들을 어떻게 구조로 바꾸는지 본다.
abloq — 에이전트가 운용하는 블로그, 검증은 기계가 잠근다
에이전트에게 블로그를 맡기면 글은 나온다. 문제는 믿을 수 없다는 것이다 — 출처를 날조하고, 고치지도 않은 글의 lastmod를 올리고, 시키지 않은 파일을 건드린다. 사람이 전부 검수할 거면 맡긴 의미가 없다. abloq의 답은 분업이다: 생성은 확률적, 검증은 결정론적. 사람이 쓰는 것은 인사이트 명세 한 장(insight.yaml)뿐이고, 집필·번역·갱신·근거 보강은 에이전트가 퀘스트로 대행하며, 품질은 blog.yaml 한 장에서 파생된 결정론적 게이트가 보증한다. 잠긴 PASS는 불가역이다 — 에이전트는 일회용이어도 진행은 누적된다.
당신의 에이전트 루프는 왜 발산하는가
Loop Engineering이 보편화될수록 사람들은 같은 벽에 부딪힌다 — 루프가 수렴하지 못하고 발산한다. 무한 회전·드리프트·리워드 해킹, 세 얼굴의 뿌리는 하나다. 루프의 판정 슬롯에 생성자 자신을 다시 꽂은 것. 그런데 발산은 차라리 운이 좋다. 보이니까. 진짜 무서운 건 조용히 거짓 수렴한 루프다. 처방은 하나 — 완료를 잠그는 권한을 LLM이 아니라 결정론적 게이트에만 둔다.
프로덕션 트래픽이 명세다
레거시 코드에는 문서가 없다. 테스트도 없다. 그런데 지금 돌아가고 있다. 잘 기록한 로그 한 달치가 곧 명세다 — 프로덕션 트래픽으로 현재 동작을 캡처한 Hurl 통합 테스트를 만들면, 코드를 한 줄도 안 읽고도 레거시의 기능을 고정하고 리팩토링의 안전망을 깐다.
reins — 퀘스트 CLI에서 도메인만 남기고, 래칫은 프레임워크로
how-make-quest는 퀘스트 CLI를 맨손으로 짓는 법을 가르쳤다. 그런데 두 번째 CLI를 지으면 같은 래칫, 같은 scan/next/submit, 같은 집계를 또 짠다. reins는 그 불변을 프레임워크로 뽑아낸다 — 래칫·명령 골격·집계·export는 reins가 공급하고, 당신은 도메인의 게이트(gate.Definition 4메서드)만 구현한다. 게이트는 치즈 방어 규칙의 카탈로그고, toulmin defeat 그래프가 '왜 졌고 뭘 바꾸면 이긴다'는 공략집을 에이전트에게 돌려준다.
고삐를 쥐여준 도구엔 정작 고삐가 없었다 — 하네스와 레인스의 경계
"Reins Engineering, 결국 하네스 아니에요?" 둘은 대립하지 않는다 — 같은 마구의 다른 부품이다. 하지만 다른 부품이다. 세계 최고의 코딩 에이전트조차 자기 코드엔 고삐를 걸지 않았다. 레인스는 가지는 게 아니라 거는 것이기 때문이다.
퀘스트 CLI 만드는 법 — 완료를 기계가 판정하게 만드는 도구를 직접 짓기
AI는 '다 했습니다'라고 말한다. 실제로는 안 끝났다. 이 글은 그 문제를 푸는 도구 — 퀘스트 CLI — 를 직접 짓는 법이다. 원리(왜)부터 cobra 명령 스켈레톤(어떻게)까지, 이 글 하나로 에이전트가 Go 퀘스트 CLI를 만들 수 있게 한다. huma가 그 워크드 예시다.
LLM 멀티 에이전트 정확도 향상의 전제조건
에이전트를 여러 개 돌리면 정확해진다? 절반만 맞다. 같은 데이터로 학습한 모델들은 같은 곳에서 틀린다. 멀티 에이전트가 작동하는 조건은 둘 — 오류 독립성을 설계하거나, 검증 가능한 도메인에서 LLM 바깥에 검증기를 세우거나.
왜 당신의 에이전트는 멈추지 않는가
에이전트를 24시간 돌린다는 자랑 앞에서 드는 감각은 감탄이 아니라 의문이다 — 왜 아직 안 끝났지? 코드는 탐색 문제가 아니라 제약 충족 문제다. 멈출 수 있는 시스템이 건강한 시스템이다.
아름다움에 관하여
아름다운 것의 70%는 수학이다. 질서를 기계가 결정론적으로 잠그고, 복잡성 30%만 사람이 결정한다. Reins Engineering은 AI 코딩 도구가 아니라 — 질서를 잠그고 복잡성만 사람에게 남기는 원리다.
'완료'는 누가 정의하는가 — 게임이 40년 먼저 푼 문제
임차인 퇴거 확인을 사진 다섯 장으로 정의하는 순간, 그건 게임 퀘스트가 된다. '완료'를 행위자의 주장이 아니라 기계적으로 검증 가능한 조건으로 정의하는 것 — 게임이 40년 먼저 푼 문제이고, AI 에이전트에게 일을 제대로 시키는 법이다.
선례는 정답이 아니다 — AI가 땜질을 베껴 권위를 만드는 법
AI는 코드의 구조는 읽지만 그게 결정인지 땜질인지는 못 읽는다. 그래서 복제할수록 결함이 거짓 권위를 얻는다. 이 루프를 끊은 건 더 큰 모델이 아니라 사람의 한 줄 반문이었다.
Agent Operable Codebase
사람이 읽기 좋은 코드와 에이전트가 작업하기 좋은 코드는 같은가? 같지 않다. 파일 하나에 함수 20개가 있으면 에이전트 성능이 30~85% 떨어진다. 사무실을 공장으로 바꿔야 한다.
제 5강. 고삐 있는 AI — Reins Engineering 개론
하네스 엔지니어링은 울타리다. Reins Engineering은 고삐다. 모델을 바꾸지 말고 계약을 추가하라.
Reins Engineering — 고삐 있는 AI
하네스 엔지니어링은 울타리다. 에이전트가 밖으로 못 나가게 할 뿐, 목적지에 도달하게 하지 않는다. Reins Engineering은 고삐다 — 결정론적 계약으로 방향을 잡고, 래칫으로 잠그고, 결정과 구현을 분리한다.
Hurl이 바이브 코딩의 드리프트를 막는다
바이브 코딩은 3개월 만에 로직 드리프트로 무너진다. CMU, METR, DORA, Amazon 사례가 이를 증명한다. Hurl로 API 계약을 plain text로 선언하고 래칫으로 잠그면, AI의 자유를 제한하지 않으면서 드리프트를 구조적으로 억제한다.
IFEval을 역이용하는 래칫 코드
LLM의 아첨 편향은 버그가 아니라 자산이다. IFEval이 측정하는 지시 수용 능력을 결정론적 피드백과 결합하면, 4.5B 로컬 모델도 정확한 코드를 생성하는 수렴 루프가 만들어진다.
AI의 아첨 편향은 비즈니스 피처다
LLM의 아첨 편향은 버그가 아니다. RLHF의 수학적 필연이며, 빅테크가 고칠 인센티브가 없는 상업적 기능이다. 이것이 LLM-as-Judge를 구조적으로 불가능하게 만드는 이유다.
코딩 에이전트는 왜 작동하고 왜 무너지는가
같은 모델이 웹 채팅에서는 hallucinate하고 코딩 에이전트에서는 작동한다. 모델이 달라서가 아니라 topology가 달라서다. 생성은 확률적이어도 된다. 검증은 결정론적이어야 한다.