이 질문은 말솜씨를 확인하려는 게 아니라, 상대의 이해 수준을 판단해 설명 방식을 조정하고 실제로 이해했는지 확인하는 과정까지 갖췄는지를 본다. 비유를 썼다는 사실보다 그 비유를 고른 기준과 이해 여부를 재확인한 절차가 답의 핵심이다. 기술적 정확성을 완전히 포기하지 않으면서도 상대가 알아야 할 것 위주로 정보를 재구성했는지가 채점 포인트다.
면접관은 무엇을 보나
기술 내용을 비엔지니어에게 설명할 때 쓴 방법이 답에 있는지를 봅니다. 없으면 면접관이 '어떤 사례로 설명할 수 있나요?'를 추가로 묻는 경우가 자주 보입니다.
설명할 때 실제로 쓴 비유나 예시가 답에 있는지를 봅니다. 없으면 면접관이 '구체적으로 어떤 상황이었나요?'를 물어보는 자리가 자주 보입니다.
듣는 사람의 배경 지식 수준을 고려한 방식이 답에 있는지를 봅니다. 없으면 면접관이 '어떤 점을 중점적으로 설명했나요?'를 추가로 묻는 경우가 흔합니다.
상대의 피드백을 받아 설명 방식을 조정한 경험이 답에 있는지를 봅니다. 없으면 면접관이 '어떤 피드백을 받았고 어떻게 대응했나요?'를 물어보는 자리가 자주 보입니다.
읽는 것과 말하는 건 다릅니다.
이 질문, 소리 내어 답해 볼까요?
모범 답변의 결
비엔지니어에게 기술 개념을 일상 비유로 설명하고 이해를 확인한 경험
인턴 때 캐시 서버 장애가 서비스에 미치는 영향을 비개발자 팀장께 설명해야 했습니다. '캐시가 뭔가요?'라는 질문부터 시작됐는데, 기술 용어로 설명하면 눈이 흐려지는 것이 느껴졌습니다.
'편의점에서 물건을 사는 것과 창고에서 직접 가져오는 것의 차이'로 설명했습니다. 편의점이 캐시, 창고가 DB에 해당하는 비유를 썼더니 '편의점이 문을 닫으면 창고까지 가야 하니까 느려지겠네요'라고 바로 이해하셨습니다.
이해했는지 확인하려면 설명 후 상대방에게 다시 말해달라고 해보는 것이 효과적이라는 걸 그때 배웠습니다. 직접 설명을 들은 것과 실제 이해한 것이 다른 경우가 많았습니다. 비유는 정확성보다 공감 가능한 경험을 기준으로 선택한다는 것이 지금도 제 방식입니다.
기획자가 이해하기 어려운 기술 제약을 시각화로 설명해 합의한 경험
팀 프로젝트에서 기획자가 요청한 실시간 재고 반영 기능이 현재 구조로는 구현 비용이 크다는 걸 설명해야 했습니다. 기술적 이유를 말로 설명했더니 '왜 못 하나요?'라는 반응이 돌아왔습니다.
화이트보드에 현재 데이터 흐름을 화살표로 그리고, 실시간 반영이 되려면 어느 단계에 무엇이 추가되어야 하는지 시각화했습니다. '추가되는 부분이 이만큼이면 일정을 얼마나 조정해야 할까요?'라는 질문으로 연결하니 기획자도 트레이드오프를 직접 판단할 수 있게 됐습니다.
그 경험에서 기술 제약을 설명할 때는 '불가능하다'보다 '이만큼의 비용이 든다'로 표현하는 것이 협업에 훨씬 도움이 된다는 걸 배웠습니다. 비엔지니어는 결정권을 원하지, 한계 선언을 원하지 않는다는 것이 지금도 제 기준입니다.
고객사 비개발자에게 장애 상황과 원인을 명확하게 전달한 경험
인턴 때 외부 파트너사 담당자에게 서비스 장애 경위를 이메일로 설명해야 했습니다. 기술 용어로 작성했더니 '무슨 말인지 모르겠다'는 회신이 왔습니다.
다시 쓸 때는 무슨 일이 있었는지, 사용자에게 어떤 영향이 있었는지, 언제 해결됐는지, 앞으로 어떻게 막을지 4단락으로 구성했습니다. 서버, 캐시 같은 단어는 쓰지 않고 '데이터를 가져오는 과정에서 연결이 끊겼습니다'처럼 표현을 바꿨습니다.
장애 설명에서 기술적 정확성보다 상대방이 알아야 할 것이 무엇인지가 먼저라는 걸 배웠습니다. 이후엔 기술 문서를 쓸 때 독자가 누구인지 먼저 정하고 단어를 고르는 습관이 생겼습니다.
전문가의 심화 해설
상황-첫 시도 실패-조정 순서로 짜야 하는 이유
이 답은 어떤 상황에서 설명이 필요했는지, 처음 시도한 설명이 왜 통하지 않았는지, 이후 어떻게 조정했는지 순서로 짜는 게 자연스럽다. 순서를 바꿔 성공한 비유부터 말하면 그 비유를 고르기까지의 시행착오가 안 보여, 면접관은 즉흥적으로 잘 맞아떨어진 우연인지 의도된 판단인지 구분하기 어렵다. 처음 시도가 통하지 않았던 지점(전문 용어로 설명했다가 상대가 이해 못 한 순간)을 먼저 보여줘야, 이후 조정이 실제 관찰에서 나온 판단이라는 신뢰가 생긴다.
비유를 던지고 끝내는 답과 이해를 확인하는 답의 차이
세 예시 모두 비유나 재구성으로 설명한 경험을 다루지만, 면접관이 갈라 보는 지점은 비유를 던진 것으로 끝나는지, 아니면 상대에게 다시 설명해달라고 요청하거나 반응을 통해 이해 여부를 확인하는 단계가 있는지다. 설명을 들려준 것과 실제로 이해시킨 것은 다른데, 확인 절차가 있는 답은 그 차이를 인지하고 있다는 신호로 읽힌다. 확인 절차 없이 비유만 말하면 설명을 전달했다는 사실에 만족한 것으로 보여, 실제 소통 능력의 깊이가 얕게 읽힐 수 있다.
상대방 반응 확인 질문이 위험한 이유와 준비된 답의 조건
'상대방의 이해도를 어떻게 확인하셨나요'는 설명 자체보다 그 이후 단계를 캐묻는 질문이라, 준비 없이 답하면 '표정을 보고 알 수 있었다'처럼 근거 약한 답으로 흐르기 쉽다. 이 질문이 위험한 이유는 설명력과 확인력을 구분해서 보기 때문에, 설명만 잘했다는 답으로는 부족하다. 준비된 답은 상대에게 다시 말해달라고 요청했거나, 구체적인 후속 질문(예: '그럼 이런 경우엔 어떻게 되나요')을 받아 이해 수준을 가늠했던 순간을 짚는다.
내부 협업 대상과 외부 고객 대상의 강조점이 달라야 하는 이유
내부 기획자나 팀장에게 설명하는 상황이라면 트레이드오프를 함께 판단하게 만드는 협의 중심 접근이 자연스럽고, 외부 고객이나 파트너사에게 설명하는 상황이라면 신뢰를 지키기 위한 정확하고 공식적인 정보 전달 방식이 더 중요하다. 이 축을 잘못 골라, 외부 고객 응대 상황에서 내부 협의하듯 캐주얼한 비유만 쓰면 신뢰도가 떨어지는 것으로 보이고, 내부 협업 상황에서 지나치게 격식 차린 보고서식 설명만 하면 협의 유연성이 부족해 보인다. 상대가 누구인지부터 정의하고 방식을 골라야 한다.
쉬운 비유가 항상 정답이라고만 생각하면 안 되는 이유
많은 지원자가 비유를 쓰는 것 자체를 소통 능력의 전부로 여기는데, 비유가 실제 기술적 맥락과 어긋나면 오히려 잘못된 판단으로 이어질 수 있다. 예시에서도 비유는 '정확성보다 공감 가능한 경험'을 기준으로 고른다고 했지, 정확성을 완전히 버려도 된다는 뜻은 아니다. 쉬운 비유만 쓰면 무조건 소통이 잘된다고 생각했다가, 상대가 그 비유를 근거로 잘못된 결정을 내리는 위험을 놓칠 수 있다. 비유는 이해를 돕는 도구이지 정보의 정확성을 대체하는 것이 아니라는 균형이 필요하다.
이어질 수 있는 꼬리질문
설명할 내용을 어떻게 정리하셨나요?
어떤 내용을 우선적으로 설명했는지 답하면 강합니다. 주요 포인트를 짚는 답이 자주 나타납니다.
상대방의 이해도를 어떻게 확인하셨나요?
상대가 이해했는지 어떻게 확인했는지 구체적으로 말하면 배려와 소통 능력이 드러납니다.
어떤 비유나 예시를 사용하셨나요?
비유를 통해 설명한 경험을 끌어오면 강합니다. 효과적인 예시를 제시하는 답이 자주 나타납니다.
흔히 빠지는 실수
- 비유나 예시를 들었다는 사실만 말하고 상대가 실제로 이해했는지 확인한 절차는 없다.
- 전문 용어를 그대로 쓰다 실패한 경험 없이 처음부터 완벽한 설명을 한 것처럼 서술한다.
- 내부 협업 상대와 외부 고객을 구분하지 않고 같은 방식으로 설명했다고 답한다.
- 비유의 정확성을 전혀 신경 쓰지 않고 이해만 쉬우면 된다는 식으로 답한다.
- 설명 방식만 말하고 그 설명이 실제 의사결정이나 협업 결과에 어떻게 연결됐는지는 언급하지 않는다.
이 질문이 나온 회사
실제 면접에서 이 질문이 확인된 회사입니다.