현대 소프트웨어 개발의 핵심 도구인 git이 왜 이렇게 자주 잘못 사용되는지, 그리고 그 배경에 있는 교육, 명령줄, 배포 경험의 부재를 살펴본다.
한동안 계속 떠들어 온 교육 프로젝트에 이제 이름이 생겼고, 랜딩 페이지도 생겼다! Arca를 만나 보자. 얼리 액세스는 잘 되면 다음 주에 공개될 예정이고, 그때까지는 글쓰기 프로젝트를 위한 기부를 해 주는 분들께 개별 자리를 계속 드리고 있다.
Git은 소프트웨어 세계의 형태를 만드는 데 깊이 중요하게 작용한 도구다. 처음에는 Linux kernel 작업을 하는 개발자들의 필요를 충족하기 위해 개발되었지만, 이제는 사실상 가장 널리 쓰이는 소프트웨어 버전 관리 시스템이 되었고, 좋든 싫든 거의 모두가 사용하는 도구가 되었다. Github는 Microsoft의 현재 운영에서 거대한 비중을 차지하고 있는데, 이것은 대체로 git 저장소를 위한 공개 원격 저장소일 뿐이다. 대부분의 PaaS 시스템은 git 저장소를 자신들이 배포하는 핵심 산출물로 삼고 있고, 대부분의 CI/CD 시스템은 첫 번째 기준점으로 git 저장소를 기대한다.
그렇기 때문에 기술 업계의 엄청나게 많은 사람들이, 그리고 어떤 맥락에서든 코드를 쓰는 사람들 가운데서는 더 큰 비율의 사람들이 git을 전혀 제대로 쓰지 못한다는 점은 우려스럽다. 이들은 merge conflict가 나면 패닉에 빠진다. Claude Code로 12,000줄짜리 커밋을 만들고 형편없는 커밋 메시지를 남긴다. 브랜치를 어떻게 써야 하는지 모른다. 원격 저장소에서 main 보호를 하지 않고, 그러다가 git을 잘 모르는 다른 누군가가 거기에 푸시해서 프로덕션 데이터베이스를 실수로 날려 버린다. 극단적인 경우에는 파일을 수동으로 업로드해서 “커밋”을 하거나, 버전 관리가 새롭고 수상한 기술이라는 이유로 아예 쓰지 않는다. 사람들은 어떤 식으로든 이 기술을 제대로 사용하는 데 정말로 애를 먹는다. 왜 이런 일이 벌어지는지 이해하는 것은 아마 유용할 것이고, 이 글은 바로 그 이야기를 다룬다.
(덧붙이자면, 여기서는 주로 개별 개발자의 관점에서 썼기 때문에 브랜칭, pull request, 혹은 대규모 팀에서 정말 원하는 여러 도구들에 대해서는 많이 쓰지 않았다. 부분적으로는 내가 그쪽 경험이 아주 많지는 않기 때문이고, 부분적으로는 여기서 내 주장을 성립시키는 데 그것들이 직접적으로 필요하다고 생각하지 않기 때문이다.)
다행히도, 요즘 소프트웨어를 직업으로 작성하는 사람들 가운데 버전 관리가 아예 전혀 없는 경우는 아주 드물다 (그래도 우리 모두가 편하게 느끼기에는 여전히 너무 자주 일어나지만). 소프트웨어를 핵심 기능으로 삼아 돌아가는 회사에서는 사실상 거의 들어 보기 힘들다. 하지만 그렇다고 해서 도구를 사용하는 과정에서 나타나는 온갖 실패 양상이 사라지는 것은 아니고, 전반적으로 사람들은 git을 정말, 정말 형편없이 사용한다.
내가 본 최악의 실패 양상은 아마 분석 스크립트 모음을 위한 “git 저장소”를 공유 드라이브의 디렉터리 하나로 유지하던 팀이었을 것이다. 기술적으로는 git 저장소로 초기화되어 있었지만, 실질적으로는 그렇게 사용되지 않았다. 그 디렉터리 안에는 수정 시각이 찍힌 코드 압축본들이 들어 있었을 뿐이다. 눈에 띄는 커밋은 거의 없었고, 솔직히 거기서 의미 있는 방식으로 브랜치를 따 보려는 것조차 망설여졌다. 당연히 명령줄 인터페이스 같은 것은 아예 없었고, 사용 가능한 git GUI 소프트웨어도 너무 뒤죽박죽이라 나조차 헷갈렸다. 이런 상황에서는, 그래, 기술적으로는 git을 쓰고 있었다고 말할 수는 있겠지만, 어떤 실제적인 의미에서도 그렇다고 보기는 분명 어려웠다.
이 팀은 어떻게 이런 상황에 이르렀을까? 우선, 이들은 말하자면 소프트웨어 팀이 아니었다. 데이터를 많이 다루고 코드를 써야 하기는 했지만(대부분 R로), 엄밀한 의미의 소프트웨어 팀은 아니었다. 중요한 점은, 그래서 그들이 자신들이 가진 인프라를 제대로 사용하는 법을 배우거나 더 적절한 것을 도입할 수 있게 해 줄 제도적 지원(설령 그게 보잘것없는 수준이었더라도)을 받지 못했다는 것이다. Git은 비교적 단순한 도구지만, 초기에 지속적으로 사용하기 시작하는 데 필요한 시동 에너지를 그냥 넘기기 어렵게 만드는, 자명하지 않은 부분들이 있다. 원격 저장소가 있어야 하고, 사람들을 거기에 인증시켜야 하고, 사람들이 큰 어려움 없이 코드를 push하고 pull하고 커밋하는 법을 보여 줘야 한다. 우리에게는 이제 너무나 당연한 일이지만, 누군가 의도적으로 등을 떠밀어 주지 않으면 배우기 결코 쉽지 않다. 나도 소스 관리를 써야 진지한 엔지니어가 된다는 사실을 인식한 뒤 실제로 도구를 유창하게 다루게 되기까지 몇 년이 걸렸다. 그런 일이 일어나도록 필요한 밀어줌을 아무도 제공하지 않으면, 실제로 그렇게 하기는 매우 어렵고, 이런 종류의 결과는 충분히 예상 가능하다. 사람들은 버전 관리를 대충 조금 쓰기는 하지만, 진지하게 쓰지는 않게 된다.
내가 몇 군데 다른 곳에서도 본 비슷한 실패 양상은, 우리가 git에 대해 이야기할 때 많은 사람들이 자동으로 Github/Gitlab를 떠올린다는 점이다. 나는 실제로 자신들을 소프트웨어 스타트업이라고 주장하던 회사에서도 이걸 본 적이 있다(그들의 비즈니스 모델은 사실 소프트웨어와 크게 관계가 없었지만). 거기서의 패턴은 사람들이 Github에 뭔가를 업로드하고 커밋도 하고 겉보기에 그럴듯한 일들을 다 하지만, 그 모든 걸 Github 인터페이스를 통해서만 한다는 것이다. 때로는 파일을 수동으로 업로드해서 “push”하는 수준에 이르기도 한다. 로컬 도구는 사실상 쓰이지 않는다. 이런 일은 보통 최신 PaaS 도구들(Netlify, Vercel, 그리고 우리 같은 옛날 사람들에게는 Heroku)이 주로 저장소를 받아들여 동작하고, 최신 프레임워크들(Flask, Django, Next.js 같은 것들)이 버전 관리에 대해 아무것도 몰라도 대충 돌아가는 앱을 꽤 빨리 만들 수 있게 해 주기 때문에 생기는 듯하다. 나는 다행히도 Supabase/Fly.io 쪽 상황이나 LLM 도구가 이것을 얼마나 가속했는지는 잘 모르지만, 아마도 좋지 않을 것이다. 이 말은, “앱을 하나 만들었고” 그것을 배포하는 법을 알고 싶어 하지만, 그렇게 하는 데 필요한 도구 체계를 전혀 모르는 사람들이 아주 많다는 뜻이다. 이들은 가이드를 읽고, 코드를 Github 저장소에 넣어야 한다는 걸 보고, Github에 가입해 프로젝트를 만들고, “upload files” 버튼을 본 다음, 아 이게 원래 이렇게 하는 방식이구나 하고 생각한다.
물론 이것은 유난히도 나쁜 상황이다. 대부분의 경우 사람들은 적어도 어떤 의미에서는 말이 되는 방식으로 작업을 커밋한다. 이런저런 방식으로 SSO, IT 직원, 그리고 비공식적인 멘토링이 사람들을 최소한 무난하게 다룰 수 있는 원격 저장소가 있는 수준까지는 끌고 간다. 그래도 사람들은 예를 들어 merge conflict를 어떻게 처리해야 하는지 제대로 이해하지 못하고, 그런 상황이 닥치면 종종 패닉에 빠진다. 마찬가지로 브랜칭이나 rebase도 혼란스럽게 느껴질 수 있고, 뭔가를 되게 만들려고 애쓰는 과정에서 정말 이상한 짓을 하기도 한다. 보통 이쯤 되면 커밋 메시지에 대해서도 불평하고 싶어지지만, 솔직히 나는 개인 프로젝트 작업을 주로 해서 내 커밋 메시지도 대체로 꽤 짧고 아쉬운 경우가 많으니, 그건 좀 위선적일지도 모르겠다. 아무튼 요점은 분명하다. 기술 업계에서 일하는 많은 사람들, 특히 소프트웨어 업계의 핵심부는 아니지만 여전히 소프트웨어를 많이 작성하는 공간에 있는 사람들은 git을 제대로 쓰는 데 정말 큰 어려움을 겪는다.
그러니 질문이 생긴다. 왜일까? git이 현대 기술 실무의 그토록 많은 부분에서 중심적이라면, 왜 우리는 소프트웨어를 작성하는 대다수 사람과 팀이 자기 일의 핵심 도구를 제대로 다루지 못하는 상황에 와 있는 걸까?
가장 직접적인 설명 하나는 명령줄과 관련이 있다. Git은 무엇보다도 우선 명령줄 도구다. 시각적 인터페이스를 만들 수는 있지만, 보통 그렇게 잘 작동하지 않는다. 도구의 논리 자체가 셸에서 사용된다는 전제를 갖고 있기 때문이다. VSCodium 같은 애플리케이션에서도(내 생각에 그래픽 도구 중에서는 꽤 나은 편이다) 단순한 커밋보다 조금이라도 복잡한 일은 결국 명령줄로 하게 된다. (나는 단순한 커밋은 그래픽 도구나 Lazygit으로 하는 편인데, 무엇이 커밋되는지 볼 수 있어서 편하고, 커밋 전에 무엇이 추적되고 있고 무엇이 아닌지 확인하는 걸 잊지 않는 것도 은근히 귀찮기 때문이다.) 특정 커밋이나 태그에서 새 브랜치를 만들거나, 브랜치를 따거나, rebase를 돌리려는 일은 시각적 인터페이스로 굳이 하고 싶지 않은 작업들이다. 그러니 결국 무슨 말이냐 하면, 명령줄만으로 git이 어떻게 작동하는지 잘 이해하지 못한다면, GUI 버전으로 가장 기초적인 작업 이상을 하려 할 때 거의 틀림없이 실제로 곤란을 겪게 된다는 것이다.
그런데 놀랍게도 실제 현업 소프트웨어 전문가들 중 상당수는 명령줄에 관해서는 완전히 길을 잃고 있다. 내 독자들은 이런 사실을 생각하기 싫어할 수도 있고 믿기 어려울 수도 있지만, 소프트웨어 개발 작업의 대다수는 여전히 Windows 머신에서 이루어진다. 예전보다는 덜하지만, 개발자들이 사실상 명령줄에 전혀 접근하지 못하는 상황도 아직 드물지 않다. 모든 것이 어떤 맞춤형 IDE의 “run” 버튼이나 Excel 스프레드시트 같은 것을 통해 이루어진다. William Gibson이 언젠가 말했듯이, “미래는 이미 와 있다. 단지 고르게 분배되지 않았을 뿐이다.” 그리고 엄청나게 많은 사람들은 소프트웨어의 선두권이 이미 10년, 혹은 그보다 더 전에 지나쳐 버린 수준의 도구, 문화, 프로세스 성숙도 속에서 여전히 일하고 있다.
그 자연스러운 결과는, git을 사용하는 많은 사람들이 git GUI가 무엇을 하고 있는지 이해하는 데 필요한 지식도 없고, 무슨 일이 벌어지는지 쉽게 배울 능력도 없다는 것이다(그걸 배우려면 결국 git을 명령줄로 계속 써 보다가 감이 붙어야 한다). 이 말은, 개인 프로젝트를 하는 단독 개발자가 쓸 법한 가장 기본적인 작업-스테이징-커밋-push 흐름조차도(브랜치도 없고, 그냥 main에 커밋하고 작업이 만족스러우면 원격에 push하는 정도) 진짜 고역이 된다는 뜻이다. 전형적인 기업 환경 워크플로에서는 완전히 다른 소프트웨어로 전환하고, 변경 사항이 반영되기를 기다리고, 커밋 버튼을 찾고, 또 다른 폼이 뜨기를 기다리고, 커밋 메시지를 쓰고, 커밋한 다음 다시 IDE로 돌아가서 하던 일을 계속해야 할 수도 있다. 이 모든 것은 몹시 비직관적이다(코드 관련 일은 IDE 안에서 일어나는데 왜 이걸 하려고 완전히 다른 도구로 가야 하지?). 그래서 대충 건성으로 하게 되거나, 아예 어떻게든 피하려고 하기가 쉽다. 좋은 IDE는 적어도 컨텍스트 전환을 줄여 줌으로써 이 문제를 조금 완화할 수 있다. 하지만 앞서 확인했듯이, 우리가 말하는 많은 소프트웨어 작업장은 좋은 IDE에 투자하지도 않고, 직원들이 괜찮은 무료 IDE를 설치하는 것조차 허용하지 않는다.
현대 소프트웨어 세계에서는 명령줄에 대해 아무것도 몰라도 놀랄 만큼 멀리 갈 수 있다. 그 자연스러운 결과로 기술 업계에서 일하는 많은 사람들은 명령줄 사용법이나 셸에서 가장 기초적인 작업 이상을 하는 법을 굳이 배우려 하지 않는다. 그런 상황에서는 사람들이 git 때문에 고생하는 모습을 보는 것이 너무도 당연하다. 계속 git 명령줄 버전만 사용하든, 결국 GUI로 돌아가든, 실제로 무슨 일이 벌어지고 있는지를 제대로 체감하려면 CLI 버전 경험이 꽤 많이 필요하다. 만약 우리가 CLI 활용 능력을 대폭 끌어올리도록 장려한다면 이 문제는 꽤 많이 개선될지도 모른다. 하지만 당연히 사람들은 CLI 사용법을 배워야겠다는 필요도 느끼지 못한다. 그러니 우리는 더 깊은 문제를 다뤄야 한다. 그것은 바로...
새 글이 올라오면 가장 먼저 알아보세요! 내 생각에 대한 독점 업데이트(그리고 약간의 마케팅)를 받으려면 뉴스레터도 구독하세요.
새 글을 받은편지함으로 받아보기 →
이메일을 입력하세요
월간 뉴스레터도 보내 주세요
누군가에게 새로운 기술이나 새로운 내용을 가르칠 때는 두 가지 원칙이 대단히 중요하다. 첫째, 도구에 대한 구체적 이해에서 추상적 이해로 올라가야 한다. 누군가가 현재 상황에 직접 적용 가능한 추상화를 이미 가지고 있다는 걸 절대적으로 _확신_할 수 있는 경우가 아니라면(그럴 때는 그걸 바탕으로 시작할 수 있다), 구체적인 사례에서 출발해 추상으로 쌓아 올려야 한다. 둘째, 가르치는 기술이나 내용의 첫 단계는 사람들에게 즉각적으로 분명한 방식으로 유용해야 한다. 좀 덜 암울했던 시절에는 이것이 수학 같은 것에도 적용되었다(사람들은 늘 수학이 쓸모없다거나 상관없다고 불평했다). 돈이 오가는 사회에서 덧셈, 곱셈, 뺄셈, 나눗셈을 배우는 것은 _잔돈 거슬러 주기_나 예산 세우기 같은 일에 매우 중요하기 때문에, 일이 불쾌하더라도 즉각적인 필요는 분명히 있었다. 비슷하게 나는 십대 때 Magic the Gathering과 Warhammer 40k를 하면서 확률 계산을 훨씬 더 잘하게 되었다. 확률 수학이 당장 필요했고, 그래서 배웠다.
Git과 다른 버전 관리의 문제는, 시간이 흐르면서 구체적 이해를 형성해 추상적 이해로 이어지게 해 주는 소프트웨어 작성 작업의 비율이 점점 줄어들었다는 점이다. 혹은, 더 나아가 이 기술이 당장 자신에게 유용하다는 사실이 분명하게 드러나는 경우도 줄어들었다. 이 문제는 소프트웨어 라이프사이클 전체에 대한 이해 부족에서 시작된다.
뼈아픈 경험을 통해 나는, 어딘가에 배포된 적도 없고 실제로 사용되지도 않는 프로젝트를 가지고 버전 관리의 중요성을 가르치기는 매우 어렵다는 사실을 알게 되었다. 결국 버전 관리의 핵심 가치는, 잃어버린 작업을 복구하거나 이전 버전의 코드를 보는 데 있다기보다는, 그 모든 일을 빠르고 자동화된 방식으로 할 수 있다는 데 있다. 이 지점에서 명령줄 이야기가 다시 등장한다. git의 가치 중 큰 부분은 직접 작성한 셸 스크립트에 통합해 이것저것 자동화할 수 있다는 데 있고, 따라서 UI를 통해 사용하는 것은 그것이 재미있는 이유의 상당 부분을 잃게 만든다. 셸 자동완성이나, 예전에 실행한 명령을 셸 히스토리에서 찾아 수정해 다시 실행할 수 있는 것조차 스크립팅과 자동화의 한 형태라고 볼 수 있다. 아마 내 독자들 중 상당수는 그런 것 없이 지내야 한다는 생각만으로도 이미 몸서리치고 있을 것이다. GUI로 git을 쓰는 사람들은 정기적으로 바로 그런 상황을 겪는다. 하지만 원래의 요점으로 돌아가면, 만약 여러분이 예전 버전의 코드로 엄청나게 빨리 되돌아가야 하는 상황을 한 번도 겪지 않는다면, 애초에 왜 사람들이 버전 관리에 신경 쓰는지 결코 이해하지 못할 수도 있다. 우선, 이 말은 교육 환경에서 버전 관리가 왜 중요한지를 배우기가 꽤 어렵다는 뜻이다. 과제는 보통 이전 버전을 잃더라도 빨리 다시 만들 수 있을 만큼 작고, 처음으로 동작하는 버전이 곧 제출하는 버전인 경우가 많기 때문에, 더 이른 작업 버전으로 롤백해야 할 필요가 거의 없다. 또 이 말은, 이미 자리 잡은 코드베이스에서 일하는 주니어로서 그 기술을 배우기도 쉽지 않다는 뜻이다. 예를 들어 clone하고 특정 브랜치에서 commit하는 것이 일을 전달하고 직장을 유지하는 방식이라는 건 배울 수 있겠지만, 실제 기능의 관점에서는 어떨까? 주니어에게 주어지는 종류의 작업을 생각하면, 여러분이 쓴 코드가 실제로 거의 실행되지 않을 가능성도 크고, 실행되더라도 충돌이 나도 별 문제가 없을 수 있고, 조금이라도 중요한 부분이면 결국 시니어가 중간에 개입해 문제가 main에 올라가기 전에 고쳐 버릴 가능성이 높다. 이미 돌아가는 프로젝트의 주니어로서 여러분이 “젠장, reset 강제로, reset 강제로!”라고 외치게 될 만한 실수를 할 방법은 아주 많지 않다. 설령 그런 일이 생겨도, 요즘은 그런 작업을 DevOps 팀이 하게 될 가능성이 높다. 그러면 애초에 왜 버전 관리를 하는지에 대한 중요한 교훈을 여러분은 배우지 못한다.
이런 상황이 충분히 반복되면, 버전 관리는 사실 별로 중요하지 않다거나, 적어도 자신이 정말 해결하고 싶은 문제를 풀어 주는 도구는 아니라고 생각하기 쉬워진다. 내가 이것을 전달하는 데 가장 효과적이라고 느낀 유일한 방법은 사람들이 처음부터 git을 사용해 자신이 개인적으로 신경 쓰는 무언가(대개 개인 웹사이트)를 작업하게 만드는 것이다. 사실 이것 자체가 많은 버전 관리 사용자들이 한 번도 해 보지 않은 일이기도 하다. 새로운 git 저장소를 만들고 원격 저장소에 연결해 본 적이 없고, 더 나아가 파일을 추가하거나 추적하거나 프로젝트 초기에 하게 되는 온갖 일들을 고민해 본 적도 없다. 그 부분을 이해하는 것만으로도 도움이 되지만, 내 생각에 이런 종류의 학습에서 가장 유용한 점은 _실제로 변경을 되돌리고 싶어지는 상황을 만들어 준다_는 것이다. 디자인 변경은 쉽게 불만족스러워질 수 있고, 웹사이트는 흥미롭고 무시하기 어려운 방식으로 자주 망가지며, 자기 자신에 관한 웹사이트를 다루고 있다면 문제를 빨리 고치고 싶어질 것이다. 실제로 장애가 일어나지 않더라도, 사람들은 도구의 가치를 훨씬 빨리 이해한다.
비슷하게, git이 코드 배포와 배포물 전달에서 어떤 역할을 하는지 이해하는 것도 상당히 중요하다. 2026년의 버전 관리가 해결하는 주요 문제 중 하나는 사실 버전 관리나 버전 유지 자체와는 별 관련이 없다. 오히려 우리는 git과 다른 버전 관리 도구를 통합, 배포, 그리고 코드 전달을 위해 사용한다. 많은 경우 이것들은 버전 관리 기능보다도 더 중요하다고 할 수 있다. 웹사이트의 버전 관리 기능은 _좋은 것_이고, 나는 그걸 포기하고 싶지 않지만, 버전 추적 자체는 로컬에서도 할 수 있다. 하지만 한 명령어로 웹사이트 변경 사항을 배포할 수 있다는 것은(뭐, 정확히는 세 개다. Gitlab CI/CD는 내 경우 버전 태그에서만 배포를 트리거하므로, 진행 상황을 push하고 그다음 태그도 push해야 한다) 엄청나다. 심지어 git이 버전 추적을 전혀 하지 않는다 해도, 원격 저장소에 push하고 자동화 몇 가지를 트리거할 수 있다는 것만으로도 아마 그 자체로 대단히 소중할 것이다. 그리고 그런 일은 git 같은 것이 없이는 도저히 할 수 없다. (물론 SSH 터널을 통해 로컬 디렉터리로 서버의 디렉터리를 덮어쓰는 스크립트를 쓸 수도 있겠지만, 버전 관리가 없는 상태에서 그건 너무 조악하고 약간 무섭게 느껴진다.) 배포를 위해 Github에 파일을 수동 업로드하는 사람들은 나를 짜증나게 하긴 해도, 적어도 왜 이 도구가 유용할 수 있는지 이해하는 방향으로는 꽤 많이 전진한 셈이다. 하지만 사실 요즘 프로그래밍을 하는 대다수 사람들은 평생 자기 힘으로 무언가를 실제로 배포해 본 적이 없다. 웹사이트 하나 띄워 보거나 개인 도구를 유지해야 했던 적이 없는 것이다. 그들의 모든 작업은 도대체 무슨 일이 벌어지는지 알 수 없는 회사 저장소로 들어갈 뿐이다. 사람들이 운영, DevOps, 혹은 실제 코드 배포라는 것을 진짜로 건드려 본 적이 없는 그런 상황에서는, git을 써야 한다는 감각을 못 느끼거나 심지어 그것을 배우고 싶다는 생각조차 하지 않기가 무척 쉬워진다.
이 요소들은 모두 함께 작용한다. 무언가를 배포해 보면, git이 없을 때보다 있을 때 코드 배포나 전달이 왜 훨씬 쉬운지 이해하게 되고, 동시에 왜 무언가를 꽤 빠르게 롤백하고 싶어지는지도 빨리 배우게 된다. 배포할 의도로 프로젝트를 작업하면 원격 저장소를 두는 것과 자주, 작게 커밋하는 것의 중요성이 몸에 새겨진다(그리고 충분히 긴 시간이 지나면, 이상적으로 바라는 만큼 완벽하게 포괄적이지는 않더라도 적어도 정보를 주는 커밋 메시지를 쓰게 된다). 하지만 많은 사람들에게는 그런 경험이 전혀 없고, 앞으로도 가질 가능성이 낮다. 많은 회사 개발자들은 직장에서만 코드를 쓰고, 앞서 이야기했듯이 무엇을 배포하거나 배포물로 전달해 본 적도 없고, 변경 사항을 빠르게 되돌려야 하는 상황에 놓여 본 적도 없다.
Bret Devereaux는 자신의 블로그에서(그리고 곧 나올 책에서도, 아마도: Bret, 이 글을 읽는다면 리뷰어 사본 하나 보내 줬으면 한다. 당신에게는 절대로 아무 도움도 안 되겠지만, 이 블로그에서 리뷰하는 건 재미있을 것 같다) 로마의 군사 작전상 우위에 대해 꽤 많이 썼다. 그의 결론에서 중요한 부분은, 그 우위의 상당 부분이 해당 시기 동급의 적들(내 기억이 맞다면 주로 카르타고와 헬레니즘 왕국들)보다 로마 보병이 훨씬 더 무겁게 무장되어 있었다는 사실에서 나온다는 것이다. 이것이 주는 효과의 상당 부분은 물론 전투에서 부상이나 사망의 위험을 줄이는 데 있고, 전략적·작전적 규모에서 그건 결코 작은 일이 아니다. 하지만 여기와 관련된 또 다른 효과도 있다. 더 무겁게 무장한 병사는 자신이 늘어난 보호력을 어느 정도는 더 공격적으로 싸우는 데 “소비”하는 경향이 있다. _linothorax_만 입고 있거나 아예 무방비 상태라면(갈리아 보병을 논할 때 이런 이야기가 자주 나온다), 방패로 몸을 가리고 가능한 한 적과 거리를 벌리며 꽤 보수적으로 싸우게 된다. 반대로 lorica hamata (사슬 갑옷)를 입고 있다면, 더 가까이 파고들거나, 맞교환의 가능성이 있더라도 적을 가격하거나, 비무장 혹은 경무장 전투원이라면 시도하지 않을 방식으로 적을 다치게 하거나 타격하려는 의지가 생길 수 있다.
내 생각에 이것은 git의 가장 큰 장점 중 하나다(그리고 덧붙이자면 자동화된 테스트도 그렇다). 필요할 때마다 더 이른 상태로 복구할 수 있다는 추가적인 안전성은, 소프트웨어를 만들 때 더 많은 위험을 감수하고 더 많은 시도를 할 수 있게 해 준다. 버전 관리가 전혀 없거나, 기껏해야 폴더 몇 개뿐이라면, 무언가를 시도했다가 망쳤을 때 그동안의 작업을 전부 버리고 훨씬 이전 시점으로 돌아가야 한다. 버전 관리는, 자주 하는 작은 커밋과 결합되면, 작업에서 더 많은 위험을 감수할 수 있게 해 준다. 그리고 그것은 대체로 좋은 일이다. 더 야심차게 시도하고, 더 위험한 것들을 해 보고, 영구적으로 일을 완전히 망쳐 버릴 수는 없다는 확신 속에서 작업할 수 있기 때문이다. 장기적으로는 더 빨리 기술을 배우고, 때로는 상황을 극적으로 더 좋게 만드는 완전히 새로운 패턴까지 익히게 되어 더 나은 코드로 이어진다.
내가 본 것은, 버전 관리 도구 없이 일하는 많은 소프트웨어 개발자들이 프로젝트 전체를 탈선시킬 수 있는 피해를 피하기 위해 방어적인 습관을 발전시킨다는 점이다. 이들은 지나치게 보수적으로 행동하고, 작동한다는 걸 알고 있는 예전 코드를 많이 재사용하며, 새로운 것을 시도하는 데 극도로 조심스러워진다. 극단적인 경우에는 사람들이 같은 애플리케이션을 여러 직장에 복사해 놓고 억지로 모양을 맞추는 상황으로 이어질 수도 있다. 전반적으로 이들은 새로운 패턴, 라이브러리, 언어, 기술, 혹은 어떤 새로운 것이든 시도하려 하지 않게 된다. 버전 관리를 제대로 이해하지 못한다면, 사실 이것은 꽤나 말이 된다. Git은 더 빠르게 움직이고 더 많은 위험을 감수하게 해 주지만, 여러분이 직접 제대로 버전 관리되는 프로젝트에서 작업해 본 적이 없다면 그 사실을 알 수 없다. 행동이 실제로 바뀌려면 안전감, 즉 “좋아, 이걸 망쳐도 그냥 되돌리면 돼”라는 감각이 필요하다. (덧붙이자면, 이 글을 읽는 LLM 지지자 중에서 왜 직장에서 사람들이 LLM 도구를 도입하지 않는지 궁금해하는 사람이 있다면, 이유가 이것일 수 있다. 나는 개인적으로 LLM을 좋아하지 않지만, 여러분이 그것들이 좋다고 생각하고 사람들이 쓰길 원한다 해도, 대상이 되는 사람들이 git이 가져다주는 기본적인 안전성을 체화하지 못했다면, 그들은 절대로 그 도구를 받아들이지 않을 것이다.)
문제는, 우리 중 많은 이들에게 그 안전성이 일종의 제2의 본능이라는 점이다. 우리는 git을 쓰고, 그것이 _작동한다_는 걸 안다. 하지만 그런 안전성이 없는 사람에게는, git을 제대로 쓰는 것(작은 커밋, 자주 하는 커밋, 로컬에서 작업하기, 그리고 제발 하늘 아래 모든 신성한 것들을 위해서라도 push 직전에 큰 커밋 하나만 하지 않기)이 오히려 실제 위험처럼 느껴질 수도 있다. 결국 그것은 새롭고 다소 이상한 도구이고, 그들이 새롭고 이상한 도구에 대해 가진 경험은 대체로 “이거 때문에 작업이 망가져서 전부 다시 해야 했다”는 것이기 때문이다. 여러분은 본질적으로 그들에게 알몸으로 전장으로 뛰어들라고 하면서, 적만큼이나 자신도 다치게 할지 모른다고 그들이 생각하는 새로운 무기를 쓰라고 말하고 있는 셈이다.
이 모든 점들을 종합하면, 왜 이렇게 많은 사람들이 git을 효과적으로 사용하는 데 어려움을 겪는지, 그리고 왜 이 문제가 그토록 끈질긴지에 대한 꽤 강한 설명이 된다고 생각한다. 요컨대, 많은 사람들에게는 이 도구들을 제대로 배워야 할 이유가 눈에 보이지 않으며, 설령 시도하더라도 그 도구를 배우는 과정 자체가 적극적으로 위험하고 불안하게 느껴질 수 있다. 물론 이것은 바람직한 상태가 아니므로, 이제 우리는 어떻게 이 문제를 극복하고 사람들이 git을 효과적으로 쓰게 할 수 있을지로 넘어간다.
git이 꽤 사용자 친화적이지 않고 학습 곡선도 가파르다는 이야기는 제법 많이 나왔고, 여기에 어느 정도 진실이 있는 것도 사실이다. Mira Welner의 훌륭한 글 Can we communally deprecate git checkout?은 이 소프트웨어가 가진 문제의 종류를 보여 주는 훌륭한 사례다. 그래서 업계 표준으로서 git에서 벗어나 다른 것을 써야 한다고 제안하는 사람들도 꽤 있다. Mercurial은 그중 가장 자주 언급되는 것 중 하나다. 물론 나는 Mercurial을 직접 써 본 적이 없고(아마 써 봐야 할지도 모르겠다), 하지만 도구를 바꾼다고 우리의 문제가 해결되지는 않을 거라고 생각한다. 사용성 측면에서의 몇 가지 개선은 도움이 될 수 있겠지만, 여러 면에서 git이 지금과 같은 형태를 하고 있는 데에는 아주 타당한 이유들이 있고, 예를 들어 밀링 머신이나 선반이 쓰기 어렵다고 해서 그걸 바보처럼 단순화하려고 하지는 않을 것이다. 도구를 더 쓰기 쉽게 만드는 것은 할 만한 좋은 일이지만, 그 방법만으로 문제를 없앨 수는 없다.
사람들에게 자기 프로젝트를 만들어서 스스로 배우라고 하는 것도 사실상 출발점이 되기 어렵다. 우선 많은 사람들에게는 그럴 시간이 없다. 내가 이야기하는 회사 개발자들 중 많은 사람들은 삶도 있고 가족도 있고, 퇴근 후 몇 시간씩 git이 왜 중요한지, 어떻게 유창하게 쓰는지를 가르쳐 줄 새 프로젝트를 만들 여유가 없다. 게다가 교사 없이 새로운 기술을 배우는 것은 꽤 어렵다. 대부분의 분야에는 교사가 조금 밀어 줘야 비로소 실제로 노력을 하게 되는 가치 있는 것들이 있고(앞서 말한 시동 에너지를 교사가 공급해 주는 셈이다), 이런 것들 중 상당수는 교사 없이 배우려고 하면 나쁜 습관을 익히기 쉽다. 예를 들어 정말 중요한 것을 정확히 짚는 데 수고를 들이고 싶지 않거나, 형편없거나 틀린 자료를 찾게 되면 그렇다. 적절한 지원을 받는 의욕적인 사람이라면 이 방법이 통할 수 있지만, 쉽게 확장 가능한 전략은 아니다.
현실적으로, 개발자 집단 전체에서 git 사용의 전반적인 질을 끌어올리는 유일한 방법은 소프트웨어 세계의 교육 질을 크게 향상시키는 것이다. 이것은 악명 높을 정도로 큰 도전이다. 그럼에도 형식 교육은 git을 잘 쓰지 못하는 문제를 해결하기 시작하기에 더 쉬운 장소이므로, 먼저 그것을 이야기하겠다. 우리는 코딩을 가르치기 시작하는 거의 즉시 버전 관리를 도입할 수 있다. “hello, world”는 결코 너무 이른 시점이 아니다. 교육 초기 단계에서는 사람이 컴퓨터에 입력하는 거의 모든 것이 이미 어떤 종류의 신비한 룬 문자처럼 느껴지기 때문에, 명령 하나나 둘을 더 추가하는 것은 쉽고, 초기에 습관을 형성하는 데 도움이 된다. 그리고 교육자들은 시간이 지날수록 이것을 굳힐 수 있다. 무엇보다도 교육자들에게는 여기서 중요한 강력한 힘이 하나 있는데, 바로 평가의 조건을 설정하는 힘이다. 모든 과제를 원격 저장소에 push하는 형태로 제출하라고 요구할 수 있고, 그러면 적어도 사람들에게 git 도구의 기초를 효과적으로 쓰도록 강제할 수 있다. 진짜 동기의 빈약한 대체재이긴 하지만, 많은 목적에는 그 정도로도 충분하다.
더 큰 소프트웨어 공간에서 git 교육을 이루는 일은 더 어렵다. 결국 회사가 교육에 시간과 자원을 투입해야 하는데, 그런 일은 아주 자주 일어나지 않는다. 이 부분에 대해서는 내가 내놓을 해법이 많지 않다. (뭐, 해법이 하나 있긴 한데, 그건 내가 팔고 있는 것이고, 그것이 결코 해결책의 아주 작은 일부 이상은 될 수 없다는 점을 나도 잘 알고 있다.) 그래도 실제로 DevOps를 상식적으로 운영하는 곳이라면 떠오르는 첫 번째 생각은, 장기적으로 어떤 직무를 맡을 예정이든 간에 새로 입사한 모든 사람이 처음에는 DevOps를 순환 경험하게 하는 것이다. 적당히 바쁜 회사에서 DevOps 실무에 노출되는 것은, 버전 관리와 git 사용을 진지하게 대하는 것이 왜 중요한지를 사람들에게 각인시키기에 아주 좋은 방법이다. 결국 누군가가 도구를 잘못 사용해서 끔찍하게 일이 터지고, 그걸 여러분이 고쳐야 하는 경험은 대체로 저절로 뇌리에 박힌다. 여기서 떠오르는 또 다른 생각은, 작고 독립적인 도구의 구축과 유지보수를 장려하는 것이 좋을 수 있다는 것이다. 보통은 유지보수 부담이 늘어난다는 이유로 이런 일을 장려하지 않지만, 그 반대급부로 작은 도구를 유지하는 팀들(한두 명이 유지할 수 있을 정도로 작은)은 많은 것을 배우고, 적절한 버전 관리 사용 같은 것들이 얼마나 중요한지에 대한 속성 과외를 자주 받게 된다. 합리적인 범위 안에서 이런 종류의 작업을 장려하는 것은 사람들이 역량을 키우게 하는 좋은 방법일 수 있다.
Git은 우리가 매일 사용하는 거의 모든 소프트웨어, 그리고 사회가 돌아가도록 중요한 일을 배경에서 수행하는 훨씬 더 많은 소프트웨어의 핵심 작업 도구다. 그렇다면 더 많은 사람들이 이 도구가 무엇을 하고 어떻게 작동하는지 강하게 이해하고 있다면 아마 좋을 것이다.
내 글이 마음에 드나요? 더 많은 글을 보고 싶나요? 여기서 지원해 주세요(그리고 앞으로 며칠 안에 기부하고 나에게 알려 주면 제품이 지속되는 한 Arca에 무료로 접근할 수 있다).
독립 글쓰기를 지원하기 →
