백엔드, 실무에서는 어떻게 어떻게 협업할까?

백엔드 개발자로 실무를 진행하다 보면, 연차가 쌓일수록 코드를 짜는 시간보다 '맥락을 파악하고 소통하는 시간'이 기하급수적으로 늘어난다는 것을 체감하게 됩니다.
서비스 규모가 커지고 팀원이 늘어나면, 어제 결정된 사항이 오늘 번복되거나 기획의 의도가 개발 단계에서 왜곡되는 일이 빈번해지죠.

결국 실무 협업은 단순히 "협업을 잘하자"라는 구호나 잦은 회의만으로 해결되지 않습니다. 서로 다른 직군이 하나의 목표를 향해 얼마나 유기적이고 효율적인 구조로 움직이느냐의 싸움입니다.

특히 서비스가 커짐에 따라 문서 정리를 어떻게 진행하느냐에 따라 업무 효율은 적게는 수배, 많게는 수십 배까지 차이 나게 됩니다.

오늘은 제가 실무에서 겪으며 다듬어온, 기획자·디자이너·프론트엔드·백엔드가 유기적으로 움직일 수 있는 효율적인 업무 프로세스와 문서화 시스템을 소개합니다.

1. 커뮤니케이션의 나침반: PM/PO의 PRD

모든 프로젝트의 출발점은 PM(프로덕트 매니저) 혹은 PO(프로덕트 오너)가 작성하는 PRD(Product Requirements Document)입니다.

PRD란 무엇인가?

쉽게 말해 '무엇을, 왜 만드는가'를 정의하는 문서입니다. 이 문서는 나중에 기능이 배포된 후, "이 기능이 왜 만들어졌고 당시 어떤 배경이 있었는가"를 설명하는 핵심 히스토리가 됩니다.

• 작성 주체: PM 또는 PO

• 주요 내용:

  1. 목표: 기능을 통해 해결하려는 비즈니스 목표와 문제 정의

  2. 사용자 스토리: 어떤 사용자가 어떤 상황에서 이 기능을 사용하는지 기술

  3. 기능 요구사항: 구체적으로 구현되어야 할 기능 리스트

  4. 성공 지표(KPI): 출시 후 성과를 판단할 기준

[가상의 PRD 예시: 포인트 적립 및 소진 시스템]

목표: 유저의 재방문율을 높이기 위해 구매 시 포인트 적립 및 결제 시 소진 기능 도입

사용자 스토리: "사용자는 상품 구매 시 결제 금액의 1%를 적립 받고, 
			다음 구매 시 100원 단위로 포인트를 사용할 수 있어야 한다."

성공 지표: 포인트 도입 후 30일 이내 재구매율 15% 상승

2. 사용자 경험의 설계도: 디자이너의 UXDR

기획이 텍스트의 영역이라면, 이를 유저의 눈앞에 구현하는 설계도는 디자이너의 UXDR(UX Design Review)입니다.

UXDR이란 무엇인가?

PRD를 바탕으로 설계된 UX/UI 디자인이 사용자 경험 측면에서 적절한지 검토하고 기록하는 문서입니다. 디자인은 단순히 예쁜 화면을 만드는 것이 아니라 '논리'를 만드는 과정입니다.

• 작성 주체: UX/UI 디자이너

• 백엔드 개발자가 주목할 점:

  1. User Flow: 사용자가 목표를 달성하기 위해 거치는 경로

  2. 와이어프레임: 실제 화면 설계안 및 데이터 노출 방식

  3. 피드백 기록: 개발팀과 논의하며 수정된 제약 사항들

[가상의 UXDR 예시: 포인트 상세 내역 화면]

동선: 마이페이지 → 포인트 잔액 클릭 → 포인트 적립/소진 상세 리스트 노출

결정 근거: 무한 스크롤 방식을 채택하여 유저가 과거 내역을 끊김 없이 탐색할 수 있도록 설계

개발 협의사항: 포인트 소진 시 실시간 잔액 반영 UI 처리를 위해 소켓 혹은 롱폴링 방식 검토 필요

3. 기술적 의사결정의 기록: FE/BE의 ADR

백엔드 개발자에게 가장 중요한 문서를 하나 꼽으라면 단연 ADR(Architecture Decision Record)입니다.

PRD와 더불어 가장 핵심이 되는 문서입니다.

ADR이란 무엇인가?

