INDEX
여러 생성형 AI를 함께 사용할 때 발생하는 모델 선택, 작업 분배, 맥락 전달, 결과 취합의 번거로움을 줄이기 위해 기획한 서비스다. 목표 입력부터 작업 계획, 에이전트 실행 상태, 결과 통합까지의 흐름을 웹 프로토타입으로 구현했으며, 현재 작업 실행은 실제 AI API가 아닌 규칙·템플릿 기반 시뮬레이션이다.
만들게 된 배경
여러 AI를 함께 활용하는 사용자는 작업마다 모델을 선택하고, 이전 대화와 자료를 옮기고, 결과를 검토·통합하는 과정을 직접 관리해야 한다. INDEX는 이 과정을 사용자가 반복하는 대신 하나의 작업 공간에서 조율하도록 구상했다. 단순한 멀티 모델 채팅 화면보다는 프로젝트 단위의 목표·맥락·작업 흐름 관리에 초점을 맞췄다.
개발 기간
2026.09 — 개발 중
해결하려던 문제와 목표
핵심 문제는 모델 선택 비용, 맥락 전환 비용, 작업 조정·검증·통합 비용이다. 사용자가 목표 하나를 입력하면 시스템이 하위 작업을 구성하고 적합한 AI·도구를 배정해 결과를 모으는 경험을 목표로 한다. 향후 실제 API를 연결한 MVP에서 사용자 개입 횟수, 작업 완료 시간, 결과 품질, 맥락 유지, API 비용을 단일 모델 방식과 비교해 가치를 검증할 계획이다.
주요 기능
- 목표 기반 작업 계획 생성 — 웹 데모 구현: 입력 문장을 규칙으로 분류해 사업계획·조사·개발·일반 작업 중 하나의 유형을 선택하고, 해당 유형의 하위 작업 3개를 생성한다. LLM이 계획을 자동 추론하는 기능은 아직 아니다.
- 에이전트 병렬 실행 및 모델 배정 — 시뮬레이션 구현: GPT·Claude·Gemini 계열의 가상 모델을 작업에 배정하고,
Promise.all로 3개 작업의 진행률과 완료 상태를 표시한다. 실제 모델 호출 대신DemoProvider가 사전 정의된 출력 내용을 생성한다. - 실패 처리·재배정·실행 제어 — 웹 데모 구현: 특정 작업의 실패를 의도적으로 발생시키고, 실패한 작업만 다른 가상 모델에 재배정해 다시 실행할 수 있다. 실행 중지는
AbortController로 처리한다. - 프로젝트별 공유 맥락·작업 기록 — 브라우저 수준 구현: 프로젝트 목표·요구사항·메모, 실행 로그, 결과 기록을
localStorage에 보관한다. 새로고침 시 실행 중이던 작업을 중지 상태로 복구하며, 서버 기반 공유 메모리나 모델 간 실제 맥락 전송은 구현되지 않았다. - 구조 검증·결과 통합·문서 내보내기 — 웹 데모 구현: 작업 완료 여부와 입력 내용 포함 여부를 규칙으로 검사한 후 결과 템플릿을 Markdown으로 통합하고 복사·다운로드한다. 출처 사실관계나 AI 응답 품질을 검증하는 기능은 아니다.
아직 구현·검증되지 않은 핵심 MVP 기능: 실제 멀티 AI API 호출, LLM 기반 자율 작업 분해·동적 라우팅, 외부 검색·파일·코드 실행 도구 연동, 서버 영속 저장 및 계정 간 동기화, 실측 비용·품질 최적화.
내가 직접 구현하거나 담당한 부분
제공 자료에서 확인되는 작업 범위(개인 기여 귀속은 추가 확인 필요):
- 서비스 기획: 프로젝트의 문제 정의, 목표 기반 오케스트레이션 워크플로, Shared Context·Model Router·Evaluator·Synthesizer의 역할 및 MVP 범위를 문서화한 자료가 있다.
- 기술 검토·비용 분석: 발표 조사 문서에 연동 AI, 구현 기술, 구독료, 예상 토큰·API 비용을 ‘담당 범위’로 명시했다. LangGraph·LiteLLM·MCP·RAG 등의 역할과 RouteLLM·LLMLingua-2 등 관련 연구를 비교하고, 저가 모델 분배 비율과 추가 호출 비용을 반영한 조건부 계산을 정리했다.
- 시장 근거 조사: KISDI·Deloitte/Ipsos·HEPI/Savanta·Pew 및 Bango 자료의 표본·조사 대상·문항 범위를 구분해, 유료 AI 이용 경험과 복수 구독·실제 비용 부담을 혼동하지 않도록 정리한 조사 자료가 있다.
- 웹 결과물:
INDEX-landing.html(소개·시나리오 재생)과INDEX-demo.html(상태 관리 및 작업 흐름 시뮬레이션)의 코드가 제공됐다. 직접 작성한 코드의 범위·본인 구현 여부는 확인 필요이므로 개인 개발 성과로 확정하지 않는다.
팀 구성과 역할
- 팀 인원: 확인 필요. 2026-09-18 마스터 문서는 ‘1인 중심 기획’으로 기록하지만, 이후 팀 설명 자료가 있어 현재 인원을 단정할 수 없다.
- 내 역할: 기획 및 기술·시장 자료조사 관련 문서가 확인됨. 다만 개인별 역할 분담표와 코드 작성자 정보가 없어 구체적인 본인 담당 범위는 확인 필요.
설계 구조 / 기술을 선택한 이유
서비스 목표 아키텍처(설계안): 사용자 목표 → Planner·Task Decomposition → Model/Tool Routing → Multi-Agent 실행 → Shared Context → Evaluator·Retry/Re-routing → Synthesizer → 최종 결과물. 독립 작업은 병렬로, 선행 결과가 필요한 작업은 순차적으로 수행하도록 구상했다. 초기 라우팅은 규칙 기반으로 시작하고, 실행 로그를 확보한 뒤 동적 라우팅으로 확장하는 단계적 접근이다.
현재 웹 프로토타입(실제 코드): 키워드 정규식 분류 → 유형별 3개 고정 작업 생성 → DemoProvider 비동기 시뮬레이션 → 완료·입력 포함 여부 검사 → 템플릿 결과 병합. 프레임워크나 AI 서비스에 연결된 백엔드 없이 브라우저에서 동작하도록 작성되어 있다. 프로젝트·결과 기록은 브라우저의 localStorage에만 저장한다.
도입 검토 근거: 조사 문서는 LangGraph를 작업 흐름·상태 관리, LiteLLM을 모델 API 호출·비용 집계, MCP/함수 호출을 외부 도구 연결, RAG·압축·캐시를 입력 맥락 최적화 후보로 구분했다. 이는 기술 선정 제안이며 실제 채택·연동 증거는 아니다. 브라우저 데모의 시뮬레이션 방식은 API 키 없이 사용자 흐름을 체험할 수 있게 한다.
기술 구성과 확인 범위
- 웹 프로토타입: HTML5, CSS3, JavaScript(Vanilla JS)
- 브라우저 상태·실행 처리:
localStorage,Promise.all,AbortController,Blob기반 Markdown 내보내기 - Backend / Database / AI API: 업로드된 데모 코드에서 실제 연동 확인되지 않음
- 설계·도입 검토 후보(구현 스택 아님): LangGraph, LiteLLM, OpenAI·Anthropic·Google AI API, MCP, RAG, 프롬프트 압축·캐싱
가장 어려웠던 문제
가장 어려웠던 문제: 실제 개발 중 가장 어려웠던 장애 사례는 확인 필요. 다만 제공된 코드에서 확인되는 핵심 기술적 과제는 병렬 작업의 실패·취소·재실행 시 실행 상태를 일관되게 관리하는 것이다.
문제의 원인: 여러 비동기 작업은 각각 다른 시점에 완료되거나 실패할 수 있으며, 실행 도중 프로젝트를 바꾸거나 브라우저를 새로고침하면 진행 중 상태와 저장된 기록이 어긋날 수 있다. 이는 코드 구조상 대응한 상황이지, 실제 장애 발생 원인이 기록된 것은 아니다.
해결 방법:
작업별 상태·진행률·시도 횟수를 관리하고, Promise.all 결과를 수집해 실패 작업이 남아 있으면 통합을 보류한다. 실패 작업만 다른 가상 모델로 재배정해 재실행하며, AbortController로 중지하고 저장 상태 복원 시 진행 중 작업을 중지 상태로 변경하도록 구현했다.
해결 결과: 코드상 실패 시뮬레이션·선택적 재시도·새로고침 후 상태 정리 흐름을 확인했다. 실제 AI API 환경에서의 오류 복구율이나 안정성 테스트 결과는 미확인이다.
최종 결과 / 실제 사용 여부
INDEX의 서비스 방향, 핵심 아키텍처 설계안, 기술·시장 조사 자료, 랜딩 페이지와 브라우저 기반 인터랙티브 데모 코드가 확인된다. 데모는 목표 입력·가상 작업 분배·상태 표시·재시도·Markdown 산출물 저장 흐름을 제공하지만, 실제 AI 추론이나 웹 검색을 수행하지 않는다. 상용 출시, 공개 배포, 실사용자 운영, 성능 개선 실측은 확인되지 않았다. 조사에서 제시한 API 비용 37~47% 절감은 저가 모델 처리 60%·추가 호출 비용 10~20% 등의 조건을 둔 계산 예시로, 제품의 달성 성과가 아니다.
배운 점
자료에서 도출되는 기술적 시사점(본인의 학습 경험 표현은 확인 필요): 여러 AI를 연결하는 것과 작업의 계획·상태·검증·통합을 책임지는 오케스트레이션은 서로 다른 문제다. 시뮬레이션의 완료·형식 검사와 실제 모델 출력의 사실·품질 검증도 구분해야 한다. 또한 저가 모델 라우팅이 토큰 수 감소를 뜻하지는 않으며, 비용 비교에는 계획·검토·재시도 및 도구 호출까지 포함해야 한다.
앞으로 개선하고 싶은 점
실제 GPT·Claude·Gemini 계열 API와 서버 측 실행 어댑터를 연결하고, 규칙 기반 계획을 실제 모델 기반 작업 분해·평가로 단계적으로 전환한다. 프로젝트 자료의 영속 저장과 작업별 맥락 선택·전달을 구현하고, 모델 전환 시 맥락 손실을 검증할 필요가 있다. 동일 과제를 단일 모델 / 모델 라우팅 / 라우팅+맥락 압축으로 비교해 품질·시간·사용자 개입·실제 API 비용을 측정하는 것이 우선 개선 과제다.