1. Coding Agent는 왜 LSP보다 grep을 선호할까?

읽은 날 : 2026-09-07

1.1. 먼저 알아둘 개념

grep
- 파일 안의 문자열을 찾는 textual/lexical search 도구
- 코드의 의미를 이해하지 않고 일치하는 문자열을 찾는다.
- 따라서 실제 메서드 호출뿐 아니라 주석, 문자열, XML, SQL 등에 존재하는 동일한 텍스트도 모두 검색할 수 있다.
LSP(Language Server Protocol)
- 에디터와 Language Server가 언어에 대한 정보를 주고받기 위한 표준 프로토콜
- Go to Definition, Find References, Diagnostics, Symbol Search 등 코드의 구조와 의미를 이용한 기능을 제공할 수 있다.
- 이 글에서는 LSP 전체가 아니라 LSP를 이용한 definition/reference 등의 semantic navigation과 grep을 비교한다.
Lexical Search vs Semantic Navigation
- Lexical Search는 이 문자열이 어디에 있는가?를 찾는다.
- Semantic Navigation은 이 symbol의 정의/참조가 어디에 있는가?를 찾는다.
- 따라서 어느 한쪽이 항상 우월한 것이 아니라 찾으려는 대상에 따라 적합한 도구가 다르다.
Harness
- LLM Agent가 실제로 동작하기 위해 모델 주위에 구성된 실행 환경
- 모델에게 주어지는 instruction, 사용할 수 있는 tool, tool의 input schema, 결과와 error의 형태, 다음 행동으로 이어지는 loop 등을 포함한다.
- 같은 모델이라도 harness를 어떻게 구성하느냐에 따라 실제 agent의 행동과 성능이 달라질 수 있다.

에이전트의 역량 = 모델 × 실행 환경

정확한 도구라고 해서 agent에게 더 좋은 도구는 아니다.
- 해당 도구로 다음 행동까지 자연스럽게 이어지느냐가 중요
grep은 바로 소비 가능한 문맥을 제공
- 반면 LSP같은 semantic tool은 symbol identifier나 위치 정보만 주고 또다시 read를 호출해야한다면 agent의 행동비용은 커질 수 밖에 없다.
즉, LLM agent가 얼마나 좋느냐도 중요하지만 **어떤 tool을 어떤 schema로 제공하고 어떤 형태로 문맥에 돌려주는지가 중요함

인간이 생각하기에 더 좋은 도구라고 해서 LLM agent에게도 좋은 도구는 아니다.
- 인간의 관점에서는 단순 textual search보다 코드의 구조와 의미를 이해하는 semantic tool이 더 고도화된 도구라고 생각하기 쉽다.
agent는 아래가 중요

text

정확도
+ 호출의 단순성 
+ 결과의 가독성 
+ 문맥의 충분함 
+ 다음 행동까지의 비용

실제 운영때를 생각해보면 semantic을 이용한 서치는 영향도 분석일 때 많지만 대부분은 textual search임
특히나 Java/Spring 환경에선 하나의 이름이 여러 파일에 존재 가능
- Xml, SQL, JSP, JS등 레거시 프로젝트를 생각한다면 textual search가 더 강할 수 있다.
[x] #task rg.exe를 실제 반입하여 이클입스에서 빠른 textual search 구현해보기 🛫 2026-09-08 📅 2026-09-09 ✅ 2026-09-08
- 이클립스 -> External Tools -> rg.exe -> Grep Console -> 결과 클릭 -> 해당 파일 이동
- [ ] #task External Tools 완료, Grep Console을 좀 더 만져야 할거같음. ➕ 2026-09-08 ⏳ 2026-09-09
- [ ] #task CFR 디컴파일러를 이용한 vscode 디컴파일러 반입하기 ➕ 2026-09-08 ⏳ 2026-09-09
예시 코드

text

rg --no-heading -n --column --color never -F "${string_prompt:검색어}" -g "*.java" .