📌 1. 상황 정리

2026년 6월 30일, Spring Boot 3.5의 무료(OSS) 보안 패치가 종료된다. 이후 선택지는 세 가지다.

  • Spring Boot 4로 마이그레이션한다 — 무료, 대신 코드 수정 필요
  • 유료 지원을 구매한다 — 3.5에 대한 보안 패치를 계속 받는다
  • 아무것도 안 한다 — 새 CVE가 나와도 패치 없음

이 글은 두 번째 선택지, 유료 지원의 구체적인 내용을 정리한다. 누가 제공하고, 얼마이고, 어떻게 동작하는가.


📌 2. 유료 지원 제공자는 두 곳이다

2.1 Tanzu Spring (Broadcom/VMware) — 본가

Spring Boot를 만든 팀이 직접 제공하는 상용 지원이다. Spring의 모든 커미터가 Tanzu 팀 소속이므로, OSS 코드를 만든 사람이 직접 패치를 만든다.

지원 범위:

  • Spring Boot, Spring Framework, Spring Security, Spring Data 등 50개 이상 Spring 프로젝트
  • OpenJDK, Apache Tomcat, Apache HTTP Server까지 포함
  • 24/7 글로벌 기술 지원 (Broadcom 지식베이스, 전문가 직접 상담)

추가 기능:

  • Spring Enterprise Repository: OSS 종료 후 패치 버전을 별도 Maven 저장소로 제공
  • Application Advisor: Spring 앱의 의존성·소스코드·설정을 자동으로 업그레이드해주는 도구
  • Spring Health Assessment: 포트폴리오 전체의 의존성과 보안 이슈를 스캔

2.2 HeroDevs NES (Never-Ending Support) — 서드파티

Spring 오픈소스 커뮤니티 기여자들이 참여하는 서드파티 회사다. Spring 팀과는 별개 조직이지만, Spring 코드를 분석해서 자체적으로 보안 패치를 만들어 제공한다.

지원 범위:

  • Spring Boot 1.5부터 3.5까지 전 버전
  • Spring AI 1.0, 1.1 포함
  • Boot가 관리하는 전체 의존성 트리(Spring Security, Spring Data 등) 포함

추가 기능:

  • 드롭인 교체: 코드 변경 없이 Maven 저장소 URL만 바꾸면 패치된 라이브러리를 받을 수 있음
  • SLA 기반 인시던트 대응: SOC 2, FedRAMP, PCI, HIPAA 컴플라이언스 지원
  • 매출의 일부를 Spring 오픈소스 메인테이너에게 환원

📌 3. 가격

Tanzu Spring

공개 가격이 없다. 영업팀에 문의해야 견적을 받을 수 있다.

알려진 참고 정보:

  • Azure Spring Apps Enterprise 플랜 기준으로 vCPU당 시간당 $0.05의 Tanzu 라이선스 비용이 부과된다
  • 단독 구독(Tanzu Spring Runtime) 가격은 비공개이며, 앱 수·코어 수·지원 등급에 따라 달라진다
  • 업계 추정치로는 연간 수천만 원 ~ 수억 원 규모 (기업 규모에 따라 크게 차이)
  • Tanzu Application Service(Cloud Foundry 기반 PaaS) 사용 기업은 추가 비용 없이 포함

핵심: 개인 개발자나 소규모 팀이 접근할 수 있는 가격대가 아니다. 기업용 구독이다.

HeroDevs NES

역시 공개 가격이 없다. "Contact Sales"를 통해 맞춤 견적을 받아야 한다.

알려진 참고 정보:

  • 사용 중인 Spring 프로젝트 목록 기반으로 커스터마이징된 패키지를 제공한다
  • 불필요한 프로젝트를 제외하여 비용을 줄일 수 있다
  • Tanzu보다는 저렴하다는 것이 업계 평가이나, 구체적 금액은 비공개
  • AngularJS, Vue 2, Drupal 7 등 다른 EOL 프레임워크와 번들로 구매 가능

핵심: Tanzu보다는 접근성이 높지만, 역시 기업 대상이다. 개인 개발자에게는 현실적이지 않다.


📌 4. 지원 기간

제공자                                          Spring Boot 3.5 지원 기간
무료 OSS 2024.11 ~ 2026.06 (약 19개월)
Tanzu Spring 2026.07 ~ 최대 2031년 (메이저 마지막 마이너에 최대 5년 추가)
HeroDevs NES 2026.07 ~ 무기한 ("Never-Ending"이 이름인 이유)

Tanzu는 Spring Boot 3.5가 3.x 메이저의 마지막 마이너 버전이므로, 기존 OSS 지원 기간에 5년을 추가한 엔터프라이즈 지원을 제공한다. 즉 최대 2031년경까지 패치를 받을 수 있다.

HeroDevs는 이름 그대로 "끝나지 않는 지원"을 표방한다. Spring Boot 1.5(2019년 EOL)도 아직 지원하고 있으므로, 실질적으로 무기한이다.


📌 5. 보안 패치 적용 방식

두 제공자 모두 Maven/Gradle 저장소를 바꾸는 것이 핵심이다. 코드를 고칠 필요가 없다.

Tanzu Spring — Spring Enterprise Repository

EOL 이후 패치 버전은 Maven Central이 아닌 Tanzu 전용 저장소에 배포된다.

 
 
xml
<!-- build.gradle.kts 또는 pom.xml에 저장소 추가 -->
<repositories>
  <repository>
    <id>spring-enterprise</id>
    <url>https://repo.spring.io/enterprise</url>  <!-- Tanzu 구독 인증 필요 -->
  </repository>
</repositories>

Tanzu 구독 계정으로 인증하면, 3.5.14, 3.5.15 같은 패치 버전을 계속 받을 수 있다. 기존 코드의 spring-boot-starter-parent 버전만 올리면 된다.

 

HeroDevs NES — HeroDevs Registry

HeroDevs는 자체 Maven 저장소를 운영한다. NES 토큰으로 인증한다.

xml
<!-- Maven settings.xml -->
<servers>
  <server>
    <id>herodevs-nes-registry</id>
    <username>any_text_here_not_used</username>
    <password>YOUR_NES_ACCESS_TOKEN</password>
  </server>
</servers>

<!-- pom.xml -->
<repositories>
  <repository>
    <id>herodevs-nes-registry</id>
    <url>https://registry.nes.herodevs.com/maven</url>
  </repository>
</repositories>

<parent>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-parent</artifactId>
  <!-- 버전 형식: [마지막OSS]-spring-boot-[NES버전] -->
  <version>3.5.13-spring-boot-3.5.15</version>
</parent>

Gradle도 동일한 구조다:

 
 
groovy
// build.gradle
repositories {
  maven {
    url = uri("${herodevs_nes_registry_url}")
    credentials {
      username = "${herodevs_nes_registry_user}"
      password = "${herodevs_nes_registry_token}"
    }
  }
  mavenCentral()
}

plugins {
  id 'org.springframework.boot' version '3.5.13-spring-boot-3.5.15'
}

두 방식 모두 공통점: 기존 코드를 한 줄도 수정하지 않는다. 의존성을 받아오는 저장소만 바뀐다. CI/CD 파이프라인에서 인증만 설정하면 기존 빌드 프로세스 그대로 동작한다.


📌 6. 두 유료 지원의 차이 정리

비교 항목                            Tanzu Spring                                                         HeroDevs NES 
제공자 Broadcom/VMware (Spring 본가) 서드파티 (커뮤니티 기여자 기반)
패치 제작자 Spring 커미터 본인 HeroDevs 자체 보안팀
가격 비공개 (기업 영업) 비공개 (기업 영업, Tanzu보다 저렴 추정)
최소 규모 기업 단위 프로젝트 단위 커스터마이징 가능
지원 기간 최대 5년 추가 (3.5 기준 ~2031) 무기한
적용 방식 Spring Enterprise Repository HeroDevs Maven Registry
코드 변경 없음 (저장소 URL만 추가) 없음 (저장소 URL + 버전 형식 변경)
추가 기능 Application Advisor, Health Assessment SOC 2/FedRAMP/PCI/HIPAA SLA
Spring AI 지원 미확인 1.0, 1.1 명시적 지원
컴플라이언스 Broadcom 엔터프라이즈 인증 기반 SLA 기반 인시던트 대응

📌 7. 누구에게 어떤 선택이 맞는가

Boot 4로 마이그레이션 (무료)

  • 개인 개발자, 스타트업, 소규모 팀
  • 신규 프로젝트이거나 코드베이스가 작은 경우
  • 마이그레이션에 투입할 시간이 있는 경우

Tanzu Spring (유료 본가)

  • 대기업, 금융권, 공공기관
  • 수십~수백 개의 Spring 앱을 운영하는 조직
  • Spring 커미터의 직접 패치와 24/7 지원이 필요한 경우
  • 이미 Tanzu Application Service를 쓰고 있는 경우 (추가 비용 없음)

HeroDevs NES (유료 서드파티)

  • 중견 기업, Spring AI를 포함해 패치가 필요한 경우
  • Tanzu 구독보다 낮은 비용으로 보안 패치만 받고 싶은 경우
  • Boot 4 마이그레이션까지 시간을 벌기 위한 "브릿지" 용도
  • 다른 EOL 프레임워크(AngularJS, Vue 2 등)도 함께 지원받고 싶은 경우

📌 8. 실무자 관점의 핵심

유료 지원이 존재한다는 것 자체는 좋은 소식이다. 하지만 현실을 직시하면:

가격이 비공개라는 것은 비싸다는 뜻이다. "Contact Sales"를 거치는 B2B 구독은 개인이 결제할 수 있는 수준이 아니다. 개인 개발자나 소규모 팀에게 유료 지원은 사실상 선택지가 아니다.

결국 개인 개발자의 답은 하나다. Spring Boot 4로 올리는 것. 무료이고, Spring 팀이 활발하게 지원하는 버전이다.

유료 지원은 "Boot 4로 올리고 싶은데 당장 못 올리는 기업"을 위한 것이다. 수백 개의 마이크로서비스가 3.5에 묶여 있고, 마이그레이션에 6개월~1년이 걸리는 조직이 시간을 사는 용도다.


📌 9. 정리

질문                                                                                                    답
6월 이후 Spring Boot 3.5를 무료로 쓸 수 있나? 쓸 수 있다. 하지만 보안 패치가 없다.
유료로 쓰면 패치가 나오나? Tanzu 또는 HeroDevs 구독 시 계속 받는다.
얼마인가? 비공개. 기업 영업 기반이다.
코드를 고쳐야 하나? Maven 저장소 설정만 바꾸면 된다. 코드 변경 없다.
개인 개발자도 살 수 있나? 현실적으로 어렵다. Boot 4로 올리는 것이 답이다.
언제까지 지원되나? Tanzu는 ~2031년, HeroDevs는 무기한.

