AI 용어 사전 11편 (2026) — 자율성 · 도구 사용 · 파이프라인, AI가 스스로 일을 이어갈 때

“AI한테 과제를 통째로 맡겼더니 알아서 코드도 짜고 실행도 하더라고요” “이제 챗봇이 검색도 하고 이메일도 보내요” “여러 단계를 자동으로 이어주는 파이프라인을 짰는데 어디서 잘못됐는지 찾기가 어려워요” — 코딩 도구 리포트, 자동화 영상, IT 뉴스 어디서나 이 세 단어가 번갈아 나옵니다. 그런데 세 단어의 차이를 한 줄로 말하지 못하면, AI가 어디까지 알아서 해도 되는지를 결정할 수 없습니다. “다 똑같이 AI 아닌가?”로 넘기면, 왜 어떤 도구는 한 번 묻고 일하고 어떤 도구는 끝까지 혼자 가는지, 왜 “도구를 쓸 수 있게 열어 두었다가 사고가 났다”는 말이 자꾸 나오는지를 이해할 수 없습니다. 세 단어의 뜻을 모르면 AI에게 어디까지 권한을 줄지 판단하는 눈도, 결과를 책임지는 태도도 흔들립니다.

요약 (TL;DR): 자율성 · 도구 사용 · 파이프라인 핵심 요약 자율성은 사람이 매번 개입하지 않아도 AI가 스스로 판단해 일을 이어가는 정도로, 한 번 시키면 끝까지 혼자 하는 코딩 에이전트가 그 폭의 끝입니다. 도구 사용은 AI가 필요할 때 외부 도구·API를 직접 호출하는 능력이라 “손과 눈이 달린 AI”에 해당하고, 답을 모르면 검색하고 계산이 필요하면 계산기를 쓰는 식으로 나타납니다. 파이프라인은 여러 처리 단계를 정해진 순서로 이어 한 흐름으로 묶은 구조로, “이메일이 오면 요약하고 → 캘린더에 넣고 → 알림을 보낸다”가 그 자동화의 뼈대입니다.

이 글은 5분 안에 읽고 AI가 스스로 일을 이어가는 힘을 다루는 세 단어 — 자율성 · 도구 사용 · 파이프라인을 정리합니다. 각 단어가 “무엇을 가리키고 왜 중요한가”를 Devin · Claude · Make 같은 도구 화면과 일상 사례로 짚고, 흔히 빠지는 오해까지 잡습니다. 도구 사용법이 아니라 개념을 먼저 잡는 글입니다.

왜 “에이전트”를 또 다루나? 우리 블로그의 3편 AI 에이전트 · 멀티모달 · API는 에이전트가 ‘무엇인지’를 다뤘습니다. 이번 11편은 그 ‘에이전트’가 실제로 돌아가게 만드는 세 개의 톱니바퀴 — AI가 어디까지 스스로 결정하나(자율성), 어떻게 바깥 세상을 건드리나(도구 사용), 여러 단계를 어떻게 한 흐름으로 잇나(파이프라인) — 를 가른 글입니다. 10편 추론 · 지연 · 처리량이 ‘한 번 답을 낼 때까지의 시간’을 다뤘다면, 이번 편은 ‘한 답에서 다음 답으로 일을 이어갈 때’를 다룹니다 — 그래서 자율성이 ‘빠르다’와 다른 ‘멀리 간다’의 문제임이 드러납니다.

자율성·도구 사용·파이프라인은 각각 무슨 뜻일까?

이 섹션에서 배우는 것: 세 단어를 한 줄씩 먼저 훑고, 각각이 내 판단에서 어떻게 나타나는지 보기.

