THE 1995 DevOps Note

Thundering Herd 란?

NellKiM — Thu, 23 Apr 2026 11:12:58 +0900

Thundering Herd(우르르 몰려드는 소떼) 문제는 컴퓨터 과학 및 시스템 엔지니어링에서 발생하는 고전적인 성능 병목 현상이다.

말 그대로 수많은 프로세스나 스레드가 어떤 이벤트(예: 락 해제, 서비스 복구, 캐시 만료 등)를 기다리다가, 이벤트가 발생하는 순간 동시에 깨어나 하나의 리소스를 차지하기 위해 격렬하게 경쟁하는 상황을 의미한다.

1. 주요 발생 시나리오

Thundering Herd 문제는 인프라와 애플리케이션 아키텍처 전반에 걸쳐 다양한 형태로 나타난다.

캐시 스탬피드 (Cache Stampede / Cache Miss Storm): 가장 흔하게 접할 수 있는 시나리오이다. 트래픽이 매우 높은 특정 데이터(예: 메인 화면의 공지사항)의 캐시 TTL(Time-To-Live)이 만료되었다고 가정하면, 그 순간 수천 개의 요청이 동시에 들어오면, 모든 요청이 '캐시 미스(Cache Miss)'를 겪고 동시에 원본 데이터베이스(DB)로 쿼리를 날려 DB가 과부하로 다운될 수 있다.
프로세스/스레드 웨이크업 (Process Wake-up): 전통적인 운영체제 수준의 문제이다. 여러 개의 워커 프로세스가 하나의 소켓을 감시(accept())하고 있을 때, 새로운 연결이 들어오면 대기 중이던 모든 프로세스가 동시에 깨어나며, 하지만 연결을 가져가는 것은 단 하나의 프로세스뿐이다. 나머지는 다시 수면 상태로 돌아가는데, 이 과정에서 불필요한 컨텍스트 스위칭과 CPU 리소스 낭비가 발생한다.
서버 재시작 및 Retry 폭주 (Microservices / API): 특정 마이크로서비스나 DB가 일시적인 장애로 다운되었다가 복구되는 순간, 타임아웃을 겪고 대기하던 수많은 클라이언트들이 **동시에 재시도(Retry)**를 요청하면서 갓 복구된 서버를 다시 다운시키는 현상이다.

2. 시스템에 미치는 영향

이 문제가 발생하면 시스템은 리소스를 유용한 작업이 아닌 '경쟁 상태를 처리하는 데' 모두 소모하게 됩니다.

CPU 스파이크(Spike): 수많은 프로세스가 동시에 깨어나며 컨텍스트 스위칭 비용이 급증하여 CPU 사용률이 100%를 찍습니다.
메모리 및 네트워크 병목: 동시에 많은 커넥션이 생성되고 데이터를 요청하면서 메모리가 고갈되거나 네트워크 대역폭이 포화 상태가 됩니다.
연쇄 장애 (Cascading Failure): 타임아웃이 발생하고, 재시도가 반복되면서 하나의 작은 지연이 전체 시스템의 장애로 번지게 됩니다.

3. 해결 및 완화 전략

Thundering Herd 현상을 방지하기 위해서는 '분산'과 '통제'가 핵심입니다.

A. Jitter (지터) 및 Exponential Backoff 도입

클라이언트가 재시도를 할 때 똑같은 주기로 요청하지 않도록, 재시도 간격에 무작위성(Random Jitter)을 부여하는 방식입니다.

적용 예: 서비스 장애 복구 시, 클라이언트 A는 1.1초 후, 클라이언트 B는 2.3초 후, 클라이언트 C는 1.5초 후에 재시도하도록 분산시켜 트래픽 충격을 완화합니다.

B. 분산 락 (Distributed Lock) / Mutex 사용

캐시가 만료되었을 때, 캐시를 갱신할 수 있는 권한(Lock)을 단 하나의 요청(스레드)에게만 부여합니다.

적용 예: 캐시 미스가 발생하면 첫 번째 요청이 락을 획득하여 DB에서 데이터를 조회하고 캐시를 갱신합니다. 락을 얻지 못한 나머지 대기 요청들은 잠시 대기하다가 갱신된 캐시 데이터를 읽어가거나, 시스템 설정에 따라 과거의 데이터(Stale Data)를 반환받습니다.

C. Request Coalescing (요청 병합)

동일한 데이터에 대한 여러 요청이 들어왔을 때, 이를 개별적으로 처리하지 않고 하나의 백엔드 요청으로 병합하는 방법입니다.

적용 예: Nginx의 proxy_cache_lock 지시어나 API Gateway의 쿼리 병합 기능을 사용하면, 100개의 동일한 캐시 미스 요청이 들어와도 백엔드로는 단 1개의 요청만 전달됩니다.

D. Stale-While-Revalidate 패턴

캐시 만료 시간을 두 가지로 관리하는 방법입니다.

캐시가 만료되었더라도 즉시 삭제하지 않고, 클라이언트에게는 일단 약간 오래된(Stale) 데이터를 먼저 빠르게 반환합니다.
그와 동시에 백그라운드에서는 비동기적으로 단일 스레드가 DB를 조회하여 최신 데이터로 캐시를 조용히 갱신(Revalidate)합니다.

E. OS/인프라 레벨의 최적화

현대의 커널 및 웹 서버(예: Nginx)에서는 이 문제를 방지하기 위해 여러 워커가 동시에 깨어나지 않도록 EPOLLEXCLUSIVE 플래그를 사용하거나, SO_REUSEPORT 소켓 옵션을 통해 커널 단위에서 트래픽을 분산시키는 기술을 기본적으로 적용하고 있습니다.

코스모스 네트워크(Cosmos Network)

NellKiM — Mon, 23 Mar 2026 15:49:05 +0900

코스모스 네트워크란 무엇인가

코스모스 네트워크(Cosmos Network)는 흔히 “블록체인의 인터넷(Internet of Blockchains)” 이라고 불립니다. 핵심 목표는 하나의 체인 위에 모든 것을 몰아넣는 것이 아니라, 각 목적에 맞는 독립 블록체인들을 만들고, 그 체인들이 서로 안전하게 통신하게 하는 것입니다. 코스모스 공식 문서도 Cosmos Hub를 CometBFT, Cosmos SDK, IBC로 구성된 상호연결 블록체인 생태계의 일부로 설명한다

그럼 코스모스 네트워크 가 왜 필요한가?

코스모스가 등장한 배경은 크게 세 가지다.

첫째, 상호운용성 부족

전통적인 블록체인 구조에서는 체인 A의 자산이나 메시지를 체인 B로 자연스럽게 옮기기 어렵습니다. 이 문제를 해결하려면 보통 별도의 브리지, 커스터디 서비스, 래핑 토큰이 필요했고, 이 과정에서 보안 리스크와 운영 복잡도가 커졌습니다. IBC는 체인 간 메시지 전달을 표준화해 이 문제를 줄이려는 접근이다.

둘째, 확장성 문제

모든 애플리케이션이 하나의 체인에 몰리면 처리량, 수수료, 실행 환경 제한이 커집니다. 코스모스는 애플리케이션별로 독립 체인을 두고, 필요한 경우에만 서로 통신하게 하므로 병목을 분산시키는 구조를 지향합니다. Cosmos SDK 문서는 SDK가 CometBFT 위에서 보안성 있는 상태 머신을 만들기 위한 프레임워크라고 설명하며, 이는 곧 목적별 체인 설계라는 코스모스 철학과 맞닿아 있다.

셋째, 주권성(Sovereignty)

많은 블록체인 플랫폼은 애플리케이션이 상위 체인의 규칙, 수수료 정책, 실행 환경에 종속됩니다. 반면 코스모스에서는 각 체인이 자체 토큰 경제, 수수료 체계, 거버넌스, 모듈 구성을 선택할 수 있습니다. 이 점이 “앱체인(appchain)” 모델의 핵심이다.

코스모스의 전체 구조

코스모스는 단일 네트워크라기보다, 공통 기술 스택과 통신 규약을 공유하는 상호연결 체인 집합으로 이해하는 게 정확합니다. 그 구조를 설명할 때 자주 나오는 개념이 Hub, Zone, IBC이다.

1. Hub

Hub는 여러 체인을 연결하는 중심 역할의 체인입니다. 대표적인 예가 Cosmos Hub이며, 기본 토큰은 ATOM입니다. Cosmos Hub 공식 문서는 이를 “first of many interconnected blockchains”라고 설명합니다.

중요한 점은 Hub가 인터넷의 중앙 서버 같은 절대적 통제자가 아니라는 것입니다. 코스모스 생태계는 처음에는 허브 중심 비유로 많이 설명됐지만, 실제 IBC는 허브를 거치지 않고 체인 간 직접 연결도 가능합니다. 즉, 허브는 연결의 중심점이 될 수는 있어도 반드시 모든 통신의 단일 관문은 아닙니다. 이 점 때문에 “코스모스 = 하나의 메인체인”으로 이해하면 틀린다.

