자신보다 뛰어난 사람을 채용하는 법 2026 전문성 평가 기준

2026년 5월 7일 기준, 리더 채용과 AI 에이전트 도입에서 어려운 지점은 같다. 내가 그 분야 전문가가 아닌데, 상대가 진짜 잘하는지 판단해야 한다는 점이다. 마케팅 리더를 뽑는 개발자 CEO도 그렇고, 보안 에이전트를 붙이는 작은 팀도 그렇다. 정답을 직접 채점할 수 없으면 평가 기준을 바꿔야 한다.

Jason Cohen은 2026년 4월 19일 A Smart Bear에 쓴 글에서 이 문제를 채용 관점으로 풀었다. GeekNews 요약도 같은 핵심을 잡았다. 전문지식 자체를 맞히려 들지 말고, 후보가 우리 회사의 맥락을 바꾸는지 봐야 한다는 것이다. 면접이 끝났을 때 바로 실행하고 싶은 아이디어가 남는가. 실제 문제를 던졌을 때 질문이 날카로워지는가. 레퍼런스 체크에서 이 사람이 빛나는 환경과 망가지는 환경이 선명해지는가.

이 글은 그 채용 원칙을 TECHTAEK 방식으로 바꾼 글이다. 사람 채용에만 쓰지 않는다. 외주 개발자, fractional CMO, 보안 컨설턴트, AI 코딩 에이전트, 리서치 에이전트 평가에도 같은 틀을 쓴다. 전문성을 모를 때 필요한 것은 더 어려운 면접 질문이 아니다. 작은 실제 문제와 관찰 가능한 증거다.

오늘 먼저 잡을 판단

전문성을 모를 때는 후보에게 정답 퀴즈를 내면 안 된다. 내가 정답을 모르기 때문이다. 대신 우리 맥락을 얼마나 빨리 이해하는지, 내 문제를 얼마나 구체적으로 바꿔주는지, 실행 뒤 어떤 검증 루프를 제안하는지 봐야 한다. 이 세 가지는 비전문가도 관찰할 수 있다.

사람 후보라면 이렇게 본다. 면접 중에 우리 팀의 실제 병목을 더 정확히 설명해주는가. 내가 놓친 제약을 질문으로 끌어내는가. 채용 여부와 별개로 이번 주에 바로 해보고 싶은 아이디어를 남기는가. 전문 용어가 아니라 우리 상황에 맞춘 선택지를 주는가.

AI 에이전트도 똑같다. 벤치마크 점수만 보지 않는다. 우리 저장소 구조를 읽고, 기존 유틸을 재사용하고, 위험한 변경 앞에서 멈추고, 결과를 검증하는가. 잘 모르는 영역에서 그럴듯한 답을 길게 쓰는 에이전트는 사람 후보와 똑같이 위험하다. 말은 유창한데 맥락 적용이 약하면 운영비만 늘어난다.

한 줄 기준은 이렇다. 나보다 뛰어난가를 묻기 전에 우리 맥락을 나보다 더 선명하게 만들었는가를 본다. 이 질문은 꽤 쓸 만하다. 사람에게도 먹히고, 에이전트에게도 먹힌다.

왜 전문성 없는 평가는 자꾸 망가질까

전문성을 모르는 상태에서 사람을 평가하면 두 가지 유혹이 생긴다. 첫째, 더 어려운 질문을 만들고 싶어진다. 둘째, 말이 유창한 사람을 실력자로 착각하기 쉽다. 문제는 두 방법 모두 채점자가 약하다는 것이다.

예를 들어 개발자가 마케팅 임원을 뽑는다고 하자. 수요 창출, 포지셔닝, 세그먼트, 파이프라인, 브랜드, 세일즈 협업 같은 말을 들으면 그럴듯하다. 하지만 그 답이 우리 회사 단계에 맞는지 판단하기 어렵다. 대기업용 답을 초기 스타트업에 붙이면 멋있지만 무겁다. 초기 팀용 답을 성숙한 조직에 붙이면 빠르지만 허술할 수 있다.

