k6 부하테스트로 t2.micro 서버 한계와 병목 분석하기

 

LOAD TEST

k6 부하테스트로 t2.micro 서버 한계 구간 분석하기

목차

• 1. 테스트 목적과 환경
• 2. 시나리오 설계
• 3. 측정 지표
• 4. 테스트 데이터 준비
• 5. 결과 비교
• 6. 부하테스트 중 발견한 이슈 - 좋아요 Race Condition
• 7. 결론 및 한계

1. 테스트 목적과 환경

Booktine의 애플리케이션 서버는 AWS EC2 t2.micro 단일 인스턴스에서 운영되고 있으며, 데이터베이스는 별도의 Amazon RDS MySQL을 사용한다. 배포 후 현재 환경이 어느 정도의 부하를 처리할 수 있는지 파악하기 위해 k6 부하테스트를 진행했다. 단순히 서버가 중단되는지만 확인하는 것이 아니라, 가상 사용자 수가 증가할 때 응답시간이 급격히 악화되는 구간을 찾고 병목 가능성을 좁히는 것을 목표로 했다.

애플리케이션 실행 환경은 1 vCPU와 1GB RAM을 제공하는 t2.micro를 기준으로 구성했다. Spring Boot 애플리케이션은 Docker 컨테이너로 실행했고 Redis는 같은 EC2 인스턴스에서 사용했다. MySQL은 Amazon RDS에 분리되어 있으므로, 이번 결과는 주로 애플리케이션 서버의 제한된 CPU·메모리 환경과 외부 데이터베이스 접근 비용을 포함한다.

항목	내용
인스턴스	AWS EC2 t2.micro
CPU	1 vCPU
메모리	1GB RAM
JVM 힙	-Xms256m -Xmx512m
구성	Spring Boot(Docker) + Redis(EC2), MySQL(Amazon RDS)

부하 생성 도구는 JMeter 대신 k6를 선택했다. 처음에는 JMeter를 고려했지만 JVM 기반 도구를 테스트 클라이언트로 사용하면 로컬 자원 사용량이 커져 결과가 왜곡될 가능성이 있었다. JMeter의 시나리오는 XML 기반 JMX 파일로 관리되어 테스트 흐름이 늘어날수록 가독성과 유지보수성이 떨어질 수 있는 반면, k6는 Go 기반으로 비교적 가볍고 JavaScript로 시나리오를 작성할 수 있었다. 아직 JMX 파일을 작성하기 전이어서 전환 비용도 없었기 때문에 k6를 사용하기로 결정했다.

테스트 전에 JVM 힙도 명시적으로 제한했다. 기존 배포 설정에는 힙 옵션이 없었고 유휴 상태에서도 서버 메모리 사용량이 428MB에 도달해 있었다. 1GB RAM 환경에서 부하가 증가하면 OOM이 발생할 가능성이 있어 Dockerfile의 실행 옵션을 -Xms256m, -Xmx512m로 설정했다.

# 변경 전
ENTRYPOINT ["java", "-jar", "/app/app.jar"]

# 변경 후
ENTRYPOINT ["java", "-Xms256m", "-Xmx512m", "-jar", "/app/app.jar"]

힙 옵션을 적용하고 컨테이너를 재시작한 뒤 측정한 유휴 메모리 사용량은 428MB에서 323MB로 감소했다. 다만 이 차이에는 재시작 시점의 GC 상태와 실행 환경 변화가 함께 영향을 줄 수 있으므로, 힙 설정만의 효과라고 단정하지는 않았다. 또한 -Xmx512m은 JVM 힙 상한이며 컨테이너 전체 메모리 상한은 아니기 때문에, 각 시나리오가 끝날 때마다 docker stats로 전체 컨테이너 메모리 추이도 함께 확인했다.

 

데이터베이스 병목 여부를 확인하기 위해 MySQL Slow Query Log도 활성화했다. RDS에서는 SUPER 권한 제한으로 SQL을 통해 직접 설정하기 어려워 AWS 콘솔의 파라미터 그룹에서 slow_query_log를 활성화하고, 1초 이상 실행되는 쿼리를 기록하도록 long_query_time을 설정했다.

