3P by GN⁺ | ★ favorite | 댓글 3개
  • AI 도구가 코드 작성과 리뷰 영역까지 빠르게 침투하는 상황에서, 면접에서 AI 사용을 기본적으로 배제하고 기초 역량 중심으로 평가해야 함
  • 좋은 면접은 신호 품질(signal quality)회사 비용(cost to company) 두 축으로 평가되며, 두 요소는 완전히 독립적이지 않음
  • 면접 유형은 Take-home, Live exercise, Presentation, Actual work 네 가지로 구분되며, 각각 신호 품질과 비용이 다름
  • AI 코딩으로 인해 take-home은 너무 쉬워지고 리뷰 부담이 커지며, 누출된 문제도 AI가 강력한 코치 역할을 함
  • AI 숙련도는 instrumental skill(도구적 기술) 에 불과하므로, 회사는 foundational skill(기초 역량) 평가에 집중해야 함

핵심 주장

  • AI 모델과 도구의 빠른 진화 속에서 엔지니어가 6개월 후에도 코드를 작성·리뷰할지 의문이 제기되며, 핵심 기술이 사라진다면 면접 방식도 진화해야 하는가라는 질문에서 출발
  • 대부분 기업은 현상 유지를 택했으며, 이 혁명을 주도하는 기업도 포함됨
    • Anthropic의 채용 가이드라인은 take-home을 "별도 지시가 없는 한 Claude 없이" 완료하도록 요구
  • 일부 기업은 AI 사용을 허용·권장·필수화하며, AI 숙련도 자체가 면접의 주제가 되기도 함
  • 결론적으로 면접에서 AI를 일반적으로 배제해야 하며, 면접을 AI에 맞게 조정하는 구체적 방법을 제시

좋은 면접의 두 가지 차원

  • 신호 품질 (Signal quality)

    • 주어진 역량 집합에 대해 강한 후보를 식별하고 노이즈(역할에 비핵심적이거나 쉽게 가르칠 수 있는 요소)를 무시하는 능력
    • 면접 특화 준비에 대한 무력화(Invulnerability to preparation): 성과가 준비량·노력에 좌우되면 그 특성에 대한 신호만 얻게 됨
    • 현실성(Realism): 면접은 일상 업무와 닮아야 하나 그 자체가 목적은 아님. "algorithm & data structure" 면접은 실무에서 직접 쓰이지 않음에도 오랫동안 살아남음
    • 평등(Equality): 사전 도메인 전문성, 유료 멘토링, 시간 여유, 온라인 유출 문제, 최근 경험자 지인 등으로 일부 후보가 더 유리함. 이상적으로는 모두에게 공평한 환경 필요
    • 난이도(Difficulty): 좋은 면접은 다수가 실패할 만큼 충분히 어려움. 최선은 여러 통찰이 필요한 광범위하고 모호한 문제
  • 회사 비용 (Cost to company)

    • 면접 질문은 상당한 시간 투자를 요구: 초안 설계와 실험 승인, 직무·레벨별 스코어카드 작성, 내·외부 후보 대상 테스트, 면접관 문서화·교육
    • 질문과 스코어카드는 지속적으로 보정되므로 투자가 계속 유지되어야 함
    • 난이도(Difficulty): 질문 제작도 어렵지만 충분히 어려운 질문 제작은 더 큰 도전. 너무 쉽거나 너무 어려운 양극단은 모두의 시간 낭비
    • 후보 매력도(Appeal to candidate): 시간이 과도하게 드는 절차나 지루한 질문은 우수 엔지니어를 떠나게 하고 전환율을 떨어뜨림. 질문은 엔지니어링 문화를 드러냄
  • 두 차원은 완전히 독립적이지 않으며, 예컨대 난이도는 양쪽 모두에 영향. 어려운 면접은 강한 후보를 빛나게 하지만 false negative(허위 탈락) 를 유발할 수 있음
  • 면접은 완벽할 필요 없으며 false negative와 false positive는 항상 존재. false negative 식별은 어렵지만, 좋은 온보딩과 명확한 첫 학기 마일스톤으로 false positive를 빠르게 정리 가능

