혼자는 천재, 팀에는 민폐 - 혼자 개발하다 팀 협업으로 넘어올 때 가장 어려웠던 것

팀 협업 입사 적응 경험담 ⏱ 읽는 시간 약 9분

사이드 프로젝트 3년 경력, 입사 첫 달에 현실을 마주했다. 기술이 문제가 아니었다

입사 전 나는 꽤 자신 있었다. 사이드 프로젝트 경험 3년, GitHub 커밋 500개 이상, Next.js로 서비스도 두 개 만들어봤다. 기술 면접도 무난하게 통과했다. "팀에서도 잘 할 수 있겠지"라는 생각은 입사 첫 주에 박살났다.

내 첫 PR에 코멘트가 14개 달렸다. 기능은 됐는데 코드가 문제였다. 변수명, 함수 분리, 커밋 메시지, 파일 구조. 전부 "나한테는 당연한" 방식이었는데, 팀한테는 달랐다. 그날 퇴근길에 "내가 이걸 왜 못 하지"가 아니라 "내가 이걸 왜 몰랐지"가 더 컸다.

 

혼자는 천재, 팀에는 민폐

3년

입사 전 혼자 개발한 기간

14개

첫 PR에 달린 리뷰 코멘트

3개월

팀 협업 방식에 적응하는 데 걸린 시간

5가지

가장 어려웠던 충돌 포인트

 

혼자 개발과 팀 협업, 뭐가 다른가

혼자 개발할 때는 내가 규칙이었다. 변수명도 내 맘대로, 커밋 메시지도 asdf도 괜찮았다. 폴더 구조는 그날 기분에 따라 달랐다. 이게 나쁜 게 아니었다. 혼자라면 머릿속에 모든 컨텍스트가 있으니까.

팀은 달랐다. 내 코드를 다른 사람이 읽는다. 내 커밋을 다른 사람이 리버트해야 할 수도 있다. 내 변수명을 6개월 뒤 신입이 봐야 한다. 혼자 개발에서 최적화된 습관이 팀에서는 전부 마찰이 됐다.

항목	혼자 개발	팀 협업	내가 틀렸던 부분
커밋 단위	기능 하나 완성되면	논리적 변경 단위	한 커밋에 파일 23개 수정
브랜치 전략	main 하나	feat/fix/hotfix 분리	main에 직접 push 시도
코드 스타일	내 기준	팀 컨벤션 문서	ESLint 경고 무시하고 PR
함수/변수명	내가 알면 됨	팀원이 읽어야 함	data2, tmp, res 남발
리뷰 요청	없음	PR + 설명 필수	PR 설명 없이 "확인 부탁드립니다"
에러 처리	console.log	로깅 시스템 + 사용자 메시지	프로덕션 코드에 console.log 40개

 

가장 어려웠던 다섯 가지

01

내 코드가 틀렸다는 걸 인정하는 것

첫 PR 리뷰에서 시니어 개발자가 "이 부분은 이렇게 하는 게 낫습니다"라고 했을 때, 솔직한 반응은 "내 방법이 틀린 건 아닌데"였다. 이게 방어 심리라는 걸 알면서도 좀처럼 "맞아요, 배웠어요"가 안 나왔다. 3년 동안 내 방식이 정답이었으니까. 이 심리를 넘어서는 데 한 달이 걸렸다.

심리적 허들이 기술 허들보다 높았다

02

커밋 메시지 — 왜 이렇게까지 해야 하나

혼자 개발할 때 커밋 메시지는 나한테 쓰는 메모였다. fix, 수정, 작동됨. 팀에서는 달랐다. Conventional Commits 형식으로 feat(auth): 소셜 로그인 카카오 연동처럼 써야 했다. "왜 이렇게까지?"라고 생각했는데, 두 달 후 예전 커밋에서 버그 원인을 추적할 때 제대로 된 메시지가 얼마나 중요한지 직접 체감했다.

귀찮음이 나중에 팀의 시간을 아낀다

03

Merge Conflict — 처음엔 공황 수준이었다

혼자 개발할 때 브랜치는 main 하나였다. 충돌이 날 일이 없었다. 처음으로 팀 레포에서 머지 컨플릭트가 났을 때 VSCode 화면이 빨간 줄로 가득 찼다. 어느 쪽 코드가 맞는지 몰라서 팀장한테 Slack으로 "저 잠깐 도움 요청해도 될까요"를 보냈다. 지금은 컨플릭트를 보면 그냥 해결하는데, 그때는 30분 넘게 걸렸다.

모르면 물어보는 게 제일 빠르다

04

내 속도를 팀 속도에 맞추는 것

혼자 개발은 내 페이스가 전부였다. 팀에서는 스프린트 일정이 있었다. 예상보다 오래 걸리면 팀 전체 일정이 밀렸다. 처음엔 "오래 걸린다"고 말하는 게 창피해서 말을 못 했다. 결과적으로 마감 전날에 "아직 30% 남았어요"를 말하는 최악의 상황이 한 번 있었다. 그 뒤로 진행이 막히면 하루 안에 공유하는 습관을 들였다.

