마케팅 집행
캠페인 하나, 갈래 넷
소재 카피 · 타겟 세그먼트 · 랜딩 문구 · 예산 시나리오를 동시에 굴립니다. 한 사람이 순서대로 만들면 나흘, 갈래로 나누면 하루에 네 벌이 나오고 사람은 고르기만 합니다.
AI 에이전트 도입 · 정착
도구를 파는 일이 아닙니다. 무엇을 자동화할지 판단하고, 통제 장치를 세우고, 팀이 실제로 쓰게 만드는 일까지 함께합니다.

AI 코딩 도구는 이미 쓰고 계실 겁니다. 문제는 도구가 없는 게 아닙니다. 도구는 각자 알아서 쓰고 있는데, 회사 차원에서는 아무것도 안 보이는 상태라는 것입니다.
대부분의 경우 됩니다. Claude Code도 Codex도 잘 만든 도구고, 혼자 하나씩 처리할 때는 그것으로 충분합니다. 저희도 그렇게 씁니다.
문제는 하나를 둘로, 둘을 다섯으로 늘릴 때 생깁니다. 그때부터는 에이전트를 굴리는 일보다 에이전트를 파악하는 일이 더 오래 걸립니다. 아래가 실제로 막히는 지점들입니다.
터미널 창을 늘리면 에이전트는 늘어납니다. 그런데 세 개째부터는 어느 창에서 무엇이 끝났는지 모릅니다. 창을 늘린 게 아니라 놓칠 것을 늘린 셈입니다.
MARBLO
전부 하나의 화면에 올라옵니다. 대화 로그가 아니라 상태로 봅니다.
두 에이전트가 한 저장소에서 돌면 서로의 변경을 덮어씁니다. 결국 하나 끝나면 다음 하나를 돌리게 되고, 병렬로 굴린 의미가 사라집니다.
MARBLO
티켓마다 git worktree 를 따로 팝니다. 물리적으로 서로의 파일을 못 건드립니다.
리뷰는 사람의 기억에 의존합니다. 바쁘면 건너뜁니다. 사내 규정이 있어도 그건 문서일 뿐 흐름이 아닙니다.
MARBLO
REVIEW 단계를 통과해야 머지됩니다. 규정을 문서가 아니라 흐름이 강제합니다.
Claude Code 는 Claude 입니다. 이 티켓엔 Codex 가 낫고 저 티켓엔 Grok 이 나아도, 모델을 바꾸려면 도구를 바꿔야 합니다. 한 벤더에 묶입니다.
MARBLO
티켓마다 모델을 지정합니다. 벤더가 하나 흔들려도 작업이 멈추지 않습니다.
누가 어느 작업에 토큰을 얼마나 썼는지 그때그때 확인할 방법이 없습니다. 예산을 세울 수도, 초과를 막을 수도 없습니다.
MARBLO
벤더별·모델별·에이전트별 사용량과 금액이 워크스페이스에 남습니다. 어느 에이전트가 실제로 어떤 모델을 돌렸는지까지 대조됩니다.
코드는 남는데 왜 그렇게 했는지는 대화창과 함께 사라집니다. 몇 달 뒤 같은 자리를 고칠 때 처음부터 다시 파악합니다.
MARBLO
티켓 단위 추가 전용 기록이 남습니다. 어떤 에이전트가 무엇을 근거로 무엇을 바꿨는지 되짚습니다.
에이전트를 켜는 건 쉽습니다. 어려운 건 지금 무엇이 돌고 있는지 아는 것입니다.
Marblo 공식 리포지토리
병렬로 굴리는 건 어렵지 않습니다. 어려운 건 병렬로 굴리면서도 무엇이 바뀌었는지 알고, 마지막에 사람이 승인하게 만드는 것입니다. 도입 검토에서 실제로 걸리는 지점도 성능이 아니라 여기입니다.
feature/audit-panel
ahead 3 · behind 0 · no conflicts
fix/board-query
ahead 7 · behind 4 · 2 conflicts
archive/repo-connect
ahead 0 · behind 12 · merged
목표 하나를 갈래로 쪼개고, 각 갈래를 성격이 다른 모델에 맡기고, 마지막에 사람이 합치는 것. 이 사고 방식 자체는 코드와 무관합니다.
마케팅 집행도, 데이터 분석도, GA4 구축도, 기획 문서도 같은 구조로 돌아갑니다. 개발팀이 없는 조직에서도 쓸 수 있다는 뜻입니다.
마케팅 집행
소재 카피 · 타겟 세그먼트 · 랜딩 문구 · 예산 시나리오를 동시에 굴립니다. 한 사람이 순서대로 만들면 나흘, 갈래로 나누면 하루에 네 벌이 나오고 사람은 고르기만 합니다.
데이터 분석
한 모델이 쿼리를 짜는 동안 다른 모델이 그 결론을 무너뜨릴 방법을 찾습니다. 벤더가 다르면 같은 착각을 공유하지 않습니다. 혼자 분석할 때 가장 위험한 게 자기 확신입니다.
GA4 구축
이벤트 택소노미 설계, 태깅 구현, 수집 검증을 각각 맡깁니다. 보통은 검증이 구현을 기다리고 구현이 설계를 기다리는데, 그 대기가 사라집니다.
기획 · 문서
한쪽이 기획서를 쓰는 동안 다른 쪽이 반대 논리를 세웁니다. 회의에 들고 갈 때 이미 한 번 두들겨 맞은 문서가 됩니다. 회의에서 처음 지적받는 것보다 낫습니다.


