2026년 로컬 AI 에이전트: 실제로 작동하는 것과 여전히 실패하는 것

빠른 사실

• 테스트된 스택: Cline + Ollama, Continue.dev Agent, LangGraph + Ollama(맞춤형), AutoGPT-local, OpenInterpreter, MetaGPT local.
• 테스트된 작업: 주제 리서치, 다중 파일 리팩터링, 이메일 초안 트리아지, 스크레이프-요약, 버그 디버깅.
• 하드웨어: Apple M5 Max 64 GB 통합 메모리와 2× NVIDIA RTX 3090 24 GB 데스크톱. 두 기기 모두 Qwen3-Coder 30B Q4_K_M을 32K context로 편안하게 실행합니다.
• 모델: Qwen3-Coder 30B(주), GLM-4.7 32B, Gemma 4 27B, Llama 3.3 70B(2026년 5월 기준 신뢰할 수 있는 4가지 tool-caller). 이후 GLM-5.1/5.2, Kimi K2.6, DeepSeek V4가 차세대 오픈웨이트 tool-caller로 등장했습니다. 위 평가는 2026년 5월 모델 세트로 측정되었으며 이들 모델로 재검증되지 않았습니다.
• 평가 형태: 2개 스택이 5가지 작업 모두에서 신뢰할 수 있고, 3개 스택은 각 1–2가지 작업에서 신뢰할 수 있으며, 1개 스택은 사용 불가입니다.
• 앱 간 확장 범위: 신뢰할 수 있는 2개 스택은 MCP 서버(파일시스템, sqlite/데이터베이스, 브라우저)를 통해 에디터를 넘어 확장되어, 단일 앱 코딩 에이전트를 여러 도구에 걸쳐 읽고 판단하고 실행하는 local-first 다단계 에이전트로 바꿔줍니다.
• 비용: API 수수료 0원. 350W GPU 데스크톱에서 다단계 작업당 약 전기 비용 ~150–450원(Mac에서는 75원 미만).
• 효과적인 감독 패턴: 읽기 도구는 자동 승인, 모든 쓰기/셸 도구는 수동 승인, 긴 세션 후 감사 로그 검토.

테스트 방법: 동일 모델, 동일 작업, 다른 하네스

• 백엔드: macOS와 Linux에서 Ollama 0.5+. 주 모델 Qwen3-Coder 30B Q4_K_M (32K context). 보조 모델(GLM-4.7 32B, Gemma 4 27B, Llama 3.3 70B)은 tool 호출 실패가 단일 모델의 아티팩트가 아님을 확인하는 데 사용하였습니다.
• 하드웨어: Apple M5 Max 64 GB MacBook Pro 하나와 2× RTX 3090 24 GB Linux 데스크톱. 두 기기 모두 Qwen3-Coder 30B를 사용 가능한 속도(>15 tokens/s)로 유지합니다.
• 작업: 주제 리서치(틈새 주제에 대한 8개 출처 수집, 중복 제거, 요약), 다중 파일 리팩터링(12개 TypeScript 파일에서 서비스 이름 변경), 이메일 초안 트리아지(40개 메시지 폴더에 대한 요약 및 응답 초안 작성), 스크레이프-요약(5개 URL 읽기 및 비교 요약 작성), 버그 디버깅(기존 테스트가 불안정한 이유 파악).
• 실행 빈도: 각 작업은 30일 기간 동안 스택당 3번 실행되었으며, 매번 새로운 프롬프트를 사용하였습니다. 결과는 "감독 없이 완료", "감독 포함 완료", "부분적", "막힘/실패"로 채점하였습니다.
• 감독 지표: 작업당 필요한 승인 횟수와 제안된 행동을 거부한 승인 비율. 높은 거부율은 하네스가 인간이 필터링해야 하는 노이즈를 생성하고 있음을 나타냅니다.
• 정직성 제약: 정확한 수치가 아닌 범위. "5가지 작업 모두에서 신뢰할 수 있음"은 15번의 실행 중 13–15번이 완료됨을 의미합니다. "긴 계획 범위에서 실패"는 개입 없이 15번 실행 중 3–6번이 완료됨을 의미합니다. 평가는 보수적입니다. 스택이 작동하였지만 사소하지 않은 개입을 통해서만 작동한 경우, 무감독 작업 목적으로는 실패로 계산합니다.
• Tool 호출 신뢰성은 이 모든 것의 기반이 되는 레이어입니다. 모델 측 비교는 2026년 Tool Calling을 위한 최고의 로컬 모델을 참조하십시오. 프로토콜 레이어는 MCP로 Ollama를 데이터베이스와 API에 연결하기에서 다룹니다.

