역질문과 최종 면접 - 묻고 마무리하기

이 장에서 배우는 것

앞 장에서 언어 지식을 설명하는 연습을 했다면, 이제 면접의 마지막 대화를 준비할 차례다. 면접관이 “궁금한 점이 있나요”라고 물었을 때는 자신을 한 번 더 홍보하는 데 그치지 않고, 입사 후 맡을 일과 일하는 방식을 확인해야 한다. 최종 면접에서도 새로운 정답을 만들어 내기보다 앞서 말한 경험과 선택 기준을 일관되게 설명하는 일이 중요하다.

가상의 중고 거래 서비스 팀에 지원한 신입 개발자 지우는 기술 면접을 마치고 최종 면접을 앞두고 있다. 이 장에서는 지우가 질문을 고르고, 조건을 확인하고, 결과를 다음 준비로 연결하는 과정을 따라간다. 마지막에는 이미 들은 답을 제외하고 주제별 역질문을 고르는 작은 프로그램을 만든다.

팀·일·성장에 관한 질문을 구체적인 상황과 연결해 고른다.
이미 답을 들은 질문과 아직 확인하지 못한 부분을 구분한다.
최종 면접에서 지원 동기, 판단 기준, 경험의 한계를 일관되게 설명한다.
처우와 일정은 적절한 담당자에게 확인하고, 면접 후 기록과 감사 인사를 정리한다.
질문 후보를 의미 단위로 분류하고 중복을 줄이는 과정을 코드로 확인한다.

문제 상황

지우는 중고 거래 서비스의 상품 등록과 거래 상태 변경 기능을 만드는 팀에 지원했다. 기술 면접 중 면접관은 변경 사항을 동료가 검토하며, 입사 초기에는 안내 담당자와 작은 수정부터 시작한다고 설명했다. 지우의 메모에는 “코드 검토는 어떻게 하나요”, “신입은 어떻게 적응하나요”, “성장할 수 있나요”가 적혀 있다.

그대로 질문하면 앞의 두 질문은 이미 들은 내용을 반복한다. 마지막 질문은 범위가 넓어 “성장할 기회가 있다”는 답으로 끝나기 쉽다. 지우에게 필요한 정보는 기회의 존재보다 구체적인 작동 방식이다. 누구에게 어떤 피드백을 받는지, 작은 수정을 마친 뒤 다음 책임은 어떻게 정하는지 확인해야 입사 후 모습을 그릴 수 있다.

최종 면접에서는 다른 어려움도 생긴다. 면접관은 지원 이유와 입사 후 기대를 다시 묻고, 채용 담당자는 합류 가능일을 확인한다. 지우는 기술 면접에서 말한 내용을 그대로 반복해야 할지, 더 인상적인 답을 새로 만들어야 할지 고민한다. 처우를 물으면 관심이 부족해 보일까 걱정하고, 면접이 끝난 뒤에는 감사 메일을 보내야 하는지도 망설인다.

이 상황에서 필요한 것은 말을 많이 하는 기술이 아니다. 이미 확인한 사실, 남은 질문, 자신의 선택 기준을 나누는 준비다. 면접 시간은 제한되어 있으므로 모든 항목을 한 번에 확인하려 하지 말고, 판단에 영향을 주는 정보부터 묻는다.

역질문은 입사 후의 장면을 확인하는 질문이다

역질문은 지원자가 면접관에게 하는 질문이다. 좋은 역질문은 자신의 관심과 연결되어 있고, 상대가 답할 범위가 분명하며, 답을 들은 뒤 선택이나 준비가 달라진다. “팀 분위기가 좋은가요”보다 “최근 의견이 갈렸을 때 결정을 정리한 방식이 궁금하다”는 질문이 실제 협업 모습을 확인하기 쉽다. 다만 다른 구성원의 잘못이나 내부 갈등의 세부 내용을 캐묻는 방식은 피한다.

질문은 팀·일·성장으로 나누어 준비하면 빠진 부분을 찾기 쉽다. 팀에서는 함께 판단하는 방식, 일에서는 처음 맡을 책임과 우선순위, 성장에서는 피드백과 기대 수준을 확인한다. 세 주제를 반드시 하나씩 물어야 하는 것은 아니다. 면접에서 충분히 설명한 주제는 빼고, 남은 시간과 자신의 판단 기준에 맞춰 고른다.

