TL;DR — 제조 품질 현장에 쌓인 5천 건 이상의 비정형 개선대책서를 OCR·RAG로 지식자산화하고, 신규 품질문제에 대해 스무고개식 멀티턴(HITL 가이드형)으로 품질 대책서 작성을 보조하는 에이전트 케이스다. 핵심은 "AI가 자동으로 써준다"가 아니라 "AI가 방향·점검항목을 제시하고 사람이 완성한다"는 설계 선택이다.
현상·원인 입력 → 점검시트 제안 → 멀티턴 점검 → 사람이 완성 → 재색인
이 한 케이스가 RAG·HITL·Memory·Evaluation을 핵심으로, 21개 에이전틱 디자인 패턴을 동시에 요구한다.
1. 완전 자동 생성을 포기한 이유
제조 품질 관리 도메인의 현장에는 수천 건의 개선대책서가 쌓여 있다. 이번 케이스의 원천에는 과거 수년간 쌓인 비정형 품질 대책서가 스캔 이미지·표·자유서술이 뒤섞인 형태로 누적돼 있었다. 이런 자산을 본 순간 누구나 같은 기대를 품는다. "현상과 원인만 입력하면, 과거 사례를 학습한 AI가 품질 대책서를 알아서 완성해 주지 않을까?" 이 글은 그 기대를 정면으로 반박하는 데서 출발한다. 결론부터 말하면 이 시스템의 정체성은 완전 자동 생성이 아니라, HITL(Human-in-the-Loop) 가이드형 멀티턴이다 — AI는 방향과 점검항목을 제시할 뿐, 실제 점검·판단·완성은 사람이 한다.
자동화를 택하지 않은 이유는 두 가지다. 첫째, 품질 대책서는 책임 문서다. 환각으로 잘못된 원인이 자동 등록되고, 그것이 다시 검색DB에 재색인되면 오염은 자산 전체로 확산된다(설계서가 명시한 환각률 목표는 ≤5%(도입 기대효과·목표치)인데, 자동 생성은 이 한 줄을 구조적으로 위협한다). 둘째, 대책의 근거는 현장에만 있다. 설비 온도·압력·작업 환경 같은 핵심 변수는 과거 문서에 다 적혀 있지 않으며, 그 순간 라인에서 사람이 직접 점검해야만 확인된다. AI가 멋대로 채우는 순간 그것은 근거 없는 창작이 된다. 그래서 설계는 AI의 출력을 항상 '제안'으로 라벨링하고, 정식으로 등록되는 문서는 사람이 검토·수정한 버전뿐이도록 못박았다.
현실에 빗대면 이렇다. 신입이 혼자 보고서를 써내는 구조가 아니다. 옆자리의 베테랑 품질 선배가 점검표를 들고 "이건 확인했나? 설비 온도는? 압력은? 작업 환경은 봤나?"라고 스무고개식으로 코칭하며 함께 완성하는 구조다. 선배(AI)는 무엇을 확인해야 하는지 빠짐없이 짚어 주지만, 실제로 라인에 가서 온도계를 읽고 사진을 찍고 "정상/이상"을 판정하는 것은 어디까지나 작업자(사람)다. 이 케이스에서 멀티턴 루프는 바로 그 코칭 대화이며, 필수 점검항목이 모두 충족될 때까지 추가 질문↔응답(응답+사진+판정)이 반복되고, 충족되기 전에는 초안 생성과 등록이 차단된다. 종료조건은 'AI의 추론이 수렴했다'가 아니라 '사람이 필수 점검을 끝냈다'는 룰 게이트인 것이다.
이 설계 선택에는 정직하게 드러낼 트레이드오프가 있다. 가이드형은 자동화 대비 처리량이 낮고, 사람의 손을 매 턴 거치므로 작성 시간 단축 효과(목표치)도 완전 자동화의 환상보다 보수적이다. 또한 멀티턴을 성립시키려면 '세션ID·대화 컨텍스트의 보존 책임을 프론트엔드와 에이전트 중 누가 지는가'라는 미결 쟁점을 PoC 착수 전에 계약으로 확정해야 한다 — 이를 미루면 멀티턴 자체가 동작 불능이 된다. 그럼에도 이 케이스를 고른 이유는 분명하다. "AI가 다 해준다"는 환상이 가장 깨지기 쉬운 고위험·고책임 도메인에서, AI 실패가 곧 업무 중단이 아니라 '사람 주도로의 안전한 전환'이 되도록 설계하는 법을 보여 주기 때문이다. 다음 절부터 이 한 케이스가 어떻게 21개 디자인 패턴을 동시에 요구하는지 풀어 나간다.
2. 5천 건이 넘는 비정형 문서와 세 가지 일
이 케이스의 출발점은 단순하다. 제조 품질 관리 도메인의 한 발주사(현업)는 지난 수년간 고객사에 제출한 개선대책서를 5천 건 이상 보유하고 있었다. 그런데 정작 이 문서들은 자산 구실을 못 하고 있었다. 품질 대책서는 PDF·PPT·Word 같은 비정형 문서로 개인 드라이브와 공유 폴더에 산재해 있었고, 색인이 없으니 "예전에 비슷한 불량 품질 대책서를 본 것 같은데"라는 담당자의 기억에만 의존해 손으로 뒤져야 했다. 설계서는 이를 "산재·비정형 문서라 검색이 사실상 불가"라고 못 박는다. 잘 작성된 품질 대책서조차 다음 유사 사례로 환류되지 못해 같은 재발 대책이 반복되는 — 전형적인 지식 단절의 구조였다.
시스템이 떠맡는 일은 정확히 세 가지로 갈라진다. 이 분리는 단순한 메뉴 구분이 아니라, 각 일이 서로 다른 트리거·서로 다른 책임자·서로 다른 패턴을 요구하기 때문에 설계상 반드시 떼어내야 하는 경계다. 아래가 설계서 §1-E의 하위기능 3분류를 그대로 가져온 것이다.
| 하위기능 | 트리거 | 핵심 처리 | 성격 |
|---|---|---|---|
| 6-1 수집·자산화 | DB 변경 이벤트 | 품질문제 메타 수집 → OCR 추출 → 검색DB(색인·임베딩) 구축 | 배치(오프라인) |
| 6-2 품질 대책서 추천·생성 | 사용자 요청 | 유사사례 RAG 검색 → HITL 멀티턴 개선 가이드 → 품질 대책서 초안 출력 | 케이스 정체성 |
| 6-3 과거 품질 검색 | 사용자 요청 | 분류체계 필터(년도/품종/업체/문제/원인) + 자연어 RAG → HTML 결과 | 검색(온라인) |
세 일의 관계를 흐름으로 보면 6-1이 흩어진 문서를 검색 가능한 지식으로 갈아 넣고(오프라인), 그 위에서 6-2와 6-3이 사용자 요청마다 동작한다(온라인). 핵심은 6-2가 "완전 자동 생성이 아니다"라는 설계 선언이다. AI는 점검시트와 개선방향을 멀티턴으로 제시할 뿐, 설비온도·압력·작업환경을 실제로 점검하고 최종 판단·작성하는 주체는 사람이다 — 이것이 이 케이스를 단순 RAG 챗봇과 가르는 분기점이다.
"그냥 LLM에 문서를 다 넣고 물어보면 되는 거 아냐? RAG니 멀티턴이니 왜 복잡하게 만들지?"
② Context 한계 — 그 많은 문서 전문을 한 프롬프트에 담을 수 없다. 설계서도 "검색·LLM 컨텍스트 한계"를 명시한다. 그래서 의미적 최유사 사례만 검색해 주입하는 RAG가 필수다.
③ 환각 위험 — 근거 없이 생성된 대책은 고객 제출 문서로는 치명적이다. 사람이 설비온도·압력을 직접 점검·판단하는 HITL 멀티턴이 환각을 막는 안전장치다.
3. 3레이어 아키텍처 — 수집·생성·검색이 맞물리는 법
이 시스템은 하나의 거대한 모놀리식 파이프라인이 아니라, 수집·자산화 / 추론·생성(HITL) / 검색이라는 세 개의 독립 레이어로 분리되어 있다. 분리의 이유는 단순하다. 세 레이어는 가동 주기와 책임 주체가 근본적으로 다르기 때문이다. 수집·자산화는 원천 데이터 시스템(품질문제 마스터 DB)의 변경 트리거에 의해 비동기 배치로 돈다. 추론·생성은 사용자가 화면에서 현상·원인을 입력하는 실시간 멀티턴 세션이다. 검색은 분류체계 필터와 자연어 질의를 받는 저지연 조회다. 이렇게 성격이 다른 작업을 같은 실행 경로에 묶으면, 대량 OCR 배치가 도는 동안 사용자 품질 대책서 생성이 막히는 식의 자원 경합이 발생한다. 레이어 경계가 곧 실패 격리 경계이자 확장 단위인 것이다.
데이터는 한 방향으로만 흐르지 않는다. 핵심은 수집 → 추론 → 검색의 직선 흐름 위에 얹힌 피드백 루프다. 추론·생성 레이어에서 사람이 완성·승인한 품질 대책서(현상-원인-대책)는 그대로 폐기되지 않고, 수집·자산화 레이어의 색인·청킹·임베딩 모듈로 환류되어 재색인된다. 즉 오늘 한 사람이 작성한 품질 대책서가 내일 다른 사람의 검색·추천 근거가 된다. 처음의 정적 지식 베이스가 운영하면서 스스로 자라는 지식 자산으로 바뀌는 지점이며, 이것이 이 아키텍처를 단순 RAG 검색기와 구분 짓는 결정적 설계다. 설계 문서에서도 이 환류는 원천 정의 자료마다 포함 여부가 엇갈려 아직 공식 범위로 확정되지 않았고, "채택 권장 / 발주사(현업) 승인 필요"라는 미결 쟁점으로 정직하게 남아 있다.
레이어 경계를 인터페이스로 끊어 둔 또 다른 실익은 교체 가능성이다. 검색 레이어의 내부 구현(현재는 벡터+키워드 하이브리드)을 향후 그래프 기반 검색이나 외부 자료 결합으로 바꾸더라도, 추론·생성 레이어는 "검색DB에 질의하면 citation 포함 유사사례가 돌아온다"는 계약만 유지되면 영향을 받지 않는다. 반대로 추론·생성 레이어의 멀티턴 흐름을 수정해도 수집 배치는 그대로다. 다만 이 깔끔한 분리에는 정직하게 드러내야 할 트레이드오프가 있다. 첫째, 피드백 루프가 검색DB 품질을 떨어뜨릴 위험이다 — 미완성·저품질 대책서가 그대로 재색인되면 검색 공간이 오염되므로, 등록 전 사람 확인 단계가 환류의 전제 조건이 된다. 둘째, 멀티턴 세션 상태(누적 대화 컨텍스트·세션ID)를 프론트엔드 화면 시스템이 들고 있을지, 에이전트가 들고 있을지의 책임 경계가 아직 확정되지 않았다. 이 경계가 모호하면 레이어 2의 상태가 두 곳에 흩어져 일관성이 깨진다. 레이어로 나눈 덕에 각 레이어는 단순해졌지만, 경계를 가로지르는 상태와 환류 품질이라는 두 난제는 오히려 또렷해진 셈이다.
4. 핵심 패턴 ① RAG 지식자산화 — 비정형 문서를 검색 가능한 지식으로
이 시스템에서 RAG(ch14, Knowledge Retrieval)를 '핵심'으로 분류한 이유는 단순하다. 그동안 쌓인 방대한 분량의 개선대책서가 PDF·이미지 같은 비정형 문서로 개인·공유 드라이브에 산재해 있어, 색인이 없는 탓에 검색이 사실상 숙련 담당자의 기억에 의존한다는 것이 현장의 가장 큰 병목이었기 때문이다. 즉 이 케이스의 정체성은 화려한 자동 생성이 아니라, 흩어진 비정형 경험을 검색 가능한 지식자산으로 전환하는 것 그 자체다. RAG의 오프라인 절반(색인)이 곧 6-1 자산화 파이프라인이고, 온라인 절반(검색→생성)이 6-2·6-3에 1:1로 대응한다.
자산화 파이프라인은 비정형 품질 대책서 → OCR 구조화 → 청킹 → 임베딩 → 벡터+키워드(BM25) 하이브리드 검색DB의 순차 흐름이다. OCR 구조화 단계에서 원문 텍스트를 발생형태·귀책사유·발생장소·중요도·발생년도·대책방안의 6필드로 정리하고, 별도로 원천 데이터 시스템(품질문제 마스터 DB)의 메타데이터는 본문이 아닌 필터링용 메타데이터로 동반 색인한다. 이렇게 본문(의미검색 대상)과 메타(사전필터 대상)를 분리하는 것은, 뒤에서 다룰 분류체계 필터 검색과 자연어 의미검색을 한 인덱스 위에서 동시에 성립시키기 위한 의도적 설계다.
여기서 가장 중요한 설계 결정은 OCR 단계를 '원문 추출'과 '스키마 매핑'의 2단계로 분리한 것이다. 그 근거는 정직하게 말해 OCR 추출 스키마가 아직 미확정이기 때문이다. 원천 요건은 추출 필드를 6가지로 '열거'할 뿐, 각 필드의 필수성·타입·enum은 명시하지 않고 "OCR 추출 구조·범위는 수행 시 추가 검토"라고만 적혀 있다. 만약 추출과 매핑을 한 덩어리로 묶으면, 나중에 스키마가 확정되거나 바뀔 때마다 전체를 다시 OCR해야 한다. 1단계(원문)를 한 번만 확정해 두고 2단계(매핑)만 교체·재실행하도록 갈라 두면, 스키마 후확정의 충격을 매핑 단계 안에 가둘 수 있다 — 이것이 "왜 이렇게 설계했는가"의 핵심 답이다.
마지막으로, 이 파이프라인이 단순 벡터 RAG에 머물지 않는다는 점을 분명히 해야 한다. 상위 요건은 사내 문서만이 아니라 외부 자료 결합과, 부품-공정-품질-품질 대책서를 잇는 관계 모델(온톨로지)·GraphRAG를 명시적으로 요구한다. 요건 문서가 "온톨로지+GraphRAG를 RAG의 차별화 축"으로 규정하는 것이 핵심이다. 본 절의 BM25+벡터 하이브리드는 그 기반일 뿐이며, 의미 기반 추론·연관검색·근거확장은 별도의 GraphRAG 트랙으로 확장되어야 한다. 따라서 색인 파이프라인은 검색 단계를 '교체 가능한 블랙박스'로 추상화해, 추후 그래프 탐색이 붙어도 상류 자산화가 흔들리지 않도록 설계한다.
| 검색 단계 | 메커니즘 | 상태 |
|---|---|---|
| 메타데이터 사전필터 | 분류체계(년도·품종·업체·문제·원인) 키워드 필터로 후보 축소 | 기반(본 절) |
| 벡터 의미검색 | 자연어 질의 → 임베딩 유사도 회수, BM25와 점수 융합 | 기반(본 절) |
| 온톨로지·GraphRAG | 관계 모델 위 그래프 탐색 → 근거 병합 → 응답 검증(차별화 축) | 미반영·별도 트랙 |
| 외부 자료 결합 | 사내 문서 + 외부 자료를 코퍼스에 결합 | 범위 미확정 |
정직하게 남는 미결 쟁점도 명확하다. OCR ≥90% 가정이 깨지면 색인 본문 품질이 검색·생성 전 구간으로 전파되는 garbage-in 상류 병목이 되고, OCR 스키마의 필수성·타입은 합동 인터페이스 정의서에서 확정되어야 하며, 외부 자료의 범위·출처는 발주사(현업) 확인이 필요한 스코프 분쟁 지점이다. 이 설계의 미덕은 그런 불확실성을 숨기지 않고 2단계 분리·블랙박스 추상화라는 구조로 흡수해 둔 데 있다.
5. 핵심 패턴 ② HITL 가이드형 멀티턴 — 스무고개로 품질 대책서를 완성하다
이 시스템의 정체성을 한 문장으로 압축하면 "완전 자동 생성이 아니다"이다. AI는 품질 대책서를 대신 써 주지 않는다. AI는 과거 사례에서 방향과 점검항목을 제시할 뿐이고, 실제 점검을 수행하고 판단하며 최종 문서를 완성하는 주체는 사람(현업)이다. 이것이 Human-in-the-Loop(HITL)가 이 케이스에서 보조 장치가 아니라 설계의 본질인 이유다. 표면적으로는 챗봇처럼 보이지만, 내부 동작은 AI가 한 가지씩 캐물어 가며 사람의 암묵지를 끌어내는 '스무고개식 멀티턴 점검' 구조다.
흐름은 사용자가 현상(필수)과 원인(선택)을 입력하는 데서 시작한다. 여기서 첫 갈림길은 원인란의 유무다. 원인이 비어 있으면 시스템은 현상만으로 과거 사례를 검색(현상 RAG)해 원인 후보와 과거 대책을 함께 제시하고, 원인이 채워져 있으면 현상+원인으로 검색(현상+원인 RAG)해 과거 대책만 제시한다. 이 분기를 코드의 if문이 아니라 분리된 두 개의 검색 도구(현상 RAG / 현상+원인 RAG)로 정의한 이유는, 멀티턴 상태를 무상태(stateless)로 격리해 세션 충돌을 피하고 LLM의 도구 선택 신뢰도를 확보하기 위함이다. 분기 직후 검색된 Top-K 사례는 그 자체로 점검시트와 개선방향 생성의 Groundedness 근거가 된다 — 점검항목을 AI가 지어내는 것이 아니라 회수된 과거 사례에서 길어 올리도록 강제하는 장치다.
진짜 정체성은 그다음에 펼쳐지는 멀티턴 점검 사이클에 있다. LLM이 점검시트를 생성하면, AI는 설비 온도·압력·작업 환경 같은 추가 점검항목을 한 번에 하나씩 질문한다. 사용자는 실제로 현장을 점검한 뒤 응답·사진·판정을 입력한다. 여기서 사진은 AI의 판정 입력이 아니라 사람 판정의 증빙일 뿐이라는 점 — 역할을 혼동하면 설계가 무너진다. 매 턴의 응답은 누적되고, 필수 점검항목이 모두 충족될 때까지 질문↔응답이 반복된다. 충족되면 비로소 현상-원인-대책 구조의 품질 대책서 초안이 합성되고, 사람이 검토·완성·등록한다. 이 반복부는 직선 체인으로는 표현할 수 없기에 LangGraph의 interrupt()/Command(resume)와 Checkpointer로 구현하고, 세션ID를 thread_id로 삼아 멀티턴 상태를 영속화한다.
(추천만, 판정 아님)
응답+사진(증빙)+판정
+ LLM-as-Judge 이원화
사람이 완성·등록
설계에서 가장 정직하게 드러내야 할 쟁점은 종료조건과 무한루프 방지다. 종료는 단일 조건으로 두지 않고 이중화했다. (1)정상완료는 필수 점검항목 전부 충족 + 사용자 확정, (2)폴백완료는 유사 사례가 0건일 때 수동 작성 후 확정, (3)중단은 최대 턴수 도달 또는 사용자 취소다. 핵심은 "충족 = 자동 종료"가 아니라 "충족 = 사람에게 종료 후보 신호 전달"이라는 점이다. 충족 판정을 LLM에만 맡기면 환각으로 인한 조기 종료가 발생하므로, 결정론적 체크리스트 + LLM-as-Judge를 이원화해 게이트를 통과시킨다. 무한루프는 max_iterations(최대 턴수 상한)와 '모름' 응답 시 사람 전문가 에스컬레이션으로 차단한다.
아직 풀리지 않은 가장 큰 리스크는 멀티턴 상태 보존 책임 경계다. 누적된 점검 컨텍스트를 프론트엔드 화면 시스템이 가질지, 에이전트가 가질지가 발주사·개발사 간 R&R상 미명시 상태로 남아 있다. 경계가 모호하면 세션 유실·중복 질문·항목 누락이 발생하고 interrupt/resume 자체가 깨진다. 본 설계는 세션ID 소유권을 에이전트 측(thread_id)에 귀속시키되 인터페이스 정의서에서 선확정할 것을 권고한다. 또 하나의 트레이드오프 — 멀티턴 누적은 컨텍스트 길이를 초과시켜 1회 응답 ≤5초(목표치) NFR과 충돌하므로, 최초 현상/원인 요구사항은 항상 보존하되 중간 점검 응답은 요약 압축한다. 다만 충족 판정의 근거가 되는 점검 이력은 요약이 아닌 구조화 state로 별도 보존해야 충족 판정이 틀어지지 않는다.
6. 핵심 패턴 ③ 메모리 — 멀티턴 세션과 지식이 늙지 않게 하는 피드백 루프
LLM은 본질적으로 무상태(stateless)다. 한 번의 호출이 끝나면 직전 대화도, 어제 등록한 품질 대책서도 기억하지 못한다. 그런데 이 케이스의 정체성인 스무고개식 멀티턴(설비온도·압력·작업환경을 추가 질문하고, 사용자가 응답·사진·판정을 주면 필수 점검항목이 충족될 때까지 반복)은 "기억"을 전제로만 성립한다. 그래서 메모리 패턴(ch8)은 보조가 아니라 핵심으로 분류된다. 설계의 출발점은 메모리를 두 층으로 갈라보는 것이다 — 대화 한 세션을 잇는 단기 메모리와, 세션을 넘어 영속되며 자라는 장기 메모리.
(가) 단기 메모리 — 멀티턴 누적 컨텍스트, 그리고 미결의 책임 경계. 단기 메모리는 세션ID(LangGraph에서는 thread_id)를 키로 한 상태 저장소(Checkpointer/Session State)다. 매 턴마다 "이미 충족된 점검항목"과 "남은 필수항목"을 상태로 들고 다음 질문을 생성하고, 현상·원인·과거대책·판정을 누적해 품질 대책서 초안으로 병합한다. 여기서 설계서가 정직하게 드러내는 최대 미결 쟁점이 등장한다 — 멀티턴 세션 상태를 누가 소유·영속하는가(프론트엔드 화면 시스템 vs 에이전트)가 아직 확정되지 않았다는 점이다. 이는 단순한 구현 디테일이 아니라 시스템 토폴로지를 가르는 일급 결정이다. 만약 프론트가 매 턴 전체 대화 히스토리를 다시 실어 보내는 방식이면 Context 길이초과와 일관성 리스크를 떠안고, 반대로 에이전트측 Checkpointer가 thread_id로 상태를 영속하고 프론트는 세션ID와 이번 입력만 넘기는 방식이면 책임이 명확해진다. 설계서는 후자(에이전트 소유)를 권고하되, 경계가 모호한 채로 분할되면 세션 유실·중복 질문·항목 누락이 발생할 수 있어 PoC에서 반드시 검증해야 할 핵심 리스크로 못박는다.
여기엔 또 하나의 트레이드오프가 숨어 있다. 멀티턴이 길어져 Context 길이 초과가 임박하면, 긴 대화를 통째로 들고 갈 수 없으니 분할요약·병합으로 압축한다. 문제는 NFR이 명시하듯 병합 과정에서 품질 하락이 발생한다는 것이다. 요약은 정보 손실이고, 손실된 정보가 하필 판정 근거였다면 충족도 평가가 오판으로 이어진다. 그래서 설계는 "무엇을 버리고 무엇을 지킬지"를 규칙화한다 — 최초의 현상·원인 요구사항은 항상 원본 보존, 중간 점검응답은 "항목별 통과/미통과" 같은 종료 판정 핵심만 남기고 압축, 원본은 체크포인트에 따로 보관한다. 또한 "필수항목 충족까지 반복"이라는 종료 조건을 LLM의 즉흥 판단이 아니라 checklist_status·pending_required_items라는 명시 상태 키로 결정하게 만들어, 메모리가 단순 저장소를 넘어 제어 흐름의 근거 역할까지 하도록 설계했다.
(나) 장기 메모리 — 검색DB, 그리고 지식이 늙지 않게 하는 선순환. 장기 메모리는 세션을 넘어 영속되는 Store, 즉 검색DB다. 초기 시드는 원천 데이터 시스템(품질문제 마스터 DB)에서 OCR로 구조화한 과거 품질 대책서(발생형태·귀책사유·발생장소·중요도·년도 등)를 청킹·임베딩해 적재한 것이다. 그런데 이렇게 쌓인 자산도 시간이 지나면 낡는다. 이 케이스의 백미는 피드백 루프다 — 멀티턴이 끝나 사람이 완성·승인한 품질 대책서(현상-원인-대책)를 검색DB에 등록→재색인하면, 그 검증된 경험이 다음 신규 건의 RAG 후보로 다시 등장한다. 즉 단기 메모리에서 검증된 결과가 장기 메모리로 승격되는 구조이며, 운영할수록 지식자산이 스스로 신선하게 자라는 데이터 선순환이 만들어진다(PoC 필수요건과 일치). 다만 무비판적 재색인은 위험하다. 미검증·부정확한 완성본이 코퍼스에 누적되면 추적성이 오염되므로, 사람 승인(필수 점검항목 충족) + 품질 게이트(환각 ≤5%·근거 충실도) 통과 건만 색인하는 승격 게이트와, 롤백 가능한 출처·버전 메타가 반드시 따라붙어야 한다.
정리하면, 메모리 패턴은 이 시스템에서 두 가지 정직한 긴장을 끌어안는다. 하나는 아직 풀리지 않은 책임 경계(멀티턴 상태를 프론트엔드 화면 시스템이 들 것인가, 에이전트가 들 것인가)이고, 다른 하나는 압축이 곧 손실인 Context 초과 대응의 품질 하락 트레이드오프다. 그럼에도 단기→장기 승격 피드백 루프는 이 케이스를 "한 번 쓰고 버리는 도구"가 아니라 운영할수록 똑똑해지는 지식 시스템으로 만든다. 단, 메모리는 어디까지나 저장 계층일 뿐이며, 환각 억제·근거 검증은 다음 절의 RAG·가드레일과 결합해야 비로소 완성된다.
7. 핵심 패턴 ④ 평가와 가드레일 — 환각을 잡는 품질 게이트
앞 절들이 무엇을 검색하고(RAG) 누가 최종 책임지는가(HITL)를 다뤘다면, 이 절의 질문은 더 날카롭다. "시스템이 내놓은 한 문장이 진짜 과거 사례에 근거한 것인가, 아니면 그럴듯하게 지어낸 것인가?" 발주사(현업)가 작성하는 것은 제조 품질 관리 도메인의 품질 대책서다. 여기에 근거 없는 원인·대책이 한 줄이라도 섞이면 그것은 곧 잘못된 현장 조치로 이어진다. 그래서 이 케이스에서 ch19 Evaluation은 '핵심', ch18 Guardrails는 '보조'로 분류됐지만, 둘은 사실상 한 몸으로 움직이는 환각 통제 이중 방벽이다. ch19가 품질을 '측정'하고, ch18이 그 측정 결과로 출력을 '차단'한다.
왜 평가가 '핵심'까지 올라갔는가. 이 시스템은 완전 자동 생성기가 아니라 HITL 가이드형 멀티턴이다. 사람이 최종 판단을 한다는 것은, 사람에게 건네는 점검질문·대책 초안 하나하나에 신뢰 점수가 붙어야 한다는 뜻이다. 근거가 약한 문장을 사람이 무비판으로 채택하면 환각은 그대로 품질 대책서에 박제되고, 그 품질 대책서가 다시 검색DB로 재색인되면(데이터 선순환) 오염이 코퍼스에 누적·증폭된다. 측정 없는 선순환은 오염의 가속기다. 따라서 평가는 '있으면 좋은' 기능이 아니라 선순환 구조가 성립하기 위한 전제 조건이다.
환각 통제의 1차 메커니즘은 단순하지만 강력하다 — 근거 강제(Citation)다. 생성된 개선가이드의 각 항목에는 그 문장이 인용한 과거 품질 대책서의 식별자(관리번호·발생년도)가 첨부된다. 인용이 붙지 않은 문장은 그냥 통과시키지 않고 소프트 차단(회색 표시)으로 사람 검토를 유도한다. 이때 ch18 출력 가드레일은 생성 문장과 회수된 근거 청크를 Citation 매핑 검증으로 대조하고, 32개 메타 컬럼(중요도 S/A/B/C 등)과 모순되는 분류값은 마스터 DB 허용값만 통과시켜 환각을 입구에서 거른다. 입력 측에서는 OCR 구조화 직후·임베딩 직전에 PII 마스킹 + 도메인 스키마 검증 + OCR 신뢰도 임계를 배치한다 — 이 입력 게이트가 이 케이스에서 가드레일이 가장 단단하게 기여하는 지점이다.
평가는 한 층이 아니라 3수준으로 짠다. 왜 굳이 3층인가? 멀티턴 가이드는 '한 문장이 맞느냐'와 '한 세션이 제대로 수렴했느냐'가 전혀 다른 품질 축이기 때문이다. Response 수준은 점검질문·대책 초안 각각의 Groundedness·환각률·인용근거를 채점하고, Trajectory 수준은 원인란 유무에 따른 분기(현상RAG vs 현상+원인RAG)가 의도한 검색 경로를 탔는지를 검증한다. Session 수준은 스무고개식 멀티턴이 필수 점검항목 충족까지 완성 품질 대책서로 수렴했는지를 본다. 그리고 핵심은, 이 세 축을 표준 평가지표와 NFR에 1:1로 결선한다는 점이다.
| 평가 수준 | 대상 기능 | 표준 지표(인수 기준) | Gate 판정 |
|---|---|---|---|
| Response — 근거성/환각 | 대책 초안·점검질문 생성 | Groundedness · Citation coverage · Hallucination rate · RAGAS | 인용 없는 문장 소프트 차단 → 사람 검토 |
| Trajectory — 경로 | 원인란 유무 분기·검색 경로 | 분기 경로 정합(expected_path 일치율) | 정합 < 0.8 → REVIEW 회귀 |
| Session — 수렴 | 멀티턴 전체 대화 | 필수항목 충족률 · 평균 턴 수 · 인간 채택률 | 미수렴 → HITL 추가질문 경로 유지 |
| 검색(6-3) | 과거 품질 문제 검색 | Precision@5 · Recall@K · MRR | Top-5 적중률 < 80% → 자동제시 대신 HITL fallback |
이 매트릭스의 설계 의도는 "평가지표 = 인수 기준 = 모니터링 알림"을 한 줄에 묶는 것이다. RAG 평가의 표준 지표(Precision@K·Recall@K·MRR·RAGAS·Groundedness·Citation coverage·Hallucination rate·Gate)를 추상적 KPI로 두지 않고, 검색 지표는 6-3에, 근거성 지표는 6-2 Response에, 경로 지표는 Trajectory에 못 박는다. 그래야 점수 하락이 발생했을 때 "모델 문제인지 데이터 문제인지"를 축별로 분리 진단할 수 있다. 특히 원천 품질 대책서 간 불일치(추적성 리스크)는 Groundedness·Citation coverage를 구조적으로 끌어내리므로, 점수가 낮다고 무조건 모델을 의심하면 오진한다.
| NFR 항목 | 도입 기대효과(목표치) | 결선 게이트 |
|---|---|---|
| 환각 통제율 | ≤ 5% (가정·목표치) | Response 게이트 FAIL 임계 |
| RAG 검색 적중률(Top-5) | ≥ 80% (가정·목표치) | 미달 시 HITL fallback |
| OCR 추출 정확도 | ≥ 90% (가정·목표치) | 미달 건 수동 검토 큐 격리 |
| 멀티턴 1회 응답시간 | ≤ 5초 (가정·목표치) | P95 대시보드 알림 |
| 서비스 가용성 | ≥ 99.5% (가정·목표치) | 슬라이딩 윈도우 모니터링 |
정직하게 드러내야 할 미결 쟁점이 셋 있다. 첫째, 이 NFR 목표치는 전부 가정값이다(환각≤5%·Top-5≥80%·OCR≥90%·가용성≥99.5%, 작성시간 단축≥30%·재사용률≥50%도 동일). 측정의 분모·판정자·표본을 합의하지 않으면 Gate는 자의적 숫자놀음이 된다. 둘째, Golden 평가셋의 부재가 최대 병목이다 — Precision@K·MRR을 재려면 정답 라벨이 선행돼야 하는데, OCR 스키마가 아직 미확정이라 평가셋과 스키마 확정 일정이 서로 묶여 있다. 셋째, 채점자(LLM-as-a-Judge) 자신도 환각한다. 그래서 Goals-Met을 규칙 기반 결정적 체크리스트와 LLM 판정으로 이원화하고, OCR 신뢰도·검색 관련도 같은 외부 정량 신호를 우선 근거로 삼으며, 사람 평가와의 상관을 주기적으로 검증해야 한다. 평가 시스템조차도 결국 사람이 한 번 더 검증하는 — 이 케이스 전체를 관통하는 'Human as the last gate' 원칙의 마지막 적용점이다.
8. 나머지 17개 패턴은 어디에 맞물리나
앞 절들에서 이 케이스의 정체성을 이루는 네 패턴 — RAG(지식 회수)·HITL(가이드형 멀티턴)·Memory(멀티턴 컨텍스트)·Evaluation(품질 평가) — 을 다뤘다. 그렇다면 나머지 17패턴은 단순한 들러리일까. 그렇지 않다. 21패턴을 한 실무 케이스에 적대적으로 매핑한 결과 분포는 핵심 4 · 보조 13 · 약함 4로 나왔다. 여기서 가장 중요한 분석적 결정은 "작동하는 것"과 "정체성인 것"을 분리한 점이다. 라우팅·도구사용·예외처리는 분명히 시스템 안에서 돈다. 그러나 이를 전부 '핵심'으로 올리면 케이스의 무게중심이 흐려지고, 패턴 교과서를 억지로 덧씌운 과대평가가 된다.
보조(13개)는 "분명히 작동하나 빼도 본질이 무너지지 않는" 패턴이다. 예컨대 라우팅은 품질 대책서 멀티턴의 '원인란 유무 분기'(있으면 현상+원인 RAG, 없으면 현상 RAG)로 정확히 닿고, 예외처리는 대량 OCR 배치의 부분 실패 복구와 멀티턴 무한루프 방지를 떠받치는 횡단 인프라다. 병렬화는 임베딩 배치의 Fan-Out, 도구사용은 두 RAG 검색 함수를 잇는 배관, 학습은 완성본 재색인이라는 피드백 환류로 작동한다. 다만 이들은 모두 정체성 위에 얹힌 메커니즘이라는 점이 등급의 근거다.
약함(4개)은 더 정직하게 선을 그었다. MCP·A2A는 다중에이전트 PoC 시연을 구성할 때 권장되지만, 없어도 케이스가 성립하는 통합·시연 선택지다. 우선순위·탐색은 점검질문 순서·항목 선택을 MCDM·MAB로 모델링할 수 있으나, 실제 의사결정 주체가 현업 사람(HITL)이고 대응되는 실체(작업 대기열·SLA 위반시계)가 없어 설계제안 수준에 머문다. 여기서 미결 쟁점이 하나 드러난다 — 우선순위 패턴의 6-3 결과 랭킹은 본질상 RAG 리랭킹(ch14)의 책임이라 개념 중복 소지가 있다. 이를 'RAG 리랭킹의 한 구성요소'로 한정 표기해 혼선을 피했다.
| Ch | 패턴 | 강도 | 케이스 적용 한 줄 |
|---|---|---|---|
| 1 | Prompt Chaining | 🟦 보조 | 수집·자산화 배치(트리거→OCR→구조화→청킹→임베딩)가 전형적 순차 체인 |
| 2 | Routing | 🟦 보조 | 멀티턴의 '원인란 유무 분기' = 규칙 기반 Condition Function |
| 3 | Parallelization | 🟦 보조 | OCR·임베딩 배치의 Fan-Out(gather+Semaphore)로 적재 가속 |
| 4 | Reflection | 🟦 보조 | 초안의 논리정합·Groundedness를 Critic이 검증하는 품질 게이트 |
| 5 | Tool Use | 🟦 보조 | 두 RAG 검색(현상/현상+원인)을 도구로 정의한 검색 배관 |
| 6 | Planning | 🟦 보조 | 단계 분해·완료기준만 빌려주는 렌즈(루프 본체는 ch4·ch13) |
| 7 | Multi-Agent | 🟦 보조 | 정체성을 '담는 그릇'(토폴로지)이지 정체성 그 자체가 아님 |
| 9 | Learning & Adaptation | 🟦 보조 | 완성본 재색인 = 검색 코퍼스 학습(모델 파라미터 변경 아님) |
| 11 | Goal Setting | 🟦 보조 | '필수 점검항목 충족'을 측정 가능한 종료조건으로 명시화 |
| 12 | Exception Handling | 🟦 보조 | OCR 배치 부분실패 복구·멀티턴 무한루프 방지 횡단 인프라 |
| 16 | Resource-Aware Opt. | 🟦 보조 | 원인란 분기를 '쿼리 복잡도 라우터'로 → 경로별 모델 차등 |
| 17 | Reasoning | 🟦 보조 | 스무고개 멀티턴이 'ReAct 변형'(단, 도구 자율실행은 빠짐) |
| 18 | Guardrails | 🟦 보조 | Groundedness/Citation·PII 검증 등 출력 안전 게이트 |
| Ch | 패턴 | 강도 | 케이스 적용 한 줄 |
|---|---|---|---|
| 10 | MCP | ⬜ 약함 | 과거 품질 검색을 MCP Tool로 노출하는 설계 제안(없어도 성립) |
| 15 | A2A Protocol | ⬜ 약함 | 3개 에이전트 분리·통신은 다중에이전트 시연용 권장 선택지 |
| 20 | Prioritization | ⬜ 약함 | 점검질문 순서화·검색 리랭킹(본질은 ch14 RAG 리랭킹) |
| 21 | Exploration | ⬜ 약함 | 다음 점검항목 선택을 MAB 탐색-활용으로 모델링(설계 수준) |
결국 이 매트릭스가 던지는 교훈은 명확하다. 실무 요건 하나는 결코 한 패턴으로 끝나지 않는다. '과거 품질 대책서로 신규 품질 대책서 작성을 보조한다'는 한 문장이 21패턴 중 17개를 동시에 호출한다. 그러나 모든 호출이 동등하지는 않다. 진짜 어려운 일은 패턴을 찾는 것이 아니라, 작동하는 것과 정체성인 것을 분리해 과대·과소평가를 둘 다 피하는 것이다. 남은 미결 쟁점 — 멀티턴 세션경계(프론트 vs 에이전트)의 책임 위치 — 가 결정돼야 우선순위 상태 보존·동적 재우선순위화가 일관되게 작동한다는 점은, 약함 패턴조차 정직하게 한계를 드러내야 함을 보여준다.
9. 통합 아키텍처 — 어느 레이어에서 어느 패턴이 작동하나
21개 패턴을 한 줄로 나열하면 "다 들어갔다"는 인상만 남는다. 그러나 설계의 진짜 질문은 "어느 레이어가 시스템의 정체성을 규정하고, 어느 패턴이 그 위에 얹히는 보조·운영 계층인가"이다. 이 케이스의 골격은 세 개의 기능 레이어가 하나의 횡단 요소 레이어 위에 떠 있는 구조다. ① 수집·자산화 레이어(오프라인 배치)는 과거 비정형 품질 대책서를 OCR로 6필드(발생형태·귀책사유·발생장소·중요도·발생년도·대책방안) 구조화해 벡터+키워드 검색DB를 짓는 결정론적 ETL이다. ② 추론·생성(HITL) 레이어(온라인 멀티턴)는 현상·원인 입력에서 출발해 점검시트를 추천하고 스무고개식으로 사람의 점검 수행을 끌어내 품질 대책서 초안에 도달하는 — 케이스의 정체성이 응축된 — 의사결정 증강 구간이다. ③ 검색 레이어(단발성 조회)는 분류체계 필터와 자연어를 결합한 읽기전용 하이브리드 검색이다.
왜 이렇게 레이어를 갈랐는가. 동일한 RAG라도 레이어마다 작동 양태가 전혀 다르기 때문이다. 수집·자산화에서 RAG는 '색인 절반'(구조화→청킹→임베딩→DB)으로만 나타나고, 추론·생성에서는 '검색→생성 절반'(원인란 분기=쿼리 구성 분기, 회수 Top-K=생성의 Groundedness 근거)으로, 검색 레이어에서는 메타 사전필터+벡터의 Hybrid Search 교과서 사례로 갈라진다. 한 패턴이 전 레이어를 관통하되 역할이 갈리는 이 비대칭이야말로 "패턴=레이어"라는 순진한 1:1 매핑을 거부해야 하는 이유다. 같은 논리로 Memory는 RAG를 '시간축'으로 재해석한 거울상이다 — 멀티턴 누적 컨텍스트가 단기 메모리(세션ID/Checkpointer), 지식 자산이 장기 메모리(Store), 완성본 재색인이 단기→장기 전이다. 그래서 핵심 미결인 '세션 보존 책임경계(프론트 vs 에이전트)'는 본질적으로 이 단기 메모리를 누가 소유하느냐의 문제로 환원된다.
| 레이어 | 작동 패턴 | 역할 |
|---|---|---|
| 수집·자산화 (오프라인 배치) | 핵심 RAG(색인 절반)·Memory(시드)·Evaluation(OCR≥90%) 보조 Prompt Chaining·Parallelization·Reflection·Exception·Guardrails(입력 가드 가장 단단)·Goal | 비정형 품질 대책서를 6필드로 구조화·임베딩해 검색DB를 짓는 RAG의 색인 절반. 장기 메모리의 초기 시드를 채우는 결정론적 ETL. |
| 추론·생성(HITL) (온라인 멀티턴) ★정체성 | 핵심 HITL·RAG(생성 절반)·Memory(단기/장기)·Evaluation(3수준) 보조 Routing·Reflection·Learning·Goal·Tool Use·Planning·Resource·Reasoning·Exception·Guardrails 약함 Prioritization·Exploration | 원인란 분기→현상(+원인)RAG→점검시트 추천→스무고개 멀티턴(추가질문↕사람 응답·사진·판정)→충족 시 초안 생성→등록→재색인. 의사결정 증강형 HITL. |
| 검색 (단발성 조회) | 핵심 RAG(Hybrid)·Memory(Store 읽기)·Evaluation(Top-5≥80%) 보조 Prompt Chaining·Routing·Parallelization·Tool Use·HITL(약한 증강)·Guardrails(권한가드) 약함 Prioritization(MCDM)·MCP·Reasoning | 분류체계 5필터+자연어→벡터+키워드 하이브리드→관련도 정렬·요약. 세션상태를 거의 쓰지 않는 읽기전용 조회. |
| 횡단 요소 (전 구간 운영·통신) | 핵심 Evaluation(측정 백본) 보조 Multi-Agent(그릇)·Exception·Resource·Guardrails(Defense-in-Depth)·Learning(선순환) 약함 A2A·MCP·Prioritization(P0~P3) | 세 기능을 담는 에이전트 토폴로지, 인터페이스 3종의 통신 계약, NFR·평가·예산·안전을 떠받치는 비기능 백본. |
표를 관통하는 설계 논증은 세 가지다. 첫째, 정체성을 규정하는 핵심은 단 4개다 — RAG·HITL·Memory·Evaluation. 나머지 17개를 핵심으로 격상하면 "전부 중요하다=아무것도 중요하지 않다"가 되어 PoC 우선순위가 무너진다. 둘째, 보조 패턴은 핵심에 종속된다. Routing(원인란 분기·충족 여부 분기)·Reflection(OCR·초안 자기검증)·Tool Use(검색·재색인·생성의 도구화)는 분명히 작동하지만, 멀티턴의 주도권은 어디까지나 HITL·Memory·Reflection이 쥐고 있어 Planning·Reasoning·Resource는 동일한 멀티턴을 각기 단계분해·추론기법·복잡도 라우팅의 렌즈로 '재서술'할 뿐 새 정체성을 만들지 않는다. 셋째, 약함 등급은 정직하게 약하게 둔다. MCP·A2A는 단일조직 내부 PoC라 본래 가치(표준 어댑터·프레임워크 무관 원격협업)가 약하게만 닿고, Prioritization·Exploration은 검색 리랭킹 공식과 점검질문 MAB의 약한 확장에 머문다.
횡단 요소 레이어를 별도로 둔 이유도 같은 맥락이다. Multi-Agent는 세 기능을 '담는 그릇'으로서 추론·생성 구간을 서브그래프로 캡슐화하고 재색인만 색인 경계로 핸드오프하는 토폴로지를 결정할 뿐, 시스템 정체성을 정의하지는 않는다(다중에이전트 PoC 요건을 충족하는 그릇). Exception Handling과 Resource Optimization은 가용성 ≥99.5%(도입 기대효과·목표치)를 떠받치는 비기능 백본이고, Guardrails는 입력(자산화: PII·스키마 검증이 가장 단단)→생성(근거성·환각 차단)→출력(권한 가드)의 Defense-in-Depth로 얹힌다. 그 정점에 Evaluation이 — 기능 레이어 내부가 아니라 전 구간을 가로지르는 측정 백본으로 — 자리한다. 다만 이 우아한 분리가 무비용은 아니다. 핵심 미결은 두 가지로 정직하게 남는다 — (1) 단기 메모리(세션) 소유권이 프론트엔드 화면 시스템에 있는지 에이전트에 있는지가 미확정이고, (2) 32컬럼 스키마가 잠정이라 Goal Setting의 종료조건과 Guardrails의 허용 도메인 검증이 아직 확정값에 묶이지 못했다. 통합 아키텍처는 '완성된 청사진'이 아니라, 이 두 결정이 내려질 때 비로소 핵심 4개 골격이 NFR 게이트까지 닫히는 조건부 설계다.
10. 설계가 자주 어긋나는 세 지점
분석 보고서와 설계서를 교차 검토하면서 가장 많은 시간을 잡아먹은 것은 코드가 아니라 전제(前提)에 대한 합의 부재였다. 이 시스템은 비정형 개선대책서를 RAG로 지식자산화하고, 신규 품질문제에 대해 HITL 가이드형 멀티턴으로 품질 대책서 작성을 보조하는 구조다. 그런데 "AI가 품질 대책서를 만들어 준다"는 한 문장을 어떻게 읽느냐에 따라 화면 범위·책임 경계·검색 아키텍처가 통째로 달라진다. 아래 세 가지는 모두 실측 버그가 아니라 설계 단계의 해석 차이가 계약 분쟁으로 번지는 지점이라는 공통점을 가진다.
첫 번째는 완전 자동 생성 환상이다. 발주사(현업)의 원천 의견은 명확하다 — "AI가 처음부터 끝까지 대신 작성하지 않는다." AI는 스무고개식 점검시트와 개선방향을 멀티턴으로 제시할 뿐, 설비온도·압력·작업환경 같은 현장 변수의 실제 점검과 최종 판단·작성은 사람이 한다. 이것을 "자동 작성기"로 오해하면 챗봇 UI가 아니라 단발성 생성 버튼을 만들게 되고, RAG 적중률이 목표(Top-5 ≥80%, 환각 ≤5% — 도입 기대효과/목표치)에 못 미칠 때 폴백할 HITL 추가질문 경로가 설계에서 통째로 빠진다. 왜 가이드형이어야 하는가? 비정형 품질 대책서의 원인 추론은 본질적으로 불확실하기 때문에, 신뢰도 미달 시 자동 제시 대신 사람에게 회귀하는 경로가 환각을 막는 마지막 안전판이 된다.
두 번째는 멀티턴 상태 보존의 책임 경계 공백이다. 스무고개 대화는 여러 턴에 걸쳐 누적되는 stateful 흐름인데, 설계서 R&R 표를 보면 "세션ID는 프론트엔드 화면, 대화 컨텍스트는 에이전트가 보유"라는 구분이 (가정)으로만 적혀 있고 확정되지 않았다(미결 과제). 누가 멀티턴 상태를 보존하느냐가 미정이면, 컨텍스트 길이 초과 시 분할요약·병합을 누가 책임지는지(에이전트)도, 자기수정 히스토리를 어디 저장하는지도 전부 공중에 뜬다. 그래서 이 케이스의 병렬 검색은 의도적으로 무상태(stateless)로 격리 설계해 세션 충돌을 회피했다 — 책임 경계가 정해지기 전까지 상태를 함부로 만들지 않는 것이 정직한 설계다.
세 번째는 단순 벡터 RAG로 끝내는 것이다. 임베딩 유사도 Top-K 검색만으로 "검색 끝"을 선언하면 손쉽지만, 상위 고도화 요건은 GraphRAG와 온톨로지 기반 관계 탐색, 그리고 "외부 자료 결합"을 명시한다(미결 과제). 그런데 발주사의 상위 정의에는 외부자료 결합이 명시된 반면 하위 기능 정의에는 누락되어 있어, 그대로 두면 범위 축소 또는 범위 분쟁으로 번진다. 설계서가 검색 단계를 "교체 가능한 블랙박스"로 추상화한 이유가 여기 있다 — 지금은 벡터+키워드 하이브리드로 구현하되, 온톨로지 관계 탐색 경로를 나중에 끼워 넣을 수 있게 인터페이스를 열어 둔 것이다. 다만 외부자료의 정의·수집 범위는 발주사 확인 전까지 미결임을 정직하게 표기해야 한다.
여기에 두 개의 작은 지뢰가 더 있다. OCR 스키마 후확정 — 추출 필드(발생형태/귀책사유/발생장소/중요도/발생년도/대책방안)의 필수성·타입·enum은 원천이 "수행 시 추가 검토"라고만 적어 전부 (가정)이며, 확정은 개발사와의 합동 인터페이스 정의서에서 한다(필수/권장 단정 금지). 그리고 Context 길이 초과 시 병합 품질하락 — 방대한 컨텍스트 한계로 분할요약·병합이 불가피한데, 병합 시 품질이 떨어질 수 있고 허용 임계 기준이 아직 미정이다(대표 샘플 20건 청킹 POC 후 협의 권고). 세 지점과 두 지뢰의 공통 교훈은 하나다 — "확정되지 않은 것을 확정처럼 설계하지 않는다."
11. 재사용 가능한 설계 교훈 5선
하나의 실무 요건(과거 품질 대책서 자산화 + 가이드형 품질 대책서 추천 + 과거 사례 검색)을 21개 에이전틱 패턴으로 분해하면서 얻은 가장 값진 산출물은, 특정 케이스를 넘어 다른 비정형 문서·전문가 판단 도메인에도 그대로 이식되는 일반 원리다. 아래 다섯 교훈은 보고서 §6의 열 개 교훈을 다섯 축으로 압축한 것으로, 각각 "왜 이 설계여야 하는가"의 논증과 함께 묶이는 패턴을 명시한다. 공통된 메타 교훈을 먼저 말하면 — 패턴은 정체성(identity)과 토폴로지(topology)를 구분해서 붙여야 한다. 다중에이전트로 그릴지 단일 노드로 그릴지는 구현 선택이고, 이 케이스의 정체성은 어디까지나 RAG·HITL·멀티턴 메모리이기 때문이다.
교훈을 다섯 개로 묶을 때 의도적으로 드러낸 트레이드오프가 있다. (a) 결정론적 라우팅으로 단순화하면 비용·환각은 줄지만 '단계추론 데모'라는 시연용 화려함은 포기해야 하고, (b) 자동화를 멈추는 HITL은 안전하지만 작성 시간 단축(목표치)과 정면으로 긴장하며, (c) 피드백 루프는 자산을 키우지만 검증 게이트 없이는 품질을 오염시킨다. 좋은 설계는 이 긴장을 숨기지 않고 경계와 권한을 컴포넌트에 명확히 배치해 해소한다.
비정형 문서를 자산화할 때 추출 스키마(발생형태·귀책사유·발생장소·중요도 등)는 프로젝트 초기에 확정되기 어렵다. 스키마가 흔들리면 청킹·임베딩·색인 전체가 재작업으로 번진다. 따라서 원문 OCR 추출 단계를 독립 컴포넌트(서브그래프)로 격리하고, 스키마 매핑·검증은 그 뒤 별도 단계로 미뤄 변경 영향 반경을 한 단계로 가둔다. 미확정 스키마는 잠정 기준으로 두되, 재색인되는 완성본의 실제 필드 분포를 누적 관찰해 파서·청킹을 후속 보정하는 약한 학습 고리를 둔다.
스무고개식 멀티턴은 무상태 LLM 위에 단기 메모리를 얹어야 성립한다. '세션ID·대화 컨텍스트 보존 책임이 프론트엔드 화면 시스템에 있느냐 에이전트에 있느냐'는 조직 간 R&R 협상이 아니라, 단기 메모리(Checkpointer/Session State)를 어느 컴포넌트가 소유·영속하느냐는 기술 계약 문제다. 권장 설계: thread_id 단위로 '충족된 점검항목·남은 필수항목·누적 판정'을 에이전트 측 상태 저장소에 귀속시키고, 프론트는 세션ID 발급·전달만 책임진다. 이 결정을 미루면 추천 흐름 전체가 동작 불능이 되므로 PoC 착수 전 1순위로 확정한다.
완성본 등록 → 검색DB 재색인은 단순 부가기능이 아니라 데이터 선순환의 심장이다. 컴포넌트 관점에서 이는 대화별 단기 메모리(세션 state)에서 사람이 검증·완성한 (현상-원인-대책)이 조직 공유 장기 메모리(벡터+키워드 Store)로 '승격'되는 단기→장기 전이다. 이 승격을 register_draft / reindex 도구로 명세화하면 에이전트가 표준 호출로 선순환을 트리거할 수 있고, 초기 자산은 운영 중 점진 확장된다. 단, 검증 통과 완성본만 색인하는 게이트를 반드시 끼워야 저품질 대책서가 다음 추천의 근거를 오염시키는 품질 회귀를 막는다.
'잘 검색되는가·환각이 없는가'를 막연한 인상이 아니라 업계 표준 지표로 못박아야 PoC가 합·불을 다툴 수 있다. 검색 품질은 Golden 셋 기반 Precision@5 · Recall@K · MRR로, 생성 품질은 RAGAS · Groundedness · Citation coverage · Hallucination rate로 측정한다. 더 나아가 평가를 Response(각 초안의 근거성)·Trajectory(원인란 유무 분기가 의도대로 호출됐는가)·Session(필수 점검항목 충족까지 멀티턴이 완성본으로 수렴했는가) 3수준으로 설계하면, 재색인 전후 품질 비교와 분포 드리프트(PSI) 감지로 '데이터 선순환' 자체를 검증할 수 있다.
멀티턴 종료조건('필수 점검항목 충족')은 '추론 수렴'이 아니라 룰 기반 게이트다. 핵심은 계측(목표충족도)·자기수정(반성)·종료권한(사람)을 서로 다른 컴포넌트에 분리 배치하는 것이다. AI는 다음 점검질문을 생성(Thought)하지만 실제 점검·판정(Action)은 현업 작업자가 하고, 그 응답+사진+판정이 Observation으로 돌아온다. 이렇게 종료 권한을 사람에게 귀속시키면 AI 실패가 곧 작업 중단이 아니라 '사람 주도로 전환'되는 안전한 저하(graceful degradation) 경로가 된다. 비정형 문서와 전문가 판단이 섞인 도메인에서는 "AI가 자동으로 써준다"가 아니라 "AI가 방향·점검항목을 제시하고 사람이 완성한다"가 정석 아키텍처다.
남는 미결 쟁점도 정직하게 적는다. 이 다섯 교훈은 원천 설계서(익명화본)와 패턴 정의에 근거한 설계 제안 수준이며, 실제 GraphRAG 적용 여부나 발주사의 As-Is 수치는 미확인이다. 특히 교훈 4의 평가 백본은 Golden 셋 구축이라는 선행 비용을 전제하고, 교훈 5의 HITL은 자동화 기대효과(목표치)와 끊임없이 균형을 잡아야 한다. 그럼에도 다섯 교훈이 가리키는 방향은 일관된다 — 경계를 명확히 긋고, 권한을 사람에게 남기며, 모든 것을 표준 지표로 계측하라.
12. 엔터프라이즈 도입 기대효과와 적용 체크리스트
지금까지 RAG 지식자산화, HITL 가이드형 멀티턴, 단기·장기 메모리, 3수준 평가가 하나의 실무 요건 위에서 어떻게 맞물리는지를 짚었다. 마지막으로 "그래서 도입하면 무엇이 좋아지는가"를 정직하게 다룬다. 결론부터 말하면, 본 케이스의 모든 효과 수치는 설계 문서가 협의 대상으로 제시한 목표치(가정)이며 특정 기업의 실측 결과가 아니다. 더 중요한 사실은 As-Is 베이스라인 자체가 미확보라는 점이다. 설계서 §4.6과 Open Issues는 "리드타임·반송률·재발률의 현행 수치가 없다"고 명시하며, "최근 6개월 처리 이력으로 베이스라인을 먼저 측정한 뒤 목표값을 협의"하도록 못박았다. 즉 아래 표의 30%·80%·50%는 달성치가 아니라 파일럿 전후 측정으로 검증해야 할 가설이다.
왜 이 점을 그렇게 강조하는가. 이 케이스의 본질이 비정형 문서 + 전문가 판단이 섞인 도메인이기 때문이다. As-Is가 "산재 문서를 숙련자가 기억으로 수기 탐색"이라 검색 적중률의 베이스라인이 사실상 0%에 가깝고, 작성 리드타임도 작성자별 편차가 커 단일 기준값이 없다. 베이스라인이 없는데 효과를 단정하면 그것은 분석이 아니라 마케팅이다. 그래서 엔터프라이즈 도입의 첫 단계는 기능 구현이 아니라 측정 가능한 비교 프레임을 세우는 일 — 파일럿 코호트를 정하고, 동일 품질문제 집합에 대해 As-Is(수기) vs To-Be(AI 가이드) 처리시간·반송률·적중률을 나란히 재는 설계가 선행되어야 한다.
| 기대효과 지표 | 정의 | 목표치(가정) | 측정 방법·전제 |
|---|---|---|---|
| 품질 대책서 작성 소요시간 단축률 | (Before − After) / Before | ≥ 30% 단축 | 현업 파일럿 전·후 측정. Before 기준값 미확보 → 선측정 필요 |
| 유사사례 검색 적중률 | Top-5 결과 내 적합 사례 포함 비율 | ≥ 80% | 파일럿 사용자 평가 + Precision@K·Recall@K·MRR 정량지표 병행 |
| 품질 대책서 재사용률 | 시스템 추천 기반 품질 대책서 활용 비율 | ≥ 50% | 프론트엔드 화면 시스템 로그. 피드백 루프 채택 시 측정 가능 |
| 지식 누적 속도 | 월 신규 완성 품질 대책서 재색인 건수 | 기준값 협의 | 검색DB 증분 로그. 피드백 루프 운영 전제(승인 완성본만 색인) |
| 내부 반송률 감소 | 반송(재작업) 건수 / 전체 제출 건수 | 50% 감소 | 양식 표준화·점검항목 가이드 효과. As-Is 반송률 미확보 |
| 신입 담당자 자립 기간 | 독립 작성 첫 승인까지 기간 | 30% 단축 | AI 가이드가 숙련자 경험 대리. 장기 관찰 필요 |
이 표에서 가장 설계적으로 흥미로운 칸은 지식 누적 속도다. 다른 지표가 "사람이 더 빨라졌나"를 보는 데 반해, 이 지표는 "시스템이 스스로 자라고 있나"를 본다. 완성 품질 대책서를 재색인하는 피드백 루프가 실제로 코퍼스를 키우면, 검색 적중률은 운영을 지속할수록 우상향해야 한다. 다만 여기에는 맹점이 있다 — 검증 통과 완성본만 색인하는 게이트가 없으면 저품질 대책서가 다음 추천의 근거를 오염시켜 적중률이 오히려 점진 회귀한다. 그래서 "재색인 전후 적중률·분포 드리프트(PSI) 비교"가 단순 KPI가 아니라 데이터 선순환이 진짜 품질을 올렸는지를 가르는 핵심 검수 항목이 된다.
기능을 만들기 전에 합의해야 할 것들이 있다. 설계서 Open Issues가 한결같이 가리키는 교훈은 "AI 모델보다 조직의 표준·계약·범위가 먼저 막혀 있으면 PoC가 동작 불능에 빠진다"는 것이다. 아래는 그 미결 안건을 도입 전 점검 체크리스트로 정리한 것이다. 특히 1·2번은 미결 시 멀티턴 자체가 끊기거나 RAG 근거 품질이 무너지는 최우선(P0) 항목이다.
| 우선순위 | 점검 항목 | 미결 시 리스크 / 합의 주체 |
|---|---|---|
| P0 | 멀티턴 세션ID·컨텍스트 보존 책임(에이전트 vs 프론트) 인터페이스 정의서 확정 | 단기 메모리 소유권 미정 시 스무고개 루프 동작 불능. 개발사 합동 확정 |
| P0 | OCR 추출 스키마(6필드) 합동 확정 | 스키마 변경이 청킹·임베딩·색인 전면 재작업으로 전파. 발주사·개발사 합의 |
| P1 | 분류체계(년도/품종/업체/문제/원인)·표지 양식 표준 확보 | 화면·검색·필터 설계의 선행 입력. 발주사(현업) 책임 산출물 |
| P1 | 평가 Gate 기준 합의(Precision@K·MRR·Groundedness·Citation·환각률) | 인수검수 Gate 불명확 시 합격 기준 부재. NFR을 표준 지표 용어로 정렬 |
| P2 | 외부자료·GraphRAG/온톨로지 결합 범위 확정 | 하이브리드 RAG만으로는 관계추론 요건 미충족 위험. 데모 범위 명시 |
| P2 | Context 분할요약·병합 품질 임계값 + 기밀/PII 마스킹 범위 | 병합 품질하락·작업자 식별정보 노출. 대표 샘플 PoC로 임계 협의 |
마지막 트레이드오프를 솔직히 남긴다. 효과 수치를 보수적으로 "목표치"라 라벨링하면 사업 제안의 임팩트는 약해 보인다. 그러나 As-Is 미확보 상태에서 단정한 수치는 인수검수 단계에서 "그 30%의 기준값이 무엇이냐"는 질문에 무너진다. 본 설계가 일관되게 택한 입장은 "근거 있는 목표치 + 측정 프레임"이 "근거 없는 확정 수치"보다 엔터프라이즈 신뢰를 얻는다는 것이다. AI가 자동으로 써주는 시스템이 아니라 사람이 완성하는 시스템이라는 정체성과 마찬가지로, 효과 역시 "측정으로 증명하는" 정직함이 이 도메인의 정석이다.
13. 베스트 프랙티스 — 언제 이 아키텍처를 쓰고, 언제 피하나
지금까지 살펴본 아키텍처를 한 문장으로 압축하면 "비정형 전문 문서를 RAG로 자산화하고, 그 위에서 사람과 AI가 멀티턴으로 함께 결과물을 완성하며, 완성본을 다시 코퍼스로 되먹이는 구조"다. 이 설계는 우아하지만 만능이 아니다. 오히려 적용 조건을 잘못 잡으면 과설계(over-engineering)의 전형이 된다. 보고서가 정체성을 4축 — ① 비정형 문서 RAG 자산화 ② HITL 가이드형 멀티턴 ③ 피드백 루프 데이터 선순환 ④ 평가·가드레일 — 으로 못박은 이유가 여기에 있다. 도입을 결정하려면 "내 문제가 이 4축을 실제로 요구하는가"를 먼저 따져야 한다.
핵심 논증은 이렇다. 이 아키텍처의 비용 대부분은 RAG 색인 파이프라인(ch14)·멀티턴 상태보존(ch8)·HITL 루프(ch13)·평가 백본(ch19)이라는 네 개의 무거운 축에서 발생한다. 만약 문제가 이 네 축 중 일부만 요구한다면, 더 단순한 패턴(단일 호출 RAG, 룰 기반 분류기, 정형 쿼리)으로 충분하며 이 풀스택은 부채가 된다. 반대로 네 축을 모두 요구한다면 — 즉 비정형 전문 문서가 다수이고, 전문가의 현장 판단이 반드시 개입해야 하며, 자동 판정의 오류 리스크가 크고, 결과물 품질을 계약 수준으로 검증해야 한다면 — 이보다 정직한 정석 아키텍처는 없다.
여기서 정직하게 드러내야 할 미결 쟁점이 둘 있다. 첫째, 멀티턴 세션 상태의 소유권 경계(프론트엔드 화면 시스템 vs 에이전트)다. 보고서가 1순위 리스크로 지목했듯, 이 단기 메모리를 누가 영속하느냐가 정해지지 않으면 스무고개식 멀티턴 자체가 동작 불능이 된다. 둘째, '다중 에이전트'를 정체성으로 착각하는 과설계다. 다중 에이전트 시연을 의식해 단일 도메인 검색이나 결정적 ETL까지 에이전트로 쪼개면, 토폴로지가 본질을 잡아먹는다. 다중 에이전트는 정체성이 아니라 '본질을 담는 그릇'일 뿐이라는 게 보고서의 일관된 결론이다.
| 도입 전 체크리스트 | 확인 질문 | 핵심 패턴 |
|---|---|---|
| □ 비정형 문서 규모 | OCR·구조화가 필요한 자유서술 문서가 수백~수천 건 이상 쌓여 있는가? | ch14 RAG |
| □ 사람 판단의 불가피성 | 현장 확인·전문가 판정 없이는 결과물이 완성될 수 없는가? | ch13 HITL |
| □ 멀티턴 상태 소유권 | 세션ID·대화 컨텍스트를 어느 컴포넌트가 영속할지 계약으로 못박았는가? (착수 전 1순위) | ch8 Memory |
| □ 피드백 루프 게이트 | 검증 통과 완성본만 재색인하는 품질 게이트가 단기→장기 승격 직전에 있는가? | ch9·ch19 |
| □ 평가·가드레일 백본 | Groundedness·환각률·적중률을 측정·게이트할 평가 체계를 초기부터 둘 수 있는가? | ch19·ch18 |
| □ 과설계 경계 | 결정적 분기는 룰로, 단일 검색은 단일 에이전트로 두어 토폴로지 과분할을 피했는가? | ch2·ch7 |
결국 이 모든 설계 결정이 수렴하는 지점은 단 하나의 철학이다. 비정형 전문 문서와 사람의 현장 판단이 뒤섞인 도메인에서, 가장 위험한 선택지는 "AI가 알아서 써주게 만드는 것"이다. RAG가 과거 지식을 회수해 방향을 비추고, 멀티턴이 빠진 정보를 사람에게 되묻고, 평가 게이트가 환각을 차단하고, 피드백 루프가 사람이 완성한 결과물을 다시 자산으로 키운다 — 이 모든 장치는 결국 한 가지를 보장하기 위해 존재한다. AI가 써주는 게 아니라, AI와 사람이 함께 쓴다. 이 한 문장을 설계의 헌법으로 삼을 수 있는 문제라면, 이 아키텍처는 당신의 정답이다. 그렇지 않다면, 더 단순한 길을 택하라.
케이스 스터디 · 한 실무 요건 = 21개 에이전틱 패턴 · 핵심 4종(RAG · HITL · Memory · Evaluation)을 중심으로 본 적용 분석
에이전틱 AI를 공부할 때 우리는 패턴을 한 개씩 배운다 — 체이닝, 라우팅, RAG, 휴먼 인 더 루프, 메모리, 평가. 하지만 현장의 실무 요건 하나는 그 패턴들을 한꺼번에 요구한다. 이 케이스는 "비정형 문서를 검색 가능한 지식으로 만들고(RAG), 사람과 함께 멀티턴으로 답을 완성하며(HITL·Memory), 그 품질을 게이트로 통제한다(Evaluation·Guardrails)"는 네 축을 정체성으로 삼고, 나머지 열일곱 패턴이 이를 떠받친다. 가장 중요한 한 줄은 변하지 않는다 — AI가 써주는 게 아니라, AI와 함께 쓴다. 비정형 문서와 전문가 판단이 섞인 고책임 도메인에서, 이것이 자동화보다 먼저 와야 할 설계 원칙이다.
- LangGraph 공식 문서 — Human-in-the-loop · interrupt · 조건부 엣지
- LangChain 공식 문서 — RAG 튜토리얼(검색 증강 생성)
- Google ADK 공식 문서 — LlmAgent · Multi-agent · FunctionTool
- RAGAS 공식 문서 — RAG 평가 지표(faithfulness · answer relevancy)
'Agentic AI Case Studies' 카테고리의 다른 글
| AI에게 배합 비율을 묻지 마라 — 계산은 옵티마이저에, 설명만 LLM에 (0) | 2026.06.25 |
|---|---|
| AI는 시험 일정을 계산하지 못한다 — 제약 스케줄링 최적화 모듈과 LLM을 분리한 자동 배치 설계 (0) | 2026.06.23 |
| 가장 비슷한 과거값이 정답은 아니다 — 사출 수축률을 추천하고 학습하는 HITL 에이전트 (0) | 2026.06.20 |