빌드 시스템을 사용해야 하는 이유

문제 신고 소스 보기

이 페이지에서는 빌드 시스템이 무엇인지, 빌드 시스템은 왜 사용해야 하는지, 그리고 조직 확장이 시작됨에 따라 컴파일러와 빌드 스크립트가 최선의 선택이 되지 않는 이유를 설명합니다. 이 문서는 빌드 시스템에 관한 경험이 많지 않은 개발자를 대상으로 합니다.

빌드 시스템이란 무엇인가요?

기본적으로 모든 빌드 시스템은 목적이 있습니다. 즉, 엔지니어가 작성한 소스 코드를 머신에서 읽을 수 있는 실행 가능한 바이너리로 변환합니다. 빌드 시스템은 사람이 작성한 코드만 사용할 수 있는 것이 아닙니다. 또한 빌드나 테스트를 위해 프로덕션 환경에서 머신이 자동으로 빌드하도록 허용합니다. 엔지니어가 수천 명인 조직에서는 대부분의 빌드가 엔지니어에 의해 직접이 아니라 자동으로 트리거되는 것이 일반적입니다.

컴파일러만 사용하면 안 되나요?

빌드 시스템의 필요성은 명확하지 않을 수 있습니다. 대부분의 엔지니어는 코딩을 배우는 동안 빌드 시스템을 사용하지 않습니다. 대부분 명령줄에서 gcc 또는 javac와 같은 도구를 직접 호출하거나 통합 개발 환경 (IDE)에서 이에 상응하는 도구를 호출하는 것으로 시작합니다. 모든 소스 코드가 같은 디렉터리에 있으면 다음과 같은 명령어가 잘 작동합니다.

javac *.java

이렇게 하면 자바 컴파일러가 현재 디렉터리의 모든 자바 소스 파일을 바이너리 클래스 파일로 변환하도록 지시합니다. 가장 간단한 경우에는 이것만 있으면 됩니다.

그러나 코드가 확장되면 정보 표시가 시작됩니다. javac은 가져올 현재 코드를 찾기 위해 현재 디렉터리의 하위 디렉터리를 살펴보는 것이 현명합니다. 그러나 파일 시스템의 다른 부분 (여러 프로젝트에서 공유하는 라이브러리)에 저장된 코드를 찾을 수는 없습니다. 또한 자바 코드를 빌드하는 방법만 알고 있습니다. 대규모 시스템에는 여러 프로그래밍 언어로 작성된 서로 다른 부분이 포함되는 경우가 많으며, 그 사이에 종속 항목 웹을 사용하므로 단일 언어의 컴파일러가 전체 시스템을 빌드할 수는 없습니다.

여러 언어 또는 컴파일 단위의 코드를 처리하는 경우 더 이상 코드 빌드에 한 단계가 필요하지 않습니다. 이제 코드가 사용하는 항목을 평가하고 각 요소마다 다른 도구 세트를 사용하여 적절한 순서로 이러한 부분을 빌드해야 합니다. 종속 항목이 변경되면 비활성 바이너리에 종속되지 않도록 이 프로세스를 반복해야 합니다. 적당한 크기의 코드베이스의 경우 이 프로세스는 지루하고 오류가 발생하기 쉽습니다.

컴파일러는 자바의 서드 파티 JAR 파일과 같이 외부 종속 항목을 처리하는 방법도 모릅니다. 빌드 시스템이 없다면 인터넷에서 종속 항목을 다운로드하고 하드 드라이브의 lib 폴더에 고정한 후 해당 디렉터리에서 라이브러리를 읽도록 컴파일러를 구성하여 이를 관리할 수 있습니다. 시간이 지남에 따라 이러한 외부 종속 항목의 업데이트, 버전, 소스를 유지하기 어렵습니다.

셸 스크립트는 어떤가요?

