두 가지 가치에 대한 이야기

행위(behavior), 구조(structure)

• 모든 소프트웨어 시스템은 이해관계자에게 행위, 구조라는 두 가지 가치를 제공해야 한다.
• 소프트웨어 개발자는 두 가치를 모두 반드시 높게 유지해야 하는 책임을 진다.
• 불행히도 개발자는 한 가지 가치에만 집중하고 나머지 가치는 배제하곤 하는데 결국 소프트웨어 시스템이 쓸모 없게 된다.

행위

• 소프트웨어의 첫 번째 가치.
• 프로그래머는 이해관계자가 기능 명세서나 요구사항 문서를 구체화할 수 있도록 돕고, 이해관계자의 기계가 이러한 요구사항을 만족하도록 코드를 작성 및 디버깅 한다.
• 보통 많은 프로그래머가 이러한 활동이 자신이 해야 할 일의 전부라고 생각한다.

아키텍처

• 소프트웨어의 두 번째 가치.
• 소프트웨어 = 부드러움(soft) + 제품(ware) 의 합성어이다.
  • 제품은 상품(product)을 뜻하며, 부드러움(soft)이라는 단어 두 번째 가치가 존재한다.
  • 소프트웨어는 부드러움을 지니도록 만들어졌다.
  • 소프트웨어를 만든 이유는 기계의 행위를 '쉽게 변경'할 수 있도록 하기 위해서다.
    • 만약 기계의 행위를 바꾸는 일을 어렵게 만들고자 했다면 소프트웨어가 아니라 하드웨어라고 불렀을 것이다.
    • 변경사항을 적용하는 데 드는 어려움은 변경되는 범위(scope)에 비례해야 하며, 변경사항의 형태(shape)와는 관련이 없어야 한다.
    • 소프트웨어 개발 비용의 증가를 결정짓는 주된 요인은 바로 이 변경사항의 범위와 형태의 차이에 있다. 이 때문에 개발 비용은 요청된 변경사항의 크기에 비례한다. 또한 개발 첫 해가 다음 해보다 비용이 덜 들고, 다음 해에는 그 다음 해보다 비용이 적게 드는 이유도 이 때문이다.
    • 개발자가 이해관계자의 변경 요구사항이 마치 사각형 마개를 동그란 구멍에 밀어 넣도록 강요 받는 느낌을 받는 것은, 개발자가 구성한 아키텍처가 이미 특정 형태에 대한 선호도를 가지고 있기 때문이다.
    • 따라서 아키텍처는 형태에 독립적이어야 하고, 그럴수록 더 실용적이다..

더 높은 가치

기능 VS 아키텍처 논쟁

(= 소프트웨어 시스템이 동작하도록 만드는 것이 더 중요한가?

VS 소프트웨어 시스템을 더 쉽게 변경할 수 있도록 하는 것이 더 중요한가?)

• 현장에서 늘 부딪히는 논쟁거리임.
• 전자를 주장하는 관리자와 후자를 주장하는 개발자의 입장으로도 볼 수 있음.
• 관리자는 후자의 중요성도 알지만 전자의 경우가 더 중요하다고 얘기함.
  • 그러나 시간이 지나 변경 요청에 대해 변경 비용이 너무 커서 현실적으로 적용하기 어렵다는 답변을 내놓으면, 그 책임은 고스란히 개발자의 몫이 된다..ㅋㅋ

아이젠하워 매트릭스-문제의 우선순위 정하기

• 문제를 두 가지 유형으로 분류하는 것.
  • 중요함(아키텍처) VS 긴급함(소프트웨어)

- 긴급한 문제가 아주 중요한 문제일 경우는 드물고, 중요한 문제가 몹시 긴급한 경우는 거의 없다.
- 소프트웨어의 첫 번째 가치인 행위는 긴급하지만 매번 높은 중요도를 지니는 것은 아니다.
- 소프트웨어의 두 번째 가치인 아키텍처는 중요하지만 즉각적인 긴급성을 필요로 하는 경우는 절대 없다.
- 위 도표는 아래와 같이 우선순위를 정할 수 있음.
    1. 긴급하고 중요한
    2. 긴급하지는 않지만 중요한
    3. 긴급하지만 중요하지 않은
    4. 긴급하지도 중요하지도 않은.
    
    → 아키텍처, 즉 중요한 일은 이 항목의 가장 높은 두 순위를 차지한다.
    
    - 업무 관리자와 개발자가 흔하게 저지르는 실수는 세 번째에 위치한 항목을 첫 번째로 격상시켜 버리는 일이다.
    - 소프트웨어 개발자는 기능의 긴급성이 아닌 아키텍처의 중요성을 설득하는 책임을 가져야 한다.
    

아키텍처를 위해 투쟁하라

• 현장은 각 부서마다 중요하다고 믿는 가치를 위한 투쟁의 장이다.
• 소프트웨어 개발자도 이해관계자임을 명심해야 한다.
  • 소프트웨어를 안전하게 보호해야 할 책임이 있으므로 이해관계가 있는 것.
  • 특히 소프트웨어 아키텍트라면 아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해진다. 이러한 상황이 발생하도록 용납했다면, 결국 소프트웨어 개발팀이 스스로 옳다고 믿는 가치를 위해 충분히 투쟁하지 않았다는 뜻이 된다.