AI 에이전트 (agent)

에이전트

AI 에이전트 (agent)

LLM 에 도구와 루프를 쥐어 주고, 목적에 맞게 스스로 판단하며 여러 단계를 실행하게 만드는 구조의 총칭.

1줄 정의

LLM 에 도구와 루프를 쥐어 주고, 목적에 맞게 스스로 판단하며 여러 단계를 실행하게 만드는 구조의 총칭.

전체 시스템에서 맡는 역할

“AI 에이전트” 는 2024 년 이후 업계 중심 키워드가 됐다. 다만 말이 넓어서 “LLM 을 약간 만진 것” 수준으로 뿌옇게 쓰이기도 한다. 여기서 정의 윤곽을 분명히 해 두자.

AI 에이전트의 본질은 3요소의 조합에 있다.

  • LLM: 판단과 생성을 하는 뇌
  • Tools: 바깥에 작용하는 손발 (파일 읽기/쓰기, API 호출, 검색, 명령 실행 등)
  • Loop: “판단 → 도구 실행 → 결과 읽기 → 다시 판단” 을 도는 제어 구조

이 셋이 갖춰진 게 agent. LLM 단발 호출 (ChatGPT 의 1문 1답) 은 agent 가 아니다. 1회 API 호출로 끝이니까. Tools 가 있어도 Loop 가 없으면 agent 라 부르기 어렵다. 한 스텝만 도니까.

Claude CodeCursor 의 Agent 모드가 전형. 사용자가 “이 버그 고쳐” 라고 하면 모델은 읽고 → 생각하고 → 편집하고 → 테스트 돌리고 → 결과 보고 → 다시 고친다, 를 스스로 돈다. 중간에 사람에게 물을 수도 있지만 기본은 자율로 다음 스텝을 고른다.

요점은 이것. 에이전트를 쓴다는 건 루프 제어를 LLM 에 맡긴다는 것. 이게 기존 자동화 (사람이 플로우차트 그리고 그대로 도는 방식) 와의 본질적 차이다.

흔한 오해

  • 오해 1: LLM 에 지시만 내리면 다 “에이전트” 다, 라고 말해지기 쉽다.

– 실제로는 도구와 loop 가 없으면 agent 가 아니라 “chatbot + 프롬프트 엔지니어링” 에서 그친다. 구분하지 않으면 설계 논의가 엇갈린다.

  • 오해 2: 에이전트는 완전 자율로 돈다, 라고 기대되기 쉽다.

– 실제로 완전 자율은 다루기 어렵고, 현실에서는 “반자율 + 사람 체크포인트” 로 설계된다. 어디서 사람이 개입할 것인가 (허가 다이얼로그, 차분 리뷰, 위험 조작 확인) 의 설계야말로 실력을 보이는 곳.

  • 오해 3: 에이전트는 프롬프트만 잘 쓰면 만들 수 있다, 로 단순화되기 쉽다.

– 실제로는 프롬프트뿐 아니라 harness 설계 (도구, 권한, 컨텍스트 관리, 에러 처리) 가 품질의 대부분을 결정한다. 프롬프트는 요소 하나일 뿐이다.

이 용어가 중요한 이유

“에이전트” 를 모호하게 계속 쓰면 제품에 AI 를 넣을 때의 설계 판단이 거칠어진다. 이게 실무 가치.

  • 이 태스크는 단발 LLM 으로 충분한가, 루프가 필요한가
  • 도구는 뭘 건넬 것인가, 권한을 어디서 끊을 것인가
  • 실패 시 재시도를 모델에 맡길 것인가, 코드로 제어할 것인가
  • 사용자 확인은 어느 타이밍에 끼울 것인가

이 질문들에 구체적인 답을 가질 수 있는 건 “에이전트” 라는 말을 윤곽 있게 이해하고 있을 때뿐이다. 자기 팀이나 제품에서 “이거 agent 인가” 를 구분할 수 있는 언어를 갖춰 두면 설계 회의의 해상도가 올라간다.