면접 유형 분류

  • Take-home

    • 후보가 (1) 모호한 문제(예: 제품 사양)에 대한 솔루션을 (2) 몇 가지 기술 제약(예: 프로그래밍 언어 목록)을 지켜 제출
    • 종종 후보가 작업을 발표하고 즉석에서 수정하는 review 면접으로 이어짐
    • 신호 품질: (AI 이전) 높음 — 설계·코딩·디테일·테스트 등 광범위한 신호 제공, 6시간 이상 투입은 동기 입증
    • 회사 비용: 중간 — 평가 자동화 가능, 산출물(코드)을 비동기로 리뷰 가능, 다만 후보를 떠나게 할 수 있음
    • AI와 동기 부여된 개인에게 매우 취약
  • Live exercise

    • algorithm & datastructure, live coding, system design, postmortem review 등, 보통 1시간 이상. "Netflix 아키텍처 설계", "rate-limiter 작성" 같은 문제를 면접관 앞에서 즉석 해결
    • 신호 품질: 중간 — 제대로 설계·진행 시 객관적이나 신호가 보통 한 주제에 집중됨
    • 회사 비용: 중간 — 후보 준비에 덜 취약하려면 다양한 질문이 많이 필요
    • 비용 절감을 위해 일부 기업은 자동화 서비스 사용
  • Presentation

    • "주도한 프로젝트 설명", "아키텍처 다이어그램", "~했던 경험" 등으로 후보가 문제와 답을 직접 선택
    • 신호 품질: 낮음 — 실패 모드가 많음
      • 흥미로운 문제를 다뤄본 적 없음(예: 주니어), 지루한 문제 선택, 영향·기여 과장, 발표 준비 부족, 강한 커뮤니케이터지만 실행자는 아님, 면접관의 도메인 지식 부족으로 부정확한 평가
    • 회사 비용: 낮음 — 보정 관점에서 준비할 게 많지 않음
    • "다르게 한다면?" 같은 회고 질문, "요건 X를 바꾸면?" 같은 가설 질문으로 낮은 신호 품질을 완화 가능하며, 이 경우 비보정 live exercise에 가까워짐. 면접관의 노력과 전문성이 더 많이 요구됨
  • Actual work (면접 유형 아님)

    • 1주일간 유급으로 함께 일하는 방식. Linear 같은 기업이 사용
    • 신호 품질: 높음 / 회사 비용: 높음
  • 대부분 기업은 이 유형들을 혼합하며, Live exercise가 우세

질문 유출은 시간 문제 (AI와 무관)

  • 질문 유출은 시간 문제이며, Glassdoor 같은 사이트가 면접 비밀을 모두 나열. 일부 후보는 질문을 팔기 위해 면접을 거치기도 함
  • 무시하면 신호가 약해지고, 면접 성과의 주요 동인이 "우리 면접 절차를 찾아봤는가"로 변질됨
  • 대응 전술

    • 준비 통제(Control the preparation): presentation을 혼합에 포함하거나 정밀한 가이드 제공(예: "시스템 설계는 데이터베이스 중심", "알고리듬은 그래프")으로 공평한 환경 조성
    • 유형별 질문 다양화: 오래된 질문을 정기적으로 보관(archive). 후보가 질문을 정확히 예측하지 못하면 준비 범위를 넓혀야 하며, 이것이 목표. 단 무료는 아님
    • 유출 난이도 상승(Make it harder to leak): 온사이트 진행, 화이트보드 사용, 가장 취약한 질문을 절차 후반부에 배치(후보 수가 적어 유출 확률 하락)

AI 코딩이 현재 면접 모델을 위협

  • (1) Take-home은 후보에겐 너무 쉽고 회사엔 너무 비싸짐

    • 2026년 대부분 제출물은 AI 생성 또는 AI 보조일 가능성이 높고, 현재 버티는 과제도 다음 모델 릴리스에 풀리는 것은 시간 문제
    • 결과적으로 대부분 후보가 첫 단계를 통과하므로 리뷰에 많은 시간이 듦. AI가 생성한 제출물을 AI로 리뷰하는 것은 불합리
    • AI 코딩은 면접 비용을 피면접자에서 면접관으로 이동시킴
      • Brandolini의 법칙 인용: 나쁜 코드를 반박하는 데 드는 에너지는 그것을 만드는 데 드는 에너지보다 한 자릿수 더 큼
  • (2) 코드 작성 시간이 줄면 live-coding 비중을 낮추는 게 자연스러움

    • 기계어를 작성하지 않고 고수준 언어를 쓰듯, 면접에서 허용하는 도구도 일상 업무와 맞추는 것이 합리적이라는 관점
  • (3) 질문이 유출되면 AI는 강력한 코치

    • 과거엔 질문을 찾고 준비하는 데 시간·자원이 많이 들었으나, 이제 AI로 가장 강력하고 저렴한 도움을 얻음

