넥슨의 LLM 에이전트 길들이기: 인프라 모니터링 서비스 적용 사례

백오피스 복잡성 증가

• 내부용 백오피스 서비스 다수 운영

  • 이슈 대응을 위한 서비스 별 담당자 정보 최신화 이슈

  • 이슈 발생 시 개별 확인으로 시간 소요

  • 이를 한 번에 쉽게 조회할 수 있는 시스템 필요

LLM 활용 및 AWS 지원

• AI 활용을 위한 업무 개선 사례 R&D

  • LLM의 추론 능력에 주목

  • LLM 챗봇 개발 경험의 한계 극복을 위한 AWS Professional Service 활용

    • 문제 발생 시 AWS 서비스로 해결 지원

LLM으로 하고 싶은 것

• 복수의 서비스를 연동하여 의미있는 답변 생성

  • 프로토타입 수준의 구현 목표

LLM으로 다양한 서비스의 연관 답변 만들기

• 구현 범위

  • 서비스의 Metric 데이터 중심 (확장성 고려)

  • 서비스맵 활용

  • LLM 챗봇 형태

• 성공한 점

  • 2주 단위 Sprint 목표 기능 구현

  • 기술 노하우 내재화

• 개선 필요점

  • 사용자 요구에 미흡한 사용성

  • 답변 품질 이슈 (속도, 정확도, 답변 비용)

  • 서비스간 연동 정보 보완 필요

프로젝트 조율

• 키 컨셉

  • Enablement: 인력과 기술의 지속성

    • 정량적 평가 중요성

    • 리더의 가치 인식에 따라 Enablement의 가치 달라짐

챗봇 준비사항

• 고려사항

  • 데이터간 연결고리 자동 확보

  • 변경 정보 즉시 반영

  • 다양한 응답 형태 지원 (그래프, 리스트, 자연어 등)

• 해결 방안

  • 연결고리 자동 식별 (엔지니어 - 서비스 - 호스트 - 매트릭)

  • 적합 기술 범위 설정

  • 범용 LLM 사용 및 커스텀 답변 설정

  • Amazon Bedrock 사용

  • Langchain 사용 (Bedrock 객체 제공)

• 초기 컨셉

  • Task -> LLM | Tools -> API, VectorDB

ReAct 프롬프팅

• 작업 계획 및 실행

  • LLM은 생성, 반복 / Langchain은 결과 주입

  • 실행 시간 30~40s, 추가 주입 시 30~45s 소요

• 초기 구성 검토

  • 데이터 연결고리, 정보의 즉시성, 자유로운 응답값

  • 응답 시간 및 환각 문제 발생

이슈 및 해결

• 속도, 정확도, 비용 문제

  • LLM 토큰 개수에 따른 비용 증가

  • 긴 입력의 복잡성 (프롬프트 + 정보 + 예제 + 명령)

  • 대화턴의 피로도

• 반복 빈도 최소화

  • 응답 속도와 환각 위험 축소

  • 모델 분리 검토 (Claude 2.1: 10~15s, Claude instant: 3~5s)

• MVP

  • 역할별 임무 부여 - multi-agent

  • 계획적 업무 수행 - Plan and Execute

  • 작업 단위 분할 - Task Tools

• 분할 작업도 LLM 활용

  • 설계, 코딩, 배포 단계로 작업 분할

• 추가 검토 기술

  • RAG 구성, Slot Filling, Streaming

지속 가능한 AI

• 변화에 능동적 대응 및 미래 방향성 확립

• LLM 모델의 지속적 업데이트 및 기술 개선 포인트 반영