LG CNS의 Agentic AI를 활용한 APQR 시스템 설계 및 자동화 구축 사례

본 블로그는 LG CNS 와 AWS 가 공동 작성하였습니다.

품질보증 담당자가 QMS, LIMS, SAP, EDMS를 오가며 자료를 모으고 APQR 리포트 한 건을 완성하는 데는 약 12시간이 걸렸습니다. 종근당과 LG CNS는 Agentic AI로 이 시간을 약 1시간으로 줄였습니다.

LG CNS는 AWS 프리미어 파트너로, 다수의 대규모 엔터프라이즈 고객을 대상으로 SM(운영 유지보수)/AM(현대화)/Migration 서비스를 제공하고 있습니다. 이 글은 1941년 설립되어 전문의약품, 일반의약품, 건강기능식품을 생산하는 국내 주요 제약기업 종근당과 함께 진행한 APQR(연간 제품 품질 평가) 자동화 프로젝트에서 AWS 서비스와 Agentic AI로 품질 리포트 생성 과정을 시스템화한 실전 경험을 바탕으로 작성되었습니다.

여러 품질 시스템에 흩어진 자료를 신뢰할 수 있는 근거로 준비하고, Business Agent를 리포트 생성 워크플로우 안에서 실행해 APQR 리포트 생성 시간을 줄인 과정을 소개합니다.

들어가며

연간 제품 품질 평가(Annual Product Quality Review, APQR)는 한 제품이 지난 1년 동안 일관된 품질로 제조됐는지 검토하는 절차이며, 그 결과를 APQR 리포트로 정리합니다. 제약회사의 품질보증(QA) 담당자는 APQR 한 건을 작성하기 위해 품질 관리 시스템(QMS), 시험실 정보 관리 시스템(LIMS), 전사적 자원 관리 시스템인 SAP, 전자 문서 관리 시스템(EDMS)을 오가며 제품과 평가 기간에 맞는 자료를 찾아야 합니다.

기존에는 품질 담당자가 제품별 APQR 리포트 작성에 필요한 파일을 여러 시스템에서 직접 찾고 정리했습니다. 자료를 모은 뒤에도 누락 확인, 통계 계산과 경향 분석, DOCX 본문과 Excel 첨부 자료 작성, 근거 재확인 과정이 이어졌습니다.

종근당과 LG CNS는 이를 단순히 문장을 생성하는 문제가 아니라, 근거를 확인할 수 있는 APQR 작성 과정을 시스템으로 구현하는 문제로 정의했습니다. AWS 서비스를 기반으로 일탈, CAPA, 안정성 시험 등 12개 품질 업무를 맡는 Business Agent를 두고, 그 안에 조회, 계산, 해석과 문서 생성처럼 단위 기능을 수행하는 28개 유형의 Unit Agent를 사전 정의된 내부 실행 흐름으로 배치해 총 66개 이상의 실행 노드로 구성했습니다. 그 결과 APQR 리포트 생성 시간을 90% 이상 단축했습니다.

APQR 리포트 생성에서 해결해야 했던 세 가지 문제

여러 시스템의 자료가 바로 리포트의 근거가 되지는 않습니다

APQR 리포트에는 제품 정보부터 일탈, 시정 및 예방 조치(CAPA), 안정성 시험, 변경 관리와 시험 결과 경향 분석까지 서로 다른 품질 업무의 결과가 포함됩니다. 데이터가 저장된 시스템뿐 아니라 코드 체계, 날짜 기준, 파일 형식과 열 구조도 다릅니다.

원본 파일을 그대로 LLM에 전달하면 어느 버전을 사용했는지, 해당 제품과 기간의 자료만 사용했는지, 리포트의 수치가 어느 원본에서 나왔는지 확인하기 어렵습니다. 따라서 파일을 접수하고 형식과 대상을 확인한 뒤, 원본 참조를 유지한 조회용 데이터로 준비하는 과정이 먼저 필요했습니다.

수치 계산과 생성형 AI 서술은 검증 방식이 다릅니다

문서 번호와 상태를 조회하는 일, 통계와 업무 규칙을 계산하는 일, 계산 결과를 품질 관점에서 설명하는 일은 서로 다른 방법으로 검증해야 합니다.

