# AI 코딩 에이전트, 마케팅 스택 안에서 자리는 따로 있다

URL: https://trycompass.co/ko/journal/ai-koding-eijeonteu-maketing-seutaek-jari
Type: blog
Locale: ko
Published: 2026-07-03
Updated: 2026-07-03

---

> AI 코딩 에이전트와 노코드 빌더, 그로스팀은 계속 혼동한다. 실제 업무 구분과 위험이 커지는 지점을 짚는다.

그로스팀의 이번 주 티켓 큐에는 세 가지 요청이 쌓여 있다. 랜딩페이지 변형 테스트, 계속 깨지는 CRM 필드 동기화, 그리고 아무도 Looker로 만들고 싶어하지 않는 대시보드. AI 코딩 에이전트, 즉 Cursor, Claude Code, GitHub Copilot의 에이전트 모드 같은 도구는 이 중 두 가지를 오후 한나절 만에 실제로 작동하는 코드로 처리할 수 있다. 세 번째는 캠페인이 끝난 뒤 무슨 일이 벌어지는지에 달려 있다. 이 글은 AI 코딩 에이전트가 실제로 맡도록 설계된 업무와 노코드 에이전트 빌더가 대신 하는 일, 그리고 이 둘을 혼동했을 때 프로덕션 장애로 이어지는 지점을 정리한다.

## AI 코딩 에이전트와 노코드 에이전트 빌더는 다른 도구다

지금 "AI 코딩 에이전트"를 검색하면 결과 페이지에 서로 다른 두 범주가 뒤섞여 나온다. Cursor, Claude Code, GitHub Copilot의 에이전트 모드, Devin은 실제 코드를 작성하고 실행한다. 저장소를 열고, 테스트 스위트를 돌리고, 커밋을 남긴다. 반면 Gumloop, Lindy, Metaflow는 워크플로를 만든다. 드래그 앤 드롭 캔버스 뒤에서 API 호출을 연결할 뿐, 저장소는 어디에도 없다.

두 종류 모두 마케팅·그로스팀에게 "엔지니어 없이 직접 자동화를 만드세요"라는 문구로 팔린다. 하지만 소스 컨트롤에 손을 대는 쪽은 하나뿐이고, 이 차이가 문제가 생겼을 때 누가 고치는지를 결정한다.

노코드 에이전트 빌더에서 만든 워크플로는 자기 샌드박스 안에서 실패한다. 깨진 단계, 재실행, 벤더에게 보내는 지원 티켓이 전부다. 반면 AI 코딩 에이전트가 작성하고 팀이 직접 배포한 스크립트는 어디에 올려놨든 그 자리에서 실패한다. 예약 함수, 유료 툴이 대신 처리하던 웹훅, 2024년 이후로 SSL 인증서를 아무도 갱신하지 않은 공유 서버의 크론잡. Compass는 캠페인을 라우팅할 때 온콜 엔지니어가 배포를 대하는 방식과 똑같이 접근한다. 무엇이 먼저 무너지고, 무엇이 그걸 잡아내는가.

그로스팀이 워크플로 빌더 대신 코딩 에이전트를 꺼내 드는 실제 사례 두 가지가 있다. 광고 플랫폼의 네이티브 태깅이 놓치는 엣지 케이스를 처리하는 UTM 파서, 또는 BI 티켓을 기다리는 대신 웨어하우스에서 어트리뷰션 수치를 바로 가져오는 사내 슬랙 명령어. 둘 다 인증 관련 보일러플레이트 30줄에 감싸인 비즈니스 로직 5줄이다. 에이전트가 잘 처리하고 사람은 두 번 타이핑하기 싫어하는 바로 그 영역이다.

Wegic은 이 두 범주 사이에 있다. 챗으로 페이지나 작은 사이트를 설명하면 템플릿을 채우는 게 아니라 실제 코드를 작성한다. 터미널을 열지 않고도 코딩 에이전트급 결과물을 원하는 팀에게는 순수 워크플로 빌더보다 이쪽이 더 가까운 비교 대상이다.

![데스크에 서서 코드 에디터와 캠페인 분석 화면을 보는 마케팅 오퍼레이션 담당자](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/trycompass/2026-07/dde15a-inline1.webp)

## 그로스팀이 실제로 코딩 에이전트에 맡기는 업무

이 흐름을 도입한 팀들을 지켜보면 세 가지 패턴이 반복된다. BI 툴이 기본으로 연결하지 않는 두 API를 이어붙인 사내 대시보드, 그냥 두면 애널리스트의 오후 반나절을 잡아먹을 일회성 데이터 추출, 그리고 플랫폼 업데이트 하나로 깨진 리디렉션 체인에서 트래킹 픽셀이 계속 정상 발화하도록 잡아주는 접착제 스크립트.

