2JINISHAPPY

분산 시스템의 재앙, Split Brain: 원인 분석부터 글로벌 기업의 대응 전략까지

이진2 — Thu, 22 Jan 2026 18:30:53 +0900

오늘은 고가용성(HA, High Availability) 시스템을 설계하는 엔지니어라면 반드시 정복해야 할 숙제, Split Brain(스플릿 브레인) 현상을 심층적으로 다루어 보겠습니다.

단순히 "서버가 두 개가 된다"는 수준을 넘어, 왜 이 현상이 데이터 정합성을 파괴하는지, 그리고 글로벌 기업들은 어떤 엔지니어링 기법으로 이를 방어하고 있는지 정리했습니다.

1. Split Brain: 왜 분산 시스템의 '악몽'인가?

1.1 개념 정의

분산 시스템에서 Split Brain은 네트워크 단절(Network Partition)로 인해 클러스터가 두 개 이상의 독립적인 그룹으로 쪼개지고, 각 그룹이 서로의 존재를 알지 못한 채 스스로를 Master(Leader)로 승격시키는 현상을 말합니다.

1.2 CAP 정리와 Partition Tolerance

분산 시스템의 근간인 CAP 정리에 따르면, 네트워크 분절(P)이 발생했을 때 시스템은 일관성(C)과 가용성(A) 중 하나를 선택해야 합니다.
Split Brain은 가용성을 억지로 유지하려다 일관성이 완전히 깨져버리는 시나리오입니다. 두 개의 Master가 각각 다른 쓰기 요청을 수락하면, 네트워크가 복구된 후 데이터는 복구 불가능한 '뇌 분리' 상태에 빠지게 됩니다.

2. 글로벌 사례 분석: GitHub의 2018년 24시간 서비스 중단

Split Brain이 실제 비즈니스에 어떤 타격을 주는지 보여주는 가장 유명한 사례는 2018년 10월 발생한 GitHub의 데이터베이스 장애입니다.

장애 전개 (Timeline)

발단: US 동부와 US 서부 데이터센터 간의 광케이블 문제로 약 43초간 네트워크가 단절되었습니다.
현상: GitHub이 사용하는 MySQL HA 솔루션인 Orchestrator가 서부 노드와 통신이 끊기자, 동부 노드를 새로운 Master로 승격시켰습니다.
문제: 하지만 서부 노드(기존 Master)는 여전히 살아있었고, 일부 애플리케이션 서버는 여전히 서부 노드에 쓰기 요청을 보내고 있었습니다.
결과: 양쪽 데이터센터에 서로 다른 데이터가 쌓이는 데이터 정합성 오류가 발생했고, GitHub은 이를 수동으로 대조하여 복구하느라 24시간 넘게 서비스 장애를 겪었습니다.

Key Insight: "Failover(장애 조치)는 빠를수록 좋지만, '정확하지 않은' Failover는 안 하느니만 못하다."

3. 해결을 위한 엔지니어링 메커니즘

3.1 분산 합의 알고리즘 (Raft & Paxos)

현대 분산 시스템(etcd, Kubernetes, Consul 등)은 Raft 알고리즘을 통해 Split Brain을 방어합니다. 핵심은 Quorum(의사정족수)입니다.

공식: $N/2 + 1$ (전체 노드의 과반수 동의 필요)
노드가 3대라면, 최소 2대의 동의를 얻어야 Leader가 됩니다. 네트워크가 1:2로 쪼개지면 1대인 그룹은 절대 Leader가 될 수 없으므로 쓰기 작업을 중단합니다.

3.2 I/O Fencing: "상대방의 손발을 묶어라"

합의만으로는 부족할 때가 있습니다. 확실한 격리를 위해 Fencing(울타리 치기) 기법을 사용합니다.

STONITH (Shoot The Other Node In The Head): 네트워크 응답이 없는 노드의 전원을 원격(IPMI 등)에서 강제로 꺼버립니다.
Resource Fencing: 공유 스토리지 레벨에서 특정 노드의 접근 권한을 즉시 차단합니다.

4. 실전 코드 및 설정 가이드

4.1 Corosync/Pacemaker를 이용한 Quorum 설정

리눅스 클러스터링 도구인 Corosync에서 Split Brain을 방지하기 위한 핵심 설정 예시입니다.

# /etc/corosync/corosync.conf 핵심 설정

totem {
    version: 2
    cluster_name: my_cluster
    transport: udpu
}

quorum {
    # 쿼럼 방식 설정
    provider: corosync_votequorum
    # 노드 수가 2개일 때 특별 처리 (가급적 3개 이상 권장)
    two_node: 0 
    # 과반수 미달 시 서비스 중단 여부 (중요!)
    last_man_standing: 1
    # 쿼럼을 잃었을 때 동작: 'stop'으로 설정하여 데이터 오염 방지
    wait_for_all: 1
}

4.2 Python으로 이해하는 Quorum 로직 (Pseudo-code)

간단한 코드로 Leader 선출 시 Quorum을 체크하는 로직을 시뮬레이션해 보겠습니다.

import time

