이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
기술적 문제와 비즈니스 요구 사이에서 균형을 맞추는 것이 어렵다는 것을 처음 느낀 건 팀 프로젝트에서 기능 구현 범위를 결정할 때였습니다. 기술적으로 가능한 것과 기한 안에 완성할 수 있는 것이 달랐고, 팀원들마다 생각하는 우선순위가 달랐습니다.
그때 제가 시도한 방식은 기능 목록을 세 단계로 나누는 것이었습니다. 없으면 안 되는 것, 있으면 좋은 것, 나중에 해도 되는 것으로 구분했습니다. 이렇게 정리하니 팀원들이 어디에 집중해야 하는지 빠르게 합의됐고, 기한 안에 핵심 기능을 완성할 수 있었습니다.
기술 측면에서 욕심을 내면 완성도를 높일 수 있지만, 기한을 넘기면 다른 팀원에게 부담이 됩니다. 그 균형을 먼저 요구사항을 명확히 정리하는 것에서 시작한다고 생각하게 됐습니다. 완성보다 완료가 먼저라는 감각은 그 경험에서 생겼습니다.
인턴 기간에 작은 기능 하나를 맡았는데, 처음에 빠르게 동작하도록 짜다 보니 나중에 수정하기 어려운 구조가 됐습니다. 선임에게 피드백을 받았고, 지금은 동작하지만 기술 부채가 생겼다는 말을 들었습니다. 그때 처음으로 단기 완료와 장기 유지 사이의 긴장을 실감했습니다.
그 이후로 코드를 짜기 전에 이 구조를 나중에 바꾸어야 할 가능성이 있는지를 먼저 생각하게 됐습니다. 비즈니스 요구가 자주 바뀌는 부분이라면 처음부터 유연하게 짜는 것이 낫고, 잘 안 바뀌는 부분은 단순하게 짜는 것이 더 현실적이라는 판단이 생겼습니다.
기술과 비즈니스를 균형 있게 보려면 상대방의 언어를 이해해야 한다는 것도 배웠습니다. 개발자가 위험 요소를 설명할 때 기술 용어로 하면 팀원이 판단하기 어렵고, 이것을 하면 나중에 이런 상황이 생길 수 있다는 식으로 설명해야 논의가 됐습니다.
기술적 문제와 비즈니스 요구 사이에서 균형을 맞추려면 양쪽의 제약 조건을 먼저 파악해야 한다고 생각합니다. 기술 측면의 제약과 시간·비용 측면의 제약을 같이 놓고 봐야 선택지가 보입니다.
캡스톤 프로젝트에서 비슷한 상황이 있었습니다. 팀원이 외부 API를 쓰자고 제안했는데, 기술적으로는 더 빠르게 구현할 수 있었지만 무료 호출 횟수 제한이 있어서 실제 운영 시 문제가 될 수 있었습니다. 저는 그 제약 조건을 먼저 확인하고 팀에 공유했고, 결국 다른 방식을 선택했습니다.
이 경험에서 배운 것은 기술 결정을 내릴 때 비용·운영·확장성을 함께 보지 않으면 나중에 다시 뜯어고치는 일이 생긴다는 것입니다. 처음에 조금 더 시간을 써서 조건을 파악하는 것이 결국 더 빠르다는 것을 그때 알았습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 여기어때 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.