이 중 어느 것도 "마테크 스택 전체를 만들어달라"는 요청이 아니다. 범위가 명확하고, 담당자가 한 명이며, 실패할 때 소리 내며 실패한다. 마지막 조건이 생각보다 중요하다. 어트리뷰션 스크립트가 조용히 실패하는 쪽이 스크립트가 아예 없는 것보다 나쁘다. 팀이 이미 틀린 숫자로 계속 의사결정을 내리기 때문이다.

가트너의 판단은 단호하다. [2026년 말까지 기술 제품·서비스의 80%가 전통적인 IT 직군 밖의 사람들 손에서 만들어질 것](https://www.bluerock.io/post/rise-of-the-citizen-developer)이라는 전망이다. 이건 AI 에이전트에 국한된 마케팅 수치가 아니라, 지금 누가 소프트웨어를 작성하는지에 대한 구조적 예측이다. 웹훅을 고치려고 Claude Code에 프롬프트를 입력하는 그로스 마케터는 이미 이 숫자 안에 들어 있다.

직무 기술서처럼 들리는 요청은 걸러야 한다. "어트리뷰션 모델을 만들어주세요" 같은 것. AI 코딩 에이전트는 두 테이블을 조인하는 스크립트를 작성할 수 있다. 하지만 어트리뷰션 방법론을 결정하는 주체가 되어서는 안 된다.

네 번째 패턴은 규모는 작지만 팀이 살펴보기 시작하면 계속 나온다. 자동화 플랫폼의 작업당 과금이 어느새 마테크 예산에서 가장 비싼 항목이 됐을 때, 취약한 Zapier 체인을 단일 스크립트로 다시 짜는 일이다. 코딩 에이전트가 오케스트레이션 로직을 대체하는 게 아니라, 조건부 단계 5개를 돌리는 대가로 붙던 벤더 마진을 없애는 것뿐이다.

## "블라스트 반경"이 진짜 문제가 되는 지점

"그냥 프롬프트로 시키면 된다"는 조언이 빠뜨리는 부분이 여기다. 위험한 건 코딩 에이전트 자체가 아니다. 그 에이전트가 무엇을 건드리는지가 위험하다.

광고 플랫폼의 읽기 전용 API에서 캠페인 지출을 읽어오는 스크립트는 리스크가 낮다. 최악의 경우라도 이사회 전에 누군가 다시 확인할 리포트에 잘못된 숫자 하나가 들어가는 정도다. 반면 CRM에 쓰기 작업을 하거나, API 키를 로테이션하거나, 이메일 플랫폼에 세그먼트 업데이트를 바로 밀어넣는 스크립트는 완전히 다른 종류다. 에이전트가 필드명을 잘못 짐작하거나 레이트 리밋을 건너뛰면, 그 실수는 내일 아침 영업팀이 전화로 확인할 프로덕션 데이터에 그대로 남는다.

가장 먼저 빠뜨리는 부분은 인증 정보다. 자기 스크립트를 테스트하려고 CRM API 키가 필요한 에이전트는 그 키를 커밋될 설정 파일이나 프로젝트보다 오래 남는 채팅 로그에 아무렇지 않게 붙여 넣는다. 이건 에이전트가 잘못한 게 아니라 요청받은 대로 정확히 한 것뿐이다. 가드레일은 보안 리뷰가 뒤늦게 발견하는 게 아니라, 첫 테스트를 돌리기 전에 사람이 그 키를 어디에 둘지 결정하는 데서 나와야 한다.

도입 데이터도 실제로 어디에 착지하는지 뒷받침한다. 마케팅·SDR 아웃바운드 직군은 [AI 에이전트 도입률 약 41%, 회수 기간 중간값 3.4개월로 측정된 직군 중 가장 빠른 회수 속도](https://www.digitalapplied.com/blog/ai-agent-adoption-2026-enterprise-data-points)를 기록했고, 마케팅 오퍼레이터는 스크립트가 돌아가기 시작하면 주당 5.4시간 가까이 절약한다고 답했다. 빠른 회수는 사업성 판단에는 좋은 신호다. 하지만 스크립트가 런칭 주간에 조용히 발화를 멈췄을 때 누가 온콜인지에 대해서는 아무것도 말해주지 않는다.

해법은 아무도 읽지 않는 정책 문서가 아니다. AI 코딩 에이전트가 만든 스크립트가 읽기 전용 피드 이상의 무언가를 건드리기 전에 던져야 할 질문 세 가지다. 캠페인이 끝난 뒤 누가 소유하는가, 어디에 올라가는가("내 노트북"은 답이 아니다), 화요일 새벽 2시에 실패하면 무슨 일이 벌어지는가. 이 세 질문에 한 문장씩으로 답하지 못한다면, 답할 수 있을 때까지 그 스크립트는 샌드박스에 머물러야 한다.

스크립트가 고객 데이터나 살아있는 캠페인 예산, 나중에 컴플라이언스 리뷰가 물어볼 만한 무언가를 건드린다면 세팅에 15분 더 쓸 가치가 있다. 리포트가 나가고 나면 버릴 일회성 추출이라면 그 절차는 생략해도 된다.

![키보드를 치는 손 옆에 손으로 그린 워크플로 다이어그램이 있는 노트](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/trycompass/2026-07/39e4a6-inline2.webp)

## 다들 인용하는 시민 개발자 통계, 놓치는 부분

가트너의 80% 수치는 "AI가 코딩을 민주화한다"는 글마다 반복해서 인용되지만, 이 숫자를 실제로 쓸모 있게 만드는 단서는 빠져 있다. 이 수치는 사내 툴, 프로토타입, 부서 단위 유틸리티를 센 것이다. 같은 시점까지 프로덕션 마케팅 인프라의 80%를 비엔지니어가 유지보수한다는 뜻이 아니다.

"그로스 마케터가 AI 코딩 에이전트로 작동하는 스크립트를 만들었다"와 "그 스크립트가 이제 회사가 의존하는 인프라다" 사이에는 실제 간극이 있다. 전자는 오늘도 계속 일어난다. 후자는 예전과 똑같은 것들을 요구한다. 버전 관리, 담당자, 롤백 방법. 에이전트가 코드를 쓴다고 이 요구사항이 사라지지 않는다. 다만 시점이 앞당겨질 뿐이다. 스크립트가 깨진 다음이 아니라 돌아가기 시작하기 전에.

시민 개발자 수치는 지금 누가 무언가를 만들 능력이 있는지에 대한 서술로 받아들여야지, 무엇을 무인 상태로 돌려도 되는지에 대한 판정으로 받아들여서는 안 된다.

## "그냥 대시보드 만들어달라고 하세요" 조언은 건너뛰어라

"마케팅에서 AI 코딩 에이전트 쓰는 법"류의 글 대부분은 캠페인 커맨드 센터나 통합 리포팅 대시보드 같은 완전한 사내 툴부터 시작하라고 권한다. 이건 첫 프로젝트로는 틀린 선택이다.

실제 가치를 얻는 팀은 더 작게 시작한다. 스크립트 하나, 입력 하나, 출력 하나, 매일 코드를 쓰지는 않아도 읽을 줄 아는 사람이 검토한다. 대시보드는 UI를 두른 스크립트 열 개다. 그 열 개를 이어붙여 인프라라고 부르기 전에, 먼저 스크립트 하나를 제대로 내보내라.

코딩 파트까지 가기도 전에 팀이 회의록과 후속 작업에 파묻혀 있다면, 그건 먼저 풀어야 할 별개의 더 작은 문제다. AI 회의 에이전트가 캠페인 코드는 한 줄도 건드리지 않고 처리해주는 영역이다.

## 오케스트레이션 캠페인 스택에 이게 어떻게 들어맞는가

AI 코딩 에이전트는 함수를 작성한다. 오케스트레이션 레이어는 그 함수가 언제 실행되는지, 무엇이 트리거하는지, 그리고 이메일·광고·CRM 전반에서 다음에 무슨 일이 일어나는지를 결정한다. 이 둘을 혼동하면 아무 데도 연결되지 않은 채 저장소에 방치된, 원래 만들어진 캠페인에서는 한 번도 트리거되지 않는 훌륭한 스크립트만 남게 된다.

Compass의 입장은 명확하다. 오케스트레이션은 실시간 신호를 바탕으로 캠페인을 채널 간에 라우팅하는 레이어이지, 그 채널이 돌아가는 코드를 작성하는 레이어가 아니다. 둘은 경쟁 관계가 아니라 보완 관계다. 정체된 이메일 시퀀스를 플래그하는 코딩 에이전트 스크립트는, 다음 스프린트가 아니라 바로 그날 안에 발송을 광고로 재라우팅하는 무언가가 다운스트림에 있어야 비로소 쓸모가 생긴다.

런칭의 커머스 쪽을 운영하는 팀에게는 이 라우팅 논리가 마케팅 툴 바깥까지 확장된다. 자체 자동화 레이어를 가진 스토어 플랫폼에도 에이전트가 만든 스크립트와 똑같은 질문을 던져야 한다. 런칭 도중 동기화가 실패했을 때 예외 처리 경로는 누가 소유하는가.

![유리 회의실에서 화이트보드에 그린 대략적인 워크플로 다이어그램 앞에 모인 소규모 그로스팀](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/trycompass/2026-07/4af113-inline3.webp)

## 이번 분기 실제로 맡길 업무

AI 코딩 에이전트는 범위가 명확하고, 소유자가 있고, 실패할 때 소리 내며 실패하는 업무에서 그로스팀 스택에 자리를 얻는다. UTM 파서, 웨어하우스 데이터 추출, 웹훅 수정이 그렇다. 어트리뷰션 방법론을 작성하거나 첫날부터 프로덕션 CRM 데이터에 무인으로 접근하는 일에는 자리가 없다.

누군가의 오후 반나절을 실제로 아껴주는 가장 작은 스크립트부터 시작하라. 스크립트가 깨진 다음이 아니라 나가기 전에 담당자를 지정하라. 더 큰 캠페인 판단은 코딩 에이전트가 우연히 먼저 건드린 무언가가 아니라, 그런 판단을 내리도록 설계된 레이어로 라우팅하라.

한 분기가 지난 뒤 이 세팅이 작동하는지 알려주는 지표는 세 가지다. 그 스크립트들 중 몇 개가 여전히 무인 상태로 돌고 있는가, 사람이 알아채기 전에 몇 번 조용히 실패했는가, 알아챈 뒤 수정까지 얼마나 걸렸는가. 세 번째 숫자가 계속 줄어든다면 코딩 에이전트는 스택 안에서 제자리를 얻은 것이다. 첫 번째 숫자가 팀이 담당자를 지정하는 속도보다 빠르게 늘어난다면, 효율이 아니라 유지보수 부채를 쌓은 것이다.

## FAQ

### AI 코딩 에이전트와 노코드 에이전트 빌더의 차이는 무엇인가?

코딩 에이전트는 저장소를 열고 테스트를 돌리고 실제 커밋을 남기는 반면, 노코드 빌더는 드래그 앤 드롭 캔버스에서 API 호출만 연결한다. 문제가 생겼을 때 코딩 에이전트가 만든 스크립트는 배포한 곳에서 그대로 실패하고, 노코드 워크플로는 벤더의 샌드박스 안에서 실패한다.

### 그로스팀은 AI 코딩 에이전트에 어떤 업무를 맡겨야 하는가?

UTM 파서처럼 광고 플랫폼이 놓치는 엣지 케이스를 처리하는 스크립트, 웨어하우스에서 어트리뷰션 수치를 바로 꺼내는 슬랙 명령어, 트래킹 픽셀을 고치는 접착제 스크립트처럼 범위가 좁고 담당자가 명확하며 실패할 때 소리 내며 실패하는 업무가 적합하다.

### AI 코딩 에이전트가 만든 스크립트에서 가장 위험한 부분은 무엇인가?

에이전트 자체가 아니라 그것이 건드리는 대상이다. CRM에 쓰기 작업을 하거나 API 키를 로테이션하거나 라이브 캠페인 예산에 손대는 스크립트는, 필드명 오류나 레이트 리밋 누락이 곧바로 프로덕션 데이터 사고로 이어진다.

### 가트너의 시민 개발자 80% 통계를 그대로 믿어도 되는가?

그 수치는 사내 툴과 프로토타입, 부서 단위 유틸리티를 센 것이지 프로덕션 마케팅 인프라를 가리키지 않는다. 스크립트를 만들 능력이 있다는 것과 그 스크립트가 회사가 의존하는 인프라가 됐다는 것은 다른 이야기다.

### AI 코딩 에이전트로 만든 첫 프로젝트로 대시보드를 시작해도 되는가?

권장하지 않는다. 대시보드는 UI를 두른 스크립트 열 개에 가깝다. 입력 하나, 출력 하나가 명확한 스크립트 하나를 먼저 제대로 내보내고, 그다음에 이어붙이는 편이 안전하다.

### AI 코딩 에이전트가 만든 스크립트를 프로덕션에 올리기 전에 무엇을 확인해야 하는가?

캠페인이 끝난 뒤 누가 소유하는지, 어디에 올라가는지(노트북은 답이 아니다), 새벽에 실패하면 무슨 일이 벌어지는지 세 가지를 한 문장씩으로 답할 수 있어야 한다. 답하지 못하면 스크립트는 샌드박스에 머물러야 한다.

### AI 코딩 에이전트는 마케팅 오케스트레이션 레이어를 대체하는가?

아니다. 코딩 에이전트는 함수를 작성하고, 오케스트레이션 레이어는 그 함수가 언제 실행되고 무엇을 트리거하는지를 결정한다. 두 레이어를 혼동하면 아무 데도 연결되지 않은 스크립트만 저장소에 남는다.