최종 대화에서 만날 질문 열 가지와 준비할 핵심
질문	의도	답변 핵심	꼬리 질문
마지막으로 궁금한 점이 있나요?	관심의 구체성과 상호 적합성 확인	이미 들은 내용을 제외하고 중요한 미확인 항목을 묻는다.	그 점이 왜 중요한가요?
어떤 팀에서 일하고 싶나요?	협업 방식과 기대 확인	추상적인 분위기보다 관찰 가능한 행동을 말한다.	기대와 다른 팀이라면요?
입사 후 처음 해 보고 싶은 일은 무엇인가요?	업무 이해와 기대의 현실성 확인	서비스와 연결한 작은 기여부터 제시한다.	다른 업무를 맡는다면요?
우리 팀을 선택한 이유는 무엇인가요?	지원 이유와 판단 기준의 일관성 확인	확인한 사실과 아직 기대하는 부분을 구분한다.	다른 팀에도 같은 이유가 있지 않나요?
어떤 피드백을 받고 싶나요?	학습 방식과 책임감 확인	구체적인 행동을 고칠 수 있는 피드백을 원한다고 설명한다.	동의하기 어려운 피드백이라면요?
앞서 설명한 경험에서 본인의 기여는 어디까지인가요?	설명의 신뢰성과 역할 경계 확인	자신이 한 일, 함께 한 일, 확인하지 못한 일을 나눈다.	다시 한다면 무엇을 바꾸겠나요?
희망 처우와 합류 가능일을 알려 주세요.	조건과 일정의 조율 가능성 확인	조건의 기준과 실제 가능한 일정을 분명히 말한다.	조정 가능한 항목은 무엇인가요?
다른 채용 절차도 진행 중인가요?	의사결정 일정 확인	공유 가능한 범위에서 사실과 일정만 전달한다.	언제까지 결정이 필요한가요?
마지막으로 덧붙일 말이 있나요?	누락된 정보와 마무리 방식 확인	필요한 정정이나 짧은 관심 표현을 남긴다.	추가로 확인할 자료가 있나요?
이번 면접을 돌아보면 무엇을 보완하겠나요?	자기 점검 능력 확인	관찰한 부족함과 다음 행동을 연결한다.	그 행동의 효과를 어떻게 확인하겠나요?

깊게 보기: “마지막으로 궁금한 점이 있나요?”

지우는 코드 검토와 입사 초기 안내에 관한 답을 이미 들었다. 이때 새로운 질문을 억지로 만들 필요는 없다. 들은 내용에서 아직 설명되지 않은 부분을 좁혀 묻는다. 질문 앞에 짧게 맥락을 붙이면 반복 질문과 후속 질문의 차이도 분명해진다.

같은 역질문 기회에 대한 답의 차이
수준	답변	차이를 만드는 지점
나쁜 답	홈페이지를 못 봤는데, 어떤 서비스를 만드는 곳인가요?	기본적으로 확인할 수 있는 정보의 탐색을 상대에게 넘긴다.
보통 답	신입 개발자는 어떻게 성장하나요?	관심은 드러나지만 답의 범위가 넓다.
좋은 답	입사 초기 수정 작업 뒤에 받는 피드백이 궁금하다. 프로젝트에서 기능 완성 여부만 확인해 같은 지적을 반복한 경험이 있다. 안내 담당자가 있다는 설명은 들었으므로, 이후 어떤 기준으로 다음 업무를 정하는지 알고 싶다. 아직 정해진 절차가 없다면 최근 사례를 가능한 범위에서 듣고 싶다.	확인할 대상, 경험에서 나온 이유, 이미 들은 정보, 대안 질문이 연결된다.

좋은 답의 결론은 “수정 작업 뒤의 피드백을 확인하고 싶다”다. 근거는 완성 여부만으로는 개선점을 알기 어렵다는 점이다. 여기에 자신의 경험을 붙이고, 정해진 절차가 없을 수 있다는 한계와 사례를 듣겠다는 대안을 더한다. 실제 말할 때는 이 내용을 짧게 나누어 전달하면 된다.

면접관: “왜 그 부분을 중요하게 생각하나요?”
지우: “피드백을 다음 작업에서 실행할 수 있어야 같은 실수를 줄일 수 있다고 생각한다. 제 프로젝트에서는 지적을 기록하지 않아 같은 검토 의견을 다시 받았다. 그래서 이후에는 지적과 수정 결과를 함께 남겼다. 팀의 방식이 다르다면 그 방식에 맞춰 개선 결과를 확인하고 싶다.”

