B컷전문 | 개발과 인생의 이야기

계층형 아키텍처는 소프트웨어 설계의 기본입니다. 하지만 진짜 중요한 건 '계층이 몇 개냐'가 아니라 '책임이 올바르게 분리되었느냐'입니다. 이 글에서는 구조를 넘은 설계 철학을 깊이 있게 다룹니다.

레이어의 수보다 중요한 것: 책임(Responsibility)

많은 개발자들이 아키텍처 설계를 시작할 때 흔히 묻는 질문은 "몇 개의 계층이 적당한가요?"입니다.
그러나 더 중요한 질문은 **"각 계층이 어떤 책임을 가져야 하며, 그것이 명확하게 분리되어 있는가?"**입니다.

---

1. 전통적인 계층 구조의 재조명

우리는 3~4계층의 구조를 자주 사용합니다.

• UI (사용자와의 인터페이스)
• Application Logic (유스케이스, 흐름 제어)
• Domain (핵심 비즈니스 로직)
• Infrastructure (DB, API, 메시지 브로커 등)

이러한 계층 구조는 시스템을 시각적으로 이해하는 데 도움이 되지만, 실제로는 계층을 나눈 것만으로는 책임이 분리되지 않습니다.

문제는 언제 발생하는가?

• Service 계층에 모든 로직이 몰리는 경우
• Controller가 도메인 규칙을 직접 건드리는 경우
• Repository가 비즈니스 정책을 포함하는 경우

구조는 계층이지만, 구현은 스파게티가 되는 순간입니다.

---

2. 책임 분리의 설계 원칙

책임 분리(Separation of Concerns, SoC)는 단순히 클래스나 함수 수준에서 적용되는 게 아닙니다.
전체 시스템이 어떤 주제, 기능, 변화 요인에 따라 분리될 수 있는가를 기준으로 나뉘어야 합니다.

설계 기준

• 변경의 이유가 다른 요소는 반드시 분리하라
  예: DB 변경과 UI 변경은 별개여야 한다.
• 한 책임은 한 곳에만 존재해야 한다
  예: 결제 수수료 로직이 3개의 계층에 중복돼선 안 됨
• 기술 의존성과 비즈니스 로직은 분리해야 한다
  예: Kafka나 Redis 같은 인프라 기술은 도메인 로직과 섞이지 않아야 함

---

3. 구조에서 철학으로: 계층을 넘는 설계

현대 아키텍처는 계층적 사고를 **동심원 구조(클린 아키텍처, Onion 아키텍처)**로 확장했습니다.

• 중심에는 순수한 도메인 모델이 있고
• 그 바깥에는 유스케이스(Application Logic)
• 더 바깥에는 UI, DB, 외부 시스템이 위치함

이 구조에서는 의존성이 항상 안쪽을 향해야 하며, 외부 요소는 인터페이스(Port)로 추상화됩니다.

즉, 구조는 단순히 위에서 아래가 아니라, 안쪽에서 바깥으로 퍼지는 책임의 흐름으로 보는 것이 더 근본적인 관점입니다.

---

4. 실무 적용 예시: ‘주문 처리 시스템’의 책임 분리

잘못된 설계

• Controller에서 직접 주문 가격 계산
• Repository에서 결제 정책 판단
• Service에서 이메일 전송 로직까지 담당

개선된 책임 분리

• OrderDomainService: 주문 가격, 할인 정책 계산
• OrderUseCaseService: 유스케이스 흐름 관리 (주문 생성 → 결제 요청 → 알림)
• NotificationAdapter: 이메일/SMS 전송, 외부 시스템 연결
• Controller: 요청 수신 및 응답 생성만 담당

---

5. 팀 조직과 코드 구조의 일치

소프트웨어 아키텍처는 코드 구조뿐 아니라 팀의 커뮤니케이션 구조에도 영향을 줍니다.
책임이 잘 분리되면, 다음과 같은 이점이 생깁니다:

• 기능별 팀 구성 가능 (Feature Team)
• 병렬 개발이 쉬움
• 테스트 커버리지가 높아짐
• 신입 개발자 온보딩 시 진입 장벽이 낮아짐

반대로 책임이 섞여 있으면, "어디서부터 손대야 할지 모르는" 상황이 빈번해집니다.

---

모르면 모른다고 말해야 할 부분

"계층은 무조건 3개가 적당하다", "도메인 계층은 항상 따로 둬야 한다"는 주장들은 상황에 따라 다릅니다.
실제로는 작은 서비스에서는 Application과 Domain을 하나로 합쳐도 무방할 수 있으며, 비즈니스 로직이 단순한 경우는 별도 계층 분리가 오히려 오버엔지니어링이 될 수 있습니다.

따라서 "몇 계층이 맞다"는 질문보다는 **"이 책임은 왜 여기에 있어야 하는가?"**라는 질문이 더 중요합니다.

---

마무리하며

계층 아키텍처는 여전히 훌륭한 출발점입니다. 하지만 **진짜 중요한 건 ‘형태’가 아니라 ‘역할’**입니다.
책임을 기준으로 설계를 바라보는 시각이 없다면, 아무리 많은 계층을 나눠도 아키텍처는 복잡하고 유연하지 않은 구조로 남을 수밖에 없습니다.

다음 회차에서는 이 철학을 더 발전시켜, 클린 아키텍처와 헥사고날 아키텍처가 등장하게 된 배경과 구조적 차이를 본격적으로 다루겠습니다.