AWS DevOps Agent 를 활용한 성능 테스트 결과 분석

1. 개요

AWS DevOps Agent는 인시던트 대응을 위한 자율형 AI 에이전트입니다. 장애가 발생하면 AWS 리소스와 외부 모니터링 도구(Datadog 등)의 메트릭·로그를 자동으로 수집·분석하고, 근본 원인을 파악하여 우선순위가 지정된 권장사항을 제공합니다.

그런데 한 발 물러서 생각해보면, 성능 테스트 결과 분석도 본질은 같습니다 — “특정 시간대에 시스템에 부하가 가해졌을 때, 어떤 리소스가 어떤 상태였고, 어디가 병목이었는가?”를 파악하는 일입니다. DevOps Agent의 핵심 역할 — AWS 리소스를 자동으로 탐색하고, 메트릭을 수집·분석하고, 문제를 식별하여 조치 우선순위를 제공하는 것 — 은 인시던트든 성능 테스트든 동일하게 적용됩니다.

이 글에서는 DevOps Agent의 이러한 분석 역량을 성능 테스트 영역으로 확장하여, 테스트 직후 병목 식별과 보고서 작성을 수 분으로 단축하는 활용 방법을 소개합니다.

2. 성능 테스트 결과 분석의 현실 — 왜 테스트보다 분석에 더 오랜 시간이 걸리는가

도구 분산과 수작업의 벽

성능 테스트가 끝나면 엔지니어가 수행해야 할 분석 작업:

1. CloudWatch에서 EC2 CPU, 네트워크, 디스크 I/O 메트릭 확인
2. RDS Performance Insights에서 쿼리 대기 이벤트 분석
3. ALB의 5xx 에러율과 타겟 응답 시간 확인
4. ElastiCache의 CPU, 메모리, 커넥션 수 확인
5. Datadog APM에서 서비스 간 호출 레이턴시와 에러 트레이스 확인
6. 위 데이터를 종합하여 병목 구간을 식별하고 우선순위를 정한 보고서 작성

테스트 자체는 30분이면 끝나지만, 분석과 보고서 작성에 3~5시간이 소요되는 것이 현실입니다. 더 큰 문제는 경험에 따라 분석 품질이 크게 달라진다는 점입니다. 숙련된 엔지니어는 메트릭 패턴을 보고 즉시 병목을 짚지만, 경험이 적은 엔지니어는 어떤 메트릭을 봐야 하는지조차 판단하기 어렵습니다.

3. 왜 DevOps Agent인가

이 문제를 해결하기 위한 접근은 여러 가지가 있습니다:

• CloudWatch 대시보드를 사전에 구성해두고 테스트 후 확인
• 자체 분석 스크립트를 작성하여 메트릭 수집 자동화
• Grafana 등 통합 대시보드 구성

그러나 이 방법들은 사전 구성이 필요하고, 새로운 서비스가 추가될 때마다 업데이트해야 하며, “어디가 병목인지” 판단은 여전히 사람의 몫입니다.

AWS DevOps Agent를 선택한 이유는 이 세 가지가 이미 내장되어 있기 때문입니다:

1. AWS 리소스를 자동으로 탐색하고 메트릭을 수집 (사전 구성 불필요)
2. 메트릭 간 상관관계를 분석하여 병목을 식별 (판단까지 수행)
3. Datadog 등 외부 도구와 연동하여 통합 분석 (단일 창에서 완결)

별도의 도구를 만들 필요 없이, 테스트 후 “분석해줘”라고 요청하면 됩니다.

성능 테스트 분석에 활용 가능한 핵심 기능

4. 활용 사례 — JMeter 부하 테스트 후 병목 분석

샘플 웹 애플리케이션(Concert 예매 웹)에 JMeter로 부하 테스트를 수행하고, DevOps Agent에 병목 분석을 요청하여 결과 보고서를 생성하는 실제 활용 예시를 소개합니다.

4-1. 사전 준비

