에이전틱 AI 용어 20개, 개발자라면 알아야 할 것들

DEV Community

20 Agentic AI Terms Every Developer Should Know (Explained Simply)

Do you ever feel like the AI world has moved forward a little too quickly? You hear about...

Sylwia Laskowska · 2026-09-03

개요 #

자가 치유 시스템, 자율 에이전트, HITL, MCP. 요즘 AI 판에서 쏟아지는 약어들을 보다 보면 이게 기술 용어인지 DJ 예명인지 헷갈릴 때가 있다. Dev.to에 글을 쓰는 Sylwia Laskowska는 이런 혼란을 겨냥해 에이전틱 AI 용어 20개를 정리한 글을 올렸다.

접근법이 독특하다. 학술적 정의를 일부러 버렸다. 필자의 전제는 이렇다. 이미 아는 사람에게는 다섯 문단짜리 설명이 필요 없고, 모르는 사람에게 가장 쓸모없는 게 바로 그 다섯 문단짜리 설명이라는 것.

대신 가상의 억만장자 캐릭터를 세웠다. 이름은 Elon Mózg. 폴란드어로 Mózg는 '뇌'를 뜻한다. 자동차와 로켓을 만들고, 소셜 미디어 플랫폼을 사들였고, 최근에는 AI 코딩 회사까지 인수한 인물이다. 이 사람에게 AI 에이전트가 필요하다는 설정으로 20개 용어를 하나씩 풀어간다. 필자는 2주 뒤 AGNTCon + MCPCon Europe 발표를 앞두고 있고, 본인도 복습이 필요해서 정리했다고 밝혔다.

에이전트의 기본 구조 #

1. AI 에이전트 #

목표를 받고 달성 방법을 스스로 정하는 AI 시스템이다. 단순 챗봇과 갈라지는 지점은 응답 하나를 내놓고 멈추지 않는다는 것. 다음 단계를 계획하고, 도구를 쓰고, 결과를 확인한 뒤 작업을 이어간다.

Elon이 "화성에 기지를 지어줘"라고 했다고 치자. 챗봇이라면 이론 강의를 늘어놓거나 지금은 불가능하다는 소리를 할 것이다. 에이전트는 다르게 움직인다. 가장 가까운 로켓 발사 슬롯을 확인하고, 로켓 상태를 점검하고, 엔지니어를 뽑고, 필요한 장비를 주문한다. 물론 실제로 그렇게 매끄럽게 굴러가진 않겠지만.

2. 에이전틱 워크플로 #

AI가 작업의 일부를 담당하는 다단계 프로세스다. 핵심은 단계 순서를 개발자가 미리 설계해 둔다는 점. 모델이 매번 다음 행동을 결정하지 않아도 된다.

단순한 구조가 이렇다면:

user → prompt → LLM → response

에이전틱 워크플로는 이런 모양이다:

trigger → get data → LLM analyzes data → make a decision → call a tool → LLM generates summary → send result

Elon은 매일 아침 자기 제국 전체 요약을 원한다. 그래서 이렇게 설계한다:

get car sales → get rocket launch status → get latest AI company updates → LLM analyzes everything → choose 5 most important updates → generate morning briefing → send to Elon

AI가 데이터를 분석하고 중요한 정보를 골라 보고서를 만들지만, 매일 아침 프로세스 전체를 새로 발명하지는 않는다. 어떤 단계가 어떤 순서로 일어날지는 이미 정해져 있다. 물론 유연성을 넣을 수도 있다. rocket launch delayed? → ask LLM to summarize why 같은 식으로. 그래도 여전히 미리 설계한 워크플로 위를 지나간다.

3. 에이전트 루프 #

에이전트가 행동하고, 결과를 관찰하고, 무슨 일이 있었는지에 따라 다음 행동을 정하는 메커니즘이다. 필자는 예전에 80줄 코드로 기본 AI 에이전트를 만들 수 있다는 글을 쓴 적이 있다.

단순화하면 이렇다:

decide → act → observe → decide → act → observe → ...

목표를 달성했다고 에이전트가 판단하거나, 우리가 멈추라고 할 때까지 반복된다. 실제 시스템이라면 최대 반복 횟수를 걸어두는 게 좋다.

Elon이 "이번 주에 저녁 시간 비는 날 찾아줘"라고 물었다. 이번엔 해답까지 가는 경로를 프로그래밍해 두지 않았다. 에이전트가 직접 찾아야 한다. 캘린더 확인 → 빈 저녁 없음. 옮길 수 있는 회의 탐색 → 자동차 회사 회의가 유력. 옮기려 시도 → 화성 식민지 계획과 충돌. 목요일 확인 → 로켓 발사. 금요일 확인 → 다른 스타트업 인수 마무리. 토요일 확인 → 비어 있음.

