cmod.ify

[AI Tool] Claude Code #2 - 토큰, 왜 이렇게 빨리 닳을까? (실전 기준으로 토큰 절약하기)

modifyC — Fri, 27 Mar 2026 12:25:17 +0900

"왜 Claude 쓰면 토큰이 이렇게 빨리 닳지?"

같은 작업인데도
누군가는 10번 쓰고 끝내고,
누군가는 3번 만에 끝냅니다.

차이는 '토큰'이 아니라
AI를 쓰는 방식입니다.

1. 내가 토큰을 얼마나 쓰고 있는지 확인하기

먼저 현재 사용량부터 파악해야 합니다.

웹에서 확인하는 법

Claude Code에서 확인하는 법

세선 안에서 /usage를 치면 됩니다.

2. 토큰이 뭔가요?

AI가 텍스트를 처리하는 최소 단위입니다.

한글 1글자  ≈ 2~3 tokens
영어 단어 1개 ≈ 1 token

그래서 같은 내용을 한글로 쓰면 영어보다 토큰을 2~3배 더 씁니다.

그렇다고 영어로 써야 한다는 뜻은 아닙니다. 이건 뒤에서 자세히 다룰게요.

토큰이 많이 쌓이면 어떻게 될까요? → 컨텍스트가 터집니다.

3. 토큰 문제 vs 컨텍스트 문제 (이 둘은 다릅니다)

많은 분들이 이걸 헷갈려하는데, 사실 완전히 다른 문제입니다.

토큰 = 비용 문제  →  돈이 얼마나 드는가
컨텍스트 = 성능 문제  →  Claude가 얼마나 기억하는가

컨텍스트 윈도우란 Claude가 한 번에 기억할 수 있는 공간입니다 (200k tokens).

대화가 길어질수록 이 공간이 채워지고, 꽉 차면 앞 내용부터 잊어버리기 시작합니다. 그래서 중간에 /compact로 압축해줘야 합니다.

/context로 확인 가능합니다

읽는 법

System prompt:  6.3k   ← Claude Code 기본 지침 (고정값, 매 요청마다 포함됨)
System tools:  19.3k   ← 파일 읽기/쓰기 도구 설명 (고정값)
MCP tools:     31.3k   ← 연결된 MCP 서버 설명 (연결할수록 증가)
Messages:      99.4k   ← 내가 주고받은 대화 전부 (누적됨)
Free space:    10k     ← 남은 공간

여기서 포인트는 Messages 항목.

System 영역은 사실 어쩔 수 없는 고정 비용입니다. 근데 Messages는 대화할수록 계속 쌓입니다. 즉 세션이 길어질수록 같은 질문 하나에 드는 토큰이 점점 커집니다.

/compact Focus on CSS 분리 작업

깃허브에서도 한 이슈를 마치면 close 하듯이, 클로드도 한 이슈가 지나면 압축해줍시다.

안 하면 세션이 강제 종료되거나, Claude가 앞에서 한 작업을 까먹는 상황이 발생합니다.

4. 요금제별 체감 (수치보다 경험 기준)

공식 수치보다 실제 작업 기준으로 보는 게 더 와닿습니다.

작업	대략적인 토큰 소모
CSS 인라인 분리 (파일 3~4개)	약 15k~25k
GitHub PR 생성 + 설명 작성	약 10k~20k
버그 디버깅 (로그 분석 포함)	약 30k~50k
CLAUDE.md 작성 (`/init`)	약 5k~10k

Pro 기준으로 하루 종일 개발 작업하면 체감상 오후쯤 속도 제한이 걸리기 시작합니다. 특히 MCP 연결하면 System 영역만 30k 이상이라 기본 소모가 꽤 큽니다.

하루 작업량이 많다면 Max 요금제가 유리합니다.
Pro는 가볍게 쓸 때, Max는 하루 종일 붙잡고 개발할 때 기준으로 보면 됩니다.
하루 2~3시간 가볍게 쓰면 Pro
하루 종일 개발하면 Max
(개인적 의견입니다)

간단한 이슈 생성 및 add, commit 은 ! 를 작성해서 스스로 작성하여 토큰을 아껴봅시다

5. 토큰보다 중요한 건 결과 타입이다

이게 이 글에서 가장 하고 싶은 말입니다.

토큰을 아끼는 사람 vs 잘 쓰는 사람의 차이

❌ 프롬프트를 잘 쓰는 사람
✅ 결과를 설계하는 사람

영어가 토큰 효율이 좋다는 건 사실입니다. 근데 그게 전부가 아닙니다.

내가 어색한 영어로 의도를 전달하다 생기는 오차 가 토큰 낭비보다 훨씬 큰 비용입니다. 수정 요청, 재질문, 맥락 재설명… 이게 다 토큰이거든요.

그래서 저는 이렇게 생각합니다.

자연어(언어)가 중요한 게 아니라, 결과 타입 정의가 중요하다.

예시 1 - draw.io 다이어그램

Claude한테 "다이어그램 그려줘" 하면 어색한 SVG가 나옵니다.
근데 "이 구조를 draw.io XML 포맷으로 출력해줘" 하면?
→ XML 그대로 복사해서 draw.io에 import하면 깔끔한 다이어그램 완성입니다.

사용 예시

예시 2 - PPT

Claude한테 직접 PPT 만들어달라고 하는 것보다,
"이 내용으로 Genspark용 프롬프트 정의해줘" 하고
→ 그 프롬프트를 Genspark에 붙여넣으면 훨씬 퀄리티 좋은 PPT가 나옵니다.

사용 예시

핵심은 이겁니다.

Claude를 최종 결과물 생성기로 쓰지 말고, 원하는 결과에 맞는 형태로 출력하는 변환기로 쓰는 거임.

그러면 언어가 영어든 한국어든 크게 상관없습니다. 내가 정확하게 의도를 전달할 수 있는 언어로 쓰는 게 결국 더 효율적입니다.

6. 토큰 낭비하는 사람 특징

공감되는 항목이 있다면 고쳐야 할 습관입니다.

- 한 세션에서 모든 작업을 다 하려 함
- 자연어로만 설명하고 결과 형식을 정의 안 함
- /compact 없이 세션을 계속 이어감
- MCP 다 연결해두고 안 씀 (System 토큰만 잡아먹음)
- haiku로 충분한 작업에 sonnet/opus 씀

현재(2026년 3월) 기준 가격은 이렇습니다. MetaCTO

모델	input	output
Haiku 4.5	$1	$5
Sonnet 4.6	$3	$15
Opus 4.6	$5	$25

그래서 배수 계산하면:

Haiku vs Sonnet : 3배 차이
Sonnet vs Opus : 약 1.7배 차이
Haiku vs Opus : 5배 차이

해당 수치는 API 호출 기준이며 Pro 및 Max 구독에 대한 정확한 토큰은 공개되지 않았습니다.

7. 실전 토큰 절약 팁

단순 팁보다 왜 해야 하는지 까지 설명합니다.

방법	이유
`/compact` 80%마다 실행	컨텍스트 유지 + 성능 저하 방지
작업 단위로 세션 분리	맥락 오염 방지. 관계없는 대화가 섞이면 Claude가 혼선을 겪음
haiku로 단순 작업 처리	CSS 분리, 파일 이동 같은 작업은 haiku로 충분. sonnet 대비 비용 차이 큼
`!git` 명령어 직접 실행	`!` 붙이면 셸 명령어 직접 실행. 토큰 0 소모
CLAUDE.md 잘 써두기	매 세션마다 프로젝트 설명 안 해도 됨. 반복 설명 = 토큰 낭비
필요한 MCP만 연결	MCP 하나당 System 토큰 수천~수만 추가됨. 안 쓰는 건 끊어두는 게 이득
결과 타입 명시하기	"JSON으로 출력해줘", "draw.io XML로 줘" → 재질문 없이 한 번에 끝남

정리

토큰을 아끼는 건 결국 AI를 어떻게 쓰느냐의 문제입니다.

언어보다 의도 전달이 중요하고
프롬프트보다 결과 타입 정의가 중요하고
많이 쓰는 것보다 잘 쓰는 게 중요합니다.

다음 글에서는 실제 아키텍쳐 다이어그램을 표현하는 방법을 좀 더 깊게 다뤄볼 예정입니다.

참고: Claude Code 공식 문서 https://code.claude.com/docs

[AI Tool] Claude Code #1 - Claude CLI로 코딩하기 (설치부터 GitHub MCP 연동까지)

modifyC — Fri, 27 Mar 2026 11:19:34 +0900

전문 레퍼런스 문서보다는, 직접 써보면서 겪은 것들을 정리한 실용 가이드입니다.
이미 리포가 생성된 포트폴리오 html(깃블로그)을 기준으로 작성하였습니다.

Claude Code가 뭔가요?

Anthropic이 만든 AI 코딩 도구입니다.

claude.ai 웹이랑 헷갈릴 수 있는데, 결정적인 차이가 있습니다.
가장 중요한 점은 결제가 필요하단 것이겠죠.

claude.ai 웹: 브라우저에서 대화하는 챗봇
Claude Code: 터미널에서 내 프로젝트 폴더에 직접 접근해서 파일 읽고, 수정하고, 커밋까지 해주는 도구

단순히 "코드 짜줘" 수준이 아니라 실제 작업 환경에서 같이 일하는 느낌입니다.
이런 도구를 AI 에이전트 하네스라고 부르는데, AI가 도구(파일 시스템, 터미널, Git 등)를 직접 다룰 수 있도록 연결해주는 실행 환경을 의미합니다.

설치 방법 2가지

(이 글은CLI 설치 기준임)

1. vscode Extension으로 설치

vscode 익스텐션 탭에서 Claude Code 검색하면 바로 나옵니다.