2. Zone

Zone은 코스모스 생태계에 연결되는 개별 블록체인입니다. 각 Zone은 독립적인 합의, 검증자 세트, 애플리케이션 로직, 토큰 경제를 가질 수 있습니다. 쉽게 말하면, 게임 서비스면 게임용 체인, 디파이면 디파이용 체인, 프라이버시 기능이 필요하면 프라이버시 체인을 따로 만들 수 있다.

           ┌───────────────┐
           │   Cosmos Hub  │
           │    (ATOM)     │
           └──────┬────────┘
                  │
     ┌────────────┼────────────┐
     │            │            │
┌────▼────┐  ┌────▼────┐  ┌────▼────┐
│ Zone A  │  │ Zone B  │  │ Zone C  │
│ (DeFi)  │  │ (Game)  │  │ (NFT)   │
└─────────┘  └─────────┘  └─────────┘

✔️ 설명

Hub: 중간 연결 역할
Zone: 각각 독립 블록체인
각 Zone은 서로 다른 서비스 (DeFi, 게임, NFT 등)

핵심: 각 체인은 독립적이지만 연결됨

3. IBC

IBC는 코스모스의 핵심입니다. IBC는 체인 간에 토큰만 옮기는 기능이 아니라, 검증 가능한 메시지 전달 규약입니다. 공식 문서는 IBC에서 relayer가 오프체인 프로세스로서 양 체인의 상태를 읽고, 반대편 체인에 증명과 함께 메시지를 전달한다고 설명합니다. 또한 각 체인은 상대 체인의 라이트 클라이언트를 사용해 들어온 메시지를 검증한다.

[Chain A]                         [Chain B]

 ┌──────────┐                ┌──────────┐
 │ Light    │◀──────────────▶│ Light    │
 │ Client   │                │ Client   │
 └────┬─────┘                └────┬─────┘
      │                             │
      │   (Proof + Packet)          │
      │                             │
      ▼                             ▼
 ┌──────────┐   Relayer   ┌──────────┐
 │ State    │────────────▶│ State    │
 │ Change   │             │ Update   │
 └──────────┘             └──────────┘

✔️ 설명

각 체인은 상대 체인의 Light Client를 가짐
Relayer가 메시지 전달 (중계자 역할)
하지만 검증은 각 체인이 직접 수행

핵심: 중앙 없이도 신뢰 가능한 통신

코스모스를 구성하는 핵심 기술 스택

1. CometBFT

CometBFT는 코스모스 생태계의 합의 엔진 계열입니다. 원래 Tendermint Core로 널리 알려졌고, 현재 공식 문서에서는 CometBFT로 설명됩니다. CometBFT는 두 가지 핵심 요소를 제공합니다. 하나는 BFT 합의 엔진, 다른 하나는 ABCI(Application Blockchain Interface) 입니다. CometBFT 공식 문서는 이를 “consensus engine + generic application interface”로 설명한다.

이 의미를 쉽게 풀면
CometBFT는 “네트워크 합의와 블록 생성”을 담당하고, 애플리케이션은 “이 트랜잭션이 유효한가, 상태를 어떻게 바꿀 것인가”를 담당합니다. 즉, 블록체인 엔진과 비즈니스 로직이 비교적 깔끔하게 분리됩니다. 이 구조는 개발자가 합의 알고리즘을 직접 구현하지 않고도 앱체인을 만들 수 있게 해 준다.

2. Cosmos SDK

Cosmos SDK는 코스모스 체인을 만들기 위한 프레임워크입니다. 공식 문서는 이를 CometBFT 위에서 안전한 상태 머신을 개발하기 위한 프레임워크라고 설명합니다. 개발자는 계정, 스테이킹, 거버넌스, 슬래싱 같은 기본 모듈을 조립하고, 필요한 비즈니스 모듈을 추가해 체인을 구성할 수 있습니다.

기술블로그에서 강조하면 좋은 포인트는, Cosmos SDK가 단순 라이브러리가 아니라 모듈형 블록체인 운영체제에 가깝다는 점입니다. 예를 들어 웹 개발에서 스프링 부트가 기본 보안, 설정, MVC 틀을 제공하듯, Cosmos SDK는 블록체인에 필요한 기본 기능을 모듈 단위로 제공합니다. 다만 스프링 부트가 애플리케이션 프레임워크라면, Cosmos SDK는 합의 엔진과 결합된 상태 머신 프레임워크라는 점이 더 무겁다.

3. IBC 프로토콜

IBC는 체인 간 상호작용을 정의합니다. 단순 API 호출과 달리, IBC는 상대 체인의 상태 증명을 기반으로 패킷을 전달하고 검증합니다. 각 체인은 상대 체인에 대한 라이트 클라이언트를 유지하고, relayer가 가져온 증명이 유효한지 검증한 뒤에만 상태를 변경합니다.

⚙️ 코스모스 기술 스택 구조

┌──────────────────────────────┐
│        Application           │
│   (DeFi / Game / NFT 등)     │
├──────────────────────────────┤
│        Cosmos SDK            │
│   (계정, 스테이킹, 거버넌스)   │
├──────────────────────────────┤
│        CometBFT              │
│   (합의 + 네트워크 엔진)      │
└──────────────────────────────┘

✔️ 설명

CometBFT → 합의 엔진
SDK → 비즈니스 로직
Application → 실제 서비스

IBC는 실제로 어떻게 동작하는가

IBC를 이해하려면 네 가지 요소를 기억하면 좋다.
클라이언트(client), 연결(connection), 채널(channel), 패킷(packet) 입니다. 공식 문서도 IBC 스펙에서 채널과 패킷의 의미를 별도로 설명하겠다.

1. 라이트 클라이언트

체인 A는 체인 B 전체를 다시 실행하지 않는다, 대신 체인 B의 헤더와 증명을 검증할 수 있는 라이트 클라이언트를 체인 내부에 유지합니다. 코스모스 문서는 Tendermint/CometBFT 라이트 클라이언트가 상대 체인의 합의를 추적한다고 설명한다.

즉, 체인 A는 “체인 B가 정말 이 상태를 가졌는지”를 직접 검증할 수 있습니다. 이 구조가 중앙 브리지 운영자 없이도 신뢰를 줄이는 핵심이다.

2. Connection

두 체인은 먼저 서로의 라이트 클라이언트를 기반으로 연결 관계를 맺습니다. 이것은 TCP 연결과 비슷한 개념적 단계라고 볼 수 있지만, 실제로는 온체인 상태와 증명에 기반한 신뢰 연결이다.

3. Channel

Connection 위에는 애플리케이션 목적에 맞는 Channel이 열립니다. 예를 들어 토큰 전송용 채널, 인터체인 계정용 채널처럼 목적별로 채널을 둘 수 있습니다. 채널은 ordered/unordered 특성을 가질 수 있고, 전달 순서 보장 여부도 여기에 달려 있습니다. 공식 스펙은 IBC가 ordered channel에서 순서 보장과 exactly-once delivery를 지원하도록 설계되었다고 설명합니다.

4. Packet

실제 메시지는 Packet 형태로 전송된다. 체인 A가 체인 B로 어떤 메시지를 보내면, 그 사실이 체인 A 상태에 기록됩니다. 이후 relayer가 그 이벤트와 증명을 읽어 체인 B에 제출하고, 체인 B는 자체 라이트 클라이언트로 이를 검증한 뒤 패킷을 처리합니다. IBC 공식 사이트와 문서는 relayer가 체인 상태를 스캔하고 패킷을 반대 체인으로 운반한다고 설명합니다.

5. Relayer의 역할

Relayer는 IBC의 매우 중요한 구성요소이다. 다만 Relayer는 “신뢰해야 하는 중앙 운영자”는 아니고, Relayer가 패킷을 전달하더라도 최종 검증은 체인이 자체 라이트 클라이언트로 수행하기 때문에, 따라서 relayer는 데이터 운반자에 가깝고, 보안의 최종 책임은 체인의 검증 로직에 있습니다. Cosmos 문서도 relayer를 “physical connection layer”로 설명한다.

이 구조를 IT 시스템에 비유하면, IBC는 단순 REST 호출보다 메시지 브로커 + 증명 검증 + 상태 동기화 프로토콜에 더 가깝다.

IBC Packet 흐름 (실제 동작)

1. Chain A에서 토큰 전송 요청

   User → Chain A
         ↓
   Packet 생성

2. Relayer가 감지

   Chain A 상태 읽음
         ↓
   Proof 포함해서 전달

3. Chain B에서 검증

   Light Client로 검증
         ↓
   성공 시 상태 반영

