비인간 아이덴티티(NHI)란 무엇인가요? 머신 대 사람 80대 1·시크릿 2,865만 건 유출로 본 2026 기업 대응 완전 가이드

비인간 아이덴티티(NHI)란 무엇이고 왜 2026년 최대 보안 사각지대가 됐나요?

결론부터 말하면 NHI는 사람이 아닌 주체가 시스템에 접근할 때 쓰는 자격증명 전체를 가리키며, 기업 안에서 사람 계정보다 압도적으로 많은데도 관리 주체가 없다는 것이 문제의 본질입니다. 평균적인 기업에서 머신 아이덴티티 대 사람 계정 비율은 80대 1을 넘고, 클라우드 네이티브·DevOps 환경에서는 144대 1까지 올라갑니다. 보안 사고의 68%가 이미 머신 아이덴티티와 얽혀 있고, NHI의 71%는 권장 주기 안에 자격증명이 교체되지 않습니다. 여기에 AI 에이전트가 스스로 API를 호출하기 시작하면서 이 표면은 2026년 가장 빠르게 넓어지는 공격면이 됐습니다.

793일 잠들어 있던 서비스 계정 이야기
NHI는 정확히 무엇을 가리키나요
왜 지금 폭발적으로 늘어났을까요
실제로 어떻게 털리나요
AI 에이전트가 바꾼 판
기업이 밟아야 할 4단계 도입 절차
도구 선택 기준과 흔한 실패
FAQ
같이 읽으면 좋은 것들

793일 잠들어 있던 서비스 계정 이야기

보안 진단 사례 가운데 자주 인용되는 장면이 있습니다. 어느 조직의 클라우드 환경을 점검했더니 793일 동안 한 번도 로그인 기록이 없는 Azure 서비스 계정이 발견됐는데, 이 계정이 운영 구독 세 곳에 대해 소유자 수준의 권한을 그대로 들고 있었습니다. 만든 사람은 이미 퇴사했고, 어떤 자동화를 위해 만들었는지 기록도 남아 있지 않았습니다.

이런 계정은 보안팀 대시보드에서 잘 보이지 않습니다. 사람 계정이라면 인사 시스템과 연동돼 퇴사 시점에 자동으로 비활성화되지만, 서비스 계정에는 퇴사라는 이벤트가 없기 때문입니다. 프로젝트가 끝나도 계정은 남고, 남은 계정은 시간이 지날수록 아무도 건드리지 못하는 상태가 됩니다. 지웠다가 무엇이 멈출지 모르니까요.

실무에서 마주치는 장면은 이보다 더 일상적입니다. 소스 코드에 하드코딩된 API 키, 지라 티켓 본문에 붙여 넣은 운영 데이터베이스 비밀번호, 슬랙 스레드에 공유된 결제 게이트웨이 관리자 토큰. 하나하나는 사소한 편의엿지만 합치면 조직 전체를 여는 열쇠 꾸러미가 됩니다.

NHI는 정확히 무엇을 가리키나요

NHI(Non-Human Identity, 비인간 아이덴티티)는 사람이 직접 조작하지 않고도 인증하고 행동하는 모든 주체의 신원을 뜻합니다. 머신 아이덴티티라고도 부르며 범위는 생각보다 넓습니다.

유형	구체적 예	주된 자격증명
서비스 계정	애플리케이션 전용 계정, DB 접속 계정	비밀번호, 인증서
API 키·토큰	SaaS 연동 키, 결제 게이트웨이 토큰	정적 문자열
CI/CD 자격증명	GitHub Actions 토큰, 배포 파이프라인 시크릿	단기·장기 토큰
워크로드 아이덴티티	쿠버네티스 서비스어카운트, IAM 롤	프로젝션 토큰
IaC 프린시펄	테라폼 서비스 프린시펄	클라이언트 시크릿
자동화 봇	RPA 봇, 배치 스케줄러	계정+비밀번호
AI 에이전트	LLM 기반 자율 에이전트, MCP 클라이언트	OAuth 토큰, API 키

