들어가며 

지난 1993년에 개봉했던 사랑의 블랙홀이라는 영화를 기억하시나요? 남자 주인공이 2월 2일 성촉절(Groundhog Day, 미국에서 마멋이 겨울잠에서 깨어난다고 여기는 날) 하루를 끊임없이 반복해서 살게 되면서, 사랑을 얻기 위해 매일매일 좀 더 완벽한 사람으로 변해가는 로맨틱 코미디 영화입니다. 빌 머레이(Bill Murray)가 연기한 극 중 필 코너스(Phil Connors)의 목표는 자기 자신을 개선하고 자신의 목표를 달성하는 방법을 단계별로 배우는 것이었습니다. 완벽한 하루를 살기 위한 필의 노력은 많은 변화를 만들어 냈고, 결국 목표에 도달하게 됩니다. 이 영화의 이야기는 지속적인 개선의 좋은 예입니다. 주인공 필은 매일매일을 반복하면서 지난 실수들을 지속적으로 고쳐 나가며 더 완벽한 하루를 만들어 나갔습니다. 마찬가지로 지속적인 개선은 현재 맡고 있는 일을 향상시키기 위해 일상의 노력을 반복적으로 수행하면서 개선해 나가는 것입니다. 

저는 올해 6월에 LINE에 입사해 LINE 메신저 클라이언트와 관련된 CI(Continuous Integration)/CD(Continuous Delivery) 업무를 지속적으로 개선하고 자동화하는 DevOps 역할을 수행하고 있습니다. 이번 글에서는 지속적인 CI/CD 개선을 위해 데이터를 시각화하고 활용해 나간 경험을 공유하려고 합니다.

CI/CD의 목표

현재 수행하고 있는 업무의 목표는 개발된 소스 코드를 사용자의 모바일 장비에 설치할 수 있도록 Google Play Store에 배포하는 것입니다. 조금 더 자세히 이야기하자면, 개발자가 신규 기능이나 변경 내용에 대해 소스 코드(개발 브랜치)를 수정하고 버전 관리 시스템(GitHub Enterprise)에 소스 코드를 기록하는 것(Git 커밋)부터 업무가 시작됩니다. 그 이후 소스 코드를 다른 사람이 개발한 소스 코드에 합치기 전에 잘 작동하는지, 그리고 규칙에 맞게 개발되었는지 PR(Pull Request)을 보내 자동으로 확인합니다. 그다음으로 기술 블로그에 자주 소개되었던 동료 개발자들의 코드 리뷰가 진행되고, 코드 리뷰가 완료되면 동일한 검증 과정을 거친 동료들의 결과물이 모인 소스 코드로 통합하는 작업(PR 머지)이 수행됩니다. 이제 개발자의 소스 코드는 실제 배포될 수 있는 코드에 포함되었습니다. 배포 가능한 소스 코드(릴리스 브랜치)를 주기적으로 빌드해서 테스트 가능한 알파, 베타 버전으로 만듭니다. 그러면 테스터가 모바일 장치에 설치해 실제로 잘 동작하는지 여러 테스트를 수행합니다. 만약 버그나 오류가 발견되면 수정하는 과정을 거쳐 드디어 Google Play Store에 배포합니다. 배포할 땐 일부 사용자에게 먼저 배포해서 이상이 없는지 모니터링한 뒤 전체 사용자에게 배포하는 점진적인 방식을 사용합니다. 

이런 작업은 수많은 사람들이 밀접하게 연계되어 있으며, 매끄럽고 원활하게 동작시키려면 많은 노력이 필요합니다. 만약 이 과정을 한 개인이 수동으로 진행한다면 많은 문제가 발생할 수 있습니다. 그래서 작업 시간을 줄이고 불편함을 최소화하기 위해 관련된 업무 프로세스를 도출하여 자동화하는 업무를 수행합니다. 이런 업무와 프로세스는 서비스가 발전하면서 발생하는 변화를 끊임없이 따라가며 지속적으로 개선해 나가는 것이 제일 중요합니다.

CI/CD 개선 전략 

CI/CD 업무 자동화라는 것은 여러 사람 간에 일이 처리되는 방식을 이해한 뒤 무언가 필요하거나 개선 가능한 지점을 찾아내 프로세스로 정의하고, 스크립트나 시스템을 이용해 반복 처리할 수 있도록 만드는 것입니다. 그런데 연관된 사람들은 각자 가지고 있는 역할을 바쁘게 수행하고 있기 때문에 그 사람들의 일하는 방식을 이해하고, 필요로 하는 것을 찾기란 결코 쉽지 않은 일입니다. 그래서 다음과 같은 2가지 전략을 기반으로 요구 사항을 수집했습니다. 

