2장. 변화에 드는 비용

문법식·2022년 11월 5일
0

이 책 전반에서 작고 점진적인 변화를 해야 한다고 강조하는 데에 여러 이유가 있지만, 무엇보다도 중요한 것은 우리가 수행한 변경의 영향력을 이해하고, 필요한 경우 방향을 바꿔야 하기 때문이다. 이로써 실수에 따른 추가 비용 상승을 효과적으로 완화할 수 있지만, 실수할 가능성을 완전히 제거하지는 못한다.

가역적 결정과 비가역적 결정

가역적 결정과 비가역적 결정이 의사결정 스펙트럼에 양 끝단에 놓여있다고 가정한다. 마이크로서비스 마이그레이션 시 여러 결정들이 어디에 위치하는지를 평가하기란 처음에는 다소 어려울 수 있다. 하지만 뒤늦게 결정을 바꾼다면, 결과적으로 따라올 영향에 대한 이해가 반드시 수반되야 한다. 추후 궤도 수정이 초래할 영향이 클수록, 비가역적인 결정처럼 보일 확률이 높다.
마이크로서비스 마이그레이션의 일환으로 내릴 수많은 결정은 의사결정 스펙트럼 상에서 '가역적' 방향의 끝단을 향할 것이다. 소프트웨어에는 실행을 되돌리거나 취소가 가능한 속성이 있어서, 소프트웨어 변경이나 소프트웨어 배포를 되될릴 수 있다. 따라서, 이후에 마음을 바꿨을 때 치르게 될 비용을 반드시 고려해야 한다.

비가역적 의사결정에는 더 많은 참여, 신중한 숙고, 충분한 고려가 필요하며, 더 많은 시간을 할애해야 마땅하다.

실험을 시도해볼 만한 곳

코드베이스 내에서 코드를 이동하는 비용은 꽤 낮다. 이런 작업을 지원하는 도구는 많아서, 문제가 발생하더라도 대개는 수정을 빠르게 진행할 수 있다. 그러나 데이터베이스를 분리하는 작업은 훨씬 더 많은 노력이 들며, 데이터베이스 변경을 롤백하는 과정은 정말 복잡하다. 마찬가지로, 서비스 간에 지나치게 결합된 통합을 풀거나 여러 컨슈머가 사용하는 API를 완전히 재작성하는 작업은 많은 책임을 요한다. 높은 변경 비용은 운영이 점점 더 위험해진다는 사실을 의미한다. 이런 위험을 관리하기 위해 영향이 가장 적다고 예상하는 곳에서 실수를 시도하는 쪽이 낫다.
변화와 실수를 바로잡는 비용이 낮은 곳에서 생각을 하는 것이 좋다. 작가는 화이트보드 앞에서 많이 생각한다고 한다. 우리가 제안하는 설계를 화이트보드에 그려본다. 서비스 경계가 될 것으로 여겨지는 곳에서 사용 사례를 실행할 때 어떤 일이 발생하는지 확인해보면 된다.

profile
백엔드

0개의 댓글