방구석 개발자의 실험실

[AWS] ACM(Certificate Manager) 완벽 가이드: SSL/TLS 인증서 관리부터 ALB 연결까지

snapcoder — Mon, 13 Apr 2026 23:06:53 +0900

들어가기

클라우드 환경에서 HTTPS 통신을 구현하려면 SSL/TLS 인증서가 필수입니다. AWS는 이를 관리하기 위해 ACM(AWS Certificate Manager)라는 서비스를 제공합니다.

이번 글에서는 ACM이 무엇인지부터 시작해, 인증서 선택 기준, 등록 방법, 그리고 ALB와의 연결 방식까지 실무 관점에서의 완전한 가이드를 소개합니다.

상품 페이지 : https://aws.amazon.com/ko/certificate-manager/

Certificate Manager - AWS Certificate Manager - AWS

AWS Certificate Manager를 사용하여 AWS 서비스 및 연결된 내부 리소스를 통해 퍼블릭 및 프라이빗 SSL/TLS 인증서를 프로비저닝, 관리 및 배포하는 데 도움이 됩니다.

aws.amazon.com

사용 설명서 : https://docs.aws.amazon.com/ko_kr/acm/latest/userguide/acm-overview.html

AWS Certificate Manager란 무엇인가요? - AWS 인증서 관리자

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

1️⃣ SSL/TLS 인증서란 무엇인가?

기본 개념

SSL/TLS 인증서는 웹 서버와 클라이언트 간의 통신을 암호화하고, 서버의 신원을 검증하는 디지털 인증서입니다.

HTTP 통신 (평문)
  ↓
사용자 데이터 노출 위험 ❌

HTTPS 통신 (암호화된 HTTP + SSL/TLS)
  ↓
사용자 데이터 보호 ✅

SSL/TLS의 역할

역할	설명
데이터 암호화	사용자 입력 정보(비밀번호, 개인정보)를 암호화
서버 검증	접속한 서버가 진짜인지 확인
무결성 보장	데이터가 전송 중에 변조되지 않았음을 보장
SEO 개선	검색엔진이 HTTPS 사이트를 더 높게 평가

2️⃣ AWS ACM(Certificate Manager)이란?

ACM의 역할

AWS Certificate Manager(ACM)는 SSL/TLS 인증서를 생성, 관리, 배포하는 관리형 서비스입니다.

수동 방식 (외부 CA에서 구입):
  1. 외부 CA 선택
  2. CSR(Certificate Signing Request) 생성
  3. 도메인 검증
  4. 인증서 다운로드
  5. 서버에 설치
  6. 갱신 시기 주의
  → 번거로움

AWS ACM (자동 관리):
  1. ACM에서 인증서 요청
  2. AWS가 도메인 검증
  3. ALB/NLB에 자동 연결
  4. 자동 갱신 처리
  → 간편함

ACM의 주요 특징

✅ 무료: AWS 리소스(ALB, NLB, CloudFront 등)와 함께 사용하면 무료
✅ 자동 갱신: 만료 전 자동으로 새 인증서 발급
✅ 사설 CA 지원: 자체 인증서 생성 가능
✅ 멀티 도메인: 와일드카드(*.example.com) 지원
✅ 무료 SSL/TLS 검증: DNS/이메일 검증 모두 지원

3️⃣ ACM vs 외부 인증서(Imported) 비교

ACM 인증서 (AWS에서 발급)

장점:
  ✅ 무료 (AWS 리소스 사용 시)
  ✅ 자동 갱신 (번거로움 없음)
  ✅ 생성 및 관리 간단
  ✅ AWS 리소스와 자동 연동

단점:
  ❌ AWS 리소스에만 사용 가능 (온프레미스 불가)
  ❌ 인증서 다운로드 불가 (오직 AWS 내에서만)
  ❌ 와일드카드만 사용 가능 (단일 도메인 불가)

외부 인증서 (제3자 CA에서 구입 후 Import)

장점:
  ✅ 다양한 환경 지원 (온프레미스, 다른 클라우드 등)
  ✅ 인증서 다운로드 가능
  ✅ 레거시 시스템 지원

단점:
  ❌ 구매 비용 발생
  ❌ 수동 갱신 필요
  ❌ 관리 복잡도 높음
  ❌ 만료 전 알림 관리 필요

언제 어떤 걸 선택할까?

AWS 환경만 사용 → ACM 추천 (무료 + 자동 갱신)
온프레미스도 필요 → 외부 인증서 Import (유연성)

4️⃣ 왜 ALB(Application Load Balancer)에 인증서를 등록하는가?

TLS 종료(Termination) 개념

TLS 종료란 로드밸런서가 클라이언트로부터 받은 암호화된 트래픽을 복호화하는 것을 말합니다.

클라이언트 (HTTPS)
  ↓ (암호화된 요청)
ALB (TLS 종료 - 복호화)
  ↓ (HTTP로 복호화)
백엔드 EC2 (일반 HTTP)

왜 ALB에 인증서를 등록할까?

이유	설명
암호화 담당	클라이언트-ALB 구간만 HTTPS 필요
백엔드 부하 감소	EC2가 암복호화 작업 하지 않음 → CPU 절약
중앙 관리	모든 인증서를 ALB에서 통합 관리
비용 효율	EC2 개별 인증서 관리 불필요
자동 갱신	ACM 자동 갱신이 ALB까지 자동 반영

예시:
  사용자 ──(HTTPS/암호화)── ALB(인증서 등록)
                            ──(HTTP/평문)── EC2 인스턴스
                            ──(HTTP/평문)── EC2 인스턴스

5️⃣ NLB vs ALB 인증서 적용 차이

ALB (Application Load Balancer)

특징:
  - 애플리케이션 계층(Layer 7) 로드밸런싱
  - HTTPS 리스너에 인증서 바로 등록
  - SNI(Server Name Indication) 지원으로 여러 인증서 매핑 가능
  - 호스트명 기반 라우팅 가능

사용 사례:
  - 웹 애플리케이션
  - API 서버
  - 마이크로서비스

ALB + 인증서 구조:

ALB의 HTTPS 리스너 (포트 443)
  ├─ 인증서 1: example.com
  ├─ 인증서 2: api.example.com
  └─ 인증서 3: *.example.com

각 인증서에 대해 라우팅 규칙 적용

NLB (Network Load Balancer)

특징:
  - 전송 계층(Layer 4) 로드밸런싱
  - 높은 성능과 극저 지연시간
  - TLS 오프로딩 지원 (ALB와 유사)
  - UDP/TCP 동시 지원

사용 사례:
  - 실시간 게임 서버
  - IoT 데이터 수집
  - 극도로 높은 성능 필요

NLB + 인증서 구조:

NLB의 TLS 리스너 (포트 443)
  ├─ 기본 인증서: example.com
  └─ SNI 인증서 매핑도 가능

백엔드는 다양한 프로토콜 지원

ALB vs NLB 선택 기준

항목	ALB	NLB
사용 계층	Layer 7(응용)	Layer 4(전송)
인증서 관리	쉬움 (호스트명 기반)	복잡 (IP 기반)
성능	중간	매우 높음
비용	저가	고가
추천 대상	일반 웹앱	고성능 필요

6️⃣ 키 알고리즘 종류 (ECDSA P-256 vs RSA 2048)

RSA 2048

특징:
  - 오래된 표준 알고리즘
  - 2048비트 키 길이
  - 호환성 매우 높음

장점:
  ✅ 거의 모든 브라우저/디바이스 지원
  ✅ 레거시 시스템 호환

단점:
  ❌ 키 크기 크다 (인증서 크기 증가)
  ❌ 암호화/검증 속도 느림
  ❌ 보안강도 상대적으로 낮음

예):
  인증서 크기: ~2KB
  검증 시간: 상대적으로 느림

ECDSA P-256 (권장)

특징:
  - 최신 타원곡선 암호화
  - 256비트 키 길이 (RSA 2048과 동등 보안강도)

장점:
  ✅ 키 크기 작다 (인증서 크기 작음)
  ✅ 암호화/검증 속도 빠름
  ✅ 보안강도 우수함
  ✅ 모던 브라우저 전부 지원

단점:
  ❌ 매우 오래된 디바이스는 미지원 (극히 드물음)

예):
  인증서 크기: ~900B (RSA 2048 대비 45%)
  검증 시간: 2배 이상 빠름

성능 비교

RSA 2048:
  인증서 크기: 2,048 bytes
  서명 생성: ~10ms
  서명 검증: ~5ms

ECDSA P-256:
  인증서 크기: 900 bytes  ← 45% 작음
  서명 생성: ~3ms         ← 3배 빠름
  서명 검증: ~2ms         ← 2.5배 빠름

7️⃣ 키 알고리즘 선택 기준

ECDSA P-256을 선택해야 할 때 (권장)

✅ 현대적인 웹 애플리케이션
✅ 모바일 앱이 주요 사용자
✅ API 서버 (성능 중요)
✅ 극도의 호환성이 필수 아닐 때

→ 대부분의 경우 ECDSA P-256 선택

RSA 2048을 선택해야 할 때

✅ 레거시 디바이스 지원 필수
✅ IE 8 이하 구 브라우저 필요
✅ 매우 오래된 시스템과 호환

→ 극히 드문 경우만

ACM에서 선택 방법

ACM 인증서 요청 페이지:

  키 알고리즘
  ├─ RSA 2048 (호환성 최우선)
  └─ ECDSA P-256 (권장) ← 선택

실무 추천: ECDSA P-256 선택

모던 환경에서 성능과 보안 모두 우수
호환성도 99.9% 수준

8️⃣ 인증서 유효 기간 및 자동 갱신

인증서 유효 기간

ACM에서 발급하는 인증서:
  유효 기간: 1년 (13개월)
  갱신 시기: 만료 30일 전부터 자동 갱신 시작

자동 갱신 흐름

Day 1 (인증서 발급)
  ↓
Day 335 (만료 30일 전)
  ↓
AWS: "자동 갱신 진행"
  - 새로운 인증서 생성
  - 도메인 검증 (DNS 또는 이메일)
  - 기존 리소스(ALB 등)에 자동 적용
  ↓
Day 365 (만료일)
  ↓
기존 인증서 만료
새 인증서 활성화 ✅
  (기존 서비스 중단 없음)

만료 전 알림 설정

SNS 토픽 구독으로 알림 수신:
  - 만료 45일 전
  - 만료 30일 전
  - 만료 7일 전
  - 갱신 실패 시

중요: ACM이 자동 갱신하지만, SNS 알림을 꼭 설정해서 문제 발생 시 대비하세요!

9️⃣ 계정/리전별 인증서 독립 관리

계정별 독립 관리

AWS 계정 A
  └─ ACM 인증서 (example.com)
     └─ 이 계정 내 ALB/NLB만 사용 가능

AWS 계정 B
  └─ 동일한 도메인 인증서 필요
     └─ 계정 B에서도 별도 ACM 인증서 요청 필요

주의: 한 계정의 인증서는 다른 계정에서 사용 불가
→ 멀티 계정 환경에서는 각 계정별로 인증서 요청 필요

리전별 독립 관리

ACM은 리전별 서비스:

  us-east-1 (버지니아)
    └─ 인증서 A 등록

  eu-west-1 (아일랜드)
    └─ 동일 도메인이라도 별도 인증서 필요

  ap-northeast-1 (도쿄)
    └─ 동일 도메인이라도 별도 인증서 필요

예외: CloudFront

CloudFront는 us-east-1 인증서만 사용 가능
→ CloudFront 연결 시 us-east-1에 인증서 요청

리전별 인증서 동기화 (자동 불가)

권장 구조:

  Main Region (us-east-1)
    ↓ (수동 구독)
  SNS 토픽
    ↓
  Backup Region (eu-west-1)
    └─ 별도 ACM 인증서 유지

팁: 멀티 리전 운영 시 각 리전마다 같은 도메인으로 인증서 요청 후, 자동 갱신 설정

도메인 검증 방식 (DNS 검증 vs 이메일 검증)

DNS 검증 (권장)

특징:
  - ACM이 DNS에 CNAME 레코드 생성
  - AWS가 자동 검증

장점:
  ✅ 완전 자동화 (수동 작업 불필요)
  ✅ 자동 갱신도 자동으로 검증 완료
  ✅ 이메일 받지 못해도 괜찮음

단점:
  ❌ Route 53 또는 지원하는 DNS 공급자 필요
  ❌ DNS 레코드 수정 권한 필요

검증 절차:
  1. ACM 인증서 요청
  2. "DNS로 검증" 선택
  3. AWS 제시 CNAME 레코드 Route 53에 추가
  4. AWS 자동 검증 (보통 5분 이내)
  5. ✅ 인증서 발급

CNAME 레코드 예시:

Name: _abc123.example.com
Type: CNAME
Value: _xyz789.acm-validations.aws.

이메일 검증

특징:
  - 도메인 관리자 이메일로 검증

장점:
  ✅ DNS 수정 권한 불필요
  ✅ 어떤 DNS 공급자든 가능

단점:
  ❌ 수동 확인 필요
  ❌ 이메일 못 받으면 검증 실패
  ❌ 자동 갱신 시 매번 이메일 승인 필요
  ❌ 갱신 실패 위험 높음

검증 절차:
  1. ACM 인증서 요청
  2. "이메일로 검증" 선택
  3. 도메인 관리자 이메일로 검증 링크 수신
  4. 링크 클릭해서 승인
  5. ✅ 인증서 발급

선택 기준

AWS Route 53 사용 중    → DNS 검증 (완전 자동화)
타 DNS 서비스 사용      → 상황에 따라
  - 자동화 필요         → DNS 검증
  - 수동 작업 괜찮음    → 이메일 검증

강력 권장: DNS 검증 (자동 갱신 안정성 때문에)

1️⃣1️⃣ ACM 인증서 등록 방법 (단계별)

Step 1: ACM 콘솔 접속

AWS Management Console
  ↓
ACM (Certificate Manager) 검색
  ↓
"인증서 요청" 클릭

Step 2: 인증서 유형 선택

공개 인증서 (일반적)
  └─ HTTPS/TLS 통신용

프라이빗 CA
  └─ 내부 통신용

Step 3: 도메인 이름 입력

도메인 이름:
  example.com

추가 도메인:
  www.example.com
  *.example.com (와일드카드)

Step 4: 검증 방식 선택

DNS 검증 (권장)
  or
이메일 검증

Step 5: 태그 추가 (선택)

키: Environment
값: Production

키: Project
값: MyApp

Step 6: 리뷰 및 요청

"요청" 클릭
  ↓
검증 대기 (DNS: 5분, 이메일: 며칠)
  ↓
✅ 발급 완료

1️⃣2️⃣ ALB 리스너 규칙과 인증서 연결 구조

ALB 기본 구조

클라이언트 (인터넷)
  ↓ (HTTPS 443)
ALB (리스너)
  ├─ 리스너 1: 포트 443 (HTTPS)
  │  ├─ 인증서: example.com
  │  └─ 대상 그룹: TargetGroup-1
  │
  └─ 리스너 2: 포트 80 (HTTP)
     └─ 규칙: 포트 443으로 리다이렉트

ALB HTTPS 리스너 설정 (포트 443)

1. 리스너 생성
   - 프로토콜: HTTPS
   - 포트: 443

2. 보안 정책
   - ELBSecurityPolicy-TLS-1-2-2017-01 (기본)
   - or 커스텀 정책

3. 인증서 선택
   - ACM에서 발급한 인증서 목록 표시
   - 기본 인증서: example.com
   - 추가 인증서: *.example.com

