로컬 코딩 AI용 컴퓨터, 자동완성과 에이전트는 다르게 고릅니다

TypeScript 폼을 작성할 때 자동완성은 커서 뒤에 이어질 짧은 코드를 제안해요. 제안이 정확하더라도 도착 전에 다음 줄을 이미 썼다면 도움이 줄어요. 같은 파일에서 제안이 나온 시점, 수락 여부, 수락 뒤 고친 부분을 기록해요. 채팅에서 완성된 함수를 만드는 일은 결과 전체를 읽고 붙이는 작업이고, 타이핑 중 제안을 쓰는 일은 현재 줄과 변수 흐름에 맞는지 바로 판단하는 작업이에요.

사용 중인 편집기가 해당 모델을 지원하는지 먼저 확인하고, 제안이 프로젝트의 변수명과 코드 스타일을 따르는지 살펴요. 완성 함수를 붙인 뒤 변수명을 고치는 일과 괄호나 조건식을 한 줄씩 추천받는 일은 검토 기준이 달라요. 실제 편집기에서 자주 쓰는 파일을 열고 제안을 수락한 뒤 수정량까지 기록해야 자동완성이 작업 흐름을 돕는지 알 수 있어요.

초대 코드 검사 함수를 고친다면 빈 문자열과 스페이스 세 칸은 거부하고 AB-12는 그대로 허용한다는 기준을 정해요. 길이만 검사하면 공백 세 칸도 통과할 수 있으므로 앞뒤 공백을 제외한 뒤 빈 값인지 확인해야 해요. 공백 검사를 위해 계산한 값을 그대로 저장할 필요는 없어요. 정상 코드의 대소문자나 저장 형식까지 바꾸면 요청 범위를 벗어날 수 있어요.

재현 입력과 현재 결과, 기대 결과를 모델에 전달하고 관련 함수와 호출부만 보여 줘요. diff에서는 바뀐 파일과 수정 범위를 확인하고, 테스트에서는 세 사례의 실제 결과를 봐요. 자동 테스트가 없다면 입력 세 개를 직접 넣는 작은 재현을 만들 수 있어요. 한 사례가 통과해도 폼 전체가 고쳐졌다고 보지 말고, 검증 함수와 화면의 제출·오류 표시 흐름을 따로 확인해요. 화면이 제출을 막고 오류 안내를 지우는지도 살펴야 사용자가 정책을 실제로 경험할 수 있어요.

테스트에서 실패하면 검증 로직이 잘못됐는지, 화면이 값을 전달하는 과정에서 문제가 생겼는지 구분해요. 두 계층 모두 바꿔야 한다면 어떤 곳이 규칙을 책임지는지 먼저 정하고, 수정된 파일을 필요한 범위로 제한해요. 이렇게 하면 한 화면의 예외 처리가 다른 폼의 동작까지 바꾸는 일을 줄일 수 있어요.

여러 파일을 수정하는 에이전트는 요청, 코드, 앞선 답변, 도구 결과를 문맥으로 사용해요. 초대 코드 규칙이 화면과 테스트에 걸쳐 있다면 관련 파일을 함께 찾아 전달해요. 저장소 전체를 넣으면 요청과 무관한 코드까지 섞여 필요한 위치를 찾기 어려워질 수 있어요. 긴 문맥은 자료를 더 담을 뿐, 올바른 파일을 자동으로 골라 주지는 않아요.

규칙이 있는 함수와 이를 호출하는 화면, 기존 테스트를 함께 찾아요. 비슷한 이름의 다른 폼을 고쳤다면 검색 경로부터 바로잡아요. 올바른 파일을 읽고도 함수와 화면의 연결을 놓친 경우에는 ‘검증 함수 수정, 호출부 확인, 오류 표시 확인’처럼 단계별로 계획해요. 기존 테스트에는 함수 이름만으로 알 수 없는 예외 정책이 담길 수 있으므로 수정 전에 읽고, 에이전트가 설명한 변경 이유가 실제로 읽은 파일과 맞는지 확인해요.

파일 읽기, 수정 적용, 테스트나 패키지 설치 명령 실행은 저장소와 환경에 미치는 영향이 달라요. 처음부터 저장소 전체와 터미널·설치 권한을 함께 열지 말고, 우선 읽기만 허용해 필요한 파일을 찾게 해요. 수정 단계에서는 변경 diff를 확인하고, 테스트는 실행 명령이 무엇을 건드리는지 이해한 뒤 맡겨요. 로컬 모델을 쓴다는 사실만으로 검색 도구나 외부 API¹까지 로컬에서 처리된다고 볼 수는 없어요.

초대 코드 수정은 사본이나 별도 브랜치에서 시험하고, 비밀키와 실제 고객 자료는 입력하지 않아요. 테스트가 네트워크나 설치를 요구하면 파일 수정 권한과 별도로 실행 환경을 살펴요. 민감한 저장소라면 외부 전송 가능성이 있는 도구를 제외하고 되돌릴 수 있는 사본에서만 실행 권한을 시험해요.

같은 TypeScript 폼 작업으로 후보를 비교해요. 자동완성은 제안이 타이핑 흐름에 맞는지, 함수 수정은 빈 값과 공백 입력이 거부되고 AB-12가 유지되는지, 에이전트는 수정 범위와 테스트가 맞는지 확인해요. 여러 역할을 함께 쓸 계획이면 실제로 사용할 모델 조합과 동시 실행도 시험해요. 짧은 제안 속도만으로 여러 파일 작업이 끝나는 시간을 예상하지 않아요.

가상의 두 수정안을 비교해 볼게요. A는 코드 생성에 15초가 걸리고 사람이 90초 더 고쳐 총 105초, B는 생성에 30초가 걸리고 20초만 손봐 총 50초예요. 생성이 느린 B가 전체 작업은 먼저 끝내는 사례예요. 이 숫자는 설명을 위한 가정이지 특정 모델을 측정한 결과가 아니며, 두 안의 테스트와 사람 검토 수준을 같게 해야 비교가 공정해요. 속도 비교로 후보를 좁힌 다음 실제 폼 작업을 테스트까지 끝내고, 현재 장비로 수정과 검토가 원활하다면 구매를 미뤄도 돼요.