이 저장소의 테스트 워크플로를 4분 간격으로 두 번 실행해 캐시의 손익을 쟀습니다. 첫 실행에는 복원할 캐시가 없었고, 두 번째 실행은 첫 실행이 저장해 둔 캐시를 복원했습니다.

캐시 덕분에 테스트 실행은 113초에서 99초로 14초 줄었습니다. 그런데 복원에 10초가 더 들고 저장 시간은 그대로라, 잡 전체로는 161초에서 159초가 되어 차이가 없었습니다. 이 저장소의 예제는 의존성이 적고 Testcontainers로 PostgreSQL을 띄우는 시간이 테스트 시간의 대부분이라, 캐시로 줄일 수 있는 몫이 애초에 작았습니다. 두 번만 비교한 값이라 테스트 시간 14초 차이에는 러너 성능 편차도 섞여 있을 수 있습니다. 그래도 캐시 저장에 매번 40초 가까이 든다는 점은 두 실행에서 같았습니다.

아티팩트는 필요할 때만 올립니다. 이 워크플로는 테스트 리포트를 실패했을 때만 업로드합니다. 성공한 실행에서는 이 단계가 0초로 끝납니다.

워크플로는 on에 선언한 이벤트가 발생할 때 실행됩니다. 이벤트는 성격에 따라 네 갈래로 나뉩니다.

성능 관점에서는 schedule의 공식 문서 문구를 알아둘 만합니다. GitHub은 schedule 이벤트가 Actions 전체의 부하가 높은 시간대에 지연될 수 있고, 매시 정각이 바로 그런 시간대이며, 부하가 충분히 높으면 큐잉된 잡이 아예 드랍될 수도 있다고 안내합니다. cron의 분을 0이 아닌 값으로 두면 정각에 몰리는 혼잡을 피할 수 있습니다.

이벤트 자체가 생성되지 않는 경우도 있습니다. 한 번에 5,000개가 넘는 브랜치를 푸시하면 push 이벤트가 만들어지지 않고, 태그를 한 번에 3개 넘게 푸시하면 태그에 대한 이벤트가 만들어지지 않습니다. 워크플로가 실행되지 않았는데 로그도 없다면, 워크플로 설정보다 앞 단계인 이벤트 생성이 생략되지 않았는지 의심해 볼 수 있습니다.

서버 쪽 내부 구조를 설명하는 문서는 없지만, 공식 문서와 장애 보고서 곳곳에 언급된 내부 서비스와 의존 시스템의 정보를 이으면 큰 흐름을 재구성할 수 있습니다.

핵심은 워크플로 실행이 단일 서비스가 아니라 여러 큐와 서비스를 지나는 비동기 파이프라인이라는 점입니다. webhook 처리 → 실행 생성 → 잡 큐 → 러너 배정 중 어느 구간이 막혀도 사용자에게는 똑같이 "워크플로가 시작되지 않는" 증상으로 보입니다.

참고로 러너가 GraphQL API를 직접 호출하지는 않습니다. 액션 내려받기와 API 호출은 api.github.com 등 REST 엔드포인트와 *.actions.githubusercontent.com 계열 도메인을 씁니다. 워크플로 파일을 읽거나 액션을 resolve하는 단계에서 내부적으로 GraphQL을 쓰는지는 공개된 자료가 없습니다.

이 구조에서 성능에 크게 영향을 주는 요소는 워크플로 파일이나 조건식의 개수가 아니라, 조건이 파이프라인의 어느 단계에서 평가되는가입니다. 조건은 앞쪽에서 평가될수록 이득입니다. 같은 "건너뛰기"라도 평가 시점이 다릅니다.

그래서 튜닝의 핵심은 실행과 잡을 만들지 않도록 조건을 가능한 한 앞 단(on 필터)으로 옮기는 일입니다.

반대로 개수는 걱정할 요인이 아닙니다. 트리거 평가는 파일 단위로 일어나므로 파일이 많으면 평가할 대상도 늘어나는 셈이지만, 파일 수가 실행 시작을 늦춘다는 공식 자료나 측정은 찾지 못했습니다. 공식 한도도 파일 수가 아니라 파일 하나의 크기(500KB), 트리거 이벤트 빈도(저장소당 10초에 1,500개), 실행 생성 빈도(10초에 500개)에 걸려 있습니다. 조건식도 마찬가지입니다. 표현식 평가는 서버 쪽에서 일어나고, 그 비용이 실행 시간에 잡힐 만큼 크다는 근거는 없습니다. 워크플로 파일을 합치거나 조건식을 줄이는 정리는 관리 편의로는 의미가 있어도, 실행 시간을 줄이는 수단은 아닙니다.

