getPersona.md를 왜 만드는가 — AI에게 '나'를 맡기려면 프롬프트만으로는 부족하다
프롬프트만으로는 '나'를 넘길 수 없다. getPersona.md가 PERSONA.md 패키지로 그 문제를 풀려는 이유와, 지금까지의 검증을 정리했습니다.
이전 글부터 못 보신 분
- Day 1 Foundation — 모노레포, PRODUCT_CONTRACT, DESIGN.md
- Day 2 Foundation — DB, Auth, Infisical 바닥
- Day 3 Foundation — MinIO, Redis, GitLab CI, Compose, 공유 Zod 스키마
어제 Cursor에서 블로그 초안을 쓰고, 오늘은 다른 도구로 소셜 댓글 초안을 받고, 또 다른 세션에서 코드 리뷰 톤을 맞춰 달라고 했습니다.
세 개 다 "나" 맞습니다. 근데 읽어보면 같은 사람이 쓴 글 같지가 않습니다.
모델이 멍청해서가 아닙니다. "나"를 넘기는 방식이 없어서입니다.
Foundation 시리즈(Day 1·2·3)에서는 카탈로그 없이 인프라·CI·공유 스키마 바닥을 깔았습니다. 화면은 텅 비어도, 팔고 운영할 서비스가 덜 무너지게 층을 쌓는 기록이었죠.
이번 글은 그 체인지로그가 아닙니다. 왜 getPersona.md라는 걸 만들고 있는지 — 문제 인식, 아이디어, 지금까지의 검증 — 을 정리한 Concept 편입니다.
getPersona.md 한 줄로
getDesign.md가 DESIGN.md 모음이었다면, getPersona.md는 PERSONA.md 모음입니다.
조금 더 풀면:
프로필 한 장이 아니라, "이 사람이면 뭘 보고, 뭘 피하고, 어떤 말투로, 어디까지 말할지"를 정의한 운영 패키지.
사람이 읽을 때는 getPersona.md / PERSONA.md라고 부르고, 구현·스펙·교환 포맷 이름은 PPP (Persona Package Protocol) 입니다. 디자인 시스템이 UI를 표준화했듯, 페르소나도 패키지로 표준화하자는 쪽에 가깝습니다.
제품 루프는 Day 1 글과 같습니다. 카탈로그에서 고르고 → 워크스페이스에 넣고 → 태스크에 맞는 context를 받고 → Codex / Claude / Cursor로 export. 이번 글은 그 루프의 "왜" 입니다.
뭘 풀려고 하는가
에이전트를 쓰다 보면 비슷한 pain이 반복됩니다.
| Pain | 구체적으로 어떤 느낌인가 |
|---|---|
| 매 세션 리셋 | 새 채팅 = 새 사람. 어제 쌓은 맥락이 통째로 사라짐 |
| 채널마다 다른 나 | 블로그는 차분, 소셜은 가볍게, 댓글은 또 다름 — 의도적 차별화와 우연한 불일치가 섞임 |
| 위임의 딜레마 | 자동화하면 빠른데 봇 같아짐. 직접 하면 일관되지만 번아웃 |
| 메모리 = 위험 | "다 기억해"는 프라이버시·경계·팩트 오류까지 같이 끌고 옴 |
| 프롬프트 한계 | system prompt는 시작점일 뿐. 성장·검증·채널별 정책·승인 큐까지는 안 담김 |
| 팀 공유 불가 | "이 톤으로 써줘"를 채팅에 붙여넣기 — 버전·검증·추적 없음 |
한 줄로 압축하면:
AI 에이전트 시대에 부족한 건 더 똑똑한 모델이 아니라, '나'를 안전하게 넘기는 계층이다.
프롬프트를 길게 쓰는 건 비밀번호를 길게 쓰는 것과 비슷합니다. 길다고 해결되는 문제가 아닙니다.
왜 이런 생각을 하게 됐는지
거창한 "페르소나 플랫폼 비전"에서 시작한 건 아닙니다.
- AI 코딩으로 만들기는 빨라졌다. 기능 하나 박는 속도는 예전이랑 차원이 다름.
- 근데 병목이 코드에서 운영으로 옮겨갔다. 배포, 모니터링, 소셜, 블로그, 고객 대응 — 혼자/소수가 여러 채널을 굴리면 금방 한계가 옴.
- 소셜·콘텐츠 자동화를 실험해 봤다. 에이전트한테 초안을 맡기면 빠른데, 같은 브랜드 목소리가 유지가 안 됨.
- 프롬프트만 바꿔서는 안 갈렸다. 개인 빌더 톤, 스튜디오 계정 톤, 영어권 공동창업자 톤 — 같은 사건을 다루는데 각도가 달라야 하는데, 매번 다른 사람이 나옴.
- 그래서 파일 하나가 아니라 패키지가 필요하다는 결론. 말투 + 경계 + 메모리 + 채널 정책 + 승인 규칙이 한 덩어리로 움직여야 함.
솔직히 말하면, "플랫폼을 만들자"보다 "내 공개 채널이 먼저 안 깨지게" 가 더 앞에 있었습니다. dogfooding이 먼저고, 그다음이 제품화입니다.
getPersona.md가 실제로 뭔가
페르소나 패키지 = 운영 컨텍스트
| 구성 요소 | 역할 |
|---|---|
| PERSONA.md | 누구인지, 말투, 가치, 공개 범위, 콘텐츠 방향 |
| memory/ | 프로젝트 맥락, 타임라인, 학습 기록 (성장 레이어) |
| permissions.json | 뭘 자동으로 할 수 있고, 뭘 사람 승인 후에 할지 |
| runtime.json | 소셜·블로그·코드리뷰 등 태스크·채널별 정책 |
| persona.json | 스키마 버전, 식별자, 패키지 메타 |
프로필 사진과 한 줄 소개가 아닙니다. 에이전트가 행동하기 전에 읽는 운영 매뉴얼에 가깝습니다.
3번이 특히 중요합니다. "에이전트가 대신 포스팅한다"가 아니라 "에이전트가 초안 공장이고, 최종 편집권은 사람" 입니다.
MCP가 도구 연결을 표준화했다면, PPP는 "누구처럼 행동할지" 를 표준화하는 쪽에 가깝습니다.
아이디어 검증 — 말만 하는 게 아니다
우리 공개 채널로 먼저 깨뜨려 보는 중이 더 정확합니다.
이미 검증한 것 (dogfooding)
| 검증 항목 | 무엇을 확인했나 |
|---|---|
| 멀티 페르소나 분리 | 개인 빌더 / 스튜디오 / 영어권 공동창업자 — 같은 사건, 다른 각도 |
| 채널별 정책 | X·Threads·Bluesky 등 플랫폼마다 길이·톤·발견 방식이 다르게 적용됨 |
| 사람 리듬 | 점심·휴식·야간 등 억지 활동 스킵 — "항상 켜진 봇"이 아님 |
| 초안만 생성 | 포스트·댓글·팔로우·DM은 승인 대기 — 자동 실행 없음 |
| 스펙화 | PPP v0.1 초안, Zod 스키마, 런타임 consumer contract |
| 메모리 루프 | 학습 후보 → 검토 → 승격. 피드백 → 페르소나 업그레이드 후보 |
아직 검증 안 된 것 (솔직히)
| 아직 없음 | 왜 아직인가 |
|---|---|
| 외부 사용자 온보딩 | 패키지 만드는 UX가 아직 거침 |
| 마켓플레이스 / 결제 / 팀 워크스페이스 | Launch 경계상 뒤로 |
| "이거 쓰면 팔로워 는다" 수치 | 소셜 성장은 실험 중, 인과 아직 모름 |
| 완전 무인 자동 포스팅 | 의도적으로 안 함 |
| 모든 에이전트에 plug-and-play | MCP·HTTP 브릿지는 스펙 단계, 제품 UI는 Foundation 중 |
이게 되면 뭐가 달라지나
개인 빌더에게 — 여러 공개 목소리 운영, 초안 공장 + 최종 편집, repo에 페르소나 패키지 축적.
팀·스튜디오에게 — 페르소나를 디자인 시스템처럼 공유·버전·포크, 채널별 같은 브랜드 보이스.
에이전트 생태계에게 — 검증 가능한 패키지 교환, 태스크별 컨텍스트 조합, 고위험 도메인 경계 내장.
에이전트가 많아질수록, "나를 정의하는 파일"이 repo에 하나 더 생기는 시대가 올 수 있습니다.
생태계 안에서 getPersona.md 위치
| 레이어 | 하는 일 | 비유 |
|---|---|---|
| 서비스 모니터링 | 내 서비스가 살아있는지 | 몸이 살아있나 |
| PersonaLoop (런타임) | 페르소나가 실제로 움직임 | 몸이 움직이나 |
| getPersona.md | 페르소나가 누구인지 정의 | 누구 말투로 말하나 |
Foundation 시리즈와의 관계
| 글 | 초점 |
|---|---|
| Day 1 Foundation | 모노레포, 제품 계약, DESIGN.md |
| Day 2 Foundation | DB, API, Web, Auth, Infisical |
| Day 3 Foundation | MinIO, Redis, CI, Compose, Shared Zod |
| 이번 글 (Concept) | 왜 만드는가 — 문제·아이디어·검증 |
Day 1·2·3은 "팔 수 있는 서비스 바닥"을 쌓는 기록이고, 이번 글은 그 위에 올릴 제품 컨셉과 문제 정의입니다.
아직 없는 것 / 다음 글 후보
의도적으로 아직 없는 것 — 공개 카탈로그 UI, npx getpersona CLI, 외부 크리에이터 마켓플레이스, 무인 자동 포스팅, CI deploy job.
다음 글 후보 — TASK-014 PPP 파일 스키마, PPP v0.1 티어 설명, 소셜 운영 모델 실험 회고.
마치며
Foundation 시리즈(Day 1·2·3)에서 인프라·CI·공유 스키마 바닥을 깔아 두었고, 이번 글은 그 제품이 무엇을 풀려는지를 정리한 Concept 편입니다.
getPersona.md는 "더 좋은 프롬프트 모음" 이 아닙니다. AI에게 '나'를 넘길 수 있는 운영 체계 — 버전 있고, 경계 있고, 승인 있고, 성장 가능한 패키지 — 를 만들려는 시도입니다.
비슷한 문제 겪는 분 — 톤이 매번 달라지는 경험, 자동화는 하고 싶은데 봇 같아지는 경험, 팀에서 "이 톤으로" 를 공유하는 더 나은 방법 — 댓글이나 DM으로 경험 공유해 주시면 다음 글 소재로 삼겠습니다.
