[AI 아이디어 노트 03] ColGrep-Agent: 큰 모델이 읽기 전에 로컬 탐색기가 코드를 찾는다

AI 아이디어 노트는 이제 막 등장한 AI 모델·도구의 발상과 활용 가능성을 살펴보는 연재입니다.

‘업로드가 너무 일찍 완료 처리된다’는 버그 제보가 들어왔습니다. 저장소에는 수백 개의 파일과 여러 진행 상태 처리기, 비슷한 이름의 상태 필드가 있습니다. AI 도우미는 수정안을 제안하기도 전에 완료 처리를 담당하는 코드를 찾는 데 상당한 시간을 쓸 수 있습니다.

LightOn이 2026년 10월 12일 발표한 ColGrep-Agent는 이 검색 단계를 로컬에서 처리합니다. 저장소를 탐색하고 관련 파일 경로와 줄 범위, 코드를 주 코딩 도우미에 돌려줍니다. 작은 전문 모델이 길을 찾고 큰 모델이 수정을 고민하도록 하는 ‘로컬 정찰대’에 가깝습니다. LightOn 발표

이 글에서는 구성 요소와 시작 방법, 첫 비교에서 측정할 항목을 소개합니다. 매력은 검색에 드는 부가 비용을 줄인다는 데 있습니다. 실제 사용하는 저장소와 질문, 장비에서도 그 이점이 유지되는지가 확인할 부분입니다.

2026년 10월 20일 촬영한 공개 모델 페이지입니다. 공개된 모델 카드 화면이며 작성자의 장비에서 모델이 실행됐음을 보여주는 자료는 아닙니다.

세 이름은 작업 흐름의 서로 다른 부분을 뜻한다

ColGrep은 의미 기반 검색 도구입니다. ColGrep-Agent-2B는 공개된 모델의 이름입니다. colgrep --agent 명령은 제한된 검색 실행 환경 안에서 모델을 돌립니다. 별도의 모델 제품군이 아니라 도구와 모델을 함께 사용하는 방식입니다. 공식 설명

이 구분은 어디까지 도입할지 정할 때 유용합니다. 어떤 개발자는 에이전트의 반복 실행 없이 터미널에서 의미 검색만 쓰고 싶을 수 있습니다. 다른 팀은 코딩 도우미가 로컬 에이전트에 질문하고 더 작고 집중된 문맥을 받도록 구성할 수 있습니다.

검색 시스템은 의미 기반 질문과 경로·패턴 같은 정확한 조건을 함께 사용합니다. 각각 해결하는 문제가 다릅니다. 자연어 질문은 식별자 이름을 모르는 동작을 찾는 데 도움이 되고, 스택 추적에서 복사한 함수 이름에는 정확한 문자열 검색이 여전히 유용합니다.

처음 사용하는 사람에게 중요한 출력은 간단합니다. 확인할 위치를 추린 목록입니다. 여전히 코드를 이해하고 주변 규약을 확인해야 하며, 동작을 바꾼 뒤에는 관련 테스트를 실행해야 합니다. 유용한 위치는 수정을 위한 입력이지 수정 자체는 아닙니다.

검색을 반복할수록 비용이 쌓인다

코딩 도우미는 보통 단어를 검색하고, 파일을 열고, 다른 식별자를 발견하고, 참조를 따라간 뒤 다시 검색합니다. 단계가 늘 때마다 이후 모델 호출에 들어갈 문맥도 늘어날 수 있습니다. 관리자가 쉽게 탐색하는 저장소라도 처음 접하는 도우미에는 비용이 큰 대상일 수 있습니다.

ColGrep-Agent는 이 탐색 과정을 로컬 반복 실행으로 옮깁니다. 주 도우미가 질문하면 탐색기가 후보 파일을 검색하고 읽은 뒤, 관련 있다고 판단한 위치를 반환합니다. 모든 프로그래밍 문제를 로컬 모델에 맡기는 대신 탐색의 담당을 나누는 방식입니다.

연결이 끊겼다가 다시 이어진 뒤 녹음 세션이 복구되지 않는 문제를 조사한다고 해봅시다. ‘reconnect’를 넓게 검색하면 통신 보조 함수와 UI 알림, 오래된 테스트가 함께 나올 수 있습니다. 유용한 결과는 현재 세션을 관리하는 코드와 연결을 재생성하는 함수까지 목록을 좁혀줘야 합니다.