4. 라우팅 규칙
   - 호스트명 기반: example.com → TargetGroup-A
   - 호스트명 기반: api.example.com → TargetGroup-B
   - 패턴 매칭: /api/* → TargetGroup-C

인증서와 라우팅 규칙 연결 예시

ALB 포트 443 (HTTPS)
│
├─ 인증서 1: example.com
│  ├─ 규칙 1: 호스트명 = example.com → TargetGroup-1 (웹사이트)
│  └─ 규칙 2: 호스트명 = www.example.com → TargetGroup-1
│
├─ 인증서 2: api.example.com
│  └─ 규칙 3: 호스트명 = api.example.com → TargetGroup-2 (API)
│
└─ 인증서 3: *.example.com (와일드카드, 폴백)
   └─ 규칙 4: 기타 모든 호스트명 → TargetGroup-3 (기본값)

SNI(Server Name Indication) 활용

클라이언트가 TLS 핸드셰이크 시 접속하려는 도메인명 전달
  ↓
ALB가 SNI로 받은 도메인명 확인
  ↓
해당 인증서로 응답
  ↓
단일 IP에서 여러 인증서 운영 가능 ✅

예:

사용자 1이 example.com 접속
  → SNI: example.com 전달
  → ALB: example.com 인증서로 응답

사용자 2가 api.example.com 접속
  → SNI: api.example.com 전달
  → ALB: api.example.com 인증서로 응답

모두 동일 ALB IP를 사용하지만 인증서는 분리

실무 체크리스트

ACM 인증서 구축 시

✅ ECDSA P-256 키 알고리즘 선택
✅ DNS 검증 방식 선택
✅ Route 53에 CNAME 레코드 추가
✅ 인증서 발급 대기
✅ SNS 알림 구독 설정
✅ ALB 포트 443 HTTPS 리스너 생성
✅ ACM 인증서 연결
✅ 라우팅 규칙 설정

멀티 리전/계정 환경에서

✅ 각 리전별로 ACM 인증서 요청
✅ 각 계정별로 ACM 인증서 요청
✅ CloudFront 사용 시 us-east-1에만 인증서 구성
✅ 자동 갱신 설정 확인

정리

AWS ACM은 SSL/TLS 인증서를 무료로 생성하고 자동 관리해주는 서비스입니다.

ECDSA P-256 키 알고리즘 선택으로 성능 최적화
DNS 검증 방식으로 완전 자동화
ALB HTTPS 리스너에 인증서 등록해서 TLS 종료
SNI 활용으로 단일 IP에서 다중 도메인 지원

이 구조를 정확히 이해하면 AWS 환경에서 HTTPS를 안전하고 효율적으로 운영할 수 있습니다!

[DevOps] 무중단 배포 전략 4가지 총정리: 롤링,카나리,블루그린,A/B 배포 장단점

snapcoder — Mon, 6 Apr 2026 21:08:11 +0900

들어가기

서비스를 운영하다 보면 새로운 기능을 배포해야 합니다. 하지만 배포 중 서비스가 중단되면 사용자는 불편을 겪게 됩니다.

무중단 배포(Zero-Downtime Deployment)는 서비스 운영 중에도 중단 없이 새로운 버전을 배포하는 전략입니다. 오늘은 실무에서 자주 사용되는 4가지 무중단 배포 전략을 비교하고, 각각의 특징과 선택 기준을 소개합니다.

1️⃣ 롤링 배포 (Rolling Deployment)

정의: 순차적으로 구 버전 인스턴스를 제거하고 새 버전으로 교체하는 배포 방식입니다.

동작 원리

초기 상태: [v1] [v1] [v1] (총 3개 인스턴스)
           (모두 로드밸런서에 연결)

Step 1: [v1] [v1] [v1]
        └─ 첫 번째 인스턴스를 LB에서 제거
        └ 새로운 버전(v2) 배포
        └ [v2] [v1] [v1]

Step 2: [v2] [v1] [v1]
        └─ 두 번째 인스턴스를 LB에서 제거
        └ [v2] [v2] [v1]

Step 3: [v2] [v2] [v1]
        └─ 세 번째 인스턴스를 LB에서 제거
        └ [v2] [v2] [v2]

완료: 모든 인스턴스가 새 버전(v2)로 업데이트됨

장점

✅ 리소스 효율적 — 추가 서버 필요 없음
✅ 간단한 구현 — 기본적인 배포 자동화로 가능
✅ 빠른 배포 — 병렬로 여러 인스턴스 배포 가능

단점

❌ 배포 중 버전 혼재 — v1과 v2가 동시에 운영되므로 호환성 관리 필요
❌ 문제 발생 시 즉시 복구 어려움 — 롤백이 오래 걸림
❌ 카나리 테스트 불가 — 일부만 먼저 배포할 수 없음

언제 사용?

버전 간 호환성이 좋을 때
빠른 배포가 우선일 때
인프라가 제한적일 때

2️⃣ 카나리 배포 (Canary Deployment)

정의: 새 버전을 일부 사용자에게만 먼저 배포하고, 문제 없으면 점진적으로 확대하는 방식입니다.

카나리 배포의 유래: 광산에서 위험한 가스를 감지하기 위해 카나리새를 광산에 먼저 보냈습니다. 새가 살아있으면 안전하다고 판단했죠. 배포도 마찬가지입니다. 새 버전을 먼저 일부 사용자에게 배포해 "위험한 버그"가 없는지 확인하는 방식입니다!

동작 원리

초기 상태: [v1] [v1] [v1] (100% v1)
           LB 트래픽 분배

Step 1 (10% 카나리): [v2] [v1] [v1]
                     10%  90%
                     (10% 사용자만 v2 체험)

Step 2 (50% 점진): [v2] [v2] [v1]
                   50%  50%
                   (문제 없으면 비율 확대)

Step 3 (100% 완료): [v2] [v2] [v2]
                    (모든 사용자가 v2 사용)

문제 발생 시: 즉시 카나리 버전 중단 후 롤백

장점

✅ 위험 최소화 — 일부 사용자만 영향받음
✅ 실시간 모니터링 — 실제 사용자의 반응을 관찰
✅ 빠른 롤백 — 문제 감지 시 즉시 중단 가능
✅ 신뢰도 높음 — 운영 환경에서 미리 검증

단점

❌ 배포 시간 오래 걸림 — 점진적 확대에 시간 필요
❌ 모니터링 필수 — 지표 추적 및 알림 체계 구축 필요
❌ 버전 혼재 — 여러 버전이 동시 운영되므로 호환성 관리 필요

언제 사용?

장애 영향이 큼과 같은 고위험 배포일 때
사용자 반응을 미리 보고 싶을 때
점진적 롤아웃이 필요할 때

3️⃣ 블루그린 배포 (Blue-Green Deployment)

정의: 구 버전(Blue)과 새 버전(Green)을 동시에 준비한 후, 로드밸런서의 트래픽을 한 번에 전환하는 방식입니다.

동작 원리

사전 준비: 구 버전(Blue)과 새 버전(Green) 동시 준비

[Blue 환경]        [Green 환경]
[v1] [v1] [v1] ←→ [v2] [v2] [v2]
(현재 운영)        (새 버전 테스트)

LB: Blue → 100% 트래픽

Step 1: 새 버전(Green)에서 충분한 테스트 수행
       - 기능 검증
       - 성능 테스트
       - 데이터 마이그레이션 확인

Step 2: 테스트 완료 후 LB 전환

LB: Blue ← → Green
    0%    100% (트래픽 즉시 전환)

Step 3: 문제 발생 시 즉시 Blue로 롤백

LB: Blue ← → Green
    100%   0%  (즉시 원래 버전으로 복구)

장점

✅ 빠른 배포 — 테스트 완료 후 즉시 전환
✅ 빠른 롤백 — 한 번에 이전 버전으로 복구 가능
✅ 버전 격리 — v1과 v2가 분리되어 있어 호환성 문제 없음
✅ 0% 다운타임 — 트래픽 전환만으로 배포 완료

단점

❌ 리소스 2배 필요 — Blue와 Green 환경을 동시 유지해야 함
❌ 비용 증가 — 인프라 비용 2배
❌ 데이터 동기화 복잡 — Blue와 Green 간 데이터 정합성 관리 필요

언제 사용?

빠른 롤백이 중요할 때
인프라 리소스가 충분할 때
데이터베이스 마이그레이션이 필요 없을 때

4️⃣ A/B 배포 (A/B Deployment)

정의: 구 버전(A)과 새 버전(B)을 동시에 운영하면서, 특정 사용자 그룹별로 어느 버전을 사용할지 선택하는 방식입니다.

(카나리 배포와 비슷해 보이지만, A/B는 "비율" 기반이 아니라 "그룹" 기반입니다)

동작 원리

[버전 A 환경]       [버전 B 환경]
[v1] [v1]          [v2] [v2]

라우팅 규칙:
  - OS = iOS    → B 버전 (v2)
  - OS = Android → A 버전 (v1)
  또는
  - User ID % 2 == 0 → B 버전 (v2)
  - User ID % 2 == 1 → A 버전 (v1)
  또는
  - Region = Asia → A 버전 (v1)
  - Region = US → B 버전 (v2)

결과: 사용자에 따라 다른 버전 경험

장점

✅ 정확한 테스트 — 특정 사용자 그룹만 새 버전 체험
✅ 기능별 검증 — 특정 국가나 디바이스에서만 배포 가능
✅ 사용자 세분화 — 타겟 사용자에게만 새 기능 공개 가능
✅ 점진적 확대 — 리스크를 최소화하며 배포 확대

단점

❌ 복잡한 라우팅 — 사용자별 어느 버전을 보여줄지 관리 필요
❌ 데이터 일관성 문제 — A 버전과 B 버전의 데이터 동기화 어려움
❌ 디버깅 어려움 — 버전별 사용자 행동이 다르면 원인 파악 어려움
❌ 오래 운영 불가 — 장기 운영 시 유지보수 비용 증가

언제 사용?

새 기능을 특정 사용자에게만 공개할 때
국가/디바이스별로 다른 버전을 배포할 때
UI/UX 개선 효과를 측정하고 싶을 때

4가지 배포 전략 비교표

항목	롤링	카나리	블루그린	A/B
배포 시간	느림	매우 느림	빠름	중간
리소스 필요	최소	최소	2배	2배
롤백 속도	느림	빠름	매우 빠름	중간
버전 격리	❌	❌	✅	❌
위험도	높음	낮음	매우 낮음	중간
모니터링	기본	필수	기본	필수
추천 환경	저위험	고위험	높은 확실성	실험/검증

배포 전략 선택 가이드

상황별 추천 전략

Q1: 빠른 배포가 최우선이다
  → 블루그린 배포

Q2: 버전 호환성이 좋고 리소스가 부족하다
  → 롤링 배포

Q3: 새 버전이 얼마나 안정적인지 확신할 수 없다
  → 카나리 배포

Q4: 특정 사용자 그룹에만 새 기능을 공개하고 싶다
  → A/B 배포

Q5: 장애가 생기면 안되는 주요 서비스이다. (ex 결제쪽)
  → 블루그린 또는 카나리 배포

단계별 배포 전략

Dev 환경
  ↓
Staging: 카나리 배포로 10% 사용자 대상 테스트
  ↓
Production: 블루그린 배포로 빠르게 전환
  ↓
모니터링: 이상 발생 시 즉시 롤백

실전 팁

1. 모니터링은 필수

- 에러율 모니터링 (CPU, 메모리 등)
- 사용자 응답 시간 추적
- 에러 로그 실시간 수집
- 알림 설정 (임계값 도과 시)

2. 롤백 계획 수립

- 이전 버전의 데이터베이스 백업
- 라우팅 설정 자동화 (빠른 전환)
- 롤백 테스트 주기적 실행

3. 버전 간 호환성 검증

- API 응답 형식 호환성 확인
- 데이터베이스 스키마 마이그레이션 테스트
- 캐시 무효화 계획 수립

정리

무중단 배포 전략은 상황과 요구사항에 따라 선택합니다.

롤링 배포: 빠르고 간단하지만 위험도 높음
카나리 배포: 느리지만 가장 안전함
블루그린 배포: 비용은 크지만 가장 빠르고 확실함
A/B 배포: 실험과 검증에 최적화됨

여러 전략을 조합하여 사용하면 리스크를 최소화하면서도 빠르게 배포할 수 있습니다.

당신의 서비스 특성과 인프라에 맞는 배포 전략을 선택하고, 항상 모니터링과 롤백 계획을 먼저 수립하세요!

[SQL] ORDER BY Ties: 하나의 데이터가 여러 Page에 조회되는 이유

snapcoder — Mon, 30 Mar 2026 01:52:10 +0900

제가 아는 tie 는 넥타이 뿐입니다.

라고 하실 분들을 위해(저도 포함입니다), 용어부터 짚고 넘어가보겠습니다.

# 영어에서, tie = 묶다 / 연결하다 / 동점 => 스포츠 경기 동점되면, “The game is tied” 라고 표현

# DB에서, ORDER BY tie = 정렬 기준 같은 row 존재 => “ORDER BY tie 발생했다" 라고 표현

# tie-breaker = 동점을 깨는 기준

데이터 조회 쿼리에서 페이지네이션을 구현할 때 마주친 ORDER BY Ties 버그를 소개합니다.
실제로는 1개의 행만 존재하는데, 1페이지와 2페이지에 동일한 데이터가 나타나는 현상을 겪었고, 그 원인과 해결 방법을 정리했습니다.

문제 유형: 데이터베이스 — LIMIT/OFFSET 페이지네이션 불안정성

문제: 1페이지와 2페이지에서 같은 데이터가 조회된다

예시 사진은 20개씩 페이징 처리 => 407번 id가 1페이지와 2페이지에 표시되고 있음.

상황

DB에는 실제로 데이터가 1개 존재
API에서 페이지 크기 10으로 첫 번째 페이지(LIMIT 10 OFFSET 0) 조회
그 다음 두 번째 페이지(LIMIT 10 OFFSET 10) 조회
결과: 같은 1개의 데이터가 두 페이지 모두에 표시됨 ❌

테스트 시나리오

-- DB의 실제 데이터: 1행
SELECT COUNT(*) FROM sample_table;  -- 결과: 1


-- 1페이지 조회
SELECT * FROM sample_table 
ORDER BY created_at DESC, view_count DESC
LIMIT 10 OFFSET 0;
-- 결과: 데이터 1행 출력


-- 2페이지 조회
SELECT * FROM sample_table
ORDER BY created_at DESC, view_count DESC
LIMIT 10 OFFSET 10;
-- 결과: 데이터 1행 출력 (같은 데이터!)

원인: ORDER BY Ties 문제

ORDER BY Ties(데드히트, 동점)란 정렬 조건의 값이 동일한 여러 행이 있을 때 발생합니다.
LIMIT/OFFSET 페이지네이션에서는 각 쿼리마다 정렬 순서가 보장되지 않아 중복 또는 누락이 발생할 수 있습니다.

예시로 이해하기

실제 데이터 3행:
ID | created_at | view_count
1  | 2025-01-01 | 100
2  | 2025-01-01 | 100   ← created_at과 view_count가 같음
3  | 2025-01-01 | 100   ← created_at과 view_count가 같음


쿼리 1: ORDER BY created_at DESC, view_count DESC LIMIT 2 OFFSET 0
결과 (경우 1): [ID=1, ID=2]
결과 (경우 2): [ID=1, ID=3]  ← 정렬 순서가 보장되지 않음


쿼리 2: ORDER BY created_at DESC, view_count DESC LIMIT 2 OFFSET 2
결과 (경우 1): [ID=3]        ← ID=2 누락
결과 (경우 2): [ID=2]        ← ID=3 누락

정렬 값이 같으면, 데이터베이스는 임의의 순서로 반환할 수 있습니다.
페이지네이션 경계에서 순서가 뒤바뀌면 데이터가 중복되거나 누락됩니다.

해결책: 최종 Tie-Breaker로 Primary Key 추가

정렬 조건의 마지막에 Primary Key(id DESC)를 추가하여 모든 행이 고유한 값으로 최종 정렬되도록 보장합니다.

2페이지(우측)에서 407 중복 조회되지 않음.

수정 전

SELECT * FROM sample_table
ORDER BY created_at DESC, view_count DESC
LIMIT 10 OFFSET 0;

수정 후

-- id DESC를 최종 tie-breaker로 추가
SELECT * FROM sample_table
ORDER BY created_at DESC, view_count DESC, id DESC
LIMIT 10 OFFSET 0;

개선 효과

모든 행이 고유한 id로 최종 정렬 처리로, 동일한 정렬값을 가진 행들의 순서 보장 문제 해결
LIMIT/OFFSET 페이지네이션에서 중복 및 누락이 완전히 제거
정렬 순서가 쿼리마다 일관되게 유지됨

적용 예시: Java에서 동적 쿼리 생성

Before (문제 있는 코드)

String query = "SELECT * FROM data_table "
    + "ORDER BY created_at " + direction
    + ", view_count DESC"
    + ", CASE WHEN deadline IS NULL THEN 1 ELSE 0 END"
    + ", deadline ASC";
    // ← 여기서 끝남. Tie-breaker 없음


String sql = query + " LIMIT " + pageSize + " OFFSET " + offset;
ResultSet rs = statement.executeQuery(sql);

After (개선된 코드)

// 마지막에 id DESC를 추가 처리로, 정렬 동점에서 발생하는 페이지 경계 중복 데이터 문제 해결
String query = "SELECT * FROM data_table "
    + "ORDER BY created_at " + direction
    + ", view_count DESC"
    + ", CASE WHEN deadline IS NULL THEN 1 ELSE 0 END"
    + ", deadline ASC"
    + ", id DESC";  // ← Tie-breaker 추가


String sql = query + " LIMIT " + pageSize + " OFFSET " + offset;
ResultSet rs = statement.executeQuery(sql);

적용 포인트

정렬 방식	수정 사항
등록일순	`... created_at DESC` → `... created_at DESC, id DESC`
조회수순	`... view_count DESC` → `... view_count DESC, id DESC`
마감일순	`... deadline ASC` → `... deadline ASC, id DESC`
복합 정렬	마지막 조건 뒤에 `id DESC` 추가

핵심 정리

항목	내용
문제	정렬값이 같은 행들에서 LIMIT/OFFSET이 불안정함
원인	Tie가 발생했을 때 DB의 반환 순서가 보장되지 않음
해결책	Primary Key(`id DESC`)를 최종 정렬 조건으로 추가
효과	모든 행의 순서가 고유한 값으로 보장되어 페이지네이션 안정화
주의사항	모든 정렬 방식에 일관되게 적용해야 효과적

데이터베이스 페이지네이션에서는 정렬 순서의 명확성이 중요하여
정렬값이 같은 경우를 대비해 항상 Primary Key를 최종 tie-breaker로 지정하는 것을 권장드립니다.

[Codility] Round Robin 대기시간 합 구하기

snapcoder — Sat, 28 Mar 2026 23:08:25 +0900

구현(Simulation) + 수식 유도 유형 문제를 복기합니다.
단계별 시뮬레이션 없이 수학적 공식으로 각 작업의 완료 시간을 직접 계산하는 접근이 핵심이었던 문제입니다.

문제 유형: 구현(Simulation) — 라운드로빈 스케줄링 + 수식 유도

문제 요약

N개의 작업이 주어진다. 각 작업은 처리에 필요한 시간(정수)을 가진다.
라운드로빈(Round Robin) 방식으로 1 단위씩 번갈아 처리할 때, 모든 작업의 완료 시간 합을 구하라.

입력 예시:

3
3 1 2

출력 예시:

라운드로빈(Round Robin)이란?

라운드로빈은 CPU 스케줄링에서 자주 등장하는 방식입니다.
여러 작업을 정해진 시간 단위(여기서는 1)만큼 공평하게 번갈아 처리합니다.

작업 목록: [3, 1, 2]

시간 1: 0번 작업 처리 (3→2)
시간 2: 1번 작업 처리 (1→0) → 완료! (완료 시간 = 2)
시간 3: 2번 작업 처리 (2→1)
시간 4: 0번 작업 처리 (2→1)
시간 5: 2번 작업 처리 (1→0) → 완료! (완료 시간 = 5)
시간 6: 0번 작업 처리 (1→0) → 완료! (완료 시간 = 6)

총 완료 시간 합: 2 + 5 + 6 = 13

풀이 접근 — 수식으로 직접 계산

실제로 한 단위씩 시뮬레이션하면 최악의 경우 O(N × max_task) 시간이 걸립니다.
대신 각 작업이 언제 완료되는지를 수식으로 직접 계산하면 O(N²)에 해결할 수 있습니다.

핵심 공식

i번째 작업의 완료 시간 = commonDisturbTime + frontDisturbTime + 1

각 항의 의미는 다음과 같습니다.

항목	의미
`disturbTime = task[i] - 1`	작업 i가 완료되기 직전까지, 다른 작업들이 끼어들 수 있는 최대 횟수
`commonDisturbTime`	모든 작업 j가 `min(task[j], disturbTime)` 만큼 방해한 시간의 합
`frontDisturbTime`	앞에 있으면서 `task[i]` 이상인 작업들이 마지막 라운드에서 한 번 더 끼어드는 횟수
`+1`	작업 i 본인의 마지막 처리 1회

예시 추적: [3, 1, 2]

0번 작업 (task = 3):

disturbTime = 2
commonDisturbTime = min(3,2) + min(1,2) + min(2,2) = 2+1+2 = 5
frontDisturbTime = 0 (앞에 아무것도 없음)
완료 시간 = 5 + 0 + 1 = 6

1번 작업 (task = 1):

disturbTime = 0
commonDisturbTime = min(3,0) + min(1,0) + min(2,0) = 0
frontDisturbTime = 1 (앞의 3이 1 이상)
완료 시간 = 0 + 1 + 1 = 2

2번 작업 (task = 2):

disturbTime = 1
commonDisturbTime = min(3,1) + min(1,1) + min(2,1) = 1+1+1 = 3
frontDisturbTime = 1 (앞의 3이 2 이상)
완료 시간 = 3 + 1 + 1 = 5

총합: 6 + 2 + 5 = 13

코드

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

public class Main {

    public static void main(String[] args) throws IOException{

        // 라운드로빈 대기시간 합 문제
        // RoundRobin : 공평하게 정해진 시간만큼 번갈아가며 처리하는 알고리즘

        // 3, 1, 2 => 정답은 13
//        시간 1: 0번 (3→2)
//        시간 2: 1번 (1→0) → 완료 (2)
//        시간 3: 2번 (2→1)
//        시간 4: 0번 (2→1)
//        시간 5: 2번 (1→0) → 완료 (5)
//        시간 6: 0번 (1→0) → 완료 (6)

        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));

        StringTokenizer st = new StringTokenizer(br.readLine());
        int n = Integer.parseInt(st.nextToken());

        int[] task = new int[n];
        st = new StringTokenizer(br.readLine());
        for(int i=0; i<n; i++){
            task[i] = Integer.parseInt(st.nextToken());
        }

        int dap = 0;
        // i번째 위치한 작업이, 언제 종료되는지를 계산
        for(int i=0; i<n; i++){
            // 본인 포함하여, 완료 직전까지, 한바퀴씩 돌면서, 방해받는 최소 기준 시간
            int disturbTime = task[i]-1;

            // i번째 작업이, 모든 Task들로부터 방해받는 시간들 계산
            int commonDisturbTime = 0;
            for(int j=0; j<n; j++){
                commonDisturbTime+= Math.min(task[j], disturbTime);
            }

            // i번째 작업이, 본인보다 앞에 있고 & 크거나 같은 작업들로부터, 방해받는 시간들 계산
            int frontDisturbTime = 0;
            for(int j=0; j<i; j++){
                if(task[j] >= task[i]){
                    frontDisturbTime++;
                }
            }

            // i번째 작업이, 방해받아왔던 시간들 + 본인 작업 마무리 1 더해주기
            int totalDisturbTime = commonDisturbTime + frontDisturbTime + 1;
            dap += totalDisturbTime;
        }

        // Test Case Example : 3,1,2
        // 3,1,2에서 첫번째 작업 3은, (하나작은 2기준으로 min했을때 2,1,2 총 다섯번 방해받음) + (3이 제일 앞에 위치해서 앞쪽 방해 없음) + 본인마무리한번 = 5+0+1 = 6걸림.
        // 3,1,2에서 두번째 작업 1은, (하나작은 0기준으로 min했을때 0,0,0 방해 없이 바로 끝남) + (1보다 앞에 큰건 3 한개임) + 본인마무리한번 = 0+1+1 = 2걸림.
        // 3,1,2에서 세번째 작업 2는, (하나작은 1기준으로 min했을때 1,1,1 총 세번 방해받음) + (2보다 앞에 큰건 3 한개임) + 본인마무리한번 = 3+1+1 = 5걸림.
        // 총 걸리는 시간은 6+2+5 = 13

        bw.write(String.valueOf(dap));
        bw.flush();
        bw.close();
    }
}

정리

요소	처리 방법
완료 전 방해 기준	`disturbTime = task[i] - 1`
전체 방해 시간	모든 j에 대해 `min(task[j], disturbTime)` 합산
앞줄 추가 방해	`task[j] >= task[i]`인 앞 작업 카운트
완료 시간 공식	`commonDisturbTime + frontDisturbTime + 1`

i번째 작업이 방해받는 시간을 계산하여 완료 시간을 구하면 됩니다.

[Codility] 그룹화 및 정렬 후 순서 출력하기 (+자릿수 동적 처리)

snapcoder — Sat, 28 Mar 2026 19:11:44 +0900

구현(Simulation) 유형 문제를 복기합니다.
조건을 그대로 코드로 옮기는 구현 문제이지만, 원본 순서 보존과 자릿수 자동 조정 두 가지를 동시에 챙겨야 했던 문제입니다.

문제 유형: 구현(Simulation) — 그룹화 + 정렬 + 포맷 처리

문제 요약

N개의 사진 정보가 주어진다. 각 줄은 파일명, 도시명, 촬영시간 형식이다.
입력 순서를 유지하면서, 각 사진 이름을 도시명 + 도시 내 시간순 번호 + 확장자 형식으로 변환하라.
단, 번호 자릿수는 해당 도시의 사진 수에 맞춰 동적으로 맞춘다.

입력 예시:

photo.jpg, CityA, 2013-09-05 14:08:15
friend.png, CityB, 2015-06-20 15:13:22
sunset.jpg, CityA, 2013-09-05 14:07:13
lake.png, CityC, 2020-01-01 00:00:01
tree.jpeg, CityB, 2015-06-20 15:13:20
mountain.jpg, CityC, 2020-01-01 00:00:02

출력 예시:

CityA2.jpg
CityB2.png
CityA1.jpg
CityC1.png
CityB1.jpeg
CityC2.jpg

풀이 접근

핵심 아이디어는 세 단계입니다.

도시별로 원본 인덱스를 그룹화 — 사진 자체가 아닌 인덱스를 저장해 원본 순서를 보존
도시 내에서 시간순 정렬 — 같은 도시 사진끼리만 Collections.sort로 정렬
자릿수 동적 계산 — 도시 내 사진 수의 자릿수를 구해 %0Nd 포맷으로 번호 생성

자릿수 처리:

도시 사진이  9장 이하 → 1자리 (1, 2, ...)
도시 사진이 10장 이상 → 2자리 (01, 02, ...)
도시 사진이 100장 이상 → 3자리 (001, 002, ...)

핵심 코드

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

public class Main {

    public static void main(String[] args) throws IOException{

        // 사진 이름 수정 문제. (파일명, 도시, 촬영시간)
        // 도시별로 그룹화하고, 같은 도시 내에서 시간순 정렬하고, 1부터 번호 부여한다음, 원래 입력 순서대로 출력하자.

        int n;
        String dap = "";

        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));

        StringBuilder sb = new StringBuilder();
        String line;

        while((line=br.readLine()) != null && !line.isEmpty()){
            sb.append(line).append("\n");
        }
        String[] lines = sb.toString().trim().split("\n");
        n = lines.length;

        // mountain.jpg, Seoul, 2020-01-01 00:00:02
        String[] photos = new String[n];
        String[] exts = new String[n];
        String[] cities = new String[n];
        String[] times = new String[n];

        Map<String, List<Integer>> cityMap = new HashMap<>();
        for(int i=0; i<n; i++){
            String[] parts = lines[i].split(", ");
            photos[i] = parts[0].toString();
            exts[i] = parts[0].toString().substring(parts[0].toString().lastIndexOf(".")+1);
            String city = parts[1].toString();
            cities[i] = city;
            times[i] = parts[2].toString();
            // System.out.println("photo: " + photo + ", ext: " + ext + ", city: " + city + ", time: " + time);

            if(!cityMap.containsKey(city)){
                cityMap.put(city, new ArrayList<Integer>());
            }
            cityMap.get(city).add(i);
        }
//        City: Warsaw
//            Index: 0, Line: photo.jpg, Warsaw, 2013-09-05 14:08:15
//            Index: 2, Line: myFriends.png, Warsaw, 2013-09-05 14:07:13
//            Index: 3, Line: sunset.jpg, Warsaw, 2013-09-05 14:10:00
//        City: Seoul
//            Index: 5, Line: lake.png, Seoul, 2020-01-01 00:00:01
//            Index: 6, Line: mountain.jpg, Seoul, 2020-01-01 00:00:02
//            Index: 7, Line: a.jpg, Seoul, 2020-01-01 00:00:02
//            Index: 8, Line: b.jpg, Seoul, 2020-01-01 00:00:02
//        City: London
//            Index: 1, Line: john.png, London, 2015-06-20 15:13:22
//            Index: 4, Line: tree.jpeg, London, 2015-06-20 15:13:20




        // 각 도시별로 사진 인덱스 리스트를 시간순으로 정렬한 다음, 번호를 붙여서 결과 배열에 저장한다. (2자릿수로 강제 번호 생성)
//        String[] result = new String[n];
//        for(String city : cityMap.keySet()){
//            List<Integer> list = cityMap.get(city);
//            Collections.sort(list, (a,b) -> times[a].compareTo(times[b])); // 같은 도시 내에서, 사진을 시간순으로 정렬
//
//            int cityPhotoCount = list.size();
//            for(int i=0; i<cityPhotoCount; i++){
//                int photoIndex = list.get(i);
//                String printIndex = String.format("%02d", i+1); // 2자리로 맞춰서 번호 생성 (01, 02, ...)
//                // 출력 포맷 : 도시이름 + 번호 + 확장자
//                result[photoIndex] = city + printIndex + "." + exts[photoIndex];
//            }
//        }

        // 각 도시별로 사진 인덱스 리스트를 시간순으로 정렬한 다음, 번호를 붙여서 결과 배열에 저장한다. (유동적인 번호 생성)
        String[] result = new String[n];
        for(String city : cityMap.keySet()){
            List<Integer> list = cityMap.get(city);
            Collections.sort(list, (a,b) -> times[a].compareTo(times[b])); // 같은 도시 내에서, 사진을 시간순으로 정렬

            int cityPhotoCount = list.size();
            int digit = String.valueOf(cityPhotoCount).length(); // 10장이면 2자릿수, 100장이면 3자릿수, ...
            for(int i=0; i<cityPhotoCount; i++){
                int photoIndex = list.get(i);
                String printIndex = String.format("%0" + digit + "d", i+1); // 2자리로 맞춰서 번호 생성 (01, 02, ...)
                // 출력 포맷 : 도시이름 + 번호 + 확장자
                result[photoIndex] = city + printIndex + "." + exts[photoIndex];
            }
        }

        dap = String.join("\n", result);

        bw.write(dap);
        bw.flush();
        bw.close();
    }
}

고민했던 포인트

원본 순서를 어떻게 보존할까?

처음에는 사진 객체를 정렬하면 원본 인덱스가 사라진다는 점을 놓쳤습니다.
인덱스를 따로 저장하고, 결과를 result[원본인덱스]에 쓰는 방식으로 해결했습니다.

자릿수를 왜 하드코딩하면 안 될까?

처음 작성 시 %02d로 고정했는데, 도시 사진이 100장 이상이면 099, 100이 섞여 오답이 됩니다.
String.valueOf(list.size()).length()로 자릿수를 동적으로 계산해야 모든 케이스를 커버합니다.

도시 사진 수	고정 `%02d`	동적 처리
9장	`01`~`09` ✅	`1`~`9` ✅
10장	`01`~`10` ✅	`01`~`10` ✅
100장	`01`~`100` ❌	`001`~`100` ✅

시간 파싱 없이 정렬 가능한가?

2020-01-01 00:00:02 형식은 문자열 사전순 정렬이 시간순 정렬과 동일합니다.
Date 파싱 없이 times[a].compareTo(times[b])만으로 충분합니다.

정리

요소	처리 방법
도시별 그룹화	`HashMap<String, List<Integer>>` — 인덱스 저장
시간순 정렬	`Collections.sort` + 문자열 비교
자릿수 맞춤	`String.valueOf(size).length()` → `%0Nd`
원본 순서 보존	`result[원본인덱스]`에 직접 저장

HashMap으로 그룹화하고, 인덱스를 기준으로 결과를 역추적하는 패턴으로 해결.

[Codility] 자릿수 합이 N인 가장 작은 수 (#Greedy)

snapcoder — Sat, 28 Mar 2026 17:36:24 +0900

[Codility] 자릿수 합이 N인 가장 작은 수 (#Greedy)

그리디 알고리즘 문제를 복기합니다.
처음엔 단순해 보였지만, 히든 테스트케이스에서 꼼꼼하게 생각하게끔 만드는 문제입니다.

문제 요약

양의 정수 N이 주어졌을 때, 각 자릿수의 합이 N이 되는 가장 작은 자연수를 구하시오.

예시:

N = 9 → 9
N = 10 → 19 (1+9=10, 최솟값)
N = 18 → 99 (9+9=18)
N = 20 → 299 (2+9+9=20)

풀이 접근: Greedy

핵심 아이디어는 두 가지입니다.

자릿수 합을 빠르게 채우려면 9를 최대한 써야 한다.
9보다 작은 숫자를 여러 자리에 쪼개면 자리수가 늘어나서 수가 커집니다.
수를 최소로 만들려면 나머지를 가장 앞자리에 배치해야 한다.
예) N=20: 9,9,2 순서면 992, 2,9,9 순서면 299 → 앞자리가 작아야 전체 수가 작아집니다.

정리하면:

몫 = N / 9    → 9를 몫 개 만큼 이어 붙임
나머지 = N % 9  → 나머지가 0이 아니면 맨 앞에 배치

코드

// N을 9로 나눈 몫·나머지로 분해해, 나머지를 앞에 배치하는 Greedy 처리로 자릿수 최소화 문제 해결
public static void main(String[] args) throws IOException {

    BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
    BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(System.out));

    int n = Integer.parseInt(new StringTokenizer(br.readLine()).nextToken());
    String dap;

    if (n == 0) {
        // 입력이 0이면 답은 0
        dap = "0";
    } else if (n < 10) {
        // 9 이하면 자기 자신이 가장 작은 수
        dap = String.valueOf(n);
    } else {
        int mok  = n / 9;
        int rest = n % 9;

        StringBuilder sb = new StringBuilder();

        // 나머지가 0이 아닐 때만 맨 앞에 추가(히든 케이스: rest=0이면 앞에 0이 붙어 오답)
        if (rest != 0) sb.append(rest);

        // 9를 몫 개 만큼 뒤에 붙임
        for (int i = 0; i < mok; i++) sb.append(9);

        dap = sb.toString();
    }

    bw.write(dap + "\n");
    bw.flush();
    bw.close();
}

히든 테스트케이스 — 나머지가 0일 때

처음 작성 시 rest가 0이어도 무조건 앞에 붙였더니 N=18에서 099가 출력되는 문제가 있었습니다.

if (rest != 0) 조건을 추가해야 선행 0 없이 정상 출력됩니다.

N	몫	잘못된 출력	올바른 출력
9	1	`09` ❌	`9` ✅
18	2	`099` ❌	`99` ✅
27	3	`0999` ❌	`999` ✅

정리

조건	처리
N = 0	`"0"` 반환
N < 10	N 그대로 반환
N ≥ 10	나머지(있을 때만) + 9 × 몫

Greedy 알고리즘의 핵심은 매 순간 최선의 선택을 하는 것입니다.
이 문제에서는 "가장 큰 한 자리 숫자(9)를 최대한 쓰고, 남은 나머지를 앞에 두면 항상 최솟값"으로 해결할 수 있습니다.

[Index] 복합 인덱스 적용기: 트리 구조 개념부터 실전 적용까지

snapcoder — Wed, 25 Mar 2026 23:20:50 +0900

오늘은, 데이터를 조회하는 쿼리에 복합 인덱스를 추가하면서,

인덱스가 어떤 원리로 동작하는지 다시 한번 정리했습니다.

배경: 인덱스 없이 조회하면 어떻게 될까?

아래 예시는 조회 쿼리의 WHERE 절입니다.

WHERE (use_yn != 'N' OR created_at::date = CURRENT_DATE - 1)
  AND (created_at IS NULL OR created_at::date >= CURRENT_DATE - 1)

인덱스가 없으면 PostgreSQL은 Sequential Scan(Seq Scan) 을 수행합니다.
테이블의 모든 행을 첫 줄부터 끝까지 읽으며 조건을 하나씩 확인하는 방식입니다.

데이터가 100건이면 100번, 1만 건이면 1만 번 읽습니다.

데이터가 적을 때는 문제없지만, 쌓일수록 응답 속도가 그만큼 느려집니다.

그런데, 인덱스는 내부적으로 어떻게 동작할까?

인덱스가 빠른 이유를 이해하려면 그 내부 구조를 알아야 합니다.
MySQL(InnoDB), PostgreSQL, Oracle 등 대부분의 RDB는 인덱스 자료구조로 B+Tree를 사용합니다.
트리 계열의 자연스러운 발전 과정으로 나온 구조입니다. 흐름을 따라가 보겠습니다.

Tree (트리)

부모-자식 관계로 이어진 계층 구조입니다. 파일 시스템의 디렉토리 구조가 대표적인 예입니다.

Binary Tree (이진 트리)

각 노드가 최대 2개의 자식을 갖는 트리입니다. 구조 제약만 있을 뿐, 값의 정렬 규칙은 없습니다.

Binary Search Tree (이진 탐색 트리, BST)

왼쪽 자식 < 부모 < 오른쪽 자식 규칙을 지키는 이진 트리입니다. 탐색 시 절반씩 범위를 줄여나가므로 이론상 O(log n)이지만, 데이터가 편향 삽입되면 한쪽으로 치우쳐 최악 O(n)이 됩니다.

B-Tree (Balanced Tree)

BST의 편향 문제를 해결한 구조입니다. 노드 하나에 여러 키를 담고, 삽입/삭제 시 자동으로 균형을 맞춥니다. 루트에서 모든 리프까지의 높이가 동일하게 유지됩니다.

B+Tree

B-Tree의 변형으로, 실제 데이터(또는 포인터)는 리프 노드에만 저장되고 내부 노드는 탐색 경로 역할만 합니다. 리프 노드끼리 링크드 리스트로 연결되어 있어 범위 조회(>=, BETWEEN)에 매우 유리합니다.

PostgreSQL의 기본 인덱스 타입이 B+Tree입니다. CREATE INDEX 시 별도 타입을 지정하지 않으면 자동으로 B+Tree가 적용됩니다.

복합 인덱스 적용

인덱스 생성

-- (use_yn, created_at) 복합 인덱스 생성으로,
-- use_yn 필터와 created_at 범위 조건을 인덱스 단계에서 함께 처리해 Seq Scan 제거
CREATE INDEX IF NOT EXISTS idx_sample_use_yn_created_at
    ON sample_table(use_yn, created_at);

동작 원리

복합 인덱스 (use_yn, created_at)은 내부적으로 다음과 같이 정렬된 B+Tree를 구성합니다.

use_yn = 'Y', created_at = 2026-03-01
use_yn = 'Y', created_at = 2026-03-15
use_yn = 'Y', created_at = 2026-04-30
use_yn = 'N', created_at = 2026-01-10   ← 쿼리 플래너가 이 구간은 읽지 않음
use_yn = 'N', created_at = 2026-02-28   ← 마찬가지

쿼리에 use_yn != 'N' 조건이 있으면, 플래너는 use_yn = 'Y' 구간만 스캔합니다.
use_yn = 'N'인 행들은 인덱스 레벨에서 아예 건너뜁니다.

이후 created_at >= CURRENT_DATE - 1 조건도 인덱스 내 정렬된 순서를 이용해 범위 스캔(Index Range Scan)으로 처리합니다.

Seq Scan과 비교

항목	Seq Scan	Index Range Scan
읽는 행 수	테이블 전체	조건에 맞는 범위만
use_yn = 'N' 행	전부 읽고 버림	아예 접근 안 함
범위 조건 처리	조건마다 전체 재탐색	정렬된 B+Tree에서 이진 탐색

실제로 얼마나 빨라졌나?

수천 건 이하 규모에서는 체감 속도 차이를 측정하기 어렵습니다.
PostgreSQL은 테이블이 작으면 인덱스를 타는 비용보다 전체를 한 번에 읽는 Seq Scan이 더 빠르다고 판단해 인덱스를 아예 무시하기도 합니다.

일반적으로 다음 기준이 통용됩니다.

1만 건 미만: Seq Scan과 차이 없음. 플래너가 인덱스를 무시할 수 있음
1만 ~ 10만 건: 인덱스 효과가 나타나기 시작. 조건 선택도가 높을수록 유리
10만 건 이상: 인덱스 유무가 응답 속도에 직접적인 영향을 줌

이번 적용의 핵심은, 당장의 속도 개선은 미미하겠지만 탐색 구조의 개선입니다.

이전: 데이터가 늘수록 조회 비용이 선형으로 증가
이후: 조건에 맞는 범위만 스캔, 데이터가 늘어도 불필요한 행을 읽지 않음

지금은 나중을 대비한 사전 최적화입니다.

심화: 인덱스, 어떤 컬럼으로 어떤 순서로 잡아야 할까?

인덱스를 걸기로 했다면 이제 두 가지 질문이 남습니다. 어떤 컬럼에, 어떤 순서로 걸 것인가.

어떤 컬럼에 걸어야 할까?

두 가지 조건을 함께 보면 됩니다.

① WHERE절에 자주 등장하는 컬럼 — 인덱스를 타려면 일단 조건에 있어야 합니다.

② 그 중에서 카디널리티(Cardinality)가 높은 컬럼 — 카디널리티란 컬럼이 가질 수 있는 값의 종류 수입니다. 값의 종류가 많을수록 인덱스로 걸러낼 수 있는 행이 많아집니다.

컬럼	WHERE 등장 빈도	카디널리티	인덱스 효과
`use_yn`	항상	낮음 (Y/N 2가지)	약함
`user_id`	자주	높음 (수만 가지)	강함
`created_at`	자주	높음 (날짜별 다양)	강함

따라서 use_yn 단독 인덱스는 효과가 거의 없습니다. Y/N 두 가지뿐이라 절반밖에 걸러내지 못하기 때문입니다.
대신 (use_yn, created_at) 복합 인덱스처럼 카디널리티 낮은 컬럼(등호 조건) + 카디널리티 높은 컬럼(범위 조건) 조합이 실전에서 가장 많이 쓰이는 패턴입니다.

추가로 고려할 기준:

= 조건 컬럼을 먼저, 범위(>=, BETWEEN) 조건 컬럼을 나중에 두는 것이 기본 전략입니다.
ORDER BY에 사용되는 컬럼도 인덱스에 포함하면 정렬 비용을 줄일 수 있습니다.

복합 인덱스에서 순서가 중요한 이유

복합 인덱스 (A, B)와 (B, A)는 완전히 다르게 동작합니다.

B+Tree는 첫 번째 컬럼 기준으로 먼저 정렬되기 때문에, 쿼리에서 첫 번째 컬럼을 조건으로 사용하지 않으면 인덱스 자체를 타지 못합니다.

-- 인덱스: (use_yn, created_at)

WHERE use_yn = 'Y' AND created_at >= '2026-01-01'  -- ✅ 인덱스 정상 사용
WHERE created_at >= '2026-01-01'                    -- ❌ 첫 컬럼 빠짐 → 인덱스 무시될 수 있음
WHERE use_yn = 'Y'                                  -- ✅ 첫 컬럼만 있어도 사용 가능

이를 선두 컬럼 원칙(Leftmost Prefix Rule) 이라고 합니다. 인덱스를 설계할 때 "어떤 컬럼이 항상 조건에 포함되는가"를 먼저 파악하고, 그 컬럼을 앞에 두는 것이 핵심입니다.

인덱스가 오히려 독이 되는 경우

인덱스는 조회 성능을 높이는 대신 쓰기 비용을 높입니다. INSERT, UPDATE, DELETE 가 발생할 때마다

인덱스도 함께 갱신해야 하기 때문입니다.

쓰기가 매우 잦은 테이블에 인덱스를 과도하게 걸면 오히려 전체 성능이 저하될 수 있습니다.
카디널리티가 낮은 컬럼(예: status 컬럼에 값이 2~3가지뿐)에 단독 인덱스를 걸면 효과가 거의 없습니다.
인덱스가 많을수록 쿼리 플래너가 최적 경로를 고르는 비용도 늘어납니다.

인덱스는 많이 걸수록 좋은 게 아니라, 필요한 곳에 정확히 걸어야 합니다.

마무리

이번 케이스처럼 WHERE 절에 자주 등장하는 컬럼 조합을 복합 인덱스로 구성하면,

데이터가 쌓여도 쿼리 비용이 급격히 늘어나는 것을 방지할 수 있습니다.

작을 때 만들어두는 인덱스가, 나중에 가장 값진 한 줄이 되기를.

[JVM] Heap 구조 뜯어보기: new 한 줄이 메모리에서 벌어지는 일

snapcoder — Tue, 17 Mar 2026 20:17:05 +0900

이전 글에서 부하테스트를 주제로 포스팅하면서 JVM Heap 구조를 간략히 언급했는데,

이번에는 JVM 자체를 한 번 깊게 다뤄보고자 합니다.

2026.03.16 - [IT/java|Spring] - [부하테스트] JMeter Ramp-up부터 JVM Heap 최적화까지: 서버 성능 개선기

[부하테스트] JMeter Ramp-up부터 JVM Heap 최적화까지: 서버 성능 개선기

배경여러 서비스를 운영하면서 공통 질문이 생겼습니다. "POD 한 대가 실제로 얼마나 버틸 수 있는가?"부하테스트를 준비하던 중, 검증계·운영계 모두 JVM Heap이 Pod 메모리와 맞지 않게 설정되어

snapcode.tistory.com

알고 있다고 생각하면서도, 막상 설명하려면 막히는 내용 이기도 합니다.

이미 알고 계신 분께는 복습이, 처음 접하시는 분께는 새로운 발견이 되길 바랍니다.

배경

이전 글에서 JVM Heap을 Pod 메모리의 75%로 조정하는 최적화를 다뤘습니다. 그 과정에서 "Heap 안에 Young Generation, Eden, Survivor, Old Generation이 있다"는 내용을 언급했는데, 이번 글에서는 그 구조를 객체의 생애주기 흐름으로 풀어보겠습니다.

new Object()를 호출하는 순간, 그 객체는 JVM 메모리 안에서 어떻게 되는지 살펴보겠습니다.

JVM 메모리 전체 구성

먼저 전체 그림부터 짚고 넘어갑니다.

# JVM 프로세스 메모리 구성 (4,096 MiB Pod 기준)
│
├─ Heap Memory                    2,048 MiB  ← -Xms(초기 크기) / -Xmx(최대 크기) 로 제어
│   ├─ Young Generation                      ← -XX:NewSize / -XX:MaxNewSize 로 제어
│   │   │                                      (새로 생성된 객체가 최초로 할당되는 영역)
│   │   ├─ Eden Space                          (새 객체 최초 할당 공간, 꽉 차면 Minor GC 트리거)
│   │   └─ Survivor Space                      (Minor GC 후 살아남은 객체 임시 보관)
│   │       ├─ From (S0)
│   │       └─ To   (S1)
│   └─ Old Generation                          (오래 살아남은 객체 저장, Full GC 대상)
│
├─ Non-Heap Memory
│   ├─ Metaspace              ~256 MiB         (클래스 메타데이터 저장 / Java 8 이전의 Permanent Generation에 해당)
│   └─ Code Cache              ~64 MiB         (JIT 컴파일된 코드 저장으로, 반복 실행 성능 향상)
│
└─ 기타 JVM 프로세스 메모리
    ├─ Thread Stack            ~200 MiB         (스레드 200개 × 1 MiB, 각 스레드의 호출 스택)
    ├─ Direct Memory           ~128 MiB         (NIO/Netty 버퍼 처리로, GC 범위 밖에서 I/O 성능 확보)
    ├─ GC 내부 구조             ~50 MiB
    ├─ OpenTelemetry Agent     ~256 MiB         (APM 계측 오버헤드 처리로, 트레이싱 비용 상시 발생)
    ├─ OS 버퍼                 ~100 MiB
    └─ 여유                    ~994 MiB
                               ─────────
                               4,096 MiB

< 이해를 한층 두껍게 해주는, 용어 풀이 >
* MiB : Mebibyte. 1 MiB = 1,024 KiB = 약 1MB. 메모리 단위
* Pod : Kubernetes에서 컨테이너를 실행하는 최소 단위. 서버 인스턴스 1개라고 이해하면 됨
* Heap Memory : JVM이 객체를 저장하는 주 메모리 공간. GC가 관리
* Xms : X memory start. JVM 시작 시 초기 Heap 크기
* Xmx : X memory maximum. JVM이 사용할 수 있는 최대 Heap 크기
* Young Generation : 새로 생성된 객체가 할당되는 Heap 영역. Minor GC 대상
* XX:NewSize / XX:MaxNewSize : Young Generation 크기를 제어하는 JVM 옵션
* Eden Space : 객체가 처음 생성되어 할당되는 공간. 에덴동산에서 유래
* Minor GC : Young Generation이 꽉 찼을 때 발생하는 빠른 가비지 컬렉션
* GC : Garbage Collection. 더 이상 참조되지 않는 객체를 자동으로 메모리에서 제거하는 과정
* Survivor Space : Minor GC에서 살아남은 객체를 임시 보관하는 공간
* From (S0) / To (S1) : Survivor의 두 칸. 항상 한 칸은 비워두고 살아남은 객체를 번갈아 복사
* Old Generation : Survivor를 여러 번 살아남은 객체가 승격되는 영역. Full GC 대상
* Full GC : Heap 전체를 대상으로 하는 무거운 GC. 실행 중 애플리케이션이 잠깐 멈춤(STW)
* STW : Stop-The-World. Full GC 실행 중 모든 애플리케이션 스레드가 일시 정지되는 현상
* Non-Heap Memory : Heap 외 JVM이 사용하는 메모리. GC 대상이 아님
* Metaspace : 클래스 구조·메서드 정보 등 메타데이터를 저장하는 영역. Java 8부터 PermGen 대체
* Permanent Generation (PermGen) : Java 7 이하에서 클래스 메타데이터를 저장하던 고정 크기 영역. Java 8부터 Metaspace로 교체
* Code Cache : JIT 컴파일러가 변환한 기계어 코드를 저장해두는 영역
* JIT : Just-In-Time 컴파일러. 자주 실행되는 코드를 런타임에 기계어로 번역해 성능 향상
* Thread Stack : 각 스레드마다 독립적으로 갖는 호출 스택. 메서드 호출 순서·지역변수 저장
* Direct Memory : GC 범위 밖에서 OS와 직접 통신하는 메모리 버퍼
* NIO : Non-blocking I/O. 블로킹(응답 올때까지 기다리는 것) 없이 I/O를 처리하는 Java 표준 API
* Netty : NIO 기반의 고성능 네트워크 프레임워크. Direct Memory를 활용해 대용량 I/O 처리
* OpenTelemetry Agent : 분산 트레이싱·메트릭·로그를 자동 계측하는 Java Agent. -javaagent 옵션으로 JVM에 부착
* APM : Application Performance Monitoring. 응답시간·처리량·에러율 등을 실시간 수집·시각화하는 모니터링 체계
* OS 버퍼 : 운영체제가 소켓·파일 I/O 처리를 위해 사용하는 커널 레벨 메모리

우선 크게 세가지 영역으로 나뉩니다.

Heap : 객체가 살고 죽는 공간. GC의 주 무대
Non-Heap : 클래스 정보·JIT 코드 저장. GC 대상이 아님
기타 : 스레드·I/O·에이전트 등 JVM 프로세스 운영에 필요한 나머지 메모리

Heap — 객체의 생애주기

태어난걸 축하해

1단계 : 탄생 — Eden Space

new Object()를 호출하면 객체는 Eden Space에 할당됩니다.

"Eden" 이라는 이름은 성경의 에덴동산(Garden of Eden)에서 유래했습니다. 새로 태어난 생명(객체)이 처음 머무는 곳이라는 의미입니다. 대부분의 객체는 이곳에서 짧게 살다가 사라집니다. 요청 하나를 처리하면서 만들어진 임시 객체들, 루프 안에서 생성된 문자열 등이 대표적입니다.

Eden이 꽉 차면 Minor GC가 트리거됩니다. 이 시점에 JVM은 Eden에 있는 객체를 전수 검사합니다.

더 이상 참조되지 않는 객체 → 즉시 제거
아직 참조 중인 객체 → Survivor Space로 이동

에덴동산이 꽉찼어. 정리하자.

2단계 : 생존 — Survivor Space (From / To)

Survivor Space는 From(S0) 과 To(S1) 두 칸으로 나뉩니다. 언뜻 보면 왜 두 칸인지 의아할 수 있는데, Minor GC 동작 방식 때문입니다.

# Minor GC 발생 시 Survivor 동작 흐름

[Minor GC 전]
  Eden   : 객체 가득 참
  From   : 이전 GC에서 살아남은 객체들 존재
  To     : 비어있음

[Minor GC 실행]
  1. Eden + From에서 살아있는 객체를 To로 복사
  2. 복사 시 각 객체의 age(생존 횟수) += 1
  3. Eden + From 전체를 비움

[Minor GC 후]
  Eden   : 비어있음
  From   : 비어있음  ← 역할이 뒤바뀜 (기존 To가 새로운 From)
  To     : 비어있음  ← 다음 GC를 위해 항상 한 칸은 비워둠

핵심은 항상 한 칸(To)은 비어있어야 한다는 것입니다. 살아있는 객체를 한쪽에서 다른 쪽으로 통째로 복사하는 방식(Copying GC)을 쓰기 때문입니다. 덕분에 메모리 단편화 없이 빠르게 정리할 수 있습니다. GC가 끝나면 From과 To의 역할은 뒤바뀝니다.

* 단편화란? 메모리 곳곳에 작은 빈 공간이 흩어져서, 전체 여유는 있는데 막상 큰 객체를 넣을 자리가 없는 상태

실버타운으로 모셔드릴께요.

3단계 : 승격 — Old Generation

Minor GC를 거칠 때마다 살아남은 객체의 age(나이) 가 1씩 증가합니다. age가 임계값(기본 15)에 도달하면 Old Generation으로 승격(Promotion) 됩니다.

Old Generation에는 오랫동안 살아남은 객체들이 모입니다. 캐시, 싱글톤, DB 커넥션 풀 등이 대표적입니다. Old Generation이 꽉 차면 Full GC가 발생합니다.

Full GC는 Minor GC보다 훨씬 무겁습니다. Heap 전체를 스캔하고, 그 동안 Stop-the-World(STW) — 즉 애플리케이션이 잠깐 멈춥니다. 응답 지연 스파이크의 주원인 중 하나 입니다.

# 객체 생애주기 요약

new Object()
    ↓
 Eden Space  →  (Minor GC 탈락)  →  소멸
    ↓ 살아남음
 Survivor (From ↔ To 반복)
    ↓ age >= 15
 Old Generation  →  (Full GC 탈락)  →  소멸

Non-Heap — 코드와 클래스의 공간

Metaspace

클래스 정의(메서드 목록, 필드 정보, 어노테이션 등)가 저장됩니다. Java 8 이전에는 Permanent Generation(PermGen) 이라는 고정 크기 영역에 저장했는데, 클래스가 많아지면 java.lang.OutOfMemoryError: PermGen space 에러가 잦았습니다. Java 8부터 Metaspace로 교체되면서, Native 메모리 영역으로 이동, 필요에 따라 자동 확장됩니다.

매번 한줄씩 읽기 힘들어. 기계어로 번역해서 저장해두자.

Code Cache

JVM은 처음에 소스코드(.java) → 바이트코드(.class) → JVM이 한 줄씩 해석(인터프리터) → 실행하다가,

자주 호출되는 코드를 감지하면 JIT(Just-In-Time) 컴파일러가 기계어로 변환해 Code Cache에 저장합니다. 이후 해당 코드는 변환 없이 바로 실행되어 성능이 향상됩니다. => 이게 부하테스트에서 Ramp-up이 중요한 이유와도 연결됨!

* 실무에서 자주 JIT에 올라가는 것들:
- HTTP 요청마다 호출되는 핵심 비즈니스 로직
- 루프 안에서 반복 실행되는 코드
- 자주 쓰는 유틸 메서드 (날짜 변환, 문자열 처리 등)
- 프레임워크 내부 코드 (Spring의 DispatcherServlet 등)

기타 JVM 프로세스 메모리

Heap·Non-Heap 외에도 JVM 프로세스는 추가 메모리를 사용합니다.

영역	설명
Thread Stack	각 스레드마다 독립적으로 가지는 호출 스택. 스레드 200개 × 1 MiB ≈ 200 MiB
Direct Memory	NIO/Netty가 GC 범위 밖에서 직접 관리하는 버퍼 메모리. I/O 성능 확보에 사용
GC 내부 구조	GC 알고리즘이 참조 추적·카드 테이블 관리 등에 사용하는 내부 메모리
OpenTelemetry Agent	-javaagent로 부착된 APM 계측 오버헤드. 트레이싱 비용 상시 발생 (~256 MiB)
OS 버퍼	OS 레벨 소켓·파일 I/O 버퍼

Reserved vs Committed

JVM 메모리를 이야기할 때 자주 등장하는 두 개념입니다.

Reserved : OS에 주소 공간만 예약해둔 상태. 실제 RAM은 미사용
Committed : 실제 RAM에 매핑된 상태. 실제로 사용 중

예) -Xmx3072m 설정 시 JVM은 3,072 MiB를 Reserved로 잡아두고 => 객체가 쌓이면서 점진적으로 Committed로 전환합니다. Heap뿐 아니라 Metaspace 등 Non-Heap 영역도 동일한 방식으로 동작합니다.

정리

new Object() → Eden Space 할당 (에덴동산: 새 생명이 태어나는 곳)
Eden이 꽉 차면 Minor GC 트리거 → 살아남은 객체는 Survivor Space 이동(From ↔ To)
From/To는 항상 한 칸이 비어있어야 Copying GC 방식으로 단편화 없이 정리 가능
age >= 15 → Old Generation 승격 → Full GC 대상
Non-Heap(Metaspace·Code Cache)은 GC 대상이 아닌 클래스 정보·JIT 코드 저장 공간
Reserved(예약) → Committed(실제 사용) 전환 방식으로 메모리 효율 확보

마치며

JVM 메모리 구조를 알고 나면, -Xmx 하나 건드릴 때도 "왜 이 값인가" 를 설명 할 수 있게 됩니다.

Pod 메모리 안에서 Heap과 Non-Heap이 어떻게 나뉘는지 감이 오셨으면 좋겠습니다.

실무 업무 하시면서, 메모리 설정값을 자신있게 건드려 보시길 바랍니다.

[부하테스트] JMeter Ramp-up부터 JVM Heap 최적화까지: 서버 성능 개선기

snapcoder — Tue, 17 Mar 2026 01:46:54 +0900

배경

여러 서비스를 운영하면서 공통 질문이 생겼습니다. "POD 한 대가 실제로 얼마나 버틸 수 있는가?"

부하테스트를 준비하던 중, 검증계·운영계 모두 JVM Heap이 Pod 메모리와 맞지 않게 설정되어 있다는 것을 발견했습니다. Heap을 먼저 바로잡고 테스트를 진행했으며, 이 글은 그 과정 전체를 정리합니다.

JVM Heap 최적화: 인수인계 시점부터 고정되어 있던 잘못된 설정을 발견 및 개선
부하테스트: 최적화 이후 실제 성능을 데이터로 검증

JVM Heap 최적화

문제 발견

부하테스트 준비 중 Heap 설정을 살펴보다 이상한 점을 발견했습니다. 인수인계 시점부터 검증계·운영계 모두 Xms=Xmx=2048m으로 고정되어 있었는데, 환경별 Pod 메모리와 맞지 않는 설정이었습니다. 초기 개발 시 놓친 부분으로 판단했습니다.

검증계 (Pod 2 GiB): Heap 2,048m → Non-Heap 영역 여유 없음 → OOM 위험
운영계 (Pod 4 GiB): Heap 2,048m → 나머지 2 GiB가 활용되지 않는 상태

[ 검증계 ]                          [ 운영계 ]
Pod 메모리:  2 GiB (2,048 MiB)      Pod 메모리:  4 GiB (4,096 MiB)
JVM Heap:   2 GiB (2,048 MiB)      JVM Heap:   2 GiB (2,048 MiB)
차이:        0  ← Non-Heap 여유 없음  차이:        2 GiB ← Heap이 절반만 활용

할당된 자원 내 최적화 요청 (비용 변동x)

Non-Heap 영역이란?

JVM 프로세스는 Heap 외에도 Non-Heap 영역을 상당량 사용합니다.

JVM 프로세스 메모리 구성 (4,096 MiB Pod 기준)
│
├─ Heap Memory                    2,048 MiB  ← -Xms(초기 크기) / -Xmx(최대 크기) 로 제어
│   ├─ Young Generation                      ← -XX:NewSize / -XX:MaxNewSize 로 제어
│   │   │                                      (새로 생성된 객체가 최초로 할당되는 영역)
│   │   ├─ Eden Space                          (새 객체 최초 할당 공간, 꽉 차면 Minor GC 트리거)
│   │   └─ Survivor Space                      (Minor GC 후 살아남은 객체 임시 보관)
│   │       ├─ From (S0)
│   │       └─ To   (S1)
│   └─ Old Generation                          (오래 살아남은 객체 저장, Full GC 대상)
│
├─ Non-Heap Memory
│   ├─ Metaspace              ~256 MiB         (클래스 메타데이터 저장 / Java 8 이전의 Permanent Generation에 해당)
│   └─ Code Cache              ~64 MiB         (JIT 컴파일된 코드 저장으로, 반복 실행 성능 향상)
│
└─ 기타 JVM 프로세스 메모리
    ├─ Thread Stack            ~200 MiB         (스레드 200개 × 1 MiB, 각 스레드의 호출 스택)
    ├─ Direct Memory           ~128 MiB         (NIO/Netty 버퍼 처리로, GC 범위 밖에서 I/O 성능 확보)
    ├─ GC 내부 구조             ~50 MiB
    ├─ OpenTelemetry Agent     ~256 MiB         (APM 계측 오버헤드 처리로, 트레이싱 비용 상시 발생) ← 중요
    ├─ OS 버퍼                 ~100 MiB
    └─ 여유                    ~994 MiB
                               ─────────
                               4,096 MiB

특히 분산 추적(Trace), 메트릭, 로그를 자동 계측해서 백엔드로 전송하기 위한,

OpenTelemetry Agent 오버헤드(~256 MiB)가 예상보다 크며, 이를 무시하면 OOM 위험이 있습니다.

자세한 JVM 내용은, 다음 컨텐츠에서 다룹니다.

2026.03.17 - [IT/java|Spring] - [JVM] new 한 줄이 메모리에서 벌어지는 일: JVM 힙 구조 뜯어보기

JVM

snapcode.tistory.com

개선 방향

Xms (X memory start) : JVM 시작 시 초기 Heap 크기
Xmx (X memory maximum) : JVM이 사용할 수 있는 최대 Heap 크기
둘이 다르면 트래픽 증가 시 Heap이 동적으로 확장되며 그 과정에서 응답 지연 발생 → Xms = Xmx로 고정해 처음부터 최대 메모리를 확보
Xms = Xmx 고정 → 런타임 중 Heap 확장 없음 → 응답 지연 방지 (성능 최우선 옵션 채택)
Heap = Pod 메모리의 75% 수준으로 조정
나머지 25% → Non-Heap 영역(Metaspace, Thread Stack, OTel 등) 확보 → OOM 방지

# Heap을 Pod 메모리의 75%로 설정해 Non-Heap 영역 OOM 방지 처리로, 서비스 안정성 강화

# STG (검증계): Pod 2 GiB
env:
  - name: JAVA_OPTS
    value: "-Xms1536m -Xmx1536m"   # 2,048 MiB × 75% ≈ 1,536 MiB

# PRD (운영계): Pod 4 GiB
env:
  - name: JAVA_OPTS
    value: "-Xms3072m -Xmx3072m"   # 4,096 MiB × 75% ≈ 3,072 MiB

환경	Pod 메모리	변경 전 Heap	변경 후 Heap	방향
STG (검증계)	2 GiB	2,048m	1,536m	하향 (부하테스트에서 검증 완료)
PRD (운영계)	4 GiB	2,048m	3,072m	상향 (성능 개선)

부하테스트

Heap 최적화 이후, 실제 성능을 데이터로 검증하기 위해 부하테스트를 진행했습니다.

테스트 목표

단일 POD 기준 최대 TPS는 얼마인가?
목표 TPS 달성을 위한 POD 구성(수평 확장) 기준 수립
현재 인프라 자원이 과소/과도하게 설정되어 있지는 않은가?

테스트 설계

서비스별로 스펙과 트래픽 패턴이 다르기 때문에, 아래 기준을 공통으로 적용했습니다.

항목	기준
베이스라인 POD 사양	1 vCore / 2 GiB (서비스 공통)
POD 수 변화	1개 → 2개 → 4개
동시 유저 수	100 / 200 / 400 또는 100 / 500 / 1,000 (서비스별 상이)
부하 증가 방식	Ramp-up (period: 60s, duration: 300s)

유저 수 상한은 서비스별로 다르게 설정했으며, 최대 응답시간이 10초를 초과하는 구간부터는 서비스 관점에서 의미 없다고 판단해 진행을 제외했습니다.

Ramp-up — 60초

테스트 시작 시 유저 수를 한번에 올리지 않고, 설정 시간 동안 점진적으로 증가시키는 방식
예) 동시 유저 100명 / Ramp-up 60초 → 6초마다 약 10명씩 추가, 60초 시점에 100명 도달
처음부터 최대 부하를 주면 서버가 워밍업되지 않아 초반 수치가 왜곡되므로, 서버가 안정된 이후의 실제 성능을 측정하기 위해 60초로 설정

Duration — 300초(5분)

Ramp-up이 끝난 이후 실제 부하를 유지하는 시간
Ramp-up 60초 완료 후 61초~360초까지 300초간 부하 유지 → 전체 테스트 시간 360초
184 TPS 기준 300초면 약 55,000건 수집 → 샘플이 적으면 응답 지연 수치가 왜곡될 수 있어 신뢰할 수 있는 수치 확보를 위해 300초로 설정

테스트 시나리오

전일자 실데이터 기반 구성 — 실제 요청 파라미터 그대로 사용, 현실적인 분포 반영을 위해 중복 요청 의도적 포함
샘플 데이터 종류: 약 20,000여 개

동일 시나리오 반복 실행

각 유저 수 구간마다 동일한 시나리오를 3회 반복 실행
1회 결과만으로는 네트워크 지연·서버 상태 등 일시적 변수 배제 어려움
3회 반복 → 수치의 재현성 확인, 해당 스펙에서의 실제 성능임을 검증

성능 테스트 결과

P95 / P99 — 전체 요청 중 빠른 순서로 95% / 99% 지점의 응답시간. P95가 700ms라면 100건 중 95건은 700ms 이내 응답. 평균보다 느린 요청까지 반영한 체감 응답시간 지표입니다.

100 User — 단일 POD

시나리오	POD	TPS	평균(ms)	P95(ms)	P99(ms)	에러율
#1	1	168.37	534.57	719.9	796	0%
#2	1	182.94	491.89	733	799	0%
#3	1	184.24	488.8	722	774	0%

3회 반복 중 최대 184.24 TPS 달성, 에러율 0% 안정적.

Grafana 16:25~16:35 시간대 모니터링 (샘플수 55,300여개)

Ramp-up 구간 (0~60s): 유저 수 점진 증가와 함께 CPU가 빠르게 상승
Steady State: CPU ≈ 100% 포화 구간 — TPS 184 달성 시점과 일치
테스트 종료 후: CPU가 점진적으로 하강하며 0%에 수렴

200 User — 단일 POD

시나리오	POD	TPS	평균(ms)	P95(ms)	P99(ms)	에러율
#4	1	182.18	986.19	1,602	1,682	0%
#5	1	175.52	1,024	1,606	1,714	0%
#6	1	179.48	1,001.4	1,633	1,729	0%

동시 유저 2배 증가 시 TPS는 유지되나, 평균 응답시간이 ~2배 상승. POD 추가 없이 처리량 한계 도달.

400 User — POD 수평 확장

시나리오	POD	TPS	평균(ms)	P95(ms)	P99(ms)	에러율
#7	2	108.38	3,305.66	5,020	5,628	0%
#8	4	109.7	3,266.24	4,143	4,956	0%

400 User 구간은 평균 응답시간이 3초 이상으로 치솟아 서비스 허용 범위를 벗어났습니다. 이 구간은 실 서비스에서 도달할 가능성이 낮은 임계치를 확인하기 위한 참고용 테스트로, 이상 동작 없이 정상 응답했음을 확인하는 것으로 목적을 달성했습니다.

결과 요약

이번 테스트를 통해 단일 POD(1 vCore / 2 GiB) 기준 최대 TPS는 184임을 확인했습니다.

현재 서비스는 초기 단계로 목표 TPS가 한 자릿수~수십 단위 수준 => 부하테스트 결과, 트래픽이 예상치를 크게 상회하더라도 POD 1개로 충분히 커버 가능함을 데이터로 검증 완료.

현재 서비스 목표 TPS는 수십 단위 수준으로, 단일 POD 최대 TPS 184 대비 충분한 여유를 확보한 상태로 확인할 수 있었습니다.

정리

인수인계된 Xms=Xmx=2048m 고정 설정에서 환경별 Pod 메모리와의 불일치를 발견 및 개선
Heap = Pod 메모리의 75% 룰 적용 → Non-Heap OOM 위험 해소, 운영계 성능 향상
Heap 최적화 이후 부하테스트 진행 → 단일 POD 최대 TPS 확인
현재 목표 TPS 대비 충분한 여유 확보 — POD 1개로 충분한 수준임을 데이터로 검증

[Kanana 429] 카나나 앰배서더 첫날 — 100명 모인 발대식 현장 후기

snapcoder — Fri, 13 Mar 2026 21:24:28 +0900

안녕하세요. 오늘은,

KANANA 429 앰배서더 발대식 에 다녀왔습니다

2026년 3월 13일, 카카오 AI 캠퍼스(경기 용인)에서 KANANA 429 앰배서더 발대식이 열렸습니다.

AI캠퍼스 입구

감각적인 포토부스

대학생 / 크리에이터 / AI 전문가 세 그룹이 한자리에 모인 자리로, 참석자만 약 100명에 달했습니다.

입장: 키캡 · 이름표 · 죠르디 카드

도착하자마자 귀여운 빈 키캡과 타임테이블이 적힌 이름표를 받았습니다.

키캡은 처음엔 비어있고, 미션 통해서 채워야 합니다. 누르면 불빛이 반짝반짝 합니다 손맛이 있습니다

이벤트 미션 모두 성공

인생네컷처럼 포토부스에서 사진을 찍으면 죠르디 카드로 만들어주는 이벤트도 있었습니다.

카나나 모델을 활용한 것으로 알고있고, 카카오톡 사진 우측상단의 "영상으로 만들기" 기능도 처음 사용해볼 수 있었습니다.

각종 굿즈 퀄리티도 상당했습니다.

명함 홀더

디저트도 정말 맛있었습니다.
에그 타르트도 맛있었습니다. 잘먹었습니다 감사합니다

앰배서더 활동 시작에 앞서

유의사항과, 카카오안의 AI서비스들을 확인할 수 있었습니다. AI국민비서 '구삐'는 매우 잘 사용하고 있었는데, 이 외에도 아직 사용해보지 못한 서비스들이 의외로 많았습니다.

세션 1: 조코딩님 — 최신 AI 트렌드 & 카나나-o 활용 사례

유튜브 코딩 채널로 유명한 조코딩님께서 최신 AI 트렌드와 카나나-o 서비스 활용 사례를 발표해 주셨습니다.
비IT 분야 참석자들도 쉽게 이해할 수 있도록 풀어주셔서, AI 개념 접근성 면에서 좋은 시간이었습니다.

조코딩님께서는 무엇보다도 AI가 어떻게 활용되고 있고, 앞으로 어떻게 활용할 수 있는지, "AI 활용" 이라는 키워드에 있어서는 정말 컨텐츠로 잘 다루시는 것 같습니다.

한가지 기억나는 점은, 시댄스2.0이 제작한 재난 영화의 퀄리티가, 수십 수백억을 공들여 만든 것처럼 진짜 같았던게 제 머릿속에는 매우 임팩트가 컸습니다. 신기했습니다.

(해당 모델은 저작권 이슈로 아직 공개되고 있지 않다고 합니다.)

점심: 코스요리

점심은 코스요리로 제공됐습니다. 기대 이상으로 맛있었고, 가져다주시고 치워주셔서 앉은자리에서 먹기만하고 편했습니다.

모두 찍진 못했지만 메인디시 2개만 보여드립니다.

입에서 녹습니다.

세션 2: Hunter님 ㅡ 네트워킹: AI 전문가 그룹

오후에는 AI 전문가 그룹으로 이동해 hunter님께서 진행해주시는 네트워킹 시간을 가졌습니다.
저서를 출간하신 분, 석·박사 과정 중인 분, 현업 종사자, 취업 준비생까지 다양한 분들이 계셨고, 생각보다 훨씬 높은 수준의 자리여서 많이 놀랐습니다. 스펙이 대단하신분들이 정말 많이 계셨습니다..

세션 3: Peter님 — Deep Request

이어서 Peter님의 Deep Request 세션에 참석했습니다.
카나나 모델의 구조와 동작 방식에 대해 깊이 있는 내용을 다뤄주셔서, 모델에 대한 이해를 한층 높이며

저번에 포스팅한 내용을 한번 더 되새겨볼 수 있었습니다.

https://snapcode.tistory.com/200

[Kanana-o] 한국 최초 옴니 AI, 직접 써봤습니다. (feat. 부산 사투리)

안녕하세요. 운이 좋게도 Kanana-o Beta Tester 로 선정되어,멀티모달 언어 모델을 직접 사용해보고, 간단한 서비스로 구현해본 경험을 공유하고자 합니다.실제로 사용해보며 느낀 점과 함께, 기능 개

snapcode.tistory.com

세션 4: CHOI님 ㅡ AI기술 중심 콘텐츠 전략

다른 앰배서더분들께서 입을 모아서 "우리나라에서 가장 AI소식이 빠른 분이시다." 라고 하실만큼, 최신 동향을 파악하고 전파하는데에 힘쓰고 계신것으로 알고있습니다.

인상 깊었던 점은, 쓰레드를 선택한 이유도 그렇고, 본인이 가진 생각과 콘텐츠 전략을 선보이시는게 멋있었습니다.

이동: 판교아지트 <---> 카카오 AI 캠퍼스

출발과 귀환 모두 셔틀버스를 이용했습니다.
역세권인 카카오 판교아지트 1층 버스정류장에서 승하차해서 덕분에 매우 편리했습니다.

마치며

카카오가 지금껏 쌓아온 모델을 직접 먼저 경험해보고, 앞으로의 성장을 함께 지켜볼 수 있다는 점에서 기대가 큽니다.

오늘을 준비해주신 모든 분들께 감사드립니다. 짧은 시간이었지만 밀도 있는 하루였습니다.

KANANA 429, 잘 부탁드립니다.

굿즈 모음

앰배서더 바람막이 등 로고

기억에 남으시는 분들 - 영상 합성 데이터 데2빗님, 마음 치유 hn마인드님, 연차안쓴 기획자님, 파워E 엔C 데이터 jsy님, 모델 연구 석사님, 예술계 sin코님, 취준중이신님, 제주도 훈ter님, 러닝크루 인플루언서님, 가정기술 교직원님, 지급받은 명함100개중 1개빼고 전부 교환했다는 대학생님 등등

[CI/CD] paths-filter 하나로 빌드 시간 72% 단축하기

snapcoder — Fri, 13 Mar 2026 00:57:08 +0900

배경

사이드 프로젝트를 개발하면서 GitHub Actions로 CI/CD를 운영하고 있습니다.
프론트엔드(Next.js)와 백엔드(Spring Boot + Docker)를 하나의 레포에서 관리하다 보니,
텍스트 하나 수정해도 매번 풀빌드가 돌았습니다.

Node.js 설치 → npm ci → Next.js 빌드
JDK 설치 → Gradle 빌드 → Docker 빌드 → Docker 푸시 → 서버 배포

평균 소요 시간: 약 3분대...!
FE 수정 1줄 → 백엔드 Docker 이미지까지 새로 빌드 → 배포까지 3분 대기

문제 분석

# 기존: 모든 커밋에서 무조건 전체 실행
- name: Build with Gradle       # BE 변경이 없어도 항상 실행
  run: ./gradlew build -x test

- name: Build and push Docker image  # FE 변경만 있어도 항상 실행
  uses: docker/build-push-action@v6

FE 변경 시 낭비되는 단계:

JDK 설치 / Gradle 빌드 / Docker 빌드·푸시 / BE 서버 배포

BE 변경 시 낭비되는 단계:

Node.js 설치 / npm ci / Next.js 빌드 / rsync 전송 / FE 서버 배포

해결: dorny/paths-filter로 변경 경로 감지

# fetch-depth: 2 설정 처리로, 이전 커밋과 diff 비교 불가 문제 해결
- name: Checkout code
  uses: actions/checkout@v4
  with:
    fetch-depth: 2

# 변경된 경로 감지 처리로, FE/BE 빌드 분기 문제 해결
- name: Detect changed paths
  uses: dorny/paths-filter@v3
  id: filter
  with:
    filters: |
      fe:
        - 'frontend/**'
      be:
        - 'src/**'
        - 'build.gradle'
        - 'Dockerfile'
        - 'gradle/**'

# FE 변경 시만 실행 처리로, 불필요한 Node.js 빌드 스킵 문제 해결
- name: Build Next.js Frontend
  if: steps.filter.outputs.fe == 'true'
  run: cd frontend && npm run build

# BE 변경 시만 실행 처리로, 불필요한 Docker 빌드 스킵 문제 해결
- name: Build and push Docker image
  if: steps.filter.outputs.be == 'true'
  uses: docker/build-push-action@v6
  with:
    context: .
    push: true
    tags: sample-username/sample-app:latest
    cache-from: type=gha   # GHA 레이어 캐시 사용 처리로, 변경된 레이어만 재빌드 문제 해결
    cache-to: type=gha,mode=max

추가: Docker 이미지 정리 전략

# 기존: 전체 이미지 삭제(-a 옵션) 처리 → 빌드 캐시 레이어까지 제거되어 재취득 비용 발생
docker image prune -af

# 변경: dangling 이미지만 삭제 처리로, 구 이미지 누적 + 캐시 레이어 손실 문제 해결
docker image prune -f

docker pull로 새 latest를 받으면 기존 태그는 자동으로 <none>:<none> dangling 상태가 됩니다.
-f만으로 충분히 정리되며, 유효한 레이어 캐시는 그대로 유지됩니다.

결과

구분	적용 전	적용 후
FE 단독 변경	약 3분 3초 (풀빌드 20회 평균)	51초
감소율	—	약 72% 감소

측정 기준: GitHub Actions 실제 run 기록 20회 평균(풀빌드) vs 조건부 빌드 첫 FE 단독 실행
=> BE 단독 변경 시에도 Node.js / npm ci / Next.js 빌드 / rsync 등이 스킵되어 추가 단축 효과가 기대됩니다.

정리

dorny/paths-filter 하나로 변경 경로를 감지하고, 각 스텝에 if: 조건을 추가하는 것만으로
빌드 시간을 크게 줄일 수 있었습니다.

모노레포 구조에서 FE / BE를 함께 관리한다면 적용을 추천합니다.

[Linux] crontab × find 조합으로 N일 초과 파일 자동 삭제하기

snapcoder — Thu, 12 Mar 2026 01:37:05 +0900

서버를 운영하다 보면 로그 파일이 조용히 쌓여 어느 날 디스크를 꽉 채우는 상황을 겪게 됩니다.
크롤러 로그가 100MB를 넘긴 후에야 뒤늦게 수동으로 지웠는데, 이 과정을 자동화한 방법을 소개합니다.

상황 정리

/home/user/project/logs/
├── crawler_20260308.log   # 날짜별 로그
├── crawler_20260309.log
├── crawler_20260310.log
├── crawler_20260311.log
└── crawler.log            # 누적 메인 로그 (108MB...)

날짜별 로그(crawler_YYYYMMDD.log)는 매일 생성되지만, 오래된 파일은 굳이 보관할 필요가 없습니다.
7일치만 남기고 초과분은 매일 자동 삭제되도록 설정합니다.

핵심 명령어: `find` + `-mtime`

# -name 패턴으로 삭제 범위 제한 + -mtime +7로 최근 파일 보호 처리로, 실수로 현재 로그 삭제되는 문제 해결
find /home/user/project/logs -name "crawler_*.log" -mtime +7 -delete

옵션	설명
`-name "crawler_*.log"`	날짜별 로그 파일만 대상 (메인 로그 제외)
`-mtime +7`	마지막 수정 시간 기준 7일 초과 파일만 선택
`-delete`	조건에 맞는 파일 즉시 삭제

crawler.log는 파일명 패턴(crawler_*.log)에 해당하지 않으므로 삭제 대상에서 자동 제외됩니다.

crontab 등록

KST 기준 매일 새벽 5시에 실행되도록 등록합니다.
UTC 서버(Oracle Cloud 등) 기준으로는 UTC 20:00에 해당합니다.

crontab -e

# 매일 KST 05:00 (UTC 20:00) - 7일 초과 날짜별 로그 자동 삭제
0 20 * * * find /home/user/project/logs -name "crawler_*.log" -mtime +7 -delete

저장 후 별도 활성화 없이 즉시 적용됩니다.

등록 확인:

crontab -l

최종 crontab 구성 예시

# 매시간 0분 - 크롤러 실행
0 * * * * source /home/user/project/venv/bin/activate && cd /home/user/project && python main.py >> /home/user/project/logs/crawler.log 2>&1

# 매일 KST 05:00 (UTC 20:00) - 7일 초과 날짜별 로그 삭제
0 20 * * * find /home/user/project/logs -name "crawler_*.log" -mtime +7 -delete

정리

find + -mtime 조합으로 N일 초과 파일을 조건부 선택
파일명 패턴으로 삭제 대상 범위를 명확히 제한해 안전하게 운영
crontab에 등록해 매일 자동 실행, 수동 관리 불필요

간단하지만 서버 디스크 관리에 꽤 실용적인 조합입니다.

[Claude Code] 반복 프롬프트 이제 그만: 슬래시 커맨드로 나만의 AI 단축키 만들기

snapcoder — Tue, 10 Mar 2026 20:16:44 +0900

Claude Code를 쓰다 보면 매번 같은 긴 프롬프트를 붙여넣게 되는 순간이 옵니다.

블로그 초안 작성, 코드 리뷰 요청, 커밋 메시지 정리 등... 이런 반복 작업을 한 줄로 줄여주는 게 커스텀 슬래시 커맨드입니다.

https://code.claude.com/docs/ko/slash-commands

슬래시 커맨드란?

Claude Code에서 / 로 시작하는 명령어입니다.
기본 내장 커맨드(/help, /clear 등) 외에도, 사용자가 직접 만들어 등록할 수 있습니다.

만드는 방법

프로젝트 루트에 .claude/commands/ 디렉토리를 만들고, 그 안에 .md 파일을 생성하면 됩니다.

.claude/
└── commands/
    └── review.md   →   /review 로 호출됨

파일명 = 커맨드명이고, 파일 내용이 실행될 프롬프트입니다.
사용자 입력을 받으려면 $ARGUMENTS를 사용합니다.

<!-- .claude/commands/review.md -->
아래 코드를 리뷰해줘. 개선점이 있으면 제안해줘.

대상: $ARGUMENTS

호출 시:

/review src/components/MyComponent.tsx

→ $ARGUMENTS 자리에 src/components/MyComponent.tsx 가 자동으로 들어가 실행됩니다.

적용 범위

위치	범위
`.claude/commands/`	현재 프로젝트에서만 동작
`~/.claude/commands/`	모든 프로젝트에서 동작 (전역)

많이들 쓰는 커맨드 예시

1. `/review` — 코드 리뷰 자동화

커뮤니티에서 가장 보편적으로 쓰이는 패턴입니다.
PR 올리기 전 빠르게 셀프 리뷰를 받을 수 있어 실용적입니다.

<!-- .claude/commands/review.md -->
다음 파일을 코드 리뷰해줘.

- 버그 가능성
- 성능 이슈
- 가독성 개선점

파일: $ARGUMENTS

2. `/test` — 테스트 코드 생성

구현 후 바로 테스트 코드를 뽑아내는 용도로 많이 사용됩니다.

<!-- .claude/commands/test.md -->
아래 파일에 대한 단위 테스트 코드를 작성해줘.
기존 테스트 스타일을 참고해서 일관성 있게 작성해줘.

대상: $ARGUMENTS

마무리

슬래시 커맨드는 만드는 데 1분도 걸리지 않지만, 반복 작업을 줄여주는 효과는 상당합니다.
자주 쓰는 프롬프트가 있다면 바로 커맨드로 등록해두시길 추천합니다.

[OCI] 무료 서버 잡기: API 스크립트로 A1.Flex 인스턴스 자동 선점 (+Discord 알람 연동)

snapcoder — Mon, 9 Mar 2026 23:56:13 +0900

Elasticsearch를 자체 호스팅하려면 최소 4GB RAM 이상의 서버가 필요합니다.
JVM 힙 메모리를 대량으로 사용하는 구조라 메모리가 부족하면 OOM으로 죽거나 정상 기동이 어렵습니다.

항목	Elasticsearch 최소 권장
RAM	4GB 이상 (힙 2GB + OS 캐시)
CPU	2 Core 이상
Disk	SSD 권장

Oracle Cloud Free Tier의 ARM 인스턴스(VM.Standard.A1.Flex)는 최대 4 OCPU / 24GB RAM까지 무료로 사용할 수 있어 Elasticsearch 운영에 충분한 스펙입니다.

단, 항상 "Out of host capacity" 오류로 생성이 막힙니다.

이 글에서는 OCI REST API + 쉘스크립트 + 크론을 이용해 용량이 생기는 순간 자동으로 인스턴스를 선점하는 방법을 소개합니다.

목표 스펙

항목	값
Shape	VM.Standard.A1.Flex
OCPU	1
Memory	6GB
OS	Oracle Linux 9
Region	ap-seoul-1

사전 준비

1. OCI API Key 발급

OCI Console → 내 프로파일 → API 키 → API 키 추가 → API 키 쌍 생성 → 비공개 키 다운로드

발급 후 구성 파일 미리보기에서 아래 값을 확인합니다.

user=ocid1.user.oc1..YOUR_USER_OCID
fingerprint=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
tenancy=ocid1.tenancy.oc1..YOUR_TENANCY_OCID
region=ap-seoul-1

2. 서버에 PEM 키 업로드

다운로드한 .pem 파일을 서버에 올리거나, vi로 직접 붙여넣기 합니다.

vi /etc/oci/oci_api_key.pem
# 다운로드한 .pem 내용 붙여넣기 후 저장

chmod 600 /etc/oci/oci_api_key.pem

3. 필요한 OCID 수집

항목	확인 위치
Tenancy OCID	OCI Console → 내 프로파일 → 테넌시
User OCID	OCI Console → 내 프로파일
Compartment OCID	ID & 보안 → 구획 (루트 사용 시 Tenancy OCID와 동일)
Subnet OCID	네트워킹 → VCN → 서브넷
Image OCID	인스턴스 생성 화면 → 개발자도구 Network 탭에서 확인

쉘스크립트 작성

크론 전용으로 설계하여 1회 시도 후 종료합니다. 성공 시 크론을 자동으로 삭제합니다.

#!/bin/bash
# OCI 인스턴스 생성 스크립트 (1회 시도 후 종료 - 크론 전용)

# =====================
# 설정값
# =====================
TENANCY_OCID="ocid1.tenancy.oc1..YOUR_TENANCY_OCID"
USER_OCID="ocid1.user.oc1..YOUR_USER_OCID"
FINGERPRINT="xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx"
PRIVATE_KEY_PATH="/etc/oci/oci_api_key.pem"
REGION="ap-seoul-1"
COMPARTMENT_OCID="ocid1.tenancy.oc1..YOUR_TENANCY_OCID"
AVAILABILITY_DOMAIN="XXXX:AP-SEOUL-1-AD-1"
SUBNET_OCID="ocid1.subnet.oc1.ap-seoul-1.YOUR_SUBNET_OCID"
IMAGE_OCID="ocid1.image.oc1.ap-seoul-1.YOUR_IMAGE_OCID"
SSH_PUBLIC_KEY="ssh-rsa YOUR_PUBLIC_KEY_HERE"
LOG_FILE="/etc/oci/create_instance_log.txt"

HOST="iaas.${REGION}.oraclecloud.com"
ENDPOINT="https://${HOST}/20160918/instances"

# =====================
# OCI API 서명 함수 (RSA-SHA256)
# =====================
sign_request() {
    local method=$1
    local path=$2
    local body=$3

    local date=$(date -u "+%a, %d %b %Y %H:%M:%S GMT")
    local body_sha256=$(echo -n "$body" | openssl dgst -binary -sha256 | openssl base64)
    local content_length=${#body}

    local signing_string="date: ${date}
(request-target): $(echo $method | tr '[:upper:]' '[:lower:]') ${path}
host: ${HOST}
content-length: ${content_length}
content-type: application/json
x-content-sha256: ${body_sha256}"

    local signature=$(echo -n "$signing_string" | openssl dgst -binary -sha256 -sign "$PRIVATE_KEY_PATH" | openssl base64 | tr -d '\n')

    local auth_header="Signature version=\"1\",keyId=\"${TENANCY_OCID}/${USER_OCID}/${FINGERPRINT}\",algorithm=\"rsa-sha256\",headers=\"date (request-target) host content-length content-type x-content-sha256\",signature=\"${signature}\""

    echo "$date|$body_sha256|$content_length|$auth_header"
}

# =====================
# 1회 API 호출
# =====================
instance_name="my-instance-$(date +%s)"

body="{
  \"availabilityDomain\": \"${AVAILABILITY_DOMAIN}\",
  \"compartmentId\": \"${COMPARTMENT_OCID}\",
  \"displayName\": \"${instance_name}\",
  \"sourceDetails\": { \"sourceType\": \"image\", \"imageId\": \"${IMAGE_OCID}\" },
  \"shape\": \"VM.Standard.A1.Flex\",
  \"shapeConfig\": { \"ocpus\": 1, \"memoryInGBs\": 6 },
  \"createVnicDetails\": { \"assignPublicIp\": true, \"subnetId\": \"${SUBNET_OCID}\" },
  \"metadata\": { \"ssh_authorized_keys\": \"${SSH_PUBLIC_KEY}\" }
}"

path="/20160918/instances"
sig_data=$(sign_request "POST" "$path" "$body")

date_header=$(echo "$sig_data" | cut -d'|' -f1)
body_sha256=$(echo "$sig_data" | cut -d'|' -f2)
content_length=$(echo "$sig_data" | cut -d'|' -f3)
auth_header=$(echo "$sig_data" | cut -d'|' -f4)

response=$(curl -s -w "\n%{http_code}" -X POST "$ENDPOINT" \
    -H "Date: $date_header" \
    -H "Host: $HOST" \
    -H "Content-Type: application/json" \
    -H "Content-Length: $content_length" \
    -H "x-content-sha256: $body_sha256" \
    -H "Authorization: $auth_header" \
    -d "$body")

http_code=$(echo "$response" | tail -1)
body_resp=$(echo "$response" | head -n -1)

if [ "$http_code" = "200" ]; then
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] SUCCESS" >> "$LOG_FILE"
    echo "$body_resp" | grep -o '"id":"[^"]*"' | head -1 >> "$LOG_FILE"

    # Discord 웹훅 알림
    curl -s -X POST "https://discord.com/api/webhooks/YOUR_WEBHOOK_ID/YOUR_WEBHOOK_TOKEN" \
        -H "Content-Type: application/json" \
        -d "{\"content\": \"✅ OCI 인스턴스 생성 성공! $(date '+%Y-%m-%d %H:%M:%S')\"}"

    # 성공 시 크론 자동 삭제
    crontab -l | grep -v 'create_instance.sh' | crontab -
else
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] HTTP $http_code - $body_resp" >> "$LOG_FILE"
fi

Discord 알림 설정 (선택)

성공 시 Discord로 알림을 받을 수 있습니다.

웹훅 URL 생성:

Discord → 서버 만들기 → 비공개 채널 생성
채널 편집 → 연동 → 웹후크 만들기 → URL 복사

스크립트의 YOUR_WEBHOOK_ID/YOUR_WEBHOOK_TOKEN 부분을 복사한 URL로 교체하면 됩니다.

성공하면 아래처럼 Discord 알림이 도착합니다.

✅ OCI 인스턴스 생성 성공! 2026-03-10 09:10:35

크론 등록

cron은 초 단위를 지원하지 않으므로, sleep 10으로 10초 딜레이를 줍니다.
OCI 자원 회수가 정각에 이루어지는 경우가 많아 00초 직후를 노리는 전략입니다.

chmod +x /etc/oci/create_instance.sh
crontab -e

아래 내용 추가:

* * * * * sleep 10 && /bin/bash /etc/oci/create_instance.sh

동작 확인

# 수동 1회 테스트
sh /etc/oci/create_instance.sh

# 로그 실시간 확인
tail -f /etc/oci/create_instance_log.txt

# 크론 등록 확인
crontab -l

응답 코드 의미:

코드	의미	조치
`200`	성공 — 인스턴스 생성됨	크론 자동 삭제
`429 TooManyRequests`	요청 횟수 초과	자동 해소 대기
`500 Out of host capacity`	무료 자원 부족	용량 생길 때까지 대기

결과

로그에 아래처럼 출력되면 성공입니다.

[2026-03-09 23:40:35] SUCCESS
"id":"ocid1.instance.oc1.ap-seoul-1...."

성공과 동시에 크론이 자동 삭제되어 불필요한 API 호출이 중단됩니다.

마치며

OCI 콘솔에서 수동으로 눌러가며 시도하는 것보다 훨씬 효율적입니다.
스크립트 실행 후 기다리면 용량이 생기는 순간 자동으로 잡힙니다.

잘 잡히길 기대해봐야겠습니다..!

[Kanana-o] 한국 최초 옴니 AI, 직접 써봤습니다. (feat. 부산 사투리)

snapcoder — Sat, 7 Mar 2026 23:27:04 +0900

안녕하세요.

출처 https://tech.kakao.com/posts/811

운이 좋게도 Kanana-o Beta Tester 로 선정되어,

멀티모달 언어 모델을 직접 사용해보고, 간단한 서비스로 구현해본 경험을 공유하고자 합니다.

실제로 사용해보며 느낀 점과 함께, 기능 개발 및 테스트 과정도 정리해보았습니다.

사람처럼 보고, 듣고, 말하는 AI의 탄생
출처 https://omni.kanana.ai/

Kanana-o

카카오가 공개한 '카나나-o(Kanana-o)'는

국내 최초로 텍스트, 음성, 이미지를 동시에 이해하고 처리하는 통합 멀티모달(Multimodal)의 옴니 AI 언어모델 입니다.

공식 홈페이지 : https://omni.kanana.ai/

Kanana-o

더욱 똑똑하게 답하며, 더욱 풍부한 감정표현을 향한 Kanana-o의 진화 과정

omni.kanana.ai

Kanana-v(Vision) + Kanana-a(Audio) = Kanana-o

출처 https://tech.kakao.com/posts/802

이미지와 음성을 아우르다.

단순히 여러 모델을 연결한 구조라기보다는 Kanana-v(Vision)와 Kanana-a(Audio)를 Model Merging 방식으로 결합해
하나의 LLM backbone 위에서 동작하도록 설계된 통합 멀티모달 모델이라고 소개되고 있습니다.

말이 참 어렵습니다. 구조적으로 쉽게 이해해보자면 아래와 같습니다.

Audio Encoder (Whisper) // 사람의 귀처럼 음성을 텍스트 형태로 이해할 수 있는 정보로 바꿔줌
        ↓
Audio Projector // 텍스트를 LLM이 이해할 수 있는 형태로 번역기처럼 가공해줌
        ↓
LLM backbone // 사람의 뇌처럼 여러 데이터 보고 문맥 파악, 질문 이해, 결론 도출
        ↑
Vision Encoder // 사람의 눈처럼 이미지를 읽어들여서
Vision Projector // 이미지를 LLM이 이해할 수 있는 형태로 번역기처럼 가공해줌
        ↓
Voice Token LM // 사람의 성대처럼 목소리나 톤, 속도 등의 발화 스타일을 만들어줌
        ↓
TTS (Voicebox + Univnet) // 사람의 입처럼 음성으로 말해줌

한줄 요약 :말을 하면 → 귀(Whisper)가 듣고 → 뇌(LLM)가 생각하고 → 필요하면 눈(vision) 정보도 같이 보고 → 합쳐서 이해한 뒤 → 입(TTS)으로 다시 말해주는 모델

당연히 짚고 넘어가야 할

음성 처리 방식

한국어 음성 특화 모델인 만큼, Kanana-o의 음성 구조에서 중요한 부분은 말투가 결정되고 만들어지는 단계입니다.

흥미로운 점은, 텍스트 응답을 먼저 생성한 뒤 -> 음성 토큰으로 변환하는 two-stage 방식이 특징입니다.

음성 → Whisper → 임베딩
↓
LLM 이해
↓
텍스트 응답 생성
↓
Voice Token LM // 어떤 말투로 말할지 결정하는 곳 (억양, 톤, 속도, 감정 등)
↓
Token → Mel spectrogram // 위에서 결정된 성대 진동 패턴을 만드는 단계
↓
Vocoder → 음성

Kanana-v(Vision)의

사진 처리 방식

흥미로운 점은, 이미지를 LLM이 이해할 수 있는 형태로 변환할때 LLM에 바로 넣지 않고,

Vision Encoder → Projector → LLM 구조를 거쳐,

이미지 정보를 LLM이 이해할 수 있는 embedding 형태로 변환하는 방식이 특징입니다.

사진 입력
↓
Vision Encoder (CLIP 기반) // 이미지 특징 추출
↓
Image Feature Embedding // 고차원 feature로 표현
↓
C-Abstractor (Projector) // feature를 LLM이 이해할 수 있는 토큰(Visual Token) 형태로 변환
↓
LLM 입력 // 이미지 + 텍스트 context 함께 이해
↓
텍스트 응답 생성 // 사진 설명, 객체 인식, OCR, 차트 해석 등 수행

둘러 볼 만한

카카오의 차별화 전략

1) 멀티모달 데이터셋 직접 구축

텍스트 입력에서는 정확하고 풍부한 설명을 제공하던 모델이, 동일한 질문을 오디오로 전달하면 답변 품질이 저하될 수도 있다고 합 니다. 모달리티에 따라 답변 품질이 다르다는 것.

카카오는 이를 해결하고자

단순한 양의 확보를 넘어, 난이도·도메인 다양성·모달 조합의 균형까지 모두 고려한 구조화된 데이터셋을 직접 설계 구축함으로써,

모달리티에 무관하게 멀티모달 지시 이행 능력 고도화를 진행했다고 합니다.

텍스트로 "~방법 알려줘" => 답변 품질 좋음
VS
음성으로 "~방법 알려줘" => 답변 품질 떨어짐(모달리티별 성능 차이) => 데이터셋 확보 => 멀티모달 지시 이행 능력 개선

2) 멀티턴 memory 기반 음성 대화

일반적인 LLM => [질문 → 답변], [질문 → 답변], [질문 → 답변] 학습 => 질문하면 답변하고 끝.
VS
Kanana-o => 하나의 Sequence로 [대화 전체] 학습 => 대화 흐름 유지 + context 기억 + tone 유지.

3) 감정 음성 (DPO 학습)

결론부터 말하면, AI가 감정 없이 읽는 음성이 아니라, 사람처럼 감정을 담아서 말하도록 훈련했다는 겁니다.

단순 TTS가 아니라, DPO(Direct Preference Optimization) 방식으로 감정 표현을 학습했다고 합니다.

예를들면 아래와 같습니다.

일반 AI => "감사합니다" => 감정이 없음
VS
Kanana-o => "감사합니다;;" => 딱딱 당황 => 이건 별로라는걸 AI에게 계속 가르침 => 부정 톤 학습
Kanana-o => "감사합니다." => 정중 미지근 => 무미건조한걸 AI에게 계속 가르침 => 평범 톤 학습
Kanana-o => "감사합니다~!" => 밝고 긍정적 => 이게 더 좋다는걸 AI에게 계속 가르침 => 긍정 톤 학습

앞으로 기대해도 좋은

미래 성장 로드맵

Kanana-o 모델의 성장은 멈추지 않습니다. 카카오의 다음 목표는 아래와 같습니다.

1. Full-duplex 대화 =>서로 쉼 없이 동시에 말할 수 있고, 남의 말도 끊을 수 있고, 정말 사람처럼.
2. On-device 경량화 => 클라우드 의존 없이, 기기 안에서 바로 실행
3. 음성 외 모든 오디오 생성 => 박수소리, 게임 사운드, 고기 굽는 소리 등 다른 소리도 만들자.
4. Human preference alignment => AI를 취향에 맞게 조정하는 것

주요 기능

기능	설명
Image Captioning	이미지 설명 생성
Image-based Instruction Following	이미지 + 텍스트/음성 기반 지시 수행
OCR-based Reasoning	이미지 내 텍스트 인식 및 추론
ASR (자동 음성 인식)	한국어/영어 음성 → 텍스트 변환
Speech Translation	음성 → 다국어 번역
Text-to-Speech	텍스트 → 자연스러운 음성 생성
Style-instructed TTS	스타일 지정 음성 합성
Podcast-style Speech	이미지/텍스트 → 팟캐스트 형식 음성
Multiturn Conversation	멀티턴 음성/텍스트 대화
Omnimodal QA	텍스트 + 이미지 + 음성 통합 질의응답

위와 같이 다양한 기능을 기반으로, 활용 가능성이 무궁무진 하다고 봅니다.

참고 링크 : https://huggingface.co/kakaocorp/Kanana-1.5-o-9.8B-instruct-2602-API_Doc

kakaocorp/Kanana-1.5-o-9.8B-instruct-2602-API_Doc · Hugging Face

We’re on a journey to advance and democratize artificial intelligence through open source and open science.

huggingface.co

여기까지가

Kanana-o 모델에 대한 리뷰였습니다.

다음은 기능 구현 및 Beta 테스트 내용입니다.

구현 아이디어: AI 커리어 상담사 '커나나'

저번 PlayMCP 등록 이후,

사람과 얼마나 비슷할까?

를 직접 검증 해보고 싶었습니다.

그래서 AI 채용 상담사 '커나나' 를 만들어보았습니다. (커리어 + 카나나 의 합성어)

썸네일 화면

서비스에 배포된, Kanana-o 연동 기반 기능들은 아래 같습니다.

명함 · 포트폴리오 이미지를 첨부해 커리어 분석
실시간 음성 대화 기반 커리어 코칭
사투리 페르소나 적용 (서울 / 부산)
화자(Speaker A / B) 선택 기능
모의면접 수준의 자연스러운 멀티턴 대화

개발 내용

(1) WebSocket 실시간 스트리밍 + 멀티턴 히스토리 관리

WebSocket 기반으로 채팅을 구성했습니다.
스트리밍 응답을 청크 단위로 실시간 전달하기 위해 WebSocket 메시지 버퍼 크기도 별도로 증설했습니다.

// WebSocket 설정 (샘플 코드)
@Configuration
public class WebSocketConfig implements WebSocketConfigurer {
    @Override
    public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
        registry.addHandler(chatHandler, "/ws/chat")
                .setAllowedOrigins("*");
    }
}

대화 히스토리는 서버에서 세션 단위로 관리해, 이전 맥락을 유지한 채 연속 질문이 가능합니다.

// 멀티턴 히스토리 관리 (샘플 코드)
List<Message> history = sessionHistory.getOrDefault(sessionId, new ArrayList<>());
history.add(new Message("user", userInput));
history.add(new Message("assistant", assistantReply));
sessionHistory.put(sessionId, history);

(2) 이미지 분석 + SmartKeywordExtractor (멀티모달 활용)

Kanana-o의 멀티모달 기능을 활용해 명함이나 포트폴리오 이미지를 업로드하면,
이미지에서 직무 키워드를 추출해 자동으로 채용공고를 검색하는 흐름을 구현했습니다.

[명함 이미지 업로드]
        ↓
[Kanana-o 이미지 분석 → 직무/기술 키워드 추출]
        ↓
[SmartKeywordExtractor → 검색 쿼리 정규화]
        ↓
[관련 채용공고 목록 인라인 표시]

이미지는 Base64로 인코딩해 API에 전달했으며, data URL 포맷도 별도로 처리했습니다.

// 이미지 멀티모달 요청 (샘플 코드)
List<ContentPart> content = List.of(
    new ImageUrlPart(base64DataUrl),
    new TextPart(KEYWORD_EXTRACT_PROMPT)
);
String response = kananaClient.chat(content);
List<String> keywords = smartKeywordExtractor.parse(response);

SmartKeywordExtractor는 AI 응답에서 직무명, 기술스택, 경력 수준 등을 파싱해 데이터 검색 키워드를 정규화하는 역할을 담당합니다.

(3) 음성 파이프라인 구축

브라우저에서 수집한 PCM 오디오를 Kanana-o에 전달하기 전에 전처리가 필요했습니다.

불필요한 고주파 대역을 제거하고, 데이터 전송량을 줄여, 실시간 음성 처리 효율 개선을 위해

WAV 변환 후 16kHz로 리샘플링하여 전송하도록 처리했습니다.

- iPhone / iOS Safari 기본 샘플레이트 : 44.1kHz (44100 Hz)

// WAV 변환 + 리샘플링 (샘플 코드)
byte[] resampled = AudioResampler.resample(rawPcm, originalRate, TARGET_RATE_16K);
byte[] wavBytes  = WavConverter.toWav(resampled, TARGET_RATE_16K, CHANNELS, SAMPLE_WIDTH);
String b64Audio  = Base64.getEncoder().encodeToString(wavBytes);

응답 음성은 스트리밍으로 수신해 청크 단위로 저장한 뒤 병합하여 재생합니다.

# 음성 청크 수집 및 병합 (샘플 코드)
audio_chunks = []

for chunk in stream_response:
    audio_data = extract_audio(chunk)
    if audio_data:
        save_wav_chunk(audio_data, chunk_index)
        audio_chunks.append(audio_data)

merge_wav_chunks(audio_chunks, output_path="result/output.wav")

(4) 음성 UX — 아이들 타임아웃 & 녹음 충돌 방지

음성 대화 모드에서 UX를 다듬는 데 생각보다 많은 공이 들었습니다.

Voice Idle Timeout: 일정 시간 침묵 시 자동으로 녹음 종료 처리
이중 API Key: 쿼터 제한 대응을 위해 두 개의 API 키를 번갈아 사용
녹음 충돌 모달: 녹음 중 재시작 시도 시 경고 다이얼로그 표시
뮤트 기능: 음성 응답 재생 중 음소거 토글

// 아이들 타임아웃 처리 (샘플 코드)
function startIdleTimer() {
    idleTimer = setTimeout(() => {
        if (isRecording) stopRecording();
    }, IDLE_TIMEOUT_MS);
}

(5) 사투리 페르소나 구현

시스템 프롬프트에 방언 가이드를 명시해 서울 표준어 · 부산 사투리 두 가지 페르소나를 구현했습니다.
별도로 TTS 화자(A / B)는 목소리 톤 선택 제공되며, 방언과 화자는 독립적으로 조합할 수 있습니다.

인사말, 에러 메시지, 안내 문구 등도 방언별로 분기 처리해 전체적인 일관성을 유지했습니다.

// 사투리별 인사말 분기 (샘플 코드)
const GREETINGS = {
    seoul: "안녕하세요! 무엇을 도와드릴까요?",
    busan: "어서오이소~ 뭐 도와드릴까예?"
};

# 사투리 페르소나 설정 예시 (샘플 코드)
response = client.chat.completions.create(
    model="kanana-o",
    messages=[
        {"role": "system", "content": DIALECT_SYSTEM_PROMPT},
        {"role": "user",   "content": user_message}
    ],
    modalities=["text", "audio"],
    audio={"voice": "preset_spk_2"},  # 화자 B
    stream=True,
)

테스터 분들과 공유하고 싶은

꿀팁

(1) 빠른 시작 — OpenAI SDK 그대로 재활용

Kanana-o는 OpenAI SDK 호환 인터페이스를 제공합니다.
base_url과 model만 바꾸면 기존 코드를 그대로 쓸 수 있습니다.

client = OpenAI(
    base_url="https://kanana-o-endpoint.example.com/v1",
    api_key="<KANANA_API_KEY>"
)
response = client.chat.completions.create(
    model="kanana-o",
    messages=[{"role": "user", "content": "안녕하세요!"}]
)

(2) 멀티모달 출력 형식 강제 프롬프트

이미지를 함께 전달하면 모델이 지정한 출력 형식을 무시하는 경우가 있습니다.
FORMAT 태그 + Few-shot 예시를 함께 쓰면 준수율이 높아집니다.

이미지를 분석하고, 반드시 아래 [FORMAT] 안의 형식으로만 답하세요.
다른 텍스트는 절대 포함하지 마세요.

[FORMAT]
KEYWORD: <키워드1>, <키워드2>
LEVEL: <junior|mid|senior>
[/FORMAT]

--- 예시 ---
입력: (백엔드 개발자 명함 이미지)
출력:
[FORMAT]
KEYWORD: Java, Spring Boot, AWS
LEVEL: mid
[/FORMAT]

이 부분은 다른 테스터분들의 프롬프트 전략도 궁금한 포인트입니다. 좋은 방법이 있다면 공유해 주세요!

(3) 사투리 시스템 프롬프트 예시

TTS 화자 프리셋뿐만 아니라, 시스템 프롬프트에 방언 규칙과 예시를 구체적으로 명시하면 효과가 더 좋습니다.

당신은 부산 출신 AI 상담사입니다.
반드시 부산 사투리를 사용해 답변하세요.

[방언 규칙]
- ~습니다 → ~습니더
- ~이에요 → ~이라예
- ~인가요? → ~인교?

[예시]
표준어: 무엇을 도와드릴까요?
부산어: 뭐 도와드릴까예?

표준어: 잠시만요.
부산어: 잠깐만예.

(4) 쿼터 소진 방지 테스트 팁

베타 기간 개발 중 쿼터를 아껴쓸 수 있는 방법을 고민해보았습니다.

텍스트 먼저 검증 — 음성 출력은 쿼터 소모가 빠를것으로 예상되어, 로직은 텍스트 모드로 먼저 검증
모달리티별 단독 우선 테스트 — 이미지 / 음성 조합 전에 각각 단독으로 먼저 테스트

(5) 앞으로 해보고 싶은 것들

아직 테스트해보지 못한 기능이 많습니다.

기능	활용 아이디어
Podcast-style Speech	채용 뉴스나 JD를 AI가 팟캐스트 형식으로 읽어주는 기능
감정 표현력 TTS	면접 상황에 따라 긴장감 있는 / 친근한 톤 전환
Audio Multiturn	음성만으로 연속 모의면접 진행
Image-to-Podcast	포트폴리오 이미지를 자동으로 음성 자기소개로 변환

시연 Shorts

서비스의 사용자 경험 시나리오는 아래와 같습니다.

부산 사투리 프로필로 변경
화자 선택
실시간 대화 모드 활성화 후 인사
커나나가 부산 사투리로 반갑게 응답

" 부산 사투리까지 하는 멀티모달 AI 등장... "

※ 20초부터 사투리 음성을 들으실 수 있습니다.

Kanana-o의 사투리를 실제로 들어보니 어떠셨나요?

사투리를 사용하지 않는 저로서는 이 발음이 정확한 사투리인지, 흉내 낸 발음인지 판단하긴 어려웠습니다.

응답 텍스트에는 "듣겠습니더" 로 표시되어 있었지만, 음성에서는 "듣겠습니다" 에 가깝게 발음된 것처럼 들리기도 했습니다.

다만 전반적인 한국어 발화 자체는 매우 자연스럽게 느껴졌습니다.

특히 실제 사람이 말하는 것처럼 말 사이의 호흡이나 템포가 자연스럽게 이어진다는 점이 인상적이었습니다.

서울 사람인 제 기준에서는 사투리 표현도 충분히 신기하고 인상적으로 들렸습니다.

~~(솔직히 저보다 커나나가 사투리를 더 잘하는 것 같습니다..)~~

테스트 한계

1. 멀티모달 요청에서 규칙 미준수

명함 이미지와 텍스트를 함께 입력했을 때 Tool Call처럼 활용하기 위해 특정 출력 형식을 명시했지만,

간혹 모델이 해당 형식을 그대로 따르지 않는 경우도 있었습니다.

프롬프트 설계를 조금 더 정교하게 다듬어야 할 부분도 있겠지만,

생성형 모델 특성상 출력 형식을 완전히 강제하기는 쉽지 않은 부분이 아닐까 생각했습니다.

다른 테스터분께서도 비슷한 경험을 공유해주신 것으로 보아,

향후 모델 측면에서도 점차 개선되지 않을까 기대하고 있습니다.

2. 일일 쿼터 제한

현재 1일 횟수 제한이 있으며, 잔여 쿼터 조회 기능은 아직 지원되지 않아,
개발 사이클 상 더딘 부분이 있지만, 베타 기간인 만큼 이해는 하고 있습니다.

친절하게 도움주시는 관계자분들께 항상 감사드립니다.

출처 https://api-omni.kanana.ai/

앞으로의 목표

명함 · 포트폴리오 이미지 기반 커리어 분석 기능 고도화
멀티턴 모의면접 흐름 구현
출력 형식 준수를 위한 프롬프트 전략 개선
풍부한 감정 표현력 테스트
다중 화자 대화 TTS 심층 테스트

출처 https://omni.kanana.ai/

처음 이런 기회를 주신 카카오 관계자분들께 감사드립니다.
앞으로 모델 성능이 개선될수록 더 많은 가능성이 열릴 것 같아 기대됩니다.

맺음말

다른 테스터분들은 어떻게 Kanana-o를 활용하고 계신가요?
디스코드 혹은 댓글로 편하게 공유해 주세요!

참고문헌

Kanana-o API 명세서, https://huggingface.co/kakaocorp/Kanana-1.5-o-9.8B-instruct-2602-API_Doc

kakaocorp/Kanana-1.5-o-9.8B-instruct-2602-API_Doc · Hugging Face

We’re on a journey to advance and democratize artificial intelligence through open source and open science.

huggingface.co

Kanana-o 모델 이해를 위한, edwin.ai / james.e 님의 이미지와 음성을 아우르는 카카오의 멀티모달 언어모델 Kanana-o 알아보기

이미지와 음성을 아우르는 카카오의 멀티모달 언어모델 Kanana-o 알아보기 - tech.kakao.com

안녕하세요, 카카오의 AI 모델 개발을 담당하는 카나나(Kanana) 조직의 Ed...

tech.kakao.com

멀티모달 지시 이행 능력과 멀티턴 대화 이해를 위한, edwin.ai / james.e / jessie.e 님의, 더욱 똑똑하게 답하며, 더욱 풍부한 감정표현을 향한 Kanana-o의 진화 과정

더욱 똑똑하게 답하며, 더욱 풍부한 감정표현을 향한 Kanana-o의 진화 과정 - tech.kakao.com

안녕하세요, 카카오의 AI 모델 개발을 담당하는 카나나(Kanana) 조직의 Ed...

tech.kakao.com

이미지 처리 방식 이해를 위한, logan.c 님의, 이미지도 찰떡같이 이해하는 카카오의 멀티모달 언어모델 Kanana-v 알아보기

이미지도 찰떡같이 이해하는 카카오의 멀티모달 언어모델 Kanana-v 알아보기 - tech.kakao.com

안녕하세요, 카카오의 AI 모델 개발을 담당하는 카나나 알파(Kanana ⍺) 조...

tech.kakao.com

AI 모델 라인업, 카카오의 AI 모델, 카나나 모델 패밀리를 소개합니다

카카오의 AI 모델, 카나나 모델 패밀리를 소개합니다 - tech.kakao.com

지난 if(kakaoAI)2024에서는 카카오의 독자적인 AI 모델 라인업, Ka...

tech.kakao.com

AI 기반 아이디어 발굴 과정에서, hunter.jo 님의 카카오 x 한국정보과학회 AI 에이전트 경진대회

(FAQ) 카카오 x 한국정보과학회 AI 에이전트 경진대회 - tech.kakao.com

본 경진대회에 관심을 가져주신 모든 분께 감사드립니다. 참가자들이 AI 에이전트 ...

tech.kakao.com

※ 컨텐츠 내용상 문제의 소지가 있는 경우 말씀주시면 개정하도록 하겠습니다. 감사합니다.

[Kanana-o] 베타 테스터로 선정되신 것을 축하드립니다! (#앰배서더)

snapcoder — Wed, 4 Mar 2026 19:57:08 +0900

저번 달 Kanana-o 모델 공개 당시 소개 글을 작성한 적이 있습니다.

[AI] Kanana-o, 카카오 독자 개발 옴니(Omni) 모델. 과연 사람과 얼마나 가까울까? (https://snapcode.tistory.com/195)

[AI] Kanana-o, 카카오 독자 개발 옴니(Omni) 모델. 과연 사람과 얼마나 가까울까?

2026.02.12 모집 시작. 그리고 2026.02.20, 안내 메시지가 도착했습니다. 요즘 카카오는 확실히 AI에 집중하고 있다는 느낌을 받습니다. 이번에 공개된 모델은 Kanana-o국내 최초 통합 멀티모달 언어모델

snapcode.tistory.com

그리고 오늘 저녁.

운이 좋게도, 카카오의 멀티모달 AI 모델 Kanana-o API 베타 테스터에 참여하게 되었습니다.

[Kanana] 베타 테스터로 선정되신 것을 축하드립니다!

선정 안내 메시지와 함께 전용 API 콘솔 접근 권한이 부여되었고, 개인별 API Key를 발급받았습니다.

베타 프로그램 개요

모델: Kanana-o (Omni AI)
지원 기능: 텍스트 · 이미지 · 음성 입력 및 멀티모달 응답
제공 방식: 전용 API 콘솔을 통한 Key 발급
사용 기간: 약 5개월
공식 디스코드 채널 운영 (가이드, 버그 제보, 이벤트 진행)

오프라인 발대식 및 네트워킹 세션도 함께 운영될 예정이라고 합니다.

API 리뷰 (코드생략)

Kanana-o API는 Chat Completion 기반 구조로 제공되며
기존 LLM과 유사한 방식으로 빠르게 연동할 수 있을 것 같습니다.

멀티모달 입력과 스트리밍 응답을 지원하며, 단일 메시지 구조 안에서 통합 처리가 가능합니다.
이를 바탕으로 음성 인터페이스나 콘텐츠 자동화 등 다양한 서비스 설계에 활용할 수 있을 것으로 보입니다.

앞으로

베타 기간 동안 실제 서비스 관점에서 활용 가능성을 추가로 실험해볼 예정입니다.
일일 응답 횟수가 10회로 제한되어 있다는 것 같아, 신중하게 테스트해야 할 것 같습니다.
다음 글에서는 실제 API 사용 경험을 정리해보겠습니다.

쿼터 할당이 늘어났으면 하는 바램입니다.

참고링크

kanana-o API 기술 문서 https://huggingface.co/kakaocorp/Kanana-1.5-o-9.8B-instruct-2602-API_Doc

kakaocorp/Kanana-1.5-o-9.8B-instruct-2602-API_Doc · Hugging Face

We’re on a journey to advance and democratize artificial intelligence through open source and open science.

huggingface.co

[PlayMCP] 내가 만든 MCP 서버를 카카오에 등록하다. 2편 심사통과 후기

snapcoder — Wed, 25 Feb 2026 19:32:59 +0900

저번 글에서 썼던 것처럼, 연휴 직전에 MCP를 직접 구현하고 등록했다.
https://snapcode.tistory.com/189

[PlayMCP] 내가 만든 MCP 서버를 카카오에 등록하다.

오늘 드디어 MCP 서버를 배포했습니다.원래 공모전이 뜨자마자 @DBrider3와 참가하려했지만, 일정상 참가하진 못했고, 이렇게 만들어보았습니다.https://playmcp.kakao.com/ PlayMCP | 새로운 AI 경험의 시작Pl

snapcode.tistory.com

심사를 요청해둔 상태였는데, 오늘 메일 한 통을 받았다.

“심사가 완료되었습니다.”

사실 처음에는 모델 연결 실패로 한 차례 재심사를 요청했었는데, 이번에는 무사히 통과됐다.

Tool 호출 건수가 조금 올라간 것을 보니, 실제로 여러 테스트 케이스를 돌려보며 정책 준수 여부를 확인해주신 것 같다.
@심사 담당자님, 도움주셔서 감사합니다.

요즘 개인 프로젝트로 하루하루 배움의 덕을 쌓아가면서, 참 개발이 재미있단걸 또 느끼고 있다.
판도가 빠르게 바뀌고 있다는 걸 체감하고 있고, 앞으로 어디까지 변할지 기대되면서도 조금은 두렵다. (AI의 성장 속도가 정말 빠르다…)

아무튼 이번 경험은 개인적으로 의미가 크다.
단순 실험이 아니라, 누구나 사용할 수 있는 형태의 서비스로 공개되었다는 점에서 작은 성장의 이정표처럼 느껴진다.

Agent 구조를 이해하고 MCP를 직접 설계하며 요청/응답 흐름, 스키마, 예외 처리를 서비스 관점에서 고민해볼 수 있었다.
이론으로만 알던 개념을 실제 구조로 만들어본 경험이었다. 앞으로 조금 더 고도화해볼까 한다.
이쯤 되면 카페24꺼로, 아주 작은 서버 하나 따로 운영해야 하나 고민도 된다.

[AI] GitHub Copilot Pro 한도 초과 후기: LTE 다 쓰고 3G로 버티는 기분

snapcoder — Fri, 20 Feb 2026 20:19:07 +0900

신나게 개발하고 있었는데, 나에게도 드디어 찾아왔다.

한 도 초 과.

검색해보니 GitHub Copilot 설정 페이지를 들어가보라고 나온다.

https://github.com/settings/copilot/features

GitHub · Change is constant. GitHub keeps you ahead.

Join the world's most widely adopted, AI-powered developer platform where millions of developers, businesses, and the largest open source community build software that advances humanity.

github.com

그리고 빨간색 바를 마주했다.

Premium Requests: 100.1%

처음 경험했다. 이게 다 써지는 거였나?

GitHub에서는 “정확한 토큰 수”를 공개하지 않아서 모르겠지만 넉넉할 줄 알았다

내가 사용 중인 플랜

현재는 GitHub Copilot Pro 플랜.

개발자 개인용 유료 플랜으로, IDE·CLI·모바일에서 Copilot을 사용할 수 있다.

Copilot Pro 주요 제공 사항

IDE 내 코드 자동완성
Chat 기반 코드 설명 및 리팩토링
Copilot CLI 지원
GitHub Mobile Chat 지원
월별 Premium Requests 제공
모델 선택 기능 (지원 모델 범위 내)

즉, 단순 자동완성이 아니라 거의 “AI 페어 프로그래머” 수준이라고 한다.

Premium Requests란?

일반 자동완성보다
더 많은 연산이 필요한 요청들:

Copilot Chat
대규모 코드 분석
리팩토링 요청
복잡한 프롬프트 기반 코드 생성

이런 요청이 Premium Request로 차감된다.

그리고 나는…

100.1% 사용.

왜 다 썼을까?

최근에:

LLM Agent 서버 설계
Spring 리팩토링
Docker 구조 수정
Nginx 설정
CI/CD 개선

거의 모든 코드를 Copilot과 함께 작업했다.

단순 자동완성이 아니라:

구조 설계 질문
설정 파일 생성
오류 분석
리팩토링 제안

을 계속 던졌다.

결과는 이번달 한도 초과.

느낀 점

이건 단순히 “많이 썼다”의 문제가 아니라,

AI를 개발 도구가 아니라 개발 동료처럼 쓰고 있다는 증거

라고 생각했다.

Copilot이 없으면 생산성이 확실히 떨어질 것 같다는 느낌도 들었다. (이젠 사실 좀 무섭기도 하다..AI의 성장 잠재력이..)

결론

Premium Requests 100% 초과.

의도한 건 아니지만, AI를 적극적으로 활용하는 개발 습관이 이미 자리 잡았다는 신호 같았다.

Plan, Agent, Edit, Ask 차이도 모르던 때가 엊그젠데.

다음 달 리셋이 빨리 돌아왔으면 좋겠다.

퍼플렉시티 1년 무료, 뭐 무료, 뭐 대학생 제공, 이런거좀 해둘걸 싶다.

[Server] 내장 톰캣 대신 Nginx 리버스 프록시를 도입한 이유

snapcoder — Fri, 20 Feb 2026 20:02:45 +0900

처음에 빠르고 간단히 내장톰캣으로 프로젝트 개발을 시작했었다.

implementation 'org.springframework.boot:spring-boot-starter-web'

[Server] 내장 톰캣 대신 Nginx 리버스 프록시를 도입한 이유

사이드 프로젝트를 운영하면서 이런 구조가 되었다.

Next.js (static export)
Backend API 서버
LLM Agent 서버
크롤러
이미지 리소스

문제는 모두 한 서버에서, 각기 다른 포트로 떠 있었다는 점이다.

왜 Nginx를 고민했을까?

1️⃣ 포트 단일화

FE: 정적 파일
BE: 8080
Agent: 8081

사용자는 하나의 도메인으로 접속하지만 실제 서비스는 여러 포트에서 동작 중이었다.

이를 다음처럼 정리하고 싶었다.

example.com → 정적 파일
example.com/api → Backend
example.com/agent → LLM Agent

즉, 리버스 프록시 목적이었다.

2️⃣ CORS 문제

브라우저 기준으로 origin이 달라지면서 API 호출 시 CORS 이슈가 발생했다.

프론트와 API를 같은 도메인 아래로 묶으면
애초에 CORS 설정을 복잡하게 가져갈 필요가 없다. Nginx는 이 문제를 구조적으로 해결해준다.

3️⃣ Next.js static export

이번 프로젝트는 next start 방식이 아니라 static export 빌드 결과물을 서빙하는 구조였다.

즉, Node 서버가 반드시 필요하지 않다. 정적 파일이라면 굳이 애플리케이션 서버로 서빙할 이유가 없다.
Nginx가 훨씬 가볍고 효율적이다.

4️⃣ 저사양 서버 환경

무료 클라우드 서버 환경에서는 메모리 사용량도 중요한 요소다.

애플리케이션 서버 여러 개를 띄우는 것보다 Nginx로 정적 파일을 분리하는 편이 안정적이다.

실제 리소스 비교

도입 전 (내장 톰캣 사용)

Spring Boot 내장 톰캣이 정적 파일까지 함께 처리했다. (그래서 무거웠음)

Nginx 도입 후

전 후가 매우 많이 차이난다...!

컨테이너 메모리 224MiB → 86.77MiB (약 61% 감소, -137MiB)
전체 시스템 메모리 사용량 413MiB → 287MiB (약 30% 감소, -126MiB)
컨테이너 CPU 사용률 0.23% → 0.13% (약 43% 감소)
가용 메모리(available) 331MiB → 459MiB (약 38% 증가)
정적 리소스 처리 주체 변경 (내장 톰캣 → Nginx 분리)
→ 애플리케이션 서버는 API 처리에 집중 가능

그래서, 꼭 써야 할까?

정리해보면 이렇다.

상황	Nginx 필요성
단일 Node 서버	낮음
정적 + API 분리	높음
멀티 서비스 운영	높음
CORS 이슈 존재	매우 높음

이번 프로젝트에서는
리버스 프록시 + 정적 서빙 + 포트 통합 목적이 명확했기 때문에
도입을 검토하는 게 합리적이었다.

결론

Nginx는 "무조건 쓰는 기술"이 아니라
구조가 복잡해지는 순간 자연스럽게 필요해지는 도구라고 생각한다.

서비스가 단순할 때는 필요 없다.

하지만

포트가 늘어나고
API가 분리되고
Agent 서버가 추가되는 순간

그때부터는 고민이 아니라 선택에 가까워지더라.

[AI] Kanana-o, 카카오 독자 개발 옴니(Omni) 모델. 과연 사람과 얼마나 가까울까?

snapcoder — Fri, 20 Feb 2026 19:31:02 +0900

2026.02.12 모집 시작.
그리고 2026.02.20, 안내 메시지가 도착했습니다.

요즘 카카오는 확실히 AI에 집중하고 있다는 느낌을 받습니다.

이번에 공개된 모델은 Kanana-o
국내 최초 통합 멀티모달 언어모델이라고 소개합니다.

https://omni.kanana.ai/?t_src=talk&t_ch=msg

Kanana-o

더욱 똑똑하게 답하며, 더욱 풍부한 감정표현을 향한 Kanana-o의 진화 과정

omni.kanana.ai

사람에 가까운 자연스러운

이걸 엄청 강조하는 것 같습니다.

최근 LLM은 성능 경쟁을 넘어
“어떻게 경험을 설계하느냐”의 단계로 넘어가고 있다고 느낍니다.

Kanana-o 역시
멀티모달 + 자연스러운 발화 + 한국어 최적화라는 방향으로
카카오식 AI 전략을 보여주는 사례라고 생각합니다.

우선 대기등록은 신청해두었는데 앰배서더처럼 발표 일자가 기재되어있지 않아,

발표를 기다려봐야겠습니다.

아래는 홈페이지와 동일 내용 발췌

국내 최초 통합 멀티모달 언어모델
Kanana-o를 가장 먼저 만나보세요

Kanana-o란?

2025년 5월 국내 최초로 개발된 사람처럼 보고, 듣고, 이해하며 풍부한 감정까지 표현하는 통합 멀티모달 언어모델입니다.

API (Beta) 최초 공개

안정적인 서비스 제공을 위해, Kanana-o는 대기 등록 후 선정된 사용자부터 순차적으로 이용하실 수 있습니다.

신청 방법

방법: 하단 버튼을 눌러 대기 등록하기
기간: 2026/5/27까지 주차별 선별
안내: 카카오톡 채널 메시지로 개별 안내

FEATURE

가장 깊게 이해하는 AI

텍스트, 이미지, 음성 등 두 가지 이상의 정보를 동시에 이해하고 처리해, 한국어와 한국적 맥락 속 복잡한 의도와 상황까지 깊이 해석합니다.
가장 자연스럽게 말하는 AI

억양, 속도, 감정, 화자 특성을 고려해 풍부한 감정과 자연스러운 표현으로 사람처럼 말하고 반응합니다.

정확한 발음과
깨끗한 음질

가장 자연스러운
한국어 발화

풍부한
감정 표현력
가장 다재다능한 AI

카나나는 특정 태스크에 한정되지 않는 범용 멀티모달 모델로, 다양한 실생활 유스케이스를 폭넓게 지원합니다.

팟캐스트
발화 지원

멀티턴 대화
시나리오

다중 화자
대화 TTS

영상

소리 켜기

개발기 더보기

더욱 똑똑하게 답하며, 더욱 풍부한 감정표현을 향한 Kanana-o의 진화 과정 - tech.kakao.com

안녕하세요, 카카오의 AI 모델 개발을 담당하는 카나나(Kanana) 조직의 Ed...

tech.kakao.com

FAQ

이번 베타 서비스의 목적은 무엇인가요?

Kanana-o 신규 모델을 제한된 인원에게 API를 제공하는 클로즈드 베타 테스트(Closed Beta Test)입니다. 최신 모델을 무료로 체험해 보실 수 있으나, 베타 특성상 이용량에 제한이 있고 서비스 안정성이 변동될 수 있는 점 양해 부탁드립니다.

Kanana-o 모델(API)로 무엇을 할 수 있나요?

Kanana-o는 텍스트, 음성, 이미지를 통합적으로 이해하고 생성할 수 있는 최신 통합 멀티모달 언어모델로, 사람에 가까운 자연스러운 발화와 향상된 지시 이행 능력을 갖추고 있습니다. 단순한 벤치마크 성능을 넘어 실제 사용자 경험을 개선하는 데 초점을 맞춘 실용적인 기술을 제공하며, 자세한 모델 구조 및 스펙은 카카오 기술 블로그에서 확인하실 수 있습니다.

베타 테스터 선정 기준은 무엇인가요?

단순한 호기심보다는 구체적인 활용 시나리오와 기술적 구현 역량을 갖추고, 적극적으로 피드백을 주실 수 있는 분을 우선하여 선정합니다. Kanana-o를 활용해 실질적인 가치를 창출하고, 초기 팬덤으로서 함께 성장할 개발자분들의 많은 지원 바랍니다.

[AI] 카카오 AI 앰배서더, AI를 소비하면서 동시에 제품으로 만드는 개발자.

snapcoder — Fri, 20 Feb 2026 19:20:26 +0900

https://tech.kakao.com/posts/809

카카오 AI 앰배서더 ‘KANANA 429 앰배서더’를 신규 모집합니다. - tech.kakao.com

이 글은 카카오 공식 보도자료로, 기술블로그에 동시 게재합니다. KANANA...

tech.kakao.com

어느날 "카카오 AI 앰배서더" 공개 모집 알림톡이 날라왔습니다.

AI를 실사용 및 개발하고있는 요즘, 외부 커뮤니티 활동에도 참여하면 좋을 것 같다고 생각하여 신청했습니다.

이왕이면 내부 프로젝트에만 머무르지 않고,
외부 커뮤니티 활동을 통해 더 넓은 관점에서 AI를 다뤄보고 싶었습니다.
그래서 지원했습니다.

지금은 안보이지만, 3가지 중에 하나를 선택해야 하더군요.
지원 분야는 세 가지였습니다.

- AI 전문가
- 콘텐츠 크리에이터
- 대학생

저는 AI 전문가를 선택했습니다.

카카오 AI 앰배서더는

최신 AI 기술을 실무에 연결하거나
실제 서비스 관점에서 활용 사례를 만들 수 있는 기회이며
같은 방향성을 가진 개발자들과 교류할 수 있는 장이라고 생각합니다.

[MCP] JSON-RPC 2.0 API 동적 대시보드 만들기: Swagger처럼 브라우저에서 Tool 테스트하기

snapcoder — Fri, 20 Feb 2026 02:24:37 +0900

[MCP] JSON-RPC 2.0 API 동적 대시보드 만들기: Swagger처럼 브라우저에서 Tool 테스트하기

배경

REST API 서버를 개발할 때 Swagger UI가 얼마나 유용한지 알 것입니다. 요청/응답을 시각적으로 확인하고 바로 테스트할 수 있으니까요.

그런데 JSON-RPC 2.0 프로토콜 기반 MCP 서버를 만들면서 같은 편의성이 필요했습니다. PlayMCP 클라이언트도 좋지만, 개발 중에는 빠른 디버깅이 필요하거든요.

그래서 만들었습니다: GET /api/mcp 요청 시 동적으로 생성되는 인터랙티브 HTML 대시보드.

문제: 프로토콜이 다르면 테스트 도구도 달라진다

Swagger UI: REST API용 (각 엔드포인트별 문서화)
Postman: JSON-RPC 2.0? 복잡한 요청 포매팅 필수
우리의 MCP 서버: Tool 목록, 입력 스키마, 실행 폼이 동적임

→ 자동 생성되는 테스트 페이지가 필요했습니다.

솔루션: 브라우저 기반 인터랙티브 테스트 대시보드

아키텍처

GET https://example.com/api/mcp
  ↓
브라우저(text/html Accept)인지 확인
  ↓
└→ Yes: HTML 대시보드 반환
└→ No: SSE 스트림 반환

핵심 구현

1️⃣ 브라우저 vs API 클라이언트 구분

@GetMapping
public Object streamMessages(HttpServletRequest httpRequest) {
    String acceptHeader = httpRequest.getHeader("Accept");
    boolean isBrowserRequest = acceptHeader != null && 
                               acceptHeader.contains("text/html");

    if (isBrowserRequest) {
        String htmlContent = generateToolsDashboard();
        return ResponseEntity.ok()
            .header("Content-Type", "text/html; charset=UTF-8")
            .body(htmlContent);
    }
    // API 클라이언트용 SSE 스트림...
}

2️⃣ 동적 HTML 생성

등록된 모든 Tool을 읽어서 각각 카드로 렌더링:

private String generateToolsDashboard() {
    List<Tool> tools = ToolRegistry.getAllTools();

    // 헤더: 서버 정보, 상태 표시
    // Tool 섹션: 등록된 Tool 목록 동적 생성
    // 각 Tool별 카드:
    //   - 설명
    //   - 입력 스키마 (JSON)
    //   - 실행 폼 (동적 입력창)
    //   - 요청 예제
    //   - 결과 표시 영역
}

3️⃣ 각 Tool마다 실행 폼 자동 생성

입력 스키마에서 매개변수 추출:

private String generateExecutionForm(
    String toolName, 
    Map<String, Object> inputSchema) {

    // inputSchema.get("properties")에서 필드 정보 추출
    // for each field:
    //   - 타입에 따라 <input type="text"> 또는 <input type="number">
    //   - required 여부 확인
    //   - placeholder로 설명 표시
}

결과 HTML (예시):

<form onsubmit="event.preventDefault(); executeTool('search_jobs');">
    <div>
        <label>keyword <span style="color:red">*</span></label>
        <input type="text" name="keyword" required />
    </div>
    <div>
        <label>limit</label>
        <input type="number" name="limit" />
    </div>
    <button type="submit">  실행</button>
</form>

4️⃣ 브라우저에서 Tool 실행

JavaScript로 JSON-RPC 2.0 요청 생성 후 호출:

function executeTool(toolName) {
    // 폼 데이터 → arguments 객체 변환
    const arguments_ = {};
    for (let [key, value] of formData.entries()) {
        arguments_[key] = isNaN(value) ? value : Number(value);
    }

    // JSON-RPC 2.0 포맷
    const request = {
        jsonrpc: '2.0',
        method: 'tools/call',
        params: {
            name: toolName,
            arguments: arguments_
        },
        id: 1
    };

    // POST /api/mcp/call_tool
    fetch('/api/mcp/call_tool', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify(request)
    })
    .then(res => res.json())
    .then(data => {
        // 결과 표시 (✅ 성공 / ❌ 오류)
        // 실행 시간 표시
        // JSON 포맷팅된 결과 표시
    });
}

UI 디자인

그라데이션 배경 + 깔끔한 카드 레이아웃:

body {
    background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
}

.tool-card {
    background: #f9fafb;
    border-radius: 8px;
    padding: 25px;
    transition: all 0.3s ease;
}

.tool-card:hover {
    border-color: #667eea;
    box-shadow: 0 5px 15px rgba(102, 126, 234, 0.1);
}

.execution-panel {
    background: #f0f4ff;
    border: 2px solid #667eea;
    padding: 20px;
}

.execute-button {
    background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
    color: white;
    padding: 12px 24px;
    border-radius: 6px;
    font-weight: 600;
}

.execute-button:hover {
    transform: translateY(-2px);
    box-shadow: 0 5px 15px rgba(102, 126, 234, 0.4);
}

접속 방법

1️⃣ 서버 실행

./gradlew bootRun

2️⃣ 브라우저 접속

https://sample-domain.example/api/mcp

3️⃣ 대시보드 확인

서버 상태 정보 (프로토콜, 버전, Tool 개수)
등록된 모든 Tool 목록
각 Tool별 설명, 스키마, 테스트 폼

4️⃣ Tool 실행

폼에 파라미터 입력
실행 버튼 클릭
결과 즉시 표시
- ✅ 성공: 실행 시간 + JSON 결과
- ❌ 오류: 에러 메시지 + 상세 정보

기술 스택

요소	기술
프로토콜	JSON-RPC 2.0
템플릿	동적 StringBuilder HTML 생성
스타일	인라인 CSS (별도 파일 없음)
스크립팅	Vanilla JavaScript (라이브러리 불필요)
마크업	HTML5

핵심 장점

✅ 개발자 친화적: 별도 클라이언트 없이 브라우저로 즉시 테스트
✅ 자동 동기화: Tool 등록/수정 시 자동으로 대시보드 갱신
✅ 시각적 피드백: 실행 시간, 상태, 오류 메시지 한눈에 파악
✅ 학습 자료: 각 Tool의 입력 포맷, 요청 예제 자동 생성
✅ 프로덕션 배포: 경량 (외부 라이브러리 불필요)

주의사항

⚠️ 개발/테스트 목적: 프로덕션에서 API 인터페이스는 보호 필요
⚠️ Origin 검증: CORS, DNS Rebinding 공격 방지 로직 포함
⚠️ 타임아웃: 긴 작업은 30초 제한 설정

결론

Swagger UI 없이도 JSON-RPC 2.0 기반 API를 효과적으로 테스트할 수 있습니다.

브라우저만으로 Tool 목록 확인, 파라미터 입력, 결과 확인까지 한 번에. 개발 속도가 빨라집니다.

[Backend] SSE vs WebSocket: 실시간 통신 방식 언제 뭘 쓸까?

snapcoder — Wed, 18 Feb 2026 23:43:29 +0900

[Backend] SSE vs WebSocket: 실시간 통신 방식 언제 뭘 쓸까?

빠른 비교표

항목	SSE	WebSocket
프로토콜	HTTP	TCP
통신 방향	단방향 (서버→클라이언트)	양방향 (전이중)
연결 유지	HTTP 연결 유지	별도 소켓 유지
자동 재연결	✅ (기본 내장)	❌ (수동 구현)
CORS	간단	복잡
구현 복잡도	쉬움	어려움
리소스 사용	중간	많음

언제 뭘 쓸까?

1️⃣ SSE (Server-Sent Events)

"서버가 일방적으로 계속 밀어주기"

Usecase:
- 장시간 작업의 진행상황 표시 (파일 업로드, 데이터 처리)
- 실시간 알림 (새 메시지, 주문 상태 변경)
- 라이브 피드 (실시간 뉴스, 대시보드)

흐름:
[클라이언트] --연결 유지--> [서버]
                           ├─ [0.5초] 진행 상황 1 푸시
                           ├─ [1.5초] 진행 상황 2 푸시
                           └─ [5초] 최종 결과 푸시

2️⃣ WebSocket

"양쪽이 자유롭게 대화하기"

Usecase:
- 채팅 (양방향 메시지)
- 온라인 게임 (실시간 플레이어 위치)
- 협업 도구 (실시간 문서 편집)
- 실시간 양방향 상호작용

흐름:
[클라이언트] <--양방향--> [서버]
  ├─ "검색해줘" ─────────────>
  │                         [처리 중]
  <──────── "진행: 50%" ←────┤
  "음, 다시 검색" ─────────────>

코드 예시

SSE (Server-Sent Events)

서버 (Spring Boot):

@RestController
public class StreamController {
    @GetMapping("/api/stream-search")
    public SseEmitter search() {
        SseEmitter emitter = new SseEmitter(60 * 1000L);
        new Thread(() -> {
            try {
                // [0.5초] 진행 상황 1
                emitter.send(SseEmitter.event()
                    .id("progress")
                    .data("{\"loaded\": 100}"));
                Thread.sleep(500);
                // [1초] 진행 상황 2
                emitter.send(SseEmitter.event()
                    .id("progress")
                    .data("{\"loaded\": 200}"));
                // [5초] 최종 결과
                emitter.send(SseEmitter.event()
                    .id("complete")
                    .data("{\"results\": [...]}"));
                emitter.complete();
            } catch (IOException e) {
                emitter.completeWithError(e);
            }
        }).start();
        return emitter;
    }
}

클라이언트 (JavaScript):

const es = new EventSource('/api/stream-search');
es.addEventListener('progress', (event) => {
    const data = JSON.parse(event.data);
    console.log(`진행: ${data.loaded}개`);  // [중간중간 받음]
    updateUI(data.loaded);
});
es.addEventListener('complete', (event) => {
    const result = JSON.parse(event.data);
    console.log('완료:', result.results);  // [최종 결과]
    es.close();
});

WebSocket

서버 (Spring Boot):

@Configuration
@EnableWebSocket
public class WebSocketConfig implements WebSocketConfigurer {
    @Override
    public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
        registry.addHandler(new MessageHandler(), "/ws/app").setAllowedOrigins("*");
    }
}

@Component
public class MessageHandler extends TextWebSocketHandler {
    private Set<WebSocketSession> sessions = new HashSet<>();

    //   클라이언트에서 메시지 받기
    @Override
    protected void handleTextMessage(WebSocketSession session, TextMessage message) {
        String msg = message.getPayload();  // 클라이언트로부터 받은 메시지
        System.out.println("  받음: " + msg);

        //   모든 연결된 세션에 메시지 보내기
        for (WebSocketSession s : sessions) {
            try {
                s.sendMessage(new TextMessage(msg));  // 메시지 전송
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }

    @Override
    public void afterConnectionEstablished(WebSocketSession session) throws Exception {
        sessions.add(session);  // 새 연결 등록
        System.out.println("✅ 연결됨: " + session.getId());
    }

    @Override
    public void afterConnectionClosed(WebSocketSession session, CloseStatus status) throws Exception {
        sessions.remove(session);  // 연결 제거
        System.out.println("❌ 연결 종료: " + session.getId());
    }
}

클라이언트 (JavaScript):

const ws = new WebSocket('ws://sample-server.example.com/ws/app');

// ✅ 연결 수립
ws.onopen = () => {
    console.log('✅ 소켓 연결됨');

    //   서버에 메시지 보내기
    ws.send(JSON.stringify({message: 'hello'}));
    console.log('  보냄: hello');
};

//   서버에서 메시지 받기
ws.onmessage = (event) => {
    const data = JSON.parse(event.data);
    console.log('  받음:', data.message);  // 서버로부터 받은 메시지
    updateUI(data.message);
};

// ❌ 연결 종료
ws.onerror = (error) => {
    console.error('❌ 에러:', error);
};

ws.onclose = () => {
    console.log('❌ 연결 종료됨');
};

// 언제든 메시지 보낼 수 있음 (클라이언트 주도)
setTimeout(() => {
    ws.send(JSON.stringify({message: 'again'}));  //   다시 보내기
}, 2000);

핵심 차이점

항목	SSE	WebSocket
연결 수명	유지	유지
데이터 흐름	단방향	양방향
브라우저 지원	IE 미지원	대부분
메모리 사용	중간	많음
지연시간	낮음	낮음

실전 의사결정 플로우

"실시간 양방향 통신 필요?"
  ├─ [NO] → SSE ✅ (진행상황, 알림)
  └─ [YES] → WebSocket ✅ (채팅, 게임)

실제 개발 팁

SSE 선택:

장시간 작업의 진행상황 (파일 업로드, 데이터 처리)
단순 알림 (클라이언트가 듣기만 하면 됨)
자동 재연결이 필요할 때
구현이 간단할 때

WebSocket 선택:

채팅, 협업 도구
실시간 양방향 상호작용
높은 메시지 처리량 필요할 때
낮은 지연시간이 중요할 때

[MCP] Gemini + LangChain4j 활용하여 검색 기능 개선

snapcoder — Tue, 17 Feb 2026 04:02:17 +0900

[ MCP Inspertor Search Result ]

상황

기존 검색은 정해진 SQL로 단순 키워드만 조회했습니다. 이번에 Gemini AI(무료 플랜) + LangChain4j를 결합하여 자연어를 JSON으로 변환한 후, 동적 SQL을 안전하게 생성하는 시스템을 구현했습니다.

핵심 개선사항

기존: 고정 SQL, WHERE 조건 사전 정의
개선: 자연어 → LLM 분석 → JSON 추출 → 동적 SQL (유연성 ↑)

아키텍처 흐름

사용자 입력 (자연어)
    ↓
[Gemini 2.0 Flash] 검색 조건 분석
    ↓
JSON 파싱 (필터 조건 구조화)
    ↓
[PreparedStatement] 안전한 SQL 조립
    ↓
데이터베이스 실행 → 결과 반환

실제 예시

입력: "금융 회사의 5년 이상 경력 개발자 공고 10개"

LLM 변환 JSON:

{
  "company": "금융 핀테크 결제",
  "experience_level": "5년 이상 경력",
  "keyword": "금융 결제 핀테크 개발자",
  "limit": 10
}

동적 생성 SQL:

SELECT t.id, t.title, t.link, c.name as company_name,
       d.level, d.job_type, d.description
FROM job t
LEFT JOIN detail d ON t.id = d.job_id
LEFT JOIN company c ON t.company_id = c.id
WHERE t.status != 'DELETED'
  AND (c.name ILIKE '%금융%' OR c.alias ILIKE '%금융%')
  AND (t.title ILIKE '%개발자%' OR d.description ILIKE '%개발자%')
ORDER BY t.created_at DESC
LIMIT 10

핵심 구현: 3단계 파이프라인

Step 1: LLM이 자연어를 JSON으로 변환

private String generateSearchCriteria(String userInput) {
    String prompt = """
        사용자의 자연어 검색을 JSON으로 변환하세요.

        동의어 확장 예시:
        - "금융" → "금융 핀테크 결제 송금"
        - "헬스" → "헬스 의료 건강 웰니스"
        - "게임" → "게임 엔터테인먼트 게이밍"

        JSON 형식:
        {
          "company": "회사명 또는 null",
          "experience_level": "경력요건 또는 null",
          "keyword": "검색어 + 동의어",
          "limit": 10
        }

        입력: """ + userInput;

    return chatModel.chat(ChatRequest.builder()
        .messages(UserMessage.from(prompt))
        .build()).aiMessage().text();
}

특징:

Gemini 2.0 Flash (빠른 응답)
자동 동의어 확장
JSON 응답만 추출

Step 2: JSON 파싱 및 검증

private Map<String, Object> parseSearchCriteria(String json) throws Exception {
    JsonNode node = objectMapper.readTree(json);
    Map<String, Object> criteria = new HashMap<>();

    criteria.put("company", node.has("company") ? 
        node.get("company").asText() : null);
    criteria.put("experience_level", node.has("experience_level") ? 
        node.get("experience_level").asText() : null);
    criteria.put("keyword", node.has("keyword") ? 
        node.get("keyword").asText() : null);
    criteria.put("limit", node.has("limit") ? 
        node.get("limit").asInt() : 10);

    return criteria;
}

Step 3: PreparedStatement로 안전한 SQL 생성

private List<Map<String, Object>> buildAndExecuteQuery(Map<String, Object> criteria) 
        throws SQLException {

    validateInput(criteria);  // 길이/범위 검증

    StringBuilder sql = new StringBuilder();
    sql.append("SELECT t.id, t.title, t.link, c.name as company_name, ");
    sql.append("       d.level, d.job_type, d.description, t.created_at ");
    sql.append("FROM job t ");
    sql.append("LEFT JOIN detail d ON t.id = d.job_id ");
    sql.append("LEFT JOIN company c ON t.company_id = c.id ");
    sql.append("WHERE t.status != 'DELETED' ");

    List<Object> params = new ArrayList<>();

    // 회사명 필터
    String company = (String) criteria.get("company");
    if (company != null && !company.isEmpty()) {
        sql.append("AND (c.name ILIKE ? OR c.alias ILIKE ?) ");
        params.add("%" + company.trim() + "%");
        params.add("%" + company.trim() + "%");
    }

    // 키워드 필터 (공백 분할 → OR)
    String keyword = (String) criteria.get("keyword");
    if (keyword != null && !keyword.isEmpty()) {
        String[] words = keyword.trim().split("\\s+");
        sql.append("AND (");
        for (int i = 0; i < words.length; i++) {
            if (i > 0) sql.append(" OR ");
            sql.append("(t.title ILIKE ? OR d.description ILIKE ?)");
            params.add("%" + words[i] + "%");
            params.add("%" + words[i] + "%");
        }
        sql.append(") ");
    }

    int limit = (Integer) criteria.getOrDefault("limit", 10);
    sql.append("ORDER BY t.created_at DESC LIMIT ?");
    params.add(limit);

    // 쿼리 실행
    try (Connection conn = dataSource.getConnection();
         PreparedStatement pstmt = conn.prepareStatement(sql.toString())) {

        pstmt.setQueryTimeout(5);
        for (int i = 0; i < params.size(); i++) {
            Object param = params.get(i);
            if (param instanceof String) {
                pstmt.setString(i + 1, (String) param);
            } else if (param instanceof Integer) {
                pstmt.setInt(i + 1, (Integer) param);
            }
        }

        List<Map<String, Object>> results = new ArrayList<>();
        try (ResultSet rs = pstmt.executeQuery()) {
            while (rs.next()) {
                Map<String, Object> row = new HashMap<>();
                ResultSetMetaData meta = rs.getMetaData();
                for (int i = 1; i <= meta.getColumnCount(); i++) {
                    row.put(meta.getColumnLabel(i), rs.getObject(i));
                }
                results.add(row);
            }
        }
        return results;
    }
}

보안 기능:

PreparedStatement 사용 (SQL Injection 방지)
입력 길이 검증 (100자 제한)
limit 범위 제한 (최대 20)
5초 타임아웃

기술 스택

구성	기술	설명
LLM	Gemini 2.0 Flash	무료 플랜, 빠른 응답
라이브러리	LangChain4j	Java LLM 통합
SQL 보안	PreparedStatement	파라미터 바인딩
JSON	Jackson	타입 안전 파싱
DB	PostgreSQL	ILIKE 검색 지원

설정 방법

Gemini API 키 발급

공식 링크: https://aistudio.google.com/

API 키 발급 후 복사

build.gradle 의존성

dependencies {
    implementation 'dev.langchain4j:langchain4j-google-ai-gemini:VERSION'
    implementation 'dev.langchain4j:langchain4j-core:VERSION'
    implementation 'com.fasterxml.jackson.core:jackson-databind:VERSION'
}

환경 설정

GEMINI_API_KEY=YOUR_API_KEY_HERE
GEMINI_MODEL=gemini-2.0-flash

결론

Gemini + LangChain4j + PreparedStatement로 안전하면서도 유연한 자연어 검색을 구현했습니다. LLM이 자연어를 구조화 데이터로 변환하고, 검증된 데이터로만 SQL을 조립해 보안과 사용성을 모두 확보했습니다.

무료 플랜으로도 실무 프로토타입 구현이 가능합니다.

[Supabase] DB 연결 실패? Connection Pool Size 부족 문제 해결하기

snapcoder — Thu, 12 Feb 2026 01:01:15 +0900

무료형 SaaS DB를 처음 써보는 것이기도 하고, 이렇게 작게 기본값이 되어 있을 줄 몰랐다.

문제 상황

Supabase Postgres를 사용하던 중, Spring Boot 애플리케이션에서 간헐적으로 DB 명령문이 실행되지 않는 현상이 발생했다.

❌ [ERROR] java.sql.SQLException: Cannot connect to database
org.postgresql.util.PSQLException: too many connections for role "user_account"

검색해보니 Supabase의 기본 Connection Pool Size가 너무 작다는 것이 원인이었다.

원인 분석

Supabase는 Compute Size(사양)에 따라 기본 Pool Size가 결정된다.

Compute Size	Default Pool Size
Nano	15
Small	30
Medium	60
Large	100

우리 프로젝트는 Nano 사양에 기본값 15로 설정되어 있었다. 이는 동시에 15개 이상의 데이터베이스 연결이 필요한 경우 새로운 요청을 수용할 수 없다는 뜻이다.

Spring Boot의 HikariCP 기본 설정:

Maximum Pool Size: 10
Minimum Idle: 10

즉, 최악의 경우 HikariCP만 10개, 그 외 시스템 연결 5개로 이미 Pool이 가득 찬다.

해결 방법

방법 1: Supabase 콘솔에서 Pool Size 증가 (권장)

Supabase 대시보드 > 프로젝트 선택
Settings > Database > Connection Pooling
Pool size 변경 (기본값 → 30 이상)

[Before] Default Pool Size: 15
[After]  Pool Size: 30 ← 변경

방법 2: Spring Boot Connection Pool 최적화

application.yml 또는 application.properties 설정:

spring:
  datasource:
    hikari:
      maximum-pool-size: 8        # 풀 최대 사이즈 감소
      minimum-idle: 2             # 최소 유휴 연결 감소
      idle-timeout: 60000         # 유휴 연결 타임아웃
      max-lifetime: 1800000       # 최대 연결 유지시간
      auto-commit: true

또는 환경변수로 설정:

SPRING_DATASOURCE_HIKARI_MAXIMUM_POOL_SIZE=8
SPRING_DATASOURCE_HIKARI_MINIMUM_IDLE=2

방법 3: 동시 요청 수 제한 (임시방편)

요청 수를 줄이는 것도 하나의 방법이다.

// application.yml
server:
  tomcat:
    threads:
      max: 10              # 동시 요청 수 제한
      min-spare: 5

개선 결과

로그에서 에러가 사라졌다.

✅ [BEFORE] ❌ DB 연결 오류: too many connections
✅ [AFTER]  ✅ DB 검색 완료: '백엔드' (150ms, 결과: 42건)

주의사항

Pool Size를 무한정 늘릴 수 없다
- Supabase 구독 계획에 따라 최대값이 결정됨
- Nano → Small/Medium 업그레이드로 해결 가능
Spring의 HikariCP 설정도 함께 조정해야 한다
- Supabase Pool Size > HikariCP Maximum Pool Size
- 설정 안 하면 여전히 연결 실패 가능

결론

Supabase 기본 설정은 소규모 프로젝트 기준이다. 동시 요청이 많거나 여러 도구가 DB를 공유하는 경우, Pool Size를 명시적으로 증가시키는 것이 필수다.

[PlayMCP] 내가 만든 MCP 서버를 카카오에 등록하다.

snapcoder — Wed, 11 Feb 2026 20:33:55 +0900

오늘 드디어 MCP 서버를 배포했습니다.

원래 공모전이 뜨자마자 @DBrider3와 참가하려했지만, 일정상 참가하진 못했고, 이렇게 만들어보았습니다.

https://playmcp.kakao.com/

PlayMCP | 새로운 AI 경험의 시작

PlayMCP와 함께하는 AI 에이전트 세상, 새로운 AI 경험을 만들어 보세요.

playmcp.kakao.com

아직 심사 전이지만, 앞으로의 기능 확장이 기대됩니다.

등록화면

Inspector 테스트 성공 화면

MCP 서버 적용 및 사용 화면

마치며

참고로, 저처럼 MCP 서버를 만들어보고자 하신다면,

아래 가이드를 우선적으로 읽으시면 좋을 것 같습니다.

카카오에서 공식 배포한 가이드입니다.

https://www.notion.so/MCP-2d89b97b4888808a9e1dc17a13e70187

추가적으로, 디테일 정보들이 흩뿌려져있습니다.

MCP 서버 생성 가이드에서는 못본 것 같은데

MCP 심사 정책 에는 응답크기 제한 등의 내용이 있었던 것 같습니다

개발 전에 여러 문서를 빠르게라도 한번 쭉 읽어보시고 진행하시면 좋을 것 같습니다

감사합니다.

참고링크

가이드 : https://www.notion.so/MCP-2d89b97b4888808a9e1dc17a13e70187

도움말 : https://www.notion.so/2189b97b4888803dbbdcef264e7eff58

심사정책 : https://www.notion.so/21b9b97b48888024922ec3dfcacf97e5

json schema : https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/schema/2025-03-26/schema.json

[MCP] JSON 응답 vs 스트리밍, 실전에서 고른 구현 방식

snapcoder — Mon, 9 Feb 2026 23:13:15 +0900

Model Context Protocol(MCP)로 AI에 기능을 붙일 때, 경량 구현과 스트리밍 중 뭘 선택할까? 각 방식의 장단점을 비교하고 선택 기준을 정리했습니다.

두 가지 패턴

1️⃣ 경량 구현: 한 번에 응답

사용자 → AI 에이전트 → [요청] → MCP 서버
                    ← [2초 대기] ←
                    ← [전체 데이터] ←

핵심: HTTP POST/JSON으로 한 번의 왕복으로 완성된 응답 반환

요청 예시

curl -X POST http://localhost:8080/api/mcp/call_tool \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/call",
    "params": {
      "name": "search_jobs",
      "arguments": {"query": "백엔드"}
    }
  }'

응답 예시

{
  "jsonrpc": "2.0",
  "result": {
    "content": [{
      "type": "json",
      "data": [
        {"id": 1, "company": "Company A", "role": "Backend Engineer"},
        {"id": 2, "company": "Company B", "role": "Senior Backend"}
      ]
    }]
  }
}

구현 예시 (Java)

@PostMapping("/api/mcp/call_tool")
public MCPResponse callTool(@RequestBody MCPRequest request) {
    try {
        MCPResult result = tool.execute(request.getParams());
        response.setResult(result);
    } catch (Exception e) {
        response.setError(new MCPError(-1, e.getMessage()));
    }
    return response;
}

2️⃣ 스트리밍: 실시간 응답

사용자 → AI 에이전트 → [요청] → MCP 서버
                    ← [0.2초] ← [첫 데이터]
                    ← [0.2초] ← [두 번째 데이터]
                    ← [0.2초] ← [세 번째 데이터]

핵심: SSE/WebSocket으로 데이터를 조금씩 실시간 스트리밍

요청 예시

curl -N http://localhost:8080/api/mcp/stream_tool?tool=search_jobs&query=backend

응답 스트림 예시

event: tool_result
data: {"id": 1, "company": "Company A", "role": "Backend Engineer"}

event: tool_result
data: {"id": 2, "company": "Company B", "role": "Senior Backend"}

event: done
data: {"status": "completed"}

구현 예시 (Java / SseEmitter)

@GetMapping("/stream_tool")
public SseEmitter streamTool(@RequestParam String tool, @RequestParam String query) {
    SseEmitter emitter = new SseEmitter(60000L);

    new Thread(() -> {
        try {
            List<Map<String, Object>> results = searchJobsFromDB(query);
            for (Map<String, Object> result : results) {
                Thread.sleep(200);
                emitter.send(SseEmitter.event()
                    .name("tool_result")
                    .data(result));
            }
            emitter.send(SseEmitter.event().name("done").data("{}"));
            emitter.complete();
        } catch (IOException e) {
            emitter.completeWithError(e);
        }
    }).start();

    return emitter;
}

⚖️ 비교표

항목	경량 구현	스트리밍
개발 시간	⏱️ 30분	⏱️ 2시간
응답 첫 데이터	2~5초	0.5초
대역폭 사용	한 번에 모두	점진적
UX	"로딩 중..."	실시간 글자
디버깅	✅ 쉬움	❌ 어려움
에러 처리	✅ 간단	❌ 복잡
서버 리소스	✅ 효율적	❌ 많이 소모
배포 난이도	✅ 낮음	❌ 높음

✅ 경량 구현 선택 기준

장점

기존 REST API 로직 재활용
Postman에서 간단히 테스트
추가 설정 불필요
멀티스레딩/비동기 처리 불필요

단점

데이터가 많으면 대기 시간 증가
실시간 느낌 없음
느린 네트워크에서 불편

적합한 경우

✅ 데이터 크기 < 1MB
✅ 응답 시간 < 5초 허용
✅ 채용공고 검색, 날씨, 주식 정보
✅ 서버 리소스 제한적

스트리밍 선택 기준

장점

0.5초부터 데이터 도착
ChatGPT처럼 실시간 답변
점진적 대역폭 사용
AI가 첫 데이터부터 병렬 처리 가능

단점

SseEmitter/WebSocket 복잡한 구현
스레드 관리 어려움
에러 처리 복잡
프록시/타임아웃 설정 필요 (Nginx)

적합한 경우

✅ 데이터 크기 > 10MB
✅ 실시간 느낌 필수
✅ AI 텍스트 생성, 비디오/음성 스트리밍
✅ 서버 리소스 충분

CareerLens 프로젝트: 경량 구현 선택

이 프로젝트는 경량 구현을 채택했습니다.

선택 이유

이유	설명
데이터량	채용공고 20~50개 (약 500KB)
응답 시간	1~2초 대기 허용
개발 시간	4시간 내 완성 필요
배포	기존 Spring Boot 그대로 사용

사용자 경험

사용자: "백엔드 개발자 공고 찾아"
↓ (1초 대기)
AI: "백엔드 개발자는 45개 공고가 있습니다.
    경력 3년 이상 권장하며, 연봉은
    8,000만~1억5,000만원대입니다."

실제 구현

@PostMapping("/api/mcp/call_tool")
public MCPResponse callTool(@RequestBody MCPRequest request) {
    // 1. 요청 검증
    // 2. Tool 조회
    // 3. DB 쿼리 (동기)
    // 4. JSON-RPC 응답 반환
}

향후 개선

사용자가 실시간 스트리밍을 요구하면:

Phase 2: SSE 엔드포인트 추가
GET /api/mcp/stream_tool → 스트리밍 응답

현 단계에서는 단순함이 최고의 설계입니다.

참고 자료

[Next.js] 카카오톡 썸네일 공유 기능 추가 - OG 메타 태그 설정방법

snapcoder — Mon, 9 Feb 2026 01:49:20 +0900

제미나이로 OG 이미지부터 만드는중...

[Next.js] [Next.js] 카카오톡 썸네일 공유 기능 추가 - OG 메타 태그 설정방법

웹사이트를 카카오톡/페이스북에 공유할 때 썸네일이 안 뜨는 문제를 OG 메타 태그로 5분 안에 해결합니다.

문제: 카카오톡 공유 시 썸네일 미표시

Next.js 프로젝트를 배포했는데, 링크를 카카오톡에 붙여 넣어도 썸네일 이미지가 나오지 않습니다.

❌ 예상: 썸네일 이미지 + 제목 + 설명
✅ 현실: 텍스트만 표시됨

원인: Open Graph(OG) 메타 태그 미설정

해결방법

1️⃣ 썸네일 이미지 준비

크기: 1200x630px (카카오톡, 페이스북 표준)

frontend/
└── public/
    └── og-image.png

2️⃣ Next.js Metadata 설정

파일: app/layout.tsx

import type { Metadata } from "next";

export const metadata: Metadata = {
  title: "MyService - 스마트 검색 플랫폼",
  description: "AI가 분석해주는 스마트 검색 경험",

  openGraph: {
    title: "MyService - 스마트 검색 플랫폼",
    description: "AI가 분석해주는 스마트 검색 경험",
    type: "website",
    url: "https://example-domain.com",
    images: [
      {
        url: "https://example-domain.com/og-image.png",
        width: 1200,
        height: 630,
        alt: "MyService 썸네일"
      }
    ]
  }
};

3️⃣ 필수 필드

필드	역할	예시
`og:title`	제목	"MyService - 스마트 검색"
`og:description`	설명	"AI 분석 검색"
`og:image`	썸네일	"https://example.com/og-image.png"
`og:url`	페이지 URL	"https://example.com/"
`og:type`	콘텐츠 타입	"website"

✅ 테스트

카카오톡: 채팅창에 링크 입력 → 미리보기 확인

온라인 검증: https://metatags.io 에서 URL 입력 후 미리보기

⚠️ 주의사항

1. 이미지 경로는 절대 URL

// ❌ 상대 경로 (작동 안 함)
url: "/og-image.png"

// ✅ 절대 URL (작동함)
url: "https://example-domain.com/og-image.png"

2. 캐시 문제

SNS가 캐시하고 있으면 변경사항이 반영되지 않을 수 있습니다.

카카오톡: URL 다시 입력
페이스북: 검증 도구에서 "Scrape Again"

3. 이미지 사양

권장: 1200x630px
최대: 300KB 이하
형식: PNG, JPG

보너스: Twitter Card

트위터도 지원하려면:

twitter: {
  card: "summary_large_image",
  title: "MyService - 스마트 검색",
  description: "AI 분석 검색",
  images: ["https://example-domain.com/og-image.png"]
}

정리

단계	소요 시간
이미지 준비	5분
코드 수정	2분
배포	1분
총합	8분

이제 공유 링크에 썸네일이 표시됩니다!

전

후
(카카오톡 채팅방 캐시가 살아있을 수 있어서, 새 URL로 공유하면 즉시 테스트 가능합니다. => https://{도메인}/?v=1 )

[정부API] "개인회원은 사용할 수 없습니다": 공공데이터 Open API 사용기

snapcoder — Wed, 28 Jan 2026 20:31:57 +0900

본문

배경: 설레는 마음으로 시작한 API 연동

Career Lens 프로젝트를 진행하면서 채용정보를 실시간으로 제공하고 싶었습니다. 마침 한국고용정보원(워크넷)에서 제공하는 "채용정보 API"를 발견했고, 공공데이터포털에서 Open API 서비스라고 명시되어 있었습니다.

생각: "오! 공공데이터면 누구나 쓸 수 있겠지?"

현실: "개인회원은 사용할 수 없는 OPEN-API입니다."

상황 분석: 뭐가 문제지?

1단계: 인증키 신청

공공데이터포털(data.go.kr)에서 "한국고용정보원_워크넷 채용정보" API를 검색

  API 정보
- 제공기관: 한국고용정보원
- API 유형: LINK
- 데이터포맷: XML
- 활용신청: 8,597명
- 비용: 무료

"무료이고, 활용신청이 8,000명 이상? 대박이네!"라고 생각했습니다.

2단계: 인증키 발급

고용24 공식 사이트(work24.go.kr)에서:

회원가입 (개인회원으로)
OPEN-API 서비스 신청
담당자 심사 (24시간 이내 완료)
인증키 발급 ✅

"야! 인증키도 받았다. 이제 API 호출하면 되겠지?"

3단계: API 호출 및 절망

GET https://www.sample-api-gateway.go.kr/cm/openApi/call/wk/callOpenApiSvcInfo210L01.do
?authKey=sample_auth_key_abc123def456
&callTp=L
&returnType=XML
&startPage=1
&display=10

응답:

<?xml version="1.0" encoding="UTF-8"?>
<GO24>
  <script/>
  <error>개인회원은 사용할 수 없는 OPEN-API입니다.</error>
</GO24>

이 순간의 심정:

원인 분석: "공공"의 정의가 다르다?

공공데이터포털의 설명과 실제 API 사용 정책이 다릅니다.

공공데이터포털 설명

"채용정보 API를 이용하여 다양한 카테고리의 구인정보를 구성할 수 있습니다.
키워드, 직종, 희망지역을 토대로 나에게 맞는 일자리를 검색할 수 있습니다."

마치 누구나 쓸 수 있는 것처럼 표현

고용24 OPEN-API 이용안내

"OPEN-API는 고용24 기업회원 전용 서비스입니다.
비회원인 경우 회원가입 후 이용 가능합니다."

개인회원은 원천 차단

공식 공지사항 (최근 추가)

"워크넷 OPEN-API 개인회원 개방 안내"

아, 최근에 일부 API는 개인회원도 개방되기 시작했다고?

️ 가능한 해결 방법

방법 1: 기업회원으로 전환

❌ 장점: 모든 API 사용 가능
❌ 단점: 사업자등록증 필요, 복잡한 승인 절차

방법 2: 다른 공개 API 찾기

✅ 장점: 제약 없음
✅ 단점: 데이터 품질과 최신성 미보장

가능한 대안 API:

Indeed API - 국내 미지원
LinkedIn Jobs API - 개인사용자 접근 제한
GitHub Jobs API - 기술직 중심
웹 스크래핑 - 법적/윤리적 이슈 고려 필요

방법 3: 공공데이터포털에 개선 요청

고객센터: 1566-0025
개선의견: "개인 개발자도 사용 가능하도록 정책 개선"
공식 채널: 공공데이터포털 → 개선의견 게시판

배운 점: "무료"와 "누구나"는 다르다

공공데이터 API 사용 전 체크리스트

항목	확인 사항
✅ 비용	무료인가?
⚠️ 접근 권한	개인/기업/모두 가능한가?
⚠️ 심사 기간	기업심사는 얼마나 걸리는가?
⚠️ 제한사항	상업이용, 수정, 배포 가능한가?
⚠️ 문서 신뢰성	공공데이터포털 vs 제공기관 사이트 일치하는가?
⚠️ SLA	장애 시 책임은 누가 지는가?

참고 자료

공공데이터포털: https://www.data.go.kr/
워크넷 고용24: https://www.work24.go.kr/
공공데이터포털 고객센터: 1566-0025
고용24 고객센터: 1577-7114

당신의 경험은?

혹시 공공데이터 API를 사용하면서 비슷한 경험이 있으신가요?
또는 좋은 대안 API가 있다면 댓글로 공유해주세요!

[Spring Security] 자동화된 봇 공격 분석 및 방어: 로그 노이즈 90% 제거하기

snapcoder — Wed, 28 Jan 2026 00:59:30 +0900

[Spring Security] 자동화된 봇 공격 분석 및 방어: 로그 노이즈 90% 제거하기

배경: 아직은 사용자가 나밖에 없는데.. 갑자기 증가한 로그 (귀신이 왔다갔나...)

프로덕션 서버에 배포한 Career Lens 애플리케이션(example.com)의 Docker 컨테이너 로그를 확인했을 때, 이상한 패턴의 에러 메시지들이 대량으로 쌓여 있었습니다.

2026-01-27T02:06:08.623+09:00  WARN --- Request method 'POST' is not supported
2026-01-27T02:44:09.104+09:00  INFO Error parsing HTTP request header
java.lang.IllegalArgumentException: Invalid character found in method name [0x050x010x00...]

처음엔 애플리케이션 버그인 줄 알고 당황했지만, 자세히 분석해보니 외부 공격이었습니다.

로그 분석: 무엇이 일어났는가?

에러 유형별 분류

에러 유형	발생 빈도	원인
`HttpRequestMethodNotSupportedException: Request method 'POST'`	매우 높음	잘못된 HTTP 메서드 사용 시도
`Invalid character found in method name [0x05...]`	높음	이진 데이터를 HTTP 헤더로 전송
`/index.php?s=/index/\think\app/invokefunction`	중간	ThinkPHP RCE 취약점 공격
`PROPFIND 요청`	낮음	WebDAV 메서드를 이용한 시스템 스캔
`Path with "WEB-INF"` 접근 시도	낮음	서블릿 내부 경로 탐색

공격자 프로필

대상: 인터넷 전체 포트 80/443 스캔
목표: PHP 기반 애플리케이션 취약점 찾기
전술: CVE 기반 자동화된 스캔 봇
위험도:   낮음 (Java 애플리케이션은 PHP 취약점에 면역)

특히 주목할 점은 /index.php?s=/index/\think\app/invokefunction&function=call_user_func_array 같은 ThinkPHP 익스플로잇 공격이었다는 것입니다. 이는 자동화된 취약점 스캔 봇이 모든 서버에 일괄 공격을 퍼붓는 전형적인 패턴입니다.

해결 방법: 3단계 방어 전략

Step 1️⃣: 로깅 설정 최적화

application.properties에 추가:

# 악의적 요청 로그 노이즈 제거
logging.level.org.apache.coyote.http11.Http11Processor=WARN
logging.level.org.apache.catalina=WARN
logging.level.org.apache.tomcat=WARN
logging.level.org.springframework.security=INFO
logging.level.org.springframework.web.servlet.mvc.method.annotation=WARN

효과:

Invalid character found... 같은 반복 로그가 INFO/DEBUG 레벨에서 WARN으로 상향 조정
실제 에러만 화면에 표시
로그 노이즈 90% 감소 ✅

Step 2️⃣: Spring Security 의존성 추가

build.gradle에 추가:

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-security'
}

Step 3️⃣: SecurityConfig 클래스로 강화된 보안 설정

src/main/java/com/example/config/SecurityConfig.java:

package com.example.config;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.web.SecurityFilterChain;
import org.springframework.web.cors.CorsConfiguration;
import org.springframework.web.cors.CorsConfigurationSource;
import org.springframework.web.cors.UrlBasedCorsConfigurationSource;

import java.util.Arrays;
import java.util.logging.Logger;

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    private static final Logger logger = Logger.getLogger(SecurityConfig.class.getName());

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
            .cors(cors -> cors.configurationSource(corsConfigurationSource()))
            .csrf(csrf -> csrf.ignoringRequestMatchers("/api/**"))
            .authorizeHttpRequests(auth -> auth.anyRequest().permitAll())
            .headers(headers -> headers
                .frameOptions(frameOptions -> frameOptions.deny())
                .httpStrictTransportSecurity(hsts -> hsts
                    .maxAgeInSeconds(31536000)
                    .includeSubDomains(true)
                )
            );

        logger.info("✅ Spring Security 설정 완료");
        return http.build();
    }

    @Bean
    public CorsConfigurationSource corsConfigurationSource() {
        CorsConfiguration configuration = new CorsConfiguration();
        configuration.setAllowedOrigins(Arrays.asList(
            "http://localhost:3000",
            "http://localhost:8080",
            "https://example.com"
        ));
        configuration.setAllowedMethods(Arrays.asList(
            "GET", "POST", "PUT", "DELETE", "OPTIONS"
        ));
        configuration.setAllowedHeaders(Arrays.asList(
            "Content-Type", "Authorization"
        ));
        configuration.setAllowCredentials(true);
        configuration.setMaxAge(3600L);

        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**", configuration);

        logger.info("✅ CORS 설정 완료");
        return source;
    }
}

결과: 보안 강화 체크리스트

항목	적용 여부	효과
✅ 로그 레벨 조정	O	로그 노이즈 90% 감소
✅ HTTP 메서드 검증	O	이상한 요청 자동 차단
✅ CORS 제한	O	신뢰할 수 있는 도메인만 API 접근
✅ CSRF 보호	O	크로스사이트 요청 위조 방지
✅ 보안 헤더	O	XSS, Clickjacking, MIME 스니핑 방지
✅ HTTPS 강제	O	모든 통신 암호화

결론

자동화된 봇 공격은 계속 들어올 것입니다. 하지만 이제 우리의 서버는:

로그가 깔끔해져서 실제 에러를 쉽게 파악 가능
보안이 강화되어 대부분의 공격이 자동으로 차단됨
개발자 경험 개선으로 배포 후 모니터링이 효율적

Java + Spring Security의 조합으로 PHP 공격에는 완전히 안전하며, 로깅 설정으로 노이즈까지 제거했습니다.

참고 자료

Spring Security 6.1+ 공식 문서: https://docs.spring.io/spring-security/reference/
OWASP Top 10: https://owasp.org/www-project-top-ten/
HTTP 보안 헤더: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers

[Docker] 컨테이너 파일을 서버에 마운트하기 : Docker + Volume Mount

snapcoder — Tue, 27 Jan 2026 00:38:48 +0900

문제: 컨테이너의 파일을 호스트에서 어떻게 접근할까?

일반적인 상황:

Docker 컨테이너 내부
└─ /app/crawler/main.py (크롤러 파일)

호스트(서버) 시스템
└─ /home/opc/career-lens/crawler/ (비어있음  )

크론잡
└─ python3 /home/opc/career-lens/crawler/main.py 
   (파일이 없어서 실행 불가!)

원인: 컨테이너와 호스트의 파일시스템이 분리되어 있음

✨ 해결책: Docker Volume Mount (-v 옵션)

docker run -v /app/crawler:/home/opc/career-lens/crawler \
  career-lens:latest

의미:

컨테이너의 /app/crawler/
↔️ 호스트의 /home/opc/career-lens/crawler/
양방향으로 동기화!

️ 파일시스템 마운트 구조

Before (마운트 없음)

┌─────────────────────────────┐
│   Docker 컨테이너           │
│  ┌───────────────────────┐  │
│  │ /app/crawler/         │  │
│  │ ├─ main.py ✅         │  │
│  │ ├─ config.py ✅       │  │
│  │ └─ crawlers/ ✅       │  │
│  └───────────────────────┘  │
│   (컨테이너 내부에만 존재)  │
└─────────────────────────────┘

┌─────────────────────────────┐
│   호스트(서버) 시스템       │
│  ┌───────────────────────┐  │
│  │ /home/opc/crawler/    │  │
│  │ (비어있음) ❌         │  │
│  └───────────────────────┘  │
└─────────────────────────────┘

❌ 파일 접근 불가능

After (Volume Mount 적용)

┌─────────────────────────────┐
│   Docker 컨테이너           │
│  ┌───────────────────────┐  │
│  │ /app/crawler/         │  │
│  │ ├─ main.py ✅         │  │
│  │ ├─ config.py ✅       │  │
│  │ └─ crawlers/ ✅       │  │
│  └─────────┬─────────────┘  │
│            │ 마운트 (-v)     │
└────────────┼─────────────────┘
             │
┌────────────↓─────────────────┐
│   호스트(서버) 시스템        │
│  ┌───────────────────────┐   │
│  │ /home/opc/crawler/    │   │
│  │ ├─ main.py ✅         │   │
│  │ ├─ config.py ✅       │   │
│  │ └─ crawlers/ ✅       │   │
│  └───────────────────────┘   │
│                              │
│  ⬅ 크론잡이 여기서 읽음       │
└──────────────────────────────┘

✅ 양방향 동기화 완벽!

구현: Docker Volume Mount

1️⃣ Dockerfile - 컨테이너에 파일 포함

FROM eclipse-temurin:17-jdk-jammy

# JAR 파일 복사
ADD ./build/libs/*.jar careerlensApp.jar

# ✅ 핵심: 호스트의 crawler/ 폴더를 컨테이너에 복사
COPY crawler/ /app/crawler/

EXPOSE 80
EXPOSE 443

ENTRYPOINT ["java", "-Xmx256m", "-Xms128m", "-Duser.timezone=Asia/Seoul", "-jar", "/careerlensApp.jar"]

포인트:

COPY crawler/ /app/crawler/ → 빌드 시점에 호스트 파일을 컨테이너로 복사
컨테이너 내부 경로: /app/crawler/

2️⃣ Docker Run - Volume Mount 설정

docker run -d \
  --name career-lens \
  -p 80:80 \
  -p 443:443 \
  -v /etc/letsencrypt:/etc/letsencrypt:ro \
  -v /app/crawler:/home/opc/career-lens/crawler \
  --user root \
  career-lens:latest

핵심 라인 분석:

-v /app/crawler:/home/opc/career-lens/crawler
   │ 컨테이너 경로  │ 호스트 경로

   컨테이너 파일시스템
   └─ /app/crawler/
      ├─ main.py
      ├─ config.py
      └─ crawlers/

          ↕️ 양방향 마운트

   호스트 파일시스템
   └─ /home/opc/career-lens/crawler/
      ├─ main.py
      ├─ config.py
      └─ crawlers/

마운트 옵션 설명:

옵션	설명
`-v`	Volume Mount (파일시스템 마운트)
`/app/crawler`	컨테이너 내부 경로
`/home/opc/career-lens/crawler`	호스트 시스템 경로
(기본값)	양방향 읽기/쓰기
`:ro`	Read-Only (읽기만 가능)

3️⃣ GitHub Actions 배포 스크립트

# 호스트 경로 준비
mkdir -p /home/opc/career-lens/crawler
echo "✅ 호스트 마운트 경로 준비 완료"

# 컨테이너 시작 + Volume Mount
docker run -d \
  --name career-lens \
  -p 80:80 \
  -p 443:443 \
  -e SPRING_PROFILES_ACTIVE=prd \
  -e DB_USERNAME=${{ secrets.DB_USERNAME }} \
  -e DB_PASSWORD=${{ secrets.DB_PASSWORD }} \
  -v /etc/letsencrypt:/etc/letsencrypt:ro \
  -v /app/crawler:/home/opc/career-lens/crawler \
  --user root \
  career-lens:latest

# 마운트 검증
echo "  Volume Mount 확인:"
docker exec career-lens ls -la /app/crawler/

✅ 실제 적용 결과

컨테이너 내부 (마운트된 경로)

$ docker exec career-lens ls -la /app/crawler/
total 28
drwxr-xr-x. 3 root root  126 Jan 26 15:26 .
drwxr-xr-x. 3 root root   21 Jan 26 15:28 ..
-rw-r--r--. 1 root root  562 Jan 26 15:26 config.py
drwxr-xr-x. 2 root root   97 Jan 26 15:26 crawlers
-rw-r--r--. 1 root root  915 Jan 26 15:26 logger.py
-rw-r--r--. 1 root root 4452 Jan 26 15:26 main.py
-rw-r--r--. 1 root root    1 Jan 26 15:26 README.md
-rw-r--r--. 1 root root  113 Jan 26 15:26 requirements.txt
-rw-r--r--. 1 root root  393 Jan 26 15:26 run.sh

호스트 파일시스템 (마운트된 경로)

$ ls -la /home/opc/career-lens/crawler/
total 28
drwxr-xr-x. 3 opc opc 126 Jan 26 15:26 .
drwxr-xr-x. 3 opc opc  21 Jan 26 15:28 ..
-rw-r--r--. 1 opc opc 562 Jan 26 15:26 config.py
drwxr-xr-x. 2 opc opc  97 Jan 26 15:26 crawlers
-rw-r--r--. 1 opc opc 915 Jan 26 15:26 logger.py
-rw-r--r--. 1 opc opc 4452 Jan 26 15:26 main.py
-rw-r--r--. 1 opc opc 113 Jan 26 15:26 requirements.txt
-rw-r--r--. 1 opc opc 393 Jan 26 15:26 run.sh

✅ 완벽하게 동기화됨!

양방향 동기화 흐름

변경 흐름 1: 컨테이너 파일 변경 → 호스트 반영

1️⃣ 컨테이너 내부에서 파일 수정
   $ docker exec career-lens echo "수정됨" > /app/crawler/main.py

2️⃣ 호스트 파일시스템에 자동 반영
   $ cat /home/opc/career-lens/crawler/main.py
   수정됨 ✅

3️⃣ 크론잡이 최신 파일 읽음
   0 9 * * * python3 /home/opc/career-lens/crawler/main.py
   (최신 버전으로 실행!)

변경 흐름 2: 호스트 파일 변경 → 컨테이너 반영

1️⃣ 호스트 파일시스템에서 파일 수정
   $ echo "호스트에서 수정" > /home/opc/career-lens/crawler/config.py

2️⃣ 컨테이너 내부에 자동 반영
   $ docker exec career-lens cat /app/crawler/config.py
   호스트에서 수정 ✅

3️⃣ 컨테이너의 애플리케이션이 최신 설정 읽음
   (config.py가 변경되었으므로 자동 리로드)

Volume Mount 원리

파일시스템 마운트란?

마운트 = 두 파일시스템을 연결하는 작업

-v /app/crawler:/home/opc/career-lens/crawler
  ↓
  "컨테이너의 /app/crawler/ 디렉토리를
   호스트의 /home/opc/career-lens/crawler/ 에 마운트하라"
  ↓
  결과: 두 경로가 동일한 파일을 가리킴

호스트 입장에서의 마운트

# 마운트 확인
$ mount | grep crawler
# 또는
$ df /home/opc/career-lens/crawler/

# 마운트 정보 상세 보기
$ docker inspect career-lens --format='{{json .Mounts}}' | python3 -m json.tool

출력 예:

[
  {
    "Type": "bind",
    "Source": "/app/crawler",
    "Destination": "/home/opc/career-lens/crawler",
    "Mode": "",
    "RW": true,
    "Propagation": "rprivate"
  }
]

마운트 유형 비교

유형	문법	설명	사용처
Bind Mount	`-v /host:/container`	호스트 경로를 컨테이너에 마운트	파일 공유
Named Volume	`-v myvolume:/container`	Docker가 관리하는 볼륨	데이터 보존
tmpfs	`--tmpfs /container`	메모리 기반 임시 파일시스템	임시 파일

우리의 경우:

-v /app/crawler:/home/opc/career-lens/crawler
→ Bind Mount 사용
→ 호스트의 실제 디렉토리를 마운트

주의사항

1️⃣ 호스트 경로 미리 생성

# ❌ 이렇게 하면 안 됨
docker run -v /app/crawler:/nonexistent/path ...

# ✅ 이렇게 해야 함
mkdir -p /home/opc/career-lens/crawler
docker run -v /app/crawler:/home/opc/career-lens/crawler ...

2️⃣ 권한 문제

# 호스트에서 권한 확인
ls -la /home/opc/career-lens/crawler/

# 권한 조정 필요 시
chmod 755 /home/opc/career-lens/crawler/
chown opc:opc /home/opc/career-lens/crawler/

3️⃣ 파일 덮어쓰기

# 호스트와 컨테이너가 동일한 파일을 가짐
# 한쪽에서 삭제하면 다른 쪽에서도 삭제됨

docker exec career-lens rm /app/crawler/main.py
# → /home/opc/career-lens/crawler/main.py 도 삭제됨!

실전 예제

크론잡에서 마운트된 파일 사용

# Crontab 설정
$ crontab -e

# 추가
0 9 * * * python3 /home/opc/career-lens/crawler/main.py >> /var/log/crawler.log 2>&1

동작:

매일 9시에 크론잡 실행
/home/opc/career-lens/crawler/main.py 실행 (마운트된 경로)
컨테이너의 /app/crawler/main.py와 동일한 파일
최신 코드로 자동 반영!

호스트에서 로그 수집

# 컨테이너에서 생성한 로그를 호스트에서 읽기
docker exec career-lens cat /app/crawler/logs/output.log

# 또는 직접 호스트에서 읽기 (마운트되었으므로)
cat /home/opc/career-lens/crawler/logs/output.log

마운트 상태 확인

방법 1: Docker Inspect

docker inspect career-lens --format='{{json .Mounts}}'

방법 2: Mount 명령어

mount | grep career-lens

방법 3: 파일 확인

# 컨테이너에서 파일 생성
docker exec career-lens touch /app/crawler/testfile.txt

# 호스트에서 확인
ls -la /home/opc/career-lens/crawler/testfile.txt
# ✅ 파일이 보임 = 마운트 성공!

정리: Volume Mount의 핵심

1️⃣ 파일시스템 마운트란?

컨테이너 경로 ↔️ 호스트 경로 (양방향 동기화)

2️⃣ 마운트 선언

-v /app/crawler:/home/opc/career-lens/crawler

3️⃣ 마운트 동작

컨테이너에서 /app/crawler/ 파일 수정
  ↓
호스트의 /home/opc/career-lens/crawler/ 에 자동 반영
  ↓
크론잡이 호스트 경로에서 읽음
  ↓
최신 파일로 자동 실행!

4️⃣ 확인 명령어

# 컨테이너 내부
docker exec career-lens ls -la /app/crawler/

# 호스트 시스템
ls -la /home/opc/career-lens/crawler/

# 동일한 파일들이 보이면 마운트 성공!

결론

Docker Volume Mount를 사용하면:

✅ 컨테이너와 호스트의 파일시스템을 연결
✅ 양방향으로 자동 동기화
✅ 크론잡에서 쉽게 접근 가능
✅ 파일 수정 시 즉시 반영

이것이 현대적인 컨테이너 파일시스템 운영의 핵심입니다!

[DB] Flyway 마이그레이션 실패 원인: desc 컬럼의 함정

snapcoder — Mon, 26 Jan 2026 22:07:32 +0900

[DB] Flyway 마이그레이션 실패 원인: desc 컬럼의 함정

문제 상황

Spring Boot + Flyway + PostgreSQL 환경에서
컨테이너 기동 시 다음과 같은 에러가 발생했다.

ERROR: syntax error at or near "desc"
SQL State  : 42601
Location   : db/migration/V2__insert_initial_data.sql
Line       : 10

Flyway 마이그레이션 도중 SQL 문법 오류로 인해
컨테이너가 정상적으로 기동되지 않는 상황이었다.

에러가 발생한 SQL (문제 코드)

INSERT INTO common_code (type, code, name, desc, created_at, updated_at) VALUES
    ('COMPANY_SCALE', 'LARGE', '대기업', '임직원 1000명 이상', NOW(), NOW()),
    ('COMPANY_SCALE', 'MEDIUM', '중견기업', '임직원 300~1000명', NOW(), NOW())
ON CONFLICT DO NOTHING;

에러 메시지는 단순히 desc 근처에서 문법 오류가 났다고만 알려준다.

원인 분석

1️⃣ desc는 PostgreSQL 예약어

desc는 PostgreSQL에서 ORDER BY DESC에 사용되는
예약어(Keyword) 이다.

즉, 아래 구문에서:

(name, desc, created_at)

PostgreSQL은 desc를 컬럼명이 아닌 키워드로 해석한다.

2️⃣ MySQL에선 되는데 PostgreSQL에선 터진 이유

MySQL: 예약어 사용에 비교적 관대
PostgreSQL: 예약어 사용 엄격

DB 변경 시 가장 자주 터지는 지점 중 하나

️ 해결 방법

❌ 선택하지 않은 방법

"desc"

처럼 더블 쿼트로 감싸는 방식도 가능하지만:

모든 쿼리에 따옴표 필요
유지보수 지옥
ORM/JPA와 궁합 최악

✅ 선택한 방법 (권장)

컬럼명을 예약어가 아닌 이름으로 변경

✏️ 수정 내용

✅ V1__init_schema.sql

변경 전

CREATE TABLE common_code (
    id BIGSERIAL PRIMARY KEY,
    type VARCHAR(50),
    code VARCHAR(50),
    name VARCHAR(100),
    desc VARCHAR(255),
    created_at TIMESTAMP,
    updated_at TIMESTAMP
);

변경 후

CREATE TABLE common_code (
    id BIGSERIAL PRIMARY KEY,
    type VARCHAR(50),
    code VARCHAR(50),
    name VARCHAR(100),
    description VARCHAR(255),
    created_at TIMESTAMP,
    updated_at TIMESTAMP
);

동일한 변경을 company 테이블에도 적용

✅ V2__insert_initial_data.sql

변경 전

INSERT INTO common_code (type, code, name, desc, created_at, updated_at)
VALUES ('SAMPLE', 'CODE', '샘플명', '설명 텍스트', NOW(), NOW());

변경 후

INSERT INTO common_code (type, code, name, description, created_at, updated_at)
VALUES ('SAMPLE', 'CODE', '샘플명', '설명 텍스트', NOW(), NOW());

모든 INSERT 문에서 desc → description으로 변경

결과

Flyway 마이그레이션 정상 수행
컨테이너 정상 기동
애플리케이션 정상 배포 완료 ✅

교훈 정리

✔ PostgreSQL 예약어는 컬럼명으로 쓰지 말자

desc
user
order
group
limit

✔ DB 마이그레이션 스크립트는

가장 엄격한 DB 기준으로 작성하자

✔ Flyway 실패 = 서비스 기동 실패

단순 SQL 오류도 전체 서비스 장애로 이어질 수 있다...매우위험...

✨ 한 줄 요약

PostgreSQL에서 desc는 컬럼명이 아니라 폭탄이다.

[Flyway] spring-boot-starter-flyway vs flyway-core 차이 정리

snapcoder — Mon, 26 Jan 2026 21:54:55 +0900

[Flyway] spring-boot-starter-flyway vs flyway-core 차이 정리

배경

Spring Boot 3.x 프로젝트에서 Flyway를 사용해
PostgreSQL 마이그레이션을 적용하던 중, 아래와 같은 의존성 구성이 문제가 되었다.

implementation 'org.springframework.boot:spring-boot-starter-flyway'

기존에는 문제없이 동작하던 설정이었지만,
Spring Boot 3.x + PostgreSQL 환경에서는 버전 충돌 및 DB 인식 오류가 발생했다.

결국 다음과 같이 의존성을 변경했다.

// ❌ 제거됨
implementation 'org.springframework.boot:spring-boot-starter-flyway'

// ✅ 추가됨
implementation 'org.flywaydb:flyway-core:9.22.3'
implementation 'org.flywaydb:flyway-database-postgresql:9.22.3'

이 글에서는 이 두 방식의 차이점과 왜 문제가 발생했는지를 정리한다.

spring-boot-starter-flyway란?

implementation 'org.springframework.boot:spring-boot-starter-flyway'

특징

Spring Boot에서 제공하는 편의용 스타터
내부적으로 다음을 포함
- flyway-core
- Spring Boot가 관리하는 Flyway 버전
자동 설정(Auto Configuration) 을 통해 별도 설정 없이 동작

문제점

Flyway 버전을 직접 제어할 수 없음
Spring Boot가 지정한 Flyway 버전이
- PostgreSQL 드라이버
- PostgreSQL 서버 버전
  과 호환되지 않는 경우 발생

특히 PostgreSQL 최신 버전을 사용할 때 자주 문제 발생

flyway-core + flyway-database-postgresql이란?

implementation 'org.flywaydb:flyway-core:9.22.3'
implementation 'org.flywaydb:flyway-database-postgresql:9.22.3'

역할 분리 구조

라이브러리역할

flyway-core	Flyway 핵심 엔진
flyway-database-postgresql	PostgreSQL 전용 SQL 파서 및 DB 지원

장점

Flyway 공식 권장 방식
DB별 모듈을 명확히 분리
PostgreSQL 버전 대응이 빠름
Spring Boot 버전에 덜 종속적

DB 호환성 문제를 직접 통제 가능

⚠️ 왜 starter를 쓰면 문제가 생겼을까?

Spring Boot 3.x 환경에서:

spring-boot-starter-flyway
- → Spring Boot BOM이 관리하는 Flyway 버전 사용
PostgreSQL
- → 최신 버전 사용 중

이 조합에서 자주 발생하는 문제:

PostgreSQL 버전을 Flyway가 제대로 인식하지 못함
마이그레이션 SQL 파싱 오류
Unsupported Database 관련 에러

원인은 Flyway와 PostgreSQL 간 버전 불일치

✅ 해결 전략

❌ 지양

implementation 'org.springframework.boot:spring-boot-starter-flyway'

✅ 권장

implementation 'org.flywaydb:flyway-core:9.22.3'
implementation 'org.flywaydb:flyway-database-postgresql:9.22.3'

이렇게 하면:

Flyway 버전을 명시적으로 관리
PostgreSQL 지원 모듈을 명확히 포함
Spring Boot 업그레이드에도 영향 최소화

정리 한 줄 요약

Spring Boot 3.x + PostgreSQL 환경에서는
spring-boot-starter-flyway 대신
flyway-core + flyway-database-postgresql 조합이 훨씬 안정적이다.

✨ 개인적인 팁

운영 환경에서 DB 마이그레이션은 절대 자동에만 맡기지 말 것
Flyway는 DB 종류별 모듈 분리 방식이 기본 철학
starter는 편하지만, 문제 생기면 디버깅이 훨씬 어렵다

[Flyway] Spring Boot에서 PostgreSQL 마이그레이션 자동화

snapcoder — Mon, 26 Jan 2026 21:35:09 +0900

[Flyway] Spring Boot에서 PostgreSQL 마이그레이션 자동화

Flyway란?

정의

Flyway는 데이터베이스 스키마 버전 관리 및 마이그레이션 자동화 도구입니다. Git처럼 SQL 스크립트의 버전을 관리하고, 애플리케이션 시작 시 자동으로 데이터베이스 스키마를 최신 상태로 유지합니다.

필요성

✅ 버전 관리: DB 스키마 변경 이력을 코드로 추적
✅ 자동화: 수동 SQL 실행 불필요 → 휴먼 에러 감소
✅ 일관성: 모든 팀원이 동일한 DB 상태 유지
✅ 배포 단순화: CI/CD 파이프라인에 자동 포함
✅ 개발 효율성: 새로운 팀원도 자동으로 DB 초기화

장점

항목	설명
자동 마이그레이션	애플리케이션 시작 시 자동 실행
버전 추적	모든 변경사항을 코드로 기록
롤백 안전성	이전 버전 상태 복구 가능
멀티 환경	로컬/테스트/운영 동일 적용

단점

항목	설명
복잡한 마이그레이션	대용량 데이터 변환은 성능 고려 필요
학습곡선	초기 설정 및 네이밍 규칙 학습 필요
프로덕션 주의	스크립트 검증 필수, 실패 시 DB 손상 위험

프로젝트 환경

기술 스택

- Backend: Spring Boot 3.3.2
- Database: PostgreSQL
- 마이그레이션: Flyway
- 빌드: Gradle

프로젝트 구조

[프로젝트경로]/
├── build.gradle
├── src/
│   ├── main/
│   │   ├── java/
│   │   │   └── com/careerlens/
│   │   └── resources/
│   │       ├── db/migration/
│   │       │   ├── V1__init_schema.sql
│   │       │   └── V2__insert_initial_data.sql
│   │       ├── application.properties
│   │       └── application-local.properties
│   └── test/
└── frontend/

구현 과정

1단계: build.gradle에 Flyway 의존성 추가

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    implementation 'org.springframework.boot:spring-boot-starter-flyway'  // ← 추가
    runtimeOnly 'org.postgresql:postgresql'
    // ... 기타 의존성
}

2단계: 마이그레이션 파일 생성

디렉터리 생성

src/main/resources/db/migration/

V1__init_schema.sql - 초기 스키마 정의

Flyway의 네이밍 규칙을 따름:

V + 버전번호 + __ + 설명
예: V1__init_schema.sql, V2__insert_initial_data.sql

-- ✅ 1. COMMON_CODE 테이블 (공통코드)
CREATE TABLE IF NOT EXISTS common_code (
    id BIGSERIAL PRIMARY KEY,
    type VARCHAR(50),
    code VARCHAR(50),
    name VARCHAR(100),
    desc VARCHAR(255),
    created_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP
);

-- ✅ 2. COMPANY 테이블 (회사정보)
CREATE TABLE IF NOT EXISTS company (
    id BIGSERIAL PRIMARY KEY,
    name VARCHAR(255),
    alias TEXT,
    desc VARCHAR(255),
    del_yn VARCHAR(1) DEFAULT 'N',
    deleted_at TIMESTAMPTZ,
    created_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP
);

-- ✅ 3. JOB_POSTING 테이블 (채용공고)
CREATE TABLE IF NOT EXISTS job_posting (
    id BIGSERIAL PRIMARY KEY,
    company_id BIGINT,
    name VARCHAR(255),
    link VARCHAR(500),
    experience_level VARCHAR(100),
    work_type VARCHAR(100),
    etc1 VARCHAR(100),
    etc2 VARCHAR(100),
    etc3 VARCHAR(100),
    del_yn VARCHAR(1) DEFAULT 'N',
    deleted_at TIMESTAMPTZ,
    created_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (company_id) REFERENCES company(id)
);

V2__insert_initial_data.sql - 초기 데이터 삽입

-- 공통코드 (기업 규모)
INSERT INTO common_code (type, code, name, desc, created_at, updated_at) VALUES
    ('COMPANY_SCALE', 'LARGE', '대기업', '임직원 1000명 이상', NOW(), NOW()),
    ('COMPANY_SCALE', 'MEDIUM', '중견기업', '임직원 300~1000명', NOW(), NOW()),
    ('COMPANY_SCALE', 'SMALL', '중소기업', '임직원 50~300명', NOW(), NOW()),
    ('COMPANY_SCALE', 'MICRO', '스타트업', '임직원 50명 이하', NOW(), NOW()),
    ('COMPANY_SCALE', 'FOREIGN', '외국계', '외국 본사의 국내 법인', NOW(), NOW())
ON CONFLICT DO NOTHING;

-- 회사정보
INSERT INTO company (name, alias, desc, del_yn, created_at, updated_at) VALUES
    ('[회사A]', '[회사A](주),[회사영문A]', '핀테크 결제 솔루션 기업', 'N', NOW(), NOW()),
    ('[회사B]', '[회사B](주),[회사영문B]', 'IT 금융 플랫폼 기업', 'N', NOW(), NOW()),
    ('[회사C]', '[회사C](주),[회사영문C]', 'IT 포털 및 서비스 기업', 'N', NOW(), NOW()),
    ('[회사D]', '[회사D](주),[회사영문D]', '로컬 커머스 플랫폼', 'N', NOW(), NOW()),
    ('[회사E]', '[회사E](주),[회사영문E]', 'E-커머스 및 로지스틱스 기업', 'N', NOW(), NOW())
ON CONFLICT DO NOTHING;

-- 채용공고
INSERT INTO job_posting (company_id, name, link, experience_level, work_type, etc1, etc2, etc3, del_yn, created_at, updated_at) VALUES
    (1, '2026년 [회사A] 신입 공채', 'https://example.com/job/1', '신입', '정규직', '결제시스템', '대규모공채', NULL, 'N', NOW(), NOW()),
    (2, '2026년 [회사B] 백엔드 경력직 채용', 'https://example.com/job/2', '2년+', '정규직', '백엔드', '경력채용', NULL, 'N', NOW(), NOW()),
    (2, '2026년 [회사B] 프론트엔드 채용', 'https://example.com/job/3', '주니어', '정규직', '프론트엔드', '경력채용', NULL, 'N', NOW(), NOW()),
    (3, '2026년 [회사C] 신입 공채', 'https://example.com/job/4', '신입', '정규직', '풀스택', '대규모공채', 'Tech', 'N', NOW(), NOW()),
    (3, '2026년 [회사C] 데이터 경력직 채용', 'https://example.com/job/5', '5년+', '정규직', '데이터분석', '경력채용', 'ML', 'N', NOW(), NOW()),
    (4, '[회사D] 모바일 개발자 채용', 'https://example.com/job/6', '주니어', '정규직', '모바일', '경력채용', NULL, 'N', NOW(), NOW()),
    (5, '[회사E] 인프라 엔지니어 채용', 'https://example.com/job/7', '신입', '정규직', '인프라', '대규모공채', NULL, 'N', NOW(), NOW()),
    (5, '[회사E] 백엔드 개발자 채용', 'https://example.com/job/8', '주니어', '정규직', '백엔드', '경력채용', NULL, 'N', NOW(), NOW())
ON CONFLICT DO NOTHING;

3단계: application.properties 설정

# ============================================================
# Database Configuration
# ============================================================
spring.datasource.url=jdbc:postgresql://[DB_HOST]:[DB_PORT]/[DB_NAME]
spring.datasource.driver-class-name=org.postgresql.Driver
spring.datasource.username=${DB_USERNAME}
spring.datasource.password=${DB_PASSWORD}

# ============================================================
# JPA / Hibernate Configuration
# ============================================================
spring.jpa.database-platform=org.hibernate.dialect.PostgreSQLDialect
spring.jpa.hibernate.ddl-auto=validate
spring.jpa.show-sql=false

# ============================================================
# Flyway Configuration
# ============================================================
spring.flyway.enabled=true
spring.flyway.locations=classpath:db/migration
spring.flyway.baseline-on-migrate=true
spring.flyway.validate-on-migrate=true

주요 설정 설명:

ddl-auto=validate - Flyway가 스키마 관리하므로 Hibernate는 검증만 수행
baseline-on-migrate=true - 기존 DB도 마이그레이션 호환성 유지

주요 학습 포인트

1️⃣ CREATE TABLE IF NOT EXISTS 중요성

-- ❌ 나쁜 예: 테이블이 이미 존재하면 에러 발생
CREATE TABLE common_code (...)

-- ✅ 좋은 예: 테이블이 없을 때만 생성, 있으면 무시
CREATE TABLE IF NOT EXISTS common_code (...)

이점:

재실행 안전성: 마이그레이션 스크립트를 여러 번 실행해도 안전
개발 편의성: 데이터 손실 없이 스크립트 재실행 가능
멱등성(Idempotent): 같은 결과 보장

2️⃣ TIMESTAMP vs TIMESTAMPTZ 선택

항목	TIMESTAMP	TIMESTAMPTZ
타임존 정보	❌ 미포함	✅ 포함
저장 형식	서버 로컬 시간	UTC 기준
글로벌 서비스	❌ 위험	✅ 권장
자동 변환	❌ 수동 처리	✅ 자동

-- ❌ 나쁜 예: 타임존 미포함
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP

-- ✅ 좋은 예: 타임존 포함 (PostgreSQL 권장)
created_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP

실제 차이:

서버 시간대: 한국(+09:00)에서 2026-01-26 10:00 저장
↓
TIMESTAMP:   2026-01-26 10:00:00 (타임존 정보 없음)
TIMESTAMPTZ: 2026-01-26 10:00:00+09:00 (타임존 정보 포함)
↓
미국(EST) 서버에서 조회하면
TIMESTAMP:   2026-01-26 10:00:00 (???)
TIMESTAMPTZ: 2026-01-25 20:00:00-05:00 (정확함!)

3️⃣ INSERT VALUES로 대량 데이터 삽입 최적화

-- ❌ 나쁜 예: 한 번에 하나씩 삽입 (4줄 × 5개 = 20줄)
INSERT INTO common_code (...) 
SELECT 'COMPANY_SCALE', 'LARGE', ... WHERE NOT EXISTS (...);
INSERT INTO common_code (...) 
SELECT 'COMPANY_SCALE', 'MEDIUM', ... WHERE NOT EXISTS (...);
INSERT INTO common_code (...) 
SELECT 'COMPANY_SCALE', 'SMALL', ... WHERE NOT EXISTS (...);
-- ... 반복

-- ✅ 좋은 예: VALUES로 한 번에 삽입 (5줄)
INSERT INTO common_code (type, code, name, desc, created_at, updated_at) VALUES
    ('COMPANY_SCALE', 'LARGE', '대기업', ..., NOW(), NOW()),
    ('COMPANY_SCALE', 'MEDIUM', '중견기업', ..., NOW(), NOW()),
    ('COMPANY_SCALE', 'SMALL', '중소기업', ..., NOW(), NOW()),
    ('COMPANY_SCALE', 'MICRO', '스타트업', ..., NOW(), NOW()),
    ('COMPANY_SCALE', 'FOREIGN', '외국계', ..., NOW(), NOW())
ON CONFLICT DO NOTHING;

성능 개선:

코드 라인: 50% 단축
네트워크 왕복: 5회 → 1회
실행 속도: 약 3~5배 향상

4️⃣ ON CONFLICT DO NOTHING으로 재실행 안전성

-- ❌ 나쁜 예: 중복 데이터 오류 발생
INSERT INTO common_code (...) VALUES (...)

-- ✅ 좋은 예: 중복 시 무시 (멱등성 보장)
INSERT INTO common_code (...) VALUES (...)
ON CONFLICT DO NOTHING;

용도:

Flyway 재실행 시 중복 오류 방지
데이터 무결성 유지
스크립트 재사용 가능

5️⃣ 외래키(Foreign Key) 제약조건 활용

CREATE TABLE job_posting (
    id BIGSERIAL PRIMARY KEY,
    company_id BIGINT,
    -- ...
    FOREIGN KEY (company_id) REFERENCES company(id)  -- ← 참조 무결성 보장
);

이점:

✅ 데이터 무결성: 존재하지 않는 회사 삽입 방지
✅ 일관성: 회사 삭제 시 자동 처리 (설정에 따라)
✅ 명확한 관계: 테이블 간 관계를 명시적으로 표현

6️⃣ Soft Delete (논리적 삭제) 패턴

CREATE TABLE company (
    id BIGSERIAL PRIMARY KEY,
    name VARCHAR(255),
    del_yn VARCHAR(1) DEFAULT 'N',        -- 삭제 여부
    deleted_at TIMESTAMPTZ,              -- 삭제 시간
    -- ...
);

사용 예시:

-- 회사 삭제 (물리 삭제 아님, 논리적 삭제)
UPDATE company 
SET del_yn = 'Y', deleted_at = NOW() 
WHERE id = 1;

-- 활성 회사만 조회
SELECT * FROM company WHERE del_yn = 'N';

장점:

✅ 데이터 복구: 언제든 복구 가능
✅ 감사 추적: 삭제 시간 기록
✅ 데이터 분석: 삭제 이력 분석 가능
✅ 관계 무결성: 참조 중인 데이터 안전

실행 및 검증

마이그레이션 실행 결과

실행 시 콘솔 로그

...
2026-01-26 10:30:45.123 INFO  ... Initializing Flyway...
2026-01-26 10:30:45.456 INFO  ... Current schema version: 0
2026-01-26 10:30:46.789 INFO  ... Migrating schema to version 1
2026-01-26 10:30:47.012 INFO  ... Successfully applied 1 migration
2026-01-26 10:30:47.234 INFO  ... Migrating schema to version 2
2026-01-26 10:30:48.567 INFO  ... Successfully applied 1 migration
2026-01-26 10:30:49.890 INFO  ... Flyway completed successfully
...

PostgreSQL에서 확인

-- Flyway 마이그레이션 이력 확인
SELECT * FROM flyway_schema_history;

-- 생성된 테이블 확인
\dt  -- 모든 테이블 목록

-- 데이터 확인
SELECT COUNT(*) FROM common_code;  -- 16개 (공통코드)
SELECT COUNT(*) FROM company;       -- 5개 (회사)
SELECT COUNT(*) FROM job_posting;   -- 8개 (채용공고)

트러블슈팅: Flyway 버전 오류

에러 메시지:

Could not find org.springframework.boot:spring-boot-starter-flyway:.
Required by: project :

원인:
의존성 관리 플러그인이 Flyway 버전을 찾지 못함

해결 방법:

# Gradle 캐시 정리 및 의존성 다시 다운로드
./gradlew clean --refresh-dependencies

# 의존성 확인
./gradlew dependencies --configuration compileClasspath

결론

Flyway 적용의 이점

측면	효과
개발 생산성	자동 마이그레이션으로 수동 작업 제거
팀 협업	모든 팀원이 동일한 DB 상태 유지
배포 안정성	CI/CD 파이프라인에 통합된 자동화
데이터 무결성	스키마 버전 관리로 일관성 보장
개발 속도	새로운 팀원도 자동으로 DB 초기화

배운 점

데이터베이스 설계의 중요성 - 처음부터 올바른 구조로 설계하면 나중 확장이 훨씬 수월
멱등성의 가치 - IF NOT EXISTS, ON CONFLICT DO NOTHING으로 안전한 재실행 가능
타임존 관리의 중요성 - TIMESTAMPTZ는 글로벌 서비스 필수
자동화의 효율성 - Flyway로 DB 관리를 코드화하면 휴먼 에러 대폭 감소

참고 자료

[보안] Spring Boot HTTP→HTTPS 리다이렉트 완전정복

snapcoder — Sun, 25 Jan 2026 23:42:29 +0900

[보안] Spring Boot HTTP→HTTPS 리다이렉트 완전정복

개요

이 글은 Spring Boot(백엔드)에서 HTTP → HTTPS 자동 리다이렉트를 구현하는 방법을 정리합니다.
사용자가 http://your-domain.com으로 접속해도 자동으로 https://your-domain.com으로 이동하게 합니다.

핵심: 사용자는 신경 쓸 필요 없이 자동으로 보안 연결로 이동합니다!

목표

✅ 모든 HTTP 요청(포트 80) → HTTPS(포트 443)로 자동 리다이렉트
✅ Spring Boot에서 HTTP(80) + HTTPS(443) 동시 리스닝
✅ 사용자 경험 개선 (자동 이동, 보안 경고 제거)
✅ SEO 최적화 (Google HTTPS 우대)
✅ 보안 강화 (중간자 공격 방지)

전제

도메인 → 서버 IP(A 레코드) 연결 완료
포트 80, 443 접근 허용(방화벽/보안그룹)
Spring Boot 3.x, Java 17 이상
Let's Encrypt 인증서 발급 완료

1. 왜 HTTP → HTTPS 리다이렉트가 필수인가?

1.1 사용자 경험 (UX)

❌ 리다이렉트 없음 (보안 경고)
사용자: http://your-domain.com 입력
  ↓
브라우저: ⚠️ "이 사이트는 안전하지 않습니다" 경고 표시
  ↓
사용자: 불신 → 이탈 ❌

✅ 리다이렉트 적용 (자동 보안 연결)
사용자: http://your-domain.com 입력
  ↓
자동으로 https://your-domain.com로 이동
  ↓
사용자: 자동으로 보안 연결 ✅ (주소창에  )

1.2 SEO (검색 엔진 최적화)

Google은 HTTPS 사이트를 검색 순위에서 우대
HTTP 사이트는 "Not Secure" 경고로 클릭률 저하
웹마스터 도구에서 HTTPS 이전 권장

1.3 보안

중간자 공격(MITM) 방지 - 데이터 암호화
쿠키, 세션, 로그인 정보 암호화
신용카드 정보 전송 시 필수 (PCI-DSS 준수)

1.4 기술 표준

거의 모든 상용 웹사이트가 구현 (Amazon, Google, Facebook 등)
최신 브라우저 기능(HTTP/2, HTTP/3)은 HTTPS에서만 동작

2. Spring Boot 설정 (HTTP → HTTPS 리다이렉트)

2.1 application.properties - SSL 및 리다이렉트 설정

파일 위치: src/main/resources/application.properties

# ========================================
# SSL/TLS 설정 (Let's Encrypt PEM 방식)
# ========================================
server.port=443
server.ssl.enabled=true
server.ssl.key-store-type=PEM
server.ssl.certificate=/etc/letsencrypt/live/{YOUR_DOMAIN}/fullchain.pem
server.ssl.certificate-private-key=/etc/letsencrypt/live/{YOUR_DOMAIN}/privkey.pem

# HTTP/2 지원
server.http2.enabled=true

# 보안 쿠키 설정
server.servlet.session.cookie.secure=true
server.servlet.session.cookie.http-only=true
server.servlet.session.cookie.same-site=strict

# HTTP → HTTPS 리다이렉트 설정
server.tomcat.redirect-context-root=true

변수 설명:

{YOUR_DOMAIN} → 실제 도메인으로 대체 (예: example.com)

2.2 WebConfig.java - HTTP → HTTPS 자동 리다이렉트 구현

파일 위치: src/main/java/com/yourcompany/config/WebConfig.java

package com.yourcompany.config;

import org.apache.catalina.connector.Connector;
import org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory;
import org.springframework.boot.web.servlet.server.ServletWebServerFactory;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/**
 * HTTP → HTTPS 자동 리다이렉트 설정
 * 
 * 동작 원리:
 * 1. 사용자가 http://your-domain.com 입력 (포트 80)
 * 2. Spring Boot HTTP Connector(80)가 요청 감지
 * 3. Redirect-Port(443)로 자동 리다이렉트
 * 4. 브라우저가 Location 헤더 읽음 → https://your-domain.com 재요청
 * 5. Spring Boot HTTPS Connector(443)가 요청 처리
 * 6. TLS/SSL 보안 연결 확립 ✅
 */