1. Agent Space 생성: 테스트 대상 애플리케이션이 위치한 AWS 계정을 연결
2. 모니터링 도구 연동: Datadog MCP 연결
3. Topology 구성 확인: Agent가 애플리케이션 아키텍처를 올바르게 인식하는지 확인

4-2. 테스트 환경 구성

아키텍처

[ALB] → [Gateway] → [concert-service]      → [Aurora PostgreSQL]
                  → [user-service]         → [Aurora PostgreSQL]
                  → [queue-service]        → [ElastiCache Redis]
                  → [reservation-service]  → [Aurora PostgreSQL]
                  → [payment-service]      → [Aurora PostgreSQL]

AWS Resource

4-3. JMeter 부하 테스트 수행

테스트 파라미터

테스트 시나리오 (순차 실행):

1. 공연 목록 조회 (GET /api/concerts)
2. 공연 상세 조회 (GET /api/concerts/{id})
3. 대기열 진입 (POST /api/queue/{id}/enter)
4. 예매 (POST /api/reservations)
5. 대기열 이탈 (DELETE /api/queue/{id}/leave)

1차 테스트 결과

부하유저

<그림1. 부하테스트 – 부하유저>

TPS

<그림2. 부하테스트 – TPS>

Response Time

<그림3. 부하테스트 – 응답시간>

테스트 시작 직후, Virtual User가 500에 도달하는 시점부터 HTTP 500 에러가 대량 발생했습니다. 약 10분간 7,332건의 Internal Server Error가 기록되었으며, 모두 POST /api/reservations 예매 API에서 발생했습니다.

JMeter Summary Report에서 예매 요청의 Error%가 급증하는 것을 확인한 후, AWS DevOps Agent에 원인 분석을 요청했습니다.

4-4. DevOps Agent에 분석 요청

Investigation 생성 시 다음과 같이 자연어로 요청합니다:

“2026년 6월 15일 2026-06-15 16:45 ~ 16:55 KST 시간대에 concert-reservation 시스템에 대해 부하테스트를 수행하였습니다.
환경 정보:
Region: ap-northeast-2 
AWS 리소스 태그: Project = concert-reservation 
CloudWatch Application Signals 서비스명: 
gateway (Spring Cloud Gateway, port 8080) 
concert-service (port 8082) 
user-service (port 8081) 
payment-service (port 8083) 
queue-service (port 8084)
reservation-service (port 8085) 
OTEL resource attributes: service.name={서비스명}, deployment.environment=dev 
인프라: 
EC2 t3.large × 6대, 
Aurora PostgreSQL 16.11, 
ElastiCache Redis 7.1 
ALB: concert-reservation-alb-2128394632.ap-northeast-2.elb.amazonaws.com 
예매 시도시 500유저에 도달하였을때 Fail이 발생합니다. 500에러로 보입니다. 원인이 뭔가요?
한글로 답해주세요.”

4-5. Agent 분석 과정

Agent는 이 요청을 받으면 자율적으로:

1. Topology 탐색: concert-reservation 시스템의 ALB → Gateway → 5개 마이크로서비스 → Aurora/Redis 관계 식별
2. 데이터 수집: 해당 시간대의 CloudWatch 메트릭 + Application Signals + X-Ray 트레이스 + 서비스 로그 수집
3. 다중 가설 분석: 복수의 병목 가설을 병렬로 생성하고, 반증을 수집하여 가장 증거가 강한 원인으로 수렴
4. 조치 방안 제시: Priority와 함께 조치 목록 제시

Agent 처리과정 예시:

Agent는 현재 진행중인 LSE(Large Scale Event) 확인을 비롯하여, 테스트 대상 리소스의 CloudWatch 정보를 병렬로 수집합니다.

<그림4. DevOps Agent 처리과정 예시1>

수집된 데이터를 바탕으로 병목의 원인을 파악합니다. 복수의 병목 가설을 병렬로 생성하고, 반증을 수집하여 가장 증거가 강한 원인으로 수렴합니다.

<그림5. DevOps Agent 처리과정 예시2>

<그림6. DevOps Agent 처리과정 예시3>

