이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 기획팀과 개발팀 역할로 나뉘었는데, 기획서에 간단한 필터 기능이라고만 적혀 있어서 각자 다른 것을 만들고 있었습니다. 저는 단순 드롭다운을 구현했고, 기획 팀원은 다중 선택 + 날짜 범위 필터를 기대하고 있었습니다. 2주 후 중간 리뷰에서 서로 다른 결과물을 보고 당황했습니다. 이후로는 어떤 사용자가 어떤 상황에서 쓰는지를 구현 전에 같이 작성하는 방식으로 바꾸었습니다.
한 문장 요구사항은 구현 전에 질문으로 풀어야 한다는 것을 배웠고, 그 이후에는 비슷한 미스커뮤니케이션이 없었습니다. 이후로 요구사항이 들어오면 "어떤 상황에서 필요한가"를 먼저 적는 습관이 생겼습니다. 그 한 줄이 구현 방향 전체를 바꾸는 경우가 많다는 것을 배웠습니다.
인턴 때 스프린트 종료 3일 전에 클라이언트 측에서 화면 레이아웃 전체를 바꿔달라는 요청이 왔어요. 팀에서는 당황했고 일부는 거절해야 한다고 했습니다. 저는 먼저 어떤 이유로 변경이 필요한지를 묻자고 제안했어요. 알고 보니 클라이언트가 사용성 테스트 결과를 받은 직후였고, 특정 탭이 사용자들이 못 찾는다는 문제가 있었습니다. 전체 레이아웃 변경 대신 해당 탭의 위치와 레이블만 수정하는 대안을 제시했고 클라이언트가 동의했어요. 요구 변경의 배경을 먼저 이해하면 더 좁은 해결책으로 합의할 수 있다는 걸 배웠습니다. 요구 변경의 배경을 먼저 이해하면 더 좁은 해결책으로 합의할 수 있다는 걸 배웠습니다. 이후 변경 요청이 들어오면 "왜?"를 먼저 묻는 게 습관이 됐어요.
캡스톤 프로젝트에서 지도 교수님께 진행 상황을 보고할 때, 기술 용어를 쓰면 이해 못 하시는 경우가 있었어요. REST API 설계가 완료됐습니다라고 했더니 그게 뭔가요라고 하셔서 당황했습니다. 이후로는 프론트엔드와 백엔드가 데이터를 주고받는 규칙을 만들었습니다처럼 바꿔서 설명했어요. 교수님이 바로 이해하시고 후속 질문을 주셨는데, 그 질문이 우리가 놓쳤던 예외 케이스를 짚어주셨습니다. 기술을 모르는 이해관계자가 더 날카로운 질문을 할 수 있다는 걸 배웠어요. 상대가 이해하는 언어로 말하면 더 좋은 피드백을 받을 수 있다는 걸 이제는 압니다. 상대가 이해하는 언어로 말하면 더 좋은 피드백을 받을 수 있다는 걸 이제는 압니다.
기술 언어와 비기술 언어를 상황에 맞게 전환하는 게 협업의 핵심이라고 생각해요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 영업지원·기획 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.