AX는 사람이 병목이라 잘 안됩니다. 사람을 최소화하세요.

올해 모든 기업이 AX(AI Transformation)를 외치고 있다. 하지만 나는 올해 많은 기업들의 AX 시도가 그리 성공적이지 못할 것 같다.

대부분의 기업은 AX를 개인이 AI 도구를 잘 쓰는 것으로 착각한다. 직원들에게 프롬프트 엔지니어링을 가르치고, 비싼 AI 도구, SaaS 툴을 쥐여준다. 하지만 이는 여전히 사람이 병목인 구조다. 사람이 배우고, 사람이 기억하고, 사람이 툴을 찾아 써야 하기 때문이다.

진정한 AX는 사람이 배우는 것이 아니라, 조직의 시스템이 노하우를 흡수하고 증폭시키는 구조를 만드는 것이다. 나는 이것을 생산성 복리 엔진(Productivity Compound Engine)이라 부른다 (Every에서 처음 제시한 복리 엔지니어링, Compounding Engineering에서 영감을 얻었다).

이 엔진을 장착한 조직만이 진정한 AI-Native이며, 복리가 붙는 협업이 가능한 AX 조직이라 할 수 있다.

AX의 핵심: 사람은 잊어도, 엔진은 기억한다

내가 정의하는 AX의 본질은 AI를 업무의 부분 자동화 도구로 쓰는 것이 아니다. 조직의 핵심 운영을 생산성 복리 엔진 중심으로 재설계하는 것이다.

기존의 사내 업무가 어떻게 바뀔지 비교해보면 쉽게 이해할 수 있다.

과거: 팀원 A가 훌륭한 업무 자동화 스크립트를 짠다. 사내 위키에 올린다. 팀원 B는 그게 있는 줄도 모르고 똑같은 스크립트를 또 짠다. (비효율의 반복, 덧셈의 조직)
지니파이의 AX: 팀원 A가 툴을 만든다. 생산성 복리 엔진이 이를 자동으로 인식해 에이전트가 새 도구로 등록한다. 팀원 B가 에이전트에게 업무를 시키면, 에이전트가 알아서 A가 만든 툴을 꺼내와 실행한다. (효율의 누적, 복리의 조직)

이것이 팀의 생산성 복리 엔진이다.

사람이 굳이 “내가 이거 만들었으니 쓰세요”라고 외치지 않아도, 에이전트가 알아서 조직 내 파편화된 도구와 지식을 모듈화하고 재사용한다. 업무를 하면 할수록 조직의 에이전트는 똑똑해지고, 다음 업무는 더 쉬워진다.

그리고 이 과정에서 무엇보다 사람이 배우고, 기억하고, 툴을 사용하기 위해서 일의 방식의 바꾸는 것이 최소화될 수 있다.

AX에서 가장 큰 사람이라는 병목이 최소화되어, 생산성에 복리가 붙는 것이다.

팀의 생산성 복리 엔진을 지탱하는 2가지 기둥

이 엔진이 작동하려면 두 가지 전제 조건이 필요하다. (1) 이 엔진을 채울 재료와 (2) 엔진을 사용할 주체다.

1. 재료 공급: 전 팀원의 바이브 코더(Vibe Coder)화

에이전트가 가져다 쓸 도구(Tool)가 있어야 한다. 이를 위해선 팀원 전체가 필요한 소프트웨어를 직접 만들어 쓸 수 있어야 한다.

소프트웨어 개발 장벽은 무너졌다. 클로드 코드(Claude Code)와 같은 코딩 에이전트 덕분에, 이제 자연어로 코딩하는 바이브 코딩만으로도 누구나 툴을 만들 수 있다.

팀원들이 각자의 업무 효율을 위해 만든 작은 툴들이, 곧장 생산성 복리 엔진을 구성하는 라이브러리 중 하나가 된다.
바이브 코더가 많을수록, 엔진 내에 쌓이는 자산은 기하급수적으로 늘어난다.

2. 엔진 활용: 클로드 코드의 일반 업무 에이전트화

아무리 많은 자동화 소프트웨어가 내부에서 만들어져도 사람이 일일이 찾아서 써야 한다면 실패다.

우리 지니파이는 코딩 에이전트인 클로드 코드를 전사적 일반 업무(General) 에이전트로 격상시켰다.