취미 프로젝트가 컴파일러만으로 빌드할 수 있을 만큼 간단하지만, 앞에서 설명한 몇 가지 문제가 발생하기 시작했다고 가정해 보겠습니다. 빌드 시스템이 여전히 필요하지 않다고 생각할 수 있으며 올바른 순서로 빌드를 처리하는 간단한 셸 스크립트를 사용하여 지루한 작업을 자동화할 수 있습니다. 한동안 도움이 되었지만 곧 더 많은 문제가 발생합니다.

  • 지루해지죠. 시스템이 더 복잡해짐에 따라 빌드 코드 작업에 실제만큼 많은 시간을 할애하게 됩니다. 셸 스크립트 디버깅은 점점 더 많은 해킹이 겹쳐지면서 골치 아픈 문제입니다.

  • 속도가 느립니다. 실수로 오래된 라이브러리에 종속되지 않도록 실행할 때마다 빌드 스크립트가 모든 종속 항목을 순서대로 빌드하도록 합니다. 어떤 부분을 다시 빌드해야 하는지 감지하기 위해 로직을 추가하려고 하는데, 이는 스크립트에 매우 복잡하고 오류가 발생하기 쉽습니다. 또는 매번 다시 빌드해야 할 부분을 지정하는 방법을 고민하고 있는데, 정사각형으로 돌아갑니다.

  • 반가운 소식입니다. 발표할 시간입니다. jar 명령어에 전달하여 최종 빌드를 만드는 데 필요한 모든 인수를 파악하는 것이 좋습니다. 그리고 업로드 방법을 중앙 저장소에 푸시하는 방법을 잊지 마세요. 문서 업데이트를 빌드 및 푸시하고 사용자에게 알림을 보낼 수도 있습니다. 음, 다른 스크립트를 호출해야 할 수도 있습니다.

  • 재해 하드 드라이브가 다운되어 이제 전체 시스템을 다시 만들어야 합니다. 모든 소스 파일을 버전 제어에 유지할 수 있을 정도로 지능적이었습니다. 하지만 다운로드한 라이브러리는 어떨까요? 모두 다시 찾아 처음 다운로드했을 때와 동일한 버전인지 확인할 수 있나요? 스크립트는 특정 위치에 설치된 특정 도구에 종속되었을 수 있습니다. 스크립트가 다시 작동하도록 동일한 환경을 복원할 수 있나요? 컴파일러가 올바르게 작동하도록 하기 위해 오래 전에 설정했던 모든 환경 변수는 어떨까요?

  • 이러한 문제에도 불구하고 프로젝트는 성공적으로 진행되어 더 많은 엔지니어를 고용할 수 있습니다. 이전 문제가 발생하기까지 재해가 발생하지 않는다는 것을 깨달았습니다. 새 개발자가 팀에 가입할 때마다 동일한 부트스트랩 프로세스를 거쳐야 합니다. 최선의 노력에도 불구하고 각 사용자의 시스템에는 약간의 차이가 있습니다. 한 사람의 시스템에서 작동하는 것이 다른 사람의 기기에서는 효과가 없는 경우가 많으며, 디버깅 도구 경로나 라이브러리 버전을 사용하여 차이가 있는 위치를 파악하는 데 몇 시간씩 걸릴 때마다

  • 빌드 시스템을 자동화해야 한다고 결정합니다. 이론적으로는 새 컴퓨터를 만들고 매일 밤 크론을 사용하여 빌드 스크립트를 실행하도록 설정하기만 하면 됩니다. 어려운 설정 절차를 거쳐야 하지만 지금은 인간의 뇌가 경미한 문제를 감지하고 해결할 수 있는 이점이 없습니다. 이제 아침에 들어서면 어젯밤에 사용자 시스템에서 작동했지만 자동 빌드 시스템에서는 작동하지 않은 변경사항이 있기 때문에 어젯밤에 빌드가 실패한 것을 확인할 수 있습니다. 간단한 해결 방법이지만, 이렇게 자주 발생하는 경우가 많기 때문에 매일 간단한 수정 내용을 찾아 적용하는 데 많은 시간을 할애하게 됩니다.

  • 프로젝트가 커질수록 빌드는 느려집니다. 언젠가는 빌드가 완료되기를 기다리는 동안 휴가 중인 동료의 유휴 데스크톱을 애타게 바라보고 낭비된 모든 컴퓨팅 성능을 활용할 방법이 있었기를 바랍니다.

규모의 확장 문제가 발생했습니다. 최대 1주일에서 2주(최대 1~2주) 동안 코드 20줄로 작업하는 단일 개발자(대학을 졸업한 후기 초보 개발자가 경험하는 전체 경험)에는 컴파일러만 있으면 됩니다. 스크립트를 사용하면 시간이 조금 더 걸릴 수 있습니다. 그러나 여러 개발자와 해당 머신 간에 조정이 필요한 경우 완벽한 빌드 스크립트만으로는 충분하지 않습니다. 이러한 머신의 사소한 차이를 설명하기가 매우 어려워지기 때문입니다. 이 시점에서는 이 간단한 접근 방식을 세분화하여 실제 빌드 시스템에 투자해야 합니다.