GitHub Actions macOS OpenSSL 4 변경 전 확인할 것? 2026 점검표

2026년 11월 2일부터 8일까지 GitHub Actions의 일부 macOS runner에서 기본 openssl 명령을 OpenSSL 4로 바꾸는 단계적 배포가 계획되어 있습니다. GitHub 공지를 기준으로 먼저 PATH를 통해 버전을 지정하지 않고 실행하는 부분을 찾고, 인증서·키·서명·TLS와 원시 의존성 빌드를 실제 작업에서 검증하세요. OpenSSL 3이 필요한 작업은 명시적으로 해당 버전을 선택해야 합니다.

이 글은 기업 macOS CI 이미지와 도구 체인을 관리하는 IT·플랫폼 책임자를 위한 내용입니다.
인증서나 서명 스크립트를 유지한다면 기본 명령과 버전 가정을 확인하세요.
원시 라이브러리를 빌드하는 팀은 대표 작업으로 호환성과 되돌리기 경로를 검증하세요.

마지막 업데이트: 2026년 10월 23일. 날짜와 대상 범위는 GitHub runner-images 변경 공지를 기준으로 확인했습니다. 배포 일정은 호환성 검증에 따라 조정될 수 있으므로 게시 후에도 공지와 이미지 변경 기록을 다시 확인해야 합니다.

OpenSSL 4 GitHub Actions macOS CI 마이그레이션의 대상부터 좁히세요

공지에 적힌 대상은 macOS 26 Intel 및 Arm64 runner와 Xcode 27 Arm64 runner입니다. 해당 환경에서 버전을 지정하지 않은 openssl 명령의 기본 버전을 OpenSSL 4로 전환할 계획이며, OpenSSL 3은 버전이 명시된 Homebrew 경로로 계속 사용할 수 있다고 안내합니다. 이는 계획이지 이미 완료된 변경은 아닙니다. 공식 변경 공지

따라서 모든 macOS 작업이 바뀐다거나 Linux·Windows runner까지 영향을 받는다고 일반화하지 마세요. 먼저 팀에서 실제 사용하는 runner 종류와 이미지, 작업별 실행 경로를 확인해야 합니다. GitHub는 호스팅 runner의 종류와 사용 기준을 runner 참고 문서에서 설명하고, 이미지에 포함된 소프트웨어 목록을 확인하는 방법도 별도 안내합니다.

변경 판단은 runner 라벨만으로 끝낼 수 없습니다. 같은 라벨을 사용하더라도 실제 작업 시점의 이미지와 설치 도구 상태가 중요합니다. 작업 로그에 버전과 실행 경로를 남겨야 공지된 대상과 팀 환경이 실제로 겹치는지 판별할 수 있습니다.

주의: 공지된 적용 날짜는 확정 완료일이 아닙니다. 공지가 수정되거나 이미지 내용이 바뀌면 대상, 배포 상태, OpenSSL 3 사용 방법을 다시 대조하세요.

기본 명령을 호출하는 숨은 경로가 영향 범위입니다

YAML 파일에서 openssl을 검색하는 것만으로는 충분하지 않습니다. 호출이 셸 스크립트, 빌드 도구, 재사용 작업 또는 의존성 설치 스크립트에 들어 있을 수 있습니다. 작업 정의에서 실제 스크립트까지 호출 경로를 따라가고, 버전을 별도로 지정하지 않은 실행과 버전별 실행을 구분하세요.

조사 결과에는 적어도 호출 파일, 실행 작업, runner 이미지, 명령이 선택한 바이너리 경로와 버전, 생성 산출물을 기록하세요. 이렇게 해야 실패가 기본 버전 변경 때문인지, 다른 이미지 변경이나 스크립트 수정 때문인지 나누어 볼 수 있습니다.

GitHub Actions에서 진단 결과를 로그에 남길 때는 워크플로 명령을 사용할 수 있습니다. 경로를 추가하거나 변경하는 경우에는 GitHub의 PATH 관련 워크플로 명령 안내를 따르세요. 설정이 한 작업에만 필요한지 후속 단계 전체에 적용해야 하는지도 확인해야 합니다.

명령과 산출물의 버전 가정을 분리해 검토하세요

OpenSSL 3에서 동작하는 옵션, 기본값, 버전 판별, 명령 출력 파싱이 있다면 OpenSSL 4에서도 같을 것이라고 가정하지 마세요. 그렇다고 공지에 언급된 차이만으로 특정 프로젝트가 반드시 실패한다고 단정해서도 안 됩니다. 각 항목은 재현과 테스트가 필요한 위험 신호로 다루는 편이 정확합니다.

OpenSSL 명령 형식 옵션 문서와 변경 공지를 대조해 사용 중인 옵션과 출력 처리 방식을 확인하세요. 특히 스크립트가 버전 문자열을 비교하거나 명령 결과의 특정 문구를 파싱하는 경우, 실제 runner에서 결과를 수집해 기대값과 비교해야 합니다.

