백엔드와 프론트엔드 협업, 브랜치부터 PR까지
이제 우리는 각자의 역할을 나눠 실제 팀처럼 움직이기 시작합니다.
프런트엔드와 백엔드로 나뉘고, 서로 코드를 주고받고, 하나의 서비스를 만들어가게 됩니다.
이번 편은 단순한 실습을 넘어, **'협업이란 무엇인가'**에 대한 감각을 익히는 시간입니다.
혼자 공부하던 단계를 넘어, 이제는 다른 사람과 함께 무언가를 만든다는 기분.
그 과정 속에서 우리는 개발 지식뿐 아니라, 소통력과 문제 해결력을 얻게 됩니다.
👥 역할 분담 시뮬레이션
역할 정의:
- 프런트엔드: 사용자 화면 UI 구성 (HTML/CSS/JS 혹은 React 등)
- 백엔드: API 서버 구현 (Node.js/Express 기반)
🧩 예시 주제
- 간단한 로그인/회원가입 기능 구현
- 할 일 목록 앱을 프런트-백 분리 구조로 제작
- 뉴스 검색 API를 이용한 검색 결과 페이지 만들기
예시 시나리오:
- 프런트는 로그인/회원가입 UI 페이지 제작
- 백엔드는 사용자 등록 API (POST /signup)와 로그인 API (POST /login) 구현
- API 문서 작성 후, 프런트가 해당 API를 연결하여 실제 로그인 흐름 구축
🔁 협업 기본 원칙
- 각자 로컬에서 작업하되, 하나의 GitHub 저장소를 공유
- 브랜치를 나누어 역할별로 작업한 후 Pull Request(이하 PR)로 통합
- 주기적으로 커뮤니케이션을 통해 요구사항 및 충돌사항 확인
Tip: Notion이나 Google Docs를 활용해 명확한 협업 문서를 만들어두면 좋습니다.
🌿 협업 시 Git 브랜치 전략
브랜치명 용도
| main | 제품 배포 기준이 되는 메인 브랜치 |
| frontend | 프론트 개발 브랜치 |
| backend | 백엔드 개발 브랜치 |
브랜치 명명 규칙 팁:
- feature/login-ui, feature/signup-api, fix/css-bug, refactor/db-model
- 기능 중심 네이밍은 팀원 간 이해도를 높여줍니다.
각 브랜치는 독립적으로 작업되며, 완성 후 PR을 통해 main으로 병합합니다.
이 과정을 통해 팀원 모두가 코드 변경 사항을 명확히 이해할 수 있게 됩니다.
🔁 Pull Request 실습 과정
- 본인 브랜치에서 작업 시작
git checkout -b frontend # 또는 backend
- 작업 완료 후 커밋 & 푸시
git add .
git commit -m "회원가입 폼 구현"
git push origin frontend
- GitHub 웹에서 PR 생성 (→ 병합 대상: main)
- 팀원이 리뷰 후 승인 → main 브랜치로 병합
✏️ 좋은 PR 작성법
- 제목은 간결하고 기능 위주로: feat: 회원가입 UI 구현
- 본문에는 변경 사항 요약, 동작 방식, 테스트 결과 포함
- 리뷰 시 코드 외에도 의도와 맥락을 설명하는 습관을 들이세요
✅ PR 문화는 단순한 형식이 아니라, 개발자 간 소통 방식입니다.
📬 실습 미션: 협업하며 PR 날려보기
- 두 명이 역할 나누어 각자 브랜치 생성
- 각자 담당 기능 구현 후 GitHub에 Push
- 서로 PR 작성 → 리뷰 → 병합
- 로컬에서 main 브랜치 pull → 전체 통합 확인
✅ GitHub의 Issue 기능을 이용해 역할 분담을 명확히 해두면 좋습니다.
예: Issue #3 - 프런트엔드 로그인 화면, Issue #4 - 백엔드 로그인 API 등
보너스 실습:
- GitHub Actions를 활용한 간단한 테스트 자동화 (CI 도입 맛보기)
❗ 협업 도중 자주 발생하는 문제들
상황 해결 방법
| 같은 파일을 동시에 수정 | 미리 역할 조율 + merge 후 conflict 해결 |
| 커밋 로그가 뒤죽박죽 | rebase로 정리 or 커밋 컨벤션 도입 |
| 브랜치가 너무 많아짐 | 정기 정리 + 브랜치 전략 재정비 |
주의할 점:
- 커밋은 자주, 작게
- 충돌이 발생하면 겁먹지 말고 차근히 git status, git log, git diff로 원인 분석
💼 실무 협업 도구 소개
도구 용도 비고
| Slack | 실시간 채팅 및 협업 | 깃 PR 알림 연동 가능 |
| Notion | 협업 문서 및 회고 작성 | API 문서화, 일정 공유 가능 |
| Figma | UI 디자인 협업 | 프론트 개발자와 디자이너간 연동 |
✅ 이러한 도구는 단순한 보조 수단이 아닌, 협업의 핵심 채널이 됩니다.
💡 협업 경험, 왜 중요한가?
- 실무에서는 대부분의 작업이 팀 단위로 이뤄짐
- Git/GitHub 기반 협업 경험은 취업 면접에서 강력한 어필 포인트
- 협업 과정을 명확히 정리하면 포트폴리오에 “협업 경험” 항목으로 활용 가능
예시 문장 (이력서용)
- “2인 팀으로 역할 분담(프런트/백엔드)을 통해 로그인 기능 개발 경험 보유”
- “GitHub PR 리뷰와 병합, 이슈 관리 경험 다수 보유”
정리 노하우:
- GitHub 저장소에 README.md로 프로젝트 개요 + 역할 + 흐름 정리
- Notion으로 회고 노트 정리 (협업에서 느낀 점, 문제 해결 경험)
🔮 다음 단계 예고
이제 협업도 해봤다면,
이제는 ‘배포’, 즉 우리가 만든 서비스를 외부에 공개하는 경험을 해야 합니다.
6편: AWS EC2에 직접 배포해 보기 + 퍼블릭/프라이빗 VPC 분리 구조
→ 실전 배포의 벽을 넘고, 인프라의 개념을 배우는 시간입니다.
🤝 당신의 코드가 누군가와 연결되기 시작했습니다. 이제는 세상과 연결할 차례입니다.