이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 B2B SaaS 온보딩 프로젝트에서 고객사 담당자가 세 번 바뀌는 상황을 겪었습니다. 요건이 바뀔 때마다 개발 방향이 흔들려서 변경 이력과 합의 내용을 문서로 남기는 것을 제가 먼저 시작했습니다. 처음엔 슬랙 채팅으로만 소통하다 보니 나중에 '그런 말 한 적 없다'는 상황이 생겼고, 이후엔 회의 후 요약 메일을 보내고 고객 확인을 받는 흐름을 만들었습니다. 담당자 교체 때마다 온보딩 문서를 업데이트해서 새 담당자가 빠르게 프로젝트 컨텍스트를 파악할 수 있게 했습니다. 이 경험에서 B2B 프로젝트의 도전은 기술보다 이해관계 관리라는 걸 배웠습니다.
요건 변경이 있을 때 흔들리지 않으려면 합의 기반이 단단해야 한다는 것, 그때 처음 피부로 느꼈습니다.
B2B 프로젝트에서 일정을 크게 잘못 추정해 팀 전체가 야근을 반복한 경험이 있습니다. 고객사가 추가 요건을 요청할 때 범위가 명확하지 않은 상태에서 할 수 있다고 먼저 확약한 것이 문제의 시작이었습니다. 프로젝트 중반에 일정이 터지면서 납기를 맞추기 위해 품질 일부를 양보하는 결정을 팀이 내렸고, 저도 동의했습니다. 결과적으로 납기는 맞췄지만 기술 부채가 남았고, 이후 유지보수 단계에서 그 비용이 더 크게 돌아왔습니다. 솔직히 회고하면, 그 시점에 안 된다고 말하는 것이 장기적으로 고객과 팀 모두에게 더 나은 선택이었을 것입니다. 이 경험 이후 요건 추가 요청에는 영향 범위를 먼저 추정하고 숫자로 제시한 뒤 합의하는 습관이 생겼습니다.
고객사 레거시 시스템과 신규 API를 연동하는 프로젝트에서 공식 문서와 실제 동작이 다른 케이스가 반복적으로 나왔습니다. 제가 직접 실 환경에서 반복 테스트를 돌리며 케이스를 정리했고, 발견한 엣지 케이스를 고객사 담당자에게 공유해 문서를 수정하게 했습니다. 혼자 해결하려다 시간을 낭비하던 중 선임에게 물어보니 레거시 연동은 항상 이렇고 직접 탐색하는 것 외에 방법이 없다는 조언을 들었습니다. 돌아보면 처음부터 비슷한 경험이 있는 사람을 찾아 먼저 물어봤으면 불필요한 삽질을 줄일 수 있었을 것입니다. 이 경험 이후로는 연동 초기에 경험자에게 먼저 물어보는 습관이 생겼습니다. 모르는 것을 일단 혼자 파는 것이 때로는 비효율임을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 크라우드웍스 테크니컬 PM 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.