AI-native Sales Copilot을 표방하는 Yess 웹앱에서 최대 과제는 AI로 생성된 컨텐츠의 높은 퀄리티와 심리스한 전달이다. 높은 퀄리티의 경우 백엔드 로직과 프롬프트가 관여하는 부분이라면 심리스한 전달은 프론트엔드의 역할이 보다 중요한 부분이라고 할 수 있다. 이 글에서는 팀원으로서 AI-native Sales Copilot 런칭에 기여하고, 또한 프론트엔드 개발자로서 기술적으로 문제를 해결하고자 노력하면서 겪었던 좌충우돌의 경험에 대해 정리해 본다.
덧붙이자면 문제를 정말 잘 해결해서 자랑하고자 적은 글은 아니다. 단지 지금까지의 지식 수준에서 최선을 다했고 이에 대한 기록의 차원이다. 분명히 더 나은 해결 방법이 있을 것이라고 생각한다.
왜 AI Meeting Cheat-sheet인가
Yess 웹앱에서 생성형 AI를 가장 적극적으로 활용한 부분은 프로젝트 런칭 전, 즉 계약을 성사시키기까지 일련의 과정에 필요한 문서 작업들이다. 고객 문의·미팅 준비·프로젝트 전략·미팅 노트·미팅 요약 및 분석·제안서 작성 등 수많은 문서 작업이 이에 포함된다. 이 모든 걸 클라이언트별로 일일이 작성한다고 생각하면 막연하게 느껴지는데, 대부분의 고객사들이 이러한 방법을 고수하고 있다. 굉장히 노동집약적이긴 하지만 차별화를 통해 계약 성사율을 높이기 위해서는 정성과 노력이 필요할 수밖에 없다. 하지만 그 안에서도 성공적인 전략과 패턴은 어느 정도 존재한다. 그렇기 때문에 문서 작업은 템플릿과 생성형 AI의 결합으로 생산성을 최대화할 수 있는 대표적인 분야가 되었다. 전체적인 맥락을 유지하면서 특정 전략에 맞춰 문서 초안을 작성하는 데 AI의 도움을 받을 수 있다면 시간 측면에서 훨씬 효율적이다. 정말 잘 해주기만 한다면 AI를 도입하지 않을 이유가 없는 것이다.
그렇다면 Yess 웹앱은 AI를 어떤 페인 포인트에 접목하여 고객사들의 신뢰를 얻을 수 있을까? 이에 대한 답이 PMF를 찾는 첫 단계가 될 것이라 기대하고 모든 팀원이 함께 실험 주제들을 브레인스토밍하였다. 결론적으로 고객들은 세일즈의 가장 앞 단계인 미팅 준비에 가장 많은 시간을 할애하고 그만큼 어려움도 크게 느낄 것이라는 가설을 세웠고, 인터뷰를 통해 실제 문제임을 확인했다. 이 문제를 해결하기 위해 AI Sales Copilot의 첫 피처로 AI Meeting Cheat-sheet을 구상하게 되었다. (링크는 프로덕트에 최종 반영된 모습을 영상화한 것이다.)
개발자도 기획을 할 수 있다. 그리고 해야 한다.
나는 개발자들도 기획에 같이 참여하는 동시에 부족한 기획 능력을 보충하기 위해 레퍼런스 분석 스터디를 진행하는 것을 제안하였다. 감사하게도 팀원들이 이 제안에 공감하고 적극적으로 임해주었다. 제안을 했던 이유는 누구나 기획을 할 수 있고, 또 해야 한다고 생각했기 때문이다. 이는 개발자가 반드시 기획에 참여해야 한다는 강제적인 의미는 아니다. 기획 주도적인 마인드셋으로 접근할 때 개발자로서 의사결정의 퀄리티도 높아진다고 생각한다. 지금까지는 개발 주도적으로 업무를 해왔기 때문에 한 번쯤은 무게중심을 기획으로 옮겨야 그 균형을 맞출 수 있지 않을까? 개발자의 가장 중요한 목표는 문제 해결이며 개발은 수단일 뿐이다. 어떤 경우에는 개발을 안 하는 것이 최선의 해결 방법일 수도 있다. 기획 주도적으로 접근하기 위해서는 대략 다음과 같은 순서로 생각해 보면 된다.
- 어떤 문제가 있는가?
- 어떻게 해결할까?
- 개발이 필요하다면 어떤 방법으로 할까?
이번 피처에서 고려한 고객이 느끼는 가장 큰 문제는, 클라이언트와의 미팅이라는 한 번의 기회를 통해서 프로젝트의 성공률을 최대한 높여야 하기 때문에 준비에 대한 부담이 크다는 점이다. 혹은 반대로 부담 없이 준비함으로 인해서 프로젝트의 성공률이 낮아지는 경우도 문제가 된다. 어느 쪽이든 충분히 준비되었는지 여부가 프로젝트 성공 및 고객사의 이익과도 연결된다. 따라서 Yess 웹앱의 목표는 클라이언트로 하여금 도저히 프로젝트를 맡기지 않으면 안 되겠다고 느끼게 할 만큼 철저한 퀄리티로 미팅 준비 컨텐츠를 제공하고, 이를 활용할 수 있도록 돕는 것이다.
그렇다면 이 목표를 어떻게 달성할까? 포인트는 고객이 이것만 있으면 미팅 준비는 끝이다 라고 느낄 수 있어야 한다는 것이고, 여기에 초점을 맞춘 결과 AI Meeting Cheat-sheet이라는 네이밍과 함께 주요 컨텐츠 구성이 도출되었다. 중요한 시험 전에 참고하는 족보처럼 성공적인 미팅을 위해서 필요한 내용만 모아놓은 요점 정리 노트와 같은 것이라고 할 수 있다. 구체적으로 제공되는 컨텐츠는 다음과 같다.
- Hook Points: 클라이언트에게 어필할 수 있는 후킹 포인트
- Offers: 프로젝트 수주를 위한 제안서 전략
- Agenda: 미팅 때 논의해야 할 주제
- Questions: 클라이언트에게 확인해야 할 사항들
- Risks: 프로젝트의 잠재적 리스크들
- Terms: 프로젝트와 관련된 업계/전문 용어들
- Client Background: 클라이언트의 회사 및 커리어 배경 분석
생성형 AI 피처의 인풋, 프롬프트
생성형 AI 피처에서 고객에게 제공되는 컨텐츠를 아웃풋이라고 정의한다면 인풋은 프롬프트이다. AI 시대 기획자에게 프롬프트 엔지니어링은 필수 역량이다. AI에게 주는 지시에 따라서 결과의 퀄리티가 좌지우지되기 때문이다.
Yess 팀에서는 프롬프트 엔지니어링과 관련된 스터디 및 해커톤을 몇 차례 진행했는데, 이때 GPTs를 활용한 Client Portal Generator와 Gemini를 활용한 Proposal Genie를 구현한 바 있다. 이 활동을 통해서 생성형 AI의 아웃풋에 영향을 줄 수 있는 몇 가지 요소들을 테스트해 보았다. 그 결과 컨텐츠 퀄리티에 가장 큰 영향을 미치는 것은 프롬프트이며, 그 외의 Knowledge나 Fine Tuning 등은 생각보다 유의미한 영향을 미치지 않는 것으로 판단되었다. (다만 다루는 데이터의 양이나 성격에 따라 다른 결과를 낼 수도 있기 때문에 반드시 그렇다는 단정은 아니다.) 그렇다면 프롬프트 엔지니어링에 있어서 가장 유의미한 퀄리티의 차이를 이끌어내는 요소들은 어떤 것들이 있을까?
인스트럭션 설계
우선 명확한 역할과 목표를 포함하여 인스트럭션을 설계하는 것이 중요하다. 그러기 위해서는 생성형 AI를 단순히 똑똑한 함수 정도로 보는 것이 아니라 에이전트로 보는 시각이 필요하다. 에이전트는 특정한 목표를 이루기 위해 작업을 수행하는 존재이다. 따라서 결과물을 얻기 위한 행동만 지시하기보다는 뚜렷한 역할과 목표를 함께 제시할 때 보다 높은 퀄리티의 아웃풋을 얻을 수 있다. 일반적으로 활용되는 템플릿을 분석해 보면 다음과 같이 구성된다.
| 분류 | 예시 |
|---|---|
| 역할 | You are a professional strategist. |
| 목표 | Your goal is to help me prepare for the meeting with the client and ensure a successful contract. |
| 결과물 | Suggest two to three hook points that I can use to appeal to the client. |
| 조건 | A hook point consists of the title, description, and two to three key factors. The format of key factors should be a phrase with max two words. |
여기에 필요하다면 원하는 결과물의 형태(JSON/Markdown 등)나 예시를 첨부해도 된다.
이 단계에서 한 가지 염두에 둘 부분은, 프롬프트의 역할을 정의할 때에도 단일 책임 원칙을 적용하는 것이 좋다는 점이다. 가능하면 하나의 프롬프트에는 한 가지 역할만을 부여할 때 아웃풋의 퀄리티가 높아진다. 생성형 AI의 아웃풋 퀄리티를 객관적으로 수치화하여 평가하기는 어렵지만 여러 조건으로 테스트해 보았을 때 충분히 체감할 수 있는 수준이었다. 다만 프로그래밍을 할 때와 마찬가지로 너무 작은 단위로 쪼갤수록 오히려 의존 관계의 복잡도와 통신 과정에서의 성능 저하가 단점으로 작용할 수 있으니 적절한 수준을 판단하는 것이 중요할 것이다.
사용자 인풋 설계
둘째로 사용자 인풋을 설계하는 것이 중요하다. 위에서 정의한 프롬프트를 ChatGPT에 인풋으로 주면 답변이 그럴듯하게 나온다. 하지만 사용자에게 도움이 되는 결과물은 아닌데, 그 이유는 사용자가 맞닥뜨리고 있는 현실을 전혀 담고 있지 않기 때문이다. 따라서 프롬프트에 어떤 사용자 인풋을 주어야 현실의 맥락과 맞는 아웃풋을 얻을 수 있는지 테스트해 보아야 한다. 미팅을 준비할 때 참고할 수 있는 인풋은 크게 네 가지로 구성된다.
| 분류 | 예시 |
|---|---|
| 프로젝트 | 제목, 설명, 서비스 카테고리, 우선순위, 예산, 기간 |
| 클라이언트사 | 회사명, 웹사이트, 이메일, 링크드인, 설명, 규모, 위치, 타임존, 매출, 자금, 산업 |
| 클라이언트 담당자 | 이름, 직책, 이메일, 링크드인, 전화번호, 위치, 타임존 |
| Yess 고객사 | 회사명, 웹사이트, 이메일, 규모, 위치, 타임존, 설명, 서비스 카테고리, 우선순위, 매출, 비즈니스 목표, 클라이언트 리뷰 |
이 요소들은 특히 사용자에게 제공할 UI/UX를 정하는 것과도 연관있지만, 그 중에서도 아웃풋의 퀄리티에 가장 큰 영향을 미치는 핵심 요소를 도출해야 한다. 그러기 위해서는 프롬프트와 인풋 요소의 조합 별로 테스트하는 과정이 필요하다. 생성형 AI 피처에서는 인풋이 복잡할수록 사용성의 허들이 높아지기 마련이라서 이 복잡도를 어떻게 잘 핸들링하는지가 관건이다. 예를 들면 가장 중요한 것을 강조하고 나머지는 세부 설정으로 숨기거나, 혹은 최대한 모든 인풋에 기본값을 미리 채워두는 식의 전략을 고려해 볼 수 있다.
또한 이 단계에서는 제품에 이미 존재하는 데이터와의 의존성과 연동 방법을 미리 고민할 필요도 있다. Yess 웹앱의 경우 프로젝트 데이터는 Inquiry Form, 클라이언트 담당자 데이터는 Contact, Yess 고객사 데이터는 Settings에서 이미 관리하고 있는 데이터였기 때문에 AI Meeting Cheat-sheet에서 인풋을 수정하는 행위가 데이터의 출처에도 반영되어야 할지, 혹은 독립적으로 다루어야 할지 고민이었다. 결과적으로는 사용자에게 데이터가 전역적으로 연동되고 있음을 안내하고 데이터 출처에도 반영하는 쪽을 선택하였는데, 그 이유는 해당 데이터들이 상황에 따라 달라지기보다는 독립적이고 고정적인 성격을 가지고 있기 때문이다.
프롬프트 개선 이터레이션
프롬프트 엔지니어링은 특히나 더 기획과 개발의 경계를 허물어야만 효율적으로 이루어질 수 있다는 생각이 든다. 이는 AI Meeting Cheat-sheet을 시작으로 생성형 AI 피처를 계속해서 빌드하며 느낀 것이다. 인풋과 아웃풋이 모두 사용자 경험과 직결된다는 것이 근본적인 원인이라면, 그보다 더 크리티컬한 건 수없이 프롬프트 개선 이터레이션을 돌리며 최적화해야 하기 때문에 이 과정을 기획과 개발이 철저하게 분리된 상태에서 진행할 경우 커뮤니케이션 코스트가 겉잡을 수 없이 늘어나게 된다는 점이다.
이 문제를 해결하기 위해서 Yess 팀은 LangSmith를 도입했다. 덕분에 팀원 누구라도 프롬프트를 원하는 때에 개선하고 테스트할 수 있는 환경이 마련됐다. 아쉽게도 프론트엔드를 담당하는 입장에서 LangSmith를 적극적으로 활용할 기회가 없었지만, 틈날 때 들어가서 어떤 식으로 프롬프트가 개선되고 있는지 살펴볼 수 있어서 편리했다.
타이핑 애니메이션의 명분
처음 시도한 기획이다 보니 시행착오도 있었다. 기획을 할 때는 의도적으로 개발 가능 여부나 방법에 대해서 고려하지 않고 진행했었는데, 막상 개발을 시작하려니 '사물이 보이는 것보다 구현하기 어려운' 벽에 부딪히고 말았던 것이다.
생성형 AI에서 스트리밍으로 받아오는 응답을 타이핑 애니메이션과 함께 실시간 렌더링하는 것이 요구사항인데, 커서 포지셔닝과 연동되는 데이터의 종류는 다양하고 앞으로도 어떤 형태로든 늘어날 가능성이 있었다. 그 모든 경우의 수를 대응하면서 일관성과 확장성이 보장된 로직을 설계하는 것이 너무 어려웠다. 당시 대응해야 하는 데이터 형태만 하더라도 quill·tiptap 데이터, 레거시·최신 테이블 데이터, 일반 객체로 된 기타 데이터 등이 있었다. 각 데이터에 해당되는 로직을 하나씩 구현하고 유지보수하는 데 들이는 시간이 데이터 종류만큼 N배가 소요되는 것이다. 빠르게 제품 개선 사이클을 돌려서 PMF를 찾아야 하는 상황에 타이핑 애니메이션을 위해 이 정도로 리소스를 들이는 것이 맞을까?
AI Meeting Cheat-sheet은 여러 가지 주제의 컨텐츠를 종합적으로 제공한다. 이 컨텐츠들이 모두 완성되려면 총 로딩 시간은 굉장히 길어지는 한계가 있다. 이처럼 긴 로딩 시간에 어떻게 대처할지 고민하는 것은 생성형 AI를 활용하는 프로덕트의 숙명같은 것일지도 모른다. 어떤 방식에서 명분을 찾을지 확실히 하기 위해서 레퍼런스를 분석해 보았고, 대개 다음 네 가지 형태로 나뉘어지는 것을 확인했다.
- 응답 내용을 실시간으로 스트리밍 (e.g. ChatGPT, Google Bard, Notion)
- 로딩 스피너 및 진행 상황에 대한 UI 표시 (e.g. Midjourney, DALL·E, Lilys)
- 백그라운드에서 진행되고 있음을 알리고 다른 작업을 유도 (e.g. tldv, Github Copilot, Warp)
- 게임/영상/팁 등 컨텐츠로 시선을 분산 (e.g. Spotify, Netflix, Roblox)
이 중에서 타이핑 애니메이션이 필요한 건 1번에만 해당된다. 그렇다면 2~4번 대신에 타이핑 애니메이션을 구현하는 리소스를 감수하고 1번을 선택하는 이유는 무엇일까? 이에 대해 논의한 결과 사용자들이 AI Meeting Cheat-sheet의 가치를 발견하는 시점을 최대한 앞당기는 것이 중요하기 때문이라고 결론을 내렸다. 응답이 마무리되기까지 걸리는 총 시간보다도 실제 컨텐츠가 어떤 형태인지 확인할 수 있는 시간을 빠르게 하는 것에 초점을 맞추기로 했다.
경계를 넘어
개인적으로 사이드 프로젝트를 비롯하여 회사 업무에서도 종종 기획을 한 경험이 있고 또 그걸 즐기는 편이다. 그런데 이번에는 나조차도 개발 업무에만 매몰된 지 오래된 상황에서 모든 팀원이 함께 기획에 참여하도록 이끌었다는 점에서 굉장히 새로운 도전이었다. 게다가 생성형 AI를 직접 프로덕트에 적용하는 건 처음이다 보니 이에 대해 학습해야 할 내용도 많았다.
새로운 도전은 항상 많은 교훈을 남기고 성장의 자양분이 된다고 믿는데, 이번에도 마찬가지였다. AI 시대가 성숙해지고 그 성능이 가속화될수록 기획 주도적인 마인드셋으로 사고하는 것은 개발자의 필수 역량이라는 점을 깨닫게 되었다. (혹은 동시에 개발에 대한 지식이 기획자의 필수 역량이 되어가는 것 같기도 하다.) LangSmith와 같은 제품이 기획과 개발을 철저하게 분리하기 어려워지는 현실을 잘 반영한 사례가 아닐까 싶다. 그뿐 아니라 Gemini 해커톤에서는 Vercel의 AI SDK로 백엔드와 프론트엔드가 통합된 환경에서 개발을 해보았는데 오히려 AI 스트리밍을 다루는 피처에서는 이게 훨씬 편하게 느껴졌다. 이런 경험을 통해서 마지막에는 Yess 웹앱에도 Server-Driven UI를 도입하면 좋겠다는 생각과 그 시도로 이어지기도 했는데, 이에 대한 내용도 이후 포스트에서 자세히 적어보겠다.