팀장이 알아야 할 AI 에이전트 용어: 개발자 말에 끌려가지 않기

핵심 요약

회사에서 "AI 에이전트를 도입하자"는 말이 나오면 대부분 바로 도구부터 고릅니다. Claude Code를 쓸지, Codex를 붙일지, 사내 문서 검색을 연결할지, Slack 봇으로 만들지 같은 이야기입니다. 그런데 실제 프로젝트가 흔들리는 지점은 의외로 더 앞에 있습니다. 팀이 "에이전트"라는 단어로 서로 다른 것을 상상하고 있을 때입니다.

어떤 사람은 챗봇을 떠올립니다. 어떤 사람은 매주 보고서를 자동으로 만드는 워크플로우를 떠올립니다. 개발자는 모델이 툴을 호출하고 파일을 고치는 실행 루프를 떠올립니다. 보안팀은 권한과 로그를 떠올립니다. 이 상태에서 프로젝트를 시작하면 같은 회의에 앉아 있어도 각자 다른 제품을 만들게 됩니다.

Hugging Face가 2026년 5월 25일 공개한 Harness, Scaffold, and the AI Agent Terms Worth Getting Right는 이 혼란을 정리하려는 글입니다. 원문은 agent, harness, scaffold, model, context engineering, tool, skill, sub-agent 같은 단어를 하나씩 풀어 설명합니다. 중요한 점은 Hugging Face도 "모두가 동의한 최종 정의"라고 말하지 않는다는 것입니다. 대신 빠르게 변하는 분야에서 대화를 덜 헷갈리게 하는 실용적 지도에 가깝습니다.

이 글은 그 용어를 한국 회사의 업무 장면으로 번역해 봅니다. 결론부터 말하면, AI 에이전트의 핵심은 "똑똑한 모델" 하나가 아닙니다. 모델을 어떤 지시와 기억으로 감쌀지, 어떤 실행 루프가 툴을 호출할지, 언제 멈추고 누구에게 승인을 받을지까지 합의해야 비로소 에이전트가 됩니다.

이미지 출처: Hugging Face Blog, 2026-05-25 공개.

왜 용어부터 맞춰야 하나

AI 프로젝트에서 용어는 사소한 문제가 아닙니다. "고객 문의 처리 에이전트"를 만든다고 해봅시다. 운영팀은 고객 메일을 읽고 답변 초안을 쓰는 도구를 원할 수 있습니다. 제품팀은 환불 정책과 배송 정책을 찾아 정확한 답을 만드는 시스템을 원할 수 있습니다. 개발팀은 Zendesk API, Notion 문서, 주문 DB를 오가며 여러 번 판단하는 자동화 루프를 생각할 수 있습니다. 법무팀은 고객에게 실제 답장을 보내기 전 사람 승인이 필요하다고 볼 수 있습니다.

네 팀 모두 "에이전트"라고 말하지만, 필요한 시스템은 다릅니다. 단순 초안 작성이면 챗봇과 검색만으로 충분할 수 있습니다. 정해진 순서로 자료를 모아 보고서를 만들면 워크플로우가 맞습니다. 고객의 답변에 따라 다음 행동을 바꾸고, 툴을 호출하고, 실패하면 우회하고, 마지막에 사람 승인을 요청해야 한다면 에이전트에 가깝습니다.

용어를 맞춘다는 것은 말장난이 아닙니다. 예산, 보안, 책임 소재, 출시 범위를 정하는 일입니다. "하니스가 무엇을 책임지는가"를 정하지 않으면 모델이 잘못된 툴을 호출했을 때 누가 막는지 흐려집니다. "스캐폴드가 무엇을 담는가"를 정하지 않으면 시스템 프롬프트, 툴 설명, 메모리, 출력 형식이 여기저기 흩어집니다. "워크플로우와 에이전트의 차이"를 정하지 않으면 굳이 자율성이 필요 없는 업무까지 비싼 에이전트로 만들게 됩니다.

모델은 직원이 아니라 두뇌에 가깝다

