Software-Design on philipjkim

번역글: Big Design Up Front — 여전히 나쁜 생각입니다

Tue, 28 Jul 2026 14:23:37 +0900

이 글은 Claude Opus 5 를 이용해 번역되었으며, 이후 퇴고를 거쳤습니다.

원문: Pragmatic Programmers Newsletter — “Big Design Up Front: Still a Bad Idea”

우리는 1990년대의 소프트웨어 위기를 불러왔던 그 관행을 그대로 되풀이할 위험에 처해 있습니다.

40년 전, 도구와 하드웨어가 발전하면서 우리는 점점 더 큰 시스템을 만들 수 있게 됐습니다. 더 야심 차고, 범위도 넓고, UI도 화려한 시스템들이었습니다. 짜릿한 시절이었습니다.

하지만 문제가 있었습니다. 시스템이 복잡해질수록 프로젝트는 점점 더 실패했습니다. 일정 추정은 웃음이 나올 만큼 빗나갔고, 기능은 잘려나갔고, 버그는 넘쳐났습니다. 프로젝트는 납품되는 만큼이나 자주 취소됐습니다. 2000년 무렵에는 여섯 개 중 하나 정도만 일정과 예산에 근접하게 마무리됐습니다.

Agentic Coding 시대의 개발방법론 — 더 중요해진 5가지, 무용해진 5가지

Tue, 28 Apr 2026 12:40:28 +0900

이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며: 사라진 것이 아니라 재배치되었다

2025년 한 해를 거치면서 백엔드 개발자가 키보드 앞에서 보내는 시간의 모양이 크게 달라졌습니다. Claude Code, Cursor, Codex 같은 에이전트가 대부분의 코드를 직접 작성하고, 사람은 명세를 다듬고, 결과를 검증하고, 다음 작업을 지시하는 시간이 길어졌습니다. Stack Overflow의 2025 Developer Survey는 응답자의 66%가 almost-right AI code 를 고치는 데 더 많은 시간을 쓰고 있다고 답했습니다.

이 변화 앞에서 가장 자주 듣는 잘못된 결론이 “이제 SW 엔지니어링 방법론은 다 의미가 없어졌다” 입니다. 하지만 2025년 하반기에서 2026년 초까지 Kent Beck, Birgitta Böckeler, Simon Willison, Armin Ronacher, Steve Yegge처럼 실제로 에이전트와 매일 일하는 시니어 엔지니어들이 남긴 글을 읽어 보면 정반대 그림이 보입니다. 방법론이 사라진 것이 아니라, 어떤 것은 더 중요해지고 어떤 것은 의미를 잃는 형태로 재배치되었습니다.

웹서비스 내부 구조 아키텍처 가이드 Part 2: EDA, VSA, Modular Monolith

Thu, 12 Mar 2026 10:07:30 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1에서는 Layered Architecture, Ports & Adapters 계열(Hexagonal/Onion/Clean), CQRS를 다뤘습니다. Part 2에서는 나머지 세 아키텍처와 전체 비교를 다룹니다.

4. Event-Driven Architecture (EDA)

개요

Event-Driven Architecture는 시스템 구성 요소 간의 통신을 이벤트를 통해 수행 하는 설계 패턴입니다. 컴포넌트가 서로 직접 호출하는 대신, “무언가가 발생했다"는 사실을 이벤트로 발행하면, 관심 있는 컴포넌트가 이를 구독하여 반응합니다.

이 글의 전제가 Kafka/RabbitMQ 같은 메시지 브로커를 포함하는 환경이므로, EDA를 내부 구조 패턴으로 다루는 것은 매우 자연스럽습니다. 메시지 브로커가 있다는 것 자체가 이미 이벤트 기반 통신의 인프라를 갖추고 있다는 뜻이기 때문입니다.

웹서비스 내부 구조 아키텍처 가이드 Part 1: Layered, Ports & Adapters, CQRS

Thu, 12 Mar 2026 10:07:29 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

이 글은 웹서비스를 전제로 합니다. 구체적으로는 HTML/CSS/JS 프런트엔드, REST/gRPC 기반 백엔드, RDB/Redis/NoSQL 저장소, Kafka/RabbitMQ 같은 메시지 브로커가 있는 환경을 상정합니다.

비교 대상은 “배포 아키텍처"가 아닙니다. 마이크로서비스냐 모놀리스냐의 문제가 아니라, 애플리케이션 내부 코드를 어떻게 나누고, 의존성을 어느 방향으로 흐르게 하며, 변경을 어떤 단위로 흡수할 것인가 에 관한 내부 구조 아키텍처입니다. Microsoft도 논리적 계층(layer)과 물리적 계층(tier)을 구분하며, 논리적 계층 분리가 반드시 별도 서버 분리를 의미하지는 않는다고 설명합니다.

아키텍처 비교: VSA vs. Hexagonal Architecture

Mon, 22 Sep 2025 14:14:05 +0900

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

깊은 모듈 대 작은 함수: 오스터하우트와 마틴의 소프트웨어 설계 철학 및 커뮤니티 수용에 대한 비교 분석

Mon, 01 Sep 2025 15:49:15 +0900

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

Ousterhout 와 Martin 의 소프트웨어 설계 철학의 공통점, 차이점 및 충돌 부분에 대한 여러 의견과 관점들에 대해 gemini 2.5 pro 에게 요청한 연구 결과입니다.

책 소개: 소프트웨어 설계의 철학

Mon, 04 Aug 2025 18:13:51 +0900

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

아래 내용은 Gemini 의 연구 결과에 약간의 퇴고를 거친 것입니다.

서론: 복잡성과의 전쟁

존 오스터하우트의 저서 “소프트웨어 설계의 철학(A Philosophy of Software Design)“은 소프트웨어 개발의 가장 근본적인 한계가 성능이나 기능이 아니라, 우리가 만든 시스템을 우리 스스로 이해하는 능력에 있다는 주장으로 시작합니다.[1, 2] 이 책의 전체 철학은 단 하나의 적, 즉 복잡성(complexity) 에 맞서기 위한 일련의 전략들로 구성되어 있습니다.[3, 4, 5, 6]