Value Object는 식별성 없이 값이 같으면 같다고 간주되는 객체입니다. 돈, 색상, 날짜 같은 개념이 대표적인 예입니다. 10,000원이라는 금액은 어떤 지폐나 계좌 잔액으로 표현되더라도 같은 금액으로 취급할 수 있습니다. 아래 3곳의 링크에서 이 정의를 확인할 수 있습니다.

Eric Evans의 'Domain-Driven Design’에서도 'VALUE OBJECT’를 식별성 없이 속성만으로 동일성을 판단하는 객체로 정의합니다.

Java 코드에서는 동등성을 판단할 속성 값을 기준으로 equals()와 hashCode()를 구현하면 Value Object가 됩니다. 이때 지켜야 할 두 메서드의 규약은 Joshua Bloch의 'Effective Java' 3판 Item 10과 Item 11에 정리되어 있습니다. Java 16부터 정식 기능이 된 record를 사용하면 간결하게 정의할 수 있습니다. record를 도입한 JEP 395도 record를 불변 데이터의 투명한 운반자 역할을 하는 클래스("classes that act as transparent carriers for immutable data")로 소개합니다.

이 클래스의 두 인스턴스는 담고 있는 값이 같으면 동등합니다.

Java 언어와 JVM에도 DDD 및 Fowler의 Value Object와 핵심 성질을 공유하는, 식별성 없는 value object 개념이 도입되고 있습니다. Project Valhalla의 JEP 401: Value Objects (Preview)는 불변이고 객체 식별성이 없으며 필드 값으로만 구분되는 value object를 제안합니다. 2026년 8월 현재 이 JEP는 JDK 28에 미리보기 기능으로 통합되어 있습니다. JEP 169: Larval State for Value Objects는 이러한 불변 value object의 임시 가변 상태를 다루는 별도의 Draft 제안입니다. DDD의 설계 패턴과 Valhalla의 언어·JVM 개념은 동일한 추상화는 아니지만, 어느 쪽에서도 value object를 getter/setter만 가진 객체라는 의미로 사용하지 않습니다.

한편 실무에서는 앞의 정의와 무관하게, 값 동등성과 상관없이 데이터를 담는 객체(data holder)라는 의미로 폭넓게 해석해서 getter/setter만 가진 운반용 객체를 VO라고 부르는 관례도 퍼져 있습니다. 이 관례를 확산시킨 대표적인 출처는 뒤의 Core J2EE Patterns 절에서 살펴봅니다.

DTO의 원래 정의는 원격 호출을 효율화하기 위한 객체입니다. Martin Fowler의 'Patterns of Enterprise Application Architecture' 카탈로그와 책의 401쪽에서는 원격 호출의 횟수를 줄이기 위해 여러 데이터를 한 번에 담아서 나르는 객체로 정의합니다. 원격 호출은 비용이 크므로 한 번의 호출로 필요한 데이터를 모두 전달하려는 의도에서 나온 패턴입니다.

HTTP API의 요청과 응답처럼 네트워크를 건너는 데이터를 담는 객체는 프로세스 경계를 넘고 직렬화된다는 점에서 이 정의와 통합니다. 다만 모든 HTTP 메시지가 원격 호출 횟수를 줄이기 위해 도입되는 것은 아니므로, 이를 DTO라고 부르는 용법은 원래 정의를 현대적인 API 경계에 확장한 것입니다.

실무에서는 여기에서 더 나아가 이 정의를 폭넓게 해석해서, 원격 호출과 무관하게 같은 프로세스 안에서 계층의 경계를 넘어 데이터를 운반하는 객체까지 DTO라고 부르는 관례가 생겼습니다. DB 조회 결과를 담는 객체, 서비스 계층에서 뷰 렌더링 계층으로 전달하는 객체, JPA 엔티티를 서비스 레이어 바깥에 직접 노출하지 않도록 변환한 응답 전용 객체가 그런 예입니다. 이런 용법은 원래 정의를 한층 더 적극적으로 확장한 것이어서, 원격 호출 횟수를 줄인다는 엄밀한 정의와는 거리가 있으므로 DTO라고 부르기 어렵다는 주장도 충분히 나올 수 있습니다. Fowler 자신도 LocalDTO에서 로컬 맥락에서는 DTO가 필요하지 않을 뿐 아니라 오히려 해롭다고("Not just do you not need them in a local context, they are actually harmful") 말합니다.