에이전트 현실 테이블: 6개 스택, 5가지 작업, 정직한 평가

작동하는 것: Cline + Ollama가 기본 선택

• 무엇인가: Cline은 VS Code를 자율 에이전트 표면으로 변환하는 VS Code 확장 프로그램입니다. 모델은 Plan 모드에서 계획을 제안하고, Act 모드에서 도구 표면(read_file, write_to_file, replace_in_file, execute_command, list_files, search_files)을 통해 실행하며, 도구가 허용 목록에 있지 않는 한 단계 사이에서 승인을 요청합니다.
• 왜 작동하는가: 하네스에 주견이 있습니다. 도구 표면이 작고 안정적이며, 승인 흐름이 보입니다(각 단계가 수락하거나 거부하는 카드임). 모델은 전체 머신이 아닌 에디터만 봅니다. 마지막 동작이 항상 한 번의 클릭으로 되돌릴 수 있으므로 실패가 복구 가능합니다.
• 뛰어난 곳: 다중 파일 리팩터링(단일 작업에서 12개 파일의 서비스 이름 변경), 탐색적 버그 디버깅("이 테스트가 불안정한 이유 찾기": Cline이 인접한 테스트 파일을 읽고, 의존성을 추적하고, 가설을 제안하고, 편집하고, 테스트를 실행함), 프로젝트 내에서 markdown 결과물을 생성하는 범위 제한적 리서치.
• 어려움을 겪는 곳: 외부 HTTP가 필요한 비코딩 작업(네이티브 브라우저 없음). 이메일 초안 트리아지는 MCP 서버나 셸 도구를 연결해야만 작동하며, 그 시점에는 더 작고 범위가 제한된 도구가 직접 할 수 있는 일을 위해 세 가지를 설정하고 있는 것입니다.
• 감독 비용: 작업당 약 5–12번 승인. 대부분은 읽기 도구(저렴하고 빠른 수락)입니다. 비용이 드는 것은 write_to_file과 execute_command입니다. 수동 승인이 필요하도록 설정하면 드문 잘못된 호출이 실행되기 전에 잡을 수 있습니다.
• 토큰 비용: 높음. 에이전트가 파일을 읽는 동안 전체 파일 내용이 대화로 스트리밍됩니다. 32K context의 Qwen3-Coder 30B로 12개 파일 리팩터링은 윈도우를 빠르게 소진합니다. 사소하지 않은 작업에는 128K context 모델(DeepSeek Coder V3, Llama 3.3 70B)로 전환하십시오. (DeepSeek는 이후 오픈 웨이트 신세대 모델인 DeepSeek-V4—Flash/Pro—를 출시했습니다. R1/V3는 계속 로컬에서 사용할 수 있습니다.)
• 자동 승인 목록을 포함한 더 자세한 Cline 설정은 Continue.dev vs Cline vs Aider: 2026년 최고의 로컬 코딩 에이전트를 참조하십시오.

작동하는 것: 더 가벼운 작업을 위한 Continue.dev Agent 모드

• 무엇인가: Continue.dev는 주로 VS Code와 JetBrains용 자동 완성 및 채팅 확장 프로그램으로, tool 호출(파일 읽기/쓰기, 코드베이스 검색, 터미널 실행)과 다단계 계획 루프를 추가하는 Agent 모드가 있습니다. 에이전트는 Cline보다 더 제한적입니다. 더 적은 도구, 더 짧은 기본 계획 범위, 덜 공격적인 자율 동작.
• 왜 작동하는가: Continue.dev의 대상 사용자는 자동 완성 사용자이므로 Agent 모드는 "작고, 빠르고, 보임"이라는 UX를 상속합니다. 각 편집은 모델이 파일을 건드리기 전에 diff 미리보기로 표시됩니다. 계획이 3–5단계를 거의 넘지 않으므로 토큰 소비가 적당하고 감사 기록이 짧습니다.
• 뛰어난 곳: 1–2개 파일 작업, "이 코드베이스 영역 설명", "이 제약으로 이 함수 재작성", "이 메서드에 대한 테스트 추가". 에이전트가 전체 코드베이스를 대화로 끌어오지 않고 실행되므로 32K context 모델이 편안합니다.
• 어려움을 겪는 곳: 5단계 이상의 계획. 8개 이상의 편집이 필요한 다중 파일 리팩터링은 2–3개 파일 후 멈추고 사용자에게 계속하도록 요청하는 경우가 있습니다. 이것은 버그가 아닙니다. 하네스가 계획 범위에 대해 보수적이지만, 동일한 작업에서 Cline보다 더 자주 감독함을 의미합니다.
• 감독 비용: 작업당 약 4–8번 승인, diff 미리보기에 가중치(신호가 높고 빠른 수락).
• 토큰 비용: Continue.dev가 전체 파일을 스트리밍하는 대신 TF-IDF + 임베딩 인덱스를 사용해 관련 스니펫을 검색하기 때문에 Cline보다 현저히 낮습니다. 32K context 모델이 대부분의 작업을 편안하게 완수합니다.
• Cline 대신 Continue.dev Agent를 선택하는 경우: 작업이 2–3개 파일 내에 들어맞을 때, 토큰 예산이 타이트할 때, 이미 자동 완성을 위해 Continue.dev를 사용하고 있어 두 개 대신 하나의 도구를 원할 때.

