
소프트웨어를 만든 이유는 기계의 행위를 빠르고 쉽게 변경하는 방법이 필요했기 때문이다. 하지만 이러한 유연성은 시스템의 형태, 컴포넌트의 배치 방식, 컴포넌트가 상호 연결되는 방식에 상당히 크게 의존한다.
소프트웨어를 브드럽게 유지하는 방법은 선택사항을 가능한 많이, 그리고 강한 오랫동안 열어 두는 것이다. 그렇다면 열어줘야 할 선택사항이란 무엇일까? 그것은 바로 중요치 않은 세부사항이다.
모든 소프트웨어 시스템은 주요한 두 가지 구성요소로 분해할수 있다. 바로 정책과 세부사항이다.
정책요소란?
정책 요소는 모든 업무 규칙과 업무 절치를 구체화 한다. 정책이란 시스템의 진정한 가치가 살아 있는 곳이다.
세부사항이란?
세부사항은 사람, 외부 시스템 프로그래머가 정책과 소통할 때 필요한 요소지만 정책이 가진 행위에는 조금도 영향을 미치지 않는다. 이러한 세부사항은 입출력 장치, 데이터베이스, 웹 시스템, 서버, 프레임워크, 통신 프로토콜 등이 있다.
아키텍트의 목표는 시스템에서 정책을 가장 핵심적인 요소로 식별하고 동시에 세부사항은 정책에 무관하게 만들 수 있는 형태의 시스템을 구축하는데 있다. 이를 통해 세부사항은 결정하는 일은 미루거나 연기할 수 있게 된다.

- 개발 초기에는 데이터베이스 시스템을 선택할 필요가 없다. 고수준의 정책은 어떤 종류의 데이터 베이스를 사용하는지 신경 써서는 안 된다. 정말이지 신중한 아키텍트라면, 고수전의 정책을 데이터베이스가 관계형인지 분선형인지, 계층형인지, 아니면 평범한 플랫 파일인지와는 관련이 없도록 만들어야 한다.
- 웹서버, REST, 의존성 주입 등도 동일하다. 개발 초기에는 세부사항을 신경 쓰지 않아도 된다.
세부사항에 몰두하지 않은 채 고수준의 정책을 만들수 있따면, 이러한 세부사항에 대한 결정을 오랫동안 미루거나 연기할 수 있다. 이러한 결정을 더 오래 참을 수 있다면, 더 많은 정보를 얻을 수 있고, 이를 기초로 제대로 된 결정을 내릴 수 있다.
또한 이를 통해 다양한 실험을 시도해볼 수 있는 선택지도 열어 둘 수 있다. 현재 동작하고 있는 일부 고수준 정책이 있고, 이들 정책이 데이터베이스에 독립적이라면 다양한 데이터베이스를 후보로 두고 그 정용 가능성과 성능을 검토해볼 수 있다. 웹 시스템, 웹 프레임워크, 심지어 웹 자체에 대해서도 마찬가자다.
선택사항을 더 오랫동안 열어 둘 수 있다면 더 많은 실험을 해볼 수 있고 더 많은 것을 시도할 수 있다.
좋은 아키텍트는 결정되지 않는 사항의 수를 최대화 한다.

![[소프트웨어 아키텍처] 파이프라인 아키텍처란 무엇인가?](https://codecampai.com/wp-content/uploads/2026/01/image-10-768x374.jpg)
![[소프트웨어 아키텍처] 인터페이스 분리 원칙(ISP)에 대해서 알아보자.](https://codecampai.com/wp-content/uploads/2026/01/image-45-768x419.jpg)
![[소프트웨어 아키텍처] 가이드라인을 활용한 프로젝트 관리](https://codecampai.com/wp-content/uploads/2026/01/image-26-768x419.jpg)
![[소프트웨어 아키텍처] 아키텍처의 효율적인 협상 원칙](https://codecampai.com/wp-content/uploads/2026/01/image-27-768x419.jpg)
![[소프트웨어 아키텍처] 체크리스트를 활용한 프로젝트 관리](https://codecampai.com/wp-content/uploads/2026/01/image-25-768x429.jpg)
![[소프트웨어 아키텍처] 소프트웨어 개발/배포에 대한 고찰](https://codecampai.com/wp-content/uploads/2026/02/image-34-768x419.jpg)