2022. 4. 11. 01:21ㆍProgramming theory/Programming
- 목차
이 글은 이전에 운영하던 깃 블로그에서 옮겨온 글입니다.
서론
의존성의 단어적인 뜻은, "다른 것에 의지하여 생활하거나 존재하는 성질."입니다. 즉, 무언가가 없으면 안 되는 상황이나 관계를 말합니다. 사실 의존성은 객체지향에서 만의 문제는 아닙니다. 그럼, 개발하는 입장에서 의존성은 무엇을 말할까요?
예를 들어 내가 만든 프로젝트 에는 결제 기능이 있습니다. 이 결제는 구글 플레이 스토어를 통해 구매가 이루어집니다. 그렇다면 구글 플레이 결제 라이브러리를 사용해 구연되어 있을 겁니다. 그런데 만약, 프로젝트에 구글 결제 라이브러리가 포함되어 있지 않다면? 해당 기능은 사용할 수 없을 것입니다. "내 프로젝트는 [구글 플레이 결제 라이브러리]에 의존성을 가지고 있다."가 되는 겁니다.
프로젝트와 라이브러리 사이, 라이브러리와 라이브러리 사이, 코드와 코드 사이 등등… 개발에서 의존성을 관계는 참으로 많고 복잡합니다. 특히나, 규모가 큰 프로젝트일 경우 더욱더 말이죠. 그렇기 때문에 의존성을 관리하는 것은 매우 중요한 문제입니다. 이 글에서는 이러한 의존성에 관해서 간단히 이야기해보려 합니다.
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에서의 의존성 관리 방법에 대해 써볼까 합니다.
