✨생산성을 높이기 위해서 처음부터 모든 것을 만드는 대신 컴포넌트 방식으로 프로그램을 개발한다. 

과거에는 빌드를 할 때 로컬에 모든 의존성 라이브러리 등이 환경으로 설치돼 있어야 했습니다. 라이브러리 설치가 안 되어 있으면 소스 코드를 가져와서 직접 컴파일하는 방식이 전부였습니다. 하지만 이제 컴포넌트화 되고 OS 청원 시스템 라이브러리가 아닌 나만의 라이브러리로만 작업하기가 굉장히 까다롭다는 이야기입니다.

조엘 온 소프트웨어 문항 중에 ‘한 단계로 빌드할 수 있습니까?’, ‘일일 빌드를 진행하고 있습니까?’ 여기에 어떤 의미가 숨어 있냐면요. 바로  ‘소스 코드를 컴파일해서 뭘 하겠다’라는 암묵적인 가정이 숨어있는 겁니다. 그런데 요즘 Node.js라거나 파이썬으로 애플리케이션을 작성한다고 생각하면, 위의 문항처럼 단순히 잘 되지 않거든요.

그래서 ‘빌드라는 게 뭘 의미하는지’ 근본적으로 생각할 필요가 있습니다. 

요즘의 빌드는 의존성 자체의 버저닝(versioning)이라든지 호환성을 관리하는 데 시간을 많이 소비합니다. 물론 이런 상황에서도 형상 관리 시스템의 중요도는 떨어지지 않습니다. 즉, 과거에는 두 가지가 한 축으로 동시에 움직였다면 지금은 이 두 가지 축으로 각각 움직이고 있다는 의미입니다. 이제 현대 환경에서는 ‘이 두 가지를 어떻게 효율적으로 관리하느냐’가 중요한 사안입니다. 

✨그 다음 테스트입니다.

CI/CD 파이프라인을 만들어서 적용할 때도 ‘의존성을 어떤 식으로 잘 해결해주느냐’가 관건인데요. 우리가 컨테이너 환경을 말할 때 암묵적인 가정이 있습니다. 흔히 ‘도커로 만다’라는 표현을 쓰는데요. 의존성, 그리고 유틸리티와 같은 프로그램 패키지 단위 자체를 크게 잡을 수 있다는 겁니다. 이 부분이 과거에 비해서 현대 여러분이 직면하는 가장 큰 변화가 아닐까 싶습니다.

물론 옛날 방식으로 프로그램 짜는 분들도 아직 계시고, 어쩔 수 없이 아직 C언어를 사용하거나 아니면 외부 애플리케이션이나 라이브러리, 프레임워크를 최소로 사용하면서 작업을 해야 하는 그런 레거시 상황도 있다는 것도 제가 잘 알고 있습니다. 하지만 점점 더 이 부분이 현대적인 방식으로 바뀐다는 것에는 변함의 여지가 말씀을 드립니다. 

이제 제가 단위테스트를 강조하고 있는 이유를 말씀 드릴게요. 
단위(Unit) 테스트가 End to End(E2E) 테스트보다 점점 더 중요해지기 시작했습니다.