학습 범위 이것은 코딩테스트를 위한 학습 범위인데 내가 1년동안 학습과 경험을 통해서 코딩테스트를 처음 시작할 때 도움이 많이 되었던 것을 소개드릴려고 한다. (구현과 그래프)

이 내용은 코딩테스트 공부를 시작하거나, 자신만의 공부하는 방법이 없는 취업준비생에게 추천한다.

N과M

https://www.acmicpc.net/workbook/view/2052

첫번째는 바로 N과M 시리즈를 다 푸는 것이다. 이때 그냥 푸는 것이 아니라 하나의 코드를 외운다.

이 코드는 N과M 시리즈 1번 문제의 정답이다.

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

public class Main {
    static int n, m;
    static int[] p,r,visited;
    public static void main(String[] args) throws Exception {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());
        n = Integer.parseInt(st.nextToken());
        m = Integer.parseInt(st.nextToken());

        p = new int[m+1];
        visited = new int[n+1];

        perm(0);

    }
    public static void perm(int depth) {
        if(depth >= m){
            for(int i=0;i<m;i++){
                System.out.print(p[i] + " ");
            }
            System.out.println();
            return;
        }
        // 외워야 할 부분 
        for(int i=1;i<=n;i++){
            if(visited[i] == 1) continue;
            visited[i] = 1;
            p[depth] = i;
            perm(depth+1);
            visited[i] = 0;
        }
    }
}

일단 이 코드를 밥 먹으면서도 적을 수 있도록 완벽하게 외운다. 질문은 받지 않는다.

다 외웠다면 조합을 하는 방법까지 알려줄테니 외운다. (N과M-2)

1. 메서드 파라미터에 int start를 추가한다.
2. 재귀 for문을 start부터 돌린다.

    public static void main(String[] args) throws Exception {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());
        n = Integer.parseInt(st.nextToken());
        m = Integer.parseInt(st.nextToken());

        p = new int[m+1];
        // start 값 추가
        combi(0, 1);

    }
    static public void combi(int depth, int start) {
        if(depth >= m){
            for(int i=0;i<m;i++){
                System.out.print(p[i] + " ");
            }
            System.out.println();
            return;
        }
        // visited 없이 start부터 출발 (왜 visited가 필요 없을까?)
        for(int i=start;i<=n;i++){
            p[depth] = i;
            combi(depth+1, i+1);
        }
    }

여기까지 완벽히 외웠다면 이제 여기에 있는 값들을 하나씩 변경시켜 보면서 다른 시리즈를 모두 풀면 된다. 이 두개의 틀에서 조금씩 변형시켜 보고 값을 출력해보면 이 코드가 어떻게 돌아가는 지 감이 잡히게 된다. (안잡히면 그려보는 것을 추천한다)

여기까지 한다면 이제 재귀와 백트래킹에 대해서 이해할 수 있고, 대부분의 문제를 완전탐색으로 접근할 수 있게 된다! (이제부터 코테가 재밌어짐)

빵집 (DFS)

https://www.acmicpc.net/problem/3109

DFS의 대표 문제이다. 풀었더라도 다시한번 풀고, *모르겠다면 오래 고민하지 말아야 한다. *

DFS의 특징을 사용해서 그리디하게 문제를 풀어야 한다.

이 그림을 보고 왜 되는 지 파악하면서 코드를 작성한다. 다시한번 말하지만 너무 시간 쏟지 말고 AI한테 코드를 부탁하고 외운다.

벽부수기 시리즈 (BFS)

https://www.acmicpc.net/search#q=%EB%B2%BD%20%EB%B6%80%EC%88%98%EA%B3%A0&c=Problems

이 시리즈는 단순한 BFS는 아니다. 다차원 BFS이고 벽을 부쉈을 때 안 부쉈을 때 다른 평면에서 움직인다는 것이 핵심 아이디어이다.

        map = new int[n][m];
        visited = new int[n][m][2];

이렇게 3차원 visited 배열을 사용해서 벽이 있다면 부쉈을 때의 세계선, 안부수고 지나갔을 때의 세계선을 다 기록하면서 도착지까지 가는 것이다.

여기까지 문제를 다 풀고 코드를 외웠다면 간단한 구현 문제들은 다 풀 수 있을 것이다!

최소비용 구하기 (다익스트라)

https://www.acmicpc.net/problem/1916

이 문제를 추천하는 이유는 그래프를 구현하는 방법을 배우기 위함이다. 그래프를 배열로 만드는 방식과 연결리스트로 만드는 방식 두가지를 다 시도해보길 바란다.

    static class Rode implements Comparable<Rode> {
        int to;
        int weight;
        public Rode(int to, int weight) {
            this.to = to;
            this.weight = weight;
        }

        @Override
        public int compareTo(Rode o) {
            return this.weight - o.weight;
        }
    }
    ...
    ...
    ...
    private static void bfs(int start) {
        // 초기값 설정
        visited = new int[n+1];
        dist = new int[n+1];
        Arrays.fill(dist, Integer.MAX_VALUE);
        // 탐색 시작
        PriorityQueue<Rode> pq = new PriorityQueue<>();
        pq.add(new Rode(start, 0));
        dist[start] = 0;
        while(!pq.isEmpty()) {
            Rode curRode = pq.poll();
            int cur = curRode.to;
            if(visited[cur] == 1) continue;
            visited[cur] = 1;
            for(Rode next : pList[cur]) {
                if(next.weight + dist[cur] >= dist[next.to]) continue;
                dist[next.to] = next.weight + dist[cur];
                pq.add(new Rode(next.to, dist[next.to]));
            }
        }
    }

Class를 사용해서 길(Road)를 객체화 하고 PriorityQueue를 통해서 weight가 가장 작은 것부터 나오게 하는 것이 왜 속도가 빠르게 되는 지를 이해하면 된다!

여기까지 문제를 풀고 코드를 외웠다면 기본적인 문제를 도전할 수 있게되고, 구현은 되는데 시간 복잡도와 공간복잡도에서 막히게 되는 실력까지 생길 수 있을 것이다.

그때가 되면 알고리즘을 학습해야 한다. 알고리즘 리스트 여기서 하나씩 알고리즘을 골라서 대표 문제를 도전하고 AI에게 정석 코드를 받아서 외우고 다른 대표 문제를 풀면서 알고리즘을 학습한다.

사실 이걸 적으면서 느낀 건데 이 문제들만 푼다고 바로 코딩테스트의 고수가 될 수는 없을 것이다. 나도 아직 너무 못하기 때문에..

하지만 코딩테스트 초보가 알고리즘을 사용하는 문제에 도달하기 전까지 코딩테스트가 재미없고, 벽이 존재한다고 생각한다. 그 벽을 깨고 알고리즘 문제에 도달할 수 있는 구현 능력을 가지게 되었을 때 코딩테스트를 재밌게 느끼고, 실력이 빠르게 늘 수 있다고 생각하기에 이 4가지 종류의 문제를 충분히 익히는 것을 추천한다!

이 사진은 3부라는 리그 경기의 예선전이다. 여기에서 3등을 하게되면 예선 탈락, 1,2 등을 하게 되면 본선으로 가게된다.

이렇게 결과가 본선으로 가게되면 예선전에서는 풀리그 였지만 토너먼트로 경기의 특성이 바뀌고 남자 3부의 결과가 나오게 된다.

이런 특성을 가지고 있기에 대회, 경기, 게임 이 3단계로 구분을 하였고, 복식과 단체전을 커버하기 위해서 그룹테이블을 별도로 만들어 관리하였다.

유저

탁구 리그전 서비스를 이용하는 사용자의 기본 정보를 관리한다. 인증 정보와 탁구 실력을 나타내는 rating(부수) 을 함께 저장하여 사용자 식별과 경기 매칭의 기준으로 활용한다.

