채용 공고와 현장 사이의 이상한 간극
요즘 테크 채용 공고를 보면 묘한 이중성이 눈에 띈다. 한쪽에선 'AI 네이티브 개발자', 'LLM 워크플로우 경험자'를 외치면서, 정작 인터뷰 룸에선 화이트보드 앞에 세워놓고 손으로 정렬 알고리즘을 짜라고 한다. dev.to에 올라온 한 개발자의 글이 이 모순을 정면으로 건드렸다. "AI가 90%를 처리하는데 왜 우리는 아직도 암기 코딩을 증명해야 하나?" 라는 질문이다.
이건 단순한 불만이 아니다. 팀 리드 입장에서 이 질문은 훨씬 더 날카롭게 읽힌다. 우리가 측정하는 역량이 실제로 팀에 필요한 역량인가?
'코딩 능력'의 정의가 이미 바뀌었다
솔직히 말하면, 나는 신규 팀원에게 더 이상 알고리즘 암기력을 기대하지 않는다. 대신 내가 보는 건 세 가지다.
첫째, AI 출력을 읽고 판단하는 능력. 코드를 직접 쓰는 것보다 AI가 생성한 코드에서 논리적 결함, 엣지 케이스 누락, 보안 취약점을 짚어내는 능력이 훨씬 중요하다. Cursor나 Claude Code가 뱉어낸 300줄짜리 컴포넌트를 5분 안에 검토할 수 있느냐 없느냐가 실제 팀 속도를 가른다.
둘째, 아키텍처 판단력. AI는 지시받은 대로 구현한다. 어떤 데이터 모델을 쓸지, 어느 레이어에서 관심사를 분리할지, 어떤 트레이드오프를 감수할지—이 결정은 여전히 사람의 몫이다. 앞서 언급한 dev.to 글의 표현을 빌리자면, "건축가는 벽돌을 직접 굽지 않는다. 하지만 구조를 설계하는 건 반드시 건축가여야 한다."
셋째, 시스템 오너십 감각. AI가 코드를 썼더라도 그 코드가 프로덕션에서 어떻게 동작할지, 장애 시 어디를 봐야 할지를 아는 사람이 팀에 있어야 한다. 이건 문서가 아니라 경험과 책임감에서 나온다.
AI가 지워버린 것: 협업의 마찰
그런데 역량 정의보다 더 조용하고 위험한 문제가 있다. 같은 dev.to에서 한 시니어 개발자가 쓴 글이 이걸 정확히 짚었다. 그는 AI를 활용해 생산성은 올랐지만, 어느 순간 AI를 토론 상대로 쓰고 있다는 걸 깨달았다고 고백했다.
문제는 AI가 '예스맨'이라는 점이다. 아무리 비판적 페르소나를 프롬프트로 주입해도, AI는 결국 사용자를 설득하거나 자기 신념을 끝까지 지키지 않는다. 확신도 없고, 틀릴 위험도 없고, 동료가 용기 있게 내 설계를 반박할 때 생기는 그 마찰이 없다.
AI-First 전환을 추진하면서 팀 내 리뷰 회의가 줄고, 페어 프로그래밍 세션이 사라지고, 아키텍처 논쟁이 Slack 스레드 대신 각자의 채팅창으로 흡수되는 팀을 여럿 봤다. 속도는 올라간 것처럼 보인다. 하지만 그 속도가 팀의 집단 판단력 위에 서 있는 건지, 아니면 개인의 AI 의존 위에 서 있는 건지—이 둘은 전혀 다른 이야기다.
팀 리드가 설계해야 할 것
AI-First 전환에서 내가 실제로 챙기는 구조는 두 가지다.
하나, 역량 평가 기준 재설계. 채용과 온보딩에서 '손 코딩 테스트'를 '코드 리뷰 테스트'로 바꾸는 것부터 시작했다. AI가 생성한 코드 블록을 주고 "이 코드의 문제점을 찾아라", "이 설계 결정을 왜 이렇게 했는지 설명하라"는 질문이 훨씬 더 현장에 가깝다. 암기력이 아니라 판단력을 본다.
둘, 인간 협업 루프 의도적 설계. AI가 토론 공간을 채우기 전에, 팀이 실시간으로 부딪히는 구조를 만들어야 한다. 주 1회 아키텍처 리뷰를 고정 의제로 넣고, AI 출력에 이의를 제기하는 것을 팀 문화로 명시화한다. "AI가 이렇게 제안했는데 왜 다르게 결정했나?"를 기록에 남기는 것—이게 팀의 판단력이 축적되는 방식이다.
전망: 기준을 다시 쓰지 않으면 모순은 심화된다
채용 시장의 '수동 코딩 요구'는 단기적으로 사라지지 않을 것이다. 조직의 관성이 평가 기준 변화보다 훨씬 느리기 때문이다. 하지만 실제로 AI-First 팀을 운영하는 리드라면, 이 간극을 방치할 여유가 없다. 잘못된 역량 기준으로 채용한 팀원은 잘못된 방향으로 성장하고, 잘못된 성장은 팀 전체의 기술 부채로 돌아온다.
AI가 코드를 쓰는 시대에 개발자에게 기대해야 할 건 더 빠른 타이핑이 아니라, 더 날카로운 판단과 더 깊은 협업이다. 그리고 그 두 가지는 AI가 대신해주지 않는다. 팀 리드가 의도적으로 설계해야 한다.