프론트엔드·백엔드 협업 매너와 API 인터페이스 먼저 맞추기

협업할 때 지켜야 할 비즈니스 매너

아는 척하지 않기

서로 아는 도메인이 다를 때 가장 조심해야 하는 부분이다. "내가 아는 백엔드는~"으로 시작하는 말은 상대에게 큰 반감을 산다.

상대방의 말을 먼저 들어주고, 내가 명확하게 다르게 알고 있는 부분이 있다면 이렇게 말한다.

"제가 알기로는 ~인데, 혹시 틀리거나 더 나은 방법이 있다면 제안 주시면 감사하겠습니다."

양쪽 모두 이제 막 배우기 시작한 경우가 많다. 서로 모르는 게 당연하다는 전제로 도와가며 진행하는 분위기를 만드는 것이 가장 중요하다.

당연하게 요구하지 않기

페이지네이션이 필요한데 백엔드가 전체 데이터를 내려주고 프론트에서 전처리하라고 하는 상황을 가정해 보자.

"누가 이렇게 줘요, 프론트 로딩 과부하 걸려요. 페이지네이션으로 주세요."
"제가 알기로는 페이지네이션으로 주는 게 어렵지 않은 걸로 아는데, 페이지네이션으로 주세요. 프론트는 무한 스크롤 다 만들어 놨어요."

두 방식 모두 상대를 누르고 무시하는 말투다. 내 판단이 맞더라도 먼저 상대의 의견을 묻고, 수정하기 쉬운 구조인지, 수정에 얼마나 걸릴지를 유연하게 이야기하는 편이 낫다.

짜증 내지 않기

같은 내용이라도 전달 방식에 따라 다르게 들린다.

던지기: 스크린샷 한 장과 함께 "민수님 이거 500 에러나요."
떠넘기기: "에러 메시지 봐도 모르겠고 Postman으로 해도 똑같아요, 어떡해요?"
분노: "에러납니다. 저 이거 때문에 시간만 날렸고 오늘까지 끝내야 하니 빨리 해결해 주세요."

결국 얼굴을 보고도 할 수 있는 말로 소통하는 것이 가장 중요하다. 일정이 밀리고 바빠지면 예민해지기 쉬우니, 나도 상대도 그렇게 되지 않도록 서로 조심한다.

API를 기다리지 말고 인터페이스를 먼저 맞추기

기획 → 디자인 ──────────────→ 디자인 끝 → 퍼블리싱(API 연동) ──→
     → 백엔드(DB 설계, API 설계) ──→ 백엔드(실제 구축) → 배포 → 수정 →

API가 완성될 때까지 기다리지 말고, DB 설계가 끝난 시점에 프론트 리드와 백엔드 리드가 응답 형태(타입) 를 먼저 맞춘다.

엔티티(예: Book)의 필드와 타입
공통 응답 구조(data, message, status 등)
목록 API의 페이지네이션 여부와 구조
에러 응답 형식

예를 들어 Book이 title: string, price: number를 가지고 공통 응답이 data, message, status로 구성된다고 합의했다면, 프론트는 타입과 fetch 함수를 미리 만들어 둘 수 있다.

type Book = {
  title: string;
  price: number;
};

type DefaultResponse<T> = {
  data: T;
  message: string;
  status: number;
};

const getBookList = async () => {
  const { data } = await axios.get<DefaultResponse<Book[]>>('/api/books');
  return data;
};

여기에 MSW를 도입해 실제 요청을 보내는 것처럼 개발하면, 백엔드가 배포된 뒤 MSW만 끄고 바로 통합 테스트 단계로 넘어갈 수 있다. 백엔드 작업을 기다리는 시간을 최대한 줄이는 방법이다.