AI가 할 수 없는 나머지 20%를 위해 채용하는 방법 (그리고 왜 지원자에게 처음부터 코딩하도록 요구하는 것을 그만두었는가)

몇 주 전 저는 "AI 에이전트는 우리 코드의 80%를 훌륭하게 처리합니다. 나머지 20%가 우리가 여전히 시니어(Seniors)를 필요로 하는 이유입니다."라는 글을 게시했습니다.

그 글은 25개의 반응과 34개의 댓글을 얻었습니다. 그중 몇몇 댓글은 서로 다른 표현으로 동일한 질문을 던졌습니다.

"채용할 때 그 20%를 실제로 어떻게 측정하나요?"

타당한 질문입니다. 저는 첫 번째 글에서 명확한 답을 가지고 있지 않았기에 그 질문을 피했습니다. 이제는 답을 알고 있습니다. 적어도, 우리가 이전에 시도했던 그 어떤 것보다 더 잘 작동하는 프로세스를 갖추게 되었습니다.

이것이 바로 그 답입니다.

AI가 명확하게 만들기 전부터 기존의 인터뷰는 망가져 있었습니다

수년 동안 우리는 표준적인 플레이북(Playbook)을 따랐습니다. 화이트보드 문제. 제한 시간이 있는 코딩 연습. "45분 안에 REST 엔드포인트(REST endpoint)를 구축하세요." 여러분도 익숙한 방식일 것입니다.

이 인터뷰가 실제로 테스트했던 것은 이것입니다: 이 사람이 누군가가 지켜보는 가운데, 압박감을 느끼며, 기억력만으로 문법적으로 올바른 코드를 작성할 수 있는가?

그것은 실제 기술입니다. 다만 더 이상 중요하지 않은 기술일 뿐입니다.

AI는 코드 작성 부분을 처리합니다. AI가 완벽하게 처리한다는 뜻은 아닙니다. AI가 틀리는 20%에 대해 저는 별도의 글을 썼습니다. 하지만 보일러플레이트(Boilerplate), CRUD, API 래퍼(API wrappers), 표준 패턴(Standard patterns)에 해당하는 80%는 어떨까요? 에이전트(Agent)가 몇 초 만에 생성해낼 것입니다. 깔끔하게, 타입(Typed)이 지정된 상태로 말이죠. 아마 제가 선택했을 것보다 더 나은 변수명(Variable names)을 사용할지도 모릅니다.

따라서 만약 제가 누군가를 채용하면서, 그 사람이 에이전트가 이미 더 빠르게 할 수 있는 일을 할 수 있는지 테스트한다면, 저는 정확히 무엇을 배우고 있는 것일까요?

그들이 압박감 속에서도 타이핑을 할 수 있다는 것? 좋습니다. 에이전트도 할 수 있습니다. 그리고 에이전트는 긴장하지도 않습니다.

우리가 현재 실제로 진행하는 인터뷰

우리는 지원자에게 처음부터 코드를 작성하도록 요구하는 것을 그만두었습니다. 대신, 우리는 AI 에이전트가 이미 작성한 코드를 그들에게 건네줍니다.

코드는 괜찮아 보입니다. 우리가 포함시킨 테스트를 통과합니다. 변수명은 깔끔합니다. 타입은 정확합니다. 주니어(Junior)가 본다면 "배포하세요(ship it)"라고 말할 것입니다.

하지만 그것은 틀렸습니다.

시스템을 중단시킬 정도로 틀린 것은 아닙니다. 하지만 3주 후에 비용을 발생시키는 방식으로 틀렸습니다. 오직 _결과(consequences)_를 생각하는 사람만이 잡아낼 수 있는 방식으로 틀렸습니다.

구체적인 사례는 이렇습니다. 우리는 지원자에게 결제 확인을 처리하는 웹훅 핸들러(webhook handler)를 제공합니다. 핸들러는 잘 작동합니다. 이벤트를 수신하고, 데이터베이스를 업데이트하며, 200 상태 코드를 반환합니다. 깔끔한 코드입니다.

빠져 있는 것: 멱등성 (idempotency). 만약 은행이 웹훅을 재시도한다면 — 그리고 은행은 항상 재시도합니다 — 핸들러는 결제를 두 번 처리합니다. 고객은 두 번 결제됩니다. 우리는 FCA(영국 금융행위감독청)로부터 민원을 받게 됩니다. 코드는 정확하지만, 시스템은 망가진 것입니다.