실패하는 것: LangGraph + Ollama(긴 계획 범위에서 취약)

• 무엇인가: LangGraph는 상태 머신 오케스트레이션 라이브러리입니다. 노드(모델 호출, 도구 실행, 조건 평가를 수행하는 타입이 있는 함수)와 엣지(전환)를 정의합니다. 런타임이 그래프를 실행하고, 분기를 관리하며, 단계 간 상태를 관리합니다. Ollama 백엔드와 결합하면 맞춤형 로컬 에이전트를 갖게 됩니다.
• 데스크톱 에이전트로 실패하는 이유: 실패 표면은 모델이 아닌 오케스트레이션 코드입니다. 화이트보드에서 깔끔해 보이는 상태 머신은 tool이 예상치 못한 데이터를 반환할 때 루프에 빠집니다. 예를 들어, 200은 반환하지만 본문이 빈 HTTP 요청, 존재하지만 디렉터리인 경로에서의 파일 읽기 등. 에이전트가 작업을 디버깅하는 만큼 그래프를 디버깅합니다.
• 계획 범위: 4–5개 노드를 초과하면 취약합니다. 각 분기점은 테스트 표면을 두 배로 늘립니다. 노드 6에서 가능한 실행 경로 트리가 있고 모델은 예상하지 못한 경로를 선택합니다. 그러면 그래프가 다음 노드가 소비할 수 없는 방식으로 상태를 재작성합니다.
• 네이티브 승인 게이트 없음: 루프에 인간 중단을 직접 구축해야 합니다. 라이브러리가 이를 지원하지만(인터럽트-재개가 문서화되어 있음), 구현은 사용자의 몫입니다. Cline과 Continue.dev는 이것을 무료로 제공합니다.
• 실제로 맞는 곳: 입력 형태를 제어하고, 도구 표면이 고정되어 있으며, 그래프에 대한 실제 테스트 스위트를 작성할 수 있는 서버 측 워크플로. 예를 들어, 세 가지 결정론적 도구와 하나의 모델 노드가 있는 고객 지원 라우팅 플로우가 LangGraph의 최적 지점입니다.
• 로컬 에이전트 질문에 대한 평가: 실패. 맞춤형 LangGraph 오케스트레이터를 구축하여 한 번의 설치로 Cline이 하는 것을 하는 것은 사용자의 90%에게 낭비된 시간입니다. Cline이 표현할 수 없는 워크플로 형태가 있고 그래프를 정직하게 유지할 테스트 규율이 있는 경우에만 하십시오.

실패하는 것: OpenInterpreter는 감독하면 유용하지만 감독 없이는 위험함

