저는 스스로를 프로 찍먹러라고 생각합니다.
SwiftUI로 앱 프로젝트 경험, Spring Boot 서버 개발 경험도 있고, React로 웹 개발도 경험했습니다.
이런 여러 경험에서 가장 크게 배운 건 기술 자체보다 바로 협업이었습니다. 서로 역할도 다르고, 관점도 다르기 때문이죠. 그래서 협업은 늘 삐걱거릴 수밖에 없습니다.
제가 세 분야를 찍먹한 경험은 협업이 왜 어려운지, 어떻게 풀어나가야 하는지를 몸으로 느끼게 해주었습니다. 이제 그 경험을 토대로 제가 겪은 협업의 A to Z를 이야기해 보려 합니다.
협업의 시작
프로젝트의 시작은 뭘까요?
일상에서 불편함을 느끼고 그에 따라 이런 서비스가 있으면 어떨까?라는 생각에서 시작됩니다.
하지만 진짜 프로젝트의 시작은 아이디어 그 자체가 아닙니다.
그 아이디어의 배경과 맥락을 이해하고 PM의 요구사항을 정확히 인지하는 순간부터 프로젝트는 굴러가기 시작합니다.
예를 들어 어떤 프론트엔드 엔지니어는 화려한 인터랙션을 좋아한다고 해봅시다. 하지만 이번 프로젝트의 방향이 가볍고 심플한 사용자 경험이라면? 본인의 기본값을 내려놓고 우선순위를 수정할 수 있어야 합니다.
디자이너도 마찬가지죠. 평소 자신만의 스타일이나 도전해보고 싶은 디자인이 있다고 하더라도 PM이 정한 서비스의 방향과 다르다면 맞춰가는 과정이 필요합니다.
반대로 PM도 개발자와 디자이너에게 현실적으로 불가능한 요구를 계속한다면? 문제가 생기겠죠.
결국 협업의 시작은 PM의 요구사항과 팀원의 기본 성향 사이에서 균형을 맞추는 일입니다.
이 출발선에서 조율이 이루어지지 않으면 겉으론 같은 목표를 향하는 것 같아도 실제로는 각자 다른 꿈을 꾸게 됩니다. 이게 바로 협업이 처음부터 어긋나는 지점입니다.
저 역시 여러 분야를 겪어오며 뼈저리게 느낀 건 협업은 저절로 되지 않는다는 겁니다.
내 파트만 잘 하면 되겠지?라고 다들 생각합니다. 물론 내 파트만 잘하면 프로젝트가 굴러가죠. 하지만 의도적으로 구조를 만들고 도구를 활용하고 같은 언어로 맞춰가는 과정을 거쳐야만 비로소 함께하는 개발이 됩니다.
서로의 언어를 번역하기
협업은 서로 다른 세계의 언어를 번역하는 일이다.
프론트엔드, 백엔드, 모바일은 같은 서비스를 만들지만 서로 다른 세계에 살고 있습니다. 사용하는 언어도, 익숙한 코드 구조도, 문제를 바라보는 관점도 전부 다릅니다.
예를 들어, 로그인 API를 두고 대화한다고 가정해 봅시다.
- 프론트엔드는 "응답 속도가 조금만 느려져도 UX가 망가져요. 로딩 스피너 대신 즉각적인 피드백이 필요합니다."라고 합니다.
- 백엔드는 "속도보다 중요한 건 안정성이에요. 토큰을 안전하게 검증하지 않으면 보안 구멍이 생깁니다."라고 대답하죠.
- 모바일은 또 이렇게 말합니다. "네트워크가 끊겼다가 다시 연결되면 토큰을 갱신해야 해요. 앱스토어 심사도 이런 부분을 민감하게 봅니다."
이 대화에서는 같은 API에 대해 이야기하고 있지만 서로 전혀 다른 차원의 대화를 하고 있습니다.
CORS 에러와 Proxy, 언어의 불일치
실제로 프론트와 백엔드 협업에서 흔히 겪는 게 바로 CORS 에러입니다.
프론트는 “API가 안 불러와져요!”라고 외치고, 백엔드는 “서버는 멀쩡하게 돌아가는데요?”라고 답합니다.
이 오류를 해결하기 위해서는 서버에서 Access-Control-Allow-Origin 등의 헤더를 설정하여 특정 출처의 요청을 허용하거나 프록시 서버를 사용해 요청을 같은 출처로 보이게 하는 방법이 있습니다.
중요한 건 서로의 언어 차이를 메워주는 다리 역할입니다. 이걸 단순히 “프론트 잘못” 혹은 “백엔드 잘못”으로 치부하지 않는 거죠. 프론트에게는 CORS는 보안 정책이라 그렇다고 설명해 주고, 백엔드에게는 프론트 로컬 환경에선 이렇게 proxy로 해결할 수 있다고 알려주는 사람이 필요합니다.
협업이란 내 관점만 고집하는 것이 아니라 상대의 말을 그들의 맥락에서 다시 풀어내어 번역하는 과정입니다. 이 과정이 원활할수록 팀은 더 빠르게, 그리고 더 유기적으로 움직일 수 있습니다.
소통하기
“안 된다”에서 끝내지 말고, “왜, 어떻게”까지 설명하라.
한 번은 백엔드에서 API 응답 구조를 바꾼 적이 있습니다. 프론트 팀은 갑자기 깨지는 화면을 보고 당황했죠. 그때 했던 설명은 이거였습니다. “DB 구조가 바뀌어서요.”
맞는 말이긴 하지만 이 정도로는 팀원들이 납득하기 어렵습니다. 아래처럼 말했다면 더 좋았을 텐데 말이죠.
- 왜 바꿨는지: 기존 구조에 보안 취약점이 있었기 때문에.
- 어떻게 대응하면 되는지: 응답 JSON 한 줄만 수정하면 됩니다.
이 두 줄이 들어가면 대화는 불필요한 갈등 대신 신뢰로 바뀝니다.
이외에도 프로젝트에서 소통의 문제를 겪었던 순간들이 있습니다.
첫 번째는 백엔드 측에서 API 명세서를 언제까지 전달해줄 지 연락이 없어 프론트 입장에서는 데이터 구조를 전혀 알 수 없었고 화면은 만들었다고 해도 데이터 흐름을 생각하며 작업할 수 없었습니다.
두 번째는 백엔드 측에서 무중단 배포를 하지 않고 중간에 서버를 수정하는 바람에 프론트 팀이 모여 함께 작업하기로 한 날 정작 서버가 닫혀 아무 작업도 하지 못했던 경험도 있습니다.
PM이 필요한 데이터 시트를 제 때 넘겨주지 않아 여러번 수정 작업을 해야 했던 적도 있습니다.
이런 일은 결국 소통의 부재에서 시작됩니다. 언제까지 API 명세서가 나올거다, 이 시간에는 서버 수정 때문에 서버가 닫힐 수 있다 같은 기본적인 정보가 공유되지 않으면 팀 전체 일정이 뒤틀리고 불필요한 대기 시간이 생길 수 있습니다.
그래서 저희는 WBS로 작업 단위를 나누고 마감 시점을 명확히 공유하는 것이 꼭 필요하다고 생각합니다. 이건 프론트와 서버의 작업 기간 차이가 있기 때문이기도 하죠. 또, 작은 변경 사항이라도 실시간으로 공유하고 소통하는 것도 중요합니다.
이걸 위해 협업 도구 몇 가지를 간단하게 소개해보겠습니다.
협업 도구
개발팀의 커뮤니케이션은 단순히 입으로 하는 대화로 끝나지 않습니다. 도구가 뒷받침돼야 대화가 사라지지 않고 쌓입니다.
- 노션: 회의록, 기획안, 문서, 링크를 한곳에 정리하는 용도로 사용합니다.
- 지라: 태스크 관리나 스프린트 진행 상황 공유를 위해 사용합니다.
- 슬랙 / 디스코드: 빠른 피드백과 실시간 소통, 주간 회의를 위해 사용합니다.
중요한 건 “어디에 무엇을 남길지”를 팀원 모두가 아는 것입니다. 이슈는 지라에, 회의 결과는 노션에, 긴급 알림은 슬랙에. 흩어지지 않고 한눈에 찾아볼 수 있어야 대화가 진짜 힘을 가집니다.
협업에서 커뮤니케이션은 결국 맥락을 잃지 않는 것입니다. 왜 이 결정을 했는가, 어떤 대안이 있었는가, 지금 어디까지 와 있는가. 이 맥락이 대화와 툴을 통해 이어질 때 비로소 팀은 같은 방향을 보고 달릴 수 있습니다.
기록하기
기록 없는 협업은 기억과 추측에 의존한다. 그리고 기억과 추측은 언제든 배신한다.
제가 여러 프로젝트를 하면서 공통적으로 가장 크게 부딪힌 문제는 문서화 부족이었습니다.
API 명세서 내용이 부족해 길을 돌아가기도 하고, 기능 플로우를 화면 설계서 없이 진행하다가 완성된 화면이 PM이 의도했던 것과 다르게 나오기도 하고, 깃허브 이슈와 PR에 설명이 없어 리뷰 과정에서 괜한 시간을 소모하기도 했습니다.
이러면 결국 팀은 누가 잘못했는지를 따지느라 시간을 낭비하게 됩니다.
API 명세서와 Swagger
API는 협업의 혈관과 같습니다. 여기서 오해가 생기면 전체가 꼬입니다.
“status는 int인가요? string인가요?”, “이 필드는 nullable인가요?”
이런 질문이 오가는 순간 이미 협업은 지체되고 있습니다.
- API 명세서와 Swagger: 어떤 URL이 있고 어떤 파라미터가 필요한지, 어떤 응답이 오는지 프론트는 문서를 통해 직접 호출해볼 수 있습니다.
- 화면설계서: 어떤 버튼을 누르면 어떤 플로우로 이동하는지, 디테일을 말로만 합의하는 건 위험합니다. Figma, Zeplin 같은 툴을 활용해 버튼 위치, 화면 전환, 에러 메시지까지 문서로 정리해 두어야 합니다.
API 명세서와 화면 설계서는 우리가 같은 것을 보고 있다는 증거입니다.
여기서 잊지 말아야 할 건 이 문서들이 프로젝트 내내 최신 상태로 유지되어야 한다는 것입니다.
요구사항이 바뀌면 API 스펙도 달라지고 디자인 수정이 들어가면 화면 플로우도 변합니다. 이와 동시에 문서가 제때 갱신되지 않으면 팀은 서로 다른 것을 보게 되고 이는 불필요한 충돌과 재작업으로 이어지게 됩니다.
GitHub
코드 협업에서 GitHub는 단순 저장소가 아니라 협업의 기록을 남기는 공간입니다.
- Issue: 기능 추가, 버그 수정, 리팩토링 등 할 일을 명확히 구분해 기록해야 합니다. 왜 이 작업을 했는지의 흔적이 남습니다.
- PR: 작은 단위로 리뷰 가능한 코드만 올려야 합니다. 예를 들어 버튼 색상 바꾸기와 DB 마이그레이션이 같은 PR에 들어가면 리뷰가 어려워지고 협업 효율이 떨어집니다.
- 컨벤션: 커밋 메시지, 브랜치 네이밍, PR 템플릿을 팀 공통 언어로 삼아야 합니다. feat/login-api, fix/button-color, refactor/user-service처럼 이름만 봐도 무슨 작업인지 알 수 있도록 약속해야 합니다.
이런 규칙이 없다면 결국 이 커밋은 뭐지?하며 히스토리 속에서 길을 잃게 됩니다.
협업은 코드가 아니라 맥락이 담긴 기록을 리뷰하는 일입니다.
큰 그림 보기
협업의 마지막은 내 코드가 아니라 우리의 서비스를 보는 것이다.
협업이 꼬이는 이유 중 하나는 각자 자기 파트만 보고 끝내버리기 때문입니다.
프론트는 화면이 잘나오면 그만, 백엔드는 API 응답이 잘 나가니 그만. 이렇게 각자 할 일만 끝내면 서비스는 돌아가긴 합니다. 하지만 사용자 경험은 어긋날 수 있습니다.
QA
여기서 중요한 게 바로 QA입니다.
QA는 단순히 버그를 찾는 단계가 아닙니다.
- 로그인 버튼이 실제로 눌리는지(기능 테스트)
- 여러 브라우저와 기기에서 일관되게 동작하는지(호환성 테스트)
- 서버 부하에도 안정적으로 돌아가는지(성능 테스트)
- 화면 설계서와 API 명세서가 일치하는지(요구사항 검증)
이 모든 과정이 결국 줌아웃된 관점에서 서비스 품질을 담보하는 일입니다.
프론트, 백엔드, 모바일이 각각 QA를 하고 마지막에는 통합 QA를 통해 우리 서비스가 진짜로 잘 굴러가는지를 확인해야 합니다.
줌아웃은 사용자 경험이라는 큰 그림을 함께 보는 태도고 QA는 그 큰 그림이 흔들림 없이 구현됐는지 검증하는 안전망입니다. 줌아웃이 방향을 잡아주고 QA가 그 방향이 올바르게 구현됐는지 확인하는 것. 이 두 가지가 맞물려야 협업은 비로소 완성됩니다.
지금 협업을 시작하려는 사람에게는 “작은 것부터 맞추세요”, 이미 협업을 경험한 사람에게는 “상대의 세계를 이해해 보세요”라는 말을 남기고 싶습니다.
여기까지가 제가 A부터 Z까지 삽질하며 얻은 하나의 방법이었습니다.