Hugging Face 원문은 model을 가장 단순하게 설명합니다. 모델은 텍스트를 받아 텍스트를 내놓는 LLM입니다. Claude, GPT, Qwen, Kimi, DeepSeek 같은 모델이 여기에 들어갑니다. 모델 자체는 호출 사이의 기억도 없고, 스스로 반복 실행되는 루프도 없습니다. 툴을 쓰고 싶다는 의도를 표현할 수는 있지만, 실제 API를 호출하고 파일을 읽고 명령을 실행하는 일은 바깥 시스템이 해야 합니다.

일반 업무로 비유하면 모델은 머리가 좋은 직원의 "두뇌"에 가깝습니다. 그런데 두뇌만 사무실 한가운데 놓여 있다고 일이 되지는 않습니다. 어떤 업무를 맡았는지, 어떤 문서를 봐야 하는지, 어떤 권한이 있는지, 결과물을 어떤 형식으로 내야 하는지, 어디까지 하면 멈춰야 하는지 정해져야 합니다.

이 구분이 중요한 이유는 기대치를 낮추기 위해서가 아니라, 실패 원인을 정확히 찾기 위해서입니다. AI가 회의록 요약을 이상하게 했다면 모델이 부족했을 수도 있습니다. 하지만 회의록 원문이 최신 파일이 아니었거나, 요약 형식이 불명확했거나, 참석자 이름을 확인할 사내 주소록이 연결되지 않았을 수도 있습니다. 이때 모든 실패를 "모델이 멍청하다"로 돌리면 문제를 고칠 수 없습니다.

개발팀에서도 마찬가지입니다. 코딩 에이전트가 엉뚱한 파일을 고쳤다면 모델이 약해서일 수도 있지만, 레포 구조를 알려주는 지침 파일이 없었거나, 테스트 실행 규칙이 하니스에 제대로 들어가지 않았거나, 변경 범위를 제한하는 가드레일이 없었을 수 있습니다. 모델은 중요하지만, 모델만으로 제품 경험이 결정되지는 않습니다.

스캐폴드는 모델이 보는 작업대다

Scaffold, 한국어로는 보통 스캐폴드 또는 비계라고 부를 수 있습니다. 건축 현장에서 작업자가 올라서는 임시 구조물을 생각하면 쉽습니다. Hugging Face는 스캐폴딩을 모델 주변의 행동 정의 레이어로 설명합니다. 시스템 프롬프트, 툴 설명, 응답 파싱 방식, 실행 중 기억 관리, 컨텍스트 구성 같은 것이 여기에 들어갑니다.

업무 비유로 바꾸면 스캐폴드는 "이 직원에게 건네는 작업대와 업무 매뉴얼"입니다. 고객지원 AI에게는 환불 정책, 금지 표현, 답변 톤, 고객 정보 조회 규칙이 필요합니다. 회의록 AI에게는 참석자 목록, 결정사항 형식, 액션 아이템 표기 방식, 민감 정보 제거 규칙이 필요합니다. 코딩 AI에게는 프로젝트 구조, 테스트 명령, 코드 스타일, 변경 금지 파일, PR 설명 양식이 필요합니다.

스캐폴드가 약하면 모델은 매번 즉흥적으로 일합니다. 오늘은 정책 문서를 참고하고, 내일은 기억나는 일반 상식으로 답하고, 모레는 툴 설명을 오해합니다. 사용자는 "같은 질문인데 왜 답이 다르지?"라고 느낍니다. 사실 문제는 모델이 아니라 작업대가 매번 달라지는 데 있을 수 있습니다.

스캐폴드에서 특히 중요한 것이 context engineering입니다. Hugging Face는 별도 Context Engineering Course도 운영합니다. 핵심은 모델에게 가능한 모든 문서를 통째로 밀어 넣는 것이 아닙니다. 지금 작업에 필요한 정보, 대화 이력, 툴 결과, 관련 지식, 기억을 어떤 순서와 형식으로 보여줄지 설계하는 일입니다.

