컴파일,빌드,배포의 개념과 자동화

코드와 컴파일러 등 여러 도구를 이용하여 무엇인가를 만들어내는(build) 것의 결과물은 동작하는 소프트웨어가 된다. 

컴파일->빌드->배포 순서인데, 컴파일을 포함한 배포 직전까지의 모든 과정을 '빌드 한다'라고 표현하기도 한다.

코드 작성 후에 컴파일부터 배포하기까지의 모든 과정을 빌드한다고 표현하는 경우도 있는데 회사나 팀마다 다르다.

 

1. 컴파일 : 사용자가 작성한 코드를 컴퓨터가 이해할 수 있는 언어로 번역하는 일 

2. 빌드 : 컴파일된 코드를 실제 실행할 수 있는 상태로 만드는 일

3. 배포 : 빌드가 완성된 실행 가능한 파일을 사용자가 접근할 수 있는 환경에 배치시키는 일 

4. 혹은 컴파일을 포함해 war, jar 등의 실행 가능한 파일을 뽑아내기까지의 과정을 빌드한다고도 한다

 

 

예를 들어 이클립스나 인텔리제이같은 IDE에서 java로 코딩을 할 때, 

코드를 짠 후 Run을 통해 코드를 실행시킨다 (컴파일+실행) 

정상적으로 실행되면 이것을 war파일로 뽑아서(빌드) 웹서버에 올리거나(배포) 

JSmooth등을 사용해 exe, jar파일로 뽑아(빌드) 사용자에게 주면 된다(배포) 

 

웹이 아닌 exe 파일로 배포하는 경우엔 보통 'deploy'보다 'distribution'한다고 표현한다.

둘다 같은 배포의 영역이지만 deploy는 일반적으로 웹개발 영역에서 사용되는 용어.

 

 

Run을 돌리면 컴파일과 실행이 동시에 발생하기 때문에 일반적으로 IDE를 사용하는 경우엔 컴파일 과정을 인식하기 어렵다. 코드를 작성하고 Run을 누르는 순간 컴파일이 자동으로 실행되지만 터미널이나 CMD에서 실행할 때는 개발자가 직접 컴파일을 해주어야 한다.

 

// HelloWorld.java

public class HelloWorld{
    public static void main(String[] args){
        System.out.println("Hello, World!");
    }
}

위의 코드를 터미널에서 실행할 때 바로 실행하면 다음과 같은 에러가 발생한다.

$ java HelloWorld.java
오류: 기본 클래스 HelloWorld.java을(를) 찾거나 로드할 수 없습니다.

아직 내가 작성한 코드가 컴퓨터 언어로 번역(컴파일)되지 않았기 때문에 컴퓨터가 코드를 이해할 수 없기 때문이다.

$ javac HelloWorld.java
$ ls
HelloWorld.class    HelloWorld.java

javac 명령어를 사용하여 파일을 컴파일해주면 컴파일된 .class 파일이 생긴다. 

$ java HelloWorld
Hello, World!

뒤의 확장자명을 제외하고 클래스 이름만으로 java 명령어를 실행하면 잘 실행된다.

만약 누군가 이 파일을 사용하기 위해 특정 디렉토리에 위치시켜달라고 요청을 했고, 내가 그 위치에 파일을 가져다 놓으면 HelloWorld라는 프로그램을 배포한 셈이 되는 것이다. war파일이나 exe파일은 아니지만, 실행 가능한 파일을 최종 사용자가 가용한 위치에 옮겨둔다는 개념에서 보면 그렇게 볼 수도 있다는 것. (이미 올라가있는 프로그램에 이 파일이 추가로 필요하다면 컴파일된 .class 파일을 지정된 프로그램의 위치에 접근하여 배치해주는 것도 크게 보면 배포의 개념)  

 

실제 서비스를 운영하다보면, 코드를 수정한 이후 다시 컴파일하고 실행가능한 파일로 추출해서 배포하는 과정을 여러번 반복해야 한다. 이 작업을 실수없이 효율적으로 하기 위해 '빌드 자동화', '배포 자동화'라는 개념이 등장했다. 

 

