website: CI 러너 코어 수·병렬 테스트 실행 수 확인용 디버그 로그 추가

요약

2026년 7월 21일, ci/speed-up-pipeline 브랜치에서 .github/workflows/ci.yml 파일에 디버그용 스텝을 추가했습니다. 변경 규모는 크지 않아서 8줄 추가, 1줄 삭제에 그쳤지만, CI 속도 개선이라는 더 큰 작업의 일부로 봐야 하는 커밋입니다. 커밋 메시지 그대로 "러너 코어 수·병렬 fork 수 확인용 임시 로그 (검증 후 제거 예정)"인데, 말 그대로 최적화를 하기 전에 지금 상황이 어떤지부터 파악하려는 목적입니다.

배경 및 목적

CI 파이프라인 속도를 개선하려는 작업을 진행 중인데, 뭘 최적화하려면 먼저 현재 리소스가 어떻게 쓰이고 있는지 알아야 합니다. Gradle 테스트를 병렬로 돌릴 때 실제로 몇 개의 프로세스가 fork되는지, 그리고 GitHub Actions 러너가 제공하는 코어 수가 몇 개인지를 모르는 상태에서는 병렬성을 얼마나 늘리거나 줄여야 할지 판단할 근거가 없습니다.

예를 들어 러너가 2코어인데 테스트 executor가 4개씩 뜨고 있다면 오히려 컨텍스트 스위칭 비용 때문에 손해를 보고 있을 수도 있고, 반대로 4코어인데 executor가 1개만 뜬다면 병렬성을 더 끌어올릴 여지가 있는 겁니다. 이런 걸 추측이 아니라 실제 로그로 확인하고 싶어서 임시로 디버그 스텝을 넣었습니다.

구현 내용

변경된 파일은 .github/workflows/ci.yml 하나입니다.

러너 코어 수 확인 스텝 추가

Gradle 세팅 이후, 빌드 전에 새로운 스텝을 하나 끼워 넣었습니다.

- name: (디버그) 러너 코어 수 확인
  run: |
    echo "CI=$CI"
    nproc

nproc 명령으로 러너가 실제로 몇 개의 논리 코어를 가지고 있는지 출력하도록 했습니다. CI 환경변수도 함께 찍어서 이 스텝이 CI 환경에서 정상적으로 실행되고 있는지 같이 확인할 수 있게 했습니다.

빌드 스텝 수정 — 테스트 executor 프로세스 수 카운트

기존에는 단순하게 테스트를 돌렸습니다.

./gradlew compileJava test

이걸 아래처럼 바꿔서, 테스트 로그를 파일로 저장하고 그 안에서 병렬로 뜬 Gradle Test Executor 프로세스 수를 세도록 했습니다.

./gradlew compileJava test --info 2>&1 | tee /tmp/test-info.log
echo "--- Gradle Test Executor 프로세스 수 ---"
grep -c "Starting process 'Gradle Test Executor" /tmp/test-info.log || true

--info 옵션을 붙여서 로그 레벨을 올리고, 그 출력을 tee로 /tmp/test-info.log에 저장하면서 동시에 화면에도 출력되게 했습니다. 그다음 grep -c로 "Starting process 'Gradle Test Executor" 문자열이 몇 번 나오는지 세는데, 이게 실제로 몇 개의 테스트 executor 프로세스가 fork되어 실행됐는지를 알려주는 지표가 됩니다.

grep -c ... || true로 뒤에 || true를 붙인 이유는, 만약 매칭되는 라인이 하나도 없으면 grep이 종료 코드 1을 반환하면서 파이프라인 전체가 실패로 처리될 수 있기 때문입니다. 디버그용 스텝 때문에 빌드 자체가 죽는 걸 막기 위한 안전장치입니다.

배운 점 및 개선점

이번 커밋 자체는 로직 변경이 아니라 순수하게 관찰을 위한 로그 추가라서 배울 만한 기술적인 내용은 크지 않지만, 최적화 작업을 할 때의 접근 방식 면에서 되짚어볼 부분이 있습니다. 병렬성이나 리소스 설정을 바꾸기 전에 먼저 현재 상태를 로그로 찍어서 데이터를 확보하는 순서로 진행하고 있다는 점입니다. 감으로 설정값을 바꾸기보다는 nproc과 executor 카운트 같은 구체적인 숫자를 먼저 확인한 뒤 판단하려는 방향입니다.

커밋 메시지에 이미 "검증 후 제거 예정"이라고 명시되어 있는 만큼, 이 디버그 스텝들은 코어 수와 병렬 fork 수를 확인하고 나면 정리되어야 합니다. CI 로그에 불필요한 출력이 계속 남아있으면 나중에 다른 사람이 로그를 볼 때 혼란을 줄 수 있어서, 후속 커밋에서 이 부분을 되돌리는 작업이 필요합니다. 확인된 코어 수와 executor 수를 바탕으로 gradle.properties나 워크플로 설정에서 병렬 테스트 옵션(maxParallelForks 등)을 조정하는 게 다음 단계가 될 것 같습니다.