DAO-Code 자동 실행 안전한가? 2026 팀 모드 선택 가이드

저장소 안의 파일을 읽고 명령까지 자동으로 실행하는데, 무엇이 바뀌었는지 팀원이 바로 확인하기 어렵습니까?
이번 주에는 팀 기본값을 작업별 승인으로 두고, 읽기 전용 분석만 plan으로 시작하십시오. 작업 디렉터리 격리와 비밀 정보 보호, 복구 시험을 통과한 뒤에만 제한된 영역에서 auto를 검토하십시오.

이 글을 읽어야 하는 사람

팀 코드 저장소에 DAO-Code 기준을 정하려는 기술 책임자에게 맞습니다.
API Key, SSH 설정, 빌드 자격 증명을 보호해야 하는 보안 담당자와 여러 개발 환경을 배포하는 플랫폼 관리자도 대상입니다.

속도보다 승인 범위를 먼저 비교해야 합니다

DAO-Code의 실행 방식은 작업을 얼마나 자동화하느냐의 문제가 아닙니다. 읽기, 파일 수정, 셸 명령, 외부 경로 접근을 어디까지 허용할지 정하는 권한 설계입니다. 공식 README에는 plan, default, acceptEdits, auto, bypassPermissions 계열 방식이 설명되어 있습니다. 모드 이름만 보고 안전 등급으로 해석해서는 안 됩니다. 공식 README의 실행 방식 설명과 공식 보안 정책을 각각 확인하십시오.

• plan: 저장소 구조와 변경 계획을 검토하는 단계에 적합합니다. 낯선 저장소나 코드 리뷰 전 분석에 우선 적용합니다.
• default: 명령과 변경을 작업 단위로 확인합니다. 팀의 기본값으로 가장 보수적인 출발점입니다.
• acceptEdits: 파일 변경을 더 빠르게 처리할 수 있지만, 셸 명령과 외부 연결의 승인 경계는 따로 확인해야 합니다.
• auto: 허용된 작업 범위 안에서 실행을 자동화합니다. 한정된 작업 디렉터리와 격리 환경에서만 검토합니다.
• bypassPermissions 또는 yolo: 권한 우회를 전제로 할 수 있습니다. 정식 저장소와 공유 계정에는 사용하지 않습니다.

자동 실행은 효율을 높일 수 있습니다. 그러나 승인 절차를 줄이는 순간 책임 추적과 실수 복구 비용이 커집니다. 프로젝트가 제공하는 기능 설명은 제3자 보안 인증서가 아니며, 모든 플러그인, Hooks, MCP 서비스의 안전성을 증명하지도 않습니다.

첫 번째 점검: 파일과 명령의 경계를 실제로 시험하십시오

설정 파일에 allow, ask, deny 규칙이 있다고 해서 곧바로 충분한 것은 아닙니다. 규칙 우선순위와 자동 모드에서의 동작을 별도로 확인해야 합니다.

다음 순서로 진행하십시오.

1. 별도 테스트 저장소를 만들고 샘플 파일만 넣습니다.
2. 정상 작업 디렉터리 안의 읽기와 편집을 시험합니다.
3. 작업 디렉터리의 상위 경로와 형제 경로에 쓰기를 요청합니다.
4. 쉘 명령으로 설정 파일과 숨김 경로에 접근을 시도합니다.
5. 거부 규칙이 auto에서도 유지되는지 로그로 확인합니다.
6. 외부 URL이나 MCP 도구를 통한 우회 경로도 따로 시험합니다.

여기서 중요한 것은 성공 여부가 아니라 거부가 항상 거부되는지입니다. 경로 문자열을 바꾸거나 상대 경로를 사용했을 때 통제가 풀리면 auto를 중단해야 합니다. OWASP의 AI Agent 보안 권고도 최소 권한, 외부 입력 검증, 도구 호출 통제를 핵심 점검 대상으로 봅니다.

조건으로 고르는 실행 모드

• 저장소가 낯설거나 읽기만 필요하면 plan을 선택하십시오. 변경이 필요하면 default로 되돌립니다.
• 팀원이 매번 변경을 확인해야 하거나 정식 저장소라면 default를 선택하십시오.
• 작업 디렉터리가 분리되고, 거부 규칙과 복구 시험이 끝났다면 제한된 auto를 선택할 수 있습니다.
• 생산 자격 증명, 되돌릴 수 없는 삭제, 외부 시스템 변경이 포함되면 자동 모드를 선택하지 말고 사람 승인을 유지하십시오.
• 자격 증명이 없고 실패해도 즉시 폐기할 수 있는 격리 환경만 있다면 yolo를 테스트 용도로만 검토하십시오. 정식 팀 환경으로 승격하지 마십시오.

두 번째 점검: 파일보다 자격 증명 노출을 먼저 막으십시오

DAO-Code가 수정한 파일만 살펴보면 부족합니다. DeepSeek API Key, SSH 설정, 클라우드 자격 증명, 프로젝트 비밀 값이 프롬프트, 로그, 기억 기능, 하위 프로세스 환경으로 전달될 수 있는지 확인해야 합니다.

다음 항목을 체크하십시오.

• [ ] API Key와 SSH 개인 설정을 작업 디렉터리 밖에 두었습니까?
• [ ] 하위 프로세스에 전달되는 환경 변수를 최소화했습니까?
• [ ] 로그에 요청 본문, 토큰, 개인 경로가 남지 않습니까?
• [ ] 민감한 대상 접근 시 강제 확인이 발생합니까?
• [ ] 외부 URL과 리다이렉션을 검증합니까?
• [ ] 비밀 정보 검색과 차단 결과를 별도 로그에서 확인했습니까?

