크래프톤 AI 역량 평가에서 개발 경험 없는 매장 직원 출신이 상위권에 오른 이유 (크래프톤 구한모·조정석님)

한 줄 요약

크래프톤 AI 프론티어 본부의 구한모·조정석이 만든 AI 역량 평가 도구 '프로브'를 다룬 인터뷰예요. 코딩 테스트 대신 AI와 함께 실제 업무를 해 보는 환경을 주고 결과물·AI 활용·이해도를 기술·의도·인지 세 축으로 채점했더니, 개발 경험 없는 매장 직원 출신이 상위권에 올랐다는 이야기가 핵심입니다.

전체 내용 정리

AI를 잘 쓰는 사람과 AI 네이티브는 출발점이 달라요

조쉬가 진행하는 이번 인터뷰에는 크래프톤 AI 프론티어 본부의 두 사람이 나왔어요. 구한모는 베인앤컴퍼니에서 4년 정도 컨설팅을 하다 크래프톤에 합류한 PO(프로덕트 오너)예요. 학부는 문과였고 테크를 좋아해 컴퓨터공학도 공부했어요. 그런데 컴퓨터보다 사람과 이야기하는 게 더 재밌어서 비즈니스 쪽으로 방향을 틀었다고 해요.

조정석은 전자공학을 전공하고 대학원에서 로보틱스를 연구한 AI 프로덕트 엔지니어입니다. 네이버제트에서 3년 정도 모션 캡처를 AI로 대체하는 일을 했어요. 크래프톤에 온 뒤 Cursor(AI 코드 에디터)가 나오는 걸 보고 모델 하나 만드는 일이 생각보다 빨리 대체될 수 있겠다고 느꼈대요. 마침 구한모가 팀을 꾸린다고 해서 합류했습니다.

두 사람이 지금 만드는 건 채용 과정에서 지원자의 AI 역량을 평가하는 솔루션 '프로브'예요. 기업들은 AI를 잘 쓰는 사람을 뽑고 싶어 하지만 그걸 어떻게 알아볼지 막막해하거든요. 크래프톤 내부에 이런 노하우가 쌓여 있어서 솔루션으로 만들어 보자며 시작했다고 합니다.

조쉬는 프롬프트를 잘 쓰는 사람, Claude Code를 어느 정도 쓰는 사람, AI를 잘 조종해 통제력을 높이는 사람이 다 다를 거라며 질문을 던졌어요. AI 리터러시와 AI 네이티브니스를 왜 구분하느냐고 묻자 구한모는 이렇게 답해요. 리터러시가 있는 사람은 기존 워크플로 안에서 효율을 올릴 방법을 고민해요. 반면 AI 네이티브한 사람은 워크플로 자체를 처음부터 다시 설계하죠. 일론 머스크의 제1원리(first principles)처럼 기존 방식과 상관없이 내 의도에서 출발해요. 이 부분은 AI로 바꾸고 저 부분은 SaaS 없이 직접 만들어 해결해 보겠다는 태도와 역량을 함께 갖춘 사람이라는 설명입니다.

엔터 키를 누르고 퇴근하면 에이전트가 밤새 일해요

조정석은 AI로 일하는 방식을 두 갈래로 나눠요. 첫째는 뭔가를 만들어야 하는 상황이에요. 그는 출근해서 퇴근할 때까지 거의 모든 시간을 에이전트에게 맡길 일을 설계하는 데 써요. 오늘 구현할 범위와 버그를 고칠 범위를 정하고 에이전트가 봐야 할 영역을 대화로 다듬죠. 검증할 때 어떤 데이터를 볼지 정하고 로컬부터 프로덕션까지 세 단계 환경에서 각각 어떻게 확인할지 루프를 짜 둡니다.

그다음은 간단해요. "퇴근할 때는 엔터 키 누르고 그냥 가면 돼요." 보통 에이전트를 네다섯 개 돌려 두고 퇴근한 뒤 다음 날 아침에 결과를 확인한대요. 토큰이 녹지만 회사 지원이 넉넉해서 레버리지로 쓴다고요.

