Architecture
시스템 개발 전체의 기반이 되는 변경 불가한 초기 결정들의 집합
아키텍처는 단순히 기술 스택(Java, Spring, MySQL 등)을 고르는 것이 아니라,
시스템이 어떤 방향으로 성장할지를 결정하는 근본적인 틀이다.
건축에서 아키텍처가 망치나 벽돌의 종류가 아니라 ‘건물을 어떻게 사용할 것인가(usage)’를 정의하듯, 소프트웨어 아키텍처 역시 “어떤 기술을 쓸 것인가”보다 “무엇을 하려는가”에 집중해야 한다
잘못된 관점 — Delivery 중심
대부분의 웹 시스템은 MVC 구조를 갖지만,
실제로는 Use Case보다 프레임워크나 UI에 종속된 구조를 갖고 있다.
중요한 것은 Delivering 메커니즘(UI, DB, FW)이 아니라 Use Case이다.
웹, 콘솔, 모바일 등 어떤 환경에서도
시스템의 핵심 로직은 동일하게 동작해야 한다.
즉, Use Case는 Delivery 메커니즘에 완전히 분리 되어야 한다.
Use Case란 무엇인가
Use Case란 사용자가 시스템과 상호작용하여 목표를 달성하는 절차
Use Case는 시스템의 외부적인 표현(화면, 버튼, 클릭 등)을 포함하지 않는다.
대신, 사용자의 행동과 시스템의 반응만을 기술한다.
[목적] 사용자가 새로운 주문을 생성한다.
1. 사용자 → 시스템: 주문 데이터를 전송한다.
2. 시스템 → 사용자: 주문 ID를 반환한다.이 예시에서 버튼 클릭이나 화면 이동은 언급되지 않는다.
중요한 것은 입력과 출력의 관계이며, 이것이 바로 시스템의 핵심 행위이다.
Use Case 중심 아키텍처
Application 개발은 Delivery와 독립적인 Use Case에 의해 주도되어야 한다.
Use Case는 단순한 시나리오가 아니라 시스템의 구조를 이끄는 중심 원리이다.
- 시스템의 핵심은 UI가 아니라 Use Case
- Use Case가 시스템의 “의도”를 드러낸다.
아키텍처를 변경하지 않고도 Delivery 메커니즘을 교체할 수 있다.
같은 회계 시스템을 웹 UI와 콘솔 UI로 모두 제공할 수 있다면,
그 시스템은 좋은 아키텍처를 갖고 있는 것이다.
좋은 아키텍처 — 결정을 미루는 구조
좋은 아키텍처는 프레임워크, UI, DB 같은 것들에 대한 결정을
가능한 한 오랫동안 미루게 해준다.
좋은 아키텍처는 ‘지금 당장 모든 것을 정해야 한다’는 압박에서 벗어나게 한다.
시간이 지날수록 더 많은 정보를 얻게 되므로,
결정을 늦출수록 더 나은 판단을 할 수 있다. 이것이 “결정 미루기”의 핵심이다
정리
| 구분 | 핵심 개념 |
|---|---|
| 아키텍처란 | 시스템 전체의 방향을 결정하는 변경 불가한 기반 |
| 핵심 | Use Case 중심의 구조 |
| 구성요소 | Boundary, Interactor, Entity |
| 좋은 아키텍처 | 기술 결정을 늦추고, 핵심 로직을 먼저 완성하는 구조 |
