또마니또(ttomanito)는 마니또(주는 사람) ↔ 마니띠(받는 사람)가 1:1로 매칭되어 익명 채팅으로만 서로를 도와주는 모바일 웹 게임입니다. 채팅 메시지가 두 사람 사이에서만 오가야 하는 구조이기 때문에, STOMP 라우팅이 사용자를 잘못 식별하면 게임성 자체가 무너집니다. HTTP 인증(SecurityContext, ThreadLocal)과 WebSocket 채널(비동기)의 컨텍스트 분리에서 출발해, 2단계 인터셉터 + 커스텀 Principal(JwtUserDetails가 UserDetails와 Principal을 동시에 구현)로 Principal.getName()을 userId로 통일한 과정을 정리합니다.

STOMP란?

Spring Boot에서 WebSocket을 구현할 때 자주 등장하는 STOMP(Simple Text Oriented Messaging Protocol)는 WebSocket 위에서 동작하는 서브프로토콜입니다. WebSocket 자체는 단순한 양방향 소켓 연결만 제공하지만, STOMP는 그 위에 구독(Subscribe) / 발행(Publish) 구조와 목적지(destination) 기반 라우팅을 더합니다.

Spring Boot에서는 @MessageMapping으로 SEND를 처리하고, SimpMessagingTemplate.convertAndSendToUser(userId, dest, payload)로 특정 사용자에게만 메시지를 보낼 수 있습니다. 이 API가 사용자를 찾는 기준이 바로 Principal.getName()입니다. 이 글의 핵심 문제는 WebSocket 채널에서 이 Principal을 어떻게 일관되게 주입하느냐입니다.

1. 들어가며

또마니또는 게임이 시작되면 참가자 간에 1:1 익명 채팅방이 자동 생성됩니다. 메시지는 두 사람 사이에서만 오가야 하고, 다른 방으로 새면 게임성이 무너집니다.

채팅 도메인을 구현하면서 두 가지를 동시에 풀어야 했습니다.

1. 메시지 저장 — 채팅 메시지를 어디에 저장할 것인가 (MongoDB vs MySQL)
2. 인증·라우팅 — STOMP 채널이 사용자를 어떻게 식별해서 1:1 메시지를 정확히 전달할 것인가

본문은 다음 흐름으로 정리합니다.

1. 채팅 도메인 구조 — STOMP + MongoDB + MySQL의 역할 분담
2. 왜 메시지 저장소는 MongoDB인가
3. 문제 — WebSocket 인증의 비동기 컨텍스트
4. 결정적 해결 — 2단계 인터셉터 + 커스텀 Principal (userId 기반)
5. 1:1 메시지 라우팅 검증

2. 채팅 도메인 구조 — STOMP + MongoDB + MySQL

채팅 도메인의 책임을 다음과 같이 세 축으로 나눴습니다.

// ChatMessage.java
@Document(collection = "chat_message")        // ★ MongoDB
public class ChatMessage {
    private Long senderUserId;
    private Long senderRoomUserId;
    private Long chattingRoomId;
    private MessageType type;
    private String content;
    private LocalDateTime sentAt;
}

// ChattingRoom.java
@Entity
@Table(name = "chatting_room")                // ★ MySQL
public class ChattingRoom {
    @ManyToOne private ManitoAssignment manitoAssignment;
    private String lastMessage;
    private LocalDateTime lastMessageTime;
}

같은 "채팅" 단어로 묶이지만, 메타데이터(ChattingRoom)와 메시지(ChatMessage)는 요구가 완전히 다릅니다. 메타는 강한 일관성과 외래 키가 필요하고, 메시지는 빠른 append와 시간 역순 페이지네이션이 필요합니다. 그래서 저장소도 분리했습니다.

WebSocket 측 설정의 핵심은 다음과 같습니다.

// WebSocketConfig.java (요약)
@Override
public void configureMessageBroker(MessageBrokerRegistry config) {
    config.enableSimpleBroker("/queue", "/topic/chat", "/topic/waiting");
    config.setApplicationDestinationPrefixes("/app");
    config.setUserDestinationPrefix("/user");           // ★ 1:1 메시지 라우팅 prefix
}

@Override
public void registerStompEndpoints(StompEndpointRegistry registry) {
    registry.addEndpoint("/ws/chat")
            .addInterceptors(jwtHandshakeInterceptor)    // HTTP 업그레이드 단계
            .setAllowedOriginPatterns("...");
}

@Override
public void configureClientInboundChannel(ChannelRegistration registration) {
    registration.interceptors(wsAuthChannelInterceptor); // STOMP CONNECT 단계
}

여기서 config.setUserDestinationPrefix("/user") 한 줄이 본 트러블슈팅의 출발점입니다. 이 설정이 켜져 있으면 서버에서 convertAndSendToUser(userId, "/queue/chat.{roomId}", payload)를 호출했을 때 STOMP 프레임워크가 자동으로 /user/{userId}/queue/chat.{roomId} 패턴으로 변환해 그 사용자의 세션에만 전달합니다.

문제는 "그 사용자가 누구인가"를 STOMP가 어떻게 결정하느냐 였습니다.

3. 왜 메시지 저장소는 MongoDB인가

이 글의 메인 주제는 인증이지만, MongoDB 선택 이유를 짚고 가야 인증·라우팅 설계와의 결합이 자연스러워집니다. MySQL chat_message 테이블 단일 구조도 검토했지만, 다음 이유로 메시지만 MongoDB로 분리했습니다.

마지막 항목이 본 트러블슈팅과 직결됩니다. 메시지를 MongoDB로 분리해두면 STOMP 채널의 책임이 "메시지를 받아 저장하고, 그 결과를 1:1로 다시 라우팅하는" 두 단계로 명확하게 정리됩니다. JPA 트랜잭션 경계와 WebSocket 비동기 처리가 같은 함수 안에 섞이는 위험이 사라지기 때문에, 인증·Principal 설계가 "누구에게 보낼 것인가" 한 가지에만 집중할 수 있습니다.

4. 문제 — WebSocket 인증의 비동기 컨텍스트

HTTP 요청은 다음 흐름으로 사용자를 식별합니다.

HTTP Request
   ↓ Servlet Filter (JwtAuthenticationFilter)
   ↓ JWT 파싱 → Authentication 객체
   ↓ SecurityContextHolder.getContext().setAuthentication(auth)   ★ ThreadLocal 저장
   ↓ Controller @AuthenticationPrincipal 주입

핵심은 SecurityContextHolder가 내부적으로 ThreadLocal이라는 점입니다. 한 HTTP 요청 = 한 스레드라는 가정 위에서만 동작합니다.

WebSocket은 이 가정이 깨집니다.

핸드셰이크가 끝나고 STOMP CONNECT / SEND / SUBSCRIBE가 들어올 때마다, 처리하는 스레드는 핸드셰이크 시점과 다른 스레드입니다. ThreadLocal인 SecurityContext는 텅 비어 있습니다. 즉 HTTP 인증 결과를 그대로 가져다 쓸 수가 없습니다.

따라서 WebSocket 채널은 자체적으로 사용자를 식별하는 방법이 필요하고, 그 방법이 STOMP CONNECT 시점에 acc.setUser(auth)로 세션에 Principal을 부착해 두는 것입니다. 이후 같은 세션의 모든 프레임에서는 StompHeaderAccessor.getUser()로 해당 Principal을 꺼낼 수 있습니다. 이것이 다음 절에서 다룰 2단계 인터셉터의 역할입니다.

또한 STOMP 1:1 메시지 라우팅(convertAndSendToUser(userId, ...))은 내부적으로 Principal.getName()으로 사용자를 찾기 때문에, "Principal의 name이 무엇이어야 하는가"가 명시적으로 정의돼야 합니다. 이메일? 로그인 ID? 데이터베이스 PK?

만약 어떤 곳은 Principal.getName() = email이고 어떤 곳은 Principal.getName() = userId.toString()으로 섞여 있으면, convertAndSendToUser("42", ...) 호출 시 그 세션의 Principal name이 "user42@example.com"이라 매칭이 안 되어 메시지가 사라지는 사고가 납니다. 이게 본 트러블슈팅의 본질이었습니다.

참고 — 자주 빠지는 함정 Spring Security의 기본 User 클래스에서 getUsername()이 반환하는 값은 보통 사용자가 로그인할 때 입력한 식별자(이메일·loginId)입니다. 반면 STOMP의 user-prefix 라우팅은 Principal.getName()을 키로 씁니다. 두 값이 같으면 문제 없지만, 어디선가 userId를 키로 쓰기 시작하면 즉시 어긋납니다.

5. 결정적 해결 — 2단계 인터셉터 + 커스텀 Principal (userId 기반)

해결은 다음 네 부분을 동시에 적용하는 형태로 진행했습니다.

1. JwtHandshakeInterceptor — HTTP → WebSocket 업그레이드 시점에 JWT 추출 + 세션 attributes 저장 (검증 실패해도 핸드셰이크 자체는 통과)
2. WebSocketAuthChannelInterceptor — STOMP CONNECT 시점에 JWT 재검증 + Principal 주입
3. JwtUserDetails — UserDetails와 Principal을 동시에 구현 + getName() = userId.toString()으로 통일
4. ChatWebSocketController — Authentication 파라미터로 Principal 받아 convertAndSendToUser(userId.toString(), ...) 호출

5-1. JwtHandshakeInterceptor (HTTP 업그레이드 단계)

// JwtHandshakeInterceptor.java (요약)
@Component
public class JwtHandshakeInterceptor implements HandshakeInterceptor {

    public static final String ATTR_JWT = "JWT_TOKEN";

    @Override
    public boolean beforeHandshake(ServerHttpRequest request, ...,
                                   Map<String, Object> attributes) {
        String token = resolveFromHeader(request);            // Authorization: Bearer ...
        if (token == null) token = resolveFromCookie(request, "accessToken");

        if (token != null && jwtProvider.isTokenValid(token)
                          && !tokenRevocationService.isRevoked(token)) {
            attributes.put(ATTR_JWT, token);                  // ★ 세션 attributes에 저장
        }
        return true;                                          // ★ 항상 true — 검증은 다음 단계에서
    }
}

핵심은 return true입니다. 핸드셰이크 자체는 항상 성공시키고, 토큰만 세션 attributes에 옮겨 둡니다. 이렇게 분리한 이유는 두 가지입니다.

• HTTP 핸드셰이크 단계에서 401 반환하면 클라이언트가 재시도 시 쿠키/헤더 흐름이 복잡해짐
• 채널 인터셉터 단계에서 다시 검증할 거라, 굳이 두 번 거절할 필요가 없음

5-2. WebSocketAuthChannelInterceptor (STOMP CONNECT 단계)

// WebSocketAuthChannelInterceptor.java (요약)
@Override
public Message<?> preSend(Message<?> message, MessageChannel channel) {
    StompHeaderAccessor acc = MessageHeaderAccessor.getAccessor(
            message, StompHeaderAccessor.class);

    if (acc != null && StompCommand.CONNECT.equals(acc.getCommand())) {
        // ① 핸드셰이크 단계에서 저장한 토큰
        String token = resolveFromSession(acc.getSessionAttributes());
        // ② 폴백 — STOMP native header의 Authorization
        if (token == null) token = resolveFromNativeHeader(acc);

        if (token != null && jwtProvider.isTokenValid(token)) {
            UserDetails ud = jwtProvider.loadUserFromToken(token);    // ★ JwtUserDetails 로드
            var auth = new UsernamePasswordAuthenticationToken(
                    ud, null, ud.getAuthorities());
            acc.setUser(auth);                                        // ★ STOMP 사용자 등록
            log.debug("[WS] Authentication set for user={}", ud.getUsername());
        }
    }
    return message;
}

핵심은 acc.setUser(auth) 한 줄입니다. 이 시점부터 같은 STOMP 세션에서 들어오는 모든 메시지에는 Spring이 자동으로 Authentication을 주입해 줍니다.

5-3. JwtUserDetails — UserDetails + Principal 동시 구현

// JwtUserDetails.java (요약)
public class JwtUserDetails implements UserDetails, Principal {   // ★ 두 인터페이스 동시
    private final Long userId;
    private final String username;
    private final List<? extends GrantedAuthority> authorities;

    public JwtUserDetails(User user) {
        this.userId   = user.getUserId();
        this.username = String.valueOf(user.getUserId());          // ★ userId 문자열
        this.authorities = List.of(new SimpleGrantedAuthority("ROLE_USER"));
    }

    @Override public String getUsername() { return username; }     // userId 문자열
    @Override public String getName()     { return userId.toString(); }  // ★ Principal.getName()
}

이 클래스 한 곳에서 "이 시스템에서 사용자를 식별하는 키는 userId 한 가지"를 못 박습니다.

• UserDetails.getUsername() → "42" (userId 문자열)
• Principal.getName() → "42" (userId 문자열)
• HTTP 측 @AuthenticationPrincipal JwtUserDetails에서도 동일
• WebSocket 측 Principal.getName()에서도 동일

이 일치 한 가지가 convertAndSendToUser(userId.toString(), ...)가 항상 같은 키로 매칭됨을 보장합니다.

5-4. ChatWebSocketController — Principal 주입 + 1:1 라우팅

// ChatWebSocketController.java (요약)
@MessageMapping("/chat.send.{chatRoomId}")
public void sendMessage(@DestinationVariable Long chatRoomId,
                        @Payload ChatMessageDto payload,
                        Authentication authentication) {           // ★ Principal 주입
    if (authentication == null
            || !(authentication.getPrincipal() instanceof JwtUserDetails jud)) {
        log.warn("[WS] 인증 없음 — 메시지 드롭");
        return;
    }
    Long senderUserId = jud.getUserId();

    // ① MongoDB에 저장
    ChatMessage saved = chatMessageRepository.save(
            ChatMessage.createText(chatRoomId, ..., senderUserId, payload.content()));

    // ② 두 사용자에게 1:1 라우팅
    List<Long> receivers = service.findReceivers(chatRoomId, senderRoomUserId);
    for (Long uid : receivers) {
        template.convertAndSendToUser(
                uid.toString(),                                    // ★ Principal.getName()과 매칭
                "/queue/chat." + chatRoomId,
                new SocketPayload<>("MESSAGE", saved));
    }
}

핵심 포인트:

• Authentication 파라미터를 컨트롤러 메서드 시그니처에 명시 → Spring이 자동 주입
• instanceof JwtUserDetails jud 패턴 매칭으로 타입 안전 추출
• convertAndSendToUser(uid.toString(), ...)의 첫 인자가 Principal.getName()과 정확히 일치

6. 1:1 메시지 라우팅 검증

해결책 적용 후, 한 채팅방의 두 사용자 사이에서 STOMP 메시지가 다음과 같이 흘러갑니다.

[Manito Browser]                  [Spring]                       [Manitti Browser]
  │ STOMP CONNECT                   │
  │   Authorization: Bearer ...     │
  │ ──────────────────────────────▶ │ JwtHandshakeInterceptor       │
  │                                 │   → attributes.JWT_TOKEN      │
  │                                 │ WebSocketAuthChannelIntercept │
  │                                 │   → acc.setUser(auth)         │
  │                                 │   Principal.getName() = "42"  │
  │                                 │                               │
  │ SUBSCRIBE /user/queue/chat.5    │                               │
  │ ──────────────────────────────▶ │ (Principal "42"의 채널)       │
  │                                 │                               │
  │ SEND /app/chat.send.5  "안녕"   │                               │
  │ ──────────────────────────────▶ │ ChatWebSocketController       │
  │                                 │   senderUserId = 42           │
  │                                 │   MongoDB save                │
  │                                 │   convertAndSendToUser(       │
  │                                 │     "99", /queue/chat.5, ...) │
  │                                 │ ──────────────────────────▶  │
  │                                 │                               │  ◀── /user/queue/chat.5
  │                                 │                               │      "안녕"

convertAndSendToUser("99", ...)의 "99"가 마니띠의 Principal.getName()과 정확히 같은 값(userId.toString())이기 때문에 STOMP가 그 사용자의 세션 큐에만 메시지를 꽂아 줍니다.

마니또(uid=42)와 마니띠(uid=99) 두 브라우저를 동시에 열어 STOMP 연결 → 메시지 전송 → 수신까지 재현

서버 로그에서는 JWT 핸드셰이크 인터셉터 → STOMP CONNECT 인증 설정 → MongoDB 저장 → 수신자 큐 라우팅의 전 구간이 순서대로 확인됩니다.

찌르기·통화·알림까지 같은 채널 위에서

같은 인증 컨텍스트 위에서 채팅뿐 아니라 찌르기(/chat.poke)·통화 시그널링(/chat.call.start/accept/reject)까지 동일하게 동작합니다. Principal이 한 가지 키(userId)로 통일되어 있으니, 어떤 매핑에서도 "이 사용자에게만 알림" → convertAndSendToUser(userId.toString(), ...) 한 줄로 끝납니다.

7. 정리

Before vs After

인증 흐름 비교

                  HTTP 요청                     WebSocket 채널
                  ─────────                     ────────────
1. 토큰 검증     JwtAuthenticationFilter       JwtHandshakeInterceptor (1회)
                                              + WebSocketAuthChannelInterceptor (CONNECT)

2. 저장소        SecurityContext (ThreadLocal) StompHeaderAccessor.user (세션 단위)

3. 사용자 키     JwtUserDetails.getUsername()  JwtUserDetails.getName()
                = userId 문자열                = userId 문자열   ← 같은 값
4. 컨트롤러      @AuthenticationPrincipal      Authentication 파라미터
                JwtUserDetails ud              → ud.getUserId()

세 번째 행이 결론입니다. UserDetails.getUsername()과 Principal.getName()이 같은 클래스에서 같은 값(userId)을 반환하도록 통일한 것이 곧 HTTP·WS 두 컨텍스트를 묶는 접점이었습니다.

마무리

본 포스팅에서는 또마니또 프로젝트의 STOMP 1:1 채팅 라우팅이 의미를 가지기 위한 인증 인프라로서, HTTP 인증과 분리된 WebSocket 채널의 비동기 컨텍스트에서 사용자를 어떻게 식별할 것인가 문제를 풀었던 과정을 정리하였습니다.

핵심 요약

• WebSocket은 비동기 채널이므로 HTTP의 SecurityContext를 그대로 못 쓴다.
• 1:1 메시지 라우팅의 키는 Principal.getName() — 이 값을 시스템 전반에서 하나로 통일해야 한다.
• UserDetails와 Principal을 같은 클래스에 두고 같은 값(userId)을 반환하게 하면 HTTP·WS 두 컨텍스트가 한 줄로 묶인다.

