새로운 기능을 개발하다 보면 이런 순간이 찾아와요. 모니터에는 수십 개의 탭이 열려있고, 팀 내부 도구 사용법을 찾아보려는데 문서가 어디 있는지조차 기억나지 않죠. 결국 동료에게 메시지를 보내고 답장을 기다리면서 개발 흐름이 끊기고 맙니다. 익숙한 상황이죠?
토스 프론트엔드 챕터도 비슷한 문제를 경험하고 있었는데요. 이 문제를 조금 다르게 풀어 봤습니다. 문서를 더 잘 써서 방문하게 하는 대신, 문서가 직접 찾아가는 방식으로요.
문서의 경로의존성 깨기
문서의 경로의존성은 사용자가 원하는 정보를 찾기 위해 정해진 경로를 따라가야 하는 제약을 뜻해요. 기존의 기술 문서는 생산자 입장에서 구조화되어 있어서 사용자 입장에서 원하는 정보를 찾으려면 여러 번의 탐색, 혹은 검색이 필요하죠. 이런 문서의 경로의존성을 깨기 위해 먼저 개발자들이 어떻게 일하는지 관찰하고, 인터뷰했어요. 
개발자들이 지식을 얻기 위해 주로 사용하는 방식은 “질문하기”였어요. 옆에 있는 동료에게 물어보거나, 사내 메신저 채널에 질문을 던지는 거죠. 자연스럽고 공감되는 행동이었어요. 그래서 이런 개발자의 행동을 존중하는 방식으로 문서의 형태를 바꿔보기로 했습니다.
질문하기의 가장 큰 장점은 원하는 정보를 즉각적으로 얻을 수 있다는 거예요. 방대한 문서를 검색하고 읽는 것보다 동료에게 직접 물어보는 것이 시간과 노력 면에서 훨씬 효율적이에요. 개발자들이 문서를 더 적극적으로 활용하게 하려면, 이러한 즉각성이 문서에도 필요하다고 생각했어요. 마치 대화하듯이 문서에 질문을 던졌을 때 맥락에 맞는 답변을 바로 받을 수 있다면, 문서는 더욱 강력한 도구가 될 거예요.
그렇게 탄생한 도구가 바로 ‘박씨’에요.
박씨: 질문하면서 문서 읽기
특징: 질문하면 문서 내용을 기반으로 답변해줘요. 일의 흐름이 끊기지 않고 바로바로 정보를 얻을 수 있어요.
위치: IDE(VSCode, Cursor)와 사내 메신저에 있어요.
효과: "문서 찾기"가 아닌 "대화하듯 물어보기”로 지식을 얻을 수 있어요.
재밌는 점: 박씨는 프론트엔드 챕터 헤드 서진님의 페르소나를 따서 만들어 졌어요.


박씨는 LLM이 더 정확하고 신뢰할 수 있는 답변을 만들어내기 위해 개발된 RAG(Retrieval-Augmented Generation) 기반 챗봇이에요. 기존 문서들을 바탕으로 믿을 수 있는 정보를 답변하고, 그 출처를 함께 제공해요. 박씨를 사용하면 문서를 탐색하거나 키워드로 검색할 필요 없이, 궁금한 점을 자연스럽게 물어보면서 필요한 정보를 얻을 수 있어요. 동료에게 물어보는 것보다 더 정확하고, 누구에게나 일관된 답변을 제공한다는 장점이 있죠.
박씨가 좋은 품질의 답변을 하려면 탄탄한 기반 지식이 필요해요. 그래서 저희는 문서의 양과 질을 모두 높이는 것에도 많은 공을 들이고 있어요. 하지만 테크니컬 라이터와 소수의 개발자들만으로는 충분한 문서를 만들기 어려웠어요. 이 시스템이 확장성을 가지려면 누구나 자신의 지식을 쉽게 문서화할 수 있어야 했죠. 그래서 실록봇이라는 문서 자동화 도구를 만들었답니다.
실록봇: 대화를 바로 문서화하기
역할: 사내 메신저 대화 속 중요 정보를 쉽게 문서화해요.
작동방식: 대화 스레드에 실록봇 이모지를 붙이거나 봇을 호출하면 AI가 대화를 분석하고 요약해서  PR을 올려요.
효과: 사람이 시간을 내서 문서를 따로 작성하는 것이 아니라, 실제 문제 해결 과정에서 자연스럽게 그리고 자동으로 기록할 수 있어요.

실록봇은 팀 내에서 오가는 중요한 대화를 요약해서 자동으로 문서화 해줘요. 사실 개발자들은 사내 메신저에서 질문에 답하거나 대화하며 항상 지식을 교류하고 있더라구요. 그런 대화가 메신저에서 일어나기 때문에 빠르게 휘발되고, 반복적으로 같은 질문이 올라오는 게 아쉬웠어요. 실록봇은 메신저에서 일어나는 대화를 요약해서 문서 리포지토리에 PR을 만들어요. 메신저에 남긴 유용한 메시지나 논의 스레드를 최소한의 노력으로 기록할 수 있게 된 것이죠.
예를 들어, 어떤 버그를 해결하기 위해 나눈 대화가 도움이 됐다고 생각한 팀원이 실록봇을 호출해요. 그러면 그 대화는 바로 문서가 되고, 이렇게 만들어진 정보는 박씨가 학습해요. 덕분에 팀원들은 같은 질문을 반복할 필요 없이 실록봇이 모은 정보와 박씨를 사용해 쉽게 해결책을 찾을 수 있어요. 문서를 위한 문서 작성이 아니라, 지식이 공유되는 순간에 자연스럽게 문서가 만들어지는 거예요.
지식이 흐르는 팀
박씨와 실록봇 덕분에 이제 토스 프론트엔드 챕터는 특정 팀원에게 지식이 몰려있거나, 같은 질문이 반복되는 문제가 줄었어요. 필요한 순간에 필요한 정보가 제공되면서 팀 내 지식이 자연스럽게 흐르는 환경이 되었답니다. 그리고 이런 환경이 팀의 생산성과 효율성을 높이고 있어요. 개발자의 행동을 관찰하고, ‘기술 문서’를 정적인 정보 모음이 아니라 개발자의 학습과 문제 해결을 도와주는 시스템으로 접근했던 것이 유효했어요.
테크니컬 라이팅도 함께 진화하고 있는데요. 이전에는 공급자 관점에서 정보를 구조화하고 특정 기능을 효과적으로 설명하는 것에 초점을 맞췄다면, 지금은 개발자가 문서를 잘 사용할 수 있는 시스템을 만드는 데 집중하고 있어요. 결국 테크니컬 라이팅의 본질은 ‘어떻게 문서로 개발자의 문제 해결을 도와줄 수 있을까’이기 때문이에요.
토스 프론트엔드 플랫폼 팀은 지식을 공유하고, 접근하기 좋은 학습 인프라를 만드는 여정에 함께하실 분을 기다리고 있어요. AI 기반 문서화 시스템을 더욱 발전시키고, 코드와 자연스럽게 연결되는 문서 자동화 시스템을 만들고, 사내 메신저를 비롯한 여러 플랫폼과 잘 어우러지는 문서 생태계를 구축하는 일들이 기다리고 있어요.
개발자들이 더 효율적으로 일할 수 있는 환경을 만들어서 개발자 경험을 한 단계 높이는 일에 관심 있으신가요? 그렇다면 Frontend Platform Engineer에 지원해 주세요! 함께 더 나은 개발 문화를 만들어가요.



