AI 가상 팀이 기획서를 써준다고?
BTS(Build Team Service) 개발기
by Engineering Team

들어가며: 혼자서 기획서 쓰는 게 이렇게 외로운 일이었나

안녕하세요! 하이어다이버시티 Engineering 팀입니다. 👋
기획서를 써본 적이 있다면 공감할 겁니다.
아이디어는 있는데, 혼자 쓰다 보면 자꾸 한쪽으로 치우칩니다.
"이 기능 진짜 만들 수 있는 거야?"라고 물어볼 개발자도 없고, "사용자가 정말 이걸 원할까?"라고 태클 걸어줄 동료도 없습니다.
저희 팀도 같은 고민을 했습니다.
사내에서 새로운 서비스나 기능을 기획할 때, 기획자 혼자 초안을 쓰고 → 회의에서 처음 공유하면 → "그건 기술적으로 어렵고요", "보안 검토는 했나요?", "시장 데이터는요?" 같은 피드백이 쏟아집니다.
그래서 또 수정하고, 또 회의하고. 이 반복을 줄일 수 없을까? "회의 전에 미리 가상 팀에게 검토받으면 어떨까?"
이 아이디어에서 BTS가 시작되었습니다.
왜 AI로 만들었나요?
솔직히 말하면, 이 문제를 AI 없이도 풀 수 있습니다. 체크리스트 템플릿을 만들거나, 기획 리뷰 프로세스를 정형화하거나, 외부 컨설턴트를 쓰는 방법도 있습니다.
그런데 왜 굳이 AI였을까요?
저희가 판단한 건 단순합니다. -> 지금은 AI에 적응해야 하는 시대라는 것.
AI를 "쓸까 말까" 고민하는 단계는 이미 지났습니다.
ChatGPT가 나온 지 3년, 이제 문제는 "AI를 어떻게 잘 쓸 것인가"입니다. 그리고 잘 쓰려면 직접 만들어봐야 합니다.
API를 연동해보고, 프롬프트를 설계해보고, 한계를 몸으로 느껴봐야 "이건 AI에게 맡기고, 이건 사람이 해야 해"라는 감각이 생깁니다.
BTS는 그 감각을 키우기 위한 프로젝트이기도 했습니다.
AI가 정말로 "전문가처럼 토론"할 수 있는지, 여러 AI 모델을 섞으면 관점의 다양성이 생기는지, 프롬프트 엔지니어링만으로 얼마나 깊이 있는 결과물을 만들 수 있는지 — 직접 부딪혀보고 싶었습니다.
결과적으로, 이 과정에서 얻은 가장 큰 수확은 BTS라는 제품 자체보다 "AI와 협업하는 방법론"이었습니다.
- 어디까지가 AI의 영역이고 어디부터가 사람의 영역인지, 그 경계를 실무에서 체감한 것.
BTS가 뭔가요?
BTS(Build Team Service)는 AI 가상 팀원들이 실시간으로 토론하며 기획서를 만들어주는 서비스입니다.
사용자가 프로젝트 목표를 입력하면, 기획자 · 디자이너 · 개발자 · QA · 마케터 · 데이터 분석가 · 보안 담당자 · 사용자 페르소나 — 최대 8명의 AI 전문가가 각자의 관점에서 의견을 나눕니다.
브레인스토밍부터 시작해서 토론, 리뷰까지 다중 라운드로 진행되며, 이 과정을 바탕으로 구조화된 기획서가 자동 생성됩니다.
쉽게 말해, 아이디어 하나 던져놓고 커피 한 잔 마시고 오면 기획서 초안이 완성되어 있는그런 도구입니다.
핵심 흐름
- 목표 입력 → 팀 구성 → AI 팀 토론 (자동 N라운드) → 기획서 생성 → 피드백 반영 → 완성
주요 기능 보기
1. 역할별 AI 에이전트
기획자·디자이너·개발자·QA·마케터·데이터 분석가·보안 담당자·사용자 페르소나 — 최대 8명의 전문 역할을 제공합니다.
각 에이전트는 고유한 성격, 말투, 사고 패턴을 가지고 있어 실제 팀 회의처럼 다양한 관점이 충돌합니다.
Junior/Senior 레벨 설정도 가능해서, 같은 역할이라도 다른 깊이의 발언을 이끌어낼 수 있습니다.
2. 멀티 AI 모델 선택
한 토론 안에서 팀원마다 다른 AI 모델을 배정할 수 있습니다.
기획자는 Gemini로, 개발자는 GPT로, 보안 담당자는 Claude로 — 모델마다 성향이 다르기 때문에 관점의 다양성이 자연스럽게 생깁니다.

