AI 코딩 컨텍스트를 전체와 선별로 한 달 나눠 써봤더니

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

같은 AI 코딩 에이전트인데도 어떤 날은 기존 구조를 정확히 읽고, 어떤 날은 멀쩡한 함수를 새로 만들어 버렸습니다. 모델보다 먼저 의심해야 할 것은 AI 코딩 컨텍스트를 얼마나, 어떤 방식으로 제공했는가였습니다.

한 달 동안 업무 성격이 비슷한 저장소에서 두 방식을 번갈아 사용했습니다. 한쪽은 저장소 전체를 인덱싱해 넓게 탐색하게 했고, 다른 쪽은 작업에 필요한 파일과 규칙만 골라 전달했습니다. 편의성은 전체 컨텍스트가 앞섰지만, 수정 범위와 검토 비용까지 계산하자 승부는 예상보다 복잡했습니다.

전체 컨텍스트 vs 선별 컨텍스트, 첫 주부터 차이가 났다

넓게 읽히면 탐색은 빠르고 판단은 흔들렸다

전체 컨텍스트 방식은 저장소 인덱싱, 의미 기반 검색, 연관 파일 자동 첨부처럼 에이전트가 넓은 범위를 탐색하게 만드는 접근입니다. 처음 보는 프로젝트에서 로그인 흐름이나 주문 처리 구조를 물었을 때는 강력했습니다. 컨트롤러에서 서비스, 저장소, 테스트 파일까지 사람이 경로를 지정하지 않아도 찾아냈기 때문입니다.

문제는 ‘관련 있어 보이는 코드’가 ‘이번 변경에 필요한 코드’와 같지 않다는 점입니다. 오래된 구현, 사용하지 않는 실험 폴더, 이름이 비슷한 다른 도메인의 클래스가 함께 검색되면 답변이 길어지고 수정 제안도 넓어졌습니다. 특히 모노레포에서는 다른 애플리케이션의 인증 코드를 참고해 현재 서비스에 존재하지 않는 패턴을 끌어오는 일이 있었습니다.

반면 선별 컨텍스트 방식은 담당자가 대상 파일, 인터페이스, 테스트, 코딩 규칙을 직접 묶어 전달합니다. 시작할 때 3~7분 정도 손이 더 갔지만 변경 파일 수가 줄었고, “왜 이 파일까지 수정했지?”라는 리뷰 질문도 눈에 띄게 감소했습니다. 독자님의 풀 리퀘스트가 자주 커진다면 모델 성능보다 입력 범위가 먼저 문제일 수 있습니다.

• 전체 컨텍스트 우세: 구조 파악, 영향 범위 탐색, 처음 맡은 저장소 조사
• 선별 컨텍스트 우세: 작은 버그 수정, 명확한 기능 추가, 리뷰 범위 통제
• 전체 방식의 함정: 오래된 코드와 유사 이름 파일까지 근거처럼 취급할 수 있음
• 선별 방식의 함정: 호출부나 공통 규칙을 누락하면 국소적으로만 맞는 코드가 생성됨

컨텍스트는 많이 넣는 자료 창고가 아니라, 에이전트가 이번 작업에서 참고할 증거의 경계입니다.

속도 vs 정확도를 작업 기록으로 맞붙여 봤다

완료 시간보다 재작업 시간을 함께 세야 한다

비교할 때 ‘첫 코드가 나온 시간’만 보면 전체 컨텍스트가 압승합니다. 자연어로 요구사항을 입력한 뒤 에이전트가 파일을 찾아 초안을 만드는 시간이 짧기 때문입니다. 하지만 초안 생성 속도는 개발 완료 속도가 아닙니다. 저는 작업별로 첫 제안까지 걸린 시간, 사람이 제거한 변경 수, 테스트 재실행 횟수, 리뷰 수정 횟수를 함께 기록했습니다.

전체 컨텍스트는 탐색형 업무에서 유리했습니다. 오류 메시지만 알고 원인을 모르는 상황에서는 에이전트가 로그 처리기와 공통 예외 계층까지 찾아 후보를 제시했습니다. 선별 방식이었다면 담당자가 먼저 관련 파일을 찾아야 했을 것입니다. 반대로 결제 금액 반올림 규칙처럼 변경 지점이 분명한 업무에서는 선별 컨텍스트가 더 안정적이었습니다. 대상 구현과 테스트, 도메인 규칙만 제공하니 주변 리팩터링을 제안하지 않았습니다.

다음 비교표처럼 작업 종류를 나누면 어느 한쪽을 무조건 표준으로 정하는 실수를 피할 수 있습니다. 핵심은 토큰 사용량 자체보다 검증해야 할 가설과 변경 범위가 얼마나 늘어났는지입니다.

1. 원인을 모르는 장애나 구조 질문은 전체 탐색으로 시작합니다.
2. 수정 후보가 정해지면 관련 파일만 남겨 선별 컨텍스트로 전환합니다.
3. 생성된 패치의 변경 파일 수가 예상보다 많으면 즉시 범위를 다시 줄입니다.
4. 테스트 실패를 고칠 때는 실패 로그 전체보다 첫 실패와 관련 테스트를 우선 제공합니다.

승자는 작업 단계에 따라 바뀌었다

대결 결과를 한 문장으로 압축하면 탐색전은 전체 컨텍스트, 수정전은 선별 컨텍스트였습니다. 저장소 전체 인덱싱을 켜 두더라도 실제 구현 명령에는 대상 디렉터리와 금지 범위를 명시하는 혼합 방식이 가장 실용적이었습니다. “관련 코드를 찾아라”와 “찾은 모든 코드를 바꿔도 된다”는 전혀 다른 권한이기 때문입니다.