이를 하나의 LLM에 맡기면 수치까지 생성 결과에 좌우됩니다. 결과가 잘못됐을 때 원인이 조회 조건, 계산식, LLM 입력, 문서 조립 중 어디에 있는지도 구분하기 어렵습니다. 조회와 수치 계산은 재현 가능한 코드로 처리하고, LLM은 확인된 결과를 바탕으로 해석과 서술을 담당하도록 역할을 나눴습니다.

여러 품질 업무가 하나의 실행 흐름에서 맞물립니다

APQR 리포트 생성은 Agent 하나가 한 번 응답하고 끝나는 작업이 아닙니다. 일탈, CAPA, 안정성, 변경 관리와 경향 분석 등 여러 품질 업무를 병렬로 처리하되, 필요한 결과가 모두 준비된 뒤에만 종합 의견과 첨부 목록을 만들고 최종 문서를 조립해야 합니다.

그래서 품질 업무별 Business Agent를 두고, 리포트 생성 워크플로우가 이들의 실행 순서와 결과 취합을 관리하도록 구성했습니다.

APQR 업무는 어떻게 달라졌는가

자동화 전후의 가장 큰 차이는 리포트 작성 주체를 AI로 바꾼 것이 아닙니다. 품질 담당자가 직접 수행하던 반복 작업을 시스템 단계로 옮기고, 담당자가 근거와 예외를 검토하는 데 집중할 수 있게 한 것입니다.

그림 1. 반복적인 수집·계산·문서 입력을 시스템이 수행하고 품질 담당자가 근거와 최종 내용을 검토하는 구조로 바꿨습니다.

종근당의 품질 담당자는 APQR 업무 절차와 검토 기준을 제공하고, 시스템이 준비한 근거와 계산 결과, 리포트를 검토합니다. LG CNS는 이 절차를 AWS 기반 APQR 시스템으로 구현했습니다.

AWS 기반 APQR 리포트 생성 구조

전체 플랫폼은 데이터 준비와 리포트 생성이라는 두 흐름으로 구성했습니다. 첫 번째 흐름은 QMS, LIMS, SAP, EDMS의 파일을 확인하고 표준화해 APQR 근거 데이터셋으로 준비합니다. 두 번째 흐름에서는 품질 담당자의 요청에 따라 리포트 생성 워크플로우를 실행하고, 준비된 근거만 사용해 APQR 리포트를 생성합니다.

두 흐름을 구분하면 파일 접수와 표준화 방식이 바뀌어도 리포트 생성 기능에 미치는 영향을 줄일 수 있습니다. 반대로 Business Agent나 문서 양식이 바뀌더라도 원본과 조회용 표준 데이터는 같은 기준으로 유지할 수 있습니다.

리포트 생성 워크플로우 안에서 품질 업무별 Business Agent가 실행되고, 각 Business Agent 안에서 필요한 Unit Agent가 실행됩니다. 상위 워크플로우는 Business Agent 간 선후 관계와 병렬 실행을 관리하고 결과를 취합합니다.

그림 2. 상단은 품질 담당자의 요청부터 APQR 리포트 생성·검토까지의 흐름이고, 하단은 품질 시스템의 파일을 조회 가능한 근거로 준비하는 흐름입니다. 두 흐름은 Amazon Athena(서버리스 SQL 쿼리 서비스)의 조회 결과가 조회 Unit Agent로 반환되는 지점에서 연결되며, Amazon Bedrock(완전관리형 생성형 AI 서비스)은 해석이나 내용 일관성 점검이 필요한 경우에만 호출됩니다.

각 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 모델 변경의 영향이나 응답 품질은 해석과 내용 일관성 점검 영역에서 별도로 확인할 수 있습니다.

APQR 요청 한 건이 리포트가 되는 과정

그림 3. 요청 조건과 근거 준비 상태를 확인하고 Business Agent를 병렬로 실행한 뒤, 결과를 취합해 만든 DOCX와 Excel을 품질 담당자가 검토하는 과정입니다.

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

파일을 신뢰할 수 있는 APQR 근거로 준비하기

파일은 업로드됐다는 이유만으로 APQR 리포트에 사용할 수 있는 근거가 되지 않습니다. 외부 시스템에서 받은 파일의 대상과 형식을 확인하고, 원본과 조회용 데이터를 구분한 뒤, 조회 Unit Agent가 리포트 요청 범위에 맞는 자료만 사용하게 해야 합니다.

