Amit Patel, Jujutsu로 코드 이력과 튜토리얼 장별 코드를 함께 관리

Red Blob Games를 운영하는 Amit Patel은 r/roguelikedev의 여름 로그라이크 제작 행사에서 Jujutsu를 사용한 경험을 소개했습니다. 14장짜리 튜토리얼을 따라 게임을 만들면서, 자신의 코드 수정 이력과 독자가 장별로 따라갈 코드 흐름을 함께 관리하려 했습니다.

Patel이 구상한 이력에서 가로축은 시간에 따라 적용한 코드 수정이고 세로축은 튜토리얼의 장 순서입니다. 목표는 완성된 게임뿐 아니라 튜토리얼에 제시할 정돈된 코드와 모두 실행되는 중간 버전 50개를 만드는 것이었습니다. 앞선 장을 고쳐도 뒤쪽 장의 코드를 새 수정 위에 이어 갈 수 있는 구조가 필요했습니다.

Patel은 Git에서도 장마다 브랜치를 만들고 각 브랜치가 앞 장을 부모로 삼도록 하면 같은 구조를 만들 수 있다고 설명했습니다. 이 방식에서는 브랜치와 병합을 관리하며 앞 장의 변경을 뒤 장에 전달해야 합니다. Jujutsu는 변경을 다시 쓸 때 후손 변경을 자동으로 리베이스합니다. Patel은 이를 이용해 장별 변경을 연결했습니다.

던전 생성 장을 작업하던 Patel은 타일 맵 자료구조를 개선할 수 있다고 보고, 앞선 장의 자료구조를 고친 뒤 던전 생성 코드를 이어 갔습니다. 그는 두 부분을 오가며 함께 다듬었습니다. 시야 계산 장에서도 앞선 장의 개선점을 찾아 되돌아갔습니다. 수정 대부분은 최근 장에 집중됐지만 때로는 과거 장까지 손봤고, 병합 충돌이 생기면 이를 해결한 뒤 최근 장의 작업으로 돌아갔습니다.

프로젝트 전체에서 이름을 통일할 때는 앞선 장의 변경을 뒤쪽으로 전달하고, 뒤에서 만든 변경을 앞선 이력에도 반영했습니다. Patel은 과거 장을 편집하는 jj edit과 변경을 앞선 이력으로 옮기는 jj absorb를 함께 사용했습니다. Jujutsu 문서에 따르면 jj absorb는 각 변경을 해당 줄을 마지막으로 수정한 가장 가까운 수정 가능 조상으로 옮깁니다. 목적지를 명확히 정할 수 없는 변경은 원래 위치에 남습니다.

이 자동화가 코드의 의미까지 파악하지는 않습니다. Patel의 예에서 1장의 apple을 zebra로 바꿔도, Jujutsu는 2장에서 사용한 같은 이름을 찾아 바꾸지 않았습니다. 병합 충돌이 없어도 코드가 컴파일되지 않을 수 있어, Patel은 각 장의 코드를 직접 고치고 시험했습니다. 변경이 자동으로 많이 처리돼 작업 흐름을 따라가기 어려운 점도 단점으로 꼽았습니다.

Patel은 개발에는 Jujutsu를 쓰고, 다른 사람이 Jujutsu를 사용하지 않아도 되도록 결과물을 Git으로 내보냈습니다. 그가 밝힌 공개 GitHub 저장소의 Git 커밋은 54개이며, 내부 Jujutsu 커밋은 약 5,000개입니다. 완성된 게임은 웹에서 플레이할 수 있지만, Patel은 이번에는 노트만 작성하고 튜토리얼은 쓰지 않았습니다.