회사 업무에서는 이 차이가 큽니다. "우리 Notion 전체를 AI에게 연결했다"는 말은 출발점일 뿐입니다. 환불 문의를 처리할 때 가격 정책, 배송 정책, 예외 승인 기준, 고객의 과거 문의, 주문 상태 중 무엇을 먼저 보여줄지 정해야 합니다. 잘못된 문서를 먼저 보여주면 모델은 자신 있게 틀립니다. 정보가 너무 많으면 핵심을 놓칩니다. 스캐폴드는 AI가 보는 세상을 설계하는 일입니다.

하니스는 AI를 실제로 움직이는 실행 장치다

Harness는 원래 마구, 안전띠, 장비를 몸에 고정하는 장치를 뜻합니다. AI 에이전트에서 하니스는 모델을 반복 호출하고, 모델이 요청한 툴을 실행하고, 결과를 다시 모델에게 넣고, 언제 멈출지 결정하는 실행 레이어입니다. Hugging Face 원문은 하니스를 "에이전트를 돌게 만드는 것"으로 설명합니다.

식당으로 비유하면 더 쉽습니다. 모델은 요리사의 판단력입니다. 스캐폴드는 레시피, 주방 규칙, 재료 목록, 손님 주문서입니다. 하니스는 주문을 주방에 넣고, 조리 과정을 진행시키고, 재료가 없으면 대체 규칙을 적용하고, 완성되면 서빙을 멈추게 하는 운영 시스템입니다. 아무리 요리사가 똑똑해도 주문 시스템이 고장 나면 음식은 엉뚱한 테이블로 갑니다.

AI 업무에서도 하니스가 약하면 위험한 일이 생깁니다. 모델이 "이 고객에게 환불 처리하겠습니다"라고 말했을 때 실제 환불 API를 바로 호출할지, 사람 승인을 받을지, 금액 한도를 확인할지 하니스가 정해야 합니다. 모델이 "테스트를 돌렸습니다"라고 말했을 때 실제 테스트 명령을 실행했는지, 실패 로그를 다시 읽었는지, 비용이 너무 커지면 중단했는지 하니스가 관리해야 합니다. API 한 번으로 격리된 Linux 실행 환경을 붙이는 Gemini Managed Agents API 사례도 모델보다 실행 하니스와 샌드박스 설계가 제품 경험을 좌우한다는 점을 보여줍니다.

OpenAI도 Harness Engineering 글에서 agent-first 환경의 제품 개발을 다루며, 에이전트가 실제 작업을 할 때 피드백 루프와 실행 구조가 얼마나 중요한지 설명했습니다. Anthropic의 Claude Code 문서 역시 Claude Code를 Claude 주변의 agentic harness로 설명합니다. 표현은 제품마다 다를 수 있지만 공통점은 같습니다. 에이전트 경험은 모델과 실행 구조가 결합되어 만들어집니다.

이미지 출처: Hugging Face Blog / documentation-images

워크플로우와 에이전트는 다르다

AI 도입에서 가장 흔한 실수는 모든 자동화를 에이전트라고 부르는 것입니다. 하지만 워크플로우와 에이전트는 다르게 설계해야 합니다.

워크플로우는 정해진 순서가 중요합니다. 매주 월요일 오전 9시에 매출 데이터를 가져오고, 지난주 대비 증감률을 계산하고, 그래프를 만들고, Slack에 올리는 작업은 워크플로우에 가깝습니다. 예외가 적고 단계가 고정되어 있습니다. 이런 일에는 굳이 자율 판단을 크게 줄 필요가 없습니다. 오히려 예측 가능성이 더 중요합니다.

에이전트는 관찰과 행동의 루프가 중요합니다. 고객이 "배송이 안 왔다"고 하면 먼저 주문 상태를 조회하고, 배송사 API를 확인하고, 지연 사유를 판단하고, 보상 정책을 찾아보고, 고객 등급과 금액에 따라 다음 행동을 바꿀 수 있습니다. 코딩 에이전트도 비슷합니다. 파일을 읽고, 가설을 세우고, 수정하고, 테스트하고, 실패하면 다시 로그를 읽습니다. 처음부터 끝까지 단계가 완전히 고정되어 있지 않습니다.

