OrbitPrompt Whitepaper — Final v1.0

PHL × OrbitPrompt
× Claude Code

Closed-Loop Cognitive OS (Protocol-First)

2026-02-28  ·  Co-Authored: Claude Opus 4.6

목차

00

한 줄 정의

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

구성요소역할
PHLMeaning DSL (말 기반 프로토콜)
Claude CodeState Transition Engine
GitHub 레포State Store (영구 메모리)
OrbitPromptPHL → 실행 단위(Prompt Atom) 변환 Runtime

핵심

이건 "프롬프트 모음집"이 아니라 프로토콜 설계다. 단축키·스니펫이 아니라 상태 전이(state transition) 기반 운영체제(OS) 레벨 인터페이스다.

01

왜 이게 필요한가 — 문제 정의

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

LLM 코딩 협업의 실제 병목은 "코드를 못 짜서"가 아니라 설명 비용이다.

  • 자연어 설명은 길고, 모호하고, 재설명·재확인 반복이 생긴다.
  • "대충 더 튼튼하게" 같은 표현은 AI가 구현 모드로 오해하거나 과잉·과소 수행한다.

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

아무리 컨텍스트가 길어도 프로젝트 전체 규칙·철학·기본기·보안·스타일·프로토콜과 반복되는 리팩토링·테스트·로깅·에러 처리를 매번 대화로 실어 나르면 토큰이 붕괴한다.

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

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

02

핵심 아이디어 — 아키텍처 골자

🗜️ 2.1 Semantic Compression Interface
PHL 토큰은 "명령어"가 아니라 의미 압축(semantic compression)이다. 토큰 하나가 레포에 정의된 규칙·철학·검증 절차를 호출한다. 결과적으로 사용자 음성(STT)·텍스트 출력의 정보 밀도(density)가 상승한다.
📂 2.2 Externalized System Prompt (GitHub as Ruleset)
레포는 단순 저장소가 아니라 외부화된 시스템 프롬프트 역할을 한다. Claude는 작업 전에 레포의 "규칙 파일"을 읽고, 실행 중에도 필요한 정의를 검색·참조한다. "규칙"은 대화가 아니라 파일 시스템(레포)에 존재한다.
🔀 2.3 Stateful Command Model (Snippet과의 차이)
스니펫은 항상 같은 코드를 붙여넣는다. 맥락(파일 구조, 데이터 흐름, 변수명, 에러 전략)을 모른다. 상태 저장이 없다.

PHL은 현재 코드·구조·테스트·로그·보안 상태를 읽고 판단한다. 결과를 커밋으로 남겨 "이전 상태"를 참조 가능하게 만든다. 같은 토큰이라도 프로젝트 맥락에 맞게 수행이 달라진다.

03

시스템 구성요소 정의

3.1 PHL — Meaning DSL / Protocol Tokens

PHL은 "자연어"가 아니라 프로토콜 토큰 집합이다. PHL 토큰은 다음을 포함한다:

  • 목적(Goal)
  • 범위(Scope)
  • 제약(Constraints)
  • 수행 단계(Procedure)
  • 산출물(Artifacts)
  • 검증(Validation)
  • 실패 시 정책(Failure policy)

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

3.2 OrbitPrompt — Execution Runtime / Prompt Atom

OrbitPrompt는 PHL 토큰·명령을 실행 단위(Prompt Atom)로 분해하고, Claude가 코드 작업을 수행할 수 있게 작업 계획·체크리스트·출력 형식으로 변환한다.

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

역할내용
원천(Truth)PHL 정의의 단일 진실원천
기록(Log)실행 결과의 이력
버전(History)상태의 버전 관리
실험(Experimentation)롤백·브랜치 실험 환경

핵심 선언

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

04

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

4.1 실행 사이클 (필수)

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

4.2 상태 전이 원칙 (필수)

  • 커밋 없는 변경은 "임시 상태"로 간주
  • PHL 토큰 실행은 반드시 검증을 포함
  • 실패 시: 되돌리거나(rollback) 실패 로그·대안 플랜을 남김

05

기술적 근거 — 방어 논리

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

항목가능 여부
레포 기반 규칙 저장✅ 가능
에이전트가 파일 읽고 작업✅ 가능
PHL 토큰을 규칙으로 매핑✅ 가능
실행 결과를 커밋으로 상태화✅ 가능

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

환경에 따라 자동 로드는 보장되지 않는다. 따라서 운영 규칙으로 강제한다. 에이전트 시작 시 PHL_SPEC.md와 PHL_INDEX.json을 먼저 읽는 루틴을 작업 스크립트·체크리스트로 고정한다.

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

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

5.4 반박 대비 — "환각이 줄어드나?"

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

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

06

핵심 병목 — PHL Interpreter Spec

⚠ 사망 조건

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

