PHL 명세 개요

PHL(Parksy Habit Language)은 철학자 박씨의 사유 패턴을 프로토콜로 정의한 명세다. 모든 Generator, MCP, FAB 라우트는 이 명세를 준수해야 한다.

토큰 명세

PHL-Expansion  → 모듈 확장/보강     → RT-β
PHL-Hardening  → 보안/안정성 강화   → RT-γ
PHL-Reverse    → 역방향 검증        → RT-δ
PHL-Produce    → 에피소드 생산      → RT-α
PHL-Theme      → 시즌 주제 설정     → RT-α
PHL-Publish    → 배포               → RT-θ
PHL-Review     → 리뷰/QC            → RT-δ

8단계 실행 사이클

  1. SPEC 로드
  2. Intent 해석
  3. 컨텍스트 수집
  4. MCP 체인 컴파일
  5. 실행
  6. 결과 수집
  7. 포맷
  8. 상태 갱신

PHL-Review가 실제로 하는 일

토큰 표에서 가장 조용한 항목이 PHL-Review(리뷰/QC → RT-δ)다. 생산 토큰(Produce/Theme/Publish)들이 화려하게 산출물을 뽑아내는 동안, Review는 그 산출물이 진짜인지 검증하는 역할만 한다. 실제로 이 역할 분업이 세션 단위로 굳어진 사례가 있다 — 한쪽 에이전트가 생산(구현)을 병렬로 돌리고, 다른 쪽은 오직 검증만 맡아서 "12개 중 8개가 가짜 프로토콜"이라는 최초 감사 오류를 스스로 재검증해 뒤집은 일이다. Review 토큰이 없었다면 그 오류가 그대로 굳어 다음 스프린트의 헛수고로 이어졌을 것이다.

8단계 사이클에서 6번(결과 수집)이 중요한 이유

실행(5단계) 직후 바로 상태 갱신(8단계)으로 넘어가지 않고 굳이 "결과 수집"이라는 중간 단계를 둔 건, 실행 성공과 실행 결과의 품질이 다른 문제이기 때문이다. MCP 서버가 에러 없이 실행됐다고 결과가 맞다는 뜻은 아니다 — football-model MCP가 한때 드라이버 실패를 무음으로 60점 처리했던 사례처럼, "실행됨"과 "정확함" 사이에 조용한 실패가 숨을 수 있다.

PHL-Spec#프로토콜#명세