이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 새 기능 기획서를 처음 작성하는 역할을 맡았는데, 요건을 정리해서 개발팀에 전달했더니 '이 경우엔 어떻게 해요?'라는 질문이 10개 이상 왔습니다. 예외 케이스를 생각하지 않고 정상 흐름만 적었던 게 문제였습니다. 그 이후엔 요건 문서에 정상 흐름 외에 에러 케이스와 예외 처리 정책을 기본 항목으로 넣었습니다. 다음 기획서부터 질문이 3개 이하로 줄었습니다.
요건 정의는 정상 케이스보다 예외가 더 많은 지면이 필요하다는 걸 그때 배웠습니다. 요건 정의는 정상보다 예외가 더 많은 지면을 써야 한다는 걸 배웠고, 지금도 기획서에 예외 케이스를 먼저 채웁니다.
사이드 프로젝트에서 서비스를 배포한 뒤 데이터 처리 오류가 반복됐습니다. 알고 보니 기획 단계에서 동시 요청이 오면 어떻게 처리할지 정의를 안 했던 게 원인이었습니다. 그때 운영 정책이 기획에서 빠지면 배포 이후에 고쳐야 한다는 걸 처음 실감했습니다. 이후 프로젝트에서는 동시성, 오류 복구, 재시도 정책을 기획 단계에서 기본 항목으로 포함했습니다. 기획서에 운영 정책이 빠지면 결국 개발자나 운영자가 임기응변으로 채우게 된다는 걸 배웠습니다.
운영 정책이 기획에서 빠지면 배포 후 임기응변이 생긴다는 걸 배웠고, 이후에도 운영 정책을 기획 단계에 포함합니다. 기획과 운영의 경계가 명확할수록 팀 전체가 편해집니다.
인턴 때 기획서를 개발팀과 운영팀 모두에게 공유했는데, 개발팀은 기술 스펙을, 운영팀은 처리 흐름을 보고 싶어 한다는 걸 알게 됐습니다. 처음엔 하나로 다 쓰려다 둘 다 알아보기 어렵다는 피드백을 받았습니다. 요건 정의 섹션과 운영 정책 섹션을 분리하고, 각 섹션이 누구를 위한 것인지 명시했습니다.
이후 개발팀 검토 시간이 짧아지고, 운영팀에서도 예외 케이스를 먼저 확인하게 됐습니다. 기획서는 독자가 여럿이면 섹션을 나눠야 한다는 걸 그때 배웠습니다. 기획서는 독자가 여럿이면 섹션을 나눠야 한다는 걸 배웠고, 이후에도 독자를 먼저 정하고 씁니다. 독자를 먼저 생각하는 습관이 기획력의 기반입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 카카오 서비스기획 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.