AI로 코드를 짜는 시대, 우리는 채용 방식을 다시 설계했습니다

코딩 테스트가 현실과 멀어지고 있다

오늘날 개발자들이 일하는 방식은 빠르게 바뀌고 있습니다.

AI와 함께 큰 그림을 그리고, 세부 구현은 함께 만들어가는 방식이 새로운 개발 표준이 되고 있습니다.

그런데 채용 현장은 아직 그 현실을 따라가지 못하고 있는 듯합니다. Copilot, Cursor, Claude 등 좋은 개발자일수록 이 툴들을 핵심 워크플로우에 깊숙이 녹여 쓰는데, 여전히 많은 기업이 인터뷰에서 이 툴들을 전부 제한합니다. 실제 업무 방식과 평가 방식 사이의 간극이 점점 벌어지고 있는 것입니다.

AI를 연구하고 개발하는 포지션이라면 이 괴리는 더욱 극명하게 느껴집니다. 매일 AI 툴과 함께 모델을 만들고 시스템을 설계하는 사람을 채용하면서, AI 없이 알고리즘을 구현하라고 하는 것입니다.

트웰브랩스도 같은 고민 앞에 서게 되었습니다.

실제로 일어난 일

당시 트웰브랩스의 Jockey 팀에서는 영상 AI 시스템을 위한 고수준의 추론과 에이전틱 워크플로우를 개발하고 있었습니다. 그에 따라 하나의 팀에서 Reasoning Modeler와 Agent Engineer 두 트랙의 채용을 동시에 준비하였습니다.

처음에는 기존에 운영해오던 코딩 테스트를 그대로 사용했습니다. ML알고리즘을 구현하고 PyTorch로 코드를 작성하는 문제로서 충분히 난이도가 있고 변별력이 뛰어난, 검증된 테스트였습니다.

그런데 인터뷰 후 묘한 상황이 발생하였습니다.

한 후보자가 문제를 끝까지 풀지 못했지만, 인터뷰 내내 날카로운 질문을 던진 것입니다. 시스템의 병목이 어디 있을지, 프로덕션 환경에서 어떤 실패가 발생할 수 있는지를 정확히 짚었습니다. 실제 AI 시스템을 프로덕션에서 운영해본 사람만 아는 종류의 인사이트였습니다.

합격인가, 불합격인가?

쉽게 답을 내릴 수 없었습니다. 그리고 이내 그 불편함이 중요한 신호라는 걸 깨달았습니다. 인터뷰 문제 자체가 우리가 원하는 걸 측정하지 못하고 있었던 것입니다.

Jockey가 찾는 엔지니어의 기준을 다시 쓰다

우리는 Jockey 팀에서 실제로 필요한 사람이 누구인지 고민해 보았습니다.

• 불분명한 문제를 데이터로 정의하는 사람

• AI 툴을 자신의 사고를 확장하는 도구로 쓰는 사람

• 코드를 빠르게 짜는 것보다, 무엇을 짜야 하는지를 먼저 파악하는 사람

기존 코딩 테스트가 나쁜 문제였던 것은 아닙니다. 알고리즘 구현 능력과 수학적 사고를 요구하는 포지션에는 여전히 유효한 방식이었지만, 우리가 찾는 포지션에는 맞지 않았습니다.

그래서 우리는 평가 기준을 다시 썼습니다.

Data Driven Problem Solving: 우리의 해답

새로운 문제를 설계하기 전, 우리와 같은 고민을 하고 있는 회사들이 어떻게 접근하는지 먼저 살펴봤습니다. 시스템을 설계한 뒤 직접 구현해보는 방식, 혹은 망가진 코드베이스를 개선하는 방식 등 업계에서도 다양한 시도들이 이뤄지고 있었습니다. 우리는 이런 흐름을 참고하되, 트웰브랩스의 실제 업무 맥락에 맞게 재해석했습니다.

💡참고한 글
Sierra — The AI-native interview
Google — Google's AI-Assisted Coding Interview (2026 Guide)

