pmjigu

[회고] 좋은 제품을 만드는 것과 선택받는 것은 달랐다

pmjigu — Tue, 21 Jul 2026 12:48:39 +0900

웹 서비스를 기획하고 출시하고 운영하며 가장 크게 배운 것

하나의 웹 서비스를 초기 기획부터 출시, 운영까지 경험했다.

문제를 정의하고, 기능을 정하고, 화면을 설계했다. 출시 이후에는 실제 사용자의 반응을 살피며 불편한 지점을 고쳤다. 서비스가 만들어지고 운영되는 전 과정을 지나고 나니 여러 배움이 남았지만, 가장 크게 느낀 점은 제품의 완성도만으로는 서비스가 성장하지 않는다는 것이었다.

돌이켜보면 우리는 서비스 안에서 일어나는 일에 지나치게 집중했다고 본다.

사용자가 더 편하게 이용하려면 어떤 기능이 필요한지, 화면의 구조는 자연스러운지, 사용자 흐름에서 걸리는 부분은 없는지 혹은 적절한지를 계속 고민했다. 이런 개선이 쌓이면 제품의 만족도가 높아지고, 그 결과 사용자가 자연스럽게 늘어날 것이라고 생각했다. 물론 서비스 내부의 경험을 다듬는 일은 중요하다.

다만 운영을 이어가며 알게 된 것은, 어쩌면 당연하게도 제품을 잘 만드는 일과 그 제품이 시장에서 발견되는 일은 서로 다른 문제라는 점이었다.

우리는 언덕 위 빵집의 진열대만 고치고 있었다

이 경험을 빵집에 비유하면 이해하기 쉬울 것 같다.

이미 빵집이 많은 한 마을에 넉넉하지 않은 자본으로 가게를 열다 보니 사람들이 많이 오가는 거리가 아니라, 일부러 찾아가야 하는 언덕 위에 빵집을 열었다고 해보자. 손님이 기대만큼 오지 않자 손님이 들어오기 편하게 문을 수리하고, 빵이 잘 보이게 진열대를 다시 배치하고, 간판의 디자인을 바꾼다. 가게에 들어온 사람에게는 분명 더 좋은 경험을 줄 수 있다. 그러나 빵집이 있는지도 모르는 사람에게는 달라지는 것이 없다.

아무리 특별하고 맛있는 빵을 준비했더라도 사람들은 우연히 언덕을 오르지 않는다. 어떤 빵을 파는 곳인지, 왜 찾아갈 만한지, 그곳에서 어떤 경험을 할 수 있는지를 먼저 알려야 한다.

우리 서비스도 비슷했다. 이미 방문한 사용자의 경험을 개선하는 데에는 많은 시간을 들였지만, 아직 서비스를 모르는 사람에게 어떻게 존재를 알릴지, 어떤 이유로 관심을 갖게 할지, 왜 다른 서비스가 아니라 우리를 선택해야 하는지, 우리릉 어떻게 소개할지 등에 대해서는 충분히 설계하지 못했던 것이다.

좋은 제품만으로 선택받기 어려운 시장

지금의 서비스 시장은 이미 많은 제품으로 채워져 있다.

하나의 도메인 안에서도 오랫동안 사용자를 확보한 대표 서비스가 있고, 특정 기능을 더 편리하게 만든 서비스도 있으며, 비슷한 문제를 각기 다른 방식으로 해결하는 제품도 계속 등장한다.

신규 고객의 입장에서는 새로운 서비스가 나왔다는 사실만으로 이를 사용해 볼 이유가 크지 않다. 이미 익숙하게 쓰는 제품이 있고, 그 안에 기록과 데이터, 관계와 사용 습관이 쌓여 있기 때문이다. 새로운 서비스를 이용하려면 기존의 방식을 멈추고, 다시 가입하고, 낯선 화면을 익혀야 한다. 만드는 사람에게는 간단해 보이는 몇 단계가 사용자에게는 굳이 넘어야 할 이유가 없는 장벽이 될 수 있다. 기능이 조금 더 많거나 사용성이 조금 더 좋다는 이유만으로 기존 제품을 떠나는 사람도 많지 않다. 현재 쓰는 서비스가 크게 불편하지 않다면, 대부분은 익숙한 선택을 유지한다.

같은 분야에 여러 대안이 존재할수록 차이는 더 빠르고 명확하게 전달되어야 한다고 생각한다.

사용자는 모든 제품을 직접 체험하고 비교하지 않는다. 평소 자주 접한 이름, 주변의 추천, 한눈에 이해되는 메시지처럼 판단하기 쉬운 단서를 바탕으로 선택한다.

제품 안에 좋은 기능이 있어도 서비스 밖에서 그 가치가 보이지 않으면, 사용자에게는 수많은 비슷한 선택지 중 하나일 뿐인 것이다.

우리는 사용자가 서비스에 들어온 이후의 흐름은 세밀하게 살폈지만, 그 이전 과정은 충분히 보지 못했던 것 같다. 사람들이 어디에서 서비스를 처음 접하는지, 무엇을 보고 관심을 갖는지, 기존 제품을 두고 이동할 만큼 어떤 차이가 있는지를 더 깊게 고민했어야 했다. 제품을 만드는 일은 화면 안에서 끝나지 않는다. 사용자가 서비스를 발견하고, 필요성을 이해하고, 직접 사용해 보기로 결정하는 과정까지 제품의 일부로 보아야 하는 것이 중요하지 않을까.

기능은 복제되지만 관계는 쉽게 옮겨지지 않는다

운영을 하며 기능만으로 시장에서 경쟁력을 오래 유지하기 어렵다는 점도 느꼈다.

좋은 기능을 먼저 출시해도 비슷한 기능은 빠르게 등장한다. 특히 AI를 활용해 제품을 만드는 속도가 빨라지면서, 구현 자체가 차별점으로 남는 기간은 더 짧아졌다. 물론, 기능이 중요하지 않다는 의미는 아니다. 다만 기능 하나만으로 사용자가 계속 머무를 이유를 만들기는 어렵다는 뜻에 가깝다.

그래서 서비스가 오래 성장하려면 복제하기 어려운 기반이 필요하다고 생각이 들었다. 나는 그중 하나가 서비스 안에서 만들어지는 관계라고 생각한다.

창작자와 사용자가 연결되고, 사용자끼리 경험을 공유하고, 활동의 결과가 다시 새로운 참여로 이어지는 구조는 화면이나 기능을 따라 만드는 것만으로 재현하기 어렵다. 시간이 지나며 쌓인 신뢰와 문화, 이용자 간의 연결은 다른 서비스로 쉽게 옮겨지지 않는다.

중요한 것은 단순히 사람을 많이 모으는 것도 아니다. 사용자가 원하는 콘텐츠와 사람을 제대로 연결하고, 그 관계가 계속 이어질 이유를 만드는 것이 더 중요하다는 생각이 든다.

다음에는 유입 이후의 관계까지

이번 프로젝트를 통해 다음 서비스를 만든다면 무엇을 다르게 해야 할지도 조금은 분명해졌다.

기획 초기부터 기능, 디자인, 사용성뿐 아니라 유통을 함께 고민해야 한다. 누가 이 서비스를 가장 필요로 하는지, 그 사람은 어디에 있는지, 어떤 메시지를 통해 서비스의 가치를 이해할 수 있는지까지 제품 전략 안에 포함해야 한다. 유입 이후의 흐름도 달라야 한다. 사용자가 한 번 방문해 콘텐츠를 이용하고 떠나는 데서 끝나는 서비스가 아니라, 다시 돌아올 이유가 있고 누군가와 관계를 맺을 수 있는 구조를 만들고 싶다.

특히 창작자와 사용자의 관계가 쌓이고, 이용자가 단순 소비자를 넘어 참여자와 팬으로 이어지는 플랫폼을 고민해 보고 싶다.

이를 위해서는 콘텐츠를 보는 경험을 넘어, 좋아하는 대상에 대한 반응과 기록이 서비스 안에 남아야 한다고 생각한다. 이용자가 자신의 취향을 표현하고, 비슷한 관심을 가진 사람들과 연결되며, 창작자 역시 팬의 반응을 지속적으로 확인할 수 있어야 하지 않을까.

결국 앞으로는 콘텐츠를 보고 나가는 데서 끝나는 서비스가 아니다. 이용자가 좋아하는 창작자를 계속 팔로우하고, 콘텐츠에 반응하고, 다른 팬들과 이야기를 나누며 다시 방문할 이유가 생기는 공간을 만들고, 그런 곳에 합류하여 함께 성장하고 싶다.

영어 회화 공부를 시작한 이유: 1:1 학원과 오픽 IH 목표

pmjigu — Tue, 7 Jul 2026 17:19:24 +0900

변화

최근 들어 영어를 조금 더 유창하게 구사하고 싶다는 생각이 들었다. 자연스럽게 영어 회화 공부의 필요성도 느끼게 되었다.

이전 직장에서도 해외 서비스 런칭을 위해 필드 테스트를 진행하며 영어를 사용해야 하는 상황은 있었다. 다만 당시에는 함께 소통하던 개발자와 현지 엔지니어 모두 한국어가 가능한 상황이었다. 소프트 런칭 때 우리 서비스를 이용해주신 고객분들을 만나기도 했지만, 가벼운 질문을 통해 반응을 파악하는 정도로 영어를 사용했다.

그런데 이번 직장에서는 영어를 사용해야 하는 빈도와 필요성이 조금 더 커졌다. 콘텐츠진흥원 등에서 진행하는 해외 부스에 나가 해외 유저들을 직접 만나고, 서비스와 이벤트에 대해 설명하고, 질문에 답하는 일이 많아졌다. 단순히 정해진 문장을 말하는 것이 아니라, 현장에서 만난 유저들과 자연스럽게 대화해야 하는 순간들이 생겼다.

그 과정에서 영어를 조금 더 잘했다면 좋았겠다는 생각을 자주 하게 되었다.

물론 나는 아주 기본적인 대화는 할 수 있다. 하지만 대화가 조금만 깊어지거나 예상하지 못한 질문을 받을 때면 한계를 느꼈다. 사용자의 반응을 더 자세히 파고들고 싶었고, 그들이 어떤 문화적 맥락 안에서 어떤 경험들을 하고 있는지 알고 싶었다. 그런데 막상 그 순간이 오면 하고 싶은 말이 머릿속에만 머무는 경우가 많았다.

목적과 이유

내가 영어 공부를 본격적으로 시작하려는 이유는 단순히 영어를 잘하고 싶어서라기보다, 결국 영어로 더 자유롭게 말하고, 더 깊이 이해하고 싶었기 때문이다.

처음에는 단순히 머릿속에 떠오르는 말을 영어로도 자연스럽게 하고 싶다는 생각이 컸다. 해외 유저를 만났을 때 하고 싶은 말이 바로 나오고, 예상하지 못한 질문에도 당황하지 않고 답할 수 있으면 좋겠다고 생각했다. 기본적인 대화에서 멈추지 않고, 조금 더 편하게 질문하고 설명할 수 있는 회화 자신감이 필요했다.

그런데 조금 더 생각해보니, 내가 진짜 영어 회화를 공부해야겠다고 결심한 이유는 거기서 끝나지 않았다. 영어를 더 잘 구사할 수 있다면 같은 경험을 하더라도 훨씬 더 깊이 이해하고 느낄 수 있겠다는 생각이 들었다.

나는 원래 문화를 소비하고 이해하는 것을 좋아하는 사람이다. 여행을 가더라도 유명한 관광지만 돌거나, 흔히 말하는 필수 쇼핑 리스트를 따라가는 것보다는 그 나라의 문화를 직접 경험하는 쪽을 더 좋아한다. 예술과 패션, 식문화처럼 그 나라의 분위기와 사람들이 살아가는 방식이 드러나는 것들에 관심이 많다.

예를 들면 파리에서는 내가 좋아하는 낭만주의 시대의 작품을 보기 위해 루브르 박물관과 오랑주리 미술관에 가기도 하고, 지금 프랑스에서 주목받는 작가의 전시는 무엇인지 찾아보고 가기도 한다. 카페에 앉아 사람들이 어떤 옷을 입고, 어떤 방식으로 시간을 보내는지 구경하는 일도 좋아한다. LA나 샌프란시스코에 갔을 때는 사람들이 주말을 보내는 방식, 동네마다 다른 분위기, 거리에서 느껴지는 자유로운 패션과 문화를 보는 것이 흥미로웠다. 토론토에서는 다양한 문화가 섞인 도시의 분위기와 사람들이 먹는 음식, 시드니에서는 바다와 가까운 일상과 여유 시간을 보내는 방식이 눈에 들어왔다. 현지인들은 여유 시간에 무엇을 하는지 보고 직접 경험해보는 것, 자주 가는 식당을 물어보고 가서 먹어보는 것, 왜 이런 식문화와 생활 방식이 생겼는지 궁금해하는 것들이 나에게는 여행의 중요한 부분이다.

