GitHub Actions vs GitLab CI for backend, web, and mobile

멀티앱 CI에서 사람들이 겪는 어려움

하나의 리포지토리에서 백엔드, 웹 앱, 모바일 앱을 모두 빌드하면 CI는 단순한 "테스트 실행"이 아닙니다. 서로 다른 툴체인, 빌드 시간, 배포 규칙을 조율하는 트래픽 컨트롤러가 됩니다.

가장 흔한 고통은 단순합니다: 작은 변경 하나가 너무 많은 작업을 촉발합니다. 문서 수정만으로 iOS 서명 작업이 시작되거나, 백엔드 변경으로 웹 전체 재빌드가 발생하면 모든 머지가 느리고 불안해집니다.

멀티앱 환경에서는 몇 가지 문제가 초기에 드러납니다:

• 러너 표준화 문제: 머신마다 SDK 버전이 달라 CI와 로컬에서 빌드 결과가 달라집니다.
• 비밀의 확산: API 키, 서명 인증서, 스토어 자격증명이 여러 잡과 환경에 중복됩니다.
• 캐시 혼란: 잘못된 캐시 키는 오래된 빌드를 만들고, 캐시가 없으면 매번 느립니다.
• 섞인 배포 규칙: 백엔드는 자주 배포하고 싶지만 모바일은 추가 검증이 필요합니다.
• 파이프라인 가독성: 설정이 잡들로 가득 차서 아무도 손대기 싫어집니다.

그래서 GitHub Actions와 GitLab CI의 선택은 단일 앱보다 모노레포에서 더 중요합니다. 경로별로 작업을 분리하고, 아티팩트를 안전하게 공유하며, 병렬 잡이 서로 간섭하지 않게 하는 명확한 방법이 필요합니다.

실용적 비교는 네 가지에 달합니다: 러너 설정과 확장성, 비밀 저장과 범위 지정, 캐시와 아티팩트, 그리고 "변경된 것만 빌드"를 얼마나 안전하고 쉽게 표현할 수 있는지입니다.

이것은 일상적인 신뢰성과 유지보수성에 관한 이야기이지, 어떤 플랫폼이 통합 기능이 더 많거나 UI가 더 예쁜지의 문제는 아닙니다. 빌드 도구(Gradle, Xcode, Docker 등)에 관한 결정을 대체하지도 않습니다. 대신 깨끗한 구조를 유지하기 쉬운 CI를 고르는 데 도움을 줍니다.

GitHub Actions와 GitLab CI 구조 비교

가장 큰 차이는 파이프라인 구성과 재사용 방식입니다. 백엔드, 웹, 모바일 빌드가 같은 리포지토리를 공유하면 이것이 중요해집니다.

GitHub Actions는 automation을 .github/workflows/ 아래 YAML 파일로 저장합니다. 푸시, 풀리퀘스트, 스케줄, 수동 실행 같은 이벤트로 워크플로우가 트리거됩니다. GitLab CI는 리포지토리 루트의 .gitlab-ci.yml을 중심으로 동작하며, 포함 파일(include)을 사용할 수 있고 파이프라인은 보통 푸시, 머지리퀘스트, 스케줄, 수동 잡으로 실행됩니다.

GitLab은 스테이지 중심입니다. build, test, deploy 같은 스테이지를 정의하고 잡을 스테이지에 배치해 순서대로 실행합니다. GitHub Actions는 워크플로우에 여러 잡을 두고, 기본적으로 병렬로 실행되며 의존관계가 필요한 경우에만 needs 같은 방법으로 기다리게 합니다.

여러 대상에 동일한 로직을 적용할 때는 GitHub의 매트릭스 빌드가 자연스럽습니다(iOS vs Android, 여러 Node 버전 등). GitLab도 parallel 잡과 변수로 비슷한 확장을 할 수 있지만 직접 연결해야 할 부분이 더 많아지는 경향이 있습니다.

