GitHub Blog의 ‘GitHub Dungeons’ 실험은 장난감 프로젝트처럼 보이지만, Copilot CLI를 코드 작성 보조가 아니라 비동기 작업자처럼 쓰는 흐름을 잘 보여준다. 핵심은 재미있는 데모 자체보다 저장소 접근 권한, 생성된 PR 검토, 재현 가능한 실행 조건, 위험한 자동화 명령을 어디까지 허용할지다.
핵심 요약
- GitHub의 Lee Reilly는 GitHub Copilot CLI Challenge에서 현재 저장소를 터미널 로그라이크 게임으로 바꾸는 GitHub CLI 확장 GitHub Dungeons를 만들었다.
- 던전은 저장소의 최신 커밋 SHA를 시드로 사용한다. 같은 커밋이면 같은 맵이 나오고, 코드가 바뀌면 던전 구조도 달라진다.
- 구현에는 Binary Space Partitioning(BSP) 방식이 쓰였다. 공간을 재귀적으로 나누고 방과 복도를 연결해 무작위지만 탐색 가능한 구조를 만든다.
- Copilot CLI의
/delegate는 작업을 클라우드에서 실행되는 Copilot coding agent에 넘기고, 결과를 pull request로 돌려주는 방식으로 소개됐다. /yolo는/allow-all의 별칭이다. 데모에는 어울리지만 실제 저장소에서는 권한·롤백·리뷰 경계를 먼저 정해야 한다.
무엇이 바뀌었나
이번 글은 새 제품 발표라기보다 Copilot CLI를 이용한 개발 방식의 사용 사례다. 기존 코드 보조가 “함수나 파일 일부를 제안받는 경험”에 가까웠다면, GitHub Dungeons 사례는 “기능 요구사항을 설명하고, 에이전트가 별도 작업으로 구현한 뒤, 사람이 PR을 검토하는 경험”에 초점을 둔다.
원문에서 Reilly는 Go에 익숙하지 않았지만 Copilot 덕분에 문법보다 동작에 집중할 수 있었다고 설명한다. 예를 들어 /delegate Make each level progressively harder...처럼 레벨 난이도 조정을 지시했고, Copilot은 비동기적으로 1차 구현을 만든 뒤 PR을 열었다. 이후 사람은 게임 밸런스와 세부 동작을 조정했다.
또 다른 예로 “dungeon scribe” 에이전트를 만들어 던전 생성 방식을 설명하는 문서와 ASCII 아트 다이어그램을 생성하게 했다. 이 대목은 에이전트 코딩이 단순 구현뿐 아니라 문서화, 설명 자료, 보조 산출물 생성까지 묶을 수 있음을 보여준다.
코드베이스가 던전이 되는 방식
GitHub Dungeons는 저장소를 읽어 방, 복도, 적, 출구가 있는 터미널 게임으로 렌더링한다. 사용자는 WASD, 방향키 또는 Vim 키로 이동하고, 적과 싸우며, 숨겨진 문을 찾아 다섯 레벨을 탈출한다. 원문은 안개 효과, 자동 공격, 처치 수와 정복한 레벨 같은 통계 추적도 언급한다.
기술적으로 흥미로운 부분은 맵 생성의 재현성이다. 최신 커밋 SHA가 시드로 쓰이므로 같은 코드 상태에서는 같은 던전이 나온다. 반대로 커밋이 바뀌면 던전도 바뀐다. 실제 개발 자동화에 대입하면 “AI가 만든 결과가 매번 흔들리는가, 입력과 버전을 고정하면 다시 확인할 수 있는가”를 따져야 한다는 신호로 읽을 수 있다.
| 원문 데모 | 실무에서 읽을 포인트 |
|---|---|
| 저장소를 로그라이크 던전으로 변환 | 에이전트가 저장소 구조를 읽고 작업 맥락으로 활용할 수 있는지 확인 |
| 커밋 SHA 기반 맵 생성 | 동일 입력에서 결과를 재현할 수 있는지, 버전 고정이 가능한지 확인 |
/delegate가 PR을 생성 |
자동 변경은 바로 병합하지 말고 리뷰 가능한 단위로 격리 |
/yolo와 pre-commit 훅 데모 |
권한을 넓히는 명령과 파괴적 훅은 샌드박스에서만 다뤄야 함 |
실사용 전에 확인할 운영 기준
Copilot CLI나 유사한 에이전트 도구를 업무 저장소에 붙일 때는 먼저 접근 범위를 정해야 한다. 원문 기준으로 /delegate는 클라우드의 Copilot coding agent에 작업을 넘긴다. 따라서 비공개 코드, 고객 데이터, 내부 설정 파일이 포함된 저장소라면 조직의 Copilot 정책, 저장소 권한, 외부 실행 환경에서 볼 수 있는 파일 범위를 확인해야 한다.
두 번째 기준은 PR 단위의 검토 가능성이다. GitHub Dungeons 사례처럼 에이전트가 만든 변경이 PR로 남으면 사람이 diff, 테스트, 롤백 경로를 확인할 수 있다. 반대로 로컬 작업 트리에서 바로 파일을 바꾸거나 넓은 쓰기 권한을 허용하는 방식은 실패했을 때 원인 추적이 어렵다.
세 번째는 자동 실행의 상한선이다. 원문에는 게임을 이기지 못하면 저장된 변경을 잃게 만드는 pre-commit 훅 예시가 나오지만, 글 자체도 강하게 경고한다. 실제 환경에서는 이런 파괴적 자동화가 아니라 임시 브랜치, 깨끗한 작업 트리, 별도 테스트 저장소, 명시적 승인 절차부터 둬야 한다.
소규모 검증 절차
- 테스트 저장소를 따로 만든다. 업무 저장소 대신 공개 예제나 복제본에서 Copilot CLI, GitHub CLI 확장, 권한 프롬프트가 어떻게 동작하는지 확인한다.
- 설치와 실행을 분리한다. 원문 명령은
gh extension install leereilly/gh-dungeons뒤gh dungeons를 실행하는 흐름이다. 설치 단계에서 어떤 권한을 요구하는지, 실행 단계에서 어떤 파일을 읽는지 따로 기록한다. /delegate결과를 PR로만 받는다. 자동 생성된 코드를 바로 병합하지 말고 테스트 실패, 불필요한 파일 변경, 의존성 추가 여부를 리뷰한다./yolo사용을 기본 금지한다. 모든 권한 허용은 데모 환경에서만 허용하고, 팀 저장소에서는 명령별 승인 또는 제한된 권한 모델을 우선한다.- 재현 조건을 남긴다. 실행한 커밋 SHA, CLI 버전, 프롬프트, 생성된 PR 링크를 남겨 같은 결과를 다시 검증할 수 있게 한다.
의미 있는 변화와 한계
GitHub Dungeons가 생산성 도구로 바로 쓰일 가능성은 크지 않다. 하지만 이 실험은 에이전트 코딩 도구를 평가할 때 봐야 할 질문을 잘 드러낸다. “코드를 얼마나 빨리 쓰는가”보다 “작업을 얼마나 잘 나누고, 사람이 검토 가능한 형태로 남기며, 실패했을 때 되돌릴 수 있는가”가 더 중요하다.
특히 저장소 전체를 입력으로 삼는 도구는 맥락을 잘 이해할수록 유용하지만, 그만큼 권한과 데이터 처리 리스크도 커진다. 개인 토이 프로젝트에서는 재미있는 자동화가 될 수 있어도, 회사 저장소에서는 정책·감사·비용·보안 리뷰가 먼저다.
출처와 검증
- 원문: GitHub Blog, “Dungeons & Desktops: Building a procedurally generated roguelike with GitHub Copilot CLI” (Lee Reilly, 2026년 5월 12일)
- 관련 제품: GitHub Copilot CLI
- 프로젝트 참고: leereilly/gh-dungeons
- 본문의 설치 명령,
/delegate,/yolo, BSP, 커밋 SHA 기반 생성, pre-commit 훅 경고는 원문에 나온 내용을 기준으로 정리했다.
결론
GitHub Dungeons는 “AI가 게임을 만들었다”는 가벼운 이야기로 끝낼 수 있지만, 실제로는 Copilot CLI가 에이전트형 개발 흐름으로 확장되는 모습을 보여준다. 업무에 적용하려면 재미있는 결과보다 권한, PR 리뷰, 재현성, 롤백 가능성, 파괴적 명령 제한을 먼저 확인하는 편이 안전하다.