KT Enterprise B2B Sales AI Agent 구축

분석 에이전트 8종 병렬 실행으로 지연 87% 단축

문제분석 품질을 위해 관점별로 에이전트를 8종으로 분리했으나, 순차 실행 구조에서 각 LLM 호출 시간이 그대로 누적되어 일괄 생성에 2분 이상이 소요됐습니다.

결정각 에이전트의 역할·프롬프트·출력 JSON 스키마를 독립적으로 격리해 상호 의존성을 제거하고, 스레드 풀(ThreadPoolExecutor) 기반 병렬 실행으로 전환. LLM 호출이 I/O 대기 중심이라는 점을 근거로 GIL 영향 없이 동시 처리가 가능하다고 판단.

결과분석 관점 8종을 유지한 채 일괄 생성 지연을 2분대에서 15.7초로 87% 단축. 전체 소요가 합계가 아닌 최장 단일 작업에 수렴하는 구조가 되어 관점 확장 여지 확보.

SHA-256 해싱·원문 분리 저장으로 멱등성 확보

문제30분 주기 수집에서 외부 API가 '최근 N건'을 반환하는 특성상 중복 적재가 반복됐고, 파싱 규칙을 변경해도 이미 적재된 과거 데이터에는 적용할 수 없었습니다.

결정출처가 부여한 ID가 아닌 페이로드 내용 자체를 SHA-256으로 해싱해 중복을 판별하고, 원문(Raw)과 가공 데이터를 분리 저장하는 구조로 설계.

결과수집기를 반복 실행해도 결과가 동일한 멱등성을 확보해 실패 시 재실행만으로 복구 가능. 다만 원문 보관은 6개월 백필 시점에 재검토했습니다. 재처리 목적으로 남긴 원본이 실제로는 한 번도 쓰이지 않은 채 용량의 85%를 차지해, 조달 데이터에 한해 실사용 값만 남기고 원본을 제거했습니다.

호출 예산제·커서 백필로 상용 규모(12,000곳) 대응

문제검증 대상이 4개사일 때는 회사당 6회, 하루 24회로 DART 한도(2만)의 0.1%였습니다. 12,000곳으로 늘리면 72,000회가 되어 한도를 3.6배 초과하는데, 호출 횟수를 세는 코드가 없었습니다. 이 API는 한도를 넘겨도 HTTP 200을 반환하고 본문 코드로만 알리므로, 대부분의 호출부가 이를 예외로 취급하지 않아 빈 응답을 정상으로 받아 기존 캐시를 덮어쓸 수 있었습니다.

결정계수 지점을 모든 fetch 함수가 반드시 거치는 저수준 요청 함수 2곳으로 수렴시켜 누락을 구조적으로 차단. 자체 계수가 예산에 닿으면 호출 전에 막고, 응답에 한도 초과 코드가 있으면 그날 예산을 즉시 닫는 2단 감지를 적용(재시도·다른 프로세스로 계수가 어긋날 수 있으므로 실제 응답을 우선). 예산 소진 시 회사 단위로 커서를 저장해 다음 날 이어받는 백필을 도입하고, 호출자별로 예외 처리를 나눠 대시보드는 빈 결과를, 적재 워커는 예외를 받게 했습니다. 워커가 '예산이 없어 못 받았다'와 '받았는데 비었다'를 구분해야 커서를 옮길지 판단할 수 있기 때문입니다.

결과12,000곳을 약 4일 주기로 순회하는 구조 확보. 시뮬레이션으로 예산 소진 중단·커서 이어받기(중복 0)·완주 후 리셋을 검증했습니다. 함께 호출 자체도 줄여, 업종코드는 소비처가 앞 2자리만 쓰는 것을 확인해 업종명 유도로 대체(12,000회 → 0회), 기업 식별자는 이름 대조를 종목코드 대조로 바꿔 매칭률 28% → 100%로 올렸습니다.

원본 보관에서 필요한 값의 투영으로 (1,058MB → 92MB)

문제조달 공고 6개월치를 백필하니 SQLite 파일이 1,058MB가 되어 저장소에 포함할 수 없게 됐습니다. 용량의 85%(898MB)가 API 응답을 통째로 저장한 테이블이었는데, 공고문 첨부 주소가 그 원본 안에만 있어(공고의 94%) 단순 삭제가 불가능했습니다.

결정원본을 참조하는 코드 경로를 전수 확인한 결과 첨부 주소 한 곳뿐임을 밝히고, 그 값만 공고 표에 JSON 컬럼으로 투영한 뒤 원본을 제거. 재처리 가능성을 포기하는 결정이었으나, 6개월간 파싱 로직을 여러 번 고치면서도 원본 재처리를 한 번도 하지 않았다는 사실을 근거로 삼았습니다. 데이터 이전 전에 읽는 쪽을 먼저 고쳐, 새 컬럼이 비면 기존 경로로 자동 폴백하도록 해 이전과 배포의 순서 의존을 없앴습니다. 비가역 작업이므로 --dry-run·원본 파일 보존·복원 스크립트를 함께 뒀습니다.

