DAO-Code가 macOS에서 열리지 않나요? 권한 및 PATH 수정 안내 (2026)

공식 package.json의 요구 조건은 385~410행에 따로 정의되어 있습니다. 따라서 DAO-Code가 macOS에서 열리지 않을 때는 무작정 다시 설치하지 말고, 먼저 which, 실제 파일 경로, 버전 명령으로 설치 결과를 확인해야 합니다. 그다음 PATH, 실행 권한, macOS 보안 차단, npm 권한, API 키 순서로 좁혀 가면 됩니다. sudo 사용, 보안 기능 전체 해제, 반복 재설치는 마지막에도 기본 해법이 아닙니다.

이 글을 읽어야 하는 사용자

dao를 실행했는데 명령어를 찾지 못하는 사용자에게 맞습니다.
macOS가 실행 파일을 막거나 알 수 없는 개발자라고 표시하는 사용자도 대상입니다.
npm 설치 중 권한 오류가 발생했거나, 실행은 되지만 모델 인증에 실패하는 개발자도 단계별로 확인할 수 있습니다.

오류 문구로 수리 위치부터 나누기

아래처럼 원본 오류를 먼저 보관하십시오. 화면을 캡처할 때는 API 키, 사용자 이름, 로컬 경로의 일부를 가려야 합니다.

DAO-Code 공식 설치 스크립트는 운영 체제와 칩 구조에 맞는 실행 파일을 내려받고 기본 경로에 기록하도록 구성되어 있습니다. 다만 설치가 끝났다고 해서 현재 셸의 PATH가 자동으로 갱신된다고 단정할 수는 없습니다. 공식 설치 스크립트와 공식 설치 안내를 서로 대조하십시오.

첫 단계: 설치 결과와 셸 경로 확인하기

터미널에서 다음 명령을 차례로 실행하십시오.

which dao
command -v dao
uname -m
echo "$SHELL"

which dao와 command -v dao가 아무것도 출력하지 않으면 두 경우를 나눠야 합니다.

• 실행 파일이 실제로 없는 경우: 설치 스크립트의 종료 메시지와 기본 설치 경로를 다시 확인합니다.
• 파일은 있지만 명령어를 찾지 못하는 경우: PATH가 현재 셸에 반영되지 않은 것입니다.

먼저 전체 경로로 직접 실행해 보십시오.

/실제/설치/경로/dao --version

이 방식은 임시 진단입니다. 전체 경로 실행이 성공해도 PATH가 고쳐진 것은 아닙니다. 영구 수정 전에는 현재 셸이 어떤 파일을 읽는지 확인하십시오.

printf '%s\n' "$PATH"
ls -la ~/.zshrc ~/.bashrc 2>/dev/null

기본 셸이 zsh라면 ~/.zshrc, 다른 셸이라면 해당 설정 파일에 실행 파일이 있는 디렉터리를 추가합니다.

export PATH="/실제/설치/경로:$PATH"

위 명령은 현재 터미널에서만 유지됩니다. 설정 파일에 같은 내용을 추가한 뒤 새 터미널을 열고 다음으로 검증하십시오.

which dao
dao --version

설정 파일을 수정했는데도 새 터미널에서 사라진다면 잘못된 파일을 편집했거나, 셸 초기화 과정에서 PATH를 다시 덮어쓰는 설정이 있는 것입니다. 이때는 설치를 반복하지 말고 echo "$SHELL" 결과와 설정 파일의 PATH 줄을 비교하십시오.

두 번째 단계: 실행 권한과 macOS 보안 차단 분리하기

permission denied는 파일의 실행 비트가 없다는 뜻일 수 있습니다. 다음으로 파일 상태를 확인합니다.

ls -l /실제/설치/경로/dao

소유자에게 실행 권한이 없다면 해당 파일에만 최소 범위로 권한을 추가합니다.

chmod u+x /실제/설치/경로/dao

이후 다시 버전을 확인합니다. chmod 뒤에도 알 수 없는 개발자 경고가 계속되면 실행 권한 문제가 아니라 macOS의 격리 속성 또는 출처 검증 문제일 수 있습니다.

Apple의 보안 설명에 따르면 Gatekeeper는 내려받은 앱과 실행 파일의 출처 및 서명을 확인합니다. Apple의 플랫폼 보안 설명을 먼저 읽고, 파일이 공식 저장소에서 온 것인지 확인하십시오. 출처가 불명확한 파일에는 허용 절차를 적용하지 않는 것이 맞습니다.