'AI 예산 관리·소비 코칭 모바일 서비스' '똑똑꺼비' 프로젝트의 시그니처 기능은 사용자가 매장 앞에서 핸드폰을 한 번 흔들면, GPS 로 주변 가맹점 리스트를 띄우고, 사용자가 매장을 확인·선택하면 그 매장에서 가장 혜택 좋은 결제 카드와 사용 가능한 기프티콘을 한 화면에 보여주는 Interactive 소비 제안 입니다. 이 기능이 의미를 가지려면 사용자가 미리 등록해둔 기프티콘이 "그 매장의 기프티콘" 으로 정확히 분류되어 있어야 했고, 그 데이터 정형화의 출발점이 OCR 자동 등록이었습니다. 처음 검토했던 Tesseract 의 한국어 정확도 한계에서 출발해, GCP Vision API + 도메인 텍스트 파서(GifticonTextParser) 의 2단 구조로 전환한 과정을 정리한 내용입니다.

1. 들어가며

똑똑꺼비의 핵심 기능은 다음과 같습니다.

② Interactive 소비 제안 기능에서, 사용자가 GS25 앞에서 핸드폰을 흔들었을 때 시스템은 다음 흐름을 풀어야 합니다.

흔들기
  └─ GPS 좌표 + 반경 N m 이내 주변 가맹점 리스트
        └─ "지금 [가맹점명] 이 맞나요?" 확인 창
              └─ 사용자 확정(또는 다른 매장으로 변경)
                    └─ 그 매장 결제 카드 추천 + 사용 가능 기프티콘 목록

실제 결과 화면 — GS25 매장이 선택된 후 그 매장에서 가장 혜택이 좋은 결제 카드(케이패스 3933)가 한 화면에 노출됩니다.

마지막 단계 — "그 매장 결제 카드 + 사용 가능 기프티콘 목록" 이 의미를 가지려면, 사용자가 사전에 등록해둔 기프티콘 이 정확한 가맹점(franchiseId) 으로 분류되어 있어야 합니다. "스타벅스" / "Starbucks" / "스타벅스 코리아" 가 등록 시 자유롭게 입력되어 서로 다른 가맹점으로 들어가 있다면, 사용자가 흔들기 결과로 "스타벅스" 매장을 선택해도 본인의 "Starbucks" 표기 기프티콘이 매칭되지 않는 상황이 발생합니다.

따라서 기프티콘 등록 단계 에서 다음 두 가지를 동시에 풀어야 했습니다.

1. 이미지 → 텍스트 (OCR 정확도)
2. 텍스트 → 도메인 모델 (브랜드 캐노니컬 매핑 · 만료일 LocalDate 파싱 · 상품명 추출)

본문은 다음 흐름으로 정리합니다.

1. 등록 단계가 흔들기 결과 매칭에 어떻게 이어지는가
2. Tesseract(Tess4J) 한국어 OCR
3. 정규식 + 캐노니컬 사전으로 후처리 보강
4. GCP Vision API + 도메인 텍스트 파서 분리
5. 측정 결과

2. 등록 데이터 품질이 흔들기 결과 매칭을 결정한다

기프티콘 등록은 흔들기와는 완전히 분리된 사전 단계 입니다. 사용자는 카카오톡 선물함 등에서 받은 기프티콘 이미지를 앱에 등록해 두고, 등록된 기프티콘은 서비스 DB 에 영속됩니다. 이후 매장 앞에서 흔들기를 했을 때, 시스템은 사용자가 선택한 가맹점에 매칭되는 기프티콘을 DB 에서 검색해 보여줍니다.

즉 흔들기 자체가 등록을 대체하는 게 아니라, 등록 단계에서 부여된 franchiseId 의 정확도가 흔들기 결과 화면의 정확도를 결정 하는 구조입니다.

기존 등록 폼은 다음 4 개 필드로 구성되어 있었습니다.

• 브랜드(franchise) — 드롭다운 검색 (스타벅스 / 배스킨라빈스 / 배달의민족 …)
• 상품명(label) — 자유 입력 ("아메리카노 Tall" 같은 형태)
• 만료일(expiresAt) — 날짜 피커
• 이미지(imageUrl) — 파일 첨부

이 자유 입력 방식이 등록 단계와 이후 흔들기 매칭 단계에 누적시키는 문제는 다음과 같았습니다.

즉 "흔들면 매장에서 쓸 수 있는 내 기프티콘이 정확히 뜬다" 라는 시그니처 결과 화면의 품질이 사용자가 사전에 입력한 등록 데이터 품질에 그대로 종속 되어 있었습니다. 자동 추출과 정규화가 같이 풀려야 했습니다.

사용자가 등록해 둔 기프티콘이 스타벅스 / 이디야 / 탐앤탐스 등 매장 단위로 정확히 그룹화 되어 있어야, 흔들기 후 매장 선택 단계에서 곧바로 매칭되는 기프티콘을 꺼내올 수 있습니다.

3. Tesseract (Tess4J)

처음에는 외부 비용 없이 자체 OCR 을 돌리는 쪽을 우선 검토하였습니다. JVM 환경에서 가장 흔한 옵션은 Tess4J (Tesseract 의 Java 바인딩) 입니다.

implementation 'net.sourceforge.tess4j:tess4j:5.12.0'

구현 시도

Tesseract tess = new Tesseract();
tess.setDatapath("/usr/share/tesseract-ocr/4.00/tessdata");
tess.setLanguage("kor+eng");
String text = tess.doOCR(imageFile);

샘플 기프티콘 이미지(스타벅스 / 배스킨라빈스 / GS25 / CU 등) 를 모아 OCR 을 돌려보았습니다. 결과 텍스트 품질에 다음과 같은 한계가 드러났습니다.

참고 Tesseract 의 한국어 정확도는 인쇄체 본문 에는 충분하지만, 광고/패키징 디자인 텍스트 에서는 떨어지는 것으로 알려져 있습니다. 기프티콘 카드는 후자에 해당합니다.

이 단계에서 OCR 결과 텍스트 자체의 품질이 너무 흔들렸기 때문에, 후처리 정규식·사전이 무엇을 해도 입력 노이즈가 그대로 따라오는 상황이었습니다.

4. 정규식 + 캐노니컬 사전으로 후처리 보강

OCR 결과를 그대로 쓰지 못한다면, 결과 텍스트 위에 강한 정규식 + 캐노니컬 사전 을 얹어 보정해 보기로 했습니다.

// 흘림체로 깨진 "스 타 벅 스" → "스타벅스" 복원 시도
text = text.replaceAll("(\\S)\\s+(?=\\S)", "$1");

// 만료일 패턴 — 다중 구분자 흡수
Matcher m = Pattern.compile(
    "(20\\d{2})[./년 -]\\s*(\\d{1,2})[./월 -]\\s*(\\d{1,2})"
).matcher(text);

// 브랜드 캐노니컬 사전 (예시)
Map<String, String> CANON = Map.of(
    "starbucks", "스타벅스",
    "스타벅스코리아", "스타벅스",
    "STARBUCKS", "스타벅스"
);

확인된 한계

• 정규식이 잡는 패턴 ⊂ OCR 이 흐트러뜨린 패턴 — 흘려쓰기 + 자모 오인식 이 결합되면 어떤 정규식도 회복 불가
• 캐노니컬 사전을 두껍게 만들수록 새 브랜드 추가 비용 ↑
• 사용자가 수정한 결과를 학습 데이터로 모으기엔 운영 부담 큼

→ "OCR 텍스트 품질을 끌어올리지 않는 한 정규식 후처리는 한계가 명확하다" 가 결론이었습니다. OCR 엔진 자체를 교체하는 쪽이 본질적인 해법 이라는 판단으로 다음 단계로 넘어갔습니다.

5. GCP Vision API + 도메인 텍스트 파서 분리

5-1. 선택 이유

GCP Vision API 의 TEXT_DETECTION 은 다음 측면에서 Tesseract 보다 유리했습니다.

• 한국어 광고/패키징 디자인 폰트 에 학습된 OCR 모델
• 줄/블록 단위 레이아웃 정보까지 함께 반환 → 정형화 단계가 훨씬 가벼움
• 인프라/모델 관리 부담 0 — credentials JSON 한 장만 컨테이너에 주입

무료체험 계정을 사용하여 부담을 줄였습니다.

5-2. 인터페이스로 분리한 OCR 클라이언트

OCR 엔진 자체는 향후 교체 여지가 있다고 판단해 OcrClient 인터페이스로 추상화하였습니다.

public interface OcrClient {
    String extractText(byte[] imageBytes) throws Exception;
}

@Component
@ConditionalOnProperty(name = "app.ocr.provider", havingValue = "vision", matchIfMissing = true)
public class VisionOcrClient implements OcrClient {

    @Value("${app.ocr.credentials-path:}")
    private String credentialsPath;

    @Override
    public String extractText(byte[] imageBytes) throws Exception {
        var settings = ImageAnnotatorSettings.newBuilder();
        if (!credentialsPath.isBlank()) {
            try (var in = Files.newInputStream(Path.of(credentialsPath))) {
                var creds = GoogleCredentials.fromStream(in)
                        .createScoped(List.of("https://www.googleapis.com/auth/cloud-platform"));
                settings.setCredentialsProvider(FixedCredentialsProvider.create(creds));
            }
        }
        try (var client = ImageAnnotatorClient.create(settings.build())) {
            var img  = Image.newBuilder().setContent(ByteString.copyFrom(imageBytes)).build();
            var feat = Feature.newBuilder().setType(Feature.Type.TEXT_DETECTION).build();
            var req  = AnnotateImageRequest.newBuilder().addFeatures(feat).setImage(img).build();
            var res  = client.batchAnnotateImages(List.of(req)).getResponses(0);
            if (res.hasError())
                throw new IllegalStateException("OCR error: " + res.getError().getMessage());
            return res.getTextAnnotationsList().isEmpty()
                    ? "" : res.getTextAnnotationsList().get(0).getDescription();
        }
    }
}

핵심 포인트

• @ConditionalOnProperty — app.ocr.provider=vision 기본값. 향후 다른 엔진으로 교체할 때 빈 자체로 차단
• credentials 두 가지 경로 — 명시적 파일 경로 / ADC(Application Default Credentials) 자동 fallback
• 응답에서 getTextAnnotationsList().get(0) 만 꺼내면 줄/블록 정보까지 합쳐진 전체 텍스트 한 덩어리

5-3. OCR 텍스트 → 도메인 모델 정형화 (GifticonTextParser)

OCR 결과 품질이 안정되었으니, 이제 정형화 책임만 따로 떼서 도메인 텍스트 파서로 분리하였습니다. OCR 엔진과 도메인 정형화가 같은 클래스에 있으면 엔진 교체 시 변경 영역이 광범위해지기 때문입니다.

GifticonTextParser 는 다음 세 함수만 노출합니다.

• findBrand(String text) → String
• findExpiry(String text) → LocalDate
• findLabel(String text, String brand) → String

각각의 전략은 다음과 같습니다.

브랜드 — 2단 fallback + 캐노니컬 매핑

1순위 : "교환처:" 라벨 뒤 텍스트  → 정규식 캡처
2순위 : 상위 6 줄 토큰 빈도 분석  → ≥ 2 회 등장한 토큰
캐노니컬 사전 (77 개)
        "starbucks" / "스타벅스 코리아" / "STARBUCKS"  →  "스타벅스"

이 캐노니컬 매핑이 곧 흔들기 결과 매칭의 조인 키 입니다. 사용자가 흔들기 후 가맹점을 선택하면 그 가맹점의 franchiseId 가 결정되고, 사용자 기프티콘은 정규화된 franchiseId 로 즉시 검색됩니다.

매칭이 끝나면 사용자는 추가 입력 없이 바로 사용 가능한 기프티콘 바코드를 노출받게 됩니다 — 예: GS25 매장 선택 후 등록해둔 바나나우유 기프티콘이 즉시 노출.

만료일 — 다중 형식 정규식

Pattern.compile("(20\\d{2})[./년- ]\\s*(\\d{1,2})[./월- ]\\s*(\\d{1,2})")
// "2025/11/30" / "2025.11.30" / "2025년 11월 30일" / "2025-11-30" 모두 흡수

LocalDate 로 변환되어야 흔들기 결과 화면에서 만료된 기프티콘을 자동으로 걸러낼 수 있습니다.

상품명 — 스코어링

상위 점수 후보 한 개를 label 로 채택합니다.

5-4. 호출 흐름

@PostMapping(consumes = MediaType.MULTIPART_FORM_DATA_VALUE)
public ResponseEntity<GifticonCreateResponse> upload(@RequestPart MultipartFile file) {
    Long userId = SecurityUtils.currentUserIdOrNull();
    return ResponseEntity.ok(gifticonService.createFromUpload(userId, file));
}

@Transactional
public GifticonCreateResponse createFromUpload(Long userId, MultipartFile file) {
    String text   = ocrClient.extractText(file.getBytes());           // ① 외부 OCR
    if (!isGifticon(text)) throw new InvalidGifticonImage();           // ② 가드 (키워드 + 바코드 패턴)
    String brand  = parser.findBrand(text);                            // ③ 정형화
    LocalDate exp = parser.findExpiry(text);
    String label  = parser.findLabel(text, brand);

    Franchise fr  = franchiseService.findOrCreate(brand);              // ④ 캐노니컬 매핑
    Gifticon g    = gifticonRepository.save(Gifticon.of(userId, fr, label, exp, imageUrl));
    return GifticonCreateResponse.from(g, text);                       // ocrPreview 도 함께 반환
}

핵심

• OCR 호출 과 도메인 정형화 가 깨끗이 분리됨 → 엔진 교체 비용 ↓
• 응답에 ocrPreview 를 함께 내려, 사용자가 부정확한 필드를 즉시 손볼 수 있도록 UX 보조
• franchiseService.findOrCreate(brand) 가 곧 흔들기 결과 매칭이 의존하는 정규화 지점

6. 측정 결과

Before vs After

참고 위 정확도 수치는 자율 테스트셋(팀·지인 보유 기프티콘 약 50 장) 기준입니다.

마무리

본 포스팅에서는 똑똑꺼비 프로젝트의 Interactive 소비 제안(흔들기 → 가맹점 선택 → 카드/기프티콘) 이 의미를 가지기 위한 데이터 인프라로서, 기프티콘 자동 등록 OCR 을 Tesseract 후처리에서 GCP Vision API + 도메인 정규화 분리 구조로 전환한 과정을 정리하였습니다.

핵심 요약

• OCR 엔진 품질 자체 가 후처리 정규식의 상한선을 결정.
• 엔진(OcrClient) 과 도메인 정규화(GifticonTextParser) 의 책임을 처음부터 분리 해야 교체 비용이 작아짐.
• 자동 추출만으로는 부족 — 캐노니컬 매핑(브랜드 사전) 이 시그니처 기능(흔들기 후 가맹점 선택 시의 기프티콘 매칭) 의 조인 키 품질을 결정.

'운세 강화게임과 결합된 새로운 경험의 데일리 운세 플랫폼' '아그작' 프로젝트에서, 자정에 도는 랭킹 스냅샷 스케줄러가 새벽 시간대에만 Deadlock 으로 죽는 패턴을 발견하였습니다. Grafana Alert → Mattermost 로 새벽 에러를 실시간 감지한 뒤 원인을 추적하고, ShedLock + Redis 분산 락 + 매시간 분할로 해결한 과정을 정리한 내용입니다.

1. 들어가며

아그작은 사용자의 오늘 운세 점수를 기반으로 시간 단위 랭킹 을 제공하는 서비스입니다. 초기에는 매일 23:59 에 단 한 번 그날치 랭킹 스냅샷을 새로 갈아끼우는 단순 cron 으로 동작하고 있었으나, 자정 직후 새벽 시간대에 간헐적으로 Deadlock 예외 가 발생하는 현상을 확인하였습니다.

TaskUtils$LoggingErrorHandler : Unexpected error occurred in scheduled task
SqlExceptionHelper            : Deadlock found when trying to get lock; try restarting transaction

낮 시간대에 동일 스케줄러를 임의로 트리거해 보면 문제 없이 돌고 있었기에, "왜 새벽에만 터지는가" 를 출발점으로 원인을 추적하였습니다.

본문은 다음 흐름으로 정리합니다.

1. 문제 상황 진단 — Grafana Alert 로 새벽 에러 감지
2. 기존 스케줄러 구조와 운영 환경 분석
3. 원인 — Blue/Green 두 컨테이너의 스케줄러 동시 실행
4. ShedLock + Redis 분산 락 적용 (매시간 분할 포함)
5. 측정 결과 및 회고

2. 문제 상황 진단 — Grafana Alert → Mattermost

운영에는 EFK + Prometheus + Grafana 기반의 모니터링 체계가 구축되어 있었고, 5xx 또는 ERROR 레벨 로그가 5분 윈도우 내에 임계치를 넘으면 Mattermost 로 알림이 전달되도록 설정되어 있었습니다.

함께 운영 채널에는 다음과 같이 데드락 메시지를 직접 식별 한 캡처도 남아 있습니다.

[FIRING] Application 5xx ERROR detected (logs, 5m window) (critical)
Env: prod | Service: agzak-app-server | Count: 2
- 최근 5분 이내 ERROR 레벨 로그가 발생했습니다.

해당 알림을 통해 새벽 시간대에 다음과 같은 패턴으로 ERROR 가 발생되고 있다는 사실을 확인하였습니다.

3. 기존 스케줄러 구조와 운영 환경 분석

문제가 일어난 스케줄러는 RankingScheduler 의 단일 메서드입니다. 당시에는 하루 한 번 23:59 에 그날치 랭킹을 통째로 갈아끼우는 단순 cron 이었습니다.

@Component
@EnableScheduling
@RequiredArgsConstructor
public class RankingScheduler {

    private final RankingService rankingService;

    /** 매일 23:59: 그날치 ranking 스냅샷을 통째로 재생성 */
    @Scheduled(cron = "0 59 23 * * *", zone = "Asia/Seoul")
    public void todayRebuild() {
        rankingService.rebuildTodaySnapshot();
    }
}

rebuildTodaySnapshot() 의 핵심은 해당 날짜 스냅샷을 통째로 교체 하는 부분입니다.

@Transactional
public void replaceTodaySnapshot(LocalDate date, List<Ranking> rows) {
    rankingRepository.deleteByDate(date);   // ① 그날치 ranking 전부 삭제
    if (rows != null && !rows.isEmpty()) {
        rankingRepository.saveAll(rows);    // ② 새 랭킹 일괄 INSERT
    }
}

운영 환경은 다음과 같이 구성되어 있습니다.

• AWS EC2 단일 인스턴스 위에 Docker compose 로 서비스 기동
• 백엔드는 Blue/Green 무중단 배포 구조 — 두 컨테이너(agzak-app-blue, agzak-app-green) 가 nginx 뒤에서 트래픽을 나눠 받음
• 두 컨테이너 모두 동일한 MySQL/Redis 를 바라봄