면접관이 답하면 준비한 다음 질문으로 바로 넘어가지 않는다. 먼저 핵심을 짧게 확인하고, 판단에 필요한 부분만 한 번 더 묻는다. “업무 담당자가 수정 결과까지 확인한다는 뜻으로 이해했다”처럼 정리하면 자신의 해석이 맞는지도 점검할 수 있다.

이미 들은 답을 의미별로 표시하고 남은 질문을 주제별로 고르면 반복을 줄일 수 있다

피해야 할 것은 주제보다 묻는 방식이다

처우, 근무 시간, 휴가, 근무 장소는 입사 판단에 필요한 정보다. 이를 묻는 행위 자체를 관심 부족으로 볼 필요는 없다. 다만 담당자가 답할 수 있는 범위를 고려한다. 기술 면접관에게 보상 세부 항목을 길게 묻기보다 채용 담당자와 확인할 경로를 정하고, 팀 면접에서는 실제 업무 운영 방식을 묻는 편이 자연스럽다.

공개 자료에 있는 내용을 확인 없이 되묻거나, “야근은 안 하죠”처럼 원하는 답을 유도하거나, 구성원 개인의 평가와 내부 비밀을 요구하는 질문은 피한다. 공개 자료에 설명이 있어도 적용 범위가 불분명하다면 “안내된 근무 방식이 이 직무에도 적용되는지 확인하고 싶다”처럼 미확인 부분을 명시하면 된다.

“질문은 몇 개 해야 하나요”에는 고정된 답이 없다. 남은 시간이 짧다면 가장 중요한 질문 하나를 고른다. 준비한 내용이 모두 설명되었다면 “준비한 질문은 오늘 설명으로 확인했다”라고 말하고, 실제로 도움이 된 설명을 짧게 짚어도 된다. 관심을 증명하려고 이미 들은 답을 다시 요구할 필요는 없다.

최종 면접에서는 선택 기준과 약속의 범위를 확인한다

최종 면접이 항상 같은 형식으로 진행되는 것은 아니다. 기술 내용을 다시 확인할 수도 있고, 함께 일할 때의 기대나 합류 조건을 주로 이야기할 수도 있다. 지원자는 앞선 면접과 설명이 일치하는지, 자신의 기여를 부풀리지 않는지, 모르는 점을 구분하는지 준비해야 한다. 직급이 높은 면접관에게 맞추려고 지원 이유를 바꾸면 오히려 설명의 근거가 약해진다.

깊게 보기: “우리 팀을 선택한 이유는 무엇인가요?”

지원 이유를 확인한 사실과 연결하는 방법
수준	답변	차이를 만드는 지점
나쁜 답	일단 합격하면 어떤 일이든 하겠다.	선택 기준과 업무 이해를 확인하기 어렵다.
보통 답	중고 거래 서비스를 좋아하고 많이 배울 수 있을 것 같아서 지원했다.	관심은 있지만 이 팀과 연결되는 근거가 부족하다.
좋은 답	거래 상태를 사용자에게 일관되게 보여 주는 일을 맡고 싶어 지원했다. 작은 상태 표시도 사용자의 다음 행동에 영향을 주기 때문이다. 과제 프로젝트에서 거래 완료 표시가 늦게 바뀌어 혼란을 준 경험이 있다. 이 팀에서는 작은 수정부터 동료 검토를 받는다고 들었다. 실제 담당 범위는 아직 모르므로, 입사 초기에는 맡은 흐름을 이해하고 검증하는 일부터 기여하고 싶다.	선택의 결론, 이유, 경험, 미확인 범위와 현실적인 출발점이 이어진다.

면접관: “그 이유는 다른 팀에도 해당하지 않나요?”
지우: “그렇다. 서비스 주제만으로 이 팀만의 이유라고 말할 수는 없다. 현재 확인한 차이는 작은 변경부터 동료와 검토하며 적응한다는 방식이다. 제 경험의 부족한 부분과 맞는다고 판단했다. 아직 모든 운영 방식을 확인한 것은 아니므로 오늘 들은 내용까지 함께 보고 선택하려 한다.”