PHL이 느슨하면:

  • Claude가 "자기 해석"을 한다
  • 작업이 매번 달라진다
  • 다시 설명 비용이 생긴다
  • 결국 시스템이 붕괴한다

07

레포 구조 제안

/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/ # 실행 플레이북(단계별 체크리스트) /orbit/templates/ # Prompt Atom 생성 규칙/템플릿 /reflection/ # 로그, 회고, 실패 기록, 사례 /CHANGELOG.md

원칙

토큰 정의는 "짧게 호출 / 길게 정의". 정의는 파일로 쪼개서 검색 가능하게. PHL_INDEX.json으로 토큰 탐색 비용 최소화.

08

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

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

09

Claude Code 운영 규칙

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

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

9.2 질문(Ask) 규칙

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

  • 범위가 모호함 (어느 모듈인지)
  • 정책 충돌 (보안 vs 속도)
  • 테스트·빌드 실패했는데 진행 요청
  • 외부 API·비밀키 등 민감정보가 필요
  • 요구가 정의되지 않은 토큰 호출

9.3 Architecture Validation Mode

사용자가 "더미·리허설·양산 전 검증"을 말하면 구현 모드가 아니라 Architecture Validation Mode로 전환. 파일이 없어도 계약·프로토콜·디렉토리 스캐폴딩·Mock을 만든다.

10

토큰 예시 3개

🔧 PHL-Expansion — 확장·보강·견고화
Intent: 현재 모듈을 확장 가능하고 견고하게 만든다 Procedure: - 에러 처리 강화 (명시적 예외, 리턴 타입 안정화) - 로깅 추가 (입출력/에러/핵심 분기) - 인터페이스 정리 (의존성 분리, SRP 방향 리팩토링) - 테스트 추가 (핵심 경로/에러 경로) Validation: 테스트 통과 + 린트/타입 체크 통과 Commit: "PHL-Expansion: <module> - <summary>"
🔒 PHL-Hardening — 보안·안정성 강화
Intent: 취약점/안정성 리스크를 최소화한다 Procedure: 입력 검증, 인증/인가, 비밀키 처리, rate limit, 안전한 기본값 Validation: 보안 체크리스트 + 테스트 Non-Goals: 기능 추가 금지 (필요 시 별도 토큰)
🔄 PHL-Reverse-Mapping — 역검증·역로깅
Intent: 기존 로직을 역방향 관점에서 검증한다 Procedure: 데이터 흐름 역추적, 역순 로깅, 역테스트 (정/역 일관성) Validation: 정방향/역방향 테스트 모두 통과

11

단축키와의 차이 — 최종 방어

Snippet (단축키) PHL 프로토콜
본질 정적 텍스트 확장 의미 압축 호출
맥락 인식 없음 레포 규칙·맥락을 읽고 판단
상태 관리 없음 검증 → 커밋으로 상태 전이
이어달리기 불가 히스토리 기반 가능

단축키는 타이핑 자동화, PHL은 판단+실행 자동화다.

12

구현 로드맵

🚀 Phase 1 — 최소 작동(MVP)
PHL_SPEC.md 루트에 SSOT 생성 · PHL_INDEX.json 생성 · 토큰 3개 먼저 정의 (Expansion, Hardening, Refactor) · Claude 출력 형식·질문 규칙 고정
🔧 Phase 2 — 안정화
테스트·린트·CI 루틴 고정 · 실패 로그·롤백 정책 정교화 · 토큰 간 충돌(Non-Goals) 정리
🌐 Phase 3 — 확장
도메인별 토큰 묶음 (backend/frontend/docs/data) · 브랜치 전략 (실험/양산) · (옵션) Sketch DSL

부록

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

맞는 진단: LLM 협업의 실제 비용은 코드가 아니라 설명이다. 이걸 파일 시스템으로 외부화한다는 발상은 CLAUDE.md의 상위 진화형이다.

독창적 조합: 학계의 Meta-Prompting·자기참조 개념을 실전 콘텐츠 생산에 적용하고, "말버릇"이라는 인간 고유 인터페이스를 프로토콜로 물성화한 사례는 발견되지 않았다.

사망 조건 자각: 섹션 6에서 "PHL 인터프리터 규칙이 엄격하지 않으면 시스템 붕괴"를 설계자 본인이 먼저 짚었다. 강점이다.

다음 스텝: Phase 1 MVP(PHL_SPEC.md + PHL_INDEX.json + 토큰 3개)가 레포에 실제로 구현되면 8.2 → 9.0 이상으로 올라간다.

너는 코드를 "생성"하는 게 아니라, PHL 프로토콜을 실행한다.

모든 규칙의 진실원천은 레포의 PHL_SPEC.md와 /phl-spec/tokens/* 이다.

토큰을 받으면: (1) 스펙 로드 (2) 계획 (3) 변경 (4) 검증 (5) 커밋 순서로 보고한다.