VS Code Compare Models: 모델을 비교하기 전에 맞춰야 할 조건

VS Code의 Compare Models로 같은 개발 과제를 여러 모델에 맡길 때는, 결과를 보기 전에 기준 커밋과 통과 조건부터 적어 두세요. 한쪽만 다른 테스트 데이터에 접근했거나 설정이 달랐다면, 두 결과의 차이를 모델의 능력으로 설명하기 어렵습니다. 비교를 한 묶음으로 정리하는 새 기능은 어떤 조건으로 돌렸는지 기억하고 결과를 다시 찾는 데 도움이 됩니다.

Microsoft는 VS Code 1.146 Insiders의 2026년 11월 4일 항목에서 Agents 창에 비교 세션을 컬렉션으로 묶는 변경을 안내했습니다. 같은 날 기록에는 에이전트가 두 개에서 열 개 설정으로 비교를 시작하거나 비교 결과와 평가를 읽을 수 있는 변경도 들어 있습니다. 11월 10일 릴리스 노트와 비교 기능 문서를 확인했습니다. 아래 내용은 Git 저장소에서 변경안을 검토하려는 개발자를 위한 예시이며, 모델별 성능·시간·비용을 직접 측정한 결과가 아닙니다.

비교 전에 무엇을 고정하면 좋을까요?

예시 과제는 문서 사이트에 이미 있는 검색 결과 카드에서, 설명이 없는 항목에 빈 줄이 생기지 않게 하는 일입니다. 하나의 문장만 던져도 모델은 여러 방향을 고를 수 있습니다. 한 모델은 템플릿을 바꾸고, 다른 모델은 데이터에서 빈 값을 정리하고, 또 다른 모델은 레이아웃을 고칠 수 있어요. 의도한 변경 범위가 없으면 답안이 다양하다는 사실은 알 수 있지만, 팀에서 어떤 변경을 받아들여야 하는지는 판단하기 어렵습니다.

가령 과제를 이렇게 써 볼 수 있습니다. 카드의 설명에 표시할 문자가 없을 때 설명 영역만 숨깁니다. 제목과 링크는 그대로 표시하고, 설명이 있는 카드의 모양은 유지합니다. 공백만 있는 설명과 실제 문장이 있는 설명을 각각 확인합니다. 기존 스타일을 지키면서 수정한 파일과 확인 결과를 알려 달라고 요청합니다. 이 문구는 설명용 가상 과제이며, 공식 문서의 예제를 그대로 가져온 것이 아닙니다.

같은 질문이라고 해도 시작점이 다르면 기준은 어긋납니다. 비교하고 싶은 것이 모델 선택이라면 우선 같은 저장소의 같은 커밋, 같은 대상 파일, 같은 검증 항목을 기준으로 잡으세요. 도구 구성이나 모델의 추론 설정을 다르게 둔다면 차이를 기록합니다. 나중에 차이가 보였을 때 모델만 바뀐 것인지 실행 조건이 함께 바뀐 것인지 다시 확인할 수 있어요.

비교에서 고정할 항목	기록하는 이유
출발 커밋과 작업 대상	결과가 같은 코드와 문제에서 출발했는지 확인
프롬프트와 변경 범위	각 시도가 같은 요구와 제외 범위를 받았는지 확인
실행 도구와 모델 설정	접근할 수 있는 파일과 실행 조건의 차이를 구분
기대 결과와 테스트	요약 문장의 설득력과 실제 동작을 따로 확인

별도 작업 트리에서 놓치기 쉬운 것

공식 문서에 따르면 Git 저장소를 선택한 비교에서 각 시도는 저장소의 커밋된 상태를 기준으로 자기 Git 작업 트리에서 실행됩니다. 작업 트리는 같은 저장소의 내용을 별도 위치에 펼쳐 두고 수정할 수 있는 공간입니다. 원래 폴더에 저장했지만 아직 커밋하지 않은 수정이나 Git이 추적하지 않는 환경 설정·의존성은 각 작업 트리에 들어 있지 않을 수 있습니다.

예를 들어 내 폴더에서만 쓰는 작은 예제 데이터가 있어 원래 폴더에서는 테스트가 성공한다고 가정해 보세요. 작업 트리에는 파일이 없어서 모델이 만든 변경과 관계없이 테스트 준비에 실패할 수 있습니다. 이때 보고서에 “모델이 테스트를 실패했다”고만 적으면 원인을 놓칩니다. 예제가 누락됐는지, 의존성 준비가 달랐는지, 코드 변경이 실제로 실패했는지 나누어 보세요. 먼저 사용할 수 있는 공개 테스트 데이터와 실행 전제를 정해 두면 같은 파일을 다시 찾는 시간도 줄어듭니다.