단순히 “여기가 유명하다더라”, “이 음식이 맛있다더라”에서 끝나는 것이 아니라, 왜 이곳에서는 이런 문화가 생겼는지, 사람들은 이 문화를 어떻게 받아들이고 있는지 알고 싶다. 알아보고, 이해하고, 경험하고, 느끼는 과정 자체를 좋아한다.

그런데 이런 경험을 할 때마다 언어의 차이가 꽤 크게 느껴졌다. 지금의 짧은 영어로도 현지인들과 짧게 대화를 나누며 새롭게 알게 되는 것들이 있었다. 추천받은 식당에 가서 메뉴에 대해 물어보거나, 이 동네 사람들은 주말에 주로 무엇을 하는지 듣거나, 어떤 전시가 요즘 인기 있는지 물어보는 것만으로도 여행의 밀도가 달라졌다.

그래서 오히려 더 아쉬웠다. 짧은 대화만으로도 이렇게 새롭게 느껴지는 것들이 있는데, 내가 조금 더 자연스럽게 말할 수 있었다면 얼마나 더 많은 것을 듣고 이해할 수 있었을까 하는 생각이 들었다. 단순히 필요한 말을 전달하는 것을 넘어, 그들의 일상과 취향, 문화적 맥락을 조금 더 깊게 나누고 싶었다.

기획자로서도 이 부분은 중요하게 느껴졌다. 결국 서비스를 만드는 일은 사람을 이해하는 일이고, 사용자가 어떤 환경에서 서비스를 쓰는지, 어떤 부분에서 불편함을 느끼는지, 어떤 기대를 가지고 있는지 직접 듣는 과정이 필요하다고 생각한다. 특히 해외 유저를 만나는 순간에는 언어가 그 이해의 깊이를 결정하는 경우가 있었다. 그 나라 사람들이 어떤 콘텐츠를 좋아하는지, 어떤 방식으로 여가를 보내는지, 무엇을 자연스럽게 받아들이고 무엇을 낯설게 느끼는지는 실제 대화와 경험 속에서 더 잘 보이는 경우가 많다.

결국 내가 영어 공부를 통해 얻고 싶은 것은 단순한 시험 점수나 스펙이 아닌 것이다.

내가 좋아하는 문화를 더 깊게 이해하고, 다양한 국가의 유저들과 더 자연스럽게 대화하고, 더 넓은 시장과 사람을 입체적으로 바라볼 수 있는 힘에 가깝다.

대안과 선택 이유

영어 회화 공부를 시작하기 위해 내가 선택한 방법은 1:1 영어회화 학원이었다.

처음부터 학원을 생각했던 것은 아니다. 처음에는 혼자 공부했다. 지난 출장과 여행에서 내가 하고 싶었지만 말하지 못했던 것들, 답하고 싶었지만 바로 표현하지 못했던 상황들을 따로 적어두었다. 그리고 그 상황에서 현지인들은 어떻게 더 자연스럽게 말하는지 궁금해 한국에 돌아와 유튜브나 미드를 찾아보며 표현을 따라 해보기도 했다. 예를 들면 부스에서 유저가 예상하지 못한 질문을 했을 때 어떻게 답하면 좋을지, 여행 중 현지인에게 식당에서 음식이 어땠는지, 전시를 보니 어떤지 물어보면 뭐라고 답변 할지 부터. 스몰토킹을 할 때 꺼내면 좋을 만한 주제까지. 실제로 내가 겪었던 상황을 바탕으로 공부하다 보니 처음에는 꽤 흥미롭게 느껴졌다.

하지만 시간이 지나면서 금방 한계가 느껴졌다. 생각보다 나는 의지가 강한 사람이 아니었는지, 아니면 한국에 돌아온 뒤 영어를 써야 하는 환경이 사라져서인지, 다시 느슨해지는 내 모습을 보게 되었다. 영어 공부가 필요하다는 생각은 계속 있었지만, 당장 하지 않아도 큰일이 나는 것은 아니었기에 우선순위에서 자꾸 밀렸다. 그래서 다른 방법을 찾아보기 시작했다.

선택지는 여러 가지가 있었다. 영어 회화 앱을 사용할 수도 있었고, 대형 어학원에 다닐 수도 있었다. 1:1 학원을 등록하는 방법도 있었고, 스터디 모임에 참여하는 방법도 있었다. 각각 장단점은 있었지만, 내가 원하는 조건은 비교적 명확했다.

첫 번째는 반강제로라도 영어 공부를 주기적으로 해야 하는 환경이어야 했다. 혼자 하면 쉽게 미뤄지는 나를 이미 확인했기 때문에, 일정한 시간에 영어를 말해야 하는 구조가 필요했다.

두 번째는 내가 영어를 쓰고 싶은 상황에 맞춰 연습할 수 있어야 했다. 단순히 정해진 교재를 따라가는 것보다, 나의 생각, 나의 취미, 내가 자주 놓이는 상황을 중심으로 말해보고 싶었다. 또 내가 자주 쓰는 표현, 발음, 말하는 습관에 대해서도 직접적인 코칭을 받고 싶었다.

세 번째는 영어에 대한 자신감을 조금씩 채울 수 있는 환경이어야 했다. 나는 영어를 아예 모르는 것은 아니지만, 막상 말하려고 하면 머릿속에서 문장이 멈추는 경우가 많았다. 그래서 틀리더라도 계속 말해보고, 그 안에서 조금씩 나아지고 있다는 감각을 느낄 수 있는 환경이 필요했다.

이 조건들을 놓고 보니 선택은 어렵지 않았다. 가격적으로는 가장 부담이 있는 선택지였지만, 지금 나에게는 1:1 학원이 가장 잘 맞는 방법이라고 생각했다.

그리고 영어 회화 실력을 늘리는 것이 가장 큰 목적이지만, 단기적으로는 오픽 IH 등급을 목표로 세웠다. 점수 자체가 최종 목적은 아니지만, 나는 목표를 정하고 그것을 달성했을 때 동기부여를 느끼는 편이다. 막연히 영어를 잘하고 싶다는 마음만으로는 쉽게 흐려질 수 있으니, 우선은 오픽 IH라는 기준을 하나 세워두고 그 과정 안에서 영어로 말하는 시간을 늘려보기로 했다.

앞으로

앞으로는 영어 공부를 해나가는 과정도 하나씩 기록해보려고 한다.

아직 시작 단계라 얼마나 빠르게 늘지는 모르겠다. 분명 말이 잘 나오지 않아 답답한 날도 있을 것이고, 생각보다 더디게 느껴지는 순간도 있을 것이다. 그래도 이번에 그 과정까지 남겨보고 싶다. 잘한 것만 남기기보다는 틀렸던 표현, 말문이 막혔던 순간, 조금씩 나아졌다고 느낀 순간, 극복한 방법도 함께 적어보고 싶다.

영어 공부를 시작한 이유는 결국 더 잘 말하기 위해서이기도 하지만, 더 깊이 이해하기 위해서다. 느리더라도 꾸준히 말해보고, 배우고, 다시 기록해보려고 한다.

AI 시대에도 기회는 꼭 AI에만 있지 않다 : 시장의 불편함

pmjigu — Thu, 2 Jul 2026 15:04:12 +0900

요즘 어디를 봐도 당연한듯 AI 이야기다.
AI 에이전트, 자동화, 생성형 AI. 새로운 서비스를 고민할 때도 자연스럽게 “여기에 AI를 붙일 수 있을까?”부터 생각하는 모습을 쉽게 볼 수 있다.

그런데 가끔은 이렇게 좁아진 시야에 환기가 필요하지 않나 싶다.
모두가 AI를 바라볼 때, 아직도 전화와 엑셀과 감으로, 그리고 주먹구구식으로 돌아가는 시장은 어디인지 보는 것. 어쩌면 그곳에 더 현실적인 기회가 있지 않을까?

이런 생각을 들게 한 사례가 루트릭스다.

루트릭스는 조경 수목 유통을 데이터화하는 스타트업이다. 쉽게 말하면 나무를 사고파는 시장의 정보를 정리하는 회사다. 전국 수목 농장의 데이터를 모아 어떤 농장에 어떤 나무가 있는지, 규격은 어떤지, 수량과 가격은 어떻게 되는지를 확인할 수 있게 만든다.

솔직히 처음 들으면 요즘 사람들의 이목을 집중할 아주 화려한 사업처럼 느껴지지는 않는다. 나무, 조경, 농장, 중개. 스타트업보다는 오래된 산업에 더 가깝게 느껴지는 단어들이다. 그런데 오히려 이 지점이 흥미로웠다.

자세히 보면 오래된 시장일수록 데이터가 비어 있는 경우가 많다. 누가 무엇을 가지고 있는지, 가격이 적정한지, 어떻게 구매해야 하는지, 지금 구매 가능한 수량이 있는지조차 명확하지 않다. 그러다 보니 구매자는 계속 전화를 돌리고, 판매자는 아는 사람 중심으로 거래하고, 중개자는 발로 뛰며 정보를 연결한다.

이런 시장에서 고객이 원하는 건 대단히 복잡한 기술이 아니지 않을까?
필요한 건 의외로 단순할 것이다.

어떤 상품, 그러니까 어떤 나무가 있는지, 얼마인지, 몇 주를 살 수 있는지, 어떻게 살 수 있는지, 사진으로 상태를 확인할 수 있는지.

결국 고객은 멋진 기술보다 “바로 살 수 있는 정보”를 원할 것 같다.

이 부분이 기획자인 나로서는 꽤 중요하게 느껴졌다. 좋은 서비스에 대한 정의는 각자 다를 수 있겠지만, 흔히 말하는 좋은 서비스는 꼭 새로운 기술에서만 출발하지 않는 것 같다. 오히려 누군가 매일 반복해서 겪는 불편함, 매번 전화로 해결하는 일, 엑셀과 경험에 의존하는 업무 속에서 출발하는 경우가 많다.

그 불편하고 복잡하지만 어느새 당연해진 부분을 찾아, 조금 더 간편한 방식으로 바꾸는 것이 내가 해야 할 일이 아닐까. AI가 아무리 발전해 많은 일을 대신해준다고 해도, 데스크 리서치부터 현장에 나가 고객의 경험을 직접 따라가 보는 일은 여전히 필요하다고 생각한다.

루트릭스 사례를 보면서 다시 생각하게 됐다.
AI 시대에도 돈이 되는 문제는, 고객들이 정말 원하는 문제는 꼭 AI 문제가 아닐 수 있다고.

데이터가 없는 시장.
정보가 흩어져 있는 시장.
사람이 직접 발로 뛰어야만 굴러가는 시장.
고객이 매번 같은 질문을 전화로 반복해야 하는 시장.
프로세스가 제대로 정리되어 있지 않은 시장.

이런 곳에 오히려 우리가 볼 수 있는 기회가 있다. 그리고 이런 기회 앞에서는 AI 기능을 먼저 떠올리기보다, 먼저 물어봐야 할 질문들이 따로 있는 것 같다.

“아직도 비효율적으로 돌아가는 시장은 어디인가?”
“정보가 없어서 모두가 불편한 산업은 어디인가?”
“사람들이 당연하게 참고 있는 불편은 무엇인가?”

기획은 유행어를 붙이고 따르는 일이 아니라, 문제를 발견하고 구조를 바꾸는 일에 가깝다고 생각한다.

그런 의미에서 루트릭스가 나무 시장에서 발견한 기회는 꽤 인상적이다. 모두가 AI를 외치는 시대에도, 아직 데이터가 없는 시장에는 여전히 큰 기회가 숨어 있다고 생각한다. 그리고 요즘은 나 역시 이 부분에 대해 조금씩 더 고민하게 된다.

[기획] AI 시대에서 좋은 프롬프트보다 중요한 것

pmjigu — Fri, 15 May 2026 15:57:01 +0900

출처 : 나무위키

AI에게 묻기 전에