한 줄 요약 👉 Spring Boot 3.5 유료 지원은 **"기업이 마이그레이션 시간을 사는 보험"**이다. 개인 개발자에게 진짜 답은 Boot 4 마이그레이션이다.

LIST

📌 1. 무슨 일이 일어나는가

2026년 6월 30일, Spring Boot 3.5의 OSS(무료 오픈소스) 지원이 종료된다.

같은 날 Spring AI 1.0과 Spring AI 1.1도 함께 EOL에 진입한다. 이 날 이후로는 보안 패치, 버그 수정, 업데이트가 더 이상 제공되지 않는다.

"지원이 끝나도 돌아가는 데 문제없잖아?"라고 생각할 수 있다. 맞다. 코드는 그대로 돌아간다. 문제는 새로운 취약점이 발견됐을 때 패치가 오지 않는다는 것이다.


📌 2. 이론이 아니다 — 지난달 실제로 일어난 일

2026년 3월, Spring AI에서 고위험 CVE 2건이 동시에 공개됐다. 둘 다 CVSS 8점대의 심각한 취약점이다.

CVE-2026-22729 — JSONPath 인젝션 (CVSS 8.6)

Spring AI의 AbstractFilterExpressionConverter에서 발견됐다. 사용자 입력이 JSONPath 쿼리에 이스케이핑 없이 그대로 들어간다.

공격 시나리오:

// 정상적인 필터
metadata.department == "engineering"

// 공격자가 주입한 필터
metadata.department == "" || metadata.accessLevel == "admin"

|| 연산자가 JSONPath의 논리 OR로 해석되면서, 원래 접근할 수 없는 admin 레벨 문서까지 전부 조회된다. 멀티테넌트 격리나 역할 기반 접근 제어를 우회하는 공격이다.

영향 범위: PgVectorStore, OracleVectorStore 등 AbstractFilterExpressionConverter를 상속하는 모든 벡터 스토어. pgvector를 쓰고 있다면 직접 해당된다.

CVE-2026-22730 — SQL 인젝션 (CVSS 8.8)

MariaDBFilterExpressionConverter에서 입력 검증이 누락돼 있었다. 공격자가 임의의 SQL 명령을 실행할 수 있고, 데이터베이스의 기밀성·무결성·가용성 전부가 침해될 수 있다.

현재는 패치된 상태다

Spring AI 1.0.4, 1.1.3에서 두 CVE 모두 수정됐다. 지금 업데이트하면 문제없다.

진짜 문제는 6월 이후다. 이와 비슷한 수준의 CVE가 7월에 발견되면? Spring AI 1.x에는 패치가 오지 않는다. 상위 버전(Spring AI 2.0)에서만 수정된다. EOL 버전을 쓰는 팀은 스스로 코드를 분석하고 직접 패치하거나, 취약점을 안고 가거나, 둘 중 하나를 선택해야 한다.


📌 3. 업그레이드 경로가 꼬여 있다

자연스러운 마이그레이션 경로는 이렇다:

Spring Boot 3.5 + Spring AI 1.x (EOL: 2026.06)
        ↓
Spring Boot 4 + Spring AI 2.0 (현재 지원 중)

 

문제는 타이밍이다. Spring AI 2.0은 Spring Boot 4를 타겟으로 하며, 메이저 API 변경을 포함한다. 단순히 버전만 올리는 게 아니라, API 마이그레이션이 필요하다.

Spring Boot 3.5 EOL(6월)과 Spring AI 2.0 정식 출시 사이에 공백이 생길 수 있고, 이 기간에는 안전한 버전 조합이 존재하지 않는 상태가 된다.


📌 4. Spring Boot 3.5 EOL의 파급 범위

Spring Boot 3.5가 EOL이 되면, Boot가 관리하는 전체 의존성 트리가 함께 지원 종료된다.

구성 요소                                                                                                                     EOL 시점
Spring Boot 3.5 2026년 6월
Spring Framework 6.2 2026년 6월
Spring AI 1.0 / 1.1 2026년 6월
Spring Security (6.2 기반) 2026년 6월
Spring Data (6.2 기반) 2026년 6월

Boot 하나가 EOL이면, 그 위에 올라간 Spring Security, Spring Data, Spring AI가 전부 영향을 받는다. 의존성 하나하나가 아니라 생태계 단위로 지원이 끊긴다.


📌 5. 유료 지원이라는 선택지

Spring 팀은 이 상황을 알고 있고, 해법도 제시하고 있다.

Tanzu Spring (VMware 상용 지원): Spring Boot 3.5는 메이저 버전(3.x)의 마지막 마이너이므로, 상용 엔터프라이즈 지원을 통해 최대 5년 추가 지원을 받을 수 있다. 비용이 발생한다.

HeroDevs NES (Never-Ending Support): 서드파티 유료 지원으로, Spring Boot 3.5와 Spring AI 1.x에 대한 보안 패치를 EOL 이후에도 제공한다. 코드 변경 없이 드롭인 교체가 가능하다.

둘 다 기업용 선택지다. 개인 개발자나 소규모 팀에게는 사실상 "Boot 4 + Spring AI 2.0으로 올려라"가 유일한 답이다.


📌 6. 지금 할 수 있는 것

즉시 (지금)

  • Spring AI를 1.0.4 또는 1.1.3으로 업데이트해서 CVE-2026-22729, CVE-2026-22730을 패치한다
  • 프로젝트의 Spring Boot 버전과 Spring AI 버전을 확인한다

단기 (6월 전까지)

  • Spring Boot 4 마이그레이션을 시작한다. javax → jakarta 전환, deprecated API 정리가 핵심이다
  • Spring AI 2.0 GitHub 마일스톤을 추적한다. 출시되면 바로 마이그레이션할 준비를 해둔다
  • Boot 4에서 기존 코드의 호환성을 테스트한다

중기 (6월 이후)

  • Spring AI 2.0이 출시되면 마이그레이션을 실행한다. API 변경이 있으므로 테스트 기간을 확보해야 한다
  • Boot 4 + Spring AI 2.0 조합으로 전환을 완료한다

📌 7. 이미 Spring Boot 4를 쓰고 있다면

Spring Boot 4를 이미 채택한 프로젝트라면 Boot 자체의 EOL 문제는 없다. 하지만 Spring AI 부분은 별개다. Spring AI 1.x가 Boot 4에서 동작하더라도, Spring AI 자체의 지원은 6월에 종료된다.

결국 Spring AI 2.0이 나올 때까지는 1.x를 쓸 수밖에 없고, 2.0이 출시되면 API 마이그레이션이 필요하다. 이 부분의 일정 리스크를 프로젝트 계획에 반영해야 한다.


📌 8. 정리

Spring Boot 3.5 EOL은 단순한 버전 업데이트 문제가 아니다. Spring AI를 포함한 전체 Spring 생태계의 지원이 동시에 끊기는 이벤트다.

6월이 지나면 새로운 CVE에 대한 패치가 오지 않는다. 지난달 발견된 CVSS 8.6, 8.8 수준의 취약점이 7월에 발견된다면, EOL 버전에서는 직접 대응해야 한다.

준비할 시간은 약 2개월 남았다.

한 줄 요약 👉 Spring Boot 3.5 + Spring AI 1.x의 무료 보안 패치는 2026년 6월 30일에 끝난다. Boot 4 + Spring AI 2.0 마이그레이션을 지금 시작해야 한다.

LIST

📌 1. 왜 이 비교가 필요한가

서버를 외부에 공개할 때 가장 큰 고민은 **"인바운드 포트를 열지 않고 어떻게 서비스를 노출할 것인가"**다.

전통적인 포트포워딩 방식은 공유기에서 직접 포트를 열어야 하고, 서버 IP가 그대로 노출된다. 포트스캔 한 번이면 어떤 서비스가 돌아가는지 다 보인다.

이 문제를 해결하는 두 가지 접근이 있다:

  • Cloudflare Tunnel — Cloudflare 네트워크를 경유하는 관리형 터널
  • Pangolin — WireGuard 기반의 셀프 호스팅 터널 + 리버스 프록시 + 인증 통합 플랫폼

둘 다 "아웃바운드 전용 터널"이라는 동일한 원리를 사용하지만, 철학과 트레이드오프가 완전히 다르다.


📌 2. 공통점: 아웃바운드 전용 터널의 원리

두 솔루션 모두 같은 핵심 원리를 공유한다.

[서버] ---(아웃바운드 연결)---> [중계 서버] <--- [사용자 접속]

홈서버가 먼저 중계 서버에 연결을 맺는다. 인바운드 포트를 열 필요가 없다. 공유기 NAT 뒤에 있어도, CGNAT 환경이어도 동작한다.

보안 효과:

  • 서버의 공인 IP가 노출되지 않는다
  • 포트스캔에 아무것도 잡히지 않는다
  • 공격 표면(attack surface)이 중계 서버 한 곳으로 수렴한다

차이점은 **"그 중계 서버를 누가 운영하느냐"**다.


📌 3. Cloudflare Tunnel — 관리형 터널의 왕

✔ 구조

[사용자] → Cloudflare Edge(전 세계 300+개 PoP)
                ↓ (암호화된 터널)
         cloudflared (서버 데몬)
                ↓
         로컬 서비스 (localhost:3000 등)

서버에 cloudflared를 설치하면, Cloudflare Edge까지 아웃바운드 터널을 자동으로 맺는다. 사용자 트래픽은 Cloudflare → 터널 → 홈서버 순서로 흐른다.

✔ 강점

1) 인바운드 포트 제로

공유기에서 포트포워딩 설정이 아예 필요 없다. cloudflared가 아웃바운드로만 동작하기 때문에, 홈서버를 포트스캔해도 아무것도 나오지 않는다.

2) DDoS 방어 기본 포함

Cloudflare는 2025년 한 해 동안 4,710만 건의 DDoS 공격을 처리했다. 31.4Tbps 규모의 세계 최대 DDoS 공격도 자동 방어한 이력이 있다. 이 방어력이 무료 플랜에도 적용된다.

3) WAF (웹 방화벽) 기본 제공

SQL Injection, XSS, RCE 등 주요 웹 공격에 대한 관리형 룰셋이 무료로 포함된다. 2025년 12월 React Server Components의 CVSS 10.0 취약점(CVE-2025-55182)이 발견됐을 때도 공식 발표 전에 WAF 룰을 선배포했다.

