변경 사항을 스테이징(stage)하고, git commit을 입력하고, 커서가 깜빡이는 가운데 오늘 벌써 세 번째로 "fix stuff"라고 적고 계신가요? 두 개의 오픈 소스 CLI(Command Line Interface)가 스테이징된 디프(diff)를 읽고 메시지를 초안으로 작성함으로써 여러분의 고민을 덜어주고자 합니다. 바로 aicommits와 opencommit입니다. 두 도구 모두 글로벌 npm 패키지로 설치되며, 거대 언어 모델(LLM)을 활용하고, git에 후크(hook)를 연결하여 일반적인 git commit 명령 시 실행되도록 할 수 있습니다. 차이점은 세 가지 부분에서 나타납니다: 디프가 전송되는 위치, 도구의 설정 가능 범위, 그리고 생성된 메시지가 틀렸을 때의 처리 방식입니다.

저희는 두 도구를 모두 설치한 후, TypeScript 저장소와 Go 서비스 전반에 걸친 실제 스테이징된 디프를 대상으로 테스트하며 일상 업무에서 실제로 중요한 부분들이 어떻게 작동하는지 비교했습니다.

각 도구의 작동 방식

aicommits (Hassan El Mghari 제작, Nutlope 계정으로 게시됨)는 인터페이스를 의도적으로 작게 유지합니다. npm install -g aicommits로 설치하고, aicommits config set OPENAI_KEY=sk-...로 키를 설정한 뒤, 변경 사항을 스테이징하고 aicommits를 실행하면 됩니다 (aic라는 별칭(alias)을 사용하면 더 짧습니다). 이 도구는 스테이징된 디프를 읽어 OpenAI에 전송하고, 사용자가 수락하거나 거부할 수 있는 단일 메시지를 출력합니다. aicommits --generate 3을 입력하면 하나의 메시지 대신 선택할 수 있는 세 개의 후보를 반환합니다. aicommits config set type=conventional을 사용하면 출력 형식을 Conventional Commits 형식(feat:, fix: 등)으로 전환할 수 있습니다. 자동화를 위해 aicommits hook install을 실행하면 prepare-commit-msg git 후크가 추가되며, 이후 일반적인 git commit을 실행하면 해당 명령이 가로채져 생성된 메시지가 에디터에 미리 채워집니다.

opencommit (oco 명령어, Dima Sukharev 제작) 또한 동일한 핵심 루프 — 스테이징(stage), oco 실행, 제안 수락 — 를 수행하지만, 훨씬 더 많은 설정 옵션(knobs)을 제공합니다. 가장 큰 차이점은 프로바이더(provider) 지원입니다. 별도의 설정 없이도 OpenAI, Anthropic, Azure, Google Gemini와 통신할 수 있으며, 결정적으로 oco config set OCO_AI_PROVIDER=ollama를 통해 로컬 모델을 위한 Ollama를 지원합니다. OCO_EMOJI=true를 통해 메시지에 GitMoji 이모지를 접두사로 붙일 수 있고, OCO_LANGUAGE로 메시지 본문을 영어가 아닌 언어로 작성할 수 있으며, — 대부분의 팀이 가장 중요하게 생각하는 기능인 — 기존의 commitlint 설정을 읽어와 생성된 메시지가 이미 CI에서 강제하고 있는 규칙을 준수하도록 할 수 있습니다. 훅(hook)은 oco hook set으로 설치합니다.

실질적인 결과: aicommits는 최소한의 설정으로 한 가지 일에 집중하는 도구입니다. 반면 opencommit은 기존 팀의 워크플로(workflow)에 맞춰 유연하게 변형 가능한 설정 가능한 플랫폼입니다.

진짜 차이점: 누가 모델을 제어하는가

대부분의 일대일 비교는 "둘 다 커밋 메시지를 작성한다"는 수준에서 멈추지만, 실제 결정은 프로바이더의 유연성에 달려 있습니다.

aicommits는 OpenAI 우선 방식입니다. 덕분에 설정이 간결하며(하나의 키, 하나의 프로바이더, 합리적인 기본값), 저희의 테스트 실행 결과 생성된 메시지는 일관되게 깔끔하고 관례적(conventional)이었습니다. 대가는 종속성(lock-in)입니다. 만약 고용주가 소스 코드를 OpenAI로 보내는 것을 금지하거나, 로컬 모델을 실행하고 싶다면 aicommits는 제대로 된 해답을 제시하지 못합니다.

opencommit은 모델을 교체 가능한 백엔드(backend)로 취급합니다. OCO_AI_PROVIDER를 ollama로 지정하면 스테이징된 디프(diff)가 노트북을 절대 떠나지 않습니다. 대신 자신의 기기에서 실행되는 llama3나 qwen2.5-coder와 같은 로컬 모델로 전달됩니다. 규제가 엄격한 코드베이스에서 작업하거나, 토큰당 발생하는 API 비용에 거부감이 있는 사람에게는 이 단 하나의 기능이 결정적인 요소가 됩니다. 트레이드오프(tradeoff)는 품질입니다. 작은 로컬 모델은 최첨단(frontier) API 모델보다 덜 정교하고 덜 정확한 메시지를 작성하며, 크거나 미묘한 디프(diff)를 다룰 때 그 차이를 느끼게 될 것입니다.

기본적으로 두 도구 모두 스테이징된 전체 디프 (diff)를 제3자 API로 전송합니다. 만약 스테이징된 변경 사항에 비밀값(secret), .env 값, 또는 고객 기록이 포함되어 있다면, 이는 네트워크를 통해 전송됩니다. pre-commit 비밀값 스캐너를 추가하고, 생성된 키가 스테이징된 파일에 포함되지 않도록 하며, 민감한 저장소의 경우 로컬 Ollama 모델과 함께 opencommit을 사용하여 디프 (diff)가 사용자의 기기에 머물도록 하세요.

품질, 속도, 그리고 편집 비용 (editing tax)

두 도구 모두 사용자를 과정에서 완전히 배제하지 않으며, 이는 올바른 설계입니다. 두 도구 모두 커밋이 완료되기 전에 편집할 수 있는 메시지를 미리 채워줍니다. 출력물을 최종 답변이 아닌 강력한 초안으로 생각하십시오. 작고 단일 목적의 디프 (diff) (함수 이름 변경, 파일 하나에서의 버그 수정 등)의 경우, 두 도구 모두 우리가 그대로 받아들일 만한 메시지를 생성했습니다. 대규모의 다중 파일 디프 (diff)의 경우, 모델이 많은 관련 없는 변경 사항을 한 줄로 압축하기 때문에 두 도구 모두

개인 프로젝트를 진행하는 대부분의 개별 개발자에게는 aicommits가 더 빠른 선택입니다. 팀 단위의 작업이나 개인정보 보호가 중요한 작업의 경우에는 opencommit의 유연성이 약간 더 무거운 설정 과정을 보상해 줍니다.

만약 이미 에디터(editor) 내에서 AI를 활용하고 있다면, AI 커밋 메시지는 동일한 워크플로 (workflow)의 작은 확장일 뿐입니다. 즉, 디프 (diff)를 작성한 어시스턴트가 이를 설명할 수도 있는 것입니다.