새로운 기능을 개발하다 보면 이런 순간이 찾아와요. 모니터에는 수십 개의 탭이 열려있고, 팀 내부 도구 사용법을 찾아보려는데 문서가 어디 있는지조차 기억나지 않죠. 결국 동료에게 메시지를 보내고 답장을 기다리면서 개발 흐름이 끊기고 맙니다. 익숙한 상황이죠?
토스 프론트엔드 챕터도 비슷한 문제를 경험하고 있었는데요. 이 

토스 프론트엔드 팀은 이제 문서를 찾아 헤매지 않아요. 문서와 AI로 개발자의 질문에 바로 답변해주는 환경을 만들고 있거든요. 개발에만 온전히 집중할 수 있는 새로운 문서 시스템, 어떻게 만들었는지 알려드려요.

토스 프론트엔드 개발자들이 더 이상 문서를 찾지 않는 이유

다른 회사나 서비스에서 만든 API를 사용해 본 경험이 있으신가요? 복잡한 API를 파악하거나 새로운 업데이트를 적용하려고 할 때 설명이 정확하지 않다면 API를 적용하는 데 어려움을 겪죠. 그래서 API를 외부 개발자에게 제공할 때, 명확하고 쉽게 이해할 수 있는 문서는 필수적이에요.
토스페이먼츠는 최고의 문서 경험을 

MDX, OAS, remark를 활용한 토스페이먼츠의 API 문서 엔지니어링에 대해 소개해요.

더 자유롭고, 빠르고, 정확하게: 토스페이먼츠 API 문서 엔지니어링

