The Second-System Effect

우리는 디자인하는 것과 실제로 구현하는 것을 아키텍트와 빌더 각각의 관심사로 분리시켰다. 그러면 아키텍트는 더 이상 더 싸고 빠르게 구현하는 것에 대한 책임이 없는데 그들의 invetive enthusiasm은 어디서 올 수 있는가? 그럼에도 아키텍트에게 주어진 제한은 명확하고 이는 지켜야 할 규율로 상호 간의 지켜야 할 것과 스스로 지켜야 할 것으로 존재한다. 

 

첫 번째는 빌더들과 커뮤니케이션할 때 지켜야 할 규율이다. 아키텍트들에게 주어진 제한은 예산이다. 예산에 맞게 디자인이 나와야 하고 여기에는 예측이 들어간다. 이 예측은 실제 빌더들의 구현단계에서 확정되거나 조정된다. 만약 디자인이 예산을 못 맞추게 되면 두 가지 선택지가 있다. i) 디자인을 수정하거나 ii) 더 싼 구현을 요구하는 것이고 이때 빌더들과의 대화에서는 감정이 섞인 대화가 필연적이다. 우선 커뮤니케이션을 일찍 시작해서 지속적으로 하는 것이 가장 중요하다. 그리고 최종 구현 결정은 전적으로 빌더에게 달렸다는 것을  이해해야 한다. 또한 어떤 식으로 구현을 해야 할지 제안할 준비가 항상 되어 있어야 하며 만약 요구사항을 맞추는 다른 구현 방식이 있다면 이를 받아들일 준비 또한 되어 있어야 한다. 그리고 구현상에서 발생한 공적을 포기할 준비가 되어 있어야 한다.

 

두 번째는 스스로 지켜야할 규율이다. 첫 번째 시스템은 대게 성공적이다. 제한된 예산안에서 아키텍트가 자신이 무엇을 해야 하는지 명확히 알고 있기 때문이다. 하지만 이 과정에서 예산 때문에 구현하지 못한 것들이 쌓이고 이 모든 것들이 두 번째 시스템에 들어가게 된다. 그러다 보니 두 번째 시스템은 과도하게 복잡하고 불필요한 기능들로 구성되게 된다. 그리고 첫 번째 시스템을 구현하면서 쌓인 요구사항들이 추후에는 그 가정이 더 이상 성립하지 않게 되어서 불필요해지는 경우가 많다. 그렇다면 이러한 second-system effect를 피하려면 어떻게 해야 할까. 우선 second-system을 구현하지 않는 것이다. 하지만 그럴 수 없으니 이를 잘 인식하고 추가되어야 하는 기능에 명확한 가치를 부여해 보는 것이다. x 기능이 a% 메모리를 사용하고 b% 만큼의 레이턴시를 추가할 만큼 값진 것인가?라는 질문을 스스로에게 물어보는 것이다. 그리고 두 번째는 최소 두 번의 시스템을 만든 경험이 있는 시니어에게 물어보는 것이다.