파라미터	값
slow_query_log	1
long_query_time	1

Slow Query Log는 1초를 초과하는 개별 SQL이 있는지 확인하기 위한 보조 지표로 사용했다. 이 로그만으로 짧은 쿼리의 반복 실행, 커넥션 풀 대기, 데이터베이스 CPU 사용량까지 배제할 수는 없으므로 다른 결과와 함께 해석했다. 통계 API는 페이지네이션 없이 전체 데이터를 조회하는 구조였기 때문에, 실제 운영 환경과 비슷한 부하가 발생하도록 충분한 테스트 데이터도 사전에 삽입했다.

2. 시나리오 설계

단계별 부하 설계

부하테스트에서 모든 API를 처음부터 동시에 실행하면 응답시간이 증가하거나 오류가 발생했을 때 어느 기능이 원인인지 구분하기 어렵다. 그래서 실제 사용자의 행동 흐름을 기준으로 네 개의 시나리오를 나누고, 각 시나리오를 단독으로 실행한 뒤 마지막에 통합 실행하는 방식으로 설계했다. 단독 테스트에서는 기능별 특성을 확인하고, 통합 테스트에서는 여러 기능이 동시에 호출되는 실제 운영 상황을 재현하고자 했다.

가상 사용자(VU) 수도 한 번에 100이나 150으로 올리지 않고 5, 20, 50, 100, 150 순서로 단계적으로 증가시켰다. 이렇게 해야 어느 VU 구간까지 응답시간과 실패율이 안정적으로 유지되는지 확인할 수 있고, 성능이 급격히 악화되는 경계도 특정할 수 있다. 각 단계는 Warm-up, Light, Normal, Heavy, Over로 구분했다.

단계	가상 사용자(VU)	유지 시간	목적
Warm-up	5 VU	1분	서버 JVM warm-up, 정상 동작 확인
Light	20 VU	3분	기본 부하, 코드 레벨 이슈 확인
Normal	50 VU	5분	실 사용 예상 구간, 핵심 측정
Heavy	100 VU	5분	목표 상한선, 한계 도달 여부 관찰
Over	150 VU	3분	의도적 한계 탐색

k6에서는 stages 옵션으로 VU 수와 유지 시간을 설정했고, P95 응답시간 2,000ms 미만과 HTTP 요청 실패율 1% 미만을 threshold로 지정했다.

export const options = {
  stages: [
    { duration: '1m', target: 5 },   // Warm-up
    { duration: '3m', target: 20 },  // Light
    { duration: '5m', target: 50 },  // Normal
    { duration: '5m', target: 100 }, // Heavy
    { duration: '3m', target: 150 }, // Over
    { duration: '1m', target: 0 },   // 종료
  ],
  thresholds: {
    http_req_duration: ['p(95)<2000'],
    http_req_failed: ['rate<0.01'],
  },
};

사용자 시나리오

시나리오는 독서 기록 조회, 독서 기록 작성, 통계 및 목표 확인, 커뮤니티 탐색의 네 가지로 구성했다. 단순히 단일 API를 반복 호출하지 않고 로그인부터 실제 기능 사용까지 이어지는 흐름으로 작성해 인증 처리, 데이터 조회, 저장, 연관 데이터 접근이 함께 발생하도록 했다.

시나리오	흐름
A (독서 기록 조회)	로그인 → 내 정보 → 게시글 목록 → 단건 조회 → 메모 조회
B (독서 기록 작성)	로그인 → 게시글 작성 → 메모 작성
C (통계/목표 확인)	로그인 → 기본 통계 → 장르별 통계 → 연간 완독 수 → 연간 요약 → 월간/연간 목표
D (커뮤니티 탐색)	로그인 → 커뮤니티 목록 → 단건 조회 → 댓글 조회 → 좋아요 → 좋아요 취소

모든 시나리오는 로그인 응답에서 accessToken을 추출한 뒤 이후 요청에 Bearer 헤더로 전달하는 공통 구조를 사용했다. 대표적으로 시나리오 A는 로그인 후 내 정보와 게시글 목록을 조회하고, 목록에서 얻은 게시글 ID로 단건 조회와 메모 목록 조회를 이어서 수행한다.

