프롬프트 엔지니어링보다 데이터 파이프라인이 먼저입니다

LLM 기반 뉴스 서비스의 품질 개선기

자사 데이터 플랫폼에서는 외부 뉴스를 자동으로 수집하고, LLM으로 분류·요약해 내부 사용자에게 전달하는 뉴스 서비스를 운영하고 있습니다.

이미 운영 중인 서비스였지만 어느 순간부터 자사와 직접 관련 없는 기사가 섞이거나, 반대로 중요한 기사가 빠지는 문제가 반복적으로 나타났습니다.

처음에는 단순한 프롬프트 문제라고 생각했습니다.

하지만 원인을 찾기 위해 수집부터 최종 결과까지 Bottom-up으로 따라가 보니, 실제로는 데이터 파이프라인 전체를 함께 봐야 하는 문제였습니다.

1. 처음에는 분류 프롬프트만 고치려고 했습니다

가장 눈에 띄는 문제는 자사 뉴스의 오분류였습니다.

기사에서 자사가 여러 기업 중 하나의 사례로만 등장하거나, 관련 기사 영역에 회사명이 포함됐는데도 자사 뉴스로 분류되는 경우가 있었습니다.

반대로 실제로 중요한 자사·관계사 뉴스가 제외되는 경우도 있었습니다.

처음에는 분류 기준을 조금 더 명확하게 작성하면 해결될 것이라고 생각했습니다.

그런데 테스트를 반복할수록 프롬프트만으로 설명하기 어려운 결과가 나타났습니다.

그래서 프롬프트 수정을 잠시 멈추고, 뉴스 한 건이 수집되어 최종 결과가 나오기까지 어떤 과정을 거치는지부터 확인했습니다.

2. 파고들어 보니 문제는 파이프라인에 걸쳐 있었습니다

전체 구조를 확인해 보니 뉴스는 대략 다음 단계를 거치고 있었습니다.

검색·수집 → 후보 선별 → 분류·요약 → 중복 제거 → 카테고리 요약 → 최종 발송

중요한 것은 각 단계가 보는 정보와 역할이 서로 달랐다는 점입니다.

어떤 단계는 제목과 검색 결과 일부만 보고 있었고, 어떤 단계는 기사 본문까지 확인했습니다. 본문 접근에 실패하면 제한된 정보만으로 판단하기도 했고, 중복 제거 단계에서는 원문이 아니라 앞 단계에서 생성한 요약을 활용하고 있었습니다.

즉 최종 화면에서 보이는 하나의 오분류도 실제 원인은 달랐습니다.

• 검색 단계에서 잘못된 후보가 들어왔는지
• 본문을 제대로 읽지 못했는지
• 분류 기준이 부족했는지
• 중복 판단에 필요한 정보가 부족했는지

이 구조를 먼저 파악하고, 각 단계의 입력 데이터와 책임을 문서화했습니다.

3. 단계별 역할과 품질 기준을 다시 설계했습니다

구조가 보이기 시작하면서 모든 문제를 하나의 프롬프트에서 해결하려 하지 않았습니다.

수집 단계에서는 관련 후보를 충분히 확보하되, 동음이의어·단순 언급·관련 기사 영역 등 명확한 오염 패턴을 줄였습니다.

분류 단계에서는 단순히 키워드가 포함됐는지가 아니라, 실제 기사에서 자사가 핵심 주체인지를 다시 판단하도록 했습니다.

중복 제거 단계에서는 제목 표현이 달라도 동일한 발표·업데이트·이슈라면 대표 기사 하나로 정리하도록 기준을 보완했습니다.

이 과정에서 품질 기준도 다시 생각하게 됐습니다.

자사와 관련 없는 기사가 포함되는 것은 Precision(정밀도) 문제이고, 중요한 자사 기사가 빠지는 것은 Recall(재현율) 문제로 볼 수 있습니다.

