Five Lines of Code - 9. 코드 삭제의 미학

주제: 도움이 되지 않는 모든 것을 제거하기 (strangler fig pattern, spike&stabilze pattern)

🔖 9.4.1 스트랭글러 무화과나무 패턴

책의 내용

레거시 코드에 대한 통찰력을 얻으려면 각 부분이 얼마나 호출되는지 알아야 합니다. 그리고 레거시 코드가 나머지 소프트웨어와 얼마나 밀접하게 연결되어 있는지도 알아야 합니다.

이 과정을 돕기 위해 마틴 파울러의 스트랭글러 무화과나무 패턴을 사용할 수 있습니다. 가장 많이 호출되는 부분은 거의 확실하게 마이그레이션되어야 하고, 가장 적게 호출되는 부분은 높은 확률로 삭제될 수 있으므로 이런 잔가지들을 먼저 처리하고 어려운 결정이 있는 몸통으로 이동합니다. 가장 적게 또는 항상 실패하는 코드를 비판적으로 평가해서 중요하거나 전략적 기능이 있는지 여부를 판단해야 합니다.

나의 생각

아마 회사에서 일을 하면 새로운 기능을 만드는 것보다, 기존 코드나 기능을 유지보수하면서 레거시 코드를 파악하는 일이 많을 거다. 그때 위의 문장을 잘 떠올리면 좋겠다.

참고로, AWS 가이드에서는 스트랭글러 무화과나무 패턴을 아래와 같이 설명한다.

strangler fig 패턴을 사용할 때는 다음 모범 사례를 따르십시오. 그러면 애플리케이션을 독립적으로 확장하고 보다 원활하게 배포할 수 있습니다.

  • 테스트 적용 범위가 양호하고 관련 기술 부채가 적은 구성 요소를 선택하십시오. 이 구성 요소로 시작하면 팀은 현대화 프로세스 중에 많은 확신을 가질 수 있습니다.

  • 확장성 요구 사항이 있는 구성 요소를 선택하고 이러한 구성 요소 중 하나부터 시작하십시오.

  • 비즈니스 요구 사항이 자주 변경되고 자주 배포되는 구성 요소를 선택합니다.

다만 스트랭글러 무화과나무 패턴의 단점으로는 아래와 같이 설명하므로 참고하면 좋겠다.

  • 복잡성이 낮고 크기가 작은 소규모 시스템에는 적합하지 않습니다.

  • 백엔드 시스템에 대한 요청을 가로채거나 라우팅할 수 없는 시스템에서는 사용할 수 없습니다.

  • 프록시 또는 파사드 레이어는 제대로 설계하지 않은 경우 단일 장애 지점이 되거나 성능 병목 현상이 발생할 수 있습니다.

  • 문제가 발생할 경우 작업을 수행하는 이전 방식으로 빠르고 안전하게 되돌리려면 리팩터링된 각 서비스에 대한 롤백 계획이 필요합니다.

🔖 9.10 라이브러리 제거를 위한 코드 삭제

책의 내용

고품질의 공급하는 공급업체의 라이브러리를 선택해서 해당 업체의 내부 품질 보안 요건을 믿는 것입니다.

이전 절에서 언급한 보안 위험을 완화할 간단한 해결책은 종속성을 가시적으로 만든 다음, 각 라이브러리가 개선 용도인지 중요 용도인지 분류하는 것입니다. 이 방법을 사용해서 의존도를 낮추고 궁극적으로 라이브러리에 대한 의존을 줄입니다. 다만, 개선용 라이브러리에서 중요 라이브러리로 승격될 때는 주의하십시오.

나의 생각

의존성 가시화에 대한 이해

프로젝트에서 사용하는 모든 외부 라이브러리(의존성)를 명확하게 확인하고 문서화한다. 이를 통해 어떤 라이브러리들이 프로젝트에 포함되어 있는지, 각 라이브러리가 어떤 역할을 하는지 쉽게 파악할 수 있다.

만약 문서화를 잘 해두지 않으면 어떤 문제가 발생할까? 만약 사용 중인 라이브러리의 버전이 구형이거나 보안 패치가 적용되지 않은 상태일 때 이를 악용하는 보안 공격에 취약할 수 있다. 혹은 프로젝트에 여러 라이브러리가 사용될 때, 이들 간의 버전 충돌이나 호환성 문제, 혹은 중복 사용 등의 문제가 발생할 수 있다. 이러한 충돌이 발생한다면 예측하지 못한 버그를 발생하고, 디버깅을 하는데에 상당한 시간과 리소스가 소모될 것이다.

라이브러리의 중요성 분류에 대한 이해

각 라이브러리를 '개선 용도'와 '중요 용도'로 분류한다. 이는 라이브러리의 중요도와 필수성에 따라 우선순위를 매기는 것을 의미한다.

  • 개선 용도 라이브러리: 프로젝트에 편리한 기능을 제공하거나 개발 과정을 간소화하는 데 도움을 주지만, 핵심 기능이나 시스템의 운영에는 직접적으로 필수적이지 않은 것들을 말한다.

  • 중요 용도 라이브러리: 반대로 프로젝트의 핵심 기능에 깊이 관여하거나 시스템의 안정성과 직접적인 연관이 있는 필수 라이브러리들을 의미한다.

생각보다 이 둘은 많이 다른 성격을 띄기에, 책에도 서술한듯이 개선용 라이브러리에서 중요 라이브러리로 승격될 때는 주의를 기울여야겠다.

📚 참고 자료

Last updated