AI 네이티브 시대의 ‘일머리’ 있는 사람을 뽑는 법

일머리는 모호한 일을 실행 가능한 일로 바꾸고, 결과까지 책임지는 능력이다.

---

최근 동료와 바이브 코딩 도입 이후 실무자들의 생산성에 차이를 만드는 요소들에 관해 이야기했다. 같은 AI 도구를 활용해도 왜 사람마다 만들어내는 결과가 다를까. 그 차이를 하나씩 짚어가다 보니, 결국 ‘일머리’라는 단어로 설명할 수 있다는 결론에 다다랐다.

그런데 막상 일머리가 무엇인지 정의해보니 흥미로운 점을 발견했다. 업무의 목적과 맥락을 파악하고, 모호한 문제를 구조화하고, 우선순위를 정해 실행한 뒤, 결과를 확인하고 개선하는 능력. 개발자들이 소프트웨어를 만들며 해오던 일과 정확히 맞아떨어졌다.

그렇다면 이런 능력을 가진 사람을 어떻게 알아볼 수 있을까. 개발 경력이 길다는 사실만으로 일머리를 판단할 수는 없다. 오늘은 경력과 상관없이 일머리 있는 사람을 채용하는 방법에 관해 이야기해보려 한다.

출발점은 회사 전체가 필요로 하는 인재상과 팀이 필요로 하는 실무 역량을 구분하는 것이다. 회사 공통의 인재상은 인터뷰로 확인하고, 팀의 실무 역량은 AI를 활용하는 맞춤형 과제로 확인한다. AI는 지원자의 업무 방식뿐 아니라, 회사가 그런 과제를 만드는 비용도 바꾸고 있다.

TL;DR

• 일머리를 목적 파악, 구조화, 판단, 실행, 검증, 적응이라는 관찰 가능한 행동으로 바꾼다.
• AI로 맞춤형 채용 과제를 만드는 비용이 낮아진 만큼, 팀과 역할의 실제 업무에 가까운 과제를 설계한다.
• 회사 공통의 인재상은 인터뷰로, 팀의 실무 역량은 AI 활용 과제로 평가하고, 제출물 기반 면접으로 판단의 근거를 확인한다.
• 실무에서 AI 활용을 기대하는 직무는 과제와 면접 중 실무 작업에서도 AI 사용을 필수로 한다. 회사 샌드박스에서 작업하고 로그와 커밋 이력을 보존한다.
• 평가 항목과 비중, 합격 기준은 회사와 역할에 맞게 설계한다. 경력 연수에 기대기보다 실제 판단과 결과를 확인한다.

1. 채용하고 싶은 능력에 이름을 붙인다

내가 생각하는 일머리의 정의는 다음과 같다.

주어진 업무의 목적과 맥락을 빠르게 파악하고, 해야 할 일을 스스로 구조화하여, 적절한 우선순위와 방법으로 결과까지 만들어내는 능력.

여기에 실행 결과를 확인하고 계획을 수정하는 능력까지 포함해야 한다. 처음 세운 계획이 그럴듯해도 현실과 맞지 않으면 바꿔야 하기 때문이다.

예를 들어 “고객 불만이 늘었으니 확인해달라”는 요청을 받았다고 하자. 일머리가 드러나는 지점은 보고서의 분량이 아니다. 정말 불만이 증가했는지, 주문량 증가에 따른 변화인지, 특정 제품이나 시점에 집중되는지 구분하는 과정이다. 그다음 가장 먼저 확인할 가설과 행동을 정하고 결과를 확인해야 한다.

AI에게 보고서 초안을 맡길 수는 있다. 하지만 어떤 데이터를 봐야 하는지, 무엇을 해결해야 하는지, 어느 정도의 근거가 있어야 행동할지는 여전히 판단이 필요한 문제다. 채용에서는 바로 그 판단을 관찰해야 한다.

2. 좋은 엔지니어에게 이미 요구해온 역량이다

이 정의를 읽으면 소프트웨어 엔지니어에게 익숙한 업무 흐름이 떠오른다. 요구사항의 이유를 확인하고, 모호한 부분을 명확하게 만들고, 문제를 나누고, 기술적 선택의 장단점을 비교하고, 구현한 뒤 운영 결과를 보며 개선하는 과정이다.

