개발 소스코드 관리; 1. 형상관리, CI/CD (Continuous Integration, Continuous Delivery)

개발 소스코드 관리

1. 형상관리, CI/CD

2. Git을 설치하고 덤으로 얻는 리눅스 환경

3. GitHub 사용하기 - 1) 계정생성, Token 발행

4. GitHub 사용하기 - 2) VSCode 연결, 해제

5. 예제로 본 Git 사용법 (기본 명령어) - 1

 

인터넷이나 책에서 형상관리나 CI/CD가 무엇인지에 읽어보면 설명은 잘 되어 있지만 잘 와닿지 않는 경우가 많다. 그래서 그동안 내가 경험하고 느낀 것을 짧게 공유하고, 현재 내가 하고 작은 프로젝트를 관리할 수 있는 간단한 CI/CD를 만든 과정을 설명하겠다.

1. 내 생활에서 찾아본 형상관리, CI/CD

아직 체계적인 회사에서 일하고 있지 않는 개발자이거나 이제 프로그램을 배우기 시작한 학생이라면 한 번쯤은 새로운 기능을 자신 있게 추가했는데 동작하지 않아 고치다가 예전 프로그램으로 돌려본 기억이 있을 것이다. 어떨 때에는 귀찮아서 백업본을 남기지 않았다가 기억을 더듬으면서 다시 만든 기억도 있을 것이다. 나만 그랬을 리가 없다. ^^ 만약 그때 개발한 소스코드를 쉽게 저장하면서 버전을 달아서 구분하고 새로운 기능을 추가하기 위해 작업공간을 만들었다가 성공했을 때에만 기존 소스코드에 합쳐주는 기능이 있었으면 일이 훨씬 편해졌을 것이다. 이런 작업을 형상관리라고 한다.

 

나이가 들어 내가 회사의 서비스를 오픈하고 새로운 기능을 추가하는 입장이 되니 한쪽에서 프로그램을 조금만 수정해도 동작하지 않는 가능성이 생기고, 그러다 보니 서로 날짜를 잡아 협의하고, 서로 검증하고, 프로그램을 바꾸는 계획을 잡는 일련의 작업이 너무 느리게만 느껴졌었다. 그러다 CI/CD (Continuous Integration / Continuous Delivery)라는 방식을 적용하니 서비스에 새로운 기능을 넣는 기간이 짧아져서 원하는 기능은 빠르게 넣고 필요 없는 기능을 빨리 제거해서 사용자 편의성이 좋아지는 것을 느낄 수 있었다. 물론 CI/CD가 잘 동작하기 위해서는 팀원 개발자들 뿐 아니라 관리자도 개발주기에 대한 생각을 많이 바꿔야 한다. 그렇지 않으면 한쪽이 번아웃 되거나 이전보다 더 개발기간이 늘어나는 문제가 발생한다.

2. CI/CD가 어려운 이유

우리나라는 서방 선진국들에 비해 일 처리하는 속도가 매우 빠르다. 실리콘 밸리는 앱 하나 개발하는 데에도 많은 돈을 들인다. 우리가 잘 아는 링키드인이나 페이스북이나 모두 수천 명, 수만 명의 개발자가 하나의 앱을 개발하기 위해 매일 일을 하고 있다. 우리는 어떨까? 대기업 프로젝트도 전사 ERP 수준의 프로젝트를 하지 않는 한 백 명 이상의 개발자가 모일 일도 없도 개발 기간도 10개월을 넘기지 않는 것이 대부분이다. 정말 적은 돈으로 빨리 잘 만든다.

 

마이크로소프트는 1주 개발하면 3주를 테스트, 디버깅, 코드리뷰, 형상관리, 품질관리 등 우리나라 개발자들에게는 개발기간에 해야 할 당연한 일이라고 생각되는 일에 더 많은 시간을 할애하고 있다. 개발자들에게는 정말 부러운 업무환경이지만 짧은 기간에 실적을 내야 할 관리자들에게는 돈 많은 회사의 사치로 보일 수밖에 없다.  

 

나는 모두의 생각이 바뀌지 않으면 성공적으로 CI/CD가 회사에 녹아들어서 서비스 개선, 결국에는 매출 증대로 이어지는 과정을 볼 수 없을 것이라 생각한다. 결국은 개발자는 CI/CD를 위해 테스트 케이스를 소스코드가 변경될 때마다 성실히 만들고 수정하는 것을 당연히 해야 할 서비스 개발과정의 일부로 여겨야 하고, 관리자는 이를 위한 시간을 당연한 것으로 인정하고 개발 예산에 반영하지 않으면 CI/CD가 성공할 수 없다.

 

