백엔드 아키텍처 로드맵 - 설계 원칙부터 분산 시스템까지
TL;DR
- 대상: 코드 구현을 넘어 시스템 전체를 설계하고 싶은 백엔드 개발자
- 범위: 클린 아키텍처, DDD, 이벤트 기반 설계, API 전략
- 목표: 트레이드오프를 이해하고 상황에 맞는 아키텍처를 선택하는 능력
좋은 아키텍처란 뭘까요?
정답은 없습니다. 다만 저는 “현재 팀 상황에서 최선의 트레이드오프를 선택하는 것”이라고 생각합니다.
화려한 기술 스택보다 중요한 건, 팀이 운영할 수 있고 비즈니스 요구사항에 맞는 구조를 만드는 겁니다. 이 허브에서는 제가 실무와 토이프로젝트에서 직접 적용해본 아키텍처 패턴들을 정리했습니다.
시리즈 목차
1. 소프트웨어 설계 철학
“돌아가는 코드”를 넘어 “유지보수 가능한 코드”를 지향합니다.
클린 아키텍처, “노트북과 여행용 어댑터”로 이해하기
비즈니스 로직이 외부 환경(DB, 프레임워크)에 너무 의존하고 있다면 읽어보세요.
- 핵심: 도메인(노트북)은 어댑터(변환 플러그)를 통해 외부 세계와 연결됨
- 실전 효과: H2 DB 없이도 테스트 가능 (5초 → 0.3초)
- 추천: Service가 JPA Repository에 직접 의존하는 구조가 불편해진 분
토이프로젝트로 시작하는 DDD - 도메인 주도 설계 첫걸음
“어디까지가 도메인 로직이고, 어디서부터가 애플리케이션 로직인가?”가 헷갈리셨다면.
- 핵심: 도메인 모델에 비즈니스 로직 담기, 값 객체(VO)로 개념 명확화
- 실전 효과: 상태 변경이 안전해지고, 오타로 인한 버그 방지
- 추천: Service 클래스가 비대해져서 고민인 분
2. 시스템 통합 & 확장
여러 외부 시스템을 통합하거나 확장 가능한 구조를 만들 때 필요한 패턴입니다.
멀티 벤더 IoT 연동 설계하기 (1편) - Adapter 패턴으로 통합하기
“새 제조사 추가할 때마다 기존 코드를 수정해야 하나요?” 싶을 때.
- 핵심: 제조사가 누구든 상관없는 인터페이스 설계
- 실전 효과: 신규 제조사 추가 시간 1-2주 → 2-3일
- 추천: 외부 API가 여러 개인데 각각 형식이 다른 상황인 분
멀티 벤더 IoT 연동 설계하기 (2편) - Event-Driven Architecture로 확장하기
“핵심 로직보다 부가 기능(알림, 로그, 통계)이 더 많아졌어요.”
- 핵심: 핵심 로직은 이벤트만 발행, 부가 기능은 리스너로 분리
- 실전 효과: API 응답 시간 800ms → 200ms (75% 감소)
- 추천: 서비스 클래스가 7-8개 의존성에 묶여있는 분
3. API & 통신 전략
프론트엔드 및 외부 시스템과의 효율적인 통신 방법을 고민합니다.
GraphQL vs REST, 실무에서의 선택 - 언제 뭘 써야 할까?
“필요한 필드만 받을 수 있으면 좋겠는데…” 요청을 받아보셨다면.
- 핵심: Over-fetching/Under-fetching 문제와 API 관리 복잡도 비교
- Trade-off: 유연성(GraphQL) vs 캐싱/단순성(REST)
- 추천: DTO 클래스가
UserSimpleResponse,UserDetailResponse… 로 늘어나는 분
정적 블로그에서 백엔드 통신하기 - 일반 웹과의 결정적 차이
“왜 Netlify Functions를 써야 하죠? 그냥 axios로 API 호출하면 안 되나요?”
- 핵심: 정적 사이트에서 API 키를 안전하게 보호하는 방법
- 기술: Netlify Functions (서버리스)로 백엔드 기능 구현
- 추천: Gatsby/Next.js SSG에서 외부 API를 호출해야 하는 분
준비 중인 주제
아직 정리 중인 글입니다. 완성되면 허브에 추가됩니다.
- 분산 트랜잭션 실전 가이드 (SAGA 패턴): MSA에서 2PC 없이 데이터 정합성 맞추기
- 분산 환경에서 데이터 정합성 챙기기: 웹훅만 믿었다가 당한 일, 멱등성 보장 전략
이 시리즈를 읽으면
- 비즈니스 로직을 외부 환경에서 분리하는 방법을 알게 됨
- 새로운 요구사항이 추가되어도 기존 코드를 수정하지 않는 구조를 설계할 수 있음
- 상황에 맞는 API 통신 방식을 선택할 수 있음
- 정적 사이트에서도 동적 기능을 안전하게 구현할 수 있음
읽는 순서 추천
| 관심사 | 추천 순서 |
|---|---|
| 아키텍처 입문 | 클린 아키텍처 → DDD → IoT 1편/2편 |
| API 설계 고민 | GraphQL vs REST → 정적 블로그 통신 |
| 레거시 리팩토링 | IoT 1편 → 클린 아키텍처 → DDD |
| 확장성 고민 | IoT 1편 → IoT 2편 (EDA) → DDD |
참고 :
https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
https://martinfowler.com/articles/201701-event-driven.html
Implementing Domain-Driven Design (Vaughn Vernon)
읽어주셔서 감사합니다.🖐