4) Zero Trust Access

관리자 페이지 같은 민감한 경로에 이메일 인증, OTP, 소셜 로그인 기반 접근 제어를 걸 수 있다. VPN 없이도 특정 사용자만 접근 가능하게 만든다.

5) 무료

개인 사용 수준에서는 비용이 0원이다.

✔ 약점

1) TLS 종단(Termination) 구조

Cloudflare Tunnel은 end-to-end 암호화가 아니다. 트래픽이 Cloudflare 네트워크 내부를 지날 때 TLS를 벗기고, 캐싱/WAF 처리 후 다시 암호화한다. 즉, Cloudflare 내부에서는 평문 트래픽을 볼 수 있다.  홈서버 수준에서는 현실적 위험이 거의 없지만, 원리적으로 Cloudflare를 "신뢰"해야 하는 구조다.

2) 100MB 파일 크기 제한

Tunnel을 통해 전송하는 단일 파일에 100MB 제한이 있다. Immich 같은 사진 관리 앱에서 대용량 파일을 다룰 때 문제가 된다.

3) 영상 스트리밍 ToS 제한

Jellyfin, Plex 같은 미디어 서버의 영상 스트리밍은 Cloudflare ToS 위반 소지가 있다. 실제로 계정이 정지된 사례가 보고되어 있다.

4) 벤더 종속(Vendor Lock-in)

DNS, WAF, Access, Tunnel이 모두 Cloudflare 생태계 안에 묶인다. Cloudflare가 정책을 변경하거나 무료 플랜 기능을 축소하면 대응이 어렵다.


📌 4. Pangolin — 셀프 호스팅 터널의 신흥 강자

✔ 구조

[사용자] → Pangolin Server (내 VPS, 공인 IP)
                ↓ (WireGuard 터널)
         Newt 클라이언트 (서버 데몬)
                ↓
         로컬 서비스

VPS에 Pangolin 서버를 설치하고, 서버에는 Newt라는 경량 WireGuard 클라이언트를 돌린다. Cloudflare Tunnel과 동일한 "아웃바운드 전용" 패턴이지만, 중계 서버가 Cloudflare 대신 내 VPS다.

Pangolin은 Fossorial이라는 YC 2025 배치 회사가 개발했으며, GitHub 스타가 약 19,000개에 달하는 활발한 오픈소스 프로젝트다(AGPL-3.0 라이선스).

✔ 핵심 구성 요소

구성                요소                                       역할
Pangolin Server VPS에서 동작. 대시보드 UI, 인증/접근제어, 리소스 관리
Newt 홈서버에서 동작. 경량 WireGuard 클라이언트, 루트 불필요
Gerbil WireGuard 인터페이스 관리 서버 (Go로 작성)
Traefik 내장 리버스 프록시. 라우팅, SSL 인증서, 로드밸런싱

✔ 강점

1) 진짜 End-to-End 암호화

WireGuard 터널 위에서 트래픽이 흐르기 때문에 중간에 누구도 평문을 볼 수 없다. Cloudflare의 TLS 종단 이슈가 없다.

2) 파일 크기/스트리밍 제한 없음

100MB 제한도 없고, 영상 스트리밍 ToS 제한도 없다. Jellyfin, Immich 등을 자유롭게 운영할 수 있다.

3) 올인원 플랫폼

리버스 프록시(Traefik) + 터널(WireGuard) + 인증(SSO/OIDC) + 대시보드 UI가 하나의 패키지에 들어있다. Cloudflare Tunnel + Cloudflare Access를 합친 것과 동등한 기능을 셀프 호스팅으로 제공한다.

4) Zero Trust 접근 제어

리소스별로 세분화된 접근 정책을 설정할 수 있다. 전체 네트워크가 아닌 특정 앱에만 접근을 허용하는 구조다.

5) 완전한 인프라 통제

트래픽이 내 VPS만 경유한다. 제3자에게 트래픽을 맡기지 않는다. 정책 변경이나 서비스 종료 리스크가 없다.

✔ 약점

1) VPS 비용 발생

최소 월 $4~5의 VPS가 필요하다. RAM 1GB 이상, 포트 80/443/51820 개방이 필수다.

2) 공격 표면이 VPS로 이동

Cloudflare Tunnel은 Cloudflare의 수천 명 보안 엔지니어가 Edge를 방어한다. Pangolin은 내가 VPS 보안을 직접 책임져야 한다. DDoS 방어도 VPS 호스팅 업체 수준에 의존한다.

3) 운영 부담

Pangolin 서버 업데이트, Traefik 설정, WireGuard 관리, SSL 인증서 갱신 등을 직접 해야 한다. "설치하고 잊어버리는" 수준은 아니다.

4) DDoS 방어 없음

Cloudflare 같은 글로벌 엣지 네트워크가 없으므로, VPS에 직접 DDoS가 들어오면 호스팅 업체의 기본 방어에 의존해야 한다.


📌 5. 직접 비교표

항목                                             Cloudflare Tunnel                                                Pangolin
비용 무료 VPS 월 $4~5+
인바운드 포트 불필요 (0개) 서버: 불필요 / VPS: 80, 443, 51820
암호화 TLS 종단 (Cloudflare 내부 평문 가능) WireGuard E2E 암호화
DDoS 방어 엔터프라이즈급 자동 방어 없음 (VPS 호스팅 의존)
WAF 관리형 룰셋 포함 (무료) 없음 (직접 구성 필요)
파일 크기 제한 100MB 없음
영상 스트리밍 ToS 위반 소지 제한 없음
인증/접근제어 Cloudflare Access 내장 SSO/OIDC
관리 UI Cloudflare 대시보드 Pangolin 대시보드
벤더 종속 Cloudflare 생태계 종속 없음 (완전 셀프 호스팅)
운영 부담 거의 없음 중간 (VPS + 서버 관리)
트래픽 가시성 Cloudflare가 볼 수 있음 나만 볼 수 있음

📌 6. 어떤 상황에서 무엇을 선택할 것인가

✔ Cloudflare Tunnel이 맞는 경우

  • 웹 서비스(API, 웹앱) 위주 운영
  • DDoS 방어가 중요한 경우
  • 운영 부담을 최소화하고 싶은 경우
  • 비용 0원을 원하는 경우
  • 1인 운영자 (VPS 관리할 여력이 부족)

✔ Pangolin이 맞는 경우

  • Jellyfin, Plex 등 미디어 스트리밍 운영
  • 100MB 이상 파일 전송이 필요한 경우
  • Cloudflare에 트래픽을 맡기고 싶지 않은 경우
  • E2E 암호화가 필수인 경우
  • 인프라 전체를 직접 통제하고 싶은 경우

✔ 둘 다 쓰는 하이브리드 구성

실전에서는 둘을 병행할 수도 있다:

  • 웹 서비스 → Cloudflare Tunnel (DDoS 방어 + WAF 혜택)
  • 미디어 서버 → Pangolin (파일 크기 제한/ToS 회피)

📌 7. 보안 관점 정리

Cloudflare Tunnel의 공격 표면

공격자 → Cloudflare Edge → (여기서 방어) → 터널 → 홈서버

공격 표면이 Cloudflare Edge 한 곳이고, 그 방어를 Cloudflare가 담당한다. 2025년 10월 ACME 경로 우회 제로데이가 발견된 적이 있지만, 버그바운티를 통해 18일 만에 패치됐다. 완벽하지는 않지만, 개인이 직접 방어하는 것보다 압도적으로 강력하다.

단, Cloudflare를 "정상적으로 통과한" 트래픽은 그대로 서비스에 도달한다. 앱 레벨 취약점(SQL Injection, RCE 등)은 별도로 방어해야 한다. WAF가 기본적인 것은 잡아주지만, 우회 기법은 계속 나온다.

Pangolin의 공격 표면

공격자 → VPS (포트 80, 443, 51820) → WireGuard 터널 → 홈서버

공격 표면이 VPS의 열린 포트들이고, 그 방어를 내가 직접 담당한다. CrowdSec, fail2ban 등을 붙일 수 있지만, Cloudflare 수준의 DDoS 방어는 불가능하다.

대신 WireGuard E2E 암호화로 인해 터널 내부 트래픽은 누구도 볼 수 없다.


📌 8. 결론: 현실적 선택 기준

질문                                                                                                    Cloudflare Tunnel               Pangolin
미디어 스트리밍 하나요?
대용량 파일 다루나요?
DDoS 방어가 필요한가요?
VPS 관리할 여력이 있나요? 불필요 필수
비용에 민감한가요? ✔ (무료) ✗ (월 $4~5)
E2E 암호화가 필수인가요?

대부분의 1인 홈서버 운영자에게 Cloudflare Tunnel이 현실적 최선이다. 무료이고, DDoS 방어가 포함되고, 운영 부담이 거의 없다. "Cloudflare를 신뢰할 수 있느냐"가 유일한 질문인데, 전 세계 웹 트래픽의 20%를 처리하는 회사가 개인 홈서버 트래픽을 악용할 현실적 가능성은 없다.

Pangolin은 Cloudflare의 구조적 한계에 부딪힌 사람을 위한 선택지다. 미디어 스트리밍, 대용량 파일, 완전한 프라이버시가 필요하다면 Pangolin이 답이다. 단, VPS 보안을 직접 책임져야 한다는 트레이드오프를 받아들여야 한다.


한 줄 요약 👉 Cloudflare Tunnel = "맡기는 보안" (강력하지만 신뢰 기반) 👉 Pangolin = "내가 하는 보안" (자유롭지만 책임도 내 것)

LIST

2009년에 태어난 전자정부표준프레임워크(eGovFrame)는 17살이 되었다. Spring Boot 4가 Jakarta EE 11을 품고, React/Vue가 프론트엔드의 기본값이 된 2026년, 여전히 JSP와 MyBatis 위에서 돌아가는 공공 SI 현장은 어디로 향하고 있는가?


전자정부프레임워크, 지금 어디까지 왔나

전자정부표준프레임워크는 2009년 행정안전부 산하 한국정보화진흥원에서 처음 출시된 이래, 공공 정보화 사업의 사실상 필수 요건으로 자리잡았다. Spring 프레임워크 위에 MyBatis, Jackson, Apache Commons 등을 조합한 "2차 가공 프레임워크"로, 다양한 업체가 중구난방으로 쓰던 기술 스택을 통일하겠다는 취지였다.

2026년 4월 현재 최신 버전은 eGovFrame 4.3.0이다. 주요 변화를 정리하면 다음과 같다.

