AI 코딩 에이전트는 이제 코드 작성 도구라기보다 작업 실행자에 가깝습니다.
파일을 읽고, 고치고, 테스트를 돌리고, 패키지를 설치하고, 때로는 배포 스크립트까지 만집니다.

그래서 중요한 질문은 “에이전트가 코드를 잘 짜는가”에서 끝나지 않습니다.
어디까지 맡기고, 어디서 사람이 멈춰 세울 것인가를 정해야 합니다.

이 글은 2026년 5월 28일 기준 OpenAI, Anthropic, GitHub, OWASP 문서를 바탕으로 AI 코딩 에이전트에게 무조건 자동으로 맡기면 위험한 작업을 정리합니다.

먼저 결론

AI 코딩 에이전트에게 아래 작업을 맡길 수는 있습니다.
다만 초안 작성, 점검 목록 생성, 테스트 보조까지만 맡기고, 최종 실행은 사람이 확인하는 편이 안전합니다.

작업에이전트에게 맡겨도 되는 범위사람이 직접 해야 할 것
secret 처리노출 가능성 스캔실제 키 입력, 폐기, 재발급
운영 DB 작업마이그레이션 초안 작성백업 확인, 실행, 롤백 판단
삭제 명령삭제 대상 목록화실제 삭제 명령 승인
배포체크리스트 작성, 로그 요약운영 반영, 장애 대응 판단
인증/권한 코드테스트 케이스 초안보안 리뷰와 정책 판단
의존성 변경후보 비교, 취약점 확인major upgrade 승인
법률/라이선스관련 문서 찾기최종 사용 가능 여부 판단

1. 실제 API 키와 인증 정보를 다루는 작업

에이전트에게 실제 API 키, 토큰, 인증서, DB 비밀번호를 그대로 붙여 넣는 것은 피해야 합니다.

위험한 작업은 이런 것입니다.

  • .env 파일에 실제 키를 넣으라고 시키기
  • 에이전트 대화창에 production token을 붙여 넣기
  • 배포 로그에서 credential을 찾아 달라고 원문 전체를 넘기기
  • GitHub token, Cloudflare token, OpenAI API key를 테스트 코드에 임시로 넣기

GitHub MCP Server의 secret scanning 같은 도구는 커밋 전 점검에 도움이 됩니다.
하지만 이런 도구는 이미 노출된 값을 찾아내는 보조 장치이지, 키를 안전하게 다뤄도 된다는 허가가 아닙니다.

현실적인 사용법은 이렇습니다.

실제 secret 값은 보지 말고, placeholder 기준으로 .env.example과 설정 로딩 코드를 만들어줘.

그리고 사람이 직접 해야 할 일은 따로 둡니다.

  1. secret은 비밀번호 관리자나 secret manager에 보관합니다.
  2. .env.example에는 실제 값이 아니라 YOUR_API_KEY_HERE 같은 placeholder만 둡니다.
  3. 커밋 전 secret scanning을 돌립니다.
  4. 노출이 의심되면 수정이 아니라 키 폐기와 재발급부터 합니다.

2. 운영 데이터 삭제와 마이그레이션 실행

에이전트는 SQL과 migration 파일을 빨리 만들 수 있습니다.
문제는 운영 데이터에서는 “문법이 맞는가”보다 “되돌릴 수 있는가”가 더 중요하다는 점입니다.

특히 아래 작업은 자동 실행을 피해야 합니다.

  • DROP TABLE
  • 대량 DELETE
  • 컬럼 타입 변경
  • production DB 직접 접속
  • 마이그레이션 후 데이터 보정 스크립트 실행
  • 오래된 백업 삭제

에이전트에게 맡길 수 있는 범위는 초안과 검토입니다.

이 마이그레이션의 위험한 지점, 롤백 방법, 실행 전 백업 체크리스트를 만들어줘.

실제 실행 전에는 사람이 아래를 확인해야 합니다.

  1. 최신 백업이 있고 복구 테스트를 해봤는가
  2. 쿼리가 예상 행 수만 건드리는가
  3. 읽기 전용 환경이나 staging에서 먼저 검증했는가
  4. 롤백 SQL 또는 복구 절차가 있는가
  5. 실행 시간이 서비스에 영향을 주지 않는가

3. 파일 삭제, 권한 변경, 시스템 명령 자동 실행

OpenAI의 shell tool 문서도 임의 shell 명령 실행은 위험하므로 sandbox, allowlist, denylist, 최소 권한, 감사 로그 같은 통제가 필요하다고 안내합니다.
Claude Code 문서도 파일 수정, 테스트 실행, 명령 실행처럼 더 강한 작업에는 권한 설정과 확인 흐름을 강조합니다.

개발자가 특히 조심해야 할 명령은 익숙한 명령입니다.

  • rm -rf
  • chmod -R
  • chown -R
  • curl | sh
  • npm install 뒤 postinstall 실행
  • Docker volume 삭제
  • 서버 안에서 직접 실행하는 배포 스크립트

에이전트에게는 삭제 명령을 바로 실행시키지 말고, 먼저 목록을 만들게 하는 편이 낫습니다.

삭제 후보를 실제 삭제하지 말고 목록만 보여줘. 왜 삭제해도 되는지 근거도 같이 적어줘.

좋은 규칙은 단순합니다.

  1. 삭제는 먼저 dry-run 또는 목록 출력으로 확인합니다.
  2. 저장소 밖 파일을 건드리는 명령은 별도 승인합니다.
  3. 네트워크에서 받은 스크립트를 바로 실행하지 않습니다.
  4. Docker volume, DB 파일, 업로드 파일은 자동 삭제 대상에서 제외합니다.

