Golang의 표준 Project Structure에 관해 세부적으로 알아본다. (지속적으로 업데이트)
1. CMD folder
CMD folder가 나온 이유는 go build 명령어와 깊은 연관이 있다.
먼저, go 공식 document에서는 go build를 다음과 같이 정의한다.
go build 정의: compile packages and dependencies.
go build [-o output] [build flags] [packages]
여기서, 우리는 packages에 주목해야 한다.
package는 directory 범위를 뜻한다.
CMD folder의 필요성을 이해하고자 할 때 사실 제일 방해되는 부분이 go build 명령어를 입력했을때 파일 범주로도 build가 된다는 것이다.
예를 들어,
TEST project
---- firstmain.go
---- secondmain.go
이런식으로 project structure가 잡혀있고, 각 firstmain.go / secondmain.go 안에 main 함수가 있다면
go build firstmain.go 이렇게 해도 문제 없이 작동한다. (go build secondmain.go도 마찬가지로 잘 동작.)
그런데 사실 여기에 한 가지 문제가 있는데, 만약 firstdependency.go라는 파일을 추가하고 안에 sum이라는 함수를 만든 뒤 firstmain.go에서 이를 import하면 build 할 때 sum이라는 함수를 찾지 못한다는 에러와 함께 빌드에 실패하게 된다.
go build firstmain.go firstdependency.go 이런식으로 build를 해야 에러 없이 빌드에 성공한다.
그리고 또 한가지 문제가 있는데, 만약 binary가 다른 버전으로 두 개가 필요하면 어떻게 될까? (예를 들어, 테스트용 binary라던지)
그럴 경우 우리는 go build firstmain.go firstdependency.go 혹은 필요에따라 go build secondmain.go seconddependency.go 이런식으로 파일을 나열해주면서 build를 진행해야 한다. 지금이야 파일이 몇 개 없어서 무슨 문제가 있나 싶겠지만, 문제는 나중에 서로 연관된 파일이 뭔지 묶는 것도 어렵고 관리하기가 어려워 진다. 또한, 이 프로젝트를 처음보는 사람에게 있어서 프로젝트를 이해하기가 어려워지는 문제점도 있다.
이럴 해결하기 위해 나온 것이 CMD folder이다.
CDM folder를 만들고 그 하위에 사용할 바이너리 명과 일치하게 folder를 추가한다.
ex)
TEST project
---- cmd
---- first
---- firstmain.go
---- firstdependency.go
---- second
---- secondmain.go
---- seconddependency.go
이렇게 해두면 처음 프로젝트에 접근한 사람도 실행파일에 대해 한 번에 알아볼 수 있고, 빌드를 진행할 때도 go build first 혹은 go build second 이런 식으로 할 수 있다.
2. internal folder (추후 업데이트 예정)