4. Ack 반환

   Chain B → Chain A

Cosmos Hub와 ATOM의 역할

Cosmos Hub는 코스모스 생태계의 대표적인 허브 체인이고, ATOM은 그 기본 토큰이며, 공식 문서는 ATOM이 Cosmos Hub의 보안과 거버넌스에 쓰인다고 설명합니다.

ATOM의 역할은 대체로 세 가지로 요약할 수 있으며,

첫째, 스테이킹입니다. 검증자와 위임자는 ATOM을 스테이킹해 네트워크 보안에 참여
둘째, 거버넌스입니다. 체인 업그레이드, 파라미터 변경, 정책 의사결정에 투표할 수 있다.
셋째, 인터체인 서비스의 기반 자산입니다. 최근 Cosmos Hub는 단순 연결 허브를 넘어 Interchain Security 같은 서비스도 제공한다.

Interchain Security는 왜 중요한가

코스모스 생태계의 약점 중 하나는 각 체인이 독립적이라는 점, 독립성은 장점이지만, 반대로 말하면 작은 체인은 충분한 검증자와 보안을 확보하기 어렵다는 뜻이기도 합니다.

이를 보완하기 위한 개념 중 하나가 Interchain Security입니다. Cosmos Hub 공식 문서는 이를 Hub가 제공하는 주요 인터체인 서비스 중 하나로 소개하며, 소비자 체인이 Hub의 보안 자원을 활용할 수 있게 한다고 설명한다.

초기 앱체인은 기능은 훌륭해도 자체 토큰 시가총액과 검증자 생태계가 약하면 공격 비용이 낮아질 수 있으며, Interchain Security는 이를 줄이기 위해 기존 강한 허브 체인의 보안을 공유하는 모델입니다.

코스모스의 장점

1. 높은 주권성

각 체인이 독립적으로 정책을 설계할 수 있습니다. 실행 환경, 수수료 구조, 토큰 경제, 거버넌스, 기능 모듈 구성이 자유롭습니다. 이는 “남의 메인넷 위에서 돌아가는 dApp”과 구별되는 앱체인 모델의 가장 큰 장점

2. 확장성

애플리케이션을 별도 체인으로 분리하면 처리량 병목을 완화할 수 있습니다. 모든 앱이 하나의 글로벌 상태를 두고 경쟁하는 구조보다, 목적별 체인으로 분산하는 쪽이 성능과 정책 측면에서 유리하다.

3. 상호운용성

IBC 덕분에 체인 간 토큰 이동, 메시지 전달, 인터체인 계정 같은 기능이 가능합니다. 이는 단순 브리지보다 더 일반화된 메시지 전송 모델이다.

4. 개발 생산성

Cosmos SDK와 CometBFT를 이용하면 합의 엔진부터 처음부터 구현하지 않고도 블록체인을 구축할 수 있습니다. 즉, 개발자는 비즈니스 로직과 체인 설계에 더 집중할 수 있습니다.

코스모스의 한계와 비판 포인트

1. 보안의 분산

코스모스는 체인별 주권이 강한 만큼, 보안도 체인별로 다릅니다. 이는 이더리움처럼 강력한 단일 보안 풀을 공유하는 모델과 대비됩니다. Interchain Security가 이를 보완하지만, 모든 체인이 동일한 보안 수준을 자동으로 갖는 것은 아닙니다.

2. 운영 복잡도

독립 체인을 운영한다는 것은 인프라, 검증자, 업그레이드, 거버넌스, 경제 설계를 모두 자체적으로 관리해야 함을 뜻합니다. “체인을 만들 자유”는 동시에 “체인을 운영할 책임”도 함께 줍니다. 이건 장점이면서 부담입니다.

3. IBC도 운영 주체가 필요함

IBC 자체는 무신뢰에 가깝게 설계되지만, relayer 운영, 채널 관리, 앱 레벨 호환성은 여전히 실무 영역입니다. 즉 프로토콜이 있다고 해서 자동으로 모든 체인 간 UX가 완벽해지는 것은 아닙니다.

PL/SQL 이란?

NellKiM — Fri, 20 Mar 2026 11:45:07 +0900

PL/SQL은 오라클 데이터베이스에서 쓰는 절차형 SQL 언어다.
이름도 그대로 보면 된다.

SQL: 데이터 조회/입력/수정/삭제
PL/SQL: SQL에다가 변수, 조건문, 반복문, 예외처리, 함수, 프로시저를 붙인 것

즉:

“오라클 DB 안에서 동작하는 프로그래밍 언어”

1. 왜 PL/SQL을 쓰는가

일반 SQL은 보통 한 번에 한 문장씩 처리한다.

예를 들어:

SELECT * FROM EMP;
UPDATE EMP SET SAL = SAL * 1.1 WHERE DEPTNO = 10;

이건 단순 조회/수정은 잘하지만, 아래 같은 로직은 불편하다.

조건에 따라 다르게 처리
여러 SQL을 묶어서 한 번에 실행
오류 발생 시 예외 처리
반복 처리
값을 변수에 담아 계산
업무 로직 캡슐화

그래서 PL/SQL을 쓴다.

예를 들면:

급여가 특정 금액 이하인 직원만 인상
부서별 보너스 계산
입력값 검증 후 데이터 저장
배치성 데이터 처리
트랜잭션 단위 업무 처리

2. PL/SQL의 특징

1) 오라클 전용

PL/SQL은 기본적으로 Oracle Database용이다.
다른 DB에도 비슷한 개념은 있지만 문법이 다르다.

Oracle → PL/SQL
SQL Server → T-SQL
PostgreSQL → PL/pgSQL

2) SQL + 절차형 언어

PL/SQL 안에서는 SQL을 그대로 쓸 수 있다

BEGIN
    UPDATE EMP
       SET SAL = SAL + 100
     WHERE EMPNO = 7369;
END;
/

SQL만 있는 게 아니라:

IF
LOOP
WHILE
FOR
EXCEPTION

이런 것도 사용 가능

3) 블록 구조

PL/SQL은 기본적으로 블록(Block) 구조다.

기본 형태:

DECLARE
   -- 변수 선언부
BEGIN
   -- 실행부
EXCEPTION
   -- 예외 처리부
END;
/

DECLARE: 변수 선언
BEGIN ~ END: 실제 실행
EXCEPTION: 오류 처리

3. PL/SQL 기본 구조

예제 1: 가장 단순한 블록

BEGIN
DBMS_OUTPUT.PUT_LINE('HELLO PL/SQL');
END;
/

설명:

DBMS_OUTPUT.PUT_LINE = 콘솔 출력 비슷한 개념
/ = SQL*Plus, SQL Developer 같은 도구에서 블록 실행 신호

예제 2: 변수 선언

DECLARE
V_NAME VARCHAR2(50);
BEGIN
V_NAME := 'KIM';
DBMS_OUTPUT.PUT_LINE(V_NAME);
END;
/

여기서:

VARCHAR2(50) = 문자열 변수
:= = 대입 연산자

주의:
PL/SQL에서는 변수 대입을 =가 아니라 :=로 한다.

4. 데이터 타입

PL/SQL은 오라클 타입을 주로 쓴다.

자주 쓰는 타입

NUMBER : 숫자
VARCHAR2(n) : 문자열
DATE : 날짜
CHAR(n) : 고정 길이 문자열
BOOLEAN : 참/거짓 (PL/SQL 내부용)
CLOB : 대용량 문자
BLOB : 바이너리

예:

DECLARE
V_NUM NUMBER := 100;
V_NAME VARCHAR2(20) := 'LEE';
V_DATE DATE := SYSDATE;
BEGIN
DBMS_OUTPUT.PUT_LINE(V_NUM);
DBMS_OUTPUT.PUT_LINE(V_NAME);
DBMS_OUTPUT.PUT_LINE(V_DATE);
END;
/

5. SELECT INTO

PL/SQL에서 조회 결과를 변수에 담을 때 자주 쓴다.

DECLARE
V_ENAME EMP.ENAME%TYPE;
V_SAL EMP.SAL%TYPE;
BEGIN
SELECT ENAME, SAL
INTO V_ENAME, V_SAL
FROM EMP
WHERE EMPNO = 7369;

DBMS_OUTPUT.PUT_LINE('이름: ' || V_ENAME);
DBMS_OUTPUT.PUT_LINE('급여: ' || V_SAL);
END;
/

중요한 점

SELECT INTO는 반드시 1건만 조회되어야 한다.

문제가 되는 경우:

결과 0건 → NO_DATA_FOUND
결과 2건 이상 → TOO_MANY_ROWS

그래서 실무에서는 예외처리를 같이 넣는다.

6. %TYPE, %ROWTYPE

이건 실무에서 매우 중요하다.

1) %TYPE

테이블 컬럼 타입을 그대로 따라간다.

