드워프 포트리스도 버전 관리를 쓴다고? · 타른 애덤스 발언 · 1인 개발 교훈

"코드를 블랙박스 같은 곳에 커밋하는 느낌이 싫었어요." 2013년에 드워프 포트리스를 만든 타른 애덤스가 한 말로 전해지는 문장이에요. 그런데 이 게임이 이제는 버전 관리를 쓴다는 이야기가 나왔어요. 개발자 커뮤니티에서는 꽤 상징적인 소식이에요. 세상에서 가장 복잡한 게임 중 하나가 십수 년간 그 도구 없이 굴러왔다는 사실 자체가 전설처럼 돌았기 때문이에요.

이번 이야기의 출발점은 Simon Willison이 2026년 10월 11일에 올린 짧은 블로그 글이에요. 이 글을 따라가며, 실제로 확인되는 것과 확인되지 않는 것을 나눠서 정리해볼게요.

드워프 포트리스는 어떤 게임인가요

드워프 포트리스는 Bay 12 Games의 타른 애덤스와 그의 형제 재크 애덤스가 만든 게임이에요. Game Developer 인터뷰에 따르면 게임이 처음 공개된 날은 2006년 8월 8일이고, PC Gamer 기사에는 두 형제가 2000년대 초반부터 함께 개발해 왔다고 나와요. 플레이어는 난쟁이 무리를 이끌고 요새를 짓는데, 세계 지형과 역사, 인물들의 관계까지 게임이 스스로 만들어내요. 그래서 예상 못 한 사건이 줄줄이 벌어지고, 그 이야기가 입소문을 타며 오랫동안 컬트적인 인기를 얻었어요.

이 게임은 오랫동안 무료로 배포됐어요. 그러다 2022년 12월 6일에 스팀에서 유료판이 나왔어요. 퍼블리셔는 Kitfox Games이고, 그래픽과 더 쉬운 인터페이스가 들어갔어요. 무료 버전은 계속 받을 수 있다고 Game Developer 기사는 전해요.

스팀 출시, 숫자로 보면

PC Gamer가 2022년 12월 13일에 낸 기사에 따르면 출시 6일째에 판매량은 약 30만 장이었어요. 타른 애덤스는 인터뷰에서 첫날 판매량이 16만 장이라는 Kitfox 쪽 발표를 언급하며 지금은 그 두 배쯤 된다고 말했어요. 이 기사의 제목이 "백만장자가 되는 새로운 현실에 적응해야 한다"일 만큼 반응은 컸어요. 이 숫자들은 이 글 뒤쪽에서 중요한 배경이 돼요.

버전 관리가 뭔가요

개발자가 아닌 분들을 위해 짧게 풀어볼게요. 버전 관리는 쉽게 말해 코드를 위한 "변경 내역 기록장"이에요. 워드 문서에서 변경 내용을 추적하고 이전 버전으로 되돌리는 기능을 써본 적 있다면, 그 개념을 프로젝트 전체 파일로 넓힌 거라고 생각하면 돼요.

가장 널리 쓰이는 도구가 Git이에요. 기본 흐름은 이 정도예요.

git add .                       # 바뀐 파일을 기록 대상으로 올린다
git commit -m "난쟁이 AI 수정"  # 변경 내용을 설명과 함께 저장한다
git log                         # 지금까지의 기록을 본다
git switch -c map-rewrite       # 실험용 가지(브랜치)를 만든다

핵심 용어는 두 개예요. 커밋은 "이 시점의 상태를 저장한다"는 뜻이고, 브랜치는 "본선과 따로 실험할 가지를 만든다"는 뜻이에요. 나중에 가지를 본선에 합치는 일을 병합이라고 부르고, 같은 부분을 두 사람이 다르게 고쳤을 때 생기는 문제가 병합 충돌이에요.

애덤스는 무슨 말을 해왔나요

Simon Willison의 글은 타른 애덤스의 발언 세 개를 시간순으로 놓았어요. 아래는 그 글이 소개한 내용이고, 번역과 요약은 제가 한 거예요.

2013년 발언은 Reddit 링크 형태로만 인용돼 있어서 저는 원문을 직접 열어 확인하지 못했어요. 2016년 발언 역시 PC Gamer 인터뷰 3쪽에 있다고 Willison이 링크했지만, 제가 가져온 페이지 본문에서는 그 문장을 직접 확인하지 못했어요. 두 발언은 Willison의 인용을 그대로 전한 것이라고 봐주세요. 반면 2023년 발언은 Game Developer 원문에서 직접 확인했어요.

2023년 인터뷰의 맥락

이 인터뷰는 스팀 출시 직후인 2023년 3월 14일에 나왔어요. 퍼블리셔와 일해본 소감을 묻는 질문에 애덤스는 대체로 만족한다고 답했어요. 빌드를 올리는 일은 마찰이 거의 없고, Kitfox도 훌륭하다고 했어요. 그러면서 확인해야 할 디스코드 채널과 사용해야 할 버전 관리가 생겨서 과정이 예전보다 훨씬 복잡해졌다고 덧붙였어요.

여기서 눈여겨볼 건 말투예요. 버전 관리를 "도입했다"고 선언하지 않고, 달라진 작업 환경을 설명하다가 자연스럽게 언급했어요. 그만큼 이미 일상이 됐다는 느낌이 들어요. 다만 이건 어디까지나 저의 해석이에요.

