엔터프라이즈 아키텍처는 냉소적이어야 한다.

회사에 입사를 하고 많은 프로젝트들을 거치며 꾸준히 느끼는 바가 있는데, 기본적으로 엔터프라이즈 아키텍처는 냉소적이어야 한다는 것이다.

 

실제 세상에서 다양한 물리적 혹은 논리적인 이유로 시스템들은 에러를 마주하게 된다. 그 어떤 큰 기업에서 운영하는 시스템도 에러로부터 자유로울 수는 없다는 것은 확실하다.

 

엔터프라이즈 아키텍처는 이러한 현실에 냉소적일 수 있는 아키텍처여야만 한다.

 

다른 API나 모듈 또는 컴포넌트가 언제든 에러를 낼 수 있다고 의심하고, 그들이 주기적으로 에러를 낼 것이라는 가정 하에 스스로를 지킬 수 있는 방벽을 덕지덕지 세워 놓아야만 한다.

 

서킷브레이커 도입을 통해 장애 전파를 막고, try-catch 등을 통해 적절한 레이어에서 적절하게 에러 처리를 할 수 있도록 코드를 짜야 한다. 스레드 풀이나 커넥션 풀과 같이 제한적인 사이즈를 가진 리소스 풀의 경우 해당 사이즈가 적절한지, 그리고 리소스가 경합에 의해 병목이 되었을 때에 운영 담당자에게 어떻게 알릴거나 이를 어떤식으로 로그로 남길지 등 관찰 가능성 역시 충분히 고려해야만 한다.

 

사용자들이 믿을 수 있는 서비스를 만들기 위해서는 그 무엇도 믿지 않는 불신 가득한 아키텍처를 구축해야만 한다는 생각이 문득 들었다.