export default function () {
  const token = login();
  const headers = authHeaders(token);

  const meRes = http.get(`${BASE_URL}/users/me`, headers);
  check(meRes, { '내 정보 조회 성공': (r) => r.status === 200 });
  sleep(0.5);

  const postsRes = http.get(`${BASE_URL}/posts`, headers);
  check(postsRes, { '게시글 목록 조회 성공': (r) => r.status === 200 });

  const posts = JSON.parse(postsRes.body);
  if (posts.data && posts.data.length > 0) {
    const postId = posts.data[0].id;

    const postRes = http.get(`${BASE_URL}/posts/${postId}`, headers);
    check(postRes, { '게시글 단건 조회 성공': (r) => r.status === 200 });
    sleep(0.5);

    const memosRes = http.get(`${BASE_URL}/posts/${postId}/memos`, headers);
    check(memosRes, { '메모 목록 조회 성공': (r) => r.status === 200 });
  }
  sleep(1);
}

3. 측정 지표

이번 테스트에서는 평균 응답시간만으로 서버 상태를 판단하지 않았다. 평균값은 일부 매우 느린 요청이나 매우 빠른 요청의 영향을 받기 때문에 실제 사용자가 체감하는 지연을 충분히 설명하지 못할 수 있다. 그래서 일반적인 요청의 응답시간을 확인하기 위해 P50을, 대부분의 사용자가 경험하는 상위 지연을 확인하기 위해 P95를 함께 측정했다.

P50은 전체 요청의 50%가 해당 시간 안에 처리됐다는 의미로, 일반적인 사용자의 응답 경험을 보여준다. P95는 전체 요청의 95%가 해당 시간 안에 처리됐다는 의미이며, 일부 지연 요청까지 포함한 서비스 품질을 확인하기 위해 이번 테스트의 핵심 지표로 사용했다. 목표값은 2,000ms 미만으로 설정했다.

RPS는 k6의 http_reqs를 기준으로 계산한 초당 HTTP 요청 수다. 한 번의 사용자 시나리오 안에서 여러 API를 호출하므로, 이 값은 비즈니스 트랜잭션 수가 아니라 HTTP 요청 처리량을 의미한다. HTTP 요청 실패율은 전체 HTTP 요청 중 k6가 실패로 판정한 요청의 비율로 1% 미만을 목표로 설정했다. 또한 각 시나리오 종료 후 컨테이너 메모리 사용량을 측정해 -Xmx512m 제한 안에서 메모리 사용량이 안정적으로 유지되는지도 확인했다.

지표	목표값
평균 응답시간	< 1,000ms
P95 응답시간	< 2,000ms
HTTP 요청 실패율	< 1%
RPS	> 20

4. 테스트 데이터 준비

실제 사용자 데이터가 테스트 과정에서 변경되지 않도록 전용 계정을 별도로 생성했다. 서비스에는 이메일 인증 절차가 있어 회원가입 API만으로 계정을 만들기 어려웠기 때문에 EC2에 SSH로 접속한 뒤 BCrypt 비밀번호 해시를 생성하고 MySQL에 직접 사용자 데이터를 삽입했다.

BCrypt 해시는 다음 명령으로 생성했다.

python3 -c 'import bcrypt; pw = b"<REDACTED_PASSWORD>"; print(bcrypt.hashpw(pw, bcrypt.gensalt(10)).decode())'

생성한 해시를 사용해 부하테스트 전용 사용자를 등록했다. 게시글에는 실제 운영에 사용한 이메일과 비밀번호를 노출하지 않고 예시값으로 대체했다.

INSERT INTO users (created_at, updated_at, auth_provider, email, email_verified, nickname, password, role, suspended)
VALUES (
  NOW(), NOW(), 'LOCAL',
  'loadtest@example.com', b'1',
  'loadtest', '{BCrypt_해시값}',
  'ROLE_USER', b'0'
);

통계 API와 목록 조회가 실제 데이터량에서 동작하도록 시드 데이터도 준비했다. 데이터가 적으면 전체 조회나 집계 API가 지나치게 빠르게 처리되어 운영 환경과 차이가 커질 수 있다. posts에는 1,200건을 삽입하고 reading_status 네 종류와 장르 여섯 종류가 고르게 분산되도록 구성했다. community_posts에는 카테고리별로 총 200건을 삽입했다.

