이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 기술 부채 해결과 신규 기능 개발 사이의 우선순위 논쟁을 처음 경험했습니다. 비즈니스 팀은 신규 기능을 빠르게 출시하길 원했고, 개발팀은 기술 부채를 먼저 해소하지 않으면 개발 속도가 계속 느려진다는 입장이었습니다. 저는 이 갈등을 비즈니스 임팩트와 기술 리스크 두 축의 매트릭스로 정리해 팀에 공유했습니다. 높은 비즈니스 임팩트·낮은 기술 리스크 항목은 바로 진행, 낮은 임팩트·높은 기술 리스크 항목은 기술 부채 해소 후 진행하는 방식으로 순서를 제안했습니다. 이 프레임이 논의의 공통 기준이 되자 두 팀의 갈등이 줄었다는 팀장님 피드백을 받았습니다. 비즈니스 목표와 기술 목표의 균형은 어느 쪽이 더 중요한가의 문제가 아니라 두 축을 동시에 볼 수 있는 기준을 만드는 것이라고 생각합니다.
비즈니스 목표와 기술 목표의 균형에서 제가 중요하게 본 것은 둘을 대립이 아니라 같은 목표 위에서 보는 것입니다. 팀 프로젝트에서 사업 쪽은 기능을 빨리 내고 싶어 하고, 개발 쪽은 안정성을 먼저 챙기고 싶어 해 부딪혔습니다. 처음엔 어느 쪽이 옳은가로 다퉜는데, 사실 둘 다 서비스가 잘 되는 것이라는 같은 목표를 향하고 있었습니다. 그래서 저는 각 요구가 그 공통 목표에 어떻게 기여하는지를 함께 따져 순서를 정하자고 제안했습니다. 사용자에게 당장 임팩트가 큰 것은 먼저, 안 하면 나중에 더 큰 비용이 되는 것은 그다음으로 묶었습니다. 균형은 어느 쪽이 이기느냐가 아니라, 같은 목표 위에서 무엇을 먼저 할지를 함께 정하는 것이라고 생각합니다. 대립을 공동 판단으로 바꾸는 것이 핵심이었습니다.
비즈니스와 기술 목표를 조율하며 제가 양보해야 했던 자리도 있습니다. 한 프로젝트에서 사용자에게 좋은 기능을 빨리 내고 싶었지만, 개발 쪽이 지금 기반을 손보지 않으면 앞으로 모든 개발이 느려진다고 했습니다. 처음엔 당장의 기능이 더 급해 보여 밀고 싶었지만, 그 말을 듣고 일부 기능을 미루고 기반 정비를 먼저 하기로 했습니다. 제가 보던 것은 단기 임팩트뿐이었고, 장기 속도라는 다른 축을 놓쳤던 것입니다. 그 경험으로 저는 내 판단이 옳아 보여도, 다른 쪽이 보는 축을 무시하면 전체가 느려진다는 것을 배웠습니다. 균형은 한쪽을 관철하는 것이 아니라, 단기와 장기를 함께 보고 무엇을 양보할지 정하는 것이었습니다. 그래서 저는 균형을 맞출 때 내가 못 보는 축이 무엇인지를 먼저 묻습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 스마일게이트(사업부문) 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.