• 무엇인가: OpenInterpreter는 모델이 사용자의 머신에서 코드(Python, 셸, JavaScript, R)를 작성하고 실행할 수 있게 하는 CLI입니다. 대화형 프롬프트는 기본적으로 각 블록을 실행하기 전에 확인을 요청합니다. 프레이밍은 "ChatGPT Code Interpreter, 로컬"입니다.
• 자율 에이전트로 실패하는 이유: 보안 프롬프트가 블록별이며 모델은 정기적으로 무해해 보이지만 영구적인 상태 변경을 생성하는 셸 명령을 제안합니다(rm on deep paths, pip install into system Python, git reset --hard). 각 블록을 확인하는 것이 작업이 됩니다. 잘못된 블록을 승인하는 비용이 무제한이기 때문에 훑어볼 수 없습니다.
• 자동 확인 모드가 존재합니다. 그리고 그것이 모든 공포 이야기가 나오는 곳입니다. 중요한 것이 있는 머신에서 자동 확인으로 OpenInterpreter를 실행하는 것은 권장하지 않습니다.
• 뛰어난 곳: 감독받는 메모장으로. "이 CSV를 Parquet으로 변환", "이 200개 PDF에서 메타데이터 추출", "이 Python 스크립트를 asyncio 사용으로 재작성". 터미널에 남아서 각 명령을 관찰하고 모델이 더 빠르게 작성 작업을 하는 경우.
• 실패하는 곳: 자율성과 유사한 모든 것. 확인 프롬프트가 활성화되어 있어도 30분 작업은 평균 40+ 확인이 필요하며 실패 모드가 다양합니다(잘못된 작업 디렉터리, 부분 읽기, 예상치 못한 네트워크 호출).
• 감독 비용: 사실상 100%: 각 블록을 감독합니다. "5분" 작업은 읽고 승인하는 시간을 포함하면 직접 하는 것보다 오래 걸립니다.
• 평가: 유용한 도구이지만 잘못된 카테고리. OpenInterpreter는 코드를 실행하는 코딩 어시스턴트이지 자율 에이전트가 아닙니다. Cline과 비교하는 것은 잘못된 프레이밍입니다. 올바른 프레이밍은 "Cline은 기능을 제공하고, OpenInterpreter는 일회성 스크립트를 작성한다"입니다.

실패하는 것: MetaGPT Local(멀티에이전트 역할극 붕괴)

• 무엇인가: MetaGPT는 소프트웨어 개발팀을 시뮬레이션하는 멀티에이전트 프레임워크입니다. Product Manager 에이전트가 요구사항을 작성하고, Architect 에이전트가 설계하고, Engineer 에이전트가 코딩하고, QA 에이전트가 테스트합니다. 각 에이전트는 다른 시스템 프롬프트와 다른 도구 세트를 가진 동일한 기반 모델입니다.
• 실패하는 이유: 멀티에이전트 역할극은 모델이 많은 턴에 걸쳐 일관된 페르소나를 유지하고 컨텍스트를 안정적으로 핸드오프할 수 있다고 가정합니다. 실제로 30B 클래스 로컬 모델로는 페르소나가 흐려집니다. Engineer 에이전트가 PM 에이전트의 분석을 다시 실행합니다. QA 에이전트가 테스트 대신 코드를 재작성합니다. 핸드오프 상태, 즉 각 에이전트가 자신의 턴에서 배운 것이 버그입니다.
• 더 깊은 문제: 멀티에이전트 추상화는 용량을 추가하지 않고 턴을 추가합니다. 동일한 도구 표면과 더 긴 스크래치패드를 가진 단일 에이전트가 더 적은 토큰으로 더 적은 표류와 함께 동일한 작업을 수행합니다. "팀" 프레이밍은 인류학적이지 아키텍처적이지 않습니다.
• 효과가 있을 수 있는 곳: 단단히 정의된 작업과 하드 핸드오프 경계: 예를 들어, 각 단계가 결과물을 가지고 다음 단계가 이전 추론을 무시하는 작성 팀 워크플로(리서치 → 아웃라인 → 초안 → 편집). 우리는 MetaGPT가 체크리스트 프롬프트를 가진 단일 에이전트 하네스를 능가하는 실제 워크플로를 찾지 못했습니다.
• 평가: 실패. 버그는 구현이 아닌 개념적입니다. 구조화된 프롬프트를 가진 단일 에이전트 하네스가 우리가 실행한 모든 작업에서 멀티에이전트 하네스를 능가합니다.
• 단일 에이전트 루프의 신뢰성을 향상시키는 프롬프팅 기법은 chain-of-thought prompting을 참조하십시오. 모델이 생각하는 데 도움이 되는 구조화된 추론 패턴과 단일 에이전트가 일관성을 유지하는 데 도움이 되는 패턴이 동일합니다.

LangGraph를 넘어선 멀티에이전트 오케스트레이션: CrewAI와 AutoGen/AG2