이 답은 지원 이유를 독점적인 이유로 꾸미지 않는다. 공통으로 적용되는 관심과 이 팀에서 확인한 사실을 구분한다. 면접관에게 듣기 좋은 확신보다, 무엇을 근거로 판단했는지 설명하는 편이 후속 질문에도 대응하기 쉽다.

깊게 보기: “희망 처우와 합류 가능일을 알려 주세요”

조건을 이야기할 때 분명히 해야 할 것
수준	답변	차이를 만드는 지점
나쁜 답	다른 곳은 훨씬 많이 준다. 바로 맞춰 주면 내일부터 나올 수 있다.	확인되지 않은 비교와 지킬 수 없는 약속이 섞일 수 있다.
보통 답	팀 기준에 맞추겠다. 일정은 나중에 말씀드리겠다.	실제 제약과 확인 시점을 알기 어렵다.
좋은 답	처우는 맡을 역할과 고정 보상, 변동 보상의 구성을 확인한 뒤 협의하고 싶다. 총액만으로는 조건을 같은 기준에서 비교하기 어렵기 때문이다. 현재 마무리할 프로젝트 일정이 있어 종료 후 합류할 수 있다. 제가 정리한 가능일을 전달하겠다. 팀에서 더 이른 일정이 필요하다면 조정 가능한 범위를 확인해 회신하겠다.	협의 기준, 이유, 실제 제약, 확인 후 답할 범위를 구분한다.

위 답은 조건의 기준을 먼저 확인하는 상황의 예다. 희망 금액을 직접 요청받았고 자신의 기준이 정해져 있다면 그 금액이나 범위를 분명히 말한다. 이때 고정 보상 기준인지, 변동 보상을 포함한 기준인지 함께 설명한다. 범위를 말한다면 하한도 실제 수용 가능한 조건이어야 한다. 준비되지 않았다면 확인할 항목과 회신 가능한 시점을 밝히고 답한다.

면접관: “다른 채용 절차는 어디까지 진행됐나요?”
지우: “다른 절차도 진행 중이며 아직 최종 결정은 하지 않았다. 답변 기한이 정해지면 바로 공유하겠다. 개별 팀의 제안 내용을 자세히 전달하기는 어렵지만, 제 결정 일정은 정확히 말씀드릴 수 있다.”

다른 절차를 숨기거나 압박 수단으로 꾸밀 필요는 없다. 없는 제안을 있다고 말하지 않고, 공유할 수 있는 사실과 결정 시점을 전달한다. 최종 조건은 기억에 의존하지 말고 문서로 확인한다. 총액, 지급 조건, 맡을 역할, 근무 조건, 합류일에 서로 다른 해석이 없는지 살피고, 불분명한 항목은 수락 전에 담당자에게 묻는다.

면접이 끝나면 사실과 해석을 나누어 기록한다

면접 직후에는 세 가지를 남긴다. 실제로 받은 질문과 들은 답, 자신이 어떻게 답했는지, 다음에 바꿀 행동이다. “팀이 나를 마음에 들어 하지 않았다”는 해석이다. “본인 기여를 두 차례 더 물었고, 함께 한 일과 혼자 한 일을 분명히 나누지 못했다”는 기록이다. 후자는 다음 연습의 재료가 된다.

감사 인사는 필수 절차로 생각하지 않는다. 별도 연락을 받지 않는다는 안내가 있다면 그 안내를 따른다. 연락 가능한 공식 경로가 있고 전할 내용이 있다면, 시간에 대한 감사와 도움이 된 설명을 짧게 적는다. 답변을 요구하거나 평가 결과를 재촉하지 않는다. 개인 연락처를 찾아 메시지를 보내지도 않는다.

오늘 면접 시간을 내 주셔서 감사하다. 입사 초기에는 작은 수정의 결과를 함께 검토하며 업무 범위를 넓힌다는 설명이 역할을 이해하는 데 도움이 되었다. 안내받은 다음 절차를 기다리겠다.

이는 담을 내용을 보여 주는 예시다. 실제 메시지는 상대와 사용하는 정중한 호칭과 종결 표현에 맞춘다. 중요한 사실을 잘못 전달했다면 감사 인사 속에 숨기지 말고 무엇을 정정하는지 분명히 적는다. 사소한 표현을 바꾸기 위해 긴 답안을 다시 보내는 것은 피한다.

