jjaehyeok 님의 블로그

프로그래머스 Lv.3 | Python | 순위

jjaehyeok — Mon, 18 May 2026 11:27:59 +0900

1. 문제 정보

프로그래머스

SW개발자를 위한 평가, 교육의 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프

programmers.co.kr

난이도: Lv.2

2. 문제 설명

n명의 권투선수가 권투 대회에 참여했고 각각 1번부터 n번까지 번호를 받았습니다. 권투 경기는 1대1 방식으로 진행이 되고, 만약 A 선수가 B 선수보다 실력이 좋다면 A 선수는 B 선수를 항상 이깁니다. 심판은 주어진 경기 결과를 가지고 선수들의 순위를 매기려 합니다. 하지만 몇몇 경기 결과를 분실하여 정확하게 순위를 매길 수 없습니다.

선수의 수 n, 경기 결과를 담은 2차원 배열 results가 매개변수로 주어질 때 정확하게 순위를 매길 수 있는 선수의 수를 return 하도록 solution 함수를 작성해주세요.

제한사항

선수의 수는 1명 이상 100명 이하입니다.
경기 결과는 1개 이상 4,500개 이하입니다.
results 배열 각 행 [A, B]는 A 선수가 B 선수를 이겼다는 의미입니다.
모든 경기 결과에는 모순이 없습니다.

입출력 예 설명

2번 선수는 [1, 3, 4] 선수에게 패배했고 5번 선수에게 승리했기 때문에 4위입니다.
5번 선수는 4위인 2번 선수에게 패배했기 때문에 5위입니다.

3. 접근 기준

이 문제는 직접 경기한 결과만 보는 문제가 아니다. 간접 관계까지 확인해야 한다.

예를 들어:

1이 2를 이김
2가 3을 이김

이면:

1은 3도 이길 수 있음

으로 판단할 수 있다. 따라서 각 선수마다 다음 두 가지를 확인해야 한다.

이 선수가 이길 수 있는 선수들
이 선수를 이길 수 있는 선수들

이를 위해 그래프를 두 개 만든다.

wins  → 내가 이긴 선수 방향
loses → 나를 이긴 선수 방향

그리고 각 선수마다 BFS를 두 번 수행한다.

4. 사용한 패턴 / 알고리즘

그래프

경기 결과를 방향 그래프로 표현

BFS

간접 승리 관계 탐색
간접 패배 관계 탐색

5. 핵심 아이디어

핵심은 한 선수 기준으로 관계를 양방향으로 확인하는 것이다.

예를 들어 i번 선수에 대해:

wins 그래프를 따라가면 i가 이길 수 있는 선수들을 찾을 수 있다.
loses 그래프를 따라가면 i를 이길 수 있는 선수들을 찾을 수 있다.

이 두 개의 개수를 합쳤을 때:

win_cnt + lose_cnt == n - 1

이면, 나머지 모든 선수와의 관계가 확인된 것이므로 순위를 알 수 있다.

6. 풀이 코드

from collections import deque

def solution(n, results):
    answer = 0

    # wins[a] = a가 이긴 선수 목록
    wins = [[] for _ in range(n + 1)]

    # loses[b] = b를 이긴 선수 목록
    loses = [[] for _ in range(n + 1)]

    # 경기 결과를 그래프로 저장
    for a, b in results:
        wins[a].append(b)
        loses[b].append(a)

    # 각 선수마다 순위를 확정할 수 있는지 확인
    for i in range(1, n + 1):

        # i가 이길 수 있는 선수 수
        win_cnt = 0
        visited = [False] * (n + 1)
        q = deque([i])

        while q:
            node = q.popleft()
            visited[node] = True

            # 현재 선수가 이긴 선수들을 따라감
            for nxt in wins[node]:
                if not visited[nxt]:
                    visited[nxt] = True
                    q.append(nxt)
                    win_cnt += 1

        # i를 이길 수 있는 선수 수
        lose_cnt = 0
        visited = [False] * (n + 1)
        q = deque([i])

        while q:
            node = q.popleft()

            # 현재 선수를 이긴 선수들을 따라감
            for nxt in loses[node]:
                if not visited[nxt]:
                    visited[nxt] = True
                    q.append(nxt)
                    lose_cnt += 1

        # 다른 모든 선수와 승패 관계가 확인되면 순위 확정 가능
        if win_cnt + lose_cnt == n - 1:
            answer += 1

    return answer

6-1. 코드 추가 설명

이 문제에서 그래프를 두 개 만드는 이유는 방향이 다르기 때문이다.

wins[a].append(b)

는 다음 의미다.

a가 b를 이겼다

즉, a에서 출발하면 a가 이길 수 있는 선수들을 따라갈 수 있다.

반대로:

loses[b].append(a)

는 다음 의미다.

b를 이긴 선수는 a다

즉, b에서 출발하면 b를 이길 수 있는 선수들을 따라갈 수 있다.

예를 들어 경기 결과가 다음과 같다고 하자.

n = 5
results = [[4, 3], [4, 2], [3, 2], [1, 2], [2, 5]]

그러면 그래프는 다음처럼 만들어진다.

wins = [[], [2], [5], [2], [3, 2], []]

loses = [[], [], [4, 3, 1], [4], [], [2]]

2번 선수 기준으로 보면:

wins[2] = [5]

2번은 5번을 이길 수 있다.

loses[2] = [4, 3, 1]

2번은 4번, 3번, 1번에게 진다.

따라서 2번 선수는:

이길 수 있는 선수: 5번
질 수 있는 선수: 4번, 3번, 1번

즉, 2번 선수는 나머지 4명과의 관계를 모두 알 수 있다.

win_cnt + lose_cnt = 1 + 3 = 4
n - 1 = 4

따라서 2번 선수의 순위는 확정할 수 있다.

7. 핵심 로직 요약

이 문제의 핵심은 각 선수 기준으로 이길 수 있는 선수와 질 수 있는 선수를 모두 찾는 것이다.

경기 결과를 방향 그래프로 만든다.
wins에는 이긴 방향을 저장한다.
loses에는 진 방향을 반대로 저장한다.
각 선수마다 wins 방향으로 BFS를 수행한다.
각 선수마다 loses 방향으로 BFS를 수행한다.
두 개수를 합쳐 n - 1이면 순위 확정 가능하다.

결국, “승리 방향 탐색 + 패배 방향 탐색 + 전체 관계 확인” 이 흐름이 핵심이다.

8. 정리

처음 보면 단순히 승패 수를 세면 될 것처럼 보인다. 하지만 직접 경기 결과만으로는 순위를 알 수 없다.

이 문제에서 중요한 부분은 간접 관계였다.

A가 B를 이기고, B가 C를 이기면
A는 C보다 앞에 있다

이 관계를 그래프로 따라가야 한다.

또 하나 중요한 점은 한 방향만 보면 안 된다는 것이다.

순위를 확정하려면:

내가 이길 수 있는 선수
나를 이길 수 있는 선수

둘 다 알아야 한다.

결국 이 문제는 한 선수와 나머지 모든 선수의 관계를 그래프 탐색으로 확인하는 문제라고 볼 수 있다.

미니 PC 서버 Kubernetes 배포 (2) - Airflow 기반 데이터 파이프라인 동작 검증

jjaehyeok — Tue, 12 May 2026 19:54:46 +0900

1. 문제 배경

Kafka, Redis, MySQL, Spark Streaming을 포함한 기반 서비스 구성을 완료했지만, 각 구성 요소가 개별적으로 실행되는 상태만으로는 실제 데이터 흐름이 정상 동작하는지 확인하기 어려웠다.

특히 이번 구조에서는 다음 흐름이 실제로 연결되어 동작해야 했다.

Airflow
→ Kafka
→ Spark Streaming
→ Redis
→ MySQL, S3

즉, 단순 Pod 실행 여부가 아니라 실제 데이터가 생성되고 처리되는 흐름 자체를 검증할 필요가 있었다.

이번 단계에서는 Airflow DAG 실행을 통해 데이터가 생성된 이후, Kafka, Spark, Redis, MySQL, S3 로 이어지는 흐름이 정상적으로 연결되는지를 확인해야한다.

2. 목표

Airflow DAG 실행을 통한 데이터 적재
Kafka → Spark → Redis / MySQL,S3 흐름 검증
각 구성 요소 간 실제 연결 상태 확인
데이터 파이프라인 정상 동작 여부 확인

3. Airflow 구성 및 실행

데이터 적재를 위해 Airflow를 Kubernetes 환경에 배포했다.

Airflow는 Scheduler와 Webserver를 분리된 리소스로 구성했으며, 각 구성 요소는 YAML 기준으로 적용했다.

kubectl apply -f airflow-rbac.yaml
kubectl apply -f airflow-init.yaml
kubectl apply -f airflow-logs-pvc.yaml
kubectl apply -f airflow-scheduler.yaml
kubectl apply -f airflow-webserver.yaml
kubectl apply -f airflow-service.yaml

3-1) Airflow Webserver 접속

Airflow UI에 접근하기 위해 Kubernetes Service 기준으로 포트 포워딩을 수행했다.

kubectl port-forward svc/airflow-webserver 8080:8080 -n airflow

하지만 현재 Airflow는 원격 미니 PC 서버 내부에서 실행 중이었기 때문에, 로컬 PC 브라우저에서 직접 접근할 수는 없는 상태였다.

따라서 Windows 로컬 PC에서 SSH Local Port Forwarding을 추가로 구성했다.

ssh -L 8080:localhost:8080 <접속ID>@<미니PC-IP> -p <포트번호>

이후 로컬 브라우저에서 다음 주소로 접속했다.

localhost:8080

이 구조를 통해 로컬 PC 브라우저 요청이 SSH 터널을 거쳐 미니 PC 내부의 Airflow Webserver로 전달되도록 구성했다.

3-2) airflow hook 설정

Airflow에서 외부 API를 호출할 때 API 키나 기본 URL을 코드에 직접 작성하면 관리가 어려워진다.
특히 API 키가 DAG 코드에 포함되면 Git에 노출될 위험이 있고, 환경이 바뀔 때마다 코드를 수정해야 한다.

이를 방지하기 위해 Airflow의 Connection 기능을 사용했다.
Connection에 API 접속 정보를 등록하고, DAG에서는 Hook을 통해 필요한 값을 가져오도록 구성했다.

4. 데이터 흐름 확인

4-1) Kafka 데이터 유입 확인

Airflow DAG 실행 이후 Kafka topic에 데이터가 정상적으로 적재되는지 확인했다.

Kafka Pod 접속

kubectl exec -it kafka-0 -- bash

Topic 데이터 확인