class Node:
    def __init__(self, node_id, total_nodes):
        self.node_id = node_id
        self.total_nodes = total_nodes
        self.votes = 0
        self.is_leader = False

    def request_vote(self):
        """
        다른 노드들에게 투표를 요청하는 메서드
        실제 환경에서는 RPC(Remote Procedure Call)로 구현됩니다.
        """
        # 네트워크 단절 상황을 가정한 투표 획득 로직
        self.votes = self.get_network_votes() 

        # 쿼럼 체크: 과반수(N/2 + 1)를 넘었는가?
        quorum_size = (self.total_nodes // 2) + 1

        if self.votes >= quorum_size:
            self.is_leader = True
            print(f"[Node {self.node_id}] Quorum 확보 성공! Leader로 승격합니다.")
        else:
            self.is_leader = False
            print(f"[Node {self.node_id}] Quorum 확보 실패 (표수: {self.votes}/{quorum_size}). Standby 유지.")

    def get_network_votes(self):
        # 네트워크 상황에 따라 연결 가능한 노드 수 반환
        pass

# 3개의 노드 중 1개만 연결된 상황 시뮬레이션
node_1 = Node(node_id=1, total_nodes=3)
node_1.votes = 1 # 자신만 연결됨
node_1.request_vote() # 결과: Standby 유지

5. 엔지니어를 위한 Split Brain 방어 설계 원칙 ✅

단순히 "서버를 여러 대 둔다"는 것만으로는 부족합니다. 실제 운영 환경에서 Split Brain을 원천 차단하거나 피해를 최소화하기 위한 3가지 핵심 설계 원칙을 제안합니다.

5.1 홀수 노드 구성과 Quorum 알고리즘의 수학적 근거

분산 시스템에서 노드 수를 홀수로 구성하는 것은 선택이 아닌 필수입니다.

2개 노드 구성 시: 네트워크가 1:1로 단절되면 양쪽 모두 과반수(2/2=1)를 점유할 수 없어 전체 서비스가 중단되거나, 혹은 양쪽 모두 Master가 되는 Split Brain이 발생하기 쉽습니다.
3개 노드 구성 시: 1:2로 단절될 경우, 2대인 그룹이 과반수($3/2 + 1 = 2$)를 확보하여 서비스를 이어가고, 1대인 노드는 스스로 격리됩니다.

5.2 "안전하게 죽기(Fail-fast)" 전략

시스템이 스스로의 상태를 확신할 수 없을 때는 과감하게 프로세스를 종료하는 것이 데이터를 오염시키는 것보다 훨씬 낫습니다.

Watchdog 활용: 하드웨어 또는 소프트웨어 Watchdog을 설정하여, 클러스터 엔진(Corosync 등)이 일정 시간 응답하지 않으면 커널 패닉(Kernel Panic)을 유발해 강제로 시스템을 리부트시킵니다.
Self-Fencing: 노드가 쿼럼을 잃었다고 판단되는 즉시 모든 I/O를 중단하고 Read-only 모드로 전환하거나 프로세스를 Kill 하는 로직을 애플리케이션 레벨에서 구현해야 합니다.

5.3 지연 시간(Latency)과 타임아웃의 상관관계

글로벌 서비스에서는 네트워크 지연이 일시적으로 발생할 수 있습니다. 이때 타임아웃 설정이 너무 짧으면 빈번한 Failover로 인해 오히려 Split Brain 위험이 커집니다.

Heartbeat Timeout > Network Jitter: 네트워크 미세 떨림보다 하트비트 임계치를 길게 설정하되,
Detection Time < Data Inconsistency Time: 데이터가 꼬이기 시작하는 시간보다는 빠르게 감지해야 합니다.

6. [Advanced] Cloud Native 시대의 Split Brain

최근 쿠버네티스(Kubernetes) 환경에서도 etcd 클러스터의 Split Brain은 매우 중요한 이슈입니다.

etcd의 대응 방식

쿠버네티스의 두뇌인 etcd는 Raft 알고리즘을 극단적으로 활용합니다. 만약 etcd가 Split Brain 상태에 빠지면, 쿠버네티스 API 서버는 상태를 업데이트할 수 없게 되어 클러스터 전체의 컨트롤 플레인이 마비됩니다.

실제 클라우드 환경의 예 (AWS Multi-AZ):
가용 영역(Availability Zone) 간의 네트워크 단절이 발생했을 때, AWS는 Elastic IP와 Route53의 헬스 체크를 통해 트래픽을 한쪽으로 강제 유도하지만, DB 레벨에서는 여전히 Split Brain 위험이 존재합니다. 이때는 'Cloud-native Fencing'인 AWS API를 호출하여 반대편 노드의 인스턴스를 강제로 터미네이트(Terminate)하는 방식을 사용하기도 합니다.

7. 결론 및 인사이트: "정합성은 엔지니어의 자존심이다"

Split Brain은 분산 시스템을 다루는 엔지니어에게 피할 수 없는 숙명과도 같습니다. 우리는 '절대 끊기지 않는 네트워크'를 만들 수 없기 때문입니다.

핵심 요약 (TL;DR)

현상: 네트워크 단절로 인해 다수의 Master가 발생하여 데이터 정합성이 깨지는 현상.
원인: 물리적 네트워크 장애, 과도한 시스템 부하로 인한 하트비트 응답 지연.
해결책: * 소프트웨어: Raft/Paxos 알고리즘을 통한 Quorum(다수결) 확보.
- 하드웨어: STONITH 등 Fencing(강제 격리) 기법 적용.
- 설계: 반드시 홀수 노드로 구성하고, 모호할 땐 Fail-fast 할 것.

정리
고가용성(HA)의 목적은 서비스의 영속성이지만, 그 기반에는 데이터의 무결성이 있어야 합니다. 잘못된 Failover로 데이터가 꼬이는 것보다, 차라리 잠시 서비스를 멈추고 데이터를 보호하는 것이 더 성숙한 엔지니어링 의사결정일 수 있습니다.

이벤트 응모 시스템으로 배우는 Redis 분산 락(Distributed Lock) 해결 가이드

이진2 — Wed, 21 Jan 2026 23:14:57 +0900

안녕하세요! 오늘은 백엔드 개발자라면 한 번쯤은 마주하게 되는, 혹은 면접 단골 질문이기도 한 '동시성 제어'에 대해 이야기해보려 합니다.

선착순 이벤트나 한정판 상품 판매 시스템을 구축할 때, 수만 명의 사용자가 동시에 '구매' 버튼을 누르면 어떤 일이 벌어질까요? 단순히 DB의 값을 업데이트하는 방식으로는 데이터의 원자성(Atomicity)을 보장하기 어렵습니다.

오늘은 그 해결책 중 하나인 Redis 분산 락을 활용해 문제를 해결하는 방법을 알아보겠습니다! ‍

1. 왜 DB 락(Lock)만으로는 부족할까?

일반적으로 관계형 데이터베이스(RDBMS)가 제공하는 Pessimistic Lock(비관적 락)이나 Optimistic Lock(낙관적 락)을 떠올릴 수 있습니다. 하지만 다음과 같은 상황에서는 한계가 명확하죠.

성능 저하: DB 자체에 락을 걸면 트랜잭션이 길어질수록 DB 커넥션 점유 시간이 늘어나 전체 처리량이 떨어집니다.
분산 환경: 여러 대의 서버 인스턴스가 동작하는 MSA 환경에서는 각 서버의 로컬 락(e.g. Java의 synchronized)이 무용지물이 됩니다.

이때 활용하기 좋은 도구가 바로 Redis입니다. 메모리 기반이라 빠르고, 모든 명령어가 싱글 스레드로 동작하여 원자성을 보장하기 때문이죠.

2. Redisson 라이브러리를 이용한 분산 락 구현 ️

Redis를 이용해 직접 SETNX 명령어로 락을 구현할 수도 있지만, 타임아웃 처리나 재시도 로직을 직접 짜기엔 위험 요소가 많습니다. 그래서 Java 진영에서는 Redisson 라이브러리를 주로 사용합니다.

핵심 코드 예제 (Spring Boot)

재고를 감소시키는 로직에 분산 락을 적용해 보겠습니다.

@Service
@RequiredArgsConstructor
public class StockService {

    private final RedissonClient redissonClient;
    private final StockRepository stockRepository;

    public void decreaseStock(Long itemId, Long quantity) {
        // 1. Lock 객체 가져오기 (고유한 키 값 설정)
        RLock lock = redissonClient.getLock("ITEM_LOCK:" + itemId);

        try {
            // 2. 락 획득 시도 (waitTime: 락 획득 대기 시간, leaseTime: 락 점유 시간)
            boolean available = lock.tryLock(10, 1, TimeUnit.SECONDS);

            if (!available) {
                throw new RuntimeException("락 획득에 실패했습니다. 잠시 후 다시 시도해주세요.");
            }

            // 3. 비즈니스 로직 수행 (재고 감소)
            Stock stock = stockRepository.findById(itemId).orElseThrow();
            stock.decrease(quantity);
            stockRepository.save(stock);

        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        } finally {
            // 4. 반드시 락 해제 (획득한 스레드인지 확인 필수)
            if (lock.isHeldByCurrentThread()) {
                lock.unlock();
            }
        }
    }
}

코드 포인트 설명

tryLock: 무한정 기다리지 않고 지정된 시간 동안만 락 획득을 시도합니다. 시스템 전체의 행(Hang) 걸림을 방지하죠.
isHeldByCurrentThread: 락을 획득하지 못한 스레드가 다른 스레드의 락을 해제하는 불상사를 막아줍니다.
Pub/Sub 방식: Redisson은 락이 해제될 때 대기 중인 스레드에게 알림을 주는 방식을 사용하여 Redis에 주는 부하를 줄입니다.

3. 주의할 점: 트랜잭션의 커밋 시점 ⚠️

분산 락을 사용할 때 가장 많이 하는 실수 중 하나는 @Transactional과 분산 락의 순서입니다.

성공적인 동시성 제어를 위해서는 반드시 아래의 실행 순서를 지켜야 합니다:

락 획득 (Lock Acquire)
트랜잭션 시작 & 비즈니스 로직 수행
트랜잭션 커밋 (Transaction Commit)
락 해제 (Lock Release)

왜 그럴까요? 만약 트랜잭션이 커밋되기 전에 락이 해제되어 버리면, 대기하던 다른 스레드가 즉시 락을 획득하고 데이터를 읽어갑니다. 하지만 이전 스레드의 변경 사항이 아직 DB에 최종 반영(Commit)되지 않았기 때문에, 다른 스레드는 업데이트 전의 데이터를 읽어 '재고 초과'와 같은 정합성 오류를 일으키게 됩니다.

따라서 실무에서는 보통 서비스 레이어 외부에서 락을 잡고 내부 서비스를 호출하는 Facade 패턴을 주로 사용합니다.

4. 요약 및 인사이트

백엔드 개발자로서 기술을 선택할 때는 항상 트레이드오프(Trade-off)를 고민해야 합니다.

비교 항목 DB Lock (Pessimistic) Redis (Redisson)

속도	상대적으로 느림	매우 빠름 (In-memory)
복잡도	단순함 (SQL 수준)	별도 인프라(Redis) 필요
효율성	커넥션 점유로 부하 발생 가능	Pub/Sub 방식으로 부하 적음
권장 상황	충돌이 적고 단일 DB일 때	초당 요청이 많고 분산 환경일 때

✅ 한 줄 요약

분산 환경에서 데이터 정합성을 확실히 지키고 싶다면, 트랜잭션 범위보다 넓게 설계된 Redis 분산 락을 적극 검토해보자!

서버 장애의 80%는 여기서 시작된다? 커넥션 풀(Connection Pool) 최적화 가이드

이진2 — Tue, 20 Jan 2026 18:00:47 +0900

안녕하세요! 5년 차 주니어 개발자입니다. 오늘은 백엔드 성능의 핵심 보루, **커넥션 풀(Connection Pool, CP)**에 대해 깊이 있게 다뤄보려 합니다.

"사용자가 많아지면 무조건 풀 크기를 늘리면 될까?" "언제 풀이 부족하다는 걸 알 수 있을까?" 실무에서 마주하는 이 질문들에 대해 명쾌한 해답과 모니터링 노하우를 공유합니다!

1. 커넥션 풀(Connection Pool)이란? ‍♂️

DB 커넥션 풀은 미리 일정한 수의 **데이터베이스 연결(Connection)**을 만들어 '풀(Pool)' 속에 보관해 두었다가, 요청이 올 때마다 빌려주고 반납받는 방식입니다.

왜 직접 연결하지 않고 '풀'을 사용하나요? (Why?)

DB와 매번 새로 연결하는 작업(TCP 3-way handshake 등)은 비용이 매우 비쌉니다.

시간 절약: 미리 연결된 객체를 사용하여 응답 속도를 높입니다.
자원 보호: 무한정 연결이 생기는 것을 방지하여 DB 서버의 부하를 조절합니다.

2. 실전! 커넥션 풀을 언제 늘리고 줄여야 할까?

설정값보다 중요한 것이 현재 상태를 확인하는 방법입니다. 서비스 모니터링(Grafana, CloudWatch 등) 시 다음 지표를 유심히 보세요.

✅ 이런 상황엔 "늘려야 합니다" (Scale-Up)

Connection Wait Time 증가: 클라이언트가 커넥션을 빌리기 위해 대기하는 시간이 길어진다면, 현재 풀이 모든 요청을 소화하지 못하고 있다는 뜻입니다.
Pool Usage(사용률)가 90% 이상: 피크 타임에 사용률이 지속적으로 높다면 여유분을 확보해야 합니다.
Active Connections vs Pending Threads: 활성 커넥션은 꽉 찼는데, 커넥션을 기다리는 스레드(Pending)가 쌓이고 있다면 증설이 필요합니다.

✅ 이런 상황엔 "줄여야 합니다" (Scale-Down)

DB 서버 CPU/Memory 부하: WAS는 멀쩡한데 DB 서버의 CPU 사용률이 너무 높다면, 너무 많은 커넥션이 Context Switching을 일으키고 있을 확률이 큽니다.
Idle Connections 과다: 평소에 사용되지 않고 노는 커넥션이 너무 많다면 메모리 낭비입니다.
Deadlock 발생 빈도 증가: 커넥션이 너무 많으면 트랜잭션 간 경합이 심해져 데드락이 더 자주 발생할 수 있습니다.

3. 주니어 개발자가 흔히 하는 착각: "많을수록 좋다?" ❌

"차선이 많으면 무조건 차가 안 밀리겠지?"라고 생각하기 쉽지만, DB는 그렇지 않습니다.

HikariCP 공식 가이드의 권장 공식

가장 널리 쓰이는 커넥션 풀 라이브러리인 HikariCP는 아래와 같은 공식을 제안합니다.

$$connections = ((core\\_count * 2) + effective\\_spindle\\_count)$$

핵심: DB 서버의 CPU 코어 수에 맞춰 적절한 제한을 두는 것이, 무작정 늘리는 것보다 훨씬 빠릅니다.

4. 실무에서 바로 써먹는 설정 튜닝 포인트 ️

# Spring Boot application.yml 예시
spring:
  datasource:
    hikari:
      maximum-pool-size: 20 # 부하 테스트를 통해 결정 (보통 10~50 사이)
      minimum-idle: 20      # maximum-pool-size와 동일하게 설정 권장
      connection-timeout: 3000 # 3초 이상 대기 시 에러 (사용자 경험 보호)
      max-lifetime: 1800000    # DB의 wait_timeout보다 무조건 2~3분 짧게!

프로젝트 설정 파일(application.yml)에 적용할 핵심 파라미터입니다.

maximum-pool-size: 최대 풀 크기. 보통 10~50 사이에서 부하 테스트 후 결정합니다.
minimum-idle: 최소 유휴 연결 수. 성능을 위해 maximum-pool-size와 동일하게 맞추는 것을 권장합니다.
connection-timeout: 커넥션 획득 대기 시간. 보통 3000ms(3초) 내외로 설정합니다.
max-lifetime: 커넥션 최대 수명. DB의 wait_timeout보다 무조건 2~3분 짧게 설정하는 것이 장애 방지의 핵심입니다.

5. 요약 및 마무리

커넥션 풀은 서버의 '호흡기'와 같습니다. 단순히 값을 크게 잡는 것이 아니라, 모니터링 지표를 바탕으로 우리 서비스에 맞는 최적의 값을 찾아가야 합니다.

한 줄 요약

"커넥션 풀 튜닝의 핵심은 모니터링 지표를 바탕으로 DB 서버가 감당할 수 있는 최적의 '한계치'를 찾는 것이다."

출처 및 참고 자료

HikariCP Wiki: About Pool Sizing
Baeldung: A Guide to HikariCP
MySQL Docs: How MySQL Handles Client Connections
Oracle Blog: Real World Connection Pool Sizing

네트워크 대역폭(Bandwidth)이란?

이진2 — Mon, 19 Jan 2026 13:41:57 +0900

오늘은 백엔드 서버를 설계하고 운영할 때 절대 간과해서는 안 될 요소, 바로 네트워크 대역폭(Bandwidth)에 대해 이야기해보려 합니다.

서버 로직 최적화에는 공을 들이면서, 정작 데이터가 오가는 '길'에 대해서는 무관심하지 않으셨나요? 대역폭을 이해하면 성능 개선은 물론 인프라 비용까지 획기적으로 줄일 수 있습니다.

1. 대역폭(Bandwidth)이란 무엇인가?

네트워크 대역폭은 단위 시간 내에 전송할 수 있는 데이터의 최대 용량을 의미합니다. 흔히 속도와 혼동하지만, 정확히는 '통로의 넓이'에 가깝습니다.

핵심 개념 비교

용어	개념	비유
대역폭 (Bandwidth)	이론상 최대 전송 가능량	고속도로의 차선 수 (8차선 vs 2차선)
처리량 (Throughput)	실제로 전송된 데이터 양	1시간 동안 실제 통과한 차량 수
지연 시간 (Latency)	데이터가 도달하는 데 걸리는 시간	출발지에서 목적지까지 도달하는 시간

2. 서버 개발자가 대역폭에 민감해야 하는 이유 (Why?)

① 클라우드 비용의 주범: Data Transfer Out

대부분의 클라우드 서비스(AWS, Azure 등)는 서버로 들어오는 트래픽은 무료지만, 서버에서 외부로 나가는 트래픽(Egress)에 대해서는 과금을 합니다. 대역폭 최적화가 곧 기술적인 비용 절감(Cost Optimization)인 셈이죠.

② 시스템의 병목 현상 (Bottleneck)

아무리 DB 인덱싱을 잘하고 서버가 0.1초 만에 응답을 생성해도, 결과 데이터가 너무 커서 대역폭 제한에 걸리면 사용자는 결국 '느린 서비스'라고 느끼게 됩니다.

3. 대역폭 최적화를 위한 실전 전략 (How?)

✅ 1. 응답 데이터 압축 (Gzip / Brotli)

가장 기본적이면서 효과적인 방법입니다. JSON이나 HTML 같은 텍스트 데이터는 압축 효율이 매우 좋습니다.

// Node.js Express 기준 압축 적용 예시
const compression = require('compression');
const express = require('express');
const app = express();

// 모든 응답에 Gzip 압축 적용
app.use(compression());

app.get('/api/users', (req, res) => {
// 거대한 JSON 데이터도 압축되어 전송됨
res.json({ users: Array(1000).fill({ id: 1, name: 'Gemini' }) });
});

✅ 2. 효율적인 데이터 포맷 선택

JSON은 사람이 읽기 좋고 디버깅이 편하지만, 데이터 크기 면에서는 불리할 수 있습니다. 특히 내부 서버 간 통신(MSA)이나 트래픽이 막대한 구간에서는 Protocol Buffers(protobuf)나 MessagePack 같은 바이너리 포맷을 고려해 보세요.

JSON: {"id": 123, "name": "John"} -> 텍스트 기반이라 필드명 중복이 발생하고 용량이 큼.
Protobuf: 이진(Binary) 데이터로 직렬화되어 데이터 크기가 JSON 대비 최대 1/10까지 줄어듭니다.

✅ 3. CDN 및 캐싱 활용

정적 파일(이미지, JS, CSS)은 API 서버의 대역폭을 소모하지 않도록 CDN(Content Delivery Network)으로 분산시켜야 합니다.

Origin 서버 보호: 사용자의 요청이 서버로 직접 오지 않고 전 세계 곳곳의 Edge Server에서 처리됩니다.
캐시 헤더 활용: Cache-Control을 적절히 설정하여 동일한 리소스를 중복해서 전송하지 않도록 합니다.

✅ 4. 지연 로딩(Lazy Loading) 및 페이지네이션

한 번에 모든 데이터를 응답하는 대신, 사용자가 필요한 시점에 맞춰 데이터를 쪼개서 전송하는 전략입니다.

Pagination: 10,000개의 목록을 한 번에 주지 않고 20개씩 끊어서 응답합니다.
Partial Response: 클라이언트가 필요한 필드만 선택해서 가져갈 수 있도록 설계합니다. (예: GraphQL)

4. 요약 및 인사이트

네트워크 대역폭은 무한하지 않은 비싼 자원입니다. 서버 개발자는 단순히 기능 구현을 넘어, 내가 설계한 데이터 구조가 네트워크 환경에 어떤 부하를 주는지 항상 고민해야 합니다.

한 줄 요약

"데이터를 보내기 전에 압축하고, 적절한 포맷을 선택하며, 정적 자원은 CDN에 맡겨 대역폭을 효율적으로 사수하자!"

출처 및 참고 자료

MDN Web Docs: Bandwidth - 네트워크 용어 사전
AWS Architecture Blog: Top 10 tips for optimizing network costs
High Performance Browser Networking (Ilya Grigorik 저): 네트워크 성능 최적화의 필독서
Google Developers: Protocol Buffers Documentation
Cloudflare Learning: What is Bandwidth? | Bandwidth vs Speed

[LeetCode] Rotate Array: 배열 회전 마스터하기 (Kotlin 풀이 및 최적화 전략)

이진2 — Fri, 16 Jan 2026 23:18:30 +0900

오늘은 기술 면접 단골 문제인 LeetCode의 189. Rotate Array 문제를 함께 살펴보겠습니다. 배열을 다루는 기본적인 감각은 물론, 공간 복잡도 최적화 능력을 어필하기 아주 좋은 문제입니다.

문제 개요

주어진 정수 배열 nums를 오른쪽으로 k단계만큼 회전시키는 문제입니다.

Input: nums = [1,2,3,4,5,6,7], k = 3
Output: [5,6,7,1,2,3,4]
핵심 조건: k는 음수가 아닐 수 있으며, 배열의 길이보다 클 수 있습니다. 또한, 가능하다면 O(1) 공간 복잡도(In-place)로 해결하는 것이 권장됩니다.

첫 번째 접근: 임시 배열 활용하기 (Space O(n))

코드 구현 (Kotlin)

class Solution {
    fun rotate(nums: IntArray, k: Int): Unit {
        // 1. 원본 배열과 같은 크기의 임시 리스트 생성
        val temp = MutableList(nums.size) { 0 }

        // 2. 각 인덱스에 들어갈 위치 계산하여 할당
        for (index in nums.indices) {
            // (index + nums.size - (k % nums.size)) % nums.size 공식을 사용해
            // 회전 후 해당 자리에 와야 할 원본 데이터를 찾아옵니다.
            temp[index] = nums[(index + nums.size - (k % nums.size)) % nums.size]
        }

        // 3. 원본 배열에 결과 복사
        for (index in temp.indices) {
            nums[index] = temp[index]
        }
    }
}

분석 및 특징장점: 로직이 직관적입니다. 각 칸이 어디서 데이터를 가져올지 수식으로 명확히 정의됩니다.

시간 복잡도: $O(n)$ - 배열을 두 번 순회합니다.
공간 복잡도: $O(n)$ - 원본 배열과 동일한 크기의 temp 리스트가 필요합니다.

더 나은 방법은 없을까? (공간 최적화: In-place)

실제 개발 인터뷰에서는 "추가 메모리를 사용하지 않고(O(1)) 해결할 수 있나요?"라는 후속 질문이 들어올 확률이 매우 높습니다.
이때 사용할 수 있는 마법 같은 방법이 바로 배열 뒤집기(Reverse) 전략입니다.

뒤집기 전략 3단계

전체 배열을 뒤집는다.
앞부분 k개를 뒤집는다.
나머지 뒷부분을 뒤집는다.

이 방식을 사용하면 별도의 메모리 할당 없이 배열 안에서 요소의 위치만 바꿔 문제를 해결할 수 있습니다.

최적화 코드 (Kotlin)

    class Solution {
      fun rotate(nums: IntArray, k: Int): Unit {
          val n = nums.size
          // k가 n보다 클 수 있으므로 나머지 연산 필수!
          val realK = k % n 

          // 1. 전체 뒤집기: [7, 6, 5, 4, 3, 2, 1]
          reverse(nums, 0, n - 1)
          // 2. 앞부분 k개 뒤집기: [5, 6, 7, 4, 3, 2, 1]
          reverse(nums, 0, realK - 1)
          // 3. 뒷부분 뒤집기: [5, 6, 7, 1, 2, 3, 4] -> 완성!
          reverse(nums, realK, n - 1)
      }

      private fun reverse(nums: IntArray, start: Int, end: Int) {
          var s = start
          var e = end
          while (s < e) {
              val temp = nums[s]
              nums[s] = nums[e]
              nums[e] = temp
              s++
              e--
          }
      }
  }

‍ 시니어 엔지니어의 인사이트

k % nums.size를 잊지 마세요

면접관은 경계 조건(Edge Case) 처리를 유심히 봅니다.
만약 배열 길이가 3인데 k가 10이라면, 실제로는 1번 회전한 것(10 % 3 = 1)과 같습니다.
이 처리가 누락되면 성능 저하나 에러가 발생할 수 있습니다.

공간 복잡도와 트레이드 오프처음 작성하신 O(n) 공간 방식은 코드가 명확하고 이해하기 쉽다는 장점이 있습니다.

반면 O(1) 방식은 메모리 효율은 극대화되지만 "배열을 세 번 뒤집는다"는 논리를 미리 알고 있어야 구현이 쉽습니다.
상황에 맞는 최적의 해법을 제시하고 이유를 설명하는 능력이 중요합니다.

✅ 한 줄 요약배열 회전 문제는 전체 뒤집기 후 부분 뒤집기 전략을 사용하면 추가 메모리 없이 $O(n)$ 시간 안에 해결 가능하다!

출처

LeetCode 189. Rotate Array: https://leetcode.com/problems/rotate-array/

[LeetCode] 27. Remove Element

이진2 — Sun, 2 Mar 2025 14:22:31 +0900

class Solution(object):
    def removeElement(self, nums, val):
        result = []
        k = 0

        for i in nums:
            if val != i:
                k+=1
                result+=[i]
        
        nums[:] = result[:]
        return k

https://leetcode.com/problems/remove-element/?envType=study-plan-v2&envId=top-interview-150

주어진 배열 nums에서 val 이라는 값을 전부 제거한 뒤, val이 아닌 원소의 개수를 반환하는 문제

새로운 배열을 만들어서 val이 아닌 값을 push한 뒤 k의 값을 카운트 하는 방식으로 풀었다

새로운 배열을 만들어서 교체하는 방식이 아니라 실제 배열에서 교체하는 방식으로도 풀 수 있을까?

[LeetCode] 88. Merge Sorted Array

이진2 — Sun, 23 Feb 2025 16:08:30 +0900

오랜만에 리트코드를 풀어봤다

https://leetcode.com/problems/merge-sorted-array/?envType=study-plan-v2&envId=top-interview-150

오름차순으로 정렬된 두 개의 배열을 합치는 것

포인터 두 개를 사용했고, 마지막 인덱스 처리하기 번거로워서 각각의 배열 양 끝에 max number 값을 넣어주었다

import sys

class Solution(object):
    def merge(self, nums1, m, nums2, n):
        i = 0
        j = 0
        result = []
        nums1+=[sys.maxsize]
        nums2+=[sys.maxsize]

        while i<m or j<n :
            if nums1[i]<nums2[j] and i<m:
                result+=[nums1[i]]
                i+=1
            else:
                result+=[nums2[j]]
                j+=1
        
        nums1[:]=result

오랜만에 푸니까 파이썬도 c도 문법이 하나도 생각 안 난다 ㅎㅎ

kubernetes components

이진2 — Sun, 12 Nov 2023 16:05:34 +0900

https://kubernetes.io/images/docs/components-of-kubernetes.svg

https://kubernetes.io/images/docs/kubernetes-cluster-architecture.svg

쿠버네티스는 컨테이너를 파드 내에 배치하고 노드에서 실행함으로서 워크로드를 구동한다.

Node

클러스터 내 설치되는 가상 혹은 물리 머신을 의미.

과거에는 미니언즈라는 용어로 불렀다. 용어는 현재도 혼용해서 사용한다.

어플리케이션이 실행중이다가 노드가 죽을 수도 있으니, 일반적으로 클러스터에는 여러 개의 노드를 둔다.

Cluster

노드(워커 머신)의 집합.

모든 클러스터는 최소 한 개 이상의 워커 노드를 가진다.

클러스터 외부에서 관점에서는 하나의 노드가 죽어도 다른 노드로 접근 가능하기 때문에, 부하 분산 및 고가용성을 보장한다.

고가용성을 보장하기 위해서는 쿠버네티스 자체적으로 다음의 일을 지속적으로 수행해야 한다.

모든 클러스터를 관리하고, 관리중인 자원의 정보를 저장하고, 노드를 모니터링 하고, 상태를 감지해서 다른 노드로 트래픽을 옮기는 작업이다.

이걸 수행하는 컴포넌트를 마스터 노드라고 하고, 그 외의 노드는 모두 워커 노드라고 칭한다.

마스터 노드는 쿠버네티스 자체에 내장되있는 하나의 노드이며, 워커 노드들 사이에서 실제 컨테이너 오케스트레이션을 관장한다.

쿠버네티스를 설치하면 실제로 아래의 것들도 함께 설치된다.

Control Plain Component

kube-apiserver

쿠버네티스 API를 외부에 노출하는 컴포넌트.

유저, 매니징 디바이스, CLI를 포함한 외부에서 내부 클러스터로 접근하기 위해 거치는 프론트 엔드다.

etcd

distributed, reliable key value store

쿠버네티스가 클러스터를 관리하는 데 필요한 모든 데이터를 저장하는 곳.

여러 클러스터에서 마스터와 여러 워커 노드를 각각의 방식으로 구동중이라면, etcd는 락을 이용해서 각각의 마스터가 컨플릭트가 발생하지 않게끔 관리한다.

kube-scheduler

(노드가 배정되지 않은) 새로 생성된 파드를 감지하고, 실행할 노드를 선택하는 스케줄러.

스케줄링 고려 요소에는 리소스에 대한 요구사항, affinity & anti-affinity, 데이터 지역성 등을 포함한다.

kube-controller-manager

노드, 잡, 엔드포인트, 서비스어카운트 컨트롤러로 구성되어 있다.

이들 모두 분리된 프로세스지만, 복잡성을 낮추기 위해 단일 바이너리로 컴파일 되고 단일 프로세스 내에서 실행한다.

간략한 역할로는 노드/컨테이너가 다운되었을 때 이를 감지하고 대응하거나, 새로운 컨테이너를 생성하기 위한 결정을 내린다.

Node Component

실행중인 파드를 유지하고, 쿠버네티스 런타임 환경을 제공하며 모든 노드 상에서 동작한다.

kubelet

클러스터의 각 노드 내에서 실행되는 에이전트. 파드 내의 컨테이너들이 기대하는 대로 돌아가도록 관리한다.

container runtime

컨테이너를 실행하는 데 사용되는 기본 소프트웨어

도커를 많이 사용하지만, 정식 CRI 구현체는 아니다. containerd, CRI-O가 이에 속한다.

참고

(kotlin)gradle spring boot application dockerize

이진2 — Thu, 28 Sep 2023 19:07:59 +0900

https://spring.io/guides/topicals/spring-boot-docker/

Getting Started | Spring Boot Docker

The Spring Boot Maven and Gradle plugins use buildpacks in exactly the same way that the pack CLI does in the following examples. The resulting images are identical, given the same inputs. Cloud Foundry has used containers internally for many years now, an

spring.io

1. spring boot application initialize

https://start.spring.io/ 에서 생성했다

앱 특성에 따라 아무거나 골라도 상관 없지만 kotlin+gradle 설정이 필요하다.

2. Dockerfile 작성

FROM eclipse-temurin:17-jdk
VOLUME /tmp
ARG JAR_FILE
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["java","-jar","/app.jar"]

간단한 도커파일을 작성했다.

앱이 무거워져서 이미지 빌드 시간이 길어질 경우 layered jar를 활용한 멀티 스테이지 빌드로 시간 단축이 가능하다.

3. docker build

4. 실행

이 방식이 있고, palantir라는 라이브러리를 사용해서 gradle task로 추가해 사용하는 방법이 있다.

https://plugins.gradle.org/plugin/com.palantir.docker

Gradle - Plugin: com.palantir.docker

Version 0.35.0 (latest) Created 03 April 2023. Gradle Docker is a simple docker orchestrator for executing docker build and push from within Gradle. plugins { id("com.palantir.docker") version "0.35.0" } buildscript { repositories { maven { url = uri("http

plugins.gradle.org

또, spring boot 프로젝트라면 2.3 이후 버전부터는 maven, gradle 빌드팩 지원이 포함되어 있다.

https://spring.io/blog/2020/01/27/creating-docker-images-with-spring-boot-2-3-0-m1

Creating Docker images with Spring Boot 2.3.0.M1

Spring Boot 2.3.0.M1 has just been released and it brings with it some interesting new features that can help you package up your Spring Boot application into Docker images. In this blog post we’ll take a look at the typical ways developers create Docker

spring.io

별다른 설정 없이 bootBuildImage gradle task를 실행하면 이미지가 빌드되고, 위와 똑같이 실행된다.

빌드 파이프라이닝이 복잡하지 않은 초기 애플리케이션이라면 이렇게 구성해도 괜찮을 것 같다.

Engine=InnoDB는 뭘 지정해주는 걸까 - MySQL 엔진과 스토리지 엔진

이진2 — Sun, 9 Jul 2023 23:05:28 +0900

MySQL 아키텍처

MySQL 서버는 MySQL 엔진, 스토리지 엔진으로 구분
스토리지 엔진은 핸들로 API를 만족하면 누구든 구현해서 서버에 추가 가능

MySQL 엔진 아키텍처

출처: https://dev.mysql.com/doc/refman/8.0/en/images/mysql-architecture.png

MySQL 엔진

MySQL 엔진은 아래의 역할들을 수행하며 요청된 SQL 문장을 분석, 최적화하는 핵심 처리를 함

커넥션 핸들러: 클라이언트로부터의 접속 및 쿼리 요청을 처리
SQL 파서
전처리기
옵티마이저: 쿼리를 최적화 하여 실행

스토리지 엔진

실제 데이터를 디스크 스토리지에 저장하거나 데이터를 읽어오는 부분을 전담
스토리지 엔진은 여러 개를 동시에 사용할 수 있다
각 스토리지 엔진은 성능 향상을 위해 키 캐시나 InnoDB 버퍼 풀과 같은 기능을 내장

mysql> CREATE TABLE test_table (fb1 INT, fb2 INT) ENGINE=INNODB;

핸들러 API

핸들러 API: MySQL 엔진의 쿼리 실행기에서 데이터를 쓰거나 읽을 때 스토리지 엔진에 요청하는 API
InnoDB 스토리지 엔진 또한 이 핸들러 API를 이용해 MySQL 엔진과 데이터를 주고받음

MySQL 스레딩 구조

출처: Real MySQL 1권 - 그림 4.2

MySQL 서버는 프로세스 기반이 아니라 스레드 기반으로 작동하며, 크게 포그라운드 스레드와 백그라운드 스레드로 구분한다

포그라운드 스레드(클라이언트 스레드)

주로 클라이언트 사용자가 요청하는 쿼리 문장을 처리
최소 MySQL 서버에 접속된 클라이언트의 수만큼 존재
커넥션이 종료되면 스레드는 다시 스레드 캐시로 되돌아간다. 스레드 캐시에 일정 개수 이상이 대기 중이면 캐시에 넣지 않고 종료시켜 일정 개수의 스레드만 캐시에 존재하게 한다.

백그라운드 스레드

인서트 버퍼를 병합하는 스레드
로그를 디스크로 기록하는 스레드
InnoDB 버퍼 풀의 데이터를 디스크에 기록하는 스레드
데이터를 버퍼로 읽어 오는 스레드
잠금이나 데드락을 모니터링하는 스레드

InnoDB에서도 데이터를 읽는 작업은 주로 클라이언트 스레드에서 처리되기 때문에 읽기 스레드는 많이 설정할 필요 없다.

사용자의 요청을 처리하는 도중 데이터의 쓰기 작업은 지연(버퍼링)되어 처리될 수 있지만 데이터의 읽기 작업은 절대 지연될 수 없다.

메모리 할당 및 사용 구조

출처: Real MySQL 1권 - 그림 4.3

글로벌 메모리 영역과 로컬 메모리 영역으로 구분
글로벌 메모리 영역의 모든 메모리 공간은 MySQL 서버가 시작되면서 운영체제로부터 할당.

글로벌 메모리 영역

클라이언트 스레드 수와 무관하게 하나의 메모리 공간만 할당
필요에 따라 2개 이상의 메모리 공간을 할당받을 수 있지만 클라이언트의 스레드 수와는 무관하다.
영역
- 테이블 캐시
- InnoDB 버퍼 풀
- InnoDB 어댑티브 해시 인덱스
- InnoDB 리두 로그 버퍼

로컬 메모리 영역(세션 메모리 영역)

MySQL 서버의 클라이언트 스레드가 쿼리를 처리하는 데 사용하는 메모리 영역
로컬 메모리는 각 클라이언트 스레드별로 독립적으로 할당되며 절대 공유되어 사용되지 않는다는 특징이 있다.
영역
- 커넥션 버퍼
- 정렬 버퍼
- 조인 버퍼
- 바이너리 로그 캐시
- 네트워크 버퍼

세션이 너무 많아지면 "세션별 버퍼 크기 * 세션 수"만큼의 메모리 비용이 추가로 든다.

플러그인 스토리지 엔진 모델

전문 검색 엔진을 위한 검색어 파서도 플러그인 형태로 개발해서 사용 가능
MySQL에서 쿼리가 실행되는 과정 중 대부분의 작업은 MySQL엔진에서 처리되고, 마지막 데이터 읽기/쓰기 작업만 스토리지 엔진에 의해 처리.
- 실질적인 GROUP BY나 ORDER BY 등 복잡한 처리는 스토리지 엔진 영역이 아닌, MySQL 엔진의 처리 영역인 쿼리 실행기에서 처리.
하나의 쿼리 작업이 여러 하위 작업으로 나뉠 때, 각 작업이 MySQL 엔진 영역에서 처리되는지 아니면 스토리지 엔진 영역에서 처리되는지 구분할 줄 알아야 한다.
MySQL 서버에서는 스토리지 엔진뿐만 아니라 다양한 기능을 플러그인 형태로 지원한다.

쿼리 실행 구조

출처: Real MySQL 1권 - 그림 4.6

쿼리 파서

사용자 요청으로 들어온 쿼리 문장을 토큰으로 분리해 트리 형태의 구조로 만들어내는 작업
쿼리 문장의 기본 문법 오류는 이 과정에서 발견되어 사용자에게 오류 메시지를 전달한다.

전처리기

파서 과정에서 만들어진 파서 트리를 기반으로 쿼리 문장에 구조적인 문제점이 있는지 확인
내장 함수와 같은 개체를 매핑해 해당 객체 존재 여부와 객체의 접근 권한 등을 확인

옵티마이저

사용자의 요청으로 들어온 쿼리 문장을 저렴한 비용으로 가장 빠르게 처리할지를 결정하는 역할

실행 엔진

만들어진 계획대로 각 핸들러에게 요청해서 받은 결과를 또 다른 핸들러 요청의 입력으로 연결하는 역할을 수행

핸들러(스토리지 엔진)

MySQL 서버 가장 밑단에서 실행 엔진의 요청에 따라 데이터를 디스크로 저장하고 디스크로부터 읽어 오는 역할을 담당.

스레드 풀

내부적으로 사용자의 요청을 처리하는 스레드 개수를 제한해서, 동시 처리되는 요청이 많더라도 MySQL 서버의 CPU가 제한된 개수의 처리에만 집중할 수 있게 하는 목적
제한된 수의 스레드만으로 CPU가 처리하도록 적절히 유도하면 불필요한 컨텍스트 스위치를 줄여 오버헤드를 낮출 수 있다.
일반적으로 CPU 코어의 개수와 스레드 그룹의 개수를 맞추는 것이 CPU 프로세서 친화도를 높이는데 좋다.
스레드 그룹의 모든 스레드가 일을 처리하고 있다면 스레드 풀은 스레드 그룹에 새로운 작업 스레드를 추가할지, 아니면 기존 작업 스레드가 처리를 완료할 때까지 기다릴지 여부를 판단.

트랜잭션 지원 메타데이터

테이블의 구조 정보와 스토어드 프로그램 등의 정보를 데이터 딕셔너리 또는 메타데이터라고 한다.
- 기존에는 파일 기반의 메타데이터는 생성 및 변경 작업이 트랜잭션을 지원하지 않기 때문에 테이블의 생성 또는 변경 도중에 MySQL 서버가 비정성적으로 종료되면 일관되지 않은 상태로 남는 문제가 발생
8.0부터는 테이블의 구조 정보나 스토어드 프로그램의 코드 관련 정보를 모두 InnoDB의 테이블에 저장하도록 개선

2JINISHAPPY

분산 시스템의 재앙, Split Brain: 원인 분석부터 글로벌 기업의 대응 전략까지

1. Split Brain: 왜 분산 시스템의 '악몽'인가?

1.1 개념 정의

1.2 CAP 정리와 Partition Tolerance

2. 글로벌 사례 분석: GitHub의 2018년 24시간 서비스 중단

장애 전개 (Timeline)

3. 해결을 위한 엔지니어링 메커니즘

3.1 분산 합의 알고리즘 (Raft & Paxos)

3.2 I/O Fencing: "상대방의 손발을 묶어라"

4. 실전 코드 및 설정 가이드

4.1 Corosync/Pacemaker를 이용한 Quorum 설정

4.2 Python으로 이해하는 Quorum 로직 (Pseudo-code)

5. 엔지니어를 위한 Split Brain 방어 설계 원칙 ✅

5.1 홀수 노드 구성과 Quorum 알고리즘의 수학적 근거

5.2 "안전하게 죽기(Fail-fast)" 전략

5.3 지연 시간(Latency)과 타임아웃의 상관관계

6. [Advanced] Cloud Native 시대의 Split Brain

etcd의 대응 방식

7. 결론 및 인사이트: "정합성은 엔지니어의 자존심이다"

핵심 요약 (TL;DR)

함께 보면 좋은 글

이벤트 응모 시스템으로 배우는 Redis 분산 락(Distributed Lock) 해결 가이드

1. 왜 DB 락(Lock)만으로는 부족할까?

2. Redisson 라이브러리를 이용한 분산 락 구현 ️

핵심 코드 예제 (Spring Boot)

3. 주의할 점: 트랜잭션의 커밋 시점 ⚠️

4. 요약 및 인사이트

✅ 한 줄 요약

함께 보면 좋은 글

서버 장애의 80%는 여기서 시작된다? 커넥션 풀(Connection Pool) 최적화 가이드

1. 커넥션 풀(Connection Pool)이란? ‍♂️

왜 직접 연결하지 않고 '풀'을 사용하나요? (Why?)

2. 실전! 커넥션 풀을 언제 늘리고 줄여야 할까?

✅ 이런 상황엔 "늘려야 합니다" (Scale-Up)

✅ 이런 상황엔 "줄여야 합니다" (Scale-Down)

3. 주니어 개발자가 흔히 하는 착각: "많을수록 좋다?" ❌

HikariCP 공식 가이드의 권장 공식

4. 실무에서 바로 써먹는 설정 튜닝 포인트 ️

5. 요약 및 마무리

한 줄 요약

함께 보면 좋은 글

출처 및 참고 자료

네트워크 대역폭(Bandwidth)이란?

1. 대역폭(Bandwidth)이란 무엇인가?

핵심 개념 비교

2. 서버 개발자가 대역폭에 민감해야 하는 이유 (Why?)

① 클라우드 비용의 주범: Data Transfer Out

② 시스템의 병목 현상 (Bottleneck)

3. 대역폭 최적화를 위한 실전 전략 (How?)

✅ 1. 응답 데이터 압축 (Gzip / Brotli)

✅ 2. 효율적인 데이터 포맷 선택

✅ 3. CDN 및 캐싱 활용

✅ 4. 지연 로딩(Lazy Loading) 및 페이지네이션

4. 요약 및 인사이트

한 줄 요약

함께 보면 좋은 글

출처 및 참고 자료

[LeetCode] Rotate Array: 배열 회전 마스터하기 (Kotlin 풀이 및 최적화 전략)

문제 개요

첫 번째 접근: 임시 배열 활용하기 (Space O(n))

코드 구현 (Kotlin)

더 나은 방법은 없을까? (공간 최적화: In-place)

최적화 코드 (Kotlin)

‍ 시니어 엔지니어의 인사이트

함께 보면 좋은 글

출처

[LeetCode] 27. Remove Element

[LeetCode] 88. Merge Sorted Array

kubernetes components

Node

Cluster

Control Plain Component

kube-apiserver

etcd

kube-scheduler

kube-controller-manager

Node Component

kubelet

container runtime