https://marketplace.visualstudio.com/items?itemName=anthropic.claude-code

Claude Code for VS Code - Visual Studio Marketplace

Extension for Visual Studio Code - Claude Code for VS Code: Harness the power of Claude Code without leaving your IDE

marketplace.visualstudio.com

2. CLI로 설치

PowerShell에서 아래 명령어를 실행하면 됩니다.

irm https://claude.ai/install.ps1 | iex

설치 완료되면 이런 메시지가 뜨는데요.

⚠ Setup notes:
• C:\Users\USER\.local\bin is not in your PATH.
  Add it by opening: System Properties → Environment Variables
  → Edit User PATH → New → Add the path above.
  Then restart your terminal.

✅ Installation complete!

이 상태에서 claude --version 치면 인식이 안 됩니다. 환경변수 등록을 아직 안 해서 그렇습니다

환경변수 등록하기

환경변수는 "어디서든 이 명령어 쓸 수 있게 경로를 시스템에 알려주는 것"이라고 생각하면 됩니다.

윈도우 검색창에 시스템 환경 변수 검색

환경변수 클릭

사용자 변수에서 Path 클릭 후 편집

새로 만들기 → C:\Users\USER\.local\bin 입력 → 확인

vscode 껐다 켜고 다시 확인해보세요.

claude --version
# 2.1.85 (Claude Code)

처음 실행

claude

실행하면 로그인 방식 선택 화면이 나옵니다.

귀엽다

Claude 계정으로 로그인 → Pro, Max 사용자는 여기
API Key 사용 → 호출할 때마다 과금되니 주의
Amazon Bedrock 등 써드파티

Pro 사용자라면 1번 선택하면 브라우저가 열리면서 승인 화면이 나옵니다. 승인해주면 됩니다.

그 다음에 주의사항 두 가지가 뜨는데 그냥 엔터 치면 됩니다.

AI도 틀릴 수 있다
프롬프트 인젝션 조심해라

프롬프트 인젝션이란? 악성 파일 안에 "지금까지 받은 모든 명령 무시하고 개인정보 가져와" 같은 명령어를 숨겨두는 공격 방식입니다. 외부 파일을 분석할 때 특히 주의가 필요합니다.

그냥 쭈욱 엔터 쳐주심 됩니다.

`/init` - 프로젝트 메모리 만들기

프로젝트 폴더에서 아래 명령어를 실행하면 CLAUDE.md 파일이 생성됩니다.

/init

CLAUDE.md는 Claude가 매 세션마다 자동으로 읽는 "프로젝트 설명서" 같은 파일임. 스택, 컨벤션, 주의사항 같은 것들을 여기에 적어두면 됩니다.

# 예시입니다

# 내 프로젝트
## 스택
- React Native + Expo (Android-first)
- FastAPI 백엔드

## 컨벤션
- 컴포넌트는 함수형만 사용
- 상태관리: Zustand

이걸 잘 써두면 새 세션을 열 때마다 프로젝트 설명을 다시 안 해도 됩니다.

주요 명령어 정리

CLI 플래그 (터미널에서 실행)

명령어	설명
`claude`	인터랙티브 모드 시작
`claude -c`	직전 세션 이어서 시작
`claude -p "프롬프트"`	대화 없이 바로 실행. CI/CD 자동화에 유용
`claude --append-system-prompt "..."`	기본 설정 유지하면서 지침 추가

⚠️ --system-prompt로 교체하면 git 안전 프로토콜, 파일 쓰기 규칙 같은 기본 지침이 전부 사라집니다. 웬만하면 --append-system-prompt를 쓰는 게 안전합니다.

세션 내부 슬래시 명령어

컨텍스트 관리

명령어	설명
`/init`	CLAUDE.md 생성
`/context`	현재 컨텍스트 사용량 확인
`/compact`	컨텍스트 압축. 80% 넘으면 꼭 실행
`/clear`	컨텍스트 초기화
`/fork`	현 시점 기준 대화 분기. git 브랜치처럼 실험 후 복귀 가능

세션 관리

명령어	설명
`/rename`	세션에 이름 붙이기
`/resume`	저장된 세션 불러오기
`/stats`	토큰 사용량 확인
`/model`	모델 전환

작업 흐름

명령어	설명
`/plan`	코드 수정 전에 읽기 전용으로 분석 먼저. 강추
`/help`	전체 명령어 목록

인터랙티브 모드 단축키

단축키	설명
`@파일경로`	특정 파일 직접 참조. 예: `@src/auth.ts 리뷰해줘`
`!명령어`	셸 명령어 바로 실행. 예: `!git status`
`Esc + Esc`	코드/대화 롤백 메뉴

모델 선택

/model haiku    # 빠르고 저렴. 단순 작업용
/model sonnet   # 기본 모델. 대부분 이걸로 충분
/model opus     # 복잡한 문제용. 토큰 소모가 크니 아껴서 쓸 것

CSS 분리 같은 단순 작업은 haiku로도 충분합니다. 굳이 sonnet까지 쓸 필요 없음.

컨텍스트란?

Claude가 현재 세션에서 기억할 수 있는 공간입니다.

메모장 한 장(200k tokens) 이라고 생각하면 됩니다. 대화할수록 채워지고, 꽉 차면 앞 내용부터 잊어버리기 시작합니다.

/context 를 실행하면 이런 화면이 나옵니다.

System prompt:  6.3k   ← Claude Code 기본 지침
System tools:  19.3k   ← 파일 읽기/쓰기 도구 설명
MCP tools:     31.3k   ← 연결된 MCP 서버 설명
Messages:      99.4k   ← 주고받은 대화 전부
Free space:    10k     ← 남은 공간

80% 넘으면 /compact로 압축해줘야 합니다. 안 하면 세션이 강제 종료될 수 있음.

/compact Focus on CSS 분리 작업

키워드를 넘기면 그 내용 위주로 압축해줍니다.

파일 수정/생성 권한 설정

Claude Code는 파일을 건드리기 전에 기본적으로 허락을 구합니다. 근데 액션 종류별로 따로 물어봄.

파일 수정 권한 → 따로
파일 생성 권한 → 따로

매번 확인받기 귀찮다면 세션 안에서 이렇게 말하면 됩니다.

새 파일 생성도 매번 확인 안 받아도 되게 권한 추가해줘

그러면 settings.json에 자동으로 권한이 추가됩니다.

-p 플래그로 자동화할 때는 이렇게 쓸 수 있습니다.

claude -p "인라인 css를 별도의 파일로 분리해줘." --dangerously-skip-permissions

이름이 좀 무섭게 생겼는데, 로컬 작업에서는 그냥 "확인 없이 바로 실행해"라는 의미입니다.

Git 연동

자연어로 그냥 말해도 됩니다.

"변경사항 커밋해줘"
"커밋 메시지 추천해줘"
"어떤 파일 변경됐는지 보여줘"
"현재 브랜치 알려줘"

직접 명령어를 치고 싶을 때는 ! 붙이면 셸 명령어가 바로 실행됩니다. 이 방식은 토큰을 소모하지 않습니다.

!git add .
!git status
!git log --oneline -5

GitHub MCP 연동

MCP는 Claude Code에 외부 서비스를 연결해주는 프로토콜입니다. GitHub MCP를 연결하면 PR 생성, 이슈 확인 같은 작업을 Claude가 직접 처리할 수 있습니다.

1단계: GitHub PAT 발급

GitHub → Settings → Developer settings → Personal access tokens → Tokens (classic) → Generate new token

권한 설정은 아래처럼 해주세요.

Repository access: All repositories
Permissions:
- Contents: Read and write
- Pull requests: Read and write
- Issues: Read-only
- Metadata: Read-only (필수)

⚠️ 발급된 토큰은 창을 닫으면 다시 볼 수 없습니다. 반드시 어딘가 저장해두세요.

2단계: MCP 등록

Claude Code 세션 밖 터미널에서 실행해주세요.

$pat = "여기에_발급받은_토큰"
claude mcp add github --scope user --transport http https://api.githubcopilot.com/mcp/ -H "Authorization: Bearer $pat"

--scope user 옵션을 붙이면 모든 프로젝트에서 사용할 수 있습니다.

3단계: 확인

MCP 설정 변경 후에는 Claude Code를 껐다 켜야 반영됩니다. 세션을 유지하고 싶다면 먼저 /rename으로 이름을 붙여두고, 재시작 후 /resume으로 불러오면 됩니다.

사용 예시

Claude Code 재시작 후 세션 안에서 확인합니다.

/mcp

github가 목록에 뜨면 성공입니다.

"현재 변경사항으로 PR 만들어줘. 제목은 'feat: CSS 인라인 스타일 분리'"
"열린 이슈 목록 보여줘"
"PR 검토하고 main에 머지해줘"

이슈와 pr 까지 생성된 모습

그냥 바로 스스로 검토하고 머지하라고 해봅시다

PAT 설정을 하나 더 추가해야하는데 그냥 클로드가 사용 방법을 알려줬으니 따라 치겠습니다

정리

상황	해결책
단순 파일 수정/분리	haiku 모델 사용
버그 디버깅, 기능 구현	sonnet 모델 사용
컨텍스트 80% 초과	`/compact` 실행
새 작업 시작	`/clear` 또는 새 세션
GitHub PR 자동화	GitHub MCP 연결
자동화 스크립트	`claude -p "..." --dangerously-skip-permissions`

다음 글에서는 토큰 아끼는 법을 다룰 예정입니다. 쓰다 보면 생각보다 금방 닳아서, 나름대로 고찰한 것들을 정리해볼게요.

참고: Claude Code 공식 문서 https://code.claude.com/docs

[Optimization] Wattup #5 K8s 클러스터 메모리 최적화