@Configuration
public class WebConfig {

    /**
     * Tomcat 서블릿 웹서버 팩토리
     * HTTP(80)과 HTTPS(443) 두 포트를 동시에 리스닝하도록 설정
     */
    @Bean
    public ServletWebServerFactory servletContainer() {
        TomcatServletWebServerFactory tomcat = new TomcatServletWebServerFactory();

        // HTTP 포트(80)에서 들어온 요청을 HTTPS(443)로 리다이렉트
        tomcat.addAdditionalTomcatConnectors(createHttpConnector());

        return tomcat;
    }

    /**
     * HTTP 포트(80) 커넥터 생성
     * 
     * 매개변수 설명:
     * - setPort(80): HTTP 표준 포트 (포트 포워딩으로 80에서 수신)
     * - setScheme("http"): HTTP 프로토콜 명시
     * - setSecure(false): 비보안 연결 (TLS 없음)
     * - setRedirectPort(443): 리다이렉트 대상 포트 (HTTPS)
     */
    private Connector createHttpConnector() {
        Connector connector = new Connector(TomcatServletWebServerFactory.DEFAULT_PROTOCOL);
        connector.setPort(80);             // HTTP 리스닝 포트
        connector.setScheme("http");       // HTTP 스킴
        connector.setSecure(false);        // 비보안 연결
        connector.setRedirectPort(443);    // HTTPS 리다이렉트 대상
        return connector;
    }
}

