이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
풀스택 프로젝트에서 백엔드와 프론트엔드를 분리해 개발하면서 협업에서 가장 중요한 것이 API 계약이라는 것을 배웠습니다. 초반에는 백엔드가 응답 구조를 임의로 바꾸면 프론트엔드에서 예상치 못한 오류가 생기는 일이 반복됐습니다. OpenAPI 스펙으로 API를 먼저 정의하고 목 서버를 만들어 프론트엔드가 개발을 병행하도록 한 뒤에는 이 문제가 크게 줄었습니다.
필드명 규칙에 대한 합의도 중요했는데, 카멜케이스와 스네이크케이스를 혼용하다가 파싱 오류가 생긴 경험이 있습니다. 에러 응답 형식의 표준화도 마찬가지로, 프론트엔드가 에러를 어떻게 표시할지 설계하려면 백엔드 에러 구조가 예측 가능한 형태여야 합니다. 한계는 팀 규모가 커질수록 API 스펙 동기화가 더 어려워진다는 점으로, 자동화 도구의 필요성을 느끼고 있습니다. 서버-프론트 협업은 코드보다 계약을 먼저 맞추는 것이 전체 속도를 높이는 결이었습니다.
백엔드와 프론트엔드가 분리된 팀 프로젝트에서 API 문서를 늦게 공유하는 관행이 병목이 됐습니다. 백엔드가 구현을 마치면 그때서야 엔드포인트 목록을 공유하다 보니 프론트엔드는 그 전까지 목 데이터로만 작업했습니다.
이 경험 이후 제가 주도해서 API 설계 단계에서 먼저 스펙 문서를 작성하고, 그 스펙 기준으로 목 서버를 띄우는 방식을 도입했습니다. json-server로 간단한 목 엔드포인트를 올려두니 프론트엔드가 API 완성을 기다리지 않고 화면을 만들 수 있었고, 실제 백엔드가 나왔을 때 연결 작업이 훨씬 짧아졌습니다.
이 경험에서 배운 것은 협업의 핵심이 코드를 잘 짜는 것보다 대기 시간을 줄이는 데 있다는 점입니다. 스펙 합의를 먼저 하면 양쪽이 병렬로 움직일 수 있어 전체 일정이 단축됩니다. 지금도 새 팀에서 백엔드 역할을 맡으면 가장 먼저 API 스펙 초안을 공유하는 것을 원칙으로 삼고 있습니다.
서버-프론트 협업을 여러 번 경험하면서 기술적 합의보다 팀 내 커뮤니케이션 습관이 더 자주 걸림돌이 된다는 것을 느꼈습니다. API 스펙 문서가 있어도 변경 사항을 구두로만 전달하면 상대방이 놓치는 경우가 생겼고, 서로 이미 공유했다고 생각하는 상황에서 문제가 터졌습니다.
제가 아직 부족한 부분은 API 버전 관리입니다. 기존 엔드포인트를 변경할 때 하위 호환성을 유지하면서 새 기능을 추가하는 방법, 그리고 프론트엔드에 변경 알림을 체계적으로 전달하는 프로세스를 실무에서 더 다듬고 싶습니다. 소규모 프로젝트에서는 채팅으로 해결됐지만 팀 규모가 커지면 같은 방식이 통하지 않는다는 것을 알고 있습니다.
협업에서 기술적 합의는 시작점일 뿐이고, 변경이 생겼을 때 양쪽이 놓치지 않고 싱크를 맞추는 프로세스를 갖추는 것이 더 어렵고 중요하다는 생각이 남아 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 라인 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.