지난 콘텐츠에서는 테크니컬 라이터의 역할과 그동안 해왔던 일을 중점적으로 소개해 드렸어요. 이번 콘텐츠에서는 토스의 테크니컬 라이터가 개발자 경험 전반으로 역할을 확장해 온 이야기를 공유해요.
개발자 경험(Developer eXperience)이란?
‘개발자경험’에 대해 들어보신 적 있나요? 이제 친숙한 개념이 된 UX(

토스의 테크니컬 라이터가 하는 일에 이어, 개발자 경험 전반으로 역할을 확장해 온 이야기를 공유해요.

그 많은 개발 문서는 누가 다 만들었을까 (2) 개발자의 학습을 돕는 모든 것

안녕하세요, 저는 토스페이먼츠 테크니컬 라이터 한주연입니다. 지난 3년 동안 토스페이먼츠와 토스 커뮤니티에서 테크니컬 라이터로 일을 해왔는데요. 토스 커뮤니티의 테크니컬 라이터들은 개발자를 위한 문서를 쓰는 것뿐만 아니라, 멋진 개발자 경험을 제공하기 위해 다양한 일을 하고 있답니다. 이번 시리즈에서는 테크니컬 라이터의 

토스 커뮤니티의 테크니컬 라이터들은 개발자를 위한 문서를 쓰는 것뿐만 아니라, 멋진 개발자 경험을 제공하기 위해 다양한 일을 하고 있답니다.

그 많은 개발 문서는 누가 다 만들었을까 (1) 토스페이먼츠 테크니컬 라이터가 하는 일


Simple Questions, Big Wins.
간단한 문구에 깊은 철학을 담아낸 <Simplicity24> 가 지난 11월, 뜨거운 관심과 호응 속에 성황리에 막을 열었어요. 21년 처음 시작된 토스의 디자인 컨퍼런스 <Simplicity>는 올해로 3회를 맞이했는데요. 최신 디자인 트렌드와 실무 경험을 공유하는 것을 넘어, 디자이너들의 고민과 질문에 새로운 시각과 해결의 실마리를 제공하는 자리로 자리매김하고 있어요.
이번 아티클을 통해 <Simplicity24>의 취지와 숨겨진 비하인드 스토리를 들려드리고자 해요!

질문은 모든 성공의 시작
“성공을 만들어내는 것은 정말 간단한 질문에서 시작된다”
이번 <Simplicity24> 를 관통하는 핵심 메시지로, 디자인의 본질을 다시 생각하게 만드는 말이에요. 디자인의 본질은 문제를 해결하는 데 있으며, 그 시작은 작고 사소한 질문에서 비롯될 수 있다는 점을 강조하고 싶었다고 해요. 이번 컨퍼런스 기획을 주도한  Product Designer (Tools) 챕터에서는 이 메시지의 의도에 대해 이렇게 설명을 덧붙였어요.
“디자이너가 이런 질문을 던졌기에 더 다양한 시도와 과정을 거칠 수 있었고, 결국 의미 있는 결론에 도달할 수 있었다고 생각해요. 이번 <Simplicity24> 세션에서는 ‘지표가 좋으면 UX도 반드시 좋은 걸까?’, ‘어려운 기능은 꼭 설명해야 할까?’ 같은 질문들이 다뤄졌는데요. 이러한 사례를 공유하며, 컨퍼런스 참가자 분들께서 이미 떠올려본 질문에 공감하거나, 앞으로 이런 질문을 던져볼 계기가 되길 바라는 마음이에요.” 

”그리고 그렇게 된다면, 메시지가 잘 전달되었다고 느낄 수 있을 것 같아요.”

Product Designer (Tools) 오지은 님
B2B SaaS 제품을 만드는 디자이너들은 업계 특성 상 참고할 수 있는 공식이나 환경이 부족해 고민을 해결하기 어려운 경우가 많은데요. 이번 <Simplicity24> 에서 다뤄진 토스 Product Designer (Tools) 의 경험이 이러한 디자이너에게 실무적인 참고 자료로 활용되는 동시에, 혼자서 고민하던 문제들에 공감할 수 있는 장이 되길 기대해요.

디테일은 메시지를 담는 그릇
컨퍼런스를 준비하는 과정은 작은 질문에서 시작된다는 철학과 닮아 있었어요. 모든 요소의 디테일을 통해 컨퍼런스 참가자에게 더 나은 경험을 전달하기 위해 설계되었거든요. 
“처음 맥북 내부를 열었을 때를 잊을 수 없어요. 보이지 않는 내부를 이렇게 아름답게 만들다니. 토스도 이와 같은 정신을 가지고 있다고 생각해요. 겉으로 드러나는 부분 뿐 아니라, 보이지 않는 내부까지도 치열하게 고민하며 디자인하거든요.”

Product Designer (Tools) 이다윗 님
토스 서비스 또는 내부 효율화 제품도 이러한 철학이 깃든 결과물이에요. 이번 컨퍼런스를 통해 이 같은 디테일의 중요성을 보여주고, 업계 디자이너들에게도 공감과 동기를 제공하고자 했어요. 특히, 보이지 않는 곳에서 노력하는 디자이너들이 더욱 인정받고 공감 받는 계기가 되었으면 하는 바람도 담겨 있어요. 

디테일에 담긴 노력, 하나
컨퍼런스 참가자를 위한 환경 만들기
 “더욱 편리하고 몰입감 있게 경험할 수 있는 환경, 어떻게 만들 수 있을까?”

이번 <Simplicity24> 는 단순히 사례를 공유하는 것을 넘어, 컨퍼런스 참가자들이 더욱 편리하고 몰입감있게 컨퍼런스를 경험할 수 있도록 디테일까지 세심하게 신경 썼어요.
특히, 작년에 진행된 <Simplicity23> 에서 받은 피드백이 이번 컨퍼런스 설계에 큰 영향을 미쳤는데요. 피드백을 철저히 반영해 홈페이지의 무거운 동작을 최적화하고, 자막 이동을 더욱 직관적으로 개선했어요. 작은 참고 이미지는 크고 선명하게 보이도록 업데이트 했어요.
이러한 노력은 단순한 기능 개선을 넘어, 컨퍼런스 참가자에게 더 나은 학습 경험을 제공하기 위한 필수 과정이었는데요. 결과적으로 이러한 디테일에 대한 집착이 컨퍼런스의 메시지를 더욱 선명하고 효과적으로 전달하는 데 큰 기여를 할 수 있었다고 해요.

디테일에 담긴 노력, 둘
보이지 않는 곳에 담긴 노력과 철학
 “어떻게 하면 모두가 ‘이게 진짜 문제구나’ 하고 느끼게 만들 수 있을까?” 
15~20분이라는 짧은 시간 안에 제품, 도메인, 디자이너의 역할은 물론 문제 상황의 배경과 해결 과정을 모두 쉽게 표현하는 일은 예상보다 훨씬 어려운 일이었어요.
내부에서는 리뷰 시간을 통해 서로 맥락을 이해하고 있었기에 비교적 간단해 보였지만, 컨퍼런스 참가자는 이런 배경 지식이 전혀 없는 상황을 가정해야 했어요. 그 결과, 설명해야 할 내용이 훨씬 많아졌고, 이를 간결하면서도 효과적으로 전달하기 위한 고민이 필요했어요.





단어 선택부터 이해를 돕는 이미지 제작, 설명의 깊이를 어디까지 조절해야 할지 까지 세세하게 신경 써야 했어요. 어떤 부분은 비유를 통해 설명하는 것이 효과적이었고, 또 다른 부분은 실제 제품을 보여주는  방식이 더 적합했죠. 하지만 케이스마다 요구 사항이 달라 일관성 있는 이미지를 만드는 것도 쉬운 일이 아니었어요. 이러한 밸런스를 잡아가는 과정은 큰 도전이었지만, 메시지를 효과적으로 전달하기 위해 반드시 필요한 작업이었어요.

대본을 최소 10번 이상 퇴고하고, 말투와 호흡까지 신경 썼고, 대본을 외우고 또 수정하며 완성도를 높였어요. 문제 상황을 단순히 정보 전달에 그치지 않고, 컨퍼런스 참가자로 하여금 “이게 진짜 문제구나” 하고 느끼게 만드는 것이 목표였기 때문이에요. 촬영과 재 촬영을 반복하며 디테일에 집착한 이 과정은 더 나은 메세지를 전달하기 위해 최선을 다한 흔적들로 가득하다고 생각해요.

디테일에 담긴 노력, 셋
끝없는 협업의 연속, 토스 팀이라서 가능했던 결과
 “마지막까지 계속된 고민, ’이게 더 좋지 않을까?’”
영상, 그래픽, 개발, 마케팅, 굿즈 제작까지 각 분야에서 전문가의 도움과 높은 퀄리티를 유지하는 과정이 필수적이었어요. 하지만 결과물에 대한 기대치가 높은 만큼 정해진 일정, 제한된 리소스, 예산 안에서 이를 조율하는 일이 결코 쉽지 않았어요. "처음부터 이렇게 진행했더라면 더 좋았을 텐데"라는 아쉬움을 반복하며 시행착오를 겪을 수 밖에 없었어요.
특히, 이번 컨퍼런스에서 다뤄지는 주제의 특성 상 개인정보 보호, 법무, 기술 보안, 커뮤니케이션 등 다양한 분야의 검토가 필요했는데요. 내부 비즈니스와 프로세스가 노출될 가능성이 있는 부분은 특히 세심한 검토가 요구되었고, 이로 인해 예상보다 많은 시간이 소요되었어요.
결국 이러한 문제들을 해결할 수 있었던 건 토스 팀의 협업 덕분이었어요. 모든 팀원이 마치 자신의 일처럼 나서서 도와준 덕분에 해결할 수 있었어요. 늦은 시간까지 도움을 주신 분들도 계셨고, 그 덕분에 무사히 런칭을 마칠 수 있었어요. 모두가 함께했기 때문에 가능했다고 생각해요.
”디자이너로서 제품 런칭 경험은 많았지만, 하나의 컨퍼런스를 세상에 내놓기 위해 이렇게 많은 사람들의 노력과 협업이 필요하다는 것을 새삼 깨달은 경험이었어요. 아쉬움도 남지만, 컨퍼런스의 이터레이션을 통해 다음에 더 완성된 모습을 기약하며 마무리하고 싶어요.”

”함께 준비한 팀원들의 모습을 보며, 본업과 병행하면서도 각자 맡은 역할을 넘어 더 나은 결과물을 위해 노력해주신 점에서 많은 것을 배울 수 있었어요. 마지막까지 "이게 더 좋지 않을까?"를 고민하며, 여러 요청과 피드백을 모두 소화해주신 연사분들께도 깊이 감사드려요.”

Product Designer (Tools) 이지현 님
질문이 열어준 가능성
“작은 질문에서 시작된 변화가 여러분의 다음 여정을 더욱 빛나게 하길 바랍니다”
이번 <Simplicity24>는 단순히 사례를 공유하는 자리가 아니었어요. 질문을 던지고, 그 질문이 만들어낸 과정을 공유하며, 디자이너들끼리 서로 공감하고 연결되는 시간이 되고자 했어요. 
각 회사의 보이지 않는 곳에서 묵묵히 노력하는 디자이너들이 많다는 걸 알기에, 이번 컨퍼런스가 그분들에게 공감과 힘이 되길 바라는 마음이에요. 
다음 Simplicity를 향해서
<Simplicity> 시리즈는 앞으로도 계속될 예정이에요. 이번에는 B2B와 내부 고객을 위한 제품을 다루는 Product Designer(Tools)들의 이야기를 중심으로 했지만, 다음에는 UX Platform 등 다른 디자인 직군의 이야기가 이어질 계획이에요. 각 챕터의 특색을 살려 더 다양한 주제를 다루며, 더욱 풍성한 이야기를 공유할 예정이라고 해요.
앞으로도 이어질 <Simplicity> 시리즈에 많은 기대 부탁 드릴게요.



Simple Questions, Big Wins.
간단한 문구에 깊은 철학을 담아낸 <Simplicity24> 가 지난 11월, 뜨거운 관심과 호응 속에 성황리에 막을 열었어요. 21년 처음 시작된 토스의 디자인 컨퍼런스 <Simplicity>는 올해로 3회를 맞이했는데요. 최신 디자인 트렌드와 실무 경험을 공유하는 것

Simple Questions, Big Wins.

지난 11월, 뜨거운 관심과 호응 속에 성황리에 막을 연 <Simplicity24>의 숨겨진 비하인드 스토리를 전해드려요!

Simplicity24, 성공의 문을 여는 가장 평범한 질문

안녕하세요. 저는 토스 팀원들이 더 쉽고, 효율적으로 유저 리서치를 할 수 있는 환경을 만드는 일을 하고 있어요.
유저 무물데이를 어떤 분들이 어떻게 활용하고 있는지 살펴보니, PD (Product Designer)분들이 제품 출시 전, 프로토타입 테스트 용도로만 주로 활용하고 있는 것을 발견했어요.
프로토타입 테스트뿐 아니라 제품 배포 후 실제 앱에서 사용자들이 어떻게 쓰는지 보는 것 또한 프로토타입 테스트만큼 중요한데, 라이브 환경에서 사용성 테스트 (UT)는 많이 하고 있지 않다는 것을 데이터로 확인했어요.
그래서 몇몇 PD분들을 만나 그 이유를 여쭤봤어요. 제품 배포 후에는 데이터가 쌓이니 지표나 다양한 채널로 들어오는 cs나 voc를 통해 문제를 파악하거나 A/B 테스트로 검증할 수 있어 굳이 리소스를 들여 사용자를 만나 정성조사를 할 필요를 못 느끼는 분들도 있었고, 라이브 UT에서 문제가 나와도 당장 사일로에서는 매출, 유저 수, 리텐션 등 지표와 관련 있는 다음 실험을 준비하기 때문에 우선순위에 밀려 제품 개선이 이루어지기 쉽지 않다고 이야기해 주시는 분들도 있었어요. 
PD분들은 사용성에 문제가 있다는 것을 인지하고 있더라도, 제품은 팀원들 다 같이 만들다 보니 제품을 변경하려면 공감대 형성이 필수적이었는데 혼자서는 라이브 UT를 진행하는 것부터 진행 후 문제 개선을 설득하기 쉽지 않았던 것이죠. 


사용성 문제. 중요한 건 알지만..
각 팀에서는 매출, 전환율 등 팀의 목표 달성이 중요하다 보니, 전체 제품의 정성적 사용성에 대해서는 우선순위가 밀릴 수밖에 없었어요. 이 문제를 중요하게 생각하는 팀원이 있다고 해도, 나머지 팀원들과 공감대를 형성하려면 논의가 길어져서 시간이 오래 걸리는 문제도 있었죠. 사용성을 중요하게 생각하는 프로덕트 디자이너는 어떤 디자인이 사용성이 좋고, 좋지 않은지 알고 있지만 다른 팀원들은 사용자의 경험을 직접 본 적이 없기 때문에 공감하기 어려워하는 상황이 발생했어요.
그래서 PD 분들뿐만 아니라 사일로 구성원 모두 비슷한 유저 감수성을 갖는 것이 중요하겠다 생각했어요. 우리는 토스 앱을 매일 보니 너무나 쉽고 당연하게 이용하는 것도, 유저는 못 보고 지나치거나, 이해하지 못하고, 이용하기 어려워한다는 것을 말로 설명하는 것보다 직접 보여 드려야겠다고 생각했죠.
게다가 PD, PO (Product Owner), PM(Product Manager), 이 외의 개발자, DA(Data Analyst) 등 다른 직군들은 열심히 제품은 만들고 계시지만, 실제로 유저가 어떻게 쓰는지 볼 기회가 없었어요. 이러한 기회를 만들어 주는 것이 필요하겠다고 생각했어요.


어떻게 중요성을 효과적으로 알릴 수 있을까?
사일로 팀원들이 뚜렷한 목적이나 준비를 하지 않더라도 사용자 인터뷰에 참여해 생생한 유저의 목소리를 듣는다면, 유저에 대한 공감대가 높아지고 유저 리서치의 중요성과 필요성을 체감할 것이라고 생각했어요.
유저의 생생한 목소리를 듣도록 하려면, 듣는 것 이 외의 모든 준비 과정이나 허들을 없애야 한다고 생각했어요. 그리고 실제로 아무 준비 없이 몸만 와도 괜찮다고 공지를 하고 실제로 팀원들도 그렇게 느낄 정도로 물리적, 심리적 허들을 낮추는데 집중했어요.
첫 번째로 고려했던 것은 시간이에요. 다들 미팅, 본업 등으로 바쁘시다 보니 1시간 동안 시간을 내라고 하면 부담스러워할 것 같았어요. 그래도 사일로 구성원들끼리 보통 점심을 같이 먹기 때문에, 따로 시간을 내거나 약속할 필요 없는 점심시간으로 시간을 설정했어요.
두 번째로는 모든 준비를 다 해주고 몸만 오도록 하는 것이었어요. 시간은 맞췄는데, 프로그램 신청과 참여를 위해 준비를 많이 해 오도록 하면 부담을 느끼실 것 같았어요. 그래서 유저에게 궁금한 것만 말씀해 주시면, 사용자 리크루팅부터 질문지 설계, 인터뷰 진행까지 모두 다 대신해 드렸어요. 심지어 점심 메뉴 세팅까지 대신해 드렸니, 얼마나 가볍게 오면 되는지 아시겠죠?
세 번째로는 인터뷰 주제였어요. 프로그램을 통해 주고자 했던 밸류를 사일로 구성원들 모두 얻어 갈 수 있도록 하기 위해서 제일 신경을 썼던 부분인데요. 직군과 상관없이 모두 관심을 가질 수 있어야 하기 때문에, 인터뷰 주제와 질문지 구성이 중요했어요. 점심시간으로 프로그램이 짧다 보니 많은 유저를 만날 수 없었고, 인터뷰 시간도 길게 잡을 수 없었어요. 그리고 단순히 유저의 경험을 듣는 것보다는 본인들이 개발한 화면이 유저의 휴대폰에서 어떻게 구현되는지 직접 보는 것이 개발자분들에게 더 신선할 것 같았어요. (간혹 숨어있는 버그도 덤으로 찾아갈 수 있고요!)
그래서 20분씩 2명의 다른 세그먼트의 유저를 만나 평소 제품 사용 경험을 토스 앱을 보며 질문했어요.

10분
처음 10분은 팀원들과 인사를 나누고 프로그램에 대해 소개해요.

20분 X 2명
그리고 20분씩 2번의 유저 인터뷰를 진행했어요. 이때 팀원들이 질문을 슬랙에 남겨주면 바로 질문해 되도록 궁금한 점을 해소해 주기 위해 노력했어요.

PD, PO 뿐만 아니라 데이터 직군, 개발자도 활발하게 궁금한 것들을 질문해 주셨어요.


10분
마지막 10분은 인터뷰 내용 중 어떤 부분이 인상적이었는지 등 간단히 후기를 질문하고 마무리했어요. 
그리고 유저 리서치가 무엇이고, 어떻게 활용하는 것인지 모르는 분들도 계시기 때문에 단 2명의 유저를 만나는 것이고, 이 2분이 우리 제품을 쓰는 모든 유저로 일반화하지 않도록 같이 말씀드렸어요.
프로그램이 종료했는데도, 사일로 팀원들끼리 치열하게 앞으로 제품 방향성에 대해 남아서 이야기하는 모습을 볼 수 있었어요.
 
프로그램 참여 이후
참가한 대부분의 팀원들이 캐주얼하고 부담 없이 유저의 목소리를 들을 수 있어 좋았고, 우리에게 당연한 것이 유저에게 당연한 것이 아니라는 것을 보게 되어 유익했다고 공통적으로 이야기해 주셨어요. 이런 후기를 유저를 접할 기회가 없었던 DA, 개발자 등 직군 상관없이 모두 해 주신 이야기라 더욱 뜻깊어요.





물론 크고 작은 사용성 문제가 나왔는데요. 따로 고쳐달라고 요청드리지 않았는데도, 현재 사일로 지표와 무관한 문제를 개발자분께서 따로 챙기고 계셨어요.


어떻게 제품을 만드는지가 유저가 제품을 어떻게 쓰는지에 영향을 미치는 것을 직접 보게 되었고 더욱 제품에 대해 주인 의식을 갖고 고객 관점에서 고민할 수 있는 계기를 마련한 것 같아요. 프로세스를 단축하거나 리서치 도구를 새롭게 만드는 것뿐만 아니라 팀원들끼리 비슷한 공감대를 형성하는 것과 리서치를 더 부담 없이 하도록 환경을 마련하는 것 또한 효율화의 일환이라고 생각해요.




적용해보기
사용성 문제. 팀원들을 설득하기 어렵나요? 유저 리서치 보다 데이터로, 실험으로 충분하다고 생각하는 분위기인가요? 그렇다면 다 같이 유저 인터뷰를 해 보세요.
우리 제품을 이용하는 유저는 정말 다양해요. 데이터로 보지 못 한 유저의 맥락을 지레짐작하기보다는 유저를 직접 만나 물어보세요. 그리고 단순히 인터뷰 결과를 정리해 팀원들과 공유하기보다는 시간이 괜찮다면 팀원들과 함께해 보세요. 팀원들과 제품을 바라보는 시각을 맞추고 논의를 훨씬 효율적으로 만들어줄 거예요.



안녕하세요. 저는 토스 팀원들이 더 쉽고, 효율적으로 유저 리서치를 할 수 있는 환경을 만드는 일을 하고 있어요.
유저 무물데이를 어떤 분들이 어떻게 활용하고 있는지 살펴보니, PD (Product Designer)분들이 제품 출시 전, 프로토타입 테스트 용도로만 주로 활용하고 있는 것을 발견했어요.
프로토타입 테스트뿐 

“유저 무물 런치" 프로그램을 통해 제품 개발에 유저 감수성을 높인 과정에 대해 알려드릴게요.

토스 팀은 점심 시간에 사용자를 만난다

🤔 ’사용자는 이 페이지를 어떻게 이해할까?’ 
🤔 ‘화면이 복잡해 보이진 않을까?’ 
🤔 ‘이 그래픽은 어떤 의미로 느껴질까?’ 
제품을 만들다 보면 사용자에게 궁금한 점이 참 많이 생기는데요, 내가 원할 때마다 사용자를 만나 궁금한 점을 물어볼 수 있다면 얼마나 좋을까요? 
토스에서는 디자이너분들이 더 자주, 빠르게 제품의 사용성을 점검할 수 있게 토스 사용자처럼 학습된 AI ‘휴리봇’을 만들었어요. 휴리봇에게 내가 디자인한 화면을 보여주고 사용성과 관련된 질문을 하면 토스 사용자와 흡사한 의견을 줍니다. 단 몇 초만 에요.  
혹시 AI 제품을 만들기 위해 그동안 ‘프롬프트 엔지니어링’만 신경 쓰고 계셨다면, 이번 글을 통해 실무에서 AI를 실제로 잘 활용하기 위해 프롬프팅 외에도 필요한 것들을 프롬프팅 전-중-후 단계 별로 알려드릴게요. 이해하기 쉽게 휴리봇을 제품화 하는 과정을 함께 설명해 드리면서요.
*프롬프트(prompt)란? 생성형 AI에 특정 작업을 수행하도록 지시하는 자연어 텍스트로, 고품질의 아웃풋을 생성하기 위해 프롬프트를 최적화하는 프로세스를 ‘프롬프트 엔지니어링’이라고 함


01) 프롬프팅 전
해결하고자 하는 문제 좁히기 
프로젝트를 시작할 때 우선으로 해야 하는 일은 해결하고자 하는 문제와 목표를 뚜렷하게 정의하는 것이에요. 어쩌면 당연한 이야기처럼 들릴 수 있지만, 그것이 명확해야 진행 과정에서 다시 처음으로 돌아가거나 막히는 일을 줄일 수 있어요. 
휴리봇으로 해결하고자 했던 문제는 ‘UT의 스케일업’이었어요. 토스에는 ‘유저 무물데이’ 프로그램이 있어 디자이너가 원할 때면 언제든 사용자를 만나 온라인 UT 할 수 있는 환경이 잘 마련되어 있는데요. 
*유저무물데이란?  랜덤한 토스 사용자를 대상으로, 원하는 시간에 비대면 UT를 할 수 있는 프로그램 (자세한 내용은 아티클에서 확인할 수 있어요)
프로세스가 잘 마련되어있더라도, 디자이너가 UT를 하기 위해서는 UT용 프로토타입이나 질문지 등 필수적으로 준비해야 하는 것들이 있기 때문에 최소 1시간 이상의 준비 시간이 필요하고, 사용자를 만나는 게 심리적인 부담이 되어 더 많은 준비를 하게 될 때도 있어요.    
아주 중요하거나 복잡한 제품일 경우, 사용자에게 사용성을 검증하는 것이 필수적이라 이 시간이 어쩔 수 없지만, 화면 내에 있는 작은 그래픽 하나, 한 문장, 작은 버튼의 사용성을 확인하기 위해서도 이런 준비 과정이 필요했기 때문에 빠르게 배포해야 하는 제품일 경우 UT를 진행하지 않고 바로 실험하거나, 주변에 있는 다른 직군의 팀원에게 “OO님, 이 문장 무슨 뜻인 것 같아요?”,”OO님, 이 그래픽 어떤 의미로 느껴져요?”라고 물어보며 게릴라 UT로 사용성을 확인하는 경우도 있었어요. 
현재의 방식으로는 UT의 스케일업이 어렵고, 디자이너가 지금보다 훨씬 자주 가볍게 사용성을 점검하게 하려면 완전히 허들을 낮춘 새로운 UT 방식이 필요하겠다는 판단이 들었어요.    