첫 번째는 주변 사람들, 즉 개발자들의 이야기에 귀를 기울이는 것입니다. 개발자가 그들의 관점에서 무심코 이야기하는 것 속에서 많은 피드백을 얻을 수 있습니다. 개발 문서, 회의록, 채팅방, 그리고 자리에 모여서 나누는 이야기 등 다양한 곳에서 들려오는 작은 목소리에도 호기심을 갖고 귀를 기울이는 것이 중요합니다. 

두 번째는 CI/CD 작업에서 생산되는 데이터를 여러 사람들이 업무에 활용할 수 있도록 보여주는 것입니다. 이 데이터를 통해 개발자들은 현재 상태를 정량적으로 파악하여 미래를 예측해 볼 수 있습니다. 그렇게 되면 개발자도 자동화 업무에서 진행되는 개선 작업에 더 관심을 갖게 될 것이고, 이를 통해 자동화 업무를 수행하는 저와 의사소통할 수 있는 통로가 만들어집니다. 

이번 글에서는 두 번째 전략인 데이터 시각화에 대해 설명하겠습니다.

CI/CD 데이터 시각화

CI/CD에서 생성되는 데이터의 종류

어떤 것을 보여줄지 정하기 위해서는 먼저 무엇을 보여줄 수 있는지 알아야 합니다. 지금 이 순간에도 LINE Android 클라이언트 소스 코드를 모바일에 배포하기 위한 수많은 작업이 실행되고 있는데요. 이런 CI/CD 작업에서는 어떤 데이터들이 생성될까요? 

• 소스 코드 정보
  • 신규로 추가한 라인 수, 변경된 라인 수, 소스 코드 파일 개수, 커밋 개수 등
• 소스 코드 정적 분석 데이터 
• 소스 코드 빌드 데이터 
  • 작업별 빌드/테스트 시간
  • 빌드 성공/실패율, 빌드 로그
  • 빌드 테스트 리포트, 패키지(APK) 정보, 버전 정보 
  • 빌드 옵션, 메모리 덤프 데이터
  • 빌드 태스크 의존성 정보
• 빌드 시스템 정보
  • 사용자 시스템 정보(CPU, 메모리)
  • CPU 사용량, 메모리 사용량, 디스크 사용량
  • 빌드 대기 시간, 빌드 장비 활용 시간

이 외에도 많은 데이터가 다양한 시스템에서 여러 형태로 관리되고 있습니다. 김춘수 시인의 '꽃'에 나오는 '그의 이름을 불러 주기 전에는 그는 다만 하나의 몸짓에 지나지 않았다'라는 구절처럼, 아직 목적이 부여되지 않은 데이터들이 CI/CD 시스템에 많이 쌓여 있는 상황이었습니다. 

데이터 시각화 목표 설정

무엇을 보여줄 수 있는지 파악했으니 이제 보여주고 싶거나 해결해야 할 문제가 무엇인지 목표를 정의해야 합니다. 목표를 설정하는 방법은 두 가지가 있는데요. 하나는 스스로 업무의 개선점을 파악해 데이터와 연관해서 해결 가능한 문제를 정의하는 것이고, 다른 하나는 외부에서 피드백을 받아 문제를 정의하는 것입니다. 

전자의 경우 이미 수립한 업무 목표를 정량적으로 파악하는 데 도움이 됩니다. 예를 들어, 개발자가 코드를 올리면 자동으로 수행되는 코드 검증 시간을 줄이는 것(Pull Request 리드 타임 개선)과 실제 배포 대상 코드가 배포되는 시간을 줄이는 것(릴리스 리드 타임 개선)과 관련하여 지표를 수립하여 빌드 관련 리소스와 스크립트 개선 작업 결과를 숫자로 확인할 수 있습니다.

후자의 사례로, 최근에 개발 과정에서 배포되는 패키지 크기가 갑작스럽게 커지는 문제가 발생했었습니다. 다행히 배포하기 전에 해결할 수 있었지만, 문제를 빨리 탐지할 수 있는 체계를 마련할 필요가 생겼습니다.

데이터 시각화의 첫 번째 목표는 후자의 사례에서 도출된, 배포 패키지 데이터를 수집하면서 갑작스럽게 크기가 증가할 경우 알림이 발생하는 것으로 잡았습니다. 

데이터 시각화 방법 결정

어떻게 데이터를 모아서 보여줄까? 어떻게 시작할까? 초기에 이런 고민을 많이 했습니다. 기존에 이미 데이터를 보여주는 대시보드가 있었지만 관리되지 않고 방치되어 유지 보수하기 어려운 상태였습니다. 그래서 이참에 관리하기 편하면서 사용자에게 빠르게 데이터를 보여줄 수 있는 시스템을 새로 만들기로 결정했고, 다음과 같은 기준을 두고 시스템을 찾아보았습니다. 