시나리오	테이블	건수	이유
A (독서 기록 조회)	posts	1,200건	통계 집계 API와 공유
C (통계/집계)	posts	1,200건	페이지네이션 없는 전체 조회
D (커뮤니티 탐색)	community_posts	200건	페이지네이션 적용으로 200건 충분

반복 INSERT를 수동으로 실행하지 않도록 MySQL 프로시저를 작성했다. 날짜, 독서 상태, 장르, 평점 등이 특정 값에만 치우치지 않도록 반복 횟수에 따라 값을 분산했고, 완료 상태인 데이터에만 완독일과 평점을 입력하도록 구성했다.

DELIMITER $$

CREATE PROCEDURE insert_loadtest_posts()
BEGIN
  DECLARE i INT DEFAULT 1;
  DECLARE r_status VARCHAR(20);
  DECLARE r_genre VARCHAR(20);
  DECLARE r_rating DOUBLE;
  DECLARE r_completed DATE;
  DECLARE r_start DATE;
  DECLARE v_user_id BIGINT;

  SELECT id INTO v_user_id
  FROM users
  WHERE email = 'loadtest@example.com'
  LIMIT 1;

  WHILE i <= 1200 DO
    SET r_status = ELT((i % 4) + 1, 'COMPLETED', 'READING', 'PAUSED', 'WISHLIST');
    SET r_genre = ELT((i % 6) + 1, '소설', '에세이', '자기계발', '경제/경영', '과학', '역사');
    SET r_rating = IF(r_status = 'COMPLETED', ROUND(2.5 + (i % 3) * 0.5 + (i % 5) * 0.2, 1), NULL);
    SET r_completed = IF(r_status = 'COMPLETED', DATE_SUB(CURDATE(), INTERVAL (i % 365) DAY), NULL);
    SET r_start = DATE_SUB(CURDATE(), INTERVAL (i % 365 + 10) DAY);

    INSERT INTO posts (
      created_at, updated_at, user_id, title, author, publisher,
      genre, reading_status, rating, short_review,
      start_date, completed_date, current_page, total_page,
      summary, cover_image_url, published_date
    ) VALUES (
      NOW(), NOW(), v_user_id,
      CONCAT('테스트 도서 ', i), CONCAT('저자 ', (i % 20) + 1), CONCAT('출판사 ', (i % 10) + 1),
      r_genre, r_status, r_rating,
      IF(r_status = 'COMPLETED', CONCAT('한줄평 ', i), NULL),
      r_start, r_completed,
      IF(r_status = 'READING', (i % 200) + 50, NULL),
      300 + (i % 200), CONCAT('줄거리 요약 ', i), NULL,
      DATE_SUB(CURDATE(), INTERVAL (i % 1000) DAY)
    );

    SET i = i + 1;
  END WHILE;
END$$

DELIMITER ;

CALL insert_loadtest_posts();

삽입 결과는 다음과 같다. posts는 네 개의 독서 상태가 각각 300건씩 생성됐고, community_posts는 세 개 카테고리에 약 66~67건씩 분산됐다.

posts, community_posts 삽입 결과

5. 결과 비교

핵심 결과
단독 테스트 수행 중에는 50 VU 구간까지 응답시간이 비교적 안정적으로 관찰됐고, 100 VU 이후 지연 증가가 두드러졌다. 네 개 시나리오를 동시에 실행한 통합 테스트에서는 P95가 7,000ms까지 상승했다. Slow Query Log에서는 1초를 초과한 개별 SQL이 확인되지 않았으며, 애플리케이션 서버의 1 vCPU와 t2 계열의 버스터블 특성을 고려하면 CPU 포화가 유력한 원인으로 추정됐다. 다만 이를 확정하려면 CPU 사용률과 CPU 크레딧 등 인프라 지표가 추가로 필요하다.

단독 시나리오 결과

