본문 바로가기

IT 책

[클린 아키텍처] 1. 설계와 아키텍처 두 가지 가치에 대한 정리

글의 목적

  • SW가 돌아가도록 만드는것은 누구나 할수 있다. 하지만 제대로 만드는것은 다른 이야기 이다.
  • 백엔드를 독학하면서 느낀점은 좋은 코드는 코드블록 수준에서 나오는것이 아니라 좋은 아키텍처에서 나온다는 느낌.
  • 그래서 클린 아키텍처라는 책을 nestjs 책을 읽다가 추천받아서 읽어보면서 느낀점을 정리하려고 함.

본론

 1. 설계와 아키텍처란?

  • 설계와 아키텍처 둘 사이에는 어떠한 차이도 없다.

 1.1. 목표란?

소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는 데 있다. 
- 클린 아키텍처 7p
  • 좋은 SW 설계의 목표는 고객의 요구사항은 만족하면서 비용이 낮은 설계이다.

1.2. 실제사례

  • 회사는 성장중이다.
  • 개발자도 늘어난다.
  • 다만 코드 한줄이 가진 비용도 점점 올라간다.
  • 개발자는 착각한다, 서비스 출시 후에 현재 엉망인 코드를 정리할 수 있다고. 하지만 다시 엉망인 코드를 돌아볼 시간은 없고 항상 예측불가능한 상황에 대처하는 시간만 늘어난다.
  • 개발자는 실수한다. 다시 원점으로 돌아가서 처음부터 다시 작성하면 이 문제가 해결될 수 있을거라고
자신을 과신한다면 재설계하더라도 원래의 프로젝트와 똑같이 엉망으로 내몰린다.
- 클린 아키텍처 13p

 1.3. 결론

  • 아키텍처에 대해 공부하고 현재 아키텍처의 품질에 대해서 고민하는 것.

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

  • SW 개발자는 행위(behavior)와 구조(structure), 두 가지 가치를 모두 반드시 높게 유지해야 하는 책임을 진다.

 2.1. 행위(behavior)

  • 개발자는 클라이언트의 요구사항을 위해 구현과 버그를 수정하는 행위를 한다.
  • 그리고 그 행위가 자신의 직업이라고 생각한다.
  • 그것은 틀렸다.

 2.2. 구조(structure)

  • 소프트웨어는 말 그대로 부드러운 제품이어야 한다.
  • 부드럽다는 말을 다시 말하면 변경하기 쉬워야 한다는 말이다.
  • 클라이언트가 요구사항을 수정하면 개발자는 변경사항은 쉽게 적용할 수 있어야 하고 변경사항을 적용하는 데 드는 어려움은 변경되는 범위(scope)에 비례해야하고 형태(shape)와는 관련이 없어야 한다.
  • 비용의 증가도 결국 여기에 있다.
  • 아티텍처가 특정 구조를 더 선호하면 할 수록 클라이언트의 변경사항의 맞추는것은 더욱 힘들어진다.
  • 결국 아키텍처는 독립적일수록 실용적이다.

 2.3. 더 높은 가치

  • 행위와 구조, 즉 다시말해서 기능과 아키텍처 둘 중에 더 높은 가치란 무엇일까?
  • 기능이 중요하다고 생각하는 개발자도 있을것이고 아키텍처가 중요하다고 생각하는 개발자도 있을것이다.
  • 하지만 답은 언제나 아키텍처로 정해져 있다.
1. 완벽하게 동작하지만 수정이 아예 불가능한 프로그램
2. 동작은 하지 않지만 변경이 쉬운 프로그램
  • 너무 극단적이라는 비판에 대해서는 비용을 추가시켜서 생각해보자
  • 1번은 1번의 성향이 짙을 수록 비용이 많이 들어간다.
  • 2번은 동작하도록 만드는것이 과연 비용적으로 많이 들어갈까?
  • 정답은 항상 아키텍처에 있다.

 2.4. 아이젠하워 매트릭스

  • 두 가지 가치를 설명하는데 적합하다고 생각한다.
    1. 긴급하고 중요한 일
    2. 긴급하지는 않지만 중요한 일
    3. 긴급하지만 중요하지 않은 일
    4. 긴급하지도 중요하지도 않은 일
  • 위에서 중요한 것은 기능보다는 아키텍처라고 정의했다. 따라서 1번과 2번은 아키텍처다.
  • 기능은 기한에 맞춰 구현되어야 하기 때문에 항상 긴급하다. 따라서 1번과 3번이 기능이다.
  • 개발자는 기능보다는 아키텍처를 더 중요하게 생각해야하지만 기능에서도 3번 즉, 긴급하지만 중요하지 않은 기능에 대해서는 많은 선택을 해서는 안된다.

 2.5. 아키텍처를 위해 투쟁

  • 귀찮고 바빠질것 같고 업무가 늘어날것 같아도 개발자는 아키텍처를 위해서 투쟁해야 한다.

결론

  • 생각보다 글이 잘 읽혀서 재밌었다.
  • 아키텍처가 중요하다고 생각하긴 했지만 생각지도 못한 관점에서 아키텍처를 보게 되어서 좋았다.
  • 그런데 마지막 투쟁은....주니어개발자의 역량은 아닌것 같다.
  • 주니어개발자는 결정권자들이 아키텍처에 대해서 고민할 시간이 늘어나도록 업무를 빠르게 처리해주는게 더 맞는것 같다.
  • 클린 아키텍처는 책이 두껍지는 않지만 글씨가 작아서 대략 10회 분의 글이 나올 것 같다.