이해하기 쉽게 정리하는 클린 아키텍처

이 글은 ‘만들면서 배우는 클린 아키텍처’ 라는 책으로 회사 내부 스터디를 하며, 이제 막 개발을 시작하시거나 개발자들과 협업하시는 분들을 위해 이해하기 쉽게 클린 아키텍처란 무엇인지에 대한 글을 작성해 보았습니다

개발자들이 아키텍처 설계하는 기간 동안 무엇을 하는지 이해해보는 시간이 되셨으면 좋겠습니다

 

---

 

아키텍처란 무엇일까?

애플리케이션 아키텍처는 ‘애플리케이션을 설계하고 구축하는 데 사용하는 패턴과 기술’ 입니다. 아키텍처는 애플리케이션을 구축할 때 따라야 할 로드맵과 모범 사례를 제공하여 체계적으로 구성된 애플리케이션을 완성할 수 있게 해줍니다

아키텍처를 조금 더 쉽게 이해하기위해 사에서의 업무 프로세스로 예시를 들어보겠습니다

 

어느 회사에 업무 프로세스가 없다고 하면, 직원들이 자기 스타일로 업무를 하고 제 각각의 문서 형식과 정리되지 않는 문서함들 및 컴퓨터 공유폴더, 심하게는 외부로 보내는 공문의 형태와 명함의 모양까지 다를 수 있습니다

그리고 누가 어떤 업무를 하는지 명확하지 않을 수 있습니다

 

이렇게 일을 하다 보면 같은 업무를 하더라도 이 다른 직원의 업무를 파악하는데 시간이 걸리고 업무 협업이 있을 때 많은 문제가 발생할 수 있으며, 문제가 생기면 어디서 생긴 문제인지도 찾기 힘들어집니다

 

그래서 기업에서는 업무 프로세스에 조직의 구조, 직원들의 역할, 문서와 공유할 것들을 정리하여 업무를 원활히 진행할 수 있게 도와줍니다

 

---

 

문제가 있는 업무 프로세스

업무 프로세스를 정의하면서 까지 규칙을 정하는 이유는 뭘까?

심리학자 필립 잠바르도(Philip Zimbardo)는 1969년에 '깨인 창문 이론'이라고 알려진 실험을 했습니다

번호판이 없는 차를 주거환경이 좋은 지역에 세워 뒀지만 일주일 동안 아무런 문제도 일어나지 않았습니다

하지만 잠바르도가 일부러 창문을 깨뜨린 이후에는 24시간도 지나지 않아 차의 주요 부품들이 도난 당했고 행인들은 아무렇지 않게 차를 망가뜨리기 시작했습니다

 

위에 실험처럼 누군가가 조금 더 편한 업무를 위해 업무 프로세스 규칙을 지키지 않는걸 시작 한다면, 다음 사람도 규칙을 어길 가능성이 높아지고 나중에는 규칙을 어기는게 당연하게 여겨져 문제가 생길것 입니다

그래서 우리는 다소 힘들더라도 규칙을 지키면서 업무를 해야 할 책임이 있습니다

 

명확하지 않은 업무환경

규모가 작은 기업의 경우에는 부서의 역할이 명확하지 않거나 그 부서가 하는 일이 많을 때가 있습니다
인원이 많지 않고 서로가 어떤 업무를 하고 있는지 알고 있어서 상관이 없다고 생각할 수 있지만 신규 입사자가 늘어나고 회사가 점점 커지면 누가 어떤 업무를 하는지 몰라서 생길 수 있는 문제점이 많이 생기게 됩니다

 

그래서 보통의 회사들은 역할에 맞는 경영지원, 마케팅, 영업, 개발 등등의 부서로 나누게 되고 그 안에서도 각각의 팀으로 분리하고, 직원들의 업무 또한 명확하게 규정하고 있습니다

 

 

유연하지 못한 업무 프로세스

회사의 모든 결제를 담당하는 직원이 있다고 가정해 봅시다

결제를 하기 위해서는 사내 이메일만로 요청을 했었지만 사내 회계 프로그램 도입으로 요청할 수 있는게 추가 된다면,

결제 담당직원의 업무가 추가되면서 문제가 발생할 수 있습니다

 

