닫는 글 — 다시, 변경 앞에서
이 책은 아키텍처의 그림으로 시작하지 않았습니다. 되돌리기 비싼 결정을 무엇이라고 부를지에서 시작했습니다. 그 출발점을 다시 적으면 이렇습니다.
아키텍처란, 시스템에 대한 결정 중 되돌리기 비싼 것들과 그 근거이며, 구조는 그 결정이 남긴 흔적이다.
열다섯 장 전에는 정의였지만, 이제는 변경을 앞에 둔 날의 질문이 되었습니다. 새 서비스 하나를 떼어 낼 때, DB 스키마를 공유할 때, 규칙을 어디에 둘 때, 팀을 나눌 때마다 이 문장은 더 구체적인 형태로 돌아옵니다.
우리는 무엇을 배웠나
먼저 아키텍처가 풀려는 진짜 문제는 변경이라는 것을 보았습니다. 코드는 오늘의 요구를 통과시키는 것으로 끝나지 않습니다. 다음 요구가 왔을 때 얼마나 넓게 흔들리는지가 구조의 값을 정합니다. 그래서 함께 바뀌는 것은 가까이 두고, 바뀔 법한 것은 경계 뒤에 숨기며, 의존성 화살표는 가장 자주 바뀌는 바깥이 아니라 가장 안정된 정책을 향하게 했습니다.
그다음에는 “좋은 구조”를 감각으로 부르지 않고 품질 속성이라는 말로 바꿨습니다. 변경용이성, 테스트가능성, 가용성, 무결성은 서로 공짜로 늘지 않습니다. 한쪽을 얻으면 다른 쪽의 비용이 따라옵니다. 그래서 목표는 가장 멋진 답이 아니라 우리 상황에서 가장 덜 나쁜 답입니다.
발전사의 장들은 패턴의 목록이 아니라 고통의 지도였습니다. 진흙공에서 레이어드로, 복잡해진 규칙에서 DDD와 헥사고날로, 조직의 조율 비용에서 모듈 경계로, 배포 독립성의 욕망에서 분산의 물리학으로 이어졌습니다. 여기서 가장 중요한 사실은 새 구조가 이전 구조를 “이긴” 것이 아니라는 점입니다. 새 구조는 이전 구조가 감당하지 못한 고통의 비용을 다른 방식으로 지불한 응답이었습니다.
마지막 실전 장들은 그 원리를 실제 일에 연결했습니다. 같은 요구를 다른 구조로 구현해 변경의 diff와 테스트를 비교했고, 달리는 레거시 시스템을 멈추지 않고 이행하는 법을 보았습니다. 데이터 소유권은 코드 경계보다 강하고, 아키텍처는 문서에 쓰는 선언만으로 유지되지 않습니다. 적합도 함수로 계속 확인하고, ADR로 당시의 근거와 대가를 남겨야 합니다.
다음 변경 앞에서
이 책을 다 읽은 뒤에 새 아키텍처를 검토하게 된다면, 패턴 이름부터 꺼내지 않았으면 합니다. 먼저 아래 순서로 상황을 읽어 보세요.
- 어떤 고통이 반복되는가? “불편하다”가 아니라, 어느 품질 속성이 얼마나 부족한지 문장으로 씁니다.
- 그 고통은 정말 구조의 문제인가? 프로세스, 관찰 가능성, 테스트 부재, 팀의 대화 문제를 구조 변경으로 덮으려는 것은 아닌지 확인합니다.
- 무엇을 얻고 무엇을 지불하는가? 비용이 보이지 않는 선택은 아직 이해하지 못한 선택입니다.
- 지금 결정해야 하는가? 포트, 모듈, 설정처럼 선택지를 남기는 구조가 지금의 결정보다 나을 수 있습니다.
- 누가 이 경계와 데이터를 소유하는가? 코드의 선이 팀과 데이터의 현실을 이기지 못한다는 사실을 기억합니다.
- 어떻게 지킬 것인가? 테스트, 린트, ArchUnit 같은 적합도 함수 중 하나를 정하고, 되돌리기 비싼 선택이라면 ADR로 근거를 남깁니다.
이 순서는 정답을 만들어 주지 않습니다. 대신 유행과 불안을 설계 근거처럼 쓰는 일을 막아 줍니다. 아키텍처의 성숙함은 복잡한 다이어그램의 수가 아니라, 무엇을 아직 결정하지 않았는지와 왜 그 결정을 했는지를 말할 수 있는 능력에 더 가깝습니다.
다시, 첫 문장으로
언젠가 익숙한 구조가 답답해질 것입니다. 레이어드가 답답할 수도 있고, 마이크로서비스의 운영 비용이 답답할 수도 있으며, 오래된 모놀리스가 바꾸기 어려울 수도 있습니다. 그때 “요즘은 무엇을 쓰지?”보다 먼저 물어야 할 질문은 하나입니다.
우리는 지금 정확히 어떤 고통을 겪고 있으며, 그 고통은 어느 품질 속성의 결핍인가?
그 질문에 답할 수 있다면, 이 책의 패턴들은 이름표가 아니라 도구가 됩니다. 답하지 못한다면, 구조를 크게 바꾸기보다 먼저 관찰하고 기록할 시간일지도 모릅니다.
아키텍처는 명사가 아니라 동사입니다. 한 번 고르는 일이 아니라, 바뀌는 시스템과 조직의 조건 속에서 경계를 만들고, 검증하고, 필요하면 다시 고르는 활동입니다. 그러니 완벽한 구조를 찾기보다 다음 변경을 더 정직하게 맞을 구조를 만드세요.
유행이 아니라 고통에서 출발하세요. 그리고 중요한 선택에는 근거를 남기세요.