Precision
모델이 “관련 있다”고 판단한 결과 중 실제로 관련 있는 결과의 비율
→ 높을수록 불필요한 결과가 적습니다.

Recall
실제로 찾아야 하는 관련 결과 중 모델이 얼마나 놓치지 않고 찾아냈는지의 비율
→ 높을수록 중요한 결과의 누락이 적습니다.

둘 다 중요하지만 실제 운영에서 오류의 비용은 달랐습니다.

잘못 포함된 뉴스는 사람이 최종 검수에서 제거할 수 있습니다.
하지만 중요한 기사가 자동 단계에서 아예 제외되면, 사람이 그 기사의 존재 자체를 알지 못할 수 있습니다.

그래서 중요 기사 Recall을 우선 확보하고, 후단 분류를 통해 Precision을 보완하는 방향으로 기준을 잡았습니다.

프롬프트 수정은 실제 데이터로 반복 검증했습니다

프롬프트를 수정한 뒤에는 여러 날짜의 수집 데이터와 분류 결과를 함께 비교했습니다.

• 중요한 기사가 빠지지 않았는지
• 무관한 기사가 포함되지 않았는지
• 동일한 이슈가 여러 건 남지 않았는지

그리고 수정한 문제 사례만 해결됐는지를 보지 않았습니다.

기존에 정상적으로 처리되던 기사까지 영향을 받지 않았는지 함께 확인했습니다.

프롬프트에도 일종의 회귀 테스트(Regression Test)가 필요했습니다.

4. Live에서는 ‘한 건의 오류’보다 패턴을 봤습니다

여러 날짜의 데이터를 반복 검증한 뒤 Live에 반영했습니다.
이후에는 오류 한 건이 발견될 때마다 바로 프롬프트를 수정하지 않았습니다.
운영 중에는 우선순위를 두고 확인했습니다.

중요 기사 누락 → 명확한 오입 → 중복 잔존

경계가 애매한 사례는 바로 수정하지 않고 관찰 대상으로 남겼습니다. 같은 문제가 반복될 때만 개선 후보로 올렸습니다. 예외 규칙을 계속 추가하면 당장의 한 사례는 해결할 수 있지만, 다른 정상 데이터를 망가뜨리는 과적합이 생길 수 있기 때문입니다.

결국 중요한 것은 모든 오류를 없애는 것이 아니라, 어떤 오류를 더 중요하게 관리할 것인지 기준을 세우고 지속적으로 관찰하는 것이었습니다.

5. 프롬프트 문제로 시작했지만, 결국 구조의 문제였습니다

이번 작업은 처음에는 “분류 프롬프트를 어떻게 고칠까?”라는 작은 문제로 시작했습니다.
하지만 원인을 따라가다 보니 뉴스가 어떤 순서로 처리되고, 각 단계가 어떤 데이터를 보고, 어디까지 책임지는지를 먼저 알아야 했습니다.

그래서 가장 먼저 한 일은 새로운 프롬프트를 쓰는 것이 아니라 기존 데이터 파이프라인을 파악하고 문서화하는 것이었습니다. 그 이후에야 각 단계의 개선 지점을 나눌 수 있었고, 품질 기준을 정하고, 프롬프트를 수정하고, 실제 데이터로 반복 검증해 Live까지 반영할 수 있었습니다.

이번 작업에서 가장 크게 남은 것은 특정 프롬프트 문장보다 이 접근 방식입니다.

프롬프트 문제로 시작했지만, 결국 데이터 파이프라인 전체를 이해하고 단계별로 개선해야 해결할 수 있는 문제였습니다.

LLM 서비스의 품질 문제를 만났을 때 결과 화면만 보고 모델이나 프롬프트부터 수정하기보다, 입력 데이터부터 중간 처리와 최종 출력까지 어디에서 품질이 결정되는지를 먼저 추적하는 것.

이번 작업에서 다시 확인한 가장 중요한 원칙이었습니다.