두가지 가치에 대한 이야기

모든 SW 시스템은 이해관계자에게 두가지 가치를 제공한다.
행위와 구조
개발자는 두 가치를 반드시 높게 유지해야 하는 책임을 진다.
불행히도 대부분의 개발자는 한가지에만 집중하고, 다른 하나는 배제하곤 한다.

행위

SW의 첫 가치는 행위다
프로그래머를 고용하는 이유는 이혜관계자를 위해 기계가 수익을 창출하거나 비용을 절약하도록 만들기 위해서다

아키텍처

SW의 두번째 가치는 'SW' 라는 단어와 관련이 있다.
Soft, Ware = 부드러운 제품
SW를 만드는 이유는 기계의 행위를 쉽게 변경하기 위해서다(유연성?)

SW는 부드러워야 한다. 즉 변경하기 쉬워야 한다.
요구사항이 바뀌면 변경사항이 생긴다.
이러한 변경사항을 적용하는 데에 어려움은 범위에는 비례해야 하며, 변경사항의 형태와는 관련이 없어야 한다.

이해 관계자는 비슷한 변경사항을 제시하지만, 개발자 입장에서는 어려운 지시로 느껴진다.
새로운 요청사항이 발생할 때마다 바로 이전의 변경사항을 적용하는 것보다 조금 더 힘들어진다.
-> 시스템의 형태와 요구사항의 형태가 서로 맞지 않기 때문이다.
(병에 네모난 뚜껑을 닫으라는 것)

문제는 아키텍처다. 아키텍처가 특정 형태를 다른 형태보다 선호할수록, 새 기능을 해당 구조에 맞추기는 어렵다.
(이미 정형화된 구조가 있는 상태에서는 어렵다)
아키텍처는 형태에 독립적이어야 하고, 그럴수록 실용적이다

더 높은 가치

기능 vs 아키텍처 어떤 것의 가치가 더 높은가?

  • 기능
    • 시스템이 동작하도록 만드는 것
  • 아키텍처
    • 시스템을 더 쉽게 변경할 수 있도록 하는 것

예를 들어보자

  1. 상황(1)
    • 완벽하게 동작하지만 수정이 불가능
    • 요구사항이 변경될 때, 동작하지 않는다
    • 결국 프로그램은 쓸모가 없어진다
  2. 상황(2)
    • 동작을 하지 않고 변경이 쉬운 프로그램
    • 개발자는 프로그램을 동작하게 할 수 있다
    • 변경이 발생해도 유지보수할 수 있다

불가능한 기능은 없다.
하지만 변경이 없는 서비스/시스템은 없다.

우선수위

긴급함 과 중요도로 나눠보자.

동작시키는 것은 긴급: o, 중요: 기능마다 다름
아키텍처 긴급: x, 중요: o

아키텍처는 언제든 항상 중요도가 가장 높다.

아키텍처를 위해 투쟁하라

이러한 책임(깔끔한 아키텍처를 유지하려는 책임)을 다하려면 ㅅ투쟁해야 한다.
디자인, 관리, 운영, 기획 등 각각의 팀은 각팀의 책임을 다한다.
개발팀도 SW를 안전하고 유연하게 유지해야 하는 책임이 있다.

+ Recent posts