팀원은 클로드 코드에게 자연어로 업무를 지시한다.
클로드 코드는 직접 소프트웨어를 만들어서 일을 처리하거나, (거의 모든 컴퓨터 관련 기능이 구현되어 있는) 커맨드 라인 명령어들을 도구로 쓸 수 있어서, 일반 업무도 처리 가능하다.
그 뿐만 아니라, 클로드 코드는 팀 생상선 복리 엔진을 검색해 동료들이 만들어둔 MCP, 서브 에이전트, 스킬, 커스텀 커맨드, 이미 구현된 소프트웨어 도구 중 최적의 도구를 찾아 실행한다.
필요한 도구가 없으면? 그때 즉석에서 바이브 코딩으로 만들어 쓴다. 그리고 그 도구는 다시 엔진 내에 추가된다.

이것이 지니파이가 생각하는 AX된 조직의 동작 방식이다.

[예시] 그로스 마케터의 업무는 어떻게 바뀌는가?

“그래서 뭐가 달라지는데?”라고 묻는 분들을 위해, 그로스 마케터의 업무 변화를 예시로 소개한다.

상황: 지난주 집행한 광고 채널(Meta, Google, TikTok)의 성과를 분석하고, 저조한 소재를 OFF 한 뒤 예산을 재조정해야 한다.

❌ AX 실패 조직 (과거의 방식)

데이터 수집: 3개 매체 대시보드에 각각 로그인해서 엑셀 데이터를 다운로드한다.
데이터 가공: 엑셀로 데이터를 합치고 피벗 테이블을 돌린다. (2시간 소요)
병목 발생: ROAS 계산 로직이 복잡해 개발팀에 SQL 쿼리를 요청한다. “바빠서 이틀 뒤에 됩니다”라는 답변을 받는다.
수동 실행: 3일 뒤 데이터를 받아 분석을 마치고, 다시 각 매체에 들어가 수동으로 광고를 끈다.
휘발: 이 과정에서 얻은 인사이트와 SQL 쿼리는 마케터 개인의 PC에만 남고 사라진다.

⭕️ 생산성 복리 엔진이 있는 AX 조직 (지니파이 방식)

지시: 마케터가 클로드 코드(업무 에이전트)에게 자연어로 말한다. “지난주 광고 성과 분석해서 보고해주고, ROAS 200% 미만 소재는 끄는 걸 제안해줘.”
엔진 가동 (재사용): 에이전트는 팀의 생산성 복리 엔진을 검색한다.
- 개발팀이 3달 전에 만들어 둔 전사 통합 광고 데이터 호출 모듈을 찾아 실행한다.
- 다른 마케터가 지난주에 바이브 코딩으로 짠 ROAS 분석 및 이상징후 탐지 스크립트를 찾아 적용한다.
실행 및 개선 (바이브 코딩): 1분 만에 분석 결과가 나온다. 마케터는 이번 분석에 클릭률(CTR) 가중치를 더하고 싶다. 개발자에게 요청하지 않고, 그 자리에서 바이브 코딩으로 로직을 수정해 실행한다.
자산화 (복리 누적): 마케터가 수정한 이 CTR 가중치 분석 로직은 즉시 팀 생산성 복리 엔진에 새로운 버전의 스킬로 자동 저장된다.
결과: 이제 우리 팀의 모든 에이전트는 오늘부터 더 똑똑해진(CTR까지 고려하는) 분석 능력을 갖게 되었다.

이것이 팀의 생산성 복리 엔진의 복리이다. 내가 한 개선이 즉시 동료의 무기가 되는 것이다.

지니파이에서 풀스택 개발자와 AI 교육 담당자를 채용 중입니다.
클로드 코드로 업무하고 협업하는 AI 네이티브 회사에 합류하세요!

AX 조직이 되기 위한 Step-by-Step 가이드

이런 엔진을 구축하기 위해 우리는 다음 4단계를 밟고 있다.

Step 1. 시간 확보 (주 52시간 룰)

가장 중요하다. 대부분의 AX 시도는 여기서 실패한다. 절대적인 시간 확보를 위해서 나는 팀원들의 동의를 얻었다. 주 32시간은 실무, 20시간은 무조건 AI 엔진 구축과 학습에 쓴다. 당장의 실무를 줄여서라도 이 시간을 확보하지 못하면 시작조차 불가능하다. 팀 리드는 실제 이런 시간 확보가 가능한지 계속 확인하고, 실무 시간을 줄여줘야한다.

Step 2. 전사적 바이브 코딩

엔진에 넣을 연료는 팀원들이 만든다. 개발자뿐만 아니라 기획자, 마케터, 디자이너 모두가 자연어로 필요한 도구를 직접 만들어 쓸 수 있어야 한다. 이를 위한 개발자의 코칭과 온디맨드 도움을 제공한다. 최신 AI 코딩 기법 (예: Ralph Wiggum) 등이 나오면 개발자가 비개발자에게 알려준다.

Step 3. 단일 진실의 원천 (SSOT) 구축

