taetae-o 님의 블로그

Spring AI 기반 운동 피드백 기능 1차 구현 정리

taetae-o — Sat, 18 Jul 2026 15:46:24 +0900

1. 목표

단순 자유 질의형 챗봇이 아니라, 사용자의 운동 데이터를 기반으로 피드백을 생성하는 AI 운동 코치 API를 구현하는 방향으로 진행했다.

현재 구현 범위는 다음과 같다.

단일 운동 데이터 입력 기반 AI 피드백 API
운동 기록 RDB 저장
운동 기록 텍스트 content 생성
OpenAI embedding 생성
PostgreSQL pgvector 기반 VectorDB 저장
Spring AI 기반 LLM 스트리밍 호출
SSE 기반 실시간 응답
테스트 기반 검증

지식 RAG 검색은 아직 피드백 호출 흐름에 직접 적용하지 않았다. 현재는 먼저 사용자의 운동 기록을 VectorDB에 쌓는 단계까지 구현했고, 이후 RAG 검색 기반 프롬프트 확장은 별도 기능으로 추가할 계획이다.

2. 프로젝트 MVP

2.1 MVP 기능

현재 MVP는 단일 운동 피드백 생성이다.

사용자는 러닝 또는 사이클링 운동 데이터를 입력한다.
서버는 해당 운동 데이터를 저장하고, AI가 분석 가능한 형태로 변환한 뒤 LLM에 전달하여 피드백을 생성한다.

지원하는 운동 타입은 다음과 같다.

RUNNING
CYCLING

사용자가 설정한 피드백 등급은 다음과 같다.

AMATEUR
PRO

등급에 따라 프롬프트 톤과 분석 수준을 다르게 가져간다.

2.2 단일 운동 피드백 흐름

운동 데이터 입력
→ Controller에서 요청 수신
→ Workout 도메인으로 변환
→ 운동 기록 RDB 저장
→ 운동 기록을 임베딩용 content로 변환
→ OpenAI Embedding API 호출
→ PostgreSQL pgvector 테이블에 저장
→ 운동 타입별 Prompt 생성
→ Spring AI로 LLM 스트리밍 호출
→ SSE로 사용자에게 피드백 전달

3. 기술 선택과 구조

3.1 Spring MVC + JPA + Virtual Thread

초기에는 WebFlux/R2DBC 구조도 고려했지만, 현재 프로젝트는 다음 구조로 정리했다.

Spring MVC
Spring Data JPA
PostgreSQL
pgvector
Spring AI
Java Virtual Thread
SSE

운동 기록은 JPA 연관관계 매핑을 사용하는 편이 자연스럽다.
또한 AI API 호출은 외부 I/O가 중심이므로, MVC 환경에서도 Virtual Thread를 사용하면 동시 요청 처리 부담을 줄일 수 있다.

컨트롤러에서는 SSE 응답 처리를 위해 SseEmitter를 사용한다.

@PostMapping(value = "/single/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public SseEmitter generateSingleWorkoutFeedbackStream(@RequestBody FeedbackRequest request) {

    Member member = Member.of(1L, "temporary-user");
    Workout workout = workoutMapper.toWorkout(request);
    SseEmitter emitter = new SseEmitter(0L);

    Thread.startVirtualThread(() -> {
        try {
            coachFeedback.getFeedbackStream(
                    member, workout, request.tier(), chunk -> send(emitter, chunk));
            emitter.complete();
        } catch (Exception e) {
            emitter.completeWithError(e);
        }
    });

    return emitter;
}

현재 Member.of(1L, "temporary-user")는 실제 인증 적용 전 수동 테스트를 위한 임시 처리다.
운영 구조에서는 Spring Security의 인증 사용자 정보를 기반으로 Member를 주입하는 방식으로 변경할 예정이다.

4. Hexagonal Architecture 기반 패키지 구조

프로젝트 패키지는 크게 다음과 같이 분리했다.

project
├── adapter
│   ├── in
│   │   └── mapper
│   └── out
│       └── persistence
├── application
│   ├── in
│   ├── out
│   ├── service
│   ├── workout
│   └── prompt
│       ├── embedding
│       ├── template
│       │   └── section
│       └── workout
└── domain

4.1 Domain

도메인은 Spring 의존 없이 구성했다.

주요 도메인:

Member
RunningWorkout
CyclingWorkout
WorkoutVector
AthleteTier
WorkOutType

예를 들어 RunningWorkout은 생성 시점에 핵심 불변식을 검증한다.

@Override
public void validate() {
    if (startedAt == null) {
        throw new IllegalArgumentException("운동 시작 시간(startedAt)은 필수 값입니다.");
    }
    if (endedAt == null) {
        throw new IllegalArgumentException("운동 종료 시간(endedAt)은 필수 값입니다.");
    }
    if (endedAt.isBefore(startedAt)) {
        throw new IllegalArgumentException("운동 종료 시간(endedAt)은 시작 시간(startedAt)보다 빠를 수 없습니다.");
    }
    if (movingTime != null && movingTime <= 0) {
        throw new IllegalArgumentException("운동 시간(movingTime)은 0보다 커야 합니다.");
    }
    if (distance != null && distance < 0) {
        throw new IllegalArgumentException("운동 거리(distance)는 음수가 될 수 없습니다.");
    }
    if (steps != null && steps < 0) {
        throw new IllegalArgumentException("걸음 수(steps)는 음수가 될 수 없습니다.");
    }
}

4.2 Application In Port

외부에서 들어오는 유스케이스는 application/in에 정의했다.

public interface CoachFeedback {

    void getFeedbackStream(
            Member member,
            Workout workout,
            AthleteTier tier,
            Consumer<String> chunkConsumer
    );
}

운동 벡터 저장 유스케이스도 인터페이스로 분리했다.

public interface WorkoutVectorSaver {

    UUID save(Member member, Workout workout, AthleteTier tier);
}

4.3 Application Out Port

외부 시스템으로 나가는 의존성은 application/out에 정의했다.

AiSender
EmbeddingGenerator
MemberRepository
RunningWorkoutRepository
CyclingWorkoutRepository
WorkoutVectorRepository

이렇게 분리하면 application service는 JPA, JDBC, Spring AI 구현체를 직접 알지 않아도 된다.

5. 핵심 구현 1: 단일 운동 피드백 유스케이스

CoachFeedbackService는 단일 운동 피드백의 상위 흐름을 담당한다.

@Service
@RequiredArgsConstructor
public class CoachFeedbackService implements CoachFeedback {

    private final AiSender aiSender;
    private final AiPromptBuilder aiPromptBuilder;
    private final WorkoutRecordSaver workoutRecordSaver;
    private final WorkoutVectorSaver workoutVectorSaver;

    @Override
    public void getFeedbackStream(
            Member member,
            Workout workout,
            AthleteTier tier,
            Consumer<String> chunkConsumer
    ) {
        Long workoutId = workoutRecordSaver.save(member, workout, tier);

        workoutVectorSaver.save(member, workoutId, workout, tier);

        String prompt = aiPromptBuilder.build(workout, tier);

        aiSender.sendStream(prompt, chunkConsumer);
    }
}

이 서비스는 다음 순서를 오케스트레이션한다.

WorkoutRecordSaver로 운동 기록을 RDB에 저장한다.
저장된 workoutId를 기반으로 WorkoutVectorSaver가 VectorDB 저장을 수행한다.
운동 데이터 기반 프롬프트를 생성한다.
AI 스트리밍을 호출한다.

이제 RDB 운동 기록 저장과 VectorDB 저장 책임이 분리되었다.

6. 핵심 구현 2: 운동 기록 저장과 VectorDB 저장 책임 분리

운동 기록 저장은 WorkoutRecordSaver 유스케이스 포트가 담당한다.

public interface WorkoutRecordSaver {

    Long save(Member member, Workout workout, AthleteTier tier);
}

구현체인 WorkoutRecordSaveService는 운동 타입별 저장 전략 registry를 감싼다.

@Service
@RequiredArgsConstructor
public class WorkoutRecordSaveService implements WorkoutRecordSaver {

    private final WorkoutSaveStrategyRegistry workoutSaveStrategyRegistry;

    @Override
    public Long save(Member member, Workout workout, AthleteTier tier) {
        return workoutSaveStrategyRegistry.save(member, workout, tier);
    }
}

VectorDB 저장은 WorkoutVectorSaver가 담당한다.
이미 저장된 운동 기록 ID를 받아 content 생성, embedding 생성, pgvector 저장만 수행한다.

@Service
@RequiredArgsConstructor
public class WorkoutVectorSaveService implements WorkoutVectorSaver {

    private final WorkoutEmbeddingContentBuilderRegistry contentBuilderRegistry;
    private final EmbeddingGenerator embeddingGenerator;
    private final WorkoutVectorRepository workoutVectorRepository;

    @Override
    public UUID save(Member member, Long workoutId, Workout workout, AthleteTier tier) {
        String content = contentBuilderRegistry.build(workout, tier);

        float[] embedding = embeddingGenerator.generate(content);

        WorkoutVector workoutVector = WorkoutVector.create(new CreateWorkoutVectorCommand(
                member.getId(),
                workoutId,
                workout.getWorkOutType(),
                content,
                createMetadata(workout, tier),
                embedding
        ));

        return workoutVectorRepository.save(workoutVector);
    }
}

현재 저장 흐름은 다음을 보장한다.

운동 기록은 RDB에 먼저 저장된다.
저장된 운동 기록 ID를 workout_id로 VectorDB에 함께 저장한다.
VectorDB 저장 서비스는 RDB 저장을 직접 수행하지 않는다.
운동 타입별로 임베딩 원문 content를 다르게 생성한다.
OpenAI embedding 결과를 pgvector 컬럼에 저장한다.
이후 WorkoutVectorSaver는 비동기 색인 작업으로 분리하기 쉬운 구조가 되었다.

7. 핵심 구현 3: 전략 패턴 기반 운동 타입 확장

운동 타입이 늘어날 때 switch문을 계속 수정하지 않도록 전략 패턴을 적용했다.

7.1 요청 → 도메인 변환 전략

public interface WorkoutRequestMapper {

    WorkOutType supportType();

    Workout toWorkout(FeedbackRequest request);
}

WorkoutMapper는 등록된 전략 중 운동 타입에 맞는 mapper를 선택한다.

@Component
public class WorkoutMapper {

    private final Map<WorkOutType, WorkoutRequestMapper> mappers;

    public WorkoutMapper(List<WorkoutRequestMapper> mappers) {
        this.mappers = mappers.stream()
                .collect(Collectors.toMap(
                        WorkoutRequestMapper::supportType,
                        Function.identity()
                ));
    }

    public Workout toWorkout(FeedbackRequest request) {
        if (request.workOutType() == null) {
            throw new IllegalArgumentException("운동 종목(workOutType)은 필수 값입니다.");
        }

        WorkoutRequestMapper mapper = mappers.get(request.workOutType());
        if (mapper == null) {
            throw new IllegalArgumentException("지원하지 않는 운동 타입입니다: " + request.workOutType());
        }

        return mapper.toWorkout(request);
    }
}

새 운동 타입을 추가할 때는 해당 운동 전용 mapper만 추가하면 된다.

7.2 운동 기록 저장 전략

상위 유스케이스 포트는 application/in의 WorkoutRecordSaver이고, 운동 타입별 분기 로직은 application/workout 패키지의 전략으로 분리했다.

application/in
├── WorkoutRecordSaver
└── WorkoutVectorSaver

application/workout
├── WorkoutSaveStrategy
├── RunningWorkoutSaveStrategy
├── CyclingWorkoutSaveStrategy
└── WorkoutSaveStrategyRegistry

운동 타입별 저장 전략 인터페이스는 다음과 같다.

public interface WorkoutSaveStrategy {

    WorkOutType supportType();

    Long save(Member member, Workout workout, AthleteTier tier);
}

러닝 저장 전략:

@Component
@RequiredArgsConstructor
public class RunningWorkoutSaveStrategy implements WorkoutSaveStrategy {

    private final RunningWorkoutRepository runningWorkoutRepository;

    @Override
    public WorkOutType supportType() {
        return WorkOutType.RUNNING;
    }

    @Override
    public Long save(Member member, Workout workout, AthleteTier tier) {
        if (!(workout instanceof RunningWorkout runningWorkout)) {
            throw new IllegalArgumentException("러닝 운동 데이터가 아닙니다.");
        }

        return runningWorkoutRepository.save(member, runningWorkout, tier);
    }
}

7.3 임베딩 content 생성 전략

public interface WorkoutEmbeddingContentBuilder {

    WorkOutType supportType();

    String build(Workout workout, AthleteTier tier);
}

러닝 content 예시:

[러닝 운동 기록]
사용자 등급: AMATEUR
운동 타입: RUNNING
운동 시작 시간: 2026-07-18T07:00
운동 종료 시간: 2026-07-18T07:45
거리: 8.20 km
운동 시간: 45 분
...
평균 페이스: 5.48 min/km
최고 페이스: 4.92 min/km
걸음 수: 7600

7.4 프롬프트 생성 전략

프롬프트 생성은 Template + Section 구조로 분리했다.
CoachFeedbackPromptBuilder는 application service가 사용하는 상위 진입점이고, 실제 단일 운동 프롬프트 조립은 SingleWorkoutPromptTemplate이 담당한다.

호출 구조는 다음과 같다.

CoachFeedbackService
→ CoachFeedbackPromptBuilder
→ SingleWorkoutPromptTemplate
→ SingleWorkoutPromptSection

CoachFeedbackPromptBuilder는 직접 문자열을 조립하지 않고, Workout과 AthleteTier를 SingleWorkoutPromptContext로 감싼 뒤 template에 위임한다.

@Component
public class CoachFeedbackPromptBuilder {

    private final PromptTemplate<SingleWorkoutPromptContext> singleWorkoutPromptTemplate;

    @Autowired
    public CoachFeedbackPromptBuilder(SingleWorkoutPromptTemplate singleWorkoutPromptTemplate) {
        this.singleWorkoutPromptTemplate = singleWorkoutPromptTemplate;
    }

    public String build(Workout workout, AthleteTier tier) {
        return singleWorkoutPromptTemplate.render(new SingleWorkoutPromptContext(workout, tier));
    }
}

Template은 등록된 section들을 순서대로 실행하고, 결과 문자열을 합쳐 최종 prompt를 만든다.

@Component
public class SingleWorkoutPromptTemplate
        implements PromptTemplate<SingleWorkoutPromptContext> {

    private final List<SingleWorkoutPromptSection> sections;

    public SingleWorkoutPromptTemplate(List<SingleWorkoutPromptSection> sections) {
        this.sections = sections.stream()
                .sorted(Comparator.comparingInt(SingleWorkoutPromptSection::order))
                .toList();
    }

    @Override
    public String render(SingleWorkoutPromptContext context) {
        return sections.stream()
                .map(section -> section.render(context))
                .collect(Collectors.joining("\n"));
    }
}

현재 단일 운동 프롬프트는 다음 section들로 구성된다.

SingleWorkoutPromptTemplate
├── SingleWorkoutSystemInstructionSection
├── SingleWorkoutCommonSection
├── SingleWorkoutSpecificSection
├── SingleWorkoutHallucinationGuardSection
└── SingleWorkoutOutputFormatSection

각 section의 책임은 다음과 같다.

SingleWorkoutSystemInstructionSection
- AMATEUR, PRO 등급별 코칭 톤과 분석 수준 지정
SingleWorkoutCommonSection
- 거리, 시간, 심박수, 케이던스 등 공통 운동 정보 생성
SingleWorkoutSpecificSection
- 운동 타입에 따라 러닝/사이클링 전용 section builder 선택
SingleWorkoutHallucinationGuardSection
- 제공된 데이터 외 추측 금지 규칙 추가
SingleWorkoutOutputFormatSection
- 응답 형식 고정

운동 타입별 분석 지표는 기존 전략을 그대로 사용한다.

public interface WorkoutPromptSectionBuilder {

    WorkOutType supportType();

    String build(Workout workout);
}

즉, 프롬프트 생성의 전체 흐름은 template이 담당하고, 바뀌는 조각은 section과 운동 타입별 builder가 담당한다.
나중에 1주일 피드백이나 RAG 지식 context가 추가되면 WeeklyWorkoutPromptTemplate, KnowledgeContextSection 같은 단위로 확장할 수 있다.

8. 핵심 구현 4: RDB Entity와 Domain 분리

저장용 Entity와 도메인 객체를 분리했다.

예를 들어 러닝 운동 기록 저장 Entity는 JPA 전용 객체다.

@Entity
@Table(name = "running_workout")
public class RunningWorkoutEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Enumerated(EnumType.STRING)
    private AthleteTier tier;

    @ManyToOne
    @JoinColumn(name = "member_id")
    private MemberEntity member;

    private LocalDateTime startedAt;
    private LocalDateTime endedAt;
    private Double distance;
    ...

    public static RunningWorkoutEntity from(
            RunningWorkout workout,
            AthleteTier tier,
            Member member
    ) {
        return new RunningWorkoutEntity(
                null,
                tier,
                MemberEntity.reference(member),
                workout.getStartedAt(),
                workout.getEndedAt(),
                workout.getDistance(),
                ...
        );
    }
}

도메인 객체는 JPA를 알지 않고, Entity는 persistence adapter 내부에만 존재한다.

9. 핵심 구현 5: PostgreSQL pgvector 저장

운동 벡터 저장 테이블은 schema.sql로 관리한다.

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE IF NOT EXISTS workout_vector_store (
    id uuid PRIMARY KEY,
    member_id bigint,
    workout_id bigint NOT NULL,
    workout_type varchar(30) NOT NULL,
    content text NOT NULL,
    metadata jsonb NOT NULL DEFAULT '{}'::jsonb,
    embedding vector(1536) NOT NULL,
    created_at timestamp NOT NULL
);

저장 adapter는 JDBC를 사용한다.
JPA가 pgvector 타입을 직접 다루기 어렵기 때문에, vector 저장소는 JdbcTemplate 기반으로 구현했다.

@Component
@RequiredArgsConstructor
public class WorkoutVectorRepositoryAdapter implements WorkoutVectorRepository {

    private final JdbcTemplate jdbcTemplate;
    private final ObjectMapper objectMapper;

    @Override
    public UUID save(WorkoutVector workoutVector) {
        WorkoutVectorEntity entity = WorkoutVectorEntity.from(workoutVector);

        jdbcTemplate.update("""
                        INSERT INTO workout_vector_store (
                            id,
                            member_id,
                            workout_id,
                            workout_type,
                            content,
                            metadata,
                            embedding,
                            created_at
                        )
                        VALUES (
                            CAST(? AS uuid),
                            ?,
                            ?,
                            ?,
                            ?,
                            CAST(? AS jsonb),
                            CAST(? AS vector),
                            ?
                        )
                        """,
                entity.getId().toString(),
                entity.getMemberId(),
                entity.getWorkoutId(),
                entity.getWorkoutType().name(),
                entity.getContent(),
                toMetadataJson(entity),
                toVectorLiteral(entity),
                entity.getCreatedAt()
        );

        return entity.getId();
    }
}

