↓ 본문으로 건너뛰기
인재덕
  1. 게시물/

개발자가 실제로 사용하는 모니터링 구축하기

· loading · loading ·
인재덕
작성자
인재덕
A Kiwi living in Korea
목차

“내 컴퓨터에서는 작동한다"와 “프로덕션에서 작동한다” 사이에는 격차가 있습니다. 모니터링은 이 격차를 메워야 합니다. 대부분의 경우 그렇지 못합니다—개발자가 문제가 생겼을 때 찾는 도구가 아니라 운영 도구로 구축되었기 때문입니다.

나쁜 모니터링의 모습
#

도구가 없는 것이 아닙니다. 이런 것입니다:

  • 맹목적 디버깅: 프로덕션 로그에 접근할 수 있었다면 5분이면 될 버그에 개발자가 3시간을 쓴다
  • 고객이 버그를 발견: 알림이 아닌 지원 티켓으로 장애를 알게 된다
  • 알림 피로: 하루 200개 알림, 대부분 무관하여 모두가 전부 무시한다
  • 느린 인시던트 대응: 무언가 고장나고, 처음 30분을 고치는 대신 무엇이 일어났는지 파악하는 데 쓴다

패턴은 매번 동일합니다—모니터링은 존재하지만 개발자가 실제로 일하는 방식과 연결되지 않았습니다.

실제로 필요한 것
#

메트릭, 로그, 트레이스—연결되어야 한다
#

  • 메트릭은 뭔가 잘못되었다고 알려줍니다 (에러율 급증, 레이턴시 증가)
  • 로그는 무슨 일이 있었는지 알려줍니다 (스택 트레이스, 요청 페이로드, 에러 메시지)
  • 트레이스는 어디서 발생했는지 알려줍니다 (어떤 서비스, 어떤 엔드포인트, 어떤 데이터베이스 호출)

이것들은 연결되어 있을 때만 유용합니다. 알림이 발생하면 메트릭에서 관련 로그로, 트레이스로 클릭 스루할 수 있어야 합니다. 개발자가 세 가지 다른 도구에서 타임스탬프를 수동으로 대조해야 한다면 그 구성은 작동하지 않는 것입니다.

개발자가 여는 대시보드
#

대부분의 모니터링 대시보드는 CPU 사용률, 메모리, 디스크 I/O를 보여줍니다. 용량 계획에는 중요하지만 500 에러를 디버깅하는 데는 도움이 되지 않습니다.

다음을 보여주는 대시보드를 만드세요:

  • 기술 메트릭 옆에 비즈니스 메트릭 (에러율과 함께 시간당 가입 수)
  • 타임라인 오버레이에 최근 배포
  • 지난 1시간의 상위 5개 에러와 로그 링크
  • 평균이 아닌 레이턴시 퍼센타일 (p50, p95, p99)

개발자가 자발적으로 대시보드를 열지 않는다면 충분히 유용하지 않은 것입니다.

무엇을 해야 하는지 알려주는 알림
#

모든 알림은 두 가지 질문에 답해야 합니다:

  1. 무엇이 고장났는가?
  2. 어디서부터 살펴봐야 하는가?

나쁜 알림: “web-server-3의 CPU 높음”

좋은 알림: “14:32 이후 /api/payments 에러율 > 5%. 마지막 배포: 14:15 @sarah. [로그 보기] [트레이스 보기]”

도움이 되는 다른 것들:

  • 임계값보다 베이스라인: 임의의 숫자를 넘었을 때가 아니라 정상 동작에서 벗어났을 때 알림
  • 소유권 기반 라우팅: 결제 에러는 전체 조직이 아닌 결제 팀에게
  • 그룹화: 관련 에러 클러스터를 50개 개별 알림이 아닌 하나의 Slack 메시지로

빠른 피드백
#

“무언가 고장남"에서 “개발자가 알게 됨"까지의 시간은 1분 이내여야 합니다. 이는:

  • 실시간 로그 스트리밍 (5분마다 배치 처리가 아님)
  • 릴리스가 문제를 일으켰는지 확인할 수 있는 배포 마커가 있는 대시보드
  • 서비스 경계를 넘어 작동하는 분산 트레이싱

