퍼플프린트 시스템으로 퍼플프린트 서비스를 만들고 있다
3초 요약
- 퍼플프린트는 4월부터 지금까지 자기 설계 코치로 자기 서비스를 설계하고, 그 문서대로 만들고 고쳐 왔어요.
- 제품 모양이 웹앱에서 MCP 코치, 하이퍼 리뷰, 웹 코치로 바뀌어도 맨 위에서 정한 결정이 문서로 남아 있어 흔들림이 적었어요.
- 자기 도구를 자기에게 먼저 쓰면 고객보다 먼저 빈틈을 만나요. 그 빈틈을 고친 기록이 곧 업데이트예요.
옆에 앉아 돕던 방식에는 한계가 있었어요
퍼플프린트는 처음에 서비스가 아니었어요. 제가 쓰던 설계 방법을 문서와 규칙으로 묶어 둔 저장소였고, 저는 사람들 옆에 직접 앉아서 그걸 따라가게 도왔어요. 아이디어 한 줄에서 시작해 질문에 답하다 보면 누구를 위한 건지, 무엇을 먼저 만들지가 정리됐어요.
효과는 있었는데 문제가 하나 있었어요. 제가 옆에 있어야만 됐어요. 제 시간에는 한계가 있으니 더 많은 사람에게 닿을 수가 없었어요. 그래서 이 방법을 서비스로 만들기로 했어요. 그리고 그 서비스를 설계할 때도 같은 방법을 그대로 쓰기로 했어요. 시스템으로 시스템의 서비스를 설계하고, 설계한 대로 만드는 거예요.
설계 문서가 먼저 길을 정해 줬어요
제일 먼저 만든 건 코드가 아니라 문서였어요. 퍼플프린트가 유저에게 만들어 주는 문서를 우리 서비스에도 똑같이 만들었어요.
- •맥락문서: 누가 어떤 상황에서 겪는 어떤 문제를 푸는지
- •설계문서: 무엇부터 풀지, 핵심 기능, 어떻게 돈을 벌지
- •화면 흐름과 화면 구조: 처음 들어온 사람이 어디서 무엇을 하는지
- •디자인 기준: 색과 글꼴, 화면 부품의 규칙
- •알리는 계획과 개발 인계 문서: 누구에게 어떻게 알리고, 무엇부터 만들지
첫 웹앱은 금방 모양을 갖췄어요. 그런데 그 속도는 밤새 코드를 쳐서가 아니었어요. 누구를 위한 건지, 무엇을 만들지, 어떻게 보여 줄지, 어떤 순서로 만들지가 이미 문서에 있어서 만드는 동안 다음에 뭘 할지 고민할 일이 거의 없었어요. 빨라진 게 아니라 끊기지 않았던 거예요.
제품 모양이 몇 번 바뀌는 동안 남은 것
4월의 퍼플프린트는 아이디어 한 줄을 네 단계로 정리하는 웹앱이었어요. 지금은 많이 달라졌어요. 쓰던 AI 도구에 연결해 그 대화창 안에서 0~9단계를 이끄는 코치가 됐고, 기획서와 설계 문서를 39개 관점에서 점검하는 하이퍼 리뷰가 생겼고, 10월에는 설치 없이 쓰는 브라우저 웹 코치를 열었어요.
겉모양은 이렇게 바뀌었지만 바뀌지 않은 게 있어요. 무엇부터 정하는지의 순서, 정해야 할 게 나오면 후보와 추천과 고르지 않은 이유를 함께 보여 주는 방식, 정한 걸 문서로 남기는 것. 이 세 가지가 맨 위 문서에 적혀 있었기 때문에, 화면과 기술이 바뀌어도 "이게 맞나"를 다시 처음부터 따지지 않아도 됐어요.
고객보다 먼저 빈틈을 만나요
자기 도구를 자기에게 먼저 쓰면 좋은 점이 하나 있어요. 고객이 겪기 전에 제가 먼저 막혀요. 몇 가지는 꽤 아프게 배웠어요.
같은 걸 다시 묻는 코치
웹 코치로 처음 써 보는 사람처럼 한 벌을 진행해 봤을 때, 화면 흐름 단계에서 선택 카드를 160장 넘게 넘기고도 문서를 못 썼어요. 세어 보니 212장 중 73장은 앞에서 이미 정한 걸 다시 묻는 카드였어요. 질문을 하나씩 하라는 규칙이 항목 하나마다 카드 한 장으로 풀린 거예요. 그 뒤로 확인은 묶음으로 한 번 받고, 정한 건 다시 묻지 않게 고쳤어요.
첫 화면에서 떠나는 데모
데모를 처음 공개했을 때는 완성본부터 보여 줬어요. 문서가 다 찬 화면이 오히려 부담이 돼서 첫 화면에서 가장 많이 빠졌어요. 그래서 빈 프로젝트에서 시작해 한 턴씩 따라가는 데모로 바꿨어요. 이 이야기는 데모 글에 따로 적었어요.
연결한 뒤 안 보이는 코치
쓰던 AI 도구에 퍼플프린트를 연결하고도 도구 목록에 안 보여서 멈추는 분들이 있었어요. 대부분 앱을 한 번 다시 열면 보이는데, 그걸 모르면 연결이 실패한 줄 알아요. 그래서 설치 안내의 마지막 단계를 "앱 다시 열기"로 못 박았어요.
고친 것은 업데이트 기록으로 남겨요
빈틈을 고칠 때는 코드보다 설계 문서를 먼저 고쳐요. 코칭 규칙이 바뀌면 판 번호가 오르고, 같은 시험 대화를 바뀌기 전과 뒤로 다시 돌려 규칙별로 비교해요. 좋아진 것만 보지 않고, 다른 데가 나빠지지 않았는지도 같이 봐요. 유저가 체감하는 변화는 업데이트 기록에 날짜와 함께 남겨요.
한 AI가 만든 걸 같은 AI가 점검하면 같은 자리를 같이 놓치기 쉬워요. 그래서 큰 변경은 다른 AI에게도 따로 읽히고, 둘의 지적이 어디서 갈리는지 대조해요. 갈린 자리가 대개 다시 볼 자리예요.
이 기록이 쌓이면 그 자체가 증거가 돼요. 말로 "이 방법이 돼요"라고 하는 것보다, 그 방법으로 자기 서비스를 몇 달째 고치고 있다는 기록이 더 많은 걸 보여 주니까요.
만든 사람이라서 놓치는 것도 있어요
자기 도구를 자기에게 쓰는 데도 빈 곳이 있어요. 저는 퍼플프린트를 너무 잘 알아서, 처음 온 사람이 어떤 말에서 멈추는지 잘 못 느껴요. "MCP로 연결하세요"가 저에게는 한 줄이지만, 처음 듣는 분에게는 무슨 말인지부터 막혀요.
그래서 제 사용만 믿지 않아요. 처음 쓰는 분들을 직접 만나 화면을 같이 보고, 어디서 손이 멈추는지 옆에서 봐요. 온보딩 뒤 2시간쯤 지나면 이 제품의 가치가 확실히 전해지는데, 그 2시간까지 못 가는 분이 많다는 것도 그렇게 알았어요. 지금 창업자분들을 직접 돕는 일을 시작한 이유 중 하나도 그거예요. 돕는 동안 제가 놓친 자리가 계속 보여요.
느낌 대신 매일 아침 숫자를 봐요
고친 게 정말 도움이 됐는지는 느낌으로 알기 어려워요. 그래서 매일 아침 전날 숫자가 요약돼서 와요. 몇 명이 가입했고, 그중 몇 명이 첫 문서를 만들었고, 데모를 연 사람이 어디까지 따라갔는지 같은 것들이에요. 누가 무엇을 썼는지 내용은 보지 않고 건수만 봐요.
누군가 같은 자리에서 여러 번 막히면 그것도 따로 신호로 와요. 그러면 다음 작업을 시작하기 전에 그 신호부터 확인해요. 숫자가 적을 때는 비율에 흔들리지 않으려고 원래 건수를 같이 보고, 숫자로 이유를 알 수 없을 때는 직접 연락해 물어봐요. 기록은 무엇이 이상한지까지만 알려 주고, 왜인지는 사람을 만나야 알 수 있더라고요.
같은 방법을 내 서비스에 쓰려면
- •내 서비스를 내가 먼저 처음 쓰는 사람처럼 끝까지 써 본다
- •막힌 자리와 다시 물은 자리를 그때그때 적어 둔다
- •고칠 때는 화면보다 그 결정을 적은 문서를 먼저 고친다
- •고친 뒤에는 같은 상황을 다시 겪어 보고, 다른 데가 나빠지지 않았는지 본다
처음 쓰는 사람처럼 쓰는 게 생각보다 어려워요. 만든 사람은 어디를 눌러야 하는지 이미 알아서 막히지 않거든요. 그래서 저는 일부러 처음 고르는 답, 모르겠다는 답, 엉뚱한 답을 섞어서 써 봐요.
이 시스템이 진짜 되는지의 가장 직접적인 증거는, 그 시스템으로 자기 자신을 계속 고치고 있다는 기록이에요.
과정은 계속 공개할게요
무엇이 잘 됐고, 어디서 막혔고, 어떤 문서와 판단이 실제 제품으로 이어졌는지 앞으로도 이 블로그에 적을 거예요. 잘 된 이야기만 쓰면 따라 하는 분들이 같은 자리에서 또 막히니까요.
자주 묻는 질문
자기 도구로 자기를 만들면 객관성이 떨어지지 않나요?
맞는 걱정이에요. 그래서 하이퍼 리뷰로 따로 점검하고, 다른 AI에게도 교차 점검을 맡기고, 실제로 쓰는 분들의 말을 같이 봐요. 자기에게 먼저 쓰는 건 객관적인 평가를 대신하려는 게 아니라, 고객보다 먼저 막히려는 거예요.
퍼플프린트가 만든 문서를 직접 볼 수 있나요?
공개 데모에서 실제 웹 코치로 끝까지 설계한 프로젝트의 문서를 볼 수 있어요. 대화와 문서가 단계마다 어떻게 자라는지 처음부터 따라가 볼 수 있어요.
제 서비스에도 이 방법을 쓸 수 있나요?
네. 아이디어 단계라면 설계 코치로 문서부터 만들고, 이미 만든 서비스라면 하이퍼 리뷰로 빈틈부터 본 뒤 비어 있는 결정을 채우면 돼요.
지금 상황이 이렇다면
- 아이디어만 있다면, 웹 코치에서 한두 줄로 시작해 첫 설계 문서부터 만들어 보세요.
- 이미 만든 서비스가 있다면, 하이퍼 리뷰로 빈틈과 고칠 순서부터 확인해 보세요.
- 리포트를 받고 무엇부터 고칠지 막막하면, 리포트를 창업자 1,000명 직접 돕기로 보내 주세요. 퍼플프린트 창업자가 핵심 이슈와 방향을 직접 무료로 짚어 드려요.