함께 자라기 - 협업을 실천하며 느낀 것들
조영호, 《함께 자라기: 애자일로 가는 길》을 읽고 적용하면서, 함께 성장한 경험을 가지게 되었다.
‘함께 자라기’는 개발 능력만큼이나,
아니 어쩌면 그보다 더 중요한 것이 소통과 협업 능력이라는 사실을 다시 확인하게 해주는 책이다.
IT 산업은 점점 더 복잡해지고, 요구사항은 거대해지고 있다.
각자 맡은 역할도 다르고, 배경도 다르고, 생각하는 방식도 다르다.
그 속에서 혼자 뛰어난 사람보다,
함께 성장하는 팀이 훨씬 더 큰 가치를 만든다.
그래서 협업을 더 잘하고 싶었다.
그리고 그 답을 찾기 위해
《함께 자라기》를 읽고, 책의 내용을 실제 팀 프로젝트에 적용해 보았다.
책이 나에게 말해준 것
책을 읽으며 가장 크게 와닿은 문장은 이것이었다.
“성장은 개인이 독주하는 순간보다
팀이 서로의 배움을 격려하는 순간에 더 크게 일어난다.”
그래서 나는
배우는 데서 멈추지 않고, 직접 실천하기로 결심했다.
그래서 진짜로 해보았다 - 협업을 위한 10가지 실천
책을 읽고 끝나는 것이 아니라,
현재 프로젝트에 바로 적용하며 “함께 자라기”를 경험해보고 싶었다.
아래는 내가 실제로 도입하고, 팀 전체가 직접 실천했던 방식들이다.
1️⃣ 하루 세 번의 회의 — 피드백 루프 짧게 가져가기
- 각자 기능 구현하고, 아침/점심/저녁 회의 때, 질문 나누기
- 각자 구현한 기능, 트러블 슈팅, 다음 미팅 때까지 할 것, 전달사항 공유
- 6하 원칙으로 정리하여 질문
- 진행사항 완료했으면 회의시간에 알려주고, 나머지 사람들은 그 다음 회의시간까지 코드리뷰해주기
짧고 빠른 피드백 덕분에
모호했던 논의가 명확해지고, 막힘 없이 작업이 이어졌다.
2️⃣ Issue & Milestone으로 협업의 가시화 만들기
- 할 일은 Issue로 세분화
- Issue 데드라인은 2일
- 완료했다면, comment를 통해 작업 스케줄, 작업 내역을 공유하기
- 2차 프로젝트 기준으로 Milestone 설정
일이 ‘보이기 시작하니까’
서로의 흐름을 이해하며 더 자연스럽게 협업할 수 있었다.
3️⃣ PR 기반 Code Review 문화 만들기
책의 핵심 메시지 중 하나는 이것이었다.
“사람을 변화시키는 것은 꾸준한 피드백이다.”
그래서 우리는 PR을 중심으로
서로의 코드에 질문하고, 제안하고, 실수도 잡아냈다.
- 질문하기
- not equal이 무슨 역할을 하는 메소드인가요?
- 이게 무슨 로직인지 설명해주실 수 있을까요?
- 제안하기
- 이 메소드는 부분집합도 만들고, 합도 구하고, 소수 판별도 하고, answer 카운트도 하네요. 한 메소드가 4가지일을 하고 있습니다. 한 번에 하나씩만 하도록 수정할 수 있을까요?
- 실수 고쳐주기
- 질문하기 하면, 자연스럽게 실수 발견하게 된다.
- 여기에서만 break문을 사용하고 아래에서는 return 문을 사용한 특별한 이유가 있을까요? → 실수 발견
- 코드 리뷰하는 사람은 이슈 1개당 2명으로 두기
- Merge 할 사람, Merge 기준 정하기
처음엔 어색했지만,
나중에는 서로의 코드를 더 신뢰하게 되었다.
4️⃣ Issue Tracker
Github Project Board가 있는데 4명에서 Jira와 같은 Issue Tracker가 필요한 것인가?
- Issue Tracker를 쓰면 소요시간 체크, Gant, Agile 보드가 있어서 스프린트 하기 쉽다.
- Jira : small to large SaaS enterprises / Github: small software development teams
- → 우리 프로젝트 내에서 Github Project Board로 충분하다고 결정했다.
5️⃣ 컨벤션 통일 — 팀의 언어 하나로 맞추기
- PEP8 기반 Python 스타일 가이드
- RESTful API Convention 점검 및 리뷰
- URI 규칙 통일
- Wiki & README 문서화
문서가 쌓일수록
팀 전체의 언어가 하나로 통일되며 개발 속도도 빨라졌다.
6️⃣ 역할
프로젝트 초반에는 역할을 나누기보다,
팀 전체가 하나의 목표를 향해 같은 속도로 나아가는 것을 더 중요하게 두었다.
그래서 우리는 “전원이 함께 참여하는 역할 구조”를 만들었다.
- 개발에 집중
- Code Review를 팀 전체가 적극 참여
- Github Readme / Wiki 문서화
- Issue 생성 및 할당
- 아이디어 제안 & 와이어프레임 제작
- 프로젝트 방향성 논의
- 스크럼 운영 (회의 주제 만들기 포함)
특히 강조했던 부분은 이것이다.
“회의 전에 프로젝트 전체 방향을 생각해보기”
“PM 역할을 모두가 다같이 하기”
이 방식 덕분에 팀 전체가 프로젝트의 ‘전체 그림’을 자연스럽게 공유할 수 있었다.
7️⃣ Github Flow
협업의 기본 틀은 Github Flow로 맞추고,
브랜치 전략을 명확하게 문서화했다.
- master
- test_box에서 충분히 검증된 기능만 병합
- test_box
- 각자 작업 브랜치에서 유의미한 진전이 있을 때 병합
- 개별 작업 브랜치
- LHS, LJK, LYS, KHY 등 개인 브랜치에서 개발 진행
그리고 보안·안정성을 위해 다음을 엄격히 지켰다.
- 공개되면 안 되는 파일은 절대 Repo에 올리지 않기
- .gitignore 적극 활용
- 메인 브랜치 이름 통일
이 구조 덕분에 작업 흐름이 훨씬 명확해지고, 충돌도 줄어들었다.
8️⃣ Code (보안 & 설정)
코드 수준에서도 기본적인 보안과 설정을 강화했다.
- 데이터베이스 접근 시 인증 기능 추가
- 환경 변수/설정값 조사 및 방식 선정 후 적용
작은 프로젝트라도 보안을 신경 쓰는 습관은
팀 전체의 코드 퀄리티를 안정적으로 끌어올렸다.
9️⃣ API 점검
API 품질을 높이기 위해 도구를 적극 활용했다.
- POSTMAN으로 API 호출 시간 확인 및 요청 테스트
- 테스트 코드 작성(Rests Docs 활용)
- → API 문서 자동화 & 실제 요청 흐름 검증
덕분에 서버 로직을 건드릴 때마다
문서가 자동으로 갱신되고, 기능이 의도대로 작동하는지 빠르게 확인할 수 있었다.
🔟 한 스프린트가 끝날 때마다, 주기적인 회고를 통하여 프로젝트의 방향을 잡기
스프린트가 끝날 때마다 팀 전체가 모여
짧고 명확한 KPT 회고를 진행했다.
- Keep: 유지할 것
- Problem: 개선할 점
- Try: 다음에 시도할 것
이 회고는 단순한 회상 시간이 아니라,
팀의 방향을 다시 잡아주는 중요한 시간이었다.
다음 스프린트에서 무엇을 개선해야 하는지,
무엇을 유지해야 하는지가 명확해졌다.
협업은 일을 나누는 것이 아니라 “같은 목적지로 걷는 것”
팀 프로젝트의 마지막 발표 때, 많이 성장한 팀이라고 피드백을 받았다.
모두가 스프링을 처음 배우는 상태였는데도
각자의 작업에 몰입하고, 배운 것을 나누고,
같이 성장하기 위해 움직이다 보니
모든 팀원이 백엔드 기능을 골고루 맡아 수행할 수 있었다.
협업은 단순히 역할을 나누는 것이 아니라
같은 방향을 바라보며 함께 걸어가는 일이라는 것
임을 확신하게 되었다.
마무리 - 함께 자라는 개발자로 남고 싶다
《함께 자라기》는 내게
“혼자 잘하는 개발자보다, 함께 잘하는 개발자가 되고 싶다”는 발돋움을 해주는 책이었다.
실제 프로젝트에서
협업 방법을 연구하고, 도입하고, 개선해가는 과정은
정말 뿌듯한 경험이었다.
앞으로도 나는
더 좋은 협업, 더 건강한 팀, 더 빠른 피드백을 고민하며
계속해서 “함께 자라는 개발자”로 성장하고 싶다.
'Book Review' 카테고리의 다른 글
| 나를 알고 싶을 때 뇌과학을 공부합니다 (질 볼트 테일러) (0) | 2022.07.02 |
|---|