그래서 실무에서는 먼저 이렇게 물어야 합니다. 이 업무는 매번 같은 순서로 처리되는가, 아니면 중간 결과에 따라 다음 행동이 달라지는가. 전자라면 워크플로우가 맞을 가능성이 큽니다. 후자라면 에이전트를 검토할 수 있습니다. 모든 업무를 에이전트로 만들면 비용과 위험이 커집니다. 모든 업무를 워크플로우로 묶으면 복잡한 예외를 처리하지 못합니다.

툴, 스킬, 서브에이전트를 구분해야 권한이 보인다

Hugging Face 원문은 tool use, skills, sub-agents도 따로 설명합니다. 이 셋을 구분하면 실제 운영 설계가 쉬워집니다.

툴은 하나의 행동입니다. 웹 검색하기, DB 조회하기, 파일 읽기, 코드 실행하기, 티켓 생성하기, 이메일 초안 만들기 같은 함수 호출에 가깝습니다. 툴은 강력하지만 좁습니다. "고객 주문 상태 조회"는 툴입니다.

스킬은 여러 단계의 지식 패키지입니다. "환불 문의를 조사하고 답변 초안을 작성하는 법", "버그를 재현하고 원인을 좁히는 법", "월간 리포트를 만드는 법"처럼 목표를 달성하는 절차와 배경 지식이 묶여 있습니다. 툴이 버튼 하나라면, 스킬은 업무 매뉴얼에 가깝습니다.

서브에이전트는 다른 에이전트에게 일을 맡기는 구조입니다. 예를 들어 메인 에이전트가 "계약서 위험 조항은 법무 서브에이전트에게, 가격 분석은 재무 서브에이전트에게, 기술 가능성은 개발 서브에이전트에게 맡긴다"는 식입니다. 서브에이전트는 단순 함수가 아니라 자체적으로 추론하고 툴을 쓰고 결과를 돌려줄 수 있습니다. 이 개념은 추상적인 용어가 아니라, Antigravity 2.0 v2.0의 병렬 서브에이전트 워크플로우처럼 실제 코딩 도구의 제품 구조로도 빠르게 들어오고 있습니다.

이 구분은 권한 관리와 바로 연결됩니다. 툴은 어떤 API를 호출할 수 있는지 정해야 합니다. 스킬은 어떤 상황에서 로드되고 어떤 문서를 참고하는지 정해야 합니다. 서브에이전트는 어느 범위까지 독립적으로 판단하고, 어떤 결과를 메인 에이전트가 검증해야 하는지 정해야 합니다.

일반 회사에서는 "AI에게 Gmail과 Drive를 연결하자"라고 쉽게 말하지만, 실제로는 이 질문들이 따라옵니다. 읽기만 허용할 것인가, 보내기까지 허용할 것인가. 고객 개인정보가 있는 문서는 검색 대상에서 빼야 하는가. 결제, 환불, 계약, 인사처럼 되돌리기 어려운 행동은 반드시 사람 승인을 거칠 것인가. 이런 질문은 모델 선택보다 먼저 나와야 합니다.

에이전트 도입에서 가장 흔한 실패

첫 번째 실패는 에이전트가 필요 없는 일을 에이전트로 만드는 것입니다. 정해진 데이터 추출, 정해진 리포트 생성, 정해진 알림 발송은 워크플로우로도 충분한 경우가 많습니다. 에이전트를 붙이면 자연어 입력은 편해지지만, 비용과 예측 불가능성이 같이 올라갑니다.

두 번째 실패는 하니스를 제품 바깥의 임시 코드로 두는 것입니다. 데모에서는 모델에게 "필요하면 이 함수를 호출해"라고 해도 됩니다. 하지만 운영에서는 재시도, 타임아웃, 비용 제한, 권한 확인, 감사 로그, 중단 조건, 사람 승인 흐름이 필요합니다. 이 부분이 없으면 에이전트는 잘 될 때는 멋져 보이지만, 실패할 때 어디서 멈췄는지 알기 어렵습니다.

세 번째 실패는 스캐폴드를 문서화하지 않는 것입니다. 시스템 프롬프트가 누군가의 노트북에 있고, 툴 설명은 코드 안에 흩어져 있고, 금지 규칙은 Slack에 떠다니면 재현성이 떨어집니다. 에이전트가 지난주와 이번 주에 다르게 행동해도 원인을 찾기 어렵습니다.