답변이 짧다고 반드시 검색이 좋아지는 것은 아닌 이유도 여기에 있습니다. 최종 저장을 설명하는 파일 하나를 탐색기가 빼버리면 주 도우미는 자신 있게 불완전한 수정을 만들 수 있습니다. 목표는 필요한 근거를 남기면서 관련 없는 문맥을 줄이는 것입니다.

공식 문서의 역할 분담을 설명하기 위해 직접 제작한 인포그래픽입니다. 질문과 반환 위치는 예시입니다.

발표된 절감 수치는 코드 검색에 관한 것이다

LightOn은 13개 저장소의 코드 검색 질문 52개를 대상으로 grep과 비교했을 때 API 토큰 34% 감소, 캐시를 반영한 API 비용 40% 감소를 보고했습니다. 해당 비교에서 발표자가 측정한 값입니다. 애플리케이션을 만들거나 유지하는 전체 비용이 40% 줄어든다는 뜻은 아닙니다. 연구 설명

범위가 중요한 이유는 소프트웨어 작업에 여러 비용이 있기 때문입니다. 검색 비용이 줄어도 구현을 고민하는 비용은 그대로일 수 있습니다. 전체 시간에서는 테스트 실행이 가장 클 수도 있습니다. 클라우드 토큰을 절약하는 모델이 로컬 CPU와 GPU, 메모리, 인덱싱 시간을 사용할 수도 있죠.

세 가지 질문을 나눠보세요. 올바른 코드를 찾았는지, 코딩 작업이 정확히 끝났는지, 전체 작업에 어떤 자원이 들었는지입니다. 측정하기 쉬운 하나만 보면 나머지 둘은 답하지 못합니다. 팀은 발표된 비율을 보편적인 예측값으로 받아들이기보다 자기 업무에 맞는 절충점을 선택해야 합니다.

반복되는 프롬프트는 가격 비교도 복잡하게 합니다. 제공 업체에 따라 캐시된 입력, 캐시되지 않은 입력, 생성 출력의 가격이 다를 수 있습니다. 도구가 정보를 제공한다면 각각 기록하고, 사용량을 확보한 뒤 날짜를 명시한 가격표를 적용하세요.

자신 있게 검토할 수 있는 저장소부터 시작한다

공식 시작 안내에는 macOS, Windows, 소스 빌드 경로가 있습니다. 깨끗한 복사본이나 상태를 잘 아는 저장소로 시작하고 설치 프로그램을 실행하기 전에 릴리스 안내를 읽으세요. 익숙하지 않은 도구에 검토하지 않은 운영 작업 폴더를 바로 맡기는 것은 좋은 출발점이 아닙니다. ColGrep 문서

macOS에서 Homebrew를 쓴다면 LightOn 발표에 다음 명령이 나옵니다.

brew install lightonai/tap/colgrep
colgrep --install-agent

두 번째 명령은 호스팅 추론 서비스에 가입하는 대신 로컬 모델을 준비합니다. 발표에서는 기본 양자화 모델 다운로드 크기를 약 2.5 GB라고 설명합니다. 문서에 나온 다운로드 크기이지, 모든 설정에 필요한 메모리와 디스크 공간의 총합은 아닙니다. 모델 준비

Windows에서는 공식 저장소의 최신 PowerShell 설치 방법을 따라가되 실행 전에 설치 코드를 검토하세요. 사용할 수 있는 런타임과 가속 방식은 장비에 따라 다릅니다. Mac에서 명령이 성공했다고 Windows에서도 같은 설치 과정과 속도, 자원 사용량이 보장되는 것은 아닙니다.

첫 실행은 다음 순서로 진행하면 실험의 조건을 이해하기 쉽습니다.