AI 에이전트도 비슷하다. 에이전트가 테스트를 추가했습니다, 보안을 강화했습니다, 리팩터링했습니다라고 말하면 좋아 보인다. 하지만 진짜 기존 규칙을 읽었는지, 같은 유틸을 또 만들지 않았는지, 위험한 파일을 건드리지 않았는지 봐야 한다. 여기서 평가자는 모델 내부를 모른다. 그래서 결과물과 과정 로그를 봐야 한다.

전문성 없는 평가는 권위에 기대면 위험하다. 큰 회사 출신, 유명 모델, 높은 점수, 화려한 포트폴리오는 출발점일 뿐이다. 그 사람이 지금 우리 문제에 맞는지는 별도 검증이다. 도구도 마찬가지다. 좋은 모델이라고 해서 우리 워크플로에 바로 좋은 것은 아니다.

그래서 평가 질문은 바뀌어야 한다. 이 사람이 정답을 아는가보다 이 사람이 우리 문제를 더 좋은 형태로 바꾸는가가 먼저다. 이 에이전트가 똑똑한가보다 이 에이전트가 우리 시스템 안에서 안전하게 성과를 내는가가 먼저다. 말하자면 지식 퀴즈에서 운영 관찰로 넘어가는 것이다.

기준 1: 바로 실행하고 싶은 아이디어가 남는가

좋은 후보는 면접이 끝난 뒤 할 일을 남긴다. 그 할 일은 거창할 필요가 없다. 오히려 작고 구체적일수록 좋다. 예를 들어 고객 이탈 원인을 인터뷰 5개로 확인하자 같은 수준이면 충분하다.

나쁜 신호는 반대다. 말은 많았는데 내일 무엇을 바꿀지 모르겠다. 프레임워크 이름은 많이 나왔는데 우리 팀의 제약과 연결되지 않는다. 자료를 찾아보면 어디서 들어본 말이 많다. 그럴 때는 전문성보다 발표 능력을 보고 있을 가능성이 크다.

AI 에이전트 평가에서도 이 기준을 쓸 수 있다. 좋은 에이전트는 작업을 끝낸 뒤 다음 검증 행동을 남긴다. 예를 들어 이 변경은 결제 플로우와 연결되어 있으니 e2e 테스트를 먼저 돌려야 한다고 말한다. 또는 이 유틸은 이미 있는 helper를 재사용했고, 새 추상화는 만들지 않았다고 근거를 남긴다.

그냥 긴 요약을 남기는 에이전트는 아직 부족하다. 작업 이후 사람이 무엇을 봐야 하는지, 어떤 위험이 남았는지, 어떤 조건에서 롤백해야 하는지 알려줘야 한다. 사람 리더와 AI 에이전트 모두 여기서 갈린다. 실행 가능한 아이디어는 평가자의 전문성 부족을 줄여준다.

실전 질문은 이렇게 바꾼다.

대상	덜 좋은 질문	더 좋은 질문
리더 후보	이 분야에서 제일 중요한 전략은 뭔가요?	우리 팀의 현재 병목을 듣고 이번 주에 바꿀 행동 3개를 제안해 주세요.
외주 개발자	React 잘하세요?	이 화면에서 유지보수 리스크가 큰 부분을 20분 안에 짚어 주세요.
AI 코딩 에이전트	이 버그 고쳐줘.	원인 후보, 수정 범위, 테스트 방법, 건드리지 않을 파일을 먼저 제안해 줘.
리서치 에이전트	시장 조사해 줘.	출처 등급을 나누고, 결정에 바로 쓰는 표로 요약해 줘.

핵심은 같은 방향이다. 상대가 우리 맥락에 들어와서 다음 행동을 선명하게 만드는지 본다. 그게 없으면 아직 검증이 끝난 게 아니다.

기준 2: 실제 문제를 던졌을 때 질문이 좋아지는가

