[2편] 우리는 추론 중에도 파인튜닝을 한다
Windsurf의 인프라와 모델 운영 전략
이 글은 Pragmatic Engineer 뉴스레터 내 Building Windsurf with Varun Mohan을 바탕으로 작성되었습니다.
Windsurf의 CEO 바룬 모한(Varun Mohan)과의 인터뷰를 통해, 단순히 LLM으로 코드를 생성하는 기술을 넘어서, AI 에이전트 시대에 우리가 재정의해야 할 문제 해결력, 개발자의 역할, 그리고 신뢰할 수 있는 도구와 조직이란 무엇인지 실무자의 시선으로 되짚어봅니다.
Windsurf는 단순히 LLM을 API로 불러다 쓰는 서비스가 아닙니다.
이들은 직접 모델을 학습하고, 추론 인프라를 최적화하며,
latency와 사용자 경험을 극한까지 밀어붙이는 하드코어 엔지니어링 집단입니다.
그 중심에는 두 가지 철학이 있습니다.
첫째, "빠른 속도는 선택이 아니라 생존이다."
둘째, "우리는 우리가 만든 모델을 가장 잘 운영할 수 있어야 한다."
latency 100ms, 그 아래로도 내려가야 한다
Windsurf의 사용자 경험에서 가장 핵심적인 요소는 속도입니다.
일반적인 LLM API 제공자는 첫 토큰 응답 속도를 수백 밀리초 정도로 잡습니다.
하지만 Varun은 이마저도 느리다고 단언합니다.
"우리는 첫 토큰 생성까지 100ms 이하, 초당 수백 토큰 생성까지를 목표로 합니다."
왜일까요?
Windsurf의 사용자들은 대부분 IDE에서 작업 중인 개발자들입니다. 이들이 Tab을 눌러 자동완성을 받을 때, 200ms만 늦어도 손이 먼저 타이핑을 시작해 버립니다. 즉, 반응 속도가 1초 이내여도 '느리다'라고 체감되는 환경이죠.
이런 극단적인 반응속도를 위해 Windsurf는 speculative decoding, 모델 병렬화, dynamic batching, token-level 캐싱 등 다양한 기법을 조합합니다. 하지만 무엇보다 중요한 건 GPU 자원을 어떻게 쓰느냐입니다.
GPU는 메모리보다 연산력이 많다 – 진짜 병목은 어디에?
Varun은 GPU 구조를 이렇게 설명합니다.
"GPU는 CPU보다 100배 이상 빠른 연산 능력을 갖고 있지만, 메모리 대역폭은 10배 정도밖에 안 됩니다."
이 말은 곧, 연산이 충분히 복잡하지 않으면 GPU는 메모리 I/O에 막혀서 놀게 된다는 뜻입니다.
Windsurf 팀은 이 문제를 해결하기 위해 다음과 같은 전략을 씁니다.
요청을 최대한 병렬로 처리해 GPU를 바쁘게 유지
하지만 병렬 처리가 latency를 늘리지 않도록 speculative decoding을 조합
layer 수준에서 메모리-연산 최적 밸런스를 설계
이러한 전략은 모델 학습, 추론 모두에 적용됩니다.
추론 중 파인튜닝? 미친 짓일까, 혁신일까
Windsurf는 한때 기업 고객에게 자체 모델과 함께 파인튜닝 인프라를 제공했습니다.
문제는 GPU 자원이 항상 여유롭지 않다는 것. 그래서 이들은 기상천외한 방법을 도입합니다.
"inference 중 GPU가 놀고 있을 때, 남는 layer부터 backpropagation을 돌렸습니다."
심지어 inference 요청이 오면 학습을 해당 layer에서 일시 정지하고 inference를 처리한 뒤, 다시 이어서 학습을 계속합니다. 이 ‘preemptible layer-wise fine-tuning’은 한편으론 비효율적이고 복잡한 구조이지만, Windsurf는 이 과정을 통해 self-hosted 환경에서의 사용자 맞춤 모델 튜닝 실험을 할 수 있었습니다.
하지만 결론은 이렇게 납니다.
"파인튜닝은 성능을 높여주지만, 그보다 더 큰 효과는 개인화된 retrieval 시스템에서 옵니다."
즉, 파인튜닝보다는 정확한 코드 검색, 문맥 파악, 사용자 맥락 유지가 훨씬 더 실질적인 사용자 경험 향상으로 이어진다는 판단입니다.
Retrieval 시스템 = 임베딩 + 키워드 + AST + Knowledge Graph
Windsurf가 강조하는 건 단순한 벡터 검색이 아닙니다. 오히려 이렇게 말합니다.
"임베딩 검색만으로는 회귀 테스트에 실패하는 코드 패턴을 찾기 어렵습니다."
그래서 Windsurf는 다음과 같은 retrieval 전략을 사용합니다.
AST 기반 연결성 분석: 어떤 함수가 호출되는지, 어떤 모듈 간 의존성이 있는지 파악
Knowledge Graph: 특정 코드 변경이 다른 파일에 어떤 영향을 줄지 확률 기반 예측
Keyword 기반 탐색: 패턴 검색에 최적화된 빠른 루틴 적용
임베딩 검색: 의미 기반 검색으로 recall 극대화
이 모든 것을 조합한 후, 검색된 코드 조각에 대해 추론 시간에 추가 연산을 수행하여 최종 후보를 추립니다. 즉, retrieval은 indexing이 아니라 inference의 일부로 간주됩니다.
데이터센터 위치, 라우팅, 네트워크까지 신경 써야 하는 이유
속도에 목숨 거는 Windsurf에게, 물리적 거리조차 민감한 이슈입니다.
예를 들어 인도 사용자의 경우, 속도 저하의 원인이 데이터센터-인도 간 거리라기보단 현지 ISP의 혼잡이라는 사실을 실험을 통해 밝혀냈습니다.
즉, 사용자 경험 최적화를 위해선 단지 GPU를 더 빠르게 만드는 것만으론 부족합니다.
라우팅, 패킷 지연, 지역별 네트워크 품질까지 전부 고려해야 하는 상황입니다.
인프라 최적화는 제품 전략 그 자체다
Varun은 이렇게 말합니다.
"우리는 AI 스타트업이지만, 인프라 회사이기도 합니다."
Windsurf의 경우, 성능과 latency가 곧 제품의 경쟁력이며, 이는 마케팅이나 UI보다 더 강력한 사용자 리텐션 요소가 됩니다. 그리고 이 모든 걸 가능하게 만든 건, 초창기부터 인프라를 직접 구축하며 쌓아온 경험이었습니다.
3편에서는 Windsurf가 왜 '코드 전용 LLM'을 직접 학습하게 되었는지, 일반 텍스트 기반 LLM이 코드에서는 왜 부족한지, fill-in-the-middle 문제와 AST 기반 확장성에 대해 다룰 예정입니다.
