codesign errSecInternalComponent: 2026년 원격 서명은 어떻게 고칠까?

errSecInternalComponent는 원인이 하나로 고정된 오류가 아닙니다. Apple의 코드 서명 자료에서도 비표준 로그인 환경에서는 Keychain 접근, 개인 키, 인증서 신뢰 사슬을 서로 나누어 확인해야 합니다. 특정 Xcode 버전의 단일 회귀라고 단정할 공식 근거도 없습니다.

먼저 다음 정보를 지웅하지 말고 기록합니다.

• 실제 서명 명령을 실행한 macOS 사용자 이름
• 그래픽 터미널인지 SSH인지, 또는 빌드 실행기인지
• 사용한 Keychain의 실제 경로
• codesign, xcodebuild, Archive 중 처음 실패한 단계
• 대상 앱의 Bundle ID와 서명 신원의 일부 식별 정보
• 오류 전문에서 암호, Team ID, 인증서 해시, 파일 경로를 탈락시킨 사본

그 뒤 같은 사용자, 같은 산출물, 같은 서명 신원으로 그래픽 터미널과 SSH에서 최소 테스트를 실행합니다.

whoami
security list-keychains
security default-keychain
codesign --verify --verbose=4 "/경로/테스트앱.app"

왜 그래픽 터미널에서는 되고 SSH에서는 실패합니까?
두 환경이 같은 사용자를 표시하더라도 로그인 세션이 Keychain을 여는 방식과 대화형 승인 상태가 다를 수 있습니다. 그래픽 환경만 성공하면 우선 Keychain 잠금 또는 접근 승인 문제로 좁힙니다. 두 세션 모두 실패하면 인증서와 개인 키의 짝, 중복 신원, 신뢰 사슬을 먼저 봅니다.

security find-identity의 결과만 보고 “인증서가 있으니 정상”이라고 판단하면 안 됩니다. 서명에는 인증서만 필요한 것이 아니라 해당 인증서와 짝을 이루는 개인 키, 그리고 대상과 맞는 프로비저닝 프로파일이 함께 필요합니다. Apple의 인증서 종류 안내는 배포용 인증서와 개발용 인증서의 용도를 구분합니다.

security find-identity -v -p codesigning
security find-certificate -a -p "/경로/빌드용.keychain-db"
security find-key -a "/경로/빌드용.keychain-db"

다음 네 가지를 따로 대조합니다.

• 인증서: 만료되지 않았고 대상 배포 방식에 맞는지 확인합니다.
• 공개 키: 인증서 안에 포함된 키입니다.
• 개인 키: 실제 서명 작업에서 사용되며, 인증서와 짝이 맞아야 합니다.
• 디지털 신원: 인증서와 대응 개인 키가 결합된 서명 가능한 상태입니다.

security find-identity에 인증서가 보이지만 개인 키가 없으면 서명은 완료되지 않습니다. 같은 이름의 오래된 인증서가 여러 개 있거나, 인증서는 한 Keychain에 있고 개인 키는 다른 Keychain에 있는 경우도 구분해야 합니다.

인증서에 짝을 이루는 개인 키가 있는지 어떻게 확인합니까?
Keychain 접근 앱에서 인증서 항목을 펼쳐 개인 키가 연결되어 있는지 확인하거나, 명령행에서 인증서와 개인 키를 각각 조회합니다. 출력에는 실제 암호나 전체 해시를 글에 복사하지 말고, 내부 기록에서는 앞뒤 일부만 남겨 비교합니다. Apple의 인증서 기술 설명은 인증서 내부의 키 관계를 확인할 때 기준으로 사용할 수 있습니다.

그래픽 세션만 성공했다면 서명 도구가 올바른 Keychain을 보고 있는지부터 고정합니다. 작업을 실행하는 사용자 계정에서 다음과 같이 명시적으로 확인합니다.

security list-keychains -d user
security default-keychain -d user
security unlock-keychain -p "<일회성_입력값>" "/경로/빌드용.keychain-db"
security show-keychain-info "/경로/빌드용.keychain-db"

실제 운영 스크립트에서는 암호를 명령행 인자나 저장소에 직접 넣지 않습니다. 비밀 저장소에서 일시적으로 주입하고, 프로세스 목록과 로그에 남지 않는 방식으로 구성합니다. Keychain을 해제하는 초기화 단계는 서명 명령과 같은 빌드 사용자 문맥에서 실행해야 합니다.

그다음 서명 도구가 필요한 항목에만 접근하도록 설정합니다. 접근 제어를 바꾸기 전에는 현재 설정을 백업하고, 범위를 넓히는 변경은 테스트 Keychain에서 먼저 검증합니다. 잘못된 접근 설정은 다른 앱이나 자동 작업의 키 사용 범위까지 바꿀 수 있으므로, 실패 시 기존 Keychain으로 되돌릴 수 있어야 합니다. Keychain의 저장과 접근 모델은 Apple Keychain 문서에서 확인할 수 있습니다.

SSH에서만 실패한다면 인증서를 다시 만들어야 합니까?
대부분은 바로 다시 만들 필요가 없습니다. 그래픽 세션에서 같은 인증서와 개인 키로 서명이 되고 SSH에서만 실패한다면, 먼저 Keychain 잠금과 접근 승인, 사용자 문맥을 복구합니다. 두 세션 모두 개인 키가 없거나 인증서가 만료되었거나 신뢰 사슬이 끊긴 경우에만 재가져오기나 교체를 검토합니다.

