AI 에이전트와 관련하여 우리가 어디에 있는지에 대한 무작위적인 불평:
일부에서는 이를 에이전트라고 부르지 않지만, 결정적 흐름을 갖춘 "워크플로 에이전트"는 어디에나 있으며 작동합니다. 누구나 Zapier 및 n8n과 같은 코드가 필요 없는 도구로 시작하더라도 간단한 워크플로 에이전트를 만들 수 있습니다. 복잡한 워크플로 에이전트를 안정적이고 효율적으로 구축하려면 훨씬 더 많은 고려가 필요합니다. 관련 통합이 내장된 일반적이고 가치 있는 사용 사례에 대한 복잡한 워크플로는 비즈니스로서 독립적으로 운영될 수 있으며, 나중에 다른 워크플로 또는 보다 자율적인 작업으로 확장할 수 있는 훌륭한 GTM이 될 수도 있습니다.
더욱 역동적이고 자율적인 에이전트들이 작동하기 시작했으며, 연구(특히 웹 기반인 경우)와 코딩에 도움이 됩니다. 하지만 데이터 소스(예: API)를 더 많이 추가하기 시작하면 안정성이 떨어집니다. 읽기 전용 에이전트는 안전하고 테스트하기 쉽지만, 자율 에이전트가 직접 작업(쓰기)을 하도록 하는 것은 위험합니다. (이에 대한 엉뚱한 생각: CRM과 같은 도구를 사용하여 개발 미러를 "포크"하고 자동화 실험을 실행한 후 롤백하거나 병합할 수 있다면 좋을 것 같습니다.)
동적 에이전트는 (1) 좋은 계획을 만들고 추적하고 (2) 작업을 올바르게 실행하면서 (3) 각 단계(계획 및 각 작업 모두)에 적용할 적절한 맥락을 찾을 수 있을 때 효과적으로 작동합니다. 마지막으로, (4) 계획을 적절하게 조정하고 실패하거나 성과가 좋지 않은 작업을 실행하는 방식을 개선할 수 있도록 진행 과정을 (인간의 입력 여부와 관계없이) 반영해야 합니다.
업무 계획: LLM의 추론 능력 개인적인 맥락이 필요 없는 간단한 작업 목록(심층적인 조사, 요약을 위한 일련의 웹 검색 등)에는 적합합니다. 많은 엔티티를 조사해야 하는 경우, 작업 목록 관리가 비교적 기본적이기 때문에 심층적인 조사는 효과적이지 않습니다. 스프레드시트 기반 AI 도구는 여러 엔티티를 조사하는 데 더 적합합니다. 작업 관리를 스프레드시트로 효과적으로 이전할 수 있기 때문입니다. 프롬프트 간에 긴 작업 목록을 전달하는 것은 여기서는 효과가 없습니다. 코딩 에이전트의 작업 관리는 간단한 문제, 간단한 코드 또는 처음부터 시작하는 경우에 효과적입니다. 더 복잡한 기존 프로젝트를 진행하면 신뢰성이 떨어지며, 개발자는 코드의 작동 방식과 구성 방식(.md 파일)을 문서화하여 에이전트가 더 정보에 기반한 작업 목록을 작성할 수 있도록 함으로써 신뢰성을 높입니다. 복잡한 코드는 더 많은 문서가 필요하며, 결국 해당 문서에서 관련 맥락만 동적으로 가져와야 합니다. 많은 사람/기업이 프로젝트를 처리하는 올바른 순서/접근 방식/도구에 대해 문서화되지 않은 강력한 의견을 가지고 있으며, 이를 사전에 그리고 즉석에서 문서화하는 더 많은 접근 방식이 필요합니다. 코딩과 웹 기반 연구 에이전트가 효과적인 또 다른 이유는 모두 동일한 도구 세트를 사용하기 때문에 해당 도구의 사용법을 "배우는" 데가 필요하지 않기 때문입니다(다음에 자세히 설명하겠습니다).
작업 실행: 작업은 일반적으로 API 호출(API 사용 방법 및 기본 데이터 구조에 대한 인증 및 이해가 필요함 - 이는 CRM이나 DB처럼 사용자 정의 테이블/열이 있는 고유한 것일 수 있음), LLM 추론(예: 요약), 조합, 심지어 워크플로 에이전트*입니다. 연구 에이전트는 실제로 루프 내의 웹 검색 및 요약일 뿐입니다. 코딩 에이전트는 코드 기반의 CRUD이며 학습 API를 위한 웹 검색일 수 있습니다. 인증 및 기본 API 액세스는 해결된 것 같지만(MCP가 여기에 적합함), 도구별 컨텍스트(사용자에게 질문하지만 초기 연결 시 분석하고 기존 데이터를 파헤쳐 도구 사용 방법, 데이터 구조, 도구를 사용하는 시나리오/프로젝트를 이해함)에 대한 내용이 더 많았으면 좋겠습니다. 오류/반성/피드백은 관련성이 있을 때 컨텍스트로 피드백되는 체계적인 학습으로 전환되어야 합니다. 동일한 도구가 조직 간에 다른 목적과 방식으로 사용될 수 있으며 작업을 잘 실행하기 위해 이를 어떻게든 포착/문서화해야 합니다.
문맥: 회사의 신입사원이라고 상상해 보세요. 온보딩 과정에서 많은 것을 배우게 되고(온보딩이 잘될수록 처음부터 더 효과적일 수 있습니다), 직장에서 배우는 것도 있는데, 조직의 경험에서 배우는 것("우리는 이렇게 합니다")과 자신의 경험에서 배우는 것으로 나뉩니다. 전자는 대규모 조직에서 더 흔합니다. 문맥 관리도 비슷합니다. 메타(사용자/회사), 프로젝트/부서별, 작업별, 도구별 등과 같은 여러 계층의 문맥이 있습니다. 간단한 시스템 프롬프트에서 하이브리드 RAG 전략(벡터, 키워드, 그래프)으로 발전했지만, 데이터/문맥을 갖는 것 외에도 문맥을 언제 어떻게 검색할지에 대한 지침이 필요합니다. 오늘날 초기 버전에서 볼 수 있지만 개선의 여지가 많습니다. 이는 단순히 기술적인 문제가 아니라 비즈니스 문제이기도 합니다. 기본적으로 예상되는 모든 시나리오를 다루는 온보딩 문서를 작성해야 하기 때문입니다. 프로젝트가 복잡해질수록 관련 정보만 프롬프트에 포함되도록 문맥을 올바르게 정리하고 관련 없는 문맥을 최소화하기 위해 더 많은 주의가 필요합니다.
반성: LLM/API 비용과 관찰을 포괄하는 에이전트 모니터링 도구가 있지만, 성공/실패를 할당하는 것이 과제입니다. 코딩 에이전트가 다른 에이전트보다 우위를 점하는 한 가지 영역은 코드 테스트를 통해 실패를 감지하는 결정론적 방법입니다. 다른 많은 에이전트 작업의 경우, 향후 출력을 개선하기 위해 인간의 입력을 수집하는 올바른 방법을 아직 알아내고 있습니다. 제가 아는 한, 오늘날의 반성은 인간 참여형(human-in-the-loop) 방식입니다. 피드백은 주로 에이전트를 개선하기 위해 인간 개발자에게 제공되지만, 진정한 의미는 반성을 자기 개선으로 전환하는 방법을 알아낼 때입니다. 즉, 에이전트가 작업 목록 생성 및 작업 실행의 실패에서 얻은 통찰력을 바탕으로 다음 번에 더 나은 결과를 낼 수 있도록 하는 것입니다. 기본적으로 반성은 필요할 때만 프롬프트로 가져올 수 있는 잘 구성된 맥락으로 전환되어야 합니다. 이는 에이전트의 미세 조정, 그리고 에이전트적 강화 학습 환경으로 발전하게 되는데, 아직은 초기 단계인 것 같습니다.
*앞서 워크플로 에이전트에게 작업을 인계하는 것에 대해 언급했는데, 에이전트가 도구로 워크플로 에이전트를 사용하지 않아도 되는 경우(매번 알려진 작업 목록을 알아내는 것과 대조적으로) 또는 시스템이 복잡해서 전문화된 컨텍스트와 도구를 갖춘 전문화된 에이전트가 더 나은 성능을 보이는 경우(또는 다른 사람이 만든 에이전트를 활용하는 경우)에 이 방법이 합리적입니다(제가 여기서 보기 시작한 패턴 중 하나는 에이전트 협업을 더 쉽게 하기 위한 자연어 API 엔드포인트입니다).
오늘날의 모델 품질에 무한한 콘텐츠 창(품질 저하 없음), 무한한 컴퓨팅, 무한한 저장소, 브라우저 액세스 및 지불 방법이 있다면 단일 LLM 루프만으로도 많은 작업을 완료하기에 충분할 것입니다. 위의 무의미한 요점(무한한 것은 없다)의 요점은 에이전트 오케스트레이션이 주로 구조와 코드를 통해 LLM의 작업을 오프로드하는 방법을 설계하여 제한을 관리하는 것이라는 것입니다.
실제 운영 환경에서 사용되는 에이전트는 내부 도구, 다양한 도구를 결합한 독립형 제품, 핵심 도구에 내장된 기능 등 다양한 형태로 제공됩니다. 에이전트는 일반적이거나 특수할 수 있습니다. 채팅, 음성 및 백그라운드 에이전트가 에이전트 흐름을 트리거하는 데 가장 일반적인 UI 인터페이스인 것으로 보입니다.
내가 놓친 다른 게 뭐야?