Long-Distance NES — VS Code Copilot이 커서 너머까지 코드를 고치는 방법

함수 이름을 하나 바꿨다. 이제 그 함수를 호출하는 곳이 파일 곳곳에 흩어져 있다. 커서는 상단에 있는데, 바꿔야 할 호출부는 300줄 아래에 있다. 기존 Copilot의 Next Edit Suggestions(NES)는 커서 근처만 봤기 때문에, 그 300줄 밖은 보이지 않았다. Long-Distance NES는 이 한계를 깼다. 커서가 어디 있든, 파일 어느 위치의 편집이 필요한지 예측하고 제안한다.

---

NES란 무엇인가

Next Edit Suggestions는 현재 편집 흐름을 보고 "다음에 어디를 고칠지"를 예측하는 기능이다. 자동완성이 "지금 타이핑하는 곳"을 채워준다면, NES는 "지금 편집 흐름상 다음에 손댈 곳"을 미리 제안한다.

핵심 차이: 자동완성은 커서 위치에서 앞을 채운다. NES는 편집 의도의 흐름을 따라 다음 수정 지점을 예측한다.

기존 NES는 커서 주변의 좁은 범위만 대상으로 했다. 같은 파일 안에 있더라도 수백 줄 떨어진 곳은 제안 대상이 아니었다. Long-Distance NES는 이 범위를 파일 전체로 확장한 것이다.

[💡 잠깐! 이 용어는?] NES(Next Edit Suggestions): 현재 편집 패턴을 분석해 "다음에 수정할 가능성이 높은 코드 위치와 내용"을 자동으로 제안하는 VS Code Copilot의 기능. 탭 키로 수락할 수 있다.

---

기존 NES와 Long-Distance NES 비교

항목	기존 NES	Long-Distance NES
제안 범위	커서 근처 (수 줄 이내)	파일 전체
예측 대상	단일 위치	멀리 떨어진 임의 위치
모델 구조	단일 모델	Location Model + Edit Generation Model
학습 방식	Supervised finetuning	SFT + RLVR 2단계
UX	인라인 제안	커서 옆 경량 위젯 + diff 하이라이팅

기존 NES가 "바로 옆 동료에게 말 걸기"라면, Long-Distance NES는 "회의실 저쪽에 앉은 사람에게 필요한 자료를 미리 건네주기"에 가깝다.

---

어떻게 동작하는가 — 2모델 아키텍처

Long-Distance NES의 핵심은 하나의 모델이 모든 걸 처리하지 않는다는 점이다. 두 모델이 역할을 나눈다.

Location Model — 어디를 고칠 것인가

Location Model은 현재 편집 컨텍스트를 입력받아 "파일의 어느 위치를 다음에 편집해야 하는가"를 예측한다. 현재 커서 위치, 최근 변경 이력, 주변 코드의 구조를 함께 보고 점프 여부와 목적지를 결정한다.

비유하면 GPS 내비게이션의 경로 계산과 같다. 내비는 현재 위치와 주변 도로 상황을 보고 "다음 교차로에서 우회전"이라고 알려준다. Location Model은 코드의 현재 상태를 보고 "300줄 아래 이 함수 호출부가 다음 수정 대상"이라고 판단한다.

Edit Generation Model — 무엇으로 고칠 것인가

Location Model이 위치를 결정하면, Edit Generation Model이 그 위치에 무엇을 제안할지 생성한다. 현재 편집 의도(함수명 변경, 타입 수정 등)에 맞춰 해당 위치의 코드를 어떻게 바꿀지 diff 형태로 만들어낸다.

[💡 잠깐! 이 용어는?] Supervised Finetuning(SFT): 레이블이 붙은 데이터(입력-정답 쌍)로 모델을 학습시키는 방법. 여기서는 "이 편집 이후 실제로 어디를 고쳤는가"라는 실제 개발자 행동 데이터를 정답으로 사용한다.

---

훈련 과정 — 두 단계의 최적화

1단계: Supervised Finetuning + Grid Search

먼저 실제 코드 편집 데이터로 기본 모델을 훈련한다. 개발자가 편집 A를 한 뒤 실제로 파일의 다른 위치 B를 편집했다면, (A → B) 쌍이 훈련 데이터가 된다.

훈련 단계	방법	목표
1단계	SFT + Grid Search	기본 편집 패턴 학습
2단계	RLVR	선택적 제안 능력 학습

