클린 아키텍쳐
좋은 프로그램은 무엇인가?
우리가 불완전한 지식에 기초해 행동한다는 사실을 인정할 뿐만 아니라, 불완전한 지식으로 행동하는 것이야말로 인간으로서 우리가 일을 하는 방식이며, 우리의 뛰어난 부분임을 이해한다.
<안티프래질>에서 나심 탈레브가 리스크 예측에 대해 이야기하는 부분과 통하는 부분이 있어서 특히 울림있다. 완벽하게 예측하고 통제할 수 없음을 이해하고 리스크와 비용을 최소화하는 방향으로 의사결정을 하는 것. 정치, 경제 등의 다양한 세상사를 꿰뚫는 본질적인 원리를 안티프래질의 개념을 통해서 설명하려 했던 탈레브의 통찰이 개발에도 적용될 수 있는게 재밌게 느껴진다.
탁월한 개발자는 어떤 고민을 할까?
과거에 팀원들과 Google's Engineering Practices documentation 를 같이 읽고 우리 팀의 리뷰 가이드라인을 만들어보자! 하고 이야기해본 적이 있다. 이때 좋은 규칙을 만들기 위해 우리가 지향해야할 좋은 codebase는 무엇인지 생각해보았는데 쉽게 떠오르지 않아서 조금 당황스러웠다. 그때 당시에 팀원들과 이야기하면서 기록한 메모를 찾아보니 다음과 같이 적여있다 ㅎㅎ
테스트 작성에 용이한가?
작성한 컴포넌트는 순수한가?
관심사 분리가 적절하게 되어있는가?
읽기 좋은 코드인가?
개발자로써 더 나은 지향점을 바라보고 나아가고 있다고 생각하고 있었는데, 그 지향점에 대한 충분한 고민없이 주변에서 좋다라고 말하는 것만 정신없이 흡수하며 코드를 짜고 있지는 않았나 반성했던게 기억이 난다.
정말로 좋은 코드란 무엇일까? 어떠한 코드가 정말 좋은 코드라고 말할 수 있을까? 나는 그 코드를 위해서 어떤 노력을 했나?
그때 당시의 메모는 위와 같은 질문으로 끝이 났다. 여기서 생각을 디벨롭하기에 어려웠는지, 고민하다가 끝나버린 건지는 모르겠지만, 우연하게도 나는 위의 질문에 대한 답의 실마리를 <클린 아키텍처>에서 찾을 수 있었다.
개발자는 무엇을 하는 사람인가?
이 책을 읽으면서 가장 먼저 떠올린 질문은 "개발자는 무엇을 하는 사람이고, 왜 좋은 코드를 짜야할까?" 였다. 나는 개발자로써 어떤 가치를 창출해서 조직에 기여해야하는걸까?
엉클 밥은 이 책에서 소프트웨어 시스템이 제공하는 가치를 크게 두가지로 봤다.
1. 행위 ( 기능 )
2. 아키텍쳐 ( 유동성 )
모든 소프트웨어는 목적을 지닌다. 세상에 제공하고자 하는 가치가 있기 때문에 만들어진다. 그렇기에, 기본적으로 그 가치를 창출하기 위한 기능(행위)이 동작해야 한다. 그런데 그 기능이 완성되었다고 끝이 아니다. 세상은 빠르게 변화하고 거기에 맞춰서 소프트웨어도 발빠르게 변화해야 한다. 이전에 만들어서 효과있었던 기능이 몇 년 후에, 혹은 몇 달 후에는 working하지 않을 수도 있다. 그래서 회사는 자신들이 제공하고자 하는 가치를 어떻게 하면 효과적으로 전달할 수 있을지 끊임없이 고민하고 실험하며, 소프트웨어는 그런 변화하는 요구사항에 유연하게 대처할 수 있어야 한다.
즉, 개발자는 소프트웨어 시스템이 필요로 하는 이 두 가치( 기능, 유동성 )을 위한 고민을 하고 구현하는 사람이다.
그래서, 어떤 고민을 할 수 있을까?
어떤 일을 함에 있어 본질적인 물음을 던질 수 있다면 성장에 큰 도움이 된다. 지향점이 무엇인지를 분명하게 알고, 그것을 끊임없이 상기시켜줄 질문이 있다면 나 자신을 계속해서 계발할 수 있지 않을까? 나에게 좋은 넛지를 줄만한 질문들은 무엇이 있을까를 고민해보았다.
1. 지금 짜고 있는 것은 업무 규칙인가? 세부사항인가? 업무 규칙이 세부사항과 결합되어있지는 않은가?
2. 의존성의 방향이 상위 컴포넌트를 가리키는가?
3. 오버 엔지니어링을 하고 있지 않는가? 지금 하고 있는 추상화로 인해 추후 요구사항이 변경되거나 추가되었을 때 구현 비용이 증가할 여지가 있는가?
4. 요구사항이 변화했을때 수정해야할 코드가 명확하게 구분되어있나?
이러한 질문들에 대한 답을 해가면서 코드를 작성하다보면 자연스럽게 테스트가능한 코드, 관심사 분리, 순수 컴포넌트로 이루어진 프로그램이 만들어져있지 않을까?
아키텍처는 종착지가 아니라 여정에 더 가까우며, 고정된 산출물이 아니라 계속되는 탐구 과정에 더 가까움을 이해해야 좋은 아키텍쳐가 만들어진다.
이 말이 너무 좋았다. 최종 정착지로써의 아키텍처는 없고, 지속적으로 탐구해가면서 완성해가는 아키텍처가 좋은 아키텍처라는 말. 아키텍처라는 단어를 소프트웨어로 바꿔도 여전히 유효할 것 같다. 개발자로써 개발에 대해 다른 관점에서 생각해볼 수 있게 해준 책. 매우 좋은 책인 것 같다.
"소프트웨어는 종착지가 아니라 여정에 더 가까우며, 고정된 산출물이 아니라 계속되는 탐구 과정에 더 가까움을 이해해야 좋은 소프트웨어가 만들어진다"
참고:
