서울 AI 허브에서 열린 'Cursor Hackathon Seoul 3rd'에서 166명의 참가자가 단 하루 만에 29개의 실제 작동하는 서비스를 시연했다. 참가자의 90%는 해커톤 경험이 전무한 초보자였고, 상당수는 기획자·디자이너·도메인 전문가 등 비개발 직군이었다. 시각장애인 이동 지원 앱, AI 복지 추천 서비스 '받을지도'—이 결과물들은 몇 줄의 자연어 프롬프트에서 시작됐다. 이 숫자가 팀 리드에게 던지는 질문은 하나다. "그래서 우리 팀은 이걸 어떻게 구조화할 것인가?"
바이브 코딩이 바꾼 건 '누가 만드느냐'가 아니라 '무엇이 병목이냐'다
뉴스N연합 보도에 따르면 Cursor는 현재 포춘 500대 기업 70% 이상이 도입한 플랫폼이다. 가트너 2026 매직 쿼드런트 기업 AI 코딩 에이전트 부문에서 리더로 선정됐고, Bugbot·클라우드 에이전트·관리자 대시보드 등 엔터프라이즈 거버넌스 기능을 빠르게 확장 중이다. 이 확장 방향이 의미하는 바는 명확하다. AI 코딩 도구의 경쟁은 이미 '누가 더 좋은 코드를 짜느냐'에서 '누가 더 많은 사람을 문제 해결형 창작자로 만드느냐'로 이동했다.
비개발자가 자연어로 서비스를 완성하는 바이브 코딩 시대에, 진짜 병목은 더 이상 코딩 능력이 아니다. '어떻게 개발할 것인가'의 진입 장벽이 무너졌으니, 병목은 이제 '무엇을 만들 것인가'—즉 문제 정의와 기획으로 이동한다. 팀 리드가 주목해야 할 지점이 바로 여기다.
CLAUDE.md는 메모리가 아니다—그리고 이 구분이 워크플로우 설계의 핵심이다
비개발자가 하루 만에 서비스를 뚝딱 만들어내는 장면은 인상적이다. 하지만 그 에이전트가 세션이 끝나면 학습한 모든 맥락을 잃어버린다는 사실은 덜 인상적이지만 훨씬 중요하다. dev.to의 Thomas Jumper가 정리한 구분이 실무적으로 정확하다. CLAUDE.md, AGENTS.md, .cursor/rules는 인스트럭션 파일이다—팀이 작업 전에 명문화한 규칙, 민감 폴더 목록, 배포 전 확인 사항. 이것은 git에 들어가야 한다. 반면 에이전트가 작업 중에 발견하는 것들—특정 플래그 아래서 깨지는 플레이키 테스트, 왜 저 이상한 추상화가 존재하는지, 아직 런북에 없는 배포 스텝—이건 인스트럭션이 아니라 메모리다.
이 두 가지를 혼동하는 팀이 생각보다 많다. CLAUDE.md에 모든 걸 우겨넣으면 파일은 비대해지고, 정작 에이전트가 작업 중 발견한 유용한 맥락은 세션 종료와 함께 증발한다. AI-First 워크플로우 설계에서 인스트럭션 레이어와 메모리 프로토콜을 분리하는 것은 선택이 아니라 기본 아키텍처 결정이다.
마크다운 파일 하나로 랜딩페이지 15개를 배포한 팀이 보여준 것
dev.to에 공개된 사례는 AI-First 워크플로우의 ROI를 구체적으로 보여준다. 한 팀이 지난주 홈페이지를 15번 완전히 재설계했다. Figma 목업이 아니라 실제 배포된, 픽셀 단위까지 완성된 페이지들이다. 다크 리뷰 수트, 블루프린트 스펙 시트, 리서치 페이퍼, 옐로 마커 헤드라인 포스터—전혀 다른 15개의 디자인이 동일한 카피를 공유한다. 모든 페이지가 단 하나의 마크다운 파일(content/vme.md)에서 카피를 읽기 때문이다.
이 구조가 해결한 건 단순한 기술적 문제가 아니다. "헤드라인에 팀을 언급해야 한다"(카피 문제)와 "너무 딱딱하다, 더 playful하게"(디자인 문제)가 같은 회의실에서 뒤엉키는 고질적인 리뷰 미팅을 없앤 것이다. 카피와 디자인을 물리적으로 분리하자 피드백이 명확해졌고, Claude Code 에이전트가 실제 레퍼런스 사이트의 CSS에서 디자인 DNA를 추출해 변형을 생성했다. "더 임팩트 있게"라는 모호한 지시 대신 "v7 > v9 > v8"이라는 순위가 에이전트에게 최적화할 그래디언트를 줬다.
팀 리드가 실제로 설계해야 할 세 가지 레이어
세 사례를 엮으면 AI-First 워크플로우의 실체가 윤곽을 드러낸다. 팀 리드가 지금 당장 설계해야 할 레이어는 셋이다.
첫째, 역할 재정의. 비개발자가 서비스를 직접 만드는 시대에 개발자의 역할은 '코드를 짜는 사람'에서 '에이전트가 올바른 방향으로 작동하도록 경계를 설계하는 사람'으로 이동한다. 해커톤에서 빛난 건 참가자의 코딩 실력이 아니라 문제를 정의하는 기획력이었다. 팀 내 역할 분담도 이 방향으로 재조정해야 한다.
둘째, 인스트럭션과 메모리의 분리. CLAUDE.md에 팀 컨벤션과 민감 영역 규칙을 명문화하되, 에이전트가 작업 중 발견하는 런타임 지식은 별도 메모리 프로토콜로 포착하는 구조를 갖춰야 한다. 이 분리 없이는 에이전트가 아무리 빠르게 달려도 같은 실수를 반복한다.
셋째, 구조가 속도를 만든다. 랜딩페이지 15개 배포 사례의 핵심은 Claude Code의 능력이 아니라 카피와 디자인을 분리한 아키텍처 결정이다. AI 에이전트는 잘 구조화된 환경에서 기하급수적으로 생산성이 올라간다. 반대로 구조 없이 에이전트를 투입하면 빠르게 기술 부채를 쌓는다.
전망: 속도는 이미 해결됐다, 이제 구조의 문제다
솔직히 말하면, 비개발자가 하루 만에 서비스를 만드는 것 자체는 이미 해결된 문제다. 서울 해커톤이 그걸 증명했다. 남은 문제는 그 속도를 팀 수준에서, 프로덕션 수준에서 지속 가능하게 만드는 것이다. AI 코딩 도구 시장이 개인 생산성 향상에서 엔터프라이즈 오케스트레이션 플랫폼으로 이동하는 방향(Cursor의 포춘 500 침투율이 이를 반영한다)도 결국 같은 맥락이다. 단일 에이전트의 코딩 성능이 아니라, 팀 전체가 일관된 품질로 빠르게 움직일 수 있는 거버넌스와 구조의 문제.
팀 리드에게 필요한 건 더 좋은 AI 도구를 고르는 감각이 아니라, 그 도구들이 맞물려 작동하도록 워크플로우를 설계하는 능력이다. 비개발자가 만든 29개의 서비스가 하루 만에 세상에 나왔다면, 그다음 날 그것들을 유지하고 발전시키는 구조는 누가 설계할 것인가. 그 질문의 답이 팀 리드의 역할이다.