이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
학부 시절 알고리즘 수업에서 문제를 작은 단위로 쪼개 풀기 를 반복 훈련했는데, 처음에는 코딩과 기획이 무관하다고 생각했습니다. 그런데 인턴 기간 중 고객 주문 처리 시스템 플로우를 기획할 때, 각 단계의 입력·처리·출력 을 먼저 정의하는 방식이 자연스럽게 나왔습니다.
시스템 플로우 문서 가 명확하다는 개발팀 피드백을 받았고, 팀원들이 이후 다른 기획에도 같은 형식을 썼습니다. 예외 케이스와 엣지 케이스 를 미리 목록으로 만드는 습관도 알고리즘 풀이 연습에서 온 것이라는 걸 나중에 알았습니다. 서로 달라 보이는 경험이 기획 실무에서 연결되는 순간 이 생각보다 자주 있었습니다. 이전 공부가 어떤 형태로 쓰일지 모르니 깊이 익히는 것 이 중요하다고 생각하게 됐습니다.
시스템 기획에 도움이 된 다른 경험은 예외 상황을 미리 목록으로 만드는 습관이었습니다. 알고리즘 풀이에서 엣지 케이스를 빠뜨리면 전체가 틀어지는 걸 반복해 겪은 게 몸에 뱄습니다. 인턴 때 주문 처리 플로우를 기획하면서, 정상 흐름뿐 아니라 결제 실패·중복 주문 같은 예외를 먼저 표로 정리했습니다. 그 목록 덕분에 개발 단계에서 뒤늦게 발견될 구멍이 줄었다는 피드백을 받았습니다.
잘 되는 경우보다 안 되는 경우를 먼저 적는 것이 시스템 기획의 핵심이었습니다. 추상적인 '꼼꼼함'이 아니라, 예외를 목록화하는 구체적 습관이 산출물의 품질을 갈랐습니다. 공부에서 온 버릇이 실무 산출물로 이어졌습니다.
시스템 기획에서 제가 부족했던 건 구조에 갇혀 사용자 경험을 늦게 본 것입니다. 입력·처리·출력으로 깔끔하게 나누는 데는 익숙했지만, 그 흐름이 실제 사용자에게 자연스러운지는 처음엔 충분히 못 봤습니다. 한 번은 논리적으로는 맞는 플로우가, 사용자에겐 단계가 너무 많아 불편한 것을 뒤늦게 알았습니다. 분해하는 능력과 사용자 입장에서 보는 능력은 달랐습니다. 그래서 플로우를 짠 뒤 실제 써보는 사람의 동선으로 한 번 더 점검하려 했습니다.
구조가 깔끔하다고 좋은 기획은 아니었습니다. 논리와 경험을 함께 보는 감각이, 제가 계속 키워야 할 부분이라고 생각합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 스마일게이트 기획 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.