Dependency (의존성) ?
의존성의 단어적인 뜻은, “다른 것에 의지하여 생활하거나 존재하는 성질.” 이다. 즉, 무언가가 없으면 안되는 상황이나 관계를 말한다. 개발에서도 의존성은 무엇을 말할까?
예를들어 내가 만든 프로젝트 결제 기능이 있다. 이 결제는 구글 플레이 스토어를 통해 구매가 이루어진다. 그렇다면 구글 플레이 결제 라이브러리를 사용해 구연 되어 있을것이다. 그렇다면 프로젝트에 구글 결제 라이브러리가 포함되어 있지 않다면? 해당 기능은 사용할수 없을 것이다. “내 프로젝트는 [구글플레이 결제 라이브러리]에 의존성을 가지고 있다.” 가 된다.
프로젝트와 라이브러리 사이, 라이브러리와 라이브러리 사이, 코드와 코드 사이 등등… 개발에서 의존성을 관계는 참으로 많고 복잡하다. 그렇기 때문에 의존성을 관리하는것은 매우 중요한 문제다.
Dependency (의존성) 관리
위에서 의존성을 ‘관리’ 한다고 표현했다. 의존성을 관리한다? 왜 그럴 필요가 있지? 다음과 같은 상황을 생각해보자, (실제와는 관련이 없는 단순한 예시일뿐이다.)
1) 프로젝트에서 사용하는 라이브러리 A, B 가 있다. |
2) A, B 라이브러리는 C라는 라이브러리의 기능을(사용하여) 만들어졌다. |
3) A 에서 사용된 C 라이브러리 버전은 1.0 / B 에서 사용된 C 라이브러리 버전은 2.0 이다. |
4) C 라는 라이브러리를 프로젝트에 포함하여야 한다. |
5) C 라이브러리의 1.0 버전을 프로젝트에 포함시켰다. |
위와 같은 상황을 보면, 큰 문제가 없을거 같다. 하지만 실제로는 문제가 발생했다. 왜일까? B에서 사용하는 C 2.0 버전에 추가된 기능이 1.0 버전에는 존재 하지 않았다. B 에서 해당 기능을 호출할때 Crash 가 난다. 구조상으로 보면 분면 C 라이브러리가 포함 되어있기 때문에 문제가 없을거 같았지만, 런타임에서 문제가 발생할수 있다. 이와 같은 일이 일어나지 않으려면
5) C 라이브러리 2.0 버전을 프로젝트에 포함시켰다. |
여야 했다. 글로 읽었을때는 “아니 2.0 포함 시키면 되잖아?” 라고 느낄수 있을것이다. 그래 사람은 안다. 2.0을 포함시켜야 한다는걸. 하지만 프로젝트 개발단계에서는 어떻게 알지? 뭘 기반으로 알것인가? 수동으로 일일이 넣어주면 되나? 사실 사용하는 모듈, 라이브러리, 코드가 적고 작업자가 적다면 그럴수도 있을것이다. 그래도 분명 문제가 생길것이다. 하물며, 큰 규모의 프로젝트에서는 어떤일이 발생할지… 상상을 하지 말자. 이처럼 의존성은 ‘관리’ 가 필요하다.
마무리
개발을 하면서, 의존성 관련된 문제를 많이 접한다. 프로젝트의 규모가 커질수록, 담당하는 일이 많을 수록, 적용하는 기술이 많을수록, 업데이트를 할수록… 어느 과정에서도 의존성 관리는 땔래야 땔수 없는 필수 과정이었다. 마치 버그… 아니다. 여기까지 하도록 하자. 이후 포스팅들에서는 iOS, Android 에서의 의존성 관리 방법에 대해 써볼까 한다.