특히 실패를 먼저 생각하는 습관이 있다. 입력이 잘못되면 어떻게 할까. 외부 서비스가 응답하지 않으면 어떻게 할까. 결과가 틀렸는지 어떻게 알아차릴까. 문제가 생기면 되돌릴 수 있을까.

이 질문은 소프트웨어 밖에서도 유용하다. 교육을 기획할 때는 참가자의 수준이 예상과 다르면 어떻게 할지 묻는다. 고객 응대 프로세스를 설계할 때는 담당자가 부재하면 누가 이어받을지 확인한다. 시장조사에서는 결론을 바꿀 만한 반대 증거를 찾는다.

여기서 기회가 생긴다. AI가 조사, 문서화, 분석의 일부를 도와준다면 엔지니어가 자신의 문제 해결 역량을 인접 업무에 적용할 수 있다. 소프트웨어 엔지니어링 경험을 일반적인 문제 해결 훈련으로 바라볼 수 있다는 가설이다.

다만 개발자라는 직함이 일머리를 보장하지는 않는다. 다른 직무에도 같은 역량을 가진 사람이 있다. 채용에서 볼 것은 직업에 대한 이미지가 아니라 실제 행동이다.

3. 직무의 경계보다 역할과 실패 비용을 본다

AI와 개발을 이야기할 때는 비개발자가 서비스를 만드는 방향에 관심이 모인다. 반대 방향도 살펴볼 만하다. 개발자가 AI를 활용해 고객 인터뷰 질문을 만들거나, 데이터를 분석하거나, 기술 교육을 설계하는 것이다.

이때 “다른 직무를 대신한다”는 표현은 너무 넓다. 시장조사 초안을 만드는 일과 사업의 투자 결정을 책임지는 일은 다르다. 기술 문서를 작성하는 일과 보안 감사를 최종 승인하는 일도 다르다.

역할을 확장할지는 세 가지를 함께 보고 결정해야 한다. 기존 역량이 얼마나 전이되는가, 결과를 검증할 도메인 지식이 있는가, 실패했을 때의 비용은 얼마인가.

내부 검토용 초안은 작은 실험으로 시작할 수 있다. 고객에게 약속하거나 큰 비용을 집행하는 판단에는 더 깊은 전문성과 검토가 필요하다. 개발자가 다른 영역으로 이동하면 언제나 위험이 낮다는 일반화도 성립하지 않는다.

따라서 채용 공고도 책임질 결과와 필요한 전문성을 구체적으로 써야 한다. “AI를 잘 쓰는 개발자”보다 “고객의 문제를 확인하고, 작은 해결책을 구현하고, 효과를 측정하며 개선할 사람”이라는 설명이 평가할 행동을 더 명확하게 만든다.

4. 회사의 인재상과 팀의 실무 역량을 나누어 본다

내가 주목하는 또 하나의 변화는 맞춤형 채용 과제를 만드는 비용이 크게 낮아졌다는 점이다. 팀의 업무를 과제로 옮기려면 상황을 설명하고, 샘플 데이터를 만들고, 시작할 수 있는 프로젝트와 검증 방법을 준비해야 한다. 이제 이 준비 과정에서도 AI 에이전트의 도움을 받을 수 있다.

예를 들어 팀이 만드는 제품의 목적과 채용할 사람이 맡을 일을 정리해 AI에 전달하고, 과제 시나리오와 샘플 문서, 테스트용 도구, 평가 항목의 초안을 함께 만들 수 있다. 담당자는 초안이 실제 업무를 잘 반영하는지 검토하고, 직접 과제를 풀어보며 난도와 소요 시간을 조정한다. 이 과정을 통해 팀마다 다른 문제를 채용 과제에 담는 부담을 줄일 수 있다.

그렇다면 채용에서도 두 가지 질문을 나누어 볼 수 있다.

확인할 것	주요 평가 방식	살펴볼 내용
회사 전체가 필요로 하는 인재상	공통 인터뷰	협업, 책임, 고객에 대한 태도 등 회사가 중요하게 여기는 원칙을 실제로 어떻게 실천했는가
팀이 필요로 하는 실무 역량	팀과 역할에 맞춘 AI 활용 과제	맡게 될 문제를 이해하고, AI와 함께 설계·구현·검증해 결과를 만들 수 있는가