또 다른 사례로, 상태 전이(state transitions)가 포함된 결제 흐름을 보여줍니다. pending(대기)에서 authorised(승인)를 거쳐 settled(결제 완료)로 이어집니다. 보기에는 맞습니다. 하지만 결제가 settled에서 다시 pending으로 돌아갈 수 있는 경로가 존재합니다. 이는 불법적인 상태 전이입니다. 우리 도메인에서 이는 이미 가맹점 계좌에 들어간 돈이 환불 기록 없이 이론적으로 다시 회수될 수 있음을 의미합니다. 존재해서는 안 될 전이에 대해 테스트를 작성하지 않았기 때문에, 어떤 테스트도 이를 잡아내지 못합니다.

우리는 지원자에게 이 코드를 작성하라고 하지 않습니다. 검토(review)하라고 합니다. 작성하는 것이 아니라

한 엔지니어가 이렇게 말합니다: "멱등성 키 (idempotency key)가 없습니다. 이는 은행으로부터의 네트워크 재시도 (network retry)가 결제를 이중 처리하게 된다는 뜻입니다. 고객은 두 번의 출금을 확인하게 될 것이고, 고객 지원 팀에는 티켓이 접수될 것입니다. 귀하는 매입 은행 (acquiring bank)에 분쟁을 제기해야 하며, 환불에는 영업일 기준 5~7일이 소요됩니다. 그리고 만약 이런 일이 대량으로 발생한다면, 귀하는 규제 보고 의무 (regulatory reporting obligation)를 지게 됩니다."

동일한 관찰입니다. 하지만 깊이는 완전히 다릅니다. 첫 번째 사람은 패턴을 알고 있습니다. 두 번째 사람은 그 패턴이 누락되었을 때 하류 (downstream)에서 어떤 일이 발생하는지를 알고 있습니다.

그러한 하류에 대한 인식 — 버그가 비즈니스를 통해 앞으로 어떻게 전개되는지 추적할 수 있는 능력 — 이 바로 그 20%입니다.

이력서가 아닌 의도를 보고 채용하라

우리의 채용 프로세스가 변한 이유는 우리의 채용 철학이 먼저 변했기 때문입니다.

우리는 이력서를 채용하지 않습니다. 우리는 의도 (intent)를 채용합니다. 세 가지 사례를 들어보겠습니다.

한 개발자의 이력서에는 "기술적 숙련도 (Technical Proficiency)" 항목 아래에 단 하나의 기술이 적혀 있었습니다: 구글링 (Googling). 과장이 아닙니다. 실제로 그렇게 적혀 있었습니다. 학사 학위 (B.Sc.)가 있었지만, 화려한 인턴십도 없었고 GitHub에 개인 프로젝트도 없었습니다. 그저 자신이 무엇을 아는지에 대해 정직했고, 모르는 것을 배우는 데에는 끈질긴 사람이었습니다. 오늘날 그 사람은 우리의 가맹점 대상 앱 (merchant-facing app) 전체를 책임지고 있습니다.

또 다른 사람은 추천이나 소개 없이 그저 구직을 위해 우리에게 콜드 메시지 (cold-message)를 보냈습니다. 면접에서 그들은 조용했습니다. 수줍어하는 것이 아니라 조용했습니다. 말하기보다 더 많이 들었습니다. 말을 할 때는 곧바로 해결책으로 들어갔습니다. 서론도, 얼버무림도, "음, 상황에 따라 다르겠지만" 같은 말도 없었습니다. 그저 "여기에 문제가 있고, 저는 이렇게 고칠 것이며, 무엇이 잘못될 수 있습니다"라고 말할 뿐이었습니다.

세 번째 사람은 인턴으로 시작했습니다. 그들은 현재 우리의 오픈 뱅킹 (Open Banking) 연동을 엔드 투 엔드 (end-to-end)로 구축하고 있습니다. 보조하는 것이 아닙니다. 유지보수하는 것도 아닙니다. 직접 구축하고 있습니다.

이들의 공통점은 학위나 기술 스택 (tech stack), 혹은 경력 연수가 아닙니다. 세 가지입니다: 호기심 (curiosity), 주인 의식 (ownership), 그리고 틀릴 수 있다는 것을 인정하는 태도 (willingness to be wrong).

