KnowledgeForge의 폐쇄 루프(Closed-loop) 지식 생명주기

IT 서비스 관리(ITSM) 티켓에 기록된 증상과 해결 방법이 지식 베이스로 전환되지 않아 엔지니어가 동일한 문제를 반복 해결하는 비효율이 발생한다. KnowledgeForge는 해결된 인시던트 티켓에서 유효한 정보를 추출해 지식 생명주기를 자동화하는 폐쇄 루프(Closed-loop) 시스템을 구축했다. 기업의 IT 지원 팀이 처리하는 수천 건의 티켓 이력에 잠겨 있던 해결책을 수집하고 정제해 엔지니어의 반복적인 문제 해결 시간을 단축한다.

시스템은 생성(Generation)과 큐레이션(Curation)이라는 두 서브시스템이 데이터를 주고받는 구조다. 생성 서브시스템은 클러스터링된 티켓 묶음을 분석해 새로운 지식 베이스 문서와 근본 원인 분석(RCA) 문서를 작성한다. 여러 티켓에 나타나는 공통 증상과 해결 경로를 추적해 하나의 기술 문서로 통합함으로써, 단편적인 작업 노트가 조직 전체가 공유하는 공식 지식으로 변환된다.

큐레이션 서브시스템은 생성된 문서와 기존 문서를 대상으로 유형 분류, 중복 제거, 품질 점수 산정, 약한 콘텐츠 재작성이라는 네 단계의 정제 과정을 수행한다. [Figure 1] 특히 큐레이션 단계에서 저장된 벡터 데이터는 다시 생성 단계의 검색 증강 생성(RAG) 근거로 재사용된다. 검증된 기존 지식을 참조해 새 문서의 정확도를 높이는 순환 구조를 통해 지식 베이스의 품질을 관리한다. 정제가 완료된 최종 산출물은 ServiceNow를 통해 지식 관리자의 승인을 거쳐 게시된다.

Claude 4.5와 RAG를 활용한 문서 생성 및 큐레이션 흐름

Amazon S3에 JSON 형태로 저장된 고객별 티켓 테마와 키워드, 작업 노트가 입력 데이터로 사용된다. 해결된 인시던트를 문제별로 그룹화해 S3 버킷에 저장하면, 이 데이터가 Amazon Bedrock에서 구동되는 Anthropic Claude Sonnet 4.5 모델로 전달되어 고정된 구조의 문서로 생성된다.

용어의 일관성을 유지하기 위해 RAG 구조를 적용한다. S3 Vectors 인덱스에서 생성하려는 문서와 가장 유사한 기존 문서 5개를 검색해 모델의 참조 컨텍스트로 제공한다. 모델은 이 문서들을 근거로 기존 지식 체계와 충돌하지 않는 정형화된 문서를 작성하며, 작성자나 시점에 상관없이 동일한 기술 용어를 사용하게 한다.

전체 생성 프로세스는 Amazon ECS와 AWS Fargate를 통해 실행된다. Fargate는 서버리스 컨테이너 엔진으로, 처리해야 할 티켓 테마가 급증하는 버스트성 워크로드에 맞춰 컴퓨팅 자원을 자동으로 확장한다. 인프라 관리자가 서버 용량을 직접 설정할 필요 없이 생성 로직이 담긴 컨테이너만 배포해 수요에 대응하는 구조다.

문서 조립 효율을 높이기 위해 Amazon Bedrock의 응답 스트리밍(Response streaming)을 활용한다. 컨테이너는 전체 응답이 완료될 때까지 대기하지 않고, 토큰이 도착하는 즉시 실시간으로 문서를 조립한다. 이 방식은 대량의 티켓 데이터를 지식 문서로 변환하는 파이프라인의 대기 시간을 줄여 처리 속도를 높인다.

S3 Vectors와 전용 벡터 데이터베이스의 인프라 효율성 비교