전문성을 모를 때 가장 좋은 평가 재료는 실제 문제다. 가상의 완벽한 케이스보다 지금 팀이 겪는 애매한 문제를 던지는 편이 낫다. 예쁘게 포장된 케이스 스터디보다 지저분한 현실이 더 많은 것을 보여준다. 현실은 친절하지 않아서 평가에 쓸모가 있다.

예를 들어 마케팅 리더 후보에게 이렇게 묻는다. 우리 블로그는 글 수가 많은데 글당 수익이 낮다. 무엇부터 확인하겠나? 좋은 후보는 바로 정답을 말하기보다 질문을 한다. 트래픽 소스, 검색 의도, 전환 경로, 광고 위치, 글 클러스터, 발행 빈도, 리라이트 이력부터 물을 것이다. 그 질문이 좋으면 이미 절반은 검증된 셈이다.

AI 에이전트도 실제 문제를 줘야 한다. 깨끗한 예제 저장소보다 어제 실패한 테스트, 애매한 로그, 기존 규칙이 많은 폴더가 낫다. 좋은 에이전트는 바로 고치기 전에 작업 범위를 좁힌다. 나쁜 에이전트는 자신감 있게 넓게 고친다. 대부분의 사고는 그 자신감에서 시작한다.

실전 평가에서는 다음 순서가 좋다.

실제 문제 하나를 준다.
배경 정보는 일부러 과하게 주지 않는다.
먼저 물어보는 질문을 관찰한다.
가정과 모르는 부분을 표시하는지 본다.
작은 실행안과 검증 방법을 요구한다.
결과보다 사고 과정을 기록한다.
마지막에 우리 팀에서 이 방식을 쓰려면 무엇이 위험한가를 묻는다.

이 방식은 사람에게도 좋고 에이전트에게도 좋다. 전문성을 직접 채점하지 않아도 된다. 질문 품질, 가정 표시, 범위 조절, 검증 습관은 비전문가도 볼 수 있다.

기준 3: 전체 조직을 끌어올리는가

Jason Cohen 글의 좋은 지점은 리더를 자기 부서 안에 가두지 않는다는 점이다. 뛰어난 리더는 마케팅, 세일즈, 엔지니어링 같은 자기 영역만 잘하는 사람이 아니다. 목표 설정, 의사결정, 커뮤니케이션, 갈등 처리, 조직 구조 같은 공통 운영 역량도 가져온다. 이건 TECHTAEK 관점에서 아주 중요하다.

AI 에이전트도 마찬가지다. 좋은 에이전트는 자기 작업만 끝내지 않는다. 팀의 작업 방식도 조금 더 낫게 만든다. 예를 들어 반복되는 실수를 발견하면 체크리스트를 제안한다. 기존 문서가 낡았으면 업데이트 후보를 남긴다. 테스트가 빈 구간을 발견하면 다음 작업의 우선순위를 바꾼다.

다만 여기서 조심할 점이 있다. 조직을 끌어올린다는 말이 모든 곳을 건드린다는 뜻은 아니다. 좋은 사람은 영향 범위를 넓히되, 변경 범위는 조심스럽게 잡는다. 좋은 에이전트도 마찬가지다. 규칙을 읽고, 소유권을 확인하고, 필요한 만큼만 고친다.

평가표로 바꾸면 이렇다.

관찰 항목	좋은 신호	위험 신호
목표 이해	문제를 팀 목표와 연결한다	자기 전문영역 언어만 반복한다
질문 방식	제약과 우선순위를 먼저 묻는다	바로 해결책부터 말한다
실행 범위	작은 실험과 검증을 제안한다	대규모 개편부터 제안한다
팀 영향	다른 팀이 이해할 언어로 설명한다	자기 영역 사람만 알아듣는다
운영 습관	기록, 책임자, 후속 점검을 남긴다	좋은 말만 남기고 흐지부지된다

