본문으로 건너뛰기

AI 에이전트 도입 · 정착

AI 에이전트를 회사에 정착시킵니다

도구를 파는 일이 아닙니다. 무엇을 자동화할지 판단하고, 통제 장치를 세우고, 팀이 실제로 쓰게 만드는 일까지 함께합니다.

Marblo 보드 — 12개 작업이 4개 컬럼에 퍼져 각각 담당 에이전트가 붙어 있다
스킬 · MCP · 에이전트 · 워크플로 173종 MIT 공개한국 업무용 22종 포함코드는 로컬에 남습니다오픈 생태계 보기
PROBLEM

지금 팀에서 벌어지는 일

AI 코딩 도구는 이미 쓰고 계실 겁니다. 문제는 도구가 없는 게 아닙니다. 도구는 각자 알아서 쓰고 있는데, 회사 차원에서는 아무것도 안 보이는 상태라는 것입니다.

  • 누가 어떤 도구를 얼마나 쓰는지 파악이 안 됩니다. 도입을 결정한 적도 없는데 이미 다들 쓰고 있습니다.
  • 에이전트가 만든 변경이 리뷰 없이 들어가거나, 반대로 무서워서 아무도 실무에 안 씁니다. 중간이 없습니다.
  • 결과물은 남는데 왜 그렇게 했는지가 안 남습니다. 담당자가 바뀌면 처음부터 다시 파악해야 합니다.
  • AI 사용료가 어느 팀에서 얼마나 나가는지 청구서를 받고 나서야 압니다. 예산을 세울 근거가 없습니다.
  • 보안 검토를 통과할 자료를 만들 사람이 조직 안에 없습니다. 그래서 검토가 시작되지도 못하고 멈춰 있습니다.
WHY NOT JUST ONE AGENT

Claude Code 하나면 되지 않나요

대부분의 경우 됩니다. Claude Code도 Codex도 잘 만든 도구고, 혼자 하나씩 처리할 때는 그것으로 충분합니다. 저희도 그렇게 씁니다.

문제는 하나를 둘로, 둘을 다섯으로 늘릴 때 생깁니다. 그때부터는 에이전트를 굴리는 일보다 에이전트를 파악하는 일이 더 오래 걸립니다. 아래가 실제로 막히는 지점들입니다.

동시에 하나밖에 못 봅니다

터미널 창을 늘리면 에이전트는 늘어납니다. 그런데 세 개째부터는 어느 창에서 무엇이 끝났는지 모릅니다. 창을 늘린 게 아니라 놓칠 것을 늘린 셈입니다.

MARBLO

전부 하나의 화면에 올라옵니다. 대화 로그가 아니라 상태로 봅니다.

WORKING 5 · REVIEW 2 · IDLE 1 · DONE 18 — 창을 옮기지 않고 전부 봅니다
같은 파일을 서로 밟습니다

두 에이전트가 한 저장소에서 돌면 서로의 변경을 덮어씁니다. 결국 하나 끝나면 다음 하나를 돌리게 되고, 병렬로 굴린 의미가 사라집니다.

MARBLO

티켓마다 git worktree 를 따로 팝니다. 물리적으로 서로의 파일을 못 건드립니다.

Developing · Merge needed · Cleanup merged — 상태가 함께 표시됩니다
머지를 막아주는 장치가 없습니다

리뷰는 사람의 기억에 의존합니다. 바쁘면 건너뜁니다. 사내 규정이 있어도 그건 문서일 뿐 흐름이 아닙니다.

MARBLO

REVIEW 단계를 통과해야 머지됩니다. 규정을 문서가 아니라 흐름이 강제합니다.

Worktree diff ready · 4 changes · opened from task branch
모델을 작업 단위로 못 고릅니다

Claude Code 는 Claude 입니다. 이 티켓엔 Codex 가 낫고 저 티켓엔 Grok 이 나아도, 모델을 바꾸려면 도구를 바꿔야 합니다. 한 벤더에 묶입니다.

MARBLO

티켓마다 모델을 지정합니다. 벤더가 하나 흔들려도 작업이 멈추지 않습니다.

티켓마다 다른 모델 — Opus 5 · Claude · Fable 5 · MiniMax · Kimi 3 · Codex 5.6 · Luna · Sol · Grok
비용은 청구서로 알게 됩니다

누가 어느 작업에 토큰을 얼마나 썼는지 그때그때 확인할 방법이 없습니다. 예산을 세울 수도, 초과를 막을 수도 없습니다.

MARBLO

