플랫폼 구조가 복잡하고 무거워 고민이라면
배포 자동화 ‘CI/CD’ 적용이 먼저!
수시로 시스템을 연동하고 유지 보수하는 IT실 개발자에게 ‘배포’는 일상이다. 보통은 빌드 과정이 간단하기 때문에 반복되는 업무라 하더라도 자동화의 필요성을 크게 느끼지 못했다. 그러나 보안 시스템을 강화하면서 데일리펀딩 간편투자앱에 AppGuard를 적용한 데다 기존 코드 푸시 업데이트를 EAS 업데이트로 바꾸게 돼 배포 과정에도 큰 변화가 생겼다. 구조가 복잡해지고 앱이 무거워져 CI/CD의 필요성을 절실하게 느낀 것이다. (CI/CD는 ‘지속적인 통합/지속적인 배포’를 뜻하는 개념으로, 개발된 새 코드를 실제 적용하기까지의 단계를 자동화하는 것을 말한다.)
처음에는 Shell에서 명령어를 통해 간단하게 CI/CD를 구축했는데, 큰 효과를 얻지 못했다. 여전히 로컬(개인 PC)에서 빌드하기 때문에, 여러 일과 병행해서 진행할 때 기존에 실행하던 것을 중단하고 다른 프로세스를 가동하는 ‘컨텍스트 스위칭(Context Switching)’이 빈번했다. 또 개발 환경에 영향받지 않았으면 하는 니즈도 있었다.
가뜩이나 장기 프로젝트로 개발 환경을 마이그레이션 중이니, 작은 이슈도 다음으로 미뤄서는 안 된다고 생각했다. 이왕이면 리소스를 줄인다는 측면에서만 접근하지 않고 작업자의 능률도 고려하는 방식으로 CI/CD를 재구현하고 싶었다. 컨텍스트 스위칭 없이 새 코드를 따로 분리해 자동으로 업로드하는 방법이 없을까 고민하다 이참에 빌드 서버를 새로 꾸리는 게 좋겠다는 생각이 들었다. 혹시 빌드 서버가 변경되는 등의 여러 변수가 발생할 수 있으니, 그 관리 도구로 GitHub Actions을 도입하기로 했다. 이는 웹과 앱 모두를 고려한 CI/CD 작업의 출발점이었다. 개인적인 니즈에서 출발한 이 배포 자동화 작업이 모두의 개발 환경을 개선하는 프로젝트라는 데 확신도 섰다.
작업 속도, 자원 절약 모두 챙기는 CI/CD는?
‘새 빌드 서버 구축’이 그 답
데일리펀딩 IT실의 장기 프로젝트 ‘마이그레이션’이 CI/CD 작업에 많은 영향을 줬다. 시스템을 Next.js 프레임워크로 이관할 때 CD를 접목했는데, 이 과정에서 CI/CD 워크플로우를 오케스트레이션 및 자동화하는 GitHub Actions과 GitHub Actions의 편의 기능인 Self-Hosted Runner를 활용했다. 순서상으로는 앱 CI/CD를 먼저 기획했으나 웹 먼저 개발하고 나중에 앱에 적용했다.
가장 기초 작업은 GitHub Actions이 돌아가는 환경을 구축하는 것이다. 그래서 빌드와 운영에 필요한 서버 모두 Self-Hosted Runner를 설정해 GitHub Actions이 동작하도록 했다. 기존에는 프로덕션 서버에서 빌드를 해서 작업 속도가 너무 느리고, CPU 자원 리소스도 상당했으니, 효율화 관점에서 빌드 서버를 새로 구축하는 게 좋은 방법이라 구상했다.
그러나 데일리펀딩이 기존에 쓰던 클라우드 서버 자원을 활용해 빌드 서버를 구축하긴 어려웠다. 앱 생태계에서 iOS는 자신의 환경이 아니면 빌드가 불가능하기 때문이다. 즉, Mac이 돌아가는 OS에서만 빌드가 가능한데, 문제는 일반 리눅스 서버보다 비용이 약 10배나 더 든다는 것이다. 비용 절감 또한 효율화의 연장선이라고 생각했기 때문에 IT실에서 쓰지 않아 남는 맥북으로 사용자 정의 빌드 환경인 Self-Hosted Runner를 구성하기로 했다. 그렇게 빌드 서버에 Self-Hosted Runner를 설정했다.
앱 CI/CD도 새 빌드 서버 맞춤형으로,
꼼꼼히 챙겨야 개발자 니즈 채우니까
앱 CI/CD는 웹보다 훨씬 코드도 많고 기존에 하지 않았던 작업도 꽤 많이 들어갔다. Self-Hosted Runner를 설정하고 워크플로우에서 yml 파일을 정의하는 건 동일하지만, 플레이스토어와 앱스토어에 각각 배포해야 하니 말이다. OTA(Over-the-Air) 방식과 Store 업데이트 2가지로 진행하는데, 패키지 버전 구분이 먼저다.
OTA 방식은 플랫폼을 가리지 않아 iOS, AOS 모두 하나의 방법으로 배포하는 반면, Store 업데이트는 iOS와 Android가 별도의 빌드로 구분돼 있기 때문에 배포하는 방식이 완전히 다르다. 명령어로 배포 방식을 구분하기에는 관리의 리소스가 커져서 스토어 업로드를 각각 도와주는 오픈소스 라이브러리인 fastlane을 사용했다.
iOS는 빌드 단계에서 ‘이 앱이 개발자로부터 배포됐다’라는 인증/서명이 반드시 필요하다. 기존에는 개발자 계정으로 자동 서명을 진행했으나, 빌드 서버를 새로 구축했기 때문에 인증서를 별도로 보관해야 했다. 그래서 안전한 공간에 인증서를 암호화해서 저장하고 fastlane에서 제공하는 기능인 Match로 인증할 수 있도록 조치했다. 그다음에는 앱스토어에 접근할 수 있는 키를 발급 받아 배포까지 진행되도록 시스템을 구축했다. (AOS는 Match를 요구하지 않으므로 자유롭게 빌드하고, 업로드할 때만 키를 통해 플레이스토어에 배포하면 된다.)
이러한 CI/CD 작업을 거쳐 얼마 전, 웹은 첫 배포도 진행했다. 이후 앱은 OTA 방식 먼저 적용했고, 최근 Store 방식도 성공적으로 진행했다. 이번에 오랜 염원이었던 CI/CD를 구현하긴 했으나, 우선 CI는 휴먼 리스크를 줄일 수 있는 유효성 검증 부분만 구현했다는 아쉬움도 존재한다. 앞으로 CI는 더 발전할 여지가 남아 있으니, ‘개발자를 위한 개발자가 되고 싶다’는 목표에 차근차근 걸어가려고 한다.
완성한 코드를 프로덕션에 적용하는 ‘빌드-테스트-배포’ 과정 사이사이마다 얼마간 대기해야 하고 자잘하게 무언가를 처리해야 했던 개발자, 배포 과정에서 작업을 이어 가기 너무 불편했던 개발자라면, CI/CD를 적극 추천한다.