tidy first 13장 '하나의 더미' 를 읽고

Monolithic 와 MSA

‘여러 개의 작은 코드 조각’ 을 보고 ‘여러 개의 작은 서버’ 가 떠올랐습니다. ‘유지보수’ 관점에서 생각해 봤을 때, ‘유지’ 는 대체로 수월하지만, ‘보수’ 는 가끔 복잡할 때가 있었습니다. 특정 도메인의 트래픽 증가로 서버를 갑자기 증설해야 하는 경우 유연하게 대처할 수 있지만(=유지), 여러 도메인이 관여하는 기능 개선 및 확장 시(=보수)에는 제공하고자 하는 가치에 비해 작업 범위와 양이 많을 수 있습니다.

그렇다고 해서 MSA 가 부적절하다는 것은 아니지만, 서비스 규모에 따라 서버를 어떻게 설계할지(=위치시킴, 배치) 고민이 필요하며, MSA 를 맹신하지(=작은 코드 조각으로 분리하는 일) 않도록 조심 해야겠습니다. 과도가 예리하다고 해서 소를 잡는데 사용하지 않는 것 처럼, 어떤 특정한 기술이나 개념이 모든 경우에 해답이 될 수 없다고 다시 한 번 생각 했습니다.

리팩토링을 위한 안전장치

메서드를 추출하는 것도 그렇지만, 작은 코드 조각들을 한데 모을 때도 수정 전과 후에 같은 결과를 반환하는지 검증하는 과정이 필요하다고 생각 합니다. 그리고 코드 조각을 한데 모아 얻은 통찰을 바탕으로 재구성한 코드에 대한 확신은 테스트 코드로부터 얻을 수 있겠습니다. 설령 재구성한 결과 일부 예외 케이스에서 부작용이 발생 하더라도, 좋은 테스트 코드가 안전을 보장해 준다면 (=해당 케이스로의 진입이 없다) 서비스를 여전히 안정적으로 운영할 수 있습니다.

 

다시 말해, 이 길을 따라가면 고랑에 빠질 것이 뻔하지만, 그 길을 걷는 사람이 없다면 빠지는 사람도 없겠다는 심보 입니다.