LINE Games의 AI Agent를 통한 게임 퍼블리싱 가속화 여정

더 재미있고 품질 좋은 게임을 빠르게 유저와 만날 수 있도록 하기 위해 외부 개발사와의 원활한 협업은 게임 퍼블리싱 비즈니스에서 필수입니다. LINE Games는 다양한 게임 개발사가 빠르게 게임을 출시할 수 있도록 인앱결제, 빌드 배포, 계정 관리 등 퍼블리싱을 위한 플랫폼을 제공하고 있습니다. 하지만 각 개발사가 처한 상황이 다르고, 사용하는 게임 엔진(Unity와 Unreal)과 프레임워크 등 다양한 환경에 있어 기술 문의에 많은 리소스가 소모되고 있었습니다. 특히 복잡한 API 연동 프로세스와 다양한 환경별 가이드라인으로 인해 신규 게임 출시 주기가 지연되는 경우가 빈번했습니다.

LINE Games는 이를 해결하기 위한 솔루션 도출을 위해, AWS와 함께 Working backwards에 기반한 Innovation 워크샵을 진행했습니다. 그 과정에서 GenAI 기반의 게임별 AI 추천 시스템, API 연동 현황 플랫폼 등 다양한 이니셔티브가 도출되었고 게임 퍼블리싱 주기 단축과 운영 효율성 개선을 기대할 수 있는 가능성을 발견하게 되었습니다. 이를 기반으로 LINE Games, 파트너인 GSN, AWS가 함께 AI Agent 기반의 플랫폼 구축을 시작하게 되었습니다.

LINE Games는 현재 “Nexus AI”라는 이름의 플랫폼을 구축하고 이를 베타로 운영 중입니다. Nexus AI는 Amazon Bedrock을 활용한 AI Agent 시스템으로, 기존 LINE Games 내부의 문서들을 기반으로 외부 개발사의 기술 문의를 실시간으로 해결하고 온보딩 경험을 개선하는 것을 목표로 개발되었습니다. 본 글에서는 Amazon Bedrock Knowledge Base(이하 KB)와 Amazon Bedrock Agents를 중심으로 구축한 자동화된 AI Agent의 아키텍처와 구현 상세, 그리고 실제 베타 운영 경험을 공유합니다.

게임 퍼블리싱 어려움

LINE Games는 게임 개발사를 대상으로 퍼블리싱 플랫폼과 SDK를 제공하며 개발사의 빠르고 성공적인 런칭을 지원하고 있습니다. 하지만 개발사마다 게임 엔진, 프레임워크, 아키텍처가 다르기 때문에 획일화된 가이드로는 모든 상황을 커버하기 어려웠습니다. 특히 예측 불가능한 변수들이 방대한 API 문서와 결합하면서, 기술 지원에 대한 커뮤니케이션 비용이 기하급수적으로 증가했습니다. 특히 다음의 두 가지 요인이 가장 큰 커뮤니케이션 비용을 차지하게 되었습니다.

외부 개발사가 겪는 기술 통합의 병목 현상

상황 맞춤형 가이드 부재 : “문서에는 REST API 명세만 있는데, 제가 사용하는 Unity C# 환경에서 바로 사용할 수 있는 샘플 코드는 없나요? 매번 작성하는 작업이 큰 부담입니다”
기술 문의 응답 속도 : “간단한 API 파라미터 질문인데, 담당자를 찾고 답변을 주고 받다 하루 이상 지체되었습니다. 이 문제 하나 때문에 빌드 테스트가 중단되었습니다.”
방대한 문서 속 정보 탐색 피로도 : “새로운 빌드 시스템이 적용됐는데, 수백 페이지가 넘는 문서에서 변경된 파라미터를 찾기까지 한 시간이 걸렸습니다.”

내부 지원팀이 직면한 운영상의 과제

반복적인 업무 과다 : “기술PM으로서 SDK 연동 시 발생하는 기본적인 인증 토큰 갱신 관련 질문에 일주일에 3~4회 이상 동일한 답변을 하고 있습니다. 이 시간만 줄여도 신규 기능 개발 로드맵에 집중할 수 있을텐데요.”
코드와 문서 사이의 간극: “새로운 SDK를 배포했는데, CI/CD를 통해 문서가 자동 업데이트되지 않아 개발사 문의가 들어왔을 때 문서가 낡았다는 것을 알게 되었습니다.”
경험의 비공유 및 단절 : “오랜 경험을 가진 담당자가 퇴사하거나 팀을 이동하면, 담당자의 머릿 속에 있던 지식이 단절되어 기술 지원 품질이 불안정해졌습니다.”

퍼블리싱 어려움 극복을 위한 GenAI의 도입

이를 프로토타이핑 하는 과정에서 처음에는 정해진 시나리오나 FAQ 기반으로만 응답할 수 있는 단순한 형태의 챗봇을 생각했습니다. 다만, 이 경우 개발사의 복잡하고 비선형적인 기술 질문에는 근본적인 한계가 있었습니다. 따라서 챗봇을 넘어 AI Agent를 통해 LINE Games 내에서도 숙련된 전문가들만 할 수 있었던 문서 검색, 상황 분석, 코드 생성의 복합적인 과정을 자동화하고자 했습니다.

이 과정에서 Amazon Bedrock을 선택한 이유는 다음과 같습니다.

관리형 RAG : Bedrock KB를 통해 방대한 API 문서를 직접 처리하고 인덱싱하는 작업을 줄이고, 높은 신뢰도로 컨텍스트를 제공할 수 있습니다.
관리형 에이전트 : Bedrock Agent를 통해 단순히 답변을 생성하는 것을 넘어, 질문의 의도를 분석하여 ‘문서 검색’, ‘코드 생성’, ‘서포트 티켓 생성 API 호출’ 등의 적절한 액션(툴)을 스스로 판단하고 실행하도록 설계하기 용이했습니다.
유연한 모델 선택 : 개발사의 니즈와 복잡도에 따라 Anthropic Claude를 비롯해 여러 LLM을 선택적으로 활용할 수 있었습니다.