그런데, 해마다 프로젝트 예산을 만들어 집행해야 한다면 비용효율을 먼저 생각할 수밖에 없다. 또, 내가 개발하는 프로그램을 나중에 문제가 생겼을 때 내가 고치지 않아도 되고, 개선을 내가 하지 않아도 된다면 테스트 케이스를 열심히 만들까? 나는 SI (System Integration) 전문 기업에 개발을 프로젝트 단위로 발주하는 동안에는 성공하기 쉽지 않은 개념이라고 생각한다. 물론 방법은 있겠지만...

3. 내가 사용하는 간단한 CI/CD

나는 CI/CD환경을 구축하기 위해 Git, GitHub과 Jenkins를 주로 사용한다. 당연히 이것만으로는 부족하고 프로그램을 개발할 때 어떤 테스트 프레임워크를 사용할 것인지 TDD를 할 것인지 어떤 기준으로 할 것인지도 중요하다. 나는 아두이노 프로젝트나 프론트엔드 프로젝트나 백엔드 프로젝트에 모두 적용할 수 있는 범용적인 환경을 만들어 보기로 하고 다음과 같은 아키텍처로 만들기로 했다.

내 개인용 CI/CD 아키텍쳐

• Git

나는 형상관리를 위해 git을 이용한다. 예전에는 CVS (Concurrent Version System)도 사용했고 SVN (Subversion) 도 형상관리에 사용했다. SVN으로 넘어올 때에는 문제가 생기면 저장된 소스코드를 에디터로 열어 볼 수 있는 CVS가 그리웠고, git으로 넘어올 때에는 SVN의 단순한 명령어가 그리웠다. 하지만 내 컴퓨터에서 변경된 내용만을 서버에 빠르게 저장할 수 있고, 서버가 없어도 일단 내 컴퓨터에 먼저 저장하고 관리할 수 있는 편리한 분산환경, 팀별 또는 상황별로 branch를 사용해서 작업공간을 분리하는 기능에 익숙해지면 svn도 cvs도 너무 불편해서 돌아갈 수 없는 환경이 되어 버린다.

 

• GitHub

모든 프로그램을 내 컴퓨터에 있는 git repository에만 저장하면, 외부에 나갔다가 급하게 작업해야 할 일이 생겼을 때, 컴퓨터 하드디스크가 갑자기 고장 났을 때 난감한 상황이 생긴다. 또 CI/CD를 위해 Jenkins를 설치하려 해도 내 컴퓨터에 같이 설치해서 작업이 돌 때 그 부하를 그대로 느끼거나, Jenkins를 외부에 설치하면 내 컴퓨터를 ssh로 외부에 활짝 열어줘야 하는 상황이 발생한다. GitHub을 사용하면 이런 문제를 해결하고 안전하게 외부에 저장할 수 있다.

 

GitHub도 예전에는 매우 제한적으로만 무료로 사용할 수 있었다. 잘 기억은 안 나지만 무료는 프로젝트 수도 제한이 되어 있고 public으로 만들어 공개할 수도 없었다. 하지만 마이크로소프트가 인수하고 나서 2년이 지난 2020년부터는 저장공간 500M, 월 데이터 전송 1G까지는 private든 public이든 무료로 사용할 수 있게 되었다. 이 정도면 스타트업에서 비용을 지불하고 사용해야 할 정도는 아니다.

 

• Jenkins

Jenkins눈 2011년에 만들어진 오래된 오픈소스 CI/CD프로그램이다. Java로 만들어져 있고, 이쁜 화면을 좋아하는 우리들 눈에는 상당히 구린 프로그램처럼 보인다. 하지만 아직도 CI/CD에서는 강자이다. Git의 사용이 늘어나면서 실리콘밸리에는 한동안 CI/CD는 Gitlab으로 하는 것이 당연시되기도 했지만 외부 서비스를 사용하기보다는 내 환경에 설치하고 유지보수하는 우리나라 환경에서는 Jenkins보다는 Gitlab은 매우 무겁고 비싼 환경이다. 그래서 나는 Jenkins를 좋아한다. 무료인데 내가 원하는 기능은 대부분 plugin에서 찾을 수 있다. 가볍게 노트북에 설치해서 동작시킬 수도 있고 복잡한 프로젝트는 여러 대에 Agent를 분산할 수도 있다.

 

이제 Git부터 하나씩 설치하면서 사용하려 한다.