3. HTTP → HTTPS 리다이렉트 동작 원리 (상세 흐름도)

┌─────────────────────────────────────────────────────────────┐
│ 1️⃣ 사용자가 브라우저에 입력                                 │
│    URL: http://your-domain.com                              │
│    (자동으로 포트 80 사용)                                   │
└────────────────────┬────────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────────┐
│ 2️⃣ 브라우저가 HTTP 요청 생성                                │
│    GET / HTTP/1.1                                           │
│    TCP 포트 80으로 연결 시도                                 │
└────────────────────┬────────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────────┐
│ 3️⃣ Spring Boot Tomcat HTTP Connector 수신                  │
│    connector.setPort(80) 설정된 커넥터가 요청 수신         │
│    HTTP 프로토콜로 처리 시작                                │
└────────────────────┬────────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────────┐
│ 4️⃣ HTTP → HTTPS 리다이렉트 결정                             │
│    connector.setRedirectPort(443) 설정 확인                 │
│    HTTP 301 (Moved Permanently) 응답 생성                  │
│    Location 헤더: https://your-domain.com/                 │
└────────────────────┬────────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────────┐
│ 5️⃣ 브라우저가 Location 헤더 읽음                            │
│    HTTP 301 응답에 포함된 새 URL 감지                       │
│    자동으로 https://your-domain.com으로 재요청             │
│    (사용자는 주소창 변화만 인식)                             │
└────────────────────┬────────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────────┐
│ 6️⃣ HTTPS 연결 확립                                          │
│    TCP 포트 443으로 연결                                     │
│    TLS 핸드셰이크 수행                                       │
│    - 클라이언트: 암호화 제안                                 │
│    - 서버: Let's Encrypt 인증서 전송                        │
│    - 인증서 검증 (CA 체인 확인)                             │
└────────────────────┬────────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────────┐
│ 7️⃣ Spring Boot Tomcat HTTPS Connector 수신                 │
│    server.port=443으로 설정된 커넥터가 요청 수신             │
│    SSL/TLS 보안 연결 확립 ✅                                │
│    application.properties의 인증서 로드:                    │
│    - fullchain.pem (공개 인증서)                            │
│    - privkey.pem (개인 키)                                  │
└────────────────────┬────────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────────┐
│ 8️⃣ 응답 반환 (암호화된 통신)                                │
│    안전한 HTTPS 통신으로 콘텐츠 전송                         │
│    사용자: https://your-domain.com ✅                       │
│    주소창에   자물쇠 아이콘 표시                           │
└─────────────────────────────────────────────────────────────┘