에이전트가 "토요일 저녁이 비었습니다"라고 답하면, Elon은 "좋아, 회의 잡아"라고 한다. 그리고 루프가 다시 시작된다.

워크플로와 루프, 어떻게 다른가 #

가장 간단하게 구분하면 이렇다. 에이전틱 워크플로 = AI를 쓰도록 설계된 프로세스. 에이전트 루프 = AI가 행동하고 결과를 확인해 다음 반복에서 뭘 할지 정하는 것.

중요한 건 에이전트 루프가 더 큰 에이전틱 워크플로의 한 구성 요소가 될 수 있다는 점이다. 워크플로는 전체 프로세스를 설명하고, 루프는 에이전트가 단계별로 움직이며 직전 결과에 반응하게 하는 메커니즘을 설명한다.

모델 바깥의 장치들 #

Photo by Markus Winkler on Pexels

4. 툴 콜링 #

LLM은 훌륭하지만 결국 정교한 다음 단어 예측기다. 인터넷 전체를 뒤지거나 은행을 털 수 있는 전지전능한 존재가 아니다. 모델이 실제로 뭔가를 하게 하려면 적절한 함수나 도구에 접근할 수 있게 해줘야 한다. 모델이 필요한 도구를 골라 툴 콜을 생성하면, 애플리케이션이나 에이전트 하니스가 그걸 실행하고 결과를 모델에 돌려준다.

Elon이 "어제 빨간 차 몇 대 팔았어?"라고 묻는다. 에이전트는 숫자를 지어내지 않는다. 쓸 수 있는 도구를 본다:

getRedCarsSales(date)

툴 콜을 요청하고, 결과를 받은 뒤에야 답한다. "백만 대입니다, Elon. 평범한 하루였네요."

5. 에이전트 하니스 #

LLM 하나만으로는 에이전트 전체가 되지 않는다. 하니스는 모델을 둘러싼 소프트웨어로, 도구·에이전트 루프·컨텍스트·상태·권한·에러를 관리한다.

Elon이 "최신 차량 빌드가 테스트 다 통과했는지 확인하고, 아니면 팀에 알려줘"라고 했다. 모델은 CI 결과를 확인해야겠다까지는 알아낼 수 있다. 하지만 실제로 CI를 확인하고, 결과를 모델에 넘기고, 모델이 다음 행동을 정하게 하는 것은 하니스의 몫이다. LLM이 뇌라면, 하니스는 그 주변에 나머지 몸을 만든다.

6. 컨텍스트 엔지니어링 #

에이전트를 만들 때 시스템 프롬프트만으로 부족한 순간이 온다. 컨텍스트 엔지니어링은 특정 시점에 모델이 어떤 정보를 받아야 하는지 설계하는 일이다. 문서, 대화 기록, 메모리, 도구 실행 결과, 사용자 데이터 같은 것들이 대상이다.

Elon이 "그거 X에 올려"라고 했다고 하자. 컨텍스트 없이는 끔찍한 지시다. 하지만 제대로 된 컨텍스트가 있으면 에이전트는 알 수 있다. "그거"가 무엇을 가리키는지(예: 또 다른 스타트업 인수), 대화 앞부분에서 무슨 일이 있었길래 이 글이 긍정적이어야 하는지 부정적이어야 하는지, Elon이 문안을 승인했는지, 애초에 게시 권한이 있는지.

컨텍스트는 많이 준다고 좋은 게 아니다. 맞는 걸 줘야 좋다.

7. 메모리 #

현재 컨텍스트 윈도우에만 의존하지 않고 중요한 정보를 저장했다가 나중에 꺼내 쓰는 메커니즘이다. 같은 얘기를 열 번째 설명하고 싶지 않다면 필수다.

월요일에 Elon이 "AI 코딩 회사 하나 살까 생각 중이야"라고 한다. 3주 뒤 Elon이 묻는다. "내가 사려던 게 뭐였지?" 에이전트가 답한다. "AI 코딩 회사입니다." "맞다. 얼마였지?" "제발 하지 마세요."

메모리는 작동한다.

8. MCP: Model Context Protocol #

당신이 타이어나 로켓 부품 제조사라고 해보자. 당연히 Elon의 에이전트든 누구의 에이전트든 당신 제품을 주문할 수 있길 바랄 것이다. 그런데 모든 에이전트가 당신 시스템 구조를 일일이 추측하게 만들 수는 없다.

여기서 MCP가 등장한다. Model Context Protocol은 AI 애플리케이션이 외부 도구와 컨텍스트에 표준화된 방식으로 연결되게 하는 오픈 프로토콜이다. MCP 서버는 도구(tools), 리소스(resources), 프롬프트(prompts) 같은 걸 노출할 수 있다.

