이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
ERP 제안서 작성 실습에서 처음에 기능 목록을 먼저 나열했더니 '그래서 우리 회사 문제가 어떻게 해결되나요'라는 피드백을 받았습니다. 기능이 많아도 고객의 문제와 연결되지 않으면 제안서가 카탈로그처럼 보인다는 걸 그때 깨달았습니다. 그 뒤로는 고객의 현재 고통 지점 → 해결 방향 → 기능 순서로 구성합니다. 현황에는 고객이 인터뷰에서 말한 구체적인 수치를 그대로 인용하면 설득력이 높아집니다. 팀 프로젝트에서 이 구성을 적용한 제안서가 '문제가 잘 보인다'는 평가를 받았을 때 순서의 차이가 크다는 걸 확인했습니다. 기능 사양은 뒤에 붙여도 되지만 왜 이 기능이 필요한가는 앞에 있어야 한다고 생각합니다.
ERP 제안서 작성에서 제가 가장 오래 고민한 부분은 ROI 산정을 어디까지 써야 하는가였습니다. 수업에서 배운 공식을 그대로 적용하면 숫자가 나오기는 하지만, 가정이 너무 많아서 실제 의사결정에 쓰이기 어렵다는 피드백을 받았습니다.
결국 제가 택한 방식은 낙관적 시나리오와 보수적 시나리오를 함께 제시하는 것이었습니다. 단일 수치보다 범위를 보여주는 방식이 오히려 신뢰도 있는 산정이라는 인식을 줬습니다. 고객이 보수적 시나리오에서도 효과가 있다면 도입 결정을 내리기 더 쉽다는 논리였습니다.
ROI는 설득을 위한 도구이지 예측 도구가 아니라는 걸 그 과정에서 배웠습니다. 어느 가정에서 숫자가 달라지는지를 명시하는 것이 제안서의 신뢰를 높이는 방식이라는 결이 남아 있습니다.
ERP 제안서에서 한계를 명시하는 게 오히려 설득력을 높인다는 걸 처음 실감한 건 발표 피드백을 받았을 때였습니다. 제안서에 기대 효과만 적었더니 '이 수치는 어느 조건에서 나오는 건가요'라는 질문이 바로 나왔습니다.
이후에는 '이 효과가 나타나기 위해 필요한 전제 조건' 을 제안서 안에 먼저 적었습니다. 예를 들어 '데이터 정합성이 현재 90% 이상인 경우', '핵심 사용자 교육이 3개월 내 완료되는 경우' 같은 조건을 명시하는 방식이었습니다.
그 방식을 쓰고 나서 Q&A에서 가정 관련 질문이 줄었고, 오히려 '이 조건이 안 되면 어떻게 대응하나'라는 실무적인 질문으로 바뀌었습니다. 제안서는 좋은 결과를 약속하는 문서가 아니라 의사결정을 돕는 문서라는 결을 그 경험에서 얻었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 올웨이즈 풀스택 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.