AA 설계단계에서 실제 작업

AA(Application Architecture, 애플리케이션 아키텍처)를 설계할 때 “무엇을 만들어야 하나?”를 한 줄로 요약하면 이거다:

코드를 쓰기 전에, 코드가 지켜야 할 질서를 먼저 만든다.

 

그 질서를 구성하는 기본 요소들을 실무 기준으로 단계적으로 정리해보자.
(이건 이론 목록이 아니라, 실제 설계 문서에 들어가야 하는 것들이다)

실제 설계작업

키워드: 레이어 정의, 컴포넌트 역할, 데이터 흐름, 트랜잭션, 예외 처리, 확장 규칙

 

 

---

1️⃣ 시스템의 책임 분해 (Responsibility Breakdown). 책임경계

AA의 출발점은 항상 이 질문이다.

이 시스템은 무슨 책임을 어디까지 지는가? 기술과 무관한 비지니스 결정

여기서 해야 할 일:

• 시스템이 해결해야 할 문제 범위
• 하지 않기로 한 것 (경계 설정)
• 외부 시스템과의 역할 분리

예시 (실무식 표현):

• 주문 생성, 변경, 취소는 우리 시스템 책임
• 결제 승인/취소는 외부 PG 책임
• 재고 차감은 동기, 재고 복구는 비동기

이 단계가 흐릿하면
→ 이후 모든 레이어가 뒤섞인다. (책임분산, 중복구현... )

---

2️⃣ 계층 구조 정의 (Layered Structure). 의존규칙

AA의 핵심 뼈대다.
“어떤 코드가 어떤 코드에 의존해도 되는가”를 결정한다. 레이어 컴포넌트 간 허용된 방향

보통 다음을 명확히 한다:

• Presentation Layer (Controller / API)
• Application Layer (Use Case / Service)
• Domain Layer (비즈니스 규칙)
• Infrastructure Layer (DB, 외부 API)

중요한 포인트:

• 의존 방향은 단방향
• 위 → 아래만 가능
• 아래가 위를 모르면 성공

이걸 문서로 안 박아두면
나중에 Service가 Controller를 호출하는 괴물이 탄생한다.

---

3️⃣ 주요 컴포넌트와 역할 정의

여기서부터 “그림이 그려지는” 단계다.

• 핵심 컴포넌트 목록
• 각 컴포넌트의 책임
• 컴포넌트 간 통신 방식

예:

• OrderService: 주문 상태 전이만 담당
• OrderValidator: 검증 규칙 전담
• OrderRepository: 영속성만 담당

포인트는 이거다:

클래스 목록이 아니라, 역할 목록을 먼저 만든다

---

4️⃣ 데이터 흐름과 경계 (Data Flow & Boundary)

AA는 코드 구조만이 아니라 데이터 이동 규칙도 정의한다.

정의해야 할 것:

• DTO ↔ Domain 변환 위치
• 외부 입력 데이터가 내부 모델로 들어오는 지점
• 트랜잭션 경계

예:

• Controller → DTO
• Service 진입 시 Domain 변환
• Repository는 Domain만 취급

이걸 안 정하면:

• Controller에서 Entity 수정
• Entity가 JSON으로 그대로 노출
  같은 사고가 발생한다.

---

5️⃣ 상태 관리와 트랜잭션 전략. 상태변화 규칙

누가 데이터를 바꿀지, 어디서 상태 전이가 허용되는지.

결정해야 할 것:

• 트랜잭션 시작/종료 위치
• 상태 변경 책임자
• 동시성 제어 전략

예:

• 하나의 Use Case = 하나의 트랜잭션
• 상태 변경은 Domain 내부 메서드로만 허용
• 락은 DB 기준, 낙관/비관 여부 명시

AA 문서에 이게 없으면
→ 운영 중 데이터가 망가진다. 컨트롤러에서 상태를 변경하거나, Repository에서 규칙을 실행하거나.. 디버깅 불가능 