프로젝트 목표 정의하기
문제를 좁혔다면, 이것이 해결되었을 때 어떤 모습이길 기대하는지 목표를 정의해야 해요. 목표가 명확하면 AI 봇으로 만들고자 하는 상이 명확해지고, 그럼 프롬프팅을 훨씬 더 효율적으로 쉽게 할 수 있어요. 
디자이너가 가벼운 사용성 점검을 자주 하게 하려면, UT를 준비하고 진행하는 것에 대한 허들을 완전히 부숴야겠다고 생각했고 AI를 활용해 보기로 했어요. 토스 사용자처럼 학습된 AI 봇이 있다면 사용자를 만나지 않고도 채팅으로 대화하며 제품의 사용성을 빠르게 점검할 수 있겠다고 생각했거든요. AI 봇을 만드는 것 외에도 UT 질문지를 템플릿화한다든지, 무물보다 훨씬 가벼운 프로그램을 기획한다든지 여러 가지 액션 아이템들이 떠올랐지만, 그 중 가장 임팩트 있고 빠르게 실험해 볼 수 있는 아이템으로 AI 봇을 선정했어요. 
봇으로 달성하고자 하는 목표가 뚜렷해지니 봇이 해줘야 하는 역할을 쉽게 구체화하고 좁혀나갈 수 있었어요. 휴리봇의 목표는 ‘디자이너가 가볍게 훨씬 자주 사용성을 점검하게 되는 것’이에요. 그러려면 이 봇이 실제로 디자이너분들이 자주 만나는 사용자가 되어야겠죠. 그래서 디자이너분들이 자주 인터뷰하시는 사용자 그룹의 특성을 파악하고, 봇이 최대한 그 사용자를 닮게 만들어야겠다고 생각했어요. 예를 들면 전체 디자이너분들이 쓰시는 게 목적이니까 특정 제품에만 적용되는 10대 사용자보다는, 20~40대 사용자를 선택하는 게 맞는 거죠.
그다음에는, 디자이너분들이 UT에서 주로 어떤 질문을 하는지 살펴봤어요. 제품마다 여러 가지 질문이 있긴 했지만, 인터뷰마다 공통으로 하시는 질문들이 있더라고요. 예를 들면 “이 화면이 어떻게 이해되는지 설명해 주세요.” “이 버튼을 누르면 다음 화면에 뭐가 나올 것 같으세요?” 같은 질문들은 제품 종류와 상관없이 공통적으로 하는 질문이에요. 이 질문들을 봇에게 물어봐서 답변을 받을 수 있다면, 실제 사용자를 만났을 때는 이 질문을 생략하고 그 시간에 더 상세한 질문을 할 수 있게 되겠죠.
이렇게 봇으로 해결하고자 하는 문제와 봇이 해줘야 하는 역할, 기능에 대해 명확하게 정의해야 프롬프팅을 더 효율적으로 빠르게 할 수 있어요. 뚜렷한 목적 없이 막연히 ‘이것도 되고, 저것도 되는 봇’을 만들다 보면 프롬프팅은 더욱 복잡하고 어려워지거든요.