이제는 AI를 활용해 일하는 것이 너무 자연스러워졌다. 예전 같으면 혼자 자료를 찾아보고, 생각을 정리하고, 어떤 방향으로 접근할지 한참 고민했을 텐데 요즘은 조금 달라졌다. 어느 순간부터는 내 생각을 먼저 정리하기보다, AI에게 넣을 프롬프트를 작성하고 있는 나를 보게 된다.

아마 많은 분들이 비슷하게 느끼지 않을까 싶다.
일단 AI에게 상황을 공유하고, 기획을 하다가 막히면 AI에게 물어본다. 시장 조사가 필요하면 정리해달라고 하고, 문서의 구조가 필요하면 초안을 만들어달라고 한다. 이제 AI는 특별한 도구라기보다 일을 시작할 때 자연스럽게 켜두는 기본 도구에 가까워졌다.

그런데 AI를 쓰다가 초반에 느끼는 것이 있다.
AI에게 어떤 질문을 던지느냐에 따라 답변의 방향이 완전히 달라진다는 점이다.

이제 많은 사람들이 AI를 잘 쓰는 방법을 알고 있다. AI에게 역할을 부여하고, 조건을 구체적으로 적고, 원하는 형식을 지정하고, 예시를 함께 넣는 식이다. 실제로 이런 방식은 꽤 도움이 된다. 같은 질문이라도 프롬프트를 어떻게 쓰느냐에 따라 답변의 품질이 달라지기 때문이다. 그래서 좋은 프롬프트를 찾아보고, 서로 공유하는 모습도 자주 보인다.

하지만 최근 들어 기획 등 업무에서 AI를 쓰다 보니, 그보다 앞에 있어야 하는 것이 있다는 생각이 들었다.
결론부터 말하면, AI를 잘 쓰기 위해 가장 먼저 필요한 것은 좋은 프롬프트 문장이 아니라 내가 지금 하고 있는 기획의 목적과 목표를 제대로 이해하는 일이다.

내가 풀고 싶은 문제가 무엇인지.
그 문제가 누구의 어떤 문제인지.
이번 작업을 통해 어떤 결과물을 얻고 싶은지.
그리고 최종적으로 어떤 형태의 결과물을 발행하거나 전달해야 하는지.

이 질문들이 정리되지 않은 상태에서 AI에게 물어보면, 답변은 그럴듯하지만 실제 기획에는 잘 붙지 않는 경우가 생각보다 많았다. 정보는 많고 문장은 매끄럽지만, 정작 내가 결정해야 하는 문제와는 조금씩 어긋나 있는 것이다.

시행착오 1. AI에게 3가지 확인하기

여기까지 오기 전에는 나름의 시행착오가 있었다. (앞으로도 시행착오가 많고 변하겠지만 말이다..ㅎㅎ)
처음에는 AI를 잘 쓰기 위해서는 질문을 잘하는 것이 가장 중요하다고 생각했다. 그래서 어떤 역할을 부여하면 답변이 더 좋아지는지, 조건을 어떻게 달아야 원하는 형식으로 나오는지, 어떤 순서로 요청해야 더 쓸 만한 답이 나오는지를 계속 시도했다.

그런데 몇 번 반복하다 보니, 질문을 잘하는 것만으로는 부족하다는 생각이 들었다.
질문 자체는 꽤 구체적으로 적었는데도, 막상 나온 답변을 기획에 붙이려 하면 어딘가 어긋나는 경우가 있었기 때문이다.

예를 들어 시장 조사를 요청했는데 내가 실제로 필요했던 것은 시장 규모가 아니라, 지금 이 시장에서 사용자 행동이 어떻게 바뀌고 있는지에 가까울 때가 있었다. 경쟁사 분석을 요청했지만, 정작 알고 싶었던 것은 기능 경쟁사의 기능 목록이 아니라 그 서비스가 어떤 문제를 먼저 풀고 있는지였던 적도 있었다.

돌이켜보면 AI의 답변이 틀렸다기보다는, 내가 무엇을 얻고 싶은지 충분히 정리하지 않은 상태에서 질문을 던진 것이다.

그래서 어느 순간부터는 AI에게 질문하기 전에 먼저 세 가지를 확인하려고 했다.

누구의 어떤 문제를 풀 것인가.
이번 작업을 통해 어떤 결과물을 얻고 싶은가.
최종적으로 어떤 형태로 발행하거나 전달할 것인가.

이 세 가지가 정리되지 않으면 ChatGPT를 쓰든, Claude를 쓰든 결과는 크게 달라지지 않았다. 물론 도구마다 답변의 스타일과 강점은 다르다. 어떤 도구는 구조화가 좋고, 어떤 도구는 문맥을 길게 끌고 가는 데 강하다. 하지만 기획에서 더 중요한 것은 어떤 도구를 선택하느냐보다, 내가 먼저 문제를 어떤 구조로 보고 있는지 정리하는 일이었다.

예를 들어 같은 “온보딩 개선”을 묻더라도 목적에 따라 질문은 완전히 달라진다.
신규 가입자의 이탈을 줄이고 싶은 것인지, 핵심 기능 경험까지 더 빨리 데려가고 싶은 것인지, 아니면 가입 후 첫 결제까지의 전환을 높이고 싶은 것인지에 따라 AI에게 요청해야 할 분석도 달라진다. 겉으로는 모두 온보딩 개선이지만, 실제로 풀어야 하는 문제와 봐야 하는 지표는 다르다.

이때부터 조금씩 느꼈던 것 같다.
도구가 중요한 게 아니라, 문제를 해결하는 구조가 먼저가 아닐까라는 것을.

그리고 지금처럼 AI 도구가 빠르게 좋아질수록 오히려 질문하는 사람의 역할은 더 중요해지는 것 같다. AI가 더 빠르게 정리해주고, 더 그럴듯한 답을 만들어줄수록 내가 무엇을 물어보고 있는지 모르면 더 빠르게 엉뚱한 방향으로 갈 수 있다.

더 무서운 건 그 답변이 꽤 그럴듯하기 때문에, 방향이 어긋났다는 사실을 바로 알아차리기 어렵다는 점이다.
문장은 매끄럽고 구조도 잘 잡혀 있는데, 정작 내가 해결해야 할 문제와는 조금씩 멀어져 있는 것이다. 그래서 AI에게 묻기 전에 내가 먼저 문제의 기준선을 잡는 과정이 필요했다.

시행착오 2. AI에게 내 관점 들어내기

그래서 최근에는 AI에게 바로 “정리해줘”라고 말하기보다, 내가 지금 어떤 구조로 문제를 보고 있는지 먼저 드러내려고 한다.
앞서 말한 세 가지를 정리한 뒤, 그다음에는 내가 어떤 관점으로 이 문제에 접근하고 있는지를 AI에게 함께 알려주는 것이다.

예를 들면 이런 식이다.

네가 [내 역할]을 맡은 서비스 기획자라면, 지금 이 문제에서 무엇부터 확인하겠어?
내가 현재 [내 접근 방식]으로 접근하고 있는데, 이 접근의 전제와 사각지대를 먼저 짚어줘.
특히 최근 [업계 변화/주요 사건]이 기존 [구조/관행]을 어떻게 흔들고 있는지 중심으로 정리해줘.

이 프롬프트에서 중요한 건 AI에게 바로 정답을 달라고 하지 않는다는 점이다. (이게 참 쉽지 않다... 내가 원하는 것은 쉽게 얻고자 하는 답이기에) 대신 내가 어떤 방식으로 문제를 보고 있는지, 그리고 그 방식 안에 어떤 전제가 숨어 있는지를 먼저 확인하게 한다.

기획을 하다 보면 어느 순간 내가 세운 가설을 사실처럼 다루게 될 때가 있다.
“이 시장은 이런 구조로 움직인다”, “유저는 이 흐름에서 이런 행동을 할 것이다”, “이 기능이 들어가면 자연스럽게 다음 행동으로 이어질 것이다” 같은 생각들이다.

물론 이런 가설은 필요하다. 가설이 있어야 기획도 앞으로 나아갈 수 있기 때문이다. 하지만 문제는 그 가설이 지금도 유효한지 확인하지 않은 채, 계속 그 위에 내용을 쌓아갈 때 생기는 것 같다.

예를 들어 어떤 서비스를 분석하면서 처음부터 “이 서비스의 강점은 커뮤니티일 것이다”라고 생각하고 들어갈 수 있다. 그러면 AI에게도 자연스럽게 커뮤니티 관점의 질문을 던지게 된다. “이 서비스의 커뮤니티 구조를 분석해줘”, “유저 간 상호작용이 어떻게 리텐션으로 이어지는지 정리해줘”와 같은 식이다.

그러면 답변 역시 그 방향으로 정리될 가능성이 높다.
하지만 실제로는 그 서비스의 성장 요인이 커뮤니티가 아니라 결제 구조, 콘텐츠 공급 방식, 온보딩 경험, 혹은 최근 플랫폼 정책 변화일 수도 있다. 처음 질문의 방향이 좁으면 AI가 아무리 많은 정보를 정리해줘도, 결국 내가 보고 싶은 것만 더 선명해질 수 있는 것이다.

그래서 AI에게 역할을 부여하는 것만큼 중요한 것은, 내가 이미 어떤 관점으로 문제를 보고 있는지 함께 알려주는 일이라고 생각한다.

단순히 이렇게 묻는 것과,

서비스 기획자처럼 이 서비스를 분석해줘.

이렇게 묻는 것은 다르다.

나는 지금 이 문제를 유저 리텐션 관점에서 보고 있어.
이 접근의 전제와 사각지대를 먼저 짚어주고, 다른 관점에서 봤을 때 놓칠 수 있는 부분을 정리해줘.

내가 직접 시행착오를 겪어보니 후자의 질문은 AI에게 답을 만들게 하는 동시에, 내 질문 자체를 검토하게 만든다. 그리고 이 과정에서 내가 처음에 너무 당연하게 두고 있던 관점이 조금씩 보이기 시작한다.

시행착오 3. AI의 전제 파악하기

또 하나 쓰게 된 방식은 여러 AI를 병렬로 사용하는 것이다.
같은 주제를 ChatGPT에도 물어보고, Claude에도 물어보고, 필요하면 다른 AI에도 물어본다. 처음에는 단순히 더 좋은 답변을 고르기 위해서였다. 그런데 몇 번 해보니 답변의 품질보다 더 흥미롭게 보이는 지점이 있었다.

같은 문제를 두고도 각 AI가 깔고 있는 전제가 조금씩 다르다는 점이다.

같은 시장 데이터, 같은 사례, 같은 키워드를 보고도 어떤 답변은 현황을 깔끔하게 정리하는 데서 끝난다. 반면 어떤 답변은 그 현상이 앞으로 어떤 구조 변화를 만들 수 있는지까지 이어간다. 이때의 차이는 단순히 정보량에서 나오는 것이 아니었다. 같은 정보를 보더라도 어떤 관점에서 해석하느냐에 따라 결론이 달라지는 것이다.

그래서 요즘은 두 개 이상의 답변을 나란히 놓고, 다시 이런 식으로 묻는다.

다음은 다른 AI가 정리한 분석이야.
이 분석의 전제 세 가지를 짚어줘.
그리고 그 전제들이 지금 시점에 흔들리고 있다면 결론이 어떻게 달라지는지 반박해줘.

이 질문이 꽤 유용했던 이유는, 내가 이미 그럴듯하다고 받아들인 분석을 다시 의심하게 만들기 때문이다.

기획자는 자료를 많이 모으는 사람이라기보다, 어떤 자료를 어떤 구조 안에서 해석할지 결정하는 사람에 가깝다. 그래서 AI가 정리한 내용도 그대로 가져오면 안 된다고 생각하고 있다. 그 답변이 어떤 전제를 기준으로 사실을 배열했는지 봐야 하지 않을까?

예를 들어 “이 시장은 성장하고 있다”는 분석이 있다고 해보자. 겉으로 보면 긍정적인 신호처럼 보인다. 하지만 그 성장이 유저의 반복 사용에서 나온 것인지, 일시적인 프로모션에서 나온 것인지, 특정 플랫폼의 정책 변화 때문에 생긴 것인지에 따라 다음 기획 방향은 완전히 달라진다.

반복 사용이 늘어난 것이라면 사용자의 습관 형성 구조를 봐야 한다. 프로모션 효과라면 비용을 줄였을 때도 같은 행동이 유지되는지 확인해야 한다. 정책 변화로 인한 성장이라면 그 정책이 다시 바뀌었을 때도 서비스가 버틸 수 있는지 봐야 한다.

