"금요일 밤, 고객사 CTO에게서 전화가 왔습니다. '방금 사내 맥을 macOS 27로 올렸더니 사내 앱 배포 스크립트가 전부 멈췄어요. 월요일 아침까지 못 고치면 200명이 일을 못 합니다.'"
— 어느 프리랜서 개발자가 받은 실제 문의, 그리고 그가 하룻밤에 100만 원을 받은 이유
애플이 macOS 27에서 오래된 명령어들을 조용히 정리하기 시작하면서, 수많은 맥 앱 배포사·사내 IT팀·MSP(IT 아웃소싱 업체)의 자동화 스크립트가 예고 없이 멈추는 사고가 터지고 있습니다. 특히 dmg(디스크 이미지) 파일을 만들고 배포할 때 쓰던 hdiutil의 핵심 옵션들이 폐기(deprecated)되면서, "어제까지 잘 돌던 배포가 오늘 갑자기 에러"라는 사례가 급증하고 있죠.
여기서 기회가 생깁니다. 이 문제는 "어렵지만 범위가 좁고, 급하고, 값을 매기기 쉬운" 완벽한 유료 대행 아이템입니다. 그리고 비전공자도 AI를 도구로 쓰면 충분히 진단·수리 서비스를 만들어 팔 수 있습니다. 오늘은 그 방법을 5단계로 정확히 보여드리겠습니다.
도대체 뭐가 멈추는 걸까? (문제의 정체)
맥 앱은 보통 .dmg라는 디스크 이미지 파일로 배포됩니다. 이 dmg를 자동으로 만들고, 아이콘 배치하고, 서명하는 과정에서 오랫동안 hdiutil이라는 명령어가 쓰였어요. 문제는 macOS 27부터 hdiutil의 일부 하위 기능(특히 파티션·포맷 관련 동작)이 diskutil 계열로 이전되거나 폐기되면서, 옛날 스크립트가 "명령을 찾을 수 없음" 또는 "지원하지 않는 옵션" 에러로 죽는다는 점입니다.
당신이 팔 것은 "맥 전문가"가 아닙니다. "멈춘 스크립트를 다시 돌게 만드는 진단 리포트 + 수정된 스크립트"라는 결과물입니다. 고객은 코드 실력이 아니라 "월요일 아침에 배포가 되느냐"에 돈을 냅니다.
누가, 왜 100만 원을 낼까?
이 서비스의 고객은 명확합니다. "배포가 멈추면 하루에 수백만 원씩 손해 보는 사람들"이죠.
비전공자를 위한 5단계 실전 가이드
1단계 — 스크립트와 에러 로그부터 그대로 받기
고객에게 "배포에 쓰는 스크립트 파일(주로 build.sh, package.sh, CI 설정 yml)과 실패했을 때 터미널에 뜬 빨간 글씨 전체를 복사해서 주세요"라고 요청합니다. 이 두 가지만 있으면 90%는 원인이 잡힙니다. 코드를 못 읽어도 괜찮습니다 — 다음 단계에서 AI가 읽어줄 테니까요.
2단계 — AI에게 '폐기 진단표'를 시키기
받은 스크립트를 AI(Claude 등)에 붙여넣고 이렇게 지시합니다.
이 표가 바로 고객에게 줄 진단 리포트의 초안이 됩니다. AI가 "검증 필요"라고 한 부분만 4단계에서 실제로 돌려보면 되니, 리스크도 관리됩니다.
3단계 — 대체 명령으로 마이그레이션
진단표를 근거로 AI에게 "이 스크립트를 macOS 27에서 동작하도록 수정하되, 구버전 맥에서도 깨지지 않도록 버전 분기를 넣어줘"라고 요청합니다. 여기서 핵심은 "무조건 최신으로 갈아엎기"가 아니라, 고객사가 여러 버전의 맥을 섞어 쓰는 현실을 반영하는 것입니다. 이 디테일 하나가 아마추어와 프로를 가릅니다.
4단계 — 가상머신에서 실제로 돌려보기
수정한 스크립트를 macOS 27 테스트 환경(가상머신 또는 여분의 맥)에서 실행해 dmg가 진짜로 만들어지는지 눈으로 확인합니다. "AI가 고쳐줬으니 되겠지"는 금물 — 고객 앞에서 다시 터지면 신뢰가 무너집니다. 이 검증 과정이 있기에 100만 원이라는 값이 정당화됩니다.
고객의 실제 운영 환경에서 바로 테스트하지 마세요. 항상 복사본·테스트 환경에서 검증한 뒤 납품합니다. 서명(코드사이닝) 인증서 같은 민감 정보는 절대 받아두지 말고, 고객이 직접 넣는 자리만 표시해 줍니다.
5단계 — 리포트로 납품하고 청구하기
단순히 고친 파일만 던지면 "이거 몇 줄 바꾼 거 아니에요?"라는 소리를 듣습니다. 대신 ①진단표 ②변경 전/후 비교 ③재발 방지 체크리스트를 담은 2~3장짜리 리포트를 함께 줍니다. 고객은 이 문서를 보고 "전문가에게 제대로 맡겼다"고 느끼고, 이 리포트가 다음 고객사 소개로 이어집니다.
왜 이 아이템이 '지금' 좋은가
운영체제의 명령어 폐기는 매년 반복됩니다. 올해는 hdiutil이지만, 내년엔 또 다른 명령이 사라지죠. 즉 이건 한 번 벌고 끝나는 유행이 아니라, "OS가 바뀔 때마다 다시 발생하는 반복 수요"입니다. 한 번 신뢰를 쌓은 고객은 다음 대격변 때 또 당신을 찾습니다.
좁은 문제 · 높은 긴급도 · 명확한 결과물 · 반복 수요. 비전공자가 AI를 무기로 "진단·수리 대행"이라는 서비스를 만들기에 이보다 좋은 조건은 드뭅니다. 필요한 건 화려한 코딩 실력이 아니라, 문제를 서비스로 포장하는 감각과 검증하는 성실함입니다.
물론 여기까지 읽고 "AI에게 뭐라고 시켜야 정확한 진단이 나오는지, 검증 환경은 어떻게 꾸리는지, 견적서와 리포트는 어떤 형식으로 써야 100만 원이 자연스러운지"가 궁금하실 겁니다. 그 실제 프롬프트 설계·검증 루틴·고객 응대 대본까지 손에 잡히게 익히고 싶다면, 투더제이(TTJ) 코딩클래스 정규반에서 이런 "AI 활용 실전 수익화 프로젝트"를 처음부터 끝까지 함께 만들어 봅니다. 비전공자가 첫 대행 건을 수주하는 과정을 단계별로 다루니, 오늘 글이 흥미로웠다면 한 번 들여다보셔도 좋겠습니다. 🙂
※ 이 글의 명령어·버전 정보는 이해를 돕기 위한 예시이며, 실제 작업 시에는 반드시 최신 공식 문서와 테스트 환경에서 검증하세요.