단어	한 줄 정의	직관적 의미	일상 예시
자율성(Autonomy)	사람이 매번 개입하지 않아도 AI가 스스로 판단해 일을 이어가는 정도	”얼마나 알아서 하나”의 폭	”한 번 시키면 끝까지 혼자 하는 코딩 에이전트”
도구 사용(Tool Use)	AI가 필요할 때 외부 도구·API를 직접 호출하는 능력	”손과 눈이 달린 AI"	"답을 모르면 검색하고, 계산이 필요하면 계산기를 쓴다”
파이프라인(Pipeline)	여러 처리 단계를 정해진 순서로 이어 한 흐름으로 묶은 구조	”단계를 잇는 자동화의 뼈대"	"이메일이 오면 요약하고 → 캘린더에 넣고 → 알림을 보낸다”

⚠️ 자율성·도구 사용·파이프라인은 능력의 크기가 아니라 ‘권한과 구조의 설계’입니다. 같은 도구라도 권한을 얼마나 줄지, 어떤 도구를 열어 둘지, 단계를 어떻게 잇느냐에 따라 약속이 되기도 하고 사고가 되기도 합니다. 이 글은 2026년 8월 기준의 개념 설명이며, 각 도구의 정확한 기능·한도·보안 설정은 공식 자료에서 확인하세요. 출처: Anthropic 도구 사용 문서, OpenAI 함수 호출 가이드, Make 자동화 플랫폼

용어 1: 자율성(Autonomy) — “AI가 어디까지 스스로 결정하나?”

이 섹션에서 배우는 것: 자율성이 ‘사람이 매번 개입하지 않아도 AI가 스스로 판단해 일을 이어가는 정도’라는 것, 그래서 같은 ‘AI’라도 자율성의 폭이 결과를 완전히 바꾼다는 점.

자율성은 에이전트를 가늠하는 가장 중요한 축입니다. 한 줄로 말하면, 사람이 매 단계 확인하고 눌러줘야 하는 도구에서부터, 한 번 과제를 주면 끝까지 스스로 판단해 처리하는 도구까지 — AI가 ‘얼마나 알아서’ 일하는가의 폭입니다. 자율성이 낮으면 AI는 하나를 할 때마다 사람에게 “이제 뭘 할까요?”를 물어야 하고, 자율성이 높으면 스스로 다음 단계를 정해 일을 이어 갑니다. Anthropic 연구와 Hugging Face 에이전트 문서는 이 차이를 ‘도구를 쓰는 모델’과 ‘스스로 계획해 행동하는 에이전트’를 가르는 핵심으로 다룹니다.

Devin Desktop 홈페이지 화면 devin.ai 홈페이지

자율성이 왜 따로 짚히는지는 코딩 에이전트 Devin에서 선명하게 보입니다. “이 웹사이트에 로그인 기능을 만들어 줘”라는 과제를 받으면, Devin은 코드를 직접 작성하고 실행하고 테스트한 뒤 결과를 보여줍니다 — 사람이 매 줄을 확인해 주지 않아도 여러 단계를 스스로 이어 가는, 높은 자율성의 사례입니다. AI 코딩 도구 비교 (2026)에서 다룬 Cursor·GitHub Copilot이 “코드 한 줄을 추천하는 보조 도구”라면, Devin은 과제 단위로 직접 수행하는 주체에 가깝습니다. 중요한 점은 자율성이 ‘우위’가 아니라 ‘선택’이라는 것 — 자율성이 높을수록 사람 손이 덜 가는 대신, AI가 잘못된 방향으로 멀리 갈 수 있는 여지도 커집니다. 그래서 자율성은 ‘능력’이기 전에 ‘얼마나 믿고 맡길 것인가’의 판단 문제입니다.

5분 안에 직접 확인하기

devin.ai 홈페이지에 접속해 데모 영상이나 예시 과제를 확인하세요. AI가 코드를 작성하고 실행하는 과정이 어떻게 사람의 개입 없이 이어지는지 살펴봅니다. “한 번 시키면 스스로 여러 단계를 잇는다”는 자율성의 높은 쪽 끝을 보는 것입니다.
평소 쓰는 챗봇에서 “이메일 초안을 써 줘”라고만 하고 다음 지시를 주지 않아 보세요. 답 한 번을 내놓고 멈춘다면 자율성이 낮은 쪽이고, “초안을 보내 드릴까요?”처럼 다음 단계를 스스로 제안한다면 자율성이 조금 더 높은 쪽입니다.
“이 일을 끝까지 맡기면 어떤 단계가 알아서 일어날까?”를 한 줄로 적어 보세요. 자율성을 판단하는 가장 실용적인 질문은 “내가 몇 번이나 손을 대야 하나”입니다.