CI/CD 부분만 따로 보면 다음과 같이 Jenkins → Spring BE(Blue/Green) → Nginx 흐름이 잡혀 있습니다.

이 환경에서 "왜 동시에 두 인스턴스가 같은 스케줄러를 돌고 있는가?" 가 사건의 진짜 원인이 됩니다.

4. 원인 — Blue/Green 두 컨테이너의 스케줄러 동시 실행

@Scheduled 어노테이션은 각 JVM 마다 독립적으로 동작 합니다. 즉 Blue 와 Green 두 컨테이너가 동시에 떠 있는 상태에서는, 양쪽이 같은 cron 시각에 동일한 스케줄러를 동시에 실행 합니다.

이 상태에서 두 컨테이너가 23:59 정각에 동시에 다음을 수행하게 됩니다.

[Blue]  TX-A: DELETE FROM ranking WHERE date = '2025-11-18'
[Green] TX-B: DELETE FROM ranking WHERE date = '2025-11-18'
[Blue]  TX-A: INSERT INTO ranking (...) VALUES (...) x N
[Green] TX-B: INSERT INTO ranking (...) VALUES (...) x N

ranking 테이블에는 (member_id, date) 복합 유니크 제약과 (date, rank_no) 인덱스가 잡혀 있습니다.

@Table(
    name = "ranking",
    uniqueConstraints = {
        @UniqueConstraint(name = "UQ_ranking_member_date", columnNames = {"member_id", "date"})
    },
    indexes = { @Index(name = "IDX_ranking_date_rank", columnList = "date, rank_no") }
)

이 구조에서는 다음 시나리오로 Deadlock 이 발생합니다.

참고 InnoDB 는 인덱스 단위로 락을 잡고, DELETE ... WHERE date = ? 는 인덱스 범위 락(gap + record lock) 을 광범위하게 점유합니다. 두 트랜잭션이 같은 범위에 동시에 들어오면 락 획득 순서가 어긋나는 순간 Deadlock 이 발생할 수 있습니다.

실제로 동일 시나리오를 로컬에서 재현하여 SHOW ENGINE INNODB STATUS 의 LATEST DETECTED DEADLOCK 섹션을 확인하면, 두 트랜잭션이 서로의 gap lock 을 기다리다 한쪽이 victim 으로 롤백되는 구조가 그대로 드러납니다.

위 캡처는 Blue 컨테이너의 트랜잭션이 ranking 테이블 PRIMARY 인덱스 위에서 lock_mode X locks gap before rec 를 보유한 채로 자신의 insert intention 락을 또다시 기다리고 있는 상태를 보여줍니다. Green 쪽도 같은 상태에 들어가면 InnoDB 가 한쪽을 victim 으로 골라 ROLLBACK 합니다.

InnoDB 가 *** WE ROLL BACK TRANSACTION (2) 로 victim 을 명시하는 부분이 운영 환경에서 보이던 Deadlock found when trying to get lock; SQLState 40001 의 직접적인 원인이었습니다.

그렇다면 왜 새벽(자정 직후)에만 터지는가?

당시 스케줄러는 매일 23:59 단 한 번 만 도는 cron 이었기 때문에, 매일 같은 시각에 두 컨테이너가 거의 밀리초 단위로 동시에 트리거됩니다. 더불어 자정 직후에는 외부 트래픽이 거의 없어 다른 SQL 의 간섭이 들어오지 않으니, 두 트랜잭션의 락 획득 시점이 정확히 같은 윈도우 에 진입합니다.

즉, 자정 Deadlock 은 다음 두 조건이 동시에 만족된 결과였습니다.

• 1일 1회 정시 cron — 두 컨테이너가 동일 시각에 ms 단위로 동기화되어 출발
• 외부 트래픽 0 — 다른 트랜잭션이 락 윈도우를 흩뜨릴 여지가 없음

5. ShedLock + Redis 분산 락 적용 (매시간 분할 포함)

해결은 두 가지를 함께 적용하는 형태로 진행하였습니다.

1. ShedLock + Redis 분산 락 — Blue/Green 두 컨테이너가 떠 있어도 한쪽만 실제 작업 수행
2. 자정 1회 → 매시간 분할 — 시간 단위 랭킹 요구사항에도 맞춰, @Scheduled 를 매시간 cron 으로 잘게 쪼갬

ShedLock(net.javacrumbs.shedlock) 은 다중 인스턴스 환경에서 @Scheduled 가 한 번만 실행되도록 보장 해주는 라이브러리입니다. 이미 운영에 사용 중이던 Redis 를 락 저장소로 그대로 활용할 수 있어 추가 인프라 부담이 없었습니다.

의존성

implementation 'net.javacrumbs.shedlock:shedlock-spring:5.15.1'
implementation 'net.javacrumbs.shedlock:shedlock-provider-redis-spring:5.15.1'

LockProvider 설정

@Configuration
public class SchedulerLockConfig {

    @Bean
    public LockProvider lockProvider(StringRedisTemplate stringRedisTemplate) {
        return new RedisLockProvider(
                Objects.requireNonNull(stringRedisTemplate.getConnectionFactory()),
                "shedlock:agzak"          // Redis key prefix
        );
    }
}

매시간 분할 + @SchedulerLock 적용

@Component
@EnableScheduling
@RequiredArgsConstructor
public class RankingScheduler {

    private final RankingService rankingService;

    /** 매시간 59분 55초: Redis → MySQL 스냅샷 재생성 */
    @Scheduled(cron = "55 59 * * * *", zone = "Asia/Seoul")
    @SchedulerLock(name = "rankingSnapshot", lockAtMostFor = "PT4M", lockAtLeastFor = "PT20S")
    public void todayRebuild() {
        rankingService.rebuildTodaySnapshot();
    }

    /** 매시간 55분: MySQL → Redis 리씨드 (정합성 보정) */
    @Scheduled(cron = "0 55 * * * *", zone = "Asia/Seoul")
    @SchedulerLock(name = "rankingReseed", lockAtMostFor = "PT4M", lockAtLeastFor = "PT10S")
    public void hourlyReseedRedis() {
        rankingService.reseedRedisFromMysqlToday();
        int pruned = rankingService.pruneTodayOrphans();
        if (pruned > 0) log.info("Pruned {} orphan(s) after reseed", pruned);
    }
}

각 옵션의 의미는 다음과 같습니다.

동작 흐름

55분 정각
 ├─ Blue:  RedisLockProvider.lock("rankingReseed") → SET NX 성공 → 실행
 └─ Green: RedisLockProvider.lock("rankingReseed") → SET NX 실패 → 스킵

내부적으로는 Redis SET key value NX PX <ms> 명령을 사용하기 때문에, 두 컨테이너가 정확히 동시에 시도해도 한쪽만 락을 획득 합니다. 락을 못 받은 쪽은 조용히 메서드를 빠져나갑니다.

이 구성으로 "Blue/Green 동시 실행" 이라는 근본 원인이 사라지고, 자정 1회 → 매시간 분할로 바뀌면서 만에 하나 한 사이클이 깨져도 다음 시간 cron 에서 자동 회복 되는 안전망이 생깁니다.

Grafana 의 Loki 로그 패널에서 두 컨테이너의 동작을 함께 보면, 한쪽은 ACQUIRED — snapshot ok, 다른 쪽은 skipped — locked by ... 가 매 사이클마다 교차로 찍히는 것을 확인할 수 있습니다.

같은 시각에 양쪽이 동시에 트리거되어도 실제 DB 작업은 단 한 번만 수행되며, 락 토큰(d450e30d9dde-..., 2483813bd96c-...) 으로 어느 인스턴스가 락을 잡았는지 추적이 가능합니다.

참고 — 위 Grafana 캡처는 로컬 재현 환경에서 캡처한 자료입니다.

6. 측정 결과

ShedLock + 매시간 분할 적용 전후를 운영 로그 기준으로 비교하였습니다.

Before vs After

7. 회고 및 정리

@Scheduled 는 인스턴스마다 독립 실행이 기본값입니다. Blue/Green 구조에서 이것이 데드락으로 이어진다는 사실은 직접 겪기 전까지는 실감하기 어려웠습니다.

"트래픽 0 + 정시 cron" 조합은 생각보다 위험합니다. 자정처럼 조용한 시간대는 오히려 두 인스턴스의 락 획득 윈도우가 완벽히 겹쳐 충돌 확률이 높아집니다. 시간 단위 분할이 이 윈도우를 흩뜨리는 데 유효했습니다.

알람 없이는 새벽 장애를 모르고 지나쳤을 것입니다. 모든 추적의 출발점은 Mattermost 로 들어온 FIRING 한 줄이었습니다. 모니터링·알람 체계 자체가 인프라의 일부라는 점을 다시 확인했습니다.

마무리

본 포스팅에서는 자정에만 발생하던 랭킹 스케줄러 Deadlock 의 원인을 추적하고, ShedLock + Redis 분산 락 + 매시간 분할로 해결한 과정을 정리하였습니다.

핵심 요약

• @Scheduled 는 인스턴스마다 독립 실행이라는 기본 동작을 인지할 것.
• 무중단 배포 환경에서는 분산 락으로 단일 실행을 명시적으로 보장 하는 것이 표준 해법.
• "정시 cron + 트래픽 0 시간대" 라는 조합은 동시 출발 확률이 높아 데드락에 취약 — 시간 분할이 함께 가야 안전.
• 알람·리포트 체계가 갖춰져 있을 때, 자정 같은 비활성 시간대 장애도 표면 위로 끌어올릴 수 있음.

'운세 강화게임과 결합된 새로운 경험의 데일리 운세 플랫폼' '아그작' 프로젝트의 시간 단위 랭킹 기능에서, 단일 MySQL 테이블 + ORDER BY 정렬만으로는 실시간성·운영 안정성·과거 조회 세 가지 요구를 동시에 만족시키지 못한다는 한계를 확인하였습니다. 이를 Redis ZSET 기반 실시간 랭킹 + MySQL 스냅샷 보관소 라는 이중 저장 구조로 분리한 의사결정 과정을 정리한 내용입니다.

1. 들어가며

아그작은 사용자가 받은 오늘의 운세 점수 를 기반으로 다음 세 가지 랭킹을 제공합니다.

처음에는 단순하게 Fortune 테이블을 그날 날짜로 조회한 뒤 메모리 정렬로 응답하였으나, 실제 운영 환경에 올린 후 다음과 같은 문제를 마주하였습니다.

1. 매 요청마다 풀스캔 + ORDER BY 발생
2. "내 등수 가져오기" 가 별도 카운트 쿼리로 분기되어 비용이 또 발생
3. 어제·과거 일자 랭킹을 보고 싶은 요구가 생김 — 이때는 운세 데이터가 변경되어도 그 시점의 순위가 보존 되어야 함

본문은 다음 흐름으로 정리합니다.

1. 문제 상황 — 단일 MySQL 정렬 기반 구현의 한계
2. 본질 재정의 — "실시간 랭킹" 과 "스냅샷" 은 다른 자료구조가 필요하다
3. Redis ZSET(실시간) + MySQL Ranking(스냅샷) 이중 저장
4. 동기화 전략 — 시간당 reseed + 매시간 스냅샷
5. 측정 결과
6. 회고 및 정리

2. 문제 상황 — 단일 MySQL 정렬 기반 구현의 한계

초기 구현은 Fortune 테이블을 날짜 기준으로 조회한 뒤, 애플리케이션에서 정렬 + 페이징으로 잘라 응답하는 단순 구조였습니다.

// 의사 코드 — 초기 구현
List<Fortune> fortunes = fortuneRepository.findAllByDateWithMember(today);
return fortunes.stream()
    .sorted(Comparator.comparingInt(Fortune::getTotalScore).reversed())
    .limit(limit)
    .map(this::toRankingItem)
    .toList();

확인된 문제점은 다음과 같습니다.

특히 마지막 항목 — "어제 랭킹은 어제 그대로 보존" + "오늘 랭킹은 점수가 바뀔 때마다 즉시 반영" — 두 요구를 단일 테이블 + 정렬만으로는 깨끗하게 표현하기 어려웠습니다.

3. 본질 재정의 — 실시간 랭킹과 스냅샷은 다른 자료구조가 필요하다

요구사항을 다시 정리하면 다음과 같습니다.

MySQL 은 정형 + 영속 보관에 강하고, ZSET 은 정렬 상태 자체를 자료구조로 들고 있는 구조입니다. 두 영역은 요구되는 갱신 빈도와 정렬 비용이 근본적으로 다릅니다.

→ "오늘 랭킹은 Redis ZSET 으로, 과거 일자는 MySQL 스냅샷 테이블로" 저장소 자체를 분리 하기로 의사결정하였습니다.

4. Redis ZSET (실시간) + MySQL Ranking (스냅샷)

시스템 구성

                점수 변경 이벤트
사용자 → Fortune 갱신 → refreshTodayForMember(memberId)
                            │
                            ▼
                    ┌────────────────┐
                    │  Redis ZSET    │  ← 오늘 랭킹 실시간
                    │  HASH (user)   │
                    └───────┬────────┘
                            │  매시간 59분 55초
                            ▼  rebuildTodaySnapshot()
                    ┌────────────────┐
                    │ MySQL ranking  │  ← 과거 일자 보관
                    └────────────────┘
                            ▲
                            │  매시간 55분 reseed (정합성 보정)
                    ┌───────┴────────┐
                    │ MySQL fortune  │
                    └────────────────┘

Redis 키 설계

// rank:20251119:total      ZSET (memberId → totalScore)
// rank:20251119:original   ZSET (memberId → originalScore)
// rank:20251119:gain       ZSET (memberId → 증가율 %)
// rank:20251119:user:42    HASH (nickname/total/original)

private String key(LocalDate d, String suffix) {
    return "rank:" + d.format(DAY) + ":" + suffix;
}
public String zTotal(LocalDate d)    { return key(d, "total"); }
public String zOriginal(LocalDate d) { return key(d, "original"); }
public String zGain(LocalDate d)     { return key(d, "gain"); }
public String hUser(LocalDate d, Long memberId){ return key(d, "user:"+memberId); }

ZSET 에는 점수만, HASH 에는 닉네임/원본 점수 등 부가 정보 를 분리 저장하여 ZSET 조회 시 메모리·네트워크 비용을 줄였습니다.

RedisInsight 로 실제 키 구조를 보면, rank:20251125 네임스페이스 아래에 total / original / gain 세 ZSET 과 사용자별 HASH 가 함께 적재된 것이 보입니다.

total ZSET 옆에는 동일 날짜의 original (강화 전 점수 기준) ZSET 도 함께 보관되어, 같은 사용자에 대해 정렬 기준만 다른 두 결과를 곧바로 꺼낼 수 있습니다.

점수 변경 → 즉시 반영

운세 점수가 바뀌는 모든 도메인 이벤트(쿠키 굽기·먹기 등) 직후 다음 메서드가 호출됩니다.

public void upsertTodayUser(Long memberId, String nickname,
                            Integer total, Integer original) {
    LocalDate d = today();
    double gain = RankCalculator.increasePct(original, total);

    redis.executePipelined((RedisCallback<Object>) connection -> {
        HashOperations<String, String, String> h = redis.opsForHash();
        ZSetOperations<String, String> z = redis.opsForZSet();

        if (nickname != null) h.put(hUser(d, memberId), "nickname", nickname);
        if (total != null)    h.put(hUser(d, memberId), "total",    String.valueOf(total));
        if (original != null) h.put(hUser(d, memberId), "original", String.valueOf(original));

        if (total != null)    z.add(zTotal(d),    String.valueOf(memberId), total.doubleValue());
        if (original != null) z.add(zOriginal(d), String.valueOf(memberId), original.doubleValue());
        z.add(zGain(d), String.valueOf(memberId), gain);
        return null;
    });
}

ZSET ZADD 는 O(log N) 으로 끝나기 때문에, 점수 갱신 자체가 DB 정렬 한 번보다 압도적으로 가볍습니다.

TOP N 읽기

// 오늘 TOP N — Redis 만으로 끝남
public List<UserRow> readTop(LocalDate d, String zset, int limit) {
    Set<TypedTuple<String>> rows =
        redis.opsForZSet().reverseRangeWithScores(zset, 0, Math.max(0, limit-1));
    // ZSET 결과 + HASH 보강 후 반환
    // ...
}

ZREVRANGE 0 N-1 WITHSCORES 한 번이면 정렬된 상태가 그대로 나옵니다.

"내 등수" 단건 조회

public Integer zrevRank1Base(String zset, long memberId) {
    if (!redis.hasKey(zset)) return null;
    Long zero = redis.opsForZSet().reverseRank(zset, String.valueOf(memberId));
    return zero == null ? null : (int)(zero + 1);
}

ZREVRANK 는 O(log N) 으로 등수를 바로 반환합니다. 별도 카운트 쿼리·메모리 정렬 없이 끝납니다.

5. 동기화 전략 — 시간당 reseed + 매시간 스냅샷

Redis 가 빠르고 가볍지만, 단일 실패점이 되면 곤란 합니다. 따라서 두 가지 동기화 잡을 두어 정합성·내구성을 함께 챙겼습니다.

시간당 Reseed (MySQL → Redis)

@Scheduled(cron = "0 55 * * * *", zone = "Asia/Seoul")
@SchedulerLock(name = "rankingReseed", lockAtMostFor = "PT4M", lockAtLeastFor = "PT10S")
public void hourlyReseedRedis() {
    rankingService.reseedRedisFromMysqlToday();
    rankingService.pruneTodayOrphans();
}

@Transactional
public void reseedRedisFromMysqlToday() {
    LocalDate today = redisStore.today();
    var fortunes = mysqlStore.fortunes(today);
    if (fortunes.isEmpty()) return;

    // ZSET 사이즈와 MySQL 행 수가 다르면 리씨드
    Long zcard = redisStore.zcard(redisStore.zTotal(today));
    boolean needsReseed = (zcard == null) || (zcard.intValue() != fortunes.size());
    if (!needsReseed) return;

    var rows = fortunes.stream().map(...).toList();
    try {
        redisStore.bulkUpsertTodayUsers(rows);
    } catch (Exception e) {
        log.warn("Redis reseed failed: {}", e.getMessage());
    }
}

핵심 포인트:

• ZCARD 와 MySQL 행 수가 같으면 noop — 매시간 강제로 갈아엎지 않음
• 다르면 bulk upsert 로 ZSET·HASH 한 번에 채움 (Redis 파이프라이닝)
• 실패해도 예외를 그대로 던지지 않고 로그만 — Redis 가 잠깐 문제여도 다음 요청에서 회복

매시간 스냅샷 (Redis → MySQL ranking)

