원래 마크다운으로 작성한거 떼다 붙인거라 보기 좀 불편하긴 하네요

---
목차

1. 서론
2. 의존성 역전 패턴 소개
    * 의존성 역전 패턴의 정의
    * 모듈의 수준이란
    * 모듈간 의존이란
    * 추상화를 통한 의존이란
3. 기존 설계의 문제점 분석
4. 의존성 역전 패턴의 적용
5. 효과 및 장점
6. 실제 사례
7. 결론

서론

좋은 사람이 되려면 가장 중요한 것은 무엇일까? 우선은 좋다는 것의 기준이 무엇인부터 잡아야 할 것이다. 기준이 있어야만 행동, 존재, 특징 등은 옳고 그름과 같은 평가를 받을 수 있다. 이는 소프트웨어 역시 마찬가지다.

그렇다면 좋은 개발자란 무엇일까? 여러 기준이 있을 수 있겠지만 단순하게 개발자를 소프트웨어를 만드는 사람이라 이야기할 때 좋은 소프트웨어를 만드는 사람이라 할 수 있을 것이다. 그렇다면 좋은 소프트웨어를 만든다는 것의 기준은 무엇으로 삼을 수 있을까?

소프트웨어의 개념이 창시된 이래 많은 시간이 지나 수많은 '좋은 개발' 기준들이 대두했고, 요 근래 핫한 것에 '결합도', 그리고 '유연성'이 있다. 여기서 소프트웨어의 유연성은 시스템이 변경에 얼마나 잘 대응하는지, 좀 더 자세하게는 새로운 기능을 추가하거나 변경, 제거하는 것이 얼마나 용이한가를 말한다. 소프트웨어의 결합도는 이와 반대되는 개념으로, 소프트웨어를 구성하는 모듈 간의 상호 의존성이 얼마나 강한가를 의미한다. 결합도가 높다는 것은 한 모듈이 변경될 때 다른 모듈에 얼마나 많은 영향을 미친다는 것을 말한다.

소프트웨어는 하드웨어가 수정 및 업데이트가 힘들었기 때문에 이를 해소하기 위한 필요하에서 새로 창시된 가상의 기계라고 말할 수 있을 것이다. 탄생 시점의 관점에서 봐도 소프트웨어에서 가장 중요한 가치 중 하나로 유연성이 높고 결합도가 낮기를 요구하는 것은 어찌보면 당연할 것이다.

의존성 역전 패턴은 이런 목표를 달성하기 위한 소프트웨어 설계 방법론 중 하나이다. 사전적으로는 상위 수준의 모듈이 하위 수준의 모듈에 직접적으로 의존하지 않고, 둘 사이에 있는 추상화를 통해 의존하는 소프트웨어 설계를 우리는 의존성 역전 패턴이라 부른다.

의존성 역전 패턴 소개

의존성 역전 패턴의 정의

너무 어려운 표현이 많으니 하나하나 단어를 나눠가며 이해해보자. 의존성 역전의 정의를 다시 살펴보면

상위 수준의 모듈이 하위 수준의 모듈에 직접적으로 의존하지 않고, 둘 사이에 있는 추상화를 통해 의존하는 소프트웨어 설계 패턴을 말한다

그럼 이제 우리의 의문은 다음과 같다

* 모듈의 수준은 무엇이고 무엇을 기준으로 상위, 하위를 구분하는가?
* 모듈이 다른 모듈에 의존한다는 것은 무엇을 말하는가?
* 추상화를 통해 의존한다는 것과 직접적으로 의존하는 것의 차이는 무엇인가?

모듈의 수준(Level)이란

모듈은 소프트웨어 개발에서 특정 기능이나 목적을 수행하기 위해 독립적으로 구현된 단위를 말한다. 모듈에는 대표적으로 함수, 클래스, 패키지, 라이브러리 등이 존재한다.


def greet(name):
    """
    주어진 이름에 대한 인사말을 출력하는 함수

    Parameters:
        name (str): 인사말을 전달할 대상의 이름

    Returns:
        str: 인사말 문자열
    """
    return f"Hello, {name}!"


한 개의 프로그램을 구성하는 데는 여러 가지 기능이 필요하고, 이들을 각각 모듈을 통해 만들어내는 데 성공했다 가정하자. 그런데 소프트웨어는 지속적인 유지 및 보수를 필요로 하기 때문에 단순히 이들을 늘어놓아서는 효율적으로 관리할 수 없다. 이 때문에 수준, 혹은 Level의 개념이 등장한다.

