5장 피할 수 없는 코드 의존성 관리

[fkdl0048]

5장 피할 수 없는 코드 의존성의 관리

복잡한 프로그램을 짜봐야 비로소 깨닫는 의존성의 진실

코드에 의존성을 추가하는 것은 그다지 어려운 결정이 아니다. '같은 일을 반복하지 말라(DAY)'는 매우 보편적인 원칙이다. 우리가 직접 라이브러리의 기능을 일일이 구현할 필요가 없듯이 말이다. 하지만 의존성에는 다양한 위험성이 내포되어 있다.

따라서 의존성을 다룰 땐, 이런 위험을 인지하고 사전에 완하할 수 있는 방법을 반드시 고려해야 한다.

의존성 관리를 이해하기 위한 필수 개념

문제점과 권장 기법을 살펴보기 앞서 먼저 의존성과 버저닝의 기본적인 개념을 이해해야 한다. 의존성이란, 코드가 의존하는 코드를 말한다. 그 의존성이 필요한 시점, 즉 컴파일 시점, 테스트, 런타임 등을 의존성 범위라고 부른다.

의존성은 패키지 관리 파일 또는 빌드 파일에 선언한다. 꼭 언어레벨이 아니더라도 유니티의 어셈블리나 언리얼의 Target.cs 파일도 의존성을 선언하는 파일이다.

책에서 말하는 버저닝은 깃헙의 릴리즈 버전과 같이 각각 주, 보조, 패치등의 담당을 말하며 이는 꼭 의존성 버저닝에만 해당되는 말은 아니다.

이행적 의존성에서 트리형태가 가지는 의존성에 대해서 보여주는데, 실제 상속 구조나 하위레벨을 가지는 컴포넌트로 생각해도 언어를 넘어 툴 레벨에서 의존성을 가질 수 있음을 간접적으로 보여준다.

현업이면 누구나 한 번은 겪는 의존성 지옥

현업자에게 의존성 지옥을 묻는다면 동일 라이브러리 버전 충돌이나 라이브러리 업그레이드 후의 비호환성 문제를 일으켜 런타임 장애를 유발하는 등 다양한 문제를 겪어본 경험이 있을 것이다. (다이아몬드 의존성, 버전 충돌 등)

어디서나 순환은 문제가 되는데, 의존성에서도 마찬가지다. 순환 의존성은 한 라이브러리를 업그레이드하면 다른 라이브러리가 깨지게 된다.

의존성 지옥에서 탈출하자

의존성은 피할 수 없지만 뭐가 됐든 새로운 의존성이 추가될 때마다 비용이 따른다. 의존성의 가치가 그 비용보다 큰지 여러분 큰지 스스로 판단해야 한다.

• 이 기능은 정말 필요한가?
• 의존성은 얼마나 잘 관리되고 있는가?
• 뭔가 잘못됐을 때 의존성을 수정하는 것은 얼마나 쉬운가?
• 의존성은 얼마나 성숙해 있는가?
• 의존성에서 하위 호환되지 않는 변경이 얼마나 자주 일어나는가?
• 나 자신과 우리 팀, 우리 조직은 의존성에 대해 얼마나 이해하고 있는가?
• 코드를 직접 작성한다면 구현 난이도는 어느 정도인가?
• 어떤 유형의 코드 라이선스가 적용돼 있는가?
• 의존성 내에서 내가 사용하는 코드의 사용하지 않는 코드의 비율은 어느정도 인가?

내 생각엔 의존성에 대해서 같이 작업을 하려면 개인의 이해도 중요하지만 그만큼 성숙한 팀이 필요한 것도 사실이다. 따라서 위 조건들을 만족하고 다룰 수 있다면 의존성 관리 기법을 통해 관리하자.

의존성을 격리하자

코드 복사와 같이 자동화 관리를 포기하는 수준의 작업을 극도로 싫어할 수 있지만(DAY원칙) 실용적으로 생각했을 때, 더 큰 의존성 문제나 불안정한 의존성 문제를 피하는 데 도움이 된다면 코드를 복사하는 것에 대하여 지나친 죄의식을 가질 필요는 없다.

과거 유니티로 레이어를 정렬하는 컴포넌트를 만들었을 때, 해당 컴포넌트의 오름차, 내림차 정렬에 해당하는 것을 public으로 bool로 조절할 수 있게 해둔 기억이 있는데 결국 나중에는 오름차, 내림차 정렬을 위한 컴포넌트를 따로 만들어서 사용했던 기억이 있다. 이는 결국 의존성을 격리한 것이다. (네이밍으로 구분)

다른 방법으론 의존성 가리기가 있다. 의존성을 피하기 위해 다른 네임스페이스에 위치하도록 하는 고급 기술이며, 현재는 많은 언어가 이를 지원한다.

의존성은 신중하게 추가하자

라이브러리는 명시적으로 선언하는 것이 좋다. 이행적 의존성 라이브러리가 제공하는 메서드와 클래스는 괜찮아 보이더라도 버전이 달라짐에 매우 취약하다.

버전을 고정하자

모든 의존성의 버전 번호를 명시하라. 이 방법을 버전 고정이라고 부른다. 버전을 고정해두지 않으면 빌드나 패키지 관리 시스템이 버전을 결정하게 된다.

라이브러리, 의존성 실상 개발 과정에서 버전 업그레이드는 매우 위험한 작업이다. 마이그레이션은 물론 테스트, 릴리즈, 배포 등의 과정을 거쳐야 하기 때문이다.

의존성의 범위를 좁히자

의존성의 '범위'는 의존성이 빌드 수명주기 내에서 언제 사용되는 것인지를 결정한다. 범위는 계층 구조를 갖는다. 컴파일타임 의존성은 런타임에도 사용되지만, 반대로 런타임 의존성은 컴파일타임에 사용되지 않으며 단지 실행될 때만 사용된다.

의존성은 최대한 범위를 좁혀서 사용해야 한다. 모든 의존성을 컴파일 타임 범위에 추가하는 것은 좋은 방법이 아니다. 범위를 좁히면 충돌과 런타임 바이너리의 크기를 줄일 수 있다.

순환 의존성에 주의하자

절대로 순환 의존성이 발생해서는 안된다.