운용 모델
우선순위 3종 + 작업 성격에 따라 그 외 모델 배치 · BYOM 연결 가능
저희는 파는 쪽이기 이전에 도입을 책임지는 쪽입니다. 맞지 않는 곳에 넣으면 6개월 뒤에 저희가 다시 불려갑니다. 그래서 안 맞는 경우를 먼저 말합니다.
맞습니다
지금은 아닙니다
구독을 켜는 것과 팀이 실제로 쓰는 것은 다른 일입니다. 단계마다 판단할 것이 따로 있고, 어느 단계에서든 멈추는 게 맞는 결론일 수 있습니다.
지금 업무 중 무엇이 에이전트로 넘어갈 수 있고 무엇은 넘기면 안 되는지 가려냅니다. 반나절 워크숍과 리포트로 끝냅니다.
에이전트를 지휘하는 일은 코딩과 다른 기술입니다. 작업 분해, 승인 기준, 실패 처리까지 실습으로 익힙니다. 강의가 아니라 실습입니다.
워크플로우 하나를 골라 실제로 돌립니다. 효과가 안 나오면 여기서 멈추는 게 맞습니다. 그 판단도 진단의 일부입니다.
사내 매뉴얼, 승인 기준, 운영 규칙을 문서로 남깁니다. 담당자가 바뀌어도 유지되게 만드는 단계입니다.
온프레미스, SSO, 감사 로그, SLA. 보안팀과 구매팀이 요구하는 것을 채웁니다.
도구 도입에서 가장 큰 걱정은 성능이 아니라 나갈 수 있느냐입니다. 업무 절차를 특정 도구 안에만 쌓아두면 그 도구가 비싸지거나 방향을 틀어도 못 떠납니다.
스킬 · MCP 서버 · 에이전트 · 워크플로 · 지식팩 173종이 공식 리포지토리에 MIT 로 공개돼 있습니다. 전부 지금 쓰는 CLI 에서 그대로 동작하는 파일이라, 앱을 그만 써도 그 자산은 남습니다. 여기엔 DART 공시 · 부동산 실거래가 · 판례 검색 · HWP 편집 같은 한국 업무용 22종이 포함됩니다.
세 가지 경로가 있고, 각각 다른 사람을 위한 것입니다.