2장. 협업이 반이다
신입 시절, 주변에는 코드를 잘 짜는 것이 개발자의 가장 중요한 덕목이며, 곧 일을 잘하는 것이라고 믿는 사람들이 많았다.
누구보다 빠르게, 누구보다 깔끔하게 코드를 완성하면 그것이 최고의 개발자라고 생각하는 친구들이었다.
하지만 회사 프로젝트는 달랐다.
한 사람이 혼자 만든 멋진 코드가, 팀 전체의 일정에는 오히려 방해가 되기도 했다.
모듈 간 충돌, 문서화 누락, 리뷰 없이 배포된 기능이 만든 장애… 이런 일들은 개인의 역량만으로는 감당되지 않았다.
그때 우리는 깨닫게 된다.
개발은 개인 경기장이 아니라, 팀이 함께 달리는 릴레이라는 것을.
내가 만든 바통이 다음 사람에게 부드럽게 이어지지 않으면, 팀 전체가 넘어지거나 늦어진다.
협업에서 가장 중요한 건 정보를 숨기지 않는 것이다.
신입일수록 ‘이 정도는 혼자 해결할 수 있겠지’라며 작은 문제를 묻어두곤 한다.
하지만 그 문제는 시간이 지날수록 커져서, 결국 팀 전체가 막히는 원인이 된다.
정보를 공유한다는 건 약함을 드러내는 것이 아니다.
오히려 문제를 조기에 발견하고, 더 나은 방향을 찾을 기회를 만드는 일이다.
작업 시작 전 → 무엇을, 언제까지 할지 간단히 공유한다.
작업 중간 → 지금 어디까지 왔고, 막힌 부분은 없는지 알려준다.
작업 후 → 어떤 코드가 바뀌었는지, 어디에 영향이 있는지 문서화한다.
이런 습관이 자리 잡히면 동료들은 당신을
“일을 맡기면 예측 가능한 결과를 주는 사람”
이라고 믿게 된다. 그 신뢰가 결국 기회를 넓힌다.
처음 코드 리뷰를 받으면 마치 시험지를 채점받는 기분이 든다.
변수명 하나, 들여쓰기 하나까지 지적을 받으면 괜히 작아지기도 한다.
하지만 곧 알게 된다.
리뷰는 평가가 아니라, 품질을 함께 높이는 과정이라는 것을.
리뷰에서 나온 피드백은 단지 이번 코드에만 적용되는 게 아니다.
다음 작업, 그다음 작업에도 영향을 준다.
즉, 리뷰를 많이 받을수록 성장 속도는 빠르다.
코드의 의도를 먼저 설명한다.
열린 마음으로 질문과 제안을 받아들인다.
반박이 필요하다면 근거를 명확히 말한다.
리뷰어가 보기 편하도록 커밋을 작게 나눈다.
협업은 개발자끼리만 하는 게 아니다.
기획자, 디자이너, 운영팀, 심사팀… 모두 다른 언어를 쓴다.
기획자는 ‘사용자 경험’을, 디자이너는 ‘화면 흐름’을, 운영팀은 ‘업무 효율’을 우선한다.
신입일수록 이런 차이를 간과하기 쉽다.
“기획서에 다 있는데 왜 또 물어보지?”
“저 요구사항은 말도 안 되는데?”
하지만 그럴 때일수록 중요한 건, 상대방의 언어로 말하는 것이다.
예를 들어 “이 API는 200ms 걸립니다” 대신
“이 API 때문에 결제 화면에서 사용자 대기 시간이 0.2초 늘어납니다”라고 말하면 훨씬 쉽게 이해된다.
협업에서 갈등은 필연적이다.
문제는 갈등 자체가 아니라, 그걸 어떻게 다루느냐이다.
신입일수록 갈등이 생기면 말을 아끼고 피하려 한다.
하지만 대부분의 경우, 문제는 사라지지 않고 커진다.
가장 좋은 방법은 사실(Fact)과 감정(Feeling)을 분리하는 것이다.
“이 코드 구조가 유지보수에 어려움을 줄 것 같습니다”
는 괜찮지만,
“당신 코드가 문제입니다”
라고 하면 대화는 바로 막힌다.
결국 협업은 신뢰의 문제다.
사람들은 잘하는 사람보다 믿을 수 있는 사람과 일하고 싶어 한다.
신입 개발자가 신뢰를 얻는 방법은 단순하다.
약속한 기한을 지킨다.
모르면 빨리 묻는다.
문제를 숨기지 않는다.
동료의 시간을 존중한다.
이 4가지만 지켜도, 팀은 당신을 ‘같이 일하고 싶은 사람’으로 기억한다.
개발자로서 성장하려면 협업은 피해 갈 수 없는 과정이다.
혼자 잘하는 것만으로는 부족하다.
팀 속에서 함께 잘하는 법을 배울 때, 비로소 커리어가 단단해진다.