결국 VO와 DTO를 구분하는 기준은 객체의 특성과 역할입니다. 값 개념을 표현하며 동등성을 값으로 판단하는 것은 VO의 성질이고, 경계를 넘어 데이터를 운반하는 것은 DTO의 역할입니다. 이 둘은 서로 배타적인 분류가 아니므로, 값 동등성을 가진 불변 DTO는 동시에 VO의 성질을 가질 수도 있습니다. 반대로 DTO가 반드시 값 동등성을 가져야 하는 것은 아닙니다.

Java/J2EE(현 Jakarta EE) 진영에서 두 용어의 혼용을 확산시킨 대표적인 초기 출처는 Deepak Alur 등이 쓴 'Core J2EE Patterns: Best Practices and Design Strategies’입니다. 2001년에 나온 초판에서는 티어(tier) 사이의 데이터 전송 객체를 Value Object라는 이름의 패턴으로 정의했습니다. 이 이름이 값 동등성 객체로서의 Value Object와 혼동을 유발했기 때문에, 2003년의 2판에서는 같은 패턴을 TO(Transfer Object)로 개칭했습니다. Martin Fowler는 같은 역할의 패턴을 DTO라고 부릅니다('Patterns of Enterprise Application Architecture' 401쪽). 정리하면 다음 세 가지는 같은 전송 패턴을 가리킵니다.

Oracle의 Transfer Object 문서에서 개칭된 이름으로 정리된 패턴 설명을 볼 수 있습니다.

같은 용법은 다른 책에서도 확인됩니다. 여러 서적이 VO와 DTO를 같은 의미로 쓴다고 명시했습니다.

이 책들이 모두 Core J2EE Patterns 초판의 직접적인 영향을 받았다고 단정할 수는 없습니다. 다만 등장 시기와 여러 문헌에서 반복되는 표현을 고려하면, 초판의 용법이 이후 Java/J2EE 문헌의 표현에도 어느 정도 영향을 미치지 않았을까 추정합니다. 2판에서 이름을 개칭한 지 20년이 넘은 지금까지도 그 관행은 남아 있습니다.

이미 팀 안에서 통용되는 이름을 굳이 바꿔야 하는지 의문이 들 수도 있습니다. 그러나 데이터 운반 객체를 VO라고 부르는 관행에는 실질적인 비용이 있습니다. 값 동등성 객체로서의 Value Object가 여러 중요한 맥락에서 계속 등장하기 때문입니다.

getter/setter만 가진 데이터 홀더를 VO라고 이해하고 있다면 이런 자료를 읽을 때 용어가 어긋나서 혼란이 생깁니다. 원격 프로세스 경계를 넘는 데이터 운반 객체를 DTO라고 부르면 Fowler의 정의와도, Core J2EE Patterns 2판 이후의 개칭된 이름과도 자연스럽게 연결됩니다.

앞의 DTO 정의 절에서 본 것처럼 근래의 관례로는 계층 경계를 넘는 데이터 홀더라는 넓은 의미로 DTO를 쓰기도 합니다. 그러나 클래스 이름에 DTO를 남용하면 단점이 있습니다. HTTP 요청 파라미터를 담는 객체, 통계 쿼리의 결과를 담는 객체까지 모두 DTO라고 부르면 이름만으로는 역할이 드러나지 않습니다.

더 좋은 방법은 객체의 역할에 따라서 접미어를 분리하는 것입니다. 이렇게 하면 이름만으로 역할이 드러나고, 원격 호출과 관련되지 않은 계층에서 쓰이는 객체를 DTO라고 부를 때 엄밀한 정의에서 벗어난다는 논쟁도 피할 수 있습니다. 예를 들면 다음과 같은 이름입니다.

spider-silk의 Publish 워크플로에 앞 글의 gh run view 명령을 돌린 결과입니다.