1. 저장소 커밋과 작업 폴더 상태를 기록합니다. 관련 코드를 이미 아는 질문을 고릅니다.
2. 공식 경로로 설치한 뒤 설치된 버전의 colgrep --help와 인덱싱 안내를 읽습니다.
3. 에이전트 연동 전에 일반 의미 검색을 실행합니다. 무시할 파일과 제외 폴더가 예상대로 처리되는지 확인합니다.
4. 해당 버전 도움말의 호출 방식으로 colgrep --agent를 시험합니다. 반환한 위치를 저장소에서 하나씩 확인합니다.
5. 독립 검색이 유용할 때 지원되는 코딩 도우미에 연결합니다. 이전 검색 설정도 비교할 수 있게 남겨둡니다.

이 순서는 설치·평가 안내이며 이 글을 위해 설치를 수행했다는 보고가 아닙니다. 소개 글의 목적은 앞으로 보게 될 결과를 지어내는 대신 첫 실험을 고르기 쉽게 하는 것입니다.

파일을 지정하기보다 동작을 질문한다

좋은 검색 질문에는 사건과 찾으려는 동작이 담겨 있습니다. ‘접수된 업로드가 백그라운드 처리를 마친 뒤 어디서 완료 상태가 되는가?’는 ‘업로드 코드 찾아줘’보다 정보가 많습니다. 탐색할 규약을 알려주면서 실제 담당 코드는 발견할 여지를 남깁니다.

질문에 수정 방안을 미리 넣지 마세요. 특정 플래그를 바꿔야 할 함수만 찾으라고 하면 검색이 그 가정을 따라가며 실제 상태를 담당해야 할 구성 요소를 놓칠 수 있습니다. 사용자가 관찰한 현상에서 출발하고, 그 현상을 설명하는 구현을 확인하세요.

연습용으로 서로 다른 탐색 유형을 다루는 질문 세 가지를 써볼 수 있습니다. 요청을 어디서 인증하는지, 백그라운드 작업이 최종 결과를 어디에 저장하는지, 프런트엔드가 상태 업데이트를 어디서 구독하는지입니다. 식별자 하나를 대조하기보다 파일 사이의 책임을 따라가도록 하는 예시입니다.

정확한 문자열도 여전히 필요합니다. 스택 추적, 라우트 경로, 오류 코드가 있으면 질문을 훨씬 정밀하게 만들 수 있습니다. 관찰된 동작과 함께 제시해 검색이 실패한 작업 흐름에서 벗어나지 않도록 하세요.

설명보다 반환한 위치를 먼저 평가한다

제시한 줄을 열고 함수의 책임을 이해할 만큼 주변 코드를 읽으세요. 줄 번호가 정확해도 조건 검사, 호출자, 최종 저장 단계가 빠진 코드 조각은 오해를 줄 수 있습니다. 문맥은 그럴듯해 보이는 데 그치지 않고 주장을 확인할 수 있을 만큼 충분해야 합니다.

저장소 커밋도 중요합니다. 리팩터링 뒤에는 유용했던 경로와 줄 범위가 낡은 정보가 될 수 있습니다. 평가에 사용한 리비전과 검색 결과를 연결해두고, 소스가 바뀌면 도구의 공식 절차에 따라 인덱스를 갱신하세요.

코드 검색 시험에서는 도구의 답을 보기 전에 관리자가 기대 파일을 정하게 하세요. 그렇지 않으면 그럴듯한 위치를 받아들인 뒤 성공 기준을 바꾸기 쉽습니다. 모든 문제에 정답 파일이 정확히 하나 있다고 가정하지 말고 모호한 질문은 따로 분류하세요.

로컬 자원까지 포함해 비교한다

같은 저장소 리비전에서 같은 질문을 기존 검색과 새 방식에 각각 넣어보세요. 처음에는 일반 질문 열두 개 정도와 책임 관계를 묻는 어려운 질문 몇 개로 시작할 수 있습니다. 제안하는 시험 설계이며 공식 벤치마크나 통계적 신뢰도를 보장하는 구성은 아닙니다.

알고 있는 관련 파일이 포함됐는지, 관계없는 코드가 얼마나 반환됐는지, 클라우드 토큰과 시간이 얼마나 들었는지 기록하세요. 인덱스 생성은 반복 검색과 따로 측정합니다. 자주 쓰는 저장소에서는 초기 준비 비용을 감수할 수 있지만 한 번만 탐색할 때는 이점이 작을 수 있습니다.

직접 제작한 평가 기록표입니다. 측정 칸을 비워둔 것은 의도적입니다. 자원과 품질의 절충이 가치 있는지 판단하기 전에 직접 값을 수집하세요.

