자기소개서

제가 제품을 만들 때 가장 중요하게 여기는 질문은 "사용자가 겪는 불편의 근본 원인은 무엇인가?"입니다. 겉으로 드러나는 현상을 바로 해결하려 하기보다, 사용자의 맥락·행동·환경을 구조적으로 분석해 뿌리를 정의하는 것이 제 방식의 중심입니다. '내마음속씨앗' 프로젝트가 그 대표적인 사례입니다. 저는 개인적으로 성경을 꾸준히 읽어보려 여러 시도를 했지만, 습관이 잘 정착되지 않았습니다. 이를 단순한 의지의 부족으로 보지 않고, "왜 이렇게 읽기 어려운가?"를 조사하며 문제를 거슬러 올라갔습니다. 분석 결과, 성경이 어려운 이유는 단지 종교적 거리감 때문이 아니라, 시대·문화·상황의 간극이었습니다. 수천 년 전 이스라엘·근동 지역의 사건과 맥락을 21세기 한국인이 이해하기는 근본적으로 어려웠고, 이 장벽이 '콘텐츠'로서의 성경 소비를 가로막고 있었습니다.

LLM에게 "쉽게 풀어줘"라고 하면 대부분 설교문처럼 출력됩니다. 하지만 기독교 커뮤니티에서 설교는 목회자의 고유 권한이기 때문에, AI가 설교를 모방하는 콘텐츠는 오히려 거부감을 유발할 수 있습니다. 저는 문제를 "콘텐츠를 어떻게 만들까"가 아니라, "사용자가 어떻게 성경과 부담 없이 접촉할 수 있을까"로 재정의했습니다. 그 결과, 설교형 접근이 아니라, 부담 없이 들을 수 있는 오디오 포맷인 팟캐스트라는 형식의 솔루션을 채택하게 되었습니다.

문제의 정의가 바뀌면, 해결도 달라지며, 이는 제가 Product Builder로서 가장 중요하게 생각하는 부분입니다.

저는 개발자를 목표로 개발을 배운 사람이 아닙니다. 문제를 해결하고 검증하는 과정에서 필요했기 때문에 익혔습니다. 기술은 저에게 목적이 아니라, 가설을 빠르고 정확하게 검증하기 위한 실험 도구였습니다.

'몰디브매치'에서도 같은 관점으로 접근했습니다. 몰디브 여행은 특수한 구조를 가진 시장입니다. 섬 하나가 곧 리조트이며, 숙박 기간 동안 이동이 불가능합니다. 즉, 여행 경험 전체가 단일 리조트의 품질에 의해 결정되는 '고관여, 고위험' 의사결정 구조입니다. 그러나 한국에서는 정보 채널이 대부분 여행사 중심으로 기울어 있고, 신혼여행 위주의 단발성 소비이기 때문에 강력한 피드백 시스템이 부재합니다. 결국 정보의 비대칭성이 구조적으로 극단적으로 큰 시장이었습니다.

리뷰 텍스트를 아무리 NLP로 정교하게 분석해도, 이러한 구조적 문제를 해결할 수 없다는 결론에 도달했습니다. 그래서 저는 230개 리조트의 데이터를 정제하고, 수천 개 리뷰를 구조적으로 분류하여 "사용자가 리조트를 선택할 때 고려하는 결정적 요인이 실제로는 6개로 수렴한다"는 사실을 발견했습니다.

그 지점부터 기술이 의미를 가졌습니다. 사용자가 자신의 선호를 가중치 형태로 입력하면, 요인 기반 추천 알고리즘이 최적 후보를 제시하는 구조로 설계했습니다.

기술은 화려함이 아니라, 사용자가 더 나은 결정을 할 수 있게 만드는 장치일 때 빛난다는 것을 배울 수 있었습니다.

뭉클랩에서 PO로 합류했을 때, 장사왕의 광고 분석 페이지는 쿠팡과 스마트스토어의 데이터를 스크래핑하여 숫자로 나열하는 대시보드 형태였습니다. GA4나 Airbridge와 구조적으로 다르지 않았습니다. 그런데 이런 도구들의 주 사용자는 데이터 분석가나 퍼포먼스 마케터 — 즉, 숫자를 보는 것이 일인 사람들입니다. 장사왕의 핵심 고객은 분석 역량이 없는 소규모 셀러(1인 또는 소규모 팀)였고, 이들에게 숫자 나열 대시보드를 주는 것은 UX 설계가 잘못된 것이라 판단했습니다.

셀러의 업의 본질은 "잘 파는 것"이지 "데이터를 분석하는 것"이 아닙니다. 그래서 제품의 방향을 "숫자 나열"에서 "다음 액션 제안"으로 전환했습니다. 기존 숫자 중심 대시보드를 Deep Layer로 유지하면서, 그 위에 룰베이스로 "무엇이 잘되고 무엇이 안 되고 있는지"를 자동 분류하는 Surface Layer를 얹었고, 다시 그 위에 LLM이 셀러별 데이터를 종합 분석하여 "다음에 뭘 해야 하는지"까지 제안하는 AI Layer를 설계·출시했습니다.

이 과정에서 장사왕의 북극성 지표는 "높은 재방문율과 짧은 체류시간"이라는 결론에 도달했습니다. 셀러가 매일 돌아오되, 오래 머물 필요 없이 바로 다음 액션을 알 수 있다면 — 셀러의 성과가 꾸준히 우상향하는 구조가 됩니다. 체류시간이 길다는 것은 오히려 제품이 답을 주지 못하고 있다는 신호입니다. 같은 데이터를 다루더라도, 고객이 다르면 제품의 형태와 성공 지표가 완전히 달라져야 한다는 것을 체득한 경험이었습니다.

