에이전트가 코드를 작성하는 시대 — Git 도구는 무엇이 되어야 하는가?

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

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

그리고 핵심적인 부분은 바로 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는 제가 구현할 수 있는 그 아이디어의 가장 작은 형태입니다.