Molayo

© 2026 Molayo

Qiita헤드라인2026. 06. 15. 15:46

AI 에이전트 구축에 필요한 기술을 IBM의 7가지 요소로 정리하다

요약

IBM의 7가지 핵심 기술을 바탕으로 AI 에이전트 구축에 필요한 기술 스택과 설계 원칙을 정리합니다. 단순 프롬프팅을 넘어 아키텍처, 도구 설계, 평가 및 관측 가능성을 포함한 시스템적 접근법을 다룹니다.

핵심 포인트

  • AI 에이전트는 프롬프트를 넘어 시스템 설계와 오케스트레이션이 핵심임
  • 도구 설계 시 입출력 스키마, 권한, 실패 처리 설계가 필수적임
  • 로그, 트레이스, 메트릭을 통한 평가와 관측 가능성이 실무의 핵심임
  • 확률적으로 동작하는 모델을 위해 기존 소프트웨어 공학적 접근이 필요함

AI 에이전트를 만드는 이야기를 따라가다 보면 프롬프트 (Prompt), RAG, 도구 (Tool), 평가 (Evaluation), 가드레일 (Guardrail), 멀티 에이전트 (Multi-agent) 등 다양한 용어들이 한꺼번에 등장합니다.

저 자신도 "결국 어디서부터 어디까지 배워야 할까"라며 혼란을 겪고 있습니다. 그래서 IBM의 영상인 'The 7 Skills You Need to Build AI Agents'를 입구로 삼아, AI 에이전트 구축에 필요한 기술을 정리해 보려 합니다.

다만, IBM의 7가지만을 유일한 지도로 본다면 조금 놓치는 관점이 있을 수도 있습니다. 이 기사에서는 IBM의 7가지 기술을 토대로 하면서, Karpathy, Andrew Ng, Anthropic, OpenAI, Google, Chip Huyen 등의 1차 정보와 비교하며 살펴보겠습니다.

세세한 구현 절차가 아니라, "앞으로 AI 에이전트를 만든다면 무엇을 배워야 하는가"에 대한 지도를 만들기 위한 기사입니다.

읽으시는 분들에게 다음과 같은 상태를 제공할 수 있기를 바랍니다.

  • IBM의 7가지 기술을 단순한 체크리스트가 아닌 구현의 지도로 사용할 수 있음
  • 자신의 프로젝트에서 무엇을 해야 할지 판단할 수 있음
  • "에이전트를 만드는 것" 외에, 심플한 워크플로우 (Workflow)로 끝낼 수 있는 선택지를 가질 수 있음

AI 에이전트 구축에서 우선적으로 파악해야 할 핵심은 다음 세 가지라고 생각합니다.

  • 아키텍처와 오케스트레이션 (Architecture and Orchestration): LLM, 도구, 데이터, 서브 에이전트, 인간의 확인을 어떻게 연결할 것인가
  • 도구 설계 (Tool Design): AI가 망설임 없이 사용할 수 있는 입출력, 스키마 (Schema), 권한, 실패 시의 처리를 어떻게 설계할 것인가
  • 평가와 관측 가능성 (Evaluation and Observability): 데모에서 작동하던 것을 왜 실패했는지 추적할 수 있는 본 프로덕션 시스템으로 만들 수 있는가

특히 평가는 여러 정보원들이 매우 강력하게 주장하고 있는 부분입니다. 프롬프트를 수정해서 "왠지 좋아진 것 같다"는 느낌에서 멈추지 않고, 로그 (Log), 트레이스 (Trace), 메트릭 (Metric), 테스트 케이스 (Test case)를 통해 개선하는 지점이 에이전트 구축의 실무적인 핵심이라고 생각합니다.

전체상을 먼저 표로 나타내면 다음과 같습니다.

관점IBM의 7가지 기술로 보이는 것다른 정보원에서 보완할 것
설계시스템 설계, 신뢰성, 보안Anthropic의 심플한 워크플로우, OpenAI의 에이전트 분할
...

IBM Technology의 영상은 프롬프트 엔지니어링 (Prompt Engineering)과 에이전트 엔지니어링 (Agent Engineering)을 나누어 생각하고 있습니다.

좋은 프롬프트를 쓰는 것도 중요하지만, 그것만으로는 에이전트를 만들 수 없습니다. LLM, 도구, 데이터베이스, 외부 API, 권한, 인간의 확인, 실패 시의 회복까지 포함하여 시스템으로서 설계해야 합니다.