버전별 핵심 전환점:

  • v4.0 (2022.3): Spring 5 기반 전환, Boot-Template/MSA-Template 추가, Java 8 최소 요구
  • v4.2 (2024): 공통컴포넌트 251종, Eclipse 2022-12 적용
  • v4.3 (2025): Spring Boot 기반 Boot-Template·MSA-Template 업그레이드, Java Config 생성 기능 추가, 공통컴포넌트 254종, 보안 패치 강화

눈여겨볼 점은 MSA 템플릿의 공식 지원이다. eGovFrame GitHub에서 egovframe-msa-edu 저장소를 보면, Spring Cloud Gateway, Config Server, Service Discovery 기반의 마이크로서비스 아키텍처를 공식 교육 과정으로 제공하고 있다. 2026년 교육 과정도 초급/고급/심화로 개편되었다.

그러나 핵심적인 문제가 있다. eGovFrame 4.3은 Spring 5 / Spring Boot 2.x 기반이다. 2025년 11월에 Spring Boot 4가 GA 되었고, Spring Boot 3.5의 무료 지원도 2026년 6월에 종료된다. 업스트림이 두 세대나 앞서 나간 상황에서, eGovFrame의 다음 메이저 버전이 언제 나올지는 아직 공식 로드맵이 없다.


Spring Boot 4 시대, eGovFrame이 직면한 기술 격차

Spring 생태계는 2025~2026년에 걸쳐 세대교체를 완료했다. eGovFrame이 따라잡아야 할 격차를 구체적으로 보자.

javax → jakarta 패키지 전환

Spring Boot 3부터 javax.* 패키지가 jakarta.*로 전면 교체되었다. Spring Boot 4에서는 javax.servlet, javax.persistence 등이 완전히 제거되었다. eGovFrame의 254개 공통컴포넌트가 모두 이 전환을 거쳐야 한다는 뜻이다. 단순 find-replace가 아니라, 의존하는 서드파티 라이브러리 전체의 호환성을 검증해야 하는 작업이다.

Java 17 최소 기준선

Spring Boot 4의 최소 Java 버전은 17이다. Java 25까지 공식 지원한다. 반면 eGovFrame은 여전히 Java 8을 기준선으로 잡고 있다. 공공기관의 운영 환경이 Java 8에 머물러 있는 현실과, 최신 프레임워크가 요구하는 기준선 사이의 간극이 점점 벌어지고 있다.

Hibernate ORM 7.1 / Jakarta Persistence 3.2

Spring Boot 4는 Hibernate ORM 7.1을 탑재했다. detached entity의 재연결(reassociation) 방식이 변경되는 등 JPA 사용 패턴 자체가 달라졌다. eGovFrame은 여전히 MyBatis 중심인데, JPA/Hibernate를 함께 지원하는 공통컴포넌트가 이 변화를 수용하려면 상당한 리팩토링이 필요하다.

JSpecify Null Safety

Spring Framework 7은 JSpecify 어노테이션을 포트폴리오 전체에 적용해 컴파일 타임 null 안전성을 제공한다. Kotlin 2.2와도 자동 연동된다. 이건 eGovFrame이 직접 대응할 영역은 아니지만, Spring 생태계 전반의 코드 품질 기준이 올라갔다는 신호다.


JSP의 운명: 죽지 않았지만, 이미 퇴장 중

기술적 현실

JSP(JavaServer Pages) 자체가 "deprecated"로 선언된 적은 없다. Jakarta Server Pages는 Jakarta EE 11에도 여전히 포함되어 있다. 하지만 사실상(de facto) 퇴장이 진행 중이다.

Spring Boot에서 JSP의 위치:

  • Spring Boot는 초기부터 JSP 대신 Thymeleaf를 권장해왔다
  • 내장 톰캣에서 JSP를 쓰려면 별도 의존성(tomcat-embed-jasper)과 WAR 패키징이 필요하다
  • Spring Boot의 fat-jar 배포 모델과 JSP는 구조적으로 궁합이 맞지 않는다
  • Spring Boot 4에서 JSP가 제거된 것은 아니지만, 공식 문서와 예제에서 JSP는 사실상 언급되지 않는다

프론트엔드 패러다임의 전환:

2026년의 웹 개발은 백엔드와 프론트엔드의 분리가 기본값이다. 서버가 JSON API만 제공하고, 프론트엔드는 React/Vue/Next.js 등의 SPA(또는 SSR) 프레임워크가 담당한다. JSP는 서버에서 HTML을 생성하는 SSR(Server Side Rendering) 방식인데, 이 모델은 다음과 같은 한계를 갖는다.

  • 모바일 앱이나 외부 연동을 위해 별도 API를 다시 만들어야 한다
  • 프론트엔드 개발자와 백엔드 개발자의 역할 분리가 어렵다
  • 컴포넌트 재사용, 상태 관리, 라우팅 등 현대 UX 요구사항을 충족하기 어렵다
  • CDN 캐싱, 정적 배포 등 성능 최적화 전략을 적용하기 어렵다

한국 SI 현장의 현실

그럼에도 JSP는 한국 SI 현장에서 아직 살아 있다. 이유는 기술적이 아니라 구조적이다.

발주처가 eGovFrame을 요구한다. 공공기관 정보화 사업의 RFP(제안요청서)에 "전자정부표준프레임워크 적용"이 명시되어 있으면, 수주 업체는 eGovFrame을 써야 한다. 그리고 eGovFrame의 공통컴포넌트 상당수가 JSP 기반 뷰를 포함하고 있다.

기존 시스템이 JSP로 되어 있다. 유지보수 사업에서 "기존 시스템과 동일한 기술 스택"은 암묵적 요구사항이다. JSP로 만들어진 시스템의 유지보수를 React로 하겠다고 제안하면, 발주처 입장에서는 리스크다.

개발 인력 수급 문제. 하청-재하청 구조에서 투입되는 개발자의 다수가 JSP + jQuery + MyBatis 스택에 익숙하다. 새로운 기술 스택으로의 전환은 재교육 비용과 일정 리스크를 수반하며, 이를 감당할 여유가 SI 프로젝트 구조에는 거의 없다.


eGovFrame의 MSA 템플릿: 변화의 조짐

eGovFrame 4.x에서 가장 주목할 변화는 MSA 템플릿의 공식화다. egovframe-msa-edu 저장소를 보면, 프론트엔드가 React 기반으로 분리되어 있다. 백엔드는 Spring Cloud 기반 마이크로서비스, 프론트엔드는 SPA로 구성되는 구조다.

이것은 eGovFrame 진영에서도 "JSP 중심의 모놀리식 구조"가 더 이상 유일한 선택지가 아님을 공식적으로 인정한 것이다. 2025년 11월 128차 세미나에서는 K-PaaS(구 PaaS-TA)와의 연계, 카카오클라우드 콜라보가 진행되었고, MSA 포함 템플릿 프로젝트 컨트리뷰션 실습까지 다루었다.

다만, 이 MSA 템플릿이 실제 공공 SI 사업에서 채택되는 비율은 아직 극히 낮다. 대부분의 중소규모 공공 사업은 여전히 모놀리식 + JSP + MyBatis 조합이다. MSA 템플릿은 "대규모 클라우드 네이티브 사업"을 위한 선택지로 제시되고 있을 뿐, 표준 선택지를 대체하지는 못하고 있다.


5년 후를 내다본 예측

eGovFrame 5.0은 올 것인가?

Spring Boot 3.5의 무료 지원이 2026년 6월에 종료된다. eGovFrame이 Spring 5 기반에 머물러 있으면, 보안 패치를 받지 못하는 구간이 점점 늘어난다. eGovFrame 5.0(또는 그에 준하는 메이저 업데이트)이 Spring Boot 3.x 이상, Jakarta EE 10+ 기반으로 나오는 것은 시간문제다. 다만, 254개 공통컴포넌트의 javax → jakarta 전환과 호환성 테스트를 고려하면, 2027년 이전에 나오기는 쉽지 않을 것이다.

JSP는 언제 사라지는가?

JSP는 "특정 시점에 사라지는" 기술이 아니다. 마치 COBOL처럼, 새로운 프로젝트에서는 선택되지 않지만, 기존 시스템에서는 수십 년간 유지되는 기술이 될 가능성이 높다.

구체적으로 예측하면:

  • 신규 공공 SI 사업: 2028년경이면 RFP에 "SPA 프론트엔드 + REST API 백엔드" 구조가 보편화될 것이다. eGovFrame의 MSA 템플릿이 그 교두보 역할을 하고 있다.
  • 기존 시스템 유지보수: JSP 기반 시스템은 2030년대 중반까지도 운영될 것이다. 이 시스템들의 유지보수 인력 수요는 감소하겠지만, 완전히 사라지지는 않는다.
  • 개발자 커리어: "JSP만 할 줄 아는 개발자"의 시장 가치는 이미 하락세에 있다. React/Vue + Spring Boot(API 서버) 조합을 기본으로 갖추지 않으면, SI에서도 점점 입지가 좁아진다.

Thymeleaf은 대안인가?

JSP의 "바로 다음 세대" SSR 기술로 Thymeleaf이 자주 거론된다. Spring Boot가 공식 권장하는 템플릿 엔진이기도 하다. Thymeleaf은 순수 HTML로도 브라우저에서 미리보기가 가능해 퍼블리셔와의 협업이 수월하고, Spring Boot의 fat-jar 배포와도 잘 맞는다.

하지만 Thymeleaf도 결국 SSR이다. API 서버 + SPA 구조가 대세인 상황에서, Thymeleaf은 "가벼운 관리자 페이지"나 "내부 백오피스" 수준에서 선택되는 기술이지, 대규모 공공 서비스의 메인 뷰 기술로 자리잡기는 어렵다.


SI 개발자를 위한 현실적 제언

지금 당장

  • Spring Boot 3.x → 4.x 전환의 핵심 포인트(javax→jakarta, Hibernate 6→7, Jackson 2→3)를 파악해두자. eGovFrame이 언제 따라오든, Spring 생태계의 방향 자체는 변하지 않는다.
  • React 또는 Vue 기본기를 익혀두자. 프론트엔드 전문가가 될 필요는 없지만, REST API를 설계하고 SPA와 연동하는 구조를 이해하는 것은 백엔드 개발자에게도 필수다.

중기적으로

  • eGovFrame MSA 템플릿을 직접 돌려보자. GitHub에 교육 소스가 공개되어 있다. Spring Cloud Gateway, Config Server, Service Discovery 구조를 eGovFrame 맥락에서 경험해두면, 향후 클라우드 네이티브 공공 사업에서 경쟁력이 된다.
  • K-PaaS(구 PaaS-TA) 생태계를 주시하자. 정부의 클라우드 전환 정책과 맞물려, 컨테이너 기반 배포가 공공 SI에도 점진적으로 확산되고 있다.