3. 다중 라운드 토론
한 번의 발언으로 끝나는 게 아닙니다.
브레인스토밍(아이디어 발산) → 심화 토론(구체화·반론) → 최종 리뷰(합의·보완)까지, 실제 회의의 흐름을 구조화된 라운드로 재현합니다.
라운드가 진행될수록 논의가 깊어지고, 초반에 놓친 허점이 후반에 잡힙니다.
4. 기획서 생성 + 피드백 반영
토론이 끝나면 전체 논의를 바탕으로 구조화된 기획서가 생성됩니다.
마음에 안 드는 부분이 있으면 피드백을 입력하면 되고, AI가 피드백을 반영한 다음 버전을 만들어줍니다.
모든 버전이 저장되므로, 이전 버전과 비교(diff)하며 변경점을 추적할 수 있습니다.

5. 기획서 분석 모드
이미 작성된 기획서가 있다면? 텍스트를 붙여넣거나 파일을 업로드하면, AI 팀이 해당 문서를 읽고 팀 토론을 통해 강점·약점·누락 항목·개선 제안을 포함한 분석 리포트를 생성합니다.
6. PDF 내보내기
완성된 기획서를 깔끔한 PDF로 다운로드할 수 있습니다.
회의 자료로 바로 활용하거나, 이해관계자에게 공유할 때 유용합니다.

7. 키워드 학습 + 단어장
토론 중 등장하는 전문 용어(`[[키워드]]` 형식으로 표시)를 클릭하면 AI가 해당 용어를 쉽게 설명해줍니다.
이 설명을 개인 단어장에 저장해두면, 나중에 같은 키워드가 나왔을 때 AI를 다시 호출하지 않고 바로 확인할 수 있습니다.
8. 세션 히스토리 + 아카이브
모든 토론 세션은 자동 저장됩니다.
히스토리에서 이전 토론을 다시 열어볼 수 있고, 완성된 기획서는 아카이브에 정리되어 검색·조회·PDF 다운로드가 가능합니다.

9. 관리자 대시보드
관리자 권한이 있는 사용자는 전체 사용량 통계를 확인할 수 있습니다.
AI 모델별 API 호출 횟수, 토큰 사용량, 응답 시간 등을 시각화하여 비용 관리와 모델 성능 비교에 활용합니다.
10. 토큰 비용 최적화
AI API는 토큰 단위로 과금되기 때문에, 멀티 라운드 토론에서 비용 관리는 필수입니다.
BTS는 매 라운드마다 이전 대화 전체를 보내는 대신, 핵심 포인트만 자동 추출·축약하여 컨텍스트로 전달합니다.
맥락은 유지하면서 토큰 사용량은 줄이는 방식으로, 라운드가 늘어나도 비용이 선형적으로 증가하지 않도록 설계했습니다.
만드는 과정: PoC에서 프로덕션까지
프레임워크 선택
Next.js 16 + React 19 + TypeScript 조합을 선택했습니다.
서버 컴포넌트와 API Routes를 한 프로젝트에서 관리할 수 있어, AI API 호출을 서버 사이드에서 안전하게 처리하면서 클라이언트에서는 실시간 토론 UI를 구현할 수 있었습니다.
인증은 Keycloak SSO + NextAuth 5 조합으로, 사내 통합 인증 체계에 맞췄습니다.
데이터베이스는 PostgreSQL + Prisma ORM으로 세션·메시지·문서 버전을 체계적으로 관리합니다.
가장 어려웠던 부분: 에이전트 페르소나 설계

기술적으로 가장 고민이 깊었던 건 AI 에이전트의 페르소나 시스템입니다.
단순히 "너는 개발자야"라고 역할만 부여하면, 모든 에이전트가 비슷한 톤으로 비슷한 말을 합니다.
실제 팀 회의처럼 느껴지려면 각 역할이 확연히 다른 관점과 깊이로 발언해야 합니다.
결국 역할별로 다음 요소를 세밀하게 정의했습니다. 예를 들어 QA 엔지니어의 경우:
- 전문 지식 (해당 역할의 핵심 역량) → 테스트 피라미드, BDD, 장애 시나리오
- 사고 패턴 (문제를 바라보는 프레임) → "이게 실패하면 어떻게 되지?"
- 활용 프레임워크 (실무에서 쓰는 방법론) → FMEA, Chaos Engineering
- 말투 (성격이 드러나는 표현 방식) → 신중하고 질문 중심
여기에 Junior/Senior 레벨까지 구분하여, 같은 개발자 역할이라도 주니어는 기술 트렌드 중심으로, 시니어는 아키텍처와 유지보수 관점으로 발언하도록 설계했습니다.
멀티 AI 프로바이더 아키텍처

