[클린 아키텍처] 1부 소개

책/기술서적

interactics 2023. 5. 2. 23:46

1. 설계와 아키텍처란?

좋은 소프트웨어 설계의 목표라는 것은 무엇일까?

소프트웨어 아키텍처의 목표는 필요로 하는 시스템을 생성하는데에 요구되는 인력을 최소화하는 것이다.

설계의 품질을 재는 척도는 무엇일까?

고객의 요구를 만족시키는 데에 드는 비용이다.

새로운 기능을 출시할 때마다 드는 비용이 증가한다면, 그것은 나쁜 설계이다.

"시장에 제품을 출시하는 것이 먼저야! 코드는 나중에 정리하면 되니까!"

이는 흔한 거짓말이다. 코드를 나중에 정리하는 경우는 없다.

왜냐? 시장의 압박은 항상 존재하니까.

"다시하면 잘해야지" 혹은 "나중에 시간이 많으면 제대로 잘 할거니까!"라는 자기 과신은 결국 틀린 선택이 된다.

행위인가 구조인가?

개발자라면 이 두 가지 가치 모두 중요하게 다루어야한다.

행위는 소프트웨어를 제작하는 행위이다. 개발자가 기능 명세서나 요구사항 문서를 만족하기 위해 구현하는 행위이다.

안타깝게도 요구사항을 만족시키는 일은 개발자의 일 전부가 아니다.

소프트웨어는 부드러운 것이다. 즉 Soft-부드러운- ware-제품-이라는 것이다.

소프트웨어의 비용 상승은 필히 변경 사항의 범위(Scope)에 있어야한다는 것이다. 형태(Shape)와는 무관해야한다는 것이다.

극단적으로 비교하지는 말자. 둘 다 적절하게 가져가야한다. 변경 비용이 커서 개선할 수 없다는 것은 없어야한다.

중요함 긴급함	중요함 긴급하지 않음
중요하지 않음 긴급함	중요하지 않음 긴급하지 않음

행위 = 긴급함 but 매번 중요도가 높은 것은 아니다.

아키텍처 = 중요도가 높다 but 진짜 긴급한 경우는 없다.

아이젠하워 매트릭스에 의하면 우선순위는

1. 긴급하고 중요한 <- 아키텍처 & 행위

2. 긴급하지는 않지만 중요한 <- 아키텍처

3. 긴급하지만 중요하지 않은 <- 행위

4. 긴급하지도 않고 중요하지도 않은

1번과 2번에 아키텍처가 위치하고, 1번과 3번에 행위가 위치한다.

이에, 아키텍처가 좀 더 중요한 것으로 볼 수 있다.

실수하지 말아야하는 것은 바로 3번을 1번의 우선순위로 격상시키는 것.

본인이 생각하는 더 중요한 가치를 위해 투쟁해야한다. 투쟁은 항상 존재해야한다.

소프트웨어 개발자도 이해관계자이다. 뻔뻔하게 당신의 가치를 위해 투쟁해라.

아키텍처가 후순위가 되면, 미래에 반드시 개발 비용이 더 많이 들고, 변경할 여지가 점점 줄어든다!