대답하던 AI가 함께 일하게 된 과정이에용
AI와 함께 일하는 방식이 어떻게 발전해 왔는지 먼저 살펴봐용. 문장을 이해하던 모델이 자료를 찾고 도구를 쓰며 업무 일부를 자동화하게 된 과정을 따라가면, AI에게 맡길 범위와 사람이 확인할 지점이 더 분명해져용.
기준일: 2026-08-09 · 공개 논문, 공식 기술 문서, 기관·기업 보고서 기반
먼저 짚어볼게용: 모델 이름만으로는 실제 성능을 알 수 없어용
2017년 가 등장한 뒤 언어 모델은 빠르게 커졌어용. 사람의 지시를 따르는 법을 배웠고, 검색기와 계산기, 브라우저, 사내 시스템도 직접 쓰기 시작했어용. 질문에 한 번 답하고 끝나던 AI가 이제는 여러 단계를 이어서 처리해용.
하지만 모델만 덩그러니 놓아서는 일을 맡길 수 없어용. 필요한 자료와 도구를 연결하고, 무엇을 했는지 기록해야 해용. 돈이나 개인정보가 걸린 행동은 사람이 확인하도록 막아두어야 해용. 이런 실행 환경을 ()라고 불러용. 하네스는 모델에 자료, 도구, 권한, 검사와 기록 기능을 붙인 작업 환경이에용.
실제 결과는 모델 성능만으로 정해지지 않아용. 어떤 하네스를 붙였는지, 무슨 도구를 썼는지, 어떤 조건에서 시험했는지가 함께 작용해용. 모델 이름이나 시험 점수만 비교하면 실제 업무에서의 성능을 놓치기 쉬워용.
1. 2017~2026, AI에 어떤 능력이 더해졌을까용?
아래 연도는 최초 발명일이 아니라 대표 논문이나 공개 발표 시점을 기준으로 삼았어용. 여러 연구가 겹쳐 발전한 분야라서 시작점을 회사 하나나 논문 한 편으로 못 박기는 어려워용.
2017: 가 단어 사이의 관계를 한꺼번에 보다
Transformer는 문장 속 단어들을 한꺼번에 살펴보고, 어떤 단어들이 서로 연결되어 문맥을 만드는지 으로 계산해용. 이전 방식과 달리 여러 단어를 한꺼번에 처리할 수 있어, 많은 자료를 더 빠르게 학습하기 좋았다. 오늘날 대규모 언어 모델()은 대부분 이 구조를 바탕으로 해용.
2018~2020: 한 모델이 여러 언어 작업을 맡기 시작했어용
()은 많은 글에서 다음에 올 단어를 맞혀보며 언어 패턴을 익히는 과정이에용. 이렇게 만든 LLM 하나로 요약, 번역, 질문 답변, 초안 작성 같은 여러 언어 작업을 처리할 수 있었어용. 업무가 바뀔 때마다 모델을 처음부터 새로 만들 필요도 줄었어용.
다만 LLM은 사실을 차곡차곡 보관한 데이터베이스가 아니에용. 문맥상 그럴듯한 표현을 만들어내기 때문에, 자신 있게 틀린 답을 내놓기도 해용.
2020: 가 답하기 전에 관련 문서를 찾아보다
검색 증강 생성(RAG)은 질문에 맞는 문서를 먼저 찾고, 그 내용을 모델에 함께 건네용. 모델을 다시 훈련하지 않아도 사규나 제품 매뉴얼, 계약 양식 같은 내부 자료를 답변에 반영할 수 있어용.
검색 결과가 엉뚱하거나 오래됐다면 답변도 함께 틀어져용. RAG는 근거를 붙여주지만, 그 근거가 맞는지까지 보장하거나 환각을 완전히 없애주지는 않아용.
2021: 하나를 여러 제품에 쓰다
Foundation model은 넓은 범위의 데이터로 먼저 학습한 뒤, 여러 작업과 제품에 맞춰 조정해 쓰는 기반 모델이에용. 같은 모델을 여러 서비스가 나눠 쓰면서 장점도 위험도 함께 퍼졌어용. 기업은 모델을 직접 만들지 않고도 나 공개 모델 위에 자사 데이터와 업무 절차를 얹을 수 있게 됐어용.
2022: 과 로 지시를 더 잘 따르다
사전학습 모델은 문장을 이어 쓰는 데는 능했지만, 사용자의 의도를 꾸준히 따르지는 못했어용. Instruction tuning은 질문과 좋은 답변 예시를 보여주며 모델을 추가로 학습해용. RLHF는 사람들이 어떤 답을 더 낫다고 골랐는지 이용해 답변 습관을 조정해용. 이 두 방법이 자리 잡으면서 일반 사용자도 대화형 생성 AI를 훨씬 쉽게 쓸 수 있게 됐어용.
2022: 복잡한 문제를 중간 단계로 나눠 풀어용
계산이나 계획처럼 여러 단계를 거치는 문제는 바로 답을 내게 하면 자주 틀려용. 는 문제를 중간 단계로 나눠 풀도록 유도했어용. 최신 은 답을 내기 전에 더 많은 연산을 써용. 하지만 AI가 여러 단계로 해도 그럴듯한 오답을 낼 수 있어용. 결과가 자연스러워 보여도 책임은 사람에게 있으므로, 중요한 판단은 사람이 직접 확인해야 해용.
2022~2023: 와 로 판단한 뒤 행동해용
ReAct는 판단하고 도구를 쓴 다음, 나온 결과를 보고 다음 행동을 고르는 과정을 반복해용. 과 tool use를 이용하면 검색기와 계산기, 데이터베이스, 이메일, 캘린더, 코드 실행기를 정해진 형식으로 호출할 수 있어용.
언어 모델만으로는 최신 정보를 확인하거나 실제 시스템을 바꿀 수 없어용. 도구가 연결되면서 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가 선택하게 할지에 따라 달라져용.
1단계:
사람이 질문하면 AI가 초안을 내고, 사람이 확인한 뒤 다음 지시를 줘용. 이메일 초안이나 회의 요약처럼 매 단계에서 방향을 잡아야 하는 일에 잘 맞아용. 통제하기는 쉽지만 사람이 계속 조작해야 해용.
2단계:
'메일 수신 → 분류 → 요약 → 담당자에게 전송'처럼 처리 순서가 미리 정해져 있어용. 규칙이 분명한 업무에서는 결과를 예상하기 쉽고, 어느 단계에서 문제가 났는지 기록하기도 편해용.
3단계:
'이번 주 경쟁사 변화를 조사해 임원용 보고서를 작성하라'는 목표를 받으면 검색하고 자료를 고른 뒤, 부족하면 더 찾아보고 초안을 써용. 예외가 많은 지식 업무에 쓸 수 있지만, 단계가 늘어난 만큼 비용과 실패할 지점도 많아져용.
4단계: 조직이 권한과 책임을 운영해용
사람은 목표와 우선순위를 정하고 애매한 예외를 판단해용. 는 반복 실행과 정보 처리를 맡아용. 이 단계에서는 좋은 도구를 사오는 것만으로 부족해용. 누가 어떤 권한을 갖는지, 결과를 어떻게 할지, 문제가 생기면 누가 멈출지를 조직 차원에서 정해야 해용.
처리 순서가 늘 같은 업무라면 가 더 싸고 안전해용. 에이전트는 예외가 많아 경로를 미리 정하기 어려운 일에 필요한 만큼만 쓰는 편이 나아용.
3. 에는 무엇이 들어가는가
목표와 지시를 먼저 정해용
역할과 완료 조건, 하지 말아야 할 행동, 결과 형식을 정해용. '잘해줘'라고만 쓰지 말고 무엇을 읽을지, 어디까지 바꿀 수 있는지, 어떤 증거가 있어야 끝난 것으로 볼지를 적어용.
과
지금 하는 일에 필요한 자료만 골라 알맞은 순서로 제공해용. 긴 문서를 통째로 넣기보다 관련 정책과 고객 상태, 직전 작업, 좋은 예시를 추려용. 이 한 번의 요청 문구를 다듬는 일이라면, context engineering은 작업 내내 AI가 참고할 정보 환경을 관리하는 일이에용.
와
방금 하던 작업의 상태와 사용자 선호, 프로젝트 기록, 지식베이스를 구분해서 저장해용. 모든 대화를 무기한 보관하면 개인정보와 잘못된 기억까지 함께 쌓여용. 무엇을 저장하고 언제 지울지, 누가 삭제할 수 있는지를 먼저 정해야 해용.
필요한 도구만 연결해용
검색기와 데이터베이스, 사내 시스템, 파일, 캘린더, 코드 실행기를 연결해용. 자료를 읽는 권한과 실제 내용을 바꾸는 권한은 분리해용. 가능하다면 화면을 클릭하는 방식보다 결과를 확인하기 쉬운 를 쓰는 편이 나아용.
은 API와 달라용. API가 프로그램끼리 연결되는 방법이라면, Skill은 특정 업무를 수행하는 절차와 전문지식, 스크립트, 템플릿을 묶어 다시 쓰는 방법이에용.
실행 루프와
는 계획하고 행동한 뒤 결과를 확인하고 필요하면 고쳐용. 여러 에이전트를 함께 쓴다면 각자 무슨 일을 맡는지, 결과를 어떤 형식으로 넘길지, 몇 번까지 반복하고 언제 멈출지를 정해야 해용. 이 흐름을 실제로 돌리면서 상태 저장과 재시도, 시간 제한, 일시중지와 재개를 처리하는 부분이 이에용.
권한, 와 승인
에이전트에는 지금 맡은 일에 필요한 권한만 줘용. 지출 한도와 외부 전송 범위를 정하고, 삭제나 공개 게시 전에는 사람이 확인해용. 승인 화면에는 무엇을 왜 바꾸려는지가 보여야 해용. 내용도 모른 채 버튼 하나만 누르게 해서는 제대로 검토할 수 없어용.
와
Evals는 실제 사례를 모아 같은 조건에서 결과를 반복해서 확인하는 방법이에용. Guardrails는 개인정보 노출과 금지 행동, 정책 위반을 감지해 막아용. 정답률만 볼 게 아니라 근거가 빠졌는지, 사람이 고치는 데 얼마나 걸렸는지, 비용과 사고가 얼마나 생겼는지도 함께 봐야 해용.
와 감사 기록
에이전트가 어떤 지시와 자료를 읽었고 무슨 도구를 호출했는지 기록해용. 최종 결과만 남기면 어디서 잘못됐는지 찾기 어려워용. 실행 과정이 남아 있어야 같은 오류를 다시 만들어보고 고칠 수 있어용.
모든 클릭을 사람이 승인해야 한다면 자동화할 이유가 줄어들어용. 실수해도 되돌릴 수 있는 저위험 작업은 자동화하고, 돈과 개인정보, 외부 공개처럼 되돌리기 어려운 행동만 사람이 확인해용.
연구 범위도 확인해용: SWE-agent 연구에서는 같은 GPT-4 Turbo를 써도 컴퓨터와 연결되는 인터페이스에 따라 문제 해결률이 달랐어용. 2026년 Harness-Bench도 모델과 하네스 조합에 따라 점수 차이가 컸다고 보고했어용. 다만 두 연구 모두 범위가 제한된 기술 과제를 다뤘어용. 이 결과만으로 하네스가 모든 업무에서 모델보다 중요하다고 결론 내릴 수는 없어용.
4. 첫 업무를 고르는 기준이에용
첫 실험은 자주 반복되고 입력과 결과가 파일이나 시스템에 남는 업무가 좋아용. 무엇이 좋은 결과인지 비교할 기준이 있어야 하고, 실수하더라도 사람이 확인하거나 되돌릴 수 있어야 해용.
법적 책임이 따르는 일, 채용과 해고, 큰 금액, 의료와 안전, 민감한 관계 판단, 물리 시스템 제어는 한 번의 오류도 비용이 커용. 이런 업무에서는 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 기능을 얼마나 사용했는지 보여주는 기록을 분석했어용. 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와 함께 일할 때도 최종 판단과 책임은 사람에게 있어용. 무엇을 자동화할지 정하고, 좋은 결과의 기준을 만들고, 중요한 순간에는 사람이 확인하는 방식으로 업무를 다시 설계해용.
참고한 자료를 모았어용
- 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이며 범위가 제한된 기술 과제를 다뤄용. 하네스가 모든 업무에서 모델보다 우월하다는 증거로 사용하지 않았어용.
- 미래에 관한 내용은 현재 기술과 도입 신호를 바탕으로 한 해석이에용. 확정된 예측으로 읽어서는 안 돼용.