10. 테스트 전략

이번 구현은 테스트를 계층별로 분리했다. 이렇게 분리 한 이유는 다음과 같다

SpringBootTest시 별도의 Spring 컨테이너에서 실행되는것을 방지 해 테스트 속도 증가
테스트 환경 DB를 H2가 아닌 PostgreSQL Docker로 띄우기 때문에 동일한 컨테이너를 보도록 하기 위함
중복되는 테스트 환경 설정을 통합 하기 위함 입니다.

10.1 Test Support 분리

테스트 환경은 목적별 Support 클래스로 분리했다.

ProjectIntegrationTestSupport
├── SpringBootIntegrationTestSupport
├── DataJpaTestSupport
└── JdbcTestSupport

ProjectIntegrationTestSupport
- PostgreSQL/pgvector Testcontainers 공통 설정
SpringBootIntegrationTestSupport
- @SpringBootTest
- Application 통합 테스트
DataJpaTestSupport
- @DataJpaTest
- JPA Repository slice 테스트
JdbcTestSupport
- @JdbcTest
- pgvector JDBC Repository slice 테스트

10.2 Domain 단위 테스트

Spring 없이 도메인 불변식을 검증했다.

MemberTest
RunningWorkoutTest
CyclingWorkoutTest
WorkoutVectorTest

검증 내용 예시:

nickname 필수
운동 시작/종료 시간 필수
종료 시간이 시작 시간보다 빠르면 실패
운동 시간은 0보다 커야 함
운동 거리는 음수 불가
embedding vector 필수
embedding 방어적 복사

10.3 전략 패턴 단위 테스트

Spring 없이 전략 객체를 직접 생성해서 Registry에 주입하는 방식으로 테스트했다.

예시:

WorkoutEmbeddingContentBuilderRegistry registry =
        new WorkoutEmbeddingContentBuilderRegistry(List.of(
                new RunningWorkoutEmbeddingContentBuilder(),
                new CyclingWorkoutEmbeddingContentBuilder()
        ));

테스트 대상:

WorkoutEmbeddingContentBuilderRegistryTest
WorkoutSaveStrategyRegistryTest
CoachFeedbackPromptBuilderTest

검증 내용:

러닝이면 러닝 전략 선택
사이클이면 사이클 전략 선택
지원하지 않는 타입이면 실패
프롬프트에 공통/전용 지표 포함
응답 제한 규칙 포함
응답 형식 포함

10.4 Repository Slice 테스트

JPA Repository는 @DataJpaTest로 검증했다.

MemberRepositoryTest
RunningWorkoutRepositoryTest
CyclingWorkoutRepositoryTest

pgvector 저장소는 @JdbcTest로 검증했다.

WorkoutVectorRepositoryTest

10.5 Application 통합 테스트

WorkoutVectorSaverTest
- 이미 저장된 workoutId를 받아 vector 저장
- content 생성
- embedding 생성
- vector 저장
- 실패 시 예외 전파
CoachFeedbackTest
- 운동 기록 저장 → vector 저장 → AI 호출 순서 검증
- AI chunk 전달
- 운동 기록 저장 실패 시 vector 저장과 AI 호출 차단
- vector 저장 실패 시 AI 호출 차단
- AI 호출 실패 시 예외 전파

10.6 Controller Slice 테스트

@WebMvcTest로 Controller만 검증했다.

CoachFeedbackControllerTest

검증 내용:

러닝 JSON 요청 처리
사이클 JSON 요청 처리
도메인 객체 변환
CoachFeedback 호출
SSE 응답 반환

10.7 Architecture 테스트

Hexagonal Architecture의 의존성 방향이 깨지지 않도록 ArchUnit 기반 아키텍처 테스트를 추가했다.

ArchitectureTest

검증 규칙은 다음과 같다.

@ArchTest
static final ArchRule domain_should_not_depend_on_application_or_adapter =
        noClasses()
                .that().resideInAPackage(DOMAIN)
                .should().dependOnClassesThat().resideInAnyPackage(APPLICATION, ADAPTER);

@ArchTest
static final ArchRule application_should_not_depend_on_adapters =
        noClasses()
                .that().resideInAPackage(APPLICATION)
                .should().dependOnClassesThat().resideInAnyPackage(ADAPTER);

즉, 다음 의존성 역류를 테스트로 막는다.

domain → application / adapter 의존 금지
application → adapter 의존 금지
adapter.in → adapter.out 의존 금지
adapter.out → adapter.in 의존 금지

또한 layered architecture 규칙으로 전체 계층 접근 방향도 검증한다.

Domain
Application
InboundAdapter
OutboundAdapter

이 테스트 덕분에 RunningWorkoutEntity 같은 persistence 전용 객체가 application 계층으로 침투하는 문제를 조기에 발견할 수 있다.

전체 테스트 결과:

./gradlew test
BUILD SUCCESSFUL

11. 할루시네이션 대응 전략

이번 구현에서는 자유 질의형 챗봇보다 템플릿 기반 AI 기능을 우선한다. 이 방식 자체가 할루시네이션을 줄이는 전략이 될 수 있다고 생각 한다.

11.1 Template Routing

사용자가 아무 질문이나 입력하는 구조가 아니라, 서비스가 제공하는 기능을 선택하도록 제한한다.

현재 기능:

단일 운동 피드백

추가 예정 기능:

1주일 운동 기반 피드백

이렇게 하면 LLM이 답변해야 하는 범위가 좁아진다.

자유 질문
→ 모든 주제 가능
→ 도메인 밖 답변 가능성 증가

템플릿 기반 피드백
→ 운동 데이터 기반 답변으로 제한
→ 불필요한 질문 차단

11.2 Structured Prompt

운동 데이터를 자유 텍스트로 전달하지 않고, 고정된 구조로 전달한다.

[기본 운동 통계 정보]
- 운동 시작 시간
- 운동 종료 시간
- 운동 거리
- 운동 시간
- 평균 심박수 / 최대 심박수
- 평균 케이던스 / 최대 케이던스

[러닝 전용 분석 지표]
- 평균 페이스
- 최고 페이스
- 총 걸음 수

이 구조는 모델이 어떤 지표를 기준으로 피드백해야 하는지 명확히 알려준다.

11.3 Context Grounding Rule

프롬프트에는 다음과 같은 규칙을 추가할 수 있다.

제공된 운동 데이터에 근거해서만 피드백하세요.
제공된 데이터로 판단할 수 없는 내용은 추정하지 말고, 확인이 필요하다고 답하세요.

현재 프롬프트는 SingleWorkoutHallucinationGuardSection을 통해 이 규칙을 별도 section으로 포함한다.

[응답 제한 규칙]
- 반드시 제공된 운동 데이터에 근거해서만 피드백하세요.
- 제공되지 않은 신체 정보, 질병 정보, 과거 운동 이력은 추측하지 마세요.
- 판단할 수 없는 내용은 "제공된 데이터만으로는 판단하기 어렵습니다"라고 답하세요.

이후 RAG 적용 시에는 검색된 지식 context에 대해서도 같은 grounding rule을 적용할 예정이다.

11.4 Query Scope Guard

향후 자유 질문 기능을 열 경우, 먼저 질문이 운동 기록 피드백 범위 안에 있는지 검사할 수 있다.

사용자 질문
→ 운동 기록/피드백 관련 질문인지 판별
→ 관련 없음: 거절 응답
→ 관련 있음: RAG/LLM 진행

예시 응답:

이 서비스는 운동 기록 기반 피드백만 제공할 수 있습니다.
운동 기록, 페이스, 심박수, 주간 운동 추세와 관련된 질문을 선택해 주세요.

11.5 No Context, No Answer

RAG 적용 시 가장 중요한 전략이다.

VectorDB에서 관련 지식이나 운동 기록을 찾지 못한 경우, LLM에게 억지로 답변을 생성하게 하지 않는다.

사용자 질문
→ embedding 생성
→ VectorDB 검색
→ similarity threshold 확인
→ 관련 context 없음
→ LLM 호출 차단 또는 근거 부족 응답

예시 응답:

관련 운동 기록이나 지식 컨텍스트를 찾지 못해 정확한 답변을 제공하기 어렵습니다.
운동 기록을 먼저 입력하거나, 지원하는 피드백 템플릿을 선택해 주세요.

이 전략은 근거 없는 답변 생성을 줄이는 데 효과적이다.

12. 다음 구현 계획

12.1 1주일 운동 기반 피드백

다음 단계는 단일 운동 피드백과 별도로 1주일 기반 피드백 API를 추가하는 것이다.

예상 흐름:

사용자 식별
→ 최근 1주일 러닝/사이클링 기록 조회
→ 운동 기록 목록을 주간 요약 context로 변환
→ 주간 피드백 프롬프트 생성
→ LLM 스트리밍 호출

예상 엔드포인트:

POST /api/v1/coach/feedback/weekly/stream

12.2 RAG 기반 지식 검색 확장

이후에는 현재 저장 중인 운동 벡터와 별도로, 운동 지식 문서를 VectorDB에 저장하고 검색하는 기능을 추가할 계획이다.

최종 목표 흐름:

사용자 운동 기록 context
+
VectorDB에서 검색한 운동 지식 context
+
질문 템플릿
→ 최종 프롬프트 생성
→ LLM 호출

이때 No Context, No Answer, Similarity Threshold, Scope Guard 전략을 함께 적용할 예정이다.

12.3 인증 사용자 연동

현재는 수동 테스트를 위해 member_id = 1 사용자를 seed하고 컨트롤러에서 임시로 사용한다.

Member member = Member.of(1L, "temporary-user");

추후 Spring Security 적용 후에는 인증된 사용자 정보를 기반으로 Member를 조회하거나 주입할 예정이다.

지갑 잔액 차감 동시성 제어 및 락(Lock) 실험

taetae-o — Fri, 10 Jul 2026 04:22:47 +0900

실험 조건 및 가설

테스트 대상 도메인: 토스 실시간 간편 결제 플랫폼 시나리오 (지갑 잔액 차감 및 결제 이력 적재)
실험 엔티티 구조: 하나의 트랜잭션 내에서 Wallet WalletOptimistic 잔액 차감(UPDATE) 후, PaymentHistory 내역 생성(INSERT) 수행
최초 지갑 잔액: 10,000원
동시 요청 수: 100개 (32개 고정 스레드 풀 FixedThreadPool 활용)
회당 차감 금액: 100원 (총 10,000원 차감 시도)

본 실험에서 검증하고자 하는 '데이터 정합성(Data Integrity)'은 단순히 "모든 요청이 에러 없이 성공하여 잔액이 0원이 되었는가"가 아닙니다.
대규모 동시성 트래픽 속에서 락으로 인해 실패할지언정, 사용자가 확인한 성공 결과(결제 내역)와 실제 자산 금고(지갑 잔액)의 싱크가 단 1원의 오차도 없이 원자적으로 일치하는가를 본질적인 합격 기준으로 정의합니다.

데이터 정합성 검증 공식:

{실제 차감된 총 금액 (초기 잔액 - 최종 잔액)} = {적재된 결제 내역 수(historyCount)} * 100 {원}

Case 1: No Lock (아무런 제어 장치가 없는 동시성 요청)

락이 없는 경우 동시성 환경에서의 주문 내역과, 실제 차감된 돈의 정합성이 맞지 않는 문제가 발생한다
No Lock 정합성 테스트 결과 생성된 총 주문 내역 수: 100건 최종 남은 DB 실제 잔액: 8900원 지갑에서 실제로 차감된 총 금액: 1100원
애플리케이션 계층에서는 100건의 주문이 모두 정상 처리(200 OK)되어 결제 내역이 생성되었으나, 실제 DB 자산은 고작 1,100원(11회 분량)만 차감되었습니다. 결과적으로 8,900원의 금액 오차(자산 손실)를 입으며 시스템의 무결성을 지키지 못함

원인 분석

레이스 컨디션 진입:
- Thread A와 Thread B가 거의 동일한 밀리초(ms) 단위로 DB에서 동일 유저의 지갑 잔액(10,000원)을 읽어옵니다. 이 시점에 두 스레드가 자바 메모리상에 보유한 데이터는 둘 다 10,000원으로 동일합니다.
덮어쓰기 발생:
- 두 스레드는 각자 독립적으로 10,000원 - 100원 = 9,900원이라는 차감 연산을 수행합니다. 이후 Thread A가 먼저 DB에 9,900원을 반영하고 커밋하지만, 곧바로 뒤이어 도착한 Thread B가 A가 업데이트한 사실을 모른 채 자신이 계산한 9,900원을 DB에 그대로 덮어써 버립니다.
결론:
- 비즈니스적으로는 분명히 2번의 차감 요청이 수행되어 잔액이 9,800원이 되어야 하지만, 앞선 트랜잭션의 연산 결과가 유실(Lost Update)되면서 돈이 100원만 깎이는 현상이 100번의 요청 동안 무한히 반복된 것입니다.

Case 2 : 낙관적 락

낙관적 락을 사용하는 경우 동시성 환경에서의 주문 내역과 실제 차감된 돈의 정합성이 맞는다
낙관적 락 정합성 테스트 결과 생성된 총 주문 내역 수: 15건 최종 남은 DB 실제 잔액: 8500원 지갑에서 실제로 차감된 총 금액: 1500원 낙관적 락 실패 횟수: 85번
100개의 동시 요청 중 85건의 요청은 버전 충돌로 인해 실패 처리되었습니다. 최종적으로 오직 15건의 주문만 정상 완료되었으며, 지갑 잔액 또한 정확히 1,500원만 차감되었습니다.
[성공한 주문 수(15건) × 100원 = 실제 차감액(1,500원)] 공식이 완벽히 성립하여 자산 정합성이 완벽하게 보장됨을 증명합니다.

원인 분석

버전 관리를 통한 동시성 제어: WalletOptimistic 엔티티는 @Version 필드를 통해 낙관적 락을 수행합니다.
레이스 컨디션에서의 충돌: 동시성 환경에서 여러 스레드가 거의 동시에 DB를 조회(SELECT)하면, 스레드들이 읽어온 객체의 version 초기값은 모두 동일(예: version = 0)할 수 있게 됩니다.
조건절 불일치로 인한 예외 발생:
- 각 스레드가 연산을 마치고 UPDATE 쿼리를 날릴 때, JPA는 내부적으로 WHERE id = ? AND version = ? 조건과 함께 버전을 1 증가시키는 쿼리를 수행합니다.
- 가장 먼저 도착한 1등 스레드가 커밋을 성공시키는 순간, DB 내부의 version 컬럼은 1로 업데이트됩니다.
- 뒤이어 도착한 나머지 99개의 스레드들은 여전히 WHERE version = 0 조건으로 수정을 시도하기 때문에, DB 엔진 내에서 조건이 일치하는 행을 찾지 못해 수정된 행의 수(Affected Rows)가 0건이 됩니다.
- JPA는 이를 데이터 충돌로 인지하여 ObjectOptimisticLockingFailureException 예외를 던지고 트랜잭션을 롤백시킵니다.
트랜잭션 원자성 사수:
- 예외가 터지는 순간 스프링의 @Transactional 프록시 레이어는 해당 스레드의 트랜잭션을 통째로 롤백(Rollback) 시킵니다. 이 덕분에 지갑 잔액이 안 깎인 스레드는 아랫줄의 PaymentHistory 인서트 쿼리까지 함께 취소(유실)되어 주문 내역과 잔액의 싱크가 깨지지 않고 안전하게 보존되는 것입니다.

Case 3 : 비관적 락

비관적 락을 사용하는 경우 동시성 요청이 밀려올 때 애플리케이션이 아닌 DB 레벨에서 트래픽을 대기 시키기 때문에,
단 한 건의 실패(예외)도 없이 100건의 요청을 모두 성공시킵니다.
비관적 락 정합성 테스트 결과 생성된 총 주문 내역 수: 100건 최종 남은 DB 실제 잔액: 0원 지갑에서 실제로 차감된 총 금액: 10000원
낙관적 락과 달리 실패한 결제가 없습니다. 100개의 동시성 요청이 대기(Blocking)를 거쳐 모두 순차적으로 반영되었으며,
그 결과 지갑 잔액은 정확히 0원이 되었고 주문 히스토리도 유실 없이 100건이 적재되었습니다.

원인 분석

FOR UPDATE를 통한 로우 레벨 락(Row-level Lock) 선점:
- WalletPessimisticRepository에서 호출한 findByUserIdWithLock 메서드는 MySQL 엔진에 SELECT ... FOR UPDATE 쿼리를 날립니다.
  이 쿼리는 조회하는 동시에 해당 유저의 지갑 레코드(Row)에 다른 트랜잭션이 접근하지 못하도록 배타적 쓰기 락(X-Lock)을 걸어버립니다.
스레드 블로킹(Blocking) 메커니즘:
- 가장 먼저 도착한 1등 스레드가 락을 획득하고 트랜잭션을 시작하는 순간, 동시에 들이닥친 나머지 99개의 스레드는 예외가 발생하는 것이 아니라 1등 스레드가 연산을 마치고 커밋하여 락을 풀어줄 때까지 DB 문턱에서 대기(Blocking) 상태로 줄을 서게 됩니다.
갱신 손실(Lost Update)의 원천 차단:
- 2등 스레드는 1등 스레드가 10,000원 - 100원 = 9,900원으로 잔액을 완전히 업데이트하고 커밋한 이후의 상태를 바라보며 락을 이어받습니다.
  즉, 모든 스레드가 앞선 트랜잭션의 결과가 완전히 반영된 최신 잔액을 조회하여 차감 연산을 수행하므로, No Lock에서 발생했던 덮어쓰기(Lost Update) 현상이 원천적으로 불가능해집니다.
안정적인 비즈니스 흐름 보장:
- 트랜잭션이 실패하지 않고 순차적으로 통과하기 때문에, 지갑 차감 아랫줄에 있는 PaymentHistory 인서트문 또한 롤백 없이 100번 모두 안전하게 커밋됩니다.
  결과적으로 결제 내역과 지갑 자산이 완벽하게 1:1 매칭되는 무결한 데이터 상태가 완성됩니다.

알게된 점 (Lessons Learned)

- 이 문제는 비관적 락 테스트를 진행할 때 마주진 예외이다, 이 예외는 @Lock(LockModeType.PESSIMISTIC_WRITE) 로 Repository 메서드에 락을 걸게 되는데
  이렇게 락이 걸린 메서드가 트렌젝션이 실행되지 않는 곳에서 호출했을 경우 나타나가 된다
