소프트웨어도 최대한 간결할수록 좋다.

복잡하다고 잘 만든 시스템이 아니다. 최대한 간결해야 한다. 

SRE의 임무는 시스템의 신속함과 안정성 사이의 균형을 유지하는 것이다. 여기서 신속함과 안정성의 균형을 유지하려면 필수적인 요소가 간결함이다. 

완벽함이란 더 이상 추가할 것이 없을 때가 아니라
더 이상 걷어낼 것이 없을 때 비로소 완성된다

- 프랑스 시인 '생택쥐페리' -

소프트웨어의 디자인에서도 위의 말이 적용된다. 조금 더 정확히 표현하면, API를 최소화하는 것은 소프트웨어 시스템의 간결함을 추구하기 위한 가장 기본적인 관점이다. 우리가 소비자에게 제공하는 API의 메서드와 매개변수를 줄인다면, 그 API는 더 이해하기 쉬워진다. 이와 같이 소프트웨어에서는 간결하면 간결할수록 오히려 더 나은 점이 많다.

모듈화

간결함을 추구함에 있어서 프로그래밍에서는 모듈화를 적극 활용하려고 한다. 시스템의 일부에 '독립적으로 변경을 추가할 수 있는 능력'을 지속 가능한 시스템에서는 기본적인 것이다. 느슨한 결합은 개발자의 신속함과 시스템의 안정성을 동시에 향상시킬 수 있는 간소화 패턴이다. 

느슨한 결합으로 잘 구성된 시스템에서는 특정 컴포넌트에서 버그가 발견된다 하더라도 다른 컴포넌트에 에러 전파가 많이 일어나지 않게 된다. 만약 느슨한 결합으로 구성되어 있지 않다면 한 API를 변경할 때도 전체 시스템을 다시 빌드해야만 한다. 

시스템이 복잡해짐에 따라 API, 컴포넌트, 모듈에 대한 역할 분담의 중요성은 점점 더해져간다. 이것은 객체지향 클래스 디자인과 일맥상통한다. 관계가 없는 기능들을 모두 가지고 있는 하나의 큰 클래스를 작성하는 것은 좋지 않은 사례라는 것이 널리 알려져 있는 것처럼, 시스템에 util 같은 모듈을 만들어 배포하는 것 역시 좋지 않은 사례다. 잘 디자인된 분산 시스템은 명확하고 분명한 범위의 목적을 가진 바이너리들로 구성된다.

불필요한 코드는 당장 지워!

누군가는 "이 코드가 나중에 필요하면 어쩌려고?"라든가 "그냥 나중에 필요할 때 쉽게 돌려놓도록 주석 처리하는 게 어때?" 혹은 "지우지 말고 그냥 플래그만 달아두면 안 돼?"라며 항의하기도 한다. 

"전부 다 헛소리다."

버전 관리 시스템(Git)으로 변경을 쉽게 되돌릴 수 있는데, 수백 줄의 코드를 주석으로 처리하는 것은 코드를 산만하게 만들고 혼란만 가중시킬 뿐이다. 그리고 전혀 실행된 적이 없는 코드나 항상 비활성화 상태의 플래그가 설정된 코드는 마치 시한 폭탄 같은 것이다.

한 번에 많은 코드를 배포하지마!

일반적으로 간결한 릴리즈가 복잡한 릴리즈보다 낫다. 여러 변경을 동시에 릴리즈하는 것보다는 하나의 변경을 릴리즈하면서 그 영향ㅇ르 이해하고 분석하는 것이 쉽기 때문이다. 

만약 시스템에 100개의 서로 무관한 변경 사항을 동시에 릴리즈했는데, 성능이 저하되거나 버그가 발생했다고 가정하자. 그러면 원인을 파악하기기 굉장히 어렵다. 

따라서 릴리즈는 한 번에 큰 단위로 수행하는 것보다, 여러 번 작은 단위로 나눠서 수행하는 것이 훨씬 좋다. 

결론

소프트웨어에서의 간결함은 신뢰성을 위한 필수 전제조건이다. 따라서 소프트웨어를 최대한 간소화하는 방법을 찾으려는 노력을 꾸준히 해야 한다. 어떤 문제를 해결하기 위해서 멋있어 보이는 기술, 최근 기술을 선택하는 것보다 훨씬 간결하고 빠르게 해결할 수 있는 해결책을 선택할 줄 알아야 한다.