머신 아이덴티티(NHI) — 사람보다 많아진 '비인간' 계정이 최대 보안 구멍이 된 이유

머신 아이덴티티(Non-Human Identity, NHI)는 사람이 아니라 서비스·워크로드·스크립트·봇이 시스템에 접근할 때 쓰는 '계정'을 말한다. API 키, 서비스 계정, OAuth 토큰, 인증서, CI/CD 파이프라인의 비밀값이 전부 여기에 들어간다. 최근 보안 업계가 여기에 눈을 돌린 이유는 단순하다. 한 조직 안에서 이런 비인간 신원의 수가 직원 수를 한참 앞질렀기 때문이다.

사람 계정은 그래도 관리가 된다. 입사하면 만들고, 퇴사하면 지운다. 비밀번호는 주기적으로 바꾸고 MFA를 건다. 문제는 머신 아이덴티티다. 마이크로서비스 하나가 뜨면 토큰이 여러 개 발급되고, 그 토큰이 어디서 쓰이는지, 언제까지 유효한지, 누가 만들었는지 아무도 추적하지 않는 경우가 흔하다.

왜 지금 문제가 되나

클라우드 네이티브로 넘어오면서 한 애플리케이션이 수십 개의 작은 서비스로 쪼개졌다. 서비스끼리 통신하려면 서로를 인증해야 하고, 그때마다 신원이 필요하다. 여기에 SaaS 연동, 서드파티 통합, 자동화 스크립트, AI 에이전트까지 얹히면 신원의 개수는 걷잡을 수 없이 불어난다. AI 에이전트가 대신 API를 호출하기 시작하면서 이 곡선은 더 가팔라졌다.

그런데 관리 도구는 여전히 '사람'을 전제로 설계돼 있다. IAM 콘솔, 온보딩·오프보딩 프로세스, 접근 리뷰가 전부 사람 계정 중심이다. 머신 신원은 개발자가 필요할 때 그때그때 만들고, 만든 사람이 팀을 떠나면 그 토큰은 주인 없이 남는다. 이걸 업계에서는 시크릿 스프롤(secret sprawl)이라고 부른다.

사람 신원과 무엇이 다른가

공격자가 노리는 지점

정적 키의 가장 큰 약점은 '한 번 새면 계속 유효하다'는 점이다. 비밀번호는 유출돼도 사용자가 바꾸면 무력화되지만, 코드에 하드코딩된 액세스 키는 아무도 로테이션하지 않으면 몇 년째 살아 있다. 공개 저장소, 컨테이너 이미지 레이어, CI 로그, 클라이언트 번들에 실수로 커밋된 키를 자동으로 긁어가는 봇이 상시 돌고 있다는 건 이미 상식이다.

• 과다 권한 — 귀찮다는 이유로 서비스 계정에 넓은 권한을 주면, 그 토큰 하나가 뚫렸을 때 피해 범위가 조직 전체로 번진다.
• 공유 크레덴셜 — 여러 서비스가 같은 키를 돌려 쓰면 누가 사고를 냈는지 추적이 불가능하고, 폐기하면 멀쩡한 서비스까지 죽는다.
• 서드파티 연동 — 외부 SaaS에 발급한 토큰은 우리 통제 밖이다. 그쪽이 뚫리면 우리 데이터도 함께 노출된다.

대응은 결국 '수명 짧게, 권한 좁게'

해법의 방향은 뚜렷하다. 정적인 장기 키를 수명이 짧은 동적 크레덴셜로 바꾸는 것이다. 워크로드가 필요할 때 그 순간의 신원을 증명하면, 짧게 유효한 토큰을 발급받아 쓰고 곧 만료시킨다. 클라우드 제공자의 워크로드 아이덴티티 페더레이션, SPIFFE/SPIRE 같은 표준, 시크릿 매니저의 동적 시크릿이 모두 이 방향을 가리킨다.

그리고 최소 권한. 서비스 계정마다 '이 작업에 딱 필요한 만큼만' 권한을 준다. 여기에 발급된 신원을 한곳에서 목록화하고, 소유자를 지정하고, 안 쓰는 것을 주기적으로 회수하는 거버넌스가 붙어야 한다. 화려한 신기술이 아니라 지루한 목록 관리가 실제로 사고를 막는다.

비밀번호 없는 시대를 이야기하지만, 정작 뒤에서 시스템을 움직이는 건 여전히 방치된 키와 토큰이다. 사람의 로그인을 아무리 강화해도 머신 신원을 방치하면 뒷문은 활짝 열려 있는 셈이다.

자주 묻는 질문

머신 아이덴티티(NHI)와 시크릿 관리는 같은 말인가요?

겹치지만 같지는 않습니다. 시크릿 관리는 API 키·비밀번호 같은 값을 안전하게 보관·주입하는 데 초점이 있고, 머신 아이덴티티는 그 값이 대표하는 '신원' 자체를 누가 소유하고 어떤 권한을 갖는지 전체 수명 주기를 관리하는 더 넓은 개념입니다. 시크릿 관리는 NHI 보안의 한 축입니다.

왜 머신 계정에는 MFA를 못 거나요?

MFA는 사람이 그 순간 개입해 두 번째 요소를 입력하는 것을 전제로 합니다. 서비스가 자동으로 API를 호출하는 상황에는 사람이 없죠. 그래서 대안으로 수명이 짧은 동적 토큰, 워크로드 아이덴티티 기반 인증, 인증서 회전 같은 방식으로 '유출돼도 곧 쓸모없어지게' 만드는 전략을 씁니다.

가장 먼저 무엇부터 손봐야 하나요?

코드와 저장소, 로그에 하드코딩된 정적 키를 찾아내는 것이 우선입니다. 시크릿 스캐닝으로 노출된 값을 색출해 즉시 회전시키고, 만료 없는 장기 키를 수명 짧은 크레덴셜로 바꾸는 것부터 시작하면 위험을 가장 빠르게 줄일 수 있습니다.

AI 에이전트가 늘면 이 문제가 더 커지나요?

그렇습니다. 에이전트는 사람 대신 여러 API와 도구를 호출하므로 그만큼 새로운 머신 신원과 토큰을 요구합니다. 에이전트에 넓은 권한을 통째로 주면 그 하나가 탈취됐을 때 피해가 큽니다. 에이전트별로 권한을 좁게 나누고 수명 짧은 토큰을 쓰는 설계가 점점 더 중요해지고 있습니다.