• CrewAI + Ollama: 로컬 모델을 겨냥하기 가장 쉬운 멀티에이전트 프레임워크입니다. Ollama 및 LiteLLM 통합이 문서화되어 있고 성숙합니다. CrewAI의 2계층 설계가 중요합니다. "Crews"(스스로 다음 단계를 협상하는 자율 역할극 에이전트)는 MetaGPT와 동일한 핸드오프 상태 표류를 물려받습니다. "Flows"(개발자가 정의한 이벤트 기반 단계 시퀀스로, 에이전트를 타입이 지정된 노드로 사용)는 LangGraph처럼 동작하며, 모델이 아닌 개발자가 다음에 일어날 일을 결정하기 때문에 안정적입니다.
• CrewAI 신뢰성: 프로덕션 팀은 에이전트가 실행의 약 80%를 완료한다고 보고합니다. 이는 감독 없는 작업에 있어 상당한 격차입니다. 가장 흔한 무음 실패는 CrewAI 설정과 실제로 Ollama가 다운로드한 모델 이름 사이의 불일치입니다. Ollama 서버가 실행되지 않을 때 실패는 사전 경고 없이 첫 번째 tool 호출에서 드러납니다.
• AutoGen/AG2 + Ollama: Ollama에 대한 네이티브 tool-calling은 Ollama 0.3.1부터 지원됩니다(`pip install pyautogen[ollama]). OpenAI 호환 엔드포인트 경로는 AG2 0.28+ 및 Ollama 0.5.7+에서 사용할 수 있습니다. 설정은 저희의 비공식 테스트에서 CrewAI보다 더 신뢰할 수 있었습니다. 움직이는 부품이 적고 클라이언트 클래스가 하나뿐입니다(api_type="ollama"`). 하지만 근본적인 멀티에이전트 대화 패턴(여러 턴에 걸쳐 계획을 논의하는 에이전트)은 몇 턴 후 MetaGPT와 동일한 페르소나 표류 한계에 부딪힙니다.
• 두 프레임워크가 실제로 성과를 내는 곳: 고정된 수의 타입이 지정된 단계와 테스트 스위트를 갖춘 결정론적 파이프라인입니다. 어느 단계에서든 깔끔하게 재시작되는 데이터 보강 작업, 세 가지 고정 tool을 갖춘 지원 티켓 라우터 등이 그 예입니다. 이는 LangGraph가 승리하는 것과 동일한 형태이며, 이유도 같습니다. 인간이 제어 흐름을 결정했고, 모델은 타입이 지정된 슬롯을 채우기만 합니다.
• 두 프레임워크가 MetaGPT처럼 실패하는 곳: "크루에게 목표를 주고 에이전트들이 스스로 작업 분담을 결정하게 하라"는 식의 작업입니다. 핸드오프 상태, 즉 한 에이전트가 배운 것과 다음 에이전트에게 전달한 것은 어느 프레임워크가 감싸든 여전히 약한 고리입니다.
• 결론: "최고의 로컬 멀티에이전트 오케스트레이션 프레임워크"가 타입이 지정된 단계를 가진 프로덕션 파이프라인용 프레임워크를 의미한다면, CrewAI Flows나 AutoGen/AG2는 LangGraph와 함께 합리적인 선택입니다. 워크플로가 스크립트화되면 세 가지 모두 동일한 신뢰성 한계로 수렴하므로, 점수를 매기는 대결이 아니라 팀의 Python 관례에 따라 선택하십시오. 개방형 작업을 스스로 분담하는 자율 에이전트를 의미한다면, 세 가지 중 어느 것도 아직 거기에 도달하지 못했습니다.

사용 불가: AutoGPT-Local은 사실상 방치 상태

• 무슨 일이 있었나: AutoGPT는 2023년의 표준적인 "자율 에이전트" 프로젝트였습니다. 과대 선전이 기술을 앞섰습니다. 계획 루프는 실제 작업에서 결코 신뢰할 수 없었습니다. 프로젝트가 정체되고, 유지 관리자 팀이 분산되었으며, 로컬 전용 포크가 18개월 이상 동안 모든 의존성 업데이트에 뒤처졌습니다.
• 2026년 5월의 구체적인 문제: Ollama 통합이 2024년에 변경된 API 형태를 가정합니다. 내부 계획 프롬프트가 이전 세대 모델에 맞게 조정되어 최신 오픈 웨이트 모델에서 잘못 형성된 계획을 생성합니다. 2025년에 리포지터리에 보고된 문제들이 응답 없이 열려 있습니다.
• 계획 루프 표류: 시작된 실행에서 에이전트는 일반적으로 2–4분 내에 순환 tool 호출 패턴에 진입하였습니다. 동일한 파일을 다시 읽고, 동일한 검색을 다시 실행하고, 작업으로 수렴하지 않습니다. 이것은 범위가 제한되지 않은 자율 루프의 잘 알려진 실패 모드이며, 정확히 범위가 제한된 하네스(Cline, Continue.dev)가 설계상 피하는 것입니다.
• 평가: 사용 불가. 2026년에 AutoGPT-local에 주말을 투자하지 마십시오. 흥미로운 작업이 명시적인 승인 게이트를 가진 범위가 제한된 하네스로 이동하였습니다. AutoGPT는 현재 옵션이 아닌 역사적 아티팩트입니다.
• 향수를 느낀다면: 원래 리포지터리는 여전히 GitHub에 있습니다. 관계를 맺는 올바른 방법은 교훈으로입니다. 자율성이 잘못된 추상화였으며 감독받는 지원이 작동하는 것입니다.