두 평가 시점의 차이는 필수 상태 검사 문제와도 이어집니다. on 필터로 워크플로를 건너뛰면 검사가 Pending으로 남아 병합이 막히지만, 잡 수준 if로 건너뛴 잡은 상태가 Success로 보고되어 병합을 막지 않습니다. 그래서 필수 검사로 지정한 워크플로에서는 경로 필터 대신 잡 수준에서 변경 파일을 판별해 건너뛰는 방식이 우회책이 됩니다.

앞 절에서 장애 보고서는 구조를 재구성하는 근거였는데, 이 절에서는 장애 사례 자체를 봅니다. 장애가 파이프라인의 어느 단계를 막는지, 그리고 그때 생기는 지연이 왜 워크플로 튜닝의 범위 밖인지가 여기서 드러납니다.

2025년 말부터 GitHub 장애가 잦아졌다는 체감은 데이터와 대체로 맞습니다. 월별 availability report에 집계된 인시던트 수가 2025년 하반기에는 월 3~5건이었는데 2026년에는 월 6~10건으로 늘었습니다. 이 글을 쓰는 2026년 8월에는 1일부터 27일까지 githubstatus.com에 올라온 인시던트 25건 중 7건이 Actions 관련이었습니다. 증상도 "실행 시작 지연", "잡이 queued 상태로 고착"처럼 파이프라인 앞 단이 막히는 유형이 반복됩니다.

원인을 나눠 보면, Actions 파이프라인 자체의 장애와 파이프라인이 의존하는 상류 서비스 장애가 섞여 있습니다.

GitHub도 이 구조를 문제로 인정하고, 2026년 3월에 "Actions와 Git 같은 핵심 시스템이 공유 인프라 문제에 영향받지 않도록 의존성을 격리하겠다"고 밝혔습니다. 커뮤니티에서는 진행 중인 데이터센터 이전 작업을 장애 증가와 연결하는 추측도 있지만, 공식 장애 보고서가 이전 작업을 원인으로 지목한 적은 없습니다.

사용자 입장에서 중요한 함의는 하나입니다. 장애나 혼잡으로 생기는 대기 시간은 워크플로 안쪽을 아무리 튜닝해도 줄지 않습니다. 그래서 이 글의 첫 번째 기법은 측정, 그중에서도 실행 시간과 대기 시간의 구분입니다.

잡이 실제로 실행된 시간과 별개로, 러너를 배정받기까지 기다리는 시간이 따로 있습니다. 워크플로 실행이 생성된 시각(createdAt)과 잡이 시작된 시각(startedAt)의 차이가 대기 시간입니다. 앞에서 본 파이프라인으로 말하면 잡 큐잉부터 러너 배정까지의 구간입니다.

개인 저장소에서는 대기가 거의 없지만, 동시 실행 한도에 걸리는 조직 저장소에서는 대기가 실행 시간보다 길어지기도 합니다. 그런 상황이면 워크플로 내부를 아무리 다듬어도 체감 시간이 줄지 않습니다. 저장소나 조직의 Insights 탭에 있는 Actions Performance Metrics에서 잡별 평균 실행 시간과 평균 대기 시간을 최대 1년 치까지 볼 수 있으니, 여기서 대기가 문제인지 실행이 문제인지를 먼저 구분하는 편이 좋습니다.

on에 paths나 paths-ignore를 걸면 바뀐 파일 경로에 따라 실행을 건너뜁니다. 앞에서 본 대로 이 필터는 실행 생성 전에 평가되므로, 필터에 걸리면 파이프라인에 아무것도 들어가지 않습니다.

paths를 쓸 때는 워크플로 파일 자신을 목록에 넣어 두는 점이 중요합니다. 이렇게 해야 워크플로를 고쳤을 때 그 변경이 검증됩니다.

같은 브랜치에 커밋을 연달아 밀어 넣으면 이전 커밋의 워크플로가 계속 돌고 있는데 새 실행이 또 시작됩니다. 결과를 볼 필요가 없는 실행이 러너를 차지합니다. concurrency로 그룹을 묶고 cancel-in-progress를 켜면 진행 중이던 실행이 취소됩니다.