에이전트가 멍청한 짓을 하지 않으려면 회사의 상황을 알아야 한다. 우리는 Notion, Slack, Linear를 주요 협업툴로 쓰고 있는데, 이중 Linear를 SSOT(단일 진실의 원천, Single Source of Truth)로 만들어, 에이전트가 회사의 전략과 우선순위를 실시간으로 파악하게 한다 (참고로 Linear는 Jira, Asana와 유사한 업무 관리툴). 항상 Linear의 모든 이니셔티브-프로젝트-이슈가 최신 업데이트가 될 수 있도록 팀원들에게 자동화 툴을 제공한다.

Step 4. 생산성 복리 엔진 구축

개인이 만든 도구를 자동으로 수집하고, 설명서를 붙여 공유하는 시스템을 구축한다. 팀원들이 클로드 코드와 함께 만든 툴, 스킬, 슬래쉬 명령어, 서브 에이전트 등을 자동으로 모듈화하고 문서를 덧붙인 뒤, 공유하는 시스템이다.

지니파이 전략: AX가 잘 안되는 지점을 제품(Product)로

앞서 얘기한 4단계의 진행 과정은 각각이 결코 쉽지 않다. 그래서 잘 진행되지 않는 부분을 내부 소프트웨어 도구를 만들어서 해결을 시도하고, 그게 효과적이라면, 지니파이의 프로덕트로 따로 런칭하려고 계획 중이다. 현재는 4가지를 시도 중이다.

1. AX 실습 생성기

[문제] “AI 써보세요”라고 하면 막막해하고, 일반 강의나 유튜브 튜토리얼 등은 내 실무와 동떨어져 있다.
[제품] 개개인의 업무 로그(Slack, Notion, Linear)를 분석해, 당장 해결해야 할 실무와 직결된 맞춤형 AI 실습 과제를 생성해주고, 전사의 진행 상황을 통합 관리한다.

2. 바이브 코딩 코칭 플랫폼

[문제] 비개발자의 코드는 기능은 동작해도 보안과 구조가 취약해 기술 부채가 누적된다.
[제품] 개발자가 비개발자의 코드를 주기적으로 리뷰하고, 온디맨드로 코치해 주는 플랫폼.

3. 협업 에이전트

[문제] Slack, Notion, Linear에 흩어진 정보를 사람이 일일이 정리하는 건 불가능하다.
[제품] 대화와 문서를 감지해 Linear의 이니셔티브, 프로젝트 내용을 자동 최신화 하는 에이전트.

4. 로컬 싱크앱

[문제] 에이전트가 클라우드 데이터를 MCP, API로 호출하면 속도가 느리고 비용이 비싸다.
[제품] 클라우드 데이터를 로컬 파일로 실시간 동기화해, 에이전트가 초고속 로컬 RAG로 처리하게 돕는 에이전트의 구글 드라이브.

이때 우리는 1인 1프로젝트 원칙을 유지하려 하고 있다. 작년 1년간 프로덕트 개발팀 (PM-디자이너-개발자)를 운영하며 느낀 것은

맥락의 분절과
협업을 위한 중간 과정에서 오는 시간 소요
(1/N으로) 오너십이 옅어지는 문제

때문에 AI를 도입해도 개발 속도가 빨라지지 않았다. 이 세 가지 문제를 1인 1프로젝트 원칙으로 해결하려 한다.

맺음말: 병목에서 관리자로 전환할 때

우리가 생각하는 AX의 핵심은 조직의 AX가 성공적이기 위해서 팀의 생산성 복리 엔진이 필요하다, 그리고 임직원은 클로드 코드와 같은 AI 에이전트를 써서 일해야 한다 – 는 것이다.

왜냐하면, 사람이 사람과 직접 협업하기보다, 사람이 에이전트와 협업하고, 에이전트가 사람 대신 학습하고 협력할 수 있게 하여, 협업과 소통에서 사람이라는 병목을 최소화 해야 조직의 생산성이 기하급수적으로 향상되기 때문이다.

사람이 병목이라 최소화되어야 하는 것이 처음에는 슬픈 일이라 생각했다.

하지만, 이것은 사람이 실무자들 사이에서 같이 일하려 하지 말고, 이제 그들에게 비전을 심어주고 중간에 업무를 돌봐주는 관리자의 역할로 전환해야 한다는 뜻이기도 하다.

그리고 그런 전환을 못하면 경쟁력을 가지기 어렵다.

지니파이는 구성원들 모두가 AI 시대에 맞는 인재로 전환하는데 성공해서 우리 스스로 정의한 AX의 첫 번째 증거가 되고 싶다.