기존 구조로 지원할 수 없던 요구사항을 위해 운영 파이프라인을 다시 설계하다

새로운 요구사항을 프롬프트 수정으로만 처리하지 않고, 고객과 엔지니어링 사이에서 구조적 문제를 해결했습니다.

서비스는 LangChain, RAG, GPT를 활용해 지문에서 영어 문제를 생성하고 있었습니다. 이미 사용 중이었지만 생성 품질이 점차 흔들리고 있었습니다.

• 같은 문제가 중복 생성됐습니다.
• 오답 선택지가 지문과 관련 없는 내용으로 생성되기도 했습니다.
• Few-shot 검색이 의도한 문제 유형이나 학생 수준과 맞지 않는 예시를 선택했습니다.
• 생성 실패가 최종 결과 전에 일관되게 걸러지지 않았습니다.

개별 프롬프트만의 문제가 아니었습니다. 검색, 출력 구조, 검증 과정이 모두 최종 품질에 영향을 주고 있었습니다.

고객은 생성 도구를 자사 서비스에 내장할 계획이었고, 1지문 2문항은 고객 제품에서 반드시 지원해야 하는 형식이었습니다.

“하나의 지문에서 서로 연결된 문제 두 개를 생성해주세요.”

고객 요구사항

겉으로는 출력 개수를 하나 늘리는 요청처럼 보였습니다. 하지만 기존 시스템은 한 번의 생성 과정에서 독립적인 문제 하나를 만드는 구조였고, 각 문제가 개별적으로 컨텍스트를 관리해 두 문제가 함께 참조할 수 있는 지문 단위 구조가 없었습니다.

프롬프트 호출을 한 번 더 하면 문제 두 개를 만들 수는 있지만, 같은 지문 맥락을 공유하거나 유효한 연계 문제로 구성된다는 보장은 없었습니다.

요청을 두 가지 범위로 나누고 차이를 고객에게 직접 설명했습니다.

단계 이름은 일반화해 표기했습니다. 실제 파이프라인 컴포넌트와 캐시 이름은 고객 확인 전까지 공개하지 않습니다.

수치는 변경 이후 테스트한 생성 파이프라인 기준입니다. 정확한 측정 조건과 약 800회 테스트의 문제 유형별 구성은 게시 전 고객 확인이 필요합니다.

기술적 한계는 실행 가능한 경로와 함께 설명할 때 가장 유용했습니다. 요구사항을 "지금 가능한 것"과 "아키텍처 변경 후 가능한 것"으로 나누어, 제약을 숨기지 않으면서도 고객과 방향을 합의할 수 있었습니다.

LLM 출력의 실패가 프롬프트에서 시작되는 것만은 아니라는 점도 확인했습니다. 검색 품질, 공유 컨텍스트, 데이터 구조, 검증, 캐싱이 모두 최종 결과에 영향을 주었습니다.

다시 진행한다면 검색 품질 검사를 더 이른 단계에 추가할 것입니다. Few-shot 불일치가 생성 이후의 품질 문제로 이어지기 전에 발견할 수 있습니다.