Xcode 27 원격 SSH 서명 실패 시 어떻게 해야 하나요? 2026 점검

SSH로 원격 Mac에서 아카이브할 때 서명이 실패하는 개발자를 위한 진단 안내입니다. 실행 사용자와 키체인, 개인 키 접근을 먼저 확인한 뒤 인증서와 프로파일을 점검하고, 실제 아카이브로 수정 여부를 검증하는 절차를 설명합니다.

그래픽 환경에서는 서명되지만 SSH에서 errSecInternalComponent가 나타나나요?

판단: 같은 프로젝트가 그래픽 세션에서는 서명되고 SSH에서만 실패한다면, 인증서를 다시 만들기 전에 작업의 실제 실행 사용자와 로그인 키체인의 잠금 상태, codesign의 개인 키 접근 권한을 확인하세요. 이 오류만으로 원인을 하나로 단정할 수는 없습니다.

이 글은 SSH로 원격 Mac에서 xcodebuild archive를 실행하다 CodeSign 오류를 만난 독립 개발자에게 적합합니다.
자체 macOS 빌드 작업을 관리하는 소규모 팀은 작업 계정과 로그인 환경이 일치하는지 확인할 수 있습니다.
서명 신원은 보이는데 원격 서명이 실패하는 경우에는 개인 키, 인증서, 프로비저닝 프로파일을 차례로 구분해 보세요.

00먼저 실패 지점이 CodeSign인지 확인합니다

빌드가 실패했다는 결과만으로 서명 문제라고 결론 내리면 안 됩니다. 컴파일 오류, CodeSign 단계의 오류, 아카이브 이후 업로드 오류는 조사할 대상이 다릅니다. 로그에서 처음 발생한 오류와 해당 작업 이름을 확인하고, 후속 오류보다 첫 CodeSign 실패를 기준으로 살펴보세요.

로그에서 보이는 상태 먼저 확인할 지점 다음 조치
컴파일 단계에서 실패 소스, 의존성, 빌드 설정 서명 문제로 분류하지 않습니다
CodeSign 작업에서 실패 사용자, 키체인, 서명 신원 아래 순서로 SSH 실행 환경을 점검합니다
아카이브는 끝났지만 업로드 실패 업로드 인증과 전송 단계 서명 문제와 분리해 확인합니다

같은 프로젝트와 빌드 설정으로 그래픽 세션과 SSH 세션의 결과를 비교하세요. 그래픽 환경에서 성공하고 SSH에서만 실패한다면, 프로젝트 설정을 곧바로 바꾸기보다 실행 맥락의 차이를 먼저 확인하는 편이 안전합니다. Apple은 비표준 서명 환경에서 errSecInternalComponent가 나타날 수 있고 키체인 잠금도 가능한 원인이라고 설명하지만, 이 오류가 단일 원인을 가리킨다고 하지는 않습니다. Apple Developer Technical Support의 SSH·CI 서명 오류 안내를 참고하세요.

01첫 단계: SSH 작업의 실행 사용자와 홈 디렉터리를 맞춥니다

SSH 로그인 계정과 빌드 작업이 실제로 사용하는 계정이 다르면, 로그인 키체인과 서명 신원도 기대한 것과 달라질 수 있습니다. 명령을 실행할 수 있다는 사실만으로 그래픽 로그인 세션과 같은 보안 환경이라고 판단하지 마세요. Apple의 Daemons와 Agents 실행 맥락에 관한 설명도 비대화형 작업의 실행 조건을 구분할 때 참고할 수 있습니다.

SSH 접속 직후와 실제 빌드 작업 안에서 다음 값을 확인합니다.

id -un
printf '%s\n' "$HOME"

두 결과가 예상한 macOS 계정과 홈 디렉터리를 가리키는지 확인하세요. 빌드가 CI 작업이나 예약 작업에서 실행된다면, SSH 대화형 셸에서 얻은 결과만으로 실제 작업의 계정을 대신 판단할 수 없습니다.

확인 항목 기록할 값 값이 다르면 살펴볼 곳
실행 사용자 id -un 결과 SSH 계정, CI 작업 계정, sudo 사용 여부
홈 디렉터리 $HOME 결과 작업 환경 변수와 계정 설정
실행 유형 대화형 SSH 또는 비대화형 작업 작업이 시작되는 서비스와 로그인 맥락