왜 바뀌었을까요

인터뷰에서 확인되는 사실과 제 추측을 나눠서 말해볼게요.

확인되는 사실은 이래요. 같은 인터뷰에서 애덤스는 올해 새 프로그래머 Putnam이 합류했다고 말했어요. 그리고 이 게임은 "처음부터 여러 사람이 함께 작업하도록 설계되지 않았다"는 취지의 말도 했어요. 앞서 보았듯 퍼블리셔 Kitfox와 아트, 음악 등 여러 기여자도 들어왔어요.

여기서부터는 제 분석이에요. 혼자 코드를 쓸 때는 버전 관리가 주는 이득이 작아 보일 수 있어요. 어제의 나와 오늘의 나만 조율하면 되니까요. 하지만 두 번째 프로그래머가 같은 코드를 건드리는 순간 상황이 달라져요. 누가 무엇을 바꿨는지 추적해야 하고, 동시에 수정한 부분을 합쳐야 해요. 이 지점에서 버전 관리는 선택이 아니라 사실상 필수에 가까워져요. 애덤스가 도구를 갈아탄 건 취향이 변해서라기보다 일하는 방식이 바뀌어서라고 보는 게 합리적이에요.

브랜치와 병합 충돌, 애덤스의 걱정

같은 인터뷰에서 가장 흥미로운 대목은 앞으로의 계획을 이야기한 부분이에요. 애덤스는 "맵 재작성"이라는 큰 작업을 언급했어요. 2D에서 3D로 넘어오며 생긴 구조적 문제를 다시 손보는 작업인데, 코드의 상당 부분을 뜯어고쳐야 한대요. 그는 또 다시 여러 해에 걸친 대형 업데이트 주기를 겪고 싶지 않다고 했어요.

그러면서 이런 취지로 말했어요. 버전 관리가 계속 잘 돌아간다면 그 작업을 위한 브랜치를 따로 만들어 밀고 가면서, 본선에서는 계속 패치하고 심지어 상당한 기능도 추가할 수 있을 거라고요. 하지만 병합 충돌이 상당할 것으로 예상하고, 이 부분은 자신이 경험이 없다고도 인정했어요.

이 대목은 버전 관리가 단순한 백업이 아니라 "개발 전략을 바꾸는 도구"라는 걸 보여줘요. 예전에는 큰 재작성을 하려면 몇 년 동안 새 기능을 멈추고 한 줄기로 가야 했어요. 브랜치가 있으면 두 줄기를 동시에 굴릴 수 있어요. 대신 나중에 합칠 때 값을 치러야 하고, 애덤스는 그걸 정확히 알고 있었어요.

이번 소식에서 확인되지 않는 것들

글을 끝내기 전에 선을 분명히 그어둘게요.

• 정확한 전환 시점은 알 수 없어요. 확인된 건 2016년 3월에는 안 쓴다고 했고 2023년 3월에는 쓴다고 했다는 것까지예요.
• 어떤 도구를 쓰는지는 확인한 자료에 없어요. Git이라고 단정할 근거가 없어요.
• Willison은 글에서 스팀 성공으로 "백만장자가 되기 전에" 도입한 게 아쉽다는 취지의 농담을 했어요. 하지만 제가 확인한 건 2022년 12월 PC Gamer 기사에서 이미 판매량이 크게 올랐다는 것과, 버전 관리를 언급한 인터뷰가 2023년 3월이라는 것이에요. 도입이 성공 이전이었는지 이후였는지는 이 자료만으로는 판단할 수 없어요.
• 새로운 소식처럼 보이지만, 근거가 되는 발언은 3년도 더 된 인터뷰예요. Willison이 이를 다시 꺼내 정리한 거고, 최근 개발팀이 따로 발표한 내용은 확인하지 못했어요.

혼자 만드는 개발자에게 남는 교훈

애덤스의 사례는 두 방향으로 읽을 수 있어요. 하나는 "버전 관리 없이도 훌륭한 게임을 만들 수 있다"는 쪽이고, 다른 하나는 "팀이 커지면 결국 필요해진다"는 쪽이에요. 둘 다 맞아요. 다만 그가 십수 년을 그렇게 버틴 건 코드를 혼자 완전히 이해하고 있었기 때문이라는 점은 따져봐야 해요. 보통의 1인 개발자에게 그대로 적용하기는 어려워요.

애덤스가 병합 충돌을 두고 "경험이 없다"고 솔직히 말한 점도 배울 만해요. 도구를 늦게 도입하면 그만큼 익힐 기회도 늦어져요. 작은 프로젝트에서 미리 브랜치와 병합을 연습해 두면, 프로젝트가 커졌을 때 큰 재작성을 겁내지 않고 시작할 수 있어요.

결국 이 소식이 전하는 메시지는 "버전 관리를 쓰라"는 훈계가 아니에요. 도구는 작업 방식을 따라간다는 것, 그리고 작업 방식은 팀과 규모가 바뀌면 함께 바뀐다는 것이에요. 20년 가까이 혼자 코드를 지켜온 개발자도 새 동료가 생기자 도구를 바꿨어요. 내 프로젝트가 지금 어느 단계인지 가늠해 보고, 필요해지기 전에 한 걸음 앞서 준비해 두는 것. 그게 이번 이야기에서 가져갈 만한 실용적인 교훈이에요.