Clean Architecture를 읽어가며 생각한 내용들을 정리한 내용.

인트로 부분에서 저자는 좋은 코드와 아키텍쳐가 무엇인지 설명을 하고 왜 필요한지에 대해서 설명을 하게된다.

1. "굴러"가기만 하는 코드

나의 개발 역사를 조금 설명하자면 첫째도 구현, 둘째도 구현 ... 마지막도 구현이었다.

사업과 서비스를 만들어 가기 위해서 개발을 시작했고 구현만 됐으면 됐고 그 다음 또 다른 기능의 구현이었다. 당연히 좋은 코드에 대해서는 관심이 없었던 과거였다.

저자도 첫장에서 "그들이 만든 코드는 아마도 예쁘지 않을 것, 그러나 작동한다" 라고 이야기 한다.

2. 정도를 걷는 것은 힘든 것

저자는 개발을 제대로 정도로 하는 것은 매우 힘들다고 한다.

이 부분에서 깊은 사고력과 통찰력이 필요하다고 하는데 "굴러"가기만 하는 코드를 작성하는 사람들은

그것이 문제인지 아닌지에 대한 자각도 없는데 어떻게 그런 사고력과 통찰력이 있을 수 있을까?

나는 당연히 그 힘듦도 필요성을 가지고 있을 수도, 알 수도 없었다.

3. 코드 잘 짜면 뭐가 좋은데?

저자는 몇가지 물음을 통해 그 필요성에 대해 스스로 답할 수 있게 해준다.

1. 막 짠 코드로 간단한 수정이 며칠씩 걸리는 경험 해 보았나? (yes)
2. 누군가 짜둔 후진 코드로 인해 방해를 받아봤나? (yes)
3. 설계가 엉망이어 제대로 제품을 만들지 못해 고객의 신뢰를 잃고 팀의 사기가 떨어져봤나? (yes)
4. 프로그래밍 지옥을 경험해봤나? (yes)

나는 각각 한가지의 질문에 대해서 쉽게 그 경험들을 떠올릴 수 있다.

나 역시 최근 1-2년 들어서야 위의 문제점과 심각성을 동감 할 수 있고 해결책을 모색하고 있던중이다.

4. 저자가 제시하는 좋은코드란?

1. 기능에 비해 거대한 인력이나 투자가 없어진다.
2. 변경사항을 쉽고 빠르게 대응할 수 있다.
3. 그 변경사항에 대해선 결함이 거의 없다.
4. 극대한 효율성과 확장성을 갖게 된다.

위의 문제점을 보고나니 저자가 말한대로 "유토피아" 적인 상황이 아닐 수 없다.

그리고 저자는 그런 프로젝트들을 경험했다고 자신한다.

What is Design and Architecture?

부채가 많이 쌓인 개발자들에게 가장 추상적이고 먼 단어가 아닐까 싶다.

그리고 디자인과 아키텍처에 대해 많이들 혼동 했을텐데 두 단어는 큰 차이가 없고 나누는 것이 무의미하다라고 한다.

그래도 굳이 나눈다고 한다면

디자인은 시스템 설계를 미시적으로 보아 디테일한 부분을 정의한다는 것

아키텍처는 반대로 거시적으로 보아 큰 구조물을 해당하는 것을 정의한다는 것

소프트웨어를 설계하는 데에 있어서는 두 부분 모두 필수적이며 두가지가 긴밀하기 이어진다고 한다.

목표는?

그 아키텍처의 목표는 만들고 발전시켜나갈 시스템에 필요 인력을 최소화하는데에 있다.

케이스 스터디

저자는 여러 실제 회사들의 사례들을 보여주며 개발자의 수는 점점 늘어나는데 그에 반해 생산성은 급속도로 떨어지는 것을 증명한다.

결론

결론은 당연하게도 소프트웨어의 품질을 높이는 것만이 이 문제를 해결 할 수 있는 방법이라고 이야기를 한다.

A Tale of Two Values

개발자에게 있어서 두 가지의 가치가 있다고 한다.

1. 행동

   프로그래머는 어떤 제품을 만들어 가치를 창출해야만 한다.

   사업측의 요구사항에 맞추어 제품을 만들어낸다.

   많은 잘못된 개발자들이 이것을 개발자의 주된 업무라고 생각한다.

2. 구조

   Software에서 ware는 제품을 의미하며, Soft가 즉 두번째 가치에 해당.

   소프트웨어에서 변경은 쉬워야한다. 그렇지 못하면 hard ware가 아닌가.

   특정 요구사항이 있으면 그 요구사항의 범위에 의해서만 작업의 비용이 결정되어야 하며,

   요구사항으로 인해 소프트웨어의 구조가 변경되어서는 안된다.

   아키텍처가 어떠한 형태에 포함되거나 그곳에 종속되어서 요구사항을 점점 맞추기 힘들어지고 그 기존의 어떠한 형태도 점점 잃어 갈 수 있어 두번째 가치를 잃게 될 수 있다.

3. 더 중요한 가치

   옛날의 나에게는 더 중요한게 무엇이냐 한다면 제품을 만들어 내는 것이다.

   쉽게 그렇게 생각했던 이유는 결국 개발도 서비스나 제품을 만들기 위한 것이며, 서비스가 존재해야 그 제품을 만들어가는 개발자들도 계속해서 필요하다고 생각했기 때문이다.

   하지만 이곳에서 저자는 사업의 요청사항에 의해 급급하게 기능구현만을 하게 된다면 다음 요청사항에 대해서 변경이 불가능한 경우가 생긴다고 했다. 그 경우는 변경으로 인해 얻는 이익보다 변경을 하기 위해 필요한 비용이 커질 때이다.

   저자는 여기서 프로그래머가 그 구조를 지켜내야한다고 이야기한다.

4. 아키텍처를 위한 투쟁

   소프트웨어 아키택처를 지켜내는 일은 개발자의 책무이며, 이것을 위해 기능구현을 우선순위로 하는 것들과 싸워야 한다고 한다.

   사실 나도 이전까진 사업이 더 중요하지... 개발이 더 중요해? 이러한 생각을 가지면서 위의 생각을 완벽하게 공감할 수 없었다. 하지만 아래의 생각들을 가지게 되면서 저자의 생각에 공감하게 되었다.

   내가 이것을 이해하게 된 생각은 각 포지션 별로 중요하게 보아야 할 것들이 다르다는 것이다.

   공통의 목표로 나아가지만 중요하게 보아야 할 것들은 다르다.

   마케팅팀도 투쟁한다.

   어떻게든 최고로 많은 유저 유입을 위해서 최대한 많은 마케팅 비용을 집행하려고 노력한다.

   경영팀도 투쟁한다.

   어떻게든 운영 비용을 감소시켜 때론 직원들의 불편함을 만들면서도 회사가 이익이 날 수있도록 노력한다.

   개발팀도 투쟁해야한다.

   어떻게든 사업측의 요구를 빠르고 낮은 리소스를 활용해 받을 수 있도록 아키텍처를 보존하는 노력.

   더 드는 생각이지만 이런 구조가 이루어지기 위해선 각자 다른 포지션의 팀원들을 신뢰할 수 있는 문화가 뒷받침 되어야 한다고 생각까지 들었다.