modifyC — Thu, 12 Mar 2026 11:25:36 +0900

[Optimization] Wattup #5 K8s 클러스터 메모리 최적화 — 95% → 76%

OPTIMIZATION GUIDE

WattUp K8s 메모리 최적화

Kafka 단일화 · JVM 힙 제한 · 리소스 튜닝 · 95% → 76%

최적화 흐름 요약

단계	작업	메모리 변화
1Kafka 3→1	KRaft 3-node → 단일 노드로 축소	95% → 83%
2Worker 축소 시도	worker3 제거 시도 → PVC 분산으로 포기	변화 없음
3리소스 limits 설정	backend / importer livenessProbe + resources 추가	83% → 84% (역효과)
4JVM 힙 제한	Kafka HEAP_OPTS, PostgreSQL shared_buffers 제한	84% → 76%

메모리 사용량 변화

최적화 전 — 95%

95%

Kafka 단일화 후 — 83%

83%

리소스 limits 추가 후 — 84% (소폭 증가)

84%

JVM 힙 제한 후 — 76% ✅

76%

최적화 1 — Kafka 3-node → 1-node

Kafka 단일 노드로 축소 (03-kafka.yaml)

개발/테스트 환경에서 Kafka 3-node KRaft 클러스터는 리소스 낭비가 크다. 단일 노드로 줄이면 broker+controller를 겸임할 수 있어 구조가 오히려 단순해진다.

yaml — 03-kafka.yaml : StatefulSet replicas

# 찾아서
replicas: 3
# 이렇게
replicas: 1

yaml — QUORUM_VOTERS 단일 노드로 변경

# 찾아서 (3개 나열된 부분)
1@kafka-0.kafka-headless.ev-prod.svc.cluster.local:9093,2@kafka-1...:9093,3@kafka-2...:9093
# 이렇게 (kafka-0만 남기기)
1@kafka-0.kafka-headless.ev-prod.svc.cluster.local:9093

yaml — 04-debezium.yaml, 05-apps.yaml : BOOTSTRAP_SERVERS

# 찾아서
kafka-0...9092,kafka-1...9092,kafka-2...9092
# 이렇게
kafka-0.kafka-headless.ev-prod.svc.cluster.local:9092

bash — 기존 Kafka PVC까지 완전히 제거 후 재배포

# 설정 데이터가 남아있으면 충돌하므로 PVC까지 반드시 삭제
kubectl delete statefulset kafka -n ev-prod
kubectl delete pvc -l app=kafka -n ev-prod

# 재배포
kubectl apply -f 03-kafka.yaml
kubectl wait --for=condition=Ready pod -l app=kafka -n ev-prod --timeout=120s

# Debezium, apps 재배포
kubectl apply -f 04-debezium.yaml
kubectl apply -f 05-apps.yaml

# 확인 — kafka-0 1/1 Running 이면 성공
kubectl get pods -n ev-prod

✅ RESULT

메모리 사용량 95% → 83% 감소. Kafka 3개 프로세스가 차지하던 JVM 힙이 사라지면서 12% 확보.

최적화 2 — Worker 노드 축소 시도 (실패)

worker3 제거 시도 → PVC 분산으로 포기

VM 1대를 줄이면 호스트 머신 메모리도 직접 확보할 수 있다. 하지만 PVC는 노드에 묶여있어서 PVC가 있는 노드는 절대 제거할 수 없다.

bash — 어느 노드에 PVC pod이 있는지 먼저 확인

kubectl get nodes
kubectl get pods -n ev-prod -o wide
kubectl get pvc -n ev-prod -o wide

트러블슈팅 — Worker 제거 불가 (PVC 분산 문제)

문제

PVC를 가진 pod(postgres, mongo, kafka)가 worker1, worker2, worker3에 각각 흩어져 있었다. 어느 노드도 안전하게 지울 수 없는 상태.

원인

local-path-provisioner의 PV는 특정 노드에 고정(node affinity)된다. pod 분포 결과 — postgres: worker1, debezium: worker2, kafka+mongo+nginx: worker3. 모든 노드에 PVC 관련 pod이 분산.

결론

worker 노드 축소는 이번 구조에선 불가. 처음부터 StatefulSet pod을 특정 노드에 몰아두는 nodeSelector 설계가 필요하다.

교훈

local-path PVC를 사용하면 pod이 어느 노드에 스케줄되느냐에 따라 PV 위치가 결정된다. 나중에 노드를 줄일 계획이 있다면 처음부터 nodeSelector나 nodeName으로 StatefulSet의 위치를 고정해야 한다.

결과

포기. 메모리 변화 없음. 하지만 local-path PVC + nodeSelector 설계라는 중요한 교훈을 얻었다.

최적화 3 — 리소스 limits + livenessProbe (역효과)

backend / importer resources 설정 → 오히려 증가

리소스 낭비를 막고 가용성도 높이기 위해 livenessProbe와 resources를 함께 추가했다.

yaml — 05-apps.yaml : backend

livenessProbe:
  httpGet:
    path: /health
    port: 8000
  initialDelaySeconds: 20
  periodSeconds: 20
  timeoutSeconds: 3
  failureThreshold: 3
resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"
    cpu: "500m"

yaml — 05-apps.yaml : importer (백엔드보다 가볍게)

livenessProbe:
  httpGet:
    path: /health
    port: 8000
  initialDelaySeconds: 20
  periodSeconds: 20
  timeoutSeconds: 3
  failureThreshold: 3
resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "256Mi"
    cpu: "250m"

트러블슈팅 — resources 설정이 오히려 메모리를 늘린 이유

문제

83% → 84%로 오히려 소폭 증가했다.

원인

resources.requests는 실제 사용량이 아니라 K8s 스케줄러가 미리 예약(reserve)하는 값이다. 실제 프로세스가 그만큼 쓰지 않아도, 노드 입장에서는 해당 메모리가 "사용 중"으로 잡힌다. 즉, requests를 잡는 순간 K8s가 그 양을 미리 점유해버린다.

시도

limits를 더 타이트하게 잡아보거나 requests 값을 실제 사용량에 맞게 내려야 함. 하지만 이 환경에서 실질적인 효과는 다음 단계(JVM 힙 제한)에서 나왔다.

교훈

requests는 예약이고 limits는 상한선이다. 메모리를 실제로 줄이려면 애플리케이션이 쓰는 양 자체를 줄여야 한다. requests만 높게 잡으면 실제 사용량과 무관하게 노드 메모리가 꽉 찬 것처럼 보인다.

결과

메모리 83% → 84%. 역효과. livenessProbe는 가용성 측면에선 유효하지만, 메모리 최적화 수단으로는 requests/limits 설정 자체가 아닌 실제 사용량 감소가 핵심임을 확인.

최적화 4 — JVM 힙 제한 (핵심)

Kafka HEAP_OPTS + PostgreSQL shared_buffers 제한

JVM 기반 프로세스(Kafka)와 메모리 공격적인 프로세스(PostgreSQL)는 제한을 안 걸면 가용 메모리를 최대한 먹으려 한다. 명시적으로 상한을 지정하면 실제 사용량이 바로 줄어든다.

yaml — 03-kafka.yaml : Kafka 컨테이너 env에 추가

- name: KAFKA_HEAP_OPTS
  value: "-Xmx512m -Xms512m"

yaml — 02-databases.yaml : PostgreSQL env에 추가

- name: POSTGRES_SHARED_BUFFERS
  value: "128MB"

bash — 재배포

# Kafka는 PVC까지 지워야 힙 설정이 제대로 적용됨
kubectl delete statefulset kafka -n ev-prod
kubectl delete pvc -l app=kafka -n ev-prod
kubectl apply -f 03-kafka.yaml

# PostgreSQL은 PVC 유지하고 재시작
kubectl rollout restart statefulset/postgres -n ev-prod

# 확인
kubectl get pods -n ev-prod
kubectl top nodes  # metrics-server 있으면 메모리 확인 가능

트러블슈팅 — JVM이 기본적으로 메모리를 과하게 잡는 이유

원인

JVM은 기본적으로 시스템 메모리의 1/4을 최대 힙(-Xmx)으로 자동 설정한다. 8GB RAM 노드라면 Kafka 인스턴스 하나가 2GB를 잡아먹는다. 컨테이너 환경에서 limits.memory가 없으면 노드 전체 RAM을 기준으로 계산해버린다.

해결

KAFKA_HEAP_OPTS="-Xmx512m -Xms512m"으로 개발 환경에서는 512MB로 고정. PostgreSQL도 shared_buffers를 명시적으로 제한.

교훈

K8s의 limits.memory는 OOM killer를 위한 상한이고, JVM의 -Xmx는 힙 자체의 크기다. 두 개는 별개로 동작한다. JVM 프로세스를 컨테이너에 올릴 때는 반드시 HEAP_OPTS와 limits.memory를 함께 설정해야 한다.

✅ RESULT

메모리 사용량 84% → 76%. JVM 힙 제한이 가장 직접적이고 효과적인 메모리 최적화 수단임을 확인.

최종 정리 — 교훈 모음

최적화 항목	핵심 교훈	효과
Kafka 3→1	개발 환경에서 3-node KRaft는 과잉. 단일 노드로 충분.	-12%
Worker 축소 시도	local-path PVC는 노드에 고정됨. 처음 설계 시 nodeSelector 필수.	0%
resources limits	requests는 예약이라 오히려 메모리가 늘어 보임. 실제 사용량 감소가 핵심.	+1% (역효과)
JVM 힙 제한	JVM은 자동으로 RAM의 1/4을 힙으로 잡음. HEAP_OPTS 명시 필수.	-8%