둘째는 이미 만든 에이전트를 다듬는 일이에요. 프로브에서는 지원자 한 명의 과제를 평가하는 데 20개가 넘는 에이전트가 병렬로 돌아가요. 이 에이전트를 잘 맞추려면 실제 사람이 만든 데이터로 좋은 데이터셋을 갖춰야 하죠. 조정석은 이밸류에이션(evaluation, 평가 체계)을 만들고 그걸 기준으로 에이전트를 맞춰 가는 구조가 가장 중요하다고 봐요. 연구자들에게 익숙한 워크플로라서 그 방식을 빌려 오면 한결 쉬워질 거라는 말도 덧붙였습니다. 여러 에이전트를 닫힌 루프(closed loop)로 엮는 방법을 고민하던 조쉬에게 건넨 답인데요. 조정석 자신도 유튜브에서 조각조각 얻은 방법을 조합해 쓰고 있다고 해요.

구한모는 옵시디언(Obsidian, 마크다운 기반 노트 앱)을 중심에 둬요. 원래 노션을 썼는데 LLM과 협업하기에는 옵시디언이 더 맞다고 판단했대요. 요일별로 할 일을 적어 두면 그 자체가 프롬프트가 돼요. 옵시디언 폴더는 GPT를 쓰든 Claude를 쓰든 같은 메모리와 스킬을 꺼내 쓰는 공용 창고 역할을 해요. 크론잡(정해진 시간에 자동 실행되는 작업)이 매일 아침저녁으로 돌면서 에이전트가 참고할 자료도 채워 넣고요. 조쉬는 세컨드 브레인의 정석대로 하고 있다며 감탄했어요. 미팅은 녹음만 하면 노트가 자동으로 써지고 메모리에 반영돼서 이제는 컨텍스트를 따로 넣지 않고 에이전트와 대화만 하면 된다고 합니다.

여기서 구한모가 강조한 개념이 CAPEX(초기 투자 비용)예요. 기업이 자동화를 하려면 앞단에 자본을 투자하듯 개인도 시간을 얼마나 먼저 들일지 판단해야 하는 시대가 왔다고 봐요. 지금 시간을 써서 세팅해 두면 매일 반복되는 일과 의사결정에 드는 의지력이 얼마나 줄어드는지 따져 봐야 해요. 구한모 본인은 주말에 하루 정도를 들여 이 구조를 만들었다고 해요.

프로브는 코딩 테스트보다 '하루 같이 일해 보기'에 가까워요

구한모는 사람의 업무 역량을 보는 가장 효과적인 방법이 하루 정도 같이 일해 보는 거라고 말해요. 하지만 기업마다 지원자를 몇천 명씩 봐야 하니 현실적으로 불가능하죠. 그래서 개발자 채용은 측정 가능한 코딩 테스트로 1차를 거르고 면접으로 같이 일하면 어떨지를 간접적으로 확인해 왔어요. 프로브는 처음부터 같이 일하는 경험을 주자는 데서 출발했어요. 그래서 코딩 테스트보다는 AI를 전제로 한 업무 역량 테스트로 봐 달라고 합니다.

현업과 가장 비슷한 환경을 만드는 데 초점을 둔 이유도 있어요. AI로 만들 수 있는 게 많아지면서 제품의 라이프사이클이 빨라졌고 엔지니어가 내려야 하는 의사결정도 늘었거든요. 그래서 프로브는 결과물만이 아니라 문제를 정의하고 결정을 내리는 과정까지 함께 보도록 설계됐어요. 사람들과 소통하며 질문을 던지는 능력도 하나의 역량으로 본다고 해요.

화면은 VS Code 같은 IDE(통합 개발 환경)를 닮았어요. 디렉터리를 볼 수 있고 README로 과제를 확인하며 터미널에서 Claude Code나 Codex를 쓸 수 있어요. 만든 HTML을 바로 띄워 보는 브라우저도 붙어 있고요. 고객사에 따라 지원자가 평소 쓰던 스킬을 업로드해 쓰게 할 수도 있어요. 좋은 외부 스킬을 가져다 쓰는 것도 중요한 능력이라고 보기 때문이죠.

우측 채팅창에는 현업 담당자의 페르소나를 입힌 에이전트가 있어요. 과제 지시서는 일부러 짧고 러프하게 줍니다. 시연에 나온 과제는 e스포츠 글로벌 대회 현장의 요청을 본뜬 건데요. 선수가 인터뷰 전에 혼자 질문에 답해 보고 방금 한 답변을 돌아볼 수 있으면 좋겠다는 정도만 적혀 있어요. 여기에 현업 담당자가 선수들과 연습할 때 쓰는 코칭 방식도 서비스에 담고 싶다는 요청이 붙죠. 현업 파트너 설명을 요약하면 물어보면서 니즈를 찾으라는 뜻이에요.

