티맵모빌리티의 기존 운영 워크플로우와 AWS DevOps Agent를 연계한 AIOps 구축 사례

티맵모빌리티는 2천만 명의 등록 사용자와 1,400만 명의 월간 활성 사용자를 보유한 대표 모빌리티 플랫폼으로, 수십 개의 AWS 계정에서 실시간 교통 정보 기반 내비게이션과 운전습관, 대리운전, 숏폼 등 다양한 모빌리티 서비스를 제공합니다. 실시간성이 중요한 서비스 특성 상 짧은 장애도 많은 사용자의 이동 경험에 영향을 줄 수 있기 때문에 장애가 발생하면 어느 서비스와 리소스에서 문제가 발생했는지, 영향 범위가 어디까지인지 신속하게 파악하는 초기 분류(Triage)가 중요합니다. 정확한 조사로 원인 후보를 좁혀 불필요한 확인을 줄이고 적절한 복구 조치를 선택해 평균 장애 복구 시간(MTTR: Mean Time To Recovery)을 단축할 수 있기 때문입니다.

DevOps 팀의 모든 클라우드 운영 및 장애 대응 업무는 사내 협업 플랫폼과 체계적인 IT 서비스 관리(ITSM) 시스템을 중심으로 유기적으로 연결되어 있습니다. AWS 권한 신청과 같은 운영 관련 요청은 Jira 티켓으로 접수해 처리하고, 장애가 발생하면 Datadog에서 감지한 알람을 Slack으로 전달받아 대응합니다. 담당자들은 알람이 올라온 Slack 스레드에서 상황과 조사 내용을 공유하며 후속 조치를 결정합니다. 팀은 이러한 워크플로우 안에서 단순 반복 운영 업무를 자동화하고 장애 대응 속도를 높이기 위한 사내 AI 에이전트 Rookie와 데이터베이스 분석을 전담하는 DB DOSA를 개발했습니다. 두 에이전트는 운영 효율성을 높이고 장애 초기 분석을 지원했지만, 장애의 원인 후보를 검증하고 실제 원인까지 추적하는 데에는 여전히 담당자의 추가 조사가 필요했습니다.

이 블로그에서는 티맵모빌리티가 기존의 운영 업무 워크플로우를 유지하면서 AWS DevOps Agent를 심층 조사에 연결한 과정과, 조사 정확도를 높이기 위해 적용한 방법을 실제 장애 사례와 함께 소개합니다.

Rookie로 시작한 AIOps, 그리고 남은 과제

티맵모빌리티 DevOps 팀은 추가 인프라 운영 부담을 줄이기 위해 기존 Amazon EKS 환경에 Rookie를 배포했습니다. Strands Agents 프레임워크로 에이전트를 구현하고 Amazon Bedrock을 통해 LLM을 연동했으며, Jira, Slack, CMDB(Configuration Management Database, 구성 관리 데이터베이스), CI/CD 등 사내 시스템은 MCP 서버로 연결했습니다.

Rookie는 AWS 계정 접근 권한 요청 또는 각 리소스 담당자를 조회하는 등의 요청이 Jira로 접수되면 담당자 승인 후 자동으로 처리했습니다. 데이터베이스 전문 에이전트 DB DOSA는 쿼리 검증과 스키마 변경 영향도 검토 등 DB 운영 업무를 지원했으며, DB 부하 분석 시간을 건당 10분에서 2분으로 단축했습니다. 운영 업무 자동화와 DB 부하 분석에서 절감한 운영 시간은 연간 약 209시간에 달하는 성과를 보였습니다.

팀은 이후 Rookie의 활용 범위를 AWS 리소스 상태와 이벤트, Datadog 메트릭과 로그를 활용한 알람 분석으로 넓혔습니다. 하지만 1차 분석을 빠르게 제공하는 것과 근본 원인을 규명하는 것은 별개의 문제였습니다. 에이전트의 응답 282건 중 68.4%에 추가 확인 요청이나 미확인 사항이 포함되어 있었습니다. 초기 정보 수집은 빨라졌지만, 근본 원인 후보를 검증하고 조사 범위를 좁히는 일은 여전히 담당자의 몫이었습니다.