결국 같은 “성장”이라는 단어 안에도 확인해야 할 질문은 전혀 다를 수 있다는 것이다.
그래서 AI가 준 답변을 볼 때는 “맞는 말인가?”만 보는 것이 아니라, “어떤 전제를 깔고 맞는 말처럼 보이는가?”를 함께 봐야 한다는 생각이 들기 시작했다.

여러 AI를 쓰는 이유도 여기 있는 것 같다. 답변을 더 많이 모으기 위해서라기보다, 내가 하나의 해석에 너무 빨리 기대고 설득되어 따라고 있지는 않은지 확인하기 위해서다.

시행착오 5. AI의 근거 확인하기

물론 이렇게 관점을 넓히는 것만으로는 부족하다.
여러 AI의 답변을 비교하면서 전제를 확인하더라도, 어느 순간부터는 반드시 근거를 확인해야 한다고 느낀 것이다. (당연하고 기본적인 것임에도 놓치는 경우가 많다)

AI는 문장을 꽤 그럴듯하게 만든다. 읽다 보면 실제로 그런 자료가 있었던 것처럼 느껴질 때도 있다. 하지만 기획 문서에서 중요한 것은 자연스러운 설명이 아니라, 지금 의사결정에 써도 되는 근거라는 것을 놓치면 안된다.

그래서 정리 단계로 넘어갈 때는 이런 질문을 붙인다.

이 내용의 근거가 되는 공식 블로그 포스트, IR 자료, 컨퍼런스 발표의 제목과 발행일을 알려줘.
내가 직접 검색해서 실존 여부를 확인할 수 있어야 해.

이 질문을 넣는 이유는 단순하다. AI가 말한 내용이 실제로 확인 가능한 자료에 기반하고 있는지 보기 위해서다.

특히 시장 변화나 기업 전략, 업계 트렌드를 다룰 때는 더 조심해야 하는 것 같다. AI는 여러 정보를 섞어 자연스러운 흐름으로 정리해줄 수 있지만, 실제 업무에서는 출처가 확인되지 않는 문장을 그대로 쓰기 어렵다.

예를 들어 어떤 서비스가 특정 방향으로 전략을 바꾸고 있다고 말하려면, 공식 블로그나 IR 자료, 컨퍼런스 발표, 인터뷰처럼 확인 가능한 근거가 있어야 한다. 그리고 발행일도 중요하다. 몇 년 전 자료를 지금의 전략처럼 가져오면 기획의 출발점이 어긋날 수 있기 때문이다.

이 과정은 사실 조금 번거롭다. 하지만 실제로 해보면 꽤 큰 차이를 만든다.

AI가 정리해준 내용을 그대로 받아쓰는 것이 아니라, 그 내용을 구성하는 근거가 실제로 존재하는지 확인하게 되기 때문이다. 그리고 근거를 확인하는 과정에서 처음의 해석이 달라지는 경우도 있다.

처음에는 “이 회사가 A 방향으로 가고 있다”고 생각했는데, 공식 자료를 보면 실제로는 A보다 B를 더 중요하게 말하고 있을 수 있다. 또는 과거에는 A를 강조했지만, 최근 발표에서는 전혀 다른 지표를 이야기하고 있을 수도 있다.

이런 차이는 AI가 정리한 문장만 읽어서는 잘 보이지 않는다는 걸 느꼈다.
결국 직접 확인 가능한 근거까지 내려가야 보인다. 기획에서 필요한 것은 그럴듯한 문장이 아니라, 실제 판단에 사용할 수 있는 재료이기 때문이다.

출처 : 나무위키

시행착오의 결론, 결국 나의 몫

앞으로도 AI를 사용하며 일하는 방식은 계속 바뀔 것 같다.
지금 내가 쓰고 있는 방법도 시간이 지나면 달라질 수 있고, 더 좋은 도구나 더 나은 방식이 나올 수도 있다. 실제로 내가 AI를 쓰는 방법은 지금도 계속 변하고 있다.

그럼에도 변하지 않는 것이 무엇일까 고민했다.
그럼에도 변하지 않는 것이 있다면, 결국 무엇을 고민하고 무엇을 비교하고 무엇을 판단할지는 나의 몫이라는 점이다.

AI는 빠르게 정리해주고, 다양한 관점을 제안해주고, 내가 놓친 가능성을 보여줄 수 있다. 하지만 내가 무엇을 얻고 싶은지 모르면 그 답변은 쉽게 흩어진다. 내가 무엇을 어떻게 해결하고 싶은지 정리되어 있지 않으면, 아무리 그럴듯한 답변도 실제 기획에는 잘 붙지 않는다.

그래서 AI를 잘 쓰기 위해 필요한 것은 단순히 좋은 프롬프트를 찾는 일이 아니라, 내가 지금 어떤 문제 앞에 서 있는지 계속 확인하는 일에 가까운 것 아닐까?

내가 얻고자 하는 것은 무엇인지.
무엇을 어떻게 해결하고 싶은지.
이 문제를 바라보는 내 관점 안에 당연하게 깔린 전제는 없는지.
그리고 그 전제는 지금도 유효한지.

이 질문들을 먼저 붙잡고 있어야 AI의 답변도 제대로 볼 수 있는 것 같다.
답변을 그대로 따라가는 것이 아니라, 비교하고 의심하고 다시 확인하면서 내 판단의 재료로 삼을 수 있지 않을까 싶다.

결국 AI가 일을 대신해주는 시대가 아니라, AI와 함께 일할수록 내가 더 선명해져야 하는 시대에 가까운 것 같다.
도구는 계속 좋아지겠지만, 문제를 정의하고 중심을 잡는 일은 여전히 기획자의 몫이다.

팬덤 서비스는 무엇을 중심으로 설계되어야 할까: 위버스, 비스테이지, 포카마켓, 슈퍼스타 리듬게임

pmjigu — Thu, 23 Apr 2026 15:09:29 +0900

출처 : Chatgpt 이미지 생성

팬덤 서비스를 기획하며 다시 보게 된 질문

지난 글에서는 쇼핑 경험을 목적형 쇼핑과 발견형 쇼핑으로 나눠 정리해봤습니다. 필요한 것을 빠르게 해결하는 경험이 중요한 서비스가 있는가 하면, 둘러보다가 취향에 맞는 것을 발견하게 만드는 경험이 더 중요한 서비스도 있다는 이야기였죠.

https://fejigu.tistory.com/22

그런데 팬덤 서비스를 기획하다 보니, 이 프레임만으로는 잘 설명되지 않는 영역이 있다는 생각이 들었습니다. 같은 팬덤 서비스라고 해도 어떤 서비스는 팬과 아티스트의 관계를 더 자주 확인하게 만들고, 어떤 서비스는 팬덤을 직접 운영할 수 있게 하며, 또 어떤 서비스는 수집과 거래를 더 편하고 믿을 수 있게 만드는 데 집중하고 있었기 때문입니다. 어떤 서비스는 구매보다 참여와 반복 몰입을 훨씬 더 중요하게 다루고 있기도 했고요.

특히 인상적이었던 건, 팬을 하나로 보면 이 차이가 잘 보이지 않는다는 점이었습니다. 팬덤은 하나의 집단처럼 보이지만 실제로는 서로 다른 팬덤셀로 흩어져 있고, 한 사람 안에서도 상황에 따라 다른 부캐가 드러난다고들 이야기합니다. 결국 팬덤 서비스를 기획할 때 중요한 건 “팬 전체를 위한 기능”을 나열하는 게 아니라, 우리 서비스가 팬의 어떤 행동을 가장 자주, 자연스럽게 만들고 싶은가를 먼저 정하는 일이라는 생각이 들더라고요.

그래서 이번에는 팬덤 서비스가 무엇이 중요한지를 추상적으로 이야기하기보다, 이미 잘 되고 있는 팬덤 서비스들이 각각 어떤 팬 행동을 중심으로 설계되어 있는지를 기준으로 다시 정리해보면 고민해보고자 합니다.

기능보다 팬 행동 중심으로 보기

팬덤 서비스는 모두 팬을 위한 서비스이지만, 그렇다고 모두 같은 경험을 만드는 것은 아니더라고요.
앞서 한번 말한 것처럼 어떤 서비스는 팬이 더 자주 연결감을 느끼게 하고, 어떤 서비스는 팬덤을 더 직접적으로 운영하게 만들고, 또 어떤 서비스는 좋아하는 대상을 더 오래 모으고 관리하게 만듭니다. 어떤 서비스는 팬의 시간을 반복적으로 점유하면서 참여 자체를 핵심 경험으로 만들기도 하고요.

이 관점에서 보면, 팬덤 서비스를 기획할 때 중요한 질문도 조금 달라지죠.
커뮤니티가 필요할까, 커머스를 붙일까, 멤버십을 넣을까 같은 기능 중심의 질문보다, 팬이 이 안에서 어떤 행동을 반복하게 될까를 먼저 보는 편이 더 본질적이라고 느껴졌습니다.

당연하게도 팬은 언제나 같은 모습으로 움직이지 않습니다. 그래서 팬덤 서비스도 결국은 팬 전체를 상대하는 서비스라기보다, 특정한 팬 행동을 더 자주 일으키도록 설계된 서비스라고 보는 게 더 맞는 것 같아요.

위버스

팬덤 서비스라면 가장 먼저 떠오르는 위버스를 보면, 이 서비스가 팬덤을 어떤 경험으로 풀고 있는지가 비교적 분명하게 보입니다. 위버스는 단순히 팬이 콘텐츠를 보거나 굿즈를 구매하는 공간이라기보다, 팬과 아티스트의 관계를 일상적으로 이어가게 만드는 구조에 더 가깝게 느껴졌어요. 실제 커뮤니티 안에서도 Highlight, Fan, Artist, Fan Letter, Media, LIVE, Notice 같은 탭이 먼저 놓여 있는데, 이 구성만 봐도 상품 탐색보다 소식을 확인하고, 반응을 남기고, 라이브를 기다리고, 애정을 표현하는 행동이 더 앞에 배치되어 있다는 인상을 받게 됩니다.

이런 구조를 보면 위버스의 코어는 거래보다 연결의 지속성에 더 가까운 것 같습니다. 팬은 이 안에서 단순히 무언가를 사는 사람이 아니라, 좋아하는 아티스트의 소식을 계속 확인하고, 다른 팬들의 반응을 보며 함께 분위기를 만들고, Fan Letter나 LIVE 같은 접점에서 애정을 표현하고 기다리는 사람에 가깝습니다. 즉 위버스는 팬을 ‘구매자’로 보기보다, 계속 돌아와 관계를 확인하고 팬으로서의 소속감을 유지하는 존재로 보고 설계한 서비스처럼 느껴졌어요. 그래서 위버스는 팬덤 서비스 안에서도 커머스형이라기보다, 관계를 반복적으로 확인하게 만드는 관계형 서비스에 더 가깝다고 생각했습니다.

비스테이지

비스테이지를 보면 위버스와는 조금 다른 방향이 먼저 보입니다. 위버스가 팬이 머무르며 관계를 확인하는 구조에 더 가깝다면, 비스테이지는 팬덤 운영자가 팬의 참여 구조를 직접 설계할 수 있게 만드는 서비스처럼 느껴졌어요. 실제로 비스테이지는 POP, 멤버십, 커뮤니티, 라이브 스트리밍, 설문 같은 기능을 한 흐름 안에 두고 있고, 커뮤니티도 목적별로 여러 개를 운영할 수 있으며, 멤버십 역시 등급별 혜택을 나눠 설계할 수 있게 해둡니다. 여기에 설문과 폴은 팬이 머무는 공간 안에서 바로 실행할 수 있고, POP은 라이브·채팅·1:1 TALK처럼 팬과 스타의 접점을 더 세분화해 운영할 수 있게 해주고요.

이런 구조를 보면 비스테이지의 코어는 단순히 팬이 더 자주 반응하게 만드는 데 있다기보다, 팬덤 운영자가 관계와 참여를 여러 접점으로 나누어 직접 설계하고 관리할 수 있게 만드는 데 더 가까워 보였습니다. 그래서 비스테이지는 관계형 서비스라기보다, 팬덤을 직접 구축하고 운영하게 만드는 운영형 서비스에 더 가깝다고 느껴졌습니다.

포카마켓

