이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 개발팀과 자주 회의를 하면서, 기술을 모르는 채로 들어가면 회의가 겉돈다는 걸 느꼈습니다. 그 이후로 회의 전에 관련 기술 개념을 간단히 찾아봤는데, 모든 걸 이해하려다 보면 끝이 없어서, 이 기능이 '왜 어려운지'와 '무엇이 제약인지'를 파악하는 데 집중했습니다. 개발팀에서 '기획자 중에 이런 질문 하는 분이 드물다'는 말을 들었고, 논의 속도도 빨라졌습니다. 기술 배경지식은 구현을 이해하는 것보다 제약을 이해하는 것이 소통에 더 유용하다는 걸 배웠습니다.
제약을 이해하는 것이 소통에 더 유용하다는 걸 배웠고, 이후에도 회의 전에 기술 제약을 먼저 파악합니다.
기획 공부를 하면서 간단한 웹 페이지를 직접 만들어본 경험이 있습니다. 처음엔 버튼 하나 추가하는 게 왜 시간이 걸리는지 몰랐는데, 직접 짜보니 디자인, 동작, 예외 처리를 각각 고려해야 한다는 걸 알게 됐습니다. 그때부터 개발자에게 '버튼 하나만 추가하면 돼요'라는 말을 안 하게 됐습니다. 이후 개발팀과 일정 협의할 때 더 현실적인 기준으로 논의할 수 있었습니다. 개발자와 소통하려면 코드를 잘 짜는 게 아니라 왜 어려운지를 아는 것이 먼저라는 걸 배웠습니다.
왜 어려운지를 아는 것이 개발자 소통의 시작이라는 걸 배웠고, 이후에도 직접 짜보는 경험을 이어가고 있습니다.
취준 중 기술 블로그와 개발 문서를 꾸준히 읽는 습관이 있습니다. 처음엔 내용이 어려웠는데, 기술 용어를 외우는 대신 '이게 왜 생겼는지'를 중심으로 읽으니 개념이 맥락으로 이해됐습니다. 예를 들어 캐싱이 왜 필요한지를 알면, 개발팀이 '이 기능엔 캐시가 안 된다'고 할 때 왜 어려운지 바로 이해됩니다.
이런 배경이 있으니 개발팀과 회의에서 전달이 더 잘 됐습니다. 기술 지식은 구현 방법보다 맥락을 이해하는 것이 소통에 더 효과적이라는 걸 배웠습니다. 맥락을 이해하는 것이 소통에 더 효과적이라는 걸 배웠고, 이후에도 원리 중심으로 기술 문서를 읽습니다. 기술의 맥락을 알면 개발자의 말이 다르게 들립니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.