티오더 시스템이 가진 과거의 문제

티오더는 스타트업으로서 폭발적인 성장을 이뤘지만, 인프라 운영 측면에서는 큰 도전 과제에 직면했었다. 티오더는 10개의 쿠버네티스 클러스터와 300개의 워크로드를 관리하고 있었고, 수많은 포스(POS)사와의 연동을 처리해야 하기 때문에 시스템이 복잡했다.

티오더 시스템 운영팀의 가장 큰 고민은 장애 대응에 너무 많은 시간과 비용이 든다는 점이었다. 기존 운영 방식은 문제 발생 후에야 대응하는 사후적 구조였다. 비개발자는 로그·지표를 이해하기 어렵고, 개발자와 운영팀은 문제 원인이 서비스인지 인프라인지 빠르게 판단하기 힘들었다. 그 결과 대응 속도는 늦어지고 책임·원인 논의가 길어졌다.

예를 들어 장애가 발생할 경우, 각 서비스별로 구축된 ELK (Elasticsearch,Kibana, Beats, Logstash) 스택의 로그를 일일이 뒤져야 했다. 이런 방식으로 인해 장애 대응 시간의 70%를 로그 검색에 썼고, 20%는 소통과 책임 소재 파악에 허비했다. 정작 실무자가 문제를 해결하는 시간은 10%에 불과했다. 개발과 운영을 동시에 해야 하는 상황에서 가시성 부족은 지속적인 장애 대응의 걸림돌이었다. CloudWatch, Grafana, ELK 등 여러 툴을 오가며 장애 지점을 찾아야 했고, 서비스가 늘어날수록 전체 상태를 파악하는 데 더 많은 시간이 들었다. 서비스가 급격하게 늘어나면서 가시성이 현저히 떨어졌고, 장애 시간도 그만큼 늘어날 수밖에 없었다.

티오더는 일반 이용자(B2C)와 매장 점주(B2B)가 함께 사용하는 시스템이다. 주문 서비스가 단 몇 분만 중단돼도 고객인 매장의 매출과 운영 전반에 타격이 크다. 이 때문에 안정성과 신뢰성 확보가 티오더 운영의 핵심 과제로 떠올랐다.

사후 대응 대신 선제적 대응 체계로

티오더는 빠르게 확장되는 서비스 구조 속에서 장애 대응과 운영 효율성에 한계가 명확해지자, 기존의 방식에서 벗어나 새로운 운영 체계를 구축해야 한다는 결론에 도달했다. 가장 먼저 해결해야 할 과제는 흩어져 있는 로그와 모니터링 시스템을 중앙화하고, 문제 탐색에 소모되는 시간을 줄이는 것이었다.

또 하나의 핵심 과제는 수백 개의 분산 서비스에 대한 명확한 식별과 추적 체계 구축이었다. 서비스 증가로 인해 어느 팀이 어떤 서비스를 관리하는지, 어떤 환경과 클러스터에서 실행되고 있는지 파악하기 어려워졌고, 이는 장애 분석 속도에 직접적인 악영향을 미쳤다. 따라서 서비스별로 고유 ID, 팀, 환경, 카테고리, 클러스터명 등을 포함한 일관된 메타 태그 체계를 마련해 운영 전 과정에서 공통 기준으로 삼을 필요가 있었다.

더불어 티오더는 사후 대응 중심의 운영 방식에서 벗어나 선제적으로 이상을 감지하고 대응할 수 있는 체계를 마련해야 했다. 문제 발생 후 로그를 뒤져 원인을 찾는 방식은 서비스 규모가 커질수록 실효성이 떨어졌다. 장애가 발생하는 순간 즉시 관련 팀에 전파되어 인프라 문제인지 애플리케이션 문제인지 빠르게 분리할 수 있는 능동적 모니터링 체계가 필요했다.

마지막으로, 장애 대응 과정에서 반복적으로 발생하는 불필요한 커뮤니케이션 비용을 줄이고 책임과 역할을 명확히 분리하는 구조가 필요했다. 문제의 요약, 심각도 분석, 해결 방법이 자동화되어야 개발팀과 운영팀이 각각 본연의 업무인 개발과 운영 최적화에 집중할 수 있다. 이를 위해 티오더는 알람을 정제하고, 필요한 알람만 전달하며, 메시지 자체에 해결 조언을 포함할 수 있는 체계를 구축하는 것을 중요한 과제로 삼았다.

Datadog을 기반으로 한 성과

티오더는 이 같은 문제 해결을 위해 다양한 오픈소스 모니터링 도구들을 비교·검토한 끝에 Datadog을 도입하기로 결정했다. Datadog이 서비스 구조와 장애 요소를 가장 명확하게 가시화해 주는 도구였기 때문이다. 이전에는 CloudWatch, Grafana, ELK 등 여러 툴을 오가며 지표와 로그를 각각 확인해야 했지만, Datadog은 이러한 관측 요소를 한 화면에서 통합적으로 보여줄 수 있는 유일한 솔루션이었다.

