AI 에이전트에게 우리 계정, 그냥 빌려줘도 될까?

에이전트 아이덴티티 논의가 빨라지는 지금, 작은 팀이 30분 안에 할 수 있는 계정·권한·로그 정리법.

AI 트렌드 대표 이미지

요즘 작은 팀에서도 에이전트가 실제로 일을 합니다.
코딩 에이전트가 리포지토리에 PR을 올리고, 리서치 에이전트가 시트를 채우고, 고객문의 에이전트가 메일함을 뒤집니다.
그런데 대부분은 대표님 계정으로 로그인한 상태에서 돌아갑니다.
최근 업계 흐름을 보면 이 문제가 '나중에 정리할 일'에서 '지금 정리할 일'로 넘어왔습니다.
미국 NIST는 에이전트 시스템을 어떻게 식별·인증·인가하고 보호할지에 대해 업계 의견을 모으고 있고, 싱가포르 IMDA는 올해 초 다보스에서 에이전틱 AI용 거버넌스 프레임워크를 공개했습니다.
책임 소재, 투명성, 인간 감독, 데이터 거버넌스 네 축이었죠.
대기업 이야기로 들리지만, 실무에서는 아주 작은 질문 하나입니다. 이 에이전트는 누구의 신분으로 일하고 있나?

왜 지금 '에이전트 계정'을 따로 만들어야 할까?

공유 계정으로 에이전트를 돌리면 사고가 났을 때 누가 했는지 알 수 없고, 되돌릴 근거도 남지 않습니다.
2026년 에이전트 아이덴티티 표준 논의의 핵심어도 '위임'입니다.
사람과 에이전트의 신분을 분리해 두고, 에이전트가 사람의 권한을 위임받아 행동했다는 사실을 기록에 남기는 방식이죠.

예를 들어 대표 계정으로 코딩 에이전트를 돌리면 커밋, 브랜치 삭제, 배포 기록이 전부 대표 이름으로 남습니다.
3개월 뒤 "이 설정 누가 바꿨지?"라는 질문에 아무도 답할 수 없습니다.
반대로 에이전트에게 자기 계정을 주면 로그가 "김대표가 지시 → devbot이 실행" 두 줄로 남고, 문제가 생겼을 때 사람 계정은 그대로 두고 에이전트 키만 끊을 수 있습니다.

많은 팀이 이 단계를 건너뛰는 이유는 시간이 없어서가 아니라, 에이전트를 '도구'로 보기 때문입니다.
하지만 실제로 돌아가는 방식을 보면 에이전트는 도구가 아니라 권한을 가진 계정입니다.
노트북에 깔린 앱과 달리, 우리 이름으로 로그인해 데이터를 읽고 무언가를 바꿉니다.
신입사원이 첫날 받는 계정 세팅을 떠올려 보면, 에이전트에게도 같은 절차가 필요하다는 게 금방 이해됩니다.

작은 팀은 무엇부터 바꾸면 될까?

좋은 소식과 나쁜 소식이 있습니다.
아직 업계에 하나의 지배적 표준이 없어서, 현장에서는 커스텀 클레임을 담은 JWT 형태 토큰, mTLS 인증서, 클라우드 관리형 아이덴티티가 뒤섞여 쓰입니다.
그래서 작은 팀은 표준이 정리되기를 기다릴 필요가 없습니다.
아래 운영 습관 다섯 개만 이번 주에 만들어 두면 나중에 어떤 표준이 이겨도 그대로 갈아탈 수 있습니다.

  1. 에이전트마다 별도 계정: 사람 계정을 빌려주지 말고 devbot, support-bot 같은 봇 사용자를 만듭니다.
    슬랙, 깃허브, 노션, 구글 워크스페이스 모두 봇/서비스 계정을 지원합니다.
  2. 권한은 작업 단위로: '전체 읽기·쓰기'가 아니라 '이 리포지토리 하나', '이 폴더만', '읽기 전용'으로 좁힙니다.
    만료 없는 장기 키는 만들지 않습니다.
  3. 되돌릴 수 없는 작업은 분리: 결제, 환불, 대량 발송, 삭제 권한은 에이전트 기본 자격증명에서 아예 빼두고, 필요할 때만 사람이 별도 승인 경로로 실행합니다.
  4. 외부 텍스트를 읽는 에이전트는 쓰기 권한과 떼어놓기: 메일, 깃허브 이슈, 웹페이지처럼 남이 쓴 글을 읽는 에이전트는 프롬프트 인젝션에 노출됩니다.
    읽는 역할과 쓰는 역할을 다른 계정으로 나누세요.
  5. 회수 리허설: 키를 끊는 절차를 한 장으로 적어두고, 분기에 한 번은 실제로 끊어봅니다.
    문서만 있고 해본 적 없는 절차는 사고 당일에 작동하지 않습니다.

이 정리가 매출에도 도움이 될까?

됩니다.
접근 통제, 감사 로그, 데이터 저장 위치는 이미 B2B 계약 검토와 보안 문서에서 반복해서 나오는 질문입니다.
에이전트를 쓰는 팀이라면 여기에 '에이전트 권한' 항목이 추가됩니다.

3인 팀이라도 에이전트 목록, 각자의 권한 범위, 로그 보관 기간을 한 장에 정리해 두면 실사 대응이 끝납니다.
반대로 "저희는 대표 계정으로 돌립니다"라고 답하면, 기능이 아무리 좋아도 계약이 한 달 밀립니다.
이번 주 과제는 간단합니다.
지금 우리 시스템에 로그인해 있는 에이전트를 종이에 적어보세요.
대개 다섯 개를 넘지 않습니다.
그중 삭제·결제 권한을 가진 것부터 계정을 떼어내면, 오늘 30분으로 가장 큰 위험 하나가 사라집니다.

자주 묻는 질문

에이전트에게 사람 계정을 빌려주면 실제로 어떤 문제가 생기나요?
사고의 원인 추적과 권한 회수가 동시에 막힙니다. 로그에는 사람 이름만 남아 누가 지시했고 무엇이 자동 실행이었는지 구분할 수 없고, 키를 끊으려면 그 사람의 업무까지 함께 멈춰야 합니다. 에이전트가 자기 계정을 가지고 있으면 사람 계정은 살려두고 에이전트만 차단할 수 있습니다.
직원이 2~3명인데도 봇 계정을 따로 만들 필요가 있을까요?
규모보다 권한의 성격이 기준입니다. 에이전트가 삭제, 결제, 대량 발송처럼 되돌릴 수 없는 작업에 손댈 수 있다면 인원 수와 무관하게 계정을 분리하는 것이 좋습니다. 반대로 읽기 전용 리서치 에이전트라면 읽기 권한만 준 토큰 하나로도 충분합니다.
표준이 아직 정리되지 않았다면 지금 세팅한 게 무용지물이 되지 않을까요?
지금 필요한 것은 특정 기술 스택이 아니라 운영 습관입니다. 계정 분리, 좁은 권한, 만료되는 토큰, 회수 절차는 어떤 표준이 자리 잡아도 그대로 쓰입니다. 나중에 위임 규격이 정리되면 이미 정리된 목록을 그 규격에 맞춰 옮기기만 하면 됩니다.