4. HTTP → HTTPS 리다이렉트 테스트

4.1 curl 명령어 테스트

# HTTP 요청 시 리다이렉트 확인
curl -i http://your-domain.com

# 예상 결과:
# HTTP/1.1 301 Moved Permanently
# Location: https://your-domain.com/
# Server: Apache Tomcat

4.2 브라우저에서 테스트

1. 브라우저 주소창에 입력: http://your-domain.com
2. 자동으로 https://your-domain.com으로 이동 ✅
3. 주소창에   자물쇠 아이콘 표시 확인
4. 개발자 도구 (F12) → Network 탭
   - Request URL이 https://로 시작하는지 확인
   - Status: 301 Moved Permanently 확인

4.3 SSL 인증서 검증

# 로컬에서 인증서 정보 확인
openssl s_client -connect your-domain.com:443 -tls1_2

# 인증서 만료날짜 확인
openssl x509 -in /etc/letsencrypt/live/your-domain.com/fullchain.pem -noout -dates

# 결과:
# notBefore=Jan 23 11:23:08 2024 GMT
# notAfter=Apr 22 11:23:08 2024 GMT

# 온라인 SSL 검증 (SSL Labs)
# https://www.ssllabs.com/ssltest/analyze.html?d=your-domain.com

5. 프로젝트 파일 구조 및 위치