깊게 보기: “이번 면접을 돌아보면 무엇을 보완하겠나요?”

자기 점검을 다음 행동으로 연결하는 답
수준	답변	차이를 만드는 지점
나쁜 답	너무 긴장해서 전부 망쳤다.	평가가 넓어 무엇을 고칠지 알 수 없다.
보통 답	프로젝트 설명을 더 연습하겠다.	방향은 있지만 연습의 대상과 기준이 없다.
좋은 답	제 기여 범위를 먼저 구분하는 연습이 필요하다. 추가 질문을 받고서야 동료가 맡은 부분을 설명했기 때문이다. 다음에는 제가 결정한 내용과 함께 검토한 내용을 나눠 짧게 답하겠다. 오늘의 부족함이 전체 평가의 이유인지는 알 수 없으므로, 우선 확인 가능한 답변부터 고치겠다.	개선 결론, 관찰 근거, 구체적인 행동, 평가 해석의 한계를 담는다.

면접관: “연습이 나아졌다는 것은 어떻게 확인하겠나요?”
지우: “설명을 들은 사람이 제가 직접 한 일과 동료가 한 일을 구분할 수 있는지 확인하겠다. 녹음한 답에서도 주어가 빠진 부분을 찾아 고치겠다. 길이만 줄여 필요한 근거가 사라지지 않도록 후속 질문도 함께 받아 보겠다.”

탈락한 경우에도 결과만으로 원인을 단정하지 않는다. 피드백을 요청할 수 있는 경로가 있다면 짧게 요청할 수 있지만, 답변이 없을 수도 있다. 받은 피드백 역시 이번 상황에서 관찰된 정보로 다룬다. 기록에서 반복되는 어려움 하나를 고르고, 답변을 수정한 뒤 다시 설명해 보는 과정까지 마쳐야 다음 준비가 된다.

완성 코드

다음 프로그램은 지우가 준비한 질문 일곱 개에서 이미 답을 들은 질문을 제외하고, 팀·일·성장마다 하나씩 고른다. 질문 문장 자체를 비교하지 않고, 질문이 확인하려는 사실을 집합으로 표시한다. 실제 대화를 자동으로 이해하는 도구는 아니다. 면접 메모를 읽은 사람이 의미 표지를 붙인 뒤 실행하는 작은 실험이다.

질문 하나에 여러 사실이 들어 있다면 그 사실을 모두 들었을 때만 중복으로 분류한다. 성장 질문에는 입사 초기 안내와 피드백이 함께 들어 있다. 안내는 들었지만 피드백은 듣지 못했으므로 후보로 남는다. 남은 질문은 원래 목록의 순서대로 선택한다. 목록 순서가 같은 주제 안에서의 우선순위다.

다음 내용을 main.py에 저장한다. Python 3.12 이상에서 표준 라이브러리만 사용하며, 입력이나 네트워크 연결 없이 바로 종료한다. 난수와 현재 시각을 사용하지 않아 같은 코드의 출력은 일정하다.

from dataclasses import dataclass


@dataclass(frozen=True)
class Question:
    topic: str
    text: str
    facts: frozenset[str]


def choose_questions(
    candidates: list[Question],
    heard: frozenset[str],
    topics: tuple[str, ...],
) -> tuple[list[Question], list[Question]]:
    duplicates = []
    remaining = []

    for question in candidates:
        if question.facts and question.facts <= heard:
            duplicates.append(question)
        else:
            remaining.append(question)

    selected = []
    for topic in topics:
        for question in remaining:
            if question.topic == topic:
                selected.append(question)
                break

    return selected, duplicates


