LSP는 잊어라? 코드를 'Git 위의 엔티티'로 다루는 새 접근법 'Sem'

무슨 이야기냐면요

요즘 AI 코딩 도구가 정말 많아졌잖아요. 그런데 이 도구들을 써보면 한 가지 답답한 지점이 있어요. AI한테 "이 함수 어디서 쓰여?"라고 물어보면, 결국 코드 전체를 텍스트로 쭉 읽어보고 어림짐작으로 대답하는 경우가 많거든요. 사람이 코드를 '의미 단위'로 이해하는 것과는 좀 다르죠.

Sem이라는 프로젝트는 바로 이 지점을 건드립니다. 한 줄로 요약하면 "코드를 파일 덩어리가 아니라, 의미를 가진 개체(엔티티)들의 모음으로 다루자"는 제안이에요. 그리고 그 개체들을 따로 데이터베이스에 보관하는 게 아니라 Git 위에 얹는다는 게 핵심입니다.

LSP랑 뭐가 다른 거죠?

혹시 LSP라고 들어보셨어요? Language Server Protocol의 줄임말인데요, 이게 뭐냐면 VS Code 같은 에디터에서 자동완성 띄워주고, '정의로 이동' 눌렀을 때 해당 함수로 점프시켜주고, 빨간 밑줄로 에러 알려주는 그 기능들을 표준화한 약속이에요. 마이크로소프트가 만들어서 지금은 거의 모든 에디터가 이걸 씁니다.

그런데 LSP에는 특징이 하나 있어요. 항상 '지금 이 순간'의 코드만 본다는 거죠. 내가 파일을 열어놓은 그 시점의 상태만 분석합니다. 어제 이 함수가 어떻게 생겼었는지, 누가 언제 이름을 바꿨는지 같은 '시간의 흐름'은 LSP가 신경 쓰는 영역이 아니에요. 그리고 에디터가 켜져 있어야, 언어 서버 프로세스가 돌고 있어야 작동하죠.

Sem은 발상을 뒤집습니다. 코드 속의 함수, 클래스, 모듈 같은 걸 각각 하나의 엔티티로 정의하고, 이걸 Git 커밋 히스토리 위에 차곡차곡 쌓아요. 그러면 "이 함수가 3개월 동안 어떻게 진화했는지", "이 클래스를 건드린 커밋들이 뭔지"를 코드의 의미 단위로 추적할 수 있게 됩니다. 텍스트 diff(어느 줄이 바뀌었나)가 아니라 개체 단위의 변화로 보는 거예요. 이게 왜 좋냐면, AI 에이전트가 코드베이스를 탐색할 때 "파일 500개를 읽어"가 아니라 "이 엔티티와 연결된 것만 가져와" 식으로 훨씬 정밀하게 맥락을 잡을 수 있거든요.

업계 흐름에서 보면

사실 비슷한 고민을 하는 프로젝트들이 슬슬 나오고 있어요. 코드를 그래프로 보는 GitHub의 코드 내비게이션, 의존 관계를 추적하는 Sourcegraph, 코드를 임베딩(벡터)으로 바꿔서 검색하는 수많은 RAG 도구들이 다 "코드를 더 똑똑하게 이해하자"는 같은 방향을 보고 있죠. Sem이 색다른 건, 별도의 인덱싱 서버나 외부 DB에 의존하지 않고 Git이라는, 이미 모든 개발자가 쓰는 기반 위에 직접 의미 계층을 올린다는 점이에요. 새로운 인프라를 깔 필요가 적다는 건 실무 도입에서 꽤 큰 매력입니다.

한국 개발자에게는

당장 회사 코드베이스에 적용하라는 얘기는 아니에요. 아직 초기 단계의 실험적 프로젝트니까요. 다만 "AI 시대에 코드를 어떻게 표현할 것인가"라는 질문은 앞으로 우리 일에 직접 영향을 줍니다. 사내 코드 검색, AI 코드 리뷰 봇, 온보딩 자동화 같은 걸 만들려는 분이라면, 코드를 텍스트가 아니라 '엔티티 + 히스토리'로 다루는 이런 관점을 미리 익혀두면 분명 도움이 될 거예요.