AI가 만든 코드를 다시 이해하려는 화면, Whiteboard
AI 코딩 에이전트가 브랜치를 바꾼 뒤 남기는 것은 대개 긴 diff다. 파일이 열 개만 넘어가도 리뷰어는 무엇이 달라졌는지와 왜 달라졌는지를 따로 복원해야 한다. 9월 25일 GeekNews가 소개한 Whiteboard는 그 복원 작업을 화면 위로 옮기려는 오픈소스 데스크톱 앱이다.
Whiteboard를 소개한 X 게시물
기능과 한계는 개발팀의 GitHub 저장소에서 확인했다. 저장소 설명에 따르면 Whiteboard는 Claude Code나 Codex 같은 코딩 에이전트에 연결된다. 에이전트가 앱 안의 캔버스에 변경 사항을 그릴 수 있도록 SDK를 제공하고, 사람은 그 그림과 코드를 오가며 검토한다. 저장소의 첫 사용 예시는 현재 브랜치를 최신 main과 비교해 Whiteboard에서 리뷰를 열어 달라고 에이전트에 요청하는 것이다.
그림에서 코드로 돌아가는 길
개발팀이 강조하는 첫 기능은 다이어그램의 목적지다. 시퀀스 다이어그램이나 데이터 관계도, 에이전트 실행 기록의 한 부분을 누르면 관련 코드로 이동한다. 설계 그림이 코드와 떨어진 발표 자료로 남지 않게 하려는 시도다. 코드 탐색에는 VS Code에서 익숙한 키 입력과 LSP 기능을 쓴다고 설명한다.
두 번째는 변경 내용을 고르는 방식이다. 개발팀은 Rust로 만든 AST 기반 diff 뷰어가 관련 있는 코드 변경을 추려 보여준다고 말한다. 기본 설정에서는 크게 추가된 함수를 의사 코드로 요약하고, 테스트와 문서 변경을 접거나 숨긴다. 이 동작은 플러그인으로 바꿀 수 있다. 읽는 양은 줄어들 수 있지만, 접힌 테스트가 실제로 무엇을 검증하는지는 원본에서 다시 확인해야 한다. 요약 화면이 리뷰의 출발점일 수는 있어도 변경 전체의 증거는 아니다.
결정 기록을 변경 사항 옆에 놓는다
세 번째 기능은 결정 기록이다. 개발팀은 에이전트 실행 기록을 캔버스에 연결해 사용자가 제시한 요구사항, 구현 경로, 에이전트가 자율적으로 고른 선택을 함께 보게 한다고 설명한다. 저장소의 예시 질문은 특정 PR에서 수집 지표가 어떻게 바뀌었는지, 오류와 멈춤은 어떻게 다루는지를 캔버스로 설명해 달라는 것이다. 줄 단위 변경만 읽을 때보다 설계 이유를 묻기 쉬운 화면이 된다.
여기까지는 개발팀이 공개한 설계와 기능 설명이다. 이 글에서 Whiteboard를 설치해 실제 브랜치의 리뷰 품질을 비교하지는 않았다. 개발팀도 현재는 앱 안에서 파일을 직접 편집할 수 없고, 여러 저장소에 걸친 리뷰는 충분히 지원하지 않으며, 공유한 리뷰는 이후 변경을 자동 반영하지 않는다고 적었다. 로컬 체크아웃에서 작동하고 MIT 라이선스로 공개돼 있다는 사실과, 내 팀의 코드 검토 시간이 줄었다는 결론은 구분해야 한다.
Whiteboard가 겨냥하는 질문은 명확하다. 에이전트가 만든 diff를 받은 사람이 어떤 변경인지 이해하고, 이유를 따라가고, 의심스러운 부분에서 곧바로 코드로 내려갈 수 있는가. 캔버스의 효용도 그 왕복이 실제 리뷰에서 얼마나 잘 되는지로 판단할 수 있다.
