AI로 인해 '즉전력'의 정의가 바뀌었다. 신입 엔지니어에게 요구하는 3가지 축을 정리한다

나는 지난 5년 정도 신입 엔지니어 채용에 관여해 왔다. 면접 평가 시트, 코딩 테스트(Coding Test) 문항, 기술 질문 템플릿. 몇 번이고 다시 써왔다고 생각했지만, 최근 1~2년 사이 판단 기준 자체가 바뀌어 버렸다고 느끼고 있다. AI가 작성할 수 있는 범위의 코드를 작성할 수 있는 것이 신입 엔지니어의 강점이 되는 시대는 이미 끝났다.

최근 면접에서는 이런 일이 일어나고 있다. 코딩 테스트 점수는 높다. 기본적인 알고리즘(Algorithm)도 작성할 수 있다. 그런데도 현장에 투입되고 나면 "무엇을 만들어야 할지 모르겠다", "사양(Specification)을 전달받아도 착수가 늦다"라는 케이스가 눈에 띄게 늘었다.

이유는 간단하다. AI가 일상적으로 코드를 작성하는 시대가 되면서, 코딩 테스트 점수가 '현장에서 움직일 수 있는가'와 직결되지 않게 되었기 때문이다. AI로 보완할 수 있는 능력과 AI로는 보완할 수 없는 능력의 경계가 신입 엔지니어의 평가 축을 다시 만들고 있다.

나는 낮 동안 신입 대상의 워크 샘플형 인턴십인 'N한 인턴'이라는 사업을 지켜보고 있다. 소케이(早慶)·교토대(京大)급 학생들을 대상으로, 90분 동안 실무 과제를 풀게 하고 4개 축 × 20점 = 80점 만점으로 채점하는 구조다. 설계를 진행하며 알게 된 것은, 코딩 테스트에서는 절대 나타나지 않는 '3가지 축'이 있다는 사실이었다.

평가 축	코딩 테스트로 알 수 있는가	실무에서의 중요도
알고리즘 구현력	◎	중
...

아래 3가지. 이곳이 지금의 신입 엔지니어 채용에서 정말로 보아야 할 포인트라고 나는 생각한다.

사양서가 제대로 작성된 현장은 현실적으로 거의 없다. 스프린트(Sprint) 중에 전달되는 요구사항은 대개 모호하다. "사용자가 사용하기 편한 폼", "적절한 느낌의 CSV 출력", "적절한 유효성 검사(Validation)" —— 이런 말들로부터 스스로 무엇을 만들지 결정하는 능력이 필요하다.

AI에게 "적절한 유효성 검사"라고 던져도 무난한 것밖에 돌아오지 않는다. 여기서 힘을 발휘하는 것은 사용자가 어떤 상황에서 어떻게 사용하는지를 상상하고, "이번에는 이 관점의 유효성 검사가 본질적으로 필요하다"라고 결정할 수 있는 해상도다. 이것은 코딩 테스트에서는 절대 물을 수 없다.

우리 팀에서는 이 축을 **"모호한 입력에 대해 자신의 전제 조건을 얼마나 명시적으로 작성할 수 있는가"**로 평가하고 있다. 구현 그 자체보다, 구현하기 전에 어떤 가정을 두었는가가 현장에서는 유효하다. 결국 신입의 성장 가능성은 여기서 결정된다.

신입에게 "일단 돌아가는 코드로도 괜찮다"라고 건네면, 당연히 돌아가는 코드를 작성해 온다. 문제는 그 이후다.

• 왜 이 라이브러리(Library)를 선택했나?
• 왜 이 데이터 구조(Data Structure)인가?
• 왜 여기서 루프(Loop)를 멈췄나?

여기에 답할 수 있느냐에 따라 현장에서의 성장 폭이 완전히 다르다. 이것은 경험량의 문제가 아니라, "자신이 지금 선택한 선택지 옆에 있었던 선택지를 제대로 비교하고 있는가"라는 사고의 습관에 관한 이야기다.

신입 단계에서 이것이 가능한 학생은 적다. 다만, 가능한 학생은 1할 정도 있다. 코딩 테스트에서는 이 1할이 드러나지 않기 때문에 별도의 평가 도구가 필요하다.

평가 예시 (축 2: 설계 판단과 트레이드오프 (Trade-off))
제출된 코드에 대해 다음을 구두 또는 리포트로 질문:
1. 이 데이터 구조를 선택한 이유는?
...

채점하다 보면 알게 되지만, 답변의 내용보다 답변 방식의 구조가 더 많은 정보를 담고 있다. 비교한 뒤에 선택하는 습관이 몸에 밴 학생은 선택하지 않은 선택지에 대해서도 자연스럽게 이야기해 준다. 반대로 그런 습관이 없는 학생은 "일단 이것으로 했습니다"에서 멈춘다.