작업 트리에서 파일 수정이 분리된다고 해서 에이전트의 컴퓨터나 네트워크 접근도 같은 범위로 제한되는 것은 아닙니다. 공식 문서는 저장소 비교의 작업 트리 세션이 도구 승인 프롬프트를 건너뛰는 Allow all 방식으로 작동한다고 안내합니다. 실제로 비교를 실행할 환경은 조직의 접근 승인과 에이전트 샌드박스 조건을 먼저 확인하세요. 민감한 자료가 있는 저장소라면 실험을 시작하기 전에 공개 샘플이나 승인된 별도 환경으로 문제를 옮겨 검토할 수 있습니다.

컬렉션에 남길 내용은 결과보다 조건부터

컬렉션으로 비슷한 비교 세션을 한데 모을 수 있다는 설명은, 여러 번의 비교에서 출발점과 질문을 다시 찾아볼 수 있다는 점에서 반갑습니다. 저장소와 과제가 같더라도, 이번에는 예외 입력을 추가했고 다음에는 도구 구성을 바꿨다면 한 차례의 결과처럼 읽을 수 없습니다. 팀 내부의 비교 기록에는 비교 이름과 함께 기준 커밋, 요청 문구의 버전, 실행한 설정, 확인한 결과를 남기는 방식을 생각해 볼 수 있습니다.

가상의 카드 문제로 돌아가 보죠. 첫 시도에서 설명이 비었을 때의 모양만 비교했다면, 다음 시도에서는 공백 문자만 있는 경우를 포함할 수 있습니다. 두 실험을 같은 작업 묶음에 두더라도 통과 조건이 늘었다는 점은 적어야 합니다. 결과 수치가 달라졌을 때 실제로 요구가 달라진 것인지, 같은 조건에서 구현이 달라진 것인지 비교할 수 있기 때문입니다.

이 기록을 길게 쓰기 어렵다면 최소한 한 줄씩만 남겨도 됩니다. 첫 줄은 문제와 기준 커밋입니다. 둘째 줄은 관찰한 결과와 재현 방법입니다. 셋째 줄은 빠진 확인이나 남은 검토입니다. 이 글의 기록 방식은 팀에서 시도를 다시 찾을 수 있게 하는 제안입니다. 현재 제품이 그 정보를 자동으로 모으거나 특정 형식으로 내보낸다는 의미는 아닙니다.

평가 점수와 실제 동작을 따로 읽어 보세요

공식 안내에는 저장소 비교에서 선택적으로 평가 모델인 Judge를 지정해 여러 시도를 살펴보는 흐름이 있습니다. 평가가 있으면 추천안과 이유를 보는 데 도움이 되지만, 평가가 사용한 증거와 내가 확인해야 할 동작을 연결해야 합니다. 문서에 따르면 표시되는 토큰 값은 실제 총량보다 작을 수 있고, 점수표가 화폐 단위 비용을 재는 것은 아닙니다. 도구의 토큰 표시와 계정의 실제 사용량·비용을 한 칸에 넣지 마세요.

시도에서 본 것	통합 전에 확인할 질문
설명이 간결하고 자신감 있음	요구한 동작을 실제 바뀐 파일과 테스트에서 확인했나요?
테스트 성공이 보고됨	어떤 환경에서 어떤 항목을 실행했는지 알 수 있나요?
수정 파일이 많음	요구한 범위를 넘어선 변경이 필요한 이유가 있나요?
Judge가 특정 시도를 추천	추천 근거의 테스트나 파일을 직접 다시 확인했나요?

예를 들어 한 시도가 빈 줄을 없앴는데 설명이 있는 카드의 레이아웃도 바꾸고, 다른 시도는 카드 한 군데만 수정했다고 가정해 보세요. 고르는 기준은 답변이 더 화려한 쪽이 아니라, 필요한 경우와 기존 동작을 함께 통과했는지입니다. 테스트가 없는 동작은 화면을 확인할 방법을 정하고, 확인할 수 없으면 미확인으로 남깁니다. 실패한 시도도 원인을 기록해 두면 다음 프롬프트의 조건을 더 정확히 쓸 수 있습니다.

