요즘 성능 이슈는 “느리다"에서 끝나지 않습니다.
클라우드 비용 상승, AI 생성 코드 유입, 고빈도 배포가 겹치면서 원인 추적 속도 자체가 경쟁력이 됐습니다.

기존 APM은 “어느 요청이 느린지"를 잘 보여주지만, “CPU를 누가 먹었는지” “할당이 왜 급증했는지"를 항상 빠르게 보여주진 못합니다. 그래서 2026년엔 APM 위에 Continuous Profiling(지속적 프로파일링) 을 상시로 붙이는 팀이 늘고 있습니다.

이 글에서 얻는 것

  • Continuous Profiling이 기존 APM/메트릭과 어떻게 다른지 역할을 명확히 구분할 수 있습니다.
  • 도입이 필요한 팀과 아직 이른 팀을 트래픽·비용·장애 빈도 기준으로 판단할 수 있습니다.
  • 과도한 도구 도입 없이 30일 내 파일럿을 돌리는 실무 적용 순서를 얻습니다.

핵심 개념/이슈

1) APM만으로는 “코드 레벨 비용"이 비는 구간이 생긴다

APM은 요청 경로, 외부 호출, 오류율 관점에서 매우 강력합니다. 다만 아래 질문은 별도 프로파일 데이터가 필요합니다.

  • p95가 40% 올랐는데 CPU를 가장 많이 잡아먹는 함수는 무엇인가?
  • GC/할당 증가가 특정 릴리스 이후 왜 커졌는가?
  • 락 대기 시간이 긴데 정확히 어떤 코드 경로에서 병목이 발생하는가?

즉, APM이 “어디가 느린가"를 보여준다면, 프로파일링은 “왜 느린가"를 함수/스택 단위로 보여줍니다. 베이스라인은 관측성 기본 구성과 APM 기초를 먼저 맞춰두는 게 좋습니다.

2) Continuous Profiling의 핵심: 샘플링으로 상시 수집

지속적 프로파일링은 디버그 때 잠깐 켜는 프로파일러가 아닙니다. 낮은 오버헤드로 샘플을 계속 모아 “평소 패턴"과 “이상 징후"를 비교합니다.

주로 다루는 타입:

  1. CPU Profile: 핫 함수/핫 스택 추적
  2. Allocation/Heap Profile: 메모리 할당 증가 구간 추적
  3. Lock/Block Profile: 대기/경합 지점 식별

중요한 포인트는 “한 번의 flame graph"가 아니라, 릴리스별·서비스별 변화량입니다. 이 비교가 있어야 회귀(regression)를 잡을 수 있습니다.

3) 왜 지금 트렌드가 강해졌나: 비용 압력 + 배포 속도 + 코드 생성 자동화

2026년 팀들이 특히 민감하게 보는 건 세 가지입니다.

  • 클라우드 비용이 분기마다 10~20%씩 증가
  • 하루 수십~수백 배포로 성능 회귀가 자주 유입
  • AI 생성 코드 비중 증가로 비효율 패턴이 더 자주 섞임

결국 “장애 후 포렌식"보다 “배포 직후 성능 회귀를 조기 차단"하는 체계가 필요해졌고, Continuous Profiling이 그 공백을 메우고 있습니다.

4) 도입 판단 기준(숫자 중심)

아래 3개 중 2개 이상 해당하면 파일럿 가치가 높습니다.

  • 서비스별 월 인프라 비용이 최근 3개월 평균 대비 15% 이상 상승
  • p95 레이턴시 회귀 이슈가 월 2회 이상 발생
  • 성능 이슈 RCA(원인 분석)에 평균 4시간 이상 소요
  • 동일 서비스의 배포 빈도가 주 5회 이상

우선순위는 보통 장애/비용 영향도가 큰 서비스 20%부터 시작하는 편이 성과가 빠릅니다.

실무 적용

1) 30일 도입 플랜: “전 서비스"보다 “핵심 2~3개"부터

  • 1주차: API 게이트웨이/결제/검색 등 고트래픽 서비스 2~3개 선정
  • 2주차: CPU + Allocation 프로파일만 우선 수집(신호 과다 방지)
  • 3주차: 릴리스 태그 연동, 배포 전후 Top Hotspot 비교 대시보드 구성
  • 4주차: 성능 회귀 경보 기준 설정 후 운영 온콜 절차 연결

