트렌드 위에서 잠시 길을 잃었던 기획자의 반성문
이력서나 포트폴리오에는 보통 정량적・정성적 성과가 돋보이는 업무 위주로 적는다. 하지만 실무자로서 진짜 레슨런을 얻는 순간은 보기 좋게 실패한 프로젝트를 마주할 때다.
나에게는 이전 회사에서 진행했던 AI 서비스 기획이 바로 그런 프로젝트였다. 성공적으로 안착했다면 메인 홈 화면의 주요 GNB로 당당히 승격할 수 있을 만큼 회사에서도 밀어주는 건이었다. 그러나 이 거대한 프로젝트는 기획, 디자인, 개발 요청까지 완료되고 프로토타입 시뮬레이션까지 돌아가는 상태에서 ‘무기한 보류’라는 처참한 성적표를 받고 말았다.
대체 왜일까? 오늘은 그 이유와, 진하게 겪은 레슨런에 대해 적어보고자 한다.
첫 시작은 "우리 서비스에도 AI를 도입해 보자"는 대표님의 한 마디였다. 서비스의 메인 프로세스인 '견적 신청'을 AI 챗봇과의 대화로 진행할 수 있으면 좋겠다는 것이 핵심 요구사항이었다. 즉시 이 아이디어를 개발 가능한 형태의 기획으로 구체화했다.
모두를 만족시킬 수는 없었다. 여러 고객군 중에서도 일정표가 담긴 PDF 파일을 이메일로 전달하는 법인 고객을 핵심 타겟으로 잡았다. 기존에는 운영팀이 일일이 일정표를 확인하며 수동으로 입력해야 했던 배차 정보를 AI가 자동으로 추출하게 만들어, 운영 리소스를 대폭 줄이는 것이 1차 목표였다. 이를 위해 왕복/편도 여부, 출발지, 목적지, 날짜, 인원 등의 필수 입력 정보와 결제 방식, 선호 차량 같은 선택 정보를 명확히 분리하여 MVP 스펙을 정의했다.
본격적으로 개발을 요청하기 전, 기획한 로직이 기술적으로 실현 가능한지 직접 검증하기 위해 두 가지 테스트 환경을 구축했다.
먼저 커스텀 GPT(GPTs)를 생성했다. 고객이 PDF를 업로드했을 때 정보가 잘 추출되는지, 누락된 정보가 있을 경우 챗봇이 어떤 톤앤매너로 질문하며 대화를 이끌어가는지 전반적인 UX를 테스트했다.
동시에 Google Sheets와 Google Apps Script, OpenAI API를 연동해 백엔드 데이터의 출력값도 시뮬레이션했다. 사용자가 입력값을 수기로 작성했을 때 AI가 임의로 데이터를 지어내는 할루시네이션은 없는지 꼼꼼히 검증했다. 또한, 시간 값을 10분 단위로 반올림하거나 시스템 오차(+30분 보정)를 해결하는 프롬프트 규칙을 직접 실험하며 AI 출력의 정확성과 안정성을 사전에 철저히 확보하고자 했다.
검증된 로직을 바탕으로 화면 구상에 들어갔다. Notion AI, ChatGPT, 듀오링고 맥스 등 유사 AI 서비스 레퍼런스를 분석해 보니, 단순 채팅만으로는 정보 수정이 번거롭고 가독성이 현저히 떨어진다는 단점이 있었다. 이에 디자이너와 논의해 대화형 인터페이스의 친숙함은 유지하되, AI가 정리한 결과값을 한눈에 보고 쉽게 수정할 수 있도록 챗봇(입력 유도) + 폼 UI(결과 확인 및 수정)가 결합된 하이브리드 형태의 PC 웹 화면 플로우를 피그마로 설계했다.
이 모든 과정을 마친 뒤, 개발팀이 바로 작업에 착수할 수 있도록 상세 요구사항을 정리해 Jira에 공유했다. 단일/다중 견적 처리 방식, 실패 시 재시도 로직, 비회원 휴대폰 인증 프로세스와 제3자 API 사용에 따른 약관 동의 가이드라인까지 빈틈없이 명세해 개발팀에 정식으로 요청을 넘겼다.
여기까지만 보면 꽤 그럴싸하고 완벽해 보이는 프로세스였지만, 현실은 결코 녹록지 않았다.
기획서를 넘기자, 현실적인 장벽이 하나둘 튀어나오기 시작했다. 우선 개발팀에서 “PDF 파일 분석부터 바로 적용하는 건 변수가 너무 많으니, 텍스트 채팅으로 단일 견적을 신청하는 것부터 차근차근 개발해 보자”는 피드백이 왔다. 기획을 덜어내어 1단계부터 착수하기로 했지만, 진짜 문제는 기능 구현이 아니라 개발팀의 깊은 한숨에 있었다.
"기존 견적 폼으로도 3분이면 충분한데… 굳이 AI를 써서 채팅으로 해야 하는 이유가 뭔가요?"
이 근본적인 의문 위로, 기술적인 문제들이 눈덩이처럼 불어났다.
AI는 생각보다 똑똑하면서도 멍청했다. 출발지와 도착지가 같으면 왕복, 다르면 편도로 인식해야 하는데 이걸 스스로 판단하지 못해 수많은 오답을 뱉어냈다. 편도인데 오는 날짜를 묻고, 세부 이동 경로만 나와야 할 곳에 점심 식사, 견학 같은 불필요한 정보까지 신나게 지어내서 출력했다. 이를 통제하기 위해 '절대 이러지 마라', '이럴 땐 무조건 이렇게 해라' 등 Instruction(제약 사항)이 끝도 없이 추가됐다.
안타깝게도 우리 팀에는 규격화된 TC가 부재했다. 기본적인 QA 가이드라인조차 없는 상황에서, AI가 뱉어내는 예측 불가능한 변수까지 맞닥뜨리니 체계적인 검증은 요원했다. 테스트를 돌리다 예상치 못한 변수가 터지면 그때그때 질문을 달고, 개발팀이 레포트를 쓰며 예외 처리를 막아내는 땜질식 QA가 반복되었다.
조그마한 오타 하나만 나도 AI의 인식률은 바닥을 쳤다. 최신 모델(GPT-4o 이상)을 적용하면 대부분의 인식 문제가 해결되었지만, 처리 시간과 토큰 비용이 기하급수적으로 늘어났다.
3분이면 끝날 직관적인 견적 신청이 채팅 입력 대기 → AI 분석 로딩 기다림 → 추출된 정보 검증 → 틀린 부분 챗봇 대화로 핑퐁하며 수정이라는 지루한 과정으로 변질되었다.
객관적인 사용자 여정을 비교해 보니 오히려 기존 폼 방식보다 더 번거롭고 느린 UX가 되어가고 있었다. 기획의 목적조차 팀원들에게 납득시키지 못한 채 끝없는 예외 케이스와의 사투를 벌이면서, 프로젝트의 동력은 급격히 상실되었다.
“견적 신청할 때 굳이 AI를 써야 하는 이유가 뭐지?”
개발팀의 날 선 의문에 기획자인 나조차도 명쾌하게 대답할 수 없었던 원인은 따로 있었다. 솔직히 고백하건대, 이 프로젝트의 진짜 시작점은 현장의 목소리나 고객의 페인 포인트가 아니었다.
이 거대한 기획의 이면에는 우리 서비스에도 최신 AI 기술을 도입했다는 점을 대외적으로 어필하려는 비즈니스 차원의 목표가 크게 자리 잡고 있었다. 기획자로서 이러한 방향성을 운영 리소스 감소와 유저 편의성 향상이라는 실질적인 서비스 가치로 연결 짓기 위해 밤낮으로 고민했다. 하지만 기술 도입 자체가 1순위가 되다 보니 기획의 논리가 빈약해졌고, 나 자신조차 온전히 납득하기 어려운 지점들이 생겨났다.
가장 큰 허들은 UI 방향성을 조율하는 과정이었다. 대화형 챗봇의 한계를 보완하기 위해 제안했던 하이브리드 형태의 화면 설계안은, AI 챗봇이라는 초기 콘셉트를 극대화해야 한다는 내부 의견에 따라 아쉽게도 채택되지 못했다. 이미 직관적이고 완성도 높은 견적 폼이 메인 홈 화면에 존재함에도 불구하고, 모든 신청 프로세스를 채팅창 안에서 완결 짓는 것으로 최종 방향성이 굳어졌다.
결국 기획 스펙을 대폭 수정하여 100% 대화형 챗봇으로 선회한 프로토타입의 결과는 참담했다. 속도는 느리고 오류는 잦아 리소스 대비 고객 효용이 너무 낮다는 경영진의 최종 판단이 내려졌고, 프로젝트는 무기한 보류되었다. 비즈니스적 브랜딩과 과시용 신기술에 눈이 멀어, 프로덕트가 진짜 해결해야 할 본질을 잃어버린 프로젝트의 예견된 수순이었다.
성공한 프로젝트는 이력서를 빛내주지만, 실패한 프로젝트는 기획자의 시야를 한 뼘 더 넓혀준다. AI 견적 신청 기능 기획을 떠나보내며 얻은 가장 큰 레슨런은 명확하다.
AI는 목적이 아니라 수단일 뿐이고, 기획의 본질은 가치를 지켜내는 것이다.
흔히 기획자의 역량을 말할 때 세밀한 기능 명세나 정교한 데이터 모델링을 높게 평가하곤 한다. 물론 이는 실무 현장에서 꼭 필요한 역량이지만, 이번 프로젝트를 겪으며 한 가지 더 중요한 사실을 깨달았다. 기획자의 역량은 여기서 멈추지 않고, 어떤 상황에서도 사용자의 진짜 니즈가 무엇인지 끝까지 놓치지 않는 냉정함까지 확장되어야 한다는 점이다.
비즈니스적으로 트렌디한 기술을 어필하고 싶은 경영진의 니즈도, 복잡한 예외 케이스를 하나하나 쳐내며 시스템을 구현하는 개발팀의 수고도 모두 프로덕트를 완성하는 소중한 자산이다. 결국 기획자는 이 양쪽 사이에서 구현의 효율을 높이는 동시에, 그 안에 담긴 기술이 과연 고객에게 진정한 가치를 주고 있는지를 끊임없이 묻고 조율해야 하는 자리에 있다. 두 역량 중 어느 하나도 소홀히 해서는 안 된다.
비록 이번 기능은 라이브되지 못했지만, 이 실패의 경험은 앞으로 내가 만들 프로덕트들이 흔들릴 때마다 기술과 가치 두 축의 균형을 잡아주는 튼튼한 나침반이 되어줄 것이다.