4. 인증, 결제, 권한 같은 보안 핵심 로직의 최종 판단

AI 코딩 에이전트는 로그인 화면, JWT 처리, OAuth 콜백, 결제 webhook 코드를 빠르게 만들 수 있습니다.
하지만 이 영역은 “동작한다”와 “안전하다”가 다릅니다.

사람이 반드시 직접 봐야 하는 코드는 보통 이런 곳입니다.

  • 로그인과 세션 만료
  • 관리자 권한 체크
  • 결제 webhook 검증
  • 파일 업로드 검증
  • 비밀번호 재설정
  • multi-tenant 데이터 접근
  • CORS, CSRF, redirect URL 처리

OWASP LLM Top 10에서도 excessive agency, sensitive information disclosure, prompt injection처럼 에이전트가 너무 넓은 권한을 가질 때 생기는 위험을 다룹니다.
코딩 에이전트가 만든 보안 코드는 더더욱 “테스트가 통과했으니 끝”으로 보면 안 됩니다.

에이전트에게는 이렇게 시키는 편이 낫습니다.

이 권한 체크 코드에서 우회 가능한 경로를 공격자 관점으로 검토하고, 추가해야 할 테스트 케이스를 제안해줘.

최종 판단은 사람이 해야 합니다.

5. 라이선스, 개인정보, 법률 판단

에이전트는 오픈소스 라이선스 요약을 잘합니다.
하지만 특정 회사나 서비스에서 써도 되는가는 요약 문제가 아니라 책임 문제입니다.

자동으로 맡기면 위험한 질문은 이런 것입니다.

  • 이 GPL 라이브러리를 상용 서비스에 써도 되나
  • 사용자 로그를 AI API에 보내도 되나
  • 고객 데이터를 학습용으로 써도 되나
  • 해외 리전에 저장해도 되나
  • 이 크롤링이 약관 위반인가

에이전트는 관련 문서, 약관, 라이선스 조항을 찾는 데 쓰는 편이 좋습니다.
결론은 내부 정책, 계약, 법률 검토를 거쳐야 합니다.

실무 프롬프트는 이렇게 잡습니다.

최종 결론을 내리지 말고, 검토해야 할 조항과 리스크 질문만 정리해줘.

6. 큰 의존성 변경과 자동 패키지 설치

AI 에이전트는 “필요한 패키지를 설치해줘”라는 요청에 매우 적극적으로 반응합니다.
작은 유틸 하나를 붙이는 작업처럼 보이지만, 실제로는 공급망 위험을 들여오는 일입니다.

주의할 상황은 이렇습니다.

  • 이름이 비슷한 패키지 설치
  • 오래된 패키지 또는 유지보수 중단 패키지 추가
  • major version upgrade
  • lockfile 대량 변경
  • postinstall script가 있는 패키지
  • 보안 도구나 인증 라이브러리 교체

GitHub MCP Server의 dependency scanning 같은 흐름은 커밋 전 보안 확인에 유용합니다.
하지만 패키지를 추가해도 되는지, 더 작은 대안이 있는지는 사람이 판단해야 합니다.

추천 흐름은 이렇습니다.

  1. 에이전트에게 후보 2~3개를 비교하게 합니다.
  2. 공식 문서, 유지보수 상태, 라이선스, 취약점 이력을 봅니다.
  3. lockfile 변경량을 확인합니다.
  4. 설치 후 테스트와 dependency scanning을 실행합니다.

7. 장애 대응과 incident 판단

장애가 났을 때 에이전트에게 로그를 요약하게 하는 것은 도움이 됩니다.
하지만 운영 조치까지 바로 맡기면 위험합니다.

특히 아래는 사람이 직접 판단해야 합니다.

  • 운영 서버 재시작
  • DB failover
  • 캐시 전체 삭제
  • 사용자 데이터 복구
  • 결제 재처리
  • 장애 공지 작성과 원인 확정
  • 보안 사고에서 키 폐기와 접근 차단

장애 상황에서는 속도가 중요하지만, 증거 보존도 중요합니다.
에이전트가 급하게 로그를 정리하거나 임시 수정 코드를 만들 수는 있어도, 어떤 조치를 고객에게 알릴지와 어떤 증거를 남길지는 운영자가 결정해야 합니다.

에이전트에게는 이렇게 요청합니다.

아직 수정하지 말고, 로그에서 시간순 사건 흐름과 가능한 원인 후보만 정리해줘.

맡겨도 되는 작업은 무엇인가

반대로 아래 작업은 AI 코딩 에이전트와 잘 맞습니다.

  • 테스트 실패 원인 추적
  • 반복적인 타입 수정
  • 문서 초안 작성
  • 작은 UI 컴포넌트 구현
  • 단순 리팩터링 후보 찾기
  • 코드 리뷰 체크리스트 작성
  • 로그 요약
  • 마이그레이션 위험 분석

핵심은 권한입니다.
읽기와 초안 작성은 넓게 허용해도 되지만, 쓰기, 삭제, 배포, 네트워크, secret 접근은 좁게 열어야 합니다.

한 줄 결론

AI 코딩 에이전트는 좋은 개발 동료가 될 수 있지만, 운영 권한을 가진 자동 조종 장치로 두면 안 됩니다.
secret, 데이터, 삭제, 배포, 보안 로직, 의존성, 장애 대응은 사람이 마지막 승인권을 가져야 합니다.

같이 보면 좋은 글

출처