플랫폼 구조가 복잡하고 무거워 고민이라면
배포 자동화 ‘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 자원 리소스도 상당했으니, 효율화 관점에서 빌드 서버를 새로 구축하는 게 좋은 방법이라 구상했다.