kafka-console-consumer.sh \
--bootstrap-server localhost:9092 \
--topic outbreak_topic \
--from-beginning

확인 결과 DAG 실행 이후 Kafka topic에 메시지가 적재되는 것을 확인했다.

이를 통해 데이터가 파이프라인 시작 지점까지 정상적으로 전달되는 것을 확인할 수 있었다.

4-2) Spark Streaming 처리 확인

Spark Streaming Driver 및 Executor Pod 상태를 확인했다.

kubectl get pods | grep streaming

또한 로그를 통해 Kafka 데이터를 지속적으로 소비하는 흐름을 확인했다.

kubectl logs outbreak-streaming-driver

로그 확인 결과 Spark Streaming이 Kafka 메시지를 정상적으로 읽어서 배치 처리하는 것을 확인할 수 있었다.

특히 이번 구조에서는 Spark 작업을 DAG 실행 시마다 생성하는 방식이 아니라, Kafka topic을 지속적으로 구독하는 상시 실행 서비스 형태로 구성했다는 점이 중요했다.

4-3) Redis 반영 확인

Redis에 데이터가 정상적으로 저장되었는지 확인하기 위해 redis-cli로 key 목록을 조회했다.

kubectl exec -it redis-xxxxx -- redis-cli

KEYS *

조회 결과 Spark 처리 이후 Redis에 key가 저장된 것을 확인했다.

이를 통해 Spark 처리 결과가 실시간 저장 영역까지 정상적으로 전달되는 것을 확인할 수 있었다.

4-4) MySQL 반영 확인

최종적으로 MySQL에 데이터가 저장되는지 확인했다.

MySQL Pod 접속

kubectl exec -it mysql-0 -- mysql -u user -p

Database 확인

SHOW DATABASES;
USE toy_project;

테이블 확인

SHOW TABLES;

데이터 확인

SELECT * FROM OUTBREAK_OCCURRENCE;

확인 결과 돌발상황 ID(ACC_ID), 발생 시각, 종료 시각 데이터가 정상적으로 저장된 것을 확인했다.

4-5) S3 저장 확인

이를 통해 최종적으로 전처리된 데이터는 MySQL, 원본데이터는 S3에 정상적으로 전달되는 것을 검증할 수 있었다.

5. 핵심 포인트

이번 단계에서 중요한 점은 각 서비스를 단순 실행한 것이 아니라, 전체 흐름이 하나의 데이터 파이프라인으로 연결되어 동작하는지를 검증했다는 점이다.

각 서비스 역할은 다음과 같이 분리했다.

Airflow → 외부 데이터 수집 및 Kafka 적재
Kafka → 데이터 전달 경로 역할
Spark Streaming → Kafka 데이터 지속 처리
Redis → 실시간 저장 및 중간 버퍼 역할
MySQL → 최종 이력 데이터 저장
S3 → 원본 데이터 저장

특히 Spark Streaming은 DAG 실행 시마다 생성되는 구조가 아니라, Kafka topic을 지속적으로 구독하는 상시 실행 서비스 형태로 구성했다.

6. 전체 구조 정리

전체 데이터 흐름은 다음과 같이 구성했다.

Airflow
→ Kafka
→ Spark Streaming
→ Redis
→ MySQL

구체적으로는 다음과 같은 역할로 분리했다.

Airflow에서 1분 주기로 외부 API 호출
Kafka를 통해 메시지 단위 데이터 전달
PySpark에서 Kafka topic 지속 구독 및 전처리
Redis에 실시간 저장
MySQL에 최종 이력 데이터 저장

전체적으로 수집–처리–저장 흐름을 분리해 각 단계 역할을 명확하게 구성했다.

7. 마치며

이번 단계에서는 Kubernetes 위에서 실행 중인 각 서비스를 실제 데이터 흐름 기준으로 연결해 검증했다.

특히 단순 Pod 실행 상태만 확인하는 것이 아니라,

데이터 생성
Kafka 적재
Spark 처리
Redis 저장
MySQL 최종 적재

과정을 순차적으로 확인하면서 실제 데이터 파이프라인이 정상적으로 동작하는지를 검증할 수 있었다.

또한 Spark Streaming을 상시 실행 구조로 구성하면서, 실시간 데이터 처리 흐름도 함께 확인할 수 있었다.

미니 PC 서버 Kubernetes 배포 (1) - Kafka · Redis · MySQL 기반 서비스 배포

jjaehyeok — Tue, 12 May 2026 16:00:04 +0900

1. 문제 배경

사전 준비 단계에서 이미지, 설정, 권한, 저장소를 분리했지만 실제 서비스는 아직 실행되지 않은 상태였다.

Kubernetes에서는 서비스를 단순히 실행하는 것이 아니라, 각 서비스의 역할과 성격에 맞게 리소스를 나눠서 배포해야 한다.

특히 이번 구조에서는 다음 기준이 중요했다.

상태 저장 여부
다른 서비스의 접근 필요 여부
지속적으로 실행되어야 하는지 여부
후속 처리 서비스가 의존하는 리소스가 먼저 준비되어 있는지 여부

이번 단계에서는 Kafka, Redis, PostgreSQL과 같은 기반 서비스를 먼저 배포하고, 이후 Spark Streaming 서비스가 안정적으로 구독할 수 있도록 Kafka topic도 초기화 단계에서 함께 준비했다.

2. 목표

NaviSafe 주요 서비스를 Kubernetes 리소스로 분리하여 배포
서비스 간 연결 구조 구성
Spark Streaming이 의존하는 Kafka topic 사전 생성
이후 데이터 처리 흐름이 실행될 수 있는 기반 환경 준비

3. 배포 대상 서비스

이번 단계에서 배포한 주요 구성 요소는 다음과 같다.

Zookeeper / Kafka
→ 메시지 브로커 구성
Redis
→ 중간 버퍼 및 실시간 데이터 저장
PostgreSQL + PostGIS
→ 공간 데이터 및 최종 데이터 저장
Kafka Topic
→ Spark Streaming 구독 입력 경로

이 구성 요소들은 이후 Spark Streaming과 Airflow가 정상적으로 동작하기 위해 먼저 준비되어 있어야 하는 기반 서비스에 해당한다.

4. 리소스 설계 기준

서비스를 배포할 때 다음 기준으로 리소스를 나눴다.

4-1) StatefulSet

Kafka
Zookeeper
MySQL

이 리소스들은 데이터 유지가 필요하고, Pod 이름 및 순서가 의미를 가지는 서비스다. 따라서 일반 Deployment보다 StatefulSet이 더 적절했다.

4-2) Deployment

Redis

Redis는 현재 구조에서 단일 인스턴스로 운용했고, Pod가 재생성되더라도 동일한 방식으로 다시 실행되면 되는 형태였기 때문에 Deployment로 구성했다.

4-3) Service

Kafka Service
Redis Service
MySQL Service

Pod는 재생성될 때마다 IP가 변경될 수 있기 때문에, 다른 서비스들이 안정적으로 접근할 수 있도록 Service를 통해 고정된 접근 경로를 구성했다.

4-4) Job

Kafka Topic 초기화 Job

Kafka topic은 애플리케이션 로직 안에서 매번 생성하기보다, 초기화 단계에서 먼저 준비되어 있어야 하는 기반 리소스에 가까웠다.

따라서 별도 Job으로 분리해 한 번 생성하는 방식으로 구성했다.

5. 서비스 배포

각 리소스는 YAML 기준으로 배포했다.

kubectl apply -f zookeeper.yaml  
kubectl apply -f kafka.yaml

kubectl apply -f redis-service.yaml
kubectl apply -f redis-deployment.yaml

kubectl apply -f mysql-service.yaml 
kubectl apply -f mysql-statefulset.yaml

kubectl apply -f spark-rbac.yaml

이 과정을 통해 클러스터 내부에서 기반 서비스들이 먼저 실행되도록 구성했다.

spark-rbac.yaml은 이후 Spark 작업이 Kubernetes 리소스에 접근할 수 있도록 사전에 준비한 권한 설정이다.

6. Kafka Topic 초기화, Spark Streaming 실행 및 S3 접근 키 설정

이번 파이프라인에서는 다음 두 개의 topic이 필요했다.

outbreak_topic
emergency_alert_topic

초기에는 Airflow DAG에서 topic을 생성한 뒤 데이터를 적재하도록 구성했지만, Spark Streaming 서비스를 먼저 실행하는 구조에서는 topic이 없는 상태로 구독을 시도하면서 오류가 발생했다.

이후 topic은 데이터 적재 이전에 미리 준비되어 있어야 하는 기반 리소스로 보고, 별도 초기화 단계에서 먼저 생성하도록 순서를 조정했다.

6-1) Kafka Topic 초기화 Job 실행

kubectl apply -f kafka-topic-init.yaml

이 방식으로 topic을 먼저 생성해두면 이후 Spark Streaming 서비스는 topic이 존재하는 상태에서 안정적으로 구독을 시작할 수 있다.

6-2) Kafka Topic 생성 확인

kubectl exec -it kafka-0 -- bash
kafka-topics.sh --bootstrap-server localhost:9092 --list

6-3) aws s3 ACCESS_KEY_ID 설정

kubectl create secret generic aws-secret \
  --from-literal=AWS_ACCESS_KEY_ID=[] \
  --from-literal=AWS_SECRET_ACCESS_KEY=[] \
  --from-literal=AWS_REGION=ap-southeast-2 \
  --from-literal=S3_BUCKET=navisafe-data-jh \

6-4) Spark Streaming 서비스 실행

kubectl apply -f outbreak-streaming.yaml
kubectl apply -f emergency-alert-streaming.yaml

7. 실행 상태 확인

배포 이후 각 서비스가 정상적으로 실행 중인지 확인했다.

kubectl get pod

또한 Kafka topic 초기화 Job은 실행 완료 이후 Completed 상태가 된 것을 확인했다.

8. 핵심 포인트

이번 단계에서 중요한 점은 서비스를 한 번에 올린 것이 아니라, 각 서비스의 성격에 맞게 리소스를 나눠서 배포했다는 점이다.

상태 저장 서비스 → StatefulSet
반복 실행 서비스 → Deployment
서비스 간 연결 → Service
초기화 작업 → Job

특히 Kafka topic은 단순 부가 설정이 아니라, Spark Streaming 서비스가 정상적으로 시작되기 위해 먼저 준비되어야 하는 의존 리소스라는 점을 확인할 수 있었다.

9. 마치며

이번 단계에서는 실제 데이터 처리 이전에 필요한 기반 서비스를 먼저 Kubernetes 클러스터 위에 구성했다.