그림 4. 파일의 대상과 형식을 확인하고, 원본을 보존한 뒤 요청에 필요한 범위만 조회하는 과정입니다.

접수 단계에서 파일의 대상과 형식을 확인합니다

파일 인터페이스는 수신한 파일의 출처와 자료 유형이 등록돼 있는지, 파일 형식과 열 구조가 지원 범위에 맞는지 확인합니다. 기준에 맞지 않는 파일은 처리 대상에서 분리하고 사유를 기록해, 데이터 문제를 Business Agent의 처리 오류로 오인하지 않도록 했습니다.

파일 접수와 후속 처리를 분리해 대량의 파일이 들어오더라도 파일 접수 요청에는 먼저 응답할 수 있게 했습니다. 일시적인 처리 실패는 다시 시도할 수 있도록 처리 상태와 실패 사유를 함께 관리했습니다.

원본과 조회용 데이터를 분리합니다

Amazon S3(객체 스토리지)에는 수신 원본과 문서 버전을 보존하고, 확인을 통과한 데이터는 조회에 적합한 표준 형태로 별도 준비합니다. 변환 결과를 표준 데이터로 반영하기 전에 형식과 건수를 확인해 불완전한 중간 결과가 APQR 근거에 포함되지 않도록 했습니다.

이 구조는 리포트에 사용한 데이터가 어느 원본에서 왔는지 확인하면서도, Business Agent가 원본 파일의 형식 차이를 매번 처리하지 않게 합니다.

Amazon Athena로 요청 범위만 조회합니다

조회 Unit Agent는 외부 품질 시스템과 전체 파일을 직접 읽지 않습니다. Amazon Athena에서 제품, 평가 기간과 문서 유형을 조건으로 필요한 항목만 조회하고, 결과에 원본 파일이나 문서 번호 참조를 유지합니다.

Amazon Athena를 활용하면 별도 분석 데이터베이스에 모든 파일을 복제하지 않고 Amazon S3의 표준 데이터를 SQL로 조회할 수 있습니다. 또한 조회 Unit Agent가 가져오는 범위를 요청 조건으로 제한해 불필요한 데이터와 LLM 입력을 줄일 수 있습니다.

일부 업무는 한 종류의 문서만 확인해서는 충분하지 않습니다. 문서 사이의 참조 관계까지 함께 확인해야 합니다. 이때 조회 Unit Agent는 기준이 되는 문서를 먼저 찾은 뒤, 연결된 문서를 이어서 조회합니다. 다음은 이 과정을 일반화한 예시입니다.

-- 개념 예시입니다. 실제 테이블·열 이름은 다르며, 조회 조건은 파라미터로 전달합니다.
WITH target_case AS (
    SELECT case_id, product_code, opened_date, source_file_uri
    FROM apqr_std.quality_case
    WHERE review_year = ?             -- 파티션 열: 평가 기간으로 스캔 범위를 먼저 제한
      AND product_code = ?            -- 평가 대상 제품
      AND opened_date BETWEEN ? AND ?
)
SELECT t.case_id,
       t.product_code,
       t.opened_date,
       t.source_file_uri,             -- 원본 파일 참조를 결과에 함께 반환
       l.linked_case_id,
       l.linked_case_type,
       l.linked_case_status
FROM target_case t
LEFT JOIN apqr_std.quality_case_link l
       ON l.review_year = ?           -- 조인 대상도 같은 파티션만 읽습니다
      AND l.case_id = t.case_id
      AND l.linked_case_status NOT IN ('CLOSED', 'CANCELED')
ORDER BY t.opened_date, l.linked_case_id;

예시에서는 파티션 열로 스캔 범위를 먼저 줄이고, 제품과 기간으로 기준 문서를 좁힌 뒤 그 문서와 연결된 항목을 붙입니다. 종결·취소 상태는 조인 조건에서 제외해 리포트 작성 시점에 확인할 항목만 남기고, 연결 문서가 없는 기준 문서는 LEFT JOIN으로 결과에 그대로 유지합니다. 조회 결과에는 원본 파일 참조(source_file_uri)를 함께 반환해 이후 검토에서 근거를 찾을 수 있게 했습니다. 테이블과 열 이름은 설명을 위해 일반화했습니다.

Business Agent를 리포트 생성 워크플로우 안에서 실행하기