막히면 하루 안에 말하기

05

내 코드를 설명해야 한다는 것

혼자 개발할 때 코드는 "돌아가면 됐다". 팀에서는 PR을 올리면서 왜 이 방법을 선택했는지를 설명해야 했다. 처음엔 설명 없이 PR만 올렸다. "확인 부탁드립니다" 한 줄이 전부. 리뷰어 입장에서 코드 의도를 모르니 질문 코멘트가 쏟아졌다. PR 설명을 제대로 쓰기 시작하자 리뷰 코멘트 수가 절반으로 줄었다.

PR 설명 잘 쓰면 리뷰 시간 반으로

 

커밋 메시지 — 전후 비교

❌ 혼자 개발할 때 커밋 메시지

commit a3f9d2c
Author: 나
Date:   Mon Oct 14 23:41

    수정

commit 7b21e8a
Date:   Mon Oct 14 22:03

    됨

commit 2cd45f1
Date:   Mon Oct 14 19:55

    asdf

commit 9e87a3b
Date:   Mon Oct 14 15:22

    일단 저장

✅ 팀 컨벤션 익힌 후

commit f8a2c1d
Author: 나
Date:   Thu Nov 7 18:30

    fix(auth): 카카오 로그인 콜백
    리다이렉트 URL 누락 수정

commit 3d91b4e
Date:   Thu Nov 7 16:10

    feat(dashboard): 월별 통계
    차트 컴포넌트 추가

commit c72f8a0
Date:   Thu Nov 7 14:45

    refactor(api): 중복 fetch 로직
    공통 훅으로 추출

 

PR 설명 — 이게 반이다

리뷰 코멘트 수가 절반으로 줄어든 가장 큰 이유가 PR 설명을 제대로 쓰기 시작한 것이었다. 초반엔 PR 설명을 귀찮다고 생각했다. 지금은 PR 설명 쓰는 시간이 리뷰 시간을 줄이는 투자라는 걸 안다.

 

 

 

현재 사용 중인 PR 템플릿 — .github/pull_request_template.md

## 변경 사항
- 카카오 소셜 로그인 연동
- 콜백 URL 환경변수 분리

## 변경 이유
기존 이메일 로그인만 있어 이탈률이 높음.
카카오가 주요 사용자층 SNS여서 우선 적용.

## 테스트 방법
1. 로컬에서 KAKAO_CLIENT_ID 환경변수 설정
2. /login 진입 후 카카오 버튼 클릭
3. 콜백 후 /dashboard 리다이렉트 확인

## 스크린샷
[로그인 버튼 UI 변경 전/후 첨부]

## 관련 이슈
Closes #142

## 리뷰어에게
카카오 API 응답 타입이 공식 문서랑
실제 응답이 달라서 any 처리한 부분 있음.
더 나은 방법 아시면 코멘트 부탁드립니다.

 

3개월 후 — 무엇이 달라졌나

"혼자 개발은 내가 빠른 게 전부였다. 팀 개발은 함께 빠른 게 전부였다. 이 차이를 몸으로 이해하는 데 3개월이 걸렸다."

— 3개월 차 회고 노션 메모

3개월이 지나니까 달라진 것들이 보였다. PR 리뷰 코멘트 수가 14개에서 평균 4개로 줄었다. 머지 컨플릭트가 이제 두렵지 않다. 팀장한테 "막혔어요"를 하루 안에 말하는 게 습관이 됐다. 그리고 코드 리뷰를 받을 때 "내 코드가 공격받는다"는 느낌이 거의 사라졌다.

✅

혼자 개발에서 팀 협업으로 넘어오는 분들께 — 딱 세 가지
① 커밋 메시지는 미래의 동료에게 쓰는 편지 — 내가 왜 이 코드를 썼는지를 남겨야 한다
② 막히면 하루 안에 말하기 — 혼자 끙끙거리는 게 팀에서는 가장 큰 비용이다
③ 내 코드가 아니라 팀의 코드베이스 — PR 리뷰는 공격이 아니라 집단 지성이다

💜

솔직히 말하면, 아직도 어려운 게 있다
3개월이 지난 지금도 완전히 적응됐다고 할 수는 없다. 혼자 빠르게 처리하고 싶은 충동이 가끔 올라온다. 스프린트 마감이 촉박할 때 "이거 그냥 main에 직접 밀까"라는 생각이 스친다. 그 충동을 누르는 게 팀 개발자로 성장하는 과정인 것 같다.

---

💬 혼자 개발에서 팀으로 넘어올 때 가장 어려웠던 건 뭐였나요?

비슷한 경험을 겪으신 분들, 혹은 지금 팀 협업에 적응 중인 분들의 이야기가 궁금합니다. 특히 "이건 나만 어려웠나?" 싶은 것들 편하게 댓글로 남겨주세요. 혼자 개발이 더 익숙한 분들도, 처음부터 팀에서 시작한 분들도 모두 환영합니다. 🙏