소프트웨어를 개발할 때 내린 중요한 기술적 결정과 '그 이유'를 기록한 문서입니다. 코드는 수정하면 그만이지만, "왜 그때 이 라이브러리를 썼는지", "왜 이런 DB 구조를 선택했는지"는 기록하지 않으면 금방 잊힙니다.

• 작성 주체: 소프트웨어 아키텍트 또는 개발팀(FE/BE)

• 문서의 효과:

  1. 시간이 흐른 뒤에도 당시의 기술적 맥락을 파악 가능

  2. 새로운 팀원이 합류했을 때 프로젝트의 기술 스택을 빠르게 이해

  3. 코드 리뷰 시 "왜 이렇게 짰는지"에 대한 명확한 근거 제시

[가상의 ADR 예시: 포인트 데이터베이스 설계]

맥락: 포인트 적립/소진은 금융 거래와 유사하므로 데이터 무결성이 최우선임

결정: 읽기 성능보다 트랜잭션의 ACID 보장을 위해 RDBMS(PostgreSQL) 사용

결과: 실시간 대용량 트래픽 발생 시 부하가 우려되나, Redis를 활용한 캐싱 전략으로 보완하기로 함

4. 휘발되는 대화를 자산으로: 각종 논의사항 문서

실무에서는 슬랙(Slack) 대화나 복도에서 나눈 대화로 정책이 바뀌는 경우가 많습니다. 하지만 이런 대화는 금방 휘발됩니다.
나중에 "누가 그렇게 하라고 했지?"라는 불필요한 논쟁을 막기 위해 논의사항 문서를 운영해야 합니다.

• 내용: API 필드명 변경, 예외 정책의 수정, 특정 기술적 문제에 대한 해결 방안 조율 등

• 활용: 이 문서들은 후에 PR(Pull Request) 및 코드 리뷰에서 참고 자료로 쓰이며, 구현의 히스토리가 됩니다.

5. 실무 프로세스의 전체 흐름 (Full Cycle)

이 모든 시스템이 어떻게 유기적으로 움직이는지 정리하면 다음과 같습니다.

1. PRD 작성 및 공유: PM이 "무엇을, 왜" 만드는지 정의합니다.

2. UXDR 설계 및 검토: 디자이너가 동선을 그립니다. 백엔드 개발자는 이 단계에서 "이 UI를 그리려면 어떤 API가 필요한가?"를 고민합니다.

3. ADR 및 설계: FE와 BE가 만나 API 명세를 맞추고 아키텍처를 확정합니다. 이 과정에서 기술적 결정 사안이 ADR에 남습니다.

4. 구현 및 Discussion: 코딩 도중 발생하는 변수나 예외 케이스는 논의사항 문서에 업데이트하며 소통합니다.

5. Code Review: 작성된 문서들을 레퍼런스 삼아 코드의 무결성을 검증합니다. "PRD 요구사항에 부합하는가?", "ADR 설계 방향과 일치하는가?"가 기준이 됩니다.

결론: 문서화는 '비용'이 아니라 '저축'입니다.

서비스가 작을 때는 "그냥 말로 하면 되지, 언제 문서를 다 쓰고 있냐"라고 생각하기 쉽습니다. 하지만 서비스가 커지고 시스템이 복잡해지는 속도는 인간의 기억력을 아득히 추월합니다.

잘 정리된 PRD, UXDR, ADR 시스템은 다음과 같은 가치를 만들어냅니다.

• 온보딩 비용 감소: "이 문서들만 정독하세요"로 신규 입사자 교육의 절반이 끝납니다.

• 커뮤니케이션 미스 방지: 모든 팀원이 하나의 문서를 보고 같은 목표를 공유합니다.

• 기술 부채 관리: 과거의 결정 근거를 알기 때문에 리팩토링이나 유지보수가 훨씬 쉬워집니다.

마치며

협업은 단순히 말을 많이 하는 것이 아니라, 누구나 동일한 정보에 접근할 수 있는 시스템을 만드는 것입니다. 서비스가 커질수록 이 문서화 시스템의 차이가 업무 효율의 차이를 만듭니다.
잘 정리된 PRD, UXDR, ADR은 소통 비용을 획기적으로 낮춰주고, 개발자가 오로지 '품질'과 '구현'에만 집중할 수 있는 환경을 만들어 줍니다.

결국 효율적인 협업이란, 코드를 치기 전의 고민을 얼마나 밀도 있게 기록하고 공유하느냐에 달려 있습니다. 여러분의 팀도 오늘부터 작은 ADR 하나부터 시작해 보시는 건 어떨까요?