에이전트(Agent). 라틴어로 "행동하는 자"라는 뜻입니다.
AI를 만나면서 "스스로 판단하고 행동하는 시스템"이 됐죠.

OpenClaw로 에이전트 광풍이 불더니,
하네스 엔지니어링과 만나면서 2026년의 핵심 키워드로 자리잡는 중이에요.

에이전트가 얼마나 대세냐면, Anthropic이 3월 12일에 "Claude Certified Architect" 자격증 시험을 출시했어요. 에이전트 아키텍처, MCP, Claude Code 설정까지 프로덕션 수준으로 시험 봅니다. 파트너사 소속만 응시 가능하고 일반인은 못 봐요. 에이전트가 유행이 아니라 직무가 되고 있다는 신호죠.

그 시험 가이드를 통째로 뜯어서 화제가 됐던 hoeem이란 개발자가, 이번엔 에이전트 입문 가이드를 공개했습니다. "아무도 처음부터 끝까지 정리한 강좌를 안 만들어서 내가 만들었다"고 해요.

읽으면 오늘 에이전트 하나 만들 수 있습니다. 핵심만 뽑아볼게요.

Q. AI 에이전트가 뭔데요?

구조는 놀라울 만큼 단순합니다.

사용자가 입력 → AI가 생각 → 직접 답할지 도구를 쓸지 결정 → 도구를 썼으면 결과를 다시 AI한테 전달 → 반복

AI가 뇌, 도구가 손, 기억이 메모장. LangGraph를 쓰든 CrewAI를 쓰든 OpenAI SDK를 쓰든, 이 루프는 안 바뀝니다.

일반 AI는 텍스트를 받아서 텍스트를 내놓는 게 전부예요. 에이전트는 여기에 세 가지가 붙습니다. 도구(계산기, 검색, 파일, API), 검색(외부 정보 가져오기), 기억(대화 내용이나 문서를 기억하기).

Q. 근데 에이전트가 진짜 필요한가요?

대부분은 필요 없습니다. 이 가이드에서 제일 중요한 부분이에요.

워크플로우는 순서가 정해져 있습니다. 같은 입력이면 항상 같은 경로. 싸고 안정적이에요. 에이전트는 AI가 다음 단계를 알아서 결정합니다. 유연하지만 비용이 더 들어요.

먼저 워크플로우로 시작하세요. 그걸로 안 되면 그때 에이전트로 올리면 됩니다.

Q. 워크플로우만으로 풀 수 있는 게 뭔가요?

Anthropic이 정리한 5가지 패턴이 있어요. 대부분의 문제가 여기서 해결됩니다.

1. 프롬프트 체이닝 — 작업을 순서대로 연결. 카피를 쓰고 → 번역하고 → 검수하는 식.

2. 라우팅 — 입력을 분류해서 맞는 처리로 보냄. 고객 문의가 오면 결제/기술/영업으로 나눠서 각각 다른 프롬프트로.

3. 병렬화 — 독립적인 작업을 동시에 돌림. 보고서 3개 섹션을 따로 쓰거나, 같은 질문을 3번 돌려서 다수결.

4. 오케스트레이터-워커 — 중앙 AI가 작업을 쪼개서 일꾼 AI들한테 나눠줌. 어떻게 쪼갤지는 상황 보고 판단.

5. 평가자-최적화 — AI 하나가 만들고, 다른 AI가 평가. 합격할 때까지 반복.

Q. 진짜 만들려면요?

이 질문 네 개에 답할 수 있으면 첫 버전은 하루면 만듭니다.

"결과물이 뭐야?" — 요약 리포트인지, 분류 결과인지, 수정된 문서인지.
"어떤 정보가 필요해?" — 웹 검색, 파일, 데이터베이스, 아니면 사용자 입력만.
"어떤 행동을 할 수 있어?" — 답변만, 검색도, 파일 수정까지.
"지켜야 할 규칙이 뭐야?" — 톤, 형식, 불확실할 때 어떻게 할지.

공식은 이거예요.

에이전트 = 역할 + 목표 + 도구 + 규칙 + 출력 형식

예시: 역할은 리서치 어시스턴트, 목표는 정확한 정보 수집과 요약, 도구는 웹 검색과 계산기, 규칙은 출처 표기 + 불확실하면 말하기, 출력은 요약/리스크/결론.

Q. AI한테 에이전트 설계를 시킬 수 있나요?

됩니다. 이게 꿀팁이에요.