솔루션 아키텍처

[그림 1] Nexus AI 아키텍처

LINE Games는 Amazon Bedrock을 중심으로 개발사의 기술 문의를 자율적으로 처리하는 자동화된 기술 지원 시스템을 구축했습니다. 이는 단순한 챗봇이 아닌, 질문의 의도를 파악하고 필요한 액션을 오케스트레이션하는 Agentic RAG 아키텍처로 구성되었습니다. 기반 모델로는 Claude 4.5 Sonnet을 사용했으며, 지속적으로 새 모델이 나올 때 답변 드리프트 정도를 검증하고 모델 업그레이드를 할 예정입니다.

아키텍처는 크게 세 개의 레이어로 구성됩니다. 프론트엔드는 기존 플랫폼에 통합된 채팅 인터페이스입니다. 개발사는 별도 도구 없이 기존에 사용하던 플랫폼에서 바로 질문할 수 있으며, Streaming 응답을 통해 유저 경험을 향상시켰습니다.

애플리케이션 백엔드에서는 Bedrock Agent가 중심이 되어 KB를 검색하고 Lambda에 정의되어 있는 도구를 호출하며, 답변 생성을 처리하게 됩니다. 특히 Bedrock Agent는 기존 LINE Games Confluence에 저장된 수백 개의 기술 문서가 담긴 KB를 검색하고, 필요하다면 Lambda 함수를 호출하여 실시간 Wiki 정보를 조회합니다. 이를 통해 개발사의 질문에 최대한 최신 문서를 기반으로 맞춤형 답변을 생성합니다. 또한 ElastiCache for Valkey를 활용한 시맨틱 캐싱을 통해 자주 물어보는 질문이나 이전에 생성된 답변의 경우 LLM 호출을 하지 않고, 더 빠른 속도로 비용효율적으로 응답할 수 있습니다.

마지막으로 데이터 파이프라인은 AWS Step Functions로 자동화되어 있습니다. 매일 정해진 시간에 Confluence 문서를 크롤링하고, KB를 업데이트하여 기술 문서 변경 사항이 자동으로 AI Agent에 반영되도록 했습니다. 또한 KB는 후술할 시맨틱 청킹 및 커스텀 청칭 로직을 통해 문서를 최적화된 상태로 저장합니다. 현재 인적 리소스는 코드 변경에 따라 문서를 업데이트하는 것에만 사용되고 있으며, 추후에 이 또한 자동화하는 것을 목표로 하고 있습니다.

구현 상세

RAG 구현 퀄리티에서 가장 핵심적인 요소는 데이터입니다. 본 파트에서는 데이터 수집, 청킹 전략과 메타데이터 기반 필터링을 통해 어떻게 데이터 퀄리티를 높였는지와 Step Function을 통한 자동화 과정까지 전체 데이터 파이프라인 구축하는 과정을 살펴보겠습니다. 또한 AI Agent 성능 개선을 위해 도메인 기반 프롬프트 엔지니어링을 하고, 유저 경험을 위해 스트리밍 응답을 적용해 TTFT(Time To First Token)를 개선한 과정을 살펴보겠습니다.

Confluence 데이터 수집 자동화

LINE Games는 Confluence Server를 사용하고 있습니다. Bedrock KB는 Confluence 데이터 소스를 제공하고 있지만, Confluence Cloud 만을 지원하고 있습니다. 따라서 Confluence Server의 문서들을 수집하기 위해 크롤링 파이프라인 구축이 필요했습니다.

Confluence에는 스페이스라는 개념을 통해 큰 주제별 문서 묶음(예시: 플랫폼, SDK, 빌링)을 논리적으로 구성할 수 있으며, 페이지는 실제 내용이 담긴 문서 단위를 의미합니다. Confluence 크롤링을 위한 Lambda 함수는 대상 스페이스의 모든 페이지를 수집합니다. 각 페이지 수집 시, Bedrock KB 필터링에 활용할 수 있는 메타데이터 파일을 함께 생성합니다. 이 메타데이터는 검색 시 쿼리 필터링을 가능하게 하여 RAG의 정확도를 높이는 역할을 합니다. 실제 메타데이터 구조는 다음과 같습니다 :

{
  "metadataAttributes": {
    "category": {
      "value": { "type": "STRING", "stringValue": "billing" },
      "includeForEmbedding": true
    },
    "engine_type": {
      "value": { "type": "STRING", "stringValue": "unity" },
      "includeForEmbedding": true
    },
    "page_title": {
      "value": { "type": "STRING", "stringValue": "Unity 인앱결제 가이드" },
      "includeForEmbedding": true
    },
    "labels": {
      "value": { "type": "STRING", "stringValue": "인앱결제, SDK" },
      "includeForEmbedding": true
    },
    "page_id": {
      "value": { "type": "STRING", "stringValue": "123456" },
      "includeForEmbedding": false
    },
    "source_url": {
      "value": { "type": "STRING", "stringValue": "https://..." },
      "includeForEmbedding": false
    }
  }
}

메타데이터 자동 생성 로직은 다음과 같습니다.

category : 스페이스 키 기반 매핑을 통해 문서의 대분류를 결정합니다. (예: PLAT – “platform”, NEP – “ntsdk”, lgbillingsystem – “billing”)
engine_type : 상위 페이지 경로 내의 키워드를 분석해 개발사가 사용하는 엔진 유형을 식별합니다. (예 : Unity Version – “unity”, Unreal Version – “unreal”, 그 외 – “general)
page_title : 페이지 제목을 임베딩에 포함하여 검색 정확도를 향상시킵니다.
labels : Confluence 페이지에 태그된 라벨을 수집해 세부 검색 필터로 활용합니다.
page_id, source_url : 출처 인용 용도로 활용하며 임베딩 벡터 생성에서는 제외합니다.