만약, 결제 업무 요청 받는 직원과 결제 업무를 담당하는 직원 각각 존재 한다면 다른 방식의 업무 요청 방식이 생기더라도 큰 문제가 생기지 않을 것입니다

 

업무 요청의 방법과 순서

고객사에서 영업부서로 계약서 작성 요청이 왔다고 가정해 봅시다

이 경우 업무 요청은 고객사에서 영업부서로, 영업부서는 경영지원부서로, 정해진 방향으로 업무가 되야 합니다

만약 고객사에서 경영지원부서로 바로 요청을 하게 된다면 당장은 큰 문제가 생기지 않지만 위에서 이야기한 깨진유리창처럼 반복되는 상황이 발생해 나중에는 문제가 생길 수 있습니다

또 각 부서 간에 협업을 할 때 정해진 형식의 문서를 사용하지 않은 상태에서 내용을 전달하고 피드백을 받게 되면  함께 일하는 직원들은 해당 내용을 이해하는 과정을 거쳐야만 할 것입니다

 

그렇기 때문에 정해진 업무 프로세스를 유지하여야 합니다

또한 영업부서는 고객사로 부터 받은 자료를 경영지원부서가 요청하는 형식의 문서로 변경하여 넘기고,

경영지원부서는 영업부서로 부터 받은 요청서를 경영지원부서의 규정에 맞추어 추가적으로 정리하여 내부 문건으로 남기는 방법을 사용한다면 서로 이해하는 과정이 없어지고 예상치 못한 문제가 발생할 확률도 줄어들 것입니다

로고 디자인 업무 프로세스

 

---

 

좋은 업무 프로세스를 만들기 위한 방법

명확한 업무 이름 (네이밍)

부서가 어떤 일을 하는지, 그 직원이 어떤일을 하는지 알아야 할 경우 명확한 업무 이름을 지정하면 이름만 보고도 어떤 업무를 누가 하는지 이해하기 쉬워집니다

예를 들어 채용을 담당하는 팀이 있다면 <인사팀>보다는 <채용팀>이라는 부서명이 더 명확할 것이며, 직원의 업무 역시 <채용팀 사내추천 담당>과 같이 어떤 업무를 하는지 정확하게 표현하는 게 좋습니다

 

개발 역시 이름을 정해야 할 곳이 많이 있습니다

패키지 이름, 메서드 이름, 변수 이름 등..을 정할 때 이름을 보고 알 수 있도록 정해주는 게 좋습니다

네이밍에 대한 룰은 '클린 코드'와 같은 책을 참고하시면 좋습니다

 

명확한 부서 구분 (패키지 구성)

이번엔 회사의 부서를 어떻게 나누는 게 좋을까?

개발부서도 기획팀, 프런트엔드팀, 백엔드팀, QA팀 등으로 세분화할 수 있듯이 회사의 부서도 회사의 규모와 업무 영역에 따라서 변화될 확률이 높습니다

 

개발 역시 소프트웨어의 규모나 목표에 따라 다르겠지만 최소한의 역할이 부여된 파일과 그 파일들을 그룹별로 잘 묶을 수 있는 폴더 구조는 반드시 필요합니다

예를 들어 사용자의 정보를 얻는 곳을 service.user 폴더가 아닌 service.user.find.info 폴더에 보관을 한다면 좀 더 명확하게 구분을 할 수 있을 것입니다

 

정확한 역할 분담 (역할 세분화)

직원이 한 가지 업무만을 담당하는 것이 논리적으로는 가장 좋은 역할 분담이지만 현실적으로는 불가능한게 사실입니다 만약 한 직원이 여러 가지 업무를 담당하고 있고 그 업무가 과도하게 늘어난다면 다른 직원에게 업무를 분배해줘야 합니다

 

개발을 할 때는 모든 역할을 한 곳에 두지 않고 나눌 수 있는 제일 작은 단위까지 나눠서 작업을 하는 게 좋습니다

예를 들어 사용자의 정보를 얻는 곳을 UserInfo.java 라는 파일에서 모두 작업하지 않고 UserName.java, UserAddress.java 와 같이 세분화시켜서 작업을 진행을 해야 합니다

 