4-6. DevOps Agent 분석 결과

Topology

<그림7. DevOps Agent Topology>

Root Cause #1: 중복 예약 검증 로직의 Race Condition

Agent가 reservation-service의 로그를 분석한 결과, 부하 테스트 시작 전(baseline)에는 에러가 2건에 불과했으나, 500 유저가 동시 접속한 시점부터 7,332건의 에러가 폭증(3,666배 증가)한 것을 식별했습니다.

에러의 정체는 IncorrectResultSizeDataAccessException — “1건만 반환되어야 할 쿼리가 2건을 반환했다”는 것으로, Agent는 스택트레이스를 추적하여 정확한 코드 위치까지 짚어냈습니다:

500명 동시 요청
  → CreateReservationUseCase.execute()
    → ReservationDomainService.validateNoDuplicate()
      → findByUserIdAndConcertIdAndStatus() — "결과 없음" 확인
        → INSERT 성공 (동시에 복수 요청이 검증 통과)
          → 이후 조회 시 2건 반환 → NonUniqueResultException → HTTP 500

근본 원인: DB에 유니크 제약조건이 없어서 동시 요청이 검증을 통과하고 중복 INSERT에 성공함.

Root Cause #2: 재고 차감 Optimistic Lock 충돌

예약 성공 후 Redis pub/sub으로 재고 차감 이벤트가 발생하는데, 동시에 다수의 메시지가 도착하면 @Version기반 Optimistic Lock이 충돌:

• concert#36에 대한 StaleObjectStateException 46건 발생
• RedisMessageListenerContainer에 ErrorHandler 미설정 → 재시도 없이 유실
• 실제 예약과 재고 수치 불일치 가능

Root Cause 결과 화면

<그림8. DevOps Agent Root Cause>

Mitigation Plan 화면

Agent는 식별된 근본 원인을 바탕으로 구체적인 조치 방안(Mitigation Plan)을 제시합니다.

<그림9. DevOps Agent Mitigation Plan>

4-7. 조치 적용

DevOps Agent 분석 결과를 바탕으로 두 가지 수정을 적용했습니다:

1. 중복 예약 Race Condition → DB 유니크 인덱스 추가 (user_id + concert_id + status) + DataIntegrityViolationException을 409 Conflict로 핸들링
2. 재고 차감 충돌 → findById를 findByIdForUpdate (PESSIMISTIC_WRITE)로 변경하여 동시 요청을 DB 레벨에서 직렬화

4-8. 2차 테스트 결과 (조치 후)

조치 적용 후 동일 조건(JMeter VU 500)으로 재테스트 하였습니다. TPS 그래프에서 이전에 발생했던 Failed Transaction이 사라지고 대부분의 요청이 성공하는 것을 확인했습니다. 육안으로 확인되지 않는 잠재적 병목이나 문제가 있는지 검증하기 위해 DevOps Agent에 재분석을 요청했습니다.

TPS

<그림10. 2차 부하테스트 – TPS>

DevOps Agent 분석결과 테스트는 정상적으로 완료되었으며, 문제가 없는것으로 확인되었습니다.

Agent 분석 요약

• 5xx 에러 해소 확인 — 이전 7,332건 → 테스트 첫 1분에 181건(JVM 워밍업) 후 완전 소멸
• reservation-service 4xx (~20%) — 유니크 제약조건이 정상 동작. 중복 예약 시도를 409 Conflict로 차단하는 정상적인 멱등성 보장 동작
• 인프라 자원 충분 — 모든 리소스 CPU 15% 미만, Redis 캐시 적중률 97.2%, 네트워크 ~1Mbps (한계 5Gbps)

“피크 6,000 req/min(100 TPS)을 안정적으로 처리했으며, 인프라 자원 모두 충분한 여유가 있어 현재 부하 수준의 5~10배까지도 수용 가능할 것으로 판단됩니다.”

<그림11. DevOps Agent 결과 보고서>

5. Datadog/GitLab 연동으로 더 깊은 분석