전체 354초 중 276초를 GitHub Packages에 아티팩트를 올리는 데 씁니다. 빌드는 58초입니다. Gradle 빌드 캐시를 아무리 잘 맞춰도 이 워크플로는 6분에서 5분으로밖에 줄지 않습니다. 측정하지 않고 "Gradle 빌드가 느리다"고 짐작해서 캐시 설정부터 손댔다면, 효과가 거의 없는 곳에 시간을 쓰게 됐을 것입니다.

flashcard의 CI는 Go 코드를 검사하는 워크플로라, 원고 디렉터리만 고쳤을 때는 실행하지 않도록 paths-ignore를 걸었습니다.

같은 브랜치에 커밋을 연달아 밀 때의 중복 실행은 concurrency로 취소합니다.

대기 시간도 확인했습니다. 실행 생성이 14:04:15Z, 잡 시작이 14:04:18Z로 대기가 3초였습니다. 개인 저장소라 러너 배정 대기는 문제가 아니었고, 튜닝 대상은 실행 시간 쪽임을 확인했습니다.

잡 분리의 준비 비용도 이 저장소에서 확인할 수 있습니다. Set up job 1초, 체크아웃 2초, actions/setup-go 7초로 실제 작업 전에 10초를 씁니다. 잡을 나누면 이 10초를 잡마다 다시 내므로, 이 정도 규모의 워크플로에서는 잡 분리가 이득이 되기 어렵습니다.

spring-jdbc-book은 예제 코드가 바뀔 때만 테스트를 돌리도록 paths로 대상을 지정했습니다. 워크플로 파일 자신을 목록에 넣어 둔 점이 중요합니다. 이렇게 해야 워크플로를 고쳤을 때 그 변경이 검증됩니다.

pdf-refinery는 Python 세 버전을 매트릭스로 돌립니다.

실행 기록을 보면 세 잡이 각각 305초, 240초, 308초 걸렸습니다. 러너 사용 시간의 합은 853초지만, 세 잡이 동시에 시작해서 실제로 기다린 시간은 가장 느린 308초입니다. 버전별 검증이라는 목적을 러너 준비 비용(잡당 10초 안팎)만 더 내고 체감 시간 증가 없이 달성한 셈입니다.

캐시는 아직 붙이지 않았습니다. 매 실행마다 pip install -e '.[dev]'에 41~50초를 쓰는데, 이 시간은 거의 전부 다운로드라서 캐시를 붙이면 줄어들 가능성이 높습니다. spring-jdbc-book과 달리 이쪽은 캐시가 이득일 후보입니다.

til의 Cloud Run 배포 워크플로는 중간에 취소되면 어중간한 상태로 남을 수 있습니다. 그래서 cancel-in-progress를 켜지 않고, 그룹만 묶어 한 번에 하나만 돌게 했습니다.

이 설정에서 진행 중인 실행은 끝까지 돌고 새 실행은 대기합니다. 다만 기본값으로는 한 그룹에서 대기할 수 있는 실행이 하나뿐이라, 커밋 세 개를 연달아 밀면 첫 번째는 배포되고 두 번째는 취소되며 세 번째만 배포됩니다. 중간 실행까지 모두 돌려야 하는 워크플로라면 앞 글에서 다룬 queue: max를 고려해야 합니다.

다섯 저장소에 적용한 내용과 결과입니다.

다섯 저장소에서 공통으로 확인한 것은 측정이 먼저라는 점입니다. spider-silk처럼 병목이 짐작과 다른 곳에 있기도 하고, spring-jdbc-book처럼 정석으로 알려진 캐시가 측정해 보면 이득이 없기도 합니다. 기법을 적용하기 전과 후의 잡 전체 시간을 비교하는 습관이 어떤 설정보다 효과가 컸습니다.

이 포스트는 Claude Code와 정상혁이 함께 작성했습니다.

구체적인 튜닝 기법을 보기 전에, 푸시 한 번이 러너 위에서 도는 잡이 되기까지 GitHub 내부에서 거치는 경로를 정리합니다. 튜닝하려면 시간이 어디에서 소모되는지 알아야 하는데, GitHub이 Actions의 내부 구조를 직접 공개하지는 않습니다. 대신 공식 문서와 장애 보고서(availability report)에 흩어져 있는 내부 서비스에 대한 언급으로 구조를 재구성할 수 있고, 장애 사례는 그 구조의 어느 단계가 실제로 막히는지도 보여줍니다.