영상에서 언급된 7가지를 제 이해대로 정리하면 다음과 같습니다.

기술무엇을 보는가
시스템 설계LLM, 도구, DB, 서브 에이전트를 어떻게 협조시킬 것인가. 실패 시의 경로도 포함
...

여기서 중요한 것은, 많은 부분이 "기존의 소프트웨어 공학을 확률적으로 동작하는 부품에 다시 적용하는" 이야기라는 점입니다.

에이전트는 모델이 똑똑하다고 해서 저절로 안정되는 것이 아닙니다. 외부 도구가 다운되거나, 검색 결과가 약하거나, 모델이 형식을 틀리거나, 읽은 문서에 악의적인 지시가 포함되는 상황. 그러한 전제를 바탕으로 설계해야 합니다.

IBM의 7가지 기술은 상당히 실무적입니다. 반면, 다른 1차 정보와 비교해 보면 IBM에서는 크게 전면에 내세우지 않는 논점도 있습니다.

Google의 Agents 화이트페이퍼 (Whitepaper)나 5-Day Intensive에서는 메모리 (Memory)가 주요 구성 요소로 다뤄지고 있습니다. Karpathy 또한 LLM은 장기적인 기억을 자연스럽게 갖지 않으며, 기본적으로 컨텍스트 윈도우 (Context Window)에 의존하고 있다는 문제를 강조합니다.

이 부분은 RAG와 겹치는 부분도 있습니다. 과거의 대화, 사용자의 취향, 과거의 판단을 검색하여 추출한다면 리트리벌 (Retrieval)의 연장선입니다.

다만, 무엇을 기억할지, 무엇을 잊을지, 제한된 컨텍스트에 무엇을 채워 넣을지는 단순한 검색 품질뿐만 아니라 상태 관리 (State Management)에 가까운 이야기입니다. 얼마 전부터 자주 언급되는 컨텍스트 엔지니어링 (Context Engineering)도 이 주변의 이야기라고 생각합니다.

Andrew Ng는 에이전트의 대표적인 설계 패턴으로 Reflection, Tool use, Planning, Multi-agent collaboration을 꼽았습니다.

IBM의 7가지에도 시스템 설계나 서브 에이전트 이야기는 있지만, 태스크 분해, 자기 개선, 복수 에이전트의 협조를 패턴으로서 배우는 관점은 Ng의 방식이 더 이해하기 쉽습니다.

특히 Planning (계획)과 Multi-agent collaboration (멀티 에이전트 협업)은 막연하게 만들면 금방 복잡해집니다. 어디까지 분해할지, 어떤 에이전트에게 무엇을 맡길지, 누가 최종 판단을 내릴지를 설계하지 않으면, 그저 느리고 디버깅하기 어려운 시스템이 됩니다.

Anthropic의 Building Effective Agents는 이 점이 상당히 현실적입니다.

처음부터 복잡한 에이전트 프레임워크를 사용하는 것이 아니라, 단순한 구성부터 시작합니다. 필요에 따라 Prompt Chaining (프롬프트 체이닝), Routing (라우팅), Parallelization (병렬화), Orchestrator-Worker (오케스트레이터-워커), Evaluator-Optimizer (평가자-최적화 도구)와 같은 워크플로우를 사용합니다. 그러다 더 필요해졌을 때 비로소 자율적인 에이전트로 나아갑니다.

단순한 워크플로우로 해결될 수 있다면, 에이전트로 만들지 않는 것이 더 안정적입니다. AI 에이전트를 만드는 기술에는 '만들지 않는 판단'도 포함되어 있습니다.

Karpathy의 Software 3.0 이야기 중 저에게 가장 와닿았던 점은, 에이전트를 '모든 것을 자동으로 수행하는 것'으로 보지 않는 것입니다.

현시점의 LLM은 상당히 강력하지만, 항상 신뢰할 수 있는 것은 아닙니다. 따라서 사용자가 확인하기 쉽고, 필요에 따라 통제권을 짧게 가져갈 수 있는 설계가 필요합니다. Karpathy는 이를 autonomy slider (자율성 슬라이더)라고 표현합니다.

이는 IBM의 제품 사고(Product thinking)나 OpenAI의 인간 에스컬레이션 (Escalation) 설계와도 연결됩니다.