이러한 메타데이터는 개발사가 “Unity 엔진” 환경에서 “빌링” 관련 “SDK” 문서를 찾는 것과 같이 구체적인 필터링 검색을 할 때 활용되어 검색 범위를 좁히고 정확도를 크게 향상합니다.

수집 후 저장 과정에서는 문서의 계층적 구조처럼 S3에 페이지를 동일한 계층적 디렉토리 구조로 저장했습니다. 예를 들어 “Platform > Unity Version > SDK 연동 가이드” 구조라면 S3에도 같은 경로의 Prefix로 저장되어 AI가 검색 결과를 역추적(Backtracking)하기 쉽도록 했습니다. 파일 명은 “제목_페이지ID.html” 형식으로 충돌을 방지했습니다.

시맨틱 청킹 + 커스텀 청킹 전략

Bedrock KB는 문서를 임베딩하기 전에 적절한 크기로 나누는 청킹(Chunking) 과정을 거칩니다. Nexus AI는 Bedrock KB의 시맨틱 청킹 전략에 커스텀 청킹 Lambda를 조합하여 기술 문서 특성에 최적화된 청크를 생성했습니다.

1단계 : Bedrock KB 시맨틱 청킹

이상적으로는 문서의 전체 맥락을 보존하는 것이 중요하지만, Amazon Titan Text Embeddings V2 모델의 입력 토큰 한도가 8192로 제한되어 있어 긴 기술 문서는 의미 단위로 분할이 불가피합니다. 이를 위해 Bedrock KB의 시맨틱 청킹 전략을 채택했습니다. 설정은 다음과 같습니다 :

{
  "chunkingStrategy": "SEMANTIC",
  "semanticChunkingConfiguration": {
    "maxTokens": 8000,
    "bufferSize": 1,
    "breakpointPercentileThreshold": 95
  }
}

Titan 모델의 토큰 한도 내에서 최대한 큰 청크 사이즈(maxTokens : 8000)를 유지하고, 문장 유사성이 급격히 떨어지는 구간(breakpointPercentileThreshold, 높을 수록 큰 청크)에서 분할함으로써 기술 문서의 내용이 중간에 끊기지 않고 의미 단위가 보존되도록 유도했습니다.

2단계 : 커스텀 청킹 Lambda를 통한 정제

1단계에서 분할된 청크는 여전히 Confluence HTML 원본 데이터를 포함하고 있습니다. Confluence는 매크로 태그, 취소선 등의 비정형 요소를 많이 포함하고 있어 AI의 정확한 이해를 방해합니다. 따라서 커스텀 청킹 Lambda를 통해 다음과 같은 추가 정제 작업을 수행했습니다. 1번과 2번 작업은 크롤링 작업에서 수행할 수도 있지만, 관심사의 분리를 위해 커스텀 청킹 Lambda에서 수행하게 되었습니다.

Deprecated 문서 필터링 : 내용에 ‘deprecated’, ‘삭제 예정’ 등의 키워드가 포함된 청크는 아예 제외하여 AI가 오래된 정보를 참조하는 것을 방지했습니다. 실제 데이터 분석 결과, 전체 976개 파일 중 168개(17%)가 필터링되었습니다.
HTML 태그 정제 : ac:structured-macro, ac:layout 등 Confluence 전용 매크로 태그와 취소선(s, strike, del) 콘텐츠를 제거하여 불필요하거나 유효하지 않은 정보를 걸러냈습니다.
최소 길이 보장 : 텍스트 길이가 50자 미만인 청크는 정보량이 부족하다고 판단하여 제외했습니다.

예시 코드

from bs4 import BeautifulSoup
import re

def custom_chunking_handler(event, context):
    """
    Bedrock KB Custom Chunking Lambda
    Semantic Chunking 후 추가 정제 수행
    """
    for file in event["inputFiles"]:
        for content_batch in file["contentBatches"]:
            content_json = load_from_s3(content_batch["key"])

            filtered_chunks = []
            for chunk in content_json["fileContents"]:
                html_body = chunk["contentBody"]

                # 1. Deprecated 문서 필터링
                if is_deprecated(html_body):
                    continue

                # 2. HTML 정제 (Confluence 매크로, 취소선 제거)
                clean_text = clean_html_content(html_body)

                # 3. 정제된 청크만 유지
                if clean_text and len(clean_text.strip()) >= 50:
                    filtered_chunks.append({
                        "contentBody": clean_text,
                        "contentMetadata": chunk["contentMetadata"]
                    })

            save_to_s3(filtered_chunks)

    return event

def is_deprecated(html_content):
    """Deprecated/Legacy 문서 필터링"""
    deprecated_keywords = [
        r'deprecated', r'deprecate', r'legacy',
        r'삭제예정', r'삭제할', r'미사용',
        r'archived', r'hotfix', r'임시'
    ]

    text = BeautifulSoup(html_content, 'html.parser').get_text().lower()
    return any(re.search(pattern, text) for pattern in deprecated_keywords)

def clean_html_content(html_content):
    """Confluence HTML 정제"""
    soup = BeautifulSoup(html_content, 'html.parser')

    # Confluence 매크로 태그 제거
    for macro_tag in soup.find_all(['ac:structured-macro', 'ac:layout']):
        macro_tag.decompose()

    # 취소선 콘텐츠 제거 (더 이상 유효하지 않은 정보)
    for tag in soup.find_all(['s', 'strike', 'del']):
        tag.decompose()

    # 코드 블록, 리스트, 테이블 구조 보존하여 텍스트 추출
    return soup.get_text(separator=' ', strip=True)

2단계 청킹 전략의 장점