회사 공통 인터뷰에서는 추상적인 가치에 동의하는지 묻는 데서 더 나아가야 한다. 의견이 충돌했을 때 어떻게 조율했는지, 자신의 실수를 언제 누구에게 알렸는지, 피드백을 받고 행동을 바꾼 경험이 있는지 구체적으로 묻는다. 회사가 중요하게 여기는 원칙을 관찰 가능한 행동으로 정리하는 것이다.

팀은 입사 후 맡길 일을 축소한 과제로 실무 역량을 확인한다. 같은 개발자 채용이라도 고객용 제품을 만드는 팀과 사내 업무 자동화를 담당하는 팀은 다른 과제를 만들 수 있다. 맞춤화의 단위는 팀과 역할로 잡고, 같은 포지션의 지원자에게는 공통된 요구 수준과 평가 조건을 적용한다.

두 평가의 결과는 함께 보되, 무엇을 근거로 판단했는지는 구분해 남긴다. 팀의 실무 판단은 과제와 작업 기록을 근거로 설명하고, 회사 공통의 인재상은 인터뷰에서 확인한 사례를 근거로 설명한다. 제출물에 대한 후속 면접은 과제에서 관찰한 판단을 더 깊이 확인하는 과정이 된다.

5. AI 에이전트와 함께 과제를 설계하고 제출한다

나는 이전에 실제 업무의 축소판에 해당하는 프로젝트를 채용 과제로 제시한 적이 있다. 지원자가 코딩 에이전트를 사용해 프로젝트를 진행하고, 커밋 이력과 프롬프트를 담은 회고를 남기게 했다. 최종 산출물과 함께 그 결과에 도달한 과정도 평가의 재료로 삼았다.

이 경험을 바탕으로 팀의 실무 역량을 확인하는 과정을 두 단계로 연결해보려 한다. 지원자가 AI 에이전트와 함께 과제를 설계하고 제출하는 단계, 그리고 제출한 과제를 놓고 면접하는 단계다. 회사 공통의 인재상을 확인하는 인터뷰 항목도 함께 마련한다.

실무에서 AI를 활용해 일할 사람을 채용한다면 두 단계의 실무 작업 모두 AI 사용을 필수로 둔다. AI에 어떤 일을 맡기고, 어떤 판단을 직접 내리며, 결과를 어떻게 검증하는지가 평가 대상이기 때문이다.

개발자 채용이라면 다음과 같은 업무용 에이전트 시스템 개발 과제를 생각해볼 수 있다.

직원의 업무 요청을 받아 사내 문서를 검색하고, 근거를 제시하며 답변하는 에이전트 시스템을 설계하라. 업무 처리가 필요한 요청에는 처리 계획을 만들고, 필요한 승인을 받은 뒤 업무 도구를 호출할 수 있어야 한다. 주어진 시간 안에 검증할 핵심 흐름을 정하고, 설계와 구현 결과를 제출하라.

회사는 샘플 문서, 가상의 업무 데이터, 테스트용 업무 도구를 제공한다. 지원자는 AI 에이전트와 함께 요구사항을 해석하고, 시스템을 설계하고, 구현과 검증을 진행한다. 여기서 과제를 수행하는 코딩 에이전트와 지원자가 개발하는 업무용 에이전트 시스템은 구분된다.

지원자가 처음부터 모든 기능을 만들 필요는 없다. 먼저 어떤 직원의 어떤 업무를 해결할지, 문서에 답이 없으면 어떻게 할지, 도구 실행 전에 어떤 승인이 필요한지 정리해야 한다. 문서 검색과 답변에 집중할지, 작은 업무 하나를 끝까지 처리하는 흐름을 만들지도 선택해야 한다.

회사는 해당 직무에서 반드시 확인할 요구사항과 제출 범위를 미리 밝힌다. 지원자는 그 안에서 우선순위와 방법을 결정한다. 구현 중심 역할이라면 실행 가능한 핵심 흐름과 테스트를, 설계 중심 역할이라면 구조와 선택의 근거, 검증 방법에 더 무게를 둘 수 있다. 과제의 배경 정보와 질문에 대한 답변 조건은 같은 채용에 참여하는 지원자에게 일관되게 제공한다.

