«A Philosophy of Software Design» 19~21장으로 8부작을 맺습니다. struct embedding 으로 흉내 낸 구현 상속에서 ‘덮어쓴’ 메서드가 부모의 호출에는 적용되지 않는 함정을 재현하고 인터페이스 합성으로 바꾸며, 저자의 TDD 비판을 공정하게 옮기고 반론을 덧붙입니다. 20장의 RAMCloud Buffer 예제를 Go 로 옮겨 ‘측정 먼저’ 를 실제로 해 본 결과는 책의 2배가 아니라 10% 였고, 그 숫자를 그대로 싣습니다. 마지막으로 시리즈 전체를 위험 신호 표 하나로 정리합니다.

«A Philosophy of Software Design» 16~18장을 Go 코드로 읽습니다. 경로 탈출 버그를 Save 한 곳에만 땜질해서 Load 와 Delete 에 구멍을 남기는 수정과, ID 타입을 도입해 세 함수를 한 번에 막는 수정을 비교하고, ‘없음’ 을 네 가지 방식으로 표현하는 저장소를 한 가지로 통일하며, 제네릭 Pair 의 First·Second 를 이름 있는 struct 로 바꾸고, 이벤트 버스 뒤에 숨은 호출 흐름을 직선으로 펴는 과정을 Before → After 로 보여 줍니다. gofmt 가 이 책의 17장을 언어 차원에서 구현한 것이라는 이야기도 합니다.

«A Philosophy of Software Design» 12~15장을 Go 코드로 읽습니다. 이름을 그대로 풀어 쓴 주석을 단위와 경계 조건을 채운 주석으로 바꾸고, 저자가 6개월을 쏟은 Sprite 의 block 버그를 Go 의 named type 으로 컴파일 시점에 잡아내며, 14.5절에서 저자가 Go 스타일 가이드와 갈라서는 지점을 양쪽 논거 그대로 싣습니다. 여섯 줄짜리 주석 없이는 설명할 수 없던 Search 함수를 주석부터 다시 써서 설계를 고치는 과정도 보여 줍니다.

«A Philosophy of Software Design» 10장을 Go 코드로 읽습니다. 예외가 없는 Go 에서 이 장은 ‘if err != nil 을 어떻게 줄이는가’ 라는 질문이 됩니다. 없는 노트를 지우면 에러를 내던 Delete 를 ‘없는 상태로 만든다’ 로 재정의해 시그니처에서 error 를 지우고, 범위 밖이면 패닉하던 Snippet 을 항상 정의되는 함수로 바꾸고, 짧은 읽기를 io.ReadFull 로 감추고, 핸들러마다 반복되던 http.Error 를 한 곳으로 모으고, nil 검사를 부르던 ‘선택 없음’ 을 빈 선택으로 없앱니다. 저자가 Tcl 의 unset 을 설계 실수로 꼽는 이유와, 이 원칙을 지나치게 밀면 어떻게 되는지도 함께 봅니다.

«A Philosophy of Software Design» 9장과 11장을 Go 코드로 읽습니다. ‘20줄 넘으면 나눠라’ 를 따르느라 공유 상태 구조체를 주고받는 함수 다섯 개가 된 임포트 코드를 하나로 되돌리고, 텍스트 타입 안에 커서 undo 까지 끌어안은 설계를 범용 History 와 특수 목적 Action 으로 갈라내며, 줄 단위·범위 단위 두 인터페이스를 둘 다 Go 로 써 보고 상위 코드의 길이로 판정합니다. 책이 Clean Code 와 갈라서는 지점도 이 장에 있습니다.

«A Philosophy of Software Design» 6~8장을 Go 코드로 읽습니다. 백스페이스 키마다 메서드를 하나씩 둔 텍스트 타입을 Insert 와 Delete 두 개로 줄이면서 여러 줄 선택 삭제가 공짜로 생기는 과정, 다섯 메서드 중 넷이 저장소를 그대로 부르는 ‘서비스 계층’ 을 걷어내는 과정, 함수 네 단계를 관통하는 pass-through 인자를 App 구조체로 거두는 과정, 그리고 재시도 간격을 설정값으로 떠넘기는 대신 응답 시간을 재서 스스로 정하게 만드는 과정을 Before → After 로 보여 줍니다. Go 의 context.Context 가 책의 context 와 다른 이유도 짚습니다.

