🏗️ 아키텍처 설계 - 무엇이 무엇을 어디까지 의존해야 할까?

왜 이 글을 쓰게 되었을까?

개발을 처음 배울 땐 컨트롤러, 서비스, 리포지토리. 딱 세 개의 레이어로 프로젝트를 나눴다. 그리고 대부분의 로직은 서비스에 몰아넣었다. 그때는 그것만으로도 어느 정도는 역할이 분리 된다고 생각했다.

 

그런데 시간이 지나고 개발을 조금씩 더 하다 보니, ‘서비스에 로직을 넣는다’는 말 자체가 점점 모호하게 느껴졌다. ‘서비스’라는게 무엇인지, ‘비즈니스 로직’은 어디까지고, ‘도메인 로직’은 어디까지인지 고민이 되었다.

 

이런 고민이 깊어질 즈음, 회사에서 프론트엔드 업무도 같이 하게 됐다. 프론트엔드는 백엔드보다 훨씬 얕게 알고 있지만, 프론트 역시설계에서 ‘의존성’은 굉장히 중요한 문제라는 것을 느꼈다.

 

의존성이 한 번 꼬이기 시작하면 유지보수와 기능 변경이 굉장히 힘들어진다. 그래서 이번 글에서는 의존성 설계가 왜 중요한지, 그것에 대한 어떤 결론을 내렸는지에 생각을 정리해보려 한다.

---

의존성이 꼬이면 생기는 일들

의존성 설계가 잘못되면 어떤 문제가 생길까? 너무 거창하게 ‘아키텍처’라는 단어를 쓰지 않더라도, 몇 가지 상황만 떠올려보면 감이 올 수 있다.

 

• A 기능을 바꾸려고 했는데, 전혀 관련 없어 보이는 B, C 기능도 같이 깨졌다.
• 새로운 기능을 넣으려고 했더니 어디부터 넣어야 할지 감이 안 온다.
• 테스트 코드 짜는 게 어렵다. 어떤 클래스에 어떤 책임이 있는지 모르겠다.
• 특정 구현체를 바꾸고 싶은데, 상위 로직이 그 구현체에 직접 의존하고 있어서 바꾸는 데 너무 많은 리스크가 따른다.

이런 문제들은 대부분 의존성의 방향이 잘못되었거나, 관심사가 뒤섞여 있을 때 발생한다.

 

그래서 설계에서 가장 먼저 고려해야 할 건 레이어를 나누는 기준보다도 무엇이 무엇에 의존해야 하고, 무엇은 절대 의존하지 말아야 하는지에 대한 생각이라고 느꼈다.

---

내가 생각한 의존성의 방향

이번에 개인적으로 생각해 본 구성은 다음과 같다. 흔히 말하는 3-tier 구조(Controller, Service, Repository)에서 ‘Service’라는 이름 아래 뭉뚱그려졌던 부분을 좀 더 역할별로 분리하는 방향이다.

의존성 분리 기준

1. Application Layer (최상위 로직 조합)

• 여러 도메인 로직을 조합하거나, 외부 요청 흐름을 관리
• 프레젠테이션 계층이나 외부 호출과 가장 가까움
• Controller, Scheduler 등이 호출하는 주요 진입점

2. Domain Layer (핵심 비즈니스 로직)

• 실제 도메인 로직을 담당하는 영역
• 객체 간 협력, 정책 판단, 핵심 도메인 행위 구현

3. Infrastructure Layer (외부 의존 캡슐화)

• 외부 API 호출, DB 연동, 메시징 등
• 도메인 로직에 직접 영향 주지 않도록 인터페이스로 분리

4. Support Layer (보조 기능 제공)

• 유틸성 기능 (날짜 포맷 변환, 문자열 계산 등)
• 모든 레이어에서 공통적으로 의존 가능

---

의존성 흐름도

                   ┌────────────────────────┐
                   │   Application Layer    │
                   └───────────┬────────────┘
                               │
          ┌────────────────────┼────────────────────────┐
          ↓                    ↓                        ↓
┌────────────────┐ ┌─────────────────────┐ ┌───────────────────┐
│  Domain Layer  │ │Infrastructure Layer │ │   Support Layer   │
└────────┬───────┘ └────────────┬────────┘ └────────────┬──────┘
         │                      │                       ▲
         └──────────────────────┴───────────────────────┘

• Application Layer는 Domain, Infra, Support 모두를 의존 가능
• Domain Layer는 Support만 의존 가능
• Infrastructure Layer도 Support만 의존 가능

이런 구조를 따르게 되면 자연스럽게 도메인 로직은 외부 구현체에 영향을 받지 않고, Infra는 Interface를 통해 교체 가능하며, Application은 전체 흐름을 조율하는 역할에 집중할 수 있다고 생각한다.

---

패키지 구조 예시

com.myproject
├── application
│   └── OrderUseCase.kt
├── domain
│   ├── model
│   │   └── Order.kt
│   └── service
│       └── OrderDomainService.kt
├── infrastructure
│   ├── persistence
│   │   └── OrderRepositoryImpl.kt
│   └── external
│       └── ExternalPaymentClient.kt
├── support
│   └── DateUtils.kt
└── presentation
    └── OrderController.kt

---

왜 이렇게 나눴을까?

도메인과 인프라가 섞여 있는 구조에서는 다음과 같은 문제들이 반복됐다.

• 외부 API 형식이 바뀌면 도메인 로직도 같이 바뀌었다.
• 날짜 계산처럼 단순한 로직이 여기저기 중복되어 있었다.
• 도메인 로직에 메시지 큐나 외부 라이브러리 로직이 섞여 있어 테스트가 불편했다.

반면 위 구조처럼 나누면 아래와 같은 장점이 있다.

• 도메인 영역은 순수하게 남기 때문에, 테스트 작성이 쉬워지고 변경에 유연하다.
• 외부 API 요청을 캡슐화한 영역은 mocking 하기도 편하다.
• 비즈니스 흐름이 상단에서만 조합되기 때문에, 새로운 요구사항을 반영하기 쉬워진다.

---

그래서 결론은?

이번 글에서는 복잡한 이론보다는 실제 프로젝트에서 느꼈던 '의존성 설계'의 중요성에 대해 정리해보았다.

 

우리는 흔히 아키텍처를 이야기할 때 계층을 나누는 데에 집중하지만, 정작 중요한 건 누가 누구를 의존할 수 있는가에 대한 규칙을 세우는 일도 굉장히 중요하다고 생각한다.

 

내가 생각하는 핵심은 아래 두 가지다:

1. 도메인 로직은 외부 구현에 영향을 받지 않도록 순수하게 유지해야 한다.
2. 외부 시스템과의 연결은 명확하게 분리하고 캡슐화해야 한다.

물론 프로젝트의 성격, 규모, 팀 문화에 따라 더 나은 대안이 있을 수도 있다. 하지만 현 시점에서 내가 느낀 가장 실용적인 방향은 이 정도 선이었다.

 

덧붙이자면, 이 글은 클린 아키텍처나 헥사고날 설계 같은 특정 아키텍처 패턴을 깊이 있게 이야기하기보단, 그보다 먼저 고민되어야 할 의존성 설계의 우선순위에 대해 기록해두고 싶어서 작성했다. 구조적인 선택 역시 중요하지만 이런 점들을 고려하고 해도 좋다고 생각한다.

 

그래서, 앞으로 프로젝트를 시작할 때는 '기능을 어떻게 나눌까?'도 중요하지만 '누가 누구를 의존할 수 있을까?'도 깊게 고민하려고 한다.