모든 엔지니어는 결국 똑같은 벽에 부딪힙니다. 코드는 작동하지만, _시스템_이 작동하지 않는 상황 말이죠. 부하가 걸리면 요청이 타임아웃됩니다. 한 팀의 배포(deploy)가 다른 팀의 서비스를 망가뜨립니다. 새벽 2시에 왜 데이터베이스가 병목 현상(bottleneck)을 일으키는지 아무도 설명하지 못합니다. 그것은 코딩 문제가 아닙니다. 그것은 시스템 디자인 (system design) 문제입니다.

화이트보드 이론 대신 실제 사례를 통해, 2026년에 실제로 중요한 아키텍처 패턴들을 살펴보겠습니다.

모놀리스 (Monolith) vs 마이크로서비스 (Microservices): 모두가 틀리는 질문

인터넷은 이 문제를 이분법적인 선택으로 프레임화하는 것을 좋아합니다. 하지만 그렇지 않습니다. 진짜 질문은 이것입니다: 당신은 지금 당장 실제로 어느 정도의 독립적인 확장(scaling)과 배포(deployment)가 필요한가?

모놀리스는 레거시 실수(legacy mistake)가 아닙니다. 그것은 종종 올바른 시작점입니다.

// 잘 구조화된 모놀리스: 하나의 배포 단위, 명확한 내부 경계
// src/modules/orders/orderService.js
export async function createOrder(userId, items) {
...

위의 모든 것은 하나의 코드베이스, 하나의 배포 파이프라인(deploy pipeline), 하나의 데이터베이스에 존재합니다. 그것은 약점이 아닙니다. 시스템을 분리하고 나면 그리워하게 될 단순함입니다.

마이크로서비스는 팀들이 독립적으로 제품을 출시해야 하거나, 시스템의 한 부분이 나머지 부분과 매우 다른 확장(scaling) 요구 사항을 가질 때 그 복잡성을 정당화합니다.

// order-service (독립적 배포 단위)
app.post("/orders", async (req, res) => {
  const order = await createOrder(req.body);
...

  await reserveStock(event.orderId);
});

변화에 주목하세요: orderService가 inventoryService를 직접 호출하는 대신, 이들은 이벤트를 통해 통신합니다. 그러한 디커플링 (decoupling)이 마이크로서비스의 핵심 목적이며, 동시에 복잡성의 모든 근원(재시도(retries), 최종 일관성 (eventual consistency), 분산 트레이싱 (distributed tracing))이기도 합니다.

이벤트 기반 아키텍처 (Event-Driven Architecture): 기능으로서의 디커플링 (Decoupling)

서비스가 몇 개 이상이 되면, 서비스 간의 직접적인 HTTP 호출은 긴밀한 결합(tight coupling)의 망을 형성합니다. 이벤트 기반 디자인은 이를 뒤집습니다:

// 최소한의 이벤트 버스 추상화 (Kafka, SQS 또는 Redis Streams 기반)
class EventBus {
  async publish(topic, payload) {
...

데드 레터 큐 (Dead-letter queue)는 사람들이 생각하는 것보다 더 중요합니다. 분산 시스템 (distributed system)에서 장애는 예외적인 상황이 아니라 반드시 발생하는 일입니다. 첫 새벽 3시의 호출(page)을 받은 이후가 아니라, 첫날부터 장애를 고려하여 설계하십시오.

데이터베이스 계층: 대부분의 시스템이 실제로 무너지는 지점

대부분의 "시스템 디자인 (system design)" 실패는 서비스의 문제가 아니라 데이터의 문제입니다. 내재화할 가치가 있는 몇 가지 패턴은 다음과 같습니다:

읽기 집약적인 워크로드 (read-heavy workloads)를 위한 읽기 복제본 (Read replicas):

const writeDb = new Pool({ host: "primary.db.internal" });
const readDb = new Pool({ host: "replica.db.internal" });

...

데이터베이스 앞단의 캐싱 (Caching):

async function getProduct(productId) {
  const cached = await redis.get(`product:${productId}`);
  if (cached) return JSON.parse(cached);
...

여기서 캐시 무효화 (Cache invalidation)는 고전적이고 어려운 문제입니다. 쓰기 통과 무효화 (write-through invalidation)와 같이 더 스마트한 방식이 필요하기 전까지는, 5분간의 TTL (Time To Live) 설정은 투박하지만 정직한 도구입니다.

과잉 엔지니어링 (Overengineering) 없는 패턴 선택

제가 성급한 복잡성을 피하기 위해 활용해 온 대략적인 가이드입니다:

팀이 성장함에 따라 이러한 결정 사항들을 문서화하고 있다면, **software hub**를 조기에 구축할 가치가 있습니다. 아키텍처 결정 기록 (architecture decision records)은 Slack 스레드 속에서 빠르게 사라지기 마련이며, 각 패턴의 "이유 (why)"가 담긴 단일 저장소를 갖는 것은 6개월 뒤에 과거의 논쟁을 다시 반복하는 수고를 크게 줄여줍니다.

실질적인 절충안: 모듈형 모놀리스 (Modular Monolith)

마이크로서비스 (microservices)가 시기상조처럼 느껴지지만 엉망으로 뒤엉킨 모놀리스가 두렵다면, 검증된 절충안이 있습니다. 마치 이미 분리된 것처럼, 엄격한 내부 경계를 두어 모놀리스를 구조화하는 것입니다.

src/
  modules/
    orders/       # 자체 DB 테이블을 소유하며, 모듈 간 SQL 교차 사용 금지
...

// modules/orders/index.js — 이 모듈에 대한 유일한 공개 인터페이스 (public interface)
export { createOrder, getOrder, cancelOrder } from "./orderService.js";
// 이 폴더 외부에서는 그 외의 어떤 것도 가져올 (import) 수 없습니다.

이를 통해 분산 시스템 (distributed systems)의 운영 비용(operational tax)을 지불하지 않고도, 명확한 소유권(ownership)과 강제된 경계(enforced boundaries)와 같은 마이크로서비스 (microservices)의 규율 대부분을 얻을 수 있습니다. 나중에 실제로 모듈을 별도의 서비스로 분리해야 할 때 (만약 필요하다면), 경계는 이미 그려져 있을 것입니다.

## 마무리하며 (Wrapping Up)

좋은 시스템 디자인 (system design)은 가장 유행하는 패턴을 선택하는 것이 아닙니다. 팀 규모, 확장 요구 사항 (scaling needs), 일관성 요구 사항 (consistency requirements)과 같은 실제 제약 조건에 아키텍처 (architecture)를 맞추는 것입니다. 생각보다 더 단순하게 시작하세요. 나중에 모놀리스 (monolith)를 분리하는 비용은 실제로 존재하지만 관리 가능한 수준입니다. 하지만 분리할 필요가 없었던 시스템을 성급하게 분산시키는 비용은 되돌리기가 훨씬 더 어렵습니다.

_이 패턴들 사이의 트레이드오프 (trade-offs)에 대한 더 심도 있는 분석을 원하시나요? 서버리스 (serverless)와 엣지 컴퓨팅 (edge compute)이 결합되었을 때 이러한 아이디어들이 어떻게 전개되는지 확인하려면 저희의 *_[Serverless Architecture Guide](https://repackra.com/)*를 확인해 보세요.*