면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
교내 앱 기획 프로젝트에서 처음 작성한 명세서에 「빠르게 로딩되어야 함」이라는 표현을 썼다가, 개발 담당자에게서 기준이 뭐냐는 질문을 받았습니다.
이후로는 「2초 이내 첫 화면 렌더링」처럼 수치를 명시하는 습관을 들였습니다. 예외 상황(네트워크 지연 시 로딩 화면 노출 기준)까지 함께 적어두니 재확인 질문이 눈에 띄게 줄었습니다.
기획서의 모호함은 결국 개발 단계에서 시간으로 돌아온다는 것을 배웠습니다.
인턴 당시 기능 명세서가 회의 때마다 구두로만 수정돼 버전이 꼬이는 문제를 봤습니다. 저는 문서 상단에 변경 이력 표를 추가해 날짜·변경 내용·사유를 기록하자고 제안했습니다.
작은 습관이었지만, 이후 「이 부분 왜 바뀌었죠」라는 질문에 회의를 다시 소집하지 않고 문서만 봐도 답이 나왔습니다.
기획 문서는 최신 상태만큼 변경 과정을 추적할 수 있는 것도 중요하다고 생각합니다.
동아리 서비스 기획을 하며 같은 기능을 개발팀에는 상세 스펙 문서로, 운영진에게는 한 페이지 요약본으로 나눠 전달한 적이 있습니다.
처음엔 같은 문서를 모두에게 보냈는데, 운영진 회의에서 상세 스펙 때문에 논의가 자꾸 옆길로 샜습니다. 요약본을 따로 만든 뒤로는 운영진 회의는 의사결정에 집중되고, 개발팀은 필요한 상세 정보를 그대로 참조할 수 있었습니다.
문서를 하나로 통일하는 것보다 독자에 맞춰 나누는 것이 더 효율적이라는 것을 배웠습니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.