백엔드 설계 에 정답 은 거의 없다. 있는 건 트레이드오프 다. “이게 맞나요?” 의 답 은 대부분 “무엇 을 포기 할 건데요?” 로 되물어야 한다. 이 글 은 백엔드 설계 결정 을 세 개 의 축 으로 압축 해서, 각 축 을 실제 시스템 사례 로 풀어본다.

백엔드 설계 세 축 — 성능↔복잡도 / 결합도↔일관성 / 가역성↔속도

AXIS 01 — 성능 ↔ 복잡도

빠르게 가려면 복잡해진다. 단순하면 느려진다.

성능 을 얻는 거의 모든 기법 은 복잡도 라는 청구서 를 남긴다. 대표 가 캐시 다.

  • 캐시 를 넣으면 빠르다 — 대신 무효화(invalidation) · TTL · stale 데이터 가 따라온다. “캐시 무효화” 는 컴퓨터과학 의 2 대 난제 로 불릴 만큼 골치 아프다.
  • 매번 쿼리 하면 느리다 — 대신 머릿속 에 있는 모델 그대로 다. 캐시 계층 이 없으니 버그 도 그만큼 적다.

정산 시스템 에서 나 는 대시보드 에 Caffeine 캐시 를 쓰되, @CacheEvict 로 세션 시작·완료 시점 에 무효화 를 건다. 즉 캐시 를 넣는 순간 “언제 무효화 할지” 라는 복잡도 를 떠안은 것.

기본값: 실측 숫자 가 없으면 — 단순 쪽. “느릴 것 같아서” 미리 캐시 를 까는 건 대개 조기 최적화. 측정 해서 진짜 느릴 때 복잡도 를 산다.

AXIS 02 — 결합도 ↔ 일관성

느슨하게 쪼개면 자유롭다. 그런데 데이터 가 어긋난다.

MSA·이벤트 기반 은 결합 을 푸는 대신 일관성 을 양보 한다. 핵심 은 동기 호출 vs 이벤트 다.

  • 동기 호출 — 한 트랜잭션 에 묶이니 강한 일관성. 대신 한쪽 이 죽으면 같이 죽는다(강결합).
  • 이벤트(비동기) — 한쪽 이 죽어도 살아남는다. 대신 “결제 는 됐는데 알림 은 안 간” 순간 이 생긴다(최종 일관성).

이 선택 을 도메인 별 로 갈라야 한다. 정산 에서 나 는:

  • 결제·정산 확정 = 강한 일관성 — Outbox 로 같은 트랜잭션 에 이벤트 를 박제 하고, at-least-once + 3 단 멱등 으로 유실·중복 을 막는다. 돈 은 어긋나면 안 된다.
  • 알림·통계 = 이벤트 — 조금 늦거나 순서 가 바뀌어도 세상 안 무너진다. 여기 서 강결합 을 걸면 오히려 손해.

기본값: 돈 / 권한 / 정합성 = 동기. 알림 / 통계 = 이벤트. 정산 시스템 을 KPI 로 에서 다룬 Outbox 가 정확히 이 축 위 의 선택 이다.

AXIS 03 — 가역성 ↔ 속도 (가장 중요)

되돌리기 쉬운 결정 은 빨라도 된다. 되돌리기 어려우면 — 느려야 한다.

세 축 중 가장 중요 하다. 결정 의 속도 를 그 결정 의 가역성 에 맞춰야 하기 때문이다. 아마존 의 “one-way door vs two-way door” 와 같은 개념.

  • 캐시 추가 = 되돌리기 쉬움 → 30 분 회의 면 충분. 문제 생기면 캐시 끄면 원복.
  • DB 스키마 변경 = 되돌리기 어려움 → 2 주 RFC + ADR. 한 번 깨진(마이그레이션 된) 데이터 는 못 되돌린다.

나 는 이걸 도구 로 강제 한다:

  • 되돌리기 쉬운 것 — GitOps 로 빠르게. 잘못 되면 git revert 한 방(→ GitOps 안전성). feature flag 로 껐다 켰다.
  • 되돌리기 어려운 것 — Flyway 마이그레이션 은 신중하게. 파괴적 변경(컬럼 삭제·타입 변경) 은 ADR 로 근거 를 남기고, 단계적(add → backfill → switch → drop)으로.

기본값: 결정 의 무게 = 가역성 에 정비례. 되돌릴 수 있으면 빨리 결정 하고 실험 하라. 되돌릴 수 없으면 느리게, 문서(ADR) 를 남기고 가라. 속도 를 일률적 으로 밀어붙이는 게 가장 위험하다.

세 축 을 관통 하는 원칙

세 축 은 따로 노는 게 아니라 하나 의 태도 로 수렴 한다:

  1. 의심 되면 단순 쪽 (Axis 1) — 복잡도 는 나중에 사도 늦지 않다. 성능 은 측정 후에.
  2. 정합성 이 필요한 곳만 묶어라 (Axis 2) — 돈 은 동기, 나머지 는 이벤트. 전부 강결합 도, 전부 느슨함 도 틀렸다.
  3. 가역성 으로 속도 를 조율 하라 (Axis 3) — 되돌릴 수 있는 건 빠르게 실험, 못 되돌리는 건 느리게 결정.

결국 좋은 설계 는 “최고 의 선택” 이 아니라 “이 맥락 에서 무엇 을 포기 했는지 설명 할 수 있는 선택” 이다. 세 축 은 그 포기 를 의식적 으로 하게 만드는 좌표계다.

결론

“이 설계 맞나요?” 라는 질문 에 나 는 이제 세 축 으로 되묻는다:

  • 성능 을 위해 복잡도 를 살 만큼, 진짜 느린가? (측정 했나)
  • 이걸 강하게 묶어야 하나, 어긋나도 되나? (돈인가 알림인가)
  • 이 결정 은 되돌릴 수 있나? (그럼 빨리, 아니면 느리게)

정답 을 외우는 대신 좋은 질문 을 갖는 것 — 그게 설계 감각 이다. 그리고 이 세 축 은, 내가 매번 새 기능 을 설계 할 때 실제로 머릿속 에 펼치는 좌표계다.

설계 는 선택 이 아니라, 포기 를 설명 하는 일이다.