특히 Kafka, Redis, MySQL과 같은 서비스들은 단순 실행이 아니라

상태 저장 여부
서비스 간 연결 구조
초기화 순서
후속 서비스 의존성

을 고려해 리소스를 분리할 필요가 있었다.

또한 Spark Streaming이 안정적으로 실행되기 위해서는 Kafka topic 역시 사전에 준비되어 있어야 했고, 이를 별도 Job으로 분리하면서 초기화 작업과 지속 실행 서비스를 구분할 수 있었다.

이를 통해 이후 데이터 파이프라인이 안정적으로 동작할 수 있는 기반 환경을 먼저 준비할 수 있었다.

다음 단계에서는 Airflow를 Kubernetes 환경에 배포하고, 실제 데이터가 Kafka → Spark Streaming → Redis → MySQL, S3 로 이어지는 전체 흐름이 정상적으로 연결되는지를 검증할 예정이다.

특히 이번에는 단순 서비스 실행 여부가 아니라,

Airflow DAG를 통한 데이터 생성
Kafka topic 데이터 적재
Spark Streaming의 실시간 구독 및 처리
Redis 저장 확인
MySQL, S3 최종 적재 확인

과정을 순차적으로 확인하면서, 실제 데이터 파이프라인이 Kubernetes 환경에서 정상적으로 동작하는지를 검증할 예정이다.

또한 Spark Streaming을 DAG 실행 시마다 생성하는 구조가 아니라, Kafka topic을 지속적으로 구독하는 상시 실행 서비스 형태로 구성하면서 스트리밍 기반 처리 구조도 함께 확인할 예정이다.

미니 PC 서버 Kubernetes 배포 준비 - Namespace · Secret · Spark Operator 구성

jjaehyeok — Tue, 12 May 2026 15:17:11 +0900

1. 문제 배경

k3s 기반 Kubernetes 클러스터 구성을 완료한 이후 바로 서비스를 배포하려 했지만, Kubernetes는 단순히 컨테이너를 실행하는 구조가 아니라 이미지, 설정, 권한, 저장소가 분리된 상태에서 동작한다.

이 상태에서 바로 서비스를 배포할 경우 다음과 같은 문제가 발생할 수 있었다.

클러스터에서 이미지를 가져오지 못하는 문제
환경 변수와 설정이 코드에 종속되는 구조
Pod가 외부 리소스에 접근하지 못하는 문제
Pod 재시작 시 데이터가 유실되는 문제
서비스 간 리소스 충돌 문제

따라서 실제 NaviSafe 서비스를 배포하기 전에, Kubernetes 실행에 필요한 공통 구성 요소를 먼저 준비했다.

2. 목표

Kubernetes 실행에 필요한 공통 리소스 구성
설정과 코드 분리
서비스별 namespace 분리
외부 리소스 연결 정보 분리
Spark 작업 실행 환경 구성
데이터 유지 가능한 구조 준비

3. Docker Registry 기반 이미지 관리

k3s 환경에서는 kind처럼 로컬 이미지를 직접 주입하는 방식(kind load)을 사용할 수 없기 때문에, 클러스터가 Docker Registry에서 이미지를 직접 가져오는 방식으로 구성했다. 이를 위해 Deployment 및 SparkApplication YAML에서 이미지 경로를 DockerHub 기준으로 지정했다.

4. Helm 설치

Spark Operator를 Kubernetes에 설치하기 위해 Helm을 사용했다.

Windows 환경에서는 실행 파일을 직접 설치했지만, Ubuntu 서버에서는 공식 설치 스크립트를 사용해 구성했다.

4-1) Helm 설치

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

4-2) 설치 확인

helm version

정상적으로 설치된 경우 Helm 버전 정보가 출력된다.

5. Spark Operator 설치

Spark 작업을 Kubernetes 리소스로 관리하기 위해 Spark Operator를 설치했다. Spark Operator를 사용하면 Spark 작업을 단순 Pod 실행이 아니라 Kubernetes 리소스 형태로 선언적으로 관리할 수 있다.

5-1) Helm 저장소 등록

helm repo add spark-operator https://kubeflow.github.io/spark-operator
helm repo update

5-2)Spark Operator 설치

helm install spark-operator spark-operator/spark-operator \
--namespace spark-operator \
--create-namespace

5-3) 왜 Operator를 사용하는가

Operator를 사용하면

SparkApplication 리소스로 작업 정의 가능
Driver / Executor 자동 관리
재시작 및 상태 관리 가능
Spark 작업을 Kubernetes 방식으로 운영 가능

구조를 만들 수 있었다.

6. Namespace 구성

서비스 역할별로 리소스를 분리하기 위해 namespace를 구성했다.

kubectl create namespace airflow

7. Secret 구성

외부 서비스 연결 정보는 코드에 직접 포함하지 않고 Kubernetes Secret으로 분리했다.

kubectl create secret generic navisafe-producer-secret \
  --from-literal=KAFKA_BOOTSTRAP=<kafka-bootstrap-server> \
  --from-literal=REDIS_HOST=<redis-host> \
  --from-literal=MYSQL_HOST=<mysql-host> \
  --from-literal=MYSQL_USER=<username> \
  --from-literal=MYSQL_PASSWORD=<password>

※ 실제 계정 정보는 보안상 제외

8. ConfigMap 구성

초기 설정 파일은 ConfigMap으로 분리했다.

8-1) SQL 스크립트 ConfigMap

kubectl create configmap mysql-init-script --from-file=init.sql

8-2) Airflow Pod Template ConfigMap

kubectl create configmap airflow-pod-template \
--from-file=airflow-pod-template.yaml \
-n airflow

8-3) Spark Streaming 코드 ConfigMap

Spark Streaming 코드 역시 이미지 내부에 직접 포함하지 않고 ConfigMap으로 분리했다

kubectl create configmap spark-code --from-file=preprocessing/outbreak_streaming.py --from-file=preprocessing/emergency_streaming.py --from-file=utils/ -o yaml --dry-run=client | kubectl apply -f -

8-4) 왜 ConfigMap을 사용하는가

설정 파일을 이미지 내부에 포함할 경우 설정 변경 시 이미지를 다시 빌드해야 한다.

반면 ConfigMap을 사용하면

설정만 별도 수정 가능
운영 환경별 설정 분리 가능
코드와 설정 분리 가능

구조를 만들 수 있었다.

9. ServiceAccount 구성

Spark 작업이 Kubernetes 리소스에 접근할 수 있도록 ServiceAccount를 생성했다.

kubectl create serviceaccount spark

9-1) 왜 필요한가

Spark Driver Pod는 Kubernetes API와 통신하면서

Executor 생성
Pod 상태 조회
작업 상태 관리

등 작업을 수행한다. 따라서 Kubernetes 리소스 접근 권한이 필요했다.

10. StorageClass 및 PVC 확인

k3s에서는 기본적으로 local-path StorageClass를 제공한다.

kubectl get storageclass

확인 결과:

10-1) 왜 중요한가

NaviSafe에서는 다음 서비스들이 Persistent Volume을 사용한다.

PostgreSQL
Kafka
Redis 일부 구성
Airflow 로그 저장

따라서 PVC가 정상적으로 생성 가능한 환경이 필요했다. k3s는 기본적으로 local-path-provisioner를 포함하고 있기 때문에
별도 Storage Provisioner 설치 없이 로컬 디스크 기반 PVC를 사용할 수 있었다.

11. 마치며

이번 단계에서는 실제 서비스를 바로 배포하기보다, Kubernetes 운영에 필요한 공통 구성 요소를 먼저 준비했다.

특히 서버 환경에서는 단순 컨테이너 실행보다

이미지 관리 방식
설정 분리
권한 관리
저장소 구성
서비스 분리

가 먼저 정리되어야 안정적으로 운영할 수 있었다.

다음 단계에서는 실제 NaviSafe 서비스를 k3s 클러스터에 배포할 예정이다.

이를 위해

PostgreSQL / Redis / Kafka 배포
Spark Streaming 실행
Airflow 연결
Backend / Frontend 배포

과정을 순차적으로 진행하며, 실제 서버 환경에서 데이터 파이프라인이 정상적으로 동작하는지 검증할 예정이다.

미니 PC 서버에 k3s 기반 Kubernetes 운영 환경 구성

jjaehyeok — Mon, 11 May 2026 20:27:55 +0900

1. 문제 배경

로컬 Kubernetes 환경(kind)에서 데이터 파이프라인과 공간 데이터 처리 기능 검증을 완료한 이후, 이제 실제 서버 환경에서 장시간 실행 가능한 구조로 전환할 필요가 있었다.

로컬 환경에서는 다음과 같은 한계가 있었다.

PC 종료 시 서비스 중단
외부 네트워크 접근 제한
장시간 스트리밍 처리 운영 어려움
실제 서비스 환경과 차이 존재

따라서 항상 실행 가능한 미니 PC 서버에 SSH로 접속해 NaviSafe 서비스를 직접 배포하고 운영 환경을 구성하기로 했다.

또한 이후 AWS 기반 클라우드 환경으로 확장하기 전에, 우선 미니 PC 서버에서 실제 배포 및 운영 과정을 먼저 검증할 예정이다.

이를 통해

Kubernetes 기반 서비스 운영
장시간 스트리밍 처리 안정성 확인
네트워크 및 서비스 연결 검증
서버 환경에서의 리소스 사용 확인

과정을 사전에 점검하고, 이후 클라우드 환경으로 확장할 계획이다.

2. 목표

미니 PC 서버 SSH 접속
Kubernetes 환경 구성
NaviSafe 서비스 배포
외부 네트워크에서 접근 가능한 구조 준비

3. kubectl 설치 및 서버 환경 구성

미니 PC 서버에 SSH로 접속한 이후, 먼저 Kubernetes 클러스터를 제어하기 위한 CLI 도구인 kubectl 설치를 진행했다.

3-1) Kubernetes 저장소 등록

이후 Kubernetes 공식 저장소를 등록했다.

sudo apt update
sudo apt install -y apt-transport-https ca-certificates curl

curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | \
sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] \
https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /" | \
sudo tee /etc/apt/sources.list.d/kubernetes.list

3-2) kubectl 설치

sudo apt update
sudo apt install -y kubectl

설치 이후 버전을 확인했다.

kubectl version --client

이를 통해 미니 PC 서버에서도 Kubernetes 클러스터를 직접 제어할 수 있는 환경을 구성했다.

4. k3s 기반 Kubernetes 클러스터 구성

로컬 환경에서는 kind 기반으로 Kubernetes 구성을 테스트했지만, 미니 PC 서버에서는 장시간 실행과 실제 운영 환경 구성을 고려해 k3s 기반으로 전환했다.

