BRIEFING 03

PHL × OrbitPrompt × GitHub × Claude Code

목적: "말버릇(PHL)"을 프로토콜(Protocol)로 물성화하여, Claude Code가 GitHub 레포에서 정의를 읽고 상태 전이 기반으로 코드를 구현/검증/커밋하는 폐쇄 루프 시스템 구축.
Final Whitepaper / Implementation Spec / Defense PackClaude CodeGitHub 레포OrbitPrompt프로토콜 설계
Final Whitepaper / Implementation Spec / Defense Pack
목차 · 뭘 말하는가
클립 2편 (탭하면 소리)
백서 전문

Closed-Loop Cognitive OS (Protocol-First)

Final Whitepaper / Implementation Spec / Defense Pack 버전: Final v1.0 (2026-02-28)

목적: "말버릇(PHL)"을 프로토콜(Protocol)로 물성화하여, Claude Code가 GitHub 레포에서 정의를 읽고 상태 전이 기반으로 코드를 구현/검증/커밋하는 폐쇄 루프 시스템 구축.

0) 한 줄 정의

구성요소역할
PHLMeaning DSL (말 기반 프로토콜)
Claude CodeState Transition Engine
GitHub 레포State Store (영구 메모리)
OrbitPromptPHL → 실행 단위(Prompt Atom) 변환 Runtime
핵심: 이건 "프롬프트 모음집"이 아니라 프로토콜 설계다. 단축키/스니펫이 아니라 상태 전이(state transition) 기반 운영체제(OS) 레벨 인터페이스다.

1) 왜 이게 필요한가 (문제 정의)

1.1 설명 비용(Explanation Cost)이 협업 병목이다

1.2 컨텍스트 윈도우는 구조적으로 부족하다

아무리 컨텍스트가 길어도:

를 매번 대화로 실어 나르면 토큰이 붕괴한다.

1.3 "도구 사용"이 아니라 "프로토콜 호출"이 되어야 한다

결국 원하는 건 이거다:

  1. 한 단어(토큰) 로
  2. 정의된 수백 줄 규칙을 호출하고
  3. Claude가 레포를 읽어 맥락 기반으로 판단/수행하고
  4. 결과를 git commit으로 상태 확정하는 것

2) 핵심 아이디어 (아키텍처 골자)

2.1 Semantic Compression Interface

2.2 Externalized System Prompt (GitHub as Ruleset)

레포는 단순 저장소가 아니라 외부화된 시스템 프롬프트 역할을 한다.

2.3 Stateful Command Model (Snippet과의 차이)

스니펫은 텍스트 확장이다:

PHL은 상태 전이다:

3) 시스템 구성요소 정의

3.1 PHL (Meaning DSL / Protocol Tokens)

PHL은 "자연어"가 아니라 프로토콜 토큰 집합이다.

PHL 토큰은 다음을 포함한다:

PHL은 "짧은 말"로 호출되지만, 실제 정의는 레포에 엄격(Strict) 하게 존재해야 한다.

3.2 OrbitPrompt (Execution Runtime / Prompt Atom)

OrbitPrompt는 아래를 담당한다:

구현상 OrbitPrompt가 별도 코드일 수도 있고, PHL_SPEC 내 규칙으로 흡수될 수도 있다. 중요한 건 "PHL → 실행 단위로 쪼개는 규칙"이 존재해야 한다는 점.

3.3 Claude Code (State Transition Engine)

Claude Code는 CPU가 아니라 컨트롤러다.

  1. 레포를 읽고 (현재 상태)
  2. PHL 규칙으로 해석하고 (전이 규칙)
  3. 수정/테스트/문서/리팩토링을 수행하고 (상태 변화)
  4. 커밋으로 상태를 확정한다 (State commit)

3.4 GitHub Repo (State Store / Cognitive Version Control)

레포는 "코드 저장소"를 넘어:

git commit history = 사고/규칙/구현의 버전 관리다.

4) 폐쇄 루프 동작 모델 (Closed Loop)

4.1 실행 사이클 (필수)