네 번째 실패는 컨텍스트를 많이 넣는 것을 정답으로 착각하는 것입니다. 긴 컨텍스트는 편리하지만 공짜가 아닙니다. 비용, 지연 시간, 잘못된 정보 혼입 위험이 있습니다. 더 중요한 것은 "무엇을 넣지 않을지"입니다. 최신 정책과 폐기된 정책이 같이 들어가면 모델은 어느 쪽이 맞는지 모를 수 있습니다.

다섯 번째 실패는 평가를 나중으로 미루는 것입니다. 에이전트는 한 번의 답변만 평가하면 부족합니다. 어떤 파일을 읽었는지, 어떤 툴을 호출했는지, 몇 번 실패했는지, 어디서 사람 승인을 요청했는지까지 봐야 합니다. Hugging Face의 Agents Course도 에이전트를 관찰, 사고, 행동의 반복 구조로 설명합니다. 반복 구조라면 평가도 반복 과정 전체를 봐야 합니다.

회의에서 바로 써먹는 5가지 합의 질문

AI 에이전트 도입 회의에서 용어가 흐려진다면 아래 질문부터 맞추는 것이 좋습니다.

1. 우리가 말하는 에이전트는 단순 답변 도구인가, 정해진 워크플로우인가, 중간 결과에 따라 행동을 바꾸는 실행 루프인가.

2. 모델은 무엇을 맡고, 하니스는 무엇을 맡는가. 특히 툴 호출, 재시도, 중단 조건, 비용 제한, 사람 승인 흐름은 어디에 구현되는가.

3. 스캐폴드에는 어떤 지시와 문서가 들어가는가. 시스템 프롬프트, 툴 설명, 출력 형식, 정책 문서, 장단기 메모리는 누가 관리하고 어떻게 버전 관리하는가.

4. 어떤 툴은 읽기만 허용하고, 어떤 툴은 쓰기까지 허용하는가. 이메일 발송, 환불, 계약 변경, 코드 배포처럼 되돌리기 어려운 행동은 어느 단계에서 사람 승인을 받는가.

5. 성공과 실패를 어떻게 측정하는가. 최종 답변 품질만 볼 것인가, 툴 호출 횟수, 비용, 지연 시간, 오류 복구, 승인 요청, 보안 위반 시도까지 함께 볼 것인가.

이 다섯 질문에 답하지 못한다면 아직 "에이전트를 만들자"가 아니라 "무엇을 자동화할지 정하자" 단계일 가능성이 큽니다. 반대로 이 질문에 답할 수 있다면 모델이 바뀌어도 프로젝트의 뼈대는 흔들리지 않습니다.

누가 지금 읽어야 하나

직장인과 생산성 관심층에게 이 용어사전은 "AI가 내 일을 대신하느냐"보다 "내 일이 어떤 단위로 쪼개져 AI와 연결되는가"를 보는 데 도움이 됩니다. 회의록, 고객응대, 리서치, 문서 작성, 일정 조율은 모두 에이전트 후보처럼 보이지만 실제로는 워크플로우, 검색, 초안 작성, 사람 승인 단계가 섞여 있습니다. 이 구조를 이해하면 과장 광고에 덜 흔들립니다.

개발자에게는 더 직접적입니다. 에이전트 품질은 모델 API 호출 한 줄로 끝나지 않습니다. 툴 스키마, 실행 루프, 로그, 컨텍스트 압축, 파일 접근 권한, 테스트 전략, 중단 조건이 제품 품질을 좌우합니다. 같은 모델을 써도 Cursor, Claude Code, Codex, 사내 에이전트가 다르게 느껴지는 이유가 여기에 있습니다. 하니스가 다르면 제품 경험도 달라집니다.

