서론

아마 프로그래머 분들이라면 한번 쯤 클린코드라는 책을 들어보셨을 것 같은데요, 클린 아키텍처 역시 마찬가지입니다. 오랜 기간 동안, 프로그래머로 일해오신 로버트 C. 마틴 작가님께서 쓰신 책입니다. 제가 알기론 반 세기(!?) 동안 프로그래머로 일하셨다고 해요. 정말 대단하지 않나요?
오늘 다뤄 볼 클린 아키텍처는 소프트웨어 설계 방법론으로 주로 웹이나 모바일 앱의 아키텍처로 자주 활용된다고 합니다. 단순히 프레임워크를 사용할 줄 아는 수준을 넘어, 저를 포함하여 조금 더 체계적이고 소프트웨어를 만들고 싶은 분들이라면 오늘 내용에 주의를 기울여보면 좋은 통찰을 얻어갈 수 있으시리라 생각합니다.

아키텍처? 왜 알아야할까.

소프트웨어 개발자로 일하다보면, 소프트웨어 아키텍처에 관한 이야기와 글들은 평소에도 쉽게 접하실 수 있을 겁니다. 그만큼 자주 언급되고 사람들이 관심을 갖는 까닭은 그만큼 중요해서겠죠? 본격적으로 클린 아키텍처에 대해서 알아보기 전에, 아키텍처란 무엇인지 짚고 넘어갑시다.

소프트웨어 아키텍처란 소프트웨어의 구성요소들 사이에서 유기적 관계를 표현하고 소프트웨어의 설계와 업그레이드를 통제하는 지침과 원칙이다. (위키피디아)

아키텍처는 쉽게 말해, 소프트웨어를 설계하는 방법이자 지켜야 할 원칙입니다. 소프트웨어 설계에 원칙을 적용하는 까닭은 꽤나 분명해 보입니다. 바로 더 좋은 소프트웨어를 만들기 위함일텐데요, 그렇다면 어떤 원칙을 갖는 것이 좋은 소프트웨어를 만드는 데 도움이 될까요?

소프트웨어가 가진 본연의 목적을 추구하려면 소프트웨어는 반드시 '부드러워'야 한다. 다시 말해 변경하기 쉬워야 한다. 이해관계자가 기능에 대한 생각을 바꾸면, 이러한 변경사항을 쉽게 적용할 수 있어야 한다. (이하 로버트 C. 마틴, 클린 아키텍처)

저자가 이야기하듯, 좋은 소프트웨어는 유연한 소프트웨어라고 합니다. 그리고 유연한 소프트웨어란 고객의 요구사항에 따라, 쉽게 그 기능을 변경하거나 추가할 수 있는 제품을 말합니다. 따라서 고객의 요구사항이 변화함에 따라, 개발자가 제품의 기능을 쉽게 변화할 수 있는 구조를 설계하도록 돕는 아키텍처가 좋은 아키텍처가 되겠죠? 세상에는 이를 위해 다양한 아키텍처가 존재하는데요, 클린 아키텍처도 그 중 하나입니다. 먼저 그 구성요소를 살펴보겠습니다.

클린 아키텍처의 구성요소

클린 아키텍처를 구글에 검색하면 가장 많이 나오는 게, 바로 첫번째 그림인 원형 다이어그램입니다. 그만큼 이 다이어그램이 클린 아키텍처의 특성을 잘 드러내기 때문인 것 같습니다. 그림을 자세히 살펴보면, 다양한 용어들이 등장하는 것을 알 수 있습니다. 그래서 아키텍처에 관한 설명에 앞서, 구성요소에 대한 용어 설명을 드리고자 합니다.

1. 엔티티

먼저 가장 안쪽에 위치한 엔티티입니다. 엔티티는 'Enterprise wide business rules'을 캡슐화한 요소인데요, '개념적으로 그렇구나' 정도로 이해하시면 될 것 같습니다. 엔티티는 제가 첨부드린 두번째 그림에서 알 수 있듯, 일반적으로 규칙이 변경 될 가능성이 가장 적고 피라미드 구조의 가장 높은 위치의 규칙이기도 합니다. 개념적으론 그렇구요, 실제로 개발할 땐 그러한 인터페이스나 클래스 내부에 속성과 메소드 형태로 작성합니다.

1. 유스케이스

