C 코드를 GitLab CI로 자동 빌드하고 테스트하는 방법

GitLab CI/CD를 활용하여 C 코드의 자동 빌드 및 테스트 환경을 구축하면, 개발 프로세스의 효율성을 극대화할 수 있습니다. 수동 빌드와 테스트 과정은 시간이 많이 걸리고, 실수로 인해 오류가 발생할 가능성이 높습니다. 반면, CI/CD(Continuous Integration / Continuous Deployment)를 활용하면 코드 변경이 발생할 때마다 자동으로 빌드하고 테스트하여 문제를 사전에 감지할 수 있습니다.

GitLab은 자체적으로 강력한 CI/CD 기능을 제공하며, 이를 활용하면 C 프로젝트의 품질을 지속적으로 관리할 수 있습니다. 본 기사에서는 GitLab CI/CD를 사용하여 C 코드의 자동 빌드 및 테스트를 설정하는 방법을 단계별로 설명합니다. .gitlab-ci.yml 파일 작성부터, 빌드 및 테스트 수행, 실행 결과 확인, 최적화 방법까지 구체적인 실습을 통해 알아보겠습니다.

GitLab CI/CD 개요
1. CI/CD의 핵심 개념
2. GitLab CI/CD의 장점
GitLab CI/CD 설정을 위한 사전 준비
`.gitlab-ci.yml` 파일 작성 기본
C 코드 빌드 단계 구성
자동화된 테스트 작성
빌드 및 테스트 결과 확인
캐싱 및 병렬 실행 최적화
보안 및 환경 변수 관리
요약

GitLab CI/CD 개요

GitLab CI/CD(Continuous Integration / Continuous Deployment)는 소프트웨어 개발의 자동화를 지원하는 강력한 도구입니다. 이를 활용하면 코드 변경이 발생할 때마다 자동으로 빌드, 테스트, 배포를 수행하여 개발 프로세스를 효율적으로 관리할 수 있습니다.

CI/CD의 핵심 개념

Continuous Integration (CI, 지속적 통합)

개발자가 새로운 코드를 커밋할 때마다 자동으로 빌드 및 테스트를 수행하여 코드의 안정성을 유지합니다.

Continuous Deployment (CD, 지속적 배포)

테스트를 통과한 코드가 자동으로 배포되어 운영 환경에 적용됩니다.

GitLab Runner

GitLab에서 CI/CD 파이프라인을 실행하는 프로세스로, GitLab 서버와 연결되어 코드를 빌드하고 테스트합니다.

GitLab CI/CD의 장점

자동화된 빌드 및 테스트: 수작업을 줄이고, 코드 품질을 보장할 수 있습니다.
빠른 피드백 제공: 코드 변경 시 즉시 문제를 감지하여 빠르게 수정할 수 있습니다.
일관된 개발 환경 유지: 동일한 설정으로 모든 개발자가 동일한 결과를 얻을 수 있습니다.

GitLab CI/CD는 .gitlab-ci.yml 파일을 기반으로 동작하며, 이를 설정하면 프로젝트에 맞는 자동화된 워크플로우를 구성할 수 있습니다. 다음 섹션에서는 GitLab CI/CD를 설정하기 위한 사전 준비 과정에 대해 살펴보겠습니다.

GitLab CI/CD 설정을 위한 사전 준비

GitLab CI/CD를 활용하여 C 코드의 자동 빌드 및 테스트를 수행하려면 몇 가지 사전 설정이 필요합니다. 여기에서는 GitLab 프로젝트에서 CI/CD를 활성화하고, GitLab Runner를 설정하는 방법을 설명합니다.

1. GitLab 프로젝트 생성 및 CI/CD 활성화

GitLab CI/CD를 사용하려면 먼저 GitLab에서 프로젝트를 생성해야 합니다.

GitLab 로그인 후 새 프로젝트 생성

GitLab에 로그인한 후 “New project”를 클릭합니다.
기존 코드를 가져오거나 새 저장소를 생성합니다.

CI/CD 설정 확인

프로젝트 설정(Settings)에서 CI/CD 항목을 찾아 활성화되어 있는지 확인합니다.
Runner가 연결되었는지 확인하려면 Settings > CI/CD > Runners에서 확인할 수 있습니다.

2. GitLab Runner 설치 및 등록