사람 후보를 볼 때도 이 표를 쓴다. AI 에이전트를 볼 때도 이 표를 쓴다. 특히 좋은 말만 남기고 흐지부지는 사람과 에이전트 모두에게 매우 흔하다. 좋은 말은 무료지만 운영은 유료다.

기준 4: 레퍼런스 체크는 능력 검증보다 환경 검증이다

레퍼런스 체크는 보통 이상하게 작동한다. 후보가 좋은 말 해줄 사람을 고른다. 그러면 우리는 좋은 말을 듣는다. 그리고 모두가 예의 바르게 시간을 쓴다. 이러면 검증이라기보다 의식에 가깝다.

더 나은 방식은 환경을 묻는 것이다. 이 사람이 최고로 잘하는 환경은 무엇인가. 반대로 힘이 빠지는 환경은 무엇인가. 본인이 너무 자연스럽게 해서 강점인지 모르는 강점은 무엇인가. 이 질문은 능력 점수보다 환경 적합성을 보여준다.

AI 에이전트에는 레퍼런스 체크가 없다고 생각하기 쉽다. 하지만 비슷한 것은 있다. 공개 이슈, 릴리스 노트, 실패 사례, 벤치마크 설명, 실제 사용 로그, 사내 파일럿 결과다. 특히 벤치마크 하나보다 실패 사례가 더 쓸모 있다. 어디서 망가지는지 알아야 우리 환경에 맞는지 판단할 수 있다.

사람과 에이전트 모두에게 묻는 환경 질문은 이렇게 만들 수 있다.

질문	사람 후보에게 보는 것	AI 에이전트에게 보는 것
최고로 잘하는 환경은?	목표, 권한, 팀 성숙도, 속도 선호	저장소 크기, 테스트 존재, 권한 범위, 도구 연결
망가지는 환경은?	모호한 목표, 정치적 조직, 과도한 승인	모호한 요구, 부족한 테스트, 넓은 쓰기 권한
자연스러운 강점은?	질문력, 구조화, 빠른 실행, 갈등 조정	범위 제한, 재사용, 로그 요약, 검증 제안
필요한 보호장치는?	온보딩, 목표 문서, 의사결정권	sandbox, approval gate, read-only scan, diff review

여기서 중요한 것은 약점 없는 대상을 찾는 게 아니다. 그런 대상은 없다. 대신 지금 우리 환경에서 강점이 빛나고 약점이 터지지 않을 조건을 찾는다. 채용도 도입도 결국 환경 매칭이다.

기준 5: 잘못 뽑았을 때 빨리 알아차리는가

어떤 평가법도 완벽하지 않다. 면접에서 훌륭했는데 실제로 안 맞는 사람이 있다. 데모에서는 멋졌는데 우리 저장소에서는 삐걱대는 에이전트도 있다. 문제는 오판 자체보다 오판을 방치하는 것이다.

사람 채용에서는 이런 신호를 본다. 내가 직접 하는 편이 더 빠르다고 계속 느낀다. 좋은 팀원들이 영감을 받기보다 불평을 쌓는다. 후보가 가져온 방식이 실제 산출물로 이어지지 않는다. 회의는 늘었는데 결정은 느려진다.

AI 에이전트 도입에서는 이런 신호를 본다. 사람이 매번 결과를 다시 써야 한다. 작은 작업마다 컨텍스트와 비용이 과하게 든다. 기존 규칙을 읽지 않고 같은 실수를 반복한다. 테스트 없이 자신감 있는 변경을 만든다. 위험한 권한을 달라고 자주 요구한다.

초기 2주 관찰표를 만들면 훨씬 낫다.

기간	사람 리더	AI 에이전트
1일차	질문의 질과 맥락 이해	저장소 읽기, 파일 범위 제안
3일차	작은 실행안과 팀 반응	작은 변경 성공률, 테스트 통과
1주차	반복 가능한 운영 리듬	같은 실수 재발 여부, 로그 품질
2주차	팀이 더 선명해졌는가	사람이 검수할 일이 줄었는가