유스케이스는 생산자 관점에서 보면 이 계층에서 제품의 비즈니스 로직을 정합니다. 비즈니스 로직이란 소프트웨어 설계에 알맞게 데이터를 변경하고 가공하는 방법을 말하는데요. 여기서 데이터란 상위 계층인 엔티티를 의미하겠죠? 다시 말해, 엔티티에 기술된 정보들을 참조하여, 사용자의 요청에 따라 알맞게 데이터를 가공하거나 출력해주는 역할을 합니다. 사용자 입장에서 보면, 좀 더 간단합니다. 예를 들어, 유튜브 앱을 이용할 때 무얼 하시나요? 동영상을 검색하고 원하는 동영상을 보겠죠? 좋아요를 표시하거나 댓글을 남기기도 합니다. 여러분이 앱에서 누르는 클릭과 입력 하나 하나가 전부 어플의 유스케이스입니다.

1. 인터페이스 어댑터

그럼 어댑터는 무슨 역할을 할까요? 어댑터는 데이터 형식을 변환하는 역할을 하는 요소입니다. 그럼 데이터 형식은 왜 바꿔야 할까요? 개발 생태계에선 지금 사용하고 있는 프레임워크보다 언제든지 더 좋은 성능과 사용성을 가진 프레임워크가 나오기 마련이고 프레임워크에 대한 의존성이 낮다는 가정 하에 변경하기도 쉬운 요소입니다. 만약 그 때마다 프레임워크에 맞춰 내부 로직을 수정한다면 소프트웨어를 유지 보수할 때 불편함이 많겠죠? 이 때 인터페이스 어댑터가 유스케이스를 앱이나 웹 같은 외부 에이전시에게 가장 편리한 형태로 바꾸는 역할을 해줍니다. 개발 플랫폼에 따라 어댑터의 로직을 조금 수정하면 되니 내부 비즈니스 로직은 그대로 유지한 채 개발할 수 있으니 편리하겠죠? 이에 관해, 구글에 어댑터 패턴을 검색하셔서 관련된 글들을 읽어보시면 이해가 잘 되실 겁니다.

1. 프레임워크와 드라이버

앞서 언급한 웹 혹은 앱 프레임워크가 대표적입니다. 대표적으로 앱 프레임워크인 '플러터'와 웹 프레임워크인 '앵귤러' 등이 있을 것입니다. 사실 큰 회사에서 자사 프레임워크 하나씩은 밀고 있죠. 구글에선 '플러터'와 '앵귤러, 페이스북에선 '리액트 네이티브'와 '리액트' 마이크로소프트에선 .Net 프레임워크 기반의 '사마린'을요. 각각 성능과 사용 방법에 따라서 크고 작은 차이가 있으므로, 그 때 그 때마다 적합한 프레임워크를 선택하는 것도 중요하리라 생각됩니다.

클린 아키텍처 설계의 네 가지 원칙

이제 구성요소들에는 무엇이 있으며 특징은 무엇인지 살펴보았으니, 본격적으로 클린 아키텍처의 설계 원칙에 대해서도 알아보도록 하겠습니다.

1) 내부 영역으로 갈수록 변경될 가능성이 낮아야 합니다.

위 그림을 보았듯, 클린 아키텍처는 원 안에 여러 개의 원들이 각각을 감싸고 있는 형태임을 알 수 있습니다. 원의 안쪽으로 갈수록 변경되지 않는 데이터이며 반대로 바깥쪽으로 갈수록 변경될 확률이 높은 요소들이 위치합니다. 원의 가장 안쪽에는 변경될 가능성이 적은 엔티티가 위치하고, 변경될 가능성이 높은 UI/DB 등을 원의 가장 바깥쪽에 위치시킵니다. 이렇게 분리해두면, 변경사항이 생겼을 때 바깥쪽을 중심으로 살펴보면 되니 작업이 수월하겠죠?

2) 외부 영역은 내부 영역에 의존할 수 있지만, 내부 영역은 외부 영역에 의존할 수 없습니다.

이렇게 소프트웨어를 설계하면, 각 계층 간 의존성이 낮아지고 역할 구분이 명확해짐에 따라, 에러 발생의 가능성을 줄이고 코드 유지보수를 더욱 수월하게 처리할 수 있게 됩니다. 이에 관해, 저자의 말을 추가하겠습니다.

클린 아키텍처가 갖는 기본의 목적 역시 관심사를 분리하는 것입니다. 각각의 관심사에 따라 계층을 나누고, 세부 구현이 아닌 도메인 중심으로 설계하며, 내부 영역이 프레임워크나 데이터베이스 UI 등의 외부 요소에 의존하지 않도록 합니다.

3) 좋은 아키텍처는 프레임워크에 의존하지 않습니다.