결과1,058MB → 92MB(8.7%)로 줄여 저장소 포함이 가능해졌고, 공고 81,661건·수요기관 603곳·첨부 77,179건(94%)을 보존했습니다. 조회 기능은 호출부 변경 없이 동일하게 동작합니다.

LangGraph 기반 멀티 노드 에이전트 코어 설계

문제GPU 서버 스펙·가격 질의처럼 하나의 질문에 상품 검색·조건 비교·지식 조회가 동시에 필요한 케이스에서, 단일 LLM 호출만으로는 툴 선택과 응답 품질을 안정적으로 통제하기 어려웠습니다.

결정사용자 질문·연동 툴 목록·수집 정보·검색 컨텍스트를 관리하는 AgentState를 정의하고, User Chat UI로부터 시작되는 전체 실행 그래프를 설계. Query Analysis & Routing 노드(LLM 의도 분석 기반 툴 라우팅), Generation 노드(답변 생성·유효성 체크), Slot-Filling/Rewrite 노드(필수 정보 누락 시 역질문·쿼리 재작성 루프)로 책임을 분리.

결과질문 의도에 따라 VectorDB RAG Retrieval + LLM Wiki Lookup을 병행 실행하는 등 동적 라우팅을 구현하고, [사용자 발화 → 의도 분류·가드레일 → RAG 검색 → 상품 안내·추천 → 멀티턴 대화 → 답변·UI 연계]의 6단계 프로세스를 완성.

Generation ↔ Slot-Filling 조건부 흐름 (자기 교정 루프)

문제답변 생성에 필요한 필수 정보가 누락된 상태에서 그대로 응답하면 부정확하거나 환각이 섞인 답변이 나갔습니다.

결정Generation 노드에서 정보 충분(Perfect Info) 시 텍스트·Product Card·출처(Citation)를 스트리밍 출력하고, 정보 부족(Info Missing) 시 Slot-Filling 노드로 분기하는 조건부 흐름을 설계. 누락 슬롯이 있으면 역질문(예: "혹시 현재 KT 전용선을 이용 중이신가요?")을 생성하고 쿼리를 재정교화한 뒤 재검색하는 자기 교정 루프를 구현.

결과정보가 충분할 때만 답변을 확정 출력하고, 부족하면 역질문으로 보완해 응답 신뢰도를 확보.

질의 유형별 멀티 RAG 지식 소스 전략

문제FAQ·상품 설명, 관계·종합 질의, 표준 용어·규정은 성격이 달라 하나의 검색 방식으로는 정확도와 일관성을 동시에 확보하기 어려웠습니다.

결정일반 FAQ·상품 설명은 Vector RAG(의미 유사도·대용량 확장), 관계·종합 질의는 GraphRAG(Multi-hop 추론), 표준 용어·규정·정책은 LLM Wiki로 매핑하는 지식 소스 전략을 수립. 문서 유형별 기준과 메타데이터(제목·출처·기준일·카테고리)를 정의·표준화.

결과질의 특성에 맞는 지식 소스를 선택해 검색 정확도를 높이고, 용어 일관성 보장·환각 감소 기반을 마련.

하이브리드 검색 + Re-Ranking 검색 품질 최적화

문제단일 검색 방식으로는 키워드 정합성과 의미 유사도를 모두 잡기 어렵고, Top-K 결과에 불필요한 컨텍스트가 섞여 답변 품질을 떨어뜨렸습니다.

결정BM25 + Vector 하이브리드 검색과 Graph Traversal을 결합한 검색 계층을 구성하고 Top-K 검색·파이프라인 파라미터를 튜닝. BGE-Reranker를 활용해 검색 정보를 점수화하고 불필요 정보를 제거하는 Grade & Rerank 컨텍스트 검증을 적용.

결과검색 정확도와 컨텍스트 품질을 향상시키고, RAG/GraphRAG/Wiki 통합 컨텍스트를 Agent·LLM에 전달해 실시간 답변 생성과 연결되는 End-to-End 파이프라인(문서 수집 → 구조화 → 지식 데이터화 → RAG 검색 → 통합 지식 결과)을 구성.

문제상품 카탈로그·규정 문서·마스터 데이터 등 정형화되지 않은 문서로 멀티 RAG를 구축하는 과정에서 문서 레이아웃 차이, 출처·기준일 누락, 전처리 기준 불일치가 발생하면 동일한 질문에도 서로 다른 문서가 검색되어 판단 일관성이 흔들렸습니다.

해결문서 유형별 기준과 메타데이터(출처·기준일·카테고리) 정리 방식을 정의하고, Parsing Engine 기반 문서 구조화와 함께 문서 수집→구조화→전처리→검색으로 이어지는 처리 흐름을 표준화. 입력 단계에서부터 오류 가능성을 줄이는 구조 개선에 집중.

문제복잡한 관계 질의·상품 간 연관·종합 질문은 단순 벡터 유사도 검색만으로는 정확히 답하기 어려웠습니다.

해결GraphRAG로 Entity·관계를 추출해 지식 그래프를 구축·적재하고, 표준 용어·고정 가이드라인·마스터 정보는 Markdown 위키(LLM Wiki)로 구조화해 용어 일관성 보장·환각 감소를 지원.