- @Lock(LockModeType.PESSIMISTIC_WRITE) 어노테이션이 부여된 리포지토리 메서드는 호출 시 MySQL 엔진에 SELECT ... FOR UPDATE 구문을 전송하여 쓰기 락(X-Lock)을 획득하게 된다.
  데이터베이스 메커니즘상 락의 수명 주기는 트랜잭션의 수명 주기와 같기 때문에(트랜잭션이 종료되어야 락이 해제됨). 따라서 락을 걸고 유지하려면 반드시 활성화된 트랜잭션@Transactional 범위 내부여야 한다.
  하지만 멀티스레드 비동기 연산이 끝난 후, 테스트 코드의 검증 레이어(메인 스레드)는 트랜잭션이 없는 맨바닥 상태였기 때문에 JPA 레이어에서 이를 부적절한 사용으로 판단하고 예외를 발생시킨 것이다.
org.springframework.dao.InvalidDataAccessApiUsageException : Query requires transaction be in progress, but no transaction is known to be in progress
어노테이션을 사용한 낙관적 락, 비관적 락 적용 방법
- 낙관적 락은 엔티티(Entity) 클래스의 특정 필드 위
- 비관적 락은 리포지토리(Repository) 인터페이스의 메서드 위에 사용한다
테스트 코드의 // when 부분에서 List<CompletableFuture<Void>> 생성 부분
- 테스트 코드를 작성하면서 이 List<CompletableFuture<Void>> 부분을 보면 IntStream 을 통해 100개의 CompletableFuture를 생성해 실행 시키는것을 알 수 있다.
  왜 이렇게 생성하는지 보니 동시성 환경에서 최신 자바 동시성 테스트 코드에서는 이 형식을 표준처럼 아주 많이 사용한다고 한다.
- 일반적인 for 반복문으로 CompletableFuture를 생성하고 반복문 외부에 선언된 List<CompletableFuture<Void>> 에 add 하는 코드와 동일한 동작을 하지만
  선언된 리스트가 밖에 있다보니 원자성과 불변성에서 코드상의 문제가 발생할 여지를 최소화 한다고 한다.
표 정리

비교 항목	낙관적 락 (@Version)	비관적 락 (@Lock)
기본 전제	충돌이 거의 없을 것이다	충돌이 무조건 있을 것이다.
락의 주체	애플리케이션 (JPA/Hibernate)	데이터베이스 엔진 (MySQL FOR UPDATE)
트래픽 밀릴 때	롤백 및 재시도 비용 급증 (성능 저하)	스레드 대기(Blocking)로 커넥션 풀 고갈 위험
데이터 무결성	충돌 시 에러 발생 (버전 불일치 예외)	원천 차단 (완벽한 무결성 보장)

낙관적 락은 가벼운 데이터, 낮은 충돌 확률일때 사용 비관적 락은 무거운 자산 데이터, 높은 충돌 확률일때 사용

만약 배달의민족, 쿠팡, 토스처럼 트래픽이 분당 수백만 건씩 몰리는 트래픽 환경이 되면 그때는 비관적 락도 쓰지 못합니다.

DB 커넥션 풀이 다 말라붙어서 서버가 터지게 되기 때문이다 그래서 실무에서는 DB를 잠그는 대신 Redis를 활용한 분산 락(Distributed Lock)을 쓰거나, Kafka 같은 메시지 큐(Message Queue)를 앞에 두어 트래픽 자체를 순차적으로 통과시키는 방식으로 고도화합니다.

https://github.com/oTAETAEo/db-playground/tree/main/src/main/java/com/taehyun/db_playground/mysql/lock/scenario01

db-playground/src/main/java/com/taehyun/db_playground/mysql/lock/scenario01 at main · oTAETAEo/db-playground

DB 사용시 발생할 수 있는 시나리오를 정의하고 학습하는 공간 입니다. Contribute to oTAETAEo/db-playground development by creating an account on GitHub.

github.com

MySQL 복합 인덱스로 빠른 조회 및 Using filesort 정렬 부하 해결하기

taetae-o — Thu, 9 Jul 2026 18:02:33 +0900

1. 실험 개요

목적: 결제 히스토리 테이블에서 특정 조건 조회 시, 인덱스 유무 및 인덱스 구성 방식에 따른 성능 변화를 측정하고 최적의 인덱스 전략을 확인합니다.
대상 테이블: payments_v1
데이터 스케일: 총 1,000,000 건 (100만 건)
실험 환경: Docker MySQL 8.x / Spring Boot 통합 테스트 환경

2. 테스트 시나리오

비즈니스 요구사항"특정 유저가 지정한 특정 기간 동안 결제에 성공(SUCCESS) 한 내역 중, 카드(CARD) 결제 건만 최신순(created_at DESC) 으로 화면에 노출합니다."

3. 성능 측정 결과 요약 (Benchmark)

실험 단계	소요 시간 (ms)	소요 시간 (초)	성능 개선율	비고
Case 1: No Index	294 ms	0.294 초	기준점 (100%)	Full Table Scan + Filesort 부하 발생
Case 2: 단일 인덱스 (`user_id`)	84 ms	0.084 초	약 71.4% 개선	Index Lookup 진입, `Using filesort` 잔존
Case 3: 복합 인덱스 (최적화)	79 ms	0.079 초	약 73.1% 개선	`type: range`, 정렬 연산 완전 제거

4. 단계별 실행 계획(EXPLAIN) 및 상세 분석

Case 1: 인덱스가 없는 상태 (No Index)

측정 결과: 294 ms (조회 건수: 4 건)
MySQL 실행 계획 (EXPLAIN):

id	select_type	table	type	rows	filtered	Extra
1	SIMPLE	p1_0	ALL	996,546	0.04	Using where; Using filesort

핵심 지표 분석:
- type: ALL: 100만 건 대용량 테이블을 처음부터 끝까지 전부 읽는 Full Table Scan이 발생하여 대량의 디스크 I/O 유발.
- rows: 996,546: 단 4건의 실데이터를 찾기 위해 내부 통계 공식상 약 100만 개에 달하는 행을 검사하는 비효율 발생.
- Extra: Using filesort: 인덱스를 통한 정렬 최적화가 불가능하여, 쿼리 실행 후 메모리(Sort Buffer)에서 무거운 파일 정렬 연산을 수행함.

Case 2: 단일 인덱스 적용 후 (`user_id`)

적용 인덱스: CREATE INDEX idx_user_id ON payments_v1(user_id);
측정 결과: 84 ms (조회 건수: 4 건)
MySQL 실행 계획 (EXPLAIN):

id	select_type	table	type	key	rows	filtered	Extra
1	SIMPLE	p1_0	ref	idx_user_id	15	0.37	Using where; Using filesort

핵심 지표 분석:
- type: ref: Full Table Scan에서 B-Tree 인덱스를 통한 고속 참조 조회(Index Lookup)로 변경.
- rows: 15: 탐색해야 할 행의 수가 100만 건에서 단 15건으로 대폭 감소하여 CPU 및 데이터 스캔 부하가 감소.
- Extra: Using filesort: user_id 조건은 인덱스를 탔으나, created_at DESC 정렬 조건을 인덱스가 지원하지 못해 메모리 정렬 연산이 여전히 존재.

Case 3: 복합 인덱스 적용 후 (최적화 상태)

적용 인덱스: CREATE INDEX idx_user_payment_created ON payments_v1(user_id, payment_type, payment_status, created_at);
측정 결과: 79 ms (조회 건수: 4 건)
MySQL 실행 계획 (EXPLAIN):

id	select_type	table	type	key	rows	filtered	Extra
1	SIMPLE	p1_0	range	idx_user_payment_created	4	100.00	Using index condition; Backward index scan

핵심 지표 분석:
- type: range: 복합 인덱스 구성 후, BETWEEN 조건으로 지정된 특정 3달간의 데이터 범위만 타깃하여 스캔했음을 의미.
- rows: 4 / filtered: 100.00: 최종 결과인 4건을 추출하기 위해 정확히 4건의 행만 검사함. 쓸데없이 읽고 버려진 데이터가 없는 탐색 효율성 100% 상태 달성.
- Extra: Backward index scan: Using filesort가 완벽히 제거됨. 인덱스 마지막 열에 created_at을 배치하여 이미 정렬된 인덱스 블록을 역방향으로 읽어 내림으로써 정렬 연산 비용을 0으로 구성.
- Extra: Using index condition: ICP(Index Condition Pushdown) 메커니즘이 작동하여 디스크에서 테이블 레코드를 읽기 전 스토리지 엔진 레벨에서 조건을 선 필터링, 불필요한 디스크 I/O를 원천 차단함.

알게된 점 (Lessons Learned)

복합 인덱스 설계의 대원칙 규칙
복합 인덱스 구성 시 딱 떨어지는 동등 조건(=) 컬럼들을 전방에 배치하고, 범위 조건
(BETWEEN, >, <)이나 정렬 조건(ORDER BY) 컬럼을 후방에 배치해야 인덱스의 전 구간 스캔 효율이 극대화된다는 사실을 실측 데이터로 확인했습니다.
테스트 가독성 및 유지보수성 향상
테스트 코드 작성 시 하드코딩된 값 대신 고정 시점 필터를 매개변수(Parameter)로 추출하여 주입함으로, 가독성이 높고 시점이 고정되어 시간이 지나도 깨지지 않는 안정성 있는 테스트 코드를 작성하는 방법을 알게 되었습니다.
AssertJ 고급 검증 API의 활용

public SELF isSortedAccordingTo(Comparator<? super ELEMENT> comparator)

Comparator를 통해 리스트의 요소들이 원하는 정렬 기준(예: 최신순 DESC)에 맞춰 정상적으로 정렬되어 넘어왔는지 최종 검증할 수 있습니다.

public SELF allSatisfy(Consumer<? super ELEMENT> requirements)

리스트의 모든 요소가 람다식 내의 검증 조건을 통과하는지 반복문 없이 가독성 높게 전수 검증할 수 있습니다.

https://github.com/oTAETAEo/db-playground/tree/main/src/main/java/com/taehyun/db_playground/mysql/index/scenario01_payment_history

db-playground/src/main/java/com/taehyun/db_playground/mysql/index/scenario01_payment_history at main · oTAETAEo/db-playground

DB 사용시 발생할 수 있는 시나리오를 정의하고 학습하는 공간 입니다. Contribute to oTAETAEo/db-playground development by creating an account on GitHub.

github.com

Webhook 수신 운동 데이터 처리시 메모리 폭주 트러블 슈팅(JMC 추적)

taetae-o — Wed, 8 Jul 2026 17:34:51 +0900

간단 요약

대용량 Terra Activity 웹훅 payload를 처리할 때 발생하던 메모리 스파이크를 줄이기 위해 웹훅 수신부와 운동 데이터 처리 워커를 스트리밍 방식으로 변경했다.

테스트 : 10명이 동시에 나눠서 총 100번 8.9M 크기의 운동데이터를 가진 json 데이터 전송

동일한 k6 비교 테스트 기준으로 `byte[]` 총 할당량은 18.6 GiB → 1.42 GiB로 줄었고, 약 92.4% 감소했다. Heap peak 역시 약 3 GiB → 384 MiB 수준으로 낮아졌다.

즉, 기존처럼 request body와 압축 해제 데이터를 JVM Heap에 통째로 올리던 구조에서 벗어나, 데이터를 스트림으로 흘려보내며 처리하도록 변경해 메모리 사용량을 크게 줄였다.

성능 측정 항목	변경 전 (A안: 메모리 적재)	변경 후 (B안: 임시 파일 스풀링)	개선 효과 및 결과
byte[] 총 할당량 (Alloc Total)	18.6 GiB	1.42 GiB	약 92.4% 감소
byte[] 할당 지분율	81.50%	23.30%	58.2%p 감소
char[] 총 할당량 (Alloc Total)	217 MiB	191 MiB	약 12% 감소
PropertyValueBuffer 총 할당량	102 MiB	55.6 MiB	약 45.5% 감소
힙 메모리 정점 (Heap Peak)	약 3.0 GiB	약 384 MiB	서버 다운 위험 제거 (대폭 감소)
최상위 부하 지점 (Hot Spot)	Arrays.copyOfByteArrayOutputStream	java.lang.DoubleActivityGraphSampleExtractor	메모리 낭비 원천 차단 (순수 비즈니스 연산으로 이동)

문제 사항 분석 (JMC)

K6 사용해 메모리 개선 효과를 확인하기 위한 테스트 10명이 동시에 나눠서 총 100번 8.9M 크기의 운동데이터를 가진 json 데이터 전송

웹훅 수신 및 운동데이터 처리 워커의 byte[] 사용시 JVM 메모리 공간

테스트 중 byte[] 에 총 할당된것이 18.6GiB, JFR 레코딩 기간의 Total Allocation는 81.5% 잡아먹는 문제 발생

초반 webhook 수신부에서 사용한 byte[]로 받는 문제와 받은 운동 데이터를 워커가 처리하는 두가지 동작이 복합적으로 일어나다 보니 엄청난 JVM 메모리 공간을 차지하는걸로 보인다

아래 Stack Trace를 보게되면 하단 Thread를 실행하고 우리 서비스 클래스가 실행된것을 확인 해 보니

ZstdTerraPayloadCompressor

public byte[] decompress(...)

형태의 메서드를 사용하는것을 알 수 있었다, 우리 서비스 특성상 웹훅으로 들어온 큰 페이로드 데이터를 압축해 DB에 저장을 하는 방식을 사용하고 있고 이렇게 저장된 압축 데이터를 별도 구성한 워커로 처리하고 있었다.

데이터를 처리하는 워커 내부적으로 압축된 데이터를 메모리에서 풀기 때문에 압축 데이터 + 압축 해제 데이터가 같이 메모리에 공존하는 것 뿐만 아니라

byte[] 의 Flame Graph

이것을 보게 되면 압축 해제 메서드인 decompress(byte[]) 메서드를 실행한 직후 가로로 긴 막대가 생긴것을 알 수 있다, 여기서 가로는 메모리를 많이 사용하면 할 수록 가로 크기가 커진다고 생각하면 된다.

여기서 다른 막대와 길이가 비슷하다고 생각할 수 있지만 여기서 핵심은 자식이 없다는 것이다 다른 막대는 긴 막대 아래 자식 막대가 있는데 지금 사진을 보게되면 하단 자식 없이 Arrays.copy(byte[], int) 막대가 최 하단인 것을 알수 있다.

즉 운동 데이터를 웹훅으로 수신 받을때도 byte[] 사용으로 JVM 메모리 압박과 이후 운동 데이터가 압축 저장된 DB에서 압축 운동 데이터를 JVM에 전부 올리고나서 압축 해제까지 하는 복합적인 문제가 발생했다

AI도움을 받아 작성한 코드였지만 이걸 작성할때는 JVM의 메모리 부분을 생각하지도 못했던것 같다 ....

여기서 문제였던 메서드를 보자면

@Override
public byte[] decompress(byte[] payloadBytes) throws Exception {
    if (payloadBytes == null || payloadBytes.length == 0) {
        return new byte[0];
    }

    try (ZstdInputStream zstdInputStream = new ZstdInputStream(new ByteArrayInputStream(payloadBytes));
         ByteArrayOutputStream outputStream = new ByteArrayOutputStream(initialBufferSize(payloadBytes))) {
        zstdInputStream.transferTo(outputStream);
        return outputStream.toByteArray();
    }
}

이런 형식이다, 여기서 사용되는 transferTo(...) toByteArray(...) 가 문제였다.

public long transferTo(OutputStream out) throws IOException {
    Objects.requireNonNull(out, "out");
    long transferred = 0;
    byte[] buffer = new byte[DEFAULT_BUFFER_SIZE];
    int read;
    while ((read = this.read(buffer, 0, DEFAULT_BUFFER_SIZE)) >= 0) {
        out.write(buffer, 0, read);
        if (transferred < Long.MAX_VALUE) {
            try {
                transferred = Math.addExact(transferred, read);
            } catch (ArithmeticException ignore) {
                transferred = Long.MAX_VALUE;
            }
        }
    }
    return transferred;
}

public synchronized byte[] toByteArray() {
        return Arrays.copyOf(buf, count);
    }

transferTo(...) 메서드는 out.write(buffer, 0, read); 호출하고 내부적으로 ByteArrayOutputStream 의 write(...) 메서드를 호출
내부에 있는 ensureCapacity(...) 메서드를 호출 해 마지막에는 Arrays.copy(byte[], int) 호출 한다.

toByteArray(...) 메서드도 Arrays.copy(byte[], int) 를 사용하고 있는걸 알 수 있다.

여기서 알 수 있는것은 운동 압축 페이로드 하나를 풀기 위해서 총 3개의 큰 불필요한 byte[] 이 생성되었다는것을 알 수 있었다. 이런 이유 때문에 JVM의 메모리 부하가 일어난것을 알게 되었다.

특정 기술의 API를 사용할때 어떤식으로 동작하는지 JVM 메모리 관점에서도 생각해 봐야한다는것을 알게 되었다.

문제 1. 웹훅 수신부에서 request body를 byte[]로 전부 읽고 있었다 (웹훅 수신부)

처음 확인된 가장 큰 문제는 웹훅 수신부였다. 기존 Terra 웹훅 컨트롤러는 요청 본문을 @RequestBody byte[]로 받고 있었다.

  @PostMapping
  public ResponseEntity<Void> receiveWebhook(
      @RequestBody byte[] payload,
      @RequestHeader(...) String signature
  ) {
      ...
  }

이 구조에서는 HTTP request body가 컨트롤러 메서드에 들어오기 전에 이미 Spring MVC의 HttpMessageConverter에 의해 byte[]로 전부 읽힌다. 즉, 10MB payload가 들어오면 컨트롤러 로직이 시작되기 전에 이미 JVM Heap에는 10MB짜리 byte[]가 만들어진다.

HTTP request body

Spring ByteArrayHttpMessageConverter
byte[] payload
Controller 진입

문제는 여기서 끝나지 않는다. 컨트롤러 이후 로직에서는 이 byte[]를 기반으로 다음 작업들이 이어졌다.

byte[] payload

HMAC 서명 검증
payload 압축
event_type 추출
DB inbox 저장

대용량 request body가 처음부터 JVM Heap에 통째로 올라오고, 이후 처리 과정에서도 추가적인 byte[]와 내부 배열 복사가 발생할 수 있는 구조였다.

문제 2. DB에서 압축 payload를 byte[]로 전부 올리고 있었다 (워커)

기존 운동 데이터 처리 워커의 흐름은 대략 다음과 같았다.