사람 아이덴티티와 비교하면 성격이 완전히 다릅니다. 사람은 입사·부서이동·퇴사라는 수명주기를 가지고, MFA를 걸 수 있으며, 이상 행동이 관찰되면 본인에게 확인할수 있습니다. NHI는 셋 다 해당하지 않습니다. 만들어진 기록이 없고, 두 번째 인증 요소를 붙일 사람이 없으며, 평소 행동 패턴을 물어볼 상대가 없습니다.

왜 지금 폭발적으로 늘어났을까요

숫자가 이야기를 대신합니다. 한 조사에 따르면 평균적인 기업의 머신 아이덴티티는 2021년 약 5만 개에서 2025년 25만 개로 다섯 배 늘었습니다. 다른 조사에서는 머신 대 사람 비율이 100대 1로 보고됐고 일부 조직은 500대 1에 달했습니다.

증가의 동력은 세 가지입니다.

첫째, 마이크로서비스와 컨테이너입니다. 모놀리식 애플리케이션 하나가 서비스 스무 개로 쪼개지면 서비스 간 인증이 스무 배로 늘어납니다. 쿠버네티스 파드 하나하나가 아이덴티티를 갖습니다.

둘째, SaaS 연동입니다. 조직이 쓰는 SaaS가 늘어날수록 이들을 잇는 API 키도 늘어납니다. 문제는 이 키의 상당수를 보안팀이 아니라 현업 부서가 직접 발급한다는 점입니다.

셋째, AI 에이전트입니다. 이 부분은 뒤에서 따로 다루겠습니다.

증가 속도보다 심각한 것은 관리 공백입니다. NHI의 97%가 실제 필요 이상의 권한을 갖고 있고, 머신 아이덴티티의 0.01%가 클라우드 리소스의 80%를 통제한다는 분석도 있습니다. 소수의 과도한 권한 계정에 리스크가 극단적으로 집중돼 있다는 뜻인데요. 반대로 보면 이 0.01%만 제대로 잡아도 위험의 상당 부분을 줄일수 있다는 의미이기도 합니다.

실제로 어떻게 털리나요

공격 경로는 대체로 네 갈래로 정리됩니다.

1. 시크릿 유출. 가장 흔합니다. GitGuardian의 조사에 따르면 2025년 한 해 동안 공개 깃허브 저장소에 새로 추가된 하드코딩 시크릿이 2,865만 건에 달했습니다. 공격자는 저장소를 스캔해 유효한 키를 찾고, 그 키로 곧장 내부 API를 호출합니다. 사람 계정처럼 비밀번호를 추측할 필요가 없습니다.

2. 부실한 오프보딩. OWASP가 정리한 NHI Top 10에서 부적절한 오프보딩이 1순위 위험으로 지목된 이유입니다. 프로젝트가 끝나고 통합이 해지돼도 자격증명은 살아 있습니다. 앞의 793일짜리 계정이 여기에 해당합니다.

3. 권한 상승. 낮은 권한의 CI 토큰 하나를 얻은 뒤, 그 토큰으로 배포 파이프라인을 조작해 더 높은 권한의 자격증명을 꺼내는 방식입니다. 파이프라인은 정의상 프로덕션에 접근할수 있으므로 중간 단계 하나만 뚫려도 마지막까지 이어집니다.

4. 공급망 경유. 서드파티 SaaS에 발급해 준 토큰이 그 업체 쪽에서 유출되는 경로입니다. 우리 조직의 보안 수준과 무관하게 뚫립니다.

네 갈래 모두 공통점이 있습니다. 정적이고 오래 살아 있는 자격증명이 전제라는 점입니다. 그래서 대응의 방향도 하나로 모입니다. 오래 사는 비밀을 없애는 것입니다.

AI 에이전트가 바꾼 판

2026년 이 주제가 급부상한 결정적 이유는 AI 에이전트입니다. 가트너는 아이덴티티·접근 관리가 AI 에이전트에 맞춰 재편되는 흐름을 2026년 6대 사이버보안 트렌드 가운데 하나로 꼽았습니다.