• 빠르게 구축할 수 있고 문제가 발생했을 때 참고할 만한 레퍼런스가 많은가?
• 데이터를 유연하게 수집할 수 있는가?
• 설정을 손쉽게 변경할 수 있는가?
• 알림 기능이 있는가?
• 다양한 차트를 사용할 수 있고 관련 생태계가 구축되어 있는가?
• 시스템을 처음 접하는 동료와도 손쉽게 시작할 수 있는가? 

위와 같은 기준에 비추어 사내에서 많이 사용하면서 다양한 영역에 걸쳐 많은 레퍼런스를 보유한 데이터 수집, 저장, 조회용 오픈소스인 ELK Stack과 시각화를 위한 오픈소스인 Grafana를 활용하기로 했습니다. ELK를 선택한 이유는 다양한 장비에서 서로 상이한 데이터들을 수집할 수 있는 기능을 가지고 있었고, Grafana는 ELK뿐만 아니라 다양한 데이터베이스나 데이터 저장소에 연결해 차트를 그릴 수 있는 기능을 제공하고 있어서 선택했습니다.

그리고 한 가지 더, 사내 인프라 서비스인 Verda에서 ELK 관리형 서비스를 제공하고 있어서 간단하게 신청해서 안정적인 시스템을 확보할 수 있었고, Grafana와 같은 연관 시스템은 Docker를 이용해 빨리 확보할 수 있었습니다.

시각화할 데이터 수집

필요한 데이터를 정의하고 Jenkins를 이용해서 배포할 패키지를 만듭니다.

• OS 플랫폼
• 빌드 번호
• 빌드 Job URL
• 패키지명
• 버전 정보
• 패키지 크기 정보

여기서 중요한 것은 꼭 필요한 정보 이외의 다른 데이터를 추가하면 안 된다는 것입니다. 다양한 데이터를 살펴보다 보면, 정보를 조금 더 추가해서 다른 곳에 동일한 데이터 세트를 활용하고 싶은 욕심이 생길 수 있습니다. 하지만 그 욕심을 버리고 처음 설정해 놓은 목표만 바라보고 가야 합니다. 앞으로 꾸준히 이 데이터를 개선해 나갈 것이기 때문에 데이터를 합치거나 변환하는 것은 나중에 해도 됩니다. 

데이터를 정의한 뒤 Jenkins에서 패키지를 만드는 작업이 종료되는 시점에 정의한 데이터를 ELK에 전달할 수 있도록 스크립트 설정을 추가합니다. 설정에 관한 상세한 설명은 EKL 튜토리얼을 참고하시기 바랍니다. 

데이터 시각화 수행 결과

ELK에 저장된 데이터를 Grafana에 연결하면 시계열 그래프로 변환할 수 있습니다. 기존 차트와 비교해 보면 많은 점이 개선되었습니다.

현재 저희는 내부적으로 여러 개발 단계(phase)를 정의하여 이에 맞춰 개발을 진행하고 있는데요. 기존 차트에서는 아래와 같이 그래프에 모든 단계가 섞여 나왔기 때문에 단순하게 추이만 확인할 수 있었습니다.

이를 개선하여 그래프를 개발 단계별로 나눠서 전체적인 추이를 살펴보며 큰 변경이 발생했는지 쉽게 확인할 수 있게 만들었습니다.

또한 새로운 그래프에선 사용자에게 실제로 배포되는 패키지의 크기를 버전별로 추적할 수 있도록 만들었고, 크기가 갑자기 증가했을 때 알림을 보내는 기능을 추가해 사전에 이를 인지할 수 있게 만들었습니다.

세계 각국에 사용자가 퍼져있는 LINE 메신저에서 패키지 크기의 증가는 매우 민감한 사항입니다. 통신 속도가 느린 환경의 사용자나 저사양의 모바일 기기를 이용하는 사용자는 용량이 큰 패키지를 꺼리기 때문입니다. 위 지표를 활용하면 갑작스러운 크기 변경에 대응할 수 있고, 내부적으로 진행되는 작업에 정량적인 데이터를 활용할 수 있습니다. 

향후 전망

이번 글에서는 지속적인 개선 여정의 시작 단계를 소개했습니다. 저 수준(raw)의 데이터를 사람들이 쉽게 해석할 수 있는 형태로 바꾸어 제공하면, 변화를 만들 수 있는 피드백과 통찰력을 얻을 수 있습니다. 일단 통계 정보를 활용하여 트렌드를 파악하는 수준으로 시작했는데요. 앞으로 수학 모델을 적용해 분석을 자동화하여 지능화된 서비스로 만들어 나가고 싶습니다. 다음엔 이렇게 작은 시작이 CI/CD를 어떻게 변화시켜 나가고 있는지 소개하겠습니다. 긴 글 읽어주셔서 감사합니다.