메뉴

문서정보

목차

원문 : Go project structure best practices

Go Project Structure Best Practices

Go 애플리케이션의 구조는 다소 논쟁적인 주제가 될 수 있다. Go 애플리케이션에 대한 구조는 Golang standards / Project Layout에 잘 정의되어 있다. 어떤 개발자는 참고하는 정도로 이용하지만 어떤 개발자는 반드시 이 구조를 따라야 한다고 주장하기도 한다. 내 입장은 "소프트웨어에서의 규칙은 가능하면 지키려고 하되 얽매일 필요는 없다"이다.

위 문서는 좋은 내용을 담고 있지만 Go 모듈이 도입되면서 수정이 필요하다. 이 문서는 Go 애플리케이션을 개발 할 때 참고 할 수 있는 다양한 구조들을 제시하고 있다.

Flat Structure - 작은 애플리케이션

많은 프로젝트들이 일단 소규모로 시작하다가 (성공할 것 같다거나 참여자가 많아지면)살을 붙여가는 방식으로 규모를 키워간다.

이러한 상황에서는 아래와 같이 간단한 플랫(Flat) 구조로 시작하는게 좋다. 프로젝트 구조를 간단하게 함으로써, 복잡한 구조를 분석하는 오버헤드없이 가능한 빠르게 대상 사용자에게 가치를 제공하는데 집중 할 수 있다. 간단한 구조는 개발자를 끌어모으는데도 도움이 된다.
.
└── applications
    ├── main.go
    ├── main_test.go
    ├── utils.go
    └── utils_test.go
종종 개발자들이 프로젝트의 초기 단계에서 코드베이스를 정리하고 재정렬하는데 많은 시간을 소비하는 것을 보았다. 이는 실제 가치있는 것이 전달되기 전에 개발자 혹은 개발팀내에서의 피드백, 목표 고객과의 피드백 간격이 길어지게 한다.

장점

Flat 구조는 그러니까 하나의 디렉토리에 모든 코드들을 몰아 넣는 구조가 되겠다.

참고 프로젝트들

중간규모 크기의 애플리케이션 - 모듈화

프로젝트의 규모가 커지고 복잡성이 증가하면 Flat 구조를 벗어난 구도화된 구조가 필요하다. 효과적인 구조는 프로젝트의 빠른 성장을 돕는다.

블로그 서비스를 위한 REST API를 예로 들어보자. 이 REST API는 유저 등록, 로그인, 로그아웃을 처리하기 위한 사용자 관리 API와 사용자의 컨텐츠를 처리(생성, 수정, 삭제 등)하는 컨텐츠 관리 API그룹으로 나눌 수 있을 것이다.

이제 애플리케이션은 의미별로 컴포넌트를 만들어서 분리하고, 각 컴포넌트에서 공유하는 핵심로직을 관리하기 위한 독립 패키지를 유지하기 위한 구조를 고민해야 한다.

.
└── rest-api
    ├── articles
    │   └── articles.go
    ├── main.go
    ├── user
    │   ├── login.go
    │   ├── registration.go
    │   └── user.go
    └── utils
        └── common_utils.go

참고 프로젝트들

성숙한 프로젝트

Hashicorp의 Terraform, Google의 Kubernetes와 같은 대규모 응용 소프트웨어는 $GOPATH가 사용되던 시절에 기본적인 개발이 완료된 프로젝트다. 이런 소프트웨어는 pkg와 같은 폴더를 여전히 사용하고 있다.

이러한 구조는 잘 작동하기는 하지만 Go Module이 널리 보급되면서 현대적인 구조로 마이그레이션되고 있다.