완성된 코드를 서버에 올린다고 개발이 끝나는 것이 아니기 때문에 개선사항이 필요할 때마다 코드 수정을 해줘야 한다.

그때마다 수정된 코드를 git에 커밋하고 통합된 코드를 다시 컴파일하고 빌드하고 배포하는 과정이 반복되어야 한다. 코드가 제대로 동작하는지 테스트 코드를 작성하고, 이를 수행 및 검증하는 작업도 필요할 것이다. 이러한 과정들을 매번 개발자가 직접 수행하는 것은 비효율적이고 이 과정을 수작업으로 진행하면서 실수를 유발하기 쉽다. 

 

 

그래서 자동화가 필요하다. 개발자는 git에 수정된 코드를 올리기만 하고 컴파일, 테스트, 빌드, 배포 등의 과정은 정해진 절차에 따라 특정 프로그램이 자동으로 수행하는 것이다. git에 코드를 올리는 행위 자체가 트리거가 되어 나머지 과정을 자동으로 수행한다고 생각하면 된다. 그리고 모든 과정이 끝나면 그 결과를 개발자에게 리포트해준다. 

 

자동화와 직접적으로 관련있는 내용은 아니지만 CI/CD하면 꼭 자동화가 따라오고 프로젝트의 크기가 커질수록 자동화가 배제된 CI/CD는 상상하기 어려워진다. 

 

CI는 지속적 통합(Continuous Integration)으로, 모든 개발이 끝난 이후에 코드 품질을 관리하는 고전적 방식의 단점을 해소하기 위해 나타난 개념이다. 말 그대로 개발하면서 '코드에 대한 통합'을 '지속적'으로 진행함으로써 품질을 유지하는 것이다. 이럴 때 git에 코드만  올려놓으면 알아서 테스트와 빌드를 수행하고 그 결과를 잘 정리해서 개발자에게 자동으로 알려주는 프로그램이 있다면 편리할 것이다. 그렇기 때문에 CI를 설명할 때는 항상 자동화라는 키워드가 따라다닌다. 

 

CD는 지속적 배포(Continuous Deploy 또는 Delivery)로써, 소프트웨어가 항상 신뢰 가능한 수준에서 배포될 수 있도록 지속적으로 관리하자는 개념이다. CI의 연장선으로 생각하면 된다. 배포 이전에 테스트와 빌드는 필수적이기 때문에 사실상 CD가 되려면 항상 CI가 선행되어야 한다고 봐도 무방하다. 

 

즉, CI 프로세스를 통해 개발 중에 지속적으로 빌드와 테스트를 진행하고, 이를 통과한 코드에 대하여 테스트서버와 운영서버에 곧바로 그 내용을 배포해 반영하는 것이다. 이상적인 환경이라면 테스트와 빌드가 '지속적'으로 이루어지기 때문에, 배포 또한 자연스럽게 '지속적'으로 이루어지게 된다. 

 

사실상,

CI = 빌드 및 테스트 자동화

CD = 배포 자동화

라고 기억해도 무방하다.

 

코드 품질관리에 있어서 CI/CD 자동화가 왜 필요하며 이러한 시스템을 구축하는 것이 왜 중요한지에 대해 이해해야 한다. CI/CD를 자동화하기 위해서 고려해야할 부분이 많으며 언제, 어떤 자동화 프로세스를 어떻게 돌리고 어떤 방식으로 결과를 리포트할지 등의 절차를 엄밀하게 진행해야 한다. CircleCI, Travis, Jenkins와 같이 CI/CD를 상대적으로 쉽게 구현할 수 있도록 도와주는 솔루션들도 있으니 참고해보면 좋을 것이다. 

 

 

References https://itholic.github.io/qa-compile-build-deploy/

https://itholic.github.io/qa-build-automation/

https://itholic.github.io/qa-cicd/