이영준 개발자의 CI/CD 첫걸음

『지속적 통합배포 구축은 처음이라』는 ‘[Beyond the book] 『자바 프로젝트 필수 유틸리티』 편’ 참여자의 글을 모아 한 권의 책으로 엮은 무료 전자책입니다.

[Beyond the book]은 책, 그다음 이야기를 전하는 독자참여 프로젝트입니다. 책을 읽고 현업에 적용한 이야기, 책에 소개된 내용 이외의 더 나은 대안은 없는지 등 다양한 주제의 독자 여러분의 기고를 기다리고 있습니다.  



이영준
웹 서비스 개발 및 운영 8년차 개발자다. 사람, 그리고 사람을 이어주는 플랫폼에 관심이 많다. 단편적인 기술보다 전체적인 흐름을 볼 수 있는 개발자가 되고자 오늘도 노력하고 있다.



● 어떤 분야를 개발하고 있나요?

이메일, 문자, 알림톡, 푸시 등 다양한 메시징 채널에서 대량 발송을 할 수 있는 플랫폼을 개발합니다. 현재는 플랫폼에서 수집된 빅데이터를 활용한 분석 시스템을 주로 개발하고 있습니다.


● 개발팀 규모가 궁금해요

제가 소속된 개발팀은 4~6명 사이의 인원으로 구성되어 있습니다. 사내 전체 개발자 수는 50~60명 규모입니다.


● 기존 개발환경은 어떤 구성인가요?

  • 빌드 : 개발자 로컬PC에서 프로젝트별로 메이븐이나 그레이들을 사용합니다.
  • 단위 테스트 : 필요한 경우 로컬에서만 테스트 케이스를 만들어 사용합니다.
  • 배포 : 개발자가 로컬에서 빌드한 결과물을 FTP를 통해 업로드합니다.
  • 지속적인 통합 : 지속적인 통합 프로세스 구성은 되어 있지 않습니다.


● 지속적 통합/배포 환경을 구축하려는 이유는 무엇인가요?

  • 개발과 운영 버전의 충돌

    SVN으로 소스 코드 관리를 하고 있었지만, 특정 시점의 스냅샷만 태그로 남겨두는 정도로 형상 관리를 했습니다. 웹 서비스는 운영 중인 프로덕션 버전에 여러 기능이 지속적으로 통합되어 질 수 밖에 없는데, 단일 브랜치로만 관리를 하다보니 테스트나 통합에 어려움이 많았습니다.

    운영에 반영할 때도 아직 반영되어서는 안 되는, 개발 중인 다른 기능 때문에 적절한 시점에 기능들이 반영되지 못할 때도 있었습니다. SVN은 아무래도 Git보다 브랜치 관리나 전환이 느리고 편하지 못한 부분이 있었고, 이후 여러 툴과의 통합을 고려하여 GIT을 도입하기로 하였습니다.

  • 수작업 배포의 리스크

    빌드는 운영 반영 시점에 팀원 중 한 명이 로컬에서 진행하였습니다. 빌드된 결과물을 서버에 반영할 때도, 해당 서버에 직접 FTP로 접속 후 업로드를 하고 커맨드를 입력하여 프로세스를 재시작하였습니다. 운영 중인 웹 어플리케이션이 적은 수도 아니었는데 이러한 작업을 모두 수작업으로 진행하고 있었습니다. 이러한 환경에서 오랜 시간 일을 해온 팀원들에게는 시간이 좀 걸릴 뿐 오류의 위험은 없다라고 생각 될 수 있지만, 언젠가 한번은 오류를 겪을 수 밖에 없고 새로 합류할 팀원에게도 큰 장애물이 될 수 밖에 없습니다. 그래서 지속적인 통합/배포를 통해 개발 외적인 시간 사용을 줄이고 잠재적인 오류를 막으며 로직에 집중할 수 있는 환경을 만들고자 하였습니다.


● 새로 구축한 개발환경을 소개해 주세요


  • 소스 코드 관리는 Git으로

    여전히 Git을 낯설어하는 개발자는 많지만, 지속적인 통합/배포 과정에서 Git은 필수 옵션이 되어가고 있습니다. 개발자 개개인이 로컬 브랜치 전략을 유연하게 가져갈 수도 있고, 통합/배포 시에 개발과 운영 버전을 효율적으로 관리하기에도 편리합니다. 브랜치 전략은 팀원끼리의 합의가 많이 필요한 부분입니다. 좀 더 생산적인 결과를 내기 위해서는 스스로 오랜 습관에서 벗어나려는 노력을 하고 제품을 위한 선택을 할 수 있어야 합니다. 사내 Git 서버 용도로 Gitlab을 설치하였고, 기존 프로젝트들을 하나씩 옮겨가고 있습니다.

  • 젠킨스 서버 구축

    빌드 작업을 수행할 젠킨스 서버를 구축하였습니다. 『자바 프로젝트 필수 유틸리티』 책에서 특히 도움을 많이 받은 부분입니다. 개별 작업들을 파이프라인으로 만들어서 처리하는 부분은 앞으로 여러 용도로 활용할 수 있을 것 같습니다. 젠킨스는 또한 수많은 플러그인들을 제공하고 있어서 상황에 맞는 적절한 플러그인을 잘 고를 수 있어야 합니다.

  • 지속적인 통합 구성

    실제 개발 환경에 적용하기에 앞서, 우선 기존 작업들을 자동화하는데 중점을 두었습니다. Git의 특정 브랜치에 변경 작업이 일어나면 젠킨스에서 감지하여 자동으로 테스트 및 빌드를 진행하게 했습니다. 『자바 프로젝트 필수 유틸리티』에서는 소나큐브를 사용하여 코드 검사도 하던데 이 부분도 추후 적용해 보려고 합니다.

  • ChatOps

    ChatOps는 이슈 관리 툴인 Jira 세미나에서 알게 된 개념입니다. 지속적인 통합/배포 과정에서 좀 더 편리하고 즉각적인 알림을 줄 수 있도록 업무 메신저를 활용하는 것인데, 현재 팀에서 사용 중인 잔디 메신저에도 웹훅 기능이 있습니다. 젠킨스에서 빌드가 완료되면 결과를 잔디 채팅방에서 바로 확인할 수 있도록 하였습니다.


    해외 메신저 슬랙은 젠킨스 플러그인이 제공되어 바로 웹훅을 전달할 수 있지만, 잔디는 플러그인이 없으므로 Zapier 같은 자동화 툴 사이트를 사용하여 웹훅을 전달하도록 해야 합니다. 향후 배포나 모니터링 상황에서도 웹훅을 통한 알림은 매우 유용할 것으로 생각됩니다.


● CI/CD를 도입 후 어떤 점이 달라졌나요?

개발한 소스를 커밋한 이후에 배포까지의 과정을 개발자가 더 이상 수작업으로 하지 않아도 된다는 것은 개발 생산성 향상에 큰 도움이 되었습니다. 사소한 작업으로 여겨질 수 있지만 자동화로 인해 심리적 안정감을 더해 주고, 이는 운영 안정성 향상으로 이어질 수 있다고 생각합니다.

아직 배포까지는 완벽히 환경이 구축되지 않았지만, 도커와 같은 컨테이너 기술을 통해 효율적인 인프라 관리와 무중단 배포도 가능한 환경으로 만들어 보려고 합니다.