AI VIDEO BRIEFING

AI 에이전트 인프라의 조건: 에이전트 정체성과 권한, 얇아지는 하네스, 단계별 ROI 측정법

앤트로픽 클로드 플랫폼 팀이 밝힌 에이전트 인프라의 현재를 정리했다. 에이전트가 스스로 권한을 요청하는 정체성 모델, 얇아지는 하네스와 그 위에 얹히는 조합 전략, 개인에서 팀으로 넓혀 가는 ROI 측정 순서를 짚는다.

에이전트가 인프라가 될 때: 클로드 플랫폼 팀이 말하는 정체성·하네스·ROI 영상 대표 이미지

핵심 메시지

  • 여섯 달 전만 해도 플랫폼의 실체는 추론과 토큰에 접근하는 API였지만, 지금은 인프라와 하네스 엔지니어링 부담을 대신 떠안는 기능들이 붙고 있다.
  • 에이전트는 사람의 계정을 빌려 쓰는 대신 자기 정체성을 갖고, 목표 달성에 필요한 접근 권한을 스스로 요청하고 감사받는 방향으로 간다.
  • 모델이 똑똑해지면서 업무 절차를 촘촘히 규정하던 하네스는 얇아지고, 대신 여러 전략을 조합하는 상위 구조가 등장하고 있다.
  • 확산을 막는 것은 모델 성능이 아니라 20년 전 가정에 머문 보안·컴플라이언스 기준과 평가 체계의 부재다.
  • ROI는 거대한 사내 프로세스부터 손대지 말고 개인의 속도에서 시작해 팀, 그다음 부서 간 프로세스로 넓히는 편이 성공 확률이 높다.

쉽게 이해하기

앤트로픽의 클로드 플랫폼 담당자들이 에이전트 인프라를 주제로 나눈 대담이 공개됐다. 제품 관리자와 엔지니어링 책임자, 제품 책임자가 참여해 지난 반년 사이 무엇이 달라졌고 기업들이 어디서 막히는지를 짚었다. 논의의 전제는 에이전트가 프롬프트를 넣는 도구에서 업무를 돌리는 인프라로 옮겨가고 있다는 것이다. 반년 전까지 플랫폼은 사실상 추론과 토큰에 접근하게 해 주는 API였지만, 지금은 인프라와 하네스 엔지니어링 문제를 플랫폼이 대신 떠안는 쪽으로 기능이 늘고 있다.

에이전트 정체성 문제는 흥미로운 방향으로 정리됐다. 에이전트는 사람의 권한에 얹히는 대신 별도의 정체성을 갖는 편이 맞다는 것이다. 구체적으로는 에이전트가 원하는 결과를 전달받고 그 결과를 내려면 어떤 접근 권한이 필요한지 되물으면, 사용자가 일부는 승인하고 일부는 거부하는 식이다. 승인된 범위 안에서 에이전트는 스스로 서비스 계정에 가까운 것을 만들고, 그 뒤로는 감사 기록으로 행동을 검증할 수 있다.

왜 하필 지금 이런 워크플로가 성립하느냐는 질문에는 두 가지 답이 나왔다. 하나는 모델의 비결정성이 예전만큼 골칫거리가 아니라는 점이다. 과거에는 먼저 이걸 하고 그다음 저걸 한다는 표준 절차를 모델 주위에 잔뜩 쌓아야 했지만, 이제는 적당한 가드레일 안에서 모델이 필요한 단계를 스스로 찾아낸다. 다른 하나는 인프라로, 에이전트가 작업 공간에 상주하다가 어떤 신호에 깨어나 한동안 일을 돌리고 준비가 되면 돌아오는 구조를 뒷받침할 기반이 갖춰졌다.

그 결과 하네스는 점점 얇아진다. 몇 달 전만 해도 사람들은 조건 분기로 뒤엉킨 복잡한 업무 절차 상자를 만들었고 그런 구조는 대체로 취약했는데, 모델이 도구 호출과 추론에서 나아지면서 제약을 하나씩 지울 수 있게 됐다는 것이다. 대신 얇아진 하네스 위에 상위 구조가 생긴다. 여러 에이전트가 같은 문제를 놓고 경쟁하게 하거나, 하나가 아이디어를 내면 다른 하나가 반박하게 하거나, 막혔을 때 더 똑똑한 쪽에 자문을 구하게 하는 식의 전략 조합이다. 현장 사례로는 20년 가까이 설비를 다뤄 온 한 사람의 판단이 은퇴와 함께 사라지던 제조 공장에서, 표준 작업 절차와 설비 신호를 넘겨받은 에이전트가 그 판단의 상당 부분을 대신하게 된 이야기가 소개됐다.