이 용어가 나오는 기사

  • Claude Code / Cursor / 바이브 코딩 관련 거의 모든 기사 (※ auto-link 로 자동 삽입)

다음에 읽을 용어 3개

  • Claude Code — 에이전트의 참조 구현.
  • tool use — 에이전트의 손발을 성립시키는 기구.
  • harness — 에이전트를 감싸는 바깥층.
最終更新: 2026-04-18 · shuntailor.net テイラー百科事典

AI エージェント

エージェント

AI エージェント

LLM にツールとループを与え、目的に対して自分で判断しながら複数ステップを実行させる仕組みの総称。

一行定義

LLM にツールとループを与え、目的に対して自分で判断しながら複数ステップを実行させる仕組みの総称。

全体システムの中での役割

「AI エージェント」は 2024 年以降、業界の中心キーワードになった。ただ言葉が広いせいで、「LLM をちょっと工夫したやつ」程度にぼんやり使われることも多い。ここで定義の輪郭を明確にしておく。

AI エージェントの本質は 3 つの要素の組み合わせにある。

  • LLM: 判断と生成を行う脳
  • Tools: 外部に対して作用する手足(ファイル読み書き、API 呼び出し、検索、コマンド実行など)
  • Loop: 「判断 → ツール実行 → 結果を読み → また判断」を回す制御構造

この 3 つが揃ったものが agent。LLM 単発呼び出し(ChatGPT の一問一答)は agent ではない。1 回の API コールで終わるから。Tools があっても Loop がなければ agent と呼びにくい。1 ステップだけ動くから。

Claude CodeCursor の Agent モードは典型例。ユーザーが「このバグを直して」と言うと、モデルは読む → 考える → 編集する → テストする → 結果を見る → 直す、を自分で回す。途中で人間に聞くこともできるが、デフォルトは自律的に次のステップを選ぶ。

ここがポイント。エージェントを使うということは、ループの制御を LLM に委ねるということ。これが従来の自動化(人間がフローチャートを書いて、それ通りに動く)との本質的な違いだ。

よくある誤解

  • 誤解 1:LLM に指示を出せば全部「エージェント」だ、と言われがち。

– 実際には、ツールと loop がないと agent ではなく「chatbot + プロンプトエンジニアリング」止まり。区別しないと設計議論が噛み合わなくなる。

  • 誤解 2:エージェントは完全自律で動く、と期待されがち。

– 実際には、完全自律は扱いが難しく、現実には「半自律 + 人間のチェックポイント」で設計される。どこで人間が介入するか(許可ダイアログ、差分レビュー、危険操作の確認)の設計こそが腕の見せ所。

  • 誤解 3:エージェントはプロンプトをうまく書けば作れる、と単純化されがち。

– 実際には、プロンプトだけでなく harness の設計(ツール、権限、コンテキスト管理、エラー処理)が品質の大半を決める。プロンプトは一つの要素にすぎない。

この用語が重要な理由

「エージェント」を曖昧に使い続けると、プロダクトに AI を組み込む時の設計判断が粗くなる。これが実務価値。

  • このタスクは単発 LLM で十分か、ループが必要か
  • ツールは何を渡すか、どこで権限を切るか
  • 失敗時のリトライはモデルに任せるか、コードで制御するか
  • ユーザーへの確認はどのタイミングで挟むか

これらの問いに具体的な答えを持てるのは、「エージェント」という語を輪郭つきで理解している時だけだ。自分のチームや製品で「これは agent なのか」と区別できる言語を持っておくと、設計会議の解像度が上がる。

この用語が登場する記事

  • Claude Code / Cursor / バイブコーディング関連ほぼ全記事(※ auto-link で自動挿入)

次に読むべき用語 3 つ

  • Claude Code — エージェントのリファレンス実装。
  • tool use — エージェントの手足を成立させる機構。
  • harness — エージェントを包む外側の層。
最終更新: 2026-04-18 · shuntailor.net テイラー百科事典
JAKO