2단계: RLVR — 제안할지 말지를 스스로 판단

SFT만으로는 모델이 "너무 자주 점프"하는 문제가 생겼다. 조금만 관련이 있어도 멀리 뛰어가서 제안을 남발했다. 이건 실제 사용에서 노이즈가 된다.

[💡 잠깐! 이 용어는?] RLVR(Reinforcement Learning with Verified Rewards): 검증 가능한 보상 신호를 사용하는 강화학습. 모델의 출력이 실제로 맞았는지 여부를 명확하게 측정할 수 있을 때 사용한다. "정답을 맞히면 보상, 불필요하게 제안하면 패널티" 형태로 동작한다.

RLVR 단계에서 모델은 "제안해서 맞았을 때"뿐만 아니라 "불필요한 제안을 자제했을 때"도 보상을 받도록 설계됐다. 이 과정에서 데이터셋을 "점프 안 해도 되는 예시"를 더 많이 포함하도록 재구성했다. 결과적으로 모델이 확신이 있을 때만 멀리 뛰어가는 선택적 판단을 배우게 됐다.

---

UX — 어떻게 보이는가

제안이 현재 커서와 멀리 떨어진 곳에 있을 때, 화면을 갑자기 스크롤시키거나 팝업을 띄우면 편집 흐름이 끊긴다. VS Code의 해법은 두 가지다.

• 커서 옆 경량 위젯: 현재 커서 위치 근처에 작고 눈에 잘 띄지 않는 위젯을 표시한다. "파일 아래쪽에 제안이 있다"는 것만 알린다.
• diff 스타일 하이라이팅: 탭 키를 누르면 에디터가 해당 위치로 이동하면서 변경 내용을 diff 형태로 강조해서 보여준다.

비유하면 카카오맵에서 길을 안내할 때 "300m 앞에서 우회전"을 미리 알려주는 것과 같다. 지금 당장 핸들을 꺾을 필요는 없지만, 다음에 뭘 해야 하는지 인지하고 있을 수 있다.

---

A/B 테스트 결과

Microsoft가 공개한 A/B 테스트 결과는 하나의 수치로 요약된다.

Long-Distance NES를 활성화한 그룹은 NES를 통해 작성된 코드 양이 23% 증가했다.

이 수치는 "제안이 더 많이 떴다"가 아니라 "제안을 더 많이 수락했다"는 의미다. 관련 없는 곳에 자꾸 뜨는 제안은 무시된다. 23%는 제안의 정확도가 실제 개발 흐름과 맞아떨어졌다는 지표다.

---

실제로 어디에 쓰이나

Long-Distance NES가 빛을 발하는 상황들은 명확하다.

함수 이름 변경: fetchUser를 getUser로 바꿨다. 같은 파일에 호출부가 7개 있다. NES가 각각의 위치를 순서대로 안내한다.

파라미터 타입 변경: 함수 시그니처에서 id: number를 id: string으로 바꿨다. 이 함수를 호출하는 곳에서 숫자 리터럴을 문자열로 바꿔야 한다. NES가 그 위치들을 찾아준다.

함수 시그니처 업데이트: 새 파라미터를 추가했을 때, 기존 호출부에 기본값이나 새 인자를 추가해야 하는 위치들을 제안한다.

---

정리

• Long-Distance NES는 기존 NES의 제안 범위를 파일 전체로 확장한다
• Location Model(어디) + Edit Generation Model(무엇) 2모델 구조로 동작한다
• 훈련은 SFT로 기본 패턴을 학습하고, RLVR로 선택적 판단 능력을 추가한다
• "너무 자주 점프"하는 문제는 no-jump 예시를 늘린 데이터 재구성으로 해결했다
• UX는 편집 흐름을 끊지 않는 경량 위젯 + diff 하이라이팅으로 구현됐다
• A/B 테스트에서 NES를 통한 코드 작성량이 23% 증가했다
• 다음 단계는 크로스 파일 제안과 통합 모델이다

함수 이름 하나를 바꿀 때마다 파일 전체를 스크롤하며 호출부를 찾던 수고가, 탭 키 몇 번으로 끝나는 시대가 가까워지고 있다.

---

참고:

• VS Code Blog — Long-Distance Next Edit Suggestions: https://code.visualstudio.com/blogs/2026/02/26/long-distance-nes