초기엔 지표를 많이 붙이는 것보다, “배포 후 24시간 내 회귀 탐지” 하나를 확실히 만드는 게 낫습니다.

2) 의사결정 임계치(예시)

  • 신규 릴리스 후 특정 함수 CPU 비중이 기준선 대비 +30%: 롤백 또는 패치 우선 검토
  • Allocation rate +25%가 2시간 이상 지속: 메모리 회귀 조사 티켓 자동 생성
  • Lock wait 샘플 비중이 10% 초과: 동시성 병목 점검 스프린트 우선순위 상향
  • 성능 회귀 RCA 시간이 4시간 초과: 프로파일 대시보드 구조 개선 작업 즉시 투입

실무에서는 “오탐을 줄이는 기준"이 중요합니다. 처음부터 민감도를 높이면 경보 피로가 빠르게 옵니다.

3) 기존 관측 체계와 연결

Continuous Profiling은 독립 도구가 아니라 기존 관측 스택의 확장입니다.

추천 운영 흐름:

  1. 알람이 p95 상승 감지
  2. 같은 시간대 프로파일에서 핫스택 확인
  3. 최근 배포 diff와 매핑
  4. 패치/롤백 결정

이 4단계가 자동화되면 MTTR이 눈에 띄게 줄어듭니다.

4) 조직 적용 팁: 성능을 “개발팀 책임"에서 “플랫폼 계약"으로

플랫폼 팀이 아래 3가지를 표준으로 제공하면 확산 속도가 빨라집니다.

  • 공통 프로파일 수집 에이전트(언어별 템플릿)
  • 릴리스 태깅/서비스 태깅 규칙
  • 성능 회귀 대응 런북

개별 팀이 도구를 고르는 구조보다, 기본 경로를 제공하고 팀은 임계치만 조정하게 하는 방식이 운영 마찰이 적습니다.

트레이드오프/주의점

  1. 오버헤드 관리가 필요하다
    샘플링 기반이라도 트래픽이 높은 서비스에서는 1~3% 수준의 추가 비용이 생길 수 있습니다. 수집 빈도와 보존 기간을 서비스 등급별로 다르게 가져가야 합니다.

  2. 데이터 민감도 이슈를 무시하면 안 된다
    스택/심볼 정보에 내부 경로가 포함될 수 있으므로 접근 권한과 보관 정책을 분리해야 합니다.

  3. 도구만 붙이고 운영 루틴이 없으면 실패한다
    프로파일 대시보드가 있어도 배포 리뷰/온콜 프로세스와 연결되지 않으면 “좋은 그림"으로 끝납니다.

  4. 모든 성능 문제를 프로파일링이 해결하지는 않는다
    네트워크 지연, 외부 API SLA, DB 잠금처럼 시스템 경계 이슈는 메트릭/트레이스와 함께 봐야 정확합니다.

체크리스트 또는 연습

팀 체크리스트

  • 고비용/고트래픽 서비스 2~3개를 파일럿 대상으로 선정했다.
  • CPU/Allocation 프로파일부터 시작하고, 초기 경보 항목을 3개 이하로 제한했다.
  • 배포 태그와 프로파일 데이터를 연결해 릴리스 전후 비교가 가능하다.
  • p95 상승 알람에서 핫스택 확인까지 10분 내 접근 가능한 런북이 있다.
  • 월간 성능 회귀 건수와 RCA 소요시간을 KPI로 추적한다.

연습 과제

  1. 최근 2주 배포 중 p95가 가장 크게 튄 릴리스를 1개 선택하고, 프로파일 기준으로 원인 가설 3개를 작성해보세요.
  2. 서비스 하나를 골라 “CPU Top 5 함수"의 기준선을 만든 뒤, 다음 릴리스에서 변화율을 비교해보세요.
  3. 온콜 대응 문서에 “알람→프로파일→배포 diff→결정” 4단계 절차를 추가하고, 모의훈련 1회를 실행해보세요.

결국 Continuous Profiling의 핵심은 도구 도입이 아니라, 성능 회귀를 배포 단위로 빠르게 감지하고 끊는 운영 체계입니다.
APM이 이미 있다면, 그 위에 프로파일링을 얹는 순간부터 “느림의 원인"을 감으로 추측하는 시간을 크게 줄일 수 있습니다.

관련 글