AI 에이전트를 '도입'하는 것과 '설계'하는 것은 다른 문제다. 많은 팀이 에이전트 도구를 붙이고 프롬프트를 조금 다듬는 선에서 멈추지만, 실제로 에이전트가 워크플로우 안에서 예측 가능하게 작동하려면 세 가지 레이어를 동시에 설계해야 한다. 캔버스(어떻게 연결할 것인가), 프롬프트(어떻게 지시할 것인가), 자율성 수준(얼마나 스스로 결정하게 할 것인가)—이 세 축이 맞물리지 않으면 에이전트는 빠른 자동화 도구가 아니라 예측 불가능한 블랙박스가 된다.
레이어 1 — 캔버스: 에이전트 흐름을 시각적으로 연결하기
dev.to에 공개된 agent-flow-canvas는 브라우저 기반의 시각적 에이전트 워크플로우 빌더다. Trigger, LLM, Router, Memory, Subagent 등 8개의 노드를 드래그로 연결하고 실행하면 그래프가 브라우저 탭 안에서 라이브로 돌아간다. 설치도, 로그인도, 서버 백엔드도 없다. API 키는 localStorage에만 머물고 OpenAI, Anthropic, Gemini 등 엔드포인트로 직접 요청이 나간다. '당신이 키를 가져오면, 브라우저가 일을 한다'는 설계 철학이 일관되게 관통한다.
이 도구가 흥미로운 건 기술 스펙보다 그 제작 과정이다. 저자는 빌더를 개발하면서 메인 에이전트와 테스팅 에이전트를 병렬로 운용했고, 두 에이전트는 test_result.md라는 공유 파일로 커뮤니케이션했다. 태스크명, 수정된 파일, 우선순위, 성공 여부, 그리고 status_history—누가 언제 무엇을 믿었고 왜 그 판단을 내렸는지를 쌓아가는 타임스탬프 로그. 특히 stuck_count 필드는 같은 문제가 반복적으로 해결됐다가 다시 깨질 때마다 올라가는 카운터다. 이건 상태 플래그가 아니라, 시스템이 제자리를 맴돌고 있다는 고백이다.
프론트엔드 개발자 입장에서 이 구조가 중요한 이유는 단순하다. 에이전트 워크플로우를 캔버스로 시각화한다는 것은 단순히 노드를 이어붙이는 UI 문제가 아니다. 어떤 에이전트가 어떤 책임을 가지고, 서로 어떤 프로토콜로 소통하며, 실패했을 때 누가 그것을 감지하는가—이 구조 설계가 캔버스 레이어에 녹아있어야 한다. 시각적 빌더는 그 설계를 낮은 진입 비용으로 프로토타이핑하는 도구다.
레이어 2 — 프롬프트: 에이전트에게 일을 맡기는 방식
캔버스가 구조를 잡았다면, 각 LLM 노드 안에서 실제로 에이전트가 무엇을 어떻게 하는지는 프롬프트 설계에 달려있다. dev.to의 'Claude 프롬프트 엔지니어링' 가이드는 여기서 직접적으로 적용 가능한 여섯 가지 기법을 제시한다.
핵심은 하나다. 에이전트에게 일을 시킬 때 '완료'의 기준을 명시하지 않으면, 에이전트는 보수적으로 추측한다. "이메일 검증 함수를 작성해"가 아니라 "RFC 5322 호환, TLD 없는 주소 거부, 외부 의존성 없음, 유효/무효/엣지케이스 3개 단위 테스트 포함"이라고 써야 실제 제약 조건에 맞는 결과가 나온다. 마찬가지로, 코드와 지시를 섞어서 던지면 긴 파일에서 맥락이 흐려진다. <file path="auth/session.ts"> 같은 XML 태그로 명시적으로 구분하는 것이 멀티파일 컨텍스트에서 특히 효과적이다.
에이전트 워크플로우에서 더 중요한 기법은 태스크 체이닝이다. 하나의 거대한 프롬프트로 전체 기능 구현을 요청하는 것보다, 설계→구현→리뷰→수정으로 단계를 쪼개면 각 단계를 독립적으로 검증할 수 있다. 에이전트가 잘못된 전제를 가지고 200줄의 코드를 만들어내기 전에, 설계 단계에서 "캐시 전략을 먼저 설명해, 그 다음에 구현해"라는 요청이 그 오류를 잡아낸다. 긴 세션에서는 컨텍스트 관리도 설계 대상이다. Claude Code 기준으로, 무관한 태스크 사이에 /clear를 치는 것은 귀찮음이 아니라 세션 품질을 유지하는 습관이다.
레이어 3 — 자율성 수준: 에이전트에게 얼마나 결정권을 줄 것인가
세 번째 레이어가 가장 과소평가된다. 캔버스를 그리고 프롬프트를 다듬었다면, 이제 진짜 질문이 남는다. 이 에이전트는 얼마나 스스로 결정해야 하는가?
dev.to의 'Agentic AI Explained' 분석은 자율성을 0에서 5까지 6단계 스펙트럼으로 정리한다. 레벨 0은 고정 규칙 기반 시스템, 레벨 1은 경로는 코드가 고정하되 모델이 특정 작업(분류, 요약, 추출)을 처리하는 구조, 레벨 2는 사전 검토된 선택지 중 모델이 분기를 결정, 레벨 3은 하드 제약 안에서 모델이 직접 단계를 계획하고 도구를 순서 결정, 레벨 4는 감독 없는 실질적 자율성, 레벨 5는 목표 자체를 스스로 설정하는 오픈엔디드 자율성이다.
중요한 건 분석이 내리는 결론이다. 2026년 현재 실제 프로덕션에서 작동하는 대부분의 에이전트는 레벨 1, 2, 3에 있다. 그런데 마케팅은 레벨 4의 언어로 판매된다. Gartner는 수천 개의 '에이전틱 AI' 벤더 중 130개만이 그 이름에 걸맞다고 평가했고, 이를 '에이전트 워싱'이라 불렀다. MIT 연구에서 95%의 생성형 AI 파일럿이 손익에 측정 가능한 기여를 하지 못한 이유도 같다. 기술 실패가 아니라, 구매한 자율성 수준과 프로세스가 실제로 흡수할 수 있는 자율성 수준의 불일치였다.
실용적인 프레임으로 바꾸면 이렇다. 에이전트가 어떤 행동을 했을 때, 그것이 되돌릴 수 없는 결과를 만드는가? 만든다면, 그 행동 전에 사람이 개입하는 게이트가 설계되어 있어야 한다. Anthropic 자신이 가이드에서 "가장 단순한 해결책을 먼저 찾고, 결과가 실질적으로 개선될 때만 복잡성을 높여라"라고 권고한다. 자기 모델을 덜 사라고 말하는 벤더의 조언은 귀담아 들을 이유가 있다.
세 레이어를 엮는 설계 흐름
결국 이 세 레이어는 순서대로 설계되어야 한다. 먼저 캔버스로 에이전트 간 역할과 프로토콜을 시각화한다. 어떤 노드가 무엇을 책임지고, 실패했을 때 어떤 노드가 그것을 감지하는가. agent-flow-canvas처럼 브라우저 안에서 즉시 실험 가능한 빌더는 이 단계를 낮은 비용으로 반복할 수 있게 해준다. 다음으로 프롬프트를 설계한다. 성공 기준을 명시하고, 컨텍스트를 구조화하고, 큰 태스크는 체이닝으로 쪼갠다. 마지막으로 자율성 수준을 결정한다. 이 에이전트가 레벨 1인지, 레벨 3인지를 의식적으로 선택해야 한다. 기본값으로 두면 마케팅 언어가 결정해버린다.
'빠른 프로토타이핑 → 검증 → 고도화'라는 흐름은 이 세 레이어를 한 사이클씩 조이는 과정이다. 캔버스로 구조를 잡고, 프롬프트로 지시를 다듬고, 자율성 수준을 실제 결과와 대조해가며 올리거나 낮춘다. 에이전트가 제대로 작동하는 순간은 도구를 설치한 순간이 아니라, 이 세 레이어가 서로 맞물리는 순간이다.