Copilot CLI가 코드를 더 잘 찾게 됐다면, 수정 전에 무엇을 알려 줘야 할까요?

핵심 요약 (TL;DR)

GitHub의 Copilot CLI 1.0.100 변경 기록은 온라인 세션에서 의미 기반 코드 검색을 기본 활성화하고, 파일 경로에 맞는 지침을 자동 적용한다고 안내합니다.[1] 코드를 찾는 능력이 좋아져도 무엇을 바꿔야 하는지는 별도의 문제입니다. 첫 웹앱을 고칠 때는 위치를 찾는 요청과 수정 규칙을 나누어 전달해 보세요.

이번 업데이트에서 무엇이 달라졌나요?

한국 시간 10월 20일 공개된 릴리스에는 온라인 세션의 의미 기반 코드 검색 기본 활성화가 포함됐습니다. 저장소 루트의 .github/instructions에 둔 경로별 지침도, 에이전트가 해당 파일을 읽거나 수정할 때 자동 적용한다고 설명합니다.[1]

의미 기반 검색은 파일 이름만 떠올리기 어려운 상황에서 참고할 변화입니다. 다만 공식 기록은 검색 정확도의 수치나 모든 질문에서 올바른 파일을 찾는다는 보장을 제시하지 않습니다. 온라인 세션이라는 적용 범위도 오프라인까지 넓혀 해석하면 안 됩니다. 이 글에서는 기능을 직접 실행해 비교하지 않았습니다.

코딩을 모르면 어떤 질문부터 하면 좋을까요?

예약 화면에서 날짜를 바꿔도 이전 결과가 남는다고 생각해 보겠습니다. 곧바로 ‘예약 기능을 고쳐 주세요’라고 요청하기보다, 그 동작과 연결된 파일을 찾고 각 파일의 역할을 설명하도록 요청해 보세요. 다음은 실습용 제안입니다.

“날짜를 바꾼 뒤 예약 목록을 갱신하는 코드를 찾아 주세요. 아직 수정하지 말고, 입력값을 받는 곳과 결과를 표시하는 곳이 어디인지 설명해 주세요. 어느 부분이 원인인지는 확인된 사실과 추정을 나누어 주세요.”

찾은 위치가 맞는지 확인한 뒤에야 수정 범위를 정합니다. 검색 결과가 나온 것을 원인 분석이 끝난 것으로 받아들이지 않는 순서입니다. 화면에서 재현한 행동과 코드의 설명을 연결하면, 낯선 파일 이름만 나열된 답변보다 검토하기 쉬워집니다.

경로별 지침에는 무엇을 담으면 좋을까요?

전체 프로젝트의 공통 원칙과 특정 화면의 규칙을 구분해 보세요. 예를 들어 예약 화면에는 ‘날짜 변경 중에는 이전 결과를 최신 결과처럼 보이지 않게 한다’는 조건을, 테스트 쪽에는 ‘실제 예약을 생성하지 않고 샘플 자료를 사용한다’는 조건을 정할 수 있습니다. 이는 이 글의 제안이지 GitHub가 제공한 예제 지침은 아닙니다.

지침을 파일에 넣을 때는 적용 경로와 형식이 맞는지 확인하고, 에이전트에게 어떤 지침을 읽었는지 설명받으세요. 자동 적용 기능이 생겼다고 오래된 규칙까지 자동으로 올바른 규칙이 되는 것은 아닙니다. 처음에는 작은 화면 하나에만 적용해 원하는 수정이 나오는지 살펴보시는 편이 좋습니다.

검색 설정과 실행 권한은 왜 따로 봐야 할까요?

같은 릴리스는 신뢰된 저장소의 플러그인이 대화 실행 전에 자동 설치·업데이트되며, 샌드박스에서 로컬 네트워크 접근을 기본 허용한다고도 안내합니다.[1] 코드 검색을 개선한 업데이트라고 해서 검색 기능만 바뀌었다고 생각해서는 안 됩니다.

특히 localhost나 사설 네트워크의 서비스에 접근할 수 있다는 설명은 완전한 네트워크 차단과 다릅니다. 첫 실습에서는 실제 업무 서비스 대신 샘플 환경을 쓰고, 저장소를 신뢰한다는 선택에 어떤 플러그인이 따라오는지 확인해 보세요. 잘 찾는 능력과 실행해도 되는 범위는 서로 다른 점검 항목입니다.

FAQ: 지침 파일을 두면 잘못된 수정이 없어지나요?

그런 보장은 없습니다. 지침이 적용됐는지 확인한 뒤에도 변경 내용과 실제 화면을 다시 검토해야 합니다. 규칙 전달과 결과 검증을 따로 남겨 주세요.

FAQ: 첫 앱부터 모든 폴더의 지침을 만들어야 하나요?

처음에는 반복해서 틀리는 화면이나 중요한 제약이 있는 경로부터 시작해 보세요. 길고 포괄적인 문서보다 실제로 확인할 수 있는 작은 규칙을 권합니다.

출처
[1] https://github.com/github/copilot-cli/releases/tag/v1.0.100
관찰: 2026-10-20 KST