[개발자 책읽기] 클린 아키텍처-소프트웨어 구조와 설계의 원칙 (2장 두가지 가치에 대한 이야기)

해당 글은 Robert C.Martin 클린 아키텍처 라는 책을 읽고 학습한 내용을 정리 및 회고하는 글 입니다. 자세한 사항은 YES 24 클린 아키텍처 - 소프트웨어 구조와 설계의 원칙 에서 확인해주세요.

 

클린 아키텍처 - 소프트웨어 구조와 설계의 원칙 (Robert C. Martin)

 

• 위키북스
• 지은이: Robert C.Martin (Uncle Bob)
• 옮긴이: 송준이

 

---

 

이번 장에서 이야기하고자 하는 것

 

• 소프트웨어가 이해관계자에게 제공하는 두가지 가치
  1. 행위
  2. 구조
• 개발자는 두가지 가치중 한가지에만 집중하거나 덜 중요한 가치에 집중함
• 행위
  • 개발자는 이해관계자가 기능 명세나 요구사항 문서를 구체화할 수 있도록 도와줌
• 구조 (아키텍쳐)
  • 소프트웨어는 변경하기 쉬워야 한다.
  • 변경사항을 적용하는데에 어려움이 있다면
    • 변경의 범위에 비례해야 하고 (Scope)
    • 변경의 형태와는 관련이 없어야 한다. (Shape)
• 더 중요한 가치는?
  • 단연 구조 (아키텍처) 이다.
    • 두가지 양 극단의 사례를 검토하는 논리 기법을 적용해보았을 때,
      1. 완벽하게 동작함, 수정이 불가능함
      2. 동작하지 않음, 변경 및 수정이 쉬움
    • 2번이 더 좋은 시스템임
      • 이유는 프로그램을 동작하도록 만들 수 있고 변경되더라도 여전히 동작할 수 있게 유지할 수 있기 때문에

 

나의 해석과 회고

최근 진행한 프로젝트에서 리더가 강조한 내용이 있다.

 

우리가 Notification 서비스를 위해서 특정 솔루션 (Toast, Senders, Slack) 에 결정되면 안된다.

 

그래서 코드 자체에서 벤더사를 칭하는 용어를 최소한으로 유지한 채 개발을 하게 되었다.

 

소프트웨어는 부드러움을 지니도록 만들어졌다. 소프트웨어를 만든 이유는 기계의 행위를 쉽게 변경할 수 있도록 하기 위함이다.

 

이 대목에서 큰 공감을 할 수 있었다.

 

결정하지 않는 아키텍처가 바로 좋은 아키텍처라는 리더의 말을 지키기 위해서 우리는 언제든지 외부 벤더를 추가할 수 있도록 개발하였기 때문이다.

 

개발자가 하는 일은 소스코드만 쳐다보고 있는게 아니라는 것도 좋은 말이었다.

 

개발자는 좋은 아키텍처를 위해서 이해관계자들과 대립하고 코드를 사수해야 한다.

 

시장의 요구로 급하게 출시해야 하는 기능이 존재한다면 시간에 쫓겨 좋지 못한 길로 가는 아키텍처를 방관해서는 안된다.

 

계속되는 delay 가 있고 업무 담장자의 꾸중이 있더라도 좋은 아키텍처를 사수해야 한다.

 

좋지 못한 길로 빠져드는 아키텍처를 방관하여 변경이 불가능한 하드웨어가 된다면 우리는 시스템을 방치하였던 죄로 인해 처벌받게 될 것이다..

 

아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해진다. 이러한 상황이 발생하도록 용납했다면 결국 소프트웨어 개발팀이 스스로 옳다고 생각하는 가치를 위해 충분히 투쟁하지 않았다는 것이다.