241020 Datadog으로 완성하는 AWS 모니터링 끝판왕 세미나 후기

Datadog AWS 모니터링 세미나 후기: Observability부터 DevSecOps까지

회사 동료분 덕분에 'Datadog으로 완성하는 AWS 모니터링 끝판왕'이라는 흥미로운 세미나에 다녀왔다. 마침 우리 팀에서 Sentry라는 에러 모니터링 툴을 막 도입했던 시기여서 더욱 유익한 시간이었다. 이번 세미나에서 얻은 인사이트를 현재 팀에서 사용하는 Sentry와 비교하며 정리해 보았다.

1. 기본 다지기: AWS 환경에서의 Observability

첫 세션은 AWS Startup Partner Solution Architect이신 권기훈 님의 'AWS 환경에서의 Observability' 발표였다.

실패는 기본값: "Everything fails, all the time"

"모든 것은 언제나 실패합니다."

발표는 아마존 CTO 버너 보겔스(Werner Vogels)의 유명한 이 한마디로 시작되었는데 클라우드 환경의 복잡성이 기하급수적으로 증가하는 오늘날, 실패는 예외가 아닌 상수라는 점을 다시 한번 깨닫게 하는 말이었다. 그렇다면 우리는 이 변화무쌍한 시스템의 내부를 어떻게 들여다보고 이해해야 할까? 그 답이 바로 'Observability(관찰 가능성)' 에 있었다.

Observability란 무엇인가?

Observability는 시스템의 내부를 직접 보지 않고도, 외부로 드러나는 출력(로그, 메트릭, 트레이스 등)을 통해 시스템의 내부 상태를 얼마나 잘 추론할 수 있는지를 나타내는 능력이다. 단순히 '모니터링'을 넘어, 복잡한 워크로드의 가시성을 확보하고 , 장애를 빠르게 해결하며, 궁극적으로는 더 나은 개발 환경과 사용자 경험을 만들어 이익을 창출하는 데 그 중요성이 있다.

Observability를 구성하는 핵심적인 세 가지 요소(3 Pillars)는 다음과 같다.

• Logs: "무슨 일이 있었나?"에 대한 답. 이벤트에 대한 타임스탬프가 찍힌 텍스트 레코드이다.
• Metrics: "시스템 상태가 어떤가?"에 대한 답. 시간 경과에 따라 측정된 시스템의 상태를 나타내는 숫자 값이다.
• Traces: "요청이 어디를 거쳐 갔나?"에 대한 답. 분산 시스템 환경에서 사용자 요청의 전체 여정을 추적하여 성능 병목 지점을 찾아낸다.

AWS 환경에서의 Observability 구현 패턴

권기훈 님은 AWS 환경에서 Observability를 구현하는 세 가지 주요 패턴을 소개해 주셨다.

1. Pattern #1. AWS Native 도구 활용: Amazon CloudWatch, AWS X-Ray 등 AWS가 제공하는 서비스를 사용하는 방식이다. 다른 AWS 서비스와 쉽고 빠르게 연동할 수 있다는 큰 장점이 있다.
2. Pattern #2. OpenSource와 조합: Prometheus, Grafana, OpenTelemetry 등 오픈소스와 AWS의 관리형 서비스를 조합하는 방식이다. 더 높은 유연성과 커스터마이징이 가능하며 비용 효율적인 구성이 가능하다는 장점이 있다.
3. Pattern #3. Custom Architecture (feat. Datadog): Datadog과 같은 전문 솔루션을 활용하여 아키텍처를 구성하는 방식. 각 목적에 특화된 강력한 기능과 높은 수준의 통합 환경을 제공한다.

세션을 마무리하며, 더 깊이 있는 학습을 원하는 사람들을 위해 AWS Startup Bootcamp 라는 유용한 사이트도 소개해 주셨다. 이곳에 AWS 모니터링과 관찰 가능성의 기초 이론부터 직접 따라 해 볼 수 있는 실습 자료까지 잘 정리되어 있다고 한다.

2. 실전편: VoC부터 보안까지

이론을 배웠으니 이제 실전이다. 두 번째 세션은 Datadog의 조용원 Sales Engineer님께서 스타트업 개발자의 실제 사례를 통해 Datadog이 어떻게 문제를 해결하는지 보여주는 데모로 진행되었다.

막막한 VoC(고객의 소리), 어디서부터 시작할까?

"저는 지금 지방 출장 중에 급하게 서비스를 이용하려는데 결제가 도무지 안되네요. 도저히 사용하지 못하겠습니다."

