책 선정 이유
현재 하고 있는 독서 스터디에서 책에서 다루는 내용이 너무 하드웨어에 가깝고, 실제 실무에 적용하거나 면접 스터디로도 적절하지 않은 것 같다는 의견이 있어서 변경하게 됐다.
그런데 왜 하필 클린 아키텍처냐 묻는다면...! 다들 원하는 책이 다음과 같았다.
그런데 이 중에서
- 언어를 최대한 가리지 않고(스터디원이 각자 주력으로 하는 기술 스택이 다양하다),
- 신입 개발자들에게 크게 도움이 될 만한
것으로 골랐더니 클린 아키텍처가 남았다.
앞으로 어떻게 될 지 기대되는데,
개인적으로 궁금한 부분들을 해소할 수 있을지 의구심도 가득 품은 채
열심히 읽으면서 정리해보도록 하겠다!
1장 설계와 아키텍처란?
인상 깊은 부분
(7쪽) 소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는데 투입되는 인력을 최소화하는 데 있다.
(11쪽) 이들 개발자는 "코드는 나중에 정리하면 돼. 당장은 시장에 출시하는 게 먼저야!"라는 흔해 빠진 거짓말에 속는다. 이렇게 속아 넘어간 개발자라면 나중에 코드를 정리하는 경우는 한 번도 없는데, 시장의 압박은 절대로 수그러들지 않기 때문이다. '시장 출시가 먼저'라는 생각을 하는 이유는 바로 뒤에 여러 무리의 경쟁자가 뒤쫓고 있고, 경쟁자보다 앞서 가려면 가능한 한 빠르게 달려야 하기 때문이다.
요약
어떤 개발 조직이라도 비용과 생산성을 위해 소프트웨어 아키텍처의 품질을 고려해야하며, 좋은 소프트웨어 아키텍처가 무엇인지 이해해야한다.
느낀 점
설계의 중요성에 대해 피상적으로만 알고 있다는 것을 깨달았다. 단지 어떤 디자인 패턴을, 어떤 lint를 써야하는 것과 같은 것이 설계가 아니라 코드를 직접 치기 전 서비스가 어떤 구조로 잡고 가야하는지 고민하고, 추후 비용과 생산성에 영향을 미칠 수 있는 모든 것이 설계임을 깨달았다.
당장 전에 다니던 회사만 해도 위의 인용구에서 말했던 그대로, '코드는 나중에 정리하면 된다. 스파게티 코드라도 전혀 상관없다. 모든 건 시장 출시 이후 생각한다.'라고 하며 생각하고 개발자들끼리 논의하는 것을 지양했다. 이때 나는 설계의 중요도도 몰랐거니와 의견을 낼 수 있는 자리도 아니었기에 별 다른 말을 할 수 없었다.
책이 갈수록 어떤 이야기를 할지 모르겠지만, 내가 설계에 대한 목소리를 낼 수 있도록 근거를 마련하는 데에 도움이 되길 바란다.
2장 두 가지 가치에 대한 이야기
인상 깊은 부분
(17쪽) 소프트웨어가 가진 본연의 목적을 추구하려면 소프트웨어는 반드시 '부드러워'야 한다. 다시 말해 변경하기 쉬워야 한다. 이해관계자가 기능에 대한 생각을 바꾸면, 이러한 변경사항을 간단하고 쉽게 적용할 수 있어야 한다. 이러한 변경사항을 적용하는 데 드는 어려움은 변경되는 범위scope에 비례해야 하며, 변경사항의 형태shape와는 관련이 없어야 한다.
(21쪽) 이러한 도전(아키텍처를 위해 투쟁하는 것)은 당신이 소프트웨어 아키텍트라면 두 배로 중요해진다. 맡은 업무 자체를 봐도 소프트웨어 아키텍트는 시스템이 제공하는 특성이나 기능보다는 시스템의 구조에 더 중점을 둔다. 아키텍트는 이러한 특성과 기능을 개발하기 쉽고, 간편하게 수정할 수 있으며, 확장하기 쉬운 아키텍처를 만들어야 한다.
요약
모든 소프트웨어 시스템은 행위와 구조라는 두 가지 가치를 이해관계자에게 제공하며, 어느 상황이든 구조이자 아키텍처가 최우선이 되어야 한다.
느낀 점
아직까지는 구체적인 방법이 나오지 않아 뜬 구름 잡는 소리로밖에 들리지 않는다. 경험으로 미루어보자면, 스타트업은 매번 기간과의 싸움을 하면서, 서비스 론칭 전까지 기획, 즉 구조가 모호한 경우도 다수이며, 기획에 구멍이 있는데 여기서 설계가 탄탄한 서비스를 개발하는 것은 불가능에 가까운 일이다.
당장에 기획자, 이해관계자가 원하는 뚜렷한 기능은 있으나 전반적인 구조(예상되는 사용자 행동, 플로우, 데이터 관계)가 잡히지 않을 경우 구조는 어떻게 잡기 시작해야할 지 궁금해졌다. 책의 뒷 부분에 이러한 궁금증을 해소시킬 만한 내용이 있으면 좋겠다.
