아키텍처란 무엇인가

학습 목표

소프트웨어 아키텍처의 정의를 설명할 수 있다.

구조를 컴포넌트·커넥터·제약 으로 표현할 수 있다.

아키텍처 결정과 디자인 결정의 범위를 구분할 수 있다.

트레이드오프가 아키텍처의 핵심임을 설명할 수 있다.

문제 상황

• 기능은 잘 돌아가는데 변경이 점점 느려진다
  • 결제 방식 하나 바꾸려면 여러 모듈·DB·배치를 동시에 수정
  • 테스트 범위를 예측하기 어렵고, 배포 리스크가 커진다
• "코드는 있는데 구조가 없다"
  • 패키지·폴더는 있지만 경계가 없음
  • 레이어를 어기는 호출, 순환 의존이 쌓인다
• 회의마다 다른 답이 나온다
  • 개발은 속도, 운영은 안정성, 비즈니스는 출시 일정
  • 공통 기준 없이 논쟁만 반복된다

이런 문제는 클래스 하나 고치는 수준이 아니다. 시스템 구조와 설계 결정 수준에서 풀어야 한다. 그게 아키텍처다.

1. 소프트웨어 아키텍처의 정의

여러 정의가 있지만 공통 분모는 같다.

• 구조(Structure)
  • 시스템을 이루는 요소와 그 관계
• 설계 결정(Design Decision)
  • 왜 이 구조를 선택했는지, 무엇을 포기했는지
• 품질 속성(Quality Attribute)
  • 성능·가용성·보안 등 목표

Bass et al. (Software Architecture in Practice) 는 다음과 같이 정의한다.

소프트웨어 시스템의 구조를 구성하는 요소들, 이들 간의 관계, 그리고 이 구조와 관계를 안내하는 설계·진화 원칙

 

Richards & Ford (Fundamentals of Software Architecture) 는 아키텍처를 다음 다섯 가지로 본다.

요소	내용
Structure	컴포넌트·관계
Architecture characteristics	품질 속성 (가용성, 확장성 등)
Architecture decisions	바꾸기 어려운 결정
Design principles	팀이 따를 가이드라인
Environment	배포·조직·규제 등 맥락

• 동작하는 코드 ≠ 좋은 아키텍처
  • 프로토타입은 돌아가도, 운영·변경·확장을 견디지 못할 수 있다
  • 아키텍처는 시간이 지나도 유지되는 구조를 다룬다

2. 구조: 컴포넌트·커넥터·제약

구조는 "박스와 화살표"가 아니라 세 가지로 나눠 생각하면 명확하다.

컴포넌트 (Component)

• 계산·상태를 담당하는 단위
• 예: API 서버, 주문 서비스, PostgreSQL, Redis, Kafka

커넥터 (Connector)

• 컴포넌트 간 통신·호출·데이터 전달 메커니즘
• 예: HTTP REST, gRPC, 메시지 큐, JDBC

제약 (Constraint)

• 구조를 제한하는 규칙
• 예: "주문 DB는 Order 서비스만 접근", "동기 호출은 3 hop 이내"

• 같은 컴포넌트라도 커넥터가 다르면 아키텍처가 달라진다
  • REST 동기 호출 vs 이벤트 비동기 — 장애 전파·일관성·지연이 다름
• 제약을 문서화하지 않으면 시간이 지나며 침묵의 규칙만 남는다

3. 아키텍처 결정 vs 디자인 결정

오리엔테이션에서 개요를 봤다. 여기서 범위를 구체화한다.

	아키텍처 결정	디자인 결정
범위	시스템·서비스 전체	모듈·클래스·함수
변경 비용	높음 (재배포·마이그레이션)	상대적으로 낮음
예	모놀리스 vs MSA, RDB vs NoSQL, 동기 vs 이벤트	클래스 분리, 패턴 선택, 네이밍
시점	초기에 신중히, ADR로 기록	구현 중 반복 개선

 

• 아키텍처 결정이 디자인을 제한한다
  • MSA를 선택하면 서비스 간 API 계약·분산 트랜잭션이 디자인 이슈가 된다
  • 레이어드 아키텍처를 선택하면 Presentation이 Persistence를 직접 호출하면 안 된다
• 디자인이 아키텍처를 깨뜨릴 수 있다
  • "잠깐만 이 서비스에서 다른 DB 직접 읽자" → 경계 붕괴
  • 작은 위반이 쌓이면 아키텍처가 명목상만 남는다
• 실무에서의 구분 기준 (Richards & Ford)
  • 아키텍처적 중요도: 이 결정이 품질 속성·구조에 얼마나 영향을 주는가
  • 변경 난이도: 되돌리는 비용이 큰가
  • 둘 다 높으면 아키텍처 결정으로 취급하고 ADR을 남긴다

4. 트레이드오프

아키텍처에 최선(best) 은 없고 적합(fit) 만 있다.

• 모든 품질 속성을 동시에 극대화할 수 없다
  • 강한 일관성 vs 가용성 (CAP)
  • 개발 속도 vs 운영 안정성
  • 단순한 모놀리스 vs 독립 배포 가능한 MSA
• 트레이드오프를 명시하지 않으면
  • 나중에 "왜 이렇게 됐지?"만 남는다
  • 기술 부채가 의도 없는 부채가 된다

선택	얻는 것	잃는 것
모놀리스	단순 배포·트랜잭션	팀·배포 독립성
MSA	독립 확장·배포	분산 복잡도·운영 비용
동기 REST	단순한 호출 흐름	연쇄 장애·지연 누적
이벤트 기반	느슨한 결합	eventual consistency

• 초기에 구조를 잡지 않으면 변경 비용이 기하급수적으로 오른다
  • 기능 추가는 선형인데, 결합도는 누적된다
  • 아키텍처 작업은 "나중에"가 아니라 비용이 가장 쌀 때 하는 것

5. 아키텍처가 다루는 범위

코드 구조만이 아니다. 오리엔테이션의 범위 다이어그램을 전제로 정리한다.

• 배포 단위: JAR 하나인지, K8s Pod 여러 개인지
• 데이터 소유권: 서비스마다 DB를 갖는지, 공유 스키마인지
• 통신 방식: 동기 API인지, 이벤트 스트리밍인지
• 운영·관측: 로그·메트릭·트레이스를 어디서 수집하는지
• 개발자가 매일 쓰는 디자인 패턴(Singleton, Factory 등)은 아키텍처 스타일(레이어드, MSA)과 다른 층위다
  • 패턴은 디자인 결정에 가깝다
  • 스타일 선택은 아키텍처 결정에 가깝다

---

해당 내용은 Fundamentals of Software Architecture (Mark Richards, Neal Ford) 및 Software Architecture in Practice, 4/E (Bass, Clements, Kazman) 의 내용을 기반으로 합니다.