2026년 지금, AI 코딩 도구를 '뭘 쓸지' 고민하는 팀은 많다. 하지만 정작 생산성이 올라가지 않는 팀을 들여다보면, 문제는 도구가 아니라 워크플로우에 있다. Claude Sonnet을 쓰든 GPT-5.4를 쓰든, Cursor를 열든 OpenCode를 터미널에서 돌리든—도구를 고르기 전에 팀이 먼저 설계해야 할 것이 있다. AI와 일하는 순서, 즉 워크플로우다.
도구 생태계: 선택지가 많아졌지만 판단 기준은 여전히 같다
dev.to에 올라온 'The AI Model Landscape in 2026' 가이드는 솔직한 선언으로 시작한다. "이 글은 금방 낡을 것이다. 하지만 도구를 고르는 사고 틀은 낡지 않는다." 지금 프론티어 모델은 사실상 세 축이다. 코딩 벤치마크 기준선 역할을 하는 Claude Sonnet 4.6, 데스크탑 UI 조작과 복잡한 에이전트 워크플로우를 네이티브로 지원하는 GPT-5.4, 그리고 Google 생태계와 강하게 결합된 Gemini 3.1 Pro. 셋 모두 1M 토큰 컨텍스트를 지원한다.
하지만 가이드가 강조하는 핵심은 여기다. "일상 업무에서는 모델보다 그걸 감싸는 도구가 더 중요하다." 에디터 통합 없이 Claude를 쓰는 것보다, GPT-4o를 VS Code에 깊이 연결한 Copilot이 실제 생산성에서 앞설 수 있다. 모델 벤치마크 순위는 매주 뒤집힌다. 팀이 진짜 따져야 할 건 모델 점수가 아니라 도구가 우리 개발 흐름에 얼마나 자연스럽게 끼어드는가다.
코딩 특화 도구로 내려오면 선택지는 세 갈래다. GitHub Copilot Pro+는 모델 교체 자유도와 에디터 통합 성숙도가 가장 높지만, 네이티브 컨텍스트 한계(128K)가 발목을 잡는다. Cursor는 에디터 자체를 AI 협업 공간으로 재설계한 접근이라 워크플로우가 맞으면 생산성 점프가 크다. OpenCode는 터미널 에이전트로, 모델 종속 없이 API 키나 기존 구독을 연결해 쓴다. 어떤 도구를 고르든, 그 도구가 팀의 개발 흐름 어디에 꽂히는지를 먼저 그려야 한다.
BMAD: '바이브 코딩'이 숨긴 결정들을 끄집어내는 워크플로우
도구를 골랐다면 다음 질문은 이거다. "그래서 AI와 어떤 순서로 일할 것인가?" 여기서 BMAD 워크플로우가 등장한다. dev.to의 'A BMAD workflow, end to end'는 URL 단축 서비스(만료 기능 포함)를 예제로 삼아 전 과정을 실제로 돌려보인다. 이 글이 기존 AI 개발 아티클과 다른 지점은, 코드를 빨리 만드는 법이 아니라 코드를 짜기 전에 무엇을 결정해야 하는가를 설계하는 방법을 다룬다는 점이다.
바이브 코딩의 함정은 명확하다. "URL 단축기 만들어줘, 링크 만료 기능 포함해서." 이 한 줄 프롬프트 안에는 결정이 필요한 질문이 네 개 이상 숨어 있다. 만료 기준이 TTL인가, 절대 타임스탬프인가, 클릭 수인가? 만료된 링크는 404를 내보내나, 410을 내보내나, 랜딩 페이지로 리다이렉트하나? 클릭 카운팅은 기능인가 메커니즘인가? ID 체계는 무엇인가? AI는 이 질문들을 조용히 혼자 결정하고 코드를 넘긴다. 3주 뒤 누군가 버그 리포트를 올릴 때, 팀은 아무도 의식적으로 내리지 않은 결정을 디버깅하게 된다.
BMAD는 이 문제를 구조로 푼다. 분석가(Mary), PM(John), 아키텍트, 개발자—각기 다른 역할을 가진 에이전트 페르소나를 순서대로 거치면서, 코드가 나오기 전에 결정들을 문서화한다. /bmad-brainstorming으로 시작하면 AI는 답을 주는 게 아니라 팀에게 질문을 던진다. 숨겨진 결정들을 드러내는 것이 이 단계의 유일한 목적이다. 여기서 나온 brief.md는 "우리가 v1에서 의도적으로 결정한 것"과 "의도적으로 미룬 것"을 모두 기록한다.
이후 흐름은 PRD → 아키텍처 문서 → 스토리 파일 → 구현 → 리뷰 순으로 이어진다. 각 단계에서 나온 마크다운 파일들이 레포지토리에 남는다. 이게 핵심이다. 바이브 코딩은 코드만 남긴다. BMAD는 왜 이렇게 만들었는가를 기록한 아티팩트를 남긴다. AI가 코드를 생성할 때 참조하는 컨텍스트가 '바이브'가 아니라 '스펙'이 되는 것, 그게 품질 차이를 만드는 지점이다.
Taste: 워크플로우를 설계하는 사람이 가져야 할 것
그렇다면 AI가 코드를 다 짜는 환경에서, 팀 리드의 역할은 무엇인가? dev.to에서 410포인트를 받으며 Hacker News 프론트를 장식한 에세이('Taste Is All That\'s Left')는 불편하지만 정확한 진단을 내린다. AI는 이제 '그럴듯한' 코드를 빠르게 만들어낸다. 문제는 '그럴듯한'이 엔지니어링에서 가장 위험한 단어라는 것이다.
에세이의 논지는 이렇다. 코드를 만드는 비용이 0에 가까워지면, 가치는 만드는 능력에서 무엇을 만들지 판단하는 능력으로 이동한다. 저자가 이것을 '취향(Taste)'이라고 부르는 건, 소프트한 개념이어서가 아니다. 오히려 반대다. 취향은 논증이 완성되기 전에 먼저 도달하는 판단이다. 좋은 엔진니어는 왜 이상한지 설명하기 전에 먼저 이상함을 느낀다. 이것이 자동화할 수 없는 부분이고, AI가 대체하지 못하는 마지막 영역이다.
그런데 취향은 어디서 오는가. 에세이가 불편한 이유는 바로 여기다. 취향은 마찰(friction)에서 만들어진다. 잘못 만든 것을 그 안에서 살아야 했던 경험, 실패를 충분히 오래 들여다본 기억—그것이 쌓여 판단력이 된다. AI가 처음부터 '괜찮은' 결과물을 내주는 환경에서 시작하는 주니어는, 올라가야 할 벽을 만나지 못한다. 그 벽을 오르는 과정이 바로 판단력을 기르는 커리큘럼이었는데.
팀 리드에게 이 논지는 실질적인 과제를 던진다. 첫째, 주니어에게 마찰을 제거해주지 마라. AI 생성 정답을 바로 건네는 것은 교육을 건너뛰는 일이다. 틀린 방향으로 만들어보게 하고, 그 결과를 같이 들여다보는 시간이 취향을 만든다. 둘째, '그럴듯한 것'을 통과시키는 팀 문화는 기술 부채를 누적시킨다. AI가 생성한 코드가 작동한다고 해서 옳은 건 아니다. 리뷰 단계에서 팀의 취향, 즉 '이건 아니다'라고 말할 수 있는 기준이 작동해야 한다.
팀 리드가 지금 당장 설계해야 할 것
세 가지 소스를 엮으면 2026년 AI-First 팀이 실제로 필요한 것이 보인다. 도구 선택은 시작이다. 하지만 그것만으로는 아무것도 달라지지 않는다.
1. 도구보다 워크플로우 먼저. 어떤 모델, 어떤 에디터를 쓰든, AI와 협업하는 순서를 팀 차원에서 합의해야 한다. BMAD 같은 스펙 주도 흐름은 그 순서를 구조화하는 하나의 방법이다. 팀만의 버전을 만들어도 된다. 중요한 것은 AI가 코드를 짜기 전에 팀이 결정을 마쳤는가다.
2. 아티팩트를 남기는 문화. AI와의 대화는 휘발된다. 브리프, PRD, 아키텍처 문서—결정의 흔적을 레포지토리에 남기는 것이 장기 품질의 기반이다. 코드 리뷰만큼 스펙 리뷰를 진지하게 다뤄야 한다.
3. '노(No)'를 말할 수 있는 팀. AI가 생성한 그럴듯한 코드를 통과시키지 않는 판단력, 그 판단력을 팀 안에 분산시키는 것이 리드의 역할이다. 측정 대시보드에 잡히지 않는다. 하지만 6개월 뒤 기술 부채의 차이로 나타난다.
모델 이름은 바뀐다. 가격표도 바뀐다. 하지만 '무엇을 만들지 결정하고, 그 결정을 기록하고, AI가 생성한 것 중 무엇이 살아남아야 하는지를 판단하는 구조'—이건 바뀌지 않는다. 그것을 설계하는 것이 2026년 테크 리드의 일이다.