코드 못 고치는 편집기, AI 리뷰 도구로 HN 1위
Claude Code나 Codex 같은 코딩 에이전트를 팀에서 쓰고 있다면, 요즘 진짜 병목이 어디로 옮겨갔는지 한 번쯤 느꼈을 것이다. 에이전트한테 기능 하나를 맡기면 몇 분 만에 수백 줄짜리 변경이 돌아온다. 그런데 그걸 “이대로 merge해도 되나”라고 판단하는 속도는 예전 그대로다. 파일을 몇 개나 건드렸는지, 테스트는 손댔는지, 에이전트가 중간에 스스로 판단해서 바꿔버린 부분은 없는지 — 결국 사람이 한 줄씩 읽어야 끝난다.
예를 들어 로그인 기능 하나를 에이전트에게 맡겼다고 해 보자. 몇 분 뒤 파일 12개가 바뀐 diff가 돌아온다. 그중 실제로 눈여겨봐야 할 로직 변경은 두세 군데뿐이고, 나머지는 import 정리나 타입 힌트 추가 같은 부수적인 변경이다. 문제는 일반적인 텍스트 diff 화면에서는 이 둘이 똑같은 무게로 보인다는 것이다. 리뷰어는 결국 12개 파일을 전부 열어 어디가 중요한 변경인지부터 스스로 가려내야 한다.
이 틈을 정면으로 겨냥한 오픈소스 도구가 오늘 해커뉴스 1위(395점)에 올랐다. 이름은 Whiteboard. 2026년 YC 겨울 배치(W26) 스타트업 dev.fast가 만들었고, 공개 나흘 만에 깃허브 스타 1,245개를 모았다. 팀 단위로 Claude Code 훅과 CLAUDE.md를 굴리는 법을 다뤘을 때처럼, 이번에도 공식 저장소의 README와 릴리스 정보를 직접 읽고 옮긴다.
편집은 안 되는 편집기
Whiteboard의 가장 이상한 특징부터 말하면, 이 도구는 Visual Studio Code를 통째로 포크해서 만들었는데 정작 그 화면에서 파일을 고칠 수 없다. 공식 문서의 “알려진 한계” 항목 첫 줄에 그렇게 적혀 있다. “지금은 Whiteboard 안에서 파일을 편집할 수 없습니다. 이게 필요하면 이슈를 남겨 주세요”라고.
보통 우리가 아는 코드 편집기는 “쓰는” 도구다. VS Code든 커서(Cursor)든, 코드를 타이핑하고 저장하는 게 기본 기능이다. Whiteboard는 그 반대로 갔다. 코드를 쓰는 일은 이제 에이전트가 맡고, 사람이 하는 일은 “이 변경을 받아들일지 말지 판단하는 것” 하나로 좁아졌다는 전제 위에서, 아예 편집 기능을 빼고 리뷰 기능만 남긴 것이다. 정말 코드를 고치고 싶으면 원래 쓰던 에디터나 터미널로 돌아가야 한다. 버그가 아니라 이 도구가 뭘 위해 존재하는지 보여주는 설계 결정이다.
왜 지금 이런 도구가 필요해졌나
Whiteboard 저장소의 “이게 왜 존재하나” 섹션은 스스로 이렇게 진단한다. “순수 HTML 기반 도구들은 스펙이나 다이어그램을 코드에 쉽게 연결해 주지 못했다. 그리고 트레이드오프는 보통 구현을 한 번 해 본 뒤에야 발견된다.” 다이어그램은 다이어그램대로 따로 그려지고 코드는 코드대로 따로 있어서, 리뷰어가 머릿속에서 계속 둘을 매핑해야 했다는 뜻이다.
여기에 에이전트가 코드를 쓰는 속도까지 빨라지면서 문제가 더 커졌다. 사람이 한 줄씩 타이핑하며 코드를 짜던 시절엔 “쓰는 사람”과 “검토하는 사람”의 속도 차이가 크지 않았다. 지금은 에이전트 하나가 몇 분 만에 큰 변경을 만들어내는데, 그걸 읽고 판단하는 속도는 여전히 사람 눈 속도 그대로다. 리뷰가 코드 작성 전체 과정에서 차지하는 시간 비중이 갈수록 커지는 셈이다.
Whiteboard 팀은 이 격차를 설명하려고 개발자 커뮤니티에서 자주 인용되는 자료 두 개를 “영향받은 것”으로 직접 링크해 뒀다. 하나는 “이해하는 것이 새로운 병목”이라는 제목의 글이고, 다른 하나는 안드레이 카파시가 코딩 에이전트를 “천재적인 주니어 개발자”에 비유한 트윗이다. 주니어 개발자는 일을 빨리 하지만, 그 일을 맡긴 이상 시니어가 결과물을 꼼꼼히 봐줘야 한다는 비유다. 에이전트가 잘하고 못하고를 떠나서, “일단 맡기고 나중에 확인한다”는 구조 자체가 리뷰의 무게를 키운다는 이야기다.
세만틱 diff — 텍스트 대신 의미로 본다
Whiteboard가 내세우는 첫 번째 핵심 기능은 러스트(Rust)로 새로 짠 diff 뷰어다. 우리가 흔히 보는 깃허브 PR 화면의 diff는 텍스트 줄 단위로 비교한다. 그래서 함수 하나에서 들여쓰기만 바뀌어도, 실제 로직은 그대로인데 그 블록 전체가 빨갛고 파랗게 칠해진다. 진짜 바뀐 게 뭔지는 사람이 눈으로 다시 걸러내야 한다.
Whiteboard의 diff 뷰어는 코드를 텍스트가 아니라 문법 구조(AST, 코드를 나무 모양으로 분해한 표현)로 이해한다. 그래서 실제로 의미가 바뀐 부분만 강조해서 보여줄 수 있다. 공식 설명에 따르면 새로 추가된 긴 함수는 통째로 펼쳐 보여주는 대신 의사코드(pseudocode) 형태로 요약해서 먼저 보여주고, 유닛 테스트나 문서처럼 로직에 영향을 주지 않는 변경은 기본적으로 접어서 숨긴다. 리뷰어는 “이 변경이 실제로 뭘 하는지”를 먼저 훑고, 필요할 때만 원본 코드를 펼쳐 보면 된다. 이 요약·접기 규칙 자체도 WASM 기반 플러그인으로 바꿀 수 있게 열어 뒀다고 밝혔다.
다이어그램에서 코드로 바로 점프한다
두 번째 축은 다이어그램과 코드의 연결이다. 시퀀스 다이어그램이나 ER(엔티티-관계) 다이어그램, 혹은 에이전트가 남긴 실행 기록의 인용문을 캔버스에서 클릭하면, 그 근거가 된 실제 코드 줄로 화면이 바로 넘어간다. 다이어그램만 보고 “이게 진짜 코드에 반영됐나?“를 따로 확인할 필요가 없다는 뜻이다.
코드를 열어본 화면에서는 VS Code 그대로의 키바인딩과 LSP(언어 서버 프로토콜 — 코드 자동완성·정의 찾기 등을 처리하는 표준 규격) 지원이 딸려 온다. 신택스 하이라이팅은 물론이고, 어떤 함수를 클릭해 “정의로 이동”하거나 “이 변수를 쓰는 곳 전부 찾기” 같은 기능이 리뷰 화면 안에서 그대로 동작한다. 같은 원리로 웹 UI는 저장소 코드 브라우저 역할도 겸한다. 파일 트리를 넘기면서 특정 파일이나 디렉터리에 한정된 커밋 이력을 보고, 커밋 상세의 diff를 접었다 펼 수 있고, 브랜치·태그도 화면에서 바로 고를 수 있다.
결정 로그 — 에이전트가 왜 그렇게 짰는지
세 번째 축이 가장 새롭다. Whiteboard 팀은 “에이전트가 자율적으로 내린 결정들이 전체 변경에 어떻게 영향을 미쳤는지 판단하기가 어려웠다”고 문서에 적었다. 그래서 에이전트가 스스로 자신의 실행 기록을 캔버스에 남기고, 그 기록들을 서로 연결할 수 있는 구조를 만들었다.
말로 풀면 이런 식이다. 사람이 “이 API에 로그인 기능을 추가해 줘”라고 처음에 요청한 내용, 에이전트가 실제로 구현한 코드, 그리고 그 사이에 에이전트가 스스로 판단해서 고른 세부 결정(예: 세션 만료 시간을 몇 분으로 잡을지, 에러 메시지를 어떤 형태로 돌려줄지)까지 한 화면에서 추적할 수 있다. 리뷰어 입장에서는 “이건 내가 명시적으로 시킨 부분”과 “이건 에이전트가 알아서 판단한 부분”을 구분해서 볼 수 있게 된다는 뜻이다 — 에이전트 코드 리뷰에서 실제로 제일 궁금하고, 지금까지는 diff만 봐서는 알기 어려웠던 지점이다.
이게 왜 중요하냐면, 지금까지는 이 정보 자체가 어디에도 남지 않았기 때문이다. 에이전트한테 나중에 “왜 이렇게 짰어?“라고 다시 물어보면 그럴듯한 답을 주긴 하지만, 그건 그 순간 다시 만들어낸 설명이지 실제로 그 결정을 내렸던 시점의 기록은 아니다. 사후에 지어낸 설명과 실제 판단 근거는 다를 수 있다. Whiteboard의 결정 로그는 에이전트가 작업하던 그 순간의 트레이스를 그대로 캔버스에 남기기 때문에, 나중에 다시 물어봐서 받는 답변보다 신뢰도가 높다는 게 이 기능의 요점이다.
VS Code를 패치가 아니라 통째로 얹은 이유
Whiteboard는 VS Code의 오픈소스 버전인 Code OSS를 패치 방식이 아니라 통째로 가져와서(vendoring) 쓴다. 흔히 쓰는 VS Code 포크들은 원본에 패치 몇 개만 얹어서 유지보수 부담을 줄이는데, Whiteboard는 반대로 원본 코드 전체를 가져온 뒤 필요 없는 부분을 걷어내는 쪽을 택했다.
이유가 흥미롭다. 공식 문서 원문을 그대로 옮기면 “코딩 에이전트는 패치를 잘 다루지 못한다”는 것, 그리고 “다들 전용 에이전트 TUI나 데스크톱 앱으로 넘어가면서 우리는 이제 텍스트 에디터를 한 줄씩 diff를 검토하는 용도로만 쓰고 있다”는 것이다. 덧붙여 “요즘 VS Code 코드베이스의 약 45%는 코파일럿(깃허브의 AI 코딩 기능)이 짠 것”이라며, 그중 자신들에게 필요 없는 부분을 걷어냈다고도 밝혔다. 대신 보안·기능 패치는 업스트림 Code OSS를 계속 지켜보다 정기적으로 병합한다고 설명한다.
지금 아직 못 하는 것
공식 문서가 스스로 인정한 한계는 세 가지다. 첫째, 앞서 말한 대로 파일을 편집할 수 없다. 둘째, 여러 저장소를 넘나드는 리뷰는 아직 잘 지원되지 않는다 — 마이크로서비스처럼 저장소가 여러 개로 쪼개진 팀이라면 한 화면에서 전체를 보기는 어렵다는 뜻이다. 셋째, 리뷰 화면을 공유 버튼으로 다른 사람에게 보낼 수는 있지만, 공유한 뒤에 원본을 업데이트해도 상대방 화면엔 자동으로 반영되지 않는다. 바뀐 내용을 보여주려면 다시 공유해야 한다.
Whiteboard는 로컬 체크아웃(자기 컴퓨터에 내려받은 저장소)을 대상으로 동작하는 완전한 오픈소스(MIT 라이선스) 데스크톱 앱이고, 팀용 호스팅 제품은 아직 계획 단계라고 밝혔다. 지금은 macOS와 Fedora(리눅스 배포판)용 다운로드만 공개돼 있다.
어떤 모델과 같이 쓰면 좋은가
공식 가이드는 “우리 경험상 GPT-6 Sol이나 Claude Opus 5.5 같은 모델이 지능·비용·속도의 균형이 가장 좋다”고 적었다. 다만 프롬프트를 Whiteboard 자체에 입력하는 방식은 아니다. Claude Code나 Codex 같은 기존 코딩 에이전트한테 “이 커밋들을 최신 main과 비교해서 리뷰하고 Whiteboard에 열어 줘”라고 지시하면, 에이전트가 자체 SDK를 통해 캔버스에 다이어그램과 설명을 직접 그려 넣는 식으로 작동한다. 즉 Whiteboard 자체는 모델을 새로 붙이는 도구가 아니라, 이미 쓰고 있는 에이전트의 출력을 받아서 보여주는 캔버스에 가깝다.
실제로 써보면 어떤 흐름인가
공식 데모 영상에서 보여주는 흐름은 대략 이렇다. 터미널에서 코딩 에이전트에게 리뷰를 요청하면, 에이전트가 변경 사항을 분석해 Whiteboard 캔버스 위에 시퀀스 다이어그램과 함께 리뷰 문서를 그려낸다. 사람은 그 다이어그램을 보면서 궁금한 지점을 클릭해 실제 코드로 들어가고, 마음에 안 드는 부분이 있으면 그 화면을 클립보드로 캡처해 에이전트에게 다시 넘긴다. 그러면 에이전트가 피드백을 반영해 캔버스를 다시 그린다.
도입 절차 자체는 세 단계로 짧다. macOS나 Fedora용 앱을 내려받아 실행하고, 시작 화면에서 Claude Code나 Codex를 연결한 다음, 에이전트에게 리뷰를 요청하면 끝이다. 팀 전체 계정 연동이나 별도 서버 설정 같은 절차는 필요 없다 — 로컬 체크아웃을 그대로 쓰기 때문이다.
공식 문서는 실제로 팀에서 쓸 법한 요청 예시도 두 개 공개했다. 하나는 새 API를 추가하는 커밋 묶음을 두고 “제안하는 API 형태, 사용 예시, 이 변경의 동기(맥락에서 확인 가능하다면)를 보여달라”고 요청하는 식이다. 다른 하나는 실제로 더 구체적인데, “가장 최근 posthog PR의 텔레메트리 변경 내용을 설명해 줄 수 있어? 뭘 추적하는 거고, 좋은 대시보드나 제품 퍼널을 어떻게 만들 수 있을까? 행(hang)이나 에러, 크래시는 어떻게 처리하고 있어? Whiteboard를 써서” 라고 커밋 링크와 함께 구체적으로 묻는 예시다. 요청이 구체적일수록 캔버스에 그려지는 리뷰 문서도 그만큼 자세해진다는 뜻으로 읽힌다.
이미 있는 AI 코드 리뷰 도구들과는 뭐가 다른가
AI가 코드 리뷰를 도와주는 서비스 자체는 새롭지 않다. 깃허브의 Copilot 코드 리뷰 기능이나 CodeRabbit 같은 SaaS형 리뷰 봇은 PR이 올라오면 자동으로 코멘트를 달아주는 방식으로 이미 많이 쓰인다. 이런 도구들의 공통점은 “PR 화면에 코멘트를 추가하는 부가 기능”에 가깝다는 것이다.
Whiteboard는 접근 자체가 다르다. PR 화면에 코멘트를 얹는 게 아니라, 리뷰라는 행위를 위한 별도의 작업 공간(캔버스)을 통째로 만들었다. 그 안에서 다이어그램·코드·에이전트의 판단 근거가 서로 링크로 연결되고, VS Code 수준의 코드 탐색 기능까지 그대로 들어온다. 다시 말해 “리뷰 보조 기능”이 아니라 “리뷰 전용 환경”을 표방한다는 점에서, 앞서 나온 리뷰 자동화 서비스들과는 체급이 다르다. 물론 그만큼 로컬에 앱을 설치하고 에이전트를 직접 연결해야 하는 진입장벽도 있다 — 클릭 한 번으로 PR에 봇을 추가하는 SaaS형 도구보다는 설정이 더 필요하다.
확인된 것과 확인되지 않은 것
이 글을 쓰는 시점 기준으로 확인한 사실은 이렇다. 깃허브 저장소는 2026년 8월 18일에 만들어졌고, 오늘(2026년 9월 25일) 기준 스타 1,245개, 최근 커밋은 몇 시간 전이다. 해커뉴스 “Show HN” 글은 같은 날 395점으로 1위에 올랐고, 라이선스는 MIT다.
다만 dev.fast의 정확한 팀 규모, YC로부터 받은 투자 금액, 유료 호스팅 제품의 출시 시점 같은 세부 사항은 공식 발표 자료에 나와 있지 않아 이 글에는 넣지 않았다. 텔레메트리는 코드·diff·프롬프트·모델 출력을 포함하지 않는다고 문서에 명시돼 있고 언제든 끌 수 있다고 돼 있지만, 정확히 어떤 항목이 수집되는지는 공식 텔레메트리 레퍼런스 문서를 직접 열어 확인하는 걸 권한다 — 이 글은 그 레퍼런스의 전체 항목을 옮기지는 않았다.
수치나 사실이 빠르게 바뀔 수 있는 초기 오픈소스 프로젝트라는 점도 감안할 필요가 있다. 스타 수나 HN 순위는 이 글을 쓰는 순간의 스냅샷이고, 릴리스가 몇 주 안에 더 나올 가능성도 높다. 실제로 도입을 검토한다면 이 글보다는 저장소의 최신 커밋과 이슈 트래커를 직접 확인하는 쪽을 권한다 — 초기 단계 도구일수록 문서와 실제 동작 사이의 간극이 빠르게 좁혀지거나, 반대로 새로운 한계가 드러나기도 한다.
기여하고 싶다면
프로젝트는 기여와 피드백을 열어 두고 있다. 기여 절차는 CONTRIBUTING.md에, 행동 규범은 CODE_OF_CONDUCT.md에 정리돼 있고, 보안 취약점은 SECURITY.md에 나온 절차대로 별도 보고하게 돼 있다. 질문은 공식 디스코드 채널에서 받는다. 이런 문서들이 저장소 첫 화면에 빠짐없이 갖춰져 있다는 것도, 8월 중순에 만들어진 지 한 달 남짓한 프로젝트치고는 운영 체계가 이미 잡혀 있다는 신호로 볼 수 있다.
코딩 에이전트를 팀에서 쓰고 있다면
지금 당장 Whiteboard를 도입하지 않더라도 이 도구가 짚은 문제 자체는 대부분의 팀에 이미 와 있다. 에이전트가 만든 diff를 훑어보고 그냥 승인하는 습관이 있다면, 그 diff 안에 에이전트가 “알아서” 내린 결정이 몇 개나 숨어 있는지 스스로 한 번 점검해 보는 것부터 시작해도 된다. 예를 들어 다음 리뷰에서는 “이 부분은 내가 시킨 것”과 “에이전트가 알아서 판단한 것”을 구분해서 표시해 달라고 에이전트에게 직접 요청해 보는 것도 방법이다. 별도 도구 없이 지금 쓰는 에이전트에게 프롬프트만 바꿔서 물어봐도, Whiteboard가 캔버스로 자동화해 준 그 구분을 텍스트로나마 흉내 낼 수 있다.
이 도구를 오늘 당장 설치하지 않더라도 기억해 둘 만한 지점은 하나다. 에이전트가 “무엇을 했는지”는 diff가 보여주지만, “왜 그렇게 했는지”는 별도로 물어보지 않으면 영영 기록에 남지 않는다는 것. Whiteboard는 그 “왜”를 구조화해서 남기는 데 특화된 도구고, 비슷한 문제의식을 가진 도구가 앞으로도 계속 나올 가능성이 높다.
멀티 에이전트 팀 협업 구조를 다뤘을 때도 비슷한 결론이었다. 에이전트를 더 많이, 더 빠르게 굴릴수록 결국 사람이 마지막에 확인하는 지점의 설계가 전체 워크플로의 병목이 된다는 것이다. Whiteboard처럼 “리뷰 자체를 전용 도구로 분리하는” 접근이 앞으로 몇 개월 안에 더 많이 나올 가능성이 높은 이유이기도 하다.