원형 다이어그램의 가장 바깥쪽에 프레임워크가 위치한 게 보이시죠? 앞서, 원의 바깥쪽에 위치한 요소일수록 변경될 가능성이 높고 의존성이 높다고 이야기했습니다. 이는 클린 아키텍처가 프레임워크와의 의존성을 최소화하기 위한 설계 방법이기 때문입니다. 과거의 저처럼 '프레임워크에 의존하지 않는다고? 그러면 어떻게 개발을 해?'라고 생각하시는 분도 있을 것 같습니다. 하지만 프레임워크는 어디까지나 개발 생산성을 높이는 도구이지, 프레임워크 때문에 내부 로직이 좌우되는 상황은 발생되선 안됩니다. 클라이언트 측 요구사항이 변경되었을 때, 기능을 바꾸기 어렵기 때문이죠. 유지 보수가 어려워지는 문제도 발생하구요.

프레임워크는 매우 강력하고 상당히 유용할 수 있다. 그러나 아키텍처의 중심을 차지하는 일은 없어야 한다. 아키텍처는 프레임워크에 대한 것이 아니다. 시스템에 관한 것이다. 따라서 아키텍처를 프레임워크로부터 제공받아서는 절대 안 된다. 프레임워크는 사용하는 도구일 뿐, 아키텍처가 준수해야 할 대상이 아니다. 아키텍처를 프레임워크 중심으로 만들어버리면 유스케이스가 중심이 되는 아키텍처는 절대 나올 수 없다.

그렇습니다. 프레임워크는 소프트웨어의 개발에 필요한 여러 기능들을 제공함으로써 개발자의 생산성을 높여주는 좋은 도구입니다. 그렇지만 프레임워크에 사용하는 것에 익숙해지는 것이 꼭 좋은 일은 아니라고 합니다. 그 까닭은 프로젝트에서 프레임워크에 대한 의존성이 높아지게 되기 때문입니다. 갑자기 프레임워크의 지원이 중단된다면, 큰 어려움을 겪게 되겠죠? 또한 프레임워크를 사용하면 개발 방식이 프레임워크에 적합한 방식으로 제한되기도 합니다. 예를 들어, 리덕스를 사용하면 하나의 동작을 처리하기 위해서 reducer, action, dispatch 함수를 추가해줘야만 하죠. 이는 리덕스가 Flux 디자인 패턴을 따르기 때문입니다.

프레임워크 제작자는 당신도 자신의 프레임워크에 결합되기를 바란다. 한번 결합하면 그 관계를 깨기가 매우 어렵기 때문이다. 그러나 프레임워크와는 거리를 두어야 한다. 가급적이면 프레임워크를 가능한 한 오랫동안 아키텍처 경계 너머에 두자.

DB 역시 마찬가지입니다. DB는 어디까지나 세부사항이며, 아키텍처에서 우선적으로 고려할 요소는 아니라고 저자는 이야기합니다.

데이터는 중요하나, 데이터베이스는 세부사항이다. 체계화된 데이터 구조와 데이터 모델은 아키텍처적으로 중요하나, 그저 데이터를 회전식 자기 디스크 표면에서 이리저리 옮길 뿐인 기술과 시스템은 아키텍처적으로 중요치 않다.

4) 유스케이스는 아키텍처에서 최우선이다.

클린 아키텍처에서 핵심이 되는 요소는 바로 UseCases입니다. UseCases는 앞서 언급했듯, 비즈니스 로직을 담당하므로 어플리케이션의 주요 로직을 담은 부분이라고 할 수 있습니다. 이 부분은 앞서 여러 설명을 하였으니, 저자의 말로 갈음하겠습니다.

좋은 아키텍처는 유스케이스를 그 중심에 두기 때문에, 프레임워크나 도구, 환경에 전혀 구애받지 않고 유스케이스를 지원하는 구조를 아무런 문제 없이 기술할 수 있다. 좋은 소프트웨어 아키텍처는 프레임워크, 데이터베이스, 웹 서버, 그리고 여타 개발 환경 문제나 도구에 대해서는 결정을 미룰 수 있도록 만든다. 좋은 아키텍처는 유스케이스에 중점을 두며, 지엽적인 관심사에 대한 결합은 분리시킨다.

