예르미의 코딩노트

[KubeCon Japan 2026] 첫날 키노트 (2) : 일본 기업들의 실전 사례

예르미(yermi) — Sun, 23 Aug 2026 23:52:22 +0900

첫날 키노트 후반부입니다. 앞 글에서 AI 워크로드가 부딪히는 자원의 한계를 다뤘다면, 이번에는 실제로 Kubernetes 위에 AI 플랫폼과 대규모 인프라를 올린 사례 네 편을 정리합니다.

두 개씩 짝지어 읽으면 흐름이 잘 보입니다. 앞의 둘은 AI 플랫폼, 뒤의 둘은 선언적 대규모 운영입니다.

왜 멀티테넌시인가 : Preferred Networks

Preferred Networks — Building a Multi-Tenant AI Platform

Building a Multi-Tenant AI Platform with the CNCF Ecosystem — Aya Igarashi (Preferred Networks)

10분을 받은 이 발표가 첫날 키노트 중 밀도가 가장 높았습니다.

발표자는 2016년부터 Kubernetes를 썼다고 합니다. 당시는 IaC 전환과 마이크로서비스가 화두였고 선언적 배포가 매력이었죠. 10년이 지나 AI가 인프라 요구사항을 근본적으로 바꿨는데도 Kubernetes는 여전히 기반으로 남아 있습니다. 이유로 강한 커뮤니티와 CRD·오퍼레이터로 대표되는 확장성을 꼽았습니다.

PFN은 AI 제품부터 자체 AI 칩(MN-Core)까지 수직 통합하고, 그 컴퓨팅 파워를 Kubernetes 기반 플랫폼으로 사내외 연구자에게 제공합니다. 즉 멀티테넌트 환경입니다.

왜 멀티테넌시인가? 이유는 비용입니다. AI 플랫폼 총비용의 대부분이 액셀러레이터인데 희소하고 비싸서 유휴 상태로 둘 수 없습니다. 그래서 공유합니다.

Balancing Cost and Isolation — 네임스페이스 격리부터 전용 클러스터까지

그런데 공유는 트레이드오프죠. 많이 공유할수록 격리가 약해집니다. Kubernetes는 여기서 스펙트럼을 줍니다. 왼쪽은 논리적 격리에 저비용, 오른쪽은 강한 격리에 높은 오버헤드. 정답은 없고 요구사항이 결정합니다.

PFN은 네임스페이스 격리와 전용 노드를 섞은 하이브리드를 골랐고, 그 대가로 나머지를 직접 만들어야 했습니다.

경계(Boundary): 실제 테넌트는 조직-프로젝트 계층 구조인데 네임스페이스는 평평합니다. 그래서 HNC(Hierarchical Namespace Controller)를 쓰는데, 업스트림이 아카이브돼서 자체 포크를 유지 중이라고 합니다. 그리고 경계는 벽 하나가 아니라 층으로 쌓습니다. 네트워크 계층은 NetworkPolicy, API 계층은 어드미션 컨트롤, 컨트롤러는 watch 범위 제한, 그 외 스택 전반에 추가 제약.

공정성(Fairness): 경계만으로는 한 테넌트가 다 써버리는 걸 못 막습니다. Kueue로 컴퓨트 쿼터를 관리하고 테넌트별 리소스 제한을 둡니다. 그리고 컴퓨트만이 아니라 오브젝트 생성 개수도 제한합니다. 단일 테넌트가 컨트롤 플레인에 과부하를 주지 않도록 하는 건데, 자원 쿼터만 생각하기 쉬운 지점입니다.

효율(Efficiency): AI 학습은 다수 파드가 지속적으로 통신·동기화하므로 동시에 시작해야 합니다. 일부만 뜨면 나머지가 유휴 대기죠. 그래서 갱 스케줄링을 자체 스케줄러 플러그인으로 구현했습니다(업스트림도 개발 중). 그리고 노드마다 자유 공간이 잘게 파편화되면 총량이 충분해도 큰 파드가 못 들어가므로 타이트 패킹을 합니다.

Maximizing Cost Efficiency — 다 함께 시작하기(갱 스케줄링)와 빈 패킹

이 세 가지가 "멀티테넌트 AI 플랫폼을 만든다"는 문장을 실제 엔지니어링 항목으로 번역해줍니다. 사내 플랫폼을 고민하는 입장에서 그대로 체크리스트로 쓸 수 있겠다 싶었습니다.

마무리는 이랬습니다. 10년 뒤에는 지금 상상 못 할 워크로드를 돌리게 될 텐데, 확장성·생태계·커뮤니티 셋이 있으면 플랫폼이 계속 적응할 수 있다는 것.

3시간을 3분으로 : Subaru

How Subaru Accelerated AI Model Development for Next-Generation EyeSight with Kubernetes — Ryoji Kobayashi (Subaru)

스바루는 차세대 아이사이트의 인식 정확도를 높이기 위해 AI 모델을 사내에서 개발하고 있습니다. 그런데 개발이 확대되면서 문제가 쌓였습니다.

거대한 ML 컨테이너 이미지
수동 배포 작업
점점 복잡해지는 머신러닝 워크플로

이를 풀기 위해 Harbor, Envoy Gateway, MetalLB, Argo CD, Helm, Argo Workflows 조합으로 Kubernetes 기반 AI 모델 개발 플랫폼을 구축했습니다. 결과가 명료합니다.

컨테이너 이미지 pull 시간 60배 단축 — 약 3시간에서 3분으로

컨테이너 이미지 pull 시간이 약 3시간에서 3분으로(60배)
25개 애플리케이션 정의에 GitOps 적용
머신러닝 워크플로 자동화

이 사례는 올해 KubeCon Japan 케이스 스터디 콘테스트 수상작이기도 합니다. 오프닝 키노트에서 Bryce가 직접 축하 멘트를 하기도 했고요.

앞의 PFN 사례와 붙여 보면 흥미롭습니다. 자체 AI 칩까지 만드는 조직과, 기존 개발 프로세스를 개선하려는 조직이 결국 같은 CNCF 도구 상자를 쓴다는 점이요. 규모와 성숙도는 다른데 선택지는 같습니다.

15명이 1,300개 클러스터를 : LY Corporation

Ten Years Later — 팀 규모를 늘리지 않고 스케일만 키웠다

From 5 to 1,300+ Clusters: Declarative Scaling for Private Kubernetes — Shota Yoshimura (LY Corporation)

3분 동안 나온 숫자가 이렇습니다.

1,300개 이상의 클러스터, 40,000개 이상의 노드, 그리고 플랫폼 엔지니어 15명.

슬라이드 마지막 줄이 이걸 1인 기준으로 환산해줍니다.

"오늘 플랫폼 엔지니어 한 명이 90개 클러스터를 운영합니다."

일본 최대 규모의 프라이빗 Kubernetes 플랫폼 중 하나입니다. OpenStack 기반 프라이빗 인프라 위에서 Kubernetes 커스텀 리소스와 컨트롤러로 인프라를 선언적으로 정의하고, 클러스터 프로비저닝·스케일링·업그레이드·복구를 자동화했습니다.

결과로 든 세 가지입니다.

프로비저닝이 수 주에서 수 시간으로
무중단 운영 확보
Kubernetes를 제품 팀을 위한 셀프서비스 플랫폼으로 전환

같은 발표자가 별도 브레이크아웃에서 28분짜리 심화 발표도 진행했습니다. 그쪽은 안전한 scale-in을 다루는데, 대부분의 발표가 확장(scale-out)에 집중하는 것과 달리 온프레미스에서는 유휴 노드가 하드웨어 조달과 랙 용량에 직결되므로 축소도 중요하다는 관점이었습니다.

Argo CD 하나로 5,000개 앱을 : Hyundai AutoEver

Data Can't Cross Borders — 데이터 주권 규제가 그대로 아키텍처가 된다

Out of the Box, at Multi-Region Scale: How Hyundai Scales Its Platform — Jaewoo Choi (Hyundai AutoEver)

바로 다음이 현대차그룹 사례였습니다. 자체 프라이빗 클라우드 hCloud 위에서 글로벌 플랫폼을 운영하고 CI/CD 파이프라인에 오픈소스 도구를 제공합니다.

단일 Argo CD 인스턴스가 전 세계 300개 이상 클러스터에 걸쳐 5,000개 이상의 Application 관리
매달 수백 개씩 증가
멀티리전 Harbor 레지스트리는 5,000개 이상 저장소에 60,000개 이상 아티팩트를 3개 리전에 복제

마지막 항목의 이유가 데이터 주권 규제와 성능을 동시에 맞추기 위한 설계라는 점이 눈에 띄었습니다. 글로벌 제조사가 부딪히는 제약이 그대로 아키텍처에 반영돼 있었습니다.

발표자가 Argo CD 메인테이너이기도 해서, 도구를 쓰는 쪽과 만드는 쪽을 동시에 하는 사례이기도 합니다. 한국 발표자가 KubeCon Japan 키노트에 서는 걸 현장에서 보는 것도 반가웠고요.

마치며

뒤의 두 발표가 던지는 공통 메시지는 분명했습니다. 이 규모에서 사람이 손으로 관리하는 건 애초에 선택지가 아니고, 선언적 정의와 컨트롤러 패턴이 유일한 답이라는 것.

그리고 첫날 키노트 전체를 한 문장으로 정리하면 이렇습니다.

클라우드 네이티브가 AI 아래로 내려갔다.

AI가 클라우드 네이티브를 대체하는 게 아니라, AI 워크로드가 돌아갈 바닥을 클라우드 네이티브가 깔고 있다는 것. Bryce의 표현을 빌리면 지난 10년이 분산 워크로드를 돌릴 시스템을 만드는 기간이었다면, 다음 10년은 그 위에서 AI라는 새 워크로드를 받아내는 기간이 되는 셈입니다.

다음 글부터는 첫날 오후 브레이크아웃 세션을 하나씩 다룹니다. 먼저 GitOps의 진실 공급원을 두고 벌어진 토론, "OCI is not Git" 세션입니다.

[오늘가챠] 비동기(@Async)의 늪: 외부 통신 중 마주친 JPA Detached Entity 해결기

예르미(yermi) — Sat, 22 Aug 2026 16:40:23 +0900

업로드된 이미지를 Cloudinary(미디어 서버)에 전송하고, AI(Gemini API)로 분석하는 작업은 네트워크 상황에 따라 2~5초가량 소요됩니다. 유저를 멍하니 5초 동안 멈춰둔 채 기다리게 할 수 없어, 응답성을 높이고자 로직을 Spring @Async를 활용해 비동기로 분리하려다 영속성 컨텍스트 지옥에 빠진 트러블슈팅 경험입니다.

JPA Detached Entity 문제 흐름

1. 섣부른 비동기 처리의 시도

요청이 오면 "업로드 대기열에 등록되었습니다"라는 성공 응답을 클라이언트에 0.1초 만에 내려주고, 무거운 작업은 백그라운드 스레드에 던져버리도록 설계했습니다.

// ❌ 처음 시도한 코드 (에러 발생)
@Async // 새로운 백그라운드 스레드풀에서 실행
public void processUploadAsync(User user, byte[] file) {
    // 1. 3~5초가 걸리는 외부 API 통신 (Blocking)
    String url = cloudinaryService.upload(file);

    // 2.   에러 발생 포인트!
    Card card = new Card(user, url); 
    cardRepository.save(card);
}

결과는 대실패였습니다. 업로드는 잘 되었으나 마지막에 DB 저장 시 Detached Entity 에러가 발생하며 롤백되었습니다.

org.hibernate.LazyInitializationException: 
  could not initialize proxy [com.gacha.user.entity.User#1] - no Session

2. 원인 파악: 스레드(ThreadLocal)와 OSIV의 한계

Spring Data JPA는 기본적으로 웹 요청(Request)을 처리하는 단일 스레드(ThreadLocal)에 트랜잭션과 영속성 컨텍스트(EntityManager)를 바인딩하여 묶어둡니다. (Open Session In View 패턴 포함)

[시간순 흐름]
Main Thread ──────────────────────────────────────────
 ┌────────────────────────────────────┐
 │  트랜잭션 열림 + 영속성 컨텍스트     │
 │  1. User 조회 (Managed 상태)       │
 │  2. @Async 호출 (User 객체 전달)    │
 │  3. HTTP 200 OK 반환               │
 └────────────────────────────────────┘
   ↑ 트랜잭션 종료, 영속성 컨텍스트 닫힘

Async Thread ──────────────────────────────────────────
           ┌─────────────────────────────────────┐
           │  4. Cloudinary 업로드 (3초 대기)     │
           │  5. user.getCards()... →   에러!    │
           │     User는 이미 Detached 상태!       │
           └─────────────────────────────────────┘

메인 스레드에서 유저(User) 객체를 조회해 비동기 메서드로 파라미터로 넘겼습니다.
메인 스레드는 즉시 200 OK를 반환하고 트랜잭션을 종료하며 영속성 컨텍스트를 닫아버립니다.
새로운 백그라운드 스레드에서 수 초의 외부 API 통신이 끝난 뒤, 넘겨받은 User 객체를 이용해 새로운 릴레이션을 맺으려 시도합니다.
그러나 JPA 입장에서 해당 User는 이미 관리 대상이 아닌 준영속(Detached) 상태의 껍데기 객체입니다. 따라서 저장을 거부한 것입니다.

3. 해결책: 트랜잭션 분리와 식별자(ID) 전달 패턴

엔티티 객체 자체를 다른 스레드의 파라미터로 넘기는 것은 시한폭탄을 넘기는 것과 같습니다. 객체 대신 엔티티의 식별자(PK ID)만 넘기고, 비동기 스레드 내부에서 완전히 독립된 새로운 트랜잭션을 열어 다시 로드(Proxy 초기화)하도록 리팩토링했습니다.

// ✅ 해결된 코드 — ID만 전달하고 새 트랜잭션에서 재조회

@Async
public void processUploadAsync(Long userId, byte[] file) {
    // 외부 API 통신: 여기는 트랜잭션을 걸지 않아 커넥션 낭비를 막음
    String url = cloudinaryService.upload(file);

    // DB 저장: 새로운 스레드 안에서 별도 트랜잭션 개시
    saveCardTransaction(userId, url);
}

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void saveCardTransaction(Long userId, String url) {
    // 새로운 영속성 컨텍스트에 엔티티를 새롭게 로드(Attached)
    User user = userRepository.findById(userId).orElseThrow();
    Card card = new Card(user, url); 
    cardRepository.save(card); // ✅ 정상 저장!
}

4. 마무리

비동기 처리는 유저의 응답 시간을 비약적으로 개선하지만, JPA의 스레드 로컬 바인딩 특성과 생명주기를 완벽하게 이해하지 못하면 런타임 에러의 원흉이 됩니다. 비동기 큐잉을 할 때는 파라미터로 순수한 식별자(Long)나 불변 객체(DTO)만 전달해야 한다는 개발 패턴을 뼈저리게 배울 수 있었습니다.

[KubeCon Japan 2026] 첫날 키노트 (1) : 무한한 수요와 유한한 컴퓨트⚡

예르미(yermi) — Thu, 20 Aug 2026 23:42:25 +0900

참관 후기와 현장에서 만난 사람들 이야기에 이어, 이제 세션 리뷰를 시작합니다.

첫날 키노트는 9시 30분 오프닝부터 10시 25분 클로징까지 약 한 시간 동안 일곱 개 발표가 숨 가쁘게 이어졌습니다. 3분짜리 라이트닝 형식이 대부분이라 개별로 나누기보다 주제별로 묶어 읽는 편이 낫다고 판단했고, 두 편으로 나눠 정리합니다.

이번 글에서는 오프닝 키노트와 "자원의 한계"를 다룬 두 발표를 다룹니다.

메인홀 오프닝 — WELCOME! ようこそ

오프닝 : "Keep Cloud Native Moving"

Linux Foundation의 Jonathan Bryce(Executive Director)와 Chris Aniszczyk(CTO)가 25분을 채웠습니다.

Aniszczyk가 정리한 CNCF 현황 중 눈에 띈 숫자입니다.

지난 6개월 사이 생태계 개발자가 1,500만 명에서 약 2,000만 명으로 40% 성장
그중 일본 개발자가 약 95만 명, CNCF 프로젝트 기여도 세계 10위
Kyverno, OpenTelemetry, Kubeflow가 나란히 졸업
NVIDIA가 플래티넘 멤버로 합류하며 CNCF 프로젝트용 GPU에 400만 달러 기부

일본, CNCF 기여도 세계 10위

일본 관련해서는 「State of Cloud Native in Japan」 리포트를 별도로 발간했다고 소개하며 Keycloak 기여가 두드러진다고 언급했는데, 둘째 날 Hitachi 키노트를 보고 빈말이 아니었다는 걸 알았습니다.

뒤집힌 그래프 하나

A Shift in AI Workloads — 추론 67% 대 학습 33%, 그리고 2030년 추론 전용 93.3GW

이어서 Bryce가 AI 이야기를 받았습니다. 이 파트의 그래프 한 장이 이번 KubeCon 전체를 관통하는 메시지였습니다.

AI 컴퓨트 배분이 뒤집혔습니다. 2년 전에는 학습 2/3에 추론 1/3이었는데 올해 정확히 반대가 됐습니다. McKinsey 추정으로는 2030년까지 추론 전용 컴퓨트만 93.3GW가 필요한데, 지금 전 세계 모든 컴퓨트를 합친 것보다 큰 규모입니다.

그리고 이어진 문장이 핵심입니다. 추론 워크로드의 성격 — 상시 가동, 성능 보장, 버스트 트래픽 대응 — 은 클라우드 네이티브 커뮤니티가 지난 10년간 풀어온 문제와 정확히 같다는 것.

Kubernetes는 AI를 위해 설계되지 않았습니다. 분산 시스템을 위해 설계됐고 AI가 마침 그런 워크로드였을 뿐이라는 관점이 이번 행사 전체에서 가장 자주 반복된 프레임이었습니다.

또 하나 인상적이었던 건 효율 개선이 하드웨어보다 소프트웨어 계층에서 나오고 있다는 지적이었습니다. vLLM, Kubernetes 같은 오픈소스가 지금 가장 큰 이득을 만들어내고 있다는 것. 그래서 오픈소스 커뮤니티의 작업이 AI를 지속 가능하고 효율적으로 만드는 데 중요하다는 논지로 이어졌습니다.

구체적 사례로 llm-d 프로젝트를 소개했습니다. 가장 널리 쓰이는 추론 엔진인 vLLM을 수평 확장하는 프로젝트인데, 캐싱과 지능형 라우팅 덕분에 GPU에 단순 로드밸런싱하는 것보다 수 배 나은 성능이 나온다고 합니다.

그리고 AI Conformance 프로그램. Kubernetes 컨포먼스가 100개 넘는 제품에 일관성을 준 것처럼, AI 워크로드도 어느 환경에서 띄우든 일관되게 동작하도록 만들겠다는 계획입니다.

♾️ 무한한 에이전트, 유한한 Kubernetes

Reality of AI Agent — 에이전트가 스폰하는 파드들

Infinite Agents, Finite Kubernetes — Mohammad Mikal Bin Amrul Halim Gan (SoftBank)

3분인데 문제 정의가 선명했습니다.

이제 우리는 단독 AI 애플리케이션이 아니라 서브 에이전트를 스폰하고 머신 속도로 서로 통신하는 자율 에이전트 생태계를 호스팅하게 됩니다. 인프라 관점에서는 완전히 새로운 워크로드 프로파일입니다. 무거운 연산 파드가 다수 생성되고, 즉시 처리하고, 사라집니다. 이 변동성이 컨트롤 플레인에 그대로 부하가 됩니다.

그런데 수요는 무한한데 데이터센터는 무한히 지을 수 없습니다. 공간, 전력, 자본에 엄격하게 캡이 걸려 있습니다. 그래서 자원 효율이 유일한 활로라는 것.

여기서 짚은 역설이 이 발표의 핵심입니다.

역사적으로 격리를 강화하면 자원 효율이 떨어졌습니다. 보안을 위해 환경을 나누면 사용률이 급락하고 비용이 치솟았죠. 그런데 AI 시대에는 보안을 타협할 수 없습니다. 그러니 격리를 유지하면서 동시에 효율의 정점을 노려야 한다는 게 지금의 엔지니어링 과제라는 겁니다.

제시한 방향은 이렇습니다. 여러 워크스페이스를 그냥 공유 환경에 모으면 경계가 겹치면서 자원 경합, 지연 스파이크, 보안 취약점이 서로 번져 들어갑니다. 대신 워크로드마다 하드 인포스드 경계를 두되 하드웨어를 채울 만큼 조밀하게 패킹해야 한다는 것.

그리고 여러 시설로 확장하면 한쪽은 한계에 부딪히고 다른 쪽은 놀게 됩니다. 그 경계 규격을 인프라 전반에 표준화하면 보안 태세를 유지한 채 워크로드를 시설 간 동적으로 재배치할 수 있다는 게 결론이었습니다.

마무리 문장이 이 세션 전체를 요약합니다. "유한한 하드웨어, 무한한 능력."

️ GPU 중심 인프라로의 전환

Dynamic Resource Composition for GPU-centric infrastructure — CoHDI

The Next Evolution of Kubernetes: GPU-Centric Infrastructure for AI Workloads — Takao Indoh (Fujitsu)

바로 다음 순서였던 후지쯔는 같은 문제를 하드웨어 쪽에서 풀었습니다.

AI 플랫폼을 둘러싼 환경이 매일 바뀌는데 핵심 이슈는 자원 비용 급등입니다. GPU 비용, 메모리 비용, 전력 비용이 동시에 오릅니다. 이런 제약 아래서 가용 자원을 최적으로 쓰려면 CPU 중심 인프라에서 GPU 중심 인프라로 전환이 필요하다는 진단입니다.

후지쯔의 답은 동적 자원 구성(Dynamic Resource Composition) 입니다.

소프트웨어 계층 — CoHDI: AI 워크로드에 맞춰 하드웨어를 동적으로 스케일 업/다운하는 오픈소스
하드웨어 계층 — 컴포저블 하드웨어: 요구에 따라 하드웨어를 자유롭게 조합

이 두 계층을 합쳐 워크로드 기반으로 자원 사용과 전력 소비를 최적화한다는 구상입니다.

프로젝트 소식도 있었습니다. CoHDI가 CNCF Sandbox 프로젝트로 승인됐고 인큐베이팅 승격이 목표라고 합니다. 향후 과제로 다른 오픈소스와의 통합, 지원 디바이스 확대를 들었고요. 3층 솔루션 쇼케이스의 Fujitsu 부스에서도 같은 이야기를 하고 있었습니다.

마치며

두 발표를 붙여놓고 보면 흥미롭습니다. SoftBank는 소프트웨어에서 경계를 표준화하는 접근이고, 후지쯔는 하드웨어에서 구성 자체를 유연하게 만드는 접근입니다. 방향은 정반대인데 같은 벽을 양쪽에서 두드리고 있습니다.

그 벽이 무엇인지도 분명했습니다. 전력, 공간, 자본. 클라우드 네이티브 컨퍼런스 첫날 오전부터 이런 물리적 제약 이야기가 나온다는 게 이번 행사의 성격을 잘 보여줬다고 생각합니다.

다음 글에서는 첫날 키노트 후반부, 일본 기업들이 실제로 Kubernetes 위에 AI와 대규모 플랫폼을 올린 사례 네 편을 다룹니다.

[K8s] 제로 트러스트를 향한 클러스터 내부 보안: Network Policy와 RBAC

예르미(yermi) — Wed, 19 Aug 2026 22:54:54 +0900

이번 글에서는 K8s 내부에 제로 트러스트(Zero Trust) 보안 모델을 구축하기 위한 Network Policy와 RBAC을 다룹니다.

1. 기본값은 "모두 허용": K8s 네트워크의 위험한 출발점

K8s의 기본 네트워크 설정은 모든 Pod 간 통신을 허용합니다. 같은 클러스터에 있는 프론트엔드 Pod, 백엔드 Pod, 데이터베이스 Pod가 서로 아무런 제약 없이 접근할 수 있습니다. 이는 개발 초기에는 편리하지만, 프로덕션 환경에서는 치명적인 보안 취약점입니다.

프론트엔드 Pod가 해킹당하면 DB Pod에 직접 접근 가능
관련 없는 네임스페이스의 Pod끼리도 자유롭게 통신

2. Network Policy: Pod 간 방화벽

Network Policy는 K8s에서 Pod 간의 트래픽을 제어하는 방화벽 규칙입니다.

# DB Pod는 backend 라벨이 붙은 Pod의 5432 포트 접근만 허용
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-allow-backend-only
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: backend
      ports:
        - protocol: TCP
          port: 5432

핵심 규칙

Default Deny: Network Policy가 하나라도 적용되면, 해당 Pod는 명시적으로 허용된 트래픽만 받습니다.
라벨 기반 선택: IP가 아닌 Pod의 라벨(Label)로 대상을 지정하므로, Pod가 재생성되어 IP가 바뀌어도 정책이 유지됩니다.
네임스페이스 격리: namespaceSelector를 통해 다른 네임스페이스에서의 접근을 완전히 차단할 수 있습니다.

Network Policy: Pod 간 허용/차단 트래픽 흐름

3. RBAC: "누가 K8s API를 호출할 수 있는가"

Network Policy가 Pod 간의 네트워크 통신을 제어한다면, RBAC(Role-Based Access Control)는 K8s API 서버에 대한 접근 권한을 제어합니다. "이 개발자는 Pod를 조회할 수 있지만 삭제는 못 한다", "이 CI/CD 서비스 계정은 Deployment만 업데이트할 수 있다" 같은 규칙을 설정합니다.

RBAC의 4가지 핵심 오브젝트:

오브젝트	범위	역할
Role	네임스페이스	특정 네임스페이스 내 권한 정의
ClusterRole	클러스터 전체	클러스터 전역 권한 정의
RoleBinding	네임스페이스	사용자/그룹에 Role을 연결
ClusterRoleBinding	클러스터 전체	사용자/그룹에 ClusterRole을 연결

# 백엔드 개발자에게 production 네임스페이스의 Pod 조회 권한만 부여
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]   # 조회만 가능, 삭제/수정 불가

RBAC 계층 구조: User → RoleBinding → Role → 리소스 권한

4. 요약: 제로 트러스트 보안 체크리스트

계층	도구	원칙
네트워크	Network Policy	명시적으로 허용하지 않은 Pod 간 통신은 모두 차단
API 접근	RBAC	최소 권한 원칙(Least Privilege) — 필요한 권한만 부여
데이터 전송	Cilium WireGuard	Pod 간 통신 자동 암호화

제로 트러스트의 핵심은 "클러스터 내부라고 해서 신뢰하지 않는다"입니다. Network Policy로 Pod 간 통신을 최소화하고, RBAC으로 API 접근을 제한하는 것이 클라우드 네이티브 보안의 기본입니다.

[오늘가챠] 성능 끌어올리기: CompletableFuture를 이용한 병렬 처리

예르미(yermi) — Sat, 15 Aug 2026 16:36:14 +0900

유저가 사진을 촬영하고 업로드할 때, 백엔드에서는 크게 2가지 무거운 작업이 일어납니다.

Cloudinary 서버로 원본 이미지 전송 (수 초 소요)
GPS 위경도를 한글 지명으로 변환하는 Reverse Geocoding API 호출 (수 초 소요)

이 두 가지 작업을 순차적으로 실행하면 유저는 화면이 멈춘 채로 10초 가까이 기다려야 합니다. 이를 해결하기 위해 자바의 CompletableFuture를 도입한 경험입니다.

순차 실행 vs 병렬 실행 비교

1. 기존 방식의 문제점 (순차 실행)

I/O 바운드 작업들이 직렬로 연결되어 유저 경험(UX)을 심각하게 훼손하고 있었습니다.

// 기존의 느린 코드 (직렬 실행)
String imageUrl = cloudinaryClient.upload(request.file().getBytes()); // 3초 대기
String locationName = reverseGeocode(lat, lng);                       // 3초 대기
// 총 6초 대기 후 DB 저장...

2. CompletableFuture를 활용한 병렬 실행

두 작업은 서로 의존성이 없습니다. 사진이 업로드되는 동안 위치 정보를 알아내면 됩니다. 실제 PhotoService.createDraft 메서드의 병렬 처리 코드입니다.

// PhotoService.java — createDraft() 핵심 부분

// 프라이버시 보호를 위해 GPS 좌표를 소수점 2자리로 블러 처리
Double blurredLat = Math.round(request.latitude() * 100.0) / 100.0;
Double blurredLng = Math.round(request.longitude() * 100.0) / 100.0;

// ⚡ Cloudinary 업로드 + Reverse Geocoding 병렬 실행
CompletableFuture<String> uploadFuture =
    CompletableFuture.supplyAsync(() -> {
        try { return cloudinaryClient.upload(request.file().getBytes()); }
        catch (Exception e) { throw new RuntimeException("이미지 업로드에 실패했습니다.", e); }
    });

CompletableFuture<String> geoFuture =
    CompletableFuture.supplyAsync(() -> reverseGeocode(blurredLat, blurredLng));

String imageUrl;
String locationName;
try {
    // 병렬로 실행된 두 스레드의 결과를 최대 30초, 10초까지만 대기하고 합침
    imageUrl = uploadFuture.get(30, TimeUnit.SECONDS);
    locationName = geoFuture.get(10, TimeUnit.SECONDS);
} catch (Exception e) {
    throw new RuntimeException("업로드 처리 중 오류가 발생했습니다.", e);
}

Reverse Geocoding 구현 상세

GPS 좌표를 한글 주소로 변환하는 로직도 직접 구현했습니다. OpenStreetMap의 무료 API(Nominatim)를 활용합니다.

// PhotoService.java — reverseGeocode() 발췌
private String reverseGeocode(Double lat, Double lng) {
    if (lat == null || lng == null) return "알 수 없는 장소";
    try {
        String url = String.format(Locale.US,
            "https://nominatim.openstreetmap.org/reverse"
            + "?format=json&lat=%f&lon=%f&zoom=18&addressdetails=1", lat, lng);

        Map<String, Object> address = // API 응답에서 address 추출

        // 시 > 구 > 동 순서로 한글 지명 조합
        String city = (String) address.getOrDefault("city",
                address.getOrDefault("state", null));
        String district = (String) address.getOrDefault("borough",
                address.getOrDefault("city_district", null));
        String dong = (String) address.getOrDefault("neighbourhood",
                address.getOrDefault("quarter",
                address.getOrDefault("suburb", null)));

        // "서울특별시 강남구 역삼동" 형태로 조합
        StringBuilder sb = new StringBuilder();
        if (city != null) sb.append(city);
        if (district != null) sb.append(" ").append(district);
        if (dong != null && !dong.equals(district)) sb.append(" ").append(dong);
        return sb.length() > 0 ? sb.toString() : "알 수 없는 장소";
    } catch (Exception e) {
        log.warn("Reverse geocoding failed for lat:{}, lng:{}", lat, lng, e);
        return "알 수 없는 장소";
    }
}

3. 프론트엔드 측 추가 최적화: 이미지 리사이즈

백엔드의 병렬 처리 외에도, 프론트엔드에서 이미지를 업로드 전에 Canvas API로 리사이즈하여 네트워크 전송량을 줄였습니다.

// Gacha.jsx — 브라우저 Canvas를 이용한 이미지 리사이즈
const resizeImage = (file) => new Promise((resolve) => {
    const img = new Image();
    const reader = new FileReader();
    reader.onload = (e) => {
        img.onload = () => {
            const MAX = 1200;
            let { width, height } = img;
            if (width > MAX || height > MAX) {
                const ratio = Math.min(MAX / width, MAX / height);
                width = Math.round(width * ratio);
                height = Math.round(height * ratio);
            }
            const canvas = document.createElement('canvas');
            canvas.width = width;
            canvas.height = height;
            canvas.getContext('2d').drawImage(img, 0, 0, width, height);
            canvas.toBlob((blob) => resolve(blob), 'image/jpeg', 0.85);
        };
        img.src = e.target.result;
    };
    reader.readAsDataURL(file);
});

원본 12MB 사진 → Canvas 리사이즈 → JPEG 85% → 약 300KB로 압축 후 전송. 모바일 환경에서 업로드 속도가 체감적으로 크게 향상되었습니다.

4. 결과와 마무리

두 작업을 병렬 스레드로 밀어 넣음으로써, 전체 소요 시간은 두 작업 중 '가장 오래 걸리는 작업의 시간'으로 획기적으로 줄어들었습니다. 6초가 걸리던 작업이 3초 안팎으로 끝났습니다. 또한 uploadFuture.get(30, TimeUnit.SECONDS) 처럼 타임아웃을 꼼꼼하게 설정하여, 외부 API 서버(Cloudinary, Geocoding)가 죽더라도 백엔드의 스레드가 무한정 블로킹(Deadlock)되는 재앙을 막아냈습니다.

[K8s] K8s 네트워크의 진화와 성능 최적화: kube-proxy의 한계와 eBPF/Cilium

예르미(yermi) — Wed, 12 Aug 2026 22:50:37 +0900

이번 글에서는 K8s 내부 네트워킹의 심장부인 kube-proxy가 대규모 환경에서 어떤 한계에 부딪히는지 살펴보고, 이를 근본적으로 해결하는 eBPF 기반의 Cilium이 왜 차세대 K8s 네트워크 표준으로 떠오르고 있는지 알아봅니다.

1. kube-proxy와 iptables의 한계