재사용 방식도 다릅니다. GitHub에서는 재사용 가능한 워크플로우와 composite 액션을 많이 사용합니다. GitLab에서는 include, 공유 템플릿, YAML 앵커/extends로 재사용하는 경우가 많습니다.

승인과 보호된 환경도 다르게 동작합니다. GitHub는 보호된 환경(protected environments)에 리뷰어 요구 및 환경 비밀을 두어 프로덕션 배포가 승인될 때까지 멈추게 하는 방식이 흔합니다. GitLab은 보호된 브랜치/태그와 보호된 환경, 수동 잡을 조합해 특정 역할만 배포를 실행하도록 하는 방식이 일반적입니다.

러너 설정과 잡 실행

러너 설정에서 두 플랫폼의 일상적 차이가 느껴집니다. 둘 다 호스티드 러너(머신을 관리하지 않음)와 자체 호스팅 러너(머신, 업데이트, 보안 모두 관리)를 지원합니다. 호스티드 러너는 시작하기 쉽고, 자체 호스팅은 속도, 특수 도구, 사설 네트워크 접근이 필요할 때 선호됩니다.

많은 팀에서 실용적 분리는 다음과 같습니다: 백엔드와 웹은 Linux 러너, iOS 빌드가 필요할 때만 macOS 러너. Android는 Linux에서 돌릴 수 있지만 무거우니 러너 사양과 디스크 공간에 신경 써야 합니다.

호스티드 vs 자체 호스티드: 무엇을 관리할 것인가

호스티드 러너는 유지보수 없이 예측 가능한 환경이 필요할 때 적합합니다. 자체 호스팅은 특정 Java/Xcode 버전, 빠른 캐시, 내부 네트워크 접근이 필요할 때 맞습니다.

자체 호스팅을 선택하면 러너 역할을 초기에 정의하세요. 대부분 리포지토리는 다음과 같은 소수의 러너로 잘 운영됩니다: 일반 Linux 러너(백엔드/웹), Android용 더 강한 Linux 러너, iOS 패키징/서명을 위한 macOS 러너, 권한을 엄격히 제한한 배포 전용 러너.

잡당 적절한 러너 선택

두 시스템 모두 러너를 목표로 지정할 수 있습니다(GitHub에서는 labels, GitLab에서는 tags). linux-docker, android, macos-xcode15처럼 워크로드에 맞게 이름을 붙이세요.

격리성은 많은 불안정한 빌드의 원인입니다. 남은 파일, 손상된 공유 캐시, 혹은 자체 호스팅 머신에 수동으로 설치한 도구는 무작위 실패를 만들 수 있습니다. 깨끗한 작업공간, 고정된 도구 버전, 정기적인 러너 정리가 빠른 효과를 냅니다.

용량과 권한도 반복되는 문제입니다. 특히 macOS 가용성은 비용과 직결됩니다. 기본 규칙은: 빌드 러너는 빌드하고, 배포 러너는 배포하며, 프로덕션 자격증명은 가능한 한 작은 잡 집합에만 둡니다.

비밀과 환경 변수

멀티앱 CI 파이프라인에서 비밀은 가장 위험한 지점입니다. 기본 원칙은 비슷합니다(플랫폼에 비밀 저장, 런타임에 주입)만 범위 지정 방법이 다르게 느껴집니다.

GitHub Actions는 레포지토리와 조직 수준에서 비밀을 지정하고 추가로 Environment 레이어를 둡니다. 이 Environment는 프로덕션에 수동 게이트와 별도의 값 세트가 필요할 때 유용합니다.

GitLab CI는 프로젝트, 그룹, 인스턴스 수준의 CI/CD 변수를 사용합니다. 환경에 따른 변수(scope)와 protected(보호된 브랜치/태그에서만 사용 가능), masked(로그에 숨김) 같은 보호 기능도 제공합니다. 모노레포에서 여러 팀이 함께 사용할 때 이런 제어가 유용합니다.

