지난달부터 팀원들과 국내 신규 번역 발간된 로버트 C. 마틴의 클린 아키텍처 읽어보기 스터디를 진행하고 있다. 이 아저씨의 '클린' 시리즈가 유명하디 유명한 명서들이란 것은 두말하면 잔소리인데, 우연찮게 발간 사실을 빠르게 알게 되어 고민없이 이 책을 선정해 스터디를 제안 했다.

현재까지 약 70% 정도 읽었는데, 역시나 좋다. 기대했던 것 보다 더. 사실 따지고보면 클린 소프트웨어에서 다뤄졌던 많은 내용들이 중복되긴 하지만, 그 관점이 살짝 다르고, 개인적으로는 그 관점과 설명이 클린 소프트웨어보다 더 잘 와 닿는다.

목차를 훑어보면 SOLID 를 다시 짚는다던지, 개념적으로 대략 알고 있고 뻔한 내용일 것 같은 부분들이 다수 존재하지만, 중복 내용에 대한 우려를 포함해 구매를 주저하는 분들이 있다면 개인적으로는 정말 주저할 필요 없이 읽어보라고 권하고 싶다. 이 아저씨의 설명 방법과 디테일한 포인트를 집어주는 부분들이 개인적으로는 정말 만족스럽다. 다만 디테일한 포인트들이 산재한 만큼 쉽게 쉽게 읽어지는 책은 아니다.

모든 챕터들의 내용들을 요약 정리해두고 싶지만, 본격적인 내용들을 블로그에 게시하는 것은 여러모로 문제가 있는 것 같아, 본격적 내용에 들어가기 전 도입부 (1부 - 소개) 의 두 챕터 내용들을 살짝 정리하고 부분별로 개인적 감상 혹은 경험을 첨부하여 올려 본다.