일반적으로 높은 레벨부터 낮은 레벨까지의 모듈의 수준을 분류하면 다음과 같다.

1. 프레임워크 수준
2. 라이브러리 수준
3. 패키지 수준
4. 소스 코드 수준

즉 각 단계가 얼마나 큰 범위를 다루는지를 통해 수준 혹은 레벨이 다르다 말하는 것이다. 또한 고수준의 모듈일수록 저수준 모듈에 비해 높은 수준의 추상화를, 저수준 모듈일수록 기능의 구현에 집중하게 된다.

비유를 통해 살펴보자. 당신은 지금 거대한 도서관의 사서이다. 이 도서관에는 수백만 권의 책이 가득하다. 당신은 새로운 책을 구입하고, 낡고 열람하지 않는 책은 폐기하며, 사람들이 책을 찾기 쉽도록 배치하고, 반납과 대출을 관장하는 등의 일을 하게 될 것이다. 그리고 이런 일을 하기 위해서는 효과적으로 책들이 구조화돼있어야 한다.

이 때 도서관이 책들을 각각 주제나 카테고리로 분류한 뒤, 카테고리 내에서 작은 분류로 나눠서 정리돼있다 하자. 예를 들어 문학으로 책을 분류했다면, 그 다음에는 소설이나 시 등으로 추가적인 분류가 가능할 것이다.

소프트웨어도 도서관이 책을 분류해서 구조화하는 것과 마찬가지로 모듈을 구조화하게 된다. 각각의 소스 코드를 패키지 단위로, 패키지들을 라이브러리 단위로, 라이브러리들을 프레임워크 단위로 분류하는 것이 소프트웨어의 구조화인 것이다.

모듈간 의존이란

이런 모듈간 맺을 수 있는 관계들 중 의존은 한 모듈의 정의 또는 동작이 다른 모듈에 종속되는 것을 말한다. 자동차를 예로 들어 생각해보자. 자동차는 여러 부품으로 구성돼있지만 성능을 결정하는 가장 중요한 역할을 하는 것은 바퀴와 엔진이라 할 수 있다. 엔진이 사용하는 연료가 무엇인지와 같은 엔진의 특징에 자동차라는 최상위 모듈은 동작이나 설계에서 크게 영향 받을 수 밖에 없다. 이 때 소프트웨어적인 관점에서 우리는 자동차라는 상위 모듈이 엔진이라는 하위 모듈에 의존한다고 표현할 수 있다.

추상화를 통한 의존 vs 직접 의존

그렇다면 추상화를 통한 의존이란 무엇인가? 마찬가지로 자동차를 가지고 설명을 해보겠다. 자동차란 무엇인지 추상적으로 표현하면 '엔진을 통해 얻은 동력'을 '바퀴에 전달해 회전시켜' 이동하는 물체라고 할 수 있을 것이다. 여기서 엔진에서 가장 핵심적인 기능을 동력이라는 추상적인 개념만 남기고, 바퀴는 동력을 전달받아 회전한다는 개념만 남긴 뒤에 자동차를 설명하는 것이 이제 상위 모듈이 하위 모듈의 추상화를 통해 의존하는 방식이다.

이에 반면 직접적인 의존은 100마력의 8기통 가솔린 엔진이 장착된, 반지름 50cm의 바퀴를 네 개 장착한 자동차를 우리가 정의했다고 하자. 이제 차이점이 보이는가? 추상화를 통한 의존을 통해 정의한 자동차는 이후에도 동일한 기능을 유지하면서도 세세한 부분들에 추가적인 업그레이드나 조정이 가능하지만, 직접적인 의존을 통해 정의한 자동차는 해당 제약 때문에 변화할 수 있는 여지가 좁아지게 된다. 이것이 추상화를 통한 의존의 힘인 것이다!

결론

그렇다면 이제 눈치 좋은 독자는 이제 이해할 수 있을 것이다. 그렇다 의존성 역전은 최상위 레벨의 모듈인 인터페이스에 하위 모듈을 의존하는 방식을 통해서 기존에 구현 과정에 높아진 결합성을 낮추고 유연성을 높이자는 패턴인 것이다.