유지보수 비용을 기준으로 왜 기술은 보수적으로 선택하고, 관행과 도구는 더 과감하게 실험할 수 있는지에 대한 글.
유명한 글 Choose Boring Technology는 혁신적인 기술을 사용하는 데 두 가지 문제가 있다고 말합니다:
이 두 가지는 모두 기술의 주된 비용이 유지보수라는 생각으로 이어집니다. 무언가를 만들기 쉬운 것과 그것을 계속 운영하기 쉬운 것은 다를 수 있습니다. 우리는 핵심 업무에 쓰이는 기술을 "버릴" 수 없습니다. 이를테면 우리 팀이 Julia로 새로운 서비스를 만들고, 2년 뒤 그것이 잘못된 선택이었다고 판단했다고 합시다. 그러면 우리는 data to Postgres code to Java 전체를 마이그레이션하는 (비싼) 과정을 거치거나, 아니면 어쨌든 그것을 계속 운영하는 (비싼) 과정을 감수해야 합니다. 어느 쪽이든 회사는 엔지니어들이 다른 유용한 것들, 예를 들면 머릿속으로 크립토를 채굴하는 법 같은 것 대신 그 기술에 익숙하도록 자원을 써야 합니다.
기술은 변화가 느립니다. 예를 들어 다리만큼 느리지는 않지만, 그래도 꽤 느립니다.
이제 Julia를 도입한 동시에 test && commit || revert (TCR)도 실천하기 시작했다고 해봅시다. 2년 뒤 우리는 그것에도 질릴 수 있습니다. 이 문제를 해결하는 방법은 그냥... 더 이상 TCR을 하지 않는 것입니다. 우리가 지원해야 할 "레거시 관행"은 없고, 프로세스를 버리는 데 따르는 유지보수 부담도 없습니다. 관행을 도입하고 버리는 일은 기술을 도입하고 버리는 일보다 훨씬 쉽습니다.
이는 우리가 사용하는 소프트웨어에서는 보수적이어야 하지만, 그것을 사용하는 방식에서는 더 자유롭게 혁신적일 수 있음을 뜻합니다. 기술에 대해 혁신 토큰이 세 개 있다면, 관행에는 여섯 개나 일곱 개쯤 있다고 할 수 있습니다. 그리고 관행을 되돌리면 그 토큰도 다시 돌려받을 수 있습니다.
(이것의 이면은 사회적 프로세스가 기술보다 덜 "안정적"이며 계속 굴러가게 하려면 더 많은 노력이 든다는 점입니다. 그래서 "공학적 통제"가 관리적 통제보다 사고를 줄이는 데 더 효과적이라고 여겨집니다.)
이 주장을 더 밀고 나가면, 우리는 기술을 두 범주로 나눌 수 있습니다: "재료"와 "도구".1 재료는 비즈니스를 뒷받침하기 위해 돌아가야 하는 모든 것입니다. 우리의 코드, 서비스 아키텍처, 데이터 그리고 데이터베이스 엔진 등이 여기에 해당합니다. 도구는 우리가 재료를 만드는 데 쓰지만, 재료가 그것에 의존하지는 않는 것들입니다. 에디터, 개인용 bash 스크립트 같은 것들입니다. 이 범주는 경계가 흐릿하지만, 결국은 "프로젝트가 이것을 잃으면 얼마나 큰일인가?"로 요약됩니다.
그리고 도구는 재료보다 교체하기 쉬우므로, 우리는 그것에 대해 더 혁신적일 여유가 있습니다. 실제로도 사람들이 데이터베이스를 바꾸는 것보다 일시적인 것들을 더 빨리 교체하는 모습을 볼 수 있다고 생각합니다.
(이 글이 짧은 이유는, 이 주제로 내가 얼마나 많이 쓸 수 있을지 심하게 과대평가했기 때문입니다.)
이제 일주일 남았습니다! google form으로 April Cools를 제출할 수도 있고, 아주 멋지고 기술적으로 하고 싶다면 github PR로도 제출할 수 있습니다.
