태그: #linux
GPU·LLM·MLOps·쿠버네티스, 그리고 마음가짐에 관한 글 · 90 편
#linux 태그가 붙은 글은 90편이고, 가장 최근 글은 2026-08-19에 올라왔습니다.
함께 자주 붙은 태그: #kernel 29 #performance 14 #cgroups 13 #kubernetes 11 #2026-03 10
최근 90일 동안 많이 읽힌 글:
커널을 빌드하고 부팅하기 — 내 노트북 말고 VM에서
커널을 직접 빌드해 본 사람과 그렇지 않은 사람 사이에는 넘기 힘든 선이 하나 있습니다. 이 글은 그 선을 넘는 절차를 처음부터 끝까지 정리합니다. defconfig와 menuconfig와 localmodconfig가 각각 무엇을 해 주는지, .config 파일이 실제로 무엇을 통제하는지, 디버그 심볼이 빌드 시간과 디스크를 어떻게 잡아먹는지, 그리고 병렬 빌드 옵션이 어디서 한계에 부딪히는
2026-08-19 · 28 분 읽기 #linux#kernel#kbuild#kconfig#qemu커널을 관측하고 디버깅하기 — 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커널 모듈 작성 — 가장 작은 모듈부터 파라미터와 GPL 심볼까지
앞의 네 편이 남의 코드를 읽는 일이었다면 이 글부터는 커널 안에서 실행되는 코드를 직접 씁니다. 로드되기만 하는 가장 작은 모듈을 먼저 만들고, 그것이 왜 그 형태여야 하는지를 moduleinit과 MODULELICENSE의 실제 정의를 열어 확인합니다. 트리 밖에서 모듈을 빌드하는 Makefile은 커널 공식 문서의 예제를 그대로 따라가고, insmod와 rmmod와 modinfo와 ls
2026-08-19 · 27 분 읽기 #linux#kernel#kernel-module#kbuild#printkRHEL 폐쇄망 설치가 어려운 진짜 이유 — 의존성은 그래프이고, 그 그래프는 안쪽에서 풀 수 없습니다
금융·공공·국방 폐쇄망에 RHEL 패키지를 반입해 설치할 때 왜 "rpm 파일 하나 복사"로 끝나지 않는지를 구조부터 정리합니다. RPM 의존성이 목록이 아니라 심볼 단위 그래프라는 점, 그 그래프를 푸는 depsolver가 저장소 메타데이터를 필요로 하는데 폐쇄망 안에는 그 메타데이터가 없다는 점, 그래서 문제가 "파일 옮기기"가 아니라 "해결된 트랜잭션을 통째로 옮기기"가 된다는 점을 짚
2026-08-14 · 16 분 읽기 #linux#rhel#air-gap#dnf#rpm폐쇄망에서 모듈과 버전 고정 — RHEL 8·9·10이 서로 다른 이야기를 합니다
RHEL 8의 모듈러리티가 폐쇄망에서 정확히 어디서 꼬이는지, 그리고 RHEL 9와 RHEL 10에서 그 이야기가 어떻게 달라지는지를 공식 문서 기준으로 갈라 정리합니다. 핵심은 모듈러 RPM을 그냥 복사해서 만든 로컬 저장소에서는 그 패키지들이 조용히 보이지 않게 된다는 점입니다. dnf가 모듈 메타데이터로 RPM을 필터링하기 때문인데, 해법은 reposync에 --download-meta
2026-08-14 · 15 분 읽기 #linux#rhel#air-gap#dnf#modularity폐쇄망 안에 로컬 저장소 만들기 — createrepo_c, repodata, .repo 파일과 GPG 키
반입한 rpm 묶음을 폐쇄망 안에서 정상적인 dnf 저장소로 만드는 전 과정을 다룹니다. createrepoc가 만들어 내는 repodata 디렉터리의 구조와 repomd.xml의 역할, 패키지를 추가했을 때 --update로 증분 갱신하는 법, 그리고 체크섬 타입과 메타데이터 압축 옵션을 공식 man 페이지 기준으로 정리합니다. 이어서 baseurl에 file 스킴을 쓰는 단일 서버 구성과
2026-08-14 · 15 분 읽기 #linux#rhel#air-gap#dnf#createrepo폐쇄망 반입 절차와 무결성 — 6개월 뒤에도 같은 설치가 나오는 번들 만들기
반입 매체에 무엇을 담고 무엇을 검증할지, 그리고 그 번들을 6개월 뒤에 다시 열었을 때 같은 결과가 나오게 만드는 방법을 정리합니다. 폐쇄망에서 서명 검증이 연결망보다 오히려 더 중요한 이유 — 나중에 온라인으로 대조할 수단이 사라진다는 점 — 을 먼저 짚고, rpm과 rpmkeys의 서명 검사 명령을 최신 man 페이지 기준으로 구분해 설명합니다. 이어서 재현 가능한 번들의 핵심인 매니페
2026-08-14 · 13 분 읽기 #linux#rhel#air-gap#rpm#gpg폐쇄망 반입을 위해 밖에서 받기 — dnf download, reposync, yumdownloader는 서로 다른 문제를 풉니다
인터넷이 연결된 장비에서 RHEL 패키지를 의존성까지 통째로 받아 폐쇄망에 반입하는 실제 절차를 명령 단위로 정리합니다. dnf download의 --resolve와 --alldeps가 정확히 무엇을 다르게 하는지, 왜 이미 설치된 패키지 때문에 의존성이 조용히 빠지는지, 그리고 --installroot로 빈 루트를 만들어 그 함정을 없애는 방법을 공식 문서 문장과 함께 다룹니다. 빈 ins
2026-08-14 · 15 분 읽기 #linux#rhel#air-gap#dnf#rpm폐쇄망 운영 플레이북 — 보안 패치를 따라가고, 롤백하고, CVE 지연을 관리하기
반입 절차가 완성된 다음의 이야기, 즉 폐쇄망을 몇 년간 굴리는 운영 편입니다. 먼저 폐쇄망에서 CVE 대응이 늦어지는 것이 팀의 게으름이 아니라 반입 주기라는 구조 때문임을 분명히 하고, 그 지연을 없앨 수 없다면 어떻게 측정하고 관리할지를 다룹니다. dnf updateinfo와 --security 계열 옵션으로 무엇이 밀려 있는지 세는 방법을 공식 문서 기준으로 정리하되, 반입 저장소에서
2026-08-14 · 19 분 읽기 #linux#rhel#air-gap#dnf#security폐쇄망 컨테이너 이미지 반입 — podman save와 skopeo는 다른 도구입니다
RPM 반입 절차가 자리를 잡고 나면 다음 요구는 거의 항상 컨테이너 이미지입니다. podman save와 skopeo copy 계열이 어떻게 다른지 — 하나는 로컬 저장소를 거치고 다른 하나는 레지스트리에서 레지스트리로 직접 옮긴다는 점 — 부터 정리하고, 여러 이미지를 한 번에 다루는 폐쇄망 미러링에는 왜 skopeo sync가 정답인지 공식 문서의 표현과 함께 설명합니다. 트랜스포트 표
2026-08-14 · 18 분 읽기 #linux#rhel#air-gap#podman#skopeo국내 개발 블로그 명글 큐레이션 1 — 백엔드와 인프라, 직접 열어 확인한 14편
한국어로 쓰인 백엔드와 인프라 글 중에서 설명이 구체적이고 재현 가능한 14편을 골라 소개합니다. Istio의 Sidecar와 ServiceEntry, Envoy의 서킷 브레이커와 라우팅, 프로메테우스 푸시 게이트웨이의 한계, JVM 메모리 구조와 GC, 클래스 패스 섀도잉, 카프카 파티션 증설 시 컨슈머 설정, 리눅스 서버를 60초 안에 파악하는 순서, HTTP Keep-Alive와 TCP
2026-08-12 · 24 분 읽기 #curation#큐레이션#backend#infra#istio느린 건 CPU가 아니라 시스템 콜 경로였다 — 폰을 서버로 만들며 배우는 것
CMF Phone 1을 개인 인프라 서버로 만든 사례를 통해 리눅스 호환 계층의 실제 비용이 어디에 붙는지 정리합니다. 저자는 postmarketOS 플래싱에 실패한 뒤 스톡 안드로이드를 유지하고 Termux를 호스트 제어 평면으로 삼았으며, 일반 웹 서비스는 PRoot로 충분했지만 Chromium 기반 워크로드만은 유저스페이스 변환 계층 때문에 남는 CPU에 도달하지 못했습니다. 해결은 코
2026-08-09 · 19 분 읽기 #linux#termux#chroot#proot#self-hostingConnection refused와 timeout의 차이 — TCP 수준에서 원인 좁히는 법
연결이 안 될 때 터미널이 돌려주는 메시지는 크게 두 갈래입니다. Connection refused는 상대가 RST를 돌려준 것이고, timeout은 보낸 SYN에 아무 응답이 없는 것입니다. 이 한 줄 차이가 프로세스 문제인지 경로 문제인지를 거의 결정합니다. tcpdump로 SYN과 RST를 직접 확인하는 법, SYN 재전송 간격으로 타임아웃 길이를 미리 계산하는 법, 리스너가 있는데도
2026-07-26 · 20 분 읽기 #network#tcp#troubleshooting#linux#kubernetes로드 애버리지가 CPU 사용률이 아닌 이유 — load average 24에 CPU는 30%일 때
uptime의 load average는 24를 넘겼는데 top의 CPU는 30%도 되지 않는 상황을 다룹니다. 리눅스의 로드 애버리지는 다른 유닉스와 달리 실행 대기(R) 태스크뿐 아니라 D 상태(uninterruptible sleep) 태스크까지 세기 때문에, 디스크나 NFS 대기만으로도 숫자가 치솟습니다. 세 숫자가 5초 샘플링과 지수이동평균으로 어떻게 만들어지는지, 코어 수로 나누는 관
2026-07-26 · 21 분 읽기 #linux#performance#load-average#psi#troubleshootingdig는 되는데 애플리케이션은 실패한다 — DNS 해석 순서부터 확인하는 법
dig로는 정상적으로 답이 오는데 애플리케이션만 이름을 못 찾는 상황은 버그가 아니라 구조입니다. dig와 nslookup은 /etc/hosts와 nsswitch.conf를 아예 거치지 않고 리졸버에 직접 질의하기 때문입니다. 애플리케이션이 실제로 밟는 경로를 nsswitch.conf부터 systemd-resolved 스텁 리졸버까지 따라가고, getent와 resolvectl로 같은 경로를
2026-07-26 · 21 분 읽기 #network#dns#linux#kubernetes#troubleshooting