AI 코딩 에이전트에게 실기기를 맡기기 전에, 권한을 3단계로 나눴다
이 글은 「보수적인 13년 차 QA가 코딩 에이전트를 시작한 이유」에서 이어집니다. 왜 코딩 에이전트를 쓰기로 했는지, 왜 흩어진 프로젝트를 하나로 합쳤는지는 그 글에 있습니다.
지난 글에서 새로운 자동화 프로젝트는 설계부터 테스트케이스 생성, 대시보드까지 한 번에 가기로 했다고 썼는데 맡기기 전에 정해야 할 게 하나 있었습니다.
결론부터 말하면, 시작부터 끝까지 보안! 특히 민감정보 보호를 최우선 순위에 뒀습니다.
이 원칙을 가장 극단적으로 보여주는 장면이 하나 있습니다.
이미 코드에 그대로 적혀 있는 값도, 절대 옮겨 적지 않습니다. "이 값이 존재한다"라고 말하게 했습니다.
이 프로젝트엔 예전부터 있던 레거시 스크립트가 섞여 있는데, 거기엔 실기기 IP나 SSH Key 경로 같은 값이 이미 하드코딩돼 있습니다.
구조를 파악하려면 이 파일들을 읽어야 하는데, 읽는 것과 그 안의 값을 옮기는 것은 완전히 다른 문제라고 선을 그었습니다.
AI는 이 파일을 열어봐도 되지만, 그 안의 실제 값은 코드로도 로그로도 채팅 응답으로도 절대 그대로 옮기지 않고 "이런 종류의 값이 존재한다" 정도로만 언급하게 했습니다.
AI가 스스로 판단해서 실행해도 되는 것과 절대 안 되는 것을 3단계로 나눠서 미리 박아둔 것도, 이 하나의 우선순위에서 나온 첫 번째 구체적인 장치였습니다.
왜 이 질문이 필요했나
지금까지 AI한테 모르는 코드를 물어보거나 짜달라고 하는 건 위험 부담이 크지 않았습니다. 질문할 때 뭘 보여줄지는 항상 제가 정할 수 있었기 때문에 민감한 값은 애초에 빼고 물어보면 그만이었습니다.
근데 코딩 에이전트는 다릅니다. 채팅창에 붙여 넣은 것만 보는 게 아니라, 저장소 안의 파일을 직접 열어보고, 명령을 실행하고, 이번 프로젝트라면 실기기에까지 접속합니다.
제가 뭘 보여줄지 고를 수 있는 구조가 아니라, 에이전트가 거의 모든 것에 접근할 수 있는 구조라는 뜻입니다.
이 차이가 생각보다 큽니다. 코드에 버그가 있으면 다시 고치면 되지만, AI가 테스트 도중에 실수로 로그아웃 버튼을 눌러버리거나, 설정을 바꿔버리거나, 결제까지 한다면 이건 "코드를 고쳐서" 되돌릴 수 있는 문제가 아닙니다.
오랫동안 QA를 하면서 "사람이 실수해도 되돌릴 수 있는 선"을 항상 생각했었는데, AI에게 실기기를 맡기면서 이 질문을 처음으로 마주하게 됐습니다.
그래서 어떻게 나눴나
크게 세 단계로 나눴습니다.
| 구분 | 내용 |
|---|---|
| 절대 금지 (승인해도 안 됨) | 결제·구매 액션 — 이건 사람이 허락해도 뚫을 수 없는 최상위 규칙으로 박아뒀습니다 |
| 승인 필요 (먼저 제안, 사람이 허락한 뒤에만 실행) | Appium 서버 기동, pytest 실행, 초기화, 앱 삭제/설치, 시스템 설정 변경, 로그인/로그아웃/회원가입 같은 계정 상태를 바꾸는 액션, 파일 쓰기·삭제 |
| 화이트리스트 (AI가 스스로 실행 가능) | 디바이스 목록 조회, 읽기 전용 쉘 명령 |
핵심은 AI가 기준 없이 알아서 위험 여부를 판단하게 두지 않았다는 겁니다. 대신 판단 기준을 구체적인 가이드라인으로 먼저 만들어 줬고, AI는 그 가이드라인에 따라 판단합니다. 그리고 그 판단이 맞는지는 제가 한 번 더 검토했습니다.
파일을 쓰고 지우는 걸 승인 필요로 둔 것도, 중요한 파일을 고치기 전에 원본을 날짜 폴더에 백업해두는 규칙을 만든 것도, 잘못 지우거나 덮어썼을 때 되돌릴 수 있는 선을 확보하기 위해서입니다.
세 단계로 나눈 기준
임의로 나눈 게 아니라, 세 가지 질문으로 걸렀습니다.
- 되돌릴 수 있는가? — 읽기만 하는 명령(디바이스 목록 조회 등)은 실행해도 되돌릴 게 없으니 화이트리스트로
- 사용자 계정 상태를 바꾸는가? — 로그인/로그아웃처럼 "상태"를 건드리는 건, 되돌릴 수는 있어도 그 과정에서 다른 검증을 다 망가뜨릴 수 있어서 승인 필요로
- 실제 서비스·비즈니스에 영향을 주는가? — 결제만큼은 승인 절차로도 못 뚫게, 아예 최상위 금지로 박았습니다. 사람이 실수로 승인해버릴 가능성 자체를 차단한 겁니다.
이 정도로 끝이 아닙니다
권한만 나눠두면 안전할 것 같지만, 화이트리스트라고 아무 확인 없이 실행하게 둔 건 아니었습니다. 화이트리스트 명령이라도 "지금 실행하려는 명령이 뭔지" 실행 직전에 항상 먼저 보여주게 했고, 한 번에 명령 하나만 실행하고 결과를 확인한 뒤에만 다음으로 넘어가게 했습니다. 예상 밖의 화면이 뜨면 그 자리에서 무조건 멈추고 사람한테 물어보게 해뒀고요.
심지어 원래 원칙대로면 값의 존재만 확인하면 되는 계정 화면의 개인정보 필드들도, 이것들만은 예외로 실제 값을 절대 출력하지 않고 기대값과의 일치 여부(True/False)만 남기게 했습니다.
임의로 만든 게 아닙니다
이 3단계는 설계하기 전에 미리 조사하고 정한 구조입니다. OWASP의 LLM 애플리케이션 보안 가이드를 먼저 찾아봤고, 거기서 "과도한 에이전시(Excessive Agency)"를 과도한 권한·기능·자율성 세 가지 원인으로 나누는 걸 참고해서 지금의 절대 금지 / 승인 필요 / 화이트리스트 구조를 설계했습니다. 그리고 한 번 정해두고 끝낸 게 아니라, 프로젝트를 진행하면서 새로운 위험이 보일 때마다 권한과 보안 규칙을 계속 강화해왔습니다.
나중에 알고 보니 업계에서는 이런 3단계 분류를 "Always / Ask / Never"이라 부르고 있었고, OWASP 기준으로 이 "과도한 에이전시" 항목은 2026년판에서 6위에서 3위로 뛰어오를 만큼 지금 뜨거운 주제였습니다.
다음 편
권한을 나눠도 남는 위험이 하나 있습니다. TV 화면에 적힌 글자를 AI가 "명령"으로 착각하는 문제입니다. 이 위험이 왜 생기는지, 그리고 어떻게 대응했는지는 거버넌스 시리즈의 다음 편에서 다루겠습니다.