kind는 Docker 컨테이너 내부에서 Kubernetes 클러스터를 실행하는 구조이기 때문에 로컬 테스트에는 적합하지만, 서버 환경에서 상시 운영하기에는 다소 무거운 구조였다.

반면 k3s는 경량 Kubernetes 배포판으로

단일 서버 환경 운영에 적합
리소스 사용량이 비교적 작음
서버 재부팅 이후 자동 복구 가능
실제 운영 환경과 유사한 구조 구성 가능

장점이 있었기 때문에 미니 PC 환경에서는 k3s를 선택했다.

4-1) k3s 설치

공식 설치 스크립트를 통해 k3s를 설치했다.

curl -sfL https://get.k3s.io | sh -

설치 이후 k3s 서비스 상태를 확인했다.

sudo systemctl status k3s

active(running) 정상 확인

5. kubectl과 k3s 클러스터 연결

5-1) k3s 설치 이후 노드 상태를 확인

kubectl get nodes

하지만 다음과 같은 오류가 발생했다.

The connection to the server localhost:8080 was refused

이는 Kubernetes 클러스터 문제가 아니라, 일반 kubectl이 k3s의 kubeconfig 파일을 찾지 못해 기본 주소(localhost:8080)로 접근한 상태였다.

5-2) k3s 전용 kubectl 확인

먼저 k3s 내부 kubectl을 사용해 클러스터 상태를 확인했다.

sudo k3s kubectl get nodes

정상적으로 노드가 조회되는 것을 확인했다. 이를 통해 k3s 클러스터 자체는 정상적으로 실행 중인 상태임을 확인했다.

5-3) kubeconfig 연결

이후 일반 kubectl에서도 동일하게 클러스터를 제어할 수 있도록 k3s kubeconfig 파일을 사용자 환경으로 복사했다.

mkdir -p ~/.kube
sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
sudo chown $USER:$USER ~/.kube/config
chmod 600 ~/.kube/config

5-4) 연결 확인

다시 노드 상태를 확인했다.

kubectl get nodes

정상적으로 k3s 노드가 조회되는 것을 확인했다.

왜 필요한가

k3s는 자체 kubeconfig를 /etc/rancher/k3s/k3s.yaml 경로에 생성한다.

하지만 일반 kubectl은 기본적으로 다음 경로를 참조한다.

~/.kube/config

따라서 kubeconfig를 사용자 환경으로 복사하지 않으면 kubectl이 클러스터 정보를 찾지 못하게 된다.

이번 과정은 단순 파일 복사가 아니라, k3s 클러스터와 일반 kubectl CLI를 연결하는 작업이었다.

6. k3s 기본 리소스 확인

k3s 설치 및 kubectl 연결 이후, 클러스터 내부 기본 리소스가 정상적으로 실행 중인지 확인했다.

kubectl get pods -A
kubectl get svc -A
kubectl get storageclass

6-1) Pod 상태 확인

kubectl get pods -A

k3s 설치 직후 기본적으로 생성되는 시스템 Pod들을 확인했다.

확인 결과:

CoreDNS
metrics-server
local-path-provisioner
traefik

등 주요 시스템 리소스가 정상적으로 Running 상태인 것을 확인했다.

왜 확인하는가

이 리소스들은 Kubernetes 클러스터의 기본 동작에 필요한 구성 요소들이다.

예를 들어

CoreDNS → Pod 간 DNS 통신
metrics-server → 리소스 모니터링
local-path-provisioner → PVC 동적 생성
traefik → Ingress 및 외부 접근 처리

역할을 담당한다. 즉, 이 리소스들이 정상 동작해야 이후 NaviSafe 서비스도 안정적으로 배포할 수 있다.

6-2) Service 확인

kubectl get svc -A

클러스터 내부 서비스 상태를 확인했다. 특히 traefik 서비스가 LoadBalancer 형태로 생성된 것을 확인했다.

이를 통해 이후 외부 네트워크 접근 구성이 가능한 상태임을 확인했다.

6-3) StorageClass 확인

kubectl get storageclass

확인 결과 기본 StorageClass로 local-path가 설정된 것을 확인했다.

왜 중요한가

NaviSafe에서는 다음 서비스들이 Persistent Volume을 사용한다.

PostgreSQL
Kafka
Redis 일부 구성
Airflow 로그 저장

따라서 PVC가 정상적으로 생성될 수 있는 StorageClass가 반드시 필요했다. k3s에서는 기본적으로 local-path-provisioner를 제공하기 때문에 별도 스토리지 설정 없이도 로컬 디스크 기반 PVC를 사용할 수 있었다.

이번 단계에서는 단순 설치 확인이 아니라

DNS
네트워크
스토리지
시스템 Pod

등 Kubernetes 기본 구성 요소가 정상적으로 동작하는지를 검증했다는 점이 중요했다. 이를 통해 이후 NaviSafe 서비스를 실제로 배포할 수 있는 클러스터 상태를 확인했다.

7. 마치며

이번 과정에서는 로컬 kind 환경에서 검증했던 Kubernetes 구성을 실제 미니 PC 서버 환경으로 확장했다.

단순히 Kubernetes를 설치하는 수준이 아니라,

SSH 기반 서버 접근
Docker 리소스 정리 및 디스크 문제 해결
kubectl 설치
k3s 클러스터 구성
kubeconfig 연결
기본 시스템 리소스 검증

과정을 순차적으로 진행하며 실제 운영 가능한 Kubernetes 환경을 준비했다.

특히 로컬 테스트 환경에서는 크게 드러나지 않았던

디스크 사용량 관리
Kubernetes 저장소 설정
kubeconfig 연결
서버 환경 리소스 관리

문제를 직접 확인하면서, 운영 환경에서는 단순 서비스 실행 외에도 인프라 상태를 함께 관리해야 한다는 점을 확인할 수 있었다.

또한 k3s 기반으로 전환하면서 단일 서버 환경에서도 비교적 가벼운 Kubernetes 구성이 가능했고,
이후 NaviSafe 서비스를 장시간 실행할 수 있는 기반 환경을 마련할 수 있었다.

다음 단계에서는 실제 NaviSafe 서비스를 k3s 클러스터 위에 배포할 예정이다.

이를 위해

Namespace 구성
Secret / ConfigMap 적용
PostgreSQL / Redis / Kafka 배포
Spark Streaming 연결
Backend / Frontend 서비스 배포

등의 과정을 순차적으로 진행하며, 로컬 테스트 환경에서 검증했던 데이터 파이프라인을 실제 서버 환경에서 실행할 예정이다.

프로그래머스 Lv.2 | Python | 배달

jjaehyeok — Mon, 11 May 2026 12:25:25 +0900

1. 문제 정보

프로그래머스

SW개발자를 위한 평가, 교육의 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프

programmers.co.kr

난이도: Lv.2

2. 문제 설명

N개의 마을로 이루어진 나라가 있습니다. 이 나라의 각 마을에는 1부터 N까지의 번호가 각각 하나씩 부여되어 있습니다. 각 마을은 양방향으로 통행할 수 있는 도로로 연결되어 있는데, 서로 다른 마을 간에 이동할 때는 이 도로를 지나야 합니다.

도로를 지날 때 걸리는 시간은 도로별로 다릅니다. 현재 1번 마을에 있는 음식점에서 각 마을로 음식 배달을 하려고 합니다. 각 마을로부터 음식 주문을 받으려고 하는데, N개의 마을 중에서 K 시간 이하로 배달이 가능한 마을에서만 주문을 받으려고 합니다. 다음은 N = 5, K = 3인 경우의 예시입니다.

위 그림에서 1번 마을에 있는 음식점은 [1, 2, 4, 5] 번 마을까지는 3 이하의 시간에 배달할 수 있습니다. 그러나 3번 마을까지는 3시간 이내로 배달할 수 있는 경로가 없으므로 3번 마을에서는 주문을 받지 않습니다. 따라서 1번 마을에 있는 음식점이 배달 주문을 받을 수 있는 마을은 4개가 됩니다.

마을의 개수 N, 각 마을을 연결하는 도로의 정보 road, 음식 배달이 가능한 시간 K가 매개변수로 주어질 때, 음식 주문을 받을 수 있는 마을의 개수를 return 하도록 solution 함수를 완성해주세요.

제한사항

마을의 개수 N은 1 이상 50 이하의 자연수입니다.
road의 길이(도로 정보의 개수)는 1 이상 2,000 이하입니다.
road의 각 원소는 마을을 연결하고 있는 각 도로의 정보를 나타냅니다.
road는 길이가 3인 배열이며, 순서대로 (a, b, c)를 나타냅니다.
- a, b(1 ≤ a, b ≤ N, a != b)는 도로가 연결하는 두 마을의 번호이며, c(1 ≤ c ≤ 10,000, c는 자연수)는 도로를 지나는데 걸리는 시간입니다.
- 두 마을 a, b를 연결하는 도로는 여러 개가 있을 수 있습니다.
- 한 도로의 정보가 여러 번 중복해서 주어지지 않습니다.
K는 음식 배달이 가능한 시간을 나타내며, 1 이상 500,000 이하입니다.
임의의 두 마을간에 항상 이동 가능한 경로가 존재합니다.
1번 마을에 있는 음식점이 K 이하의 시간에 배달이 가능한 마을의 개수를 return 하면 됩니다.

3. 접근 기준

이 문제의 핵심은 1번 마을에서 각 마을까지의 최단 거리를 구하는 것이다. 도로에는 이동 비용이 있고, 모든 비용이 동일하지 않다.
따라서 단순 BFS가 아니라 다익스트라 알고리즘을 사용해야 한다.

정리하면 다음 흐름이다.

마을과 도로 정보를 그래프로 만든다.
1번 마을에서 시작한다.
각 마을까지의 최소 이동 시간을 계산한다.
계산된 거리 중 K 이하인 마을만 카운트한다.

4. 사용한 패턴 / 알고리즘

다익스트라 알고리즘

시작 노드에서 다른 모든 노드까지의 최단 거리 계산
간선 비용이 있는 그래프에서 사용
우선순위 큐를 사용하면 더 짧은 거리부터 탐색 가능

힙(heapq)

현재까지 발견한 거리 중 가장 짧은 거리부터 꺼내기 위해 사용

그래프 (인접 리스트)

각 마을과 연결된 마을 정보 저장

5. 핵심 아이디어

1) dist 배열

dist[i]

의 의미:

1번 마을에서 i번 마을까지의 현재 최단 거리