막히는 지점은 기술이 아니라 조직이었다. 보안과 컴플라이언스 기준이 20년 전 가정 위에서 작동하는데 에이전트는 그 전제를 근본부터 흔들고, 무엇이 안전한 에이전트인지에 대한 체크리스트를 다시 쓰는 일이 오래 걸린다. ROI에 대해서는 사내 프로세스 120개를 한 번에 바꾸려 하지 말고 한 사람이 얼마나 빨라졌는지에서 출발해 팀, 그다음 여러 팀이 얽힌 프로세스로 넓히라는 조언이 나왔다. 엔지니어링 팀의 사람 구성은 예전과 크게 다르지 않지만 티켓을 처리하던 다수가 각자 에이전트를 지휘하는 구조로 옮겨가고 있고, 실패 모드로는 조율 없이 각자 프로토타입을 쏟아내는 과잉 독립이 지목됐다.

주요 인사이트

  • 에이전트에게 사람 계정을 빌려주는 대신 별도 정체성을 주자는 제안은 보안 논의를 '접근을 막을 것인가'에서 '무엇을 승인하고 어떻게 감사할 것인가'로 옮긴다. 권한 요청과 감사 로그가 한 쌍으로 묶인다는 점이 핵심이다.
  • 하네스가 얇아진다는 진단은 그동안 쌓아 온 절차 코드가 자산이 아니라 부채가 될 수 있다는 뜻이기도 하다. 모델이 좋아질수록 제약을 지우는 작업이 정기적인 유지보수 항목이 된다.
  • 여러 에이전트를 경쟁시키거나 서로 반박하게 하는 구조는 단일 에이전트의 성능을 끌어올리는 대신 아키텍처로 품질을 확보하려는 시도다. 하네스가 얇아진 자리를 이런 조합 전략이 채운다.
  • ROI를 개인에서 시작하라는 조언은 단순해 보이지만, 부서 간 프로세스가 표준 절차도 전문성도 공유하지 않는 사람들로 엮여 있다는 현실 인식에서 나온다. 가장 어려운 대상부터 자동화하려는 시도가 실패하는 이유이기도 하다.
  • 팀 구성이 그대로인데 산출량만 늘었다는 관찰은 인력 대체보다 역할 이동에 가깝다. 티켓 처리자가 줄고 설계 판단을 하는 사람이 늘어난다는 것은 채용과 평가 기준이 함께 바뀐다는 뜻이다.

자주 묻는 질문

에이전트 정체성이란 구체적으로 어떤 구조인가요?

에이전트가 사람의 권한에 얹히지 않고 자기 정체성을 갖는 방식입니다. 원하는 결과를 전달받은 에이전트가 그 결과를 내려면 어떤 접근 권한이 필요한지 되묻고, 사용자가 일부를 승인하거나 거부하면 승인된 범위 안에서 서비스 계정에 가까운 것을 만들어 일합니다. 이후 행동은 감사 기록으로 검증할 수 있습니다.

왜 하네스가 얇아진다고 보나요?

과거에는 모델의 비결정성 때문에 조건 분기가 뒤엉킨 업무 절차를 모델 주위에 쌓아야 했고 그 구조는 취약했습니다. 모델이 도구 호출과 추론에서 나아지면서 적당한 가드레일 안에서 필요한 단계를 스스로 찾아내게 됐고, 그만큼 제약을 걷어낼 수 있게 됐다는 설명입니다.

에이전트 도입의 ROI는 어떻게 측정하라고 하나요?

사내 프로세스 전체를 한 번에 바꾸려 하지 말고 개인의 속도에서 출발하라고 권합니다. 한 사람이 빨라지면 팀 단위 속도를 보고, 그다음 여러 팀이 얽힌 프로세스로 넓히는 순서입니다. 초기 지표는 속도와 생산성에 두고, 재무 지표나 사용자 지표는 그 뒤에 붙이는 편이 낫다고 봅니다.

기업이 에이전트를 확대하지 못하는 가장 큰 이유는 무엇인가요?

보안과 컴플라이언스 기준, 그리고 평가 체계의 부재가 꼽혔습니다. 많은 팀의 보안 가정이 20년 전 전제 위에 서 있는데 에이전트는 그 전제를 근본부터 바꾸기 때문에, 무엇이 안전한 에이전트인지에 대한 체크리스트를 다시 쓰는 일 자체가 오래 걸린다는 것입니다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗

관련 AI 소식