날조 없이 DB 팩트로 자동 설명 생성하기

새 피처가 나오거나 운영 데이터가 쌓이면, 그것을 설명하는 텍스트가 필요한 순간이 온다. 멤버의 소개글, 앨범의 분석 결과, 혹은 이벤트의 요약—이런 일들은 수작업으로 하면 비용이 크고 일관성도 떨어진다. 그래서 자동화를 생각하는데, 많은 팀이 바로 LLM 을 떠올린다. 빠르고 유연하고 그럴듯하니까. 하지만 이번에는 다르게 접근하기로 했다.

왜 LLM을 쓰지 않았나

enrich_text.py 는 이름 그대로 텍스트를 "풍부하게" 만드는 모듈인데, 멤버 bio 나 앨범 분석 같은 데이터에 대한 영어 설명을 자동으로 생성해야 했다. 처음에는 당연히 LLM 기반 생성기를 고려했다. 몇 줄 프롬프트와 API 호출이면 끝이니까.

그런데 운영 관점에서 생각해보니 문제가 있었다. 사실성이다. 팩트 하나가 틀리면, 이걸 사용자가 읽는 순간 신뢰도가 떨어진다. 특히 멤버의 경력 정보나 앨범의 통계 수치처럼 검증 가능한 정보라면 더 그렇다. LLM 의 hallucination 은 명확하지 않고, 오류를 일일이 캐치하기도 어렵다.

반대로, 우리가 이미 DB 에 갖고 있는 정보들—멤버 이름, 가입 시기, 앨범 곡 수, 평점, 뷰 수 등—은 검증된 팩트들이다. "왜 이 정보를 버리고 새로 만들까?" 라는 단순한 질문에서 출발했다.

팩트 조립 방식으로 설계하다

enrich_text.py 의 핵심은 템플릿 + 데이터 조합이다. 개념적으로는 간단하다:

• DB 에서 필요한 정보 쿼리 (멤버 프로필, 활동 기간, 앨범 메타데이터 등)
• 그 정보를 구조화된 문장 틀에 채워넣기
• 필요에 따라 조건부 로직 적용 (예: 신곡이면 "recently released", 인기도가 높으면 "top-rated" 같은 수식어)

이렇게 하면:

특히 추적 가능성이 중요했다. 나중에 "왜 이렇게 썼지?" 라고 물었을 때, 정확히 DB 의 어떤 값에서 비롯된 것인지 알아야 한다. 운영진이 오류를 신고해도, 로직을 수정하면 된다. 반복 가능하고, 재현 가능하고, 논의 가능하다.

팀에 미치는 영향

이런 선택이 흥미로운 이유는 기술 의사결정의 우선순위 시프트를 반영하기 때문이다. 1-2년 전이라면, "LLM 으로 더 자연스럽게" 라는 압박이 있었을 것 같다. 하지만 지금은 대량 운영 환경에서 "정확하고, 유지 가능하고, 비용 효율적인가?" 가 더 중요해졌다.

멤버십 봇이나 자동화 파이프라인을 운영하는 팀 입장에서는, 매일 수백 개 기록이 생성된다. 거기에 LLM 을 붙이면, API 비용도 늘어나고, 오류도 제어하기 어렵고, 디버깅도 느리다. 반면 팩트 조립 방식은 문제가 발생하면 로그만 봐도 "아, 이 필드가 비어 있구나" 하고 바로 원인을 찾는다.

또한 이건 낮은 수준의 기술 의사결정이 아니라 문화의 문제이기도 하다. "최신 기술을 최대한 활용한다" 에서 "문제에 맞는 올바른 도구를 쓴다" 로의 shift. 팀 내 후배나 새로운 엔지니어들도 이런 판단을 배우면서, 자기도 비슷한 상황에서 쉽게 선택할 수 있게 된다.

일반적 패턴으로 보면

이런 류 자동화는 어디에나 있다:
- 이메일 발송: 템플릿 + 사용자 정보 조합
- 리포트 생성: 쿼리 결과를 정해진 포맷으로 나열
- 알림 메시지: 이벤트 타입에 따라 미리 작성된 문구 대입

LLM 이 대안이 될 수 있지만, 정확성이 중요한 도메인이라면 팩트 기반을 기본으로 삼고, 필요한 부분만 생성형으로 보강하는 하이브리드도 고려해볼 만하다.

마무리

enrich_text.py 는 크기는 작지만, 철학이 담긴 작은 결정이다. "LLM 을 안 쓴다" 가 아니라, "사실이 먼저다" 라는 우선순위의 표현이다. 운영하다 보니 이런 판단이 얼마나 중요한지 알게 된다.

🛒 이 글과 어울리는 추천 상품

• 기계식키보드 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.