워크플로를 고치기 전에 어느 단계가 시간을 쓰는지부터 확인해야 합니다. GitHub UI의 실행 결과 화면에서 각 단계를 펼치면 소요 시간이 나오지만, 여러 실행을 비교하려면 gh CLI로 뽑는 편이 빠릅니다.

측정하지 않고 "빌드가 느리다"고 짐작해서 캐시 설정부터 손대면, 효과가 거의 없는 곳에 시간을 쓰게 됩니다. 전체 시간의 대부분을 빌드가 아닌 단계(예: 아티팩트나 패키지 업로드)가 차지하는 워크플로도 흔합니다.

가장 확실하게 시간을 줄이는 방법은 실행 횟수 자체를 줄이는 것입니다. 실행할 필요가 없는 워크플로는 트리거 조건으로 거르고, 결과를 볼 필요가 없어진 실행은 concurrency로 취소합니다.

의존성을 내려받는 시간은 대개 캐시로 줄입니다. actions/cache를 직접 쓰기 전에, 언어별 setup 액션에 내장된 캐시 옵션을 먼저 확인하는 편이 간단합니다.

한 잡 안에서 순서대로 실행하던 작업을 여러 잡으로 나누면 병렬로 돌아갑니다. 매트릭스를 쓰면 같은 작업을 여러 입력으로 반복하는 잡을 한 번에 선언할 수 있습니다.

나눠진 잡들은 동시에 시작하므로, 러너 사용 시간의 합은 잡들의 합이지만 실제로 기다리는 시간은 가장 느린 잡의 시간으로 줄어듭니다.

여기에 두 가지 대가가 따릅니다.

첫째, 잡마다 러너 준비 비용을 다시 냅니다. Set up job, 체크아웃, setup 액션까지 실제 작업 전에 대개 10~30초를 씁니다. 잡을 셋으로 나누면 이 비용을 세 번 냅니다. 전체가 30초짜리인 워크플로를 나누면 오히려 느려집니다.

둘째, 잡 사이에 데이터를 넘기려면 아티팩트 업로드와 다운로드가 필요합니다. 한 잡 안에서는 파일 시스템에 그대로 두면 되던 빌드 결과물을, 잡을 나누면 올렸다가 다시 받아야 합니다.

그래서 잡을 나눌 만한 경우는 다음과 같습니다.

needs로 잡 사이 의존을 걸면 병렬성이 사라지므로, 정말 앞 잡의 결과가 필요할 때만 씁니다. 매트릭스에서는 fail-fast가 기본값 true라, 한 조합이 실패하면 나머지 조합이 취소됩니다. 실패를 빨리 알고 러너 시간을 아끼려면 그대로 두고, 어느 버전에서 깨지는지 한 번에 다 보려면 false로 바꿉니다.

같은 워크플로도 저장소 공개 여부에 따라 다른 사양에서 돕니다.

비공개 저장소의 표준 러너는 2코어입니다. Gradle의 병렬 빌드나 go test -p처럼 코어 수에 비례하는 작업은 여기서 기대만큼 빨라지지 않습니다. 공개 저장소에서 측정한 시간을 비공개 저장소에 그대로 대입하면 안 되는 이유이기도 합니다.

선택할 수 있는 러너는 세 가지입니다.

운영체제 선택도 시간과 비용에 영향을 줍니다. 표준 러너의 분당 단가는 Linux 2코어가 $0.006, Windows 2코어가 $0.010, macOS 3~4코어가 $0.062입니다. 공개 저장소에서는 표준 러너가 무료지만, 비공개 저장소에서 macOS 러너를 쓰면 같은 시간에 Linux의 10배가 넘게 청구됩니다. macOS 러너는 애플 플랫폼용 빌드에만 쓰고, 나머지는 Linux에 두는 편이 낫습니다.

남은 두 가지는 개별 효과가 크지는 않지만 설정이 간단합니다.

