수년 동안 저는 VS Code를 Git 클라이언트로 사용해 왔습니다. 엄밀히 말하면 에디터라기보다 GitLens를 실행하는 호스트에 가까웠죠. 브랜치 그래프(branch graph), 히트맵 형태의 blame, 인라인 렌즈 주석(inline lens annotations)들이 바로 저의 Git 워크플로우였습니다.

그러다 2025년이 찾아왔고, 그 워크플로우는 조용히 무너졌습니다. 그 과정에서 저는 Git 도구들이 내내 잘못된 대상을 위해 만들어져 왔다는 사실을 깨달았습니다.

GitLens가 나를 에디터에 묶어두었다

GitLens는 훌륭한 확장 프로그램입니다. 코드 옆에 표시되는 모든 커밋(commit) 주석, 히트맵으로 보여주는 파일의 히스토리, 한 화면에 나타나는 브랜치 그래프까지. 저는 수년 동안 이를 사용해 왔습니다.

문제는 GitLens가 오직 _에디터 내부_에서만 작동한다는 점입니다. 커밋 히스토리를 보려면 VS Code가 열려 있어야 합니다. 오랫동안 그것은 비용이 아니었습니다. 어차피 저는 하루 종일 에디터 안에 있었으니까요. 코드를 직접 타이핑하는 사람은 바로 저였습니다.

2025년: 내 손이 키보드에서 떠나다

그 후 Cursor, Claude Code, 그리고 Codex가 등장했습니다. 처음에는 그저 범위가 조금 더 넓은 자동 완성(autocomplete)처럼 느껴졌습니다. 그러다 고개를 들어보니 에이전트(agent)가 실제로 편집을 하고 있었습니다. 함수를 작성하고, 파일 전반에 걸쳐 리팩터링(refactoring)을 수행하며, 심지어 커밋(commit)까지 만들고 있었죠. 저는 지시하고, 읽고, 판단합니다.

역할이 뒤바뀌었습니다. 저는 더 이상 코드의 _저자(author)_라기보다는 _검토자(reviewer)_에 가깝습니다. 키보드에 손을 올리고 있는 시간보다 에이전트가 방금 수행한 작업을 살펴보는 데 더 많은 시간을 보냅니다.

그 시점에 VS Code는 오버헤드(overhead)처럼 느껴지기 시작했습니다. 에이전트는 터미널(terminal)에서 실행됩니다. 저에게 에디터를 계속 열어두어야 할 이유는 단 하나, GitLens뿐이었습니다. 단지 커밋 목록을 훑어보기 위해 IDE 전체를 부팅하는 것이 갑자기 터무니없어 보였습니다.

Git 도구는 여전히 저자를 위해 만들어져 있다

여기에 진짜 문제가 있습니다. GitLens, Sourcetree, GitHub Desktop, lazygit, 에디터의 내장 SCM 패널 등 거의 모든 Git 도구는 코드를 직접 손으로 쓰는 사람을 전제로 합니다.

그래서 이 도구들은 커밋(commit), 스테이지(stage), 푸시(push), 머지(merge), 리베이스(rebase), 체리 피크(cherry-pick)를 전면에 내세웁니다. blame 기능에 깊게 파고듭니다. 충돌 해결(conflict-resolution) UI에 공을 들입니다. 이 모든 것은 저자(author)에게 필요한 것들입니다.

하지만 에이전트 시대에 저의 Git 사용 방식은 다릅니다. 대부분의 경우 저는 그저:

• 에이전트가 방금 커밋(commit)한 내용을 확인하고
• 그것이 타당한지(makes sense) 결정하며
• 무언가 이상해 보일 때 디프(diff)를 확장해서 보고
• 잘못되었을 때 에이전트에게 다시 하라고 말하는 것입니다.

이 루프(loop)의 어느 단계에서도 저는 수동으로 커밋(commit), 푸시(push), 또는 머지(merge)를 하지 않습니다. 만약 Git 수술(git surgery)이 필요하다면, 말로 에이전트에게 지시하는 것이 더 빠릅니다. 하지만 기존 도구들은 제가 이제 거의 건드리지 않는 바로 그 수술 기능들에 화면 공간과 무게를 쏟아붓고 있습니다.

도구들이 틀린 것은 아닙니다. 다만 그 도구들이 설계된 대상 사용자가 이전 시대의 사람일 뿐입니다.

리뷰어를 위한 Git 도구의 모습