포토카드 서비스인 포카마켓도 있는데요. 반면 포카마켓은 위버스나 비스테이지와는 또 다른 방식으로 팬덤을 풀고 있는 서비스처럼 보였습니다. 위버스가 관계의 지속성을, 비스테이지가 팬덤 운영의 구조를 중심에 둔다면, 포카마켓은 팬덤을 계속 모으고 완성해가는 수집의 경험으로 해석하는 쪽에 더 가깝게 보여지죠. 실제로 서비스 구조도 Home, Used, Official, Collect Book, My처럼 짜여 있는데, 이 흐름은 단순히 포토카드를 한 번 구매하는 행동보다 탐색하고, 고르고, 쌓아두고, 다시 관리하는 흐름 전체를 하나의 경험으로 보고 있다는 인상을 줍니다. 홈에서도 최애를 먼저 설정하고 그 기준으로 아이템을 탐색하게 만드는 구조가 앞에 놓여 있는데, 이 역시 팬을 일회성 구매자가 아니라 좋아하는 대상을 계속 찾아 모으는 사람으로 보고 설계한 것처럼 보여지고요.

이런 구조를 보면 포카마켓의 코어는 거래 그 자체라고 보기보다는 수집의 연속성과 그 과정에서의 신뢰에 더 가까운 것 같습니다. About 페이지에서도 검증된 공식 포토카드만 거래되도록 자체 인증 과정을 두고 있고, 구매한 카드를 바로 받는 대신 Collect Book에 쌓아두었다가 원하는 시점에 배송을 요청하게 만드는 흐름을 강조하고 있죠. 결국 포카마켓은 팬덤을 소통이나 참여보다 먼저, 최애를 계속 모으고 안심하고 관리하는 경험으로 풀고 있는 서비스에 더 가깝다고 느껴졌습니다. 그래서 이 서비스는 팬덤 서비스 안에서도 관계형이나 운영형보다는, 수집의 지속을 중심에 둔 수집형 서비스로 보는 게 더 맞다고 생각했습니다.

슈퍼스타 리듬게임

슈퍼스타 리듬게임이라고 팬덤형 게임 서비스도 있는데요. 위버스처럼 관계를 지속시키거나, 비스테이지처럼 팬덤 운영 구조를 제공하거나, 포카마켓처럼 수집의 연속성을 설계하는 서비스와는 또 다른 방향에 있습니다. 이 서비스의 코어는 팬과 아티스트의 연결 자체보다 좋아하는 아티스트를 반복적으로 플레이하고 몰입하게 만드는 경험에 더 가깝다고 느껴졌어요. 실제 앱 구조도 그 방향을 분명하게 보여줍니다. 플레이스토어 설명을 보면 핵심 루프가 곡 플레이 → 테마 카드 수집 → 카드 강화 → 더 높은 점수 획득 → 주간 리그/슈퍼스타 리그 참여 → 미션과 이벤트 보상 획득으로 이어지는데, 이 흐름은 팬을 단순히 소비자나 관람자가 아니라 계속 들어와 참여하고 성취를 쌓는 플레이어로 보고 설계한 구조처럼 읽힙니다. 특히 아티스트 곡들이 매주 업데이트되고, 테마 카드로 덱을 채우고 강화해 점수를 올리며, 주간 리그와 슈퍼스타 리그에서 다른 팬들과 경쟁하고, 매일 새로운 미션과 컴백 연동 이벤트를 수행하게 만든다는 점이 이 코어를 잘 보여주는 것 같습니다.

이런 구조를 보면 슈퍼스타 리듬게임은 팬덤을 관계나 운영, 실물 수집보다 먼저 반복 참여와 몰입의 경험으로 풀고 있는 서비스에 더 가까운 것 같습니다. 카드 수집 요소가 있긴 하지만, 여기서 카드는 포카마켓처럼 소장 자체가 목적이기보다 플레이 성과를 높이고 경쟁을 이어가기 위한 성장 자원으로 작동하는 것 아닌가 싶습니다. 결국 중요한 건 한 번 좋아하고 끝나는 것이 아니라, 좋아하는 아티스트를 매일 플레이하고, 점수를 올리고, 이벤트에 참여하면서 팬 경험을 반복 루프로 만드는 것이죠.

그래서 슈퍼스타 리듬게임은 팬덤 서비스 안에서도 관계형이나 운영형, 수집형과는 조금 다르게, 팬의 시간을 계속 점유하고 반복 행동을 만들어내는 참여형 서비스로 보여졌습니다.

결국 같은 팬덤 서비스라도 중심에 두는 경험은 다르다

이 네 가지 서비스를 같이 놓고 보니, 같은 팬덤 서비스를 만들고 있어도 실제로 중심에 두는 경험은 꽤 다르다는 점이 더 분명해졌습니다.

위버스는 팬과 아티스트의 관계를 계속 확인하고, 팬으로서의 소속감을 유지하게 만드는 데 더 가깝습니다.
비스테이지는 그 관계와 참여를 하나의 플랫폼 안에서 직접 설계하고 운영할 수 있게 만드는 데 더 가깝고요.
포카마켓은 좋아하는 대상을 계속 모으고 안심하고 관리할 수 있게 만드는 수집의 경험에 더 집중합니다.
슈퍼스타 리듬게임은 팬이 반복적으로 참여하고, 몰입하고, 경쟁하며 성취를 쌓게 만드는 구조를 중심에 두고 있고요.

이렇게 보면 팬덤 서비스는 모두 비슷해 보이지만, 실제로는 중심에 두는 경험이 꽤 다르다는 생각이 듭니다. 어떤 서비스는 팬덤을 관계의 지속으로 풀고, 어떤 서비스는 운영 가능한 구조로 풀며, 또 어떤 서비스는 수집이나 반복 참여의 경험으로 풀고 있으니까요. 그래서 팬덤 서비스를 기획할 때도 단순히 “팬덤 서비스니까 커뮤니티가 필요하겠지”, “커머스도 붙어야겠지”, “이벤트도 있어야겠지”처럼 기능 중심으로 접근하면 오히려 서비스의 중심이 흐려질 수 있겠다는 생각이 들더군요.

그래서 이번에는 이미 사랑받고 있는 서비스들을 하나씩 분석해보면서, 결국 더 중요하다고 느낀 건 우리 서비스가 팬덤을 어떤 경험으로 해석하고 있는지, 그리고 그 안에서 팬의 어떤 행동을 가장 자주 만들고 싶은지를 먼저 정하는 일이었습니다.

그래서 우리 서비스는 어떤 팬 행동을 중심에 둘 것인가

그래서 이번에 사랑 받고 있는 팬덤형 서비스들을 하나씩 분석해보고 관심 있게 보면서, 저도 앞으로 팬덤형 서비스를 기획할 때의 기준을 조금 더 분명하게 가져가야겠다는 생각을 하게 됐습니다.

무엇이 잘 되고 있는지를 보는 것도 중요하지만, 그 기능들을 그대로 따라가기보다 우리 서비스 안에서 팬이 어떤 마음으로 들어오고, 어떤 경험을 하고, 왜 다시 돌아오게 만들고 싶은지를 먼저 더 오래 고민해야겠더군요.

결국 앞으로의 기획에서는 기능 자체보다도, 팬이 이 안에서 어떤 감정을 느끼고 어떤 행동으로 이어지게 되는지를 더 세심하게 보게 될 것 같습니다. 저도 팬덤형 서비스를 만들면서, 더 많은 것을 넣는 방향보다 우리 서비스만의 팬 경험을 더 선명하게 만드는 방향으로 고민해보려고 합니다.

[기획] 우리 서비스는 어떤 쇼핑 경험을 만들고 있을까

pmjigu — Wed, 15 Apr 2026 16:04:58 +0900

출처 : 구글 이미지

서비스를 기획하며 다시 생각해본 기록

요즘 신규 서비스를 기획하면서 자연스럽게 다시 보게 된 질문이 있습니다.
우리는 지금 어떤 쇼핑 경험을 만들고 있는가, 그리고 고객은 이 안에서 무엇을 기대하고 있을까 하는 질문이었어요.

PM, 기획자의 입장에서 커머스 서비스를 보다 보면 쇼핑은 하나로 묶어 설명하기 어렵다는 생각을 자주 하게 됩니다. 분명 어떤 고객은 필요한 것을 가장 빠르고 편하게 사고 싶어 하고, 또 어떤 고객은 둘러보는 과정 속에서 취향에 맞는 상품을 발견하는 즐거움을 더 크게 느끼니까요. 이 차이는 단순히 취향의 문제가 아니라, 서비스의 구조와 우선순위를 다르게 설계해야 하는 기준이 되기도 합니다.

저 역시 이번에 신규 앱을 기획하면서 우리 플랫폼의 쇼핑 성격이 어디에 더 가까운지 돌아보게 됐고, 목적형 쇼핑과 발견형 쇼핑은 무엇이 다르며 각각 어떤 경험으로 풀어내야 하는지 다시 기본부터 정리해보고 싶어졌습니다. 이 글은 그 고민의 흐름을 따라가며 정리한 메모에 가깝습니다.

같은 쇼핑이어도, 고객이 원하는 경험은 꽤 다르다

쇼핑은 모두 비슷해 보이지만, 실제로는 고객이 들어온 맥락에 따라 기대하는 경험이 꽤 다르죠.

예를 들어 생수나 휴지처럼 이미 필요한 것이 정해져 있는 상품을 살 때는 가능한 한 빨리 찾고, 익숙한 조건 안에서 비교하고, 바로 결제까지 이어지는 것이 중요합니다. 반대로 패션이나 뷰티, 인테리어처럼 취향이 크게 작용하는 카테고리에서는 처음부터 원하는 상품이 선명하지 않은 경우가 많습니다. 이럴 때는 검색의 정확도보다도 내 취향에 맞는 제안, 둘러보는 재미, 발견의 즐거움이 더 크게 작동합니다.

그래서 쇼핑 경험은 크게 두 가지로 나눠질 수 있는 것 같아요. 하나는 필요를 빠르게 해결하는 목적형 쇼핑, 다른 하나는 취향을 탐색하고 발견하는 발견형 쇼핑입니다.

물론 실제 서비스에서는 이 둘이 완전히 분리하기는 어렵죠. 하나의 플랫폼 안에도 두 성격이 함께 섞여 있고, 같은 고객도 상황에 따라 전혀 다른 쇼핑 모드로 들어가니까요. 다만 신규 앱을 기획하는 입장에서는 지금 우리가 더 중심에 두고 있는 쇼핑 경험이 무엇인지 먼저 분명히 보는 것이 중요하다고 느꼈습니다. 그래야 메인 화면의 구조도, 추천 방식도, 검색과 큐레이션의 비중도 훨씬 선명하게 정리되기 때문입니다.

목적형 쇼핑

먼저, 목적형 쇼핑은 고객이 이미 어느 정도 필요한 것을 알고 있는 상태에서 시작됩니다. 당장 필요한 생활용품을 사야 하거나, 늘 쓰던 상품을 다시 구매해야 하거나, 조건이 명확한 상품을 비교해서 사려는 경우가 여기에 가까워요.

이때 고객이 기대하는 것은 대체로 분명합니다. 좋은 가격, 빠른 배송, 검증된 후기, 쉬운 비교, 적은 클릭. 결국 중요한 건 고객이 원하는 상품에 얼마나 빠르게 도달할 수 있느냐입니다.

쿠팡이나 네이버 같은 서비스가 강하게 자리 잡은 이유도 여기에 있다고 생각합니다. 이들은 고객이 굳이 오래 고민하지 않아도 되도록, 이미 필요한 것이 있을 때 빠르게 찾고 바로 살 수 있는 경험을 만들어왔습니다. 목적형 쇼핑에서는 “무엇을 보여주느냐”만큼이나 “얼마나 적은 노력으로 찾게 하느냐”가 중요한 것 같습니다.

출처 : beusable

개인화의 핵심은 탐색 비용 절감 아닐까

요즘 추천 기능을 거의 모든 서비스들에서 확인할 수 있는데요. 목적형 쇼핑에서 추천은 발견의 즐거움을 주기 위한 장치라기보다, 고객이 덜 헤매게 돕는 장치에 가까운 것 같아요. 최근에 본 상품, 장바구니에 담았던 상품, 자주 구매한 상품, 함께 구매한 상품을 연결해서 보여주는 방식이 대표적이죠.

이런 추천은 고객이 수많은 상품을 다시 비교하는 수고를 줄여줍니다. 특히 반복 구매가 잦거나 익숙한 브랜드가 있는 카테고리일수록, 추천은 새로운 것을 제안하는 것보다 이전의 선택을 더 쉽게 이어주게 하는 역할이 더 큽니다.

