[팀 프로젝트 1] 협업의 힘듦. 부끄러운 후기

 

 

 

1. 부끄럽지만, 1일차와 2일차

 이 글을 A님과 B님이 볼 수도 있다는 생각을 안 하는 것은 아니다. 그리고 또 누구에게 보여주기에도 참 부끄럽고 민망한 경험이다. 그러나 진정한 회고... 나아지는 리더, 팀원이 되기 위해서 솔직하게 적어본다.

 

 팀이 결정된 후(6/29) 조장을 자원했다. 그리고 그날 바로 조원분들께 하고 싶은 주제가 있다면 생각해오라고 말씀드렸다.

팀원 중 한 분은 정보공학을 전공하셨고, 정보보안 쪽으로 가고 싶다고 하셨다. 개발 위주로 하고 싶고. 안 다뤄본 언어도 없으신 것 같았다.  나에게 "python으로 개발하나요?" 라고 물어보셔서 "네, 그렇겠죠?"(Java를 쓰진 않을테니...?) 라고 말씀드렸는데, "요즘 Javascript가 유행인 것 같아서요."라고 했을 땐 조금 놀랄 수밖에 없었다. 나도 개발에 대해서 잘은 모르고... 안 배운지 제법 오래됐긴 했지만... 그래도 나쁜 분 같지 않았다. 그래서 일기장에 '걱정은 되지만 나쁜 분 같지는 않다.'고 적었다. 내 주제에 감히 사람을 평가하며... 

 

 다음날 메모지를 나눠드리고, 거기에 원하는 주제를 쓰게 했다. 그렇게 익명으로 원하는 주제를 받고 정하려고 했다. 그러나 이번 프로젝트는 '클론 프로젝트'! 어떤 사이트를 클론하고, 거기서 페인 포인트를 분석하고 그걸 개선하여 서비스를 만드는 것. 그래서 메모지는 버려지게 되었고. 새로운 주제를 생각해보기 시작했다. 

 

 오전엔 남은 수업을 들었다. 각자 자기코드로 해보기엔 오류 잡느라 시간이 다 갈것 같아서, 강사님 코드를 받아서 그걸 배포해보는 방식이었다. 물론... 나는 약간의 도전심에 내 코드를 가지고 railway 배포를 도전해보았다. (결국은 왠지 모르겠지만 홈페이지 접속하면 백엔드 응답만 나왔음.) 내 옆자리에 앉아계신 분은 애니메이션 유튜브를 틀어놓고 수업을 들으시면서 도중에 취업 공고를 보곤 하셨다. 그러다가 배포가 잘 안됐는지 강사님께 손을 들었고... 강사님이 오셨다. 문제는 '.env'파일이 없는 것! 강사님도 env 파일은 공유해줄 수 없다고 했었기에... 강사님은 그 분의 프로젝트 폴더에서 .env 파일을 찾기 시작하셨다. 그러나, 프로젝트 폴더는 비어있었다. 

 강사님께 자소서를 쓰느라 바빠서 수업을 듣지 못했다고 말하는 게 들렸다. 이 프로젝트 만드는 거 배우는 걸로 우리 프로젝트를 해야하는데 괜찮을까? 조금 걱정이... 많이 됐다... 같이 점심을 먹고 조심스레 얘기를 꺼내보았다. "수업 안 들으셨는데 괜찮으시겠어요?"