제출물에는 설계와 코드뿐 아니라, 어떤 가정을 했고 무엇을 구현했으며 무엇이 남았는지 포함한다. 프롬프트와 회고는 그 선택을 설명하는 자료가 된다. 실제 직무와 유사한 활동을 수행하게 하는 접근은 직무 과제 평가(work sample)와 연결된다. 미국 인사관리처(OPM)도 이를 평가 방법으로 소개하며, 입사 시점에 갖추어야 할 역량을 대상으로 사용할 것을 설명한다.¹

제출까지 허용하는 기간과 실제로 기대하는 작업 시간은 구분해야 한다. 일주일 안에 제출하게 한다고 해서 모든 지원자가 과제에 쓸 수 있는 시간이 같은 것은 아니다. 회사는 예상 작업 시간, 최소 제출 범위, 추가 구현의 평가 여부를 미리 안내하고, 필요한 경우 과제 보상도 설계해야 한다.

6. 회사의 샌드박스에서 작업 기록을 보존한다

과정을 평가하려면 기록을 얼마나 믿을 수 있는지도 해결해야 한다. 제출 직전에 정리한 회고는 당시의 판단을 그대로 보여주지 않을 수 있다. 프롬프트와 설명도 AI로 다시 작성할 수 있다.

내가 가장 좋은 방식이라고 보는 것은 회사가 마련한 샌드박스에서 프로젝트를 진행하고, 생성된 로그와 커밋 이력을 지원자가 사후 수정할 수 없도록 보존하는 것이다. 작업 환경, AI 도구와 계정, 사용 비용을 회사가 제공하고 지원자는 그 안에서 과제를 수행한다.

이때 작업 공간과 기록 보관 공간의 권한을 나누어야 한다. 지원자는 코드와 설계 문서를 자유롭게 고치고 새 커밋을 만들 수 있다. 이미 수집된 로그와 커밋 기록에는 수정·삭제 권한을 주지 않는다. 작업에 사용하는 AI 에이전트에도 같은 제한을 적용한다. 잘못된 선택을 고치는 과정은 새 기록으로 남는다.

예를 들어 다음과 같이 구성할 수 있다.

기록	수집·보존 방식	면접에서 확인할 내용
AI와 주고받은 요청·응답, 도구 호출	회사가 관리하는 수집 경로를 통해 작업 공간 밖에 저장	어떤 맥락을 주었고 결과를 어떻게 다뤘는가
커밋과 해당 시점의 파일 상태	회사 원격 저장소에 자동 전송하고 수신한 이력을 별도 보관	설계와 코드가 어떤 순서로 바뀌었는가
실행·테스트 결과	회사 실행 환경에서 로그를 수집하고 코드 버전과 연결	확인했다고 설명한 동작을 실제로 검증했는가
회고와 최종 제출물	제출 시점의 버전을 고정하고 이후 설명은 별도 기록	설명이 당시 작업과 일치하는가

지원자와 작업 에이전트가 수집 장치를 중단하거나 보관 설정을 바꾸지 못하도록 관리 권한도 분리한다. 원격 저장소에서는 강제 푸시와 브랜치 삭제를 막고, 지원자에게 보호 규칙을 우회할 권한을 주지 않는다. GitHub의 보호 브랜치도 이런 제한을 제공한다.²

다만 원격 브랜치 보호만으로 샌드박스 안의 모든 작업 이력이 보존되는 것은 아니다. 로컬에서 기록을 고친 뒤 처음 전송하는 경우도 있기 때문이다. 따라서 작업 중 로그와 코드 상태를 지속적으로 수집하고, 회사 측 수신 시각과 연결해 보관해야 한다. 수집된 기록에는 보존 기간 동안 덮어쓰기·삭제를 막는 저장 방식을 적용할 수 있다. 예를 들어 S3 Object Lock은 지정된 객체 버전에 이런 보호를 제공한다.³

