Ch09. 간결함

1. 안정성 vs 신속성

시스템의 안정성과 신속함 중 어떤 것이 중요할까? 주요 프로덕션 소프트웨어 시스템의 경우라면, 안정성과 신속함의 적절한 균형을 원할 것이다. SRE는 절차와 사례, 그리고 도구를 만들어 좀 더 신뢰성 있는 소프트웨어를 구성하기 위해 일한다. 마찬가지로 SRE는 이런 작업들이 개발자들의 신속성에 가능한 영향을 미치지 않도록 일한다. 하지만 신뢰성을 위한 프로세스는 개발자들의 신속성을 오히려 높이는 경향이 있다.

 

2. 지루함의 미덕

소프트웨어 분야에서 '지루함'은 긍정적인 요소이다. 대부분의 개발자들은 프로그램이 자생적이고 흥미로운 어떤 것이기를 원하지 않는다. 스크립트 내에 가만히 앉아서 자신들의 비즈니스적 역할을 예측 가능한 상태에서 수행하기만을 바랄 뿐이다. 프로덕션 환경에서 뭔가 놀라운 일이 일어난다는 것은 SRE에게는 재앙이나 다름없다.

 

3. 내 코드는 절대 포기하지 않을 거야!

엔지니어 역시 사람이고 자신들의 창조물에 감정을 이입하는 경향이 있으므로 소스 트리의 대규모 정리에 대해 반감을 갖는 것은 그다지 놀라운 일이 아니다. 누군가는 "이 코드가 나중에 필요하면 어쩌려고?" 라든가 "그냥 나중에 필요할 때 쉽게 돌려놓도록 주석 처리하는 게 어때?"라며 항의하기도 한다. 전부 다 헛소리다. 소스 제어 시스템으로 변경을 쉽게 되돌릴 수 있는데, 수백 줄의 코드를 주석으로 처리하는 것은 코드를 산만하게 만들고 혼란만 가중시킬 뿐이다.

 

예전에는 위의 말을 공감했지만 요즘에는 오히려 자신의 코드의 정리가 필요할 때 적극적으로 의견을 받아들이는 것 같다. 나 또한 그렇다. 잘못을 했다고 꾸짖는 문화가 아니라서 그런 것 같기도 하다.

 

4. 최소한의 API

"완벽함이란 더 이상 추가할 것이 없을 때가 아니라 더 이상 걷어낼 것이 없을 때 비로소 완성된다"라는 말이 있다. 너무 공감된다. 더 이상 추가할 것이 없을 때가 존재할까? 더 이상 걷어낼 것이 없을 때는 추가로 들어온 피드백도 빠르게 반영 가능하기 때문에 완벽한 상태라고 생각한다.

 

위의 말을 더 정확히 표현하면, API를 최소화하는 것은 소프트웨어 시스템의 간결함을 추구하기 위한 가장 기본적인 관점이다. 사용자에게 제공하는 API의 메서드와 매개변수를 줄인다면, 더 이해하기 쉬울뿐더러, API를 최대한 잘 만드는 데 더 많은 노력을 들일 수 있다.

 

소프트웨어에서는 더 적은 것이 오히려 더 나은 점이 많다! 작고 간결한 API는 그만큼 문제를 잘 이해했다는 보증수표이기 때문이다.

 

+) 책에서는 API를 버전별로 관리하면 시스템이 예전 버전의 API를 사용하는 동안 개발자가 새로운 버전을 안전하고 적절한 방법으로 추가할 수 있다고 한다. API 마다 버전별로 관리하면 분명히 시스템을 안정적으로 관리할 수 있을 것 같지만 반대로 관리 포인트가 많이 늘어나는 것이 아닐까라는 생각도 있다. 혹시 여러분의 생각은 어떠하신가요?

 

5. 릴리즈의 간소화

여러 변경을 동시에 릴리즈하는 것보다는 하나의 변경을 릴리즈하면서 그 영향을 이해하고 분석하는 것이 훨씬 쉽다는 것은 자명하다. 만일 시스템이 100개의 서로 무관한 변경 사항을 동시에 릴리즈했는데, 성능이 저하되었다면 어떤 변경이 성능에 영향을 미쳤는지, 그리고 왜 그런 일이 발생했는지 알아내기 위해서는 더 많은 노력이나 추가 작업이 필요할 것이다. 릴리즈를 더 작은 단위로 수행할 수 있다면 더 강한 확신을 가지고 움직일 수 있다. 그 이유는 대형 시스템 내에 발생한 각각의 코드 변경에 대해 충분히 이해할 수 있기 때문이다.

 

6. 결론

이번 장에서는 소프트웨어의 간결함은 신뢰성을 위한 사전 조건이라고 강조하고 있다. 신뢰성뿐만 아니라 신속성에도 영향을 준다고 생각하며, 간결함을 통해 유지 보수도 수월하게 할 수 있다고 생각한다. 앞으로는 어떤 작업을 할 때 어떻게 하면 최대한 간결하게 구현할 수 있을지 고민해 봐야겠다.