잘 안 되는 경우

민감한 권한을 통째로 맡긴 경우: 자율성이 높은 에이전트에게 결제·삭제·공개 게시 권한을 한꺼번에 열어 주면, AI가 잘못 판단했을 때 되돌리기 어려운 일이 한 번에 일어납니다. 자율성은 권한의 범위와 짝을 이뤄야 합니다.
AI가 스스로 멈출 때를 정하지 않은 경우: “끝까지 알아서 해”만 주면 AI는 멈출 곳을 모르고 무한히 시도하거나 엉뚱한 방향으로 일을 이어 갑니다. 언제 멈추고 사람에게 물어야 하는지(이를 ‘중단 조건’이라 합니다)를 미리 정하지 않으면 자율성이 사고로 바뀝니다.

자율성이 “얼마나 알아서 하나”라면, 다음 단어는 “알아서 할 때 무엇을 손에 쥐고 하나”를 다룹니다.

용어 2: 도구 사용(Tool Use) — “AI가 바깥 세상을 건드릴 때”

이 섹션에서 배우는 것: 도구 사용이 ‘AI가 필요할 때 외부 도구·API를 직접 호출하는 능력’이라는 것, 그래서 도구 없는 모델과 도구를 쓰는 모델의 답이 왜 다른지.

도구 사용은 AI의 능력 경계를 넓히는 장치입니다. 한 줄로 말하면, AI가 스스로 ‘지금 검색이 필요하다’ ‘계산이 필요하다’ ‘달력을 봐야 한다’고 판단해, 외부 도구나 API를 호출해 그 결과를 다시 자기 답에 끌어오는 능력입니다. 모델이 혼자 아는 것만 말하는 상태에서, 도구를 쓸 수 있으면 검색 결과로 최신 정보를 끌어오고, 계산기로 정확한 수치를 내고, 코드 실행기로 직접 돌려 확인합니다. Anthropic 도구 사용 문서와 OpenAI 함수 호출 가이드는 이를 ‘함수 호출(function calling)‘이라는 이름으로, 모델이 외부 세계와 실제로 상호작용하게 만드는 표준 기능으로 다룹니다.

Claude 홈페이지 화면 claude.ai 홈페이지

도구 사용이 왜 따로 짚히는지는 Claude에서 분명하게 보입니다. Claude는 웹 검색, 코드 실행, 컴퓨터 화면 조작까지 ‘도구’로 쓸 수 있게 설계되었으며, Anthropic 컴퓨터 사용 문서에서 이를 공식으로 다룹니다. 도구가 없는 모델에게 “오늘 서울 날씨는?”을 물으면 그 모델이 학습 시점에 알던 날씨만 말하거나 모른다고 하지만, 도구를 쓰는 모델은 검색 도구를 불러 최신 날씨를 끌어옵니다. 6편에서 다룬 지식 절단이 모델이 ‘아는 것의 한계’였다면, 도구 사용은 그 한계를 ‘필요할 때 바깥에서 가져오는’ 쪽으로 넓히는 장치입니다. 그래서 “이 답이 어디서 왔나”를 물으면서 도구 사용을 보는 눈이, 환각과 사실을 가르는 데 직결됩니다. 도구 사용은 강력하지만, 열어 둔 도구가 곧 AI가 닿을 수 있는 세상의 범위이므로 어떤 도구를 허락할지가 곧 안전의 문제가 됩니다.

5분 안에 직접 확인하기