최소 비용을 구해야기 때문에 처음에는 모두 매우 큰 값으로 초기화한다.

INF = int(1e9)
dist = [INF] * (N + 1)

그리고 시작점만 0으로 설정한다.

dist[1] = 0

2) heapq 사용 이유

다익스트라는 현재까지 가장 짧은 거리 부터 탐색해야 한다. 거리를 기준으로 하기 때문에 거리를 첫번째 값으로 배치한다.

그래서 힙에:

(거리, 노드)

형태로 저장한다.

예:

(3, 5)

의미:

5번 마을까지 현재 거리 3

heapq는 튜플 첫 번째 값을 기준으로 정렬하므로 가장 짧은 거리부터 꺼낼 수 있다

6. 풀이 코드

import heapq

def solution(N, road, K):

    # 그래프 생성
    # graph[a] = [(연결 마을, 비용), ...]
    graph = [[] for _ in range(N + 1)]

    # 양방향 도로 정보 저장
    for a, b, cost in road:
        graph[a].append((b, cost))
        graph[b].append((a, cost))

    INF = int(1e9)

    # 최단 거리 저장 배열
    dist = [INF] * (N + 1)

    # 시작 마을은 1번
    dist[1] = 0

    # 우선순위 큐 생성
    heap = []

    # (현재 거리, 현재 마을)
    heapq.heappush(heap, (0, 1))

    while heap:

        # 현재 가장 짧은 거리의 마을 꺼내기
        cur_dist, cur_node = heapq.heappop(heap)

        # 이미 더 짧은 경로로 처리된 적이 있으면 무시
        if cur_dist > dist[cur_node]:
            continue

        # 현재 마을과 연결된 다음 마을 확인
        for next_node, cost in graph[cur_node]:

            # 다음 마을까지 거리 계산
            next_dist = cur_dist + cost

            # 더 짧은 거리라면 갱신
            if next_dist < dist[next_node]:

                # 최단 거리 갱신
                dist[next_node] = next_dist

                # 힙에 새로운 거리 정보 추가
                heapq.heappush(heap, (next_dist, next_node))

    # K 이하 거리인 마을 개수 반환
    return sum(d <= K for d in dist)

6-1. 예시로 이해하기

문제 예시와 같은 구조가 있다고 하자.

도로 및 그래프:

road = [
    [1, 2, 1],
    [1, 4, 2],
    [2, 3, 3],
    [2, 5, 2],
    [4, 5, 2],
    [5, 3, 1]
]

## graph[i]: i번째 마을의 (인접 마을, 비용)
graph = [[], [(2, 1), (4, 2)], [(1, 1), (3, 3), (5, 2)], 
	[(2, 3), (5, 1)], [(1, 2), (5, 2)],
	[(2, 2), (3, 1), (4, 2)]]

초기 상태:

dist = [INF, 0, INF, INF, INF, INF]
heap = [(0, 1)]

1) 1번 마을 탐색 (탐색 시작 마을)

heap = [(0,1)]
heapq.heappop(heap) # (0, 1) => (비용, 마을)

연결 정보:

graph[1] = [(2, 1), (4, 2)] #(1번 마을의 인접 마을, 비용)

1 → 2 : 비용 1	# dist[2]=INF 이므로 1로 갱신
1 → 4 : 비용 2	# dist[4]=INF 이므로 2로 갱신

갱신 후:

dist = [INF, 0, INF, INF, INF, INF] => dist = [INF, 0, 1, INF, 2, INF]
heap = [(0, 1)] => heap = [(1, 2), (2, 4)]	#(1번 마을로 부터의 거리, 현재 마을)

1번 마을 -> 2번 마을까지 거리 : 1

1번 마을 -> 4번 마을까지 거리 : 2

현재 가장 짧은 거리: 힙에서 첫번째 값을 기준

heap = [(1,2),(2,4)]
heapq.heappop(heap) #(1, 2)

가 나오므로 2번 마을 탐색

2) 2번 마을 탐색

2번과 연결된 마을 확인:

graph[2] = [(1, 1), (3, 3), (5, 2)]	#(2번 마을의 인접 마을, 비용)
→ 1 : 1 + 1 = 2 	# dist[1]=0 이므로 갱신 x
→ 3 : 1 + 3 = 4	# dist[3]=INF이므로 4로 갱신
→ 5 : 1 + 2 = 3	# dist[5]=INF이므로 3로 갱신

갱신 후:

dist = [INF, 0, 1, INF, 2, INF] => dist = [INF, 0, 1, 4, 2, 3]
heap = [(2, 4)] => heap = [(2, 4), (4, 3), (3, 5)]

즉 다음 탐색은:

heap = [(2, 4), (4, 3), (3, 5)]
heapq.heappop(heap) # (2, 4) => (비용, 마을)

가 나오므로 4번 마을 탐색

3) 4번 마을 탐색

4번과 연결된 마을 확인:

graph[4] = [(1, 2), (5, 2)]
4 → 1 : 2 + 2 = 4	# dist[1]=0 이므로 갱신 X
4 → 5 : 2 + 2 = 4	# dist[5]=3 이므로 갱신 X

근데 이미:

dist[1] = 0
dist[5] = 3

더 짧은 경로가 있으므로 갱신하지 않는다.

if next_dist < dist[next_node]:

조건을 만족하지 못하기 때문에 갱신 안 함, 힙에도 추가 안 함

dist = [INF, 0, 1, 4, 2, 3]

현재 가장 짧은 거리: 힙에서 첫번째 값을 기준

heap = [(3, 5),(4, 3)]
heapq.heappop(heap) #(3,5)

가 나오므로 5번 마을 탐색

4) 5번 마을 탐색

5번과 연결된 마을 확인:

graph[5] = [(2, 2), (4, 2), (3, 1)]

5 → 2 : 3 + 2 = 5   # dist[2]=1 이므로 갱신 X
5 → 4 : 3 + 2 = 5   # dist[4]=2 이므로 갱신 X
5 → 3 : 3 + 1 = 4   # dist[3]=4 이므로 갱신 X

조건을 만족하지 못하기 때문에 갱신 안 함, 힙에도 추가 안 함

dist = [INF, 0, 1, 4, 2, 3]

현재 가장 짧은 거리: 힙에서 첫번째 값을 기준

heap = [(4, 3)]
heapq.heappop(heap) # (4, 3)

가 나오므로 3번 마을 탐색

5) 3번 마을 탐색

3번과 연결된 마을 확인:

graph[3] = [(2, 3), (5, 1)]
3 → 2 : 4 + 3 = 7   # dist[2]=1 이므로 갱신 X
3 → 5 : 4 + 1 = 5   # dist[5]=3 이므로 갱신 X

조건을 만족하지 못하기 때문에 갱신 안 함, 힙에도 추가 안 함

최종 결과:

dist = [INF, 0, 1, 4, 2, 3]

heap = []

힙이 비었으므로 탐색 종료.
 
K = 3 이라면:

1, 2, 4, 5

총 4개 마을에 배달 가능하다.

7. 핵심 로직 요약

이 문제의 핵심은 가장 짧은 거리부터 탐색하면서 최단 거리 배열을 갱신하는 것 이다.

그래프를 인접 리스트로 만든다.
dist 배열에 최단 거리를 저장한다.
힙에서 가장 짧은 거리부터 꺼낸다.
연결된 마을 거리 갱신
더 짧은 경로면 힙에 다시 추가
최종적으로 K 이하인 마을 개수 계산

결국, 그래프 + heapq + 다익스트라 구조가 핵심이다.

8. 정리

처음에는 BFS처럼 보였는데, 실제로는 비용이 있는 최단 거리 문제 라는 걸 이해해야 했다.

특히 중요한 포인트는 이거였다.

탐색 순서가 노드 번호가 아니라 거리 기준이다

그래서 heapq를 사용하는 순간 다익스트라 구조가 만들어진다.

또 하나 느낀 점은 같은 마을이 힙에 여러 번 들어갈 수 있다 는 점이다.

그래서

if cur_dist > dist[cur_node]:
    continue

조건이 꼭 필요하다.

결국 이 문제는 다익스트라를 처음 익힐 때

왜 heap을 쓰는지
왜 거리 배열이 필요한지
왜 더 짧은 거리만 갱신하는지

를 이해하기 좋은 대표 문제였다.

프로그래머스 Lv.2 | Python | 게임 맵 최단거리

jjaehyeok — Fri, 8 May 2026 11:53:54 +0900

1. 문제 정보

프로그래머스

SW개발자를 위한 평가, 교육의 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프

programmers.co.kr

난이도: Lv.2

2. 문제 설명(요약)

게임 맵은 0과 1로 이루어진 2차원 배열이다.

1은 이동할 수 있는 칸
0은 벽이라 이동할 수 없는 칸

캐릭터는 왼쪽 위 (0, 0)에서 출발하고, 상대 팀 진영인 오른쪽 아래까지 이동해야 한다.

이때 상대 팀 진영까지 도착하는 최단 거리를 구하는 문제다. 도착할 수 없다면 -1을 반환한다.

3. 접근 기준

이 문제는 2차원 격자에서 최단 거리를 구하는 문제다.

각 칸에서 이동할 수 있는 방향은 다음 4가지다.

상, 하, 좌, 우

모든 이동 비용이 1로 동일하므로, 최단 거리는 BFS로 구하는 것이 적합하다.

DFS를 사용하면 한 경로를 끝까지 들어가기 때문에 처음 도착한 경로가 최단 거리라는 보장이 없다.

반면 BFS는 시작점에서 가까운 칸부터 차례대로 탐색하므로, 처음 목적지에 도착했을 때의 거리가 최단 거리다.

4. 사용한 패턴 / 알고리즘

BFS (너비 우선 탐색)

시작점에서 가까운 칸부터 탐색
최단 거리 문제에 적합
큐를 사용해서 탐색 순서를 관리

2차원 배열 탐색

행, 열 범위 체크
벽 여부 체크
방문 여부 체크

5. 핵심 아이디어

핵심은 maps 배열 자체에 이동 거리를 누적하는 것이다.

처음 시작 위치는 1이다. 다음 칸으로 이동할 때마다 현재 칸 값에 1을 더해서 저장한다.

예:

maps[nx][ny] = maps[x][y] + 1

이렇게 하면 별도의 거리 배열을 만들지 않아도 된다.

또 이미 방문한 칸은 다시 방문하지 않도록 해야 한다. 이 코드에서는 방문한 칸의 값을 거리 값으로 바꾸기 때문에, maps[nx][ny] == 1인 칸만 이동 대상으로 보면 된다.

6. 풀이 코드

from collections import deque