DECLARE
V_ENAME EMP.ENAME%TYPE;
BEGIN
...
END;
/

장점:

EMP.ENAME 타입이 바뀌어도 변수 타입이 자동 반영됨
하드코딩 줄어듦

2) %ROWTYPE

한 행 전체 구조를 그대로 가져온다.

DECLARE
V_EMP EMP%ROWTYPE;
BEGIN
SELECT *
INTO V_EMP
FROM EMP
WHERE EMPNO = 7369;

DBMS_OUTPUT.PUT_LINE(V_EMP.ENAME);
DBMS_OUTPUT.PUT_LINE(V_EMP.SAL);
END;
/

장점:

컬럼 하나씩 선언할 필요 없음

단점:

SELECT * INTO는 컬럼 변경 영향 받을 수 있어서 조심해야 함

7. 조건문

IF 문

DECLARE
V_SAL NUMBER := 3000;
BEGIN
IF V_SAL >= 5000 THEN
DBMS_OUTPUT.PUT_LINE('고액 연봉');
ELSIF V_SAL >= 3000 THEN
DBMS_OUTPUT.PUT_LINE('중간 연봉');
ELSE
DBMS_OUTPUT.PUT_LINE('낮은 연봉');
END IF;
END;
/

8. 반복문

1) BASIC LOOP

DECLARE
V_CNT NUMBER := 1;
BEGIN
LOOP
DBMS_OUTPUT.PUT_LINE(V_CNT);
V_CNT := V_CNT + 1;

EXIT WHEN V_CNT > 5;
END LOOP;
END;
/

2) WHILE LOOP

DECLARE
V_CNT NUMBER := 1;
BEGIN
WHILE V_CNT <= 5 LOOP
DBMS_OUTPUT.PUT_LINE(V_CNT);
V_CNT := V_CNT + 1;
END LOOP;
END;
/

3) FOR LOOP

BEGIN
FOR I IN 1..5 LOOP
DBMS_OUTPUT.PUT_LINE(I);
END LOOP;
END;
/

실무에서는 FOR LOOP가 간단해서 많이 쓰인다.

9. DML 사용

PL/SQL 안에서는 INSERT, UPDATE, DELETE를 그대로 쓸 수 있다.

INSERT

BEGIN
INSERT INTO EMP_TEMP(EMPNO, ENAME, SAL)
VALUES (9999, 'KIM', 3000);
END;
/

UPDATE

BEGIN
UPDATE EMP
SET SAL = SAL + 500
WHERE DEPTNO = 10;
END;
/

DELETE

BEGIN
DELETE FROM EMP_TEMP
WHERE EMPNO = 9999;
END;
/

10. 트랜잭션 처리

PL/SQL에서도 트랜잭션 개념은 동일하다.

COMMIT : 확정
ROLLBACK : 취소

BEGIN
UPDATE ACCOUNT
SET BALANCE = BALANCE - 1000
WHERE ACC_NO = 'A001';

UPDATE ACCOUNT
SET BALANCE = BALANCE + 1000
WHERE ACC_NO = 'A002';

COMMIT;
END;
/

실무에서는 이체, 정산 같은 업무에서 중요하다.

다만 프로시저 내부에서 무조건 COMMIT을 수행하면
호출한 쪽에서 트랜잭션 제어가 어려워질 수 있어서 설계에 따라 조심한다.

11. 예외 처리

PL/SQL의 강점 중 하나다.

DECLARE
V_ENAME EMP.ENAME%TYPE;
BEGIN
SELECT ENAME
INTO V_ENAME
FROM EMP
WHERE EMPNO = 9999;

DBMS_OUTPUT.PUT_LINE(V_ENAME);

EXCEPTION
WHEN NO_DATA_FOUND THEN
DBMS_OUTPUT.PUT_LINE('데이터 없음');
WHEN TOO_MANY_ROWS THEN
DBMS_OUTPUT.PUT_LINE('데이터가 여러 건임');
WHEN OTHERS THEN
DBMS_OUTPUT.PUT_LINE('기타 오류 발생');
END;
/

자주 쓰는 예외

NO_DATA_FOUND
TOO_MANY_ROWS
ZERO_DIVIDE
DUP_VAL_ON_INDEX
VALUE_ERROR
OTHERS

WHEN OTHERS는 마지막에 두는 게 일반적이다.

12. CURSOR

조회 결과가 여러 건일 때 쓴다.

명시적 커서 예시

DECLARE
CURSOR C_EMP IS
SELECT EMPNO, ENAME, SAL
FROM EMP
WHERE DEPTNO = 10;

V_EMPNO EMP.EMPNO%TYPE;
V_ENAME EMP.ENAME%TYPE;
V_SAL EMP.SAL%TYPE;
BEGIN
OPEN C_EMP;

LOOP
FETCH C_EMP INTO V_EMPNO, V_ENAME, V_SAL;
EXIT WHEN C_EMP%NOTFOUND;

DBMS_OUTPUT.PUT_LINE(V_EMPNO || ' / ' || V_ENAME || ' / ' || V_SAL);
END LOOP;

CLOSE C_EMP;
END;
/

커서 FOR LOOP

더 많이 쓰임

BEGIN
FOR REC IN (
SELECT EMPNO, ENAME, SAL
FROM EMP
WHERE DEPTNO = 10
) LOOP
DBMS_OUTPUT.PUT_LINE(REC.EMPNO || ' / ' || REC.ENAME || ' / ' || REC.SAL);
END LOOP;
END;
/

실무에서 여러 건 읽어 처리할 때 많이 씀.

13. PROCEDURE

프로시저는 반환값 없는 실행 단위다.

예를 들어 “사원 급여 인상 처리” 같은 업무를 묶어놓는다.

CREATE OR REPLACE PROCEDURE UPD_SALARY (
P_EMPNO IN EMP.EMPNO%TYPE,
P_INC IN NUMBER
)
IS
BEGIN
UPDATE EMP
SET SAL = SAL + P_INC
WHERE EMPNO = P_EMPNO;
END;
/

실행:


BEGIN
UPD_SALARY(7369, 500);
END;
/

14. FUNCTION

함수는 반환값이 있는 프로그램 단위다.

CREATE OR REPLACE FUNCTION GET_ANNUAL_SAL (
P_EMPNO IN EMP.EMPNO%TYPE
)
RETURN NUMBER
IS
V_SAL EMP.SAL%TYPE;
BEGIN
SELECT SAL
INTO V_SAL
FROM EMP
WHERE EMPNO = P_EMPNO;

RETURN V_SAL * 12;
END;
/

사용:


SELECT GET_ANNUAL_SAL(7369)
FROM DUAL;

프로시저와 함수 차이

프로시저

반환값 없어도 됨
업무 처리용
OUT 파라미터로 값 전달 가능

함수

반드시 RETURN 필요
계산 결과 반환
SQL 안에서 호출 가능(제약 있음)

15. IN / OUT / IN OUT 파라미터

IN

입력용

OUT

출력용

IN OUT

입출력용

CREATE OR REPLACE PROCEDURE GET_EMP_INFO (
P_EMPNO IN EMP.EMPNO%TYPE,
P_ENAME OUT EMP.ENAME%TYPE,
P_SAL OUT EMP.SAL%TYPE
)
IS
BEGIN
SELECT ENAME, SAL
INTO P_ENAME, P_SAL
FROM EMP
WHERE EMPNO = P_EMPNO;
END;
/

16. PACKAGE

패키지는 관련된 프로시저, 함수, 변수, 커서 등을 묶는 단위다.

쉽게 말하면:

PL/SQL 모듈 묶음

장점

구조화
유지보수 편함
공통 로직 묶기 좋음
권한 관리 편함

패키지는 보통:

PACKAGE SPEC: 외부 공개 선언부
PACKAGE BODY: 실제 구현부

로 나뉜다.

예시

SPEC

CREATE OR REPLACE PACKAGE PKG_EMP IS
PROCEDURE UPD_SALARY(P_EMPNO IN NUMBER, P_INC IN NUMBER);
FUNCTION GET_SAL(P_EMPNO IN NUMBER) RETURN NUMBER;
END PKG_EMP;
/

BODY

CREATE OR REPLACE PACKAGE BODY PKG_EMP IS

PROCEDURE UPD_SALARY(P_EMPNO IN NUMBER, P_INC IN NUMBER) IS
BEGIN
UPDATE EMP
SET SAL = SAL + P_INC
WHERE EMPNO = P_EMPNO;
END;

FUNCTION GET_SAL(P_EMPNO IN NUMBER) RETURN NUMBER IS
V_SAL NUMBER;
BEGIN
SELECT SAL INTO V_SAL
FROM EMP
WHERE EMPNO = P_EMPNO;
RETURN V_SAL;
END;

END PKG_EMP;
/