전체 메모리 절감 결과
최적화 전 95% → 최적화 후 76%. 약 19% 감소. VM 4대(master+worker3) 기준 총 32GB RAM 중 약 6GB 확보.

[Technical Review] Wattup #4 VirtualBox 기반 K8s 클러스터 구축과 트러블슈팅

modifyC — Wed, 11 Mar 2026 00:35:32 +0900

WattUp K8s 배포 가이드

DEPLOYMENT GUIDE

WattUp K8s 배포 전과정

VirtualBox · kubeadm · Calico · 트러블슈팅 포함

전체 배포 흐름

단계	내용
1VM 생성	VirtualBox VM 4개 생성 (master + worker 3)
2기본 설정	hostname, /etc/hosts, swap 비활성화, 커널 모듈
3containerd	컨테이너 런타임 설치
4K8s 바이너리	kubeadm / kubelet / kubectl 설치
5클러스터 생성	kubeadm init (master)
6worker join	worker 노드 3대 클러스터 합류
7CNI 설치	Calico 네트워크 플러그인
8StorageClass	local-path-provisioner (PVC용)
9포트포워딩	VirtualBox NAT 포트포워딩 설정
10이미지 빌드	Debezium 커스텀 이미지 빌드 & 푸시
11yaml 수정	ConfigMap, Secret 세팅
12배포	순서대로 kubectl apply
13접속 확인	curl / 브라우저로 서비스 확인

접근 구조

OCI (Frontend: React + Docker) ↓ Tailscale VPN nginx (NodePort 30007) ← 유일한 외부 진입점 ↓ backend-svc ← ClusterIP (내부 전용) ↓ postgres / mongo / kafka ← ClusterIP (내부 전용) ↑ ↓ debezium kafka (CDC 캡처) ↓ mongo ← 싱크

VM 환경 구성

VirtualBox VM 생성

역할	hostname	IP
master	master	192.168.56.10
worker1	worker1	192.168.56.11
worker2	worker2	192.168.56.12
worker3	worker3	192.168.56.13

항목	값
OS	Ubuntu 24.04
CPU	2 core
RAM	8GB
Disk	50GB

네트워크 어댑터는 어댑터1: NAT (인터넷), 어댑터2: Host-Only (VM간 통신) 두 개로 설정한다.

netplan — 고정 IP 설정 (각 VM)

# /etc/netplan/00-installer-config.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      dhcp4: true
    enp0s8:
      dhcp4: false
      addresses:
        - 192.168.56.10/24  # 각 VM에 맞게 변경

bash

sudo netplan apply

모든 VM 기본 설정 (master + worker 전부)

bash — hostname 설정

# 각 VM에서 자신의 역할에 맞게
sudo hostnamectl set-hostname master   # master에서
sudo hostnamectl set-hostname worker1  # worker1에서

bash — /etc/hosts, swap 비활성화, 커널 모듈

# /etc/hosts에 추가
192.168.56.10 master
192.168.56.11 worker1
192.168.56.12 worker2
192.168.56.13 worker3

# swap 비활성화
sudo swapoff -a
sudo sed -i '/ swap / s/^/#/' /etc/fstab

# 커널 모듈
sudo modprobe overlay
sudo modprobe br_netfilter

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF

sudo sysctl --system

containerd 설치 (모든 VM)

bash

sudo apt update
sudo apt install -y containerd

sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml

# systemd cgroup 활성화 (필수!)
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml

sudo systemctl restart containerd
sudo systemctl enable containerd

# 확인
sudo systemctl status containerd   # active (running) 이어야 함

kubeadm / kubelet / kubectl 설치 (모든 VM)

bash

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

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

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

sudo apt update
sudo apt install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

클러스터 생성 (master에서만)

bash

sudo kubeadm init \
  --apiserver-advertise-address=192.168.56.10 \
  --pod-network-cidr=192.168.0.0/16

# kubeconfig 설정
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

# 확인 (CNI 설치 전이라 NotReady가 정상)
kubectl get nodes

⚠️ 주의완료 후 출력되는 kubeadm join ... 명령어를 반드시 복사해두세요. worker join에 필요합니다. 잃어버렸다면 master에서 kubeadm token create --print-join-command로 재발급 가능합니다.

worker 노드 join

bash — worker1, worker2, worker3에서 각각 실행

sudo kubeadm join 192.168.56.10:6443 \
  --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash>

bash — master에서 확인

kubectl get nodes # 4개 노드가 보이면 성공

CNI 설치 — Calico (master에서)

bash

kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

# 모두 Ready 될 때까지 대기
kubectl get nodes -w

StorageClass 설치 (master에서)

PVC(PersistentVolumeClaim)를 자동으로 처리하기 위해 local-path-provisioner를 설치하고 기본 StorageClass로 지정한다.

bash

kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml

kubectl patch storageclass local-path \
  -p '{"metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

# 확인 — local-path (default) 표시되면 성공
kubectl get storageclass

VirtualBox 포트포워딩 설정

호스트 PC에서 K8s 서비스에 접근하기 위한 포트포워딩. VirtualBox → master VM → 설정 → 네트워크 → 어댑터1(NAT) → 고급 → 포트 포워딩에서 설정.

이름	호스트 포트	게스트 포트	용도
nginx	50007	30007	유일한 외부 진입점

Debezium 이미지 빌드 & 푸시 (호스트 PC)

PostgreSQL CDC 커넥터 플러그인이 포함된 커스텀 Debezium 이미지를 빌드해서 Docker Hub에 푸시한다.

bash

mkdir debezium && cd debezium
docker build -t agn705/wattup-debezium:v1.0 .
docker push agn705/wattup-debezium:v1.0

yaml 파일 수정

01-configmap.yaml에 schema.sql과 nginx.conf 내용을 붙여넣고, Secret은 별도로 생성한다.

파일 구조 k8s-prod/ ├── 00-namespace.yaml — Namespace ├── 01-configmap.yaml — schema.sql, nginx.conf ├── 02-databases.yaml — PostgreSQL, MongoDB ├── 03-kafka.yaml — Kafka 3-node KRaft ├── 04-debezium.yaml — Debezium CDC ├── 05-apps.yaml — importer, backend └── 06-nginx.yaml — Nginx (외부 진입점)

환경변수 처리 기준

변수	처리 방식
POSTGRES_PASSWORD	Secret (kubectl create)
MONGO_INITDB_ROOT_PASSWORD	Secret (kubectl create)
DATA_GO_KR_SERVICE_KEY	Secret (kubectl create)
KAFKA_BOOTSTRAP_SERVERS	yaml 하드코딩 (내부 FQDN)
GROUP_ID / *_TOPIC	yaml 하드코딩 (고정값)

배포

배포 순서

bash — yaml 파일 master VM으로 복사

scp -r ./k8s-prod ubuntu@192.168.56.10:~/

bash — Secret 생성 후 순서대로 배포

# Namespace 먼저
kubectl apply -f k8s-prod/00-namespace.yaml

# Secret 생성
kubectl create secret generic ev-secret \
  --from-literal=POSTGRES_USER=... \
  --from-literal=POSTGRES_PASSWORD=... \
  --from-literal=POSTGRES_DB=... \
  --from-literal=MONGO_INITDB_ROOT_USERNAME=... \
  --from-literal=MONGO_INITDB_ROOT_PASSWORD=... \
  --from-literal=DATA_GO_KR_SERVICE_KEY=... \
  -n ev-prod

# 순서대로 배포
kubectl apply -f k8s-prod/01-configmap.yaml
kubectl apply -f k8s-prod/02-databases.yaml
kubectl apply -f k8s-prod/03-kafka.yaml

# Kafka Ready 대기 (중요!)
kubectl wait --for=condition=Ready pod -l app=kafka -n ev-prod --timeout=180s

kubectl apply -f k8s-prod/04-debezium.yaml
kubectl apply -f k8s-prod/05-apps.yaml
kubectl apply -f k8s-prod/06-nginx.yaml

bash — 상태 확인

kubectl get pods -n ev-prod
kubectl get svc -n ev-prod
kubectl get pvc -n ev-prod

트러블슈팅 1 — Secret .env 파일 오류

문제

.env 파일 형식 오류로 Secret 생성 실패.

해결

파일 대신 --from-literal로 항목을 직접 넣어서 생성하면 형식 오류가 없다.

트러블슈팅 2 — PostgreSQL command 무시 문제

문제

02-databases.yaml에서 command 필드가 씹혀서 DB가 제대로 초기화되지 않았다.

원인

PostgreSQL 공식 이미지는 command가 아니라 args로 인자를 받는다.

해결

command → args로 변경 후, PVC까지 삭제하고 재배포 (PVC를 안 지우면 빈 폴더가 남아서 같은 오류 반복).

bash

kubectl delete -f 02-databases.yaml
kubectl delete pvc --all -n ev-prod   # 꼭!
kubectl apply -f 02-databases.yaml

트러블슈팅 3 — PostgreSQL CrashLoopBackOff (권한 오류)

문제

chmod: changing permissions of '/var/lib/postgresql/data': Operation not permitted 에러로 postgres-0가 계속 죽었다.

원인

local-path-provisioner가 PVC 디렉토리를 root 소유로 생성하는데, runAsUser: 999 설정을 같이 넣으면 오히려 권한이 없어진다.

해결

securityContext에서 runAsUser, runAsGroup을 제거하고 fsGroup: 999만 남긴다. K8s가 볼륨 소유권을 fsGroup으로 자동 처리해준다.

yaml — 수정 후

securityContext:
  fsGroup: 999    # runAsUser, runAsGroup 제거

트러블슈팅 4 — Kafka 데드락 (KRaft 쿼럼 실패)

문제

kafka-0 혼자 먼저 떠서 쿼럼을 못 맞춰 계속 죽는 데드락 상태.