actions/checkout의 fetch-depth 기본값은 1이라 최신 커밋 하나만 받습니다. 0으로 바꾸면 전체 이력을 받는데, 커밋이 수만 개인 저장소에서는 이 단계만 수십 초가 걸립니다. 릴리스 노트 생성처럼 이력이 정말 필요한 잡에만 0을 지정하고, 나머지는 기본값을 두면 됩니다. 모노레포에서 일부 디렉터리만 필요하다면 sparse-checkout으로 받는 범위를 줄일 수 있습니다.

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

actions/upload-artifact는 v4에서 업로드·다운로드가 최대 10배 빨라졌으므로, v3 이하를 쓰고 있다면 올리는 편이 좋습니다. 다만 v4부터 아티팩트가 워크플로가 아닌 잡 단위로 묶이므로, 매트릭스 잡에서 같은 이름으로 올리면 충돌합니다. 이름에 매트릭스 값을 붙여 구분해야 합니다.

지금까지의 계산은 github.com을 전제로 했습니다. 앞의 조건 평가 시점 절에서 파일 수와 조건식의 개수는 걱정할 요인이 아니라고 했는데, 그 전제는 트리거 평가와 실행 생성이 GitHub의 공용 인프라에서 일어난다는 것이었습니다. 설치형인 GitHub Enterprise Server(GHES)에서는 이 전제가 달라집니다. webhook 접수부터 트리거 평가, 실행 생성, 잡 큐잉까지 파이프라인 전체가 사내 인스턴스의 자원으로 돌아가기 때문입니다. GitHub은 GHES에서 Actions를 켜는 데에 최소 8 vCPU와 64GB 메모리를 요구하고, 연결하는 러너 수에 따라 권장 사양을 올려 잡습니다(예: 32 vCPU·160GB 메모리의 최대 연결 러너 수는 2,700대).

그래서 github.com에서는 유지보수성 관점에서 추천했던 파일 정리가 GHES에서는 자기 인스턴스의 용량 절감이 됩니다. 안 쓰는 워크플로를 삭제·비활성화하고, 미러링이나 봇의 대량 푸시처럼 워크플로가 필요 없는 이벤트를 줄이면, 그만큼 인스턴스가 처리할 평가와 실행 생성이 줄어듭니다. schedule의 정각 분산도 의미가 달라집니다. github.com에서는 GitHub의 혼잡을 피하는 요령이었지만, GHES에서는 조직 전체의 cron이 정각에 몰리면 내 인스턴스에 부하 스파이크가 생깁니다. 다만 GHES에서도 트리거 평가 자체가 병목이라는 근거가 따로 있지는 않으므로, 이런 정리는 지연을 고치는 처방이라기보다 인스턴스 용량을 아끼는 예방에 가깝습니다.

러너와 스토리지의 전제도 다릅니다. GHES에는 GitHub 호스티드 러너가 없어 셀프 호스티드 러너만 쓸 수 있습니다. 잡이 큐에서 기다리는 시간이 전적으로 사내 러너 풀의 용량에 달려 있으므로, 러너 사양 절에서 본 표준 러너의 사양·단가 비교는 GHES에 적용되지 않습니다. 로그·아티팩트·캐시는 별도로 준비한 외부 blob storage(S3, Azure Blob 등)에 저장되므로, 캐시의 손익도 그 스토리지의 성능에 따라 달라집니다.

측정 수단은 오히려 늘어납니다. github.com에서는 실행 생성 앞 구간이 블랙박스지만, GHES 관리자는 관리 콘솔의 모니터 대시보드에서 CPU·메모리 포화, 백그라운드 잡 큐 적체, Actions 관련 지표를 직접 볼 수 있습니다. 실행 시작이 느릴 때 워크플로를 고치기 전에 인스턴스 쪽 병목부터 확인할 수 있으므로, 측정을 먼저 하라는 이 글의 순서는 GHES에서도 그대로 적용됩니다.

지금까지 살펴본 기법을 적용 순서대로 정리하면 다음과 같습니다.

1번을 건너뛰고 2번부터 시작하면, 병목이 다른 곳에 있는 워크플로에서 헛수고를 하게 됩니다. 이 순서대로 제 저장소 다섯 곳에 적용하며 측정한 기록을 다음 글에 정리했습니다.

GitHub Actions 워크플로 튜닝: 저장소 다섯 곳의 적용 사례 →

이 포스트는 Claude Code와 정상혁이 함께 작성했습니다.