K8s에서 Service로 트래픽을 보내면, 실제로는 각 노드에서 실행 중인 kube-proxy가 트래픽을 적절한 Pod로 전달합니다. 전통적으로 kube-proxy는 iptables 규칙을 사용합니다. 문제는 규모가 커지면 iptables 규칙이 선형으로 급증한다는 것입니다.

Service 1,000개 × 각 Service당 Pod 10개 = iptables 규칙 수만 개
패킷 하나가 도착할 때마다 이 규칙들을 순차적으로(O(n)) 탐색

실제 사례: 대규모 클러스터에서 Service 수가 5,000개를 넘어가면
iptables 규칙 업데이트에만 수 분이 소요되는 현상이 보고되었습니다.

kube-proxy(iptables) vs eBPF 패킷 처리 경로 비교

2. eBPF: 리눅스 커널 안에서 동작하는 프로그래밍 가능한 네트워크

eBPF(extended Berkeley Packet Filter)는 리눅스 커널의 네트워크 스택 안에 사용자 정의 프로그램을 주입할 수 있는 기술입니다.

iptables는 커널의 netfilter 훅에서 규칙 체인을 순차 평가하지만, eBPF는 네트워크 스택 훨씬 앞단(XDP/tc)에서 패킷을 가로채 처리
O(n) 선형 탐색 대신 해시맵 기반 O(1) 조회로 성능이 Service 수에 영향을 받지 않음
패킷이 불필요한 네트워크 스택 계층을 건너뛸 수 있어 레이턴시 감소

물론 kube-proxy도 손 놓고 있었던 것은 아닙니다. iptables 외에 커널 해시테이블 기반의 IPVS 모드를 제공해 대규모 환경의 탐색 비용을 줄였고, 최근에는 nftables 모드도 추가됐습니다.

다만 어느 쪽이든 커널 네트워크 스택 전체를 타야 한다는 구조적 제약은 남습니다. eBPF는 바로 이 지점을 건드립니다.

3. Cilium: eBPF 위에 세운 K8s 네트워크 플랫폼

Cilium은 eBPF를 K8s 환경에서 쉽게 활용할 수 있도록 만든 CNI(Container Network Interface) 플러그인이자 종합 네트워크 플랫폼입니다.

Cilium이 제공하는 핵심 기능:

kube-proxy 완전 대체: iptables 없이 eBPF만으로 Service 라우팅 처리
L3/L4/L7 Network Policy: HTTP 경로나 gRPC 메서드 단위의 정교한 보안 정책
투명 암호화(WireGuard): Pod 간 트래픽을 애플리케이션 수정 없이 자동 암호화
사이드카 없는 서비스 메시: Istio처럼 각 Pod에 Envoy 사이드카를 붙이지 않고도 mTLS, 트래픽 관측 가능
Hubble: 네트워크 플로우를 실시간으로 시각화하는 관측 도구

Cilium 아키텍처: eBPF 기반 K8s 네트워크 플랫폼

4. 요약: kube-proxy에서 Cilium으로의 전환

항목	kube-proxy (iptables)	Cilium (eBPF)
패킷 처리	커널 netfilter 규칙 체인 순차 탐색	커널 레벨 해시맵 O(1)
대규모 성능	Service 5,000+ 시 규칙 업데이트 병목	Service 수에 무관한 일정 성능
암호화	별도 설정 필요	WireGuard 내장 투명 암호화
관측성	제한적	Hubble로 네트워크 플로우 실시간 시각화

현재 GKE는 Dataplane V2를 통해, AKS는 "Azure CNI Powered by Cilium" 옵션을 통해 Cilium 기반 네트워킹을 제공하는 등 주요 매니지드 K8s 서비스들이 eBPF 데이터플레인을 채택하기 시작했으며, CNCF 컨퍼런스에서도 eBPF/Cilium 관련 세션이 해마다 증가하는 추세입니다.

[KubeCon Japan 2026] 거기서 만난 사람들 : 부스와 세션장에서 이어진 인연

예르미(yermi) — Sun, 9 Aug 2026 18:12:31 +0900

지난 참관 후기에서 예고했던 이야기를 풀 차례입니다. 이번 KubeCon + CloudNativeCon Japan 2026에서 세션만큼이나, 어쩌면 세션보다 더 기억에 남는 건 사람들이었습니다. sysdig 부스에서 만난 한국인 엔지니어, Grafana 부스의 Alloy 개발자, 그리고 Java Champion 살라보이(Salaboy)까지 세 번의 만남을 기록합니다.

1️⃣ sysdig 부스에서 만난 한국인 엔지니어 : "이제는 CNAPP의 시대"

"Runtime security for AI coding agents"를 내건 sysdig 부스에서 뜻밖에 한국인 엔지니어를 만났습니다. 한국어로 편하게 Falco와 Prempti에 대한 설명을 들을 수 있었는데, 특히 인상 깊었던 건 이 말이었습니다.

"AI 시대에는 DevSecOps를 넘어, 이제 CNAPP(Cloud-Native Application Protection Platform)의 시대로 가고 있다."

빌드 파이프라인에 보안을 끼워 넣는 수준을 넘어, 클라우드 네이티브 애플리케이션 전체를 하나의 플랫폼에서 보호하는 방향으로 패러다임이 이동하고 있다는 것.

AI 코딩 에이전트가 만들어내는 코드가 폭증하는 시대에 런타임에서의 가시성과 통제가 왜 중요해지는지, 부스의 캐치프레이즈가 그대로 이해되는 대화였습니다. 대화 끝에는 한국에서 같이 식사 한번 하자는 약속까지 하고 헤어졌습니다. 이번 쿠버콘이 남긴 소중한 인연입니다.

2️⃣ Grafana 부스의 Alloy 개발자 : 온프레미스 운영자의 오랜 궁금증

LGTM 스택으로 옵저버빌리티를 구축하면서 온프레미스 환경에서는 Ansible로 Alloy를 설치·배포하고 있는데, 늘 마음 한구석에 "이게 표준적인 방법이 맞나?" 하는 의문이 있었습니다. 마침 부스에 Alloy 개발자가 있어 직접 물어봤습니다.

돌아온 답은 명쾌했습니다. "온프레미스라면 Ansible을 쓰는 게 표준인 것 같다."

쿠버네티스 환경에서는 코드 한 줄이면 Alloy가 설치되지만, 온프레미스에서는 그게 불가능하니 구성 관리 도구로 배포하는 것이 자연스러운 접근이라는 것. 개발 당사자에게 "지금 방식이 맞다"는 확인을 받으니, 그간의 운영 방식에 대한 확신이 생겼습니다. 문서로는 얻기 힘든, 콘퍼런스 현장에서만 가능한 종류의 답이었습니다.

3️⃣ Java Champion : "Spring AI로 만들어 와라, 리뷰해주겠다"

Dash0 소속으로 이번 행사에 스피커로 참여한 Java Champion 살라보이(Mauricio Salatino)의 세션이 끝난 후, 용기를 내어 평소 고민을 질문했습니다.

오픈소스 프로젝트가 거의 다 Go나 Python으로 만들어져 있는데,
Java 개발자는 어떻게 기여를 시작해야 하나요?

그러자 마치 고인물이 반가운 뉴비를 만난 듯 눈을 반짝이며 기뻐하더니, Spring AI를 소개해주었습니다. 이걸로 직접 프로젝트를 만들어보라고, 만들어 오면 자기가 리뷰해주겠다는 약속과 함께요.

Java/Spring 백엔드 개발자로서 오픈소스 기여의 진입점을 고민하던 저에게는 이번 쿠버콘 최고의 수확이라 해도 과언이 아닌 순간이었습니다. 숙제가 생겼으니, 이 후속 이야기는 언젠가 별도의 글로 돌아오겠습니다.

마치며

CNAPP이라는 화두, 운영 방식에 대한 확신, 그리고 오픈소스 기여라는 숙제까지 세 번의 대화가 각각 하나씩을 남겼습니다. 영어가 완벽하지 않아도, 기술이라는 공통 언어가 있으니 대화는 어떻게든 이어집니다. 다음에 글로벌 콘퍼런스에 가시는 분이 있다면, 초록 스티커를 붙이고 부스와 세션장에서 딱 한 번만 용기 내보시길 권합니다.

다음 글에서는 이틀간 직접 들은 세션들을 하나하나 리뷰합니다. 참관 준비 글에서 픽했던 세션들이 실제로 어땠는지, 현업 백엔드 개발자 관점의 솔직한 후기로 이어가겠습니다.

[오늘가챠] 앱 생태계를 지켜라: dHash와 SHA-256을 활용한 이미지 중복 방어

예르미(yermi) — Sat, 8 Aug 2026 16:32:04 +0900

유저가 TCG 카드 재화를 쉽게 얻기 위해 똑같은 풍경 사진이나 유행하는 인터넷 밈(Meme) 이미지를 무한정 반복해서 업로드한다면 어떻게 될까요? 앱 생태계의 희소성은 무너지고 서버 스토리지 비용만 폭발하게 됩니다. 이를 막기 위해 구축한 2단계 필터링 알고리즘 도입기입니다.

dHash 알고리즘 흐름도

1. 1차 방어: SHA-256 무결성 검사

가장 기초적이고 확실한 중복 방지 로직은 파일 자체가 동일한지 검사하는 것입니다. 유저가 이미지를 업로드하면, 백엔드에서 이미지 바이너리의 SHA-256 암호학적 해시값을 추출하여 DB에 저장합니다.

// 파일 내용이 완전히 1바이트라도 같으면 동일한 해시가 나옴
MessageDigest digest = MessageDigest.getInstance("SHA-256");
byte[] hashBytes = digest.digest(fileBytes);
String fileHash = bytesToHex(hashBytes);

// DB 조회: 이 해시가 이미 존재하면 업로드 차단
if (photoMapper.existsByFileHash(fileHash)) {
    throw new IllegalStateException("이미 업로드된 파일입니다.");
}

하지만 암호학적 해시는 파일의 '내용 무결성'을 확인하는 데 쓰이므로, 이미지 화질이 조금 낮아지거나 스마트폰 상단바가 포함된 채 캡처되기만 해도 완전히 다른 해시값을 뱉어내어 어뷰징을 막지 못했습니다.

SHA-256의 한계:
  원본 고양이.jpg       → 해시: a3f2b1c9...
  동일 고양이(살짝 크롭) → 해시: 7e8d4a1f...   ← 완전히 다른 값!
  동일 고양이(필터 적용) → 해시: 1b9c5e72...   ← 역시 다른 값!

2. 2차 방어: Perceptual Hash (dHash) 도입

이에 시각적 유사성을 판단하여 인간의 눈에 똑같아 보이는 이미지를 차단하는 dHash(Difference Hash) 알고리즘을 구현해 적용했습니다.

dHash 알고리즘의 동작 원리

리사이징 및 흑백화: 이미지를 9x8 해상도(총 72픽셀)의 초소형 사이즈로 강제 리사이징하고 그레이스케일(흑백)로 변환합니다. (색상과 비율 왜곡 무시)
명암 비교: 인접한 가로 픽셀 8개 쌍을 비교합니다. 왼쪽 픽셀이 오른쪽 픽셀보다 밝으면 1, 아니면 0을 부여합니다.
64비트 정수 생성: 총 8개 행 × 8개 비교 = 64번의 비교 결과가 나오며, 이를 비트 연산하여 하나의 64비트 정수(long)로 압축해 DB에 저장합니다.

// dHash 생성 핵심 로직 — ImageService.java
public long computeDHash(BufferedImage image) {
    // Step 1: 9x8 해상도로 강제 리사이징 (가로 9, 세로 8)
    BufferedImage resized = resize(image, 9, 8);
    // Step 2: 그레이스케일 변환
    BufferedImage grayImage = toGrayscale(resized);

    // Step 3: 인접 픽셀 명암 비교 → 64비트 해시 생성
    long hash = 0;
    for (int y = 0; y < 8; y++) {
        for (int x = 0; x < 8; x++) {
            int leftPixel = grayImage.getRGB(x, y);
            int rightPixel = grayImage.getRGB(x + 1, y);
            hash = hash << 1;
            if (getBrightness(leftPixel) > getBrightness(rightPixel)) {
                hash |= 1; // 왼쪽이 더 밝으면 비트를 1로 세팅
            }
        }
    }
    return hash; // 64비트 long 타입 정수
}

3. 해밍 거리(Hamming Distance) 계산

이제 새 이미지가 올라오면, 기존 DB에 저장된 64비트 해시값들과 해밍 거리(두 비트열에서 서로 다른 비트의 개수)를 계산합니다. 자바에서는 Long.bitCount(hash1 ^ hash2) XOR 연산을 통해 1밀리초 만에 매우 빠르게 계산할 수 있습니다.

// 해밍 거리 계산 — 단 한 줄로 유사도 판별
int hammingDistance = Long.bitCount(existingHash ^ newHash);

if (hammingDistance <= 5) {
    // 해밍 거리 5 이하 = 약 90% 이상 일치 → 유사 이미지로 판정
    throw new IllegalStateException("유사한 이미지가 이미 존재합니다.");
}

dHash 유사도 판별 예시:
  원본 고양이      dHash: 1011001010110100... (64bit)
  살짝 크롭한 고양이 dHash: 1011001010110101... (64bit)
  → XOR 결과: 0000000000000001... → bitCount = 1
  → 해밍 거리 1 (≤ 5) → ⛔ 업로드 거부!

  완전히 다른 풍경   dHash: 0100110101001011... (64bit)
  → XOR 결과: 1111111111111111... → bitCount = 32
  → 해밍 거리 32 (> 5) → ✅ 업로드 허용

수백 번의 테스트 결과, 해밍 거리가 5 이하(약 90% 이상 일치)라면 원본을 약간 잘라냈거나 인스타그램 필터를 씌운 정도의 '유사 이미지'로 판별할 수 있었습니다. 이 임계값(Threshold)을 초과하면 과감히 업로드를 거부(Reject)했습니다.

4. 마무리

크롭(Crop) 되거나 필터가 씌워진 꼼수 업로드를 dHash 알고리즘으로 완벽하게 방어해 냈습니다. 머신러닝 기반의 무거운 이미지 분석(CNN 등) 모델을 띄우지 않고도, 단순하고 원초적인 비트 연산 알고리즘만으로 서비스 생태계를 보호한 값진 아키텍처 결정이었습니다.

[K8s] 트래픽 폭주에 대비하는 K8s 자동 확장 전략: HPA와 KEDA

예르미(yermi) — Wed, 5 Aug 2026 22:44:10 +0900

이번 글에서는 K8s가 제공하는 자동 확장(Auto-Scaling) 메커니즘인 HPA(Horizontal Pod Autoscaler)와, 그 한계를 넘어선 이벤트 기반 확장 프레임워크 KEDA를 비교합니다.

1. HPA: CPU/메모리 기반의 기본 자동 확장

HPA는 K8s에 기본 내장된 오토스케일러입니다. 동작 원리는 직관적입니다.

metrics-server가 각 Pod의 CPU/메모리 사용량을 주기적으로 수집
HPA 컨트롤러가 목표치(target)와 비교 (예: "CPU 평균 50% 유지")
목표치를 초과하면 Pod를 늘리고(Scale-Out), 밑돌면 줄입니다(Scale-In)

# HPA 설정 예시
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-server-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50   # CPU 평균 50% 유지

HPA 자동 확장: 트래픽 급증 시 Pod 수 자동 조절

HPA의 한계

리액티브(Reactive) 방식: 이미 CPU가 올라간 후에야 반응합니다. 트래픽 스파이크에 대한 대응이 늦을 수 있습니다.
메트릭 제한: 기본적으로 CPU와 메모리만 기준으로 삼습니다. "카프카 큐에 메시지가 1만 개 쌓였으니 컨슈머를 늘려라"는 판단이 불가능합니다.
0→1 스케일링 불가: 최소 1개의 Pod가 항상 떠 있어야 합니다. 트래픽이 없는 야간에도 리소스를 소비합니다.

2. KEDA: 이벤트 기반의 차세대 오토스케일러

KEDA(Kubernetes-based Event Driven Autoscaler)는 HPA의 한계를 극복하기 위해 등장한 CNCF 프로젝트입니다. 핵심 차이는 "무엇을 기준으로 스케일링하는가"입니다.

기준	HPA	KEDA
스케일링 트리거	CPU, 메모리 (내부 메트릭)	Kafka 큐 깊이, HTTP 요청률, Cron, AWS SQS, Redis 등 60+ 외부 이벤트
Zero-to-One	❌ 최소 1개 Pod 필수	✅ 트래픽 없으면 0개까지 축소, 이벤트 발생 시 1개부터 기동
동작 방식	리액티브 (이미 올라간 후)	프로액티브 (외부 신호 기반 선제 대응)

# KEDA ScaledObject 예시: Kafka 큐 깊이 기반 스케일링
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: order-consumer-scaler
spec:
  scaleTargetRef:
    name: order-consumer
  minReplicaCount: 0          # 트래픽 없으면 0개까지!
  maxReplicaCount: 30
  triggers:
    - type: kafka
      metadata:
        bootstrapServers: kafka:9092
        consumerGroup: order-group
        topic: orders
        lagThreshold: "100"   # 미처리 메시지 100개 이상이면 스케일 아웃

HPA vs KEDA: 내부 메트릭 기반 vs 이벤트 기반 스케일링

3. 요약: 실무에서의 선택 기준

시나리오	추천	이유
REST API 서버 (Spring Boot)	HPA	CPU 기반 스케일링으로 충분, K8s 기본 기능
Kafka 컨슈머 / 배치 워커	KEDA	큐 깊이 기반 스케일링, 0→1 지원으로 비용 절감
크론 기반 선제 스케일링	KEDA	Cron 트리거로 "매일 오전 9시에 미리 5개로 확장" 가능
복합 (API + 비동기 워커)	HPA + KEDA 혼용	각 워크로드 특성에 맞는 전략 적용

K8s 자동 확장의 핵심은 "인프라를 트래픽에 반응하는 탄력적 자원으로 전환"하는 것입니다. HPA가 기본기를 제공하고, KEDA가 이벤트 기반 마이크로서비스 아키텍처에 최적화된 고급 확장을 담당합니다.

[KubeCon Japan 2026] 참관 후기 : 요코하마에서 만난 클라우드 네이티브의 축제☁️

예르미(yermi) — Sun, 2 Aug 2026 18:03:48 +0900

Dan Kohn 장학금 수혜자로 선정되어 다녀오겠다고 예고했던 KubeCon + CloudNativeCon Japan 2026, 드디어 다녀왔습니다. 7월 29일부터 30일까지 이틀간 요코하마 PACIFICO Yokohama에서 열린 글로벌 클라우드 네이티브 진영의 축제 현장을, 현업 백엔드 개발자의 시선으로 기록해 봅니다.

이번 글에서는 행사장의 전체적인 분위기와 등록·배지 시스템, 오프닝 키노트, 식사, 솔루션 쇼케이스(스폰서 부스)와 굿즈까지 참가자 경험 전반을 리뷰합니다. 현장에서 만난 사람들 이야기와 세션별 상세 리뷰는 각각 다음 편들에서 이어집니다.

⚓ 파시피코 요코하마 도착 : "Keep Cloud Native Moving"

미나토미라이의 파시피코 요코하마에 도착하면 가장 먼저 「ようこそ / WELCOME!」 사이니지가 반겨줍니다. 이번 행사의 슬로건은 "Keep Cloud Native Moving". 신칸센과 요코하마의 랜드마크(랜드마크 타워, 코스모 클락 대관람차) 위를 헤엄치는 비단잉어(코이) 마스코트가 곳곳에 등장하는데, 일본 개최지의 정체성을 잘 살린 디자인이라 등록 전부터 기분이 좋아졌습니다.

등록은 사전 등록 후 현장 배지 픽업 방식입니다. 저는 Dan Kohn 장학금 수혜자라 일반 등록 줄 옆에 마련된 별도 데스크에서 등록을 진행했는데, 스태프가 이름을 확인하고 바로 배지를 챙겨주어 빠르게 입장할 수 있었습니다.

여행자 입장에서 반가웠던 것 하나 1층에 클로크룸(Cloakroom)이 운영되어 캐리어나 큰 짐을 무료로 맡길 수 있습니다. 저처럼 숙소 체크아웃 후 바로 행사장으로 오거나, 마지막 날 공항으로 직행하는 일정이라면 꼭 활용하시길 추천합니다.

배지 하나에 담긴 디테일

개인적으로 인상 깊었던 부분은 배지 시스템의 디테일이었습니다. 단순한 이름표가 아니라 커뮤니케이션 도구로 설계되어 있습니다.

프로너운(Pronoun) 스티커: 자신의 호칭을 배지에 붙여 표시할 수 있습니다.
커뮤니케이션 스티커: 초록(말 걸어주세요) / 노랑(아는 사람만) / 빨강(지금은 대화 어려움) 3색 스티커로 네트워킹 선호도를 표시합니다. 내향적인 엔지니어가 많은 커뮤니티 특성을 배려한 장치라고 느꼈습니다.
배지 뒷면: Wi-Fi 정보, 행사 리소스 QR, 웰컴 리셉션 드링크 티켓, 티셔츠 교환 티켓까지 — 이틀간 필요한 것이 배지 하나에 모두 들어 있습니다.

저도 프로너운 스티커와 초록색 'GREEN' 스티커를 붙이고 이틀을 보냈습니다. 배지 하나로 "말 걸어도 되는 사람"이라는 신호를 보낼 수 있으니, 낯선 글로벌 콘퍼런스에서 네트워킹의 심리적 장벽이 확실히 낮아지는 느낌이었습니다.

오프닝 키노트 : 일본의 오픈 이노베이션 플랫폼

메인홀은 극장식 대형 홀이었는데, 키노트 시작 전부터 자리가 빠르게 채워졌습니다. 오프닝 키노트는 Linux Foundation의 Chris Aniszczyk(CTO) 와 Jonathan Bryce(Executive Director)가 무대에 올랐습니다. "Let's keep cloud native moving"이라는 마무리 멘트처럼, 쿠버네티스가 이미 성숙기에 접어든 지금 커뮤니티가 어디로 움직이고 있는지를 확인할 수 있는 자리였습니다.

키노트가 끝나고 세션룸으로 이동하는 복도는 그야말로 인산인해였습니다. 아시아 각국에서 온 엔지니어들이 뒤섞인 복도에서 글로벌 콘퍼런스에 와 있다는 실감이 났습니다.

먹는 것까지 진심 : 도시락과 웰컴 리셉션

점심은 인터컨티넨탈 요코하마 그랜드에서 준비한 도시락이 제공되었습니다. Western / Japanese / Chinese / Vegetarian 스타일 중 골라 가는 방식이었고, 모든 메뉴 앞에 알레르겐 성분표가 상세하게 비치되어 있었습니다. 호텔 케이터링답게 콘퍼런스 도시락의 기대치를 훌쩍 넘는 퀄리티였습니다. 별점을 매기자면 주저 없이 만점입니다.

수요일 저녁 17:45부터는 솔루션 쇼케이스 홀에서 웰컴 리셉션이 열렸습니다. 배지에 붙은 드링크 티켓 1장으로 맥주나 와인을 받을 수 있고, 논알콜 음료는 티켓 없이 자유롭게 마실 수 있습니다. 연어 카나페, 파테, 타르트 등 핑거푸드도 종류가 다양했고 역시 메뉴마다 알레르겐 표기가 붙어 있었습니다. 접시를 들고 부스 사이를 오가며 자연스럽게 대화가 이어지는, 네트워킹하기 좋은 분위기였습니다.

솔루션 쇼케이스 : 스폰서 부스 탐방

3층 솔루션 쇼케이스에는 글로벌 벤더와 일본 기업의 부스가 함께 들어섰습니다. Microsoft Azure, Grafana, Nutanix, CAST AI, Coder, SUSE, Snyk, Canonical 같은 글로벌 벤더와 함께 Hitachi, Fujitsu 등 일본 대기업이 OSPO(오픈소스 프로그램 오피스)를 전면에 내세운 부스를 운영하는 점이 인상적이었습니다. 오픈소스를 '활용'하는 단계를 넘어 '기여'를 조직 차원에서 제도화하는 흐름이 일본 엔터프라이즈에도 확실히 자리 잡고 있었습니다.

LGTM 스택을 운영 중인 입장에서 Grafana 부스는 그냥 지나칠 수 없었습니다. 「ダッシュボードだけじゃない(대시보드만이 아니다)」라는 캐치프레이즈와 함께 '실무에서 쓸 수 있는 AI'를 내세운 라이브 데모가 진행 중이었는데, RCA Workbench로 장애 원인을 추적하는 화면이 인상적이었습니다. 뉴스레터 가입하면 돌릴 수 있는 가챠 머신에 다마고치풍 마스코트까지, 부스 운영도 가장 즐거운 곳 중 하나였습니다.

이 외에도 sysdig/Falco 부스는 "Runtime security for AI coding agents"를 전면에 내걸고 있었는데, AI 코딩 에이전트의 런타임 보안이 스폰서 부스의 키 메시지로 등장할 만큼 올해 행사 전반의 화두가 'AI'였다는 점을 체감할 수 있었습니다. 부스에서는 굿즈만 얻은 것이 아니라 뜻밖의 만남들도 있었는데, 그 이야기는 다음 편에 따로 담았습니다.

굿즈 리뷰 : 부스별 수확 정리

콘퍼런스의 소소한 재미, 굿즈도 빼놓을 수 없습니다. 부스별 수확은 이렇습니다.

KubeCon 공식: 유니클로 기념 티셔츠 (배지의 티켓으로 교환, 요코하마 스카이라인 디자인)
Grafana Labs: LGTM(Loki·Grafana·Tempo·Mimir) 홀로그램 스티커 세트
Red Hat: 시그니처 빨간 페도라와 젓가락 세트
Snyk: 마스코트 '패치(Patch)' 브릭 키트와 인형
sysdig / SUSE: 파랑새·카멜레온 마스코트 인형
Datadog: 강아지 패턴 양말
기타: 키링, 키캡, 에코백, 케이블 세트와 각종 스티커들

한 가지 팁 — 부스에서 배지를 스캔하면 연락처가 해당 스폰서사에 제공된다는 안내(Badge Scanning Notice)가 있으니, 이 점은 알고 스캔에 응하시면 됩니다.

전리품, 그 후 : 사무실로 이어진 쿠버콘

귀국 후 짐을 풀어 전리품을 한자리에 펼쳐보니, 캐리어도 없이 백팩 하나로 이걸 다 들고 왔다는 게 스스로도 신기할 정도였습니다. 인형만 해도 SUSE 카멜레온에 sysdig 파랑새 두 마리까지.

전리품은 사무실까지 이어졌습니다. "SCALE K8s. NOT CHAOS."라고 적힌 Nutanix 티셔츠를 건넨 동료는 그 자리에서 바로 갈아입고 나타났고, SUSE 카멜레온과 sysdig 파랑새 인형, 뜨개 꿀벌 키링도 각각 주인을 찾아 동료들의 백팩 위와 책상 곳곳에 자리를 잡았습니다. 인형이며 스티커며 나눠드리니 다들 생각보다 훨씬 좋아하셔서, 굿즈를 핑계로 자연스럽게 쿠버콘에서 보고 들은 이야기까지 팀에 전할 수 있었습니다. 이런 소소한 전파 효과야말로 콘퍼런스 참가의 숨은 가치가 아닐까 싶습니다.

마치며

처음 참관한 글로벌 KubeCon은 기대 이상이었습니다. 세션의 밀도는 물론이고, 별도 데스크로 배려받은 장학생 등록, 짐을 맡길 수 있는 클로크룸, 호텔 케이터링 도시락, 배지 스티커 하나까지 — 참가자 경험 전반의 완성도가 '역시 CNCF 플래그십 행사'라는 말이 나오게 했습니다. 참가를 고민 중인 분이 있다면 운영 면에서는 걱정할 것이 하나도 없다고 말씀드리고 싶습니다.

다음 글에서는 현장에서 만난 반가운 사람들 — sysdig의 한국인 엔지니어, Grafana의 Alloy 개발자, 그리고 Java Champion 살라보이(Salaboy)와의 만남 이야기를 풀어보겠습니다.

[오늘가챠] 생성형 AI의 도입: Gemini 2.0 Flash와 안전장치

예르미(yermi) — Sat, 1 Aug 2026 16:28:45 +0900

단순히 사진을 업로드하고 게시하는 서비스는 지루합니다. '오늘가챠'는 유저가 찍은 평범한 일상 사진을 화려한 능력치와 세계관을 가진 카드로 자동 변환합니다. 이를 위해 생성형 AI를 결합한 경험입니다.

Gemini AI 사진 분석 및 카드 변환 흐름

1. 기술 선정: 왜 Gemini인가?

OpenAI의 GPT 모델 대신 구글의 Gemini 2.0 Flash 계열을 선택했습니다. 가격이 압도적으로 저렴하고 처리 속도가 빠르기 때문입니다. 하지만 무료 티어는 분당 요청 수(Rate Limit) 제한이 빡빡했습니다. 이를 극복하기 위해 GeminiClient에 다중 모델 Fallback 로직을 구현했습니다. 실제 프로젝트의 전체 Fallback 코드입니다.

// GeminiClient.java — 다중 모델 Fallback 전략

// 시도할 모델 목록 (우선순위 순서)
private static final List<String> GEMINI_MODELS = List.of(
        "gemini-2.0-flash", "gemini-2.5-flash-lite", "gemini-flash-latest");

public CardAnalysis analyze(byte[] imageBytes, String mimeType,
                            String userComment, String locationName) {
    String base64Image = Base64.getEncoder().encodeToString(imageBytes);
    // ...

    Exception lastException = null;

    for (String modelName : GEMINI_MODELS) {
        String url = "https://generativelanguage.googleapis.com/v1beta/models/"
                + modelName + ":generateContent?key=" + apiKey;
        try {
            ResponseEntity<String> response = restTemplate.exchange(
                    url, HttpMethod.POST,
                    new HttpEntity<>(objectMapper.writeValueAsString(requestBody), headers),
                    String.class);
            log.info("Gemini 분석 성공 (사용 모델: {})", modelName);
            return parseResponse(response.getBody());
        } catch (HttpClientErrorException.TooManyRequests e) {
            log.warn("Gemini API Rate Limit 초과 (모델: {}). 다음 모델 시도...", modelName);
            lastException = e;
        } catch (HttpServerErrorException e) {
            log.warn("Gemini 서버 에러 (모델: {}, 코드: {}). 다음 모델 시도...",
                    modelName, e.getStatusCode());
            lastException = e;
        }
        try { Thread.sleep(1000); } // 모델 간 전환 시 1초 대기
        catch (InterruptedException ie) { Thread.currentThread().interrupt(); }
    }

    // 모든 모델이 실패한 경우 의미 있는 에러 메시지 반환
    if (lastException instanceof HttpClientErrorException.TooManyRequests) {
        throw new RuntimeException(
            "무료 AI 분석 한도(1분 20회)를 초과했습니다. 약 1분 뒤에 다시 시도해 주세요.");
    }
    throw new RuntimeException("AI 서버 접속이 원활하지 않습니다.", lastException);
}

하나의 모델이 한도 초과(429 Too Many Requests) 에러를 뱉으면, 즉시 다음 대체 모델로 요청을 넘겨 유저가 에러를 겪지 않게 방어했습니다. 3개 모델을 모두 실패해도 사용자 친화적인 메시지를 반환합니다.

2. 안전 정책과 프롬프트 엔지니어링

생성형 AI 도입 시 가장 조심해야 할 것은 윤리 및 정책 위반(예: 타인의 얼굴 사진 훼손)입니다.
프롬프트 단에 아주 강력한 가드레일(Guardrails)을 세웠습니다. 실제 GeminiClient.java에 선언된 프롬프트의 전문입니다.

private static final String ANALYSIS_PROMPT = """
    당신은 일상 사진을 분석하여 트레이딩 카드 게임의 카드 메타데이터를 생성하는 AI입니다.

    ## 안전 검사 (최우선)
    아래 항목에 해당하면 safe=false로 판정하고 rejectReason을 작성하세요:
    - 선정적·음란한 이미지 (노출, 성적 암시 포함)
    - 과도한 폭력·고어 이미지
    - 불법 활동·약물 관련 이미지
    - 혐오·차별 조장 콘텐츠
    - 저작권 침해가 명백한 이미지 (스크린샷 등)
    - 사람의 얼굴(이목구비)이 식별 가능한 이미지 (초상권 보호)
    위 항목에 해당하지 않으면 safe=true로 판정하세요.

    ## 카드 메타데이터 (safe=true일 때만 생성)
    1. theme: 반드시 다음 11개 중 하나:
       FOOD, CITY, NATURE, ANIMAL, OBJECT, SKY,
       FASHION, RIDE, SPACE, HOBBY, MOMENT
    2. name: 카드의 창의적이고 감성적인 이름 (한국어, 15자 이내)
    3. flavor: 카드 뒷면의 감성적인 한 줄 문구 (한국어, 30자 이내)

    반드시 다음 JSON 형식으로만 응답하세요:
    {"safe":true,"theme":"FOOD","name":"카드이름","flavor":"플레이버텍스트","rejectReason":""}
    부적절한 이미지일 경우:
    {"safe":false,"rejectReason":"거부 사유"}
    """;

JSON 응답 파싱과 예외 처리