이 표의 핵심은 빨리 작게 보는 것이다. 6개월 뒤에 이상한데라고 말하면 이미 비싸다. AI 도구도 월말 청구서가 온 뒤에야 느끼면 늦다. 사람도 도구도 파일럿 기간의 관찰 항목을 미리 정해야 한다.

리더 후보와 AI 에이전트를 같은 표로 보는 이유

사람과 에이전트를 완전히 같다고 말하려는 게 아니다. 사람은 책임, 맥락, 감정, 관계, 윤리의 주체다. 에이전트는 도구다. 이 차이는 분명히 둬야 한다.

다만 운영 평가에서는 닮은 지점이 있다. 둘 다 내가 직접 못 하는 일을 맡기려고 부른다. 둘 다 초기에는 말과 데모가 실제보다 좋아 보일 수 있다. 둘 다 우리 맥락을 못 읽으면 비용이 커진다. 둘 다 잘못 들이면 기존 팀의 속도를 떨어뜨린다.

그래서 평가표를 공유할 수 있다. 질문력, 맥락 적용력, 실행 범위, 검증 습관, 실패 대응. 이 다섯 가지는 사람과 에이전트 모두에게 통한다. 특히 AI 에이전트 시대에는 이 표가 더 중요해진다. 도구가 사람처럼 말하기 시작하면, 사람은 말솜씨를 실력으로 착각하기 더 쉬워진다.

운영자의 일은 화려한 답을 고르는 것이 아니다. 작게 맡기고, 결과를 보고, 기록을 남기고, 권한을 천천히 넓히는 것이다. 이건 채용에서도 도입에서도 꽤 재미없는 방식이다. 하지만 재미없는 방식이 보통 덜 터진다. 시스템 운영은 원래 약간 심심해야 오래 간다.

평가 질문 10개

면접이나 파일럿에서 바로 쓸 수 있는 질문을 정리하면 이렇다.

우리 상황을 듣고 가장 먼저 확인할 제약은 무엇인가.
지금 설명한 문제에서 내가 잘못 보고 있을 가능성은 무엇인가.
이번 주에 바로 해볼 수 있는 작은 실험은 무엇인가.
이 실험이 실패했다는 신호는 무엇인가.
당신이 이 문제를 해결했던 실제 사례는 무엇인가.
이 문제에서 모르는 부분은 무엇인가.
이 일을 맡기려면 어떤 권한과 어떤 보호장치가 필요한가.
어떤 환경에서는 당신의 방식이 잘 안 맞는가.
2주 뒤 우리가 좋아졌는지 무엇으로 판단할까.
이 일을 경쟁사가 당신에게 맡기면 우리가 걱정해야 할 점은 무엇인가.

AI 에이전트에게도 거의 그대로 쓴다. 다만 표현을 바꾼다. 당신 대신 이 작업이라고 쓰면 된다. 예를 들어 이 작업에서 모르는 부분과 가정을 먼저 표시해 줘라고 요청한다. 또는 수정 전 읽을 파일, 수정할 파일, 건드리지 않을 파일을 나눠 줘라고 한다.

질문은 많아 보이지만 구조는 단순하다. 맥락을 묻고, 작은 실행을 묻고, 실패 신호를 묻고, 보호장치를 묻는다. 이 네 가지를 못 답하면 아직 맡기기 이르다. 사람이면 더 면접해야 하고, 에이전트면 권한을 줄여야 한다.

실전 운영표

팀에서 실제로 쓰려면 표 하나로 줄이는 게 좋다. 아래 표를 Notion, Obsidian, Google Sheet 어디든 넣어두면 된다. 후보자마다, 에이전트마다 한 줄씩 적는다. 말로만 기억하면 나중에 다 미화된다.