뭉클랩에서 PO로 합류했을 때, 팀에는 스프린트 프로세스가 없었습니다. 백로그 우선순위도, 개발 일정의 예측 가능성도 부재한 상태였습니다. 저는 3개월이라는 짧은 기간 안에 스프린트 플래닝, 백로그 관리, 회고 프로세스를 도입해 팀의 개발 사이클을 체계화했습니다.

동시에 한 가지 실험을 병행했습니다. PO 업무 — 리서치, 기획 문서 작성, 검증 — 에 LLM 에이전트를 적용해본 것입니다. 처음에는 "ChatGPT에게 PRD 초안을 써달라"는 수준이었습니다. 효율은 올랐지만, 본질적인 변화는 아니었습니다. AI가 기존 워크플로우 위에 얹어지는 '도구'에 불과한 한, PO의 판단 구조 자체는 바뀌지 않았습니다.

이 경험에서 하나의 가설이 생겼습니다. AI를 기존 프로세스에 끼워넣는 것이 아니라, 워크플로우 자체를 AI 네이티브로 재설계하면 어떨까? PO의 업무를 역할 단위로 분해하고, 각 역할에 특화된 에이전트가 서로 다른 관점에서 교차 검증하는 구조를 만들면, 한 사람의 PO가 팀 수준의 판단 품질을 낼 수 있지 않을까?

이 가설이 사이드 프로젝트 Popilot의 출발점이 되었고, 이후 Corti 개발에 정식으로 적용되었습니다. 같은 모델이 역할만 바꿔가며 수행하는 것은 진짜 멀티에이전트가 아닙니다. 서로 다른 모델의 blind spot을 교차 활용할 때 비로소 객관적 검증이 가능해진다는 것을 실무에서 확인했습니다.

비엘큐에서 '테스트밸리'와 '퀵셀'을 운영하던 시절, "고가의 전자제품을 체험 후 구매 또는 반품 가능"이라는 서비스 구조는 겉보기에는 장점이 많아 보였습니다. 그러나 실제 데이터를 분석해보니, 체험 후 반품이라는 구조는 기대만큼 작동하지 않았습니다. 전자제품은 고관여 상품이고, 대부분의 사용자는 이미 유튜브 등의 커뮤니티를 통해 충분한 정보를 확보한 뒤 '구매 여부를 거의 결정한 상태'로 유입되었기 때문입니다. 반면 회사의 비즈니스 모델은 중고 재고가 늘어날수록 B2B 판매가 증가하는 구조였습니다. 따라서 서비스의 구조적 요구와 고객 행동의 실제 메커니즘이 서로 맞지 않는 근본적 모순이 존재했습니다. 이 모순을 해결하기 위해 재고 순환의 병목이 고객 퍼널이 아니라 재고 공급 구조 자체에 있다는 결론을 내렸습니다. 그래서 기존의 "반품"이라는 관점을 벗어나, 사용자에게 직접 "매입 신청"을 유도하는 구조를 제안했습니다. 이 관점 전환을 기반으로 중고 매입 전용 서비스 '퀵셀'을 설계, 출시하며 재고 확보량과 회전율을 전체적으로 높일 수 있었습니다.

이 경험은 기능이 아니라 시스템 단위로 문제를 재정의하고 설계하는 것의 중요성을 확고하게 만들었습니다.

뭉클랩에 PO로 합류했을 때, 팀에는 개발 프로세스라고 부를 만한 것이 없었습니다. 백로그는 있었지만 우선순위 기준이 불명확했고, 스프린트 단위의 계획이나 회고도 부재했습니다. 개발자들은 각자의 판단으로 업무를 진행하고 있었고, 기획자와 개발자 사이에 "다음에 뭘 해야 하는지"에 대한 공유 언어가 없었습니다.

저는 처음부터 무거운 프레임워크를 도입하지 않았습니다. 먼저 개발자 한 명 한 명과 대화하며 각자가 느끼는 병목이 무엇인지 파악했습니다. 문제는 역량이 아니라 정렬이었습니다. 팀원들은 충분히 유능했지만, "지금 가장 중요한 것이 무엇인지"를 합의하는 구조가 없었을 뿐이었습니다. 이 진단을 기반으로 주간 스프린트 플래닝, 백로그 우선순위 체계, 짧은 회고 루틴을 단계적으로 도입했습니다.

3개월이라는 짧은 기간이었지만, 팀의 개발 사이클에 예측 가능성이 생겼고, "왜 이걸 먼저 하는지"에 대한 공유된 맥락이 만들어졌습니다. 프로세스를 도입하는 것은 규칙을 만드는 일이 아니라, 팀이 같은 기준으로 대화할 수 있는 언어를 만드는 일이라는 것을 배웠습니다.

AI 기반 제품이 빠르게 등장하고 사라지는 시대입니다. 기술 성능만으로 성공하는 것도 아니고, UI만 좋다고 성공하는 것도 아닙니다. 제가 여러 프로젝트를 하며 배운 원칙은 하나입니다.

"AI 제품의 성공은 문제 정의 → 실험 설계 → 검증의 정확도에서 결정된다."

AI 모델을 선택하는 것보다 중요한 것은 '무엇이 문제인지', '해결해야 할 가설은 무엇인지', '어떤 실험을 통해 검증해야 하는지', '기술을 어떻게 비즈니스 언어로 번역할 것인지'입니다. 저는 앞으로도 이러한 영역에서 기여하고 싶습니다. 비즈니스의 문제를 AI가 풀 수 있는 형태로 구조화하고, PoC를 설계해 빠르게 검증하며, 사용자의 경험과 기술 아키텍처 사이의 간극을 좁히고, 시작부터 끝까지 "문제가 해결되는 방향"으로 제품을 이끄는 조직의 한 구성원이 되고 싶습니다.