그렇다면 리뷰어를 위한 Git 도구는 어떤 모습이어야 할까요? 저는 네 가지 요소로 결론을 내렸습니다.

1. 읽기 전용(read-only)이어야 합니다. 검증(verification)이 임무인 도구는 실수로 상태를 변경할 수 없어야 합니다. 커밋(commit)/푸시(push)/머지(merge) 버튼이 없다면, 실수로 누를 버튼도 없습니다. 읽기 전용은 누락된 기능이 아니라, 설계 결정(design decision)입니다.

2. 창(window)이 아니라 상주(resident)해야 합니다. 리뷰는 하루에도 수십 번 발생하는 짧은 작업입니다. 매번 앱을 실행하고 닫는 것은 마찰(friction)을 일으킵니다. 트레이(tray)에 머물다가, 클릭 한 번으로 확장되고, 다시 방해하지 않고 물러나는 것이 더 낫습니다.

3. 0.5초 안에 완료되어야 합니다. "에이전트가 방금 제대로 했나?"라는 질문은 0.5초짜리 질문입니다. 도구가 그보다 오래 걸린다면 사람들은 그냥 확인을 건너뛰어 버립니다. 훑어보기(glance)를 위해서는 속도 자체가 기능입니다.

4. 문제를 수정하는 곳이 되려 해서는 안 됩니다 — 에이전트에게 넘겨줘야 합니다. 무언가 잘못되었을 때, 도구가 그 자리에서 직접 수정하게 할 필요는 없습니다. 커밋(commit)과 디프(diff)를 깔끔한 컨텍스트(context)로 묶어 에이전트에게 바로 전달하십시오. 수정은 에이전트가 더 잘합니다.

그래서 gitwink를 만들었습니다

gitwink는 이 네 가지 요소를 구현하여 만들어졌습니다.

gitwink — a unified commit timeline that expands from the tray

gitwink는 시스템 트레이(system tray)에 상주합니다. 클릭하거나 Ctrl+Shift+G를 누르면, 사용자의 모든 로컬 저장소(repo)에 걸친 최근 커밋(commit)들이 하나의 타임라인으로 펼쳐지는 패널이 확장됩니다. 저장소, 시간 범위 또는 작성자(author)별로 필터링할 수 있으며, 커밋을 클릭하면 메시지 본문과 변경된 파일 목록이 인라인(inline)으로 확장됩니다.

"잠깐, 에이전트가 정말 이걸 한 건가?" 싶은 순간을 위해, 별도의 diff 창이 열려 사이드 바이 사이드(side-by-side) 뷰를 제공하며, 이미지 에셋의 경우 전/후(before/after) 미리보기도 지원합니다.

gitwink diff window — side-by-side diff with inline image preview

그리고 핵심적인 부분은 바로 AI 컨텍스트로 복사(Copy as AI context) 기능입니다. c를 한 번 누르면 커밋, 파일 목록, 그리고 diff가 마크다운(markdown) 블록 형태로 클립보드에 저장됩니다. 이를 Claude나 Codex에 붙여넣고 "이게 맞나요?"라고 물어보세요. 이 도구는 판단의 자리를 대신하는 것이 아니라, 판단할 수 있도록 깨끗한 자료를 전달할 뿐입니다.

gitwink는 git 클라이언트가 아닙니다. 커밋(commit), 푸시(push) 또는 머지(merge)를 할 수 없습니다. 설계 단계부터 읽기 전용(read-only)으로 만들어졌습니다. 텔레메트리(telemetry), 전화 홈(phone-home), 네트워크 호출이 없으며, Tauri 2와 Rust로 구축된 작은 로컬 앱이고 코드는 MIT 라이선스입니다.

Windows 및 macOS 빌드는 최신 릴리스(latest release)에서 확인할 수 있습니다. (아티팩트(artefacts)에 아직 코드 서명이 되어 있지 않아, 처음 실행 시 SmartScreen / Gatekeeper 경고가 나타날 수 있습니다. 릴리스 노트에 우회 단계가 안내되어 있습니다.)

마치며

에이전트가 코드를 작성하기 시작하면서, 개발자의 역할은 _작성(authoring)_에서 _리뷰(reviewing)_로 이동했습니다. 하지만 대부분의 git 도구는 여전히 작성자를 위해 설계되어 있습니다. 리뷰어에게는 읽기 전용이면서, 상주하고, 빠르며, 에이전트에게 전달할 수 있는 무언가가 필요합니다. gitwink는 제가 구현할 수 있는 그 아이디어의 가장 작은 형태입니다.