만약 우리 플랫폼이 목적형 쇼핑의 성격이 강하다면, 메인 홈에서부터 “무엇을 새롭게 보여줄까”보다 “무엇을 더 빨리 다시 살 수 있게 해줄까”가 더 중요한 질문이 되기 때문이죠. 최근 본 상품, 재구매 진입점, 개인화된 추천 영역, 맞춤형 혜택 노출은 이때 훨씬 큰 힘을 가질 수 있을 것 같네요.

검색도 결정을 줄여주는 기능이어야 한다

목적형 쇼핑에서는 검색도 매우 중요한 축인데요. 그런데 검색이 잘 된다는 건 단순히 키워드에 맞는 결과를 정확히 보여주는 것만 의미하지 않는다고 생각해요.

고객은 검색창을 열기 전부터 이미 많은 맥락을 가지고 들어옵니다. 최근 구매 이력, 선호 브랜드, 자주 찾는 카테고리, 가격대, 배송 조건처럼요. 그래서 좋은 목적형 쇼핑 경험은 검색 이전 단계에서부터 고객의 행동을 예측하고, 자주 사는 상품을 먼저 보여주거나, 정기구독과 재구매 동선을 자연스럽게 열어주더라고요.

또 검색 결과 안에서도 필터와 정렬이 얼마나 잘 구성되어 있는지가 중요합니다. 정확도, 인기순, 추천순 같은 기준이 단순히 존재하는 것을 넘어서, 고객이 진짜 빠르게 고를 수 있도록 설계되어야 하죠. 결국 목적형 쇼핑에서 검색도 정보 탐색 기능이라기보다 구매까지 가는 시간을 줄이는 기능에 더 가깝습니다.

결국은 더 덜 헤매게 하기 위한 것이다

결론적으로 목적형 쇼핑에서는 고객을 촘촘하게 이해하는 것도 중요합니다. 연령, 성별, 지역, 가구 구성, 반복 구매 패턴에 따라 필요한 상품은 꽤 다르게 나타나기 때문입니다.

이런 데이터는 프로모션 효율을 높이거나 광고를 정교하게 운영하는 데도 쓰이지만, 기획자의 입장에서 더 중요하게 보였던 건 탐색 경험을 얼마나 자연스럽게 줄여주느냐였습니다. 고객이 지금 필요로 할 확률이 높은 것을 먼저 보여주고, 굳이 여러 번 비교하지 않아도 되도록 도와주는 것. 목적형 쇼핑은 결국 이런 작은 편의의 축적에서 경쟁력이 생기는 것 같습니다.

발견형 쇼핑

반대로 발견형 쇼핑은 출발점이 조금 다릅니다. 고객이 처음부터 사고 싶은 상품을 명확히 정하지 않은 상태이거나, 상품 그 자체보다도 취향과 분위기, 라이프스타일에 더 크게 반응하는 경우가 많습니다.

패션, 뷰티, 인테리어처럼 감각과 맥락이 중요한 카테고리에서 특히 이런 성격이 강하게 드러나는데요. 이때 고객은 단지 조건에 맞는 상품을 찾는 것이 아니라, 나에게 어울리는 무드나 스타일을 함께 발견하고 싶어 합니다.

그래서 발견형 쇼핑에서는 가격 비교나 빠른 탐색만으로는 충분하지 않습니다. 추천도 다르게 작동해야 하고, 화면도 다르게 구성돼야 하며, 콘텐츠의 역할도 훨씬 커집니다.

목적형 쇼핑이 효율을 높이는 경험이라면, 발견형 쇼핑은 고객의 감정과 취향을 움직이는 경험에 더 가깝죠.

출처 : 무신사

큐레이션이 상품보다 먼저 작동한다

발견형 쇼핑에서 고객은 상품 하나를 보러 오는 것이 아니라, 자신이 좋아할 만한 분위기나 취향을 함께 탐색합니다. 이때 단순히 비슷한 상품을 추천하는 것만으로는 부족할 때가 많습니다. 고객이 왜 이 상품에 끌리는지, 어떤 스타일 안에서 더 매력적으로 느껴지는지까지 보여줘야 하기 때문이죠.

그래서 큐레이션의 힘이 중요해지는 것 같습니다.
패션이라면 옷 한 벌이 아니라 전체 스타일링으로, 인테리어라면 소품 하나가 아니라 공간의 분위기로, 뷰티라면 제품 스펙이 아니라 사용 맥락과 이미지로 제안해야 하죠.

출처 : 에이블리

무신사의 코디 탭이나 에이블리의 스타일 중심 탐색 구조가 인상적인 이유도 여기에 있다고 생각합니다. 이들은 단순한 상품 나열보다 “이 느낌이 좋다”는 반응을 먼저 끌어내는 데 집중하는데요. 발견형 쇼핑에서는 이런 감각적 진입점이 검색보다 더 강한 힘을 가지기도 합니다.

저희 서비스는 목적형 쇼핑보다 발견형 쇼핑의 성격이 더 강하다고 느끼고 있어요. 그래서 요즘은 이 특성을 더 잘 살리려면 화면과 탐색 경험을 어떻게 구성해야 할지 자주 고민하게 됩니다. 상품을 카테고리 중심으로 보여주는 방식보다 스타일, 상황, 테마처럼 고객의 취향이 먼저 반응할 수 있는 맥락을 전면에 두는 것이 더 맞을 수도 있겠다는 생각도 들고요. 추천 역시 구매 이력을 따라가는 방식보다, 비슷한 취향 안에서 새로운 상품을 자연스럽게 발견할 수 있도록 설계하는 쪽이 더 우리 서비스다운 방향일 수 있겠다고 보고 있습니다.

상품보다 장면이 먼저 기억된다

목적형 쇼핑이 가격과 배송, 혜택 중심의 메시지에 반응한다면, 발견형 쇼핑은 더 자주 감정과 장면에 반응한다고 생각합니다.

예를 들어 옷을 하나 볼 때도 단순히 소재나 가격보다, 내가 이걸 입었을 때 어떤 분위기로 보일지 먼저 상상하게 되죠. 인테리어 소품도 마찬가지입니다. 상품 자체보다 우리 집에 놓였을 때 어떤 느낌일지, 내 공간이 어떻게 달라질지를 함께 떠올립니다. 그래서 발견형 쇼핑에서는 스토리와 콘텐츠가 중요합니다. 상품을 설명하는 것에 그치지 않고, 그 상품이 들어간 라이프스타일 전체를 보여줘야 하죠. 고객은 정보를 읽는 동시에 자신을 그 안에 대입해보게 됩니다.

기획자의 입장에서 보면 이 차이는 꽤 실무적인 고민으로 이어지는데요.
목적형 쇼핑에서는 전환을 빠르게 만드는 UI가 중요하다면, 발견형 쇼핑에서는 고객이 조금 더 머물고, 둘러보고, 몰입할 수 있게 만드는 UI가 더 중요할 수 있습니다. 꼭 바로 사게 만드는 버튼보다, 더 보고 싶고 더 탐색하고 싶게 만드는 구조를 먼저 고민해야 하는 이유도 여기에 있다고 생각합니다. 쉽지 않은 문제이지만, 요즘 제가 가장 많이 고민하고 있는 지점도 바로 이 부분입니다.

출처 : 지그재그

취향 기반 서비스일수록 고객 간 소통이 더 중요해진다

발견형 쇼핑은 플랫폼이 일방적으로 추천만 잘한다고 완성되지 않는데요. 오히려 고객들이 서로의 맥락을 참고할 수 있도록 해주는 구조가 더 큰 힘을 발휘할 때가 많은 것 같습니다.

오늘의집이 좋은 예시가 되어줍니다. 다른 사람의 공간을 보다가 마음에 드는 제품을 발견하고, 그 제품 정보를 확인하고, 실제 사용 맥락을 보며 구매까지 이어질 수 있죠. 이 과정은 단순히 상품 탐색을 줄이는 것을 넘어서, 취향을 구체적으로 이해하게 돕습니다.

패션과 뷰티도 크게 다르지 않습닏. 지그재그의 후기, 스타일링 예시, 질문과 답변, 실시간 소통, 라이브 방송처럼 고객이 서로 참고할 수 있는 접점이 많을수록 발견의 밀도는 높아집니다. 특히 취향이 개입되는 상품일수록 다른 사람의 선택과 맥락은 생각보다 강한 설득력이 됩니다.

그래서 발견형 쇼핑을 기획할 때는 단순히 “추천 기능을 넣을까”를 넘어서, 고객이 서로의 취향을 참고하고 반응할 수 있는 구조가 있는지도 함께 봐야 한다고 생각합니다. 결국 발견은 시스템만이 아니라 사람 사이에서도 만들어지기 때문이죠.

우리 서비스는 어떤 쇼핑 경험을 중심에 두고 있는가

신규 앱을 기획하면서 계속 돌아보게 되는 건, 결국 우리 서비스가 고객에게 어떤 쇼핑 경험을 더 중심적으로 제공하고 있는가에 대한 질문입니다.

실제 커머스는 목적형 쇼핑과 발견형 쇼핑이 깔끔하게 나뉘지 않고 한 서비스 안에 함께 존재하는 경우가 더 많지만, 그렇다고 두 성격을 모두 비슷하게 가져가면 오히려 서비스가 애매해지기 쉽다고 느꼈어요. 빠르게 찾고 바로 사게 만드는 경험이 더 중요한 서비스가 있는 반면, 머물며 취향을 탐색하고 자연스럽게 발견하게 만드는 경험이 더 중요한 서비스도 있으니까요.

그래서 기획에서는 두 유형을 구분해 이해하는 것 자체보다, 우리 플랫폼이 어디에 더 가까운지 먼저 판단하고 그에 맞게 화면과 탐색 구조, 추천 방식의 우선순위를 정하는 일이 더 중요하다고 생각합니다. 저도 이번에 이 부분을 다시 정리하면서 무엇을 더 추가할지보다, 어떤 경험을 더 선명하게 만들어야 할지를 고민하고 정리할 수 있었습니다 :)

[서비스 기획] 유저는 필요하다고 했는데, 왜 행동은 다를까

pmjigu — Sun, 12 Apr 2026 22:34:07 +0900

출처 : Tachyon Systems

요즘 유저 행동을 분석하다 보면, 유저의 말과 행동이 꽤 자주 다르다는 걸 다시 느끼게 돼요. 인터뷰에서는 필요하다고 했던 기능이 실제로는 거의 쓰이지 않기도 하고, 자주 쓴다고 말한 기능이 로그에는 잘 남아 있지 않기도 해요.

사실 이런 불일치 자체가 아주 이상한 일은 아니죠. 사람은 원래 말보다 행동에서 더 현실적으로 움직이니까요. 좋은 사용자처럼 보이고 싶어서 그렇게 말했을 수도 있고, 실제보다 더 자주 쓴 것처럼 기억했을 수도 있고, 불편했는데도 괜찮았다고 스스로 정리했을 수도 있어요. 또 지금의 의욕으로 미래의 사용 빈도를 조금 낙관적으로 예상하기도 하고요.

그래서 저는 이런 차이를 단순히 유저 심리의 문제로만 보지는 않으려고 해요. 유저의 말이 맞는지 틀린지를 가리는 데서 멈추기보다, 우리 서비스가 어떤 행동은 쉽게 만들고 어떤 행동은 어렵게 만들고 있는지도 함께 봐야 한다고 생각해요.

실제 행동으로 이어지지 않았다면 그 사이에 어떤 마찰이 있었는지를 보는 일이 더 중요하다고 느껴요. 왜 그렇게 말했는지, 그런데 왜 행동은 달랐는지를 함께 보면서 그 사이의 원인을 더 들여다보려고 노력합니다. 결국 PM이 봐야 하는 건 말과 행동 사이의 간극을 푸는 일인지도 모르겠어요.

유저의 말과 행동이 어긋날 때, 떠올리는 기준들

그래서 요즘은 유저의 말과 행동 사이의 간극을 볼 때, 제가 자주 떠올리는 기준들을 이번 기회에 정리해보려고 해요.

첫 번째는, 사람은 조금만 번거로워도 쉽게 포기한다는 점이에요. 필요하다고 말한 기능도 시작 과정이 길고 피곤하면 쉽게 포기합니다. 의지가 없는 게 아니라 그냥 덜 귀찮은 선택이 이기는 거죠.

