이 글은 "AI agents"에 대한 정의를 명확히 하고 시작한 점이 특히 인상적이라는 의견임. 여기서 사용하는 정의는 "LLM이 자체적으로 프로세스와 툴 사용을 동적으로 관리하며, 작업 수행 방식을 스스로 통제하는 시스템"임. ‘agent’와 ‘workflow’를 구분하는 부분과 여러 실용적인 워크플로우 패턴을 소개한 방식도 마음에 든다는 입장임. 글이 처음 나왔을 때 직접 작성한 정리 글도 있음 building-effective-agents 노트. 그리고 최근 Anthropic의 multi-agent 연구 시스템 구축기도 흥미로웠고, 여기에 관한 추가 노트도 있음 multi-agent research system 노트
이 글에서 말하는 workflow 정의가 정확하지 않다는 생각임. 요즘 워크플로우 엔진들은 미리 정해진 코드 경로를 따르지 않고 에이전트와 사실상 동일하게 동작하는 경우가 많음. 저자가 워크플로우를 새롭게 정의한 건 구분하려는 의도로 보이지만, 실제로는 agent란 것도 단순히 LLM 응답에 따라 동적으로 호출하는 루프 형태의 워크플로우라는 의견임. 최신 워크플로우 엔진도 매우 동적이라는 주장임
Building Effective Agents의 공동 저자 한 명이 AIE에서 해당 글을 주제로 강연도 진행했는데, 반응이 매우 좋았다는 경험 공유임 유튜브 영상
multi-agent 연구에 대한 글이 정말 좋은데, Building Effective AI Agents 글에서 "프레임워크 없이 처음부터 시스템을 구축하는 것이 교육적 관점에서는 좋다"는 주장에는 동의하지 않는다는 의견임. 좋은 프레임워크를 쓰면 다양한(그리고 공급업체를 가리지 않는) LLM을 손쉽게 실험할 수 있다는 점이 첫 번째 이점이라는 주장임
Anthropic이 어떤 AI agent framework를 사용하는지 궁금하다는 질문임. 자체 프레임워크를 공개한 적이 없는 것 같다는 의견임
추가 노트가 고맙고, 이 주제가 최근 본인에게도 매우 중요한 이슈라는 반응임
AI 분야에서는 반 년이 아주 길게 느껴지는 체감임. 몇 달 전 이 글을 반복해서 읽었는데, 이제 에이전트 개발이 분명히 병목에 다다른 느낌임. 최신 Gemini조차도 오히려 성능이 퇴보한 것 같다는 의견임
여러 에이전트를 동시에 돌리는 게 비용이 많이 들어 RoI를 낮추는 요인임. 예를 들어, 주식용 DeepSearch agent는 6개 agent를 사용하는데 쿼리마다 약 2달러 비용 소모임. 멀티에이전트 오케스트레이션이 컨트롤하기 어렵고, 모델이 더 강력하면 멀티에이전트 필요성이 줄어듦. 반대로 약한 모델일수록 특화된 좁은 AI의 비즈니스 가치가 더 올라간다는 실제 경험 공유임
에이전트가 퇴보했다고 느껴지는 이유가 궁금하다는 질문임. 왜 그냥 스스로 분신을 여러 개 만들어서 24/7로 병렬로 계속 일하고 검증하며 발전 시키지 못하는지에 대한 궁금증임
프롬프트 인젝션 문제를 해결하는 게 아주 어려워서 이 부분이 심각한 병목이 되고 있다는 의견임
에이전트가 어떻게 task queueing, race condition, 그 외 동시성 문제를 다루는지 궁금함. 멀티 에이전트 워크플로우 구축 관련 기사에서는 orchestrator agent가 전체를 관리한다는 내용이 많은데, 실질적으로는 더 복잡한 설계와 똑똑한 glue code가 필요한지 항상 궁금함. 아니면 이 모든 게 진짜로 “자동 마법”처럼 작동하는지에 대한 의문임
에이전트의 표준은 도구들이 순차적으로 실행된다는 것이라서 동시성 문제를 걱정하지 않아도 된다는 설명임. 이제는 여러 모델이 병렬 툴 호출을 지원하고 있어서, 모델이 “이 세 가지 툴을 실행”이라고 요청하면 harness가 병렬 혹은 순차로 실행 후 결과를 다음 스텝에 전달하는 방식을 사용함. Anthropic은 멀티에이전트 설정을 더 적극적으로 활용하고 있는데, 상위 에이전트가 하위 에이전트들에게 병렬로 작업을 위임하는 구조임. 이 트릭은 Claude Code에 적용되고 있고, 관련 역공학 노트(claude-trace) 및 Claude Research 작동 방식에 대한 글(multi-agent-research-system)에서도 확장 설명함. LLM 툴 사용 패턴을 발견하는 단계는 아직 매우 초기이며, 모델이 툴 사용을 정말 잘하게 된 것도 최근 6개월 사이의 일이라 앞으로 발전 가능성이 큼
그래서 모든 걸 JSON으로 다루기보다는 LLM이 직접 code를 만들어서 tool call을 다루는 방향을 선호하게 됨. Huggingface의 smolagents 라이브러리는 LLM이 python 함수 호출 코드를 생성하는 방식을 사용함. 병렬 툴 호출을 원하면 프롬프트에서 명시하면 되고, LLM이 동기화도 처리해야 함. 물론 LLM이 만든 코드를 실행하는 이슈는 있지만 여러 해결책이 존재함
Codex 웹 인터페이스 사용 사례 공유임. 한 번에 끝내기엔 너무 긴 리팩토링 플랜이 있었고, “ask” 기능을 통해 여러 작업으로 분리하고 병렬로 가능한 작업을 그룹화함. LLM은 실제 팀이 분담하는 방식과 유사하게 분할했지만, 작업 간 커뮤니케이션 전제가 없다 보니 컨텍스트 소실이 매우 큼. 직접 하는 것보다 더 오래 걸려도 시도는 했지만, 여러 개의 세션에 각 작업마다 상세한 프롬프트(목적, 방법, 검증, 문서화 등)를 주는 방식으로 순차 처리함. 요약하자면 orchestrator agent는 아주 간단한 작업에는 쓸 수 있지만, 생각보다 적용 범위가 한정적이라는 실제 경험 공유임
마법처럼 자동으로 작동하는 것은 아무것도 없다는 입장임. 기존 시스템에서 신경 써야 하는 운영 특성을 AI 에이전트에도 반드시 개발해야함. AI agent 데모만 보고 “스파게티 코드 팀의 코드를 깔끔한 AI 프롬프트 몇 개로 대체”할 수 있다고 생각하면 속을 수 있음. 실제로 소수 케이스에서는 동작할 수 있지만, 결국은 모든 코드가 시스템에서 필요한 이유가 있고, 아예 그 코드를 LLM에 다 번역해 넣는 수준이 되면 방향성을 잃은 것이라는 경고임
코딩 에이전트의 경우 emerging pattern으로 컨테이너를 활용해 작업을 격리하고, git으로 작업물을 리뷰 및 머지하는 방식이 정립 중임. 예시로는 컨테이너, MCP 활용 사례(container-use)가 있으며, 병렬 코드 작업에 유용함. 그 외 업무에서는 n8n, Zapier, CrewAI 같은 워크플로우 빌더도 여전히 자주 사용함
이 글은 “가장 단순한 것”부터 시작하고 진짜 복잡성이 필요할 때만 추가하라는 메시지를 상기시켜줌. 명확하게 정의된 LLM 호출과 약간의 심플한 glue logic만으로 더 안정적이고, 디버깅도 쉽고, 비용도 저렴한 시스템 구축 가능성 언급함. 반대로 화려하게 보이는 에이전트 시스템은 오히려 문제를 더 많이 야기하는 경우가 많음
AI가 사람들에게 실질적으로 도움을 주는 존재가 되길 바라는 희망 표현임
Anthropic이 이런 기술 정보를 제공하는 것도 좋지만, 비전문가를 위한 쉬운 가이드 버전도 제공해야 한다는 생각임. 예를 들면 마케팅 부서에서 에이전트를 도입하고 싶어도, 기초 수준에서 사양을 정의할 수 있는 가이드가 필요함. 글의 마지막 부분과 부록에서 관련 내용이 있긴 하지만, 여전히 “어떻게 구축할 것인가”는 구현 측면에 머무르고 있다는 지적임
(2024년 12월 - 지금 생각하면 한참 전처럼 느껴지는 시점이라는 소회임)
아아아 이제 다시 머리 써서 2024년 12월에 원시인처럼 100퍼센트 코드를 직접 짜야 하는 상황으로 돌아간다는 농담형 반응임 관련 댓글
이 글이 아주 잘 버티고 있다는 의견임. 개인적으로 계속 참고자료로 쓰고 있으며, 시간이 지나도 구식이라는 느낌이 없음. Anthropic이 "실질적인 AI 도구 개발 파트너"로서 새로운 인상을 준 글이었다는 평가임
Hacker News 의견
이 글은 "AI agents"에 대한 정의를 명확히 하고 시작한 점이 특히 인상적이라는 의견임. 여기서 사용하는 정의는 "LLM이 자체적으로 프로세스와 툴 사용을 동적으로 관리하며, 작업 수행 방식을 스스로 통제하는 시스템"임. ‘agent’와 ‘workflow’를 구분하는 부분과 여러 실용적인 워크플로우 패턴을 소개한 방식도 마음에 든다는 입장임. 글이 처음 나왔을 때 직접 작성한 정리 글도 있음 building-effective-agents 노트. 그리고 최근 Anthropic의 multi-agent 연구 시스템 구축기도 흥미로웠고, 여기에 관한 추가 노트도 있음 multi-agent research system 노트
이 글에서 말하는 workflow 정의가 정확하지 않다는 생각임. 요즘 워크플로우 엔진들은 미리 정해진 코드 경로를 따르지 않고 에이전트와 사실상 동일하게 동작하는 경우가 많음. 저자가 워크플로우를 새롭게 정의한 건 구분하려는 의도로 보이지만, 실제로는 agent란 것도 단순히 LLM 응답에 따라 동적으로 호출하는 루프 형태의 워크플로우라는 의견임. 최신 워크플로우 엔진도 매우 동적이라는 주장임
Building Effective Agents의 공동 저자 한 명이 AIE에서 해당 글을 주제로 강연도 진행했는데, 반응이 매우 좋았다는 경험 공유임 유튜브 영상
multi-agent 연구에 대한 글이 정말 좋은데, Building Effective AI Agents 글에서 "프레임워크 없이 처음부터 시스템을 구축하는 것이 교육적 관점에서는 좋다"는 주장에는 동의하지 않는다는 의견임. 좋은 프레임워크를 쓰면 다양한(그리고 공급업체를 가리지 않는) LLM을 손쉽게 실험할 수 있다는 점이 첫 번째 이점이라는 주장임
Anthropic이 어떤 AI agent framework를 사용하는지 궁금하다는 질문임. 자체 프레임워크를 공개한 적이 없는 것 같다는 의견임
추가 노트가 고맙고, 이 주제가 최근 본인에게도 매우 중요한 이슈라는 반응임
AI 분야에서는 반 년이 아주 길게 느껴지는 체감임. 몇 달 전 이 글을 반복해서 읽었는데, 이제 에이전트 개발이 분명히 병목에 다다른 느낌임. 최신 Gemini조차도 오히려 성능이 퇴보한 것 같다는 의견임
여러 에이전트를 동시에 돌리는 게 비용이 많이 들어 RoI를 낮추는 요인임. 예를 들어, 주식용 DeepSearch agent는 6개 agent를 사용하는데 쿼리마다 약 2달러 비용 소모임. 멀티에이전트 오케스트레이션이 컨트롤하기 어렵고, 모델이 더 강력하면 멀티에이전트 필요성이 줄어듦. 반대로 약한 모델일수록 특화된 좁은 AI의 비즈니스 가치가 더 올라간다는 실제 경험 공유임
에이전트가 퇴보했다고 느껴지는 이유가 궁금하다는 질문임. 왜 그냥 스스로 분신을 여러 개 만들어서 24/7로 병렬로 계속 일하고 검증하며 발전 시키지 못하는지에 대한 궁금증임
프롬프트 인젝션 문제를 해결하는 게 아주 어려워서 이 부분이 심각한 병목이 되고 있다는 의견임
에이전트가 어떻게 task queueing, race condition, 그 외 동시성 문제를 다루는지 궁금함. 멀티 에이전트 워크플로우 구축 관련 기사에서는 orchestrator agent가 전체를 관리한다는 내용이 많은데, 실질적으로는 더 복잡한 설계와 똑똑한 glue code가 필요한지 항상 궁금함. 아니면 이 모든 게 진짜로 “자동 마법”처럼 작동하는지에 대한 의문임
에이전트의 표준은 도구들이 순차적으로 실행된다는 것이라서 동시성 문제를 걱정하지 않아도 된다는 설명임. 이제는 여러 모델이 병렬 툴 호출을 지원하고 있어서, 모델이 “이 세 가지 툴을 실행”이라고 요청하면 harness가 병렬 혹은 순차로 실행 후 결과를 다음 스텝에 전달하는 방식을 사용함. Anthropic은 멀티에이전트 설정을 더 적극적으로 활용하고 있는데, 상위 에이전트가 하위 에이전트들에게 병렬로 작업을 위임하는 구조임. 이 트릭은 Claude Code에 적용되고 있고, 관련 역공학 노트(claude-trace) 및 Claude Research 작동 방식에 대한 글(multi-agent-research-system)에서도 확장 설명함. LLM 툴 사용 패턴을 발견하는 단계는 아직 매우 초기이며, 모델이 툴 사용을 정말 잘하게 된 것도 최근 6개월 사이의 일이라 앞으로 발전 가능성이 큼
그래서 모든 걸 JSON으로 다루기보다는 LLM이 직접 code를 만들어서 tool call을 다루는 방향을 선호하게 됨. Huggingface의 smolagents 라이브러리는 LLM이 python 함수 호출 코드를 생성하는 방식을 사용함. 병렬 툴 호출을 원하면 프롬프트에서 명시하면 되고, LLM이 동기화도 처리해야 함. 물론 LLM이 만든 코드를 실행하는 이슈는 있지만 여러 해결책이 존재함
Codex 웹 인터페이스 사용 사례 공유임. 한 번에 끝내기엔 너무 긴 리팩토링 플랜이 있었고, “ask” 기능을 통해 여러 작업으로 분리하고 병렬로 가능한 작업을 그룹화함. LLM은 실제 팀이 분담하는 방식과 유사하게 분할했지만, 작업 간 커뮤니케이션 전제가 없다 보니 컨텍스트 소실이 매우 큼. 직접 하는 것보다 더 오래 걸려도 시도는 했지만, 여러 개의 세션에 각 작업마다 상세한 프롬프트(목적, 방법, 검증, 문서화 등)를 주는 방식으로 순차 처리함. 요약하자면 orchestrator agent는 아주 간단한 작업에는 쓸 수 있지만, 생각보다 적용 범위가 한정적이라는 실제 경험 공유임
마법처럼 자동으로 작동하는 것은 아무것도 없다는 입장임. 기존 시스템에서 신경 써야 하는 운영 특성을 AI 에이전트에도 반드시 개발해야함. AI agent 데모만 보고 “스파게티 코드 팀의 코드를 깔끔한 AI 프롬프트 몇 개로 대체”할 수 있다고 생각하면 속을 수 있음. 실제로 소수 케이스에서는 동작할 수 있지만, 결국은 모든 코드가 시스템에서 필요한 이유가 있고, 아예 그 코드를 LLM에 다 번역해 넣는 수준이 되면 방향성을 잃은 것이라는 경고임
코딩 에이전트의 경우 emerging pattern으로 컨테이너를 활용해 작업을 격리하고, git으로 작업물을 리뷰 및 머지하는 방식이 정립 중임. 예시로는 컨테이너, MCP 활용 사례(container-use)가 있으며, 병렬 코드 작업에 유용함. 그 외 업무에서는 n8n, Zapier, CrewAI 같은 워크플로우 빌더도 여전히 자주 사용함
이 글은 “가장 단순한 것”부터 시작하고 진짜 복잡성이 필요할 때만 추가하라는 메시지를 상기시켜줌. 명확하게 정의된 LLM 호출과 약간의 심플한 glue logic만으로 더 안정적이고, 디버깅도 쉽고, 비용도 저렴한 시스템 구축 가능성 언급함. 반대로 화려하게 보이는 에이전트 시스템은 오히려 문제를 더 많이 야기하는 경우가 많음
AI가 사람들에게 실질적으로 도움을 주는 존재가 되길 바라는 희망 표현임
Anthropic이 이런 기술 정보를 제공하는 것도 좋지만, 비전문가를 위한 쉬운 가이드 버전도 제공해야 한다는 생각임. 예를 들면 마케팅 부서에서 에이전트를 도입하고 싶어도, 기초 수준에서 사양을 정의할 수 있는 가이드가 필요함. 글의 마지막 부분과 부록에서 관련 내용이 있긴 하지만, 여전히 “어떻게 구축할 것인가”는 구현 측면에 머무르고 있다는 지적임
(2024년 12월 - 지금 생각하면 한참 전처럼 느껴지는 시점이라는 소회임)
이 글이 아주 잘 버티고 있다는 의견임. 개인적으로 계속 참고자료로 쓰고 있으며, 시간이 지나도 구식이라는 느낌이 없음. Anthropic이 "실질적인 AI 도구 개발 파트너"로서 새로운 인상을 준 글이었다는 평가임
Agent에 대한 과대광풍(hype)이 지금은 많이 가라앉았다는 견해임
글이 당시에도 토론되었던 이력이 있다는 정보 공유임 원문 HN 토론
이 글이 과장이나 유행을 따르지 않고 현실적으로 접근한 점이 마음에 든다는 의견임. 많은 사람들이 유행 따라 agent 시스템을 만들다가, 실제로 그 작업에 진짜 agent가 필요한지 고민 없이 진행하는 경향에 대해 비판적임