AWS DevOps Agent는 Datadog, GitLab과 네이티브로 연동됩니다. CloudWatch만으로는 보이지 않는 애플리케이션 레벨의 인사이트를 함께 분석할 수 있습니다:

• APM 트레이스: 서비스 간 호출 체인에서 어떤 구간이 느린지
• Database Query 분석: 어떤 SQL이 느렸는지 (RDS Performance Insights와 상호보완)
• GitLab 코드 분석: 최근 배포된 커밋과 MR을 자동으로 확인하여, 장애를 유발한 코드 변경을 식별하고 문제 지점의 소스코드를 직접 분석

이를 통해 “인프라 병목”과 “애플리케이션 코드 병목”, “최근 배포로 인한 회귀”를 하나의 분석에서 동시에 식별할 수 있습니다.

<그림12. DevOps Agent 네이티브 연동>

6. Chat으로 Investigation 심화 질의

Investigation이 완료된 후에도 분석이 끝나는 것이 아닙니다. 왼쪽 Chat 패널에서 결과에 대해 추가 질문을 할 수 있어, 불명확한 부분을 즉시 파고들 수 있습니다.

예를 들어:

• “reservation-service의 에러가 시작된 07:50:02에 정확히 어떤 일이 있었는지 더 자세히 알려줘”
• “이 Race Condition을 방지하려면 어떤 조치를 추천하는가?”
• “concert-service와 Aurora는 정상이라고 했는데, 근거가 되는 메트릭을 보여줘”

Agent는 이미 수집한 데이터를 기반으로 즉시 응답하며, 필요하면 추가 메트릭을 조회하여 답변합니다. 보고서에 담기지 않은 세부사항까지 대화로 확인할 수 있어, 분석 보고서 작성 시 빠진 맥락을 채울 수 있습니다.

<그림13. DevOps Agent Chat 예시>

7. 기대 효과

Before → After

핵심 장점

1. 코드 레벨 추적: 단순히 “500 에러 발생”이 아니라, validateNoDuplicate() → findByUserIdAndConcertIdAndStatus()까지 정확히 짚어냄
2. 일관된 분석 품질: 경험에 관계없이 동일한 깊이의 분석 결과
3. 조사 갭 명시: 분석할 수 없는 영역(메모리 메트릭 부재, 로그 미수집)을 투명하게 알려줘서 다음 액션이 명확
4. 팀 공유 용이: Investigation 결과가 자동으로 기록되어 팀원과 공유 가능

8. 결론 및 시작하기

성능 테스트의 가치는 테스트를 수행하는 것이 아니라, 결과를 정확히 분석하고 적절한 조치를 취하는 데 있습니다. AWS DevOps Agent는 이 분석 과정을 대폭 단축하여 엔지니어가 “메트릭 수집”이 아닌 “의사결정”에 집중할 수 있게 합니다.

특히 정기적으로 성능 테스트를 반복하는 팀에게는, 매번 수 시간씩 소요되던 분석 작업이 수 분으로 줄어드는 효과는 누적됩니다. 다음 성능 테스트에서 DevOps Agent에 분석을 맡겨보시기 바랍니다.

시작하기

1. AWS Management Console에서 AWS DevOps Agent를 검색합니다.
2. Agent Space를 생성하고 테스트 대상 계정을 연결합니다.
3. 모니터링 도구(Datadog 등)를 연동합니다.
4. 성능 테스트를 수행한 후, Investigation을 생성하여 분석을 요청합니다.

자세한 내용은 AWS DevOps Agent 사용 설명서를 참조하세요.

AWS Enterprise Support 한국 고객을 위한 성능 테스트 지원

AWS Enterprise Support 한국 고객이라면, 성능 테스트에 어려움이 있을 때 전문적인 도움을 받을 수 있습니다. 한국 Enterprise Support팀에서 운영하는 성능테스트 지원 프로그램을 통해 워크로드 분석부터 테스트 환경 구성, 병목 식별까지 TAM과 함께 진행할 수 있습니다. 관심이 있으시다면 담당 TAM에게 문의해 주세요.