또한 Datadog은 쿠버네티스 환경을 위한 헬름 차트(Helm Chart) 기반의 간편한 설치·구축 방식을 제공해, 티오더가 EKS로 레거시를 전환하는 과정에서 부담 없이 연동할 수 있었다. 티오더는 클러스터별 특성을 통제하기 위해 AppSet을 활용했고, Datadog이 제공하는 태그 기반 검색 기능을 잘 활용하기 위해 메타 태그 체계를 서비스 설계 단계부터 표준화했다. 서비스 ID, 팀, 환경, 서비스명, 카테고리, 클러스터명, 리전 등을 태그로 미리 정의해 두어, 서비스가 어디서 실행되고 어느 팀이 관리하는지 몇번의 클릭만으로 확인할 수 있는 구조를 만들었다.

Datadog의 핵심 강점 중 하나는 통합 대시보드 구성 능력이었다. APM, 에러 로그, 파드 CPU/메모리, 요청 수, 레이턴시, HTTP 4xx/5xx, HPA 상태 등 다양한 정보를 Datadog의 단일 화면에 집약했다.

서비스 간의 연동 관계 파악도 Datadog으로 크게 개선됐다. Datadog이 제공하는 서비스 맵 기능을 활용해 어떤 서비스가 어디와 통신하고 있는지, 트래픽이 어디로 몰리는지, 장애 지점이 어디에서 발생했는지를 시각적으로 확인할 수 있었다. 티오더처럼 외부 연동 서비스가 많은 회사에서는 이러한 관계도가 장애 탐색 속도를 획기적으로 단축시키는 핵심 도구로 활용되었다.

Datadog은 단순 모니터링을 넘어 운영 패러다임 자체를 변화시키는 기반이 되었다. 티오더는 APM, 로그, 인프라 지표를 한곳에서 확인하면서 문제가 인프라 문제인지 서비스 내부 문제인지 즉시 구분할 수 있는 구조를 마련했다. 이로써 개발팀은 본연의 개발에 집중하고, 데브옵스팀은 운영 최적화에 집중하는 역할 분리가 명확한 운영 체계가 구축되었다.

“Datadog만큼 가시화가 잘 되고 장애 요소를 잘 파악되도록 하는 서비스는 없었습니다.”

더 나아가 티오더는 Datadog을 AI 기술인 MCP(Model Context Protocol)와 결합하여 능동적인 장애 대응 시스템을 구축했다. Datadog에서 이상 감지 알림이 발생하면 이를 AWS SNS를 통해 MCP 모듈로 전송하고, AI가 즉시 관련 로그와 트레이스를 분석해 장애 원인과 해결책을 파악하도록 구성했다. 또 분석된 내용을 바탕으로 장애 리포트 초안을 작성하고 지라(Jira) 티켓을 생성한 뒤, Slack으로 요약된 정보를 발송하는 과정까지 자동화했다. 결과적으로 개발자는 문제 발생 시 AI로부터 즉각적인 조언을 받을 수 있게 되어 대응 시작 시간이 2~3분 단축되었고, 전체 문제 해결 속도는 53% 이상 빨라지는 성과를 거두었다.

향후 계획

티오더는 현재 구축한 Datadog 기반 관측 체계와 MCP 자동 대응 시스템을 한 단계 더 고도화해, 전사적인 운영 효율과 안정성을 강화한다는 계획을 세우고 있다. 지금까지는 주로 APM·로그에 대한 수집과 분석 중심으로 시스템을 구성해 왔지만, 앞으로는 Datadog의 활용 범위를 더욱 넓혀 더 많은 알림 시나리오와 이상 징후 감지 모델을 확장 적용할 계획이다. 이를 통해 서비스 전반에 걸친 위험 요소를 더 빨리, 더 정확하게 탐지할 수 있는 환경을 구축하겠다는 목표다.

또한 모니터링의 통합성을 높이기 위해, 현재 AWS CloudWatch에서 확인하고 있는 매니지드 서비스들의 모니터링 지표들까지 모두 Datadog으로 이관하여 관리 범위를 넓힐 계획이다. 기술적인 측면에서는 현재 오픈 소스로 구성된 자체 MCP 서버를 향후 Datadog 공식 지원 MCP 모듈로 전환하여 시스템을 발전시키고, 웹사이트상에서 AI를 활용한 탐색 기능을 내부적으로 더욱 강화할 예정이다.

티오더가 추구하는 궁극적인 목표는 단순히 알람의 개수를 줄이는 것이 아니라, 분석과 조언을 포함한 ‘진짜 필요한 알림’만 효과적으로 전달되게 해 생산적인 운영 환경을 지속적으로 구축해 나가는 것이다.