1단계 시맨틱 청킹 : 의미 단위를 보존, 빠른 처리
2단계 커스텀 청킹 : Confluence 및 내부 문서 구조 기반 정제, 품질 필터링을 통해 AI 환각(Hallucination) 유발 요소 제거
결과 : 높은 데이터 퀄리티 기반 정확도 높은 답변 생성

메타데이터 기반 필터링

RAG의 검색 증강 품질은 검색 결과의 정확도에 크게 좌우됩니다. 개발자들은 자신의 환경에 특화된 정보만을 원합니다. Unity 엔진으로 개발하는 경우 Unreal 엔진 관련 문서는 불필요하고 해당 문서들이 검색 결과에 포함된다면 노이즈로 작용하여 답변의 정확도를 떨어뜨릴 수 있습니다.

이러한 문제를 해결하기 위해 Bedrock KB의 메타데이터 필터링을 통해 정확도를 향상시킬 수 있습니다. “Confluence 데이터 수집 자동화” 파트에서 서술한 것처럼 이 때 수집된 메타데이터를 사용하여, 사용자의 질문과 컨텍스트에 맞는 문서 청크만을 검색 대상에 포함하도록 필터링을 적용했습니다. 즉, 쿼리가 모호한 경우에도 검색되는 문서의 범위를 명확하게 제어할 수 있고, 검색 대상 수를 줄여 정확도 향상과 벡터 저장소 쿼리 비용 절감이라는 이점을 동시에 얻을 수 있게 됩니다.

필터링 예시

Unity 엔진을 사용하는 개발사가 인앱결제에 대해 질문하는 경우, Bedrock Agent는 질문의 의도를 파악한 후, Bedrock KB에 질의 시 다음과 같은 메타데이터 필터를 자동삽입하여 검색을 요청합니다.

{
  "metadataFilter": {
    "andAll": [
      { "equals": { "key": "category", "value": "billing" } },
      { "equals": { "key": "engine_type", "value": "unity" } }
    ]
  }
}

벡터 검색 이전에 필터링이 적용되기 때문에 유사도가 높더라도 필터 조건에 맞지 않는 문서(예: Unreal 결제 관련 문서)는 검색 후보에서 제외됩니다. 결과적으로 검색 정확도가 극대화되고, LLM이 오염된 정보를 바탕으로 환각 현상을 일으킬 가능성이 최소화됩니다.

Step Functions를 통한 자동화

기술 지원 시스템이 항상 최신 정보를 유지하려면, 데이터 파이프라인이 안정적이고 자동화되어야 합니다. LINE Games는 전체 데이터 적재 및 Bedrock KB 동기화 파이프라인 자동화 도구로 AWS Step Functions를 선택했습니다.

데이터 파이프라인은 S3, Confluence 크롤링, Bedrock KB 동기화 등 여러 동기/비동기적인 작업들을 포함하게 됩니다. 이처럼 장시간 소요되거나 여러 서비스를 엮어 사용해야 하는 복잡한 워크플로우를 처리할 때, Step Functions는 다음의 이점들을 제공했습니다 :

시각적 워크플로우 관리 : 복잡한 비즈니스 로직의 흐름을 시각적으로 정의하고 관리할 수 있어 유지보수성이 높습니다.
내장된 에러 처리 및 재시도 : Confluence API 호출 실패, 네트워크 타임아웃 등 일시적인 오류 발생 시 Step Functions가 자동으로 재시도 로직을 처리하여, Lambda 코드 내에서 복잡한 에러 처리를 할 필요가 없습니다. 특히 에러가 발생한 단계를 시각적으로 파악하고 확인할 수 있다는 점도 운영 과정에서 큰 도움이 되었습니다.
비동기 작업 지원 : Bedrock KB Ingestion Job처럼 완료까지 긴 시간이 소요되는 장기 실행 작업을 Lambda의 타임아웃과 별개로 안정적으로 관리할 수 있습니다.

[그림 2] Step Function Workflow

해당 워크플로우는 매일 자동 실행되며, Confluence 문서가 대규모 업데이트 되면 수동 트리거를 할 수도 있습니다. 따라서 이를 통해 문서 업데이트의 지연을 최소화하고 인적 개입 없이, AI Agent가 항상 최신 지식을 바탕으로 개발사를 지원할 수 있게 도울 수 있게 되었습니다.

프롬프트 엔지니어링 : 도메인 지식 주입

Agentic RAG에서 최종 답변 품질은 검색된 컨텍스트의 품질 뿐만 아니라, LLM이 컨텍스트를 해석하고 답변을 구성하게 만드는 가이드라인인 프롬프트에 의해 크게 좌우됩니다. LINE Games는 Bedrock Agent의 시스템 프롬프트에 내부 퍼블리싱 프로세스의 핵심 도메인 지식을 명시적으로 주입하여 답변의 정확성과 실용성을 극대화했습니다. 이 중 효과가 높았던 도메인 관련 프롬프트 예시를 몇 가지 살펴보겠습니다.

복잡한 상호작용 흐름 명시

LINE Games의 인앱 결제는 클라이언트의 SDK, 게임 서버, 빌링 플랫폼이 복잡하게 얽혀 상호작용하는 다중 주체 프로세스입니다. 개발자들이 가장 혼란을 겪는 부분인 ‘어떤 주체(Who)가’, ‘어떤 API(What)를’, ‘언제(When)’ 호출해야 하는지를 프롬프트에 명시적으로 정의했습니다. 이런 흐름을 프롬프트에 포함하여 AI Agent는 개발사의 현재 질문이 전체 흐름 중 어느 단계에 해당하는지 정확히 파악하고 다음 단계를 오류 없이 안내할 수 있게 됩니다. 예를 들어 개발사가 “Purchase API가 실패했어요”라고 질문하면, AI Agent는 이전 단계인 Reserve가 정상적으로 이뤄졌는지, 다음 단계인 Complete를 위한 준비가 되었는지 등 도메인 기반 트러블 슈팅 질문을 역으로 던질 수 있게 됩니다.