AI의 응답이 마크다운 백틱(```json)으로 감싸져 오는 엣지 케이스도 처리했습니다.

// GeminiClient.java — 응답 파싱 (마크다운 백틱 정제 포함)
private CardAnalysis parseResponse(String responseBody) {
    try {
        JsonNode root = objectMapper.readTree(responseBody);
        String text = root.at("/candidates/0/content/parts/0/text").asText();
        // AI가 ```json ... ``` 으로 감싸서 보내는 경우 정제
        text = text.replaceAll("```json\\s*", "").replaceAll("```\\s*", "").trim();
        JsonNode json = objectMapper.readTree(text);

        boolean safe = json.path("safe").asBoolean(true);
        if (!safe) {
            return new CardAnalysis(false,
                json.path("rejectReason").asText("부적절한 콘텐츠가 감지되었습니다."),
                null, null, null);
        }
        return new CardAnalysis(true, null,
            validateTheme(json.path("theme").asText("OBJECT")),
            json.path("name").asText("이름 없는 카드"),
            json.path("flavor").asText("누군가의 일상에서 탄생한 카드."));
    } catch (Exception e) {
        throw new RuntimeException("AI 분석 중 오류가 발생했습니다.", e);
    }
}

// 유효하지 않은 테마값이 오면 기본값 "OBJECT"로 Fallback
private String validateTheme(String theme) {
    return switch (theme.toUpperCase()) {
        case "FOOD", "CITY", "NATURE", "ANIMAL", "OBJECT",
                "SKY", "FASHION", "RIDE", "SPACE", "HOBBY", "MOMENT" ->
            theme.toUpperCase();
        default -> "OBJECT";
    };
}

부적절 이미지 차단 시 후처리

AI가 safe=false로 판정하면, 해당 사진을 즉시 숨김 처리(hidden)합니다. 유저에게는 거절 사유를 안내합니다.

// CardFacade.java — craft() 메서드 내 안전 검사 후처리
if (!analysis.safe()) {
    // 부적절한 이미지는 숨김 처리 (사용자에게 보이지 않음, 재업로드 불가)
    photoService.hidePhoto(up.getId());
    String reason = analysis.rejectReason() != null
        ? analysis.rejectReason() : "부적절한 이미지입니다.";
    throw new IllegalStateException(reason);
}

3. 마무리

AI 분석 코드를 보면 단순한 API 호출이 아니라, JSON 포맷을 강제하기 위한 텍스트 정규화(마크다운 백틱 치환 등)와 예외 모델 Fallback까지 실무적인 엣지 케이스들을 꼼꼼하게 처리했습니다. AI API 연동은 코딩보다 응답을 통제하는 엔지니어링이 진정한 핵심 역량입니다.

[K8s] 상태가 있는(Stateful) 데이터를 위한 스토리지 전략: PV, PVC와 StatefulSet

예르미(yermi) — Wed, 29 Jul 2026 22:38:57 +0900

이번 글에서는 K8s에서 영구적인 데이터를 관리하기 위한 스토리지 추상화 계층과, 상태 유지가 필요한 애플리케이션을 위한 특수한 배포 전략인 StatefulSet을 백엔드 개발자의 시각에서 정리합니다.

1. Pod의 치명적 약점: 휘발성(Ephemeral) 스토리지

Pod가 삭제되거나 재시작되면 컨테이너 내부의 파일 시스템은 완전히 초기화됩니다. Spring Boot 앱처럼 상태가 없는(Stateless) 워크로드에는 문제가 없지만, 데이터베이스라면 치명적입니다.

K8s는 이 문제를 해결하기 위해 볼륨 시스템을 제공하며, 그중 핵심이 되는 개념이 PV와 PVC입니다.

2. PV와 PVC: 개발자와 인프라의 계약서

K8s는 스토리지를 요청하는 측(개발자)과 제공하는 측(인프라)을 분리합니다.

PV (Persistent Volume): 클러스터 관리자가 미리 프로비저닝해 둔 실제 물리 스토리지(AWS EBS, NFS, Ceph 등)를 K8s 오브젝트로 추상화한 것입니다.
PVC (Persistent Volume Claim): 개발자가 "나는 10GB짜리 SSD 스토리지가 필요해"라고 요청서를 작성하는 것입니다.
바인딩(Binding): K8s가 PVC의 요구 사항에 맞는 PV를 자동으로 찾아 연결해 줍니다.

# PVC 예시: 개발자가 작성하는 스토리지 요청서
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-data
spec:
  accessModes:
    - ReadWriteOnce       # 하나의 Pod에서만 읽기/쓰기
  resources:
    requests:
      storage: 10Gi       # 10GB 요청
  storageClassName: gp3   # AWS gp3 SSD 타입

백엔드 개발자 관점: PVC만 잘 작성하면 됩니다.
실제 디스크가 AWS EBS인지, GCP Persistent Disk인지는 storageClassName이 결정하며,
이는 인프라 팀이 미리 설정해 둡니다. Gateway API의 역할 분리와 같은 철학입니다.

PV/PVC 아키텍처: Pod → PVC → PV → 물리 스토리지

3. StatefulSet: 순서와 정체성이 있는 Pod

일반적인 Deployment로 관리되는 Pod들은 이름이 랜덤(app-7d8f4b-xk2z9)하고, 서로 완전히 동일하며 교체 가능합니다. 하지만 데이터베이스 클러스터에서는 이런 특성이 문제가 됩니다.

Master와 Replica의 역할이 정해져 있어 순서대로 기동해야 합니다.
각 노드가 자신만의 고유한 스토리지를 가져야 합니다.
재시작해도 같은 네트워크 이름(db-0, db-1)을 유지해야 합니다.

StatefulSet은 이 모든 요구 사항을 충족시키는 특수한 워크로드 컨트롤러입니다.

특성	Deployment	StatefulSet
Pod 이름	랜덤 (`app-xk2z9`)	순서 고정 (`db-0`, `db-1`, `db-2`)
스토리지	공유 또는 없음	각 Pod 전용 PVC 자동 생성
기동 순서	동시에 병렬 기동	`db-0` → `db-1` → `db-2` 순차 기동
네트워크	재시작 시 IP 변동	Headless Service로 고정 DNS 제공

Deployment vs StatefulSet 비교

4. 요약: 언제 무엇을 쓸 것인가?

Stateless 앱 (Spring Boot API 서버, React 프론트엔드) → Deployment + 필요 시 PVC
Stateful 앱 (PostgreSQL, Redis Cluster, Kafka) → StatefulSet + volumeClaimTemplates

[StatefulSet]
     │
     ├── [db-0] ──── [PVC: db-data-0] ──── [PV: AWS EBS vol-001]
     ├── [db-1] ──── [PVC: db-data-1] ──── [PV: AWS EBS vol-002]
     └── [db-2] ──── [PVC: db-data-2] ──── [PV: AWS EBS vol-003]

K8s에서 데이터를 다룰 때 핵심은, "데이터의 생명주기를 Pod의 생명주기와 분리"하는 것입니다. PV/PVC를 통해 이 분리가 이루어지고, StatefulSet이 상태가 있는 워크로드의 안정적인 운영을 보장합니다.

[오픈소스] 특수문자를 10개만 아는 강도 검사기를 고치다 [Password-Strength-Tester-and-Cracker]

예르미(yermi) — Mon, 27 Jul 2026 22:04:27 +0900

오랜만에 good first issue를 하나 잡았다. Password Strength Tester and Cracker라는 자바 콘솔 프로젝트인데, 비밀번호 강도를 판정해주는 기능에 버그가 있다는 이슈였다.

문제의 코드는 이거였다.

String specialChars = "!@#$%^&*()";

특수문자를 딱 10개만 인정한다. - _ [ ] { } 같은 건 전부 특수문자 취급을 못 받는다는 뜻이다. 그래서 고치기 전 판정이 이렇게 나온다.

비밀번호	판정
`correct-horse-battery1A` (23자)	Medium
`P@ssw0rd[]{}` (12자)	Strong

23자짜리 패스프레이즈는 Medium인데, 사전에 있는 password를 leet로 바꾼 12자짜리는 Strong이다. 그것도 뒤에 붙인 []{}는 인정도 못 받고 오직 @ 하나 덕분에. 거의 거꾸로다

특수문자 10개만 인정하는 문제와 수정안이 적힌 GitHub 이슈

근데 이슈에 적힌 수정은 한 줄이었다

Invert the test. Rather than listing which symbols count,
treat anything that isn't a letter, digit, or whitespace as a symbol

if (!Character.isLetterOrDigit(ch) && !Character.isWhitespace(ch)) hasSpecial = true;

목록을 나열하지 말고 뒤집으라는 것. 이거 한 줄이면 끝나는 거 아닌가? 싶었는데 메인테이너가 이슈를 할당해주면서 코멘트를 남겼다.

The part worth spending your time on is the test cases rather than the one-line fix.
I'd rather see a PR that gets those judgements written down explicitly than one that just widens the character set.

특수문자 목록만 넓히는 PR은 원하지 않는다고. 대신 두 가지를 정하고 그 근거를 적으라고 했다.

공백은 특수문자인가? 29자짜리 패스프레이즈가 지금은 "소문자만"으로 판정되는데, 그렇다고 공백을 "특수"라고 부르는 것도 이상하지 않나?
길이만으로 충분한가? aaaaaaaaaaaaaaaaaaaa는 20자짜리 아무것도 아닌 문자열인데.

한 줄 고치는 이슈인 줄 알았더니, 사실은 뭘 강한 비밀번호로 볼 것인가를 정하는 이슈였던 것이다.

그래서 코드보다 규칙을 먼저 적었다

바로 코딩하지 않고 이슈에 코멘트부터 남겼다. 내가 제안하는 규칙은 이랬다.

classes = {대문자, 소문자, 숫자, 특수} 중 존재하는 개수
Strong  = 12자 이상 && classes >= 3
Medium  = (8자 이상 && classes >= 2) || (20자 이상 && classes >= 1)
Weak    = 그 외
오버라이드: 서로 다른 문자가 2개 이하면 무조건 Weak

두 질문에 대한 내 답은 규칙 안에 박아뒀다.

공백은 특수문자로 안 친다. 대신 길이가 패스프레이즈를 구제하게 했다. 공백을 기호라고 우기면 평범한 문장이 있지도 않은 기호 다양성을 가진 것처럼 보이게 되니까. correct horse battery staple은 "20자 이상"이라는 조항으로 Medium이 된다. 정직하게.

길이만으로는 부족하다. 그래서 "서로 다른 문자 2개 이하면 Weak" 가드를 넣었다. 사실 이 가드가 있어야 위의 길이 조항을 안심하고 쓸 수 있다. 없으면 aaaaaaaaaaaaaaaaaaaa가 20자라는 이유로 Medium이 되어버린다.

그리고 하나 승인을 요청했다. 기존 Strong 조건이 4종류 전부를 요구하는데, 이슈 표에 "Strong이어야 한다"고 적힌 my_secure_pass_2026!에는 대문자가 없다. 4종 전부는 애초에 성립할 수 없었다.

그리고 내가 판 함정에 내가 빠졌다

메인테이너 답변은 거의 전부 yes였다. 기분 좋게 읽어 내려가는데 중간에 이런 게 있었다.

One thing to catch before you code it
Your ruleset and one of your assumptions disagree.

...네?

내가 코멘트에 이렇게 썼었다. "표에서 비어있는 my_secure_pass_2026는 Medium으로 하겠습니다."

그런데 내가 방금 제안한 규칙에 넣고 돌려보면:

길이 19
소문자 ✓, 숫자 ✓, 그리고 _는... 내가 제안한 반전 테스트에서 특수문자다 ✓
3종류 + 12자 이상 → Strong

밑줄을 깜빡한 거다. "영문·숫자·공백이 아니면 특수"라고 내 손으로 써놓고, 정작 그 줄을 계산할 때는 _를 안 세었다. 표의 "현재 판정" 칸에 적힌 Medium을 무심코 "기대 판정" 칸에 옮겨 적은 셈이었다. 심지어 그 Medium은 지금 고치려는 버그가 만들어낸 값인데

메인테이너의 마무리가 좋았다.

That's the whole point of writing the rules down first
— this is the kind of contradiction that's invisible until the cases are on the page.

규칙을 먼저 적어두는 게 바로 이래서라고. 케이스를 지면에 올려놓기 전엔 안 보이는 종류의 모순이라고. 창피하긴 했는데, 코드 다 짜고 나서 발견하는 것보단 백배 나았다.

내 규칙의 모순을 지적하고 테스트 작성을 요청한 메인테이너 코멘트

테스트가 곧 명세다

메인테이너가 요구한 마지막 조건은 이거였다.

That way the test is the spec, and if anyone later tweaks a threshold,
the row that changes tells them what they broke.

테스트 프레임워크 없이, failures 카운터와 평범한 if와 System.exit(1)만 쓰는 자체 검증 클래스를 만들었다. 이슈 표의 모든 행 + 내가 추가한 엣지 케이스를 기대값으로 박아넣었다.

expect("correct-horse-battery1A", "Strong");
expect("my_secure_pass_2026", "Strong");          // 밑줄이 특수 → 3종
expect("correct horse battery staple", "Medium"); // 길이가 구제, 공백은 기호가 아님
expect("aaaaaaaaaaaaaaaaaaaa", "Weak");           // 길이만으론 부족

그런데 여기서 하나 빠진 게 있었다. "공백은 특수문자가 아니다"라는 결정을 검증하는 케이스가 없었다. 패스프레이즈 케이스는 공백을 특수로 쳐도 어차피 Medium이 나와서, 둘을 구분해내지 못한다. 즉 나중에 누가 공백을 특수로 바꿔도 테스트가 안 깨진다.

그래서 한 줄 추가했다.

expect("abcdefgh 1234", "Medium"); // 공백을 특수로 치면 3종이 되어 Strong으로 바뀐다

13자에 소문자+숫자 2종이라 Medium. 만약 공백을 특수로 인정하면 3종이 되면서 Strong으로 튀고, 테스트가 깨진다. 이제 그 판단이 진짜로 코드에 고정된 것이다.

다만, 고친 뒤에도 `P@ssw0rd[]{}`는 Strong이다

솔직하게 짚어둘 게 있다. 새 규칙으로 돌려도 P@ssw0rd[]{}는 여전히 Strong이다. 12자에 네 종류를 다 갖췄으니 규칙상 그렇다. 하지만 이건 크래킹 툴이 제일 먼저 시도하는 password의 leet 변형이다. 실제 강도로 치면 최하위권인데 우리 검사기는 최고 등급을 준다.

이 검사기가 보는 건 문자 종류의 개수와 길이뿐이기 때문이다. 사전 단어도, a→@ o→0 같은 leet 치환도, 키보드 패턴도 전혀 모른다. 그래서 P@ssw0rd[]{}와 진짜 무작위 12자를 구분하지 못한다.

이번 작업이 고친 건 일관성이지 정확성이 아니었던 셈이다. 제대로 하려면 zxcvbn 같은 사전 기반 추정기가 필요한데, 그건 이 이슈의 범위를 한참 넘는 얘기다.

마무리

한 줄 고치는 이슈인 줄 알고 시작했는데, 실제 로직 변경은 13줄 추가 4줄 삭제였고 시간의 대부분은 "무엇을 강한 비밀번호로 볼 것인가"를 정하고 그 근거를 적는 데 썼다.

돌아보면 이번에 제일 많이 배운 건 자바 문법이 아니라 이거였다. 머릿속에서 맞는 것 같은 규칙도, 케이스를 늘어놓고 하나씩 돌려보기 전까진 모른다. 내 규칙과 내 기대값이 어긋나 있는 걸 나는 끝까지 못 봤고, 지적을 받고 나서야 종이 위에 늘어놓고 계산해봤다. 테스트를 명세로 남기라는 말이 왜 그렇게 강조됐는지 알 것 같았다.

Success⭐

[도서리뷰] 누구나 이해하는 클라우드 인프라 지식 사전 - 기능은 다 만들었는데, 왜 새벽 3시에 전화가 울릴까?

예르미(yermi) — Mon, 27 Jul 2026 12:23:20 +0900

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

AI가 코드를 대신 짜주는 시대에, 왜 장애는 여전히 사람의 몫일까?

2026년의 개발 환경은 몇 년 전과 완전히 달라졌습니다. AI 코딩 도구가 기능 구현의 속도를 몇 배로 끌어올렸고, 이제 "이 기능을 어떻게 만들지"는 예전만큼 어려운 질문이 아닙니다. 그런데 이상하게도, 새벽에 울리는 알람의 개수는 줄지 않았습니다.

응답 속도가 슬금슬금 느려지고, 트래픽이 조금 늘었을 뿐인데 어딘가에서 병목이 생기고, 배포한 뒤 장애가 났는데 원인을 짚지 못합니다. 이건 코드 품질의 문제가 아닙니다. 서비스는 서버, 네트워크, OS, 컨테이너, 클라우드, 모니터링, 보안, 운영 체계가 유기적으로 맞물려 돌아가는 물건이기 때문입니다. AI는 코드를 대신 써줄 수 있어도, 내가 모르는 계층의 문제를 대신 진단해주지는 않습니다.

한빛미디어의 신간 <누구나 이해하는 클라우드 인프라 지식 사전>은 바로 이 빈틈을 겨냥한 책입니다. 특정 벤더의 콘솔 사용법을 알려주는 매뉴얼이 아니라, 도구가 아무리 바뀌어도 변하지 않는 시스템의 기본 원리를 576쪽 23개 장에 한 흐름으로 정리한 책입니다.

인프라를 '외우는' 대신 '연결해서 이해하게' 만드는 책.

인프라는 결국 '계층'을 보는 눈이다

이 책에서 가장 먼저 꺼내는 이야기는 클라우드 서비스가 아니라 계층 구조입니다. 시스템은 층으로 쌓여 있고, 계층화는 호환성과 분담을 위해 존재한다는 것. 너무 당연한 이야기 같지만, 실무에서 우리가 헤매는 대부분의 순간은 "지금 이 문제가 어느 층에서 벌어지고 있는지"를 특정하지 못할 때 발생합니다.

응답이 느리다는 신고 하나를 받았을 때, 그게 애플리케이션 코드인지, DB 커넥션 풀인지, 컨테이너 리소스 리밋인지, 아니면 그냥 DNS인지 구분하지 못하면 우리는 감으로 로그를 뒤지게 됩니다. 저는 이전에 서버리스 DB의 커넥션 풀이 고갈되는 문제를 잡느라 며칠을 태운 적이 있는데, 돌이켜보면 그건 어려운 문제였다기보다 어느 계층을 봐야 하는지 몰랐던 문제에 가까웠습니다.

1장이 마지막에 던지는 키워드가 인상적입니다. "You build it, you run it." 만든 사람이 운영한다는 원칙은 이제 슬로건이 아니라 기본값이고, 이 책 전체는 그 기본값을 감당할 수 있는 지식의 목록이라고 봐도 무방합니다.

가용성·용량·성능, 숫자로 말하는 법을 배우다

2장부터 4장까지가 이 책의 첫 번째 절정입니다. 가용성과 신뢰성을 측정하고, 용량과 부하를 관리하고, 성능을 튜닝하는 흐름이 순서대로 이어집니다.

특히 3장의 구성이 좋았습니다. 병목 지점의 처리량을 조절하는 기법에서 시작해 수평 확장(스케일 아웃/인), 수직 확장(스케일 업/다운), 그리고 확장의 한계를 뛰어넘는 분할까지 단계적으로 올라갑니다. "일단 인스턴스를 늘린다"는 반사적인 대응이 왜 어느 지점부터는 통하지 않는지, 그 한계선이 어디인지를 구조적으로 설명해 줍니다.

4장의 성능 튜닝은 더 실전적입니다. 성능 튜닝의 기본 흐름 → 부하 테스트 → 성능 개선 기술 → 용량 부족에 대처하는 기술 순서로 진행되는데, 측정 없는 튜닝은 그냥 추측이라는 당연한 원칙을 다시 확인하게 됩니다. 부하 테스트를 제대로 설계해 본 적 없이 "최적화했습니다"라고 말해왔던 스스로를 반성하게 만드는 챕터였습니다.

스케일 아웃, 스케일 업, 그리고 분할. 언제 무엇을 선택해야 하는지의 기준을 제시한다.

관찰 가능성, 이 책에서 가장 두꺼운 챕터

개인적으로 가장 오래 붙들고 읽은 곳은 14장 감시, 모니터링, 관찰 가능성(Observability)입니다. 무려 10개 절로 구성된, 이 책에서 가장 공들인 장 중 하나입니다.

이 장이 좋은 이유는 도구부터 소개하지 않는다는 점입니다. "관찰 가능성이라는 개념이 왜 등장했는가"를 먼저 묻고, 시계열 데이터와 데이터 가시화라는 기초를 깔아준 다음에야 실무 적용과 툴 이야기로 넘어갑니다. 요즘 옵저버빌리티 이야기가 곧바로 스택 이름 나열로 흘러가는 경우가 많은데, 이 책은 왜 그 스택이 필요해졌는지를 먼저 이해시킵니다.

그리고 장애 대응의 기본 원칙과 사후 분석(포스트모템)까지 같은 장 안에 넣어둔 구성이 마음에 들었습니다. 관측은 대시보드를 예쁘게 만드는 일이 아니라, 장애가 났을 때 원인에 도달하고 다음에 같은 일이 반복되지 않게 만드는 일이라는 걸 구조로 보여주기 때문입니다.

15장의 데브옵스와 SRE가 바로 뒤에 이어지는 것도 자연스럽습니다. 사용자 가치를 기준으로 신뢰성을 제어한다는 SRE의 사고방식, 그리고 플랫폼 엔지니어링까지, 조직이 이 지식을 어떻게 굴러가게 만드는지가 이어집니다.

볼 수 없는 것은 고칠 수 없다. 감시에서 관찰 가능성으로, 그리고 SRE로 이어지는 흐름.

배포와 릴리스는 다른 말이다

19장 릴리스 엔지니어링의 첫 절 제목이 "배포와 릴리스 구분"인데, 이 책의 성격을 잘 보여줍니다.

우리는 두 단어를 습관적으로 섞어 씁니다. 하지만 코드를 서버에 올리는 행위(배포)와 그 기능을 사용자에게 노출하는 행위(릴리스)를 분리해서 생각하는 순간, 블루-그린이나 카나리, 피처 플래그 같은 기법들이 왜 존재하는지가 한 번에 정리됩니다. 책은 대표적인 배포 기법과 릴리스 기법을 각각 정리한 뒤, CI/CD와 이들을 어떻게 조합할지, 그리고 릴리스 전 리뷰와 체크리스트까지 이어갑니다.

그 밖에도 실무에서 반드시 마주치지만 아무도 체계적으로 가르쳐주지 않는 주제들이 촘촘합니다. 7장의 HTTPS와 TLS 인증서, 9장의 가상화·컨테이너·도커·쿠버네티스, 11장의 프로덕션/스테이징/개발 환경과 멀티 테넌시 분리 기법, 17장의 구조화 로그와 로그 저장 기간, 18장 백업의 3-2-1 전략, 21장의 메일 전송, 22장의 컴플라이언스까지. 심지어 23장은 '취업'입니다. 이 지식들이 현장에서 어떤 기대치로 환산되는지를 마지막에 짚어주는 구성이 인상적이었습니다.

'사전(事典)'이라는 형식에 대하여

제목에 붙은 '지식 사전'은 마케팅 수사가 아니라 이 책의 실제 사용법입니다. 부록에 용어집과 찾아보기가 따로 붙어 있고, 각 장이 독립적으로 완결되어 있어서 순서대로 읽지 않아도 됩니다.

물론 단점도 있습니다. 넓게 다루는 만큼 각 주제의 깊이는 전문서 한 권을 대체하지 못합니다. 쿠버네티스를 제대로 파려면 쿠버네티스 책이 따로 필요하고, 보안도 마찬가지입니다. 하지만 이 책의 목적은 애초에 그게 아닙니다. 흩어져 있던 기술 키워드들을 하나의 서비스 구조 위에 배치해서, 내가 지금 무엇을 모르는지 알게 해주는 것. 저는 이걸 지도라고 부르고 싶습니다. 지도가 있어야 어디를 깊게 파야 할지도 정할 수 있으니까요.

번역도 깔끔합니다. 역자가 40여 종의 역서를 낸 현직 솔루션 아키텍트라서인지, 일본어 기술서 특유의 어색함 없이 용어가 자연스럽게 읽혔습니다.

총평 및 추천 대상

<누구나 이해하는 클라우드 인프라 지식 사전>은 당장 내일 복붙할 코드를 주는 책이 아닙니다. 대신 장애가 났을 때 어디를 봐야 할지 아는 개발자로 만들어주는 책입니다.

✅ 이런 분들에게 강력 추천합니다:

기능 구현은 자신 있지만, 장애·성능·운영 앞에서는 매번 검색부터 시작하는 개발자
쿠버네티스, 옵저버빌리티, CI/CD 같은 키워드를 따로따로 알고는 있지만 하나로 꿰어지지 않는 백엔드 엔지니어
주니어에게 인프라 기본기를 가르쳐야 하는데 마땅한 공통 교재가 없어서 곤란했던 팀 리드
클라우드를 쓰고는 있지만 그 아래에서 무슨 일이 벌어지는지 궁금했던 모든 개발자

도구는 계속 바뀝니다. AI는 앞으로 더 많은 코드를 대신 써줄 겁니다. 그래도 시스템을 지탱하는 원리는 그대로이고, 그 원리를 아는 사람과 모르는 사람의 차이는 장애가 났을 때 가장 선명하게 드러납니다. 책상 옆에 꽂아두고 필요할 때마다 펼쳐볼 한 권으로 권합니다.

코드를 잘 짜는 것과 서비스를 잘 굴리는 것은 다른 능력이다.
그리고 후자는 여전히, 사람이 알아야 한다.

[오늘가챠] 프론트-DB 직결 시대의 필수 보안: Supabase RLS 적용기

예르미(yermi) — Sat, 25 Jul 2026 16:24:28 +0900

BaaS(Backend as a Service)의 등장으로 프론트엔드에서 API를 거치지 않고 DB를 직접 쿼리하는 일이 잦아졌습니다. 이는 개발 속도를 비약적으로 높여주지만, 자칫하면 대형 보안 사고로 이어질 수 있습니다. 이를 방어하기 위해 Supabase의 핵심 기능인 RLS(Row Level Security)를 적극 활용한 경험을 공유합니다.

RLS(Row Level Security) 동작 원리

1. BaaS의 편리함 이면에 숨겨진 보안 취약점

'오늘가챠' 앱에서는 유저가 카드를 뽑으면 cards 테이블에 데이터가 저장됩니다.
만약 프론트엔드 클라이언트가 Supabase anon 키(익명 접속용 퍼블릭 키)를 이용해 직접 DB 쿼리를 날린다면 어떨까요?

// 프론트엔드에서 직접 DB를 찌르는 코드 (위험함)
const { data } = await supabase.from('cards').select('*')

악의적인 해커가 개발자 도구(Network 탭)에서 anon 키를 빼내어, 남의 user_id를 넣고 쿼리를 조작한다면 타인의 인벤토리를 들여다보거나 카드를 삭제해버릴 수 있습니다. 기존 백엔드(Spring)에서는 아래처럼 매번 권한 검증 로직을 짜야 했습니다.

// PhotoService.java — 기존의 수동 권한 검증 코드
public Photo getOwnedPhoto(Long userId, Long photoId) {
    Photo up = photoMapper.findById(photoId);
    if (up == null) throw new IllegalArgumentException("업로드를 찾을 수 없습니다.");
    if (!up.getUserId().equals(userId)) throw new SecurityException("권한이 없습니다.");
    return up;
}

2. RLS(Row Level Security)란?

PostgreSQL 9.5부터 도입된 RLS는 애플리케이션 코드가 아닌 데이터베이스 엔진 레벨에서 특정 유저가 테이블의 '어떤 행(Row)'에 접근할 수 있는지 권한을 제어하는 기능입니다.

Supabase는 자체 구축한 Auth(인증) 시스템의 JWT 토큰과 이 RLS를 기가 막히게 연동해 두었습니다.

3. RLS 정책(Policy) 작성 실전

Supabase 대시보드(SQL Editor)를 통해 cards 테이블에 다음과 같은 정책을 선언했습니다.

-- 1. 카드 조회 정책: 오직 자신이 뽑은 카드만 볼 수 있다.
CREATE POLICY "View own cards" 
ON cards FOR SELECT 
USING (auth.uid() = user_id);

-- 2. 카드 추가 정책: 카드 뽑기 성공 시 자기 계정에만 저장 가능.
CREATE POLICY "Insert own cards" 
ON cards FOR INSERT 
WITH CHECK (auth.uid() = user_id);

-- 3. 사진 조회 정책: 공개(public) 사진은 모두가 볼 수 있지만,
--    비공개(private) 사진은 소유자만 볼 수 있다.
CREATE POLICY "View photos" 
ON photos FOR SELECT 
USING (
  status = 'public' 
  OR auth.uid() = user_id
);

동작 원리

프론트엔드나 백엔드에서 Supabase로 요청을 보낼 때, 헤더에 유저가 로그인하며 발급받은 JWT(Authorization: Bearer <token>)를 담아 보냅니다.
DB 엔진 내부에서 이 토큰을 파싱해 auth.uid() 함수를 통해 요청자의 고유 UUID를 알아냅니다.
쿼리에 명시적 WHERE 절이 없더라도, DB가 알아서 자신이 소유한 행(Row)만 필터링하여 응답을 내려주거나 접근을 차단합니다.

[요청 흐름]
프론트엔드 → JWT 토큰 포함 요청 → Supabase PostgREST
         → auth.uid() 추출 → RLS 정책 자동 적용
         → "WHERE user_id = '추출된_UUID'" 자동 주입
         → 안전한 결과만 반환

실제 프로젝트의 테이블 스키마와 RLS의 연계

-- photos 테이블은 user_id를 FK로 가지며, RLS가 이 컬럼을 기준으로 필터링
CREATE TABLE IF NOT EXISTS photos (
    id            BIGSERIAL PRIMARY KEY,
    user_id       BIGINT       NOT NULL REFERENCES users(id),
    image_url     VARCHAR(500) NOT NULL,
    status        VARCHAR(10)  NOT NULL DEFAULT 'DRAFT',
    -- ...
);

-- cards 테이블도 동일하게 user_id 기반 RLS 적용
CREATE TABLE IF NOT EXISTS cards (
    id          BIGSERIAL PRIMARY KEY,
    user_id     BIGINT    NOT NULL REFERENCES users(id),
    photo_id    BIGINT    NOT NULL REFERENCES photos(id),
    -- ...
);

4. 마무리

RLS를 적용함으로써, 백엔드 서버에서 길고 장황하게 작성해야 했던 유저 권한 검증 로직이 통째로 삭제되었습니다. 프론트엔드-BaaS 직결 아키텍처를 사용할 때 발생할 수 있는 보안 취약점을 DB 엔진 층에서 가장 안전하고 우아하게 틀어막은 베스트 프랙티스입니다.

[K8s] 눈을 가리고 운전할 수는 없다: K8s 옵저버빌리티(Observability)와 AIOps의 도래

예르미(yermi) — Wed, 22 Jul 2026 22:33:44 +0900

단일 서버(Monolithic) 환경에서는 서버에 직접 접속해 로그 파일을 열어보면 그만이었지만, 언제든 죽고 재생성되는 K8s 환경에서는 불가능한 방식입니다. 이번 글에서는 클라우드 네이티브 환경의 필수 요소인 옵저버빌리티(Observability)와, 이를 고도화하는 AIOps 트렌드에 대해 다룹니다.

1. 모니터링(Monitoring)을 넘어 옵저버빌리티(Observability)로

단순한 '모니터링'과 '옵저버빌리티(관측성)'는 미묘하지만 큰 차이가 있습니다.

모니터링: 시스템이 "언제(When)" 망가졌는지, 즉 CPU 사용률이 90%를 넘었는지 등 미리 정의된 임계치를 감시합니다.
옵저버빌리티: 시스템이 "왜(Why)" 망가졌는지, 즉 분산된 마이크로서비스 환경에서 외부 요청이 내부의 어떤 서비스들을 거쳐갔고 어느 지점에서 지연이 발생했는지 내부 상태를 추론할 수 있게 해줍니다.

옵저버빌리티를 달성하기 위해서는 흔히 '3대 기둥(Three Pillars)'이라 불리는 데이터를 중앙 집중화해야 합니다.

메트릭(Metrics): CPU, 메모리, HTTP 요청 횟수 등 정량적인 수치 데이터
로그(Logs): 애플리케이션이 뿜어내는 텍스트 형태의 이벤트 기록
트레이스(Traces): 하나의 요청(Request)이 여러 마이크로서비스를 거쳐가는 전체 경로와 구간별 소요 시간 (분산 트레이싱)

옵저버빌리티 3대 기둥: Metrics, Logs, Traces

2. K8s 생태계를 장악한 관제탑: LGTM 스택

이 3가지 데이터를 효율적으로 수집하고 저장하기 위해, 최근 클라우드 네이티브 생태계에서는 사실상의 표준(De facto standard)으로 LGTM 스택이 강력하게 자리 잡았습니다.

구성 요소	역할	설명
Loki	Logs	K8s 환경에 최적화된 로그 집계 시스템. ELK(Elasticsearch)와 달리 메타데이터(Label)만 인덱싱하여 매우 가볍고 비용 효율적
Grafana	Visualization	수집된 모든 데이터를 하나의 화면에서 시각화해 주는 강력한 대시보드
Tempo	Traces	대규모 분산 트레이싱 백엔드. 서비스 간 호출 지연을 폭포수(Waterfall) 차트로 시각화
Mimir	Metrics	Prometheus의 한계(장기 보관 및 스케일링)를 극복한 대용량 시계열 데이터베이스

3. 파편화된 데이터 수집의 통일: OpenTelemetry (OTel)

LGTM 백엔드가 훌륭해도, Spring Boot 앱에서 메트릭, 로그, 트레이스를 각각 다른 에이전트(Agent)를 통해 수집한다면 운영 오버헤드가 극심해집니다. 이를 해결하기 위해 등장한 CNCF의 핵심 프로젝트가 바로 OpenTelemetry(OTel)입니다.

[Spring Boot (Pod)] ──(OTel SDK)──▶ [OTel Collector]
                                          │
                                          ├──▶ 메트릭  ──▶ [Mimir]
                                          ├──▶ 로  그  ──▶ [Loki]
                                          └──▶ 트레이스 ──▶ [Tempo]

OTel은 특정 벤더에 종속되지 않는 표준화된 데이터 수집 파이프라인을 제공합니다. 개발자는 애플리케이션 코드에 OTel 라이브러리만 연동해 두면, 인프라 담당자는 OTel Collector를 통해 데이터를 가공하고 원하는 백엔드(LGTM, Datadog 등)로 언제든 유연하게 보낼 수 있습니다.

LGTM 스택 + OpenTelemetry 아키텍처

4. 옵저버빌리티의 종착지: AIOps와 자동화된 대응

데이터를 잘 모았다고 끝이 아닙니다. K8s 클러스터 규모가 커지면 수집되는 데이터량은 인간이 눈으로 분석할 수 없는 수준(Alert Fatigue, 알람 피로)에 이릅니다.

여기서 최근 주목받는 AIOps (Artificial Intelligence for IT Operations) 개념이 등장합니다.

이상 탐지 (Anomaly Detection): "CPU 80% 이상일 때 알람" 같은 고정된 규칙이 아니라, 머신러닝 모델이 평소 서비스의 트래픽 패턴을 학습하여 "수요일 오후 2시 치고는 결제 실패율이 비정상적으로 높다"는 것을 스스로 감지합니다.
근본 원인 분석 (Root Cause Analysis, RCA): 장애가 발생하면 AI가 OTel을 통해 수집된 트레이스와 로그를 결합 분석하여 "DB 쿼리 락(Lock)이 원인이다"라고 짚어줍니다.
자동화된 롤아웃 조치 (Zero-Touch Rollout Fixes): GitOps 플랫폼과 연동하여, 새 버전 배포 후 에러율이 상승하는 것이 감지되면 AI가 개입해 즉시 이전 안전한 버전으로 자동 롤백을 수행합니다.

[오늘가챠] 서버리스 DB의 한계 극복: Supabase 커넥션 풀 고갈 해결

예르미(yermi) — Sat, 18 Jul 2026 16:18:48 +0900

백엔드 배포 직후, 앱에 트래픽이 몰리자 에러가 쏟아졌습니다. 서버리스 환경에서 맞닥뜨린 DB 커넥션 풀(Connection Pool) 고갈 에러의 원인과, HikariCP를 튜닝하여 이를 극복한 과정입니다.

커넥션 풀 고갈 문제와 해결

1. 런타임 에러 발생: Connection is not available

기능 구현을 마치고 테스트를 진행하자 백엔드에서 예외가 발생하며 서버가 뻗어버렸습니다.

java.sql.SQLTransientConnectionException: 
  HikariPool-1 - Connection is not available, request timed out after 30000ms.

이 에러는 Spring Boot 서버가 DB와 통신하기 위해 커넥션 풀(Connection Pool)에서 커넥션을 빌리려 했으나 남는 커넥션이 없어 타임아웃이 발생했다는 뜻입니다.

2. 원인: Supabase 무료 티어의 Connection Limit

원인은 백엔드 코드가 아닌 인프라 한계에 있었습니다. PostgreSQL을 호스팅해 주는 Supabase 무료 티어의 최대 동시 접속(Max Connections) 허용치는 15개입니다.
반면 Spring Boot가 구동될 때 사용하는 HikariCP의 maximumPoolSize 기본값은 10입니다. 배포된 서버와 로컬 개발 서버가 동시에 켜져 있으면 순식간에 20개가 넘어 DB가 연결을 거부(Reject)한 것입니다.

커넥션 소비 계산:
  Render(배포 서버) : HikariCP 기본 10개
+ 로컬(개발 서버)   : HikariCP 기본 10개
= 총 20개 동시 커넥션 시도
→ Supabase 허용치: 15개 →   Connection Refused!

3. 트러블슈팅: HikariCP 파라미터 극단적 튜닝

제한된 리소스에 맞게 애플리케이션 설정을 극단적으로 최적화해야 했습니다. 실제 프로젝트의 application.yml 설정입니다.

# application.yml — HikariCP 커넥션 풀 튜닝
spring:
  datasource:
    url: ${DATABASE_URL}
    driver-class-name: org.postgresql.Driver
    username: ${DATABASE_USER:postgres}
    password: ${DATABASE_PASSWORD:}
    hikari:
      maximum-pool-size: 3    # 동시 커넥션을 최대 3개로 제한
      minimum-idle: 1          # 유휴 커넥션도 1개로 최소화

# MyBatis 설정 — 쿼리 타임아웃으로 이중 방어
mybatis:
  mapper-locations: classpath:mapper/*.xml
  configuration:
    map-underscore-to-camel-case: true
    default-fetch-size: 100
    default-statement-timeout: 30   # 30초 이상 걸리는 쿼리는 강제 종료

왜 3으로 줄였을까?

maximum-pool-size: 3: 백엔드 서버가 아무리 바쁘고 트래픽이 몰려도, DB로 향하는 동시 커넥션을 절대 3개 이상 뚫지 않도록 스로틀링(Throttling)을 걸었습니다. 유휴 커넥션도 1개로 제한했습니다.

튜닝 후 커넥션 소비:
  Render(배포 서버) : HikariCP 3개
+ 로컬(개발 서버)   : HikariCP 3개
= 총 6개 동시 커넥션
→ Supabase 허용치: 15개 → ✅ 여유 확보!

이로써 로컬 서버와 배포 서버가 동시에 켜져 있어도 Supabase 자체가 죽어버리는 현상을 원천 방어했습니다.

프로덕션 프로필 분리

application.yml에서 --- 구분자로 프로덕션 환경을 분리했습니다.

---
# Production profile (Supabase PostgreSQL)
spring:
  config:
    activate:
      on-profile: prod

  datasource:
    url: ${DATABASE_URL}
    driver-class-name: org.postgresql.Driver
    hikari:
      maximum-pool-size: 3
      minimum-idle: 1

server:
  port: ${PORT:8080}   # Render가 주입하는 PORT 환경변수 사용

Dockerfile의 ENTRYPOINT에서 -Dspring.profiles.active=prod를 지정하여, 프로덕션 환경에서는 항상 Supabase에 연결되도록 설정했습니다.

4. 마무리

클라우드 생태계를 이용할 때는 제공자가 숨겨둔 하드 리밋(Hard Limit)을 런타임 이전에 반드시 파악해야 합니다. 인프라의 한계를 소프트웨어(HikariCP 튜닝)로 우아하게 방어하며 서비스 안정성을 확보했습니다.

[K8s] 인프라 배포의 패러다임 시프트: GitOps와 OCI 레지스트리의 이해

예르미(yermi) — Wed, 15 Jul 2026 22:27:20 +0900

이번 글에서는 전통적인 CI/CD 방식의 한계를 극복하기 위해 등장한 GitOps(깃옵스) 패턴과, 최근 GitOps의 단일 진실 공급원(Source of Truth)으로 새롭게 주목받고 있는 OCI(Open Container Initiative) 레지스트리의 개념을 정리해 봅니다.

1. Push형 가고 Pull형 온다: 전통적 CD와 GitOps의 차이

기존의 전통적인 배포 방식(Jenkins, GitLab CI 등)은 가상 머신(VM)이나 서버에 원격으로 접속해 배포 스크립트를 실행하는 Push 방식이었습니다.

전통적인 Push 방식: CI/CD 툴이 K8s 클러스터의 API 권한(kubeconfig 등)을 직접 가지고, 밖에서 클러스터 안으로 kubectl apply -f deployment.yaml 명령을 밀어 넣는(Push) 형태입니다.
문제점: 외부의 CI/CD 툴이 클러스터의 막강한 관리자 권한을 상시 보유해야 하므로 보안상 취약점이 생깁니다. 또한 누군가 실무에서 kubectl로 직접 설정을 바꾸면, Git 레포지토리의 코드와 실제 인프라의 상태가 불일치하는 현상이 발생합니다.

이 문제를 해결하기 위해 등장한 개념이 바로 GitOps이며, 이를 구현한 대표적인 오픈소스가 Argo CD와 Flux입니다. GitOps는 Pull 방식을 사용합니다.

Push형 CD vs Pull형 GitOps 비교

작동 원리: K8s 클러스터 내부에 배포된 GitOps 에이전트(예: Argo CD)가 지정된 Git 레포지토리를 계속 감시(Polling)합니다. Git에 저장된 YAML 파일과 현재 클러스터의 상태가 다르면, 에이전트가 클러스터 내부에서 스스로 변경 사항을 당겨와(Pull) 싱크를 맞춥니다.
장점: 클러스터 외부로 배포 권한을 노출할 필요가 없어 보안이 극대화됩니다. 인프라의 모든 변경 이력이 Git 커밋 로그로 남기 때문에 추적과 롤백이 매우 정교해집니다.

2. "OCI is not Git": 왜 GitOps의 저장소로 OCI를 고민할까?

GitOps 환경이 성숙해지면서, 대규모 인프라를 관리하는 엔지니어들 사이에서 새로운 화두가 던져졌습니다. 바로 "쿠버네티스 명세서(YAML)를 반드시 Git 레포지토리에만 저장해야 하는가?"에 대한 의문입니다.

여기서 등장한 개념이 OCI(Open Container Initiative) 아티팩트 활용입니다.

원래 OCI 레지스트리(예: Docker Hub, AWS ECR, GitLab Container Registry 등)는 'Docker 이미지'를 저장하는 공간이었습니다. 하지만 OCI 스펙이 발전하면서, 이제는 이미지뿐만 아니라 K8s YAML 파일, Helm 차트 등 클라우드 네이티브 환경의 모든 정적 아티팩트를 묶어서 버저닝하고 저장할 수 있게 되었습니다.

Git 저장소 대신 OCI 레지스트리를 활용할 때의 이점

대규모 커밋으로 인한 Git 오버헤드: 수백 개의 마이크로서비스가 배포될 때마다 GitOps 배포용 Git 레포지토리에 수많은 자동 커밋이 발생합니다. 이는 Git 서버의 성능 저하와 API 레이트 리밋(Rate Limit) 문제로 이어집니다.
보안 및 접근 제어의 한계: 배포 명세서에 접근해야 하는 에이전트가 늘어날수록 Git 레포지토리 자체의 접근 권한 관리가 복잡해집니다.
불필요한 변경 이력의 비대화: 소스 코드가 아닌 컴파일된 배포본(YAML 결과물)의 단순 텍스트 변경 이력이 Git 히스토리에 무겁게 쌓이게 됩니다.

이러한 한계를 극복하기 위해, CI 파이프라인에서 렌더링이 완료된 최종 K8s 배포 명세서(YAML)를 OCI 아티팩트 패키지 형태로 빌드하여 이미지 레지스트리에 푸시하고, K8s 클러스터 안의 GitOps 에이전트(Flux 등)는 이 OCI 레지스트리를 '단일 진실 공급원(Source of Truth)'으로 바라보고 동기화하는 아키텍처가 대안으로 부상하고 있습니다.

3. 요약: 현대적인 배포 파이프라인의 모습

OCI 레지스트리 기반 GitOps 파이프라인

결국 배포 자동화의 미래는 "모든 산출물을 OCI라는 표준 규격으로 패키징하고, 클러스터 내부의 에이전트가 이를 안전하게 당겨와 스스로 동기화(GitOps)하는 구조"로 수렴하고 있습니다.

[KubeCon Japan 2026] 참관 준비 : 백엔드 및 인프라 아키텍트의 시선으로 픽한 핵심 세션 라인업

예르미(yermi) — Mon, 13 Jul 2026 00:36:53 +0900

KubeCon + CloudNativeCon Japan 2026 티켓 등록을 마치고, 본격적으로 3일간의 타임테이블을 구성해 보았습니다. 넘쳐나는 훌륭한 세션들 사이에서, 실무 아키텍처 고도화와 대규모 시스템 스케일링에 직접적인 영감을 줄 수 있는 핵심 트랙들을 선별했습니다.

1. AI-Native Observability & AIOps (최우선 관심사)

시스템의 가시성을 확보하고 장애를 사전에 제어하는 AIOps 아키텍처에 관심이 많은 만큼, 가장 눈여겨보고 있는 트랙들입니다.

수요일 오후 4시 30분에 진행되는 "From Tool Calls to Context Fabric: Building AI-Native Observability for Platform Engineering" 세션은 이번 행사에서 꼭 들어야 할 1순위입니다. 이 세션은 AI 기반의 관측성을 플랫폼 엔지니어링 생태계에 어떻게 녹여낼 수 있는지 다루고 있습니다.
수요일 오후 2시 10분에는 Kevin Dubois와 Carlos Sanchez가 진행하는 "AIOps: (near) Zero-Touch Production Rollout Fixes" 세션이 열립니다. 복잡한 백엔드 시스템의 롤아웃 과정에서 AI를 활용해 어떻게 무중단 배포 안정성을 확보하고 픽스(Fix)를 자동화하는지에 대한 해답을 찾을 수 있을 것 같습니다.
수요일 오후 2시 50분에는 클라우드 네이티브 생태계 전반의 AI 전환 흐름을 거시적으로 짚어주는 "The State of Cloud Native: The Shift Towards AI" 세션도 놓치지 않고 챙길 예정입니다.

2. ️ 대규모 멀티 클러스터 확장과 플랫폼 엔지니어링

마이크로서비스 아키텍처가 고도화됨에 따라 리소스를 효율적으로 분산하고 통제하는 진정한 의미의 플랫폼 엔지니어링 철학을 엿볼 수 있는 세션들입니다.

수요일 오후 12시 10분, "Don't Start With 500 Clusters: Patterns in Scaling Multi-Cluster Kubernetes Using Cluster API" 세션에서는 Cluster API를 활용한 멀티 클러스터 스케일링 안티 패턴과 최적화 패턴을 깊이 있게 분석합니다.
수요일 오전 11시 30분에는 GitOps의 진실 공급원(Source of Truth)을 완전히 새로운 관점에서 바라보는 "OCI is not Git: Rethinking the GitOps Source of Truth for a Kubernetes-Native World" 세션이 진행됩니다.
OCI 아티팩트를 활용해 기존 Git 기반의 선언적 배포 파이프라인이 어떻게 진화하고 있는지 아키텍처 관점에서 확인해 볼 계획입니다.
수요일 오후 5시 10분에는 엔터프라이즈 환경 고유의 사일로(Silo) 현상을 타파한 사례를 다루는 "From 165 Days to 30 Minutes: Breaking Enterprise Silos with Platform Engineering" 세션이 준비되어 있습니다.

3. AI 에이전트 도입 및 고트래픽 시스템 대응

최근 높은 트래픽이 발생하는 비즈니스 로직에 관심이 많아졌는데, 이를 뒷받침할 인프라와 AI 에이전트의 엔터프라이즈 스케일링 실사례를 확인할 수 있는 트랙입니다.

수요일 오후 3시 50분에는 AI 기반의 코드 리뷰 에이전트를 엔터프라이즈 규모로 어떻게 확장하는지 보여주는 "From Experiment to Enterprise: Scaling an AI Agent for Code Review" 세션이 열립니다.
목요일 오전 11시 30분에는 "Running OpenSearch at Scale in High-Traffic Gaming Systems" 세션이 진행됩니다. 트래픽 스파이크가 일상적으로 발생하는 게이밍 환경에서 대규모 로그와 검색을 처리하기 위한 OpenSearch 스케일아웃 노하우를 상세히 배울 수 있을 것으로 기대합니다.

DAY 1의 마무리: 네트워킹 쉴 틈 없이 쏟아지는 수요일 세션들이 끝나고 나면,
오후 5시 45분부터 3층에서 "Welcome Reception"이 시작됩니다.

다양한 세션을 통해 얻은 기술적 영감을 바탕으로, 현장의 글로벌 쿠버네티스 메인테이너 및 전 세계 엔지니어들과 깊이 있는 네트워킹을 즐길 생각에 벌써부터 벅차오르네요. 요코하마 현장에서 직접 보고 느낀 생생한 클라우드 네이티브 트렌드와 기술적 딥다이브는 다녀와서 자세히 포스팅하겠습니다!

[오늘가챠] 비용 0원 무중단 배포 파이프라인 구축기 (Vercel + Render)

예르미(yermi) — Sat, 11 Jul 2026 16:12:15 +0900

사이드 프로젝트의 성패는 '얼마나 개발 이외의 인프라 공수를 줄일 수 있는가'에 달려있습니다. 코드 한 줄 작성할 시간도 부족한데, 리눅스 서버에 접속해 배포 스크립트를 고치고 Nginx 리버스 프록시를 튜닝하는 것은 굉장한 피로를 유발합니다. 이를 해결하기 위해 프론트엔드는 Vercel, 백엔드는 Render를 활용하여 완전 자동화된 배포 파이프라인을 구축했습니다.

CI/CD 배포 파이프라인

1. 프론트엔드: Vercel이 가져다준 개발 경험(DX)의 혁신

과거에는 AWS S3 버킷에 빌드된 리액트 파일을 올리고 CloudFront 캐시를 갱신(Invalidation)하는 GitHub Actions 스크립트를 직접 짜야 했습니다. Vercel은 이 과정을 생략합니다.

Preview Deployment (미리보기 배포)

가장 만족스러웠던 기능은 PR(Pull Request) 단계에서 제공되는 Preview Deployment입니다.
새로운 기능을 브랜치에서 작업하고 PR을 올리면, Vercel이 해당 브랜치만을 위한 독립적인 URL을 즉시 생성해 줍니다.

로컬에서 브랜치를 체크아웃받고 npm run dev를 실행할 필요 없이, 핸드폰 브라우저로 링크만 열어서 모바일 UI를 바로 테스트할 수 있었습니다.
1인 개발 사이드 프로젝트에서도 '셀프 코드 리뷰'와 '모바일 실기기 테스트'의 질을 엄청나게 높여주었습니다.

Vercel 프로젝트 설정

실제 프로젝트의 vercel.json 설정입니다. 단 13줄로 빌드 명령, API 프록시, 프레임워크 지정까지 모두 끝납니다.

{
  "buildCommand": "npm run build",
  "outputDirectory": "dist",
  "installCommand": "npm install",
  "framework": "vite",
  "rewrites": [
    {
      "source": "/api/:path*",
      "destination": "https://<your-app>.onrender.com/api/:path*"
    }
  ]
}

rewrites 설정 한 방으로 프론트엔드의 /api/* 요청이 Render 백엔드로 자동 프록시 되어, CORS 설정의 복잡함을 제거했습니다.

2. 백엔드: Render의 Docker 배포와 Cold Start 방어

백엔드는 Spring Boot(Java)를 사용했습니다. Render는 IaaS가 아닌 PaaS이므로, 서버 인스턴스를 관리할 필요가 없습니다.

환경 파편화 방지: Multi-stage Dockerfile 배포

로컬과 운영 서버의 자바(Java) 버전 파편화를 막기 위해 멀티 스테이지 빌드 Dockerfile을 작성하여 Render에 배포했습니다.

# Stage 1: Build — Gradle로 bootJar 생성
FROM eclipse-temurin:17-jdk-alpine AS builder
WORKDIR /app
COPY gradlew .
COPY gradle gradle
COPY build.gradle settings.gradle ./
RUN chmod +x gradlew
RUN ./gradlew dependencies --no-daemon || true
COPY src src
RUN ./gradlew bootJar --no-daemon -x test

# Stage 2: Run — 경량 JRE 이미지에서 실행
FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
COPY --from=builder /app/build/libs/*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-Dspring.profiles.active=prod", "-jar", "app.jar"]

핵심 포인트: jdk-alpine으로 빌드하고 jre-alpine으로 실행하는 멀티 스테이지 전략으로, 최종 이미지 사이즈를 400MB → 약 150MB로 줄였습니다. Render의 무료 빌드 시간(Free Tier)과 메모리를 아끼는 데 크게 기여했습니다.

Render 대시보드에 GitHub 레포를 연결하고 환경을 Docker로 지정하면, 코드가 푸시될 때마다 Render가 위 파일을 읽어 자동으로 컨테이너를 빌드하고 무중단 배포를 수행합니다.

치명적 단점, Cold Start 방어전

Render의 무료 플랜(Free Tier)은 15분 동안 외부 요청이 없으면 인스턴스를 수면(Sleep) 상태로 전환합니다. 이후 유저가 접속하면 서버가 깨어나는 데(Cold Start) 30초~1분 이상이 소요되어 끔찍한 UX를 초래합니다. 이를 막기 위해 /health 엔드포인트를 직접 구현했습니다.

// HealthController.java — UptimeRobot이 핑하는 대상
@RestController
public class HealthController {

    @GetMapping("/health")
    public ResponseEntity<Map<String, String>> health() {
        return ResponseEntity.ok(Map.of("status", "ok"));
    }
}

그리고 UptimeRobot이라는 무료 외부 모니터링 서비스에 가입하여, 위 /health 엔드포인트로 10분마다 핑(HTTP GET)을 날리도록 설정했습니다. 이 꼼수(?) 덕분에 백엔드 서버는 24시간 잠들지 않고 즉각적인 API 응답을 보장하게 되었습니다.

Spring Boot Actuator 대신 직접 구현한 이유: Actuator를 의존성에 추가하면 /actuator/health 외에도 다수의 관리 엔드포인트가 자동 노출됩니다. 보안 설정에 신경 쓸 여유가 없었기에, 딱 필요한 한 줄짜리 컨트롤러를 직접 작성했습니다.

3. 마무리

Vercel과 Render의 조합은 1인 개발자에게 축복과도 같습니다. CI/CD 구축과 인프라 관리에 들어갈 수십 시간을 아껴 핵심 비즈니스 로직 개발에 투자할 수 있었습니다. 다음 편에서는 데이터베이스로 활용한 Supabase와, 그곳에서 마주친 끔찍한 '커넥션 풀 고갈' 에러 해결 과정에 대해 다루겠습니다.

[K8s] 외부 트래픽 라우팅의 진화: Ingress에서 Gateway API까지

예르미(yermi) — Wed, 8 Jul 2026 22:23:57 +0900

이번 글에서는 외부 트래픽을 K8s 클러스터 내부로 안전하고 정교하게 라우팅하기 위한 L7(애플리케이션 계층) 네트워크 기술의 진화 과정을 살펴봅니다. 기존의 표준이었던 Ingress의 한계점과, 이를 극복하기 위해 등장한 차세대 표준 Gateway API의 개념을 백엔드 개발자의 시각에서 정리합니다.

1. Service의 한계와 Ingress의 등장

K8s의 Service는 기본적으로 L4(TCP/UDP) 레벨의 로드밸런서 역할을 합니다.

만약 백엔드 시스템이 커져서 api.example.com/user는 User 서비스(Pod)로, api.example.com/order는 Order 서비스(Pod)로 보내야 하는 HTTP 라우팅이 필요하다면 어떻게 할까요? 기존 인프라 환경이라면 Nginx나 Spring Cloud Gateway 같은 L7 리버스 프록시(Reverse Proxy)를 앞단에 두었을 것입니다.

K8s에서는 이 역할을 Ingress(인그레스)가 담당해 왔습니다.

Ingress 리소스: "특정 도메인이나 경로(Path)로 들어온 요청을 어떤 Service로 보낼지" 정의한 라우팅 규칙(YAML)입니다.
Ingress Controller: 이 규칙을 실제로 읽어들여 트래픽을 분산시키는 실체입니다. Nginx Ingress Controller가 가장 유명합니다.

2. Ingress의 한계: "어노테이션(Annotation) 지옥"

Ingress는 오랫동안 K8s의 표준으로 쓰였지만, 클라우드 네이티브 환경이 복잡해지면서 뚜렷한 한계를 드러내기 시작했습니다.

가장 큰 문제는 Ingress의 기본 스펙이 너무 단순하다는 것이었습니다. 경로 기반 라우팅 정도만 기본 지원할 뿐, 카나리 배포를 위한 가중치 기반 트래픽 분산(Traffic Splitting)이나 특정 HTTP 헤더를 기반으로 한 라우팅, 정교한 타임아웃 설정 등은 표준 스펙에 없었습니다.

이를 해결하기 위해 개발자들은 Nginx 등 각 컨트롤러가 제공하는 자체 어노테이션(Annotation)을 YAML 파일에 덕지덕지 붙여야 했습니다.

# Ingress 어노테이션 지옥의 예시
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
    # 컨트롤러가 바뀌면 이 어노테이션들은 모두 무용지물이 됩니다.

결국 이 방식은 표준화가 무너지고 특정 벤더(Nginx, HAProxy 등)에 완전히 종속되는 결과를 낳았습니다. 또한, 인프라 관리자와 백엔드 개발자가 하나의 Ingress 파일을 수정하다가 설정이 꼬이는 권한 분리의 문제(RBAC)도 존재했습니다.

Ingress vs Gateway API 아키텍처 비교

3. 차세대 표준: Gateway API의 등장

이러한 Ingress의 한계를 극복하고, K8s L7 네트워킹의 진정한 표준을 세우기 위해 등장한 것이 바로 Gateway API입니다. (참고: API Gateway 패턴과는 다른, K8s의 리소스 이름입니다.)

Gateway API는 거대한 하나의 Ingress 리소스를 역할(Role)에 따라 3가지 오브젝트로 분리한 것이 핵심입니다.

GatewayClass: "우리는 어떤 인프라(AWS ALB, Istio, Nginx 등)를 사용할 것인가?"를 정의합니다. (인프라 제공자 담당)
Gateway: 클러스터 진입점의 IP, 포트, TLS(SSL) 인증서 등을 정의합니다. (클러스터 관리자 담당)
HTTPRoute: "/user로 오면 User Service로 보내고, 헤더에 x-test=true가 있으면 테스트 v2 Service로 보내라" 같은 애플리케이션 레벨의 정교한 라우팅 규칙을 정의합니다. (백엔드 개발자 담당)

백엔드 개발자 관점에서의 Gateway API 장점

명확한 역할 분담 (Role-Oriented): 백엔드 개발자는 인프라 설정이나 인증서를 신경 쓸 필요 없이, 오직 자신의 서비스 라우팅 규칙인 HTTPRoute 리소스만 관리하면 됩니다.
표준화된 강력한 라우팅: 더 이상 어노테이션에 의존하지 않아도 됩니다. HTTP 헤더 매칭, 트래픽 가중치 분배(A/B 테스트), 리다이렉트 같은 고급 기능이 HTTPRoute의 공식 표준 스펙으로 내장되어 있습니다.

4. 요약: K8s 트래픽 아키텍처의 완성

정리하자면, 외부 트래픽이 K8s 내부의 Spring Boot 앱까지 도달하는 현대적인 파이프라인은 다음과 같이 그려집니다.

K8s 트래픽 아키텍처: Gateway → HTTPRoute → Service → Pod

Ingress에서 Gateway API로의 전환은 단순히 도구가 바뀌는 것을 넘어, 인프라 관리와 애플리케이션 개발의 관심사를 분리하고 책임을 명확히 하는 과정입니다. 현재 새롭게 구축되는 K8s 클러스터들은 빠르게 Gateway API를 채택하고 있는 추세입니다.

[KubeCon Japan 2026] Dan Kohn 장학금 선정 및 등록 완료! 요코하마로 갑니다⚓

예르미(yermi) — Sat, 4 Jul 2026 23:30:12 +0900

올해 AWS 서밋을 비롯해 여러 테크 박람회를 둘러보며 인프라와 클라우드 생태계의 변화를 체감하고 있었는데, 오픈소스 및 클라우드 네이티브 진영의 가장 거대한 축제인 KubeCon + CloudNativeCon Japan 2026에 참여할 수 있는 뜻깊은 기회가 생겼습니다.

CNCF(Cloud Native Computing Foundation)에서 운영하는 Dan Kohn 장학금(Dan Kohn Scholarship) 프로그램에 지원했었는데, 감사하게도 수혜자로 선정되어 콘퍼런스 무료 티켓을 받게 되었습니다. 신청해 두고 내심 기대하고 있었는데 합격 레터를 받으니 개발자로서 정말 뿌듯하네요.

Linux Foundation으로부터 반가운 합격 통지서

개발자로서 기대하는 관전 포인트

이번 KubeCon + CloudNativeCon Japan 2026은2026년 7월 28일부터 30일까지 일본 요코하마에 위치한 PACIFICO Yokohama에서 개최됩니다. 마침 날짜도 딱 한 달 정도 남은 시점이라 타이밍이 아주 좋습니다.

글로벌 KubeCon을 직접 참관하는 것은 이번이 처음이라 기대가 큽니다. 최근 국내외를 막론하고 플랫폼 엔지니어링(Platform Engineering)과 클라우드 네이티브 아키텍처의 내재화가 다각도로 이루어지고 있는 만큼, 현업 백엔드 개발자 관점에서 깊이 있게 살펴보고 싶은 테마들이 많습니다.

쿠버네티스 생태계의 현재와 미래: 컨테이너 오케스트레이션의 표준을 넘어, 대규모 분산 환경에서 클러스터 관리를 얼마나 더 효율적이고 선언적으로 제어할 수 있는지 글로벌 메인 테이너들의 세션을 통해 확인해 보고 싶습니다.
클라우드 네이티브 모니터링 및 관측성(Observability): 복잡해지는 인프라 구조 속에서 메트릭, 로그, 트레이스를 매끄럽게 파이프라인화하여 시스템 가시성을 확보하는 글로벌 오픈소스 프로젝트들의 최신 트렌드를 직접 파헤쳐 볼 생각입니다.

앞으로의 준비 계획

장학금으로 티켓은 해결했으니, 이제 남은 건 요코하마로 떠나기 위한 개인 여정을 준비하는 일입니다. 7월 말 본격적인 휴가철과 겹치는 일정이라 마음을 단단히 먹고 빠르게 움직여야 할 것 같습니다.

항공권 및 요코하마 숙소 예약: 퍼시피코 요코하마 전시장과 접근성이 좋은 동선으로 빠르게 비행기와 숙소를 알아볼 예정입니다.
타임테이블 빌드: 3일 동안 쏟아지는 수많은 세션 중 실무 아키텍처 설계와 오픈소스 동향에 영감을 줄 수 있는 핵심 트랙들을 미리 선별해 나만의 스케줄러를 채워야겠습니다.

글로벌 엔지니어들과 교류하고 최신 기술의 정수를 맛볼 수 있는 기회를 얻은 만큼, 다녀와서 블로그에 개발자 관점의 밀도 높은 테크 리포트를 공유할 수 있도록 준비해 보겠습니다. 요코하마에서 열릴 클라우드 네이티브 축제가 벌써부터 기다려지네요!

KubeCon + CloudNativeCon Japan | LF Events

The Cloud Native Computing Foundation’s flagship conference gathers adopters and technologists from leading open source and cloud native communities.

events.linuxfoundation.org

[오늘가챠] 프로젝트 오버뷰: 왜 이 스택을 선택했는가?

예르미(yermi) — Sat, 4 Jul 2026 14:51:30 +0900

'오늘가챠'는 유저가 찍은 평범한 일상 사진을 화려한 TCG(Trading Card Game) 카드로 만들어주는 서비스입니다.

단순한 이미지 업로드 게시판을 넘어서, 유저 간의 수집욕을 자극하고 실시간으로 카드를 뽑는 경험을 제공하는 것이 핵심 기획이었습니다. 이를 구현하기 위해 비용을 0원에 가깝게 유지하면서도 안정적이고 빠른 서비스를 제공할 수 있는 아키텍처 설계가 필요했습니다.

오늘가챠 시스템 아키텍처

1. 기획의 제약 사항과 인프라의 조건

1인 개발로 진행되는 사이드 프로젝트 특성상 다음과 같은 뚜렷한 제약 사항이 있었습니다.

무자본 (비용 최적화): AWS EC2, RDS, S3를 깡통으로 세팅하면 월 최소 수만 원의 고정 비용이 발생합니다. 트래픽이 보장되지 않은 상태에서 이는 큰 부담입니다.
개발 속도: 인프라 설정(Nginx, SSL 발급, 로드 밸런싱)에 리소스를 쏟기보다는, AI 프롬프트 엔지니어링이나 프론트엔드 UX 개선에 시간을 쏟아야 했습니다.
대량의 이미지 처리: TCG 게임 특성상 고화질 이미지가 넘쳐납니다. 이를 서버에서 직접 리사이징하고 서빙하면 백엔드가 뻗어버릴 것이 자명했습니다.

2. 각 레이어별 기술 스택 선정 이유

프론트엔드: Vercel (React + Vite)

Zero-config 배포: GitHub 리포지토리와 연결하면 main 브랜치 푸시만으로 빌드부터 배포, 캐시 무효화까지 자동화됩니다.
Edge Cache: 전 세계 CDN 네트워크에 정적 에셋이 자동 캐싱되어, 화려한 UI 자원들이 유저와 가장 가까운 엣지 노드에서 서빙됩니다. (초기 로딩 속도 극대화)

Vercel의 API 프록시 기능은 vercel.json 한 줄로 FE와 BE 간의 CORS 문제를 우아하게 해결해 줍니다.

{
  "buildCommand": "npm run build",
  "outputDirectory": "dist",
  "framework": "vite",
  "rewrites": [
    {
      "source": "/api/:path*",
      "destination": "https://<your-app>.onrender.com/api/:path*"
    }
  ]
}

백엔드: Render (Spring Boot + Docker)

IaaS 대신 PaaS: AWS EC2에 직접 서버 환경을 구축하는 대신, Render를 통해 Docker 컨테이너를 그대로 배포했습니다.
자동화된 SSL 및 로드 밸런싱: Let's Encrypt 스크립트를 작성할 필요 없이, Render가 알아서 HTTPS 통신을 보장해 줍니다. 백엔드 개발자는 오직 비즈니스 로직에만 집중할 수 있습니다.

데이터베이스 & 인증: Supabase (PostgreSQL)

RDBMS의 필요성: NoSQL(Firebase)로는 유저, 카드, 인벤토리, 가챠 로그 등 복잡하게 얽힌 관계형 데이터를 무결성 있게 관리하기 어려웠습니다. Supabase는 강력한 PostgreSQL을 기반으로 합니다.
BaaS의 편의성: DB 서버 세팅 없이 GUI 툴을 제공하며, JWT 기반의 Auth(인증) 시스템이 내장되어 있어 로그인 구현 공수를 획기적으로 줄여주었습니다.

실제 프로젝트에서는 아래 DDL로 테이블을 관리합니다.

-- 핵심 테이블 구조 (schema.sql 발췌)
CREATE TABLE IF NOT EXISTS users (
    id          BIGSERIAL PRIMARY KEY,
    username    VARCHAR(50)  NOT NULL UNIQUE,
    nickname    VARCHAR(50),
    password    VARCHAR(255) NOT NULL,
    gold        INT          NOT NULL DEFAULT 0,
    gems        INT          NOT NULL DEFAULT 0,
    role        VARCHAR(10)  DEFAULT 'USER',
    created_at  TIMESTAMP    DEFAULT NOW()
);

CREATE TABLE IF NOT EXISTS photos (
    id            BIGSERIAL PRIMARY KEY,
    user_id       BIGINT       NOT NULL REFERENCES users(id),
    image_url     VARCHAR(500) NOT NULL,
    theme         VARCHAR(20),
    rarity        VARCHAR(1),
    cp            INT,
    status        VARCHAR(10)  NOT NULL DEFAULT 'DRAFT',
    ai_name       VARCHAR(100),
    ai_flavor     VARCHAR(500),
    created_at    TIMESTAMP    DEFAULT NOW()
);

CREATE TABLE IF NOT EXISTS cards (
    id          BIGSERIAL PRIMARY KEY,
    user_id     BIGINT    NOT NULL REFERENCES users(id),
    photo_id    BIGINT    NOT NULL REFERENCES photos(id),
    level       INT       NOT NULL DEFAULT 1,
    is_favorite BOOLEAN   NOT NULL DEFAULT false,
    created_at  TIMESTAMP DEFAULT NOW()
);

미디어 서버 (CDN): Cloudinary

On-the-fly 최적화: 프론트엔드에서 이미지를 요청할 때 URL에 파라미터(f_auto, q_auto)만 추가하면, Cloudinary 엣지 서버가 실시간으로 WebP 포맷으로 변환 및 리사이징하여 내려줍니다. 백엔드의 이미지 처리 부담을 0으로 만들었습니다.

실제 백엔드 업로드 클라이언트 코드에서도 자동 변환을 설정해 두었습니다.

// CloudinaryClient.java — 업로드 시 자동 최적화 적용
public String upload(byte[] imageBytes) throws IOException {
    Map<String, Object> result = cloudinary.uploader().upload(imageBytes, ObjectUtils.asMap(
        "folder", "<your-folder>",
        "transformation", new Transformation()
            .width(800).crop("scale")
            .quality("auto").fetchFormat("auto")
    ));
    return (String) result.get("secure_url");
}

3. 프로덕션 배포 인프라 요약

서비스	플랫폼	역할	비용
프론트엔드	Vercel	정적 호스팅 + API 프록시	무료
백엔드	Render	Spring Boot API (Docker)	무료
DB	Supabase	PostgreSQL + Auth	무료
이미지	Cloudinary	이미지 업로드/CDN	무료 (25GB)
AI 분석	Gemini	사진 → 카드 메타데이터 생성	무료 (RPM 제한)
모니터링	UptimeRobot	`/health` 핑 (Cold Start 방지)	무료

4. 마무리

이렇게 6가지 모던 클라우드 서비스를 레고 블록처럼 조립하여, 엔터프라이즈급 퍼포먼스를 내면서도 유지보수 비용은 0원에 수렴하는 아키텍처를 완성했습니다. 다음 편에서는 프론트엔드와 백엔드의 무중단 배포 파이프라인 구축 과정을 상세히 알아보겠습니다.

[K8s] 스프링부트 개발자를 위한 쿠버네티스 생존 가이드

예르미(yermi) — Fri, 3 Jul 2026 17:51:17 +0900

쿠버네티스(Kubernetes, K8s)가 IT 인프라의 표준이 되었다는 것은 누구나 안다. 하지만 사내 시스템이 아직 레거시 VM이나 단순 Docker Swarm 환경에 머물러 있다면, K8s의 방대한 생태계는 거대한 진입장벽처럼 느껴진다.

1. 쿠버네티스는 왜 필요한가? (오케스트레이션의 존재 이유)

Docker를 사용해 Spring Boot 애플리케이션을 띄우는 것은 훌륭하다. 하지만 트래픽이 몰려서 컨테이너를 100개로 늘려야 한다면? 컨테이너가 죽었을 때 자동으로 다시 살려야 한다면? 무중단 배포를 해야 한다면?

이러한 '컨테이너들의 배포, 스케일링, 네트워크 유지, 에러 복구'를 자동화해 주는 지휘자(Orchestrator)가 바로 쿠버네티스다.

컨테이너들의 배포, 스케일링, 네트워크 유지, 에러 복구를 자동화해 주는 지휘자, 쿠버네티스

2. K8s 핵심 오브젝트: 백엔드 개발자 관점의 매핑

K8s는 모든 것을 '오브젝트(Object)' 상태로 관리하며, yaml 파일로 "나는 이런 상태를 원해(Declarative)"라고 선언하면 K8s 마스터 노드가 알아서 그 상태를 유지해 준다. 가장 핵심이 되는 3가지만 알아보자.

① Pod (파드): K8s의 가장 작은 배포 단위

비유: Docker 컨테이너 또는 가상 머신(VM)
개념: K8s는 컨테이너를 직접 띄우지 않고, 'Pod'라는 캡슐로 감싸서 띄운다. 보통 1개의 Pod 안에는 1개의 Spring Boot 컨테이너가 들어간다. (필요에 따라 로그 수집용 사이드카 컨테이너를 함께 넣기도 한다.)
특징: Pod는 언제든 죽고 다시 생성될 수 있는 '소모품'이다. 재생성될 때마다 내부 IP가 바뀐다.

② Deployment (디플로이먼트): 무중단 배포와 스케일링의 핵심

비유: Auto Scaling Group + 배포 관리자
개념: "Spring Boot Pod를 항상 3개 유지해 줘"라고 K8s에 명령하는 명세서다.
특징: 트래픽이 늘어나면 Pod 개수를 5개로 늘려주고, 버전업 시 기존 Pod를 하나씩 내리고 새 Pod를 올리는 롤링 업데이트(Rolling Update)를 알아서 처리해 준다.

③ Service (서비스): 고정된 주소를 제공하는 로드밸런서

비유: 내부 Load Balancer (L4)
개념: Pod는 죽고 태어나길 반복하며 IP가 계속 바뀐다고 했다. 그렇다면 프론트엔드나 다른 마이크로서비스는 어떻게 이 API를 호출할까?
특징: Service는 죽지 않는 고정된 IP와 도메인 이름을 제공한다. 클라이언트가 Service를 호출하면, 살아있는 건강한 Pod들에게 트래픽을 알아서 분산(로드밸런싱)해 준다.

K8s 핵심 오브젝트: 백엔드 개발자 관점의 매핑

3. 요약: 트래픽은 어떻게 흐르는가?

사용자가 접속한다.
트래픽이 Service(로드밸런서)에 도착한다.
Service는 현재 살아있는 Pod(Spring Boot 앱) 중 하나로 트래픽을 넘긴다.
만약 Pod가 OOM(Out of Memory)으로 죽으면, Deployment가 즉시 새로운 Pod를 생성해 3개 상태를 유지한다.

트래픽은 어떻게 흐르는가?

[도서리뷰] 하네스 엔지니어링 - 혼자 코딩하고 혼자 Merge하는 AI의 폭주를 막다

예르미(yermi) — Tue, 30 Jun 2026 00:09:41 +0900

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

단일 AI 에이전트는 자신의 실수를 보지 못한다

2026년 현재, Claude Code나 Cursor 같은 AI 코딩 도구는 개발자의 일상이 되었습니다. 프롬프트 하나면 순식간에 코드를 뱉어내는 시대지만, 실무에 이를 적용하다 보면 곧 거대한 벽에 부딪히게 됩니다. 바로 단일 에이전트의 구조적 한계입니다.

가장 치명적인 문제는 AI가 '자신의 실수를 스스로 보지 못한다'는 점입니다. 혼자 PR을 작성하고 스스로 Merge해버리는 구조가 AI 에이전트의 기본값이기 때문입니다. 실제로 2025년 7월에는 한 기업에서 에이전트가 프로덕션 데이터를 삭제하고 "복구 불가"라고 거짓 보고를 했던 끔찍한 사고도 있었습니다.

이러한 통제 불능의 AI를 어떻게 시스템 안으로 안전하게 편입시킬 수 있을까요? 카카오 FDE팀의 황민호(로빈 황) 수석이 집필한 신간 <하네스 엔지니어링>은 이 질문에 대한 가장 완벽하고 체계적인 해답을 제시하는 최초의 실전서입니다.

"모델이 아니라 하네스가 결과를 결정한다." 깃허브 3천 스타를 받은 검증된 아키텍처가 담긴 실전 바이블.

하네스(Harness), 모델 밖의 통제선을 긋다

책에서 말하는 '하네스'란 모델 내부의 가중치를 건드리는 것이 아닙니다. 대신 모델 바깥에 권한, 도구, 검증, 관측을 설계하여 에이전트가 통제된 환경 속에서 스스로 일하게 만드는 구조를 뜻합니다.

가장 충격적이었던 것은 저자가 직접 수행한 A/B 테스트 결과였습니다. 동일한 클로드 모델을 사용했음에도, 단순히 .claude/ 디렉토리의 환경 구성(하네스)을 바꾼 것만으로 성능이 49.5점에서 79.3점으로 수직 상승했다는 기록은 엔지니어로서 엄청난 인사이트를 주었습니다. '프롬프트 엔지니어링'이라는 주술적 영역에서 벗어나, 철저한 '시스템 아키텍처'의 영역으로 AI를 끌어올린 것입니다.

단일 에이전트를 넘어, 팀으로 움직이는 AI. 책임의 분리가 시스템의 안정성을 만든다.

에이전트 팀을 지휘하는 3가지 기둥

이 책은 하네스 시스템을 에이전트, 스킬, 오케스트레이터라는 세 가지 핵심 기둥으로 분해하여 설명합니다.

에이전트(Agent): 가드레일을 통해 에이전트가 '할 수 없는 것'을 파일로 명확히 정의합니다.
스킬(Skill): 'Description' 한 줄이 모델의 호출 여부를 결정한다는 원리(Why-First 원칙 등)를 통해, 도구를 정교하게 설계하는 법을 다룹니다.
오케스트레이터(Orchestrator): 이 책의 백미입니다. 3인 이상의 에이전트가 모였을 때 리더에게 병목이 생기는 현상을 막기 위해, 오케스트레이터를 이벤트 루프와 피어(Peer) 통신(TeamCreate, TaskCreate, SendMessage)으로 풀어내는 과정은 기존 분산 시스템 설계와 완벽하게 맞닿아 있습니다.

파이프라인, 생성-검증, 감독자 패턴 등. 복잡한 AI 프레임워크 없이 Git과 마크다운만으로 구현이 가능하다.

6가지 아키텍처 패턴과 메타스킬

개발자로서 당장 실무에 적용해 보고 싶었던 파트는 후반부의 6가지 아키텍처 패턴이었습니다. 파이프라인, 팬아웃/팬인, 전문가 풀, 생성-검증, 감독자, 계층적 위임 등 상황에 맞는 패턴을 플로우차트를 통해 선택하는 기준을 제시합니다.

특히 코드 리뷰 자동화, 풀스택 기능 구현, 그리고 자그마치 3,500개의 레거시 테스트 파일을 마이그레이션한 시나리오 등은 현업에서 마주하는 골칫거리들을 AI 팀이 어떻게 해결할 수 있는지 완벽한 청사진을 제공합니다. 복잡한 파이썬 프레임워크 지식 없이, Git과 마크다운 파일만 다룰 줄 안다면 이 모든 파이프라인을 구축할 수 있다는 점이 이 책의 가장 큰 무기입니다.

- 총평 및 추천 대상

<하네스 엔지니어링>은 단순히 AI에게 일을 시키는 '사용자'를 넘어, AI가 일하는 '시스템'을 설계하려는 아키텍트를 위한 책입니다.

✅ 이런 분들에게 강력 추천합니다:

클로드 코드 등 AI 도구를 쓰고 있지만, 단일 에이전트의 잦은 실수와 한계에 부딪힌 개발자
하네스라는 개념을 들어봤으나, 실제 마크다운과 Git으로 어떻게 구현하는지 막막했던 분
AI를 개인의 도구로 쓰는 단계를 넘어, 조직의 워크플로(코드 리뷰, 레거시 마이그레이션 등)에 도입하려는 리드 개발자

AI가 작성한 코드를 불안한 눈으로 지켜보는 대신, 견고한 하네스를 입혀 완벽하게 통제된 'AI 개발 팀'을 당신의 서버에 구축해 보시길 바랍니다.

AI를 통제하는 것은 마법 같은 프롬프트가 아니라,
견고하게 설계된 시스템 아키텍처다.

[정보보안기사] 무선 통신 규격(IEEE 802.11) [통신 규격 알파벳, Wi-Fi 세대별 진화]

예르미(yermi) — Fri, 5 Jun 2026 22:46:48 +0900

1. 통신 규격 알파벳 (Wi-Fi 세대별 진화)

이 부분은 "속도와 주파수가 어떻게 발전했는가"의 L1/L2 물리 계층 영역입니다.

b (Basic / Beginning) - 2.4GHz, 11Mbps
- 가장 기본적이고 처음으로 대중화된 규격입니다.
a (Ahead) - 5GHz, 54Mbps
- b보다 시대를 앞서가서(Ahead) 5GHz 주파수를 쓰고 속도도 빨랐지만, 장애물을 못 뚫어서 당시엔 망했습니다.
g (Great) - 2.4GHz, 54Mbps
- b의 넓은 커버리지(2.4GHz)와 a의 빠른 속도(54Mbps)를 합친 아주 훌륭한(Great) 규격입니다.
n (Next generation / aNtenna) - 2.4/5GHz (Wi-Fi 4)
- 안테나 여러 개를 쓰는 기술(MIMO)을 도입한 다음 세대(Next) 규격입니다.
ac (ACcelerated) - 5GHz (Wi-Fi 5)
- 속도를 기가급으로 가속(Accelerated)시킨 5GHz 전용 규격입니다.
ax (AXtreme) - 2.4/5/6GHz (Wi-Fi 6/6E)
- 다중 접속 기술을 넣어 붐비는 곳에서도 극한(eXtreme)의 효율을 내는 최신 규격입니다.

️ 2. 보안 및 기능 알파벳 (시험 출제 1순위 구역)

i (Information Security / Ironclad) WPA2, AES, CCMP
- 가장 중요합니다. 무선 보안의 끝판왕(Ironclad)을 만들기 위해 제정된 '보안 표준'입니다.
- 시험 꿀팁: 문제 지문에 WPA2, AES, CCMP, 802.11i 이 4가지는 무조건 한 세트(JSON 객체)로 묶여서 다닙니다. 넷 중 하나가 나오면 나머지가 정답입니다.
x / 802.1X (aXess Control) 인증, EAP, RADIUS
- 접근을 통제하기 위한 포트 기반 인증 표준입니다. 공유기 비밀번호 하나로 다 들어오는 게 아니라, 사내 인증 서버(RADIUS)를 거쳐서 "너 홍길동 맞아?"를 개별적으로 확인(EAP)하는 기업형 보안 아키텍처입니다.
e (Entertainment / QoS)
- 영상이나 음성 통화(엔터테인먼트) 트래픽이 끊기지 않게 우선순위(QoS)를 부여합니다.
h (Helicopter / Radar)
- 5GHz 대역이 기상 레이더(헬리콥터 등) 주파수와 겹칠 때 간섭을 피하기 위해 사용합니다.

[정보보안기사] 윈도우 보안 아키텍처 : SAM, LSA, SRM [윈도우 보안의 뼈대]

예르미(yermi) — Fri, 5 Jun 2026 22:43:58 +0900

️ 윈도우 보안 아키텍처: 3대 핵심 컴포넌트

윈도우 보안의 뼈대는 크게 DB, 인증 서버, 검문소 3가지로 나뉩니다.

1. SAM (Security Account Manager) - "회원 정보 DB"

역할: 로컬 사용자의 계정 정보와 비밀번호 해시(Hash) 값을 저장하는 데이터베이스 파일입니다.
개발자 비유: 우리가 백엔드에서 만드는 Users 테이블(DB)과 완벽히 같습니다. 평문 비밀번호는 없고 해시값(LM/NTLM 해시)만 들어있습니다.
물리적 위치: %SystemRoot%\System32\config\SAM (윈도우가 켜져 있는 동안에는 커널이 락을 걸고 있어 일반적인 방법으로는 절대 열어볼 수 없습니다.)

2. LSA (Local Security Authority) - "인증 서버 및 보안 총괄 (lsass.exe)"

역할: 사용자가 입력한 ID/PW가 맞는지 검증하고, 성공 시 '액세스 토큰(Access Token)'을 발급하는 윈도우 보안의 심장입니다.
개발자 비유: 로그인 API를 처리하는 'Auth Server(인증 서버)'입니다.
동작 로직: 사용자가 암호를 입력하면, LSA는 그 값을 해시로 변환한 뒤 SAM DB에 쿼리를 날려 값이 일치하는지 비교합니다. 일치하면 사용자에게 "너는 홍길동(SID)이고, 관리자 그룹에 속해 있어"라는 정보가 담긴 액세스 토큰(JWT 토큰 같은 역할)을 쥐여줍니다.

3. SRM (Security Reference Monitor) - "커널 단의 최종 검문소"

역할: 사용자가 특정 파일이나 폴더에 접근하려고 할 때, 이 요청을 허용할지 차단할지 최종 결정하는 커널(Kernel) 모드의 감시자입니다.
개발자 비유: Spring Security의 '권한 인가(Authorization) 필터'나, 파일 시스템 앞단을 지키는 라우터입니다.
동작 로직: 사용자가 파일 더블클릭을 하면, SRM이 나섭니다. "잠깐, 너 아까 LSA한테 받은 액세스 토큰 줘봐." 토큰을 확인한 뒤, 파일에 설정된 ACL(접근 제어 리스트, NTFS 보안 속성)과 비교하여 접근을 승인(Grant)하거나 거부(Deny)하고 이 기록을 감사 로그(Audit Log)로 남깁니다.

전체 파이프라인 시나리오 (로그인부터 파일 열기까지)

이 3가지가 어떻게 협업하는지 데이터 흐름을 추적해 보겠습니다.

[인증/로그인]
- 사용자가 키보드로 ID/PW 입력 (Winlogon 프로세스).
- ➡️ LSA가 이 데이터를 받음.
- ➡️ LSA가 SAM 파일(DB)을 뒤져서 비밀번호 해시가 맞는지 확인.
- ➡️ 성공 시, LSA가 사용자 고유의 SID(Security ID)가 담긴 '액세스 토큰'을 생성해서 던져줌.
[인가/파일 접근]
- 사용자가 1급기밀.docx 파일을 더블클릭.
- ➡️ 커널 모드의 SRM이 요청을 가로챔.
- ➡️ SRM이 사용자의 액세스 토큰과 파일의 ACL(예: "관리자만 읽기 가능")을 비교 (접근 제어).
- ➡️ 일치하면 파일을 열어주고, 아니면 액세스 거부(Access Denied) 에러를 뱉음.

[정보보안기사] 파일 시스템 : FAT32 & NTFS [FAT32 vs NTFS 핵심 스펙 비교]

예르미(yermi) — Fri, 5 Jun 2026 22:39:48 +0900

과거 레거시 규격인 FAT32와 현대 Windows 표준인 NTFS의 아키텍처적 차이와 보안성(기사 시험 단골 출제 포인트)을 명확하게 디버깅해 드리겠습니다.

1. FAT32 (File Allocation Table 32)

아키텍처 구조: 이름 그대로 '파일 할당 테이블(File Allocation Table)'이라는 일종의 인덱스 주소록 배열을 메모리에 올려놓고 파일의 위치를 찾아가는 방식입니다. 32비트 주소 체계를 사용합니다.
치명적인 아키텍처적 한계 (시험 단골):
- 단일 파일 최대 크기 = $4\text{GB} - 1\text{Byte}$ ($2^{32} - 1$ 바이트): 32비트 포인터 상의 한계로 인해, 아무리 큰 1TB짜리 하드디스크를 FAT32로 포맷했더라도 단 하나의 파일 크기가 4GB를 넘는 순간 시스템 크래시(용량 초과 에러)가 발생합니다. 현대의 고화질 동영상 파일이나 대용량 DB 백업 파일을 저장할 수 없는 결정적인 이유입니다.
- 단일 볼륨(드라이브) 최대 크기: 최대 2TB(실무 시스템에 따라 다름)까지만 인식 가능합니다.
보안성의 부재: 앞서 공부하셨던 DAC(임의적 접근 제어)나 ACL(접근 제어 리스트) 개념이 아예 존재하지 않습니다. 즉, 어떤 사용자가 OS로 로그인하든 FAT32에 저장된 파일은 누구나 복사하고 수정할 수 있어 엔터프라이즈 환경에서는 절대 사용할 수 없습니다.

2. NTFS (New Technology File System)

Windows NT 계열부터 도입된 현대적 파일 시스템으로, FAT32의 모든 한계를 오버라이드(Override)하기 위해 설계되었습니다.

아키텍처 구조: MFT (Master File Table)라는 고도화된 관계형 메타데이터 구조를 사용하며, 대용량 디렉토리를 빠르게 탐색하기 위해 내부적으로 B-Tree 인덱스 구조를 채택했습니다.
대용량 스케일 아키텍처:
- 단일 파일 최대 크기: 이론상 16TB~16EB까지 지원하므로 현대의 테라바이트 단위 파일도 아무 문제 없이 IO 처리가 가능합니다.
운영체제 보안의 핵심 (기사 시험 100% 출제):
- 보안성 (ACL 지원): 파일과 디렉토리마다 보안 레이어(Owner, 권한 매핑 룰)를 심을 수 있습니다. 시스템 보안 과목에서 다루는 "특정 계정만 이 폴더를 읽게 해라"는 비즈니스 로직은 전부 NTFS의 ACL 인프라 덕분에 작동합니다.
- 저널링 (Journaling) - 트랜잭션 관리: DB의 ACID 트랜잭션 로그처럼, 파일 시스템에 변경 사항을 쓰기 전에 먼저 '저널(Journal)' 영역에 로그를 기록합니다. 파일 쓰기 도중 갑자기 서버 전원이 나가도(Power Failure), 리부팅 시 저널 로그를 리플레이(Roll-Forward/Roll-Back)하여 파일 시스템이 깨지는 것을 완벽하게 방어(자동 복구)합니다.
- 압축 및 암호화 (EFS): 커널 레벨에서 파일 자체를 투명하게 압축하거나 암호화하는 기능을 내장하고 있습니다.

FAT32 vs NTFS 핵심 스펙 비교

속성	FAT32	NTFS
최대 단일 파일 크기	4GB 제한 (가장 중요)	이론상 제한 없음 (16TB 이상)
보안 기능 (ACL)	지원 안 함 (보안성 전무)	지원함 (사용자 권한 통제 가능)
장애 복구 기능	지원 안 함 (디스크 검사 필요)	저널링(Journaling) 지원 (트랜잭션 복구)
디렉토리 인덱스 구조	선형 리스트 배열	B-Tree 구조 (대용량 고속 탐색)
호환성	임베디드, Mac, Linux 등 최고 수준	Windows 전용 (타 OS에서는 Read-Only인 경우 많음)

[정보보안기사] 트로이 목마(Trojan Horse) 특징 [악성코드 3대장 핵심 아키텍처 비교]

예르미(yermi) — Fri, 5 Jun 2026 22:34:36 +0900

트로이 목마는 왜 악성코드를 전파하지 않을까요? 트로이 목마가 전파를 '못 하는' 것이 아니라, 목적 자체가 은밀한 침투이기 때문에 아예 전파 로직(네트워크 스캐닝, 자가 복제 코드)을 구현하지 않도록 설계되었기 때문입니다. 보안 엔지니어의 관점에서 이 구조적인 차이를 디버깅해 보겠습니다.

1. 전파(Propagation)를 포기하고 얻은 것: 완벽한 '스텔스(Stealth)'

웜(Worm)처럼 스스로 네트워크를 타고 다른 PC로 전파되려면, 쉴 새 없이 IP를 스캐닝하고 취약점(익스플로잇) 패킷을 쏘아대야 합니다.

문제점: 이렇게 활동하면 트래픽이 폭증하여 사내 방화벽이나 IDS/IPS(침입 탐지 시스템)의 경고 로그에 즉각적으로 탐지됩니다.
트로이 목마의 선택: 트로이 목마의 최우선 목적은 랜섬웨어처럼 시끄럽게 감염시키는 것이 아니라, 조용히 백도어를 열어두거나 사용자의 키보드 입력(Keylogging), 공인인증서를 빼내는 것입니다. 따라서 보안 장비의 레이더를 피하기 위해 네트워크를 뒤지는 전파 로직을 과감히 버린 것입니다.

2. 시스템 취약점 대신 '인간의 취약점'을 노리는 아키텍처

트로이 목마는 스스로 복제할 수 없는 대신, 사회공학적 기법(Social Engineering)이라는 아주 확실한 배포 파이프라인을 사용합니다. 고대 그리스의 트로이 목마처럼 '정상적이고 유용한 프로그램'으로 위장하여, 사용자가 직접 클릭해서 실행하도록 유도합니다.

정상적인 엑셀 문서(기획안.xlsx)나, 무료 라이선스 크랙 프로그램(.exe)으로 위장합니다.
사용자가 본인의 의지로 더블 클릭하여 실행하는 순간, 백그라운드에서 악의적인 페이로드(Payload)가 메모리에 올라갑니다.
OS 입장에서는 사용자가 합법적으로 권한을 부여해 실행한 프로세스이므로 차단하기가 매우 까다로워집니다.

악성코드 3대장 핵심 아키텍처 비교 (시험 출제 포인트)

기사 시험에서 이 세 가지의 작동 방식을 묻는 쿼리가 무조건 등장합니다. 명확히 캐싱해 두시길 바랍니다.

구분	바이러스 (Virus)	웜 (Worm)	트로이 목마 (Trojan)
기생 여부	정상 파일(Host)에 기생함 (.exe 감염)	독립적인 실행 파일 (스스로 존재)	독립적인 실행 파일 (정상 프로그램으로 위장)
자기 복제/전파	O (감염된 파일이 이동할 때 퍼짐)	O (네트워크 취약점을 타고 스스로 퍼짐)	X (스스로 복제하거나 전파하지 않음)
핵심 감염 경로	USB, 공유 폴더, 감염된 파일 실행	네트워크 스캐닝, 이메일 자동 발송	사용자의 직접 실행 (피싱, 위장 다운로드)
주요 목적	시스템 파괴, 파일 변조	네트워크 대역폭 고갈 (DDoS 악용)	정보 유출, 백도어 생성, 좀비 PC화

[정보보안기사] 해커의 권한에 따른 4대 암호 공격 모델 [암호문 단독 공격, 알려진 평문 공격, 선택 평문 공격, 선택 암호문 공격]

예르미(yermi) — Fri, 5 Jun 2026 22:30:49 +0900

1. 암호문 단독 공격 (COA - Ciphertext-Only Attack)

해커의 권한: API 접근 권한 없음. (최악의 상황)
상황: 해커가 네트워크 패킷을 스니핑하거나 DB를 털었는데, 원본 데이터는 하나도 없고 오직 fj39d@kd 같은 '암호문'만 잔뜩 쌓여 있는 상태입니다.
해킹 로직: 알파벳 빈도수(e가 제일 많이 쓰인다 등)를 분석하거나 무식하게 전수 공격(Brute-force)을 돌려야 합니다.

2. 알려진 평문 공격 (KPA - Known-Plaintext Attack)

해커의 권한: 과거의 [Input ↔ Output] 로그 데이터 열람 권한.
상황: 해커가 우연히 "서버에 'admin'을 넣으면 'X9s@!'가 나온다"는 과거의 짝꿍(평문-암호문) 데이터베이스를 몇 개 확보했습니다.
해킹 로직: 이 로그 데이터를 머신러닝 모델 돌리듯 통계적으로 분석해서 규칙(선형 방정식)을 찾습니다. (이전 답변에서 말씀드린 '선형 분석(Linear)'이 바로 이 단계입니다.)

3. 선택 평문 공격 (CPA - Chosen-Plaintext Attack) ⭐️ (가장 많이 나옴)

해커의 권한: 서버의 encrypt(data) API 엔드포인트를 마음대로 호출할 수 있음.
상황: 시스템에 취약점이 있어서, 해커가 자기가 원하는 '평문'을 서버에 던지면 서버가 꼬박꼬박 '암호문'으로 변환해서 리턴해 주는 상태입니다.
해킹 로직: A를 넣어보고, 딱 1비트만 바꾼 A'를 넣어보면서 결과값이 어떻게 튀는지 차이를 끈질기게 분석합니다. (이것이 앞서 배운 '차분 분석(Differential)'입니다.)

4. 선택 암호문 공격 (CCA - Chosen-Ciphertext Attack)

해커의 권한: 서버의 decrypt(data) API 엔드포인트를 마음대로 호출할 수 있음. (최강의 권한)
상황: 해커가 쓰레기 같은 '암호문'을 대충 조작해서 서버에 던지면, 서버가 그걸 풀어서 '평문'으로 보여주거나 "패딩 형식이 틀렸어!"라고 에러 로그(Exception)를 뱉어주는 상태입니다.
해킹 로직: 요즘 실무에서도 가장 위험한 공격(예: Padding Oracle Attack)입니다. 해커는 서버가 뱉는 복호화 에러 메시지를 힌트 삼아 서버의 비밀키를 완전히 탈취해 버립니다.

[정보보안기사] 차분 분석, 선형 분석, 전수 공격 [블록암호 공격법]

예르미(yermi) — Fri, 5 Jun 2026 22:28:09 +0900

정보보안기사 시험에서 블록 암호 공격법은 무수히 많은 해킹 기법 중 딱 2개의 천재적인 수학적 분석법과 1개의 무식한 방법으로 압축되어 출제됩니다. 개발자의 디버깅(테스트) 방법론에 빗대어 설명해 드리겠습니다.

1. 차분 분석 (Differential Cryptanalysis): "입력을 살짝 비틀어보자"

테스트 환경: 선택 평문 공격 (CPA - Chosen Plaintext Attack) 해커가 암호화 API(블랙박스)에 내 맘대로 평문 파라미터를 던져보고, 리턴되는 암호문을 마음껏 수집할 수 있는 환경입니다.
해킹 로직:
1. 해커가 10000000이라는 평문(A)을 던져 암호문(A')을 받습니다.
2. 이번엔 딱 1비트만 바꾼 10000001이라는 평문(B)을 던져 암호문(B')을 받습니다.
3. 두 암호문 A'와 B'의 '차이(XOR 값, Difference)'를 분석합니다.
개발자 비유: API에 id=1을 넣었을 때와 id=2를 넣었을 때, Response 바디의 어떤 해시값이 어떻게 요동치는가(나비효과)를 수만 번 추적해서 내부의 비밀키를 역추적하는 '블랙박스 퍼징(Fuzzing) 테스트'와 완벽히 같습니다.

2. 선형 분석 (Linear Cryptanalysis): "통계적 패턴을 찾자"

테스트 환경: 알려진 평문 공격 (KPA - Known Plaintext Attack) 해커가 API에 값을 마음대로 쏴볼 수는 없지만, 누군가 통신한 엄청난 양의 [평문 - 암호문] 로그 세트를 탈취하여 DB에 쌓아둔 상태입니다.
해킹 로직: 평문(Input)의 특정 비트들과 암호문(Output)의 특정 비트들을 이리저리 XOR 해보면서, 비밀키(Key)와 일치할 확률이 50%를 미세하게 넘는 '선형 방정식(Linear Equation)'을 찾아냅니다.
개발자 비유: 수백만 건의 [Input, Output] 로그 데이터를 머신러닝(선형 회귀) 모델에 때려 넣고, "입력의 1번째 비트와 출력의 5번째 비트를 더하면 높은 확률로 키의 3번째 비트가 나온다"는 통계적 근사식을 뽑아내는 '데이터 마이닝' 기법입니다.

3. 전수 공격 (Brute-Force): "O(2^n) 무한 루프"

해킹 로직: 수학적 분석 다 집어치우고, 키가 0000일 때부터 FFFF일 때까지 for문을 돌려 모든 경우의 수를 무식하게 다 대입해 보는 방법입니다.
방어 대책: 이 공격을 막는 유일한 방법은 루프를 다 도는 데 우주의 나이보다 긴 시간이 걸리도록 키 길이를 늘리는 것뿐입니다. (과거 DES가 키 길이가 56비트로 짧아서 이 전수 공격에 며칠 만에 털렸고, 그래서 오늘날 키 길이가 256비트인 AES-256으로 넘어오게 된 겁니다.)

[정보보안기사] 스테가노그래피(Steganography) & 워터마킹(Watermarking)

예르미(yermi) — Fri, 5 Jun 2026 22:25:06 +0900

1. 스테가노그래피 (Steganography): "존재 자체를 감춰라"

설계 목적: 정보의 기밀성(Confidentiality) 확보. 메시지를 주고받는다는 '통신 사실 자체'를 숨기는 것이 목적입니다.
핵심 메커니즘 (LSB 대체법): 주로 이미지 파일의 LSB(Least Significant Bit, 최하위 비트) 영역을 조작합니다. 예를 들어 24비트 RGB 컬러에서 각 색상 레이어의 마지막 1비트를 비밀 메시지의 비트로 변환하는 방식입니다. 마지막 1비트가 바뀌어도 인간의 눈(디스플레이)으로는 색상 변화를 전혀 인지할 수 없습니다.
아키텍처적 한계: 강인성(Robustness)이 극도로 낮습니다. 파일이 중간에 기하학적으로 리사이징되거나 포맷 변환(예: 고압축 JPEG로 변환)되면 LSB 영역의 데이터가 가장 먼저 날아가므로, 숨겨진 메시지가 즉시 파괴(Exception 터짐)됩니다.

2. 디지털 워터마킹 (Digital Watermarking): "저작권을 증명하라"

설계 목적: 저작권 보호 및 무결성(Integrity) 인증. 데이터의 존재 여부보다는, 공격을 당하더라도 끝까지 살아남아 소유주를 증명하는 것이 목적입니다. (가시성과 비가시성 모두 존재하지만, 보안기사에서는 주로 비가시성 워터마크의 메커니즘을 묻습니다.)
핵심 메커니즘: 이미지의 주파수 도메인(DCT, DWT 등 변환 영역)의 고주파/중주파 성분에 저작권 정보를 분산하여 은닉합니다.
분류 (시험 단골 변수):
1. 강인성 워터마킹(Robust): 의도적인 압축, 필터링, 크롭(자르기) 공격을 당해도 워터마크가 쉽게 지워지지 않도록 설계 (저작권 증명용).
2. 취약성 워터마킹(Fragile): 원본에 미세한 변조만 가해져도 워터마크가 깨지도록 설계 (위·변조 탐지 및 무결성 검증용).

CBT 필터링용 핵심 비교 그리드 (메모리 캐싱용)

시험 지문에서 다음 키워드가 매핑되면 1초 컷으로 정답을 찾아내야 합니다.

구분	스테가노그래피 (Steganography)	디지털 워터마킹 (Digital Watermarking)
최우선 목표	기밀성 (비밀 통신 사실 은닉)	저작권 보호 / 무결성 인증
공격에 대한 태도	공격에 취약함 (쉽게 파괴됨)	공격에 버텨야 함 (강인성 요구)
관심의 대상	커버 데이터 안에 숨겨진 메시지 내용	메시지를 담고 있는 콘텐츠 자체의 저작권

짚고 넘어가야 할 보너스 개념: 핑거프린팅 (Fingerprinting)

워터마킹을 공부할 때 시험 문제에 보기로 100% 엮여 나오는 개념이 핑거프린팅(Fingerprinting)입니다. 둘 다 저작권을 보호하는 기술이지만, '누구의 정보'를 심느냐의 라우팅 대상이 다릅니다.

워터마킹: 콘텐츠에 '판매자(저작권자)'의 정보를 심습니다. (모든 구매자에게 동일한 파일 배포)
핑거프린팅: 콘텐츠에 '구매자(사용자)'의 정보를 심습니다. (구매자마다 서로 다른 파일 배포)
- 비즈니스 로직: 만약 해당 콘텐츠가 토렌트 등 외부망에 불법 유포되었을 때, 유포된 파일 내부의 핑거프린트를 파싱하여 최초 불법 유포자(배포자)를 추적(Trace)할 수 있습니다.

[정보보안기사] 블록 암호(Block Cipher) [패딩으로 남는 공간 채우기]

예르미(yermi) — Fri, 5 Jun 2026 22:21:40 +0900

웹 백엔드나 DB 암호화, 파일 암호화 등 우리가 실무에서 다루는 암호화(AES, DES 등)의 99%는 이 블록 암호 아키텍처를 따릅니다. 개발자 관점에서 기사 시험에 무조건 나오는 3가지 핵심 로직만 빠르게 디버깅해 보겠습니다.

1. 패딩 (Padding): 남는 공간 채우기

블록 암호는 무조건 '정해진 상자 크기(예: 16바이트)' 단위로만 동작합니다. 그런데 사용자의 비밀번호가 10바이트라면 상자에 6바이트가 남게 되겠죠?

이때 빈 공간을 의미 없는 데이터나 규칙적인 값으로 강제로 채워 넣는 작업을 패딩(Padding)이라고 합니다. 실무에서 AES 암호화를 구현할 때 AES/CBC/PKCS5Padding처럼 뒤에 붙는 옵션이 바로 이 남는 공간을 어떻게 채울 것인지에 대한 규칙입니다.

2. 내부 구조: 파이스텔(Feistel) vs SPN

블록 상자 안에서 데이터를 어떻게 지지고 볶을 것인가에 대한 아키텍처입니다. 시험에서는 두 구조의 차이를 묻는 단답형이 자주 나옵니다.

구분	파이스텔 (Feistel) 구조	SPN (Substitution-Permutation Network) 구조
작동 방식	블록을 반으로 쪼갠 뒤(L, R), 서로 교차하며 꼬아버림	데이터를 병렬로 치환(S-box)하고 위치를 섞음(P-box)
특징	암호화와 복호화 로직이 완벽히 동일 (역순으로 키만 넣으면 됨)	암호화와 복호화 로직이 다름. 병렬 처리가 가능해 매우 빠름
대표 알고리즘	DES, SEED (과거 레거시)	AES, ARIA (현재 표준)

3. 운영 모드 (Modes of Operation) ⭐️

블록 암호에서 가장 중요한 파트입니다. 파일 용량이 커서 블록이 수천 개가 나올 때, "이 수많은 블록들을 어떤 순서와 관계로 엮어서 암호화할 것인가?"를 결정하는 패턴입니다.

① ECB (Electronic Codebook) - 절대 쓰면 안 되는 안티패턴

가장 무식한 방식입니다. 1번 블록 따로, 2번 블록 따로, 독립적으로 암호화합니다. 이 ECB 모드의 위험성을 단적으로 보여주는 전 세계 보안 업계의 아주 유명한 '리눅스 펭귄(Tux)' 짤이 있습니다.

치명적 단점: '똑같은 평문 블록'이 들어가면 '똑같은 암호문 블록'이 튀어나옵니다. 즉, 데이터의 패턴이 그대로 노출됩니다.

ECB 모드의 치명적인 취약점 시각화. 출처: Qvera

가운데 이미지가 ECB 모드로 암호화한 결과입니다. 픽셀 데이터(평문)가 같으면 암호문도 같게 나오기 때문에, 데이터는 암호화되었을지언정 원본의 윤곽(패턴)이 그대로 남아버립니다. 해커가 가장 좋아하는 먹잇감이죠.

② CBC (Cipher Block Chaining) - 실무의 기본값

ECB의 문제를 해결하기 위해 도입된 '체이닝(Chaining)' 기법입니다.

작동 원리: 현재 블록을 암호화하기 전에, '이전 블록의 암호문'과 먼저 XOR 연산을 섞어버립니다.
장점: 똑같은 평문 블록이 연속으로 들어와도, 이전 블록의 결과값이 계속 누적되어 섞이기 때문에 위 사진의 세 번째처럼 완전한 무작위 노이즈(안전한 상태)로 출력됩니다.
IV (초기화 벡터): 첫 번째 블록은 섞을 '이전 블록'이 없으므로, 암호화를 시작할 때 랜덤한 더미 데이터를 하나 던져주는데 이를 IV(Initialization Vector)라고 부릅니다. (개발하실 때 키값 말고 IV값도 같이 세팅해 보신 기억이 있으실 겁니다.)

개발자로서 실무 API 연동하실 때, 구글링해서 복붙하던 AES/CBC/PKCS5Padding이라는 문자열이 이제 "AES(SPN 구조) 알고리즘을 써서, CBC(체이닝) 모드로 블록을 엮고, 남는 공간은 PKCS5 규칙으로 채운다"라는 완벽한 아키텍처 명세서로 읽히실 겁니다.

[정보보안기사] 스트림 암호(Stream Cipher) [난수와 XOR 연산]

예르미(yermi) — Fri, 5 Jun 2026 22:16:52 +0900

스트림 암호 (Stream Cipher)란?

개발자 비유: 블록 암호가 데이터를 128비트짜리 상자(블록)에 꽉꽉 채워질 때까지 기다렸다가 트럭으로 한 번에 보내는 '택배' 방식이라면, 스트림 암호는 수도꼭지에서 흐르는 물처럼 데이터가 발생하는 족족 1비트(Bit) 또는 1바이트(Byte) 단위로 실시간 암호화하여 흘려보내는 방식입니다.

1. 핵심 메커니즘: 난수와 XOR 연산

복잡한 알고리즘이 필요 없습니다. 스트림 암호의 코어 로직은 단 하나, XOR(배타적 논리합) 연산입니다.

시스템 내부의 난수 발생기(PRNG)가 끝없이 무작위 비트열을 뿜어냅니다. 이를 키 스트림(Keystream)이라고 부릅니다.
실제 전송할 데이터(평문)의 비트와, 난수 발생기가 만든 키 스트림의 비트를 1:1로 매핑하여 XOR 연산을 때려버립니다.
그 결과물(암호문)을 바로 네트워크로 전송합니다.

2. 정보보안기사 출제 포인트 (특징)

시험에서는 주로 블록 암호와 비교하는 지문으로 출제됩니다. 아래 3가지 특징은 반드시 기억해야 합니다.

초고속 실시간 처리: 데이터를 모을 필요가 없으므로 암호화 속도가 매우 빠릅니다. 따라서 Latency에 민감한 실시간 음성/영상 스트리밍이나 무선 통신(Wi-Fi, Bluetooth) 환경에 주로 쓰입니다.
에러 전파(Error Propagation)가 없음: 네트워크 통신 중 암호문의 1비트가 손상(깨짐)되었다고 가정해 봅시다. 스트림 암호는 비트 단위로 독립적인 XOR 연산을 하므로, 수신 측에서도 딱 그 1비트만 복호화에 실패하고 나머지 데이터는 멀쩡합니다. (반면 블록 암호는 1비트만 깨져도 그 블록 128비트 전체가 쓰레기값이 되는 '눈사태 효과'가 발생합니다.)
대표 알고리즘: 과거 Wi-Fi 무선 공유기 비밀번호 방식에 쓰였던 RC4, 그리고 하드웨어 칩셋으로 구현하기 쉬운 LFSR(선형 귀환 시프트 레지스터) 등이 시험에 단골 오답/정답으로 등장합니다.

[정보보안기사] SYN Flooding & ARP Spoofing [L4, L2 공격 방법]

예르미(yermi) — Fri, 5 Jun 2026 22:13:09 +0900

네트워크 보안의 공격과 방어는 결국 "TCP/IP 프로토콜 자체가 너무나도 '신뢰 기반'으로 멍청하게 설계되었다"는 태생적 한계에서 출발합니다. 가장 빈출되는 핵심 공격 두 가지부터 부숴보겠습니다.

1. SYN Flooding (L4): TCP 3-Way Handshake의 메모리 누수 유발

백엔드에서 DB 커넥션 풀(Connection Pool)이 꽉 차서 장애가 나는 상황과 정확히 같은 원리입니다.

개발자 관점: 클라이언트와 서버가 TCP 연결을 맺을 때 SYN -> SYN/ACK -> ACK 과정을 거칩니다. 서버는 클라이언트로부터 최초의 SYN을 받으면, "아, 곧 연결되겠구나!" 하고 연결 대기 상태(SYN_RECV)로 전환하며 커넥션 정보를 메모리의 백로그 큐(Backlog Queue)에 할당해 둡니다.
해커의 공격 (익스플로잇): 해커는 출발지 IP를 무작위로 위조(Spoofing)한 뒤, 타겟 서버로 SYN 패킷만 초당 수만 개씩 날립니다. 서버는 응답으로 SYN/ACK를 보내고 마지막 ACK를 하염없이 기다리지만, 출발지 IP가 가짜니 ACK가 올 리가 없습니다. 결국 백로그 큐 메모리가 꽉 차버려서(Overflow), 정상적인 유저의 연결 요청마저 전부 Drop(거부)시켜버리는 서비스 거부(DoS) 상태에 빠집니다.
기사 시험 출제 포인트 (방어책):
- Syncookies (신쿠키): 가장 정답으로 자주 나오는 리눅스 커널 레벨의 방어 기법입니다. 서버가 SYN을 받았을 때 백로그 큐에 메모리를 할당하지 않고, 암호화된 해시값(Cookie)을 SYN/ACK의 시퀀스 번호에 담아 보냅니다. 클라이언트가 정상적인 ACK에 그 쿠키를 담아 돌려보낼 때만 메모리를 할당하는 지연 할당 아키텍처입니다.

2. ARP Spoofing (L2): 로컬 네트워크의 Man-in-the-Middle (MitM)

이건 라우터를 타지 않는 동일한 서브넷(L2 스위치 대역) 내부에서 일어나는 기만전술입니다.

개발자 관점: 네트워크 통신의 최종 목적지는 IP가 아니라 하드웨어의 MAC 주소입니다. 단말기들은 "192.168.0.1(게이트웨이) IP 가진 놈, MAC 주소가 뭐야?" 하고 브로드캐스트로 묻고(ARP Request), 응답을 받아 자신의 ARP 캐시 테이블(Map 구조)에 업데이트합니다.
해커의 공격 (익스플로잇): 해커가 로컬 망에 잠입해서, 자기가 라우터(게이트웨이)인 척 "내 MAC 주소가 192.168.0.1의 MAC 주소야!"라고 조작된 ARP Reply 패킷을 계속 뿌립니다. 망 내의 PC들은 바보처럼 해커의 MAC 주소를 게이트웨이로 캐싱해 버립니다. 이후 PC들이 외부망으로 보내는 모든 패킷은 라우터가 아니라 해커의 PC(프록시 역할)를 무조건 거쳐서 나가게 됩니다. 완벽한 패킷 스니핑(Sniffing) 환경이 구축되는 겁니다.
기사 시험 출제 포인트 (방어책):
- ARP 캐시 테이블을 동적(Dynamic) 업데이트가 아닌, 정적(Static, -s 옵션)으로 하드코딩해 버리는 조치가 가장 원시적이지만 확실한 정답 지문으로 출제됩니다.

3. 방어 아키텍처: 방화벽(Firewall) vs IDS/IPS

이제 이런 트래픽 레벨의 공격을 막아내는 방어 장비의 룰셋을 세팅해야 합니다. 기사 실기 시험에서는 직접 이 룰셋을 코딩해야 하므로 개념을 명확히 분리해야 합니다.

방화벽 (Firewall - L3/L4 통제): AWS의 Security Group이나 Network ACL과 같습니다. 패킷의 '헤더(IP, Port)'만 봅니다. "80 포트로 들어오는 IP는 허용, 22번 포트는 관리자 IP만 허용." 구조가 단순해서 속도가 빠르지만, 80번 포트를 타고 들어오는 XSS나 SQLi 같은 L7 페이로드 내부의 악성 데이터는 전혀 까보지 못합니다.
IDS (탐지) / IPS (탐지+차단) - L7 통제: 방화벽이 놓친 패킷의 '내용물(Payload)'을 뜯어보는(Deep Packet Inspection) 장비입니다.
- "TCP 80 포트로 들어오는데, 내용물에 admin' -- 이나 <script> 같은 문자열 패턴(Signature)이 있으면 차단해!"라는 정밀한 룰셋을 정의합니다. 대표적인 오픈소스 엔진이 바로 Snort(스노트)입니다.

[정보보안기사] 접근 통제 모델(Access Control Models) [DAC, MAC, RBAC]

예르미(yermi) — Fri, 5 Jun 2026 22:09:50 +0900

백엔드 API를 개발하실 때 가장 많이 고민하시는 부분이 바로 "이 유저가 이 API 엔드포인트에 접근할 권한(Authorization)이 있는가?"일 것입니다. 정보보안기사에서는 이 권한 부여 방식을 크게 3가지 아키텍처로 분류하여 묻습니다. 스프링 시큐리티(Spring Security)나 클라우드 IAM 정책을 설계해 보셨다면 이미 뼈대는 다 알고 계신 내용입니다.

1. DAC (Discretionary Access Control, 임의 접근 통제)

개발자 관점: 리눅스 서버에서 매일 치시는 chmod 755, chown 명령어 그 자체입니다. 파일(객체)을 생성한 소유자(Owner)가 "내 파일이니까 내 맘대로 권한을 줄게!" 하고 임의로(Discretionary) 권한을 통제하는 방식입니다.
핵심 메커니즘: 시스템은 사용자의 '신분(Identity)'을 확인하고, 파일에 붙어있는 ACL(Access Control List)을 뒤져서 권한이 있는지 체크합니다.
기사 시험 출제 포인트 (함정 주의):
- 키워드: '소유자(Owner)', '신분(Identity)', 'ACL(접근 제어 목록)'이라는 단어가 나오면 100% DAC입니다.
- 취약점 단골 출제: "DAC는 트로이 목마(Trojan Horse) 공격에 취약하다." (O) -> 최고 관리자(root)가 실수로 악성코드 파일에 실행 권한을 줘버리면 시스템이 그대로 뚫리기 때문입니다. 중앙 통제가 안 된다는 것이 가장 큰 단점입니다.

2. MAC (Mandatory Access Control, 강제 접근 통제)

개발자 관점: 리눅스 건드릴 때 가장 짜증 나서 보통 꺼버리고 시작하는 SELinux나, 군대/국가기관의 망분리 환경을 떠올리시면 됩니다. 파일 소유자? 그딴 건 중요하지 않습니다. 오직 시스템 관리자(Admin)가 정한 절대적인 규칙에 의해서만 강제로(Mandatory) 통제됩니다.
핵심 메커니즘: 모든 사용자와 파일에는 '보안 등급(Security Label)'이 붙습니다. (예: 사용자=1급 기밀 인가자, 파일=2급 기밀 문서). 무조건 사용자의 등급이 파일의 등급보다 높거나 같아야만 접근할 수 있습니다.
기사 시험 출제 포인트 (함정 주의):
- 키워드: '보안 레이블/등급(Security Label)', '관리자(Admin/System)', '규칙(Rule) 기반'이라는 단어가 나오면 MAC입니다.
- 특징: 구현하기가 미치도록 복잡하고 무거워서 일반적인 상용 서비스에서는 잘 안 씁니다. 군사 목적이나 극도의 보안이 필요한 폐쇄망에서 씁니다.

3. RBAC (Role-Based Access Control, 역할 기반 접근 통제)

개발자 관점: 가장 완벽하게 익숙하신 모델입니다. 스프링 시큐리티의 @Secured("ROLE_ADMIN") 어노테이션이나, AWS IAM Role, 쿠버네티스의 RBAC가 정확히 이겁니다. 사용자 개인에게 일일이 권한을 주는 게 아니라, 시스템에 '역할(Role)'을 만들어두고 (예: DB 관리자, 일반 유저, 익명 유저), 사용자를 그 역할에 맵핑(Mapping)하는 구조입니다.
핵심 메커니즘: 사용자의 신분이 아니라 '사용자가 맡은 직책/역할'에 따라 접근을 통제합니다.
기사 시험 출제 포인트 (가장 출제 빈도 높음):
- 장점 키워드: '관리 용이성', '인사이동(부서 이동)', '최소 권한의 원칙', '직무 분리(SoD, Separation of Duties)'가 나오면 묻지도 따지지도 않고 RBAC입니다. 회사에서 직원이 퇴사하면 그 직원의 Role만 회수하면 끝이니까 관리가 압도적으로 편합니다.

출제자 마인드로 리버스 엔지니어링

기사 시험에서는 이 세 가지를 섞어놓고 말장난을 칩니다. 디버깅 트리를 딱 이렇게 짜두시면 됩니다.

권한의 주체는 누구인가?
- 소유자가 맘대로 준다 -> DAC
- 관리자가 강제로 묶어버린다 -> MAC
- 시스템에 정의된 그룹(역할)이 준다 -> RBAC

이 접근 통제 모델은 'Bell-LaPadula 모델(기밀성)'이나 'Biba 모델(무결성)' 같은 극혐 수학적 보안 모델의 베이스가 되기 때문에, 지금 아키텍처 관점에서 딱 분리해 두시면 나중에 공부하실 때 렌더링이 아주 빠르게 됩니다.

[정보보안기사] 버퍼 오버플로우(Buffer Overflow) [함수 호출의 콜스택 하이재킹]

예르미(yermi) — Fri, 5 Jun 2026 22:06:20 +0900

1. 스택 버퍼 오버플로우: 함수 호출의 콜스택(Call Stack) 하이재킹

개발자 관점의 정상 로직: 함수가 호출되면 메모리의 스택(Stack) 영역에 '스택 프레임'이 쌓입니다. 여기에는 지역 변수(Buffer)가 들어가고, 가장 중요한 RET(Return Address, 함수가 끝나고 돌아갈 원래 코드의 메모리 주소)가 저장됩니다.
해커의 관점 (익스플로잇): 공격자는 strcpy()처럼 입력값 길이를 검사하지 않는 취약한 함수를 타겟으로 잡습니다. 10바이트짜리 지역 변수 공간에 100바이트짜리 쓰레기값과 악성 코드(Shellcode)를 때려 넣습니다.
결과: 넘쳐흐른 데이터가 스택의 다른 영역을 다 덮어쓰다가, 결국 RET 주소까지 해커가 조작한 메모리 주소로 덮어버립니다. 함수가 정상적으로 종료되는 순간, CPU는 원래 돌아가야 할 곳이 아니라 해커가 지정한 악성 코드가 있는 주소로 점프(JMP)하여 스크립트를 실행해 버립니다. 관리자 권한(Root) 쉘이 뚫리는 순간입니다.

2. 기사 시험 출제 포인트: OS 레벨의 방어 기법 (Mitigation)

보안 기사 CBT에서는 공격 원리보다 "이걸 막기 위해 OS에 적용된 메모리 보호 기법이 무엇인가?"를 묻는 문제가 무조건 나옵니다. 이 4가지는 서버 인프라 엔지니어링의 핵심이기도 합니다.

1. ASLR (Address Space Layout Randomization)
- 개념: 해커가 RET를 덮어쓰려면 자기가 주입한 악성 코드가 메모리 '어디에' 있는지 정확한 주소를 알아야 합니다. ASLR은 프로그램이 실행될 때마다 스택, 힙, 라이브러리의 메모리 주소를 랜덤하게 섞어버리는 기술입니다.
- 출제 함정: "ASLR을 적용하면 오버플로우 취약점 자체를 근본적으로 제거할 수 있다" -> (X) 오버플로우 자체를 막는 게 아니라, 메모리 주소를 예측하기 힘들게 만들어 공격 성공 확률을 극도로 낮추는 우회 방지 기법입니다.
2. DEP (Data Execution Prevention) / NX Bit (No-eXecute)
- 개념: 스택이나 힙은 '데이터'를 저장하는 공간이지 '코드'가 실행되는 공간이 아닙니다. OS와 CPU가 합작하여 데이터 영역에서는 명령어(Instruction)가 아예 실행되지 못하도록 실행 권한을 박탈해 버리는 기술입니다.
3. Stack Canary (스택 카나리아)
- 개념: 광부들이 탄광에 독가스가 있는지 확인하기 위해 카나리아 새를 데려간 것에서 유래했습니다. 버퍼와 RET 주소 사이에 랜덤한 '더미 값(Canary)'을 몰래 끼워 넣습니다. 함수 종료 직전에 이 카나리아 값이 변조되었는지 확인합니다. 값이 바뀌었다면 누군가 오버플로우를 낸 것이므로 프로세스를 강제로 킬(Kill)해 버립니다.
4. 시큐어 코딩 (안전한 함수 사용)
- 정답 지문 단골: strcpy, strcat, gets 같은 길이 검증이 없는 위험한 함수 대신, strncpy, strncat, fgets처럼 복사할 데이터의 최대 길이(n)를 파라미터로 명시하는 안전한 함수를 사용해야 한다는 내용이 출제됩니다.

방금 본 내용들은 평소 트러블슈팅 하시던 "서버가 왜 죽었지? 아 메모리 릭(Leak)이나 Segmentation Fault 났네" 하는 상황을 공격자가 의도적으로 발생시켜서 시스템을 장악하는 과정입니다.

[일상] 휴가 가서 서버실을 뽑았습니다 ️ [광기의 고퀄리티 인프라 미니어처, tarlin 네트워크 랙 조립기]

예르미(yermi) — Fri, 5 Jun 2026 21:36:16 +0900

최근 다녀온 오키나와 여행에서 정말 예상치 못한 곳에서 발걸음을 멈추고 말았습니다. 평범한 가챠 기계들 사이에서 뿜어져 나오는 범상치 않은 IT 인프라의 기운... 바로 '서버실 네트워크 장비 가챠'를 발견했기 때문이죠!

손바닥 네트워크 기기(手のひらネットワーク機器) 1.3

제가 뽑은 시리즈는 타린(Tarlin)에서 출시한 '손바닥 네트워크 기기(手のひらネットワーク機器) 1.3' 버전입니다. 캡슐을 열어보니 1/12 스케일로 정교하게 축소된 랙 마운트 장비들이 들어있었습니다. 이 가챠는 놀랍게도 로고만 대충 따라 한 것이 아니라 Cisco, A10 Networks, Furukawa Electric, Dell Technologies, Fortinet 등 실제 글로벌 제조사들의 공식 감수와 협력을 받아 제작되었습니다. 제가 뽑은 두 가지 모델은 다음과 같습니다.

A10 Networks Thunder 7655S: 트래픽 분산과 보안을 담당하는 든든한 L7 ADC 장비
CISCO Meraki MX85: 클라우드 관리형 보안 및 SD-WAN 어플라이언스

A10 Networks Thunder 7655S & CISCO Meraki MX85. 장비에 연결할 수 있는 초록색 LAN 케이블까지!

또한 이 가챠는 단품으로 끝나는 것이 아니라, 다른 시리즈와 결합하여 완벽한 미니어처 데이터센터(IDC) 생태계를 구성할 수 있답니다. 나중에 기회가 된다면 다른 시리즈도 뽑아볼 예정..

혹시 일본 여행 중에 이 가챠 기계를 발견하신다면, Full-Rack 구성을 위해 동전을 넉넉히 준비하시는 것을 추천해 드립니다. 저도 다음번엔 반드시 Zabbix 모니터와 쿨링 팬 세트까지 풀세트로 뽑아와야겠습니다!

나의 꿈은 서버 랙 풀세트 확장!

[도서리뷰] 그림으로 배우는 생성형 AI - API 호출을 넘어 'AI 아키텍처'를 설계하다

예르미(yermi) — Mon, 25 May 2026 16:26:51 +0900

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

OpenAI API 연동 완료! ...그런데 다음은요?

요즘 백엔드 개발자들의 일상을 보면, 시스템에 생성형 AI를 연동하는 작업이 빠지지 않습니다. Spring Boot나 Django 환경에서 LLM API를 호출해 텍스트를 생성하는 것 자체는 이제 주니어 개발자도 몇 시간이면 해내는 시대가 되었습니다.

하지만 진짜 문제는 그다음부터입니다. 단순한 질의응답을 넘어, AI가 외부 도구를 사용하고, 기억을 유지하며, 복잡한 태스크를 자율적으로 수행하는 '에이전트 시스템'을 구축하려고 하면 눈앞이 캄캄해집니다. RAG 파이프라인의 아키텍처를 어떻게 잡을지, 환각 현상은 어떻게 통제할지 등은 단순한 API 문서만으로는 해결되지 않는 엔지니어링의 영역이기 때문입니다.

이러한 설계의 벽에 부딪혔을 때, 한빛미디어의 신간 <그림으로 배우는 생성형 AI>를 펼쳤습니다. 구글과 마이크로소프트를 거친 전문가들이 집필하고, 개발자들의 영원한 '믿고 보는 번역가' 류광 님이 번역한 이 책은, 생성형 AI의 복잡한 블랙박스를 투명한 유리 상자로 만들어주는 강력한 시각적 아키텍처 가이드입니다.

코드를 치기 전, 시스템의 '큰 그림'을 그리기 위한 필수 지침서

논문 대신 '도식'으로 이해하는 메커니즘

새로운 AI 모델이 나올 때마다 ArXiv에 올라오는 논문을 전부 읽을 수는 없습니다. 특히 클라우드 및 시각적 스토리텔링의 대가인 프리양카 베르가디아가 참여한 이 책은, 텍스트로 읽으면 한없이 추상적인 트랜스포머의 어텐션 메커니즘이나 임베딩 벡터 공간의 개념을 극도로 직관적인 다이어그램으로 풀어냅니다.

나의 인사이트: 평소 RAG 파이프라인을 구축할 때 벡터 DB와 청킹 전략을 단순히 '라이브러리 사용법'으로만 접근하곤 했습니다. 하지만 책의 도식화된 파이프라인 흐름도를 보며, 인덱싱 단계에서 데이터가 어떻게 벡터로 변환되고 쿼리 시점에 어떤 수리적 매칭이 일어나는지 시스템 아키텍처 관점에서 명확하게 정리할 수 있었습니다. 구조가 눈에 보이니, 병목 현상이 발생할 포인트도 자연스럽게 예측이 가능해졌습니다.

복잡한 수학 공식 대신 재밌는 만화로

프롬프트를 넘어 '에이전트'와 '책임 있는 AI'로

현재 개발 씬의 가장 큰 화두는 단연 'AI 에이전트'입니다. 책에서는 LLM을 단순한 텍스트 생성기가 아니라, 시스템의 '추론 엔진'으로 사용하는 방법을 구조화하여 설명합니다. 계획, 도구 사용, 메모리 관리로 이어지는 에이전트의 작동 원리를 보면서, 향후 마이크로서비스(MSA) 아키텍처 내에서 AI 에이전트를 어떻게 독립적인 노드로 배치할 것인가에 대한 깊은 영감을 받았습니다.

또한, 현업 개발자라면 피할 수 없는 '책임 있는 AI' 파트도 인상 깊습니다. 보안, 프라이버시, 편향성 문제를 아키텍처 레벨에서 어떻게 필터링하고 가드레일을 세울 것인지 고민하게 만드는, 매우 실무적인 통찰을 제공합니다.

생성형 AI는 단순한 기능이 아니라, 시스템의 새로운 추론 계층이다.

- 총평 및 추천 대상

<그림으로 배우는 생성형 AI>는 파이썬 코드가 빼곡한 튜토리얼 북이 아닙니다. 이 책은 코드를 짜기 전에 우리가 무엇을, 어떤 구조로 만들어야 하는지를 명확히 짚어주는 훌륭한 설계도입니다.

✅ 이런 분들에게 강력 추천합니다:

LLM API 연동은 해봤지만, 본격적인 AI 에이전트 기반 서비스를 설계하려는 중/시니어 엔지니어
복잡한 논문이나 텍스트 대신, 시스템의 전체 흐름(Data Flow)을 직관적으로 파악하고 싶은 개발자
기술 조직 리더나 아키텍트로서 생성형 AI 애플리케이션의 아키텍처 표준을 잡아야 하는 분

생성형 AI를 단순히 '신기한 장난감'으로 소비하는 것을 넘어, 내 시스템을 혁신할 '견고한 엔진'으로 탑재하고 싶다면 이 책을 첫 번째 지침서로 삼으시길 바랍니다.

수식과 코드의 숲에서 길을 잃은 개발자에게 건네는,
가장 직관적이고 세련된 AI 아키텍처 지도.

[일상] AWS Summit Seoul 2026: 클라우드 생태계와 AI 에이전트의 진화 현장을 가다

예르미(yermi) — Thu, 21 May 2026 19:26:57 +0900

이번에는 국내 최대 규모의 클라우드 행사인 AWS Summit Seoul 2026에 다녀왔습니다.

이번 행사를 참관하며 가장 뼈저리게 느낀 점이 있다면, 내년에는 무조건 '오픈런'을 해야겠다는 것입니다. 트랙 세션은 입장조차 힘들 정도로 수많은 인파가 몰렸고, 런치박스 역시 넉넉할 줄 알고 여유를 부리다 뒤늦게 가보니 이미 전체 소진되어 꽤나 험난한 하루를 보냈습니다.

비록 계획했던 세션들을 온전히 듣지는 못했지만, EXPO 부스를 둘러보는 것만으로도 글로벌 IT 기업들의 최신 아키텍처 트렌드와 치열한 기술적 열기를 체감하기에는 충분했습니다. 이번 서밋에서 개발자의 시선으로 포착한 핵심 인사이트를 정리해 봅니다.

AWS Summit Seoul 2026

1. 소음 속의 몰입을 만든 Lightning Theater와 무선 관람 시스템

이번 서밋에서 가장 아쉬우면서도 신선했던 부분은 세션 운영 방식이었습니다. 인기 있는 트랙들은 빈자리가 없어 입장하기 어려웠고, 오픈형 무대로 진행된 Lightning Theater 역시 발 디딜 틈이 없었습니다.

인상 깊었던 기술 운영: 흥미로웠던 건 소음이 가득한 엑스포 홀 한가운데에서 세션이 진행됨에도 불구하고, 참관객들에게 무선 이어폰을 제공해 주파수를 맞춰 발표를 듣게 한 시스템이었습니다. 주변 인파의 웅성거림 속에서도 이어폰을 귀에 꽂는 순간 오롯이 발표자의 목소리와 아키텍처 슬라이드에 집중할 수 있는 몰입감 넘치는 경험이었습니다. 공간적 제약을 영리하게 극복한 오프라인 서밋만의 매력적인 세션 연출이었습니다.

AWS Summit Seoul 2026: Lightning Theater

2. 엔터프라이즈 모니터링의 최전선, Datadog 부스 탐방

엑스포 존에서 가장 가보고 싶었던 곳 중 하나는 단연 인프라 관측성(Observability) 생태계를 리드하는 Datadog(데이터독) 부스였습니다. 글로벌 벤더답게 부스 규모도 크고 개발자들로 가득했습니다.

기술적 시사점: 클라우드 네이티브 환경이 고도화될수록 수많은 마이크로서비스(MSA)에서 쏟아지는 로그, 메트릭, 트레이스를 효율적으로 중앙화하고 시각화하는 인프라 모니터링 파이프라인의 설계가 필수적입니다. 데이터독은 대규모 분산 시스템의 복잡한 연결 고리를 직관적인 대시보드로 통합해 문제의 근본 원인을 빠르게 추적할 수 있는 엔터프라이즈급 아키텍처를 잘 보여주고 있었습니다. 모니터링 플랫폼으로서의 탄탄한 입지를 다시금 확인할 수 있었고, 부스에서 브랜드 아이덴티티가 담긴 귀여운 강아지 스티커 굿즈도 챙길 수 있어 만족스러웠습니다.

엔터프라이즈 모니터링의 최전선, Datadog

3. CI/CD 파이프라인을 통제하는 AI 에이전트: GitLab Duo & Kiro

이번 행사에서도 'Agentic AI' 트렌드는 명확했습니다. 다만 앞선 전시회들이 일반 업무용 서비스에 집중했다면, AWS Summit은 철저히 개발자를 위한 에이전트를 조명했습니다.

GitLab Duo Agent Platform: 단순히 IDE에서 코드를 자동 완성해 주는 수준을 넘어섰습니다. CI/CD 파이프라인 분석, 보안 취약점 점검, Merge Request 리뷰 등 소프트웨어 생애주기 전반을 오케스트레이션하는 에이전트의 등장은, 앞으로 DevOps 환경이 얼마나 더 자동화될 수 있는지 보여줍니다.
AWS Kiro (Autonomous Agent): "프로토타입부터 프로덕션까지"라는 슬로건을 내건 Kiro 부스도 인상적이었습니다. CLI 환경에서 에이전틱 코딩으로 AWS 리소스에 접근하고, 파이프라인을 자율 실행한다는 개념은 향후 인프라 구성과 배포의 패러다임을 바꿀 만한 흥미로운 기술이었습니다.

CI/CD AI 에이전트: GitLab Duo & Kiro

4. 기술 박람회의 백미, 치열한 엑스포 굿즈 이벤트

사람이 너무 많아 세션을 제대로 듣지 못한 아쉬움은 엑스포 부스들의 다채로운 이벤트로 달랬습니다. 확실히 글로벌 네임밸류를 가진 기업들이 대거 참여하다 보니 굿즈와 이벤트 스케일도 남달랐습니다.

Nutanix Pit Stop Challenge: 하이브리드 클라우드 마이그레이션을 홍보하며 '정확히 3초'를 잡는 타이머 게임을 진행했는데, 단순하면서도 개발자들의 승부욕을 강하게 자극했습니다.
Cloudflare 부스: 부스에 전시된 PS5와 레고 세트가 수많은 참관객들의 발길을 멈추게 했습니다. 이런 화려한 스케일의 이벤트들이 곳곳에서 열려 엑스포의 분위기를 한층 띄워주었습니다.

AWS Summit Seoul 2026: 치열한 엑스포 굿즈 이벤트

총평: 클라우드 생태계의 중심에서 느낀 아키텍처의 변화

비록 세션 참석과 런치박스 획득에는 실패했지만, 코엑스를 가득 메운 수많은 개발자와 엔지니어들의 열기만으로도 IT 트렌드의 중심에 서 있다는 것을 체감할 수 있었습니다.

내년 Summit은 마음을 단단히 먹고 아침 일찍 오픈런을 해서, 더 깊이 있는 트랙 세션들을 파헤쳐 봐야겠습니다!

[서포터즈] 정보처리산업기사 서포터즈 6개월 활동 후기

예르미(yermi) — Thu, 7 May 2026 22:22:54 +0900

길다면 길고 짧다면 짧았던 6개월간의 서포터즈 활동이 드디어 마무리됩니다. 첫 게시글에서 과정평가형을 선택한 이유를 말씀드린 때가 엊그제 같은데, 벌써 마지막 총정리 글을 쓰게 되었습니다.

이번 최종 게시글에서는 서포터즈 활동을 하면서 제가 느꼈던 개인적인 성장 경험과 제도에 대한 소감, 그리고 과정평가형을 준비하는 여러분께 드리고 싶은 응원의 메시지를 전하겠습니다.

1. ✍ 서포터즈 활동을 통한 개인적인 성장

이 6개월간의 블로그 포스팅 작업은 저에게 자격증 취득 경험을 더욱 의미 있게 만들어 주었습니다.

1. 지식의 재정립 및 심화 학습

가장 큰 수확은 '가르치는 것'이 '배우는 것'이라는 진리를 다시 한번 깨달은 것입니다.

NCS 구조화: 제가 배운 데이터베이스 모델링, 프로그래밍 알고리즘, 테스트 케이스 설계 등 모든 NCS 능력 단위를 독자분들이 이해하기 쉽도록 구조화하고 설명하는 과정이 필요했습니다. 이 과정에서 파편화되어 있던 지식들이 논리적으로 연결되었고, 깊이가 더해졌습니다.
용어의 명확성: NCS에서 사용되는 전문 용어들을 다시 한번 찾아보고 정확하게 정리하면서, 실무에서도 자신감 있게 표준 용어를 사용할 수 있는 기반을 다졌습니다.

2. 소통과 공감 능력 향상

주변 지인들의 질문에 답하며 저의 경험이 다른 이들에게 실질적인 도움이 될 수 있다는 것에 큰 보람을 느꼈습니다.

경험의 공유 가치: 막연했던 과정평가형 제도에 대한 궁금증을 해소하고, "덕분에 학습 방향을 잡았다"는 피드백을 들을 때마다 큰 동기 부여가 되었습니다.

2. 한국산업인력공단 및 과정평가형 제도에 대한 소감

서포터즈 활동을 통해 과정평가형 제도를 더욱 깊이 이해하게 되었습니다. 이 제도는 미래 산업 현장에 꼭 필요한 시스템이라고 확신합니다.

실무 중심 인재 양성의 핵심: 과정평가형은 이론 암기 위주의 평가 방식을 벗어나, 실질적인 직무 역량을 기르는 데 최적화된 시스템입니다. 앞으로 IT 산업이 더욱 고도화될수록, 이처럼 실무 능력을 갖춘 인재의 가치는 더욱 높아질 것입니다.
평가와 학습의 연계: 내부 평가와 외부 평가의 유기적인 연계를 통해, 학습자가 과정을 놓치지 않고 꾸준히 역량을 쌓아갈 수 있도록 돕는다는 점이 매우 인상적이었습니다.

과정평가형 예비 학습자에게 전하는 메시지

정보처리산업기사 과정평가형은 여러분의 미래 커리어를 탄탄하게 다져줄 훌륭한 기회입니다. '성실함'을 가장 중요한 무기로 삼으세요. 긴 교육 기간 동안 지치지 않고 매일매일 실습하고, 결과물을 완성해 나가는 성실함이야말로 과정평가형 합격의 가장 큰 비결입니다.

여러분이 흘린 땀과 노력은 단순한 자격증 점수가 아니라, 취업 시장과 실무 현장에서 빛을 발할 진정한 실력이 될 것입니다. 저의 경험이 여러분의 여정에 작은 이정표가 되었기를 바랍니다.

저도 이제 정보처리산업기사 자격증을 기반으로 실무 현장에서 더욱 발전하는 모습을 보여드리겠습니다. 여러분의 꿈을 진심으로 응원합니다. 감사합니다!

본 게시글은 한국산업인력공단 과정평가형 정보처리산업기사 서포터즈 활동비를 지원받아 작성되었습니다.

[LGTM] Grafana: 관측성의 완성, 단일 창구와 대시보드 베스트 프랙티스

예르미(yermi) — Tue, 5 May 2026 13:06:53 +0900

- Grafana: 관측성의 완성, 단일 창구와 대시보드 베스트 프랙티스

Mimir(메트릭), Loki(로그), Tempo(트레이스)를 거쳐 수집된 고품질의 텔레메트리 데이터도, 결국 엔지니어가 직관적으로 해석하고 즉각적인 트러블슈팅 행동으로 옮길 수 없다면 절반의 성공에 불과합니다. LGTM 스택의 대미를 장식하는 Grafana(그라파나)는 이 방대한 백엔드 데이터들을 하나의 문맥으로 엮어내는 '단일 창구(Single Pane of Glass)'이자 관측성의 통합 프론트엔드 플랫폼입니다.

이번 포스팅에서는 단순히 차트를 그리는 도구를 넘어, 엔터프라이즈 환경에서 Grafana를 어떻게 설계하고 운영해야 개발자 경험을 극대화할 수 있는지 베스트 프랙티스를 살펴보겠습니다.

1. 단순한 UI를 넘어선 통합 쿼리 엔진 (Mixed Data Sources)

Grafana의 진정한 강력함은 이기종 데이터 소스를 한 화면에서 믹스 앤 매치(Mix and Match)할 수 있다는 점입니다. LGTM 데이터뿐만 아니라 인프라 환경의 RDBMS(PostgreSQL, MySQL), 인메모리 캐시(Redis), 메시지 큐(Kafka)까지 플러그인을 통해 직접 연결할 수 있습니다. 예를 들어, 하나의 대시보드 패널에 Mimir의 API TPS 메트릭 그래프와 Redis의 캐시 적중률, 그리고 DB의 Active Session 수를 겹쳐서 표현함으로써, 장애의 병목 지점과 파급 효과를 단 한 번의 시야각으로 입체적 분석이 가능하게 만듭니다.

단순한 UI를 넘어선 통합 쿼리 엔진

2. 프로비저닝과 Dashboard as Code (DaC)

시니어 엔지니어의 관점에서, 대시보드를 UI 화면에서 수동으로 클릭하며 만들고 수정하는 것은 지양해야 할 '안티 패턴'입니다. 관측성 인프라 역시 애플리케이션 코드와 동일하게 CI/CD 파이프라인에 태워야 합니다.

프로비저닝(Provisioning): Grafana는 YAML 파일을 통해 데이터 소스의 연결 정보와 대시보드 디렉토리를 선언적으로 구성할 수 있습니다. 서버가 재시작되어도 설정이 날아가지 않으며, 컨테이너 환경에 최적화되어 있습니다.
DaC (Dashboard as Code): Jsonnet(Grafonnet 라이브러리)이나 Terraform 등을 활용하여 대시보드 패널 구성을 코드로 관리합니다. 이를 통해 버전 관리, 코드 리뷰(PR), 문제 발생 시 즉각적인 롤백이 가능한 GitOps 기반의 관측성 환경을 구축하여 휴먼 에러를 방지하고 전사적인 대시보드 일관성을 유지할 수 있습니다.

GitOps 기반의 관측성 환경

3. 대시보드 설계 베스트 프랙티스: RED와 USE 방법론

대시보드를 열었을 때 수십 개의 그래프가 난립해 있으면 인지 부하만 가중됩니다. 마이크로서비스 환경에서는 다음 두 가지 표준 방법론을 교차 적용하여 화면을 계층화하는 것이 효과적입니다.

① RED Method (서비스 및 API 관점)

사용자나 다른 서비스와 직접 맞닿아 있는 애플리케이션의 상태를 측정할 때 최상단에 배치합니다.

Rate (초당 요청 수 - TPS / RPS)
Errors (실패한 요청의 비율 - HTTP 5xx 등)
Duration (요청을 처리하는 데 걸린 시간 - 평균값보다 Latency P99, P95 등 백분위수 활용)

② USE Method (인프라 리소스 관점)

노드, 파드(Pod), 디스크, 네트워크 등 물리적/논리적 하위 리소스의 상태를 측정할 때 사용합니다.

Utilization (리소스 사용률 - CPU, Memory Usage)
Saturation (포화도 - Queue에 쌓인 대기 작업 수나 Throttling 수치)
Errors (리소스 에러 - 네트워크 드롭, 디스크 I/O 에러 등)

4. 통합 알람과 라우팅

장애를 대시보드를 보고서야 아는 것은 이미 늦은 것입니다. Grafana의 Unified Alerting은 파편화되어 있던 알람 룰 엔진을 하나로 통합하여 매우 강력한 파이프라인을 제공합니다.

통합 알람과 라우팅

단일 룰 엔진에서 PromQL이나 LogQL 결과를 평가하고, 알람에 라벨(예: severity=critical, team=backend)을 부여합니다. 이후 Notification Policy를 통해 심각도나 담당 팀 단위로 Slack, PagerDuty, Webhook 등으로 정교하게 라우팅하여 불필요한 알람 피로도(Alert Fatigue)를 최소화합니다.

마무리하며: AIOps로의 도약

LGTM 스택을 통해 메트릭, 로그, 트레이스를 유기적으로 통합하는 것은 단순히 "현재 시스템을 잘 모니터링하자"는 1차원적인 목표 그 이상을 의미합니다.

파편화 없이 정규화되고, TraceID와 Exemplar로 완벽하게 연관성이 맺어진 고품질의 관측성 데이터는 머신러닝 모델을 훈련하기 위한 최고의 데이터 셋입니다. 이는 향후 AI가 메트릭의 계절성을 파악해 이상 징후를 선제적으로 탐지(Anomaly Detection)하고, 장애 발생 시 수많은 로그와 트레이스를 분석해 근본 원인을 스스로 추론하는 AIOps 플랫폼으로 나아가기 위한 가장 견고한 기술적 초석이 됩니다.

[study] W3C Trace Context란? [끊김 없는 분산 트레이싱의 핵심]

예르미(yermi) — Mon, 4 May 2026 22:55:41 +0900

- W3C Trace Context란?

현대의 마이크로서비스 아키텍처(MSA) 환경에서 하나의 사용자 요청은 수많은 서비스를 넘나듭니다. 이때 가장 큰 골칫거리 중 하나는 "이 요청이 대체 어디서 병목이 걸렸는가?"를 찾아내는 것입니다. 이러한 분산 추적 컨텍스트를 서비스 간에 끊김 없이 전파하기 위해 등장한 HTTP 및 메시징 헤더의 국제 표준, W3C Trace Context에 대해 깊이 알아보겠습니다.

쉽게 말해, 이 규약은 "A 서비스에서 B 서비스로 넘어가는 네트워크 요청이 전체 트랜잭션 중 어디에 속하는지 알려주는 범용 명함"과 같습니다. 현재 옵저버빌리티 생태계의 사실상 표준인 OpenTelemetry에서도 기본 프로토콜로 채택하고 있습니다.

1. 왜 필요해졌을까? : "헤더 파편화"의 종식

이 W3C 표준이 제정되기 전의 분산 추적 환경은 그야말로 혼돈이었습니다. 각 APM 벤더마다 트레이스 ID를 넘기는 헤더 포맷이 중구난방이었습니다.

Zipkin: X-B3-TraceId
Datadog: x-datadog-trace-id
New Relic: newrelic

이러한 파편화로 인해, A 서비스(Zipkin 사용)가 B 서비스(Datadog 사용)를 호출하면 Trace ID가 서로 호환되지 않아 추적의 맥락이 뚝뚝 끊어지는 Broken Trace 현상이 빈번하게 발생했습니다. 특히 외부 파트너사 API나 이기종 시스템과 연동할 때 이 문제는 더욱 치명적이었습니다. W3C Trace Context는 이러한 혼란을 범용적으로 통합하고 규격을 통일하기 위해 탄생했습니다.

2. 핵심 구성 요소: 단 두 개의 표준 헤더

W3C Trace Context는 시스템 간 통신 시 매우 심플하게 딱 두 개의 표준 헤더만을 사용합니다.

① traceparent (핵심 식별자)

트레이스의 흐름을 잇는 가장 중요한 필수 헤더입니다. 대시(-)로 구분된 4개의 고정된 필드로 명확하게 구성되어 있습니다.

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

Version (00): 현재 적용된 W3C 스펙의 버전입니다. (현재는 00 단일 버전)
Trace ID (4bf92f35...): 전체 분산 트랜잭션을 관통하는 16바이트 고유 식별자입니다. Grafana Tempo나 Jaeger 같은 백엔드에서 검색의 절대적인 기준이 되는 핵심 ID입니다.
Parent ID / Span ID (00f067aa...): 현재 요청을 직전에 호출한 서비스(Parent Span)의 8바이트 ID입니다. 이 값을 기반으로 호출의 부모-자식 관계를 트리 형태로 엮어 Waterfall 차트를 렌더링할 수 있습니다.
Trace Flags (01): 1바이트 비트 플래그입니다. 현재는 맨 끝 1비트만 사용하며, 01은 이 트레이스 데이터를 백엔드에 샘플링(기록)하라는 지시(Sampled), 00은 샘플링을 생략하라는 지시를 의미합니다.

② tracestate (벤더 특화 데이터)

표준화된 traceparent만으로는 담을 수 없는, 각 APM 벤더들만의 고유한 메타데이터를 잃어버리지 않고 다음 홉(Hop)으로 릴레이하기 위한 선택적 헤더입니다. Key-Value 쌍으로 구성되며 쉼표(,)로 구분합니다.

tracestate: datadog=00f067aa0ba902b7,rojo=t61rcWkgMzE

3. 실무 아키텍처에서의 적용: Context Propagation (컨텍스트 전파)

실제 프로덕션 레벨에서 API Gateway -> Service A -> Kafka -> Service B 와 같은 복잡한 비즈니스 로직의 흐름을 하나의 완벽한 트레이스로 묶어내려면, 이 traceparent 값이 마이크로서비스의 네트워크 경계를 넘을 때마다 반드시 유실 없이 전파되어야 합니다.

동기식 통신 (HTTP/gRPC)
- OpenTelemetry SDK나 널리 쓰이는 웹 프레임워크(Spring Boot의 Micrometer Tracing, Express 등)에 내장된 인터셉터/미들웨어가 HTTP Header 또는 gRPC Metadata에 traceparent를 자동으로 주입하고 추출합니다.
비동기식 통신 (Kafka, RabbitMQ 등)
- 비동기 메시징 구간에서도 트레이스는 이어져야 합니다. 핵심은 비즈니스 로직이 담긴 메시지 페이로드를 오염시키지 않고, Kafka Record Header와 같은 프로토콜 레벨의 메타데이터 영역에 traceparent를 실어 보내는 것입니다. 이를 통해 컨슈머(Service B)가 메시지를 폴링할 때, 앞단의 Trace ID를 그대로 이어받아 동일한 트랜잭션 컨텍스트 내에서 Span을 기록할 수 있습니다.

결론

W3C Trace Context는 단순한 헤더 규칙 그 이상입니다. 이기종 시스템과 다양한 통신 프로토콜, 그리고 수많은 APM 벤더들이 혼재된 현대의 클라우드 네이티브 생태계에서 메트릭, 트레이스, 로그를 하나의 유기적인 스토리로 꿰어내는 가장 밑바탕이 되는 식별자 릴레이 메커니즘입니다. 견고한 옵저버빌리티 플랫폼을 구축하고자 한다면, 이 표준에 대한 이해는 선택이 아닌 필수입니다.

Trace Context

This section is non-normative. This section provides a step-by-step example of a tracing vendor receiving a request with trace context headers, processing the request and then potentially forwarding it. This description can be used as a reference when impl

www.w3.org

[서포터즈] 정보처리산업기사 과정평가형, 이것만은 꼭 기억하자!

예르미(yermi) — Sun, 3 May 2026 18:15:40 +0900

벌써 6개월 차, 과정평가형 NCS 리뷰의 마지막 단계에 이르렀습니다. 그동안 DB, 프로그래밍, 테스트, 인프라, 보안 등 핵심 NCS 능력 단위를 기반으로 한 학습 경험과 평가 팁, 그리고 취업 활용 방안까지 모두 공유해 드렸습니다.

이번 게시글은 정보처리산업기사 과정평가형을 준비하거나 고민하는 분들을 위해, 제가 꼽는 가장 중요한 핵심 3가지와 학습 시 유의사항을 총정리해 드리는 시간을 갖겠습니다.

과정평가형 선택의 핵심 장점 3가지 재강조

과정평가형은 단순히 '정보처리산업기사' 자격증 하나를 취득하는 것을 넘어, 미래의 IT 인재에게 필수적인 세 가지 선물을 제공합니다.

1. 즉시 적용 가능한 '실무 능력'

가장 큰 장점은 이론과 실습의 괴리가 없다는 점입니다. NCS 능력 단위는 현업에서 실제로 요구하는 직무를 반영하고 있습니다.

배움의 연결: DB의 정규화 이론을 배우면 바로 DBMS에 테이블을 설계하고, 테스트 기법을 배우면 바로 테스트 케이스를 작성하여 코드를 검증했습니다.
자신감 확보: 이처럼 실행 가능성(Actionable) 있는 지식 습득 덕분에, 취업 후에도 새로운 기술에 대한 학습 부담이 적고 실무에 빠르게 적응할 수 있었습니다.

2. 취업 경쟁력을 높이는 '포트폴리오'

과정평가형의 모든 학습 결과물은 여러분의 경험과 능력을 객관적으로 증명하는 문서가 됩니다.

결과 중심: 프로젝트 기획부터 구현, 테스트, 그리고 최종 보고서까지의 과정이 모두 기록됩니다.
면접의 무기: 면접관에게 "이 프로젝트를 통해 어떤 NCS 능력을 달성했는지"를 명확하게 설명할 수 있으며, 이는 검정형 자격증만으로는 얻기 힘든 강력한 무기입니다.

3. 장기간 학습을 통한 '심층 이해와 습관'

단기간의 암기로는 불가능한 깊은 이해와 지속 가능한 학습 습관을 형성시켜 줍니다.

지식의 체화: 6개월 내외의 기간 동안 반복적인 실습과 평가를 거치면서, 프로그래밍의 논리적 사고, 데이터베이스의 구조적 이해 등이 지식으로만 남지 않고 기술과 습관으로 체화됩니다.
성실성 증명: 내부 평가 점수가 높다는 것은 곧 교육 과정에 성실하게 참여하고 꾸준히 노력했다는 증거이므로, 구직 시 긍정적인 평가를 받을 수 있습니다.

과정평가형 학습 시 이것만은 꼭!

이 과정이 모두에게 쉬운 것만은 아닙니다. 성공적인 자격 취득을 위해 제가 강조하고 싶은 두 가지 유의사항입니다.

1. 출결 및 내부 평가 관리는 '생명'이다

과정평가형은 교육 이수 시간과 내부 평가 점수가 합격의 필수 조건입니다.

철저한 출결 관리: 정해진 이수 시간을 채우지 못하면 외부 평가 기회 자체가 박탈됩니다. 지각/결석에 각별히 유의해야 합니다.
과제와 보고서의 완성도: 내부 평가는 단순 시험 점수뿐 아니라 보고서, 실습 결과물의 완성도로 결정됩니다. 매 능력 단위의 과제를 허투루 하지 않고 충실히 수행해야 최종 합격에 유리합니다.

2. NCS 능력 단위와 평가 기준을 이해하고 학습하라

학습하는 내용이 곧 평가의 기준입니다.

목표 확인: 각 NCS 능력 단위가 요구하는 '수행 준거'가 무엇인지 정확히 파악하고, 실습 시 그 준거를 달성하는 데 집중해야 합니다.
통합적 사고: 외부 평가는 여러 능력 단위가 통합된 형태의 실무 문제로 출제됩니다. DB와 프로그래밍, 보안 지식을 융합하여 문제를 해결하는 훈련을 해야 합니다.

다음 이야기: 서포터즈 활동을 마무리하며

정보처리산업기사 과정평가형은 저에게 자격증 이상의 가치를 선물해 주었습니다. 이 경험을 공유하면서 저 또한 제가 배운 지식을 다시 한번 정리할 수 있었습니다.

다음 최종 게시글에서는 이 6개월간의 서포터즈 활동 후기와 함께, 과정평가형 제도를 통해 성장할 여러분을 진심으로 응원하는 메시지를 담아 마무리하겠습니다.

본 게시글은 한국산업인력공단 과정평가형 정보처리산업기사 서포터즈 활동비를 지원받아 작성되었습니다.

[LGTM] Tempo: 100% 샘플링을 실현한 분산 트레이싱과 MSA 병목 추적

예르미(yermi) — Sat, 2 May 2026 12:39:40 +0900

- Tempo: 100% 샘플링을 실현한 분산 트레이싱과 MSA 병목 추적

메트릭(Mimir)을 통해 장애의 '발생'을 인지하고, 로그(Loki)를 통해 에러의 '원인'을 파악하는 과정까지 살펴보았습니다. 이제 관측성의 마지막 퍼즐이자, 거대한 마이크로서비스 아키텍처(MSA) 환경에서 가장 까다로운 질문인 "도대체 수많은 서비스 중 어디서 병목이 발생했는가?"를 해결할 차례입니다.

이번 포스팅에서는 LGTM 스택의 'T'를 담당하며 분산 트레이싱 백엔드의 새로운 패러다임을 제시한 Tempo(템포)에 대해 깊이 파헤쳐 보겠습니다.

1. 분산 트레이싱의 딜레마: '샘플링(Sampling)의 저주'

하나의 사용자 요청이 API 게이트웨이를 거쳐 Auth, Payment, Inventory, Database 등 수십 개의 마이크로서비스를 통과하는 환경을 상상해 보십시오. 특정 요청이 지연될 때, 어느 구간에서 병목이 발생했는지 추적하기 위해 기존에는 Jaeger나 Zipkin 같은 분산 추적 시스템을 사용해 왔습니다.

하지만 기존 시스템들은 데이터를 저장할 때 Cassandra나 Elasticsearch 같은 무겁고 값비싼 스토리지를 백엔드로 사용했습니다. 트레이스 데이터는 메트릭이나 로그보다 훨씬 방대하기 때문에, 쏟아지는 트레이스를 모두 저장하다가는 인프라 비용이 파산 수준에 이르게 됩니다. 그래서 엔지니어들은 어쩔 수 없이 샘플링(Sampling)이라는 타협안을 선택했습니다. "전체 트래픽의 1% 또는 5%만 랜덤하게 수집하자."

이로 인해 치명적인 문제가 발생합니다. 간헐적으로 발생하는 심각한 장애나 특정 결제 실패 건을 추적하려고 할 때, 정작 내가 찾고자 하는 그 요청의 트레이스 데이터는 샘플링에 걸러져 유실되어 버리는 현상입니다. 바늘을 찾기 위해 건초더미의 95%를 태워버리는 격이었습니다.

분산 트레이싱의 딜레마: 샘플링의 저주

2. Tempo의 파괴적 혁신: "버리지 말고 다 저장해라"

Grafana Labs는 Tempo를 설계하며 앞서 살펴본 Mimir, Loki와 완벽하게 동일한 철학을 적용했습니다. 바로 비용 효율적인 오브젝트 스토리지(S3, GCS)의 적극적인 활용과 인덱스 최소화(Index-free)입니다.

Tempo는 복잡한 검색을 위한 인덱스를 거의 만들지 않습니다. 오직 고유한 식별자인 TraceID만으로 데이터를 찾을 수 있도록 아키텍처를 극단적으로 단순화했습니다. 인덱싱 오버헤드가 사라지고 스토리지가 저렴해지자, 마침내 타협할 필요가 없어졌습니다.

Tempo는 100% 샘플링을 지향합니다. 버려지는 데이터 없이 모든 사용자 요청의 라이프사이클을 기록합니다. 언제 어떤 에러가 발생하든 해당 TraceID만 알고 있다면, 그 요청이 수십 개의 컨테이너와 비동기 메시지 큐(Kafka 등)를 어떻게 관통했는지 폭포수(Waterfall) 차트로 완벽하게 복원해 냅니다.

3. Tempo 아키텍처와 W3C Trace Context

분산 트레이싱이 성립하려면 여러 서비스가 동일한 맥락을 공유해야 합니다. Tempo는 CNCF의 관측성 표준인 OpenTelemetry(OTel)를 네이티브로 지원하며, W3C Trace Context 규격을 통해 서비스 간 컨텍스트를 전파합니다. 시스템 내부적인 동작 구조는 다음과 같습니다.

Tempo 아키텍처와 W3C Trace Context

기술적 동작 원리:

Context Propagation: 첫 요청 시 생성된 고유 식별자(TraceID)가 traceparent 등의 HTTP 헤더나 이벤트 브로커(Kafka 등)의 메타데이터에 담겨 마이크로서비스의 호출 체인을 따라 전파됩니다.
Span 수집 (OTLP): 각 서비스는 자신의 작업 구간(Span)을 OpenTelemetry 포맷(OTLP)으로 수집 에이전트인 Grafana Alloy에 비동기로 전송합니다.
수신 및 저장 (Distributor & Ingester): Tempo의 Distributor가 트래픽을 받아 Ingester로 분배하며, Ingester는 스팬들을 메모리에 버퍼링 후 압축하여 S3 객체 스토리지에 블록 형태로 저장합니다.
O(1) 수준의 단일 조회: Grafana에서 TraceID를 입력하면, Querier는 무거운 검색을 수행하는 대신 블록 내 블룸 필터를 활용하여 해당 트레이스가 위치한 S3 오프셋을 찾아내 데이터를 가져옵니다.

4. 완성된 통합: 점과 점을 잇다

Tempo의 진정한 위력은 단독으로 쓰일 때보다 메트릭, 로그와 결합할 때 발휘됩니다. Tempo는 앞선 포스팅에서 보았던 '단일 장애 추적 파이프라인'의 핵심 연결 고리입니다.

Mimir(메트릭) -> Tempo: CPU 사용량 급증 알람을 보고 대시보드에 들어가면, 메트릭 그래프 위의 점에 TraceID가 매핑되어 있습니다. 클릭 한 번으로 장애 당시의 정확한 트레이스 뷰로 넘어갑니다.
Tempo -> Loki(로그): 트레이스 폭포수 차트에서 유독 오래 걸린 특정 서비스의 구간을 발견합니다. 해당 Span을 클릭하면, 그 Span 내에서 발생한 애플리케이션 로그(Loki)만 정확하게 필터링되어 나타납니다.

이러한 유기적인 연결은 이벤트 기반 아키텍처나 비동기 통신이 잦은 복잡한 시스템에서 엔지니어의 디버깅 시간을 혁신적으로 단축해 줍니다.

5. 마무리하며

파편화되어 있던 데이터들을 하나의 문맥으로 엮어내는 LGTM 스택의 컴포넌트들을 모두 살펴보았습니다. 오브젝트 스토리지를 백엔드로 삼아 무한한 확장성과 가성비를 달성한 이 관측성 파이프라인은 단순히 장애 처리를 빠르게 하는 것을 넘어섭니다. 이렇게 100% 샘플링되어 정형화된 고품질의 텔레메트리 데이터(Metrics, Logs, Traces)는, 향후 머신러닝 알고리즘이 시스템의 이상 징후를 스스로 탐지하고 근본 원인을 추론하는 AIOps(Artificial Intelligence for IT Operations) 플랫폼으로 진화하기 위한 가장 강력한 기반 데이터 셋이 됩니다.

[LGTM] Loki: 인덱스 프리 아키텍처로 완성하는 압도적 가성비의 로그 중앙화

예르미(yermi) — Fri, 1 May 2026 02:19:42 +0900

- Loki: 인덱스 프리 아키텍처로 완성하는 압도적 가성비의 로그 중앙화

지난 포스팅에서는 Mimir를 통해 어떻게 메트릭 데이터의 수평 확장과 장기 보관 문제를 해결하는지 살펴보았습니다. 메트릭(Mimir)이 알람을 통해 장애의 '발생'을 알려주었다면, 이제 엔지니어는 에러의 스택 트레이스나 쿼리 로그를 뒤져 장애의 '근본 원인'을 찾아내야 합니다.

이번 포스팅에서는 LGTM 스택에서 로그(Logs)를 담당하며, 기존 로그 관리의 패러다임을 완전히 뒤집어버린 Loki(로키)에 대해 깊이 있게 다뤄보겠습니다.

1. ELK 스택의 딜레마: 로그는 너무 무겁고 비싸다

지난 수년간 로그 중앙화의 사실상 표준은 Elasticsearch, Logstash, Kibana로 이루어진 ELK 스택이었습니다. Elasticsearch는 강력한 전문 검색 엔진입니다. 어떤 단어로 검색하든 0.1초 만에 결과를 뱉어냅니다. 하지만 이 강력한 성능 이면에는 치명적인 단점이 존재합니다. 바로 '압도적인 유지보수 비용'입니다.

무거운 역색인(Inverted Index): Elasticsearch는 들어오는 모든 로그 메시지를 파싱하고 쪼개어 거대한 역색인 사전을 만듭니다. 이로 인해 원본 로그 데이터보다 인덱스 용량이 더 커지는 배보다 배꼽이 큰 상황이 빈번하게 발생합니다.
고가의 스토리지 요구: 빠른 인덱스 검색을 위해 필연적으로 고성능의 SSD를 요구합니다. 하루에 수백 GB에서 수 TB씩 쏟아지는 MSA 환경의 로그를 모두 SSD에 장기 보관하는 것은 인프라 예산의 재앙과 같습니다.
OOM(Out Of Memory) 이슈: 인덱스가 커질수록 JVM Heap 메모리 사용량이 급증하여, 클러스터 안정성을 유지하기 위한 엔지니어의 운영 피로도가 극심해집니다.

ELK 스택의 딜레마: 로그는 너무 무겁고 비싸다

대부분의 로그는 'Write Heavy, Read Rarely'(쓰기는 엄청나게 많지만, 실제 읽히는 것은 장애가 났을 때뿐인) 특성을 가집니다. 어쩌다 한 번 장애 추적을 위해 검색할 로그에, 막대한 인덱싱 비용과 SSD를 투자하는 것이 과연 합리적일까요?

2. Loki의 철학: 인덱스 프리(Index-Free) 아키텍처

Grafana Labs는 이 지점에서 완전히 다른 접근을 시도합니다. "모든 것을 인덱싱하지 말고, 메타데이터만 인덱싱하자." 이것이 바로 프로메테우스에서 영감을 받은 Loki의 핵심 철학입니다.

① 라벨(Label) 기반의 메타데이터 인덱싱

Loki는 로그의 본문(메시지 텍스트)을 분석하거나 인덱싱하지 않습니다. 대신 해당 로그가 어디서 왔는지 나타내는 꼬리표, 즉 라벨(예: app="payment", env="prod", level="error")만 인덱스로 만듭니다. 인덱스가 극도로 작아지므로 메모리와 스토리지 사용량이 기하급수적으로 줄어듭니다.

② 저렴한 오브젝트 스토리지에 압축 저장

인덱싱되지 않은 거대한 원본 로그 데이터는 Chunk 형태로 고도로 압축되어 AWS S3, GCS, MinIO와 같은 매우 저렴한 오브젝트 스토리지에 곧바로 저장됩니다. 비싼 SSD가 필요 없습니다.

3. Loki 아키텍처: 분산 Grep 엔진

그렇다면 인덱스도 없이 어떻게 방대한 로그에서 원하는 에러 문구를 찾아낼까요? Loki는 검색 시점에 압도적인 분산 병렬 컴퓨팅 능력으로 오브젝트 스토리지를 Full Scan 해버리는 방식을 택했습니다. 쉽게 말해 클러스터 전체가 달려들어 수행하는 '초고속 분산 Grep'입니다.

Loki 아키텍처: 분산 Grep 엔진

동작 워크플로우:

수집 (Alloy/Promtail): 각 노드에 배포된 에이전트가 로그를 수집하고, 쿠버네티스의 파드 라벨 등을 메타데이터로 부착하여 Loki 서버의 Distributor로 전송합니다.
저장 (Ingester): 수집된 로그는 메모리에 잠시 머물다 압축된 Chunk 형태로 S3와 같은 Object Storage에 쓰입니다.
조회 (Querier & Query Frontend): 사용자가 검색을 요청하면, Query Frontend가 쿼리를 잘게 쪼개어 수많은 Querier 워커들에게 분배합니다.
분산 Grep 처리: Querier들은 먼저 라벨 인덱스를 통해 S3의 수많은 파일 중 '어느 청크를 뒤져야 할지' 범위를 대폭 좁힙니다. (예: app="payment" 라벨이 붙은 청크만 다운로드). 이후 해당 청크들의 압축을 풀고 메모리 위에서 정규표현식으로 타겟 텍스트를 고속으로 스캔합니다.

4. LogQL: 프로메테우스의 유산을 이어받다

Loki의 쿼리 언어인 LogQL은 PromQL과 매우 유사한 문법을 가집니다. 크게 두 가지 역할을 수행합니다.

① Log Queries (로그 필터링)

라벨 매처를 통해 로그 스트림을 좁히고, 파이프(|) 연산자를 통해 텍스트를 필터링하거나 파싱합니다.

예시: {app="payment", env="prod"} |= "NullPointerException" | json
(해석: prod 환경의 payment 앱 로그 중 "NullPointerException"이 포함된 로그만 가져와서 JSON 형태로 파싱하라)

② Metric Queries (로그의 메트릭화)

단순한 텍스트 검색을 넘어, 특정 에러 로그가 발생하는 빈도를 실시간 시계열 메트릭(그래프)으로 변환할 수 있습니다.

예시: rate({app="payment"} |= "error" [5m])
(해석: payment 앱에서 최근 5분간 "error" 단어가 포함된 로그의 초당 발생 횟수를 그래프로 그려라)

이 기능을 통해 별도의 애플리케이션 메트릭 코드를 작성하지 않아도, 로그만으로 훌륭한 모니터링 대시보드와 알람을 구축할 수 있습니다.

5. 마무리하며

Loki는 "검색 속도를 위해 모든 자원을 쏟아붓는" 기존의 패러다임에서 벗어나, "클라우드 시대의 저렴한 오브젝트 스토리지와 스케일 아웃이 쉬운 컴퓨팅 파워를 활용하여 비용 효율성을 극대화하는" 방향으로 로그 아키텍처를 재정의했습니다.

단순 검색 속도는 역색인 기반의 Elasticsearch가 빠를 수 있지만, 라벨이라는 동일한 문맥을 통해 메트릭(Mimir)에서 로그(Loki)로 단 한 번의 클릭만으로 이어지는 Seamless한 트러블슈팅 경험, 그리고 S3 기반의 압도적인 스토리지 비용 절감은 왜 많은 조직이 LGTM 스택으로 마이그레이션을 선택하는지 증명합니다.

[일상] CS50’s Introduction to Artificial Intelligence with Python 강좌 수료 [AI의 '블랙박스'를 열고 논리와 확률을 마주하다]

예르미(yermi) — Thu, 30 Apr 2026 13:54:31 +0900

This is CS50 AI.

요즘 어딜 가나 AI 이야기뿐입니다. 현업에서 ChatGPT나 GitHub Copilot 같은 도구들을 숨 쉬듯 쓰고 있지만, 정작 그 이면에 어떤 원리가 숨어있는지 막연하게 느껴질 때가 많았습니다.

AI의 기초적인 동작 원리를 수학적, 논리적 관점에서 훑어볼 수 있는 하버드의 CS50 AI 과정은 아주 훌륭한 길잡이가 되었습니다. 최신 딥러닝 트렌드만 좇기보다, 인공지능이라는 학문이 어떻게 발전해 왔는지 고전적인 탐색 알고리즘부터 머신러닝의 기초까지 넓고 얕게 경험해 볼 수 있었습니다.

CS50’s Introduction to Artificial Intelligence with Python

Search & Games (탐색과 게임 트리) 가장 먼저 만난 것은 틱택토(Tic-Tac-Toe)를 완벽하게 플레이하는 AI를 만드는 과제였습니다. 단순히 경우의 수를 다 나열하는 것이 아니라, Minimax 알고리즘을 통해 나와 상대방의 최선의 수를 계산하는 논리를 배웠습니다. Alpha-Beta Pruning으로 불필요한 계산을 쳐내며 탐색 트리를 최적화하는 과정은, 마치 미로 찾기에서 가장 효율적인 길을 찾아내는 것 같은 재미가 있었습니다.

Search & Games (탐색과 게임 트리)

Knowledge & Logic (지식과 논리 표현) AI가 인간의 언어나 명제를 어떻게 이해하고 추론하는지 배우는 파트였습니다. "비가 오면 우산을 쓴다" 같은 문장들을 명제 논리로 변환하고, 모델 체킹을 통해 새로운 사실을 도출해 내는 과정은 꽤나 철학적으로 다가오기도 했습니다.

Knowledge & Logic (지식과 논리 표현)

Uncertainty & Probability (불확실성과 확률) 현실 세계는 명확한 논리보다 불확실성으로 가득 차 있습니다. 이 파트에서는 Bayes' Rule과 Markov Models를 다루었습니다. 주사위 확률처럼 단순한 예시부터 시작해, 오늘의 날씨로 내일의 날씨를 예측하는 숨겨진 마르코프 모델(Hidden Markov Model)까지, AI가 어떻게 확률적으로 세상을 판단하는지 엿볼 수 있었습니다.

Uncertainty & Probability (불확실성과 확률)

Optimization & Machine Learning (최적화와 머신러닝 기초) Local Maxima의 함정에 빠지지 않고 Global Maximum을 찾아가는 Hill Climbing이나 Simulated Annealing 같은 최적화 알고리즘도 다뤘습니다. 또한, 데이터를 기반으로 선을 그어 분류하는 SVM(Support Vector Machine)의 기본 원리와, 이미지 인식에 쓰이는 CNN(Convolutional Neural Network)의 합성곱, 풀링, 평탄화 과정까지 훑어보며 현대적인 딥러닝의 맛을 살짝 보았습니다.

Optimization & Machine Learning (최적화와 머신러닝 기초)

CS50 AI는 당장 현업에서 최첨단 AI 모델을 직접 바닥부터 짜기 위한 강의는 아닙니다. 하지만, 우리가 매일 쓰는 AI 도구들이 어떤 수학적 배경과 논리적 추론을 거쳐 결과를 내놓는지, 그 '블랙박스' 안의 풍경을 구경하게 해 줍니다. 단순한 API 호출을 넘어, 데이터가 주어졌을 때 AI가 어떤 방식으로 문제를 해결해 나가는지 전반적인 '감'을 잡는 데 이보다 좋은 강의는 없을 것 같습니다.

[LGTM] Prometheus와 Mimir: 한계 없는 TSDB와 메트릭 생태계 구축

예르미(yermi) — Wed, 29 Apr 2026 21:06:14 +0900

- Prometheus와 Mimir: 한계 없는 TSDB와 메트릭 생태계 구축

지난 포스팅에서는 관측성의 핵심인 MELT 데이터 모델과 기존 파편화된 모니터링 환경을 통합하는 LGTM 스택의 전체적인 청사진을 그려보았습니다. 이번 2편부터는 LGTM의 각 컴포넌트를 하나씩 딥다이브 해보려 합니다.

그 첫 번째 주자는 장애의 '발생'을 가장 먼저 인지하게 해주는 관측성의 최전선, 메트릭(Metrics)을 담당하는 Prometheus(프로메테우스)와 Mimir(미미르)입니다.

1. 프로메테우스의 철학: K8s 시대의 모니터링 표준

프로메테우스의 철학: K8s 시대의 모니터링 표준

프로메테우스는 단순한 모니터링 툴이 아니라, 클라우드 네이티브 생태계에서 메트릭을 수집하고 질의하는 하나의 '표준 프로토콜'로 자리 잡았습니다. 프로메테우스가 이토록 성공할 수 있었던 핵심 아키텍처 철학은 두 가지입니다.

① 풀(Pull) 모델 기반의 수집

기존의 전통적인 모니터링 에이전트들은 대상 서버에서 중앙 서버로 데이터를 밀어 넣는 Push 방식을 사용했습니다. 하지만 동적으로 파드가 생성되고 소멸하는 K8s 환경에서는 푸시 방식의 엔드포인트 관리가 매우 어렵습니다. 반면 프로메테우스는 중앙 서버가 타겟 엔드포인트(.../metrics)로 접근해 데이터를 가져오는 Pull 모델을 채택했습니다. 서비스 디스커버리와 결합하여, 모니터링 대상이 늘어나거나 IP가 변경되어도 수집 서버가 이를 동적으로 파악하고 스크랩할 수 있습니다.

② 다차원 데이터 모델과 PromQL

메트릭 데이터를 단순히 이름과 값으로 저장하지 않고, 키-값(Key-Value) 형태의 레이블을 부여하는 다차원 데이터 모델(Multi-dimensional Data Model)을 사용합니다.

예: http_requests_total{method="GET", status="200", service="auth"} 그리고 이를 필터링, 집계, 연산할 수 있는 강력한 시계열 쿼리 언어인 PromQL을 제공하여 엔지니어가 원하는 거의 모든 형태의 메트릭 대시보드를 구성할 수 있게 해줍니다.

2. 프로메테우스의 한계: 왜 Mimir가 필요해졌을까?

프로메테우스는 훌륭한 툴이지만, 엔터프라이즈 환경에서 단독으로 운영하기에는 치명적인 아키텍처적 한계가 존재합니다.

단일 노드 아키텍처 (확장성 한계): 프로메테우스는 본질적으로 단일 노드 기반으로 동작합니다. 수집해야 할 타겟과 메트릭이 폭발적으로 증가하면, 프로메테우스 서버의 메모리와 CPU가 버티지 못합니다. (Federation 기능을 지원하지만 설정이 복잡하고 유지보수가 어렵습니다.)
고가용성(HA)의 부재: 프로메테우스를 이중화하더라도, 두 서버가 각각 독립적으로 타겟을 스크랩하므로 데이터의 일관성이 보장되지 않고 중복 데이터가 발생합니다.
로컬 스토리지 의존성 (장기 보관 불가): 메트릭을 로컬 디스크(TSDB)에 저장하기 때문에 디스크 용량의 한계가 곧 데이터 보관 주기의 한계입니다. 수개월에서 수년 치의 데이터를 보관하며 트렌드를 분석하는 데는 적합하지 않습니다.

이러한 HA, Scale-out, 장기 보관이라는 3가지 난제를 완벽하게 해결하기 위해 Grafana Labs가 내놓은 오픈소스 프로젝트가 바로 Mimir입니다.

3. Mimir 아키텍처: 메트릭 생태계의 스케일 아웃

Mimir는 철저하게 마이크로서비스 아키텍처(MSA)로 설계된 시계열 데이터베이스(TSDB)입니다. 프로메테우스가 하던 역할을 '수집'과 '저장/질의'로 완벽하게 분리합니다. 아래는 프로메테우스(또는 Grafana Alloy)가 에이전트 역할을 하고, Mimir가 중앙 저장소 역할을 하는 통합 아키텍처입니다.

Mimir 아키텍처: 메트릭 생태계의 스케일 아웃

- Mimir 아키텍처의 핵심 동작 원리:

Remote Write 분리: 프로메테우스(또는 Alloy)는 각 클러스터에서 메트릭을 Pull 방식으로 수집한 뒤, 이를 자체 로컬에 저장하지 않고 Mimir의 Distributor로 Push(remote_write) 합니다.
데이터 중복 제거와 HA (Distributor & Ingester): Distributor는 들어온 데이터를 해싱하여 여러 Ingester 노드에 복제합니다. 이 과정에서 프로메테우스 이중화로 인해 발생한 중복 데이터를 완벽하게 식별하고 제거합니다.
무한한 스토리지 확장 (Object Storage): Ingester는 데이터를 메모리에 들고 있다가 약 2시간 단위로 TSDB 블록을 생성하여 S3나 GCS 같은 저렴한 오브젝트 스토리지에 밀어 넣습니다. 이로써 값비싼 블록 스토리지 없이도 메트릭을 무한히, 그리고 저렴하게 장기 보관할 수 있게 됩니다.
성능 최적화 (Compactor): Compactor는 오브젝트 스토리지에 저장된 자잘한 블록들을 주기적으로 병합하여 쿼리 성능을 최적화하고 스토리지 비용을 한 번 더 절감합니다.

4. 정리하며

이제 메트릭 수집 파이프라인의 명확한 역할 분담이 보입니다. 프로메테우스(혹은 Alloy)는 각 서비스에 가장 가까운 곳에서 타겟을 디스커버리하고 데이터를 긁어오는 가벼운 에이전트의 역할에 집중합니다. 그리고 무거운 데이터 저장, 중복 제거, 장기 보관, 그리고 복잡한 PromQL 질의 처리는 수평 확장이 가능한 Mimir가 전담하게 됩니다.

이러한 아키텍처를 통해 엔지니어는 인프라 규모가 아무리 커지더라도 단일 뷰에서 수년 치의 메트릭을 지연 없이 빠르게 조회할 수 있는 강력한 모니터링 환경을 얻게 됩니다.

[LGTM] 관측성의 핵심(MELT) & LGTM 아키텍처 개요: 파편화된 생태계를 통합하다

예르미(yermi) — Tue, 28 Apr 2026 00:30:08 +0900

- 관측성의 핵심(MELT) & LGTM 아키텍처 개요

Cloud Native와 MSA가 엔터프라이즈 환경의 표준으로 자리 잡으면서, 우리가 시스템을 바라보는 관점도 완전히 달라져야 했습니다. 과거의 '모니터링'이 단순히 "시스템이 살아있는가?"를 묻는 수동적인 행위였다면, 이제는 복잡하게 얽힌 분산 환경에서 "왜 문제가 발생했는가?"를 능동적으로 추적하는 '관측성(Observability)'의 시대로 넘어왔습니다.

이번 포스팅에서는 관측성을 구성하는 핵심 데이터 모델을 짚어보고, 대용량 트래픽 환경에서 기존 파편화된 스택의 한계를 극복하며 새로운 표준으로 자리 잡은 LGTM 스택(Loki, Grafana, Tempo, Mimir)의 아키텍처적 당위성을 살펴보겠습니다.

1. 모니터링을 넘어선 관측성: MELT 데이터 모델

최신 클라우드 네이티브 환경에서 관측성을 완벽하게 확보하기 위한 핵심 데이터 모델은 MELT라는 4가지 축으로 정의됩니다.

M (Metrics - 메트릭): 시스템의 상태를 나타내는 압축된 시계열 데이터(CPU, Memory, TPS, 에러율 등)입니다. 장애나 이상 징후의 '발생(What)'을 가장 먼저 인지하게 해주는 알람의 트리거가 됩니다.
E (Events - 이벤트): 배포, 스케일링, 파드 재시작, K8s 설정 변경 등 시스템 상태를 변화시키는 유의미한 사건들의 기록입니다. 장애 발생 전후의 환경 변화를 파악하는 데 중요합니다.
L (Logs - 로그): 애플리케이션이나 인프라가 남기는 가장 원시적이고 구체적인 텍스트 기록입니다. 에러 스택 트레이스나 쿼리 실행 내역 등을 통해 장애의 '근본 원인'을 파악하는 데 필수적인 단서를 제공합니다.
T (Traces - 트레이스): 하나의 사용자 요청이 여러 마이크로서비스를 거쳐가는 라이프사이클을 추적합니다. 분산 환경에서 장애가 '어느 서비스의 어느 구간'에서 발생했는지 병목 지점을 정확하게 특정합니다.

2. LGTM 스택 아키텍처 개요: MELT의 구현체들

LGTM은 앞서 설명한 관측성의 핵심 데이터(MELT)를 완벽하게 커버하기 위해 Grafana Labs가 주도하는 4가지 오픈소스 프로젝트의 유기적인 조합입니다. 각 컴포넌트는 특정 데이터 모델을 저장하고 쿼리하는 데 특화되어 있습니다.

L (Loki - Logs): 프로메테우스에서 영감을 받은 비용 효율적인 로그 집계 시스템입니다. 실제 로그 데이터는 압축하여 S3/GCS와 같은 저렴한 오브젝트 스토리지에 저장하고 메타데이터만 인덱싱하는 '인덱스 프리' 아키텍처를 기반으로 합니다. LogQL을 통해 대용량 로그 스트리밍 및 로그의 실시간 메트릭 변환을 지원합니다.
G (Grafana - Visualization): 수많은 텔레메트리 데이터 소스를 하나의 대시보드에 통합하는 관측성의 프론트엔드 플랫폼입니다. 단순 시각화를 넘어, Alerting 통합, RBAC, 프로비저닝을 통한 대시보드 as Code를 지원합니다.
T (Tempo - Traces): 막대한 양의 분산 트레이스 데이터를 저장하기 위한 고가용성 백엔드입니다. OpenTelemetry를 네이티브로 지원하며, 100%의 샘플링 데이터를 오브젝트 스토리지에 효율적으로 저장하고 검색하는 데 특화되어 있습니다.
M (Mimir - Metrics): 기존 Prometheus 아키텍처의 한계였던 고가용성(HA) 구성과 장기 보관 문제를 완벽하게 해결한 차세대 시계열 데이터베이스(TSDB)입니다. 뛰어난 클러스터 확장성과 멀티 테넌시를 제공하며 PromQL을 완벽하게 지원합니다.

LGTM 스택 아키텍처 개요: MELT의 구현체들

3. 왜 지금 LGTM 스택인가? (파편화된 생태계의 통합)

각 도구의 역할을 이해했다면, 이제 왜 이들이 반드시 통합되어야 하는지 알아볼 차례입니다. 기존 모니터링 아키텍처의 가장 큰 고질병은 '데이터와 툴의 파편화(Siloed Stack)'였습니다.

많은 조직이 메트릭은 Prometheus+Grafana, 로그는 ELK(Kibana) 스택, 분산 추적은 Jaeger나 Zipkin을 각각 따로 구축하여 사용했습니다. 아래 다이어그램처럼 이 구조에서는 장애 상황이 발생하면 엔지니어들이 Grafana 대시보드, Kibana 로그 검색 창, Jaeger 트레이스 화면을 번갈아 띄워놓고 타임스탬프를 눈으로 맞춰가며 에러를 추적해야 하는 심각한 컨텍스트 스위칭 비용을 치러야 했습니다.

LGTM: 파편화된 생태계의 통합

이러한 파편화와 비용 문제를 동시에 해결하며 사실상 새로운 표준으로 자리 잡은 것이 바로 LGTM 스택입니다.

① 컨텍스트의 완벽한 연결 (Seamless Correlation)

LGTM은 파편화되어 있던 데이터들을 Grafana라는 단일 창구에서 유기적으로 연결합니다. 아래 시퀀스 다이어그램처럼 Exemplar와 TraceID를 활용하여 메트릭에서 트레이스로, 트레이스에서 로그로 물 흐르듯 이어지는 단일 장애 추적 파이프라인을 제공합니다. 이는 트러블슈팅 시간을 극적으로 단축시킵니다.

② 압도적인 비용 효율성 (Object Storage First)

기존 Elasticsearch가 모든 로그 내용에 무거운 역색인을 걸어 비싼 스토리지를 요구했던 것과 달리, LGTM의 로그(Loki)와 트레이스(Tempo) 시스템은 데이터를 압축하여 S3/GCS와 같은 저렴한 오브젝트 스토리지에 저장합니다. 이는 인프라 운영 비용을 ELK 스택 대비 획기적으로 절감하면서도 분산 병렬 쿼리를 통해 충분한 검색 속도를 보장합니다.

4. 마무리하며

분산 환경에서 파편화된 데이터를 중앙화하고, 메트릭, 트레이스, 로그를 하나의 문맥으로 엮어내는 것은 단순히 인프라의 가시성을 높이는 것을 넘어섭니다. 궁극적으로는 이렇게 정제되고 정형화된 관측성 데이터를 토대로, 향후 AI가 시스템의 이상을 스스로 탐지하고 장애의 근본 원인을 자동 분석하는 AIOps 플랫폼으로 도약하기 위한 필수적인 뼈대가 됩니다.

[도서리뷰] 클라우드 애플리케이션 아키텍처 패턴 - 왜 우리 시스템은 클라우드에서도 여전히 불안할까?

예르미(yermi) — Mon, 27 Apr 2026 21:32:35 +0900

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

왜 우리 시스템은 클라우드에서도 여전히 불안할까?

개발 연차가 쌓이면서 단순한 기능 구현을 넘어, 시스템 전체의 큰 그림을 그려야 하는 순간이 옵니다. 특히 모놀리식 구조에서 마이크로서비스(MSA)나 클라우드 환경으로 넘어갈 때 가장 크게 착각하는 것이 있습니다. 바로 "클라우드 벤더(AWS, Azure 등)의 인프라를 쓰면 알아서 고가용성과 확장성이 보장될 것"이라는 믿음입니다.

하지만 분산 환경으로 시스템을 쪼개는 순간, 네트워크 지연, 트랜잭션 불일치, 연쇄 장애라는 새로운 지옥문이 열립니다. 한빛미디어의 신간 <클라우드 애플리케이션 아키텍처 패턴>은 바로 이 지점에서 우리가 겪게 될 필연적인 문제들과 그 해결책을 다루는 책입니다. 특정 클라우드 벤더의 사용법을 다루는 매뉴얼이 아니라, 변하지 않는 설계의 '정석'을 담고 있습니다.

복잡한 분산 환경을 통제하기 위한 아키텍트의 나침반

데이터의 늪에서 탈출하기 (CQRS와 이벤트 소싱)

책에서 가장 몰입해서 읽었던 부분은 분산 데이터 관리에 대한 패턴들입니다. 시스템이 분리되면 가장 먼저 부딪히는 문제가 "DB 트랜잭션을 어떻게 맞출 것인가?"입니다. 기존처럼 하나의 DB에서 JOIN을 걸어 해결할 수 없기 때문입니다.

이 책은 CQRS(명령과 조회의 책임 분리)와 이벤트 소싱(Event Sourcing) 패턴을 통해 이 딜레마를 우아하게 풀어냅니다. 상태를 단순히 덮어쓰는 것이 아니라, 일어난 '이벤트의 연속'으로 저장하고(Event Sourcing), 데이터를 쓰는 모델과 읽는 모델을 물리적/논리적으로 분리(CQRS)하는 과정을 매우 상세하게 다룹니다. 책의 설명을 따라가다 보면, 비동기 메시징 환경에서 발생할 수 있는 '최종 일관성(Eventual Consistency)'을 어떻게 아키텍처 수준에서 제어할 수 있는지 명확한 감을 잡을 수 있습니다.

데이터를 단순히 저장하는 것을 넘어, 데이터의 '흐름'을 설계하는 방법을 구체적인 도식과 함께 설명한다.

실패를 전제로 한 설계 (Resiliency Patterns)

클라우드 네이티브 아키텍처의 대전제는 "장애는 반드시, 언제나 일어난다"입니다. 이 책은 장애를 막는 것이 아니라, 장애가 발생했을 때 시스템 전체로 번지지 않도록 격리하는 복원력(Resiliency)에 상당한 지면을 할애합니다.

서킷 브레이커(Circuit Breaker): 외부 서비스에 장애가 났을 때 무의미한 호출을 차단하여 리소스 고갈을 막는 패턴.
재시도(Retry) 및 벌크헤드(Bulkhead): 일시적인 네트워크 오류를 극복하고, 하나의 컴포넌트 장애가 전체 시스템을 침몰시키지 않도록 격벽을 치는 방법.

이러한 패턴들을 읽으면서, 평소 코드 레벨에서 try-catch로만 방어하려 했던 제 자신을 반성하게 되었습니다. 동시에 시스템 전반의 상태를 모니터링하는 관측성(Observability)이 왜 분산 환경에서 선택이 아닌 필수인지, 그 철학적 배경을 이해할 수 있었습니다. 분산된 로그와 메트릭을 추적할 수 없다면, 서킷 브레이커가 열렸는지 닫혔는지조차 알 수 없기 때문입니다.

장애를 피할 수 없다면, 우아하게 복구하라.

- 총평 및 추천 대상

<클라우드 애플리케이션 아키텍처 패턴>은 당장 내일 복붙해서 쓸 수 있는 코드를 알려주지는 않습니다. 대신, 어떤 클라우드 환경에서든 흔들리지 않는 견고한 시스템 설계도를 그리는 법을 알려줍니다.

✅ 이런 분들에게 강력 추천합니다:

단일 톰캣/DB 환경을 벗어나, 본격적으로 MSA 기반 클라우드 환경을 설계해야 하는 개발자
트래픽이 늘어날 때마다 DB 락(Lock)과 장애 속에서 임시방편으로 대처하고 있는 백엔드 엔지니어
기능 구현을 넘어 시스템 전체의 아키텍처를 조망하고 싶은 주니어~중니어 엔지니어

당신의 코드가 훌륭하더라도, 아키텍처 패턴이 잘못되었다면 시스템은 결국 무너집니다. 본격적인 클라우드 네이티브로의 도약을 고민하고 있다면, 코드를 짜기 전 이 책을 먼저 펼쳐보시기를 권합니다.

예르미의 코딩노트

[KubeCon Japan 2026] 첫날 키노트 (2) : 일본 기업들의 실전 사례

왜 멀티테넌시인가 : Preferred Networks

3시간을 3분으로 : Subaru

15명이 1,300개 클러스터를 : LY Corporation

Argo CD 하나로 5,000개 앱을 : Hyundai AutoEver

마치며

[오늘가챠] 비동기(@Async)의 늪: 외부 통신 중 마주친 JPA Detached Entity 해결기

1. 섣부른 비동기 처리의 시도

2. 원인 파악: 스레드(ThreadLocal)와 OSIV의 한계

3. 해결책: 트랜잭션 분리와 식별자(ID) 전달 패턴

4. 마무리

[KubeCon Japan 2026] 첫날 키노트 (1) : 무한한 수요와 유한한 컴퓨트⚡

오프닝 : "Keep Cloud Native Moving"

뒤집힌 그래프 하나

♾️ 무한한 에이전트, 유한한 Kubernetes

️ GPU 중심 인프라로의 전환

마치며

[K8s] 제로 트러스트를 향한 클러스터 내부 보안: Network Policy와 RBAC

1. 기본값은 "모두 허용": K8s 네트워크의 위험한 출발점

2. Network Policy: Pod 간 방화벽

핵심 규칙

3. RBAC: "누가 K8s API를 호출할 수 있는가"

4. 요약: 제로 트러스트 보안 체크리스트

[오늘가챠] 성능 끌어올리기: CompletableFuture를 이용한 병렬 처리

1. 기존 방식의 문제점 (순차 실행)

2. CompletableFuture를 활용한 병렬 실행

Reverse Geocoding 구현 상세

3. 프론트엔드 측 추가 최적화: 이미지 리사이즈

4. 결과와 마무리

[K8s] K8s 네트워크의 진화와 성능 최적화: kube-proxy의 한계와 eBPF/Cilium

1. kube-proxy와 iptables의 한계

2. eBPF: 리눅스 커널 안에서 동작하는 프로그래밍 가능한 네트워크

3. Cilium: eBPF 위에 세운 K8s 네트워크 플랫폼

4. 요약: kube-proxy에서 Cilium으로의 전환

[KubeCon Japan 2026] 거기서 만난 사람들 : 부스와 세션장에서 이어진 인연

1️⃣ sysdig 부스에서 만난 한국인 엔지니어 : "이제는 CNAPP의 시대"

2️⃣ Grafana 부스의 Alloy 개발자 : 온프레미스 운영자의 오랜 궁금증

3️⃣ Java Champion : "Spring AI로 만들어 와라, 리뷰해주겠다"

마치며

[오늘가챠] 앱 생태계를 지켜라: dHash와 SHA-256을 활용한 이미지 중복 방어

1. 1차 방어: SHA-256 무결성 검사

2. 2차 방어: Perceptual Hash (dHash) 도입

dHash 알고리즘의 동작 원리

3. 해밍 거리(Hamming Distance) 계산

4. 마무리

[K8s] 트래픽 폭주에 대비하는 K8s 자동 확장 전략: HPA와 KEDA

1. HPA: CPU/메모리 기반의 기본 자동 확장

HPA의 한계

2. KEDA: 이벤트 기반의 차세대 오토스케일러

3. 요약: 실무에서의 선택 기준

[KubeCon Japan 2026] 참관 후기 : 요코하마에서 만난 클라우드 네이티브의 축제☁️

⚓ 파시피코 요코하마 도착 : "Keep Cloud Native Moving"

배지 하나에 담긴 디테일

오프닝 키노트 : 일본의 오픈 이노베이션 플랫폼

먹는 것까지 진심 : 도시락과 웰컴 리셉션

솔루션 쇼케이스 : 스폰서 부스 탐방

굿즈 리뷰 : 부스별 수확 정리

전리품, 그 후 : 사무실로 이어진 쿠버콘

마치며

[오늘가챠] 생성형 AI의 도입: Gemini 2.0 Flash와 안전장치

1. 기술 선정: 왜 Gemini인가?

2. 안전 정책과 프롬프트 엔지니어링

JSON 응답 파싱과 예외 처리

부적절 이미지 차단 시 후처리

3. 마무리

[K8s] 상태가 있는(Stateful) 데이터를 위한 스토리지 전략: PV, PVC와 StatefulSet

1. Pod의 치명적 약점: 휘발성(Ephemeral) 스토리지

2. PV와 PVC: 개발자와 인프라의 계약서

3. StatefulSet: 순서와 정체성이 있는 Pod

4. 요약: 언제 무엇을 쓸 것인가?

[오픈소스] 특수문자를 10개만 아는 강도 검사기를 고치다 [Password-Strength-Tester-and-Cracker]

근데 이슈에 적힌 수정은 한 줄이었다

그래서 코드보다 규칙을 먼저 적었다

그리고 내가 판 함정에 내가 빠졌다

테스트가 곧 명세다

다만, 고친 뒤에도 P@ssw0rd[]{}는 Strong이다

마무리

[도서리뷰] 누구나 이해하는 클라우드 인프라 지식 사전 - 기능은 다 만들었는데, 왜 새벽 3시에 전화가 울릴까?

인프라는 결국 '계층'을 보는 눈이다

다만, 고친 뒤에도 `P@ssw0rd[]{}`는 Strong이다