에이전트 데모가 현실보다 나아 보이는 이유

• 데모 작업의 범위가 제한됩니다. "뱀 게임 만들기" 또는 "이 PDF 요약"은 알려진 형태, 작은 파일 표면, 명확한 성공 신호를 가집니다. 실제 작업은 열린 결말이며("우리의 결제 플로우가 사용자의 3%를 잃는 이유 찾기") 큰 파일 표면, 모호한 성공 기준, 오류를 증폭시키는 부작용이 있습니다.
• 데모 실행은 여러 시도 중에서 직접 선택됩니다. 30초 데모 영상은 많은 시도 중 최고입니다. 에이전트가 막히거나, 파일 경로를 환각하거나, 더 이상 사용되지 않는 함수를 호출한 실행은 편집에 없습니다. 성공률을 보는 것이 아니라 성공 하나를 보는 것입니다.
• 데모 프롬프트가 과잉 지정됩니다. "User 서비스를 새 리포지터리 패턴으로 리팩터링"은 데모에서 에이전트가 찾는 파일에 새 패턴이 문서화되어 있기 때문에 작동합니다. 실제 작업에서는 패턴이 3주 전 Slack 스레드에 있습니다. 모델은 사용자의 컨텍스트가 없습니다. 데모는 그것을 가집니다.
• 데모 모델이 로컬 모델보다 큽니다. 클라우드 데모는 프론티어 모델에서 실행됩니다. 로컬 에이전트는 >10 tokens/s로 제공할 수 있는 것에서 실행됩니다. Qwen3-Coder 30B는 2026년 5월에 탁월하지만 GPT-5가 아니며, 데모는 조용히 가장 좋은 모델을 사용합니다.
• 결론: 모든 데모는 실행 상위 10%를 나타낸다고 가정하십시오. 실제 작업에 대한 합리적인 기대치는 개입이 필요한 실패 확률 20–30%의 중앙값 실행입니다. 중앙값에 대해 계획하십시오.

감독 비용이 진정한 지표

• 낮은 감독 작업(총 3–8번 승인): 범위가 제한된 리팩터링에서 Cline, 단일 파일 작업에서 Continue.dev Agent. 주로 읽기 작업과 한두 번의 쓰기이기 때문에 승인을 훑어봅니다. 전체 작업 시간은 승인 마찰이 아닌 모델 지연 시간이 지배합니다.
• 중간 감독 작업(10–20번 승인): 8개 이상의 파일을 건드리는 다중 파일 작업에서 Cline, 계획 범위를 밀어붙이는 모든 것에서 Continue.dev Agent. 더 주의 깊게 승인합니다. 전체 작업 시간이 모델과 사용자 간에 거의 균등하게 나뉩니다.
• 높은 감독 작업(40+ 승인): 사소하지 않은 모든 것을 하는 OpenInterpreter. 에이전트가 속도 향상자가 아니라 작성 속도 증폭기입니다. 인지 작업을 계속 수행하고 각 블록을 읽고 있습니다.
• 실패한 감독 패턴: 승인 피로. 세션에서 약 30번의 승인 후 인간이 읽지 않고 승인하기 시작합니다. 너무 많은 승인이 필요한 하네스는 읽는 것을 멈추도록 훈련시키며, 그 시점에서 보안 게이트는 허구입니다.
• 올바른 조정: 자동 승인 목록. 읽기 도구(read_file, list_files, search_files, list_directory)는 자동 승인에 안전합니다. 쓰기 도구(write_to_file, replace_in_file, execute_command, 양식 제출이 있는 browser_action)는 그렇지 않습니다. 이 단일 설정이 유용한 에이전트와 지루한 에이전트의 차이입니다.
• 올바른 단위: 작업당 승인 횟수. 스택을 평가할 때 데모 작업이 아닌 대표적인 실제 작업에서 승인을 세십시오. 횟수가 20을 초과하면 스택이 실제로 작업을 절약해주고 있지 않습니다.
• Tool 호출 품질을 향상시켜 감독 비용을 줄이는 프롬프팅 기법은 chain-of-thought prompting을 참조하십시오.