"아니예요. 수업 들었어요. 그냥 파일 하나가 없었어요."

 어찌보면 파일 하나가 없었던 게 맞긴 맞다. 나머지 파일들은 다 강사님이 마지막에 제공해주셨기 때문이다. 배포연습용으로... 그러나 묘하게 어긋나는 맥락과 어찌보면 거짓말이 될 수 있는 말에 나의 걱정은 조금 더 늘어났다. 

 

 

 키우는 강아지가 유기견이었다 - 이런 얘기를 하다가 유기견 사이트 얘기가 나왔다. 데이터를 좀 다뤄야하고, AI로 기능 붙일 게 있고(AX) 그래서 포인핸드로 정하게 되었다. 기획자 출신인 분도 계셨는데, BM얘기가 나왔다. 아무래도 유기동물 공고 사이트는 BM이 약하다는 편견(?)이나 사실이 있어서 아무래도 그쪽이 걱정됐다. 당장 생각나는 건 펫보험 연계, 장례 서비스나 요즘 늘어나는 펫 산업과 연계하는 것 정도... KPI를 어떻게 정의해야 할지도 모르겠고, 하지만 가보자고~ 

 

 사실 첫날엔 주제 정하기가 가장 어려운 것인데, 빠르게 정해져서 처음은 순탄했다. 다 같이 모여서 Claude(고-급모델)와 함께 기획 정석(?) 순서를 밟아나갔다. 도메인 이해부터 수요 분석, 페인 포인트 분석 등 ... 기획자 출신이신 분도 계시고 의견을 잘 내주셔서 좋았다. 개발 위주로 하고 싶다는 두 분은 말씀이 거의 없으시긴 했지만 그래도 대충 잘 굴러가고 있었다. 일은 AI가 하는데 왜 내가 힘드냐.

 RAG 데이터를 모으기 위해 A님께 부탁드렸는데 B님이 자기도 하고 싶다고 하셔서, 두 분이 그럼 상의해서 역할 나눠서 해달라고 말씀드렸다. 그래서 그 분들은 RAG 데이터를 모으고, 나와 C님은 기획안을 조금 더 다듬는 일을 하고 있었다. 그렇게 시간이 지나고... 강사님이 오셔서 우리 프로젝트의 페인 포인트, 문제 정의 등에 대해 여쭤보셨다. "유기동물에 대한 사람들의 생각이 아니라, 실제 포인핸드를 이용하는 사람들의 페인 포인트를 분석한 것이 맞냐"는 질문에 B님이 "아니, 그것까진..." 이라고 하셨다. 

 내가 실제 포인핸드를 이용해본 사람이기도 했고, 실제로 포인핸드 이용하는 유저의 페인포인트를 분석한 것이 맞았는데... 그래서 내가 부가적으로 설명을 했다. 그것에 대해서 조사를 했고, 저도 사용 중에 실제로 불편함을 느낀 부분이었다고. 그래서 그렇게 넘어갔지만 B님이 아직 우리 프로젝트 기획을 할 때 잘 이해를 못 하셨구나, 내가 너무 빨리 나갔나 하는 걱정이 들기도 했다.

 또 B님이 "저희는 크롤링으로 데이터 모으니까 RAG는 할 필요 없죠?"라고 RAG 데이터를 모으시면서..! 그렇게 말하셔서 강사님이 조금 혼내셨다. 그건 완전 별개라고. 그리고 내가 "저희 지금 RAG하기로 했잖아요~"하니까 강사님이 집중하라고ㅠㅠ B님에게 조금 뭐라고 하고 가셨다. 난 한편으론 좀 걱정이 됐다. npm이 poetry죠?라거나 이런 질문을 하실 때마다 걱정되면서도, 물어봐주셔서 다행이라는 생각도 들었다. 또 자주 피곤해하셨고 집중을 어려워하셨다. 그렇게 첫째날은 참 속상하고 힘들게 지나갔다. 

 

 이틀째 아침, C님이 개인사정으로 교육을 아예 하차하게 되셔서... 팀원은 나포함 세 명이 되었고 그래서 더 울적했다. 

하다가 멘탈 터져서 괜히 AI Studio한테 뭐라고 하기...ㅎ 미안해...

 

 

 

AI Studio한테 여러번 잡도리를 했지만 통하지 않았다. AI Studio는 디자이너의 역할 정도... 인데 조금 말을 안 듣는.

똑같이 만들지 않고 막 지 맘대로 만들어! 여기서 완벽하게 수정하려는 것부터가 잘못된 것이란 걸 늦게서야 깨달았다. 

 

html을 화면별로 받은 뒤, 안티그래비티로 가져가서 프론트엔드 작업을 마무리했다. 그게 훨씬 빠르다.

내가 고칠 수 있는 건 내가 고치고... 프론트엔드 많이 까먹긴 했지만 패딩 조절 정도는...할 수 있어요. 

 

그리고 A님이 크롤링을 거의 해주시긴 했는데, 필요한 정보들이 많이 안 넘어와서 크롤링을 내가 해보겠다고 한 뒤에 내가 한 번 더 했다. 그렇게 남아서 조금 더 하고 2일차는 퇴근! 이제 해 떨어지고 집 가는 게 일상처럼 되었지만 오히려 뿌듯하기도 했다.(이때는 뿌듯해선 안됐다)

 

그리고 집에 가는 길...

ㅠㅠ... 나보다 더 늦게까지 남으시더니... 이렇게... A님이 보낸 메세지에 정말 너무 죄송했다. 

너무 감동받고 죄송했다. 난 진짜 협업 초보였던 것이다. 