BTS는 하나의 토론 세션에서 여러 AI 모델을 동시에 사용합니다.
기획자는 Gemini로, 개발자는 GPT로, 보안 담당자는 Claude로 — 이런 조합이 가능합니다.
이를 위해 AI 프로바이더 추상화 레이어를 구현했습니다:
typescript
// 모델에 관계없이 동일한 인터페이스로 호출
const response = await generateText(model, systemPrompt, userMessage);
내부적으로는 Gemini API, OpenAI Responses API, Anthropic API를 각각 래핑하고, 호출마다 토큰 사용량·응답 시간·성공 여부를 자동으로 로깅합니다.
관리자 대시보드에서 모델별 비용과 성능을 한눈에 비교할 수 있어, "어떤 모델이 어떤 역할에 적합한지" 데이터 기반으로 판단할 수 있습니다.
토론 맥락 관리
3라운드째 토론에서 1라운드 발언을 까먹으면 안 됩니다.
하지만, 매번 전체 대화를 통째로 보내면 토큰 비용이 폭발합니다.
이를 해결하기 위해, 에이전트 발언에서 핵심 포인트(`[[키워드]]` 형식)를 자동 추출하고, "누가 어떤 포인트를 언급했는지"를 구조화된 형태로 요약해서 다음 라운드에 전달합니다.
맥락은 유지하면서 토큰은 아끼는 전략입니다.
기술 스택 전체 그림
- 프레임워크 — Next.js 16, React 19, TypeScript 5
- 스타일링 — Tailwind CSS 4
- AI 모델 — Google Gemini, OpenAI GPT, Claude
- 인증 — Keycloak SSO + NextAuth 5
- 데이터베이스 — PostgreSQL + Prisma 7
- PDF 생성 — html2pdf.js
- 문서 비교 — diff-match-patch
- 아바타 — DiceBear
- 패키지 관리 — pnpm
개발하면서 부딪힌 것들
기술 블로그라면 삽질 이야기도 빠질 수 없겠죠.
실제로 만들면서 만난 몇 가지 문제들을 공유합니다.(사실 Claude를 시켰어요)
PDF 내보내기와 다크모드의 충돌
BTS는 다크모드 기반 UI입니다.
그런데 PDF로 내보내면? 어두운 배경에 밝은 글씨 — 인쇄하면 읽을 수가 없습니다.
처음에는 html2canvas로 화면을 캡처한 뒤 PDF로 변환하는 방식을 시도했는데, `position: fixed`로 화면 밖에 숨겨둔 라이트모드 프리뷰 영역을 html2canvas가 캡처하지 못하는 문제가 있었습니다.
결국 프리뷰 컴포넌트의 CSS 변수를 라이트모드 값으로 오버라이드하고, html2canvas에 width/windowWidth를 명시적으로 지정하는 방식으로 해결했습니다.
작은 기능 하나에도 브라우저 렌더링의 깊은 곳까지 파고들어야 하는 순간이었습니다.
React 19 hydration 에러와의 싸움
React 19의 hydration 검증은 상당히 엄격합니다.
"<button>" 안에 "<button>"을 넣으면 — HTML 스펙상 유효하지 않은 구조라서 서버/클라이언트 렌더링 결과가 달라지고, 콘솔에 hydration 에러가 찍힙니다.
단어장의 리스트 아이템(클릭 가능) 안에 삭제 버튼을 넣었을 때 이 문제를 만났고, 외부 요소를 "<div role= button>"으로 교체해서 해결했습니다.
멀티 모델 간 응답 포맷 불일치
Gemini, GPT, Claude는 같은 프롬프트를 줘도 응답 포맷이 다릅니다.
어떤 모델은 마크다운 헤더를 `##`으로, 어떤 모델은 `**굵은 글씨**`로 구조를 잡습니다.
기획서 생성 시 이 차이가 문서 품질에 직접 영향을 주기 때문에, 프롬프트에 출력 포맷을 상세하게 지정하고, 모델별로 후처리 로직을 조정해야 했습니다.
반응형 UI: 데스크톱에서 모바일까지
BTS는 데스크톱과 모바일 모두에서 동작합니다.
데스크톱에서는 좌측 사이드바(LNB) + 메인 콘텐츠 레이아웃이고, 모바일에서는 하단 네비게이션 바로 전환됩니다.
사이드바는 접기/펼치기가 가능해서, 태블릿 화면에서도 토론 영역을 넓게 쓸 수 있습니다.
단어장의 경우 데스크톱에서는 좌측 키워드 목록 + 우측 상세 설명의 마스터-디테일 레이아웃을, 모바일에서는 목록 → 상세로 전환되는 풀스크린 레이아웃을 적용했습니다.
같은 컴포넌트가 화면 크기에 따라 완전히 다른 UX를 제공하도록 Tailwind CSS의 반응형 유틸리티를 적극 활용했습니다.
솔직한 한계
BTS가 실제 팀 회의를 완전히 대체할 수 있을까요?
솔직히 말하면, 아직은 한계가 있습니다.
도메인 특화 지식의 한계
AI 에이전트는 일반적인 전문 지식을 기반으로 발언합니다.
"우리 회사의 레거시 시스템 구조"나 "지난달 A/B 테스트 결과" 같은 조직 내부 맥락은 반영하기 어렵습니다.
창의적 도약의 부재
회의실에서 누군가 갑자기 "아, 근데 이걸 완전히 다른 방식으로 접근하면?"이라고 말하는 순간 — 그런 예측 불가능한 창의적 전환은 AI 토론에서 만들기 어렵습니다.
합의의 깊이
AI 에이전트들은 결국 "건설적으로 토론하라"는 지시를 따릅니다.
실제 회의에서 벌어지는 진짜 갈등과 타협의 과정과는 질적으로 다릅니다.
그래서 BTS의 포지셔닝은 "기획 초안의 퀄리티를 끌어올리는 사전 검증 도구"입니다.
혼자 쓴 초안을 회의에 가져가기 전에, 다양한 관점에서 미리 검토받는 것.
그게 BTS가 가장 잘하는 일입니다.
마치며
BTS를 만들면서 가장 인상적이었던 건, AI 모델의 성능보다도 "좋은 프롬프트는 좋은 질문에서 나온다"는 사실이었습니다.
에이전트에게 "기획자처럼 말해"라고 하는 것과, "JTBD 프레임워크를 활용하여 사용자의 핵심 과업을 분석하고, 기존 대안 대비 차별점을 구조화해서 제시해"라고 하는 건 결과물의 질이 완전히 다릅니다.
결국 AI 도구의 가치는 도구 자체가 아니라, 도구를 어떻게 설계하느냐에 달려 있었습니다.
좋은 팀 회의를 만드는 건 좋은 회의 도구가 아니라 좋은 아젠다인 것처럼요.
앞으로의 방향
BTS는 계속 발전하고 있습니다.
최근에는 레드팀(악의적 사용자/경쟁사 관점) 에이전트와 DiceBear 기반의 역할별 고유 아바타를 추가하여, 토론의 긴장감과 시각적 직관성을 높였습니다.
다음 단계로는 이런 방향들을 구상하고 있습니다.
Mermaid 다이어그램 자동 생성
토론 결과를 바탕으로 플로우차트, 시퀀스 다이어그램, ER 다이어그램 등을 자동으로 생성하여 기획서에 시각 자료를 포함합니다.
글로만 된 기획서보다 한 장의 다이어그램이 더 빠르게 전달되는 경우가 많으니까요.
조직 내부 지식 연동 (RAG)
앞서 "솔직한 한계"에서 언급한 도메인 특화 지식의 부재를 해결하기 위해, 사내 문서·위키·이전 기획서를 벡터 DB에 저장하고 토론 시 참조하는 RAG(Retrieval-Augmented Generation) 파이프라인을 준비하고 있습니다.
"우리 회사에서 작년에 비슷한 기획을 했을 때 어떤 결론이 나왔는지" AI가 알고 발언할 수 있다면, 토론의 실용성이 크게 달라질 것입니다.
프로젝트 템플릿
"모바일 앱 기획", "SaaS MVP 검증", "내부 도구 개선" 같은 자주 쓰이는 프로젝트 유형별로 최적화된 팀 구성·라운드 설정·프롬프트를 프리셋으로 제공하여, 시작 단계의 허들을 낮출 계획입니다.
외부 도구 연동
완성된 기획서를 Notion, Confluence, Jira 등으로 직접 내보내는 기능.
기획서가 만들어진 후 "이제 이걸 어디에 옮기지?"라는 고민을 없애는 것이 목표입니다.