소프트웨어 엔지니어링은 ‘계획과 검토’가 된다
📺 원본 영상: Software Engineering Is Becoming Plan and Review — Louis Knight-Webb, Vibe Kanban 🎙️ 채널: AI Engineer 📅 정리 일자: 2026-05-03 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 슬라이드, 라이브 데모 화면 등)는 포함되지 않을 수 있습니다.
개요
Vibe Kanban의 창업자이자 런던 AI Tinkerers 챕터를 이끄는 Louis Knight-Webb은 이 강연에서 AI 코딩 도구의 발전이 소프트웨어 엔지니어의 업무 구조를 근본적으로 어떻게 바꾸고 있는지를 설명한다. 핵심 테제는 단순하다. 코드를 직접 작성하는 시간은 계속 줄어들고, 그 자리를 ‘계획(Plan)‘과 ‘검토(Review)‘가 채우고 있다는 것이다. 강연은 이 새로운 업무 방식을 어떻게 설계해야 하는지, 에이전트 실행 시간이 길어짐에 따라 소프트웨어 개발자의 행동 패턴이 어떻게 변해야 하는지를 다루며, 마지막에는 이 문제를 해결하려 했던 자신의 스타트업 Vibe Kanban을 무대 위에서 직접 셧다운하는 극적인 장면으로 마무리된다.
업무 구조의 이동 — 코드 작성 시간은 어디로 갔는가
소프트웨어 엔지니어가 하루에 하는 일을 큰 틀에서 분류하면 계획, 코드 작성, 코드 검토로 나눌 수 있다. Louis에 따르면, GitHub Copilot이 등장하기 이전의 업무 비율에서는 코드 작성이 압도적으로 큰 비중을 차지했다. 회사의 규모나 팀 구성에 따라 다소 차이는 있지만, 대부분의 엔지니어에게 하루의 상당 부분은 키보드 앞에서 직접 코드를 치는 시간이었다.
02:09 - GitHub Copilot 등장 이전 대비 코드 작성/계획/검토 업무 비율 변화를 설명하는 슬라이드
그러나 도구의 진화와 함께 이 비율이 무너지기 시작했다. 최초의 GitHub Copilot은 단일 줄 완성을 제안하는 수준이었고, ChatGPT의 등장으로 함수 단위 생성이 가능해졌다. 이후 커서(Cursor) 초기 버전이 파일 전체를 완성하는 단계로 발전했고, Claude Code의 등장과 함께 엔지니어는 스스로 “나는 이제 거의 코드를 직접 쓰지 않는구나”라는 사실을 인식하게 되었다. Louis는 이 흐름을 가리켜 코드 작성 시간이 단순히 ‘없어진’ 것이 아니라 ‘이동했다’고 설명한다. 그 시간은 계획과 검토 쪽으로 흘러들어간 것이다.
이를 다시 시간 단위로 환산하면, 이전에 코딩에 하루 네 시간을 쓰던 엔지니어가 AI 도구 덕분에 그 시간을 그대로 돌려받는 것은 아니다. 대략적으로 말하면, 코딩에 30분을 쓰던 것이 AI의 도움으로 20분 정도로 줄어들고, 나머지 10분은 계획과 검토로 재배분된다. AI는 가속제(accelerant)이지만, 그렇게 확보된 시간의 상당 부분은 다시 에이전트 출력을 관리하는 데 소모된다.
두 가지 워크플로우 — 계획 중심 vs. 검토 중심
AI 코딩 에이전트와 함께 일하는 방식은 크게 두 가지로 나뉜다. Louis는 이를 ‘계획 중심 접근법(plan-based approach)‘과 ‘검토 중심 접근법(review-heavy approach)‘으로 구분한다.
계획 중심 접근법은 에이전트에게 작업을 맡기기 전에 상당한 시간을 선행 계획에 투자하는 방식이다. 구체적으로는 상세한 계획 문서나 마크다운 파일을 작성하거나, 스펙 프레임워크를 활용하거나, 모델이 더 이상 질문할 것이 없을 때까지 요구사항을 구체화하는 과정을 거친다. 이 접근법의 핵심 이점은 사전에 엣지 케이스를 제거하고 모델에게 충분한 정보를 제공함으로써 이후 검토 횟수와 시간을 줄일 수 있다는 점이다.
반면 검토 중심 접근법은 상세한 계획 없이 일단 에이전트를 돌려본 뒤 결과물을 보며 수정하는 방식이다. “컨택트 폼을 웹페이지에 추가해줘”처럼 간단한 지시로 시작해 스타일을 고치고 결과물을 조율하는 여러 차례의 왔다 갔다를 감수하는 것이다. 이 방식은 진입 장벽이 낮지만, 에이전트가 절반쯤 완성된 결과물을 계속 내놓는 상황에서 반복적으로 컨텍스트에 재진입해야 하기 때문에 실질적인 시간 비용이 상당하다.
Louis의 결론은 명확하다. 인간의 시간을 가장 가치 있는 자원으로 본다면, 항상 계획 중심 접근법을 선택해야 한다. **“5분의 계획이 30분의 AI 코드 검토를 절약한다”**는 것이 그가 강연 전체에서 가장 강조하는 핵심 문장이다.
작업 유형별 계획-검토 비율 매트릭스
계획과 검토 중 어느 쪽에 더 무게를 두어야 하는지는 작업의 성격에 따라 달라진다. Louis는 강연에서 작업 유형을 프론트엔드/백엔드 축과 기능 개발/마이그레이션·유지보수 축으로 나누어 분석한다.
06:17 - 프론트엔드/백엔드 × 기능개발/마이그레이션 축의 계획-검토 비율 2×2 매트릭스
프론트엔드 기능 개발은 사전 스펙으로 모든 것을 정의하기가 사실상 불가능한 영역이다. 프론트엔드는 상태(state)가 복잡하고, 애니메이션과 인터랙션, 스타일과 기능이 복잡하게 얽혀 있어 엣지 케이스를 미리 전부 정의할 수 없다. 따라서 이 영역에서는 에이전트와 긴밀하게 주고받는 검토 중심 접근법이 더 현실적이다.
반면 백엔드 기능 개발이나 리팩터링·마이그레이션 작업은 테스트 주도 개발(TDD) 방식으로 충분히 사전 계획을 세울 수 있다. 이 영역에서는 에이전트가 루프 안에서 인간을 끌어들이지 않고 자율적으로 작업을 완수하는 것이 이상적이며, 인간은 최초 계획 수립과 최종 검토에만 개입하면 된다. Louis는 특히 리팩터링과 마이그레이션은 거의 전적으로 에이전트에게 위임할 수 있고, 인간이 중간에 개입할 필요가 없는 영역이라고 강조한다.
에이전트 실행 시간의 증가 — 5분의 임계값
AI 코딩 에이전트가 점점 강력해질수록 단 한 번의 프롬프트 제출에서 결과물을 받아보기까지 걸리는 시간이 길어지고 있다. 이는 단순히 모델이 느려진 게 아니라, 에이전트가 수행하는 작업의 범위 자체가 넓어졌기 때문이다.
역사적으로 보면, GitHub Copilot은 단일 줄 완성에 몇 초가 걸렸고, 커서 초기 버전은 파일 하나를 완성하는 데 30초 정도가 소요되었다. 작년의 Claude Code는 1~2분 수준이었는데, 올해 들어서는 Louis 본인도 5~10분짜리 실행에서 좋은 결과를 얻고 있다고 말한다.
08:04 - GitHub Copilot → Cursor → Claude Code 순으로 에이전트 실행 시간이 증가하는 타임라인 비교
이 흐름의 원인은 단순히 코드를 반환하는 것에서, 타입 체커를 실행하는 것으로, 그리고 Playwright MCP를 통해 UI를 직접 조작하며 테스트하는 것으로 에이전트의 검증 행동이 단계적으로 확장되었기 때문이다. Louis에 따르면, 코드만 반환하는 것은 빠르지만 타입 체커 실행은 그보다 느리고, Playwright MCP 실행은 앞선 모든 것과 비교해 자릿수가 다를 정도로 느리다. 그럼에도 이 비용은 지불할 가치가 있는데, 목표는 인간이 에이전트와 씨름하는 시간을 최소화하는 것이고, 더 오래 기다리는 대가로 더 높은 정확도를 얻는 것은 합리적인 트레이드오프이기 때문이다.
Louis가 앞으로 9개월 후를 예측하는 가장 큰 분기점은 AI가 프론트엔드 작업을 큐잉(queuing)할 수 있게 되는 시점이다. 트위터에서 Chrome이나 Playwright MCP를 통해 UI를 클릭하며 테스트하는 데모를 볼 수는 있지만, 실제 메인스트림 개발에 이를 사용하는 사람을 아직 단 한 명도 만나지 못했다고 그는 솔직히 인정한다. 그러나 이것이 실현되는 순간 — 에이전트가 프로젝트를 직접 실행하고 클릭해서 버그를 찾아 수정하는 것이 가능해지는 순간 — 이 지금까지의 가장 큰 돌파구가 될 것이라고 전망한다.
여기서 핵심 질문이 생긴다. 에이전트의 평균 실행 시간이 5분을 넘는다면 어떻게 될까? 5분 정도는 로그를 지켜보거나, 현실적으로는 트위터를 훑어보며 기다릴 수 있다. 그러나 실행 시간이 20분이 된다면? 20분 동안 에이전트 로그를 지켜보며 앉아 있을 사람은 없다. 이 지점에서 소프트웨어 개발자라는 직업의 행동 방식 자체를 근본적으로 재설계해야 한다.
병렬 에이전트 실행 — 새로운 작업 패턴의 등장
5분 임계값 문제에 대한 자연스러운 해답은 병렬성(parallelism)이다. 각각 10분씩 걸리는 에이전트 여러 개를 동시에 돌리면, 하나의 작업 검토를 마치는 순간 다른 작업이 완료되어 있다. 이른바 ‘터미널 맥싱(terminal maxing)’ — 화면을 여러 에이전트 터미널로 채우는 방식 — 이 이 문제의 현실적인 해결책으로 커뮤니티에서 회자되고 있으며, Louis 역시 이것이 대기 문제를 우회하는 방법이라고 설명한다.
10:31 - 여러 에이전트 터미널을 동시에 실행하는 ‘터미널 맥싱’ 병렬 작업 화면 예시
그러나 이 방식은 동시에 새로운 도전을 만들어낸다. 소프트웨어 엔지니어는 전통적으로 한 가지 작업에 깊이 집중하는 방식, 즉 ‘딥 포커스’로 훈련되어 있다. 그런데 병렬 에이전트 모델에서는 엔지니어가 여러 작업 스트림의 매니저 역할을 동시에 맡아야 한다. Louis는 이를 ‘포커스 맥싱(focus maxing)‘이라는 신조어로 표현하며, 미래의 코딩 도구가 이 새로운 현실을 설계 철학의 중심에 두어야 한다고 강조한다. 30초마다 인간을 다른 컨텍스트로 끌어당기는 것은 뇌를 갈아버리는 방식이고, 좋은 도구라면 에이전트가 가능한 한 길게 자율적으로 실행되다가 인간에게 결과를 넘기는 패턴을 장려해야 한다.
Vibe Kanban — 미래 도구의 비전
이 문제 의식에서 출발한 것이 바로 Vibe Kanban이다. 약 1년 전 시작된 이 프로젝트는 여러 코딩 에이전트를 쉽게 병렬로 실행할 수 있도록 만드는 것을 목표로 했다. Louis는 자신이 원하는 이상적인 코딩 에이전트 도구의 요건을 다음과 같이 정리한다.
첫째, 여러 작업 스트림을 동시에 관리하는 ‘매니저’로서의 역할을 자연스럽게 지원해야 한다. 둘째, 에이전트가 최대한 오래 자율적으로 실행되다 결과를 인간에게 돌려주는 패턴을 장려해야 한다. 셋째, 작업 계획 수립을 보조해야 한다. 넷째, QA(품질 보증) 작업을 지원해야 한다. 다섯째, 코드 리뷰를 지원해야 한다 — 어떤 회사도 실제로 돈이 걸린 상황에서 완전히 바이브 코딩된(fully vibe-coded) 코드를 직접 검토 없이 배포하지는 않을 것이기 때문이다. 여섯째, 변경 사항이 배포될 때까지의 과정을 셰퍼딩(shepherding)해야 한다 — GitHub 풀 리퀘스트의 코멘트를 모니터링하고 자동으로 반응하는 기능이 이에 해당한다.
Vibe Kanban의 구현 형태는 여러 작업 공간(workspace)을 사이드바에서 생성하고, Codex, Claude Code 등 8개의 인기 코딩 에이전트 중 원하는 것을 골라 실행하고, 결과물의 diff를 GitHub 방식으로 리뷰하며, 코멘트를 달거나 라이브 프리뷰를 통해 UI를 직접 확인하고 피드백을 주는 형태였다. Louis는 이러한 기능들이 2025년 6월 14일에 이미 구현되어 있었다고 강조한다.
11:03 - Vibe Kanban 인터페이스 — 사이드바의 다중 워크스페이스, diff 리뷰, 라이브 프리뷰 기능
무대 위의 셧다운 — 그리고 솔직한 이유
강연의 가장 극적인 순간은 후반부에 온다. Louis는 이 강연을 제출한 지 몇 주 뒤인 화요일에 회사를 셧다운하기로 결정했다고 밝히며, 강연에서 남은 Vibe Kanban 홍보 시간 대신 실제로 자사 웹사이트에 셧다운 공지 블로그 포스트를 Vibe Kanban을 이용해 라이브로 작성하여 배포하는 장면을 진행한다.
15:00 - Vibe Kanban으로 셧다운 발표 블로그 포스트를 실시간 배포하는 라이브 데모 화면
이 시점에서 강연자는 실제로 Vibe Kanban 인터페이스를 화면에 띄우고, 사전 작성한 셧다운 발표 블로그 포스트를 에이전트에 입력하여 웹사이트에 배포하는 과정을 실시간으로 시연한다. Codex 에이전트가 Git 워크트리를 생성하고, 의존성을 설치하고, 변경사항을 적용하는 과정이 라이브로 진행된다.
셧다운의 이유는 현실적이다. Vibe Kanban은 월간 활성 사용자 30,000명과 GitHub 스타 25,000개를 달성했지만, 수익화에 실패했다. Louis에 따르면, 현재 환경에서 돈을 버는 회사들은 공통적으로 두 가지를 하고 있다. 엔터프라이즈에 판매하거나, 토큰을 재판매하는 것이다. Vibe Kanban은 둘 다 하지 않았다. 코딩 에이전트 자체가 아니라 에이전트를 실행하는 인터페이스였기 때문에, 사용자들은 월 30달러를 Vibe Kanban에 내고 버튼 하나를 눌러 Codex에서 3,000달러를 쓰는 구조였다. 이것이 지속 가능한 비즈니스 모델이 아니라는 사실을 인지하고 있었고, 엔터프라이즈로 올라가는 작업을 할 수도 있었지만, 이미 성숙한 시장에서 8위를 차지하기 위해 싸우는 것은 의미 있는 선택이 아니라고 판단했다.
그는 이 경험에서 단 하나의 아쉬움을 꼽았다. 엔터프라이즈 영업에 정말 뛰어난 사람을 초기에 영입하지 않은 것이다. 그 외에는 후회가 없으며, 이 일이 자신을 ‘인간으로서의 가치를 높여줬다’고 담담하게 회고한다. 회사는 셧다운되지만 프로젝트는 비상업적으로 오픈소스 형태로 계속 유지될 예정이며, 공동창업자들은 에이전트 랩에 합류하고 팀원 대부분은 이미 좋은 자리를 찾았다.
마무리 / 핵심 정리
이 강연의 핵심은 단순하지만 그 함의는 깊다. AI 코딩 도구의 발전은 소프트웨어 엔지니어를 코드를 ‘쓰는 사람’에서 코드를 ‘계획하고 검토하는 사람’으로 전환시키고 있다. 그리고 이 전환은 에이전트의 실행 시간이 길어지고 병렬 실행이 일반화되면서 더욱 가속될 것이다.
Louis가 이 강연 전체를 통해 말하고자 하는 것은 결국 이것이다. 새로운 업무 환경에서 가장 중요한 스킬은 에이전트를 시작하기 전에 충분히 생각하는 능력, 즉 좋은 계획을 세우는 능력이다. 그리고 도구는 이 새로운 현실 — 여러 에이전트 스트림을 동시에 관리하면서도 인간의 집중력을 보호하는 것 — 을 중심으로 재설계되어야 한다. Vibe Kanban은 그 비전을 실현하려는 시도였고, 비록 사업으로서는 막을 내렸지만 이 문제 자체는 여전히 유효하고 중요하다.
소프트웨어 엔지니어링의 미래는 더 많은 코드를 쓰는 것이 아니라, 에이전트에게 더 잘 지시하고 그 결과를 더 잘 판단하는 것이다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Software Engineering Is Becoming Plan and Review — Louis Knight-Webb, Vibe Kanban |
| 채널 | AI Engineer |
| 강연자 | Louis Knight-Webb (Vibe Kanban 창업자, 런던 AI Tinkerers 챕터 설립자) |
| 리포트 작성 | 2026-05-03 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.