DB payload_compressed 조회
압축된 데이터를 byte[]로 전부 로딩
압축 해제 결과도 byte[]로 전부 로딩
ActivityPayload DTO 역직렬화
센서 데이터 추출
그래프 생성
운동/Post 저장

즉, DB에는 압축된 payload를 저장하고 있었지만, 실제 처리 시점에는 압축된 데이터와 압축 해제된 JSON 데이터가 모두 JVM Heap에 올라오고 있었다.

특히 Terra Activity payload는 운동 시간이 길어질수록 커진다. 2시간 운동이라도 센서 샘플이 1초 단위로 쌓이면 수천 개 이상의 데이터가 포함되고, 기기/제공자에 따라 payload는 훨씬 커질 수 있다.

기존 구조에서는 payload가 커질수록 다음 메모리 비용이 한 번에 발생했다.

압축된 byte[]
압축 해제된 byte[]
ActivityPayload DTO
센서 sample 리스트
그래프용 중간 객체
그래프 JSON

이 구조에서는 worker가 한 개만 돌아도 큰 payload를 처리하는 순간 Heap이 튈 수밖에 없었다.

문제 3. 압축을 사용하고 있었지만 처리 경계는 스트리밍이 아니었다 (워커)

DB에는 압축된 payload를 저장하고 있었기 때문에 처음에는 메모리 사용이 어느 정도 제어되고 있다고 생각했다.

하지만 실제 병목은 저장 방식이 아니라 처리 경계에 있었다. 압축된 데이터를 DB에 저장하더라도, 처리할 때 다음처럼 사용하면 메모리 절감 효과가 줄어든다.

byte[] compressed = repository.findPayload(...);
byte[] json = compressor.decompress(compressed);
ActivityPayload payload = objectMapper.readValue(json, ActivityPayload.class);

이 방식은 압축 저장의 이점은 있지만, 처리 순간에는 결국 전체 JSON이 JVM Heap에 올라온다. 따라서 목표는 명확해졌다.

DB에서 payload를 읽는 순간부터 압축 해제, JSON 파싱까지 byte[] 전체 적재 없이 스트림으로 흘려보내자.

문제 4. ByteArrayOutputStream 내부 배열 복사 비용 (워커)

위 문제사항 분석에도 적어 두었지만 기존 구조에서는 압축된 payload를 byte[]로 읽고, 압축 해제 결과도 다시 byte[]로 만들었다.

이 과정에서 ByteArrayOutputStream이 사용되면 내부 버퍼가 부족할 때마다 더 큰 배열을 새로 만들고 기존 데이터를 복사한다.

흐름은 대략 다음과 같다.

압축 해제 스트림
ByteArrayOutputStream.write()
내부 buffer 부족
더 큰 byte[] 생성
Arrays.copyOf()
기존 데이터 복사
다시 write()

즉 최종 JSON 크기가 10MB라고 해서 딱 10MB만 할당되는 것이 아니다.

버퍼 확장 과정에서 다음과 같은 추가 비용이 발생한다.

중간 크기의 byte[] 여러 번 생성
기존 데이터 복사
GC 대상 byte[] 증가
CPU 복사 비용 증가

JFR에서도 이와 관련된 흔적이 보였다.

java.util.Arrays
java.io.ByteArrayOutputStream
byte[]

특히 payload가 커질수록 ByteArrayOutputStream의 내부 배열 확장은 더 비싸진다. 압축 해제된 JSON이 수십 MB라면, 그 크기만큼의 최종 배열뿐 아니라 중간 확장 배열과 복사 비용까지 함께 발생한다.

따라서 문제는 단순히 큰 byte[] 하나가 생긴다 가 아니라, 큰 byte[]를 만들기 위해 내부적으로 여러 번 배열이 확장/복사된다 는 점이었다.이 때문에 CPU 사용량과 GC 부담이 함께 증가했다.

문제 해결

위에서 알게된 문제점으로 인해 운동 데이터 처리 워커와 웹훅 수신부의 동작 방식을 변경하기로 결정했다

변경1. 웹훅 수신부를 스트리밍 방식으로 변경 (수신부)

기존에는 웹훅 요청을 @RequestBody byte[]로 받았다. 이 때문에 Spring MVC가 컨트롤러 진입 전에 request body 전체를 byte[]로 읽었고, 대용량 payload가 그대로 JVM Heap 에 올라갔다.

이를 해결하기 위해 @RequestBody byte[]를 제거하고, HttpServletRequest의 InputStream을 직접 읽도록 변경했다.

기존 구조

HTTP request body
@RequestBody byte[]
HMAC 검증
압축
DB 저장

변경 구조

[수신 + 검증 + 압축]

HTTP request InputStream

buffer
HMAC update
ZstdOutputStream
TempFile OutputStream

[이벤트 타입 추출]

TempFile InputStream
ZstdInputStream
Jackson JsonParser
event_type 추출

[DB 저장]

TempFile InputStream
JDBC BinaryStream
DB payload_compressed

[정리]

TempFile 삭제

변경 구조의 핵심은 request body를 한 번에 메모리에 올리지 않고, 스트림으로 흘려보내며 처리한 것이다. 수신된 데이터는 작은 buffer 단위로 읽으면서 HMAC 검증과 Zstd 압축을 동시에 수행하고, 압축 결과는 임시 파일에 저장한다.

이후 임시파일을 다시 스트림으로 열어 event_type을 추출하고, 같은 압축 파일을 JDBC BinaryStream으로 DB에 저장한다.

변경 2. DB BLOB을 BinaryStream으로 읽도록 변경 (워커)

먼저 DB에서 payload_compressed를 읽는 경계를 변경했다. 기존에는 압축 payload를 byte[]로 가져왔다면, 변경 후에는 JDBC의 getBinaryStream()을 사용해 BLOB 데이터를 스트림으로 읽도록 했다.

변경 후 흐름은 다음과 같다.

JDBC getBinaryStream()
압축 해제 InputStream
Jackson Streaming Parser
ActivityWebhookCommand 생성
기존 activity strategy 처리

이렇게 하면 DB에서 읽은 압축 데이터 전체가 JVM Heap에 한 번에 올라오지 않는다. 즉, 기존 구조가: DB BLOB → byte[] 였다면, 변경 후에는: DB BLOB → InputStream 이 되었다.

이 변경만으로도 압축 payload 자체로 인한 대형 byte[] 할당을 줄일 수 있었다.

변경 3. 압축 해제도 byte[]가 아니라 Stream으로 처리 (워커)

다음으로 압축 해제 경계도 변경했다. 기존에는 압축 데이터를 풀어서 byte[]로 만들었다.

compressed byte[]
decompressed byte[]

하지만 변경 후에는 압축 해제 결과를 InputStream으로 바로 넘긴다.

compressed InputStream
ZstdInputStream
JsonParser

즉, 압축 해제된 JSON 전체를 메모리에 올리지 않고, Jackson이 필요한 만큼 읽으면서 파싱하도록 변경했다. 이 구조에서는 압축 해제된 JSON이 거대한 byte[]로 존재하지 않는다

변경 4. Activity payload 파싱 경계를 분리 (워커)

운동 데이터 처리에는 두 종류의 데이터가 필요하다.

1. 일반 운동 메타데이터

운동 타입
시작/종료 시간
거리
칼로리
평균 심박
평균 속도
디바이스 정보 등

2. 센서/그래프 데이터

speed_samples
cadence_samples
power_samples
elevation_samples
distance_samples

기존에는 전체 JSON을 DTO로 역직렬화한 뒤, DTO 내부에서 센서 데이터를 다시 꺼냈다.변경 후에는 Jackson Streaming API를 사용해 JSON을 순회하면서 필요한 데이터를 추출하도록 했다.

JsonParser

일반 운동 데이터 추출
그래프 샘플 추출
ActivityWebhookCommand 구성

다만 이번 1차 작업에서는 그래프 처리 자체를 완전히 스트리밍 방식으로 바꾸지는 않았다. 그래프 생성 로직은 여전히 기존 ActivityGraphBuilder, ActivityGraphSampleExtractor, LTTB 다운샘플링 흐름을 유지 했다.

웹훅 수신부 + 워커 최종 흐름

[Webhook 수신부]

HTTP request InputStream
buffer read
HMAC update
ZstdOutputStream
TempFile 저장
TempFile InputStream
event_type 추출
JDBC BinaryStream
terra_webhook_inbox 저장
TempFile 삭제

[Inbox Processor / Worker]

terra_webhook_inbox.payload_compressed
JDBC getBinaryStream()
ZstdInputStream
Jackson JsonParser
ActivityWebhookCommand 생성
Cycling/Running Strategy
workout/post/graph 저장

웹훅 수신부에서는 request body를 byte[]로 만들지 않고 InputStream으로 읽으면서 HMAC 검증과 Zstd 압축을 동시에 수행한다. 압축 결과는 임시 파일에 저장한 뒤, 해당 파일을 다시 스트림으로 열어 event_type을 추출하고 DB에는 JDBC BinaryStream으로 저장한다.

이후 워커는 DB에 저장된 압축 payload를 getBinaryStream()으로 읽고, ZstdInputStream과 Jackson JsonParser를 연결해 전체 JSON을 메모리에 올리지 않고 운동 데이터를 처리한다.

핵심 차이는 byte[] 전체 적재를 제거하고 InputStream 기반 처리 로 메모리에 올려서 압축 헤제가 아닌 DB부터 Stream으로 읽으면서 압축 해제, json 파싱을 스트림으로 이어지게 바꾼 것이다

변경 후 지표

18.6 GiB ➔ 1.42 GiB 획기적인 감소

1차 워커 리팩토링과 2차 웹훅 수신부 리팩토링 이후, 동일한 k6 비교용 부하 테스트에서 byte[] 총 할당량이 크게 줄었다.

동일한 조건의 메모리 개선 효과를 확인하기 위한 테스트 조건은 다음과 같다.
  - k6 VUS: 10명
  - 총 요청 수: 100회
  - 요청 1건당 payload 크기: 약 8.9MB
  - 총 전송 데이터: 약 890MB

성능 측정 항목	변경 전 (A안: 메모리 적재)	변경 후 (B안: 임시 파일 스풀링)	개선 효과 및 결과
byte[] 총 할당량 (Alloc Total)	18.6 GiB	1.42 GiB	약 92.4% 감소
byte[] 할당 지분율	81.50%	23.30%	58.2%p 감소
char[] 총 할당량 (Alloc Total)	217 MiB	191 MiB	약 12% 감소
PropertyValueBuffer 총 할당량	102 MiB	55.6 MiB	약 45.5% 감소
힙 메모리 정점 (Heap Peak)	약 3.0 GiB	약 384 MiB	서버 다운 위험 제거 (대폭 감소)
최상위 부하 지점 (Hot Spot)	Arrays.copyOfByteArrayOutputStream	java.lang.DoubleActivityGraphSampleExtractor	메모리 낭비 원천 차단 (순수 비즈니스 연산으로 이동)

변경 전에는 웹훅 수신부와 운동 데이터 처리 워커가 동시에 동작하는 초반 구간에서 Heap 사용량이 급격히 치솟았다. 반면 변경 후에는 동일한 부하에서도 Heap 스파이크가 크게 완화되었다. 이후 운동 데이터가 지속적으로 처리되는 동안에는 Heap 사용량이 톱니 모양으로 오르내렸고, GC 이후 다시 안정적인 수준으로 회복되는 것을 확인할 수 있었다.

Platform Thread vs Virtual Thread의 AI I/O 블로킹 효율 비교

taetae-o — Sat, 4 Jul 2026 04:49:14 +0900

Platform Thread

Platform Thread는 운영체제의 1:1 스레드 매핑 방식을 선택했습니다. 여기서 1:1 매핑이란 사용자 영역에 존재하는 JVM에서 생성된 스레드가 커널 영역의 스레드와 1대1 형태로 매핑된것을 말하며 스레드 스케줄링의 통제권을 운영체제 커널에 전적으로 위임 했다는 뜻 입니다.

1:1 매핑

이 방식을 선택 한 이유는 지금의 CPU는 멀티코어 환경으로 CPU의 성능을 최대로 사용하기 위함 입니다 OS 스케줄러가 TCB를 직접
관리 하면서 CPU의 멀티코어 자원에 자바 스레드를 골고루 분산 배치 해 물리적으로 동시에 연산이 가능하게 합니다.

초창기 자바는 1:N 매핑 방식을 사용했습니다 이 방식의 한계는 1개의 OS 스레드가 JVM의 여러 스레드를 관리 하는 방식으로 만약 하나의 스레드에서 I/O 블로킹이 발생 한다면 다른 스레드도 같이 대기 해 버리는 문제가 발생 했습니다.

이 문제를 해결 하기 위해 1:1 매핑 방식을 선택 함으로, 하나의 스레드가 I/O 블로킹이 발생하게 되면 OS 커널은 그 스레드를 재우고 커널 영역의 다음 스레드를 올려 작업을 진행하게 됩니다 이런 방식은 하나의 자바 스레드가 블로킹 되었을 때 프로세스 전체(혹은 다른 자바 스레드들까지) 같이 멈춰버리는 문제를 해결 합니다.

이런 방식에도 문제가 있습니다 사용자 영역에서 생성된 스레드는 커널 영역의 스레드와 1:1 매핑이 되기 때문에 사용자 영역에서 생성된 스레드가 많게 되면 커널 영역에 생성되어야 하는 스레드도 같이 증가하게 됩니다, 이런 방식은 CPU의 컨텍스트 스위칭 문제로 시스템 전체의 처리량을 떨어뜨릴 뿐 아니라 스레드 당 고정적으로 할당되는 스택 메모리로 인해 메모리 고갈 현상을 나타낼 수 있습니다.

또한 JVM 내부에서 커널 영역에 스레드를 하나 생성 해 달라는 시스템 콜을 하기 때문에 생성 비용이 비싼 작업을 하게 됩니다 비록 스레드 풀을 통해 스레드를 재사용함으로써 초기의 시스템 콜을 최소화할 수 있으나, 대규모 트래픽이 몰려 스레드 풀의 최대 크기를 넘어서는 요청이 들어올 경우, 제한된 스레드가 모두 I/O 블로킹에 묶여 후속 요청들이 대기 큐에서 정체되거나 타임아웃으로 실패하는 근본적인 병목 현상을 막을 수 없습니다

이런 문제를 해결 할 수 있는 기술중 Virtual Thread 가 있습니다

Virtual Thread

Virtual Thread는 수많은 가상 스레드(M)를 소수의 OS 스레드(N) 위에서 실행시키는 N:M 스레드 매핑 방식을 선택 해 사용합니다

가상 스레드 N:M

여기서 핵심은 Platform Thread는 OS 영역에 스케줄링을 위임 했다면 Virtual Thread는 사용자 영역에서 스케줄링을 한다는 점과

Carrier Platform Thread 가 커널 영역의 스레드와 1:1 매핑이 되어있다는 점 입니다.

커널에서 스케줄링, 사용자 영역에서 스케줄링의 큰 차이점은 스케줄링을 사용자가 제어할 수 있다는 점 입니다 여기서 핵심적인 동작을 하는것은 Carrier Platform Thread 입니다 이 스레드는 커널 영역의 스레드와 1:1 매핑이 되어있으면서 JVM의 사용자 영역에서의 스케줄링으로 작업 할 가상 스레드를 유동적으로 변경 할 수 있고 이렇게 되면 결과적으로 커널 영역의 OS 스케줄러는 오직 고정된
Carrier Thread 만을 바라보기 때문에, 유저 영역에서 가상 스레드가 교체되어도 이를 전혀 인지하지 못합니다. 즉, 스케줄링의 제어권을 애플리케이션(사용자)이 완벽히 쥐게 됨으로써, 커널 레벨의 컨텍스트 스위칭 부하를 원천적으로 차단하고 대규모 I/O 블로킹을 효율적으로 처리할 수 있게 됩니다

또한 1:1 매핑 방식에서 발생한 메모리 문제도 이제 커널 영역에서 생성되는 무거운 스레드 생성 방식이 아닌 JVM의 힙 영역에 생성되기 때문에 더욱 작은 공간을 가지는 스레드를 생성 해 내부에서 동적으로 공간을 변경 할 수 있고 GC를 통해 메모리 회수 등등 메모리 제어권을 사용자가 가지고 있어 이에 대한 최적화도 진행 할 수 있게 됩니다.

비교

테스트 환경

기본 플랫폼 스레드 풀 방식
가상 스레드 방식

Platform Thread를 사용해서 테스트를 진행 한 결과

사용자의 요청이 들어올때 스레드는 OS 영역에 무겁게 쌓이고, 대신 스레드가 미처 처리하지 못한 '수천 개의 요청 대기 객체(큐)와 통신 버퍼 객체가 힙 영역에 쌓여서 상승하고 있는 모습 입니다.

또한 Platform Thread를 사용함으로 요청 1개 당 1개의 커널 스레드와 JVM의 스레드가 매핑이 되어 하단 Thread 부분에 그래프가 급격히 상승하는 모습을 볼수 있습니다.

또한 스레드가 계속 Wait 상태였다 Park 상태로 들어가게 되는 모습을 볼수 있습니다, 이 문제는 요청 대기 큐는 동시성 큐이기 때문에 접근을 하려면 락을 얻어야 하는데 이 락을 얻기 위해서 경쟁이 심해지게 되면 Park 상태로 스레드 상태를 변경하게 됩니다.

아래 코드는 Platform Thread Pool을 만드는 코드로 내부적으로 LinkedBlockingQueue 를 가지고 있습니다.

ExecutorService executor = Executors.newFixedThreadPool(200);

public static ExecutorService newFixedThreadPool(int nThreads) {
    return new ThreadPoolExecutor(nThreads, nThreads,
                                  0L, TimeUnit.MILLISECONDS,
                                  new LinkedBlockingQueue<Runnable>());
}

LinkedBlockingQueue는 내부에 ReentrantLock 라는 락 관련 필드를 가지고 있고 클래스 내부에는 락을 가지는 코드가 존재 합니다.

private final ReentrantLock putLock = new ReentrantLock();

이 코드 내부로 들어가 보면 아래 락을 얻는 진입점으로 들어가게 되고

@ReservedStackAccess
final void lock() {
    if (!initialTryLock())
        acquire(1);
}

AbstractQueuedSynchronizer 추상 클래스의 acquire 메서드를 호출하게 됩니다 이 메서드는 간단히 tryAcquire 메서드를 통해 락을 한번 더 확인 후 없으면 이 추상 클래스의 acquire 메서드를 호출하게 됩니다.

public final void acquire(int arg) {
    if (!tryAcquire(arg))
        acquire(null, arg, false, false, false, 0L);
}

호출된 acquire 메서드는 내부적으로 무한 루프를 돌면서 락을 얻고 락을 얻지 못한 스레드는 LockSupport.park(..) 메서드를 통해 스레드의 상태를 park 상태로 변경 합니다.

