팀 프로젝트에서 Git보다 어려운 건 사람이었다

Об этом предложении

hello world 2026/09/29 엄청 오랜만에 글을 적는 것 같다. 프로젝트 팀을 만드느라, 회사 일을 하느라 정신이 없어서 늦게 적는 것 같다.. 오늘 내가 생각한 글 주제는 팀 프로젝트를 할 때 리더의 입장에서 팀원을 관리하는 방법을 GitHub와 비교해보는 것이다. 열심히 작성했으니 천천히 음미~ 하면서 읽어주길 바랍니다. 서론 작년 말부터 이번 연도 초까지 나는 개인 프로젝트를 주로 진행하며 여러 웹사이트를 구현해봤다. 간단한 게임 사이트부터 저지먼트 사이트, 쇼핑 사이트 같은 것들을 만들어보며 실력을 키웠던 것이 기억에 난다. 하지만 이번 연도 중반, 정식으로 도제에서 회사 준비를 하며 팀 프로젝트를 시작했다. 반 친구들과 팀을 꾸려서 작업했는데, 그때 처음으로 내가 GitHub를 관리했던 것 같다. 친구들과 실력 차이가 난다고 해서 반강제로 팀장을 맡아 진행했기 때문이다.. 그렇게 처음 작업하는 GitHub은 혼돈 그 자체였다. CLI에서 어떻게 commit, push 하는지도 몰라서 1부터 공부하자는 생각으로 블로그들을 찾아봤던 것 같다. git add . git commit -m "feat: implement login" git push -u origin feature/login 위와 같은 기초적인 명령어를 학습하고, Branch protection / Rulesets Pull Request Issues GitHub Projects CODEOWNERS 같은 내용들을 학습하니 점점 관리하기 편해졌다. 처음에는 GitHub가 굉장히 어렵게 느껴졌지만, 막상 기본적인 사용법과 협업 방식을 익히고 나니 생각보다 명확했다. 각자 브랜치를 만들어 작업하고, 작업이 끝나면 Pull Request를 올린다. 이후 코드를 확인하고 문제가 없다면 main에 merge하면 된다. Branch 생성 ↓ 작업 ↓ Commit ↓ Push ↓ Pull Request ↓ Review ↓ Merge Issues를 사용하면 해야 할 작업을 정리할 수 있고, GitHub Projects까지 사용하면 현재 어떤 작업이 진행 중인지도 한눈에 확인할 수 있다. Todo → In Progress → Review → Done 처음에는 commit 하나 하는 것도 어려웠는데 몇 번 사용하다 보니 GitHub 자체를 관리하는 건 그렇게 어렵지 않았다. 규칙을 만들 수 있고, 그 규칙대로 사용하면 됐기 때문이다. 그런데 팀 프로젝트를 계속 진행하다 보니 GitHub보다 훨씬 관리하기 어려운 게 있었다. GitHub보다 어려웠던 팀원 관리 처음 팀장을 맡았을 때는 역할만 잘 나누면 프로젝트가 알아서 진행될 줄 알았다. 너는 프론트엔드 너는 백엔드 나는 전체 관리 정말 이런 느낌이었다. 각자 자신이 잘하는 분야를 맡아서 개발하고, 마지막에 합치면 될 거라고 생각했다. 하지만 실제로 해보니 그렇게 단순하지 않았다. 프론트엔드는 백엔드에서 API가 나와야 작업할 수 있는 부분이 있고, 백엔드는 DB 구조나 서비스 기획에 따라 구현이 달라진다. 디자인이 변경되면 이미 구현한 프론트엔드를 다시 수정해야 하는 경우도 있다. 결국 역할은 나눠져 있어도 프로젝트 자체는 전부 연결되어 있었다. 그리고 더 큰 문제는 사람마다 작업하는 방식이 다르다는 것이었다. 예를 들어 팀원에게 로그인 기능 구현 이라는 Task를 줬다고 해보자. 나는 당연히 로그인 UI부터 API 연결, 예외 처리까지 생각하고 말했는데 팀원은 로그인 UI만 구현하면 끝이라고 생각할 수도 있다. 둘 중 누가 잘못한 것도 아니다. 애초에 작업을 전달한 기준 자체가 애매했던 것이다. 이때부터 Role과 Task는 다르다 는 것을 확실히 느끼게 됐다. Role = 프로젝트에서 주로 담당하는 영역 Task = 실제로 지금 처리해야 하는 작업 Frontend 라는 Role을 줬다고 해서 그 사람이 무엇을, 언제까지, 어디까지 개발해야 하는지가 자동으로 정해지는 것은 아니다. 역할 분담도 중요하지만 그보다 더 세세한 작업 분배가 필요했다. GitHub에는 status가 있는데 사람에게는 없다 GitHub를 관리할 때는 오히려 편하다. PR을 보면 어떤 코드가 변경됐는지 확인할 수 있고, commit history를 보면 지금까지 어떤 작업이 이루어졌는지도 알 수 있다. CLI에서는 더 간단하다. git status 한 번 입력하면 현재 상태가 바로 나온다. 그런데 사람에게는 git status 가 없다. 팀원이 지금 작업을 하고 있는지, 어디에서 막혔는지, 언제쯤 끝날 것 같은지 직접 확인하지 않으면 모르는 경우가 많다. 그래서 처음에는 계속 물어봤다. 어디까지 했어? 이거 언제 끝날 것 같아? 저 기능은 시작했어? 한두 명이면 가능하다. 그런데 팀원이 점점 늘어나면 리더가 모든 사람에게 직접 물어보고 그 내용을 기억하는 것 자체가 일이 된다. 팀원 입장에서도 계속 진행 상황을 물어보면 부담스러울 수 있다. 그래서 생각을 조금 바꿨다. 사람을 계속 확인하는 게 아니라, 확인하지 않아도 현재 상황을 알 수 있게 만들면 되지 않을까? 사람보다 Task를 관리하기 이후부터는 사람 자체를 관리한다는 생각보다 Task를 관리한다는 생각을 하기 시작했다. 작업 하나를 만들더라도 최소한 이런 정보는 필요하다. Task ├── 담당자 ├── Status ├── Priority ├── Deadline ├── Dependency └── Blocker 누가 담당하는지, 현재 상태는 어떤지, 우선순위는 어느 정도인지, 언제까지 해야 하는지, 다른 작업과 연결되어 있는지 등을 기록하는 것이다. 작업 범위를 명확하게 만드는 것도 중요하다. 예를 들어 그냥 로그인 기능 구현 이라고 적는 것보다, 로그인 페이지 UI 구현 로그인 API 연결 로그인 성공/실패 처리 로그인 상태 유지 PR 생성 및 Review 처럼 나눠놓는 게 훨씬 명확하다. 여기서 사용할 수 있는 개념 중 하나가 Definition of Done, DoD 다. 말 그대로 어디까지 해야 이 작업을 완료했다고 볼 것인가? 를 미리 정해놓는 것이다. 내가 생각하는 완료와 팀원이 생각하는 완료가 다르면 나중에 다시 작업해야 하는 일이 생긴다. 차라리 처음부터 완료 기준을 명확하게 만들어두는 게 편했다. 그리고 프로젝트를 진행하면서 하나 더 느낀 게 있다. 작업이 늦어지는 것보다 작업이 늦어지고 있다는 사실을 늦게 아는 게 더 위험하다. 예를 들어 백엔드 API 개발이 하루 정도 늦어졌다고 해보자. 그것만 보면 별문제가 아닐 수도 있다. 하지만 그 API를 기다리는 프론트엔드 작업이 있다면 이야기가 달라진다. Backend API 지연 ↓ Frontend API 연결 지연 ↓ 통합 테스트 지연 ↓ 전체 일정 지연 Task 하나가 밀렸는데 프로젝트 전체 일정이 같이 밀릴 수 있다. 그래서 단순히 누가 일을 얼마나 했는지만 보는 게 아니라, 어떤 Task가 다른 Task와 연결되어 있는지도 확인해야 했다. 이런 작업 간 관계를 Dependency 라고 하고, 현재 작업 진행을 막고 있는 문제를 Blocker 라고 한다. Blocker가 생겼는데 팀원이 혼자 며칠 동안 잡고 있으면 리더 입장에서는 그것을 알 방법이 없다. 그래서 막힌 게 생기면 빠르게 공유하는 것도 팀의 규칙으로 만드는 게 좋다고 생각한다. 그런데 그냥 내가 하면 더 빠르지 않나? 팀장을 하면서 가장 많이 들었던 생각 중 하나다. 팀원이 어떤 기능에서 막혀 있고, 내가 해결 방법을 알고 있다. 설명하고 기다리느니 그냥 내가 코드를 작성하면 한두 시간이면 끝날 것 같다. 그러면 자연스럽게 이런 생각이 든다. 그냥 내가 하면 되는 거 아닌가? 실제로 단기적으로 보면 빠르다. 나도 처음에는 이런 식으로 작업했던 적이 많다. 문제가 생기면 내가 보고, 안 되면 내가 수정하고, 일정이 늦어지면 내가 대신 개발했다. 그런데 계속 이렇게 하다 보면 이상해진다. 팀원 작업이 막힘 ↓ 내가 대신 처리 ↓ 내 작업 증가 ↓ 프로젝트 관리 시간 감소 ↓ 다른 문제를 늦게 발견 ↓ 또 내가 직접 처리 결국 리더한테 모든 작업이 몰린다. 그리고 더 큰 문제는 팀원도 자신이 맡은 부분에 대한 이해도가 올라가기 어렵다는 것이다. 리더 한 명만 프로젝트 전체 구조를 알고 있고, 나머지는 자신이 조금씩 작성한 코드만 알고 있는 상황이 될 수도 있다. 이러면 팀 프로젝트를 하는 의미가 많이 사라진다고 생각한다. 그래서 필요한 게 Delegation, 위임 이다. 위임은 그냥 이거 해주세요. 하고 Task를 던지는 것과는 조금 다르다. 적어도 나는 아래 정도는 같이 전달하려고 한다. Task + Context + Goal + Ownership 왜 이 작업을 하는지, 어떤 결과가 필요한지, 어디까지 담당해야 하는지 알려주는 것이다. 그리고 작업을 맡겼다면 웬만하면 그 사람이 직접 해결할 수 있도록 두는 것도 필요하다. 물론 정말 막혀 있으면 도와줘야 한다. 하지만 도와주는 것과 대신 해주는 것은 꽤 다르다. 팀원 관리에서 프로젝트 관리로 여기까지 오니 내가 처음 생각했던 팀장의 역할과 지금 생각하는 역할도 많이 달라졌다. 처음에는 대충 이런 느낌이었다. 업무 배정 ↓ 진행 확인 ↓ 코드 확인 그런데 지금은 조금 다르게 생각한다. 방향 설정 ↓ Task 분해 ↓ Owner 배정 ↓ Dependency 확인 ↓ Blocker 제거 ↓ Priority 조정 ↓ 전체 진행 상황 확인 결국 리더가 해야 할 일은 모든 작업을 직접 해결하는 게 아니라, 팀원들이 자신의 작업을 해결할 수 있는 상태를 만드는 것 에 더 가깝다고 생각한다. 누군가 작업에 막혀 있다면 왜 막혔는지 확인하고, 다른 팀원의 작업이 필요하다면 연결해준다. 한 사람에게 일이 너무 많이 몰려 있다면 다시 분배하고, 일정상 모든 기능을 구현하기 어렵다면 우선순위를 바꿔야 한다. 여기서부터는 단순한 팀원 관리가 아니라 프로젝트 관리에 가까워진다. 모든 기능을 다 만들 필요는 없다 개발을 시작할 때 계획한 기능을 전부 구현하면 가장 좋다. 하지만 프로젝트를 진행하다 보면 생각보다 시간이 오래 걸리는 기능이 무조건 생긴다. 처음에는 간단해 보였는데 막상 구현해보니 복잡할 수도 있고, 예상하지 못했던 오류가 생길 수도 있다. 그런데 처음 계획을 무조건 지키려고 하면 결국 중요한 기능까지 제대로 완성하지 못할 수도 있다. 그래서 기능에도 우선순위를 정하는 게 필요하다. 간단하게 나누면 이런 방식도 있다. Must → 반드시 필요한 기능 Should → 가능하면 필요한 기능 Could → 시간이 남으면 구현할 기능 예를 들어 서비스의 핵심 기능이 아직 완성되지 않았는데 부가적인 애니메이션이나 편의 기능을 만들고 있다면 우선순위를 다시 생각해볼 필요가 있다. 시간이 부족하다면 Could 부터 버리고 Must 를 먼저 완성해야 한다. 이런 판단도 결국 리더가 해야 하는 일 중 하나라고 생각한다. 계획을 처음부터 완벽하게 만드는 것도 중요하지만, 프로젝트 상황에 맞게 계획을 수정하는 능력도 그만큼 중요했다. GitHub Projects가 프로젝트를 관리해주지는 않는다 다시 처음 이야기로 돌아가 보자. GitHub에는 정말 프로젝트 관리하기 좋은 기능이 많다. Issues를 만들 수 있고, 담당자를 지정할 수 있고, Projects에서 진행 상황을 볼 수도 있다. PR과 Review를 통해 코드가 main에 들어가기 전에 확인할 수도 있다. 처음 GitHub를 공부했을 때는 이런 기능을 잘 사용하면 팀 프로젝트도 자연스럽게 잘 관리될 거라고 생각했다. 그런데 아니었다. Issue를 만든다고 일이 진행되는 것은 아니다. Projects Board를 만든다고 일정이 맞춰지는 것도 아니다. PR 규칙을 만든다고 팀원들끼리 소통이 잘되는 것도 아니다. 결국 이런 기능들은 프로젝트를 관리하기 위한 도구 일 뿐이었다. 중요한 건 그 도구 안에 어떤 Task를 만들고, 누구에게 맡기고, 어떤 작업을 먼저 처리하고, 문제가 생겼을 때 어떻게 대응할지를 결정하는 것이다. Git보다 어려운 건 사람이었다 처음 팀 프로젝트를 시작했을 때 가장 어려운 건 GitHub라고 생각했다. commit도 몰랐고, branch도 헷갈렸고, PR은 왜 사용하는지도 잘 몰랐다. 그래서 공부했다. 명령어를 배우고, GitHub 기능을 찾아보고, 여러 번 사용하다 보니 어느 정도 익숙해졌다. Git은 잘못된 게 있으면 확인할 방법이라도 있다. git status git log git diff 문제가 생기면 기록을 보고 원인을 찾을 수도 있다. 그런데 사람은 그렇지 않았다. 사람마다 실력도 다르고, 개발 속도도 다르고, 프로젝트에 사용할 수 있는 시간도 다르다. 같은 말을 해도 서로 다르게 이해할 수도 있다. 그래서 처음에는 사람을 잘 관리해야 한다고 생각했다. 그런데 지금은 그 생각도 조금 바뀌었다. 사람을 관리하려고 하기보다, 사람들이 각자 움직일 수 있도록 프로젝트를 관리하는 게 더 중요하다고 생각한다. Task를 명확하게 만들고, 누가 담당하는지 정하고, 막힌 부분이 빠르게 보이게 만들고, 필요하면 우선순위를 바꾸고, 리더가 모든 일을 가져가는 대신 각자 자신의 영역에 Ownership을 가질 수 있게 만드는 것. 아직 나도 팀을 운영하고 있는 입장이라 이게 정답이라고 말할 수는 없다. 아마 지금 진행하고 있는 프로젝트가 더 커지고 팀원이 늘어나면 지금과는 또 다른 문제가 생길 것 같다. 그래도 예전에 반 친구들과 처음 GitHub를 켜놓고 git push 하나 때문에 헤매던 때와 비교하면, 지금은 적어도 하나는 알 것 같다. 팀 프로젝트에서 Git을 관리하는 것과 프로젝트를 관리하는 것은 완전히 다른 문제였다. 결론 결론은 생각보다 단순하다. 처음에는 GitHub를 잘 다루고, 역할을 잘 나누고, 팀원들에게 일을 잘 배정하면 그게 좋은 리더라고 생각했다. 하지만 직접 팀 프로젝트를 진행해보니 리더가 해야 하는 일은 단순히 사람들에게 일을 시키고 관리하는 것이 아니었다. 각자 맡은 작업이 명확하게 보이도록 만들고, 누군가 막혀 있다면 그 원인을 빠르게 찾고, 일정이 꼬이면 다시 우선순위를 정하고, 팀원들이 각자의 역할에 집중할 수 있도록 전체적인 흐름을 잡아주는 것이 더 중요했다. GitHub의 Ruleset이나 Branch protection처럼 사람에게 규칙 하나를 설정한다고 모든 게 해결되지는 않는다. 사람마다 실력도 다르고, 개발 속도도 다르고, 생각하는 방식도 다르기 때문이다. 그래서 결국 좋은 리더가 되려면 사람을 통제하는 방법보다 서로 다른 사람들이 하나의 프로젝트를 같이 만들어갈 수 있는 환경을 만드는 방법 을 알아야 한다고 생각한다. 나도 아직 팀을 만들고 운영하기 시작한 지 얼마 되지 않았고, 지금 진행 중인 프로젝트에서도 계속 새로운 문제를 겪고 있다. 아마 팀의 규모가 더 커지고 프로젝트가 복잡해지면 지금 적은 내용만으로 해결되지 않는 문제도 많이 생길 것 같다. 그래도 그런 문제들을 직접 겪어보고 해결하면서 프로젝트를 이끄는 방법도 조금씩 배워갈 수 있을 것 같다. 나중에 지금 진행하고 있는 프로젝트가 어느 정도 완성되면, 실제로 팀을 운영하면서 어떤 문제가 있었고 어떻게 해결했는지도 따로 글로 적어보려고 한다. 추가사항 현재 새로운 프로젝트를 같이 진행할 팀원을 모집하고 있다. 이번 글에서 이야기한 팀 운영 방식도 실제로 적용하면서 프로젝트를 진행해볼 생각이다. 관심이 있다면 아래 모집글을 한번 읽어봐주면 좋겠다. 프로젝트 팀원 모집글 많은 관심 부탁드린다! 이번 글은 여기까지 적어보겠다. 긴 글 읽어주셔서 감사합니다.