이 간극을 자체 개발만으로 해결하려면 과거 장애 분석을 활용할 지식 베이스를 관리하고, 서비스별 예외와 새로운 알람 유형에 맞춰 프롬프트를 개선해야 했습니다. 또한 모델이나 프레임워크 버전을 업데이트할 때마다 분석 품질을 검증해야 하는 부담도 있었습니다.

팀은 이러한 이유로 Rookie의 역할을 계속 확장하는 대신, 기존 업무 자동화와 심층 조사를 분리하기로 했습니다. Rookie는 운영자의 접점과 업무 자동화를 담당하고, AWS DevOps Agent는 장애 원인을 추적하는 심층 조사를 전담하는 구조입니다.

왜 AWS DevOps Agent였나

AWS DevOps Agent는 알람이나 티켓을 기반으로 텔레메트리, 코드, 배포 데이터를 연관 분석해 근본 원인과 완화 방안을 제시하는 AWS의 관리형 에이전트입니다. 티맵모빌리티는 자체 개발 부담을 줄이면서도 사내 도구와 운영 노하우를 활용할 수 있는지에 주목했습니다. 선택 기준은 다음 세 가지였습니다.

서비스 의존 관계의 자동 파악과 갱신

Rookie가 서비스 간 의존 관계를 분석에 활용하려면 팀이 해당 정보를 프롬프트나 지식 베이스에 반영하고, AWS 환경의 구성 변경에 맞춰 매번 수동으로 갱신해야 한다는 어려움이 있었습니다.

AWS DevOps Agent는 연결된 AWS 환경에서 실제 구동 중인 리소스와 의존 관계를 스스로 파악해 클라우드 토폴로지(Topology)를 자동으로 구성하고 갱신해 줍니다. 이처럼 팀이 AWS 리소스 구조를 직접 관리하는 부담을 줄이면서도, 알람이 발생한 리소스 주변의 의존성까지 심층 조사에 자동으로 연계해 활용할 수 있다는 점이 핵심적인 도입 이유였습니다.

장애 지식의 자동 축적과 중복 알람의 자동 분류

Rookie에서는 과거 장애 분석 결과를 재활용하기 위해 팀이 지식 베이스를 직접 구축하고 관리해야 했습니다. AWS DevOps Agent는 Memories 기능을 통해 매번 수행된 조사 결과와 AWS 환경 정보를 시스템에 지속적으로 축적하고, 이를 다음 후속 조사에 실시간으로 연계하여 활용합니다.

백그라운드에서 동작하는 Learning agent는 Agent Space와 최근 조사 데이터를 실시간으로 분석해 메모리를 스스로 생성하고 갱신하며, 엔지니어가 제공한 피드백까지 함께 반영합니다. 이는 모델 자체를 매번 재학습하는 것이 아니라, 조사 과정에서 얻은 컨텍스트를 다음 조사 시점에 자동으로 참조하는 방식입니다.

또한 새로운 알람이 인입되면 Triage 단계에서 현재 진행 중인 조사와의 관련성을 자동으로 판단하고, 동일한 원인의 장애로 확인되면 기존 조사 프로세스에 즉각 연결합니다. 팀은 이러한 자동화 기능을 통해 조사 지식을 수동으로 관리하는 리소스를 아끼고, 중복 알람을 분류해야 하는 운영 부담을 크게 줄이고자 했습니다.

기존 도구와 운영 노하우의 재사용

관리형 서비스를 도입하더라도 기존 사내 시스템과 팀의 조사 절차는 그대로 활용할 수 있어야 했습니다. AWS DevOps Agent는 Skills를 통해 팀의 고유한 조사 절차를 정의하고, Custom MCP 서버를 통해 사내 시스템을 유기적으로 연결하는 기능을 제공합니다.