예시 흐름 :

1. Connect (호출 주체:클라이언트 → 대상:NTSDK)
2. 상품 목록 조회 (호출 주체:게임서버 → 대상:빌링서버)
3. RefreshProductInfo (호출 주체:클라이언트 → 대상:NTSDK)
4. Reserve (호출 주체:게임서버 → 대상:빌링서버) → billingOID 발급
5. Purchase (호출 주체:클라이언트 → 대상:NTSDK)
6. Complete (호출 주체:게임서버 → 대상:빌링서버)
7. Consume (호출 주체:클라이언트 → 대상:NTSDK)

이러한 명확한 프롬프트는 Agent에게 명확한 지침을 제공합니다. 다만, 이와 같은 복잡한 상호작용의 수가 많다면, 도메인 지식도 복잡하기 때문에 한 Agent가 모든 것을 처리하는 것이 어렵습니다. 따라서 후술할 향후 계획에서 다중 에이전트 구조를 통해 각 도메인 지식에 최적화된 Agent를 구성하고 이를 오케스트레이션하는 구조를 채택하게 됩니다.

통일되고 명확한 용어 정의

LINE Games 퍼블리싱 시스템에서 사용되는 용어들은 비슷한 단어지만 실제로는 그 역할이 꽤 다른 경우들이 존재했습니다. 예를 들어 API라고 지칭하지만 각 API 주체에 따라 의미하는 바가 달라지고, Token이라고 지칭하지만 어떤 API를 호출하기 위한 토큰인지 명확한 의미 부여가 필요했습니다. 따라서 프롬프트에 각 용어의 정의와 사용 주체를 명시적으로 구분하도록 지시했습니다.

용어 예시 :

API : 빌링 API (인앱 결제처리, 게임 서버 호출) ≠ 플랫폼 API (게임 정보 조회, 게임 서버 호출) ≠ NTSDK (통합 SDK, 클라이언트 호출)
Token : authToken (게임 서버가 플랫폼과 빌링 API 호출시 사용) ≠ pfSessionToken (클라이언트 로그인 인증, NTSDK로 획득)

용어를 정리해서 통일되고 명확한 의미를 가지도록 정의한 덕에 AI Agent는 오해를 유발하는 답변을 줄이고, 정확한 용어를 사용한 답변을 제공할 수 있게 됩니다. 또한 이처럼 도메인 지식을 녹여내기 위해 논의하다보니 내부 용어가 통일되는 부가적인 효과도 확인할 수 있었습니다.

개발 환경 맞춤형 코드 제공

기술 문의의 궁극적인 목적은 ‘작동하는 코드’를 얻는 것입니다. LLM이 검색된 텍스트 기반 문서에서 코드를 추출할 때, 개발사가 사용하는 언어로 변환하여 실제 샘플 코드를 제공할 수 있게 답변 원칙을 프롬프트에 주입했습니다.

답변 시 원칙:
1. Unity 엔진 관련 질의로 판단될 경우 → C# 코드 예제 제공
2. Unreal 엔진 관련 질의로 판단될 경우 → C++ 코드 예제 제공
3. 답변 근거로 사용된 Confluence 문서의 원본 URL을 항상 인용하여 신뢰성 확보
4. 다음 단계 준비사항 안내

프롬프트 외에도 앞서 설명한 engine_type 메타데이터 필터링을 통해 개발사의 환경에 맞는 문서를 우선 검색하고 적절한 언어로 코드를 제공하는 이중의 장치를 구성했습니다. 또한 Kiro CLI (구 Q Developer CLI)와 같은 도구의 활용을 개발사에게 적극 권장하며, 생성된 샘플 코드를 통해 개발사의 코드 베이스에 손쉽게 연결하는 것을 목표로 하고 있습니다.

품질 관리 : Human-in-the-Loop 평가

프롬프트 엔지니어링은 지속적으로 도메인 지식을 압축, 정제하는 과정입니다. 실제 개발사 문의들을 수집해 테스트 셋으로 구축하고, 프롬프트 수정 전후의 답변 품질을 비교하는 Human-in-the-Loop(HITL) 방식의 정성 평가 또한 수행했습니다. 도메인 지식이 제대로 반영되었는지, 답변이 개발사 상황에 맞게 구체적인지 등은 사람이 직접 판단해야 합니다. 이 과정을 통해 프롬프트 개선이 의도치 않게 답변 품질을 저하시키는 것을 방지하고 최적의 상태를 유지할 수 있었습니다.

프롬프트 관리

프롬프트 엔지니어링을 진행하다 보면, 프롬프트 버전이 난잡해지고 프로덕션에 연결되어 있는 프롬프트를 제대로 관리하지 못하는 상황들이 발생합니다. 특히 도메인 지식을 가지고 프롬프트를 수정하는 주체가 다양하다면, 더 빈번하게 프롬프트 관리 이슈가 발생합니다. LINE Games는 Bedrock Prompt Management를 통해 모든 프롬프트(시스템 프롬프트, Agent Instruction, Tool Instruction 등)를 버전 관리하고, 시스템 운영 환경에 안전하게 배포할 수 있도록 했습니다.

프롬프트 엔지니어링은 LLM에 대한 이해와 LINE Games의 퍼블리싱 도메인 지식에 대한 깊은 이해가 모두 필요합니다. 프롬프트 개선 주체를 단순 인프라/데브옵스 팀에 더해, 실제 기술 지원 경험이 풍부한 기술 PM 및 도메인별 핵심 개발자들로 지정했습니다. 이들은 개발사의 실제 고충을 가장 잘 이해하고 있기 때문에 프롬프트에 주입해야 할 핵심 도메인 로직(예: 결제 프로세스 흐름, 토큰 구분)을 가장 정확하게 정의할 수 있었습니다.

