그때는 맞았고, 지금은 틀린 서비스 기획
IT 프로덕트 개발의 모든 것이 달라집니다.
제가 정말 좋아하는 소설이 있습니다. 미국의 소설가 "리처드 매드슨"의 "나는 전설이다"라는 호러 소설인데요. 영화를 너무 감명 깊게 본 나머지, 영화관에서 3번을 보고, DVD를 구매하고, 감독판을 본 것으로 모자라 소설 원작을 구매하여 단숨에 읽었습니다.
아무것도 남아있지 않은 영화 속 적막한 세계, 그리고 외로운 남자의 생존을 위한 사투가 그때는 왜 그리 매력적으로 느껴졌는지 모르겠습니다. 그런데 소설과 영화는 전반적인 분위기만 차용했을 뿐 정말 많이 다릅니다. 특히 소설의 주제를 완벽히 담아낸 결말은 영화 그 이상의 충격을 주었습니다.
소설은 주인공 "로버트 네빌"이 흡혈귀들에게 붙잡혀 제목과 같이 "나는 전설이다."라고 나지막이 읊조리며 끝납니다. 사실 이 소설에는 영화와 달리 좀비가 등장하지 않습니다. '흡혈귀'라고 이름 붙인 정체 모를 생명체가 등장합니다. 흡혈귀는 우리에게, 그리고 소설 속 주인공에게 '전설'로 치부되는 존재입니다. 주인공은 자신 또한 다음 세대를 지배하게 된 신인류(흡혈귀)들에게 '전설'로 남을 것이라고 생각한 것입니다. 씁쓸하지요?
AI를 본격적으로 실무에서 사용한 지 2년이 채 안되었습니다. 이대로 가면, 평범한 서비스 기획자, 디자이너, 개발자뿐만 아니라 대부분의 직군은 정말... 머지않아 전설이 될 것입니다.
이번 글은 서비스 기획의 종말 마지막 이야기이며, 서비스 기획의 전설로 남지않으려면 AI를 어떻게 사용해야 할지를 구체적으로 다룹니다. 여담으로 2년 전 '서비스 기획의 종말'이라는 글을 작성하고, 수개월 전에는 '서비스 기획의 종말 그 후'라는 글을 작성했습니다. 거기서 끝날 줄 알았는데, '트릴로지'를 쓰게 될 줄은 몰랐네요.
앞으로 더 이상 종말 시리즈는 쓰지 않을 것입니다. 다음 편부터는 이 글에서 소개된 AI기반의 제품개발 방법론을 소개하게 될 것 같습니다. 그러면 '서비스 기획의 종말' 마지막 이야기 지금 시작합니다.
어떤 사람은 AI가 아직은 멀었다고 합니다.
그리고 어떤 사람들은 AI가 다 할 것이다라고 합니다.
AI가 아직은 멀었다고 하는 사람들은 머지않아 도태될 것입니다. 제대로 도전해보지 않은 사람들이기 때문입니다. 더 위함 건 AI가 다 할 거라고 맥락도 없이 읊어대는 사람들입니다. 이들은 전부 다 사기꾼입니다. 실체없고 쓸 데 없는 강의팔이들에 불과합니다. 제대로 AI를 사용하려면 결국 직접 사용해보고, 필요한 지점을 찾아내야 합니다. 그러다보면 거대한 실체가 그려질 것입니다.
2025년은 정말 AI 때문에 정신없이 흘러갔습니다. 웹사이트 개발에 필요한 에셋을 손쉽게 제작하기도 했고, 개발 지식이 없어 엄두도 못 내던 각종 자동화도구를 말 그대로 찍어냈습니다. 이 과정에서 앞으로의 서비스기획은 정말 많이 달라질 것이라 확신했습니다.
제가 생각하기에 서비스기획자의 수직적 성장에는 한계가 뚜렷합니다. (매우 주관적)
논리적이고 명료한 PRD 작성, 화면 설계, 기초 자료 구성 등 다양한 역량들은 어느 정도 성장하면 더 나아가기 어렵습니다. 그래도 장점이 있습니다. 주변지식을 흡수하면서 수평적으로 퍼져나가기에는 더할 나위 없이 좋습니다. 개발, 디자인, 사업하다 못해 전혀 다른 분야의 지식 또한 서비스 기획자에겐 도움이 됩니다. 그러니까 서비스 기획자는 수직적 성장이 아닌 수평적 성장을 의도적 목표로 삼아야 합니다.
AI는 이러한 성장을 크게 2가지 관점에서 강력하게 촉진합니다.
1. 주변분야에 대한 학습을 매우 쉽게 합니다.
이는 서비스 기획자뿐 아니라 세상 모든 사람들의 학습에 해당됩니다. 개발 기초, SQL, 디자인과 같은 분야와 언어를 가리지 않고, 배우기 쉽게 요약하고 정리해 줍니다. 덕분에 빠르게 지식을 습득하는 게 가능해졌습니다.
2. 지식 없이도, 제품을 만들 수 있게 합니다.
모든 시도에는 결과가 남습니다. 과거에는 문서만 작성하고 끝났을 일들이 실제로 작은 제품으로 구현됩니다. 경험치에 따라 초기제품을 넘어 상업적인 수준의 제품을 개발할 수도 있습니다. 서비스 기획과 가장 가까운 주변분야인 개발과 디자인이 한 번에 해결되는 것입니다.
어찌 보면 서비스 기획자가 경쟁력을 가지기 정말 좋은 환경이 된 것 같지요?
그런데 여기서 문제가 하나 생깁니다. 이 얇고 넓은 성장을 누구나 할 수 있다는 것입니다. 서비스 기획자뿐만 아니라, 누구라도 말입니다. 단지 우리에게는 수직으로 높게 쌓기는 쉽지 않은 지식이 조금 있을 뿐입니다. 우리가 지어낸 멋진 성에는 해자가 없습니다. 해자가 없는 성은 쉽게 함락됩니다.
지금 유튜브를 켜고, "AI로 서비스 만들기" 같은 키워드로 검색하시면 투두리스트 만드는 영상만 농담 삼아 수 천 개 나옵니다. 처음엔 비웃었습니다. 이들은 서비스 기획자도 아니고, 명확하지 않은 기능명세서를 전달하고, AI와 대화를 하며, 우스운 투두리스트를 만들고 있었으니까요.
그런데 지금은 비웃을 수 없습니다. 아무것도 모르던 일반인이 Claude와 대화를 거치며, PRD를 수차례 다듬어내고, 이를 바탕으로 디자인 레퍼런스를 고르고, 개발을 시작합니다. "정말 초보적인 접근이네"라고 할 것이 아니라 진지하게 위기감을 느껴야 합니다. "어차피 저걸로 규모가 큰 제품을 만들 순 없어!"라고 안심하지 말고, 불안에 떨어야 합니다.
제미나이가 그린그림. 요즘 여기저기서 흔하게 보여서 굉장히 식상하지만, 그래도 중간은 한다.그런 걱정을 안고, AI를 툴에 접속해서 "잼미나이야 이것 좀 만들어줘"라고 입력하고 "딸깍" 클릭을 합니다. 앞서 말했던 것처럼 2025년의 절반은 딸깍 딸깍으로 보내왔는데요. 여기서 저는 굉장히 깊은 고민에 빠지게 됩니다.
직접 만든 제품을 스스로 통제하기가 어려웠기 때문입니다. 개발자라면 코드 몇 줄 수정하는 것으로 끝날 일임에도, 코딩 지식이 없는 저는 온종일 프롬프트와 씨름을 해야 했습니다.
또, AI를 규모가 큰 주요 제품기획에는 사용할 수가 없었습니다. 수십 페이지에 달하는 상세한 개발 명세서를 작성할 엄두도 나지 않았고, AI가 이를 기억하는 데에도 한계가 있었습니다.
이런 고민 끝에...
"AI야 딸깍 만들어줘" 수준이 아니라 실제 서비스 기획과 제품개발의 전체 프로세스에 AI가 함께할 수 있는 상황을 만들어야 한다는 결론에 도달합니다.
이제는 충분히 가능할 것 같다는 생각도 들었습니다. 그러려면 굉장히 큰 변화가 필요합니다. 이 거대한 변화를 이해하려면 AI를 좀 더 들여다봐야 합니다.
AI는 새로운 도구
우선 도구의 변화입니다. 아마 사무실 업무 효율은 엑셀이 등장하고, 180도 바뀌었을 것입니다. 앱 서비스 기획과 디자인은 스케치와 피그마가 등장하고 격변했고요. AI는 이 모든 상황을 다시 한번 뒤집어버릴 도구입니다. 사용방법이 조금 독특할 뿐입니다.
AI는 새로운 협업자
또 하나는, 상호작용할 대상이 하나 더 늘었다는 것입니다. 기존에는 사람과의 상호작용으로 충분했으나, 이제는 특정한 역할을 수행하는 AI라는 객체와 상호작용해야 합니다. 마우스나 키보드 클릭이 아닌, 대화와 설계를 통한 상호작용. 위에 언급한 "독특한 사용방법"입니다.
AI가 실제 서비스 기획 프로세스에 들어오려면 어떻게 해야 할까요? 그전에 답해야 할 질문이 있습니다.
여러분들은 혹시 서비스 기획을 하면서, 어떤 부분을 AI가 대체해 줬으면 좋겠다고 생각하셨나요?
사실 저는 10년 내외의 커리어를 서비스 기획과 디자인을 병행해 왔습니다. 그러다 보니 혼자 프로젝트를 진행할 때는 문서작업에 해당하는 화면 설계와 디자인을 동시에 하는 버릇이 있는데요. 당연히 1석2조이지만, 모든 세세한 기능정리가 완벽하게 이뤄진 상태로 화면을 만들지 않다 보니 세밀한 수정이 잦습니다. '상태정의', '유효성 검사', '다이얼로그 분기' 등등... 심지어 화면 번호를 바꾸는 경우도 종종 있습니다. 이미 주석을 다 작성한 상태라면, 일일이 주석을 찾아가며 '화면번호'를 고쳐 쓰기도 했습니다.
저는 이러한 작업을 '반복작업'이라고 생각했습니다. 비밀번호엔 특수문자와 숫자와 영문이 들어가야 하고, 정보수정시에는 변경사항이 있어야 저장버튼이 활성화된다거나, '만들기' 같은 버튼을 눌렀을 때 만들 수 없으면 보여줘야 하는 에러메시지 등... 하나의 서비스에는 정말 수백 개 이상의 비슷한 작업들이 존재합니다.
그래서 저는 기본적인 정보구조를 설계하고 화면을 그려두면, AI가 이런 귀찮은 주석을 직접 입력해 줬으면 좋겠다고 생각했습니다.
또, 디자인 시스템 문제도 있습니다. 컴포넌트 규격이 변경되는 경우도 잦은데요. 매 번 개발자에게 알려주지 않으면, 당연히 반영되지 않습니다. 그런데 이것도 깜빡할 수도 있고 귀찮은 일입니다. 그래서 디자인 토큰이 변경되면, 개발자가 바로 확인하고, 스테이징 서버에 배포될 수 있다면 좋겠다고 생각했습니다.
또, 기능이 구조적으로 잘 작동하는지 확인하기 위해 작성하는 '기능별 흐름도'도 편하게 만들고 싶었습니다. 내용을 쭉 써 내려가면, 자동으로 도식이 출력되는 것입니다. 물론, 이 도식이 주석작성에도 활용되면 더할 나위 없고요.
사실 더 많습니다만, 위 3개의 문장만 보아도 서비스 기획의 파이프라인에 AI를 어떻게 녹일 수 있을지 감이 오실 것입니다.
제품 개발 파이프라인의 격변
보편적인 경우의 서비스 기획은 상세한 문서작업으로부터 시작됩니다. 제품의 핵심 시장을 정의하고, 경쟁 제품을 조사하고, 제품만의 포인트를 찾아냅니다. 그리고 이러한 모든 요소를 바탕으로 제품요구사항 정의서(PRD:Product Requirements Document)를 작성합니다. 다음에는 상세한 기능명세서(Function Specification)를 바탕으로 정보 구조 설계(Information Architect)와 화면 설계(Wire Frame) 작업이 시작됩니다. 여기에 디자인이 얹히고, 사실 그전에 디자인 시스템을 먼저 구성하고 설계된 화면에 적절한 컴포넌트를 얹히기 시작합니다. 최종적으로 주석을 달고, 개발이 시작되는데요. 개발자는 기획문서를 보고 DB 구조를 설계하고, 개발 Stack을 정의하고, API명세서를 작성하고 등등의 작업을 하게 됩니다. 여기까지가 보편적으로 훑어본 제품 개발 파이프라인입니다.
제품 기획부터 출시까지, 파이프라인 (60% 정도 표현)AI가 사용된다고 해도 이 흐름은 크게 바뀌지 않습니다. 다만, 각 과정에는 분명 AI로 완벽히 대체가능한 업무들이 있습니다. 위 도식에 표시된 노랑 항목들은 진할수록 AI가 잘 대체할 수 있습니다. 물론 흰 항목들도 대체는 가능합니다만, 이건 팀바팀일 것 같습니다.
저 노란 작업들에 는 특징이 있는데요. 자료 수집 중심의 리서치, 구조화가 잘된 업무 등이 해당됩니다. 그리고... 사람이 하더라도 이해관계자들 간의 반복적인 교차 검증이 이뤄지는 작업들이지요. 이건 AI와도 마찬가지입니다. 핑퐁이 필요합니다. 대상이 AI일 뿐입니다. 격변의 핵심은 AI와 협업할 항목들을 잘 정의하고 구조화해 나가는 것입니다.
프로젝트 매니징의 격변
슬랙으로 팀원들과 대화를 나눕니다. 아니면, 회의를 녹음합니다. 그리고 AI에게 해야 할 일들을 정리 한 뒤 개발, 기획, 디자인 및 프로젝트별로 세분화된 라벨링을 알아서 적용하고, 리니어에 이슈를 생성하라고 요청합니다.
라벨을 달아두면, 관리자 입장에서는 전반적인 현황을 파악하고 이해하는데 매우 큰 도움이 됩니다. 그런데 하나하나 클릭하고 라벨을 설정하는 건 정말 지긋지긋한 일입니다. 이슈도 많게는 하루에 수십 개를 생성해야 하는데 그것도 일입니다. 개발 PM도 마찬가지일 것입니다. 티켓을 분배하고, 회수하고, 점검하고...
이제 테스트 관련 업무는 AI에게 할당하고 자동으로 테스트부터 결과보고까지 이어집니다. 운영 중에 발생하는 문제는 자동으로 이슈로 생성되고, 생성된 이슈는 다시 AI에게 할당될 것이고요.
뭔가 운율을 좀 맞추고 싶어서 억지로 격변을 끼워넣긴 했습니다만, 실제로 격변이 맞습니다. 앞으로의 서비스 기획은 정말 기존과 많이 다를 것입니다. 저 또한 아직 모든 격변을 온몸으로 때려 맞고 있습니다. 아직은 전설로 남고 싶지 않아서요.
이렇게 살아남고 생존하는 과정을 앞으로는 꾸준히 정리하며, 브런치, 블로그, 유튜브 등을 통해 소개해 나가려 합니다. 구독하고, 자주 방문해주세요.
이번 그림은 아주 유명한 그림이죠. '존 에버렛 밀레이(John Everett Millais)'의 작품. '오필리아의 죽음'입니다. 지금까지의 서비스 기획은 죽었다, 이렇게 억지로 이유를 갖다 붙이려고 하기도 했었는데요. 그냥 워낙에 멋진 그림이라 넣어봤습니다.