무엇을 수집하고 언제까지 보관하는지는 과제 시작 전에 안내한다. 수집 범위는 과제용 환경으로 한정하고, 지원자에게 도구를 익힐 기회도 제공한다. 기록이 누락된 구간은 면접에서 확인할 미확인 구간으로 남긴다.

이 구조가 확보하는 것은 수집한 기록을 사후에 바꾸기 어렵다는 신뢰다. 기록의 양이나 보존 자체가 지원자의 판단력을 증명하지는 않는다. 설명, 작업 기록, 실제 산출물, 실행 결과를 서로 대조하는 면접이 이어져야 한다.

7. 제출한 과제를 놓고 면접한다

실무에 대한 후속 면접은 지원자가 제출한 프로젝트에서 시작한다. 면접관은 설계, 커밋, AI 사용 기록, 테스트 결과를 미리 살펴보고 확인할 의사결정 지점을 고른다. 지원자가 무엇을 만들었는지 다시 발표하게 하는 데서 그치지 않고, 선택의 이유와 그 선택이 실제 결과로 이어졌는지 묻는다.

업무용 에이전트 시스템이라면 다음과 같은 질문이 가능하다.

• AI는 업무 도구를 바로 호출하는 설계를 제안했는데, 최종 구현에서는 승인 단계를 추가했다. 어떤 문제를 예상했는가?
• 회고에는 문서에 근거가 없을 때 답변을 보류하도록 바꿨다고 적었다. 어느 커밋과 테스트에서 그 변화를 확인할 수 있는가?
• 테스트 실패 뒤 프롬프트를 수정했다. 원인이 프롬프트에 있다고 판단한 근거는 무엇이며, 코드나 데이터의 문제는 어떻게 확인했는가?
• 제출물에서 아직 검증하지 못한 부분은 무엇이며, 실제 업무에 적용한다면 무엇부터 확인하겠는가?

이 질문은 설명과 기록을 연결한다. 회고를 AI의 도움으로 작성했더라도 그 내용이 실제 작업을 정확히 설명하고, 지원자가 선택의 이유를 이해하고 있는지 확인할 수 있다.

필요하다면 제출물에 작은 변경 요구를 추가한다.

업무 도구가 요청을 처리한 뒤 응답을 보내지 못했다. 에이전트가 같은 요청을 재시도해도 업무가 중복 처리되지 않도록 설계를 바꿔보라.

지원자는 기존 프로젝트를 바탕으로 AI 에이전트와 함께 영향 범위를 살피고, 수정 방법을 정하고, 가능한 범위에서 변경과 검증을 진행한다. 면접관은 이 과정에서 어떤 정보를 먼저 확인하는지, AI의 제안을 어떻게 판단하는지, 남은 문제를 얼마나 정확히 설명하는지 관찰한다. 면접 중 변경 기록도 원래 제출본과 구분해 보존한다.

마지막에는 처음의 가정, 중간에 바뀐 판단, AI의 제안을 채택하거나 거절한 이유를 돌아본다. 과제에서 남긴 기록과 면접 중 행동을 함께 보면, 낯선 조건에서도 같은 문제 해결 방식을 이어갈 수 있는지 살펴볼 수 있다.

이렇게 하면 과제와 면접이 연결된다. 과제에서 남긴 판단의 흔적을 면접에서 확인하고, 새로운 조건을 통해 그 판단이 어떻게 바뀌는지 관찰하는 것이다.

같은 면접 자리에서 회사 공통의 인재상을 확인할 수도 있다. 기술적 선택의 이유를 확인하는 질문과 협업·책임에 관한 경험을 확인하는 질문을 각각 준비하고, 답변도 해당 평가 항목에 맞춰 기록한다. 면접을 몇 차례로 나눌지는 회사가 정하되, 각 질문이 무엇을 확인하기 위한 것인지는 분명해야 한다.

8. 평가 기준은 회사와 역할에 맞게 설계한다

이 글의 제안을 모든 회사가 같은 배점으로 적용할 수는 없다. 채용할 사람이 맡을 업무와 책임이 다르면 중요하게 볼 판단도 달라진다. 평가 항목과 비중, 합격 기준은 회사가 역할에 맞게 설계해야 한다.

