AI 에이전트에게 코딩을 맡기는 순간, 질문은 “잘 짜나?”에서 “어디까지 맡겨도 되나?”로 바뀐다. 예전에는 코드 생성 품질이 핵심이었다. 지금은 도구 호출, 파일 수정, 브라우저 테스트, 외부 서비스 연결까지 한 번에 묶인다. 생산성은 좋아졌는데, 실수의 반경도 같이 넓어진 것이다.
2026년에 실무자가 봐야 할 기준은 간단하다. AI 에이전트는 사람을 대체하는 마법 상자가 아니라, 권한을 받은 작업자다. 작업자에게는 업무 범위, 승인 절차, 로그, 실패 복구 기준이 있어야 한다. 이 네 가지 없이 “알아서 해줘”를 던지면 처음에는 편하고, 나중에는 누가 뭘 바꿨는지 찾다가 커피가 식는다.
AI 에이전트 코딩은 도구 사용 문제다
AI 코딩 도구를 단순한 자동완성으로 보면 위험을 과소평가하게 된다. OpenAI 문서도 모델 응답이나 에이전트를 만들 때 built-in tools, function calling, tool search, remote MCP servers 같은 도구로 기능을 확장할 수 있다고 설명한다. 즉 최신 에이전트는 답변만 쓰는 것이 아니라, 필요한 도구를 고르고 실행하는 구조로 가고 있다.
도구를 쓴다는 말은 곧 권한을 가진다는 뜻이다. 파일을 읽을 수 있는가, 쓸 수 있는가, 쉘 명령을 실행할 수 있는가, 외부 서비스에 접속할 수 있는가, 브라우저를 조작할 수 있는가가 모두 다르다. 코딩 에이전트의 품질은 프롬프트 문장만으로 결정되지 않는다. 어떤 도구가 연결되어 있고, 그 도구가 어디까지 허용되는지가 실제 운영 품질을 만든다.
그래서 “AI가 코드를 대신 짜도 될까?”라는 질문은 너무 크다. 더 나은 질문은 “이 업무에는 어떤 권한을 줘도 되는가?”다. 테스트 파일 수정은 허용할 수 있지만, 배포 스크립트 변경은 승인 필요일 수 있다. 문서 초안 작성은 자유롭게 맡길 수 있지만, 고객 데이터가 들어간 로그 분석은 별도 기준이 필요하다. 에이전트도 결국 출입증 색깔이 필요하다.
맡겨도 되는 업무와 보류해야 하는 업무
AI 에이전트에게 바로 맡기기 좋은 업무는 실패해도 되돌리기 쉬운 작업이다. 예를 들어 README 정리, 테스트 추가, 작은 버그 재현, 린트 오류 수정, 컴포넌트 분리, 반복적인 마이그레이션 초안 작성이 여기에 들어간다. 이런 작업은 변경 범위가 비교적 좁고, 사람이 diff를 보고 검수할 수 있다.
반대로 보류해야 하는 업무는 권한과 맥락이 깊은 작업이다. 인증 흐름 변경, 결제 로직 수정, 데이터 삭제 코드, 운영 배포, 고객 개인정보 처리, 보안 정책 변경, 대규모 DB 마이그레이션은 단순한 코드 작성이 아니다. 여기는 “코드를 잘 썼다”보다 “잘못했을 때 피해가 어디까지 가나”가 더 중요하다.
중간 지대도 있다. 기존 API에 작은 필드를 추가하거나, UI 상태를 바꾸거나, 내부 도구에 새 필터를 붙이는 작업이다. 이런 작업은 맡길 수 있지만 조건이 붙는다. 요구사항이 명확해야 하고, 관련 파일 범위가 좁아야 하며, 테스트 또는 스크린샷 검증이 가능해야 한다. 즉 에이전트에게 맡기는 기준은 난이도가 아니라 검증 가능성이다.
| 업무 유형 | 맡겨도 되는 조건 | 승인 필요 신호 |
|---|---|---|
| 문서, README, 주석 정리 | 변경 범위가 문서에 한정 | 정책 문구나 법무 문장 포함 |
| 테스트 추가 | 실패/성공 기준이 명확 | 테스트가 운영 설정을 건드림 |
| UI 작은 수정 | 스크린샷으로 확인 가능 | 결제, 인증, 개인정보 화면 |
| 버그 수정 | 재현 절차와 기대 결과 존재 | 데이터 삭제, 권한 체크 포함 |
| 배포/인프라 | 보통 보류 | 운영 영향 가능성이 있으면 사람 승인 |
MCP가 붙으면 로그 기준이 더 중요해진다
MCP는 AI 에이전트가 외부 도구와 서비스를 사용할 수 있게 만드는 흐름에서 자주 등장한다. OpenAI의 MCP and Connectors 문서는 remote MCP servers와 connectors가 모델에게 외부 서비스 접근 능력을 줄 수 있으며, 이런 도구 호출은 자동 허용하거나 개발자 승인으로 제한할 수 있다고 설명한다. 이 문장에서 핵심은 “연결”보다 “승인”이다.
문서의 리스크 섹션도 중요하다. 외부 MCP 서버는 민감한 데이터를 받을 수 있고, 제3자 서비스의 조건과 보안 정책을 따른다. 또한 도구 호출에서 어떤 데이터가 공유되는지 검토하고 로그를 남기라고 권장한다. 에이전트가 코드를 고치는 데 MCP를 쓴다면, 그 MCP가 어떤 파일 경로, 어떤 토큰, 어떤 저장소 정보에 접근하는지 확인해야 한다.
실무 기준으로는 MCP를 세 등급으로 나눌 수 있다. 공개 문서 검색처럼 민감도가 낮은 도구, 사내 문서나 이슈 트래커처럼 업무 데이터가 들어간 도구, 배포·결제·CRM처럼 실제 변경 액션이 가능한 도구다. 첫 번째는 비교적 느슨하게, 두 번째는 승인과 로그를 붙이고, 세 번째는 기본적으로 사람 승인 없이는 막는 편이 낫다.
권한 체크표
첫 번째 질문은 파일 권한이다. 에이전트가 읽을 수 있는 경로와 쓸 수 있는 경로를 분리해야 한다. 전체 저장소를 읽는 것은 필요할 수 있지만, 쓰기는 작업 범위에 맞춰 좁히는 게 좋다. 특히 .env, 인증 키, 고객 데이터, 빌드 산출물, 배포 설정은 기본 차단 목록에 넣는 편이 안전하다.
두 번째 질문은 명령 실행 권한이다. npm test, pytest, rg, git diff 같은 검증 명령은 생산성을 높인다. 그러나 rm, 강제 reset, 배포 명령, 데이터베이스 변경 명령은 승인 없이는 실행하지 않아야 한다. 에이전트가 명령을 실행할 수 있다면, 명령 자체가 작은 API가 된다. API에는 권한 정책이 있어야 한다.
세 번째 질문은 네트워크 권한이다. 최신 문서 검색, 패키지 설치, 외부 API 호출은 유용하지만, 동시에 데이터 유출의 길이 될 수 있다. OpenAI의 Codex best practices도 작업 환경에 맞게 설정을 일찍 구성하라고 말하며, approval mode와 sandbox mode 같은 설정이 어떤 명령과 파일 접근을 허용할지 결정한다고 설명한다. 개발 환경에서는 느슨해 보여도, 회사 코드베이스에서는 이 차이가 크게 난다.
| 권한 항목 | 기본값 | 열어도 되는 경우 | 막아야 하는 경우 |
|---|---|---|---|
| 파일 읽기 | 작업 저장소 중심 | 관련 모듈 이해 필요 | 비밀키, 개인정보 파일 |
| 파일 쓰기 | 변경 범위 제한 | 테스트, 문서, 특정 모듈 | 배포 설정, 인증, 결제 |
| 쉘 실행 | 검증 명령 중심 | 테스트·린트·검색 | 삭제·강제 reset·배포 |
| 네트워크 | 출처 제한 | 공식 문서·패키지 조회 | 민감 데이터 전송 가능 |
| MCP 도구 | 최소 도구 | 공개 검색·읽기 중심 | 외부 변경 액션 가능 |
로그 체크표
로그는 문제가 생겼을 때의 보험이다. 에이전트가 어떤 파일을 읽고, 어떤 파일을 수정했고, 어떤 명령을 실행했는지 남아 있어야 한다. 단순히 채팅 기록이 있으면 된다고 생각할 수 있지만, 실무에서는 채팅보다 구조화된 로그가 필요하다. 변경 파일 목록, 명령 결과, 실패한 테스트, 승인된 위험 명령을 따로 남겨야 나중에 추적이 가능하다.
특히 MCP나 외부 커넥터가 붙으면 “어떤 데이터가 외부 도구로 나갔는지”가 중요해진다. OpenAI MCP 문서는 MCP 도구 호출에서 공유되는 데이터를 검토하고 로그하라고 권장한다. 이 기준을 코딩 에이전트에 적용하면, 외부 서비스에 전달된 인자, 응답 요약, 오류 메시지, 승인 여부를 남겨야 한다. 로그가 없으면 생산성 도구가 아니라 기억력 테스트가 된다.
다만 로그에도 주의가 있다. 로그에 비밀키나 개인정보를 그대로 남기면 로그가 새로운 위험이 된다. 그래서 로그는 상세해야 하지만, 민감값은 마스킹해야 한다. 좋은 로그는 문제를 재현할 만큼 충분하고, 유출돼도 피해가 제한적이어야 한다. 이 균형이 없으면 “안전하려고 남긴 기록”이 또 다른 숙제가 된다.
검수 루틴은 diff에서 시작한다
AI 에이전트가 코드를 만들었다면 첫 검수는 diff다. 전체 설명을 읽기 전에 어떤 파일이 바뀌었는지 본다. 요청과 무관한 파일이 바뀌었는지, 설정 파일이 건드려졌는지, 테스트가 추가됐는지 확인한다. 설명은 그다음이다. 사람도 가끔 말을 예쁘게 하고 코드는 이상하게 짜는데, AI도 예외는 아니다.
두 번째는 테스트다. 단위 테스트가 있으면 실행하고, 프론트엔드라면 스크린샷이나 브라우저 확인을 붙인다. 결과가 없으면 “완료”가 아니라 “초안”으로 본다. 에이전트가 테스트를 만들었다면 그 테스트가 실제 버그를 잡는지 봐야 한다. 실패하지 않는 테스트는 마음을 편하게 하지만, 너무 편한 테스트는 가끔 아무것도 안 한다.
세 번째는 롤백 가능성이다. 변경이 작고 되돌리기 쉬우면 에이전트에게 더 많은 반복을 맡길 수 있다. 변경이 크고 되돌리기 어렵다면 단계별로 쪼개야 한다. AI 에이전트에게 맡기는 좋은 작업은 “큰 문제를 한 번에 해결”이 아니라 “작은 변경을 빠르게 만들고 검수하는 루프”에 가깝다.
실제 운영 기준
개인 프로젝트라면 에이전트에게 더 넓은 권한을 줄 수 있다. 그래도 비밀키 파일, 데이터 삭제, 배포 명령은 분리하는 편이 좋다. 개인 프로젝트에서 생긴 나쁜 습관은 회사 프로젝트로 쉽게 따라온다. 가벼운 코드 실험도 기본 차단 목록을 만들어두면 나중에 덜 아프다.
팀 프로젝트라면 권한 등급을 문서화해야 한다. “문서/테스트는 자동”, “기능 코드는 리뷰 필수”, “배포/보안/결제는 사람 승인 필수”처럼 단순한 표부터 시작하면 된다. 이 표가 있어야 팀원이 AI 에이전트를 각자 다르게 쓰면서 생기는 혼선을 줄일 수 있다. 도구가 좋아질수록 규칙은 더 짧고 선명해야 한다.
회사의 운영 코드라면 에이전트를 직접 배포 파이프라인에 붙이기 전에 관찰 기간을 두는 편이 좋다. 처음에는 읽기와 초안 생성만 허용하고, 그다음 테스트 추가, 그다음 제한된 파일 쓰기로 넓힌다. 권한은 처음부터 크게 주는 것이 아니라, 신뢰와 로그가 쌓일수록 늘리는 것이다. 사람 신입도 첫날부터 프로덕션 DB 삭제 권한을 받지는 않는다. 에이전트라고 특별 대우하면 계좌 말고 서버가 놀란다.
내 기준 정리
AI 에이전트에게 맡겨도 되는 코딩 업무는 “검증 가능하고 되돌릴 수 있는 업무”다. README 정리, 테스트 추가, 작은 UI 수정, 명확한 버그 수정은 좋은 후보가 된다. 인증, 결제, 개인정보, 배포, 데이터 삭제처럼 실패 비용이 큰 업무는 사람 승인 없이는 보류해야 한다.
MCP와 외부 도구가 붙는 순간 기준은 더 엄격해진다. 도구가 많아질수록 에이전트는 똑똑해지지만, 동시에 실수할 수 있는 문도 많아진다. 그래서 2026년의 AI 코딩 실무는 프롬프트 기술보다 권한표, 로그표, 검수 루틴이 더 중요해지고 있다. 멋진 에이전트보다 좋은 운영표가 먼저다. 조금 심심해 보이지만, 심심한 운영표가 야근을 줄인다.
관련 글
FAQ
Q. AI 에이전트에게 전체 저장소를 맡기면 안 되나?
전체 저장소를 이해하도록 읽기 권한을 주는 것과 전체 저장소를 마음대로 수정하게 하는 것은 다르다. 실무에서는 읽기 범위는 넓게, 쓰기 범위는 작업 단위로 좁게 두는 편이 안전하다. 특히 비밀키, 배포 설정, 고객 데이터는 기본 차단이 좋다.
Q. MCP는 꼭 써야 하나?
꼭 써야 하는 것은 아니다. MCP는 외부 도구와 서비스를 연결할 때 유용하지만, 연결할수록 승인과 로그 기준이 필요하다. 공개 문서 검색처럼 낮은 위험의 도구부터 쓰고, 변경 액션이 가능한 도구는 사람 승인 뒤에 붙이는 편이 현실적이다.
Q. AI가 만든 코드는 어디서부터 검수해야 하나?
먼저 diff를 보고 바뀐 파일을 확인한다. 그다음 테스트와 실행 결과를 본다. 마지막으로 변경이 되돌리기 쉬운지 확인한다. 설명이 그럴듯해도 diff, 테스트, 롤백 가능성이 없으면 아직 완료가 아니라 초안에 가깝다.