개발자라면 등골이 오싹해지는 이런 고객 문의. 무엇부터 살펴봐야 할까? 수많은 로그와 메트릭, 모니터링 툴을 언제 다 뒤져볼까? 테스트 환경에서는 잘 동작하고, 운영 환경에서도 재현이 안 되는 상황. Datadog은 이 막막한 상황을 해결하기 위한 명쾌한 스텝을 제시할 수 있다고 설명하셨다.

STEP 1 & 2: RUM과 Session Replay로 상황 재현하기

먼저 RUM(Real User Monitoring) 의 Session Explorer에서 사용자 이메일, 접속 국가, 도시 등의 정보로 문제의 세션을 정확히 찾아낸다. 데모에서는 전주(Jeonju)에서 접속한 jesse.garcia@example.io 사용자를 특정했다.

그러고 나서 Session Replay 기능으로 사용자가 겪은 상황을 동영상처럼 그대로 재현한다. Session Replay 기능을 사용하면, 마치 동영상처럼 사용자가 겪은 상황을 그대로 재현해 볼 수 있다. 사용자가 어떤 버튼을 클릭했고, 화면에 "Something went wrong. Please try again." 이라는 에러가 어떻게 표시되었는지 명확하게 확인할 수 있었다.

STEP 3 & 4: Trace, Metric, Log로 원인 파고들기

Session Replay 하단의 개발자 도구와 유사한 화면에서 에러가 발생한 백엔드 API 호출을 바로 식별할 수 있다. 여기서 Datadog의 진정한 강점이 드러난다.

프론트엔드의 요청부터 시작해 어떤 백엔드 서비스들을 거쳐 어디서 에러가 발생했는지

1. End-to-End Trace: 에러가 발생한 API 호출을 클릭하면, 프론트엔드의 요청부터 시작해 어떤 백엔드 서비스들을 거쳐 어디서 에러가 발생했는지 Flame Graph로 한눈에 보여준다.

2. Unified View: 이 Trace 화면에서 탭 전환 한 번으로 관련된 Logs, Infrastructure Metrics, Network, SQL Queries 정보까지 모두 확인할 수 있다. 데모에서는 관련 로그를 확인하여 "Payment rejected for transaction due to number of API calls per minute exceeding 1000" 라는, 분당 API 호출 수가 1,000회를 초과하여 결제가 거부된 명확한 원인을 찾아냈다.

💡 개인적인 생각: RUM, Session Replay 이 두 기능은 Sentry에서도 가능하다. 센트리에서는 setUser를 통해 유저 정보를 센트리에 넘겨주면 이후에 대시보드나 이슈 페이지에서 확인이 가능하다. 또한 Session Replay 기능은 Sentry의 Replays 기능과 거의 동일해서 익숙했다. 현재 우리 팀이 사용하는 센트리(Sentry)에서도 프론트엔드와 백엔드 트레이스를 연동해 두었는데, 과연 이 정도로 매끄럽게 하나의 Trace로 연결하여 보여주고, 관련된 서버의 CPU/Memory 메트릭이나 전체 로그 스트림까지 같은 화면에서 바로 확인할 수 있을지는 꼭 확인해봐야겠다는 생각이 들었다. Datadog은 매핑이 어려운 로그와 트레이싱 등을 1:1로 편리하게 매핑하는 점이 큰 장점으로 보였다. 좋았던 점은 어떤 식으로 원인을 파악하고 해결해나가는지 문제를 해결해나가는 매끄러운 흐름을 볼 수 있던 건데, 문제가 발생한 특정 사용자 파악부터 Session Replay를 확인하고 확인된 에러의 백엔드 Trace로 이동하는 것까지의 흐름이 연결되는 게 좋았다. 앞으로 우리 팀에서도 단순히 개별 에러를 확인하는 것을 넘어, '고객 문의 → 사용자 특정 → 세션 재현 → 원인 분석' 으로 이어지는 명확한 트러블슈팅 프로세스를 정립하고 팀의 문화로 장착시키면 좋겠다는 생각을 했다.

기능 이슈는 줄었는데 이제는 성능이... AWS 모니터링 설정하기

기능 이슈를 해결하니 이제는 전반적인 성능 문제가 대두된다. Lambda, Fargate, EKS 등 다양한 AWS 서비스 모니터링은 어떻게 설정할까?

Datadog은 이 과정을 놀랍도록 단순화했다. Datadog UI에서 몇 가지 옵션을 선택하고

CloudFormation 스택 생성 버튼을 누르기만 하면, 필요한 IAM 권한 설정과 AWS 계정 연동이 몇 분 안에 끝난다. 또한 로그 수집이 필요하면 Forwarder Lambda 함수를, 클라우드 보안 설정 진단이 필요하면 CSM(Cloud Security Management)을 옵션으로 활성화할 수 있다.