항목	1점	3점	5점
맥락 이해	일반론 반복	일부 제약 반영	우리 상황을 더 선명하게 재정의
질문 품질	질문 거의 없음	확인 질문 몇 개	핵심 제약을 찌르는 질문
실행안	큰 전략만 말함	작은 액션 일부	이번 주 실행 가능한 실험 제안
검증 루프	성공 기준 없음	지표 일부 있음	실패 신호와 후속 조치까지 제시
범위 조절	넓게 바꾸려 함	일부 범위 제한	작게 시작하고 권한 단계화
기록 습관	말로 끝남	요약 남김	결정, 가정, 리스크, 다음 행동 기록
환경 적합성	잘 맞는 조건 불명확	일부 조건 설명	빛나는 환경과 망가지는 환경이 명확

합산 점수보다 중요한 것은 낮은 항목이다. 특히 검증 루프와 범위 조절이 낮으면 조심해야 한다. 똑똑하지만 넓게 망가뜨리는 사람과 에이전트가 제일 피곤하다. 속도는 빠른데 뒤처리가 느리면 총속도는 느리다.

결과	판단
30점 이상	작게 맡겨볼 수 있다
24-29점	범위와 보호장치를 줄이고 파일럿
18-23점	추가 검증 필요
17점 이하	지금 맡기면 운영비가 커질 가능성

AI 에이전트 평가에 붙이는 추가 게이트

사람 후보와 달리 AI 에이전트에는 권한 게이트가 필요하다. 좋은 말을 하는지보다 어떤 권한으로 어디까지 실행하는지가 더 중요하다. 특히 코드, 데이터, 결제, 고객정보, 운영 서버가 연결되면 말이 아니라 경계가 먼저다. 경계 없는 자동화는 편리함의 탈을 쓴 미완성 운영이다.

처음에는 읽기 전용으로 시작한다. 두 번째는 작은 패치로 제한한다. 세 번째는 테스트가 있는 영역만 맡긴다. 네 번째는 승인 후 쓰기 권한을 준다. 다섯 번째는 로그와 롤백 경로를 확인한 뒤 반복 작업을 맡긴다.

권한 확장표는 이렇게 둔다.

단계	허용	금지
0단계	요약, 파일 찾기, 리스크 목록	파일 수정
1단계	단일 파일 작은 수정	DB, 결제, 배포 파일 변경
2단계	테스트 포함 패치	운영 비밀값, 고객 데이터 접근
3단계	PR 초안 작성	자동 머지, 자동 배포
4단계	반복 작업 자동화	승인 없는 프로덕션 변경

이 표는 사람에게도 간접적으로 쓸 수 있다. 새 리더에게도 첫 주부터 모든 권한을 주지 않는다. 관찰하고, 작은 결정을 맡기고, 결과를 보고, 책임 범위를 넓힌다. 믿음은 중요하지만 운영에서는 단계가 더 중요하다.

흔한 실수

첫 번째 실수는 유명한 사람이나 유명한 도구를 바로 신뢰하는 것이다. 명성은 참고 자료다. 우리 환경 적합성의 증거는 아니다. 유명한 사람이 우리 팀을 느리게 만들 수도 있고, 좋은 모델이 우리 저장소에서는 실수를 반복할 수도 있다.

두 번째 실수는 면접 질문을 너무 일반적으로 만드는 것이다. 일반 질문은 일반 답을 만든다. 실제 문제를 줘야 실제 사고가 나온다. AI 에이전트도 마찬가지다. 좋은 코드로 고쳐줘보다 이 테스트 실패를 이 범위 안에서 고쳐줘가 낫다.

세 번째 실수는 레퍼런스 체크를 칭찬 수집으로 쓰는 것이다. 칭찬은 이미 예상된 결과다. 환경 질문을 해야 한다. 어디서 빛나는지, 어디서 무너지는지, 어떤 보호장치가 필요한지 물어야 한다.

네 번째 실수는 파일럿 없이 권한을 크게 주는 것이다. 사람도 도구도 작은 책임부터 맡기는 게 낫다. 처음부터 큰 권한을 주면 실패했을 때 원인을 분리하기 어렵다. 큰 실패는 대부분 작은 검증을 건너뛴 결과다.