Business Agent는 일탈, CAPA, 안정성, 변경 관리와 경향 분석처럼 APQR의 품질 업무 하나를 완성하는 실행 단위입니다. 각 Agent는 해당 업무에 필요한 Unit Agent를 내부 실행 흐름으로 구성합니다.

그림 5. 리포트 생성 워크플로우가 Business Agent를 병렬로 실행하고, 각 Business Agent가 업무에 필요한 Unit Agent를 내부 흐름으로 구성합니다.

하나의 대형 Agent 대신 공통 기능을 나눕니다

조회, 계산, 해석과 문서 생성을 하나의 Agent에 맡기면 오류 원인을 분리하기 어렵고, 같은 입력에 같은 결과가 필요한 계산까지 LLM 응답에 의존하게 됩니다. 이를 피하기 위해 공통 기능을 수행하는 Unit Agent를 처리 방식에 따라 나눴습니다.

• 조회 Unit Agent: Amazon Athena에서 요청 조건에 맞는 근거를 조회합니다.
• 데이터 정리 Unit Agent: 조회 결과의 날짜·숫자 형식을 통일하고 결측치를 정리합니다.
• 계산 Unit Agent: 사전에 정한 통계 방식과 업무 규칙에 따라 Python 기반 로직으로 계산합니다.
• 해석 Unit Agent: 필요한 경우 Amazon Bedrock을 호출해 확인된 결과를 해석하고 서술합니다.
• 섹션·첨부 생성 Unit Agent: 표, 차트, DOCX 본문에 들어갈 섹션과 Excel 첨부 자료를 생성합니다.

Business Agent마다 해당 품질 업무에 필요한 Unit Agent와 실행 순서를 사전에 정의했습니다. 정형 표를 만드는 업무는 조회·정리·섹션·첨부 생성 기능으로 처리하고, 통계 분석이 필요한 업무에는 계산 기능을 추가합니다. 해석이 필요한 업무에서는 계산 결과와 원본 참조, 적용 기준을 해석 Unit Agent에 전달합니다. 원본 파일 전체를 LLM에 맡기지 않아 계산과 서술의 책임을 분리하고 각 결과를 따로 확인할 수 있습니다.

APQR 리포트 생성 과정에는 LG CNS가 자체 개발한 Agent 오케스트레이션 프레임워크를 적용했습니다. 이 프레임워크는 조회·계산·문서 생성처럼 반복되는 기능을 Unit Agent로 만들어 재사용하고, 업무별 실행 순서는 설정으로 관리합니다. 이를 바탕으로 Business Agent를 만들기 때문에, 품질 업무별 Agent를 빠르게 추가할 수 있었습니다.

여러 Business Agent의 실행을 안정적으로 연결하기

APQR 리포트 생성에는 서로 독립적으로 처리할 수 있는 품질 업무와, 앞선 업무의 결과가 모두 모여야 시작할 수 있는 종합 단계가 함께 있습니다. 리포트 생성 워크플로우는 독립 업무를 병렬로 시작하고, 필요한 결과가 모이면 종합 의견 작성과 문서 생성으로 이어집니다.

워크플로우가 Business Agent를 직접 호출하고 응답을 기다리면, 한 Agent의 지연이 무관한 다른 업무까지 늦출 수 있습니다. 그래서 실행 요청과 처리 결과를 이벤트로 분리했습니다.

구조는 리포트 생성 워크플로우, 이벤트 전달 계층, Business Agent 세 부분으로 나뉩니다. 실행 조건이 충족되면 워크플로우는 요청 이벤트를 발행한 뒤 응답을 기다리지 않고 다음 판단을 계속합니다. Amazon EKS 위에서 별도로 운영하는 메시지 브로커 기반의 이벤트 전달 계층이 이 요청을 해당 Business Agent로 전달합니다.

Business Agent는 사전 정의된 내부 실행 흐름에 따라 처리한 뒤, 완료 또는 실패 이벤트를 발행합니다. 이벤트 전달 계층은 이 결과를 다시 워크플로우에 전달하고, 워크플로우는 받은 결과를 반영해 다음 단계를 진행합니다.

그림 6. 워크플로우가 요청 이벤트를 발행하면 이벤트 전달 계층이 Business Agent로 전달합니다. Agent가 발행한 완료·실패 이벤트는 동일 계층을 거쳐 다시 워크플로우에 전달되며, 다음 단계 진행을 결정합니다.

