Story Arch

운영 중

웹소설 작가를 위한 SaaS. LLM 3개를 교차시켜 브레인스토밍하고, 벡터 검색으로 장편 원고의 과거 설정을 찾고, 회수되지 않은 복선을 목록으로 추적한다.

풀려고 한 문제

장편을 200화까지 쓰면 50화 전에 깔아둔 복선을 작가 자신이 잊는다. 원고가 길어질수록 사람의 기억이 병목이 되는데, 이건 검색과 목록으로 풀 수 있는 문제였다.

상황

브레인스토밍 결과가 한 모델의 취향으로 쏠리는 문제

선택

OpenAI · Claude · Gemini에 같은 질문을 던져 결과를 나란히 두는 구조

이유

모델마다 기본으로 끌리는 전개가 다릅니다. 하나만 쓰면 그 모델의 평균값이 그대로 원고가 됩니다. 셋을 붙여 서로 다른 답을 보게 만드는 게, 더 좋은 모델 하나를 고르는 것보다 창작에는 쓸모가 있었습니다.

상황

원고 100만 자에서 '그 설정 어디 있었지'를 찾는 문제

선택

키워드 검색이 아니라 PgVector 임베딩 검색

이유

작가는 자기가 쓴 표현을 정확히 기억하지 못합니다. '주인공이 칼을 버린 장면'처럼 의미로 찾아야 해서, 별도 벡터 DB를 붙이는 대신 이미 쓰던 PostgreSQL에 PgVector를 올려 운영 대상을 늘리지 않았습니다.

상황

복선을 깔았는지 회수했는지 사람이 기억해야 하는 문제

선택

복선을 {깔린 화, 회수될 화, 상태} 레코드로 만들어 미회수분만 띄우는 화면

이유

이건 AI가 풀 문제가 아니라 대장을 만들면 끝나는 문제였습니다. 도메인을 알아야 보이는 요구사항이라, 제가 웹소설을 직접 쓰면서 겪은 걸 기능으로 옮겼습니다.

라이브 사이트에서 원고를 넣고 의미 검색과 복선 대장 화면 시연

ReactExpressPostgreSQLPgVectorOpenAIClaudeGemini