벤더별·모델별·에이전트별 사용량과 금액이 워크스페이스에 남습니다. 어느 에이전트가 실제로 어떤 모델을 돌렸는지까지 대조됩니다.

벤더별 사용량과 금액이 모델 단위까지 쪼개져 남습니다
판단 근거가 사라집니다

코드는 남는데 왜 그렇게 했는지는 대화창과 함께 사라집니다. 몇 달 뒤 같은 자리를 고칠 때 처음부터 다시 파악합니다.

MARBLO

티켓 단위 추가 전용 기록이 남습니다. 어떤 에이전트가 무엇을 근거로 무엇을 바꿨는지 되짚습니다.

filtered 38 / total 124 · 38 done · 24 reports · 18 tests

에이전트를 켜는 건 쉽습니다. 어려운 건 지금 무엇이 돌고 있는지 아는 것입니다.

Marblo 공식 리포지토리
CONTROL

통제 없이는 도입이 아닙니다

병렬로 굴리는 건 어렵지 않습니다. 어려운 건 병렬로 굴리면서도 무엇이 바뀌었는지 알고, 마지막에 사람이 승인하게 만드는 것입니다. 도입 검토에서 실제로 걸리는 지점도 성능이 아니라 여기입니다.

claude

feature/audit-panel

ahead 3 · behind 0 · no conflicts

codex

fix/board-query

ahead 7 · behind 4 · 2 conflicts

grok

archive/repo-connect

ahead 0 · behind 12 · merged

REVIEW · 머지 전에 사람이 승인합니다
격리 실행
에이전트마다 별도 git worktree 에서 돌립니다. 병렬로 돌아도 서로의 변경을 덮어쓰지 않고, 충돌은 조용히 뭉개지는 대신 충돌로 표시됩니다.
승인 게이트
작업이 끝나면 REVIEW 로 이동하고, 사람이 승인하기 전에는 머지되지 않습니다. "리뷰하기로 했다"가 아니라 리뷰를 지나야 다음이 없습니다.
감사 로그
누가 무엇을 열었고 권한이 언제 바뀌었는지 티켓 단위로 남습니다. 보안 검토에서 요구하는 자료가 따로 만들지 않아도 쌓입니다.
비용 추적
구독료와 AI 사용료가 분리돼 있고, 모델별·에이전트별 사용량을 워크스페이스에서 봅니다. 예산을 실제 숫자 위에서 세웁니다.
티켓당 격리 브랜치 · no conflicts / 2 conflicts
Member workload · Audit log · ticket + worktree
AGENT THINKING

코딩만의 이야기가 아닙니다

목표 하나를 갈래로 쪼개고, 각 갈래를 성격이 다른 모델에 맡기고, 마지막에 사람이 합치는 것. 이 사고 방식 자체는 코드와 무관합니다.

마케팅 집행도, 데이터 분석도, GA4 구축도, 기획 문서도 같은 구조로 돌아갑니다. 개발팀이 없는 조직에서도 쓸 수 있다는 뜻입니다.

마케팅 집행

캠페인 하나, 갈래 넷

소재 카피 · 타겟 세그먼트 · 랜딩 문구 · 예산 시나리오를 동시에 굴립니다. 한 사람이 순서대로 만들면 나흘, 갈래로 나누면 하루에 네 벌이 나오고 사람은 고르기만 합니다.

데이터 분석

가설과 반박을 같이

한 모델이 쿼리를 짜는 동안 다른 모델이 그 결론을 무너뜨릴 방법을 찾습니다. 벤더가 다르면 같은 착각을 공유하지 않습니다. 혼자 분석할 때 가장 위험한 게 자기 확신입니다.

GA4 구축

설계·구현·검증을 겹쳐서

이벤트 택소노미 설계, 태깅 구현, 수집 검증을 각각 맡깁니다. 보통은 검증이 구현을 기다리고 구현이 설계를 기다리는데, 그 대기가 사라집니다.

기획 · 문서

초안과 구멍 찾기를 동시에

한쪽이 기획서를 쓰는 동안 다른 쪽이 반대 논리를 세웁니다. 회의에 들고 갈 때 이미 한 번 두들겨 맞은 문서가 됩니다. 회의에서 처음 지적받는 것보다 낫습니다.

오케스트레이터가 PRD 하나를 프론트엔드·백엔드·테스트 세 티켓으로 분해하는 화면
목표 하나를 던지면 갈래로 쪼갭니다 — 프론트엔드 · 백엔드 · 테스트
분해된 세 티켓이 각각 Claude 와 Codex 에 배정돼 병렬로 진행되고 완료된 화면
갈래마다 다른 모델이 붙어 동시에 진행됩니다 — Claude · Codex
실제 워크스페이스 녹화 · 무음 · 87초 — 목표 분해와 배분 과정

