블로그
GPU·LLM·MLOps·쿠버네티스, 그리고 마음가짐에 관한 글 · 3672 편
#2026-03 762#culture 283#deep-dive 275#kubernetes 260#career 233#ai 220#llm 216#devops 195#2026-04 158#security 147#observability 118#database 113#communication 108#history 107#architecture 101#productivity 98#performance 93#linux 90#networking 89#finance 87#economy 84#mindset 80#psychology 79#ai-papers 78#food 78#it 78#travel 78#japanese 76#deep-learning 75#english 74#gpu 74#ai-agent 69#business-travel 69#postgresql 66#cs-fundamentals 63#rag 63#systems 63#python 55#learning 54#self-improvement 53
홈랩 쿠버네티스 3노드에서 7노드로 — 컨트롤 플레인 확장, etcd 쿼럼, 그리고 "조인만 하면 HA"라는 착각
워커 2대와 컨트롤 플레인 2대를 추가해 홈랩을 7노드로 확장했습니다. kubeadm의 certificate-key가 왜 2시간짜리인지, etcd 멤버 3개가 실제로 어떻게 등록되는지를 실측으로 기록했습니다. 그리고 가장 중요한 발견 — etcd 쿼럼을 갖췄다고 HA가 되는 게 아니었습니다. 엔드포인트가 물리 IP에 고정된 클러스터에서 첫 노드가 죽으면 무슨 일이 벌어지는지, 인증서 재발급
2026-08-28 · 15 분 읽기 #kubernetes#kubeadm#etcd#high-availability#homelabGPU Operator 설치 중 만난 "no runtime for nvidia is configured" — 컨테이너 런타임과 Helm 업그레이드가 실제로 하는 일
5노드 홈랩에 NVIDIA GPU Operator를 올리다 파드가 전부 Init에서 멈췄습니다. 원인은 컨테이너 런타임에 nvidia 핸들러가 없다는 것이었고, 호스트에 nvidia-ctk 바이너리가 있다고 방심한 제 판단 착오였습니다. 왜 쿠버네티스에서 container toolkit이 필수인지, Helm upgrade가 내부적으로 무엇을 바꾸는지, 그리고 Operator가 containe
2026-08-27 · 20 분 읽기 #kubernetes#gpu#nvidia#containerd#helmSynology NAS를 쿠버네티스 동적 PVC 백엔드로 — csi-driver-nfs로 5노드 홈랩에 RWX 스토리지 붙이기
홈랩 쿠버네티스에 Synology NAS를 붙여 PVC를 자동 생성되게 만들었습니다. 포트 스캔으로 NAS 정체를 알아내는 것부터, 첫 마운트 시도가 실패한 진짜 이유, csi-driver-nfs 설치와 StorageClass 두 벌 구성, 그리고 서로 다른 물리 노드가 같은 볼륨에 동시에 읽고 쓰는 RWX 검증까지 실제 출력으로 기록했습니다.
2026-08-26 · 18 분 읽기 #kubernetes#storage#nfs#csi#synology세 줄짜리 설정 파일이 GPU 4장을 일주일 동안 죽였다 — containerd 드롭인 병합의 진실
노드가 GPU를 광고하지 않았습니다. 설정 파일에는 nvidia 런타임이 멀쩡히 적혀 있는데 containerd config dump에는 없었습니다. 범인은 일주일 전에 넣은 세 줄짜리 레지스트리 설정이었고, 이유는 containerd의 imports 병합이 필드 단위가 아니라 플러그인 단위 통째 교체이기 때문이었습니다. 두 번 잘못 진단한 과정과, 결국 답을 준 실험을 그대로 옮깁니다.
2026-08-26 · 20 분 읽기 #kubernetes#containerd#gpu#nvidia#troubleshootingkube-proxy 없는 쿠버네티스 — 3노드 홈랩을 kubeadm 1.34 + Cilium eBPF로 재구축하고 실측으로 증명하기
DHCP가 IP를 바꾸는 바람에 죽어버린 홈랩 클러스터를 kubeadm 1.34와 Cilium 1.20으로 처음부터 다시 세웠습니다. kube-proxy를 아예 설치하지 않고 eBPF로 대체했고, 그것이 실제로 동작한다는 것을 iptables 체인 개수와 eBPF 맵 덤프로 확인했습니다. HTTP 메서드 단위 L7 정책, 사이드카 없는 Hubble 관측, WireGuard 투명 암호화까지 실
2026-08-25 · 15 분 읽기 #kubernetes#cilium#ebpf#kubeadm#networking모두를 위한 AI 6편 — 111만 파라미터 디퓨전으로 단어에서 숫자 그리기
"zero"라고 쓰면 0을 그리는 조건부 디퓨전 모델을 111만 파라미터로 만들었습니다. 노이즈를 섞는 forward는 공식 한 줄이고, 복원하는 reverse는 그 한 줄을 400번 거꾸로 밟는 것뿐입니다. 5편에서 L1 손실이 색을 바래게 만든 문제를 디퓨전이 어떻게 피해 가는지, 그리고 왜 모델이 노이즈를 예측하도록 학습되는지를 실제 생성 결과로 확인합니다.
2026-08-24 · 15 분 읽기 #ai#diffusion#ddpm#generative#pytorch모두를 위한 AI 5편 — 47만 파라미터 U-Net으로 흑백 사진에 색 입히기, 그리고 왜 색이 바랬는가
시리즈에서 가장 작은 모델인 47만 파라미터 U-Net으로 CIFAR-10 흑백 이미지를 컬러로 복원했습니다. 형태는 정확히 살렸지만 색이 눈에 띄게 바랬는데, 이건 모델 용량 문제가 아니라 L1 손실을 고른 결과입니다. skip connection이 무엇을 나르는지, 그리고 회귀 손실이 왜 채도를 죽이는지를 실제 결과 이미지로 확인합니다.
2026-08-23 · 14 분 읽기 #ai#computer-vision#unet#colorization#pytorch모두를 위한 AI 4편 — 137만 파라미터로 이미지에 문장 붙이기, 그리고 3편의 버그가 여기엔 없던 이유
CNN 인코더와 트랜스포머 디코더를 이어 붙여 Fashion-MNIST 이미지에 캡션을 다는 모델을 만들었습니다. 137만 파라미터, 10분 학습으로 라벨 적중률 91%가 나왔습니다. 인코더-디코더 구조에서 cross-attention이 무엇을 하는지, 그리고 3편에서 정확도를 7.5%로 떨어뜨렸던 EOS 버그가 왜 이 코드에는 없었는지를 두 함수를 나란히 놓고 확인합니다.
2026-08-22 · 12 분 읽기 #ai#captioning#multimodal#transformer#pytorch모두를 위한 AI 3편 — 손실 0.0017인데 정확도 7.5%, 범인은 패딩 한 칸이었다
이미지와 질문을 함께 받아 답하는 VQA 모델을 148만 파라미터로 만들었습니다. 학습 손실은 0.0017까지 떨어졌는데 정확도는 7.5%였습니다. 무작위보다 나쁜 수치였죠. 원인은 모델이 아니라 정답을 만드는 코드 한 줄이었고, 고치자 99.5%가 됐습니다. 왜 낮은 손실이 좋은 모델을 보장하지 않는지, 그리고 그 함정을 어떻게 알아채는지를 실제 출력으로 확인합니다.
2026-08-21 · 14 분 읽기 #ai#vqa#multimodal#debugging#pytorch집에 있는 서버로 실습형 학습 플랫폼 만들기 — 특권 없는 파드 안에 쿠버네티스를 넣는 방법
수강생이 버튼을 누르면 전용 컨테이너가 뜨고, 브라우저 터미널에서 진짜 리눅스 셸을 만지고, 단계마다 서버가 실제 상태를 검사해 채점하는 학습 플랫폼을 집에 있는 7노드 쿠버네티스 클러스터 위에 올린 기록입니다. 가장 어려운 문제는 기능이 아니라 격리였습니다. 실습이므로 수강생에게 root 를 줘야 하는데, 그 root 가 집 네트워크로 나가면 안 됩니다. Cilium 네트워크 정책을 실습별
2026-08-20 · 28 분 읽기 #kubernetes#cilium#security#homelab#kwokLabHub — 브라우저에서 진짜 서버를 만지며 배우는 실습 플랫폼을 열었습니다
읽어서는 늘지 않는 것들이 있습니다. 서버에 붙어 명령을 치고, 틀리고, 왜 틀렸는지 확인하는 과정을 대신할 방법이 없습니다. LabHub 은 그 과정을 브라우저 안에 넣은 학습 플랫폼입니다. 실습 시작을 누르면 전용 리눅스 컨테이너가 즉시 뜨고, 브라우저 터미널로 붙어 과제를 풀고, 단계마다 서버가 실제 상태를 검사해 통과 여부를 알려 줍니다. 러닝패스 12개에 코스 73개, 실습 261개
2026-08-20 · 14 분 읽기 #labhub#kubernetes#devops#education#hands-onRust 문자열이 까다로운 이유, 그리고 한글에서 그 선택이 옳은 이유
Rust에서 문자열이 어렵다는 말은 대개 인덱싱이 안 된다는 뜻입니다. 그런데 한글을 다루면 그 제약이 방어 장치였다는 게 드러납니다. "커널 파라미터 튜닝"은 26바이트이고 10글자입니다. str::find가 돌려주는 7과 사람이 세는 4가 다른 이유, len()이 바이트인 이유, 그리고 실제 검색 도구에서 이 차이가 어떻게 버그가 되는지를 실행 결과와 테스트 코드로 확인합니다.
2026-08-19 · 14 분 읽기 #rust#string#utf-8#cjk#korean커널을 빌드하고 부팅하기 — 내 노트북 말고 VM에서
커널을 직접 빌드해 본 사람과 그렇지 않은 사람 사이에는 넘기 힘든 선이 하나 있습니다. 이 글은 그 선을 넘는 절차를 처음부터 끝까지 정리합니다. defconfig와 menuconfig와 localmodconfig가 각각 무엇을 해 주는지, .config 파일이 실제로 무엇을 통제하는지, 디버그 심볼이 빌드 시간과 디스크를 어떻게 잡아먹는지, 그리고 병렬 빌드 옵션이 어디서 한계에 부딪히는
2026-08-19 · 28 분 읽기 #linux#kernel#kbuild#kconfig#qemu벤치마크가 거짓말하는 세 가지 방식 — Rust CLI를 실제로 재보고 진 이야기
Rust로 만든 검색 도구를 실제 코퍼스 11,483개 파일에 돌려 ripgrep, grep과 비교했습니다. 결과는 ripgrep이 약 10배 빨랐고 제 도구는 BSD grep과 비슷했습니다. 그런데 이 숫자에 도달하기까지 하니스 버그 세 개가 각각 그럴듯하지만 틀린 결과를 냈습니다. 셸 함수가 실제 도구를 가로챈 일, 프로세스 기준 타이머를 프로세스 간에 뺀 일, time의 출력을 스스로
2026-08-19 · 16 분 읽기 #rust#cli#benchmark#performance#ripgrep커널을 관측하고 디버깅하기 — printk, ftrace, kprobes, 그리고 QEMU와 GDB
커널 디버깅에는 사용자 공간과 결정적으로 다른 제약이 하나 있습니다. 멈춰 세우면 시스템 전체가 멈춘다는 것입니다. 그래서 커널 관측 도구는 대부분 멈추지 않고 들여다보는 쪽으로 발달했습니다. 이 글은 그 도구들을 실제로 쓰는 순서대로 정리합니다. 먼저 모두가 실제로 가장 많이 쓰는 printk와 dmesg를, 그다음 oops 메시지를 소스 줄 번호로 되돌리는 트리 안의 스크립트들을, 이어서
2026-08-19 · 31 분 읽기 #linux#kernel#ftrace#kprobes#perf커널 소스에서 길 찾기 — clone부터 "이 동작을 하는 코드"를 찾아내기까지
커널 학습에서 실제로 가장 자주 쓰게 되는 기술은 읽기가 아니라 찾기입니다. 어떤 트리를 받을지부터 정리합니다. mainline, stable, longterm이 각각 무엇이고 kernel.org의 릴리스 표를 어떻게 읽는지, torvalds 트리와 stable 트리 중 무엇을 clone해야 하는지, 얕은 복제가 언제 손해로 돌아오는지를 다룹니다. 그다음이 이 글의 본론입니다. 알고 있는 동
2026-08-19 · 29 분 읽기 #linux#kernel#kernel-source#git#cscope시스템 콜 하나를 끝까지 따라가기 — read가 커널 안에서 지나는 길
커널이 읽을 수 있는 코드라는 것을 확인하는 가장 좋은 방법은 시스템 콜 하나를 처음부터 끝까지 따라가 보는 것입니다. read(2)를 골라 사용자 공간의 호출부터 커널 안의 실제 구현, 그리고 반환까지 실제 파일 경로와 함수 이름과 함께 추적합니다. x8664에서 인자가 어느 레지스터에 실려 오는지, dosyscall64가 번호를 어떻게 함수로 바꾸는지, SYSCALLDEFINE3 매크로가
2026-08-19 · 31 분 읽기 #linux#kernel#syscall#vfs#x86첫 커널 패치 보내기 — 코드보다 절차가 관문인 이유
커널에 첨 기여할 때 막히는 곳은 대개 코드가 아니라 절차입니다. 첫 패치가 반려되는 이유의 상당수는 로직이 아니라 형식이고, 그 형식은 전부 커널 트리 안에 문서로 들어 있습니다. 이 글은 scripts/checkpatch.pl과 scripts/getmaintainer.pl이 각각 무엇을 답해주는지, Signed-off-by가 왜 필수이며 무엇을 증명하는지, 커밋 메시지가 왜 75열이고 -
2026-08-19 · 12 분 읽기 #linux#kernel#patch#git-send-email#checkpatch커널 C는 응용 C가 아니다 — 메모리 할당과 동시성의 규칙
문법은 같은 C인데 규칙이 다릅니다. 커널에서는 어떤 함수를 어디서 부를 수 있는지가 문맥에 따라 갈리고, 그 규칙을 어기면 컴파일은 통과하고 대신 시스템이 멈춥니다. 이 글은 그 규칙들을 공식 문서 기준으로 정리합니다. 먼저 스택이 사용자 공간의 수백분의 일이라는 사실에서 출발해, kmalloc과 vmalloc과 kvmalloc이 언제 갈리는지, GFP 플래그가 실제로 무엇을 허용하고 금지
2026-08-19 · 31 분 읽기 #linux#kernel#kmalloc#gfp#spinlock커널 공부는 어디서 시작하는가 — 4,300만 줄 앞에서 길을 잃지 않는 법
리눅스 커널을 공부하겠다고 마음먹은 사람이 가장 먼저 부딪히는 것은 개념이 아니라 규모입니다. 실제로 트리를 받아 세어 본 숫자로 커널이라는 코드베이스가 어떤 물건인지 먼저 보여 주고, 그중 몇 퍼센트를 평생 열어 볼 일이 없는지 정직하게 짚습니다. 그다음 현실적인 진입 경로를 읽기·관측·기여 세 갈래로 나눠 각각이 누구에게 맞는지, 왜 처음부터 순서대로 읽겠다는 계획이 거의 항상 실패하는지
2026-08-19 · 30 분 읽기 #linux#kernel#kernel-source#learning#c