Clean Architecture 정리 – 5부 15장 아키텍처

아키텍처란

시스템의 형태이다.

어떤 컴포넌트들로 구성되어있고, 컴포넌트들이 어떻게 배치되며, 상호작용하는지 등을 정의한다.

이러한 형태는 단순한 구조적 정보 이상을 담는다.
개발, 배포, 운영, 유지보수의 모든 흐름에 영향을 준다.

 

개발 측면에서 본 아키텍처

초기에는 아키텍처를 고려하는 것이 오히려 방해가 될 수 있다.
그러나 프로젝트가 커지거나 오래 살아남는 시스템일수록 아키텍처의 진가가 드러난다.

 

배포 측면에서 본 아키텍처

처음부터 배포를 고려하지 않으면,
서비스는 코드 완성과는 무관하게 “배포하기 번거롭거나 심하게는 배포 할 수 없는 상태”에 빠질 수 있다.
서비스가 하나의 단위로 배포 가능한지, 분리된 기능이 독립적으로 배포 가능한지 등을 아키텍처에서 고민해야 한다.

 

운영 측면에서 본 아키텍처

대부분의 운영 문제는 자원 부족으로 해결 가능하다.
서버를 늘리거나, DB 스펙을 키우면 된다.

 

하지만, 아키텍처가 비효율적일 때는 아무리 자원을 투입해도 해결되지 않는다.
결국 사람(=인건비)이 투입되며, 운영뿐 아니라 개발과 유지보수 비용까지 급증하게 된다.

 

아키텍처가 깔끔하면 “시스템이 어떤 흐름으로 작동하는지”가 명확하게 보인다.

• 유스케이스와 기능이 일급 엔티티로 분리되어 있고
• 개발자가 이를 중심으로 사고하게 된다

 

유지보수 측면에서 본 아키텍처

좋은 아키텍처는 탐사 비용을 줄인다.

• 새로운 기능을 추가할 때
• 기존 기능에 결함을 수정할 때 등

"어떤 코드를 건드려야 하는지"를 빠르게 파악할 수 있어야 한다.

이 탐사(Exploration)가 길어질수록, 생산성은 급격히 저하된다.

 

선택사항 열어두기

좋은 아키텍처는 '선택사항을 가능한 한 오래 미루는 구조'를 만든다.

 

여기서 말하는 선택사항이란 시스템의 핵심 동작이 아닌, 구현 세부사항(detail)들을 말한다.

예를 들어:

• 어떤 DB를 쓸지 (MySQL, MongoDB 등)
• REST를 쓸지 gRPC를 쓸지
• 특정 프레임워크를 쓸지 말지
• 어떤 웹서버로 구성할지

이런 것들은 모두 나중에 결정되어도 되는 일이다.

 

정책 vs 세부사항

개념	설명	예시
정책 (Policy)	시스템이 반드시 지켜야 할 본질적 규칙	인증이 필요하다, 주문은 재고가 있어야 한다
세부사항 (Detail)	정책을 구현하기 위한 수단	Firebase Auth vs 자체 구현, MySQL vs MongoDB

아키텍트의 목표는 정책을 먼저 결정하고,
세부사항은 나중에 결정해도 되는 구조를 만드는 것이다.

 

선택사항을 열어두면 좋은 점

1. 더 많은 실험이 가능하다
   • 여러 DB, 프레임워크, 통신방식 등을 비교하고 실험할 수 있다
   • 결정 전에 다양한 가능성을 탐색할 수 있다
2. 더 나은 정보로 결정할 수 있다
   • 시간이 지날수록 요구사항과 상황이 더 명확해진다
   • 도구나 기술의 안정성도 시간이 지나야 보인다
3. 기술 종속에서 자유로워진다
   • 특정 기술에 종속되지 않기 때문에 언제든 교체 가능
   • 유연하고 이식성 있는 시스템이 된다

 

---

소프트웨어 아키텍트란?

아키텍트는 단순한 아키텍처 설계자가 아니다.
코드를 작성하면서 동시에 나머지 팀원들이 생산성을 극대화할 수 있는 설계를 리드하는 역할이다.
그래서 코드 작업을 완전히 떠나는 것이 아니라, 문제를 직접 경험하고 해결하면서 방향을 잡는다.

 

 

※ 본 글은 『Clean Architecture』(로버트 C. 마틴 저) 5부 15장을 기반으로 학습 목적으로 요약한 글입니다.

※ 이 글은 책의 내용을 요약한 것으로, 원문 없이 읽을 경우 오해의 여지가 있을 수 있습니다. 정확한 이해를 위해 원서의 정독을 권장합니다.