코드 인텔리전스의 미래 — Sourcegraph SCIP가 그리는 다음 그림

코드 내비게이션, 어떻게 작동하는 건지 생각해본 적 있나요?

VS Code에서 함수 이름을 클릭하면 정의된 곳으로 바로 이동하잖아요. 또는 변수 위에 마우스를 올리면 타입 정보가 뜨기도 하고요. 이런 기능들을 통틀어서 코드 인텔리전스라고 부르는데요, 이게 당연한 것 같지만 사실 뒤에서 꽤 복잡한 일이 벌어지고 있어요.

로컬 IDE에서는 LSP(Language Server Protocol)라는 프로토콜이 이 역할을 해요. 이게 뭐냐면, 에디터와 언어 분석 엔진 사이에 공통 언어를 만들어서, 어떤 에디터를 쓰든 같은 수준의 코드 인텔리전스를 제공하는 표준이에요. Microsoft가 VS Code를 만들면서 제안한 건데, 지금은 거의 모든 에디터가 지원하는 업계 표준이 됐죠.

그런데 문제가 하나 있어요. LSP는 실시간 분석에 초점이 맞춰져 있거든요. 내가 지금 열고 있는 파일을 기준으로 분석을 돌리는 거예요. 이건 로컬 개발 환경에서는 완벽하게 작동하는데, 만약 GitHub 같은 웹 환경에서 수백만 개의 저장소를 인덱싱해서 코드 검색과 내비게이션을 제공하려면? LSP만으로는 어려워요. 저장소마다 언어 서버를 띄울 수도 없고, 실시간으로 전체 코드베이스를 분석하는 건 비용이 어마어마하니까요.

SCIP가 등장한 이유

SCIP(Source Code Intelligence Protocol, "십"이라고 읽어요)는 바로 이 문제를 풀기 위해 Sourcegraph에서 만든 프로토콜이에요. 코드 인텔리전스 데이터를 미리 인덱싱해서 저장하는 포맷이라고 생각하면 돼요.

비유를 들자면 이런 거예요. LSP가 도서관에서 사서에게 "이 책 어디 있어요?"하고 물어볼 때마다 직접 찾아주는 방식이라면, SCIP는 미리 전체 도서관의 목록을 만들어두고 빠르게 검색할 수 있게 해주는 카탈로그 시스템이에요. 사전에 인덱스를 만들어두니까, 실시간으로 분석할 필요 없이 바로 결과를 제공할 수 있는 거죠.

SCIP는 Protocol Buffers 기반의 직렬화 포맷을 사용하고, 각 프로그래밍 언어별로 인덱서(indexer)가 코드를 분석해서 SCIP 형식으로 출력해요. 이 인덱스에는 심볼 정의 위치, 참조 관계, 타입 정보 등이 들어가 있어서, 나중에 "이 함수를 호출하는 곳이 어디야?" 같은 질문에 빠르게 답할 수 있어요.

그래서 미래에는 뭐가 달라지나요?

Sourcegraph가 발표한 SCIP의 미래 방향은 몇 가지 중요한 변화를 담고 있어요.

첫 번째는 인덱서의 품질 개선이에요. SCIP는 프로토콜이기 때문에, 실제로 코드를 분석하는 건 각 언어별 인덱서의 몫이거든요. TypeScript, Go, Java, Python 등 주요 언어의 인덱서가 있는데, 언어마다 완성도가 달라요. 앞으로는 특히 타입 추론이 복잡한 언어들(Python, Ruby 등)의 인덱서 정확도를 높이는 데 집중한다고 해요.

두 번째는 크로스 레포지토리 내비게이션이에요. 이게 뭐냐면, A라는 저장소에서 B 저장소의 라이브러리 함수를 호출했을 때, 그 함수의 정의로 바로 이동할 수 있게 만드는 거예요. 대규모 조직에서 마이크로서비스나 모노레포를 운영할 때 엄청나게 유용한 기능이죠. 지금도 부분적으로 가능하지만, SCIP 포맷을 개선해서 이 경험을 훨씬 매끄럽게 만들겠다는 거예요.

세 번째는 AI와의 통합이에요. 요즘 AI 코딩 어시스턴트가 대세잖아요. Copilot, Cursor, Claude Code 같은 도구들이요. 이런 AI 도구들이 코드를 이해하려면 단순히 텍스트를 읽는 것만으로는 부족하고, 심볼 간의 관계, 타입 정보 같은 구조화된 데이터가 필요해요. SCIP가 바로 이 역할을 할 수 있다는 거예요. AI에게 코드의 의미적 구조를 전달하는 중간 레이어가 되는 셈이죠.

비슷한 기술들과 비교하면?

SCIP와 비슷한 역할을 하는 기술로는 GitHub의 스택 그래프(Stack Graphs)가 있어요. GitHub에서 코드 내비게이션 기능("Go to Definition" 등)을 제공할 때 사용하는 기술인데요, 접근 방식이 좀 달라요. SCIP가 빌드 환경에서 정확한 인덱스를 생성하는 방식이라면, 스택 그래프는 빌드 없이도 부분적인 분석이 가능하도록 설계됐어요. 정확도는 SCIP가 높지만, 스택 그래프는 설정 없이 바로 쓸 수 있다는 장점이 있죠.

또 하나 주목할 건 LSP 자체도 계속 진화하고 있다는 거예요. LSP 3.17에서 추가된 타입 계층 지원이나, 인라인 힌트 같은 기능들이 대표적이죠. SCIP와 LSP는 경쟁이 아니라 보완 관계에 있는데, 로컬에서는 LSP, 대규모 인덱싱과 웹 환경에서는 SCIP라는 역할 분담이 자연스럽게 이루어지고 있어요.

한국 개발자가 챙겨볼 포인트

당장 실무에서 SCIP를 직접 다룰 일은 많지 않을 수 있어요. 하지만 몇 가지 시사점이 있어요.

먼저, 대규모 코드베이스를 운영하는 팀이라면 Sourcegraph 같은 코드 검색 도구의 도입을 검토해볼 만해요. 수백 개의 저장소에서 특정 API의 사용처를 찾아야 할 때, grep으로는 한계가 있거든요. SCIP 기반의 시맨틱 검색은 이런 상황에서 진가를 발휘해요.

또한 AI 코딩 도구를 사용하는 분이라면, 이런 코드 인텔리전스 인프라가 AI의 코드 이해 능력에 직접적인 영향을 준다는 점을 알아두면 좋아요. 앞으로 AI 도구를 선택할 때 "이 도구가 코드를 얼마나 깊이 이해하는가"가 중요한 기준이 될 텐데, 그 깊이를 결정하는 게 바로 SCIP 같은 프로토콜이거든요.

정리하자면

SCIP는 코드 인텔리전스를 대규모로 제공하기 위한 인덱싱 프로토콜이고, AI 시대에 코드의 의미적 구조를 전달하는 핵심 인프라로 진화하고 있어요. LSP가 개발자의 로컬 경험을 바꿨다면, SCIP는 웹과 AI 환경에서의 코드 이해 방식을 바꾸려 하고 있는 셈이죠. 여러분은 AI 코딩 도구가 코드를 더 잘 이해하려면 어떤 정보가 가장 중요하다고 생각하시나요?