평행 작업에 최적화된 AI 코딩 툴, Verdant AI 실전 가이드
📺 원본 영상: 평행 작업에 최적화된 AI. Verdant AI!
🎙️ 채널: 코드팩토리
📅 정리 일자: 2026-01-27
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
대부분의 AI 코딩 툴은 한 번에 하나의 기능을 구현하는 데 최적화되어 있다. 그러나 실제 개발 환경에서는 여러 피처를 동시에 작업하거나, UI와 로직을 분리해서 병렬로 진행해야 할 때가 많다. Verdant AI는 이러한 병렬 작업(Parallel Tasking)을 기본 전제로 설계된 AI 코딩 툴이다. 이 영상에서는 Next.js 기반 개발자 블로그를 구축하면서 Verdant AI의 핵심 기능인 독립 워크스페이스(Git Worktree 기반), 멀티모델 전략, 그리고 자동 충돌 해결(Conflict Resolution) 기능을 실전에서 활용하는 방법을 다룬다.
Verdant AI의 철학: 병렬 작업이 기본이다
Anti-Gravity 스타일의 에이전트 중심 UI
Verdant AI의 첫인상은 기존 IDE와 다른 레이아웃에서 시작된다. 화면 왼쪽에는 작업 태스크 목록이 배치되고, 가운데는 프롬프트 입력 공간, 오른쪽에는 폴더 구조가 나타난다. 터미널은 하단에 위치하며, 이는 우리가 익숙한 구조다. 그러나 이 레이아웃의 진짜 의미는 “코드를 직접 보고 수정하는 시대가 저물고 있다”는 점에 있다. AI가 강력해지면서 개발자는 코드를 직접 편집하기보다는 프롬프트로 의도를 전달하고, 에이전트의 작업을 모니터링하는 방식으로 전환하고 있다. Verdant AI는 이러한 트렌드를 UI 레벨에서 반영한 것이다. 강연자는 “굉장히 짧은 기간에 UI적인 트렌드도 금방 바뀌었다”고 언급하며, 에이전트 중심 인터페이스가 이제는 거의 스탠다드로 자리 잡았다고 설명했다.
서브에이전트(Subagent) 기능의 중요성
Verdant AI는 서브에이전트 기능을 기본으로 제공한다. 프롬프트 입력창에서 골뱅이(@)를 입력하면 파일, 폴더, 서브에이전트를 태그할 수 있는데, 여기서 Verifier 서브에이전트가 이미 내장되어 있는 것을 확인할 수 있다. 강연자는 “아직도 서브에이전트 기능이 없는 툴들이 정말 많은데, Verdant는 Parallel Tasking을 집중해서 개발한 만큼 서브에이전트 기능이 기본으로 깔려 있다”고 강조했다. 이는 단순히 편의 기능이 아니라, 복잡한 작업을 분리하고 각 에이전트가 독립적으로 실행될 수 있도록 하는 아키텍처의 핵심이다.
Plan Mode와 Agent Mode의 전환
Verdant AI는 Plan Mode와 Agent Mode를 명시적으로 구분한다. Agent Mode는 한 번에 끝까지 자동으로 작업을 수행하고, Plan Mode는 먼저 계획을 수립한 뒤 사용자 승인을 받고 실행에 들어간다. 강연자는 “요즘 굉장히 많이 사용하는 패턴”이라고 언급하며, 복잡한 작업일수록 Plan Mode를 먼저 활용해 작업 범위를 명확히 하는 것이 중요하다고 설명했다. 이는 토큰 낭비를 줄이고, 예상치 못한 방향으로 작업이 진행되는 것을 방지하는 데 효과적이다.
멀티모델 전략: 작업별로 최적의 AI를 선택하라
Frontier Model을 자유롭게 전환하는 강점
Verdant AI의 가장 큰 장점 중 하나는 Opus 4.5, Gemini 3.4, Flash 등 여러 Frontier Model을 하나의 워크플로우 안에서 자유롭게 선택할 수 있다는 점이다. 강연자는 “Gemini 3.4로는 UI를 작업하고, Opus 4.5로는 나머지 로직을 작업하는 것도 굉장히 많이 한다”고 말하며, 모델별로 특화된 강점을 활용하는 전략을 소개했다. 예를 들어 UI 디자인은 이미지 인식이 뛰어난 Gemini 3 Pro를 사용하고, 복잡한 아키텍처 설계는 추론 능력이 강한 Opus 4.5를 사용하는 식이다.
특히 흥미로운 점은 가격 차이다. 강연자에 따르면 Opus 4.5와 Gemini 3.4의 요청 비용이 거의 3배 차이가 난다고 한다. “지금 이벤트 중이라서 그런지는 모르겠는데”라는 단서를 달았지만, Gemini Flash 모델의 경우 0.18 수준으로 매우 저렴하게 사용할 수 있다. 이는 초기화나 단순 반복 작업에 Flash 모델을 활용하면 토큰 비용을 대폭 절감할 수 있음을 의미한다. 강연자는 “여러 모델들을 동시에 쓸 수 있기 때문에 컨텍스트 스위칭 없이 가장 특화된 기능으로 작업을 해볼 수 있다”고 정리했다.
작업 단계별 모델 선택 전략
강연자가 실전에서 보여준 모델 선택 전략은 다음과 같다. 프로젝트 초기화 단계에서는 create-next-app처럼 단순 반복 작업을 AI에게 맡기지 않고 직접 실행했다. “맨날 토큰 부족하다고 말씀하시면서 이런 초기화 작업들 AI한테 맡기지 마세요. 직접 하면 훨씬 더 빠르게 작업할 수 있고 훨씬 더 효율적입니다”라는 조언은 실용적이다. 반면 프로젝트 상태를 AI에게 전달하는 작업은 Gemini 3 Flash를 Low Thinking 모드로 실행했다. 이는 복잡한 추론이 필요 없고, agents.md 파일을 생성하는 단순 작업이기 때문이다.
UI 디자인 단계에서는 Gemini 3 Pro를 High Thinking 모드로 활용했다. PNG 이미지를 입력으로 주고 Next.js 프로젝트에 맞게 컴포넌트를 생성하도록 요청했는데, 강연자는 “이미지 인식은 무조건 Gemini 3 Pro가 제일 잘한다”고 단언했다. 반면 MDX 기반 아키텍처 설계처럼 구조적 사고가 필요한 작업에는 Opus 4.5를 Ultra Thinking 모드로 사용했다. 이렇게 작업 성격에 따라 모델을 세밀하게 분리하면, 비용 대비 성능을 극대화할 수 있다.
독립 워크스페이스: Git Worktree를 UI로 추상화하다
Base와 Workspace의 개념
Verdant AI의 핵심 기능 중 하나는 독립 워크스페이스(Workspace) 시스템이다. 강연자는 이를 Git Worktree에 비유하며 설명했다. Base는 기본 브랜치(보통 main 또는 master)에 해당하고, 각 Workspace는 Base로부터 파생된 독립 브랜치이자 물리적으로 분리된 작업 공간이다. “여러 개의 작업을 동시에 개입하지 않으면서 구현하려면 Work Tree라는 개념을 사용하는 게 가장 최선”이라는 설명은 병렬 개발의 핵심을 짚는다.
New Workspace 버튼을 누르면 브랜치 이름을 입력하는 화면이 나타나는데, 여기서 아이콘과 함께 제공되는 플레이스홀더 텍스트가 “우리가 일반적으로 Work Tree를 만드는 방식 그대로”라고 강연자는 설명했다. 즉, Verdant AI는 Git 명령어를 직접 입력할 필요 없이, UI 레벨에서 Worktree 생성과 전환을 지원한다. 이는 Git에 익숙하지 않은 개발자도 병렬 작업의 장점을 누릴 수 있게 만든다.
실전 예제: 홈 페이지와 상세 페이지 동시 개발
강연자는 개발자 블로그의 홈 페이지와 상세 페이지를 동시에 개발하는 시나리오를 시연했다. 먼저 Base에서 홈 페이지 작업을 시작한 뒤, 별도로 feature/detail이라는 Workspace를 생성했다. 이 Workspace는 master 브랜치로부터 분기되며, 완전히 독립된 태스크 공간을 갖는다. 강연자는 각 Workspace에서 디자인 목업(home.png, detail.png)을 태그한 뒤, “첨부한 목업을 확인하고 현재 프로젝트에 맞게 디자인 작업해줘”라는 프롬프트를 각각 전송했다.
두 작업은 완전히 독립적으로 진행되며, 각각 다른 포트(3000번, 3001번)에서 실행된다. 홈 페이지는 Base에서 작업 중이므로 3000번 포트에서, 상세 페이지는 feature/detail Workspace에서 작업 중이므로 3001번 포트에서 확인할 수 있다. 강연자는 “기본 페이지는 당연히 우리가 아직 머지를 안 했기 때문에 Next.js 기본이 나오고, URL로 내비게이션하면 상세 페이지 잘 나온다”고 설명하며, 두 작업이 서로 간섭 없이 진행되고 있음을 보여줬다.
충돌 해결(Conflict Resolution)의 자동화
병렬 작업의 가장 큰 걸림돌은 Merge 시점의 충돌(Conflict)이다. 강연자는 “초보들은 물론이고, 초보 아니더라도 사실 이 Conflict 같은 것들은 정말 매니징하기가 기본적으로 너무 어렵다. 심지어 AI가 작업한 거에 대해서는 우리가 알기가 어렵다”고 언급했다. Verdant AI는 이 문제를 “Resolve with AI”라는 버튼으로 해결한다. Sync with master를 실행하면 양쪽 브랜치의 변경 사항이 비교되고, 충돌이 발생하면 AI가 양쪽 컨텍스트를 모두 고려해 최적의 병합 방법을 제안한다.
강연자는 실제로 feature/detail Workspace를 master와 동기화하고, 충돌이 발생한 부분에서 “Resolve with AI” 버튼을 눌렀다. AI는 양쪽의 수정 사항을 분석한 뒤 자동으로 병합을 완료했고, 이후 Merge Continue를 실행하면 모든 변경 사항이 master로 통합되었다. “병합이 이렇게 된 거를 볼 수 있다”는 강연자의 말처럼, 이 과정은 수동으로 diff를 비교하고 충돌을 해결하는 것에 비해 훨씬 빠르고 직관적이다.
디자인 워크플로우: Stitch + PNG 방식의 장단점
HTML vs PNG: 어떤 것을 선택할 것인가
강연자는 UI 디자인 단계에서 Stitch(v0 by Vercel)를 활용해 목업을 생성했다. Stitch는 프롬프트를 입력하면 HTML과 CSS로 구성된 프로토타입을 생성해주는데, 여기서 강연자는 HTML이 아닌 PNG 이미지를 다운로드해 사용했다. 그 이유는 흥미롭다. “HTML을 그대로 먹이게 되면 HTML 코드를 그대로 따라간다. 근데 우리 프로젝트에는 우리만의 스타일이 또 있잖아요. Shadcn을 쓴다거나 테마들을 쓴다거나. 만약 HTML을 사용하면 완전 똑같이 만들어 넣기 때문에 우리 프로젝트에 맞게 다시 한번 번역돼서 구현이 안 된다”는 것이다.
즉, PNG 이미지를 입력으로 주면 AI가 프로젝트의 기존 스타일(Tailwind CSS, Shadcn 등)을 고려해 재해석하지만, HTML을 입력하면 그대로 복사하는 경향이 있다. 강연자는 “저는 이미지를 쓰는 걸 조금 더 좋아합니다. 근데 만약 똑같이 만들고 싶다면 HTML을 무조건 쓰는 걸 추천드릴게요”라고 정리했다. 이는 프로젝트의 성격에 따라 선택할 수 있는 유연성을 제공한다. 새 프로젝트에서 디자인을 그대로 재현하고 싶다면 HTML을, 기존 프로젝트에 일관성 있게 통합하고 싶다면 PNG를 사용하는 것이 합리적이다.
Gemini 3 Pro의 이미지 인식 능력
강연자는 PNG 방식을 선택한 또 다른 이유로 Gemini 3 Pro의 이미지 인식 능력을 꼽았다. “이미지를 기반으로 했는데도 이렇게 완벽하게 나오는 게 저는 매번 정말 놀랍습니다”라는 감탄은 과장이 아니다. 실제 시연에서 home.png를 태그하고 “첨부한 홈페이지 목업을 확인하고 현재 프로젝트에 맞게 디자인 작업해줘”라는 단순한 프롬프트만으로, Gemini 3 Pro는 레이아웃, 색상, 폰트, 간격을 거의 완벽하게 재현한 React 컴포넌트를 생성했다.
특히 상세 페이지(detail.png)에서도 동일한 결과가 나왔는데, 강연자는 “이 이미지를 기반으로 했는데도 이렇게 완벽하게 나오는 게 저는 매번 정말 놀랍습니다”라고 반복해 강조했다. 이는 이미지 인식 모델의 발전이 UI 개발 워크플로우를 근본적으로 바꿀 수 있음을 시사한다. 디자이너가 Figma에서 작업한 화면을 PNG로 내보내고, 개발자는 그 이미지를 AI에게 주기만 하면 되는 시대가 열린 것이다.
MDX 기반 블로그 아키텍처: 로직과 UI의 분리
Plan Mode로 아키텍처 설계 승인받기
홈 페이지와 상세 페이지의 UI 작업이 끝난 뒤, 강연자는 블로그 콘텐츠 관리 시스템을 구축하기로 했다. 이번에는 Opus 4.5를 Ultra Thinking 모드로 선택하고, Plan Mode를 활성화했다. 프롬프트는 간결했다. “MDX를 기반으로 블로그 콘텐츠를 관리하려고 해. MDX 기반 아키텍처 만들어줘.” Plan Mode는 즉시 실행하지 않고, 먼저 작업 계획을 생성한다. 이 계획에는 MDX 파일 구조, 파싱 로직, 정적 페이지 생성 방식, 코드 블록 하이라이팅, 목차 자동 생성 등이 포함되었다.
강연자는 계획을 검토한 뒤 검색 기능 같은 불필요한 항목을 제거하고, Submit을 눌러 작업을 승인했다. 그러자 AI는 즉시 실행에 들어가 MDX 파일을 파싱하는 유틸리티, 정적 경로 생성 함수, 그리고 동적 라우팅을 처리하는 페이지 컴포넌트를 생성했다. 강연자는 “계획이 승인됐기 때문에 이렇게 작업을 바로 하는 거를 볼 수 있다”고 설명하며, Plan Mode가 불필요한 작업을 사전에 차단하고 토큰을 절약하는 데 효과적임을 보여줬다.
동시에 Footer Subscribe 섹션 추가하기
흥미로운 점은, MDX 아키텍처 작업이 진행되는 동안 강연자는 별도의 New Task를 생성해 Footer에 Subscribe 섹션을 추가하는 작업을 동시에 진행했다는 것이다. “Footer에 Search 대신 Subscribe 섹션을 추가해달라”는 프롬프트를 전송하고, 이 작업은 MDX 아키텍처와 완전히 독립적으로 진행되었다. 강연자는 “완전히 뭐 다른 작업이 될 수 있기 때문에”라고 설명하며, 하나의 브랜치에서도 여러 태스크를 병렬로 실행할 수 있음을 보여줬다.
이는 Verdant AI의 두 가지 병렬 작업 방식을 보여준다. 첫째는 독립 Workspace를 활용한 브랜치 레벨 병렬 작업이고, 둘째는 같은 브랜치 내에서 New Task 기능을 활용한 태스크 레벨 병렬 작업이다. 강연자는 “여러분이 원하는 대로 선택을 하고 작업을 해주면 되는 거죠”라고 정리하며, Worktree를 직접 생성하고 이동하는 번거로움을 Verdant가 모두 해결해준다고 강조했다.
병렬 작업 시 주의사항: Conflict를 최소화하라
독립성이 보장되는 작업만 병렬로 진행하라
강연자는 병렬 작업의 핵심 원칙을 명확히 제시했다. “여러분이 기본적으로 Conflict가 나지 않을 것 같은 것들 위주로 따로 작업을 해줘야 돼요.” 페이지가 완전히 다르거나 피처가 완전히 다른 경우가 가장 이상적이다. 예를 들어 홈 페이지와 상세 페이지는 파일 경로(/page.tsx vs /blog/[slug]/page.tsx)가 완전히 다르기 때문에 충돌 가능성이 거의 없다. 반면 같은 파일을 수정하는 작업들을 병렬로 진행하면, Merge 시점에 복잡한 충돌이 발생할 수 있다.
강연자는 “그렇지 않을 경우에는 웬만하면 다른 Workspace에서 작업을 하면 좋고, 그것보다 더 좋은 거는 그런 경우에는 그냥 Serial로 병렬로 작업하지 않고 Serial로 작업하는 게 훨씬 더 낫습니다. 그래야지 정신건강이 좋아요”라고 조언했다. 즉, 병렬 작업은 만능이 아니며, 작업 간 의존성과 충돌 가능성을 사전에 평가해야 한다. 무리하게 병렬화하다가 Merge 지옥에 빠지는 것보다, 순차적으로 진행하는 것이 더 효율적일 수 있다.
Workspace별 Task 관리와 정리
Verdant AI는 Workspace별로 러닝 중인 태스크를 모니터링할 수 있는 메뉴를 제공한다. 강연자는 Workspace 메뉴에서 “워크스페이스 별로 우리가 태스크가 어떤 것들이 러닝하고 있는지도 볼 수 있어요. 이런 것도 우리가 옮겨서 순서 바꿀 수도 있고요, 삭제를 할 수도 있습니다”라고 설명했다. 이는 복잡한 프로젝트에서 여러 Workspace와 태스크를 동시에 관리할 때 유용하다.
작업이 끝나면 커밋을 잊지 말아야 한다. 강연자는 Gemini Flash를 Low 모드로 설정하고 “모든 작업을 커밋 해달라”고 요청했다. Base와 각 Workspace에서 커밋이 완료되면, Sync with master를 통해 변경 사항을 통합할 수 있다. 이 과정에서 Resolve with AI가 충돌을 자동으로 해결하고, 최종적으로 Reverse to master를 실행하면 모든 작업이 하나로 병합된다. 강연자는 “Merge를 했더니 홈페이지 잘 뜨는 거 볼 수 있고, 카드를 누르면 상세 페이지까지 잘 간다”며 성공적인 병합을 확인했다.
초기화 작업의 함정: AI에게 맡기지 마라
토큰 낭비의 주범은 단순 반복 작업
강연자가 반복적으로 강조한 또 다른 포인트는 “초기화 작업을 AI에게 맡기지 말라”는 것이다. Next.js 프로젝트를 시작할 때, create-next-app 명령어를 실행하는 것은 단 몇 초면 끝나는 작업이다. 그러나 이를 AI에게 시키면 프롬프트 해석, 명령어 생성, 실행 확인 등의 과정을 거치며 불필요한 토큰을 소비한다. 강연자는 “맨날 토큰 부족하다고 말씀하시면서 이런 초기화 작업들 AI한테 맡기지 마세요. 직접 하면 훨씬 더 빠르게 작업할 수 있고 훨씬 더 효율적으로 할 수가 있습니다. 토큰도 세이브 하고요”라고 단호하게 말했다.
이는 AI 코딩 툴을 사용할 때 흔히 범하는 실수다. 모든 것을 AI에게 맡기는 것이 효율적일 것 같지만, 실제로는 단순 작업일수록 직접 실행하는 것이 빠르다. AI는 복잡한 추론과 코드 생성이 필요한 작업에 집중시키고, 명령어 실행이나 패키지 설치 같은 단순 작업은 직접 처리하는 것이 토큰 효율을 극대화하는 방법이다. 강연자의 이 조언은 단순하지만, 장기적으로 토큰 비용을 크게 절감할 수 있는 핵심 원칙이다.
agents.md와 Open Standard: Claude.md의 Verdant 버전
프로젝트 컨텍스트 전달의 표준화
Verdant AI는 agents.md 파일을 사용해 프로젝트의 컨텍스트를 AI에게 전달한다. 강연자는 “Verdant AI는 이 Open Standard를 맞춰서 agents.md 파일을 사용하는 거를 볼 수 있어요. Claude 쓰시는 분들은 이거는 그냥 Claude.md라고 생각하시면 됩니다”라고 설명했다. 이 파일에는 프로젝트의 구조, 사용 중인 라이브러리, 코딩 컨벤션, 주요 파일 경로 등이 기록된다.
agents.md를 생성하는 작업 자체는 복잡한 추론이 필요 없기 때문에, 강연자는 Gemini Flash를 Low Thinking 모드로 설정해 빠르게 처리했다. “이거 토크를 하면 우리가 High로 쓸 수도 있고 Low로 쓸 수도 있는데, 이거 이닉 같은 경우에는 우리가 뭐 생각할 필요도 없기 때문에 그냥 바로 Low로 두고 이닉을 한번 실행해 보도록 할게요”라는 설명처럼, 작업의 복잡도에 따라 Thinking 레벨을 조절하면 토큰을 효율적으로 사용할 수 있다.
Verdant AI의 접근성: 독립 프로그램 vs VS Code Extension
Anti-Gravity와의 통합 가능성
강연자는 마지막으로 Verdant AI의 유연성을 언급했다. “독립 프로그램을 이렇게 설치하지 않아도 사용을 할 수도 있거든요. 예를 들어서 Anti-Gravity 같은 VS Code 기반에 이렇게 플러그인으로 설치를 해도 우리가 동시에 같이 쓸 수 있기 때문에 우리가 일반적으로 쓰던 IDE랑 여러분이 익스텐션을 사용해서 설치를 할 수도 있습니다.” 이는 기존 개발 환경을 유지하면서 Verdant의 병렬 작업 기능만 활용할 수 있음을 의미한다.
현재 Verdant AI는 7일 무료 체험을 제공하고 있으며, 이벤트 기간 중이라고 한다. 강연자는 “관심이 생기면 지금 바로 Verdant AI 가서 직접 다운로드 해봐서 그냥 일단 회원가입하고 그냥 바로 써보면 됩니다”라고 권유하며, 직접 경험해보는 것이 가장 빠른 학습 방법이라고 강조했다.
핵심 정리: Verdant AI가 바꾸는 개발 워크플로우
Verdant AI는 병렬 작업(Parallel Tasking)을 일상적인 개발 워크플로우로 만들기 위해 설계된 AI 코딩 툴이다. Git Worktree를 UI로 추상화한 독립 Workspace 시스템은 여러 피처를 동시에 개발하면서도 서로 간섭하지 않도록 보장한다. 멀티모델 전략을 통해 UI는 Gemini 3 Pro로, 아키텍처 설계는 Opus 4.5로, 단순 작업은 Flash로 분리해 비용 대비 성능을 극대화할 수 있다.
자동 충돌 해결(Resolve with AI) 기능은 Merge 과정의 복잡도를 대폭 낮추며, Plan Mode는 불필요한 작업을 사전에 차단해 토큰 낭비를 줄인다. 그러나 병렬 작업이 만능은 아니다. Conflict 가능성이 높은 작업은 순차적으로 진행하는 것이 정신건강에 이롭고, 초기화 같은 단순 반복 작업은 AI에게 맡기지 않는 것이 효율적이다. Verdant AI는 이러한 원칙들을 이해하고 활용할 때, 개발 생산성을 획기적으로 높일 수 있는 도구다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | 평행 작업에 최적화된 AI. Verdant AI! |
| 채널 | 코드팩토리 |
| 리포트 작성 | 2026-01-27 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.