고전적 학교 평가 모델이 기술에 저항한 방식

  • 프랑스 고등학교·대학 시험은 대체로 동일한 형태
    • 자료(강의·책 등) 반입 불가, 도구(특히 계산기) 거의 미허용, 사전에 내용 비공개, 추측 불가(매 시험이 다르고 1회만 사용), 광범위하고 모호한 문제
    • 프랑스 문학 시험의 정수는 dissertation으로, 한 문장 주제로 5~10페이지 에세이를 작성하며 1830년부터 존재. 과학 시험도 모호한 문제 3~4개를 푸는 유사 형태
  • take-home, 객관식 지식 문제, 그룹 과제, 발표 등 다른 평가 형태로 보완되나 예외일 뿐 원칙은 아님
  • 분류 재적용
    • 신호 품질: 높음 — 준비 공간이 매우 넓고 지속적 노력 필요
    • 비용: 매우 높음 — 시험마다 새 주제·채점 가이드 설계, 모든 후보가 동시에 같은 시험(기업 면접엔 전혀 비현실적)
  • 흥미로운 점은 복사·붙여넣기, 인터넷, 계산기, 솔버 등 인지 도구의 비약적 발전에도 이 모델이 크게 변하지 않았다는 것
    • 교육은 그때그때의 도구가 아닌 기초 역량에 집중해야 하며, 이는 기억(mneme)보다 판단(phronesis)에 초점을 둔 아리스토텔레스적 모델과 일치

기업이 면접 중 AI 사용을 제한해야 하는 이유

  • 기초 역량 vs 도구적 역량의 구분

    • Foundational traits & skills는 구축이 어렵거나 비용이 큰 역량·태도·습관
      • 원초적 지적 능력, 수년간 학습으로 얻은 깊은 전문성(초당 수백만 요청의 분산 시스템, 수백 개 마이크로서비스를 모놀리스로 전환 등), 2차적 추론, 직업 윤리·integrity·회복력 같은 덕목
      • 문제를 식별·추상화·해결하게 하는 내재화된 지식(fundamentals)으로, 더 많은 기술을 쌓을 토대를 제공. "똑똑하니 알아서 할 것"이라 말하게 함
    • Instrumental skills는 저렴하거나 빠르게 키울 수 있음
      • 프로그래밍 언어 중급 숙련, 텍스트 에디터 적절히 사용, 문서 검색, AI 프롬프트 조정
    • 면접에서는 여러 도구적 기술 신호를 통해 후보의 기초 특성(생산성 투자 의지, 구조적 학습)을 검증하는 경우가 많음
  • Rationale 1: AI 숙련도는 기초 역량이 아님

    • 엔지니어링 도구는 꾸준히 발전했으나 면접은 대체로 동일하게 유지됨(low-code 면접 유형 없음, 시스템 설계는 대부분 기본·비관리형 기술 사용)
      • 최고의 기업은 단일 도구 숙련도를 찾지 않으며, LLM 부상으로 Expert Generalist의 중요성이 더 커짐
    • 프로그래밍 언어 전문성이 면접에서 크게 중요하지 않은 이유도 동일. 언어는 문제 해결이라는 상위 목적을 위한 도구일 뿐
    • AI 사용도 마찬가지로, prompt/context engineering, MCP/skills 정의, multi-agent workflow, harness engineering 등 미묘한 기술이 필요하지만 이는 도구적 기술이며, 코드 작성·리뷰·확장 가능 아키텍처 설계에 필요한 동일한 기초 역량을 요구
    • 기업은 두뇌를 채용하지, AI 에이전트에 무심코 지시를 입력하는 손을 채용하지 않음
    • 리뷰와 생산은 동전의 양면으로, 코드·아키텍처·분석 리뷰는 작성·설계·분석과 유사한 역량을 요구. 비즈니스 요구사항을 생성·검증하려면 사람이 필요하므로 코드 리뷰는 곧 사라지지 않음(충분히 상세한 스펙은 곧 코드)
  • Rationale 2: AI는 기초 특성·역량을 가림

    • Peter Drucker 인용: 손만 고용할 수 없으며 사람 전체가 함께 옴
    • Lewis Mumford의 구분 활용 — tool(인간 노동자가 주도) vs machine(자체 논리로 작동하며 agency를 지님). AI 사용이 과도하면 엔지니어 고유 기여와 AI 모델 기여를 구분하기 거의 불가능
    • AI를 "tool"이 아닌 "machine"처럼 쓰는 엔지니어를 경계해야 함. AI는 강력한 자동완성을 넘어선 생산성 도약이며, 사고 대부분을 외부화할 수 있음. "taste" 같은 인간 고유 영역도 위협받아 Fitts' list도 낡아 보임
    • Derrida가 분석한 Plato의 pharmakon처럼 AI는 치료제(반복 리팩터 자동화, 라이브러리 특이점 학습 시간 절약)이자 독(기초 역량 위축 위험)
    • AI를 과도하게 강조하는 면접은 인간이 아닌 모델("machine")을 평가할 위험. 인간 추론을 면접의 주제로 강조하는 과제 설계 필요
  • Rationale 3: AI는 너무 빠르게 진화

    • Arthur Mensch(Mistral CEO)에 따르면 AI 모델은 12개월마다 약 1년치 소프트웨어 엔지니어링 경험을 얻음. AI 에이전트를 인턴에 비유하던 농담은 더 이상 들리지 않음
    • 대부분 기업은 기초 역량을 강제하는 AI 저항 질문을 지속 생성·유지할 여력이 없음. 모델이 매월 진화하고 모든 모델에 접근할 수도 없는 상황에서 최고 모델에 계속 저항하는 질문 제작은 지는 싸움
      • Anthropic의 "Designing AI resistant technical evaluations"는 후보가 아닌 AI와 "싸우는" 사례 연구
    • 더 어려운 take-home 제작은 계산기를 허용하면서 더 어려운 암산을 내는 것과 유사
    • AI 모범 사례도 매월 진화하며, 모델이 지시 이해에 능해지면서 prompt engineering의 중요성이 줄어듦. 후보의 최신 기법 숙지 여부는 유용한 신호가 아님
    • 반면 fundamentals는 정의상 변하지 않음