claude.ai 에서 최신 뉴스나 오늘 날짜가 필요한 질문을 하나 던져 보세요. 모델이 “검색하겠습니다”라며 웹 검색 도구를 부르는지, 아니면 아는 것만 말하는지 보는 것이 도구 사용의 가장 바람직한 직관입니다.
챗봇에 “123 × 456 × 789를 정확히 계산해 줘”라고 물어 보세요. 큰 수의 곱셈을 즉시 정확히 내놓는다면 코드 실행 도구를 쓴 징후로 볼 수 있고, 대충 근사치만 낸다면 도구 없이 머릿속으로 추정한 것일 수 있습니다.
도구를 쓴 흔적이 답에 드러나는지 한 줄로 적어 보세요. 좋은 도구 사용은 “출처”를 보여주고, 검증 없는 도구 사용은 출처 없이 단정합니다.

잘 안 되는 경우

열어 둔 도구가 너무 넓은 경우: 검색·파일 삭제·메일 발송 도구를 한꺼번에 허락하면, AI가 필요하다고 판단한 도구를 제멋대로 불러 뜻밖의 결과를 만듭니다. 도구 사용의 안전은 ‘최소한의 도구만, 필요한 만큼만’ 여는 데 달립니다.
도구가 돌려준 결과를 검증하지 않은 경우: 도구가 틀린 결과를 돌려줘도 AI가 그것을 믿고 답에 끌어넣으면, 도구 사용이 오히려 그릇된 자신감의 원인이 됩니다. 검색 결과의 출처와 계산 결과의 합리성을 다시 한번 살피는 일이 빠지면 환각이 ‘출처 있는 거짓말’로 바뀝니다.

“무엇을 손에 쥐고 하나”를 보았다면, 마지막은 그 손들을 “어떤 순서로 이어 하나”를 다루는 단어입니다.

용어 3: 파이프라인(Pipeline) — “여러 단계를 한 흐름으로”

이 섹션에서 배우는 것: 파이프라인이 ‘여러 처리 단계를 정해진 순서로 이어 한 흐름으로 묶은 구조’라는 것, 그래서 한 단계가 고장 나면 전체가 멈추는 이유.

파이프라인은 자율성과 도구 사용을 ‘한 일’로 엮는 뼈대입니다. 한 줄로 말하면, 여러 처리 단계를 정해진 순서로 이어, 앞 단계의 결과가 뒷 단계의 입력이 되도록 한 흐름으로 묶은 구조입니다. “이메일이 오면 → AI가 요약하고 → 요약을 캘린더에 넣고 → 알림을 보낸다”가 하나의 파이프라인이며, 각 화살표가 하나의 단계입니다. Make 같은 자동화 도구가 이 파이프라인을 시각적으로 짜고 실행하는 대표 사례이며, Google Apps Script로 코드로 짜는 경우도 같은 구조입니다. 자율성이 ‘얼마나 알아서 하나’, 도구 사용이 ‘무엇을 손에 쥐고 하나’라면, 파이프라인은 **‘그 손들을 어떤 순서로 이어 하나의 일로 만드나’**를 다룹니다.

Make 홈페이지 화면 make.com 홈페이지

파이프라인이 왜 따로 짚히는지는 Make에서 선명합니다. Make는 드래그로 단계를 연결해 파이프라인을 짜는 도구이며, AI 업무 자동화 (2026)에서 다루듯 한 일을 여러 단계로 쪼개 순서대로 이어 두는 뼈대를 제공합니다. 파이프라인의 특징은 ‘한 단계가 고장 나면 그 이후가 전부 멈춘다’는 점 — 이것이 파이프라인을 ‘강력하지만 깨지기 쉬운’ 구조로 만듭니다. 2편에서 다룬 RAG도 사실 하나의 파이프라인입니다: ‘질문을 받고 → 관련 문서를 찾아 → 그 문서를 모델에 넣어 → 답을 낸다’의 단계가 정해진 순서로 이어진 구조입니다. 그래서 파이프라인을 이해하면, AI 답이 이상할 때 ‘어느 단계가 삐끗했나’를 단계별로 추적하는 눈이 생깁니다.

