1. V1 핵심 기능 - 리포트 조회 API
   • 사용자 요청 흐름대로 진행할 예정
   • 현재 V1구조 최대한 살려서 진행할 예정
2. V1에서 구현된 기능이자 V2의 핵심 기능 - 투자매매 API
   • 현재 FE 개발된 코드가 없기에
   • docker-compose 에 포함된 FE, NginX 다 날리고 BE, DB만 진행

Infra환경 세팅

• VPC 새로 생성
• 이 안에서 현재 배포 환경과 유사하게 구성하여 진행할 예정
• 마찬가지로 terraform 분리하지만 git branch와 디렉토리도 분리하여 관리

1. V1 핵심 기능 - 리포트 조회 API

• 모니터링(메트릭, 로그 수집) 세팅
• 코드는 ECR은 전에 만들어 놓은거 공유해서 거기에 가장 최근 태그값가져와서 쓰고, 현재 docker-compose에 그 값은 고정으로 넣는 작업
• 리포트 조회 처리 흐름 봐야하니까 미리 리포트 mock 데이터 넣어놓고
• SLO 기반 목표치 정하기
• 시나리오 정하기
• 테스트 진행

SLO 설정

23명이 peak이기에 1건이 실패해도 성공률은 95%가 된다. 이때 SLO는 MAU 23기준 실패 0건으로 잡고 이를 실행 합격 기준으로 둬야하고, 3초 이내 정상 응답 비율도 별도로 기록하는 것이 명확하다 이 결과는 단지 피크 조건 검증일뿐 30일 SLO 달성의 증명은 아니다.

리포트 상세 조회 부하테스트 계획

대상: 게시 완료된 AI 리포트 상세 조회 API

GET /api/v1/accounts/{accountId}/orders/{orderId}/ai-report

로그인이나 리포트 생성은 부하에 포함하지 않고, 테스트용 계정으로 상세 조회만 확인한다.

측정 지표

1. 정상 조회율: 전체 요청 중 HTTP 200, 요청한 주문 ID와 응답 주문 ID 일치, 완료 상태, 유효한 리포트 본문까지 확인한 비율
   • 운영 SLO 목표: 30일 기준 100%
   • 부하테스트 실행 합격 기준: 실패 0건
2. 빠른 정상 조회율: 전체 요청 중 유효한 응답을 3초 안에 받은 비율
   • 기존 초안의 99% 목표는 검토값으로 두고, 응답시간 p95·p99와 함께 기록한다.

트래픽과 시나리오

주 1회 발행된 리포트를 MAU 23명이 한 번씩 조회한다고 보면 주간 평균은 약 0.000038 RPS다. 공부 흐름에서 주 3회 조회하는 경우는 한 번에 여는 리포트 수를 K라 할 때 0.000114 × K RPS다. K는 코드만으로 알 수 없어, 1회 조회를 기술 기준선으로 삼는다.

Peak의 23명은 한 번에 들어오는 23건의 요청이지, 23 RPS를 계속 보내는 테스트는 아니다. 순서는 Smoke부터 시작해 결과를 확인한 뒤 다음 시나리오로 진행한다.

시나리오	부하 방식	요청 수·속도
Smoke	사용자 1명이 1회 조회	1건
Baseline	사용자 1명이 30초 간격으로 조회	10건, 약 5분
Peak	사용자 23명이 거의 동시에 1회씩 조회	총 23건, 순간 집중
spread10	사용자 23명이 10초 동안 나눠서 1회씩 조회	총 23건, 약 2.4건/초. 같은 방식으로 2회
spread60	사용자 23명이 60초 동안 나눠서 1회씩 조회	총 23건, 약 0.4건/초
Repeat	사용자 23명이 30초 간격으로 20회씩 반복 조회	총 460건, 10분간. 매 30초마다 23건이 몰리는 형태

측정 방법

k6 결과에서 실패 건수, 3초 이내 정상 응답률, p95·p99, 실제 요청률을 기록한다. 같은 시간 범위의 CloudWatch에서 앱 EC2와 k6 EC2의 CPU·메모리 및 로그도 함께 확인한다. 부하 발생기인 k6 EC2가 포화된 실행은 서버 판정에 사용하지 않는다.

리포트 상세 조회 부하테스트 결과

실행일: 2026-10-02 (KST)
대상: GET /api/v1/accounts/{accountId}/orders/{orderId}/ai-report
목적: 예상 조회 시나리오에서 응답 성공률과 응답시간 확인

결과 요약

유효한 인증정보로 실행한 본시험은 **563/563건 성공(100%)**했다. 모든 응답이 shorten_text와 9개 thoughts 필드를 포함했고, 3초 안에 완료됐다. 가장 많은 표본을 제공한 Repeat는 460/460 성공, p95 141.42ms, p99 217.33ms였다.

시나리오	부하	요청 수	성공률	응답 p95
Smoke	1 VU, 1회	1	100%	795.67ms
Baseline	1 VU, 30초 간격 10회	10	100%	24.68ms
Peak	23 VU, 동시에 1회씩	23	100%	267.64ms
spread10 1차	23 VU, 약 10초에 분산	23	100%	22.21ms
spread10 2차	23 VU, 약 10초에 분산	23	100%	18.85ms
spread60	23 VU, 약 60초에 분산	23	100%	17.69ms
Repeat	23 VU, 30초 간격 20회씩, 약 10분	460	100%	141.42ms

Repeat의 p99는 217.33ms였다. 전체 유효 요청에서 HTTP 실패와 잘못된 리포트 응답은 없었다.

참고 자원 지표

• 사용자 제공 CloudWatch 그래프에서 App EC2 Host CPU는 약 **5–8%**로 안정적으로 보인다. 그래프는 1분 단위이며, 이 값은 화면을 보고 읽은 대략치다.
• 이 부하에서 CPU가 낮았다는 것은 예상 조회 부하가 CPU 포화를 만들지 않았다는 관측이다. 최대 처리량이나 서버 한계점을 시험한 결과는 아니다.

판정과 범위

• 시험한 부하 시나리오의 응답 성공률 목표 100%를 만족했다.
• 측정된 요청은 모두 3초 안에 완료돼 3초 이내 응답 목표도 만족했다.
• 이 결과는 해당 시나리오와 시험 시간 구간에서의 SLI 결과다. 30일 전체 SLO 달성이나 최대 용량을 증명하지는 않는다.
• Peak는 23건의 단발 동시 요청이고, Repeat는 평균 약 0.77건/초로 30초마다 23건씩 몰리는 부하다. 지속적인 고RPS 용량 시험은 아니다.

별도 사전 오류

토큰 재발급 전 Smoke 1건은 HTTP 401 인증 오류였다. 토큰을 바로잡은 뒤의 Smoke는 1/1 성공했다. 본시험 집계 563건에는 인증 설정 오류가 난 사전 요청을 넣지 않았다.