관리자로서 코드를 거의 쓰지 않던 저자가 바이브 코딩과 에이전틱 AI를 활용해 다중 워크스페이스, 컨텍스트 파일, MCP, Coder Tasks로 PR 생산성을 10배까지 끌어올린 여정을 공유합니다.
읽는 데 10분
2025년 9월 11일
엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기
그렇다, 공개 고백. 내 비밀스러운 수치다.
경력 몇 년 만에 매니저가 되었고, 곧 디렉터가 되었다. 20명짜리 팀을 운영하다 보니, 내 시간은 전부 관리에 쓰였고 코딩에는 전혀 쓰이지 않았다.
커리어 내내 “그냥 코드에 뛰어들어” 팀을 돕고 싶었지만, IDE를 열 때마다 노력 대비 효과 비율이 너무 맞지 않았다. 결국 프로젝트를 관리하는 게 더 나았다.
약 4개월 전, 나는 우리 메인 코드베이스에서 전속력으로 바이브 코딩(vibe coding)을 시작했다. 사이드 프로젝트도, 일회성 내부 앱도 아니다. 우리 드론 플릿을 제어하는 실제 코드가 있는 수백만 줄짜리 모노레포에서 바이브 코딩을 시작했다.
첫 두 달은 바이브 코딩이었고, 그 다음 두 달은 에이전틱 AI(agentic AI)에 몰입했다. 코드 제출 기준으로, 지금 나는 Skydio에서 상위 5명의 기여자에 들고, 시간당 최대 10개의 PR을 올린다. 내 코드 변경은 복잡하진 않지만, 가치 있다!
관리자와 디렉터 여러분: 여러분이 생각하는 것보다 훨씬 더 팀의 코드에 기여할 수 있습니다.
이 글의 목적은 바이브 코딩과 에이전틱 AI가 무엇인지, 그리고 내가 Skydio에서 어떻게 적용했는지 설명하는 것이다. 후속 글에서는 여러분 회사에 이 세팅을 어떻게 구축할 수 있는지 다룰 예정이다.
엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기
이건 구글에 더 어울리는 질문이지만, 간단히 답하자.
AI 보조 코딩 / 바이브 코딩은 페어 프로그래밍이다.
Windsurf와 Cursor는 운전석과 관찰자 역할을 자유롭게 오가며 코딩 플로 상태에 들어가도록 돕는다. 운전석일 때는 당신이 코드를 쓰고 AI가 유용한 제안을 해준다. 관찰자일 때는 AI가 변경을 만들고, 당신은 한 줄씩 코드 리뷰만 한다.
에이전틱 AI는 인턴이 하나 있는 것과 비슷하다.
에이전트 모델에서는, 과하게 야심 찬 인턴에게 일을 쪼개 맡긴다. 에이전트에게 더 많은 컨텍스트를 줄수록, 원하는 방식으로 작업을 완수할 가능성이 높아진다. 인턴과 똑같다.
두 가지의 핵심 차이는 다음과 같다.
바이브 코딩은 초 단위로 반복되는 능동적 프로세스다. 에이전틱 AI는 분 단위로 반복되는 수동적 프로세스다.
다음 섹션에서는 0.5배 속도의 바이브 코딩에서 10배 속도의 에이전틱 AI까지 내가 어떻게 올라탔는지 과정을 설명하겠다.
내 시작 목표는 단순했다. 가장 과부하 걸린 팀의 쉬운 티켓 몇 개라도 닫는 데 내가 도움 될 수 있을까?
팀이 내가 크게 도울 수 있다고 한 영역은, 정규 엔지니어의 역량이 꼭 필요하진 않지만 시간을 갉아먹는 사소한 디자인 닛피킹과 UI 버그였다. “이 페이지의 문구를 바꿔라”라든가 “창을 줄이면 이 페이지가 이상하게 보인다” 같은 것들.
그때 나는 고민했다. 더 적극적인 코칭(즉, 마이크로매니징)을 하거나, Jira 큐를 정리(즉, 관리자의 자기만족)하거나, 그냥 내가 직접 버그를 고치는 게 팀에 더 도움이 될까? 버그 잡기를 해보자. 참고로 나는 TypeScript를 모른다(지금도 모른다).
엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기
터미널과 코드에 할당된 공간이 얼마나 큰지 보라. 곧 달라진다.
우리 백로그에는 아무도 시간을 내지 못한 작은 UX 버그가 많았다. AI가 올바른 변경에 도달하려면 여러 번의 시도가 필요했고, 리뷰 이후에도 종종 더 손봐야 했지만, 그래도 나는 티켓을 하나씩 계속 닫아 나갔다.
개발자보다 빨랐나? 아니다.
첫 번째 돌파구: 왜 머신을 1대만 쓰나, 3대를 쓰면 되는데?
어느 순간, 겉보기에는 아주 간단해 보였지만 Relay의 깊은 심연에 있는 끔찍한 버그에 갇혔다. 으악. 나는 Redux와 Relay 차이도 설명 못하는데, 이걸 어떻게 풀지. AI는 나쁜 루프에 갇혔다.
엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기
A -> B -> A -> B -> A -> B -> A -> B로 한 시간 넘게.
나는 쉽게 항복하는 사람이 아니다. 이 버그는 내가 고친다. 대화가 한 시간 넘게 이어지자 AI는 희망이 없어 보였다. 컨텍스트가 너무 깊어 새로운 접근을 시도하려 하지 않았다. 그래서 미친 생각을 했다. 이러면 어떨까:
엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기
각 워크스페이스를 번갈아 테스트하고 피드백을 주며, 그중 하나가 버그를 고치길 바랐다. 낙관으로 버그를 DDoS하듯 두들겼다. 코드는 신경 쓰지 않았다. 중요한 건 버그를 고치는 것뿐. 버그만 고치면, 나중에 코드는 정리하면 된다고 생각했다. 한 시간 후, 두 번째 워크스페이스가 해법을 찾아냈고, 뚝딱: 코드를 제출하고 머지했다!
이때부터 내 개발 방식이 달라졌다. AI 3개로 어려운 문제 1개를 풀 수 있다면, 쉬운 문제 3개에 AI 3개를 병렬로 붙일 수도 있겠지. 이제 버그를 쓸어 담기 시작했고, 속도는 3배로 뛰었다.
개발자보다 빨랐나? 주니어 엔지니어보다 빨랐다.
이제 티켓을 마구 처리한다. 디자인 총책에게 UI 엉성함(jank) 리스트를 계속 써 달라고 하고, 그가 적어내려가는 속도보다 더 빨리 처리했다. 한 번에 Windsurf를 3개 켜두고 테스트하고, 피드백 주고, 다음으로 넘어갔다. 특정 Windsurf가 막히면, 같은 이슈를 다음 Windsurf에 던져서 두세 배로 밀어붙였다. 다음 과제는 변경/테스트 사이클의 시간을 줄이는 것이었다. AI가 더 빨리 정답에 가까운 변경을 하게 만들어야 했다.
소개: 컨텍스트 파일(예: Windsurf Rules)
Skydio는 하나의 거대한 모노레포로 일한다. 이건 코드베이스라기보다 지난 10년의 스카이디오 역사가 켜켜이 쌓인 고고학 유적지에 가깝다. 절반만 끝난 마이그레이션, 고대 코드, 그리고 인턴들이 남긴 안티패턴과 오정보가 레포 곳곳에 흩어져 있다. AI가 내 입력과 다른 코드만을 컨텍스트로 삼으면, 아주 옛날 인턴 코드에 패턴 매칭해버릴 수 있었다. 최악.
이 작가의 업데이트를 받으려면 Medium에 무료로 가입하세요.
더 나은 결과를 얻으려면, AI에 우리 팀의 코딩 베스트 프랙티스와 피해야 할 안티패턴을 먹여야 했다. 푸시 전에 유닛 테스트를 돌릴 때 어떤 커맨드를 써야 하는지도 알려줘야 했다. 내게는 이게 Windsurf Rules였다. .windsurf/rules/my-practices.md에 넣는 마크다운 파일 묶음일 뿐이다. 의외로 아주 간단하다.
룰은 시스템에 자동 주입되는 사전 저장 프롬프트라고 생각하면 된다. 예를 들어 프롬프트가 프론트엔드 앱의 TypeScript를 수정하는 거라면, 대응하는 .windsurf/rules/typescript-best-practices.md가 있을 수 있다. 이 베스트 프랙티스 가이드의 내용은 프롬프트 뒤에 사실상 자동으로 삽입된다.
내가 이 파일을 쓸 때의 접근은 이랬다:
엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기
컨텍스트를 몇 번이고 반복 개선하는 게 효과의 비결이다
본질적으로, 티켓을 해결하면서 동시에 AI를 구동하는 컨텍스트도 손봤다. AI가 문제를 푸는 데 애먹으면, 끝나고 나서 무엇이 최종 해법의 열쇠였는지 AI에게 물었다. 그런 다음 컨텍스트 파일을 수정하고, 새 워크스페이스(백지 상태)를 시작해 같은 프롬프트를 다시 줬다. 이번엔 AI가 쉽게 풀면, 컨텍스트 파일 변경이 의도대로 먹힌 것이다.
💡 관리자들을 위한 핵심 인사이트: AI는 당신의 문제를 자동으로 해결해주지 않는다. 도구에 투자해야 한다.
이쯤 되니 내가 티켓을 닫는 속도가 빨라져 다른 개발자들이 눈치채기 시작했고, AI 워크플로에 대해 더 많은 질문을 해왔다.
개발자보다 빨랐나? 단순 작업에서는 시니어 엔지니어보다 빨랐다.
생산성을 다시 3배 올리려면, 가장 느린 요소를 빼야 했다. 바로 나다. 나는 한 번에 Windsurf 3개 정도를 유지할 수 있었지만, 주의력을 다 쏟아야 했다. 긴 작업을 시키면, 몇 분마다 다음 단계를 확인하느라 Windsurf를 계속 열어둬야 했다. 다음을 자동화해야 했다.
소개: Coder Tasks
엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기
Coder Tasks는 에이전틱 AI를 위한 새로운 진입점이다
Coder Tasks는 “프롬프트” → AI 에이전트의 작업 실행까지 흐름을 자동화하는 데 집중된 자동화 워크스페이스다. 코드를 GitHub에 자동 푸시하도록 설정해두면, 여러 작업을 병렬로 돌리고 PR이 리뷰 준비가 될 때까지 다시 관여하지 않아도 된다.
엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기
이 모델에서는 단계 사이를 기다리며 시간을 낭비하지 않는다.
작업에 몇 시간이 걸려도 상관없다. AI가 변경을 마칠 때까지 나는 적극적으로 개입하지 않기 때문이다. 또한, 프롬프트를 쓰고 프리뷰를 테스트하는 데는 기술적 역량이 꼭 필요하지 않다. 즉,
에이전틱 AI는 모든 역할의 모두가 제품 개선에 직접 기여하게 만든다.
디자이너는 색상과 포맷팅을 고칠 수 있다. 프로덕트 매니저는 카피를 고칠 수 있다. 그리고 Skydio의 비행 테스트 팀은 발견한 버그와 함께 바로 수정 PR을 낼 수 있다.
MCP가 퍼즐의 마지막 조각이다
MCP는 “AI 통합”을 그럴듯하게 부르는 말일 뿐이고, “MCP”는 Anthropic이 세상에 채택시키는 데 성공한 기술 표준이다. 덕분에 GitHub(회사)가 모든 AI 에이전트에 공통으로 작동하는 단일 통합을 만들 수 있다. 내게 엄청난 차이를 만든 MCP 통합은 두 가지였다. 바로 GitHub(이슈와 PR 상호작용)와 Playwright(브라우저 상호작용)다.
엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기
초록색은 기존 워크플로 대비 GitHub와 Playwright MCP가 더해준 가치 영역을 나타낸다.
GitHub MCP를 쓰면, GitHub Issues를 읽을 수 있다. 그러면 프롬프트를 “이 <이슈>를 고치되, <추가 컨텍스트>를 유념하라.”처럼 단순화할 수 있다. 더 중요한 건 PR을 자동으로 만들 수 있다는 점이다. Skydio에서는 긴 CI 체크를 돌릴 수 있고, 동시에 Vercel 프리뷰도 트리거된다. 그래서 Vercel 프리뷰가 뜰 때까지 기다렸다가 그때 다시 관여하면 된다. 내 플로는 이렇게 된다.
이 흐름에서는, 작업 그 자체보다 내가 다음 작업을 생각해내는 능력이 더 큰 병목이 된다! 다만, 다음의 계단식(step-function) 성장을 위해서는 AI가 나 없이도 스스로 더 많이 반복할 수 있게 해야 한다…
Playwright MCP를 쓰면, AI가 여러분의 개발 스택을 포함해 어떤 웹사이트든 탐색할 수 있다! 즉, AI에게 다음을 지시할 수 있다.
이게 얼마나 강력한지 잠시 생각해보자. 피드백 사이클이 내 응답에 의존할 때는, 과부하 없이 동시에 유지할 수 있는 Windsurf가 3개 정도가 한계였다. 하지만 AI가 스스로 반복할 수 있게 되면, 한계는 훨씬 높아진다. AI가 자신의 변경을 검증하는 방법만 알려줄 수 있다면, 나는 수십 개의 동시 태스크를 생성할 수 있다.
에이전틱 AI를 성공시키는 핵심은 인간의 응답을 끼지 않는 피드백 사이클을 만드는 것이다.
여기서 Skydio의 물꼬가 확 트였다. Coder Task에 프롬프트를 던지는 데 필요한 활성화 에너지는 거의 0이다. 나는 한 번에 10개의 태스크를 돌리기 시작했다. 실제 사례를 하나 들자면:
이때가 에이전틱 AI의 전환점이었다. 내가 혼자 밀어붙이는 게 아니라, 이 흐름이 스스로 생명을 얻기 시작했다. 이 글을 쓰는 시점에, 커밋 속도 기준으로 Claude Code는 Skydio에서 두 번째로 빠른 개발자다! 한계는 하늘뿐!
다음 목표: AI가 고급 워크플로를 수행하게 만들기!
끝까지 읽어주신 소수의 여러분, 고맙다! 나는 이 여정이 자랑스럽다. 에이전틱 AI로 PR을 대량 생산하자는 이야기를 올해 초부터 Skydio에 해왔지만, 그 사이에는 반드시 먼저 쌓여야 할 많은 블록들이 있었다.
Skydio의 변화는 놀라웠고, 우리 팀의 백로그는 그 어느 때보다 깨끗하다. 하지만 가장 흥미로운 건 비개발자들이 제품에 직접 기여하는 모습을 보는 것이다.
내 이야기를 읽어줘서 고맙다!