5분 안에 직접 확인하기

make.com 홈페이지에서 템플릿 갤러리를 둘러보세요. “이메일이 오면 슬랙으로 보낸다” 같은 예시 파이프라인이 단계가 어떻게 이어지는지 시각으로 보여주어, “앞 단계의 결과가 뒷 단계의 입력이 된다”는 구조를 한눈에 잡게 합니다.
평소 반복하는 일을 세 단계로 쪼개 보세요. “자료를 모으고 → 정리하고 → 보낸다”처럼 단계를 나누면 그것이 이미 파이프라인의 뼈대이며, 어느 단계가 사람 손이 가는지 보는 것이 자동화의 첫 걸음입니다.
“이 일에서 한 단계가 고장 나면 어디서부터 멈출까?”를 한 줄로 적어 보세요. 파이프라인의 약점을 미리 아는 것이 사고를 막는 가장 실용적인 습관입니다.

잘 안 되는 경우

한 단계의 결과를 다음 단계가 검증하지 않은 경우: 앞 단계가 틀린 결과를 내도 그것을 그대로 믿고 다음 단계로 넘기면, 잘못이 파이프라인 끝까지 전파되어 큰 사고로 커집니다. 각 단계마다 ‘이 결과가 말이 되나’를 한 번씩 확인하는 지점이 필요합니다.
외부 서비스가 멈추거나 바뀐 경우: 파이프라인은 여러 외부 도구에 의존하므로, 중간 도구가 서비스를 바꾸거나 멈추면 전체가 멈춥니다. 단계가 많을수록 고장 날 수 있는 접점도 많아지므로, 단계를 최소한으로 유지하는 일이 안정성의 열쇠입니다.

⚠️ 파이프라인의 안정성은 ‘단계 수’와 ‘각 단계의 검증’에 달립니다. 단계가 많을수록 자동화의 폭은 넓어지지만 고장 날 접점도 늘어나며, 한 단계가 틀려도 다음으로 넘어가지 않게 검증 지점을 두는 것이 사고를 막는 핵심입니다. 각 도구의 정확한 연동 방식과 한도는 Make 공식 문서와 Google Apps Script 문서에서 확인하세요.

세 단어가 이어지는 한 흐름

이 섹션에서 배우는 것: 세 단어가 따로 놀지 않고 ‘권한의 폭 → 능력의 확장 → 단계의 연결’의 한 흐름으로 이어진다는 것.

이 세 단어는 하나의 이야기로 이어집니다. 에이전트가 얼마나 알아서 일하나가 자율성이고, 알아서 일할 때 무엇을 손에 쥐고 하나가 도구 사용이며, 그 손들을 어떤 순서로 한 일로 이어 하나가 파이프라인입니다. “권한의 폭 → 능력의 확장 → 단계의 연결”의 한 줄로 묶으면, 왜 AI 리포트가 늘 이 세 단어를 함께 쓰는지가 자리를 잡습니다.

흐름 단계	이번 글의 단어	하는 일	결과가 나타나는 곳
권한의 폭	자율성	사람의 개입 없이 스스로 판단해 일을 이어 감	”한 번 시키면 끝까지 혼자 한다”
능력의 확장	도구 사용	필요할 때 외부 도구·API를 호출해 답을 채움	”검색·계산·실행을 직접 한다”
단계의 연결	파이프라인	여러 단계를 정해진 순서로 한 흐름으로 묶음	”한 일이 여러 단계를 거쳐 완성된다”

