IdeationEngine
팀 아이디어 회의를 AI가 진행·정리해 주는 웹 서비스.
흩어지기 쉬운 브레인스토밍을, 구조를 가진 하나의 세션으로 만든다.
이 문서는 **처음 보는 사람(개발 전공이 아니어도)**이 이 프로젝트가 무엇이고,
왜 이렇게 만들었는지, 지금 어디까지 왔는지 이해할 수 있도록 쓰여졌습니다.
📦 완성의 기준: 이미 만들어져 있는 화면 36개 + API 74개 명세
(IdeationEngine-개발핸드오프/, Vercel에 배포됨: https://ideationengine-front.vercel.app)
에 백엔드를 붙이는 것이 이 프로젝트의 완성입니다. React로 만들었던 이전 프로토타입(src/, server/)은
쓰지 않습니다 — AI를 작업마다 다르게 배분하면 비용·품질이 어떻게 되는지 먼저 검증해 보려고 만들었던 것이고,
그 검증 결과(어떤 모델을 어디에 쓸지)만 지금 제품의 AI 작업 설계로 이어졌습니다.
🧭 왜 이런 선택을 했는지는 docs/설계-결정-기록.md, 어떤 모델을 왜 골랐는지는
docs/모델선정-테스트기록.md에 정리돼 있습니다.
1. 무슨 문제를 푸나
팀으로 아이디어 회의를 하면 흔히 이렇게 됩니다.
- 서로 눈치만 보다가 목소리 큰 한 사람이 방향을 정해 버린다.
- 다들 비슷한 아이디어만 내서 다양성이 안 나온다.
- 열심히 회의했는데 결과가 정리되지 않고 흩어진다.
IdeationEngine은 이 세 가지를 판을 짜서 해결합니다.
"자유롭게 얘기해 보세요"가 아니라, 각자에게 다른 출발점을 주고,
정해진 단계(입장 → 아이스브레이킹 → 발산 → 투표 → 파트 나누기 → 보고서)로 이끌고,
마지막에 결과를 자동으로 묶어 줍니다. 해커톤·공모전처럼 오프라인에서 다 같이 모여 진행하는
상황을 타겟으로 합니다.
2. 핵심 아이디어
① 사람마다 '다른 각도'에서 출발시킨다
같은 질문을 모두에게 던지면 답이 비슷해집니다. 그래서 참여자의 **역량(프로필)**을 보고
비즈니스 · 사용자경험 · 기술 · 혁신 같은 서로 다른 각도를 나눠 줍니다. AI가 이 배분의
참고 맥락으로 프로필을 씁니다. → 아이디어가 구조적으로 겹치지 않게 됩니다.
② 정해진 흐름 하나로 끝까지 이끈다
방식을 여러 개 만들어 고르게 하는 대신, AI 인터뷰(재료 모으기) → 자유 발산 → 익명 투표 →
파트 나누기 → A4 보고서로 이어지는 고정된 흐름 하나로 갑니다. 회의 중간에 "이제 뭘 해야 하지"를
고민할 필요가 없게, 매 단계마다 다음 할 일이 화면에 정해져 있습니다.
③ 사람 의견이 먼저, AI는 다듬고 검증만
아이디어는 사람이 쓰고 사람이 고릅니다. AI는 인터뷰 답에서 재료를 뽑아 추천하거나(추천 이유는
그 사람 본인 답만 인용), 나온 아이디어의 현실성을 검증하는 역할만 합니다. 등급이 낮아도 투표에서
빼지 않습니다 — AI 판정이 사람의 선택을 대신하지 않습니다.
3. 지금 실행해 보기
가장 빠른 방법 — 배포된 화면 바로 보기
https://ideationengine-front.vercel.app 접속 → 화면 목록에서 아무 화면이나 눌러보면 됩니다.
지금은 가짜 서버(mock) 모드라 실제 데이터가 저장되진 않지만, 버튼·입력·화면 흐름은 실제로 동작합니다.
로컬에서 실행 (36개 화면 전체)
cd IdeationEngine-개발핸드오프
# index.html을 브라우저로 열기 (또는 VS Code Live Server로 열면 클립보드 복사 등도 정상 동작)
- 화면 목록에서 원하는 화면 클릭 → 화면 아래 검은 바의 ◀ ▶ 로 흐름 순서대로 이동
- 백엔드가 준비되면
assets/js/config.js에서 useMock: false로 바꾸면 실제 서버와 연결됩니다.
- 더 자세한 안내:
IdeationEngine-개발핸드오프/README.md의 "5분 안에 보기".
백엔드 개발자라면: IdeationEngine-개발핸드오프/docs/01-백엔드-한눈에-보기.md부터 보세요.
만들 API는 1차부터
7차까지 순서대로 전달돼 있습니다.
진행 상황 요약: IdeationEngine-개발핸드오프/팀공유-진행현황.md
4. 기능별 설명 — 무엇을 / 왜
계정 · 입장
- 왜: 게스트 입장을 허용하면 익명 댓글·투표의 신뢰가 깨지고, 나중에 인증을 붙이기도 어렵다.
- 뭘: 이메일/소셜 회원가입 → 로그인(액세스 토큰 1시간 + 리프레시 쿠키 30일) → 프로필 작성까지
끝나야 세션을 만들거나 들어갈 수 있다. 방 코드(대문자·숫자 6자리) 로 입장하고, 코드로 재접속도 된다.
프로필 기반 '각도' 배분
- 왜: 발산의 다양성을 사람 성향에 맡기지 않고 구조로 보장하려고.
- 뭘: 프로필의 역량을 비즈니스·사용자경험·기술·혁신 같은 각도로 매핑하고, 팀 전체가 한 각도에
몰리지 않게 분산 배정한다. 각자 "자기 각도"에서 아이디어를 시작한다.
아이스브레이킹 → 발산 → 투표
- 왜: 처음부터 아이디어를 내라고 하면 막막하다. 서로를 조금 알고, 손에 잡히는 재료가 있어야
아이디어가 나온다.
- 뭘: AI 인터뷰 질문 5개(+최근 소식 카드) → 답에서 재료 뽑기·묶기 → 각자 아이디어 작성 또는
AI 추천에서 고르기 → 익명 순위표·익명 댓글 → AI 검증·현실성 체크 → 1인 2표 투표 → 진행자가 주제 확정.
파트 나누기
- 왜: 아이디어를 정했어도 "누가 뭘 맡을지"가 또 다른 회의거리가 된다.
- 뭘: 팀 스킬(이름 없이 인원 수만 AI에 전달)로 파트·후보를 자동 추천하고, 후보가 겹친 사람에게만
추가 질문을 던져 팀장이 최종 배치를 확정한다. 마지막에 A4 2쪽 보고서로 정리된다.
AI 작업 15개 — 작업마다 다른 무게의 AI
- 왜: 인터뷰 꼬리질문처럼 즉시 답해야 하는 것과, 보고서 생성처럼 시간이 걸려도 되는 것을 같은
방식으로 부르면 느리거나 비싸진다.
- 뭘:
docs/05-AI-작업-목록.md에 15개 작업을
가벼운/중간/무거운 세 무게로 나눠 정의했고, 어떤 모델을 쓸지는 실측으로 정했다(§5). "지어내지
않기(검색 결과에 없는 사실 금지)"·"이름을 AI에 보내지 않기" 같은 안전 규칙도 문서에 명시돼 있다.
정직성 원칙
- 왜: 사용료를 받는 서비스라면, 근거 없는 수치를 사실처럼 보여주면 안 된다.
- 뭘: AI 검증 결과는 "참고용"으로 표시하고 등급이 낮아도 투표에서 빼지 않는다. 목업 모드와 실제
서버 모드를 코드에서 분명히 구분한다(§6).
AI 코드 검수 협업 (Grok)
- 왜: 한 명(또는 하나의 AI)이 만든 코드는 사각지대가 생긴다.
- 뭘: 주 개발은 Claude가, 검수·피드백은 Cursor의 Grok이 맡는 분업. 검수 이력은
grok-검수/ 폴더에, 방식은 REVIEW_GUIDE.md에 있다.
5. 심사 포인트 — 창의성 · 사업성 · 보안
🎨 창의성 — 일마다 '그 일을 가장 잘하는 AI'를 따로 씁니다
보통 서비스는 유명한 AI 하나만 씁니다. 우리는 **"일마다 잘하는 AI가 다르다면, 일에 맞는 AI를
골라 쓰면 결과도 더 좋고 비용도 더 싸지 않을까?"**를 실측으로 확인했습니다.
어떻게 확인했는지 — 편애 없이 공정하게:
- 같은 일을 여러 AI에게 똑같이 시키고, 어느 답을 어느 AI가 만들었는지 가린 채로 채점(블라인드).
- 한 주제만이 아니라 여러 주제로 반복, 채점은 또 다른 AI 여러 개 + 자동 계산 수치(다양성 지표)를 같이 봄.
- 가장 비싸고 유명한 최고급 AI(클로드·챗GPT 최신판 등)도 같은 대결에 넣어 비교.
- 결과를 다른 AI(Grok)에게 교차 검수까지 받음.
알게 된 것:
- 일마다 잘하는 AI가 정말 달랐습니다. 키워드 뽑기, 아이디어 내기, 정리하기, 검토하기 — 1등이 다 다름.
- "여러 AI를 자동으로 섞으면 더 창의적"은 틀렸습니다. 오히려 뻔해짐 — 창의적인 결과는
여러 AI가 각자 내고, 사람이 고를 때 가장 좋았습니다.
- 검토(사실 확인)는 만든 AI가 아니라 '다른 AI'가 해야 실수를 더 잘 잡았습니다.
- 값싼 AI가 수백 배 비싼 최고급 AI를 이기거나 대등했습니다 — 오픈소스 도구로 재현까지 확인(아래 🔬).
그래서 작업 성격별로 이렇게 나눠 맡깁니다 (실측 근거: docs/모델선정-테스트기록.md):
| 작업 성격 | 쓰는 AI | 왜 |
|---|
| 실시간 응답 (꼬리질문·뜻풀이) | Gemini Flash-Lite / Flash | 속도가 최우선, 꼬리 지연이 있으면 실시간에 못 씀 |
| 발산·아이디어 쏟아내기 | Solar (단일) | 혼자서도 다양하게 잘 냄 — 여러 모델 섞으면 오히려 밋밋해짐 |
| 여러 갈래 컨셉 만들기 | AI 4개가 각자 하나씩 | 서로 다른 색으로 나와야 사람이 고르기 좋음 |
| 정리·분석·현실성 검토 | Solar-Pro4 | 정리·근거 지표에서 가장 쌈 + 1위 |
| 보고서 생성 | DeepSeek-V3.2 / Solar-Pro4 | 종합 작성 1위, 분량도 유일하게 채움 |
| 검증·오류 잡기 | 만든 AI와 다른 AI | 자기가 만든 걸 자기가 검증하면 맹점을 못 봄 |
| 파트 나누기·후보 추천 | Flash-Lite | 가장 싼 모델로도 100% 통과 — 굳이 비쌀 필요 없음 |
| "이미 있나?" 시중검색 | Brave 검색 + AI 판정 | 검색은 검색엔진이, 판정은 AI가 |
- 솔직한 한계: 이 표는 작업에 걸린 것만 부르는 역할 카탈로그입니다. "이미 있나" 검색은 URL 근거가
있지만 최종 라벨은 AI 판정이고 표본이 작습니다. "어떤 아이디어가 더 창의적인가"는 AI 채점만으론
부족해 사람 평가가 더 필요합니다.
🔬 "우리끼리 계산 아님" — 외부 오픈소스 도구로 검증
① 비용 — Langfuse로 실측: 같은 작업을 우리 모델과
최고급 Claude-Opus로 둘 다 실제로 돌려 비교 — 우리 $0.0005 vs Opus $0.331 → 약 99.8% 저렴
(가정이 아니라 둘 다 실제로 돌린 값). Langfuse 합계가 우리 계산과 일치.
② 품질 — promptfoo로 재현 확인: 정리·분석·검토 작업을
제3의 심판 AI가 채점 — 분석 0.95 vs Opus 0.90 · 보고 0.95=0.95 · 검토 1.0=1.0 → 저가 모델이
최고급과 동급(살짝 앞서기도). 설정·결과는 eval/에 있어 npx promptfoo eval로 재현 가능.
점수가 천장(0.9~1.0)에 몰려 있어 "명확히 낫다"보다는 **"동급"**이 정확한 표현입니다.
💰 사업성 — 쉬운 일엔 값싼 AI, 어려운 일엔 좋은 AI → 비용 절감
- 보통 앱은 쉬운 일이든 어려운 일이든 비싼 AI 하나로 다 처리합니다. 우리는 단계마다 어떤 AI를
쓸지 미리 정해서 씁니다(위 표).
- 아낀 돈을 정직하게 보여주는 규칙: ① AI를 부를 때마다 무슨 일에·어떤 AI로·얼마 썼는지 기록(작업
비용과 라우팅/검토 비용을 나눠서). ② "값싼 AI를 섞어 실제로 낸 돈" vs "전부 비싼 AI였다면 냈을 돈"을
비교하되, 뒤엣것은 실제로 안 써본 가정이라고 분명히 표시. ③ "쌌다"만 보여주지 않고 품질을 같이
보여줌. ④ 지금 무료인 모델은 "영원히 공짜"라고 가정하지 않음.
- 실측 결과: 쉬운 일을 값싼 AI에 보내니 최고급 AI 하나만 쓰는 것보다 약 99.8% 저렴한데도 품질은
대등했습니다.
🔒 보안 — "돈을 뺏기지 않는 것"도 사업성
우리 서비스의 핵심은 API LLM이라, API 키 유출·남용 = 곧 금전 피해입니다.
스펙에 이미 설계돼 있는 것: 게스트 입장 없음(회원가입·로그인·프로필 필수) · 액세스 토큰(1시간) +
리프레시 쿠키(30일) · 방 코드 6자리. (핸드오프 docs/02-API-공통-규칙.md)
백엔드 구현 시 반드시 챙길 것:
| 위협 | 필요한 것 | 상태 |
|---|
| 방 코드 무차별 시도 | 로그인 사용자만 시도 가능하지만, 시도 횟수 제한이 스펙에 명시 안 됨 | 🔄 구현 시 추가 |
| 쿠키/CSRF | 리프레시 쿠키는 HttpOnly·Secure·SameSite + CSRF 방어 필요 | 🔄 설계 문서 미작성 |
| AI·검색 API 남용 | 15개 AI 작업·검색 호출에 인당 횟수 제한·일일 쿼터 필요 | 🔄 "호출 제한"은 언급됐으나 수치 미정 |
| API 키 노출 | 키는 서버 env에만, 프론트·번들·레포에 노출 금지 | 🔄 원칙만 있음, 구현 시 지켜야 함 |
이전 실험 코드에서 API 키 서버 전용 보관, Mongo 연산자 주입 차단, helmet 하드닝, prod CORS
화이트리스트 같은 패턴을 실제로 구현·검수까지 마쳤습니다 — 코드째로 옮기진 않지만 백엔드가 같은
패턴을 재사용할 수 있습니다. 검수 이력: grok-검수/
6. 지금 상태 — 된 것 / 진행 중인 것
✅ 완료:
- 화면 36개(회원가입·로그인·초대·아이스브레이킹·발산·투표·파트 나누기·A4 보고서) 디자인·HTML/CSS/JS
- Vercel 배포 (https://ideationengine-front.vercel.app, 지금은 가짜 서버 모드)
- API 74개·데이터 모델·AI 작업 15개 명세, 백엔드 전달 문서 1~7차
- AI 작업별 모델 선정 실측 (창의성·비용 절감 근거, §5)
🔄 진행 중:
- 실제 백엔드 서버 구현 (백엔드팀이 1~7차 순서대로 진행)
- AI 작업 15개를 실제 API로 연결
- 보안 항목 중 레이트리밋·CSRF·쿼터 구현 (§5 보안 표)
아직 형식(가짜 서버) 검증만 끝난 것: 로그인·입장·9번(파트 나누기~보고서) 흐름은 테스트용 가짜
백엔드로 돌려봤고, 나머지 화면은 목업 데이터로만 확인된 상태입니다.
7. 기술 구조 (아주 간단히)
[ 브라우저 화면 ] 정적 HTML/CSS/JS (프레임워크 없음) (IdeationEngine-개발핸드오프/screens/)
│ api.call('id', …) — 지금은 mock.js가 가짜로 응답
▼
[ 서버 ] 백엔드팀이 구현 중 — 명세: API 74개(docs/03) · 데이터 모델(docs/04) · AI 작업 15개(docs/05)
[ 배포 ] Vercel (정적 파일만) — https://ideationengine-front.vercel.app
핵심 설계 원칙: AI 키는 서버에만 두어 화면 코드에 노출되지 않게 한다. 어떤 작업에 어떤 AI를
쓸지는 실측으로 미리 정해두고(§5), 서버 구현 시 그대로 적용한다.
8. 이 저장소를 읽는 법 — 코드가 어디 있나
실제로 쓰는 코드는 IdeationEngine-개발핸드오프/ 하나뿐입니다. 아래 나머지는 그 결정에 이르기까지의
실험·기록이라, 신규 팀원은 무시해도 됩니다.
처음이면 이 3개만:
IdeationEngine-개발핸드오프/index.html — 화면 목록. 브라우저로 열면 36개를 눌러볼 수 있음.IdeationEngine-개발핸드오프/docs/01-백엔드-한눈에-보기.md — 백엔드 개발자가 제일 먼저 볼 문서.IdeationEngine-개발핸드오프/팀공유-진행현황.md — 뭘 했고 뭐가 남았는지 요약.
AI 모델을 왜 그렇게 골랐는지 궁금하면:
docs/모델선정-테스트기록.md — 어떤 모델을 왜 골랐는지 테스트 기록 전체.docs/설계-결정-기록.md — "왜 이렇게 만들었나"(다중 LLM을 왜 버렸는지,
사람 먼저·AI는 fallback으로 왜 정했는지 등 커밋 로그에 안 보이는 맥락).benchmarks/ · eval/ · 루트의 *.mjs — 위 결정에 쓰인 실험·검증 스크립트와 결과.grok-검수/ — 방향·정직성 교차검수 이력(날짜별).
쓰지 않는 이전 실험 (참고용, 무시 가능):
src/, server/ — AI 작업 배분을 먼저 검증해 본 React 프로토타입. 이 저장소의 최종 제품에는
쓰이지 않지만, 검증 결과는 위 docs/모델선정-테스트기록.md로 이어졌습니다.ROADMAP.md · ORCHESTRATOR-DESIGN.md · MODEL-ROSTER.md · SETUP-DB.md — 그 프로토타입 시절
설계·로드맵 문서(역사적 기록, 지금 로드맵 아님).
팁: git log의 커밋 메시지에 기능마다 "왜/무엇을"이 담겨 있어, 맥락이 궁금하면 로그를 읽으면 된다.
9. 협업 규칙
- 주 개발(Claude)과 검수(Grok)를 나눠서 진행합니다. → REVIEW_GUIDE.md
- 실제 작업은
ROH 브랜치에서 하고, 주요 마일스톤마다 master에 병합해 팀(백엔드 포함)이 보는 기준을 맞춥니다.