def solution(maps):
    n = len(maps)       # 행 개수
    m = len(maps[0])    # 열 개수

    # 상, 하, 좌, 우 이동 방향
    dx = [-1, 1, 0, 0]
    dy = [0, 0, -1, 1]

    # BFS를 위한 큐 생성
    q = deque()
    q.append((0, 0))  # 시작 위치

    while q:
        x, y = q.popleft()

        # 현재 위치에서 4방향 탐색
        for i in range(4):
            nx = x + dx[i]
            ny = y + dy[i]

            # 맵 범위를 벗어나면 제외
            if nx < 0 or nx >= n or ny < 0 or ny >= m:
                continue

            # 벽이거나 이미 방문한 칸이면 제외
            # 0: 벽
            # 1이 아닌 값: 이미 거리 값으로 갱신된 방문 칸
            if maps[nx][ny] != 1:
                continue

            # 다음 칸까지의 거리 저장
            maps[nx][ny] = maps[x][y] + 1

            # 다음 탐색 위치로 추가
            q.append((nx, ny))

    # 도착 지점 값이 1이면 도달하지 못한 것
    if maps[n - 1][m - 1] == 1:
        return -1

    # 도착 지점에 저장된 값이 최단 거리
    return maps[n - 1][m - 1]

6-1. 코드 추가 설명

이 코드에서 가장 중요한 부분은 다음이다.

maps[nx][ny] = maps[x][y] + 1

이 부분은 단순 방문 처리가 아니라:

현재 위치까지의 거리 + 1

을 다음 칸에 저장하는 역할이다.

예를 들어 현재 위치 값이 3이라면:

시작점에서 현재 칸까지 3칸 이동했다는 의미

이고,

다음 칸은:

3 + 1 = 4

가 된다.

즉, maps 배열 자체가:

이동 가능 여부 확인
방문 여부 확인
최단 거리 저장

세 가지 역할을 동시에 수행한다.

또 이 코드에서:

if maps[nx][ny] != 1:
    continue

조건도 중요하다.

처음 상태에서:

1 → 아직 방문하지 않은 이동 가능 칸
0 → 벽

이다.

그런데 방문하면:

maps[nx][ny] = maps[x][y] + 1

로 값이 바뀌기 때문에 더 이상 1이 아니다.

즉:

1이 아닌 값 = 이미 방문했거나 벽

이라는 의미가 된다.

그래서 별도의 visited 배열 없이도 방문 처리가 가능하다.

그리고 BFS에서 큐를 사용하는 이유도 중요하다.

q.popleft()

를 사용하면:

먼저 들어온 위치부터 탐색

하게 된다.

즉:

시작점에서 가까운 칸
그 다음 거리 칸
그 다음 거리 칸

순서로 탐색이 진행된다.

그래서 BFS는:

처음 도착한 경로가 곧 최단 거리

가 된다.

7. 핵심 로직 요약

이 문제의 핵심은 BFS로 가까운 칸부터 탐색하면서 거리 값을 누적하는 것이다.

시작점 (0, 0)을 큐에 넣는다.
큐에서 하나씩 꺼내 상하좌우를 확인한다.
범위를 벗어나거나 벽이면 제외한다.
아직 방문하지 않은 칸이면 현재 거리 + 1로 갱신한다.
도착 지점 값이 갱신되었다면 그 값이 최단 거리다.
도착하지 못했다면 -1을 반환한다.

결국, “큐 기반 BFS + 4방향 탐색 + 거리 누적” 이 흐름이 핵심이다.

8. 정리

처음 보면 단순히 길을 찾는 문제처럼 보이지만, 핵심은 “최단 거리”라는 조건이다.

이 조건 때문에 DFS보다 BFS가 더 자연스럽다.

특히 중요한 부분은 이거였다.

모든 이동 비용이 같으면 BFS가 최단 거리를 보장한다

또 별도의 visited 배열이나 distance 배열을 만들지 않고, 기존 maps에 거리 값을 직접 저장할 수 있다는 점도 중요했다.

결국 이 문제는 2차원 배열에서 BFS로 최단 거리를 구하는 기본 유형으로 정리할 수 있다.

프로그래머스 Lv.2 | Python | [1차] 뉴스 클러스터링

jjaehyeok — Fri, 8 May 2026 11:39:03 +0900

1. 문제 정보

프로그래머스

SW개발자를 위한 평가, 교육의 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프

programmers.co.kr

난이도: Lv.2

2. 문제 설명

여러 언론사에서 쏟아지는 뉴스, 특히 속보성 뉴스를 보면 비슷비슷한 제목의 기사가 많아 정작 필요한 기사를 찾기가 어렵다. Daum 뉴스의 개발 업무를 맡게 된 신입사원 튜브는 사용자들이 편리하게 다양한 뉴스를 찾아볼 수 있도록 문제점을 개선하는 업무를 맡게 되었다.

개발의 방향을 잡기 위해 튜브는 우선 최근 화제가 되고 있는 "카카오 신입 개발자 공채" 관련 기사를 검색해보았다.
카카오 첫 공채..'블라인드' 방식 채용카카오, 합병 후 첫 공채.. 블라인드 전형으로 개발자 채용카카오, 블라인드 전형으로 신입 개발자 공채카카오 공채, 신입 개발자 코딩 능력만 본다카카오, 신입 공채.. "코딩 실력만 본다"카카오 "코딩 능력만으로 2018 신입 개발자 뽑는다"

기사의 제목을 기준으로 "블라인드 전형"에 주목하는 기사와 "코딩 테스트"에 주목하는 기사로 나뉘는 걸 발견했다. 튜브는 이들을 각각 묶어서 보여주면 카카오 공채 관련 기사를 찾아보는 사용자에게 유용할 듯싶었다.

유사한 기사를 묶는 기준을 정하기 위해서 논문과 자료를 조사하던 튜브는 "자카드 유사도"라는 방법을 찾아냈다.
자카드 유사도는 집합 간의 유사도를 검사하는 여러 방법 중의 하나로 알려져 있다. 두 집합 A, B 사이의 자카드 유사도 J(A, B)는 두 집합의 교집합 크기를 두 집합의 합집합 크기로 나눈 값으로 정의된다.

예를 들어 집합 A = {1, 2, 3}, 집합 B = {2, 3, 4}라고 할 때, 교집합 A ∩ B = {2, 3}, 합집합 A ∪ B = {1, 2, 3, 4}이 되므로, 집합 A, B 사이의 자카드 유사도 J(A, B) = 2/4 = 0.5가 된다. 집합 A와 집합 B가 모두 공집합일 경우에는 나눗셈이 정의되지 않으니 따로 J(A, B) = 1로 정의한다.

자카드 유사도는 원소의 중복을 허용하는 다중집합에 대해서 확장할 수 있다. 다중집합 A는 원소 "1"을 3개 가지고 있고, 다중집합 B는 원소 "1"을 5개 가지고 있다고 하자. 이 다중집합의 교집합 A ∩ B는 원소 "1"을 min(3, 5)인 3개, 합집합 A ∪ B는 원소 "1"을 max(3, 5)인 5개 가지게 된다. 다중집합 A = {1, 1, 2, 2, 3}, 다중집합 B = {1, 2, 2, 4, 5}라고 하면, 교집합 A ∩ B = {1, 2, 2}, 합집합 A ∪ B = {1, 1, 2, 2, 3, 4, 5}가 되므로, 자카드 유사도 J(A, B) = 3/7, 약 0.42가 된다.

이를 이용하여 문자열 사이의 유사도를 계산하는데 이용할 수 있다. 문자열 "FRANCE"와 "FRENCH"가 주어졌을 때, 이를 두 글자씩 끊어서 다중집합을 만들 수 있다. 각각 {FR, RA, AN, NC, CE}, {FR, RE, EN, NC, CH}가 되며, 교집합은 {FR, NC}, 합집합은 {FR, RA, AN, NC, CE, RE, EN, CH}가 되므로, 두 문자열 사이의 자카드 유사도 J("FRANCE", "FRENCH") = 2/8 = 0.25가 된다.

입력 형식

입력으로는 str1과 str2의 두 문자열이 들어온다. 각 문자열의 길이는 2 이상, 1,000 이하이다.
입력으로 들어온 문자열은 두 글자씩 끊어서 다중집합의 원소로 만든다. 이때 영문자로 된 글자 쌍만 유효하고, 기타 공백이나 숫자, 특수 문자가 들어있는 경우는 그 글자 쌍을 버린다.
예를 들어 "ab+"가 입력으로 들어오면, "ab"만 다중집합의 원소로 삼고, "b+"는 버린다.
다중집합 원소 사이를 비교할 때, 대문자와 소문자의 차이는 무시한다. "AB"와 "Ab", "ab"는 같은 원소로 취급한다.

출력 형식

입력으로 들어온 두 문자열의 자카드 유사도를 출력한다. 유사도 값은 0에서 1 사이의 실수이므로, 이를 다루기 쉽도록 65536을 곱한 후에 소수점 아래를 버리고 정수부만 출력한다.

예제 입출력

3. 접근 기준

이 문제는 일반 집합 문제가 아니라 다중집합 문제다.

예를 들어 같은 원소가 여러 번 나오면, 그 개수까지 반영해야 한다.

A = [aa, aa, ab]
B = [aa, ab, ab]

이 경우:

교집합: aa 1개, ab 1개
합집합: aa 2개, ab 2개

처럼 단순히 set으로 처리하면 안 된다.

따라서 다음 기준으로 접근해야 한다.

문자열을 두 글자씩 자른다.
두 글자가 모두 알파벳인 경우만 사용한다.
대소문자는 구분하지 않으므로 소문자로 통일한다.
원소별 개수를 기준으로 교집합과 합집합을 계산한다.

문자열 처리 + Counter를 활용한 다중집합 계산 문제다.

4. 사용한 패턴 / 알고리즘

문자열 처리

두 글자씩 슬라이싱
알파벳 여부 확인
소문자 변환

Counter

원소별 개수 카운트
다중집합의 교집합과 합집합 계산

5. 핵심 아이디어

핵심은 Counter를 단순 카운트 용도가 아니라, 다중집합 연산 도구로 사용하는 것이다.

c1 = Counter(list1)
c2 = Counter(list2)

이렇게 만들면:

c1 & c2

는 각 원소 개수의 최솟값을 기준으로 교집합을 만든다.

c1 | c2

는 각 원소 개수의 최댓값을 기준으로 합집합을 만든다.

즉, 직접 min, max를 계산하지 않아도 Counter가 다중집합 기준으로 처리해준다.

6. 풀이 코드

from collections import Counter