호출:


BEGIN
PKG_EMP.UPD_SALARY(7369, 300);
END;
/

17. TRIGGER

트리거는 특정 이벤트가 발생했을 때 자동 실행되는 PL/SQL이다.

예:

INSERT 시 자동 로그 저장
UPDATE 시 변경 이력 기록
DELETE 방지

CREATE OR REPLACE TRIGGER TRG_EMP_LOG
AFTER INSERT ON EMP
FOR EACH ROW
BEGIN
INSERT INTO EMP_LOG(LOG_MSG, LOG_DATE)
VALUES('사원 등록: ' || :NEW.EMPNO, SYSDATE);
END;
/

주의

트리거는 편하지만 남발하면 운영이 힘들다.

이유:

어디서 자동 실행되는지 추적 어려움
성능 영향
디버깅 어려움

18. 동적 SQL

실행 시점에 SQL 문장을 문자열로 만들어 실행하는 방식이다.

BEGIN
EXECUTE IMMEDIATE 'UPDATE EMP SET SAL = SAL + 100 WHERE EMPNO = 7369';
END;
/

사용하는 경우:

테이블명/컬럼명이 동적으로 바뀌는 경우
동적 조건 처리

주의:

SQL Injection
가독성 저하
유지보수 어려움

19. PL/SQL에서 자주 보는 시스템 패키지

DBMS_OUTPUT

출력용

DBMS_OUTPUT.PUT_LINE('TEST');

DBMS_SCHEDULER

배치/스케줄 작업

UTL_FILE

파일 읽기/쓰기

DBMS_SQL

동적 SQL 처리

DBMS_JOB

구버전 잡 관리

20. 실무에서 많이 하는 일

PL/SQL은 보통 이런 데 쓴다.

배치 프로그램
인터페이스 데이터 적재
정산/집계 로직
이력 데이터 관리
검증/후처리
프로시저 기반 업무 API
대량 데이터 처리

특히 금융/공공/레거시 SI에서 많이 본다.

예를 들면:

거래 마감 배치
수수료 계산
일별 집계
전문 수신 후 테이블 적재
에러 데이터 재처리

21. 장점

1) DB 내부 실행

애플리케이션 서버를 거치지 않아도 됨

2) 성능상 유리한 경우 있음

SQL과 가까워서 대량 처리에 강한 케이스가 있음

3) 트랜잭션 제어 용이

업무 로직을 한 단위로 묶기 쉬움

4) 보안/권한 관리

테이블 직접 권한 대신 프로시저 실행 권한만 줄 수도 있음

22. 단점

1) 오라클 종속성

다른 DB로 이관 어려움

2) 복잡한 비즈니스 로직은 가독성 떨어질 수 있음

너무 많은 로직이 DB에 들어가면 관리가 어려움

3) 디버깅 불편

일반 애플리케이션 언어보다 추적이 번거로운 편

4) 잘못 짜면 성능 저하

특히 한 건씩 처리하는 로직이 문제

23. 성능에서 매우 중요한 개념

이건 실무에서 진짜 중요하다.

Row-by-Row 처리 지양

PL/SQL 루프 돌면서 한 건씩 UPDATE 하는 건 느릴 수 있다.

예를 들어 이런 방식:

FOR REC IN (SELECT EMPNO FROM EMP) LOOP
UPDATE EMP
SET SAL = SAL + 100
WHERE EMPNO = REC.EMPNO;
END LOOP;

이건 비효율적일 수 있다.

차라리 SQL 한 번으로:


UPDATE EMP
SET SAL = SAL + 100;

이게 훨씬 낫다.

즉:

할 수 있으면 SQL로 한 번에 처리
꼭 필요할 때만 PL/SQL 제어문 사용

24. SQL과 PL/SQL 차이

SQL

선언형 언어
“무엇을 원하는지” 기술
조회/변경 중심

PL/SQL

절차형 언어
“어떻게 처리할지” 기술
로직/제어/예외처리 가능

예:

SQL: “10번 부서 급여 올려”
PL/SQL: “조건 확인하고, 로그 남기고, 예외 처리하고, 올려”

25. 자주 나오는 문법 정리

문자열 연결

V_MSG := '이름: ' || V_NAME;

비교

IF V_NUM = 10 THEN

NULL 체크

IF V_NAME IS NULL THEN

주의: = NULL 아님

주석

-- 한 줄 주석

/*
여러 줄 주석
*/

26. 실무 예제 하나

사번을 받아 직원 급여를 10% 인상하고, 없으면 에러 메시지 출력하는 예제다.

CREATE OR REPLACE PROCEDURE PRC_INC_SAL (
P_EMPNO IN EMP.EMPNO%TYPE
)
IS
V_CNT NUMBER;
BEGIN
SELECT COUNT(*)
INTO V_CNT
FROM EMP
WHERE EMPNO = P_EMPNO;

IF V_CNT = 0 THEN
DBMS_OUTPUT.PUT_LINE('해당 사원이 없습니다.');
ELSE
UPDATE EMP
SET SAL = SAL * 1.1
WHERE EMPNO = P_EMPNO;

DBMS_OUTPUT.PUT_LINE('급여 인상 완료');
END IF;

EXCEPTION
WHEN OTHERS THEN
DBMS_OUTPUT.PUT_LINE('오류: ' || SQLERRM);
ROLLBACK;
END;
/

실행:


BEGIN
PRC_INC_SAL(7369);
END;
/

Ant 빌드와 MAVEN 빌드 차이

NellKiM — Wed, 25 Feb 2026 17:49:42 +0900

1) 빌드 철학: 선언형 vs 절차형

Ant = 절차형(Imperative)

개발자가 **빌드 과정(절차)**을 “순서대로” 직접 작성합니다.
즉, “컴파일하려면 폴더 만들고 → 소스 모으고 → javac 실행하고 → jar 만들고 → 복사하고 …” 를 스크립트처럼 작성.

장점

원하는 대로 커스터마이징이 매우 자유롭다.
작은 작업 자동화에 빠르게 붙일 수 있다.

단점

프로젝트마다 build.xml 스타일이 제각각이라 표준화가 약함
유지보수 시 “이 빌드가 뭘 하는지” 이해 비용이 큼

Maven = 선언형(Declarative)

개발자는 “무엇을 만들지(결과물)” + “의존성(라이브러리)” + “플러그인 설정”을 선언하면,
Maven이 정해진 Lifecycle(생명주기) 에 따라 자동으로 수행한다.

장점

표준 Lifecycle + 표준 디렉토리 구조로 협업/유지보수에 강함
의존성 관리가 내장되어 있어 빌드 재현성이 좋음(누가 빌드해도 동일)

단점

Maven 방식에 맞추는 학습이 필요
극단적으로 커스텀한 빌드 파이프라인은 플러그인/설정이 복잡해질 수 있음

2) 의존성(Dependency) 관리 차이: “Maven이 실무 표준인 핵심 이유”

Ant

기본적으로 의존성 관리 기능이 없습니다.
보통 /lib 폴더에 jar를 수동으로 넣고 classpath에 붙여야한다.
버전 충돌/전이 의존성(라이브러리가 또 다른 라이브러리 요구) 관리가 어려움.

예)

A.jar가 B 1.0 필요
C.jar가 B 2.0 필요
→ Ant는 사람이 판단해서 jar 정리해야 함

(참고: Ivy 같은 외부 도구로 보완은 가능하지만, Ant 자체의 기본 철학은 “직접 관리”에 가깝습니다.)

Maven

의존성 관리가 핵심 기능입니다.
pom.xml에 선언하면 Maven Central/사내 Nexus(Artifactory)에서 자동 다운로드
Transitive Dependency(전이 의존성) 를 자동으로 끌고 옴
의존성 트리/충돌 해결 규칙이 있음

→ “내 PC에는 되는데 서버에서는 안 된다” 같은 상황이 줄어듦

3) 빌드 라이프사이클(Lifecycle) 유무

Ant

lifecycle이 없습니다.
target을 만들고, target 간 의존관계를 수동으로 연결한다.

즉, 각 프로젝트마다:

compile target
test target
package target
이런 이름/순서가 다 다를 수 있음

Maven

정해진 lifecycle이 존재한다.

대표적으로:

clean : 이전 산출물 삭제
compile : 컴파일
test : 테스트 실행
package : jar/war 패키징
install : 로컬 저장소에 설치
deploy : 원격 저장소(사내 repo 등)에 배포

mvn install 한 줄이면 “표준 순서”로 전체 수행된다.

4) 프로젝트 구조 표준화

Ant

소스 구조가 자유로움
src가 어디인지, 리소스가 어디인지, 테스트가 어디인지 전부 build.xml에 직접 정의

→ 팀/프로젝트마다 구조가 달라져 새로 투입된 사람이 적응하기 힘들다.

