제품을 만들기 시작한 창업자에게 Claude Code의 가장 어려운 지점은 코드를 생성하는 일이 아닙니다. GitHub, 데이터베이스, 로그인 서비스, 호스팅 환경까지 연결한 뒤 어느 명령까지 실행하게 둘지 결정하는 일입니다.
“직접 실행해줘”는 편리한 요청이지만, 실행 대상이 로컬 파일인지 운영 데이터베이스인지, 테스트 환경인지 실제 고객이 쓰는 서비스인지에 따라 위험은 크게 달라집니다. Claude Code의 가치는 비개발자의 모든 판단을 대체하는 데 있지 않습니다. 사람이 빠르게 검토할 수 있도록 작업을 계획, 수정안, 실행, 검증의 단계로 나누고, 되돌릴 수 없는 변경 앞에서 멈추게 만드는 데 있습니다.
Claude Code는 계획 모드와 권한 모드를 제공하며, 일부 도구를 사전에 허용하는 설정도 지원합니다. 이 기능을 “승인 창을 줄이는 기능”으로만 해석하면 위험합니다. 더 적절한 활용법은 작업의 영향도에 따라 허용 범위를 다르게 설정하는 것입니다.
요구사항을 기능 목록이 아니라 실행 권한 표로 바꾼다
개발을 맡기기 전에 “로그인 기능을 만든다”, “예약 데이터를 저장한다”처럼 기능만 적어두면 승인 기준이 흐려집니다. 같은 로그인 기능이라도 화면 파일을 수정하는 일, 인증 공급자의 설정을 바꾸는 일, 운영 사용자 계정에 영향을 주는 일은 전혀 다른 종류의 작업이기 때문입니다.
프로젝트 시작 단계에서 제품 책임자, 개발 책임자 또는 외부 개발 파트너가 함께 실행 권한 표를 만듭니다. 이 표는 기능 명세서와 별도로 관리하는 편이 좋습니다.
| 작업 범주 | 예시 | 기본 처리 방식 | 단계 산출물 |
|---|---|---|---|
| 읽기와 조사 | 코드 구조 확인, 로그 확인, 설정 파일 분석 | 자동 허용 가능 | 조사 결과, 영향 범위 |
| 로컬 변경 | 화면 문구 수정, 테스트 추가, 개발용 파일 생성 | 자동 실행 후 검토 | 변경 파일 목록, diff |
| 되돌릴 수 있는 공유 변경 | 브랜치 생성, 커밋 생성, 테스트 환경 반영 | 조건부 허용 | PR 또는 변경 요청 |
| 외부 서비스 설정 | 로그인 제공자 설정, 저장소 권한 변경, 환경 변수 등록 | 사람 승인 후 실행 | 설정값 목록, 권한 범위 |
| 데이터 구조 변경 | 테이블 생성, 컬럼 삭제, 마이그레이션 실행 | 사람 승인 후 실행 | 마이그레이션 파일, 복구안 |
| 운영 배포와 삭제 | 운영 환경 배포, 데이터 삭제, 비밀 키 교체 | 별도 승인 없이는 실행 금지 | 배포 계획, 검증 기록, 롤백 절차 |
여기서 핵심은 “자동화 가능”과 “자동 승인”을 구분하는 일입니다. 예를 들어 데이터베이스 마이그레이션 파일을 만드는 일은 자동화할 수 있습니다. 그러나 그 파일을 운영 데이터베이스에 적용할지는 사람이 검토하고 승인해야 합니다.
권한은 서비스별 계정이 아니라 작업별 역할로 나눈다
외부 서비스를 연결할 때 흔히 생기는 문제는 편의를 위해 하나의 강한 권한을 에이전트에 넘기는 것입니다. 데이터베이스 관리 키, 전체 저장소 권한, 운영 배포 권한을 한 번에 연결하면 작업은 빨라질 수 있습니다. 반면 잘못된 요청, 불완전한 설명, 예상하지 못한 도구 호출이 발생했을 때 피해 범위도 함께 커집니다.
LLM 에이전트 보안에서 과도한 권한은 기능이 많거나 권한이 넓거나, 사람 확인 없이 자율 실행할 때 발생하는 위험으로 다뤄집니다. 따라서 권한 설계의 출발점은 “이 도구가 무엇을 할 수 있는가”가 아니라 “이번 단계에서 무엇만 할 수 있어야 하는가”여야 합니다.
다음처럼 역할을 나누면 판단이 쉬워집니다.
- 조회 역할: 코드, 문서, 로그, 테스트 결과를 읽습니다. 수정이나 배포 권한은 주지 않습니다.
- 개발 역할: 로컬 작업 폴더와 개발 브랜치에서 파일을 수정하고 테스트를 실행합니다.
- 검토 역할: 변경된 파일, SQL, 환경 설정 차이, 배포 예정 목록을 읽고 설명 문서를 만듭니다.
- 실행 역할: 승인된 명령만 제한적으로 수행합니다. 개발 환경과 운영 환경의 자격 증명은 분리합니다.
- 운영 승인자: 운영 데이터 변경, 고객에게 보이는 설정 변경, 배포를 최종 승인합니다.
특히 데이터베이스에는 읽기 전용 계정과 변경 가능한 계정을 분리하는 편이 낫습니다. 제품 데이터 일부를 조회하는 작업에 INSERT, UPDATE, DELETE 권한까지 필요한 것은 아닙니다. 필요한 테이블과 필요한 동작만 허용해야 합니다.
Claude Code에서 특정 도구를 허용 목록으로 관리할 수 있다는 점도 이 구조에 맞춰 사용해야 합니다. 예를 들어 코드 읽기, diff 확인, 테스트 실행처럼 영향이 제한된 명령은 반복 승인 없이 허용할 수 있습니다. 반대로 광범위한 셸 명령이나 운영 자격 증명을 사용하는 명령을 포괄적으로 허용하면, 승인 경계가 사실상 사라질 수 있습니다.
DB 변경은 SQL 검토, 실행 승인, 결과 확인의 세 장으로 나눈다
비개발자가 가장 쉽게 과신하기 쉬운 영역은 데이터베이스입니다. 테이블 생성과 관계 설정은 빠르게 만들어낼 수 있지만, 기존 데이터가 있는 상태에서의 변경은 “문법이 맞는가”만으로 판단할 수 없습니다.
DB 변경은 아래 순서로 고정해두는 편이 좋습니다.
-
변경 요청을 업무 언어로 기록합니다.
예를 들어 “예약에 취소 사유를 남긴다”처럼 제품 요구사항을 적습니다. “컬럼을 추가한다”는 구현 방법이므로 출발점이 될 수 없습니다. -
Claude Code가 변경안을 생성하되 실행하지 않습니다.
산출물은 마이그레이션 파일, 영향을 받는 테이블 목록, 기존 데이터 처리 방식, 되돌리는 방법입니다. -
사람이 질문을 확인하고 승인합니다.
기존 행에 어떤 값이 들어가는지, 빈 값이 허용되는지, 삭제 또는 형식 변경이 있는지, 실패했을 때 어떤 상태로 복구할지 묻습니다. 이 질문에 답할 수 없다면 운영 적용을 미뤄야 합니다. -
개발 또는 테스트 환경에서 먼저 적용합니다.
적용 전후의 스키마 차이와 주요 기능 테스트 결과를 남깁니다. -
운영 적용은 별도 승인으로 실행합니다.
테스트 통과는 운영 승인과 다릅니다. 운영에서는 고객 데이터, 운영 시간, 장애 대응 책임이 함께 걸립니다.
삭제, 컬럼 형식 변경, 기존 데이터 일괄 수정처럼 되돌리기 어려운 작업은 계획 모드에서 분석과 변경안 작성까지만 맡기고, 실행 권한은 열지 않는 편이 안전합니다.
배포 승인은 코드가 아니라 변경 묶음을 본다
“테스트가 통과했으니 배포한다”는 기준만으로는 부족합니다. 배포에는 코드 외에도 환경 변수, 데이터베이스 상태, 외부 서비스 설정, 배포 대상 브랜치가 함께 영향을 줍니다.
배포 직전 Claude Code에 다음 항목을 사람이 읽을 수 있는 형식으로 정리하게 하십시오.
- 이번 배포에서 바뀌는 기능과 파일
- 새로 추가되거나 변경되는 환경 변수
- 실행해야 하는 데이터베이스 변경 여부
- 영향을 받는 외부 서비스 연동
- 배포 후 확인할 사용자 흐름
- 문제가 생겼을 때 되돌릴 대상과 방법
- 아직 해결되지 않은 경고 또는 테스트 실패
이 문서는 승인 요청서 역할을 합니다. 중요한 점은 AI가 “배포 가능”이라고 말하는지보다, 승인자가 변경 묶음을 이해하고 “이 영향은 감수할 수 있다”고 판단할 수 있는지입니다.
운영 배포까지 자동 실행하게 하려면 최소한 배포 대상 환경을 명확히 구분하고, 승인된 변경만 포함됐는지 확인하는 절차가 먼저 있어야 합니다. 사람의 승인은 버튼을 한 번 더 누르는 행위가 아니라 책임 범위를 확인하는 단계입니다.
검증은 기능 테스트와 권한 테스트를 함께 한다
구축 후에는 제품 기능뿐 아니라 Claude Code의 행동 범위도 시험해야 합니다. 기능이 잘 작동해도, 요청 하나로 운영 데이터 수정이나 광범위한 설정 변경이 가능한 상태라면 통제 설계는 실패한 것입니다.
초기 검증에서는 다음 시나리오를 점검할 수 있습니다.
- “코드 구조를 분석해 달라”는 요청에 파일 수정이나 외부 설정 변경이 일어나지 않는가
- “테이블을 바꿔 달라”는 요청에 실행 전 마이그레이션과 영향 설명을 제시하는가
- 개발 환경용 자격 증명으로 운영 환경에 접근할 수 없는가
- 배포 요청 시 대상 환경, 변경 목록, 데이터 변경 여부를 다시 확인하는가
- 삭제 또는 대량 수정 요청에서 독립적인 사람 확인 없이 실행하지 않는가
조기 경고 신호도 정해둬야 합니다. 에이전트가 반복적으로 전체 권한 키를 요구하거나, 영향 범위 설명 없이 실행을 권하거나, 테스트와 운영 환경을 구분하지 못한다면 권한 설계나 작업 지시가 너무 넓다는 뜻일 수 있습니다. 이때 프롬프트를 더 길게 쓰기보다 권한을 줄이고 작업을 더 작은 단위로 나누는 쪽이 낫습니다.
운영 단계에서는 승인 기록을 제품 자산으로 남긴다
처음에는 속도를 위해 승인 절차를 귀찮은 일로 느낄 수 있습니다. 하지만 어떤 DB 변경을 누가 승인했는지, 어떤 환경 변수는 왜 추가됐는지, 어떤 배포에서 무엇을 확인했는지가 남아 있으면 팀이 커질수록 개발 속도가 오히려 안정됩니다.
운영 문서에는 복잡한 기술 설명보다 다음 네 가지를 남기면 충분합니다. 변경 목적, 승인자, 실행 환경, 실행 후 확인 결과입니다. 사고가 났을 때도 이 기록은 책임 추궁용 문서가 아니라 원인을 좁히고 복구 순서를 정하는 출발점이 됩니다.
Claude Code를 도입할 때 첫 질문은 “어디까지 자동화할 수 있는가”가 아니라 “어디서 멈추게 할 것인가”여야 합니다. 먼저 현재 프로젝트의 외부 연동, DB 변경, 배포 작업을 한 장의 실행 권한 표에 올려보십시오. 그 표에서 사람 이름이 비어 있는 고영향 작업부터 승인자를 정하는 일이, 도구 설정보다 앞섭니다.
