AI 에이전트
reins의 '턴'이란 무엇인가
reins의 최소 실행 단위인 턴(turn)을 해부한다. 기록되지 않은 것은 턴이 아니다 — 이 정의 하나에서 드라이버 무관성, 재시작 내성, 감사 가능성이 전부 따라 나온다. 2026년 6월의 Loop Engineering 담론과 비교해, 턴이 그 권고들을 어떻게 구조로 바꾸는지 본다.
똑똑한 모델이 설명을 못하는 이유
똑똑한 모델은 말을 어렵게 하고, 쉽게 설명하는 모델은 추론이 약하다. 둘을 나눠 쓰면 된다. Claude Code에서 소통 모델(메인)과 추론 모델(서브에이전트)을 분리 운용하는 구체적 방법과, 그 구조가 작동하는 이유.
abloq — 에이전트가 운용하는 블로그, 검증은 기계가 잠근다
에이전트에게 블로그를 맡기면 글은 나온다. 문제는 믿을 수 없다는 것이다 — 출처를 날조하고, 고치지도 않은 글의 lastmod를 올리고, 시키지 않은 파일을 건드린다. 사람이 전부 검수할 거면 맡긴 의미가 없다. abloq의 답은 분업이다: 생성은 확률적, 검증은 결정론적. 사람이 쓰는 것은 인사이트 명세 한 장(insight.yaml)뿐이고, 집필·번역·갱신·근거 보강은 에이전트가 퀘스트로 대행하며, 품질은 blog.yaml 한 장에서 파생된 결정론적 게이트가 보증한다. 잠긴 PASS는 불가역이다 — 에이전트는 일회용이어도 진행은 누적된다.
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가 그 워크드 예시다.
왜 당신의 에이전트는 멈추지 않는가
에이전트를 24시간 돌린다는 자랑 앞에서 드는 감각은 감탄이 아니라 의문이다 — 왜 아직 안 끝났지? 코드는 탐색 문제가 아니라 제약 충족 문제다. 멈출 수 있는 시스템이 건강한 시스템이다.
'완료'는 누가 정의하는가 — 게임이 40년 먼저 푼 문제
임차인 퇴거 확인을 사진 다섯 장으로 정의하는 순간, 그건 게임 퀘스트가 된다. '완료'를 행위자의 주장이 아니라 기계적으로 검증 가능한 조건으로 정의하는 것 — 게임이 40년 먼저 푼 문제이고, AI 에이전트에게 일을 제대로 시키는 법이다.
filefunc × Hono — 에이전트가 한 번에 읽는 코드를 60줄에서 18줄로
별 23k짜리 실전 프레임워크 Hono를 filefunc으로 리팩토링했다. 테스트 4419개 전부 통과. 그리고 측정해보니 — 에이전트가 개념 하나를 read할 때 읽는 코드가 중앙값 60줄에서 18줄로 71% 줄었다. 파일 개수가 아니라 '읽는 길이'가 핵심이다.
Reins Engineering — 고삐 있는 AI
하네스 엔지니어링은 울타리다. 에이전트가 밖으로 못 나가게 할 뿐, 목적지에 도달하게 하지 않는다. Reins Engineering은 고삐다 — 결정론적 계약으로 방향을 잡고, 래칫으로 잠그고, 결정과 구현을 분리한다.