편의성 vs 보안, 많이 보여주는 방식의 숨은 비용

비밀값만 가리면 충분하다는 생각이 위험했다

전체 컨텍스트의 비용은 토큰이나 응답 속도에만 있지 않습니다. 저장소에는 소스 코드 외에도 내부 URL, 고객사 식별자, 운영 절차, 예외 메시지, 오래된 인증 샘플이 남아 있을 수 있습니다. 비밀키가 아니더라도 이 정보들이 결합되면 시스템 구조를 추론하는 단서가 됩니다. 관련 개념은 네이버 지식백과의 코드 보안 설명과 코드 보안 요약도 함께 참고할 만합니다.

선별 컨텍스트는 노출 면적을 줄이는 데 유리하지만 자동으로 안전해지는 것은 아닙니다. 담당자가 로그 파일을 그대로 붙이거나 테스트 픽스처에 실제 고객 데이터를 복사했다면 파일 수가 적어도 위험합니다. 반대로 전체 인덱싱 도구라도 제외 규칙, 데이터 보존 정책, 학습 사용 여부, 접근 제어와 감사 로그가 명확하다면 관리 가능한 선택이 될 수 있습니다.

팀에서는 도구 이름보다 무엇이 수집되고 어디에 저장되며 누가 조회할 수 있는지를 먼저 문서화해야 합니다. 개인 계정으로 편리하게 연결한 저장소가 회사의 승인된 처리 경로를 벗어나지는 않는지도 확인해야 합니다. 특히 협력사 코드나 라이선스 제한이 있는 모듈은 기술적으로 읽을 수 있다는 이유만으로 컨텍스트에 넣어서는 안 됩니다.

• 인덱싱 제외: 환경 변수 파일, 인증서, 덤프, 운영 로그, 백업 디렉터리
• 권한 분리: 에이전트가 읽을 저장소와 쓰기를 허용할 브랜치를 따로 제한
• 보존 확인: 프롬프트와 첨부 코드의 저장 기간, 삭제 방법, 학습 사용 조건 점검
• 민감도 표시: 고객 데이터와 계약상 외부 전송 금지 코드에 별도 라벨 부여
• 패치 검증: 생성 코드에 내부 경로나 토큰 형식이 복제되지 않았는지 검색

보안 검토의 질문은 “AI가 코드를 보았는가”에서 끝나지 않습니다. 어떤 코드가 어떤 계정과 정책 아래 전송·보존·재사용되는지까지 이어져야 합니다.

내일 첫 작업은 6파일 컨텍스트로 시작해 보자

작게 묶고 필요할 때 한 장씩 추가한다

당장 적용하려면 거대한 규칙 문서부터 만들 필요가 없습니다. 내일 처리할 작은 버그 하나를 골라 최대 6개 파일로 컨텍스트 팩을 구성해 보세요. 구현 파일 하나, 직접 호출부 하나, 인터페이스나 타입 정의 하나, 기존 테스트 하나, 프로젝트 규칙 하나, 실패 로그 또는 요구사항 하나면 충분합니다. 여섯 칸을 채우는 것이 목적은 아니며 필요 없는 칸은 비워도 됩니다.

에이전트에게는 “이 자료만 보고 수정하라”보다 “먼저 누락된 의존성이 있는지 말하고, 확인 전에는 파일을 추가 수정하지 말라”고 요청하는 편이 좋습니다. 그러면 선별 컨텍스트의 가장 큰 약점인 누락을 탐색 단계에서 드러낼 수 있습니다. 추가 파일이 필요하다는 답을 받으면 이유를 확인한 뒤 한 장씩 보태고, 패치가 끝나면 실제 변경 파일 수와 처음 예상한 범위를 비교합니다.

전체 컨텍스트와 공정하게 겨루려면 같은 유형의 다음 작업에서는 저장소 탐색을 허용하되 수정 가능 경로만 제한해 보세요. 두 작업의 초안 속도보다 리뷰 코멘트 수, 되돌린 변경, 테스트 재실행 횟수를 기록하면 팀에 맞는 기준이 생깁니다. 체감이 아니라 작업 기록으로 선택해야 ‘우리 모델은 원래 이렇다’는 막연한 평가를 벗어날 수 있습니다.

1. 10~30분 안에 끝낼 수 있는 실제 버그 하나를 고릅니다.
2. 관련 자료를 최대 6개 파일로 묶고 각 파일을 넣은 이유를 한 줄씩 적습니다.
3. 에이전트에게 누락 가능성과 예상 변경 파일을 먼저 답하게 합니다.
4. 승인한 범위 안에서만 패치를 만들게 하고 테스트를 실행합니다.
5. 리뷰 후 불필요했던 파일과 빠졌던 파일을 기록해 다음 컨텍스트 팩에 반영합니다.

복사해서 쓸 수 있는 첫 요청문

“첨부한 파일은 이번 버그의 선별 컨텍스트다. 바로 수정하지 말고 먼저 원인 가설, 누락 가능성이 있는 의존성, 수정이 필요한 파일 목록을 제시하라. 승인 전에는 첨부 범위 밖의 파일을 변경하지 말고, 승인 후에는 기존 테스트를 우선 보강하라.” 이 문장을 내일 첫 업무의 작은 버그에 그대로 붙여 넣고, 에이전트가 요구하는 일곱 번째 파일이 정말 필요한지부터 판단해 보세요.