🤔 개인프로젝트 vs 팀프로젝트
개인프로젝트와 팀프로젝트의 차이는 무엇일까?
혼자가면 빠르게 갈 수 있지만, 함께하면 멀리 갈 수 있다는 말처럼,
세상에는 혼자 할 수 있는 것보다 함께 해야 가능한 일이 훨씬 많다.
그래서 개인적으로는 팀프로젝트가 훨씬 의미 있고 좋다고 느낀다.
- 함께 고민하고, 성장할 수 있고
- 내가 맞다고 생각한 코드도 팀원의 의견을 통해 조율해 나갈 수 있다
이 과정이 바로 확증 편향에서 벗어나고, 더 좋은 방향으로 함께 나아가는 힘이 아닐까.
👂 함께 나누는 개발, 그래서 팀프로젝트가 좋다
혼자 개발하면 조율할 필요가 없어 빠르지만,
서로의 생각을 듣고 나누면서 더 좋은 과정을 함께 설계해가는 게 정말 좋다.
그래서 팀프로젝트를 좋아하고, 함께 고민하고 성장하는 걸 선호한다.
기능을 하나 개발할 때도 단순히 구현만이 아니라
- 어떤 문제가 있었고
- 어떤 해결 방안이 있었으며
- 어떤 기술과 구조가 가장 적절한지를 함께 고민하게 된다.
이러한 고민의 깊이는 혼자 할 때보다 팀과 함께할 때 훨씬 더 풍부해진다.
이번 블로그에서는 그중에서도 코드 리뷰에 초점을 맞춰 이야기를 나눠보고자 한다.
🔍 코드 리뷰, 늦게 피어난 애정
사실 처음에는 코드 리뷰를 그리 좋아하지 않았다.
처음에는 리뷰에서 얻는 피드백보다, 그 과정에서 생기는 부담이 더 크게 느껴졌기 때문이다.
하지만 지금은 오히려 코드 리뷰 덕분에 개발이 더 좋아졌고,
작성한 코드에 대한 자신감도 생겼다.
- 내가 고민 끝에 작성한 코드가 의미 있다고 느껴지고
- 그 고민을 담은 PR 설명을 작성하며
- 팀원들의 의견을 들으며 더 나은 방향을 함께 고민하는 과정이 즐겁다
코드 리뷰는 단순히 코드 품질을 높이기 위한 도구를 넘어,
개발자 간의 대화이자 성장의 출발점이라는 걸 이제는 실감한다.
하지만 현실은 언제나 장밋빛만은 아니다.
🧱 코드 리뷰의 벽: 현실적인 문제들
처음에 코드 리뷰에 대해 많이 들었던 말이 있다:
"기능은 작은 단위로 쪼개고, 변경사항은 작게, 테스트 코드는 많이 작성하자."
그래서 develop 기준으로 항상 브랜치를 나누고, 기능별로 PR을 작게 쪼개려 했다.
그런데 실제 프로젝트에서는 이렇게 하기가 쉽지 않았다.
- 리뷰가 지연되면 다음 기능 개발을 시작하지 못하는 경우가 생겼고,
- 일정은 항상 빠듯했고, 기능은 빠르게 배포되어야 했다
예를 들어 기능 1을 구현하고 PR을 올렸는데 리뷰가 늦어진다.
그 상태에서 기능 2를 개발하면 PR 기준을 어디에 맞춰야 할까?
그래서 자연스럽게 feat/1에서 feat/2를 분기하고,
PR을 feat/1에 머지하도록 만들게 된다.
그러면 feat/2의 변경사항만 보이게 할 수 있지만,
develop 기준으로는 머지가 안 되는 문제가 생긴다.
이러한 문제를 겪으며 브랜치 전략에 대해 더 고민하게 되었고,
이전 블로그에서 해당 해결법을 정리하기도 했다. 하지만,
💥 고민의 시작: PR 피드백에서 느낀 아쉬움
어느 날, API 기능 하나를 구현해서 PR을 올렸더니 다음과 같은 피드백을 받았다.
"코드 양이 많고, 클래스별 구현 의도와 목적을 명확히 이해하기 어렵습니다..."
객체지향적으로 역할과 책임을 분리하고, 변수명 하나하나 신경 써가며 작성한 코드였는데,
이런 피드백을 받으니 마음이 아팠다.
나는 변수명, 메서드명, 테스트 코드 작성에 개발 시간의 70%를 쏟는 편인데,
이런 피드백을 들으면 나의 노력이 헛수고처럼 느껴질 수도 있다.
하지만 협업은 혼자만의 기준으로는 완성될 수 없다.
리뷰어의 피드백은 곧 협업의 시그널이고,
이 피드백을 계기로 더 좋은 팀원이 되는 방향으로 나아갈 수 있다고 생각했다.
🧪 나의 진단
1. 코드 양
처음엔 "이건 어쩔 수 없지 않았나..." 하는 생각이 들었다.
예를 들어 단순 조회 기능 하나를 구현하려 해도,
- VO, domain, repository, controller, service, exception 등 기본 구성 필요
- 추상화 적용 시 클래스 수 증가
- 테스트 코드는 실제 코드보다 4~5배 더 길어질 수 있음
하지만 기능과 테스트 코드를 따로 PR로 나누는 건 옳지 않다고 생각했다.
PR은 하나의 기능 단위여야 하고, 검증까지 포함된 형태가 바람직하다.
그렇다면 해결책은?
- 변경사항의 절대적 크기를 줄이는 것
- 기존 코드 기반으로 작업하기
- 구조 개선은 별도의 이슈로 분리
- 공통 로직은 최대한 분리하여 PR 단위를 작게 유지하기
2. 설명 부족
기능 구현에 몰두하다 보면 코드 흐름에 대한 기록을 놓치기 쉽다.
나중에 PR을 올릴 때, "어떤 생각과 의도로 작성했는지" 떠올리기 어렵다.
그래서 앞으로는,
- 커밋 메시지뿐 아니라
- PR 본문에 구현 의도와 사고 흐름을 상세히 작성하는 습관을 들이기로 했다
이런 문서화는 협업을 위한 배려일 뿐 아니라,
나 자신을 위한 리마인드 도구가 되기도 한다.
🔎 자료 조사: 협업은 결국 동료를 위한 것
프로젝트 초기에 컨벤션은 정했지만, 정작 그 이유에 대해 깊이 고민하진 못했다.
- 브랜치 전략, 커밋 컨벤션, PR 템플릿 등은 도입했지만,
- "왜 이런 규칙이 필요한가?"라는 질문에는 막연하게만 답하고 있었다
그래서 최근에 다시 관련 자료를 찾아보며 그 본질을 다시 떠올렸다.
📚 추천 자료:
- https://youtu.be/zRJExmEPg9M?si=7XJOW022TN7rFdGI
- https://youtu.be/VaaRvs8YU1M?si=qwZq1n-bTj5MpxER
- https://youtu.be/PBFUwGPp8DY?si=jVeO1rQ3wqpgrr9_
- https://youtu.be/su-rtXzThjE?si=7c_6qfk-PwbXPA63
- https://youtu.be/65L4mD9o4jU?si=Gcv4MGmO85AsT37a
그중 인상 깊었던 건, 구글/메타 개발자의 말이었다:
"기능 변경은 50줄, 테스트 코드는 150줄."
결국 테스트 코드가 더 크고 중요할 수도 있다는 점.
그리고 리뷰하기 쉬운 PR은 그 구조와 설명이 리뷰어 친화적이어야 한다는 것.
💡 결국 본질은 이것이었다
협업하기 좋은 동료가 되는 것.
내가 성장하려면 리뷰를 받아야 하고,
리뷰를 받으려면 리뷰어가 리뷰하기 좋은 환경을 만들어야 한다.
모든 코드를 꼼꼼히 봐주고 생각까지 나눠주는 건 이상적이지만,
현실에선 그렇게 되기 어렵다.
그렇다면? 리뷰받기 쉬운 구조를 만드는 것이 지금 내가 할 수 있는 최선이다.
✅ 내가 앞으로 실천할 세 가지
- 변경사항은 작게 – PR이 작을수록 리뷰 부담은 줄어든다
- 설명은 자세히 – 의도와 맥락을 충분히 남긴다
- 검증은 철저히 – 테스트 코드 포함된 상태로 PR을 보낸다
여기에 이전에 정리한 브랜치 전략을 잘 적용한다면,
리뷰하고 싶은 PR을 만들 수 있을 것이다.
리뷰하기 쉬운 동료가 되는 것,
그게 결국 내가 성장하는 길이라 믿는다. 🚀
