revfactory 한글 폰트 스튜디오 — 오케스트레이터
목표: 세상에 없는 독창적 한글 폰트를 샘플 → 피드백 → 개선 루프로 제작한다.
팀 구성 (12 에이전트, 정의: .claude/agents/)
| 에이전트 | 역할 | 주 스킬 |
|---|---|---|
| font-director | 크리에이티브 디렉터, 승인/반려 | — |
| hangul-analyst | 자모·블록·커버리지 분석 | hangul-composition |
| concept-artist | 콘셉트 발굴 + 샘플 글리프 | hangul-composition, glyph-design |
| choseong-designer | 초성 19자 + 변형 | glyph-design |
| jungseong-designer | 중성 21자 + 변형 | glyph-design |
| jongseong-designer | 종성 27종 | glyph-design |
| latin-symbol-designer | 라틴·숫자·부호 | glyph-design |
| composition-engineer | 슬롯 테이블, 음절 조합 | hangul-composition, glyph-design |
| specimen-designer | 시안 제작·배포 | font-specimen |
| font-engineer | TTF 빌드 | font-build |
| type-qa | 일관성·경계면 검증 | glyph-design, font-build |
| feedback-analyst | 피드백 → 변경 스펙 | design-feedback |
모든 Agent 호출에 model: "opus"를 명시한다.
Phase 0: 컨텍스트 확인 (매 실행 필수)
_workspace/ 상태로 실행 모드를 결정한다:
_workspace/없음 → 초기 실행: Phase 1부터 전체_workspace/있음 + 피드백/부분 수정 요청 → 부분 재실행: feedback-analyst부터 시작해 변경 스펙이 지정하는 에이전트만 재호출._workspace/feedback/·_workspace/decisions/이력을 먼저 읽는다. 특정 글자·자모 수정 요청이면 Phase 3의 자모 수정 루프(12)로 직행 — 자모 정의 수정 → 재생성 → 리빌드_workspace/있음 + 완전히 새 방향 요청 → 새 실행: 기존을_workspace_prev/로 이동 후 초기 실행- 어느 쪽인지 모호하면 사용자에게 확인한다 — 기존 작업을 덮어쓰는 판단은 임의로 하지 않는다
워크플로우
Phase 1: 콘셉트 탐색 — 실행 모드: 서브 에이전트 (병렬)
독립 탐색이라 팀 통신이 불필요하다. 콘셉트 간 오염을 막기 위해 오히려 서로 몰라야 한다.
- hangul-analyst로 샘플 음절 세트·자모 분해 표 생성 (
_workspace/analysis/) - concept-artist를 서로 다른 축(구조/획/공간)의 브리프로 2~4개 병렬 스폰 (
run_in_background: true)- 각자
_workspace/concepts/{콘셉트명}/에 concept.md + 샘플 글리프 SVG 산출
- 각자
- font-director가 결과를 평가 (
_workspace/decisions/round-1.md)
Phase 2: 시안 제작 및 피드백 — 실행 모드: 서브 에이전트 (파이프라인)
- type-qa가 글리프 규약 검증 (stroke 금지, viewBox 등 — 기계 검출 우선)
- specimen-designer가
_workspace/specimens/round-{N}.html제작 + Artifact 배포 - 사용자 피드백 대기 — 시안의 질문 블록에 대한 답을 받는다
- feedback-analyst가 피드백을 변경 스펙으로 변환 (
_workspace/feedback/round-{N}.md) - 변경 스펙에 따라 담당 에이전트 재호출 → 5로 복귀. 콘셉트가 확정될 때까지 이 루프를 반복한다
Phase 3: 본 제작 — 자모 조합 시스템 (콘셉트 확정 후) — 실행 모드: 하이브리드
본 제작은 음절 수작업이 아니라 자모 정의 × 조합 엔진이다 (라운드 4에서 구축, hangul-composition 스킬의 "자모 조합 시스템" 섹션 참조). 천지인 시스템: _workspace/glyphs/천지인/system/ — composition-engineer가 소유.
- 시스템 구축/확장 (신규 콘셉트면): composition-engineer가 문맥 박스(contexts.json)·엔진 검증 — 손 제작 표본과 엔진 재생성본의 시각 비교가 합격 기준
- 자모 정의 작성 (서브 병렬): choseong/jungseong/jongseong-designer가 각자 jamo_cho/jung/jong.json 분담 — 파일이 분리되어 충돌 없음. 각자 compose.py로 테스트 음절 생성 → 콘택트 시트 렌더 → Read 판독 검증 루프 통과 후 제출
- 전체 생성 + 표본 QA:
compose.py --ks2350으로 11,172자 생성 → 일상어 + 극단 조합(쌍자음·복합모음·겹받침) 표본 시각 검증 - 자모 수정 루프 (피드백·QA 지적 시): 개별 SVG를 고치지 말고 원인 자모 정의를 수정 → 전체 재생성 → 표본 재검증. 이유: 개별 수정은 재생성 때 소실되고, 자모 수정은 그 자모를 쓰는 모든 글자에 일괄 적용된다
- 시안 갱신(Phase 2의 5~8 루프) — 피드백 없이 커버리지만 늘리지 않는다
Phase 4: 빌드·릴리스 — 실행 모드: 서브 에이전트
- latin-symbol-designer로 시안 등장 라틴·부호 제작 (요청 시)
- font-engineer가 TTF 빌드 —
--family는 ASCII("Cheonjiin") +--family-ko "천지인"(font-build 스킬: 비ASCII 기본명은 macOS 설치 거부) + 빌드 리포트 - type-qa가 빌드 산출물 경계면 검증 (manifest ↔ TTF 글리프 수·cmap 대조) + PIL 실조판 렌더 확인
- 배포 요청 시: font-build 스킬의 릴리스 절차 —
fonts/에 최신판만 유지, README 버전표 갱신, 한글 커밋 메시지로 push (github.com/revfactory/font-harness)
데이터 전달 프로토콜
- 파일 기반(주): 모든 산출물은
_workspace/규약 경로에 저장. 파일명·경로가 인터페이스다 - 팀 모드: TaskCreate(작업·의존성) + SendMessage(접점 좌표·반려 사유 등 실시간 조율)
- 서브 모드: 반환값(요약·경고) + 파일(산출물)
_workspace/
├── analysis/ # hangul-analyst: 음절 분해, 커버리지, 제작 브리프
├── concepts/{명}/ # concept.md + glyphs/*.svg + manifest.json
├── glyphs/{명}/
│ ├── syllables/ # 손 제작 음절 (초기 라운드 검증용)
│ ├── system/ # 자모 조합 시스템: jamo_*.json + contexts.json + compose.py
│ └── generated/ # 엔진 생성 전체 음절 + manifest.json (재생성 가능 — 수정 금지)
├── specimens/ # round-{NN}.html (+ round-{N}-copy.json)
├── feedback/ # round-{N}.md
├── decisions/ # font-director 결정 기록
├── qa/ # 검수 리포트
└── build/ # TTF (버전별 보존)
fonts/ # 배포 폴더 — 최신 릴리스 1개만 (README·GitHub 공개용)
에러 핸들링
| 상황 | 처리 |
|---|---|
| 에이전트 산출물 누락/규약 위반 | 1회 재시도(위반 내용 명시) → 재실패 시 해당 항목 제외하고 진행, 시안·리포트에 누락 명시 |
| 콘셉트 병렬 탐색 중 1개 실패 | 나머지로 진행, 결정 문서에 실패 콘셉트 기록 |
| 슬롯/스펙 충돌 (디자이너 간 상충) | 삭제하지 않고 양쪽 병기 → font-director 중재, 결정 기록 |
| 빌드 실패 글리프 | 제외 빌드 + 리포트 명시, 다음 라운드 최우선 수정 |
| 피드백 해석 모호 | 임의 진행 금지, 최소 개수의 확인 질문으로 사용자에게 |
테스트 시나리오
정상 흐름 (초기 실행): "독창적인 한글 폰트 샘플 만들어줘" → Phase 0(초기 판정) → 분석 → 콘셉트 3개 병렬 → QA → 시안 round-01 배포 → 피드백 질문 제시. 성공 기준: _workspace/concepts/ 2개 이상, 시안에 유형 라벨·누락 명시·질문 블록 존재.
에러 흐름 (부분 재실행 + 산출물 결함): "받침이 너무 커요, 고쳐줘" → Phase 0(부분 재실행 판정) → feedback-analyst가 "유형4·5·6 종성 슬롯 조정"으로 일반화 → composition-engineer 재호출 → 재조합 중 ㅄ 글리프 규약 위반 발견 → 1회 반환·재시도 → 실패 시 해당 음절 플레이스홀더로 시안 갱신 + 누락 명시. 성공 기준: 지적 글자만 고치지 않고 규칙 단위로 수정, 누락이 시안에 표기됨.