대부분의 디렉터리 폼은 두 부분으로 나뉩니다. 한쪽은 제품을 설명하고, 다른 한쪽은 나를 설명합니다. 메이커 소개, 이름과 소속, 런치 보드라면 “왜 만들었는지”를 밝히는 댓글까지 요구하기도 합니다. 툴킷은 이 두 부분을 일부러 분리합니다. 제품에 관한 주장은 카피 워크숍에서 나와 copy.md에 저장되고, 개인에 관한 주장은 identity.json과 툴킷이 대외 소개 브리핑이라고 부르는 짧은 세션에서 나옵니다. 이 세션은 PR-BRIEFING.md에 설명되어 있습니다. 이 가이드는 그 세션이 무엇인지, 왜 필요한지, 그리고 representation.md에 무엇이 남는지 설명합니다.
왜 별도의 세션이 필요한가
방금 product.json을 채운 에이전트는 제품에 대해서는 많이 알지만, 내가 어떻게 소개되기를 원하는지는 거의 모릅니다. 그대로 두면 찾을 수 있는 정보(예전 직장, 이전 프로젝트, GitHub 프로필에 적힌 도시)로 소개 문구를 즉석에서 지어내 공개 메이커 프로필에 붙여 넣을 것이고, 한번 올라간 내용은 되돌리기 어렵습니다. 브리핑은 실제로 쓰일 문장을 내가 직접 확인하기 전까지는 개인적인 내용이 어떤 등록 페이지에도 올라가지 않도록 하기 위해 존재합니다. 제품마다 한 번, 첫 개인 정보가 공개되기 전에 진행하며, 그 정보가 바뀔 때마다 다시 진행합니다.
세 가지 질문
에이전트는 쉬운 말로 직접 묻습니다.
- 개인으로 소개되나요, 회사로 소개되나요, 아니면 둘 다인가요? 이 답에 따라 폼의 “메이커” 항목에 닉네임, 법적 이름, 조직 중 무엇이 들어갈지 정해집니다.
- 어떤 닉네임, 이름, 소속을 표시해도 되나요?
identity.json에 있는 모든 정보가 모든 등록 페이지에 쓰이도록 의도된 것은 아닙니다. - 절대 언급하면 안 되는 내용은 무엇인가요? 과거 제품, 관련 없는 직장, 실제 거주지 등 출시 게시물에 따라붙지 않았으면 하는 것이라면 무엇이든 해당합니다.
무엇을 묻지 않는지도 눈여겨보세요. 에이전트는 선택지를 지어내 그중에서 고르라고 하지 않습니다. 제약 조건을 모은 다음, 확인된 사실만으로 글을 씁니다.
세 가지 예시를 그대로 보여 주기
에이전트는 내가 확인한 내용만 사용해 짧은 글 세 개를 쓰고, 한 글자도 바꾸지 않은 채 그대로 보여 줍니다.
- 디렉터리 프로필에 쓸 한 줄 메이커 소개
- Show HN 스타일 게시물이나 런치 보드 댓글의 첫머리에 필요한 한 문장짜리 출시·포럼 소개
- 한 문장짜리 “왜 만들었나” 댓글
그런 다음 정말 중요한 질문 하나만 던집니다. 여기에 틀렸거나, 과장됐거나, 빠진 내용이 있나요? 모든 수정 사항은 identity.json에 조용히 메모하는 데 그치지 않고 예시 자체에 반영됩니다. 이 구분은 의도된 것입니다. 데이터 파일만 고치고 예전 문구가 담긴 초안을 그대로 둔 에이전트는 결국 예전 문구를 다시 씁니다. 내가 보지 않은 내용은 게시되지 않습니다.
무엇이 어디에 저장되나
승인된 예시, 내 수정 사항, 승인 날짜는 비공개 워크스페이스의 제품 폴더에 있는 representation.md에 저장됩니다. 그 뒤로는 소개 문구나 인사말이 필요한 플레이북 단계가 새로 지어내지 않고 이 파일에서 읽어 씁니다. 두 가지 경계가 이 파일을 믿을 수 있게 지켜 줍니다.
- 개인에 관한 주장은
copy.md의 제품 주장과 섞이지 않으며, 그 반대도 마찬가지입니다. 제품 컨텍스트 파일은 제품을 설명하고,representation.md는 나를 설명합니다. - 이 파일은 비공개 워크스페이스에만 있고 공유 전달용 저장소에는 절대 들어가지 않습니다. 또한 공개를 승인한 사실만 담으며, 비공개 계정 이메일이나
identity.json에서 비공개로 표시한 다른 정보는 포함하지 않습니다.
첫 세션에서의 위치
브리핑은 에이전트가 이끄는 온보딩의 3단계에 있습니다. identity.json을 채운 직후, 디렉터리에서 브라우저 작업을 시작하기 전입니다. 몇 분이면 끝납니다. 이 과정을 건너뛰고 에이전트가 그때그때 소개 문구를 쓰게 두면, 나중에 Product Hunt 메이커 페이지에서 내 제품을 검색해 보고 나서야 내가 어떻게 소개됐는지 알게 됩니다. 메이커 프로필을 출시 당일 이후가 아니라 그 전에 준비해 둘 가치가 있는 이유는 1인 개발자를 위한 출시 체크리스트에 더 자세히 나와 있습니다.