1장 설계와 아키텍처란?

  • 아키텍처와 설계의 차이

    • 아키텍처는 고수준의 결정사항
    • 설계는 저수준의 구조, 세부사항
    • .. 를 의미하는 경향이 있으나, 실제로 다를 것은 없다.
    • 결국 소프트웨어 구조 전체의 구성요소들
    • 고수준과 저수준의 경계는 모호하다.
    • 고수준에서 저수준으로 향하는 의사 결정의 연속성만이 있을 뿐
  • 코드 품질을 고려하자

    • 코드는 나중에 정리하면 돼

      • 이게 지켜지는 경우는 없다.

      경험상 정말 없다. ...아주 드물게 가끔?

      어쩌다 천재일우의 기회가 오더라도 고쳐야할 범위의 방대함에 의욕 상실.
      그리고 옆에서 누군가의 걱정. 사이드 이펙트가 많이 없어야 할텐데 ... 나도 무서워.
      그냥 생긴대로 쓰자.. 라는 맥빠지는 결론이 되기 쉽다. 단위가 클 수록.

      상상 이상의 용기와 결단력. 무모함. 그리고 모두의 고통이 필요하다.

      • 우선 출시하는게 중요하다!?

      우선 출시를 중요시한 제한된 구조라고 강조, 또 강조하며 결국 출시가 되더라도
      뒤따르는 확장 니즈에 미리 언급했고 그리도 강조했던 제한된 구조는 안중에 없다.
      왜 그런거야? -> blah.. blah.. -> 알고싶지 않아. 내가 그걸 알아야되? -> ...

      제한된 구조는 합의됐던 사항이라는 항변은 오히려 나를 죽이는 칼로 돌아오기 쉽다.

      아무도 도와주지 않아. 그냥 내가 나쁜 놈임.

      • 마일스톤이 끝나면 다음 마일스톤이 기다리고 있으며, 일정의 압박은 계속된다. 쭈..욱..
    • 단기간 아웃풋을 위한 코드?

      • 지저분하게 막 짜는 코드가 당장의 속도면에서 우선 더 빠르다는 것은 잘못된 고정 관념

      이건 기능 단위에 따라 좀 달라질 법한 이야기가 아닐까? 싶음

      • 실제로 막 짜는 코드는 항상 느리다. TDD 를 활용해서 코드 품질을 높여라.

      테스트는 경험상으로도 정말 유용하고, 유용하기에 중요하다.

      막 짜더라도 돌아가는지 어차피 확인은 필요한데,
      그 확인을 위한 주먹구구식 과정은 어차피 생각 이상의 시간이 소요된다.

      경험상 잘 짜진 테스트 코드는 다음 스탭의 코드 작성에도 유용하고,
      다음 스텝의 로직 테스트 과정에서 이전 코드의 신뢰성을 스스로 쌓을 수 있다.
      단지 테스트 코드 구조를 처음부터 차곡차곡 쌓아가는게 귀찮은 일이라는게 문제.

      작은 로직들을 모아 긴 로직이 완성되어 가는 과정은 즐겁고 재밌다.(!?)
      구현에 달려나가다보면 이걸 완성하는걸 우선시하는 경향이 생기고
      완성되고 나면 작은 단위로 쪼개서 하나하나 테스트 코드를 작성하기란 더더욱 귀찮아 진다.

      하지만 설령 테스트 코드를 작성하며 기능들을 완성해가지 않았더라도,
      완성 후라도 단위 테스트 코드들을 작성해 두는 것은 후일을 위해 나쁘지 않은 작업이라 생각한다.

      • 빨리가는 유일한 방법은 제대로 가는 것.
    • 개발자는 코드 품질에 대한 책임을 져야 한다. 개발자의 임무 중 하나.

      사실 맞는 말이지만 무서운 이야기. 이 아저씨 뒤통수 제대로 치고 시작한다.

      자신의 능력 내에서 그걸 지키고 싶지 않은 개발자는 없다. .. 고 변명을 하며 2장으로.

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

  • 소프트웨어가 이해 관계자에게 제공하는 두 가지 가치

    • 행위

      • 소프트웨어의 직접적 가치이자 목적.
      • 수익창출, 비용절감
    • 구조

      • 소프트웨어는 부드러움 (soft) 를 가짐. -> 쉽게 변경할 수 있어야
      • 변경에 들어가는 비용은 변경의 범위 (scope) 에 비례해야 하며, 변경의 형태 (shape) 에 영향받지 않아야 한다.
        • 시스템의 형태와 요구사항의 형태가 다르면 비용이 크게 증가
        • 아키텍처는 형태에 독립적이여하며, 그럴수록 실용적

      범위와 형태의 구분은 사실
      경우에 따라, 표현에 따라, 이해에 따라,
      각자가 받아들이는 실체가 달라지기 쉽기 때문에 명확한 구분이 어렵게 느껴진다.

      다만, 코드 레벨로 이걸 일반적으로 풀어보자면
      단위 기능 정의를 위한 인터페이스의 갯수가 범위 (구조의 갯수),
      구현체의 상세 부분들을 형태로 받아들여야 하지 않을까?

  • 기능과 아키텍처 중 어느것의 가치가 더 높은가?

    • 동작하는 것이 중요한가? 쉽게 변경 가능한 것이 중요한가?

      • 완벽하게 동작하지만 변경 불가한 프로그램
      • 당장 동작하지 않지만 수정하여 돌아갈 수 있는 프로그램
    • 개발자는 아키텍처에 더 큰 가치를 둬야 한다.

      사실 개발자 뿐 아니라 사용자 (관리자) 역시 마찬가지가 아닐까?
      바꿀 수 없는 프로그램이 무슨 의미인가?
      다만 그들에겐 그들의 '일' 이 아니기에 당장 눈에 보이는 기능에 더 가치가 있어 보일 뿐

    • 관리자는 항상 당장의 동작에 관심의 포커스를 맞추지만, 당장의 동작 요구는 세부사항만 다를 뿐 계속된다.

      • 변경을 위한 비용이 커져 현실적으로 적용하기 어렵게 되면 시스템 방치, 관리에 대한 비난

      앞장에서도 나온 이야기지만 가장 두렵고 대처하기 어려운 상황.

      대부분의 실무 상황에서는 실제 필요 비용은 중요하지 않고,
      정해진 비용안에서 변경이 결국 임무가 되기 때문.
      실제 필요 비용과 정해진 비용의 간극은 개발자의 노오력으로 체워야함. (짤리거나?)

      업무에 치인다는 핑계로 구조를 간과하면 그 결과가 눈덩이가 되어 결국 돌아올 것.

      폭탄 돌리기가 될 것이다.

  • 일의 중요성과 긴급성을 구분하라

    • 긴급하지만 중요하지 않은 일과 긴급하면서 중요한 일의 실체를 구분하라
      • 업무 관리자는 잘 모른다.
    • 개발자의 존재 이유는 더 큰 가치 판단을 하며, 그 판단을 지키기 위해
      • 그것이 개발자의 책임
      • 소프트웨어를 안전하게 보호하는 것이 책무이자 역할. 고용된 이유.
      • 투쟁하라. 싸움판에 뛰어들라. ...(첨언 아님)
      • 아키텍처의 가치를 지키고 보존하기 위해 노력하라.

    IT 서비스는 형태와 용도가 어떻건 기본적으로 상품이고,
    그 상품을 만드는 것이 개발이다.

    상품은 팔리기 위한 매력 포인트와 전략이 있어야 한다.
    그것이 시기일 수도 있고, 디테일 일수도 있고. 이건 케바케의 영역.
    그럼에도 이유불문하고 빨리, 많이 만들 수 있을 수록 세일즈 포인트상 좋다는 것은
    상품에 있어 사실 너무 당연한 이야기이다.

    그 당연한 속성에 대한 니즈가
    결국 개발자와 관리자 사이의 간극을 만드는 가장 큰 요인이라 생각된다.

    어떤 개발자인들 자신이 만들어가고 있는
    소프트웨어의 품질을 신경쓰고 싶지 않겠는가?

    하지만 상품이 가지는 본질적 특성 아래
    빠른 일정을 요구하는 업무 요청자의 요구에 맞서기란 쉽지 않다.
    같은 상품을 두고 업무를 하지만
    상품을 중심으로 한 입장의 위치부터가 불리할 수 밖에 없으니까.
    그리고 바보가 아닌 이상 빠른 일정이 상품에게 주는 장점을 개발자도 아니까.

    내가 말한 빠른 일정에 맞서기 어렵다는 것은,
    어처구니 없는 수준으로 공수 산정이 완전 잘못된
    불합리하고 무리한 일정을 말하는 것은 아니다.
    공수 산정의 범위에서
    소프트웨어 품질 유지를 위한 노력이 배제된 측면의 일정을 말하는 것

    개인적으로 기술 중심적 기업이라는 표현은

    최첨단의 기술을 화려하게쓰며
    기술 난이도 적으로 업계를 선도해가느냐가 척도가 될 수도 있지만,

    판매 이면에서 상품의 기술 분야가 중시하는
    내면의 가치를 대하는 태도 역시 중요한 척도로 볼 수 있다고 생각한다.

    두번째로 언급한 내면의 가치를 대하는 태도가
    적어도 최소한의 상식적 수준을 유지하는 곳이어야
    책에 언급된 격한 표현의 투쟁과 싸움, 고상한 표현의 설득이 시도라도 일어날 수 있다.
    그 수준이 갖춰지지 않은 곳이라면 그 시도가 괴팍한 개발자의 깽판 정도로 비춰지겠지.

    그럼에도 당장의 환경이 받춰주느냐 마느냐,
    시도를 하느냐 마느냐는 두번째 문제고,

    개발자라면
    첫째로 가능하면 주어진 환경 내에서 최대한 좋은 구조를 유지할 수 있어야 하고
    둘째로 그 설득을 시도할 능력이 있어야 한다는게 내 생각이고 목표하는 바이다.

    그러므로 이 책의 내용을 토대로 공부하면서
    좋은 구조를 유지할 수 있는 방법과 설득하기 위한 지식을 고민하려 한다.

    첨언이 길어지는데,
    개인적으로 이 책을 읽고자 했던 모호하면서도 궁극적인 목적을
    도입부에서 좀 더 구체적이고 선명하게 느낄 수 있도록
    고취시켜주는 것에 시작부터 높은 만족감을 느꼈다.

    어떤 곳에서는 깽판이라 비춰질 수 있는 개발자의 입장과 책무를
    '완전히 너의 임무' 라는 어떻게 보면 무서운 전제를 깔고 있음에도
    그렇게 하는 것이 맞다고 분명히 말해주는 것이 일종의 힐링이자 위안, 안도감을 준다.