페르소나 에이전트는 요구 사항을 한 번에 알려 주지 않도록 설계돼 있어요. 게임에서 단계를 하나씩 여는 것처럼 질문을 거듭해야 요구 사항이 하나씩 풀려요. 조쉬도 현업에서는 아무도 한 번에 알려 주지 않는다며 웃었는데요. 미팅도 커피 약속도 어렵게 잡아야 하고 상대가 불친절하게 답하는 쪽이 오히려 현업에 가깝다는 말이 이어졌어요. 실제 회사에서도 상사가 목적과 제약 조건을 정리해서 건네주지 않잖아요. 그래서 질문으로 요구 사항을 하나씩 끌어내 문제를 정의하는 과정 자체를 역량으로 봐요.

지원자들이 가장 망설이는 건 바보 같은 질문을 해도 되느냐예요. 답은 간단해요. 신입이 사수에게 묻듯 사소한 것부터 물어 맥락을 모으고 점점 질문을 고도화하는 사람이 점수를 잘 받습니다. 반대로 지금 당장 할 일을 하나, 둘, 셋 순서대로 알려 달라는 식의 요청은 페르소나 쪽에서 막아 뒀어요. 무엇을 물어야 할지 모르겠다고 하면 답해 줄 수 있는 범위는 알려 주지만 해결 방법까지 알려 주지는 않아요.

과제 시간은 해커톤 기준 6시간 정도였어요. 한 사람이 일하는 동안 AI 에이전트 20명 정도가 옆에서 지켜보는 셈이죠. 도구 사용 내역과 토큰·비용도 전부 기록돼요. 평가 화면을 설명하면서 나온 말이 흥미로워요.

"잘 하시는 분들일수록 비용 적게 쓰시거든요."

과제를 통째로 넣고 구현을 다 맡기면 결과물은 10분 안에 나와요. 그런데 그걸 손보느라 토큰을 다 써 버리고 세 시간 동안 허덕일 수 있다고 해요.

기술·의도·인지, 세 가지 부채를 기준으로 채점해요

프로브는 세 가지를 봐요. 첫째는 결과물의 완성도예요. 아키텍처를 얼마나 잘 잡았는지, 어떤 기술을 썼는지 같은 전통적인 기준이 여기에 들어가요. 둘째는 AI를 얼마나 주도적으로 다뤘느냐예요. 지시서를 복사해 붙여 넣고 해 달라고만 하면 결과물도 좋지 않고 점수도 낮게 나와요. 지시서를 조목조목 따지며 AI와 구조와 설계를 논의하고 오래 걸리는 구현은 서브 에이전트로 떼어 맡기는 식으로 오케스트레이션을 잘하는 사람이 높은 점수를 받습니다.

셋째는 가장 중요하게 보는 인지 점수예요. AI로 만든 결과물에서 문제를 뽑아 지원자에게 물어봐요. 왜 이 패턴을 썼고 이 제품의 라이프사이클에서 왜 유효한지 설명할 수 있어야 하죠. AI에게 끌려가는 사람인지 AI와 대화하며 배우고 주도하는 사람인지가 여기서 갈려요. 세 축의 바탕에는 유명한 연구 논문이 하나 있는데, 그 논문에 기술 부채·의도 부채·인지 부채라는 용어가 그대로 나온다고 합니다.

인지 축이 왜 중요한지 보여 주는 사례도 나왔어요. 어떤 지원자가 DB와 API를 설계하는데 API가 전부 읽기(read)만 하는 상황이었어요. 그러면 쓰기(write)에 대한 가드는 느슨해도 되는데, 쓰기 요청이 한꺼번에 몰릴 때를 대비한 가드까지 촘촘하게 만들어 오히려 부하를 키웠죠. 범용적으로는 잘 설계한 DB지만 이 시스템의 요구 사항에 맞는 설계는 아니에요. 요즘 AI는 그럴듯한 제품을 다 만들어 주는 대신 오버엔지니어링을 자주 해요.

