"소스, 번들, 설치된 버전은 install/doctor 스크립트가 명시적으로 비교해야 해. 성공한 swift build 는 배포 증명이 아냐."
/Applications 에 실제로 뭐가 있어?
빌드했고, closure 를 번들했고, 서명했고, 인스톨러를 돌렸어. 이제 앱이 /Applications 에 앉아 있고. 여기 불편한 질문 하나. 설치된 게 실제로 네가 생각하는 그거야? 인스톨러가 옛 빌드를 복사했을 수도, 서명이 안 먹었을 수도, dylib 이 아직 Homebrew 를 가리킬 수도, 지난주 버전을 보고 있을 수도 있어. 믿음은 검증이 아니야. 그리고 '설치했어' 랑 '설치된 게 맞아' 사이의 틈이 딱 배포 버그가 숨는 데야.
Ashen Reel 은 그 틈을 doctor 로 닫아. 하는 일이라곤 실제 설치된 번들을 심문해서 그게 진짜인지 증명하는 스크립트지. 빌드 출력이 아니라, 사용자가 실행하는 디스크 위의 그것 말이야.
doctor 가 증명하는 것
doctor 는 컴파일이 못 하는 주장들을 검사해. 앱이랑 모든 중첩 Mach-O 바이너리에 걸친 안정된 code signature. Homebrew 런타임 링크가 없는 완전한 내부 의존성 closure. 번들된 커스텀 아이콘. 그리고 소스 빌드랑 설치된 릴리스의 명확한 구분. 검사 하나하나가 바람을 출력에서 읽을 수 있는 사실로 바꿔.
doctor 는 검사 몇 개고, 각각 가정을 통과나 시끄러운 실패로 바꿔.
doctor 가 '완료' 의 진짜 정의야
Track 6 은 'swift build 는 배포 증명이 아냐' 로 열었어. doctor 가 배포 증명이 실제로 어떻게 생겼는지야. 초록 빌드는 코드가 의향이 있다고 말하고, 초록 doctor 는 진짜 타겟의 설치된 아티팩트가 서명됐고, 자립했고, 네가 내려던 버전이라고 말해. Ashen Reel 한텐 '완료' 는 빌드가 통과할 때가 아니야. 실제 Office Mac 의 /Applications 번들에 대해 doctor 가 통과할 때지. 그게 소프트웨어를 컴파일하는 거랑 배포하는 거의 경계야.