이렇게 분리하면 서로 의존하지 않는 Business Agent의 처리 시간이 전체 시간에 차례로 더해지지 않고, 한 Agent의 지연이나 일시적인 오류도 다른 Agent를 멈추게 하지 않습니다. 이벤트가 중복되거나 순서가 바뀌는 경우에는 처리 상태를 관리해 같은 요청이 다시 실행되지 않도록 하고, 오류가 나도 마지막 상태부터 이어서 처리할 수 있게 했습니다.

장기간 보존해야 하는 리포트 요청, 업무 구성과 실행 결과는 Amazon RDS for PostgreSQL(관리형 관계형 데이터베이스)에 저장합니다. Amazon ElastiCache(관리형 인메모리 캐시)는 사용자 세션과 캐시, 비동기 파일 처리를 지원해 장기 보존 이력과 수명이 짧은 애플리케이션 데이터를 분리했습니다.

실행 이력과 점검 결과로 품질 담당자의 검토를 지원하기

여러 Business Agent와 Unit Agent가 실행되면 결과만으로는 지연이나 오류가 발생한 위치를 찾기 어렵습니다. 시스템은 하나의 리포트 요청을 기준으로 Business Agent별 실행 단계와 결과를 연결하고, 이후 확인이 필요한 이력은 Amazon RDS for PostgreSQL에 저장합니다.

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

• 형식 확인: 생성돼야 할 파일과 필수 항목이 빠졌는지 확인합니다.
• 내용 일관성 확인: 품질 업무별 상세 결과와 종합 의견이 서로 어긋나지 않는지 확인합니다.
• 품질 담당자 검토: 원본 참조와 계산 결과, 점검 결과를 함께 검토하고 리포트를 최종 확정합니다.

도입 효과

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

프로젝트 내부 산정 자료에 따르면 이 범위에서 APQR 한 건에 필요한 시간은 약 12시간에서 약 1시간으로 줄었습니다. 이를 연간 약 500개 제품에 적용하면 총 투입 시간은 약 6,000시간에서 약 500시간으로 줄어, 연간 약 5,500시간을 절감한 것으로 산정됩니다.

반복적인 자료 수집과 형식 맞춤에 쓰던 시간이 줄면서 품질 담당자는 시스템이 준비한 근거와 계산을 확인하고 예외 사례와 품질 개선에 더 집중할 수 있게 됐습니다. 또한 표준화된 데이터, 재사용 가능한 Unit Agent, 품질 업무별 Business Agent와 실행 이력이 이후 개선에 활용할 수 있는 자산으로 남았습니다.

프로젝트에서 얻은 네 가지 교훈

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

향후 계획

다음 단계는 지금의 Business Agent를 다른 Agent와 애플리케이션도 그대로 호출할 수 있는 재사용 가능한 MCP(Model Context Protocol) 도구로 다듬는 것입니다. 검증된 업무 기능이 공용 도구로 공개되면, 사용자의 의도에 따라 필요한 데이터와 업무를 구성해 인사이트를 제안하는 단계로 넓힐 수 있습니다.

제약 품질 업무를 넘어 제조업 등 다른 산업에 적용할 수 있는 템플릿화도 함께 검토하고 있습니다.

마치며

종근당 APQR 프로젝트는 여러 시스템의 파일을 신뢰할 수 있는 근거로 준비하고, 재현 가능한 조회·계산과 LLM 기반 해석을 분리했으며, Business Agent를 리포트 생성 워크플로우 안에서 실행하도록 구성했습니다.

각 AWS 서비스가 맡을 책임과 경계를 분명히 하면 생성 속도를 높이면서도 리포트의 수치와 근거를 확인할 수 있습니다. Agentic AI의 가치는 문장 생성 자체보다, 신뢰할 수 있는 APQR 리포트 작성 방식을 일관되게 적용하고 그 범위를 넓히는 데 있습니다.

참고 자료

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

이 글의 도표, 예시 코드와 표기한 테이블·열 이름은 외부 공개가 가능한 수준으로 비식별 처리했으며, 실제 운영 환경의 구성과는 차이가 있습니다. 성과 수치는 프로젝트 내부 산정 기준에 따른 값으로, 적용 환경과 산정 범위에 따라 달라질 수 있습니다.

저자 소개