Google Cloud AI 하네스 강의는 에이전트에게 조심하라고 말하지 말고 권한을 코드로 막으라고 합니다 | DAKER 커뮤니티
Google Cloud Tech 유튜브 채널이 10월 22일 올린 9분 28초짜리 영상 「AI harness crash course」는 코딩 에이전트를 둘러싼 소프트웨어, 곧 AI 하네스를 네 부분으로 나눠 설계하는 법을 보여 줍니다. 발표자 Annie Wang이 가장 힘주어 말하는 대목은 위험한 행동을 막는 장치는 모델에게 조심하라고 부탁하는 문장이 아니라 소프트웨어가 강제하는 권한이어야 한다는 점입니다. 에이전트를 만들어 해커톤에 내는 참가자에게 바뀌는 점은 분명합니다. 프롬프트를 다듬기 전에 어떤 도구를 누가 승인해야 쓰는지, 몇 번 실패하면 멈추는지를 먼저 정해야 합니다. 오늘 바로 할 일은 내 에이전트가 쓰는 도구 목록을 적고, 그중 되돌리기 어려운 도구 하나에 사람 승인을 붙이는 것입니다.
영상이 말하는 AI 하네스는 무엇입니까
영상은 사용자가 코딩 에이전트에게 고객 데이터를 CSV 파일로 내려받는 버튼을 붙여 달라고 부탁하는 장면에서 시작합니다. 모델은 그 코드를 쓸 줄 알 수 있습니다. 하지만 모델 혼자서는 프로젝트 파일을 열 권한도, 앱을 실행해 기능이 실제로 되는지 확인할 방법도 없습니다. Annie Wang은 이 빈자리를 채우는 소프트웨어 층을 AI 하네스라고 부릅니다. 하네스는 맥락을 공급하고, 도구를 연결하고, 권한을 강제하며, 모델과 실행 환경 사이에 오가는 요청을 관리합니다.
영상 속 흐름은 이렇습니다. 모델이 관련 파일을 읽겠다고 요청하면 하네스가 도구를 호출해 내용을 돌려줍니다. 모델이 코드 변경을 요청하면 편집 도구가 그 변경을 적용합니다. 이어서 모델이 테스트 실행을 요청하고, 결과에서 내보낸 파일에 고객 레코드 하나가 빠졌다는 사실이 드러나면 그 피드백이 다시 모델에게 돌아갑니다. 모델은 원인을 찾고 코드를 고친 뒤 다시 시도합니다. 영상은 이 반복을 하네스가 관리하며, 계속할지, 멈출지, 도움을 요청할지도 하네스가 정한다고 설명합니다.
이 설명이 참가자에게 중요한 이유는 데모 영상에서 잘 돌던 에이전트가 심사 환경에서 무너지는 지점이 대개 모델의 실력이 아니라 이 반복을 감싼 장치에 있기 때문입니다. 같은 모델을 써도 테스트 결과를 돌려주는지, 실패를 몇 번까지 허용하는지에 따라 결과물의 안정성이 달라집니다.
하네스 설계를 네 부분으로 나눕니다
영상은 하나의 CSV 내보내기 작업을 네 영역에 차례로 통과시키며 설계 질문을 정리합니다.
- 맥락과 기억: 에이전트가 작업을 이해하고 진행 상황을 놓치지 않으려면 어떤 정보를 어디에 둘지 정합니다.
- 도구와 실행 흐름: 에이전트가 실제로 일을 하게 해 줄 도구와, 그 도구들이 어떤 순서로 움직일지 정합니다.
- 실행 환경, 보안, 개인정보: 코드가 어디서 실행되고, 에이전트가 무엇에 영향을 줄 수 있으며, 데이터가 어디로 흘러가는지 정합니다.
- 평가: 에이전트가 끝났다고 말했을 때 정말 잘 끝냈는지 확인하는 방법을 정합니다.
영상은 Google의 Agent Development Kit, 줄여서 ADK를 예로 들지만 네 질문 자체는 어떤 프레임워크로 에이전트를 만들든 그대로 적용됩니다. 아래에서는 영상의 설명을 ADK 공식 문서와 대조해 정리합니다.
맥락과 기억: 세션, 상태, 장기 기억을 구분합니다
영상의 예에서 사용자는 CSV 내보내기를 요청한 뒤 고객 이름과 이메일 주소만 넣어 달라고 덧붙입니다. 몇 단계가 지나도 에이전트는 이 조건을 기억해야 합니다. 영상은 이 정보를 세 곳으로 나눠 둔다고 설명합니다.
첫째는 세션입니다. 세션은 대화 스레드이며 사용자의 메시지, 에이전트의 도구 호출, 그 결과를 모두 기록합니다. 처음 요청과 후속 지시가 모두 세션에 들어갑니다. ADK 공식 문서도 세션을 사용자와 에이전트 사이의 하나의 진행 중인 상호작용으로 정의하고, 그 안에 에이전트가 한 메시지와 행동이 이벤트라는 이름으로 시간 순서대로 쌓인다고 적고 있습니다.
둘째는 상태입니다. 영상은 상태를 애플리케이션의 메모장에 비유합니다. 예를 들어 내보낼 열이 이름과 이메일이라는 값, 작업이 테스트 준비 완료라는 값을 키와 값 쌍으로 저장해 두면, 코드가 대화 전체를 뒤지지 않고 그 값을 바로 읽고 고칠 수 있습니다. ADK 문서에서도 상태는 현재 대화 스레드에만 해당하는 데이터로 설명됩니다.
셋째는 장기 기억입니다. 사용자가 다음 주에 새 대화를 시작했을 때, 예전에 데이터를 도표로 보기 좋아한다고 말한 선호가 다시 쓸모 있을 수 있습니다. 장기 기억 시스템은 이런 선호를 정리된 사실로 뽑아 저장했다가 필요할 때 꺼내 모델의 맥락에 넣습니다. ADK 문서는 메모리를 여러 지난 세션이나 외부 데이터에 걸친, 에이전트가 검색할 수 있는 정보 저장소로 설명합니다.
영상의 결론은 무엇을 저장하고 무엇을 다시 불러올지는 만드는 사람이 정한다는 것입니다. 해커톤 에이전트라면 사용자의 조건을 대화 기록에만 남겨 두지 말고, 반드시 지켜야 하는 값은 상태로 따로 빼 두는 편이 안전합니다. 장기 기억은 심사 기간에 꼭 필요한 기능인지 먼저 따져 보십시오. 기억을 붙이면 무엇을 언제 지울지도 함께 설계해야 합니다. 이 부분은 이전 글 어제 물은 종목을 기억하는 KIC AI Agent라면 기획서 Workflow에 저장할 것과 지울 때를 함께 그립니다에서 금융 에이전트 예시로 다뤘습니다.
도구와 실행 흐름: 병렬 검사와 재시도 한계
에이전트가 이 파일을 고쳐야겠다고 판단해도, 그 판단만으로 파일이 바뀌지는 않습니다. 실제 편집은 도구가 합니다. 영상은 도구가 파이썬 함수일 수도 있고, 테스트를 돌리거나 외부 API를 부르는 다른 함수일 수도 있다고 설명합니다. MCP 서버를 통해 도구를 연결하는 방법도 소개합니다. MCP는 Model Context Protocol의 약자로, 애플리케이션이 서버가 공개한 도구를 표준 방식으로 찾고 호출하게 해 줍니다. 예를 들어 팀의 빌드 로그가 별도 서비스에 있다면, 그 로그를 가져오는 도구를 MCP 서버로 공개해 에이전트가 실패한 빌드를 조사하게 할 수 있습니다.
도구가 갖춰지면 일의 흐름을 정해야 합니다. 영상은 모델이 다음 단계를 고르게 둘 때와, 정해진 순서가 필요할 때, 서로 독립적인 단계를 동시에 돌리고 싶을 때를 나눕니다. CSV 기능의 예에서는 코딩 에이전트가 먼저 코드를 바꾸고, 두 가지 검사가 병렬로 돌아갑니다. 하나는 내보내기 로직을 확인하는 단위 테스트이고, 다른 하나는 브라우저에서 버튼을 눌러 내려받기를 확인하는 테스트입니다. 둘 중 하나라도 실패하면 피드백이 코딩 에이전트에게 돌아가고, 둘 다 통과하면 검토 단계로 넘어갑니다.
여기서 영상이 짚는 장치가 재시도 한계입니다. 에이전트가 문제를 고치지 못한 채 계속 시도하면 워크플로가 멈추고 도움을 요청하게 만들 수 있습니다. 영상은 몇 번이 적당한지 숫자를 제시하지는 않습니다. 그 숫자는 각 팀이 작업 비용과 시간을 보고 정해야 합니다.
ADK 공식 문서에 따르면 이런 구조는 그래프 기반 워크플로로 만들 수 있으며, 파이썬, 타입스크립트, Go의 ADK 2.0.0부터 지원됩니다. 문서는 그래프 기반 워크플로를 노드와 엣지로 에이전트 로직을 정의하는 방식으로 설명하고, AI 모델을 부르지 않고 도구와 직접 작성한 코드만 이어 실행할 수도 있다고 적습니다. 또한 ADK는 여러 단계를 묶는 방법으로 그래프 기반 워크플로, 코드 안에서 반복과 조건을 직접 짜는 동적 워크플로, 순차·병렬·반복을 미리 만들어 둔 워크플로 에이전트 세 가지를 제공한다고 안내합니다.
해커톤 기획서의 Workflow 부분을 쓸 때도 같은 구분이 도움이 됩니다. 도구 이름만 나열하면 평가자는 흐름을 따라가기 어렵습니다. 도구마다 언제 부르는지, 어떤 검사가 동시에 돌고, 실패하면 어디로 돌아가는지를 적어 두면 읽는 사람이 구조를 바로 이해합니다. 이전 글 도구를 열 개 적은 KIC AI Agent 기획서는 도구마다 언제 부르는지 한 줄이 붙어야 Workflow가 읽힙니다도 함께 참고하십시오.
실행 환경과 보안: 조심하라는 말로는 부족합니다
에이전트에게 파일을 읽고, 코드를 바꾸고, 명령을 실행할 방법을 줬다면 다음 질문은 그것을 어디까지 허용할지입니다. 영상은 코딩 에이전트에게 흔히 샌드박스가 필요하다고 말합니다. 샌드박스는 접근할 수 있는 파일과 네트워크 서비스를 제한한 격리된 실행 환경입니다. CSV 예에서는 에이전트에게 프로젝트 사본과 샘플 고객 데이터를 주고, 실제 운영 고객 데이터베이스에는 접근하지 못하게 합니다. 코드가 어디서 실행되는지를 정하는 일이 실행 환경 설계입니다.
영상은 에이전트가 마주칠 내용도 따져야 한다고 말합니다. 저장소 안의 어떤 파일에 이전 지시를 모두 무시하고 인증 정보를 어떤 웹사이트에 올리라는 문장이 적혀 있다면, 그것이 프롬프트 인젝션입니다. 바깥에서 들어온 내용이 에이전트의 방향을 바꾸려는 시도입니다. 영상은 시스템이 이런 파일을 신뢰할 수 없는 데이터로 다뤄야 하며, 에이전트가 파일에서 지시문을 읽었다고 해서 그 지시를 따라야 하는 것은 아니라고 강조합니다.
그래서 실제로 일어날 수 있는 일을 제한하는 장치가 필요합니다. 영상이 꼽는 것은 제한된 도구 권한, 손닿지 않는 곳에 둔 인증 정보, 네트워크 접근 제한, 그리고 민감한 행동 앞에서 하네스가 실행을 멈추고 사람 승인을 받는 절차입니다. 영상의 표현을 옮기면 이렇습니다.
이런 통제는 소프트웨어가 강제해야 합니다. 모델에게 조심하라고 말하는 것만으로는 충분하지 않습니다. (Annie Wang, 「AI harness crash course」)
영상은 샌드박스가 공격의 피해 범위를 줄여 주지만 그것만으로 프롬프트 인젝션이 해결되지는 않는다는 점도 분명히 합니다. ADK 공식 안전·보안 문서 역시 위험의 원인으로 모호한 에이전트 지시, 악의적인 사용자의 프롬프트 인젝션과 탈옥 시도, 그리고 도구 사용을 통한 간접 프롬프트 인젝션을 나란히 적고 있습니다.
사람 승인은 ADK에서 도구 확인 기능으로 구현합니다. 공식 문서에 따르면 이 기능은 도구 실행을 잠시 멈추고 사용자나 다른 시스템에게 확인을 받은 뒤 진행하게 해 주며, 파이썬은 ADK 1.14.0부터 지원합니다. 예 또는 아니오만 묻는 단순 확인과, 설명 문구와 기대 응답 형식을 정해 구조화된 답을 받는 고급 확인 두 가지 방식이 있습니다. 파이썬에서는 도구를 FunctionTool로 감싸고 require_confirmation 값을 True로 두면 단순 확인이 붙습니다. 다만 문서는 이 기능이 아직 실험 단계이며 알려진 제약이 있다고 밝히고 있으니, 심사용 데모에 넣기 전에 직접 돌려 보고 확인하십시오.
정책으로 허락한 파일과 네트워크만 쓰게 하는 다른 접근은 이전 글 NVIDIA OpenShell은 AI 에이전트가 정책으로 허락한 파일과 네트워크만 쓰게 합니다에서, 샌드박스를 어디에 둘지는 OpenHands 샌드박스 비교 글에서 다뤘습니다.
개인정보: 도구 결과가 어디까지 흘러가는지 봅니다
영상은 보안과 별도로 개인정보 질문을 던집니다. 도구가 내 노트북에서 실행되더라도 그 출력은 호스팅된 모델로 전송될 수 있습니다. 세션 기록, 로그, 장기 기억에 저장될 수도 있습니다. 그래서 에이전트에게 실제로 필요한 데이터가 무엇인지, 그 데이터가 어디까지 갈 수 있는지, 얼마나 오래 보관할지를 먼저 생각하라고 권합니다. CSV 예에서는 가짜 고객 데이터만으로도 기능 동작을 충분히 시험할 수 있으며, 실제 고객 정보를 노출할 필요가 없다고 설명합니다.
공공·의료·금융 데이터를 다루는 대회라면 이 질문은 더 중요해집니다. 도구 결과를 모델에 그대로 넘기는 구조라면, 어떤 열이 모델로 나가는지 목록으로 적어 두십시오. 개발 중에는 가짜 데이터로 흐름을 먼저 검증하고, 실제 데이터는 대회 규정이 허용하는 환경에서만 다루는 것이 안전합니다.
평가: 결정적 검사, 모델 심사, 사람 검토를 섞습니다
마지막으로 에이전트가 끝났다고 말했을 때 정말 잘했는지 확인해야 합니다. 영상은 세 가지 방법을 소개합니다.
첫째는 결정적 평가입니다. 테스트 앱에 샘플 고객이 10명 있다면, 내려받은 파일에 같은 10명이 올바른 이름과 이메일 주소로 들어 있는지 코드로 자동 확인할 수 있습니다. 요구사항이 분명하면 코드가 결과를 판정합니다.
둘째는 모델 심사, 흔히 LLM-as-a-judge라고 부르는 방법입니다. 에이전트의 마지막 메시지가 구현 내용은 설명하면서 내보내기 버튼이 어디 있는지는 알려 주지 않을 수 있습니다. 이 메시지를 다른 모델에게 주고 버튼 위치와 내려받는 내용을 분명히 설명하는지 묻습니다. 영상은 정확성까지 확인하려면 기능이 실제로 어떻게 동작하는지 보여 주는 근거를 심사 모델에게 함께 줘야 하며, 심사 모델도 틀릴 수 있으니 사람의 판단과 비교해 보라고 말합니다.
셋째는 사람 평가입니다. 직접 기능을 써 보면 내려받기는 되는데 버튼 이름이 헷갈리거나 화면에서 찾기 어렵다는 점이 드러날 수 있습니다. 자동 검사가 아직 다루지 못하는 부분을 사람이 찾아냅니다. 영상은 한 시스템 안에서 분명한 요구사항은 코드로, 명확성 같은 품질은 모델 심사로, 사용 경험은 사람이 보는 식으로 세 방법을 섞을 수 있다고 정리합니다.
ADK 공식 평가 문서는 여기에 한 가지 관점을 더합니다. 에이전트 평가는 최종 응답만이 아니라 답에 이르기까지 거친 단계, 곧 궤적과 도구 사용도 봐야 한다는 것입니다. 문서는 개발 중에는 단위 테스트처럼 쓰는 테스트 파일을 만들고, 그 안에 사용자 질문과 함께 에이전트가 불러야 할 도구 호출 순서를 기대값으로 적어 두는 방식을 안내합니다. Google Cloud 에이전트 클리닉 영상을 다룬 이전 글 데모에서는 멀쩡했던 에이전트가 문서 품질 0.33점을 받았습니다도 트레이스를 남기는 평가 습관을 다룹니다.
해커톤 에이전트에 옮기는 순서
영상의 네 부분을 하루 안에 모두 갖추기는 어렵습니다. 아래 순서대로 하나씩 적용해 보십시오.
- 내 에이전트가 쓰는 도구를 모두 적고, 파일 삭제, 외부 전송, 결제, 메일 발송처럼 되돌리기 어려운 도구에 표시합니다. 표시한 도구 하나에 사람 승인 단계를 붙입니다.
- 같은 작업을 몇 번까지 다시 시도하게 할지 숫자로 정하고, 그 숫자를 넘으면 멈추고 사람에게 알리게 만듭니다.
- 개발용 가짜 데이터를 준비하고, 도구 결과 가운데 모델로 넘어가는 열이 무엇인지 목록으로 적습니다.
- 결과물이 맞는지 코드로 판정할 수 있는 결정적 검사를 최소 하나 만듭니다. 예를 들어 출력 파일의 행 수와 필수 열을 확인하는 검사면 충분합니다.
- 사용자가 반드시 지켜 달라고 한 조건은 대화 기록에만 두지 말고 상태 값으로 따로 저장합니다.
지금 DAKER에서 열려 있는 국부펀드 KIC, AI 에이전트 공모전은 투자·금융 업무용 AI Agent를 기획하고 실제로 작동하는 MVP로 구현하는 대회입니다. 10월 27일 오전 확인 기준으로 참가자는 611명, 제출은 85건이며, 참가 접수와 예선 기획안 제출은 11월 12일 오전 10시에 마감됩니다. 기획서 Workflow에 승인 단계와 재시도 한계를 적어 두면, 에이전트가 실패하거나 위험한 요청을 받았을 때 어떻게 행동하는지 평가자에게 보여 줄 수 있습니다.
영상에 없는 것과 확인할 점
이 영상은 개념을 정리하는 짧은 강의입니다. 하네스 구성에 따른 성능 비교나 벤치마크 수치는 나오지 않습니다. 재시도 한계의 적정 횟수도 제시하지 않습니다. 설명은 Google ADK를 예로 들기 때문에 다른 프레임워크에서는 이름과 설정 방법이 다를 수 있습니다. ADK의 도구 확인 기능은 공식 문서상 실험 단계라는 점도 기억해 두십시오. 이 글의 ADK 버전과 기능 설명은 10월 27일에 확인한 공식 문서를 기준으로 했습니다.
출처: Google Cloud Tech 유튜브 채널 「AI harness crash course」(발표 Annie Wang, 2026년 10월 22일 공개), Agent Development Kit 공식 문서(세션·상태·메모리, 그래프 기반 워크플로, 도구 확인, 안전과 보안, 에이전트 평가), DAKER 국부펀드 KIC, AI 에이전트 공모전 대회 페이지.