운영이 아닌 개발자를 위한 모니터링 구축
#

DevOps 팀이 저지르는 가장 큰 실수: 자기 자신을 위해 모니터링을 구축하는 것.

개발자와 대화하기
#

도구를 선택하기 전에:

  • 디버깅 세션 중 개발자 옆에 앉아보세요. 무엇을 하는지, 무엇을 검색하는지, 어디서 막히는지 관찰하세요.
  • 인시던트 중 어떤 질문을 하는지 물어보세요. “어떤 서비스?” “무엇이 변했나?” “요청이 어떻게 생겼나?”
  • 제품에 중요한 메트릭을 파악하세요. CPU가 아니라 체크아웃 완료율, 검색 레이턴시, 파일 업로드 성공률 같은 것.

마찰 제거
#

새 서비스를 계측하는 데 하루가 걸리면 개발자는 하지 않을 것입니다. 다음을 제공하세요:

  • 일반적인 프레임워크(Django, Express, Spring)를 자동 계측하는 라이브러리
  • 대시보드와 알림의 복사-붙여넣기 템플릿
  • 티켓 없이도 개발자가 직접 메트릭을 추가할 수 있는 셀프서비스 도구

유지보수성 유지
#

  • 모니터링 설정을 버전 관리에 저장
  • 알림 규칙 테스트—알림이 발생해야 할 때 발생하는지 검증
  • 멀티 리전으로 향한다면 처음부터 계획

팀 규모별 도구 선택
#

AWS 위의 소규모 팀: CloudWatch로 시작
#

50명 미만의 엔지니어이고 AWS에서 운영 중이라면 CloudWatch가 올바른 시작점입니다.

설정 없는 인프라 메트릭: EC2, Lambda, RDS, ECS 모두 자동으로 CloudWatch에 보고합니다. 계측 코드 없이도 가시성을 확보합니다.

저비용: 소규모 팀에 월 $10-50. 고정 플랫폼 비용 없음.

모든 것이 한곳에: 메트릭, 로그, 트레이스(X-Ray 통해), 알람. 도구 확산이 적음.

빠른 셋업: 몇 주가 아닌 몇 시간 만에 의미 있는 알림과 대시보드 구축.

CloudWatch 잘 활용하기
#

  1. CloudWatch Logs Insights는 과소평가되고 있습니다. ElasticSearch 없이도 로그를 쿼리할 수 있습니다:
fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(5m)

  1. 복합 알람으로 노이즈 감소. 에러율이 높고 AND 응답 시간이 저하될 때 알림. 각 조건을 따로가 아니라.

  2. 커스텀 메트릭이 진정한 가치. CloudWatch SDK로 비즈니스 메트릭(가입, 거래, 기능 사용)을 인프라 메트릭과 함께 추적.

  3. CloudWatch Synthetics는 스케줄에 따라 사용자 여정을 시뮬레이션하는 카나리 테스트를 실행. 사용자보다 먼저 중요 경로의 장애를 발견.

  4. X-Ray 통합으로 최소한의 설정으로 분산 트레이싱. 대부분의 마이크로서비스 아키텍처에 충분.

전환할 때
#

CloudWatch의 한계가 보이기 시작하는 때:

  • 멀티 클라우드로 전환할 때
  • 고급 이상 감지가 필요할 때
  • 대시보드 커스터마이징이 어려워질 때
  • 50명 이상의 엔지니어로 더 나은 협업 기능이 필요할 때

대규모 팀: DataDog
#

DataDog는 비쌉니다 (대규모 조직에 연 $20-100K 이상), 하지만 규모에서는 그 값을 합니다.

크로스 플랫폼: AWS, Azure, GCP, 온프레미스, 컨테이너, 서버리스, 데이터베이스, 프론트엔드—모두 하나의 뷰에서 모니터링.

자동 이상 감지: Watchdog가 수동 임계값 설정 없이 비정상 패턴을 감지. 수천 개의 서비스를 수동으로 감시할 수는 없습니다.

팀 협업: 팀별 대시보드, RBAC, 공유 조사 노트북, PagerDuty/Opsgenie 통합.

