아키텍처 이론은 실제 실무에선 어떻게 적용될까? (feat. 레이어드 아키텍처, 클린 아키텍처, 항해플러스)

서론

상사로부터 비즈니스 로직과 데이터 로직을 분리하라는 조언을 듣게 되었다. 소프트웨어 개발 시 각 계층의 역할을 구분 짓고 어떻게 소통해야 하는 아키텍처를 항해에서 배웠던 것 같은데... 가물가물한 기억을 다시 되새김질 하기 위해 항해 플러스 과정을 진행할 당시 필기했던 내용을 펼쳐 보았다. 오마이 갓! 각보다 많은 내용이 내 머리 속에서 휘발된 상태였다.

역할과 책임을 분리하는 것과 관련 있는 개념은 레이어드, 클린 아키텍처였다. 이 개념들을 다시 정리하기 위해, 이번에는 실무 적용 기회를 놓치지 않기 위해, 왜 계층 간 역할을 구분지어야 하는지 정확히 알기 위해 항해 플러스 과정을 복습하고 이 포스팅으로 정리하게 되었다.

 

본론

1. 레이어드 아키텍처와 클린 아키텍처 개념 및 사용 이유

1) 레이어드 아키텍처

출처: https://dzone.com/articles/layered-architecture-is-good

레이어드(계층) 아키텍처는 소프트웨어를 계층적으로 나누어 설계하는 구조적 패턴이다.
각 계층은 특정 역할을 담당하며 서로 독립적으로 동작하도록 설계된다. 일반적으로 다음과 같은 계층으로 나뉜다.

• Presentation Layer: 사용자 인터페이스(UI)와 관련된 로직을 처리한다.
• Application Layer: 비즈니스 로직을 담당하며, Presentation Layer와 Domain Layer를 연결한다.
• Domain Layer: 핵심 비즈니스 규칙과 데이터를 캡슐화한다.
• Infrastructure Layer: 데이터베이스나 외부 시스템과의 통신을 처리한다.

 

사용 규칙

• 상위 계층에서 하위 계층을 호출하는 일방향 흐름 유지(하위 계층에서 상위 계층을 호출하면 안 됨. 양방향 X)
• 상위 계층은 하위 계층에 의존하므로 하위 계층의 변경이 상위 계층에 영향을 줄 수 있다. = OCP X (다만, 하위 계층의 인터페이스를 통하면 의존도가 약해질 수는 있음.)
• 상위 계층이 필요한 기능을 하위 계층의 구현으로 전달. 이 때 상위 계층은 하위 계층의 내부 구현을 알 필요가 없으며 하위 계층이 제공하는 추상화된 인터페이스를 통해 요청을 전달한다.= 작업 위임 = DIP o

 

사용 이유

• 각 계층이 명확한 역할과 책임을 가지므로, 코드의 가독성과 이해도가 높아진다.
• (하위 계층의 인터페이스를 사용할 경우) 각 계층이 독립적으로 동작하므로 유지보수성이 높고 코드 재사용이 용이하다.
• 계층 간 의존성을 최소화하여 테스트하기 쉬운 구조를 제공한다.

 

2) 클린 아키텍처

출처: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

클린 아키텍처는 핵심 비즈니스 로직을 외부 구현 세부사항(UI, 데이터베이스 등)으로부터 분리하는 도메인 중심 설계이다(관심사 분리). 주요 계층은 다음과 같다

• Entities: 도메인 계층으로도 불리며, 시스템의 핵심 비즈니스 규칙과 데이터를 정의한다.
• Use Cases: 애플리케이션 계층으로도 불리며 애플리케이션 별 비즈니스 로직을 구현한다. 사용자와 시스템 간 상호작용을 정의한다.
• Interface Adapters: 외부 시스템과의 상호작용을 처리한다. 외부 입력을 도메인이 이해할 수 있는 형태로 변환한다.
• Frameworks and Drivers: 인프라 계층이라고 불리며 외부 기술적 구현(UI, 데이터베이스 등)을 담당한다.

 

사용 규칙

• 핵심은 비즈니스 로직이다. 이들은 외부 요소(예: 데이터베이스, API)로부터 분리되어야 한다. = 외부 요소(도메인 계층 바깥)의 변경이 도메인 계층에 영향을 미치면 안 된다.
• 데이터 계층 및 애플레케이션 계층은 비즈니스 로직에 의존해야 한다.

 

