[휴튼] 첫 앱을 만들기까지의 험난한 여정

생성AI를 활용하여 유저별 1:1 맞춤형 질문을 던져주는 휴튼의 앱이 드디어 출시되었습니다.

감사하게도 함께 PMC W23에 참여하고 있는 @David 님이 PMC 디스코드 채널에 샤라웃을 해주기도 하셨는데요, 오늘 메이커로그에서는 휴튼 앱을 처음으로 만들게 된 과정을 회고 형식으로 남겨보고자 합니다.

1. 앱이 '지금' 필요한가?

사실 저는 앱 개발을 최우선순위로 두지는 않았습니다. 휴튼은 기본적으로 글을 작성하는 서비스인데, 아무래도 모바일 환경에서는 기록에 집중하기 어렵기 때문이었죠. 저만 해도 모바일로는 아주 짧은 메모만 작성하고, 제 생각을 정리하는 긴 글은 무조건 PC로 작성하거든요.

그래서 휴튼의 기존 방식은, AI를 통해 생성한 각 유저별 1:1 맞춤형 질문을 일주일에 한번씩 이메일로 보내드리는 방식이었습니다. 나중에는 앱이 필요하겠다고 생각했지만, 서비스 특성상 우선순위가 높다고 생각하지는 않았습니다. 또, 앱 개발은 공수가 많이 들어가는 일이기 때문에 실험하듯 쉽게 시작해볼 수 있는 것도 아니었고요.

하지만 제가 앱을 만들어야겠다고 결심한 건 유저분들 때문이었어요. 제가 유저분들의 생각을 깊이 이해하지 못했다는 걸 깨달은 계기이기도 했습니다. 인터뷰를 통해 파악해보니, 유저분들은 실제로 이렇게 쓰고 있었습니다.

휴튼에서 던져주는 1:1 맞춤형 질문들이 정말 좋긴 한데, 곧바로 답하기에는 시간이 좀 걸림. 그래서 질문이 이메일로 오면 -> 메일을 열어보고 -> 메일에 있는 버튼을 클릭해서 휴튼 웹사이트로 이동하고 -> 거기에서 질문을 확인한 뒤 -> 그 질문에 대해 하루(며칠) 동안 생각을 해본 뒤에 -> PC로 들어와 글을 작성.

그러니까 유저분들에게는 '글 작성'에 앞서서 '질문 확인'이 더 중요했던 겁니다. 뒤돌아보니 당연한 것 같지만 당시에는 이 둘을 분리해서 생각해지 못했던 저의 실수였습니다.

2. 앱이 '지금' 필요하다!

다시 정리하면, 유저분들이 가치를 더 많이 느끼는 부분은 '질문에 답하며 생각을 정리하는 것'보다는 질문 그 자체였습니다. 내가 과거에 작성한 답변에 대해 어떤 후속 질문이 생성되었는지 확인하는 것이 더 중요했죠.

하지만 질문을 확인하기에는 이메일이라는 퍼널이 좀 긴 편이었습니다. 먼저 수많은 이메일 속에서 휴튼에서 온 질문을 찾아야 하고요, 이메일 안에 있는 버튼을 클릭해서 웹사이트로 이동해야 합니다. 그리고 무엇보다, 애초에 자동으로 스팸 처리가 되어 버리는 경우도 꽤 많아서 왜 Pro 멤버십을 구독했는데 메일이 오지 않냐고 물어보는 분들도 계셨습니다.

따라서 '휴튼AI의 질문을 쉽게 확인할 수 있도록 하기'를 위해서는 공수가 많이 들어도 앱 개발이 꼭 필요한 상황이었습니다. 유저가 가장 큰 가치를 느끼는 부분이니까요.

그리고 한 가지 더, 휴튼은 사실 심리적 장벽이 낮은 서비스는 아닙니다. 의도적으로 좋은 습관을 형성하기 위해 사용하는 서비스인 만큼, 인스타그램이나 유튜브처럼 별 생각없이 아무때나 들락날락 할 수 있는 서비스는 아니에요. 그렇기 때문에 접근성이 더더욱 중요했습니다. 앱이 웹보다 접근성이 좋다는 건 두말할 필요가 없구요.

3. 운명처럼 나타난 "그"

하지만 문제는 저는 웹 개발만 할 줄 알지 앱 개발에는 문외한이라는 것이었습니다. 이제 와서 앱 개발을 배울 수도 없는 노릇이고요(나중에 생각해보니 취미 삼아 배워보는 것도 재밌겠다는 생각은 했습니다). 따라서 앱 개발자를 구해야 했습니다.