팀은 기존에 Rookie가 사용하던 MCP 서버를 그대로 재사용하고, 과거 프롬프트에 담아두었던 팀만의 조사 노하우를 Skills로 이관했습니다. 이로써 사내 도구 연동과 환경별 조사 절차 같은 핵심 도메인 지식은 팀이 주도적으로 관리하되, 심층 조사에 필요한 AI 모델의 고도화나 에이전트 실행 인프라의 유지·관리는 AWS 관리형 서비스에 완전히 맡기는 구조를 완성했습니다. 기존에 개발해 둔 자산을 100% 재활용하면서도, 직접 개발하고 운영해야 하는 인프라 부담을 획기적으로 줄일 수 있다는 점이 AWS DevOps Agent를 선택한 핵심 이유였습니다.

티맵모빌리티의 AIOps 아키텍처

티맵모빌리티는 Rookie를 운영자의 접점으로 유지하고, AWS DevOps Agent를 심층 조사에 연결했습니다. Rookie는 Slack과 Jira에서 요청을 받아 여러 에이전트에 조사를 맡기고 결과를 비교합니다. DevOps Agent는 연결된 AWS 계정의 리소스 관계와 조사 도구를 활용해 장애 원인을 추적합니다.

[그림 1] 티맵모빌리티의 AIOps 아키텍처

Step 1~3: 알람이 들어오면 Rookie는 서비스, 발생 시각, 증상을 정리해 사내 Custom MCP인 Frontier를 호출합니다. Frontier는 AWS DevOps Agent API를 MCP 도구로 감싼 어댑터로, Investigation 요청과 상태 확인, 결과 및 조사 기록 조회 기능을 제공합니다.

Step 4~5: Rookie는 같은 알람을 Datadog Bits AI에도 보내 병렬로 조사하고, DB 관점의 확인이 필요하면 사내 에이전트 DB DOSA를 활용합니다.

Step 6~8: DevOps Agent의 Agent Space에는 조사 대상 운영 계정을 연결했습니다. DevOps Agent는 이 계정들의 리소스와 의존 관계를 조사에 활용하고, 필요한 관측 데이터와 변경 이력은 Custom MCP 도구에서 조회합니다. Datadog도 Custom MCP로 연결해 Rookie와 DevOps Agent가 함께 사용하도록 했습니다. 이 경로에서는 실제 호출 여부와 요청·응답, 권한 오류를 팀의 로그로 확인할 수 있습니다. DevOps Agent가 프라이빗 서브넷의 MCP 서버에 접근하는 경로는 Amazon VPC Lattice 기반 Private Connection으로 구성했습니다.

Step 9: 완료된 Investigation의 결과와 조사 기록은 다음 장애를 분석할 때도 활용합니다. Rookie를 비롯한 다른 에이전트들은 이전 조사에서 확인한 원인과 근거를 조회해 새 알람과 비교합니다. DevOps Agent의 조사 기록이 여러 에이전트가 참조하는 공통 Knowledge Base 역할을 하는 셈입니다.

Step 10~13: Rookie는 이번 조사에서 DevOps Agent와 Bits AI가 살펴본 대상, 시간 범위, 근거도 비교합니다. 그 결과를 HTML 리포트로 정리해 Amazon S3에 저장하고, Amazon CloudFront로 제공되는 링크를 Slack에 전달합니다. 운영자는 알람을 받은 자리에서 결론과 판단 근거를 확인할 수 있습니다.

DevOps Agent의 조사 품질 고도화

Custom MCP로 사내 시스템들을 연동한 후, 티맵모빌리티는 사내 인프라 환경과 운영 노하우를 담은 컨텍스트를 Skill 형태로 제공했습니다. 에이전트가 단순 알람 증상 확인에 그치지 않고, 제공된 사내 컨텍스트와 인프라 변경 이력을 연관 분석해 실제 장애 원인까지 정확히 추적하도록 하기 위함입니다.