공감대 형성하기
팀원들이 잘 사용하는 AI 제품을 만들기 위해서는 문제와 목표에 대한 공감대를 형성하는 것이 매우 중요해요. AI를 도입하려는 이유가 명확하지 않거나 팀원들이 그 필요성을 느끼지 못한다면, 제품은 제대로 활용되지 않을 가능성이 크거든요.
휴리봇이 해결하려는 문제인 ‘UT의 확장’은 팀원들 모두가 공감하는 부분이었지만, 이를 해결하는 데 AI가 반드시 필요하냐는 점에 대해서는 일부 팀원분들의 우려가 있었어요. 토스에서 실제 업무에 AI를 많이 활용하고 있긴 하지만, AI는 사용자의 의견을 대체할 수 없으며 AI가 생성한 답변을 실제 사용자의 의견이나 검증된 답변으로 착각하는 것이 위험할 수 있다는 의견이었죠. 이는 AI 제품 도입에 있어 흔히 제기될 수 있는 우려이고 충분히 공감되는 부분이긴 했지만, 이러한 우려가 AI의 역할을 지나치게 제한하거나 가두는 이유가 되어서는 안 된다고 생각했어요. AI가 할 수 있는 것과 없는 것을 나누는 것보다는 AI를 우리가 ‘어떻게 활용하는지’가 더 중요하다고 생각했거든요. 
그래서 저는 휴리봇의 역할은 사용자를 대상으로 하는 UT와는 명확히 다름을 설명해 드렸어요. 사용자분들을 통해서는 사용성을 ‘검증’할 수 있으나, 봇으로 할 수 있는 것은 검증의 영역 아닌 ‘점검’임을요. 사실 실제 사용자의 의견이라고 하더라도 결국 그것을 반영하는지는 디자이너의 판단이거든요. AI가 하는 말도 납득이 가능하다면 반영하는 것이고, 그게 아니라면 디자이너의 판단으로 반영하지 않을 수도 있다고 생각했어요. 
이런 봇의 역할에 대해 명확히 알렸고, 제품 관점에서도 우려되는 부분을 방지할 수 있는 장치들을 고려했어요. 그 이후에도 실제 휴리봇의 결과값들을 공유해 드리며 긍정적인 기대감을 가질 수 있도록 했어요. 