회사 공통의 인재상은 조직 전체가 공유할 인터뷰 기준으로 정리하고, 실무 역량은 채용하는 팀이 과제와 평가 기준을 함께 설계한다. 채용 담당자와 팀은 각각의 최소 요건과 최종 판단 방식을 미리 합의한다. 그래야 과제 성적이나 면접 인상 하나가 나머지 근거를 가리지 않는다.

업무용 에이전트 시스템을 만드는 같은 과제라도, 제품 엔지니어는 사용자의 문제를 좁히고 핵심 흐름을 완결하는 능력을 중점적으로 볼 수 있다. 플랫폼 엔지니어는 도구 실행의 안정성과 장애 복구를, 아키텍트는 요구사항의 충돌과 설계 선택의 근거를 더 깊이 볼 수 있다. 어떤 역할에서 무엇을 최소 요건으로 삼을지부터 정해야 한다.

그다음 목적 파악, 구조화, 우선순위, AI 위임, 검증, 적응 중 어떤 행동을 관찰할지 구체화한다. 예를 들어 도구 실행의 안정성이 중요한 역할이라면 ‘중복 처리 가능성을 알아차림’, ‘방지 방법을 설명함’, ‘수정 후 테스트로 확인함’을 서로 다른 근거로 기록할 수 있다. 각 행동에 어떤 비중을 줄지는 해당 역할의 책임에 따라 결정한다.

같은 역할의 지원자에게는 공통된 평가 항목과 수준별 기준을 적용한다. 기본 과제, 제공 정보, 이용 조건, 추가 변경의 난도도 맞춘다. 제출물에 따라 후속 질문은 달라질 수 있지만, 무엇을 좋은 판단으로 볼지는 면접관마다 바뀌어서는 안 된다. OPM의 구조화 면접 안내도 사전 질문과 공통 평가 척도를 강조한다.⁴ 이 원칙을 제출물 기반 면접의 공통 질문과 평가 기준에 적용할 수 있다.

경력과 상관없이 평가한다는 것은 연차만으로 일머리를 판단하지 않겠다는 뜻이다. 경험은 문제를 알아보는 속도와 도메인 판단에 기여할 수 있다. 회사는 입사 시점에 필요한 전문성과 입사 후 배울 수 있는 내용을 구분하고, 익숙한 업계 용어를 많이 아는 것과 문제를 잘 풀어내는 것을 혼동하지 않아야 한다.

채용 뒤에도 기준을 이어간다. 목적이 분명한 업무를 맡기고, 도메인 전문가의 피드백을 제공하며, 실제로 해결한 문제와 결과의 품질을 확인한다. 채용 당시의 평가를 입사 후 업무 결과와 비교하면 과제와 면접에서 무엇을 제대로 봤고 무엇을 놓쳤는지도 돌아볼 수 있다.

---

결론

AI 시대의 채용에서 내가 보고 싶은 사람은 목적과 맥락을 이해하고, 문제를 구조화하고, AI에 맡길 일을 정하고, 결과를 검증하며 끝까지 완결하는 사람이다. 좋은 소프트웨어 엔지니어에게 오랫동안 요구해온 역량이기도 하다.

AI로 맞춤형 과제를 만드는 비용이 낮아진 지금, 회사는 팀이 실제로 풀고 있는 문제를 채용에 더 가까이 가져올 수 있다. 지원자가 AI 에이전트와 과제를 설계하고 수행하도록 하고, 회사는 그 과정을 확인할 수 있는 환경과 기록을 마련한다. 이어지는 면접에서는 제출한 프로젝트를 중심으로 선택의 이유와 새로운 조건에 대한 대응을 확인한다.

회사 전체가 필요로 하는 인재상은 인터뷰로, 팀이 필요로 하는 실무 역량은 AI를 활용한 과제로 확인한다. 어떤 판단에 더 높은 가치를 둘지는 회사와 역할에 따라 다르다. 공통적으로 필요한 것은 지원자가 남긴 말과 행동, 결과를 연결해 보는 일이다.

“무엇을 몇 년 했는가?”에 더해 “이 모호한 문제를 받으면 무엇부터 확인하고, AI와 함께 어떤 결과까지 만들어낼 수 있는가?”를 묻는 것. AI 시대의 채용 전략은 그 질문에서 시작할 수 있다.

---