Elon이 묻는다. "10분 뒤에 소셜 미디어 플랫폼 대표랑 미팅인데, 잘라야 하나?" 에이전트는 연결된 MCP 서버로 Slack, 사내 문서, 매출 실적, Jira, 그리고 오늘의 별자리 운세까지 확인한 뒤 답한다. "아니요. Joe는 남겨두시죠. 적어도 지금은요."

판단하고 나누는 능력 #

9. 플래닝 #

복잡한 목표를 받으면 에이전트는 곧바로 첫 행동으로 뛰어들지 않고 작은 작업으로 쪼갠 뒤 순서를 정할 수 있다.

"화성에 식민지를 지어줘"에 대한 계획은 이렇다. 적합한 위치 찾기 → 운송 수단 마련 → 전력 공급 → 산소 공급 → 물 공급 → 거주지 건설 → 실제로 갈 사람 설득하기. 마지막 단계는 별도 에이전트가 필요할지도 모른다.

10. 리즈닝 #

정보를 단순히 검색하거나 재생산하는 것 이상을 요구하는 문제를 푸는 능력이다. 여러 가능성을 비교하고, 제약을 고려하고, 합리적인 행동을 고르는 일. 리즈닝이 에이전트만의 것은 아니지만, 에이전틱 시스템에서 특히 중요한 이유는 다음에 뭘 할지 정하는 데 직접 쓰이기 때문이다.

Elon이 묻는다. "로켓 발사는 텍사스에서 오후 6시, 이사회는 캘리포니아에서 오후 4시야. 둘 다 갈 수 있나?" 에이전트는 회의 시간, 이동 시간, 시차를 모두 따진 뒤 답한다. "로켓이 태우러 오지 않는 한 안 됩니다."

11. 멀티 에이전트 시스템 #

모든 걸 다 아는 에이전트 하나 대신, 역할이 다른 반자율 에이전트 여럿이 일을 나눠 협업하는 구조다.

Elon Mózg의 제국에는 이런 에이전트들이 있다. Car Company Agent(자동차), Space Agent(로켓), Social Media Agent(소셜 미디어), AI Systems Agent(AI), Finance Agent(돈), 그리고 Personal Assistant Agent(위의 전부를 통제하려 필사적으로 노력하는 역할).

Elon: "다 잘 돌아가고 있나?"

Personal Assistant Agent: "다가 뭘 말하는지부터 정의해 주시죠."

여럿을 엮는 방법 #

Photo by Ivan S on Pexels

12. 오케스트레이션 #

에이전트와 도구가 여러 개가 되면, 누가 어떤 작업을 언제 수행하고 그다음 뭐가 일어날지 관리할 주체가 필요하다. 오케스트레이터는 작업을 위임하고 결과를 모은다.

"화성에서 신차 출시하자"는 지시에 오케스트레이터는 이렇게 움직인다. → Space Agent: 거기까지 갈 수 있나? → Car Company Agent: 차가 그 여정을 견디나? → Finance Agent: 이 헛짓거리에 얼마 드나? → Legal Agent: 제발 진짜로 하는 건 아니라고 말해줘. 결과가 메인 에이전트로 돌아오고, 최종 답변이 만들어진다.

13. 핸드오프 #

한 에이전트가 특정 작업을 더 전문화된 다른 에이전트가 맡아야 한다고 판단하는 것이다. 다른 에이전트를 도구처럼 쓰는 것과 달리, 두 번째 에이전트가 대화나 작업의 다음 부분을 넘겨받는다.

Elon: "엔진 하나가 이상하게 작동해."

Personal Assistant Agent의 답은 이렇다. "치과 예약은 옮겨드릴 수 있습니다. 로켓 엔진 진단은 못 합니다." → Space Engineering Agent로 핸드오프. 합리적인 판단이다.

14. A2A: Agent2Agent Protocol #

서로 다른 에이전트가 소통하고 협업하게 하는 프로토콜이다. 다른 팀이 만들었거나 다른 시스템에서 돌아가도 상관없다.

Elon이 "로켓 왜 터졌어?"라고 묻는다. 그의 에이전트는 로켓 과학자가 아니다. 그래서 Rocket Scientist Agent에 연락하고, 그쪽이 데이터를 분석해 결과를 돌려보낸다. 아주 단순화하면 이런 대비다.

MCP: 에이전트 ↔ 도구

A2A: 에이전트 ↔ 에이전트

통제하고 검증하기 #

15. 가드레일 #

에이전트의 행동을 통제하거나 제한하는 장치다. 입력과 출력을 검사하고, 도구 접근을 제한하고, 특정 권한을 요구하고, 어떤 행동은 아예 막는다.