운용 모델

ClaudeCodexGrokOpus 5Fable 5Kimi 3MiniMaxLunaSol

우선순위 3종 + 작업 성격에 따라 그 외 모델 배치 · BYOM 연결 가능

JUDGMENT

모든 팀에 맞지는 않습니다

저희는 파는 쪽이기 이전에 도입을 책임지는 쪽입니다. 맞지 않는 곳에 넣으면 6개월 뒤에 저희가 다시 불려갑니다. 그래서 안 맞는 경우를 먼저 말합니다.

맞습니다

  • 한 사람이 여러 작업을 동시에 굴려야 하는 팀
  • 머지 전에 반드시 사람이 검토해야 하는 규정이 있는 조직
  • AI 사용료와 작업 이력을 부서 단위로 설명해야 하는 곳
  • 한 벤더에 묶이는 것이 리스크로 잡히는 조직
  • 개발 외 업무(마케팅·분석·기획)에도 적용할 여지가 있는 팀

지금은 아닙니다

  • 일이 작아서 한 사람이 순서대로 처리하는 게 더 빠른 경우
  • AI 사용료를 구독료와 별도로 집행할 방법이 아직 없는 조직
  • Linux 전용 환경 — 현재 macOS·Windows 만 지원합니다
  • 도구보다 프로세스가 먼저 필요한 팀. 그건 교육으로 먼저 풉니다
  • 당장 인원을 줄이는 것이 목적인 경우. 그 목적에는 맞지 않습니다
ADOPTION

도입은 한 번에 끝나지 않습니다

구독을 켜는 것과 팀이 실제로 쓰는 것은 다른 일입니다. 단계마다 판단할 것이 따로 있고, 어느 단계에서든 멈추는 게 맞는 결론일 수 있습니다.

  1. 01

    적합성 진단

    지금 업무 중 무엇이 에이전트로 넘어갈 수 있고 무엇은 넘기면 안 되는지 가려냅니다. 반나절 워크숍과 리포트로 끝냅니다.

  2. 02

    팀 교육

    에이전트를 지휘하는 일은 코딩과 다른 기술입니다. 작업 분해, 승인 기준, 실패 처리까지 실습으로 익힙니다. 강의가 아니라 실습입니다.

  3. 03

    PoC

    워크플로우 하나를 골라 실제로 돌립니다. 효과가 안 나오면 여기서 멈추는 게 맞습니다. 그 판단도 진단의 일부입니다.

  4. 04

    팀 정착

    사내 매뉴얼, 승인 기준, 운영 규칙을 문서로 남깁니다. 담당자가 바뀌어도 유지되게 만드는 단계입니다.

  5. 05

    전사 확장

    온프레미스, SSO, 감사 로그, SLA. 보안팀과 구매팀이 요구하는 것을 채웁니다.

설치와 연결 단계는 앱이 안내합니다 · Install CLI DONE · Authenticate DONE · 2 / 4 complete
OPEN ECOSYSTEM

쌓은 것을 들고 나갈 수 있습니다

도구 도입에서 가장 큰 걱정은 성능이 아니라 나갈 수 있느냐입니다. 업무 절차를 특정 도구 안에만 쌓아두면 그 도구가 비싸지거나 방향을 틀어도 못 떠납니다.

스킬 · MCP 서버 · 에이전트 · 워크플로 · 지식팩 173종이 공식 리포지토리에 MIT 로 공개돼 있습니다. 전부 지금 쓰는 CLI 에서 그대로 동작하는 파일이라, 앱을 그만 써도 그 자산은 남습니다. 여기엔 DART 공시 · 부동산 실거래가 · 판례 검색 · HWP 편집 같은 한국 업무용 22종이 포함됩니다.

05NEXT

어느 쪽으로 시작하시겠습니까

세 가지 경로가 있고, 각각 다른 사람을 위한 것입니다.

기업
도입을 검토 중이라면 적합성 진단부터 시작합니다. 30분 상담은 무료입니다.
개인 개발자
먼저 써보고 싶다면 Marblo Founders 베타로 바로 시작하세요.
리셀·영업 파트너
고객사에 AI 에이전트를 제안하고 있다면 함께할 수 있습니다.
Hypemarc | 이종 AI 에이전트 오케스트레이션 컴퍼니