이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
비즈니스 요구와 사용자 요구를 정렬할 때 두 요구가 충돌하는 순간을 빠르게 드러내는 것이 핵심이라고 생각합니다. 수업 서비스 기획 과제에서 비즈니스 목표를 먼저 OKR로 정의하고, 사용자 시나리오를 그 아래에 매핑하는 방식을 사용했습니다. 기능-목표 매핑표를 만들면 어떤 기능이 비즈니스와 사용자 가치를 동시에 충족하는지가 시각적으로 보였습니다. 로드맵 작성 시 사업 우선순위와 사용자 불편 지점이 겹치는 기능을 먼저 배치했습니다. 두 요구가 충돌할 때는 사용자에게 가치를 주지 않으면 비즈니스에도 결국 돌아온다는 원칙으로 판단했습니다.
완벽한 정렬보다 빠른 충돌 발견이 더 중요하다는 것을 그 경험에서 배웠습니다. 충돌을 늦게 발견할수록 수정 비용이 커지기 때문에, 정렬 과정을 반복 루틴으로 만드는 것이 중요합니다.
비즈니스 요구와 사용자 요구를 정렬할 때 제가 가장 의식하는 건, 둘이 자주 충돌한다는 점입니다. 사용자가 요청한 기능을 다 만들면 만족은 오르지만 성장에 안 닿고, 사업 레버리지 큰 기능만 밀면 사용자가 떠납니다. 그래서 저는 사용자 요청을 그대로 받지 않고, 그 요청의 배경 니즈를 파악해 사업 목표와 동시에 푸는 솔루션을 찾으려 합니다. 예를 들어 '알림을 달라'는 요청 뒤의 진짜 니즈가 '기회를 놓치고 싶지 않다'면, 그걸 사업 지표와 함께 만족시킬 길을 봅니다. 충돌할 땐 사용자에게 가치를 안 주면 결국 사업에도 돌아온다는 원칙으로 판단합니다. 다만 제 한계도 인정합니다. 저는 수업 과제 수준이라, 실제로 배경 니즈를 파고들어 두 요구를 동시에 푸는 솔루션을 설계해 본 경험은 적습니다. 또 어디까지 사용자 가치를 우선할지 그 균형도 데이터로 봐야 합니다. 그래서 정렬을 한쪽 최적화가 아니라, 사업과 사용자의 거래를 의식해 배경 니즈에서 접점을 찾는 일로 보려 합니다.
수업 서비스 기획 과제에서 비즈니스와 사용자 요구를 정렬하며, 제가 직접 한 건 둘이 충돌하는 순간을 빨리 드러내는 일이었습니다. 저는 비즈니스 목표를 먼저 OKR로 정의하고, 사용자 시나리오를 그 아래 매핑한 기능-목표 매핑표를 만들었습니다. 그러자 어떤 기능이 사업과 사용자 가치를 동시에 충족하는지가 한눈에 보였습니다. 로드맵엔 사업 우선순위와 사용자 불편이 겹치는 기능을 먼저 배치했습니다. 완벽한 정렬보다 충돌을 빨리 발견하는 게 더 중요하다는 걸 배웠습니다. 충돌을 늦게 알수록 수정 비용이 크기 때문입니다. 다만 제 한계도 인정합니다. 저는 과제 규모라, 실제로 탐색과 개발 트랙을 병행하거나 분기마다 정렬 상태를 검증하는 운영은 해 보지 못했습니다. 또 매핑표가 제 가정에 기대 있어, 실제 사용자 데이터로 검증해야 합니다. 그래서 정렬을 한 번 맞추고 끝내는 게 아니라, 충돌을 빨리 드러내 반복해 맞추는 루틴으로 보려 합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 라인 서비스 오너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.