에이전트에게 절대 맡기지 말아야 할 작업

• 프로덕션 데이터베이스 쓰기. 실제 테이블에 대해 자신 있게 DELETE FROM users WHERE active = false 쿼리를 실행하는 모델이 이 기사가 존재하는 사고입니다. 기본적으로 읽기 전용 역할로 데이터베이스 도구를 실행하십시오. 별도의 쓰기 역할은 명시적으로 필요한 작업에만, 해당 작업 기간 동안만 활성화하십시오.
• 돈이나 인증과 관련된 모든 것. 결제 API, OAuth 토큰 발급, 계정 생성, 역할 및 권한 변경. 잘못된 호출의 비용은 무제한이며, 자동화의 이점은 작습니다.
• 8–10단계를 초과하는 장기 계획. 에이전트는 장기 계획에서 표류합니다. 올바른 패턴은 "모델이 계획을 제안하고, 인간이 계획을 승인하고, 모델이 단계별로 계획을 실행"이며, "모델이 25단계 작업을 자율적으로 계획하고 실행"이 아닙니다.
• 성공을 빠르게 확인할 수 없는 작업. 2분 안에 읽을 수 있는 스크레이프-요약 작업이 좋은 후보입니다. 한 시간 미만으로 확인할 수 없는 "이 시장 리서치 후 보고서 작성" 작업은 그렇지 않습니다. 확인 비용이 재작성 비용보다 크기 때문에 보고서를 신뢰할 것입니다.
• 백업이 없는 파일을 건드리는 모든 것. 파일 시스템 접근을 단일 작업 디렉터리로 제한하십시오. 작업 공간을 일회용으로 취급하십시오. 에이전트가 작업 공간 밖의 파일에 접근할 수 있다면 에이전트를 잘못 설정한 것입니다.
• 멀티테넌트 또는 공유 인프라. 로컬 에이전트는 2026년에 개인 머신 도구입니다. 공유 CI 러너, 멀티테넌트 데이터베이스, 공유 클라우드 계정은 무감독 에이전트 루프에 잘못된 공격 표면입니다.

결정: 스택 선택

2027년이 가져올 것들

• Tool 호출 신뢰성이 계속 증가할 것입니다. Llama 3 → Llama 3.3, Qwen3 → Qwen3, Gemma 3 → Gemma 4 점프의 트렌드는 모두 같은 방향을 가리킵니다. Tool-calling 훈련은 가장 저렴하고 가장 영향력 있는 사후 훈련 단계입니다. 7B 클래스 모델은 2026년 말/2027년 초에 신뢰할 수 있는 tool-caller가 될 가능성이 높아 에이전트의 하드웨어 장벽을 크게 낮출 것입니다.
• 계획 범위가 늘어날 것입니다. 현재 ~5단계의 신뢰할 수 있는 범위가 표류 문제 없이 8–10단계에 도달할 가능성이 높습니다. 이것은 Cline 스타일의 범위가 제한된 에이전트를 더 낫게 만들지만, AutoGPT 스타일의 범위가 제한되지 않은 에이전트를 작동하게 만들지는 않습니다.
• 멀티에이전트 시스템은 큰 돌파구를 갖지 못할 것입니다. 구조적 문제(핸드오프 상태, 페르소나 표류, 중복 작업)는 모델 크기 문제가 아닙니다. 더 긴 스크래치패드를 가진 단일 에이전트 하네스가 멀티에이전트 역할극을 계속 능가할 것입니다.
• "감독받는 어시스턴트" 모델이 승리합니다. 2027년에 작업을 제공하는 에이전트는 Cline 2.0처럼 보일 것입니다. 더 나은 도구 표면, 더 부드러운 승인, 더 긴 계획 범위이며, AutoGPT의 성공적인 재출시가 아닙니다.
• 정직한 경고: 이 예측 중 하나가 틀릴 수 있습니다. 기술이 2026년 3분기의 모델 릴리스가 감독 비용 방정식을 바꿀 수 있을 만큼 충분히 빠르게 발전합니다. 2026년 11월에 이 기사를 다시 평가하십시오.

로컬 에이전트를 선택하고 실행할 때의 흔한 실수