장기적으로

  • JSP + MyBatis + eGovFrame만으로는 개발자 커리어가 정체된다. 서비스 회사든 SI든, 도메인 이해력 + 현대적 아키텍처 설계 능력이 차별화 요소가 되는 시대다.
  • AI 코딩 도구(Claude Code, GitHub Copilot 등)가 보일러플레이트 코드 생성을 대체하고 있다. 개발자의 가치는 "코드를 치는 속도"가 아니라 "무엇을 만들어야 하는지 판단하는 능력"에 있다.

마무리

전자정부프레임워크는 죽지 않는다. MSA 템플릿, 클라우드 네이티브 교육 과정, K-PaaS 연계 등 변화의 조짐은 분명히 있다. 하지만 그 변화 속도가 Spring 생태계의 발전 속도를 따라잡기에는 구조적으로 느리다.

JSP도 죽지 않는다. 다만, 새로운 가치를 창출하는 기술로서의 수명은 이미 다했다. 유지보수 기술로서의 수명만 남아 있다.

결국 개발자 개인의 선택이 중요하다. eGovFrame이 바뀌길 기다리기보다, Spring Boot 4 + SPA + 클라우드 네이티브라는 업스트림의 방향에 먼저 올라타는 것이 현실적인 전략이다. eGovFrame은 결국 그 방향으로 따라올 수밖에 없으니까.

LIST

자 분산 시스템 기반 대규모 트래픽처리를 하는데... 

보통 MAU가 얼마나 회사마다 나오는지 봤다.

named 회사는 1000만이 넘는것 같다.

잘 체감이 안되는 숫자다.

 

 

 

사실 사용자가 많지 않으면 캐시나.. 이런게 필요한다.

자 로그인한 사용자의 맞춤정보를 제공한다.

 

이커머스까지 가도 커머스에서 컬리나, 11번가 이런데서 대량 200만~800만 정도 된다.

 

나는 10~50만 정도되는 사이트까지만 다루어봤다.

 

자 10만정도 되면 redis는 필수란다. 천명 정도까지도 사실상 있으면 좋은정도다.

 

 

세션 클러스터링 개념은 1000명 정도에서도 필수라고 하니 사실상, 세션클러스터링을 deep하게 알고 , redis는  그 이상을 다룰때를 대비해서 공부한다고 생각해야 한다는 것을 알았다.

 

그리고 만명정도  부터 캐시가 좋고 , 10만 부터 캐시는 필수... 천명정도에서는 캐시 별 필요없었다..

 

 

사용자 인증 기능 구현 : 로그인한 사용자를 식별하여 맞춤 정보를 제공하는 시스템

- 안전하고 효율적인 로그인 인증 메커니즘을 스프링의 세션 기반 인증부터 시작하여 Redis 기반 세션으로 개선하는 과정

- 인증된 사용자의 고유성을 활용하여 장바구니와 같은 사용자별 데이터를 다루는 핵심 기술 역량

 

 

1일차. HTTP Session과 Session Clustering

 

1. Sticky Session( 소규모, 서버 2-3대 ), Session Replication( 중규모, 장애 허용 필요 , 노드 5개이하), Centralized Session Store( 대규모, MSA, K8s ) 와 같은 세션 클러스터링 전략

2. 단일 서버와 분산 서버 환경에서 세션 데이터 관리의 차이점

3. Redis를 활용하여 세션 데이터를 중앙에서 관리하고, 로드 밸런싱 환경에서 세션 공유를 구현하는 방법

트랜잭션과 인덱스 설계 학습

 

2일차. 인메모리 저장소 및 Redis 데이터 타입 활용

1. 초고속 데이터 액세스를 위한 인메모리 저장소의 원리를 이해하고, 문자열(String), 리스트(List), 집합(Set), 해시(Hash), 정렬된 집합(Sorted Set) 등 Redis의 5가지 핵심 데이터 타입의 구조와 특성

2. 데이터 입력, 조회, 삭제 및 만료 설정과 같은 기본 명령어를 실습하는 동시에, KEYS, FLUSHALL 등의 관리 명령어 사용법

 

  • 캐싱: 자주 찾아보는 데이터를 메모리에 미리 저장해두면, 웹사이트나 앱이 훨씬 빠르게 반응할 수 있어요.
  • 세션 관리: 사용자가 로그인했을 때의 정보나 장바구니 내용 같은 세션 데이터를 메모리에 저장해서 빠르게 처리할 수 있죠.
  • 실시간 데이터 처리: 주식 시세, 게임 랭킹, 실시간 알림처럼 순식간에 변하는 데이터를 바로바로 분석하고 처리하는 데 아주 유용해요.

 

주요 인메모리 저장소 시스템

1. Redis

Redis는 다양한 데이터 타입을 지원하는 오픈소스 인메모리 데이터 저장소예요. 단순히 키(Key)와 값(Value)만 저장하는 것을 넘어, 리스트, 해시, 집합 등 여러 가지 형태로 데이터를 저장하고 다룰 수 있는 만능 재주꾼이죠.

Sorted Set (정렬된 집합)

특징:

  • 값(Value)과 함께 숫자 형태의 점수(Score)를 저장하는 데이터 구조예요.
  • 저장된 요소들은 이 점수를 기준으로 항상 오름차순 또는 내림차순으로 자동 정렬돼요.
  • 중복된 값은 허용하지 않지만, 중복된 점수는 허용해요. (점수가 같으면 값이 사전식으로 정렬)
  • 특정 점수 범위나 순위 범위에 해당하는 데이터를 효율적으로 조회할 수 있어요.

주요 용도:

  • 순위 관리 (리더보드): 게임 점수, 사용자 랭킹, 인기 게시글 순위 등 점수를 기반으로 순위를 매겨야 하는 시스템에 가장 이상적이에요.
  • 시간 기준 정렬 데이터 관리: 이벤트 발생 시간, 메시지 전송 시간 등을 점수로 사용하여 시간 순서대로 데이터를 정렬하고 조회할 때 활용돼요.

 

 

2. Memcached

Memcached단순한 키-값 형태의 데이터를 저장하는 데 특화된 가볍고 빠른 분산 캐싱 시스템이에요. 복잡한 기능보다는 메모리 효율성과 순수한 성능에 집중한 녀석이죠.

 

 

3일차. Redis 캐싱 전략 실습

1. 캐싱(Caching)의 기본 원리를 이해하고, 시스템 성능을 극대화하는 다양한 캐싱 전략을 심층적으로 다룹니다

Cache-aside (캐시-어사이드)는 가장 널리 사용되고 직관적인 캐싱 패턴이에요. 애플리케이션 코드가 캐시와 데이터베이스 사이에서 데이터를 직접 관리하는 방식이죠.

 

Write-through (라이트-스루)는 데이터를 변경할 때 캐시와 원본 데이터 소스(데이터베이스)에 동시에 데이터를 기록하는 패턴이에요. 캐시와 데이터베이스 간의 강력한 데이터 일관성을 보장하는 데 중점을 둡니다.( 데이터 일관성이 매우 중요한 시스템)

Write-back (라이트-백)은 데이터를 변경할 때 일단 캐시에만 빠르게 데이터를 저장하고, 원본 데이터 소스(데이터베이스)는 나중에 비동기적으로 업데이트하는 패턴이에요. 쓰기 성능을 극대화하는 데 초점을 맞춥니다. ( 쓰기 빈도가 매우 높고 실시간으로 데이터 손실이 조금 발생해도 무방한 시스템)

Write-around (라이트-어라운드)는 데이터를 변경할 때 캐시를 완전히 우회하여 오직 원본 데이터 소스(데이터베이스)에만 데이터를 저장하는 패턴이에요. 캐시는 오로지 읽기 성능 향상에만 기여하고 쓰기 작업에는 관여하지 않습니다. ( 쓰기 요청은 많지만, 해당 데이터를 즉시 읽어올 필요는 적은 시스템)

 

Redis 명령어:

  • SET key value EX seconds: key를 value로 설정하면서 seconds초 후에 자동으로 만료되도록 설정합니다.
  • SETEX key seconds value 와 동일한 역할을 하는 약어 명령어입니다.
  • EXPIRE key seconds : 이미 존재하는keyseconds 초의 만료 시간을 설정합니다.

 

LRU (Least Recently Used) 및 LFU (Least Frequently Used) 정책

1.  Redis는 인메모리 저장소이므로, maxmemory설정으로 지정된 최대 메모리 용량에 도달했을 때 추가적인 데이터를 저장하려면 기존의 일부 데이터를 삭제(Eviction)해야 합니다.

 

 

LRU (Least Recently Used) 정책:

  • 설명: 가장 오랫동안 사용되지 않은(참조되지 않은) 데이터를 우선적으로 제거하는 정책이에요. 최근에 사용된 데이터는 다시 사용될 가능성이 높다는 가설에 기반합니다.

LFU (Least Frequently Used) 정책:

  • 설명: 사용 빈도(참조 횟수)가 가장 낮은 데이터를 우선적으로 제거하는 정책이에요. 오랫동안 사용되지 않았어도 자주 사용되는 데이터라면 유지하고, 최근에 사용되었더라도 사용 빈도가 낮으면 제거합니다.

 

4일차. Redis 세션 기반 사용자 인증 실습

1.  스프링 시큐리티(Spring Security), 스프링 세션(Spring Session), 그리고 레디스(Redis)를 활용해 REST API의 인증 시스템을 구축하는 방법

2. 스프링 시큐리티를 사용해 REST API의 인증 및 권한 부여를 구현하고, 스프링 세션과 레디스를 연동하여 세션 정보를 외부화하며, 다중 서버 환경에서 세션을 공유하는 원리를 이해

 

인메모리 저장소 데이터 영속성 문제

스프링 세션 (Spring Session),  HTTP Basic 인증 ....

 

 

쭈욱 배우다가.. .이게 적어도 만명이상에서 부터 효용성이 발휘된다고 하니.. 부하테스트를 직접 해봐야 하는 생각이든다.

 

 

 

 

LIST

먼저, 가장 중요한 것은 지연이 실제로 발생하고 있다는 객관적인 수치를 확보한 뒤, 이를 기반으로 백엔드 개발자와 커뮤니케이션하는 것입니다. 예를 들어, DevTools의 Network 탭에서 API 응답 시간 데이터를 수집하거나, Sentry 또는 Datadog과 같은 모니터링 도구를 통해 성능 데이터를 정리하여 공유할 수 있습니다. 이렇게 수치 기반으로 소통하여 단순히 “느리다”는 피드백이 아니라 “특정 API가 평균 3초 이상 소요된다”는 식의 구체적인 요청을 전달하여 백엔드 API의 성능 개선이 필요하다는 점을 설득할 것입니다.