Elon의 개인 에이전트가 할 수 있는 일은 회사 분석, 캘린더 읽기, 이메일 초안 작성, 발사 일정 확인, 소셜 미디어 게시물 준비. 할 수 없는 일은 로켓을 혼자 발사하기, 직원을 혼자 해고하기, 게시물을 혼자 올리기, 그리고 스타트업을 혼자 사들이기(예전엔 이게 당연하지 않았던 모양이다).

마지막 가드레일은 사건 하나 터진 뒤에 추가했다.

16. Human-in-the-Loop (HITL) #

에이전트가 자율적으로 돌아가되, 프로세스 일부에 사람을 의도적으로 끼워 넣는 것이다. 중요한 행동을 승인하거나, 출력을 교정하거나, 에이전트에게 온전히 맡기고 싶지 않은 결정을 내리는 용도다.

에이전트: "약 440억 달러에 소셜 미디어 플랫폼을 인수하려 합니다."

"이 작업은 되돌리기 어렵습니다."

"정말 진행하시겠습니까?"

[Yes] [God, please, don't!!!]

Elon Mózg가 클릭한다. 에이전트가 말한다. "뭐. 사람은 루프 안에 있었습니다."

17. Evals #

에이전트가 작업을 얼마나 잘 수행하는지 판단하는 테스트다. 최종 답변이 그럴듯한지만 보는 게 아니다. 올바른 도구를 골랐는지, 정확한 단계를 밟았는지, 기대한 결과에 도달했는지도 평가할 수 있다.

Elon Mózg 개인 비서 Eval 스위트의 테스트 하나. "Elon이 이사회와 미팅을 잡아달라고 요청한다."

기대 동작:

check calendar → find slot → ask attendees → schedule

실제 동작:

buy another startup

FAIL. 아직 갈 길이 멀다.

검색하고 조작하기 #

18. 컴퓨터 유즈 #

API에만 의존하지 않고 에이전트가 일반 사용자 인터페이스를 보고 조작하는 것이다. 웹사이트를 열고, 버튼을 찾아 클릭하고, 텍스트를 입력한다. 에이전트가 이걸 완벽하게 해내는 경우는 드물지만, 없는 것보단 낫다.

Elon에게 정부 문서가 필요하다. 그런데 정부 포털은 2007년에 만들어졌다. 필자는 폴란드에도 그런 사이트가 꽤 있다고 덧붙였다. API도 없고 MCP도 없다. 대신 47개 필드짜리 폼이 있다.

에이전트가 Chrome을 연다.

에이전트: "폼을 찾았습니다."

Elon: "좋아."

에이전트: "Internet Explorer가 필요합니다."

Elon: "화성으로 가자."

19. 에이전틱 RAG #

고전적인 RAG는 시스템이 정보를 검색해 모델에 넘긴다. 에이전틱 RAG에서는 에이전트가 검색 과정 자체를 통제한다. 어떤 정보가 빠졌는지 판단하고, 추가 데이터를 찾고, 쿼리를 다시 짜고, 그다음에야 답을 내놓는다.

"유럽에 기가팩토리를 하나 더 지어야 할까?"라는 질문에 에이전트는 먼저 매출을 확인하고 → 생산 데이터가 필요하다는 걸 알아채고 → 그걸 가져오고 → 에너지 가격 → 규제 → 후보 부지를 확인해 결과를 비교한다.

search() 한 번이 아니라 에이전트가 통제하는 리서치인 셈이다.

20. 보너스: 에이전트 워싱 #

자율적으로 작업을 수행하는 것과 거의 또는 전혀 관계없는 제품을 **"AI 에이전트"**라고 부르는 마케팅 관행이다.

Elon Mózg가 무대에 오른다. "오늘 Glokzilla Agent Ultra를 소개합니다. 세계 최초의 완전 자율 범용 리즈닝 에이전트입니다."

개발자가 레포를 열어본다.

user → prompt → LLM → response

개발자: "Elon, 그거 챗봇인데요."

Elon: "에이전틱 챗봇입니다."

투자 유치 성공.

정리 #

20개 용어를 관통하는 축은 결국 두 가지다. 하나는 모델 바깥에 무엇을 붙이느냐(하니스, 도구, 메모리, 컨텍스트), 다른 하나는 자율성을 어디까지 허용하느냐(가드레일, HITL, evals). 필자가 굳이 억만장자 캐릭터를 세운 이유도 여기 있어 보인다. 추상적인 정의보다 "이 에이전트가 혼자 로켓을 쏴도 되는가"라는 질문이 훨씬 기억에 남으니까.

필자는 당분간 리스트형 글은 이게 마지막이라고 못 박으며 글을 마쳤다.

이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.