소스 코드 & 아키텍처
Designing Defaults That Fail Safely
A practical reflection on choosing defaults that protect users and systems when configuration, rollout, or external dependency behavior is uncertain.
글
소스 코드 & 아키텍처
성장과 팀 규모, 변화를 견딜 수 있도록 소스 코드를 구조화하는 방법.
소프트웨어 아키텍처와 소스 코드 조직에 관한 실용적이고 초보자 친화적인 심층 분석 — Ports & Adapters, Clean Architecture부터 의존성 관리, 모듈 경계, 각 선택지에 따른 트레이드오프까지. 다이어그램, 실제 예제, 그리고 개인 프로젝트부터 엔터프라이즈 시스템까지 적용할 수 있는 교훈을 바탕으로 작성되었습니다.
소스 코드 & 아키텍처
Keeping Data Contracts Small Enough to Trust
A practical reflection on designing data contracts that are narrow, testable, and stable enough for teams to rely on.
소스 코드 & 아키텍처
Choosing Boring Boundaries on Purpose
A practical reflection on choosing simple software boundaries that make ownership, testing, and future change easier to reason about.
소스 코드 & 아키텍처
Designing With Escape Hatches, Not Back Doors
A practical reflection on building safe operational escape hatches that are explicit, audited, and bounded instead of hidden back doors.
소스 코드 & 아키텍처
Making Interfaces Honest About System Limits
A practical reflection on designing interfaces that show real system limits before users and operators have to discover them through failure.
소스 코드 & 아키텍처
Designing for the Change You Can Actually See
A practical reflection on designing software around visible change patterns instead of abstract future flexibility that may never arrive.
소스 코드 & 아키텍처
When Boundaries Need Examples More Than Names
A practical reflection on why software boundaries become clearer when teams anchor them in examples, responsibilities, and behavior instead of only naming layers.
소스 코드 & 아키텍처
Keeping Architecture Decisions Small Enough to Revisit
A practical reflection on making architecture decisions small, explicit, and revisitable so teams can learn without turning every choice into a permanent monument.
소스 코드 & 아키텍처
Designing Interfaces That Outlive Implementations
A practical reflection on designing software interfaces that keep product behavior stable while implementations change underneath.
소스 코드 & 아키텍처
Refactoring Toward a Clearer Core
A practical reflection on refactoring toward a clearer core: how teams can reduce coupling, protect behavior, and make the center of a codebase easier for future teammates to understand.
소스 코드 & 아키텍처
Architecture Decisions for Future Teammates
A practical reflection on architecture decisions as team memory: how small ADR-style notes help future teammates understand trade-offs, rejected paths, and when to revisit a choice.
소스 코드 & 아키텍처
Choosing Boundaries Before Choosing Tools
A practical reflection on architecture boundaries: why teams should name ownership, data, and change patterns before reaching for frameworks, services, queues, or databases.
소스 코드 & 아키텍처
Observability as a Design Choice
A practical explanation of observability as an architecture decision: why teams should design logs, metrics, traces, dashboards, and alerts into the system before production asks hard questions.
소스 코드 & 아키텍처
The Outbox Pattern
A practical explanation of the Outbox Pattern: why dual writes fail, how a transactional outbox keeps database state and events aligned, and what teams still need to handle around retries, idempotency, ordering, cleanup, and observability.
소스 코드 & 아키텍처
Service Mesh: Do You Need It?
A practical explanation of service mesh trade-offs: what it centralizes, when it helps, and why teams should solve real service-to-service pain before adopting another infrastructure layer.
소스 코드 & 아키텍처
Event Sourcing: A Beginner's Guide
A beginner-friendly guide to Event Sourcing: storing facts as an append-only event history, rebuilding current state through projections, and understanding when the pattern is worth its operational cost.
소스 코드 & 아키텍처
The Saga Pattern for Distributed Transactions
A practical explanation of the Saga pattern for distributed transactions: why one database transaction stops working across services, how orchestration and choreography differ, and why compensation, observability, and idempotency matter.
소스 코드 & 아키텍처
API Gateway Patterns
A practical look at API gateway responsibilities: routing, authentication boundaries, rate limiting, request aggregation, backend-for-frontend trade-offs, failure modes, and the observability needed to keep the edge of a system understandable.
소스 코드 & 아키텍처
Hexagonal Architecture in Practice
A practical guide to applying Hexagonal Architecture to one small feature: drawing the boundary, naming ports in business language, keeping adapters at the edge, testing the core, and deciding when the extra structure is worth the cost.
소스 코드 & 아키텍처
Events, Queues, and the Art of Not Calling Each Other: Event-Driven Architecture, Explained
When services hold hands through synchronous calls, latency adds up and one slow dependency takes down checkout. A no-hype guide to event-driven architecture: sync vs async, commands vs events, what brokers really promise (at-least-once, not exactly-once), choreography vs orchestration, and exactly when NOT to reach for events.
소스 코드 & 아키텍처
Who Owns the Data? Database-per-Service, Sagas, and Eventual Consistency Without Tears
Splitting code is the easy half — splitting data is where distributed systems humble you. A practical guide to owning data across services: why a shared database is a distributed monolith, the trade from ACID to eventual consistency, the dual-write bug and the outbox that fixes it, sagas with compensating actions, and when CQRS and event sourcing are worth their lifetime cost.
소스 코드 & 아키텍처
The Distributed-Systems Tax, Paid: Timeouts, Retries, Circuit Breakers, and Idempotency
The moment a call leaves your process it can be slow, fail, or happen twice — and that is the normal case, not the exception. The resilience toolkit, explained plainly: why timeouts come first, how retries become a self-inflicted DDoS without backoff and jitter, why idempotency is the price of retrying, and how circuit breakers, bulkheads, graceful degradation, and observability keep one bad dependency from taking down everything.
소스 코드 & 아키텍처
Scaling the Database: Indexes, Read Replicas, Caching, and Sharding — In That Order
The database is almost always the first thing to buckle under growth — and the first thing engineers over-engineer in a panic. A no-hype ladder for scaling the data layer: why you measure and add an index before touching hardware, how read replicas exploit the read/write asymmetry (and the replication-lag trap they bring), where caching helps and why invalidation is the hard part, and when you finally reach for partitioning and sharding — the one decision that is genuinely hard to undo.
소스 코드 & 아키텍처
You Can't Fix What You Can't See: Logs, Metrics, Traces, and SLOs at Scale
In a monolith, debugging was almost cosy — one log file, one process, one place the truth lived. Distributed systems quietly took that away: one request now fans out across a dozen services, and when it breaks there is no single log to read. A no-hype guide to seeing your system at scale: the three pillars (metrics, logs, traces) and the question each one answers, why a single propagated trace ID is the highest-leverage habit you can adopt, how SLOs turn reliability into an error budget you can spend, and how to alert on symptoms so on-call doesn't burn out.
소스 코드 & 아키텍처
The True Cost of Microservices
Microservices can create real team autonomy, but they move cost into operations, data consistency, observability, testing, and coordination. This piece asks when that cost is worth paying and when a modular monolith is the kinder architecture.
소스 코드 & 아키텍처
Ports & Adapters (Hexagonal Architecture), 쉽게 이해하기
Hexagonal Architecture를 친근하고 예제 중심으로 설명하는 가이드: port와 adapter가 실제로 무엇인지, 이 아키텍처를 작동시키는 단 하나의 규칙, 그리고 1인 창업자든 엔터프라이즈 팀이든 딱 얼마나 적용해야 하는지.
소스 코드 & 아키텍처
Clean, Onion & Hexagonal Architecture: 하나의 북극성, 세 가지 이름
세 가지 경쟁 아키텍처처럼 보이지만, 사실은 같은 아이디어를 세 가지 방식으로 그린 것입니다 — 의존성은 안쪽을 향하고, 프레임워크는 가장자리에. 각각이 실제로 무엇을 더하는지, 그리고 어떤 상황에 어느 것을 선택해야 하는지 알아봅니다.
소스 코드 & 아키텍처
Dependency Injection & Inversion of Control, 마법 없이 이해하기
DI 컨테이너는 밑에 있는 단순한 아이디어를 보기 전까지 마법처럼 느껴집니다: 코드가 자신의 의존성을 직접 생성하지 않도록 하고, 대신 외부에서 전달받는 것입니다. 실제 예제와 테스트에서 얻을 수 있는 이점을 포함한 처음부터 끝까지의 가이드.
소스 코드 & 아키텍처
코드베이스 구조화: 레이어별, 기능별, 또는 도메인별?
최상위 폴더가 controllers/services/models여야 할까요, 아니면 orders/billing/auth여야 할까요? 이 선택은 조용히 코드베이스의 성장 방식을 결정합니다. 레이어별, 기능별, 소리치는 아키텍처의 실용적인 여행 — 각 회사 규모별 트레이드오프와 함께.
소스 코드 & 아키텍처
모놀리스, Modular Monolith, 마이크로서비스: 솔직한 의사결정 가이드
마이크로서비스는 출발점이 아니라 조직 규모에 대해 지불하는 세금입니다. 모놀리스에서 Modular Monolith, 마이크로서비스까지의 과장 없는 여정 — 언제(그리고 분리할지 여부를) 알려주는 신호와 함께.
소스 코드 & 아키텍처
마이크로 프론트엔드: 언제 가치가 있고, 무엇이 드는가
프론트엔드를 독립적으로 배포 가능한 조각들로 분리하면 팀을 해방시킬 수도 — 또는 복잡성에 묻힐 수도 있습니다. Angular 호스트 + React 모듈 설정을 규모에서 출시한 경험을 바탕으로: 마이크로 프론트엔드가 보상을 줄 때, 그리고 그것이 가져오는 청구서.
소스 코드 & 아키텍처
레이어드 아키텍처와 Vertical Slice Architecture
레이어드 구조는 처음에는 깔끔해 보이고, vertical slice 는 변경을 실제 기능 가까이에 둡니다. 두 방식의 장점과 비용, 그리고 팀이 언제 방향을 바꿔야 하는지 차분히 살펴봅니다.
소스 코드 & 아키텍처
Dependency Direction in Plain Language
Dependency direction is the simple team rule that says stable business ideas should not depend on volatile delivery details. This explainer uses a small release scenario to show how the rule keeps code, reviews, and team conversations calmer.
소스 코드 & 아키텍처
Eventual Consistency in the Real World
A practical explanation of eventual consistency beyond the textbook definition: what users notice, which trade-offs teams are really making, how to set expectations in the product, and how operations keeps delayed truth from becoming silent data drift.
소스 코드 & 아키텍처
CQRS: Command Query Responsibility Segregation
A practical explanation of CQRS: separating commands from queries, when read and write models deserve different shapes, and how to avoid turning a useful pattern into unnecessary architecture.
소스 코드 & 아키텍처
Serverless: Trade-offs and Truths
A practical look at serverless architecture: what teams gain by handing infrastructure to managed platforms, what they still own, and how to decide when functions, queues, and managed services are the right trade.
소스 코드 & 아키텍처
Caching Strategies and Pitfalls
A practical explanation of caching strategies: where caches help, how cache-aside, read-through, write-through, TTLs, and invalidation differ, and why stale data, stampedes, keys, and observability matter as much as speed.
소스 코드 & 아키텍처
Database Sharding: When and Why
A practical explanation of database sharding: what changes when one database is split into smaller partitions, when sharding is worth the operational cost, and why shard keys, hotspots, rebalancing, and observability matter.
소스 코드 & 아키텍처
GraphQL vs. REST
A practical comparison of GraphQL and REST: how each shapes API contracts, frontend flexibility, caching, observability, team ownership, and the operational trade-offs behind choosing one style over the other.
소스 코드 & 아키텍처
Designing Idempotent APIs
A practical explanation of idempotent API design: why retries happen, how duplicate requests create risk, and how idempotency keys, stable state transitions, and clear response contracts make distributed systems calmer.
소스 코드 & 아키텍처
Rate Limiting and Throttling
A practical explanation of rate limiting and throttling: how systems protect shared capacity, shape traffic, communicate limits clearly, and keep overload from turning into a full outage.