반론에 대한 답변

  • 데이터가 없다는 지적에 대해: (1) 통계적 유의성을 갖춘 진짜 실험(무작위 대조 시험)은 거의 불가능하며 그것이 만드는 false negative를 감수할 기업은 없음 (2) 대부분 면접 설계 결정은 임상시험식 실험이 아닌 추상적 추론에 기반
  • AI로 부정행위(예: 면접 중): 명시적으로 금지했다면 AI 도구 사용은 즉시 탈락 사유
    • Warren Buffett 인용: 채용 시 integrity, intelligence, energy를 보며, integrity가 없으면 나머지 둘이 사람을 망침. integrity 없는 사람을 뽑는다면 차라리 멍청하고 게으르길 바라게 됨
  • AI로 후보를 평가해야 하는가: 안 됨. (1) 윤리적으로 잘못됨 — 지식 노동자인 인간을 채용하는데 기계가 모든 것을 평가할 수 없음 (2) AI 평가는 비결정적이고 환각으로 알려져 있어 결국 AI의 평가를 다시 리뷰해야 함

기업을 위한 구체적 권고

  • 대부분의 면접에서 AI 사용을 허용하지 말 것. 특정 도구를 과도하게 강조하지 말고 기초 역량에 집중
  • Live exercise에 투자할 것. 가짜·지루·저신호일 필요 없고 짧을 필요도 없음. data structure & algorithm 면접을 재검토할 것 — 여전히 가장 지적으로 도전적임. 인간의 노력을 요구하는 과제를 설계하고, 단일 질문 과잉 준비를 막기 위해 질문을 많이 보유
  • 면접 유형을 혼합해 비용 효율적으로 광범위한 신호 확보
  • Take-home을 조정할 것. AI 사용을 명시적으로 금지하거나, 허용하되 AI 산출물 리뷰에 시간을 낭비하지 말 것. take-home은 반드시 그에 기반한 live exercise로 이어지게 하여 후보가 작업 발표, 트레이드오프 접근, 요건 변경, 확장성 등을 설명하도록 함
  • 리뷰 역량을 평가하는 면접을 최소 하나 둘 것. 제작 비용이 낮고 흥미로운 신호를 주며 후보에게 부담이 덜함. 예: AI 계획, postmortem, 기존 코드베이스(Bug squash), 제품 요구사항 문서, 트레이드오프 분석, 시스템 아키텍처 리뷰
  • 후보를 온사이트로 부르는 것을 고려. 부정행위를 막는 가장 단순한 방법이며 질문 유출도 다소 어렵게 만듦. 단 RTO(사무실 복귀) 기업에만 해당
  • 명확한 면접 준비 가이드를 제공해 공평한 환경 조성

댓글과 토론

저한텐 1주 같이 일하기 좋은 것 같아요

라는 글도 AI로 썼겠지 ㅋㅋ

어짜피 업무할때 AI를 쓸텐데 그걸 배제하는건 의미가 있나 싶네요, 차라리 원격 면접을 없애고, 현장으로만 운영하며, 현장에서 어떻게 AI를 쓰고 사고하는지 잘 설계된 질문들과 모니터링으로 판단하는게 AI시대에 더 맞지 않을까요?

같은 문제라도 어떻게 프롬프트를 보내는지 보면 그 사람에 대해서 많은걸 알수 있지요.