AWS 표준 트러블슈팅 절차를 통한 인프라 원인 추적

티맵모빌리티의 대부분 워크로드는 Amazon EKS 위에서 동작합니다. 과거 EKS 환경에서 노드를 효율적으로 재구성하는 Karpenter의 Consolidation(비용 기반 노드 최적화) 작업 도중 서비스가 일시 중단되는 장애가 발생한 적이 있었습니다. 당시 사내 에이전트인 Rookie와 Skill을 적용하기 전의 DevOps Agent는 애플리케이션의 에러 로그만 확인할 뿐, 이 장애가 Karpenter의 노드 정리 작업 때문에 발생했다는 인프라적 인과관계까지는 밝혀내지 못했습니다.

AWS 서비스에서 복잡한 인프라 문제가 발생했을 때, 에이전트의 단독 추론만으로 정확한 원인을 찾아내는 것은 한계가 있습니다. 이에 팀은 AWS 공식 오픈소스로 제공되는 sample-ai-agent-skills를 활용했습니다. 이 오픈소스는 검증된 지식 기반의 구조화된 런북, 체계적인 조사 워크플로우 등을 제공하여 AWS 인프라 문제 조사 절차에 최적화된 환경을 지원합니다. 이에 팀은 티맵모빌리티의 주 워크로드 환경인 EKS 장애를 해결하고자 해당 오픈소스 내에서 eks-troubleshooting Skill을 선택해 적용했습니다. 이 스킬에는 파드 및 노드의 상태, 클러스터 이벤트 점검은 물론, Karpenter와 같이 EKS 환경에서 자주 발생하는 인프라 문제를 진단할 수 있는 전용 절차가 최적화되어 포함되어 있습니다. 실제로 Karpenter 이슈를 다루는 가이드라인에는 다음과 같은 필수 점검 항목이 정의되어 있습니다.

MUST:
- Check Karpenter logs: `kubectl logs -n kube-system -l app.kubernetes.io/name=karpenter --tail=100`
- Check NodePool resources: `kubectl get nodepools`
- Check NodeClaim status: `kubectl get nodeclaims`

eks-troubleshooting 스킬의 reference 중 Karpenter 관련 내용

이 절차는 에이전트가 애플리케이션 오류에 머무르지 않고, 같은 시각의 파드 상태와 Karpenter의 노드 변경 기록까지 살펴보도록 조사 방향을 넓혀 줍니다. Skill 적용 후 DevOps Agent는 서비스 중단을 Karpenter Consolidation과 연결해 원인으로 식별했습니다. 이 사례는 운영 환경에 맞는 문제 해결 절차를 제공하는 것이 에이전트의 조사 결과를 얼마나 구체화할 수 있는지 보여줍니다.

Argo CD를 통한 서비스 배포 정보와 리소스 추적

알람에는 서비스 이름만 표시되지만, 실제 장애 조사는 그 서비스가 실행 중인 EKS 클러스터, 네임스페이스, 파드(Pod) 같은 실질적인 인프라 리소스를 대상으로 이루어집니다. 티맵모빌리티는 이 간극을 메우기 위해 DevOps Agent가 Argo CD를 통해 실제 배포 컨텍스트를 직접 조회할 수 있도록 세 가지 Custom MCP 도구를 직접 개발해 에이전트에게 공급했습니다.

• 실제 배포 위치 식별 (search_argocd_applications): 알람이 발생한 서비스가 수많은 계정 중 어떤 EKS 클러스터와 네임스페이스 환경 위에 배포되어 있는지 정확한 주소를 찾아냅니다.
• 실시간 인프라 리소스 트리 파악 (get_argocd_resource_tree): 해당 서비스와 연결된 Deployment, Service, 파드(Pod) 등의 상하 관계와 실시간 리소스 구성을 한눈에 파악합니다.
• 장애 전후의 변경 이력 추적 (get_argocd_revision_metadata): 가장 최근에 배포된 소스 코드 Revision 메타데이터를 조회하여, 최근 변경 사항이 장애를 유발했는지 검증할 출발점을 확보합니다.