GitLab Runner는 CI/CD 파이프라인을 실행하는 프로세스입니다. 자체 서버에서 실행하거나, GitLab의 공용 Runner를 사용할 수 있습니다.

GitLab Runner 설치 방법 (Ubuntu 기준)

sudo apt update
sudo apt install gitlab-runner

GitLab Runner 등록

sudo gitlab-runner register

GitLab 인스턴스 URL 입력 (예: https://gitlab.com/)
Runner 등록 토큰 입력 (GitLab 프로젝트의 CI/CD 설정에서 확인 가능)
Executor 타입 선택 (shell, docker 등)

3. 프로젝트에서 `.gitlab-ci.yml` 파일 추가

GitLab CI/CD는 .gitlab-ci.yml 파일을 기반으로 동작하므로 프로젝트의 루트 디렉토리에 해당 파일을 추가해야 합니다.

기본적인 .gitlab-ci.yml 예제:

stages:
  - build
  - test

build:
  stage: build
  script:
    - gcc -o my_program main.c

test:
  stage: test
  script:
    - ./my_program

이제 GitLab CI/CD 환경을 설정할 준비가 완료되었습니다. 다음 섹션에서는 .gitlab-ci.yml 파일의 구조와 설정 방법을 자세히 살펴보겠습니다.

`.gitlab-ci.yml` 파일 작성 기본

GitLab CI/CD는 .gitlab-ci.yml 파일을 기반으로 파이프라인을 실행합니다. 이 파일은 Git 저장소의 루트 디렉토리에 위치하며, CI/CD의 빌드, 테스트, 배포 단계를 정의하는 역할을 합니다.

`.gitlab-ci.yml` 파일의 기본 구조

GitLab CI/CD는 스테이지(Stage) 기반의 실행 방식을 사용합니다. 기본적으로 .gitlab-ci.yml 파일은 다음과 같은 구조로 구성됩니다.

stages:  # 실행 단계 정의
  - build
  - test

build:   # 빌드 작업 정의
  stage: build
  script:
    - gcc -o my_program main.c  # C 코드 빌드

test:    # 테스트 작업 정의
  stage: test
  script:
    - ./my_program  # 빌드한 프로그램 실행

위 예제에서는 build 단계에서 C 프로그램을 컴파일하고, test 단계에서 실행하여 정상적으로 동작하는지 확인합니다.

주요 구성 요소

.gitlab-ci.yml 파일에서 자주 사용되는 항목은 다음과 같습니다.

stages

실행할 스테이지를 정의하며, 순서대로 실행됩니다.
예: stages: [build, test, deploy]

script

실행할 명령어 목록을 지정합니다.
예: script: - gcc -o app main.c

image

실행 환경을 설정하며, Docker 컨테이너를 사용할 수 있습니다.
예: image: gcc:latest

before_script / after_script

스테이지 실행 전후에 공통으로 수행할 명령을 정의할 수 있습니다.
예: “`yaml before_script:
- echo “Preparing environment”
  “`

실행 환경 설정 (Docker 활용)

GitLab CI/CD는 실행 환경을 Docker 컨테이너로 설정할 수도 있습니다.

image: gcc:latest  # GCC가 포함된 Docker 이미지 사용

stages:
  - build
  - test

build:
  stage: build
  script:
    - gcc -o my_program main.c

test:
  stage: test
  script:
    - ./my_program

위 설정을 사용하면 GitLab Runner가 gcc:latest Docker 이미지를 활용하여 실행되므로, 추가 환경 설정 없이도 C 코드를 빌드하고 실행할 수 있습니다.

`.gitlab-ci.yml` 작성 시 주의사항

YAML 문법을 준수해야 합니다. (들여쓰기 필수)
stages 순서대로 실행됩니다.
스크립트 오류가 발생하면 파이프라인이 중단됩니다.

이제 기본적인 .gitlab-ci.yml 파일을 이해했으므로, 다음 섹션에서는 C 코드 빌드 단계를 구성하는 방법을 살펴보겠습니다.

C 코드 빌드 단계 구성

GitLab CI/CD에서 C 코드를 빌드하는 단계는 소스 코드 컴파일 및 실행 파일 생성을 수행하는 과정입니다. 이 단계에서는 적절한 컴파일러 및 라이브러리를 설정하고, 빌드 성공 여부를 검증하는 것이 중요합니다.

기본적인 C 코드 빌드 설정

GitLab CI/CD에서는 .gitlab-ci.yml 파일 내에서 GCC 또는 Clang 같은 C 컴파일러를 사용하여 프로그램을 빌드할 수 있습니다.

image: gcc:latest  # GCC 컴파일러가 포함된 Docker 이미지

stages:
  - build

build:
  stage: build
  script:
    - gcc -Wall -o my_program main.c

위 설정에서는 gcc:latest Docker 이미지를 사용하여 gcc -Wall -o my_program main.c 명령어로 C 코드를 빌드합니다.

Makefile을 활용한 빌드 자동화

C 프로젝트의 소스 파일이 여러 개라면, Makefile을 활용하여 빌드를 관리할 수 있습니다.

Makefile 예제 (Makefile)

CC=gcc
CFLAGS=-Wall -Wextra -O2
TARGET=my_program
SRC=main.c utils.c
OBJ=$(SRC:.c=.o)

all: $(TARGET)

$(TARGET): $(OBJ)
    $(CC) $(CFLAGS) -o $@ $(OBJ)

clean:
    rm -f $(OBJ) $(TARGET)

GitLab CI/CD에서 Makefile을 사용하는 경우, .gitlab-ci.yml 설정은 다음과 같이 작성할 수 있습니다.

image: gcc:latest

stages:
  - build

build:
  stage: build
  script:
    - make

이렇게 하면 make 명령어가 실행되어 컴파일 및 링크 과정이 자동화됩니다.

빌드 결과물 아티팩트 저장

GitLab CI/CD에서는 빌드된 실행 파일을 아티팩트(artifacts) 로 저장하여, 후속 단계에서 활용할 수 있습니다.

image: gcc:latest

stages:
  - build

build:
  stage: build
  script:
    - make
  artifacts:
    paths:
      - my_program

위 설정을 적용하면 my_program 실행 파일이 GitLab의 CI/CD 아티팩트에 저장되며, 이후 단계에서 다운로드하여 실행할 수 있습니다.

병렬 빌드를 활용한 속도 최적화

소스 코드가 많을 경우, make -j$(nproc) 옵션을 사용하면 병렬 빌드를 수행하여 속도를 높일 수 있습니다.

build:
  stage: build
  script:
    - make -j$(nproc)

$(nproc)는 사용 가능한 CPU 코어 수만큼 병렬 컴파일을 수행하는 명령어로, 빌드 시간을 줄이는 데 효과적입니다.

GitLab CI/CD에서 빌드 설정이 완료되었으므로, 다음 섹션에서는 자동화된 테스트 구성 방법을 살펴보겠습니다.

자동화된 테스트 작성

GitLab CI/CD에서 C 코드의 품질을 보장하려면 자동화된 테스트가 필수적입니다. 테스트를 자동화하면 코드 변경 시 발생할 수 있는 오류를 조기에 발견할 수 있으며, 코드 안정성을 유지하는 데 도움이 됩니다.

테스트 프레임워크 선택

C 언어에서 사용할 수 있는 주요 테스트 프레임워크는 다음과 같습니다.

Check: 가장 많이 사용되는 유닛 테스트 프레임워크
CUnit: 경량 테스트 프레임워크
Unity: 임베디드 시스템에서 활용하기 좋은 프레임워크

이 예제에서는 Check 프레임워크를 활용하여 GitLab CI/CD에서 자동 테스트를 실행하는 방법을 설명합니다.

Check 프레임워크 설치 및 설정

Check 프레임워크를 설치하려면 패키지 매니저를 사용합니다.

Ubuntu에서 Check 설치:

sudo apt update
sudo apt install check

테스트 코드 작성

다음은 Check를 이용한 기본적인 C 유닛 테스트 코드 예제입니다.

테스트 대상 코드 (math_operations.c)

#include "math_operations.h"

int add(int a, int b) {
    return a + b;
}

int multiply(int a, int b) {
    return a * b;
}

테스트 대상 헤더 (math_operations.h)

#ifndef MATH_OPERATIONS_H
#define MATH_OPERATIONS_H

int add(int a, int b);
int multiply(int a, int b);

#endif

테스트 코드 (test_math.c)

#include <check.h>
#include "math_operations.h"

START_TEST(test_add) {
    ck_assert_int_eq(add(2, 3), 5);
    ck_assert_int_eq(add(-1, 1), 0);
}
END_TEST

START_TEST(test_multiply) {
    ck_assert_int_eq(multiply(2, 3), 6);
    ck_assert_int_eq(multiply(-2, 3), -6);
}
END_TEST

Suite* math_suite(void) {
    Suite *s;
    TCase *tc_core;

    s = suite_create("MathOperations");
    tc_core = tcase_create("Core");

    tcase_add_test(tc_core, test_add);
    tcase_add_test(tc_core, test_multiply);
    suite_add_tcase(s, tc_core);

    return s;
}

int main(void) {
    int number_failed;
    Suite *s;
    SRunner *sr;

    s = math_suite();
    sr = srunner_create(s);

    srunner_run_all(sr, CK_NORMAL);
    number_failed = srunner_ntests_failed(sr);
    srunner_free(sr);

    return (number_failed == 0) ? 0 : 1;
}

위 코드에서는 math_operations.c의 add() 및 multiply() 함수를 테스트합니다.

Makefile에 테스트 빌드 추가

테스트를 실행할 수 있도록 Makefile을 수정합니다.

CC=gcc
CFLAGS=-Wall -Wextra -O2
TARGET=my_program
TEST_TARGET=test_math
SRC=math_operations.c
TEST_SRC=test_math.c
OBJ=$(SRC:.c=.o)

all: $(TARGET)

$(TARGET): $(OBJ)
    $(CC) $(CFLAGS) -o $@ $(OBJ)

test: $(TEST_SRC) $(SRC)
    $(CC) $(CFLAGS) -o $(TEST_TARGET) $(TEST_SRC) $(SRC) -lcheck
    ./$(TEST_TARGET)

clean:
    rm -f $(OBJ) $(TARGET) $(TEST_TARGET)

이제 make test 명령어를 실행하면 테스트를 수행할 수 있습니다.

GitLab CI/CD에서 테스트 자동 실행

GitLab CI/CD에서 테스트를 실행하려면 .gitlab-ci.yml 파일을 다음과 같이 수정합니다.

image: gcc:latest

stages:
  - build
  - test

build:
  stage: build
  script:
    - make

test:
  stage: test
  script:
    - apt update && apt install -y check
    - make test

위 설정을 적용하면 GitLab CI/CD가 빌드 후 자동으로 테스트를 실행합니다.

테스트 결과를 GitLab에서 확인

GitLab에서는 테스트가 실패할 경우 CI/CD 실행 결과에서 빨간색(Failed) 표시가 나타나며, 로그에서 어떤 테스트가 실패했는지 확인할 수 있습니다.

이제 GitLab CI/CD에서 C 코드의 테스트 자동화가 완료되었습니다. 다음 섹션에서는 빌드 및 테스트 결과 확인 방법을 살펴보겠습니다.

빌드 및 테스트 결과 확인

GitLab CI/CD를 사용하면 빌드 및 테스트의 결과를 웹 인터페이스에서 쉽게 확인할 수 있습니다. 이 섹션에서는 GitLab에서 실행 로그를 확인하는 방법과 실패 시 디버깅하는 방법을 설명합니다.

1. GitLab에서 빌드 및 테스트 로그 확인

GitLab CI/CD가 실행되면 프로젝트의 CI/CD 파이프라인 페이지에서 빌드 및 테스트 결과를 확인할 수 있습니다.

CI/CD 실행 로그 확인 방법

GitLab 프로젝트로 이동
좌측 메뉴에서 CI/CD → Pipelines 선택
실행된 파이프라인 목록에서 최신 실행 항목 클릭
빌드(build) 또는 테스트(test) 단계를 클릭하면 실행 로그를 볼 수 있음

로그에서 빌드 및 테스트가 정상적으로 완료되었는지 확인할 수 있습니다.

2. 빌드 실패 시 디버깅

GitLab CI/CD에서 빌드가 실패하면, 로그에서 오류 메시지를 확인하여 원인을 파악할 수 있습니다.

빌드 실패 예제

실행 로그에서 다음과 같은 오류가 발생했다고 가정합니다.

main.c:10:5: error: expected ';' before 'return'

이 경우, main.c 파일의 10번째 줄에서 ;이 빠졌다는 것을 의미합니다. 코드를 수정한 후 다시 커밋하여 빌드를 재시도하면 됩니다.

GitLab에서 수동으로 빌드 재실행

GitLab UI에서 CI/CD 실행을 다시 시도하려면:

CI/CD → Pipelines 페이지로 이동
실패한 빌드 항목에서 Retry(재시도) 버튼 클릭
새 빌드가 실행되며 오류가 수정되었는지 확인

3. 테스트 실패 시 문제 해결

테스트가 실패하면 로그에서 실패한 테스트 케이스를 확인할 수 있습니다.

테스트 실패 예제

GitLab 실행 로그:

Running ./test_math
Check failed: test_add: expected 5 but got 4

위 오류는 add(2, 3) 함수가 5를 반환해야 하지만, 4를 반환했음을 의미합니다.

원인을 확인하고 math_operations.c 코드 수정 후 다시 커밋
변경 후 GitLab CI/CD가 다시 실행되며 오류가 해결되었는지 확인

4. 아티팩트를 활용한 디버깅

빌드된 실행 파일을 GitLab CI/CD 아티팩트(artifacts) 로 저장하면, 로컬 환경에서 직접 실행하여 문제를 재현할 수 있습니다.

.gitlab-ci.yml에 다음을 추가하여 빌드된 실행 파일을 저장합니다.

artifacts:
  paths:
    - my_program
    - test_math

이제 GitLab UI에서 빌드 결과물(실행 파일)을 다운로드하여 직접 실행하고 디버깅할 수 있습니다.

5. GitLab CI/CD의 상태 아이콘 활용

GitLab CI/CD의 빌드 및 테스트 상태는 프로젝트의 README 파일 또는 다른 문서에서 배지를 사용하여 표시할 수도 있습니다.

GitLab 프로젝트의 Settings → CI/CD에서 다음과 같은 배지를 추가할 수 있습니다.

![Build Status](https://gitlab.com/{username}/{repository}/badges/main/pipeline.svg)

이제 프로젝트의 README.md에서 빌드 및 테스트 상태를 실시간으로 확인할 수 있습니다.

GitLab CI/CD에서 빌드 및 테스트 결과를 확인하는 방법을 이해했으므로, 다음 섹션에서는 빌드 속도를 높이기 위한 캐싱 및 병렬 실행 기법을 살펴보겠습니다.

캐싱 및 병렬 실행 최적화

GitLab CI/CD에서 빌드 및 테스트를 실행할 때 캐싱과 병렬 실행을 활용하면 실행 속도를 크게 향상시킬 수 있습니다. 이 섹션에서는 캐시를 이용한 불필요한 재빌드 방지 및 병렬 실행을 통한 빌드 속도 개선 방법을 설명합니다.

1. 캐싱을 활용한 빌드 속도 최적화

GitLab CI/CD에서는 cache 키워드를 사용하여 변경되지 않은 파일을 재사용할 수 있습니다.

캐싱을 활용하면 라이브러리, 빌드 아티팩트, 패키지 설치 등의 시간을 절약할 수 있습니다.
GitLab은 프로젝트 내 .gitlab-ci.yml 설정을 기반으로 캐시를 자동 관리합니다.

Makefile 빌드 결과 캐싱

C 프로젝트에서는 컴파일된 오브젝트 파일(.o)을 캐싱하면 전체 빌드 시간을 단축할 수 있습니다.

cache:
  key: build-cache
  paths:
    - "*.o"
    - "build/"
  policy: pull-push

위 설정을 추가하면 빌드 과정에서 생성된 오브젝트 파일(.o)과 build 폴더가 캐싱됩니다.

동일한 코드를 다시 빌드할 때 이전 결과를 활용하여 빠르게 완료됩니다.

2. 패키지 설치 캐싱

테스트 실행을 위해 추가 패키지가 필요할 경우, 매번 새로 설치하는 대신 캐싱을 활용할 수 있습니다.

cache:
  key: apt-cache
  paths:
    - /var/cache/apt/archives
  policy: pull-push
before_script:
  - apt update && apt install -y check

이제 GitLab은 패키지 다운로드 결과를 캐싱하여, 이후 빌드에서 패키지를 재사용하게 됩니다.

3. 병렬 실행을 활용한 빌드 속도 최적화

GitLab CI/CD는 멀티 코어 시스템에서 병렬 실행을 지원합니다.

make -j$(nproc) 옵션을 사용하면 여러 개의 소스 파일을 동시에 컴파일하여 빌드 시간을 단축할 수 있습니다.

병렬 빌드 적용 예제

build:
  stage: build
  script:
    - make -j$(nproc)

$(nproc)는 사용 가능한 CPU 코어 수를 자동으로 감지하여 병렬 실행합니다.
빌드 속도가 비약적으로 향상됩니다.

4. GitLab CI/CD에서 병렬 잡(Jobs) 실행

GitLab은 동일한 스테이지에서 여러 작업(Jobs)을 병렬로 실행할 수 있습니다.

예를 들어, 서로 다른 컴파일러(GCC, Clang)를 동시에 테스트하는 경우, 아래처럼 정의할 수 있습니다.

stages:
  - test

test_gcc:
  stage: test
  script:
    - apt update && apt install -y gcc
    - gcc -o my_program main.c
    - ./my_program

test_clang:
  stage: test
  script:
    - apt update && apt install -y clang
    - clang -o my_program main.c
    - ./my_program

위 설정을 적용하면 test_gcc와 test_clang이 병렬 실행되어 전체 실행 속도가 빨라집니다.

5. CI/CD의 제한적인 리소스 활용 최적화

GitLab CI/CD에서 실행되는 Runner는 리소스 제한이 있을 수 있음을 고려해야 합니다.

최적화 전략
병렬 실행 시 메모리 사용량을 고려하여 make -j4처럼 적절한 병렬 빌드 개수를 설정
필요 없는 파일을 아티팩트로 저장하지 않도록 관리
cache:policy: push 옵션을 활용하여 변경된 파일만 업데이트

최적화 적용 후 성능 비교

캐싱 및 병렬 실행 적용 전후의 빌드 속도를 비교하면 다음과 같은 결과를 얻을 수 있습니다.

최적화 적용 여부	빌드 시간 (초)	테스트 시간 (초)	전체 실행 시간 (초)
최적화 전	120	30	150
캐싱 적용	90	30	120
병렬 실행 적용	60	15	75

최적화를 적용하면 전체 실행 시간이 최대 50% 이상 단축될 수 있습니다.

이제 GitLab CI/CD에서 빌드 속도를 최적화하는 방법을 익혔습니다. 다음 섹션에서는 보안 및 환경 변수 관리 방법을 살펴보겠습니다.

보안 및 환경 변수 관리

GitLab CI/CD에서 보안은 중요한 요소이며, 특히 환경 변수 관리는 민감한 데이터(예: API 키, 데이터베이스 비밀번호 등)를 보호하는 데 필수적입니다. 이 섹션에서는 보안 강화를 위한 환경 변수 사용법과 GitLab CI/CD에서 안전하게 설정하는 방법을 설명합니다.

1. 환경 변수를 활용한 보안 관리

GitLab CI/CD에서는 .gitlab-ci.yml 파일에 환경 변수를 직접 포함하는 대신, GitLab의 CI/CD 설정에서 환경 변수를 관리하는 것이 권장됩니다.

예를 들어, 데이터베이스 비밀번호를 코드에 직접 포함하지 않고 환경 변수로 설정하면 보안이 강화됩니다.
SECRET_KEY 같은 민감한 정보는 .gitlab-ci.yml이 아닌 GitLab UI에서 환경 변수로 설정해야 합니다.

2. GitLab 환경 변수 설정 방법

GitLab UI에서 환경 변수를 설정하는 방법은 다음과 같습니다.

GitLab 프로젝트로 이동
Settings(설정) → CI/CD 클릭
Variables(변수) 섹션에서 “Add Variable” 버튼 클릭
Key: SECRET_KEY / Value: my_secret_password 입력
Mask variable(변수 마스킹) 옵션 활성화
Save variables(저장) 클릭

이제 SECRET_KEY 변수는 GitLab CI/CD에서 SECRET_KEY 환경 변수로 사용할 수 있습니다.

3. `.gitlab-ci.yml`에서 환경 변수 사용

설정한 환경 변수를 .gitlab-ci.yml에서 다음과 같이 사용할 수 있습니다.

stages:
  - build

build:
  stage: build
  script:
    - echo "Using secret key: $SECRET_KEY"

GitLab CI/CD가 실행될 때 $SECRET_KEY가 설정된 값으로 자동 대체됩니다.
GitLab UI에서 설정한 변수만 로드되므로, 소스 코드에는 노출되지 않습니다.

4. 환경 변수의 보안 강화 (마스킹 및 보호 변수)

GitLab에서는 환경 변수를 보호하기 위해 Mask Variable(마스킹 변수) 기능을 제공합니다.

마스킹된 변수는 로그에 표시되지 않습니다.
예를 들어, 아래 로그는 마스킹된 변수를 표시하지 않습니다.

  Using secret key: [MASKED]

Protected Variable(보호된 변수) 옵션을 활성화하면 보호된 브랜치에서만 실행 가능하도록 설정할 수도 있습니다.

5. `.gitlab-ci.yml`에서 변수 파일을 로드하는 방법

환경 변수를 .env 파일로 관리하면 보안성이 향상됩니다.

.env 파일 예제:

DB_USER=root
DB_PASS=mysecurepassword

.gitlab-ci.yml에서 .env 파일을 로드하여 사용할 수 있습니다.

before_script:
  - export $(grep -v '^#' .env | xargs)

이제 .env 파일의 값을 CI/CD에서 사용할 수 있습니다.

6. GitLab CI/CD에서 SSH 키 관리

CI/CD 파이프라인에서 원격 서버에 배포하려면 SSH 키를 안전하게 관리하는 방법이 필요합니다.

GitLab의 CI/CD 변수에 SSH_PRIVATE_KEY 추가
.gitlab-ci.yml에서 SSH 키를 설정하여 원격 서버에 안전하게 접속

before_script:
  - mkdir -p ~/.ssh
  - echo "$SSH_PRIVATE_KEY" | tr -d '\r' > ~/.ssh/id_rsa
  - chmod 600 ~/.ssh/id_rsa
  - ssh-keyscan -H myserver.com >> ~/.ssh/known_hosts

이제 CI/CD 파이프라인에서 원격 서버에 안전하게 연결할 수 있습니다.

7. GitLab CI/CD 보안 모범 사례

보안 요소	설명
환경 변수 사용	민감한 정보를 `.gitlab-ci.yml` 파일에 직접 포함하지 않기
마스킹 변수	로그에서 환경 변수 값이 표시되지 않도록 설정
보호된 변수	특정 브랜치(예: `main`)에서만 변수 사용 허용
`.env` 파일 사용	민감한 정보를 코드에서 분리하여 관리
SSH 키 관리	GitLab CI/CD에서 안전하게 원격 서버 접속

GitLab CI/CD에서 보안과 환경 변수 관리를 적절히 활용하면 민감한 정보가 유출되는 것을 방지하고, 안전한 빌드 및 배포 프로세스를 유지할 수 있습니다.

이제 보안 및 환경 변수 관리 방법을 이해했으므로, 마지막으로 요약을 살펴보겠습니다.

요약

본 기사에서는 GitLab CI/CD를 활용하여 C 코드를 자동 빌드하고 테스트하는 방법을 단계별로 설명했습니다.

GitLab CI/CD 개요 – 지속적 통합(CI) 및 지속적 배포(CD)의 개념과 GitLab의 역할을 이해했습니다.
GitLab 설정 및 사전 준비 – 프로젝트에 GitLab Runner를 등록하고 CI/CD를 활성화하는 방법을 살펴보았습니다.
.gitlab-ci.yml 작성법 – CI/CD 파이프라인을 구성하는 기본 설정과 실행 단계(stages)를 정의하는 방법을 학습했습니다.
C 코드 빌드 – Makefile을 활용한 빌드 자동화 및 실행 파일을 생성하는 방법을 설명했습니다.
자동화된 테스트 – Check 프레임워크를 활용하여 유닛 테스트를 작성하고, CI/CD에서 자동으로 실행하는 방법을 배웠습니다.
빌드 및 테스트 결과 확인 – GitLab의 UI를 통해 실행 로그를 확인하고, 오류 발생 시 디버깅하는 방법을 다루었습니다.
속도 최적화 – 캐싱과 병렬 실행을 활용하여 CI/CD 실행 시간을 줄이는 전략을 적용했습니다.
보안 및 환경 변수 관리 – 민감한 정보를 환경 변수로 관리하고, SSH 키를 안전하게 저장하는 방법을 소개했습니다.

GitLab CI/CD를 적절히 활용하면 코드 품질을 유지하고, 배포 프로세스를 자동화할 수 있으며, 개발 속도를 향상시킬 수 있습니다.
본 기사를 바탕으로 GitLab CI/CD를 활용하여 C 프로젝트의 자동 빌드 및 테스트 환경을 구축해보시길 바랍니다. 🚀