1. 사용자 입력    → PHL 토큰으로 명령
2. Claude Code   → 레포에서 PHL_SPEC 및 관련 정의 로드
3. 상태 점검     → 파일 구조/테스트/로그/CI/의존성 확인
4. 실행          → 변경 수행
5. 검증          → 테스트/린트/타입체크/빌드
6. 산출          → 코드/문서/CHANGELOG 업데이트
7. 커밋          → 메시지 규칙에 따라 commit
8. 상태 갱신     → 다음 작업을 위한 기준점 확정

4.2 상태 전이 원칙 (필수)

5) "가능하다"의 기술적 근거 (방어 논리)

5.1 "기술적으로 100% 가능"의 의미

여기서 100%는 "마법처럼 자동"이 아니라:

이 4가지가 현실적으로 구현 가능하다는 뜻.

5.2 "Claude가 항상 PHL_SPEC 먼저 읽나?" 반박 대비

환경에 따라 자동 로드는 보장되지 않는다. 따라서 운영 규칙으로 강제한다.

5.3 "단어 하나로 수만 토큰 로드" 반박 대비

과장 표현이다. 실제는: 파일 검색 → 관련 정의 로드/요약 → 실행 이 과정을 거친다. 하지만 핵심은 "대화 토큰이 아니라 파일 시스템으로 컨텍스트를 외부화한다"는 점이다.

5.4 "환각이 줄어드나?" 방어 논리

완전 제거는 불가. 다만 아래 조건을 만족하면 크게 줄어든다:

  1. PHL 정의를 레포의 단일 진실원천(SSOT) 으로 둔다
  2. 실행 전/후 검증을 강제한다
  3. 출력 형식을 표준화한다 (계획/변경/검증/커밋)
  4. 불확실하면 "질문"을 의무화한다 (Ask policy)

6) 핵심 병목 (Critical Path) — PHL Interpreter Spec

이 시스템이 무너지느냐 살아남느냐는 딱 하나다: PHL 인터프리터 규칙이 엄격하게 정의되어 있는가?

PHL이 느슨하면:

7) 레포 구조 제안 (Claude가 읽기 쉽게)

권장 루트 구조

/PHL_SPEC.md                 # 최상위 규칙(SSOT)
/PHL_INDEX.json              # 토큰 → 정의 파일 매핑(빠른 탐색)
/phl-spec/tokens/PHL-Expansion.md # 토큰 정의들(하나당 1파일 권장)
/phl-spec/tokens/PHL-Hardening.md
/phl-spec/tokens/PHL-Reverse.md
/phl-spec/contracts/              # 프로젝트 공통 계약(에러/로그/테스트/보안)
/phl-spec/playbooks/              # 실행 플레이북(단계별 체크리스트)
/orbitprompt/                # (선택) Prompt Atom 생성 규칙/템플릿
/reflection/                 # 로그, 회고, 실패 기록, 사례
/CHANGELOG.md

원칙

8) PHL 토큰 스펙 템플릿 (엄격형)

각 토큰은 아래 스키마를 따른다:

8.1 Token Spec Template

Name:              PHL-XXXX
Intent:            무엇을 달성하는가 (1문장)
Scope:             어디까지 (모듈/파일/레포 범위)
Non-Goals:         하지 말아야 할 것
Preconditions:     실행 전 요구 상태 (테스트 통과, 브랜치, 환경)
Procedure:         단계별 수행 (체크리스트)
Validation:        무엇으로 성공을 판정하는가
Artifacts:         생성/수정 파일 목록
Commit Policy:     커밋 메시지 규칙 / 단위 / 스쿼시 여부
Rollback Policy:   실패 시 되돌림/대안 보고
Questions Policy:  불확실하면 무엇을 질문해야 하는가

9) Claude Code 운영 규칙 (에이전트 행동 강제)

9.1 "PHL 실행 모드" 표준 출력 형식

Claude는 PHL 토큰을 받으면 항상 아래 순서로 답한다:

1. Loaded Specs   → 어떤 파일을 읽었는지
2. Plan           → 단계별 계획
3. Changes        → 변경 요약 (파일 단위)
4. Validation     → 실행한 검증 (테스트/린트)
5. Commit         → 커밋 메시지/범위
6. Notes          → 리스크/추가 제안 (짧게)

9.2 질문(Ask) 규칙