이처럼 배포 정보의 원천인 Argo CD를 Custom MCP 도구로 엮어 제공함으로써, 에이전트가 조사해야 할 리소스와 변경 이력의 범위를 정확하게 좁힐 수 있도록 지원했습니다.

Custom MCP와 Skill로 도구 사용 기준 정하기

티맵모빌리티는 Datadog, Argo CD, 변경관리, CI/CD 등 장애 조사에 필요한 다양한 사내외 시스템을 Custom MCP 도구로 연결했습니다. 하지만 데이터 접근 수단을 제공하는 것만으로는 에이전트가 사내 표준 절차에 맞춰 유기적으로 조사하도록 강제할 수 없습니다. 수집된 단편적인 데이터들을 어떤 순서로 조합하고 원인 분석에 연계할지 명확한 지침이 필요했습니다.

팀은 이 조사 가이드라인을 DevOps Agent의 Skill에 명시했습니다. Custom MCP가 사내 시스템에서 데이터를 가져오는 ‘도구’라면, Skill은 그 데이터들을 엮어 지도를 완성하는 ‘추론 지침’입니다. 팀은 에이전트가 인프라 데이터와 소프트웨어 형상을 유기적으로 교차 검증할 수 있도록 다음과 같은 표준 런북을 주입했습니다.

## 1. 배포 리소스 확인
- search_argocd_applications로 관련 애플리케이션을 찾는다.
- get_argocd_resource_tree로 연결된 리소스를 확인한다.
- get_argocd_revision_metadata로 최근 배포 revision을 확인한다.

## 2. 변경관리 확인
- jira_search로 변경 관리 프로젝트를 검색한다.
- 관련 서비스와 장애 발생 전후 시간대를 기준으로 조회한다.
- 변경 내용·대상 시스템·작업 시각의 연관성을 확인한다.

## 3. 서비스 의존 관계 확인
- get_service_dependencies에 서비스명과 환경을 전달해 upstream/downstream 관계를 조회한다.
- 반환된 called_by / calls를 바탕으로 연관 서비스와 장애 전파 경로를 확인한다.
- Trace가 존재하면 실제 오류 호출을 추가로 조사한다.

DevOps Agent에 적용한 리소스 및 변경 이력 조사 지침 관련 Skill

결과적으로 티맵모빌리티는 인프라 문제 해결 절차, 배포 정보, 사내 도구 가이드라인을 하나로 융합하여 DevOps Agent가 단순 알람 증상에서 시작해 연관 리소스와 구체적인 장애 원인까지 스스로 추적해 나가는 고도화된 장애 대응 체계를 완성했습니다.

조사 사례: HTTP 500 알람에서 Aurora 스케일 다운 작업까지

앞서 커스텀한 운영 데이터와 조사 지침이 실제 장애 현장에서 어떻게 활용되었는지, HTTP 500 알람 인시던트 대응 과정을 통해 살펴보겠습니다. DevOps Agent는 개별 애플리케이션 오류에서 시작해 공통 DB 연결 문제로 장애 원인 후보를 좁혔고, 최종적으로 장애 직전의 변경 작업에 의한 것임을 확인해 냈습니다.

애플리케이션 로그에서 DB 연결 문제 식별

Datadog에서 특정 서비스의 HTTP 500 오류 급증 알람이 발생하자, Rookie는 해당 콘텍스트를 수집하여 즉각 DevOps Agent에 조사를 요청했습니다. DevOps Agent는 제공된 Custom MCP 도구로 애플리케이션 로그에서 다음 오류가 반복되는 것을 확인했습니다.

HikariPool - Connection is not available, request timed out after 3000ms
Communications link failure