Maven

표준 디렉토리 구조가 사실상 “규격”이다.

대표 구조:

src/main/java
src/main/resources
src/test/java
src/test/resources

→ “처음 보는 프로젝트라도 어디에 뭐가 있는지” 바로 예측 가능

5) 확장 방식: Task vs Plugin

Ant

task 중심: javac, copy, jar 같은 태스크를 조합
고급 기능은 custom task를 추가해야 하고, 경우에 따라 Java로 task를 직접 개발

Maven

plugin 중심: 빌드의 대부분 기능이 plugin으로 제공됨
예: 컴파일, 테스트, 패키징, shading(uber-jar), 코드 품질(SpotBugs/Checkstyle), 커버리지(JaCoCo), 배포 등

→ “표준 plugin + 설정”으로 해결되는 범위가 넓음

6) 멀티모듈/대규모 프로젝트 적합성

Ant

멀티모듈 구성은 가능하지만 보통 스크립트가 복잡해지고
의존성/버전 관리가 사람 손을 많이 거치게된다.

Maven

멀티모듈에 매우 강함 (parent pom, dependencyManagement 등)
버전 통합 관리, 공통 플러그인 관리가 쉬움

대기업 SI/플랫폼에서 Maven을 많이 쓰는 이유 중 하나

7) CI/CD 관점

Ant

환경 의존적이 되기 쉬움(경로, lib, 특정 서버 설정 등)
빌드 재현성(reproducible build)을 맞추려면 규율이 필요

Maven

의존성/빌드 단계가 표준화되어
CI 파이프라인이 단순해짐 (mvn clean verify 같은 방식)
사내 저장소(Nexus/Artifactory)와 연동해 운영하기 쉬움

8) 산출물/버전 관리 방식

Ant

버전 관리 체계가 빌드 스크립트에서 제각각
jar/war 이름 규칙도 프로젝트마다 다름

Maven

groupId:artifactId:version 좌표로 아티팩트를 관리
배포/저장소 관리까지 빌드 프로세스에 자연스럽게 통합

9) Ant 와 Maven 비교표

항목	Ant	Maven
철학	절차형(How)	선언형(What)
표준 구조	없음(자유)	있음(강제에 가까움)
의존성 관리	기본 없음(수동)	내장(자동, 전이 의존성)
라이프사이클	없음(직접 구성)	있음(표준 단계)
확장	task/custom task	plugin 생태계
대규모/멀티모듈	관리 난이도 상승	강력 지원
재현성/CI 친화성	규율 필요	기본적으로 유리

JKS(Java KeyStore) 파일 과 JKS 의 키체인

NellKiM — Mon, 9 Feb 2026 09:09:48 +0900

1️⃣ JKS 파일이 뭐냐

JKS = Java KeyStore

자바 기반 시스템에서 인증서와 개인키를 저장하는 보관소
파일 하나에 여러 개의 인증서/키를 담을 수 있음
주로 SSL/TLS(HTTPS), 서버 인증, 클라이언트 인증에 사용

server.jks
truststore.jks
keystore.jks

2️⃣ JKS 안에 들어가는 것들 (핵심)

JKS에는 엔트리(entry) 가 있고, 타입이 다릅니다.

1) PrivateKeyEntry (가장 중요)

개인키 + 서버 인증서 + 인증서 체인
HTTPS 서버 구동 시 필요

[개인키]
[서버 인증서]
[중간 CA]
[루트 CA]

keystore 용도

2) TrustedCertificateEntry

CA 인증서(신뢰용) 만 들어 있음
상대 서버를 믿기 위해 사용

truststore 용도

3️⃣ Keystore vs Truststore (무조건 구분해야 함)

이거 헷갈리면 SSL 문제 100% 터집니다.

구분	KeystoreTruststore	Truststore
역할	내가 누구인지 증명	상대를 믿을지 결정
포함	개인키 + 인증서	CA 인증서
사용 예	HTTPS 서버	외부 API 호출
파일명	server.jks	trust.jks

한 파일에 둘 다 넣을 수도 있지만
운영에선 보통 분리

4️⃣ 인증서 흐름 (HTTPS 기준)

서버 HTTPS 띄울 때

서버가 자기 인증서 + 개인키 보유 (keystore)
클라이언트 접속
서버 인증서 전달
클라이언트는 truststore 에서 CA 검증

API Gateway / APIM

인바운드 HTTPS → Gateway keystore
아웃바운드 HTTPS → Gateway truststore

5️⃣ JKS 관련 필수 명령어 (keytool)

JKS 내용 보기

keytool -list -v -keystore server.jks

특정 alias 보기

keytool -list -keystore server.jks -alias apim_ssl

CA 인증서 추가 (truststore)

keytool -import -alias rootca \
 -file rootca.crt \
 -keystore trust.jks

6️⃣ JKS ↔ PEM ↔ PKCS12 관계 (실무에서 중요)

요즘은 JKS보다 PKCS12(.p12/.pfx) 가 표준입니다

포맷	설명
JKS	자바 전용
PKCS12	범용(자바/웹서버 공용)
PEM	텍스트(cert/key 분리)

P12 → JKS

keytool -importkeystore \
 -srckeystore cert.p12 -srcstoretype PKCS12 \
 -destkeystore server.jks -deststoretype JKS

1️⃣ JKS에서 “키체인”이 실제로 의미하는 것

보통 누가

“이 JKS에 키체인 들어있어?”

라고 하면 99% 이걸 묻는 겁니다

PrivateKeyEntry 안에 인증서 체인이 제대로 들어있냐

2️⃣ 인증서 체인(Certificate Chain)이란?

서버 인증서는 혼자 신뢰되지 않습니다.
항상 신뢰 사슬(chain) 로 검증됩니다.

[서버 인증서]
   ↓
[중간 CA 인증서]
   ↓
[루트 CA 인증서]

이 묶음 전체를 흔히 키체인이라고 부릅니다.

정확한 용어

개인키 (Private Key)
서버 인증서 (End-Entity Cert)
중간 CA (Intermediate CA)
루트 CA (Root CA)

3️⃣ JKS 구조에서 어디에 들어가 있나

PrivateKeyEntry 구조

Alias: apim_ssl
Entry type: PrivateKeyEntry
Certificate chain length: 3

이게 바로 키체인 있음 상태입니다.

체인 길이 의미

1 → 서버 인증서만 있음 ❌
2 → 서버 + 중간 CA
3 이상 → 서버 + 중간 CA + 루트 CA ⭕ (권장)

4️⃣ 키체인 없으면 무슨 일이 생기냐

아주 흔한 장애 패턴입니다.

❌ 키체인 누락 시 증상

브라우저: NET::ERR_CERT_AUTHORITY_INVALID
Java:

PKIX path building failed
unable to find valid certification path

AWS-EC2(Elastic Compute Cloud)

NellKiM — Mon, 9 Feb 2026 09:09:22 +0900

EC2란? (Amazon EC2: Elastic Compute Cloud)

EC2는 AWS에서 제공하는 가상 서버(=클라우드 VM) 서비스야.
필요할 때 몇 분 안에 서버를 만들고, 필요 없으면 끌 수 있고, 트래픽이 늘면 서버 수를 늘려 **수평 확장(scale-out)**도 가능해.

1) EC2가 해결하는 문제 (왜 쓰나)

온프레미스에서 서버 한 대 운영하려면 보통 이런 일이 필요해:

물리 서버 구매/납품/랙 장착
OS 설치, 네트워크 구성, 방화벽 설정
장애 시 부품 교체, 백업/복구, 용량 증설
트래픽 증가 시 서버 추가 구매(시간/비용 큼)

EC2는 이걸 “클릭 몇 번(또는 IaC)”으로 서버를 생성/확장/폐기할 수 있게 만들어서,

빠른 배포
유연한 확장
비용 효율(사용한 만큼)
을 가능하게 해.

2) EC2의 핵심 개념 (구성 요소)

(1) AMI (Amazon Machine Image)

EC2 인스턴스를 만들 때 사용하는 서버 이미지
OS(예: Amazon Linux, Ubuntu, Windows) + 초기 설정 템플릿
기업에서는 “표준 AMI”를 만들어서 보안 설정/에이전트 등을 포함시키기도 함

(2) 인스턴스 타입(Instance Type)

CPU/메모리/네트워크 성능 스펙
예) t3/t4g(범용), c계열(CPU), r계열(메모리), m계열(밸런스)

블로그 포인트: “워크로드에 따라 타입 선택 기준”을 적으면 실무감 올라감
예: WAS는 m/c계열, 캐시는 r계열, 빌드는 c계열 등

(3) EBS (Elastic Block Store)

EC2에 붙는 디스크(블록 스토리지)
루트 디스크(부팅 디스크)도 EBS인 경우가 많음
스냅샷으로 백업 가능

