팀프로젝트 - 커머스 백오피스

정채림·2026년 2월 25일

문제1: "팀원 간 진행 상황 동기화 오류"

상황: 누가 무엇을 어디까지 했는지 파악이 잘 되지 않고, 팀원들의 소통 오류가 생겨서 작업에서 자잘한 문제가 생김(git pull을 했는데 오류가 남 등).

어려움: PM으로서 전체 진척률 파악이 어렵고, 계속해서 팀원으로부터 "이것 되어있나요?" 라는 질문을 받게 됨.

해결법: 깃허브의 칸반 보드 활용.

GitHub project 칸반보드를 활용하여 모든 티켓의 상태(To Do, In Progress, Done)를 시각화하여 실시간으로 확인하고, 깃허브 앱을 슬랙과 연동하여 팀원들의 PR을 빠르게 받아보고 리뷰할 수 있도록 하였다.

교훈

"PM의 역할은 팀원이 코딩을 잘하게 만드는 것이 아니라, 팀원이 '무엇을' 코딩해야 할지 명확하게 결정해 주는 것이다."

문제2: "Git 머지 충돌로 인한 코드 통합 지연 및 빌드 오류"

상황: 여러 팀원이 동일한 파일의 인접한 코드를 동시에 수정하면서, git merge나 pull을 할 때마다 대규모 충돌(Conflict)이 발생함. 충돌을 해결하는 과정에서 실수로 다른 팀원의 코드를 지우거나, 잘못된 코드가 메인 브랜치에 합쳐져 전체 프로젝트 빌드가 깨지는 상황이 반복됨.

어려움: PM으로서 기능 구현보다 '충돌 해결'에 팀원들의 리소스가 과하게 투입되는 것을 목격함. 누가 어떤 파일을 건드리고 있는지 실시간으로 공유되지 않아 중복 작업이 발생하고, 코드 통합에 대한 공포(Merge Hell)로 인해 배포 주기가 늦어짐.

해결법: Git Flow 전략 수립 및 Protected Branch 설정
팀 내 Git Flow(Feature - Develop - Main) 전략을 명문화하여 작업 단위를 세분화함. 한 번에 너무 큰 단위의 PR(Pull Request)이 올라오지 않도록 원칙을 세웠으며, GitHub의 Protected Branch 기능을 활성화하여 최소 2명 이상의 승인(Approve)과 빌드 테스트 통과 없이는 메인 코드로 합쳐질 수 없도록 강제함. 또한, 작업 시작 전 반드시 develop 브랜치를 최신화하도록 프로세스를 개선함.

교훈

"PM의 역할은 팀원이 코딩을 잘하게 만드는 것이 아니라, 팀원이 '누구의 방해도 받지 않고' 코딩할 수 있는 안전한 환경을 설계하는 것이다."

0개의 댓글