발견한 의존성	확인할 증거	판단 기준
PATH를 통해 실행하는 `openssl`	작업 로그의 버전과 실행 경로	실행 파일이 의도한 버전인지 확인합니다
버전별 Homebrew 경로를 쓰는 작업	설치 정보, 경로, 빌드 로그	OpenSSL 3이 필요한 단계가 실제로 해당 경로를 참조하는지 확인합니다
특정 옵션이나 출력에 의존하는 스크립트	명령 종료 상태, 출력, 산출물	기존 테스트가 요구하는 결과와 일치하는지 검증합니다
링크 라이브러리를 사용하는 원시 의존성	컴파일 및 링크 로그	헤더와 라이브러리 경로가 의도한 버전에 연결되는지 확인합니다

OpenSSL 3을 고정해야 한다면 이름만 지정해 두지 말고 실행 파일과 라이브러리 경로까지 검증하세요. Homebrew의 openssl@3 정보를 참고해 설치 경로를 확인한 뒤, 작업 로그와 컴파일 결과가 그 경로를 실제로 사용하는지 확인할 수 있습니다.

인증서·서명·TLS 작업은 결과물까지 확인하세요

인증서 생성, 개인 키 처리, 코드 서명, TLS 연결은 기본값 변화가 결과물이나 후속 작업에 영향을 주는지 살펴야 하는 영역입니다. 작업이 성공으로 끝나는지만 확인하면 인증서 형식, 서명 검증, 다음 단계의 소비 과정에서 생기는 문제를 놓칠 수 있습니다.

Apple은 코드 서명 인증서의 작동 방식과 macOS 배포용 서명 코드 생성 방법을 문서화하고 있습니다. 이를 팀의 배포 절차와 대조하되, 문서에 있는 일반 예제만으로 프로젝트의 호환성을 증명했다고 간주하지 마세요. 배포 산출물과 서명 검증, 후속 설치 또는 검증 단계까지 팀 테스트로 확인해야 합니다.

원시 의존성 빌드에서는 설치 스크립트가 특정 OpenSSL 버전이나 라이브러리 위치를 고정하는지 확인하세요. 컴파일 로그에 선택된 헤더와 라이브러리 경로가 드러나는지 살펴보고, 문제가 의심되는 의존성은 대표 워크플로와 분리해 빌드하세요. 공개 저장소 한 곳의 해결 방법을 팀 전체의 필수 조치로 일반화하지 않는 것도 중요합니다.

변경 전 검증 결과로 고정·시험·되돌리기를 선택하세요

전환 여부는 막연한 안정성 추정이 아니라 팀의 작업별 증거로 결정해야 합니다. 대표적인 빌드와 서명 작업을 현재 환경과 변경을 반영한 시험 환경에서 실행하고, 명령 로그, 이미지 정보, 산출물 검증 결과를 함께 보관하세요. 한 작업에서 성공했다고 전체 워크플로가 검증된 것은 아닙니다.

대응 선택	적용 조건	진행 방식
기본 버전으로 시험	OpenSSL 4에서 정상 동작하는지 아직 확인하지 못한 경우	격리된 시험 작업에서 대표 빌드와 결과물 검증을 수행합니다
OpenSSL 3 고정	작업이 OpenSSL 3을 필요로 한다는 테스트 근거가 있는 경우	버전별 Homebrew 경로를 명시하고 실행 경로와 링크 결과를 확인합니다
영향 작업 격리 후 되돌리기	검증에서 오류가 재현되거나 산출물 검증에 실패한 경우	영향 작업만 분리하고 팀의 기존 되돌리기 절차를 적용합니다

검증 항목	합격으로 볼 근거	남길 기록
runner와 이미지	실제 작업의 runner 종류와 이미지 정보가 확인됨	작업 로그와 이미지 소프트웨어 정보
명령 선택	의도한 `openssl` 실행 파일과 버전이 확인됨	명령 출력과 실행 경로
인증서·서명·TLS	팀이 요구하는 검사와 후속 소비가 통과함	검증 결과와 산출물 정보
원시 의존성	빌드가 의도한 헤더·라이브러리를 참조함	컴파일 및 링크 로그
회귀 대응	실패 시 영향 작업을 격리하고 복구할 방법이 확인됨	되돌리기 절차와 담당자

전환 후 문제를 발견하면 처음부터 모든 작업을 바꾸기보다 영향을 받는 호출을 분리하세요. 버전 고정이 필요한 작업은 경로를 명시하고, 변경과 무관한 작업은 별도로 검증해 불필요한 범위 확장을 막습니다. 기존 구매·임대 방식을 포함해 Mac 환경 선택 기준을 검토할 때도 실제 시험에서 확인한 요구사항을 기준으로 삼으세요.

FAQ

공지된 날짜가 지나면 모든 macOS 작업이 즉시 바뀌나요?

아닙니다. 공지에는 대상 runner와 단계적 배포 계획이 제시되어 있으며, 일정은 호환성 검증에 따라 달라질 수 있습니다. 날짜가 지났다는 이유만으로 모든 이미지가 같은 상태라고 판단하지 마세요. 실제 작업 로그, 이미지 소프트웨어 목록, 공지의 업데이트 내용을 확인한 뒤 팀의 대상 환경과 일치하는지 판정해야 합니다.