def main() -> None:
    candidates = [
        Question(
            "팀", "코드 검토는 어떤 순서로 진행하나요?",
            frozenset({"review"}),
        ),
        Question(
            "팀", "기술 의견이 다를 때 결정 기준은 무엇인가요?",
            frozenset({"decision"}),
        ),
        Question(
            "팀", "결정된 내용을 팀 안에 어떻게 공유하나요?",
            frozenset({"sharing"}),
        ),
        Question(
            "일", "입사 초기에 맡을 업무의 우선순위는 어떻게 정하나요?",
            frozenset({"priority"}),
        ),
        Question(
            "일", "작업이 끝났다고 판단하는 기준은 무엇인가요?",
            frozenset({"completion"}),
        ),
        Question(
            "성장", "입사 초기 안내는 어떻게 진행하나요?",
            frozenset({"onboarding"}),
        ),
        Question(
            "성장", "입사 초기 안내 이후 피드백은 어떻게 받나요?",
            frozenset({"onboarding", "feedback"}),
        ),
    ]
    heard = frozenset({"review", "onboarding"})
    topics = ("팀", "일", "성장")
    selected, duplicates = choose_questions(candidates, heard, topics)

    print("이미 들은 답과 겹쳐 제외한 질문")
    for question in duplicates:
        print(f"- [{question.topic}] {question.text}")

    print("\n주제별로 고른 질문")
    for question in selected:
        missing = ", ".join(sorted(question.facts - heard))
        print(f"- [{question.topic}] {question.text}")
        print(f"  아직 확인할 항목: {missing}")

    deferred = len(candidates) - len(duplicates) - len(selected)
    print(
        f"\n후보 {len(candidates)}개 / 중복 제외 {len(duplicates)}개"
        f" / 선택 {len(selected)}개 / 순서상 보류 {deferred}개"
    )


if __name__ == "__main__":
    main()

줄별 해설

from dataclasses import dataclass는 질문 정보를 묶는 자료형을 만들기 위해 표준 라이브러리의 기능을 가져온다. Question에는 주제, 실제 질문 문장, 확인하려는 사실을 저장한다. frozen=True는 생성 후 필드에 다른 값을 다시 대입하지 못하게 한다. facts도 변경할 수 없는 집합인 frozenset을 사용한다.

choose_questions의 매개변수는 후보 목록, 이미 들은 사실, 출력할 주제 순서다. 함수는 선택한 질문과 중복으로 제외한 질문을 각각 목록으로 반환한다. 어떤 질문이 왜 빠졌는지 따로 볼 수 있어야 잘못 붙인 의미 표지도 찾아낼 수 있다.

첫 번째 for문은 각 후보의 의미 표지를 이미 들은 사실과 비교한다. question.facts <= heard는 질문의 모든 사실이 heard에 포함되는지 확인한다. 사실 하나라도 미확인이면 remaining에 남는다. 앞의 question.facts 검사는 빈 집합을 중복으로 처리하지 않도록 한다. 의미 표지가 없다는 이유만으로 이미 답을 들었다고 판단해서는 안 된다.

두 번째 중첩 for문은 topics의 순서대로 남은 후보를 찾는다. 주제가 맞는 첫 질문을 넣고 break로 안쪽 반복을 끝낸다. 이 때문에 같은 주제의 나머지 질문은 보류된다. 중요도가 같은 질문을 임의로 섞지 않고 작성자가 정한 순서를 유지한다. 해당 주제에 후보가 없으면 아무것도 선택하지 않는다.

main의 후보 목록은 코드 검토와 입사 초기 안내에 대한 중복 질문을 포함한다. 같은 주제에서도 서로 다른 정보를 묻는 후보를 넣어 중복 제외와 개수 제한이 별개임을 확인한다. 보류된 공유 방식과 완료 기준 질문은 가치가 없어서 빠진 것이 아니라 이번 선택의 우선순위에서 뒤에 있기 때문에 빠진다.

heard와 topics는 이번 실험의 고정 입력이다. 집합은 포함 여부를 판단할 때 사용하고, 화면에 표시할 순서는 튜플과 목록으로 정한다. 선택된 질문의 미확인 항목은 차집합으로 구한다. sorted를 거쳐 출력하므로 표지가 여러 개여도 표시 순서가 흔들리지 않는다.

마지막 출력은 전체 후보에서 중복 제외와 선택 개수를 빼 보류 개수를 계산한다. 이 계산은 후보의 주제가 topics에 들어 있고 주제 이름이 중복되지 않는 현재 입력을 전제로 한다. 도구를 확장한다면 주제 오타와 중복 설정을 검사하고, 후보가 없는 주제를 별도로 안내할 수 있다. 마지막 조건문은 파일을 직접 실행할 때 main을 호출한다.

실행 결과

터미널에서 파일을 저장한 디렉터리로 이동해 실행한다.

python3 main.py

예상 출력은 다음과 같다.

이미 들은 답과 겹쳐 제외한 질문
- [팀] 코드 검토는 어떤 순서로 진행하나요?
- [성장] 입사 초기 안내는 어떻게 진행하나요?

