최코딩의 개발

[3부] CS 과제 공부하기

seung_ho_choi.s — Fri, 23 Jan 2026 15:39:22 +0900

1. JDBC 대량 데이터 처리

1-1. 개요

https://balhae.tistory.com/118

섹션1 JDBC 이해

최코딩의 개발 섹션1 JDBC 이해 본문 스프링/스프링 DB 섹션1 JDBC 이해 seung_ho_choi.s 2023. 10. 22. 00:26

balhae.tistory.com

2년 5개월전에 JDBC 생태계를 작성해봤다. 해당 블로그에 레거시한 DB 커넥션 코드도 있다.

자바에서 데이터베이스에 대량의 데이터를 삽입하거나 수정할 때, executeUpdate()를 반복해서 호출하는 것은 성능에 치명적이다. 이를 해결하기 위해 JDBC는 여러 SQL을 묶어서 한 번에 보내는 Batch(배치) 방식을 지원한다.

1-2. 표준 Batch 처리 (addBatch, executeBatch)

pstmt = conn.prepareStatement(sql);
for (int i = 1; i <= 5000; i++) {
    pstmt.setString(1, "Data_" + i);
    pstmt.addBatch(); // 배치 실행 요청을 메모리에 누적

    // 1000건 단위로 나누어 전송 (메모리 및 네트워크 효율 고려)
    if (i % 1000 == 0) {
        pstmt.executeBatch(); // 누적된 배치를 한 번에 DB로 전송
        pstmt.clearBatch();   // 배치 버퍼 초기화
    }
}
pstmt.executeBatch(); // 잔여 배치 처리

표준 JDBC 인터페이스에서 제공하는 방식으로, 대부분의 DBMS(MySQL, Oracle, PostgreSQL 등)에서 공통적으로 사용된다. 개발자가 명시적으로 전송 시점을 결정하는 점이 특징이다.

작동 원리: addBatch()를 통해 SQL을 메모리 큐에 쌓고, executeBatch()를 호출하는 순간 네트워크를 통해 DB로 전송한다.
장점: DB에 의존적이지 않아 코드 이식성이 높고, 전송 타이밍을 개발자가 정밀하게 제어할 수 있다.

즉, 다수의 SQL 실행 요청을 클라이언트 메모리에 누적하고, executeBatch() 호출 시 이를 하나의 요청으로 DB에 전달함으로써, 1,000건의 개별 SQL 실행으로 발생하던 네트워크 왕복 비용을 단 한 번으로 줄일 수 있다.

1-3. 오라클 전용 Batch 처리 (setExecuteBatch, sendBatch)

https://stackoverflow.com/questions/21485461/running-batch-statements-in-oracle-sendbatch-vs-executebatch

running batch statements in Oracle: sendBatch() vs executeBatch()