버전을 지정하지 않은 호출은 어떻게 찾을 수 있나요?

워크플로 YAML의 openssl 검색에서 시작해 셸 스크립트, 빌드 스크립트, 재사용 작업, 의존성 설치 단계까지 추적하세요. 각 호출에서 버전을 직접 지정하는지 구분하고, 실제 runner에서 버전과 실행 경로를 출력하게 하세요. 라벨이나 설정 파일만으로 실행 파일을 추측하지 말고, 대표 작업의 로그를 증거로 보관해야 합니다.

OpenSSL 3이 필요한 작업은 어떤 방식으로 고정하나요?

테스트에서 OpenSSL 3 의존성이 확인된 작업에만 버전별 Homebrew 경로를 명시하세요. 경로를 설정한 다음 실제 호출이 그 실행 파일을 선택하는지, 원시 의존성의 헤더와 라이브러리도 의도한 위치를 참조하는지 확인해야 합니다. 설정 변경 뒤에는 빌드뿐 아니라 서명, 산출물 검사와 후속 작업까지 검증하고, 실패 시 되돌릴 절차도 준비하세요.

인증서와 서명 작업은 무엇을 성공 기준으로 삼아야 하나요?

명령이 오류 없이 끝났는지만으로는 충분하지 않습니다. 인증서 생성 및 검사, 키 처리, 코드 서명, TLS 관련 작업의 결과가 팀의 요구와 일치하는지 확인하세요. 생성된 산출물의 검증과 후속 단계의 소비도 시험 범위에 포함해야 합니다. Apple 문서로 절차를 대조하되, 프로젝트별 호환성은 실제 워크플로와 감사 기록으로 판단하세요.

프로덕션 워크플로를 바로 수정하거나 배포 후에만 문제를 찾는 방식은 영향 범위를 분리하기 어렵고, 로그와 비교 기준이 없으면 원인을 특정하기도 힘듭니다. 반면 실제 Mac 환경을 격리된 검증에 사용하면 운영 중인 작업을 건드리지 않고 빌드와 도구 체인을 시험할 수 있습니다. 이미 보유한 Mac이 있고 장기간 고정된 부하를 처리하거나 물리 장치 연결이 필요하다면 직접 운영하는 편이 맞을 수 있습니다. 임시 검증 용량이 필요한 경우에는 zshmac의 서울 Mac 환경을 확인하고, 팀의 접근 권한과 시험 절차가 요구를 충족하는지 검토한 뒤 클라우드 맥 임대를 결정하세요.

자주 묻는 질문

GitHub Actions macOS runner의 OpenSSL 4 기본 전환은 언제 예정되어 있나요?

GitHub runner-images 공지는 2026년 11월 2일부터 8일까지 단계적으로 배포할 계획이라고 안내합니다. 대상은 macOS 26 Intel 및 Arm64 runner와 Xcode 27 Arm64 runner이며, 호환성 검증에 따라 일정이 바뀔 수 있습니다. 따라서 날짜만 보고 전환 완료로 간주하지 말고 공지와 실제 runner 이미지의 소프트웨어 목록, 작업 로그를 함께 확인하세요.

워크플로가 PATH를 통해 OpenSSL 3을 호출하는지 어떻게 확인하나요?

YAML에서 시작해 셸 스크립트, 빌드 스크립트, 재사용 작업까지 openssl 호출을 찾아보세요. 버전을 지정하지 않은 호출은 runner에서 PATH가 가리키는 실행 파일에 따라 달라질 수 있습니다. 해당 작업에서 openssl 버전과 실행 경로를 로그에 남기고, runner 이미지의 실제 소프트웨어 정보와 대조하세요. 이미지 이름만으로 설치 상태를 추측하지 않는 것이 중요합니다.

OpenSSL 3에 의존하는 macOS CI 작업은 버전을 어떻게 고정해야 하나요?

먼저 의존 작업이 OpenSSL 3을 반드시 필요로 하는지 테스트로 확인하세요. 필요하다면 공지에 나온 버전별 Homebrew 경로를 사용하도록 설정하고, 명령이 실제로 해당 실행 파일과 라이브러리를 참조하는지 로그로 검증합니다. PATH나 라이브러리 경로를 변경했다면 뒤이어 실행되는 빌드 단계에도 영향이 없는지 확인하세요. 고정 후에도 결과물 검증과 실패 시 원래 경로로 되돌리는 절차를 남겨야 합니다.

OpenSSL 4 변경 전에 어떤 인증서와 서명 작업을 검증해야 하나요?

인증서 생성과 검사, 개인 키 처리, 코드 서명, TLS 연결을 수행하는 실제 워크플로를 골라 검증하세요. 명령이 성공했는지만 보지 말고 생성된 산출물의 형식, 서명 검증 결과, 다음 단계에서의 소비 여부까지 확인해야 합니다. Apple의 서명 인증서 설명과 배포 서명 안내를 참고하되, 문서의 예제가 팀 프로젝트의 호환성을 보장한다고 간주하지 마세요. 팀의 테스트와 감사 기록이 판정 기준입니다.