두 번째는, 사람은 생각보다 복잡한 선택을 오래 견디지 않는다는 점이에요. 알림이 중요하다고 해도, 어떤 알림인지 헷갈리고 매번 해석해야 하고 눌렀을 때 어디로 가는지 불분명하면 결국 꺼버리게 됩니다. 정보가 아니라 작은 업무처럼 느껴지기 때문이에요.

세 번째는, 사람은 한 번 정해진 설정을 잘 바꾸지 않는다는 점이에요. 사람은 생각보다 설정을 잘 바꾸지 않아요. 특히 아직 가치를 충분히 느끼기 전 단계에서 한 번 거절한 설정은 그대로 굳어버리는 경우가 많습니다. 그래서 “왜 안 켰지?”보다 “언제, 어떤 맥락에서 켜달라고 했지?”를 보는 게 더 중요해요.

네 번째는, 나중에 얻는 보상보다 지금 느끼는 귀찮음을 더 크게 느낀다는 점이에요. 유저가 “매일 쓸 것 같다”고 말해도 실제로는 초반 세팅이 너무 길면 금방 이탈합니다. 미래의 효용보다 지금의 피로가 더 크게 느껴지기 때문이죠.

결국 PM은 유저가 무엇을 원한다고 말했는지만 볼 게 아니라, 그 행동이 실제로 일어나기 쉬운 구조인지도 함께 봐야 하더라고요.

출처 : ThinkingData

그래서 유저의 말을 바로 요구사항으로 받아들이면 안 된다고 생각해요

그래서 저는 PM이 유저의 말을 바로 기능 요청으로 받아들이기보다, 먼저 그 말이 어떤 행동으로 이어지길 기대한 것인지를 봐야 한다고 생각해요.

예를 들어 “알림이 필요해요”라는 말은 정말 알림 기능이 더 필요하다는 뜻일 수도 있지만, 어떤 순간에 중요한 정보를 놓치고 싶지 않다는 의미에 더 가까울 수도 있어요. “검색이 편해요”라는 말도 마찬가지예요. 검색 기능을 더 강화해야 한다는 뜻이라기보다, 반복적으로 찾는 대상을 더 빠르게 꺼내고 싶다는 의미일 수도 있고요.

이 유저는 왜 이게 필요하다고 말했을까. 그런데 왜 실제로는 그 행동으로 이어지지 않았을까. 정말 니즈가 약한 걸까, 아니면 중간 과정이 번거로웠던 걸까. 아직 이 행동이 왜 필요한지 충분히 와닿지 않았던 걸까, 하기에 망설여지는 이유가 있었던 걸까.

이 질문을 거치지 않으면 우리는 쉽게 “원한다고 했으니 만든다”는 방식으로 흘러가게 되더라고요. 그런데 실제로는 기능이 부족해서가 아니라, 그 행동이 일어나기 어려운 구조인 경우가 더 많았어요.

기능을 더 넣는 일보다, 행동이 일어나는 조건을 보는 일

그래서 저는 요즘 유저의 말을 어떻게 해석할지보다 그 말이 왜 실제 행동으로 이어지지 않았는지를 더 오래 보게 돼요. 유저가 필요하다고 말했는데도 실제로는 하지 않았다면, 그걸 단순히 니즈가 없다고 보기보다 중간에 어떤 마찰이 있었는지, 우리가 너무 이르게 요청한 건 아닌지, 행동하기에 번거롭거나 망설여지는 지점이 있었던 건 아닌지를 함께 보게 되고요.

실무를 하면서 비슷한 순간들이 많아요. 유저의 한마디를 바로 요구사항처럼 받아들이기보다, 그 말을 하나의 단서로 두고 실제 행동 로그와 같이 보면서 원인을 더 천천히 해석하게 되더라고요.

그 과정에서 느끼는 건, 문제는 생각보다 기능이 없는 데 있지 않고 행동이 쉽게 이어지지 않는 구조에 있는 경우가 많다는 점이에요. 그래서 요즘은 기능을 더 넣을까보다, 이 행동이 왜 아직 자연스럽게 일어나지 않는지를 먼저 보게 됩니다. 아마 지금 제가 더 오래 붙들고 있는 질문도 결국 그쪽에 가까운 것 같아요.

AI 시대, PM인 나는 어디에 집중해야 할까

pmjigu — Sun, 5 Apr 2026 00:06:07 +0900

요즘은 질문 자체가 달라졌다

빠르게 성장하고 변화하고 있는 AI시대, 요즘 AI를 둘러싼 대화는 예전과 조금 달라진 것 같아요. 처음에는 주로 생산성 이야기였죠. 어떤 툴이 더 좋은지, 누가 더 빨라졌는지, 어디까지 자동화할 수 있는지. 얼마 전까지만 해도 질문은 대체로 이거였어요. 'AI를 잘 쓰면 내가 얼마나 더 빨라질까.' 그런데 이제는 그보다 더 근본적인 질문이 남은 것 같습니다.

'AI가 이렇게 빨리 성장하면, 나와 같은 PM의 일은 앞으로 무엇이 될까.'

이 질문이 중요해진 이유는 분명해요. PM이 해오던 일 중 꽤 많은 부분이 이미 AI로 변하고 있기 때문이예요. 정리, 요약, 초안 작성, 리서치 구조화, 간단한 프로토타입 제작까지, 예전에는 분명 사람이 시간을 써야 했던 일들이 이제는 훨씬 짧은 시간 안에 가능해지고 있어요.

결국 더 중요해지는 건 판단 아닐까

그래서 앞으로 PM의 가치는 무엇일까 고민했어요. 저는 그것이 얼마나 많은 정보를 정리할 수 있느냐보다 '무엇을 판단할 수 있느냐'에서 갈릴 거라고 생각해요. AI는 선택지를 많이 만들어줍니다. 문제는 선택지가 많아질수록 판단은 더 어려워진다는 거예요. 그럴듯한 인사이트, 그럴듯한 기능 제안, 그럴듯한 문서.

앞으로는 제가 이제까지 해온 “아무것도 없는 상태에서 시작하는 일”보다 “너무 많은 답처럼 보이는 것들 사이에서 방향을 정하는 일”이 더 중요해질 것 같아요.그리고 그건 PM이 원래 맡아오던 본질에 더 가까운 일 아닐까요?

결국 PM에게 남는 일은정보를 전달하는 일이 아니라, '무엇이 중요한지 정하는 일'이라고 생각해요. 이게 정말 지금 우리가 풀어야 할 문제인지,지금 우리 팀이 붙들어야 할 우선순위인지, 겉으로는 좋아 보여도 실제로는 아닌 것은 무엇인지,
속도를 내야 하는 순간인지, 잠깐 멈춰야 하는 순간인지.

AI는 실행의 진입장벽을 낮추고 속도를 내는데 도움을 주지만 판단의 책임까지 가져가주지는 않더라고요. 그 책임은 여전히 사람에게 남고, PM은 그 중심에 있는 역할이라고 생각합니다.

출처 : miro

일하는 방식도 꽤 많이 달라질 것 같다

그렇다면 일하는 방식도 달라질 거예요.

예전에는 PM이 긴 문서와 설명으로 설득했다면, 앞으로는 더 짧고 빠르게 보여주는 방식이 중요해질 것 같아요. AI를 활용해 프로토타입을 만들고, 흐름을 빠르게 시각화하고, 실제로 작동하는 형태로 대화를 시작하는 방식이 더 자연스러워지겠죠. 저 또한 AI가 내 기능까지는 안 오겠지 저항하기보다는 새로운 일하는 방식을 받아들이고 manyfast로 기능명세서나 유저플로우를 짜고, stitch로 ui를 만들어 소통을 시작하고 claude로 데이터 분석을 하고 있습니다.

물론 그렇다고 해서 PM이 디자이너나 엔지니어가 되어야 한다는 것은 아니죠. 다만 적어도 아이디어를 말로만 다루는 역할에 머물기는 어려워질 것 같습니다. 앞으로의 PM은 생각을 빠르게 형태로 바꾸고, 그 형태를 바탕으로 더 나은 판단을 끌어내는 사람 될 것 같아요.

출처 : 모멘토스

그래서 앞으로는 이런 쪽에 더 집중해야 하지 않을까?

그래서 저는 앞으로 PM이 더 집중해야 할 역량이 무엇인지 꽤 오래 고민하고 있어요. 물론 이 생각이 답이 아닐 수도 있고, 앞으로 일을 더 해나가면서 얼마든지 달라질 수 있다고 생각해요. 그래도 지금까지 제가 고민해온 방향은 아래와 같아요

첫째는 좋은 질문을 만드는 능력.
AI 시대에는 답을 잘 찾는 것보다, 어떤 질문을 던지느냐가 결과의 수준을 크게 바뀌더라고요. 기능 요청을 그대로 받는 게 아니라, 그 뒤에 있는 문제를 다시 정의할 수 있어야 할 것 같아요.

둘째는 검증하는 능력.
AI가 만든 결과물이 많아질수록, 사람의 역할은 생산보다 검토와 승인 쪽으로 이동할 가능성이 크지 않을까요? 저와 같은 PM은 특히 제품, 사용자, 비즈니스 사이를 함께 보기 때문에 쉽지 않겠지만 무엇을 믿고 무엇을 걸러야 하는지 판단하는 역할이 더 중요해질 것 같네요.

셋째는 맥락을 읽는 능력.
지금까지 해왔던 일이지만 앞으로도 왜 지금 이 문제가 중요한지, 왜 어떤 팀은 이 결정에 불편함을 느끼는지, 왜 고객은 같은 말을 반복하면서도 다른 걸 원하고 있는지. AI가 저보다 정보를 잘 다룰수록, 이런 맥락을 읽고 의미를 해석하는 능력은 더 중요해질 수밖에 없고, 더 집중해야할 것 같아요.

넷째는 관계를 만드는 능력.
아직 저에게도 너무 어렵지만, PM은 원래도 권한보다 신뢰로 일하는 역할이었다고 생각해요. 사람을 설득하고, 시선을 맞추고, 불확실한 상황에서도 함께 움직이게 만드는 힘. 조직 간 신뢰의 기본 단위는 아직도 사람이기에 업무가 자동화되고 시스템화가 될 수록, 오히려 이 인간적 신뢰의 차별성은 더 커질 것 같아요. 그리고 이건 앞으로도 쉽게 대체되지 않을 거라고 생각해요.

결국 남는 건

앞으로 PM에게 중요한 건 툴 숙련도 자체보다 어떤 사고방식으로 일하느냐가 될 것 같습니다.

정리하는 사람보다 판단하는 사람.
조율하는 사람보다 문제를 다시 정의하는 사람.
많이 만드는 사람보다 무엇을 남기고 무엇을 버릴지 아는 사람.

그래서 저는 요즘 이 질문을 자주 떠올리게 돼요. 'AI가 대부분의 실행을 더 쉽게 만드는 시대에, 나는 어디에 더 집중하는 PM이 될 것인가.'

시스템적 사고, 높은 주체성, 성장 마인드셋, 결단력, 적응력 등등 아직도 답을 찾아가고 있는데요. 아마 앞으로의 차이는 그 질문에 얼마나 빨리, 그리고 얼마나 깊게 답하느냐에서 벌어질 것 같아 계속해서 고민해보고자 합니다.

요즘 기획자로서의 내 고민: 다음은 ‘바이브 기획’ 아닐까

pmjigu — Wed, 4 Mar 2026 17:50:06 +0900

바이브 코딩 다음은 무엇일까

오늘은 평소보다 조금 짧은 글을 남겨보려고 합니다.

요즘은 “바이브 코딩”이라는 말이 더 이상 낯설지 않죠. 코드를 ‘쓰는’ 게 아니라, 의도를 던지고 형태가 나오게 만드는 방식. 이미 많은 팀이 그 흐름 위에 올라탔고, 우리도 어느새 익숙해졌습니다.

출처 : Figma

흥미로운 건, 이게 개발만의 이야기가 아니라는 점이에요. 디자인 쪽에서도 비슷한 변화가 빠르게 오고 있죠. 최근 Figma가 2025 Config 컨퍼런스에서 ‘바이브 디자인’을 이야기하며, 디자인 영역에서도 AI 혁신을 예고하기도 했고요. “바이브 디자인” 같은 표현이 등장하는 것도 결국 같은 징후라고 생각합니다.

AI가 단순히 ‘결과물’을 만드는 게 아니라, 일하는 방식 자체를 바꿔버리는 단계로 들어왔다는 신호요.

그럼 다음은 뭘까요? 저는 요즘 그 질문을 스스로 하고 있습니다.

