You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Github Action에서 yaml 파일을 동작할 때 기본적으로 제공하는 ubuntu 모델을 사용하고 있다.
모델의 기본 스펙은 그리 좋지 못하다. 그러므로 어떠한 최적화를 하더라도 하드웨어 스펙상 원하는 속도를 낼 수 없다고 판단했다.
작년 DroidNights에서 github action을 통한 ci/cd 세션을 들었는데 그때 기억으론 엄청난 최적화 기법 없이도 시간 제약이 그리 길지 않았다. 그래서 다시 한번 발표자분의 데모 프로젝트를 방문했고 힌트를 얻었다.
runs-on: self-hosted
자체 호스팅을 통한 워크플로우 작동이라는 키워드를 기반으로 다시한번 구성을 바꿨다.
회사에서 사용하는 클라우드 서비스에 접속해 가이드에 맞춰 Github Token을 등록하고 Github를 연동했다.
클라우드 서비스가 스펙이 로컬 스펙 이상이었기 때문에 훨씬 더 빠른 빌드가 가능했다.
Activity
pachuho commentedon Nov 3, 2025
최적화의 필요성
우선순위가 높은 업무들이 생길 수 있는 상황이라 CICD 구축에 있어서 처음부터 큰 목표를 바라보지 않고 작은 목표를 넓혀가는 방향으로 진행하고 있다. 최초에 적용된 CI 구성을 기준으로 빠른 확장과 안정성 확보가 필요했다.
하지만 빌드 속도는 생각보다 너무 느렸다.
어떠한 최적화 작업이 되지 않은 action은 자동화를 처리하기엔 역부족이며 빌드 시간이 길어질 수록 CICD 파이프 라인에 들이는 시간이 늘어나 수동으로 하느니만 못한 결과를 낼 수 있다고 생각했다.
기존 시간을 최적화하여 빌드 시간 자체를 줄여야 했다.
pachuho commentedon Nov 3, 2025
최적화 과정 1. 캐싱 적용
앱을 빌드하기 위해선 코드를 바이트 코드로 전환하고 .jar로 패키징된다. 그 과정을 처리해줄 컴파일러 사용을 위해 jvm과 gradle이 필요하며 참조하고 있는 라이브러리를 임포트해야한다. 로컬 환경에선 필요한 정보들을 캐싱하며 불필요한 워크플로우 시간을 최소화한다.
Github Action의 경우 신규 job이 요청될 때 마다 아주 깨끗한 인스턴스를 제공한다. 이는 위 캐싱정보가 없다는 것을 의미한다.
그렇기 때문에 매번 빌드에 필요한 파일들을 다운로드받는 과정들이 필요해 시간이 오래 걸린다.
따라서, 캐싱 작업을 처리해 시간을 줄이는 방법을 채택했다.
Gtithub Actions에서 제공하는 Cache Service를 적용했다.
[테스트 결과]
기존: 37m 52s
변경: 8m 52s
기존 대비 75% 가량 시간을 줄일 수 있었다.
하지만 나중에 추가할 배포 워크플로우까지 추가될 것을 고려 한다면 시간을 더 줄일 필요가 있다.
pachuho commentedon Nov 3, 2025
최적화 과정 2. Self-Hosted 및 증분 빌드 적용
Github Action에서 yaml 파일을 동작할 때 기본적으로 제공하는 ubuntu 모델을 사용하고 있다.
모델의 기본 스펙은 그리 좋지 못하다. 그러므로 어떠한 최적화를 하더라도 하드웨어 스펙상 원하는 속도를 낼 수 없다고 판단했다.
작년 DroidNights에서 github action을 통한 ci/cd 세션을 들었는데 그때 기억으론 엄청난 최적화 기법 없이도 시간 제약이 그리 길지 않았다. 그래서 다시 한번 발표자분의 데모 프로젝트를 방문했고 힌트를 얻었다.
runs-on: self-hosted자체 호스팅을 통한 워크플로우 작동이라는 키워드를 기반으로 다시한번 구성을 바꿨다.
회사에서 사용하는 클라우드 서비스에 접속해 가이드에 맞춰 Github Token을 등록하고 Github를 연동했다.
클라우드 서비스가 스펙이 로컬 스펙 이상이었기 때문에 훨씬 더 빠른 빌드가 가능했다.
현재 프로젝트는 멀티 모듈로 구성되어있어 프로젝트의 gradle 옵션을 통해 증분 빌드를 적용해 보다 빠르게 워크플로우가 작동하도록 수정했다.
[테스트 결과]
기존: 8m 52s
변경: 34s
극적인 감소가 일어났고 이제 더욱 빠른 처리가 가능해졌다. 현재는 앞선 목표였던 워크플로우 목록을 처리하고 있어 2분정도의 시간이 걸리지만 테스트하거나 배포하는 데 있어 충분히 빠른 처리가 가능했다.
물론 더 최적화 하는 것도 고려해볼 수 있으나 현재로써는 최적화보다는 파이프라인을 구성하고 다른 주요 비지니스 로직에 집중하는게 우선으로 판단된다.