출처를 확인한 공식 파일인데 처음 실행만 막힌 경우에는 시스템 설정의 개인정보 보호 및 보안 화면에서 해당 실행 시도를 검토할 수 있습니다. Apple의 알 수 없는 개발자 실행 안내에 나온 제한된 절차만 사용하십시오. Gatekeeper를 끄거나 모든 다운로드 파일을 일괄 허용하는 방식은 DAO-Code 문제를 해결하는 안전한 방법이 아닙니다.

세 번째 단계: npm EACCES와 칩 구조 오류 처리하기

npm의 EACCES는 보통 현재 사용자가 전역 설치 디렉터리에 쓸 권한이 없을 때 나타납니다. 오류 경로를 먼저 읽으십시오.

npm config get prefix
npm config get cache
node --version
npm --version

전역 경로가 시스템 소유 디렉터리라면 sudo npm install ...을 바로 사용하지 마십시오. npm은 사용자 영역 경로로 바꾸거나 Node 버전 관리 도구를 사용하는 방식을 안내합니다. npm의 EACCES 공식 해결 문서에 따라 한 가지 방식을 선택하고, 기존 전역 설치와 새 설치가 섞이지 않았는지 확인하십시오.

Node 버전도 확인해야 합니다. DAO-Code의 요구 범위는 공식 package.json의 Node 설정을 기준으로 판단합니다. node --version이 요구 조건보다 낮으면 PATH만 고쳐도 설치가 끝나지 않습니다. 반대로 버전이 맞는데도 EACCES가 발생하면 Node 문제가 아니라 npm 경로 문제입니다.

칩 구조 오류는 권한 오류와 다릅니다.

uname -m
file /실제/설치/경로/dao

Apple Silicon 맥과 인텔 맥에 맞지 않는 실행 파일을 받으면 bad CPU type과 같은 오류가 발생할 수 있습니다. 이 경우 chmod나 Gatekeeper 허용으로 해결되지 않습니다. 공식 설치 스크립트가 선택한 파일과 현재 맥의 구조가 일치하는지 다시 확인하십시오. 출처가 불분명한 변환 파일을 내려받는 것보다 공식 설치 경로를 다시 검증하는 편이 안전합니다.

네 번째 단계: 실행 성공과 API 인증 실패 구분하기

터미널에서 dao --version이 정상 출력되는데 모델 요청만 실패한다면, 설치 문제는 이미 지나갔을 가능성이 큽니다. 이 단계에서는 다음을 따로 확인하십시오.

1. API 키를 저장한 위치가 공식 빠른 시작 안내와 같은지 확인합니다.
2. 현재 셸에서 환경 변수가 실제로 읽히는지 확인합니다.
3. 프로젝트 설정 파일에 오래된 키가 남아 있지 않은지 확인합니다.
4. 계정 상태, 사용 한도, 선택한 모델, API 응답 코드를 각각 확인합니다.
5. 로그에서 키 값 자체는 출력하거나 공유하지 않습니다.

환경 변수의 존재만 확인하려면 값 전체를 출력하지 마십시오.

test -n "$DAO_CODE_API_KEY" && echo "키가 설정되어 있습니다" || echo "키가 없습니다"

실제 변수 이름과 설정 위치는 버전에 따라 달라질 수 있으므로 공식 빠른 시작 안내를 기준으로 확인하십시오. 키를 새로 발급했다면 셸을 다시 열고, 프로젝트가 읽는 설정 파일도 함께 갱신해야 합니다. 명령어가 실행된다는 사실과 API 요청이 승인된다는 사실은 서로 다른 검증입니다.

결정 조건으로 복구 경로 선택하기

다음 조건을 순서대로 적용하면 불필요한 조치를 줄일 수 있습니다.

• 파일이 없으면 설치 경로와 공식 자산을 다시 확인하십시오. 파일이 있는데 명령어만 없으면 PATH를 고치십시오.
• 전체 경로 실행은 되지만 dao만 실패하면 임시 전체 경로 사용을 멈추고 셸 설정을 영구 수정하십시오.
• 파일은 있지만 permission denied가 나오면 실행 비트와 소유자를 확인하십시오. 소유자가 시스템 계정이면 권한을 넓히기보다 사용자 영역 설치를 선택하십시오.
• 출처가 확인되지 않으면 Gatekeeper 우회를 선택하지 말고 파일을 폐기하십시오.
• bad CPU type이면 권한 수정을 중단하고 uname -m과 파일 구조가 맞는지 확인하십시오.
• EACCES이면 sudo보다 npm 사용자 영역 또는 Node 버전 관리 방식을 우선 적용하십시오.
• 버전 출력은 되지만 API만 실패하면 재설치하지 말고 키 위치, 계정 상태, API 응답을 분리해 점검하십시오.

자주 겪는 다섯 가지 상황

