<aside> 🧭

한 줄 요약

백엔드 개발자로 시작했지만, 팀원들의 경험 차이와 프로젝트 전체 일정을 고려해 팀장·PM·인프라 역할을 맡았다. 개발 기준과 자동 배포 환경을 만들고 팀원들의 문제 해결을 지원했으며, 일정 안에 해결하기 어려운 실시간 영상·음성 연동은 직접 구현해 팀의 완주를 이끌었다.

</aside>

프로젝트 스냅샷

팀 구성과 역할 변화

• 전공자 3명: AI 1명, Backend 1명, Infra·PM 1명인 나
• 비전공자 3명: Frontend 2명, Backend 1명
• Backend 담당자 중 한 명도 Backend가 처음이었고, 팀원 대부분이 프로젝트 경험이 부족했다.
• 나 역시 처음에는 Backend 개발자로 참여했지만, 구현이 일부 인원에게 집중되면 일정과 팀원의 성장 기회를 함께 잃을 수 있다고 판단했다.
• 개인 기능을 더 많이 가져가는 대신 팀장·PM·Infra 역할로 전환해 방향, 일정, 개발 기준, 배포 기반을 책임졌다.

<aside> ⚖️

선택의 기준

내가 직접 구현하면 당장의 속도는 높일 수 있었지만, 프로젝트는 여섯 명이 각자의 기능을 완성하며 성장해야 한다고 생각했다. 그래서 내 개발 속도보다 팀의 성장 속도를 우선했다.

</aside>

핵심 수행 내용

1. 팀장·PM — 방향과 일정의 불확실성 줄이기

• 아이디어 구체화와 MVP 범위 설정을 주도하고, 4주 일정을 기획·설계·개발·배포·QA·발표 단계로 나눴다.
• Jira에서 업무를 기능 단위로 쪼개 담당자와 일정을 명확히 했다.
• Notion에는 논의 중 나온 아이디어, 의견, 최종 결정과 근거를 기록해 같은 논의를 반복하지 않도록 했다.
• 데일리 스크럼과 수시 공유를 통해 막힌 지점을 빠르게 드러내고 우선순위를 조정했다.
• 팀원의 현재 역량뿐 아니라 스스로 기능을 완성하며 성장할 수 있는 범위를 고려해 업무를 배분했다.

2. 개발 기반과 협업 기준 만들기

• Spring Boot 프로젝트 초기 구조를 구성하고 공통 응답, 예외 처리, JPA Auditing 등 Backend 공통 기반을 마련했다.
• 코드 컨벤션, 브랜치·커밋 전략, Issue·PR 템플릿을 정리해 팀이 같은 기준으로 개발하도록 했다.