검토자는 먼저 평가표를 보지 않고 두 시도의 파일을 같은 항목으로 읽어 볼 수도 있습니다. 예시 과제에서는 먼저 설명이 있는 카드의 변경 여부, 다음으로 공백만 있는 카드의 결과를 확인합니다. 그 다음 평가표가 어떤 근거로 추천했는지 펼쳐서 직접 확인한 내용과 맞춰 보세요. 평가가 새로 추가한 테스트를 높이 봤더라도, 그 테스트가 공백이 아닌 단순 빈 문자열만 다룬다면 아직 하나의 조건이 남아 있습니다. 이런 차이는 모델 점수보다 실제 요구를 충족했는지에 더 직접적인 근거가 됩니다.

한 번 비교한 결과를 팀의 영구적인 모델 선택으로 옮기기도 어렵습니다. 이 예시에서 유용했던 시도가 다른 언어나 다른 규모의 변경에서도 같은 선택일지는 별도의 질문입니다. 사용 중인 과제 유형 하나에 대해 어떤 조건을 통과했는지와 검토 시간에 영향을 준 일을 남겨 보세요. 변경을 통합하기 전에 취소해야 한다면 원래 작업 트리와 결과가 있는 작업 트리를 구분해, 필요한 기록과 변경을 보존한 상태로 팀의 정리 절차를 따릅니다.

여러 결과를 합치기 전에 한 가지를 선택합니다

두 변경의 장점을 합칠 필요가 있다면 공식 문서에 나오는 합성 흐름을 참고할 수 있습니다. 저장소 비교에서 평가와 합성 모델을 설정했을 때, 합성은 이전 시도들의 강점을 참고해 또 다른 작업 트리에서 새 결과를 만듭니다. 두 결과를 묶었다는 이유로 이미 통과한 구현과 같다고 볼 수는 없습니다. 합친 결과에서 기존 제한과 테스트를 다시 확인한 뒤 통합하는 방식이 문서가 안내하는 흐름입니다.

작업을 가볍게 확인하는 날에는 모든 옵션을 쓰지 않아도 됩니다. 변경 요구가 작고 기준이 뚜렷하다면 두 결과에서 변경 파일과 확인 항목부터 대조하는 편이 설명하기 쉽습니다. 질문의 목표가 토론용 설계 아이디어라면 코드 변경이나 테스트 결과를 기대하지 않아도 됩니다. 비교 종류를 먼저 적어 두면 답변을 읽는 기준이 달라져야 하는 경우를 구분할 수 있습니다.

원격 에이전트가 띄운 테스트 화면을 보는 문제는 VS Code 원격 미리보기에서 호스트를 구분하는 글에서 다뤘습니다. 이번 비교에서는 어느 호스트의 화면인지에 더해, 화면에 보인 결과가 어떤 작업 트리의 변경에서 나온 것인지도 함께 확인할 수 있습니다.

자주 나오는 질문

Compare Models 메뉴가 보이지 않아요. 공식 문서 기준 비교는 Agents 창의 미리보기 기능입니다. 현재 설치 버전과 창의 종류, 사용할 수 있는 에이전트와 조직 정책, 비교 기능 설정을 먼저 확인하세요. 메뉴가 보이도록 조직의 제어를 바꿀 필요는 없습니다.

같은 모델을 여러 번 넣어도 비교가 되나요? 문서는 추론 노력 설정을 제공하는 모델에서는 같은 모델을 다른 설정으로 추가할 수 있다고 안내합니다. 비교 목적이 설정 차이라면 모델명과 각 설정을 함께 적어 두세요.

추천안이 나왔으니 바로 합쳐도 될까요? 변경 파일과 테스트를 팀의 통과 조건과 대조하고, 준비된 결과만 기존 통합 절차로 옮기세요. 비교에서 추천이 나온 것과 저장소에 반영된 것은 각각 확인할 수 있습니다.

확인한 공식 자료

2026년 11월 10일 VS Code 1.146 Insiders 릴리스 노트, Compare model results 공식 문서, 세션 컬렉션의 Microsoft 저장소 이슈를 확인했습니다. 릴리스 노트의 날짜는 새 정리 기능의 근거이며, 실행·평가 조건은 제품 문서에서 확인했습니다.

같은 시작점과 통과 조건에서 변경 파일, 테스트, 평가의 근거를 비교하는 순서입니다.