그걸 조절하는 능력은 여전히 사람의 몫으로 남아 있어요.

구한모는 이걸 컨설팅 시절 엑셀 모델링에 빗대요. 엑셀을 켜 놓고 문제를 풀다 보면 끌려다니다가 내가 뭘 해야 하는지 놓치는 사람이 있었대요. 그래서 엑셀을 내려놓고 먼저 생각부터 하라고 배웠다고요. AI를 쓸 때도 내가 무엇을 하려는지 방향을 먼저 세우고 주도권을 뺏기지 않아야 해요. 이런 태도는 인지뿐 아니라 의도 축에서도 프롬프트로 드러난다고 합니다.

평가 결과 화면에는 기술·의도·인지별 세부 역량과 루브릭, 근거가 붙어요. 소스 코드뿐 아니라 프런트엔드 화면 스크린샷과 내부 실행 상태까지 점검해 판정에 반영하죠. 루브릭을 믿을 수 있는지도 AI 모델로 확인했어요. 같은 과제를 여러 모델에게 풀렸더니 Opus는 95점 정도, Haiku는 70점대, Sonnet은 그 중간쯤으로 나왔대요. 일반 벤치마크와 같은 순서라서 평가 체계가 탄탄하다는 근거로 봅니다. 자세한 내용은 조만간 기술 블로그에서 설명할 계획이라고 해요.

조쉬는 이 대목에 크게 공감했어요. 오버엔지니어링하는 AI에게 우리 비즈니스 목표와 맞지 않는다는 걸 사후에 가르쳐 주고 기준을 세워 줘야 하는 일이 계속 생기잖아요. 조쉬는 새로운 시대의 인재를 주변 맥락을 종합해 AI가 엉뚱한 길로 가면 그걸 알아채고 통제하는 사람으로 봐요. 구한모는 이를 주체성이라고 표현했어요. 사람은 본능적으로 인풋이 계속 들어오면 스스로 아웃풋을 만들어 내는 감각을 잃기 쉬운데, AI가 무엇을 제안하든 방향을 놓지 않는 능력이 중요하다고 해요.

개발 경험 없는 매장 직원 출신이 상위권에 오른 이유

조쉬가 새롭다고 느낀 대목은 지원자가 평소 쓰던 스킬을 가져오면 가중치를 준다는 점이에요. 인터뷰에서는 요즘 인재에게 달라진 점으로 에고를 버리는 걸 꼽아요. 처음부터 다 내가 만들겠다는 사람은 오히려 비생산적이라는 거죠. 크래프톤의 개발 리드도 예전과 뽑는 기준이 뭐가 달라졌냐는 질문에 이렇게 말했다고 해요.

"지금은 코드를 사랑하는 사람은 뽑고 싶지 않다"

코드 리뷰에서 이 코드는 아름답다고 말하던 사람이나 픽셀 하나 틀렸다고 못 쓴다던 디자이너보다 빠르게 만들고 남이 만든 것도 잘 가져다 쓰는 사람이 중요해졌다는 얘기예요. 입사 첫날 모니터부터 IDE와 플러그인까지 자기 환경을 세팅하던 경험도 나왔어요. 그 세팅이 곧 그 사람의 경쟁력인데 그걸 빼고 평가하는 건 오히려 역차별이라는 생각이었대요. PC방 장비를 쓰는 일반 게이머와 가방에서 자기 마우스와 키보드를 꺼내는 프로 게이머처럼 개인이 자기 무기를 갖추는 시대가 왔다는 비유도 이어졌습니다. 조쉬는 이 방식이 급진적이라 더 좋았다고 해요. 자기 스킬을 가져와 쓰면 면접에서 어떤 철학으로 그 스킬을 다듬었는지 이야기할 수 있어서 좋은 평가 지점이 된다고 봐요.

해커톤 결과도 같은 맥락이에요. 크래프톤은 한 뷰티 리테일 기업과 함께 OpenAI의 후원을 받아 해커톤을 열었어요. 상위권에 오른 참가자 중 한 명이 개발 경험이 없는 비개발자였는데, 그 기업의 매장에서 2년 정도 근무한 사람이었어요. 화장품 쇼핑몰을 만드는 과제에서 사용자에게 무엇이 중요한지 알았기 때문에 그걸 설계에 녹였고 AI 역량까지 갖춰 점수가 높게 나왔대요. 기존 채용 과정이었다면 놓쳤을 만한 인재였다는 얘기가 전해졌다고 합니다.