• 실수 1: 자율성 최적화. "감독 없이 얼마나 오래 실행할 수 있나?"는 잘못된 지표입니다. "작업을 완수하기 위한 승인 횟수?"가 올바릅니다. 자율성 벤치마크로 스택을 선택하면 AutoGPT가 됩니다. 감독 비용으로 선택하면 Cline이 됩니다.
• 실수 2: tool-calling 작업에 소형 모델 사용. 7B 이하(예: Gemma 3 2B) 및 tool-calling fine-tuning 없는 대부분의 7B–13B 범용 모델은 잘못 형성된 tool 호출을 실행합니다. Qwen3-Coder 30B, GLM-4.7 32B, Gemma 4 27B, Llama 3.3 70B를 사용하고 하네스와 싸우는 것을 멈추십시오.
• 실수 3: 다중 파일 작업에 32K context 사용. Cline이 전체 파일 내용을 대화로 스트리밍합니다. 8개 파일 작업이 추론 전에 32K 토큰을 소진할 수 있습니다. 사소하지 않은 다중 파일 작업에는 128K context 모델(DeepSeek Coder V3, Llama 3.3 70B)을 사용하십시오.
• 실수 4: 모든 것을 자동으로 승인. "모두 승인" 스위치는 "에이전트가 내 파일을 삭제했다"로 이어지는 진입로입니다. 읽기 도구만 자동 승인하고, 쓰기와 셸에는 수동 승인을 요구하십시오.
• 실수 5: 에이전트에서 프로덕션 데이터베이스 쓰기. 기본적으로 읽기 전용 역할을 실행하십시오. 별도의 쓰기 역할은 명시적으로 필요한 작업 기간 동안만 존재합니다. 잘못된 쓰기의 비용은 무제한입니다.
• 실수 6: Cline을 먼저 시도하기 전에 맞춤형 LangGraph 오케스트레이터 구축. "맞춤형 에이전트가 필요하다"는 사용 사례의 90%는 Cline + 몇 가지 MCP 서버가 올바른 답변일 만큼 충분히 범위가 제한됩니다. 워크플로 형태가 기존 하네스와 진정으로 호환되지 않을 때만 맞춤형을 구축하십시오.
• 실수 7: 데모 쫓기. 데모는 많은 시도 중 최고입니다. 중앙값 실행을 계획하십시오. 실제 작업에서 70–80% 성공률, 20–30%는 개입 필요. 2026년에 "완전 자율"이라고 불리는 모든 것은 마케팅이지 엔지니어링이 아닙니다.
• 실수 8: 감사 추적 무시. 긴 에이전트 세션 후 행동 로그를 읽으십시오. 패턴이 나타납니다. 세 번 연속 같은 유형의 오류는 승인 규칙을 조정하거나 모델을 변경해야 함을 알려줍니다.

출처

• Cline GitHub 리포지터리 — 자율 코딩 에이전트, 도구 표면 문서, 자동 승인 설정.
• Continue.dev 문서 — agent 모드, 코드베이스 인덱싱, 제공자 설정.
• LangGraph 문서 — 오케스트레이션 라이브러리, 상태 머신 시맨틱, 인간-루프 중단.
• OpenInterpreter GitHub 리포지터리 — 코드 실행 에이전트, 보안 모드, 로컬 모델 통합.
• MetaGPT GitHub 리포지터리 — 멀티에이전트 프레임워크, 역할 정의, 로컬 제공자 설정.
• CrewAI 문서 — Crews 대 Flows 아키텍처, 로컬 Ollama/LiteLLM 통합.
• AG2(AutoGen) Ollama 가이드 — 네이티브 tool-calling, 로컬 모델용 OpenAI 호환 엔드포인트 설정.
• Ollama 모델 라이브러리 — 사용 가능한 로컬 모델, tool-calling 지원 표시, 양자화 옵션.

자주 묻는 질문

관련 자료

• MCP로 Ollama를 데이터베이스와 API에 연결하기: 2026년 로컬 에이전트 설정 — 에이전트를 지원하는 것. 파일 시스템, 데이터베이스, 브라우저, GitHub 도구를 위한 프로토콜 레이어.
• 2026년 Tool Calling을 위한 최고의 로컬 모델 — 모델 레이어. 권장 tool-caller(Qwen3-Coder, Gemma 4, GLM-4.7, Llama 3.3)의 직접 벤치마크 비교.
• Continue.dev vs Cline vs Aider: 2026년 최고의 로컬 코딩 에이전트 — 코딩 유형 작업을 위한 인접 하네스 비교.
• EU 준법 및 기업 워크플로를 위한 로컬 AI 에이전트 — GDPR/EU AI Act 하에 운영하는 기업을 위한 응용 컨텍스트.
• 2026년 최고의 로컬 LLM — 더 넓은 오픈 웨이트 환경의 모델 참조.
• Power Local LLM 허브 — 전체 가이드 라이브러리.