(4) 네트워크: VPC / Subnet

EC2는 반드시 VPC(가상 네트워크) 안에서 만들어짐
Public Subnet / Private Subnet에 따라 외부 접근 여부가 달라짐

(5) Security Group

EC2 앞단에서 동작하는 가상 방화벽
인바운드/아웃바운드 규칙으로 포트 오픈 관리 (예: 22, 80, 443)

실무 포인트: “SG는 Allow만 있고 Deny는 없다” 같은 특징도 같이 적으면 좋음

(6) Key Pair (SSH 키)

리눅스 EC2에 SSH 접속할 때 쓰는 키(개인키)
기업은 보안상 Bastion/SSM으로 직접 SSH를 막기도 함

3) EC2는 어떻게 동작하나 (흐름)

AMI 선택
인스턴스 타입 선택
VPC/Subnet 선택
보안그룹 설정(포트/접근 IP)
스토리지(EBS) 크기 설정
생성 후 접속(SSH) → 앱 배포

4) EC2를 실무에서 어떤 용도로 쓰나 (대표 사례)

✅ (1) 웹/WAS 서버

Spring Boot, Node.js, Tomcat 등 애플리케이션 서버 운영

✅ (2) 배치/스케줄러 서버

정산, 통계, ETL, 로그 처리

✅ (3) Bastion Host(점프 서버)

외부에서 바로 내부 서버 접근을 막고, 중간 관문 서버로만 접속

✅ (4) 레거시 마이그레이션

“온프레미스 VM”을 거의 그대로 옮기고 싶을 때 가장 쉬운 선택

5) 장점 / 단점 (냉정하게)

장점

서버를 직접 다루는 자유도 최고(설치/설정 마음대로)
기존 리눅스 운영 경험 그대로 활용 가능
Auto Scaling/ALB 붙이면 탄력적 확장 가능

단점

운영 책임이 크다
- OS 패치
- 보안 취약점 조치
- 로그/모니터링 구성
- 장애 대응
서버 수가 늘면 “서버 팜”이 되어 운영 복잡도가 급증
→ 그래서 보통 **Auto Scaling + ALB + IaC(Terraform 등)**로 표준화함

6) EC2는 언제 쓰고 언제 안 쓰나 (선택 기준)

EC2가 좋은 경우

커스터마이징이 필요한 서버(특정 라이브러리/에이전트/설정)
레거시 앱 마이그레이션
컨테이너/서버리스 이전 전 단계(중간 단계)

EC2가 덜 좋은 경우

“서버 운영 자체를 최소화”하고 싶을 때
→ ECS/Fargate, Lambda, App Runner 같은 관리형이 더 적합

AWS-S3(Amazon Simple Storage Service)

NellKiM — Sun, 8 Feb 2026 17:34:29 +0900

AWS S3란? (Amazon Simple Storage Service)

S3는 AWS에서 제공하는 객체 스토리지(Object Storage) 서비스다.
쉽게 말해 **“서버 관리가 필요 없는 초대용량 파일 저장소”**라고 보면 된다.

1) S3가 왜 나왔는가 (배경)

기존에 파일을 저장하려면 보통:

서버에 디스크 붙이고
NAS 구성하고
이중화/백업 직접 설계하고
디스크 장애 나면 복구 작업 수행

이 과정이 비용도 크고 운영 부담도 큼.

S3는 이런 문제를 해결하기 위해:

저장 용량 제한 ❌
서버 관리 ❌
자동 이중화 ⭕
매우 높은 내구성 ⭕

을 목표로 만들어진 서비스다.

2) S3 한 줄 정의

S3는 무한 확장 가능한 객체(Object) 기반 스토리지 서비스로,
파일을 Key-Value 형태로 저장하고 높은 내구성을 제공한다.

3) S3의 핵심 개념

(1) Bucket

S3의 최상위 컨테이너
전 세계적으로 이름이 유일해야 함
Region 단위로 생성

s3://my-service-bucket/

(2) Object

실제 저장되는 파일 단위
구성:
- Key (파일 경로처럼 보이는 이름)
- Data (파일 내용)
- Metadata

⚠️ S3에는 폴더 개념이 없음
/는 단순히 Key 이름의 일부

(3) Key

images/2026/profile.png

디렉터리처럼 보이지만 실제로는 하나의 문자열
이 구조를 잘 설계해야 관리가 편해짐

4) S3의 동작 방식

클라이언트 또는 서버가 S3 API 호출
S3는 Object를 여러 AZ에 자동 복제
저장 완료 후 Object URL 생성

5) S3의 주요 특징 (중요)

(1) 내구성 vs 가용성

내구성: 99.999999999% (11 nines)
가용성: 약 99.9%

블로그 포인트
“S3는 거의 절대 안 날아가지만, 순간적으로 접근이 안 될 수는 있다”

(2) 스토리지 클래스

Standard: 자주 접근
IA (Infrequent Access): 가끔 접근
One Zone-IA: 단일 AZ
Glacier / Deep Archive: 장기 보관

실무에서는 Lifecycle 정책으로 자동 이동 설정함

6) S3를 실무에서 어떻게 쓰나

✅ (1) 첨부파일 / 이미지 저장

[Client]
   ↓
[Presigned URL]
   ↓
[S3]

서버 부하 없이 클라이언트가 직접 업로드

✅ (2) 로그 / 백업 저장소

애플리케이션 로그
DB 백업 파일
장기 보관 데이터

✅ (3) 정적 웹 호스팅

HTML / CSS / JS
CloudFront와 연계해서 CDN 구성

7) EC2 + S3 아키텍처 예시

[EC2 (WAS)]
   ↓ 파일 업로드
[S3]

[Client]
   ↓ 다운로드
[S3 or CloudFront]

8) S3 보안 (중요 포인트)

(1) Bucket Policy

Bucket 단위 접근 제어
IP, IAM 조건 기반 제어 가능

(2) IAM Policy

사용자/Role 기준 접근 권한 관리

(3) Public Access Block

실수로 공개되는 것 방지
실무에서는 기본 ON

면접에서 자주 나오는 질문:
“S3 공개 사고를 막는 방법은?” → Public Access Block + IAM

9) S3의 장점 / 단점

장점

서버 관리 불필요
높은 내구성
비용 효율적

단점

실시간 파일 수정 불가 (부분 수정 ❌)
파일 시스템 대용 불가 (NFS 아님)
지연 시간은 로컬 디스크보다 큼

10) 언제 쓰고 언제 안 쓰나

S3를 써야 할 때

이미지, 첨부파일
로그/백업
정적 리소스

S3를 쓰면 안 되는 경우

DB 파일 저장소
잦은 파일 수정/잠금 필요한 경우

AWS-IAM(Identity and Access Management)

NellKiM — Sun, 8 Feb 2026 17:34:16 +0900

AWS IAM이란? (Identity and Access Management)

IAM은 AWS에서 “누가(Who) 어떤 리소스에(What) 어떤 권한으로(How)” 접근할 수 있는지를 제어하는 보안의 핵심 서비스다.
AWS를 제대로 쓴다고 하면 IAM을 이해했는지부터 본다고 해도 과언이 아니다.

1) IAM이 왜 중요한가 (왜 나왔나)

AWS는:

콘솔
CLI
API

모두 권한이 있으면 무엇이든 할 수 있는 환경이다.

즉,

권한 관리가 허술하면
→ S3 전체 삭제
→ EC2 종료
→ 비용 폭탄
→ 보안 사고

그래서 AWS는 모든 접근을 IAM으로 통제하도록 설계했다.

핵심 원칙
“권한 없으면 아무것도 못 한다”

2) IAM 한 줄 정의

IAM은 AWS 리소스에 대한 접근을 사용자·역할·정책 기반으로 제어하는 인증/인가 서비스이다.

인증(Authentication): 너 누구냐?
인가(Authorization): 너 뭐까지 해도 되냐?

3) IAM의 핵심 구성 요소

(1) User (IAM 사용자)

사람(개발자, 운영자) 을 위한 계정
콘솔 로그인 / Access Key 사용 가능

❌ 실무에서는:

EC2에 IAM User Access Key를 박아두는 건 안티패턴

(2) Group (그룹)

여러 User를 묶어서 권한 관리
예:
- DevGroup
- OpsGroup
- ReadOnlyGroup

실무 팁:
“User에 직접 정책 붙이지 말고 Group으로 관리”

(3) Role (역할)

AWS 리소스가 AWS 리소스에 접근할 때 사용하는 권한
Access Key 없이 동작
임시 자격증명(STS) 사용

대표 예시

EC2 → S3 접근
Lambda → DynamoDB 접근
EKS Pod → S3 접근

[EC2]
  └─ IAM Role (S3 접근 권한)

실무 핵심
“사람은 User, 서버는 Role”

