APQR 리포트 작성이 오래 걸리는 진짜 이유

APQR(Annual Product Quality Review, 연간 제품 품질 평가)은 한 제품이 지난 1년간 일관된 품질로 제조되었는지를 검토하는 절차입니다. 이 리포트 한 건을 쓰려면 품질보증(QA) 담당자가 품질 관리 시스템(QMS), 시험실 정보 관리 시스템(LIMS), 전사적 자원 관리 시스템(SAP), 전자 문서 관리 시스템(EDMS)을 오가며 제품·기간에 맞는 자료를 일일이 찾고, 누락을 확인하고, 통계와 경향을 계산한 뒤 DOCX 본문과 Excel 첨부까지 작성해야 합니다.

문제는 이 과정을 단순히 "AI에게 문서를 써 달라"고 맡기는 방식으로는 해결되지 않는다는 데 있습니다. 종근당과 LG CNS는 이를 세 가지 문제로 구체화했습니다.

첫째, 여러 시스템의 자료가 바로 리포트의 근거가 되지는 않습니다. APQR을 만들기 위해서는 제품 정보부터 일탈, 시정 및 예방 조치(CAPA), 안정성 시험, 변경 관리와 시험 결과 경향 분석까지 여러 품질 데이터를 포함해야 합니다. 데이터가 저장된 시스템뿐 아니라 코드 체계, 날짜 기준, 파일 형식과 열 구조도 다릅니다. 원본 파일을 그대로 LLM에 전달하면 어느 버전을 사용했는지, 해당 제품과 기간의 자료만 사용했는지, 리포트의 수치가 어느 원본에서 나왔는지 확인하기 어렵습니다.

둘째, 수치 계산과 생성형 AI 서술은 검증 방식이 다릅니다. 문서 조회, 통계·업무 규칙 계산, 계산 결과를 품질 관점에서 설명하는 일은 각각 다른 방법으로 검증해야 하는데, 이를 하나의 LLM에 맡기면 숫자까지 생성 결과에 좌우되고, 결과가 틀렸을 때 원인이 조회 조건인지 계산식인지 LLM 입력인지 구분하기 어려워집니다.

셋째, APQR은 하나의 응답으로 끝나는 작업이 아닙니다. 일탈, CAPA, 안정성, 변경 관리와 경향 분석 등 여러 품질 업무를 병렬로 처리하면서도, 모두 준비된 후에만 종합 의견과 최종 문서를 만들 수 있는 순서 제약이 있습니다.

종근당과 LG CNS의 해법: 역할이 분리된 Agent 구조

종근당과 LG CNS는 이 문제를 하나의 대형 AI 모델이 아니라, 역할이 분리된 Agent 구조로 풀었습니다.

• Business Agent: 일탈, CAPA, 안정성 시험 등 APQR을 구성하는 15개 품질 업무 하나하나를 완성하는 실행 단위입니다.
• Unit Agent: Business Agent 안에서 조회, 데이터 정리, 계산, 해석, 문서(섹션·첨부) 생성처럼 단위 기능을 수행하는 30개 유형의 실행 노드입니다.

전체적으로 45개 이상의 실행 노드가 사전에 정의된 내부 흐름으로 배치되어 있습니다

핵심은 역할 분리입니다.

1. 조회 Unit Agent — Amazon Athena에서 제품·평가 기간·문서 유형 조건에 맞는 근거만 조회합니다.
2. 데이터 정리 Unit Agent — 조회 결과의 날짜·숫자 형식을 통일하고 결측치를 정리합니다.
3. 계산 Unit Agent — 사전에 정한 통계 방식과 업무 규칙을 Python 기반 로직으로 계산합니다. 이 단계는 LLM을 거치지 않기 때문에 같은 입력에는 항상 같은 결과가 나옵니다.
4. 해석 Unit Agent — 확인된 계산 결과와 원본 참조, 품질 기준을 Amazon Bedrock에 전달해 해석·서술을 생성합니다. LLM은 여기서만 호출됩니다.
5. 섹션·첨부 생성 Unit Agent — 표, 차트, DOCX 섹션, Excel 첨부 자료를 만듭니다.

