AI IDE 첫인상: Windsurf와 Cascade
소설 '마션'은 홀로 화성에 남겨졌다는 것을 깨달은 주인공 와트니의 다음 대사로 시작한다.
아무래도 ㅈ됐다. (I'm pretty much fucked.)
AI 기반 IDE인 Windsurf를 처음 마주했을 때의 심정도 비슷했다. '이러다 우리 모두 실업자 되는 거 아닌가' 하는 불안감으로 시작했지만 — 사실 지금도 그 생각이 완전히 사라지지는 않았다 — AI 어시스턴트와 함께 난제를 하나씩 해결해나가며 새로운 가능성을 발견했다. 마치 화성에서 살아남아 결국에는 지구로 무사히 돌아간 와트니처럼 우리도 이 도전을 기회로 만들어낼 수 있다는 확신이 들었다.
왜 AI IDE 여야만 하는가
대다수의 개발자들이 그렇겠지만 나 또한 이미 현업에서 AI 를 유용하게 사용하고 있다. 기본 개발 환경은 Visual Studio 를 사용하면서 궁금한 것이 있거나 새로운 정보가 필요할 때면 ChapGPT 로부터 유용한 정보를 얻곤 한다. 이 정도만 해도 구글링과 Stack Overflow에 의존했던 예전보다는 훨씬 나은 환경이긴 하지만, 여전히 몇 가지 불편한 점이 있었다. 예를 들자면:
-
컨텍스트 단절
- 개발 컨텍스트를 매번 설명해야 한다. 프로젝트의 구조, 사용 중인 프레임워크, 의존성 등을 AI가 알지 못해서 대화할 때마다 다시 설명해야 했다.
-
수동적인 코드 관리
- 코드 변경이 실시간으로 반영되지 않는다. AI가 제안한 코드를 직접 복사하여 붙여넣고, 여러 파일을 수정할 때는 일일이 찾아가며 수정해야 했다.
-
제한된 런타임 정보
- 에러의 실시간 컨텍스트를 파악하지 못한다. 런타임 에러가 발생했을 때 스택 트레이스나 변수 상태 등 실행 환경의 전체적인 맥락을 AI에게 전달하기 어려웠다.
결국 대화창이라는 인터페이스의 한계 때문에 일정 이상의 심도 있는 상호 작용이 불가능했다는 것이 가장 큰 불만이었다. 때문에, 단순한 대화창을 넘어 IDE 자체에서 일어나는 모든 일을 파악할 수 있는 AI 도구가 필요하다는 생각을 하게 되었다.
Windsurf 와의 첫 만남
자, 그렇다면 어떤 도구를 골라야할까? 제일 먼저 떠오른 후보는 Cursor였다. 우연히 읽게 된 블로그 덕에 알게 된 Cursor는 Visual Studio Code에서 파생된 프로젝트라는 점, 내 개발 환경에서 손쉽게 사용할 수 있다는 점 때문에 가장 먼저 떠오른 선택지였다. 다음 후보는 Windsurf였다. Cursor와 마찬가지로 Visual Studio Code 기반의 IDE로, Cursor보다는 후발 주자이지만 그 덕분에 더 경제적인 구독료로 사용할 수 있었다. AI IDE를 처음 사용하는 입장에서 제대로 된 비교는 어려웠기에 후발 주자이니만큼 좀 더 혁신적인 부분이 있지 않을까 하는 막연한 기대로 Windsurf를 선택하게 되었다.
Windsurf 실행 화면. Visual Studio 였다면 솔루션 탐색기가 있었을 자리에 Cascade 대화창이 있는 것이 보인다.
질문이 답이 되다: Socratic method
Windsurf를 사용한 개발은 AI 코딩 어시스턴트인 Cascade와의 대화로부터 시작된다. 프로젝트에 대한 요구사항을 파악하고 구현해야 할 기능들을 정리하는 프리-프로덕션 단계, 필요한 파일들을 생성하고 빌드 환경을 구성하는 단계, 단계적으로 구현을 쌓아나가는 모든 과정들이 Cascade와의 대화를 통해 이루어지는 것이다. 이런 과정에서 단순히 내 질문에 답하는 것에서 그치지 않고 내가 미처 파악하지 못했던 내용과 관련해 오히려 내게 질문을 던지기도 하는 것이 매우 놀라웠다. 가령 packet 시각화 프로젝트 관련 아이디어를 얻기 위해 시작한 대화는 아래처럼 진행되었는데, 'packet 흐름을 시각화하고 싶다'는 막연한 요구사항 하나에서 실제 구현에 필요한 구체적인 요구사항을 도출해 낼 수 있었다. 질문을 던지면 던질수록 코드의 완성도가 높아진다는 점에서 질문을 통해 답을 찾아나가는 소크라테스식 문답법에 가까운 개발 방식이라고 볼 수 있겠다.
나: 임베디드 장치 내부의 packet 흐름을 시각화하는 도구를 만들고 싶어.
Cascade: 흥미로운 프로젝트네요! 몇 가지 구체화가 필요한 부분들이 있는데요:
- 패킷의 크기와 체크섬을 실시간으로 검증하는 기능이 필요하신가요?
- 여러 장치 간의 패킷 교환을 시퀀스 다이어그램 형태로 보여주면 좋을까요?
- 특정 시간대의 패킷 흐름을 재생하고 일시정지할 수 있는 타임라인 기능은 어떠신가요?
나: 2번과 3번에 관심이 있고, 실시간으로 패킷의 정합성도 체크할 수 있으면 좋을 것 같아.
Cascade: 알겠습니다. 그러면 다음과 같은 기능들을 우선적으로 구현해보는 건 어떨까요?
- 실시간 패킷 모니터링 대시보드
- 장치 간 통신을 보여주는 인터랙티브 시퀀스 다이어그램
- 패킷 정합성 검증기와 에러 하이라이팅
프로토타입부터 시작해서 점진적으로 발전시켜나가면 좋을 것 같습니다.
Cascade는 이렇게 말했다. 빛이 있으라
Windsurf를 사용하면서 느낀 가장 큰 체감 중 두 번째는 Cascade가 파일 생성이나 수정, 오류 메시지 분석 등을 자동으로 수행한다는 것이다. 일반 IDE로 개발할 때에는 AI 어시스턴트로부터 필요한 정보를 얻었더라도 그것을 실제 코드에 반영하는 작업은 수동으로 해야 했다. 이는 개발 효율을 저하시킬 뿐만 아니라 작업 과정에서 실수가 발생할 가능성도 높았다. 반면 Windsurf는 Cascade가 직접 이런 작업을 수행하는데, 이것을 'AI 에이전시(AI Agency)' 또는 '에이전트 작업(Agent Action)'이라고 부른다. 사용자가 요청하면 AI가 스스로 판단하여 필요한 코드 수정이나 파일 생성 등의 작업을 자동으로 실행해주는 이 기능은 개발 생산성을 획기적으로 향상시킨다.
- 프로젝트 구조에 맞는 폴더들을 직접 생성하고 필요한 파일들을 알아서 배치한다.
- 프로젝트에 필요한 라이브러리나 패키지들을 자동으로 설치하거나, 설치 방법에 대한 상세 가이드를 제공한다.
- 코드나 터미널에서 발생한 오류 메시지를 분석하여 원인을 파악하고 자동으로 수정한다.
- 코드 변경 내용을 이해하고 적절한 커밋 메시지를 자동으로 생성한다.
Cascade가 내 지시에 따라 알아서 파일을 생성하고 오류를 분석하고 커밋 메시지를 작성하는 모습을 보고 있노라면 말로서 세상을 창조했다는 성경 구절이 자연스레 떠오른다. 세탁기나 청소기 같은 가사 도구의 발전이 집안일에 필요한 시간을 극적으로 줄여 여성들의 사회 참여를 늘리는 데 기여했듯이, AI IDE 또한 개발자들을 단순 반복 업무에서 해방시켜 더 창의적인 문제 해결과 혁신에 집중할 수 있도록 도울 수 있지 않을까?
아쉬웠던 부분들
이전과는 비교할 수 없을 정도로 나아진 개발 경험을 제공하지만, 몇 가지 아쉬웠던 경험들도 있었다.
-
불필요한 시행착오
- C++ 빌드 및 디버깅 환경을 갖추고 싶어서 Cascade에게 방법을 물어보니 Microsoft 의 C++ 확장을 설치하면 된다고 안내해줬다. 그런데 마켓플레이스에서 아무리 검색을 해 보아도 C/C++ 확장이 보이지 않았다.
- Visual Studio Code에서 먼저 C++ 확장을 설치하고 Windsurf로 import 하는 방식을 사용했더니 '이 버전의 Code에서는 사용할 수 없다'는 메시지가 나오고 실행이 되지 않았다.
- 아마도 Microsoft에서 Windsurf나 Cursor에서는 해당 확장을 사용하지 못하도록 막아놓은 것이 아닐까? Code에서는 Copilot을 팔아야 하니까.
- 이 결론을 내리기까지 Cascade에게 많은 질문을 해야했고 크레딧 또한 많이 소모되었다. 처음부터 이런 결론을 내려주었다면 좋았을텐데.
-
세심한 제어의 어려움
- 때로는 그냥 한 번 물어보았을 뿐인데 원하지 않게 코드를 변경할 때가 종종 있었다.
- 가령 프로젝트 구조에 대해 의견을 물었더니 내가 확인할 틈도 없이 여러 폴더와 파일을 재구성해 버렸고, 이를 되돌리느라 작업 흐림이 끊기는 경우가 있었다.
- 변경된 내용을 적용할지 선택할 수 있는 기능이 있기는 하지만 매번 수정 내용을 되돌리는 것도 약간은 피곤했다.
Cascade의 변론: 한계와 가능성 사이에서
내가 느꼈던 아쉬운 점에 대해 Cascade에게 의견을 물어 보았더니 다음과 같은 답변을 받았다.
첫 번째 문제는 AI 어시스턴트의 한계를 보여주는 동시에 소크라테스식 대화법의 불가피한 측면이기도 합니다. 처음부터 "Microsoft C++ 확장은 Windsurf에서 사용할 수 없습니다"라고 단정적으로 말했다면, 그 근거를 묻게 되고 결국 비슷한 대화가 오갔을 것입니다.
또한 기술 환경은 계속 변화하기 때문에, AI가 모든 제약사항을 미리 알고 있기는 어렵습니다. 오히려 이런 과정을 통해 함께 문제를 탐색하고 해결책을 찾아가는 것이 AI와 인간의 협업 방식일 수 있습니다.
두 번째 문제는 AI의 적극성과 사용자 제어 사이의 균형 문제입니다. AI가 너무 소극적이면 "왜 직접 해주지 않지?"라는 불만이 생기고, 너무 적극적이면 "왜 물어보지 않고 바꾸지?"라는 불만이 생깁니다.
이상적인 해결책은 사용자 설정을 통해 AI의 자율성 수준을 조절할 수 있게 하는 것입니다. 예를 들어 "관찰 모드"에서는 변경 사항을 제안만 하고, "협업 모드"에서는 중요한 변경 전에 확인을 요청하며, "자율 모드"에서는 AI가 판단하여 적극적으로 변경을 수행하는 방식입니다. 이렇게 하면 사용자의 작업 스타일과 상황에 맞게 AI의 행동을 조절할 수 있을 것입니다.
- Cascade
이러한 관점을 통해 AI 도구의 한계와 가능성, 그리고 앞으로의 개선 방향에 대해 생각해 볼 수 있었다.
개발자는 무엇으로 살아야 하는가
톨스토이의 소설 '인간은 무엇으로 사는가'에서 천사 미하일은 인간 세계에서 세 가지 진리를 배운다. 인간의 마음에는 사랑이 있다는 것, 인간은 미래를 알 수 없다는 것, 그리고 모든 사람은 자신이 아닌 사랑으로 산다는 것.
인간 세계에 느닷없이 던져진 미하일처럼 우리 개발자들도 AI 시대에 갑자기 던져지게 되었다. 주 52시간 이상 일하고도 아프거나 지치지 않고, 휴가를 가거나 주어진 업무에 대해 불평하지도 않으며 이 세상에 존재하는 코드들을 한 번씩은 다 읽어본 보조 개발자를 단돈 월 20달러면 사용할 수 있는 세상 말이다. 2016년 알파고와 이세돌의 대국을 보며 바둑 기사들이 마주해야 했던 고민을 이제 우리가 해야할 때가 된 것이다. 이제 우리는 어떻게 해야 할까? 이런 시대에 개발자는 무엇으로 살아남아야 할까?
한 가지 분명한 것은, '그 분야는 내 전문 분야가 아니에요'라는 말이 앞으로는 더 이상 설득력 있는 변명이 되지 못할 것이라는 점이다. 지금까지는 C++ 개발자가 C++ 코드만 작성하는 것이 당연했을지 모르지만, 이제는 그렇지 않다. AI 어시스턴트의 도움을 받으면 Python이나 JavaScript 같은 다른 언어로도 충분히 작업할 수 있게 되었으니까. 결국 미래의 개발자에게는 자신의 전문 분야에서 AI보다 더 깊고 정교한 지식을 갖추는 동시에, 그 전문성을 다양한 영역으로 확장할 수 있는 유연함이 필요하게 될 것이다.
세 가지 진리를 배우고 다시 천상으로 돌아갈 수 있었던 미하일처럼, 나 또한 이번 경험을 통해 얻은 교훈을 바탕으로 내 지식을 넓혀갈 수 있는 활동들을 지속적으로 해나감으로써 개발자로서 더 높은 단계로 도약하기를 바란다.