이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
정식 기능 요구사항 정의서를 실무로 작성해본 경험은 아직 없습니다. 다만 제가 졸업 프로젝트에서 만들 기능을 글로 정리해본 경험으로 말씀드리겠습니다.
저는 그때 "누가 읽어도 같게 이해되는 명확함"에 가장 주의했습니다. 처음엔 제가 "검색이 잘 되게"처럼 두루뭉술하게 적은 적이 있었습니다. 그러자 팀원마다 "잘 된다"를 다르게 해석해, 만든 결과가 제각각이었습니다.
그 실패 뒤 저는 "무엇을 입력하면 무엇이 나와야 하는지"를 구체적으로 적었습니다. "잘 되게" 대신 "제목 일부만 넣어도 결과가 나온다"처럼요. 기능 요구사항 정의서도 읽는 사람이 다르게 해석할 여지를 없애는 것이 핵심이라고 이해합니다. 경험이 부족한 만큼, 저는 입사 후 실제 정의서 작성 방식을 선배에게 배우며 채워가겠습니다.
기능 요구사항 정의서를 실무로 작성해본 적은 없어, 제가 학부 프로젝트에서 기능을 정리해본 경험으로 답하겠습니다.
저는 그때 "잘 될 때"만 적으면 안 된다는 걸 배웠습니다. 처음엔 제가 기능이 정상으로 동작하는 경우만 정의서에 적은 적이 있었습니다. 그러자 개발 단계에서 "빈 값이 들어오면?", "네트워크가 끊기면?" 같은 질문이 쏟아져, 작업이 자꾸 멈췄습니다.
그 실패 뒤 저는 정의서에 예외 상황과 그때 어떻게 동작할지도 함께 적었습니다. 그러자 개발이 매끄러워졌습니다. 기능 요구사항 정의서는 정상 흐름만이 아니라, "잘못됐을 때 어떻게 되는지"까지 미리 정해두는 것이 중요하다고 이해합니다. 경험이 부족한 만큼, 저는 입사 후 실제 정의서 작성을 선배에게 배우며 채워가겠습니다.
기능 요구사항 정의서 작성에 대한 제 경험을 솔직히 말씀드리면, 실무로 해본 적은 없고 학부 프로젝트에서 기능을 정리해본 경험으로 익힌 단계입니다. 다만 저는 모른다고 멈추기보다 스스로 메우는 편입니다.
최근 저는 기능 요구사항 정의서가 어떻게 작성되는지 자료로 찾아보며 노트를 정리했습니다. 그 과정에서 제가 이해한 것은, 좋은 정의서가 누가 읽어도 같게 이해되는 명확함, 예외 상황 포함, 왜 필요한지에 대한 배경이라는 요소를 갖춰야 한다는 점입니다.
아직 실무 경험이 없다는 건 제 분명한 한계입니다. 그래서 입사 후 초기에는 선배의 정의서를 따라가며 익히는 시간이 필요하다고 봅니다. 다만 학부에서 기능을 직접 글로 정리해본 점이 토대가 되고, 모르는 걸 덮어놓고 안다고 하지 않는 것이 제 태도입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 incross 서비스 오너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.