원본 파일 전체를 LLM에 넘기지 않고, 계산과 서술의 책임을 나눔으로써 결과가 잘못됐을 때 원인을 조회/계산/해석/조립 중 어디인지 바로 좁힐 수 있게 한 것이 이 구조의 핵심입니다.

이 프로젝트에는 LG CNS가 자체 개발한 Agent 오케스트레이션 프레임워크가 적용됐는데, 반복되는 기능을 Unit Agent로 재사용하고 업무별 실행 순서는 설정으로 관리하기 때문에 신규 Business Agent를 빠르게 추가할 수 있었습니다.

전체 구조 한눈에 보기: 데이터 준비 흐름과 리포트 생성 흐름

APQR 시스템은 두 개의 독립된 흐름으로 구성됩니다. 하나는 QMS·LIMS·SAP·EDMS의 파일을 확인·표준화해 근거 데이터셋으로 준비하는 흐름이고, 다른 하나는 담당자의 요청에 따라 그 근거만으로 리포트를 생성하는 흐름입니다. 두 흐름은 Amazon Athena의 조회 결과가 조회 Unit Agent로 반환되는 지점에서만 연결됩니다.

이렇게 흐름을 나누면 파일 접수 방식이 바뀌어도 리포트 생성 기능에 미치는 영향이 줄고, 반대로 Business Agent나 문서 양식이 바뀌어도 원본·표준 데이터는 같은 기준으로 유지할 수 있습니다. 여기서 Amazon Bedrock은 플랫폼의 '실행 기반'이 아니라, 해석이나 내용 일관성 점검이 필요한 순간에만 호출되는 '기능'이라는 점이 핵심입니다. 자료 조회, 통계 계산, 워크플로우 제어, 형식·누락 확인, 문서 조립은 모두 애플리케이션 코드가 담당합니다.

AWS 기반 APQR 리포트 생성 구조

각 AWS 서비스는 데이터와 상태를 얼마나 오래 보관할지, 애플리케이션을 어디에서 실행할지, 어떤 운영 책임을 맡길지를 기준으로 선택했습니다.

Amazon EKS에서 실행되는 APQR 애플리케이션이 Amazon Bedrock을 호출하는 방식

Amazon EKS(관리형 Kubernetes 서비스)는 APQR 플랫폼의 애플리케이션 실행 기반입니다. 관리 시스템, 외부 품질 시스템과 파일을 주고받는 인터페이스, 데이터 준비, Business Agent와 리포트 생성 워크플로우, DOCX·Excel 문서 생성 기능이 컨테이너 형태로 배포되어 실행됩니다.

Amazon Bedrock은 APQR 애플리케이션의 실행 기반이 아니라, 그중 일부 기능이 LLM을 필요로 할 때 호출하는 관리형 서비스입니다. Amazon EKS에서 실행되는 해석 Unit Agent는 확인된 조회·계산 결과와 원본 참조, 품질 기준, 출력 형식을 Amazon Bedrock API에 전달합니다. 내용 일관성 점검도 의미 비교가 필요한 경우에만 별도로 Amazon Bedrock을 호출합니다. 자료 조회, 통계 계산, 기본 워크플로우 제어, 형식·누락 확인과 문서 조립은 애플리케이션 코드가 담당합니다.

이 구분을 통해 계산 결과는 모델 응답과 독립적으로 재현하고, LLM 모델 변경의 영향이나 응답 품질은 해석과 내용 일관성 점검 영역에서 별도로 확인할 수 있습니다.

여러 Business Agent를 안정적으로 연결하는 법: 이벤트 기반 실행

리포트 생성 워크플로우가 Business Agent를 직접 호출하고 응답을 기다리는 방식이라면, 한 Agent의 지연이 무관한 다른 업무까지 늦출 수 있습니다. 이 프로젝트는 실행 요청과 처리 결과를 이벤트로 분리해 이 문제를 풀었습니다.