«A Philosophy of Software Design» 4~5장을 Go 코드로 읽습니다. 객체 세 개를 조립해야 노트 하나를 읽을 수 있는 얕은 모듈을 함수 하나짜리 깊은 모듈로 바꾸고, 내부 map 을 그대로 돌려주는 인터페이스가 어떻게 정보를 누출하는지, ‘읽고 나서 파싱한다’ 는 시간적 분해가 왜 같은 지식을 두 곳에 복사하게 만드는지를 실제로 컴파일되는 Before → After 로 보여 줍니다. go doc 출력 줄 수로 인터페이스 크기를 세는 방법도 소개합니다.

존 오스터하우트의 «A Philosophy of Software Design» 을 Go 코드로 다시 읽는 8부작의 첫 편입니다. 책이 말하는 복잡성의 세 가지 증상(변경 증폭·인지 부하·모름)과 두 가지 원인(의존성·모호성)을 각각 Before → After Go 코드로 보여 주고, 전술적 땜질이 어떻게 쌓이는지와 전략적 수정이 무엇을 다르게 하는지를 같은 버그 하나로 비교합니다. Go 가 이 책과 어디서 부딪히는지도 미리 밝혀 둡니다.

Pragmatic Programmers 뉴스레터 “Big Design Up Front: Still a Bad Idea"의 한국어 번역. 1990년대 소프트웨어 위기를 불러왔던 BDUF의 전제가 바이브 코딩과 에이전틱 루프에서 그대로 반복되고 있다는 이야기입니다.

에이전트가 코드를 대신 쓰는 시대에 어떤 개발방법론이 살아남고 어떤 것이 의미를 잃었는지, Kent Beck, Birgitta Böckeler, Simon Willison 등이 2025-2026년에 남긴 1차 자료를 바탕으로 정리합니다.

웹서비스 내부 코드 구조를 설계할 때 고려할 수 있는 주요 아키텍처들을 소개합니다. Part 2에서는 Event-Driven Architecture, Vertical Slice Architecture, Modular Monolith를 다루고, 여섯 가지 아키텍처의 비교와 선택 기준을 정리합니다.

웹서비스 내부 코드 구조를 설계할 때 고려할 수 있는 주요 아키텍처들을 소개합니다. Part 1에서는 Layered Architecture, Ports & Adapters 계열(Hexagonal, Onion, Clean), CQRS를 다룹니다.

이 포스트는 Vertical Slicing Architecture와 Hexagonal Architecture의 개념과 특징을 단순히 나열하는 것을 넘어, 두 아키텍처의 근본적인 설계 철학, 해결하고자 하는 핵심 문제, 그리고 실제 프로젝트에 적용했을 때 발생하는 트레이드오프를 심층적으로 분석하는 것을 목표로 합니다. 각 아키텍처의 태동 배경, 장단점, 이상적인 적용 시나리오를 비교 분석하고, 실제 적용 사례를 통해 이론이 현실에서 어떻게 구현되는지 살펴볼 것입니다. 최종적으로는 독자들이 자신의 프로젝트 맥락과 당면 과제에 가장 적합한 아키텍처를 정보에 입각하여 선택할 수 있도록 실질적인 통찰과 가이드를 제공하고자 합니다.

본 연구 보고서는 오스터하우트와 마틴이 제시하는 두 가지 상이한 소프트웨어 설계 철학을 심층적으로 비교 분석하는 것을 목표로 한다. 두 철학은 단순히 기법의 차이를 넘어, 문제의 정의 자체에서부터 근본적인 시각차를 드러낸다. 오스터하우트는 시스템적 복잡성을 주된 적으로 간주하며, 이를 인지 부하(cognitive load)와 변경 증폭(change amplification)이라는 구체적인 지표로 측정한다. 반면, 마틴은 코드의 지역적 불명확성을 가장 경계해야 할 대상으로 보며, 이를 가독성(readability)과 이해 용이성(ease of comprehension)으로 평가한다.

존 오스터하우트의 ‘소프트웨어 설계의 철학’은 소프트웨어 복잡성을 줄이고 유지 관리가 용이한 코드를 작성하는 방법에 대한 심도 있는 통찰력을 제공합니다. 21개 챕터에 걸쳐 저자는 복잡성의 본질을 분석하고, 효과적인 모듈 설계를 위한 원칙을 제시하며, 코드의 가독성과 명확성을 높이는 구체적인 기법들을 소개합니다.