이 표를 5편 파라미터 · 어텐션 · 스트리밍과 겹쳐 보면 깊이가 더해집니다. 5편이 ‘모델 한 번의 답이 어떻게 만들어지나’를 다뤘다면, 이번 11편은 ‘그 답들이 어떻게 이어져 하나의 일이 되나’를 다룹니다 — 모델의 크기(파라미터)가 ‘한 답의 품질’을 좌우한다면, 자율성·도구 사용·파이프라인은 ‘그 답이 얼마나 멀리, 얼마나 안전하게 나아가나’를 좌우합니다. 그래서 10편 추론 · 지연 · 처리량이 ‘빠르냐’의 문제였다면, 이번 편은 ‘멀리 가도 괜찮냐’의 문제입니다.

자주 묻는 질문 3가지

Q. 자율성이 높은 AI가 무조건 더 좋은 건가요? 아닙니다. 자율성이 높을수록 사람 손이 덜 가는 건 맞지만, 잘못된 방향으로도 멀리 갈 수 있는 여지가 커집니다. 민감한 권한(결제·삭제·공개)을 다룰 때는 자율성을 낮추고 사람의 확인을 거치는 쪽이 안전하며, 언제 멈추고 물을지(중단 조건)를 미리 정하는 것이 자율성을 ‘능력’으로 쓰는 조건입니다. Anthropic 연구에서 이 균형을 다룹니다.

Q. 도구 사용과 파이프라인은 같은 건가요? 다릅니다. 도구 사용은 AI가 ‘한 번에’ 외부 도구를 부르는 행위이고, 파이프라인은 여러 단계를 ‘정해진 순서로’ 이어 놓은 구조입니다. 하나의 파이프라인 안에 도구 사용 단계가 들어 있을 수 있으며, 도구 사용은 ‘부품’에, 파이프라인은 ‘조립’에 가깝습니다. OpenAI 함수 호출 가이드와 Make 공식 사이트에서 각각의 역할을 확인하세요.

Q. 파이프라인이 고장 나면 어떻게 고치나요? 가장 먼저 ‘어느 단계에서 틀렸나’를 단계별로 좁히는 것이 핵심입니다. 한 단계의 결과를 다음 단계가 검증하지 않으면 잘못이 끝까지 전파되므로, 각 단계에 ‘이 결과가 말이 되나’를 확인하는 지점을 두는 것이 사고를 줄이는 열쇠입니다. 외부 서비스 의존도가 높을수록 고장 접점이 많아지므로 단계를 최소한으로 유지하는 것도 중요합니다.

요약

세 단어를 한 문장씩만 기억해도 AI에게 무엇을 맡길지가 다르게 보입니다.

자율성 → 사람이 매번 개입하지 않아도 AI가 스스로 판단해 일을 이어가는 정도. ‘능력’이기 전에 ‘어디까지 믿고 맡길까’의 판단.
도구 사용 → AI가 필요할 때 외부 도구·API를 직접 호출하는 능력. 모델이 아는 것의 한계를 바깥에서 채우는 장치.
파이프라인 → 여러 처리 단계를 정해진 순서로 이어 한 흐름으로 묶은 구조. 단계가 많을수록 넓지만 깨지기도 쉬운 뼈대.

세 단어를 “얼마나 알아서 하나(자율성) → 무엇을 손에 쥐고 하나(도구 사용) → 어떤 순서로 이어 하나(파이프라인)“의 한 줄로 묶어두면, 다음번에 “AI가 알아서 했다”는 말을 들을 때 “그게 얼마나 알아서 한 건가, 어떤 도구를 썼나, 단계는 어디서 어디로 이어졌나?”를 묻게 됩니다. 이번 주에는 한 가지만 해 보세요 — 평소 AI에게 맡기는 일 하나를 골라 “이 일에서 AI가 어디까지 스스로 결정하고, 어떤 도구를 쓰고, 단계는 몇 단계로 이어지나?”를 한 줄로 적어 보는 것입니다. 그 작은 적기 하나가 자율성의 약속과 위험을 함께 보는 눈을 키워줍니다. 다음 글에서는 “자율성이 가져오는 위험을 어떻게 막을까 — 가드레일 · 정렬 · 안전성, AI가 스스로를 멈추게 하는 세 단어”를 이어서 풀 예정입니다.