@Scheduled(cron = "55 59 * * * *", zone = "Asia/Seoul")
@SchedulerLock(name = "rankingSnapshot", lockAtMostFor = "PT4M", lockAtLeastFor = "PT20S")
public void todayRebuild() {
    rankingService.rebuildTodaySnapshot();
}

@Transactional
public void rebuildTodaySnapshot() {
    LocalDate today = redisStore.today();
    var all = redisStore.readTop(today, redisStore.zTotal(today), Integer.MAX_VALUE);
    if (all == null || all.isEmpty()) {
        mysqlStore.replaceTodaySnapshot(today, List.of());
        return;
    }

    // 탈퇴 회원 등 고아 데이터 제거
    Set<Long> ids = all.stream().map(UserRow::memberId).collect(Collectors.toSet());
    Set<Long> alive = mysqlStore.existingMemberIds(ids);

    int rank = 1;
    List<Ranking> rows = new ArrayList<>(alive.size());
    for (var r : all) {
        if (!alive.contains(r.memberId())) continue;
        rows.add(Ranking.builder()
            .member(mysqlStore.refMember(r.memberId()))
            .date(today).rankNo(rank++)
            .totalScore(r.total()).originalTotalScore(r.original())
            .build());
    }
    mysqlStore.replaceTodaySnapshot(today, rows);
}

스냅샷 단계에서 회원 탈퇴 등으로 발생한 Redis 고아 데이터 를 정리하는 로직을 함께 둠으로써, ZSET 이 시간이 지날수록 부풀어 오르는 문제를 막았습니다.

스냅샷이 끝난 직후 MySQL ranking 테이블을 보면, 해당 일자의 ZSET 결과가 (member_id, date, rank_no, total_score, original_total_score) 컬럼에 rank_no 1번부터 차례대로 영속 저장되어 있는 것을 확인할 수 있습니다.

이 시점 이후로는 Fortune 의 점수가 다시 갱신되더라도 이미 영속 저장된 과거 일자 랭킹은 더 이상 흔들리지 않습니다. 어제 1등이었던 사용자는 오늘 점수가 어떻게 변하든 어제 시점에서는 그대로 1등입니다.

참고 — 두 스케줄러는 모두 @SchedulerLock 으로 보호됩니다. Blue/Green 두 컨테이너가 떠 있어도 한쪽만 실제 실행됩니다. 자세한 배경은 별도 포스팅 새벽 랭킹 스케줄러 Deadlock 트러블슈팅 에 정리하였습니다.

읽기 fallback

Redis 가 아예 죽어 있는 상황을 대비하여 읽기 경로에는 fallback 을 두었습니다.

public RankingListDto getTodayTopN(int limit) {
    LocalDate d = redisStore.today();
    try {
        var total    = redisStore.readTop(d, redisStore.zTotal(d),    limit);
        var original = redisStore.readTop(d, redisStore.zOriginal(d), limit);
        var gain     = redisStore.readTop(d, redisStore.zGain(d),     limit);

        if (모두 비어있으면) return getSnapshotTopN(d, limit);   // MySQL 스냅샷
        return /* Redis 결과 가공 */;
    } catch (Exception e) {
        return getSnapshotTopN(d, limit);                       // MySQL 스냅샷
    }
}

오늘 랭킹이라도 Redis 에 데이터가 없거나 예외가 나면, 마지막 정시 스냅샷 으로 자동 대체됩니다. 사용자 입장에서는 잠시 갱신이 멈춘 것처럼 보이지만, 5xx 에러는 발생하지 않습니다.

6. 측정 결과

참고 본 프로젝트는 실 사용자 트래픽이 큰 상용 서비스가 아닌 개발·배포 단계의 자율 프로젝트이므로, 아래 수치는 EFK 수집 로그와 MySQL Slow Query 카운트, 자체 부하 테스트 기반 입니다.

Before vs After (랭킹 응답 경로)

운영 모니터링 — Slow Query 0건 유지

런칭 직후에는 MySQL QPS 가 일시적으로 300~500 까지 튀는 구간이 있었으나, 이번 저장소 분리 이후 일상 QPS 가 한 자리 수까지 내려갔고, EFK 기반 일별 리포트에서 추적한 Slow Query 카운트는 0건 으로 유지되었습니다.

또한 EFK 파이프라인을 통해 일별·주별 로그 분포를 Kibana 대시보드에서도 확인하였습니다.

사용자 체감

• 게임을 통해 점수를 강화한 직후 랭킹 페이지에서 즉시 반영 되는 모습 확인 (캐시 TTL 대기 X)
• 과거 일자(전날·전주) 랭킹은 그 시점 그대로 보존 — Fortune 데이터가 갱신되어도 흔들리지 않음

7. 회고 및 정리

같은 "랭킹" 이라도 요구가 다르면 저장소를 분리해야 합니다. 갱신 빈도·보존 요구·정렬 비용이 다른 두 도메인을 단일 테이블에 끼워 맞추려 했던 것이 비용을 키운 원인이었습니다.

ZSET 은 "정렬 결과를 자료 구조로 갖는 것" 입니다. ORDER BY 가 매번 정렬 비용을 지불하는 반면, ZSET 은 ZADD 시점에 O(log N) 으로 정렬 상태를 유지합니다. ZREVRANGE / ZREVRANK 는 그 상태를 그대로 꺼내기만 합니다.

fallback + reseed 없는 Redis 1차 저장소는 단일 장애점입니다. 읽기 fallback(MySQL 스냅샷 대체), 시간당 reseed(정합성 자동 회복), 고아 데이터 prune — 세 가지를 함께 뒀기 때문에 운영 부담 없이 유지할 수 있었습니다.

마무리

본 포스팅에서는 랭킹 데이터를 Redis ZSET 실시간 + MySQL 스냅샷 보관 두 저장소로 분리한 의사결정 과정을 정리하였습니다.

핵심 요약

• 점수 갱신 즉시 반영은 ZSET ZADD (O(log N)).
• TOP N 응답은 ZREVRANGE 단건 호출 로 정렬 비용 0.
• "내 등수" 는 ZREVRANK 로 별도 쿼리 없이.
• 과거 일자는 MySQL ranking 스냅샷 으로 영속 보존.

도서 쇼핑몰 프로젝트의 개발 단계에서 검색 응답 시간이 평균 1,200ms 수준으로 측정되어, MySQL LIKE 기반 구현을 Elasticsearch로 전환한 과정을 정리한 내용입니다.

1. 들어가며

도서 쇼핑몰 프로젝트를 개발하면서 마주한 검색 성능 문제와 그 해결 과정을 정리한 내용입니다.

해당 프로젝트는 실제 사용자에게 운영되는 서비스가 아니라 개발 및 배포 단계까지만 진행한 프로젝트였습니다. 그러나 개발 단계에서 검색 기능을 테스트하던 중 응답 시간이 평균 1,200ms에 달하는 것을 확인하였고, 이는 정상적인 사용이 어려운 수준이라 판단되어 개선 작업을 진행하게 되었습니다.

본문에서는 다음과 같은 흐름으로 정리하였습니다.

1. 문제 상황 진단 및 기존 구현 분석
2. B-Tree 인덱스 추가 시도와 실패
3. MySQL Full-Text Search 검토와 한계
4. Elasticsearch 도입 및 설계 의사결정
5. 측정 결과 및 회고

2. 문제 상황 진단 및 기존 구현 분석

개발 환경에서 키워드 검색 부하 테스트를 진행한 결과, 다수의 SLOW QUERY 로그가 출력되었습니다.

WARN  [nio-8080-exec-4]
[SLOW QUERY] SELECT DISTINCT b FROM Book b LEFT JOIN ...
WHERE b.title LIKE '%데이터베이스%' duration=1525ms type=FULL_TABLE_SCAN

30분간 60건 요청 기준으로 다음과 같은 수치가 측정되었습니다.

• 평균 응답 시간 : 1,187ms
• Slow Query (≥1,500ms) : 18건 / 60건 (30%)

검색 한 번에 1.5초가 소요되는 빈도가 30%에 달하였고, 이는 사용자 입장에서 정상적인 사용이 불가능한 수준입니다.

기존 구현 코드

기존 검색 기능은 QueryDSL 의 .contains() 메서드를 사용하여 구현되어 있었습니다.

BooleanBuilder builder = new BooleanBuilder();
builder.and(
    qBook.title.contains(keyword)            // → LIKE %keyword%
    .or(qBook.description.contains(keyword))
    .or(qContributor.name.contains(keyword))
    .or(qTag.name.contains(keyword))
);

QueryDSL 의 .contains() 는 내부적으로 LIKE %keyword% 로 변환됩니다. 또한 검색 시 4개 테이블에 LEFT JOIN 이 걸리는 구조였습니다.

확인된 문제점을 정리하면 다음과 같습니다.

3. 첫 번째 시도 — B-Tree 인덱스 추가

가장 단순한 접근 방법인 인덱스 추가부터 시도하였습니다.

CREATE INDEX idx_book_title       ON book (title);
CREATE INDEX idx_book_description ON book (description(100));

인덱스 추가 후 EXPLAIN을 통해 실행 계획을 확인하였습니다.

+----+------+------+------+----------+-------------+
| id | type | key  | rows | filtered | Extra       |
+----+------+------+------+----------+-------------+
|  1 | ALL  | NULL | 9821 |    11.11 | Using where |  ← Full Table Scan
+----+------+------+------+----------+-------------+

type 컬럼이 여전히 ALL 로 출력되는 것을 확인할 수 있었습니다. 즉, 인덱스를 추가하였음에도 Full Table Scan 이 발생하고 있는 상황입니다.

원인 분석 LIKE '%keyword%' 와 같이 검색어 앞에 와일드카드가 위치할 경우, B-Tree 인덱스를 사용할 수 없습니다. B-Tree 는 데이터를 정렬된 상태로 저장하고 앞 글자부터 순차 탐색하는 구조이기 때문에, 시작점이 정해지지 않으면 전체 스캔으로 처리됩니다.

따라서 인덱스 추가만으로는 본 문제를 해결할 수 없다고 판단하였습니다.

4. 두 번째 시도 — MySQL Full-Text Search

B-Tree 인덱스로 해결이 어렵다는 점을 확인한 후, MySQL 의 Full-Text Search 기능을 검토하였습니다.

ALTER TABLE book ADD FULLTEXT INDEX ft_title_desc (title, description);

SELECT * FROM book
WHERE MATCH(title, description) AGAINST('자바' IN BOOLEAN MODE);

쿼리 자체의 응답 시간은 LIKE 방식보다 빨라졌으나, 두 가지 본질적인 한계가 있었습니다.

특히 '자바' 키워드로 검색하였을 때 '자바스크립트' 도서는 매칭되지만, '김영한' 저자의 도서는 매칭되지 않는 현상이 발생하였습니다. 저자명은 별도 테이블에 정규화되어 있어 FTS 만으로는 처리할 수 없는 구조였기 때문입니다.

이 시점에서 다음과 같은 의문이 들었습니다.

이 문제가 정말 MySQL 의 영역에서 해결할 수 있는 문제인가?

두 차례의 시도가 모두 만족스러운 결과를 내지 못하였기에, 문제의 본질을 다시 분석하였습니다.

MySQL 은 정형 데이터를 관계형 모델로 저장하는 데 최적화된 데이터베이스입니다. 반면, 키워드 기반 전문 검색은 본질적으로 비정형이며 관련도 기반 정렬이 필요합니다. 두 영역은 요구하는 저장 구조와 처리 방식이 근본적으로 다릅니다.

검색은 비정형(여러 필드 동시 매칭)이고 관련도 순 정렬이 필요하지만, RDB 는 정형(컬럼 단위 조건)에 최적화되어 있고 관련도를 계산할 구조가 없습니다. 또한 한국어 형태소 분석 역시 MySQL 은 플러그인 없이 지원하지 않습니다.

쿼리 튜닝만으로는 위 구조적 불일치가 해소되지 않는다고 판단하였고, 검색 전용 저장소를 분리하는 방향으로 의사결정을 진행하였습니다.

5. Elasticsearch 도입 및 설계

시스템 구성

┌─────────────┐   Logstash   ┌──────────────────┐
│   MySQL DB  │ ───────────▶ │  Elasticsearch    │
│ (원본 데이터)│  10초 주기   │   books index     │
└─────────────┘  JDBC sync   └──────┬───────────┘
                                    │
              ┌────────────┐        │  검색 쿼리
              │   Spring   │◀───────┘
              │    Boot    │
              │            │──▶ Kibana 모니터링
              └────────────┘      :5601

원본 데이터는 그대로 MySQL 에 저장하되, 검색 전용 데이터를 Elasticsearch 에 별도로 색인하는 구조입니다. 두 저장소는 Logstash JDBC 를 통해 주기적으로 동기화됩니다.

동기화 전략 — Logstash JDBC

데이터 동기화 방식을 두 가지 후보 중에서 검토하였습니다.

도서 등록·수정은 관리자만 수행하는 도메인 특성상 실시간성보다는 안정성과 코드 응집도가 중요하다고 판단하여 Logstash 10초 주기 동기화를 선택하였습니다.

input {
  jdbc {
    schedule  => "*/10 * * * * *"
    statement => """
      WITH RECURSIVE category_hierarchy AS ( ... )
      SELECT
        b.book_id, b.title AS book_title,
        (SELECT JSON_ARRAYAGG(JSON_OBJECT('id', c.id, 'name', c.name, 'role', cr.name))
         FROM book_contributor bc JOIN contributor c ...
         WHERE bc.book_id = b.book_id) AS book_contributor,
        ...
      FROM book b LEFT JOIN publisher p ON b.publisher_id = p.publisher_id
      WHERE b.is_active = true
    """
  }
}
output {
  elasticsearch {
    index         => "books"
    document_id   => "%{[@metadata][_id]}"
    doc_as_upsert => true
    action        => "update"
  }
}

JSON_ARRAYAGG 함수를 사용하여 nested 필드(기여자, 태그, 카테고리)를 ES 문서 형식으로 변환한 뒤 색인하는 방식입니다.

매핑 설계 — nested vs object

해당 부분은 개발 과정에서 시행착오를 겪은 부분입니다. 처음에는 object 타입으로 매핑을 설계하였습니다.

"book_contributor": [
  { "name": "김영한", "role": "저자" },
  { "name": "박성철", "role": "역자" }
]

그러나 ES 의 object 타입은 내부적으로 평탄화(flatten)됩니다.

"name": ["김영한", "박성철"]
"role": ["저자", "역자"]

이로 인해 객체 간 쌍(pair) 관계가 보존되지 않아, "김영한 역자" 와 같은 잘못된 매칭이 발생하였습니다. 이를 해결하기 위해 nested 타입으로 변경하였으나, 인덱스 매핑 변경은 전체 재색인을 수반하므로 작지 않은 비용이 발생하였습니다.

참고 Elasticsearch 에서 매핑은 한번 설정되면 일부 속성을 제외하고는 변경이 불가능합니다. 타입 변경은 사실상 인덱스를 새로 만들고 데이터를 다시 색인해야 하므로, 초기 설계 단계에서 검색 케이스를 충분히 정리한 뒤 매핑을 결정하는 것이 좋습니다.

Nori 분석기 decompound_mode 튜닝

기본 Nori 분석기를 그대로 사용할 경우 복합어 처리에 문제가 발생합니다.

"tokenizer": "nori_tokenizer"
// "스프링부트" → ["스프링부트"]   (단일 토큰)

위 설정에서는 사용자가 '스프링' 으로 검색하였을 때 '스프링부트' 도서가 매칭되지 않습니다. decompound_mode 옵션을 mixed 로 설정하면 원형과 분해된 형태소를 모두 보존합니다.

"tokenizer": {
  "type": "nori_tokenizer",
  "decompound_mode": "mixed"
}
// "스프링부트" → ["스프링부트", "스프링", "부트"]

해당 설정 변경 이후 복합어에 대한 검색 정확도가 크게 향상되었습니다.

검색 구현 — 정렬 분기

List<Map.Entry<String, String>> sortCriteria = switch (sort) {
    case "popularity"    -> List.of(Map.entry("book_likes", "desc"), Map.entry("book_views", "desc"));
    case "newest"        -> List.of(Map.entry("book_published_at", "desc"));
    case "lowest_price"  -> List.of(Map.entry("book_selling_price", "asc"));
    case "rating"        -> List.of(Map.entry("book_rating_avg", "desc"));
    case "reviews"       -> List.of(Map.entry("book_review_count", "desc"));
    default              -> List.of();  // relevance: ES score 기본 정렬
};

검색 구현 — multi_match 및 nested 쿼리

// 제목^10 · 제목.ngram^3 · 설명^3 · 출판사^2 가중치 적용
bq.should(sq -> sq.multiMatch(mm -> mm
    .fields("book_title^10", "book_title.ngram^3",
            "book_title.jaso", "book_title.synonym",
            "book_desc^3", "book_desc.ngram",
            "book_publisher^2", "book_publisher.ngram")
    .query(keyword)));

// nested: 카테고리 검색
bq.should(sq -> sq.nested(n -> n.path("book_category")
    .query(cq -> cq.multiMatch(mm -> mm
        .fields("book_category.name^3", "book_category.name.ngram")
        .query(keyword)))));

^10, ^3 와 같은 표기는 가중치(boost)를 의미하며, 제목에서 매칭되었을 때 설명에서 매칭되었을 때보다 점수가 높게 산정됩니다.

검색 구현 — ES 호출 및 결과 매핑

ES 응답에 전체 건수(total)가 포함되어 있으므로, MySQL 구현 시 필요했던 별도 count 쿼리가 불필요합니다.

6. 개선 결과

참고 본 프로젝트는 실제 사용자 트래픽을 받지 않은 개발·배포 단계의 프로젝트였기에, 개발 진행 당시 측정값을 Kibana 대시보드로 그대로 재현하는 것은 어려웠습니다. 따라서 아래 Kibana 대시보드 이미지는 당시 로그 기반 측정값을 시각화 형태로 재구성한 자료이며, 실제 수치는 응용 서버 로그(duration, took) 기반으로 검증한 값입니다.

Kibana 대시보드 (재구성)

• 평균 took : 275ms (개선 전 ~1,200ms)
• P90 : 371ms / P99 : 453ms
• 약 4.4배 개선
• 일별 요청 수가 증가하여도 응답 시간이 안정적으로 유지됨

Dev Tools 응답 확인

"took": 243 은 ES 내부 처리 시간을 의미하며, Spring Boot 레이어를 포함한 전체 응답 시간은 약 275ms 수준입니다.

Before vs After 비교

개선 후 응용 서버 로그

INFO  [nio-8080-exec-1]
[ES] searchByKeyword keyword='디자인패턴' duration=397ms took=367ms

INFO  [nio-8080-exec-2]
[ES] searchByKeyword keyword='디자인패턴' sort=lowest_price duration=262ms took=223ms