이렇게 열심히 하시는데 선입견 갖고 대했다니 진짜 너무 부끄러웠다... 

 

집에서 어떻게 해야할지 생각을 좀 해봤다. 내가 PM이라면, 그리고 지금 조장의 역할로서 할 수 있는 게 뭘까?

 

일단 개발에 대해 배운지 너무 오래되신 것 같아서, 프론트/백 구분 정도만 알려드리고

구체적으로 지시 받는 게 더 편하시다고 하셨으니, 좀 더 구체적으로 지침을 내려드리기로 했다. AI, 안티그래비티 쓰는 방법도 조금 더 구체적으로 알려드리기로 했다.

수업을 안 들으셨다면, "질문을 어떻게, 뭘 해야할지"부터 막힐 것 같았기 때문이다. 

아니다 취소. 수업을 들어도 ... 나도 그렇고, AI가 도와준다고 바로 뭔가 만들어내는 프롬프트를 짜는 건 어렵다!

 

 

2. 행복해진 3일차

 

 먼저 시작하기 전에 프론트, 백에 대해서 간단하게 설명드렸다. 사실 나도 잘 모른다 하하; 그냥 그래도... 프로젝트하는데 어떤 언어 쓰는지 어떤 프레임워크를 썼는지 정도는 알고 있어야 할 것 같아서 부족하지만 설명을 드렸다.

그리고 어제 크롤링한 방법을 설명드렸다. 네트워크 응답에서 원하는 데이터를 찾고 헤더URL을 전달하고,  거기서 원하는 데이터들을 뽑아서 정리해달라고 하는 방식을... 나도 그냥 AI 한테 부탁한거지만, 누군가에겐 AI에게 뭐라고 부탁해야할지 조차도 막막할 수 있다는 걸 생각 못 했다. 그리고 수업시간엔 네트워크 탭에서 보는 것, 뽑는 것 배우지도 않았기에 더더욱 어려우셨을 것이다. 그런 환경에서도 300마리 정도의 정보를 스스로 뽑아내신 A님이 너무 대단했다. 

 

 그리고 세 명이서 일을 나눠서 해야했기 때문에, 개발자A/개발자B/나(FE) 이렇게 오늘의 로드맵을 새로 짜기로 했다. 

그리고 PROGERSS랑 ROADMAP을 계속 변경할 것이기 때문에 따로 만든 뒤에 나중에 추합하기로 했다. 이 방식이 맞는진 모르겠다. 근데 이 파일 두 개는 필히 깃 합칠 때 충돌이 날 것 같아서 그렇게 했다. 

 

 

(이렇게 하니까 스키마 파일 등에도 _A, _B를 붙여서 나중에 다 지우고 앞으로는 붙이지 말라고 안티그래비티에게 다시 전해줘야했다.)

 

이런식으로 슬랙을 통해 구체적으로 안티그래비티에 전달할 메세지를 전달드리고, 어떤 내용인지 설명드렸다.

최대한 이해하면서 하시길 바랐다. 그리고 이런 구체적인 지침이 더 편하신지 한 번 더 여쭤봤고, 그렇다고 하셨다. 

 

그리고 실제로 커밋하고 푸쉬하고 하는걸.. - 명령어를 직접 입력해서 하면 좋겠지만, 나도 checkout, pull, push 정도 밖에 못 써서 -

아예 AGENTS.md 에 넣어버렸다.

 

 

 

## 🌿 협업 / Git 규칙 (항상 지킬 것)

> 이 규칙은 **코드를 커밋·푸시할 때마다 항상 적용**됩니다. 기능 종류와 상관없이 예외 없이 따릅니다.

### 브랜치 전략
- **`main`**: 배포·최종 완성본 브랜치. **직접 커밋/푸시 절대 금지.**
- **`feature/...`**: 기능 개발용 독립 브랜치. 모든 작업은 여기서 하고, PR을 거쳐 `main`에 합칩니다.
- **브랜치 생성 필수**: 새로운 개발 작업을 처음 시작할 때는 무조건 브랜치를 새로 따고 시작합니다.
- **단계별 브랜치 순환**: 한 단계 진행할 때마다 새로운 브랜치를 사용하며, 다음 단계 브랜치를 따기 전 기존 브랜치의 작업물은 반드시 **조장의 허락을 받아 원격 push 및 PR(Pull Request)까지 완료**해 둡니다.
- 새 작업 시작 전 항상 최신 `main`을 받은 상태에서 브랜치를 팝니다.
  ```bash
  git checkout main
  git pull origin main
  git checkout -b feature/fe-login   # 새 브랜치 만들고 이동
  ```