02키체인이 잠겼다면 SSH에서 GUI 알림을 기다리지 않습니다

SSH 환경에서는 그래픽 세션의 잠금 해제 대화상자가 나타나지 않거나, 작업이 그 대화상자에 응답하지 못할 수 있습니다. 서명 신원이 저장된 키체인이 빌드 시점에 잠겨 있는지, 그리고 빌드 계정에서 그 키체인을 사용할 수 있는지 확인하세요. 키체인에 저장된 서명 신원에 관한 Apple 설명은 인증서와 개인 키가 서명에 사용되는 신원으로 취급된다는 점을 확인하는 데 도움이 됩니다.

먼저 현재 계정에서 사용하는 키체인 목록과 서명 신원을 확인합니다.

security list-keychains -d user
security find-identity -v -p codesigning

명령 결과에 기대한 키체인이 없거나 서명 신원이 표시되지 않는다면, 엉뚱한 계정이나 키체인을 조사하고 있을 가능성이 있습니다. 목록에 신원이 있어도 작업이 실제로 개인 키에 접근할 수 있다는 뜻은 아닙니다. 잠금 해제 방식은 해당 작업 환경에서 안전하게 관리하고, 키체인 암호를 저장소나 로그, 공개 스크립트에 직접 기록하지 마세요.

키체인 암호를 명령줄 인수에 평문으로 넣거나 빌드 로그에 출력하지 마세요. SSH 세션에서 팝업이 보이지 않는 문제를 해결하려고 비밀 정보를 노출하면, 서명 실패보다 더 큰 보안 사고로 이어질 수 있습니다.

Apple의 인증서 종류와 보호 권고에 따라 인증서와 관련 개인 키를 안전하게 다루세요. errSecInternalComponent는 키체인 잠금과 관련될 수 있지만, 오류 문구만으로 잠금 상태를 확정할 수는 없습니다.

03다음으로 개인 키 접근과 서명 신원을 확인합니다

키체인이 열려 있는데도 codesign이 실패하면, 선택한 신원에 맞는 개인 키가 있는지와 빌드 프로세스가 그 키를 사용할 수 있는지를 살펴보세요. 인증서만 가져오고 대응하는 개인 키를 가져오지 않았다면, 인증서가 목록에 보이더라도 실제 서명은 되지 않을 수 있습니다.

관찰 결과 가능한 해석 확인할 내용
기대한 서명 신원이 보이지 않음 다른 사용자 또는 키체인을 조회할 수 있음 실행 계정, 홈 디렉터리, 키체인 목록
신원은 보이지만 서명에 실패함 개인 키가 없거나 접근 권한이 부족할 수 있음 신원에 대응하는 개인 키와 codesign 접근
신원과 키가 확인되지만 오류가 남음 다른 서명 구성이나 인증서 문제가 있을 수 있음 로그의 첫 실패와 인증서 상태

키체인 접근 권한 설정 하나를 모든 원격 환경의 만능 해결책으로 취급하지 마세요. 키 접근 권한을 바꾸기 전에 실패 로그와 작업 계정, 키체인 위치를 함께 기록하고, 변경은 필요한 범위로 제한하세요. 같은 계정으로 실행한 그래픽 환경과 SSH 환경의 차이가 확인될 때에만 세션 조건을 원인 후보로 좁히는 편이 좋습니다.

04인증서와 프로파일은 증거가 가리킬 때 확인합니다

키체인과 개인 키 접근을 확인한 다음에도 서명이 실패한다면, 오류가 서명 신원이나 앱 식별자 불일치를 가리키는지 살펴보세요. 인증서의 유효 상태, 프로젝트의 Bundle ID와 Team 설정, 선택한 프로비저닝 프로파일의 연결 관계를 확인합니다. Apple의 프로비저닝 프로파일 편집 및 다운로드 안내를 참고해 현재 프로젝트에 맞는 프로파일인지 대조할 수 있습니다.

확인 대상 비교할 내용 서로 다른 문제인 이유
인증서와 신원 빌드가 선택한 신원과 키체인에 있는 신원 신원 선택이나 인증서 상태를 확인합니다
앱 식별 정보 프로젝트의 Bundle ID와 Team 설정 앱 대상과 프로파일의 연결을 확인합니다
프로비저닝 프로파일 프로파일이 현재 앱과 서명 조건에 맞는지 키체인 잠금과는 별도의 구성 문제입니다