그렇게 우리는 Data Driven Problem Solving이라는 새로운 인터뷰 세션을 설계했습니다. 45분짜리 실습 세션으로, 실제 프로덕션 데이터를 그대로 사용합니다. 민감한 정보는 마스킹 처리했지만, 실제 시스템에서 발생한 문제들이 그대로 담겨있습니다.

과제의 구조는 단순합니다.

1. 데이터를 탐색하고 문제를 정의합니다

2. 패턴을 찾고 인사이트를 도출합니다

3. (보너스) 예상치 못한 이상 징후를 발견합니다

AI 툴 사용은 허용됩니다. 사실, 오히려 권장합니다. 후보자가 어떤 툴을 어떻게 사용하는지를 함께 보기 위해 맥북과 AI agent는 트웰브랩스가 준비합니다.

정답을 맞추는지보다는, 다음 세 가지를 더 중요하게 봅니다:

• 문제를 어떻게 정의하는가 — 주어진 데이터에서 무엇이 중요한지를 빠르게 파악하는가

• 어떻게 접근하는가 — 막힐 때 어떻게 돌파하는가, 가설을 어떻게 검증하는가

• AI 툴을 어떻게 쓰는가 — 단순히 코드를 생성하는 데 쓰는가, 아니면 사고를 확장하는 데 쓰는가

설계 과정에서 우리가 부딪힌 것들

새 문제를 만드는 과정은 생각보다 쉽지 않았습니다.

"AI 툴을 허용하면 변별력이 없어지지 않나?"

그런 의문이 들 수 있지만, 오히려 반대였습니다. AI 툴을 잘 쓰는 사람과 못 쓰는 사람의 차이가 극명하게 드러났습니다. 툴에 의존하는 사람은 문제를 정의하지 못한 채 코드부터 생성하는 반면, 툴을 잘 쓰는 사람은 먼저 가설을 세우고, 그걸 검증하는 데 툴을 쓰는 것을 볼 수 있었습니다.

"1시간 남짓의 시간 안에 무엇을 볼 수 있나?"

결론부터 말하면, 충분합니다. 좋은 인터뷰 문제는 30분 안에 사람의 사고 방식을 보여줍니다. 그리고 시간이 부족하면, 후보자가 무엇을 먼저 선택하는지가 드러납니다. 그것 자체가 중요한 신호입니다.

"코딩 능력은 어디서 보나?"

Data Driven Problem Solving 외에도, 기대하는 역할에 따라 별도의 라이브 코딩 세션이 있습니다. 하지만 이 세션에서도 마찬가지입니다. AI Agent와 함께 코드를 만들고, 그 결과물이 적절한지 판단하는 능력을 전반적으로 평가합니다.

인터뷰어의 이야기: 실제로 진행해보니

설계를 마친 뒤, 문제를 직접 만들고 인터뷰를 진행한 팀원들의 후기를 들어보았습니다.

Shane — "Agent는 생각보다 똑똑했고, 병목은 여기서도 사람이었습니다."

Custom harness나 특별한 프롬프트 없이도 최신 AI Agent들은 저희가 준비한 문제를 꽤 잘 풀었습니다. 문제는 분량이었습니다. Agent가 쏟아내는 응답은 제한 시간 안에 사람이 전부 소화할 수 없었고, 이걸 어떻게 처리하는지가 인터뷰의 성패를 갈랐습니다.

좋은 결과를 낸 후보자분들은 응답을 단락별로 빠르게 스캔하고, 자신의 예상을 조정하며 인사이트가 나올 가능성이 높은 쪽으로 문제를 좁혀갔습니다. 반대로 잘 풀지 못한 분들은 Agent의 응답을 거의 읽지 않고 처음 궁금해한 방향으로 질문만 쌓았습니다.

문제를 설계한 입장에서는 Agent가 정답을 그대로 말할 때 가슴이 철렁했습니다. 그런데 같은 답을 받아도 사람마다 처리하는 방식이 달랐고, 그 차이가 곧 저희가 보려던 역량이었습니다.