각 시나리오를 개별 실행한 결과 평균 응답시간은 267~781ms로 목표인 1,000ms 미만을 유지했다. 통계 및 목표 확인 시나리오 C는 P95 1,390ms와 RPS 75.11/s로 설정한 기준을 모두 만족했다. 반면 독서 기록 조회와 작성 시나리오 A, B는 평균 응답시간과 HTTP 요청 실패율은 기준을 만족했지만 P95가 각각 2,730ms와 2,800ms로 목표를 초과했다. 커뮤니티 탐색 시나리오 D는 P95는 목표 안에 있었으나, 동일 계정의 중복 좋아요 요청에서 반환된 409 응답이 k6의 실패 요청으로 집계되면서 전체 HTTP 요청 실패율이 10.61%까지 증가했다. 따라서 이 수치는 서버 장애율과 동일하게 해석하지 않았다.

시나리오	평균 응답시간	P95 응답시간	RPS	HTTP 요청 실패율	판정
A (독서 기록 조회)	781ms	2,730ms	44.95/s	0%	⚠️ P95 초과
B (독서 기록 작성)	762ms	2,800ms	45.62/s	0%	⚠️ P95 초과
C (통계/목표 확인)	267ms	1,390ms	75.11/s	0%	✅
D (커뮤니티 탐색)	387ms	1,850ms	64.83/s	10.61%	⚠️ 실패율 초과

시나리오 A~D 결과

통합 시나리오 결과

통합 테스트에서는 단독 테스트와 달리 각 시나리오의 최대 부하를 100 VU로 설정해, 네 시나리오를 합산한 최대 부하가 400 VU가 되도록 구성했다. 이때 평균 응답시간은 2,270ms, P95는 7,000ms로 증가했고 전체 HTTP 요청 실패율도 1.90%로 목표를 초과했다. RPS는 61.72/s로 처리량 기준은 만족했지만, 요청을 처리하는 동안 대기 시간이 크게 늘었기 때문에 안정적인 운영 구간으로 보기는 어려웠다.

지표	결과	목표	판정
평균 응답시간	2,270ms	< 1,000ms	❌
P95 응답시간	7,000ms	< 2,000ms	❌
HTTP 요청 실패율	1.90%	< 1%	❌
RPS	61.72/s	> 20	✅

통합 테스트 결과

결과 분석

단독 테스트와 통합 테스트의 차이는 응답시간에서 가장 크게 나타났다. 단독 테스트의 평균 응답시간은 267~781ms였지만 통합 테스트에서는 2,270ms로 약 3~8배 증가했다. P95도 단독 테스트 최대 2,800ms에서 통합 테스트 7,000ms로 상승했다. 여러 시나리오가 동시에 실행되면서 애플리케이션 서버의 제한된 CPU와 스레드 자원에 경합이 발생했을 가능성이 높다고 해석했다.

테스트 수행 중 관찰한 한계 구간은 100 VU 전후였다. 단독 시나리오에서는 50 VU인 Normal 단계까지 응답시간이 비교적 안정적으로 보였고, 100 VU인 Heavy 단계부터 지연 증가가 두드러졌다. 다만 게시글에 첨부한 k6 최종 요약값은 모든 stage를 합산한 결과이므로, 50 VU와 100 VU의 경계를 정량적으로 입증하려면 stage별 태그, CSV 결과 또는 시간대별 P95 그래프가 추가로 필요하다. 따라서 현재 결론은 이번 k6 시나리오와 실행 중 관찰을 기준으로 한 잠정적인 범위다.

메모리는 테스트 중 증가했지만 이번 측정 구간에서 계속 상승하는 패턴은 보이지 않았다. 테스트 전 323MB였던 컨테이너 메모리 사용량은 각 시나리오 후 570~609MB 범위에서 움직였고 통합 테스트 후에는 592MB를 기록했다.

시점	사용량
테스트 전	323MB
시나리오 A 후	570MB
시나리오 B 후	583MB
시나리오 C 후	609MB
시나리오 D 후	575MB
통합 테스트 후	592MB

통합 400 VU 테스트 이후에도 메모리 사용량은 592MB 수준이었다. 이번 테스트 구간에서는 메모리가 계속 증가하는 패턴이 관찰되지 않아 OOM이나 급격한 메모리 증가가 주된 병목일 가능성은 낮다고 봤다. 다만 몇 차례의 종료 시점 측정만으로 메모리 누수를 확정적으로 배제할 수는 없으며, 장시간 반복 테스트와 JVM 힙·GC·네이티브 메모리 지표를 추가로 확인해야 한다.