에이전트는 기존 NHI와 세 가지 점에서 다릅니다.

첫째, 행동이 비결정적입니다. 배치 스크립트는 매번 같은 순서로 같은 API를 호출하지만, 에이전트는 상황에 따라 다른 도구를 다른 순서로 씁니다. 정상 행동 기준선을 세우기가 훨씬 어렵습니다.

둘째, 권한이 넓게 요구됩니다. 사용자가 무엇을 시킬지 모르니 개발자는 일단 넉넉하게 권한을 부여합니다. 최소 권한 원칙과 정면으로 충돌하는 지점입니다.

셋째, 사람을 대신해 행동합니다. 에이전트가 사용자를 대리해 결제하거나 문서를 수정할 때, 그 행위의 책임 주체가 사용자인지 에이전트인지 시스템인지가 로그에 명확히 남지 않는 경우가 많습니다. 위임 체인을 기록하지 않으면 사후 추적이 불가능해집니다.

여기에 프롬프트 인젝션이 결합하면 위험이 곱해집니다. 외부 문서 한 줄이 에이전트의 도구 호출을 유도하고, 그 도구가 실제 권한을 가진 NHI로 실행되는 구조입니다. 에이전트 보안이 결국 아이덴티티 문제로 수렴하는 이유입니다.

기업이 밟아야 할 4단계 도입 절차

1단계 — 발견과 인벤토리. 없는 것은 지킬수 없습니다. 클라우드 계정의 서비스 계정, 애플리케이션의 API 키, CI/CD 파이프라인의 시크릿, SaaS 연동 토큰을 전수 조사합니다. 일회성 조사로 끝내면 3개월 뒤 다시 어긋나므로 지속적 자동 탐지로 설계해야 합니다. 각 항목에 소유자를 지정하는 것이 이 단계의 진짜 목표입니다.

2단계 — 최소 권한 재조정. 부여된 권한과 실제 사용 로그를 비교해 쓰지 않는 권한을 회수합니다. 신규 배포는 처음부터 최소 권한을 기본값으로 두고, 필요할 때 올리는 방향으로 뒤집습니다. 앞서 언급한 0.01%의 고권한 계정부터 손대면 효과가 가장 큽니다.

3단계 — 정적 자격증명 제거. 장기 API 키를 단기 토큰으로 바꾸고, 워크로드 아이덴티티 페더레이션을 도입해 비밀 없이 인증하도록 전환합니다. 남는 시크릿은 볼트에 넣고 자동 로테이션 주기를 겁니다. 71%가 제때 교체되지 않는다는 통계는 수동 로테이션이 작동하지 않는다는 증거입니다.

4단계 — 수명주기 연동. 프로젝트 종료, 서비스 폐기, 계약 해지 시 관련 NHI가 자동으로 회수되도록 프로세스를 만듭니다. 사람 계정이 인사 시스템과 연동되듯, NHI는 자산관리·프로젝트 관리 시스템과 연동돼야 합니다.

네 단계를 한 번에 밀어붙이는 조직은 대개 실패합니다. 현실적인 순서는 범위를 좁혀 한 바퀴를 완주하는 것입니다. 예컨대 결제나 고객 데이터를 다루는 프로덕션 계정 하나만 골라 1단계부터 4단계까지 끝까지 돌려 보면, 조직 안에서 어느 지점이 병목인지가 드러납니다. 대개는 기술이 아니라 소유자를 특정하지 못하는 단계에서 멈춥니다. 그 병목을 확인한 뒤 범위를 넓히는 편이 전사 일괄 적용보다 훨씬 빠릅니다.

측정 지표도 함께 정해 두는 편이 좋습니다. 실무에서 자주 쓰이는 네 가지는 인벤토리 커버리지, 소유자 지정률, 90일 이상 미사용 자격증명 수, 그리고 평균 자격증명 수명입니다. 마지막 지표가 특히 유용한데, 이 값이 줄어들면 나머지 위험도 함께 줄어드는 경향이 있기 때문입니다.