원인

3-node KRaft는 과반수 노드가 동시에 떠야 리더 선출이 가능한데, StatefulSet 기본 정책이 순차 실행이라 0번이 먼저 뜨고 1, 2번을 기다리게 된다. 이때 0번 혼자서는 쿼럼 불가.

해결

headless Service에 publishNotReadyAddresses: true, StatefulSet에 podManagementPolicy: Parallel 추가해서 3개 동시에 뜨도록 변경.

yaml

# kafka-headless Service
spec:
  publishNotReadyAddresses: true

# Kafka StatefulSet
spec:
  podManagementPolicy: Parallel

트러블슈팅 5 — Kafka init container (busybox) 문제

문제

busybox init container가 node.env 파일을 emptyDir에 써두고 메인 컨테이너로 넘겨주는 구조였는데, 파일 공유가 제대로 안 돼서 Kafka가 node ID를 못 읽었다.

해결

init container 통째로 제거. 메인 컨테이너에서 HOSTNAME을 보고 직접 node ID를 계산하도록 변경. 구조도 단순해지고 부팅 속도도 빨라졌다.

yaml — 수정 후 command

command:
  - sh
  - -c
  - |
    ORDINAL=${HOSTNAME##*-}
    export KAFKA_NODE_ID=$((ORDINAL + 1))
    export KAFKA_ADVERTISED_LISTENERS="PLAINTEXT://${HOSTNAME}.kafka-headless.ev-prod.svc.cluster.local:9092"
    exec /etc/kafka/docker/run

트러블슈팅 6 — MongoDB readinessProbe timeout

문제

MongoDB Pod이 계속 Not Ready 상태. readinessProbe가 통과를 못 했다.

원인

readinessProbe timeout 기본값이 1초인데, mongosh 실행이 1초 안에 끝나지 않아서 계속 실패 처리됐다.

해결

timeoutSeconds: 5 추가.

yaml

readinessProbe:
  exec:
    command: ["mongosh", "--eval", "db.adminCommand('ping')"]
  initialDelaySeconds: 15
  periodSeconds: 10
  failureThreshold: 10
  timeoutSeconds: 5     # 이거 추가

트러블슈팅 7 — importer CrashLoopBackOff (KeyError)

문제

importer가 KeyError: 'DATABASE_DSN'으로 바로 죽었다.

원인

코드가 요구하는 환경변수 키 이름과 yaml에 넣어준 키 이름이 달랐다.

해결

05-apps.yaml importer env에 DATABASE_DSN 추가.

yaml

- name: DATABASE_DSN
  value: "postgresql://$(POSTGRES_USER):$(POSTGRES_PASSWORD)@postgres-svc:5432/$(POSTGRES_DB)"

트러블슈팅 8 — backend CrashLoopBackOff (pydantic ValidationError)

문제

backend가 pydantic_settings ValidationError로 죽었다. POSTGRES_URL, MONGO_URL, MONGO_DB가 없다고 했다.

원인

config.py가 요구하는 키 이름과 yaml env에 넣어준 키 이름이 달랐다.

해결

backend env에 코드가 실제로 요구하는 키로 추가.

yaml

- name: POSTGRES_URL
  value: "postgresql://$(POSTGRES_USER):$(POSTGRES_PASSWORD)@postgres-svc:5432/$(POSTGRES_DB)"
- name: MONGO_URL
  value: "mongodb://$(MONGO_INITDB_ROOT_USERNAME):$(MONGO_INITDB_ROOT_PASSWORD)@mongo-svc:27017"
- name: MONGO_DB
  value: "root"

트러블슈팅 9 — nginx readinessProbe 404

문제

nginx Pod이 계속 Not Ready. GET /에 404를 반환했다.

원인

readinessProbe가 /로 요청하는데 nginx.conf에 / 경로 처리가 없었다.

해결

readinessProbe path를 /health로 변경하고, nginx.conf에 /api/와 /health location을 추가.

nginx.conf

location /api/ {
  proxy_pass http://backend;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
}
location /health {
  proxy_pass http://backend;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
}

접속 확인 & 데이터 적재

주소	확인 내용
http://localhost:50007	메인 서비스
http://localhost:50007/api/docs	backend API 문서

bash — 공공 데이터 적재 (importer)

# importer에 port-forward로 임시 접근
kubectl port-forward --address 0.0.0.0 svc/importer-svc -n ev-prod 8081:8000

# 서울 충전소 데이터 수집 (호스트 PC에서)
curl -X POST "http://192.168.56.10:8081/import/seoul?confirm=true"
# → {"items_fetched":71800,"stations_upserted":12706,...}

bash — 서비스 확인

curl http://localhost:50007/api/wattup/map/강남구
# → {"regionName":"강남구","stations":[...]}

내부 서비스 임시 접근 kubectl port-forward svc/kafka-ui-svc 8080:8080 -n ev-prod kubectl port-forward svc/debezium-svc 8083:8083 -n ev-prod

유용한 명령어 모음

bash — 상태 확인

kubectl get pods -n ev-prod
kubectl logs <pod명> -n ev-prod
kubectl describe pod <pod명> -n ev-prod

bash — 재시작

kubectl rollout restart deployment <서비스명> -n ev-prod

bash — 전부 날리고 재배포

kubectl delete statefulset --all -n ev-prod
kubectl delete deployment --all -n ev-prod
kubectl delete pvc --all -n ev-prod
kubectl apply -f k8s-prod/

bash — 무중단 배포

kubectl apply -f k8s-prod/05-apps.yaml
kubectl rollout restart deployment/backend -n ev-prod

[ARCHITECTURE] Wattup #3 OCI/VirtualBox-K8s | 하이브리드 네트워크 설계

modifyC — Wed, 11 Mar 2026 00:23:36 +0900

WattUp — Network Architecture

NETWORK ARCHITECTURE

WattUp Infrastructure

OCI · Tailscale VPN · Kubernetes (VirtualBox) · Calico CNI

Architecture Diagram

트래픽 흐름

사용자 요청 경로

사용자

HTTPS

☁

OCI Frontend

:80 Docker

Tailscale VPN

암호화 터널

Nginx

NodePort :30007

⚙

Backend

FastAPI / ClusterIP

설계 포인트 외부로 노출되는 진입점은 Nginx NodePort 하나(30007)만 사용한다. PostgreSQL, MongoDB, Kafka, Debezium, Importer는 전부 ClusterIP로 내부 통신만 허용. OCI ↔ K8s 클러스터 간 통신은 Tailscale VPN으로 암호화.

구성 요소 상세

☁

Oracle Cloud (OCI)

무료 티어 · 프론트엔드 전용

React + Nginx를 Docker 컨테이너로 실행. VirtualBox K8s 클러스터와 분리 운영. Tailscale을 통해 백엔드와 통신.

ReactNginxPodman

Tailscale VPN

WireGuard 기반 암호화 터널

OCI 프론트엔드 ↔ VirtualBox K8s 클러스터 간 사설 네트워크 구성. 공인 IP 없이도 안전하게 내부 서비스에 접근 가능.

WireGuardZero-config

☸

Kubernetes Cluster

VirtualBox · kubeadm · Calico CNI

마스터 1대 + 워커 3대 구성. Calico CNI로 파드 간 네트워크 관리. local-path-provisioner로 PVC 처리.

master:56.10worker1~3Calico

Nginx (유일한 진입점)

NodePort 30007 · 호스트포워딩 50007

클러스터 외부와 연결되는 유일한 진입점. /api/* 요청을 backend-svc로 프록시. 나머지 모든 서비스는 ClusterIP로 격리.

NodePort:30007Reverse Proxy

PostgreSQL + MongoDB

StatefulSet + PVC · ClusterIP

PostgreSQL(PostGIS)은 공공API 원본 데이터 저장. MongoDB는 CDC로 동기화된 읽기 전용 뷰. PG → Kafka → Mongo 흐름.

PostGISStatefulSetlocal-path

Kafka + Debezium

3-node KRaft · CDC Pipeline

Debezium이 PostgreSQL 변경사항을 Kafka로 발행. Kafka 컨슈머가 MongoDB에 싱크. 3-node KRaft로 고가용성 구성.

KRaftCDC3-node HA

[Troubleshooting] Wattup #2 프론트엔드 트러블 슈팅

modifyC — Tue, 10 Mar 2026 23:54:06 +0900

TROUBLESHOOTING LOG

WattUp 프론트엔드 개발기

고민했던 것들, 막혔던 것들, 그리고 해결한 것들

Map Marker

Troubleshooting 01

개별 충전소 마커 — offset 불일치 문제

문제

원래는 마커를 원 두 개(외곽 원 + 내부 원)로 구성했는데, 네이버 맵 위에 렌더링하면 두 원의 중심이 맞지 않았다. offset 값을 아무리 조정해도 줌 레벨마다 어긋났다.

원인

원 두 개를 독립된 DOM 요소로 쌓는 구조라 각각의 기준점(anchor)이 달라서 생긴 문제였다. 줌 레벨이 바뀔 때마다 픽셀 단위 계산이 틀어지니 고정값으로는 해결이 안 됐다.

해결

원 두 개를 버리고 하나의 원 + CSS 애니메이션(ripple)으로 구조를 바꿨다. anchor를 단일 중심점으로 잡으니 offset 문제가 사라졌고, ripple 효과 덕분에 시각적으로도 더 자연스러워졌다.

깨달은 것 DOM 구조가 복잡할수록 좌표 계산 오차가 커진다. 단순하게 만드는 것 자체가 해결책이 될 수 있다.

️

Troubleshooting 02

클러스터링 마커 — 데이터 과부하 문제

문제

목 데이터로 개발할 때는 괜찮았는데, 백엔드와 연결하자마자 서울 충전소 데이터가 한 번에 다 날아왔다. 지도가 버벅이고 마커가 수백 개씩 한꺼번에 그려지면서 사실상 사용이 불가능한 상태가 됐다.

원인

목 데이터로 개발할 때 데이터 양이 적어서 성능 문제를 미리 발견하지 못했다. 실제 공공데이터는 규모가 달랐다.

해결

구(區) 단위로 쪼개서 조회하는 방식으로 변경했다. 드롭다운에서 구를 선택하면 그 구의 충전소만 불러오도록 API 호출 방식을 바꿨다.

깨달은 것 목 데이터 개발은 빠르지만 실제 데이터 규모를 미리 고려해야 한다. 성능 이슈는 실제 데이터를 붙여봐야 보인다.

API & React

⚡

Troubleshooting 03

구 변경해도 API 호출이 안 되는 문제

문제

구 단위 조회로 바꾼 후, 지도를 아무리 움직여도 API 호출 로그가 하나도 안 찍혔다. 콘솔을 열어봐도 네트워크 요청 자체가 발생하지 않았다.

원인 (3가지 겹침)

원인 1 — stale 클로저: 맵 초기화와 이벤트 리스너 등록을 하나의 useEffect에 넣었더니, onBoundsChanged가 의존성 배열에 없어서 리스너가 최초 1회만 등록되고 갱신되지 않았다.
원인 2 — 네이버 맵 객체 키 오류: b.ne, b.sw로 접근했는데 실제 네이버 맵 객체는 b._ne, b._sw (언더스코어 필요)였다.
원인 3 — API 방식 자체가 잘못됨: bounds 좌표로 매번 호출하는 게 아니라 구 이름으로 호출하는 구조였는데, 원인 1 수정하면서 X/Y 좌표 방식으로 잘못 바꿔버렸다.

해결

useEffect를 두 개로 분리(맵 초기화 / 리스너 등록), 네이버 맵 키 수정, API 방식을 구 이름 기반으로 확정했다.

구 선택 → 지도 이동 → fetchStationsByDistrict("강동구") → GET /api/wattup/map/강동구 → 마커 렌더링

깨달은 것 React useEffect 의존성 배열은 꼼꼼히 챙겨야 한다. 하나 빠지면 stale 클로저 문제가 생긴다. 외부 라이브러리 객체 구조는 공식 문서를 직접 확인해야 한다.

Docker & Deploy

Troubleshooting 04

Docker 이미지 태그 관리 — latest의 함정

문제

이미지를 latest 태그 하나로만 관리했더니, 팀원에게 공유할 때마다 어떤 버전인지 헷갈렸다. 문제가 생겼을 때 이전 상태로 돌아갈 수도 없었다.

원인

latest는 "가장 최신"을 보장하는 게 아니라 그냥 기본 이름일 뿐이다. 같은 태그로 덮어쓰면 이전 이미지는 이름 없는 Dangling Image가 되어 복구가 불가능해진다.

해결 — 이중 태그 전략

버전 태그(v1.1)와 latest를 동시에 관리하는 방식으로 변경했다.

# 버전 태그로 빌드
docker build -t soojungchoi98/wattup-fe:v1.1 .

# 같은 이미지에 latest 별칭 추가
docker tag soojungchoi98/wattup-fe:v1.1 soojungchoi98/wattup-fe:latest

# 둘 다 푸시 (동일한 데이터, 용량 중복 없음)
docker push soojungchoi98/wattup-fe:v1.1
docker push soojungchoi98/wattup-fe:latest

깨달은 것 도커 태그는 포인터다. 한 번 푸시한 버전 태그는 절대 수정하지 않고, 변경사항은 v1.2처럼 새 버전으로 만드는 것이 원칙이다.

OCI Cloud Deploy

☁️

경험 공유

Vercel vs Docker — OCI로 배포해보기

고민

프론트엔드 배포 방법으로 Vercel과 Docker 이미지 두 가지를 고민했다. Vercel은 간편하지만, 이번 프로젝트는 백엔드/DB 전체가 Docker로 구성되어 있었다.

결과

팀원의 아이디어로 OCI(Oracle Cloud Infrastructure) 무료 티어를 활용하는 방안이 나왔다. 직접 계정을 만들고 Ingress 포트를 열어서 Docker 이미지를 클라우드에 배포하는 경험을 해볼 수 있었다.

깨달은 것 Vercel 클릭 한 번과는 다르게, 포트 개방부터 컨테이너 실행까지 직접 하면서 배포의 흐름을 제대로 이해할 수 있었다.

Troubleshooting 06

OCI 배포 — Docker인 줄 알았더니 Podman이었다

문제

OCI 인스턴스에 docker run으로 프론트엔드 컨테이너를 올렸는데, 외부 IP로 접근이 아예 안 됐다. localhost에서는 HTML이 정상 반환됐고, 오라클 콘솔 Security List에서 80/443 포트도 열어뒀는데 계속 No route to host 오류가 났다.

원인 (3가지 겹침)

원인 1 — Docker가 아닌 Podman: OCI는 Red Hat 계열 리눅스라 docker 명령어를 치면 Podman이 에뮬레이션 모드로 실행된다. CLI는 같지만 내부 네트워크 처리 방식이 달라 방화벽 충돌이 생겼다.
원인 2 — Security List Source Port 설정 오류: Source Port를 80, 443으로 지정했는데, 클라이언트는 임의의 Ephemeral Port로 요청을 보내기 때문에 대부분의 요청이 차단됐다.
원인 3 — nftables FORWARD 체인 REJECT 규칙: OCI 리눅스는 iptables와 nftables가 동시에 동작한다. iptables에서 REJECT 규칙을 지워도 nftables가 별도로 포워딩을 막고 있었다.

해결 과정

# Step 1. localhost 정상 확인
curl http://localhost:80

# Step 2. iptables REJECT 규칙 제거
sudo iptables -D INPUT -j REJECT --reject-with icmp-host-prohibited
sudo netfilter-persistent save

# Step 3. Security List → Source Port Range를 All로 수정

# Step 4. nftables FORWARD 체인 확인 후 flush
sudo nft list ruleset
sudo nft flush ruleset
sudo netfilter-persistent save

# Step 5. 컨테이너 재시작
sudo podman stop wattup-fe && sudo podman rm wattup-fe
sudo podman run -d --name wattup-fe -p 80:80 docker.io/soojungchoi/wattup-fe:v1.4

✅ 결과

외부 IP로 HTML 정상 반환 확인. 총 3가지 원인이 겹쳐있어서 하나씩 제거하는 과정이 필요했다.

항목	Docker (Ubuntu)	Podman (Oracle Linux)
데몬	dockerd 상시 실행	데몬 없음 (daemonless)
방화벽	iptables 단일	iptables + nftables 동시
CLI	docker 명령어	docker 에뮬레이션
네트워크	docker0 브리지	CNI 기반

깨달은 것 배포 전 docker info로 런타임 확인 필수. OCI는 iptables와 nftables가 동시에 동작하니 두 곳 모두 확인해야 한다. nft flush ruleset은 모든 규칙을 날리기 때문에 SSH 세션을 미리 하나 더 열어두고 실행할 것.

GitHub Repository

wattup-fe 보러가기

[Project Intro] Wattup #1 프로젝트 소개

modifyC — Tue, 10 Mar 2026 23:20:14 +0900

⚡ PROJECT WATTUP

WattUp

공공데이터 기반 전기차 충전소 확인 및 예약 플랫폼

React FastAPI Kafka Kubernetes Debezium PostgreSQL MongoDB

Introduction

이 플랫폼은 무엇인가요?

전기차 보급이 빠르게 늘어나고 있지만, 충전소 정보는 여전히 파편화되어 있습니다. WattUp은 공공데이터 API를 활용해 실시간으로 전국 충전소 현황을 지도 위에 보여주고, 원하는 충전소를 바로 예약할 수 있는 서비스입니다.

핵심 기능

지역구 선택 시 지도가 해당 좌표로 이동하며 충전소를 클러스터링으로 표시
zoom 단계에 따라 충전소 개수 또는 충전기 개수를 마커 숫자로 표시
충전소 마커 클릭 시 우측 모달에서 충전기 정보, 이미지, 예약 가능 시간 확인
예약자 번호 입력 후 예약 확정 — 실시간으로 DB에 반영

User Flow

어떻게 사용하나요?

지역구 선택

화면 왼쪽 상단 드롭다운에서 원하는 구를 선택합니다. 지도가 해당 구 좌표로 자동 이동합니다.

클러스터링 마커 확인

zoom 레벨에 따라 충전소들이 클러스터링됩니다. 마커의 숫자는 해당 구역의 충전소 개수를 나타냅니다.

개별 충전소 마커

지도를 확대하면 개별 충전소 마커가 나타납니다. 마커의 숫자는 해당 충전소의 충전기 개수입니다.

충전소 상세 정보

마커를 클릭하면 우측에 모달이 열립니다. 충전기 타입, 이용 가능 현황, 운영 시간, 이미지 정보를 확인할 수 있습니다.

예약 완료

예약 가능 시간을 선택하고 예약자 번호를 입력한 후 확인 버튼을 누르면 예약이 완료됩니다.

Screenshots

서비스 화면

마커 색상은 충전소 이용 가능 여부를 나타냅니다.

이용 가능

일부 가능

이용 불가

내 위치

️ 클러스터링 마커 — zoom 레벨별 충전소 집계

개별 충전소 마커 — 충전기 개수 표시

충전소 상세 정보 모달

내 위치 표시 마커

Tech Stack

사용 기술

Frontend

React Naver Maps API

Backend

FastAPI Python

Database

PostgreSQL MongoDB

Streaming / CDC

Kafka Debezium

Infra

Kubernetes Docker Nginx Tailscale

Environment

OCI VirtualBox

Team

팀 구성

총 6명이 역할을 나누어 개발했습니다.

Frontend

2명

⚙️

Backend

2명

️

DB / Kafka / Debezium

2명

☸️

Kubernetes 배포

개별 진행

[Technical Review] 말랑이 메이커 #3 AWS Resource Groups 및 태그 관리 방법

modifyC — Wed, 25 Feb 2026 11:18:26 +0900

현재 프로젝트에서 쓰고 있는 스택이 너무 많아서 일일이 검색하기 번거로워 자원을 한 번에 감독할 수 있는 Resource Groups을 사용하게 되었다.

Resource Groups 스택 기반

CloudFromation을 사용하고 있어서 간단하게 조회하기 위해 CloudFormation 스택 기반으로 조회해 보았다.

그룹화는 Cloud Fromation에서 생성했던 malang-maker을 선택 후 그룹 리소스 미리 보기를 해보았다.

그랬더니 내가 쓰던 리소스는 더 많은 리소스를 사용했는데 3가지 밖에 나오지 않았다.

그래서 사용하는 스택들에 태그를 달아서 한 번에 리소스 관리를 하기로 했다.

cloudFormation 태그 설정하기

스택 업데이트 > 직접 업데이트를 눌러야 한다. (변경 세트 생성 x)

기존 템플릿 사용 선택 후 다음

스택 옵션 구성 최상단에 태그를 추가할 수 있다.

새 태그 추가 버튼을 클릭한 후 키와 값을 작성한다.

최하단에 다음 버튼을 클릭한다

4단계도 그냥 다음 버튼을 눌러서 저장하면 된다.

스택으로 돌아오면 태그가 잘 달려있는 것을 확인할 수 있다.

다시 돌아와서 리소스를 태그 기반으로 설정해 볼 것이다.

Resource Group 태그 기반

태그 기반으로 선택 후

태그에 아까 작성한 키 밸류를 작성한다. 그리고 그룹 리소스 미리 보기를 클릭한다.

내가 사용 중인 리소스가 나오게 된다.

그룹 이름을 작성하고 저장 버튼을 누른다. (이미 있던 리소스 그룹 이름과 중복 사용 불가능하다)

저장된 리소스 그룹에서 내가 작성한 태그 별로 잘 정리되어 있는 것을 확인할 수 있다.

[Technical Review] 말랑이 메이커 #2: SAM으로 FastAPI 서버리스 마이그레이션 및 트러블슈팅

modifyC — Tue, 24 Feb 2026 09:52:39 +0900

https://pf.kakao.com/_kRFRX

1. 전체 아키텍처 흐름

FastAPI에 Mangum 부착: 기존 웹 프레임워크를 Lambda가 이해할 수 있게 변환
Docker & ECR: 코드를 컨테이너 이미지로 말아서 AWS ECR에 푸시
AWS Lambda: 올라간 이미지를 기반으로 서버리스 함수 실행
API Gateway: Lambda를 외부(카카오톡 챗봇 등)와 연결해 주는 대문 역할
IAM Role: Lambda가 DynamoDB에 접근할 수 있도록 권한 제한
AWS SAM: 이 모든 인프라 생성과 배포 과정을 템플릿 하나로 자동화
테스트: 로컬 빌드 및 실환경 테스트

2. AWS IAM 권한 세팅

기존에 쓰던 malang-dev 계정은 딱 DynamoDB 접근 권한만 열려 있었음.

권한 최소화 원칙을 지키기 위해 배포 전용 IAM 사용자 그룹을 새로 파고, SAM 배포에 딱 필요한 권한만 쥐여줬다.

서비스	권한 이름 (AWS 관리형 정책)	왜 필요한가? (설명)
IAM	IAMFullAccess	Lambda가 사용할 Role을 SAM이 배포 과정에서 직접 만들어야 해서
CloudFormation	AWSCloudFormationFullAccess	SAM은 내부적으로 CloudFormation을 엔진으로 써서 인프라를 구축
Lambda	AWSLambda_FullAccess	람다 함수를 생성하고, 업데이트하고, 삭제하는 핵심 권한
ECR	AmazonEC2ContainerRegistryFullAccess	로컬에서 빌드한 Docker 이미지를 AWS 저장소에 업로드(Push)해야 하니까 필수
S3	AmazonS3FullAccess	SAM이 배포할 때 템플릿이랑 설정 파일들을 임시로 얹어둘 공간이 필요
API Gateway	AmazonAPIGatewayAdministrator	외부에서 람다를 찌를 수 있게 URL 대문을 만들어야 하니까 필요
DynamoDB	AmazonDynamoDBFullAccess	우리 말랑이 유저 데이터를 읽고 써야 하니까 당연히 필요

(추가1) sam deploy로 배포 시엔 IAM FULL ACCESS가 필요하지만 배포가 완료 됐을 땐 READONLY로 권한 설정 변경 해야 함

3. 주요 코드 및 설정 변경 (SAM & FastAPI)

인프라 세팅이 끝났으니, 본격적으로 코드를 서버리스 환경에 맞게 뜯어고침

SAM 템플릿 (template.yaml): 소스 코드 직배포가 아니라 도커 이미지를 쓴다고 PackageType: Image로 명시.

환경별 DB 분기 (db.py): 로컬은 .env로 자격 증명을 읽고, Lambda 환경은 부여된 IAM Role을 쓰도록 os.getenv("AWS_LAMBDA_FUNCTION_NAME")를 기준으로 분기 처리.

어댑터 장착 (main.py): handler = Mangum(app, lifespan="off") 한 줄로 FastAPI와 Lambda를 연결.

도커 베이스 변경 (Dockerfile): public.ecr.aws/lambda/python:3.10 같은 AWS 전용 이미지로 베이스를 교체하고 CMD ["main.handler"] 설정.

4. 배포

1단계: 서버 구울 준비 (sam build --use-container)

파이썬 코드랑 Dockerfile을 통째로 섞어서 하나의 완성된 '도커 컨테이너 이미지'로 만드는 과정

왜 --use-container가 필요할까? template.yaml에서 PackageType: Image라고 선언. 일반 파이썬 코드를 짚(zip) 파일로 묶어서 올리는 게 아니라, 람다가 실행될 환경이랑 똑같은 도커 컨테이너 안에서 빌드하라고 SAM에게 명령하는 것임. 이 옵션을 빼먹으면 로컬 PC 환경 기준으로 빌드가 돼서 나중에 람다에서 꼬일 수 있음

2단계: 최초 배포 (sam deploy --guided 또는 -g)

이건 AWS에 "나 말랑이 서버 처음 올릴 건데, 호구조사 좀 해줘"라고 하는 단계. --guided를 붙이면 SAM이 배포에 필요한 필수 설정들을 대화형으로 캐물어.

여기서 만났던 주요 질문들

Stack Name: 우리 프로젝트 묶음 이름이야. (예: malang-maker)
AWS Region: 어디 서버에 올릴 거냐는 건데, 서울이니까 당연히 ap-northeast-2.
Image Repository: 도커 이미지를 AWS의 어디(ECR)에 저장할 건지
Confirm changes before deploy: 배포하기 전에 바뀐 내용 보여줄까? (Y 누르면 안전함)
Allow SAM CLI IAM role creation: SAM이 알아서 람다 실행 권한(Role) 만들어줘도 돼? (당연히 Y. 이거 안 하면 우리가 일일이 권한 다 만들어줘야 해)

폴더에 samconfig.toml이라는 파일이 하나 생기는데 이게 일종의 '자동 로그인 쿠키'임. 대답한 설정들이 다 여기 저장됨

3단계: 수정 후 재배포 (일상적인 배포)

이제 samconfig.toml이 있으니까, 앞으로 코드 수정하고 다시 올릴 땐 꼬치꼬치 안 물어봄

rmdir /s /q .aws-sam 기존에 빌드하다 남은 찌꺼기(캐시) 폴더를 미련 없이 날려버리는 명령어. (윈도우 기준)
sam build --use-container 깨끗한 상태에서 도커 이미지를 다시 예쁘게 굽기.
sam deploy 더 이상 --guided를 안 붙여도 됨. 알아서 기존 설정 읽어서 AWS에 업데이트된 이미지만 싹 올려줌

5. 트러블슈팅

이슈 1: 카카오톡 NetworkAccessForbidden (응답 없음)

현상: 카카오톡 채널에서 메시지를 보내도 응답이 없고, 카카오 설정 페이지에서는 '네트워크 오류'만 뜸. 심지어 503 같은 에러 코드조차 안 뜨는 상황.
진짜 원인: Dockerfile의 베이스 이미지가 문제였음. 기존에는 일반적인 Python slim 이미지를 사용했는데, AWS Lambda는 전용 런타임 환경이 필요함. 일반 이미지를 쓰면 Lambda가 코드를 실행할 준비(Init)조차 못 하고 죽어버리니까 카카오 입장에서는 "연결 거부"로 판단한 것.

해결: 베이스 이미지를 AWS에서 제공하는 Lambda 전용 이미지로 변경.

# 변경 전: FROM python:3.10-slim (Lambda에서 실행 불가)
# 변경 후: 
FROM public.ecr.aws/lambda/python:3.10

이슈 2: 카카오톡 챗봇 NetworkAccessForbidden (503 에러)

현상: 카카오 챗봇에서 응답이 없고 네트워크 오류가 뜸.
원인: 서버가 500대 에러를 뱉으면 카카오 측에서 연결을 강제로 끊어버림. 즉, 내 코드 문제.
접근: sam logs -n MalangMakerFunction --stack-name malang-maker --tail로 람다 로그부터 까봄.
handler = Mangum(app) -> handler = Mangum(app, lifespan="off") 로 코드 변경 수정하고 재배포 해 봄. 근데 이슈 3이 나타나게 됨.

이슈 3: Runtime.ImportModuleError (Unable to import module 'main')

현상: 로그를 보니 람다가 도커 안의 main.py를 아예 못 찾고 있었음.
원인: 이미지 경로가 꼬였거나, 기존 빌드 캐시(찌꺼기)가 엉뚱하게 올라간 상태.
해결: rmdir /s /q .aws-sam으로 캐시 완전 멸망시키고, sam build --use-container로 도커 환경에서 깔끔하게 재빌드 후 재배포.

이슈 4: AWS_REGION 예약어 충돌 (Configuration Warning)

현상: template.yaml의 환경 변수 설정에서 AWS_REGION이라는 이름을 그대로 사용했더니, 배포 시 경고가 뜨거나 Lambda 실행 시 지역 정보를 제대로 못 불러오는 문제가 발생함.
원인: AWS_REGION은 AWS Lambda가 예약(Reserved)해둔 환경 변수. 람다 런타임이 실행될 때 자동으로 설정되는 값. 이걸 사용자가 임의로 설정(Overwrite)하려고 하면 설정 충돌 경고가 뜨거나, 런타임에서 강제로 값을 고정해버려서 보낸 값이 무시될 수 있음

해결: 변수 이름을 MY_APP_REGION처럼 커스텀 명칭으로 변경해서 충돌을 피함.

# 변경 전
Variables:
  AWS_REGION: ap-northeast-2  # 예약어라 위험!

# 변경 후
Variables:
  MY_APP_REGION: ap-northeast-2  # 안전한 커스텀 변수

이슈 5 이미지 파일 증발:

원인: 빌드 후 람다 로그를 까보니 이미지 파일을 못 찾는 에러가 떴고, 범인은 .dockerignore에 실수로 적어둔 img 폴더 때문이었음 (이미지만 서버에 안 올라감).
해결: .dockerignore에서 해당 줄을 바로 지워버리고 깨끗하게 재빌드해서 배포.

이슈 6: 브라우저에서 {"detail":"Method Not Allowed"} 등장

현상: 배포 성공 후 주어진 API Gateway URL로 들어갔더니 저 에러가 뜸.
해결: 이건 에러가 아니라 성공의 증거! 브라우저 주소창은 GET 요청인데, 내 API는 POST만 받게 되어 있어서 프레임워크가 정상적으로 방어한 거야. 서버가 아주 건강하게 살아있다는 뜻

[15686] 치킨 배달

modifyC — Thu, 19 Feb 2026 18:53:12 +0900

집과 치킨집 좌표 추출

지도를 매번 처음부터 끝까지 훑는 건 시간이 너무 오래 걸린다. 그래서 가장 먼저 지도에서 집이 있는 위치와 치킨집이 있는 위치만 따로 뽑아 주소록을 만든다.

# 입력 받기

n, m = map(int, input().strip().split())

houses = []

chickens = []

# graph 입력 받기

for r in range(n):

row = list(map(int, input().strip().split()))

for c in range(n):

if row[c] == 1:

houses.append((r, c))

elif row[c] == 2:

chickens.append((r, c))

치킨집 조합 생성

전체 치킨집 중에서 남길 개수만큼 고르는 모든 경우의 수를 짠다. 이때 백트래킹을 사용한다. 치킨집 하나를 선택해 장바구니에 담고 다음 후보를 살핀 뒤, 계산이 끝나면 다시 그 치킨집을 빼고 다른 후보를 담는 과정을 반복하며 모든 조합을 만든다.

def dfs(idx, count):

global min_city_distance

# 종료 조건

if count == m:

city_distance = calcuate(select_chickens)

min_city_distance = min(min_city_distance, city_distance)

return

# 후보 탐색

for i in range(idx, len(chickens)):

select_chickens.append(chickens[i])

dfs(i + 1, count + 1)

select_chickens.pop()

각 집의 최단 거리 계산

치킨집 조합이 하나 완성될 때마다 거리 측정을 시작한다. 모든 집을 하나씩 순회하며, 방금 선택된 치킨집들 중 해당 집과 가장 가까운 곳까지의 거리를 구한다. 이것이 각 집의 치킨 거리가 된다.

def calcuate(selected):

total_distance = 0

for hr, hc in houses:

temp_min = float("inf")

for cr, cc in selected:

dist = abs(hr - cr) + abs(hc - cc)

temp_min = min(temp_min, dist)

total_distance += temp_min

return total_distance

도시 전체 거리 합산 및 비교

모든 집의 치킨 거리를 다 더해서 해당 조합의 최종 점수를 낸다. 새로운 조합이 만들어질 때마다 이 과정을 반복하며, 지금까지 나온 점수 중 가장 낮은 값을 계속 업데이트한다.

최적의 결과 도출

모든 경우의 수를 전부 따져본 후, 마지막까지 살아남은 가장 작은 합계 점수를 정답으로 출력한다.

치킨 배달 최악의 연산량 계산

1. 치킨집 조합 만들기

상황: 치킨집 13개 중 6개를 고를 때 (가장 가짓수가 많은 경우)
가짓수: 1,716가지

2. 한 번의 조합당 거리 계산

상황: 집 100개와 선택된 치킨집 6개를 일일이 비교할 때
계산량: 100개(집) × 6개(치킨집) = 600번

3. 전체 연산 횟수

합계: 1,716가지(조합) × 600번(계산) = 1,029,600번

import sys

input = sys.stdin.readline

# 입력 받기

n, m = map(int, input().strip().split())

houses = []

chickens = []

# graph 입력 받기

for r in range(n):

row = list(map(int, input().strip().split()))

for c in range(n):

if row[c] == 1:

houses.append((r, c))

elif row[c] == 2:

chickens.append((r, c))

select_chickens = []

min_city_distance = float("inf")

def calcuate(selected):

total_distance = 0

for hr, hc in houses:

temp_min = float("inf")

for cr, cc in selected:

dist = abs(hr - cr) + abs(hc - cc)

temp_min = min(temp_min, dist)

total_distance += temp_min

return total_distance

def dfs(idx, count):

global min_city_distance

# 종료 조건

if count == m:

city_distance = calcuate(select_chickens)

min_city_distance = min(min_city_distance, city_distance)

return

# 후보 탐색

for i in range(idx, len(chickens)):

select_chickens.append(chickens[i])

dfs(i + 1, count + 1)

select_chickens.pop()

dfs(0, 0)

print(min_city_distance)

cmod.ify

[AI Tool] Claude Code #2 - 토큰, 왜 이렇게 빨리 닳을까? (실전 기준으로 토큰 절약하기)

1. 내가 토큰을 얼마나 쓰고 있는지 확인하기

2. 토큰이 뭔가요?

3. 토큰 문제 vs 컨텍스트 문제 (이 둘은 다릅니다)

4. 요금제별 체감 (수치보다 경험 기준)

5. 토큰보다 중요한 건 결과 타입이다

6. 토큰 낭비하는 사람 특징

7. 실전 토큰 절약 팁

정리

[AI Tool] Claude Code #1 - Claude CLI로 코딩하기 (설치부터 GitHub MCP 연동까지)

Claude Code가 뭔가요?

설치 방법 2가지

1. vscode Extension으로 설치

2. CLI로 설치

환경변수 등록하기

처음 실행

/init - 프로젝트 메모리 만들기

주요 명령어 정리

CLI 플래그 (터미널에서 실행)

세션 내부 슬래시 명령어

인터랙티브 모드 단축키

모델 선택

컨텍스트란?

파일 수정/생성 권한 설정

Git 연동

GitHub MCP 연동

1단계: GitHub PAT 발급

2단계: MCP 등록

3단계: 확인

사용 예시

정리

[Optimization] Wattup #5 K8s 클러스터 메모리 최적화

WattUp K8s 메모리 최적화

[Technical Review] Wattup #4 VirtualBox 기반 K8s 클러스터 구축과 트러블슈팅

WattUp K8s 배포 전과정

[ARCHITECTURE] Wattup #3 OCI/VirtualBox-K8s | 하이브리드 네트워크 설계

WattUp Infrastructure

[Troubleshooting] Wattup #2 프론트엔드 트러블 슈팅

WattUp 프론트엔드 개발기

[Project Intro] Wattup #1 프로젝트 소개

WattUp

이 플랫폼은 무엇인가요?

핵심 기능

어떻게 사용하나요?

지역구 선택

클러스터링 마커 확인

개별 충전소 마커

충전소 상세 정보

예약 완료

서비스 화면

사용 기술

팀 구성

[Technical Review] 말랑이 메이커 #3 AWS Resource Groups 및 태그 관리 방법

Resource Groups 스택 기반

cloudFormation 태그 설정하기

Resource Group 태그 기반

[Technical Review] 말랑이 메이커 #2: SAM으로 FastAPI 서버리스 마이그레이션 및 트러블슈팅

https://pf.kakao.com/_kRFRX

1. 전체 아키텍처 흐름

2. AWS IAM 권한 세팅

(추가1) sam deploy로 배포 시엔 IAM FULL ACCESS가 필요하지만 배포가 완료 됐을 땐 READONLY로 권한 설정 변경 해야 함

3. 주요 코드 및 설정 변경 (SAM & FastAPI)

4. 배포

5. 트러블슈팅

[15686] 치킨 배달

집과 치킨집 좌표 추출

치킨집 조합 생성

각 집의 최단 거리 계산

도시 전체 거리 합산 및 비교

최적의 결과 도출

치킨 배달 최악의 연산량 계산

`/init` - 프로젝트 메모리 만들기