02) 프롬프팅 중
(프롬프트 엔지니어링 팁은 다음 아티클을 통해 공유 드릴게요.) 
초기 제품으로 가치 검증하기
프롬프트 엔지니어링을 하다 보면 ‘완벽한 프롬프트’를 짜는 것에 매몰되어, 너무 많은 시간을 쏟게 될 수 있어요. 그래서 적정 시점에서 테스트를 멈추고, 실제 사용자의 의견을 들어보는 것이 중요해요. 사용자 피드백은 프롬프트를 개선하는 데에 있어 필수적이고, 이를 통해 AI 제품으로 주고자 했던 가치를 효과적으로 검증해 볼 수 있어요. 
휴리에게 실제 사용자를 대상으로 진행한 UT와 똑같은 질문을 했을 때 사용자와 거의 흡사한 답변을 하던 시점에, 제 고객인 디자이너분들을 대상으로 테스트를 했어요. 중요한 건 너무 많은 개발 리소스를 쓰지 않고 저렴하게 검증해 보는 것이었기 때문에, 개발이 전혀 필요하지 않지만 커스텀이 가능한 챗봇을 활용했어요. 
테스트 방식은 간단했어요. 디자이너 본인이 작업 중인 화면 이미지를 넣고 해당 화면에 대해 UT를 하게 했고, 휴리봇이 해주는 답변이 실제 사용자와 유사하다고 생각하는지, 적절한 피드백이라고 여겨지는지 다양한 의견을 수집했어요. 그리고 이때 얻은 피드백을 기반으로 프롬프트를 수정하며 개선해 나갔어요. 

