이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
기술 아키텍처 논의에서 PM이 주의해야 하는 것은 기술 세부 결정보다 비즈니스 요구와 기술 선택 사이의 거래를 명확히 하는 것이라고 생각합니다. 수업 시스템 설계 케이스에서 단순한 구조가 복잡한 구조보다 운영 비용이 낮다는 원칙을 배웠습니다. 처음부터 확장성을 지나치게 고려하면 당장 불필요한 복잡도가 높아지는 문제가 생깁니다.
현재 규모에 맞는 설계를 선택하고, 확장이 필요해지면 그때 구조를 바꾸는 것이 더 현실적입니다. 아키텍처 논의에서 PM의 역할은 어떤 기능이 얼마나 자주 바뀔 것인지를 전달하는 것입니다. 그 정보가 있어야 엔지니어가 유연성과 단순함 사이의 거래를 올바르게 결정할 수 있습니다. PM이 변경 빈도를 구체적으로 전달할수록 아키텍처 논의 시간이 줄어든다는 것을 케이스에서 배웠습니다.
기술 아키텍처 논의에서 제가 의식하는 건 여러 트레이드오프를 비즈니스 우선순위와 정렬하는 것입니다. 확장성과 단순성, 일관성과 가용성(CAP), 개발 속도와 기술 부채 사이엔 늘 거래가 있었습니다. PM이 코딩 세부를 다 알 필요는 없지만, 특정 선택이 이후 기능 개발 속도·유지보수 비용·장애 리스크에 미치는 영향을 엔지니어에게 물어야 했습니다. 그걸 빠른 출시냐 안정 운영이냐 같은 비즈니스 우선순위와 정렬하는 게 제 역할이었습니다.
기술 결정을 엔지니어에게만 맡기면, 비즈니스와 어긋났습니다. 그래서 거래를 명확히 하고, 우선순위에 맞는 결정을 끌어내는 게 핵심이었습니다.
기술 아키텍처에서 제가 케이스로 배운 건 현재 규모에 맞는 단순 구조를 고르는 것입니다. 단순한 구조가 복잡한 것보다 운영 비용이 낮았습니다. 처음부터 확장성을 지나치게 챙기면, 당장 불필요한 복잡도가 올랐습니다. 그래서 지금 규모에 맞게 설계하고, 확장이 필요해지면 그때 바꾸는 게 현실적이었습니다. 아키텍처 논의에서 PM의 역할은 어떤 기능이 얼마나 자주 바뀔지를 전달하는 것이었습니다. 그 정보가 있어야, 엔지니어가 유연성과 단순함 사이의 거래를 올바르게 결정했습니다.
변경 빈도를 구체적으로 전달할수록, 논의 시간이 줄었습니다. 그래서 PM은 기술이 아니라 변화의 맥락을 전했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.