[HeartFeed] 고전 문장을 데이팅 조언으로 바꾸는 작업에서 배운 것

HeartFeed를 처음 만들 때 목표는 단순했다. 사람들의 연애 관련 고민에 AI가 답변해 주는 서비스. 그런데 만들다 보니 "답변해 주는 것" 자체가 문제가 되었다. AI가 너무 빨리, 너무 유창하게 답하면 사용자는 자기 생각을 멈춘다.

그 경험이 HeartFeed의 방향을 바꿨다.

빠른 답이 위험한 이유

AI 상담 서비스를 만들 때 가장 쉬운 방향은 유창한 조언을 바로 보여 주는 것이다. 입력을 받으면 분석하고, 요약하고, 다음 행동을 제안한다. 사용자는 그 흐름을 좋아한다. 그런데 이 장점이 곧 리스크이기도 하다.

답이 빠르면 사용자는 그 답을 자기 상황에 맞춰 해석하기 전에 받아들인다. 복잡한 감정을 한 문장으로 정리하고, 아직 생각하지 않은 문제에 대해 조언하는 것은 도움이 아니라 개입이 된다. HeartFeed에서는 이 경계를 먼저 잡아야 했다.

고전 문장을 어떻게 쓸 것인가

HeartFeed의 독특한 점은 고전 문학에서 끌어온 이야기를 데이팅 조언에 섞는 것이었다. 그런데 이 작업도 처음에는 잘못된 방향으로 갔다. 고전 문장을 마치 답처럼 배치하면, 권위가 곧 답변이 되어 버렸다.

고전 문장은 결론이 아니라 질문으로 써야 했다. "이렇게 살아라"가 아니라 "너는 지금 무엇을 붙잡고 있나"를 전달하는 장치. 사용자가 자기 경험으로 답을 찾아가게 만드는 거울. 그래서 명경과 Ruminate 프로젝트에서 고전 문장의 역할을 결론에서 질문으로 옮겼다.

HeartFeed에서도 같은 원칙이 적용되었다. 이야기가 사용자에게 들려지는 것이 아니라, 사용자가 자기 이야기를 다른 관점에서 보게 만드는 쪽으로.

multi-turn 대화가 만든 문제

HeartFeed는 multi-turn 대화를 지원한다. 사용자가 첫 질문을 하고, 후속 질문을 하면서 맥락이 쌓인다. 그런데 이 multi-turn 구조에서 문제가 생겼다.

처음에는 follow-up 질문이 관계 맥락을 잊어버렸다. 사용자가 "우리 사이에서 이게 문제인데"라고 말했는데, 다음 답변에서 "우리"의 의미를 잃어버리는 것이다. 서버와 프론트엔드 모두에서 multi-turn scope inheritance를 고쳤고, follow-up 질문이 이전 대화의 관계 맥락을 물려받도록 만들었다.

다른 문제는 clarification이 중간에 끼어드는 것이었다. 사용자가 이야기를 이어가려는데 AI가 "관련 링크가 있으니 참고하세요"를 끼워 넣으면 대화의 리듬이 깨진다. clarification은 사용자가 멈춘 상태에서만 오도록 수정했다.

latency를 줄이는 과정

HeartFeed의 v2 파이프라인은 여러 단계를 거친다. 사용자의 질문이 들어오면 RAG로 관련 자료를 찾고, LLM이 답변을 생성하고, 검증을 거쳐 사용자에게 전달된다. 이 과정에서 latency가 너무 길면 사용자는 기다리다 지친다.

줄인 것은 많았다. max_tokens를 줄이고, retry 횟수를 줄이고, top_k와 context chunks를 줄였다. generator timeout도 줄였다. 그런데 단순히 줄이는 것이 능사는 아니었다. 너무 많이 줄이면 답변의 품질이 떨어지고, 너무 적게 줄이면 사용자가 기다린다.

중간 지점을 찾는 과정은 실제로 서비스를 켜놓고 반복 테스트하는 수밖에 없었다. 숫자로 된 지표보다 실제 사용 경험에서 "이 정도면 기다릴 만하다"가 어디인지가 중요했다.

고전 문학 데이터베이스를 넓힌 이유

HeartFeed의 고전 문학 코퍼스는 처음에 좁았다. 몇몇 한국 고전과 동양 고전이 전부였다. 그런데 사용자가 실제로 묻는 질문은 그보다 훨씬 넓었다.

고전 문학 데이터베이스를 넓히면서 배운 것은, 문장의 출처보다 문장이 사용자에게 어떤 질문을 던지는지가 중요하다는 것이었다. classic literature corpus를 확장하고, scoring을 통해 어떤 문장이 어떤 상황에 적합한지 판단하는 middleware를 만들었다. 이야기에 순위를 매기는 것이 아니라, 사용자의 고민과 문장의 거리를 재는 일이었다.

Prod에서 살아남은 것

HeartFeed는 실제로 사용자가 쓰는 서비스가 되었다. prod 환경에서 요청이 들어오고, 응답이 나간다. 이 과정에서 드러난 것은 예상 못한 failure mode들이었다. JSON 응답이 깨지는 경우, LLM 제공자가 응답을 거부하는 경우, 프론트엔드가 비정상 응답을 그냥 보여 주는 경우.

이 모든 것을 prod에서 고쳤다. 테스트 환경에서 잡히지 않는 문제들은 실제 요청으로만 보인다. HeartFeed의 현재 안정성은 prod에서 반복된 수정의 결과이지, 설계 단계에서 예측한 것이 아니다.

마치며

HeartFeed를 만들면서 가장 크게 바뀐 것은 AI가 답변하는 속도에 대한 판단이었다. 빠르게 답하는 것이 항상 좋은 것은 아니었다. 사용자가 자기 생각을 할 시간을 확보하는 것이 오히려 더 중요한 경계였다. 고전 문장을 질문으로 쓰고, multi-turn 맥락을 보존하고, latency를 줄이되 품질을 포기하지 않는 것—이 모든 것은 "어떤 답이 좋은 답인가"라는 질문에 대한 현재의 답이다.