대답하는 AI에서, 함께 일하는 AI로
오늘의 AI는 질문에 답하는 데서 멈추지 않는다. 필요한 자료를 찾고, 도구를 쓰고, 결과에 따라 다음 행동을 고른다. 이런 변화가 한꺼번에 일어난 것은 아니다. AI에 어떤 능력이 차례로 더해졌는지 살펴보면, 맡겨도 되는 일과 사람이 확인해야 할 지점도 자연스럽게 보인다.
기준일: 2026-08-09 · 공개 논문, 공식 기술 문서, 기관·기업 보고서 기반
사례 범위: 이 글의 빗썸 업무 사례는 공개된 가상자산 거래소 서비스 영역을 바탕으로 만든 설명용 가상 예시다. 실제 빗썸의 내부 절차나 도입 계획을 설명하지 않으며, 가격 예측·매매 추천·자동 거래·거래지원 여부 판단은 사례에서 제외했다.
모델 이름만으로는 실제 업무 성능을 알 수 없다
2017년 가 등장한 뒤 언어 모델은 빠르게 커졌다. 사람의 지시를 따르는 법을 배웠고 검색기, 계산기, 브라우저, 사내 시스템도 직접 쓰기 시작했다. 한 번 답하고 끝나던 AI가 여러 작업을 이어서 처리하게 된 것이다.
모델만 놓아둔다고 일이 돌아가지는 않는다. 읽어야 할 자료와 사용할 도구를 연결하고, 실행 내역을 남기고, 돈이나 개인정보가 걸린 행동 앞에는 사람의 승인을 두어야 한다. 이처럼 모델 주변에 붙는 작업 환경을 ()라고 부른다. 자동차로 치면 모델은 엔진이고, 하네스는 브레이크와 계기판, 운전 규칙까지 포함한 나머지 장치다.
실무 결과는 모델의 성능표만으로 정해지지 않는다. 어떤 자료와 도구를 연결했는지, 어디까지 권한을 줬는지, 어떤 조건에서 시험했는지가 함께 작용한다. 모델 이름이나 벤치마크 점수만 비교해서는 이 차이를 볼 수 없다.
1. AI에는 어떤 능력이 차례로 더해졌나
아래 연도는 대표 논문이나 공개 발표가 나온 시점이다. 여러 연구가 겹쳐 발전한 분야이므로 특정 회사나 논문 한 편을 최초의 시작점으로 단정하지 않았다.
2017: 가 문맥 안의 단어 관계를 읽다
Transformer는 문맥 창 안에서 어떤 단어끼리 관련이 깊은지 으로 계산한다. 단어를 하나씩 순서대로 처리하던 이전 순환신경망보다 병렬 학습에 유리했고, 멀리 떨어진 단어의 관계도 더 효과적으로 다뤘다. 오늘날 대규모 언어 모델() 대부분이 이 구조에서 출발한다.
2018~2020: 한 모델로 여러 언어 작업을 처리하다
()은 많은 글을 읽고 다음에 올 단어를 맞히면서 언어의 패턴을 익히는 과정이다. 이렇게 만든 LLM 하나가 요약, 번역, 질문 답변, 초안 작성을 두루 처리했다. 업무가 바뀔 때마다 모델을 처음부터 다시 만들 필요도 줄었다.
다만 LLM은 사실을 차곡차곡 보관한 데이터베이스가 아니다. 문맥에 어울릴 법한 표현을 만들어내기 때문에 틀린 내용을 자신 있게 말할 수도 있다.
2020: 가 답하기 전에 문서를 찾다
검색 증강 생성(RAG)은 질문과 관련된 문서를 찾아 모델에 함께 건넨다. 모델을 다시 훈련하지 않아도 최신 공지, 이용 안내, 운영 매뉴얼처럼 자주 바뀌는 자료를 답변에 반영할 수 있다.
검색 결과가 엉뚱하거나 오래됐다면 답변도 틀어진다. RAG는 답의 출처를 보여줄 수 있지만, 그 출처가 정확한지까지 보장하지는 않는다. 환각도 완전히 사라지지 않는다.
2021: 하나의 기반 모델을 여러 제품에 쓰다
은 폭넓은 데이터로 먼저 학습한 뒤 여러 작업과 제품에 맞게 조정해 쓰는 기반 모델이다. 하나의 모델을 여러 서비스가 나눠 쓰면서 장점과 위험도 함께 퍼졌다. 기업은 모델을 직접 만들지 않고도 나 공개 모델에 자사 데이터와 업무 절차를 연결할 수 있었다.
2022: 사람의 지시를 더 잘 따르도록 다듬다
사전학습 모델은 문장을 이어 쓰는 데는 능했지만 사용자의 의도를 꾸준히 따르지 못했다. 은 질문과 좋은 답변 예시를 보여주며 모델을 추가로 학습한다. 는 사람들이 어떤 답을 더 낫다고 골랐는지를 이용해 답변 습관을 조정한다. 이 두 방법이 자리 잡으면서 대화형 생성 AI는 일반 사용자에게도 훨씬 다루기 쉬운 도구가 됐다.
2022: 복잡한 문제를 나눠 풀다
계산이나 계획처럼 여러 단계를 거치는 문제는 곧바로 답하게 하면 자주 틀린다. 는 문제를 중간 단계로 나눠 풀도록 유도했다. 최신 은 답을 내기 전에 더 많은 연산을 쓴다. 그래도 오답은 나온다. 문장이 자연스럽다고 내용까지 맞는 것은 아니므로, 책임이 따르는 판단은 사람이 원문과 수치를 확인해야 한다.
2022~2023: 판단한 뒤 도구를 쓰다
는 판단한 뒤 도구를 쓰고, 그 결과를 보고 다음 행동을 고르는 과정을 반복한다. 과 를 이용하면 검색기, 계산기, 데이터베이스, 고객지원 도구, 코드 실행기를 정해진 형식으로 호출할 수 있다.
언어 모델만으로는 최신 정보를 확인하거나 실제 시스템을 바꿀 수 없다. 도구가 연결되자 AI의 역할은 답변 작성에서 조회, 분류, 등록, 검증으로 넓어졌다.
2023: LLM 가 여러 작업을 이어서 처리하다
소프트웨어 에이전트 연구는 1990년대 이전부터 있었다. 2023년을 전후해 LLM이 계획을 세우고 도구를 쓰며 사람과 자연어로 대화하는 구성이 널리 알려졌다.
챗봇은 보통 질문에 답한다. 에이전트는 목표와 현재 상황을 보고 다음 행동을 고른다. 사람이 순서를 미리 정한 와 달리, 검색 결과가 부족하거나 오류가 생기면 계획을 바꿀 수 있다. 검색, 비교, 파일 작성, 시스템 입력처럼 할 일이 이어지고 예외가 자주 생기는 업무에 알맞다.
2023: 여러 에이전트가 일을 나눠 맡다
여러 에이전트가 조사자, 작성자, 검토자처럼 역할을 나눌 수 있다. 한 에이전트에게 기획과 실행, 검증을 모두 몰아줬을 때 생기는 혼선을 줄이려는 구성이다.
에이전트 수가 많다고 결과가 저절로 좋아지지는 않는다. 메시지를 주고받는 비용이 늘고, 같은 일을 두 번 하거나 한쪽의 오류가 다른 에이전트로 번질 수 있다.
2024: 코딩 에이전트와 가 파일과 화면을 다루다
코드 모델은 코드를 제안하는 데 그쳤다. 코딩 에이전트는 저장소를 읽고 파일을 고친 뒤 테스트까지 실행한다. 테스트가 실패하면 를 읽고 다시 수정한다.
Computer use는 API가 없는 프로그램을 화면의 버튼과 입력창으로 조작한다. 오래된 사내 도구에도 연결할 수 있지만 클릭이나 입력이 제대로 됐는지 확인하기는 더 어렵다. 파일 수정, 구매, 삭제처럼 결과가 남는 행동에는 와 승인 절차가 필요하다.
2024~2025: 와 가 연결 규격을 맞추다
MCP(Model Context Protocol)는 AI 애플리케이션이 데이터와 도구에 연결되는 방법을 정한 공개 규격이다. A2A(Agent2Agent Protocol)는 서로 다른 공급자나 프레임워크의 에이전트가 각자 할 수 있는 일을 알리고 작업을 주고받게 한다.
공통 규격을 쓰면 도구마다 연결 코드를 새로 만드는 수고는 줄어든다. 연결 규격이 같다고 상대를 믿어도 된다는 뜻은 아니다. 인증과 권한, 데이터가 머무는 위치, 감사 기록은 따로 관리해야 한다.
2025~2026: 가 모델 밖의 차이를 드러내다
는 지시와 , 검색, , 도구, 실행 순서, 권한, 샌드박스, , 로그, 승인 화면을 묶어 부르는 실무 용어다. 같은 모델을 써도 읽는 자료와 사용하는 도구가 다르면 결과도 크게 달라진다. 작업이 길어지면 앞서 본 내용을 잊거나 같은 오류를 반복하고, 권한과 비용이 필요 이상으로 커지기도 한다.
이 용어는 Transformer처럼 논문 한 편에서 공식 정의한 개념이 아니다. 2025~2026년 에이전트와 코딩 에이전트 실무에서 여러 운영 장치를 함께 가리키는 표현으로 쓰이기 시작했다.
2. 어떤 일까지 AI에게 맡길 것인가
Agentic AI와 는 같은 말이 아니다. 여기서 agentic AI는 주어진 목표와 도구, 권한 안에서 다음 행동을 고르는 시스템을 뜻한다. 자율성은 켜고 끄는 단일 기능이 아니다. 사람이 작업 순서를 어디까지 정하고, 어느 지점부터 AI가 고르게 할지에 따라 정도가 달라진다. 아래 네 구분은 운영 방식을 비교하기 위한 설명이며 공인된 성숙도 모형이 아니다.
: 사람이 매번 방향을 잡는다
사람이 요청하면 AI가 초안을 내고, 사람이 확인한 뒤 다음 지시를 준다. 고객 문의 답변 초안이나 입출금 문의 대응 회의 요약처럼 매번 방향을 잡아야 하는 일에 잘 맞는다. 통제하기는 쉽지만 사람이 계속 조작해야 한다.
: 정해진 순서대로 처리한다
'문의 수신 → 유형 분류 → 관련 공개 문서 연결 → 담당자에게 전달'처럼 처리 순서가 미리 정해져 있다. 규칙이 분명한 업무에서는 결과를 예상하기 쉽고, 어느 단계에서 문제가 났는지 기록하기도 편하다.
: 상황에 따라 다음 행동을 고른다
'지난 24시간 고객 문의가 늘어난 이유를 정리하라'는 목표를 받으면 문의 유형과 시간대를 살핀다. 관련 공지나 서비스 상태가 빠졌다면 더 찾아보고, 확인된 사실과 미확인점을 나눠 보고한다. 예외가 많은 지식 업무에 쓸 수 있지만, 할 일이 늘어난 만큼 비용과 실패 지점도 많아진다.
조직 운영: 권한과 책임을 함께 설계한다
사람은 목표와 우선순위를 정하고 애매한 예외를 판단한다. 에이전트는 반복 실행과 정보 처리를 맡는다. 좋은 도구를 사오는 것만으로는 부족하다. 누가 어떤 권한을 갖는지, 결과를 어떻게 할지, 문제가 생기면 누가 멈출지를 조직 차원에서 정해야 한다.
처리 순서가 늘 같은 업무에는 워크플로가 더 싸고 안전하다. 에이전트는 예외가 많아 경로를 미리 정하기 어려운 일에 필요한 만큼만 쓰는 편이 낫다.
3. 하네스는 AI가 일하는 환경을 어떻게 만드는가
목표와 완료 조건
역할, 완료 조건, 금지할 행동, 결과 형식을 정한다. '잘해줘'라고만 쓰지 말고 무엇을 읽어야 하는지, 어디까지 바꿔도 되는지, 어떤 증거가 있어야 끝난 것으로 볼지를 적는다.
작업에 필요한
지금 하는 일에 필요한 자료만 골라 알맞은 순서로 제공한다. 긴 문서를 통째로 넣기보다 관련 공지, 이용 안내, 고객 문의의 범위, 직전 작업, 좋은 예시를 추린다. 이 한 번의 요청 문구를 다듬는 일이라면 은 작업하는 동안 AI가 참고할 정보 전체를 관리하는 일이다.
와 검색
방금 하던 작업의 상태, 사용자 선호, 프로젝트 기록, 지식베이스는 성격이 서로 다르다. 저장할 때도 구분해야 한다. 모든 대화를 무기한 보관하면 개인정보와 잘못된 기억까지 함께 쌓인다. 무엇을 저장하고 언제 지울지, 누가 삭제할 수 있는지를 미리 정해야 한다.
도구와 권한
검색기, 데이터베이스, 고객지원 도구, 파일, 코드 실행기를 연결한다. 공지와 이용 안내를 읽는 권한, 개별 계정 정보를 조회하는 권한, 고객에게 답변을 발송하는 권한은 서로 분리한다. 가능하다면 화면을 클릭하는 방식보다 호출 내용과 결과를 확인하기 쉬운 가 낫다.
은 API와 다르다. API가 프로그램끼리 요청을 주고받는 약속이라면 Skill은 특정 업무의 절차, 전문지식, 스크립트, 템플릿을 묶어 다시 쓰는 단위다.
실행 순서와 중단 조건
는 계획하고 행동한 뒤 결과를 확인하고 필요하면 고친다. 여러 에이전트를 함께 쓴다면 각자의 역할, 결과를 넘길 형식, 반복 횟수, 중단 조건을 정해야 한다. 이 흐름을 실제로 돌리면서 상태 저장, 재시도, 시간 제한, 일시중지와 재개를 처리하는 부분이 이다.
와 승인
에이전트에는 지금 맡은 일에 필요한 권한만 준다. 고객 정보 조회와 외부 전송 범위를 정하고, 답변 발송이나 공지 게시 전에는 사람이 확인한다. 승인 화면에는 무엇을 왜 공개하려는지가 보여야 한다. 내용을 알 수 없는 승인 버튼은 검토 절차가 아니다.
와 안전장치
는 같은 조건에서 결과를 반복 측정하는 시험 세트다. 는 개인정보 노출, 금지 행동, 정책 위반을 감지해 막는다. 정답률만 보지 말고 출처 누락, 사람이 고치는 데 걸린 시간, 실행 비용, 사고 건수도 함께 봐야 한다.
실행 기록과 감사
에이전트가 어떤 지시와 자료를 읽었고 무슨 도구를 호출했는지 기록한다. 최종 결과만 남겨서는 어디서 잘못됐는지 찾기 어렵다. 실행 과정이 있어야 같은 오류를 재현하고 고칠 수 있다.
사람이 개입할 지점
모든 클릭을 사람이 승인한다면 자동화의 이점이 줄어든다. 공개 문서 검색과 문의 분류처럼 되돌릴 수 있는 저위험 작업은 자동화하고, 개별 계정 조회, 고객 답변 발송, 공지 게시, 금전 영향이 있는 판단에는 사람의 확인을 둔다.
연구 범위: SWE-agent 연구에서는 같은 GPT-4 Turbo를 써도 컴퓨터와 연결되는 인터페이스에 따라 문제 해결률이 달랐다. 2026년 Harness-Bench도 모델과 하네스 조합에 따라 점수 차이가 컸다고 보고했다. 두 연구 모두 범위가 제한된 기술 과제를 다뤘으므로, 이 결과를 모든 업무에 그대로 적용할 수는 없다.
4. 첫 자동화 업무를 고르는 기준
첫 실험에는 자주 반복되고 입력과 결과가 파일이나 시스템에 남는 업무가 알맞다. 좋은 결과를 가릴 기준이 있어야 하며, 실수해도 사람이 발견하거나 되돌릴 수 있어야 한다.
고객 자산과 계정에 영향을 주는 처리, 가격 예측과 매매 추천, 거래지원 여부 판단, 이상거래 최종 판정, 개인정보 이용, 외부 공지는 한 번의 오류도 비용이 크다. 이런 업무는 AI에게 자료 정리나 초안까지만 맡기고 최종 판단과 실행은 권한 있는 담당자가 해야 한다.
고객지원과 운영 안내
AI는 문의를 유형별로 묶고 최신 공지와 이용 안내에서 관련 문서를 찾아 답변 초안을 만들 수 있다. 공개 정보만으로 답할 수 없는 문의는 개별 계정 조회가 필요하다고 표시해 담당자에게 넘긴다. 고객에게 보내는 최종 답변과 보상·분쟁 예외 판단은 담당자가 맡는다.
서비스 운영
시간대와 유형별 문의 변화를 요약하고, 공개된 서비스 상태와 관련 공지를 대조해 운영 브리핑 초안을 만들 수 있다. AI는 확인된 사실과 미확인점을 나눠 보여줘야 한다. 장애 원인 단정, 복구 시점 약속, 고객 영향 범위 확정은 담당자가 판단한다.
리스크·준법 보조
공개 규정과 내부 기준에서 관련 조항을 찾아 비교표를 만들고, 검토 문서에서 빠진 근거나 상충하는 표현을 표시하는 데 쓸 수 있다. 다만 이상거래 여부, 신고 의무, 고객 제한 조치처럼 법적·재산적 영향이 있는 판단은 AI가 확정해서는 안 된다.
제품과 콘텐츠
이용 안내와 공지 초안을 채널 형식에 맞게 바꾸고, 화면 문구의 일관성과 누락 링크를 점검할 수 있다. 가상자산 가격 전망이나 매매를 유도하는 표현은 만들지 않도록 막아야 하며, 고객에게 공개되는 문안은 담당자가 사실과 시점을 확인한다.
개발과 IT 운영
코드를 찾고 고치거나 테스트와 문서를 만들고 장애 를 정리하는 데 쓸 수 있다. 아키텍처, 운영 위험, 보안 판단, 프로덕션 배포 승인은 사람이 맡는다.
2025년 METR 무작위 실험에서는 숙련된 개발자가 익숙한 코드베이스에서 최신 AI 도구를 썼는데도 작업 시간이 늘었다. AI를 붙인다고 항상 빨라지는 것은 아니다. 맡긴 일, 사용한 도구, 코드베이스 경험, 결과를 확인하는 시간에 따라 효과가 달라진다.
경영지원
회의 자료를 요약하고 결정 사항과 담당자, 기한을 뽑거나 사규와 양식을 찾는 일에 쓸 수 있다. 비용 증빙의 누락 항목을 표시하는 작업도 후보가 된다. 예외 승인과 인사·계약 판단, 실제 지급은 담당자가 맡는다.
5. AI 사용과 운영 사이에는 간격이 있다
Stanford 의 2026 AI Index에 따르면 2025년 조사 대상 조직 중 88%가 AI를 사용했다. 적어도 한 가지 업무에서 를 쓴 조직은 70%였다. 반면 업무별 AI 배치 비율은 대부분 한 자릿수였다. 세 수치는 서로 다른 범주와 문항을 측정하므로 한 단계씩 이어지는 비율처럼 비교하면 안 된다. 챗봇과 은 이미 흔하지만, 여러 작업을 스스로 이어가는 에이전트는 아직 시험 운영이 많다.
AI Index에는 고객지원 14~15%, 소프트웨어 개발 26%, 마케팅 산출 50% 등 생산성 향상을 보고한 연구가 실렸다. 절차와 결과를 비교하기 쉬운 업무에서 효과가 컸고, 깊은 이 필요한 일에서는 효과가 작았다. 장기적으로 학습 능력이 약해질 수 있다는 결과도 있었다. 연구마다 조건이 다르므로 이 숫자를 모든 조직에 그대로 대입해서는 안 된다.
Microsoft의 2026 Work Trend Index는 10개국에서 AI를 쓰는 근로자 2만 명의 설문과 Microsoft 365 사용 신호를 분석했다. 보고된 AI 효과에는 개인의 노력보다 조직 문화, 관리자 지원, 인재 제도가 약 두 배 더 큰 영향을 미쳤다. 계정 배포보다 업무 절차와 관리 방식의 변화가 더 큰 영향을 줬다는 해석이다.
순서가 정해진 자동화에는 이미 안정된 도구와 사례가 많다. 에이전트 시범 운영도 늘고 있다. 회사 전체로 넓히려면 방법, 권한 관리, 데이터 접근, 사고가 났을 때의 책임을 풀어야 한다.
6. 무엇부터 자동화할까
AI의 발전은 더 자연스러운 답변에서 끝나지 않았다. 이제는 자료를 찾고 도구를 쓰며 여러 작업을 이어서 처리한다. 모든 일을 에게 맡길 이유는 없다. 정해진 순서가 있는 일은 로 처리하고, 결과를 예측하기 어려운 일에만 에이전트를 쓰는 편이 낫다.
프롬프트보다 작업 환경을 먼저 본다
한 번 잘 쓴 프롬프트보다 어떤 자료를 읽고 무슨 도구를 쓰는지, 결과를 어떻게 확인하는지가 더 큰 영향을 준다. 지침만 적어두지 말고 테스트와 를 붙여 사람이 보기 전에 일부 오류를 잡는다.
범위가 좁은 일부터 맡긴다
모든 일을 맡는 범용 에이전트보다 입출금 공지 검색, 고객 문의 분류, 운영 브리핑 초안, 코드 마이그레이션처럼 범위와 완료 기준이 분명한 에이전트가 하기 쉽다. 자료와 권한도 필요한 만큼만 줄 수 있다.
연결 규격과 신뢰는 별개다
와 는 모델과 도구, 에이전트가 달라도 연결 코드를 다시 짜는 수고를 줄인다. 표준 규격을 쓴다고 상대 시스템까지 믿을 수 있는 것은 아니다. 접속 주체를 확인하고 권한을 제한하며 데이터가 어디로 갔는지 기록해야 한다.
말솜씨가 아니라 실행 결과를 잰다
에이전트가 자연스럽게 말한다고 일을 잘한 것은 아니다. 완료율, 출처 일치율, 사람이 고치는 데 걸린 시간, 재시도 비용을 잰다. 외부 시스템을 잘못 바꾼 횟수와 제때 멈추고 복구했는지도 운영 지표에 넣는다.
현업 경험으로 좋은 결과를 정의한다
AI가 실행을 더 많이 맡을수록 사람은 목표와 우선순위를 정하고 애매한 예외를 판단한다. 현업 경험은 AI가 만든 결과를 평가하고 업무 절차를 고치는 기준이 된다.
실패를 다음 시험 문제로 남긴다
성공과 실패 사례를 평가 데이터로 남기면 지침과 도구를 고칠 수 있다. 규칙을 바꾼 뒤 같은 시험을 다시 돌려 실제로 나아졌는지 확인한다. 에이전트는 한 번 설치하고 끝내는 제품이 아니라 계속 손보는 운영 시스템이다.
7. 현업 경험을 AI의 작업 기준으로 옮기는 법
처음부터 코딩을 배울 필요는 없다. 하던 일을 순서대로 나누고 어떤 결과가 좋으며 어떤 실수가 위험한지 설명하는 일이 먼저다.
- 업무를 입력, 판단, 행동, 검토로 나눈다.
- 좋은 결과와 위험한 결과를 구체적인 사례로 설명한다.
- 문서에 없는 예외와 암묵지를 실제 사례로 제공한다.
- AI가 쓸 권한과 사람이 질 책임을 구분한다.
- 절약한 시간뿐 아니라 수정량과 사고도 측정한다.
첫 실험은 입출금 공지 검색이나 공개 정보로 답할 수 있는 문의 분류처럼 범위가 좁은 일 하나면 충분하다. 검색, 분류, 초안 작성처럼 결과를 바로 확인할 수 있는 구간부터 맡긴다.
8. 90일 동안 작게 시험하고 넓히기
0~30일: 업무 하나를 고르고 현재 상태를 잰다
입출금 안내 문의처럼 범위가 분명한 업무를 하나 고른다. 한 달 처리량, 한 건에 걸리는 시간, 잘못된 출처를 붙인 횟수, 개인정보가 들어가는지를 적는다. AI를 쓰기 전의 시간과 품질을 남겨야 나중에 나아졌는지 비교할 수 있다. 첫 실험에는 공개 자료나 민감하지 않은 자료를 쓴다.
31~60일: 읽고 정리하는 기능만 연다
처음에는 공개 공지 검색, 문의 분류, 답변 초안처럼 외부 시스템을 바꾸지 않는 기능만 허용한다. 개인정보를 제거한 사례 30~100개로 시험 세트를 만들고 정확도, 출처 누락, 담당자가 고치는 데 걸린 시간을 함께 잰다.
61~90일: 되돌릴 수 있는 쓰기 권한만 연다
승인 전 초안을 내부 검토함에 넣는 것처럼 되돌릴 수 있는 쓰기부터 으로 연다. 고객 답변 발송, 계정 정보 조회, 공지 게시, 자산에 영향을 주는 판단은 담당자가 승인한다. 운영 화면에서는 비용, 실패율, 중단 버튼, 담당자를 바로 확인할 수 있어야 한다.
확장 전에 확인할 것
- 사람의 검토 시간을 포함해도 총 소요 시간이 줄었는가?
- 오류와 수정 비용을 포함해도 이득인가?
- 만으로 실패 원인을 재현할 수 있는가?
- 담당자가 권한을 제한하고 작업을 중단할 수 있는가?
- 모델이나 공급자를 바꿔도 업무 기준과 데이터가 남는가?
9. 용어를 다시 풀어보면
| 용어 |
뜻 |
어디에 쓰나 |
|
AI가 글을 읽을 때 나누는 작은 단위. 한 글자나 단어 조각일 수 있다 |
문장을 계산할 수 있는 단위로 바꿀 때 |
|
AI가 한 번에 참고할 수 있는 정보의 범위 |
긴 문서와 대화를 이어서 다룰 때 |
|
AI에게 주는 작업 요청 |
지금 해야 할 일을 모델에 알려줄 때 |
| Generative AI |
Generative Artificial Intelligence. 글, 이미지, 음성, 코드 같은 결과물을 만드는 생성형 인공지능 |
분류와 예측을 넘어 새 결과물을 만들 때 |
|
글이나 자료의 의미를 숫자로 바꾼 표현 |
뜻이 비슷한 자료를 찾을 때 |
|
Retrieval-Augmented Generation, 검색 증강 생성. 관련 문서를 찾아 답변에 넣는 방식 |
최신 자료와 사내 지식을 답변에 반영할 때 |
|
미세조정. 특정 데이터로 모델의 행동을 추가 학습하는 과정 |
전문 작업이나 원하는 말투에 맞출 때 |
|
Reinforcement Learning from Human Feedback, 인간 피드백 기반 강화학습 |
사람이 선호한 답을 이용해 답변 습관을 조정할 때 |
|
모델. 복잡한 문제에 더 많은 중간 계산을 쓰는 모델 |
계획, 수학, 코딩, 분석처럼 여러 단계가 필요한 문제를 풀 때 |
|
검색기, 계산기, , 앱을 호출하는 능력 |
최신 정보를 확인하거나 실제 행동을 실행할 때 |
|
미리 정한 순서대로 처리하는 자동화 |
반복 업무를 예측 가능한 순서로 처리할 때 |
|
목표와 현재 상황을 보고 다음 행동을 고르는 시스템 |
예외가 생기는 여러 단계의 업무를 처리할 때 |
| Agentic AI |
목표와 도구, 실행 순서를 결합한 AI 시스템 |
답변을 넘어 여러 작업을 이어서 처리할 때 |
|
실행 조율. 단계와 도구, 여러 를 관리하는 일 |
복잡한 실행 순서와 실패 처리를 관리할 때 |
|
실행 환경. 상태 저장과 재시도, 중단, 재개를 처리하는 부분 |
오래 걸리는 작업을 안정적으로 이어갈 때 |
| Memory |
과거 상태와 업무 기록을 저장해 다시 쓰는 기능 |
장기 작업의 상태를 이어갈 때 |
|
Model Context Protocol, 모델 컨텍스트 프로토콜 |
AI와 도구·데이터의 연결 방식을 맞출 때 |
|
Agent2Agent Protocol, 에이전트 간 통신 규격 |
서로 다른 에이전트가 작업과 결과를 주고받을 때 |
|
절차와 전문지식, 스크립트, 템플릿을 묶은 것 |
반복 업무의 수행 방법을 다시 쓸 때 |
|
모델을 둘러싼 실행·안전·검증 시스템 |
모델을 실제 업무에서 계속 운영할 때 |
|
Evaluations의 줄임말. AI 결과를 반복해서 재는 시험 |
출시 전후의 품질과 성능 저하를 확인할 때 |
|
개인정보 노출과 금지 행동을 막는 안전장치 |
정책 위반과 안전 사고를 줄일 때 |
|
관찰 가능성. 실행 과정과 실패 원인을 추적하는 기능 |
에이전트를 운영하고 문제를 조사할 때 |
|
중요한 판단이나 실행에 사람이 직접 개입하는 설계 |
책임이 크거나 되돌리기 어려운 예외를 통제할 때 |
10. 업무에 적용할 때 남겨둘 기준
- 은 언어 패턴을 다룬다. 사실을 보관하는 데이터베이스는 아니다.
- 는 목표와 도구, 검토 기준을 받아 여러 작업을 이어간다.
- AI가 더 많이 선택할수록 권한은 좁게 주고 실행 기록과 중단 장치는 분명하게 둔다.
- 여러 에이전트가 역할을 나누면 메시지 비용과 오류가 번질 경로도 늘어난다.
- 실제 성과는 모델 이름보다 업무 선정, 데이터, 하네스, 사람의 판단에 좌우된다.
AI와 함께 일한다는 것은 판단을 통째로 넘기는 일이 아니다. 자동화할 범위를 정하고 좋은 결과의 기준을 만든 뒤, 책임이 따르는 순간에는 사람이 확인한다. AI를 도입하면 우리가 일을 나누고 검토하는 방식도 함께 달라진다.
주요 출처
- Vaswani et al., Is All You Need (2017): https://arxiv.org/abs/1706.03762
- Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (2020): https://arxiv.org/abs/2005.11401
- Bommasani et al., On the Opportunities and Risks of Foundation Models (2021): https://arxiv.org/abs/2108.07258
- Ouyang et al., Training language models to follow instructions with human feedback (2022): https://arxiv.org/abs/2203.02155
- Wei et al., Chain-of-Thought Prompting Elicits in Large Language Models (2022): https://arxiv.org/abs/2201.11903
- Yao et al., : Synergizing Reasoning and Acting in Language Models (2022): https://arxiv.org/abs/2210.03629
- Schick et al., Toolformer: Language Models Can Teach Themselves to Use Tools (2023): https://arxiv.org/abs/2302.04761
- Wu et al., AutoGen: Enabling Next-Gen Applications via Conversation (2023): https://arxiv.org/abs/2308.08155
- Anthropic, Building Effective AI Agents (2024): https://www.anthropic.com/engineering/building-effective-agents
- Anthropic, Introducing the Model Context Protocol (2024): https://www.anthropic.com/news/model-context-protocol
- Google Developers, Announcing the Agent2Agent Protocol (2025): https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/
- OpenAI, A practical guide to building AI agents: https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/
- Stanford , 2026 AI Index - Economy: https://hai.stanford.edu/ai-index/2026-ai-index-report/economy
- Microsoft WorkLab, 2026 Work Trend Index - Agents, human agency, and the opportunity for every organization: https://www.microsoft.com/en-us/worklab/work-trend-index
- NIST, AI Risk Management Framework / Generative AI Profile: https://www.nist.gov/itl/ai-risk-management-framework
- World Economic Forum, The Future of Jobs Report 2025: https://www.weforum.org/publications/the-future-of-jobs-report-2025/
- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- Birgitta Böckeler / Martin Fowler, engineering for users (2026): https://martinfowler.com/articles/harness-engineering.html
- Yang et al., SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering (2024): https://arxiv.org/abs/2405.15793
- Xie et al., OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments (2024): https://arxiv.org/abs/2404.07972
- Anthropic, Introducing (2024): https://www.anthropic.com/news/3-5-models-and-computer-use
- Harness-Bench (2026 preprint): https://arxiv.org/html/2605.27922
- Anthropic, Demystifying for AI agents: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
- specification: https://agentskills.io/
출처를 읽을 때 주의할 점
- 공급업체 보고서에는 실제 사용 데이터와 함께 자사 제품과 전략의 관점도 섞일 수 있다.
- 생산성 연구마다 다룬 직무와 사용자의 숙련도, 도구, 방식이 다르다. 숫자 하나를 모든 업무에 그대로 적용해서는 안 된다.
- Agentic AI와 는 아직 빠르게 바뀌는 실무 용어다. 업계 전체가 합의한 정의는 없다.
- Harness-Bench는 2026년 preprint이며 범위가 제한된 기술 과제를 다룬다. 하네스가 모든 업무에서 모델보다 우월하다는 증거로 사용하지 않았다.
- 미래에 관한 내용은 현재 기술과 도입 신호를 바탕으로 한 해석이다. 확정된 예측은 아니다.