하지만 현실적으로 백엔드 API의 성능이 단기간에 개선되기 어려운 상황도 존재합니다. 이럴 경우, 프론트엔드 단에서 사용성을 유지할 수 있는 다양한 전략을 적용할 것입니다.

가장 기본적인 대응은 로딩 상태를 사용자에게 명확하게 전달하는 것입니다. 예를 들어, 로딩 스피너나 Skeleton UI를 사용하여 시스템이 응답 중임을 사용자에게 알려줌으로써 ‘멈춘 것 같다’는 인상을 방지하고 체감 대기 시간을 줄일 것입니다.

또한, prefetch 전략을 고려해볼 것입니다. 사용자가 특정 페이지나 기능을 요청하기 전에 필요한 데이터를 미리 받아놓아 응답 지연 시간을 최대한 줄이기 위해 노력할 것입니다. 예를 들어, 사용자가 마우스를 올렸을 때 해당 페이지 데이터를 백그라운드에서 가져오거나, 이전 페이지에서 다음 페이지에 필요한 데이터를 미리 요청해두는 방식으로 prefetch를 수행할 수 있습니다.

이와 함께, 이미 받아온 API 응답을 캐싱하여 재사용하는 전략도 고려할 수 있습니다. 예를 들어, React Query나 SWR과 같은 라이브러리를 사용하면 API 응답을 캐시하여 재사용할 수 있습니다. 이를 통해 동일한 요청을 수 초 내에 다시 수행할 경우에 서버에 재요청하지 않고 캐시된 데이터를 빠르게 제공할 수 있습니다.

LIST

① 추론(Inference): "체급의 한계를 넘다"

  • GPU Offloading (GGUF): Ollamallama.cpp를 쓰면 모델의 레이어를 GPU와 RAM에 나눠서 올릴 수 있습니다.
    • Gemma 4 9B / Llama 3.1 8B: 전체 레이어를 3070에 다 올려서 초당 30~50토큰의 광속 추론이 가능합니다.
    • Gemma 4 31B / Llama 3.1 70B: VRAM 8GB에는 핵심 레이어 일부(약 10~20개)만 올리고, 나머지는 64GB RAM에 올립니다. 속도는 초당 1~3토큰으로 느려지지만, **"실제로 돌아가며 결과물을 낸다"**는 것이 중요합니다.
  • 연구 가치: "내 컴퓨터에서 70B 모델의 추론 결과를 직접 확인하고 비즈니스 로직 검증이 가능하다"는 

② 파인튜닝(Fine-tuning): "메모리 부족(OOM)의 해결사"

  • Swap Memory 활용: 파인튜닝 시 GPU 메모리가 꽉 차면 시스템이 뻗어버리는데, 64GB의 넉넉한 RAM은 데이터 전처리나 임시 체크포인트 저장 시 버퍼 역할을 톡톡히 합니다.
  • Unsloth 최적화: Unsloth 라이브러리는 3070(8GB)에서도 Gemma 4 E2B/E4B 모델의 파인튜닝을 지원합니다. 이때 64GB RAM은 대규모 데이터셋을 메모리에 미리 로드(Pre-fetching)해 두어 학습 병목 현상을 줄여줍니다.

3. Gemma 4 vs Llama 상세 비교 (3070 + 64GB 환경)

구분 Gemma 4 (9B/31B) Llama 3.1 (8B/70B)
8GB VRAM 활용 9B 모델은 Full GPU 가속 최적화. 8B 모델은 가장 안정적이고 빠름.
64GB RAM 활용 31B 모델 하이브리드 구동 (권장). 70B 모델 하이브리드 구동 (약간 느림).
특이점 멀티모달(이미지/음성) 처리 시 RAM 사용 효율 우수. 거대 컨텍스트 처리 시 RAM 64GB가 큰 도움.
LIST

2026년 현재 SI(System Integration) 현장에서 가장 뜨거운 감자인 **Gemma 4(Gemini 계열)**와 Claude 4.6(Sonnet/Opus) 모델을 개발자 관점에서 비교해 드릴게요.

SI 프로젝트는 복잡한 레거시 코드 분석, 대규모 문서 작성, 그리고 빠른 반복 개발이 핵심이죠. 이 기준에 맞춰 두 모델의 성능과 활용법을 정리했습니다.


1. 모델별 성능 비교 (개발자 체감 기준)

구분 Gemma 4 (Gemini 3/4 기반) Claude 4.6 Sonnet Claude 4.6 Opus
코딩 스타일 효율적이고 최적화된 로직 제안 가장 인간적이고 읽기 좋은 코드 매우 복잡하고 정교한 아키텍처 설계
컨텍스트 창 압도적 (1M~2M+ 토큰) 200K (일반) / 1M (특수) 1M 토큰 이상
강점 방대한 레거시 분석, 로그 분석 실제 돌아가는 코드 구현력(Zero-shot) 논리적 추론, 복잡한 에러 디버깅
속도 매우 빠름 (Flash 모델 병행 시) 빠르고 일관성 있음 약간 느리지만 매우 신중함
특이사항 Google 워크스페이스 연동 최상 Claude Code(CLI)와의 연합 ARC AGI 2 벤치마크 최고점

2. SI 현장 상황별 "필승" 활용법

① "이거 누가 짰어?" - 레거시 분석 및 마이그레이션 (Gemini/Gemma 승)

SI 현장에서는 수백 개의 Java 파일이나 SQL 쿼리를 분석해야 할 때가 많습니다.

  • 활용법: 프로젝트 전체 소스 코드를 압축해서 Gemma 4에 던지세요. 200만 토큰에 달하는 컨텍스트 창 덕분에 파일 간의 참조 관계를 놓치지 않고 분석합니다.
  • 추천 작업: "이 전체 프로젝트에서 공통 DB Connection 로직이 어디에 있는지 찾고, Spring Boot 3.x 스타일로 한꺼번에 변경해 줘."

② "당장 화면 띄워야 해요" - 신규 기능 구현 (Claude 4.6 Sonnet 승)

프론트엔드 UI 컴포넌트나 복잡한 비즈니스 로직을 즉석에서 짜야 할 때입니다.

  • 활용법: Claude 4.6 Sonnet은 '작동하는 코드'를 만드는 능력이 가장 뛰어납니다. 특히 **Claude Code(CLI)**를 쓰면 터미널에서 바로 코드를 수정하고 테스트까지 돌릴 수 있습니다.
  • 추천 작업: "React와 Query를 써서 이 API 명세서대로 데이터 그리드 화면을 만들어줘. 에러 핸들링 포함해서."

③ "설계서랑 산출물은요?" - 문서화 및 아키텍처 설계 (Claude 4.6 Opus 승)

기술 설계서(TDD), 상세 설계서 등 까다로운 문서 작업이 필요할 때입니다.

  • 활용법: Opus 4.6은 추론 능력이 가장 깊습니다. 단순 코딩을 넘어 시스템의 안정성이나 보안 취약점을 고려한 설계를 제안합니다.
  • 추천 작업: "이 시스템의 트래픽이 10배 늘어날 경우 발생할 수 있는 병목 지점을 찾고, 인프라 개선안을 포함한 기술 설계서를 작성해 줘."

3. SI 개발자를 위한 꿀팁

  1. 멀티 모델 전략: * 분석은 Gemini: 프로젝트 전체 파악 및 대용량 로그 분석용.
    • 구현은 Claude: 실제 코드 작성 및 리팩토링용.
  2. MCP(Model Context Protocol) 활용: Claude를 쓰신다면 MCP를 통해 로컬 DB나 IDE와 직접 연결하세요. 컨텍스트를 복사/붙여넣기 하는 시간을 획기적으로 줄여줍니다.
  3. Google Ecosystem: 만약 프로젝트에서 Google Cloud(GCP)나 Firebase를 사용 중이라면, Gemma 4의 API 연동 기능이 압도적으로 편리합니다.

결론적으로, "양으로 승부하는 분석"은 Gemma/Gemini를, "질로 승부하는 코딩"은 Claude를 추천드립니다. 르무엘님의 현재 프로젝트 상황은 대규모 분석 쪽인가요, 아니면 신규 개발 쪽인가요?

 

 

온프레미스 환경 로컬에서 Gemma4 가 좋은점?

 

 

1. 비용 및 제약 없는 '무제한' 연구

  • 비용 0원: Claude 4.6 API를 연구용으로 계속 호출하면 금방 수백 달러가 깨지지만, Gemma는 서버 자원(GPU)만 있다면 전기세 외에 추가 비용이 없습니다.
  • 사용 제한(Quota) 없음: 클로드는 유료 결제를 해도 시간당 질문 횟수 제한이 걸리지만, 로컬 Gemma는 24시간 내내 풀가동해도 상관없습니다.

2. 데이터 보안 및 프라이버시 (연구 데이터 보호)

  • Local Execution: 비영리 연구 데이터, 특히 민감한 내부 로직이나 미공개 데이터를 외부 서버(Anthropic 등)로 전송할 필요가 없습니다.
  • 폐쇄망 운영 가능: 외부 인터넷 연결 없이 우분투 서버 내에서만 모델을 돌릴 수 있어 보안이 중요한 연구에 필수적입니다.

3. 파인튜닝(Fine-tuning) 및 커스터마이징

  • 도메인 특화: SI 현장의 특정 프레임워크나 특정 도메인 데이터를 Gemma에 학습시켜 '나만의 모델'로 만들 수 있습니다. (클로드는 가중치 접근이 불가능합니다.)
  • 시스템 프롬프트 제어: 모델의 응답 방식이나 파라미터($Temperature$, $Top-P$ 등)를 코드 레벨에서 완전히 제어할 수 있습니다.

4. 우분투 서버에서의 추천 구동 방식

