LLM에게 “기획서 써줘”라고 하면 자신감은 넘치지만 알맹이가 얕은 결과가 돌아온다. service-planning-harness는 글을 쓰는 쪽과 점수를 매기는 쪽을 따로 두는, 생성하는 쪽과 평가하는 쪽을 맞붙이는 방식(GAN)의 3-에이전트 하네스다. 이 구조로 그 얕음을 자동으로 바로잡는다. 한 줄 아이디어를 곧바로 개발에 착수할 수 있는 16종 기획 산출물과 보기 좋은 대시보드로 바꿔 준다.
TL;DR
- 한 줄 아이디어를 16종 기획 산출물로 전환한다.
- Planner→Generator→Evaluator, 세 역할을 맞붙이는 방식(GAN) 구조다.
- 쓰는 쪽과 평가하는 쪽을 나눠, 자기가 쓴 글을 자기가 후하게 평가하는 문제를 막는다.
- character-market 적용 4축 전부 PASS다.
- 강한 모델에도 Full tier를 의도 선택했다.
이 글의 진짜 핵심은 따로 있다. Opus 4.8은 한 번에 다룰 수 있는 글의 양(컨텍스트)이 100만 토큰이라, 글이 길어지면 대충 마무리하려는 버릇이 사실상 없다. 그런데도 가장 꼼꼼한 Full 단계를 일부러 골랐다는 점이다. 단계를 잘게 나눈 스프린트 구조는 글 길이를 줄이려는 장치가 아니다. “기획서를 모아서 만들기 전에 조사 품질부터 통과 검사한다”는, 그것과는 별개의 목적을 가진 장치다.
왜 필요한가 — “그냥 기획서 써줘”의 3가지 실패
LLM에게 아무 조건 없이 기획서를 맡기면 늘 같은 세 곳에서 무너진다. 첫째, 차별화가 “더 편리하다 / 더 빠르다”식 두루뭉술한 말로 뭉개진다. 누구나 하는 기본 수준의 문구라 경쟁에서 앞설 무기가 못 된다.
둘째, 범위가 “전부 다 만들자”로 부푼다. 최소 핵심 제품(MVP)으로 뭘 먼저 만들고 뭘 안 만들지 선이 없어, 첫 삽조차 뜰 수 없게 된다. 셋째, 성공지표가 “만족도 향상” 같은 잴 수 없는 문구로 끝난다. 무엇을 어떻게 잴지가 빠져 있다.
service-planning-harness는 이 세 가지를 정반대로 하도록 강제한다. 실제 이름을 가진 경쟁사와 대놓고 비교하게 하고, 먼저 만들 것(MVP)과 안 만들 것을 갈라 두게 하며, 잴 수 있는 지표(숫자+측정 방법)를 반드시 쓰게 한다. 아래 4분면 그림이 그 차이를 한눈에 보여준다.
어떻게 동작하나 — 3-에이전트 GAN 하네스
흐름은 주제 받기(인테이크, 어떤 모드로 만들지 고르는 단계)에서 시작한다. Planner가 spec.md와 sprint-playbook.md를 쓰면, 4개의 조사 스프린트(짧게 끊어 돌리는 작업 묶음)가 차례로 돈다. 각 스프린트는 계약 정하기 → 만들기 → 검사 관문 순서로 이뤄지고, 이 검사 관문을 통과해야만 다음으로 넘어간다.
네 스프린트는 S1 시장·경쟁 → S2 문제·타겟·가상 사용자(페르소나) → S3 화면 흐름(UX/UI) → S4 기획서 통합작성 순이다. 스프린트가 모두 끝나면 마지막에 통합 Evaluator가 4축 + 7개 점검 항목(probe) + 6개 검사 관문으로 전체를 점검한다. 화면 설계 초안(와이어프레임)이 들어간 경우에만 사람이 눈으로 확인하는 단계를 거치고, 보기 좋은 HTML 화면을 만들어 낸 뒤 결과물을 넘긴다.
핵심은 글을 쓰는 Generator와 점수를 매기는 Evaluator가 서로의 속생각은 못 보고 오직 파일로만 주고받는다는 점이다. 둘 사이에는 spec.md·sprint_contract.md·research-s1/2/3.md·critique.md·인수인계 파일(handoff.md)만 오간다. 다룰 글이 너무 길어지면, 내용을 눌러 담는 압축(컴팩션) 대신 새 세션으로 갈아타며 회복한다. 인수인계 파일만 들고 새 세션을 여는 방식이다. 압축은 글이 길어지면 대충 마무리하려는 버릇이 든 상태를 그대로 끌고 가기 때문이다.
무엇이 특별한가 — 6가지 특징
이 하네스를 떠받치는 설계 결정은 여섯 가지다. 각각이 “그냥 LLM 기획”이 놓치는 지점을 메운다.
- 생성·평가 분리(GAN): 글을 쓰는 쪽(Generator)과 평가하는 쪽(Evaluator)을 서로 다른
Agent로 따로 띄운다. 자기가 쓴 글을 자기가 후하게 평가하는 문제, 즉 평범한 결과를 자신 있게 칭찬하는 버릇을 막아 준다. - Full 단계의 4개 조사 스프린트: S1 시장·경쟁 → S2 문제·타겟·페르소나 → S3 화면 흐름(UX/UI) → S4 통합작성으로 잘게 나누고, 각 스프린트마다 계약 정하기와 통과 검사(작업량 상한 5–15, 기본 약 8)를 둔다.
- 5 출력 모드: Lean MVP 기획서(기본) / 정식 PRD / 비즈니스+기획 통합 / 화면·기능 명세 / 풀 기획 패키지(16종 + HTML 대시보드)로 산출 깊이를 고른다.
- 4축 채점 기준표, 2배 가중: 점수를 매기는 기준표는 C1 문제정의(1배) / C2 차별화·독창성(2배) / C3 실행가능성·MVP범위(2배) / C4 지표 측정성(1배)으로 짜여 있다. 2배를 준 두 축은 Claude가 조건 없이 시키면 약해지는 차별화·실행가능성이다.
- 6개의 통과/탈락 검사 관문: G-a 기능↔문제 연결 / G-b 페르소나 구체성 / G-c 실명 경쟁 비교 / G-d 지표 측정성 / G-e 먼저 만들 것·안 만들 것 분리 / G-f 빈칸(자리표시자) 0개로, 여섯 개 모두 PASS여야 통과한다.
- 화면 초안이 있을 때만 사람 확인 + 골라 쓰는 HTML 산출: 화면 설계 초안(와이어프레임)이나 화면 견본(UI 목업)이 들어간 경우에만 사람이 눈으로 보고 승인하게 한다. 원본
.md는 항상 남기면서, 발동 시 고른 형태로 HTML도 함께 낸다. 기본은 각 문서를 읽기·공유·리뷰가 쉬운 HTML로 바꾸고 중요도·순서·역할별로 안내하는 허브index.html을 두는 형태다. 또는 그림·차트·정보 그래픽을 한곳에 담아 한눈에 보는 도식 대시보드를 고를 수도 있다.
아래 마인드맵은 5모드·4스프린트·4축 채점 기준표·6개 검사 관문 전체 구조를 한 장에 담는다.
풀 패키지는 16종 산출물을 5단계로 묶는다. 발견·전략 4종(00-business-model·01-service-plan·02-market-competition·03-personas), 정의 4종(10-prd·11-user-stories·12-ia·13-user-flows), 설계 2종(20-wireframes·21-screen-spec), 기술 4종(30-functional-spec·31-erd·32-api-spec·33-policy), 실행·검증 2종(40-backlog·41-qa-testcases)이다. 여기에 길잡이 INDEX.md가 더해지고, 발동 시 고르면 각 문서의 읽기용 HTML과 허브 index.html(또는 도식 대시보드)도 함께 나온다. 원본 .md는 항상 보존된다.
16종이 늘 전부 필요한 것은 아니다. 그래서 모든 문서를 만든 뒤 마지막에 INDEX.md를 함께 만든다. 여기에는 중요도 3단계(꼭 필요 / 도메인 따라 필요 / 보조), 무엇부터 읽고 만들지의 작업 순서, 개발자·QA·디자이너·기획·경영처럼 역할별로 볼 문서 묶음, 그리고 개발 착수에 충분한 최소 6종 세트가 정리돼 있다. 16종 전부는 킥오프 정렬·고객 납품·규제 도메인에서 값지고, 평소에는 최소 세트만으로 시작하면 된다. 문서를 위한 문서가 되지 않도록 길을 잡아 주는 셈이다.
돈 규칙(가격·수수료율·정산 트리거)은 00-business-model 한 곳에서만 정의한다. ERD·API·정책서는 인용만 하고 재정의하지 않는다. 단일 출처 원칙이 정합성을 강제한다.
무엇이 더 나은가 — character-market 적용 증거
주장에는 증거가 붙어야 한다. 이 스킬을 character-market(AI 캐릭터와 창작자 직접 업로드가 만나는 양면 마켓플레이스)에 적용한 결과를 기록으로 남긴다.
최종 4축 점수는 C1 5 · C2 5 · C3 5 · C4 4였고, 6게이트 전부 PASS했다. 16종 산출물 + 1파일 HTML 대시보드가 생성됐다. 실명 경쟁사 5개(Character.AI · 제타 · 크랙 · BOOTH · Poe)를 실제 웹서치로 비교했다. 돈 규칙 단일출처(00-business-model) 강제로 ERD·API·정책서가 그 위에 정합됐다.
C4(지표 측정성)만 4점이라는 점이 오히려 믿을 만하다는 근거다. 자기가 쓴 글을 자기가 후하게 평가했다면 모든 축이 5점으로 나오기 쉽다. 별도의 Evaluator가 한 축을 깎았다는 사실이, 통과 검사가 실제로 작동했다는 증거다.
왜 강한 모델에도 Full tier인가 + 정리
Opus 4.8은 한 번에 다루는 글의 양이 100만 토큰이라, 글이 길어지면 대충 마무리하려는 버릇이 사실상 사라졌다. 글 길이 문제만 놓고 보면 단계를 잘게 나눈 스프린트 구조는 굳이 안 해도 되는 일이고, 기본 권장은 더 간단한 Simplified다. 그런데도 이 스킬은 일부러 Full을 골랐다.
이유는 글 길이 완화가 아니다. 조사 단계의 품질을 통과 검사하기 위한, 그것과는 별개의 목적 때문이다. S1–S3 조사를 Evaluator가 검사 관문으로 통과시킨 뒤에만 S4가 기획서를 모아서 만든다. 부실한 시장조사 위에 기획이 쌓이는 것을 막는 것이 핵심이다. Anthropic의 Building Effective Agents는 “쓸 수 있는 가장 단순한 해법을 먼저 찾고, 꼭 필요할 때만 복잡하게 만들라”고 말한다. Full을 고른 것은 이 원칙을 어긴 게 아니라, 조사 품질을 검사한다는 별개의 필요 때문이다.
모든 부품에는 “이건 이럴 것이다”라는 가정이 숨어 있다. 모델을 더 좋은 것으로 바꿨다고 그 가정을 한꺼번에 다 걷어내는 것은 위험하다. 차근차근 하나씩 부하를 걸어 시험해 보는 편이 안전하다. 이 스킬 자체도 스킬을 만들어 주는 또 다른 하네스 skill-wizard-harness로 만들어지고 점검됐으며, 글 항목 점검(article-coverage) 33행 PASS를 받았다. 공개 저장소 github.com/greeun/service-planning-harness 에서 영어·한국어 README를 함께 제공한다. 한 줄 아이디어가 검사 관문을 통과한 16종 산출물로 바뀌는 과정을 직접 한 번 돌려 보고, 자기 작업에 가져다 쓸지 판단하면 된다.
🔗 GitHub: github.com/greeun/service-planning-harness (public · 영어·한국어 README 제공)