고급 알림: 다중 조건 알림, 예측(임계값 돌파 시점 예측), 트래픽 패턴에 적응하는 이상 감지, 유지보수 윈도우.

심층 APM: 코드 수준 프로파일링, 트레이스에 연결된 보안 모니터링, 서비스별 비용 귀속, 자동 생성 서비스 맵.

DataDog 도입
#

  1. 작게 시작: 중요한 서비스부터 계측. 태깅으로 팀과 환경별 정리.

  2. 표준을 일찍 설정: 메트릭 명명 규칙, 대시보드 템플릿, 알림 심각도 수준, SLO 정의. 나중의 고통을 크게 줄입니다.

  3. 모든 것과 통합: CI/CD 배포 마커, 인시던트 관리, Slack 알림, ITSM 티켓팅.

  4. 팀 교육: 내부 문서, 팀 챔피언, APM과 프로파일링 워크샵. DataDog는 강력하지만 학습 곡선이 있습니다.

  5. 비용 주시: 노이즈가 많은 메트릭 필터링, 고용량 서비스에서 트레이스 샘플링, 기능 사용 정기 감사, 비용 할당을 위한 태깅.

대안
#

  • New Relic: DataDog와 유사, 고용량 트레이싱에서 더 저렴할 수 있음
  • Dynatrace: AI/AIOps가 강력, 금융 서비스에서 인기
  • Splunk: 로그 분석 최고 수준, 보안용으로 이미 사용 중이라면 특히
  • Grafana Cloud: 오픈소스 친화적, Prometheus/Loki를 이미 쓰고 있다면 최적

하이브리드 접근법
#

많은 팀이 도구를 조합합니다:

  • AWS 네이티브 서비스에는 CloudWatch (자동, 저렴)
  • 애플리케이션과 크로스 플랫폼 가시성에는 DataDog
  • DataDog가 CloudWatch 메트릭을 수집하여 통합 뷰 제공

이것이 가장 실용적인 구성인 경우가 많습니다.

흔한 함정
#

도구 과부하: 잘 연동되는 3개의 도구가 연동되지 않는 6개보다 낫습니다. 모든 모니터링 제품을 도입하지 마세요.

맥락 없는 메트릭: “초당 요청 수"를 보여주는 그래프는 베이스라인 없이는 의미가 없습니다. 500 rps가 정상인가요 10배 스파이크인가요?

아무도 안 쓴다: 개발자가 대시보드를 열지 않는다면 모니터링은 작동하지 않는 것입니다. 워크플로우의 일부로 만드세요. 별도의 시스템이 아니라.

잘못된 것을 모니터링: 사용자와 비즈니스 결과에 중요한 것을 추적하세요. “스테이트리스 컨테이너의 디스크 I/O"는 아마 불필요합니다.

모니터링의 모니터링이 없음: 인시던트 중에 알림 시스템이 다운되면 가장 중요한 순간에 아무것도 볼 수 없습니다. 중복성을 구축하세요.

시작하기
#

모니터링을 처음부터 구축하거나 고장난 구성을 수정하는 경우:

  1. 먼저 개발자와 대화하세요. 인시던트 중 무엇이 어려운지 파악하세요.
  2. SLO를 정의하세요. 가장 중요한 사용자 플로우에서 “작동한다"는 것은 무엇을 의미하는가? 목표를 설정하세요.
  3. 크리티컬 패스를 계측하세요. 가장 중요한 사용자 여정—로그인, 체크아웃, 검색, 비즈니스를 이끄는 것—부터 시작하세요.
  4. 트레이싱을 추가하세요. 분산 트레이싱은 마이크로서비스 아키텍처에서 가장 큰 디버깅 ROI를 제공합니다.
  5. 런북을 작성하세요. 모든 알림에 무엇을 확인하고 일반적인 원인을 어떻게 수정하는지 설명하는 문서 링크를.
  6. 분기마다 리뷰하세요. 오래된 알림 제거, 임계값 업데이트, 대시보드가 현재 아키텍처를 반영하는지 확인.

좋은 모니터링은 가장 멋진 도구를 갖는 것이 아닙니다. 개발자가 문제를 빠르게 수정하는 데 필요한 정보를 제공하는 것입니다.