GitHub 없이도 굴러가는 이슈 트래커: Epiq가 보여주는 분산 협업의 미래

이슈 트래커를 Git 안에 넣는다는 발상

개발자라면 누구나 GitHub Issues나 Jira 같은 이슈 트래커를 써봤을 거예요. 그런데 이런 도구들에는 공통점이 하나 있어요. 중앙 서버에 의존한다는 점이에요. 회사가 GitHub을 결제하지 않으면 이슈도 같이 사라지고, 인터넷이 끊기면 이슈를 못 봐요. 이게 당연한 것 같지만, 사실 우리가 쓰는 Git 자체는 분산형이거든요. 코드는 분산되어 있는데, 이슈와 토론은 왜 중앙에 묶여 있어야 할까요?

이번에 공개된 Epiq는 이런 의문에서 출발한 프로젝트예요. 이슈 트래커를 Git 저장소 자체에 통합해, GitHub 같은 서비스 없이도 팀이 이슈를 주고받을 수 있게 만든 TUI(터미널 사용자 인터페이스) 도구예요. 풀어 말하면 "이슈도 코드처럼 git pull/push로 동기화하자"는 발상이죠.

Git 기반 이슈 트래커는 어떻게 동작할까

이게 뭐냐면, 이슈 하나하나를 Git 저장소 안의 파일(혹은 별도 ref나 객체)로 저장하는 거예요. 누군가 이슈를 열면 그게 커밋이 되고, 댓글을 달면 또 커밋이 돼요. 그래서 git push만 하면 이슈가 동기화되고, git pull만 하면 다른 사람이 단 댓글이 내 노트북에 내려와요. 인터넷이 안 되는 비행기 안에서도 이슈를 열고 닫을 수 있고, 나중에 연결되면 알아서 합쳐져요.

Epiq는 여기에 터미널 UI를 입혔어요. vim이나 less에 익숙한 사람이라면 바로 적응할 수 있는 키 기반 조작으로, 이슈 목록을 훑고 상세 내용을 보고 새 이슈를 작성할 수 있어요. 마우스 없이도 충분히 빠르게 작업할 수 있도록 설계되어 있고, 무엇보다 가볍다는 게 특징이에요. 브라우저를 띄울 필요가 없거든요.

기술적으로 보면, 이슈를 어떻게 저장하느냐가 핵심 설계 결정이에요. 작업 브랜치를 더럽히지 않으려면 보통 별도 ref namespace(예: refs/epiq/)에 저장하거나, 별도 orphan 브랜치를 만들어요. 그래야 코드 히스토리와 이슈 히스토리가 섞이지 않거든요. 충돌 해결도 중요한데, 같은 이슈에 두 사람이 동시에 댓글을 달았을 때 자동으로 머지할 수 있도록 데이터 구조를 잘 짜둬야 해요. CRDT(여러 사람이 동시에 편집해도 결국 같은 상태로 수렴하는 자료구조예요) 비슷한 아이디어가 들어가는 경우가 많아요.

비슷한 프로젝트들과 비교해 보면

Git 기반 이슈 트래커라는 아이디어 자체는 새로운 게 아니에요. 오래된 도구로는 Bugs Everywhere, git-bug 같은 프로젝트가 있었거든요. 특히 git-bug는 꽤 활발하게 유지되고 있고, GitHub Issues와 양방향 동기화까지 지원해요. 비슷한 결의 Fossil(SQLite 만든 사람이 만든 분산 버전 관리 시스템인데, 이슈 트래커와 위키가 처음부터 내장돼 있어요)도 있고, 최근에는 Radicle처럼 P2P 네트워크 위에 코드 협업 전체를 올리려는 시도도 있어요.

이런 흐름의 큰 그림은 "GitHub 의존도 줄이기"예요. 마이크로소프트가 GitHub을 인수하면서 한동안 잠잠했지만, 작년 GitLab의 일부 정책 변경, 그리고 GitHub의 일부 정치적 결정들을 계기로 "단일 플랫폼에 모든 협업 데이터를 두는 게 안전할까?"라는 질문이 다시 떠오르고 있어요. 특히 오픈소스 진영, 그리고 정부·공공 영역에서는 데이터 주권 차원에서 자체 호스팅 가능한 도구를 찾는 흐름이 분명히 있어요.

Epiq는 이 흐름 안에서 "풀스택 협업 플랫폼"을 만드는 게 아니라 "이슈 트래커 한 조각만 깔끔하게" 가져가는 미니멀 접근을 택했어요. 터미널에서 살아가는 개발자에게는 이쪽이 더 매력적일 수 있어요.

실무에서 써볼 만한 시나리오

첫째, 사내 폐쇄망 프로젝트예요. 금융권이나 공공기관처럼 외부 인터넷 연결이 제한된 환경에서는 GitHub을 못 써요. 사내 GitLab을 깔기에는 운영 부담이 크고요. 이럴 때 Git 서버 하나만 있으면 이슈 관리까지 가능한 도구는 꽤 매력적이에요.

둘째, 개인 사이드 프로젝트예요. 혼자 하는 프로젝트라도 "나중에 할 일"을 어딘가에 적어두고 싶잖아요. README에 TODO를 적자니 너무 임시적이고, GitHub Issues를 쓰자니 비공개 저장소로 만들어야 하고. Epiq라면 그냥 저장소 안에 자연스럽게 녹여둘 수 있어요.

셋째, 로컬 우선(local-first) 워크플로우예요. 요즘 "클라우드 의존을 줄이고 내 노트북을 신뢰의 중심으로 두자"는 사조가 다시 떠오르고 있어요. Linear, Notion 같은 도구는 빠르고 예쁘지만 결국 회사가 망하면 데이터가 같이 사라지거든요. Git 저장소는 내 디스크에 있고, 백업도 쉬워요.

한국 개발자에게 주는 시사점

당장 회사 프로젝트를 Jira에서 Epiq로 옮기자고 말하긴 어려울 거예요. PM과 디자이너가 쓸 수 있어야 하는데, 터미널 UI는 진입 장벽이 있거든요. 하지만 개인 작업 흐름에서는 한번 시도해 볼 만해요. 특히 dotfiles 관리, 블로그 글감 관리, 학습 기록 같은 "혼자 쓰는 프로젝트"에 적용해 보면 Git의 분산 철학을 새로 체감할 수 있어요.

그리고 도구 자체보다 설계 아이디어가 더 값져요. "애플리케이션 데이터를 Git 저장소에 함께 두는 패턴"은 문서, 설정, 인프라 정의 등 다양한 영역에 응용할 수 있거든요. GitOps라는 키워드도 결국 비슷한 발상에서 출발했어요.

마무리

Epiq는 거대한 플랫폼이 아니라 작고 뾰족한 도구예요. 하지만 그 뒤에는 "협업을 누군가의 서버에 인질로 잡히지 말자"는 꽤 큰 철학이 있어요. 한 번쯤 자기 워크플로우의 어디까지를 클라우드에, 어디까지를 내 디스크에 둘지 점검해 볼 좋은 계기예요.

여러분의 이슈 트래커가 내일 갑자기 사라진다면, 어떤 데이터를 잃게 될까요? 그게 진짜 "내" 데이터가 맞나요?