---

6️⃣ 예외 처리와 오류 전파 규칙. 실패와 예외

놀랍게도 많은 설계 문서에 빠져 있는 부분. 

반드시 정해야 한다:

• 어떤 레이어에서 예외를 던지는가. 실패의 전파 범위
• 어디서 잡아서 사용자 메시지로 변환하는가
• 시스템 오류 vs 비즈니스 오류 구분
• 롤백의 기준

예:

• Domain: 비즈니스 예외만
• Application: 트랜잭션 롤백 판단
• Presentation: HTTP 응답 변환

이 규칙이 없으면 try-catch 지옥이 열린다.

---

7️⃣ 확장과 변경을 위한 규칙 (Extensibility Rules)

AA는 “현재”보다 “미래”를 위한 설계다.

미리 정해두는 것:

• 신규 기능 추가 시 수정 범위
• 플러그인/전략 패턴 적용 위치
• 설정 기반 vs 코드 기반 분기

예:

• 결제 수단 추가 → Strategy 추가, 기존 코드 수정 없음
• 정책 변경 → 설정값 교체

여기서 AA의 실력이 드러난다.

---

8️⃣ 비기능 요구사항 반영 

마지막으로, 하지만 절대 가볍지 않은 요소.

• 성능 기준
• 보안 정책
• 로깅 / 모니터링
• 장애 대응 방식

예:

• 모든 외부 호출은 타임아웃 필수
• 핵심 이벤트는 구조화 로그
• 장애 전파는 Circuit Breaker 사용

AA는 “잘 동작하는 코드”가 아니라
“운영 가능한 구조”를 만드는 작업이다.

---

8️⃣ AA 설계에서 유연해야 할 부분

“이 결정이 틀렸을 때, 되돌릴 수 있는가?”

• 되돌리기 어렵다 → 고정
• 되돌릴 수 있다 → 유연

예시:

• 책임 경계 ❌ 되돌리기 어려움 → 고정
• DB 종류 ⭕️ 되돌릴 수 있음 → 유연

AA의 본질은
리스크를 어디에 고정할지 결정하는 것이다.

 

여길 고정하면, 시스템이 늙는다.

① 기술 선택 ▼

• DB 종류
• 메시징 시스템
• 프레임워크
• 라이브러리

이건 전략이 아니라 수단이다.

AA에서 해야 할 건:

• “무엇을 쓴다” ❌
• “교체 가능해야 한다” ⭕️

▲ ▲ ▲ ▲ ▲ ▲

② 구현 방식 ▼

• 동기 → 비동기
• Batch → Event
• REST → Messaging

비즈니스가 자라면
구현 방식은 반드시 바뀐다.

AA는 구현을 가두지 말고
교체 가능한 자리만 제공해야 한다.

▲ ▲ ▲ ▲ ▲ ▲

③ 확장 포인트의 개수 ▼

 

초기에 흔한 실수:

• 모든 걸 Strategy로 만듦
• 모든 로직을 추상화

결과:

• 복잡도 폭증
• 이해 비용 증가
• 아무도 못 건드림

확장 포인트는:

• 실제로 바뀐 적이 있거나
• 바뀔 가능성이 높은 곳만
  ▲ ▲ ▲ ▲ ▲ ▲

 

 

④ 문서의 상세도 ▼

AA 문서도 유연해야 한다.

• 원칙은 오래 유지
• 예시는 교체 가능
• 세부 구현은 코드로 이동

문서는 지도여야지
위성 사진이면 안 된다.
▲ ▲ ▲ ▲ ▲ ▲

 

---

한 문장으로 정리하면

AA 설계 시 만들어야 할 기본 요소는 이거다:

책임, 경계, 의존성, 데이터 흐름, 상태 변화, 예외 규칙, 확장 규칙

이게 정리되면
프레임워크는 그냥 도구고,
언어는 취향 문제가 된다.