Reins Engineering
reins의 '턴'이란 무엇인가
reins의 최소 실행 단위인 턴(turn)을 해부한다. 기록되지 않은 것은 턴이 아니다 — 이 정의 하나에서 드라이버 무관성, 재시작 내성, 감사 가능성이 전부 따라 나온다. 2026년 6월의 Loop Engineering 담론과 비교해, 턴이 그 권고들을 어떻게 구조로 바꾸는지 본다.
시스템이 천재를 더 빛나게 한다
구조 없는 천재는 표류하고, 구조만 있으면 평범하다. 천재와 구조가 곱해질 때 비로소 제 값을 한다. Claude Sonnet이 43분에 32 엔드포인트를 완성한 ZenFlow 벤치마크와 B-17, Toyota, WHO 체크리스트가 증명하는 동일 원리.
abloq — 에이전트가 운용하는 블로그, 검증은 기계가 잠근다
에이전트에게 블로그를 맡기면 글은 나온다. 문제는 믿을 수 없다는 것이다 — 출처를 날조하고, 고치지도 않은 글의 lastmod를 올리고, 시키지 않은 파일을 건드린다. 사람이 전부 검수할 거면 맡긴 의미가 없다. abloq의 답은 분업이다: 생성은 확률적, 검증은 결정론적. 사람이 쓰는 것은 인사이트 명세 한 장(insight.yaml)뿐이고, 집필·번역·갱신·근거 보강은 에이전트가 퀘스트로 대행하며, 품질은 blog.yaml 한 장에서 파생된 결정론적 게이트가 보증한다. 잠긴 PASS는 불가역이다 — 에이전트는 일회용이어도 진행은 누적된다.
당신의 에이전트 루프는 왜 발산하는가
Loop Engineering이 보편화될수록 사람들은 같은 벽에 부딪힌다 — 루프가 수렴하지 못하고 발산한다. 무한 회전·드리프트·리워드 해킹, 세 얼굴의 뿌리는 하나다. 루프의 판정 슬롯에 생성자 자신을 다시 꽂은 것. 그런데 발산은 차라리 운이 좋다. 보이니까. 진짜 무서운 건 조용히 거짓 수렴한 루프다. 처방은 하나 — 완료를 잠그는 권한을 LLM이 아니라 결정론적 게이트에만 둔다.
프로덕션 트래픽이 명세다
레거시 코드에는 문서가 없다. 테스트도 없다. 그런데 지금 돌아가고 있다. 잘 기록한 로그 한 달치가 곧 명세다 — 프로덕션 트래픽으로 현재 동작을 캡처한 Hurl 통합 테스트를 만들면, 코드를 한 줄도 안 읽고도 레거시의 기능을 고정하고 리팩토링의 안전망을 깐다.
도시 하나를 태워 답 하나를 얻는다
1조 파라미터 모델이 답 하나를 뱉으려고 도시 하나만큼의 전기와 물을 태운다. 나는 이게 미쳤다고 생각했다. 답을 찾아 헤매다 알았다. 다들 고치려던 결함, LLM의 아첨이야말로 답이었다. fact를 먹이면 아첨이 정확도가 된다. 이 글은 내가 왜 Reins를 시작했는지에 대한 이야기다.
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 에이전트에게 일을 제대로 시키는 법이다.
제 11강. 망한 바이브 코딩 살리는 법
바이브 코딩으로 만든 앱이 터졌다. 새로 만들 필요 없다. 진단하고, 잠그고, 한 걸음씩 빠져나오면 된다.
Supabase는 바이브 코딩의 함정이다
AI가 Supabase를 추천하는 이유는 기술적 우월성이 아니라 훈련 데이터에 튜토리얼이 많아서다. 비즈니스 로직이 블랙박스에 들어가면 에이전트가 추적하지 못한다. 들어가는 건 30초, 나오는 건 3개월.
에이전트가 일할 수 있는 시스템을 만든다는 것
Fortune 500 IT 예산의 60~80%가 잠긴 레거시를 지키는 데 쓰인다. 열지 못하니까. AI 버블의 진짜 의미는 모델이 똑똑해지는 것이 아니라, 기업의 잠긴 기억이 도달 가능한 상태로 바뀌기 시작한다는 것이다.
huma — 엔드포인트 하나도 빠뜨리지 않는 래칫
AI 에이전트에게 42개 엔드포인트의 테스트를 시키면, 15개쯤에서 '다 했습니다'라고 선언한다. huma는 엔드포인트 목록을 래칫 세션으로 바꿔서, 에이전트가 한 개도 빠뜨리지 못하게 만든다. scan → next → write → verify. 네 명령어, 설정 없음.
codistill — 기존 코드에서 SSOT를 짜낸다
yongol을 쓰려면 처음부터 SSOT로 시작해야 하나? 아니다. codistill이 기존 코드에서 OpenAPI, DDL, sqlc 쿼리를 자동 추출한다 — 8개 언어 16개 웹 프레임워크 지원. 기초 공사가 아니라 내진 보강이다.
Agent Operable Codebase
사람이 읽기 좋은 코드와 에이전트가 작업하기 좋은 코드는 같은가? 같지 않다. 파일 하나에 함수 20개가 있으면 에이전트 성능이 30~85% 떨어진다. 사무실을 공장으로 바꿔야 한다.
제 10강. 데이터의 법 — Agent Operable Data
코드는 틀리면 테스트가 잡는다. 데이터는 틀려도 아무도 모른다. 스키마는 내가 세우는 법이다.
제 9강. 코드 너머의 자동화 — Agent Operable System
코드만 agent-operable이면 충분한가? 빌드, 배포, 모니터링까지 에이전트가 운영하는 구조.
제 8강. 에이전트의 공장 — Agent Operable Codebase
파일 하나에 함수 20개 → 에이전트 성능 30~85% 하락. filefunc로 쪼개고 tsma로 테스트한다.
제 7강. 아첨을 뒤집는 법 — 프롬프트와 검증기의 균형
의견을 주면 아첨하고, 사실을 주면 수정한다. 아첨 편향을 버그가 아니라 자산으로 쓰는 법.
제 6강. 통과하면 잠근다 — Ratchet Pattern 원리와 대량 적용
AI가 '다 했습니다'라고 선언했다. 실제로는 40/527. Ratchet Pattern은 완료 판정을 기계에게 넘긴다.
제 5강. 고삐 있는 AI — Reins Engineering 개론
하네스 엔지니어링은 울타리다. Reins Engineering은 고삐다. 모델을 바꾸지 말고 계약을 추가하라.
제 4강. 결정을 코드 밖으로 — yongol과 선언적 풀스택 제어
코드에 섞인 결정과 세부사항을 AI가 구분하지 못하는 것이 드리프트의 근본 원인이다. yongol은 결정을 10개 선언적 명세로 분리하고, 287개 규칙으로 레이어 간 모순을 잡는다.
제 3강. 깨지지 않는 앱 — Hurl, Git, CI/CD
Hurl로 API 계약을 선언하고, Git으로 세이브 포인트를 만들고, CI/CD로 자동 검증한다. 세 도구가 합쳐지면 래칫이 된다 — 앞으로만 가고 뒤로 가지 않는 톱니바퀴.
제 2강. AI를 못 믿는 법 — 바이브 코딩의 한계와 원인
AI가 새 기능을 추가하면서 기존 기능을 조용히 바꿔버리는 드리프트, 58%의 아첨 편향, 97%가 5번 곱해지면 86%가 되는 수학. 왜 5개 기능에서 무너지는가.
제 1강. AI에게 시키는 법 — 바이브 코딩 핵심요약
Claude Code 설치부터 CLAUDE.md 컨텍스트 관리까지. 코드를 모르는 사람이 AI에게 시키는 법.
제 0강. 클로드 코드 설치하기 — 당신이 쓰는 건 클로드 코드가 아닐 수 있다
유튜브가 '클로드 코드'라고 부르는 것의 절반은 클로드 코드가 아니다. 같은 모델이라도 에이전트가 다르면 결과가 다르다. 강 입구를 여기서 막는다.
Reins Engineering — 고삐 있는 AI
하네스 엔지니어링은 울타리다. 에이전트가 밖으로 못 나가게 할 뿐, 목적지에 도달하게 하지 않는다. Reins Engineering은 고삐다 — 결정론적 계약으로 방향을 잡고, 래칫으로 잠그고, 결정과 구현을 분리한다.
Hurl이 바이브 코딩의 드리프트를 막는다
바이브 코딩은 3개월 만에 로직 드리프트로 무너진다. CMU, METR, DORA, Amazon 사례가 이를 증명한다. Hurl로 API 계약을 plain text로 선언하고 래칫으로 잠그면, AI의 자유를 제한하지 않으면서 드리프트를 구조적으로 억제한다.
IFEval을 역이용하는 래칫 코드
LLM의 아첨 편향은 버그가 아니라 자산이다. IFEval이 측정하는 지시 수용 능력을 결정론적 피드백과 결합하면, 4.5B 로컬 모델도 정확한 코드를 생성하는 수렴 루프가 만들어진다.
yongol — AI 코딩 SaaS의 용골
바이브 코딩은 200 엔드포인트에서 무너진다. AI가 결정과 구현을 구별하지 못하기 때문이다. yongol은 AI의 작업 대상을 코드에서 선언적 명세 10종으로 옮기고, 레이어 간 정합성을 컴파일 전에 강제한다. Harness with reins.
AI의 아첨 편향은 비즈니스 피처다
LLM의 아첨 편향은 버그가 아니다. RLHF의 수학적 필연이며, 빅테크가 고칠 인센티브가 없는 상업적 기능이다. 이것이 LLM-as-Judge를 구조적으로 불가능하게 만드는 이유다.
코딩 에이전트는 왜 작동하고 왜 무너지는가
같은 모델이 웹 채팅에서는 hallucinate하고 코딩 에이전트에서는 작동한다. 모델이 달라서가 아니라 topology가 달라서다. 생성은 확률적이어도 된다. 검증은 결정론적이어야 한다.
Ratchet Pattern — 에이전트가 끝까지 가게 만드는 방법
AI 에이전트에게 527개 함수의 테스트를 시켰더니 40개에서 '다 했습니다'라고 선언했다. Ratchet Pattern은 완료 판정을 기계적 verifier로 강제하여 에이전트가 끝까지 가게 만드는 패턴이다.
모델 IQ보다 피드백 토폴로지
같은 모델이 40개에서 멈추기도 하고 527개를 완주하기도 한다. 차이는 모델이 아니라 피드백 구조다. LLM의 성능은 모델 자체보다 얼마나 빠르고 결정론적인 피드백 루프 위에 놓여 있는가에 더 크게 좌우된다.
tsma — 레거시 코드의 회귀 방어선
모든 함수를 인덱싱하고, 테스트 유무를 감지하고, 커버리지를 측정하고, LLM 에이전트에게 피드백을 주는 CLI 도구. 명령어 하나로 레거시 코드에 회귀 방어선을 구축한다.
filefunc — 파일 하나에 개념 하나
AI 코드 에이전트의 탐색 단위는 파일이다. 파일 하나에 개념 하나를 강제하는 Go 코드 구조 컨벤션이자 CLI 도구.