### 브랜치 이름 규칙
형식: `접두어/파트-작업내용` (소문자, 단어 구분은 하이픈 `-`)

| 용도 | 형식 | 예시 |
|---|---|---|
| 프론트 기능 | `feature/fe-기능명` | `feature/fe-login`, `feature/fe-main-page` |
| 백엔드 기능 | `feature/be-기능명` | `feature/be-matching-api`, `feature/be-db-setup` |
| 버그 수정 | `fix/fe-버그명` / `fix/be-버그명` | `fix/be-match-format` |

### 커밋 컨벤션
형식: `Type: 요약` (요약은 한글 가능). 제목만 보고 무슨 변화인지 알 수 있게 씁니다.

| 타입 | 설명 |
|---|---|
| `feat` | 새로운 기능 추가 |
| `fix` | 버그 수정 |
| `docs` | 문서 수정 (README, 가이드 등) |
| `style` | 포맷팅·세미콜론 등 (로직 변경 없음) |
| `refactor` | 기능 변화 없는 구조 개선 |
| `chore` | 빌드·패키지 설정·`.gitignore` 등 |

예: `feat: 유기동물 상세 페이지 UI 구현` / `fix: 백엔드 매칭 API 데이터 포맷 에러 수정`

### 커밋 & 푸시 & PR 흐름
```bash
git status              # 변경 파일 확인
git add .
git commit -m "feat: 유기동물 상세 페이지 UI 구현"
git push origin feature/fe-login   # 내 브랜치로 푸시 (main 아님!)
```
그다음 GitHub에서 `Compare & pull request` → 리뷰어에 **`haneebunny`** 지정 → 작업 내용 요약 작성 → `Create pull request` → **조장에게 알립니다.**

### ⚠️ 필수 주의사항
- 🚫 **`main`에 직접 푸시 절대 금지.** 반드시 `feature/` 브랜치 → PR → merge 경로만 사용합니다.
- 📦 **의존성 추가 시 lock 파일을 반드시 커밋에 포함합니다.**
  - 프론트(npm): `package.json` + `package-lock.json`
  - 백엔드(Poetry): `pyproject.toml` + `poetry.lock`
  - (아나콘다 사용자는 pull 받은 뒤 추가된 패키지를 수동 설치해야 합니다.)

중요한 규칙 같은 건 대부분 md파일에 넣어놓고 설명 드리기! 그리고 실행계획 먼저 받고 그 다음에 실행하기! 이 규칙을 세워서 하니까, 나중엔 내가 하나하나 매니징 안 해줘도 잘 하셨다. 나중에 잠깐 뭐 기다리면서 쉬라고 말씀드린 적도 있는데, 쉬다가 A님이 먼저 "뭐 할 거 없을까요?"라고 여쭤보시기도 했다... 감동...

 

이날 아쉬운 건, 한 분은 커피 안 드시는 거 모르고 커피 사다드림... 그리고 강제로라도 휴식시간을 가져서 나 또한 쉬고, 편하게 쉴 수 있도록 분위기를 만들었어야했는데 그러지 못했다. 내가 쉬라고 말은 해도 안 쉬고 하고 있으니 쉬기 어려우셨을 것 같다는 생각이 나중에서야 들었다. 정말 3일차는 협업 한다는 느낌이 더! 많이 들고, 즐거웠다. B님도 기능 구현을 실제로 해보시면서, 작동하는 페이지 보면서 즐거워하셨다. 나도 너무 뿌듯하고 기뻤다... 

 

이 날은 회고 써달라고 말씀도 안 드렸는데, 알아서 먼저 써놓으셨더라! 오히려 내가 늦게 썼다 ㅎㅎ 

 

 

 

---

 

이 밑은 그냥 3일차 진행하면서 웃기고 귀여운 것 모아놓은 것들! 

내가 svg이미지 줘야하냐니까 알아서 잘 한다더니 이렇게 만들어놓음...ㅠㅠ ㅋㅋㅋ

 

 

안티그래비티한테 말투로 뭐라한 적 없는데 말투가 좀 이상해졌다. 갑자기 너무 고개숙이시는,... 왜 그러세요.

 

 

 

QA 할 때 B님이 보내신 메세지. 나중에 보고 행복해졌다. 

결국 이 스크린샷은 ppt에 넣게 되었다.