Question 1

어떤 프로젝트와 가장 잘 맞나요?

Accepted Answer

사용자 의사결정 흐름이 핵심인 서비스와 잘 맞습니다. 핀테크, 결제·주문 퍼널, 온보딩 같은 곳이요. 사용자가 어디서 왜 망설이다 떠나는지 데이터로 쪼개 보는 걸 좋아해서, 그런 지점이 많은 서비스일수록 성과가 잘 나왔습니다. 결제 퍼널 개선(거래 횟수 28.3%↑)도 오픈뱅킹 입금(입금 횟수 101.9%↑)도 망설임 구간을 찾아 없앤 결과였습니다. 근거를 같이 보고 합의하는 문화라면 더 좋습니다. 데이터로 설득하고, 설득당하는 쪽을 선호합니다.

Question 2

협업 시 선호하는 방식은?

Accepted Answer

주 1회 짧게 모여 싱크를 맞추고 나머지는 문서로 남기는 방식을 선호합니다. 결정한 내용과 그렇게 정한 이유를 남겨두면 나중에 누가 봐도 맥락을 복원할 수 있으니까요. 방향이 모호할 때는 말로 설득하기보다 프로토타입을 먼저 만들어 같이 눌러보면서 합의합니다. 결제 퍼널을 바꿀 때도 시안 대신 실제로 동작하는 프로토타입으로 팀을 설득했습니다. 지표는 결과가 다 나온 후행 지표보다 지금 방향이 맞는지 미리 알려주는 선행 지표를 더 자주 봅니다.

Question 3

가장 자신 있는 역량은 무엇인가요?

Accepted Answer

모호한 문제를 검증 가능한 단위로 쪼개는 일입니다. 새 프로젝트에 들어가면 기능 리스트보다 지금 뭐가 왜 막혀 있는지부터 확인합니다. 결제 퍼널에서는 이탈이 몰리는 단계를 데이터로 찾아냈고, 1년 가까이 출시가 밀린 서비스에서는 우선순위를 정하는 사람이 없다는 게 진짜 문제라는 걸 확인하고 스코프부터 쳐냈습니다. 핀테크, 에듀테크, O2O, 웹3까지 도메인은 매번 달랐지만 문제를 쪼개는 방식은 같았고, 덕분에 어떤 도메인이든 처음부터 서비스를 세울 수 있었습니다.

Question 4

데이터와 직관 중 무엇을 더 믿나요?

Accepted Answer

가설은 직관으로 세우고 판단은 데이터로 합니다. 결제 퍼널을 개선할 때 처음 직관은 '이탈이 몰리는 화면을 다듬으면 된다'였는데, 단계별로 데이터를 뜯어보니 문제는 화면이 아니라 '결제 확정' 단계의 존재 자체였습니다. 그 단계를 없앴더니 거래 횟수가 28.3%, 거래 금액이 14.73% 늘었습니다. 직관만으로는 못 내렸을 결정입니다. 직관은 좋은 가설을 빨리 세우게 해주지만, 검증 없이 실행까지 가면 도박이 된다고 생각합니다.

Question 5

실패했거나 아쉬웠던 프로젝트가 있나요?

Accepted Answer

운영 프로세스가 전혀 없는 프로젝트를 맡았을 때, 급한 마음에 문서화를 미루고 실행부터 서두른 적이 있습니다. 팀원들이 같은 이야기를 서로 다르게 이해하고 있었고, 나중에 다시 맞추는 데 든 커뮤니케이션 비용이 아낀 시간보다 훨씬 컸습니다. 그 뒤로는 아무리 급해도 우선순위와 역할 정리를 먼저 하고 시작합니다. 느려 보여도 결국 그게 가장 빨랐습니다.

Question 6

AI 시대에 서비스 기획자의 역할이 뭐라고 생각하나요?

Accepted Answer

실행 비용이 떨어질수록 무엇을 왜 만들지 정하는 사람의 가치는 올라간다고 생각합니다. 예전에는 기획서를 쓰고 개발 리소스를 기다려야 검증할 수 있었지만, 지금은 직접 프로토타입을 만들어 바로 써볼 수 있습니다. AI 워크 OS, 포트폴리오 빌더 SaaS, 학교 현장에서 실제로 쓰이는 온라인 투표 플랫폼을 직접 기획·개발·배포하면서 검증 사이클을 며칠 단위로 줄였습니다. 기능을 만드는 속도는 AI가 계속 올려주겠지만, 문제를 정의하고 우선순위를 정하고 결과를 검증하는 판단은 여전히 사람 몫입니다.

Question 7

직접 개발도 하시는데, 개발자로 전향하려는 건가요?

Accepted Answer

아니요, 저는 기획자입니다. 개발은 기획을 빠르게 검증하는 수단이고요. 바이브 코딩으로 SaaS 두 개와 외주로 수주한 온라인 투표 플랫폼을 만들어 배포·운영해 봤는데, 얻은 가장 큰 자산은 코드보다 개발자의 관점이었습니다. 어떤 요구사항이 왜 비싼지, 어디서 일정이 밀리는지 이해하고 나니 기획 단계에서 미리 조율할 수 있게 됐습니다. 팀에서는 개발자와 같은 언어로 대화하고, 급할 때는 프로토타입을 직접 만들어 논의를 앞당기는 식으로 기여합니다.

Question 8

합류하면 첫 한 달 동안 무엇을 하나요?

Accepted Answer

기능 제안보다 현황 파악부터 합니다. 첫 1~2주는 지표와 퍼널, 팀이 지금 무엇에 막혀 있는지를 봅니다. 데이터가 있으면 데이터로, 없으면 CS와 리뷰, 팀 인터뷰로 확인합니다. 그다음 지금 가장 크게 멈춰 있는 것 하나를 정하고, 작게 검증할 수 있는 단위로 쪼개 첫 개선을 실행합니다. 1년 밀린 런칭을 정상화할 때도 결제 퍼널을 개선할 때도 순서는 같았습니다. 진단 없이 처방부터 하지 않는 게 첫 달의 원칙입니다.

Question 9

외주 프로젝트도 진행하시나요?

Accepted Answer

네, 기획부터 디자인·개발·배포·운영까지 한 번에 맡는 방식으로 진행합니다. 최근에는 학교 현장형 온라인 투표 플랫폼을 수주해 전 과정을 맡았습니다. 기존 수기 방식과 비교해 20학급 선거 1회 기준 운영 시간이 약 5시간 20분 줄어들게 설계했고, 배포 후에도 운영하면서 화면을 계속 다듬어 사용법 문의 전화가 고도화 전보다 75%(4통에서 1통으로) 줄었습니다. 규모가 크지 않아도 문제 정의부터 운영 개선까지 빠르게 도는 프로젝트라면 잘 맞습니다. 연락처 페이지로 편하게 문의 주세요.