해커톤 회고도 재밌어요. 심사하는 한 시간 동안 참가자들이 쉬러 갈 줄 알았는데 다들 자리에 앉아 과제를 어떻게 풀었는지 토론하고 있었대요. 결과를 공개하자 "아 역시"라는 반응이 나올 만큼 누가 잘했는지 서로 알고 있었고요. 한 참가자는 가족이 응급실에 가서 결과를 못 보고 가야 한다며 이렇게 말했대요. "저는 그 정도는 아니라서요." 상위 3명은 면접으로 1등을 가렸는데 자기가 거기까지 못 갈 거라고 본 거죠. 실제로 그 참가자는 중하위권이었어요. 문제를 푸는 사람도 플랫폼 안에서 자기 실력을 예측할 수 있을 만큼 평가가 실무 감각과 맞닿아 있다는 점이 인상 깊었다고 해요.

역할이 넓어질수록 사람에게는 경험과 관계가 남아요

HR 담당자가 프로브를 도입한다면 무엇부터 해야 할까요? 답은 담당자가 먼저 문제를 직접 풀어 보라는 거예요. 기업들은 AI 잘 쓰는 사람을 뽑고 싶다고 하지만 정작 그런 사람이 누구인지 CEO도 HR도 현업도 모르는 경우가 많거든요. CEO는 그런 사람을 뽑으라고 하는데 정작 그게 누구냐고 물으면 너희가 알아야 한다는 답이 돌아온대요. 그래서 우리가 생각하는 AI 역량이 무엇인지부터 맞추고 시작해야 한다고 봐요. 직접 풀어 보면 내가 어디가 부족한지 알게 돼요. 그러면서 이런 걸 잘하는 사람을 뽑아야겠다는 생각이 맞춰진다고 해요.

크래프톤이 고객사에 설명하는 AI 네이티브 엔지니어의 역할 확장은 네 갈래예요. 겪어 보지 못한 트래픽이나 처음 보는 SDK·기술 스택도 다루는 엔지니어, 프런트엔드 개발자가 AI와 함께 백엔드와 데이터까지 보는 풀스택 엔지니어, 제품과 솔루션 의사결정까지 하는 프로덕트 엔지니어, 그리고 HR이나 재무 같은 비즈니스 기능까지 넓히는 역할이에요. 실제로 함께 일하는 HR 담당자 중에는 자기가 배포한 서비스를 QA하느라 늦었다는 사람도 있대요. 예전엔 인프라까지 보는 개발자가 하던 일을 채용 담당자가 하고 있는 거예요.

조정석도 ML 엔지니어로 출발해 지금은 제품 전반을 아우르고 있어요. 연구 개발 쪽에 있던 사람도 제품 관점까지 넓혀 일할 수 있게 된 게 좋다고 말해요. 한 가지 일만 해 보고 끝나는 건 억울한데 이제 AI 덕분에 다양하게 해 볼 수 있잖아요. 디자이너로 커리어를 시작해 사업까지 하고 있는 조쉬도 AI가 없었다면 절대 이렇게 못 했을 거라며 맞장구를 쳤어요.

크래프톤 안에서도 이미 프로브로 팀원을 뽑았는데 그 사람이 실제로 잘 활약하고 있다고 해요. 앞으로 크래프톤 공채에 활용하고 비개발 직군까지 적용하는 게 목표예요. 회계팀에서도 배포와 유지보수까지 할 수 있으면 좋겠다는 말이 나왔고요. SK하이닉스의 AI 해커톤에도 프로브가 솔루션으로 쓰일 예정이라고 합니다. 앞서 소개한 해커톤을 후원한 OpenAI와도 제품 관점에서 파트너십을 맺고 평가 기준을 함께 논의하고 있대요. 두 사람은 이런 변화에 크래프톤이 앞에서 길을 터 줄 수 있지 않을까 기대한다고 말해요.