공식 보안 정책에 민감한 대상 확인, 감사 로그, 선택형 시스템 샌드박스가 언급되어도 이를 완전한 보안 감사로 간주해서는 안 됩니다. 로그는 운영에 필요하지만 새로운 유출 지점이 될 수 있습니다. 기록에 포함되는 값과 보관 범위는 안전한 로그 작성 원칙에 맞춰 마스킹하십시오.

macOS Seatbelt를 사용하더라도 애플리케이션의 규칙 오류나 MCP 도구의 과도한 권한을 자동으로 해결하지는 않습니다. Apple의 macOS 앱 샌드박스 설명처럼 시스템 격리는 권한 경계를 추가하는 수단이지, 승인 정책을 대체하는 장치가 아닙니다.

주의: 테스트 로그에는 실제 계정 이름, 저장소 주소, API Key, SSH 경로를 넣지 마십시오. 샘플 값으로 시험하고, 실패 기록도 공유 전에 다시 탈식별화하십시오.

세 번째 점검: 실패 비용을 기준으로 복구 방식을 비교하십시오

승인 방식이 느릴수록 안전하다고 단정할 수도 없습니다. 중요한 기준은 잘못된 변경을 얼마나 빨리 정확하게 되돌릴 수 있는가입니다.

먼저 프로젝트 자체의 버전 관리와 DAO-Code의 shadow-git 검사점을 구분하십시오. shadow-git은 실험 변경을 추적하는 보조 안전망으로 검증해야 하며, 정식 Git 기록을 대신한다고 가정하면 안 됩니다.

• 변경 전 검사점이 생성되는지 확인합니다.
• 여러 파일 수정 뒤 특정 단계로 돌아가는지 확인합니다.
• 복구가 정식 Git 이력에 불필요한 커밋을 만들지 않는지 확인합니다.
• 삭제, 이름 변경, 생성 파일까지 원상 복구되는지 시험합니다.
• 복구 후에도 비밀 값이나 임시 로그가 남지 않는지 확인합니다.

실패한 작업을 되돌리는 명령도 사람이 검토해야 합니다. 복구 명령 자체가 다시 자동 실행되면 손상을 키울 수 있기 때문입니다. 팀의 버전 관리, 변경 승인, 배포 기록은 별도로 유지하십시오. DevSecOps 흐름을 설계할 때는 NIST DevSecOps 참고 모델의 추적성과 검증 원칙을 참고할 수 있습니다.

네 번째 점검: 감사 기록에 책임자를 연결하십시오

감사 로그에 “파일이 바뀌었다”는 사실만 있으면 원인 분석이 어렵습니다. 최소한 실행 시각, 실행 주체, 선택한 모드, 대상 경로, 사용한 도구, 승인 또는 거부 결과, 복구 여부를 연결해야 합니다. 다만 이 기록에 프롬프트 원문과 비밀 값이 그대로 남으면 감사 자료가 새로운 위험이 됩니다.

팀 배포 전에 다음 책임을 정하십시오.

• 고위험 명령을 승인하는 사람
• 자동 실행 로그를 검토하는 사람
• 모드 변경을 승인하고 기록하는 사람
• 사고 시 작업 환경을 폐기하거나 복원하는 사람
• MCP 도구를 추가하거나 제거하는 사람

DAO-Code를 여러 개발 환경에 배포한다면 Hashvps 도움말 센터에 환경 운영 기준을 함께 정리해 두는 편이 좋습니다. 설치 자체보다 중요한 것은 모든 팀원이 같은 승인 규칙과 복구 절차를 사용하는 것입니다.

마지막 확인: 팀 도입 전 승인 목록

• [ ] plan으로 낯선 저장소를 읽기 전용 분석했습니까?
• [ ] 작업 디렉터리 밖 쓰기와 민감 경로 접근을 시험했습니까?
• [ ] auto에서 deny 규칙이 계속 작동했습니까?
• [ ] API Key와 SSH 설정이 로그와 하위 프로세스에 노출되지 않았습니까?
• [ ] shadow-git 검사점과 프로젝트 버전 관리로 복구했습니까?
• [ ] 감사 로그의 검토자와 보관 규칙을 정했습니까?
• [ ] MCP 도구와 Hooks를 하나씩 승인했습니까?
• [ ] yolo를 정식 환경에서 제외했습니까?

로컬 맥에서 독립 작업 공간을 만들기 어렵다면, 먼저 환경을 분리하고 다시 전달할 수 있는 원격 맥 구성을 검토하십시오. Hashvps의 맥 환경 상품 안내처럼 작업 환경을 별도로 제공하는 방식은 팀 공용 저장소와 개인 장비를 분리하는 데 유리할 수 있습니다. 다만 장기적으로 계속 무거운 빌드가 필요하거나 물리 장치 접근이 필수라면 자체 장비가 더 적합합니다. 반대로 단기 검증, 격리된 DAO-Code 테스트, 재설정 가능한 팀 환경이 목적이라면 맥 미니 렌탈을 비교할 가치가 있습니다.

DAO-Code 자동 실행의 핵심은 가장 빠른 모드를 고르는 일이 아닙니다. 이번 주에는 plan과 작업별 승인을 기준으로 격리, 비밀 정보, 복구를 직접 시험하십시오. 세 가지 검증을 모두 통과한 작업만 제한된 auto로 옮기고, bypassPermissions와 yolo는 폐기 가능한 테스트 환경 밖으로 가져가지 않는 기준을 문서화하십시오.