Clean Architecture 정리 - 1부 소개

목차

1. 설계와 아키텍처란
2. 두 가지 가치에 대한 이야기

---

1장. 설계와 아키텍처란

설계와 아키텍처는 실질적인 차이가 없다. 따라서 이 글에서는 두 용어를 혼용해서 사용한다.

좋은 소프트웨어 설계(또는 아키텍처)의 목표는 간단하다. 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는 것이다.

 

✅ 소프트웨어 설계를 무시한 개발의 흔한 흐름

• 출시 우선 사고방식
  • "설계는 나중에, 일단 시장에 먼저 내자"
  • 기능 구현만 반복하며 기술 부채가 누적된다
• 기능 추가에만 집중
  • 경쟁자를 의식해 새 기능만 계속 추가
  • 기존 코드는 정리되지 않고 복잡도만 증가한다
• 결국 리빌딩 결심
  • 생산성 저하 → "다시 만들자"라는 결론
  • 하지만 설계에 대한 학습과 반성 없이 다시 시작하면, 같은 실패를 반복하게 된다

 

★ 실제 사례: 소프트웨어 설계를 무시한 조직의 지표 변화

• Engineer Count: 버전이 거듭될수록 팀 규모는 증가한다
• Product Size (KLOC): 제품 크기는 한 시점 이후 정체된다
• Cost per LOC: 코드 1줄당 비용은 지속적으로 상승한다
• Productivity per Release: 생산성은 점점 낮아진다
• Monthly Payroll Cost: 인건비는 급증하고, 산출물은 늘지 않는다

설계 없는 확장은 결국 비용 증가와 생산성 하락으로 이어진다.

---

2장. 두 가지 가치에 대한 이야기

 

✅ 소프트웨어에는 두 가지 가치가 있다

1. 기능 (Functionality)

• 소프트웨어가 수행해야 할 직접적인 동작 또는 서비스
• 이해관계자의 목적을 위해 기계가 수익을 창출하거나 비용을 절감하도록 돕는다
• "소프트웨어가 무엇을 하느냐"에 대한 가치

2. 아키텍쳐 (Architecture)

• 소프트웨어가 얼마나 변경하기 쉬운가에 대한 구조적인 기반
• 소프트웨어는 'soft'하다는 특성을 갖고 있어야 하며, 이는 곧 변화에 유연해야 한다는 뜻이다.
• 좋은 아키텍처는 이해관계자의 요구 변화에 따라 동작을 쉽게 수정할 수 있도록 해야한다.

 

우선순위

1	정말 정말 중요하고 긴급한 기능 구현
2	아키텍쳐 구조 설계
3	중요하지는 않지만 긴급한 기능 구현
4	중요하지도 않고 긴급하지도 않은 것

많은 업무 관리자와 개발자가 3번을 1번처럼 착각하는 일이 반복한다.

그렇게 되면 아키텍처는 항상 후순위로 밀리게 된다.

그러나 업무 관리자는 아키텍처의 가치를 알지 못한다.

기획자는 기획이, 마케터는 마케팅이 가장 중요하다고 말한다. 디자이너는 디자인을, 운영자는 운영을 이야기한다.

이처럼 각자의 관점에서 중요하다고 설득하는 것이 다르듯이, 소프트웨어 구조의 중요성을 설득하는 것은 결국 개발자의 책임이다.

 

아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 수익보다 개발 비용이 커진다면 결국 시스템의 변경은 불가능해진다.

개발자는 소프트웨어를 안전하게 보호해야 할 책임이 있다!

아키텍처를 위해 투쟁해라!

 

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

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