마지막으로 두 사람의 앞으로의 계획을 물었어요. 구한모는 10x가 돼야 한다고 말해요. 팀 전체 비즈니스를 보는 사람이 적은데 많은 결정을 내려야 하니 나루토의 분신술처럼 AI를 쓰는 사람이 되려 한대요. 세션을 대여섯 개씩 동시에 돌리며 각각을 분신 삼아 의사결정을 빠르게 하고 운영 업무를 미리 처리해 두는 방식이에요.

조정석은 1년 전 Cursor가 나왔을 때를 떠올려요. 네이버제트에서 여섯, 일곱 명이 1년 정도 걸려 만든 모션 캡처 스튜디오와 비슷한 프로젝트를 크래프톤에서는 두 명이 3개월 만에 끝냈대요. 순전히 Cursor 덕분이었다고 해요. 그때 처음 든 생각은 이걸 남에게 알려 주고 싶지 않다는 거였대요. 당시만 해도 Cursor를 많이 쓰는 분위기가 아니었거든요. 두 번째로는 사람을 평가하는 기준과 회사에서 일하는 방식이 크게 바뀌겠다고 느꼈다고 합니다. 일하는 방식이 한곳에 수렴하길 바라지만 전 세계가 수레바퀴를 굴리고 있으니 그러진 않을 거라고 봐요. 그래서 변화를 따라잡고 일하는 방식을 계속 업데이트하는 루프를 스스로 돌리는 게 중요하다고 해요.

AI가 더 많은 일을 맡게 되면 사람에게 남는 가치는 무엇일까요? 조정석이 내린 결론은 경험과 관계, 두 가지예요. 책 보고 개발만 하면 되던 시대는 지났으니 경험과 관계를 더 챙기겠다고 말합니다. 조쉬는 얼마 전 팟캐스트에 나온 해시드 대표도 인간에게 남는 건 경험밖에 없는 것 같다고 했다며 공감했어요. 그러면서 요즘은 의도도 일종의 부채라고 느낀다고 했죠. 의도를 계속 넣다 보면 닫아야 할 루프가 끝없이 쌓이거든요. 이 이야기에 의도 부채 관리가 정말 중요하다는 데 공감하며 대화가 마무리돼요.

핵심 인사이트

• AI 네이티브는 워크플로를 다시 짜는 사람이에요: 기존 업무를 조금 빠르게 하는 데서 멈추지 않고 내 의도에서 출발해 무엇을 AI에 맡기고 무엇을 직접 만들지 다시 설계해요. 채용 기준이 이쪽으로 옮겨 가면 도구를 안다는 것만으로는 차별화가 어려워져요.
• 결과물보다 그 결과물을 설명할 수 있느냐가 갈라요: 프로브는 인지 점수로 지원자가 AI가 만든 코드를 이해하고 있는지 따져요. AI가 오버엔지니어링을 자주 하니 요구 사항에 맞게 덜어내는 판단이 사람의 몫으로 남아요.
• 잘하는 사람일수록 비용을 적게 써요: 통째로 맡기면 10분 만에 결과가 나와도 손보는 데 토큰과 시간을 다 써 버려요. 앞단 설계에 시간을 들이는 습관이 비용과 품질을 함께 잡아 줍니다.
• 도메인 지식이 개발 경력을 이길 수 있어요: 매장에서 2년 일한 비개발자가 사용자 관점을 설계에 녹여 상위권에 올랐어요. AI가 구현 장벽을 낮출수록 무엇이 중요한지 아는 사람이 유리해집니다.

오늘 당장 해볼 것

1. 이번 주에 반복하는 업무 하나를 골라 시간 CAPEX를 계산해 보세요. 세팅에 몇 시간이 드는지, 그 뒤 매주 몇 시간과 얼마만큼의 판단을 아낄 수 있는지 적어 보면 자동화할 일과 미룰 일이 구분돼요.
2. 퇴근 전에 Claude Code나 Codex에 맡길 작업 하나를 정해 범위·검증 기준·확인할 데이터를 문서로 먼저 써 보세요. 그 문서를 넘겨 두고 다음 날 아침에 결과를 확인하면 엔터 키 누르고 퇴근하는 흐름을 작게라도 체험할 수 있어요.
3. AI가 만들어 준 최근 결과물 하나를 골라 왜 이렇게 만들었는지 스스로 설명해 보세요. 설명이 막히는 곳이 인지 부채가 쌓인 곳이에요. 요구 사항보다 과하게 만든 부분도 함께 보여요.