WARN 레벨의 SLOW QUERY 로그가 출력되지 않으며, slow_queries 는 0건입니다.

7. 회고 및 정리

LIKE '%keyword%' 는 인덱스로 풀 수 없습니다. B-Tree 인덱스 전략과 무관하게 Full Table Scan 이 강제됩니다. EXPLAIN type: ALL 한 줄이 그 사실을 확인해 줬고, 이후 모든 의사결정의 출발점이 되었습니다.

ES 도입 비용은 띄우는 것이 아니라 매핑·튜닝에 있습니다. nested vs object 오결정 시 전체 재색인, Nori decompound_mode 파라미터 튜닝, 동기화 전략 선택 — 시간이 걸리는 부분은 모두 여기에 집중됐습니다.

본질은 성능 개선이 아니라 저장 구조 분리였습니다. 같은 쿼리를 빠르게 만든 것이 아니라, 비정형 검색·관련도·형태소 분석이라는 요구사항에 맞는 저장소로 책임을 옮긴 결과입니다.

마무리

이번 포스팅에서는 MySQL LIKE 기반 검색의 한계를 분석하고, Elasticsearch 도입을 통해 평균 응답 시간을 약 4.4배 개선한 과정을 정리하였습니다.

[BOJ-22954] 그래프 트리 분할

문제 해결 아이디어

BFS로 연결 컴포넌트와 스패닝 트리를 동시에 구성하고, 불가능 조건을 걸러낸 뒤 분할!

조건

• 그래프에서 간선 삭제만으로 서로 다른 크기의 트리 2개로 분할
• 각 트리는 연결 그래프여야 하고, 정점 및 간선 공유 불가
• N ≤ 100,000, M ≤ 200,000

불가능 조건

BFS 스패닝 트리 접근

• BFS 탐색으로 각 연결 컴포넌트의 스패닝 트리 자동 구성
• parent[v], parentEdge[v] : BFS 트리에서 v의 부모 노드와 연결 간선 번호
• 루트 노드는 parent[root] = -1

분할 전략

케이스 1. 컴포넌트 1개 (연결 그래프)

• BFS 스패닝 트리에서 리프 노드 하나를 분리 → 크기 1 + (N-1)
• 리프 조건: parent[v] != -1 (루트 제외) && childCount[v] == 0

케이스 2. 컴포넌트 2개 (크기가 다름)

• 각 컴포넌트의 BFS 스패닝 트리를 그대로 출력

코드

import java.util.*;
import java.io.*;

public class BOJ_22954 {
    static int N, M;
    static List<List<int[]>> graph;
    static int[] parent;
    static int[] parentEdge;
    static boolean[] visited;

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());

        N = Integer.parseInt(st.nextToken());
        M = Integer.parseInt(st.nextToken());

        graph = new ArrayList<>();
        for (int i = 0; i <= N; i++) {
            graph.add(new ArrayList<>());
        }

        for (int i = 1; i <= M; i++) {
            st = new StringTokenizer(br.readLine());
            int u = Integer.parseInt(st.nextToken());
            int w = Integer.parseInt(st.nextToken());
            graph.get(u).add(new int[]{w, i});
            graph.get(w).add(new int[]{u, i});
        }

        parent = new int[N + 1];
        parentEdge = new int[N + 1];
        visited = new boolean[N + 1];
        Arrays.fill(parent, -1);
        Arrays.fill(parentEdge, -1);

        List<List<Integer>> components = new ArrayList<>();
        for (int i = 1; i <= N; i++) {
            if (!visited[i]) {
                List<Integer> comp = new ArrayList<>();
                bfs(i, comp);
                components.add(comp);
            }
        }

        int numComp = components.size();
        boolean impossible = N <= 2
                || numComp >= 3
                || (numComp == 2 && components.get(0).size() == components.get(1).size());

        if (impossible) {
            System.out.println(-1);
            return;
        }

        if (numComp == 1) {
            List<Integer> all = components.get(0);
            int[] childCount = new int[N + 1];
            for (int node : all) {
                if (parent[node] != -1) childCount[parent[node]]++;
            }

            int leaf = -1;
            for (int node : all) {
                if (parent[node] != -1 && childCount[node] == 0) {
                    leaf = node;
                    break;
                }
            }

            System.out.println("1 " + (N - 1));
            System.out.println(leaf);

            StringBuilder sbV = new StringBuilder();
            StringBuilder sbE = new StringBuilder();
            for (int node : all) {
                if (node == leaf) continue;
                if (sbV.length() > 0) sbV.append(' ');
                sbV.append(node);
                if (parent[node] != -1) {
                    if (sbE.length() > 0) sbE.append(' ');
                    sbE.append(parentEdge[node]);
                }
            }
            System.out.println(sbV);
            System.out.println(sbE);
        } else {
            List<Integer> c1 = components.get(0);
            List<Integer> c2 = components.get(1);

            System.out.println(c1.size() + " " + c2.size());
            printTree(c1);
            printTree(c2);
        }
    }

    static void printTree(List<Integer> comp) {
        StringBuilder sbV = new StringBuilder();
        StringBuilder sbE = new StringBuilder();
        for (int node : comp) {
            if (sbV.length() > 0) sbV.append(' ');
            sbV.append(node);
            if (parent[node] != -1) {
                if (sbE.length() > 0) sbE.append(' ');
                sbE.append(parentEdge[node]);
            }
        }
        System.out.println(sbV);
        System.out.println(sbE);
    }

    static void bfs(int start, List<Integer> comp) {
        Queue<Integer> q = new LinkedList<>();
        q.offer(start);
        visited[start] = true;
        comp.add(start);

        while (!q.isEmpty()) {
            int u = q.poll();
            for (int[] e : graph.get(u)) {
                int next = e[0];
                int eid = e[1];
                if (!visited[next]) {
                    visited[next] = true;
                    parent[next] = u;
                    parentEdge[next] = eid;
                    q.offer(next);
                    comp.add(next);
                }
            }
        }
    }
}

예제 풀이

• N=5, M=5

그래프 구성:

BFS 스패닝 트리 (시작: 1):

리프 탐색:

출력 결과:

트리2 간선: parentEdge[3]=2 (1↔3), parentEdge[4]=4 (3↔4), parentEdge[5]=5 (4↔5)

sizes: 1 ≠ 4 → 정답

[BOJ-24042] 횡단보도

문제 해결 아이디어

시간 그래프에서 다음 파란불까지 대기 시간을 간선 가중치로 바꾼 다익스트라

조건

• 주기 M분, 매 분마다 딱 하나의 횡단보도만 파란불
• 신호 i (0-indexed): t ≡ i (mod M) 일 때 파란불 → 그 순간에 건너기 시작해야 함
• 현재 시각 t에서 period p 횡단보도를 이용하려면 t' ≡ p (mod M)인 가장 가까운 미래 t'까지 대기
• N, M이 크므로 최대 시간 ≈ N × M → long 필수

다익스트라 접근

• times[v] : 1번 지역에서 v까지 도달하는 최소 시간 (long 배열)
• 간선 가중치 = 다음 파란불까지 대기 시간 + 1 (건너는 시간)
• 현재 시각 t에서 period p 횡단보도를 이용할 때 도착 시각:

대기 시간 계산

curP = t % M (현재 주기 내 위치)

코드

import java.util.*;
import java.io.*;

public class BOJ_24042 {
    static int N;
    static int M;
    static List<List<Crosswalk>> graph = new ArrayList<>();
    static long[] times;

    static class Crosswalk {
        int nx;
        int p;

        Crosswalk (int nx, int p) {
            this.nx = nx;
            this.p = p;
        }
    }

    static class Node {
        int x;
        long t;

        Node (int x, long t) {
            this.x = x;
            this.t = t;
        }
    }

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());

        N = Integer.parseInt(st.nextToken());
        M = Integer.parseInt(st.nextToken());

        for (int i = 0; i <= N; i++) {
            graph.add(new ArrayList<>());
        }

        for (int i = 0; i < M; i++) {
            st = new StringTokenizer(br.readLine());

            int x = Integer.parseInt(st.nextToken());
            int nx = Integer.parseInt(st.nextToken());

            graph.get(x).add(new Crosswalk(nx, i));
            graph.get(nx).add(new Crosswalk(x, i));
        }

        times = new long[N+1];
        Arrays.fill(times, Long.MAX_VALUE);
        times[1] = 0;

        PriorityQueue<Node> pq = new PriorityQueue<>(Comparator.comparingLong((Node n) -> n.t)
                                                         .thenComparingInt((Node n) -> n.x));
        pq.add(new Node(1, 0));

        while (!pq.isEmpty()) {
            Node cur = pq.poll();

            if (cur.t > times[cur.x]) continue;

            for (Crosswalk nc : graph.get(cur.x)) {
                int curP = (int)(cur.t % M);
                long nt = cur.t + 1;

                if (curP < nc.p) {
                    nt += nc.p - curP;
                } else if (curP > nc.p) {
                    nt += (M - curP) + nc.p;
                }

                if (nt < times[nc.nx]) {
                    times[nc.nx] = nt;
                    pq.add(new Node(nc.nx, nt));
                }
            }
        }

        System.out.println(times[N]);
    }
}

예제 풀이

• N=4, M=5
• 신호 스케줄 (0-indexed period):

다익스트라 시뮬레이션

times[4] = 4 → 정답: 4

1번에서 4번으로 직접 연결된 횡단보도(4↔1, period=3)를 t=3에 이용하는 것이 최적

[BOJ-6236] 용돈 관리

문제 해결 아이디어

인출 금액 K에 대해 이진 탐색, check 함수로 M번 이내 인출 가능 여부 판단!

조건

• 정확히 M번 인출 (부족하면 강제, 남아도 선택적으로 재인출 가능)
• 하루치 금액보다 K가 작으면 불가능
• 최소 인출 횟수 ≤ M 이면, 나머지는 임의로 재인출하여 M번 맞출 수 있음

이진 탐색 접근

• 탐색 범위: l = max(pay[i]) ~ r = sum(pay[i])
  • 최소: 하루치는 감당해야 하므로 최댓값
  • 최대: 한 번에 전부 뽑는 경우
• 최소 K 탐색 → check(mid) 참이면 ans = mid, 더 작은 값 탐색 (r = mid - 1)

check 함수

• K원으로 시작, 잔액이 당일 금액보다 부족하면 재인출 (cnt++)
• 최종 인출 횟수 cnt ≤ M 이면 가능

코드

import java.util.*;
import java.io.*;

public class BOJ_6236 {
    static int N;
    static int M;
    static int[] pay;
    static int sum = 0;
    static int max = 0;

    private static boolean check(int k) {
        int cnt = 1;
        int remain = k;

        for (int i = 0; i < N; i++) {
            if (remain < pay[i]) {
                cnt += 1;
                remain = k;
            }
            remain -= pay[i];
        }
        return cnt <= M;
    }

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());

        N = Integer.parseInt(st.nextToken());
        M = Integer.parseInt(st.nextToken());
        pay = new int[N];

        for (int i = 0; i < N; i++) {
            pay[i] = Integer.parseInt(br.readLine().strip());
            sum += pay[i];
            max = Math.max(max, pay[i]);
        }

        int l = max;
        int r = sum;
        int mid = (l + r) / 2;
        int ans = 0;

        while (l <= r) {
            if (check(mid)) {
                ans = mid;
                r = mid - 1;
            } else {
                l = mid + 1;
            }
            mid = (l + r) / 2;
        }

        System.out.println(ans);
    }
}

예제 풀이

• N=7, M=5
• pay = [100, 400, 300, 100, 500, 101, 400]
• max = 500, sum = 1901
• 이진 탐색 범위: l=500, r=1901

K=500 으로 check 시뮬레이션

cnt = 5 ≤ M(5) → 가능

이진 탐색으로 K=500보다 작은 값도 탐색하지만 모두 불가능 → ans = 500

[BOJ-16235] 나무 재테크

문제 해결 아이디어

시뮬레이션인데 이제 자료구조를 곁들인..🥲

조건

1 ≤ $N$ ≤ 10 1 ≤ $M$ ≤ $N^2$ 1 ≤ $K$ ≤ 1,000 1 ≤ $A[r][c]$ ≤ 100 1 ≤ 입력으로 주어지는 나무의 나이 ≤ 10 입력으로 주어지는 나무의 위치는 모두 서로 다름

주어진 조건의 크기가 별로 크지 않아서 단순 시뮬레이션이라고 생각했었다.. (시간초과 어마무시..)

LinkedList 접근

• Tree 리스트를 매년 정렬 하는데 O(n log n) 걸린다.. 그래서 처음 입력받은 나무들 한 번만 정렬
• 가을에 맨 앞에 나이 1인 친구들을 삽입하면 정렬할 필요가 없기 때문에, 맨 앞 삽입이 O(1)인 LinkedList 사용 (ArrayList는 O(n))

봄

• Tree 리스트 순회하면서 해당 땅에 양분이 나무 나이보다 크거나 같으면 한 살 더 먹고, 아니면 죽는다..!

여름

• Tree 리스트 순회시 Iterator를 사용하면 한 번 순회 만으로 바로 Tree리스트에 죽은 나무들을 제거해준다!! (반복 횟수 줄이는데 용이)

가을

• Tree 리스트 순회 하면서, 번식하여 생긴 한 살인 애기 나무들을 바로 Tree 리스트에 삽입하면 forEach로 순회해서 문제가 있고, 또 정렬해줘야한다..!
• 그래서 따로 애기들용 Tree 리스트에다가 삽입 후, addAll 메소드로 기존 Tree 리스트에 맨 앞에 삽입 (정렬 필요x)

겨울

• 그저 양분 공급

코드

import java.io.*;
import java.util.*;

public class Solution16235 {
    static int N, M, K;
    static int[][] A, B;
    static int x, y, z;
    static List<Tree> trees;
    static int[] dx = {0, 0, 1, -1, 1, 1, -1, -1};
    static int[] dy = {1, -1, 0, 0, 1, -1, 1, -1};
    static int treeCnt;

    static class Tree implements Comparable<Tree> {
        int x;
        int y;
        int age;
        boolean isAlive;

        Tree(int x, int y, int age, boolean isAlive) {
            this.x = x;
            this.y = y;
            this.age = age;
            this.isAlive = isAlive;
        }

        @Override
        public int compareTo(Tree o) {
            return Integer.compare(this.age, o.age);
        }
    }

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());

        N = Integer.parseInt(st.nextToken()); // N*N 땅
        M = Integer.parseInt(st.nextToken()); // M 그루
        K = Integer.parseInt(st.nextToken()); // K 년 후
        A = new int[N][N]; // 겨울에 추가될 양분
        B = new int[N][N]; // 내 땅 양분


        trees = new LinkedList<>();
        treeCnt = 0;

        for (int i = 0; i < N; i++) {
            st = new StringTokenizer(br.readLine());
            for (int j = 0; j < N; j++) {
                A[i][j] = Integer.parseInt(st.nextToken());
                B[i][j] = 5;
            }
        }

        for (int i = 0; i < M; i++) {
            st = new StringTokenizer(br.readLine());
            x = Integer.parseInt(st.nextToken()); // 나무 x좌표
            y = Integer.parseInt(st.nextToken()); // 나무 y좌표
            z = Integer.parseInt(st.nextToken()); // 나무 나이 z
            trees.add(new Tree(x-1, y-1, z, true));
        }
        Collections.sort(trees);

        for (int k = 1; k <= K; k++) { // 나이별 나무 (오름차순)

            // 봄
            for (Tree tree : trees) {
                if (B[tree.x][tree.y] >= tree.age && tree.isAlive) {
                    B[tree.x][tree.y] -= tree.age;
                    tree.age += 1;
                } else {
                    tree.isAlive = false;
                }
            }

            // 여름
            Iterator<Tree> iter = trees.iterator();
            while (iter.hasNext()) {
                Tree tree = iter.next();
                if (!tree.isAlive) {
                    B[tree.x][tree.y] += tree.age / 2; // 죽은나무 양분
                    iter.remove();
                }
            }

            // 가을
            List<Tree> newTrees = new LinkedList<>(); 
            for (Tree tree : trees) {
                if (tree.age % 5 == 0 && tree.isAlive) {
                    for (int d = 0; d < 8; d++) {
                        int nx = tree.x + dx[d];
                        int ny = tree.y + dy[d];
                        if (nx < 0 || ny < 0 || nx >= N || ny >= N) continue;
                        newTrees.add(0, new Tree(nx, ny, 1, true));
                    }
                }
            }
            trees.addAll(0, newTrees);

            // 겨울
            for (int i = 0; i < N; i++) {
                for (int j = 0; j < N; j++) {
                    B[i][j] += A[i][j];
                }
            }
        }

        for (Tree tree : trees) {
            if (tree.isAlive) {
                treeCnt += 1;
            }
        }
        System.out.println(treeCnt);
    }
}

[SWEA-1249] 보급로

문제 해결 아이디어

2차원 배열 지도의 거리를 Node 객체 좌표 별로 갱신하는게 🦵킥! 전형적인 다익스트라

조건

• 방문 거리 고려하지 않고, 오직 복구 비용 (가중치)민 고려
• 시작점과 도착점이 정해져있음

Dijkstra 접근

• Node 객체를 생성하여 x,y 좌표 와 dist 시작점 부터 누적 거리를 저장
• dist[][] 2차원 배열 Integer.MAX_VALUE로 초기화

PriorityQueue 활용

• PriorityQueue에 Node의 dist 오름차순으로 정렬 (짧은 거리)

• 방문 배열 없이, 이미 해당 좌표까지 더 짧은 거리가 저장되어 있으면 contiunue

  if (dist[cur.x][cur.y] < cur.dist) continue;

• 2차원 배열 지도에 4방향으로 탐색 (범위 벗어 나면 continue)

• 현재 좌표까지의 거리(복구비용) + 다음 방향 까지 거리(복구비용)이 이미 존재하는 다음 좌표에 대한 거리(복구비용) 보다 작으면 갱신

코드

import java.io.*;
import java.util.*;

public class Solution1249 {
    static int T;
    static int N;
    static int[][] map;
    static int[] dx = {1, 0, -1, 0};
    static int[] dy = {0, 1, 0, -1};
    static int minCost;

    static class Node {
        int x;
        int y;
        int dist;

        Node(int x, int y, int dist) {
            this.x = x;
            this.y = y;
            this.dist = dist;
        }
    }