아키텍처가 유스케이스를 최우선으로 한다면, 그리고 프레임워크와는 적당한 거리를 둔다면, 프레임워크를 전혀 준비하지 않더라도 필요한 유스케이스 전부에 대해 단위 테스트를 할 수 있어야 한다. 테스트를 돌리는 데 웹 서버가 반드시 필요한 상황이 되어선 안 된다. 데이터베이스가 반드시 연결되어 있어야만 테스트를 돌릴 수 있어서도 안 된다. 엔티티 객체는 반드시 오래된 방식의 간단한 객체여야 하며, 프레임워크나 데이터베이스, 또는 여타 복잡한 것들에 의존해서는 안 된다.

실제 어플리케이션에서의 클린 아키텍처

아래의 그림은 앞서 보았던 클린 아키텍처의 구성요소들을 실제로 구현하기 위해, 앱에서 각각의 요소들의 역할을 하는 요소들로 구분한 것 입니다. 아래의 예시는 타입스크립트가 활용된 프론트엔드 아키텍처를 클린 아키텍처로 적용하는 상황을 가정했습니다. 따라서 클라이언트의 API 요청이 자동으로 백엔드에서 처리되는 것으로 봐주시면 될 것 같습니다.

1) Data Layer

먼저, 앱의 Data Layer부터 살펴보겠습니다. 예시코드에선 Data Layer에 클린 아키텍처의 구성요소 중 Entity가 속합니다. 데이터 레이어는 말 그대로 데이터 작업과 관련된 모든 작업을 해준다고 보면 될 것 같습니다. 하위 요소들에 대한 설명은 아래와 같습니다.

• Entity : 앞서 살펴본 Entity와는 조금 다른 의미를 갖습니다. 넓은 의미에서의 개념적인 설명을 위주로 설명했다면, 실제 구현할 때의 Entity는 좀 더 좁은 의미를 갖습니다. 제가 든 예시에서 Entity는 데이터 소스에서 활용되는 데이터를 정의한 인터페이스입니다. 여기선 클라이언트 측에서 네트워크 요청을 통해, 백엔드 서버로 받아온 데이터를 받아오는 상황이므로 엔티티는 서버 응답에 대한 형식을 정의한 인터페이스입니다. 이게 데이터 소스에서도 활용되는 것이죠.

// 서버 응답 (json)
{
    _id : 5151251234,
    title : "Clean Architector",
    author : "joonho lee",
    createdAt : "2021-06-22T14:32:42.928Z"
    views: 8,
}

// Entity : 응답에 대한 인터페이스 
interface sampleEntity {
    _id : number,
    title : string,
    author : string,
    createdAt : Date,
    views : number,
}

• DataSource : 이 영역은 데이터의 입출력이 이뤄지는 영역인데요, 한 마디로 서버로 요청을 주고 받는 역할을 한다고 보시면 될 것 같습니다. 따라서 Entity는 응답의 결과이고 데이터 소스는 서버로부터 응답을 받기 위한 데이터를 요청하는 것이 이 계층의 역할입니다. 가장 간단한 예시는 서버로부터 간단하게 데이터를 조회하는 Get 요청이 이 영역에 해당 될 것입니다.

GET, htttp://localhost:5000/post/1213 (요청)

class SamepleDataSource {
    async getPost(id : number) : Promise<sampleEntity> {
        const postInfo = await fetch(`htttp://localhost:5000/post/${id}`, {
            method: "GET"
        });
          return postInfo;
    }

    async viewIncrease(id: number): Promise<void> {
         await fetch(`/api/videos/${id}/view`, {
            method: "POST",
          });
    }
}

2) Domain Layer

앱의 도메인 레이어에선 클린 아키텍처의 유스케이스가 구현됩니다. 하위 요소들에 대한 설명은 아래와 같습니다.

• Repository & Translater : Repository는 유스케이스가 필요로 하는 데이터 저장/수정 등의 기능을 제공하는 클래스입니다. 데이터 소스를 인터페이스 형태로 참조하기 때문에 이 클래스에서 데이터소스 객체를 갈아끼우는 형태가 됩니다. 또한 Tranlator와 함께 구현했습니다. 실제로 구현할 땐 어플의 규모에 따라 하위 요소들을 축소/변형하기도 합니다.

interface SamepleRepository {
    getPost(id: number): Promise<sampleModel>;
}

class SampleRepositoryImpl implements SampleRepository {
    public async getPost(id: string): Promise<sampleModel> {

    // Entity에 접근하는 로직입니다. 
    const postEntity = await this._remote.getDetail(id);

    // Translater의 역할을 plainToClass란 메소드에서 처리해줍니다. 
    const postModel = plainToClass(PostModel, {
      id: postEntity._id,
      url: postEntity.image.mobile.location,
    });

   return postModel;
  }