codesign --verify가 통과해도 iOS 또는 macOS 배포가 정상화되었다는 뜻은 아닙니다. 실제 Archive에서는 중첩된 프레임워크, 확장 프로그램, 권한 설정, 프로비저닝 프로파일, 배포용 신원이 함께 처리됩니다.

다음 순서로 범위를 넓힙니다.

1. 테스트 앱 번들에 최소 codesign 검증을 실행합니다.
2. 같은 사용자로 xcodebuild archive를 실행합니다.
3. 생성된 Archive 안의 앱과 중첩 코드를 검증합니다.
4. 올바른 entitlements와 프로비저닝 프로파일이 포함되었는지 확인합니다.
5. 배포용 내보내기와 업로드 전 검증을 실행합니다.

codesign --display --verbose=4 "/경로/테스트앱.app"
codesign --verify --deep --strict --verbose=4 "/경로/테스트앱.app"
xcodebuild -workspace "<작업공간>.xcworkspace" \
  -scheme "<구성표>" \
  -configuration Release \
  -archivePath "/경로/<아카이브>.xcarchive" archive

프로파일은 앱의 Bundle ID, 팀, 권한과 맞아야 합니다. 배포 프로파일의 생성 조건은 Apple App Store 프로비저닝 프로파일 안내에서 확인하고, 오래된 프로파일을 무조건 삭제하기보다 현재 빌드가 참조하는 파일을 먼저 기록합니다. 프로파일을 편집하거나 내려받고 삭제하는 기준은 Apple의 프로파일 관리 안내를 따릅니다.

security find-identity에는 신원이 보이는데도 왜 서명이 실패합니까?
해당 명령은 검색 가능한 서명 신원을 보여줄 뿐, 현재 대상의 권한과 프로파일, 중첩 코드, Keychain 접근이 모두 맞다는 뜻은 아닙니다. 따라서 인증서 목록 확인 뒤에는 개인 키 연결, Keychain 잠금 상태, entitlements, 프로파일의 Bundle ID를 실제 Archive 결과와 대조해야 합니다. 빌드 설정의 서명 관련 값은 Apple Xcode 빌드 설정 참고 자료에서 확인합니다.

원격 서명은 한 번 성공하는 것보다 사람이 없는 상태에서 다시 성공하는지가 중요합니다. 다음 검사는 원격 맥 iOS 서명 환경 점검 안내와 함께 운영 기록으로 남길 수 있습니다.

• [ ] 그래픽 세션에서 성공한 사용자와 SSH 사용자가 동일합니다.
• [ ] SSH에서 기본 Keychain과 빌드용 Keychain 경로를 확인했습니다.
• [ ] 인증서와 대응 개인 키가 같은 서명 신원으로 조회됩니다.
• [ ] 오래된 중복 인증서가 현재 빌드 선택을 방해하지 않습니다.
• [ ] Keychain 초기화와 잠금 해제 절차가 비밀을 로그에 남기지 않습니다.
• [ ] codesign 최소 검증 뒤 실제 Archive까지 통과했습니다.
• [ ] 앱 권한, 중첩 코드, 프로비저닝 프로파일을 확인했습니다.
• [ ] 그래픽 세션을 종료한 뒤 SSH로 다시 연결해 서명했습니다.
• [ ] 빌드 실패 후 재시도해 초기화 절차가 다시 작동합니다.
• [ ] 호스트를 재시작한 뒤 사람의 승인 창 없이 같은 작업을 완료했습니다.
• [ ] 개인 키 교체나 인증서 폐기 전 회복 가능한 백업을 보관했습니다.

그래픽 세션을 종료한 뒤에도 자동 서명을 유지하려면 어떻게 합니까?
로그아웃 후 SSH 재접속, 작업 실패 후 재시도, 호스트 재시작을 각각 별도 상태로 검사해야 합니다. 매번 Keychain이 잠겨 서명이 멈춘다면 해당 환경은 아직 무인 운영에 적합하지 않습니다. 인증서를 다시 만드는 것보다 빌드 사용자의 Keychain 초기화와 복구 단계를 먼저 수정해야 합니다.

현재 방식이 개인 PC나 임시 실행기에 의존한다면, 그래픽 세션이 사라질 때 Keychain 상태가 달라지고, SSH 재접속마다 환경을 다시 맞춰야 하며, 발행 직전에 수동 승인 창을 처리해야 하는 문제가 남습니다. 장시간 켜 둔 개인 맥은 전원과 저장 공간 관리도 별도로 필요합니다.

반대로 NUKCLOUD 원격 맥 환경은 지속적으로 접속할 수 있는 실제 맥을 별도 작업 환경으로 운영하려는 경우에 검토할 수 있습니다. 다만 장기간 고정 부하가 계속되거나 물리 장치 연결이 필수라면 직접 보유한 맥이 더 적합할 수 있습니다. 임시 빌드, 원격 SSH 작업, 독립 개발자의 배포 검증처럼 사람이 없는 상태의 재현성이 중요한 경우에만 원격 맥 임대를 비교하는 편이 안전합니다.

명령행에서 최소 서명이 성공한 뒤에는 반드시 로그아웃, 재접속, 실제 Archive, 재시작 순서로 마지막 검증을 진행해야 합니다. 그 과정에서 수동 Keychain 승인에 계속 의존한다면, 인증서부터 폐기하기보다 사용자와 Keychain 상태를 유지할 수 있는 상시 원격 빌드 환경으로 옮길 시점인지 평가해야 합니다.