키체인 접근 실패와 프로파일 불일치를 한꺼번에 고치려고 인증서를 취소하거나 다시 만들지 마세요. 먼저 빌드 로그에서 어떤 신원이나 설정이 거부되었는지 확인해야 합니다. 앱 권한 정보가 의심되면 Apple의 빌드 산출물 권한 진단 안내와 iOS 코드 서명 문제 색인을 참고하세요.

05조건에 따라 조사 방향을 고릅니다

  • 그래픽 환경에서는 성공하고 SSH에서만 실패한다면, 인증서를 재발급하기 전에 실제 실행 사용자와 키체인 잠금 상태를 확인합니다.
  • SSH와 그래픽 환경 모두에서 서명되지 않는다면, 프로젝트 설정과 선택한 신원도 함께 살펴봅니다.
  • 서명 신원이 보이지만 개인 키 사용에서 실패한다면, 인증서 목록만 반복해서 확인하지 말고 개인 키의 존재와 작업 계정의 접근 가능성을 점검합니다.
  • 오류가 Bundle ID, Team 설정, 프로파일을 직접 지목한다면, 해당 설정의 일치 여부를 확인합니다. 단서가 없다면 인증서나 프로파일을 무작정 새로 만들지 않습니다.

Xcode 버전에 따른 동작 변경이 의심되면 해당 버전의 Apple Xcode 27 릴리스 노트를 함께 확인하세요. 릴리스 노트에 관련 변경이 보이지 않는다는 이유만으로 SSH 키체인 문제가 없다고 단정할 수는 없습니다.

06실제 아카이브로 수정 여부를 확인합니다

원인을 수정한 뒤에는 짧은 진단 명령의 성공만으로 끝내지 마세요. 운영 작업과 같은 사용자, 같은 SSH 실행 맥락, 같은 프로젝트 설정으로 대표적인 아카이브를 다시 실행해야 합니다.

  • [ ] SSH에서 실제 빌드 작업을 실행하는 계정과 $HOME을 기록합니다.
  • [ ] 서명 신원이 들어 있는 키체인과 빌드 시점의 잠금 상태를 확인합니다.
  • [ ] 신원에 대응하는 개인 키가 있고 빌드 프로세스가 사용할 수 있는지 확인합니다.
  • [ ] 오류가 서명 구성 문제를 가리킬 때만 인증서, Bundle ID, Team, 프로파일을 대조합니다.
  • [ ] 같은 작업 맥락에서 xcodebuild archive를 다시 실행하고, 로그에서 CodeSign 단계와 아카이브 결과를 확인합니다.
  • [ ] 서명이 성공하면 작업 계정, 키체인 위치, 재현 조건을 기록하고 비밀 정보의 노출 범위를 줄입니다.

키체인 잠금 해제만 확인하고 끝내지 말고, 실제 아카이브가 끝까지 성공하는지 검증하세요. 반대로 아카이브가 정상 완료되었다면 그 결과와 사용한 실행 맥락을 기록해 다음 환경 변경 뒤에도 비교할 수 있게 합니다.

07원격 빌드 환경을 다시 정리할 때의 선택

프로젝트 설정과 서명 자료는 맞는데 문제가 원격 실행 맥락에 집중된다면, 먼저 SSH 작업에 필요한 계정과 키체인 관리 조건을 정리하세요. 자체 빌드 환경은 장기간 통제하기 좋지만, macOS 업데이트와 계정 권한, 비밀 정보 보호를 직접 관리해야 합니다. 일반 클라우드 환경은 macOS 전용 도구를 그대로 쓸 수 없는 경우가 있고, 로컬 Mac은 장비 비용과 상시 가동 부담이 생깁니다.

빌드가 간헐적이거나 별도 Mac을 구매하기 전에 원격 환경을 검증하려는 경우에는 NUKCLOUD의 원격 Mac 이용 요금을 살펴볼 수 있습니다. 지원되는 작업 환경과 접속 방식은 NUKCLOUD 도움말에서 먼저 확인하세요. 다만 장기간 이어지는 고정 부하나 물리 장비 연결이 필수라면 자체 Mac이 더 적합할 수 있습니다. 임시 빌드와 재현 테스트가 주된 목적일 때 원격 Mac을 비교 대상으로 두는 것이 합리적입니다.