그런데 이 설정을 모든 워크플로에 넣으면 안 됩니다. 배포 워크플로는 중간에 취소되면 어중간한 상태로 남을 수 있습니다. 그런 워크플로는 그룹만 묶고 취소는 끕니다.

cancel-in-progress: false로 두면 진행 중인 실행은 끝까지 돌고 새 실행은 대기합니다. 다만 기본값으로는 한 그룹에서 대기할 수 있는 실행이 하나뿐이고, 뒤에 들어온 실행이 먼저 대기하던 실행을 취소합니다. 커밋 세 개를 연달아 밀면 첫 번째는 배포되고 두 번째는 취소되며 세 번째만 배포됩니다. 중간 실행까지 모두 돌려야 한다면 queue: max를 지정해 최대 100개까지 줄을 세울 수 있습니다. queue: max와 cancel-in-progress: true는 동작이 서로 어긋나므로 함께 쓸 수 없습니다.

캐시는 복원과 저장에도 시간을 씁니다. 복원은 setup 단계에서, 저장은 잡 마지막의 Post 단계에서 일어나므로, 실행 결과 화면에서 이 두 단계의 시간을 보면 캐시가 얼마를 쓰는지 알 수 있습니다.

캐시가 이득인지는 "다시 내려받는 시간"과 "복원 + 저장 시간"의 차이로 정해집니다. 의존성 다운로드에 시간을 많이 쓰는 프로젝트는 캐시로 줄어들 가능성이 높지만, 압축한 결과가 수백 MB인 캐시를 만들면 올리고 내리는 시간이 다시 받는 시간을 넘길 수 있습니다. 어느 쪽인지는 캐시를 붙인 전후의 잡 전체 시간을 비교해야 알 수 있습니다. 다음 글에 캐시를 붙여도 잡 전체 시간이 줄지 않은 실제 측정 사례를 실었습니다.

캐시를 설계할 때 알아야 할 GitHub의 제약이 세 가지 있습니다.

풀 리퀘스트에는 규칙이 하나 더 붙습니다. 풀 리퀘스트에서 만든 캐시는 병합 참조(refs/pull/…​/merge)에 묶이므로, 그 풀 리퀘스트를 다시 실행할 때만 복원됩니다. 기본 브랜치나 다른 풀 리퀘스트는 그 캐시를 쓰지 못합니다. 따라서 캐시를 처음 채우는 일은 기본 브랜치의 워크플로가 맡아야 하고, 풀 리퀘스트는 거기서 복원해 쓰는 구조가 됩니다.

아래 코드의 출력을 예상해 보면 Java의 전달 방식을 확인할 수 있습니다.

출력은 World, 2가 아니라 Hello와 1입니다.^[2] swap 메서드 안에서 파라미터 x와 y에 서로의 값을 대입해도, 호출한 쪽의 x1, y1, x2, y2는 바뀌지 않습니다. 앞에서 정리한 기준대로라면 Java는 primitive type이든 객체든 call by value로 동작합니다.

객체를 전달하는 경우를 그림과 함께 들여다보겠습니다.

work(sb)를 호출하는 순간, main 메서드의 sb에 담긴 참조값이 복사되어 work 메서드의 파라미터 sb에 대입됩니다. 두 변수는 같은 객체를 가리키지만 서로 다른 변수입니다.

work 메서드 안에서 sb에 새 객체를 대입하면 파라미터 sb만 새 객체를 가리키게 되고, main 메서드의 sb는 원래 객체를 그대로 가리킵니다. 그래서 출력은 A1입니다.

그런데 파라미터를 재할당하지 않고 파라미터가 가리키는 객체의 내부 상태를 바꾸면, 그 변경은 호출한 쪽에서도 보입니다.

main 메서드에서 "A1"이 담긴 sb로 appendWork(sb)를 호출한 뒤 출력하면 A1B2가 나옵니다.

파라미터 재할당은 호출자에게 보이지 않는데 객체 상태 변경은 보이니, "객체는 call by reference로 전달된다"는 설명이 그럴듯하게 들립니다. 그러나 이 글에서 두 방식을 가르는 실용적인 기준은 파라미터 대입이 호출자 변수에 반영되는가입니다. 객체 상태 변경이 보이는 것은 두 변수가 같은 객체를 가리키고 있기 때문일 뿐, 전달 방식은 여전히 참조값의 복사, 즉 call by value입니다.

