[SW Architecture] 불변의 법칙

 

고객은 본인이 원하는 결과물을 100프로 알지 못한다.

소프트웨어를 설계하기 위해 고객의 요구사항을 경청하고 정리하고 이끌어내는 과정은 매우 중요하다. 고객들 중 대다수는 자신이 원하는 결과물이 어떠한 형태로 만들어지고 어떠한 기능이 있어야 하는지 대략적으로만 설명하고, 중요한 기능들을 놓치는 경우도 많다. 이러한 요구사항을 최대한 이끌어내고 추후에 주어질 요구사항에 대비해야 하는게 소프트웨어 아키텍트로서의 중요한 자질이고 아키텍트로서의 즐거움일 것이다.

 

소프트웨어의 변화는 변하지 않는 불변의 법칙

고객의 요구사항은 항상 변경될 수 있고 추가 또는 제거될 수 있다. 이것은 소프트웨어 설계의 불변의 법칙 이다. 변하지 않는 소프트웨어는 없고, 발전되지 않는 소프트웨어는 존재하지 않는다. 만약 그렇다면 아키텍트와 개발자들을 매우 우울하고 재미없는 일을 하게 될지도 모른다. 변하지 않다면 누가 구조에 대해 고민하고 발전을 위한 노력을 하겠는가. 

 

미래를 예언할 순 없다. 하지만 대비할 수는 있다.

우리는 미래를 완벽하게 예언할 수 없다. '고객이 다음 달에 이러한 기능을 추가 요청할거야, 내년에 기존의 기능이 전부 바뀌길 원할거야' 이걸 예언하고 맞힐 수 있다면 얼마나 좋을까. 하지만 우리에겐 그러한 능력은 존재하지 않는다. 가끔 상상해본다. 미래를 알 수 있다면 매우 살아가는게 재밌을까? 가끔 골치아픈 고객의 주문은 이러한 능력을 간절히 원할 때도 있다. 하지만 이상은 빠르게 정리하고 현실로 돌아와 고객의 요구사항에 맞춰 개발을 해야하는게 우리 개발자들의 역할이다. 설계가 어렵고 재미있는 이유도 오늘 요청된 기능이 내일 변경될 수 도 있다. 그리고 그러한 요청을 수용하고 받아 들일 수 있는 구조와 코드를 만들어야 한다.

우리는 미래를 예언할 수는 없지만 대비는 할 수 있다. 아키텍트로써, 개발자로써 고객의 요구사항 중 변경이 필요한 부분에 대해 판단하고 대비는 할 수 있다. 물론 모든 변경에 대해 파악하고 대비를 할 순 없다. 그런 능력이 있다면 미래를 예언하는 능력을 가진것이다. 아키텍트는 가장 자주 변경될 부분을 파악하고 변경에 대한 요구사항이 발생하였을 때도 변경의 범위가 최소화 될 수 있도록 안정된 구조를 가져가야 한다. 그러한 노력은 개발이 진행되고 고객의 니즈가 지속적으로 추가될 때 큰 빛을 발할 것이다.

 

그래도 가끔은 원한다.

'미래를 가끔을 알 수 있다면 얼마나 좋을까' 라고, 그렇다면 더 좋은 구조와 코드를 창조해낼 수 있었을텐데 라는 아쉬움은 항상 가지게 된다. 그렇기에 후회하고 아쉬워하지 않기 위해 스스로 발전해야 한다. 그리고 이러한 고민을 하고 있을 모든 아키텍트와 개발자들을 응원한다.