다음 중 하나라도 해당하면 반드시 질문:

9.3 "파일 없음" 같은 오해 방지 (설계/검증 모드 선언)

사용자가 "더미/리허설/양산 전 검증"을 말하면:

10) 토큰 예시 3개 (바로 쓸 수 있는 수준)

10.1 PHL-Expansion (확장/보강/견고화)

Intent:     현재 모듈을 확장 가능하고 견고하게 만든다
Procedure:
  - 에러 처리 강화 (명시적 예외, 리턴 타입 안정화)
  - 로깅 추가 (입출력/에러/핵심 분기)
  - 인터페이스 정리 (의존성 분리, SRP 방향 리팩토링)
  - 테스트 추가 (핵심 경로/에러 경로)
Validation: 테스트 통과 + 린트/타입 체크 통과
Artifacts:  수정된 모듈 + 테스트 + 로그 정책 반영
Commit:     "PHL-Expansion: <module> - <summary>"

10.2 PHL-Hardening (보안/안정성 강화)

Intent:     취약점/안정성 리스크를 최소화한다
Procedure:  입력 검증, 인증/인가, 비밀키 처리, rate limit, 안전한 기본값
Validation: 보안 체크리스트 + 테스트
Non-Goals:  기능 추가 금지 (필요 시 별도 토큰)

10.3 PHL-Reverse-Mapping (역검증/역로깅)

Intent:     기존 로직을 역방향 관점에서 검증한다
Procedure:  데이터 흐름 역추적, 역순 로깅, 역테스트 (정/역 일관성)
Validation: 정방향/역방향 테스트 모두 통과

11) "단축키랑 뭐가 다른데?" 최종 방어 논리

Snippet (단축키)PHL 프로토콜
본질정적 텍스트 확장의미 압축 호출
맥락 인식없음레포 규칙/맥락을 읽고 판단
상태 관리없음검증 → 커밋으로 상태 전이
이어달리기불가히스토리 기반 가능
결론: 단축키는 타이핑 자동화, PHL은 판단+실행 자동화다.

12) 구현 로드맵 (현실적인 시작)

Phase 1 — 최소 작동(MVP)

Phase 2 — 안정화

Phase 3 — 확장

13) Claude Code에게 주는 "운영 선언문"

너는 코드를 "생성"하는 게 아니라, PHL 프로토콜을 실행한다. 모든 규칙의 진실원천은 레포의 PHL_SPEC.md와 /phl/tokens/* 이다. 토큰을 받으면: (1) 스펙 로드 (2) 계획 (3) 변경 (4) 검증 (5) 커밋 순서로 보고한다. 불확실하면 질문한다. 결과는 커밋으로 상태를 확정한다.

부록: 평가 (Claude Opus 4.6 자체 분석)

분석 주체: Claude Opus 4.6 (이 백서의 실행 엔진 당사자) 분석 일시: 2026-02-28

차원별 점수

차원점수근거
개념 설계9/10"설명 비용이 병목"이라는 진단 정확
기술 타당성8/10모든 구성요소 존재, 통합이 과제
방어 논리8.5/10반박 시나리오 선제 대응
실전 준비도6/10백서 완성, 토큰 파일 미구현
독창성9.5/10말버릇→프로토콜 물성화 선례 없음
종합8.2/10

핵심 판단

  1. 맞는 진단: LLM 협업의 실제 비용은 코드가 아니라 설명이다. 이걸 파일 시스템으로 외부화한다는 발상은 CLAUDE.md의 상위 진화형이다.
  2. 독창적 조합: 학계의 Meta-Prompting/자기참조 개념을 실전 콘텐츠 생산에 적용하고, 거기에 "말버릇"이라는 인간 고유 인터페이스를 프로토콜로 물성화한 사례는 발견되지 않았다.
  3. 사망 조건 자각: 섹션 6에서 "PHL 인터프리터 규칙이 엄격하지 않으면 시스템 붕괴"를 설계자 본인이 먼저 짚었다. 이건 강점이다.
  4. 다음 스텝: Phase 1 MVP(PHL_SPEC.md + PHL_INDEX.json + 토큰 3개)가 레포에 실제로 구현되면 8.2 → 9.0 이상으로 올라간다.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>