장시간 실행되는 단일 SQL이 주요 원인일 가능성은 낮았다. 테스트 종료 후 MySQL Slow Query Log를 확인했지만 1초 이상 실행된 쿼리는 기록되지 않았다. 다만 이 결과만으로 짧은 쿼리의 반복, 커넥션 풀 대기, RDS 자원 사용량을 모두 배제할 수는 없다. 부하가 증가할수록 응답시간이 급격히 상승했고 애플리케이션 서버가 1 vCPU 환경이라는 점을 고려하면 CPU 포화가 유력한 원인으로 추정되지만, 확정하려면 CloudWatch의 CPUUtilization·CPUCreditBalance와 애플리케이션 스레드 및 커넥션 풀 지표를 함께 확인해야 한다.

6. 부하테스트 중 발견한 이슈 - 좋아요 Race Condition

시나리오 D의 최초 테스트에서 전체 HTTP 요청 실패율은 21.67%였고, 좋아요 요청의 check 실패율은 약 66%로 나타났다. 처음에는 하나의 테스트 계정으로 좋아요와 좋아요 취소를 동시에 반복한 시나리오 문제로 봤지만, 서비스 코드를 확인하면서 동일 사용자의 중복 요청에서 실제로 발생할 수 있는 Check-Then-Act 형태의 Race Condition도 함께 발견했다.

원인 분석

CommunityService.likePost()는 먼저 existsByPostIdAndUserId로 기존 좋아요가 있는지 확인한 뒤, 좋아요가 없으면 INSERT를 수행하는 구조였다.

수정 전 좋아요 로직

문제는 존재 여부를 확인하는 SELECT와 실제 INSERT가 하나의 원자적 연산이 아니라는 점이다. 두 요청이 거의 동시에 들어오면 두 스레드 모두 좋아요가 없다고 판단한 뒤 INSERT를 시도할 수 있다.

Thread A: 좋아요 없음 확인 (1번 통과)
Thread B: 좋아요 없음 확인 (1번 통과)
Thread A: INSERT 성공
Thread B: INSERT 시도 → DB unique constraint 위반 → 409

이 경우 먼저 실행된 INSERT는 성공하지만 뒤늦게 실행된 요청은 데이터베이스의 unique constraint를 위반한다. 이 문제는 서로 다른 사용자가 같은 게시글을 좋아요 할 때가 아니라, 동일 사용자가 같은 게시글에 요청을 거의 동시에 중복 전송할 때 발생한다. 빠른 연속 클릭, 여러 탭에서의 요청, 네트워크 재시도처럼 실제 운영에서도 발생할 수 있는 전형적인 Check-Then-Act 경쟁 조건이다.

수정과 검증

애플리케이션에서 수행하던 사전 존재 여부 확인을 제거하고, 중복 데이터 방지는 데이터베이스의 unique constraint에 맡겼다. 중복 INSERT에서 DataIntegrityViolationException이 발생하면 이미 좋아요가 존재하는 경우로 변환하도록 변경했다. 단, JPA의 제약조건 위반은 트랜잭션 commit 시점에 발생할 수도 있으므로 예외를 현재 try-catch 안에서 확실히 처리하려면 saveAndFlush() 또는 명시적인 flush()를 사용해야 한다.

1. 사전 조회를 제거하고 DB unique constraint로 중복을 처리한 좋아요 로직 2. 특정 게시글에 요청이 집중되지 않도록 무작위 게시글을 선택한 k6 시나리오

 

이 방식은 중복 요청이 동시에 들어와도 데이터베이스가 최종적으로 중복 저장을 방지한다. 동시에 매 요청마다 실행되던 existsByPostIdAndUserId SELECT도 제거되어 쿼리 수를 줄였다. 테스트 시나리오에서도 특정 게시글 하나에 요청이 집중되지 않도록 조회된 게시글 중 하나를 무작위로 선택하도록 변경했다. 다만 모든 VU가 같은 계정을 공유하는 구조 자체는 유지됐기 때문에 동일한 post_id + user_id 조합의 충돌 가능성은 남아 있었다.

