데이터로서의 코드 (Korean Edition)

제3장. 코드베이스쿼리 —찾을 수 없는 것 찾기

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

코드베이스에 대한 모든 의미 있는 변경은 다음과 같은 질문에서 시작됩니다. ‘이것은 어디에서 사용되고 있는가? ’, ‘누가 이것에 의존하고 있는가?’, ‘어떤 서비스가 여전히 이 더 이상 사용되지 않는 API를 호출하고 있는가?’ 이러한 질문에 대한 답은 무엇을 읽고, 무엇을 수정하며, 결국 무엇을 출시할지 결정합니다. 소프트웨어 역사의 대부분 동안, 이러한 질문에 답해 주던 도구는 본질적으로 동일한 작동 원리, 즉 ‘이 문자열이 어디에 나타나는가?’를 기반으로 한 다양한 형태의 텍스트 검색이었습니다. 코드베이스가 작고 질문이 단순했을 때는 이 방법이 효과적이었습니다. 오늘날 대부분의 대규모 코드베이스는 이론적으로는 파악 가능하지만, 실제로는 파악할 수 없는 상태입니다. 정보가 존재함에도 불구하고, 이를 찾기 위해 사용되는 도구들은 코드의 표면만 볼 수 있을 뿐, 코드가 실제로 무엇을 의미하는지는 파악하지 못합니다.

제2장에서는 코드베이스를 구조화된 데이터로 쿼리할 수 있게 해주는 표현 방식으로서 ‘무손실 의미론적 트리(Lossless Semantic Tree)’를 소개했습니다. 이 장에서는 그 기능이 실제로 어떻게 작동하는지에 대해 다룹니다.

빠른 검색과 의미론적 검색

모든 질문이 동일한 수준의 정밀도를 요구하는 것은 아닙니다. grep “파일에서 찾기”와 같은 텍스트 검색 도구는 빠르고 널리 사용되며, 오탐이 문제가 되지 않을 때 유용합니다. 이러한 도구는 독특한 구성 키, 특정 문자열 리터럴, 또는 어느 정도의 잡음이 허용될 만큼 고유한 식별자를 찾는 데 사용하세요. 추상 구문 트리(AST) 기반 도구는 한 단계 더 나아가 단순한 문자열이 아닌 코드의 구조적 형태를 일치시키지만, 여전히 유형과 기호가 실제로 무엇을 가리키는지를 파악하는 데는 미치지 못합니다.

문제는 유형, 의존성, 호출 그래프, 해결된 임포트에 대한 심층적인 이해 없이는 질문에 답할 수 없을 때, 텍스트 및 구조적 검색이 한계에 부딪힌다는 점입니다. 결국, getUser() 라는 이름을 가진 두 메서드가 동일한 메서드일 수는 없습니다. Log4j의 Logger SLF4J의 Logger 이름은 같지만 유형은 다릅니다.

의미론적 검색은 컴파일러와 동일한 수준에서 추론하므로, 모든 식별자는 실제로 무엇을 가리키는지로 해석됩니다. IDE는 단일 프로젝트 내에서 이 문제를 해결하지만, LST 기반 의미론적 검색은 리포지토리 경계를 넘어 이러한 기능을 활용할 수 있게 해줍니다.

검색자가 에이전트일 때

탐색은 코딩 에이전트가 끊임없이 수행하는 작업입니다. 에이전트가 코드베이스를 읽을 때마다 탐색을 수행합니다. 즉, 문자열을 검색하고, 파일을 열어 내용을 확인한 다음, 찾은 내용을 바탕으로 다시 검색을 반복합니다. 이러한 루프의 자원 소비 방식은 개발자의 경우와 매우 다릅니다. 에이전트가 grep을 ...