final int acquire(Node node, int arg, boolean shared, ...) {
    for (;;) { 
        if (first || pred == null) {
            if (tryAcquire(arg)) { 
                return 1;          
            }
        }
        // ... 중간에 힙 영역에 줄 세우는 코드 (`new ExclusiveNode()`) 실행
        else {
            LockSupport.park(this); 
        }
    }
}

이렇게 park 상태로 들어가게 되면 작업 큐에 쌓여 있는 요청을 소모하지 못하게 되는 상태가 되기 때문에 플랫폼 스레드 풀 모델이 대규모 트래픽에서 문제가 될 수 있습니다.

Instruments 분석

이 지표는 K6 테스트를 하면서 발생한 지표 입니다

System Call Trace 부분을 보면 초반에 스레드 생성으로 인한 시스템 콜의 지표가 높은것을 알수 있습니다, 1:1 매핑은 OS 스레드와 사용자 스레드가 매핑이 되어야 하기 때문에 높은걸 알 수 있습니다, 또한 테스트가 끝날때 까지 지속적인 시스템 콜을 하고 있는데 이 부분은 스레스 생성 뿐 아니라, 스레드 상태 변경 등등 많은 시스템 콜을 하고 있는것을 알 수 있습니다.

Thread State Trace 부분을 보면 OS 커널 스케줄러는 큐의 키 경쟁에서 키를 잡지 못한 무거운 플랫폼 스레드들을 CPU 코어에서 끌어내리고(Block/Park), 깨우는 작업을 무한 반복 합니다. 이 과정에서 발생한 컨텍스트 스위칭 오버헤드는 맥 OS 커널 레벨에 엄청난 연산 부하를 주었다는것을 알 수 있습니다.

java 부분을 보면 CPU 사용량과 컨텍스트 스위칭 수치가 일정하지 않고 중간중간 튀어 나와있는 것을 알 수 있습니다 이는 CPU 코어가 진짜 가상 사용자의 요청을 처리하는 작업을 한 것이 아니라, 스레드의 상태 변경과 TCB를 갈아끼우는 오버헤드(Context Switch)에 CPU 시간을 사용 했고 사용자의 요청을 올바르게 처리하지 못했다는 것을 알 수 있습니다.

K6 지표 분석

생성된 200개의 요청에 대한 각각의 스레드는 1.5초 대기 후 2초동안 작업을 하고 응답을 처리후 다음 작업을 작업 대기 큐에서 가져와 실행하게 됩니다, 그렇게 되면 응답 속도는 매우 느려지게 됩니다

k6의 HTTP 지표를 보게되면 평균 응답 속도는 25.59초 가장 늦게 들어온 사용자의 요청은 47.04초가 걸려 응답을 받은것을 볼 수 있습니다.

테스트 기간 중 순간 10000명의 동시 사용자가 한꺼번에 서버 접속을 시도 했지만 http_reqs (123.71/s) 서버의 초당 처리량은 플랫폼 스레드 200개라는 문제 때문에 초당 123개의 요청밖에 처리하지 못하는 큰 병목이 발생 한것을 알 수 있습니다.

Virtual Thread를 사용해서 테스트를 진행 한 결과

Virtual Thread를 사용 했을 때 힙 공간이 늘어나는 이유는 K6 테스트를 통해 들어온 요청을 가상 스레드 객체로 힙 영역에 생성했기 때문에 증가 하는 모습을 보이고 있습니다. 가상 스레드(Virtual Thread)가 OS 커널에 종속되지 않고 JVM 힙 영역에 직접 적재되는 초경량 자바 객체이기 때문에. 수만 개의 요청이 들어오는 즉시 힙 공간에 가상 스레드 객체 형태로 실시간 할당되었다가, 비즈니스 로직 및 I/O 처리가 완료되는 대로 가비지 컬렉터(GC)에 의해 신속하게 소모, 회수되면서 대규모 부하 속에서도 메모리를 효율적으로 사용할 수 있는 모습입니다.

여기서 Thread 부분을 보게 되면 Platform Thread 와 다르게 커널 스레드와 매핑이 되는 스레드의 개수가 최대 31개인 모습을 볼 수 있습니다. 이유는 위에서 설명한 Virtual Thread의 실행 방식 때문 입니다. 오른쪽 사진을 보게되면 커널 스레드와 JVM의 스레드 매핑은 고작 12개 정도밖에 되지 않습니다 여기서 ForkJoinPool 접미사를 가진 스레드가 Carrier Platform Thread 입니다 위에서 설명 했듯이 1대1 매핑이 되는 스레드는 Carrier Platform Thread가 되고 이 스레드의 스케줄링을 JVM에서 진행 하면서 커널 공간에서는 접근할 수 없던 부분인 스케줄링 부분을 사용자 영역으로 이동시켜 더욱 유연한 사용자 레벨의 컨텍스트 스위칭을 할 수 있습니다.

여기서 왜 처음부터 ForkJoinPool 스레드가 Park 상태인지 의문이 들었는데 플랫폼 스레드는 1.5초의 대기 지연을 OS 커널 스레드가 진행 하기 때문에 초반 Wait 상태가 표시 되었지만, 가상 스레드는 1.5초의 대기 지연을 JVM 힙 영역 내부로 유턴시켜 격리(안 찍힘)하고, 물리 캐리어 스레드는 오직 나노초 단위의 순수 실행(Running) 순간에만 실행 되고 즉시 대기실(Park)로 복귀하기 때문에 지표상 주황색만 보이는것이라고 한다. 또한 Running를 보기 위해서 5억번 정도의 루프를 돌게 했지만 이번에는 Wait 막대만 나오는것을 보고 찾아봤더니 소켓 I/O 컨텍스트 내부에서 연산이 돌 때 JVM의 장부(ThreadMXBean)가 상태를 WAIT로 오독하는 기술적 착시가 있다고 한다.

이 가상 스레드는 ThreadFactory 를 통해 생성이 된다 실제 저장 위치는 VM Heap(힙) 영역이고 실행할 때만 잠깐 캐리어 스레드 메모리를 빌려 쓰고, 멈추거나 쉴 때는 다시 Heap 영역의 일반 객체 저장소로 돌아와 있는 구조이다.

이렇기 때문에 I/O 바운디드 작업에서 가상 스레드의 강점이 나타나게 된다

Instruments 분석

System Call Trace 부분을 보면 테스트 초반부에 그래프가 소폭 상승하는 구간이 존재합니다. 가상 스레드 모델이라 하더라도 실제 연산을 수행할 물리 스레드인 '캐리어 플랫폼 스레드(ForkJoinPool)'가 필요하기 때문에 조금 상승하는 모습을 보이고 있습니다.

지표를 보게되면 얼핏 Platform Thread 보다 안좋은거 아니야 라는 생각을 할 수 있는데 이는 지속적이고 건강한 시스템 콜 입니다 테스트가 끝날 때까지 완만한 능선 모양으로 지속적인 시스템 콜이 발생하는 것은, 플랫폼 스레드처럼 락 때문에 기절하는 비정상적인 호출이 아닙니다. 만 명의 가상 사용자의 요청으로 인한 네트워크 패킷을 처리하기 위해 스레드의 동적 상태 제어 및 실제 소켓 Read/Write 등 필수적인 하드웨어 자원 동기화 시스템 콜을 멈춤 없이 안정적으로 수행하고 있음을 보여주고 있습니다.

Thread State Trace 부분을 보면 플랫폼 스레드 때처럼 100% 위로 튀지 않고, 부하 유입 모양 그대로 유연한 곡선을 그리는 이유가 여기에 있습니다. 큐의 자물쇠 경쟁에서 패배한 수많은 가상 스레드들을 CPU 코어에서 끌어내리고 깨우는 무거운 작업을 OS 커널 스케줄러가 아니라 JVM 사용자 영역에서 전담했기 때문입니다 커널 레벨의 컨텍스트 스위칭 오버헤드가 방어되어 macOS 커널이 부하를 적절하게 받아내고 있음을 보여줍니다.

java 부분을 보면 CPU 사용량과 컨텍스트 스위칭 수치가 크게 튀지 않고, 전체 부하 진입(Ramp-up) 곡선과 완벽하게 정렬되어 일정하게 움직입니다. 이는 CPU 코어가 '무거운 스레드 상태 변경이나 TCB 장부를 갈아끼우는 오버헤드'에 자원을 사용한 것이 아님을 뜻합니다.
가상 스레드의 경량 유저 레벨 컨텍스트 스위칭 덕분에 CPU 시간이 오직 가상 사용자의 비즈니스 요청을 올바르게 처리하고 소모하는 일에 집중되었다고 할 수 있습니다

K6 지표 분석

k6의 HTTP 지표를 보게되면 avg=1.5s min=1.5s max=1.54s 등등 1.5초 근처(최대 1.54초)를 기록하고 있는 모습 입니다
상단에서 Park 상태인 막대만 보였지만 실질적으로 모든 요청이 성공적으로 응답이 왔다는것을 증명 합니다.

checks_succeeded, http_req_failed 부분을 보게되면 가상 사용자가 1분 10초 동안 무려 118,212번의 요청을 보냈지만 100% 성공적으로 처리 한 모습 입니다.

interrupted iterations 부분은 테스트가 강제로 종료되거나 부하 한계치를 넘어서 줄 서다가 타임아웃으로 잘려 나간 요청이 정확히 0건으로 나타나고 있습니다.

결론적으로 가상 스레드는 대기 지연이 큰 I/O 바운드 작업에서 물리 캐리어 스레드를 기절시키지 않고 JVM 사용자 영역 스케줄링으로 자원을 극대화 해 소프트웨어 아키텍처의 전환만으로 많은 처리량 향상과 최적의 자원 효율성 나타내고 있다.

RAG(검색증강생성)를 위한 코사인 유사도(Cosine Similarity) 고속 연산

taetae-o — Fri, 3 Jul 2026 02:39:17 +0900

요구사항

유저의 질문 벡터와 가장 유사한 데이터 Top 5를 추출하는 고속 벡터 연산 알고리즘 구현
반복문 언롤링 및 프리미티브 배열 최적화를 통해 연산 속도 극대화.

구현 사항

OpenAi의 text-embedding-3-small 을 사용해 사용자의 질문 및 기본 지식 세팅시 Vector 배열 추출
기본 지식을 넣을 API 구축
- 카테고리 설정으로 모든 정보를 다 뒤지는게 아닌 특정 카테고리 데이터만 서치
- 외부 API를 사용해서 얻은 지식 벡터 데이터는 postgresql 에 저장
사용자의 질문 API 구축
사용자의 질문에 대해 유사도 Top5 추출 기능
- pgvector 기반 DB내 Top5 추출
- 반복문 언롤링 및 프리미티브 배열 최적화를 통한 고속 벡터 연산 알고리즘 사용해 Top5 추출

InMemoryVectorRow

text-embedding-3-small 를 사용하게 되면 1536 차원의 벡터 데이터를 받게 되는데 이것을 float[] 형태로 저장하고 적절한 분야에서 데이터를 찾기 위해 카테고리 필드를 추가.

InMemoryCacheRegistry

@PostConstruct 를 사용해 미리 세팅 해 둔 지식 데이터를 메모리에 올리기 위한 준비 클래스

RagSearchService

사용자의 질문 Payload를 접수하여, 카테고리로 적절한 분야 기반으로 4칸 루프 언롤링으로 코사인 유사도를 측정
DB, Memory 구분

RagSearchController

프론트엔드나 포스트맨의 고밀도 JSON 요청을 바디로 깔끔하게 접수하여 결과 보고서를 출고하는 엔드포인트.

반복문 언롤링

우리가 흔히 짜는 for (int i = 0; i < 1536; i++) 이 반복문은 CPU가 내부적으로 명령을 수행 할 때 큰 비효율이 존재한다.

이 루프는 다음과 같은 명령을 수행한다.

i < 1536 조건이 참인지 검사
루프 내부 연산 수행
i++ 실행 및 다시 루프 시작점으로 이동

컴퓨터 구조 관점에서 CPU는 파이프라인을 통해 여러 명령어를 겹쳐 처리하려고 합니다. 하지만 조건문이나 반복문의 분기 지점에서는 다음에 실행할 명령어의 흐름이 아직 확정되지 않았기 때문에 CPU는 분기 예측을 사용합니다. 만약 예측이 맞으면 파이프라인은 계속 효율적으로 동작하지만, 예측이 틀리면 이미 파이프라인에 들어온 잘못된 명령어들을 버리고 올바른 명령어 흐름으로 다시 채워야 합니다. 이 과정에서 파이프라인 스톨이나 플러시가 발생할 수 있고, 잠깐이지만 ALU와 같은 실행 장치가 제대로 활용되지 못하는 오버헤드가 생깁니다.

이런 문제를 해결하기 효율적으로 해결하기 위해 반복문 언롤링 이라는 것을 사용할 수 있습니다.

for (; i <= len - 4; i += 4) {
    dotProduct += vecA[i] * vecB[i]; normA += vecA[i] * vecA[i]; normB += vecB[i] * vecB[i];
    dotProduct += vecA[i+1] * vecB[i+1]; normA += vecA[i+1] * vecA[i+1]; normB += vecB[i+1] * vecB[i+1];
    dotProduct += vecA[i+2] * vecB[i+2]; normA += vecA[i+2] * vecA[i+2]; normB += vecB[i+2] * vecB[i+2];
    dotProduct += vecA[i+3] * vecB[i+3]; normA += vecA[i+3] * vecA[i+3]; normB += vecB[i+3] * vecB[i+3];
}

위 코드는 4-Way 반복문 언롤링으로 한 번의 반복에서 4개의 연산을 처리하도록 만듭니다. 예를 들어 1,536번 반복하던 루프를 384번의 반복으로 줄이는 방식으로. 이 방식의 장점은 반복 횟수가 줄어들면서 루프 증가 연산, 조건 비교, 분기 명령 같은 제어 명령의 실행 횟수도 함께 줄어든다는 점입니다. 따라서 CPU 입장에서는 루프 분기 명령을 처리하는 횟수가 줄어들고, 잘못된 분기 예측이 발생할 수 있는 기회도 줄어듭니다. 또한 한 번의 반복 안에 여러 연산이 배치되기 때문에 CPU가 명령어를 더 연속적으로 처리하기 쉬워져 파이프라인 효율과 명령어 수준 병렬성이 좋아질 수 있습니다.

프리미티브 배열 최적화

프리미티브 배열 최적화 부분은 위에서 반복문 언롤링과 이어지게 될 수 있습니다 Java에는

Primitive type(원시타입)
Reference type(참조타입)

두가지 타입이 있습니다 간단히 말해 참조타입은 new 으로 생성되기 때문에 메모리 공간에 렌덤적으로 생성되게 됩니다 이런 상황으로 반복문 최적화를 하게 되면 루프를 도는 횟수는 줄어들 수 있지만 내부적으로 엄청난 비효율이 발생하게 됩니다.

0번 방 값을 연산하고 나면, 1번 방 값을 읽기 위해 다시 주소값을 타고 메모리의 완전히 다른 구역으로 이동 했다 오는 포인터 추적
오버헤드 가 발생합니다 데이터의 위치가 불 연속적이기 때문에 CPU 캐시를 효율적으로 사용하지 못하고 메모리 까지 내려갔다오는
비 효율이 발생하게 됩니다.

이때 프리미티브 타입의 배열을 사용하게 되면 CPU가 메모리에서 데이터를 읽어올 때는 딱 숫자 1개만 가져오지 않고, 효율을 위해 그 주변 데이터까지 세트로 묶어서 캐시 라인(Cache Line, 보통 64바이트 단위) 단위로 가져오게 됩니다. 그렇기 때문에 컴퓨터는 프리미티브 배열 vecA[0]의 숫자를 읽는 순간, CPU 내부의 하드웨어 장치는 내부적으로 vecA[1] vecA[2] ... 데이터도 순차적으로 읽는다는것을 감지 해 CPU 캐시에 올려두게 됩니다.

이렇게 되면 메모리까지 내려갔다 오는 횟수도 최적화가 되고 메인 메모리를 다녀오느라 발생하는 지연 시간(Latency)를 최적화 할 수 있습니다, 또한 참조 타입과 원시타입의 메모리 차지하는 크기도 원시타입이 더 적기 때문에 메모리 공강 효율의 이점을 얻을 수 있습니다.

Spring AI 의 Text embedding 모델을 사용해 보았는데 여기서도

float[] embedding = embeddingModel.embed(text);

프리미티브 타입의 배열을 반환 하는것을 알 수 있습니다.

Thread-Per-Connection 소켓 폭발 및 락 병목 스레드 덤프 분석

taetae-o — Fri, 26 Jun 2026 02:35:24 +0900

요구 사항

멀티스레드 소켓 채팅 서버에 k6로 대량 동시 연결을 인입시켜 Thread-Per-Connection 구조의 한계를 확인한다.
최초 목표는 3,000개 동시 연결이었고, 한계 지점을 확인하기 위해 최대 10,000개 연결까지 부하를 증가시켰다.
그 과정에서 스레드 생성 폭발로 인한 OOM 또는 native thread 생성 실패 상황을 재현한다.
AI 응답 대기 시간 동안 `synchronized` 락에 묶여 병목이 발생한 스레드 상태를 `jstack` 덤프로 추출해 원인을 격리한다.

문제 사항

메모리 고갈 (OOM):
- 고동시성 트래픽 유입 시 Thread-Per-Connection 구조에서는 연결 수에 비례해 플랫폼 스레드가 증가한다.
- 플랫폼 스레드는 Java Heap 안에만 존재하는 것이 아니라 OS native thread와 매핑되며, 각 스레드는 별도의 stack memory를 필요로 한다.
- 따라서 연결 수가 급격히 증가하면 Heap 사용량뿐 아니라 native memory와 OS thread 생성한계에도 도달할 수 있다.
동기화 락 병목 (Monitor Locked):
- 긴 대기 시간 동안 임계구역을 보호하는 자바의 synchronized 키워드가 '스핀락' 임계치를 초과하여 '뮤텍스(Mutex) 기반 블로킹 중량 락'으로 강제 승격.
- 이로 인해 수천 개의 스레드가 OS 대기실로 들어가 BLOCKED 상태 변경

실험에서는 JVM Heap을 30MB로 제한한 상태에서 대량 연결을 인입했고, 약 8,200개 수준의 스레드가 생성된 뒤
더 이상 안정적으로 스레드를 생성하지 못하는 상황을 관찰했다.

Thread-Per-Connection

연결당 스레드 하나라는 뜻으로 클라이언트거 서버에 접속해서 소켓 커넥션을 맺으면 서버가 그 유저만을 위한 전담 스레드를 하나 새로 만들어거나 스레드 풀에서 꺼내서 사용자의 요청과 서버의 응답까지 1대1로 붙여주는 네트워크 구동 방식 입니다.