Head First Java에서는 객체 참조를 리모컨에 비유해서 설명합니다. 객체를 전달하면 TV(객체)가 복사되는 것이 아니라 그 TV를 조작할 수 있는 리모컨(참조값)이 복사됩니다. 복사된 리모컨으로 채널을 바꾸면(객체 상태 변경) 원래 리모컨을 가진 사람에게도 바뀐 채널이 보이지만, 복사된 리모컨을 다른 TV에 연결해도(재할당) 원래 리모컨은 여전히 처음의 TV를 조작합니다.

Java의 reference는 객체를 식별하고 접근하는 값이며, 포인터처럼 이해할 수 있습니다. 아래 Java 선언의 객체 접근과 재할당 동작은

C++ 포인터를 쓴 다음 코드와 비슷합니다.

Java의 d는 객체 자체가 아니라 객체를 가리키는 값을 담고 있습니다. d를 다른 메서드의 인자로 넘기면 이 참조값이 복사되어 전달됩니다. 다만 위 C++ 코드는 객체 접근과 포인터 재할당을 설명하기 위한 비유이며, 객체의 수명 관리나 참조의 실제 표현까지 같다는 뜻은 아닙니다.

'포인터’는 Java Language Specification도 사용하는 표현입니다. 4.3.1. Objects 절은 참조값을 객체에 대한 포인터라고 정의합니다.

다만 이는 언어 수준의 의미를 설명하는 표현이지, 참조값이 원시 메모리 주소와 같은 형식이라고 보장하는 문장은 아닙니다. Java Virtual Machine Specification 2.7은 객체의 내부 구조를 특정하지 않으며, 일부 구현에서는 참조가 객체 데이터가 아니라 핸들을 가리킬 수도 있다고 설명합니다.

메서드 호출 시의 전달 방식은 8.4.1. Formal Parameters 절에 있습니다. 인자 표현식의 '값’이 새로 만들어진 파라미터 변수를 초기화한다고 설명할 뿐, 파라미터가 호출한 쪽 변수의 별칭이 된다는 언급은 없습니다.

Java를 만든 James Gosling도 The Java Programming Language 책에서 이 오해를 직접 짚었습니다.

최신 공식 Java 학습 자료인 Dev.java에서도 같은 내용을 설명합니다.

결국 혼란의 뿌리는 용어에 있습니다. Java에서 객체를 가리키는 값을 'reference’라고 부르는데, 이 단어가 'call by reference’의 reference와 겹치면서 오해가 생겼습니다. 정확한 문장은 이렇습니다. Java는 객체에 대한 참조값을 call by value로 전달합니다.

JavaScript를 call by reference로 설명하는 자료도 있습니다. 오랫동안 JavaScript의 표준적인 책으로 꼽혀온 JavaScript: The Definitive Guide, 4th Edition은 'By Value Versus by Reference' 장의 요약 표에서 객체가 by reference로 복사·전달·비교된다고 정리합니다. 이 요약 표만 보면 JavaScript는 call by reference라고 설명해도 될 것처럼 보입니다.

그런데 같은 장의 동작 설명을 읽어보면, 이 책이 말하는 by reference는 이 글의 앞부분에서 정의한 call by reference와는 다른 의미입니다. '객체 값 전체가 복사되는 대신 객체에 대한 참조가 전달된다’는 의미로 쓴 표현이고, 파라미터를 재할당해도 호출한 쪽에 보이지 않는다는 점은 이 책도 똑같이 설명합니다.

참조 자체는 값으로 전달된다("References themselves are passed by value")는 설명도 함께 나옵니다. 결국 관찰되는 동작에 대한 설명은 이 글과 같고, 무엇이 전달된다고 부를지에 대한 용어 선택이 다를 뿐입니다.

이처럼 호출자 변수 자체가 아니라 객체를 공유하는 인자 전달 동작을 call by sharing이라고 부르기도 합니다. Barbara Liskov를 비롯한 설계팀이 1970년대 중반에 만든 언어인 CLU의 설계 문서에서 쓴 용어입니다. Java, JavaScript, Python, Ruby의 객체 인자 동작을 이 개념으로 설명할 수 있습니다.

Call by value라고 하면 '객체가 통째로 복사된다’는 오해를, call by reference라고 하면 '재할당도 호출한 쪽에 보인다’는 오해를 각각 부를 수 있습니다. 그래서 저는 JavaScript도 두 용어 중 하나를 고르기보다 call by sharing이라는 개념으로 설명하는 편이 더 명확하다고 생각합니다.