워크플로우는 실행 조건이 충족되면 요청 이벤트를 발행한 뒤 응답을 기다리지 않고 다음 판단을 계속합니다. Amazon EKS 위의 메시지 브로커 기반 이벤트 전달 계층이 이 요청을 해당 Business Agent로 전달하고, Agent는 처리 후 완료·실패 이벤트를 다시 발행합니다.

이 구조 덕분에 서로 의존하지 않는 업무의 처리 시간이 전체 시간에 차례로 더해지지 않고, 한 Agent의 지연이나 일시적 오류가 다른 Agent를 멈추게 하지 않습니다. 이벤트 중복이나 순서 바뀜은 처리 상태로 관리해, 같은 요청이 중복 실행되지 않게 하고 오류 발생 시에도 마지막 상태부터 이어서 처리할 수 있게 했습니다.

하나의 요청이 리포트가 되기까지: 5단계

1. 요청 조건 저장: 제품, 평가 기간, 리포트 유형을 하나의 요청으로 저장합니다.
2. 근거 준비 확인: 필요한 파일 처리가 끝났는지 확인하고, 요청 범위·원본 참조가 유지된 자료만 사용합니다.
3. Business Agent 병렬 실행: 리포트 생성 워크플로우가 일탈·CAPA·안정성·변경 관리·경향 분석 등을 맡은 Business Agent 간의 선후 관계를 관리하며 병렬로 실행합니다.
4. 결과 취합과 리포트 생성: 모든 업무 결과가 준비되면 종합 의견과 첨부 목록을 만들고 DOCX·Excel로 조립해 Amazon S3에 저장합니다.
5. 점검 결과 확인과 최종 확정: 담당자가 원본 참조, 계산 결과, 누락 가능 항목, 내용 일관성을 확인하고 최종 확정합니다.

점검 기능은 리포트를 자동 승인하거나 다시 작성하지 않습니다. 파일·필수 항목 누락은 애플리케이션 코드로 확인하고, 의미 비교가 필요한 내용 일관성 점검에만 Amazon Bedrock을 선택적으로 사용해, 담당자가 우선 검토할 항목만 좁혀줍니다.

데이터를 '신뢰할 수 있는 근거'로 만드는 3단계

파일은 업로드되었다는 사실만으로 APQR 리포트의 근거가 되지 않습니다. 원본 파일을 근거로 바꾸는 과정은 세 단계로 나뉩니다.

1. 접수 단계에서 대상/형식 확인: 파일의 출처와 자료 유형이 등록돼 있는지, 형식과 열 구조가 지원 범위에 맞는지 확인합니다. 기준에 안 맞는 파일은 처리 대상에서 분리하고 사유를 기록해, 데이터 문제를 Agent의 처리 오류로 오인하지 않도록 합니다.
2. 원본과 조회용 데이터 분리: Amazon S3에 수신 원본과 문서 버전을 보존하고, 확인을 통과한 데이터만 조회에 적합한 표준 형태로 별도 준비합니다.
3. Amazon Athena로 요청 범위만 조회: 조회 Unit Agent는 전체 파일을 직접 읽지 않고, 제품·평가 기간·문서 유형을 조건으로 필요한 항목만 SQL로 조회하며, 결과에 원본 파일 참조를 함께 반환합니다.
   

이 구조 덕분에 리포트에 사용한 수치가 어느 원본에서 나왔는지 항상 추적할 수 있고, Business Agent는 원본 파일마다 다른 형식 차이를 매번 처리할 필요가 없습니다.

도입 효과

종근당은 이 시스템으로 APQR 리포트 생성 업무에 드는 시간을 90% 이상 줄였습니다. 여기서 생성 업무는 자료 준비부터 리포트 작성과 검토까지 프로젝트에서 산정한 범위를 뜻합니다.

프로젝트 내부 산정 자료에 따르면, 자료 준비부터 작성·검토까지 APQR 리포트 한 건에 걸리는 시간은 약 12시간에서 약 1시간으로 줄었습니다. 이를 연간 약 500개 제품에 적용하면 총 투입 시간은 약 6,000시간에서 약 500시간으로, 연간 약 5,500시간이 절감되는 것으로 산정됩니다.