다섯 번째 실수는 오판을 오래 끄는 것이다. 아닌 것 같다는 신호가 반복되면 빨리 줄여야 한다. 사람이면 역할을 다시 맞추거나 정리해야 하고, 에이전트면 권한을 줄이거나 워크플로에서 빼야 한다. 정이든 비용이든 이미 쓴 돈이든, 방치 비용보다 싸지 않다.

FAQ

Q. 전문성을 모르면 결국 운 아닌가. A. 운이 섞이는 것은 맞다. 그래서 정답 채점 대신 관찰 가능한 신호를 봐야 한다. 질문 품질, 맥락 적용, 작은 실행안, 실패 신호, 레퍼런스 환경 검증은 비전문가도 볼 수 있다.

Q. 면접에서 바로 실행하고 싶은 아이디어가 나오면 무조건 좋은 후보인가. A. 무조건은 아니다. 아이디어가 그럴듯해도 실행 비용과 부작용이 클 수 있다. 그래서 바로 채용 결론으로 가지 말고, 작은 파일럿이나 추가 질문으로 검증해야 한다.

Q. AI 에이전트도 사람처럼 레퍼런스 체크를 해야 하나. A. 이름은 다르지만 해야 한다. 공개 이슈, 실패 사례, 릴리스 노트, 실제 로그, 작은 파일럿 결과가 레퍼런스 역할을 한다. 벤치마크 점수만 보면 우리 환경에서 어디서 망가지는지 놓칠 수 있다.

Q. 좋은 후보가 모르는 것을 인정하면 감점인가. A. 오히려 좋은 신호일 수 있다. 모르는 것을 인정하고, 필요한 정보를 묻고, 작은 검증으로 넘어가면 강점이다. 모르는 것을 숨기고 그럴듯하게 말하는 쪽이 더 위험하다.

Q. 외주 개발자 평가에도 이 표를 써도 되나. A. 쓸 수 있다. 실제 문제를 주고, 질문 품질과 범위 조절, 검증 습관을 보면 된다. 특히 외주는 결과물보다 커뮤니케이션과 변경 범위가 더 큰 리스크가 되는 경우가 많다.

Q. 제일 먼저 바꿀 면접 질문 하나만 고르면. A. 우리 상황을 듣고 이번 주에 바로 바꿀 행동 3개와, 실패했는지 확인할 신호 3개를 말해 주세요가 좋다. 이 질문은 전문성, 맥락 적용, 실행 감각, 검증 습관을 한 번에 드러낸다.

참고 자료

Jason Cohen, How to hire people who are better than you, 2026-04-19.
GeekNews, 자신보다 뛰어난 사람을 채용하는 법, 2026-05-07 확인.
내부 운영 메모, 00.Inbox/260507_[요약] 자신보다 뛰어난 사람을 채용하는 법 GeekNews.md.

정리

전문성을 모를 때 평가는 더 어려운 질문으로 해결되지 않는다. 실제 문제, 좋은 질문, 작은 실행, 실패 신호, 환경 적합성으로 해결된다. 사람 후보도 그렇고 AI 에이전트도 그렇다. 말이 아니라 맥락 적용력을 봐야 한다.

자신보다 뛰어난 사람을 뽑는다는 말은 멋있다. 하지만 실무에서는 그 말을 표로 바꿔야 한다. 누가 우리 문제를 더 선명하게 만들었는가. 누가 이번 주 실행안을 남겼는가. 누가 실패했을 때 멈추는 기준까지 제안했는가.

그 세 가지가 보이면 작게 맡겨볼 수 있다. 안 보이면 아직 아니다. 채용이든 에이전트 도입이든, 처음부터 크게 믿는 것보다 작게 증명하게 하는 편이 오래 간다.

자신보다 뛰어난 사람을 채용하는 법 2026 – 전문성을 모를 때 사람과 AI 에이전트를 평가하는 기준