이 테스트 과정을 통해 휴리봇의 두 가지 가치를 검증 할 수 있었고, ‘휴리스틱 이슈를 빠르고 쉽게 확인할 수 있다’는 의미로 ‘휴리’라고 이름 짓게 되었어요.
효율적인 사용성 점검 : 최소한의 리소스로 빠르게 사용성을 점검할 수 있는 점이 디자이너분들의 업무 효율성을 높여 매우 큰 가치인 것을 파악했어요. 이 제품을 통해 주고 싶던 핵심가치가 검증된 것이죠. 
제3자의 시각 제공 : 디자이너는 종종 작업 중인 디자인 화면에 매몰되어 객관성을 놓치기 쉬운데요. 휴리봇을 통해 제 3자의 시각으로 의견을 줌으로써 본인의 디자인을 메타적으로 바라보고, 환기할 수 있는 장치의 역할을 하는 것 또한 알 수 있었어요.
이렇게 챗봇을 활용해서 휴리봇으로 제공하고자 하는 가치는 검증이 되었지만, 챗봇 특성상 접근성과 사용성에 있어서 한계가 있었어요. 챗봇은 디자이너의 작업 워크플로에 없는 단계이기 때문에 접근성이 떨어졌고, 그렇다 보니 자주 사용하지 않게 되는 문제가 발생했어요. 또한 다른 사람의 대화 이력을 확인할 수 없기에 제가 봇을 좀 더 디벨롭하거나 관리하는 것도 어려웠고요. 이러한 문제 해결과 제품 확장을 위해 내재화를 결정하게 되었어요. 