career-lens/
│
├── backend/
│   ├── src/main/
│   │   ├── java/com/yourcompany/
│   │   │   └── config/
│   │   │       └── WebConfig.java              ← HTTP→HTTPS 리다이렉트 (핵심!)
│   │   └── resources/
│   │       ├── application.properties           ← SSL 인증서 경로 설정
│   │       └── application-prd.properties       ← 프로덕션 설정
│   └── Dockerfile                              ← Docker 이미지 정의
│
├── frontend/
│   ├── next.config.js                          ← 보안 헤더 설정
│   ├── .env.production                         ← HTTPS API 기본 URL
│   └── .env.local                              ← 개발 환경 설정
│
├── docker-compose.yml                          ← 포트 매핑, 볼륨 설정
├── .github/workflows/
│   └── deploy.yml                              ← CI/CD 배포 스크립트
│
└── TEMP.md                                     ← 이 파일

6. 운영 체크리스트

✅ Spring Boot 설정
  ☐ application.properties에 SSL 인증서 경로 설정
    - server.ssl.certificate=/etc/letsencrypt/live/{YOUR_DOMAIN}/fullchain.pem
    - server.ssl.certificate-private-key=/etc/letsencrypt/live/{YOUR_DOMAIN}/privkey.pem
  ☐ WebConfig.java에서 HTTP(80) → HTTPS(443) 리다이렉트 구현
  ☐ server.port=443 및 server.ssl.enabled=true 확인
  ☐ Spring Boot 시작 로그 확인:
    - "Application started on port 443 (https)"
    - "HTTP Connector listening on port 80"