    static int dijkstra(Node s) {
        // 시작점 부터 거리 배열 초기화
        int dist[][] = new int[N][N];
        for (int i = 0; i < N; i++) {
            Arrays.fill(dist[i], Integer.MAX_VALUE);
        }
        dist[s.x][s.y] = s.dist;

        PriorityQueue<Node> pq = new PriorityQueue<>(
            Comparator.comparingInt((Node n) -> n.dist));

        pq.offer(s);

        while(!pq.isEmpty()) {
            Node cur = pq.poll();

            if (dist[cur.x][cur.y] < cur.dist) continue; // 이미 더 짧은 거리 찾음

            for (int i = 0; i < 4; i++) {
                int nx = cur.x + dx[i];
                int ny = cur.y + dy[i];

                if(nx < 0 || ny < 0 || nx >= N || ny >= N) continue;

                int cost = cur.dist + map[nx][ny];
                if (dist[nx][ny] > cost) {
                    dist[nx][ny] = cost;
                    pq.offer(new Node(nx, ny, cost));
                }
            }
        }
        return dist[N-1][N-1];
    }


    public static void main(String[] args) throws NumberFormatException, IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        T = Integer.parseInt(br.readLine());

        for (int tc = 1; tc <= T; tc++) {
            N = Integer.parseInt(br.readLine());
            map = new int[N][N];

            for (int i = 0; i < N; i++) {
                String str = br.readLine();
                for (int j = 0; j < N; j++) {
                    map[i][j] = str.charAt(j) - '0';
                }
            }

            minCost = dijkstra(new Node(0, 0, 0));
            System.out.printf("#%d %d\n", tc, minCost);
        }
    }
}

[BOJ-14719] 빗물

문제 해결 아이디어

우선순위 큐를 활용해서 2차원 세계의 벽 높이를 오름차순으로 정렬 후 순서대로 물 채우기🪣

조건

• 직관적으로 벽 사이에 물이 고임
• 2차원 세계의 바닥은 막혀있음 (0이 마지막)

PriorityQueue 접근

• Block 객체를 생성하여 i index, h height 저장
• PriorityQueue에 h 내림차순으로 정렬 (높은 벽 먼저)
• b1, b2 높은 벽과 그 다음 높은 벽 꺼내서 반복

빗물 채우기

b1부터 b2사이에 index에 위치한 세계에 b2 높이 만큼 빗물 채우기

for (int i = l + 1; i < r; i++) {
    int water = b2.h - world[i];
    if (water > 0) {
        ans += water;
        world[i] = b2.h;
    }
}

코드

import java.io.*;
import java.util.*;

public class Solution14719 {
    static int H, W;
    static int[] world;
    static int ans;
    static PriorityQueue<Block> pq;

    static class Block {
        int i;
        int h;

        Block(int i, int h) {
            this.i = i;
            this.h = h;
        }
    }

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());

        H = Integer.parseInt(st.nextToken());
        W = Integer.parseInt(st.nextToken());
        world = new int[W];
        ans = 0;
        pq = new PriorityQueue<>(Comparator.comparingInt((Block b) -> b.h).reversed());

        st = new StringTokenizer(br.readLine());
        for (int i = 0; i < W; i++) {
            world[i] = Integer.parseInt(st.nextToken());
            pq.offer(new Block(i, world[i]));
        }

        while (pq.size() > 1) {
            Block b1 = pq.poll();
            Block b2 = pq.peek();

            int l = Math.min(b1.i, b2.i);
            int r = Math.max(b1.i, b2.i);

            for (int i = l + 1; i < r; i++) {
                int water = b2.h - world[i];
                if (water > 0) {
                    ans += water;
                    world[i] = b2.h;
                }
            }
        }
        System.out.println(ans);
    }
}

프로그래머스 - GPS

문제 해결 아이디어

목표는 수정 횟수(오차로 기록된 위치를 바꾼 횟수)를 최소화하여 실제 이동 가능한 경로로 만들기, 시간 t에 v 정점에 있을 때 수정 횟수를 DP로..!

조건

• 택시는 인접한 두 거점 사이를 이동
• 이동 하지 않고 머무르기 가능
• 주어진 GPS 로그의 시작(첫번째)와 도착(마지막) 거점은 바꿀 수 없고, 나머지 위치는 원하는 거점으로 수정가능

DP 접근

각 시간 t (0 ≤ t < k)에서, 택시가 거점 v에 있을 때 지금까지 수정한 최소 횟수를 dp[t][v]라고 한다.

초기 상태: t=0에서는 GPS 로그의 첫 번째 위치 s가 고정되므로 dp[0][s] = 0이고, 다른 거점은 Integer.MAX_VALUE로 둔다.

전이: t에서 v에 있을 때, t+1에는 v에서 이동 가능한 모든 거점 w (자신 포함)로 이동할 수 있다. 이때, GPS 로그에 기록된 t+1번째 값과 w가 같으면 추가 오류 수정 없이, 다르면 1회의 오류 수정 카운트

dp[t+1][w] = min(dp[t+1][w], dp[t][v] + (w == gps_log[t+1] ? 0 : 1))

k-1 시점에 GPS 로그의 도착 위치에 도달하는 최소 수정 횟수가 정답! 도달 불가능하면 -1을 반환

코드

import java.util.*;

class Solution {
    static List<Integer>[] graph;
    public int solution(int n, int m, int[][] edge_list, int k, int[] gps_log) {
        // 1부터 n까지 정점, 양방향 간선으로 인접 리스트 생성
        graph = new ArrayList[n + 1];
        for (int i = 1; i <= n; i++) {
            graph[i] = new ArrayList<>();
            // "머무르기" 가능
            graph[i].add(i);
        }
        for (int[] edge : edge_list) {
            int a = edge[0];
            int b = edge[1];
            graph[a].add(b);
            graph[b].add(a);
        }

        // dp[t][v] : 시간 t에 v에 있을 때까지 수정한 최소 횟수
        int[][] dp = new int[k][n + 1];
        for (int i = 0; i < k; i++) {
            Arrays.fill(dp[i], Integer.MAX_VALUE);
        }
        // 시작 위치는 gps_log[0]
        dp[0][gps_log[0]] = 0;

        // 마지막 위치 gps_log[k-1]는 수정 불가
        for (int t = 0; t < k - 1; t++) {
            for (int v = 1; v <= n; v++) {
                if (dp[t][v] == Integer.MAX_VALUE) continue;
                // v에서 이동 가능한 모든 거점 w (v 자신 포함)
                for (int w : graph[v]) {
                    int cost = (w == gps_log[t + 1] ? 0 : 1);
                    dp[t + 1][w] = Math.min(dp[t + 1][w], dp[t][v] + cost);
                }
            }
        }

        int answer = dp[k - 1][gps_log[k - 1]];
        return (answer == Integer.MAX_VALUE ? -1 : answer);
    }
}

프로그래머스 - 동굴 탐험

문제 해결 아이디어

위상정렬을 잘 몰랐는데 BFS로 구현 한게 위상정렬이었던 것, 제약조건이 있어서, 특정 방🔒에 들어가기전 방문해야하는 방이 있음 -> pre[] 배열, wait[] 배열을 사용하여 i번 방을 방문하기 전에 방문해야하는 방, i번 방을 방문 한 후에 풀리는 방을 저장

1. 그래프 구성

   • graph 배열에 각 방(0번~n-1번)의 인접한 방 정보를 저장
   • 입력으로 주어진 path를 양방향 간선으로 추가

2. 제약 정보 설정

   • pre 배열은 각 방이 방문되기 전에 반드시 방문해야 하는 선행 방의 번호를 저장하며, 기본값은 -1(제약 없음)
   • order 배열을 순회하며, [A, B] 형태의 제약을 pre[B] = A로 저장
   • wait 배열은 아직 방문하지 못한, 방문해야 할 방을 보류하는 용도로 사용

3. BFS 탐색

   • 0번 방(입구)에서 시작
   • 탐색 중, 인접한 방을 방문할 때 해당 방이 선행 조건을 만족하지 않으면(즉, pre[next]가 방문되지 않았으면) wait에 저장
   • 만약 현재 방문한 방 cur가 선행 조건을 제공하는 방이라면, wait[cur]에 저장된 방을 큐에 추가하여 잠금 해제

4. 최종 확인

   • 모든 방이 방문되었는지 확인하여, 하나라도 방문하지 못했다면 false를 반환하고, 모두 방문했다면 true를 반환

코드

import java.util.*;

class Solution {
    public boolean solution(int n, int[][] path, int[][] order) {
        // 1. 그래프 구성
        List<Integer>[] graph = new ArrayList[n];
        for (int i = 0; i < n; i++) {
            graph[i] = new ArrayList<>();
        }
        for (int[] p : path) {
            graph[p[0]].add(p[1]);
            graph[p[1]].add(p[0]);
        }

        // 2. 제약 정보 설정
        // pre[i] : i번 방을 방문하기 전에 반드시 방문해야 하는 방 (없으면 -1)
        int[] pre = new int[n];
        Arrays.fill(pre, -1);
        // wait[x] : x번 방을 방문한 후에 unlock될, 아직 방문 못한 방 (없으면 -1)
        int[] wait = new int[n];
        Arrays.fill(wait, -1);

        for (int[] o : order) {
            pre[o[1]] = o[0];
        }

        // 0번 방(입구)가 잠겨있으면 탐험 불가능
        if (pre[0] != -1) {
            return false;
        }

        // 3. BFS 탐색 0번 방부터 시작
        boolean[] v = new boolean[n];
        Deque<Integer> q = new ArrayDeque<>();
        v[0] = true;
        q.offer(0);

        while (!q.isEmpty()) {
            int cur = q.poll();

            // cur 방문으로 인해 unlock되어야 하는 방이 있다면 큐에 추가
            if (wait[cur] != -1) {
                int next = wait[cur];
                q.offer(next);
                v[next] = true;
                wait[cur] = -1;
            }

            for (int next : graph[cur]) {
                if (v[next]) {
                    continue;
                }

                // next가 방문 조건(선행 방문)이 있고, 아직 방문 전이라면 next 대기
                if (pre[next] != -1 && !v[pre[next]]) {
                    wait[pre[next]] = next;
                } else {
                    v[next] = true;
                    q.offer(next);
                }
            }
        }

        // 4. 모든 방을 방문했는지 확인
        for (boolean flag : v) {
            if (!flag) {
                return false;
            } 
        }
        return true;
    }
}

프로그래머스 - 합승 택시 요금

문제 해결 아이디어

DP인데 '플로이드 워셜'이었던 것 점화식 구하는게 중요!

1. 그래프 구성

   • 주어진 fares 정보를 바탕으로 인접 행렬(dist 배열)을 생성
   • dist[i][j]는 i번 지점에서 j번 지점으로 이동하는 최소 요금을 저장
   • 직통 경로가 없으면 큰 값(주어진 조건을 만족하는 최대 거리)으로 초기화
   • 자기 자신으로의 이동 비용은 0으로 설정

