기능 하나를 바꿨을 뿐인데 화면과 API와 데이터베이스를 함께 수정해야 하는 일이 있습니다.

처음에는 작은 변경처럼 보입니다. 버튼 하나를 바꾸거나 상태값 하나를 추가하는 정도입니다. 

그런데 막상 손을 대면 여러 담당자에게 확인해야 하고, 테스트 범위가 넓어집니다.

이런 일이 반복되면 팀은 새로운 요구사항을 반기기 어려워집니다. 

개발자가 일을 못해서가 아니라, 무엇을 바꾸면 어디까지 영향을 받는지 알기 어렵기 때문입니다.

아키텍처를 이야기할 때 많은 팀이 기술부터 떠올립니다. 

마이크로서비스로 나눌지, 어떤 프레임워크를 쓸지, 데이터베이스를 어떻게 구성할지부터 논의합니다.

그런데 제품을 만들면서 더 중요하다고 느낀 건 따로 있습니다.

아키텍처는 복잡한 구조를 만드는 기술이 아니라, 

바뀌어도 되는 것과 쉽게 바뀌면 안 되는 것 사이에 선을 긋는 일이라는 겁니다.

그럼 어떻게 해야, 흔들리지 않는 구조를 만들 수 있을까요?

먼저, 바뀌면 안 되는 것을 정해야합니다

제품 안에는 오래 유지해야 하는 업무 규칙이 있습니다.

어떤 조건에서 주문을 승인하는지, 사용자의 상태를 어떻게 판단하는지, 

팀이 어떤 순서로 업무를 처리하는지 같은 것들입니다.

반면 화면, 데이터베이스, 외부 API, 프레임워크는 상황에 따라 바뀔 수 있습니다. 

문제는 이 둘이 너무 가까이 붙을 때 생깁니다.

화면을 바꾸려 했는데 핵심 업무 규칙까지 수정해야 하고, 데이터베이스를 바꾸려 했는데 

제품의 동작 방식이 달라집니다. 

외부 서비스 하나를 교체하는 일이 제품 전체의 일정으로 번지지 않는 구조가 되어야 하죠.

처음부터 크게 나눌 필요는 없습니다

아키텍처를 이야기하면 처음부터 모든 것을 서비스 단위로 분리해야 한다고 생각하기 쉽습니다.

하지만 초기 제품에서는 단순한 구조로 시작하는 편이 합리적일 때가 많습니다. 

중요한 건 지금 몇 개로 나눴는지가 아니라, 나중에 필요할 때 분리하거나 

교체할 수 있는 경계가 남아 있는지입니다.

프로젝트 초반에는 어떤 요구사항이 오래 남을지 알기 어렵습니다. 

그런데 데이터베이스나 외부 API를 핵심 로직에 묶어버리면, 나중에 바꾸는 비용이 커집니다.

미래를 정확히 예측하는 구조를 만들기는 어렵습니다. 

대신 미래를 모른다는 사실을 전제로 변경의 범위를 제한할 수는 있습니다.

작은 변경이 큰 수정으로 번지는 곳을 찾아야 합니다.

구조를 볼 때는 기술 이름보다 변경의 흐름을 먼저 봅니다.

어떤 기능을 바꿨을 때 화면과 저장 방식과 업무 규칙이 모두 따라 움직인다면, 그 사이의 경계를 다시 볼 필요가 있습니다. 팀의 업무도 비슷합니다. 모든 책임과 정보가 한 사람의 기억이나 한 개의 대화에 묶여 있으면 작은 변경에도 전체 맥락을 다시 확인해야 합니다.

좋은 아키텍처는 미래를 맞히는 설계가 아닙니다. 

미래를 맞힐 수 없다는 사실을 받아들이고, 

필요한 부분만 바꾸고 다시 움직일 수 있게 선택지를 남겨두는 설계입니다.