✅ 보안 검증
  ☐ HTTP → HTTPS 리다이렉트 테스트
    - curl -i http://your-domain.com
    - 결과: HTTP/1.1 301 Moved Permanently
  ☐ SSL 인증서 유효성 확인
    - https://www.ssllabs.com/ssltest/
  ☐ 브라우저에서 자물쇠 아이콘 표시 확인

7. 트러블슈팅

Q: 포트 80, 443 충돌

# 포트 사용 프로세스 확인
sudo lsof -i :80
sudo lsof -i :443

# 프로세스 강제 종료
sudo kill -9 <PID>

Q: SSL 인증서 로드 오류

# 인증서 파일 존재 여부 확인
ls -la /etc/letsencrypt/live/your-domain.com/

# 인증서 파일 권한 확인
sudo chmod 755 /etc/letsencrypt/live
sudo chmod 755 /etc/letsencrypt/archive

Q: HTTP 요청이 리다이렉트되지 않음

# Spring Boot 로그에서 포트 확인
# Application started on port 443 (https)
# HTTP Connector listening on port 80

# 리다이렉트 테스트
curl -v http://localhost
# 결과: HTTP/1.1 301 ← 성공

8. 최종 요약

Spring Boot 내장 Tomcat 웹서버에 Let's Encrypt PEM 방식 SSL을 적용하고, HTTP(80) → HTTPS(443) 자동 리다이렉트를 구현하면
사용자는 보안 경고 없이 자동으로 안전한 연결으로 이동합니다.

핵심 설정:

application.properties에서 SSL 인증서 경로 설정
WebConfig.java에서 HTTP(80) → HTTPS(443) 리다이렉트 구현
Spring Boot 시작 시 두 포트 동시 리스닝
사용자 자동 리다이렉트 완료 ✅

9. 참고 자료

[SSL] Let's Encrypt 무료 인증서로 HTTPS 자동갱신 구축하기: Certbot + Docker 완전 자동화 가이드

snapcoder — Thu, 22 Jan 2026 21:44:40 +0900

[SSL] Let's Encrypt 무료 인증서로 HTTPS 자동갱신 구축하기: Certbot + Docker 완전 자동화 가이드

개요

이 글은 Let's Encrypt 무료 SSL 인증서를 Certbot으로 발급하고, Docker 볼륨 마운트를 통해 이미지 재빌드 없이 자동갱신하는 방법을 정리합니다.

Spring Boot 백엔드는 application.properties에 설정된 인증서 경로를 통해 자동으로 HTTPS를 처리하며, Systemd 타이머가 매달 정기적으로 인증서를 갱신합니다.

목표

✅ Let's Encrypt 무료 SSL 인증서 발급
✅ 포트 80 (HTTP) → 포트 443 (HTTPS) 자동 리다이렉트
✅ Certbot을 통한 자동 인증서 갱신
✅ Docker 볼륨 마운트로 이미지 재빌드 없이 인증서 적용
✅ Systemd 타이머로 완전 자동화
✅ 개발자는 코드만 작성, 나머지는 모두 자동

전제

도메인 → 서버 IP(A 레코드) 연결 완료
포트 80, 443 접근 허용 (방화벽/보안그룹)
CentOS/RHEL 또는 Ubuntu 계열 서버
Docker 설치 필요
Certbot 설치 필요

1. Let's Encrypt 인증서 발급 (Certbot)

1.1 Certbot 설치

CentOS/RHEL:

sudo yum install certbot
certbot --version

Ubuntu:

sudo apt update
sudo apt install -y certbot
certbot --version

1.2 인증서 발급 (Standalone 방식)

Spring Boot가 포트 443을 사용하므로, 사전에 Spring Boot를 중지한 후 Certbot으로 인증서를 발급합니다.

# 1. Spring Boot 앱 중지
sudo docker stop career-lens

# 2. 인증서 발급
sudo certbot certonly --standalone -d {YOUR_DOMAIN}

# 3. Spring Boot 앱 재시작
sudo docker start career-lens

발급 결과:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/{YOUR_DOMAIN}/fullchain.pem
Key is saved at: /etc/letsencrypt/live/{YOUR_DOMAIN}/privkey.pem
This certificate expires on 2026-04-22 (만료날짜).

1.3 인증서 파일 구조

/etc/letsencrypt/live/{YOUR_DOMAIN}/
├── cert.pem           (공개 인증서)
├── privkey.pem        (개인 키)
├── chain.pem          (인증 체인)
└── fullchain.pem      (cert + chain, Spring Boot에서 사용)

변수 설명:

{YOUR_DOMAIN} → 실제 도메인으로 대체 (예: example.com)

2. Spring Boot 서버 설정

2.1 application.properties - SSL 및 HTTP → HTTPS 리다이렉트 설정

파일 위치: src/main/resources/application.properties

# ========================================
# SSL Configuration (Let's Encrypt - PEM)
# ========================================
server.port=443
server.ssl.enabled=true
server.ssl.key-store-type=PEM
server.ssl.certificate=/etc/letsencrypt/live/{YOUR_DOMAIN}/fullchain.pem
server.ssl.certificate-private-key=/etc/letsencrypt/live/{YOUR_DOMAIN}/privkey.pem

# HTTP/2 지원
server.http2.enabled=true

# 보안 쿠키 설정
server.servlet.session.cookie.secure=true
server.servlet.session.cookie.http-only=true
server.servlet.session.cookie.same-site=strict

# HTTP → HTTPS 리다이렉트 설정
server.tomcat.redirect-context-root=true

2.2 WebConfig.java - HTTP/HTTPS 커넥터 설정

파일 위치: src/main/java/com/yourcompany/config/WebConfig.java

Spring Boot의 WebConfig 클래스에서 HTTP(80)과 HTTPS(443) 두 포트를 동시에 리스닝하도록 설정합니다.

HTTP 포트(80)에 들어온 모든 요청은 자동으로 HTTPS(443)로 리다이렉트됩니다.

설정 내용:

HTTP Connector: 포트 80에 수신
Redirect Port: 443으로 설정 (HTTP → HTTPS 자동 리다이렉트)
HTTPS Connector: 포트 443에서 TLS/SSL 보안 연결 처리

3. HTTP → HTTPS 리다이렉트 동작 원리

┌──────────────────────────────────────┐
│ 사용자: http://{domain} 입력         │
│ (포트 80 자동 사용)                   │
└────────────┬─────────────────────────┘
             │
             ▼
┌──────────────────────────────────────┐
│ Spring Boot HTTP Connector(80) 수신  │
│ (WebConfig에서 설정)                 │
└────────────┬─────────────────────────┘
             │
             ▼
┌──────────────────────────────────────┐
│ HTTP 301 Redirect 응답               │
│ Location: https://{domain}/          │
└────────────┬─────────────────────────┘
             │
             ▼
┌───────────────��──────────────────────┐
│ 브라우저 자동 재요청                 │
│ https://{domain}                     │
└────────────┬─────────────────────────┘
             │
             ▼
┌──────────────────────────────────────┐
│ Spring Boot HTTPS(443) + TLS 연결    │
│ 보안 연결 확립 ✅                    │
│ (application.properties 인증서 로드)  │
└──────────────────────────────────────┘

4. Docker에서 인증서 볼륨 마운트 설정

4.1 docker run 명령어 (GitHub Actions)

docker run -d \
  --name career-lens \
  -p 80:80 \
  -p 443:443 \
  -e SPRING_PROFILES_ACTIVE=prd \
  -e DB_USERNAME={YOUR_DB_USER} \
  -e DB_PASSWORD={YOUR_DB_PASSWORD} \
  -v /etc/letsencrypt:/etc/letsencrypt:ro \
  {DOCKER_IMAGE}

핵심 옵션 설명:

-p 80:80 — HTTP 포트 80을 컨테이너 포트 80으로 매핑
-p 443:443 — HTTPS 포트 443을 컨테이너 포트 443으로 매핑
-v /etc/letsencrypt:/etc/letsencrypt:ro — 호스트의 인증서를 읽기 전용으로 마운트

4.2 Docker 볼륨 마운트 구조

호스트 서버 (/etc/letsencrypt)
├── live/{YOUR_DOMAIN}/
│   ├── fullchain.pem        ← Spring Boot가 읽음
│   ├── privkey.pem          ← Spring Boot가 읽음
│   └── ...
│
└─→ Docker 컨테이너 (볼륨 마운트, 읽기 전용)
    └── /etc/letsencrypt/live/{YOUR_DOMAIN}/
        ├── fullchain.pem    ← application.properties에서 참조
        ├── privkey.pem      ← application.properties에서 참조
        └── ...

이점:

인증서 갱신 후 Docker 이미지 재빌드 불필요
컨테이너 재시작만으로 새 인증서 적용
Spring Boot는 application.properties의 경로에서 자동으로 인증서 로드

5. Certbot 자동갱신 설정

5.1 Post-hook 스크립트 생성

인증서 갱신 후 자동으로 실행될 스크립트를 생성합니다.

# renewal-hooks/post 디렉토리 생성
sudo mkdir -p /etc/letsencrypt/renewal-hooks/post

# 스크립트 파일 생성
sudo nano /etc/letsencrypt/renewal-hooks/post/renew-docker.sh

스크립트 내용:

#!/bin/bash
# Certbot 인증서 갱신 후 Docker 컨테이너 재시작
# 새 인증서가 /etc/letsencrypt에 저장됨
# Docker 재시작 → Spring Boot가 자동으로 새 인증서 로드

docker restart career-lens || true

실행 권한 부여:

sudo chmod +x /etc/letsencrypt/renewal-hooks/post/renew-docker.sh

5.2 Certbot renewal 설정 확인

Certbot이 자동으로 생성한 renewal 설정 파일을 확인합니다:

sudo cat /etc/letsencrypt/renewal/{YOUR_DOMAIN}.conf

결과 예시:

# renew_before_expiry = 30 days
version = 1.22.0
archive_dir = /etc/letsencrypt/archive/{YOUR_DOMAIN}
cert = /etc/letsencrypt/live/{YOUR_DOMAIN}/cert.pem
privkey = /etc/letsencrypt/live/{YOUR_DOMAIN}/privkey.pem
chain = /etc/letsencrypt/live/{YOUR_DOMAIN}/chain.pem
fullchain = /etc/letsencrypt/live/{YOUR_DOMAIN}/fullchain.pem

[renewalparams]
account = {ACCOUNT_ID}
server = https://acme-v02.api.letsencrypt.org/directory
authenticator = standalone

5.3 Systemd 타이머 활성화 (자동갱신)

Certbot이 매달 정기적으로 자동 갱신되도록 Systemd 타이머를 활성화합니다:

# 타이머 활성화
sudo systemctl enable certbot-renew.timer
sudo systemctl start certbot-renew.timer

# 상태 확인
sudo systemctl status certbot-renew.timer

# 다음 갱신 예정시간 확인
sudo systemctl list-timers certbot-renew.timer

결과 예시:

NEXT                         LEFT     LAST PASSED UNIT                ACTIVATES
Fri 2026-04-22 11:23:08 UTC  89 days  n/a  n/a    certbot-renew.timer certbot-renew.service

6. 자동갱신 테스트

6.1 Dry-run (갱신 시뮬레이션)

실제 갱신 없이 모든 과정을 테스트합니다:

sudo certbot renew --dry-run --verbose

성공 결과:

Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/{YOUR_DOMAIN}/fullchain.pem (success)

Running post-hook command: /etc/letsencrypt/renewal-hooks/post/renew-docker.sh
Hook 'post-hook' ran with output:
 career-lens

6.2 인증서 상태 확인

sudo certbot certificates

결과 예시:

Found the following certs:
  Certificate Name: {YOUR_DOMAIN}
    Serial Number: 588e7ef361b38882fab9a321d5ca8e9d620
    Key Type: RSA
    Domains: {YOUR_DOMAIN}
    Expiry Date: 2026-04-22 11:23:08+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/{YOUR_DOMAIN}/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/{YOUR_DOMAIN}/privkey.pem

7. 최종 자동갱신 흐름도

┌─────────────────────────────────────────────────────────────┐
│ 1️⃣ Systemd Timer 발동                                       │
│    (매달 자동으로 정기적인 시간에 실행)                       │
└────────────────────┬────────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────────┐
│ 2️⃣ Certbot이 Let's Encrypt에 갱신 요청                      │
│    (인증서 유효기간 30일 전부터 자동 갱신)                    │
└────────────────────┬────────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────────┐
│ 3️⃣ 새 인증서 다운로드 및 설치                               │
│    /etc/letsencrypt/live/{YOUR_DOMAIN}/ 업데이트             │
└────────────────────┬────────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────────┐
│ 4️⃣ Post-hook 스크립트 실행                                 │
│    /etc/letsencrypt/renewal-hooks/post/renew-docker.sh      │
└────────────────────┬────────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────────┐
│ 5️⃣ Docker 컨테이너 자동 재시작                              │
│    docker restart career-lens                               │
└────────────────────┬────────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────────┐
│ 6️⃣ Spring Boot 시작                                        │
│    application.properties에서 자동으로 새 인증서 로드:        │
│    - /etc/letsencrypt/live/{YOUR_DOMAIN}/fullchain.pem     │
│    - /etc/letsencrypt/live/{YOUR_DOMAIN}/privkey.pem       │
└────────────────────┬────────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────────┐
│ 7️⃣ ✅ HTTPS 서빙 시작                                      │
│    새 인증서 적용 완료                                       │
│    Docker 이미지 재빌드 불필요!                            │
└────────────────────────────────────────────────────��────────┘

8. 모니터링 및 확인

8.1 인증서 상태 확인

sudo certbot certificates

8.2 Certbot 로그 확인

sudo tail -50 /var/log/letsencrypt/letsencrypt.log

8.3 Docker 컨테이너 상태 확인

docker ps | grep career-lens
docker logs career-lens

8.4 HTTPS 접속 테스트

curl -v https://{YOUR_DOMAIN}

# 예상 결과:
# HTTP/2 200 (보안 연결 성공)

9. 핵심 체크리스트

항목	완료
Certbot 설치	✅
Let's Encrypt 인증서 발급	✅
application.properties SSL 설정	✅
WebConfig.java HTTP/HTTPS 커넥터 설정	✅
Docker 볼륨 마운트 설정	✅
Post-hook 스크립트 생성	✅
Systemd 타이머 활성화	✅
Dry-run 테스트 성공	✅

10. 트러블슈팅

Q: 포트 80, 443 충돌

# 포트 사용 프로세스 확인
sudo lsof -i :80
sudo lsof -i :443

# 프로세스 종료
sudo kill -9 <PID>

Q: Docker 컨테이너가 재시작되지 않음

# 스크립트 실행 권한 확인
ls -la /etc/letsencrypt/renewal-hooks/post/renew-docker.sh

# Docker 권한 확인
sudo whoami  # root 권한 필요

Q: 인증서가 업데이트되지 않음

# Certbot 갱신 강제 실행
sudo certbot renew --force-renewal --verbose

# 타이머 상태 확인
sudo systemctl status certbot-renew.timer
sudo journalctl -u certbot-renew.service -n 50

Q: Spring Boot가 인증서를 읽지 못함

# 인증서 파일 권한 확인
sudo chmod 755 /etc/letsencrypt/live
sudo chmod 755 /etc/letsencrypt/archive

# Docker 로그 확인
docker logs career-lens | grep -i ssl

결론

Let's Encrypt의 무료 SSL 인증서 + Certbot + Docker 볼륨 마운트의 조합으로 이미지 재빌드 없이 인증서만 자동갱신할 수 있습니다.

Systemd 타이머가 매달 정기적으로 자동 갱신하므로, 개발자는 코드 개발에만 집중하고 인증서 관리는 완전히 자동화할 수 있습니다!

최종 구성:

Certbot: 매달 자동 인증서 갱신
Post-hook: 갱신 후 Docker 자동 재시작
Spring Boot: application.properties에서 새 인증서 자동 로드
사용자: 자동으로 HTTPS 보안 연결

[Next.js] 별도 FE 서버 없이 기존 백엔드에 웹 붙이기

snapcoder — Wed, 21 Jan 2026 08:55:10 +0900

FE 서버 없이 Spring Boot 하나로 PC·모바일 웹까지 배포하기

웹 서비스를 개발하면서 다음과 같은 요구사항이 있었다.

PC 웹과 모바일 웹을 모두 지원하고 싶다
FE용 서버를 별도로 운영하고 싶지 않다
기존 Spring Boot 프로젝트 안에서 FE 수정까지 함께 배포하고 싶다
배포 단위를 하나로 유지하고 싶다

이 글에서는 Spring Boot 프로젝트 하나만 배포해도
FE와 BE가 함께 반영되는 구조를 어떻게 만들었는지 정리한다.

1. 전체 구조 요약

이번 구조의 핵심은 단순하다.

FE는 빌드 결과물만 사용하고
실제 서비스는 Spring Boot가 담당한다

구조는 다음과 같다.

FE: Next.js (Static Export)
BE: Spring Boot
배포 단위: 하나의 Spring Boot 애플리케이션

즉, 별도의 FE 서버나 프로젝트를 운영하지 않는다.

2. 왜 이런 구조를 선택했는가

2-1. 서버를 하나만 운영하고 싶었다

FE 서버 + BE 서버를 나누면 다음 문제가 생긴다.

배포 파이프라인이 2개로 늘어남
환경 변수, 도메인 관리 복잡도 증가
사이드 프로젝트 대비 과한 인프라

이번 프로젝트에서는
운영 복잡도를 최소화하는 것이 가장 중요한 기준이었다.

2-2. Spring Boot 중심 구조를 유지하고 싶었다

이미 Spring Boot 기반 프로젝트가 있었고,

백엔드 기준으로 잘 잡혀 있었다.

FE를 별도 프로젝트로 분리하는 대신,
기존 Spring Boot 프로젝트의 정적 리소스로 포함시키는 방식이 더 적합했다.

3. FE 구성: Next.js를 Static Export로 사용하기

3-1. 왜 Static Export인가

Next.js는 기본적으로 SSR 프레임워크지만,
이번 구조에서는 정적 파일 생성용으로만 사용했다.

이유는 명확하다.

Spring Boot에서 바로 서빙 가능
Node 서버 불필요
빌드 결과물이 HTML / JS / CSS로 떨어짐

즉, Spring Boot의 정적 리소스로 그대로 포함 가능하다.

4. Spring Boot에서 FE 서빙하기

4-1. 정적 리소스 위치

Spring Boot는 기본적으로 다음 경로의 정적 파일을 자동으로 서빙한다.

src/main/resources/static

Next.js 빌드 결과물을
이 경로로 복사하는 구조를 사용했다.

디렉터리 구조 예시

spring-boot-project
└─ src
   └─ main
      └─ resources
         └─ static
            ├─ index.html
            ├─ _next/
            └─ assets/

빌드 결과물이 HTML / JS / CSS로 떨어짐

즉, Spring Boot의 정적 리소스로 그대로 포함 가능하다.

3-2. Next.js 설정 핵심

Next.js 설정에서 중요한 포인트는 다음이다.

출력 방식: Static Export
API Route 사용 ❌
서버 컴포넌트 최소화
순수 FE 역할만 담당

빌드 결과물은
index.html, _next/, assets/ 형태의 정적 파일이 된다.

4. Spring Boot에서 FE 서빙하기

4-1. 정적 리소스 위치

Spring Boot는 기본적으로 다음 경로의 정적 파일을 자동으로 서빙한다.

src/main/resources/static

Next.js 빌드 결과물을
이 경로로 복사하는 구조를 사용했다.

spring-boot-project
└─ src
└─ main
└─ resources
└─ static
├─ index.html
├─ _next/
└─ assets/

이렇게 하면
Spring Boot 애플리케이션 하나만 실행해도
FE 화면이 바로 노출된다.

4-2. 라우팅 처리

SPA 구조를 유지하기 위해
모든 FE 라우팅 요청을 index.html로 포워딩한다.

이를 통해:

PC 웹
모바일 웹
새로고침
직접 URL 접근

모두 정상 동작하도록 구성했다.

5. PC 웹 + 모바일 웹 대응 전략

5-1. 별도 앱은 만들지 않는다

이번 프로젝트에서는 다음을 선택했다.

반응형 웹 ⭕

5-2. 반응형 설계 방식

모바일 퍼스트 레이아웃
Media Query 기반 반응형
Tailwind CSS Responsive Utility 사용

이 방식의 장점은 명확하다.

하나의 코드베이스
PC / 모바일 동시 대응
유지보수 비용 최소화

6. FE 수정 → BE 배포 = 전체 반영 구조

이 구조의 가장 큰 장점은 이것이다.

FE를 수정해도
Spring Boot 한 번 배포하면 전부 반영된다

배포 흐름은 다음과 같다.

FE 코드 수정
Next.js 빌드
빌드 결과물을 Spring Boot static 경로에 포함
Spring Boot 애플리케이션 빌드
서버 배포

결과적으로
배포 단위는 항상 하나다.

7. 이 구조의 장단점

장점

서버 하나만 운영
배포 파이프라인 단순
기존 Spring Boot 구조 유지
사이드 프로젝트에 최적화
설명하기 쉬운 아키텍처

단점

SSR 사용 불가
FE 빌드 시간이 BE 빌드에 포함됨
FE/BE 완전 분리 구조는 아님

하지만 이번 프로젝트의 목적에는
충분히 합리적인 트레이드오프라고 판단했다.

8. 마무리

이번 구조의 핵심은 단순하다.

FE를 독립 서버로 운영하지 않고,
Spring Boot 애플리케이션의 일부로 취급한다

사이드 프로젝트나
운영 부담을 줄이고 싶은 개인 프로젝트에서는
가장 현실적이고 설명 가능한 선택지라고 생각한다.

앞으로도 프로젝트 규모와 목적에 따라
구조를 과하게 만들지 않는 선택을 계속 해나갈 예정이다.

9. 구현

1단계: Gradle 빌드 설정 - FE 빌드 자동화
Spring Boot 프로젝트의 build.gradle을 수정해서 Next.js 빌드 결과물을 자동으로 static 폴더에 복사하도록 설정

// build.gradle 수정 내용
plugins {
    id 'java'
    id 'org.springframework.boot' version '3.x.x'
    id 'io.spring.dependency-management' version '1.x.x'
}

// ... 기존 설정 ...

// ✅ FE 빌드 자동화 추가
task buildNextJS(type: Exec) {
    workingDir = file('frontend')
    commandLine = ['npm', 'run', 'build']
    onlyIf {
        file('frontend').exists()
    }
}

task copyNextJSBuild(type: Copy) {
    dependsOn buildNextJS
    from file('frontend/out')
    into file('src/main/resources/static')
    onlyIf {
        file('frontend/out').exists()
    }
}

// Spring Boot 빌드 전에 FE 빌드 + 복사 실행
processResources.dependsOn copyNextJSBuild

2단계: SPA 라우팅 처리 (Spring Boot Controller 설정)
모든 FE 라우팅 요청을 index.html로 포워딩하는 설정

새 파일 생성: src/main/java/com/example/config/WebConfig.java
이 파일에서:
- 정적 리소스 서빙 설정
- SPA 라우팅 포워딩 규칙 추가

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        // 정적 리소스 처리 (_next, assets 등)
        registry.addResourceHandler("/**")
                .addResourceLocations("classpath:/static/")
                .setCachePeriod(3600);
    }

    @Override
    public void addViewControllers(ViewControllerRegistry registry) {
        // SPA 라우팅: 정적 파일이 아닌 모든 경로를 index.html로 포워딩
        registry.addViewController("/{spring:\\w+}")
                .setViewName("forward:/index.html");
        registry.addViewController("/**/{spring:\\w+}")
                .setViewName("forward:/index.html");
        registry.addViewController("/**/{spring:\\w+}/**")
                .setViewName("forward:/index.html");
    }
}

이 설정으로:
✅ / → index.html 로드
✅ /about → index.html 로드 (새로고침 가능)
✅ /_next/* → 정적 파일 직접 서빙
✅ /api/* → 컨트롤러로 라우팅

3단계: Next.js 프로젝트 초기화
이제 frontend/ 디렉터리에 Next.js 프로젝트를 생성하고 Static Export로 설정

npx create-next-app@latest frontend --typescript --tailwind --no-eslint
cd frontend

그 다음 next.config.ts를 수정:

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
    /* config options here */
    output: "export",
    reactStrictMode: true,
};

export default nextConfig;

package.json 확인:

{
  "scripts": {
    "build": "next build",
    "dev": "next dev"
  }
}

Next.js 프로젝트 생성완료

4단계: 통합 빌드 테스트

./gradlew clean build