이제는 AI를 활용한 ‘바이브 기획’에 주목해야 할 때 아닐까요?

내가 말하는 ‘바이브 기획’과 요즘 고민 4가지

제가 말하는 바이브 기획은 이런 뜻이에요.
비즈니스 목표와 사용자의 바이브(맥락/욕구/감정/리듬)를 포착해서, 디자이너와 개발자 같은 메이커들이 즉시 이해하고 실행할 수 있는 ‘구조화된 명세’로 바꾸는 기획.

여기서 핵심은 “문서를 잘 쓰는 것”이 아니에요. 기획서를 문서가 아니라 AI가 ‘살아있는 시스템’으로 바라보는 관점 전환입니다. AI 시대의 기획은 점점 이 방향 혹은 지금과는 다른 방향으로 흘러가지 않을까요?

그래서 저는 요즘 아래 네 가지를 계속 붙잡고 있습니다.

출처 : Linkedin

1) 통합

IA, 플로우, 화면 설계, 명세서가 따로 놀면 결국 비용이 생겨요. 처음부터 끝까지 하나의 시스템 안에서 유기적으로 연결되어야 한다고 봅니다. 지금 우리가 겪는 “수동 동기화 지옥”에서, 언젠가는 정말 탈출해야 하니까요.

2) 구조화와 기계 가독성

기획서가 단순한 문서를 넘어 데이터베이스가 되어야 하지 않을까요? AI의 도움으로 기획을 정형적으로 쓸 수 있다면, 사람만 해독하는 기획서가 아니라 기계도 이해하는 기획서로 진화할 수 있다고 생각합니다. 기획이 객체처럼 구조화되면, AI 툴도 지금처럼 기획서를 ‘그림’이 아니라 ‘기획’으로 이해하기 시작할 테고요.

3) 버전 관리

“최종”, “찐최종”, “최종본” 같은 파일명으로 버전을 관리하는 시대는 이제 그만… 어제와 오늘의 변경분이 즉시 보이고, 바로 반영되는 방식이 기본이 되어야 한다고 봐요. 기획이 바뀌는 건 자연스러운 일이고, 문제는 “바뀐 게 전달되지 않는 것”이니까요.

4) 검증

기획 단계에서 논리적 오류를 먼저 검증할 수는 없을까요? 기획 단계에서 검증이 된다면 메이커들이 작업에 들어가기 전에 두 번 일하는 일을 크게 줄일 수 있을 겁니다. AI가 가장 잘 도와줄 수 있는 영역도 어쩌면 여기라고 생각해요.

요약하면 이거예요.
바이브 코딩이 “코드를 다루는 방식”을 바꿨다면, 바이브 기획은 “일을 정의하는 방식”을 바꾸게 될 거라고요. 이건 단순히 기획자 한 명의 생산성을 높이는 이야기가 아니라, 프로젝트 전체의 생산성을 끌어올리는 변화일 수도 있겠다는 생각마저 듭니다.

저는 지금 그 경계에 서 있는 것 같아 어떻게 나아가야할 지 요즘 고민입니다.

[Notion] 버튼 하나로 끝내는 협업: 노션 → 슬랙 알림 자동화 10분 만에 설정하기

pmjigu — Sun, 8 Feb 2026 01:44:52 +0900

지난 이야기

지난 글에서는 “왜 자동화를 하게 됐는지”, 그리고 “어떤 문제를 발견했고 어떤 흐름으로 바꿨는지”에 집중했어요. 이번 글은 예고했던 대로 그 연장선에서, 제가 실제로 적용한 노션 자동화 설정 방법을 최대한 짧고 따라하기 쉽게 정리한 실전편입니다. 처음 보시는 분이라면 아래 글을 먼저 보면 “왜 이 설정이 필요한지” 맥락이 더 또렷해져요.

[Notion] 같은 일을 두 번 하던 협업 프로세스, 노션 자동화로 한 번에 끝내기

결론부터 말하면, 설정 자체는 생각보다 복잡하지 않아요. 이미 우리가 겪는 문제가 무엇인지, 어떤 방식으로 해결할지 흐름은 먼저 정리해뒀잖아요. 그리고 “이벤트(조건) 발생 → 슬랙 메시지 전송(액션)” 이 한 문장만 이해하면, 아래 과정은 거의 클릭 가이드에 가깝습니다. 요즘은 ChatGPT 같은 AI 도움도 쉽게 받을 수 있으니, 설정은 훨씬 가볍게 끝낼 수 있고요 ㅎㅎ

노션 버튼 클릭 시 슬랙 알림 보내기

그럼 바로 설정으로 넘어가볼게요. “버튼 클릭 → 슬랙 메시지 전송” 이 한 흐름만 만들면, 요청/완료 등은 문구만 바꿔서 그대로 적용하면 끝입니다. 그리고 제가 어떤 기준으로 설정을 잡았는지 이해하기 쉽도록, 당시 정리해뒀던 목표·조건·동작도 함께 적어둘게요.

목표

노션 페이지에 들어가거나 메일/슬랙에서 다시 묻지 않아도, 슬랙 메시지 하나로 ‘확인’이 끝나게 만들기 (요청이든 완료든, 핵심 정보 + 링크가 한 번에 보이는 흐름)

조건(Trigger)

버튼을 누르는 순간
(저는 상태값이 바뀌는 순간에 알림을 보내기보다, 실무자가 내용을 한 번 더 확인하고 “이제 보내도 된다”는 타이밍에 누르는 별도 버튼이 지금 문제에 더 맞다고 판단했어요.)

동작(Action)

지정한 슬랙 채널로 메시지 전송
(메시지만 봐도 “무슨 요청인지 / 뭐가 완료됐는지”가 끝나야 했기 때문에, 요청/완료 모두 핵심 정보가 한 번에 보이도록 문구를 정리했습니다.)

출처 : EBS

설정 순서 — 여기만 따라오면 끝

참고로 저는 기본 언어가 영어로 되어 있어서, 예시 이미지에서는 속성값이 영어로 보일 거예요. 그래도 화면 구성과 설정 흐름은 동일해서 따라 하시는 데는 크게 문제 없을 겁니다 ㅎㅎ

1. 자동화를 붙일 노션 데이터베이스(또는 페이지 템플릿) 로 이동

2. 노션 데이터베이스 내 속성 설정하기

저의 경우, 이미지처럼 '그룹/요청자/담당자/요청일/작업마감일/비고/요청버튼/작업 상태/작업 경로/완료버튼' 으로 구성하고 시작했어요

3. 버튼을 둘 속성값 위치에서 타입을 Button으로 생성 후 속성값 이름 설정

속성 값을 버튼으로 생성(왼) / 속성값 이름 설정(오)

4. 자동화 편집 > 동작 : 슬랙 보내기 > 알림을 보낼 슬랙 채널 연결
Tip) 팀 채널에 바로 적용하기 전에 저처럼 개인 슬랙 채널로 먼저 테스트하면 실수 비용이 거의 0이에요

1. 자동화 편집 > 2. 동작 추가 : 슬랙으로 노티 보내기 > 3. 원하는 채널 검색 > 4. 선택된 채널 확인(처음에는 개인으로 설정 후 연습 추천)

5. 서식 편집 > 서식 입력

서식 편집(왼) / 서식 입력(오)

6. 추천 메시지 템플릿(복붙용)

메시지 구조를 아래처럼 먼저 텍스트로 정리해두면, 서식 작성도 쉽고 나중에 관리하기도 편해요. 제가 사용한 예시를 참고해서 그대로 복붙해서 쓰거나, 팀 상황에 맞게 살짝 수정해서 사용해보세요 ㅎㅎ 아래 예시들을 AI 프로그램에 프롬프트로 넣으면, 여러분 상황에 맞는 문구로도 쉽게 다듬을 수 있을 거예요.

6-1. [요청] 메시지 예시 * {} 표기는 속성값

안녕하세요, {IP팀 담당자} 입니다.
아트 작업 요청 드립니다.
- 프로젝트: {그룹}
- ART 담당자: {ART 담당자}
- IP 요청일: {IP 요청일}
- 아트 작업 마감일: {아트 작업 마감일}
- 내용: {내용}
- 비고: {비고}
자세한 내용은 하단의 'Open in Notion' 버튼에서 확인하실 수 있습니다.
감사합니다.

6-1. [요청] 서식 예시

lets(
  /* Get person who clicked the button */
  clickPerson, if(empty(context("Whoever clicked")), "담당자", context("Whoever clicked").name()),
  
  /* Get page properties */
  group, context("This page").prop("그룹").join(", "),
  ipManagers, context("This page").prop("ART 담당자").map(current.name()).join(", "),
  requestDate, context("This page").prop("IP 요청일"),
  enterpriseReviewDate, context("This page").prop("아트 작업 마감일"),
  content, context("This page").prop("내용"),
  remarks, context("This page").prop("비고"),
  
  /* Format dates */
  formattedRequestDate, if(empty(requestDate), "미정", formatDate(requestDate, "YYYY년 MM월 DD일")),
  formattedEnterpriseReviewDate, if(empty(enterpriseReviewDate), "미정", formatDate(enterpriseReviewDate, "YYYY년 MM월 DD일")),
  
 /* Create the formatted message */
"안녕하세요, " + clickPerson + " 입니다.\n" + 
"아트 작업 요청 드립니다.\n\n" + 
"- 프로젝트: " + if(empty(group), "미정", group) + "\n" + 
"- ART 담당자: " + if(empty(ipManagers), "미정", ipManagers) + "\n" + 
"- IP 요청일: " + formattedRequestDate + "\n" + 
"- 아트 작업 마감일: " + formattedEnterpriseReviewDate + "\n" + 
"- 내용: " + if(empty(content), "미정", content) + "\n" + 
"- 비고: " + if(empty(remarks), "없음", remarks) + "\n\n" + 
"자세한 내용은 하단의 'Open in Notion' 버튼에서 확인하실 수 있습니다. \n" + 
"감사합니다."
)

6-2. [완료] 메시지 예시 * {} 표기는 속성값

안녕하세요, {ART 담당자}입니다.
아트 리소스 작업이 완료되었습니다.
{IP팀 담당자} 님 확인 부탁드립니다.

- 프로젝트: {그룹}
- 아트 리소스 경로: {아트 리소스 경로}

6-2. [완료] 서식 예시

lets(
  project, context("This page").prop("그룹"),
  artResourcePath, context("This page").prop("아트 리소스 경로"),
  artAssignee, context("This page").prop("ART 담당자"),
  ipRequester, context("This page").prop("IP 요청자"),

  "안녕하세요, " +
  if(
    empty(artAssignee),
    "ART 담당자",
    join(artAssignee.map(current.name()), ", ")
  ) +
  "입니다.\n" +
  "아트 리소스 작업이 완료되었습니다.\n" +
  if(
    empty(ipRequester),
    "IP 요청자",
    join(ipRequester.map(current.name()), ", ")
  ) +
  "님 확인 부탁드립니다.\n\n" +
  "- 프로젝트: " + if(empty(project), "미지정", project) + "\n" +
  "- 아트 리소스 경로:\n" + if(empty(artResourcePath), "없음", artResourcePath)
)

7. 버튼명 수정 후 저장하기

기존에 속성값과 동일하게 적용되어있던 버튼명을 직관적으로 수정

8. 생성된 버튼 확인 > 버튼 클릭 > 슬랙 알림 전송 - 끝

완성된 버튼 (위) / 요청 버튼 클릭 시 슬랙 내 메세지 (아래_왼) / 완료 버튼 클릭 시 슬랙 내 메세지 (아래_오)

마무리: 설정법보다 중요한 건 “흐름”

출처 : EBS

이번 글에서 소개한 설정은 기능적으로는 단순해요.
그런데 이 단순함이 오히려 장점이었습니다. 팀에 적용하기 쉽고, 유지보수도 거의 필요 없거든요.

결과적으로는,

업데이트 누락이 줄었고
진행 상황을 “불필요하게 재확인하는 비용”이 줄었고
무엇보다 팀원들이 ‘자연스럽게’ 확인하게 되는 환경이 만들어졌습니다.

그리고 사용 방법이 어렵지 않다 보니, 편하게 쓰이면서 자연스럽게 유지됐고요. 결국 이런 작은 것들이 쌓여서 하나의 프로세스로 자리 잡는다고 믿어요.

이번 글도 누군가에게 도움이 되었길 바랍니다.
다음에도 기획자로 일하면서 남길 수 있는 기록들을 계속 정리해볼게요✍