첫 번째 유형은 모르는 것을 안다고 가장하지 않았습니다. 두 번째 유형은 양으로 인상을 남기려 하지 않았고, 명확함(clarity)으로 인상을 남겼습니다. 세 번째 유형은 누군가 더 어려운 문제를 할당해주기를 기다리지 않았습니다. 문제는 그곳에 있었고, 그들은 시도하는 것을 두려워하지 않았기에 스스로 그 문제들에 맞춰 성장했습니다.

그들 중 누구도 과거의 코딩 인터뷰(coding interview)를 특별히 잘 통과하지는 못했을 것입니다. 하지만 그들 모두는 AI 에이전트(AI agent)의 결과물을 검토하기를 원하는 바로 그 유형의 엔지니어들입니다.

20%는 단순한 코드가 아닙니다 — 그것은 디자인 씽킹 (design thinking)입니다

대부분의 "AI와 채용"에 관한 글들이 놓치고 있는 사실이 하나 있습니다. 중요한 나머지 20%는 단순히 결제 로직(payment logic)에서 버그를 잡아내는 것에 국한되지 않습니다. 그것은 아직 명세(spec)가 존재하지 않는 문제들에 대해 어떻게 사고해야 하는지를 아는 것에 관한 것입니다.

Atoa에 합류하기 전, 저는 CES에서 제품을 선보이는 고객들과 함께 일하며 수년간 디자인 씽킹 (design thinking) 분야에서 시간을 보냈습니다. 그중 한 프로젝트가 기억에 남습니다. 세계적인 초콜릿 제조업체가 인간의 감정 — 분노, 혐오, 슬픔, 행복, 겁쟁이(Wimpy) — 을 기반으로 한 일련의 초콜릿 시리즈를 출시하고 싶어 했습니다. 브리프(brief)의 내용은 다음과 같았습니다: 사람의 감정을 실시간으로 포착하고, 그에 맞는 초콜릿을 추천하며, 소셜 미디어에서 바이럴(viral)이 되도록 만드는 소프트웨어를 구축할 것.

이제 마케팅 매니저가 당신의 사무실로 걸어 들어와 책상 위에 이 내용을 내려놓는다고 상상해 보십시오. 브리프는 "바이럴이 되게 만들 것"입니다. 당신은 어떤 플랫폼을 기반으로 구축하겠습니까? 그 경험은 어디에 존재해야 합니까? 누군가가 그것을 공유하고 싶게 만드는 기능은 무엇입니까?

기술적으로는 무엇이든 가능하다는 가정하에 생각하십시오. 기술은 제약 사항이 아닙니다. 당신의 사고방식이 제약 사항입니다.

여기 필터가 있습니다. 만약 당신의 첫 번째 답변이 "모바일 앱과 웹 앱을 만들겠습니다"라면, 그것은 즉시 탈락입니다. 모바일과 웹이 잘못된 기술이기 때문이 아닙니다. _왜(why)_를 생각하기 전에 _어떻게(how)_로 건너뛰었기 때문입니다. 당신은 바이럴(virality)을 해결하기도 전에 전달 방식(delivery)을 해결하려 하고 있습니다. 브리프는 디자이너처럼 생각할 것을 요구했는데, 당신은 개발자처럼 생각하고 있는 것입니다.

흥미로운 답변은 질문에서 시작됩니다. 타겟 오디언스(audience)는 누구인가? 그들은 이미 어디에서 시간을 보내고 있는가? 무엇이 사람들을 스크롤을 멈추게 하고 무언가를 공유하게 만드는가? 3초의 훅(hook)은 무엇인가? 초콜릿 브랜드는 공유가 일어날 때마다 어떤 이득을 얻는가? 유료 미디어(paid media) 없이도 이것을 성장하게 만드는 메커니즘은 무엇인가?

이제 여러분에게 도전 과제를 드립니다. 여러분이라면 이것에 어떻게 접근하시겠습니까? 댓글로 남겨주세요. 기술 스택(tech stack)이 아니라, 그 _사고방식(thinking)_을 말이죠. 이 브리프(brief)를 실제로 바이럴(viral)이 될 수 있는 무언가로 어떻게 분해(decompose)하시겠습니까?

단 하나의 정답은 없습니다. 그것이 핵심입니다. 이것은 디자인 씽킹(design thinking) 연습이며

대부분의 엔지니어는 해피 패스 (happy path)에 대해 생각합니다. 결제가 완료됩니다. 웹훅 (webhook)이 실행됩니다. 데이터베이스 (database)가 업데이트됩니다. 끝입니다.