우분투 환경이라면 다음 도구들을 활용해 보세요. 르무엘님처럼 개발 경험이 풍부하시다면 5분 안에 띄울 수 있습니다.

  • Ollama (가장 추천): ```bashollama run gemma4 # 또는 최신 버전명
    가장 가볍고 CLI 환경에서 테스트하기 최적입니다.
    
  • curl -fsSL https://ollama.com/install.sh | sh
  • vLLM: 실제 연구용 API 서버를 구축하고 싶다면 성능(Throughput)이 가장 좋은 vLLM을 추천합니다. Python 환경에서 고성능 추론이 가능합니다.
  • LM Studio (Headless): GUI가 없는 서버라면 CLI 버전으로 띄워 로컬 REST API 서버로 활용할 수 있습니다.

5. 주의할 점 (하드웨어 사양)

Gemma 4는 모델 크기에 따라 요구 사양이 다릅니다.

  • 9B 모델: 일반적인 연구용으로 적합하며, VRAM 8GB~12GB 정도면 충분히 돌아갑니다.
  • 27B 이상 모델: 더 정교한 추론이 필요하지만 VRAM 24GB(RTX 3090/4090급) 이상이 권장됩니다.

요약하자면:

현시점에서 "비영리 + 연구 + 우분투 서버" 조합이라면 고민할 것 없이 Gemma입니다. 클로드는 연구 결과를 바탕으로 실제 서비스를 배포할 때 API로 연동하는 '최종 병기' 정도로 생각하시면 좋습니다.

LIST

OSIV(open session in view) 는 영속성 컨텍스트를 뷰까지 열어둔다는 의미입니다. 영속성 컨텍스트가 살아있으면 엔티티는 영속 상태로 유지될 수 있어, 뷰에서도 지연 로딩을 사용할 수 있어요. OSIV의 핵심은 뷰에서도 지연 로딩이 가능하도록 하는 것입니다. 가장 단순한 구현은 클라이언트 요청이 들어올때 필터나 인터셉터에서 트랜잭션을 시작하는 방법인데요. 이를 트랜잭션 방식 OSIV라고 합니다. 하지만, 트랜잭션 방식 OSIV는 표현 계층에서도 엔티티를 수정할 수 있기 때문에 유지보수하기 어려운 코드를 만들 수 있습니다.

트랜잭션 방식의 OSIV의 문제는 어떻게 풀어볼 수 있을까요? 🤔

최신 방식의 OSIV는 트랜잭션 방식의 문제를 해결합니다. 스프링 OSIV는 OSIV를 사용하면서 트랜잭션은 비즈니스 계층에서만 사용해요. 표현 계층에서는 트랜잭션이 없기 때문에 수정이 불가능합니다. 하지만, 표현 계층에서 트랜잭션 없는 읽기를 이용해 지연 로딩은 가능합니다. 동작 원리는 다음과 같습니다.

  1. 클라이언트의 요청이 들어오면 서블릿 필터나 스프링 인터셉터에서 영속성 컨텍스트를 생성합니다.
  2. 응용 계층에서 @Transactional로 트랜잭션을 시작할 때 미리 생성한 영속성 컨텍스트를 찾아와서 트랜잭션을 시작합니다.
  3. 응용 계층이 끝나면 트랜잭션을 커밋하고 영속성 컨텍스트를 플러시합니다. (영속성 컨텍스트는 종료하지 않습니다.)
  4. 컨트롤러와 뷰까지 영속성 컨텍스트가 유지되므로 조회한 엔티티는 영속 상태를 유지할 수 있습니다.
  5. 필터, 인터셉터로 요청이 돌아오면 영속성 컨텍스트를 종료하는데 이때 플러시는 수행하지 않습니다.

스프링 방식의 OSIV의 문제점을 한 번 생각해볼까요? 😀

충분히 고민해보신 다음에 펼쳐보세요!

OSIV 기능을 비활성화하여 성능 최적화를 해볼 수 있어요. 🤓

OSIV 기능이 활성화되어 있는 경우에는 트랜잭션의 범위를 벗어나도 커넥션을 계속 유지해요. 만약 트래픽을 많이 받는 상황이라면, 커넥션 고갈로 이어질 수 있습니다. OSIV 기능을 비활성화하여 데이터베이스 커넥션을 효율적으로 사용할 수 있습니다.

그러면 무조건 OSIV 기능을 비활성화해야 할까요? 🤔

무조건 비활성화하기 보다는 꺼야하는 근거가 필요해요. 만약 트랜잭션 범위 밖에서 지연로딩을 반드시 수행해야하는 경우에는 비활성화하기 어려울 수도 있어요.

데이터베이스를 복제하여 사용하는 경우, 데이터소스도 분리해야하는데요. OSIV 기능으로 인해 예기치 않은 데이터베이스로 요청이 전달될 수 있어요. 그리고, 대량의 트래픽이 발생하는 경우처럼 데이터베이스 커넥션을 효율적으로 사용해야할 수도 있습니다. 위와 같은 경우에는 OSIV 비활성화를 고려해볼 수 있을 것 같아요.

결국, 요지는 상황에 적합한 경우 OSIV 기능을 비활성화하는 것이 적절하다고 생각합니다.

LIST

들어가며

AI 모델을 학습시키거나 서빙하려면 결국 GPU가 필요하다. 그리고 2026년 현재, 가장 많이 쓰이는 데이터센터 GPU는 여전히 NVIDIA H100이다. OpenAI, Anthropic, Meta 할 것 없이 주요 AI 연구소 대부분이 H100 클러스터 위에서 LLM을 훈련시킨다.

문제는 가격이다. H100 한 장을 직접 사면 $25,000~$40,000(약 3,400만~5,500만 원). 8장 노드를 구성하면 하드웨어만 $200,000을 훌쩍 넘긴다. 전력, 냉각, 네트워킹, 랙 비용까지 합치면 초기 투자만으로 수억 원이다.

그래서 대부분의 팀은 클라우드에서 H100을 빌려 쓴다. 그런데 같은 H100인데 어디서 빌리느냐에 따라 시간당 비용이 최대 5배 이상 차이난다. 이 글에서는 2026년 4월 기준 H100 클라우드 비용을 프로바이더별로 비교하고, 워크로드 유형별 최적 전략을 정리한다.


1. H100 스펙 요약 — 왜 이 GPU인가

본격적인 비용 비교에 앞서, H100이 왜 표준이 됐는지 간단히 짚고 넘어가자.

NVIDIA H100 SXM5 (80GB)
├─ 아키텍처: Hopper (GH100, 800억 트랜지스터, TSMC 4nm)
├─ VRAM: 80GB HBM3, 3,350 GB/s 대역폭
├─ FP16 성능: 989 TFLOPS
├─ 핵심 기능: Transformer Engine (FP8 자동 전환)
├─ NVLink: 900 GB/s (SXM 버전)
├─ TDP: 700W
└─ A100 대비: 트랜스포머 학습 3~6배 빠름

H100의 핵심은 Transformer Engine이다. FP8과 FP16 사이를 연산 단위로 자동 전환해서, LLM 학습 시 A100 대비 3~6배 처리량 향상을 달성한다. 80GB HBM3 메모리로 FP16 기준 30B급 모델, 4/8bit 양자화 시 70B급 모델까지 단일 GPU에서 처리 가능하다.

SXM vs PCIe — 반드시 알아야 할 차이

항목                                            H100                                                  SXM5H100 PCIe
NVLink 대역폭 900 GB/s 없음 (PCIe 5.0 = 128 GB/s)
학습 성능 기준 (1x) 약 30~40% 느림
적합 용도 멀티 GPU 학습 단일 GPU 추론
가격 더 비쌈 더 저렴

멀티 GPU 학습이 목적이라면 반드시 SXM 버전을 선택해야 한다. PCIe 버전은 GPU 간 통신 병목이 심해 8장 이상 스케일링 시 효율이 급격히 떨어진다.


2. 2026년 4월 H100 클라우드 가격 비교

하이퍼스케일러 (AWS, GCP, Azure)

프로바이더        인스턴스                              GPU 수               온디맨드                    (per GPU/hr)비고
AWS p5.48xlarge 8 × H100 ~$3.90 2025년 6월 44% 인하 후 가격
GCP a3-highgpu 8 × H100 ~$3.00 컴포넌트별 과금 구조
Azure NC H100 v5 1 × H100 ~$6.98 리전별 $7~$10+

하이퍼스케일러는 GPU 자체 비용 외에 숨겨진 비용이 크다:

  • 데이터 이그레스: $0.08~$0.12/GB (학습 체크포인트 100GB 내보내기 = $8~12)
  • 스토리지: $0.10~$0.30/GB/월
  • 네트워킹 부가 비용: 전용 대역폭, VPC 피어링 등
  • 이런 부대 비용이 전체 청구서의 20~40%를 추가할 수 있다

전문 GPU 클라우드 (Specialized Providers)

프로바이더              온디맨드 (per GPU/hr)                       스팟/                                   마켓플레이스특징
Lambda Labs $2.49~$2.99 예약 시 $1.89 ML 특화, 안정적 업타임
RunPod $2.49 (PCIe) / $3.29 (SXM) $1.49 (스팟) 분 단위 과금, 무료 이그레스
CoreWeave ~$6.16 예약 시 할인 InfiniBand 클러스터, 대규모 학습
Vast.ai $1.65~$1.87 $1.07+ (마켓플레이스) P2P 마켓플레이스, 최저가
Northflank $2.74 스팟 지원 BYOC, 올인클루시브 가격
TensorDock $1.99~$2.25 스팟 $1.91+ KVM 격리, 윈도우 지원

가격 추이 — 어떻게 여기까지 왔나

2023년 하반기: $7.50~$11.00/hr  ← 극심한 공급 부족, 대기 명단
2024년 중반:   $3.00~$5.00/hr   ← 공급 개선, 신규 프로바이더 진입
2025년 초반:   $2.50~$4.00/hr   ← 시장 성숙, 경쟁 심화
2025년 6월:    AWS 44% 인하      ← 가격 전쟁 촉발
2026년 4월:    $2.00~$4.15/hr   ← 안정기 (온디맨드 기준)
2026년 하반기:  $1.50~$2.50/hr   ← 예상 (B200 본격 출하 영향)

H100 출시 초기 대비 64~75% 가격이 하락했다. 주요 원인은 TSMC의 CoWoS 패키징 용량 확대, 장기 예약 계약 만료에 따른 유휴 용량 시장 유입, 그리고 B200(Blackwell) 세대의 등장이다.


3. 실제 워크로드별 비용 시뮬레이션

숫자만 나열하면 감이 잡히지 않으니, 실제 시나리오별로 계산해보자.

시나리오 1: LLaMA 70B 파인튜닝 (LoRA/QLoRA)

필요 GPU: 1 × H100 80GB (QLoRA 4bit)
예상 소요: 24~72시간

├─ Lambda Labs ($2.99/hr):  $72 ~ $215
├─ RunPod ($2.49/hr):       $60 ~ $179
├─ AWS ($3.90/hr):          $94 ~ $281
├─ Azure ($6.98/hr):        $168 ~ $503
└─ Vast.ai ($1.65/hr):      $40 ~ $119

QLoRA 파인튜닝 하나에 프로바이더 선택만으로 최대 4배 비용 차이가 발생한다.

시나리오 2: 13B 모델 처음부터 학습 (Pre-training)

필요 GPU: 8 × H100 SXM
예상 소요: ~500시간 (데이터 규모에 따라 변동)

├─ Lambda Labs: 8 × $2.99 × 500 = $11,960
├─ RunPod SXM: 8 × $3.29 × 500  = $13,160
├─ AWS:        8 × $3.90 × 500  = $15,600
├─ GCP:        8 × $3.00 × 500  = $12,000
└─ Azure:      8 × $6.98 × 500  = $27,920

시나리오 3: 프로덕션 추론 서빙 (24/7)

필요 GPU: 2 × H100
월간 시간: 730시간

├─ RunPod ($2.49/hr):  2 × $2.49 × 730 = $3,635/월
├─ Lambda ($2.99/hr):  2 × $2.99 × 730 = $4,365/월
├─ AWS ($3.90/hr):     2 × $3.90 × 730 = $5,694/월
├─ Azure ($6.98/hr):   2 × $6.98 × 730 = $10,191/월
└─ 연간 차이:  RunPod vs Azure = 약 $78,672 절감

24/7 프로덕션에서는 연간 약 1억 원 이상 차이가 날 수 있다. 이 수준이면 프로바이더 마이그레이션에 들어가는 엔지니어링 비용을 충분히 상쇄하고도 남는다.


4. 구매 vs 렌탈 — 손익 분기점

H100을 직접 구매하는 것이 유리한 경우는 없을까?

구매 비용 (1 GPU 기준)
├─ H100 SXM5: ~$30,000
├─ 서버 섀시 + 네트워킹: ~$5,000 (GPU당 배분)
├─ 전력 + 냉각: ~$60/월/GPU
├─ 호스팅/코로케이션: ~$200/월/GPU
└─ 총 월간 유지비: ~$260/월

렌탈 비용 (클라우드 $2.50/hr 기준)
├─ 하루 8시간 사용: $20/일 = $600/월
├─ 하루 16시간 사용: $40/일 = $1,200/월
└─ 24시간 사용: $60/일 = $1,825/월
일 사용시간클라우드 월비용구매 월비용 (감가 42개월 + 유지비)손익분기
8시간 $600 ~$974 클라우드 유리
16시간 $1,200 ~$974 구매 유리
24시간 $1,825 ~$974 구매 압도적 유리

하루 12시간 이상 꾸준히 사용한다면 직접 구매가 경제적이다. 다만 이 계산에는 고장 리스크, H200/B200 세대 교체에 따른 감가 가속, 초기 구축 인력 비용 등이 빠져 있다. 대부분의 팀에게는 18개월 미만 프로젝트라면 클라우드가 안전한 선택이다.


5. 비용 최적화 전략 — 같은 작업, 절반의 비용

전략 1: 하이브리드 멀티 클라우드

┌─────────────────────────────────────────┐
│           워크로드별 프로바이더 분리           │
├─────────────────────────────────────────┤
│ 학습 (60~80% of 비용)                     │
│   → Lambda Labs / CoreWeave / RunPod    │
│   → H100 $2.49~$2.99/hr                │
├─────────────────────────────────────────┤
│ 추론 (서버리스)                            │
│   → RunPod Serverless                   │
│   → 초 단위 과금, 트래픽 없으면 $0           │
├─────────────────────────────────────────┤
│ 모델 레지스트리 / 데이터                     │
│   → AWS S3                              │
│   → 내구성 + 접근 패턴 최적화               │
├─────────────────────────────────────────┤
│ 프로덕션 서빙 (SLA 필요)                    │
│   → AWS / GCP 예약 인스턴스               │
│   → 컴플라이언스 + 99.99% 업타임            │
└─────────────────────────────────────────┘

학습은 전체 GPU 지출의 60~80%를 차지한다. 이 부분만 전문 프로바이더로 옮겨도 전체 비용을 40~50% 절감할 수 있다.

전략 2: 스팟 인스턴스 활용

스팟(Spot) / 프리엠터블(Preemptible) 인스턴스는 유휴 용량을 할인된 가격에 제공하되, 언제든 회수될 수 있다.

온디맨드 대비 절감률: 40~70%
적합: 체크포인트 지원 학습, 배치 추론, 하이퍼파라미터 탐색
부적합: 실시간 추론 API, 중단 불가 워크로드

핵심은 체크포인트 전략이다. 매 N 스텝마다 모델 상태를 저장해두면, 인스턴스가 회수되어도 마지막 체크포인트부터 재개할 수 있다. 스팟 인스턴스에서 3번 중단되더라도, 온디맨드 대비 전체 비용이 여전히 낮은 경우가 대부분이다.

전략 3: 과금 단위 확인

의외로 큰 차이를 만드는 것이 **과금 단위(Billing Granularity)**다.

프로바이더과금 단위
RunPod 분 단위
AWS 시간 단위 (최소 1시간)
Paperspace 시간 단위 (최소 1시간)
Lambda Labs 초 단위

10분짜리 실험을 시간 단위 과금 프로바이더에서 50번 돌리면 50시간 요금이 청구되지만, 분 단위 과금이면 약 8.3시간 요금만 나간다. 실험과 개발 단계에서는 분/초 단위 과금이 40% 이상 절약될 수 있다.

전략 4: 정말 H100이 필요한가?

모든 작업에 H100이 필요한 것은 아니다.

H100이 필요한 경우:
  ✅ 13B+ 파라미터 모델 학습
  ✅ 70B+ 모델 프로덕션 추론 (높은 처리량)
  ✅ 시간이 중요한 대규모 학습 잡

A100으로 충분한 경우:
  ✅ 10B 이하 모델 학습/파인튜닝
  ✅ 예산 제약이 큰 팀
  ✅ 긴급하지 않은 학습 ($1.29~$2.50/hr로 30~50% 절감)

RTX 4090으로 충분한 경우:
  ✅ Stable Diffusion 추론
  ✅ 소규모 실험 / 프로토타이핑
  ✅ 7B 이하 모델 파인튜닝 ($0.29~$0.60/hr)

6. 프로바이더 선택 가이드

모든 상황에 맞는 단일 최적 프로바이더는 없다. 워크로드 성격에 따라 달라진다.

하이퍼스케일러를 써야 하는 경우

  • 기존 인프라가 AWS/GCP/Azure 생태계에 깊이 결합되어 있을 때
  • HIPAA, FedRAMP, SOC 2 등 컴플라이언스 인증이 필수일 때
  • 99.99% SLA, 세밀한 IAM, 보장된 용량이 필요할 때
  • 다운타임 비용이 GPU 절감액을 초과할 때

전문 프로바이더를 써야 하는 경우

  • 순수 GPU 컴퓨트 — 학습, 배치 추론, 실험
  • 이그레스 비용이 부담될 때 (RunPod, Lambda = 무료 이그레스)
  • 스타트업 / 연구팀으로 예산이 제한적일 때
  • 분/초 단위 과금이 중요한 반복 실험 단계

의사결정 플로우

Q1. 컴플라이언스(HIPAA, SOC2 등)가 필수인가?
  ├─ Yes → AWS / GCP / Azure
  └─ No → Q2로

Q2. 24/7 프로덕션 서빙인가?
  ├─ Yes → Lambda Labs (안정성) 또는 하이퍼스케일러 예약
  └─ No → Q3로

Q3. 중단 허용 가능한가? (체크포인트 있음)
  ├─ Yes → RunPod 스팟 ($1.49) 또는 Vast.ai ($1.07+)
  └─ No → RunPod 온디맨드 ($2.49) 또는 Lambda ($2.99)

Q4. 월 예산은?
  ├─ < $1,000 → Vast.ai / TensorDock / RTX 4090 고려
  ├─ $1,000~$10,000 → RunPod / Lambda
  └─ > $10,000 → CoreWeave / 하이퍼스케일러 볼륨 협상

7. 앞으로의 전망 — H200, B200, 그리고 가격의 미래

H100은 2023년 출시 이후 3년차에 접어들었다. 후속 세대가 이미 시장에 진입하고 있다.

H100 (Hopper)  ── 80GB HBM3, 3,350 GB/s   ← 현재 주력
H200 (Hopper)  ── 141GB HBM3e, 4,800 GB/s  ← 같은 칩, 메모리 업그레이드
B200 (Blackwell) ── 192GB HBM3e, FP16 2.3배  ← 완전한 세대 교체
Rubin          ── 2026~2027 예정            ← 다다음 세대

B200이 본격 출하되면 H100은 "이전 세대" 취급을 받게 되고, 추가적인 10~20% 가격 하락이 예상된다. 2026년 하반기에는 H100 온디맨드 가격이 $1.50~$2.50/hr 수준까지 내려올 가능성이 높다.

하지만 역설적으로, 지금이 H100을 쓰기 가장 좋은 시점이기도 하다. 3년간 축적된 벤치마크, 튜닝 가이드, 라이브러리 호환성 — 모든 것이 검증된 상태다. B200은 더 빠르지만 배포 툴링이 아직 성숙하지 않았고, 가격도 H100 대비 프리미엄이 붙어 있다.


마치며

H100 클라우드 비용은 "어디서 빌리느냐"가 "무엇을 하느냐"만큼 중요하다. 같은 H100, 같은 워크로드인데 프로바이더 선택만으로 연간 수천만 원~수억 원의 차이가 발생한다.

핵심 요약:

  1. 하이퍼스케일러 온디맨드는 대부분의 경우 비효율적이다. 컴플라이언스가 필수가 아니라면 전문 프로바이더를 먼저 검토하자.
  2. 학습과 추론을 분리하면 각각에 최적화된 프로바이더와 인스턴스를 선택할 수 있다.
  3. 스팟 인스턴스 + 체크포인트는 비용을 40~70% 줄이는 가장 확실한 방법이다.
  4. H100이 정말 필요한지 먼저 확인하자. 많은 워크로드는 A100이나 4090으로도 충분하다.
  5. 2026년 하반기 B200 본격 출하 시 추가 가격 하락이 예상되므로, 장기 예약 계약은 신중하게.

GPU 비용은 AI 프로젝트 성패를 좌우하는 변수 중 하나다. 기술만큼 비용 전략에도 시간을 투자할 가치가 있다.


참고 자료


2026년 4월 기준 가격입니다. 클라우드 GPU 가격은 리전, 사용량, 계약 조건에 따라 변동됩니다. 실제 프로비저닝 전에 각 프로바이더의 최신 요금표를 반드시 확인하세요.

LIST

+ Recent posts