IDE 안에서 쓰는 AI - 범위 지정과 변경 검토
이 장에서 배우는 것
에디터에서 규칙 적용·편집 범위·diff·검사 결과를 연결하고 UI가 달라도 같은 검토 절차를 따른다.
에디터에서는 선택한 범위부터 확인한다
요약 도구의 오류를 고치려고 현재 선택 영역만 전달했는데 호출부의 규칙은 빠질 수 있다. 반대로 전체 작업 공간을 연결하면 불필요한 파일까지 읽게 될 수 있다. 먼저 수정 대상 함수와 그 함수를 사용하는 곳, 기대 동작을 정의한 검사를 찾아 표시한다. 화면의 선택 영역이 실제 전달된 맥락 전체와 같은지는 도구의 문서와 실행 기록으로 확인한다.
변경을 시작하기 전에 Git 상태를 읽는다. 이미 편집 중인 파일이 있다면 무엇이 이전 변경인지 구분할 수 있어야 한다. 교재 실습은 새 저장소에서 시작하거나 별도 브랜치를 사용한다. 기존 작업을 지우는 초기화 명령으로 실습 환경을 맞추지 않는다. 작업 범위를 좁히는 것이 기존 결과를 지우는 이유가 되어서는 안 된다.
규칙 파일은 적용 결과까지 확인한다
Cursor 프로젝트 규칙은 파일 범위나 호출 방식에 따라 적용될 수 있다. 확장자가 다른 파일을 같은 폴더에 넣었다고 같은 규칙으로 읽히는 것은 아니다. Kiro는 프로젝트 Steering을 .kiro/steering에 둔다고 설명한다. 독자는 하나의 에디터만 선택해 짧은 규칙을 만들고 실제 작업에서 그 규칙이 쓰이는지 확인하면 된다.
VS Code와 Copilot, JetBrains와 Junie 등 다른 조합을 사용하는 독자는 각 제품의 해당 버전 문서를 확인한다. 이 장은 열람하지 않은 UI 메뉴 이름이나 단축키를 고정 안내하지 않는다. 화면이 달라도 프로젝트 열기, 규칙 확인, 변경 제안, diff 검토, 검사 실행이라는 단계는 직접 기록할 수 있다.
모델 연결과 에이전트 연결을 구분한다
Zed 공식 개요는 자체 에이전트, 별도 프로세스로 실행되는 외부 에이전트, 모델 연결을 나누어 설명한다. 그러므로 모델 연결만 바꿨다고 모든 도구의 권한과 규칙이 바뀐다고 생각하면 안 된다. 외부 에이전트를 선택했다면 어느 프로세스가 명령을 실행하는지 확인한다.
변경 수락 전 diff에서 목적과 관계없는 포맷 변경, 의존성 추가, 검사 삭제를 찾는다. 검사 통과만 보고 삭제된 검사를 놓치면 평가 기준 자체가 사라질 수 있다. 승인 버튼은 편집을 반영하는 동작이고, 그 편집이 적절하다는 판단은 별도다. 작은 수정 하나를 명세와 대응시켜 읽는 연습을 반복한다.
| 항목 | 관찰·기대값 | 판단할 때 주의 |
|---|---|---|
| 맥락 선택 | 함수·호출부·검사 | 화면 선택과 전달 범위 대조 |
| 규칙 적용 | 제품별 규칙 위치 | 읽혔는지 실제 확인 |
| 변경 수락 | diff·검사·종료 코드 | 검사 삭제·범위 확대 검토 |
직접 해 보기
에디터 하나에서 대출 건수라는 출력 문구를 대출 수로 바꾸는 작은 변경을 제안받는다. 검사 파일에도 옛 문구가 있는지 확인하고, 목적과 무관한 변경이 섞였다면 따로 표시한다. 실제 AI 기능이 없다면 diff를 손으로 작성해도 된다.
해설과 확인 기준
완료 기록에는 바뀐 문자열, 영향을 받는 검사, 실제 실행 결과가 있어야 한다. 검사 기대값을 새 문구로 바꾸는 것은 가능하지만 실패를 피하려고 검사 전체를 삭제하는 것은 다른 변경이다. 이유 없는 의존성 추가나 광범위한 이름 변경은 이 요구의 완료 조건에 포함되지 않는다.
| 질문 | 완료 증거 |
|---|---|
| 핵심 구분을 설명할 수 있는가 | 작업 전와 수정 제안의 차이를 자기 말로 설명 |
| 실습의 판단 근거가 있는가 | 검사 삭제 diff도 확인의 관찰 기록 |
| 확인하지 않은 부분을 구분했는가 | 출처 확인·실행 확인·미확인 상태를 구분 |
근거와 기준일
제품·자료 확인일: 2026-11-08. 설명 틀·대출 도구·연습·해설은 교재의 자체 구성이다. 제품별 세부 조건은 아래 공식 문서에서 해당 실행 방식과 계정 범위를 다시 확인한다.