주제별로 고른 질문
- [팀] 기술 의견이 다를 때 결정 기준은 무엇인가요?
  아직 확인할 항목: decision
- [일] 입사 초기에 맡을 업무의 우선순위는 어떻게 정하나요?
  아직 확인할 항목: priority
- [성장] 입사 초기 안내 이후 피드백은 어떻게 받나요?
  아직 확인할 항목: feedback

후보 7개 / 중복 제외 2개 / 선택 3개 / 순서상 보류 2개

중복 제외는 질문의 가치에 대한 평가가 아니라 이미 얻은 정보와의 겹침 판단이다. 성장 질문이 남는 이유도 문장이 다르기 때문이 아니라 feedback이 아직 확인되지 않았기 때문이다. 실제 면접에서는 남은 표지에 맞춰 “초기 안내는 설명해 주셨으니, 이후 피드백을 받는 방식이 궁금하다”라고 질문을 좁히면 된다.

실무에서 자주 틀리는 것

사실 하나가 겹치면 질문 전체를 버린다

다음은 후보가 하나이고 들은 사실도 하나인 경우다. 교집합이 있다는 이유로 중복 처리하면 미확인 항목까지 사라진다.

facts = frozenset({"onboarding", "feedback"})
heard = frozenset({"onboarding"})

# 틀린 코드: 일부만 겹쳐도 True가 된다.
duplicate = bool(facts & heard)
print(duplicate)  # True

고친 코드는 질문이 확인하려는 사실을 모두 들었는지 판단한다. 빈 표지는 확인이 필요하다고 보고 남긴다.

facts = frozenset({"onboarding", "feedback"})
heard = frozenset({"onboarding"})

duplicate = bool(facts) and facts <= heard
print(duplicate)  # False

표현이 같을 때만 같은 정보라고 본다

문장 일치만 검사하면 표현이 다른 중복 질문을 놓친다. 다음 두 문장은 같지 않지만 같은 검토 절차를 묻고 있다.

heard_texts = {"변경 사항은 동료가 어떤 순서로 검토하나요?"}
candidate_text = "코드 검토는 어떤 순서로 진행하나요?"

duplicate = candidate_text in heard_texts
print(duplicate)  # False

질문과 답을 읽은 사람이 동일한 사실 표지를 붙이면 문장 차이와 정보 차이를 구분할 수 있다. 다만 검토 절차와 검토 소요 시간까지 모두 review 하나로 묶으면 구분이 너무 거칠어진다. 필요한 정보가 다르면 표지도 나눈다.

heard_facts = frozenset({"review"})
candidate_facts = frozenset({"review"})

duplicate = bool(candidate_facts) and candidate_facts <= heard_facts
print(duplicate)  # True

집합에서 출력 우선순위를 얻으려 한다

집합은 중복을 제거하는 데 적합하지만 질문의 우선순위를 표현하지 않는다. 다음 코드는 원하는 주제 순서를 보장하지 않는다.

topics = {"팀", "일", "성장"}
for topic in topics:
    print(topic)

순서가 필요한 설정에는 튜플이나 목록을 사용한다. 사실 표지 집합을 출력해야 한다면 정렬해서 표시한다.

topics = ("팀", "일", "성장")
for topic in topics:
    print(topic)

답을 들었다는 표시를 너무 일찍 붙인다

질문했다는 사실과 필요한 답을 얻었다는 사실은 다르다. 다음 코드에서는 “상황에 따라 다르다”는 답만 들어도 피드백 방식을 확인한 것으로 처리한다.

heard = set()
asked = "feedback"

heard.add(asked)  # 틀린 처리: 질문했다는 이유만으로 완료한다.

질문 이력과 확인된 사실을 나누어 기록한다. 아래에서는 질문했지만 구체적인 방식은 듣지 못했으므로 heard에 추가하지 않는다. 확인 여부는 사람이 대화 내용을 보고 판단한다.

heard = set()
asked = {"feedback"}
confirmed = set()

heard.update(confirmed)
print("feedback" in asked)  # True
print("feedback" in heard)  # False

한눈에 보기

