Santa, AI Tutor for TOEIC 개발문화 개선기
제품의 이야기를 확장하는 유저 스토리 기반 개발 프로세스
안녕하세요! 뤼이드에서 Santa, AI Tutor for TOEIC 제품을 맡고 있는 Product Manager, 이승헌입니다.
앞선 <Santa, AI Tutor for TOEIC의 사용자 경험(UX) 개선기 : 취약한 개념을 기반으로 한 사용자 주도적인 콘텐츠 선택의 경험 강화하기> 에서는 제품 성공 지표를 달성할 수 있었던 이유에 대해서 사용자 경험(User Experience) 관점에서 설명했습니다. 더 나아가 Santa 팀은 토익 시장을 타겟으로 한 제품을 넘어, 영어 학습 시장에서 더 큰 고객 가치를 전달하기 위한 꿈을 꾸고 있습니다.
이를 위해서 일관적인 목표와 어떤 환경에서도 흔들리지 않고 목표에 집중할 수 있는 ‘폼’과 ‘프로세스’를 갖춰야 한다고 생각합니다. 그래서 저희는 사용자의 선택 경험을 강화하는 제품 스펙을 시작으로 사용자에게 일관적인 제품의 이야기를 전달할 수 있는 ‘개발 프로세스’를 개선하고 있습니다.
Santa 팀이 ‘유저 스토리(User story)’의 본질에 집중해서 어떻게 제품의 이야기를 가장 잘 전달할 수 있는 프로세스를 만들어가고 있는지 과정과 팀원들의 생각을 단계별로 공유하겠습니다.
Step 1. PM, 개발자, 디자이너 모두가 함께 작성하는 유저 스토리
👦🏻 승헌(Product Manager) : 이전에도 유저 스토리(User Story)를 사용하기는 했지만, ‘요구사항(Requirement)’과 동일한 의미로 쓰였습니다. 기능 개발을 위한 스펙 문서를 적을 때 PM이 습관적으로 적고 개발자에게 요청하는 제목에 불과했습니다. 이에 우선적으로 모두가 크게 의미를 두고 있지 않던 ‘제목’을 모든 협업과 커뮤니케이션의 기준이 되는 ‘목표’로 바꾸었습니다. 그리고 어떤 사용자에게(Who), 무엇을(What), 왜(Why) 해야 하는지를 데이터 혹은 적어도 명확한 논리에 기반하여 작성하도록 가이드를 제작했습니다.
또한 유저 스토리는 PM이 혼자 쓰는 것이 아니라 개발자, 디자이너, QA 엔지니어 등 팀원 모두가 대화하며 함께 쓰는 것으로 협업 방식을 변경했습니다. 모든 회의는 PM이 고객 문제와 이를 해결할 수 있는 큰 단위의 유저 스토리를 제시하면 해당 스토리 구현의 당위성과 더 나은 구현 방법에 대해서 함께 논의하는 자리가 되었습니다. 또한 스프린트 내 작업이 가능한 단위로 유저 스토리를 쪼개고, 세부적인 유즈 케이스를 적어가며 구현 계획을 세웠습니다. 대화와 합의를 통해 산출물과 성과 지표를 명확히 정의하기 시작하니 불필요한 회의나 커뮤니케이션 미스가 실제로 줄었습니다.
👩🏻💻 유진(AOS Engineer) : 요구사항이 아닌 유저 스토리 형태로 커뮤니케이션 하니 개발자가 기획 과정에 좀 더 디테일하게 참여할 수 있었습니다. 또한 해당 기능이 왜 필요한지, 언제 어디에서 이루어져야 하는지를 사용자 관점에서 공감할 수 있었습니다. 목표가 명확한 상태에서 구현 가능한 여러 UX의 형태에 대한 아이디어를 제시하고 참여할 수 있었어요.
👩🏻🔧 지연(iOS Engineer) : 자세한 유저 스토리를 함께 적고 합의했기 때문에 개발도 더 상세히 계획할 수 있었습니다. 또한 상세하게 작성된 유저 스토리를 기준으로 작업 규모를 파악했고, 개발 기간 전 전체적인 데이터 모델과 흐름을 준비할 수 있었습니다. 이는 개발 기간 중 변경 사항을 최소화할 수 있었습니다.
예를 들어, 이번에 진행한 “사용자의 주도적인 콘텐츠 탐색 및 선택의 경험을 강화한다.(선택학습 개편)” 전략을 실행할 때, 사전에 명확히 합의된 유저 스토리를 기반으로 개발 기간 전 클라이언트와 서버 개발자가 모여 데이터 흐름을 논의했습니다. 선택 학습 탭은 강의, 문제, 어휘 그리고 실전 모의고사 네 가지 하위 탭으로 구성되어 있습니다. 이번에 진행하게 된 내용은 문제 탭의 콘텐츠 구조 개편이었고, 한꺼번에 네 가지 하위 탭의 데이터를 모두 받아와서 그렸던 이전 방식과는 다르게 한 가지 탭(문제 탭)만 새로운 서비스와 API를 사용하도록 변경해야 했습니다. 그래서 겉으로 보이는 것보다 작업의 범위가 매우 크다는 점을 발견해낼 수 있었습니다.
개발 스프린트를 시작하기 전, PM에게 현재의 모바일 아키텍처 구조와 개편이 필요한 이유를 설명했고, 이에 맞춰 개발 기간 등을 조정하며 플래닝할 수 있었습니다. 개발 진행 이후에도 방향을 수정해야 하는 일 없이 준비된 mock data로 작업을 마치고 정상 작동까지 확인할 수 있었습니다.
선택학습 : Santa, AI Tutor for TOEIC의 4가지 탭 중 사용자가 주도적으로 자신이 원하는 콘텐츠를 탐색하고 소비하는 탭
Step 2. 일관적인 제품 전체의 스토리를 만들기 위한 유저 스토리 맵핑
👦🏻 승헌(Product Manager) : “우리 이제 더 이상 쪽대본 쓰지 않았으면 좋겠습니다.” 제가 프로세스를 개선하면서 가장 많이 한 말이었습니다. 제품 전체는 사용자에게 일관된 이야기를 전달해야 합니다. 하지만 스프린트 마다 시간에 쫓기며, 새로이 기획하고 만들어낸 기능들은 제품 전체의 관점에서 보았을 때, 하나의 몰입력 있는 이야기로 느껴지지 않았습니다. 결국, 제품팀은 작고 새로운 가치를 여러 개 만드는 것이 아니라, 사용자 여정 관점에서 하나의 가치가 인접한 또 다른 가치와 연결되어 더 큰 가치가 되어야 한다고 생각했습니다. 또한 기술적인 확장성이 더해져, 더 많은 사람에게 높은 접근성을 가질 수 있는 가치 그리고 제품이 되어야 한다는 생각했습니다. 이에 따라 큰 단위의 제품 전략과 로드맵을 함께 세울 수 있는 프로세스를 고민했습니다.
어떻게 하면, 애자일과 UX 방법론 등을 동시에 챙겨가며, 제품의 지속 가능한 서사(큰 단위의 제품 이야기)를 만들 수 있을지 고민했습니다. ‘유저 스토리 맵핑(User Story Mapping)’이라는 방법을 일정 분기 단위로 진행하는 것을 도입했습니다. 이를 통해 매번 새로운 기획과 이슈에 대응하는 스프린트가 아니라, 일정한 제품 전략과 이니셔티브를 실행하는 스프린트로 전환하고자 했습니다.
👩🏻🎨 보라(Product Designer) : 사용자 여정 단위로 문제를 확인하고, 이를 해결할 수 있는 이야기인 ‘유저 스토리’를 적어가며 더 장기적이고 연속적인 사용자 경험을 설계할 수 있게 되었습니다. 그리고 유저 스토리 간의 연결을 표현한 ‘유저 스토리 맵’을 통해 중장기적인 제품의 방향성, 전략을 인지하고 디자인을 진행할 수 있었기 때문에 선행적인 고민과 생각을 할 수 있게 되었습니다. 또한 함께 합의한 방향성과 유저 스토리를 기준으로 디자인을 시작했기 때문에 불필요한 디자인 공수는 줄어들었어요.
Step 3. 모두가 제품의 품질에 책임을 갖는 개발자 QA 문화
👦🏻 승헌(Product Manager) : 성숙한 제품 개발 프로세스라면, 기획된 순간부터 기획 의도가 온전히 경험(Experience)으로 사용자에게 전달된 순간까지 팀원 모두가 촉각을 곤두세워야 합니다. 그래서 QA 활동을 시작하기 전에, 담당 PM, 디자이너, 개발자가 함께 모여 통합 테스트를 진행하고, 기능 사용 경험을 지나치게 저해하는 결함은 책임지고 해결할 수 있도록 개발자 QA 단계를 추가했습니다.
사전에 디테일하게 함께 작성한 유저 스토리는 체크 리스트와 테스트 시나리오를 더욱 쉽게 만들 수 있는 기준이 되었습니다. 플랫폼별로 체크 리스트를 활용해 기능 결함이 없는지 확인했고, 발견된 에러 케이스 중에서 빠르게 개선이 필요한 스펙과 그렇지 않은 스펙을 나누어 개선 계획을 세웠습니다. 이를 통해 QA 엔지니어는 좀 더 필요한 영역에서 집중하여 QA 활동을 진행할 수 있게 되었습니다.
🧑🏼💻 재원(Web Engineer) : 생각보다 개발자들은 어이없는 실수를 자주 하고, 이런 실수들은 기본적인 체크 리스트가 있는 것만으로도 사전에 잡을 수 있습니다. 유저 스토리가 이런 체크 리스트를 만드는 데 큰 도움이 되었습니다. 유저 스토리가 적혀있으니 순조롭게 개발자 사전 테스트를 진행할 수 있었습니다. 이전에는 QA 활동 과정에서 발견되었던 버그들이 사전에 전부 해결되었고, 선택학습 경험을 개선할 때는 버그 리포트가 한 건도 발생하지 않았습니다. 테스트 관련 이점에 더해, 서로 다른 플랫폼 개발자들 간의 구현 스펙과 도메인 지식을 통일하는 데도 큰 도움이 되었습니다. 기존에는 기획안과 시안을 보고 각 플랫폼 개발자가 각자 다르게 이해하여 의도와 다른 구현이 나오는 경우가 있었는데, 사전에 이를 막을 수 있었습니다.
Step 4. 팀의 공유된 학습을 촉진시키기 위한 회고 방식
👦🏻 승헌(Product Manager) : 이전에는 스프린트 단위의 회고를 진행할 때, 목적성이 불분명해서 의미를 느끼기가 어려웠습니다. 스프린트의 개발 생산성과 팀 개선 사항을 이야기하는 자리였던 회고를, 제품 목적을 기준으로 스펙 단위의 기능 품질, UX 품질, 코드 품질, 개선 사항 등 제품에 관한 이야기를 더 많이 하는 회고로 바꾸었습니다.
회고 시 나왔던 합의된 개선사항은 즉시 백로그에 반영했고, 추후 방향성의 변화에 따라 리팩토링이 필요한 상황을 미리 적어 놓고 대응할 수 있었습니다. 이는 팀의 목표와 제품 개발 컨텍스트를 놓치지 않고 지속적으로 개선점을 발견하고, 제품을 고도화할 수 있는 Santa 팀의 중요한 규칙이 되었습니다.
👩🏻🔧 지연(iOS Engineer) : 유저 스토리는 회고 시에 해당 스프린트의 성패를 판단하는 기준이면서, 앞으로의 To-do를 만들어주는 중요한 역할을 합니다. 기존 회고 진행 시에는 스프린트의 성패를 개발 일정이 지켜졌는지 정도로 판단했기 때문에, 다음 스프린트의 달성 목표 혹은 나아갈 길을 제시하지 못했습니다. 이번에 선택 학습 팀이 모여서 회고를 진행했을 때는 유저 스토리를 기반으로 어떤 작업이 있었고, 스토리가 달성하고자 했던 목표는 달성했는지를 팀원들이 확인할 수 있었습니다. 이를 바탕으로 부족한 점을 확인하고 다음 스프린트의 목표를 수정했습니다. 물론 성취 여부와 관계없이 과정 자체가 팀원들에게 동기부여 되었습니다.
마무리하며
Santa 팀은 지속적으로 ‘애자일 팀’의 모습을 갖추고, 한 번뿐이 아닌 반복적인 성과를 내기 위해서 변화하고 있습니다. 하나의 예시로 “사용자의 주도적인 콘텐츠 탐색 및 선택의 경험을 강화한다.”는 전략 하에 지속적으로 문제를 발견하고 해결한 결과 ‘취약점 순위 기능’의 사용자 경험 및 지표 향상을 끌어낼 수 있었습니다.
조금씩 팀이 가지고 있던 문제와 비효율을 해결하다 보니 아래와 같이 다른 팀 또는 챕터에서 오히려 스토리 주도 개발 방식과 더불어 사용할 수 있는 여러 방법론 등을 제안해주고 있습니다. 이런 이야기를 들을 때마다 조금씩 구조화된, 그리고 지속가능한 방향으로 프로세스가 개선되고 있음을 느낍니다.
👱🏼♀️ 다른 팀 구성원 : “저희가 일관된 제품 메시지를 가진 제품을 만들어내기 위해, Riiid만의 방식을 담은 Product 문서 형식을 만들어볼 수 없을까요?”
👨🏼🦱 AOS 챕터 구성원 : “저희 챕터에서 BDD(Behavior Driven Design)을 이전부터 활용하고 있는데, 스토리 주도 개발 프로세스와 함께 사용해보면 좋을 것 같아요!”
구성원 모두가 조직의 목적 그리고 개개인의 성취와 성장을 견고하게 이뤄나갈 수 있는 프로세스를 함께 고민하고 만들어 나가고 있습니다. 완벽하진 않아도 올바른 방식을 찾기 위해 노력하는 Santa 팀에 많은 관심 부탁드립니다.
콘텐츠 선택 경험을 만들기 위해 함께 노력했던 Santa 팀원들입니다.
Product Manager : 이승헌 | Product Designer : 김보라 | iOS Engineer : 송지연, Yessen | Android Engineer : 박유진, 최승명 | Web Engineer : 안재원, 이호찬 | Backend Engineer : 박서연 | Contents Lab | AI Research Team | 그 외 Santa 팀원들
Santa 팀에서 저희와 사용자 가치 전달과 제품 개발 프로세스를 같이 고민하는 데에 관심 있는 분들의 합류를 기다립니다.
#뤼이드 #산타 #산타토익 #사용자경험 #유저스토리 #유저스토리맵핑 #프로세스 #개발 #개발문화 #개발자QA #품질관리 #제품관리자 #애자일 #애자일팀 #임파워드팀
#Riiid #Santa #SantaAIToeic #UserExperience #Userstory #Userstorymapping #Process #developmentculuture #qualityassurance #PM #ProductManager #Agile #Agileteam #product
