서론: “때때로 죽는다”라는 말의 의미 Stage 2를 시작할 때 던진 질문이 있었습니다. 스레드 두 개가 같은 변수를 쓰면 왜 프로그램이 때때로만 죽는가? 7편 OS 아키텍처, 8편 프로세스와 스레드, 9편 스케줄링을 거치면서 답의 절반에는 도착했습니다. OS가 스레드를 보이지 않는 곳에서 갈아끼우고 있고, 갈아끼우는 순간은 예측 불...

이 편이 다루는 것 시리즈 마지막 편입니다. 두 가지를 묶습니다. Part 1 — 작동 원리: 시리즈의 인프라가 가능한 메커니즘. 가정 NAT 두 겹 뒤의 노트북 두 대가 어떻게 직통으로 통신하는가. STUN·ICE·hole punching·DERP·MagicDNS를 한 묶음으로 정리합니다. Part 2 — 비용·한계·회고: 연 1만 원 인프...

이 편이 다루는 것 이 편은 부산 본가 노트북을 무인 24/7 exit node로 만드는 운영 전체를 한 번에 정리합니다. 작업은 세 단계로 나뉩니다. Phase 어디서 무엇을 1. 셋업 부산 본가 (1회 방문) install.ps1 한...

이 시리즈가 다루는 것 후쿠오카에서 1년 넘게 살면서 한국 IP가 아쉬운 순간이 꾸준히 쌓였습니다. 한국 결제·은행·일부 콘텐츠는 해외 IP에서는 정상 동작하지 않거나 추가 인증을 요구하고, 그때마다 상용 한국 VPN을 잠깐 켜는 패턴은 비용·신뢰·OS 호환 모두에서 깔끔하지 않았습니다. 해결책으로 부산 본가 창고에 7년째 처박혀있던 케케묵은 ...

서론: 박싱편이 남긴 복사 비용 1편(값 타입 vs 참조 타입과 Boxing)의 마지막에 한 가지 부채를 남겼습니다. “박싱은 피했지만 struct 자체의 복사 비용은 남는다.” 박싱편의 핵심 규칙 하나를 다시 적어 봅니다. 값 타입은 대입·전달·비교될 때 전체 내용이 복사됩니다. 이 규칙이 평소엔 직관적이고 바람직합니다. ...

서론: “스택 vs 힙”이라는 말은 왜 자꾸 어긋날까 C# 교과서의 첫 장에서 우리는 이렇게 배웁니다. “값 타입(struct)은 스택에, 참조 타입(class)은 힙에 저장됩니다.” 이 문장은 틀린 설명은 아니지만, 실무에서 만나는 거의 모든 반례를 가립니다. 클래스의 필드로 int를 선언하면 그 int는 스택이 아니라 객체가 사는 ...

서론: 같은 IL, 다른 운명 앞의 두 편에서 우리는 .NET 스택의 4층(Runtime)이 여러 구현체로 나뉜다는 사실을 확인했습니다. 이번 편은 그 구현체들을 하나씩 뜯어 비교합니다. 현재 시점에서 실무적으로 의미 있는 다섯 런타임은 다음과 같습니다. 런타임 소속 등장 상태 ...

서론 — Claude는 진짜 너프됐는가 Claude Opus 4.6은 한동안 코딩 작업의 기준선을 한 단계 끌어올렸다는 평을 받았습니다. Codebase 전체를 던져도 맥락을 잡고, 까다로운 리팩터링을 한 번에 끝내고, 도구 호출 사이의 추론도 깔끔했습니다. 그런데 2026년 2월부터 이상 신호가 누적되기 시작했습니다. 사고 깊이 73% 감소, ...

서론: 역사를 아는 것이 실용적인 이유 이 편은 세 가지 질문에 답하기 위한 글입니다. “.NET 4”는 왜 건너뛰어졌는가? — .NET Core 3.1 다음 버전이 왜 4가 아니라 5인가? “Core”는 왜 이름에서 빠졌는가? — .NET Core 3.1은 있었는데 .NET Core 5는 왜 없는가? Unity는 왜 Mono 위에...

서론: “누가, 얼마나”의 문제 지난 편에서는 프로세스와 스레드가 무엇이고 OS가 그것을 어떻게 추상화하는지 보았습니다. 이제 자연스럽게 따라오는 질문이 있습니다. 준비 상태인 스레드가 100개 있는데 코어가 8개라면, OS는 누구에게 CPU를 줄까요? 그리고 얼마나 오래 줄까요? 이 두 질문에 답하는 것이 스케줄러 (Scheduler...