"AI 에이전트를 만들고 싶어요. 목표는 [설명]. 사용자가 이런 걸 물어볼 거예요 [예시 5개]. 쓸 수 있는 도구는 [목록]. 반드시 지켜야 할 규칙은 [목록]. 이걸 에이전트 설계서, 시스템 프롬프트, 도구 목록, 테스트 케이스 10개로 만들어줘."

이 프롬프트 하나로 막연한 아이디어가 만들 수 있는 계획이 됩니다.

Q. 초보자한테 맞는 에이전트 유형은요?

다섯 가지예요.

1. 리서치 에이전트 — 정보 모아서 요약. "이 주제 최신 자료 정리해줘."
2. 콘텐츠 에이전트 — 글 쓰거나 다듬기. "내 메모를 뉴스레터로 바꿔줘."
3. 워크플로우 에이전트 — 반복 업무 처리. "고객 문의 분류해줘."
4. 지식 에이전트 — 내 문서에서만 답하기. "이 PDF들만 보고 답해줘."
5. 실행 에이전트 — 파일 고치거나 코드 돌리기. "이 파일 읽고 수정해줘."

멀티 에이전트 스웜 같은 건 나중이에요. 에이전트 하나, 프롬프트 하나, 도구 1에서 2개, 테스트 5에서 10개. 여기서 출발하세요.

Q. 도구는 많을수록 좋지 않나요?

hoeem이 제일 강조하는 부분이에요. "더 많은 도구 = 더 똑똑한 에이전트"가 아닙니다. "더 나은 도구 = 더 똑똑한 에이전트"이고, "더 적은 도구 = 더 안정적인 에이전트"예요.

추가하기 전에 물어보세요. "AI가 추론만으로 답할 수 있나?" 그러면 도구 필요 없어요. "실시간 데이터나 외부 행동이 필요한가?" 그때만 넣으세요.

도구 하나가 하나의 일만 해야 합니다. 파일 관리를 하나에 다 넣지 말고 read_file, write_file, delete_file로 나누세요.

도구 자체보다 "언제 쓸지"를 알려주는 게 더 중요해요. "계산기 도구"라고만 하면 안 씁니다. "수학이 필요하면 반드시 이 도구를 써라. 절대 추측하지 마라."까지 적어야 해요.

Q. 기억(메모리)은요?

두 종류뿐이에요.

단기 기억 = 지금 대화에서 뭘 말했는지. 기본으로 돼 있어요.
장기 기억 = 외부 문서나 과거 데이터를 찾아보는 것.

70%는 메모리가 필요 없습니다. 메모리 없이 되면 넣지 마세요. 벡터 DB, 임베딩, 복잡한 파이프라인은 나중에. 뭔가 안 될 때만 추가하세요.

Q. 멀티 에이전트는 언제요?

거의 안 씁니다.

필요한 경우는 세 가지뿐이에요. 기술이 완전히 다를 때, 파이프라인이 명확할 때, 권한이 달라야 할 때. 그 외에는 에이전트 하나 + 좋은 도구면 충분합니다.

제일 안전한 패턴은 수퍼바이저 모델이에요. 사용자 → 메인 에이전트 → 필요하면 다른 에이전트 호출. 스웜이나 완전 자율 멀티 에이전트로 시작하지 마세요. 쉽게 깨집니다.

Q. 만들고 나서 어떻게 개선하나요?

깔끔한 입력이 아니라 실제 사용자처럼 테스트하세요.

"이 기술 이슈를 분류해주세요" 대신 "왜 또 결제됐어 ㅡㅡ 어떻게 해야돼"로요.

실패하면 한 번에 하나만 고칩니다. 프롬프트 → 출력 형식 → 예시 → 도구 → 메모리 → 검색. 이 순서. AI한테 디버깅을 시킬 수도 있어요. "이게 내 에이전트인데, 이걸 물어봤더니 이런 결과가 나왔어. 뭐가 잘못된 거야?"

에이전트의 핵심 루프는 Python 50줄이면 됩니다. 진짜 어려운 건 코드가 아니라, 도구 설계, 에러 처리, 테스트, 그리고 "이게 정말 에이전트가 필요한 일인가?"를 판단하는 거예요.

에이전트 하나. 프롬프트 하나. 도구 두 개. 테스트 열 개. 여기서 시작하세요.

원문 → https://x.com/hooeem/status/2037250422403113188

한 줄 평,

"휴..꿀단지 너무 먹었더니 달다달어..."

AI계의 곰돌이 푸,
엉클잡스의 꿀단지를 드시고 싶다면
팔로미

https://fronmpt.beehiiv.com/