주요 실패 원인은 우발적 노출입니다: 디버그 출력, 실패한 명령이 변수를 에코하는 경우, 혹은 아티팩트에 설정 파일이 포함되는 경우 등입니다. 로그와 아티팩트는 기본적으로 공유된다고 간주하세요.

백엔드+웹+모바일 파이프라인에서 비밀은 보통 클라우드 자격증명, DB URL, 서드파티 API 키, 서명 재료(iOS 인증서/프로비저닝, Android keystore와 비밀번호), 레지스트리 토큰(npm, Maven, CocoaPods), 자동화 토큰(이메일/SMS 제공자, 챗봇) 등을 포함합니다.

여러 환경(dev, staging, prod)이 있다면 이름을 일관되게 유지하고 환경 범위로 값을 바꾸세요. 복사하는 방식보다 회전 및 접근 제어가 관리하기 쉬워집니다.

몇 가지 규칙은 대부분 사고를 막아줍니다:

• 가능한 경우 OIDC 같은 단기 자격증명을 사용하세요. 장기 키보다 안전합니다.
• 최소 권한 원칙을 적용해 백엔드, 웹, 모바일 각각 배포용 아이덴티티를 분리하세요.
• 비밀은 마스킹하고 환경 변수를 출력하지 마세요, 실패 시에도 출력 금지입니다.
• 프로덕션 비밀은 보호된 브랜치/태그와 승인 뒤로 제한하세요.
• 빌드 아티팩트에 비밀을 절대 저장하지 마세요.

간단하지만 효과적인 예: 모바일 잡은 태그된 릴리스에서만 서명 비밀을 받고, 백엔드 배포 잡은 main으로 머지될 때 제한된 배포 토큰을 사용하도록 합니다. 이렇게만 해도 잘못 구성된 잡의 영향 범위를 크게 줄일 수 있습니다.

빠른 빌드를 위한 캐시와 아티팩트

느린 파이프라인 대부분은 지루한 이유 하나 때문입니다: 같은 것을 계속 내려받고 재빌드합니다. 캐시는 반복 작업을 피하고, 아티팩트는 특정 실행의 정확한 출력을 보존합니다.

무엇을 캐시할지는 빌드 대상에 따라 다릅니다. 백엔드는 의존성 및 컴파일러 캐시(예: Go module cache)가 이득입니다. 웹은 패키지 매니저 캐시와 빌드 툴 캐시가 중요합니다. 모바일은 Linux에서 Gradle과 Android SDK 캐시, macOS에서는 CocoaPods나 Swift Package Manager 캐시가 필요합니다. iOS의 DerivedData 같은 출력 캐시는 트레이드오프를 이해하지 않으면 문제를 일으킬 수 있습니다.

두 플랫폼 모두 기본 패턴은 같습니다: 잡 시작에 캐시를 복원하고, 끝에 업데이트된 캐시를 저장합니다. 일상적 차이는 제어 수준입니다. GitLab은 캐시와 아티팩트 동작을 하나의 파일에서 명시적으로 관리하고 만료(expiration)도 설정할 수 있습니다. GitHub Actions는 별도의 액션을 통한 캐싱을 많이 사용해 유연하지만 잘못 구성하기 쉽습니다.

모노레포에서는 캐시 키가 더 중요합니다. 좋은 키는 입력이 바뀔 때만 바뀌고 그렇지 않을 땐 안정적입니다. Lockfile(go.sum, pnpm-lock.yaml, yarn.lock 등)이 키를 주도하게 하세요. 또한 전체 리포지토 대신 특정 앱 폴더 해시를 포함하고, 앱별로 캐시를 분리해 한 변경이 모두 무효화하지 않게 하세요.

아티팩트는 특정 실행의 결과물(릴리스 번들, APK/IPA, 테스트 리포트, 커버리지 파일, 빌드 메타데이터 등)을 보관할 때 사용하세요. 캐시는 속도를 위한 것이고, 아티팩트는 기록입니다.

그래도 느리다면 큰 캐시, 매 실행마다 바뀌는 키(타임스탬프나 커밋 SHA), 러너 간 재사용이 불가능한 캐시된 빌드 출력 등을 점검하세요.