시간이 줄어든 것 자체보다 중요한 변화는, 품질 담당자가 반복적인 자료 수집·형식 맞춤 대신 시스템이 준비한 근거와 계산 결과를 검토하고, 예외 사례와 품질 개선에 더 집중할 수 있게 됐다는 점입니다.

표준화된 데이터, 재사용 가능한 Unit Agent, 업무별 Business Agent와 실행 이력은 이후 다른 품질 업무나 다른 산업으로 확장할 수 있는 자산으로 남았습니다.

프로젝트가 남긴 네 가지 교훈

1. 데이터를 먼저 신뢰할 수 있게 준비한다 — 파일 유형·버전·변환 상태를 확인하고 원본 참조를 일관되게 관리해야 같은 근거를 반복해서 쓸 수 있습니다.
2. 수치 계산과 생성형 AI의 역할을 나눈다 — 사실·수치·업무 규칙은 코드가, 해석은 LLM이 제한된 범위에서 맡습니다.
3. Agent를 워크플로우 안에서 구성한다 — Business Agent 간 선후 관계, 병렬 실행, 결과 취합을 하나의 구조로 관리해야 합니다.
4. 최종 판단은 사람이 맡는다 — 시스템은 리포트와 점검 결과를 준비할 뿐, 품질 판단과 승인을 대신하지 않습니다.

향후에는 지금의 Business Agent를 다른 Agent·애플리케이션에서도 그대로 호출할 수 있는 MCP(Model Context Protocol) 도구로 다듬고, 제약 품질 업무를 넘어 제조업 등 다른 산업에 적용할 수 있는 템플릿화도 검토하고 있습니다.

▌요약

• APQR 리포트 자동화의 품질 상한은 LLM의 서술 능력이 아니라 데이터 근거화 단계에서 결정됩니다. QMS·LIMS·SAP·EDMS의 원본 파일을 그대로 LLM에 넘기면 어느 버전·기간 자료를 썼는지, 수치가 어느 원본에서 나왔는지 추적할 수 없습니다.
• 종근당과 LG CNS는 하나의 대형 LLM에 전 과정을 맡기지 않고, Business Agent(15개 품질 업무 단위)와 Unit Agent(조회·정리·계산·해석·문서생성 등 30개 유형)로 역할을 쪼갰습니다. 계산은 Python 로직으로 고정해 같은 입력에 항상 같은 결과가 나오게 하고, LLM은 해석·서술 단계에서만 호출됩니다.
• Amazon Bedrock은 플랫폼의 실행 기반이 아니라, 해석과 내용 일관성 점검이 필요한 순간에만 호출되는 '기능'으로 설계됐습니다. 조회·계산·워크플로우 제어·문서 조립은 모두 애플리케이션 코드가 담당해, 결과가 틀렸을 때 원인을 바로 좁힐 수 있습니다.
• 여러 Business Agent는 직접 호출-응답이 아니라 이벤트 기반으로 연결돼 한 Agent의 지연이나 오류가 다른 무관한 업무의 처리 시간에 영향을 주지 않습니다.
• APQR 리포트 자동화 도입 효과로 리포트 1건당 소요 시간이 약 12시간에서 약 1시간으로, 연간 약 500개 제품 기준 총 투입 시간이 약 6,000시간에서 약 500시간으로 줄었습니다. 품질 담당자는 자료 수집·형식 맞춤 대신 검토와 예외 대응에 집중할 수 있게 됐으며, 최종 판단은 여전히 사람이 맡고 향후 MCP 도구화 및 타 산업 확장을 검토 중입니다.

▌ FAQ

Q1. 생성형 AI가 만든 보고서의 숫자를 그대로 믿어도 되나요?