   public async getPost(id: string): Promise<void> {
    this._remote.viewIncrease(id);
  }
}

• Model : 실제 사용될 데이터 형식을 정의하고 사용자의 입력에 대한 올바른 형식에 조건을 추가합니다. 모델 클래스가 따로 존재하는 까닭은 엔티티를 바로 활용할 수 없기 때문인데요, 모델은 엔티티를 Presentation Layer에서 활용하기 쉽도록 데이터 형식을 변환하기 위함입니다. 예를 들면, 아래와 같이 Class 형태로 변환해주는 것이죠.

export default class PostModel {
  public id: number;
  public title: string;
  public category: string;
  public lowCateogry: string;
  public content: string;
  public createdAt: Date;
  public imageSource: string;
  pulbic view: number;
}

• UseCase : 비즈니스 로직이 담긴 부분입니다. 여기서는 사용자가 데이터를 조회하기 위해, 게시글을 불러오는 로직을 예시로 담았습니다. 추가로 게시글의 조회수를 증가하는 등의 프론트엔드 로직들이 여기에 추가될 수 있을 것입니다.

class GetPostUseCases {
  private _repairRepository: RepairRepository;

  public execute(id : string): Promise<PostModel>{
    this._postListRepository.viewInCrease(id);
    return this._postListRepository.getPost(id);
  }
}

3) Presentation Layer

앱의 Presentation Layer에서는 나머지 인터페이스 어댑터와 프레임워크가 구현됩니다.

• Presenter : 이 부분은 리액트 상태관리 라이브러리 중 하나인 MobX를 예로 들어 설명하겠습니다. 여기에 저장되는 데이터는 실제 리액트에서 바로 활용될 수 있는 요소들입니다. 따라서 클린 아키텍처에서 인터페이스 어댑터의 역할을 수행한다고 보면 되겠습니다.

import { makeAutoObservable, observable } from "mobx";

class ContentStore {
    _contentList = observable.box([]);

    constructor() {
        makeAutoObservable(this);
    }

    get contentList() {
        return this._contentList.get();
    }

    set contentList(initialState) {
        this._contentList.set(initialState);
    }

    async getPost() {
        try {
            const posts = await GetPostUseCases.execute(); // 여기서 게시글 목록 데이터을 불러옵니다. 
            this._contentList.set(posts);
            return posts;
        } catch (error) {
            throw error;
        }
    }

}

const ContentsStore = new ContentStore();
export default ContentsStore;

• View : 이 부분을 보며, Presentation Layer는 프레임워크와의 연관성이 높은 영역임을 알 수 있을 것 입니다. 실제 프레임워크에 좌우되는 영향이 큰 계층입니다. React를 사용하는 경우로 예를 들겠습니다. 리액트의 경우에는 가상 DOM을 활용하여 컴포넌트 단위의 렌더링 방식을 채택하는데요, 그렇기 때문에 앱의 UI를 React Component로 구분지어 줘야 합니다. 거기에 JSX라는 문법이 가미되기 때문에, 새로 공부할 영역도 생겨나게 됩니다. 각설하고 아래의 코드는 Presenter에서 제공 받은 데이터를 받아와, Card 형식으로 데이터를 뿌려주는 역할을 합니다.

import React, { useEffect, useState } from "react";
import ContentsStore from "../../store/ContentsStore";

export default function Home() {
    const [post, setPost] = useState([]);
    useEffect(async () => {
        setPost(await ContentsStore.getPost());
    }, []);

    return (
        <main id="main">
            <section>
               <div>
                  <div>
                      <Card
                          key={post.id}
                          content={post.content}
                          view={post.view}
                      />
                    ))}
                  </div>
                </div>
            </section>
        </main>
    )
}

마무리 지으며..

이상으로 간단한 예시코드와 함께 클린 아키텍처에 관해 알아보았습니다. Github에서도 다양한 용례가 있는만큼, 쉽게 볼 수 있는 아키텍처 중 하나입니다. 초반에는 역할 분담을 나누는데, 어려움을 느끼실 수 있겠지만 익숙해지면 또 편하고 기능 변경에 대응하거나 앱을 확장 가능하게 가져가기 좋은 구조임은 분명해보입니다. 모두들 즐코하세요!

참고 할 만한 아티클

1. 모바일 앱에서의 클린 아키텍처
2. 클린 아키텍처 관련 글
3. 클린 아키텍처 관련 글
4. 리액트에서의 클린 아키텍처
5. 클린 아키텍처 (2018 번역판, 로버트 C. 마틴)