Logan — "모호한 문제를 모호한 채로 Agent에게 넘기는 것이 가장 큰 함정이었습니다."

이번에 에이전트 기반의 인터뷰 문제를 준비하면서, 실제로 우리가 일하는 환경과 유사한 인터뷰 환경을 제공하고자 했습니다. 문제를 직접 설계하고 인터뷰를 진행해 보니, 전통적인 problem solving 문제와는 상당히 다른 영역에서의 챌린지가 있다는 것을 느꼈습니다.

후보자들이 자주 빠지는 함정이 하나 있었습니다. 모호한 문제를 모호한 상태 그대로 에이전트에게 통째로 넘기는 것입니다. 에이전트는 어떻게든 답을 만들어내지만, 이렇게 되면 쉽사리 잘못된 방향으로 빠집니다. 에이전트가 빠진 함정이나 잘못된 방향을 후보자 스스로도 인지하기 어렵게 됩니다.

돌이켜보면 이는 인터뷰에서만의 이야기가 아닙니다. 에이전트에게 문제를 넘기기 전에, 우리가 먼저 상황의 모호성을 해소하고 문제와 접근 방향을 명확히 해야 한다는 것은 우리 모두가 알고 있는 원칙입니다. 하지만 에이전트가 손쉽게 답을 만들어주는 환경에서는 이 과정을 건너뛰고 싶은 유혹에 빠지기 쉽고, 이번 인터뷰를 통해 그 원칙의 중요성을 다시금 느낄 수 있었습니다.

인터뷰 설계는 팀의 철학을 정의하는 과정이다

이 작업을 하면서 우리가 배운 가장 중요한 것은 인터뷰 설계 자체에 관한 것이었습니다.

좋은 인터뷰 문제는 실제 업무를 닮아있어야 합니다. 후보자가 인터뷰에서 보여주는 방식이 입사 후 실제로 일하는 방식과 가까울수록, 효과적으로 역량을 파악할 수 있습니다.

반대로 인터뷰 문제가 실제 업무와 멀수록, 우리는 잘못된 사람을 뽑거나 좋은 사람을 놓칩니다.

새로운 문제를 만드는 과정은 결국 "우리 팀에서 잘하는 사람이란 어떤 사람인가"를 다시 쓰는 과정이었습니다.

이 문제를 처음 설계한 팀 외에서도 비슷한 반응이 나왔습니다. 인터뷰어로 처음 참여한 Kian은 이렇게 말했습니다.

동시에 개선이 필요한 부분도 짚어줬습니다. AI Agent를 활용하면 짧은 시간 동안 방대한 양의 텍스트가 생성되는데, 사소한 프롬프트 차이로 후보자 간 편차가 커질 수 있다는 점입니다. 그는 인터뷰어가 유효한 방향으로 충분히 가이드를 주고, 후보자가 그 방향에 맞춰 문제를 정의하고 에이전트를 활용하는지를 함께 평가하는 방식으로 보완이 필요하다고 제안했습니다.

그리고 결국 자신의 팀에도 이 인터뷰 방식을 도입하기로 했습니다. "에이전트를 쓰면서 실제 현업에 가까운 환경에서 풀 수 있는 문제가 있다는 게 큰 메리트"라는 이유였습니다.

아직 끝나지 않았다

이 인터뷰 설계가 완성형이라고 생각하지 않습니다. AI 툴은 계속 바뀌고, 에이전틱 개발의 패턴도 진화합니다. 그렇기 때문에 우리의 인터뷰도 함께 진화해야 합니다.

그럼에도 한 가지는 분명합니다. AI 네이티브 연구자·개발자를 찾으려면, 우리가 먼저 AI 시대에 맞는 질문을 던져야 한다는 사실입니다.

그 질문을 계속 다듬는 것, 그게 지금 우리가 하고 있는 일입니다.

트웰브랩스는 영상 AI의 근본적인 문제를 풀고 있습니다.

AI 시대에 맞는 방식으로 문제를 정의하고, 함께 답을 만들어갈 분들을 찾고 있습니다 → 트웰브랩스 | 채용​