설치 뒤 명령어를 찾지 못하는 경우

설치 파일이 존재하는지 먼저 확인하십시오. 파일이 있다면 새 터미널에서 PATH가 유지되는지 검증합니다. 설정 파일에 경로를 추가할 때는 기존 PATH를 지우지 말고 뒤에 이어 붙이십시오. 다른 도구의 경로를 덮어쓰면 DAO-Code를 고친 뒤 Node나 npm이 다시 작동하지 않을 수 있습니다.

macOS가 실행을 막는 경우

알 수 없는 개발자라는 문구만 보고 파일이 안전하다고 판단해서는 안 됩니다. 공식 저장소의 파일명과 해시를 비교할 수 있다면 비교하고, 출처가 확인된 경우에만 Apple이 안내하는 개별 허용 절차를 검토하십시오.

npm 설치에서 EACCES가 나오는 경우

오류에 표시된 디렉터리를 확인하십시오. 시스템 영역이면 현재 사용자가 쓰기 가능한 npm 경로로 전환합니다. sudo로 설치를 끝내면 이후 업데이트와 삭제가 다른 사용자 소유가 되어 같은 문제가 반복될 수 있습니다.

내려받은 파일의 구조가 맞지 않는 경우

uname -m은 현재 맥의 구조를 보여 줍니다. 설치 파일의 구조가 다르면 맞는 공식 자산을 선택해야 합니다. Apple Silicon에서 호환 계층을 사용하는 것과 잘못된 실행 파일을 사용하는 것은 다른 문제이므로 두 경우를 섞지 마십시오.

API 키를 바꿨는데도 인증이 실패하는 경우

새 키가 실제 프로세스에 전달되는지 확인하십시오. 셸 파일, 프로젝트 환경 파일, 별도 설정 파일에 서로 다른 값이 남아 있으면 오래된 값이 우선될 수 있습니다. 키를 로그에 남기지 말고, 계정과 API 제공자의 응답 상태를 별도로 확인하십시오.

마지막 검증과 환경 이동 판단

수정이 끝났으면 아래 체크리스트를 저장해 두십시오.

• [ ] which dao가 예상한 경로를 출력합니다.
• [ ] dao --version이 정상적으로 응답합니다.
• [ ] uname -m과 실행 파일 구조가 일치합니다.
• [ ] 공식 저장소와 설치 자산의 출처를 확인했습니다.
• [ ] 실행 권한을 필요한 파일에만 적용했습니다.
• [ ] npm 전역 경로가 사용자 권한과 충돌하지 않습니다.
• [ ] API 키를 출력하지 않고 존재 여부만 확인했습니다.
• [ ] 새 터미널과 재시작 후에도 PATH가 유지됩니다.
• [ ] 읽기 전용 프로젝트 확인 뒤 제한된 테스트 요청만 실행했습니다.

권한 설정이 여러 차례 바뀌었거나 여러 개발자가 같은 환경을 재현해야 한다면, 다음 기록을 남기십시오.

운영 체제:
칩 구조:
설치 방식:
원본 오류:
which dao 결과:
dao 버전 결과:
적용한 수정:
재시작 후 결과:
API 응답 상태:

기존 오류 기록과 위 검증 결과가 없다면 원격 환경으로 옮겨도 같은 문제를 재현하기 어렵습니다. 반대로 기준을 먼저 남기면 깨끗한 원격 맥 환경에서 권한 오염 없이 다시 확인할 수 있습니다. Hashvps 지원 센터에서 환경 초기화와 접속 조건을 확인하고, 팀 단위라면 Hashvps 요금제 상세에서 필요한 사용 기간과 관리 범위를 비교하십시오.

현재 맥에서 계속 복구하는 방식은 추가 비용이 없어 보이지만, 오래된 PATH와 시스템 소유 npm 폴더가 남아 있으면 같은 장애가 반복됩니다. 로컬 장비를 새로 사는 방식은 안정적일 수 있지만 짧은 테스트나 팀 재현만 필요할 때는 초기 비용과 관리 부담이 커집니다. 이때 Hashvps의 원격 맥 환경은 깨끗한 작업 공간을 빠르게 만들고, 재현 기준을 맞추는 선택지가 될 수 있습니다. 다만 장기간 고정 부하를 계속 처리하거나 물리 포트가 꼭 필요한 작업이라면 로컬 맥이 더 적합합니다.

필요한 것은 단순한 재설치가 아니라, 원본 오류와 복구 기준이 남아 있는 실행 환경입니다. 그 기준을 먼저 저장한 뒤 현재 맥을 고칠지, Hashvps의 원격 맥에서 새로 검증할지 결정하십시오.