첫 번째 로그는 애플리케이션이 DB 커넥션 풀(Connection Pool)에서 제한 시간 내에 연결을 획득하지 못했음을 뜻하며, 두 번째 로그는 실제 데이터베이스와의 통신 연결이 끊어졌다는 신호입니다. 1차 정보 수집을 통해 HTTP 500 오류가 단순 코드 결함이 아닌 DB 연결성과 밀접한 관련이 있다는 사실을 파악했으나, 로그만으로는 연결이 끊어진 근본 원인을 규명할 수 없었습니다.

다중 알람 연관 분석을 통한 공통 원인 추적

DevOps Agent는 내장된 자율 인시던트 분석 기능에 따라 장애 발생 시점과 겹치는 같은 시간대의 Datadog 알람 전체를 교차 조회했습니다. 이 과정에서 독립된 다른 마이크로서비스들에서도 동시에 헬스 체크 타임아웃 경보가 울리고 있다는 중요한 단서를 발견했습니다.

여러 서비스에 동시다발적으로 나타난 인프라적 증상은 개별 컨테이너의 문제가 아닌, 이들이 공유하는 공통 인프라 자원에 결함이 생겼음을 시사합니다. 이에 에이전트는 사내 배포 정보와 토폴로지를 기반으로 이 서비스들이 공통으로 바라보고 있는 Aurora MySQL 클러스터를 타깃 리소스로 특정하고, 클러스터 상태와 Writer/Reader 노드 구성을 역추적하기 시작했습니다. 서비스 알람 하나에서 출발하여 여러 시스템의 공통 의존성을 확인하며 장애 원인의 범위를 정확히 좁혀간 것입니다.

변경 이력 분석을 통한 근본 원인 도출

DevOps Agent는 사내 Jira 변경관리 기록을 탐색하여, 장애 발생 직전에 승인 및 수행된 ‘Aurora 인스턴스 스케일 다운(Scale-down)’ 인프라 작업 티켓을 찾아냈습니다. 에이전트가 데이터들을 조합해 최종 타임라인별로 구성한 인과관계는 다음과 같습니다.

Aurora 스케일 다운 및 페일오버(Failover) 진행 → 기존 DB 물리 연결 강제 단절 → 애플리케이션의 신규 커넥션 획득 실패 → 인입 요청 처리 불능으로 인한 HTTP 500 오류 대량 발생

애플리케이션 로그로 장애의 ‘증상’을 인지하고, 주변 알람 분석으로 조사할 ‘대상 리소스’를 확정했으며, Jira 변경 이력을 통해 장애를 유발한 ‘물리적 이벤트’를 최종 검증한 것입니다. 에이전트는 분산된 시스템의 데이터를 유기적으로 연결하여 무관해 보이던 HTTP 500 알람의 진짜 원인이 Aurora 변경 작업에 있었음을 추적했습니다.

[그림2] html 조사 리포트 예시

도입 효과: 초기 조사는 AI가, 운영자는 검증과 의사결정에 집중

AWS DevOps Agent 도입 이후 티맵모빌리티 DevOps 팀이 마주한 가장 큰 변화는 장애 대응의 패러다임 전환입니다. 엔지니어가 알람을 인지한 후 여러 연동 시스템을 일일이 방문하여 로그와 변경 이력을 직접 수집하던 과거의 방식에서 벗어나, 이제는 전문 에이전트가 단 몇 분 만에 구성해 둔 통합 조사 리포트를 검토하며 곧바로 의사결정과 복구 작업을 시작하는 구조로 진화했습니다.

526건의 자율 심층 조사 수행, 평균 17분 만에 결과 제공

티맵모빌리티는 약 7주간의 안정화 기간 동안 Rookie를 통해 AWS DevOps Agent에 총 526건의 심층 조사를 요청했습니다. 기존에 엔지니어가 장애 인지 후 원인 정리 및 리포트 작성까지 건당 평균 1시간을 소요한다고 가정했을 때, 하루 8시간 기준 약 66인일(526시간)에 달하는 방대한 규모의 조사 준비 작업을 에이전트가 백그라운드에서 자율적으로 처리해준 셈입니다.