이러한 관리 체계와 도메인 지식 기반 프롬프트 덕에 Nexus AI는 도메인 지식의 진화에 맞춰 시스템 프롬프트를 민첩하게 업데이트하고 기술 지원 품질을 지속적으로 향상시킬 수 있었습니다.

스트리밍 응답 : UX 최적화

AI Agent 구축을 마무리하고 초기 내부 테스트에서 발견된 가장 큰 UX 문제는 답변 생성 시간이었습니다. Agentic RAG 시스템은 KB 검색, 벡터 유사도 계산, LLM 추론 등 여러 단계를 거치기 때문에 최종 답변을 받기까지 필연적으로 긴 대기 시간이 필요합니다. 초기 내부 테스트에서 복잡한 질문에 대해 답변 생성까지 30초에서 최대 60초 이상이 소요되는 것을 확인했습니다. 답변을 기다리는 동안 사용자는 빈 화면을 보며 대기해야 했고, 시스템이 멈춘 것으로 오해하여 이탈률이 높을 것으로 예상되었습니다. TTFT(Time To First Token), 즉 첫 번째 토큰이 응답되기까지의 시간을 체감상 최소화하는 것이 필요했습니다.

해결책 1 : 스트리밍 응답

먼저 Bedrock Agent의 실시간 스트리밍 응답 기능을 활용했습니다. 이 기능은 LLM이 전체 답변을 생성하기까지 기다리지 않고 작은 청크 단위로 사용자에게 응답을 전송하는 기능입니다. LINE Games는 Nexus AI의 경우 백엔드 API 서버를 Python 환경으로 운영하고 있으며 boto3 SDK를 사용하여 스트리밍 기능을 구현했습니다. 특히 생성하는 응답이 길어질수록 스트리밍 기능의 효과가 유의미했습니다. 실제로 코드를 응답하는 경우라면, 생성 응답이 몹시 길어지는 구조를 가지고 있어 첫 응답 대기 시간이 확연히 감소하는 것을 확인했습니다. 또한 추가적으로 FE에서는 대기하는 동안 현재 진행 중인 단계와 완료된 단계를 보여주는 것도 고려하고 있습니다.

해결책 2 : 시맨틱 캐싱

개발사마다 환경과 연동 시나리오는 다르지만, 그럼에도 불구하고 공통적으로 발생하는 질문들이 분명 존재했습니다. 특히 표현 방식은 조금씩 달라도 의미론적으로 비슷한 질의를 하는 경우들이 다수 있었습니다. 유저에게 전달되어야 하는 응답이 동일한데 매번 전체 답변 생성 프로세스를 거쳐 응답하는 것은 유저 경험적으로도, 비용적인 측면에서도 효율적이지 않았습니다.

이를 해결하기 위해 ElastiCache for Valkey 8.2부터 지원되는 벡터 유사도 검색을 활용해 시맨틱 캐싱을 적용하게 되었습니다. 수십 초 단위의 응답이 100~300ms로 줄고, LLM 호출 비용 또한 급격하게 감소했습니다. Agent가 복잡하면 복잡할수록, 시맨틱 캐싱을 활용할 때 비용은 캐시 히트 비율의 배수로 감소하는 구조를 가지게 됩니다.

개선 효과

항목	스트리밍 도입 전	스트리밍 도입 후	스트리밍 + 시맨틱 캐싱
첫 응답 대기 시간	30~60초	5초	5초 & 캐싱 응답 : 100~1300ms
사용자 경험	시스템 멈춤 오해	최대한 빨리 반응	일부 응답 즉시 반응
이탈률	높음	중간	낮음

운영 경험과 교훈

메타데이터 설계의 중요성

메타데이터 구조는 초기에 신중하게 설계해야 합니다. 처음에는 category만 정의했는데, 곧 Unity와 Unreal 엔진을 구분할 필요성을 느꼈습니다. 그래서 engine_type을 추가했고, Confluence 페이지에 태그된 라벨(labels)도 수집하여 더 세밀한 검색을 지원하도록 확장했습니다. 메타데이터를 추가하려면 전체 문서를 다시 크롤링하고 Knowledge Base를 재구축해야 합니다. 이는 시간이 오래 걸리는 작업이므로, 처음부터 확장 가능한 구조로 설계하는 것이 중요합니다.

특히 engine_type 같은 배타적 분류는 자동으로 결정되도록 로직을 만들어야 합니다. 사람이 수동으로 태깅하는 작업을 최소로 줄이고, 새 문서가 추가될 때에도 누락되지 않도록 신경써서 태그를 부여해야 합니다.

청킹 전략의 최적화

데이터 품질은 RAG를 넘어 Agentic RAG에서도 여전히 중요합니다. 2단계 청킹 전략을 통해 의미 단위를 보존하면서도 LINE Games의 Confluence 페이지들에 특화된 크롤링 및 정제를 할 수 있었습니다. 초기에는 고정 토큰 크기로만 분할했는데, 문장이 중간에 끊기거나 코드 블록이 분리되는 문제가 있었습니다. 그러나 2단계 청킹 전략을 도입한 후 의미 단위가 자연스럽게 보존되어 답변 품질이 크게 개선되었습니다. 다만, 매우 긴 API 명세나 복잡한 테이블이 포함된 문서는 여전히 까다롭습니다. 8000 토큰을 초과하는 페이지는 불가피하게 분할되는데, 테이블이 중간에 끊기면 맥락이 손실되는 경우가 있습니다.

