이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 디자이너·개발자·기획자가 함께 하는 스프린트를 처음 경험하면서 각 직군이 서로 다른 언어를 쓴다는 점을 실감했습니다. 디자이너는 '느낌'과 '맥락'으로 설명하고, 개발자는 '구현 가능 여부'와 '코스트'로 응답하는 구조였습니다. 저는 두 팀 사이에서 사용자 목적을 공통 기준으로 삼는 방식으로 소통했습니다. 예를 들어 '이 버튼이 눈에 띄어야 한다'는 디자이너 의견을 '이 버튼의 클릭률 목표가 20%인데 현재 위치에서 달성 가능한가'로 바꿔 개발자에게 전달했습니다.
수치 기준이 생기자 논의가 짧아졌고 양쪽 모두 결정이 빨라졌다는 피드백을 받았습니다. 디자이너·개발자와의 소통에서 핵심 전략은 의견을 주고받기 전에 측정 가능한 기준을 먼저 합의하는 것이라고 생각합니다.
개발자·디자이너와 소통할 때 제가 또 쓴 방식은 말이 아니라 프로토타입으로 맞추는 것입니다. 디자이너는 '느낌'으로, 개발자는 '구현 가능성'으로 말해, 글로만 설명하면 서로 다르게 이해했습니다. 그래서 간단한 프로토타입이나 화면을 함께 보며 논의했습니다. 같은 화면을 보니, 말로는 안 풀리던 차이가 한눈에 합의됐습니다. 또 결정된 건 문서로 남겨, 나중에 다르게 기억하지 않게 했습니다.
추상적인 말보다, 보이는 걸 함께 보는 게 소통을 빨리 끝냈습니다. 그래서 직군 사이에선, 말을 줄이고 보이는 것으로 맞추려 했습니다.
개발자·디자이너 소통에서 제가 양보한 자리는 완벽한 디자인이나 기능입니다. 사용자 목적을 공통 기준으로 삼아도, 디자이너가 원하는 완성도와 개발 코스트가 충돌했습니다. 한 번은 디자이너의 이상적인 안이, 개발 비용이 너무 커 일부를 양보했습니다. 제 기준만 밀면, 어느 쪽도 만족 못 했습니다. 그래서 핵심 목적이 걸린 건 지키되, 덜 중요한 건 현실에 맞춰 조정했습니다.
측정 가능한 기준을 먼저 합의해도, 그 안에서 트레이드오프는 남았습니다. 그래서 어디를 양보하고 어디를 지킬지 가르는 게 소통의 실제였습니다. 다 만족시키는 답은 드물었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 디웨일 서비스 오너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.