# 문자열을 두 글자씩 끊어 다중집합 리스트로 만드는 함수
def make_multiset(s):
    s = s.lower()  # 대소문자 구분하지 않으므로 소문자로 통일
    result = []

    # 두 글자씩 확인해야 하므로 len(s) - 1까지 반복
    for i in range(len(s) - 1):
        a, b = s[i], s[i + 1]

        # 두 글자 모두 알파벳인 경우만 사용
        if a.isalpha() and b.isalpha():
            result.append(a + b)

    return result

def solution(str1, str2):
    # 두 문자열을 각각 다중집합 리스트로 변환
    list1 = make_multiset(str1)
    list2 = make_multiset(str2)

    # Counter는 각 원소가 몇 번 나왔는지 저장한다
    c1 = Counter(list1)
    c2 = Counter(list2)

    # Counter의 & 연산은 다중집합의 교집합이다
    # 같은 원소가 있으면 더 작은 개수를 선택한다
    inter = sum((c1 & c2).values())

    # Counter의 | 연산은 다중집합의 합집합이다
    # 같은 원소가 있으면 더 큰 개수를 선택한다
    union = sum((c1 | c2).values())

    # 두 집합이 모두 공집합이면 유사도는 1
    if union == 0:
        return 65536

    # 자카드 유사도 * 65536 후 소수점 버림
    return int((inter / union) * 65536)

이 코드에서 가장 중요한 부분은 다음이다.

inter = sum((c1 & c2).values())
union = sum((c1 | c2).values())

Counter는 원소별 개수를 저장하는 딕셔너리처럼 보이지만, &, | 연산을 사용하면 다중집합의 교집합과 합집합을 바로 구할 수 있다.

예를 들어:

c1 = Counter(["aa", "aa", "ab"])
c2 = Counter(["aa", "ab", "ab"])

이면:

c1 & c2

결과는:

Counter({"aa": 1, "ab": 1})

이고,

c1 | c2

결과는:

Counter({"aa": 2, "ab": 2})

이다. 따라서 values()를 합치면 각각 교집합 크기와 합집합 크기가 된다.

번외) Counter 특성을 몰랐을 때의 풀이

처음에는 Counter의 &, | 연산을 몰랐기 때문에 교집합과 합집합 원소를 직접 구한 뒤, min, max로 개수를 계산했다

from collections import Counter

# 문자열을 두 글자씩 끊어 다중집합 리스트 생성
def make_multiset(s):
    result = []

    # 두 글자씩 확인
    for i in range(len(s) - 1):

        # 현재 두 글자 추출
        pair = s[i:i + 2]

        # 두 글자가 모두 알파벳인 경우만 사용
        if pair.isalpha():
            result.append(pair.lower())  # 대소문자 통일

    return result


def solution(str1, str2):

    # 두 문자열을 다중집합 형태로 변환
    list1 = make_multiset(str1)
    list2 = make_multiset(str2)

    # 각 원소 개수 카운트
    count1 = Counter(list1)
    count2 = Counter(list2)

    # 중복 제거한 원소 집합 생성
    keys1 = set(count1.keys())
    keys2 = set(count2.keys())

    # 교집합 후보
    common_keys = keys1 & keys2

    # 합집합 후보
    all_keys = keys1 | keys2

    # 교집합 크기 계산
    # 같은 원소 개수 중 작은 값 사용
    intersection = 0
    for key in common_keys:
        intersection += min(count1[key], count2[key])

    # 합집합 크기 계산
    # 같은 원소 개수 중 큰 값 사용
    union = 0
    for key in all_keys:
        union += max(count1[key], count2[key])

    # 두 집합이 모두 공집합인 경우
    if union == 0:
        return 65536

    # 자카드 유사도 계산
    return int((intersection / union) * 65536)

두 풀이의 차이

첫 번째 풀이도 정답은 맞다. 다만 Counter의 다중집합 연산을 직접 구현한 형태에 가깝다.

차이는 다음과 같다.

직접 풀이
- set으로 교집합, 합집합 후보를 구함
- 각 원소마다 min, max를 직접 계산
- 다중집합 개념을 코드로 풀어쓴 형태
Counter 활용 풀이
- Counter & Counter로 교집합 계산
- Counter | Counter로 합집합 계산
- 내부에서 min, max 처리를 대신 해줌

한 줄로 정리하면:

직접 풀이: 다중집합 연산을 직접 구현한 코드
Counter 풀이: Counter 기능으로 다중집합 연산을 처리한 코드

7. 핵심 로직 요약

이 문제의 핵심은 문자열을 다중집합으로 바꾼 뒤, 교집합과 합집합 크기를 개수 기준으로 계산하는 것이다.

문자열을 두 글자씩 자른다.
두 글자가 모두 알파벳인 경우만 사용한다.
소문자로 통일한다.
Counter로 원소별 개수를 센다.
&로 교집합 크기를 구한다.
|로 합집합 크기를 구한다.
자카드 유사도를 계산한다.

결국, “문자열 파싱 + 다중집합 처리 + 자카드 유사도 계산” 이 흐름이 핵심이다.

8. 마치며

처음에는 set을 쓰면 될 것처럼 보였지만, 이 문제는 같은 원소가 여러 번 나오는 다중집합 문제였다.

그래서 단순 집합 연산으로 처리하면 개수가 사라져서 틀릴 수 있다.

풀면서 가장 크게 느낀 점은:

Counter는 단순히 개수 세는 용도만 있는 게 아니다

라는 점이었다.

특히 Counter의 &, | 연산이 다중집합의 교집합, 합집합을 처리해준다는 걸 알면 코드가 훨씬 짧아진다.

결국 이 문제는 문자열 처리보다도, 다중집합을 어떻게 코드로 표현할지가 핵심인 문제였다.

프로그래머스 Lv.2 | Python | 전화번호 목록

jjaehyeok — Fri, 8 May 2026 11:18:19 +0900

1. 문제 정보

프로그래머스

SW개발자를 위한 평가, 교육의 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프

programmers.co.kr

난이도: Lv.2

2. 문제 설명

전화번호부에 적힌 전화번호 중, 한 번호가 다른 번호의 접두어인 경우가 있는지 확인하려 합니다.전화번호가 다음과 같을 경우, 구조대 전화번호는 영석이의 전화번호의 접두사입니다.

구조대 : 119박준영 : 97 674 223지영석 : 11 9552 4421

전화번호부에 적힌 전화번호를 담은 배열 phone_book 이 solution 함수의 매개변수로 주어질 때, 어떤 번호가 다른 번호의 접두어인 경우가 있으면 false를 그렇지 않으면 true를 return 하도록 solution 함수를 작성해주세요.

제한 조건

phone_book의 길이는 1 이상 1,000,000 이하입니다.
- 같은 전화번호가 중복해서 들어있지 않습니다.
- 각 전화번호의 길이는 1 이상 20 이하입니다.

3. 접근 기준

처음에는 모든 번호를 서로 비교해야 할 것처럼 보인다. 하지만 실제로는 모든 조합을 비교할 필요가 없다.

핵심은 문자열을 정렬하면:

접두어 관계인 문자열끼리 서로 가까워진다

는 점이다.

예를 들어:

["119", "1195524421", "97674223"]

처럼 정렬되면,
접두어 여부는 인접한 문자열끼리만 확인해도 된다.

문자열 정렬
바로 옆 문자열끼리 접두어 확인

이 흐름으로 접근하면 된다.

4. 사용한 패턴 / 알고리즘

정렬 (Sorting)

문자열 사전순 정렬

문자열 함수

startswith() 활용

5. 핵심 아이디어

핵심은 정렬하면 접두어 관계인 문자열이 서로 붙는다는 점이다.

예:

["12", "123", "567", "88"]

정렬 후:

["12", "123", "567", "88"]

여기서 "123"은 "12"로 시작한다.

즉:

"123".startswith("12")

만 확인하면 된다. 전체를 전부 비교할 필요 없이, 정렬 후 바로 옆 문자열만 비교하면 접두어 여부를 찾을 수 있다.

6. 풀이 코드

def solution(phone_book):

    # 문자열 기준 정렬
    # 접두어 관계인 문자열끼리 가까워진다
    phone_book.sort()

    # 인접한 번호끼리만 비교
    for i in range(1, len(phone_book)):

        # 현재 문자열이 이전 문자열로 시작하면
        # 이전 번호가 접두어라는 뜻
        if phone_book[i].startswith(phone_book[i - 1]):
            return False

    return True

이 코드의 핵심은:

startswith()

함수와 정렬 아이디어다.

6-1) 왜 정렬하는가?

예를 들어 다음 번호들이 있다고 하자.

["119", "97674223", "1195524421"]

정렬하면:

["119", "1195524421", "97674223"]

이렇게 된다.

즉, 접두어 관계인 문자열들이 서로 붙게 된다

그래서 전체를 다 비교하지 않아도 현재 문자열 vs 바로 이전 문자열 비교하면 된다.

6-2) startswith란?

문자열.startswith(문자열)

형태로 사용한다.

예:

"1195524421".startswith("119")

결과:

True

즉, 현재 문자열이 특정 문자열로 시작하는가? 를 확인하는 함수다.

6-3) 왜 인접한 값만 비교하는가?

정렬 상태에서는 접두어 가능성이 있는 문자열이 반드시 근처에 위치한다.

["12", "123", "1235", "88"]

여기서 "12"와 관련 있는 문자열은 바로 뒤에 몰려 있다.

그래서:

phone_book[i]
phone_book[i - 1]

만 비교해도 충분하다.

7. 핵심 로직 요약

이 문제의 핵심은 정렬 후 인접한 문자열만 비교해서 접두어 여부를 확인하는 것이다.

전화번호를 문자열 기준으로 정렬한다.
인접한 번호끼리 비교한다.
현재 번호가 이전 번호로 시작하면 False 반환
끝까지 없으면 True 반환

결국, “정렬 + startswith 활용” 이 구조가 핵심이다.

8. 정리

처음 보면 모든 번호를 전부 비교해야 할 것처럼 느껴진다.
근데 실제로는 정렬 하나로 문제 구조가 단순해진다.

특히 핵심은 이거였다.

정렬하면 접두어 후보가 서로 붙는다

이 아이디어를 떠올리면 복잡한 탐색 없이 바로 해결할 수 있다.

또 startswith() 함수도 문자열 문제에서 굉장히 자주 나온다.

결국 이 문제는 문자열 비교 문제라기보다, 정렬을 이용해 비교 범위를 줄이는 문제라는 느낌이 강했다.

번외) 해시(Set)를 활용한 풀이

정렬 말고도 set을 이용해서 풀 수 있다.