이를 AI Agent 시스템 레벨에서만 해결하기 보다는, 원본 문서 구조의 문제가 아닌지 고민해볼 필요가 있습니다. 따라서 기술 문서 작성 가이드를 개선하는 것이 필요합니다. 더 나은 AI Agent를 위해 문서 작성 시부터 “핵심 API 명세는 단일 청크에 담길 수 있도록 페이지를 세분화하고, 코드 블록을 불필요하게 긴 설명과 혼합하지 말 것” 등의 지침을 추가하는 것이 필요하다는 점을 깨달았습니다.

도메인 간 교차 참조 문제

운영 중에 발견된 가장 복잡한 문제는 도메인 간 교차 참조였습니다. 빌링 SDK와 플랫폼 SDK는 기능상 분리되어 있지만, 실제 문서에서는 서로를 참조하는 문구가 빈번했습니다. 개발사가 category=billing으로 필터링하여 인앱결제에 대해 질문해도, 검색된 빌링 문서 청크에 플랫폼 API 관련 내용이 포함되어 있어 AI가 도메인을 명확히 구분하지 못하고 답변을 혼합하여 혼란을 주는 경우가 발생했습니다. 단기적으로는 프롬프트에 “답변 시 현재 질문의 category 외 다른 도메인 정보는 최소화할 것”이라는 명확한 지시를 추가하여 완화했지만, 근본적인 해결책은 각 도메인 지식을 별개의 에이전트가 전담하도록 분리하는 것임을 깨달았습니다. 이 경험은 향후 계획에서 후술할 다중 에이전트 구성을 검토하게 된 결정적인 계기가 되었습니다.

향후 계획

시맨틱 캐싱 고도화

적용되어 있는 시맨틱 캐시는 전통적인 방식으로 구현되어 있습니다. 질의에 대해 임베딩을 생성하고, 임베딩을 통해 벡터 유사도 검색을 ElastiCache에서 수행합니다. 단, 이 경우 개인화된 답변은 캐싱할 수 없으며 개인화된 답변이 필요하다면 다시 모든 응답 프로세스를 거쳐야 함을 의미합니다. 물론 tag를 활용해 hybrid query를 한다면 유저별 컨텍스트 혹은 카테고리 별 응답을 제공할 수도 있습니다. 다만 이 경우, 캐시의 범용성이 떨어지게 되고 이는 결국 캐시 히트율의 저하로 연결되게 됩니다. 따라서 기존 생성된 답변과 유저 컨텍스트를 다시 한 번 LLM에 넣어 개인화된 답변을 만들어내는 컨텍스트-인지 시맨틱 캐싱 사용 또한 검토하고 있습니다. 구상 중인 흐름은 다음과 같습니다 :

캐시 미스 시, SOTA LLM을 통해 정확한 답변 생성 후 캐싱
1. (Option 1) 답변을 생성할 때 Output 포맷을 통해 개인화 필요한 요소를 치환할 수 있는 템플릿 형식으로 답변 반환
2. (Option 2) 답변을 생성할 때 General한 답변을 생성하도록 유도
타 유저의 추가 질의에서 캐시 히트 시, 유저의 컨텍스트와 캐싱되었던 답변을 함께 모델에 전달해서 재추론. 단, 모델은 경량화된 모델을 사용하여 비용 절감, 추론 속도 향상.

개인화된 답변이 필요하다면 위와 같은 흐름으로, 일반적인 공통 FAQ에 대한 답변이 필요하다면 전통적인 시맨틱 캐싱을 사용하는 구현이 가능합니다. 하지만 캐싱 전략 자체가 복잡해지고 상대적으로 비용이 덜 절감될 수 있다는 단점이 있습니다. 그렇기 때문에 실제 AI Agent를 운영하며 쌓인 질의-응답 쌍 데이터를 살펴보고 개인화된 답변의 비율이 더 높아진다면 시맨틱 캐싱 고도화를 진행할 예정입니다.

AgentCore Memory 도입

현재 시스템은 세션마다 독립적으로 동작하므로, 같은 개발사가 여러 번 질문해도 이전 대화를 기억하지 못합니다. 세션 만료 후 “어떤 게임인가요?”, “어떤 플랫폼인가요?”라는 질문을 반복하게 됩니다. 이런 문제를 해결하기 위해 Amazon Bedrock AgentCore Memory를 활용하면 개발사별로 장기 컨텍스트를 유지할 수 있습니다. 개발사가 “저는 게임 A를 개발 중이고, iOS를 주력으로 합니다”라고 말하면, 이 정보를 메모리에 저장합니다. 다음 세션에서는 자동으로 이 컨텍스트를 활용하여, “빌드 가이드 보내주세요”라고만 물어도 게임 A의 iOS 빌드 가이드를 제공할 수 있습니다. 특히 액터를 게임사 직원, 게임사, 게임 별로 구성할 수도 있기 때문에 퍼블리싱 관계에 따라서 적절한 컨텍스트를 유지시킬 수 있습니다. 만약 메인 게임이 하나인 소형 스튜디오라면 게임사 혹은 게임 단위로, 혹은 게임이 여러 개인 대형 스튜디오라면 게임사 직원, 팀, 게임이 단위가 컨텍스트 메모리를 유지하는 단위가 될 수도 있습니다.

AgentCore Memory는 여러 전략을 지원합니다. User Preference Strategy는 개발사별 선호도를 저장하고, Summary Strategy는 대화 이력을 요약합니다. Custom Strategy를 구현하면 게임별 빌드 설정 이력이나 개발사별 이슈 패턴도 자동으로 학습할 수 있습니다.

특히 중요한 것은 AgentCore Memory를 사용하면 기존과 다르게 메모리가 Agent와 독립적이라는 점입니다. Bedrock Agent의 기본 memory는 agentId와 agentAliasId에 바인딩되므로, 프롬프트를 업데이트하여 새 alias를 만들면 모든 학습 데이터가 사라집니다. 하지만 AgentCore Memory는 독립적인 memoryId를 가지므로, Agent를 업그레이드해도 학습 데이터가 유지됩니다. 이는 프로덕션 환경에서 매우 중요한 차이며, LINE Games는 현재 AgentCore Memory를 통해 조직 단위의 개인화 챗봇을 구축하는 것을 목표로 삼고 있습니다.

