LLM 하네스 동기화 시스템
흩어진 Skill들
2026년 들어 더모먼트팀 레포지터리에 새로운 얼굴들이 생겼습니다. SKILL.md, 그리고 /.claude, /.agents 같은 디렉터리들입니다. 이른바 바이브코딩이 대세가 되면서 생겨난 에이전트 설정 파일들인데, 특정 프로젝트에 국한된 이야기가 아니었기 때문에 활발하게 개발되던 대부분의 프로젝트에 금세 자리를 잡았습니다.
일관된 커밋 컨벤션을 지키게 하는 git-commit Skill, 디버깅 과정을 규정하는 semantic-debugging Skill, LLM 프롬프트와 코드베이스·문서 사이에 충돌이 없는지 확인하는 contradiction-finder Sub-Agent까지, 다양한 설정 파일을 만들고 적용하고 개선해 나갔습니다. 능률은 확실히 올랐습니다. 하지만 더모먼트팀이 늘 하던 고민이자 거의 집착에 가까운 지점인 '관리 포인트 증가' 문제가 고스란히 드러났습니다.
관리 포인트
문제는 간단합니다. 사실상 같은 지침을 담은 Skill, Hook, Sub-Agent와 각종 프롬프트가 프로젝트마다 흩어져 있었습니다. 하나를 바꾸면 다른 프로젝트에서도 하나씩 바꿔야 했습니다. 커밋 컨벤션이라도 바뀌는 날에는 모든 레포지터리에 같은 수정 PR을 하나씩 올려야 할 판이었습니다.
물론 특정 프로젝트에 특화된 프롬프트도 있었습니다. 하지만 그보다는 PR·커밋 컨벤션처럼 다른 프로젝트에도 그대로 적용할 수 있는 규칙이 훨씬 많았습니다. 이를 해결하기 위해 크게 세 가지 방법을 고민했습니다.
1. 플러그인
Claude Code나 Codex처럼 사용자가 많고 생태계가 활발한 하네스 프로그램들은 '플러그인'이라는 이름으로 하네스 설정을 통째로 배포하는 기능을 제공합니다. 한때 유명했던 frontend-design 같은 Skill도 이 기능 덕분에 빠르게 퍼졌고, 저 역시 여러 플러그인을 받아 쓰고 있었습니다. 플러그인 배포와 마켓플레이스 등록은 꽤 쉬워서 접근성이 좋고, 무엇보다 사용자 입장에서 최신 하네스 설정을 받아 업데이트하고, 설정하고, 제거하는 과정이 간편합니다.
하지만 문제가 있었습니다. 더모먼트팀의 하네스 설정은 Claude Code와 Codex만을 대상으로 하지 않습니다. GitHub Copilot, 그리고 당시에는 Gemini CLI 설정까지 포함되어 있었는데, 플러그인을 쓰면 이 파일들은 따로 배포하고 관리해야 합니다. 관리 포인트를 줄이자는 원래 목적이 무색해지기 때문에 이 안은 기각했습니다.
2. 원격 레포지터리에서 ZIP 파일..?
GitHub 원격 레포지터리를 내려받는 방법 중에는 ZIP 파일로 받는 방법도 있습니다. 그렇다면 공용 하네스 파일 레포지터리를 만들고, 각 프로젝트가 ZIP 파일로 알아서 받아 가게 하면 어떨까 하는 아이디어가 나왔습니다. 굉장히 수동적인 방식이지만 적어도 하네스를 관리하는 지점이 한곳이 된다는 건 확실했습니다. 내키지는 않았지만 일단 검토해 봤습니다.
그러나 이 방식에는 치명적인 문제가 여럿 있었습니다. 우선 수동 관리라는 큰 틀을 벗어나지 못했습니다. ZIP 파일을 올바른 위치에 푸는 것도 사람이 해야 하고, 특정 프로젝트에서 하네스를 따로 수정해 설정이 어긋나는 것도 막기 어렵습니다. 이를 막기 위한 팀 규칙을 세우는 것까지 전부 비용이었습니다.
3. 원격 레포지터리는 유지하자!
그런데 검토하던 중 한 가지 아이디어가 떠올랐습니다. 공용 레포지터리는 그대로 두고, 배포만 자동화하면 되지 않을까? GitHub App을 쓰면 됐습니다. GitHub App은 이름만 App일 뿐, 정확히는 설치한 레포지터리나 조직에 대해 신원과 권한을 부여받는 패키지에 가깝습니다. 하네스 동기화를 원하는 사용자가 GitHub App을 설치해 두면 GitHub Actions 워크플로우가 이를 인식하고, 변경분을 Pull Request로 올려 주면 완벽하겠다는 생각이 들었습니다.
GitHub의 Dependabot 같은 도구도 같은 방식으로 동작하기 때문에 어느 정도 확신이 있었습니다. 그렇게 GitHub App을 만들어 Marketplace에까지 등록하고 출시했습니다.
웹 대시보드
초기에는 GitHub Actions의 schedule 트리거로 정기 동기화를 돌리고, 하네스 설정 파일이 바뀔 때마다 push 트리거로 Pull Request를 발행했습니다.
다만 확실한 단점이 하나 있었습니다. 팀 내부 인원은 즉시 동기화가 필요하면 workflow_dispatch 트리거로 워크플로우를 직접 실행하면 그만입니다. 하지만 팀 외부의 제3자는 그럴 수 없으니 매일 오전에 도는 정기 동기화를 기다리는 수밖에 없었습니다.
물론 제3자를 대상 사용자로 기획한 건 아니었습니다. 그래도 외부에서 이 하네스를 쓰지 못하게 막을 이유는 없었고, 오히려 외부에서 써 주는 것 자체가 팀에 더 도움이 된다고 판단했습니다. 그래서 동기화 기능과 설정 가이드를 웹 사이트로 만드는 작업을 시작했습니다.
기존에 GitHub Wiki로 관리하던 설정 문서도 웹 사이트로 옮겼습니다. 팀에 익숙하지 않던 Wiki라는 관리 포인트까지 한곳으로 합친 셈입니다.
문제점
2026년 10월 말, 정기 자동 동기화가 계속 실패하는 문제가 터졌습니다. 웹 대시보드에서 특정 레포지터리를 동기화하거나 하네스가 바뀌었을 때 도는 동기화에는 문제가 없어서 처음에는 급하게 들여다보지 않았습니다. 하지만 정기적으로 도는 전체 배포가 매번 실패하고 있었기 때문에 확인이 필요했습니다.
Evaluate and set job outputs
Error: Fail to evaluate job outputs
Error: The template is not valid. System.InvalidOperationException: Maximum object size exceeded
원인은 직관적이었습니다. 이 시스템을 쓰는 레포지터리가 525개를 넘어가면서, job output으로 넘기던 JSON 객체가 GitHub Actions의 job output 크기 제한을 넘어선 것입니다. 레포지터리 정보와 체크섬 등을 하나의 JSON 객체로 묶어 job 사이에 넘기던 기존 구조로는 더 이상 감당할 수 없다는 뜻이기도 했습니다.
기존 GitHub Actions 구조를 유지하면서 배치 처리를 하거나 GitHub Artifact 같은 다른 방식을 쓰는 것도 방법이었겠지만... 그보다는 아예 동기화 시스템을 DataGSM으로 옮기기로 했습니다. 그래서 정기 동기화 장애는 아직 해결하지 않은 상태입니다. 웹 대시보드에서 하는 동기화와 하네스 변경 시 도는 동기화는 정상적으로 동작하고 있습니다.
DataGSM?
사실 2026년 7월쯤 팀 내부에서 나온 아이디어가 하나 있었습니다. LLM 하네스 설정 동기화를 DataGSM에 인하우스화하는 것입니다. 무거운 배치 작업을 성능 좋은 DataGSM 서버 애플리케이션에 맡기고, 기존 학생·계정·프로젝트 정보에 묶어 관리하면 사용자 입장에서도 UX가 나아지지 않겠냐는 이야기였습니다. 인하우스화하면 서버에 고정 트래픽이 생기니 팀원들이 포트폴리오를 쓸 때도 도움이 되고, 'Data'GSM이라는 프로젝트의 근본 취지에서도 크게 벗어나지 않았습니다.
다만 처음 이 아이디어가 나왔을 때는 급한 사안이라기보다 기능 추가에 가까웠고 기술적인 난관도 있어서, 2026년 11월 현재까지 본격적으로 추진하지는 못했습니다. 우선 파일 I/O 작업을 어떻게 처리할지의 문제가 있고, 거대한 배치 작업이 돌아가는 중에 OAuth 같은 다른 요청이 몰리면 대응하기 어렵다는 문제도 있습니다.
그래도 LLM 하네스 동기화 시스템이 간단한 팀 내부 도구에 그치지 않고 더모먼트팀의 중요한 아이템으로 자리 잡았다는 것만으로도 이런 고민을 할 가치는 충분하다고 생각합니다. 하나씩 풀어 나가는 중입니다.