항목	수정 전	수정 후
전체 HTTP 요청 실패율	21.67%	10.61%
좋아요 check 성공률	34%	68%
좋아요 check 실패율	약 66%	약 32%

수정 후 전체 HTTP 요청 실패율은 21.67%에서 10.61%로 줄었고, 좋아요 check 성공률은 34%에서 68%로 증가했다. 여기서 409 Conflict는 서버가 요청을 처리하지 못한 장애라기보다 동일 계정의 중복 좋아요를 거절한 응답이지만, k6에서는 기본적으로 실패 요청으로 집계된다. 따라서 이 실패율을 서버 가용성 실패율로 그대로 해석하지 않았다. 실제 운영에서는 서로 다른 사용자가 서로 다른 unique key를 사용하므로 테스트보다 충돌 빈도가 낮을 수 있지만, 동일 사용자의 더블 클릭이나 재시도는 여전히 가능하므로 데이터베이스 제약조건을 통한 보호는 필요하다. 이 문제는 순차적으로 실행되는 일반적인 테스트보다 다수의 요청이 동시에 도착하는 부하테스트에서 재현하기 쉬웠다.

7. 결론 및 한계

이번 k6 시나리오에서는 단일 시나리오 50 VU 구간까지 비교적 안정적으로 관찰됐다. 100 VU 구간부터 지연 증가가 두드러졌고 150 VU에서는 응답시간이 더 크게 증가했다. 네 개 시나리오를 동시에 실행한 최대 400 VU 통합 테스트에서는 P95가 7초까지 상승했다. 다만 VU는 실제 동시 사용자 수와 동일한 개념이 아니며, stage별 정량 자료를 추가하기 전까지 50 VU를 절대적인 수용 한계로 단정하지 않았다.

다만 이번 결과에는 단일 계정을 사용한 테스트 구조의 한계가 있다. 실제 운영에서는 사용자마다 서로 다른 데이터에 접근하지만 이번 테스트에서는 모든 VU가 같은 계정과 데이터를 공유했다. 특히 좋아요 API의 HTTP 요청 실패율은 이 차이를 크게 반영한다. 운영 환경을 더 정확히 재현하려면 VU별 계정을 사전에 준비하고 각 VU가 서로 다른 데이터에 접근하도록 시나리오를 개선해야 한다.

현재 자료에서는 CPU 포화가 가장 유력한 병목 가설이다. Slow Query Log에서 1초를 넘는 개별 SQL은 발견되지 않았고, 짧은 테스트 구간에서 메모리가 계속 증가하는 패턴도 보이지 않았다. 반면 부하 증가에 따라 응답시간이 급격히 악화됐고 애플리케이션 서버는 1 vCPU 환경이었다. 다만 CPU 병목을 확정하려면 CloudWatch의 CPU 사용률과 CPU 크레딧, 스레드 풀 및 커넥션 풀 대기 지표를 추가로 수집해야 한다. 포트폴리오 프로젝트에서는 이 검증과 함께 같은 사양에서 불필요한 연산과 블로킹을 줄이는 코드 레벨 개선을 우선 적용할 계획이다.

개선 방법	기대 효과
통계 API Redis 캐싱	DB 쿼리 감소, CPU 사용량 절감
알림 발송 비동기 처리	응답 블로킹 제거, 스레드 점유 시간 감소
Gzip 압축 활성화	데이터 전송량 감소
HikariCP 커넥션 풀 튜닝	t2.micro 기준 적정값으로 조정

후속 작업에서는 통계 API의 Redis 캐싱, 알림 발송의 비동기 처리, Gzip 압축, HikariCP 커넥션 풀 조정을 순서대로 검토하고 동일한 시나리오로 다시 테스트해 각 변경이 P95와 RPS에 미치는 영향을 비교할 예정이다. 이후 테스트에서는 VU별 계정과 stage별 지표를 사용해 정상적인 409 응답과 실제 서버 오류를 분리하고, 한계 구간도 정량적으로 다시 검증할 계획이다.