(4) Policy (정책)

권한을 정의하는 문서 (JSON)
Allow / Deny 기반

기본 구조

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

Effect: 허용 / 거부
Action: 어떤 행동
Resource: 어떤 리소스

4) IAM Policy 종류

(1) Managed Policy

AWS가 제공 (예: AmazonS3ReadOnlyAccess)
빠르지만 권한이 넓음

(2) Inline Policy

특정 User/Role에 직접 붙임
재사용성 ❌

(3) Customer Managed Policy ⭐

실무에서 가장 권장
재사용 가능 + 최소 권한 설계 가능

5) IAM 권한 평가 로직 (중요)

AWS는 권한을 이렇게 판단함:

명시적 Deny → 무조건 거부
Allow가 있으면 허용
아무것도 없으면 기본 Deny

“Deny가 Allow보다 항상 우선”

6) 실무 IAM 설계 예시

EC2가 S3에 업로드해야 할 때 ❌ 잘못된 방식

IAM User 생성
Access Key 발급
EC2에 키 저장

✅ 올바른 방식

S3UploadRole
  └─ s3:PutObject 권한

EC2
  └─ S3UploadRole 연결

키 관리 ❌
보안 사고 위험 ↓

7) IAM 보안 베스트 프랙티스 ⭐

(1) Root 계정

MFA 필수
일상 사용 ❌

(2) 최소 권한 원칙 (Least Privilege)

필요한 권한만 부여
* 남발 금지

(3) MFA

콘솔 접근 User는 필수

(4) Access Key 관리

정기적 로테이션
가능하면 사용 자체를 줄이기 (Role 사용)

8) IAM + 다른 AWS 서비스 연계

EC2 + IAM

Role 기반 접근
S3, CloudWatch, SSM 접근

S3 + IAM

Bucket Policy + IAM Policy 조합

ALB / RDS

직접 IAM 사용 X
간접적으로 서비스 접근 제어에 영향

AWS-ALB(Application Load Balancer)

NellKiM — Sun, 8 Feb 2026 17:34:06 +0900

ALB란? (Application Load Balancer)

ALB는 AWS에서 제공하는 L7(Application Layer) 로드 밸런서로,
HTTP/HTTPS 트래픽을 여러 대상(Target)으로 분산시켜 가용성과 확장성을 높여주는 서비스다.

1) ALB가 왜 나왔는가 (배경)

단일 서버 구조의 문제:

트래픽 증가 → 서버 과부하
서버 장애 → 서비스 전체 다운
배포 중 장애 → 사용자 영향

ALB는 이런 문제를 해결하기 위해:

트래픽 분산
서버 장애 자동 감지
서버 증설/축소 자동 연계

를 목적으로 만들어졌다.

2) ALB 한 줄 정의

ALB는 HTTP/HTTPS 요청을 분석해 여러 백엔드 서버로 분산하는 애플리케이션 계층(L7) 로드 밸런서이다.

3) ALB의 핵심 구성 요소

(1) Listener

ALB가 수신하는 포트
보통:
- 80 (HTTP)
- 443 (HTTPS)

(2) Listener Rule

요청을 어떻게 분기할지 정의
기준:
- URL Path (/api, /admin)
- Host (api.example.com)

(3) Target Group

트래픽을 전달할 대상 묶음
대상 타입:
- EC2
- IP
- Lambda

(4) Health Check

대상 서버 상태 확인
정상(Target)만 트래픽 전달

4) ALB의 동작 흐름

[Client]
   ↓ 443
[Route 53]
   ↓
[ALB Listener]
   ↓
[Target Group]
   ↓
[EC2 #1] [EC2 #2]

클라이언트 요청 수신
Listener Rule 확인
정상 상태 Target으로만 전달

5) ALB의 주요 기능 (실무 핵심)

✅ L7 기반 라우팅

경로 기반 라우팅
도메인 기반 라우팅

✅ SSL 종료(SSL Termination)

인증서(ALB에 설치)
백엔드는 HTTP로 통신 가능

✅ Auto Scaling 연계

EC2 증설/축소 시 자동 Target 등록/해제

✅ 무중단 배포

서버 일부만 교체하며 배포 가능

6) ALB vs NLB vs CLB (비교)

구분	ALB	NLB	CLB
계층	L7	L4	L4/L7
프로토콜	HTTP/HTTPS	TCP/UDP	HTTP/TCP
경로 라우팅	⭕	❌	❌
지연	보통	매우 낮음	보통

일반 웹 서비스 → ALB가 정답

7) ALB 보안 구조

(1) Security Group

ALB 앞단에서 트래픽 필터링
보통 80/443만 오픈

(2) 백엔드 서버 보호

EC2는 ALB SG만 허용
외부 직접 접근 차단

8) 실무 아키텍처 예시

[User]
   ↓
[Route 53]
   ↓
[ALB]
   ↓
[EC2 (WAS) x N]
   ↓
[RDS]

ALB는 Public Subnet
EC2는 Private Subnet
RDS는 Private Subnet

9) ALB의 장점 / 단점

장점

고가용성 (Multi-AZ)
유연한 트래픽 제어
서버 확장 자동화

단점

TCP 레벨 제어 불가
고정 IP 제공 ❌ (→ Route 53 + ALIAS로 해결)

10) 언제 ALB를 써야 하나

ALB를 써야 하는 경우

웹/API 서버
무중단 배포 필요
Auto Scaling 구성

ALB를 안 써도 되는 경우

단일 내부 서비스
TCP 기반 서비스 (→ NLB)

AWS-RDS(Relational Database Service)

NellKiM — Sun, 8 Feb 2026 17:30:11 +0900

AWS RDS란? (Relational Database Service)

RDS는 AWS에서 제공하는 관리형 관계형 데이터베이스 서비스다.
DB를 직접 설치·운영하지 않고도 백업, 장애 대응, 패치까지 AWS가 대신 관리해준다.

1) RDS가 왜 나왔는가 (배경)

기존에 DB 서버를 운영하려면:

DB 설치 및 초기 설정
백업 스케줄 관리
장애 발생 시 복구
복제(Replication) 구성
OS/DB 패치

DB는 서비스의 핵심인데, 운영 부담이 매우 크다.

RDS는 이런 문제를 해결하기 위해:

DB 설치 자동화
백업/복구 자동화
고가용성 구조 제공

을 목표로 만들어졌다.

2) RDS 한 줄 정의

RDS는 관계형 데이터베이스를 관리형으로 제공하여 운영 부담을 줄여주는 AWS 서비스이다.

3) RDS에서 지원하는 DB 엔진

MySQL
PostgreSQL
MariaDB
Oracle
SQL Server

특징
엔진은 선택하지만, OS 레벨은 직접 접근 불가

4) RDS의 핵심 구성 요소

(1) DB Instance

실제 DB가 실행되는 단위
EC2 위에서 동작하지만 직접 제어 불가

(2) Storage

EBS 기반
General Purpose / Provisioned IOPS

(3) Endpoint

애플리케이션이 접속하는 주소
장애 시에도 Endpoint는 유지됨

5) RDS의 주요 기능 (실무 핵심)

✅ 자동 백업

자동 스냅샷
특정 시점 복구(PITR) 가능

✅ Multi-AZ (고가용성)

[Primary]
   ↓ 동기 복제
[Standby]

장애 발생 시 자동 Failover
애플리케이션 수정 거의 없음

✅ Read Replica

읽기 트래픽 분산
조회 성능 개선

6) RDS 동작 아키텍처

[EC2 (WAS)]
   ↓
[RDS (Primary)]
   ↓
[Read Replica]

EC2와 RDS는 보통 Private Subnet
외부 직접 접근 차단

7) RDS 보안 구조

(1) 네트워크 보안

VPC 내부에서만 접근
Security Group으로 접근 제어

(2) 인증

DB 계정 기반 인증
IAM 인증(일부 엔진 지원)

(3) 암호화

저장 시 암호화 (KMS)
전송 시 SSL

8) RDS의 장점 / 단점

장점

DB 운영 부담 최소화
안정적인 백업/복구
고가용성 기본 제공

단점

OS 접근 불가
DB 튜닝/커스터마이징 제한
비용이 EC2 직접 구성보다 높을 수 있음

9) RDS를 언제 쓰고 언제 안 쓰나

RDS가 적합한 경우

일반적인 서비스 DB
운영 인력이 제한적일 때
고가용성이 필요한 서비스

RDS가 부적합한 경우

커널 튜닝 필수
특수 플러그인 필요
완전한 제어가 필요한 경우
→ 이때는 EC2에 DB 직접 설치

10) EC2 + ALB + RDS 전체 구조

[User]
   ↓
[Route 53]
   ↓
[ALB]
   ↓
[EC2 (WAS)]
   ↓
[RDS (Multi-AZ)]