IBM의 7가지 요소에 대해, 다른 정보원들이 어느 부분을 보완하는지 짧게 정리합니다.

Karpathy: Software 3.0, 부분적 자율성, autonomy slider. 완전 자율이 아니라 인간이 확인하기 쉬운 설계를 중시함 -
Andrew Ng: Reflection (성찰), Tool use (도구 사용), Planning (계획), Multi-agent collaboration (멀티 에이전트 협업). 에이전트 설계를 공통 어휘로 이야기할 수 있게 함 -
Anthropic: 우선 단순하게 만들기. 복잡한 프레임워크나 자율 에이전트로 즉시 뛰어들지 않음 -
OpenAI: 에이전트 분할과 가드레일 (Guardrails). 안전성 체크, 인간으로의 에스컬레이션, 출력 검증을 설계에 포함함 -
Google: models, tools, orchestration, memory, evaluation. Logs, Traces, Metrics, LLM-as-a-Judge, Human-in-the-Loop를 구체화함 -
Chip Huyen: AI Engineering 전체의 지도. 데이터셋, 파인튜닝 (Fine-tuning), 추론 최적화, 평가 설계까지 폭넓게 다룸

정보원마다 강조점은 다르지만, 겹쳐보면 대체로 같은 지점으로 모입니다.

우선 아키텍처, 도구 설계, 평가입니다. IBM, OpenAI, Anthropic, Google, Ng, Huyen 중 누구의 관점을 보더라도 이 세 가지는 형태를 바꾸어 등장합니다.

특히 가장 강력하게 겹치는 부분은 평가입니다. 데모와 실전의 차이는 모델의 똑똑함만으로는 메울 수 없습니다. 어떤 케이스에서 성공하고, 어떤 케이스에서 실패하며, 왜 실패했는지를 가시화할 수 있어야 합니다.

앞으로 AI 에이전트를 만든다면, 모든 것을 한꺼번에 배우기보다 다음 순서를 따르는 것이 좋아 보입니다.

먼저 입력, 출력, 도구 호출(Tool call), 실패 이유를 기록하십시오. 작은 프로토타입이라도 성공 사례와 실패 사례를 남겨두어야 합니다. 이것이 없으면 나중에 개선할 수 없습니다.

다음으로 도구의 입출력을 명확히 하십시오. 에이전트가 사용하는 도구는 설명문, 스키마 (Schema), 에러, 권한이 사양(Specification)입니다. 이 부분이 모호하면 모델의 성능 이전에 사고가 발생합니다.

처음부터 복잡한 멀티 에이전트로 만들지 마십시오. Prompt Chaining이나 Routing으로 해결된다면 그것으로 충분합니다. 반드시 필요한 경우에만 Orchestrator-Worker나 자율 에이전트로 나아가십시오.

정보 검색이 중요하다면 RAG를 깊게 파십시오. 지속적인 이용이 중요하다면 memory와 context engineering (컨텍스트 엔지니어링)을 고민하십시오. 복잡한 태스크 분해가 필요하다면 planning이나 multi-agent collaboration을 배우십시오.

IBM의 7가지 기술은 AI 에이전트 구축을 위한 좋은 출발점입니다.

특히 시스템 설계, 도구 설계, 신뢰성, 보안, 평가, 제품 사고까지 포함하고 있으므로, '프롬프트를 쓸 줄 아는 것'과 '에이전트를 만들 줄 아는 것'은 다르다는 점을 잘 보여줍니다.

다만, IBM의 지표만으로는 메모리 및 컨텍스트 관리 (Memory and Context Management), 플래닝 및 멀티 에이전트 (Planning and Multi-agent), 애초에 만들어야 하는지에 대한 판단, 자율성 (Autonomy)과 인간의 개입 (Human Involvement)과 같은 관점이 다소 부족합니다.

결론적으로, AI 에이전트 구축 기술이란 완전히 신뢰할 수 없는 부품들을 관측 가능하고 (Observable), 제어 가능하며 (Controllable), 인간이 필요한 시점에 판단할 수 있는 시스템으로 변환하는 능력이라고 생각합니다.

아직 저 스스로도 정리 중이지만, 적어도 "평가 (Evaluation)와 관측 가능성 (Observability)을 뒤로 미루지 않는다"는 점은 상당히 확실한 배움으로 남았습니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0