I'm writing Java code to execute a batch of insert statements into an Oracle database. I've seen in some of the documentation (http://docs.oracle.com/cd/B28359_01/java.111/b31224/oraperf.htm) that ...

stackoverflow.com

정보가 없어서 위 링크를 참고했다. (AI는 100% 신뢰 못하므로..!)

// 오라클 전용 방식 (캐스팅 필요)
OraclePreparedStatement opstmt = (OraclePreparedStatement) conn.prepareStatement(sql);

// 100건이 쌓이면 자동으로 전송하도록 설정
opstmt.setExecuteBatch(100); 

for (int i = 1; i <= 250; i++) {
    opstmt.setString(1, "Oracle_" + i);
    // 100, 200번째에 자동으로 네트워크 전송 발생
    opstmt.executeUpdate(); 
}

// 나머지 50건은 설정값에 도달하지 못했으므로 수동 전송
opstmt.sendBatch();

오라클 JDBC 드라이버(OraclePreparedStatement)에서만 제공하는 독자적인 기능이다. 드라이버가 내부적으로 설정된 개수만큼 데이터를 관리하다가 자동으로 전송하는 묵시적 방식으로 동작한다.

setExecuteBatch(int size): 배치 크기를 미리 설정한다. 이 설정값만큼 executeUpdate()가 호출되면 드라이버가 알아서 DB로 데이터를 보낸다.
sendBatch(): 설정된 크기(size)에 아직 도달하지 않았더라도, 현재 쌓여있는 데이터를 즉시 강제로 전송할 때 사용한다.

2. Oracle DB 동기화 및 이중화(RAC/HA)

DB를 운영할 때 가장 중요한 것은 "서비스가 중단되지 않는 것"과 "데이터를 잃지 않는 것"이다. 이 두 마리 토끼를 잡기 위한 핵심 기술들을 소개하겠다.

2-1. HA (High Availability: 고가용성)

개념: 운영 DB 인스턴스가 죽으면, 대기하고 있던 서버에서 인스턴스를 새로 올려 서비스를 이어받는 방식이다.

DB 매커니즘: OS 레벨의 클러스터 소프트웨어가 '인스턴스 A'를 감시합니다. 장애 시 A를 강제 종료하고, 공유 저장소의 소유권을 서버 B로 넘긴 뒤 '인스턴스 B'를 새로 기동(Cold Failover)한다.

비유: 요리사가 요리하다 쓰러지면, 집에서 쉬던 요리사가 연락받고 달려와 주방을 이어받는다. (출근 시간 동안 주방 정지)장점: 구성이 단순하고 라이선스 비용이 RAC보다 저렴하다.

단점: 대기 서버가 노는 자원 낭비가 발생하며, 장애 전환 시 DB가 다시 켜지는 수 분 동안 서비스가 끊긴다.

도식화:

# HA (High Availability) - 전체 구조

[ 유저 ]
   │
   ├──▶ [WAS 서버 A]  ──┐
   │                    │
   └──▶ [WAS 서버 B]  ──┤
                        │
                        ├──▶ [DB 서버 A]              [DB 서버 B]
                        │      └─ 인스턴스 A             └─ 인스턴스 B
                        │         (Active)                  (Standby)
                        │            │                          │
                        └────────────┴──▶ [공유 디스크] ◀───────┘
                                            (DB 스토리지)
                                            
WAS는 1대여도 상관X

2-2. OPS (Oracle Parallel Server): RAC의 조상

개념: 여러 개의 인스턴스가 하나의 데이터베이스(공유 저장소)를 공유하는 최초의 모델이다.

DB 매커니즘: 여러 인스턴스가 동시에 가동되지만, 인스턴스 간 데이터 교환 기능이 없다. A 인스턴스가 수정 중인 데이터를 B가 읽으려면 반드시 디스크(Storage)에 쓰고 읽는 과정이 필요했습니다. 이를 Disk Ping이라고 한다.

비유: 두 요리사가 한 주방에서 일하는데, 서로 대화를 안 하고 메모지를 벽(디스크)에 붙여서 소통한다. (답답하고 느림)

장점: 여러 서버를 동시에 사용(Active-Active)하는 개념을 처음 도입했다.

단점: 디스크 I/O가 빈번하게 발생하여 노드(서버)를 늘려도 성능이 오히려 떨어지는 병목 현상이 심했다.

도식화

# OPS (Oracle Parallel Server) - 전체 구조 (정리 버전)

[ User ]
   |
   v
[ WAS (1대든 여러대든 OK) ]
   |
   v
+------------------- Oracle OPS Cluster -------------------+
|                                                          |
|   [DB Server A]                          [DB Server B]   |
|   (Instance A)                           (Instance B)    |
|        |                                      |          |
|        |     (인스턴스 간 전용 통신망 없음)        |          |
|        |     (메모리↔메모리 교환 없음)             |          |
|        |                                      |          |
|        +---------------> [ Shared Disk ] <--------------+ |
|                        (DB files on Storage)             |
|                                                          |
|      Disk Ping = 디스크를 중계로 데이터 동기화/교환        |
|                (Instance A → Disk → Instance B)          |
|                                                          |
+----------------------------------------------------------+

2-3. RAC (Real Application Clusters): 현대 가용성의 표준

개념: OPS의 성능 문제를 Cache Fusion 기술로 해결한 진보된 공유 구조이다.

DB 매커니즘: 인스턴스 간 고속 전용망(Interconnect)을 구축합니다. A 인스턴스 메모리(SGA)에 있는 데이터를 디스크를 거치지 않고 직접 B 인스턴스 메모리로 쏴줍니다. 이를 통해 '디스크 핑'을 제거했다.

비유: 요리사들이 무전기를 차고 실시간으로 대화하며 재료를 주고받음. 한 명의 요리사가 쓰러져도 옆 사람이 즉시 요리를 낚아챈다. (중단 없음, 고성능)

장점: 서비스 중단 없는 고가용성(High Availability)과 서버를 추가하면 성능이 올라가는 확장성(Scalability)을 동시에 만족한다.

단점: 라이선스 비용이 매우 비싸고, 인스턴스 간 통신을 관리하는 클러스터 웨어 설정이 복잡하다.

도식화

# RAC (Real Application Clusters) - 전체 구조 (정리 버전)

[ User ]
   |
   v
[ WAS (1대든 여러대든 OK) ]
   |
   v
+------------------- Oracle RAC Cluster -------------------+
|                                                          |
|   [DB Server A]                          [DB Server B]   |
|   (Instance A)                           (Instance B)    |
|        |                                      |          |
|        |<========= Interconnect (Private) ========>|     |
|        |        (Cache Fusion: 메모리 블록 전송)       |     |
|        |                                      |          |
|        +---------------> [ Shared Disk ] <--------------+ |
|                        (DB files on Storage)             |
|                                                          |
+----------------------------------------------------------+

2-4. 데이터 동기화

2-4-1. 개요

데이터베이스 동기화는 두 개 이상의 데이터베이스 간에 데이터를 일치시키는 과정이다. 서로 다른 위치나 시스템에 있는 데이터베이스들이 동일한 정보를 유지하도록 하는 것이 목적이다.

2-4-2. 주요 동기화 방식

단방향 동기화는 하나의 마스터 데이터베이스에서 하나 이상의 슬레이브 데이터베이스로 데이터가 흐른다. 주로 읽기 성능을 향상시키기 위한 복제(Replication)에 사용된다.

양방향 동기화는 여러 데이터베이스가 모두 쓰기와 읽기가 가능하며, 변경사항이 서로 동기화된다. 충돌 해결 메커니즘이 필요하다.

2-4-2. 동기화 시점

실시간 동기화는 트랜잭션이 발생하는 즉시 동기화가 이루어지며, 데이터 일관성이 높지만 성능 부담이 있다.

배치 동기화는 일정 주기마다 변경사항을 묶어서 동기화하며, 성능은 좋지만 일시적인 데이터 불일치가 발생할 수 있다.

3. DataBase CDC (Change Data Capture ) 개념

3-1. 개념

Change Data Capture (CDC)는 데이터베이스의 변화를 실시간으로 감지하고 캡처하는 기술이다. 이를 조금더 직관적으로 해석 한다면, 데이터베이스에서의 삽입(insert), 수정(update), 삭제(delete)와 같은 이벤트가 발생할 때마다 순서대로 기록한다.

3-2. 동작

https://monday9pm.com/what-is-the-cdc-and-what-can-it-do-2cd4a002b061

위 그림은 DMS( Database Migration Service) 를 통해 Kafka 가 MySQL 의 CDC 이벤트를 받은 메시지의 예시이다. 데이터 변경의 타입, 데이터, 테이블, 시간, 트랜젝션ID 등의 정보가 담겨있다. “x 테이블의 x 데이터가 언제 어떤 순서로 변경 되었다” 판단하는데 도움을 준다.

insert, update, delete 를 흔히 데이터 조작어 (DML: Data Manipulation Language)라고 부른다. CDC 는 DML 뿐 아니라 데이터 정의어 (DDL: Data Definition Language) 도 기록된다. DDL 이벤트를 활용하면 완전히 같은 스키마를 유지하는 데이터를 복제하여 유지 할수 있다.

CDC가 구현되기 위해서는 DBMS (DataBase Management System) 의 도움이 필요한다. DBMS 는 관계형 데이터베이스인 PostgreSQL, MySQL 또는 No SQL 인 MongoDB, Cassandra, DynamoDB 등이 있다. 이 중에서 PostgreSQL 은 pg_wal 폴더 안에 WAL 파일에 CDC 이벤트를 기록한다.

정리하자면

MySQL: binlog (Binarly Log)
PostgreSQL: WAL(Write Ahead Log)
MongoDB: Oplog(Operations Log)
Apache Cassandra: commitlog
DynamoDB: DynanaDB Streams / ON

이와 같다.

3-3. CDC로 할 수 있는거

3-3-1. 특정시점으로 복구

데이터베이스에 문제가 생겼을 때, 단순히 '어제의 백업본'으로 돌아가는 것이 아니라 "오늘 오후 2시 10분 5초"와 같이 아주 정밀한 시점으로 복구하는 기술이다.

3-3-2. 실시간 데이터 복제(위쪽에 동기화)

운영 중인 메인 DB의 데이터를 타겟 시스템(분석용 DB, 검색 엔진, 캐시 서버 등)에 실시간으로 똑같이 맞추는 작업이다.

3-3-3. 무중단 데이터 이관

서비스를 멈추지 않고 운영 중인 DB를 새로운 서버나 클라우드로 옮기는 고난도 작업이다.

3-4. 참고

https://monday9pm.com/what-is-the-cdc-and-what-can-it-do-2cd4a002b061

1차로 개념적으로 간단하게 정리했지만 추후 원리까지 다시 공부해서 포스팅하겠다.

4. Oracle 주요 객체와 트랜잭션 메커니즘 정리
(Function / Procedure / Package / Trigger / Redo·Undo / Commit·Rollback)

4-1. PL/SQL 객체 (Function, Procedure, Package, Trigger)

4-1-1. Function(함수)

특정 연산을 수행하고 결과를 반드시 하나의 값으로 돌려주는 객체다

구분	장점	단점
Function	SQL 문장(SELECT, WHERE 등) 안에서 직접 호출할 수 있어 계산 로직의 재사용성이 매우 높다	대량의 데이터를 조회할 때 각 행마다 함수가 실행되면 성능이 급격히 떨어질 수 있다

CREATE OR REPLACE FUNCTION fn_get_tax_price(p_price NUMBER) 
RETURN NUMBER IS
BEGIN
    -- 가격에 1.1을 곱해 부가세 포함 금액 반환
    RETURN (p_price * 1.1); 
END;

-- 사용 예시: SELECT name, fn_get_tax_price(price) FROM products;

실제 예시: 상품 가격을 입력하면 부가세(10%)가 포함된 금액을 계산해 주는 함수

4-1-2. Procedure (프로시저)

특정 비즈니스 로직을 일괄 처리하기 위한 실행 단위다.

구분	장점	단점
Procedure	여러 개의 쿼리를 하나의 묶음으로 처리하여 네트워크 부하를 줄이고 로직을 캡슐화할 수 있다.	일반적인 SQL문(SELECT) 내부에서 함수처럼 호출하여 값을 가져올 수는 없다.

실제 예시: 특정 부서 사원들의 급여를 일괄적으로 10% 인상하는 로직

CREATE OR REPLACE PROCEDURE sp_raise_salary(p_dept_id NUMBER) IS
BEGIN
    UPDATE employees 
    SET salary = salary * 1.1 
    WHERE department_id = p_dept_id;
    
    COMMIT; -- 절차 완료 후 확정
END;

-- 사용 예시: EXEC sp_raise_salary(10);

==> 즉 함수는 “값을 계산해 돌려주는 것”이고, 프로시저는 “작업을 수행하는 것”이다.

4-1-3. Package (패키지)

관련 있는 함수와 프로시저를 하나의 그룹으로 묶어 관리하는 저장소다.

구분	장점	단점
Package	관련 로직을 모듈화하여 관리가 쉽고, 패키지 내 변수를 공유할 수 있으며 메모리 효율이 좋다.	선언부(Spec)와 본체(Body)를 따로 작성해야 해서 초기 설계와 구현에 공수가 더 든다.

-- 1. 선언부 (명세서)
CREATE OR REPLACE PACKAGE emp_admin_pkg AS
    PROCEDURE add_emp(p_name VARCHAR2);
    FUNCTION get_emp_count RETURN NUMBER;
END emp_admin_pkg;

-- 2. 본체 (실제 구현)
CREATE OR REPLACE PACKAGE BODY emp_admin_pkg AS
    PROCEDURE add_emp(p_name VARCHAR2) IS BEGIN ... END;
    FUNCTION get_emp_count RETURN NUMBER IS BEGIN ... END;
END emp_admin_pkg;

4-1-4. Trigger (트리거)

특정 사건(Insert, Update, Delete)이 일어날 때 자동으로 실행되는 감시자다.

구분	장점	단점
Trigger	데이터 무결성을 강제하거나, 로그 기록(Auditing) 등 수동으로 누락하기 쉬운 작업을 자동화한다.	너무 많아지면 "왜 데이터가 바뀌었지?"를 추적하기 어렵고 전체적인 DB 성능을 예측하기 힘들다.

실제 예시: 사원 테이블의 정보가 삭제될 때, 누가 삭제했는지 이력 테이블에 자동으로 저장함

CREATE OR REPLACE TRIGGER trg_emp_delete_log
AFTER DELETE ON employees FOR EACH ROW
BEGIN
    -- 삭제된 사원의 이름과 현재 시간을 로그 테이블에 기록
    INSERT INTO emp_history(emp_name, del_date, user_id)
    VALUES (:OLD.first_name, SYSDATE, USER);
END;

-- 사용자가 DELETE 문만 실행해도 위 로직이 자동 실행됨~~꼸

4-2. Redo Log vs Undo Log

이 두 로그는 데이터의 안전과 일관성을 책임지는 "기록장"이다.

Redo Log (다시 하기):
- 역할: 변경된 모든 내용을 기록합니다. DB가 갑자기 꺼졌을 때, 로그를 보고 마지막 상태로 재현한다.
- 장점: 장애 시 데이터 유실 방지 (복구용)
- 내 작업이 절대로 사라지지 않게 기록하는 것이다.
Undo Log (되돌리기):
- 역할: 변경 전의 데이터를 보관합니다. 사용자가 작업을 취소하거나, 다른 사용자가 수정 중인 데이터를 조회할 때 사용한다.
- 장점: 작업 취소 가능, 작업 중에도 다른 사람에게 이전 데이터 보여준다.
- 즉, 내가 한 작업을 없던 일로 하거나, 남들에게 예전 데이터를 보여주기 위해 원본을 기록 하는 것이다.

4-3. Commit vs Rollback

트랜잭션을 끝내는 두 가지 방법이다.

Commit:
- 의미: "지금까지 한 작업을 DB에 진짜로 반영해!"
- 결과: Undo 세그먼트의 정보가 불필요해지고, Redo 로그에 기록된 내용이 영구 저장된다. 다른 사용자도 내가 수정한 데이터를 볼 수 있게 된다.
- 장점: 데이터 변경을 확정 짓고 다른 사용자에게 공유한다. 작업 결과가 영구적으로 보존된다.
- 단점: 한 번 커밋하면 이전 상태로 되돌리기가 매우 까다롭다(복구 작업 필요)
Rollback:
- 의미: "아차, 실수했다! 작업하기 전으로 다 돌려놔!"
- 결과: Undo Log에 저장해뒀던 '변경 전 데이터'를 다시 덮어써서 원래 상태로 복구한다.
- 장점: 실수하거나 오류가 난 작업을 즉시 취소하여 데이터 오염을 막을 수 있다.
- 단점: 이미 커밋된 데이터는 롤백할 수 없다. 즉 커밋 완료 시점 전으로 갈 수가 없다.

==> 즉 Commit과 Rollback은 사용자가 내리는 '명령'이고, Redo와 Undo는 그 명령을 수행하기 위해 DB가 뒤에서 움직이는 '수단'이라고 보면 된다. 더군다나 Redo는 '결과'만 기록하고 Undo는 '과거의 데이터 자체'를 들고있다.

300원에서 100원으로 수정하고 커밋(Commit)을 완료한 시점의 최종 정리다.

구분	저장된 값	핵심 역할
현재 잔고	100원	커밋을 했으므로 현재 공식 데이터가 됨
Redo	100원	"100원으로 바꿨음"을 기록 (DB가 깨지면 100원으로 복구하기 위함)
Undo	300원	"원래 300원이었음"을 기록 (하지만 커밋 후엔 버려지는 데이터)

[2부] CS 과제 공부하기

seung_ho_choi.s — Thu, 22 Jan 2026 14:15:56 +0900

1. Byte Stream vs Character Stream

https://xxeol.tistory.com/45

1-1. 이론

Stream은 데이터가 이동하는 통로이다. 데이터는 FIFO형태로 전송된다.

Stream의 가장 큰 특징은 단방향으로만 흘러간다는 점인데, 하나의 스트림으로 입출력을 같이 처리할 수 없어 입출력을 위해서는 두 개의 스트림(InputStream/OutputStream)이 필요하다.

InputStream은 외부에서 데이터를 읽는(입력) 역할을 수행하며, OuputStream은 외부로 데이터를 출력하는 역할을 수행한다.

Stream은 처리하는 데이터의 유형에 따라 크게 두 가지 유형으로 나뉜다.

1-2. Byte Stream

데이터를 8비트(1 byte) 단위로 주고받는 가장 기본적인 스트림이다.

이들은 주로 이진 데이터(이미지, 동영상, 파일 등)를 다룰 때 사용된다.

추상 클래스 InputStream, OutputStream를 상속하여 구현한다.

https://xxeol.tistory.com/45

1byte는 범위가 0~255로 알파벳의 대/소문자 아스키 코드 값은 모두 해당 범위에 속한다. 하지만 한글의 아스키 코드 값을 나타내려면 2byte가 필요하고, 따라서 ByteStream에서는 한글이 깨진다.

그래서 한글 File을 읽고 쓸 때는 Character Streams(Reader/Writer)를 활용해야한다.

1-3. Character Stream

데이터를 16비트(2 byte) 단위로 처리하며, 문자 인코딩을 자동으로 처리해 준다.

즉 텍스트 데이터(문자)를 처리하기 위해 설계되었습니다. 세계의 모든 언어(유니코드)를 안전하게 입출력할 수 있습니다.

추상 클래스 Reader, Writer를 상속하여 구현한다.

https://xxeol.tistory.com/45

1-4. 결론

텍스트 파일을 읽거나 쓸 때: 무조건 Character Stream을 권장한다. (특히 BufferedReader를 쓰면 성능이 훨씬 좋아진다.)
그 외 모든 파일(이미지, PDF 등): Byte Stream을 사용해야 데이터 손실이 없다.
바이트를 문자로 변환하고 싶을 때: InputStreamReader나 OutputStreamWriter라는 "브릿지(Bridge) 스트림"을 사용하면 바이트 스트림을 문자 스트림처럼 다룰 수 있다.
이때 브릿지 스트림은 브릿지 스트림(InputStreamReader, OutputStreamWriter)은 캐릭터 스트림 계열에 속하지만,
바이트 스트림과 캐릭터 스트림을 연결하는 변환 전용 스트림이다.
BufferedReader br = new BufferedReader(new InputStreamReader(System.in)); 이 코드가 대표케이스 코딩테스트 공부할때 그냥 썼는데 정확히 공부하니깐 의문점들이 풀렸다.

2. String, StringBuffer, StringBuilder 차이 및 장단점

2-1. 개요

자바에서는 대표적으로 문자열을 다루는 자료형 클래스로 String, StringBuffer, StringBuilder 라는 3가지 자료형을 지원한다. 위 3가지 클래스 자료형은 모두 문자열을 다루는데 있어 공통적으로 사용되지만, 사용 목적에 따라 쓰임새가 많이 달라지게 된다.

이번 목차에는 String, StringBuffer, StringBuilder 클래스 차이점을 알아보고, 이 3가지 중 어느 상황에서 어느 자료형을 사용하는 것이 이상적이고 성능적으로는 어느것이 더 좋은지 총정리 해보는 시간을 가져보겠다.

2-2. String

기본적으로 자바에서는 String 객체의 값은 변경할 수 없다. 이는 한번 할당된 공간이 변하지 않는다고 해서 '불변(immutable)' 자료형 이라고 불리운다. 그래서 초기공간과 다른 값에 대한 연산에서 많은 시간과 자원을 사용하게 된다는 특징이 있다.

String result = "";
result += "hello";
result += " ";
result += "jump to java";
System.out.println(result); // hello jump to java
// → 심플하지만 연산 속도가 느리다는 단점이 있다

String 자료형만으로도 + 연산자나 concat() 메소드를 사용해 문자열을 이어 붙일 수 있다. 그러나 + 연산자를 이용해 String 인스턴스의 문자열을 결합할 경우, 기존 문자열이 수정되는 것이 아니라 내용이 합쳐진 새로운 String 인스턴스가 매번 생성된다.

이로 인해 문자열을 많이 결합할수록 사용되지 않는 문자열 객체가 계속해서 생성되고 버려지게 되며, 그 결과 불필요한 메모리 낭비가 발생할 뿐만 아니라 문자열 결합 성능 또한 급격히 저하되는 단점이 있다.

이는 마치 글을 한 줄씩 추가할 때마다 기존 종이에 이어서 쓰는 것이 아니라,
새 종이를 꺼내 기존 내용을 모두 다시 옮겨 적은 뒤 새로운 내용을 덧붙이는 것과 같다.
문장이 길어질수록 종이를 더 많이 쓰게 되고, 다시 옮겨 적는 시간도 점점 늘어나게 된다.

2-3. StringBuffer / StringBuilder

2-3-1. 그들의 이론

이러한 비효율성을 해결하기 위해 자바에서는 문자열 연산을 전용으로 처리할 수 있는 StringBuffer(또는 StringBuilder) 클래스를 제공한다. 이들 클래스는 내부에 버퍼(buffer)라는 독립적인 공간을 두어 기존 문자열을 복사하지 않고 같은 공간에 문자열을 직접 추가하는 방식으로 동작한다.

StringBuffer sb = new StringBuffer();  // StringBuffer 객체 sb 생성
sb.append("hello");
sb.append(" ");
sb.append("jump to java");
String result = sb.toString();
System.out.println(result); // hello jump to java
// → + 연산보다는 복잡해 보이지만 연산 속도가 빠르다는 장점이 있다

이는 문자열을 이어 붙일 때마다 새 종이를 꺼내 다시 쓰는 대신, 하나의 화이트보드에 내용을 지우지 않고 계속 이어서 작성하는 것과 같다.

이미 적힌 내용을 다시 옮겨 적을 필요가 없기 때문에 불필요한 공간 낭비가 발생하지 않으며, 작업 속도 또한 훨씬 빠르다.

이와 같은 방식 덕분에 StringBuffer와 StringBuilder는 문자열을 반복적으로 결합해야 하는 상황에서
메모리 사용을 줄이고 문자열 연산 성능을 크게 향상시킬 수 있다.

StringBuffer sb = new StringBuffer(); // 기본 16 버퍼 크기로 생성

// sb.capacity() - StringBuffer 변수의 배열 용량의 크기 반환
System.out.println(sb.capacity()); // 16 
 
sb.append("1111111111111111111111111111111111111111"); // 40길이의 문자열을 append
System.out.println(sb.capacity()); // 40 (추가된 문자열 길이만큼 늘어남)

기본적으로 StringBuffer의 버퍼(데이터 공간) 크기의 기본값은 16개의 문자를 저장할 수 있는 크기이며, 생성자를 통해 그 크기를 별도로 설정할 수도 있다.

만일 문자열 연산중에 할당된 버퍼의 크기를 넘게 되면 자동으로 버퍼를 증강 시키니 걱정 안해도 된다. 다만, 효율이 떨어질 수 있으므로 버퍼의 크기는 넉넉하게 잡는 것이 좋다.

2-3-2. StringBuffer와 StringBuilder의 차이

StringBuffer와 StringBuilder 클래스는 둘 다 크기가 유연하게 변하는 가변적인 특성을 가지고 있으며, 제공하는 메서드와 사용 방법도 동일하다.

그렇다면 이 둘의 차이점은 무엇일까? 어렵게 생각할 필요 없이, 사실 차이는 딱 한 가지이다.
바로 멀티 스레드(Thread) 환경에서 안전(thread-safe)하냐 아니냐의 차이이다.

StringBuffer는 모든 메서드에 동기화(synchronized)가 적용되어 멀티 스레드 환경에서도 안전하지만,
이로 인해 불필요한 락(lock) 비용이 발생하여 성능이 상대적으로 떨어질 수 있다.
반면 StringBuilder는 동기화를 지원하지 않는 대신 이러한 비용이 없어 더 빠르게 동작한다.

3. Call by Value / Call by Reference / Reflection

3-1. 개요

메서드를 호출할 때 전달되는 값이 어떤 방식으로 전달되는지에 따라 프로그램의 동작 결과가 달라질 수 있다.
이를 설명하는 개념이 바로 Call by Value와 Call by Reference이다. 특히 자바에서는 객체를 전달할 때 동작 방식이 직관적이지 않아 Call by Reference로 오해하는 경우가 많다.

이번 목차에서는 Call by Value와 Call by Reference의 개념을 정리하고,
자바에서는 어떤 호출 방식을 사용하는지 예제를 통해 살펴본다.
또한 런타임 시점에 클래스 정보를 동적으로 다루는 Reflection 개념까지 함께 정리한다.

3-2. Call by Value (값에 의한 호출)

Call by Value는 메서드 호출 시 값(value)을 복사하여 전달하는 방식이다. 메서드 내부에서 전달받은 값을 변경하더라도
원본 변수에는 아무런 영향을 미치지 않는다. 자바에서 기본 자료형(primitive type)은 모두 Call by Value 방식으로 전달된다.

public class Test {
    static void change(int x) {
        x = 10;
    }

    public static void main(String[] args) {
        int a = 5;
        change(a);
        System.out.println(a); // 5
    }
}

위 코드에서 change() 메서드는 a의 값을 복사한 x를 전달받는다.
따라서 메서드 내부에서 x의 값을 변경하더라도
원본 변수 a의 값은 변경되지 않는다.

3-3. Call by Reference (참조에 의한 호출)

Call by Reference는 메서드 호출 시 변수의 주소(참조)를 전달하는 방식이다.
메서드 내부에서 값을 변경하면 원본 변수의 값도 함께 변경된다.

이 방식은 C++과 같은 언어에서 지원된다. (Java XXX)

#include <iostream>
using namespace std;

void change(int& x) {
    x = 10;
}

int main() {
    int a = 5;
    change(a);
    cout << a << endl; // 10
    return 0;
}

위 코드에서 int& x는 a의 메모리 주소를 직접 참조한다.
따라서 함수 내부에서 값을 변경하면
main 함수의 a 값도 함께 변경된다.

3-4. Java는 Call by Value일까? Call by Reference일까?

결론부터 말하면 자바는 100% Call by Value만 지원한다.
다만 객체를 전달할 때 참조값(reference value)을 값으로 전달하기 때문에
Call by Reference처럼 보이는 경우가 발생한다.

class Box {
    int value;
}

public class Test {
    static void change(Box box) {
        box.value = 10;
    }

    public static void main(String[] args) {
        Box b = new Box();
        b.value = 5;
        change(b);
        System.out.println(b.value); // 10
    }
}

위 예제에서는 객체의 참조값이 복사되어 전달되므로
같은 객체를 가리키게 되고, 그 결과 객체 내부 값이 변경된다.

하지만 참조 자체를 변경하면 원본에는 영향이 없다.

static void change(Box box) {
    box = new Box();
    box.value = 10;
}

이 경우 box는 새로운 객체를 가리키게 되며
원본 객체 b는 변경되지 않는다.
이를 통해 자바가 Call by Value 방식임을 확인할 수 있다.

4. 자바의 리플렉션

4-1. 개요

https://balhae.tistory.com/309

[리메이크] 스프링 컨테이너와 빈에 관해서

스프링 컨테이너란?스프링 컨테이너는 자바 객체(빈, Bean)를 생성하고 관리하며, 의존관계를 자동으로 연결해주는 역할을 한다. 단순한 객체 생성만 담당하는 것이 아니라, 생명주기 관리,

balhae.tistory.com

위 블로그에서 필자가 리플렉션에 대해 간단히 개요를 적어봤다.

리플렉션은 실행 중인 자바 프로그램이 자기 자신을 검사하고 조작할 수 있게 해주는 강력한 기능이다. 쉽게 말해, 프로그램이 런타임에 클래스의 구조를 분석하고, 메서드를 호출하고, 필드 값을 변경할 수 있다는 의미다.

4-2. 동작 과정

Class 객체 획득 - 클래스 정보를 담고 있는 메타데이터 객체를 가져온다
필요한 정보 조회 - 필드, 메서드, 생성자 등의 정보를 Field, Method, Constructor 객체로 얻는다
접근 권한 설정 - setAccessible(true)로 private 멤버 접근을 허용한다
실행/조작 - 메서드 호출, 필드 값 변경, 객체 생성 등을 수행한다

4-3. 주요 메서드

4-3-1. Class 객체 얻기

Class<?> clazz1 = Class.forName("com.example.User");
Class<?> clazz2 = User.class;
Class<?> clazz3 = user.getClass();

4-3-2. 필드 관련

Field[] fields = clazz.getDeclaredFields();  // 모든 필드
Field field = clazz.getDeclaredField("name"); // 특정 필드
field.setAccessible(true);                    // 접근 허용
Object value = field.get(instance);           // 값 읽기
field.set(instance, newValue);                // 값 쓰기

4-3-3. 메서드 관련

Method[] methods = clazz.getDeclaredMethods();           // 모든 메서드
Method method = clazz.getMethod("getName", String.class); // 특정 메서드
method.setAccessible(true);                              // 접근 허용
Object result = method.invoke(instance, args);           // 메서드 호출

4-3-4. 생성자 관련

Constructor<?> constructor = clazz.getConstructor(String.class, int.class);
Object instance = constructor.newInstance("홍길동", 25);

4-3-5. 어노테이션 관련

boolean hasAnnotation = method.isAnnotationPresent(Override.class);
Annotation annotation = method.getAnnotation(ApiEndpoint.class);

4-4. 실제 활용 사례

- 프레임워크 개발 - Spring의 의존성 주입(@Autowired), Hibernate의 ORM 매핑이 리플렉션으로 동작한다. 런타임에 어노테이션을 읽어 빈을 자동 주입하거나 테이블과 객체를 매핑한다.

- 직렬화/역직렬화 - Jackson, Gson 같은 JSON 라이브러리가 객체의 필드를 분석해 JSON으로 변환하거나 그 반대 작업을 수행한다.

- 테스트 프레임워크 - JUnit이 @Test 어노테이션이 붙은 메서드를 찾아 실행한다.

- 플러그인 시스템 - 런타임에 클래스를 동적으로 로드하고 실행하는 확장 가능한 애플리케이션 구조를 만든다.

- 동적 프록시 - AOP, 로깅, 트랜잭션 관리 등을 위해 런타임에 프록시 객체를 생성한다.

4-5. 누가 리플렉션을 사용하는가?

중요: 일반 개발자는 리플렉션 코드를 직접 작성하지 않는다. 프레임워크 개발자가 리플렉션을 사용해 자동화 기능을 만들어두면, 일반 개발자는 그냥 사용만 하면 된다.

4-5-1. 프레임워크 내부 동작 방식

// 일반 개발자가 작성하는 코드 (리플렉션 없음!)
@Component
public class UserService {
    @Autowired
    private UserRepository userRepository;
}

// Spring 내부에서 자동으로 실행되는 코드 (프레임워크 개발자가 작성)
Class<?> clazz = UserService.class;
Object instance = clazz.getDeclaredConstructor().newInstance();

for (Field field : clazz.getDeclaredFields()) {
    if (field.isAnnotationPresent(Autowired.class)) {
        field.setAccessible(true);
        Object dependency = getBeanFromContainer(field.getType());
        field.set(instance, dependency); // 의존성 자동 주입!
    }
}

일반 개발자는 @Autowired만 붙이면 되고, Spring이 런타임에 리플렉션으로 자동으로 객체를 주입해준다.

4-5-2. JSON 라이브러리 동작 방식

// 일반 개발자 코드
User user = new User("김철수", 25);
String json = objectMapper.writeValueAsString(user);

// Jackson 내부 코드 (라이브러리 개발자가 작성)
Class<?> clazz = obj.getClass();
Field[] fields = clazz.getDeclaredFields();

for (Field field : fields) {
    field.setAccessible(true);
    Object value = field.get(obj);
    jsonBuilder.append(field.getName(), value);
}

5. Java Compile option

5-1. 개요

https://balhae.tistory.com/276

자바의 실행 환경

1. JVM이란?JVM(Java Virtual Machine)은 이름 그대로 '자바를 실행하기 위한 가상 기계'입니다. Java의 가장 큰 특징 중 하나는 OS에 종속적이지 않다는 점인데, 이것이 가능한 이유가 바로 이 JVM 때문입니

balhae.tistory.com

자바의 실행 흐름은 위 블로그에 있다. 컴파일 옵션에 관해 정확히 파헤쳐 보자.

자바 컴파일러(javac)는 우리가 작성한 소스 코드(.java)를 JVM이 이해할 수 있는 중간 단계 언어인 바이트코드(Bytecode, .class)로 변환한다. 이 과정은 단순히 파일을 바꾸는 것이 아니라, 컴파일러에게 "어떤 재료를 참고할지", "어느 버전의 JVM에 맞출지" 등을 명령하는 과정이다.

5-2. 핵심 옵션: -classpath (-cp)

자바 컴파일의 성패는 필요한 재료(라이브러리)를 얼마나 잘 찾느냐에 달려 있다.

5-2-1. Classpath란 무엇인가?

우리가 요리(컴파일)를 하려고 레시피(소스 코드)를 펼쳤는데, 재료 리스트에 "마트에서 파는 특제 소스(외부 라이브러리)"가 적혀 있다고 가정하자. 요리사(컴파일러)가 주방을 아무리 뒤져봐도 이 소스가 없다면 요리는 중단된다. 이때 요리사에게 "그 소스는 옆 동네 창고(특정 경로)에 있어!"라고 위치를 알려주는 행위가 바로 Classpath 설정이다.

5-2-2. 왜 에러(package does not exist)가 발생하는가?

error: package org.springframework... does not exist
error: package ???.????.?????? does not exist

스프링 프로젝트처럼 외부 라이브러리에 의존하는 코드를 리눅스에서 직접 컴파일할 때 이 옵션을 빼먹으면, 컴파일러는 라이브러리 위치를 몰라 아래와 같은 에러를 내뱉는다. 재료가 어디 있는지 알려주지 않은 셈이다.

# "lib 폴더 안의 모든(*) 재료를 참고해서 요리해라"
javac -classpath "프로젝트경로/WEB-INF/lib/*" SomeFile.java

이때 위와 같이 -classpath 옵션을 사용하여 라이브러리가 모여 있는 lib 폴더의 경로를 알려주면 된다.

# 리눅스는 콜론(:), 윈도우는 세미콜론(;)으로 경로 연결
javac -classpath "프로젝트경로/lib/*:톰캣경로/lib/*" SomeFile.java

만약 프로젝트 내부 재료뿐만 아니라 톰캣(Tomcat) 엔진의 재료까지 필요하다면 구분자(:)를 사용해 이어준다.

5-3. javac 컴파일 옵션 상세 정리

나중에 개발하면서 필요할때 찾아보자.

https://internet-craft.tistory.com/24

옵션	설명	실생활 비유
-bootclasspath	자바 기본 런타임 클래스 위치 지정	요리의 기본인 '물과 불'을 어디서 끌어올지 정함
-classpath, -cp	필요한 외부 클래스/라이브러리 위치 지정	특제 소스가 있는 옆 동네 창고 위치 알려주기
-d	생성된 클래스 파일 저장 위치 지정	요리 완성본을 담을 접시(폴더) 정하기
-deprecation	사용 권장되지 않는 API 사용 시 경고	"그 재료는 유통기한 임박이니 주의해!"라고 경고함
-encoding	소스 코드 문자의 인코딩 방식 지정	레시피가 한국어인지 영어인지 명시하기
-endorseddirs	승인된 표준 경로 위치 재정의	정부 인증을 받은 정품 재료 경로 지정
-extdirs	확장 기능(Extensions) 위치 재정의	주방에 추가로 설치한 특수 도구함 위치
-g	모든 디버깅 정보 생성	요리 과정을 처음부터 끝까지 영상으로 촬영하기
-g:none	디버깅 정보를 생성하지 않음	기록 없이 요리만 빠르게 끝내기
-help	표준 옵션 개요 출력	요리 도구 사용 설명서 읽기
-J<option>	JVM에 직접 옵션 전달	가스레인지 화력(메모리)을 직접 조절하기
-nowarn	경고 메시지 출력 안 함	요리사가 궁시렁대는 소리(경고) 무시하기
-source	소스 코드의 자바 버전 지정	구버전 레시피인지 신버전 레시피인지 명시
-sourcepath	원본 소스 파일 위치 지정	재료 손질 전 원물(소스)이 쌓여있는 창고 지정
-target	결과물이 실행될 JVM 버전 지정	이 요리가 뷔페용인지(고버전), 도시락용인지(저버전) 정함
-verbose	컴파일 수행 상세 메시지 출력	요리사가 지금 뭐 하는지 하나하나 말하면서 요리함
-version	컴파일러 버전 정보 출력	요리사의 자격증 등급 확인하기
-X	비표준 옵션 개요 출력	요리사의 숨겨진 비기(필살기) 목록 보기

6. Java Memory - Garbage Collection

6-1. 개요

https://balhae.tistory.com/276

자바의 실행 환경

balhae.tistory.com

javac와 동일하게 가비지 컬렉션도 위 링크를 보면 자세히 알 수 있다.

7. Java Static

7-1. 개요

자바에서 static 키워드는 "메모리에 한 번만 올라가고, 모든 객체가 공유한다"는 의미를 갖는다. 보통 변수나 메서드 앞에 붙여서 사용하며, 객체(인스턴스)를 생성하지 않고도 클래스 이름으로 바로 접근할 수 있다는 것이 가장 큰 특징이다.

https://balhae.tistory.com/34

열 세번째, static에 관해

개요: 필자가 하도 헷갈린 드디어 그녀석에 대한 풀이를 해보겠다. https://vaert.tistory.com/101 static - 정적(static)은 고정된 의미를 가지고 있다. - static 키워드를 사용하면 static 변수와 static 메소드를

balhae.tistory.com

무려 3년전에 작성한 게시글..... 지금 보니깐 AI 도움없이 작성했는데 나름 선방하게 작성한거 같다.

7-2. static 변수(정적 변수)

클래스 수준에서 정의된 변수로, 해당 클래스로 생성된 모든 객체가 하나의 메모리 공간을 공유한다.

실생활 비유: 아파트 단지의 '공용 놀이터'와 같다. 집(객체)은 여러 채지만, 놀이터는 하나뿐이며 모든 입주민이 함께 사용한다. 누군가 놀이터에 낙서를 하면 모든 입주민에게 똑같이 보인다.
특징:
- 인스턴스 생성 전, 클래스가 로딩될 때 메모리(Method Area)에 할당된다.
- 프로그램이 종료될 때까지 메모리에 유지된다.
- 공통으로 사용되는 상수나 카운팅 변수에 자주 쓰인다.

7-3. static 메서드(정적 메서드)

객체를 생성하지 않고도 클래스명.메서드명()으로 호출할 수 있는 메서드이다.

용도: 유틸리티 성격의 함수를 만들 때 주로 사용한다. (예: Math.abs(), String.valueOf())
주의사항: static 메서드 안에서는 인스턴스 변수(static이 안 붙은 변수)를 사용할 수 없다. 인스턴스 변수는 객체가 생성되어야만 존재하는데, static은 객체 생성 전부터 메모리에 올라가 있기 때문이다.

7-4. static의 메모리적 관점 (바이트코드와 실행)

우리가 앞서 배운 컴파일 과정과 연결해서 생각하면 static의 원리가 더 명확해진다.

컴파일: javac가 소스를 읽어 바이트코드(.class)를 만든다.
클래스 로딩: JVM이 실행될 때 클래스 로더가 이 바이트코드를 읽는다.
static 할당: 이때 클래스 파일 안에 static으로 선언된 녀석들을 발견하면, 즉시 메서드 영역(Method Area)에 자리를 잡고 값을 초기화한다.

이 과정이 객체 생성(new)보다 먼저 일어나기 때문에, 우리가 new를 하지 않고도 System.out.println()처럼 바로 꺼내 쓸 수 있는 것이다.

7-5. static 사용 시 주의할 점

static은 편하지만 남용하면 독이 된다.

가비지 컬렉션(GC)의 관리 대상이 아니다: 일반 객체는 안 쓰면 GC가 치워버리지만, static은 프로그램이 꺼질 때까지 메모리에 박혀 있다. 너무 많이 만들면 메모리 부족 현상이 생길 수 있다.
객체지향(OOP)과 멀어진다: 데이터와 로직을 묶는 것이 객체지향인데, static은 데이터와 로직을 분리해버리는 경향이 있다.
멀티쓰레드 환경의 위험성: 모든 객체가 하나의 변수를 공유하므로, 여러 명이 동시에 값을 바꾸려 하면 데이터가 꼬일 수 있다. (동기화 이슈)

[1부] CS 과제 공부하기

seung_ho_choi.s — Wed, 21 Jan 2026 11:55:11 +0900

오늘은 회사에서 CS 학습 과제로 총 9가지 주제를 정리해보려고 한다.
이 중 일부는 이전에 작성한 글이 있어, 해당 내용은 기존 글 링크로 대체한다.

1. WebServer vs WAS

https://balhae.tistory.com/312

Web Server와 WAS의 차이와 웹 서비스 구조

최코딩의 개발 Web Server와 WAS의 차이와 웹 서비스 구조 본문 CS Web Server와 WAS의 차이와 웹 서비스 구조 seung_ho_choi.s 2025. 6. 24. 21:00

balhae.tistory.com

2. Get과 Post의 차이점

2-1. 기본 개념 차이

GET 메서드

서버로부터 데이터를 조회(읽기)할 때 사용
요청 파라미터가 URL에 노출됨
예: https://example.com/search?keyword=보안&page=1

POST 메서드

서버에 데이터를 전송하여 리소스를 생성/수정할 때 사용
요청 파라미터가 HTTP Body에 포함됨
URL에는 파라미터가 노출되지 않음

2-2. 주요 차이점 비교표

구분	GET	POST
데이터 위치	URL 쿼리스트링	HTTP Request Body
URL 예시	/user?id=123&name=홍길동	/user
데이터 길이	제한 있음 (보통 2KB)	제한 없음 (서버 설정에 따라)
캐싱	가능 (브라우저 캐시)	불가능
북마크	가능	불가능
브라우저 히스토리	저장됨	저장 안 됨
뒤로가기	안전함	재전송 확인 필요
보안성	낮음	상대적으로 높음
멱등성	있음 (여러 번 호출해도 결과 동일)	없음
용도	조회, 검색	생성, 수정, 삭제, 로그인

2-3. 보안적 관점에서의 차이

2-3.1 GET의 보안 취약점

① URL 노출로 인한 정보 유출

# 로그인을 GET으로 처리하는 잘못된 예
GET /login?username=admin&password=1234

문제점:
✗ 브라우저 히스토리에 저장
✗ 서버 로그에 기록
✗ 프록시 서버 로그에 남음
✗ Referer 헤더를 통해 다른 사이트로 전송될 수 있음

② 서버 로그 파일 노출

# Apache 액세스 로그 예시
192.168.1.100 - - [21/Jan/2026:10:30:45] "GET /login?id=admin&pw=secret123 HTTP/1.1" 200
192.168.1.101 - - [21/Jan/2026:10:31:20] "GET /user?ssn=901234-1234567 HTTP/1.1" 200

→ 로그 파일이 유출되면 민감한 정보가 그대로 노출됨

③ Referer 헤더를 통한 정보 유출

시나리오:
사용자가 https://bank.com/transfer?account=123&amount=1000000 페이지에서
외부 링크를 클릭하면:

다음 사이트로 전송되는 HTTP 헤더:
Referer: https://bank.com/transfer?account=123&amount=1000000

→ 외부 사이트가 계좌번호와 금액 정보를 알 수 있음

④ 브라우저 캐싱 문제

GET 요청은 브라우저에 캐시될 수 있어서:
✗ 공용 PC에서 다음 사용자가 뒤로가기로 정보 조회 가능
✗ 캐시 파일 분석으로 민감 정보 복원 가능
✗ 중간자 공격 시 캐시된 데이터 탈취 가능

2-3.2 POST가 보안적으로 우수한 이유

① HTTP Body에 데이터 은닉

POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 29

username=admin&password=1234

장점:

✓ URL에 노출되지 않아 서버 로그에 민감 정보 미기록
✓ 브라우저 히스토리에 파라미터 저장 안 됨
✓ Referer 헤더로 전송되지 않음
✓ 북마크로 공유되지 않음

② 데이터 길이 제한 없음

GET:  2KB 제한 → 복잡한 암호화 데이터 전송 어려움
POST: 무제한   → 긴 암호화 토큰, 대용량 데이터 전송 가능

③ CSRF 토큰 활용 가능

<form method="POST" action="/transfer">
    <input type="hidden" name="csrf_token" value="random_token_xyz123">
    <input name="amount" value="10000">
    <button type="submit">송금</button>
</form>

POST는 CSRF 보호 메커니즘을 적용하기 용이함

(✔CSRF: CSRF는 사용자가 로그인된 상태를 악용해, 사용자의 의도와 상관없이 공격자가 요청을 대신 보내게 만드는 공격이다. 그래서 서버는 CSRF 토큰 같은 걸로 “이 요청이 진짜 사용자 요청인지”를 확인한다. )

④ 브라우저 재전송 방지

POST 요청 후 뒤로가기 시:
"양식을 다시 제출하시겠습니까?" 경고 표시
→ 중복 거래 방지
→ 실수로 인한 중복 처리 방지

2-4. 활용 가이드라인

GET을 사용해야 하는 경우

✓ 검색 기능: /search?q=keyword
✓ 필터링: /products?category=electronics&price_min=10000
✓ 페이징: /articles?page=2
✓ 공유 가능한 URL: /post?id=123
✓ 캐싱이 필요한 조회: /api/users/123

POST를 반드시 사용해야 하는 경우

✓ 로그인: 사용자명, 비밀번호
✓ 회원가입: 개인정보
✓ 결제: 카드 정보, 계좌 정보
✓ 데이터 생성/수정/삭제
✓ 파일 업로드
✓ 민감한 검색 (의료 정보, 금융 정보 등)

3. L3와 L4 대해

3-1. OSI에 대해

3-1-1. OSI 7계층이란?

이거에 대해 알아보기전에 먼저 OSI(Open Systems Interconnection) 7계층은 네트워크 통신이 일어나는 과정을 7단계로 나눈 국제 표준 모델입니다. 각 계층은 독립적인 역할을 수행하며, 상위 계층은 하위 계층의 서비스를 이용합니다.

3-1-2. OSI 7계층 구조

7계층 - Application Layer (응용 계층)

역할: 사용자가 직접 사용하는 응용 프로그램과 네트워크 간의 인터페이스
프로토콜: HTTP, HTTPS, FTP, SMTP, DNS
실생활 비유: 편지를 쓰는 사람 (내용을 작성)

6계층 - Presentation Layer (표현 계층)

역할: 데이터의 형식 변환, 암호화, 압축
프로토콜: SSL, TLS, JPEG, MPEG
실생활 비유: 번역가 (언어를 상대방이 이해할 수 있게 변환)

5계층 - Session Layer (세션 계층)

역할: 통신 세션의 연결, 유지, 종료 관리
프로토콜: NetBIOS, RPC
실생활 비유: 통화 연결 관리자 (통화 시작과 종료를 관리)

4계층 - Transport Layer (전송 계층) ⭐ L4

역할: 종단 간 신뢰성 있는 데이터 전송 보장
프로토콜: TCP, UDP
포트 번호를 사용하여 응용 프로그램 구분
실생활 비유: 택배 기사 (물건을 확실하게 전달하고 배송 확인)

3계층 - Network Layer (네트워크 계층) ⭐ L3

역할: 서로 다른 네트워크 간의 경로 설정 및 라우팅
프로토콜: IP, ICMP, ARP
IP 주소를 사용하여 목적지 식별
실생활 비유: 우체국 (주소를 보고 어느 지역으로 보낼지 결정)

2계층 - Data Link Layer (데이터 링크 계층)

역할: 같은 네트워크 내에서 직접 연결된 기기 간 데이터 전송
프로토콜: Ethernet, Wi-Fi, MAC
MAC 주소를 사용
실생활 비유: 동네 배달원 (같은 동네 내에서 집 찾아가기)

1계층 - Physical Layer (물리 계층)

역할: 물리적인 전기 신호 전송
장비: 케이블, 허브, 리피터
실생활 비유: 도로와 차량 (실제로 물건을 운반하는 물리적 수단)

3-2. L3 (Network Layer) 깊이 파헤치기

3-2-1. L3의 핵심 역할

L3은 서로 다른 네트워크를 연결하는 계층입니다. 집 주소처럼 고유한 IP 주소를 사용해 전 세계 어디든 데이터를 전달할 수 있습니다.

3-2-2. 실생활 비유로 이해하기

상황: 서울에 사는 당신이 부산에 있는 친구에게 선물을 보낸다고 가정해봅시다.

IP 주소: 친구 집의 전체 주소 (부산광역시 해운대구 ○○동 123-45)
라우터: 각 지역의 우체국과 물류센터
라우팅: 서울 → 경기 물류센터 → 대전 물류센터 → 부산 물류센터 → 해운대구 우체국으로 가는 최적 경로를 찾는 과정

우체국 직원이 주소를 보고 "이건 부산이니까 남쪽으로 보내야겠다"라고 판단하는 것처럼, 라우터는 IP 주소를 보고 어느 방향으로 패킷을 전달할지 결정합니다.

3-2-3. L3 주요 기능

IP 주소 지정: 각 기기에 고유한 주소 부여
라우팅: 최적의 경로를 찾아 데이터 전달
패킷 분할 및 재조립: 큰 데이터를 작은 패킷으로 나누고 다시 합침
네트워크 간 통신: 서로 다른 네트워크를 연결

3-2-4. L3 장비

라우터: 네트워크 간 경로를 설정하고 패킷을 전달
L3 스위치: 스위칭과 라우팅 기능을 모두 수행

3-3. L4 (Transport Layer) 깊이 파헤치기

3-3-1. L4의 핵심 역할

L4는 실제 데이터가 정확하고 안전하게 전달되도록 보장하는 계층입니다. 포트 번호를 사용해 같은 컴퓨터 안에서 어떤 응

용 프로그램으로 데이터를 보낼지 구분합니다.

3-3-2. 실생활 비유로 이해하기

상황: 대형 아파트 단지에 택배가 도착했다고 가정해봅시다.

IP 주소: 아파트 단지 주소 (○○아파트 123동)
포트 번호: 호수 (104동 402호)
TCP: 등기 우편 (받는 사람의 서명을 받고, 분실되면 다시 보내줌)
UDP: 일반 우편 (그냥 우편함에 넣고 감, 빠르지만 분실 가능)

아파트 경비실(라우터)에서 택배를 받으면, 104동까지는 L3이 전달하고, 402호 문 앞까지는 L4가 정확하게 배달하는 것입니다.

3-3-3. L4 주요 기능

포트 번호 지정: 응용 프로그램 구분 (HTTP:80, HTTPS:443, SSH:22)
오류 제어: 데이터 손상 검사 및 재전송
흐름 제어: 수신자의 처리 속도에 맞춰 전송 속도 조절
혼잡 제어: 네트워크 혼잡 방지

3-3-4. L4 장비

L4 스위치: 포트 번호 기반으로 트래픽 분산 (로드 밸런싱)
방화벽: 포트와 프로토콜 기반 접근 제어

3-4. L3와 L4의 차이점 정리

구분	L3 (Network Layer)	L4 (Transport Layer)
주소 체계	IP 주소	포트 번호
역할	네트워크 간 경로 설정	종단 간 데이터 전송 보장
프로토콜	IP, ICMP, ARP	TCP, UDP
관심사	"어디로" 보낼까?	"어떻게" 보낼까?
장비	라우터, L3 스위치	L4 스위치, 방화벽
비유	우체국 (지역 간 배송)	택배 기사 (정확한 배달)

3-5. 실무에서의 활용

L3 활용 사례

라우팅: 서로 다른 네트워크(사무실 네트워크, 데이터센터)를 연결
VPN: IP 기반으로 원격지 네트워크 연결
서브넷 분할: 네트워크를 논리적으로 나누어 관리

L4 활용 사례

로드 밸런싱: 웹 서버 여러 대에 트래픽 분산
방화벽 정책: 특정 포트만 허용/차단
서비스 구분: 같은 서버에서 웹(80), 메일(25), SSH(22) 동시 운영

4. 쿠키와 세션의 차이

https://balhae.tistory.com/274

쿠키 VS 세션

오늘은 기술면접 단골 질문인 쿠키vs 세션에 관해서 정확한 포스팅을 하겠습니다.https://balhae.tistory.com/65 HTTP(CH7)최코딩의 개발 HTTP(CH7) 본문 스프링/HTTP HTTP(CH7) seung_ho_choi.s 2023. 5. 28. 19:39balhae.tistor

balhae.tistory.com

https://balhae.tistory.com/285

JWT vs 세션

https://balhae.tistory.com/274 쿠키 VS 세션오늘은 기술면접 단골 질문인 쿠키vs 세션에 관해서 정확한 포스팅을 하겠습니다.https://balhae.tistory.com/65 HTTP(CH7)최코딩의 개발 HTTP(CH7) 본문 스프링/HTTP HTTP(CH7)

balhae.tistory.com

https://balhae.tistory.com/266

AccessToken과 RefreshToken 인증 방식

최코딩의 개발 AccessToken과 RefreshToken 인증 방식 본문 CS AccessToken과 RefreshToken 인증 방식 seung_ho_choi.s 2025. 4. 5. 23:35

balhae.tistory.com

5. 세션 클러스터링

5-1. 세션 클러스터링(Session Clustering)이란?

세션 클러스터링은 여러 대의 웹 서버(서버 클러스터)가 사용자 세션 정보를 공유하여, 사용자가 어느 서버에 접속하더라도 동일한 세션 상태를 유지할 수 있도록 하는 기술입니다.

세션: 사용자가 웹사이트에 접속해서 로그아웃하거나 일정 시간이 지날 때까지 유지되는 상태 정보 (로그인 정보, 장바구니 등)

클러스터링: 여러 대의 서버를 하나의 시스템처럼 동작하게 만드는 기술

세션 클러스터링: 클러스터 내 모든 서버가 세션 정보를 공유하여, 사용자가 어느 서버로 요청을 보내도 일관된 경험을 제공

5-2. 실생활 비유

상황: 전국에 지점이 있는 은행 시스템

세션 클러스터링 없이: 강남 지점에서 통장을 만들었는데, 다음 날 홍대 지점에 가니 "고객님 정보가 없네요?"라고 함
세션 클러스터링 적용: 모든 지점이 중앙 시스템으로 고객 정보를 공유해서, 어느 지점을 가든 동일한 서비스를 받을 수 있음

사용자는 서버 A, B, C 중 어디에 연결되든 상관없이 자신의 로그인 상태와 데이터를 유지할 수 있습니다.

5-3. 왜 세션 클러스터링이 필요한가?

5-3-1. 단일 서버의 문제점

과거에는 웹 서버 1대로 모든 사용자를 처리했습니다. 하지만 이런 구조는 여러 문제가 있습니다.

문제 1: 서버 과부하

사용자 1만 명이 동시 접속하면 서버 1대가 감당 못함
응답 속도 느려짐

문제 2: 장애 시 서비스 중단

서버가 다운되면 모든 서비스 중단
세션 정보 모두 손실

문제 3: 확장성 부족

트래픽 증가 시 대응 어려움

5-3-2. 해결책: 서버 여러 대 운영 (클러스터링)

여러 대의 서버를 두고 로드 밸런서로 트래픽을 분산시킵니다. 하지만 여기서 새로운 문제가 발생합니다.

바로 세션 불일치 문제!

사용자 요청 #1 → 로드 밸런서 → 서버A (로그인, 세션 생성)
사용자 요청 #2 → 로드 밸런서 → 서버B (세션 없음! 로그인 안 된 것으로 인식)

5-3-3. 실생활 비유

상황: 은행 지점이 여러 개 있는 경우

문제 상황: 강남 지점에서 통장을 만들었는데, 다음 날 홍대 지점에 가니 "고객님 정보가 없네요?"
해결 필요: 모든 지점이 고객 정보를 공유해야 함

이것이 바로 세션 클러스터링이 필요한 이유입니다.

5-4. 세션 클러스터링 방식

5-4-1. Sticky Session (Session Affinity)

개념: 한 사용자는 항상 같은 서버로만 연결되도록 고정

장점

구현이 간단함
추가 세션 저장소 불필요
빠른 응답 속도

단점

서버 간 부하 불균형 발생 가능
해당 서버 장애 시 세션 손실
확장성 제한

실생활 비유
단골 미용실처럼 항상 같은 디자이너에게만 머리를 맡기는 것. 그 디자이너가 퇴사하면 내 헤어 스타일 기록이 사라짐.

동작 방식

로드 밸런서가 쿠키나 IP 주소를 보고 항상 같은 서버로 연결
사용자A → 항상 서버1
사용자B → 항상 서버2
사용자C → 항상 서버1

5-4-2. Session Replication (세션 복제)

개념: 모든 서버가 세션 정보를 서로 복사해서 동기화

장점

어느 서버든 접속 가능
서버 장애 시에도 세션 유지
빠른 세션 접근

단점

서버가 많아질수록 네트워크 트래픽 증가
메모리 사용량 증가 (모든 서버가 모든 세션 저장)
동기화 오버헤드

실생활 비유: 모든 은행 지점이 고객 정보 파일을 복사해서 가지고 있는 것. 정보 업데이트할 때마다 모든 지점에 알려야 한다.

동작 방식

서버A: 세션1, 세션2, 세션3
서버B: 세션1, 세션2, 세션3 (복제본)
서버C: 세션1, 세션2, 세션3 (복제본)

주요 기술

Tomcat Session Clustering
WildFly/JBoss Clustering
Multicast 기반 복제

5-4-3. Session Clustering (중앙 세션 저장소) ⭐ 가장 많이 사용

개념: 별도의 중앙 저장소에 세션을 저장하고, 모든 서버가 공유

장점

서버 대수에 관계없이 확장 가능
서버 장애 시에도 세션 유지
메모리 효율적 (각 서버가 모든 세션 저장 안 함)
서버 추가/제거 용이

단점

중앙 저장소 장애 시 전체 영향
네트워크 지연 발생 가능
추가 인프라 비용

실생활 비유: 모든 은행 지점이 본사의 중앙 데이터베이스를 조회하는 것. 어느 지점에 가든 같은 정보를 볼 수 있음.

동작 방식

서버A ─┐
서버B ─┼─→ Redis/Memcached (중앙 저장소)
서버C ─┘

모든 서버가 중앙 저장소에서 세션을 읽고 씀

주요 기술

Redis (가장 인기)

In-Memory 데이터베이스
빠른 읽기/쓰기 속도
TTL(Time To Live) 자동 만료 지원
데이터 영속성 옵션 제공
클러스터링 지원

Memcached

순수 캐시 전용
Redis보다 단순하고 가벼움
데이터 영속성 없음

데이터베이스 (MySQL, PostgreSQL)

데이터 영속성 보장
속도는 느림
대용량 트래픽에 부적합

6. Character Set & Encoding이란?

6-1. 이론

컴퓨터는 0과 1밖에 모르는 '바보'입니다. 우리가 사용하는 "A", "가", " " 같은 문자를 컴퓨터가 이해하게 하려면 두 가지 단계가 필요합니다.

Character Set (문자 집합): 문자에 고유한 숫자 번호를 매기는 '약속' (예: "A"는 65번이야) 즉 표현할 수 있는 문자들의 목록
Encoding (인코딩): 그 숫자를 컴퓨터 메모리에 저장하기 위해 0과 1로 변환하는 '방식' (예: 65를 어떻게 2진수로 바꿀까?)

실생활 비유: 음식 주문 시스템

Character Set (메뉴판): 메뉴판에 '김치찌개는 1번', '된장찌개는 2번'이라고 번호를 매겨놓은 상태
Encoding (주문 방식): 그 번호를 주방에 전달할 때 '손가락으로 표시'할지, '종이에 적어서' 줄지, '무전기로' 말할지 정하는 규칙

6-2. 왜 문자 집합과 인코딩이 필요한가?

6-2-1. 단일 언어 시대의 한계 (ASCII)

과거에는 영어와 기본 기호만 처리하면 됐기 때문에 7비트(128개)면 충분했습니다. 하지만 한글, 한자, 아랍어 등이 등장하며 문제가 생겼습니다.

문제 1: 각 국가가 자기들만의 인코딩 방식(EUC-KR, Shift-JIS 등)을 만듦
문제 2: 서로 다른 인코딩을 사용하는 시스템끼리 데이터를 주고받으면 글자가 깨짐 (외계어 발생)
해결책: 전 세계 모든 문자를 담을 수 있는 거대한 그릇인 유니코드(Unicode)가 탄생

6-2-2. 주요 Character Set (문자 집합) 방식

종류	특징	비유
ASCII	영어, 숫자, 특수문자만 포함 (128개)	아주 작은 동네 수첩
ANSI	ASCII에 각 나라 언어를 확장한 것 (EUC-KR 등)	동네마다 양식이 다른 장부
Unicode	전 세계 모든 문자에 고유 번호 부여	전 세계 공통 백과사전

6-3. 인코딩 방식 (Encoding) ⭐ 가장 중요

유니코드라는 '번호표'가 있어도, 이걸 실제로 어떻게 저장하느냐에 따라 효율이 달라집니다.

6-3-1. UTF-8 (가변 길이 인코딩) - 가장 많이 사용

개념: 문자에 따라 1바이트에서 4바이트까지 길이를 다르게 사용
특징:
- 영어는 1바이트, 한글은 3바이트로 처리
- ASCII와 완벽하게 호환됨
- 웹 표준이며 가장 효율적임
비유: 글자 크기에 맞춰서 박스 크기를 조절하는 '스마트 포장법'

6-3-2. UTF-16 (고정/가변 혼합)

개념: 기본적으로 2바이트 또는 4바이트 사용
특징
- 한글을 2바이트로 저장할 수 있어 한글 위주 데이터에선 UTF-8보다 용량이 적을 수 있음
- 하지만 ASCII 호환성이 떨어지고 관리가 복잡함
비유: 모든 물건을 중형 또는 대형 박스에만 담는 방식

6-3-4. EUC-KR / CP949 (한글 전용)

개념: 한글만을 위해 만들어진 과거의 방식
특징:
- 한글 2바이트 처리
- 유니코드와 호환되지 않아 현대 웹 환경에선 권장되지 않음
비유: 우리나라에서만 통용되는 지역 화폐

6-4. 왜 글자가 깨질까요? (Decoding Error)

우리가 흔히 보는 ``나 뷁 같은 현상은 인코딩(저장 규칙)과 디코딩(해석 규칙)이 일치하지 않을 때 발생합니다.

상황: "안녕"을 UTF-8(규칙 A)로 저장함
오류: 읽을 때 EUC-KR(규칙 B)로 해석하려고 함
결과: 컴퓨터는 엉뚱한 번호를 찾아내어 이상한 글자를 출력함

7. 암호화 단반향 양방햐 공개키 비공개키 암호화 종류

7-1. 단방향 vs 양방향 암호화 비교

구분	단방향 (One-Way)	양방향 (Two-Way)
복호화 (다시 풀기)	불가능	가능
핵심 목적	데이터의 무결성 확인 (진위 여부), 비밀번호 저장	데이터의 안전한 전송 및 보관
주요 용도	비밀번호 저장, 파일 변조 확인	개인정보 암호화, 이메일 보안
특징	같은 입력값은 항상 같은 결과값이 나옴	키(Key)가 있어야 원래 내용을 볼 수 있음
주요 알고리즘	MD5, SHA-1, SHA-256, SHA-512, bcrypt, scrypt	7-2에 설명

7-2. 대칭키 vs 비대칭키(공개키/개인키) 비교

구분	대칭키 (Symmetric)	비대칭키 (Asymmetric / Public Key)
사용 키 개수	1개 (암호화 키 = 복호화 키)	2개 (공개키로 암호화, 개인키로 복호화)
키 전달 문제	키를 전달하다 탈취당할 위험이 있음	공개키는 공개되어도 안전함 (개인키만 보관)
암호화 속도	매우 빠름	느림 (연산 과정이 복잡함)
주요 알고리즘	AES, DES, 3DES, ARIA, SEED, ChaCha20	RSA, ECC, DSA, ElGamal, Diffie-Hellman
암호화 키	동일한 키	공개키
복호화 키	동일한 키	비밀키
실생활 비유	금고 비밀번호 (번호만 알면 누구나 염)	우체통 (넣는 건 누구나, 꺼내는 건 주인만)

8. 유닉스 & 리눅스 명령어: Crontab (스케줄링 작업)

8-1. Crontab이란?

Crontab(크론탭)은 리눅스나 유닉스 계열 시스템에서 특정 시간에 특정 작업을 자동으로 실행하게 해주는 '예약 실행(스케줄링)' 도구입니다.

Cron: 백그라운드에서 주기적으로 정해진 작업을 실행하는 프로세스 (데몬)
Crontab: 그 작업을 언제, 어떻게 실행할지 적어놓은 '시간표(Table)'

실생활 비유

매일 아침 7시에 울리는 스마트폰 알람과 같습니다. 한 번 설정해두면 내가 신경 쓰지 않아도 정해진 시간에 맞춰 시스템이 일을 수행합니다.

8-2. Crontab 설정 기본 문법

크론탭은 5개의 별(*)과 실행할 명령어로 구성됩니다.

필드 (순서)	의미	범위
*1번째 ()**	분 (Minute)	0 ~ 59
*2번째 ()**	시 (Hour)	0 ~ 23
*3번째 ()**	일 (Day of Month)	1 ~ 31
*4번째 ()**	월 (Month)	1 ~ 12
*5번째 ()**	요일 (Day of Week)	0 ~ 6 (0:일요일, 6:토요일)

8-3. 주요 명령어

터미널에서 크론탭을 관리할 때 사용하는 명령어들입니다.

명령어	기능	비유
crontab -e	크론탭 설정 편집 (Edit)	시간표 작성/수정하기
crontab -l	설정된 내용 확인 (List)	내 시간표 구경하기
crontab -r	모든 크론탭 삭제 (Remove)	시간표 초기화하기

8-4. 실전 활용 예시

자주 쓰이는 설정 방식들을 표로 정리했습니다.

실행 주기	Crontab 설정값	설명
매분마다	* * * * * /path/script.sh	매분 0초에 스크립트 실행
매일 새벽 3시	0 3 * * * /path/script.sh	서버가 한가한 새벽에 데이터 백업
매주 월요일 오전 9시	0 9 * * 1 /path/script.sh	업무 시작 시간 맞춰 주간 보고서 생성
10분마다	/10 * * * /path/script.sh	특정 간격으로 반복 작업 수행

8-5. 왜 Crontab이 필요한가? (사용 이유)

반복 작업 자동화: 매일 수동으로 하던 로그 정리, DB 백업 등을 자동화하여 실수를 방지합니다.
리소스 효율: 트래픽이 적은 새벽 시간에 무거운 배치(Batch) 작업을 돌려 서버 부담을 분산합니다.
시스템 모니터링: 주기적으로 시스템 상태를 체크하고 관리자에게 알림을 보내는 용도로 활용됩니다.

9. 보안의 핵심: SSL(Secure Sockets Layer) & TLS(Transport Layer Security)

9-1. SSL/TLS란?

웹사이트와 브라우저 사이의 통신을 암호화하여 해커가 중간에서 정보를 훔쳐보지 못하게 만드는 보안 프로토콜입니다.

SSL: 1990년대 초반에 넷스케이프에서 처음 만든 보안 규격입니다.
TLS: SSL의 결함을 보완하고 업그레이드한 SSL의 최신 버전입니다.

핵심 포인트

사실상 지금 우리가 사용하는 기술은 대부분 TLS이지만, 사람들에게 익숙한 용어인 SSL로 혼용해서 부르는 경우가 많습니다. (마치 모든 스테이플러를 '호치케스'라고 부르는 것과 비슷합니다.)

9-2. 실생활 비유: 봉인된 특급 우편

HTTP (일반 우편): 누구나 편지 봉투를 뜯어서 내용을 볼 수 있는 일반 엽서 상태
HTTPS (SSL/TLS 적용): 특수 제작된 금고 상자에 편지를 넣고, 받는 사람만 가진 열쇠로 열 수 있는 특급 보안 우편

9-3. SSL/TLS의 주요 역할

역할	설명
암호화 (Encryption)	제3자가 데이터를 가로채도 내용을 읽을 수 없게 만듦
인증 (Authentication)	내가 접속한 사이트가 진짜 그 사이트가 맞는지 확인 (피싱 방지)
데이터 무결성 (Integrity)	전송 중에 데이터가 변조되지 않았음을 보장

9-4. 동작 방식: SSL 핸드셰이크(Handshake)

데이터를 주고받기 전, 클라이언트(브라우저)와 서버가 서로 인사를 나누며 암호화 방식을 정하는 과정입니다. 위에서 설명한 공개키(비대칭키)와 대칭키 방식이 여기서 모두 쓰입니다.

9-4-1. naver.com 접속 시 발생하는 SSL/TLS 핸드셰이크 과정

1단계: Client Hello (브라우저 → 네이버 서버)

사용자가 주소창에 엔터를 치면 브라우저가 네이버 서버에 첫 인사를 건넵니다.

보내는 정보: 브라우저가 지원하는 TLS 버전, 지원하는 암호화 방식(Cipher Suite), 그리고 임의의 난수(Client Random)를 전달합니다.

2단계: Server Hello & Certificate (네이버 서버 → 브라우저)

네이버 서버가 응답합니다.

보내는 정보: 브라우저가 제안한 방식 중 하나를 선택하고, 자신의 신분증인 'SSL/TLS 인증서'를 보냅니다. 이 인증서 안에는 네이버의 공개키가 들어있습니다.

3단계: 인증서 검증 (브라우저의 확인 작업) ⭐ 중요

브라우저는 받은 인증서가 가짜인지 확인합니다.

방법: 브라우저에 내장된 '신뢰할 수 있는 기관(CA)' 목록과 대조합니다. 만약 인증서의 디지털 서명이 유효하다면 "이 서버는 진짜 네이버가 맞구나!"라고 신뢰하게 됩니다.

4단계: Pre-Master Secret 생성 및 전달 (브라우저 → 네이버 서버)

진짜인 게 확인됐으니, 이제 데이터를 암호화할 '비밀번호'를 만들어야 합니다.

동작: 브라우저는 임의의 비밀번호(Pre-Master Secret)를 생성합니다.
암호화: 이걸 그냥 보내면 해커가 가로채겠죠? 그래서 아까 받은 네이버의 공개키로 이 비밀번호를 꽁꽁 얼려버립니다.

5단계: 비밀번호 복호화 (네이버 서버)

서버는 암호화된 비밀번호를 받습니다.

동작: 서버는 자신만 가지고 있는 개인키(Private Key)를 꺼내서 브라우저가 보낸 비밀번호를 풀어냅니다.
결과: 이제 브라우저와 네이버 서버만 아는 공통의 대칭키(세션키)가 생겼습니다.

6단계: 통신 준비 완료 (Change Cipher Spec)

양측은 "이제부터 우리가 공유한 이 대칭키로 모든 데이터를 암호화해서 주고받자!"라고 최종 확인 사인을 보냅니다.

7단계: 데이터 전송 (HTTPS 시작)

이제 우리가 보는 뉴스, 메일 등의 데이터가 대칭키(AES 등)로 암호화되어 전송됩니다. 주소창에는 초록색 자물쇠 아이콘이 뜹니다.

9-5. HTTP vs HTTPS (보안 적용 여부)

구분	HTTP	HTTPS (HTTP over SSL/TLS)
포트 번호	80번	443번
보안성	암호화 없음 (위험)	강력한 암호화 (안전)
검색 노출	검색 순위에서 밀릴 수 있음	구글 등 검색 엔진 최적화(SEO) 우대
신뢰도	브라우저에 '주의 요함' 표시	주소창 옆에 자물쇠 아이콘 표시

서브쿼리와 조인 전략

seung_ho_choi.s — Mon, 19 Jan 2026 15:54:11 +0900

오늘은 회사에서 서브쿼리와 JOIN에 대해 공부하라는 과제를 받아서, 실제 업무에서 마주친 문제를 중심으로 정리해봤다.

문제 상황

가맹점 게시글 목록을 조회할 때 작성자 이름을 함께 보여줘야 한다. 그런데 게시글의 TARGET_TYPE 값에 따라 작성자가 서로 다른 테이블에 저장되어 있다:

TARGET_TYPE = 'customerAdmin' → NTCFG_AGENTUSER 테이블 조회
TARGET_TYPE = 'masterAdmin' → NTEMP_ADMINUSER 테이블 조회

같은 "작성자 이름"이지만 데이터 출처가 다른 상황이다. 이걸 어떻게 한 번의 쿼리로 가져올 수 있을까?

해결 방법 1: 서브쿼리 방식으로 구현

- JOIN 없이 CASE + 상관 서브쿼리 사용

- 행마다 필요한 테이블만 조회

SELECT *
FROM (
    SELECT
        ROWNUM AS RN,
        t.*
    FROM (
        SELECT
            get_code_name('CshCategory', B.CATEGORY) AS CATEGORY,
            B.TITLE,
            B.VIEW_COUNT,
            B.CREATED_AT,
            B.BOARD_ID,
            CASE
                WHEN B.TARGET_TYPE = 'customerAdmin' THEN
                    (
                        SELECT ca.AGENTUSER_NAME
                        FROM NTCFG_AGENTUSER ca
                        WHERE ca.AGENTUSER_ID = B.ADMINUSER_ID
                    )
                WHEN B.TARGET_TYPE = 'masterAdmin' THEN
                    (
                        SELECT ma.ADMINUSER_NAME
                        FROM NTEMP_ADMINUSER ma
                        WHERE ma.ADMINUSER_ID = B.ADMINUSER_ID
                    )
            END AS WRITER_NAME
        FROM TEST_CSH_BOARD B
        WHERE SUBSTR(B.CREATED_AT, 1, 8)
              BETWEEN '20260119' AND '20260119'
        ORDER BY B.BOARD_ID DESC
    ) t
    WHERE ROWNUM <= 15
)
WHERE RN >= 1;

해결 방법 2: JOIN 방식으로 구현

- 두 사용자 테이블을 모두 LEFT JOIN

- CASE WHEN으로 작성자 이름 분기

SELECT
    RN,
    CATEGORY,
    TITLE,
    VIEW_COUNT,
    CREATED_AT,
    BOARD_ID,
    WRITER_NAME
FROM (
    SELECT
        ROWNUM AS RN,
        t.*
    FROM (
        SELECT
            get_code_name('CshCategory', B.CATEGORY) AS CATEGORY,
            B.TITLE,
            B.VIEW_COUNT,
            B.CREATED_AT,
            B.BOARD_ID,
            CASE
                WHEN B.TARGET_TYPE = 'customerAdmin' THEN CA.AGENTUSER_NAME
                WHEN B.TARGET_TYPE = 'masterAdmin' THEN MA.ADMINUSER_NAME
            END AS WRITER_NAME
        FROM TEST_CSH_BOARD B
        LEFT JOIN NTCFG_AGENTUSER CA
            ON B.TARGET_TYPE = 'customerAdmin'
           AND CA.AGENTUSER_ID = B.ADMINUSER_ID
        LEFT JOIN NTEMP_ADMINUSER MA
            ON B.TARGET_TYPE = 'masterAdmin'
           AND MA.ADMINUSER_ID = B.ADMINUSER_ID
        WHERE SUBSTR(B.CREATED_AT, 1, 8)
              BETWEEN '20260119' AND '20260119'
        ORDER BY B.BOARD_ID DESC
    ) t
    WHERE ROWNUM <= 15
)
WHERE RN >= 1;

이렇게 2가지 방식으로 데이터를 가져오는 방식이 있다.

서브쿼리와 JOIN의 차이는 단순한 문법 선택의 문제가 아니라,

데이터를 어떻게 다룰 것인가에 대한 관점의 차이이다.

즉, 결과 집합에서 행(row)을 줄이는 데 초점을 둘 것인지,

아니면 열(column)을 확장해 데이터를 결합할 것인지의 차이라고 볼 수 있다.

JOIN은 여러 테이블의 데이터를 결합해 조회 결과를 구성하는 데 적합하다.
필요한 컬럼들을 한 번에 가져와 화면이나 리포트에 보여줘야 하는 경우,
JOIN은 결과 구조가 명확하고 활용도가 높다.

반면 서브쿼리는 다른 테이블의 데이터를 직접 결합하기보다는,
조건을 계산하거나 존재 여부를 판단해 불필요한 행을 사전에 걸러내는 데 목적이 있다.
특히 대량의 데이터 중 특정 조건을 만족하는 대상만 추려내는 상황에서는
서브쿼리가 쿼리의 의도를 더 분명하게 드러내며, 실행 계획상으로도 효율적인 경우가 많다.

따라서 조회 결과를 어떤 형태로 만들고 싶은지,
즉 데이터를 “붙일 것인지” 아니면 “줄일 것인지”를 기준으로
JOIN과 서브쿼리를 선택하는 것이 가장 합리적인 접근이다.

2025년을 마무리 하며...

seung_ho_choi.s — Wed, 31 Dec 2025 20:05:44 +0900

‍♂️ 무너지고, 다시 일어서며 — 2025년 개발자 회고

2025년은 개발자로서 많이 무너지고 좌절했지만, 그 끝에서 취업이라는 결과를 만들며 다시 회복할 수 있었던 한 해였다.
무엇보다 이 과정을 지나오면서 주변 친구들의 소중함을 많이 깨닫게 된 해이기도 했다.

✔ 한 해 동안의 성과

프로젝트: 4개 이상 완료
자격증: 토익 스피킹 IM3 취득
수상: 2회 (블레이버스, 정션 아시아)
취업: 성공

1월 — 불타오르던 시작

1월은 정말 우여곡절이 많았던 달이었다.
미뤄왔던 토익 스피킹을 드디어 취득했고, 당근 인턴 서류에도 합격했다. 동아리에서 강의를 하며 나름 의미 있는 활동들도 많이 했다.
그리고… 부모님께 ㄷㅂ도 들켰다. 정말 끔찍했다.

이 시기에 처음으로 중소기업 면접도 봤다. 결과는 합격이었지만, 더 좋은 곳을 가고 싶다는 생각에 입사를 포기했다.
이때까지만 해도 에너지가 넘쳤고, 뭐든 할 수 있을 것 같은 자신감이 있었다.

2월 — 좌절과 운이 공존했던 달

당근 면접을 위해 약 10일 동안 준비했다. 면접 당일에는 1시간 30분 가까이 면접을 봤는데, 정말 힘들었다.
중간중간 개발자로서 아직 부족하다는 걸 뼈저리게 느꼈고, 그래도 아주 망친 것 같지는 않아서 결과를 기대했지만 결국 탈락했다.

이후 바로 블레이버스 해커톤에 참가했다.
모든 기능을 완벽히 구현하지는 못했지만, 기획자의 발표와 팀의 적극적인 시연 덕분에 수상까지 이어졌다.
이 경험을 통해 결과만큼이나 자신감과 태도도 중요하다는 걸 느꼈다.

이때부터 졸업과 함께 본격적인 취업 준비를 시작했다.

3월 — 지원, 또 지원

대기업, 중견, 중소 가리지 않고 정말 많은 회사에 지원했다.
면접 준비도 많이 했고, 운 좋게 또 한 번 중소기업 최종 합격을 했다.
하지만 연봉과 기술 스택이 마음에 걸려 입사를 포기했다.

자소서 첨삭을 받으면서 스스로를 돌아보는 시간이 많았고, 내적으로도 많이 성장했다고 느꼈다.

4월 — 처음 느낀 큰 벽

CJ 올리브영 서류에 합격해 테스트를 봤는데, 생각보다 훨씬 어려웠다.
처음으로 “아, 이게 진짜 벽이구나”라는 느낌을 받았다.

대전에서 열린 STDev 해커톤에도 참가했지만, 이 대회에서는 수상을 하지 못했다.
대신 내 문제점을 돌아보고, 앞으로 고쳐야 할 것들을 분명히 인식하게 됐다.

‍ 5월 — 잠깐의 휴식

작년과 마찬가지로 5월은 잠시 숨을 고르는 달이었다.
중간에 본 면접은 솔직히 많이 실망스러웠다.
연봉 3000, 전자정부프레임워크 기반 환경.

“내가 이런 대우를 받으면서 회사를 다녀야 하나?”라는 생각이 들었고, 그래서 오히려 더 열심히 공부하게 됐다.

6월 — 코딩 테스트의 좌절

삼성 계열사 중 한 곳의 코딩 테스트를 보게 됐다.
문제는 두 개였는데, 올리브영보다도 훨씬 어려웠고 결국 한 문제도 풀지 못했다.

그동안 코딩 테스트 준비를 정말 열심히 했기에 충격이 컸다.
당황했고, 스스로에게 실망도 많이 했다.
그래도 포기하지 않고 계속 지원하고 준비했다.

7월 — 프로젝트와 현타

스위프에 참여해 프로젝트를 진행했다.
MSA와 RabbitMQ를 다뤄보긴 했지만, 아직 공부가 많이 필요하다는 걸 느꼈다.

이 시기에 동아리에서 강연도 진행했다.
2번째였지만 누군가에게 설명하면서 내가 알고 있는 것과 모르는 것이 더 명확해졌고, 생각보다 많은 걸 배우는 경험이었다.

지금 깃허브 프로필이 이 강연 사진이다.

약학창업 해커톤에도 참가했는데, 프론트 팀원의 실력 차이로 중간중간 현타가 왔다.
결국 이 대회에서도 수상은 하지 못했다.

8월 — 다시 찾아온 성과

스위프 프로젝트를 마무리하고 정션 아시아 해커톤에 참가했다.
그리고 드디어 6개월 만에 다시 수상했다.

과정도 배운 점도 많았고, 상금 200만 원에 기념품까지 정말 만족스러운 대회였다.
“그래도 내가 헛되게 달려온 건 아니었구나”라는 생각이 들었다.

9월 — 조용히 지나간 시간

서비스 기업 서류 합격 후 준비를 했고, 하나금융그룹 면접도 봤다.
스위프 최종 발표회에서 발표도 했지만, 그 외에는 크게 기억에 남는 일은 없었다.

10~11월 — 끝내 도착한 곳

정말 바쁘고 힘들었던 두 달이었다.
특히 다날 기업 면접은 기억에 남을 정도로 빡셌다.

그럼에도 운 좋게 효성 계열사 갤럭시아머니트리에 최종 합격하며 다시 PG사로 가게 됐다.
입사까지 한 달 동안 글램핑도 가고, 쿠팡도 뛰어보고, 이것저것 해봤다.

3년 동안 쉬지 않고 달려왔던 탓인지, 처음으로 깃허브 잔디가 비어 있었다.

12월 — 새로운 시작

본격적으로 회사에 출근하면서 2025년이 마무리됐다.
정신없이 지나갔지만, 분명 의미 있는 한 해였다.

추가로 우아한테크코스 1차 합격했다..... 하 작년에 준비할걸... 너무 후회된다.

지금으로서는 경력이 더 중요하다. 앞으로 신입 개발자는 더더욱 어려워 질테니...

2026년 목표

2026년에도 2025년과 비슷한 흐름으로 성장하고 싶다.

~2월: 메시지 큐 심화 학습
- 블로그가 아닌 GitHub에 논문·보고서 형태로 정리
3~4월: 대규모 티켓팅 프로젝트
- MSA, 분산 트랜잭션 중심
5~8월: 수익화를 목표로 한 사이드 프로젝트
이후에는 회사에서 배운 시스템을 바탕으로
최신 기술 스택을 적용한 나만의 시스템을 만들고,
문제점을 하나씩 개선하며 성장하고 싶다.

물론 중간에 계속 CS, 김영한 선생님 강의, 자소서 등 공부하면서 열심히 살것이다.

우아한테크코스 8기 프리코스 후기

seung_ho_choi.s — Fri, 21 Nov 2025 21:56:06 +0900

1달만이다! 취업도 하고 이것저것 할 게 많아서 블로그는 손을 놓고 있었는데, 오늘은 우테코 프리코스 후기를 써볼까 한다.

app-release.apk

5.81MB

이번 자유 주제에서 개발한 역사 문화재 인식앱이다. 안드로이드 폰만 작동이 된다. 시연 영상도 추후 다시 찍겠다.

처음 이 프로젝트를 기획할 때만 해도 단순한 앱 개발 아이디어였다. 하지만 우테코 프리코스를 거치면서 이 프로젝트는 내 개발자 인생에서 꽤 중요한 터닝포인트가 되었다.

처음 우테코에 지원하기까지

요즘 개발 커뮤니티를 보면 부트캠프를 거쳐가는 게 거의 기본 과정이 된 것 같다. 내 주변 친구들도 마찬가지였다. 하지만 솔직하게 말하자면, 나는 대학교 3학년부터 꾸준히 공부해왔기 때문에 개발 역량이 부족하다고 느끼지는 않았다. 부트캠프를 가야 할 정도의 긴급한 상황은 아니었던 거다.

그럼에도 불구하고 우테코에 지원한 이유는 단순했다. 한 번 진득하게 다시 공부해 보고 싶었다. 그 과정에서 나와는 다른 개발자들을 만나고 그들로부터 배우고 싶었다. 그리고 무엇보다 자신이 맞다고 생각하는 개발 방식이 정말 맞는지 검증받고 싶었다. 5000자짜리 자소서를 쓸 때도 그런 진심이 충분히 담겨 있었다.

프리코스에서의 깨달음

프리코스가 시작되고 첫 몇 주는 정말 바빴다. 특히 코드리뷰 과정에서 많은 걸 배웠는데, 1주차는 개인 일정 때문에 온전히 집중하지 못했다. 하지만 2주차부터는 정말 몰입했다. 자신이 쓴 코드에 대한 피드백을 받고, 남의 코드를 리뷰하면서 새로운 시각을 얻을 수 있었다.

지금까지 백엔드 프로젝트를 하면서 나는 항상 API 개발에만 집중했다. 기능이 동작하면 그것으로 충분하다고 생각했다. 그 결과는 어떻게 되었을까? 몇 개월이 지나 다시 그 코드를 보려 할 때마다 유지보수의 악몽에 빠졌다. 코드 구조가 복잡하고, 메서드들이 너무 많은 책임을 지고 있었다.

https://balhae.tistory.com/335

[9oormthon 제주 버스 알림콜] 리메이크 및 조회 성능 최적화 하기

https://balhae.tistory.com/219 구름톤(9oormthon) 11기 대상 후기 지원 동기와 과정대학교 4학년, 졸업을 앞둔 시점에서 문득 돌아보니 지금까지 만든 프로젝트들이 너무 의미없게 느껴졌습니다. 진

balhae.tistory.com

대표적인 상황이 저 링크와 같다.

프리코스를 하면서 비로소 깨달았다. 개발은 기능 구현이 아니라 읽을 수 있는 코드를 만드는 것이라는 걸. SOLID 원칙 중 단일 책임 원칙은 개념으로만 알고 있었는데, 코드리뷰를 통해 이게 얼마나 중요한지 체감했다.

한 메서드는 하나의 책임만 가져야 한다. 메서드의 라인 수는 15줄을 넘기지 않는 게 좋다. 기능을 쪼갤 수 있는 만큼 쪼개야 한다. 이런 원칙들이 단순한 규칙이 아니라 유지보수성을 위한 필수 조건이라는 걸 깨달았을 때, 나는 개발자로서 한 단계 성장한 것 같았다.

기능을 만드는 건 개발자라면 누구나 할 수 있다. 하지만 그걸 깔끔하게, 이해하기 쉽게 만드는 건 정말 다른 얘기다. 진정한 개발자는 후자를 할 수 있는 사람이라고 생각한다.

자유주제 프로젝트 - 역사 앱 만들기

3주차 로또 과제를 끝내고 4주차가 되었을 때, 나는 충격을 받았다. 4주차는 이전과 완전히 달랐다. 프리코스 1~3주차를 통해 배운 모든 것을 바탕으로, 평가원들을 감동시킬 수 있는 작품을 만들어야 한다는 과제였다.

그 순간 나는 결정했다. 단순히 프리코스 요구사항을 충족시키는 프로젝트가 아니라, 내가 정말 만들고 싶었던 것을 만들자고.

1년, 아니 2년 전부터 계속 마음에 담고 있던 게 있었다. 한국 문화재를 알려주는 애플리케이션이었다. 그리고 한 가지 더 추가하고 싶었다. 요즘 공부하고 있던 코틀린을 이 프로젝트에 제대로 녹여내고 싶었다.

그래서 결심했다. 남은 3주 동안 Android Studio와 Kotlin으로 앱을 만들고, Spring Boot와 Kotlin으로 백엔드 서버를 구축하겠다고. 우테코에서 배운 클린코드의 원칙들을 여기에 모두 적용해서.

시간과의 싸움

당연히 쉬운 길은 아니었다. 인프런에서 Android 강의를 구매했다. 앱 개발에 대한 기본기가 부족했기 때문에 1주일 동안 빡세게 강의를 듣고 개발하려는 계획이었다.

그런데 세상일이란 게... 정확히 그 시기에 면접과 시험이 겹쳤다. 21일이라는 기간이 있었지만, 실제로 온전히 집중할 수 있었던 건 12일 정도였다. 절박했다. 남은 시간 안에 강의를 완료하고 앱을 완성해야 했다.

그런데 신기한 게, 제약이 오히려 나를 만들었다. 남은 12일 동안 나는 그 어느 때보다 집중했다. 강의를 끝내고, 실제로 앱을 만들어내야 한다는 긴박감이 나를 움직였다. 잠을 줄이고, 밥도 빨리 먹고, 오직 코딩에만 몰입했다.

결국 해냈다. 2년을 기다렸던 그 앱을 만들어냈지만 이후 추가할 기능들은 산더미이다.

https://github.com/Woowacourse-kotlin-master

Woowacourse-kotlin-master

Woowacourse-kotlin-master has 10 repositories available. Follow their code on GitHub.

github.com

마무리하며

이 프로젝트를 완성했을 때의 그 느낌은 정말 특별했다. 단순히 "앱을 만들었다"가 아니라, "클린코드 원칙을 지키면서 앱을 만들었다"는 게 자랑스러웠다. 우테코에서 배운 개발 철학을 실제로 구현해 낼 수 있었기 때문이다.

지금은 이미 취업을 했지만, 만약 우테코 최종 합격 통보를 받았다면 그곳을 택할 것이다. 배달의민족에서 함께 일하고 싶다는 마음은 여전하다.

지금 이 글을 읽는 누군가가 있다면, 이것만큼은 꼭 기억해 줬으면 좋겠다. 개발자가 되는 것은 쉽지만, 좋은 개발자가 되는 것은 정말 어렵다. 그리고 그 과정에서 만나는 피드백과 시행착오들이 얼마나 귀한지.

마지막으로 이런 좋은 기회를 준 우테코 관계자님들께 정말 감사드린다. 앞으로도 배움을 멈추지 않겠다.

인덱스에 대해

seung_ho_choi.s — Thu, 16 Oct 2025 17:24:51 +0900

개요

안녕하세요.
이번 시간에는 인덱스(Index) 에 대해 확실히 정복하고자 한다.

단순히 “검색을 빠르게 해주는 기능”으로만 알고 있었다면, 오늘을 기점으로 인덱스의 구조, 동작 원리, 선택 기준까지 명확히 이해하게 될 것이다.

핵심은 “왜 이 인덱스를 써야 하는가”를 스스로 설명할 수 있는 수준까지 도달하는 것이다.
그럼 지금부터 인덱스의 세계로 함께 들어가보자.

https://balhae.tistory.com/335

[9oormthon 제주 버스 알림콜] 리메이크 및 조회 성능 최적화 하기

balhae.tistory.com

지난 제주 버스 알림콜 프로젝트에서 조회 성능을 최적화하는 과정에서 인덱스에 대해 얕게 공부해 본 적이 있다.

인덱스 A to Z

그렇다면 인덱스란 무엇일까?

인덱스(Index)는 말 그대로 ‘색인’ 또는 ‘목차’를 의미한다.

책에서 원하는 내용을 빠르게 찾기 위해 목차를 보는 것처럼, 데이터베이스에서도 원하는 데이터를 더 효율적으로 찾기 위해 인덱스를 사용한다.

그렇다면 인덱스는 왜 도입되었을까?

그 이유부터 차근히 살펴보자.

fisrt_name	age
김씨	15
이씨	30
박씨	25
김씨	20
이씨	10

위의 그림과 같이 people 테이블이 있다고 가정하자.
이 테이블에서 age = 20인 데이터를 찾으려면

SELECT * FROM people WHERE age = 20;

이라는 쿼리를 실행해야 한다.

하지만 이때 컴퓨터는 age가 20인 행을 찾기 위해 모든 데이터를 처음부터 끝까지 하나씩 확인해야 한다.
만약 행이 1억 개라면, 1억 번을 모두 확인해야 하는 셈이다.

이 방식이 바로 풀 테이블 스캔(Full Table Scan)이다.

풀 테이블 스캔은 데이터를 순차적으로 접근하기 때문에 오히려 작은 테이블에서는 효율적일 수 있다.
또한 적용 가능한 인덱스가 없거나, 인덱스를 적용하더라도 범위가 너무 넓어 성능 이점이 적을 때에도 사용된다.
즉, 비용 대비 효과가 낮을 때 풀 테이블 스캔을 수행하는 것이다.

그렇다면 컴퓨터가 데이터를 더 빠르고 효율적으로 찾기 위해 도입된 것이 바로 인덱스(Index)다.

인덱스를 이해하기 쉽게 예를 들어보자.

숫자 1부터 100까지 중에서 A가 생각한 숫자를 B와 C가 맞혀야 한다고 하자.

B는 1이에요? 2에요? … 이런 식으로 하나씩 물어본다.
→ 최악의 경우 100번을 물어봐야 한다.
C는 “50보다 크나요?”, “75보다 작나요?”처럼 중간값을 기준으로 절반씩 나누며 탐색한다.
→ 이렇게 하면 훨씬 적은 횟수로 원하는 값을 찾을 수 있다.

이처럼 인덱스는 데이터를 정렬한 후, 이진 탐색(Binary Search)처럼 빠르게 접근할 수 있도록 도와준다.

즉, 인덱스를 age 컬럼에 적용하면
age 값을 정렬된 상태로 복사해 별도의 구조(B+Tree 등)로 저장한다.

이를 통해 DB는 정렬된 사본(인덱스)을 통해 빠르게 특정 값을 찾고,
그 인덱스가 가리키는 원본 데이터(테이블 레코드)에 접근하게 된다.

정리하자면,

인덱스란 정렬된 데이터의 사본을 유지하여, 원하는 값을 훨씬 빠르게 찾을 수 있게 하는 기술이다.

인덱스는 Array나 Linked List처럼 단순히 순차적으로 정렬된 구조가 아니라, 트리(Tree) 형태로 정렬된 구조를 가진다.
이때 사용되는 방식이 바로 이진 탐색 트리(Binary Search Tree) 구조이며, 탐색의 시간 복잡도는 O(log N) 수준으로 빠르다.

반면, 인덱스가 없을 경우에는 O(N) 시간이 걸리게 된다.
즉, 이진 탐색 트리 기반의 트리 구조가 기본적인 테이블 인덱스의 핵심 원리이다.

이때 노드를 하나씩만 배치하는 것이 아니라, 두 개 이상씩 묶어서 배치하는 방식을 사용하면 이것이 바로 B-Tree 구조이다.
즉, 이러한 방식으로 구성하면 1부터 13까지의 데이터를 효율적으로 탐색할 수 있으며,

앞서 살펴본 이진 탐색 트리(Binary Search Tree) 방식에서는 1부터 7까지만 처리할 수 있었던 것과 비교해
더 많은 데이터를 한 번에 관리하고 탐색 효율을 높일 수 있다.

위 그림처럼 가이드라인이 제공되어 탐색이 훨씬 용이해진다.
이때 B-Tree와의 가장 큰 차이점은, 단순히 가이드라인만 있는 것이 아니라 하위 노드들이 서로 연결(Linked)되어 있다는 점이다.
즉, 노드 간 이동이 훨씬 간단하며, 특히 범위 검색(Range Scan)에 매우 효율적이다.

예를 들어, ‘나이가 4부터 8까지인 데이터’를 찾는 경우를 보자.

B-Tree에서는 각 값을 찾기 위해 매번 노드를 타고 내려가야 하지만,
B+Tree에서는 한 번 4를 찾은 뒤, 연결된 노드를 따라 순차적으로 이동하기만 하면 된다.

이러한 이유로 최근 대부분의 데이터베이스는 인덱스를 B+Tree 구조로 구현하고 있다.

즉, 정리하자면 인덱스가 없는 경우에는 테이블에 존재하는 모든 데이터를 전부 탐색(Full Table Scan) 해야 하므로
검색 속도가 매우 느리다.

반면, 인덱스가 존재하는 경우에는 트리 구조를 따라 몇 번의 탐색만으로 원하는 데이터를 빠르게 찾을 수 있다.

또한 인덱스에는 원본 테이블의 행 주소(Row Address) 가 함께 저장되어 있어,

해당 주소를 참조함으로써 실제 테이블의 행을 효율적으로 반환할 수 있다.

결과적으로, 인덱스는 검색 속도를 획기적으로 향상시키는 핵심 구조라고 할 수 있다.

원본 테이블

id	강사	출신 대학
1	김을용	서울대
2	박덕팔	연세대
3	이상구	고려대

Index1

강사

김을용

박덕팔

이상구

Index2

출신 대학

고려대

서울대

연세대

인덱스는 특정 컬럼을 복사해 정렬해 두는 구조이기 때문에,
본래 테이블 외에도 위와 같이 추가적인 저장 공간을 차지한다.

따라서 검색에 사용되지 않는 컬럼에 불필요한 인덱스를 생성하는 것은 비효율적이다.

또한 인덱스는 조회 속도를 빠르게 해주는 대신,
데이터를 삽입(INSERT)·수정(UPDATE)·삭제(DELETE) 할 때마다

인덱스도 함께 갱신되어야 한다.
따라서 쓰기 작업이 잦은 테이블에서는 오버헤드가 커지고, 성능이 저하될 수 있다.

클러스터드 인덱스(Clustered Index) 는 일반적으로 PRIMARY KEY로 선언된 컬럼에 자동 적용된다.

보조 인덱스(Non-clustered Index)처럼 별도로 생성되는 구조가 아니라, 테이블 자체의 물리적 데이터가 인덱스 순서에 따라 정렬되는 방식이다.

즉, 테이블 자체가 인덱스 구조로 저장되는 형태라고 볼 수 있다.

일반적으로 인덱스는 하나의 데이터베이스 객체로서 약 10% 정도의 추가 저장 공간을 필요로 한다.
새로운 데이터를 삽입할 때 페이지(Page) 내부에 여유 공간이 없으면,

DB는 공간을 나누어 저장하기 위해 페이지 분할(Page Split) 을 수행한다.

이 과정은 디스크 I/O 증가 및 성능 저하로 이어질 수 있다.

또한 DELETE 작업 시 인덱스 데이터는 실제로 삭제되지 않고 ‘사용 안 함’ 표시만 되며,
UPDATE는 내부적으로 DELETE + INSERT 방식으로 처리된다.

이러한 동작이 반복되면 인덱스의 조각화(Fragmentation) 가 심해지고,
결과적으로 쿼리 성능이 점차 떨어지게 된다.

정리하자면, 인덱스는 조회 성능 향상에는 탁월하지만,

저장 공간 증가와 쓰기 성능 저하라는 대가를 수반한다.
따라서 읽기와 쓰기 비율을 고려한 인덱스 설계가 중요하다.

CREATE TABLE member (
    id INT PRIMARY KEY,         -- 클러스터링 인덱스
    name VARCHAR(255),
    email VARCHAR(255) UNIQUE   -- 논-클러스터링 인덱스
);

보조 인덱스(Non-Clustered Index) 는 우리가 앞서 살펴본 인덱스 구조를 의미한다.

즉, 클러스터드 인덱스와 달리 테이블의 물리적 순서와는 별개로 관리되는 인덱스이다.

이 인덱스는 데이터 행의 주소(Row Address) 를 별도로 가지고 있어, 인덱스를 통해 해당 주소를 찾아가 실제 데이터를 조회하게 된다.

또한, UNIQUE 제약 조건(Constraint) 을 설정하면 해당 컬럼에 대해 자동으로 보조 인덱스가 생성된다.

이로써 중복된 값을 방지함과 동시에,해당 컬럼을 기준으로 한 검색 성능이 향상된다.

-- 보조 인덱스 생성 3가지 방법 정리

-- 방법 1: 제약조건으로 UNIQUE 인덱스 생성
ALTER TABLE member
ADD CONSTRAINT unq_name UNIQUE (name);

-- 방법 2: UNIQUE INDEX 직접 생성
CREATE UNIQUE INDEX unq_idx_name
ON member (name);

-- 방법 3: 일반 INDEX (중복 허용)
CREATE INDEX idx_name
ON member (name);

추가로, 중복을 방지하고 싶다면 UNIQUE 제약 조건을 사용하면 된다.

데이터베이스에서는 일반적으로 기본 인덱스(Default Index) 가 자동으로 생성되지만,
중복을 허용하지 않으려면 UNIQUE INDEX를 명시적으로 생성하면 된다.

즉,

중복 허용 → 일반 인덱스(Normal Index), UNIQUE 제약 조건
중복 방지 → UNIQUE INDEX

이렇게 선택적으로 설정할 수 있다.

실제 보조 인덱스 구조다.

추가로, 클러스터드 인덱스와 논클러스터드 인덱스를 구성할 때는 실제로 보조 인덱스(Non-Clustered Index) 에는 데이터 페이지의 물리적 주소값이 직접 저장되는 것이 아니라, 해당 행을 식별할 수 있는 클러스터드 인덱스의 키 값(ID 컬럼 값) 이 저장된다.

id, 이름, 그룹, 이메일, 성별, 주민번호, 나이 등등

이처럼 인덱스 구조가 복잡하다 보니, 어떤 컬럼에 인덱스를 적용해야 할지 고민이 생긴다.

앞서 언급했듯이, 그 해답은 바로 카디널리티(Cardinality) 에 있다.

즉, 카디널리티가 높은 컬럼, 다시 말해 중복되는 값이 적은 컬럼에 인덱스를 적용하는 것이 효율적이다.

이런 컬럼일수록 인덱스를 통한 데이터 선별 효과가 커지고, 결과적으로 검색 성능 향상에 가장 큰 영향을 준다.

12	10	2	2	12	5	8
id	이름	그룹	성별	이메일	사는 지역	나이
1	승호	BE	남	test1@gmail.com	성남	23
2	디코	BE	여	test2@gmail.com	서울	21
3	세현	BE	남	test3@gmail.com	수원	23
4	유성	BE	남	test4@gmail.com	서울	24
5	용현	FE	여	test5@gmail.com	서울	23
6	민수	BE	남	test6@gmail.com	남양주	24
7	관우	FE	남	test7@gmail.com	서울	24
8	경진	BE	여	test8@gmail.com	서울	23
9	지현	BE	남	test9@gmail.com	서울	24
10	건호	BE	남	test10@gmail.com	서울	23
11	재민	BE	여	test11@gmail.com	인천	24
12	원녕	BE	여	test12@gmail.com	서울	26

예를 들어, ID, 이메일, 주민등록번호와 같은 컬럼이 대표적인 카디널리티가 높은 컬럼이다.

이러한 컬럼들은 값의 중복이 거의 없기 때문에 인덱스를 적용하기에 가장 적합하다.

또한, 인덱스에는 복합 인덱스(Composite Index) 라는 개념도 있다.

복합 인덱스는 여러 컬럼을 결합하여 하나의 인덱스로 구성한 형태로, 왼쪽(앞쪽) 컬럼부터 순서대로 조건에 사용할 때만 효율적으로 동작한다.

즉, 인덱스의 선두 컬럼(Leading Column) 을 기준으로 쿼리를 작성해야 최적의 인덱스 효과를 얻을 수 있다.

CREATE INDEX idx_user ON user (age, name, city);

즉, 해당 테이블의 인덱스는 age → name → city 순으로 정렬되어 있다.

WHERE age = 25
WHERE age = 25 AND name = '승호'
WHERE age = 25 AND name = '승호' AND city = '서울'

이렇게는 where절이 가능하지만

WHERE name = '승호'           -- ❌ age가 빠져서 불가능
WHERE city = '서울'           -- ❌ age, name 다 빠짐
WHERE name = '승호' AND city = '서울'  -- ❌ age가 없으므로 불가능

위와 같이는 안된다.

즉, 인덱스는 항상 맨 왼쪽 컬럼부터 차례로 사용될 때만 의미가 있다.

복합 인덱스

1. 선택도(카디널리티, Cardinality)

인덱스는 검색 범위를 좁히는 구조이기 때문에, 먼저 필터링되는 컬럼의 값이 다양할수록 인덱스 탐색 범위를 빠르게 줄일 수 있다.

즉 값이 다양할수록(중복이 적을수록) 앞에 둔다.

컬럼	서로 다른 값	개수 비교
age	100개 (20~60살 등)	다양성 중간
name	50,000개	다양성 높음
city	10개	다양성 낮음

이 경우 name을 앞에 두는 것이 효율적. (name, age, city)

하지만, 대부분의 쿼리가 age 기준으로 시작한다면 → (age, name, city)도 합리적 선택이 될 수 있다.

2. WHERE 절 사용 빈도

인덱스는 WHERE 절의 조건 컬럼을 기준으로 탐색한다.

따라서 가장 자주 필터링되는 컬럼을 인덱스의 앞부분에 두는 게 핵심이다.

즉 WHERE 조건에 자주 등장하는 컬럼을 앞에 둔다.

SELECT * FROM user WHERE age = 25 AND name = '승호';

대부분의 쿼리가 나이(age)를 조건으로 시작한다면
-> (age, name, city) 순이 가장 효율적이다.
반대로 이름으로 검색하는 경우가 훨씬 많다면
-> (name, age, city) 로 변경하는 게 낫다.

3. 조건 유형 (=, <, >, LIKE 등)

등호(=) 조건은 인덱스를 끝까지 사용할 수 있지만,

범위 조건(<, >, BETWEEN, LIKE)은 그 지점에서 탐색이 끊긴다.

즉 등호(=) 조건 컬럼은 앞에, 범위(<, >, LIKE)는 뒤쪽에 둔다.

-- 등호 조건만 있을 때
SELECT * FROM user
WHERE age = 25 AND name = '승호' AND city = '서울';

→ 인덱스 (age, name, city) 전부 사용

-- LIKE(범위 조건) 포함
SELECT * FROM user
WHERE age = 25 AND name LIKE '김%' AND city = '서울';

→ age까지만 완전 탐색 가능

→ name에서 탐색이 끊기므로 city는 인덱스 미사용 ❌

그래서 등호 조건 컬럼을 앞에, 범위 조건 컬럼을 뒤로 두는 게 원칙이다.

4. ORDER BY / GROUP BY 고려

인덱스는 이미 정렬된 구조이기 때문에, WHERE 조건 이후의 ORDER BY 컬럼이 인덱스 순서와 일치하면
DB가 추가 정렬(filesort) 을 하지 않아도 된다.

즉 정렬이나 그룹화에 사용되는 컬럼은 뒤쪽에 둔다.

SELECT * FROM user
WHERE age = 25
ORDER BY name, city;

→ 인덱스 (age, name, city) 와 정렬 순서가 동일하므로
→ WHERE + ORDER BY를 모두 인덱스로 처리 가능

SELECT * FROM user
WHERE age = 25
ORDER BY city, name;

→ 인덱스 순서와 다르기 때문에 filesort 발생 ❌

문제

그럼 아래 문제를 풀어보자

Book 테이블에
category 칼럼
author 칼럼(작가/식별성 높음/ 동명이인 가능)가 있다.

Book 테이블은 500만개
카테고리는 총 20개로 가정합니다

select * from book where category = ? and author = ?


인덱스
A (category)
B (author)
C (category, author)
D (author, category)

이 쿼리에 대한 인덱스 선택의 문제이다.

1. 해당 쿼리 기준으로 C(category, author)와 D(author, category)의 인덱스 동작의 차이를 설명하세요.

정답:

C는 category로 먼저 좁히고 author로 필터링한다.
D는 author로 먼저 좁히기 때문에 선택도가 높아 더 효율적이다.
두 쿼리 모두 인덱스 시크 가능하지만, 보통 D가 더 빠르

2. 해당 쿼리 기준 가장 느린 인덱스를 선택하세요.

정답:

A(category). 카디널리티가 낮아 한 category당 수십만 건을 스캔해야 한다.

3. 해당 쿼리 기준 B (author)와 D (author, category) 인덱스 동작 차이를 설명하세요.

정답:

B는 author까지만 인덱스로 찾고 category는 테이블에서 비교한다.
D는 두 조건을 모두 인덱스로 처리해 범위가 훨씬 좁다.

4. select * from book category = ? and author like '%단어%' 로 바뀐다면 가장 빠른 인덱스를 선택하세요.
정답:

C(category, author).
category로 먼저 좁히고 LIKE 검색을 그 범위 내에서 수행할 수 있다.

5. select * from book author like '%단어%' 로 바뀐다면 가장 빠른 인덱스를 선택하세요.
정답:

B(author).
LIKE 앞에 %가 있어 전체 스캔이지만, 단일 인덱스라 D보다 효율적이다.

6. select * from book where author = ? 쿼리에서 C (category, author) 인덱스 동작 방식을 설명하세요.

정답:

선두 컬럼(category)이 빠져 탐색이 불가능하다.
결국 전체 인덱스를 스캔해야 한다.

[맞춤형 헤어 컨설팅 예약] 서킷 브레이커 패턴 연구하기

seung_ho_choi.s — Fri, 10 Oct 2025 21:39:39 +0900

https://balhae.tistory.com/252

2025 블레이버스 MVP 개발 해커톤 대회 테크 인사이트상 수상 후기

어느덧 2025년…!!본격적인 취업 준비에 들어가기 전에, 마지막으로 공모전에 참가하고 싶었다.그때 동아리 친구가 블레이버스 개발 해커톤에 나가자고 제안했다.덕분에 동아리 팀원들과 함께

balhae.tistory.com

이번 연휴에는 평소에 미뤄뒀던 주제들을 하나씩 정리해보려 한다.
그중 두 번째로 카카오페이 API 장애 발생시 서킷브레이커 패턴 에 대해 깊이 다뤄볼 예정이다.

개념

서킷브레이커(Circuit Breaker) 는 마이크로서비스나 외부 API 통신에서
연속적인 실패를 감지하고, 일정 기준 이상 실패가 누적되면 호출을 자동으로 차단하는 안정화 패턴이다.

즉, 회로 차단기처럼 시스템이 과열되기 전에 전류를 끊듯이,
API 요청이 계속 실패할 경우 회로(요청 경로)를 ‘OPEN’ 상태로 전환해 더 이상 요청을 보내지 않는다.

이렇게 하면 장애가 발생한 외부 서비스로의 불필요한 요청과 리소스 낭비를 막고,

시스템 전체로 장애가 확산되는 것을 방지할 수 있다.

회로는 일정 시간 후 자동으로 HALF_OPEN → CLOSED 상태로 복귀하면서,
외부 서비스가 복구되었는지를 소량의 요청으로 테스트한다.

개발 프로세스

맞춤형 헤어 컨설팅 예약 시스템은 KakaoPay API에 장애가 발생할 경우, 일정 실패율 임계치에 도달하면 회로(Circuit Breaker)가 자동으로 차단(Open) 되어 추가적인 장애 전파를 방지한다.

또한 Fail-Fast 전략을 적용하여, 회로가 열린(Open) 상태에서는 즉시 실패 응답을 반환함으로써 사용자 대기 시간을 최소화한다.

한편, Retry 메커니즘을 통해 일시적인 네트워크 장애나 타임아웃이 발생했을 경우 최대 3회까지 재시도를 수행한다.

회로는 자동으로 OPEN → HALF_OPEN → CLOSED 상태 전환을 거쳐 정상 복구되며,

만약 CallNotPermittedException이 발생할 경우에는 보상 트랜잭션을 수행하여 시스템 안정성을 보장한다.

적용

resilience4j:
  circuitbreaker:
    instances:
      kakaoPayCB:
        registerHealthIndicator: true
        slidingWindowSize: 10                  #  최근 10회의 요청을 기준으로 상태를 판단
        minimumNumberOfCalls: 5                #  최소 5회 이상 호출되어야 통계 유효
        failureRateThreshold: 30               #  실패율 임계치 (30%) → 초과 시 회로 OPEN
        waitDurationInOpenState: 10s           #  회로 OPEN 상태 유지 시간 (10초 후 HALF_OPEN으로 전환)
        permittedNumberOfCallsInHalfOpenState: 3 #  HALF_OPEN 시 테스트 호출 3회 허용
        automaticTransitionFromOpenToHalfOpenEnabled: true #  자동으로 HALF_OPEN → CLOSED 상태 전환
        # Fail-Fast 전략: 회로가 OPEN 상태일 때는 CallNotPermittedException 즉시 발생 → 대기 없이 실패 반환

  retry:
    instances:
      kakaoPayRetry:
        max-attempts: 3                        #  최대 재시도 횟수 (3회)
        wait-duration: 1s                      #  재시도 간 대기 시간 (1초)
        # 일시적 장애 시 자동 재시도 수행 (Timeout, Connection Error 등)

위와 같이 application.yml에 설정을 추가했다.

실패율 임계치를 30%로 설정한 이유는, 결제 요청은 네트워크나 외부 API 상태에 따라 일시적으로 실패할 수 있지만,
3건 중 1건 이상 실패가 지속된다면 이는 단순한 일시 장애가 아니라 시스템적 문제로 판단하기 때문이다.

즉, 30% 이상에서 회로를 차단함으로써 불필요한 외부 호출을 줄이고 서버 자원을 보호할 수 있다.

또한 재시도 횟수를 3회로 설정한 이유는,
일시적인 네트워크 지연이나 타임아웃은 대부분 1~2초 내 재요청 시 복구되기 때문이다.
하지만 과도한 재시도는 오히려 API 서버 부하를 가중시킬 수 있어, 안정성과 효율성의 균형을 고려해 3회로 제한했다.

@Configuration
@RequiredArgsConstructor
public class ResilienceConfig {

    private final CircuitBreakerRegistry circuitBreakerRegistry;
    private final RetryRegistry retryRegistry;

    @Bean
    public CircuitBreaker kakaoPayCircuitBreaker() {
        return circuitBreakerRegistry.circuitBreaker("kakaoPayCB");
    }

    @Bean
    public Retry kakaoPayRetry() {
        return retryRegistry.retry("kakaoPayRetry");
    }
}

Resilience4j의 CircuitBreaker와 Retry를 수동 빈(@Bean) 으로 등록한 이유는,
단순히 설정 기반의 AOP 방식이 아니라 비즈니스 로직 내부에서 직접 제어하기 위해서다.

결제 요청 로직은 CircuitBreaker와 Retry를 조합해 감싸는 구조로,

자동 설정(AOP) 방식은 호출 흐름을 직접 제어할 수 없어,
Retry와 CircuitBreaker를 조합하거나 조건별로 분리 적용하는 세밀한 제어가 불가능하다.

따라서 CircuitBreakerRegistry와 RetryRegistry를 주입받아

명시적으로 인스턴스를 생성하고 로직 단위에서 제어할 수 있도록 구성했다.

/**
 * 0️⃣ 결제 준비 전 로직 - 주문 생성 및 KakaoPay Ready 요청
 */
@Override
public KakaoPayReadyResponse payLogic(String userId, ReadyRequestDTO reqDto) {
    String orderId = UUID.randomUUID().toString();

    //   서킷브레이커 + 리트라이 데코레이션
    Supplier<KakaoPayReadyResponse> decoratedSupplier =
            CircuitBreaker.decorateSupplier(kakaoPayCircuitBreaker,
                    Retry.decorateSupplier(kakaoPayRetry,
                            () -> requestPayReady(orderId, userId, reqDto.amount())
                    ));

    try {
        .... 실행

    } catch (CallNotPermittedException e) {
        .... 보상 트랜잭션 실행
    } catch (Exception e) {
        .... 에러 실행
    }
}

서킷브레이커 + 재시도 적용

위 코드는 결제 요청의 핵심은 requestPayReady() 메서드에서 카카오페이 결제 API를 호출하는 부분이다.
이 호출 구간을 단순히 실행하는 대신, Retry와 CircuitBreaker로 감싸서 안정성을 보강한다.

Retry는 일시적인 네트워크 문제나 타임아웃이 발생했을 때 최대 3회까지 자동으로 재시도하도록 설정되어 있다.

반면, CircuitBreaker는 호출 실패율이 30% 이상으로 올라가면 회로를 자동으로 “OPEN” 상태로 전환하여
더 이상 외부 API를 호출하지 않는다.

Fail-Fast 전략

회로가 OPEN 상태가 되면, Resilience4j는 외부 API를 호출하지 않고 즉시 CallNotPermittedException을 발생시킨다.

이는 “Fail-Fast 전략”으로, 불필요한 대기 없이 사용자에게 바로 실패 응답을 반환하게 한다.

덕분에 카카오페이 쪽 서버가 장애를 일으키더라도 우리 서버의 스레드가 대기 상태로 묶이지 않고,
빠르게 실패를 감지하고 안정적으로 복구를 준비할 수 있다.

예외 및 복구 처리

만약 회로가 열린 상태에서 요청이 들어오면 CallNotPermittedException이 발생하고,
우리는 이 예외를 잡아서 보상 트랜잭션(예: 결제 취소, 재시도 안내 등)을 수행한다.

분석

K6 부하 테스트를 통해 서킷브레이커 적용 전후의 성능 변화를 분석하고, 이를 통해 시스템 효율성을 검증하고자 한다.

import http from 'k6/http';
import { check, sleep } from 'k6';

// 부하 설정
export const options = {
    vus: 50,                 // 동시 사용자 50명
    duration: '30s',         // 30초간 지속
    thresholds: {
        http_req_failed: ['rate<0.1'],          // 실패율 10% 이하 목표
        http_req_duration: ['p(95)<2000'],      // 95% 요청이 2초 이하
    },
};

// 테스트 대상 API
const BASE_URL = 'http://localhost:8080';
const PAY_URL = `${BASE_URL}/api/pay/ready`;

// 각 VU(가상 유저)에 고유 userId 부여 (2~51)
export default function () {
    const userId = `user${__VU + 1}`;  // __VU: k6 내장 전역변수 (1부터 시작)
    const payload = JSON.stringify({
        amount: 1000,
        userId: userId,
    });

    const params = {
        headers: { 'Content-Type': 'application/json' },
    };

    // POST 요청 실행
    const res = http.post(PAY_URL, payload, params);

    // 결과 검증
    check(res, {
        'status is 200': (r) => r.status === 200,
    });

    // 각 요청 사이에 약간의 대기 (0.5초)
    sleep(0.5);
}

코드는 위와 같다.

결과는 위와 같다. 왼쪽이 적용 전, 오른쪽이 적용 후 사진이다.

구분	CircuitBreaker 미적용	CircuitBreaker 적용	변화
실패율 (http_req_failed)	100.00%	100.00%	동일 (Fail-Fast 정상 동작)
평균 응답시간 (avg)	634.58 ms	106.15 ms	−83.3 % 감소
중앙값 (med)	617.33 ms	2.75 ms	−99.6 % 감소
95퍼센타일 (p95)	680.75 ms	19.95 ms	−97.1 % 감소
최대 응답시간 (max)	1.66 s	9.72 s	일시적 지연 존재 (Retry 재시도 영향)
초당 요청 수 (RPS)	42.73 req/s	74.96 req/s	+75.4 % 향상
데이터 송신량 (data_sent)	228 kB (7.2 kB/s)	422 kB (13 kB/s)	시스템 처리량 증가
평균 iteration_duration	1.13 s	0.607 s	−46.9 % 단축

표로 정리하면 다음과 같다. Fast-Fail 전략의 영향으로 요청이 지연되지 않고 즉시 실패 응답을 반환하여, 도입 전보다 시스템 효율이 향상되었다. 다만 서킷브레이커는 임계값 설정이 적절하지 않을 경우 오히려 역효과를 초래할 수 있으므로 신중한 설계가 필요하다.

[맞춤형 헤어 컨설팅 예약] 동시성 충돌 연구해보기

seung_ho_choi.s — Fri, 10 Oct 2025 18:25:00 +0900

https://balhae.tistory.com/252

2025 블레이버스 MVP 개발 해커톤 대회 테크 인사이트상 수상 후기

balhae.tistory.com

이번 연휴에는 평소에 미뤄뒀던 주제들을 하나씩 정리해보려 한다.
그중 첫 번째로 동시성 충돌(concurrency issue) 에 대해 깊이 다뤄볼 예정이다.

당시 해커톤 프로젝트에서는 예약시스템이 있어서 sychronized 키워드를 사용해 스레드 간 동시성 문제를 제어했다.

하지만 시간이 지나면서 공정성(fairness) 문제와 무한 대기(deadlock) 가능성이 드러나,

보다 세밀한 제어가 가능한 ReentrantLock 으로 개선했다.

이로써 코드 단위의 락 해제와 재진입 제어가 유연해졌고, 상황에 따라 타임아웃 설정이나 공정 모드 적용도 가능해졌다.

그러나 여기서 한 가지 중요한 점을 놓치고 있었다. 바로 서버가 로드밸런싱 환경에서 3대의 인스턴스로 동작하고 있었다는 것이다.

즉, JVM 수준에서의 락(synchronized, ReentrantLock)은 인스턴스 간에 공유되지 않기 때문에,

멀티 인스턴스 환경에서는 여전히 동시성 충돌이 완전히 해결되지 않는다.

그래서 이번 실험에서는

ReentrantLock (단일 JVM 기반 락)
비관적 락(Pessimistic Lock, DB 수준 락)
Redis 분산락 (Redisson 기반, 다중 인스턴스 환경 대응)

이 세 가지 방법을 적용해보고, 각각의 처리 성능, 락 경쟁 상황, 대기 시간 등을 비교 분석해볼 예정이다.

기술 도입

낙관적 락도 존재하지만, 동시에 동일 자원에 접근하는 상황이 빈번하게 발생하는 경우에는 비관적 락을 사용하는 것이 더 적절하다.

예를 들어, 항공권 예약이나 영화관 예매처럼 비교적 여유 있는 시스템에서는 낙관적 락을 사용해도 문제가 없지만,
티켓팅이나 미용실 예약처럼 동일한 시간대에 단 한 명만 예약이 가능하고 요청이 동시에 몰리는 환경에서는 비관적 락이 더 안전하다.

낙관적 락 (Optimistic Lock)

낙관적 락은 충돌이 거의 없을 것이라고 가정하고, 자원에 접근할 때 잠금을 걸지 않는다.
마치 회의실 예약표를 미리 잠그지 않고 작성한 뒤, 나중에 제출할 때 겹치면 다시 써야 하는 방식과 같다.

이 방식은 트래픽이 적을 때는 효율적이지만,
여러 사용자가 동시에 같은 자원을 수정하려 할 경우 충돌 후 재시도와 롤백이 반복되어 성능 저하가 발생할 수 있다.

비관적 락 (Pessimistic Lock)

반면, 비관적 락은 충돌이 발생할 가능성이 높다고 가정한다.
자원에 접근하는 순간 잠금을 걸어 다른 사용자의 접근을 차단하는데,
이는 회의실 예약표를 직접 들고 가서 다른 사람이 볼 수 없게 하는 방식과 비슷하다.

이 방식은 데이터 정합성을 확실히 보장할 수 있지만,
한 사용자가 락을 잡고 있는 동안 다른 요청이 대기 상태로 전환되어 응답 지연이 발생할 수 있다.

따라서 어느 방식이 "정답"이라고 단정하기는 어렵다.
다만 이번 테스트에서는 DB 수준에서의 락 동작을 직접 확인하기 위해 비관적 락을 적용하여 실험을 진행했다.

확장 환경에서의 한계와 Redis 분산 락 도입

한편, 단일 DB 환경에서는 비관적 락만으로도 충분하지만,
DB가 여러 대로 확장된 분산 환경에서는 각 서버의 DB 연결 세션이 분리되어 있어 서버 간 락 공유가 불가능하다.

이를 해결하기 위해 Redis 기반의 분산 락(Redis Distributed Lock)을 도입했다.

Redis 분산 락은 건물 전체의 회의실 예약표를 중앙 관리실에서 통합 관리하는 방식과 유사하다.
여러 서버가 동시에 동일 자원에 접근하더라도, 중앙의 Redis가 “누가 먼저 예약했는지”를 관리하여
단 하나의 요청만 자원을 점유하도록 보장한다.

⚙️ Redis 분산 락의 특성과 트레이드오프

하지만 이 과정에서 각 서버가 Redis 서버와 통신해야 하므로,
락의 획득·해제 과정마다 네트워크 왕복(Round Trip)이 발생한다.
또한 SETNX, PEXPIRE, DEL 등의 명령을 통해 락이 관리되기 때문에
비관적 락보다 평균 응답 시간이 길어지는 단점이 존재한다.

결국, Redis 분산 락은 속도보다는 전역 일관성을 보장하는 데 초점을 맞춘 방식이라고 할 수 있다.

단일 서버

import http from 'k6/http';
import { check, sleep } from 'k6';

// 테스트 옵션 설정
export const options = {
    vus: 50,                // 가상 사용자 50명
    duration: '30s',        // 테스트 지속 시간 30초
    thresholds: {
        http_req_failed: ['rate<0.05'],   // 실패율 5% 이하
        http_req_duration: ['p(95)<500'], // 95% 요청이 500ms 이하
    },
};

// 테스트 대상 URL
const BASE_URL = 'http://localhost:8080/api/consulting';

// 공통 헤더
const params = {
    headers: {
        'Content-Type': 'application/json',
    },
};

export default function () {
    // 각 가상 사용자별로 userId 2~51 부여
    const userId = (__VU + 1).toString();

    // 요청 바디
    const payload = JSON.stringify({
        designerId: "uuid01",
        meet: "offline",
        pay: "카카오페이",
        startTime: "2025-10-09T15:30:00",
        userId: userId
    });

    // POST 요청
    const res = http.post(BASE_URL, payload, params);

    // 응답 검증
    check(res, {
        'status was 200': (r) => r.status === 200,
        'response time < 500ms': (r) => r.timings.duration < 500,
    });

    sleep(0.1); // 사용자 간 약간의 간격
}

단일 서버에서 테스트를 진행해볼 K6 코드이다.
이 코드를 통해 여러 사용자가 동시에 동일한 API를 호출할 때 발생할 수 있는 동시성 문제(예: 중복 처리, 락 충돌, 트랜잭션 경합 등)를 시뮬레이션 형태로 검증할 수 있다.

다만, K6은 서버 외부에서 부하를 발생시키는 도구이므로, 동시성의 내부 원인(스레드, 락, 트랜잭션 경합) 은 별도의 로그나 모니터링 도구를 통해 분석해야 한다.

ReentrantLock

@Component
public class ReentrantLockManager {

    private final ConcurrentHashMap<String, ReentrantLock> lockMap = new ConcurrentHashMap<>();
    private final ConcurrentHashMap<String, Boolean> reservedMap = new ConcurrentHashMap<>();

    public ReentrantLock getLock(String designerId, LocalDateTime startTime) {
        String lockKey = createKey(designerId, startTime);
        return lockMap.computeIfAbsent(lockKey, key -> new ReentrantLock(true));
    }

    public boolean isReserved(String designerId, LocalDateTime startTime) {
        String lockKey = createKey(designerId, startTime);
        return reservedMap.getOrDefault(lockKey, false);
    }

    public void markAsReserved(String designerId, LocalDateTime startTime) {
        String lockKey = createKey(designerId, startTime);
        reservedMap.put(lockKey, true);
    }

    private String createKey(String designerId, LocalDateTime startTime) {
        return designerId + ":" +
                startTime.truncatedTo(ChronoUnit.MINUTES)
                        .format(DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm"));
    }
}

public ConsultingResponseDTO executeV1(ConsultingRequestDTO req, String userId) {

    . . . . 객체 불러오기
    
    ReentrantLock lock = reentrantLockManager.getLock(req.designerId(), req.startTime());
    boolean acquired = false;

    try {
        acquired = lock.tryLock(5, TimeUnit.SECONDS);
        if (!acquired) {
            throw new BlaybusException(HttpStatus.CONFLICT, "현재 예약 요청이 많습니다. 잠시 후 다시 시도해주세요.");
        }

        // 락 안에서 메모리 캐시로 중복 체크
        if (reentrantLockManager.isReserved(req.designerId(), req.startTime())) {
            throw new BlaybusException(HttpStatus.CONFLICT, "이미 해당 시간에 예약 시간이 존재합니다.");
        }

        // DB에서도 한 번 더 체크 (혹시 모를 경우 대비)
        if (consultingRepository.existsByDesignerAndStartTime(designer, req.startTime())) {
            throw new BlaybusException(HttpStatus.CONFLICT, "이미 해당 시간에 예약 시간이 존재합니다.");
        }

        	. . . . . . . 저장 로직

        return ConsultingResponseDTO.from(consulting);
        
        // 저장 성공 후 메모리에 마킹
        reentrantLockManager.markReserved(req.designerId(), req.startTime());

    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        throw new BlaybusException(HttpStatus.INTERNAL_SERVER_ERROR, "락 획득 중 인터럽트 발생");
    } finally {
        if (acquired) {
            lock.unlock();
        }
    }
}

여기서 락은 finally 블록에서 즉시 해제되지만, 실제 DB 커밋은 @Transactional 메서드가 완전히 종료된 뒤에 이루어진다.

즉, 락이 풀린 순간 다른 스레드가 같은 자원에 대한 락을 획득해 DB에 접근할 수 있는 여지가 생긴다는 뜻이다.

이러한 타이밍 이슈를 방지하기 위해, 락 해제 직전에 메모리 캐시에 예약 상태를 미리 반영하여 다른 스레드가 동일한 시간대에 접근하지 못하도록 한 것이다.

비관적 락

@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("SELECT c FROM Consulting c WHERE c.designer = :designer AND c.startTime = :startTime")
Optional<Consulting> findWithPessimisticLock(@Param("designer") Designer designer,
                                             @Param("startTime") LocalDateTime startTime);

public ConsultingResponseDTO executeV2(ConsultingRequestDTO req, String userId) {
  
    . . . . 객체 불러오기

    // 동일 (designer, startTime) 조합에 대해 DB가 직접 Lock 잡음
    boolean exists = consultingRepository.findWithPessimisticLock(designer, req.startTime()).isPresent();
    if (exists) {
        throw new BlaybusException(HttpStatus.CONFLICT, "이미 해당 시간에 예약 시간이 존재합니다.");
    }
  
  			. . . . . . . 저장 되는 코드
  
   return new ConsultingResponseDTO(
                consulting.getId(),
                consulting.getUser().getId(),
                consulting.getDesigner().getId(),
                consulting.getMeeting(),
                type,
                ConsultingStatus.fromString(status),
                consulting.getPay(),
                consulting.getStartTime()
        );
    }

DB 수준에서 미리 락을 걸어, 동시에 접근하는 다른 트랜잭션을 사전에 차단하였다.

Redis 분산락

 public ConsultingResponseDTO execute(ConsultingRequestDTO req, String userId) {

      	. . . . 객체 불러오기 
        
        String normalizedTime = req.startTime()
                .truncatedTo(ChronoUnit.MINUTES)
                .format(DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm"));

        String lockKey = "lock:consulting:" + req.designerId() + ":" + normalizedTime;
        String reservedKey = "reserved:consulting:" + req.designerId() + ":" + normalizedTime;

        RLock lock = redissonClient.getLock(lockKey);

        boolean isLocked = false;
        try {
            // waitTime=5s, leaseTime=10s
            isLocked = lock.tryLock(5, 10, TimeUnit.SECONDS);
            if (!isLocked) {
                throw new BlaybusException(HttpStatus.CONFLICT, "현재 예약 요청이 많습니다. 잠시 후 다시 시도해주세요.");
            }

            // Redis 캐시에서 먼저 체크
            RBucket<String> reservedBucket = redissonClient.getBucket(reservedKey);
            if (reservedBucket.isExists()) {
                throw new BlaybusException(HttpStatus.CONFLICT, "이미 해당 시간에 예약 시간이 존재합니다.");
            }

            // DB에서도 체크
            if (consultingRepository.existsByDesignerAndStartTime(designer, req.startTime())) {
                throw new BlaybusException(HttpStatus.CONFLICT, "이미 해당 시간에 예약 시간이 존재합니다.");
            }

            . . . . . . . 저장되는 코드

            // Redis에 예약 완료 마킹 (TTL 1시간)
            reservedBucket.set("reserved", 1, TimeUnit.HOURS);

            return new ConsultingResponseDTO(
                    consulting.getId(),
                    consulting.getUser().getId(),
                    consulting.getDesigner().getId(),
                    consulting.getMeeting(),
                    type,
                    ConsultingStatus.fromString(status),
                    consulting.getPay(),
                    consulting.getStartTime()
            );

        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            throw new BlaybusException(HttpStatus.INTERNAL_SERVER_ERROR, "락 획득 중 인터럽트 발생");
        } finally {
            if (isLocked && lock.isHeldByCurrentThread()) {
                lock.unlock();
            }
        }
    }

앞서 명시적 락을 사용한 경우와 동일한 상황이다. 이쪽 역시 별도의 캐시를 두어 예약 상태를 관리하였다.

예약 완료 마킹을 1시간으로 설정한 이유는,
해당 시간대의 예약이 끝난 이후에는 동일한 시간 슬롯에 대한 중복 요청이 더 이상 의미가 없기 때문이다.

즉, 예약 시작 시점부터 1시간이 지나면 자연스럽게 해당 시간대의 예약 가능 여부가 초기화되도록 하여,
불필요한 캐시 데이터가 오래 남지 않게 하고 메모리 효율성을 유지하기 위함이다.

앞서 코드를 기반으로 K6 부하 테스트를 진행했다.

단순히 테스트 코드로 검증할 수도 있었지만, 응답 지연(ms) 을 함께 확인하기 위해 K6를 활용했다.
왼쪽부터 순서대로 ReentrantLock, 비관적 락, Redis 분산 락 결과이다.

구분	락 종류	평균 응답 시간	최대 응답 시간	95% 응답 시간	요청 수	HTTP 실패율	동시성 관점 분석
①	ReentrantLock (JVM 내부 락)	9.11 ms	565.87 ms	12.32 ms	≈ 455 req/s	99.99 %	단일 인스턴스 내에서만 동기화되므로 처리 속도는 빠르지만, 외부 요청 충돌 시 일부 스레드가 락을 획득하지 못해 요청 실패율이 매우 높음. 서버 내부에서는 동시성 제어가 잘 되지만, 분산 환경에는 부적합.
②	비관적 락 (Pessimistic Lock / DB 레벨)	11.36 ms	322.23 ms	17.2 ms	≈ 443 req/s	99.99 %	트랜잭션 단위의 DB 락으로 인해 정합성은 확보되지만, 동시에 다수의 요청이 들어오면 DB 락 대기로 인해 응답이 지연됨. 락 경합이 심화될수록 병목 발생. 즉 시스템 전체 성능 마비로 이어짐.
③	Redis 분산 락 (Redisson)	105.07 ms	594.73 ms	259.48 ms	≈ 242 req/s	99.98 %	네트워크 기반 분산 락으로 인해 응답 시간이 크게 증가했으며, 락 획득·해제 과정의 네트워크 오버헤드가 명확히 드러남. 그러나 여러 인스턴스 간의 일관성 유지에는 가장 적합함.

표를 정리하면 위와 같다.

단일 서버 환경에서 테스트를 진행했기 때문에, 모든 경우에서 성공은 1건, 나머지는 모두 실패한 것은 당연한 결과다.

또한 Redis의 응답 지연 시간이 가장 긴 이유 역시 네트워크를 통한 통신이 필요하기 때문이다.

표만 놓고 보면, 비관적 락과 ReentrantLock 모두 안정적으로 동작한 것으로 보인다.

다중 서버

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
    vus: 50,
    duration: '30s',
    thresholds: {
        http_req_failed: ['rate<0.05'],
        http_req_duration: ['p(95)<5000'],
    },
};

// 공통 헤더
const params = {
    headers: {
        'Content-Type': 'application/json',
    },
};

const ports = [8080, 8081, 8082];

export default function () {
    // 매 요청마다 랜덤 포트 선택
    const port = ports[Math.floor(Math.random() * ports.length)];
    const BASE_URL = `http://localhost:${port}/api/consulting/create`;

    const userId = (__VU + 1).toString();

    const payload = JSON.stringify({
        designerId: "uuid01",
        meet: "offline",
        pay: "카카오페이",
        startTime: "2025-10-09T15:30:00",
        userId: userId
    });

    const res = http.post(BASE_URL, payload, params);

    check(res, {
        'status was 200': (r) => r.status === 200,
        'response time < 5000ms': (r) => r.timings.duration < 5000,
    });

    sleep(0.1);
}

요청 시 포트 번호를 랜덤하게 선택하도록 구성하여, 여러 인스턴스에 분산되도록 설정했다.

# ================================
# Blaybus 다중 인스턴스 실행 스크립트
# ================================

# 프로젝트 루트 경로
$PROJECT_ROOT = "C:\Users\chltm\Github\Blaybus-Haertz-Server"

# JAR 파일 경로
$JAR_PATH = "$PROJECT_ROOT\build\libs\Blaybus-0.0.1-SNAPSHOT.jar"

# 환경변수 파일 경로
$ENV_PATH = "$PROJECT_ROOT\env\prod.env"

# 복사 대상 경로 (JAR 실행 위치)
$TARGET_ENV_DIR = "$PROJECT_ROOT\build\libs\env"

# env 폴더가 없으면 생성하고 prod.env 복사
if (-Not (Test-Path $TARGET_ENV_DIR)) {
    New-Item -ItemType Directory -Path $TARGET_ENV_DIR | Out-Null
    Copy-Item $ENV_PATH -Destination $TARGET_ENV_DIR
    Write-Host "env/prod.env 복사 완료"
}

# 실행 포트 목록
$ports = @(8080, 8081, 8082)

foreach ($port in $ports) {
    Write-Host "  포트 $port 인스턴스 실행 중..."
    Start-Process powershell -ArgumentList "-NoExit", "-Command", "cd '$($PROJECT_ROOT)\build\libs'; java -jar Blaybus-0.0.1-SNAPSHOT.jar --server.port=$port"
    Start-Sleep -Seconds 2
}

Write-Host ""
Write-Host "=========================================="
Write-Host "모든 인스턴스 실행 완료!"
Write-Host "8080 / 8081 / 8082 포트에서 서버 확인 가능"
Write-Host "=========================================="

위와 같이 .ps1 스크립트 파일을 작성해, 여러 인스턴스를 동시에 실행하도록 설정했다.

진행한 결과다. 순서도 아까랑 동일하다.

구분	락 종류	평균 응답 시간	최대 응답 시간	95% 응답시간	요청 수	실패율	생성 결과
①	ReentrantLock(JVM 내부 락)	13.26 ms	1.09 s	20.62 ms	≈ 438 req/s	99.97%	✅ 3건 생성
②	비관적 락(DB 기반)	19.2 ms	1.05 s	53.87 ms	≈ 415 req/s	99.99%	✅ 1건 생성
③	Redis 분산 락(Redisson)	87.38 ms	1.17 s	331.9 ms	≈ 265 req/s	99.98%	✅ 1건 생성

정리하면 위 표와 같다.

다중 서버 환경으로 설정하니 응답 시간이 확연히 감소했다.
특히 ReentrantLock의 경우 총 3건이 생성되었는데, 직접 테스트해보며 JVM 수준의 락으로는 다중 서버 간 동시 접근을 막을 수 없다는 점을 확인할 수 있었다.

반면 비관적 락과 Redis 분산 락은 모두 1건으로 동일한 결과를 보였으며,
단 비관적 락은 DB 인스턴스가 3대라면 각각에서 동일하게 3건이 생성될 가능성이 있다.

무엇보다 비관적 락(Pessimistic Lock) 은 대용량 트래픽 환경에서 DB 커넥션 고갈을 유발해 시스템 전체를 마비시킬 수 있으며, 동시에 데드락(Deadlock) 이 발생할 위험도 존재한다.

비관적 락은 일종의 “회의실 문을 잠그고 들어가는 방식”으로,
예를 들어 너는 회의실 A를 점유 중이고 나는 회의실 B를 점유 중인데,
서로 상대방 방의 열쇠가 필요하다면 둘 다 움직이지 못한 채 대기하게 된다.
이것이 바로 데드락이다.

반면 낙관적 락(Optimistic Lock) 은 회의실 문을 잠그지 않고, 나중에 겹쳤는지만 확인하는 방식이다.
따라서 충돌이 발생해도 단순히 “다시 예약해” 하고 끝나므로 대기나 데드락이 발생하지 않는다.
다만 대규모 요청이 동시에 몰리는 상황에서는 충돌 후 재시도 횟수가 폭증해 시스템 부하로 이어질 수 있다.

이러한 이유로, Redis 분산락은 DB 트랜잭션과 별개로 애플리케이션 레벨에서 락을 관리하기 때문에
DB 커넥션을 점유하지 않으면서도 자원 접근 순서를 제어할 수 있다.
즉, 비관적 락의 병목과 데드락 문제를 완화하고,
낙관적 락의 과도한 재시도 문제도 방지할 수 있는 균형 잡힌 락 제어 방식이다.

최종

이번 테스트를 통해 얻은 인사이트들은 단순한 성능 비교를 넘어,
실제 서비스 환경에서 발생할 수 있는 동시성 문제의 본질을 깊이 이해하는 계기가 되었다.
이 경험을 바탕으로, 새로운 사이드 프로젝트에서는 더 안정적이고 확장 가능한 구조를 설계하고자 한다.
나아가, 현장에서 마주칠 수 있는 다양한 문제 상황을 직접 연구하고 개선하는 개발자로 성장하고 싶다.

[9oormthon 제주 버스 알림콜] 리메이크 및 조회 성능 최적화 하기

seung_ho_choi.s — Thu, 9 Oct 2025 00:02:30 +0900

https://balhae.tistory.com/219

구름톤(9oormthon) 11기 대상 후기

지원 동기와 과정대학교 4학년, 졸업을 앞둔 시점에서 문득 돌아보니 지금까지 만든 프로젝트들이 너무 의미없게 느껴졌습니다. 진짜 의미있는 무언가를 만들어보고 싶다는 생각이 들었고,

balhae.tistory.com

이번 연휴 10일 동안은 작년 11월에 참여했던 9oormthon 제주 버스 알림콜 프로젝트를 다시 리메이크하기로 했다.

리메이크를 결심한 이유는, 당시에는 백엔드 개발 역량이 아직 미숙해서 아쉬운 점이 많았기 때문이다.
이번에는 그때의 부족함을 보완하고, 특히 조회 성능 최적화에 집중해 학습해볼 예정이다.

프로젝트 리펙터링

왼쪽은 리팩터링 이전, 오른쪽은 리팩터링 이후의 모습이다.

이전 코드에서는 전반적으로 구조가 복잡하고 일관성이 부족했지만,
리팩터링 후에는 코드의 가독성과 유지보수성이 한층 향상되었다.

프로젝트 구조

확실히 훨씬 깔끔해졌다.
이전에는 구조가 제대로 잡혀 있지 않아, 코드 흐름을 따라가기가 너무 헷갈렸다.
이번에 DDD 도메인 구조를 적용하면서 역할이 명확해지고, 유지보수도 훨씬 수월해졌다.

DB 테이블

이전에는 엔티티와 컬럼 이름이 제각각이라 일관성이 없었고,
Note 엔티티에는 정규화가 제대로 이루어지지 않아 한 엔티티가 너무 많은 역할을 맡고 있었다.

그래서 이번 리팩터링에서는 Note 엔티티를 BusLog로 변경하고,
알림(BusAlarm)과 즐겨찾기(BusFavorite) 기능은 별도의 엔티티로 분리해 관리하도록 했다.

또한 Member 테이블에는 컬럼이 너무 적어서, 최소한의 정보라도 담기 위해 name 컬럼을 추가했다

코드 구조

이전에는 코드 스타일이 정말 극악이었다…
지금 다시 보니까, 그때는 진짜 내가 얼마나 미숙했는지 느껴진다...

이걸 리팩터링하는 데만 3일이 걸렸으니 말 다 했다.

거의 전부 새로 짰다고 봐도 무방하다.

그래서 여기서는 대표적으로 버스 관련 컨트롤러와 서비스 로직만 가져와서
리팩터링 전후를 비교해보려 한다.

<리펙터링 전>

@RestController
@RequiredArgsConstructor
@Tag(name = "사용자의 버스 기록 정보")
@RequestMapping("/api/bus")
@Slf4j
public class NoteController {

    private final NoteService noteService;

    private final StationService stationService;

    private final NoteRepository noteRepository;

    @GetMapping("/list")
    @Operation(summary = "즐겨찾기 버스 기록 저장 보여주기")
    public SuccessResponse<ListResult<NoteResponse>> readAll(@RequestAttribute("id") String userId) {
        ListResult<NoteResponse> note = noteService.findAll(userId);
        return SuccessResponse.ok(note);
    }



    @PostMapping("/save")
    @Operation(summary = "버스 데이터 정보들이 쭉 넘어옴 여기서 전화 콜 및 일시 저장해줘야됨 즉 즐격찾기 false")
    public SuccessResponse<NoteSaveResponse> create(@Valid
                                                          @RequestAttribute("id") String userId,
                                                    @RequestBody NoteRequest req
    ) {
        SingleResult<Note> note = noteService.save(req,userId);



        String stationId = req.stationId();
        int station = req.station();
        String busId =req.notionId();
        // 5초마다 API 호출 시작
        stationService.scheduleBusApiCall(userId,busId, stationId,station);

        // Note 객체를 NoteSaveResponse로 변환
        NoteSaveResponse response = NoteSaveResponse.of(note.getData());

        // 변환된 NoteSaveResponse를 응답으로 반환
        return SuccessResponse.ok(response);
        // 즉시 note 객체 응답 반환
    }


    @PostMapping("/favorite")
    @Operation(summary = "즐겨 찾기 API")
    public ResponseEntity<String> delete(@Valid @RequestBody NoteFavoriteRequest req){
        Optional<Note> findNote =noteRepository.findById(req.id());
        if (findNote.isPresent()) {
            Note note = findNote.get();
            if(req.favorite()){
                noteRepository.updelete(req,2);
            }else{
                if(note.getFavorite_pre()!=1){
                    noteRepository.delete(req);
                }
            }

        } else {
            // 값이 없을 때의 처리 로직
            throw new NoSuchElementException("해당하는 사용자가 없습니다.");
        }



        // 즉시 응답 반환
        return ResponseEntity.ok("설정 완료");
    }

컨트롤러에 서비스 로직이 섞여 있고… 진짜 최악이었다.
그때는 레이어드 아키텍처 개념도 제대로 잡혀 있지 않아서,
비즈니스 로직이 컨트롤러 안에 뒤섞여 있었다.

게다가 커스텀 응답 방식도 제각각이라 일관성이 없었고,

SpringSecurityConfig 역시 구조가 정리되어 있지 않아 여러모로 불완전한 코드였다.

@Service
@EnableScheduling
@Slf4j
@RequiredArgsConstructor
public class StationService {
    private final MemberRepository memberRepository;

    private final RestTemplate restTemplate = new RestTemplate();

    // 사용자별 상태를 저장하기 위한 Map
    private final Map<String, String> userBusIdMap = new ConcurrentHashMap<>();
    private final Map<String, String> userStationIdMap = new ConcurrentHashMap<>();
    private final Map<String, Integer> userStationMap = new ConcurrentHashMap<>();
    private final Map<String, Boolean> userStopCallingMap = new ConcurrentHashMap<>();
    private final Map<String, AtomicInteger> userCntMap = new ConcurrentHashMap<>();
    private final Map<String, Set<Integer>> userSeenBusesMap = new ConcurrentHashMap<>();
    private static final long RUNNING_DURATION_HOURS = 3; // 3시간
    private final LocalDateTime startTime = LocalDateTime.now();

    @Value("${twilio.account-sid}")
    private String accountSid;

    @Value("${twilio.auth-token}")
    private String authToken;

    // 사용자별 API 호출 상태 설정 메서드
    @Async
    public void scheduleBusApiCall(String userId, String busId, String stationId, int station) {
        userBusIdMap.put(userId, busId);
        userStationIdMap.put(userId, stationId);
        userStationMap.put(userId, station);
        userStopCallingMap.put(userId, false);  // 호출 중단 플래그 초기화
        userSeenBusesMap.put(userId, new HashSet<>());  // 중복 체크 목록 초기화
        userCntMap.put(userId, new AtomicInteger(0));  // 카운터 초기화
    }

    // 5초마다 실행되는 메서드 - 사용자별로 독립적으로 동작
    @Scheduled(fixedRate = 5000)
    public void callBusApi() {
        // 현재 시간이 시작 시간으로부터 3시간 경과했는지 확인
        if (ChronoUnit.HOURS.between(startTime, LocalDateTime.now()) >= RUNNING_DURATION_HOURS) {
            log.info("3시간이 경과하여 스케줄링을 중단합니다.");
            return;  // 스케줄링 중단
        }

        userStationIdMap.forEach((userId, stationId) -> {
            String busId = userBusIdMap.get(userId);
            Integer station = userStationMap.get(userId);
            Boolean stopCalling = userStopCallingMap.getOrDefault(userId, true);
            AtomicInteger cnt = userCntMap.getOrDefault(userId, new AtomicInteger(0));
            Set<Integer> seenBuses = userSeenBusesMap.getOrDefault(userId, new HashSet<>());

            if (stationId != null && !stopCalling) {
                String url = "https://bus.jeju.go.kr/api/searchArrivalInfoList.do?station_id=" + stationId;
                ResponseEntity<BusInfo[]> response = restTemplate.getForEntity(url, BusInfo[].class);
                BusInfo[] buses = response.getBody();
                log.info("Twilio Account SID: {}", accountSid);
                log.info("Twilio Auth Token: {}", authToken);

                if (buses != null) {
                    log.info("API 응답 데이터: {}", Arrays.toString(buses));
                    log.info("현재 {} 사용자의 cnt 값: {}", userId, cnt);

                    Arrays.stream(buses)
                            .filter(bus -> busId.equals(bus.getRouteNum()) && bus.getRemainStation() == station)
                            .forEach(bus -> {
                                if (!seenBuses.contains(bus.getVhId())) {
                                    log.info("{} 사용자에게 조건을 만족하는 새로운 버스를 찾았습니다: {}", userId, bus);
                                    seenBuses.add(bus.getVhId());
                                    cnt.incrementAndGet();  // 새로운 버스일 경우 카운터 증가
                                    userCntMap.put(userId, cnt);
                                    log.info("현재 {} 사용자의 cnt 값: {}", userId, cnt);
                                    Optional<Member> byPhone = memberRepository.findByPhone2(userId);
                                    if (byPhone.isPresent()) {
                                        Member member = byPhone.get();
                                        bus_call(member);
                                        // member에 대한 로직 처리
                                    } else {
                                        // 값이 없을 때의 처리 로직
                                        throw new NoSuchElementException("해당하는 사용자가 없습니다.");
                                    }

                                    if (cnt.get() >= 2) {
                                        log.info("{} 사용자의 cnt가 2에 도달하여 호출을 중단합니다.", userId);
                                        userStopCallingMap.put(userId, true);
                                    }
                                } else {
                                    log.info("{} 사용자는 이미 확인된 버스입니다: {}", userId, bus.getVhId());
                                }
                            });

                    if (cnt.get() < 2) {
                        log.info("{} 사용자에게 조건을 만족하는 새로운 버스를 찾지 못했습니다.", userId);
                    }
                } else {
                    log.warn("API 응답에서 버스 데이터가 비어 있습니다.");
                }

                // 상태 업데이트
                userSeenBusesMap.put(userId, seenBuses);
                userCntMap.put(userId, cnt);
            }
        });
    }

    private void bus_call(Member member) {
        Twilio.init(accountSid, authToken);
        log.info("버스 콜 실행");
        String phone = member.getPhone();
        String substring = phone.substring(1);
        String from = "+16232992975";
        String to = "+82" + substring;
        log.info(to);

        // 사용자에게 전달할 음성 메시지 작성
        Say say = new Say.Builder("안녕하세요, 이것은 당신을 위한 음성 메시지입니다.")
                .language(Say.Language.KO_KR)
                .voice(Say.Voice.ALICE)
                .build();

        VoiceResponse response = new VoiceResponse.Builder()
                .say(say)
                .build();

        // VoiceResponse를 XML 문자열로 변환
        String twiml = response.toXml();

        // TwiML XML 문자열을 Twiml 객체로 감싸기
        com.twilio.type.Twiml twimlObject = new com.twilio.type.Twiml(twiml);

        // Twiml 객체를 사용하여 전화 걸기
        Call call = Call.creator(
                new com.twilio.type.PhoneNumber(to),
                new com.twilio.type.PhoneNumber(from),
                twimlObject
        ).create();

        log.info("Twilio Call SID: {}", call.getSid());
    }



}

// BusInfo 클래스는 API 응답에 맞게 필드 정의
class BusInfo {

    @JsonProperty("ARRV_STATION_ID")
    private int arrvStationId;

    @JsonProperty("ROUTE_SUB_NM")
    private String routeSubNm;

    @JsonProperty("VH_ID")
    private int vhId;

    @JsonProperty("ROUTE_ID")
    private int routeId;

    @JsonProperty("ROUTE_NUM")
    private String routeNum;

    @JsonProperty("PLATE_NO")
    private String plateNo;

    @JsonProperty("CURR_STATION_ID")
    private int currStationId;

    @JsonProperty("PREDICT_TRAV_TM")
    private int predictTravTm;

    @JsonProperty("REMAIN_STATION")
    private int remainStation;

    @JsonProperty("CURR_STATION_NM")
    private String currStationNm;

    @JsonProperty("LOW_PLATE_TP")
    private String lowPlateTp;

    // Getters and Setters
    public int getVhId() {
        return vhId;
    }

    public String getRouteNum() {
        return routeNum;
    }

    public int getRemainStation() {
        return remainStation;
    }

    @Override
    public String toString() {
        return "ROUTE_NUM=" + routeNum + ", REMAIN_STATION=" + remainStation;
    }
}

와… 진짜 최악 중의 최악이다.
지금 보면 딱 “비전공자가 ChatGPT 코드 베껴서 붙인 것 같은” 느낌이다.

인터페이스도 없고, 모듈화도 안 되어 있고, 주석도 엉망이다.
그냥 전부 다 뒤섞여 있는 짬뽕 코드 그 자체였다.

아무리 해커톤이라 급하게 만들었다고 해도, 이건 진짜 너무 했다 싶다.
그때는 돌아볼 여유도 없었지만, 지금 보니까 구조부터 완전 잘못된 설계였다.

<리펙터링 후>

@RestController
@RequiredArgsConstructor
@Tag(name = "사용자의 버스 기록 정보", description = "버스 로그, 즐겨찾기 관련 API")
@RequestMapping("/api/bus")
@Slf4j
public class BusLogController {

    private final BusLogService busLogService;

    /**
     * 버스 로그 저장 API
     * - 사용자 요청 시 새로운 버스 로그를 저장함
     * - 즐겨찾기는 기본적으로 false로 설정
     */
    @Operation(summary = "버스 로그 저장", description = "버스 데이터 정보를 저장합니다. (즐겨찾기 기본값 false)")
    @ApiResponses(value = {
            @ApiResponse(responseCode = "200", description = "버스 로그 저장 성공"),
            @ApiResponse(responseCode = "400", description = "요청 데이터가 유효하지 않음"),
            @ApiResponse(responseCode = "404", description = "사용자를 찾을 수 없음"),
            @ApiResponse(responseCode = "500", description = "서버 내부 오류")
    })
    @PostMapping
    public ResponseEntity<Void> saveBusLog(@Valid @RequestBody BusLogSaveReq req,
                                           @AuthenticationPrincipal String userId) {
        busLogService.postBusLogSave(req, userId);
        return ResponseEntity.ok().build();
    }

    /**
     * 버스 로그 전체 조회 API
     * - 사용자의 모든 버스 로그를 조회
     * - 각 로그마다 알림 여부, 즐겨찾기 여부 포함
     */
    @Operation(summary = "버스 로그 전체 조회", description = "사용자의 모든 버스 기록을 조회합니다. (알림 여부, 즐겨찾기 여부 포함)")
    @ApiResponses(value = {
            @ApiResponse(responseCode = "200", description = "버스 로그 조회 성공"),
            @ApiResponse(responseCode = "404", description = "사용자 또는 버스 로그가 존재하지 않음"),
            @ApiResponse(responseCode = "500", description = "서버 내부 오류")
    })
    @GetMapping
    public ResponseEntity<List<BusLogAllRes>> getBusLogAll(@RequestParam String memberId,@AuthenticationPrincipal String userId) {
        return ResponseEntity.ok(busLogService.getBusLogAll(memberId));
    }

    /**
     * 즐겨찾기 상태 토글 API
     * - true ↔ false 상태 전환
     */
    @Operation(summary = "버스 즐겨찾기 상태 변경", description = "해당 버스 로그의 즐겨찾기 상태를 토글합니다. (활성/비활성)")
    @ApiResponses(value = {
            @ApiResponse(responseCode = "200", description = "즐겨찾기 상태 변경 성공"),
            @ApiResponse(responseCode = "400", description = "요청 데이터가 유효하지 않음"),
            @ApiResponse(responseCode = "404", description = "버스 로그 또는 즐겨찾기 정보 없음"),
            @ApiResponse(responseCode = "500", description = "서버 내부 오류")
    })
    @PostMapping("/favorite")
    public ResponseEntity<Void> updateBusFavorite(@Valid @RequestBody BusFavoriteReq req) {
        busLogService.updateBusFavorite(req);
        return ResponseEntity.ok().build();
    }
}

훨씬 깔끔하다!! ✨
이제는 주석도 명확하게 정리되어 있고, Swagger 문서화도 잘 되어 있어서
코드가 한눈에 들어온다.

컨트롤러에는 입출력 로직만 남겨서 역할이 명확해졌고, 서비스 단에서 비즈니스 로직을 깔끔하게 처리하니까
읽기에도, 유지보수하기에도 훨씬 편하다. 이게 바로 내가 원하던 구조다

/**
 *   BusLogServiceImpl
 *
 * <p>버스 이동 기록(BusLog) 및 즐겨찾기, 알림 관련 비즈니스 로직을 담당하는 구현체입니다.</p>
 * <ul>
 *   <li>사용자의 버스 이용 내역 저장</li>
 *   <li>버스 로그 전체 조회 (알림, 즐겨찾기 포함)</li>
 *   <li>즐겨찾기 상태 토글</li>
 * </ul>
 */
@Service
@RequiredArgsConstructor
@Slf4j
@Transactional
public class BusLogServiceImpl implements BusLogService {

    private final BusLogRepository busLogRepository;
    private final BusFavoriteRepository busFavoriteRepository;
    private final BusAlarmRepository busAlarmRepository;
    private final MemberRepository memberRepository;


    /**
     *   버스 로그 저장
     *
     * <p>새로운 버스 이용 로그를 생성 및 저장합니다.
     * 사용자가 존재하지 않으면 예외를 발생시킵니다.</p>
     *
     * <p>기본적으로 생성 시 즐겨찾기는 false, 알림은 별도의 로직에서 관리됩니다.</p>
     *
     * @param req    버스 로그 저장 요청 DTO
     * @param userId 현재 로그인된 사용자 ID
     * @throws GoormBusException 사용자가 존재하지 않을 경우
     */
    @Override
    public void postBusLogSave(BusLogSaveReq req, String userId) {
        Member findMember = memberRepository.findById(userId).orElse(null);
        if (findMember == null)
            throw new GoormBusException(ErrorCode.USER_NOT_EXIST);

        BusLog busLog = BusLog.builder()
                .member(findMember)
                .departure(req.departure())
                .destination(req.destination())
                .station(req.station())
                .notionId(req.notionId())
                .stationId(req.stationId())
                .build();

        BusAlarm busAlarm = BusAlarm.builder()
                .busLog(busLog)
                .build();

        BusFavorite busFavorite = BusFavorite.builder()
                .busLog(busLog)
                .build();
        busLogRepository.save(busLog);
        busFavoriteRepository.save(busFavorite);
        busAlarmRepository.save(busAlarm);
    }

    /**
     *   버스 로그 전체 조회
     *
     * <p>특정 사용자의 모든 버스 로그를 조회합니다.
     * 각 로그마다 알림 활성화 여부 및 즐겨찾기 여부를 함께 반환합니다.</p>
     *
     * <p>사용자 또는 관련 데이터가 없을 경우 예외를 발생시킵니다.</p>
     *
     * @param memberId 사용자 ID
     * @return {@link BusLogAllRes} 리스트
     * @throws GoormBusException 사용자, 알림, 즐겨찾기 데이터가 존재하지 않을 경우
     */
    @Override
    public List<BusLogAllRes> getBusLogAll(String memberId) {
        Member findMember = memberRepository.findById(memberId).orElse(null);
        if (findMember == null)
            throw new GoormBusException(ErrorCode.USER_NOT_EXIST);

        List<BusLogAllRes> result = new ArrayList<>();
        result = selectV2(findMember, result);

        log.info("BusLog 전체 조회 완료: memberId={}, count={}", memberId, result.size());
        return result;
    }

    /**
     * ⭐ 즐겨찾기 상태 변경
     *
     * <p>버스 로그에 연결된 즐겨찾기 상태를 토글(활성/비활성)합니다.
     * 이미 true 상태면 비활성화하고, false면 활성화합니다.</p>
     *
     * @param req 즐겨찾기 상태 변경 요청 DTO
     * @throws GoormBusException 버스 로그 또는 즐겨찾기 정보가 존재하지 않을 경우
     */
    @Override
    public void updateBusFavorite(BusFavoriteReq req) {
        BusLog findBusLog = busLogRepository.findById(req.busLogId()).orElse(null);
        if (findBusLog == null)
            throw new GoormBusException(ErrorCode.BUS_LOG_NOT_EXIST);

        BusFavorite findBusFavorite = busFavoriteRepository.findByBusLog(findBusLog)
                .orElseThrow(() -> new GoormBusException(ErrorCode.BUS_FAVORITE_NOT_EXIST));

        if (findBusFavorite.isFavoriteFlag()) {
            findBusFavorite.deactivateIsFavoriteFlag();
        } else {
            findBusFavorite.activateIsFavoriteFlag();
        }
    }


    private List<BusLogAllRes> selectV1(Member findMember, List<BusLogAllRes> result) {
        List<BusLog> busLogs = busLogRepository.findByMember(findMember);

        for (BusLog busLog : busLogs) {
            BusAlarm findBusAlarm = busAlarmRepository.findByBusLog(busLog)
                    .orElseThrow(() -> new GoormBusException(ErrorCode.BUS_ALARM_NOT_EXIST));

            BusFavorite findBusFavorite = busFavoriteRepository.findByBusLog(busLog)
                    .orElseThrow(() -> new GoormBusException(ErrorCode.BUS_FAVORITE_NOT_EXIST));

            result.add(BusLogAllRes.of(
                    busLog,
                    findBusAlarm.isAlarmFlag(),
                    findBusFavorite.isFavoriteFlag()
            ));
        }

        return result;
    }


    private List<BusLogAllRes> selectV2(Member findMember, List<BusLogAllRes> result) {
        List<BusLog> busLogs = busLogRepository.findAllWithAlarmAndFavorite(findMember);

        return busLogs.stream()
                .map(busLog -> BusLogAllRes.of(
                        busLog,
                        busLog.getBusAlarm().isAlarmFlag(),
                        busLog.getBusFavorite().isFavoriteFlag()
                ))
                .toList();

    }

/**
 *   BusAlarmServiceImpl
 *
 * <p>버스 알림 관련 비즈니스 로직을 구현한 클래스입니다.</p>
 * <ul>
 *   <li>버스 알림 플래그 토글</li>
 *   <li>Twilio API를 이용한 전화 알림 발송</li>
 * </ul>
 */
@Service
@Transactional
@Slf4j
@RequiredArgsConstructor
public class BusAlarmServiceImpl implements BusAlarmService {

    private final BusAlarmRepository busAlarmRepository;
    private final BusLogRepository busLogRepository;

    @Value("${twilio.account-sid}")
    private String accountSid;

    @Value("${twilio.auth-token}")
    private String authToken;

    @Value("${twilio.from-number}")
    private String fromNumber;

    /**
     *   버스 알림 상태 토글
     *
     * <p>해당 버스 로그의 알림 상태를 활성화 ↔ 비활성화로 전환합니다.</p>
     *
     * @param req 알림 상태 변경 요청 DTO
     * @throws GoormBusException 버스 로그 또는 알림 정보가 존재하지 않을 경우
     */
    @Override
    public void updateBusAlarm(BusAlarmReq req) {
        BusLog findBusLog = busLogRepository.findById(req.busLogId()).orElse(null);
        if (findBusLog == null)
            throw new GoormBusException(ErrorCode.BUS_LOG_NOT_EXIST);

        BusAlarm findBusAlarm = busAlarmRepository.findByBusLog(findBusLog).orElse(null);
        if (findBusAlarm == null)
            throw new GoormBusException(ErrorCode.BUS_ALARM_NOT_EXIST);

        if (findBusAlarm.isAlarmFlag()) {
            findBusAlarm.deactivateIsAlarmFlag();
            log.info("버스 알림 비활성화: busLogId={}", req.busLogId());
        } else {
            findBusAlarm.activateIsAlarmFlag();
            log.info("버스 알림 활성화: busLogId={}", req.busLogId());
        }
    }

    /**
     *   버스 도착 음성 알림 발송
     *
     * <p>Twilio API를 통해 버스 도착 안내 음성 전화를 사용자에게 발송합니다.</p>
     *
     * @param member 알림을 받을 사용자
     * @param busLog 버스 운행 로그
     */
    @Override
    public void sendBusArrivalVoiceNotification(Member member, BusLog busLog) {
        Twilio.init(accountSid, authToken);

        String recipientNumber = formatRecipientPhone(member.getPhone());
        String message = buildArrivalMessage(member, busLog);
        String twimlXml = buildTwimlXml(message);

        makeVoiceCall(recipientNumber, twimlXml);
        log.info("버스 도착 알림 발송 완료: member={}, phone={}", member.getName(), recipientNumber);
    }

    /**
     * ☎ 전화번호를 국제 표준 형태(+82...)로 변환
     *
     * @param phone 사용자 전화번호
     * @return 국제 표준 형태의 전화번호
     * @throws IllegalArgumentException 전화번호 형식이 잘못된 경우
     */
    private String formatRecipientPhone(String phone) {
        if (phone == null || phone.length() < 2) {
            throw new IllegalArgumentException("잘못된 전화번호 형식입니다: " + phone);
        }
        return "+82" + phone.substring(1); // 예: 010 → +8210
    }

    /**
     *   안내 음성 메시지 문자열 생성
     *
     * @param member 사용자 정보
     * @param busLog 버스 운행 로그
     * @return 음성 메시지 내용
     */
    private String buildArrivalMessage(Member member, BusLog busLog) {
        return String.format(
                "안녕하세요, %s님. %s에서 %s로 가는 %s번 버스가 현재 %s 정류장 남았습니다. 서둘러 주세요.",
                member.getName(),
                busLog.getDeparture(),
                busLog.getDestination(),
                busLog.getNotionId(),
                busLog.getStation()
        );
    }

    /**
     *   Twilio용 TwiML XML 생성
     *
     * @param message 음성 안내 문장
     * @return TwiML XML 문자열
     */
    private String buildTwimlXml(String message) {
        Say say = new Say.Builder(message)
                .language(Say.Language.KO_KR)
                .voice(Say.Voice.ALICE)
                .build();

        VoiceResponse response = new VoiceResponse.Builder()
                .say(say)
                .build();

        return response.toXml();
    }

    /**
     *   Twilio API를 통해 실제 전화를 발신
     *
     * @param recipientNumber 수신자 전화번호
     * @param twimlXml Twilio용 XML 메시지
     */
    private void makeVoiceCall(String recipientNumber, String twimlXml) {
        Twiml twiml = new Twiml(twimlXml);
        Call.creator(
                new PhoneNumber(recipientNumber),
                new PhoneNumber(fromNumber),
                twiml
        ).create();
    }

진짜 이전보다 훨씬 깔끔해졌다!!!
모듈화도 잘 되어 있고, 인터페이스도 적절히 활용했으며, 주석 처리도 깔끔해서
이제는 코드를 한눈에 파악하기가 훨씬 쉽다.

물론 아직 더 세분화할 수 있는 부분도 있지만…!
시간상 이번에는 여기까지만 하고, 나중에 다시 다듬어볼 예정이다.

무엇보다 인상 깊었던 건 스케줄러 로직의 개선이다.
이전에는 버스 로그 생성 API가 완료되면 비동기로 스케줄러를 호출하도록 짜놨는데,
지금 보니 왜 그렇게 비효율적인 구조를 만들었는지 모르겠다.

당시엔 스케줄러 코드가 서비스 로직이랑 완전히 뒤섞여 있어서
유지보수가 어렵고, 확장성도 전혀 없었다.

지금은 그 구조를 완전히 개선해서, 스케줄러를 서비스 로직과 분리하고 아래처럼 훨씬 깔끔하고 직관적인 코드로 바꿨다.

/**
 *   StationService
 *
 * <p>버스 도착 정보와 알림 발송을 담당하는 스케줄링 서비스입니다.</p>
 * <ul>
 *   <li>30초마다 버스 도착 여부를 확인하고 음성 알림 발송</li>
 *   <li>24시간이 지난 알림의 잔여 횟수를 자동으로 초기화</li>
 * </ul>
 */
@Service
@EnableScheduling
@Slf4j
@RequiredArgsConstructor
public class StationService {

    private final BusLogRepository busLogRepository;
    private final JejuBusClient jejuBusClient;
    private final BusAlarmRepository busAlarmRepository;
    private final BusAlarmService busAlarmService;

    /**
     *   30초마다 실행되는 버스 도착 알림 스케줄러
     *
     * <p>모든 BusLog를 순회하면서:
     * <ul>
     *     <li>알림이 비활성화된 경우 제외</li>
     *     <li>잔여 알림 횟수가 0인 경우 제외</li>
     *     <li>JejuBus API를 통해 도착 정보를 조회 후,
     *     해당 정류장에 도착한 경우 음성 알림 발송 및 잔여 횟수 차감</li>
     * </ul>
     */
    @Scheduled(fixedRate = 30000)
    public void callBusScheduler() {
        List<BusLog> findBusLogAll = busLogRepository.findAll();
        for (BusLog busLog : findBusLogAll) {
            BusAlarm findBusAlarm = busAlarmRepository.findByBusLog(busLog)
                    .orElseThrow(() -> new GoormBusException(ErrorCode.BUS_ALARM_NOT_EXIST));

            // 비활성화된 알림은 건너뛰기
            if (!findBusAlarm.isAlarmFlag()) continue;

            // 잔여 횟수가 0이면 알림 스킵
            if (findBusAlarm.getAlarmRemaining() == 0L) continue;

            checkBusArrivalAndNotify(busLog, findBusAlarm);
        }
    }

    /**
     * ⏰ 1분마다 실행되는 알림 초기화 스케줄러
     *
     * <p>버스 로그 생성 이후 24시간이 지난 경우,
     * 알림 잔여 횟수를 2로 초기화합니다.</p>
     */
    @Scheduled(fixedRate = 60000)
    public void reactivateBusNotification() {
        List<BusLog> findBusLogAll = busLogRepository.findAll();
        for (BusLog busLog : findBusLogAll) {
            BusAlarm findBusAlarm = busAlarmRepository.findByBusLog(busLog)
                    .orElseThrow(() -> new GoormBusException(ErrorCode.BUS_ALARM_NOT_EXIST));

            LocalDateTime createdAt = findBusAlarm.getCreatedAt();
            LocalDateTime now = LocalDateTime.now();

            // 24시간 이상 경과 확인
            if (Duration.between(createdAt, now).toHours() >= 24) {
                if (findBusAlarm.getAlarmRemaining() < 2) {
                    findBusAlarm.initAlarmRemaining();
                    log.info("버스 알림 잔여 횟수 초기화 완료: busLogId={}", busLog.getId());
                }
            }
        }
    }

    /**
     *   버스 도착 여부 확인 후 알림 발송
     *
     * <p>JejuBus API로 버스 도착 정보를 조회하고,
     * 현재 사용자의 목표 정류장과 일치하면 음성 알림을 발송합니다.</p>
     *
     * @param busLog  버스 운행 로그
     * @param busAlarm 해당 로그의 알림 엔티티
     * @throws GoormBusException 제주 버스 API 응답이 유효하지 않을 경우
     */
    private void checkBusArrivalAndNotify(BusLog busLog, BusAlarm busAlarm) {
        ArrivalResponse response = jejuBusClient.getArrivalInfo(busLog.getStationId());
        if (response == null || response.getResultList() == null)
            throw new GoormBusException(ErrorCode.JEJU_RESPONSE_NOT_EXIST);

        response.getResultList().forEach(arrival -> {
            int remainStation = Integer.parseInt(arrival.getRemainStation());
            int busLogStation = Integer.parseInt(String.valueOf(busLog.getStation()));

            // 현재 정류장 도착 시 알림 발송
            if (remainStation == busLogStation) {
                busAlarm.minusAlarmRemaining(); // 잔여 횟수 -1 감소
                busAlarmService.sendBusArrivalVoiceNotification(busLog.getMember(), busLog);
                log.info("버스 도착 알림 발송 완료: busLogId={}, member={}", busLog.getId(), busLog.getMember().getName());
            }
        });
    }
}

전체적으로 보면 이번 리팩터링은 단순한 코드 수정이 아니라 프로젝트를 완전히 새로 세운 작업이었다.
엔티티 설계부터 프로젝트 구조, 코드 구성, 주석 스타일, 응답 포맷까지 전면적으로 손봤다.
특히 ResponseEntity로 통일하고, yml 설정과 PR/이슈 템플릿을 추가하면서 협업 환경도 훨씬 체계적으로 바뀌었다.
그렇게 해서, 제주 버스 알림콜 프로젝트는 새로운 시작을 맞이했다.

성능 최적화

약 1년 전에는 기술적으로 조금이라도 점수를 얻고 싶어서 버스 정보 조회 시 발생할 수 있는 N+1 문제를 가정하고 해결한 코드를 넣어뒀다.

그런데 지금 다시 보니, 그때 만든 건 블로그에 올리지도 않았고 코드 구조도 정리가 안 되어 있었다.

그래서 이번엔 처음부터 다시 설계하면서, N+1 문제를 가정한 상황을 직접 재현하고,

그걸 해결하는 과정을 깔끔하게 정리해보려 한다.

세팅

jpa:
  hibernate:
    ddl-auto: none
  properties:
    hibernate:
      show_sql: false              # 기본적으로 SQL 로그는 찍지 않음
      format_sql: true             # 보기 좋게 포매팅 (켜질 때용)
      use_sql_comments: false      # JPQL 주석 비활성화
      generate_statistics: true   # 통계 비활성화 (Hibernate 내부 로그 제거)
      dialect: org.hibernate.dialect.MySQLDialect

해당 코드는 쿼리 로그를 보기 위해 설정을 해두었다.

package goorm.global.aop;

import lombok.extern.slf4j.Slf4j;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.springframework.stereotype.Component;
import org.springframework.util.StopWatch;

@Slf4j
@Aspect
@Component
public class PerformanceAspect {

    @Around("execution(* goorm.domain.buslog.application.service..*(..))")
    public Object measureExecutionTime(ProceedingJoinPoint joinPoint) throws Throwable {
        StopWatch stopWatch = new StopWatch();
        stopWatch.start();

        Object result = joinPoint.proceed();  // 실제 메서드 실행

        stopWatch.stop();

        String methodName = joinPoint.getSignature().toShortString();
        log.info("⏱️ [성능측정] {} 실행 시간: {} ms", methodName, stopWatch.getTotalTimeMillis());

        return result;
    }
}

해당 코드는 Aop 기반의 메서드별 성능 측정 코드이다.

package goorm.global.infra.monitoring;

import jakarta.persistence.EntityManagerFactory;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.aspectj.lang.annotation.AfterReturning;
import org.aspectj.lang.annotation.Aspect;
import org.hibernate.SessionFactory;
import org.hibernate.stat.Statistics;
import org.springframework.stereotype.Component;

@Slf4j
@Aspect
@Component
@RequiredArgsConstructor
public class HibernateStatisticsLogger {

    private final EntityManagerFactory entityManagerFactory;

    /**
     * 버스 관련 API 요청 후 Hibernate 쿼리 통계 출력
     */
    @AfterReturning("execution(* goorm.domain.buslog.presentation..*(..)) || execution(* goorm.domain.busalarm.presentation..*(..))")
    public void logHibernateStatistics() {
        SessionFactory sessionFactory = entityManagerFactory.unwrap(SessionFactory.class);
        Statistics stats = sessionFactory.getStatistics();

        long selectCount = stats.getQueryExecutionCount();   // 실행된 SELECT 문 수
        long insertCount = stats.getEntityInsertCount();     // INSERT 문 수
        long updateCount = stats.getEntityUpdateCount();     // UPDATE 문 수
        long deleteCount = stats.getEntityDeleteCount();     // DELETE 문 수
        long totalCount = selectCount + insertCount + updateCount + deleteCount;

        log.info("  [Hibernate 쿼리 통계 요약]");
        log.info("───────────────────────────────");
        log.info("SELECT 실행 횟수 : {}", selectCount);
        log.info("INSERT 실행 횟수 : {}", insertCount);
        log.info("UPDATE 실행 횟수 : {}", updateCount);
        log.info("DELETE 실행 횟수 : {}", deleteCount);
        log.info("총 쿼리 실행 횟수 : {}", totalCount);
        log.info("───────────────────────────────");

        // 요청별 측정을 위해 통계 초기화
        stats.clear();
    }
}

각각의 요청마다 최종 실행된 쿼리 수를 확인하기 위해,
직접 수동으로 빈(Bean)을 추가해서 구현했다.

참고로, 이 로직은 Hibernate에서 기본적으로 제공하는 기능을 활용한 것이다.

즉, 별도의 라이브러리를 추가하지 않아도
Hibernate의 내부 로깅 기능을 통해 쿼리 실행 횟수를 추적할 수 있다.

/**
     * 버스 로그 전체 조회 API
     * - 사용자의 모든 버스 로그를 조회
     * - 각 로그마다 알림 여부, 즐겨찾기 여부 포함
     */
    @Operation(summary = "버스 로그 전체 조회", description = "사용자의 모든 버스 기록을 조회합니다. (알림 여부, 즐겨찾기 여부 포함)")
    @ApiResponses(value = {
            @ApiResponse(responseCode = "200", description = "버스 로그 조회 성공"),
            @ApiResponse(responseCode = "404", description = "사용자 또는 버스 로그가 존재하지 않음"),
            @ApiResponse(responseCode = "500", description = "서버 내부 오류")
    })
    @GetMapping
    public ResponseEntity<List<BusLogAllRes>> getBusLogAll(@RequestParam String memberId,@AuthenticationPrincipal String userId) {
        return ResponseEntity.ok(busLogService.getBusLogAll(memberId));
    }

이번에 테스트할 API다.

위 주석에서도 볼 수 있듯이, 버스 로그를 불러오면서
각 버스에는 알림(BusAlarm)과 즐겨찾기(BusFavorite) 두 개의 연관 엔티티가 매핑되어 있다.

참고로 @RequestParam String memberId는 k6 부하 테스트를 위해 임시로 추가한 코드다.
실제 서비스 코드에는 포함되지 않는 부분이다.

/**
 *   버스 로그 전체 조회
 *
 * <p>특정 사용자의 모든 버스 로그를 조회합니다.
 * 각 로그마다 알림 활성화 여부 및 즐겨찾기 여부를 함께 반환합니다.</p>
 *
 * <p>사용자 또는 관련 데이터가 없을 경우 예외를 발생시킵니다.</p>
 *
 * @param memberId 사용자 ID
 * @return {@link BusLogAllRes} 리스트
 * @throws GoormBusException 사용자, 알림, 즐겨찾기 데이터가 존재하지 않을 경우
 */
@Override
public List<BusLogAllRes> getBusLogAll(String memberId) {
    Member findMember = memberRepository.findById(memberId).orElse(null);
    if (findMember == null)
        throw new GoormBusException(ErrorCode.USER_NOT_EXIST);

    List<BusLogAllRes> result = new ArrayList<>();
    List<BusLog> busLogs = busLogRepository.findByMember(findMember);

    for (BusLog busLog : busLogs) {
        BusAlarm findBusAlarm = busAlarmRepository.findByBusLog(busLog)
                .orElseThrow(() -> new GoormBusException(ErrorCode.BUS_ALARM_NOT_EXIST));

        BusFavorite findBusFavorite = busFavoriteRepository.findByBusLog(busLog)
                .orElseThrow(() -> new GoormBusException(ErrorCode.BUS_FAVORITE_NOT_EXIST));

        result.add(BusLogAllRes.of(
                busLog,
                findBusAlarm.isAlarmFlag(),
                findBusFavorite.isFavoriteFlag()
        ));
    }

    log.info("BusLog 전체 조회 완료: memberId={}, count={}", memberId, result.size());
    return result;
}

테스트를 진행할 서비스 코드다.

겉으로 보기에도 이미 성능적으로 문제가 많아 보이지만, 직접 실행해보면서 어느 정도의 쿼리 부하가 발생하는지 확인해보겠다.

Fetch Join 도입 전

일단 실제 트래픽은 아니지만, 문제 상황을 가정하자.
사용자 한 명이 버스 로그 1,000건을 조회한다고 했을 때,

2025-10-07T09:09:00.412+09:00 DEBUG 37124 --- [GoormBus-prod] [nio-8080-exec-2] org.hibernate.SQL                        : 
    select
        bl1_0.id,
        bl1_0.created_at,
        bl1_0.departure,
        bl1_0.destination,
        bl1_0.member_id,
        bl1_0.notion_id,
        bl1_0.station,
        bl1_0.station_id 
    from
        bus_log bl1_0 
    where
        bl1_0.member_id=?

버스 로그 데이터 1,000개를 가져오는 1개의 쿼리

2025-10-07T09:09:00.504+09:00 DEBUG 37124 --- [GoormBus-prod] [nio-8080-exec-2] org.hibernate.SQL                        : 
    select
        ba1_0.id,
        ba1_0.alarm_remaining,
        ba1_0.bus_log_id,
        ba1_0.created_at,
        ba1_0.is_alarm_flag 
    from
        bus_alarm ba1_0 
    where
        ba1_0.bus_log_id=?
2025-10-07T09:09:00.504+09:00 TRACE 37124 --- [GoormBus-prod] [nio-8080-exec-2] org.hibernate.orm.jdbc.bind              : binding parameter (1:BIGINT) <- [1]
2025-10-07T09:09:00.517+09:00 DEBUG 37124 --- [GoormBus-prod] [nio-8080-exec-2] org.hibernate.SQL                        : 
    select
        bf1_0.id,
        bf1_0.bus_log_id,
        bf1_0.created_at,
        bf1_0.is_favorite_flag 
    from
        bus_favorite bf1_0 
    where
        bf1_0.bus_log_id=?
2025-10-07T09:09:00.517+09:00 TRACE 37124 --- [GoormBus-prod] [nio-8080-exec-2] org.hibernate.orm.jdbc.bind              : binding parameter (1:BIGINT) <- [1]

binding parameter를 참고하면 위 로그가 1000개씩 2세트로 있다.

최종적으로 현재 구조에서는 위 로그처럼 연관된 알림(BusAlarm)과 즐겨찾기(BusFavorite)를 개별 조회하게 된다.

즉,

버스 로그 조회 쿼리 1회
각 로그마다 연관 엔티티 조회 쿼리 2회 (알림 + 즐겨찾기)

1 + 2N 문제가 발생하게 된다.

터미널 로그를 확인해보니, 쿼리 개수가 무려 2,001개나 찍혔다.
실행 시간은 10,835ms, 즉 거의 10초다.

단순히 데이터를 불러오는 데 이 정도 시간이 걸린다는 건, N+1 문제가 얼마나 치명적인지 그대로 보여주는 결과였다.

https://balhae.tistory.com/307

N+1문제

https://balhae.tistory.com/156 섹션1 영속성 관리 - 내부 동작 방식최코딩의 개발 섹션1 영속성 관리 - 내부 동작 방식 본문 JPA/JPA 기본 핵심 원리 섹션1 영속성 관리 - 내부 동작 방식 seung_ho_choi.s 2024. 1. 2

balhae.tistory.com

필자의 CS 블로그에서도 다뤘듯이, N+1 문제를 해결하는 방법은 여러 가지가 있다.
그중에서도 가장 대표적인 방식이 바로 Fetch Join이다.

이번에는 이 Fetch Join을 적용해서
앞서 발생했던 과도한 쿼리 실행 문제를 어떻게 개선할 수 있는지 직접 확인해보겠다.

    @Query("""
    SELECT DISTINCT b
    FROM BusLog b
    LEFT JOIN FETCH b.busAlarm
    LEFT JOIN FETCH b.busFavorite
    WHERE b.member = :member
""")
    List<BusLog> findAllWithAlarmAndFavorite(@Param("member") Member member);

}

Fetch Join을 활용해 조인과 동시에 연관된 엔티티를 함께 조회하는 방식을 사용했다.
LEFT JOIN FETCH 구문을 통해 BusLog와 연관된 BusAlarm, BusFavorite 엔티티를 한 번에 가져오도록 구성했다.

private List<BusLogAllRes> selectV1(Member findMember, List<BusLogAllRes> result) {
    List<BusLog> busLogs = busLogRepository.findByMember(findMember);

    for (BusLog busLog : busLogs) {
        BusAlarm findBusAlarm = busAlarmRepository.findByBusLog(busLog)
                .orElseThrow(() -> new GoormBusException(ErrorCode.BUS_ALARM_NOT_EXIST));

        BusFavorite findBusFavorite = busFavoriteRepository.findByBusLog(busLog)
                .orElseThrow(() -> new GoormBusException(ErrorCode.BUS_FAVORITE_NOT_EXIST));

        result.add(BusLogAllRes.of(
                busLog,
                findBusAlarm.isAlarmFlag(),
                findBusFavorite.isFavoriteFlag()
        ));
    }

    return result;
}


private List<BusLogAllRes> selectV2(Member findMember, List<BusLogAllRes> result) {
    List<BusLog> busLogs = busLogRepository.findAllWithAlarmAndFavorite(findMember);

    return busLogs.stream()
            .map(busLog -> BusLogAllRes.of(
                    busLog,
                    busLog.getBusAlarm().isAlarmFlag(),
                    busLog.getBusFavorite().isFavoriteFlag()
            ))
            .toList();

}

selectV1이 기존 코드이고, selectV2가 Fetch Join을 적용한 서비스 코드다.
이제 두 버전의 성능 차이가 어떻게 나타날지 결과가 정말 기대된다.

2025-10-07T09:21:27.074+09:00 DEBUG 22516 --- [GoormBus-prod] [nio-8080-exec-3] org.hibernate.SQL                        : 
    select
        distinct bl1_0.id,
        ba1_0.id,
        ba1_0.alarm_remaining,
        ba1_0.created_at,
        ba1_0.is_alarm_flag,
        bf1_0.id,
        bf1_0.created_at,
        bf1_0.is_favorite_flag,
        bl1_0.created_at,
        bl1_0.departure,
        bl1_0.destination,
        bl1_0.member_id,
        bl1_0.notion_id,
        bl1_0.station,
        bl1_0.station_id 
    from
        bus_log bl1_0 
    left join
        bus_alarm ba1_0 
            on bl1_0.id=ba1_0.bus_log_id 
    left join
        bus_favorite bf1_0 
            on bl1_0.id=bf1_0.bus_log_id 
    where
        bl1_0.member_id=?
2025-10-07T09:21:27.075+09:00 TRACE 22516 --- [GoormBus-prod] [nio-8080-exec-3] org.hibernate.orm.jdbc.bind              : binding parameter (1:VARCHAR) <- [ea45ebca-ce2a-4abe-8b8c-470699637be5]

쿼리 로그와 터미널 결과를 보면, 이번에는 쿼리가 단 1회만 실행된 것을 확인할 수 있다.

무엇보다 실행 시간도 이전 10,835ms에서 50ms로, 비교할 수 없을 만큼 압도적인 성능 향상을 보여줬다.

10,000개를 기준으로 조회하면 475ms가 소요된다.

인덱스 적용

Fetch Join으로 쿼리 수를 최적화하긴 했지만, 여전히 조회 속도 측면에서는 개선의 여지가 있었다.
특히 버스 로그가 수백만 건인 경우, member_id를 기준으로 검색할 때 탐색 범위가 너무 넓어지는 문제가 있었다.

@Table(
    name = "bus_log",
    indexes = {
        @Index(name = "idx_member_id", columnList = "member_id")
    }
)
public class BusLog {
    ...
}

그래서 이렇게 인덱스를 걸면, DB가 member_id 컬럼을 기준으로 B-Tree 구조로 데이터를 정렬하여 관리하게 된다.

참고로 MySQL은 B+Tree 으로 구현되어있다.

자세히 알아보자.

버스 로그 테이블에 데이터가 쭉 쌓여 있다고 하자. 이때 특정 memberId에 해당하는 로그를 찾아야 하는데, 인덱스가 없다면 데이터 전체를 훑는 풀 스캔(Full Scan) 이 발생해 성능이 저하된다.

이를 해결하기 위해 인덱스(index) 를 도입하면, memberId 기준으로 정렬된 별도의 탐색 구조가 만들어지고, DB는 이진 탐색(Binary Search) 기법을 사용해 중간에서 데이터를 빠르게 찾아간다.

하지만 이진트리는 한 노드에 하나의 데이터만 저장하므로 깊이가 깊어질수록 탐색 비용이 증가한다.

이를 개선한 구조가 B-Tree다.
B-Tree는 한 노드에 여러 개의 키를 저장하여, 탐색 시 데이터를 반씩이 아니라 3분의 2씩 줄여나가는 식으로 더 빠르게 찾을 수 있다.

여기에 한 단계 더 나아가, 실제 데이터는 가장 하단(리프 노드) 에만 보관하고, 상위 노드에는 탐색을 위한 가이드 역할만 남긴 구조가 바로 B+Tree다.
이 구조는 범위 검색(range scan) 에 매우 효율적이다.

즉, 인덱스를 생성하면 테이블과는 별도로 memberId만 모아둔 인덱스 공간이 생기고,
DB는 먼저 인덱스에서 해당 키를 찾은 뒤, 거기에 연결된 실제 테이블의 행(row)을 가져오는 방식으로 데이터를 탐색한다.

정리하자면,

pk가 primary로 선언된 기본 키는 자동으로 클러스터드 인덱스(Clustered Index) 가 된다.

이를 보조하기 위해 만든 인덱스가 비클러스터 인덱스(Non-Clustered Index, 보조 인덱스) 다.

이번 실험에서는 바로 이 보조 인덱스의 성능을 테스트하는 것이다.

클러스터 인덱스와 보조 인덱스

그 덕분에 특정 회원의 로그를 조회할 때, 전체 테이블을 스캔하지 않고도 필요한 데이터만 빠르게 탐색할 수 있다.

하지만 인덱스는 필요할 때만 사용하는 것이 중요하다.
무분별하게 남발하면 오히려 성능 저하를 초래할 수 있다.

인덱스는 조회 속도를 빠르게 해주는 대신, 데이터 삽입·수정·삭제 시마다 인덱스도 함께 갱신되어야 하기 때문에

쓰기 작업이 잦은 테이블에서는 오버헤드가 커질 수 있다.

즉, 자주 조회되는 컬럼이나 검색 조건으로 자주 쓰이는 컬럼에만 선별적으로 인덱스를 적용하는 것이 가장 효율적이다.

인덱스를 적용한 후 실행 결과는 429ms로, 이전의 475ms보다 약간 개선되긴 했지만
체감할 만큼 큰 차이는 아니었다.

그래서 이번에는 K6을 활용해 동시 사용자 부하 테스트를 진행해, 인덱스 도입 전과 후의 실제 트래픽 환경에서의 성능 차이를 비교해보려 한다.

K6 부하 테스트

import http from 'k6/http';
import { check, sleep } from 'k6';

// 실제 DB에 저장된 member UUID 리스트 (새로운 100개)
const memberIds = [
    100개 있음 (생략)
];

export const options = {
    vus: 100, // 동시 접속 사용자 수
    duration: '30s', // 테스트 시간
    thresholds: {
        http_req_duration: ['p(95)<500'], // 95% 요청이 0.5초 이내에 끝나야 함
    },
};

export default function () {
    const memberId = memberIds[Math.floor(Math.random() * memberIds.length)];
    const url = `http://localhost:8080/api/bus?memberId=${memberId}`;
    const res = http.get(url);

    check(res, {
        'status is 200': (r) => r.status === 200,
    });

    sleep(1);
}

choco로 K6을 설치한 뒤, 프로젝트 내에 per.js 파일을 작성하고 k6 run per.js 명령어로 실행했다.

시나리오

Spring Boot + JPA 기반 프로젝트의 /api/bus API에
DB 인덱스를 적용하기 전후로 K6를 사용해 부하 테스트를 진행했습니다.

테스트 환경은 다음과 같습니다:

동시 사용자(VUs): 100명
테스트 지속시간: 30초
총 요청 수: 약 3,000건
테스트 툴: k6
API 엔드포인트: /api/bus?memberId={uuid}
DB Connection Pool: 10
Connection Timeout: 2000ms
측정 환경: 로컬 환경(원래는 실제 배포 환경에서 해야된다...!)

결과

위 사진은 K6 부하 테스트 결과를 보여준다.
왼쪽은 인덱스 도입 전, 오른쪽은 인덱스 도입 후의 모습이다.
두 결과를 비교하면, 인덱스 적용이 실제 트래픽 환경에서 요청 처리 속도와 안정성에 어떤 영향을 주었는지 한눈에 확인할 수 있다.

구분	평균 응답시간(avg)	95% 응답시간(p95)	최대 응답시간(max)	요청 수	성공률	초당 처리량(RPS)
인덱스 적용 전	32.21ms	25.27ms	685.49ms	2,955	100%	95.3/s
인덱스 적용 후	30.48ms	23.05ms	662.02ms	2,982	100%	96.17/s

결과를 정리해보면 위 표와 같다.

항목	변화	의미
평균 응답속도	⬇️ 5.4% 개선	전체 쿼리 처리속도가 더 빨라짐
95% 응답속도	⬇️ 8.8% 개선	대부분의 요청이 더 짧은 시간 내 완료
최대 응답시간	⬇️ 3.4% 개선	부하 상황에서도 응답 안정성 유지
초당 요청 처리량	⬆️ 0.9% 증가	서버의 동시 처리 여유가 생김
성공률	✅ 동일 (100%)	안정적 운영 유지

분석은 위와 같다.

응답속도(ms)
|
|       인덱스 전  avg 32.21 ────────
|       인덱스 후  avg 30.48 ──────
|
|----|----|----|----|----|----|----|---->
      0   10   20   30   40   50 (ms)

시각화를 해본 그래프이다.

최종

5~10% 정도의 개선은 겉보기에는 큰 변화가 아닌 것처럼 느껴질 수 있다. 하지만 시스템 레벨에서 보면 이는 매우 의미 있는 차이다.

단일 요청 기준으로 2ms가 단축되었다고 가정하더라도, 초당 100건의 요청, 하루 800만 건의 트래픽이 처리되는 시스템에서는
결국 하루 기준 약 4시간 이상이 절약되는 효과가 발생한다.

또한 DB 인덱스의 효율은 선형적으로 증가하지 않는다. 데이터가 쌓일수록 인덱스를 사용한 탐색 속도 이득은 지수적으로 커진다.
지금은 데이터량이 적어 체감이 크지 않지만, 100만 건 이상의 데이터가 누적되는 시점부터는 10배 이상의 성능 차이가 발생할 수 있다.

인덱스는 단순히 조회 속도만 개선하는 것이 아니다. CPU 효율 향상과 Lock 경합 완화에도 직접적인 영향을 준다.
전체 테이블 스캔(Table Scan)을 피하면서 DB Connection 점유 시간이 감소하고, 그만큼 더 많은 요청을 병렬로 처리할 수 있게 된다.

결론적으로, 인덱스 적용을 통해 평균 5~9%의 응답 속도 향상과 처리 안정성 확보가 이루어졌다. 지금은 미세한 수치 변화처럼 보이지만, 데이터가 커질수록 쿼리 탐색 성능 향상 폭은 훨씬 커질 것으로 기대된다.

이번 테스트를 통해 얻은 인사이트들은 붐빔(Boombim) 프로젝트에도 꼭 적용해봐야겠다.
현재 붐빔에서는 서울 실시간 인구 데이터 OpenAPI를 통해 약 120개의 장소 정보를 조회하고 있는데,
이 데이터를 지도를 열 때마다 매번 호출하다 보니 트래픽이 증가할수록 성능 저하가 발생할 가능성이 크다.

다음에는 이 부분에 캐싱 로직을 도입해서 API 호출 빈도를 줄이고, 실제 사용자 환경에서의 반응 속도 개선에도 도전해볼 생각이다.

최코딩의 개발

[3부] CS 과제 공부하기

1. JDBC 대량 데이터 처리

1-1. 개요

1-2. 표준 Batch 처리 (addBatch, executeBatch)

1-3. 오라클 전용 Batch 처리 (setExecuteBatch, sendBatch)

2. Oracle DB 동기화 및 이중화(RAC/HA)

2-1. HA (High Availability: 고가용성)

2-2. OPS (Oracle Parallel Server): RAC의 조상

2-3. RAC (Real Application Clusters): 현대 가용성의 표준

2-4. 데이터 동기화

3. DataBase CDC (Change Data Capture ) 개념

3-1. 개념

3-2. 동작

3-3. CDC로 할 수 있는거

3-4. 참고

4. Oracle 주요 객체와 트랜잭션 메커니즘 정리(Function / Procedure / Package / Trigger / Redo·Undo / Commit·Rollback)

4-1. PL/SQL 객체 (Function, Procedure, Package, Trigger)

4-2. Redo Log vs Undo Log

4-3. Commit vs Rollback

[2부] CS 과제 공부하기

1. Byte Stream vs Character Stream

1-1. 이론

1-2. Byte Stream

1-3. Character Stream

1-4. 결론

2. String, StringBuffer, StringBuilder 차이 및 장단점

2-1. 개요

2-2. String

2-3. StringBuffer / StringBuilder

3. Call by Value / Call by Reference / Reflection

3-1. 개요

3-2. Call by Value (값에 의한 호출)

3-3. Call by Reference (참조에 의한 호출)

3-4. Java는 Call by Value일까? Call by Reference일까?

4. 자바의 리플렉션

4-1. 개요

4-2. 동작 과정

4-3. 주요 메서드

4-4. 실제 활용 사례

4-5. 누가 리플렉션을 사용하는가?

5. Java Compile option

5-1. 개요

5-2. 핵심 옵션: -classpath (-cp)

5-3. javac 컴파일 옵션 상세 정리

6. Java Memory - Garbage Collection

6-1. 개요

7. Java Static

7-1. 개요

7-2. static 변수(정적 변수)

7-3. static 메서드(정적 메서드)

7-4. static의 메모리적 관점 (바이트코드와 실행)

7-5. static 사용 시 주의할 점

[1부] CS 과제 공부하기

1. WebServer vs WAS

2. Get과 Post의 차이점

2-1. 기본 개념 차이

2-2. 주요 차이점 비교표

2-3. 보안적 관점에서의 차이

3. L3와 L4 대해

3-1. OSI에 대해

3-2. L3 (Network Layer) 깊이 파헤치기

3-3. L4 (Transport Layer) 깊이 파헤치기

3-4. L3와 L4의 차이점 정리

3-5. 실무에서의 활용

4. 쿠키와 세션의 차이

5. 세션 클러스터링

5-1. 세션 클러스터링(Session Clustering)이란?

5-2. 실생활 비유

5-3. 왜 세션 클러스터링이 필요한가?

5-4. 세션 클러스터링 방식

6. Character Set & Encoding이란?

6-1. 이론

6-2. 왜 문자 집합과 인코딩이 필요한가?

6-3. 인코딩 방식 (Encoding) ⭐ 가장 중요

6-4. 왜 글자가 깨질까요? (Decoding Error)

7. 암호화 단반향 양방햐 공개키 비공개키 암호화 종류

7-1. 단방향 vs 양방향 암호화 비교

7-2. 대칭키 vs 비대칭키(공개키/개인키) 비교

8. 유닉스 & 리눅스 명령어: Crontab (스케줄링 작업)

4. Oracle 주요 객체와 트랜잭션 메커니즘 정리
(Function / Procedure / Package / Trigger / Redo·Undo / Commit·Rollback)