2. Floyd-Warshall 알고리즘

   • 점화식: dist[i][j] = min(dist[i][j], dist[i][k] + dist[k][j]
   • 이 과정을 k=1..n, i=1..n, j=1..n에 대해 반복

3. 합승 지점 x 선택

   • 최종적으로 s(출발점)에서 x까지 함께 택시를 탄 뒤, x에서 A, B 각각의 집으로 따로 이동하는 경우를 고려
   • 즉, 모든 지점 x(1부터 n까지)를 순회하며, 비용 dist[s][x] + dist[x][a] + dist[x][b]의 최솟값

코드

class Solution {
    public int solution(int n, int s, int a, int b, int[][] fares) {
        // 1. dist 배열 초기화
        int[][] dist = new int[n + 1][n + 1];
        for (int i = 1; i <= n; i++) {
            for (int j = 1; j <= n; j++) {
                if (i != j) {
                    dist[i][j] = 20000000; // 최대 비용 (최대 요금 100,000 * 지점갯수 200 = 20,000,000)
                }
            }
        }

        // 2. 요금 정보 입력
        for (int[] fare : fares) {
            int c = fare[0];
            int d = fare[1];
            int f = fare[2];
            dist[c][d] = f;
            dist[d][c] = f;
        }

        // 3. Floyd-Warshall 알고리즘
        for (int k = 1; k <= n; k++) {
            for (int i = 1; i <= n; i++) {
                for (int j = 1; j <= n; j++) {
                    if (dist[i][j] > dist[i][k] + dist[k][j]) {
                        dist[i][j] = dist[i][k] + dist[k][j];
                    }
                }
            }
        }

        // 4. s→x 합승 후 x→a, x→b 각각 이동 비용의 최솟값 탐색
        int answer = dist[s][a] + dist[s][b]; // s→a + s→b 비용
        for (int x = 1; x <= n; x++) {
            int cost = dist[s][x] + dist[x][a] + dist[x][b];
            if (cost < answer) {
                answer = cost;
            }
        }

        return answer;
    }
}

프로그래머스 - 코딩테스트 공부

문제 해결 아이디어

알고력과 코딩력을 달성하기 위한 최소 시간을 dp[i][j]로 구성하는게 포인트🎯

1. 목표 알고력, 코딩력 설정

   • problems에서 모든 alp_req 중 최댓값과 cop_req 중 최댓값

2. DP 배열 구성

   • dp[i][j]를 알고력 i와 코딩력 j를 달성하기 위한 최소 시간을 저장하는 2차원 배열로 정의
   • 초기 상태 dp[alp][cop] = 0으로 시작하며, 나머지 값은 큰 값(Integer.MAX_VLAUE)으로 초기화
   • 단, 초기 alp 또는 cop가 목표치를 넘는다면 목표치로 맞춤 (배열 길이 고려)

3. 상태 전이

   • 공부(알고리즘/코딩)
     • 알고리즘 공부: dp[i+1][j] = min(dp[i+1][j], dp[i][j] + 1)
     • 코딩 공부: dp[i][j+1] = min(dp[i][j+1], dp[i][j] + 1)
   • 문제 풀이
     • 만약 현재 상태 (i, j)가 문제 p의 요구치(alp_req, cop_req)를 만족한다면, 문제 p를 풀어 새 상태 (min(target_alp, i + alp_rwd), min(target_cop, j + cop_rwd))로 전이되고, 소요 시간 cost가 추가

4. 최종 답안

   • 목표 알고력과 코딩력을 달성한 상태 dp[target_alp][target_cop]의 값이 최소 총 공부 시간이 됩니다.

코드

import java.util.*;

class Solution {
    public int solution(int alp, int cop, int[][] problems) {
        // 1. 목표 알고력, 코딩력 설정 (각 문제의 최대 요구치)
        int maxAlp = 0, maxCop = 0;
        for (int[] prob : problems) {
            maxAlp = Math.max(maxAlp, prob[0]);
            maxCop = Math.max(maxCop, prob[1]);
        }
        // 초기치가 목표치를 초과하면 목표치로 맞춤
        alp = Math.min(alp, maxAlp);
        cop = Math.min(cop, maxCop);

        // 2. dp 배열 초기화
        int[][] dp = new int[maxAlp + 1][maxCop + 1];
        for (int i = 0; i <= maxAlp; i++) {
            Arrays.fill(dp[i], Integer.MAX_VALUE);
        }
        dp[alp][cop] = 0;

        // 3. DP 전이 (알고리즘 공부, 코딩 공부, 문제 풀기)
        for (int i = alp; i <= maxAlp; i++) {
            for (int j = cop; j <= maxCop; j++) {
                if (dp[i][j] == Integer.MAX_VALUE) continue;

                // 3-1. 알고리즘 공부: 알고력 1 증가
                if (i < maxAlp) {
                    dp[i+1][j] = Math.min(dp[i+1][j], dp[i][j] + 1);
                }
                // 3-2. 코딩 공부: 코딩력 1 증가
                if (j < maxCop) {
                    dp[i][j+1] = Math.min(dp[i][j+1], dp[i][j] + 1);
                }
                // 3-3. 각 문제 풀이
                for (int[] prob : problems) {
                    if (i >= prob[0] && j >= prob[1]) {
                        int newAlp = Math.min(maxAlp, i + prob[2]);
                        int newCop = Math.min(maxCop, j + prob[3]);
                        dp[newAlp][newCop] = Math.min(dp[newAlp][newCop], dp[i][j] + prob[4]);
                    }
                }
            }
        }
        return dp[maxAlp][maxCop];
    }
}

프로그래머스 - 택배 배달과 수거하기

문제 해결 아이디어

이 문제는 뒤쪽(가장 먼 집)부터 처리하는 그리디 알고리즘을 활용해야겠다고 생각했다!

1. 뒤쪽부터 처리하기

   • 집들은 물류창고에서 가까운 순서대로 1번부터 n번까지 배치되어 있으므로, 가장 먼 집부터 남은 배달 또는 수거가 있는 집까지의 거리를 기준으로 처리

2. 최대 거리 결정

   • 아직 처리할 배달이나 수거가 남은 집들 중 가장 먼 집의 번호를 찾기
   • 해당 집까지의 왕복 거리는 (집 번호 = index + 1) * 2

3. 한 번 이동에서 cap 만큼 처리

   • 트럭의 용량 cap만큼 배달과 수거 작업을 진행
   • 각각의 배열에서 가장 먼 집부터 cap 만큼의 택배 상자를 처리하고, 남은 건수 갱신

4. 반복 처리

   • 모든 집에 대한 배달 및 수거가 완료될 때까지 위 과정을 반복하며, 이동 거리 누적

코드

import java.util.*;

class Solution {
    public long solution(int cap, int n, int[] deliveries, int[] pickups) {
        long answer = 0;
        int dIdx = n - 1; // deliveries의 마지막 인덱스 (가장 먼 집)
        int pIdx = n - 1; // pickups의 마지막 인덱스 (가장 먼 집)

        // 아직 배달 또는 수거할 집이 남아있는 동안 반복
        while (dIdx >= 0 || pIdx >= 0) {
            // 배달할 집 중 남은 건수가 0인 집은 건너뛰기
            while (dIdx >= 0 && deliveries[dIdx] == 0) {
                dIdx--;
            }
            // 수거할 집 중 남은 건수가 0인 집은 건너뛰기
            while (pIdx >= 0 && pickups[pIdx] == 0) {
                pIdx--;
            }

            // 배달과 수거가 모두 완료되었다면 종료
            if (dIdx < 0 && pIdx < 0) {
                break;
            }

            // 이번 회 이동할 최대 거리는 두 포인터 중 더 큰 값(인덱스)에 1을 더한 거리
            int dist = Math.max(dIdx, pIdx) + 1;
            answer += (long) dist * 2;  // 왕복 이동 거리 누적

            int deliverCap = cap; // 이번 회 배달 처리에 사용할 남은 용량
            int pickupCap = cap;  // 이번 회 수거 처리에 사용할 남은 용량

            // 배달 처리: 가장 먼 집부터 cap 만큼 배달을 처리
            while (dIdx >= 0 && deliverCap > 0) {
                if (deliveries[dIdx] <= deliverCap) {
                    deliverCap -= deliveries[dIdx];
                    deliveries[dIdx] = 0;
                    dIdx--;
                } else {
                    deliveries[dIdx] -= deliverCap;
                    deliverCap = 0;
                }
            }

            // 수거 처리: 가장 먼 집부터 cap 만큼 수거를 처리
            while (pIdx >= 0 && pickupCap > 0) {
                if (pickups[pIdx] <= pickupCap) {
                    pickupCap -= pickups[pIdx];
                    pickups[pIdx] = 0;
                    pIdx--;
                } else {
                    pickups[pIdx] -= pickupCap;
                    pickupCap = 0;
                }
            }
        }

        return answer;
    }
}

프로그래머스 - 도넛과 막대 그래프

문제 해결 아이디어

도넛, 막대, 팔자 그래프 유형을 판별하는 방식을 빨리 찾아내는게 중요한데..😂

1. 전체 정점 범위 파악 및 그래프 구성

   • 주어진 간선 정보를 순회하며 정점 번호 수(nCount)를 파악
   • 정점 번호를 인덱스로 하는 인접 리스트와 각 정점의 진입차수(inDegree) 배열을 생성

2. 생성 정점 찾기

   • inDegree가 0이면서, out-degree가 2 이상인 정점을 생성 정점으로 결정

3. BFS를 통한 서브그래프(연결 요소) 분리

   • 생성 정점의 자식 정점들을 시작점으로 하여 BFS를 수행
   • BFS 과정에서 해당 서브그래프에 포함된 정점 수(compV)와 간선 수(compE)를 집계

4. 서브그래프 유형 판별

   • 각 서브그래프에 대해 집계한 compV와 compE의 값으로 유형을 구분
     • 도넛 그래프: compE == compV
     • 막대 그래프: compE == compV - 1
     • 팔자(8자) 그래프: compE == compV + 1

코드

import java.util.*;

class Solution {
    public int[] solution(int[][] edges) {
        // 1. 전체 정점 번호 범위 파악
        int nCount = 0;
        for (int[] e : edges) {
            nCount = Math.max(nCount, Math.max(e[0], e[1]));
        }

        // 2. 그래프와 inDegree 배열 초기화
        List<List<Integer>> graph = new ArrayList<>(nCount + 1);
        int[] inDegree = new int[nCount + 1];
        for (int i = 0; i <= nCount; i++) {
            graph.add(new ArrayList<>());
        }
        for (int[] e : edges) {
            int u = e[0], v = e[1];
            graph.get(u).add(v);
            inDegree[v]++;
        }

        // 3. "생성 정점" 찾기: inDegree == 0 이면서 outDegree (graph.get(i).size())가 2 이상인 정점
        int start = -1;
        for (int i = 1; i <= nCount; i++) {
            if (inDegree[i] == 0 && graph.get(i).size() >= 2) {
                start = i;
                break;
            }
        }

        int donut = 0, stick = 0, eight = 0;
        boolean[] v = new boolean[nCount + 1];

        // 4. BFS로 서브그래프 탐색
        for (int child : graph.get(start)) {
            if (v[child]) continue;

            int compV = 0, compE = 0;
            Queue<Integer> queue = new LinkedList<>();
            queue.offer(child);
            v[child] = true;

            while (!queue.isEmpty()) {
                int cur = queue.poll();
                compV++;

                for (int next : graph.get(cur)) {
                    compE++; // cur -> next 간선 카운트
                    if (!v[next]) {
                        v[next] = true;
                        queue.offer(next);
                    }
                }
            }

            // 5. 서브그래프 분류
            if (compE == compV) {         // 도넛 그래프: 간선 수 == 정점 수
                donut++;
            } else if (compE == compV - 1) { // 막대 그래프: 간선 수 == 정점 수 - 1
                stick++;
            } else if (compE == compV + 1) { // 팔자(8자) 그래프: 간선 수 == 정점 수 + 1
                eight++;
            }
        }

        return new int[] { start, donut, stick, eight };
    }
}

현대 사회에서 인터넷은 없어서는 안 될 인프라이다. 이 인터넷을 포함한 컴퓨터 간의 통신은 네트워크(Network) 라는 구조를 통해 이루어진다. 이 글에서는 네트워크의 기본 구조부터 IP 주소, MAC 주소까지의 개념을 하나씩 정리해본다.

🕸️ 네트워크의 구조 이해하기

📌 네트워크 토폴로지 (Network Topology)

네트워크에서 노드(컴퓨터, 서버 등) 간의 연결 형태를 토폴로지라고 한다.

• 버스형 (Bus) : 하나의 주 라인에 여러 장치가 연결된 형태
• 성형 (Star) : 중앙 장치에 모든 장치가 연결된 형태
• 링형 (Ring) : 원형으로 각 장치가 연결된 형태
• 트리형 (Tree) : 계층적 구조
• 망형 (Mesh) : 모든 장치가 서로 직접 연결

구조에 따라 통신 속도, 장애 발생 시의 영향, 비용 등에 차이가 발생한다.

👥 호스트 (Host)

• 최초 송신지와 최종 수신지를 의미하는 장치
• 예: 노트북에서 구글 서버에 웹페이지 요청 → 구글 서버가 응답

🖧 LAN과 WAN

• LAN (Local Area Network) : 한정된 공간(사무실, 집 등) 내에서 가까운 장치들을 연결하는 네트워크
• WAN (Wide Area Network) : 장거리, 광범위한 지역을 연결하는 네트워크
  • ISP (Internet Service Provider) 업체가 관리

📦 패킷과 주소

네트워크 통신은 패킷(Packet) 단위로 데이터를 주고받는다. 패킷은 다음과 같은 구조를 가진다:

• 헤더 (Header) : 송수신지 정보, 전송 제어 정보 등
• 페이로드 (Payload) : 실제 데이터
• 트레일러 (Trailer) : 에러 검사 정보

📮 주소의 종류

• IP 주소 : 네트워크 내 위치 식별
• MAC 주소 : 물리적 장치 식별

🧭 전송 방식

• 유니캐스트 : 1:1 통신
• 브로드캐스트 : 1:모두 (네트워크 상의 모든 장치로 전송)
  • 브로드캐스트 도메인 : 브로드캐스트가 전달되는 범위
• 멀티캐스트 : 1:선택된 그룹
• 애니캐스트 : 1:가장 가까운 노드로

🔁 두 호스트 간 통신 절차

네트워크 상에서 장치들이 서로 통신하기 위해서는 규약(프로토콜) 과 계층 구조가 필요하다.

🧾 프로토콜이란?

프로토콜은 네트워크 통신에서 지켜야 할 규칙 또는 약속이다.

• IP (Internet Protocol) : 주소 지정, 라우팅
• ARP (Address Resolution Protocol) : IP주소 ↔ MAC주소 매핑
• TCP (Transmission Control Protocol) : 신뢰성 있는 통신
• UDP (User Datagram Protocol) : 빠른 통신, 비신뢰성
• HTTPS : 암호화된 HTTP 통신

🧱 네트워크 계층 모델

📚 OSI 7계층

1. 물리 계층 - 전기적, 기계적 신호 전달
2. 데이터 링크 계층 - 물리적 주소(MAC) 기반의 데이터 전송
3. 네트워크 계층 - 논리적 주소(IP) 기반의 라우팅
4. 전송 계층 - 데이터 흐름 제어, 오류 검출 (TCP/UDP)
5. 세션 계층 - 통신 세션 제어
6. 표현 계층 - 데이터 표현 방식 (암호화, 압축 등)
7. 응용 계층 - 사용자 응용 프로그램 (웹, 이메일 등)

🧰 TCP/IP 4계층

1. 네트워크 인터페이스 계층 - OSI 1~2계층
2. 인터넷 계층 - OSI 3계층
3. 전송 계층 - OSI 4계층
4. 응용 계층 - OSI 5~7계층

실무에서는 TCP/IP 모델을 더 많이 사용한다.

📦 캡슐화와 역캡슐화

캡슐화(Encapsulation)

→ 데이터를 하위 계층으로 보낼 때, 각 계층의 헤더를 추가하며 이동

역캡슐화(Decapsulation)

→ 데이터를 수신할 때, 계층별로 헤더를 제거하며 상위 계층으로 전달

🧭 IP 주소의 구조와 전달

📌 IP 주소의 목적

• 호스트 식별 및 데이터 라우팅
• 단편화(Fragmentation) 를 통해 큰 데이터를 나눠 전송

📬 신뢰성 없는 통신

• IP는 신뢰성 없는, 비연결형 프로토콜
• 최선형 전송(Best-Effort Delivery) 이며, 보장하지는 않음

🧩 IP 주소의 체계

📍 클래스풀 주소 체계

• A클래스, B클래스, C클래스로 구분
• 각 클래스마다 네트워크와 호스트의 비트 수가 다름

🎭 클래스리스 주소와 서브넷 마스크

• CIDR (Classless Inter-Domain Routing) 표기 사용
• 서브넷 마스크를 통해 네트워크 영역과 호스트 영역 구분
• 서브네팅 : 큰 네트워크를 나누어 효율적으로 관리

🌎 공인 IP vs 사설 IP

• 공인 IP : 인터넷에서 고유하게 식별 가능한 주소
• 사설 IP : 내부 네트워크에서만 사용

📥 IP 주소 확인 방법

• Windows : ipconfig /all
• macOS/Linux : ifconfig

🔄 IP 주소의 할당

• DHCP (Dynamic Host Configuration Protocol) : 자동 할당
• 정적 할당 : 수동으로 지정

📡 기타 설정

• 게이트웨이 : 외부 네트워크로 나가는 출입구
• DNS : 도메인을 IP로 변환

🛠️ 전송 보완 : ICMP

• ICMP (Internet Control Message Protocol)
  1. 오류 메시지 보고
  2. 네트워크 상태 정보 제공

🔗 MAC 주소와의 대응 : ARP

• ARP (Address Resolution Protocol) 은 IP 주소에 대응되는 MAC 주소를 조회
• 네트워크 통신에서 두 호스트가 직접 통신하기 위해 반드시 필요한 과정

Ref. 📗《이것이 취업을 위한 컴퓨터 과학이다 with CS 기술 면접》, 강민철

🍪 쿠키: Stateless HTTP

HTTP는 기본적으로 Stateless하다. 즉, 이전 요청과 다음 요청 사이에 연결 정보나 상태를 유지하지 않는다. 이를 보완하기 위해 사용하는 것이 바로 쿠키(cookie)이다.

• 쿠키는 <이름, 값> 쌍으로 이루어진 데이터이며, 서버가 클라이언트에 전송하여 브라우저에 저장한다.
• 이후 같은 서버에 요청할 때 브라우저는 해당 쿠키를 요청 헤더에 포함시켜 전송한다.

쿠키 관련 주요 헤더

웹 스토리지 (Web Storage)

• 로컬 스토리지 (Local Storage): 브라우저를 꺼도 유지되는 영구 저장소
• 세션 스토리지 (Session Storage): 브라우저가 열려 있는 동안만 유지되는 임시 저장소

📦 HTTP 캐시

웹 페이지에 포함된 이미지, CSS, JS 파일은 자주 변하지 않으며 용량도 크다. 매 요청마다 다운로드하면 속도와 리소스 낭비가 크다. 이를 해결하는 기술이 바로 HTTP 캐시이다.

캐시의 핵심 개념

• Expires: 이 날짜 이전까지는 캐시된 자원을 그대로 사용해도 됨
• 신선도(freshness): 캐시된 데이터가 서버의 최신 데이터와 유사한 정도
• 유효 기간이 만료된 경우, 서버에 원본 자원이 변경되었는지 질의 후 판단

조건부 요청

🔖 If-Modified-Since 헤더

• 클라이언트가 가진 데이터의 최종 수정 시간을 서버에 전송
• 서버는 이 시간 이후로 자원이 수정되었는지 확인

🔖 Etag과 If-None-Match 헤더

• Etag: 자원의 버전을 식별하는 엔티티 태그
• 클라이언트가 If-None-Match로 현재 Etag를 전송하여, 서버에 변경 여부를 확인

결과는 위와 동일하게 200 / 304 / 404 코드로 판단된다.

📌 결론: 캐시는 단순 저장이 아닌, 서버의 상태를 고려하여 효율적으로 자원을 관리하는 시스템이다.

🌍 콘텐츠 협상(Content Negotiation)

같은 자원을 여러 표현 방식으로 제공할 수 있다. 예를 들어, 텍스트 파일은 XML, JSON, HTML 등 다양한 포맷으로 표현할 수 있다. 이 중 클라이언트에게 적합한 형식을 제공하는 것이 콘텐츠 협상이다.

📑 주요 헤더

예시:

GET /api/data HTTP/1.1
Host: example.com
Accept: application/json;q=1.0, text/html;q=0.8, application/xml;q=0.6
Accept-Language: ko-KR;q=1.0, en-US;q=0.8, ja-JP;q=0.5
Accept-Encoding: gzip;q=1.0, deflate;q=0.8, br;q=0.5
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

👉 클라이언트는 JSON, 한국어, gzip을 더 선호한다는 의미

🔒 HTTPS와 TLS/SSL

HTTP는 내용을 암호화하지 않는다. 민감한 정보가 그대로 노출될 수 있다. 이를 막기 위해 사용하는 것이 HTTPS이며, SSL/TLS 프로토콜을 기반으로 한다.

HTTPS 구성 요소

• HTTPS = HTTP + TLS
• 통신 과정 요약:
  1. TCP 3-way 핸드셰이크
  2. TLS 핸드셰이크 (암호화 통신 준비)
  3. 실제 HTTP 메시지 송수신

🔐 암호화 알고리즘의 동작 방식

TLS 통신에서 사용되는 대칭키 또는 비대칭키 암호화 방식은 아래와 같은 흐름으로 동작한다.

🔐 암호화

• 입력: 평문 + 키
• 출력: 암호문

🔓 복호화

• 입력: 암호문 + 키
• 출력: 평문

👉 키가 같으면 대칭키 방식, 다르면 비대칭키 방식이다.

🤝 TLS 1.3 핸드셰이크 흐름

TLS는 클라이언트와 서버 간의 비밀키 공유, 인증서 검증, 암호화 방식 협상을 포함한다.

📶 핸드셰이크 순서

1. 클라이언트 → 서버: ClientHello (key_share 포함)
2. 서버 → 클라이언트: ServerHello (key_share 포함), EncryptedExtensions, Certificate, CertificateVerify, Finished
3. 클라이언트 → 서버: Finished

✔ 이 후부터는 서로 동일한 키로 암호화된 데이터 송수신 가능

🛡 인증서와 보안

• 서버는 공인된 인증기관(CA)에서 발급받은 인증서를 전송한다
• 클라이언트는 이를 통해 서버의 신뢰성 확인

크롬에서 확인:

🔒 사이트 정보보기 -> 이 연결은 안전합니다 → 인증서 유효함 → 인증서 뷰어

🏗 프록시와 안정적인 트래픽

웹 시스템은 단순히 서버 하나로 구성되지 않는다. 수많은 사용자의 요청을 안정적으로 처리하고, 갑작스러운 부하에도 견딜 수 있어야 한다. 이를 위해 사용하는 대표적인 구조가 프록시, 로드 밸런싱, 스케일링, 고가용성 설계이다.

🧭 오리진 서버와 프록시 서버

🖥 오리진 서버(Origin Server)

오리진 서버는 자원의 최초 생성지이며, 클라이언트 요청에 대한 최종 응답을 보장할 수 있는 서버

🔁 포워드 프록시 (Forward Proxy)

클라이언트와 서버 사이에 위치한 중간 대리 서버로, 클라이언트 요청을 받아 대신 서버에 요청을 전달하고 응답을 받아 다시 클라이언트에 전달

✅ 주요 기능

• 캐시 저장으로 응답 속도 향상
• 클라이언트의 IP 차단 우회
• 접근 제어, 익명성 보장

📌 클라이언트 입장에서 직접 오리진 서버에 접근하지 않고, 대신 요청을 수행하는 심부름꾼 같은 존재이다.

🛡 리버스 프록시 (Reverse Proxy, 게이트웨이)

• 클라이언트가 오리진 서버에 직접 요청하는 대신, 리버스 프록시 서버가 먼저 요청을 받아 오리진 서버로 전달

✅ 주요 기능

• 클라이언트는 오리진 서버를 직접 알 필요 없음
• 오리진 서버를 숨길 수 있어 보안상 유리
• 부하 분산, SSL 종료, 캐시 제공 등에 활용

📌 리버스 프록시는 서버 진영의 문지기 또는 경비 역할을 한다.

🔄 고가용성(High Availability)

고가용성은 시스템이 장시간 중단되지 않고 동작할 수 있는 능력이다.

📊 가용성

가용성 = 업타임 / (업타임 + 다운타임)

• 업타임(uptime): 정상 작동 시간
• 다운타임(downtime): 장애로 인해 시스템이 멈춘 시간

고가용성 구현 요소

• 결함 감내(Fault Tolerance): 일부 컴포넌트가 장애를 일으켜도 전체 시스템은 작동 가능해야 한다.
• 다중화(Redundancy): 핵심 구성 요소를 복수로 구성

대표적인 기술

• 하트비트(Heartbeat): 서버 간 생존 여부를 신호로 주고받는 시스템
• 헬스 체크(Health Check): 서버 상태를 주기적으로 검사

⚖️ 로드 밸런싱 (Load Balancing)

다수의 서버가 동일한 서비스를 제공할 때, 클라이언트 요청을 고르게 분산시켜주는 장치가 로드 밸런서(load balancer)이다.

주요 알고리즘

📌 로드 밸런싱은 서버 과부하 방지, 서비스 안정성 향상을 목적으로 한다.

📈 스케일링 (Scaling)

트래픽이 급증할 경우, 서버 용량을 확장하여 시스템을 유지해야 한다. 이를 스케일링이라 한다.

스케일 업(Scale Up)

• 하나의 서버를 더 좋은 사양으로 교체
• 수직 확장(vertical scaling)

✅ 장점: 구성 간단

❌ 단점: 비용 증가, 한계 존재

스케일 아웃(Scale Out)

• 서버 수를 늘려서 처리 능력 향상
• 수평 확장(horizontal scaling)

✅ 장점: 유연한 확장

❌ 단점: 시스템 설계 복잡

🔁 오토 스케일링 (Auto Scaling)

• 실시간 트래픽 변화에 따라 자동으로 서버 수를 늘리거나 줄이는 기능
• 예: 티켓팅 시스템, 수강 신청처럼 순간적으로 트래픽이 몰리는 상황

🧰 Nginx로 알아보는 로드 밸런싱 실전

📂 Nginx 설정 파일 구조

${nginx}/nginx.conf          # 메인 설정 파일
${nginx}/conf.d/*.conf       # 웹 서버 관련 하위 설정
${nginx}/log/nginx/          # 접근/오류 로그 저장 경로

🔧 주요 설정 예시

http {
    upstream backend {
        server backend1.example.com;
        server backend2.example.com;
    }

    server {
        listen 80;
        server_name localhost;

        location / {
            proxy_pass http://backend;
        }
    }
}

• listen 80: 80 포트에서 요청 대기
• location /: 루트 경로 요청 시 처리
• proxy_pass http://backend;: 요청을 backend 서버 그룹으로 전달

📌 Nginx는 단순 웹 서버를 넘어 리버스 프록시, 로드 밸런서 역할까지 수행할 수 있는 범용 HTTP 서버이다.

🔁 업스트림(Upstream) / 다운스트림(Downstream)

이 두 개는 데이터 흐름의 방향을 기준으로 한다.

📤 업스트림 (Upstream)

• 요청을 보내는 쪽, 또는 상위 시스템
• 예: 클라이언트 → 서버일 때, 클라이언트가 업스트림
• 예: 서비스 A → 서비스 B → DB 구조에서 A는 B의 업스트림
• 🔄 위로 흐른다 생각하면 이해 쉬움 (하류 → 상류)

📥 다운스트림 (Downstream)

• 요청을 받는 쪽, 또는 하위 시스템
• 예: 클라이언트 → 서버일 때, 서버가 다운스트림
• 예: A → B → DB 구조에서 DB는 A의 다운스트림

✅ 정리: "업스트림은 데이터를 보내는 방향", 다운스트림은 그걸 받는 쪽

🔃 인바운드(Inbound) / 아웃바운드(Outbound)

이 둘은 요청/응답이 어느 시스템 안으로 들어오느냐, 나가느냐를 기준으로 한다.

🔽 인바운드 (Inbound)

• 외부 → 내부로 들어오는 트래픽
• 예: 외부 클라이언트가 내 API 서버로 요청 보냄 → 인바운드 요청
• 예: 방화벽 입장에서 외부에서 들어오는 요청

🔼 아웃바운드 (Outbound)

• 내부 → 외부로 나가는 트래픽
• 예: 내 서버가 외부 API 호출 → 아웃바운드 요청
• 예: 방화벽 입장에서 내부에서 외부로 나가는 요청

✅ 정리: "인바운드는 들어오는 것", 아웃바운드는 나가는 것"

Ref. 📗《이것이 취업을 위한 컴퓨터 과학이다 with CS 기술 면접》, 강민철

컴퓨터 네트워크에서 전송 계층(Transport Layer) 은 데이터가 송수신될 때 최종 목적지인 프로세스(프로그램) 에 정확히 전달되도록 관리하는 계층이다.

🔹 TCP와 UDP의 목적과 특징

패킷이 네트워크를 통해 전송될 때, IP 주소와 MAC 주소 를 이용하여 호스트(컴퓨터 또는 네트워크 장치) 를 식별할 수 있다. 하지만 호스트 내에서 실행 중인 특정 프로세스(응용 프로그램) 에 도달하려면 포트 번호(Port Number) 가 필요하다.

🏛 TCP (Transmission Control Protocol)

TCP는 신뢰할 수 있는 데이터 전송 을 보장하는 연결형 프로토콜 이다. 즉, 데이터가 손실되지 않고, 순서대로 도착하도록 하는 것이 특징이다.

✅ TCP의 주요 특징

1. 신뢰성 있는 데이터 전송
   • 패킷 손실이 발생하면 재전송 을 수행하며, 데이터가 정확히 전달되도록 보장한다.
   • 흐름 제어, 오류 제어, 혼잡 제어 기능을 포함한다.
2. 연결형 통신(Connection-Oriented Communication)
   • 데이터 전송 전에 반드시 3-way Handshake 를 통해 연결을 설정하고, 데이터 전송이 끝나면 4-way Handshake 로 연결을 종료한다.
3. 순서 보장
   • 각 패킷에는 순서 번호(Sequence Number) 가 포함되어 있어, 받은 패킷을 순서대로 정렬하여 처리할 수 있다.
4. 흐름 제어(Flow Control)
   • 송신자가 수신자의 처리 속도를 고려하여 데이터를 전송하는 방식이다.
5. 혼잡 제어(Congestion Control)
   • 네트워크 트래픽이 과부하 상태가 되는 것을 방지하기 위해 패킷 전송량을 조절한다.

📜 TCP 헤더 구조

🔹TCP의 제어 비트(Flags)

• ACK: 응답 확인(Acknowledgment)
• SYN: 연결 요청(Synchronize)
• FIN: 연결 종료(Finish)
• RST: 연결 초기화(Reset)
• PSH: 수신 측에서 즉시 전달(Push)
• URG: 긴급 데이터(Urgent)

🚀 UDP (User Datagram Protocol)

UDP는 빠른 데이터 전송을 위해 신뢰성을 보장하지 않는 비연결형 프로토콜 이다. TCP와 달리 데이터 손실, 순서 보장, 흐름 제어가 없다.

✅ UDP의 주요 특징

1. 비연결형 통신(Connectionless Communication)
   • 데이터를 보내기 전에 연결을 설정하지 않으며, 수신 확인도 하지 않는다.
2. 빠른 데이터 전송
   • 별도의 오류 제어나 흐름 제어 없이 단순히 데이터를 보내므로 속도가 빠르다.
3. 데이터 손실 가능
   • 데이터가 손실될 가능성이 있으며, 손실된 데이터의 재전송을 보장하지 않는다.
4. 헤더가 단순함
   • TCP보다 간단한 헤더 구조를 가지고 있어 오버헤드가 적다.

📜 UDP 헤더 구조

🔥 TCP와 UDP 비교

🎯 포트 번호 정리

🔹 포트 종류

🔹 자주 사용하는 포트 번호

🔗 TCP의 연결 수립 과정 (3-Way Handshake)

TCP 통신을 시작하기 위해 3-Way Handshake 방식이 사용된다. 클라이언트와 서버가 세그먼트를 주고받으며 연결을 설정한다.

1️⃣ 클라이언트 → 서버 (SYN 전송)

클라이언트는 연결을 요청하는 SYN 세그먼트를 서버에게 보낸다.

2️⃣ 서버 → 클라이언트 (SYN + ACK 전송)

서버는 연결 요청을 수락하며 SYN + ACK 세그먼트를 클라이언트에게 보낸다.

3️⃣ 클라이언트 → 서버 (ACK 전송)

클라이언트는 서버에게 연결을 확인하는 ACK 세그먼트를 보내면서 연결이 확립된다.

📌 이 과정이 완료되면 클라이언트와 서버 간에 데이터 전송이 가능해진다.

⚙️ TCP의 오류·흐름·혼잡 제어

🛠️ TCP 오류 제어 (Error Control)

TCP는 신뢰성 있는 데이터 전송을 보장하기 위해 오류 제어 기능을 수행한다. 오류 제어 방식에는 재전송과 중복 확인 응답(ACK)이 있다.

☑️ 1. 재전송을 통한 오류 제어

• 송신 측에서 데이터를 보낸 후 일정 시간 내에 ACK(확인 응답)을 받지 못하면 해당 데이터를 재전송한다.
• 데이터 손실이 발생하면 송신 측은 타임아웃이 발생할 때까지 ACK을 기다린 후 다시 데이터를 전송한다.

📌 타임아웃이란? 송신 측이 일정 시간 내에 ACK을 받지 못하면 데이터가 손실된 것으로 판단하고 재전송하는 메커니즘이다.

🚀 파이프라이닝 (Pipelining) 기법

TCP는 데이터 전송 속도를 높이기 위해 파이프라이닝(Pipelining) 방식을 사용한다.

🔄 파이프라이닝이란?

• 송신 측이 ACK을 기다리지 않고 여러 개의 세그먼트를 연속으로 전송하는 방식이다.
• 확인 응답(ACK)은 누적적으로 응답하여 여러 개의 패킷을 한 번에 확인할 수 있다. 💡 장점: 네트워크의 활용도를 높이고 전송 속도를 향상시킨다. ⚠️ 단점: 손실이 발생하면 해당 구간의 데이터 전체를 다시 전송해야 한다.

☑️ 2. 흐름 제어 (Flow Control)

• 수신 호스트가 한 번에 처리할 수 있는 데이터의 양을 초과하지 않도록 조절하는 메커니즘이다.
• 수신 윈도우(Receive Window) 크기를 설정하여 조절한다.

💡 예제: → 수신 호스트가 3개의 패킷만 수용 가능한 경우, 송신 호스트는 이를 초과하지 않도록 송신 속도를 조절한다.

☑️ 3. 혼잡 제어 (Congestion Control)

네트워크에 과부하가 발생하지 않도록 데이터 전송 속도를 조절하는 기법이다.

🏗️ 혼잡 제어 방식

✅ AIMD(Additive Increase Multiplicative Decrease)

• 패킷이 정상적으로 도착하면 혼잡 윈도우를 증가
• 패킷 손실이 감지되면 혼잡 윈도우 크기를 줄이는 방식

📌 혼잡 윈도우 (Congestion Window)란? ** 송신 호스트가 네트워크의 상태를 고려하여 스스로 전송 가능한 데이터 크기를 결정한다. 즉, **'혼잡 없이 전송할 수 있을 정도의 양'

📌 혼잡 상태를 판단하는 기준

• 중복된 ACK이 여러 번 수신될 경우
• 타임아웃 발생 시

🔚 TCP 연결 종료 과정 (4-Way Handshake)

TCP 연결을 종료하는 과정은 4-Way Handshake를 통해 이루어진다.

1️⃣ 클라이언트 → 서버 (FIN 전송)

• 클라이언트가 서버에게 FIN 세그먼트를 보내 연결 종료를 요청한다.

2️⃣ 서버 → 클라이언트 (ACK 전송)

• 서버는 이를 확인하고 ACK 세그먼트를 클라이언트에게 보낸다.

3️⃣ 서버 → 클라이언트 (FIN 전송)

• 서버는 모든 처리가 끝난 후 클라이언트에게 FIN 세그먼트를 보내 연결 종료를 요청한다.

4️⃣ 클라이언트 → 서버 (ACK 전송)

• 클라이언트가 이를 확인하고 ACK 세그먼트를 서버에게 보내며 연결이 완전히 종료된다.

📌 연결 종료 시 송신 측은 ‘액티브 클로즈’, 수신 측은 ‘패시브 클로즈’ 상태가 된다.

🖥️ TCP의 상태 관리 (TCP State Management)

• TCP(Transmission Control Protocol)는 신뢰성 있는 데이터 전송을 제공하는 스테이트풀(상태 기반) 프로토콜이다.

• 즉, TCP는 통신 과정에서 특정한 연결 상태를 유지하며, 각 상태에 따라 적절한 처리를 수행한다.
• TCP 상태 관리
  • 연결 수립(Connection Establishment),
  • 데이터 전송(Data Transmission),
  • 연결 종료(Connection Termination)

🔹 TCP 연결이 수립되지 않은 상태

TCP 연결이 아직 생성되지 않았거나, 종료된 상태이다.

1️⃣ CLOSED (닫힘 상태)

• 설명: TCP 연결이 존재하지 않는 상태.
• 특징: 모든 통신이 종료된 상태로, 새로운 연결 요청이 없으면 그대로 유지됨.

2️⃣ LISTEN (대기 상태)

• 설명: 서버(수신 측)가 연결 요청(SYN 세그먼트)을 기다리는 상태.
• 특징: passive open 상태에서만 발생하며, 클라이언트로부터 SYN 패킷을 수신하면 SYN-RECEIVED 상태로 이동.

🔹 TCP 연결 수립 과정 (Three-Way Handshake)

TCP는 3단계 핸드셰이크(Three-Way Handshake)를 통해 신뢰성 있는 연결을 수립한다.

3️⃣ SYN-SENT (연결 요청 송신)

• 설명: 클라이언트(액티브 오픈)가 서버에게 SYN 세그먼트를 전송한 상태.
• 특징: 서버의 응답(SYN + ACK)을 기다리며, 응답을 받으면 ESTABLISHED 상태로 이동.

4️⃣ SYN-RECEIVED (연결 요청 수신)

• 설명: 서버가 클라이언트의 SYN 요청을 받고, 이에 대한 응답으로 SYN + ACK를 보낸 상태.
• 특징: 클라이언트가 ACK를 다시 보내면 ESTABLISHED 상태로 이동.

5️⃣ ESTABLISHED (연결 수립)

• 설명: 3단계 핸드셰이크가 완료된 후, 양측이 데이터를 자유롭게 송수신할 수 있는 상태.
• 특징: 정상적인 통신이 이루어지는 상태이며, 이 단계에서 데이터 전송이 가능함.

🔹 TCP 연결 종료 과정 (Four-Way Handshake)

TCP 연결을 종료하기 위해서는 4단계 핸드셰이크(Four-Way Handshake)를 수행한다.

6️⃣ FIN-WAIT-1 (연결 종료 요청 전송)

• 설명: 액티브 클로즈 측(연결을 종료하려는 측)이 FIN 세그먼트를 전송한 상태.
• 특징: 상대방의 ACK를 기다리며, ACK를 수신하면 FIN-WAIT-2 상태로 이동.

7️⃣ CLOSE-WAIT (연결 종료 요청 승인)

• 설명: 패시브 클로즈 측(연결 종료 요청을 받은 측)이 FIN을 받고, ACK를 보낸 상태.
• 특징: 애플리케이션에서 연결 종료 준비를 마친 후 FIN을 보내면 LAST-ACK 상태로 이동.

8️⃣ FIN-WAIT-2 (ACK 수신 후 대기)

• 설명: FIN-WAIT-1 상태에서 상대방의 ACK를 받은 상태.
• 특징: 상대방이 FIN을 보낼 때까지 기다리며, FIN을 받으면 TIME-WAIT 상태로 이동.

9️⃣ LAST-ACK (마지막 FIN 전송)

• 설명: 패시브 클로즈 측이 FIN을 전송한 후, 마지막 ACK를 기다리는 상태.
• 특징: 마지막 ACK를 받으면 CLOSED 상태로 이동하여 연결 종료.

🔟 TIME-WAIT (일정 시간 대기)

• 설명: 액티브 클로즈 측이 FIN에 대한 마지막 ACK를 전송한 후, 일정 시간 동안 대기하는 상태.
• 특징: 중복된 FIN 패킷이 도착할 경우를 대비해 일정 시간 동안 유지되며, 이후 CLOSED 상태로 이동.

🌐 응용 계층 - HTTP의 기초

🔹 DNS와 URI/URL

📌 DNS(Domain Name System)란?

인터넷에서 도메인 네임을 이용해 웹사이트에 접속할 수 있도록 돕는 시스템이다.

• 도메인 네임(Domain Name): 사람이 읽기 쉬운 주소 (예: google.com)
• IP 주소(IP Address): 컴퓨터가 이해할 수 있는 숫자로 된 주소 (예: 142.250.190.78)
• 네임 서버(Name Server): 도메인 네임을 IP 주소로 변환하는 서버

📌 DNS 동작 과정

1️⃣ 사용자가 www.example.com 입력 2️⃣ 브라우저가 로컬 DNS 캐시 확인 3️⃣ 캐시에 없으면 ISP(인터넷 서비스 제공자)의 DNS 서버 조회 4️⃣ ISP의 DNS가 루트 네임 서버를 통해 IP 주소 반환 5️⃣ 최종적으로 해당 IP 주소로 접속

📌 URL(Uniform Resource Locator)과 URI(Uniform Resource Identifier)

URI와 URL은 웹에서 자원을 식별하는 방식이다.

✅ URI: 웹 상의 자원을 식별하기 위한 주소 전체를 의미

✅ URL: URI 중에서도 자원의 위치(Location)를 포함한 것

📌 URL의 구성 요소

https://www.example.com:8080/path/to/resource?query=value#fragment

• Scheme (프로토콜): https:// (HTTP, HTTPS 등)
• Authority (호스트 정보): www.example.com:8080 (도메인 + 포트 번호)
• Path (경로): /path/to/resource (서버 내 자원의 위치)
• Query (쿼리 문자열): ?query=value (추가 정보 전달)
• Fragment (조각): #fragment (페이지 내 특정 위치 지정)

🔹 HTTP의 특징

✅ 1. 요청-응답 기반 프로토콜 클라이언트(브라우저)와 서버가 요청(Request)과 응답(Response)으로 데이터를 주고받는다.

✅ 2. 미디어 독립적 어떤 데이터 유형(HTML, JSON, XML, 이미지 등)도 전송 가능하다.

✅ 3. 스테이트리스(Stateless) 프로토콜 서버는 이전 요청의 상태를 기억하지 않는다.

→ 클라이언트가 매 요청마다 필요한 정보를 전달해야 한다.

✅ 4. 지속 연결(Persistent Connection)

• HTTP/1.0 → 기본적으로 요청-응답 후 연결 종료 (비지속 연결)
• HTTP/1.1 → 기본적으로 연결 유지 (지속 연결, Connection: keep-alive)
• HTTP/2.0 → 다중 요청 처리 가능 (병렬 스트림)

📌 비지속 연결 vs 지속 연결

• 비지속 연결: 요청마다 새 연결 생성, 성능 저하
• 지속 연결: 여러 요청을 하나의 연결에서 처리, 성능 향상

🔹 HTTP 메시지 구조

HTTP 메시지는 크게 요청(Request) 메시지와 응답(Response) 메시지로 나뉜다.

📌 요청 메시지 구조

GET /hello HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

1️⃣ *요청라인(Request Line) * → 시작 라인

• 메서드(Method): GET (요청 방식)
• 요청 대상(Request-Target): /hello (요청 경로)
• HTTP 버전: HTTP/1.1

2️⃣ 헤더(Header) → 필드 라인

• Host: 요청을 보낼 서버 주소
• User-Agent: 클라이언트 정보
• Accept: 받을 수 있는 데이터 타입

3️⃣ 본문(Body, 선택적) → POST 요청에서 데이터 포함

📌 응답 메시지 구조

HTTP/1.1 200 OK
Date: Tue, 19 Mar 2025 12:00:00 GMT
Server: Apache/2.4.41
Content-Type: text/html
Content-Length: 1234

1️⃣ 상태라인(Status Line) → 시작 라인

• HTTP 버전: HTTP/1.1
• 상태 코드: 200
• 이유 구문: OK (성공)

2️⃣ 헤더(Header) → 필드 라인

• Server: 서버 정보
• Content-Type: 응답 데이터 유형
• Content-Length: 데이터 크기

3️⃣ 본문(Body, 선택적) → HTML, JSON 등 데이터 포함

🔹 HTTP 메서드

🔹 HTTP 상태 코드

✅ 1xx (정보성 상태 코드)

✅ 2xx (성공 상태 코드)

✅ 3xx (리디렉션 상태 코드)

✅ 4xx (클라이언트 오류 코드)

✅ 5xx (서버 오류 코드)

Ref. 📗《이것이 취업을 위한 컴퓨터 과학이다 with CS 기술 면접》, 강민철