이런 방식의 위험성은 자바에서 스레드를 생성할 때 스레드가 하나 생성될 때 마다 OS로 부터 스레드 로컬 스택 메모리를 할당받게 되는데 만약 기본 메모리를 1MB로 가정하고 사용자가 3000명 들어왔을 때 단순 계산으로 3GB를 소모하게 됩니다. 즉 메모리의 자원은 한정적이고 사용자가 더 늘어나게 된다면 OOM이 발생하게 되고 서버는 죽게됩니다.

또한 컨텍스트 스위칭의 문제가 발생 합니다. 컨텍스트 스위칭의 비용은 무시할 수 없고, CPU코어는 한정 되어있기 때문에 운영체제 관점에서 생성된 사용자 3000명을 관리하기 위한 PCB 하위 스레드의 정보가 저장되어있는 TCB를 생성하고 이걸로 스케줄링을 하게 됩니다.

컴퓨터는 모든것이 동시에 실행 되는것 처럼 보이지만 내부에서는 CPU가 스케줄링을 통해 번갈아 수행을 하는것이다 이게 너무 빠르기 때문에 우리 눈에는 동시에 실행 되는것 처럼 보이게 됩니다.

이렇게 번갈아 가면서 수행을 하려면 이 스레드는 어디까지 수행을 했는지 저장과, 다시 실행하기 위해 데이터를 가져와야 하고, 가져온것을 실행 해야 하는 것 까지의 작업을 하게 되는데 CPU가 이 작업을 하게 됩니다.

여기서 문제가 발생 하게 되는데 한정되어있는 CPU 자원은 많이 생성된 스레드를 전부 기아 스레드 없이 동작 시키기 위해 우선순위 등등을 따져 스케줄링을 하게 되는데 코어는 한정되어있기 때문에 실행되는 스레드의 시간이 극단적으로 줄어들 수 밖에 없습니다, 이렇게 스레드의 정보를 올리는 동작이 스레드의 실행 시간보다 길어지게 되면 핵심은 코드를 실행 시키는것이 목적이였지만 이것이 스레드의 정보를 저장, 복원하는것에 시간을 더 사용하게 됩니다.

이런 문제는 CPU의 캐시 메모리인 L1, L2, L3의 캐시 미스 문제도 발생 시키게 됩니다. 스레드는 메모리 공간에 저장되어있고 이것을 더욱 빠르게 정보를 가져오고, 저장하기 위해 캐시를 사용하게 됩니다. 하지만 스레드가 많게 되면 케시 메모리가 계속 비워지고 다시 케시에 올리기 위해 메인 메모리까지 내려갔다 오는 작업의 간격이 짧아지게 됩니다.

정리 하면 스레드 수가 과도하게 증가하면 CPU는 더 많은 스레드를 스케줄링해야 하고, 컨텍스트 스위칭과 캐시 효율 저하가 발생할 수 있다. 다만 본 실험처럼 대부분의 스레드가 monitor entry에서 `BLOCKED` 상태로 대기하는 경우, 핵심 병목은 CPU 연산 자체보다 스레드 자원 점유, 락 대기, native thread 생성 한계에 더 가깝다고 할 수 있다.

문제 분석

테스트 환경

Java: 21.0.9
- 서버 구조: Thread-Per-Connection 소켓 서버
JVM 옵션
- -Xms30m
- -Xmx30m
- -Xss1m 또는 기본값
부하 도구: k6
- 목표 연결 수
  - 1차: 3,000 connection
  - 2차: 10,000 connections
관찰 도구:
- VisualVM
- jstack
관찰 항목:
- Heap 사용량
- Live Thread 수
- OOM 발생 시점
- BLOCKED (on object monitor) 스레드 수

테스트를 위한 서버를 구동 후 k6 test.js 실행

Heap텝의 그래프의 초기 상태를 보게되면 사용량이 급격하게 증가되는 모습과 Threads 텝의 생성된 스레드의 그래프가 급격하게 증가하는 모습.

10000개의 소켓을 연결 하다가 OOM 발생 총 8200개 정도의 스레드만 생성

생성된 스레드가 임계 구역을 들어가기 위해 대기 상태인 모습과, 실행되고 있는 스레드 확인 Total 섹션에는 이 스레드가 실행되고 나서의 라이프 타임, 임계구역에 들어가지 못해 대기하고있는 스레드는 계속해서 라이프타임이 길어지고, 메모리를 계속 잡고있는다.

여기서 임계구역은 java의 synchronized 사용한다 락 종류에는 스핀락, 뮤텍스(Mutex)와 세마포어(Semaphore) 기반의 블로킹이 있다 synchronized는 뮤텍스 기법과, 스핀락 기법을 같이 사용하는것을 채택하고 있다

경쟁이 아주 잠깐 발생한다고 하면 스레드의 정보가 OS 대기실로 가고 깨어나는 오버헤드가 더 크기 때문에 임계구역 앞에서 아주 잠깐 스핀을 돌며 빠르게 키를 잡기 위함이고, 뮤텍스 기법 채택 이유는 스핀락은 키를 잡기까지 계속 루프를 돌기 때문에 불필요한 CPU 사용이 있다 이때 경쟁이 치열할 경우 스레드 내부 코드를 처리해야 하는 CPU가 스핀락의 루프까지 돌아야 하기 때문에 자바가 자원을 보호하려고 스레드를 OS 커널 뮤텍스 대기실로 보내 완전히 잠재워 버립니다.

아래 코드는 JAVA 의 synchronized 을 구현하고 있는 C++ 코드이다.

bool ObjectSynchronizer::fast_lock_spin_enter(oop obj, LockStack& lock_stack, JavaThread* current, bool observed_deflation) {
  assert(UseObjectMonitorTable, "must be");
  // Will spin with exponential backoff with an accumulative O(2^spin_limit) spins.
  const int log_spin_limit = os::is_MP() ? FastLockingSpins : 1;
  const int log_min_safepoint_check_interval = 10;

  markWord mark = obj->mark();
  const auto should_spin = [&]() {
    if (!mark.has_monitor()) {
      // Spin while not inflated.
      return true;
    } else if (observed_deflation) {
      // Spin while monitor is being deflated.
      ObjectMonitor* monitor = ObjectSynchronizer::read_monitor(obj, mark);
      return monitor == nullptr || monitor->is_being_async_deflated();
    }
    // Else stop spinning.
    return false;
  };
  // Always attempt to lock once even when safepoint synchronizing.
  bool should_process = false;
  for (int i = 0; should_spin() && !should_process && i < log_spin_limit; i++) {
    // Spin with exponential backoff.
    const int total_spin_count = 1 << i;
    const int inner_spin_count = MIN2(1 << log_min_safepoint_check_interval, total_spin_count);
    const int outer_spin_count = total_spin_count / inner_spin_count;
    for (int outer = 0; outer < outer_spin_count; outer++) {
      should_process = SafepointMechanism::should_process(current);
      if (should_process) {
        // Stop spinning for safepoint.
        break;
      }
      for (int inner = 1; inner < inner_spin_count; inner++) {
        SpinPause();
      }
    }

    if (fast_lock_try_enter(obj, lock_stack, current)) return true;
  }
  return false;
}

다음으로 jstack 덤프로 추출 한 결과이다 위 VisalVM으로 분석한것과 같이 ava.lang.Thread.State: BLOCKED 처리 되어있는걸 알 수 있다.

// 사용 명령어 
jstack <실행중인 서버 pid> > <저장 파일 명>.txt

...
"Thread-Per-Connection-Chat-3052" #3052 [1741059] prio=5 os_prio=31 cpu=0.10ms elapsed=1124.67s tid=0x00000008bfc74000 nid=1741059 waiting for monitor entry  [0x00000004767ae000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at com.example.aisocket.week2.benchmark.ChatLockManager.processAiQuery(ChatLockManager.java:6)
    - waiting to lock <0x00000005a8b415c8> (a java.lang.Class for com.example.aisocket.week2.benchmark.ChatLockManager)
    at com.example.aisocket.week2.benchmark.ClientHandler.run(ClientHandler.java:19)
    at java.lang.Thread.runWith(java.base@21.0.9/Thread.java:1596)
    at java.lang.Thread.run(java.base@21.0.9/Thread.java:1583)

"Thread-Per-Connection-Chat-3053" #3053 [1740547] prio=5 os_prio=31 cpu=0.12ms elapsed=1124.67s tid=0x00000008bfc74700 nid=1740547 waiting for monitor entry  [0x00000004769ba000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at com.example.aisocket.week2.benchmark.ChatLockManager.processAiQuery(ChatLockManager.java:6)
    - waiting to lock <0x00000005a8b415c8> (a java.lang.Class for com.example.aisocket.week2.benchmark.ChatLockManager)
    at com.example.aisocket.week2.benchmark.ClientHandler.run(ClientHandler.java:19)
    at java.lang.Thread.runWith(java.base@21.0.9/Thread.java:1596)
    at java.lang.Thread.run(java.base@21.0.9/Thread.java:1583)

"Thread-Per-Connection-Chat-3054" #3054 [1577219] prio=5 os_prio=31 cpu=0.11ms elapsed=1124.67s tid=0x00000008bfc74e00 nid=1577219 waiting for monitor entry  [0x0000000476bc6000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at com.example.aisocket.week2.benchmark.ChatLockManager.processAiQuery(ChatLockManager.java:6)
    - waiting to lock <0x00000005a8b415c8> (a java.lang.Class for com.example.aisocket.week2.benchmark.ChatLockManager)
    at com.example.aisocket.week2.benchmark.ClientHandler.run(ClientHandler.java:19)
    at java.lang.Thread.runWith(java.base@21.0.9/Thread.java:1596)
    at java.lang.Thread.run(java.base@21.0.9/Thread.java:1583)
...

이번 실험을 통해 Spring Boot/Tomcat을 사용할 때는 개발자가 직접 소켓 연결마다 스레드를 생성하지 않아도 되지만, 내부적으로도 요청 처리 스레드 풀, connection 수, blocking I/O, 락 대기 시간이 시스템 안정성에 큰 영향을준다는 점을 확인했다.