이 기간 동안 AWS DevOps Agent가 복잡한 인프라 데이터를 연관 분석해 결과를 도출하는 데 걸린 평균 조사 완료 시간은 단 17분이었습니다. 특히 야간이나 휴일 등 담당 엔지니어가 PC 앞에 앉아 업무 환경에 접속을 준비하는 골든 타임 동안에도 조사가 선제적으로 진행되므로, 정보 수집에 따르는 리소스 부담이 극적으로 줄었습니다.

전체 요청의 약 77%에서 검토할 원인 확보

전체 조사 요청 526건 중 AWS DevOps Agent가 구체적인 근본 원인을 특정해 제시한 케이스는 323건이었습니다. 타 에이전트들의 병렬 분석 데이터까지 결합한 통합 리포트 기준으로는 전체 요청의 약 77%에 달하는 405건에서 즉시 검토 가능한 수준의 원인 가설과 근거가 확보되었습니다.

이 수치는 운영자가 처음부터 원인을 찾아 헤매는 대신, 에이전트가 정리해 준 가설과 근거를 검토하며 곧바로 복구 작업을 시작할 수 있었음을 뜻합니다. 엔지니어의 역할이 파편화된 정보를 수집하는 반복 작업에서, 리포트를 바탕으로 판단을 내리고 조치를 선택하는 일로 바뀐 것입니다.

중복 알람 분류 자동화 및 인시던트 맥락 연결

실시간 모빌리티 환경에서 무수히 쏟아지는 중복된 알람을 분류하여 효율성도 크게 개선되었습니다. 전체 조사 요청 중 94건은 이미 진행 중인 기존 조사 프로세스에 시스템이 자동으로 병합했습니다.

동일한 장애 원인으로 발생하는 다량의 알람을 매번 별개의 인시던트로 인지해 처음부터 다시 조사하던 비효율을 완벽히 제거한 것입니다. 에이전트가 이전의 장애 기록을 후속 분석에 적극적으로 활용하면서, 팀은 불필요한 확인을 줄이고 인시던트의 전체 맥락을 지속해서 이어가며 실시간 서비스의 연속성을 한층 더 단단하게 확보할 수 있게 되었습니다.

마무리

티맵모빌리티는 사내 AI 에이전트 기반 운영 워크플로우에 AWS 인프라 분석 전문 매니지드 에이전트인 AWS DevOps Agent를 결합했습니다. 파편화된 사내 시스템들을 Custom MCP로 하나로 연결하고 사내 인프라 컨텍스트를 주입함으로써, 장애 조사 시간을 획기적으로 줄이고 운영 효율성을 극대화했습니다.

AIOps 체계 구축 과정의 핵심 교훈은 세 가지입니다.

• 관리형 서비스와 검증된 리소스 활용: 에이전트 인프라의 자체 개발·유지보수 부담은 AWS 관리형 서비스에 맡겨 운영 공수를 덜어내고, 복잡한 인프라 진단에는 AWS가 공식 오픈소스로 제공하는 검증된 트러블슈팅 자원을 활용할 수 있습니다.
• 사내 인프라 메타데이터 결합을 통한 조사 품질 향상: 형상 관리 및 배포 정보의 원천이 되는 사내 인프라 메타데이터를 에이전트의 추론 지침과 결합해야 실제 환경 변화와 변경 원인까지 추적하는 맞춤형 조사 품질을 확보할 수 있습니다.
• 운영 연동 시스템과의 워크플로우 통합: 에이전트를 별도의 도구로 분리하지 않고 Jira, Slack, Datadog 등 기존 운영 워크플로우 안에 자연스럽게 녹여낼 때, 여러 도구를 오가는 탐색 시간을 줄이고 실제 운영 효율성을 극대화할 수 있습니다.

기존 AIOps 환경에서 AWS DevOps Agent를 연계한 활용 방안을 고민하고 있는 유사한 사례가 있다면, 티맵모빌리티의 이번 구축 경험이 실질적인 도움이 되기를 바랍니다.