상위 20%의 엔지니어는 언해피 패스 (unhappy path)를 먼저 생각합니다. 웹훅이 두 번 실행되면 어떻게 될까요? 데이터베이스 쓰기 (write)에는 성공했지만 응답이 타임아웃 (timeout)되면 어떻게 될까요? 은행은 "예"라고 하는데 우리 시스템은 "아니오"라고 하여, 양측 모두 동의하지 않는 상태로 돈이 존재하게 되면 어떻게 될까요?

만약 지원자의 첫 번째 본능이 "이것이 어떻게 작동하는가?"라면 — 그것은 괜찮습니다. 하지만 그들의 첫 번째 본능이 "이것이 어떻게 망가지는가?"라면 — 그것이 바로 신호입니다.

그들은 무엇인가를 작성하기 전에 실패 모드 (failure modes)에 대해 질문합니까?

우리는 코드 리뷰 (walkthroughs) 과정에서 이를 관찰하기 시작했습니다. 어떤 지원자들은 즉시 수정 사항을 타이핑하기 시작합니다. 반면 다른 이들은 질문을 먼저 합니다. "이 웹훅들의 재시도 정책 (retry policy)은 어떻게 되나요?" "데드 레터 큐 (dead letter queue)가 있나요?" "이 서비스가 다운되면 진행 중인 결제 (in-flight payments)는 어떻게 되나요?"

먼저 질문하는 이들이 거의 항상 더 뛰어난 엔지니어입니다. 질문하는 것이 실행하는 것보다 본질적으로 더 낫기 때문이 아닙니다. 상위 20%의 영역 — 즉, 엣지 케이스 (edge cases), 레이스 컨디션 (race conditions), 규제 요구 사항 (regulatory requirements)을 처리하는 코드의 영역에서는 — 잘못된 것을 만드는 비용이 질문을 하나 더 하는 비용보다 더 높기 때문입니다.

그들은 단순히 무엇을 선택했는지가 아니라, 자신이 내린 트레이드오프 (tradeoff)를 설명할 수 있습니까?

이것은 제가 연차와 상관없이 모든 지원자에게 던지는 질문입니다: "의도적으로 더 나쁜 옵션을 선택했던 기술적 결정에 대해 말씀해 주세요."

흥미로운 지원자들은 답변을 가지고 있습니다. "비동기 (async) 방식이 더 탄력적(resilient)이었겠지만, 감사 추적 (audit trail)을 더 쉽게 파악할 수 있었기 때문에 두 서비스 간에 동기 (synchronous) 호출을 선택했습니다." "엣지 케이스가 아직 명확히 파악되지 않았고 잘못된 것을 자동화하고 싶지 않았기 때문에, 자동화하는 대신 수동 프로세스를 유지했습니다."

그 20%는 바로 이와 같은 결정들로 가득 차 있습니다. 정답이 항상 기술적으로 더 우월한 것인 것은 아닙니다. 때로는 새벽 2시에 디버깅하기 더 쉬운 답이 정답일 수도 있고, 더 깔끔한 감사 추적 (audit trail)을 생성하는 답이 정답일 수도 있으며, 혹은 신입 엔지니어가 세 페이지 분량의 문맥을 읽지 않고도 이해할 수 있는 답이 정답일 수도 있습니다.

주니어 교육 파이프라인 문제

첫 번째 글을 올린 후 저를 잠 못 들게 했던 질문은 이것입니다. 만약 AI가 코드의 80%를 처리한다면, 주니어들은 시니어들을 가치 있게 만드는 그 판단력을 어떻게 쌓을 수 있을까요?

과거에 그 80%는 훈련장이었습니다. CRUD 엔드포인트를 작성하는 법을 배웁니다. 데이터베이스를 연결하는 법을 배웁니다. HTTP 에러를 처리하는 법을 배웁니다. 지루한 코드에서 실수를 저지르고, 리뷰 과정에서 그 실수를 잡아내면서, 여러분은 서서히 덜 지루한 코드를 작성하기 위한 직관을 발달시킵니다.

만약 에이전트 (agent)가 첫날부터 그 모든 것을 대신 작성해 준다면, 여러분은 실제로 무엇을 배우고 있는 것일까요?

이것은 실제적인 문제입니다. 그리고 "그냥 AI를 사용하게 두라"는 것은 정답이 아닙니다. 왜냐하면 AI를 잘 사용하는 데에는 여러분이 쌓아 올려야 할 바로 그 판단력이 필요하기 때문입니다.