CREATE TABLE user (
    user_id BIGINT PRIMARY KEY AUTO_INCREMENT,
    email VARCHAR(255) UNIQUE NOT NULL,
    password VARCHAR(255) NOT NULL,
    username VARCHAR(50) UNIQUE NOT NULL,
    real_name VARCHAR(100) NOT NULL,
    gender ENUM('MALE', 'FEMALE') NOT NULL,
    birth_date DATE NOT NULL,
    region VARCHAR(100),
    phone_number VARCHAR(20),
    rating INT DEFAULT 12 COMMENT '0: 선수부, 1~12: 1부~12부',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

• email과 username은 UNIQUE 제약으로 중복 방지
• 물리적 삭제 대신 소프트 삭제 방식 권장 (기록 보존)

대회

탁구 대회의 최상위 개념으로 전체 이벤트 정보를 관리한다. 한 명의 주최자가 여러 대회를 만들 수 있으며, 하나의 대회는 여러 경기 단계(competition)를 포함할 수 있다.

CREATE TABLE tournament (
    tournament_id BIGINT PRIMARY KEY AUTO_INCREMENT,
    tournament_name VARCHAR(200) NOT NULL,
    start_date DATE NOT NULL,
    end_date DATE NOT NULL,
    location VARCHAR(200) NOT NULL,
    organizer_id BIGINT NOT NULL,
    entry_fee DECIMAL(10, 2) DEFAULT 0,
    event_info TEXT COMMENT '경기 종목 정보',
    prize_info TEXT COMMENT '시상 정보',
    description TEXT,
    status ENUM('DRAFT', 'REGISTRATION_OPEN', 'REGISTRATION_CLOSED', 'IN_PROGRESS', 'COMPLETED', 'CANCELLED') DEFAULT 'DRAFT',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    FOREIGN KEY (organizer_id) REFERENCES user(user_id) ON DELETE RESTRICT
);

organizer_id의 ON DELETE RESTRICT로 주최자 삭제 방지 status로 대회 생명주기 관리 event_info와 prize_info는 TEXT 타입으로 자유롭게 작성 가능

참가자

tournament와 user를 연결하는 중간 테이블로, 누가 어느 대회에 참가했는지 기록한다. 참가 신청부터 최종 순위까지의 전체 과정을 추적한다.

CREATE TABLE tournament_participant (
    participation_id BIGINT PRIMARY KEY AUTO_INCREMENT,
    tournament_id BIGINT NOT NULL,
    user_id BIGINT NOT NULL,
    registration_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    participation_status ENUM('REGISTERED', 'CONFIRMED', 'WITHDRAWN', 'DISQUALIFIED') DEFAULT 'REGISTERED',
    final_rank INT,
    notes TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    FOREIGN KEY (tournament_id) REFERENCES tournament(tournament_id) ON DELETE RESTRICT,
    FOREIGN KEY (user_id) REFERENCES user(user_id) ON DELETE RESTRICT,
    UNIQUE KEY unique_participation (tournament_id, user_id)
);

• (tournament_id, user_id) 조합으로 UNIQUE 제약, 중복 참가 방지
• ON DELETE RESTRICT로 기록 보존
• final_rank는 대회 완료 후 업데이트

경기

하나의 대회 안에서 진행되는 경기 단계를 관리한다. 예선전, 본선, 결승 토너먼트처럼 대회는 여러 단계로 구성될 수 있으며, 각 단계마다 다른 경기 방식과 참가 형식을 가질 수 있다.

CREATE TABLE competition (
    competition_id BIGINT PRIMARY KEY AUTO_INCREMENT,
    tournament_id BIGINT NOT NULL,
    competition_name VARCHAR(200) NOT NULL COMMENT '예선, 본선, 결승 토너먼트 등',
    competition_type ENUM('ROUND_ROBIN', 'SINGLE_ELIMINATION', 'DOUBLE_ELIMINATION', 'GROUP_STAGE') NOT NULL,
    match_format ENUM('SINGLES', 'DOUBLES', 'TEAM') NOT NULL COMMENT '단식, 복식, 단체전',
    competition_order INT NOT NULL COMMENT '대회 내 진행 순서',
    has_groups BOOLEAN DEFAULT FALSE COMMENT '조 편성 여부',
    players_per_group INT COMMENT '조별 인원수',
    description TEXT,
    status ENUM('SCHEDULED', 'IN_PROGRESS', 'COMPLETED', 'CANCELLED') DEFAULT 'SCHEDULED',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    FOREIGN KEY (tournament_id) REFERENCES tournament(tournament_id) ON DELETE RESTRICT
);

• 동일 tournament 내에서 competition_order로 순차적 진행 관리
• match_format에 따라 match_participant 테이블에 저장되는 인원수가 달라짐
• 애플리케이션 레벨에서 match_format에 맞는 참가자 수 검증 필요

그룹 (복식, 단체전)

조별 경기를 위한 그룹 정보를 관리한다. competition에서 has_groups가 TRUE일 때 사용되며, A조, B조와 같이 참가자를 나누어 조별 리그를 진행할 수 있다.

CREATE TABLE `group` (
    group_id BIGINT PRIMARY KEY AUTO_INCREMENT,
    competition_id BIGINT NOT NULL,
    group_name VARCHAR(50) NOT NULL COMMENT 'A조, B조 등',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (competition_id) REFERENCES competition(competition_id) ON DELETE RESTRICT,
    UNIQUE KEY unique_group (competition_id, group_name)
);

• (competition_id, group_name) 조합으로 UNIQUE 제약
• group은 MySQL 예약어이므로 백틱(`)으로 감싸서 사용
• 조가 필요 없는 competition에서는 사용되지 않음

참여자

특정 조에 속한 참가자를 관리한다. 조별 리그에서 어떤 사용자가 어느 조에 배정되었는지, 조 내에서의 최종 순위는 어떻게 되었는지 기록한다.

CREATE TABLE group_participant (
    group_participant_id BIGINT PRIMARY KEY AUTO_INCREMENT,
    group_id BIGINT NOT NULL,
    user_id BIGINT NOT NULL,
    group_rank INT COMMENT '조 내 최종 순위',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (group_id) REFERENCES `group`(group_id) ON DELETE RESTRICT,
    FOREIGN KEY (user_id) REFERENCES user(user_id) ON DELETE RESTRICT,
    UNIQUE KEY unique_group_participant (group_id, user_id)
);

• (group_id, user_id) 조합으로 UNIQUE 제약
• user_id를 직접 참조하여 구조 단순화
• group_rank는 조별 리그 완료 후 업데이트

매치 (게임)

실제 경기 정보를 저장한다. 두 팀(또는 두 명)이 대결하는 개별 경기의 일정, 결과, 세트 스코어를 관리하며, 토너먼트의 경우 대진표 구조도 표현한다.

CREATE TABLE `match` (
    match_id BIGINT PRIMARY KEY AUTO_INCREMENT,
    competition_id BIGINT NOT NULL,
    group_id BIGINT COMMENT '조별 경기인 경우 조 ID',
    match_round INT COMMENT '토너먼트의 경우 라운드 (8강=8, 4강=4, 결승=2)',
    match_number INT COMMENT '같은 라운드 내 경기 번호',
    court_number INT COMMENT '코트 번호',
    status ENUM('SCHEDULED', 'IN_PROGRESS', 'COMPLETED', 'CANCELLED', 'NO_SHOW') DEFAULT 'SCHEDULED',
    winner_side ENUM('SIDE_A', 'SIDE_B', 'DRAW') COMMENT '승리 팀',
    side_a_sets INT COMMENT 'A팀이 획득한 세트 수',
    side_b_sets INT COMMENT 'B팀이 획득한 세트 수',
    total_sets INT COMMENT '총 진행된 세트 수',
    next_match_id BIGINT COMMENT '토너먼트에서 다음 라운드 경기',
    notes TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    FOREIGN KEY (competition_id) REFERENCES competition(competition_id) ON DELETE RESTRICT,
    FOREIGN KEY (group_id) REFERENCES `group`(group_id) ON DELETE RESTRICT,
    FOREIGN KEY (next_match_id) REFERENCES `match`(match_id) ON DELETE SET NULL
);

• next_match_id로 토너먼트 대진표 구조 표현
• 세트 스코어를 간단하게 기록 (예: 3:1이면 side_a_sets=3, side_b_sets=1, total_sets=4)
• match는 MySQL 예약어이므로 백틱(`)으로 감싸서 사용
• ON DELETE SET NULL로 next_match_id는 참조하는 경기 삭제 시 NULL 처리

게임 참가자

각 경기에 참여하는 선수들을 관리한다. 단식은 양쪽 1명씩, 복식은 2명씩, 단체전은 3명 이상이 참여하며, side로 양 팀을 구분하고 participant_order로 팀 내 순서를 관리힌다.

CREATE TABLE match_participant (
    match_participant_id BIGINT PRIMARY KEY AUTO_INCREMENT,
    match_id BIGINT NOT NULL,
    user_id BIGINT NOT NULL,
    side ENUM('SIDE_A', 'SIDE_B') NOT NULL,
    participant_order INT COMMENT '복식이나 단체전에서 순서',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (match_id) REFERENCES `match`(match_id) ON DELETE RESTRICT,
    FOREIGN KEY (user_id) REFERENCES user(user_id) ON DELETE RESTRICT
);

• 같은 match_id에 여러 명이 참여 가능
• competition의 match_format에 따라 참가자 수 검증 필요 SINGLES: 각 side당 1명 (총 2명) DOUBLES: 각 side당 2명 (총 4명) TEAM: 각 side당 3명 이상
• participant_order로 복식에서 1번, 2번 선수 구분 가능

이 문제의 핵심 아이디어는 두가지이다.

1. 연속 부분 수열을 골라도 -1, 1, -1... 패턴과 1, -1, 1... 패턴 두가지만 나온다는 점
2. 연속 부분 수열의 최대 합을 구하는 최적화 알고리즘

그렇기에 두가지 패턴을 적용한 배열 두개를 카데인 알고리즘을 통해서 Max 값을 구해주는 것이 핵심

카데인 알고리즘?

최대 부분 배열 합을 O(n) 시간에 해결하는 알고리즘

간단하게 3, 1, -5, 4, 2 라는 배열이 있으면

3 -> 3+1= 4 -> 4-5= -1 -> -1 + 4 = 3 (초기화!) = 4 -> 4+2=6

중간에 그 전의 합이 -1이기 때문에 값이 줄어드는 곳을 다시 자기 자신으로 초기화 한다. 그렇게 한번의 순회로 6이 최대값임을 알게된다.

코드

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

class Solution {
    static int n;
    static long answer;
    static int[] arr1, arr2;
    public long solution(int[] sequence) {
        answer = Long.MIN_VALUE;
        n = sequence.length;

        arr1 = new int[n];
        arr2 = new int[n];
        // int 배열 초기화를 하면 0이기 때문에 이런 식으로 작성
        for(int i=0;i<n;i++){
            if(i % 2 == 0) {
                arr1[i] += sequence[i];
                arr2[i] -= sequence[i];
            }
            else{
                arr1[i] -= sequence[i];
                arr2[i] += sequence[i];
            }
        }
        // 두 배열의 연속 펄스 부분 수열의 합의 최댓값중 큰 값이 정답 
        return Math.max(kadein(arr1,n), kadein(arr2,n));
    }

    public static long kadein(int[] arr, int len){
        long max = Long.MIN_VALUE;
        long sum = 0;

        for(int i=0;i<len;i++){
            long newSum = sum + arr[i];
            // 새로운 합이 나보다 크면 계속
            if(newSum >= arr[i]){
                sum = newSum;

                if(newSum > max) max = newSum;
            }
            // 작으면 나로 초기화 
            else{
                sum = arr[i];

                if(sum > max) max = sum;
            }
        }

        return max;
    }  

}

1. B2B 시장의 구조적 특성과 문제점

글로벌 B2B 시장은 B2C 시장 대비 최소 3배에서 수십 배에 이르는 규모를 가진다. 일상적인 소비재 이면에는 원자재 수입, 설비 투자, 물류 계약 등 복잡하고 대규모의 기업 간 거래가 존재한다.

그러나 이러한 거대한 시장은 여전히 비효율적인 방식으로 운영되고 있다. 주문서는 팩스로 전달되고, 납기 관리는 전화로 이루어지는 등 디지털 전환 수준이 낮은 것이 현실이다.

특히 가장 심각한 문제는 자금 흐름의 비효율성이다. 상품은 즉시 납품되지만 대금은 60일 이후에 지급되는 외상 거래 구조로 인해, 수익성이 있음에도 불구하고 유동성 부족으로 도산하는 이른바 흑자부도가 빈번하게 발생한다. 대기업 중심의 외상 거래 관행 속에서 중소기업은 운영자금 조달에 구조적인 어려움을 겪고 있다.

2. AI 조달 에이전트의 등장과 역할 변화

최근 기업 조달 영역에 AI 기반 에이전트가 도입되고 있다. 해당 에이전트는 전 세계 공급망 데이터를 실시간으로 분석하며, 특정 지역의 자연재해나 공급 차질 발생 시 즉각적으로 대체 공급처로 주문을 전환한다.

아마존 비즈니스의 경우 2024년 기준 연 거래액이 약 6,380억 달러에 달하며, AI가 재고 부족을 자동으로 감지하고 주문을 실행하며, 대량 구매 시에는 자동 협상 기능을 수행한다.

가격 결정 방식 또한 변화한다. 구매 수요가 발생하면 다수의 공급사 AI가 실시간 역경매에 참여하여 최저가를 제시하며, 거래 조건은 인맥이나 관행이 아닌 데이터 기반으로 결정된다. 이로 인해 조달 시장은 완전 경쟁에 가까운 구조로 전환된다.

계약 체결 이후에는 종이 문서 대신 스마트 계약이 생성된다. 검수 통과 시점과 결제 조건이 코드 형태로 명시되며, 위변조가 불가능한 디지털 주문서는 새로운 금융 담보로 기능한다.

3. 공급망 금융(Supply Chain Finance)의 혁신

AI 기반 조달이 확산되더라도 외상 거래 관행 자체는 단기간에 사라지기 어렵다. 이 지점에서 금융기관의 역할이 중요해진다. 공급망 금융은 확정된 주문서를 기반으로 금융기관이 선제적으로 자금을 공급하는 구조를 의미한다.

은행의 AI 시스템은 구매 기업의 조달 데이터를 실시간으로 연동받아, 신뢰도가 높은 주문에 대해 공급 기업에 선지급 금융을 제공한다. 예를 들어 대기업이 하청 업체에 대규모 주문을 발주한 경우, 해당 주문의 신뢰성을 근거로 은행이 제작 자금을 먼저 대출하는 방식이다.

중국 징둥닷컴(JD.com)의 공급망 금융은 수십조 원 규모로 운영되며, 입점 판매자의 매출 데이터를 AI가 분석하여 평균 3일 이내 자금이 지원된다. 이 과정에서 부실률은 1% 미만으로 유지되며, 이는 AI가 확정성과 신뢰도가 높은 거래만을 선별하기 때문이다.

기존의 담보는 부동산이나 설비였으나, 새로운 담보는 데이터이다. 확정된 주문과 매출 데이터가 금융 신용을 대체하며, 신용 등급이 낮은 기업도 실질적인 거래 증빙이 있다면 금융 접근이 가능해진다.

4. AI 기반 신규 금융 서비스의 확장

AI 조달 에이전트는 개별 기업의 수요를 통합하여 규모의 경제를 실현한다. 지사별로 분산된 구매를 통합함으로써 단가 절감 효과를 극대화한다.

또한 금융과 물류의 결합이 가능해진다. 선박의 항만 진입 정보나 물류 이동 데이터가 실시간으로 감지되면, 은행 시스템은 자동으로 결제 절차를 실행한다. 물류의 이동이 금융 거래의 트리거로 작동하는 구조이다.

동적 할인 모델 역시 구현 가능하다. 구매 기업이 조기 지급을 조건으로 할인율을 제안하면, 판매 기업은 유동성을 확보하고 구매 기업은 원가를 절감하는 상호 이익 구조가 형성된다.

이 모든 금융 기능은 은행 애플리케이션이 아닌 기업 ERP 시스템 내부의 API 형태로 제공된다. 구매 담당자는 단순히 자재를 주문하지만, 백엔드에서는 대출 실행과 결제가 자동으로 처리되는 인비저블 코퍼레이트 뱅킹이 구현된다.

해외 거래의 경우 환전 또한 AI가 담당한다. 환율 변동성을 분석하여 최적의 송금 시점을 선택하며, 은행은 이를 통해 추가적인 수수료 수익을 확보한다.

기업 대출 한도 역시 고정적이지 않다. 대규모 프로젝트 수주와 같은 이벤트가 발생하면 AI가 이를 증빙하여 한도를 일시적으로 확장한다. 이는 기업 활동에 연동된 탄력적 금융 모델이다.

5. 리스크 관리와 한계 과제

AI는 전통적인 재무제표 외에도 다양한 대체 데이터를 활용한다. 예를 들어 공장 전력 사용량 감소는 생산 중단 신호로 해석될 수 있으며, 이를 통해 부도 가능성을 조기에 감지한다.

반면, AI 간 담합과 같은 새로운 리스크도 존재한다. 특정 공급사와 구매사 AI가 알고리즘 차원에서 담합할 가능성이 있으며, 이는 기존의 인적 부패보다 탐지가 어렵다. 이에 따라 금융기관은 거래 공정성을 감시하는 별도의 AI 시스템을 운영할 필요가 있다.

6. 은행 산업의 기회 요인

공급망 금융은 은행 입장에서 높은 수익성을 가진다. 확정 주문서를 담보로 한 선지급 금융은 연 환산 기준 12% 이상의 수익률을 기대할 수 있으며, 이는 일반 기업 대출 대비 두 배 수준이다. 국내 공급망 금융의 잠재 시장 규모는 100조 원 이상으로 추산된다.

다만 금융기관 단독으로는 한계가 있다. 조달 및 물류 데이터는 ERP 기업이나 플랫폼 사업자가 보유하고 있으므로, SAP 등 ERP 기업 및 물류 기업과의 전략적 파트너십이 필수적이다.

또한 대기업보다 중소기업 영역에서 더 큰 기회가 존재한다. AI 기반 조달 시스템은 기존 신용 평가에서 소외되었던 건실한 중소기업을 발굴할 수 있으며, 이는 상생 금융과 신규 수익 창출을 동시에 가능하게 한다.

7. 결론

AI 기반 조달과 공급망 금융의 결합은 단순한 비용 절감 수단이 아니다. 이는 물류의 속도와 금융의 속도를 일치시키는 구조적 혁신이다. 자금 흐름이 원활해질수록 경제 전반의 효율성은 향상된다.

B2B 시장은 압도적인 규모를 가지고 있으며, 공급망 금융은 기존 대출 대비 높은 수익성을 제공한다. 국내 시장 역시 충분한 성장 잠재력을 보유하고 있다.

향후 금융기관의 경쟁력은 공급망 데이터와 얼마나 깊이 연결되어 있는지에 의해 결정될 것이다. AI와 결합된 공급망 금융은 기업의 자금 흐름을 개선하는 핵심 인프라로 자리 잡을 것이다.

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

class Solution{
    // 노드 엔티티 
    class TrieNode{
        Map<Character, TrieNode> children;
        int count;
        Boolean isEnd;

        TrieNode() {
            this.children = new HashMap<>();
            this.count = 0;
            this.isEnd = false;
        }
    }
    // 트라이 자료구조
    class Trie{
        TrieNode root;

        Trie(){
            this.root = new TrieNode();
        }

        // 문자열을 통해 트라이 트리 만들기
        void addNode(String word){
            TrieNode node = root;
            for(char c : word.toCharArray()){

                // 해당 문자 노드 없으면 추가
                if(!node.children.containsKey(c)){
                    node.children.put(c,new TrieNode());
                }
                // 이동 후 count 추가
                node = node.children.get(c);
                node.count++;
            }
            // 마지막 노드에 도착했으면
            node.isEnd = true;
        }

        // 해당 문자열이 몇개를 검색해야 하는가? 
        int countNode(String word){
            TrieNode node = root;
            int count = 0;

            for(char c : word.toCharArray()){
                node = node.children.get(c);
                count++;
                // 이동하면서 1로 변하는 순간 or 끝까지 간다면 count 횟수 반환
                if(node.count == 1 || count == word.length()){
                    return count;
                }
            }
            return word.length();
        }

    }


    public int solution(String[] words) {
        int answer = 0;
        Trie trie = new Trie();
        // 추가
        for(String word : words){
            trie.addNode(word);
        }
        // 검색
        for(String word: words){
            answer += trie.countNode(word);
        }

        return answer;
    }
}

풀이

문제를 보고 트라이 자료구조를 떠올리게 되었다. 추가와 탐색 과정을 거치면서 최적화를 진행하고자 했다.

이건 트라이 자료구조를 통해서 go, gone, guild 단어를 넣게 되었을 때 어떻게 추가되는 지 그려보았다. 이렇게 트리가 완성되었다면 1로 바뀌거나 (자신만 남음), 단어 길이가 끝났을 때 몇번 검색(count)이 일어났는 지 확인해준다면 정답을 찾을 수 있다.

2025년은 우리 경제가 수많은 격변과 도전에 직면한 해였습니다. 1분기에는 예상치 못한 정치적 충격으로 역성장을 기록했고, 4월에는 트럼프 행정부의 강도 높은 관세 조치로 글로벌 통상 환경이 악화되었습니다. 6월 대선 이후 정치 리스크가 완화되면서 성장 흐름이 일부 회복되었으나, 한미 투자 협정을 둘러싼 통상 갈등이 10월 말 APEC 정상회의까지 이어지며 경기 회복 속도를 저해했습니다.

한국은행은 비상계엄 직후 경제 시스템의 독립성과 정상 작동에 대한 신뢰 구축에 주력했으며, 상반기 중 기준금리를 두 차례 인하했습니다. 하반기에는 수도권 주택시장 불안과 환율 변동성 심화로 성장과 금융안정 사이의 긴장이 고조되어 기준금리를 동결할 수밖에 없었습니다.

2026년 주요 위험 요인

글로벌 통상환경과 통화정책 불확실성

미국의 사법적·정치적 변수에 따라 관세 및 무역정책 리스크가 재부상할 가능성이 있습니다. G20 회의의 글로벌 불균형 이슈로 인한 국가간 갈등 확대 가능성도 존재합니다. 한미 투자 협정과 관련해서는 연간 200억 달러 규모의 대미 투자가 예정되어 있으나, 이는 최대치이며 실제 투자 규모는 외환시장 안정을 저해하지 않는 범위 내에서 결정될 것입니다.

파월 의장의 임기 종료 이후 미국 통화정책 방향과 일본, 유로존, 호주 등의 금리 인상 가능성도 중요한 변수입니다.

주요국 재정 건전성과 국채시장

주요 선진국들의 고령화로 인한 재정지출 증가와 코로나19 이후 누적된 정부 부채의 이자 부담 확대로 재정 여건이 크게 악화되었습니다. 글로벌 장기 국채금리가 크게 상승했으며, 국채시장에서 비은행 금융기관의 영향력 확대로 충격 발생시 위험이 증폭될 수 있습니다.

AI 산업 기대 조정 가능성

AI 관련 기업들의 주가가 빠르게 상승한 가운데, 가격 조정 발생시 위험 확산 가능성이 제기되고 있습니다. 우리나라는 반도체 생산 부문에서 경쟁력을 갖추고 있어 비교적 높은 회복력을 유지할 것으로 보이나, 국내 투자자들의 글로벌 AI 기업에 대한 익스포저 확대로 리스크 관리의 중요성이 커지고 있습니다.

국내 경제 전망

물가

소비자물가 상승률은 일시적 요인이 완화되면 연간 2.1%를 기록하며 안정된 흐름을 보일 것으로 예상됩니다. 다만 높은 환율 수준 지속시 물가 상승 압력이 다시 커질 수 있습니다. 팬데믹 이후 누적된 높은 생활물가 수준이 서민들의 부담을 가중하고 있어, 통상 구조 개선과 수입 개방 확대 등 구조적 개혁 노력이 병행되어야 합니다.

성장

올해 성장률은 1.8%로 작년 1.5%에 비해 상당히 높아져 잠재 수준에 근접할 것으로 전망됩니다. 다만 IT 부문을 제외할 경우 성장률은 1.4%에 그쳐 K자형 회복 패턴이 나타날 것으로 보입니다. 이는 지속가능한 완전한 회복으로 보기 어렵습니다.

환율

원달러 환율이 지난해 말 1400원대 후반까지 상승했으나, 우리나라는 순 대외채권국으로 대외 건전성이 양호한 만큼 과거 위기 상황과 유사하다고 보는 것은 적절하지 않습니다. 다만 최근 1400원대 후반의 환율은 우리 경제의 펀더멘털과 괴리가 큰 수준으로 판단됩니다.

환율 상승의 배경에는 한미간 성장률 및 금리 격차, 코리아 디스카운트 등이 있으며, 중장기적으로 국내 산업 경쟁력 강화와 자본시장 제도 개선이 필요합니다. 단기적으로는 거주자의 지속적인 해외 증권 투자가 외환시장 수급 불균형을 초래하여 환율 상승 압력으로 작용했습니다.

국민연금 해외투자 관련 이슈

국민연금의 해외 투자 규모와 시기, 환헤지 운영 전략 등이 국내외 시장에 지나치게 투명하게 드러나면서 환율 변화 기대가 한 방향으로 쏠리는 문제가 발생했습니다. 국민연금의 해외 투자가 거시적으로 우리 경제 성장과 국내 자본시장 발전에 미치는 영향을 종합적으로 검토할 필요가 있습니다.

최근 보건복지부가 전략적 환헤지의 탄력적 대응을 위한 기획단을 구성하고, 정부 관련부처, 국민연금, 한국은행이 협력하여 국민연금 해외 투자의 뉴프레임 구축에 대해 논의하기로 한 것은 큰 진전입니다.

2026년 통화정책 방향

성장 경로에 상하방 위험이 모두 존재하고 물가 흐름도 환율 변화에 따라 달라질 수 있으며, 수도권 주택가격 동향도 지속적으로 점검해야 합니다. 정책 환경의 불확실성이 커지고 정책 변수간 상충이 심화되는 만큼, 향후 통화정책은 다양한 경제 지표를 자세히 점검하면서 정교하게 운영해 나갈 것입니다.

시장과의 소통을 강화하고, 금융통화위원회 향후 3개월 내 조건부 기준금리 전망의 운용 방향 등을 재점검하면서 신뢰도를 높일 수 있도록 정책 커뮤니케이션을 더욱 정교하게 다듬어 나갈 것입니다.

기타 통화정책 수단

금융중개지원대출 제도는 준재정적 정책적 성격을 줄이고 금리 정책을 보완하는 수단으로 재정비할 예정입니다. 유동성 안전판 역할도 확대하여 은행 대출채권 적격담보 시스템을 올해부터 가동하고, 대상을 비은행 예금취급 기관까지 확대할 수 있도록 한국은행법 개정을 추진 중입니다.

구조개혁 연구와 싱크탱크 역할

지난 3년간 구조개혁 연구 시리즈를 통해 정책 대안을 제시해 왔으며, 내부 설문조사 결과 직원의 53%가 긍정적으로 평가했습니다. 원화 스테이블코인 보고서, 자율주행 택시 도입 연령의 결정 제도 개선, 고령층 계속 근로에 대한 보고서 등이 좋은 사례입니다. 앞으로도 양질의 연구를 통해 우리 경제의 방향을 제시하는 나침판 역할을 계속할 것입니다.

디지털 혁신과 AI 도입

프로젝트 한강 1차 실증을 마무리했고 올해는 2차 실증을 추진할 계획입니다. 블록체인을 활용한 정부의 국고금 관리 개선 사업을 적극 지원하고, 프로그래머블 화폐의 활용 경험을 축적할 것입니다. 원화 스테이블코인 발행이 필요하다고 판단하며, 위험을 최소화하면서도 혁신을 촉진할 수 있는 도입 방안을 제시했습니다.

국내 주요 기업과 협력하여 구축한 한국은행 AI 언어모형을 이달 말부터 선보일 예정이며, 망통합 사업도 3월까지 마무리할 계획입니다. 직원들이 업무 전반에 AI를 적극 활용하여 일하는 방식의 혁신을 이끌어가기를 바랍니다.

조직문화 개선과 감사 인사

지난해 말 자율기부 행사에 79.9%의 높은 참여율을 보였고, 지난 3년간 추진해 온 조직문화 개선 노력으로 조직의 역동성이 강화되고 있습니다. 부처간 유기적 협업과 정보 공유가 확대되고, 자유로운 의견 교환 문화가 자리잡고 있으며, 조사연구 방식도 탑다운에서 바텀업으로 전환되고 있습니다.

한국은행 자료 인용 보도는 전년 대비 약 11% 증가했고, 공식 유튜브 채널 구독자도 11만 명을 넘어섰습니다. 각자의 자리에서 최선을 다해 주신 모든 임직원께 깊은 감사를 드립니다.

마무리

새해도 여러 과제와 난관이 놓여 있지만, 유지경성(有志竟成)이라는 말처럼 뜻을 모아 한마음으로 임한다면 충분히 헤쳐 나갈 수 있을 것입니다. 중앙은행 직원으로서 원칙과 사명을 마음에 새기고 우리 경제의 장기적 안정을 위해 노력할 때 우리의 성과는 반드시 평가받을 것입니다. 병진년 붉은 말의 해가 지닌 역동적인 기운과 함께 새로운 한해를 힘차게 시작합시다.

2025년 대한민국 주요 보안 사고

2025년은 대한민국 사이버 보안 역사에서 가장 암울한 해로 기록될 것으로 보인다. 통신, 금융, 유통 등 모든 산업 분야에서 대규모 보안 사고가 연쇄적으로 발생하면서 국민 절반 이상이 개인정보 유출 피해에 노출되었다.

올리브영 해킹 (3월 11~12일)

피해규모

CJ그룹 핵심 계열사인 올리브영이 크리덴셜 스터핑 공격을 받았다. 약 6만여 개의 IP에서 로그인 시도가 감지되었으며, 이 중 4,900건의 계정에서 실제 로그인이 성공했다. 최종적으로 4,000건 이상의 개인정보 유출이 의심되었다. 유출 가능성이 있는 정보에는 이름, 휴대전화번호, 이메일 주소, 배송지 주소 등이 포함되었다.

방법

여러 경로에서 수집한 계정과 비밀번호를 무작위로 대입하는 크리덴셜 스터핑(Credential Stuffing) 공격 기법이 사용되었다. 공격은 2025년 3월 11일 22시 09분부터 3월 12일 03시 54분까지 약 6시간 동안 집중적으로 이루어졌다.

대응

올리브영은 공격을 탐지한 후 즉시 비정상 로그인을 차단하는 조치를 취했다. 유출 가능성이 있는 고객들에게 개별 통지를 발송했으며, 비밀번호 변경을 권고했다. 한국인터넷진흥원(KISA) 및 관계기관에 신고를 완료했다. 이 사건은 2025년 상반기 대기업 연쇄 해킹 사고의 신호탄이 되었으며, 기업 신뢰도 하락과 함께 보안 강화 필요성이 대두되었다.

관련기사

• https://www.boannews.com/media/view.asp?idx=114594
• https://economist.co.kr/article/view/ecn202503210066
• https://www.catchsecu.com/archives/23702

SK텔레콤 대규모 유출 (4월 18일)

피해규모

국내 최대 통신사 SK텔레콤이 중국계 APT 조직으로 추정되는 공격자에 의해 대규모 개인정보 유출 피해를 입었다. 약 2,696만 건의 개인정보가 유출되었으며, 유출 규모는 9.82GB에 달했다. 유출된 정보에는 전화번호, IMSI(가입자 식별번호), Ki(유심 인증 키), IMEI 등 통신사 이용자 식별 및 인증 정보 25종이 포함되었다.

방법

BPFdoor라는 고도화된 백도어 악성코드가 사용되었다. BPFdoor는 주로 중국계 APT 조직이 사용하는 리눅스 기반 백도어로, 일반적인 네트워크 보안 장비를 우회하여 명령을 수신할 수 있는 특수한 구조를 가지고 있다. 공격자는 SKT의 내부 네트워크 시스템인 HSS(Home Subscriber Server)에 장기간 잠복하며 핵심 데이터를 탈취했다. 총 27종의 BPF도어, 3종의 타이니쉘, 1종의 웹쉘, 2종의 오픈소스 악성코드(CrossC2, 슬리버)가 발견되었다.

대응

과학기술정보통신부는 이번 해킹 사건을 조사하면서 계정 정보 관리 부실, 과거 침해사고 대응 미흡, 주요 정보 암호화 조치 미흡 등 세 가지 문제점을 지적했다. SK텔레콤은 고객의 2차 피해를 방지하기 위한 조치를 취했으나, 결국 1,374억 9,100만 원의 과징금 처분을 받았다. 유영상 대표는 해킹 사태의 책임을 지고 물러났으며, 서울중앙지법 부장판사 출신인 정재헌 대외협력 사장이 신임 CEO로 선임되어 SKT 최초 법조인 CEO가 되었다. 조직적으로도 임원진 30%를 감축하는 등 강도 높은 구조조정이 단행되었다.

관련기사

• https://theori.io/ko/blog/2025-h1-hot-security-issue-case
• https://www.catchsecu.com/archives/23702
• https://m.boannews.com/html/detail.html?idx=140880

롯데카드 해킹 (8월)

피해규모

금융권 최대 규모의 개인정보 유출 사고로, 297만 명의 고객 정보가 유출되었다. 롯데카드 전체 회원 900만 명 중 3분의 1가량이 피해를 입었다. 특히 이 중 28만 명은 카드번호, CVC(카드 보안 코드), 유효기간 등 민감한 결제 정보까지 유출되어 2차 금융 피해 우려가 커졌다. 사고 이후 약 한 달 반간 78만 명이 카드를 재발급했고, 약 100만 명이 비밀번호를 변경했다. 카드 정지를 택한 고객은 18만 명, 카드 해지를 택한 고객은 5만 6,000명이 넘었으며, 3만 715명이 롯데카드 회원 탈퇴를 선택했다.

방법

2017년에 발견된 Apache Struts2 취약점(CVE-2017-5638)이 8년간 패치되지 않은 것이 사고의 원인이었다. 48개 결제 서버 중 단 한 개의 서버에서 패치가 누락되었으며, 해커는 이 취약점을 통해 웹셸(Webshell)을 설치하고 장기간에 걸쳐 고객 데이터를 빼돌렸다. 이는 기본적인 패치 관리 실패로 인한 보안 사고의 전형적인 사례로 평가된다.

대응

금융당국은 이를 심각한 내부 통제 부재로 규정했다. 롯데카드는 2025년 10월 15일부터 온라인 가맹점 이용을 제한해 부정결제 가능성을 원천적으로 차단했다고 밝혔다. 조좌진 롯데카드 대표가 책임을 지고 사임했다. 이 사건은 제2금융권 전반의 기본적인 보안 점검이 미흡하다는 현실을 보여주었으며, 금융사에 대한 징벌적 과징금 도입 논의가 본격화되는 계기가 되었다.

관련기사

• https://www.genians.co.kr/blog/data_leak
• https://m.boannews.com/html/detail.html?tab_type=1&idx=140894
• https://www.getnews.co.kr/news/articleView.html?idxno=854990

KT 개인정보 유출 (9월 공개, 2024년 10월 발생)

피해규모

KT는 2024년 10월 발생한 해킹 사고를 1년 6개월간 은폐하다가 2025년 하반기에야 뒤늦게 신고했다. 내부 서버 43대에서 개인정보 유출 가능성이 확인되었다. 368명의 이용자가 가짜 기지국(IMSI Catcher)을 통해 인증 문자를 탈취당해 2억 원대 소액결제 피해를 입었다. 이동통신망을 기반으로 한 무단 소액결제 사태와 함께 대규모 개인정보 유출이 확인되었으며, 개인정보 유출 정황 최초 발생 시기는 2024년 10월로 확인되었다.

방법

SK텔레콤 유심 해킹에 사용된 BPFdoor 악성코드에 KT도 감염되었다. 그러나 KT는 이를 신고하지 않았으며, 피해 서버를 폐기하며 증거 은폐 의혹이 제기되었다. 구조적 보안 취약점과 단일 암호키 관리 문제가 지적되었다. 가짜 기지국을 통한 공격은 이동통신 인프라의 근본적인 취약점을 드러냈다.

대응

과학기술정보통신부는 KT의 고의 은폐 사실을 경찰에 수사 의뢰했다. 법적 리스크와 가입자 이탈 등 경영 불확실성이 커졌으며, 김영섭 KT CEO가 이번 사태에 책임을 지고 물러났다. SK텔레콤 유심 해킹 사건 이후 통신사 전반의 보안에 대한 우려가 높아진 상황에서, KT의 은폐 시도는 통신사 신뢰도에 치명타를 입혔다. 정부와 통신사는 단순 소액결제 경로 분석을 넘어 해킹 전반에 대한 폭넓고 체계적인 조사가 필요하다는 지적을 받았다.

관련기사

• https://m.boannews.com/html/detail.html?idx=140880
• https://www.genians.co.kr/blog/data_leak
• https://mind-sat.com/kr/blog/q3-2025-security-incidents/

쿠팡 개인정보 대규모 유출 (11월 6일 발생, 11월 29일 공개)

피해규모

2025년 최대 규모의 개인정보 유출 사고로, 약 3,370만 개의 고객 계정 정보가 유출되었다. 이는 2024년 3분기 기준 활성 고객 수 2,470만 명보다 많은 수치로, 사실상 모든 가입자의 개인정보가 유출된 것으로 평가된다. 유출된 정보에는 이름, 전화번호, 이메일 주소, 배송 주소록, 주문 정보, 공동현관 출입번호(2,609개) 등이 포함되었다. 다만 쿠팡은 결제 정보, 로그인 관련 정보, 개인통관고유부호는 유출되지 않았다고 발표했다.

방법

전직 중국인 직원이 재직 중 취득한 내부 보안 키를 탈취해 장기간 비정상적인 접근을 시도한 것으로 추정된다. 해외 서버를 통해 2025년 6월 24일부터 장기간에 걸쳐 비정상적 접근이 이뤄졌다. 회원이 로그인할 때 사용되는 1회용 암호인 액세스 토큰을 사용한 비인가 무단 접근이 발생했다. 이는 외부 해킹이 아닌 내부자가 합법적 권한을 악용해 정보를 탈취한 '내부 보안 통제 실패' 사례로 분류된다. 장기 유효 인증키 방치가 부른 인재(人災)로 평가되었다.

대응

쿠팡은 11월 6일 18시 38분 최초 침해가 발생했지만, 이를 즉시 인지하지 못했다. 침해 사실을 알게 된 날은 12일이 지난 11월 18일 오후 10시 52분이었으며, 그마저도 쿠팡이 선제적으로 감지한 것이 아니라 고객의 민원으로 알게 되었다는 비판을 받았다. 처음 발표 시에는 약 4,500건으로 공지했다가, 11일 만인 11월 29일에 3,370만 건으로 정정하며 초기 대응 실패와 커뮤니케이션 부실로 신뢰도에 치명타를 입었다.

무단 접근 경로를 차단하고 내부 모니터링을 강화했으며, 보안기업 전문가를 영입하는 등의 후속 조치를 취했다. 경찰청, 한국인터넷진흥원, 개인정보보호위원회에 신고를 완료했다. 12월 25일 쿠팡은 유출자를 특정했고, 실제 저장된 정보는 약 3,000개 계정분이라고 재발표했으나, 정부는 합동조사 중 일방적 발표라며 강력 반발했다. 대통령실은 성탄절에 범부처 관계장관 회의를 긴급 소집해 경영진 처벌 방안과 소비자 피해 구제책 등을 논의했다.

관련기사

• https://namu.wiki/w/쿠팡%20개인정보%20대규모%20유출%20사건
• https://www.hankookilbo.com/News/Read/A2025112917570000564
• https://www.khan.co.kr/article/202512251620001
• https://www.news1.kr/it-science/general-it/6020049
• https://www.dginclusion.com/news/articleView.html?idxno=1273

종합 분석

2025년 보안 사고들은 "복잡한 고급 기술보다 기본에 충실하지 못해 발생했다"는 공통점을 보인다. 8년 전 취약점 미패치, 크리덴셜 스터핑 방어 미흡, 장기 유효 토큰 방치 등은 모두 기본적인 보안 원칙의 실패다.

개발자는 새로운 기술을 배우는 것도 중요하지만, 보안의 기본 원칙을 철저히 지키는 것이 더욱 중요하다. 특히 백엔드 개발자로서, 인증/인가 체계, API 보안, 데이터 암호화, 모니터링 등 보안의 기본을 탄탄히 다져야 한다. 보안은 선택이 아닌 필수이며, 한 번의 실수가 수천만 명의 개인정보 유출로 이어질 수 있다는 점을 명심해야 한다.

Index가 무엇인가요?

"Index는 데이터베이스에서 특정 컬럼의 값을 기준으로 데이터를 빠르게 검색하기 위한 자료구조입니다. 책의 목차처럼 원본 테이블과 별도로 관리되며, 컬럼 값과 해당 레코드의 물리적 위치 정보를 정렬된 형태로 저장합니다. 대부분의 RDBMS에서는 B+Tree 구조를 사용하는데, 이는 균형 잡힌 트리 구조로 탐색, 삽입, 삭제 연산이 모두 O(log N)의 시간복잡도를 가지기 때문입니다. Index를 통해 *Full Table Scan *없이 필요한 데이터에 직접 접근할 수 있어 조회 성능을 크게 향상시킬 수 있습니다."

이것이 내가 생각한 완벽한 답안이고 이걸 하나씩 풀어보겠다.

이미지 출처

특정 컬럼의 값을 기준 : 그림에서 company_id 값을 정렬하고 그 위치인 pointer 에 맞춰서 company_id, pointer를 가지고 있는 Index가 생성된다.

RDBMS 에서는 B+Tree 구조 : 정렬된 데이터를 이분탐색 형태로 조회하기 때문에 O(log N)의 시간복잡도를 통해서 조회할 수 있다.

복합인덱스는 무엇인가요?

저 사진은 company_id가 18인 레코드를 찾아주세요 였다면 만약 SELECT * FROM TABLE WHERE company_id = 18 AND units = 18 이라면 어떨까?

CREATE INDEX(company_id, units) 를 통해서 복합인덱스를 생성해준다.

이렇게 생성이 되고 company_id 를 우선적으로 정렬 그리고 18이 같은 경우 units를 정렬하여 생성이 된다. 그렇게 company_id 와 units를 빠르게 찾아서 값을 반환할 수 있다.

정리하자면

"복합 인덱스는 여러 컬럼을 하나의 인덱스로 묶어서 생성하는 것으로, 지정한 컬럼 순서대로 정렬된 B+Tree 구조를 만듭니다. 첫 번째 컬럼을 기준으로 먼저 정렬하고, 같은 값 내에서 두 번째 컬럼으로 정렬하는 방식입니다.

예를 들어 WHERE 절에서 여러 컬럼을 함께 조회하는 패턴이 많을 때 유용하며, 특히 인덱스 구성 순서가 쿼리 조건의 순서와 일치할 때 최대 효율을 발휘합니다.

다만 복합 인덱스는 최좌측 컬럼부터 순차적으로 사용되기 때문에, 컬럼 순서가 매우 중요합니다. 첫 번째 컬럼 조건 없이 두 번째 컬럼만으로 조회하면 인덱스를 활용할 수 없습니다. 따라서 카디널리티가 높고 자주 조회되는 컬럼을 앞쪽에 배치하는 것이 일반적입니다."

카디널리티란 무엇이고 인덱스와 어떻게 관련이 있나요?

"카디널리티는 특정 컬럼에서 중복을 제외한 고유한 값의 개수를 의미합니다. 카디널리티가 높다는 것은 고유한 값이 많아 중복이 적다는 뜻이고, 카디널리티가 낮다는 것은 같은 값이 반복되어 중복이 많다는 의미입니다.

인덱스는 데이터를 빠르게 필터링하기 위한 목적으로 사용되는데, 카디널리티가 높을수록 인덱스를 통해 걸러지는 데이터 범위가 좁아져서 효율이 높아집니다. 반대로 카디널리티가 낮으면 하나의 인덱스 값이 많은 레코드를 가리키게 되어, 결국 많은 데이터를 스캔해야 하므로 인덱스 효과가 떨어집니다.

다만 카디널리티가 낮더라도 데이터 분포가 편향되어 있거나 특정 값만 자주 조회된다면, 부분 인덱스나 필터링된 인덱스로 효율을 높일 수 있습니다."

클러스터 인덱스와 논클러스터 인덱스의 차이는 뭔가요?

"Clustered Index는 테이블 데이터 자체가 인덱스 키 순서대로 물리적으로 정렬되어 저장되는 방식입니다. InnoDB에서는 Primary Key를 Clustered Index로 사용하며, PK가 없으면 Unique Key를, 그것도 없으면 내부적으로 생성한 Row ID를 사용합니다. 테이블당 하나만 존재할 수 있고, Leaf Node에 실제 데이터 전체가 저장되어 있어서 한 번의 접근으로 데이터를 가져올 수 있습니다.

Non-Clustered Index는 실제 데이터와 별도로 존재하는 인덱스로, Secondary Index라고도 부릅니다. 책의 색인처럼 인덱스 컬럼 값과 함께 해당 데이터의 Primary Key 값을 저장합니다. InnoDB의 경우 Non-Clustered Index로 조회하면 먼저 Secondary Index에서 PK를 찾고, 그 PK로 다시 Clustered Index에 접근해서 실제 데이터를 가져오는 2단계 과정을 거칩니다. 테이블당 여러 개 생성할 수 있습니다."

결론: Index 설계 원칙

데이터베이스 성능 최적화에서 Index는 핵심적인 역할을 합니다. 효과적인 Index 설계를 위해서는 다음 원칙들을 고려해야 합니다.

1. 쿼리 패턴 분석이 우선

Index는 조회 성능을 위한 것이므로, 실제로 자주 실행되는 쿼리의 WHERE, JOIN, ORDER BY 절을 분석하여 필요한 컬럼을 파악해야 합니다.

2. 카디널리티를 고려한 선택

고유값이 많은 컬럼(높은 카디널리티)에 Index를 생성해야 필터링 효과가 좋습니다. 성별이나 Boolean 같이 값의 종류가 적은 컬럼은 Index 효과가 미미합니다.

3. 복합인덱스는 순서가 중요

복합인덱스는 최좌측 컬럼부터 순차적으로 사용됩니다. 따라서:

• 카디널리티가 높은 컬럼을 앞에 배치
• 등호(=) 조건을 범위 조건보다 앞에 배치
• 가장 자주 조회되는 컬럼을 앞에 배치

4. Trade-off를 이해하고 균형잡기

Index는 조회 성능을 향상시키지만:

• 추가 저장 공간 필요
• 쓰기 성능(INSERT, UPDATE, DELETE) 저하
• Index가 많을수록 옵티마이저의 선택지가 많아져 오히려 잘못된 Index 선택 가능

따라서 꼭 필요한 Index만 생성하고, 사용되지 않는 Index는 주기적으로 제거해야 합니다.

5. MySQL InnoDB의 특성 활용

• PK는 Clustered Index로 동작하므로 PK 크기를 작게 유지 (BIGINT 권장)
• Secondary Index는 PK를 참조하므로 PK가 작을수록 모든 Index 크기 감소
• Covering Index를 활용하면 테이블 접근 없이 Index만으로 조회 가능

6. 실행 계획으로 검증

EXPLAIN SELECT * FROM table WHERE column = value;

EXPLAIN으로 실제 Index가 잘 동작하는지 확인하고, type이 const, ref, range인지 체크해야 합니다. ALL(Full Table Scan)이 나오면 Index가 제대로 동작하지 않는 것입니다.

대학생활 내내 탁구만 친 바보가 싸피를 다니면서 겪은 일

2024년 12월 31일

싸피가 떨어지고 내년 계획을 우울하게 짜고 있을 당시.. 12월 31일날 전화가 한통 왔다. 싸피 13기에 추가합격되었다는 소식이었고, 너무 기뻐서 기억이 생생하다.

삼성청년SW아카데미 13기 자바 웹개발자 전공반으로 입과했다!

2025년 1월

같이 합격한 과동기 형의 추천으로 블로그를 시작하게 되었다. 이전 내용들을 보는데 무슨 생각이었는지.. ㅋㅋㅋㅋㅋ ( 최신 글만 봐주길 바랍니다.. )

추억이 솔솔나는 강사님이 알려주신 자바 메모리 특징과 다형성에 대한 시 ( 강사님 사랑합니다 ) 이걸 면접에 썼어야 했는데..!

자생부생 : 자식이 생성되면 부모도 생성된다 자설부설 : 자식의 설계도가 올라가면 부모의 설계도가 올라간다 생주부주 : 생성된 주소는 부모의 주소다 설공메사 : 설계도에 공개된 메서드만 사용할 수 있다

2025년 2월

정말 다행히 졸업할 수 있게 되었고 ㅎㅎ, 분에 안맞게도 너무 많이 축하를 받았다.

2025년 3월

정말 많이 부족한 상태로 싸피에 입과했기 때문에 정말 열심히 했다.

6시 기상 -> 6시 34분 출발 -> 8시에 역삼역 도착 -> 1시간 경제신문 -> 수업 -> 퇴근 -> 8시 집 도착 -> 저녁,샤워 -> 오늘 배운거 블로그 작성 -> 12시 취침

무한 반복...

2025년 4월

공부만 겁나게..! 취업 전쟁통 속에도 함께하는 17반 사람들 덕분에 정말 재밌게 취준할 수 있었다.

강사님 수업과 함께 공부했던 형, 누나, 친구, 동생들하고 함께 그린 Spring 아키텍처 내가 진짜 몰라서 엄청 물어봤는데 다들 너무 친절하게 알려준 기억이 생각난다.. ( 17반에게 무한한 감사 )

SQL-D 획득!

2025년 5월

첫 웹 개발 관통 프로젝트..! 지금까지 배운 내용을 바탕으로 SSAFY 1학기를 마무리 하는 프로젝트이다.

정말 재밌게 했던 것 같다. 이것도 다 평가가 들어가고 서로 경쟁이 있음에도 불구하고 다른 팀끼리도 서로 도와주는 모습 그게 제일 좋았다.

2025년 6월

싸피 1학기가 끝나면서 방학이 시작되었고, 나는 절망적인 시기를 살짝 보낸다..

KB데이타시스템을 운좋게 최종면접까지 갔는데 떨어졌다.. 지금에서야 말하자면, 난 최종면접을 잘 봤다고 생각해서 근처 집 알아보고 있었다.. ㅋㅋㅋㅋㅋ큐ㅠㅠㅠ

이 힘든 시기를 프로젝트를 통해서 극복할 수 있었다.. 우리의 최종 목표는 오직 도파민 (도박), BLC 팀원들 덕분에 버틸 수 있었습니다 진짜 ㅠㅠ ( 무한한 감사 )

2025년 7월

싸피 2학기가 시작되면서 다시 마음을 단단히 먹었다. 3번의 프로젝트를 통해서 진짜 엄청 성장하고 싶었다.

그렇게 시작된 첫 공통 프로젝트 AI 면접관을 만들었고, 기존 17반이 아닌 새로운 팀원들을 만나 전공, 비전공 분들과 섞여서 프로젝트를 진행했다.

좋은 사람들을 만나서 프로젝트를 해서 너무 재밌었고, 특이점으로는 마이크로소프트 인턴을 하신 분도 계셨다.. ( 싸피는 왜..? )

2025년 8월

8월에 공통을 마무리하면서 해커톤을 한번도 나가지 못했었는데 처음으로 해커톤을 나갔다. 신한은행과 SSAFY가 함께 진행하는 해커톤이어서 경쟁률도 엄청 빡셌는데 우수상을 탈 수 있었다..!

신한은행 연수원에서 진행해서 밥도 미쳤고 거의 식폭행을 당했다.. 그 좋은 곳에서 진짜 좋은 사람들끼리 밤샘 코딩을 하는데 너무 행복했다

2025년 9월

해커톤을 같이한 팀원들이 뭉쳐 프로젝트를 이어서 하자고 했고, 다들 너무 뛰어난 사람들이라 MSA와 SAGA패턴을 공부할 기회를 얻게 되었다..!

우리 화면과 SAGA 패턴을 공부하면서 같이 그린 그림이다.

정보처리기사 GET!

2025년 10월

지금은 한예결을 간 엘리트 친구와 함께 자기소개서를 공장처럼 찍어내기 시작했다. 서로 지칠때? 마다 격려해주면서 잘 달려나갔던 것 같다.

상반기까지 합쳐서 총 54개의 서류를 썼다.

14개의 서류 합격을 했고 3개는 코딩테스트 탈락 2개는 NCS, 논술 탈락 6개는 면접에서 탈락했다

많이 배울 수 있었다..

2025년 11월

최종 자율 프로젝트 코레이지 아케이드를 진행했다. 여기서는 부팀장이었는데 팀장분이 취직을 하셔서^^ 중간에 팀장을 맡게되고 발표까지 진행했다.

진짜 지금까지 배운 기술 총동원 + 쿠버네티스까지 주니어가 할 수 있는 한계까지 몰아붙였던 프로젝트였고..

결국.. 3등 우수상을 탔다!

2025년 12월

미래에셋생명에 지원해서 최종면접에서 탈락했다.. 정말 힘들지만 1년동안 열심히 했으니 쉬는 시간이 생겼다고 생각하고 지낼려고 한다..ㅠㅠㅠ

그리고 2026년

2025년 1년이 어떻게 지나가는 지 모를만큼 바쁘게 열심히 살았다..

2025년에 가장 많이 성장한 사람을 고르라고 한다면 나는 주저없이 나를 선택할 것 같다.

그리고 기술이 아닌 사람으로써도 많이 성장한 것 같다. 주변 좋은 사람들의 영향을 많이 받고 고마움을 항상 나누고 싶은 마음이 커졌다.

1년간 사실 기존에 알던 사람들의 연락을 다 끊고 학습에만 몰입했지만, 많은 시간이 생긴 만큼 주변 사람들에게 연락을 돌리면서 고마움을 어떻게든 전하고 싶다.

12.11 경제신문 스크랩 수치화 인사이트

뉴스 링크

통화정책방향

□ 금융통화위원회는 다음 통화정책방향 결정시까지 한국은행 기준금리를 현재의 2.50% 수준에서 유지하여 통화정책을 운용하기로 하였다. 물가상승률이 다소 높아진 가운데 성장은 전망의 불확실성이 여전하지만 소비와 수출을 중심으로 개선세를 이어가고 있고 금융안정 측면의 리스크도 지속되고 있는 만큼 현재의 기준금리 수준을 유지하면서 대내외 정책 여건을 점검해 나가는 것이 적절하다고 판단하였다.

□ 세계경제를 보면, 미국 관세정책의 영향으로 성장세가 둔화되겠지만 미‧중 무역갈등 완화, 주요국의 확장적 재정정책 등으로 그 속도는 완만할 전망이며, 물가경로는 국가별로 차별화될 것으로 보인다. 국제금융시장에서는 미 연준의 금리인하에 대한 기대변화, 주요국 재정상황 등에 영향받아 장기 국채금리와 미 달러화 지수가 상승하였다가 일부 되돌려졌다. 주가는 상승세를 이어가다가 AI 부문 고평가 우려 등으로 조정되었다. 앞으로 세계경제와 국제금융시장은 주요국의 통화·재정정책 변화, 글로벌 통상환경 등에 영향받을 것으로 보인다.

□ 국내경제는 건설투자 부진에도 소비 회복세와 수출 증가세가 이어지면서 개선세를 지속하였다. 고용은 전체 취업자수가 증가세를 유지하였으나 제조업 등 주요 업종에서는 감소세를 이어갔다. 앞으로 내수가 소비를 중심으로 회복세를 지속하는 가운데 수출은 증가율이 다소 둔화되겠지만 반도체 경기 호조, 한‧미 관세협상 타결 등으로 예상보다 양호한 흐름을 이어갈 전망이다. 이에 따라 금년 및 내년 성장률은 각각 지난 8월 전망치(각각 0.9%, 1.6%)를 상회하는 1.0% 및 1.8%를 나타낼 것으로 예상된다. 다만, 이러한 성장경로에는 글로벌 통상환경, 반도체 경기, 내수 회복 속도 등과 관련한 불확실성이 높은 것으로 판단된다.

□ 국내 물가는 여행 관련 서비스 및 농축수산물 가격 상승, 환율 상승에 따른 석유류가격 오름세 확대 등으로 10월 중 소비자물가 및 근원물가(식료품 및 에너지 제외 지수) 상승률이 2.4% 및 2.2%로 높아졌다. 단기 기대인플레이션율(일반인)은 11월 중 전월과 같은 수준(2.6%)을 유지하였다. 앞으로 물가상승률은 국제유가 안정세 등으로 점차 2% 수준으로 낮아지겠으나 높아진 환율, 내수 회복세 등의 영향으로 지난 전망 경로보다 다소 높은 수준에서 움직일 것으로 예상된다. 이에 따라 금년 소비자물가는 8월 전망치(2.0%)를 상회하는 2.1%, 근원물가는 지난 전망에 부합하는 1.9% 상승할 것으로 예상되며, 내년에도 소비자물가 및 근원물가 상승률이 지난 전망치(각각 1.9%)를 상회하는 2.1% 및 2.0%로 전망된다. 향후 물가경로는 국내외 경기 흐름, 환율 및 국제유가 움직임, 정부의 물가안정 대책 등에 영향받을 것으로 보인다.

□ 금융·외환시장에서는 주요 가격변수의 변동성이 확대되었다. 원/달러 환율은 거주자의 해외증권투자 확대 및 외국인 주식 순매도 등으로 1,400원대 중후반으로 높아졌고, 국고채금리는 국내 통화정책에 대한 기대 변화 등으로 상승하였다. 주가는 반도체 경기 호조 등으로 상승세를 이어가다 조정되었다. 가계대출은 기타대출을 중심으로 증가폭이 확대되었고, 수도권 주택시장에서는 가격 상승폭과 거래량이 둔화되었으나 가격 상승 기대는 여전히 높은 상황이다.

□ 금융통화위원회는 앞으로 성장세를 점검하면서 중기적 시계에서 물가상승률이 목표수준에서 안정될 수 있도록 하는 한편 금융안정에 유의하여 통화정책을 운용해 나갈 것이다. 국내경제는 성장률 전망이 상향조정되었지만 향후 경로에 상·하방 요인이 모두 잠재해 있고 물가상승률은 예상보다 다소 높아진 상황이다. 금융안정 측면에서는 수도권 주택가격 및 가계부채 리스크, 환율 변동성 확대의 영향 등에 계속 유의할 필요가 있다. 따라서 향후 통화정책은 금리인하 가능성을 열어두되, 이 과정에서 대내외 정책 여건의 변화와 이에 따른 성장 및 물가 흐름, 금융안정 상황 등을 면밀히 점검하면서 기준금리의 추가 인하 여부 및 시기를 결정해 나갈 것이다.

용어 정리

장기 국채금리 : 만기가 보통 10년 이상인 국채(정부가 발행하는 채권)의 수익률을 의미합니다. 쉽게 말해, 투자자가 장기간(예: 10년) 동안 국채를 보유했을 때 기대할 수 있는 연간 이자 수익률을 나타냅니다.

요약

1. 한국은행은 기준금리 2.50%를 유지하며, 소비·수출 중심의 개선세와 금융안정 리스크를 함께 고려해 신중한 기조를 이어가기로 했다.
2. 세계경제는 미·중 갈등 완화·재정 확대 등의 영향으로 둔화 폭이 완만할 전망이며, 금융시장은 정책 기대 변화에 따라 변동성이 확대되었다.
3. 국내경제는 반도체 경기 호조·관세협상 타결 등으로 예상보다 양호한 흐름을 보이며, 성장률 전망은 1.0%·1.8%로 상향 조정되었다.
4. 10월 물가상승률은 2.4%·2.2%로 높았으며, 환율·내수 영향으로 물가가 당초 전망보다 다소 높은 수준에서 움직일 것으로 예상된다.
5. 향후 통화정책은 금리 인하 가능성을 열어두되, 성장·물가·금융안정 지표를 면밀히 점검하며 추가 인하 여부와 시기를 결정할 계획이다.

최근 환율 급등 배경 및 영향 정리

최근 원/달러 환율이 1,400원대 중후반까지 상승한 것은 단순한 시장 변동이 아니라 여러 사건들이 복합적으로 영향을 미친 결과이다. 우선 거주자의 해외증권투자 확대가 지속되면서 국내 자금이 해외로 유출되는 흐름이 강해졌고, 동시에 외국인 투자자의 국내 주식 순매도가 이어지며 원화 약세 압력이 크게 강화되었다. 여기에 더해 글로벌 금융시장은 미국의 금리 정책 기대 변화와 주요국 재정상황 악화 등으로 변동성이 확대되었고, 이러한 환경이 달러화 강세로 이어지며 국내 환율 상승을 더욱 부추겼다.

이 같은 환율 급등은 수입물가 상승과 석유류 가격 부담 확대로 이어져 국내 물가를 다시 끌어올리는 압력이 되었고, 기업의 생산비용 증가 및 소비심리 위축 가능성 등 실물경제 전반에도 부담 요인으로 작용하고 있다. 또한 외환시장 불안은 금융시장의 변동성을 높여 금융안정 리스크를 확대하는 핵심 사건으로 평가되며, 한국은행이 기준금리 유지와 신중한 통화정책을 선택한 중요한 배경이 되고 있다.

참고자료

美연준, 기준금리 0.25%P 인하…내년 인하 전망은 '불투명'(종합)

美 연준, 기준금리 0.25%p 인하... 한은 "미 통화정책 기조 더 신중해질 것"

기본적으로 Stack은 후입선출, Queue는 선입선출이다. 그렇기에 먼저 들어오는 것이 나가도록 하기 위해서는 두번째 스택으로 전부 이동시키고 빼면 된다.

여기서 중요한 점은 stack2가 비었을 때만 stack1에서 stack2로 이동을 하고, 그 이후에는 stack1에 쌓아두면 된다. (나는 처음에 push 요청에서 stack2에서 stack1으로 이동했다)

그럼 정답 코드를 확인해보자.

import java.util.ArrayList;
import java.util.Stack;

public class TwoStackQueue {
    Stack<Integer> stack1;
    Stack<Integer> stack2;

    public TwoStackQueue(){
        stack1 = new Stack<>();
        stack2 = new Stack<>();
    }

    public void push(int x){
        // push는 단순하게 stack1에 push 한다.
        stack1.push(x);
    }

    public int pop(){
        // stack2 가 비었을 때 stack1에 있는 값을 모두 넣는다.
        if(stack2.isEmpty()){
            while(!stack1.isEmpty()){
                stack2.push(stack1.pop());
            }
        }
        // 넣었는데도 비어있다면 pop 할 수 없다. 
        if(stack2.isEmpty()){
            System.out.println("스택이 비어있습니다!");
            return -1;
        }
        // 역순으로 들어간 stack2 에서 pop을 하니 첫번째 값이 나간다. 
        return stack2.pop();
    }
}

이렇게 잘 나오는 것을 확인할 수 있다.

여기서 중요한 것은 이제 이 코드가 O(1)로 작동한다는 점이다. 정확히 말하면 Amortized O(1)이다.

Amortized(분할 상환) 시간 복잡도를 조금 풀어서 얘기하자면, 최악의 경우가 가끔 발생해도, 평균적으로는 효율적이라는 뜻이다.

push 는 stack1에 push만 하는 것이니 정말 O(1)이고, pop이 만약에 stack2가 비어있을 때 O(N)의 순회를 통해서 값을 전달해야 하는데 이때만 오버헤드가 존재하고 평균적으로는 n개의 요소를 처리하면 총 2n번의 작업이므로 각 연산은 O(1) 이라고 할 수 있는 것이다.

이런 경우를 다른 곳에서도 볼 수 있는데 대표적인 예시로 ArrayList 동적 배열이 존재한다.

만약에 ArrayList에 계속해서 값을 추가한다고 하면, 평소에는 O(1)만큼이 들것이다. 하지만 배열이 꽉 차게 된다면 크기를 2배로 늘리고 복사하는 작업이 들어가게된다. 이 때는 O(N)만큼 시간이 동작하게 되겠지만 평균적으로는 O(1) 즉 Amortized O(1)의 시간복잡도를 가지게 되는 것이다.

필수 학습 목표

• HTTP 요청/응답 구조 (Method, Header, Body) 이해
• HTTP 상태 코드: 2xx, 3xx, 4xx, 5xx 이해
• HTTPS: SSL/TLS를 통한 보안 연결 이해
• HTTP/2, HTTP/3 차이점 및 효율성

선택적 학습 목표

• 웹 보안: SSL/TLS 핸드셰이크, 인증서 관리
• HSTS (HTTP Strict Transport Security)

HTTP 요청

Request Line + Headers + Body

Request Line (요청 라인)

GET /api/users HTTP/1.1

요청이 어디로 어떤 방식으로 갈 지를 정해준다.

HTTP Methods (GET, POST, DELETE, FETCH, PUT) 중 GET 요청을 할 것이다. /api/users 로 가세요. HTTP/1.1 버전의 프로토콜로 가겠습니다.

Headers (헤더)

Host: example.com // 요청을 보낼 서버의 도메인 이름 (or IP 주소)
Content-Type: application/json // json 형식으로 보내겠음
Authorization: Bearer token123 // JWT 토큰 인증 방식이라면 여기에 token을 담는다. 
User-Agent: Mozilla/5.0 // 클라이언트의 정보, 브라우저 호환성 체크 용도로 사용
Accept: application/json // 받고 싶은 형식, json으로 응답해주삼~~

Body (본문)

선택적으로 Body를 넣어서 보낼 수 있다. 실제 요청 데이터!

{
  "id": 1,
  "username": "john",
  "email": "john@example.com"
}

HTTP 응답

Status Line + Headers + Body

Status Line (상태 라인)

HTTP/1.1 200 OK

Headers (헤더)

Content-Type: application/json
Content-Length: 348
Set-Cookie: sessionId=abc123
Cache-Control: no-cache

Body (본문)

{
  "id": 1,
  "username": "john",
  "email": "john@example.com"
}

주요 상태 코드

2xx (성공): 200 OK, 201 Created, 204 No Content 3xx (리다이렉션): 301 Moved Permanently, 302 Found 4xx (클라이언트 오류): 400 Bad Request, 401 Unauthorized, 404 Not Found 5xx (서버 오류): 500 Internal Server Error, 503 Service Unavailable

HTTPS : SSL/TLS를 통한 보안 연결

HTTP + Secure = HTTPS

HTTPS 란 HTTP 에 SSL/TLS 암호화 계층을 추가한 프로토콜이다. 기본 포트는 443을 사용한다.

SSL : Secure Socket Layer 으로 초기 보안 프로토콜이다. TLS : Transport Layer Security 로 SSL의 후속버전이고 현재 표준이다.

TLS Handshake

HTTPS가 통신할때도 악수 과정을 거친다.

Client Hello : 클라이언트가 서버에 연결 시도, 지원하는 TLS 버전, 암호화 방식 목록 전송 Server Hello : 서버가 사용할 TLS 버전과 암호화 방식 선택 서버의 SSL 인증서 전송 인증서 검증 : 클라이언트가 인증서의 유효성 확인, CA를 통해 신뢰할 수 있는 인증서인지 검증 세션 키 생성 : 클라이언트가 대칭키(세션 키)를 생성 암호화 통신 시작 : 이후 모든 데이터는 세션 키로 암호화되어 전송된다.

이런 방식을 통해 진행하여

암호화, 무결성, 인증이 보장된 통신이 가능해진다!

HTTP/2

HTTP/1.1 의 한계를 극복

HTTP/1.1 에서는 한 번에 하나의 요청만 처리할 수 있어서 여러 리소스를 받으려면 여러 TCP 연결을 맺어야 했다. 이를 HOL(Head Of Line) Blocking 문제라고 한다.

이 문제를 해결하기 위해 멀티플렉싱, 헤더 압축, 서버 푸시, 바이너리 프레임을 통해 업그레이드 한 것이 HTTP/2 이다.

멀티플렉싱: 하나의 TCP 연결에서 여러 요청과 응답을 동시에 처리할 수 있다. 스트림 단위로 데이터를 나눠서 보내기 때문에 하나의 요청이 느려도 다른 요청에 영향을 주지 않는다.

헤더 압축: HTTP/1.1에서는 매 요청마다 비슷한 헤더를 반복해서 보냈지만, HTTP/2는 HPACK 압호화를 사용해서 중복되는 헤더를 압축하고, 이전에 보낸 헤더 정보를 재사용 한다.

서버 푸시: 클라이언트가 요청하지 않아도 서버가 필요할 것 같은 리소스를 미리 보낼 수 있다. HTML을 요청하면 서버가 필요한 CSS, JS 파일을 함께 푸시하는 방식이다.

바이너리 프레임: HTTP/1.1은 텍스트 기반 프로토콜이었지만, HTTP/2는 바이너리 형식으로 데이터를 전송한다. 파싱 속도가 빠르고 오류가 적다.

HTTP/3

근본 프로토콜의 변화

하지만 여전히 TCP 기반이라 TCP 자체의 HOL Blocking 문제가 남아있다. 하나의 패킷이 손실되면 그 뒤의 모든 패킷이 대기해야 하는 구조인 것이다.

그래서 UDP 기반의 QUIC(Quick UDP Internet Connections) 프로토콜을 사용한다. UDP에 신뢰성과 보안 기능을 추가한 프로토콜이다.

독립적인 스트림: 각 스트림이 독립적으로 동작해서 한 스트림에서 패킷 손실이 발생해도 다른 스트림에는 영향을 주지 않는다. TCP 레벨의 HOL Blocking이 완전히 해결된다.

빠른 연결: TCP는 3-way handshake로 연결을 맺고, 그 위에 TLS handshake를 또 해야한다. 하지만 QUIC는 연결과 암호화를 하나의 핸드셰이크로 처리해서 지연 시간이 크게 줄어든다.

연결 마이그레이션: 모바일 환경에서 WIFI에서 LTE로 전환되면 IP가 바뀌면서 TCP 연결이 끊어진다. 하지만 QUIC는 Connection ID로 연결을 식별해서 네트워크가 바뀌어도 연결이 유지된다.

SSL/TLS 핸드셰이크와 인증서

웹 사이트 신원 증명

TLS는 Transport Layer Security의 약자로, 네트워크 통신을 암호화하는 프로토콜이다. 과거에는 SSL(Secure Sockets Layer)가 사용되었지만, 보안 취약점으로 인해 완전히 폐기되었고 현재는 TLS 1.2, 1.3만 사용된다.

TLS 가 핸드셰이크 할 때 클라이언트가 먼저 Client Hello를 통해 먼저 TLS 버전과 암호화 방식 목록을 전송한다. 난수값도 함께 보내는데, 나중에 세션 키를 생성할 때 사용한다.

그 후 서버가 Server Hello를 통해 클라이언트가 제시한 목록 중에서 사용할 TLS 버전과 암호화 방식을 선택한다. 그리고 서버의 TLS 인증서를 클라이언트에게 전송한다.

클라이언트는 받은 TLS 인증서의 유효성을 확인한다. 인증서가 신뢰할 수 있는 CA(Certificate Authority)에서 발급되었는지, 도메인이 일치하는 지, 유효 기간이 지나지 않았는지 검증한다.

검증이 되었다면, 대칭키(세션 키)를 생성한다. 이 키를 공개키로 암호화해서 서버에 전송한다. 서버는 자신의 개인키로 복호화해서 세션 키를 얻는다. 이제 클라이언트와 서버 둘 다 같은 세션 키를 얻게된다.

이후 모든 데이터는 세션 키로 암호화되어 전송된다. 대칭키 암호화는 공개키 암호화 보다 훨씬 빨라서 성능도 훨씬 좋다.

그렇게 이 handshake를 거친 후에 하는 통신은 모두 암호화, 무결성, 인증을 보장하는 통신이 된다.

캠퍼스 페이 프로젝트에서는 Let's Encrypt 인증서를 통해서 발급을 받았고, certbot 도구를 사용해서 인증서를 갱신하였다.

Corazy Arcade 에서는 Kubernetes 환경이라서 cert-manager를 통해 인증서 라이프사이클을 관리하였다. Ingress 리소스에 어노테이션을 추가하여 cert-manager가 자동으로 Let's Encrypt에서 인증서를 발급받고, 만료 전에 갱신한다. Secret으로 저장되어 Pod에 자동으로 마운트 된다.

HSTS (HTTP Strict Transport Security)

HTTP 절대 금지

나는 이전에 HTTP 요청에 들어오면 Nginx에서 HTTPS로 리다이렉트해서 보안에 신경쓴 줄 알았는데, 이는 중간자 공격에 취약한 구조였다.

HSTS를 설정하면 브라우저가 자동으로 HTTPS로 변환해서 요청을 하기 때문에 이런 공격을 방지할 수 있다.

HSTS Preload List에 등록하면 사용자가 처음 방문할 때부터 HTTPS를 사용한다. 주요 브라우저들이 공유하는 리스트이고, hstspreload.org에서 등록할 수 있다.

하지만 만약 인증서 문제가 발생하면 사용자가 사이트에 완전히 접근할 수 없게 되므로 인증서 관리가 굉장히 중요해진다.

주의: 이 글은 MySQL InnoDB 스토리지 엔진 기준으로 작성되었습니다. SQL Server, PostgreSQL 등 다른 DBMS는 인덱스 구조가 다를 수 있습니다.

Cluster Index란 무엇인가?

Cluster Index는 테이블의 실제 레코드가 인덱스 순서대로 저장되는 구조를 말한다. 쉽게 말해, 클러스터 인덱스는 "책의 본문 페이지가 목차의 순서대로 정렬되어 있는 형태"와 비슷하다.

대표 특징

• 테이블 자체가 인덱스 구조(B+Tree)로 저장됨
• 오직 하나만 생성 가능 (MySQL InnoDB 기준)
• 기본적으로 PK(Primary Key)가 클러스터 인덱스로 지정됨
• 데이터를 PK 순으로 정렬하여 저장하기 때문에 범위 조회에 매우 빠름

PK가 없다면?

InnoDB는 다음 우선순위로 클러스터 인덱스를 결정한다:

1. PRIMARY KEY가 있으면 → PK를 클러스터 인덱스로 사용
2. PK가 없고 NOT NULL UNIQUE 인덱스가 있으면 → 첫 번째 UNIQUE 인덱스 사용
3. 둘 다 없으면 → 내부적으로 숨겨진 6바이트 row ID를 자동 생성

따라서 명시적으로 PK를 정의하는 것이 성능과 관리 측면에서 유리하다.

장점

• PK 기반 조회가 매우 빠르다 (예: BETWEEN, RANGE SCAN)
• 데이터 페이지가 정렬되어 있어 순차 접근 비용이 낮음
• 범위 검색 시 연속된 데이터 블록을 읽을 수 있어 I/O 효율이 높음

단점

• INSERT 시 정렬을 유지해야 하므로 페이지 분할(Page Split) 발생 가능
  • 새 레코드가 중간에 삽입되면 기존 페이지를 나누고 재배치해야 함
  • UUID 같은 랜덤 값을 PK로 사용하면 페이지 분할이 빈번하게 발생
  • AUTO_INCREMENT 같은 순차적 값을 권장하는 이유
• PK 변경이 자주 발생하면 성능 저하
• PK 크기가 커지면 전체 인덱스 크기 증가 → 튜닝 시 PK는 가급적 짧고 변경되지 않는 값 사용

Non-Cluster Index란 무엇인가?

Non-Cluster Index는 인덱스와 실제 데이터가 분리된 구조다. 책 뒤의 색인(index)처럼, 인덱스는 따로 저장되고 그 인덱스가 가리키는 주소로 실제 데이터에 접근하는 방식이다.

대표 특징

• 데이터 파일과 인덱스 파일이 분리되어 있음
• 여러 개 생성 가능
• InnoDB의 특징: 보조 인덱스(Secondary Index)에는 PK 값이 포함되어 있음
  • 다른 스토리지 엔진(예: MyISAM)은 실제 레코드의 물리적 주소를 저장
• 실제 데이터 접근은 (보조 인덱스 → PK 조회 → 실제 데이터) 순서로 진행됨
• 이 과정을 "테이블 랜덤 액세스" 또는 "테이블 룩업(Table Lookup)"이라고 부른다

장점

• PK가 아닌 컬럼으로도 빠르게 검색 가능
• 다양한 조회 조건을 최적화할 수 있음
• 여러 개 만들 수 있어 범용적

단점

• 클러스터 인덱스보다 한 단계 더 거침 (추가 I/O 발생)
• 선택도가 낮은 컬럼에 인덱스를 만들면 오히려 느려짐
• 너무 많은 인덱스를 만들면 INSERT/UPDATE/DELETE 비용 증가

두 인덱스 구조 비교

중요한 점

1. PK는 클러스터 인덱스로서 매우 중요한 역할을 한다

PK가 너무 길면 → 모든 보조 인덱스에 PK가 포함되므로 전체 인덱스 크기가 커진다. 짧고 고유하며, 변경되지 않는 PK를 선호하는 이유다.

-- 나쁜 예: VARCHAR(100)을 PK로 사용
CREATE TABLE users (
    email VARCHAR(100) PRIMARY KEY,  -- 모든 인덱스에 100바이트 추가
    name VARCHAR(50)
);

-- 좋은 예: AUTO_INCREMENT를 PK로 사용
CREATE TABLE users (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,  -- 8바이트만 추가
    email VARCHAR(100) UNIQUE,
    name VARCHAR(50)
);

2. 보조 인덱스는 선택도가 높은 컬럼에 걸자

선택도(Selectivity): 전체 행 대비 고유 값의 비율

• 선택도가 높다 = 고유한 값이 많다 = 인덱스 효과가 좋다
• 선택도가 낮다 = 중복된 값이 많다 = 인덱스 효과가 떨어진다

-- 나쁜 예: 선택도가 낮은 컬럼
CREATE INDEX idx_gender ON users(gender);  -- 'M', 'F' 2개 값만 존재

-- 좋은 예: 선택도가 높은 컬럼
CREATE INDEX idx_email ON users(email);  -- 거의 모든 값이 고유함

3. 커버링 인덱스로 테이블 랜덤 액세스를 최소화하자

커버링 인덱스는 쿼리에 필요한 모든 컬럼을 인덱스에 포함시켜, 테이블에 직접 접근하지 않고 인덱스만으로 결과를 반환하는 기법이다.

-- 인덱스 생성
CREATE INDEX idx_user_name_age ON users(name, age);

-- 커버링 인덱스 활용 (Using Index)
SELECT name, age FROM users WHERE name = 'Kim';
-- → 인덱스만 읽고 테이블 접근 없음

-- 커버링되지 않는 경우
SELECT name, age, address FROM users WHERE name = 'Kim';
-- → address는 인덱스에 없으므로 테이블 랜덤 액세스 발생

실행 계획에서 "Using Index"가 표시되면 커버링 인덱스가 적용된 것이다.

4. WHERE, JOIN, ORDER BY 조건이 자주 쓰인다면 인덱스 생성 고려

특히 JOIN에 쓰이는 FK 컬럼은 반드시 인덱스가 필요하다.

-- orders 테이블의 user_id에 인덱스가 없으면 JOIN 성능 저하
SELECT u.name, o.order_date
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE u.status = 'active';

-- FK 컬럼에 인덱스 생성
CREATE INDEX idx_orders_user_id ON orders(user_id);

결론

Cluster Index와 Non-Cluster Index는 단순한 인덱스의 종류가 아니라, 테이블의 저장 방식과 성능 전체에 큰 영향을 주는 핵심 구조다.

• 빠른 범위 조회가 필요하다면 → Cluster Index(PK) 활용
• 다양한 조회 조건 최적화 → Non-Cluster Index 활용
• PK를 신중하게 선택해야 전체 성능이 좋아짐

인덱스 설계는 결국 트레이드오프다. 조회 성능을 높이면 쓰기 성능이 떨어지고, 인덱스를 많이 만들면 저장 공간과 유지보수 비용이 증가한다. 실제 서비스의 쿼리 패턴을 분석하고, 실행 계획을 확인하며 최적의 지점을 찾아가는 것이 데이터베이스 튜닝의 핵심이다.

11.23 경제신문 스크랩 수치화 인사이트

뉴스 링크

최재원 기자김형주 기자 2025.11.20. 오후 7:51

한투證 순이익 농협銀 추월 증권사 자산관리 역량 확대 증시활황에 '머니무브' 가속 은행은 여전히 예대마진 장사 "IMA 계기로 대형 증권사가 금융시장 판도 뒤흔들 것"

증권사들의 수익이 빠르게 증가한 것은 자산 관리 역량에서 증권사가 은행을 크게 앞선 가운데 최근 증시 활성화로 인한 '머니무브'로 증권사에 뭉칫돈이 몰리고 있기 때문으로 풀이된다. 실제 지난해 실시된 퇴직연금 실물이전과 증권사의 투자 상품 경쟁력이 맞물리면서 퇴직연금 시장에서 적립금 순위가 뒤바뀌는 현상도 나타나고 있다. 특히 초대형 투자은행(IB)을 육성하기 위해 도입된 종합투자계좌(IMA)는 앞으로 은행업에서 증권업으로의 자금 이동을 가속화하는 촉매제가 될 것으로 전망된다.

금융위원회와 한국은행, 금융투자협회 등에 따르면 지난 10월 은행권 수신은 전월 대비 22조9000억원 감소한 반면, 자산운용사 수신은 50조6000억원 증가했다. 증권사 투자자예탁금도 9조원 증가했다.

증권사로 자금이 몰리는 것은 AI·배당 확대·정책적 요인 등으로 투자 열기가 고조되었기 때문이라는 분석이 나온다. 안동현 서울대 교수는 정책이 증시를 지속적으로 부양할 것이라는 기대가 자본시장 자금 유입을 강화하고 있다고 설명했다. 키움증권은 올해 3분기 주식 수수료 수익이 1852억원으로 전년 대비 45.6% 증가했다.

증권사들의 자산 관리 역량도 머니무브의 중요한 원인으로 꼽힌다. 증권사는 다양한 상품 라인업과 높은 수익률로 DC·IRP 고객에서 경쟁우위를 확보하고 있다. 3분기 퇴직연금 적립금은 증권업권 +7조1290억원, 은행업권 +5조6884억원 증가했다. IRP 적립금 상위 10개 사업자에 한국투자증권(6월)과 NH투자증권(9월)이 신규 진입했다. 베이비부머 은퇴 진입으로 향후 은퇴자산 관리 경쟁이 업권 재편을 이끌 전망이다.

지난 19일 금융위가 한국투자증권과 미래에셋증권을 자기자본 8조원 이상의 종투사로 지정하면서 IMA 출시가 가능해졌다.

종투사는 IMA를 통해 고객 자금을 기업대출·회사채·부동산 등에 투자하여 배분할 수 있다. 원금 보장과 최대 8% 수익률 제공이 가능해 보수적 투자자에게 매력적이다.

김세완 자본시장연구원장은 IMA가 은행 중심에서 증권 중심으로 금융시장 구조를 바꾸는 계기가 될 것이라고 전망했다. 초대형 증권사의 원금 보장은 예금보험공사의 1억원 보장만큼 신뢰를 제공해 자금 유입을 끌어올릴 수 있다고 말했다.

반면 은행들은 전체 수익의 약 80%가 이자수익이고 그 절반이 가계대출에서 발생하는 등 예대마진 중심 구조에 머물러 있다. 은행계 증권사는 모그룹의 보수적 문화로 인해 리스크 감수도가 낮아 성장 전략이 제한되는 구조적 한계를 가진다는 분석도 나왔다.

은행이 금융업 주도권을 유지하려면 비은행 부문 강화와 자산 관리 역량 제고가 필수라는 지적이다.

용어 정리

머니무브(Money Move) : 예금 등 안전자산에서 주식·펀드 등 자본시장으로 자금이 이동하는 현상

IRP(개인형 퇴직연금) : 개인이 직접 운용 상품을 선택해 노후자금을 적립·운용하는 퇴직연금 제도

DC형 퇴직연금 : 확정기여형 퇴직연금으로, 사용자가 납입한 금액만 정해지고 수익률에 따라 적립금이 달라지는 방식

종투사(종합금융투자사업자) : 자기자본 8조원 이상으로, 대규모 투자·대출·자금중개 기능을 수행할 수 있는 초대형 IB

IMA(종합투자계좌) : 종투사가 고객 자금을 모아 기업대출·채권·부동산 등에 투자해 수익을 낸 뒤 배분하는 계좌로, 원금보장·고수익 구조가 가능해 자금 이동을 촉진하는 상품

요약

증권사들은 최근 증시 활황과 ‘머니무브’ 현상에 힘입어 빠르게 성장하고 있으며, 특히 AI 투자 열기와 배당 확대 정책이 자본시장으로의 자금 유입을 가속화하고 있다. 퇴직연금 시장에서도 증권사의 다양한 상품 경쟁력이 두드러져 적립금 증가폭이 은행을 앞지르는 등 판도가 변화하고 있다. 금융위가 미래에셋증권과 한국투자증권을 종투사로 지정하면서 종합투자계좌(IMA) 출시가 가능해져, 예금을 대체할 수 있는 고수익·원금보장 상품으로 추가적인 자금 이동이 예상된다. 이러한 변화로 증권사의 기업대출·채권·부동산 투자와 중개 역할도 강화될 전망이다. 반면 은행들은 예대마진 중심 구조에 머물러 경쟁력이 약화되고 있어, 자산 관리 역량 강화와 비은행 부문 확대가 필요하다는 지적이 나온다.

종합투자계좌(IMA)의 특별한 점은 무엇일까?

종합투자계좌(IMA)는 기존 은행 예·적금이나 일반적인 증권 계좌와는 성격이 다르다. 초대형 IB(투자은행) 육성을 위해 설계된 제도인 만큼, 자금을 단순히 ‘보관’하는 데서 그치지 않고 기업·프로젝트·채권 등 다양한 실물투자 분야로 직접 흘려보낼 수 있도록 만든 계좌다.

가장 큰 차별점은 ‘자산 운용의 폭’과 ‘위험·수익 구조’다. 기존 퇴직연금이나 은행 상품은 규제가 많아 보수적인 운용에 머무를 수밖에 없지만, IMA는 초대형 IB의 전문 운용 능력을 활용해 더 공격적이고 복합적인 투자를 할 수 있다. 그 과정에서 고객에게 더 높은 기대수익을 제시할 수 있다는 점이 핵심이다.

또 하나의 특징은 은행 대비 높은 자금 활용도다. 은행은 대출 중심의 비즈니스 구조를 가지고 있어 투자 수단이 제한적이지만, 종합투자계좌는 기업대출, 메자닌, 채권, 부동산, 인프라 등 다양한 구조화 금융에 자금을 투입할 수 있다. 즉, 자금이 생산적인 곳으로 흘러가는 투자 구조를 적극적으로 활용할 수 있는 통로다.

결국 IMA는 수익률을 원하는 고객, 그리고 투자역량을 키우려는 증권사 양쪽 모두에게 매력적인 계좌라는 점에서 머니무브의 핵심 거점 역할을 하고 있다.

종합투자계좌(IMA) 핵심 정리

• 초대형 IB 육성을 위해 도입된 제도
• 기업대출·채권·부동산·프로젝트 등 폭넓은 자산군에 투자 가능
• 은행보다 자금 운용 자율성이 크고 더 공격적인 투자 구조 사용 가능
• 고객 입장에서는 고수익 기대 가능성, 증권사 입장에서는 자금 유입 증가
• 머니무브 흐름을 가속화시키는 핵심 촉매제로 평가됨

ISA와 IMA, 이름은 비슷한데 무엇이 다를까?

ISA(개인종합자산관리계좌)와 IMA(종합투자계좌)는 둘 다 ‘여러 금융상품을 한 계좌에서 관리한다’는 공통점이 있다. 하지만 실제로는 성격부터 목적까지 완전히 다른 계좌다. 투자자 입장에서 어떤 계좌가 어떤 역할을 하는지 구분해두면 금융 뉴스나 상품 구조를 이해하는 데 훨씬 도움이 된다.

먼저 ISA는 개인의 재산 형성을 돕기 위한 세제 혜택 중심의 계좌다. 예금, 펀드, ETF 같은 기초적인 상품을 담고, 이익에 대해 비과세나 절세 효과를 얻는 것이 핵심이다. 구조적으로 비교적 안전하고, 규제가 많아 공격적인 자산운용을 하기는 어렵다. 즉, ISA는 "안정적 절세 + 소액 재테크"라는 성격이 강하다.

반면 IMA는 완전히 다른 방향을 지향한다. 초대형 IB가 운용하는 계좌로, 기업대출·부동산·채권·메자닌 등 은행보다 더 폭넓은 투자 자산군에 직접 접근할 수 있는 투자 플랫폼에 가깝다. 단순히 예금을 담아두는 계좌가 아니라, 전문 운용 조직을 통해 고위험·고수익 구조의 투자까지 가능해진다. 다시 말해, IMA는 "본격적인 투자 수익 추구"에 맞춰진 계좌라고 볼 수 있다.

두 계좌는 목적 자체가 다르다. ISA는 절세 효과를 바탕으로 자산을 조금씩 쌓아가는 데 초점이 맞춰져 있고, IMA는 초대형 IB의 전문 역량을 활용해 더 높은 기대수익을 추구하기 위한 투자 전용 구조다. 이 차이 때문에 ISA는 대중적이지만, IMA는 고액자산가나 전문투자자 중심으로 활용되는 경우가 많다.

참고자료

IMA시대 ‘활짝’…"투자자 보호·리스크 관리 대책 세워야"

원금 지키며 연 8% 수익…IMA 내달초 나온다

아키텍처를 보기 전에 반드시 알아야 할 개념에 대해 정리해보겠다.

핵심 개념

Control Plane (마스터 노드)

kube-apiserver : 모든 요청의 진입접으로 쿠버네티스 API를 노출하는 컴포넌트다. etcd : 분산 key-value 저장소로서 클러스터의 모든 데이터를 저장한다. kube-scheduler : 새로 생성된 Pod를 어느 노드에 배치할 지 결정한다.

등등 지휘자 컴퓨터라고 생각하면 된다.

Worker Node

kubelet : 각 노드에서 실행되는 에이전트로 API 서버와 통신하며 Pod 스펙을 받아 실행한다. kube-proxy : 네트워크 프록시 역할로 로드밸런싱 처리를 담당한다. Container Runtime : 실제 컨테이너를 실행하는 소프트웨어이다. Docker, containerd 등

등등 서비스를 실행시켜주는 나머지 컴퓨터들 라고 생각하면 된다.

추가 핵심 개념

Pod - 가장 작은 배포 단위, 하나 이상의 컨테이너를 포함한다. Service - Pod 집합에 대한 네트워크 접근을 제공한다. Namespace - 클러스터 내 리소스를 논리적으로 분리한다. Ingress - 클러스터 외부에서 내부 서비스로의 HTTP/HTTPS 라우팅을 맡는다. Cluster - 여러개의 마스터 노드, 여러개의 워커 노드로 구성된 하나의 큰 시스템

구성 정보

우리의 전체 아키텍처이다. 최대한 깔끔히 보기 좋게 간단하게 정리해 보았는데 이제 한 부분씩 정리해보고자 한다.

Ingress

Ingress는 클러스터 외부에서 내부 서비스로 들어오는 HTTP/HTTPS 트래픽을 관리하는 첫 진입점이다. nginx Ingress Controller가 워커 노드에서 Pod로 실행되며, hostNetwork 모드를 사용해 워커 노드의 80/443 포트를 직접 사용한다.

cert-manager를 사용해서 Let's Encrypt로부터 SSL 인증서를 자동으로 발급받고 갱신한다. HTTP 요청은 자동으로 HTTPS로 리다이렉트되며, TLS 1.2와 1.3을 지원한다.

라우팅 규칙은 경로 기반으로 설정했다. corazyarcade.kro.kr/ 경로는 react-server로 라우팅되어 프론트엔드를 제공하고, corazyarcade.kro.kr/api 경로는 gateway-server로 라우팅되어 백엔드 API를 처리한다. 이렇게 하나의 도메인에서 경로만으로 프론트엔드와 백엔드를 분리 운영할 수 있다.

쿠키 기반 Session Affinity를 적용해서 같은 사용자의 요청이 동일한 Gateway Pod로 라우팅되도록 했다.

Gateway

Gateway는 모든 클라이언트 요청이 거쳐가는 단일 진입점으로, Spring Cloud Gateway를 사용해 구현했다. Ingress로부터 /api 경로의 모든 요청을 받아서 적절한 마이크로서비스로 라우팅하는 역할을 담당한다.

Gateway의 핵심 역할은 JWT 기반 인증 처리다. AbstractGatewayFilterFactory를 상속받은 JwtAuthenticationFilter를 구현해서 모든 요청에 대해 JWT 토큰을 검증한다. 검증이 완료되면 토큰에서 추출한 사용자 정보를 HTTP 헤더에 담아 각 마이크로서비스로 전달한다. 이렇게 하면 각 마이크로서비스는 별도의 인증 로직 없이 Gateway에서 전달받은 사용자 정보를 신뢰하고 사용할 수 있다.

Gateway는 replica를 2개로 설정했다. 모든 트래픽의 진입점이기 때문에 Gateway에 장애가 발생하면 전체 서비스가 마비된다. 따라서 SPOF(Single Point of Failure)를 방지하기 위해 최소 2개의 Pod를 운영하며, Ingress의 Session Affinity 설정과 함께 안정적인 서비스를 제공한다.

마이크로서비스

마이크로 서비스들을 설계할 때, 중요하게 생각한 부분만 정리하자면 Auth 서버도 SPOF를 방지해야 한다고 생각했다. 그렇게 Replica 2개로 구성을 하였다. (relay-server도 부하가 예상되어 Pod을 두개로 구성하였다.)

Self-healing

Kubernetes의 Self-healing 기능을 활용해서 서비스의 안정성을 확보했다. Deployment의 replicas 설정을 통해 원하는 Pod 수를 정의하면, Kubernetes Controller가 지속적으로 현재 상태를 모니터링하면서 Pod이 죽거나 장애가 발생하면 자동으로 새로운 Pod을 생성해서 복구한다.

추가로 Spring Boot Actuator의 health check 엔드포인트를 활용해서 Liveness Probe와 Readiness Probe를 설정했다. Liveness Probe는 10초마다 /actuator/health를 호출해서 Pod의 정상 작동 여부를 확인하고, 3번 연속 실패하면 해당 Pod을 자동으로 재시작한다. Readiness Probe는 Pod이 트래픽을 받을 준비가 되었는지 확인해서, 준비되지 않은 Pod에는 요청을 보내지 않도록 한다.

예를 들어 relay-server에서 메모리 누수로 인해 응답 불가 상태가 되면, Liveness Probe가 실패를 감지하고 Kubernetes가 자동으로 해당 Pod을 재시작한다. 재시작 중에도 다른 replica Pod이 트래픽을 처리하기 때문에 서비스 중단 없이 복구가 가능하다.

독립적인 스케일링

MSA의 가장 큰 장점 중 하나는 각 서비스를 독립적으로 확장할 수 있다는 점이다. 릴레이 코딩 게임에 사용자가 몰려서 relay-server의 부하가 증가하면, relay-server만 replica를 2개에서 5개로 늘려서 트래픽을 분산시킬 수 있다. 반면 auth-server는 로그인 요청이 상대적으로 적기 때문에 2개로 유지하고, compile-server는 비동기 처리를 하기 때문에 1개로도 충분하다.

만약 모놀리식 아키텍처였다면 특정 기능의 부하가 증가해도 전체 애플리케이션을 통째로 복사해야 하기 때문에 불필요한 리소스가 함께 증가한다. 하지만 MSA는 필요한 서비스만 선택적으로 확장할 수 있어서 리소스를 효율적으로 사용할 수 있다.

추가로 HPA(Horizontal Pod Autoscaler)를 설정하면 CPU 사용률이나 메모리 사용량에 따라 자동으로 Pod 수를 조정할 수 있다. 예를 들어 relay-server의 CPU 사용률이 70%를 초과하면 자동으로 replica를 증가시키고, 부하가 줄어들면 다시 감소시켜서 비용을 최적화할 수 있다.

모니터링

클러스터와 애플리케이션의 상태를 실시간으로 모니터링하기 위해 Prometheus, Grafana, Alertmanager로 구성된 모니터링 스택을 구축했다. 모든 모니터링 컴포넌트는 monitoring 네임스페이스에 배포되어 운영 환경과 분리했다.

Docker-in-Docker

Docker-in-Docker 아키텍처

Compile Worker는 사용자가 제출한 코드를 안전하게 컴파일하고 실행하는 역할을 담당한다. 릴레이 코딩 게임의 특성상 다양한 언어의 코드를 실행해야 하고, 악의적인 코드로부터 시스템을 보호해야 하기 때문에 Docker-in-Docker(DinD) 구조로 설계했다.

사용자 코드가 들어오면 Worker는 Docker 데몬에게 새로운 컨테이너 생성을 요청한다. Python 코드라면 python:3.9 이미지로, Java 코드라면 openjdk:17 이미지로 격리된 컨테이너를 생성해서 실행한다. 컨테이너 내부에서 코드가 실행되고 결과가 수집되면 즉시 컨테이너를 삭제한다. 이렇게 하면 악의적인 코드가 실행되더라도 격리된 컨테이너 안에서만 영향을 주기 때문에 호스트 시스템과 다른 사용자의 실행 환경에는 전혀 영향을 주지 않는다.

메모리 제한을 512Mi로 설정해서 무한 루프나 메모리 폭탄 같은 리소스 공격도 방어할 수 있다. 또한 emptyDir 볼륨을 사용해서 컴파일 작업 공간을 제공하고, Pod가 재시작되면 자동으로 정리된다.

RabbitMQ 비동기 작업 처리

Compile Worker는 Service 없이 독립적인 Pod로 실행된다. 외부에서 직접 호출하지 않고 RabbitMQ 메시지 큐를 통해 작업을 받아서 처리하는 Consumer 역할이기 때문이다.

사용자가 코드를 제출하면 compile-server가 작업 정보를 RabbitMQ 큐에 넣고 즉시 "처리 중" 응답을 반환한다. Compile Worker는 큐를 지속적으로 polling하면서 작업이 있으면 꺼내서 처리한다. 이런 비동기 방식은 여러 장점이 있다.

첫째, 사용자는 컴파일 완료를 기다리지 않고 바로 응답을 받는다. 컴파일에 10초가 걸려도 사용자 경험에 영향을 주지 않는다. 둘째, Worker가 죽어도 작업이 큐에 남아있어서 재시도가 가능하다. 셋째, Worker를 여러 개 실행하면 RabbitMQ가 자동으로 작업을 분배해서 처리 속도를 높일 수 있다.

Control Plane

Control Plane은 Kubernetes 클러스터 전체를 관리하고 제어하는 중추 역할을 한다. Corazy Arcade 클러스터는 1개의 마스터 노드에 Control Plane 컴포넌트들이 배포되어 있으며, 9개의 워커 노드를 관리한다.

kube-apiserver - 모든 통신의 중심

kube-apiserver는 Kubernetes API를 노출하는 컴포넌트로, 클러스터의 모든 통신이 거쳐가는 진입점이다. kubectl 명령어를 실행하면 apiserver와 통신하고, 다른 Control Plane 컴포넌트들도 apiserver를 통해서만 클러스터 상태에 접근한다.

etcd - 클러스터의 단일 진실 공급원

etcd는 분산 key-value 저장소로, 클러스터의 모든 데이터를 저장하는 데이터베이스다. Deployment, Service, ConfigMap, Secret 같은 모든 리소스 정보와 클러스터의 현재 상태가 etcd에 저장된다.

kube-scheduler - Pod 배치 결정

kube-scheduler는 새로 생성된 Pod를 어느 워커 노드에 배치할지 결정한다. 단순히 무작위로 배치하는 것이 아니라 여러 조건을 고려해서 최적의 노드를 선택한다.

kube-controller-manager - 원하는 상태 유지

kube-controller-manager는 여러 개의 컨트롤러를 실행하면서 클러스터의 원하는 상태(desired state)와 현재 상태(current state)를 지속적으로 비교하고 조정한다.

고려사항

현재 Corazy Arcade는 단일 마스터 노드로 구성되어 있다. 학습과 개발 단계에서는 충분하지만, 프로덕션 환경에서는 마스터 노드가 단일 장애점(SPOF)이 될 수 있다. 마스터 노드에 장애가 발생하면 기존 워커 노드와 Pod는 계속 실행되지만, 새로운 배포나 스케일링 같은 관리 작업을 할 수 없게 된다.

프로덕션 환경으로 확장할 때는 마스터 노드를 3개 이상의 HA(High Availability) 구성으로 변경하는 것이 권장된다. 여러 마스터 노드가 etcd 클러스터를 구성하고, apiserver도 로드밸런서 뒤에서 다중화되어 안정성을 확보할 수 있다.

11.13 경제신문 스크랩 수치화 인사이트

뉴스 링크

2025-10-23 13:38

최상위 수준의 보안 역량 선보인 플래그십 콘퍼런스 ‘SECUI MAX SUMMIT’ 개최 BLUEMAX NGF PRO 시리즈, 자체 개발 고성능 프로세서 탑재...기존 제품 대비 16배 성능 AI 위협 대응 플랫폼 TARP, 이벤트 분류 및 연관 정보 제공 자동화해 최신 보안 위협에 신속 대응

[보안뉴스 원병철 기자] 방화벽 시장의 절대강자 시큐아이(대표 정삼용)가 고성능 프리미엄급 방화벽 ‘BLUEMAX NGF PRO’와 AI 위협 대응 플랫폼 ‘TARP’를 선보이고 최상위 수준의 보안 역량 강화를 천명했다.

시큐아이는 10월 23일 서울 중구 웨스틴조선호텔에서 고객을 초청해 최초의 플래그십 콘퍼런스인 ‘SECUI MAX SUMMIT 2025’를 개최했다. SECUI MAX SUMMIT은 시큐아이가 최상위 수준의 보안 역량과 기술 비전을 선보이는 콘퍼런스로, 올해 ‘Maximize your Security’를 주제로 진행됐다.

시큐아이는 이번 행사에서 고성능 프리미엄급 방화벽 ┖BLUEMAX NGF PRO┖와 AI 기반 통합 위협 대응 플랫폼 ┖TARP┖를 최초로 공개하고, 향후 보안 전략을 제시했다.

행사는 정삼용 대표이사, 고려대학교 정보보호대학원 임종인 교수의 키노트, 신제품 및 신규 서비스 소개, 방화벽 고객 사례, 삼성 SDS와 글로벌 협력사의 세션 등으로 구성됐다.

정삼용 대표는 ‘Maximize your Security: SECUI Full Stack Security’를 주제로 한 키노트에서 보안 패러다임의 급격한 변화 속 시큐아이만의 보안 전략을 제시했다.

정 대표는 “AI Transformation으로 고객 환경이 빠르게 변화하는 가운데, ‘고성능’, ‘통합 보안 플랫폼’, ‘AI’는 보안 플랫폼 구축의 핵심 전략 요소”라며, “시큐아이는 고성능 하드웨어가 탑재된 BLUEMAX NGF PRO와 AI 기반 통합 위협 대응 플랫폼을 기반으로 보안의 풀 스택(Full Stack)을 완비하고 이를 지속적으로 고도화해 고객의 보안성을 극대화할 것”이라고 말했다.

시큐아이가 개발한 보안 AI 기반 통합 위협 대응 플랫폼 ‘TARP’ 이어 김형동 보안서비스실장은 ‘지능형 Threat Intelligence 및 위협 대응 플랫폼(AI-Driven Security)’ 세션에서 AI 기반 보안 관제 전략을 제시했다.

TARP(Threat Analysis and Response Platform)는 시큐아이의 자체 TI 플랫폼 STIC과 연동되어 네트워크·엔드포인트·서버 등 다양한 보안 영역의 위협을 AI 기반으로 자동 분석 및 대응하는 통합 위협 대응 플랫폼이다.

시큐아이는 자체 TI 플랫폼 STIC을 통해 악성 파일 8억 건, 악성 URL 3천만 건 이상의 국내 최대 규모의 위협 인텔리전스를 확보하고 있다.

김형동 실장은 “TARP는 시큐아이가 자체 개발한 보안 AI와 TI 서비스, 그리고 시큐아이만의 고도화된 관제 역량을 통해 새로운 보안 위협에도 대응할 수 있는 보안 플랫폼”이라면서, “이미 상당수의 고객이 TARP를 통해 고성능의 보안 서비스를 받고 있다”라고 설명했다.

고성능, 지능형, ZTNA 3박자 고루 갖춘 BLUEMAX NGF PRO 시리즈 조원용 개발실장은 ‘BLUEMAX NGF PRO 시리즈 소개 - 고성능, 지능형, ZTNA 방화벽’을 주제로 신제품 발표 세션을 진행했다. BLUEMAX NGF PRO는 시큐아이가 자체 개발한 고성능 전용 프로세서를 탑재해 기존 제품 대비 최대 16배 이상의 성능을 자랑한다.

또한 방화벽을 중심으로 보안 기능이 통합되는 글로벌 트렌드에 맞춰 단일 플랫폼에서 고성능 보안과 AI 보안 기능을 동시에 제공하며, IDC, 통신사, 대기업, 금융 등 하이엔드(High-end) 시장에 최적화되어 있다.

특히 BLUEMAX NGF PRO 시리즈는 △고성능 방화벽 △지능형 방화벽 △ZTNA 방화벽을 주요 이슈로 개발됐다. 고성능을 위해 컨트롤 플레인(Control Plane)과 데이터 플레인(Data Plane)을 분리해 각각 전용 프로세스를 사용했으며, 지능형을 위해 기존 알려진 위협은 물론 변종 악성코드와 알려지지 않은 신규 위협까지 모두 차단할 수 있도록 했다. 아울러 ZTNA를 위해 정책기반을 넘어 올바른 사용자인지를 재확인하고, 2차 인증을 사용하며, 사용자의 현재 접속 단말의 상태까지 모두 점검해 접속을 허용한다. 또한 최소한의 접근권한만 인정해 서버나 개발망 등 각각에 마이크로 세그먼트를 적용해 횡적 이동을 방지했다.

조원용 개발실장은 “이번 BLUEMAX NGF PRO 시리즈는 시큐아이가 자체 개발한 전용 프로세스를 통해 경쟁사보다 두 배 이상의 성능을 내도록 개발됐다”라면서, “레거시 방화벽 3종과 차세대 방화벽 3종 등 총 6종을 준비하고 있으며, 특히 올해 말까지 레거시 방화벽 1종과 차세대 방화벽 1종을 출시할 계획”이라고 밝혔다.

한편, 시큐아이는 올해 1회를 맞이한 ‘SECUI MAX SUMMIT’을 보안혁신 사례와 신제품 공개 등 플래그십 행사로 강화해 매년 진행할 방침이다.

[원병철 기자(boanone@boannews.com)]

용어 정리

SECUI MAX SUMMIT : 시큐아이가 주최하는 플래그십 보안 콘퍼런스로, 자사의 최상위 보안 기술과 비전을 소개하고 신제품 및 보안 전략을 공개하는 행사

BLUEMAX NGF PRO : 시큐아이가 자체 개발한 고성능 프리미엄 방화벽으로, 전용 프로세서를 탑재해 기존 대비 최대 16배의 성능을 제공하고 AI 기반 지능형 보안 기능을 통합한 제품

TARP (Threat Analysis and Response Platform) : 시큐아이의 AI 기반 통합 위협 대응 플랫폼으로, 위협 인텔리전스(STIC)와 연동해 네트워크·엔드포인트 등 다양한 영역의 보안 위협을 자동 분석하고 대응

STIC (Secui Threat Intelligence Center) : 시큐아이가 운영하는 위협 인텔리전스 플랫폼으로, 악성 파일과 URL 정보를 대규모로 수집·분석해 보안 위협 정보를 제공

ZTNA (Zero Trust Network Access) : 사용자 신원과 기기 상태를 지속적으로 검증해 최소 권한만 부여하는 보안 모델로, 내부망 침투와 횡적 이동을 방지

Full Stack Security : 하드웨어부터 소프트웨어, AI 기반 위협 대응까지 보안 전 영역을 통합 관리하는 시큐아이의 보안 전략으로, 고객의 전방위적 보안성을 강화하는 것을 목표로 함

요약

시큐아이는 10월 23일 서울 웨스틴조선호텔에서 ‘SECUI MAX SUMMIT 2025’를 개최하고, 자사의 최고 수준 보안 기술과 비전을 공개했다. 이번 행사에서는 자체 개발한 고성능 프로세서를 탑재한 프리미엄 방화벽 ‘BLUEMAX NGF PRO’와 AI 기반 위협 대응 플랫폼 ‘TARP’를 처음으로 선보였다. BLUEMAX NGF PRO는 기존 제품 대비 최대 16배의 성능을 제공하며, 고성능·지능형·ZTNA 기능을 모두 갖춘 통합 보안 플랫폼으로 IDC, 통신사, 금융 등 하이엔드 시장을 겨냥했다. 또한 TARP는 시큐아이의 위협 인텔리전스 플랫폼 STIC과 연동되어 AI 기반 자동 분석과 대응을 통해 최신 보안 위협에 신속히 대응할 수 있다. 시큐아이는 이번 행사를 시작으로 SECUI MAX SUMMIT을 매년 개최해 신제품 공개와 보안 혁신 사례를 공유하는 플래그십 행사로 발전시킬 계획이다.

방화벽(Firewall) 개념 정리

방화벽(Firewall)은 내부 네트워크와 외부 네트워크(예: 인터넷) 사이에서 트래픽을 감시·차단·허용하는 보안 시스템이다. 즉, 외부의 침입이나 악성 접근을 막고, 내부의 불필요한 정보 유출을 방지하는 역할을 한다.

주요 기능

1. 패킷 필터링(Packet Filtering) : IP, 포트, 프로토콜 등을 기준으로 트래픽을 허용하거나 차단
2. 상태 기반 검사(Stateful Inspection) : 트래픽의 연결 상태를 추적해 비정상 연결 탐지
3. 애플리케이션 제어(Application Control) : HTTP, HTTPS 등 응용 계층 트래픽을 분석
4. 침입 방지(IPS) : 악성 코드나 해킹 시도를 탐지 및 차단
5. VPN 연동 : 안전한 원격 접속 환경 제공

시큐아이의 성능 향상 포인트 (BLUEMAX NGF PRO)

시큐아이의 ‘BLUEMAX NGF PRO’는 기존 방화벽의 구조와 성능을 대폭 개선한 프리미엄급 차세대 방화벽(NGF, Next Generation Firewall)이다.

1. 자체 개발 전용 고성능 프로세서 탑재

• 시큐아이가 직접 설계한 보안 전용 프로세서(Chip)를 사용
• 범용 CPU 대신 보안 트래픽 처리에 최적화된 하드웨어로 설계되어 → 기존 제품 대비 최대 16배의 성능 향상 달성

2. 컨트롤 플레인(Control Plane)과 데이터 플레인(Data Plane) 분리

• 기존 방화벽은 제어와 데이터 처리를 같은 자원에서 수행 → 부하 발생
• NGF PRO는 이를 분리해 각각 전용 프로세서로 처리 → 처리 속도 및 안정성 향상, 대규모 트래픽 환경에서도 지연 최소화

3. AI 기반 지능형 위협 탐지 기능 강화

• 기존 알려진 공격뿐 아니라 변종 악성코드와 미지의 위협(Unknown Threat)도 탐지
• AI 기반 분석 엔진을 통해 실시간으로 의심 트래픽을 식별

4. ZTNA(Zero Trust Network Access) 적용

• 단순 IP/정책 기반 접근이 아니라, 사용자 신원·기기 상태·접속 위치 등을 지속 검증
• 2차 인증 및 마이크로 세그멘테이션으로 내부망 횡적 이동 차단

5. 통합 보안 플랫폼화

• 단일 시스템 내에서 방화벽, IPS, AI 분석, ZTNA 등 다양한 기능 통합
• 기업 환경(금융, 통신, IDC 등)에 맞춘 하이엔드 보안 인프라 구축 가능

요약

즉, 시큐아이는 하드웨어(프로세서) 성능과 AI 기반 소프트웨어 지능을 동시에 강화하여 ‘고성능·지능형·제로트러스트’ 3박자를 갖춘 차세대 방화벽으로 성능을 대폭 끌어올렸다.

참고자료

IBM, 가상 및 물리적 방화벽 지원 서비스 확대

중국 해킹그룹, 지원 종료된 방화벽 제로데이 공격…국가 기관 타깃 공격 정황

양자 기술이 발전함에 따라 비밀번호는 여전히 안전한 방화벽일까요?

문제 발생

구글 로그인 후 계속을 누르면 인가 코드와 함께 콜백 URL 로 리다이렉트 되어야 한다.

근데 쿠버로 이전하면서 404가 뜨게 되었다.

이 그림은 OAuth의 흐름을 그림으로 그렸던 것인데 보자면 구글 서버에서 코드를 줄 때 프론트 서버에서 404가 뜬 것이다.

왜?

SPA의 라우팅 방식

전통적인 웹사이트는 /auth/google/callback 요청이 서버가 auth/google/callback.html 파일을 찾는다. 파일이 있으면 200, 없으면 404

하지만 우리는 React SPA로 구성되어서 index.html 밖에 없다. 그렇기에 모든 경로가 실제로는 index.html 하나인 것이다. index.html이 로드되면 JavaScript 가 URL을 보고 적절한 컴포넌트를 렌더링한다.

하지만 서버는 이를 모르기 때문에 /auth/google/callback 파일을 찾으려고 시도하면서 404가 뜨게 된다.

그래서 nignx에서 정적파일을 서빙할 때

location / {
    try_files $uri $uri/ /index.html; // 파일 없으면 index.html로

error_page 404 /index.html // 404 에러도 index.html로

이렇게 index.html 를 준다면 JavaScript가 적절한 페이지로 띄워준다.

왜 로컬에서는 문제가 없었을까?

Vite 개발 서버는 vite.config.js 가 자동으로 SPA 라우팅을 지원해준다.

export default {
    server: {
        historyApiFallback: true // 모든 404를 index.html로
    }
}

이렇게 모든 404 에러에 대한 폴백으로 index.html을 연결해주기 때문에 로컬에서는 문제가 없었다.

해결

쿠버 환경에서 nignx에서 라우팅 설정이 빠져있었다.

ConfigMap 생성

nginx 마운트

spec:
    ~~~
    ~~~
        volumeMounts:
          - name: nginx-config
            mountPath: /etc/nginx/conf.d
            readOnly: true
      volumes:
      - name: nginx-config
        configMap:
          name: frontend-nginx-config

Nginx 설정을 Pod에 주입시켰다.

이렇게 모든 요청이 index.html 을 향하게 되면서 404 에러를 없애고 JavaScript 가 안전하게 모든 요청을 처리할 수 있게 되었다.

결론

구글 OAuth 로그인 과정에서 404가 발생한 이유는 React 기반 SPA의 라우팅 특성 때문이었다. SPA는 실제로 존재하지 않는 경로라도 모두 index.html에서 처리하지만, Nginx는 이를 인식하지 못해 /auth/google/callback 파일을 찾으려다 404를 반환했다.

쿠버네티스 환경에서 Nginx 설정에

try_files $uri $uri/ /index.html;
error_page 404 /index.html;

을 추가해 모든 요청을 index.html로 리다이렉트하도록 수정함으로써 문제를 해결했다.

결국, SPA 라우팅에 대한 Nginx 설정이 빠져 있었던 것이 원인이었으며, 이 설정을 통해 프론트엔드가 정상적으로 구글 로그인 콜백을 처리할 수 있게 되었다.

11.07 경제신문 스크랩 수치화 인사이트

뉴스 링크

기사승인 2025.10.29 13:11:36

통화정책방향

□ 금융통화위원회는 다음 통화정책방향 결정시까지 한국은행 기준금리를 현재의 2.50% 수준에서 유지하여 통화정책을 운용하기로 하였다. 물가가 안정된 흐름을 지속하는 가운데 성장은 전망의 불확실성이 여전히 높지만 소비와 수출을 중심으로 개선세를 이어가고 있고 부동산 대책의 수도권 주택시장 및 가계부채 영향, 환율 변동성 등 금융안정 상황도 좀 더 살펴볼 필요가 있는 만큼 현재의 기준금리 수준을 유지하는 것이 적절하다고 판단하였다.

□ 세계경제를 보면, 미국 관세 인상의 영향이 가시화되면서 성장세가 완만히 둔화되고 물가경로는 국가별로 차별화될 전망이다. 국제금융시장에서는 장기 국채금리가 미 연준의 금리 인하, 미‧중 무역갈등 재부각 등으로 하락하였고, 미 달러화는 주요국 재정건전성 우려 등에 영향받으며 상당폭 등락하였다. 주가는 AI 관련 부문을 중심으로 높은 상승세를 이어갔다. 앞으로 세계경제와 국제금융시장은 미‧중 무역협상 및 품목별 관세 향방, 주요국의 통화·재정정책 변화 등에 영향받을 것으로 보인다.

□ 국내경제는 건설투자 부진에도 소비 회복세 지속, 양호한 수출 증가세 등으로 개선 흐름을 이어갔다. 고용은 전체 취업자수 증가규모가 확대되었으나 제조업 등 주요 업종에서는 감소세를 지속하였다. 앞으로 내수가 소비를 중심으로 회복세를 이어가고 수출도 반도체 경기 호조 등으로 당분간 양호한 흐름을 보이겠으나 미 관세 부과의 영향이 점차 커질 것으로 예상된다. 금년 및 내년 성장률은 지난 8월 전망(각각 0.9%, 1.6%)에 대체로 부합할 것으로 보이지만, 한‧미 및 미‧중 무역협상, 반도체 경기, 내수 개선속도 등과 관련한 상‧하방 불확실성이 확대된 것으로 판단된다.

□ 국내 물가는 9월 중 소비자물가 상승률이 2.1%, 근원물가 상승률(식료품 및 에너지 제외 지수)이 2.0%를 각각 나타내는 등 안정적인 흐름을 이어갔다. 단기 기대인플레이션율(일반인)은 9월 중 2.5%로 전월(2.6%)보다 소폭 낮아졌다.앞으로 국내 물가는 환율 상승 등에도 불구하고 낮은 수요압력, 국제유가 안정 등으로 2% 내외의 오름세를 지속할 것으로 예상된다. 이에 따라 금년 및 내년 소비자물가 상승률(2.0% 및 1.9%)과 근원물가 상승률(각각 1.9%) 모두 8월 전망치에 부합할 것으로 보인다. 향후 물가경로는 국내외 경기 흐름, 환율 및 국제유가 움직임, 정부의 물가안정 대책 등에 영향받을 것으로 보인다.

□ 금융·외환시장에서는 안정세가 이어지다가 9월 하순 이후 환율과 금리의 변동성이 다소 확대되었다. 원/달러 환율이 대미 관세협상 관련 불확실성, 미‧중 무역갈등 재부각 등으로 상당폭 상승하였으며 국고채금리는 좁은 범위에서 등락하다가 금융안정에 대한 경계감 등으로 높아졌다. 주가는 반도체 업황 호조, 자본시장 제도 개선 기대 등으로 큰 폭 상승하였다. 가계대출은 증가규모가 상당폭 축소되었으나 수도권 주택시장에서는 가격 상승세와 거래량이 다시 확대되었다.

□ 금융통화위원회는 앞으로 성장세를 점검하면서 중기적 시계에서 물가상승률이 목표수준에서 안정될 수 있도록 하는 한편 금융안정에 유의하여 통화정책을 운용해 나갈 것이다. 국내경제는 물가가 안정적인 흐름을 지속하는 가운데 성장은 개선세를 이어가고 있지만 무역협상, 반도체 경기 전망 등과 관련한 불확실성이 확대되었다. 금융안정 측면에서는 정부의 추가 부동산 대책의 효과를 점검하는 한편, 높은 환율 변동성의 영향에도 유의할 필요가 있다. 따라서 향후 통화정책은 성장의 하방리스크 완화를 위한 금리인하 기조를 이어나가되, 이 과정에서 대내외 정책 여건의 변화와 이에 따른 물가 흐름 및 금융안정 상황 등을 면밀히 점검하면서 기준금리의 추가 인하 시기 및 속도 등을 결정해 나갈 것이다.

용어 정리

장기 국채금리 : 만기가 보통 10년 이상인 국채(정부가 발행하는 채권)의 수익률을 의미합니다. 쉽게 말해, 투자자가 장기간(예: 10년) 동안 국채를 보유했을 때 기대할 수 있는 연간 이자 수익률을 나타냅니다.

요약

1. 한국은행 기준금리를 2.50%로 유지하며 통화정책을 운용하기로 결정.
2. 국내 소비와 수출 개선세 지속, 성장 불확실성 존재, 부동산·환율 등 금융안정 점검 필요.
3. 세계경제는 미·중 무역갈등, 금리·재정정책 변화 등에 따라 성장 둔화와 물가 차별화 전망.
4. 국내 물가는 안정적 흐름 지속, 단기 기대인플레이션 낮아 2% 내외 상승세 예상.
5. 향후 통화정책은 성장 하방리스크 완화와 금융안정을 고려하며 기준금리 추가 인하 시기와 속도 결정 예정.

장기 국채금리가 미 연준의 금리 인하, 미‧중 무역갈등 재부각 등으로 하락

최근 장기 국채금리가 하락하고 있는 이유 중 하나는 미국 연준(Fed)의 금리 인하 전망 때문이다. 연준이 금리를 낮추면 시장에서는 단기뿐만 아니라 장기 금리도 함께 하락할 것으로 예상한다. 이로 인해 투자자들은 낮아질 금리를 미리 반영해 장기 채권을 매수한다. 채권 수요가 늘어나면 채권 가격은 상승하고, 금리(수익률)는 자연스럽게 하락하게 된다.

또한, 미·중 무역갈등이 다시 부각되면서 시장의 불확실성이 커진다. 불확실성이 커지면 투자자들은 안전자산을 선호하게 되는데, 장기 국채는 대표적인 안전자산으로 인식된다. 이에 따라 장기 국채 수요가 늘어나 가격이 오르고 금리는 떨어지게 된다.

정리하면, 미국 연준의 금리 인하 기대와 글로벌 불확실성 증가는 장기 국채 수요를 높여 금리를 낮추는 요인으로 작용한다. 따라서 최근 장기 국채금리가 하락하는 현상은 이러한 시장 심리와 투자 흐름을 반영한 결과라고 볼 수 있다.

참고자료

[전문] 한국은행 금융통화위원회 10월 통화정책방향 결정문

'탈동조화' 글로벌 통화정책에 한국 경제 발목 잡힌다

이창용 한은 총재 IMF 초청 강연서 한국 통화정책 소개

frontend

현재 우리 프론트엔드는 실시간 양방향 통신을 위해서 SockJS와 STOMP를 사용한다. 이 두개가 어떻게 사용되는지 파악해보자

SockJS

const socket = new SockJS('https://example.com/ws/relay?token=abc123');

이 코드가 실행되면 SockJS는 내부적으로 이런 요청을 보낸다.

1. HTTP 기반 Handshake 요청

   GET /ws/relay/info?t=23985678443
   Accept: */*

2. 전송 방식 결정 브라우저 환경에 따라 SockJS가 다음 중 하나를 선택한다.

• WebSocket (가능하면 가장 먼저)
• xhr-streaming
• xhr-polling
• eventsource
• iframe-based transports

3. HTTP -> WebSocket 업그레이드 요청

GET /ws/relay/123/xyz/websocket HTTP/1.1
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

서버가 101 Switching Protocols 로 응답하면, 이후부터는 WebSocket 프레임 기반으로 전송이 이루어진다.

STOMP

이제 WebSocket이 통로를 뚫었으니, 어떤 메시징 규칙으로 데이터를 주고 받을 지를 STOMP (Simple Text Oriented Messaging Protocol) 사용한다.

내부적으로는 다음과 같은 문자열 프레임을 WebSocket으로 보낸다.

// 클라이언트 -> 서버 
CONNECT
accept-version:1.1,1.2
heart-beat:10000,10000
token: abc123

^@
// 서버 -> 클라이언트
CONNECTED
version:1.2
heart-beat:0,0

^@
// 구독 요청
SUBSCRIBE
id:sub-0
destination:/topic/rooms/123
// 서버 -> 클라이언트 
MESSAGE
subscription:sub-0
message-id:abc-123
destination:/topic/rooms/123

{"type":"USER_JOINED","roomId":"123","data":{...}}
^@
// 등등..

이 모든 프레임들이 WebSocket 프레임(payload) 안에 들어가서 왔다리갔다리 한다.

backend (Spring)

이제 이걸 처리할 Backend 코드를 살펴보자면

1. WebSocketConfig

프론트엔드가 /ws/relay 로 WebSocket/SockJS 요청을 보낼 수 있게 해준다.

메시지 브로커를 topic, queue 를 구독 prefix로 설정해두었다.

2. @MessageMapping (클라이언트 메시지 수신)

컨트롤러에서 @MessageMapping("/rooms/{roomId}/chat") 과 @SendTo("/topic/rooms/{roomId}") 를 통해서 브로드 캐스트

3. SimpMessagingTemplate (서비스에서 WebSocket 메시지 전송)

사용자가 방에 입장시 서비스 단에서 로직으로 SimpMessagingTemplate 를 사용해서 모든 참여자에게 입장을 알려준다.

Gateway (S.C.G)

/api/ws/relay 요청을 감지하면, /ws/relay로 relay 서버로 보낸다. 게이트웨이에서 인증 절차를 거치기 때문에 Cookie를 마이크로 서비스에 전달하지 않는다. 기본적으로 Gateway는 요청을 전달할 때 Host 헤더를 대상 서버 주소로 바꾼다. 그러나 SockJS 핸드셰이크 과정에서 CORS 및 Host 검증이 필요한 경우, 원본 호스트를 유지하도록 preserveHostHeader를 추가하였다.

트러블 슈팅

처음에 트리거 되는 path를 /ws/relay/** 로 해놨다가 nginx 에서 부터 걸러져서 문제가 있었는데 /api를 추가하고 stripPrefix를 통해 제거해줬다. (nginx가 /api 만 SCG로 넘김)

총 과정

*1. 프론트엔드 요청 *

GET /api/ws/relay/info?token=eyJ...&t=1762327856664 (SockJS)

2. Gateway filter

WebSocket 감지 후 쿼리 파라미터 추가

GET /api/ws/relay/info?token=eyJ...&t=...&userId=486&nickname=f23f23fdwf

3. stripPrefix(1) 적용

GET /ws/relay/info?token=eyJ...&t=...&userId=486&nickname=f23f23fdwf

(백엔드에서 /api 요청은 따로 받기 때문에)

4. Relay 서버 WebSocketHandshakeInterceptor

핸드 쉐이크 과정에서 queryParams.get 으로 유저 식별

결론

Spring Cloud Gateway는 HTTP 레벨에서 동작하기 때문에, WebSocket으로 업그레이드된 이후에는 커스텀 헤더를 주입하거나 수정할 수 없다. 따라서 Gateway에서 JWT를 검증한 뒤 유저 정보를 전달하려면 WebSocket 핸드셰이크 직전, 즉 HTTP 단계에서만 정보를 추가할 수 있다.

이 한계를 해결하기 위해 우리는 JWT 토큰을 쿼리 파라미터로 전달하고, Gateway 필터가 이를 검증한 뒤 userId, nickname 등의 유저 정보를 쿼리 파라미터로 추가하는 방식을 택했다. 이렇게 하면 WebSocket 업그레이드 이전의 HTTP 요청(GET /info, GET /{server_id}/{session_id}/websocket) 단계에서 이미 유저 식별 정보가 포함되어 Relay 서버로 전달된다.

Relay 서버에서는 WebSocketHandshakeInterceptor를 통해 이 쿼리 파라미터를 추출하고, 세션에 유저 정보를 저장하여 이후 STOMP 통신에서 인증된 사용자로 인식할 수 있다.

즉, Gateway는 WebSocket 업그레이드 이전 단계에서 JWT를 검증하고 유저 정보를 쿼리 파라미터에 주입, Relay 서버는 업그레이드 이후 단계에서 해당 정보를 활용하는 구조로 문제를 해결했다.

결과적으로, WebSocket 프로토콜의 제약을 우회하면서도 Gateway 레벨에서 인증과 유저 식별을 안전하게 처리할 수 있게 되었다.

기사를 보던 중 GSLB에 대한 내용이 있길래 정리해보고자 한다.

지능적 DNS

DNS 서비스의 발전된 형태

한마디로 정의하자면 특정 지역에 집중되는 트래픽을 분산하는 DNS 기반의 로드 밸런싱이다.

DNS 서비스는 도메인 이름을 IP 주소로 변환하는 일을 하는 서비스다. 하나의 도메인 주소에 대해서 여러 개의 IP주소를 넘겨줄 수 있는데, 이 기능을 이용해서 가용성 구성과 로드 밸런싱 기능을 수행할 수 있다. 하지만 가용성과 로드 밸런싱이 본 기능은 아니라서, 이런 목적으로 사용하기에는 한계가 있고 이를 해결한 것이 GSLB다.

밑에 그림은 위 : DNS, 아래 GSLB 로 DNS는 라운드로빈 방식이기 때문에 비효율적인 연결도 많이 보인다. GSLB는 위치 기반으로 해당 지역을 서비스하는 서버로 연결한다. (일부 기능) 사진 출처: https://www.joinc.co.kr/w/man/12/GSLB

어떻게?

조건에 맞게 연결

GSLB는 기존 DNS의 단순한 IP 반환 방식을 넘어서, 헬스 체크와 지능적인 라우팅 정책을 결합한 방식으로 동작한다.

사용자가 도메인을 요청하면 GSLB는 여러 조건을 실시간으로 판단한다. 각 데이터센터의 서버 상태가 정상인지, 현재 부하는 어느 정도인지, 사용자와의 지리적 거리는 얼마나 되는지, 네트워크 지연시간은 어떤지 등을 종합적으로 고려해서 최적의 IP 주소를 선택해 반환한다.

일반 DNS는 미리 설정된 IP 목록을 순서대로 반환하는 단순 Round Robin 방식이라 서버 장애 여부를 알 수 없다. 반면 GSLB는 실시간으로 서버 상태를 모니터링하기 때문에 장애가 발생한 서버는 자동으로 제외하고, TTL을 짧게 설정해서 빠르게 장애 전환이 가능하다.

SH수협은행의 경우를 예로 들면, 잠실 센터와 용인 센터가 모두 액티브 상태로 운영되면서 평상시에는 두 센터에 트래픽을 적절히 분산한다. 만약 잠실 센터에 장애가 발생하면 용인 센터로만 트래픽을 전달하고, 부하가 급증하면 여유있는 센터로 더 많은 트래픽을 할당하는 식이다.

사진 출처 : https://www.samsungsds.com/kr/network-gslb/gslb.html

데이터 일관성은?

한계와 이를 보완하기 위한 노력

액티브-액티브 구성에서 가장 중요한 문제는 바로 데이터 일관성이다. 두 개의 센터가 동시에 트래픽을 처리하는데, 각 센터의 데이터베이스가 서로 다른 상태라면 큰 문제가 발생할 수 있다.

금융권에서는 이를 해결하기 위해 주로 실시간 데이터 복제 기술을 사용한다. 한 센터에서 발생한 트랜잭션을 다른 센터로 즉시 동기화하는 방식이다. 이때 양방향 복제(Bidirectional Replication)를 사용해서 어느 센터에서 데이터 변경이 발생하든 실시간으로 반영되도록 한다.

하지만 완벽한 실시간 동기화는 사실상 불가능하고, 네트워크 지연으로 인한 시간차가 항상 존재한다. 이를 해결하기 위해 세션 어피니티(Session Affinity) 정책을 사용하기도 한다. 특정 사용자는 세션이 유지되는 동안 같은 센터로 계속 연결되도록 하는 것이다. 이렇게 하면 같은 사용자의 연속된 요청이 서로 다른 데이터 상태를 보는 문제를 줄일 수 있다.

또한 데이터베이스 레벨에서 충돌 해결(Conflict Resolution) 정책을 미리 정의해둔다. 동시에 같은 데이터를 수정하는 경우 어떤 센터의 데이터를 우선할지, 타임스탬프 기준으로 최신 데이터를 선택할지 등의 규칙을 명확히 해야 한다.

생각해볼 점들

DNS 캐싱 문제

GSLB가 아무리 빠르게 장애를 감지하고 IP를 변경해도, 사용자의 로컬 DNS 캐시나 ISP의 DNS 캐시에 이전 IP가 남아있다면 여전히 장애 서버로 접속을 시도하게 된다. 이를 해결하기 위해 TTL 값을 짧게 설정할 수 있는데 성능과 trade-off 될 수 있다.

모니터링과 알람

두개의 센터를 실시간으로 모니터링하고, 트래픽 분산 상태를 지속적으로 확인해야 한다. 한쪽 센터에 트래픽이 편중되거나, 응답 시간이 느려지거나, 에러율이 높아지는 등의 이상 징후를 빠르게 감지할 수 있는 체계가 필요하다. 기사에서 언급된 제니퍼 같은 APM 도구가 바로 이런 역할이다.

보안 정책의 이중 관리

방화벽 규칙, DDOS 방어, 침입 탐지 시스템 등 모든 보안 정책이 두 센터에서 동일하게 적용되어야 한다. 한쪽 센터의 보안 설정이 느슨하면 약점이 될 수 있다.

결론

GSLB는 단순히 트래픽을 분산하는 기술을 넘어서, 현대 금융 서비스의 무중단 운영을 가능하게 하는 핵심 인프라다.

SH수협은행이 잠실과 용인에 액티브-액티브 구성을 도입한 것은 단순한 기술 도입이 아니라, 고객에게 끊김 없는 서비스를 제공하겠다는 의지의 표현이다. 한 센터에 문제가 생기더라도 고객은 인터넷뱅킹을 계속 사용할 수 있고, 평상시에도 두 센터에 부하가 분산되어 더 안정적인 성능을 경험할 수 있다.

하지만 GSLB는 만능 해결책이 아니다. 데이터 일관성 유지, DNS 캐싱 문제, 높은 인프라 비용, 복잡한 운영 관리 등 고려해야 할 점이 많다. 특히 금융권처럼 데이터 정합성이 중요한 영역에서는 더욱 신중한 설계와 운영이 필요하다.

결국 GSLB는 고가용성과 성능 최적화라는 두 마리 토끼를 잡기 위한 선택이고, 그 선택에는 비용과 복잡도라는 대가가 따른다. 하지만 24시간 멈출 수 없는 금융 서비스에서 이는 선택이 아닌 필수가 되어가고 있다. 디지털 전환이 가속화되면서 GSLB 같은 인프라 기술의 중요성은 앞으로 더욱 커질 것이다.