관리자에게는 구매 기준이 됩니다. 벤더가 "우리 AI 에이전트가 자동으로 처리합니다"라고 말할 때, 실제로는 무엇을 자동 처리하는지 물어야 합니다. 워크플로우 자동화인지, 검색 기반 답변인지, 툴 호출 권한을 가진 에이전트인지, 사람 승인 없이 쓰기 작업까지 하는지 확인해야 합니다. 이 질문 없이 도입하면 나중에 보안팀과 운영팀이 뒤늦게 설계를 되돌려야 합니다.

어디서부터 보면 되나

원문을 직접 보려면 Hugging Face의 AI Agent 용어사전을 먼저 읽으면 됩니다. 글의 소스는 GitHub 원문에서도 확인할 수 있습니다. 블로그와 GitHub 표현이 다를 경우 공개 블로그 기준으로 보는 것이 안전합니다.

입문자는 Hugging Face의 Agents Course를 같이 보면 좋습니다. 에이전트를 관찰, 사고, 행동의 반복 구조로 설명해 실무 감각을 잡기 쉽습니다. 컨텍스트 설계가 궁금하다면 Context Engineering Course가 다음 단계입니다.

제품 관점의 하니스 설계는 OpenAI의 Harness Engineering 글과 Anthropic의 Claude Code 작동 방식 문서를 함께 보면 좋습니다. 각 회사가 같은 단어를 완전히 동일하게 쓰지는 않지만, 모델 바깥의 실행 구조가 제품 경험을 만든다는 큰 방향은 같습니다.

관전 포인트

앞으로 "AI 에이전트"라는 말은 더 많이 쓰일 것입니다. 검색, 이메일, 문서, 코딩, 고객지원, 회계, 인사 시스템까지 모두 자기 제품을 에이전트라고 부를 가능성이 큽니다. 그래서 용어는 더 중요해집니다. 단어가 흐려질수록 좋은 제품과 위험한 자동화를 구분하기 어려워집니다.

Hugging Face의 이번 글이 유용한 이유는 새로운 유행어를 하나 더 만든 데 있지 않습니다. 오히려 반대입니다. "모델", "스캐폴드", "하니스", "툴", "스킬", "서브에이전트"를 분리해 보면 AI 프로젝트를 더 현실적으로 볼 수 있습니다. 어떤 문제는 더 좋은 모델로 풀어야 합니다. 어떤 문제는 더 나은 문서와 컨텍스트로 풀어야 합니다. 어떤 문제는 실행 하니스와 권한 설계로 풀어야 합니다. 어떤 문제는 에이전트를 쓰지 않는 것이 정답입니다.

AI 에이전트 도입이 꼬이는 이유는 기술이 어려워서만이 아닙니다. 같은 단어로 다른 그림을 보고 있기 때문입니다. 팀이 먼저 맞춰야 할 것은 최신 모델명이 아니라, "우리가 만들려는 에이전트가 무엇을 보고, 무엇을 할 수 있고, 어디서 멈춰야 하는가"입니다. 그 합의가 있어야 AI는 멋진 데모를 넘어 실제 업무 도구가 됩니다.

출처와 더 읽을 거리

• Hugging Face Blog: Harness, Scaffold, and the AI Agent Terms Worth Getting Right: 이 글의 기준이 된 공식 용어사전으로, agent, harness, scaffold, model, tool, skill의 정의와 Hugging Face의 설명 맥락을 확인할 수 있다.
• Hugging Face GitHub 원문: agent-glossary.md: 공개 블로그 글의 소스 파일로, 작성자·썸네일·본문 구조와 수정 이력을 확인할 때 유용하다.
• Hugging Face Agents Course: What are agents?: 에이전트를 관찰, 사고, 행동의 반복 구조로 설명하는 입문 자료다.
• Hugging Face Context Engineering Course: 에이전트가 어떤 정보를 컨텍스트에 넣고 빼야 하는지 더 깊게 배우기 좋은 공식 강의다.
• OpenAI: Harness Engineering: Codex를 활용한 agent-first 개발 경험을 바탕으로 하니스와 피드백 루프의 중요성을 설명하는 공식 글이다.
• Anthropic Claude Code Docs: How Claude Code works: Claude Code가 Claude 주변의 agentic harness로 작동한다는 제품 관점 설명을 확인할 수 있는 공식 문서다.