모노레포 적합성: 혼돈 없이 여러 파이프라인 관리하기

모노레포는 모든 푸시가 백엔드 테스트, 웹 빌드, 모바일 서명을 트리거할 때 엉망이 됩니다. 깔끔한 패턴은 무엇이 변경되었는지 감지해 필요한 잡만 실행하는 것입니다.

GitHub Actions에서는 보통 앱별로 워크플로우를 나누고 path 필터를 사용해 해당 영역이 변경될 때만 워크플로우가 실행되게 합니다. GitLab CI에서는 하나의 파이프라인 파일에서 rules:changes나 child pipeline을 사용해 경로에 따라 잡 그룹을 만들거나 건너뜁니다.

공유 패키지는 신뢰가 깨지기 쉬운 부분입니다. packages/auth가 변경되면 해당 폴더가 직접 변경되지 않았더라도 백엔드와 웹이 둘 다 재빌드가 필요할 수 있습니다. 공유 경로는 여러 파이프라인의 트리거로 명시적으로 다루고 의존 경계를 명확히 하세요.

간단한 트리거 맵 예시는 다음과 같습니다:

• 백엔드 잡: backend/** 또는 packages/** 변경 시 실행
• 웹 잡: web/** 또는 packages/** 변경 시 실행
• 모바일 잡: mobile/** 또는 packages/** 변경 시 실행
• 문서 변경: 포맷/맞춤법 검사 같은 빠른 체크만 실행

병렬로 안전한 작업(유닛 테스트, 린팅, 웹 빌드)은 병렬화하고, 통제가 필요한 작업(배포, 앱스토어 릴리스)은 직렬화하세요. GitLab의 needs나 GitHub의 job dependency를 사용하면 빠른 초기 검사를 먼저 실행해 실패 시 나머지를 중단할 수 있습니다.

모바일 서명은 일상 CI에서 분리하세요. 서명 키를 전용 환경에 두고 수동 승인을 요구하며 태그된 릴리스에서만 서명 실행하도록 하세요. 일반 PR은 서명되지 않은 앱을 빌드해 검증만 하되 높은 권한을 노출하지 않도록 합니다.

단계별: 백엔드, 웹, 모바일을 위한 깔끔한 파이프라인

읽기 쉽게 의도를 알 수 있는 네이밍으로 시작하세요. 한 패턴을 선택해 일관되게 쓰면 로그를 보고 무엇이 실행됐는지 빠르게 알 수 있습니다.

읽기 쉬운 한 가지 방식:

• 파이프라인: pr-checks, main-build, release
• 환경: dev, staging, prod
• 아티팩트: backend-api, web-bundle, mobile-debug, mobile-release

그다음에 잡을 작게 유지하고, 이전 검사에 통과한 것만 승격시키세요:

1. PR 체크(모든 풀리퀘스트): 변경된 앱만 빠른 테스트와 린트를 실행합니다. 백엔드의 경우 배포 가능한 아티팩트(컨테이너 이미지나 서버 번들)를 빌드해 나중 단계에서 재빌드하지 않도록 저장하세요.

2. 웹 빌드(PR + main): 웹 앱을 정적 번들로 빌드합니다. PR에서는 아티팩트를 보관하거나 프리뷰 환경에 배포합니다. main에서는 dev나 staging에 적합한 버전화된 번들을 생성합니다.

3. 모바일 디버그 빌드(PR 전용): 디버그 APK/IPA를 빌드합니다. 릴리스 서명은 하지 않습니다. 목표는 빠른 피드백과 테스터가 설치할 수 있는 파일을 제공하는 것입니다.

4. 릴리스 빌드(태그 전용): v1.4.0 같은 태그가 푸시되면 전체 백엔드/웹 빌드와 서명된 모바일 릴리스 빌드를 실행합니다. 스토어에 올릴 준비가 된 출력물을 만들고 릴리스 노트와 함께 아티팩트를 보관하세요.

5. 수동 승인: staging에서 prod로 넘어갈 때 승인을 두세요. 기본 테스트 이전에 승인을 두지 마세요. 개발자는 빌드를 트리거할 수 있지만 프로덕션 배포와 프로덕션 비밀 접근은 승인된 역할만 하게 합니다.

시간을 낭비하게 하는 흔한 실수들

팀은 흔한 워크플로우 습관 때문에 몇 주를 낭비하곤 합니다.

공유 러너에 너무 의존하는 것이 한 함정입니다. 많은 프로젝트가 같은 풀을 경쟁하면 랜덤 타임아웃, 느린 잡, 피크 타임의 모바일 빌드 실패가 생깁니다. 백엔드, 웹, 모바일 빌드가 중요하다면 무거운 잡은 전용 러너(또는 최소한 별도 큐)에 격리하고 자원 제한을 명시하세요.

비밀도 시간 낭비의 또 다른 원인입니다. 모바일 서명 키와 인증서는 다루기 쉽지 않습니다. 흔한 실수는 너무 광범위하게 저장해 모든 브랜치와 잡에서 접근 가능하게 하거나, 자세한 로그로 노출시키는 것입니다. 서명 재료는 보호된 브랜치/태그로 제한하고 비밀 값을 출력하는 단계는 피하세요(심지어 base64 문자열도 포함).

캐시는 큰 디렉터리를 캐시하거나 캐시와 아티팩트를 섞어 쓰면 역효과가 날 수 있습니다. 안정적인 입력만 캐시하고, 나중에 필요할 출력은 아티팩트로 보관하세요.

마지막으로 모노레포에서 모든 변경에 모든 파이프라인을 트리거하면 시간이 낭비됩니다. 누군가 README를 수정했는데 iOS, Android, 백엔드, 웹을 모두 재빌드하면 사람들은 CI를 신뢰하지 않게 됩니다.

도움이 되는 빠른 체크리스트:

• 경로 기반 규칙을 사용해 영향을 받는 앱만 실행하세요.
• 테스트 잡과 배포 잡을 분리하세요.
• 서명 키는 릴리스 워크플로우로 제한하세요.
• 안정적인 입력만 캐시하고 전체 빌드 폴더를 캐시하지 마세요.
• 무거운 모바일 빌드를 위한 예측 가능한 러너 용량을 계획하세요.

한 플랫폼을 선택하기 전 빠른 점검 목록

선택하기 전에 실제 작업 방식에 맞는 몇 가지를 점검하세요. 이렇게 하면 한 앱에는 괜찮아 보이던 도구가 모바일 빌드, 여러 환경, 릴리스가 생기면 고통스러워지는 일을 피할 수 있습니다.

중점적으로 확인할 것들:

• 러너 계획: 호스티드, 자체 호스티드, 혹은 혼합인가. 모바일 빌드는 보통 macOS 때문에 혼합을 요구합니다.
• 비밀 계획: 비밀이 어디에 있고 누가 읽을 수 있으며 교체 방식은 어떠한가. 프로덕션은 스테이징보다 더 엄격해야 합니다.
• 캐시 계획: 무엇을 캐시하고 저장 위치는 어디이며 키는 어떻게 구성되는가. 키가 매 커밋마다 바뀌면 비용만 지불하고 속도 향상은 없습니다.
• 모노레포 계획: 경로 필터와 공통 단계(lint, tests)를 중복 없이 공유하는 방법.
• 릴리스 계획: 태그, 승인, 환경 분리. 누가 프로덕션으로 승격할 수 있고 어떤 증거가 필요한지 명확히 하세요.

작은 시나리오로 압력 테스트해 보세요. Go 백엔드, Vue 웹, 두 개의 모바일 앱이 있는 모노레포에서: 문서 전용 변경은 거의 아무 것도 하지 않아야 하고, 백엔드 변경은 백엔드 테스트와 API 아티팩트 빌드만 하며, 모바일 UI 변경은 Android와 iOS만 빌드해야 합니다.

그 흐름을 한 페이지로 설명할 수 없다면(트리거, 캐시, 비밀, 승인), 같은 리포지토리로 양쪽 플랫폼에서 일주일짜리 파일럿을 돌려 보세요. 지루하고 예측 가능한 쪽을 선택하세요.

예시: 현실적인 모노레포 빌드 및 릴리스 플로우

하나의 리포에 세 폴더가 있다고 가정해 보세요: backend/(Go), web/(Vue), mobile/(iOS와 Android).

일상에서는 빠른 피드백이 필요하고, 릴리스에서는 전체 빌드·서명·배포가 필요합니다.

실용적 분리는 다음과 같습니다:

• 기능 브랜치: 변경된 부분에 대해 린트 + 유닛 테스트 실행, 백엔드와 웹 빌드, 선택적으로 Android 디버그 빌드. iOS는 정말 필요할 때만 실행.
• 릴리스 태그: 모든 것을 실행하고 버전화된 아티팩트를 만들고 모바일 앱을 서명해 릴리스 저장소에 업로드합니다.

모바일이 포함되면 러너 선택이 중요해집니다. Go와 Vue는 거의 어디서나 Linux에서 잘 동작합니다. iOS는 macOS 러너가 필요하므로 이 한 가지 요구가 결정 요인이 되는 경우가 많습니다. 빌드 머신을 완전히 제어하고 싶다면 GitLab CI와 자체 호스팅 러너가 관리하기 더 쉽습니다. 운영 작업을 줄이고 빠르게 세팅하려면 GitHub 호스티드 러너가 편리하지만 macOS 사용 시간과 가용성을 고려해야 합니다.

캐시는 실제로 시간을 절약하지만 앱별로 최적의 캐시는 다릅니다. Go는 모듈 다운로드와 빌드 캐시를, Vue는 패키지 매니저 저장소를 캐시하고 lockfile이 바뀔 때만 재빌드하세요. 모바일은 Linux에서 Gradle과 Android SDK를, macOS에서는 CocoaPods나 Swift Package Manager를 캐시하세요. 모바일 캐시는 크고 무효화가 자주 일어날 수 있음을 예상하세요.

유지되는 규칙: 코드가 이미 한 플랫폼에 호스팅되어 있다면 그곳에서 시작하세요. 러너(특히 macOS), 권한, 규정 준수 때문에 옮겨야 할 경우에만 전환을 고려하세요.

다음 단계: 선택하고 표준화하고 안전하게 자동화하세요

코드와 팀이 이미 있는 도구를 선택하세요. 대부분의 경우 차이는 일상의 마찰에서 드러납니다: 리뷰, 권한, 고장난 빌드를 누가 얼마나 빨리 진단하는지 등입니다.

간단하게 시작하세요: 앱별로 하나의 파이프라인(백엔드, 웹, 모바일). 안정화되면 공통 단계를 재사용 가능한 템플릿으로 빼 중복을 줄이되 소유권은 흐려지지 않게 하세요.

비밀 범위를 열쇠 관리하듯 문서화하세요. 프로덕션 비밀은 모든 브랜치에서 읽을 수 없어야 합니다. 회전 주기를 설정하세요(분기별이 빈번하지 않은 것보다 낫습니다) 그리고 긴급 차단 절차를 합의하세요.

만약 코드 생성(no-code generator)을 사용해 실제 소스 코드를 생성한다면 생성/내보내기를 CI의 1등 시민 단계로 다루세요. 예를 들어 AppMaster (appmaster.io)는 Go 백엔드, Vue3 웹, Kotlin/SwiftUI 모바일 코드를 생성하므로 변경 시 코드를 재생성하고 그 후 실제로 변경된 대상만 빌드하면 됩니다.

팀이 신뢰하는 흐름이 만들어지면 새 레포에 기본으로 적용하고 단순함을 유지하세요: 명확한 트리거, 예측 가능한 러너, 엄격한 비밀, 의도한 경우에만 실행되는 릴리스.