def solution(phone_book):

    # 전화번호 존재 여부를 빠르게 확인하기 위해 set 사용
    # set의 in 연산은 평균 O(1)
    phone_set = set(phone_book)

    # 모든 전화번호 순회
    for phone in phone_book:

        # 자기 자신 전체 번호는 제외해야 하므로
        # len(phone) 전까지만 확인
        for i in range(1, len(phone)):

            # 앞부분(prefix) 생성
            prefix = phone[:i]

            # 접두어가 실제 전화번호 목록에 존재하면
            if prefix in phone_set:
                return False

    return True

이 풀이의 핵심

예를 들어:

"1195524421"

라는 번호가 있으면:

처럼 앞부분을 계속 잘라본다.

그리고:

if prefix in phone_set

를 통해 해당 접두어가 실제 전화번호 목록에 존재하는지 확인한다.

즉:

접두어 직접 생성
set으로 빠르게 존재 여부 확인

이 흐름이다.

정렬 풀이와의 차이

정렬 풀이:

접두어 후보만 비교

정렬 후 인접한 값만 확인
코드가 짧고 직관적
실전에서 더 자주 사용

set 풀이:

접두어를 직접 생성해서 확인

해시 활용 연습 가능
접두어 개념이 더 직접적으로 보임
문자열 슬라이싱 반복 발생

Kubernetes Secret 생성과 Pod에서 사용하는 방법

jjaehyeok — Thu, 7 May 2026 17:17:04 +0900

1. Secret이란?

Secret은 민감한 정보를 저장하는 Kubernetes 리소스다.

https://www.in4it.com/blog/kubernetes-secrets-management.html

DB 비밀번호
API Key
Access Token
인증 정보

Kubernetes에서 Secret과 ConfigMap이 Pod에 연결되고, 이후 Kubernetes API Server를 통해 ETCD에 저장되는 흐름을 나타낸다.

먼저 사용자는 Secret 또는 ConfigMap 리소스를 생성한다.

Secret
→ 비밀번호, API Key 같은 민감 정보 저장
ConfigMap
→ 일반 설정 값 저장

이후 Pod는 필요한 Secret이나 ConfigMap을 참조하여 값을 사용하게 된다.

그리고 Kubernetes 내부에서는:

Pod → API Server → ETCD

구조로 리소스 정보가 저장·관리된다.

여기서:

API Server
→ Kubernetes의 중앙 관리 컴포넌트
ETCD
→ Kubernetes 클러스터 상태 정보를 저장하는 Key-Value 저장소

역할을 담당한다.

다만 중요한 점은, Kubernetes Secret은 기본적으로 완전한 암호화 저장 기능이라기보다 민감 정보를 일반 YAML과 분리해서 관리하기 위한 기능에 가깝다는 점이다.

Secret 값은 내부적으로 base64 인코딩되어 저장되며, 이는 암호화(encryption)가 아니라 단순 인코딩(encoding) 방식이다.

즉 Secret만으로 강력한 보안이 보장되는 것은 아니며, 실제 운영 환경에서는:

ETCD Encryption
RBAC 권한 관리
외부 Secret Manager

같은 추가 보안 구성을 함께 사용하는 경우가 많다.

아래처럼 Pod YAML에 직접 작성하는 경우

env:
- name: DB_PASSWORD
  value: "1234"

GitHub 노출 가능성
YAML 공유 시 정보 유출
운영 환경 보안 문제

가 발생할 수 있다. 그래서 Kubernetes에서는 Secret으로 분리해서 관리한다.

2. Secret 생성 방법

가장 기본적인 방식은 kubectl create secret generic 명령을 사용하는 것이다.

2-1) 단일 값 저장

kubectl create secret generic db-secret \
  --from-literal=password=1234

의미:

Secret 이름: db-secret
key: password
value: 1234

2-2) 여러 값 저장

kubectl create secret generic db-secret \
  --from-literal=username=admin \
  --from-literal=password=1234

3. Secret 확인 방법

3-1) Secret 목록 확인

kubectl get secret

출력:

여기서:

Opaque

는 일반 Secret 타입을 의미한다.

3-2) 상세 정보 확인

kubectl describe secret db-secret

출력:

Data
====
password: 4 bytes

실제 값은 보안상 바로 출력되지 않는다.

그러나 base64로 디코딩을 하는경우 바로 출력이 된다. 그렇기 때문에 누구나 해독이 가능하다.

4. Pod에서 Secret 사용하는 방법

Secret은 보통 두 가지 방식으로 사용한다.

환경 변수(Environment Variable)
Volume 마운트

5. 환경 변수로 사용하는 방법

먼저 Secret을 생성한다.

kubectl create secret generic db-secret \
  --from-literal=username=admin \
  --from-literal=password=1234

이후 Pod YAML에서 Secret 값을 환경 변수로 연결한다.

5-1) Pod YAML

apiVersion: v1
kind: Pod
metadata:
  name: secret-pod
spec:
  containers:
  - name: nginx
    image: nginx
    env:
    - name: DB_USERNAME
      valueFrom:
        secretKeyRef:
          name: db-secret
          key: username

    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: db-secret
          key: password

5-2) 코드 설명

위 YAML은 db-secret에 저장된 값을 컨테이너 내부 환경 변수로 주입하는 구조다.

예를 들어 아래 부분:

- name: DB_USERNAME

는 컨테이너 내부 환경 변수 이름이다.

즉 애플리케이션 내부에서는:

echo $DB_USERNAME

처럼 사용할 수 있다. 그리고 실제 값은 아래에서 가져온다.

secretKeyRef:
  name: db-secret
  key: username

각 항목 의미는 다음과 같다.

name: db-secret
→ 사용할 Secret 이름
key: username
→ Secret 내부에서 가져올 값

즉 Kubernetes가:

db-secret 안의 username 값

을 읽어서:

DB_USERNAME=admin

형태로 컨테이너 내부에 자동 주입한다.

최종적으로 컨테이너 내부에서는:

DB_USERNAME=admin
DB_PASSWORD=1234

환경 변수를 사용할 수 있게 된다.

5-3) 환경변수 확인

Pod 내부에서 확인할 수 있다.

kubectl exec -it secret-pod -- env

출력 예시:

DB_USERNAME=admin
DB_PASSWORD=1234

6. Volume으로 사용하는 방법

Secret을 파일처럼 마운트할 수도 있다.

6-1) Pod YAML

apiVersion: v1
kind: Pod
metadata:
  name: secret-volume-pod
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - name: secret-volume
      mountPath: "/etc/secret"

  volumes:
  - name: secret-volume
    secret:
      secretName: db-secret

6-2) Secret 파일 확인

Pod 내부에서 확인:

kubectl exec -it secret-volume-pod -- ls /etc/secret

출력:

password
username

파일 내용 확인:

kubectl exec -it secret-volume-pod -- cat /etc/secret/password

출력:

즉 Secret 값이 파일 형태로 저장된다.

7. Secret이 내부적으로 저장되는 방식

Secret은 내부적으로 base64 인코딩되어 저장된다.

예:

echo -n "1234" | base64

출력:

MTIzNA==

중요한 점은: base64는 암호화가 아니라 단순 인코딩이라는 점이다. Secret만으로 완전한 보안이 보장되는 것은 아니다.

8. 마치며

Kubernetes에서는 비밀번호나 API Key 같은 민감 정보를 직접 YAML에 작성하기보다 Secret 리소스로 분리해서 관리한다.

그리고 Pod에서는:

환경 변수
Volume

방식으로 Secret 값을 주입해 사용한다.

이 구조를 이해하면:

왜 ConfigMap과 Secret이 분리되는지
왜 운영 환경에서 Secret 관리가 중요한지
Kubernetes가 설정과 실행 환경을 어떻게 분리하는지

를 자연스럽게 이해할 수 있다.

jjaehyeok 님의 블로그

프로그래머스 Lv.3 | Python | 순위

1. 문제 정보

2. 문제 설명

3. 접근 기준

4. 사용한 패턴 / 알고리즘

5. 핵심 아이디어

6. 풀이 코드

6-1. 코드 추가 설명

7. 핵심 로직 요약

8. 정리

미니 PC 서버 Kubernetes 배포 (2) - Airflow 기반 데이터 파이프라인 동작 검증

1. 문제 배경

2. 목표

3. Airflow 구성 및 실행

3-2) airflow hook 설정

4. 데이터 흐름 확인

4-1) Kafka 데이터 유입 확인

Kafka Pod 접속

Topic 데이터 확인

4-2) Spark Streaming 처리 확인

4-3) Redis 반영 확인

4-4) MySQL 반영 확인

MySQL Pod 접속

Database 확인

테이블 확인

데이터 확인

4-5) S3 저장 확인

5. 핵심 포인트

6. 전체 구조 정리

7. 마치며

미니 PC 서버 Kubernetes 배포 (1) - Kafka · Redis · MySQL 기반 서비스 배포

1. 문제 배경

2. 목표

3. 배포 대상 서비스

4. 리소스 설계 기준

4-1) StatefulSet

4-2) Deployment

4-3) Service

4-4) Job

5. 서비스 배포

6. Kafka Topic 초기화, Spark Streaming 실행 및 S3 접근 키 설정

6-1) Kafka Topic 초기화 Job 실행

6-2) Kafka Topic 생성 확인

6-3) aws s3 ACCESS_KEY_ID 설정

6-4) Spark Streaming 서비스 실행

7. 실행 상태 확인

8. 핵심 포인트

9. 마치며

다음 글

미니 PC 서버 Kubernetes 배포 준비 - Namespace · Secret · Spark Operator 구성

1. 문제 배경

2. 목표

3. Docker Registry 기반 이미지 관리

4. Helm 설치

4-1) Helm 설치

4-2) 설치 확인

5. Spark Operator 설치

5-1) Helm 저장소 등록

5-2)Spark Operator 설치

5-3) 왜 Operator를 사용하는가

6. Namespace 구성

7. Secret 구성

8. ConfigMap 구성

8-1) SQL 스크립트 ConfigMap

8-2) Airflow Pod Template ConfigMap

8-3) Spark Streaming 코드 ConfigMap

8-4) 왜 ConfigMap을 사용하는가

9. ServiceAccount 구성

10. StorageClass 및 PVC 확인

10-1) 왜 중요한가

11. 마치며

다음 글

미니 PC 서버에 k3s 기반 Kubernetes 운영 환경 구성

1. 문제 배경

2. 목표

3. kubectl 설치 및 서버 환경 구성

3-1) Kubernetes 저장소 등록

3-2) kubectl 설치

4. k3s 기반 Kubernetes 클러스터 구성