[4편] Cascade가 만든 새로운 개발자 경험

코드를 짜는 사람이 아니라, 흐름을 설계하는 사람으로

이 글은 Pragmatic Engineer 뉴스레터 내 Building Windsurf with Varun Mohan을 바탕으로 작성되었습니다.
Windsurf의 CEO 바룬 모한(Varun Mohan)과의 인터뷰를 통해, 단순히 LLM으로 코드를 생성하는 기술을 넘어서, AI 에이전트 시대에 우리가 재정의해야 할 문제 해결력, 개발자의 역할, 그리고 신뢰할 수 있는 도구와 조직이란 무엇인지 실무자의 시선으로 되짚어봅니다.

2023년, Windsurf 팀은 중요한 실험에 돌입합니다. 이름하여 ‘Cascade’. LLM을 단순 자동완성 도구가 아닌 에이전트(Agent)로 진화시키기 위한 프로젝트였습니다. 개발자가 작성한 의도를 받아, 관련 파일을 탐색하고, 필요한 수정 사항을 여러 파일에 걸쳐 적용하며, 테스트까지 고려하는 ‘코드 조율자’를 만들겠다는 야심 찬 시도였습니다.

하지만 이 시도는 초반부터 난관에 부딪혔습니다.

"몇 달 동안 제대로 된 결과가 나오지 않았습니다."

Varun은 실패를 인정하는 데 주저하지 않습니다. 처음 Cascade는 제대로 동작하지 않았고, 팀 내부에서도 계속 실패가 반복되자 회의감이 돌기도 했습니다. 하지만 그들은 멈추지 않았습니다.

"우리는 실패를 나쁘게 보지 않습니다. 실패란 아직 배울 게 남았다는 신호입니다."

전환점: ‘복잡한 코드베이스에서도 쓸 수 있다’는 확신

Cascade가 전환점을 맞이한 건, 단순한 챗봇 수준의 성능을 넘어, 실제로 100만 줄 이상의 복잡한 코드베이스를 이해하고 수정할 수 있게 되었을 때였습니다.

내부 개발자들이 스스로 Cascade를 쓰기 시작했고, 기존 방식보다 더 빠르고 정확하게 코드 리팩토링을 해내는 사례가 하나둘 나오기 시작합니다. 중요한 건 단지 “작동한다”가 아니라, 개발자들이 자발적으로 Cascade를 선택한다는 것이었습니다.

"그 순간, 우리는 처음으로 '이건 진짜 될 수 있다'는 확신을 얻었습니다."

액티브 AI로의 전환: 질문 대신 명령부터 한다

기존의 AI 코딩 도구는 대부분 개발자의 입력에 ‘반응’하는 구조였습니다.

즉, ‘자동완성’이나 ‘한 줄 생성’ 중심이었죠. 하지만 Cascade는 개발자의 명령이 시작점입니다.

예를 들어, 개발자가 이렇게 지시한다고 가정해 봅시다.

"이 API에 대한 audit log 기능을 추가해 줘."

이 경우 Cascade는 다음과 같은 작업을 수행합니다.

관련 API가 있는 파일을 찾고

audit log 관련 모듈이 이미 존재하는지 확인한 뒤

필요한 경우 새 로그 함수를 정의하고

해당 API 함수에 삽입하며

테스트 코드까지 수정합니다.

이런 다단계 작업은 이전까지 인간만이 할 수 있었던 ‘전체 흐름 파악과 분기적 수정’을 필요로 했습니다. Cascade는 이제 그 역할의 상당 부분을 수행할 수 있습니다.

IDE가 아닌 ‘개발 운영체제’로서의 도약

Windsurf 팀은 기존 IDE(VS Code)의 한계도 절감했습니다. 단순한 에디터로서의 IDE는, Cascade 같은 에이전트의 작업 흐름을 자연스럽게 표현하기 어려웠습니다. 그래서 그들은 아예 Code OSS를 포크 하여, 에이전트 중심의 작업 구조에 맞는 자체 IDE를 만들었습니다.

"VS Code는 단순히 코드를 편집하는 공간이지만, 우리는 개발이라는 프로세스를 담아야 했습니다."

이 새로운 IDE에서는 Cascade가 제안한 변경사항을 계획, 수정, 테스트, 리뷰 단계로 시각화하며, 개발자가 그 흐름을 점검하고 일부 수정하거나 승인할 수 있게 설계되었습니다.

즉, 개발자는 이제 코드가 아니라 ‘변화의 흐름’을 관리합니다.

비개발자도 제품을 만든다 – Windsurf 내부 사례

Cascade의 등장은 단지 개발자의 생산성만 바꾸지 않았습니다.

Windsurf 내부에서는 비개발자들이 실제 업무에 필요한 앱을 직접 만들기 시작합니다.

예를 들어, 파트너십 담당자가 사내 견적 자동화 툴을 만들고, 이를 통해 연간 6자리 수 비용을 절감한 사례가 있습니다. 이 툴은 Cascade를 활용해 직접 사내 시스템과 연동되는 form, DB 연동 로직, 계산 모듈 등을 생성했고, 검토만 개발자가 진행했습니다.

"이제 도메인 전문가가 직접 앱을 만들고, 개발자는 그걸 점검하고 다듬는 구조로 바뀌고 있습니다."

소프트웨어 개발의 ‘단가’가 바뀐다

Cascade와 Windsurf의 구조는 결국 소프트웨어 개발의 단가를 완전히 재정의합니다.

더 이상 단순 CRUD 앱 하나 만들기 위해 개발 리소스를 몇 주 단위로 할당하지 않아도 됩니다.

내부 도메인 지식을 가진 사람이 ‘의도’를 중심으로 에이전트와 협업해 프로토타입을 만들고,

개발자는 그것을 다듬는 의사결정 파이프라인이 구축됩니다.

이는 곧, 다음과 같은 메시지를 줍니다.

"이제 더 많은 소프트웨어를 더 작고 빠르게 만들 수 있다."

이는 곧 개발자 수요의 감소가 아닌, 소프트웨어 수요의 폭발적 증가로 이어집니다.

Varun이 말한 것처럼, 기술은 천장을 낮추는 것이 아니라, 천장을 더 높게 끌어올리는 역할을 합니다.

5편에서는 Windsurf가 어떻게 내부에서 기능을 테스트하고 실패를 수용하는 문화를 조직문화로 정착시켰는지, 그리고 개발자들이 직접 제품을 개선하는 조직 구조가 어떻게 만들어졌는지를 살펴봅니다.