버그 수정 전체를 비교하려면 별도 실험으로 다루세요. 같은 이슈, 저장소 상태, 테스트 기준, 모델 설정을 사용하고 최종 패치를 확인합니다. 검색 질문에서 우세한 도구라도 탐색, 편집, 테스트 해석, 여러 차례 수정이 필요한 작업에서는 다르게 작동할 수 있습니다.

한 번 운 좋게 나온 실행을 믿기보다 몇몇 질문을 반복하세요. 에이전트는 시도마다 다른 탐색 경로를 선택할 수 있습니다. 평소 토큰 사용량은 줄지만 어려운 질문은 느려진다는 결론이 나올 수도 있습니다. 전체 평균 하나로는 표현하기 어려운 실제 절충입니다.

로컬 검색이 클라우드 도우미까지 오프라인으로 만들지는 않는다

LightOn은 로컬 인덱싱과 로컬 에이전트 추론을 설명합니다. 검색 단계는 장비 안에 둘 수 있지만, 연결된 클라우드 코딩 도우미는 탐색기가 고른 코드를 전달받을 수 있습니다. ‘로컬 검색’을 ‘컴퓨터 밖으로 코드가 나가지 않음’과 동일시하기보다 질문부터 최종 모델 호출까지 전체 경로를 확인하세요. 구조 설명

저장소의 제외 설정도 의도적으로 검토할 필요가 있습니다. 생성된 폴더는 잡음을 만들 수 있고, 자격 증명과 비공개 내보내기 파일은 프로젝트 폴더 아래 있다는 이유만으로 검색 대상이 되어서는 안 됩니다. 도구의 공식 무시 규칙과 조직의 평소 저장소 관리 방식을 적용하세요.

읽기 전용 검색은 탐색기의 유용한 경계지만 이후의 파일 변경까지 승인하는 것은 아닙니다. 주 도우미는 여전히 저장소 지침을 따르고 기존 작업을 보존하며 수정 결과를 검증해야 합니다. 탐색과 변경 권한은 서로 다른 책임입니다.

팀에서는 이 경계를 연동 문서에 드러내세요. 인덱스가 어디에 있는지, 어떤 모델이 로컬에서 도는지, 어떤 코드 조각이 다른 서비스에 전달되는지, 연동을 어떻게 끄는지 알 수 있어야 합니다. 책임이 명확하면 처음 도입한 사람이 떠난 뒤에도 실험을 이해하기 쉽습니다.

가장 좋은 절약은 관련 없는 탐색을 줄이는 것이다

우리가 보는 ColGrep-Agent의 의미는 역할 전문화의 실용성에 있습니다. 로컬 탐색기가 필요한 근거를 안정적으로 반환한다면 코딩 도우미가 모든 폴더 검색에 가장 비싼 추론을 쓸 필요는 없습니다. 그중 ‘안정적으로’라는 부분을 입증하는 것이 시험 도입의 역할입니다.

저장소 하나와 관리자가 판단할 수 있는 질문 하나로 시작하세요. 동작의 담당 코드를 가리지 않으면서 읽을 양을 줄인다면 시험 범위를 넓혀볼 수 있습니다. 목표는 검색 비용을 기록하면서 올바른 수정까지 가는 길을 줄이는 것입니다.

출처와 이미지

2026년 10월 20일 확인했습니다. 성능 수치는 LightOn이 발표한 코드 검색 결과입니다. 로컬 설치, 지연 시간 측정, 전체 코딩 작업 벤치마크를 수행한 결과가 아닙니다. 공개 화면은 작성자가 촬영했고 인포그래픽은 직접 제작했습니다. 출처와 라이선스 고지는 이미지 기록에 있습니다.

• LightOn 발표와 연구, 2026년 10월 12일
• ColGrep 문서와 소스
• ColGrep-Agent 모델 카드
• 저장소의 Apache 2.0 라이선스

문제와 근거를 함께 연결한다

원래 제보, 검색 질문, 관련 코드 링크, 검토 메모를 함께 남겨두세요. Telli.sh는 이런 조사 기록을 정리하는 데 도움을 줄 수 있습니다. Telli.sh 계정 만들기