사내의 레거시 시스템을 Spring Boot 2.7에서 3.0으로 전환하는 대규모 마이그레이션 프로젝트를 진행하면서 겪었던 당혹감이 아직도 생생합니다. 당시 팀에서는 범용적인 대형 언어 모델(LLM)을 활용해 작업을 자동화하려 했지만, 모델은 우리 팀만 사용하는 내부 프레임워크의 고유한 규약을 전혀 이해하지 못했습니다. 수천 개의 자바 파일이 얽힌 복잡한 의존성 관계 속에서 모델은 존재하지 않는 API를 제안하거나, 이미 폐기된 내부 라이브러리를 참조하는 환각 현상을 반복했습니다. 단순한 프롬프트 엔지니어링이나 외부 문서를 검색해 붙여넣는 방식으로는 수백만 라인에 달하는 프라이빗 코드의 맥락을 담아내기에 역부족이라는 사실을 뼈저리게 느낀 순간이었습니다.
개발자들이 흔히 빠지는 'RAG 만능론'의 함정
많은 개발자가 사내 코드베이스에 특화된 AI를 구축할 때, 단순히 검색 증강 생성(RAG) 시스템만 잘 갖추면 된다고 믿곤 합니다. 여기에는 크게 두 가지 오해가 자리 잡고 있습니다. 첫 번째는 "컨텍스트 윈도우가 충분히 크다면 모든 코드를 집어넣을 수 있다"는 생각입니다. 하지만 Llama 3 모델의 경우 컨텍스트 윈도우가 128,000 토큰(출처: Meta AI 공식 문서)에 달함에도 불구하고, 수천 개의 파일이 얽힌 전체 리포지토리의 의존성 그래프를 한 번에 주입하는 것은 물리적으로 불가능하거나 막대한 토큰 비용을 발생시킵니다.
두 번째 오해는 "코드 검색 성능이 좋으면 모델이 알아서 정답을 찾을 것"이라는 믿음입니다. 사실 RAG는 검색된 파편화된 정보 사이의 논리적 연결 고리를 모델이 추론해야 하는 부담을 줍니다. 개발자가 느끼기에 이는 매우 당연한 오해입니다. 지금까지 우리가 접해온 대부분의 상용 서비스가 RAG 기반이었기에, 모델 자체를 우리 코드에 맞춰 '개조'한다는 개념은 비용과 기술적 난이도 측면에서 너무 멀게 느껴졌기 때문입니다.
가중치에 직접 새기는 지식의 메커니즘
실제로 코드베이스의 깊은 맥락을 이해하기 위해서는 모델의 가중치(Weights) 내부에 리포지토리의 정보를 직접 인코딩하는 과정이 필요합니다. 이는 단순히 문서를 읽어주는 비서를 두는 것이 아니라, 우리 팀의 코딩 스타일과 설계 철학을 완전히 학습한 숙련된 동료를 만드는 것과 같습니다. 오픈 웨이트 모델은 폐쇄형 API 모델과 달리 우리가 직접 가중치를 수정할 수 있다는 결정적인 이점을 가집니다.
내부적으로는 리포지토리의 구조적 정보를 효율적으로 학습하기 위한 기법들이 적용됩니다. 모델은 파일 간의 호출 관계, 특정 함수가 가진 부수 효과(Side-effect), 그리고 사내 표준 라이브러리의 사용 패턴을 신경망의 파라미터로 흡수합니다. 이 과정이 제대로 이루어지면, 모델은 별도의 외부 검색 없이도 "우리 프로젝트에서는 데이터베이스 접근 시 반드시 이 인터페이스를 거쳐야 한다"는 규칙을 본능적으로 따르게 됩니다. 이는 추론 시점에 발생하는 계산 부하를 줄이면서도 훨씬 정교한 코드 생성을 가능하게 만드는 핵심 동력입니다.
Soft-Verification: 효율과 정확도 사이의 균형점
하지만 모든 코드를 완벽하게 학습시키고 매번 검증하는 것은 컴퓨팅 자원 측면에서 매우 비효율적입니다. 여기서 '소프트 검증(Soft-Verification)'이라는 개념이 등장합니다. 이는 생성된 코드가 문법적으로 맞는지, 혹은 실제 리포지토리에 존재하는 심볼을 참조하고 있는지 등을 가볍게 확인하는 단계입니다. 엄격한 정적 분석이나 전체 테스트 수트 실행 대신, 확률적으로 오류 가능성이 높은 지점만을 골라내어 모델의 출력을 보정하는 방식입니다.
제가 관찰한 바에 따르면, 이러한 느슨한 검증 방식은 학습 속도를 비약적으로 높이면서도 치명적인 환각 현상을 억제하는 데 탁월한 효과를 보였습니다. 모든 것을 100% 완벽하게 검증하려다 학습이 멈추는 병목 현상을 해결하고, 모델이 코드의 흐름을 유연하게 학습할 수 있도록 돕는 일종의 '안전 가이드라인' 역할을 수행하는 것입니다. 이는 특히 자원이 한정된 환경에서 오픈 웨이트 에이전트를 운영해야 하는 팀에게 매우 현실적인 대안이 됩니다.
프라이빗 코드베이스 최적화의 실질적 장단점
이러한 방식이 무조건적인 정답은 아닙니다. 명확한 기회비용이 존재합니다. 우선, 모델의 가중치를 직접 관리해야 하므로 인프라 유지보수 비용이 발생합니다. 단순히 API 키만 발급받아 사용하는 방식에 비해 초기 설정 난이도가 높습니다. 또한, 코드베이스가 급격하게 변할 경우 가중치에 인코딩된 정보가 구식이 될 위험(Staleness)도 무시할 수 없습니다.
그럼에도 불구하고 보안이 중요한 금융권이나 독자적인 프레임워크를 사용하는 기술 기업에게는 오픈 웨이트 에이전트가 유일한 돌파구입니다. 외부 API로 소스 코드를 유출하지 않으면서도, 사내 인프라 내에서 독점적인 지식을 가진 모델을 소유할 수 있기 때문입니다. 저는 개인적으로 범용 모델의 성능 경쟁보다, 특정 도메인과 특정 리포지토리에 얼마나 깊게 동화될 수 있는지가 향후 개발 생산성의 격차를 만들 것이라고 판단합니다.
단순히 좋은 모델을 고르는 단계는 지났습니다. 이제는 우리 팀의 코드를 가장 잘 이해하는 '전용 에이전트'를 어떻게 효율적으로 구워낼 것인지를 고민해야 할 때입니다. 당장 모든 코드를 학습시키기 어렵다면, 가장 자주 사용되는 핵심 유틸리티 라이브러리부터 모델의 가중치에 녹여내는 시도를 시작해 보시길 제안합니다.
참고: arXiv CS.LG (Machine Learning)