앞서 언급한 RAG 구현의 핵심인 Amazon S3 Vectors는 서버 노드 유지 비용이 아닌 쿼리 횟수와 저장 용량(GB) 기반의 비용 구조를 가진다. 별도의 벡터 데이터베이스 서버를 운영하지 않고 S3에 임베딩 벡터와 메타데이터를 직접 저장해 인프라 관리 부담을 제거했다. 메타데이터를 함께 저장해 고객별 필터링을 효율적으로 수행하며, S3 사용 환경이라면 추가 인프라 도입 없이 벡터 검색 기능을 추가할 수 있다. 상세 설정은 Amazon S3 User Guide를 통해 제공된다.

모든 문서는 Amazon Titan Text Embeddings V2를 거쳐 1,024차원의 임베딩으로 생성된다. 생성된 벡터는 고객별로 분리된 S3 Vectors 인덱스에 저장되어 문서 검색과 중복 탐지를 동시에 수행한다. 벡터 방식은 문장의 의미적 유사성을 직접 계산하므로, 표현이 조금 다른 중복 문서도 찾아낼 수 있다.

중복 탐지의 기준은 코사인 거리 0.05(유사도 0.95 이상)이며, Top-K 5 설정을 통해 상위 5개 벡터를 대조한다. 표본 쌍 검증을 통해 도출한 이 임계값을 통해 단순 관련 문서와 실제 중복 복사본을 구분한다. 중복이 확인되면 최신 버전의 문서만 유지하고 오래된 문서는 폐기한다.

중복 확인 쿼리는 특정 고객의 활성 상태인 문서만을 필터링해 단 한 번의 API 호출로 처리한다.

python
response = s3_vectors_client.query(index_name='customer-index', vector=new_article_vector, top_k=5, filter={'status': 'active'})

이러한 구조는 전용 DB 서버 상시 가동 비용을 없애면서도, 라이브러리의 모든 문서에 개별 벡터를 할당하고 관리할 수 있는 경제적 기반이 된다.

Step Functions 기반 대규모 GenAI 파이프라인 오케스트레이션 패턴

매일 정해진 시간에 대량의 문서를 처리하는 파이프라인은 작업 순서와 그룹화가 핵심이다. Amazon EventBridge가 일정을 트리거하면 AWS Lambda가 새 문서나 변경 사항이 있는 고객을 식별해 배치를 구성한다. 이 데이터는 Amazon SQS FIFO로 전달되어 고객별 작업 순서를 엄격하게 보장하며, 대규모 배치 처리 시 발생할 수 있는 데이터 경합을 방지한다.

수많은 문서 처리 작업을 분산하고 실패 지점부터 복구하기 위해 AWS Step Functions의 분산 맵(Distributed Map)을 도입했다. 분산 맵은 워크플로 상태를 관리하며 정의서에 명시된 재시도 및 에러 핸들링 규칙을 자동으로 수행한다. 특히 2단계 분산 맵 구조를 통해 수천 개의 아이템을 동시에 처리하는 팬아웃(Fan-out) 환경에서도 각 작업의 성공 여부를 정밀하게 추적할 수 있다. 상세 구현 방법은 AWS Step Functions Developer Guide에 기술되어 있다.

아이템 프로세서는 STANDARD 모드로 운용한다. Amazon Bedrock의 LLM 호출이 5분을 초과하는 사례가 빈번하며, 문제 발생 시 디버깅을 위해 상세한 실행 이력을 보존해야 하기 때문이다. 또한, S3에 저장된 매니페스트 파일을 ItemReader가 직접 읽어 처리하는 방식을 통해 Step Functions의 페이로드 크기 제한 문제를 해결하고 대량의 메타데이터를 안정적으로 전달한다.

별도의 벡터 DB 없이 S3에 임베딩 벡터를 직접 저장하고, 코사인 거리 0.05와 Top-K 5 임계값을 적용해 중복을 탐지하는 것이 비용 효율적인 RAG 아키텍처 설계의 구체적인 실행 기준이다.