이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
정식 API 문서 작성 경험은 없지만, 캡스톤 프로젝트에서 팀 내부용 API 명세서를 작성한 경험이 있습니다.
프론트엔드 담당 팀원이 백엔드에서 어떤 응답 형식이 오는지 매번 저에게 물어보는 상황이 반복됐습니다. 제가 간단한 엔드포인트 목록과 요청/응답 예시를 노션에 정리해서 공유했는데, 처음에는 형식이 제각각이어서 팀원이 다시 물어보는 경우가 있었습니다. 형식을 일관되게 맞추지 않은 것이 문제였습니다.
이후 각 엔드포인트마다 요청 파라미터, 응답 필드, 오류 코드를 동일한 양식으로 정리했더니 질문이 크게 줄었습니다. 교수님께도 협업 구조가 잘 짜여져 있다는 피드백을 받았습니다. 문서는 형식의 일관성이 내용만큼 중요하다는 것을 배웠습니다.
API 문서를 처음부터 작성하기보다, 팀에서 사용하던 문서가 오래돼서 실제 코드와 달라진 것을 발견하고 업데이트한 경험이 있습니다.
팀 프로젝트 마지막 학기에 이전 학기 팀이 남긴 엔드포인트 목록을 참고했는데, 파라미터 이름이 실제 코드와 달라서 처음 연결 시도에서 오류가 발생했습니다. 혼자 코드를 직접 읽으면서 실제 동작을 파악하는 데 반나절이 걸렸습니다. 이후 문서를 실제 코드 기준으로 전부 다시 작성하면서 오류 코드 설명도 추가했습니다.
팀원들이 문서를 보고 바로 연결에 성공했고, 저도 뿌듯했지만 처음부터 문서를 코드와 함께 관리했다면 이런 상황이 없었을 것이라는 아쉬움이 남았습니다. 문서는 코드 변경과 함께 관리해야 한다는 것을 그때 배웠습니다.
프로젝트 내부 문서를 팀원이 쉽게 이해할 수 있도록 고쳐 본 경험이 있습니다.
처음 작성한 API 명세서를 팀원에게 보여줬더니 어떤 값을 어디에 넣어야 하는지 모르겠다는 말을 들었습니다. 제가 보기에는 명확했는데, 팀원 입장에서는 파라미터 타입과 필수 여부가 표시되지 않아서 헷갈렸던 것이었습니다. 그 피드백을 받고 각 파라미터에 타입과 필수 여부, 예시 값을 추가했습니다.
그 이후 같은 팀원이 한 번에 연결에 성공했습니다. 문서를 쓸 때 내가 아는 것을 기준으로 쓰면 오히려 독자에게는 불친절할 수 있다는 것을 배웠습니다. 입사 후에도 독자가 모른다고 가정하고 쓰는 방식을 유지하겠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 HD현대에너지솔루션 공통직무·미지정 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.