A1. LLM에 원본 데이터를 통째로 넘겨 계산까지 맡기면 수치가 생성 결과에 좌우될 수 있어 생성형 AI가 만든 보고서의 숫자를 신뢰하기 어렵습니다. 이 때문에 이번 프로젝트에서는 통계와 업무 규칙 계산을 Python 기반 코드로 처리해 같은 입력에 항상 같은 결과가 나오게 하고, LLM은 이미 확인된 계산 결과를 해석·서술하는 데만 사용했습니다. 계산과 서술의 책임을 나누면 결과가 틀렸을 때 원인도 더 쉽게 찾을 수 있습니다.

Q2. 기업의 생성형 AI 도입 프로젝트는 왜 성과를 내지 못하는 경우가 많나요?

A2. MIT 미디어랩 NANDA 이니셔티브의 'GenAI Divide' 보고서는 조사한 기업의 생성형 AI 시범사업 중 상당수가 손익에 측정 가능한 영향을 내지 못했다고 밝혔습니다. 기업의 생성형 AI 도입 프로젝트는 왜 성과를 내지 못하는 흔한 원인은 여러 시스템에 흩어진 데이터를 정리하지 않고 AI에 그대로 맡기거나, 계산이 필요한 업무까지 AI의 생성 결과에 의존하는 것입니다. 데이터를 먼저 신뢰할 수 있는 근거로 준비하고, 계산과 해석의 역할을 나누는 접근이 이를 보완하는 방법으로 꼽힙니다.

Q3. 제약회사가 QMS·LIMS 같은 여러 시스템에 AI를 도입하려면 무엇부터 준비해야 하나요?

A3. 제약회사가 QMS·LIMS 같은 여러 시스템에 AI를 도입하기 위해 가장 먼저 필요한 것은 AI 모델이 아니라 데이터 정리입니다. 시스템마다 다른 코드 체계, 날짜 형식, 파일 구조를 확인하고, 원본 파일과 조회에 적합한 표준 데이터를 분리해 관리하는 것이 우선입니다. 원본 참조를 유지한 채로 표준화해야, 이후 AI가 만든 결과의 근거를 언제든 원본에서 확인할 수 있습니다.

Q4. APQR 같은 정기 보고서 작성 시간을 줄이려면 어떤 방법이 있나요?

A4. APQR 같은 정기 보고서 작성 시간을 줄이려면 반복되는 자료 수집·계산·문서 입력 작업을 시스템으로 옮기고, 담당자는 근거 검토와 예외 처리에 집중하는 구조가 효과적입니다. 종근당 사례에서는 이 방식으로 리포트 한 건 작성 시간이 약 12시간에서 약 1시간으로 줄었습니다. 핵심은 AI가 보고서를 '대신 쓰는 것'이 아니라, 근거 수집과 계산을 표준화해 담당자의 검토 시간을 줄이는 데 있습니다.

▌ 참고자료

• Amazon S3 — 원본 파일과 조회용 표준 데이터, 리포트 산출물 보관: 서비스 소개 · 사용자 가이드
• Amazon Athena — Amazon S3의 데이터를 SQL로 조회: 서비스 소개 · 사용자 가이드 · 파티션으로 스캔 범위 제한
• Amazon EKS — 컨테이너 기반 애플리케이션 실행: 서비스 소개 · 사용자 가이드
• Amazon Bedrock — 해석·내용 일관성 점검에 사용한 관리형 LLM: 서비스 소개 · 사용자 가이드
• Amazon RDS for PostgreSQL — 요청과 실행 이력 보존: 서비스 소개 · 사용자 가이드
• Amazon ElastiCache — 세션·캐시와 비동기 파일 처리 지원: 서비스 소개 · 사용자 가이드
• Model Context Protocol — 향후 계획에서 언급한 도구 연동 표준: 공식 문서

관련 오퍼링 및 문의하기

• Agentic AI | LG CNS | Korea
• LG CNS 홈페이지 문의하기

본 콘텐츠는 저작권법에 의해 보호받는 저작물로 LG CNS에 저작권이 있습니다.

사전 동의 없이 2차 가공 및 영리적인 이용을 금합니다.