DBA 없이 RDS 모니터링하기: AI가 해결책까지?

"DB 전문가가 없는데 성능 문제 재발하지 않게 조치해주세요."

스타트업이라면 누구나 겪을 법한 이 상황에 Datadog DBM(Database Monitoring) 은 강력한 해답을 제시한다. DBM은 어떤 쿼리가 느린지, 실행 계획이 비효율적인지 쉽게 파악할 수 있을 뿐만 아니라 , 가장 놀라웠던 것은 AI 기반 해결책 추천 기능이었다.

"Missing Index" 와 같은 문제점을 자동으로 찾아내고 , CREATE INDEX CONCURRENTLY ... 와 같이 바로 실행 가능한 해결책 DDL까지 추천해준다.

💡 개인적인 생각: 이 기능은 정말 충격적이었는데, Sentry에서는 제공하지 않는 기능으로,(아닐수도 있어서 찾아봐야 됨. 하지만 우리가 사용하는 요금제에선 지원 안 하는 것 같다..) DB 전문가가 없는 조직에선 아주 효과적일 것 같다는 생각이 들었다.

이어진 Q&A에서는 프론트엔드에서 수집되는 데이터의 민감정보 처리에 대한 질문이 나왔는데, Datadog은 mask-user-input과 같은 옵션을 통해 수집 단계에서부터 강력한 마스킹 기능을 제공하여 사용자가 원하는 부분만 선택적으로 수집할 수 있도록 지원한다고 한다.

센트리에서도 비슷하게 지원하는 걸로 알고 있다.

3. 마지막 퍼즐: DevSecOps Cycle with Datadog

마지막 세션은 Datadog의 이현진 Sr. Sales Engineer님께서 '보안'이라는 마지막 퍼즐을 어떻게 맞춰나가는지에 대해 이야기해 주셨다.

Datadog은 개발자가 코드를 작성하는 순간부터 보안을 시작할 수 있도록 돕는다.

• IDE 플러그인 (Secure Coding): 개발자가 사용하는 IDE에 플러그인을 설치하면, 코드를 작성하는 실시간으로 보안 취약점(SAST)이나 코드 품질 문제를 찾아 피드백을 준다.
• GitHub 연동 (라이브러리/이미지 검사): GitHub과 같은 코드 저장소와 연동하여, 코드에 포함된 오픈소스 라이브러리의 취약점(SCA)이나 , 컨테이너 이미지의 취약점을 자동으로 검사한다.

💡 개인적인 생각: 린트(Lint) 규칙처럼 코드 퀄리티까지 봐주는 기능에 대해서는 '이게 꼭 필요한가?'라는 생각이 들기도 했지만, 개발 단계에서부터 보안을 내재화한다는 'Shift-Left' 개념에는 깊이 공감했다.

운영 환경에서는 클라우드 설정 오류를 감시하고(CSPM), 실행 중인 워크로드의 위협을 탐지하며(CWS), 모든 보안 관련 데이터를 한곳에 모아(Cloud SIEM) 복합적인 위협을 탐지한다. 이 모든 과정은 개발부터 운영까지 흩어져 있던 보안 데이터를 Datadog이라는 단일 플랫폼으로 통합하여, 개발자와 운영자, 보안 담당자 모두가 같은 그림을 보고 소통할 수 있게 해준다.

세미나를 마치며

'Datadog으로 완성하는 AWS 모니터링' 세미나는 Observability의 기본 개념부터 실제 장애 대응, DB 성능 최적화, 그리고 DevSecOps까지, 현대적인 클라우드 환경을 운영하는 데 필요한 핵심 요소들을 조망해 볼 수 있는 시간이었다.

가장 인상 깊었던 점은 역시 '통합' 이라는 키워드였는데, 프론트엔드 RUM, 백엔드 APM, 인프라, 로그, DB, 그리고 보안까지. 파편화된 데이터를 하나의 플랫폼에서 유기적으로 연결하여 문제의 근본 원인을 빠르게 찾고, 나아가 AI를 통해 해결책까지 제시하는 모습은 개발자로서 매우 매력적으로 다가왔다.

이번 세미나를 통해 Sentry가 에러 트래킹과 프론트엔드 성능 모니터링에 강점이 있다면, Datadog은 인프라를 포함한 시스템 전반의 모든 데이터를 하나로 묶어 분석하는 데 압도적인이라는 생각이 들었다. 내가 센트리를 아직 잘 몰라서 이렇게 느끼는 걸 수도 있지만. 아무튼, 우리 팀의 상황에 맞춰 어떤 도구를 어떻게 활용하는 것이 최선일지 다시 한번 고민해봐야 겠다.