도구 선택 기준과 흔한 실패

시장은 세 부류로 나뉩니다. 시크릿 관리 도구(볼트 계열), NHI 거버넌스 플랫폼(탐지·권한 분석 중심), 그리고 기존 IAM·CIEM 제품의 확장 기능입니다. 하나로 전부 해결되지 않으므로 조합이 필요합니다.

선택 기준은 네 가지로 압축됩니다.

멀티클라우드와 SaaS를 아우르는 탐지 범위
부여 권한이 아닌 실사용 기반 권한 분석 제공 여부
기존 CI/CD·볼트와의 연동 깊이
에이전트 위임 체인을 남기는 감사 로그 설계

도입 순서를 잘못 잡으면 비용만 들고 위험은 그대로 남습니다. 흔한 실패는 도구를 먼저 사고 인벤토리를 나중에 만드는 순서입니다. 무엇이 있는지 모르는 상태에서 플랫폼을 붙이면 경고만 수천 건 쏟아지고 아무도 처리하지 못합니다. 또 하나는 개발 생산성을 고려하지 않은 강제 로테이션입니다. 애플리케이션이 토큰 갱신을 처리하지 못하는 상태에서 로테이션 주기를 걸면 장애가 나고, 장애가 나면 예외가 늘고, 예외가 늘면 제도가 무너집니다. 순서는 언제나 가시성 → 소유자 지정 → 권한 축소 → 자동화입니다.

FAQ

NHI 관리는 기존 IAM으로 안 되나요?

부분적으로만 됩니다. 기존 IAM은 사람 중심으로 설계돼 인사 시스템 연동, MFA, 접근 승인 워크플로를 전제합니다. NHI에는 이 세 가지가 모두 적용되지 않습니다. 특히 자격증명이 코드와 설정 파일 안에 흩어져 있다는 점이 결정적 차이라, 소스 저장소와 CI/CD 파이프라인까지 훑는 별도의 탐지 계층이 필요합니다.

중소 규모 조직도 지금 시작해야 하나요?

규모와 무관하게 시작할 가치가 있습니다. 계정 수가 적을수록 인벤토리를 만드는 비용이 낮기 때문입니다. 상용 플랫폼 없이도 클라우드 제공자의 기본 도구로 미사용 자격증명을 찾고, 저장소 시크릿 스캐닝을 켜고, 장기 키를 단기 토큰으로 바꾸는 것만으로 위험의 상당 부분이 줄어듭니다.

정확도는 어떤가요? 오탐이 많지 않나요?

탐지 자체의 오탐보다 문제는 우선순위 부재입니다. 수천 개의 NHI가 한꺼번에 나열되면 처리 순서를 정하지 못해 방치됩니다. 도입 초기에는 프로덕션 접근 권한이 있고, 최근 90일 사용 이력이 없으며, 자격증명이 1년 이상 교체되지 않은 항목처럼 조건을 좁혀 다루는 편이 실효성이 높습니다.

기존 방식과 비교해 실제로 시간이 얼마나 절감되나요?

가장 크게 줄어드는 것은 사고 대응 시간입니다. 인벤토리와 소유자 정보가 있으면 유출된 키 하나를 무효화하는 데 필요한 판단이 몇 시간에서 몇 분으로 줄어듭니다. 반대로 인벤토리가 없으면 그 키를 지웠을 때 어떤 서비스가 멈추는지 몰라 무효화 자체를 주저하게 됩니다.

AI 에이전트를 도입할 때 아이덴티티는 어떻게 설계해야 하나요?

사용자 계정을 공유해 쓰게 하는 방식은 피해야 합니다. 에이전트마다 고유 아이덴티티를 부여하고, 사용자를 대리할 때는 위임 관계를 토큰에 담아 감사 로그에 남기는 구조가 권장됩니다. 권한은 도구 단위로 잘게 나누고, 결제나 삭제처럼 되돌리기 어려운 행위에는 사람의 승인 단계를 유지하는 편이 안전합니다.