빌드 성공 시:
✅ frontend/out/ 디렉터리 생성됨
✅ build/resources/main/static/ 에 Next.js 정적 파일 복사됨
✅ build/libs/*.jar 생성됨
이제 java -jar build/libs/*.jar 실행하면 Spring Boot에서 Next.js 프론트엔드를 서빙

현재 상태 정리:
✅ build.gradle - FE 빌드 자동화 설정 완료
✅ WebConfig.java - SPA 라우팅 설정 완료
✅ frontend/ - Next.js Static Export 설정 완료
✅ ./gradlew clean build - 통합 빌드 완료
✅ java -jar build/libs/*.jar - JAR 실행 확인 완료

// 전체 CI/CD 흐름 정리

1. 커밋 발생 (master 브랜치)
   ↓
2. GitHub Actions 트리거 (docker-ci.yml)
   ↓
3. 환경 설정
   ├─ 코드 체크아웃
   ├─ JDK 17 설치
   ├─ Node.js 18 설치
   └─ gradlew 실행 권한 부여
   ↓
4. Gradle 빌드 (./gradlew build -x test)
   ├─ buildNextJS 태스크 실행
   │  └─ npm run build (Next.js 정적 빌드)
   ├─ copyNextJSBuild 태스크 실행
   │  └─ frontend/out → src/main/resources/static 복사
   └─ Spring Boot JAR 생성 (FE 포함)
   ↓
5. Docker 이미지 빌드
   └─ Dockerfile로 JAR를 기반으로 이미지 생성
   ↓
6. Docker Hub 로그인 및 푸시
   └─ signalix:latest 이미지 업로드
   ↓
7. Oracle Cloud 서버 배포 (SSH)
   ├─ Docker 이미지 풀
   ├─ 기존 컨테이너 중지/제거
   └─ 새 컨테이너 실행 (포트 80, 환경변수 설정)
   ↓
8. 배포 완료 ✅
   └─ http://서버IP 접속 가능

핵심:
✅ FE 수정 → 커밋 → 자동 반영
✅ BE 수정 → 커밋 → 자동 반영
✅ 둘 다 수정 → 커밋 → 하나의 JAR로 배포

현재 상태: 완전 자동화 완료!

배포결과

어떤 서비스 소개 페이지처럼 만들어달라했더니.. 너무 예쁘게 해줬다...

커밋 한번 하면, BE/FE 둘다 반영되어 앞으로 토이 프로젝트 개발이 진짜 편할 것 같다~ ~~(무료 서버 1개 치고는 만족)~~

모바일도 ok

[Github Copilot] java.lang.IllegalArgumentException: Argument for @NotNull parameter 'fileType'

snapcoder — Tue, 20 Jan 2026 23:27:21 +0900

[Github Copilot] java.lang.IllegalArgumentException: Argument for @NotNull parameter 'fileType'

인텔리제이(IntelliJ IDEA)를 사용하다가 갑자기 GitHub Copilot Chat에서 발생하는 java.lang.IllegalArgumentException 오류로 당황하셨을 분들을 위해 해결 방법을 정리해 드립니다.

[오류 해결] IntelliJ x GitHub Copilot Chat: "Argument for @NotNull parameter 'fileType'"

최근 GitHub Copilot Chat 기능을 사용하려 할 때 아래와 같은 에러 로그와 함께 기능이 멈추는 현상이 보고되고 있습니다.

java.lang.IllegalArgumentException: Argument for @NotNull parameter 'fileType' of ... must not be null

결론부터 말씀드리면, 이는 인텔리제이 본체 버전과 코파일럿 플러그인 버전 사이의 호환성 문제일 가능성이 매우 높습니다.

1. 에러의 의미: 왜 이런 일이 발생할까?

이 에러를 기술적으로 한 줄 해석하면 다음과 같습니다.

"IDE가 플러그인에게 '지금 무슨 파일 타입이야?'라고 물었는데, 플러그인이 '몰라(null)'라고 답해서 터진 상황"

인텔리제이는 내부 API 메서드를 호출할 때 @NotNull 어노테이션을 통해 특정 파라미터(여기서는 fileType)가 절대 비어있으면 안 된다고 명시합니다. 하지만 플러그인이 IDE의 기대치와 다른 값을 넘겨주면서 예외가 발생합니다.

왜 "업데이트 미루기"가 원인이 될까?

잦은 API 변경: IntelliJ는 버전이 올라갈 때마다 플러그인이 참조하는 내부 API를 자주 변경합니다.
코파일럿의 깊은 개입: Copilot Chat은 단순히 채팅만 하는 게 아니라 에디터, 파일 타입, PSI(구문 분석 트리), UI 패널 등을 깊게 건드립니다.
버전 불일치: Copilot 플러그인은 최신 IDE 버전에 맞춰 업데이트되었는데, 사용하는 IntelliJ가 구버전이면 플러그인이 존재하지 않는 API를 호출하거나 잘못된 값을 전달하게 됩니다.

2. 내 코드의 문제일 확률은?

0%에 가깝습니다.

이 에러는 여러분이 작성 중인 Java 코드의 문법 오류나 런타임 에러가 아닙니다. IDE(인텔리제이)라는 프로그램 자체와 확장 도구(코파일럿) 사이의 충돌일 뿐입니다. 안심하고 도구 설정만 손보시면 됩니다.

3. 가장 확실한 해결 순서 (Action Plan)

문제를 해결하기 위해 아래 순서대로 진행해 보세요.

✅ 1순위: IntelliJ IDEA 업데이트

가장 권장하는 방법입니다. 현재 사용 중인 메이저 버전을 확인하고 업데이트를 진행하세요.

방법: Help -> Check for Updates (Mac은 IntelliJ IDEA -> Check for Updates)
팁: 2024.1 버전을 쓰고 있다면 최소 2024.3 등 최신 패치 버전으로 올리는 것이 좋습니다.

✅ 2순위: Copilot 플러그인 업데이트

IDE를 업데이트했다면 플러그인도 최신 상태인지 확인해야 합니다.

방법: Settings (Ctrl+Alt+S) -> Plugins -> Installed 탭
GitHub Copilot과 GitHub Copilot Chat 두 가지 모두 업데이트 버튼이 떠 있는지 확인하세요.

✅ 3순위: 캐시 무효화 (Invalidate Caches)

업데이트 후에도 찌꺼기가 남아 에러가 발생할 수 있습니다.

방법: File -> Invalidate Caches... -> 모든 항목 체크 후 Invalidate and Restart

4. 언제 무시해도 되고, 언제 고쳐야 할까?

현상심각도조치

로그에만 찍히고 사용엔 지장이 없다	낮음	시간 날 때 업데이트
채팅창이 하얗게 나오거나 응답이 없다	중간	플러그인 재시작 또는 업데이트
입력할 때마다 에러 팝업이 뜨고 IDE가 멈춘다	높음	즉시 업데이트 필수

요약 및 결론

이번 에러는 **IntelliJ 업데이트를 안 해서 생길 가능성이 거의 99%**입니다. Copilot은 클라우드 기반 서비스라 서버 쪽 로직이 계속 변하고, 이에 맞춰 플러그인도 빠르게 업데이트됩니다. 이 속도를 IDE 본체가 따라가지 못해 생기는 일종의 '세대 차이' 에러라고 이해하시면 됩니다.

지금 바로 인텔리제이를 업데이트하고 쾌적한 AI 페어 프로그래밍을 다시 즐겨보세요!

도움이 되셨나요? 혹시 현재 사용 중인 IntelliJ 버전에서 업데이트가 불가능한 특수한 상황(회사 보안 정책 등)이라면, 해당 버전에서 작동하는 안전한 이전 버전의 Copilot 플러그인 설치 방법을 추가로 가이드해 드릴 수 있습니다. 궁금하시면 댓글로 알려주세요!

[CICD] 커밋만 하면 배포되게 만들기: GitHub Actions + Docker CI/CD 삽질기

snapcoder — Tue, 20 Jan 2026 22:47:46 +0900

커밋만 하면 배포되게 만들고 싶었다: GitHub Actions + Docker CI/CD 삽질기

1. 글을 쓰게 된 배경

Spring Boot 프로젝트를 하나 새로 시작하면서, 커밋만 하면 자동으로 서버에 배포되는 구조를 처음부터 제대로 만들어보고 싶었다.

그동안 회사에서는 이미 잘 짜여진 CI/CD 파이프라인 위에서만 작업하다 보니, 정작 Docker, GitHub Actions, 서버 배포를 처음부터 끝까지 직접 구성해본 경험은 많지 않았다.

이번에 개인 프로젝트를 하면서 다음을 목표로 잡았다.

Spring Boot + Java 17
GitHub Actions 기반 CI/CD
Docker Hub 이미지 빌드 및 푸시
Oracle Cloud 무료 서버에 컨테이너 배포

그리고… 역시나 한 번에 될 리는 없었다

이 글은 그 삽질 과정을 정리한 기록이다.

2. 전체 아키텍처 구성

구성은 아래와 같다.

[GitHub Repository]
        ↓ (push to master)
[GitHub Actions]
        ↓
[Docker Image Build]
        ↓
[Docker Hub]
        ↓
[Oracle Cloud VM]
        ↓
[Spring Boot Container 실행]

브랜치: master
트리거: push
배포 방식: SSH 접속 후 docker pull & run

3. GitHub Actions 워크플로우 설정

docker-ci.yml

name: Docker CI/CD

on:
  push:
    branches:
      - master

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: '17'
          distribution: 'temurin'

      - name: Grant execute permission for gradlew
        run: chmod +x gradlew

      - name: Build with Gradle
        run: ./gradlew build -x test

      - name: Log in to Docker Hub
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      - name: Build Docker image
        run: docker build -t ${{ secrets.DOCKER_USERNAME }}/signalix:latest .

      - name: Push Docker image
        run: docker push ${{ secrets.DOCKER_USERNAME }}/signalix:latest

      - name: Deploy to Oracle Cloud
        uses: appleboy/ssh-action@v0.1.8
        with:
          host: ${{ secrets.ORACLE_HOST }}
          username: ${{ secrets.ORACLE_USER }}
          key: ${{ secrets.ORACLE_SSH_PRIVATE_KEY }}
          port: 22
          script: |
            docker login -u ${{ secrets.DOCKER_USERNAME }} -p ${{ secrets.DOCKER_PASSWORD }}
            docker pull ${{ secrets.DOCKER_USERNAME }}/signalix:latest
            docker stop signalix || true
            docker rm signalix || true
            docker run -d \
              --name signalix \
              -p 80:80 \
              -e SPRING_PROFILES_ACTIVE=prd \
              -e DB_USERNAME=${{ secrets.DB_USERNAME }} \
              -e DB_PASSWORD=${{ secrets.DB_PASSWORD }} \
              ${{ secrets.DOCKER_USERNAME }}/signalix:latest

초기 단계에서는 테스트 때문에 CI가 자주 깨질 수 있어서 -x test 옵션을 사용했다.

4. Dockerfile 설정

최종 Dockerfile

FROM eclipse-temurin:17-jre-jammy

WORKDIR /app

COPY build/libs/*.jar app.jar

EXPOSE 80

ENTRYPOINT ["java", "-Duser.timezone=Asia/Seoul", "-jar", "app.jar"]

왜 eclipse-temurin 인가?

처음에는 아래 이미지를 사용했다.

FROM openjdk:17-jdk-slim

하지만 GitHub Actions에서 아래 에러가 발생했다.

ERROR: docker.io/library/openjdk:17-jdk-slim: not found

조사해보니 openjdk 공식 이미지 중 일부 태그가 deprecated / 제거된 상태였다.

현재 Java 17 + Spring Boot 기준으로는

eclipse-temurin이 사실상 표준
GitHub Actions, Docker Hub, 클라우드 환경 모두에서 안정적

이라는 결론에 도달했다.

5. 실제 삽질 포인트 정리

1️⃣ exit code 126

Process completed with exit code 126

원인:

gradlew 실행 권한 없음

해결:

- run: chmod +x gradlew

2️⃣ Deploy 단계가 실행되지 않음

Evaluating condition for step: success()
=> false

원인:

앞 단계(Docker build)에서 실패
Deploy 단계는 아예 실행되지 않음

항상 가장 먼저 실패한 step 로그부터 확인해야 한다.

3️⃣ Docker 이미지 pull 실패

원인:

잘못된 base image 태그

해결:

openjdk → eclipse-temurin 교체

6. 배포 결과

master 브랜치에 커밋
GitHub Actions 자동 실행
Docker Hub에 이미지 생성
Oracle Cloud 서버에서 컨테이너 자동 재시작

7. 마무리하며

이번에 느낀 점은 딱 하나다.

CI/CD는 한 번에 되는 게 아니라, 로그를 읽으면서 차분히 하면 결국엔 완성된다.

특히 GitHub Actions는 에러 메시지를 굉장히 솔직하게 보여주기 때문에

어디서 실패했는지
왜 다음 step이 실행되지 않았는지

를 차분히 따라가면 반드시 해결할 수 있다.

비슷한 삽질을 하고 있는 분들에게 이 글이 도움이 되었으면 좋겠다.

[CICD] Execute permission for Gradle Wrapper in CI workflow

snapcoder — Tue, 20 Jan 2026 01:07:49 +0900

github actions 126 에러 코드 발생시 해결 방법

build-and-deploy

Process completed with exit code 126.

.github/workflows/docker-ci.yml 파일에 Gradle Wrapper 실행 권한 부여해주기 (3.1.처럼)

# 3.1. Gradle Wrapper 실행 권한 부여 (exit code 126 해결)
- name: Grant execute permission for gradlew
  run: chmod +x gradlew

# 3.2. Gradle 빌드 (초기엔 테스트 제외 권장)
- name: Build with Gradle
  # run: ./gradlew build # 전체 빌드 (테스트 포함)
  run: ./gradlew build -x test  # 테스트 제외하고 빌드

[DB] Supabase가 DBeaver에 연결되지 않는 경우 해결 방법

snapcoder — Thu, 15 Jan 2026 23:48:27 +0900

이와 함께 아래와 같은 안내 문구가 표시된다.

Not IPv4 compatible
Use Session Pooler if on a IPv4 network or purchase IPv4 add-on

처음에는 이 문구를 못봤어서 원인을 한참 헤맸다.

문제 원인

Direct connection은 IPv6 전용

Supabase의 Direct connection 방식은 기본적으로 IPv6 환경에서만 동작한다.

하지만 대부분의 개인 개발 환경은 다음과 같다.

가정용 인터넷
개인 PC
일반 회사 네트워크

➡️ 거의 대부분 IPv4-only 네트워크

이 상태에서 Direct connection JDBC 주소를 그대로 사용하면
DBeaver에서는 연결이 실패할 수밖에 없다.

해결 방법 1: Session Pooler 사용 (권장)

Supabase는 IPv4 환경을 위한 Session Pooler (PgBouncer) 를 제공한다.

Session Pooler 특징

IPv4 환경에서도 연결 가능
DBeaver, DataGrip 같은 DB Client에 적합
Direct connection과 다른 포트 사용

Supabase 콘솔에서
Session Pooler 항목을 선택하면 다음과 같은 JDBC 정보를 확인할 수 있다.

jdbc:postgresql://aws-0-ap-northeast-2.pooler.supabase.com:6543/postgres ?user=postgres &password=[YOUR-PASSWORD]

이 주소를 그대로 DBeaver에 입력하면
정상적으로 연결된다.

연결 성공 화면

[DB] BaaS형 postgres 툴 추천 (개인 프로젝트에 강추)

snapcoder — Thu, 15 Jan 2026 23:08:57 +0900

[DB] BaaS형 postgres 툴 추천 (개인 프로젝트에 강추)

https://supabase.com/

Supabase | The Postgres Development Platform.

Build production-grade applications with a Postgres database, Authentication, instant APIs, Realtime, Functions, Storage and Vector embeddings. Start for free.

supabase.com

간략히 말해보자면,

웹에서 DBeaver처럼 DB작업 가능하고, Connection String까지 제공해준다.

개인 프로젝트에 제격인 셈,

[DB] SaaS형 PostgreSQL 툴 추천 – Supabase

개인 프로젝트나 사이드 프로젝트를 진행하다 보면
DB 구축과 운영 자체가 목적이 아니라, 기능 구현이 목적인 경우가 많다.

이럴 때 직접 DB 서버를 띄우고, 보안 설정하고, 백업까지 관리하는 방식은
생각보다 많은 시간과 에너지를 소모한다.

이런 상황에서 유용하게 사용할 수 있는 SaaS형 PostgreSQL 서비스가 바로
Supabase다.

공식 사이트: https://supabase.com/

Supabase란?

Supabase는 PostgreSQL 기반의 오픈소스 BaaS(Backend as a Service) 플랫폼이다.

한 줄로 요약하면:

“PostgreSQL을 기반으로 인증, API, 스토리지까지 한 번에 제공하는 DB 중심 SaaS”

단순히 DB만 제공하는 것이 아니라,
백엔드 개발에 필요한 핵심 기능들을 함께 제공하는 것이 특징이다.

왜 PostgreSQL 기반이 중요한가?

Supabase의 가장 큰 장점 중 하나는
DB가 추상화된 NoSQL이 아니라, ‘진짜 PostgreSQL’이라는 점이다.

표준 SQL 사용 가능
기존 PostgreSQL 문법, 함수, 인덱스 그대로 사용
로컬 PostgreSQL → Supabase 이전이 쉬움

즉, 학습용이나 포트폴리오용으로도 경험이 그대로 쌓인다.

Supabase 주요 기능

1. Managed PostgreSQL

PostgreSQL 최신 버전 기반
자동 백업 및 관리
웹 콘솔에서 테이블 / 쿼리 관리 가능

“DB 관리”보다 “개발”에 집중 가능

2. 인증(Auth) 기능 기본 제공

Email / Password
OAuth (Google, GitHub 등)
JWT 기반 인증

별도의 인증 서버 없이도
서비스 수준의 인증 구조를 빠르게 구성 가능

3. Auto-generated REST & Realtime API

테이블 생성만 해도 REST API 자동 생성
실시간 데이터 변경 구독(Reatime) 지원

CRUD API를 직접 만들지 않아도 됨
프론트엔드와 바로 연동 가능

4. 무료 플랜 제공 (개인 프로젝트에 충분)

Free tier 제공
소규모 트래픽, 개인 프로젝트, 포트폴리오 용도로 충분
카드 없이 시작 가능

학생 / 취준생 / 사이드 프로젝트에 특히 적합

이런 경우에 특히 추천

개인 프로젝트 / 포트폴리오
빠르게 MVP를 만들어야 하는 경우
DB 운영보다 기능 구현에 집중하고 싶은 경우
PostgreSQL 경험을 쌓고 싶은 경우

반대로,

대규모 트래픽
커스터마이징이 많은 DB 튜닝
복잡한 인프라 설계가 목적

이라면 직접 DB를 운영하는 편이 더 적합할 수 있다.

실제 사용해보며 느낀 장점

초기 세팅이 매우 빠르다
콘솔 UI가 직관적이다
PostgreSQL 기반이라 학습 가치가 높다
“임시 DB”가 아니라 “실제 서비스 DB”로 써도 무방하다

단순한 토이 프로젝트를 넘어,
‘설계 경험’까지 가져갈 수 있는 도구

마무리

Supabase는
**“DB를 직접 관리하는 부담은 줄이고,
PostgreSQL의 장점은 그대로 가져가고 싶은 개발자”**에게 잘 맞는 선택이다.

특히 개인 프로젝트나 취업 준비용 프로젝트에서
빠른 개발 + 실무 감각을 동시에 가져가고 싶다면
한 번쯤은 충분히 써볼 가치가 있다.

참고 링크

Supabase 공식 사이트: https://supabase.com/
Supabase Docs: https://supabase.com/docs

Supabase Docs

Supabase is the Postgres development platform providing all the backend features you need to build a product.

supabase.com

보너스

1️⃣ SaaS vs BaaS 차이 (핵심만)

SaaS (Software as a Service)

완성된 소프트웨어를 제공
사용자는 기능을 “쓴다”

예시:

Notion
Slack
Jira
Figma

개발하지 않아도 바로 사용 가능

BaaS (Backend as a Service)

개발자를 위한 백엔드 구성 요소 제공
인증, DB, API, 스토리지 등

예시:

Supabase
Firebase
Appwrite

서비스를 만들기 위한 재료

[AI] 국내외 AI 전사 확산 도입 사례 모음

snapcoder — Thu, 15 Jan 2026 22:00:31 +0900

국내 기업 사례

구분	기업 명	프로그램 명	주요 특징	세부 내용	출처
교육	삼성전자	생성형 AI 파워 유저 교육 (2024.06~)	전 임직원 대상 4단계 교육 과정 이론 교육: 생성형 AI의 이해, 업무별 활용 사례 등 실습 교육: AI 도구 제작 등		https://www.sedaily.com/NewsView/2DE5EEKWR9
	포스코그룹	임원 대상 AI 체험 실습 워크숍 (2024.11)	챗GPT 기본기 및 챗봇 생성 실습 외부 교육 기업(AI Ground)과 협업		https://www.aiground.co.kr/posco-executive-ai-workshop/
	LG그룹	LG AI 대학원 (2025.09~)	사내 포털을 통해 석사 수준의 과목 제공(최신 AI Agent 트랙 포함) 현업 데이터를 활용한 실전형 AI 인재 자체 육성 + 외부 인재 유치(중장기) 목적 수료 시 LG AI 대학원 자체 명의의 석·박사(교육부 인가 후 국가 공인) 교수진: LG AI Research 내부 박사·임원급 연구자 20여 명 + 외부 석학		https://www.lgresearch.ai/aigraduateschool/introduction
	LG전자	생성형 AI 사내 교육 프로그램	초급 과정 - 생성형 AI의 이해 및 활용 사례 중급 과정 - 챗GPT, GPTs를 활용한 효율적인 업무 수행 방법 오프라인 교육도 개설 (2025.02~)		https://live.lge.co.kr/2502-lg-aigptedu/
		임원 대상 AI 및 SW 교육 (2024.05~09)	최신 기술 트렌드 교육 AI 기술이 적용된 제품 사례 새로운 콘텐츠를 만드는 생성형 AI
		AI 기술 트렌드 온라인 세미나 (2024.11)	MIT·코넬대 교수 등 전문가 초청 최신 기술 동향 소개
	한화그룹	임원 대상 생성형 AI 역량 강화 교육 (2024.09)	챗GPT 사용 업무 효율화 방법 교육 (프롬프트 엔지니어링 등) 외부 교육 기업(주식회사 사용성연구소)과 협업		https://www.theuxlabs.com/hanhwa-ai-education/
	넷마블	Game Developer Forum (GDF)	내·외부 전문가 강연 (지식 공유 목적) 2024년에는 LLM, AI 관련 실무 적용 사례도 소개		https://ch.netmarble.com/ESG/EverybodysESG/Detail?post_seq=5374&bbs_code=1015
해커톤	포스코그룹	WX 해커톤 (2024.12)	WX: 포스코 그룹 고유의 DX 기반 일하는 방식 변화 그룹사 혼합 팀 구성 AI 솔루션 공동 개발 외부 교육 기업(팀스파르타)과 협업		https://b2b.spartacodingclub.kr/blog/posco-wx-hackathon-interview
	LG전자	전사 생성형 AI 해커톤 (2024.08)	생성형 AI 기반 반복 업무 효율화 아이디어 발굴	수상작: 1. 글로벌 맞춤형 광고 콘텐츠 자동 제작 2. VOC·리뷰를 실시간 분석해 고객경험 개선점 추출 3. SW 개발 문서 자동화 파이프라인 → 현업에 적용	https://live.lge.co.kr/2412_lg_genai-hackerthon/
	카카오	사내 해커톤 ‘24K’ (2024.06)	‘AI native company’ 라는 주제로 진행 서비스를 포함한 다양한 AI 기술 적용 아이디어 모집 다양한 직군의 카카오 크루 170여 명 참여 AI 서비스 프로토타입 24시간 동안 구현		https://www.kakaocorp.com/page/detail/11132
	카카오	사내 해커톤 ‘10K’ (2025.06)	’에이전틱 AI’ 주제로 바이브코딩 활용하여 진행 전 직군 대상으로 확대, 참여율 전년 대비 50% 증가 10시간으로 축소 → 짧은 시간 안에 MVP(최소 기능 제품) 구현 목표		https://tech.kakao.com/posts/708
	카카오페이	사내 해커톤 ‘카페톤’ (2025.04)	AWS와 공동 진행 AWS 생성형 AI로 금융 서비스 개선 아이디어 제시	수상작: 1. 고객 얼굴 + 결제 이력 인식 → 초(超)개인화 메뉴 추천·결제(RAG 활용) 2. 거래 내역 기반 이미지 생성 → 일상 기록 서비스 3. 오디오 타입에 맞는 최적화된 스크립트와 유용한 회의록을 생성 → AI가 카카오페이 내부 용어 학습	https://tech.kakaopay.com/post/kakaopay-dr-04/
	카카오엔터테인먼트	사내 해커톤 '엔터톤' (2024.12)	'AI와 함께하는 엔터테인먼트’를 주제로 전체 크루 대상 진행	수상작: 1. 이용자들의 음원 댓글 반응을 측정하는 AI 모델 2. 카카오페이지 웹툰, 웹소설 베스트 댓글을 가공하여 마케팅에 활용하는 AI 3. 아티스트 실시간 방송 댓글을 분석하여 직접 하이라이트 요약 영상을 제작하는 AI	https://kakaoent.com/pr/detail/173
사내 제도 등	삼성전자	AI 크루 제도 (2025.04~)	300명 규모로 운영 (사업부 별로 모집) 현장 AI 과제 발굴 및 실행을 주도하는 선봉대 역할		https://news.nate.com/view/20250603n11503
	SK그룹	AI 역량 인증 시험 ‘SKADA’ (2023.06~)	사내 교육 플랫폼 '써니' + KAIST가 공동 개발 해당 인증을 따면 사내 평가와 승진·인사이동 면에서 혜택		https://www.sedaily.com/NewsView/2DE5EEKWR9
	크래프톤	AI Fellowship	대학생 대상 2개월 간 인턴십 + AI 프로젝트 경험 제공		https://www.krafton.ai/ko/career/ai-fellowship/

해외 기업 사례

구분	기업 명	프로그램 명	주요 특징	세부 내용	출처
편의 기능 /서비스	Salesforce	AgentExchange (2025.03~)	AI 에이전트 전용 마켓플레이스 → 개발자, 파트너, 사용자 커뮤니티가 AI 에이전트를 구축하고 수익화할 수 있는 플랫폼 200개 이상의 파트너(Google Cloud, Docusign, Workday 등)가 참여 Salesforce의 에이전트 개발 도구 'Agent Builder'에 직접 통합되어 사용자 친화적 탐색 및 적용 가능 사전 구축된 AI 액션, 프롬프트 템플릿, 토픽, 에이전트 템플릿 제공 보안 검토와 고객 리뷰를 통과한 신뢰할 수 있는 컴포넌트만 등록	파트너 사례 Google Cloud: Vertex AI 기반 실시간 검색 가능 에이전트 Box: 비정형 데이터에서 인사이트 추출 Docusign: 문서 작성-서명-추적 자동화 Workday: 직원 온보딩, 복리후생 등 셀프서비스 자동화	https://www.salesforce.com/news/press-releases/2025/03/04/agentexchange-announcement/
	Activision Blizzard	Blizzard Diffusion	사내 컨셉 아트 생성 AI 툴 → 게임 환경, 캐릭터, 외형 디자인의 컨셉 아트 제작 지원 자체 데이터셋(월드 오브 워 크래프트, 디아블로 이미지 등) 학습		https://www.gamedeveloper.com/business/blizzard-says-new-ai-concept-art-tool-represents-major-evolution-
	Meta	Devmate (2025.06~)	사내 AI 코딩 어시스턴트 Anthropic의 Claude 모델 활용		https://www.digitaltoday.co.kr/news/articleView.html?idxno=570865
교육	Microsoft	Viva Learning - Copilot Academy (2025.05~)	Viva Learning(직원 학습, 교육 플랫폼) 안에 사내 전용 Copilot 학습 허브 자동 생성 관리자-맞춤 커리큘럼으로 전 직원 실습·평가		https://learn.microsoft.com/en-us/viva/learning/academy-copilot
	Google	AI Essentials 인증 코스	직원 및 외부 연수용 단기 코스(온라인) 5개 모듈(생산성·프롬프트·Responsible AI 등) 수료 과정, 수료증 지급		https://grow.google/ai-essentials/
	Google	사내 교육 플랫폼 'Grow' 개편 (2025.06)	직원들의 AI 사용을 장려하기 위해 기존의 교육 과정을 대부분 AI 관련 과정으로 대체		https://www.nbcnewyork.com/news/business/money-report/google-overhauls-internal-learning-platform-to-focus-on-ai-business-priorities/6297101/
	Amazon	AI Ready (2023.11~)	2025년까지 200만명에게 무료로 AI 기술 교육을 제공하는 것을 목표로 시작	AWS Educate을 통해 비즈니스/비기술 직무 참여자를 위한 과정 제공 (생성형 AI 기초 사용법 등) AWS Skill Builder을 통해 개발자/기술 직무 참여자를 위한 과정 제공 (언어모델 구축, 미세조정 등)	https://www.businesswire.com/news/home/20231119572231/en/Amazon-Announces-AI-Ready-a-New-Initiative-Designed-to-Provide-Free-AI-Skills-Training-to-2-Million-People-by-2025
해커톤	Microsoft	Copilot Studio Enterprise Agent Challenge (2025.05~06)	3 주간 직원/파트너 약 7,500 명이 ‘업무 프로세스 자동화 에이전트’ 시제품을 개발 (Copilot Studio 활용) 우수 팀은 CEO 타운홀에서 시연 Power CAT 팀 주도		https://www.microsoft.com/en-us/microsoft-copilot/blog/copilot-studio/register-now-for-the-upcoming-copilot-studio-enterprise-agent-challenge/

[코딜리티] FrogJmp

snapcoder — Sun, 11 Jan 2026 23:26:27 +0900

[코딜리티] FrogJmp

문제정의 : 개구리의 현재위치에서, 원하는 위치 이상까지 가려면, 몇번 점프해야 하는가?

풀이 : 가야할 거리를 구하고, 몫을 소수로 계산해서 올림처리.

Tasks Details

easy

1. FrogJmp

Count minimal number of jumps from position X to Y.

Task Score

100%

Correctness

100%

Performance

100%

Task description

A small frog wants to get to the other side of the road. The frog is currently located at position X and wants to get to a position greater than or equal to Y. The small frog always jumps a fixed distance, D.

Count the minimal number of jumps that the small frog must perform to reach its target.

Write a function:

class Solution { public int solution(int X, int Y, int D); }

that, given three integers X, Y and D, returns the minimal number of jumps from position X to a position equal to or greater than Y.

For example, given:

X = 10 Y = 85 D = 30

the function should return 3, because the frog will be positioned as follows:

after the first jump, at position 10 + 30 = 40

after the second jump, at position 10 + 30 + 30 = 70

after the third jump, at position 10 + 30 + 30 + 30 = 100

Write an efficient algorithm for the following assumptions:

X, Y and D are integers within the range [1..1,000,000,000];

X ≤ Y.

Solution

Programming language usedJava 21

Time spent on task10 minutes

help

Notes

not defined yet

Task timeline

Beta

help

Code: 14:23:20 UTC, java, final, score: 100

show code in pop-up

1 2 3 4 5 6 7 8 9 10 11 12 13

// you can also use imports, for example:
// import java.util.*;

// you can write to stdout for debugging purposes, e.g.
// System.out.println("this is a debug message");

class Solution {
    public int solution(int X, int Y, int D) {
        // Implement your solution here
        int diff = Y-X;     // 75
        return (int) Math.ceil( (double)diff/D ); // 75/30=3
    }
}

play_arrow

check

14:13:32

14:23:21

Away from Codility tab

Analysis summary

The solution obtained perfect score.

Analysis

Detected time complexity:

O(1)

expand allExample tests

▶

example
example test

✔

expand allCorrectness tests

▶

simple1
simple test

✔

▶

simple2

✔

▶

extreme_position
no jump needed

✔

▶

small_extreme_jump
one big jump

✔

expand allPerformance tests

▶

many_jump1
many jumps, D = 2

✔

▶

many_jump2
many jumps, D = 99

✔

▶

many_jump3
many jumps, D = 1283

✔

▶

big_extreme_jump
maximal number of jumps

✔

▶

small_jumps
many small jumps

✔

[코딜리티] OddOccurrencesInArray

snapcoder — Sun, 11 Jan 2026 23:12:35 +0900

[코딜리티] OddOccurrencesInArray

문제정의 : 배열의 값중에서 1개만 나오는 솔로값 찾기.

풀이 : 배열 전체검색해서 카운팅해주고, Key값이 홀수인 경우 찾기.

Tasks Details

easy

1. OddOccurrencesInArray

Find value that occurs in odd number of elements.

Task Score

100%

Correctness

100%

Performance

100%

Task description

A non-empty array A consisting of N integers is given. The array contains an odd number of elements, and each element of the array can be paired with another element that has the same value, except for one element that is left unpaired.

For example, in array A such that:

A[0] = 9 A[1] = 3 A[2] = 9 A[3] = 3 A[4] = 9 A[5] = 7 A[6] = 9

the elements at indexes 0 and 2 have value 9,

the elements at indexes 1 and 3 have value 3,

the elements at indexes 4 and 6 have value 9,

the element at index 5 has value 7 and is unpaired.

Write a function:

class Solution { public int solution(int[] A); }

that, given an array A consisting of N integers fulfilling the above conditions, returns the value of the unpaired element.

For example, given array A such that:

A[0] = 9 A[1] = 3 A[2] = 9 A[3] = 3 A[4] = 9 A[5] = 7 A[6] = 9

the function should return 7, as explained in the example above.

Write an efficient algorithm for the following assumptions:

N is an odd integer within the range [1..1,000,000];

each element of array A is an integer within the range [1..1,000,000,000];

all but one of the values in A occur an even number of times.

Solution

Programming language usedJava 21

Time spent on task38 minutes

help

Notes

not defined yet

Task timeline

Beta

help

Code: 14:03:18 UTC, java, final, score: 100

show code in pop-up

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

// you can also use imports, for example:
// import java.util.*;
import java.util.*;

// you can write to stdout for debugging purposes, e.g.
// System.out.println("this is a debug message");

class Solution {
    public int solution(int[] A) {
        // Implement your solution here

        Map<Integer, Integer> map = new HashMap<>();
        for(int i=0; i<A.length; i++){
            int cur = A[i];
            map.put(cur, map.getOrDefault(cur, 0) + 1);
        }

        for(int key : map.keySet()){
            if(map.get(key) % 2 == 1){
                return key;
            }
        }
        return A[0];
    }
}

play_arrow

check

13:25:38

14:03:19

Away from Codility tab

Analysis summary

The solution obtained perfect score.

Analysis

Detected time complexity:

O(N) or O(N*log(N))

expand allExample tests

▶

example1
example test

✔

expand allCorrectness tests

▶

simple1
simple test n=5

✔

▶

simple2
simple test n=11

✔

▶

extreme_single_item
[42]

✔

▶

small1
small random test n=201

✔

▶

small2
small random test n=601

✔

expand allPerformance tests

▶

medium1
medium random test n=2,001

✔

▶

medium2
medium random test n=100,003

✔

▶

big1
big random test n=999,999, multiple repetitions

✔

▶

big2
big random test n=999,999

✔

[코딜리티] CyclicRotation

snapcoder — Sat, 10 Jan 2026 23:05:38 +0900

[코딜리티] CyclicRotation

문제요약 : 배열을 주어진 수만큼 shift해서 재정렬한다.

풀이 :

배열의 길이보다 K가 클때는 동일한 결과가 나오기 때문에, 몫을 찾아준다.

K = K % len; // shift 2 == shift 7 == shift 12 == ...

뒤에서 K번째부터 정답배열에 저장하고,
len에 도달하면 처음부터 저장해주면 된다.

// A = [3, 8, 9, 7, 6]

// K = 2

// [7, 6] + [3, 8, 9]

// return [7, 6, 3, 8, 9]

Tasks Details

easy

1. CyclicRotation

Rotate an array to the right by a given number of steps.

Task Score

100%

Correctness

100%

Performance

Not assessed

Task description

An array A consisting of N integers is given. Rotation of the array means that each element is shifted right by one index, and the last element of the array is moved to the first place. For example, the rotation of array A = [3, 8, 9, 7, 6] is [6, 3, 8, 9, 7] (elements are shifted right by one index and 6 is moved to the first place).

The goal is to rotate array A K times; that is, each element of A will be shifted to the right K times.

Write a function:

class Solution { public int[] solution(int[] A, int K); }

that, given an array A consisting of N integers and an integer K, returns the array A rotated K times.

For example, given

A = [3, 8, 9, 7, 6] K = 3

the function should return [9, 7, 6, 3, 8]. Three rotations were made:

[3, 8, 9, 7, 6] -> [6, 3, 8, 9, 7] [6, 3, 8, 9, 7] -> [7, 6, 3, 8, 9] [7, 6, 3, 8, 9] -> [9, 7, 6, 3, 8]

For another example, given

A = [0, 0, 0] K = 1

the function should return [0, 0, 0]

Given

A = [1, 2, 3, 4] K = 4

the function should return [1, 2, 3, 4]

Assume that:

N and K are integers within the range [0..100];

each element of array A is an integer within the range [−1,000..1,000].

In your solution, focus on correctness. The performance of your solution will not be the focus of the assessment.

Solution

Programming language usedJava 21

Time spent on task6 minutes

help

Notes

not defined yet

Task timeline

Beta

help

Code: 14:03:17 UTC, java, final, score: 100

show code in pop-up

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

// you can also use imports, for example:
// import java.util.*;

// you can write to stdout for debugging purposes, e.g.
// System.out.println("this is a debug message");

class Solution {
    public int[] solution(int[] A, int K) {

        // A = [3, 8, 9, 7, 6]
        // K = 2
        // [7, 6] + [3, 8, 9]
        // return [7, 6, 3, 8, 9]

        int len = A.length;
        if (len == 0) return A;

        K = K % len;    // shift 2 == shift 7 == shift 12 == ...

        int[] dap = new int[len];
        for (int i = 0; i < len; i++) {
            dap[i] = A[(len - K + i) % len];
        }

        return dap;
    }
}

play_arrow

check

13:57:25

14:03:17

Away from Codility tab

Analysis summary

The solution obtained perfect score.

Analysis

expand allExample tests

▶

example
first example test

✔

▶

example2
second example test

✔

▶

example3
third example test

✔

expand allCorrectness tests

▶

extreme_empty
empty array

✔

▶

single
one element, 0 <= K <= 5

✔

▶

double
two elements, K <= N

✔

▶

small1
small functional tests, K < N

✔

▶

small2
small functional tests, K >= N

✔

▶

small_random_all_rotations
small random sequence, all rotations, N = 15

✔

▶

medium_random
medium random sequence, N = 100

✔

▶

maximal
maximal N and K

✔

[코딜리티] BinaryGap (+플랫폼에 대한 사용 후기)

snapcoder — Fri, 9 Jan 2026 21:05:29 +0900

문제

1과 1 사이의 갭차이의 큰 값 구하기.

풀이

1일때 시작점인지, 종료점인지 체크해서 gap 계산 + 0일때는 카운팅만

첫 후기

editor는 해커랭크보단 느리고 가독성이 좋지 않습니다.대신 단순히 O/X 로 결과가 아니라, Reporting에 어마어마한 힘을 준 플랫폼이라고 느꼈습니다.

문제 푸는데 걸린 시간은 물론이고,아래 3가지 요소에 대해 평가되는게 다른 플랫폼과는 달랐습니다.

1️⃣ Task Score (과제 점수)

전체 과제(Task)에 대한 최종 점수
Correctness + Performance + 다른 요소들을 종합한 점수
범위: 0 ~ 100%
예: Task Score 60% → 과제 통과는 했지만 완전하지 않음

2️⃣ Correctness (정확도)

제출한 코드가 모든 테스트 케이스에서 올바른 결과를 내는 정도
단순히 “맞는 답을 반환했는지”만 평가
범위: 0 ~ 100%
예: Correctness 60% → 일부 테스트 케이스는 통과했지만, 나머지는 틀림

3️⃣ Performance (성능)

알고리즘의 시간/공간 효율
예: O(N²) 로직이 큰 입력에서 느리면 점수 낮음
Correctness가 100%여도 Performance가 낮으면 Task Score가 100%가 안 됨
이건 BinaryGap처럼 단순 문제에서는 종종 평가 안 됨

추가적으로, 타이핑 과정까지 녹화가 되는건 처음이라 신기했습니다
한영전환 안되어있어서 생긴 오탈자까지 전부 캡쳐됩니다.

~~면접 준비하면서 내 얼굴을 영상 찍어보는 기분이랄까요~~

Tasks Details

easy

1. BinaryGap

Find longest sequence of zeros in binary representation of an integer.

Task Score

100%

Correctness

100%

Performance

Not assessed

Task description

A binary gap within a positive integer N is any maximal sequence of consecutive zeros that is surrounded by ones at both ends in the binary representation of N.

For example, number 9 has binary representation 1001 and contains a binary gap of length 2. The number 529 has binary representation 1000010001 and contains two binary gaps: one of length 4 and one of length 3. The number 20 has binary representation 10100 and contains one binary gap of length 1. The number 15 has binary representation 1111 and has no binary gaps. The number 32 has binary representation 100000 and has no binary gaps.

Write a function:

class Solution { public int solution(int N); }

that, given a positive integer N, returns the length of its longest binary gap. The function should return 0 if N doesn't contain a binary gap.

For example, given N = 1041 the function should return 5, because N has binary representation 10000010001 and so its longest binary gap is of length 5. Given N = 32 the function should return 0, because N has binary representation '100000' and thus no binary gaps.

Write an efficient algorithm for the following assumptions:

N is an integer within the range [1..2,147,483,647].

Solution

Programming language usedJava 21

Time spent on task11 minutes

help

Notes

not defined yet

Task timeline

Beta

help

Code: 11:49:36 UTC, java, final, score: 100

show code in pop-up

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

// you can also use imports, for example:
// import java.util.*;

// you can write to stdout for debugging purposes, e.g.
// System.out.println("this is a debug message");

class Solution {
    public int solution(int N) {
        // Implement your solution here

        String b = Integer.toBinaryString(N);

        int max = 0;
        int cur = 0;
        boolean started = false;

        // 0 1 0 0 1 0 0 0 0 0 0 0 0 0 0 => return 2;
        for(int i=0; i<b.length(); i++){
            char c = b.charAt(i);

            if(c == '1'){       // 1
                // gap end => max check
                if(started){
                    max = Math.max(max, cur);
                }

                // start now ! => init
                started = true;
                cur = 0;
            }
            else if(started){   // 0
                cur++;
            }
        }

        return max;
    }
}

play_arrow

check

11:39:10

11:49:36

Away from Codility tab

Analysis summary

The solution obtained perfect score.

Analysis

expand allExample tests

▶

example1
example test n=1041=10000010001_2

✔

▶

example2
example test n=15=1111_2

✔

▶

example3
example test n=32=100000_2

✔

expand allCorrectness tests

▶

extremes
n=1, n=5=101_2 and n=2147483647=2**31-1

✔

▶

trailing_zeroes
n=6=110_2 and n=328=101001000_2

✔

▶

power_of_2
n=5=101_2, n=16=2**4 and n=1024=2**10

✔

▶

simple1
n=9=1001_2 and n=11=1011_2

✔

▶

simple2
n=19=10011 and n=42=101010_2

✔

▶

simple3
n=1162=10010001010_2 and n=5=101_2

✔

▶

medium1
n=51712=110010100000000_2 and n=20=10100_2

✔

▶

medium2
n=561892=10001001001011100100_2 and n=9=1001_2

✔

▶

medium3
n=66561=10000010000000001_2

✔

▶

large1
n=6291457=11000000000000000000001_2

✔

▶

large2
n=74901729=100011101101110100011100001

✔

▶

large3
n=805306373=110000000000000000000000000101_2

✔

▶

large4
n=1376796946=1010010000100000100000100010010_2

✔

▶

large5
n=1073741825=1000000000000000000000000000001_2

✔

▶

large6
n=1610612737=1100000000000000000000000000001_2

✔

[코딜리티] CodilitySync - GitHub 자동 연동 Chrome 확장프로그램

snapcoder — Fri, 9 Jan 2026 20:12:19 +0900

[코딜리티] CodilitySync - GitHub 자동 연동 Chrome 확장프로그램

코딜리티(Codility)는 공식적으로 GitHub와 직접적인 연동 기능을 제공하지는 않습니다.

즉, 코딜리티 플랫폼 내에서 코딩 테스트를 진행하는 동안 자동으로 코드가 개인 GitHub 리포지토리로 푸시되거나 하는 공식적인 방법은 없습니다.

비공식 연동 방법: Chrome 확장 프로그램 활용

가장 일반적인 비공식 방법은 CodilitySync와 같은 Chrome 웹 스토어 확장 프로그램을 이용하는 것입니다. 이 확장 프로그램은 사용자가 코딜리티에서 문제를 풀고 제출할 때, 그 코드와 문제 설명을 사용자의 GitHub 리포지토리로 자동으로 동기화해 주는 기능을 제공합니다.

https://chromewebstore.google.com/detail/codilitysync/fphhigcdafaenfgknafdhgkjdfafdooo

CodilitySync - Chrome 웹 스토어

Sync Codility submissions to your Github

chromewebstore.google.com

성함 맨 뒤가choi로 끝나는 걸 보니, 한국분께서 만드신건가 싶네요.

잘 활용하겠습니다. 감사합니다.

레파지토리 선택 후 아래 화면 뜨면 성공.

커밋 되는것까지 확인.

[코딜리티] Codility 플랫폼 친해지기 및 연습문제 시작하기

snapcoder — Fri, 9 Jan 2026 19:55:43 +0900

[코딜리티] Codility 플랫폼 친해지기 및 연습문제 시작하기

우선 코딜리티는 외국계 회사의 코딩테스트 플랫폼이다. (처음 알게된 사실..)

문제풀이를 하려면 공식 홈페이지에서는 접속 경로가 잘 안보이고

코딜리티의 연습문제 데모 테스트는 아래 링크에 위치한다.

https://app.codility.com/programmers/

Developer Training | Test Coding Skills Online - Codility

Find longest sequence of zeros in binary representation of an integer.

app.codility.com

우상단 Sign up 눌러주고 회원가입 진행하면 된다.

로그인 후, See all Lessons를 클릭하면
https://app.codility.com/programmers/lessons/

총 17강으로 레슨이 구성되어 있다.
저 주황색 글씨의 "Open reading material (PDF)" 열람용 자료 버튼을 눌러서 pdf를 다운받으면, 코딜리티에서 중요하게 보는 요소를 파악할 수 있다.(고 하는데, 봐보니깐 대학교때 강의자료 느낌인거같다)

그럼 화이팅 해보자 !

아차차
그 전에 github 자동 연동 확장 프로그램은 다음글에서

[Gemini] 제미나이에서 지브리 스타일 이미지 만들기 (막차 탑승)

snapcoder — Wed, 17 Dec 2025 01:20:59 +0900

스튜디오 지브리의 감성을 담은 그림을 인공지능으로 생성하기 위해,

구글의 제미나이(Google Gemini)를 활용해보고자 합니다.

누구나 손쉽게 지브리 스타일의 이미지를 만들 수 있습니다.

스튜디오 지브리 스타일이란?

스튜디오 지브리는 '이웃집 토토로', '센과 치히로의 행방불명' 등으로 유명한 일본의 애니메이션 스튜디오입니다. 그들의 작품은 다음과 같은 특징을 가지고 있습니다:

부드럽고 따뜻한 색감: 파스텔 톤과 자연스러운 색채를 사용합니다.
자연과의 조화: 풍부한 자연 배경과 생명력 있는 풍경을 그립니다.
감성적인 캐릭터 디자인: 큰 눈과 섬세한 표정을 가진 캐릭터들이 등장합니다.
마법과 현실의 융합: 현실적인 세계에 마법적인 요소를 자연스럽게 녹여냅니다.

제미나이로 지브리 스타일 이미지 생성하기

1. 제미나이 접속 및 로그인

웹사이트: gemini.google.com

2. 이미지 생성 요청하기

제미나이는 텍스트 프롬프트를 통해 이미지를 생성합니다. 예를 들어:

"벚꽃이 흩날리는 공원에서 우산을 쓰고 있는 소녀, 지브리 스타일로 그려줘"

이러한 프롬프트를 입력하면 제미나이가 해당하는 이미지를 생성해 줍니다.

3. 이미지 수정 및 재생성

생성된 이미지가 마음에 들지 않으면 다음과 같이 요청할 수 있습니다:

"다른 버전으로 다시 그려줘"
"배경에 큰 벚나무를 추가해줘"
"비가 내리는 분위기로 바꿔줘"

이러한 추가 지시를 통해 원하는 이미지를 얻을 때까지 수정할 수 있습니다.

4. 이미지 저장

마음에 드는 이미지가 생성되면, 이미지 위에서 마우스 오른쪽 버튼을 클릭하여 '다른 이름으로 저장'을 선택하거나, 모바일에서는 이미지를 길게 눌러 저장할 수 있습니다.