버전관리 시스템에 AI를 심다

2007년부터 쓰여온 분산 버전관리 시스템 포시일(Fossil)을 인공지능 에이전트 작업 기반으로 개조한 포크가 공개됐다. 개발자 벤시브(BenSiv)가 공식 저장소의 깃(Git) 미러를 갈라 만든 것으로, 코드 이력을 관리하던 도구에 에이전트 대화, 임베딩 검색, 지식 출처 추적을 통째로 얹었다.

무슨 일인가

포시일은 원래 SQLite 프로젝트를 뒷받침하려고 만들어졌고, 이후 다른 프로젝트로도 퍼진 버전관리 시스템이다. 티켓·위키·문서·웹 인터페이스가 하나의 저장소 안에 함께 들어 있는 것이 특징이고, 공식 사이트에서 스스로를 호스팅한다. 깃허브(GitHub)에 올라와 있는 것은 미러 기능이 제대로 도는지 확인하려는 사본에 가깝다.

이번 포크는 바로 그 구조를 노렸다. 이력과 문서와 논의가 한 저장소에 모여 있다면, 에이전트가 참조할 지식과 그 지식의 출처도 같은 곳에 둘 수 있다는 발상이다. 저장소의 문서 폴더에는 구현 로드맵, 사용자 가이드, 도입 가이드, 데이터 풀 정책, 지식 계층 정의, 저장 모델, 출처 추적 설계, 스키마, 지식 브라우저 구현 계획, 검증 계획이 각각 별도 문서로 정리돼 있다. 기능 몇 개를 붙인 실험이 아니라 '열린 지식 공유재(Open Knowledge Commons)'라는 이름을 단 설계 프로젝트에 가깝다.

핵심 짚어보기

가장 눈에 띄는 것은 설정 방식이다. 별도의 JSON 설정 파일 체계를 새로 만들지 않고, 포시일이 원래 갖고 있던 설정 시스템을 그대로 썼다. 대화 백엔드와 임베딩 백엔드를 각각 다른 설정 항목으로 지정하고, 확인 명령 한 번으로 연결 상태를 점검하는 식이다. 기본 호환 값으로 클로드(claude), 코덱스(codex), 제미나이(gemini), 올라마(ollama), 그리고 사용자 정의가 준비돼 있다.

대화용 모델과 임베딩용 모델을 분리해둔 점이 실무적으로 중요하다. 판단이 필요한 대화는 외부 상용 모델에 맡기고 문서 색인은 로컬 모델로 돌리는 조합이 설정 두 줄로 가능해지기 때문이다.

팀 공유 방식도 포시일답다. 로컬 저장소 설정이 전역 설정을 덮어쓰고, 버전관리 대상으로 표시된 설정은 전용 폴더 안의 파일로 커밋할 수 있다. 모델과 제공자 선택이 코드와 같은 이력에 함께 올라가므로, 누가 언제 어떤 모델로 만든 결과물인가가 저장소 안에서 추적된다. 검색 쪽은 임베딩 생성, 의미 색인, 조회 명령이 각각 나뉘어 있고, 웹 인터페이스에는 에이전트 채팅 화면이 붙었다. 예전 방식의 JSON 설정에서 넘어오는 이주 문서도 따로 마련돼 있다.

1인기업 실전 적용 포인트

• 지금 쓰는 지식이 어디에 흩어져 있는지부터 확인하자. 메모 앱과 코드 저장소가 분리돼 있으면 AI가 참조할 맥락도 그만큼 갈라진다.
• 대화 모델과 임베딩 모델을 분리하는 설계는 포시일을 쓰지 않아도 따라 할 수 있다. 검색과 색인은 로컬 임베딩 모델로 내려 고정비를 없애고, 판단이 필요한 호출만 유료 모델에 남긴다.
• 산출물에 '어느 모델이 언제 관여했는가'를 남기는 습관을 들이자. 결과가 틀렸을 때 원인을 좁히는 사실상 유일한 단서다.
• 도구를 갈아타기 전에 저장 형식을 먼저 본다. 저장소가 파일 하나로 떨어지면 백업이 복사 한 번으로 끝난다. 혼자 운영할 때 이 차이는 생각보다 크다.

전망 / 주의점

이 포크는 로드맵 문서가 계속 갱신되는 진행형 프로젝트이고, 별 두 개짜리 개인 작업물이다. 실제 업무 저장소를 지금 옮길 단계는 아니다. 주목할 것은 코드보다 방향이다. 에이전트가 만든 결과물을 어디에 저장하고 그 출처를 어떻게 증명할 것인가라는 질문에 버전관리 시스템으로 답한 사례이기 때문이다. 원본 개발팀의 방침과는 무관한 개인 실험이라는 점, 임베딩과 색인을 켜면 저장소 용량과 갱신 비용이 함께 늘어난다는 점은 미리 감안해야 한다.

출처: 해커뉴스 (https://github.com/BenSiv/fossil-scm)