About Directory

협업에 좋은 구조, 코드에게 좋은 구조

아키텍쳐에 대한 정의가 이루어진 후, 어떤 방식으로 협업을 하는 것이 좋을지 고민했습니다. 제가 기존에 도입해본 방법은 아래와 같습니다.

• 파일의 성격을 기준으로 폴더를 나누는 방법
• 화면 기준으로 폴더를 나누는 방법

두 방법을 사용하면서, 분명한 장단점이 존재했습니다.

• 파일 기준
  • 파일 접근 자체는 편하나, 어떤 화면에 귀속되어 있는 파일인지 파악이 어려움
• 화면 기준
  • 화면 단위로 파일이 모여있지만, 여러 화면이 하나의 비즈니스 로직을 처리하는 경우, 해당 파일의 위치가 애매해짐

이러한 문제들에 대해서, 좋은 구조를 찾기 위해서는 우리가 어떤 방식으로 일하고 싶은가를 정의하는 것이 우선이었습니다. 저희는 화면 단위로 일감을 나누어서 진행하기 보다는, 모두가 프로젝트의 이해도를 높히면서, 남의 코드 역시 수정하는 경험 자체를 하는 것이 서로의 성장에 더 도움이 된다고 생각했습니다.

따라서 특정 화면이 있을 때, 해당 화면의 비즈니스 로직을 담당하는 사람, 화면을 그리는 부분을 담당하는 사람 이렇게 둘로 나누었습니다. 이런 방식으로 일을 한다고 했을 때, Clean Architecture 구조를 보게 되었고, Layer를 기준으로 구조를 나누고 있음을 확인했습니다. 추후 가장 오른쪽의 사진과 같이 표현 계층, 도메인 계층, 인프라 계층과 같이 핵심 계층를 나누고, 도메인 계층과 표현 계층 사이는 인터페이스를 정의하여 서로 병렬 작업이 가능하도록 하였습니다.

결과적으로, 폴더를 왔다갔다 해야하는 수고스러움이 줄어들었고, 또한 완전한 병렬작업이 가능했기에, 팀 전체의 생산성을 향상 시킬 수 있었습니다.