다중 에이전트 구성

앞서 언급한 도메인 간 교차 참조 문제를 근본적으로 해결하기 위해 다중 에이전트 구성도 검토하고 있습니다. 하나의 Agent가 모든 도메인을 처리하는 대신, 빌링 Agent와 플랫폼 Agent를 분리하고 앞단에 감독자(Supervisor) Agent를 두는 구조입니다.

감독자 Agent는 사용자의 질문을 분석하여 적절한 작업자(Worker) Agent(빌링 또는 플랫폼)로 라우팅합니다. 각 작업자 Agent는 자신의 도메인에만 집중하므로, 교차 참조로 인한 혼란이 줄어듭니다. 필요시 감독자가 여러 작업자의 답변을 취합하여 통합 답변을 제공할 수도 있습니다.이를 구현하기 위해서는 문서별 도메인 식별이 더 정확해야 합니다. category 메타데이터만으로는 부족하여, Confluence 라벨 정보를 추가로 활용할 계획입니다. 예를 들어 “billing-api”, “platform-api” 같은 라벨을 문서에 태그하고, 이를 메타데이터로 수집하여 더 세밀한 도메인 분류를 시도할 수 있습니다.

다중 에이전트 구성은 Bedrock Agent에서 기능을 제공하지만, LINE Games 내부에서는 아직 리서치 및 설계 단계에 있습니다. 다중 에이전트를 활용하면 응답은 정확해지지만, 응답하는 과정에서 관여하는 Agent의 수가 늘어날수록 답변 품질은 증가할 수 있겠지만 반대로 지연 시간은 증가하게 됩니다. 따라서 현재 구성 중인 단일 Agent 시스템이 안정화된 후 단계적으로 도입할 예정입니다.

운영 현황 및 성과

Nexus AI는 현재 LINE Games 플랫폼 대시보드에 통합되어 배포를 앞두고 최종 검증 단계에 있습니다. 외부 개발사는 기존 관리 콘솔에서 채팅 인터페이스를 통해 실시간 기술 문의를 할 수 있으며, 답변은 스트리밍 방식으로 제공되도록 설계되었습니다. 답변과 함께 관련 Confluence 문서 URL이 제공되어, 개발사는 상세 정보가 필요한 경우 원본 문서를 직접 참조할 수 있습니다.

프로덕션 배포 전, 실제 개발사 문의 로그를 기반으로 구성된 테스트셋을 통해 성능 및 정확도를 검증했습니다. 이 내부 검증 결과를 바탕으로 서비스 도입 시 예상되는 목표 성과는 다음과 같습니다 :

지표	기존 시스템 (사람 대응)	목표 지표 및 내부 검증 결과	기대 효과
평균 응답 시간	2~24시간	45초 이내	빠른 응답을 통한 연동 가속화
개발팀 직접 문의 대응 비율	주 50건 (100%)	36% 감소 (목표 : 32건 이하)	핵심 인력의 반복 업무 부담 경감
개발사 만족도 (5점 만점)	3.2점	4.3점 목표	답변 품질 및 접근성 개선을 통한 만족도 향상
온보딩 기간 효율	4~6주 소요	50% 이상 향상(목표 : 2.5주 이내)	신규 개발사 통합 속도 가속화
AI 답변 정확도	N/A	88% 이상 유지	Human-in-the-Loop 검증을 통한 고품질 답변 확보
월별 질의 처리량	N/A	1,250건 이상 처리 예상	안정적인 대규모 질의 처리 능력 확보

데이터 수집은 CloudWatch 메트릭 및 Datadog으로 응답 시간과 오류율을 추적했으며, 답변 정확도는 내부 테스트셋 및 Human-in-the-Loop(HITL) 평가를 통해 88% 이상의 정확도를 검증했습니다.

결론

LINE Games의 Nexus AI는 AI Agent를 활용하여 게임 퍼블리싱 프로세스를 프로덕션 레벨에서 효율화했습니다. Amazon Bedrock Knowledge Base와 Agent를 중심으로 구축한 시스템은 Confluence 문서 자동 수집, 품질 필터링, 2단계 청킹 전략(시맨틱 + 커스텀), 메타데이터 기반 검색을 통해 개발사에게 정확하고 빠른 답변을 제공합니다.

Nexus AI를 구축하며 가장 중요했던 요인은 세 가지입니다.

데이터 품질 관리: 만료된 문서를 자동으로 필터링하고, 불필요한 콘텐츠를 원본으로부터 제거했습니다. 특히 의미 단위를 보존하는 커스텀 청킹 전략과 품질 필터링 단계를 통해 AI Agent가 신뢰할 수 있는 답변을 생성하도록 기반을 마련했습니다.
도메인 특화 설계: 게임 엔진별 메타데이터 분류, 퍼블리싱 프로세스 지식을 프롬프트에 주입, Human-in-the-Loop 방식의 품질 평가, 게임 엔진별 맞춤형 코드 예제 제공 등 최적화된 시스템을 구축했습니다.
자동화: AWS Step Functions를 통해 크롤링부터 KB 소스 동기화까지 전 과정을 자동화하여, 기술 문서가 업데이트되면 하루 안에 시스템에 반영될 수 있도록 하였습니다.

향후 시맨틱 캐싱 고도화, 다중 에이전트 구성, AgentCore Memory를 단계적으로 도입하면 응답 속도와 답변 품질, 개인화 측면에서 더욱 개선될 것으로 기대합니다. 이 글이 유사한 B2B 기술 지원 자동화를 고민하는 조직에 실질적인 도움이 되길 바랍니다.

AWS 기술 블로그