소개
최초에 ... 비싼 유료 강의 URL을 넣으면 무료 강의를 딥리서치로 만들어 주는 바이브코딩으로 모바일앱을 만들고자 했습니다. 하지만, 이미 스타트업을 운영하면서, 정말 중요한 일에 집중하고 싶었고, 그와 동시에 우리 조직이 AI 전환이 잘 되게 해야 하기 때문에, 아쉽게도 모바일앱을 만드는 사이드 프로젝트는 포기했습니다.
하지만, 저는 이번 바이브코딩 스터디에 참여하면서 이런 의문이 가득했습니다. 바이브코딩을 하는 분들은 한 달에 풀버전 SaaS 하나 만든다고도 하고, 90분만에 모바일 앱도 하나 뚝딱 만든다고 했습니다. 그런데, 우리 개발팀(파트타임 디자이너 1명 + 개발자 3명)은 제가 생각하기에 간단한 데스크탑앱을 만드는데 이렇게 시간이 걸리는 걸까요???
저희 개발팀이 10x 더 빨라질 방법이 바이브코딩에 없는 걸까요?
이 고민을 우리 개발팀과 대화하고, 다양한 해외 사례들로부터 답을 구해보았습니다.
1. 지피터스의 바이브코딩
지피터스는 매주 AI 워크샵 시간이 있어서, 개발팀과 AI 도입에 대해서 자연스레 얘기를 많이 나누게 됩니다. 현재 클로드 코드, 커서, 코드 래빗을 주로 쓰시고 있었어요. 디자인과 개발의 협업은 지금은 MVP 단계여서 아주 엄밀히 디자인을 하고 그걸 프론트 개발자에게 핸드오프해서 픽셀단위로 정밀한 프론트를 만들지는 않고 있어서, 전통적인 방법을 따르고 있진 않았습니다.
https://youtu.be/qXhSN8gqIfM?si=CG1vAdqfHcIEsjS2
<지피터스 팀이 만들고 있는 AI 튜터, 로나>
저희 개발자분들도 이제 90% 이상 코드를 AI가 작성해 주고 있다고 합니다! 이는 Anthropic의 개발팀과 거의 맞먹는 수준입니다. 그런데, 왜 제가 체감하는 개발 속도는 빠르지 않은 걸까요??
2. 정체 구간: 사람이 리뷰하는 시간
바이브 코딩의 경우, 1인이 혼자 하는 경우가 대부분인데요, 이 경우는 사실 코드의 지속 가능성에 대해서 큰 고민없이 진행하게 됩니다. 그래서 실제 프로덕션 코드베이스를 만들고 유지 보수 개선해야 하는 입자에서는
테스트 코드의 작성. Unit test coverage 일정 수준 유지
확장 가능한 아키텍처의 설계, 그 근간을 이루는 코드 작성
에 많은 시간을 투자 하시더라구요.
그리고, 무엇보다, 개발자 입장에서 내가 이해할 수 있고 나중에 수정해야 하는 거대한 코드 베이스를 만들어 가기 위해서는 바이브코딩으로 생성된 코드를 읽고 이해하고, PR 보내서 동료의 리뷰도 받아야했습니다.
사실, 코드 작성량은 엄청 늘었지만, 코드 리뷰를 하루의 50% 이상의 시간을 쓰시기도 한다고 했어요.
이 얘기는 Anthropic CPO이자 Instagram 창업가인 Mike Krieger도 동일한 얘기를 했습니다. 과거는 프로덕트의 아이디어 결정하고, 개발하고, 배포하는데 있어 서 개발이 가장 정체 구간이었었는데요, 이제는 의사 결정을 하는 부분과 (AI로 빠르게 생성된 것들 - 디자인, 코드 등을) 리뷰하는 것이 정체 구간이 되었다고 합니다!
https://youtu.be/DKrBGOFs0GY?si=oKKVA5Kg8FAjtf3g&t=921
비슷한 얘기를 딥러닝의 선구자인 Andrew Ng 교수도 생성 AI 시대에 많은 스타트업들을 도와주면서 비슷한 것을 겪고 아래와 같은 얘기를 하셨더라구요.
엔지니어링이 시간이 걸리는 것이 아니라, 사람이 이를 평가하고 리뷰하는데 더 시간이 많이 걸린다, 그래서 (스타트업에서는) 엔지니어 수보다는 PM의 수가 더 많이 필요하다.
[출처: Bilawal Sidhu의 x.com 트윗]
국내에서도 캐시슬라이드를 공동 창업하였고, 현재는 원지랩스 대표를 하고 있는 곽근봉 대표도 같은 얘기를 했습니다. AI를 활용하면서, 전체 프로덕트 팀의 정체 구간이 본인이 되고 있다고요. 디자인과 엔지니어링은 빠르게 진행되는데, 본인이 의사 결정을 내려 줘야 하는 것이 점점 많아지고 그게 정체 구간이 되고 있다고 하더라구요.
결국 우리 팀이 더 빠르게 프로덕트를 개발하기 위해서는 현재 정체 구간이 되고 있는 코드 리뷰 시간을 혁신적으로 줄일 수 있어야 할 것 같아요. 이미 이를 위해서 Code Rabbit을 쓰고 있지만, 그래도 여전히 많은 시간을 코드 리뷰에 쓰고 있습니다.
이런 경우는 마치 AI 모델의 성능을 개선하기 위해서, RLHF (Reinforcement Learning with Human Feedback, 사람 피드백을 사용하는 강화 학습)을 쓰는 것과 비슷합니다.
AI 모델이 답을 내어 놓을 때, 그걸 사람이 리뷰하고 평가하며 피드백을 제공해서 모델의 성능을 높이는 거죠. 요즘은 추론 모델의 성능이 올라가면서, RLAIF (RL with AI Feedback, AI 피드백을 사용하는 강화 학습)을 사용합다고 합니다. 즉, 피드백을 다른 LLM이 해 주는 거죠. 우리도 개발팀의 속도를 높이기 위해서, 우리 팀의 코드베이스에 대해서 PR이 날라왔을 때 높은 정확도로 코드 리뷰를 해 주는 LLM을 별도로 포스트 트레이닝해야 하는 건가? 하는 생각이 들었습니다.
Shopify가 내부적으로 개발한 Roast라는 프레임워크를 도입하는 것도 도움이 될 것 같습니다.
Roast는 Flaky test와 낮은 unit test 커버리지를 높이기 위해서 처음 만들어진 개발자용 AI 워크플로 프레임워크인데요, 간단히 얘기하자면, AI에게 일을 시킬 때, AI 기능을 써야 하는 부분과 코드로 해야 할 부분을 명시적으로 알려줘서, AI가 복잡한 워크플로도 잘 동작할 수 있게, 그리고 잘 반복할 수 있게 돕는 것입니다.
AI는 본인이 낸 답변이 맞는지 틀린지 확인할 수 있을 때 (verifiable), 동작을 더 잘 하기 때문에, Roast로 테스크 코드를 더 많이 작성하고 관리할 수 있어질수록 개발자의 코드 리뷰 부담도 줄 수 있지 않을까 싶어요.
이 문제를 해결하는 것은 좀 더 리서치와 실습이 필요한 것 같아요.
3. 파편화된 바이브 코딩
제가 하도 닥달을 해 대니까, 개발팀분들이 개발에 AI를 잘 활용하는 방법을 공유하고, 프로세스를 개선하기 위해서 개발자 워크샵을 따로 가지기로 하셨습니다. 지금도 이 워크샵은 진행중인 상태인데요, 이 워크샵 전에 우리 개발팀의 현황에 대해 하나 깨달았습니다.
개발자 세 분이 다른 IDE, AI 개발도구를 쓰고 계셨어요
프론트엔드 개발자 - Claude Code, NeoVim
백엔드 개발자 - Cursor + Gemini Pro 2.5
데이터/백엔드 엔지니어 - Cursor + Claude Sonnet/Opus 4
Code Rabbit은 공통적으로 쓰고 계셨으나, 쓰는 AI 코딩 에이전트 툴이 달랐습니다.
물론 이렇게 다른 에이전트를 쓸 수도 있습니다.
하지만, 개발을 위해서 컨 텍스트 관리하는 것이 다른게 문제였습니다. 이런 경우, 우리가 공통으로 개발하려고 하는 프로덕트에 대한 일관되고 계속 개선되는 컨텍스트를 AI 개발도구에게 전달하기 어려우니까요. 또한, 개발팀의 생각도 정확히 일치되었는지 확인도 안될 수 있고요 (저희는 PRD, TRD를 매우 상세히 쓰고 개발을 시작하지 않았거든요).
https://youtu.be/HtzkfjEH-GU?si=DQgYAcP_KSS6WX3G
그런데 이런 문제는 저희만의 문제는 아니었습니다.
LaunchDarkly 라는 회사에서는 100명이 넘는 개발자들이 기업용 SaaS를 개발하고 있는데요, 올 초부터 본격적으로 바이브코딩을 회사에 도입하기 시작했다고 합니다. 수 많은 개발자 분들이 함께 협업하기 위해서는 이런 컨텍스트를 같이 공유하는 것이 필요하고, 이를 위해서 AI 코딩 에이전트, IDE와 무관하게 컨텍스트를 관리하는 방식을 도입했더라구요.
개발에 필요한 컨텍스트, 규칙 (룰) 등을 별도의 .agent 폴더에 파일로 만들어 두고, 각 AI 코딩 에이전트에게 지침을 주는 .md 파일들은 이런 .agent 폴더의 파일들을 가리키게 되어 있었어요. 마치 C 포인터처럼요. 이렇게 함으로써, 어떤 AI 코딩 툴을 쓰던 간에 모든 개발자들이 동일한 컨텍스트, 규칙을 가지고 바이브 코딩을 할 수가 있게 되었더라구요.
그리고, 또 하나의 팁은 AI 코딩 에이전트가 원하는 결과를 내지 못할 때는 직접 코드를 수정을 하기 보다, 이 컨텍스트 및 룰 파일의 내용을 수정해서 동일한 일을 시켜도 원하는 결과가 나올 수 있도록 함께 이 컨텍스트와 룰 파일을 계속 개선해 나가는 것이 인상 깊었습니다.
이 사례를 보면서 가장 크게 느낀 것은 혼자 AI를 활용할 때와, 여러 사람이 팀으로 일할 때의 AI의 활용 방법이 달라야 하고, 그건 마치 혼자 공부하다가 사회로 나가서 팀으로 협업하는 것을 배우는 것과 유사하단 생각이 들었습니다.
4. MCP를 사용한 다른 직무와의 협업
그러면 같은 개발자가 아니라, 다른 직무, 예를 들면 저희 팀의 디자이너와 프론트 개발자분이 협업하실때는 AI가 어떻게 쓰일 수 있을까 -- 하는 생각이 들었는데요, 예전에 원지랩스 곽근봉 대표가 이런 워크플로를 설명해 주셨어요.
PM이 Visily와 같은 디자이너가 아닌 사람들을 위한 디자인 툴로 프로토타입을 디자인
이를 디자이너가 shadcn 과 같은 이미 만들어져 있고 코드가 매핑되어 있는 디자인 라이브러리를 사용해서 Figma에서 디자인으로 전환
이를 프론트엔드 개발자가 받아서 코드로 매핑하고 개발
저는 이걸 처음 접했을 때, 아 이런식으로 정말 빠르게 할 수 있겠구나 생각이 들었습니다.
그런데 이번에 Figma Live에서 Anthropic이 Figma MCP를 활용하는 방법에 대해서 소개를 해 주는 것을 보고, MCP를 사용하면 다른 직무간의 협업이 이렇게 근본적으로 바뀌겠구나 하고 놀랬어요.
https://www.youtube.com/live/x2LGggL6BNI?si=mIBFsw5Qlffjm4oD&t=1675
디자이너가 Figma MCP와 Claude Code를 사용해서, 소소한 디자인 변화 등은 직접 코드 베이스를 수정하더라구요. 그냥 스타트업이 아니라, 2천만 MAU의 Claude AI를 운영하는 Anthropic에서 이런식으로 접근 하는 것이 정말 놀라웠습니다.
피그마에서 디자인 컴포넌트를 수정합니다
피그마의 Dev Mode로 들어가서 해당 컴포넌트를 선택합니다
Claude Code를 실행해서, 수정하고 싶은 내용을 자연어로 명령합니다.
그러면, 피그마가 디자인 컴포넌트에 관한 자료를 MCP를 통해서 Claude Code에게 전달하고, 이를 바탕으로 Claude Code가 해당 코드를 수정합니다.
최종 수정된 코드는 PR을 보내고, 사람 개발자가 리뷰한 뒤에 머지됩니다
물론 이를 위한 사전 설정과 디자인 시스템에 대한 컨텍스트 .md 파일 등을 만들어 가는 것이 필요하겠지만, 디자이너가 이렇게 바로 할 수 있다는 것이 놀라웠어요. 실제 이 일을 하고 있는 Meagan Choi 디자이너는 개발을 몰라서 Claude Code랑 대화하면서 필요한 최소 지식은 습득하였다고 하네요.
새로 만드는 소프트웨어의 디자인을 AI와 함께 바꿔가는 것은 이제 놀랍지 않은데요, Anthropic과 같은 큰 코드 베이스를 다루는 곳에서 디자이너가 이미 만들어진 프로덕트의 디자인을 직접 수정하는 것은 큰 영감을 주었어요. 이때 전달해야 하는 컨텍스트를 MCP가 거의 다 전달해주게 되면서 디자이너의 마음이 전달된 코드 생성이 가능해 졌습니다.
이런 MCP의 중요성은 Shopify의 내부 AI 전환에서도 충분히 증명된 것 같습니다.
Shopify는 내부의 모든 데이터 - 슬랙, 세일즈포스, 지라, 사내 문서등의 데이터를 MCP로 접근할 수 있는 인프라를 구축했습니다. 그로 인해서, 과거의 모든 RFP (Request for Proposal, 대기업의 외주 모집 공고)를 참고해서 RFP 요구 사항에 한 방에 답변 사항을 만들기, 오늘 내가 해야 할 업무의 우선 순위를 정해주는 대시보드 구축, 매주 프로젝트 업데이트를 써 주는 AI 등으로 비개발자 직무의 사람들은 스스로 본인 업무에 필요한 툴을 개발해 쓰기 사작했다고 합니다. 이메일, 슬랙도 보지 않고, 그냥 Cursor에서 모든 작업을 처리하는 분이 있다고도 하네요.
이제 우리가 팀으로 제품을 만들 때는 이러한 서로의 업무 영역의 근처에서 AI가 해 줄 수 있는 일은 꼭 그 업무 담당자가 아니더라도 진행할 수 있게 되는 것 같습니다. 그리고,
그걸 서로 더 잘 해줄 수 있는 팀원들로 구성되어 있고,
그런 팀원들이 공통의 컨텍스트 관리가 잘 되어 있으며,
직무간 맥락 전달이 효율적인 or 사내 모든 데이터 접근이 가능한 MCP가 구축되어 있다면,
다른 팀에 비해서 더 빠르게 훨씬 빠른 속도를 낼 수 있을 것 같아요. 왜냐면 실제 디자인에서 조그만 수정을 하는 것이 개발에 걸리는 시간이 많아서가 아니라, 맥락을 전달하기 위한 시간, 그리고 개발자가 또 시간을 내야 하는 것때문에 미뤄지는 것때문에 느려지니까요.
디자이너가 직접 개발까지 할 수 있다면 디자인의 개선 속도는 정말 빨라지겠죠.
5. 개발팀의 협업 방식이 비개발팀의 미래
지금의 AI가 가장 잘 하는 영역 중 하나는 코딩입니다. 그렇기 때문에, 개발쪽이 AI 활용이 가장 빠르게 도입되고 있는 분야 중 하나가 되고 있다고 생각해요. 그렇기 때문에, 개발팀이 AI를 활용하기 위해서 협업하는 방식 그리고 AI 코딩툴의 발전하는 방향이 결국 비개발자들이 조직 단위에서 AI를 잘 활용할 수 있는 방법을 암시하고 있다고 생각합니다.
(1) 먼저 AI 툴의 관점에서 Claude Code를 살펴볼만 합니다.
가장 인기 있는 AI 코딩 툴이 가장 인기 있을 비개발자용 AI 툴이 뭐가 될지 어느 정도는 보여줍니다.
Anthropic의 법률팀, 재무팀은 Claude Code를 업무에 활용하고 있다고 합니다. 물론 코딩을 위한 것은 아니구요. 원하는 문서를 정리하고, 데이터를 수집-정리-분석하는데 Claude Code를 쓰고 있다고 하네요.
Dan Shipper의 10명 남짓되는 AI 프로덕트 팀의 운영 방법인데요, 여기서도 Claude Code가 비개발 업무에 정말 많이 쓰인다고 합니다. 심지어 Dan Shipper는 Claude Code가 비개발자용 AI 도구로써 가장 과소 평가된 도구라고 하네요. 그 사람의 팀의 사용 케이스는
대규모 데이터셋을 분석
글 쓰기, 글 스타일 따라하기, 글 평가하기
에 집중되어 있는데요, 챗GPT에게 한 방에 결과를 요구하는 것이 아니라, Claude Code가 해당 업무를 잘 하기 위해서 세부 업무를 기획하고 하나씩 해 가면서 내는 결과의 품질은 매우 높다고 합니다. 에이젠틱(Agentic)하게 다양한 일을 높은 수준의 품질로 시킬수 있는 것 같아요.
https://youtu.be/crMrVozp_h8?si=3vSTOYH8bxBC-0pJ
Claude Code는 로컬에 있는 텍스트 파일 (소스 파일)에 대해서 자유롭게 접근해서 읽고, 이해하고, 수정할 수 있으므로 자연스레 로컬에 .md 파일을 저장하는 Obsidian 노트앱과도 연계되어 쓰일 수 있습니다. 로컬 .md 파일로 노트를 저장하는 툴과 연계하면, Claude Code 특유의
자율주행 업무 수행 능력(에이젠틱 능력)과
긴 컨텍스트 윈도 크기,
전체 로컬 파일들을 RAG 하는 기능,
MCP 연동 기능,
여러 서브 에이전트를 spin-up 해서 병렬처리를 할 수 있는 능력,
일을 처리할 때 필요한 코드를 직접 짜서 저장해두고 반복해서 쓰는 능력
덕분에 통합적인 지식 업무 처리가 가능해집니다. 콘텐츠 크리에이터나 복잡한 문서 작성이 잦은 분들이 요긴하게 쓸 수 있는 것 같아요 (참고 영상 - How to 10x Your Notes - Obsidian + Claude Code).
또한, 앞서 언급한 Roast에서 개발자의 복잡한 업무를 일부는 코드 실행으로 일부는 AI가 판단해서 하는 일로 워크플로를 짤 수 있는 것처럼, 비개발자의 복잡한 업무도 코드 실행할 부분, AI가 지능으로 판단해야 하는 부분을 조합한 자동화를 할 수 있을 것 같습니다.
이처럼 개발자들이 잘 쓰는 Claude Code는 앞으로 비개발팀에서 유용하게 쓰게 될, 하지만 아직 나오지 않은 툴의 방향성을 보여줍니다. 그리고 그런 툴에 미리 적응해서 경쟁력을 얻으려면, 비개발자도 Anthropic의 Meagan Choi 디자이너처럼 Claude Code를 써야 할것 같습니다.
(물론 6~12개월 내에 Claude Code의 비개발자용 인터페이스가 Anthropic와 다른 회사에서 나올 것 같기는 합니다)
(2) 협업 방식에서는 개발팀의 컨텍스트 관리 및 규칙 관리가 비개발팀에게도 핵심이 될 것으로 보여요
원지랩스의 곽근봉 대표는 AI를 잘 쓰는 팀은 신입 사원의 온보딩 프로세스와 문서가 잘 된 회사라고 했었습니다. 왜냐하면, 자연어, 이미지 등으로 상황을 이해하고 업무를 수행할 수 있는 AI에게도 그런 온보딩 프로세스와 문서들이 해야 하는 일에 대한 컨텍스트를 정확히 알 수 있게 해 주니까요.
보통 스타트업에서는 노션으로 문서를 관리하는데요, 노션의 위키 기능에도 불구하고, 회사의 문서들이 회사의 최신 상황을 100% 반영하고 있는 경우는 거의 없다고 생각합니다. 그런 컨텍스트가 슬랙과, 리니어와, 이메일과, 회의의 구두 대화에 흩어져 있는 경우가 대부분인 것 같습니다.
하지만, 생성 AI가 가장 잘 하는 것중에 하나가 문서를 업데이트 하는 것입니다.
LaunchDarkly는 새로운 PR이 있을 때 마다, GitHub Action을 통해서 해당 PR에 관련된 개발 문서를 Devin을 시켜서 업데이트 한다고 합니다.
비개발팀에도 컨텍스트 변화가 되는 이벤트가 있을 때 이를 자동으로 감지해서, 이를 바탕으로 전체 컨텍스트를 관리하고 있는 문서가 자동 업데이트 되는 것이 필요하게 될 것입니다.
그리고 하나의 툴을 쓰다가 그 업무를 마무리하기 위해서 다른 툴을 연이어 쓰게 되는 경우, MCP를 통해서 하던 업무의 컨텍스트가 자연스레 업무 흐름따라서 흐를 수 있게 되어야 합니다. 이를 위해서 사내툴, 외부 툴의 MCP 서버를 만들고 관리하는 것이 필요할 것 같아요.
아직은 이런 컨텍스트 관리를 비개발팀이 쉽게 할 수 있는 툴이 나와있지 않습니다. 그래서, n8n과 같은 자동화 툴과 MCP를 사용해서, 컨텍스트 문서들을 업데이트 할 이벤트를 감지하고, 자동 수정하고, 그런 이벤트를 발생시킨 사람에게 리뷰를 요청하는 자동화가 필요할 것 같아요. 아니면, Claude Code를 챗GPT처럼 사용하면서, 로컬 .md 파일로 컨텍스트를 관리하고, 노션 말고, Obsidian 과 같은 노트앱을 쓰는 것도 방법일 것 같아요 (참고로 Obsidian은 개인 지식 관리용이라 협업 기능이 없습니다).
생각만해도 정말 일이 많을 것 같네요.
6. 조직의 AI 전환의 시작 - AI 자동화 엔지니어
이렇게 개인이 아닌 조직의 AI 전환 방법에 대해서 대략적인 접근 방법을 알았다고 할지라도, AI 자동화 엔지니어가 없다면 AI 전환은 어렵습니다.
저희 지피터스의 경우도 구성원 개인은 AI 활용에 정말 뛰어납니다. 17개 기수의 AI 스터디 동안 1만여개 가까운 AI 활용 사례들을 지켜보았고, 기업 내부의 AI 활용 사례들도 기업 교육으로 보아왔습니다. 하지만, 현재 지피터스가 AI 활용을 가장 잘하는 조직인가? 라고 스스로 생각해보면, 아니라는 확신이 듭니다.
그리고 그걸 뼈져리게 느끼게된 일이 있었습니다.
지피터스 스터디를 운영하는 다혜님은 전자공학 전공자에다가 AI 활용하는 것, 새로운 것을 배우는 것에 정말 열정이 넘치는 분입니다. 하지만, 근무해온 지난 1년 반 동안에 이상하게도 스터디 운영 업무는 계속 수작업이 대부분이고 AI 덕분에 자동화가 가능해 보이는 것들이 눈에 많이 띄었지만 자동화되지 않았습니다.
저는 이게 다혜님의 성격 때문인가, 체계적으로 자동화를 하기 힘든 아직 업무 경험이 부족한 것 때문인가 생각을 했어요.
하지만 두 달전에 스터디 운영을 도와줄 분을 외부에서 급히 수혈하면서 모든게 분명해졌습니다. 이 외부의 파트타임분 또한 지피터스 커뮤니티에 대한 사랑이 넘치는 분이라 정말 많은 운영 업무를 계속 도와주셨는데요, 그 덕분에 다혜님은 드디어 자동화를 진행할 시간이 생긴 것 같았습니다. 정말 무서운 속도로 회사의 업무들이 자동화 되기 시작했습니다. 운영을 도와주시는 분도 AI 활용한 자동화에는 일가견이 있는 분이라 두 분이서 같이 많은 운영 부분을 자동화 하시기 시작하더라구요.
조직의 구성원들이 AI 리터러시가 높아졌다고 할지라도, 당장에는 불난집 불끄러 가야 하는 급한 일이 매일 쏟아집니다. 그 상황에서 본인 업무에 AI를 도입하고 워크플로를 자동화 하는 것에 시간을 내기가 쉽지 않습니다. 특히, 조직의 협업을 위한 컨텍스트 문서를 관리하는 프로세스를 세우고, 최신으로 유지하기 위한 자동화를 하고, 수작업으로 하던 것을 하나씩 자동화 하기 위한 시간은 생각보다 많이 걸리기 때문에 더더욱 그러합니다.
그래서 조직은 AI 자동화 엔지니어라는 포지션을 먼저 채용해야, 조직의 AI 전환이 시작됩니다.
AI 자동화 엔지니어 (AI Automation Engineer)는 누가 처음 정의한 포지션인지는 모르겠지만, Zapier의 CEO인 Wade Foster의 위 트윗에서 명확한 정의와 하는 일을 알 수 있습니다. 팀의 업무를 AI, Zapier, Make, n8n, Airtable 등의 AI가 탑재된 자동화 툴을 활용해서 자동화하는 업무가 주가 됩니다.
Wade는 심지어 지금 Zapier에서 오픈된 모든 포지션에 AI 자동화 엔지니어는 직무 무관하게 지원할 수 있고 채용하겠다고 할 정도로, 조직에서 이 포지션을 급하게 필요로 하고 있습니다.
소프트웨어 프로덕트 관련 No. 1 콘텐츠의 저자인 Lenny에 따르면, 실리콘 밸리에서도 AI를 팀의 업무에 가장 잘 적용하고 있는 조직은 Every라고 하는데요, 여기의 대표인 Dan Shipper 에 따르면 Head of AI Operation 이라는 포지션이 AI 전환의 가장 필수적인 직무라고 합니다.
의미는 동일합니다. 기존 팀원들이 하는 일이 있습니다. AI 자동화를 도와줄 엔지니어를 채용해야 조직의 AI 전환이 시작됩니다. 이는 개인 팀원이 AI를 얼마나 잘 쓰나와 무관합니다.
그리고 저는 이 포지션이 특히 희소성 높은 인재를 채용해야 하는 회사나, 경험 많은 사람을 채용하기에는 비용 부담이 큰 스타트업에서 더 유용하게 조직에 기여할 수 있다고 생각합니다.
예를 들어, 지피터스의 경우는 대표인 제가 채용을 하고 있습니다만, 부끄럽게도 채용에 충분히 많은 시간을 들이고 있지 못합니다. 하지만, AI 자동화 엔지니어가 조직 내에 있다면, 외부의 채용 전문가를 20%의 시간만 파트타임으로 고용합니다. 그리고, 그 사람이 하는 업무의 80%를 AI 자동화 엔지니어가 자동화 합니다. 그러면, 사람이 해야 하는 20%는 외부 전문가의 도움을 받고 한번 구축한 AI 자동화로 80%의 인건비는 절약할 수 있게 됩니다. 또한 풀타임으로 채용하기 어려운 인재를 20%의 파트타임으로 고용해서 풀타임의 효과를 얻을 수 있게 됩니다.
즉, AI 자동화 엔지니어는 조직의 AI 전환을 도와줄 뿐만 아니라, 조직이 필요한 다양한 전문성을 더 낮은 비용으로 더 쉽게 구인할 수 있게 도와줍니다.
그래서 지피터스도 AI 자동화 엔지니어를 급하게 구인하고 있습니다!
7. 컴파운드 마인드 셋
(1) 복리 엔지니어링
함께 일을 하다보 면, 얻어야 하는 결과 이상으로 일 자체의 과정을 개선해 나가는 사람들이 있습니다.
예를 들면, 본인이 담당한 업무 결과를 문서로 작성하다가 팀의 문서 구조를 정리하는 일도 하는 사람, 사내에서 소프트웨어를 작성하다가 그 소프트웨어 개발을 위해서 필요한 툴에 대한 아이디어가 떠올라서 가볍게 그런 툴을 만드는 개발자 등.
이런 사람들은 AI 시대의 조직에는 큰 영향을 줍니다.
Dan Shipper는 복리 엔지니어링 (Compound Engineering)이라고 이런 업무를 지칭했는데요, 업무를 하면서 다음에 이 업무를 좀 더 쉽고 빠르게 할 수 있도록 여력을 투자하는 것이라고 설명합니다. 마치 이자의 이자가 붙으면서 돈이 빠르게 증가하는 것과 비슷해서 제가 "복리"라는 표현을 써 봤어요.
예를 들면, 개발팀이 PRD (프로덕트 요구 사항 문서), TRD (기술 요구 사항 문서) 등을 작성해야 하는 경우가 많은데요, 이걸 위한 커스텀 GPT를 만들어 두는 것이나, 반복적으로 하게 되는 업무를 Claude Code에서 커스텀 명령어로 만들어 두는 것과 같은 것들이 있습니다.
조직이 이런 복리 엔지이어링의 마인드셋을 가지고, 모두가 이걸 조금씩 실천한다면, 여력으로 만든 하나의 커스텀 GPT나 커스텀 명령어 x 조직원의 수 -- 에 해당하는 생산성의 향상을 기대할 수 있습니다.
(2) 새로운 10x 프로세스, 프로덕트, 아이디어의 발견
여기서 한 발자국 더 나아갈 수도 있어요.
우리가 가장 중요한 일에 집중하는 만큼, 그런 우선 순위 외에 새로운 프로세스나 새로운 프로덕트 등의 새로운 아이디어를 탐색하는 일에 소홀해지기 마련인데요, 만일 새로운 아이디어가 떠 올랐을 때 그걸 해 보는 것을 AI에게 위임할 수 있는 워크플로를 조금씩 만들어 둘 수 있는 것 같아요.
이런 복리 엔지니어링이 지속되면, 과거의 방식으로 우리가 일하기 때문에 나의 해야 할 일에 잘 들어오진 않지만, 성공했을 때 10x, 100x 할 수 있는 새로운 프로세스 및 제품 및 아이디어를 찾아내는 작업들을 더 할 수 있게 됩니다.
저 같은 경우는 가끔 흥미로운 소프트웨어 프로덕트 아이디어가 떠오르곤 합니다. 하지만, 이런 아이디어가 떠 올랐을 때, 이게 정말 좋은 아이디어인지 탐색하는 것은 또 많은 시간이 걸리기 때문에 그냥 노트하고 가끔 지인들과 대화 나누는 정도만 하고 있어요.
하지만, 이런 아이디어를 검증할 대기자 모집 웹사이트를 만들고, Meta 광고를 돌려서 웹사이트의 대기자 전환율을 살펴보며, 어느 정도 수요가 확인되면 빠르게 프로토타입을 만드는 것, 이런 것들을 조금씩 자동화 해서 만들수 있을 것 같습니다. 그러면, 제가 지금 만들고 있는 프로덕트의 주변에서 더 좋은 기회를 발견해서 10x, 100x 할 수 있는 사업 방향을 찾을 수도 있지 않을까 싶었습니다.
AI는 내 업무를 더 가속화하는 것보다, 내가 못하던 것을 가능하게 Zero-to-One 해서 10x, 100x 생산성이 높아지는 것 같습니다.
8. 조직 내 AI 활용 퍼뜨리기
조직이 어떻게 AI 활용을 잘 할 수 있을지 방법을 찾았더라도, 이것을 조직 내에 사람들이 온전히 받아들이게 만드는 것 또한 쉽지 않습니다.
가장 많이 도입하는 방법은 누가 AI를 잘 쓰고 있는지, 그 사례를 매 주간 회의 때 공유하는 것 같아요.
이건 지피터스 AI 스터디를 통해서 저희가 배운 점이기도 합니다. AI로 어디까지 가능한지 이미 관성이 있어서 우리가 우리의 사고를 제한하고 있는 데요, 다른 사람들의 활용 사례를 접하면서 이런 사고의 제약이 깨지고 더 과감한 시도를 해 볼 수 있게 되는 것 같아요. 그래서, 저희 지피터스 운영진도 매주 AI 워크샵이라고 하는 시간을 가지며 AI 활용 사례를 서로 공유하고 있습니다. 해외에서도 Box의 CEO인 Aaron Levie는 사내의 좋은 AI 활용 사례를 회사 내에서 매주 공유하고 있다고 하네요.
또 다른 방법은 명확한 지침을 구성원들에게 전달하는 것입니다.
Microsoft CPO는 앞으로 PM들은 어떤 기능을 개발하고자 한다고 했을 때, AI 프로토타입이 준비되지 않았다면, 그런 얘기를 입 밖으로 꺼내지도 말라고 합니다. 시각적으로 개발하고자 하는 기능을 보는 것은 정말 많은 정보를 한 번에 팀원들과 공유할 수 있는데, 이런 프로토타이핑의 비용이 이젠 정말 극적으로 낮아져서 공짜에 가깝기 때문인 것 같아요.
그리고, 업무 평가에 도입하면, AI 활용은 조직 내에서 자연히 늘어간다고 하네요.
Shopify의 경우는 업무 평가를 할 때, 주변 사람들이 얼마나 이 사람을 AI-네이티브로 생각하는지를 평가 지표에 넣었다고 합니다. 또한, 사내에서는 토큰을 가장 많이 쓴 사람이 누군지 리더보드도 만들었다고 해요. 저희 지피터스는 지금 논의 중이지만, 한 달에 한번씩 가장 AI 활용에 있어서 임팩트 있는 기여를 한 분을 뽑아서 이 사람에게 성과급을 추가로 지급하기도 했습니다.
개발자의 짝 코딩 (Pair programming)처럼, 함께 AI를 활용하는 방법을 만들어 가는 시간을 가지는 것도 큰 도움이 될 것 같아요.
Shopify에서 이미 짝 코딩을 많이 한 구성원이 회사 전체에 주는 임팩트가 그렇지 않은 구성원 대비 월등하다는 것을 오랜 기간동안 추적하고 검증해 왔다고 합니다. 이런 짝 코딩은 다른 사람이 어떻게 개발을 하는지 그 세세한 맥락을 들어볼 수 있게 하고, 남에게 설명을 하면서 나 스스로 개선점을 발견하게 합니다. 또한 노하우가 전달되기도 하고요.
<지피터스의 n8n 밤샘 해보기 행사 - 오전 11시부터 시작된 모각AI 이후 새벽 1시반까지 자리를 지키시는 분들>
AI 시대에는 비개발자 직군의 분들도 이런 짝AI가 큰 도움이 될 것 같아요.
지피터스 AI 스터디 내에서는 모각AI라는 주말 활동이 있습니다. 모여서 각자 AI 해 보는 모임인데요, 모임을 주관하는 분의 간단한 실습 세션이 있긴 하지만, 그 활용에 그치지 않고, 사람들이 모여서 함께 각자 본인의 AI 활용 방법을 만들어 가는 시간이에요. 이 시간을 짝 코딩처럼 2명씩 짝을 지어 각자가 하려는 것을 옆 사람에게 소개하면서 해 보고, 피드백도 받고 자기 점검도 하고 한다면, Shopify가 짝 코딩에서 임팩트를 얻었던 것과 같은 효과가 있을 것 같습니다. 그리고, 조직 내에서도 이런 짝AI 활동을 정기적으로 진행하게 한다면, AI 활용 방법이 보다 잘 퍼질 수 있을 것 같아요.
9. 조직의 AI 전환 지표
결국 조직의 AI 전환은
조직이 AI를 많이 활용하는가
조직이 하는 일에 대한 컨텍스트가 얼마나 잘 관리되고 활용되고 있는가
AI 활용법을 개선하는 것을 조직의 구성원 모두가 잘 참여하고 있는가
구성원이 얼마나 AI 활용법을 서로 공유하는가
등으로 확인할 수 있을 것 같습니다.
이런 부분을 측정하는 것은 여러 방법이 있겠지만, 아래의 지표들도 포함할 수 있는 것 같아요.
첫 번째 지표는 AI의 사용량을 조직의 토큰 사용량으로 측정하는 것입니다.
Shopify에서는 LibreChat을 도입하고, 이 오픈 소스 프로젝트에 직접 기여하면서 해결하였습니다. LibreChat은 가용한 모든 LLM을 쓸 수 있는 공통의 채팅 인터페이스입니다. 이 앱을 도입하면 모든 AI 활용이 API로 진행되어 임직원 각각이 한 달에 쓰는 Token 양이 정확히 측정됩니다. 또한, OpenAI, Anthropic, Grok 등의 여러 챗봇의 구독료보다 전체적으로 비용 절감도 된다고 하네요.
두 번째로는 사람들이 얼마나 리뷰에 시간을 쓰는가 하는 지표입니다.
AI 시대의 발전이 가속될수록 우리는 지금 개발팀의 업무 방식과 유사한 업무 방식을 가지게 될 것이고, 그렇다면 사람들은 컨텍스트 관리와 AI가 만들어낸 결과물을 리뷰하는데 시간을 많이 쓰게 됩니다. 현재도 컨텍스트 문서를 업데이트 하는 것조차 사람들이 직접 하기보다 AI의 도움을 받고 있는데요, 그러면 결국 하나만 남습니다. 리뷰하는 시간.
즉, 조직이 AI를 잘 활용하고 있느냐는 결국 우리 조직 구성원들이 리뷰를 하는데 시간을 얼마나 쓰고 있느냐로 어느 정도 정확히 파악을 할 수 있을 것입니다.
실무라고 얘기했던 많은 일들 - 문서를 작성하고, 코드를 작성하고, 디자인을 그리고, 마케팅 기획을 하고, ..., 이런 일을 하는 시간보다, 문서를, 코드를, 디자인, 기획안을 리뷰하는 시간이 많아진다는 것은 그 만큼 AI를 잘 활용해서 최종 결과물을 만들고 있다는 것이 됩니다.
결과와 배운 점
지피터스는 궁극적으로 사내 AI 전환을 하고, 그 노하우를 바탕으로 AI 스터디와 기업 교육을 구성해서, 모든 이들이 AI 전환될 수 있는 것을 도우려 하고 있어요. 그래서, 지금의 고민 (즉, 개인이 AI 전환되는 것보다 조직이 AI 전환되려면 어떻게 해야 하는지에 대한 고민)이 정말 시의적절하고 값지다고 생각했습니다.
계속 관련 자료를 찾아보겠지만, 제가 일단 Claude Code를 쓰면서 비개발팀의 업무 방식을 예상해보고, 회사 내의 컨텍스트를 관리할 방법을 만들어 가 보면서 계속 업데이트 하겠습니다.
일단은 지피터스 내에서
[ ] AI 자동화 엔지니어 채용
[ ] Code Rabbit 이상으로 코드 리뷰 시간 줄일 방법을 찾기
[ ] 사내 데이터베이스, Airtable 데이터에 접근하는 MCP 서버 구축
등 이런 것들부터 조금씩 해결해 보려구요.
ps. AI 조직 전환에 진심인 분들을 모아서 별로 스터디를 해 보려 합니다. [email protected]로 연락주세요!