여기서 파생된 또다른 큰 문제 두 가지는,

(1) 세상에는 앱 개발자가 차고 넘치지만 아직 휴튼의 미션에 공감하는 사람을 쉽게 찾을 수 있을 만큼 휴튼이 알려지지 않았다는 것,

(2) 앱 개발자에게 제가 물질적으로 줄 수 있는 게 없다는 것

이었습니다.

그때 운명처럼 제 오랜 개발자 친구인 @이승민이 발벗고 나서서 도와주겠다는 의사를 전했습니다. 이 친구야말로 두 가지 문제를 해소해줄 사람이었죠.

(1) 저를 오랫동안 봐왔기 때문에 제가 휴튼에서 어떤 미션을 실현시키고자 하는지 이해하고 공감하고 있었고,

(2) 이 친구도 앱 개발을 배우고 있던 시기였기 때문에 휴튼처럼 상대적으로 복잡한(가입/로그인, 결제, 멤버십 관리 등) 앱을 만들면서 배울 수 있는 게 많았다는 것

이렇게 이해관계가 맞아떨어지니 저희는 바로 앱 개발에 착수했습니다.

3.5. 무리한 요청

4로 넘어가기 전에, 제가 친구에게 부탁한 중요한 요청사항 하나를 소개드리려고 합니다. 바로 제 생일인 11월 4일에 맞춰서 앱을 내줄 수 있겠냐는 것이었습니다. 진짜 연예인병 걸린 관종 같지만, 주변 사람들과 휴튼 유저분들께 앱 출시 소식을 더 효과적으로 알릴 수 있는 장치가 필요했어요. "오늘이 제 생일인데 축하는 앱 다운로드로 해주세요!"라는 메시지를 여기저기 뿌릴 계획이었죠.

저는 2년 반 동안 두 개의 스타트업에서 PM으로 일했는데, 간혹 PM이 무리한 요청을 할 때 개발자의 표정 변화를 잘 알고 있습니다. 카톡이라 친구의 표정은 볼 수 없었지만 분명히 저한테 쌍욕을 하고 있었을 겁니다.

어쨌든 앱 개발을 도와주겠다고 한 것이 9월 말이었고 제 생일이 11월 4일이니, 한달이 조금 넘게 남은 상태였습니다. 아 물론 디자인도 나오지 않은 상태에서요.

4. Learning by doing

인생은 산 넘어 산이라고 했던가요. 저는 휴튼 웹 기획/디자인/개발을 모두 혼자 했기 때문에 '커뮤니케이션'이라고 할 것이 딱히 필요하지 않았습니다. 대충 손으로 와이어프레임 그리고, 구체적인 디자인은 개발하면서 수정해나가는 방식이었어요. 정책도 다 머릿속에 있었구요. 문서화는 사치였습니다.

하지만 제가 아닌 누군가와 협업을 할 일이 생기자, 더이상 손으로 5분만에 와이어프레임을 그려서 건네줄 수도 없고, 정책도 '다 알지?' 하면서 넘길 수가 없었습니다. 제품에 대한 sync and align이 필요한 시점이 찾아온 것입니다.

제가 디자인과 API, 그리고 세부 정책을 준비해놔야 친구가 앱 개발에 착수할 수 있기 때문에, 제가 부족한 부분을 빠르게 채우는 것이 중요했습니다. 그래서 피그마를 부랴부랴 배우고, 제가 웹에서 사용했던 Django 프레임워크에서 REST API를 만드는 법을 부랴부랴 배웠습니다. 다행히 배우는 속도가 빨라 뚝딱뚝딱 해냈습니다(잘 해냈는지는.....).

말 그대로 learning by doing이었어요. 길고 자세한 101 튜토리얼을 보고 앉아있을 시간이 없었기 때문에, 당장 뭐가 필요한지 빠르게 파악하고 그 내용에 대해 찾아본 뒤 빠르게 적용해보는 과정을 연속적으로 거쳤습니다.

5. 생각보다 너무 빠른 개발 속도

제가 세팅을 얼추 마친 뒤, 이제 친구가 달릴 차례였습니다. 그런데 친구의 개발 속도는 제가 생각했던 것보다 훨씬 빨랐습니다. 제 머릿속 계획으로는 한 달이라는 기간을 대략 이렇게 생각하고 있었거든요.

