지피지기 백전백퇴

Windsurf 2주일 찍먹

주의

이 글은 Windsurf 에디터에서 작성되었습니다. LLM이 생성한 내용이 일부 포함될 수 있음을 양해 부탁드립니다.

개요

얼마 전 GPT-4.1이 출시되면서 Windsurf 에디터에서 1주일 무료 이용이 가능하다고 해서, 기존에 쓰던 Cursor를 버리고 Windsurf를 사용해 봤다. 중간에 무료 이용 기간이 한 번 연장되어 총 2주일간 체험해볼 수 있었기에, 그 사용 후기를 남겨본다.

서론: 요즘의 AI 코딩 툴 트렌드는 챗 인터페이스…인가?

작금의 AI 코딩 툴이라는 것들 중에서 VSCode Copilot, Cursor, Windsurf, Claude code 정도를 써 봤는데, 대개 type-ahead 자동완성은 처음엔 각광을 받았지만 이제는 구색 맞추기 수준으로 전락한 느낌이다. 기능 자체가 나빠진 것은 아니고, Cursor와 Windsurf의 경우 고치려고 하는 의도에 맞춰서 적절한 추천을 잘 해준다. 다만 inline chat이나 단독 챗 인터페이스의 사용 비중이 늘어났을 뿐.

대신 챗 인터페이스를 이용해서 자연어 명령을 받아 코드를 작성하는 것들이 많이 늘어났는데, 내가 AI 코딩 툴을 만드는 건 아니라서 구체적인 이유를 알진 못하지만 아마 이런 이유가 아닐까 싶다.

대화형 인터페이스에 맞춰 만든 범용 모델을 적용하기 쉽다

요즘 코딩 특화 모델은 개발이 뜸하다. Qwen2.5-Coder가 아직까지 가장 나은 듯 한데, 이게 5달 전에 출시된 모델이다.

반대로 범용 모델 - 최근 5개월 이내 출시된 모델을 모두 나열하려면 한세월 걸릴거다. AI 한다 하는 회사중에 업데이트가 없는 회사가 손에 꼽을지경 아닌가?

더 많은 요청을 한번에 때려넣기 용이하다

inline editing의 경우, 자연어로 길게 뭔가를 설명할 바에야 그냥 바로 코드를 고치는 게 더 빠를 지경이라 굳이 LLM을 쓸 필요가 없다.

그런데 챗 인터페이스의 경우, 챗을 통해 장문의 요청을 넣고 모델에게 큰 일을 시키는 게 자연스러운 흐름이 된다.

모델도 시간을 더 많이 쓸 수 있다.

요즘 MCP다 Reasoning이다 해서 모델도 이것저것 알아보는 작업이 필요해서 그런지 요청 하나 처리해서 뭔가를 생성하는데 3-5개의 API를 호출하는 듯 보이고 최종 결과물이 생성되는 데 걸리는 시간도 30초-1분 정도를 잡아야 한다.

기대치가 높다 - 다들 쿼리 하나로 게임 하나 만들기를 원한다

코딩 관련 벤치마크들이 주어진 문제를 End-2-end로 해결하는 류의 것들이다 보니 모델들도 거기에 맞춰서 개발되고 있는게 아닌가 싶다.

결론

그러니 모두들 챗 인터페이스에 뭔가 넣고 기도메타를 올리게 되었다.

그래서, Windsurf의 기도메타는 성공했는가?

결론부터 얘기해보자면, 장문의 컨텍스트를 넣고 거기에 맞춰서 고퀄리티의 코드를 작성하는 것은 아직 멀었다고 본다. 내가 의도한 코드를 작성하는 경우가 체감상 30% 정도?

일단 어떤 작업을 해봤는지 짧게 소개해보자면, 개인용으로 쓰는 웹앱의 GraphQL client에 적당한 cache policy를 붙여서 가능한 한 offline 모드로 동작이 가능하도록 하려고 했다. 주고받은 쿼리를 모두 적기엔 너무 글이 길어지니 생략하고 뭐가 문제인지만 짧게 열거해 보자면:

  • Oneshot으로 뭔가 하는건 말도 안된다. Analyze GraphQL queries and propose a cache policy 뭐 이런식으로 해봤는데 전혀 효과없는 결과물만 받았다.
  • 요청을 개떡같이 써도 찰떡같이 알아듣는 경우가 적다. 생성물이 개판나면 요청을 바꿔가면서 재시도가 필요하다.
  • 따라서 작업을 작고 간단한 수준으로 쪼개야 한다. 실제 입력한 프롬프트는 대충 이런 수준이었다:
    • “자 일단 Apollo client를 만드는 부분을 추출해서 새 파일로 만들어줘”
    • “Apollo client를 테스트하는 간단한 유닛 테스트를 작성해봐”
    • “아니아니, 테스트 코드 파일명은 .spec.ts로 끝나야 해. 파일 이름을 컨벤션에 맞게 변경해줘”
    • “테스트 툴에서 이미 playwright를 이용하니 굳이 localStorage를 mock할 필요가 없어. mock 코드를 제거해줘”
    • “이제 GetEntry API를 이용하는 테스트를 작성해봐”
    • “Relay style pagination을 적용하는 GetEntries API를 이용하는 테스트를 작성해봐”
  • 여기까지 하고나서 보니 Apollo client의 relay style pagination cache는 다음/이전 항목을 따로 반환해주는 코드가 있는게 아니었는데 LLM 모델은 그런 부분의 구현을 제대로 이해하지 못하는 것처럼 보였다. 여기부턴 거의 손으로 작성하다시피 하는 수준이었다.
  • 그 외에 툴 자체에 clutter가 많다고 해야하나, change history 관리가 잘 안되는지 undo redo 좀 하다보면 이상한 수정이 코드 중간에 끼어드는 경우도 있었다.

결론

다만 10-20줄 정도의 짧은 코드를 Claude 3.7 sonnet으로 작성하는 것은 매우 성공률이 높고 만족스러웠다;;;