마지막 대화부터 다음 면접 준비까지의 판단 기준
상황	확인할 것	다음 행동
역질문 준비	팀·일·성장에서 판단에 필요한 정보	구체적인 장면을 묻는 후보를 우선순위대로 적는다.
이미 설명을 들음	질문의 모든 부분이 확인되었는지	전부 확인했으면 제외하고, 일부라면 남은 부분만 묻는다.
최종 면접	지원 이유와 경험 설명의 일관성	확인한 사실, 자신의 기여, 미확인 범위를 구분한다.
처우와 일정 협의	비교 기준과 실제 가능한 약속	담당자에게 조건을 묻고 최종 내용을 문서로 확인한다.
감사 인사	연락 안내와 전달할 내용	공식 경로에서 짧게 전하고 답을 요구하지 않는다.
결과 이후	관찰한 사실과 개선 가능한 행동	원인을 단정하지 않고 답변 하나를 수정해 다시 연습한다.

프로그램이 고른 세 질문은 면접에서 그대로 읽어야 할 대본이 아니다. 남은 시간과 방금 들은 설명에 맞춰 더 줄일 수 있다. 다음 장에서 모의 면접을 진행할 때도 역질문을 따로 외우기보다, 앞선 대화에서 얻은 정보를 반영해 마지막 질문을 고르는 연습을 한다.

연습 문제

완성 코드의 heard에 feedback을 추가하라. 중복 제외, 선택, 보류 개수가 각각 어떻게 바뀌는지 실행 전에 예상하고 이유를 설명하라.
“팀 분위기는 좋은가요”를 팀의 실제 행동을 확인하는 질문으로 바꾸라. 그 질문이 왜 필요한지 자신의 프로젝트 경험을 붙이고, 상대가 구체적인 사례를 공개하기 어려울 때의 대안도 적어라.
처우 안내에서 총액만 들었고 합류일은 아직 확정하지 못했다. 채용 담당자에게 확인할 항목과 자신이 약속할 수 있는 범위를 세 문장으로 작성하라. 금액이나 날짜를 임의로 만들지 마라.
면접 후 “질문이 어려웠고 면접관 반응이 차가웠다”라는 기록을 남겼다. 이를 사실, 해석, 다음 행동으로 나누라. 기억에 없는 사실을 보충하지 말고 무엇을 추가로 기록해야 하는지도 적어라.

정답과 해설

중복 제외는 3개, 선택은 2개, 보류는 2개다. 성장의 복합 질문이 요구하는 onboarding과 feedback이 모두 heard에 들어가므로 그 질문도 제외된다. 남은 성장 후보가 없어 팀과 일에서 하나씩만 선택한다. 7개에서 제외 3개와 선택 2개를 빼면 보류는 2개다. 주제별 후보가 없는데도 이미 답을 들은 질문을 다시 채워 넣지 않는다는 점을 확인한다.
가능한 답은 “의견이 다를 때 합의한 결정과 이유를 어떻게 남기는지 궁금하다”다. 이유에는 “프로젝트에서 구두로 정한 내용을 다르게 기억해 작업을 다시 한 경험이 있다”를 붙일 수 있다. 실제로 겪은 경험이 없다면 꾸미지 않고 준비 과정에서 느낀 궁금증을 설명한다. 사례 공개가 어렵다면 특정 사건 대신 보통 사용하는 기록 방식과 결정 담당자를 묻는다.
가능한 답은 “안내받은 총액에 고정 보상과 변동 보상이 각각 어떻게 포함되는지, 지급 조건은 무엇인지 확인하고 싶다. 현재 마무리할 일정이 있어 합류 가능일을 확정하는 데 필요한 시간을 확인하고 회신 시점을 먼저 전달하겠다. 최종 역할과 근무 조건도 함께 문서로 확인한 뒤 답변하겠다”다. 이미 회신 가능한 시점을 알고 있다면 모호하게 남기지 않고 실제 시점을 전달한다.
“어려웠다”와 “차가웠다”는 현재 기록만으로는 주관적인 평가에 가깝다. 기억나는 질문 문구, 답변을 멈춘 부분, 추가 질문의 내용, 상대가 실제로 한 말을 먼저 적어야 한다. 기억나지 않는 표정이나 발언은 만들어 넣지 않는다. 다음 행동은 떠오르는 질문 하나를 골라 답변의 결론과 근거를 다시 작성하는 것으로 정할 수 있다. 면접관의 반응에서 합격 여부나 탈락 원인을 확정하지 않는 것이 핵심이다.