즉, 프레임워크가 기본적인 네트워크 처리와 스레드 풀 관리를 제공하더라도, 애플리케이션 코드 내부에서 긴 I/O 작업을 synchronized`임계구역 안에 넣으면 동일한 병목이 발생할 수 있다.

고동시성 환경에서의 AI 요청 비동기 스케줄링 큐

taetae-o — Wed, 24 Jun 2026 18:13:26 +0900

요구사항

유저의 AI 질의 요청을 순서와 가중치에 따라 데드락 없이 안전하게 큐잉
소모시키는 지수 백오프(Exponential Backoff) 기반 스케줄러 알고리즘 작성

문제사항

멀티스레드 환경(유저 수천 명)에서 AI 질의 요청이 쏟아진다
외부 AI API(예: OpenAI, Claude)는 분당 요청 제한(Rate Limit)이 걸려 있다

클라이언트와 서버의 3-way-hanshake을 통해 세션을 맺으면 생성되는 소켓을 Poller events 큐에 넣게 되면 요청에 대한 적절한 처리를 하게 되고 워커 스레드인 http-nio-8080-exec-X 스레드를 통해 Spring Boot의 DispatcherServlet에 접근을 하게 된다.

이때 적절한 컨트롤러를 찾아서 처리를 할텐데 http-nio-8080-exec-X 이 스레드가 AI 요청와 응답을 기다리는 작업을 하게되면 이 스레드는 대기 상태(Waiting)이 된다, 이렇게 되면 스레드는 한정 되어있기 때문에 이런 사용자의 요청이 많이 들어오게 되면 요청을 처리할 수 없게 된다.

그렇기 때문에 http-nio-8080-exec-X 이 스레드를 빨리 놔 주어야 한다, 이때 실행 작업을 이벤드 큐에 넣는 방식으로 사용하게 된다면 즉 비동기 식으로

Acceptor의 스레드(http-nio-8080-Acceptor)가 소켓을 감지한후 처리를 하고 Poller의 events 큐에 작업을 던지는 식으로 하게 되면 Poller의 스레드(http-nio-8080-Poller)가 이후 처리를 하듯이 사용자가 AI 질문 요청을 할때도 마찬가지로 이런 방식을 사용하게 되면 작업은 이벤트 큐에 쌓이게 되고 병렬로 처리가 가능하게 될것이다 (생성된 AI 응답 스레드 수 만큼 병렬 처리 가능)

여기서 드는 의문은 http-nio-8080-exec-X 이 스레드에서 사용자의 요청을 이벤트 큐에 넣고 마무리 된다면 사용자는 응답을 받을 수 없을것이다.

이것의 해결 방법은 컨트롤러 내부에서 유저에게 바로 응답을 주는 대신, "나중에 AI 답변이 오면 여기 가방에 담아서 응답해 줘" 하고 약속하는 가상 객체(DeferredResult 또는 CompletableFuture)를 하나 생성한 후 이것을 이벤트 큐에 담는 방식이다.

이렇게 되면 http-nio-8080-exec-X 이 스레드는 유저에게 답변을 주지 않은 상태로, 톰캣 엔진에게 "나 이 요청 비동기(Async)로 전환했으니까 소켓 커넥션만 끊지 말고 끊어지지 않게 킵 해줘!"라고 말한 뒤, 톰캣 스레드 풀로 즉시 복귀하게 된다.

이후 톰캣 풀과 완전히 격리된 우리만의 AI-Scheduler-Consumer 스레드가 '질문 요청 큐'에서 일감을 하나씩 꺼내 AI의 응답을 받아오게 되면 deferredResult.setResult(답변) 이 순간, 스프링이 가방에 데이터가 들어온 것을 감지하고 톰캣에게 컨텍스트를 다시 이관(Dispatch)하면, 톰캣 풀에서 마침 놀고 있던 스레드를 깨워 깨어난 워커 스레드가 아까 킵해두었던 유저의 소켓을 쥐고, 가방에 담긴 AI 답변을 실어서 브라우저로 최종 HTTP 응답을 주고 완전히 상황을 마감한다.

[1단계: 인프라 아키텍처 관점]

(톰캣 커널 엔진) 어떻게 하드웨어 레벨의 날것의 패킷 트래픽을 서버 마비 없이 대량으로 접수하고 격리할 것인가?

[2단계: 실전 서비스 설계 관점] (AI 스케줄링 파이프라인) 그렇게 인입된 요청 중에서, 특정 비즈니스 제약(AI Rate Limit)과 서비스 규칙(유저 가중치)을 녹여서 실제 가치(Value)로 어떻게 풀어낼 것인가?

에 대한 문제라고 생각한다.

데드락이란

멀티 스레드 환경에서 서로 상대방이 필요한 자원을 쥐고 다른 자원을 요구하는 것 (교착상태)

발생 원인 : 이 4가지 조건이 모두 성립 하면 발생

상호 배제 (Mutual Exclusion): 자원은 한 번에 한 스레만 가질 수 있다. (포크는 한 명만 쥘 수 있음)
점유와 대기 (Hold and Wait): 자원을 하나 쥔 상태에서 다른 자원을 기다린다. (포크A를 쥔 채로 포크B를 요구함)
비선점 (No Preemption): 다른 스레드가 쥔 자원을 강제로 뺏어올 수 없다. (상대방 손에 있는 포크를 강탈 못 함)
순환 대기 (Circular Wait): 대기하는 주체들이 원형으로 꼬여있다. (스레드 1 ➡️ 스레드 2 ➡️ 스레드 1)

문제 해결 방법

상위 발생 원인을 하나만 원천 차단 하면 해결된다.

여기서 데드락이 발생할 수 있는 상황은 사용자의 요청과 서버의 응답을 내려주는 스레드는 http-nio-8080-exec-X 스레드인데 사용자의 AI 요청을 이벤트 큐에 넣고 AI-Scheduler-Consumer 스레드가 처리하는 AI의 답변까지 기다리는 상황이 생기면 http-nio-8080-exec-X 이 스레드는 대기 상태에 걸리게 되고 AI 답변을 받아와서 톰캣에게 답변 받았으니 사용자한테 응답을 해 주어야 하는 상황에서 그걸 처리 할 http-nio-8080-exec-X 스레드가 없어 스레드풀 데드락이 걸리는 상황이다.

구현 구조

미션 1 : 구현 구조

1차 구현

1. AIRequestTask.java (일감 데이터 가방)

책임: 큐에 들어갈 일품 세트입니다.
핵심 필드:
- 유저의 질문 내용 (prompt)
- 유저의 가중치 등급 (UserGrade)
- 요청 시간 (requestedTime - 가중치가 같을 때 선착순 정렬용)
- CompletableFuture<String> responseFuture
특이사항: PriorityBlockingQueue가 스스로 순서를 정렬할 수 있도록 자바의 Comparable<AIRequestTask> 인터페이스를
구현.

2. AIController.java (톰캣 스레드 해방 창구)

책임: 유저의 HTTP 요청을 가장 먼저 받아서 큐에 넣는 엔드 포인트.
핵심 로직:
- 요청이 들어오면 빈 가방(CompletableFuture)을 포함한 AIRequestTask를 생성합니다.
- 스케줄러의 이벤트 큐에 이 태스크를 툭 집어넣습니다.
- exec-X 스레드는 가방(CompletableFuture)만 톰캣 엔진에 리턴하면서 즉시 반환.

3. AIScheduler.java (이벤트 큐 보유 및 지수 백오프 컨슈머 엔진)

책임: 이벤트 큐를 필드로 가지는 클래스이자, 백그라운드 스레드들을 관리.
핵심 필드: PriorityBlockingQueue<AIRequestTask> eventQueue
핵심 로직:
- 클래스가 초기화될 때 AI-Scheduler-Consumer 백그라운드 스레드 3개를 생성하고 구동(while(true))
- 이 컨슈머 스레드들이 큐에서 가중치 순으로 일감을 하나씩 꺼내 외부 API를 호출합니다.
- 에러(Rate Limit) 발생 시 지수 백오프 알고리즘을 돌리며 현재 스레드만 잠시 슬립(Thread.sleep)시킵니다.
- 성공 시 task.getResponseFuture().complete(답변)을 호출하여 스프링 관제탑을 통해 톰캣 유휴 스레드(exec-Y)를 깨워 응답을 마무리.

디버깅

외부 AI 호출 기능은 임시로 구현 했기 때문에 Thread.sleep(10000); 를 사용해 외부 AI 요청 시간을 10초 준다.

1. Postman을 통해 AI 질문 API 호출

2. Tomcat의 http-nio-8080-exec-9 스레드가 4번의 코드로 작업을 큐에 삽입 후 5번 코드를 실행 이때
AI-Scheduler-Consume 스레드가 큐에있는 작업을 잡아 실행 (두 스레드 모두 RUNNING)

3. 5번 코드를 실행 후 http-nio-8080-exec-9가 반환 돼 WAIT 상태로 들어간것을 확인

4. AI의 응답이 10초 있다 전송, 사용자한테 응답을 해 주기위한 http-nio-8080-exec-9 스레드 실행

5. 실행된 톰켓 워커 스레드를 통해 세션이 끊기지 않고 응답 전송

이렇게 비동기 시, 스레드의 활성 상태를 보고 톰캣 커널 엔진과 서블릿 컨테이너가 하부 하드웨어 레벨에서 어떻게 돌아가는지 확인 할 수 있었다.

3-Way Handshake 부터 Tomcat을 지나 스프링 부트 시작점 까지

taetae-o — Tue, 23 Jun 2026 02:27:55 +0900

클라이언트에서 서버와 세션을 맺기 위해서 3-Way Handshake 진행 후 세션을 맺는다 이때 Socket 생성을 한다.

톰켓은 생성된 소켓을 감지하는 Acceptor 클래스가 있다 Runnable 인터페이스를 상속받고 있어 스레드 생성이 가능하다.

Acceptor 스레드가 생성된 Socket의 주소를 serverSocketAccept() 매서드를 통해 내부 객체로 변환한다.

이때 2개의 구현체가 있는데 각각 반환 하는 값이 다르고 동작이 추가된다.

NioEndpoint는 SocketChannel 반환후 setSocketOptions(..) 실행, 이 메서드 내부에서 NioSocketWrapper로 감싸지게 된 후 poller.register(...) 메서드를 통해 PollerEvent 객체가 Poller 스레드가 관리하는 SynchronizedQueue에 들어가게 된다 즉 Selector(멀티플렉서)라는 주문 벨 시스템에 등록 하는것 이다.

Nio2Endpoint는 AsynchronousSocketChannel 반환 자바 힙 영역에 ByteBuffer를 하나 만든 뒤, Nio2SocketWrapper로 감싸서

processSocket(..) 메서드를 호출 해 소켓 주소, 빈 바구니, 작업 완료 후 실행할 콜백 함수(CompletionHandler)를 OS 커널에게 통째로 넘긴다.

이렇게 까지 Acceptor 스레드를 통해 세션 연결된 소켓을 내부적으로 등록하고 비동기 처리를 진행하기 전 까지의 작업이 완료된다.

여기서 차이점은 연결된 세션에서 패킷을 받을때 차이점이 있다. 먼저 내부적으로 톰켓은 연결된 세션 (소켓)을 어떤식으로 처리 하는지 자세히 알아보자

Acceptor 가 NioEndpoint를 사용하는 경우 (실제 Spring Boot 프로젝트로 Acceptor 클래스를 찾아 따라가 보면 좋다)

프로그렘 준비 시점에 생성된 http-nio-8080-Acceptor 스레드가 endpoint.serverSocketAccept(...); 를 호출해 커널에 대기 중이던 소켓을 자바 영역으로 가져온다. 메서드를 타고 들어가면 serverSock.accept(...); 를 호출 해 SocketChannel 객체를 반환을 한다 이 객체는 추상 클래스로 내부에는 SocketChannelImpl 객체가 들어간다.

그 후 if(!endpoint.setSocketOptions(socket)); 호출로 NioSocketWrapper 로 감싸 poller.register(socketWrapper);

를 호출 해 마킹과, PollerEvent 객체를 생성 addEvent() 메서드를 통해 events (Poller 객체의 필드이다) SynchronizedQueue 에 들어가게 된다.

Poller도 http-nio-8080-Poller 이름을 가진 스레드를 프로그렘 준비 시점에 생성한다. 즉 Acceptor가 Poller의 events 필드에 값을 넣어 두면 Poller의 스레드가 알아서 이걸 작업 하는 형태로 간단히 생각 하면 된다.

조금 자세히 말하자면 Poller 스레드는 계속 깨어 있는것이 아니기 때문에 Acceptor가 이벤트를 추가 할때

private void addEvent(PollerEvent event) {
            events.offer(event);
            if (wakeupCounter.incrementAndGet() == 0) {
                selector.wakeup();
            }
        }

if문을 보면 어떤 숫자를 검사를 하게 된다 wakeupCounter 필드는 AtomicLong 타입으로 공유 메모리에 위치해 있는 변수이기 때문에 사용한다 원자적인 값 증가, 감소가 가능하다.

selector.wakeup(); 이라는 매서드를 호출 하는데 이것은 내부적으로 시스템 콜을 하기 때문에 커널 영역까지 들어가는 작업을 하게 된다. 이런 무거운 작업을 하지 않도록 이미 스레드가 활성화 되어 있는 경우 (0이 아닌 경우) 는 깨우지 말고 이벤트 큐에만 삽입 하도록 하는 코드이다.

이렇게 Poller의 이벤트 큐에 들어가게 되면 http-nio-8080-Poller 스레드가 작업을 시작 한다. run() 메서드를 보면 초반에 이벤트 큐를 관리하는 events() 메서드를 호출 하는걸 알 수 있는데

public boolean events() {
    boolean result = false;

    PollerEvent pe;
    for (int i = 0, size = events.size(); i < size && (pe = events.poll()) != null; i++) {
        result = true;
        NioSocketWrapper socketWrapper = pe.getSocketWrapper();
        SocketChannel sc = socketWrapper.getSocket().getIOChannel();
        int interestOps = pe.getInterestOps();
        if (sc == null) {
            if (log.isDebugEnabled()) {
                log.debug(sm.getString("endpoint.nio.nullSocketChannel"));
            }
            socketWrapper.close();
        } else if (interestOps == OP_REGISTER) {
            try {
                sc.register(getSelector(), SelectionKey.OP_READ, socketWrapper);
            } catch (Exception e) {
                log.error(sm.getString("endpoint.nio.registerFail"), e);
            }
        } else {
            final SelectionKey key = sc.keyFor(getSelector());
            if (key == null) {
                // The key was cancelled (e.g. due to socket closure)
                // and removed from the selector while it was being
                // processed. Count down the connections at this point
                // since it won't have been counted down when the socket
                // closed.
                socketWrapper.close();
            } else {
                final NioSocketWrapper attachment = (NioSocketWrapper) key.attachment();
                if (attachment != null) {
                    // We are registering the key to start with, reset the fairness counter.
                    try {
                        int ops = key.interestOps() | interestOps;
                        attachment.interestOps(ops);
                        key.interestOps(ops);
                    } catch (CancelledKeyException ckx) {
                        socketWrapper.close();
                    }
                } else {
                    socketWrapper.close();
                }
            }
        }
        if (running && eventCache != null) {
            pe.reset();
            eventCache.push(pe);
        }
    }

    return result;
}

이 메서드를 통해 events 필드를 순회 하면서 담긴 PollerEvent의 필드인 interestOps 상태가 OP_REGISTER 인 경우 sc.register(getSelector(), SelectionKey.OP_READ, socketWrapper); 메서드를 통해 SelectionKey 객체를

Poller의 Selector 에 담는다.

다시 Poller의 run() 메서드로 돌아와서 하단 코드를 보면 이런 코드가 있다.

Iterator<SelectionKey> iterator = keyCount > 0 ? selector.selectedKeys().iterator() : null;
                // Walk through the collection of ready keys and dispatch
                // any active event.
                while (iterator != null && iterator.hasNext()) {
                    SelectionKey sk = iterator.next();
                    iterator.remove();
                    NioSocketWrapper socketWrapper = (NioSocketWrapper) sk.attachment();
                    // Attachment may be null if another thread has called
                    // cancelledKey()
                    if (socketWrapper != null) {
                        processKey(sk, socketWrapper);
                    }
                }
...

코드에서 selector의 키를 가져오고 있다 여기서 Poller 클래스의 필드인 selector 이건 뭐냐면 Selector 추상클래스로 자바 Non-Blocking I/O의 핵심이다, 소캣을 감시 해야 하는데 OS마다 엔진이 다르기 때문에 추상화 한것이고 OS에 맞춰 적절한 구현체가 끼워지게 된다. 간단히 Selector 하나로 생성된 모든 소켓을 관리 할수 있다.

요약 하면 Acceptor가 Poller의 events 큐에 값을 넣어 두면 Poller의 http-nio-8080-Poller 스레드가 이미 일어나 있거나, 깨워지게 되고, events() 메서드를 실행 해 sc.register() 호출 함으로 Poller의 소켓 감시자인 Selector 필드 내부에 SelectionKey 를 추가 하게 된다.

그 후 다운 케스팅을 통해 구현체 객체로 변경 한 후 processKey(...) 메서드를 호출 한다. 이때 내부에서 SelectionKey, NioSocketWrapper 객체를 통해 이 소켓이 지금 데이터를 읽을 수 있는 상태(isReadable())인지, 아니면 데이터를 네트워크 랜카드로 내보낼 수 있는 상태(isWritable())인지 판정을 내려 적절한 분기를 타고

processSocket(socketWrapper, SocketEvent.OPEN_READ, true) 메서드를 실행 시킨다.

public boolean processSocket(SocketWrapperBase<S> socketWrapper, SocketEvent event, boolean dispatch) {
    try {
        if (socketWrapper == null) {
            return false;
        }
        SocketProcessorBase<S> sc = null;
        if (processorCache != null) {
            sc = processorCache.pop();
        }
        if (sc == null) {
            sc = createSocketProcessor(socketWrapper, event);
        } else {
            sc.reset(socketWrapper, event);
        }
        Executor executor = getExecutor();
        if (dispatch && executor != null) {
            executor.execute(sc);
        } else {
            sc.run();
        }
...

여기서 분기를 보면 Tomcat이 메모리 관리를 세세히 하고 있다는것을 알 수 있다. SocketProcessorBase<S> sc = null; 여기에 들어가는 객체를 계속 createSocketProcessor(socketWrapper, event) 이걸로 생성하는게 아닌 이미 생성 되어있는게 있으면 sc에 할당을 하고 reset(...) 메서드를 통해 이미 생성되어있는 객체에서 값만 바꾸는 동작을 한다.

sc에는 SocketProcessor 객체가 들어간다. SocketProcessor 는 SocketProcessorBase<NioChannel> 를 상속 받고 이게 Runnable를 구현하고 있어 SocketProcessorBase<S> sc 이 변수에 들어갈수 있었고 .execute(Runnable r) 이 메서드에 인자로 넣어줄 수 있다.

이후 하단에서 executor.execute(sc); 메서드를 통해

java.util.concurrent.ThreadPoolExecutor

구현체를 호출 한다. 구현체의 execute() 메서드를 확인해 보자

public void execute(Runnable command) {
    if (command == null)
        throw new NullPointerException();
    int c = ctl.get();
    if (workerCountOf(c) < corePoolSize) {
        if (addWorker(command, true))
            return;
        c = ctl.get();
    }
    if (isRunning(c) && workQueue.offer(command)) {
        int recheck = ctl.get();
        if (! isRunning(recheck) && remove(command))
            reject(command);
        else if (workerCountOf(recheck) == 0)
            addWorker(null, false);
    }
    else if (!addWorker(command, false))
        reject(command);
}

Tomcat의 스레드 풀 방식은 자바 표준의 스레드 풀 방식과는 다른점이 있다, 자바 표준 스레드 풀은 스레드 생성을 최대한 아끼고 대기 큐에 줄 부터 세우는 방식으로 큐가 전부 차면 그때 스레드를 추가하는 방식이고, 톰캣 커스텀 스레드 풀은 네트워크 요청을 빠르게 처리하기 위해 대기큐에 두지 말고 최대 스레드 풀 개수만큼 추가해 요청을 빠르게 처리하는 방식이다.

위 코드의 분기를 간략이 설명 하자면

2번째 if 문 : 요청이 들어오면 기본 스레드 풀로 스레드를 생성해 처리한다
3번째 if 문 : 기본 스레드가 전부 채워졌다면 workQueue.offer(command) 시점에 false를 반환
else if 문 : addWorker(command, false) 으로 최대 풀 사이즈까지 워커 스레드를 생성한다

스레드를 생성하는 방식은 addWorker(...) 메서드를 살펴보자 나중에 ...

이렇게 addWorker(...) 내부에서는 Worker 객체로 감싸지게 된다 이 이유는

private boolean addWorker(Runnable firstTask, boolean core) {
    retry:
    for (int c = ctl.get();;) {
        // Check if queue empty only if necessary.
        if (runStateAtLeast(c, SHUTDOWN) &&
                (runStateAtLeast(c, STOP) || firstTask != null || workQueue.isEmpty())) {
            return false;
        }

        for (;;) {
            if (workerCountOf(c) >= ((core ? corePoolSize : maximumPoolSize) & COUNT_MASK)) {
                return false;
            }
            if (compareAndIncrementWorkerCount(c)) {
                break retry;
            }
            c = ctl.get(); // Re-read ctl
            if (runStateAtLeast(c, SHUTDOWN)) {
                continue retry;
                // else CAS failed due to workerCount change; retry inner loop
            }
        }
    }

    boolean workerStarted = false;
    boolean workerAdded = false;
    Worker w = null;
    try {
        w = new Worker(firstTask);
        final Thread t = w.thread;
        if (t != null) {
            final ReentrantLock mainLock = this.mainLock;
            mainLock.lock();
            try {
                // Recheck while holding lock.
                // Back out on ThreadFactory failure or if
                // shut down before lock acquired.
                int c = ctl.get();

                if (isRunning(c) || (runStateLessThan(c, STOP) && firstTask == null)) {
                    if (t.getState() != Thread.State.NEW) {
                        throw new IllegalThreadStateException();
                    }
                    workers.add(w);
                    workerAdded = true;
                    int s = workers.size();
                    if (s > largestPoolSize) {
                        largestPoolSize = s;
                    }
                }
            } finally {
                mainLock.unlock();
            }
            if (workerAdded) {
                t.start();
                workerStarted = true;
            }
        }
    } finally {
        if (!workerStarted) {
            addWorkerFailed(w);
        }
    }
    return workerStarted;
}

여기서 이걸 왜 감싸지 ? 라는 의문이 들었는데 이렇게 감싸는 이유는 Thread는 재사용이 불가능 하기 때문에 풀에 미리 생성해 둔 Thread 가 죽지 않게 하기 위함이다.

여기서도 의문 w.thread.start() 를 해도 되는거 같은데 왜 final로 Thread의 주소를 고정 시켰는지 궁금 했다 이 이유는 멀티스레드 경합 상황에서 필드 변수의 주소값이 흔들리는 것을 원천 차단, 코드 내부에서 반복되는 w.thread. 문구를 제거하여 가독성 높이기 위함이라고 한다.

아무튼 t.start(); 를 하게 되면 http-nio-8080-exec-1 이름 형식을 가진 스레드가 SocketProcessor를 실행 하게 되고 SocketProcessor의 doRun() 메서드를 호출 한다 doRun()은

public abstract class SocketProcessorBase<S> implements Runnable {

    protected SocketWrapperBase<S> socketWrapper;
    protected SocketEvent event;

    public SocketProcessorBase(SocketWrapperBase<S> socketWrapper, SocketEvent event) {
        reset(socketWrapper, event);
    }


    public void reset(SocketWrapperBase<S> socketWrapper, SocketEvent event) {
        Objects.requireNonNull(event);
        this.socketWrapper = socketWrapper;
        this.event = event;
    }


    @Override
    public final void run() {
        Lock lock = socketWrapper.getLock();
        lock.lock();
        try {
            // It is possible that processing may be triggered for read and
            // write at the same time. The lock above makes sure that processing
            // does not occur in parallel. The test below ensures that if the
            // first event to be processed results in the socket being closed,
            // the subsequent events are not processed.
            if (socketWrapper.isClosed()) {
                return;
            }
            doRun();
        } finally {
            lock.unlock();
        }
    }


    protected abstract void doRun();
}

템플릿 메서드 패턴 구조로 작성 되어있어, 내부적으로 Runnable의 run() 메서드를 호출하면서 정의한 doRun() 을 실행 한다.

doRun()의 정의는 다음과 같다

@Override
    protected void doRun() {
        /*
         * Do not cache and re-use the value of socketWrapper.getSocket() in this method. If the socket closes the
         * value will be updated to CLOSED_NIO_CHANNEL and the previous value potentially re-used for a new
         * connection. That can result in a stale cached value which in turn can result in unintentionally closing
         * currently active connections.
         */
        Poller poller = NioEndpoint.this.poller;
        if (poller == null) {
            socketWrapper.close();
            return;
        }

        try {
            int handshake;
            try {
                if (socketWrapper.getSocket().isHandshakeComplete()) {
                    // No TLS handshaking required. Let the handler
                    // process this socket / event combination.
                    handshake = 0;
                } else if (event == SocketEvent.STOP || event == SocketEvent.DISCONNECT ||
                        event == SocketEvent.ERROR) {
                    // Unable to complete the TLS handshake. Treat it as
                    // if the handshake failed.
                    handshake = -1;
                } else {
                    handshake = socketWrapper.getSocket().handshake(event == SocketEvent.OPEN_READ,
                            event == SocketEvent.OPEN_WRITE);
                    // The handshake process reads/writes from/to the
                    // socket. status may therefore be OPEN_WRITE once
                    // the handshake completes. However, the handshake
                    // happens when the socket is opened so the status
                    // must always be OPEN_READ after it completes. It
                    // is OK to always set this as it is only used if
                    // the handshake completes.
                    event = SocketEvent.OPEN_READ;
                }
            } catch (IOException ioe) {
                handshake = -1;
                if (logHandshake.isDebugEnabled()) {
                    logHandshake.debug(sm.getString("endpoint.err.handshake", socketWrapper.getRemoteAddr(),
                            Integer.toString(socketWrapper.getRemotePort())), ioe);
                }
            } catch (CancelledKeyException ckx) {
                handshake = -1;
            }
            if (handshake == 0) {
                SocketState state;
                // Process the request from this socket
                state = getHandler().process(socketWrapper,
                        Objects.requireNonNullElse(event, SocketEvent.OPEN_READ));
                if (state == SocketState.CLOSED) {
                    socketWrapper.close();
                }
            } else if (handshake == -1) {
                getHandler().process(socketWrapper, SocketEvent.CONNECT_FAIL);
                socketWrapper.close();
            } else if (handshake == SelectionKey.OP_READ) {
                socketWrapper.registerReadInterest();
            } else if (handshake == SelectionKey.OP_WRITE) {
                socketWrapper.registerWriteInterest();
            }
        } catch (CancelledKeyException cx) {
            socketWrapper.close();
        } catch (VirtualMachineError vme) {
            ExceptionUtils.handleThrowable(vme);
        } catch (Throwable t) {
            log.error(sm.getString("endpoint.processing.fail"), t);
            socketWrapper.close();
        } finally {
            socketWrapper = null;
            event = null;
            // return to cache
            if (running && processorCache != null) {
                processorCache.push(this);
            }
        }
    }

}

이 메서드를 설명하자면

가장 상단에서 톰캣은 혹시나 서버가 꺼지는 중이거나 비정상적인 소켓인지 먼저 걸러내기
try-catch 블록은 이 연결이 암호화 통신(HTTPS)을 위한 보안 악수(Handshake)가 끝난 안전한 연결인가? 를 판정
getHandler().process(...) 메서드를 통해 스프링 부트의 DispatcherServlet을 사용하기 위한 메서드 호출 부분
스프링 부트 컨트롤러가 JSON 데이터를 브라우저에 성공적으로 전송하고 모든 비즈니스 로직이 마무리되면, 최하단의 finally 실행

getHandler().process(...) 이 메서드의 getHandler() 이 부분은

ConnectionHandler<S>

의 클래스를 할당 받아 내부 process(...) 메서드를 실행 시키고 do-while 문에 있는 이 메서드를 실행

state = processor.process(wrapper, status);

Processor의 process() 를 실행 이때 구현체는 AbstractProcessorLight 이다. 내부 구현에는 여러 상태를 기반으로 분기가 나뉘지만 정상 동작을 했다고 가정 하에 아래 메서드 실행 구현체의 추상 메서드 이다.

state = service(socketWrapper);

실행 하게 되면 Http11Processor 구현체의 service 메서드가 실행되게 된다. 이 구현체는 간략히 설명 하자면

HTTP Request Line 파싱: GET /api/v1/posts HTTP/1.1 문장을 쪼개서 메서드와 URL을 파악
HTTP Headers 파싱: Host, User-Agent, Content-Type 같은 헤더 정보를 읽어 자바 객체 장부에 기록

을 한다고 보면 된다. 이후 이 메서드를 실행

getAdapter().service(request, response);

getAdapter() 을 하면 CoyoteAdapter 구현체가 나오게 되고 이 구현체의 service(...) 메서드가 실행 이후

connector.getService().getContainer().getPipeline().getFirst().invoke(request, response);

이 메서드 호출을 끝으로 클라이언트 -> Tomcat -> Spring 시작점 여기까지가 클라이언트와 서버가 3-Way Handshake 으로 세션을 맺고 소켓을 어떤식으로 사용해 작업을 하는지 등등 .. 많이 배웠다

한 2일 정도 8시간동안 AI한테 물어보면서 코드를 분석하고 따라가 봤는데 생각보다 재미 있었고 퍼즐 맞추듯이 하다보니 그래도 흥미롭게 한거 같다.

Wrapper 객체 오버헤드 프로파일링 & 소켓 버퍼 벤치마크

taetae-o — Sun, 21 Jun 2026 02:57:32 +0900

요구사항

수백만 개의 AI 대화 임베딩 데이터(실수형 벡터)를 자바 Double[], double[] 배열에 적재 해 각각의 힙 메모리 점유율 및 소켓 전송 시 CPU 캐시 미스 비용 비교 분석

문제 정의

double Primitive Type, Double Wrapper Type 을 각각 물리적 메모리를 얼마나 사용하는지, 하드웨어 레벨에서 어떤 성능 차이를 나타내는지 검증하고, 기록 해보자

공통 구성

VECTOR_COUNT (메모리에 적재할 대화 문장의 개수) = 100_000
DIMENSION (대화 문장 1개의 실수형 숫자 개수) = 768

PrimitiveEmbeddingMemoryTest

public class PrimitiveEmbeddingMemoryTest {

    private static final int VECTOR_COUNT = 100_000;
    private static final int DIMENSION = 768;

    private static double[][] embeddings;

    public static void main(String[] args) throws IOException {
        System.out.println("double[][] primitive 임베딩 메모리 테스트");
        System.out.println("VECTOR_COUNT = " + VECTOR_COUNT);
        System.out.println("DIMENSION = " + DIMENSION);

        waitForVisualVm("Before allocation");

        embeddings = createPrimitiveEmbeddings();

        waitForVisualVm("After allocation");

        System.out.println("Done. embeddings length = " + embeddings.length);
    }

    private static double[][] createPrimitiveEmbeddings() {
        Random random = new Random(42);
        double[][] result = new double[VECTOR_COUNT][];

        for (int i = 0; i < VECTOR_COUNT; i++) {
            double[] vector = new double[DIMENSION];

            for (int j = 0; j < DIMENSION; j++) {
                vector[j] = random.nextDouble();
            }

            result[i] = vector;
        }

        return result;
    }

    private static void waitForVisualVm(String phase) throws IOException {
        System.out.println();
        System.out.println("[" + phase + "]");
        System.out.println("VisualVM에서 힙 상태를 확인한 뒤 Enter를 누르세요.");
        System.in.read();
    }
}

Primitive 형식 배열인 경우 메모리 증가

위 사진을 보면 위 메모리 증가의 이유를 알 수있다, 테스트 코드에서 생성한 double[][] 2차원 배열이 생성 되었다

double[][]

Count : 1
Size : 400,016B

이렇게 가지고 있는 이유는 주소는 4B 를 가지고, VECTOR_COUNT가 100,000개 여서 단순 곱셈으로 400,000이 나와야 하지만 16B를 초과하고 있는 모습이다. 이 부분은 자바에서 new 연산자로 생성되는 모든것은 객체이기 때문에 JVM은 이 double[][]이라는 최상위 배열 객체를 관리하기 위해, 포인터 데이터 10만 개를 배치하기 전에 맨 앞 공간에 딱 16바이트만큼의 관리용 메타데이터를 붙인다고 한다.

이때 배열 아닌경우 배열 길이 정보는 제외 될 수 있다.

마크 워드 (Mark Word) (8 바이트)
- 객체의 아이덴티티(해시코드), 가비지 컬렉션(GC) 나이, 락(Lock) 상태 등 자바 시스템이 객체를 제어하기 위한 핵심 메타데이터가 저장됩니다.
클래스 포인터 (Klass Pointer) (4 바이트)
- 이 객체가 자바의 어떤 클래스 정보(double[][])를 가리키고 있는지 알려주는 거울 역할을 합니다.
배열 길이 (Array Length) (4 바이트)
- 일반 객체 헤더(12바이트)와 달리, 배열 객체에만 특별히 붙는 필드입니다. 배열의 방이 총 몇 개인지(length = 100,000)를 기억하는 공간입니다. 이 값이 4바이트(32비트)이기 때문에 자바 배열의 최대 크기가 약 21억 개로 제한되는 것입니다.

double[]

Count : 100,007
Size : 616,000,680B

Count는 1차원 배열을 VECTOR_COUNT 만큼 생성했기 때문이다.

Size는 double[] 배열 1개의 크기는 double (8B) * 768 = 6,160 B 순수 데이터 (6,144B + 배열 헤더 16B) 로 단순히 VECTOR_COUNT * 6,160 B 를 한 값이다.

여기서 왜 7개가 더 있지라고 생각을 해서 찾아본 결과

이 사진에서 볼 수 있듯이 items가 37 부터 시작하는 값이 나타는걸 알 수 있다, 요거는 실행되는 코드에서 double 배열을 내부적으로 생성해서 사용하고 있는것으로 내 생각은 100,000 개만 있어야 한다고 생각 했지만 사소한 오차 인것 같다.

여기서 items가 0인 경우에 size는 16B 인것을 알 수 있어서 관리용 메타데이터의 사이즈인것으로 생각 했다.

Primitive 타입의 배열은 총 객체는 100,001개 생성하는것으로 GC로 인한 프리징 현상을 방지해 시스템의 부하를 최소화 할 수 있다.

워크플로우

1. new double[100,000][] (렌덤 메모리 위치에 생성) 미리 100,000개의 방을 미리 잡아둔다

2. 그 후 루프를 돌면서 인덱스에 new double[768](렌덤 메모리 위치에 생성) 미리 768개의 방을 잡아둔다

3. 2차원 배열에는 렌덤 메모리 위치에 생성된 1차원 배열 주소를 저장한다.

4. 1차원 배열에는 double 값을 별도의 new 없이 값을 삽입 할 수 있다.

1차원 배열의 내부 값은 실제 값

WrapperEmbeddingMemoryTest

public class WrapperEmbeddingMemoryTest {

    private static final int VECTOR_COUNT = 100_000;
    private static final int DIMENSION = 768;

    private static Double[][] embeddings;

    public static void main(String[] args) throws IOException {
        System.out.println("Double[][] wrapper 임베딩 메모리 테스트");
        System.out.println("VECTOR_COUNT = " + VECTOR_COUNT);
        System.out.println("DIMENSION = " + DIMENSION);

        waitForVisualVm("Before allocation");

        embeddings = createWrapperEmbeddings();

        waitForVisualVm("After allocation");

        System.out.println("Done. embeddings length = " + embeddings.length);
    }

    private static Double[][] createWrapperEmbeddings() {
        Random random = new Random(42);
        Double[][] result = new Double[VECTOR_COUNT][];

        for (int i = 0; i < VECTOR_COUNT; i++) {
            Double[] vector = new Double[DIMENSION];

            for (int j = 0; j < DIMENSION; j++) {
                vector[j] = random.nextDouble();
            }

            result[i] = vector;
        }

        return result;
    }

    private static void waitForVisualVm(String phase) throws IOException {
        System.out.println();
        System.out.println("[" + phase + "]");
        System.out.println("VisualVM에서 힙 상태를 확인한 뒤 Enter를 누르세요.");
        System.in.read();
    }
}

Wrapper 형식의 배열인 경우 메모리 증가

Double[][]

Count : 1
Size : 400,016B

이 부분은 Primitive 타입과 같이 100,000개의 주소값 + 메타 데이터의 크기를 가지고 있다.

Double[]

Count : 100,000
Size : 308,800,000B

Primitive 타입과 다르게 Size의 값이 절반으로 준걸 알 수 있다, 여기서도 주소값을 담기 때문에 4B로 계산 되기 때문이다

Double

Count : 76,800,001
Size : 1,843,200,024B

Primitive 타입과 다르게 1차원 배열에 바로 값이 들어가는것이 아닌 new Double로 생성한 주소값이 들어가는걸 알 수 있다. 단순히 100,000 * 768을 하면 알 수 있다.

Double 의 크기는 24B로 메타데이터 (배열 길이 정보 제외, 12B) + double (8B) + 8바이트 정렬 패딩 (4B) 총 24B가 된다.

new 으로 생성되기 때문에 객체의 내부 정보를 담는 메타데이터 12B와 추가 8바이트 정렬 패딩으로 4B가 추가 되었기 때문에 Primitive 타입과 다르게 16B의 오버헤드가 발생하게 된다.

워크플로우

1. new Double[100,000][] (렌덤 메모리 위치에 생성) 미리 100,000개의 방을 미리 잡아둔다

2. 그 후 루프를 돌면서 인덱스에 new Double[768](렌덤 메모리 위치에 생성) 미리 768개의 방을 잡아둔다

3. 2차원 배열에는 렌덤 메모리 위치에 생성된 1차원 배열 주소를 저장한다.

4. 1차원 배열에는 new Double (렌덤 메모리 위치에 생성) 로 생성한 주소의 값을 저장한다.

1차원 배열의 내부 값은 실제 값의 위치를 가리키는 주소값

소켓 전송 시 CPU 캐시 미스 비용 비교 분석

1. CPU 캐시 미스 측정 방법은 인텔리제이의 프로파일러 event=cpu,interval=1000000 옵션으로 간접적으로 측정

event=cpu 옵션은 단순히 시간이 얼마나 걸렸는지 재지 말고, CPU 코어가 명령어(Instructions)를 처리하고 사이클을 소모한 '물리적 작업량'을 기준으로 코드를 쪼개서 보여달라"고 엔진을 바꾸는 옵션
interval=1000000 옵션은 100만) 사이클이 소모될 때마다 딱 한 번씩만 스냅샷을 찍어서 나한테 보고해라"라고 CPU에게 지시하는 샘플링 주기(Sampling Interval) 옵션

이 라인의 값을 비교

sendWrapperData(out, wrapperData, buffer);

SocketServerPrimitiveBenchmark (Primitive 타입 탐색)

버퍼에 값을 추가 하는 라인 부분은 배열의 인덱스 기준 바로 값이 들어있기 때문에 탐색이 빠르다.

buffer.putDouble(data[i][j])

SocketServerWrapperBenchmark (Wrapper 타입 탐색)

Wrapper 타입인 경우

buffer.putDouble(data[i][j])

버퍼에 값을 추가할 때 배열에 있는 참조를 따라가기 때문에 시간이 오래 걸린다는것을 알 수 있다.

2. Apple Instruments 사용해 내 컴퓨터에서 일어나는 CPU 캐시 미스 비교 분석

Store Micro-operations (Speculative) :
CPU가 연산한 결과 데이터를 레지스터에서 메모리(캐시/RAM)로 저장(Store)하라고 명령한 총 횟수
Load Micro-operations (Speculative) :
CPU가 연산을 처리하기 위해 캐시나 RAM에서 데이터를 레지스터로 읽어오려고(Load) 시도한 총 횟수
L1D Store Misses (Speculative) :
데이터를 저장하려고 L1 데이터 캐시를 조회 했지만, 해당 주소가 캐시에 없어서(Miss) 하위 레이어로 밀려난 횟수
L1D Load Misses (Speculative) :
CPU가 데이터를 읽으려고 L1 데이터 캐시를 뒤졌으나 실패한 횟수
L1D Cache Writebacks (Speculative) :
새로운 데이터를 캐시에 올리기 위해, 기존 캐시방에 있던 '수정된 데이터(Dirty Data)'를 지우지 않고 하위 레이어인 L2 캐시로 안전하게 내려보낸 횟수

SocketServerPrimitiveBenchmark (Primitive 타입 탐색)

첫번째 분석

두번째 분석

SocketServerWrapperBenchmark (Wrapper 타입 탐색)

첫번째 분석

두번째 분석

두 방식의 L1D Load Misses (Speculative) 값을 보면 Primitive 타입 보다 Wrapper 타입이 2.5배 정도 높은걸 알 수 있다. CPU가 데이터를 읽기 위해서 L1 캐시를 뒤졌지만 실패한 횟수가 많아지면 그 다음 위치인 L2 ~ RAM 까지 내려가 데이터를 찾게되기 때문에 병목지점이 된다.

이런 문제는 위에서 설명했듯이 new Double() 로 생성하게 되어 렌덤하게 메모리에 적제되고 이것이 배열의 값으로 들어가게 될때 본 데이터가 있는 주소 값을 넣기 때문에 탐색을 할때 배열에 들어가 있는 주소는 연속적이지만, 실제 값을 찾기 위해 한번더 메모리 점프를 하는 문제가 있기 때문에 시간과, 메모리를 많이 차지한다.

taetae-o 님의 블로그

Spring AI 기반 운동 피드백 기능 1차 구현 정리

1. 목표

2. 프로젝트 MVP

2.1 MVP 기능

2.2 단일 운동 피드백 흐름

3. 기술 선택과 구조

3.1 Spring MVC + JPA + Virtual Thread

4. Hexagonal Architecture 기반 패키지 구조

4.1 Domain

4.2 Application In Port

4.3 Application Out Port

5. 핵심 구현 1: 단일 운동 피드백 유스케이스

6. 핵심 구현 2: 운동 기록 저장과 VectorDB 저장 책임 분리

7. 핵심 구현 3: 전략 패턴 기반 운동 타입 확장

7.1 요청 → 도메인 변환 전략

7.2 운동 기록 저장 전략

7.3 임베딩 content 생성 전략

7.4 프롬프트 생성 전략

8. 핵심 구현 4: RDB Entity와 Domain 분리

9. 핵심 구현 5: PostgreSQL pgvector 저장

10. 테스트 전략

10.1 Test Support 분리

10.2 Domain 단위 테스트

10.3 전략 패턴 단위 테스트

10.4 Repository Slice 테스트

10.5 Application 통합 테스트

10.6 Controller Slice 테스트

10.7 Architecture 테스트

11. 할루시네이션 대응 전략

11.1 Template Routing

11.2 Structured Prompt

11.3 Context Grounding Rule

11.4 Query Scope Guard

11.5 No Context, No Answer

12. 다음 구현 계획

12.1 1주일 운동 기반 피드백

12.2 RAG 기반 지식 검색 확장

12.3 인증 사용자 연동

지갑 잔액 차감 동시성 제어 및 락(Lock) 실험

실험 조건 및 가설

Case 1: No Lock (아무런 제어 장치가 없는 동시성 요청)

원인 분석

Case 2 : 낙관적 락

원인 분석

Case 3 : 비관적 락

원인 분석

알게된 점 (Lessons Learned)

MySQL 복합 인덱스로 빠른 조회 및 Using filesort 정렬 부하 해결하기

1. 실험 개요

2. 테스트 시나리오

3. 성능 측정 결과 요약 (Benchmark)

4. 단계별 실행 계획(EXPLAIN) 및 상세 분석

Case 1: 인덱스가 없는 상태 (No Index)

Case 2: 단일 인덱스 적용 후 (user_id)

Case 3: 복합 인덱스 적용 후 (최적화 상태)

알게된 점 (Lessons Learned)

Webhook 수신 운동 데이터 처리시 메모리 폭주 트러블 슈팅(JMC 추적)

간단 요약

문제 사항 분석 (JMC)

문제 1. 웹훅 수신부에서 request body를 byte[]로 전부 읽고 있었다 (웹훅 수신부)

문제 2. DB에서 압축 payload를 byte[]로 전부 올리고 있었다 (워커)

문제 3. 압축을 사용하고 있었지만 처리 경계는 스트리밍이 아니었다 (워커)

문제 4. ByteArrayOutputStream 내부 배열 복사 비용 (워커)

문제 해결

변경1. 웹훅 수신부를 스트리밍 방식으로 변경 (수신부)

변경 2. DB BLOB을 BinaryStream으로 읽도록 변경 (워커)

변경 3. 압축 해제도 byte[]가 아니라 Stream으로 처리 (워커)

변경 4. Activity payload 파싱 경계를 분리 (워커)

웹훅 수신부 + 워커 최종 흐름

변경 후 지표

Platform Thread vs Virtual Thread의 AI I/O 블로킹 효율 비교

비교

Platform Thread를 사용해서 테스트를 진행 한 결과

Instruments 분석

K6 지표 분석

Virtual Thread를 사용해서 테스트를 진행 한 결과

Instruments 분석

K6 지표 분석

RAG(검색증강생성)를 위한 코사인 유사도(Cosine Similarity) 고속 연산

Case 2: 단일 인덱스 적용 후 (`user_id`)