"제약 회사 내부 직원이 쓰는 형태로, 임상/법무/재무를 동시에 다루는 케이스를 가정"
A. User/Staff
- 사람이 자연어로 질문(예: “이 약의 임상 결과 요약 + 부작용 추세 + 관련 특허/법무 리스크 + 예산 영향”)을 던지는 진입점.
B. Supervisor Agent (Main)
-
오케스트레이터(지휘자) 역할.
-
하는 일:
- 사용자의 질문을 작업 단위로 분해(임상/법무/재무)
- 각 작업을 가장 적합한 Sub-Agent에 라우팅
- Sub-Agent 결과를 충돌 없이 정합성 체크(수치/용어/기간/출처)
- 최종 답변을 하나의 스토리로 합성
핵심: 멀티 에이전트에서 “똑똑한 개별 에이전트”보다 중요한 건, Supervisor가 ‘누가 무엇을 언제 어떻게’ 하게 만드는지(Workflow 제어)
C. Sub-Agents (SA1/SA2/SA3)
SA1 — Pharma R&D (임상/연구)
-
Knowledge Base: Clinical Trial Reports (임상시험 보고서 등 문서)
-
Action Group: 있음
-
Athena 연동: 있음
-
의미:
- 문서 기반 요약/근거 인용(RAG)도 하고,
- 필요하면 S3의 구조화 데이터(임상/부작용/약물 데이터)를 Athena로 SQL 질의해 “수치 근거”도 뽑을 수 있음.
SA2 — Legal (법무)
-
Knowledge Base: Legal Briefs, Patents
-
Action Group: 그림상 없음
-
의미:
- 법무는 종종 “정형 DB 질의”보다 문서 해석(계약/판례/특허 텍스트, 리걸 브리프) 중심이라 KB만으로도 유효.
- 다만 실제 운영에서는 법무도 (특허 메타데이터, 소송 히스토리, 계약 조항 DB 등) 정형 조회가 필요해지는 경우가 많아서, 추후 Action Group 확장 포인트가 됩니다.
SA3 — Finance (재무)
-
Action Group: 있음
-
Athena 연동: 있음 (S3 데이터 조회)
-
Redshift 연동: 있음 (Stock Prices)
-
의미:
- “연구 예산/비용/지출(대개 S3 데이터레이크)”은 Athena로,
- “주가/시장 데이터(웨어하우스 성격)”는 Redshift로 분리해서 조회.
2) 데이터 계층: S3–Glue–Athena / Redshift의 의미
Amazon S3 (Structured data)
-
그림 오른쪽의 “Pharmaceutical / Finance” 데이터가 저장되는 데이터 레이크 원천.
-
예시(그림의 키워드 기반):
- Pharmaceutical: Drugs, Drug Trials, Side Effects
- Finance: Research Budget
AWS Glue
-
메타데이터/스키마 계층(카탈로그)로 해석하면 됩니다.
-
S3에 파일이 있어도, Athena가 SQL로 잘 조회하려면:
- 테이블 스키마
- 파티션 정보
- 데이터 포맷(Parquet/JSON/CSV 등)
- 위치(s3://…)
이런 “데이터 사전”이 필요하고, 그 역할을 Glue가 맡습니다.
Amazon Athena (SQL Query Engine)
-
S3 위를 SQL로 조회하는 서버리스 엔진.
-
SA1/SA3의 Action Group이 Athena를 호출해:
- 특정 약물의 기간별 부작용 빈도
- trial cohort 통계
- 연구비 항목별 추이
같은 “근거 숫자”를 뽑아옵니다.
Amazon Redshift (Stock Prices)
-
주가처럼 시계열/집계/조인/동시성 요구가 큰 데이터는
- S3 + Athena로도 가능하지만,
- 성능/동시 질의/복잡한 분석 때문에 웨어하우스(Redshift)로 둔 구성으로 보입니다.
-
SA3가 “재무 분석”에서 Redshift를 같이 쓰는 이유가 여기 있어요.
3) “지식베이스(KB)”와 “Action Group”이 같이 있는 이유
멀티 에이전트에서 보통 답변 근거는 두 갈래입니다.
(1) KB = 비정형 근거 (문서)
- 임상 리포트, 법무 브리프, 특허 원문 같은 것들
- 장점: 설명/맥락/조건/해석에 강함
- 위험: 숫자/집계는 틀리기 쉬움(문서 요약의 한계)
(2) Action Group = 정형 근거 (툴/DB 질의)
- Athena/Redshift로 직접 수치를 뽑음
- 장점: 숫자/통계/필터링이 정확해짐, 재현 가능
- 위험: 권한/쿼리 인젝션/비용 폭주/민감데이터 유출
그래서 SA1·SA3처럼 “문서 + 수치” 둘 다 중요한 도메인은 KB + Action Group을 함께 둡니다.