03) 프롬프팅 후
워크플로에 넣기 위한 스펙 아웃
진짜 ‘쓰기 위한 제품’을 만들기 위해서는 어떤 기능이 꼭 필요한지, 필요하지 않은지 정의해야 해요. 챗봇으로 휴리봇의 가치를 검증한 후 제품 확장을 위한 내재화 작업 중 MVP 제품을 만들기 위해 가장 먼저 했던 작업은 기능 우선순위를 정의하는 일이었어요. 휴리봇의 제품의 핵심 가치는 무엇이고, 이 가치를 전달하기 위한 최소한의 기능은 무엇일지 판단하는 과정이 있었죠.
MVP란? 최소 기능 제품(Minimum Viable Product), 구현하고자 하는 제품의 핵심적인 가치를 골라 최소한의 기능만을 담아낸 제품  
 휴리봇 프로젝트의 목적은 ‘완벽한 봇을 만드는 것’이 아닌 ‘디자이너가 가볍게 자주 사용성 점검을 하게 하는 것’이에요. 봇을 만드는 것은 목적을 달성하기 위한 방법의 하나인 것이고요. 그렇기 때문에 완벽한 봇을 만들기 위해 불필요한 기능을 이것저것 넣는 실수를 하지 않도록 유의했어요. 
휴리봇의 핵심 가치는 채팅을 통한 쉽고 빠른 사용성 점검이니 채팅 화면이 필수적이에요. (1) 화면 이미지를 넣고 (2) 질문하면 (3) 답변을 주는 기능이 꼭 필요하고, 그밖에 대화 목록을 다시 보는 등의 기능은 있으면 좋은 정도지 MVP에 들어가야 하는 필수 기능은 아니라고 판단해서 스펙에서 제외했어요.

그렇게 만들어진 휴리봇을 디자이너분들은 이렇게 사용하고 있어요.
휴리봇으로 빠르게 점검하기





시안 아이데이션 과정에서 빠르게 휴리봇을 돌려보고, 휴리봇의 의견이 공감될 경우 이을 바탕으로 개선 하기도 해요. UT를 위한 프로토타입을 준비할 필요도, 시간을 낼 필요도 없이 언제든 할 수 있기 때문에 디자이너가 혼자 고민하는 시간을 줄이고 사용자에게는 보다 더 중요한 검증을 할 수 있게 된거죠. 

적용해보기 

해결하고자 하는 문제 좁히기
프로젝트 목표 정의하기
공감대 형성하기
초기 제품으로 가치 검증하기
워크플로에 넣기 위한 스펙아웃
AI제품은 프롬프팅만으로는 성공할 수 없어요. 혹시 여러분도 AI를 실무에 도입하지 못해 걱정이라면, 혹시 프롬프트를 잘 짜기 위한 방법만 고민하고 있었던 건 아닌지 생각해 보세요. 그리고 프롬프팅 전/ 중/ 후로 나누어서 어떤 것을 놓치고 있었는지 체크해보시는 걸 추천해 드려요. 
이렇게 만들어진 휴리봇의 프롬프트가 궁금하신가요? 다음 시간에는 휴리봇을 만들면서 얻게 된 ‘사람처럼 말하는 AI 프롬프팅 팁’에 대해 알려드릴게요! 





🤔 ’사용자는 이 페이지를 어떻게 이해할까?’ 
🤔 ‘화면이 복잡해 보이진 않을까?’ 
🤔 ‘이 그래픽은 어떤 의미로 느껴질까?’ 
제품을 만들다 보면 사용자에게 궁금한 점이 참 많이 생기는데요, 내가 원할 때마다 사용자를 만나 궁금한 점을 물어볼 수 있다면 얼마나 좋을까요? 
토스에서는 디자이너분들이 더 자주, 빠르게 