사용 이유

• 특정 프레임워크나 기술에 종속되지 않으므로 확장성과 유연성이 뛰어나다.
• 의존성 규칙(Dependency Rule)을 통해 핵심 로직이 외부 변경에 영향을 받지 않도록 보호할 수 있다.

 

2. 실무에서 자주 사용되는 '레이어드 + 클린 아키텍처 ' 형태('항해 플러스 백엔드 과정'에서 배운 내용)

코치님들의 피드백
사실 레이어드 아키텍처든, 클린 아키텍처든 어떤 아키텍처 개념을 칼로 무 자르 듯 구분짓는 것은 의미가 없다. 중요한 것은 각 계층 별 의존도를 최소화(DIP)하고 각 계층의 책임과 역할을 분리하여 확장과 변경이 용이하도록(OCP) 개발하는 것! 이를 위해 레이어드와 클린 아키텍처의 장점을 합한 형태의 아키텍처를 사용할 수 있다.

코치님들이 자주 사용하는 아키텍처는 다음과 같다.

'레이어드 + 클린' 병합 형태의 구조

1. Presentation Layer
   • 사용자 요청을 받고 응답을 반환한다. Business Layer 를 의존하며 도메인을 API로 서빙한다.
2. Business Layer
   • 비즈니스 로직을 처리하고, 도메인 모델(Entity)을 활용한다.
3. Datasource Layer (Infrastructure)
   • 데이터베이스와 통신하며, 도메인 모델 데이터를 저장하거나 불러온다.

 

사용 규칙

• 핵심은 비즈니스 로직. 의존성은 항상 비즈니스 로직으로 모인다. (클린 아키텍처 특징) = DIP o
• 비즈니스 계층은 다른 계층을 위한 추상화 인터페이스를 각각 제공하고 Presentation 과 Datasource 는 이 인터페이스를 구현. =
• Business Layer 에서는 자신이 제공하는 인터페이스 객체를 사용하기만 하면된다. (Spring Boot 의 객체 주입을 사용한다면.)

 

결론

이번 포스팅을 위해 다시 한 번 아키텍처에 대해 정리하는 기회를 갖게 되었다.

레이어드와 클린 아키텍처를 결합한 구조는 비즈니스 로직을 중심으로 각 계층의 역할을 명확히 분리하고, 의존성을 효과적으로 관리한다. 이는 코드의 유지보수성과 확장성을 크게 향상시킬 수 있다.

하지만 아직 실무 경험이 많지 않은 주니어 개발자로서, 이러한 아키텍처를 실무에 적용하기 위해 좀 더 깊게 파고들 필요성을 느낀다. 또 현재 주 사용언어가 Python 인 만큼 Java 중심으로 배웠던 위 이론들을 어떻게 Pythonic 하게 적용할 수 있을지에 대한 고민도 오랜 시간 해봐야 할 것 같다. 무엇보다 이론에 너무 얽매여 생산성이 저하되지 않도록 스스로의 업무 흐름을 살피는데 주의를 기울여야겠다는 생각도 들었다.

이번 포스팅 한 번으로 끝날 내용은 절대 절대 아님을 다시 한 번 되새기며 글을 마친다.

---

항해 플러스' 간단 소개

https://hanghae99.spartacodingclub.kr/

개발자 커리어 개척 캠프 항해99, 첫 취업부터 현직자 역량 강화까지

간단히 말하면 '항해99'에서 진행하는 주니어 개발자들을 위한 부트캠프이다.

• 현업의 멘토들과 기대 이상으로 더 가까이 대화하고 배움을 얻을 수 있다.
• 수료생들은 여러 세미나와 모임에 대한 정보를 우선적으로 제공받을 수 있다.
  '오늘은 써야지' 모임 역시 항해 플러스 수료 이후에 꾸준히 제공된 정보를 통해 지원할 수 있었다.

 

끝으로 내가 항해 플러스를 지원하기로 마음먹은 결정타 멘트를 소개한다.

팀에 사수가 없어서 조언이나 코드 리뷰를 받기 어려워요.

소개 글을 쓰는 지금 항해플러스 9기 모집이 예정되어 있다. (6월 중 예상)
지원 시 전 수료생의 추천인 코드를 입력하면 20만원 할인 혜택을 받을 수 있다.
항해플러스 추천 할인코드: 6g4pYi