• 3주의 개발

• 0.5주의 QA

• 0.5주의 심사 및 마무리

그런데 친구는 2주도 되지 않아 기본적인 개발을 거의 다 마치고 심사 넣을 준비를 하고 있었습니다. 개발 다 마친 뒤에 같이 한번 보면서 QA도 꼼꼼히 하고 디자인도 수정하는 과정을 거치려고 했는데 말이에요. 하지만 위 계획은 앱을 0to1으로 만들어본 경험이 없는 사람의 착각이었습니다.

앱을 처음으로 출시한다면, 가장 큰 리스크는 심사입니다. 특히 애플놈들(사랑합니다)의 심사는 더더욱 큰 리스크입니다. 친구의 계획은 일단 기본적인 부분만 만들어서 심사 승인을 빨리 받아버리는 것이었습니다. 첫 심사만 까다롭고 그 이후에는 비교적 수월한 편이니, 일단 기본적인 기능만 잘 돌아가게 만든 뒤에 추가 부분은 그 뒤에 붙이자는 전략이었죠.

6. 적중한 전략

친구의 전략은 맞아 떨어졌습니다. 안드로이드는 허무할 정도로 쉽게 통과가 됐는데, 애플놈들(사랑합니다)은 여간 까다로운 게 아니었습니다. 앰플리튜드로 보면서 '이런 것까지 체크한다고?' 싶을 정도였어요. 그냥 QA를 맡겨도 되겠다고 생각했을 정도

그렇게 애플은 심사에 떨어지고 -> 수정해서 다시 올리고 -> 떨어지고 -> 그 사이에 추가로 개선하고 -> 수정해서 다시 올리고...의 연속이었습니다.

앱을 처음으로 출시하는 분들이 계시다면, 그리고 명확한 데드라인을 지켜야 한다면(생일처럼..), 이 부분을 꼭 염두에 두셔야 합니다. 애플에서 어떤 부분들을 문제 삼았는지에 대해서는 다른 메이커로그로 작성해 보겠습니다.

7. 생일 선물

그래서 결국, 제 생일 전날인 11월 3일 금요일 저녁에 앱 스토어 최종 승인이 났습니다. 물론 첫 승인은 그 전에 났지만, 그건 말씀드린 것처럼 말 그대로 '첫 승인만 받기 위함'이었고 그 이후에도 계속해서 수정하며 두세번 정도 추가 심사를 올렸던 것 같아요.

여담이지만, 최종 심사(라고 생각하고 올린 게) 11월 2일 목요일 밤이었는데 크리티컬한 이슈를 발견해서 11월 3일 금요일 오전에 다시 넣었습니다. 오늘을 넘기면 주말이라 여간 초조한 게 아니었습니다. 그런데 설상가상으로 11월 3일 오전~낮부터 애플에서 심사 제출이 되지 않는 이슈가 발생해서 친구와 저는 입술을 물어뜯으며 똥줄을 타다가 결국 오후가 되어 이슈가 해결되었고, 다행히 빠르게 승인이 나서 그날 밤에 앱 스토어에 올릴 수 있었습니다.

물론 주변에도 생일 축하를 명분으로 앱 출시를 효과적으로 알릴 수 있었고요.

Takeaways

1. (당연한 얘기이지만) 머릿속으로만 생각해서 판단하지 말고 꼭 유저와 대화를 하자 : 유저가 모든 정답을 알려주는 것은 아니지만 내 판단의 오류를 찾아줄 수 있습니다.

2. 이해관계를 잘 맞추자 : 저는 개발자 친구에게 줄 수 있는 것과 줄 수 없는 것이 명확했습니다. 개발자 친구 역시 원하는 것과 굳이 필요하지 않은 것이 명확했고요. 시작할 때 이걸 잘 얘기해두는 것이 중요한 것 같습니다.

3. Learning by doing : 속도가 중요할 때는 부채가 쌓일지라도 일단 몸으로 부딪히면서 배우자.

4. 앱 첫 출시를 한다면 심사도 린하게 : 애플놈들(사랑합니다)은 첫 심사를 무척 까다롭게 하기 때문에, 최대한 일찍 심사를 올리고 빠르게 수정하는 것이 리스크를 줄이는 방법입니다.

아 참, 휴튼 앱은 아래 링크에서 받으실 수 있습니다!

👉 📱 iOS / Android