AA설계의 첫 단추. 무엇을 정할 것인가

이 글에서는 AA의 역할을 정의하고, 계약범위, 기대치에 대해 정리한다. 

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

 

코드를 쓰기 전에, 코드가 지켜야 할 질서를 먼저 만든다. "결정의 책임"

키워드 : 구조적 원칙, 경계 확정, 금지선, 통역, 운영 가능성

---

1️⃣ AA를 부르는 이유

대규모 프로젝트는 구조적으로 

• 일정은 빡셈
• 인력은 유동적
• 개발자는 계속 바뀜
• 운영은 최소 5~10년

그래서

• 초반 구조 결정이 잘못돼서 중후반에 설계가 뒤집히는 것을 막기 위한 프로젝트의 구조적 원칙을 정하는 것이 AA의 첫 단추이다.

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

---

2️⃣ AA에게 실제로 맡기는 핵심 업무 TOP 5

① “이 프로젝트의 구조적 원칙” 정리 (가장 중요)

이게 1번이다.
AA 외주 계약의 절반은 이거 하나로 끝난다.

AA에게 요구하는 산출물:

• 이 시스템은 상태 기반인가 / 이벤트 기반인가
• 마감·정산은 상태인가 / 이벤트인가
• 재고·매출의 진실 원본은 무엇인가
• 수정/재처리는 어디까지 허용하는가

👉 코드 ❌
👉 결정 문서 ⭕

이 문서가 있으면:

• 개발자 10명이 바뀌어도

구조는 안 흔들린다

② 서비스/모듈 경계 확정

SI에서 제일 자주 깨지는 게 이거다.

“이 기능은 A에서 할까요, B에서 할까요?”

AA는 여기서 판정자 역할을 한다.

• 판매 vs 재고 경계
• 정산 vs 리포트 경계
• 온라인 vs 배치 경계
• 프론트 책임 vs 백엔드 책임

AA가 남기는 것:

• 경계 다이어그램
• “이 책임은 여기까지”라는 문장

이게 없으면:

• 중복 로직
• 책임 떠넘기기
• 장애 시 책임 불명

③ DB 구조의 “금지선” 긋기

외주 AA가 제일 많이 하는 말 중 하나가 이거다.

“이 테이블은 직접 UPDATE 치면 안 됩니다”

AA는 보통 이런 걸 정의한다.

• 이벤트 테이블 (INSERT ONLY)
• 상태 테이블 (캐시)
• 리포트 테이블 (재생성 가능)
• 운영 보정 테이블

그리고 절대 하면 안 되는 것을 박는다.

• 트리거 금지 영역
• 상태 플래그 남용 금지
• 운영 DB 직접 수정 금지

👉 이게 없으면 SI 후반에 바로 무너진다.

④ 개발자·운영 사이의 “통역”

개발자언어와 운영언어는 다르다.

• 개발자 언어: 이벤트, 트랜잭션, 멱등성
• 운영 언어: 마감, 확정, 숫자, 책임

AA는 이걸 이렇게 바꿔준다.

• “SALE_CONFIRMED” → “판매 확정”
• “재정산 이벤트” → “다시 계산 버튼”
• “이벤트 로그” → “원장 화면”

그래서 SI에서 AA는:

• 개발 회의에도 있고
• 운영 회의에도 있다

⑤ “이 구조로 운영 가능하냐” 검증

외주 AA의 마지막 임무는 이거다.

“이 설계로
운영팀이 실제로 일할 수 있나?”

그래서 AA는 이런 걸 꼭 본다.

• 재고 안 맞을 때 어디서 보나?
• 마감 후 수정은 어떻게 하나?
• 누가 어떤 숫자를 책임지나?
• 장애 시 복구 시나리오는 있나?

이걸 기능 요구사항보다 먼저 본다.

---

3️⃣ 외주 AA가 거의 안 하는 것

이것도 중요하다.

❌ 직접 구현

• 컨트롤러 코드
• 배치 코드
• SQL 작성

❌ 프레임워크 선정 싸움

• “Spring vs Node”
• “Kafka 써야 하나요?”

AA는 기술보다 결정의 일관성을 본다.

---

4️⃣ 외주 AA의 실제 산출물 형태

현실적인 산출물은 이런 것들이다.

• 📄 아키텍처 원칙 문서 (10~20페이지)
• 📄 핵심 흐름 다이어그램 (판매/재고/정산)
• 📄 금지/허용 규칙 목록
• 📄 운영 시나리오 정리
• 📄 개발자 Q&A 정리본

SI PM 입장에서는:

• “이 문서로 끝까지 밀고 간다”가 목표다.

---

5️⃣ 한 문장으로 요약 (SI 현실 기준)

SI에서 외주 AA는
‘설계를 대신 구현해주는 사람’이 아니라,
‘나중에 되돌릴 수 없는 결정을 대신 책임지는 사람’이다.