개인 연구자용 AI 운영체계

개인 연구자인 의뢰인은 스스로 하네스·스킬·MCP를 붙여 봤지만 부품들이 엉키고 결과물이 만족스럽지 않았습니다. 원하는 것은 코칭보다 «대장 AI와만 대화하고, 일은 나눠 맡기고, 결과는 다른 회사 모델이 검토하는» 시스템 구축과 이후 유지보수였습니다.

요구 문서에는 등급 판정, 위임, 작업 기록·인계, 보호 폴더, 회의록·보고서·발표 양식 등 많은 항목이 있었고, 제안 전에 무엇이 실제로 가능한지 확인이 필요했습니다.

• 요구를 설계 원칙 11개로 정리해 1단계 구축 설계서를 쓰고, 설계를 맥에서 프로젝트 설정만으로 끝까지 돌려 보는 데모로 실측했습니다.
• 규칙은 문서보다 코드로 강제한다는 원칙에 따라 스킬 라우터·보호 폴더 가드·작업 기록·인계·컨텍스트 게이트를 훅으로 구현했습니다.
• 되돌리기 비싼 결과는 Codex(다른 회사 모델)가 읽기 전용으로 검토해 PASS/FAIL을 남기도록 했습니다.
• 구현에 참여하지 않은 검수자가 «된다»는 주장을 하나씩 반증하는 독립 검수를 두 차례 진행하고, 결과를 «실측/추정/반증/미시험»으로 표기했습니다.

• 1단계 핵심 구조(규칙 파일 → 등급 판정 → 위임 → 교차 검토, 훅 5종, 스킬 3종, mod 3종)가 맥에서 프로젝트 설정만으로 끝까지 동작하는 것을 확인했습니다.
• 1차 독립 검수에서 반증 3건(가드 우회, 진행 카드가 정적 예시를 그림, 작업 기록 원칙 미충족)을 찾았고, 수정 후 2차 검수에서 진행 카드·작업 기록 문제는 대부분 해소되고 인계문 양식·견본 수치 오류가 고쳐진 것을 확인했습니다.
• 가드는 리터럴 삭제 명령과 보호 설정 수정은 막았지만 같은 계열 변형 29건이 여전히 통과해, 제안에는 «3중으로 막되 완전 차단은 약속하지 않는다»로 적었습니다.
• 훅 단위 시험 23/23, 작업 기록·인계 시험 12/12가 통과했으며, 이 실측을 바탕으로 대면 3회 구축 방식의 1단계 제안을 진행했습니다.

데모는 «된다»를 보여 주는 자리가 아니라 «말하면 안 되는 것»을 찾는 자리로 쓰는 것이 제안의 정확도를 높였습니다. 문자열 검사 기반 가드는 다른 실행 경로·경로 표기 변형 같은 우회를 다 막을 수 없다는 점을 실측으로 확인했고, 그 한계를 제안 문장에 그대로 넣었습니다.

같은 요청도 실행마다 결과가 달라진다는 점(할 일 수, 근거 시각 수, 파일명)을 기록해 두었습니다. 산출물 스킬에는 생성 규칙보다 검사기를 먼저 붙여야 재현성 문제를 다룰 수 있다는 판단을 얻었습니다.