이것은 최근 특히 신경 쓰고 있는 축이다. AI를 사용할 수 있느냐의 문제가 아니다. AI로 보완할 수 있는 영역과 자신의 판단으로 채워야 하는 영역을 구분할 수 있는가를 보고 있다.

신입 중에는 AI의 출력을 그대로 제출하는 학생도 있다. 반대로 AI를 전혀 사용하지 않고 오래된 방식으로 작성해 오는 학생도 있다. 둘 다 현장에서는 약하다.

강한 것은 AI에게 거친 구현(Rough implementation)을 내보게 한 뒤, 자신의 판단으로 "이 부분은 다르다"라고 수정할 수 있는 학생이다. 이것은 지식량의 문제가 아니라, 자신의 판단 축을 가지고 있느냐의 문제다. 신입 때 이것이 몸에 밴 학생은 현장에서 2~3년 치의 차이를 만들어낸다.

다만, 이것을 면접에서 끌어내는 것은 어렵다. "AI를 어떻게 사용합니까?"라고 물으면 누구나 그럴싸한 대답을 내놓는다. 실제로 사용하게 하여 그 손놀림을 지켜볼 수밖에 없다.

결국, 나의 현시점에서의 결론은 이렇다. 신입 엔지니어 채용은 면접 전에 "실무 과제의 결과물 + 사고 프로세스 리포트 1장"을 보는 것이 가장 효율적이다.

이유는 단순하다. 면접 자리에서 위의 3가지 축을 끌어내는 것이 어렵기 때문이다. 긴장한 학생에게 "당신의 설계 판단을 알려주세요"라고 물어도 제대로 된 답변은 거의 돌아오지 않는다. 반면, 90분 동안 과제를 해결한 직후의 결과물에는 사고 프로세스 (Thinking Process)가 제대로 남아 있다. 이를 평가하는 것이 면접에서 심층 질문을 던지는 것보다 압도적으로 정확하다.

내가 낮과 밤으로 지켜보고 있는 사업(N한정 인턴)이 바로 이러한 설계다. 1인당 3,300엔의 비용으로 90분간 실무 과제를 풀게 하고, 사고 프로세스를 포함하여 80점 만점(4개 축 × 20점)으로 채점하여 기업에 전달한다. 소케이(早慶)·교토대 클래스의 학생들을 중심으로 운영하고 있으며, 면접 전 스크리닝 (Screening) 설계로서 현시점에서 가장 적합한 방식이라고 생각한다.

채용 프로세스 (Recruitment Flow) 전체를 재구축한다기보다, 면접 단계 직전에 이 한 단계를 삽입하는 것뿐이다. 도입 비용 대비 면접의 정밀도가 달라진다.

실무 시험을 채용 프로세스에 도입할 때, 내가 주의하는 점은 다음 세 가지다.

과제의 난이도를 "업무에 필요한 수준"에 맞춘다. 너무 어려우면 우수한 학생도 탈락한다. 너무 쉬우면 차별화가 되지 않는다. 경험상으로는 "현장의 주임급이 30분 내에 풀 수 있는 정도"가 적당하다.

채점 루브릭 (Rubric)을 사전에 공유하지 않는다. 사전에 공유하면 해당 축에 최적화된 답변이 돌아온다. 채점하는 측만 이를 보유해야 한다.

AI의 이용은 허가해도 괜찮다. 단, "어떻게 사용했는지"를 신고하게 한다. 숨기게 하는 것보다 사용법을 보는 것이 훨씬 더 많은 정보량을 제공한다. 이는 축 3의 평가 그 자체와 직결된다.

신입 엔지니어의 평가 축은 AI의 보급으로 확실히 변했다. 이는 "변하는 것이 좋다"의 문제가 아니라, "이미 변해버렸다"는 이야기라고 생각한다. 코딩 테스트 (Coding Test) 점수가 높아도 현장에서 움직이지 못하는 학생이 늘어나고 있는 이유는, 평가 축이 현실을 따라가지 못하고 있기 때문이다.

나는 지난 몇 년간 그 격차를 메우는 설계를 내 팀과 사업 양쪽에서 수행해 왔다. 도달한 결론은 심플하다. 면접 전에 사고 프로세스가 포함된 리포트 1장을 읽는 것. 그것만으로 채용 정밀도는 상당히 개선된다.

다만, 이 이후의 긴 이야기는 현장에서 직접 쓰면서 생각할 수밖에 없다.

• 서비스 개요 (기업용): https://ngen-intern.jp/company
• 사용 가이드: https://ngen-intern.jp/company/guide
• 문의하기: https://ngen-intern.jp/contact