하나의 AI에게 모든 것을 요구하는 것을 그만두었습니다. 그 결과는 다음과 같습니다.
요약
단일 범용 AI 모델 대신 작업 성격에 따라 특화된 여러 에이전트로 분리하여 운영하는 전략을 소개합니다. 코딩과 문서 작성 등 목적에 맞는 모델을 라우팅함으로써 답변의 품질과 전문성을 높인 사례를 다룹니다.
핵심 포인트
- 범용 AI의 한계인 일관된 어조와 깊이 문제를 해결하기 위해 에이전트 분리
- 코딩 전용(Qwen 2.5 Coder)과 문서 작성 전용(Granite 3.2) 모델의 분리 운영
- 단순 키워드 기반 라우터를 통한 효율적인 작업 배분 방식 구현
- 에이전트 전문화로 코드 리뷰 및 기술 문서 작성 품질의 즉각적 향상
하나의 AI에게 모든 것을 요구하는 것을 그만두었습니다. 그 결과는 다음과 같습니다.
몇 달 동안 저는 하나의 AI 에이전트(Agent)를 사용했습니다. 하나의 모델, 하나의 엔드포인트(Endpoint)였습니다. 코드 리뷰, 기사 초안 작성, 디버깅(Debugging), 무작위적인 "날씨가 어때"와 같은 질문까지 모든 질문을 던졌고, 그것이 이 모든 것을 처리해 주기를 기대했습니다.
하지만 그렇지 않았습니다. 정말로는 말이죠. 모든 것에 답은 해주었지만, 모든 것에 똑같은 방식으로 답했습니다. 똑같은 어조, 똑같은 깊이, 똑같은 사각지대(Blind spots)를 가졌습니다. 정밀한 코드 리뷰(Code review)가 필요할 때는 친근한 채팅 답변을 받았고, 가벼운 요약이 필요할 때는 세 단락짜리 에세이를 받았습니다.
그래서 저는 이를 세 개의 전문화된 에이전트로 나누었습니다. 유행이라서가 아닙니다. 범용 AI(General-purpose AI)는 타협안이며, 저는 타협하는 것에 지쳤기 때문입니다.
문제점: 하나의 뇌, 너무 많은 업무
저는 Mac Mini M4, RTX 3060이 장착된 Windows PC, 그리고 Ubuntu 박스로 홈 랩(Home lab)을 운영하고 있습니다. 세 기기 모두에 Ollama가 설치되어 있습니다. 처음 6개월 동안은 제가 수용할 수 있는 가장 큰 모델을 사용하여 모든 것을 그곳으로 라우팅(Routing)했습니다.
그 모델은 코딩 전문가인 Qwen 2.5 Coder 32B였습니다. 리팩터링(Refactoring)에는 훌륭했습니다. 디버깅(Debugging)에도 훌륭했습니다. 하지만
ProgrammierMinna (Windows PC, Qwen 2.5 Coder 32B) — 코더 (Coder). 코드 생성 (Code generation), 리팩터링 (Refactoring), 디버깅 (Debugging), PR 리뷰 (PR review)를 담당합니다. 응답 시간: 8-15초. 함수를 작성하거나 버그를 찾아야 할 때 이 모델로 쿼리 (Query)를 보냅니다.
DocMinna (Mac Mini, Granite 3.2 8B) — 작가 (Writer). 문서화 (Documentation), 기사 초안 (Article drafts), README, 기술 사양 (Technical specs)을 담당합니다. 응답 시간: 3-5초. 이 모델은 코딩 능력은 떨어지지만, 구조와 흐름 (Structure and flow) 면에서는 놀라울 정도로 뛰어납니다.
라우터 (Router)는 부끄러울 정도로 단순합니다:
def route_query(query: str) -> str:
coding_keywords = ["code", "function", "bug", "refactor", "debug", "pr", "review"]
writing_keywords = ["write", "draft", "article", "readme", "doc", "summary", "blog"]
...
완벽하냐고요? 아닙니다. "이메일을 보내는 Python 스크립트를 작성해줘 (Write a Python script that sends emails)"라는 요청은 "write"라는 단어 때문에 DocMinna로 라우팅되지만, 실제로는 ProgrammierMinna로 가야 할 것입니다. 이런 경우 발견할 때마다 수동으로 수정합니다. 하지만 90%의 확률로 잘 작동하며, 그것으로 충분합니다.
실제로 변화한 점
품질이 즉각적으로 향상되었습니다
분리하기 전에는 코드 리뷰 (Code review)를 요청하면 "에러 핸들링 (Error handling) 추가를 고려해보세요"와 같은 일반적인 조언만 받았습니다. 분리한 후에는 ProgrammierMinna가 "이 비동기 함수 (Async function)는 TimeoutError를 처리하지 않습니다. 47번 라인 주변에 try/except를 추가하고, 5초 타임아웃과 함께 asyncio.wait_for를 사용하세요"라고 말합니다.
질문은 같지만, 모델이 다릅니다. 깊이가 다릅니다.
과도한 설명이 필요 없어졌습니다
범용 모델 (Generalist)을 사용할 때는 "철저하게 작성해 주세요, 이건 운영 환경용 코드입니다"라거나 "가볍게 작성해 주세요, 이건 블로그 포스트입니다"와 같은 컨텍스트 (Context)를 추가해야 했습니다. 전문 모델 (Specialists)들은 이미 자신의 역할을 알고 있습니다. 톤 (Tone)을 맞추기 위해 프롬프트 엔지니어링 (Prompt-engineering)을 할 필요가 없습니다. 모델 선택 자체에 이미 녹아들어 있기 때문입니다.
병렬 처리 (Parallel processing)가 가능해졌습니다
이제 ProgrammierMinna에게는 코딩 작업을, DocMinna에게는 글쓰기 작업을 동시에 던질 수 있습니다. 이들은 서로 다른 GPU를 가진 서로 다른 머신에서 실행됩니다. 대기열 (Queue)도 없고, 하나가 끝날 때까지 다른 하나가 기다릴 필요도 없습니다.
폴백 (Fallbacks)이 더 단순해졌습니다
Windows PC가 오프라인 상태일 때(절전 모드, Vast.ai 대여 중, 또는 여행 중), 평소라면 ProgrammierMinna로 전송되었을 쿼리들은 다음과 같은 메모와 함께 Celebi로 폴백 (Fallback)됩니다: "PC 오프라인 — 범용 모델(generalist model)로 답변합니다. 품질이 다를 수 있습니다." 시스템이 단순히 실패하는 대신 우아하게 성능을 저하시킵니다 (degrades gracefully).
솔직한 단점들
관리해야 할 모델이 세 개입니다. 업데이트, 저장 공간, 어떤 버전이 어떤 머신에 있는지 추적하는 것 — 이는 오버헤드 (Overhead)입니다. 각 모델은 4~20GB입니다. 제 모델 폴더는 세 대의 머신을 거치며 40GB에서 120GB로 늘어났습니다.
라우팅 (Routing) 실수가 발생합니다. 제가 언급했던 "Python 스크립트 작성" 예시가 있습니다. 다른 사례들도 있습니다. "이 기사를 디버깅해줘" (작성 + 디버깅) 같은 요청은 라우터를 혼란스럽게 합니다. 오라우팅(mis-routes)은 약 5% 정도 발생하며, 응답이 약간 어색하게 느껴지기 때문에 이를 알아차릴 수 있습니다.
모니터링해야 할 엔드포인트 (Endpoints)가 더 많아졌습니다. 확인해야 할 Ollama 인스턴스가 하나인 대신 세 개가 되었습니다. 저는 각 인스턴스에 핑 (Ping)을 보내고, 하나라도 다운되면 Telegram 알림을 보내주는 간단한 헬스 체크 (Health check) 스크립트를 만들었습니다. 만드는 데 30분이 걸렸고, 계속해서 실행되고 있습니다.
컨텍스트 (Context)가 전달되지 않습니다. ProgrammierMinna와 긴 코딩 세션을 진행하다가 Celebi에게 "방금 데이터베이스 스키마에 대해 무엇을 결정했지?"라고 물으면, Celebi는 전혀 알지 못합니다. 각 에이전트 (Agent)는 자신만의 대화 기록을 가집니다. 저는 모델을 전환할 때 관련 컨텍스트를 복사하는 방식으로 이를 해결하고 있지만, 이는 번거로운 작업 (Friction)입니다.
수치들
| 지표 (Metric) | 하나의 범용 모델 (One Generalist) | 세 개의 전문 모델 (Three Specialists) |
|---|---|---|
| 평균 응답 시간 (코딩) | 8-15초 | 8-15초 (동일 모델) |
| ... | ... | ... |
품질의 향상은 주관적이지만 실재합니다. 저는 다시 요청해야 하는 빈도로 이를 측정했습니다. 범용 모델의 경우 응답의 약 30%가 후속 설명 (follow-up clarification)을 필요로 했습니다. 전문 모델의 경우 약 5% 정도였습니다.
이 방식이 적절한 경우 (그리고 그렇지 않은 경우)
이런 경우라면 하세요:
- 여러 가지 뚜렷한 작업 유형(코딩 + 글쓰기 + 분석)이 있는 경우
- 여러 모델(작은 모델이라도)을 실행할 수 있는 하드웨어를 갖춘 경우
- 단순함보다 품질을 더 중요하게 생각하는 경우
- 이미 현재 모델의 한계에 부딪힌 경우
이런 경우라면 하지 마세요:
- 단순히 AI와 가볍게 채팅을 나누는 경우
- RAM이 제한적인 기기를 단 하나만 보유한 경우
- 모든 작업이 유사한 경우 (모두 코딩이거나, 모두 글쓰기인 경우)
- 미세한 품질 향상보다 단순함을 더 중요하게 생각하는 경우
30분 만에 구축하기
이 방식을 시도해보고 싶다면, 가장 빠른 경로는 다음과 같습니다:
- 두 대의 기기에 Ollama 설치 (또는 RAM 여유가 있다면 한 대의 기기에 두 번 설치)
- 서로 다른 모델 다운로드 (Pull): 한 대에는 코딩 모델을, 다른 한 대에는 범용 모델을 설치
- 10줄 내외의 라우터 (Router) 작성 (위의 Python 코드 스니펫과 같은 방식)
- 스크립트가 모델에 직접 연결되는 대신 라우터를 가리키도록 설정
- 잘못된 경로로 전달되는 것을 발견하면 키워드 조정
총 소요 시간: 30분. 총 비용: $0.
진짜 승리
가장 큰 변화는 기술적인 것이 아닙니다. 정신적인 변화입니다.
이전에는 모든 면에서 평범한 AI "직원" 한 명을 두고 있었습니다. 하지만 이제는 각자의 업무에 진정으로 능숙한 세 명의 전문가를 두고 있습니다. 쿼리를 보낼 때, 어떤 전문가가 이를 처리하고 있는지 알 수 있습니다. 출력 결과에 대한 신뢰도가 더 높아졌습니다. 검증하고 수정하는 데 쓰는 시간도 줄어들었습니다.
이는 맥가이버 칼(Swiss Army knife)과 실제 공구함(toolbox)의 차이와 같습니다. 칼은 주머니에 쏙 들어갑니다. 하지만 무언가 진짜 결과물을 만들어내야 할 때는 적절한 도구가 필요합니다.
Sam Hartley는 3대의 기기로 구성된 홈 랩(home lab)에서 멀티 에이전트 AI 설정을 운영하는 1인 개발자입니다. 로컬 AI를 실제로 사용할 수 있게 만드는 인프라에 대해 글을 씁.
→ Fiverr의 맞춤형 자동화 설정
→ Telegram에서 CelebiBots 팔로우하기
ai #agents #automation #selfhosted #ollama #productivity #buildinginpublic
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기