팀별 커뮤니케이션 문서 (매핑 전략)

다른 부서와 협업을 진행해야 할 때는 문서를 받아야 하는 부서에서 요구하는 양식에 맞추어 파일을 생성하여 요청을 해야 합니다 이와 마찬가지로 요청에 대한 정보를 다른 부서로 부터 받았을 때에도 다시 우리 부서의 양식에 맞게 수정을 해야 합니다 

이렇게 주고 받는 양식이 정해져 있다면 해당 부서에서 요청을 하기전에 미리 예상되는 업무를 진행할 수도 있습니다

 

개발 역시 계층 간에 데이터를 이동할 때 데이터를 정리해서 주고받아야 합니다

서비스 영역에서 DB에 저장할 때 매핑을 통해 DB 저장을 할 수 있는 형태로 변환 해서 데이터를 넘겨 주고,

서비스 영역에서 DB에 데이터를 요청할 때도 DB에서는 서비스 영역에서 필요한 데이터만 추출해서 매핑하여 전달해야 합니다

DB에 있는 데이터 전체를 넘겨서 서비스 영역에서 처리하는 방식은 지양해야 합니다

 

업무의 구분

고객사에서 영업부서로 계약서 작성 요청이 들어왔을 때 영업부서에는 우선 고객사의 요청이 올바른지 체크를 하고 그 요청을 해결하기 위해 필요한 정보가 다 있는지 확인을 한 후에 영업부의 문서로 저장, 다시 경영지원부서에 요청을 해야 합니다 만약 고객사에서 보낸 요청을 바로 경영지원부로 보낸다면 경영지원부서에서는 예상치 못한 문제가 발생할 수 있습니다

 

개발에서 REST API에서의 업무 구분을 예를 들어보면

컨트롤러에서는 요청하는 주소가 맞는지, 요청 권한이 있는지, 원하는 데이터가 맞는지 유효성 체크 후 서비스를 호출하고

서비스에서는 로직을 통해서 값을 계산하고 추출하고 DB로의 저장 요청을 하게 되면

DB에서 저장하거나, 필요한 데이터를 추출해서 반환합니다

이처럼 컨트롤러, 서비스, DB에서 하는 업무가 명확해야 합니다

 

업무를 시작할 때 문제가 없는지 살펴보기 (테스트)

우리는 업무를 시작할때 컴퓨터는 잘 작동하는지, 전화는 잘 되는지, 사내 시스템에 접속은 잘 되는지 기본적인 확인을 마친 후에 업무를 시작합니다

 

개발에서는 서비스에 문제가 없다고 판한다는 기준을 테스트 코드로 작성하여 판단합니다

새로 개발한 로직이 기존 로직에 영향을 미치는 사이드이펙을 체크하기 위해서는 테스트 코드 작성이 필요하며, 메서드를 검증하는 단위 테스트부터 전체 서비스를 체크하는 시스템 테스트까지 진행을 해야 합니다

 

---

끝으로...

지금까지 아키텍처란 무엇인지와 아키텍처를 구성할 때 조심해야 하는 방법을 회사 업무 프로세스에 비유하여 알아봤습니다  아직 설명하지 않는 많은 방법들이 있지만 글쓴이 입장에서 꼭 필요하다고 생각하고 해야하는 것들로만 작성을 해봤습니다

 

하지만 저 방법들을 무조건 지켜야 하는 건 아닙니다

왜냐하면 모든 회사에서 동일한 업무 프로세스로 일할 수 없는 것처럼 모든 개발 프로젝트 또한 동일하게 작업할 수 없기 때문입니다

개발자로서 조금 더 좋은 개발을 하고 유지보수가 좋은 개발을 하기 위해 미리 알아두고 적재적소에 사용을 하는것이 좋습니다

 

조금 더 개발자적인 글을 보고 싶으신 분들은 점핏팀에 다른 분이 작성해놓은 아래 링크를 확인해 보시길 권해드립니다

 

https://medium.com/jumpit/flutter-3-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EA%B8%B0%EB%B3%B8-%EA%B5%AC%EC%A1%B0-clean-architecture-fa2bb329e8df

 

감사합니다