지난 몇 년간 뛰어난 소프트웨어 엔지니어들과 함께 일할 기회가 많았다. 인상 깊었던 점 중 하나는 많은 이들이 Makefiles에 대한 실질적인 지식이 없고, 그것이 왜 유용한지도 모른다는 것이었다.

빌드 과정을 자동화해야 할 때, 이들은 직접 만든 셸 스크립트로 해결하려는 경우가 많다. 프로젝트 폴더에서 흔히 볼 수 있는 build.sh, run.sh 혹은 doall.sh 같은 파일들이 그 주인공이다.

이들은 매번 같은 기본 기능들을 반복해서 구현한다:

• 입력 파라미터와 환경 변수 파싱.
• 빌드 단계 간의 의존성을 수동으로 관리.
• 오류 처리(…운이 좋다면).

그러는 과정에서 이들은 매번 같은 기본적인 실수를 반복한다:

• 입력 파라미터와 환경 변수를 잘못 다루기.
• 빌드 단계 간의 의존성 누락.
• 오류 처리를 잊고 — 심지어 더 나쁜 경우 — 프로그램 실행을 그대로 계속하기.

이런 문제들을 해결하기 위해 만들어진 것이 바로 Makefile이다.

Makefile은 무섭다!

make가 무섭다고 생각한다면, 아마도 대규모 소프트웨어 프로젝트를 위한 복잡한 빌드 시스템을 떠올리고 있을 것이다. 꼭 그렇게 복잡할 필요는 없다. make의 저자인 Stuart Feldman本人的 이야기를 직접 들어보자:

정교한 의존성 분석기라는 거창한 아이디어에서 시작해 훨씬 단순한 형태로 압축됐고, 그 주말에 Make가 탄생했습니다. 아직 덜 다듬어진 도구를 사용하는 것은 당시 문화의 일부였죠. Makefile은 마법처럼 인코딩된 바이너리가 아니라 텍스트 파일이었습니다. 그것이 유닉스 철학이었기 때문입니다: 출력 가능하고, 디버그 가능하며, 이해할 수 있는 것.

— The Art of Unix Programming (2003)

Make는 반복되는 문제를 간단하게 해결하기 위해 단 한 주말 만에 만들어졌다.

Makefile은 간단하다!

외출하기 전에는 옷을 입어야 한다. 나는 매번 같은 단순한 순서로 옷을 입는다. 속옷, 바지, 셔츠, 풀오버, 양말, 신발, 재킷 순서다. 아마 여러분도 자신만의 순서가 있을 것이다. 내 순서와는 조금 다를지라도.

이 단계들 중 일부는 서로 의존한다.
Make는 이런 의존성을 처리하는 데 유용하다.
내 일상을 Makefile로 표현해 보자.

dress: trousers shoes jacket
	@echo "All done. Let's go outside!"

jacket: pullover
	@echo "Putting on jacket."

pullover: shirt
	@echo "Putting on pullover."

shirt:
	@echo "Putting on shirt."

trousers: underpants
	@echo "Putting on trousers."

underpants:
	@echo "Putting on underpants."

shoes: socks
	@echo "Putting on shoes."

socks: pullover
	@echo "Putting on socks."

Makefile을 실행하면 다음과 같은 결과가 나온다:

$ make dress
Putting on underpants.
Putting on trousers.
Putting on shirt.
Putting on pullover.
Putting on socks.
Putting on shoes.
Putting on jacket.
All done. Let's go outside!

무슨 일이 일어난 걸까?

단계들이 올바른 순서대로 실행된 걸 눈치챘는가? 단계 간의 의존성을 그저 명확하게 적어두기만 하면, make가 올바른 순서로 실행해 준다.

각 빌드 단계는 다음과 같은 구조를 가진다:

target: [dependencies]
	<shell command to execute>
	<shell command to execute>
	...

• Makefile에서 첫 번째 타깃은 make를 호출했을 때 기본으로 실행된다.

• 타깃의 순서는 중요하지 않다.

• 셸 명령어는 반드시 탭으로 들여써야 한다.

• 실행되는 명령어의 출력을 숨기려면 @ 기호를 붙이면 된다.

• target이 빌드하려는 파일이 아니라면, 빌드 단계 끝에 .PHONY <target>를 추가하자. 흔한 phony 타깃으로는 clean, install, run 등이 있다. 그렇지 않으면 누군가 install이라는 디렉터리를 만들었을 때, 빌드 타깃이 이미 존재한다는 이유로 make가 조용히 실패할 것이다.

  .PHONY: install
  install:
  	npm install

축하한다! make에 대해 알아야 할 것의 90%를 배웠다.

다음 단계

실제 Makefiles는 훨씬 더 많은 일을 할 수 있다! 전체를 다시 빌드하는 대신 변경된 파일만 빌드하고, 가능한 한 많은 작업을 병렬로 처리한다. 다만, 가급적 단순하게 유지하도록 하자.