처음에는 AI가 병목이라고 생각했다.
Claude Code나 OpenClaude 같은 도구는 강력하지만, 긴 작업에 들어가면 목표가 흐려지고, 스펙이 사라지고, 안전 검사가 빠지고, 컨텍스트가 넘친다. 그래서 나는 AI를 더 잘 통제하는 하네스가 필요하다고 생각했다.
그게 MFH의 출발점이었다.
문제 1 — AI 실행 병목
AI는 짧은 요청에는 강하다. 하지만 긴 프로젝트에서는 다르다.
- 목표를 잊는다.
- 스펙의 edge case를 놓친다.
- safety check를 제거할 수 있다.
- 컨텍스트가 커질수록 중요한 것이 희미해진다.
- 완료했다고 말하지만 실제로는 검증되지 않았을 수 있다.
그래서 나는 AI의 실행을 외부 구조로 붙잡으려 했다.
MFH — AI가 잊어도 시스템이 붙잡게 하기
MFH는 프롬프트가 아니다. AI에게 “잘해줘”라고 말하는 방식도 아니다.
MFH는 spec, plan, status, state, hook, verification command를 통해 AI 실행 세션이 목표에서 벗어나지 않게 만드는 운영 게이트다.
핵심은 이것이다.
AI가 기억하게 하는 것이 아니라, AI가 잊어도 시스템이 기억하게 한다.
현재 공개 문장에서는 MFH를 partial/internal 상태의 운영 게이트로만 다룬다. 완성된 범용 안전 시스템이라고 주장하지 않는다.
문제 2 — 인간 운영자 병목
그런데 MFH를 만들면서 더 큰 문제가 보였다.
AI만 병목이 아니었다. 인간도 병목이었다.
AI가 계속 묻는다.
- 이 방향이 맞나요?
- 이 기술 선택이 맞나요?
- 이 테스트가 충분한가요?
- 이걸 배포해도 되나요?
- 이 실패는 멈춰야 하나요, 계속해야 하나요?
인간이 모든 기술 판단, 기억, 승인, 검증을 붙잡고 있으면 자동화는 멈춘다.
그래서 질문이 바뀌었다.
AI를 어떻게 더 잘 실행시킬까?
에서
인간이 실행 병목이 되지 않으면서도 판단권을 잃지 않으려면 어떤 운영 체계가 필요한가?
로.
Meta — 인간을 전략 경계에 남기기
Meta는 이 문제에서 나왔다.
Meta는 인간을 제거하는 시스템이 아니다. 인간이 모든 것을 기억하고 결정해야 하는 상태에서 벗어나게 하는 개인 운영체계다.
인간은 taste, product direction, irreversible action, public communication, approval boundary에 남는다.
기술 스택, 반복 검토, 기록, 요약, 원본 보존, decision ledger는 시스템이 맡는다.
Orchestra — 하나의 AI가 아니라 역할이 분리된 AI 조직
그다음 문제는 역할 분리였다.
하나의 AI에게 계획, 실행, 검증, 반박, 승인까지 맡기면 위험하다. 그래서 실행자, 회의론자, shadow reviewer, evidence arbiter, human gate를 분리해야 했다.
이게 Orchestra OS의 방향이다.
현재 만드는 것
지금 만드는 것은 전자동 개발자가 아니다.
내가 만들고 있는 것은 AI-native Operator OS다.
- AI는 실행한다.
- Meta는 운영 기억과 경계를 보존한다.
- Orchestra는 역할을 분리한다.
- MFH는 완료 주장과 drift를 검증한다.
- 인간은 전략과 승인 경계에 남는다.
현재 상태는 planning package + partial implementation + evidence-aware architecture에 가깝다.
결론
프롬프트 엔지니어링은 시작이었다. 컨텍스트 엔지니어링은 다음 단계였다. 하지만 긴 프로젝트에서는 하네스가 필요했고, 하네스 이후에는 인간 운영자 OS가 필요했다.
내가 지금 파고 있는 문제는 단순하다.
AI가 한 일을 인간이 어떻게 믿고 운영할 수 있는가?
이 질문에 대한 내 현재 답이 AI-native Operator OS다.