예시 답변 1
역할 분리를 처음 경험한 프로젝트
이전에는 프론트와 백엔드 코드를 한 프로젝트에서 섞어 개발했는데, 팀 프로젝트에서 처음으로 서버는 API만 제공하고 클라이언트가 화면을 따로 그리는 구조로 분리해봤습니다. 분리하고 나니 프론트와 백엔드를 다른 팀원이 동시에 개발할 수 있어 좋았지만, 초반에는 API 응답 형식을 맞추는 데 소통 비용이 들었습니다.
분리 구조의 장점과 소통 비용이라는 현실적 어려움을 함께 담았습니다.
면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
이전에는 프론트와 백엔드 코드를 한 프로젝트에서 섞어 개발했는데, 팀 프로젝트에서 처음으로 서버는 API만 제공하고 클라이언트가 화면을 따로 그리는 구조로 분리해봤습니다. 분리하고 나니 프론트와 백엔드를 다른 팀원이 동시에 개발할 수 있어 좋았지만, 초반에는 API 응답 형식을 맞추는 데 소통 비용이 들었습니다.
REST API를 개발할 때 처음엔 화면에 필요한 데이터를 그때그때 맞춰 API를 만들다 보니, 비슷한 API가 여러 개 생기는 문제가 있었습니다. 리소스 단위로 API를 다시 설계하고 나서야 중복이 줄었습니다. 처음부터 리소스 단위로 생각하지 못했던 게 아쉬웠습니다.
클라이언트와 서버를 분리하면 서버 로직을 몰라도 프론트 개발이 가능하다는 걸 이론으로는 알았지만, 실제로 팀 프로젝트에서 서버가 아직 완성되지 않았을 때 가짜 응답 데이터로 화면 작업을 먼저 진행해보고 나서야 그 의미를 체감했습니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.