# [[Architecture Review (아키텍처 및 설계 리뷰)|Architecture Review (아키텍처 및 설계 리뷰]]

## 📌 Brief Summary
아키텍처 리뷰(Architecture Review)는 라인 단위의 구현 세부 사항을 넘어, 코드 변경 사항의 구조적 무결성과 장기적인 생존성을 평가하는 고수준의 특화된 검토 프로세스입니다 [1, 2]. 이 과정은 아키텍처의 표류(Architectural drift)와 기술 부채의 축적을 방지하는 전략적 체크포인트 역할을 수행합니다 [1, 3]. 궁극적으로 새로운 기능이 시스템의 거시적인 디자인 패턴(예: MVC, 클린 아키텍처) 및 설계 원칙(예: SOLID)에 부합하여, 확장성과 유지보수성을 보장하도록 만드는 것을 목표로 합니다 [1, 4].

## 📖 Core Content
*   **목적 및 평가 초점:** 자동화된 도구가 포착하기 어려운 고수준의 설계 의사결정을 검증하여 시스템의 장기적인 건전성을 유지합니다 [3, 7]. 코드의 국소적 정확성보다는, 새로운 모듈이 기존 아키텍처 원칙과 정렬되며 시스템이 '거대한 진흙 뭉치(Big Ball of Mud)'가 되는 것을 방지하는 데 집중합니다 [3, 5].
*   **설계 원칙 및 정합성 검증:** SOLID 원칙(SRP, OCP 등) 준수 여부와 컴포넌트 간의 결합도(Coupling)를 검토합니다 [3, 4]. 하나의 모듈 변경이 연관 없는 다른 컴포넌트의 연쇄 수정을 유발하지 않도록 모듈성을 보장해야 합니다 [6].
*   **과도한 엔지니어링 방지:** 미래의 유연성을 확보하되, 현재 요구사항에 비해 불필요하게 복잡한 '오버 엔지니어링(Over-engineering)'이 도입되지 않았는지 평가합니다 [3, 8]. 적절한 추상화 수준을 유지하는 것이 핵심입니다.
*   **의존성 및 서드파티 검토:** 새로운 외부 라이브러리나 서비스 도입 시, 시스템의 의존성 전이 위험, 보안 취약점, 라이선스 호환성 등을 면밀히 검토하여 공급망 안정성을 확보합니다.
*   **리뷰 타이밍과 문서화:** 실제 코드가 작성되기 전, 설계 문서나 다이어그램 단계에서 사전 리뷰를 수행하는 것(시프트 레프트)이 가장 효율적입니다 [9]. 합의된 중요한 결정 사항은 **아키텍처 결정 기록(ADR, Architecture Decision Records)**으로 문서화하여 역사적 맥락을 보존합니다 [9].

## ⚖️ Trade-offs & Caveats
*   **높은 비용 및 전문성 요구:** 아키텍처 리뷰는 시스템 전반에 대한 깊은 지식이 필요하므로 시니어 개발자의 시간이 많이 소요됩니다 [10]. 이는 자칫 개발 파이프라인의 병목(Bottleneck)이 될 수 있습니다 [12].
*   **완벽주의의 함정:** 완벽한 아키텍처와 미래 확장성만을 쫓다 보면, 당장의 비즈니스 요구사항 해결이 늦어지거나 불필요한 복잡성이 주입될 수 있습니다 [8, 15].
*   **유연성 저하:** 특정 디자인 패턴을 무조건적으로 강제하는 등 지나치게 엄격한 원칙 적용은 실용적인 문제 해결을 방해할 수 있습니다 [16].

## 🔗 Knowledge Connections

### Related Concepts
*   **[[SOLID Principles|SOLID Principles]]**: 아키텍처 리뷰 시 견고한 객체 지향 설계를 판단하는 절대적인 척도입니다.
*   **Architecture Decision Records (ADR**: 리뷰를 통해 합의된 설계 선택과 트레이드오프를 기록하는 공식적인 도구입니다.
*   **Over-engineering**: 리뷰어가 가장 경계해야 할, 시스템 유지보수성을 해치는 불필요한 추상화와 일반화입니다.
*   **Shift-Left Strategy**: 설계 결함을 구현 전 초기 단계에서 잡아내어 리팩토링 비용을 예방하는 전략입니다.

### Deeper Research Questions
*   ADR 작성 프로세스를 애자일 스프린트나 PR 워크플로우 내에 마찰 없이 매끄럽게 통합하기 위한 자동화 방안은 무엇인가?
*   '오버 엔지니어링'과 '적절한 확장성 설계' 사이의 경계를 명확히 구분 지을 수 있는 정성적/정량적 평가 프레임워크는 무엇인가?
*   마이크로서비스 아키텍처(MSA) 환경에서 서비스 간 상호작용의 사각지대를 포착하는 '크로스 서비스(Cross-service) 리뷰'는 어떻게 운영해야 하는가?
*   AI가 제안한 초기 아키텍처 구조가 프로젝트의 핵심 설계 원칙을 준수하는지 인간 리뷰어가 효율적으로 검증하는 체크리스트는 어떻게 구성되는가?
*   비즈니스 성장 속도가 최우선인 스타트업 환경에서 기술 부채를 통제하기 위한 '최소 필수 아키텍처 리뷰(Minimum Viable Review)'의 범위는 어디까지인가?

### Practical Application Contexts
*   **Implementation:** 대규모 구현 전 설계 문서(RFC) 단계에서 사전 리뷰를 받아 전면 재작성 비용을 예방합니다 [50].
*   **System Design:** 새로운 모듈 추가 시 기존 컴포넌트와의 결합도를 통제하고 설계 원칙 위반을 걸러내어 시스템 구조를 보호합니다 [51].
*   **Operation / Maintenance:** 트래픽 증가 및 데이터 볼륨 확대에 대비한 확장성 검토를 통해 운영 안정성을 확보합니다.
*   **Learning Path:** 시니어 아키텍트와의 리뷰 세션을 통해 팀 전체의 설계 역량을 상향 평준화하는 멘토링 기회로 활용합니다 [53].
*   **My Project Relevance:** 중대한 구조 변경 시 요구되는 별도의 '설계 승인(Design Approval)' 단계를 도입하여 아키텍처 표류를 방지합니다.

### Adjacent Topics
*   **Technical Debt (기술 부채**: 아키텍처 리뷰 소홀로 인해 누적되는 장기적인 비용과 운영 리스크에 대해 탐구합니다.
*   **Code Smells**: 고수준의 설계 결함이 소스 코드 레벨에서 어떤 구현 안티 패턴으로 발현되는지 분석합니다.

---
*Last updated: 2026-05-02*
