아키텍처에 다들 정답이 없다고 말하곤 합니다. 클린 아키텍처를 예시로 들어보자면, 사용성이 없는 코드들을 만드는 비용과 아키텍처의 이상(ideal)을 만들기 위해 논쟁이 일어나곤 합니다.
하지만 제 생각은 다릅니다. 사업이 목적이라면, 비용 대비 비즈니스 가치가 가장 큰 것이 정답이지 않을까요? 사업가의 목표에 가장 가까운 것이 정답이라고 생각합니다. (반례로 사업가의 목표가 비용이 많이 쓰는 것이라면 제 말에 오류가 있을 수 있을 것 같습니다)
그러면 비즈니스 가치를 가장 크게 만들기 위해선 어떻게 할 수 있을까요?!
여기서 오류가 발생합니다. 썸네일에 계신 분이면 알고 계실 수도 있겠네요.
비즈니스 가치를 가장 크게 만드는 법을 알고 계신다면, 아마 개발자보다 사업가에 가깝고, 사업가보다 예언가에 가깝다고 생각합니다. (필자는 예언가를 믿지 않습니다)
그 많은 요소들 그나마 최적의 방법을 찾는 것은 경험에서 나올 것입니다.
다양한 상황을 고려할 수 있는 지식에서 나오는 것이겠죠. 하나의 작은 도메인에서 어떤 아키텍처가 비용대비 가치가 가장 높았는지, 여러 경험과 지식을 통해 알 수 있을 것입니다.
결론은 정답이 없다는거네요?
네 관심을 이끌어서 죄송합니다. 저희는 미래를 계산하여서 제가 말한 '정답'을 찾는 행동은 불가능에 가깝다고 도출됩니다. 각 상황에 대한 최적의 아키텍처가 모두 소프트웨어 공학에 쌓이지 않는 이상 앞으로도 아키텍처에 대한 토론은 지속될 것으로 생각됩니다.
제가 하고 싶은 이야기는요
정답이 없는 문제고 최적의 방안을 우리는 모르기 때문에, 계속 팀원들과 토론해야합니다. 이는 개발자간의 토론일 수도 있고, 아키텍처에 대한 고민을 할 시간을 요청하기 위해 PM 등 기획단, 사업단과 토론을 해야할 수도 있습니다.
아키텍처에 대한 의견공유는 필연적으로, 지속적으로 일어나야합니다. 또는 이해가 안가는 부분은 짚고 넘어가야합니다. 여러가지 고민의 대한 저의 생각을 남깁니다.
- 아키텍처가 바뀌었을 때, 작동 중인 레거시는 남기되 추후 시간이 여유로우면 리팩토링을 해봅니다.
- 아키텍처의 의견이 더이상 안좁혀지면, 그 상태로 진행을 해봅니다. 추후 다른 아키텍처로 변경 및 리팩토링을 하며 이전 아키텍처의 장단점을 톺아봅니다.
- 아키텍처가 바뀐 히스토리는 기록되어야 합니다. 히스토리는 레거시의 컨벤션입니다.
- 이런 토론을 깊어지면 감정이 상하는 것은 당연합니다. 이를 인정은 하되, 표출을 어른스럽게 해봅니다.
