올해 들어온 신입이 다르다
올해 3월, 우리 팀에 신입이 한 명 들어왔다. 금융IT 경력 20년 동안 수많은 신입을 맞이했지만, 이번에는 확실히 달랐다. 입사 첫 주부터 그 차이를 느꼈다.
온보딩 과제로 간단한 내부 관리 화면을 하나 만들어보라고 했다. 예전 신입들은 보통 이 과제에 2주를 썼다. 기획 문서 읽고, 기존 코드 뒤지고, 선배한테 이것저것 물어보고, 한두 번 삽질하고, 그러다 어느 순간 “아, 이 구조가 이래서 이렇게 된 거구나” 하는 깨달음의 순간이 온다. 그게 보통의 성장 과정이었다.
그런데 올해 신입은 사흘 만에 완성본을 들고 왔다. 화면 구성도 깔끔했고, 예외 처리도 나름 되어 있었고, 심지어 코드 스타일이 우리 팀 컨벤션과 꽤 비슷했다. 놀라서 물었다.
“이거 어떻게 이렇게 빨리 했어?”
신입은 아무렇지 않게 대답했다. “AI한테 기존 코드 패턴 분석시키고, 요구사항 넣어서 초안 뽑은 다음에 수정했습니다.” 당당했고, 실제로 결과물의 품질도 나쁘지 않았다.
첫 반응은 순수한 감탄이었다. ‘세상 많이 변했구나. 요즘 애들은 정말 다르네.’ 팀원들도 비슷한 반응이었다. 일부는 “우리도 저렇게 했으면 야근 줄었을 텐데”라고 농담 섞인 부러움을 표했다. 한 달 정도는 모든 것이 순조로워 보였다.
신입의 생산성은 확실히 높았다. 코드 작성 속도, 문서 정리 속도, 심지어 회의록 작성까지 — 이전 세대 신입들과는 비교가 안 될 정도였다. 수치로만 보면 2~3년차 못지않은 아웃풋이었다. 팀 리더로서 뿌듯한 마음이 있었다.
하지만 어떤 불안이 마음 한구석에서 자라고 있었다. 처음에는 그 불안의 정체를 정확히 짚지 못했다. 결과물은 좋은데 뭐가 문제란 말인가. 구체적으로 꼬집어 말하기 어려운, 그런 종류의 불편함이었다.
놀라움 뒤에 찾아온 불안
불안의 정체가 드러나기까지 오래 걸리지 않았다. 입사 두 달째, 작은 장애가 하나 터졌다.
신입이 만든 관리 화면에서 특정 조건으로 조회하면 데이터가 중복 표시되는 버그였다. 심각한 건 아니었지만, 금융 시스템에서 숫자가 두 번 보이는 건 사용자에게 공포를 준다. 바로 수정해야 했다.
“여기 중복 조회 건, 원인 파악해서 수정해줄 수 있어?”
신입이 고개를 끄덕였다. 그리고 반나절이 지났다. 보통 이 정도 버그는 한두 시간이면 원인을 찾는다. 궁금해서 자리에 가봤다.
신입은 AI에게 에러 로그를 통째로 붙여넣고 “이 버그의 원인과 해결책을 알려줘”라고 물어보고 있었다. AI가 세 가지 가능한 원인을 제시했고, 신입은 첫 번째 해결책을 그대로 적용했다. 하지만 버그는 사라지지 않았다. 두 번째 해결책을 적용했다. 역시 안 됐다. 세 번째도 마찬가지.
그 다음에 신입이 한 행동이 결정적이었다. AI에게 다시 물었다. “방금 알려준 세 가지가 다 안 되는데, 다른 원인 알려줘.” AI가 또 세 가지를 제시했다. 신입은 다시 순서대로 적용하기 시작했다.
나는 조용히 지켜보다가 물었다.
“잠깐. 그 쿼리에서 조인이 왜 두 번 걸려 있는지 이해하고 있어?”
신입이 멈칫했다. 잠시 침묵이 흘렀다.
“…사실 이 테이블 관계가 정확히 어떻게 되는지 잘 모르겠습니다.”
그 순간 깨달았다. 불안의 정체는 이것이었다. 결과물은 있는데 이해가 없었다. 아웃풋은 나오는데 과정이 빠져 있었다. AI가 과정을 통째로 건너뛰게 해준 것이다.
신입을 탓하는 게 아니다. 그 신입은 똑똑했고 성실했다. 다만 이 시대가 만든 새로운 종류의 함정에 빠져 있었을 뿐이다. 그리고 사실 그 함정은 신입 혼자 만든 것이 아니었다. AI가 모든 답을 내려주는 환경에서, “답을 빨리 내라”고 재촉하는 조직 문화가 함께 만든 것이었다.
AI가 가려주는 것 — ‘과정의 공백’
이 에피소드를 팀 회고에서 공유했을 때, 10년차 시니어 한 명이 정곡을 찔렀다.
“예전에 신입이 삽질하면서 이상한 코드 짜면, 그걸 고쳐주면서 왜 이렇게 해야 하는지 가르칠 수 있었잖아요. 근데 지금은 AI가 처음부터 꽤 괜찮은 코드를 짜주니까, 뭘 모르는지를 모르는 거예요.”
정확한 진단이었다. AI 시대의 신입 교육에서 가장 어려운 점은 바로 이것이다. AI가 과정을 가려버린다. 예전에는 과정이 눈에 보였다. 삽질의 흔적이 코드에 남았고, 질문의 수준이 이해의 깊이를 드러냈다. 선배는 그 흔적을 보고 “아, 이 부분을 아직 모르는구나” 하고 개입 시점을 잡을 수 있었다.
지금은 다르다. AI가 중간 과정을 통째로 대행하기 때문에, 겉으로 드러나는 결과물만으로는 신입이 무엇을 알고 무엇을 모르는지 판단하기 어렵다. 마치 계산기를 주고 수학 시험을 보게 한 것과 같다. 답은 맞는데, 풀이 과정이 머릿속에 없다.
과정의 공백이 만드는 구체적인 문제들을 정리하면 이렇다.
- 디버깅 능력의 부재: 코드를 직접 짜보지 않았으니, 버그가 생겼을 때 어디를 의심해야 하는지 감이 없다. AI에게 물어봐도 AI는 실제 시스템의 맥락을 모르기 때문에 일반적인 답만 나열한다.
- 설계 감각의 결여: 왜 이 구조가 이렇게 되어 있는지, 왜 이 패턴을 쓰는지 이해하지 못한다. 기존 코드를 모방할 수는 있지만, 새로운 상황에서 적절한 판단을 내리지 못한다.
- 장애 대응 불능: 순조로울 때는 문제가 드러나지 않는다. 하지만 무언가 깨졌을 때 — 금융 시스템에서는 반드시 깨지는 순간이 온다 — 과정을 건너뛴 사람은 문자 그대로 얼어붙는다.
- 소통의 단절: 자기가 만든 코드를 설명하지 못한다. 코드 리뷰에서 “왜 이렇게 했어?”라고 물으면 “AI가 이렇게 해주길래요”라는 답이 돌아온다. 이 시리즈의 5화에서 말한 “AI가 시킨 대로 했어요”가 가장 처음 나타나는 지점이 바로 여기다.
오해하지 말아달라. AI를 쓰지 말라는 이야기가 아니다. AI는 분명히 강력한 도구다. 문제는 AI를 쓰는 타이밍이다. 기초가 잡히기 전에 AI에게 과정을 통째로 위임하면, 겉으로는 빠르게 성장하는 것 같지만 실제로는 모래 위에 건물을 올리는 것과 같다.
결과와 역량의 착시 — ‘달리기 전에 걷는 법을 배워야 한다’는 진부한 말이 진부하지 않은 이유
한 가지 비유를 들어보겠다. 내비게이션 앱이 없던 시절, 처음 운전면허를 따고 도로에 나서면 지도를 보면서 길을 찾았다. 길을 잘못 들어서 30분을 헤매기도 했고, 일방통행 골목에 갇혀서 식은땀을 흘리기도 했다. 그 삽질을 통해 도로 체계가 머릿속에 새겨졌다. ‘아, 이 동네는 이런 구조구나. 큰길에서 좌회전하면 여기로 나오는구나.’
내비게이션이 보편화된 후의 운전자는 다르다. 목적지를 찍으면 알아서 안내해준다. 매일 출퇴근하는 길조차 내비게이션 없이는 불안한 사람이 많다. 평소에는 문제가 없다. 하지만 앱이 먹통이 되거나, 도로가 통제되거나, 처음 가는 곳에서 내비 신호가 잡히지 않을 때 — 길에 대한 감각이 있는 사람과 없는 사람의 차이가 극명하게 드러난다.
코드를 짜는 일도 같다. AI가 내비게이션이라면, 기초 과정에서의 삽질은 도로 체계를 체득하는 시간이다. 삽질 없이 AI에게 목적지만 찍어주는 사람은, 내비게이션이 작동하는 한 빠르고 정확하다. 하지만 내비가 꺼지는 순간 — 시스템에 장애가 나고, 로그가 꼬이고, 문서에 없는 상황이 벌어지는 순간 — 스스로 길을 찾지 못한다.
금융IT에서 그런 순간은 반드시 온다. 연말 정산 시즌의 트래픽 폭주, 규제 변경에 따른 긴급 시스템 수정, 보안 사고 대응. 이런 상황에서 “AI한테 물어볼게요”는 통하지 않는다. 실시간으로 판단하고, 맥락을 읽고, 책임지는 결정을 내려야 한다. 그 능력은 과정을 경험한 사람에게만 있다.
20년 전, 내가 삽질로 배운 것
나도 한때 신입이었다. 2006년, 금융IT 업계에 첫 발을 디딘 해다. 그때는 AI는커녕 구글 검색도 지금처럼 만능이 아니었다. 스택오버플로우는 존재하지도 않았다(2008년 출범). 모르는 게 있으면 책을 뒤지거나, 선배한테 물어보거나, 직접 삽질하는 수밖에 없었다.
입사 3개월째 되던 날, 첫 번째 야근 장애 대응을 경험했다. 야간 배치 작업이 실패했다. 수만 건의 거래 데이터가 정상적으로 이관되지 않은 것이다. 새벽 2시에 전화가 왔고, 잠결에 사무실로 나갔다.
선배가 옆에 있었지만, 먼저 해보라고 했다. “로그부터 봐. 어디서 끊겼는지 찾아.” 나는 수천 줄의 로그를 눈으로 훑었다. 한 시간이 지나도 원인을 못 찾았다. 선배가 힌트를 줬다. “그 로그 말고, 이 로그를 봐. 시간 순서대로 따라가봐.” 또 한 시간. 겨우 의심가는 지점을 찾았다. “여기 이 쿼리가 타임아웃 난 것 같은데요.” “왜 타임아웃이 났을까?” “…데이터가 많아서요?” “데이터는 항상 이만큼이야. 왜 오늘만 느렸을까?”
결국 원인은 당일 적용된 인덱스 변경 때문이었다. 다른 팀에서 성능 개선을 위해 인덱스를 재구성했는데, 그게 우리 배치 쿼리의 실행 계획을 바꿔버린 것이다.
그 새벽에 배운 것은 인덱스 지식이 아니었다. 그건 나중에 문서로도 배울 수 있는 것이었다. 내가 진짜 배운 것은 ‘왜’를 끝까지 묻는 습관이었다.
- 로그에서 에러를 찾았다 → 왜 에러가 났지?
- 쿼리가 느려졌다 → 왜 오늘만 느렸지?
- 인덱스가 바뀌었다 → 왜 인덱스 변경이 이 쿼리에 영향을 줬지?
- 실행 계획이 달라졌다 → 왜 옵티마이저가 다른 경로를 택했지?
매 단계에서 ‘왜’를 물었고, 선배는 정답을 직접 알려주는 대신 “왜”를 더 물어보게 유도했다. 그 과정이 괴로웠지만, 그 새벽의 4시간이 이후 20년 커리어의 기반을 만들었다. 시스템 장애 앞에서 얼어붙지 않고 침착하게 원인을 추적하는 능력, 겉으로 드러난 현상 뒤에 숨은 진짜 원인을 찾아가는 감각 — 그것은 삽질 없이는 절대 체득할 수 없는 것이었다.
삽질이 ‘낭비’가 아닌 이유
20년이 지난 지금, 나는 그 새벽의 경험을 자주 떠올린다. 단순히 “옛날에는 힘들었지” 같은 향수가 아니다. 그 경험이 만들어준 사고 패턴이 여전히, 아니 AI 시대인 지금 오히려 더 중요해졌기 때문이다.
AI가 내놓는 답을 평가하려면, 그 답이 맞는지 틀린지 판단할 수 있는 기저 경험이 필요하다. 직접 삽질해본 사람은 AI의 답이 맞을 때 “맞아, 이건 이래서 맞는 거야”라고 확신할 수 있고, 틀렸을 때 “잠깐, 이건 좀 이상한데”라고 직감이 작동한다. 삽질 없이 AI의 답만 받아온 사람에게는 그 직감 자체가 없다.
이 시리즈의 6화에서 판단에 대해, 8화에서 맥락에 대해, 9화에서 창의적 도약에 대해 이야기했다. 그 모든 ‘사람만 할 수 있는 일’의 공통 전제 조건이 바로 과정의 체험이다. 과정을 겪어보지 않은 사람에게 판단력은 자라지 않고, 맥락을 읽는 감각은 형성되지 않으며, 기존 패턴 너머로 도약하는 창의성도 발현되지 않는다.
삽질은 낭비가 아니라 투자다. 다만 AI 시대의 삽질은 과거와 같아서는 안 된다. 방향 없이 헤매게 하는 것이 아니라, 의미 있는 방향으로 질문하게 만드는 것이 핵심이다. 그리고 그 질문의 출발점이 바로 ‘왜’다.
가르쳐야 할 단 하나 — ‘왜’를 끝까지 묻는 힘
금융IT 20년, 챗봇 운영 8년을 돌아보면서, AI 시대의 신입에게 가르쳐야 할 것이 무엇인지 오래 고민했다. 프로그래밍 언어? 프레임워크? 프롬프트 엔지니어링? 모두 중요하지만, 모두 시간이 지나면 바뀐다. 올해 배운 프레임워크가 3년 후에도 살아있을 거라는 보장은 없다.
결론은 의외로 단순했다. AI의 답 앞에서 ‘왜’를 묻는 습관. 이것 하나다.
‘왜’를 묻는다는 것은 단순히 의심하라는 뜻이 아니다. AI의 답을 받아들이기 전에 그 답의 구조를 이해하라는 뜻이다. AI가 “이렇게 하세요”라고 했을 때, “왜 이렇게 해야 하지? 다른 방법은 없나? 이 방법의 전제 조건은 뭐지? 우리 시스템에서도 이게 맞나?”를 묻는 것이다.
신입에게 이런 이야기를 하면 가장 많이 듣는 반응이 있다. “그러면 AI를 쓰는 의미가 없지 않나요?” 아니다. AI를 더 잘 쓰기 위해 ‘왜’를 묻는 것이다.
비유를 하나 더 들겠다. 좋은 요리사는 레시피를 따르되, 왜 이 순서로 조리하는지, 왜 이 온도가 필요한지, 왜 이 재료가 들어가는지를 이해한다. 그래서 재료가 바뀌거나 도구가 달라져도 응용할 수 있다. 레시피만 따르는 사람은 레시피에 없는 상황을 만나면 멈춘다. AI는 세상에서 가장 방대한 레시피북이다. 하지만 레시피 뒤에 숨은 원리를 이해하는 것은 요리사 — 즉 사람 — 의 몫이다.
‘왜’를 묻는 힘은 태생적인 재능이 아니다. 훈련으로 만들어지는 습관이다. 그리고 습관은 환경이 만든다. 신입이 ‘왜’를 묻는 환경을 만들어주는 것, 그것이 AI 시대에 선배가 할 수 있는 가장 가치 있는 일이다.
‘왜’가 키우는 세 가지 근육
이 시리즈를 1화부터 읽어오신 분들은 눈치챘을 수 있다. 내가 말하는 ‘왜’를 묻는 힘은, 사실 지난 아홉 편에 걸쳐 이야기한 ‘사람만 할 수 있는 일’들의 공통 뿌리다. ‘왜’를 습관적으로 묻는 사람에게는 세 가지 근육이 자란다.
첫 번째 근육: 판단력 — 답의 무게를 재는 힘
6화에서 다뤘던 주제다. AI는 답을 주지만 결정은 사람이 한다. 그 결정을 내리려면, 답이 얼마나 신뢰할 수 있는지 무게를 잴 수 있어야 한다.
챗봇 운영 8년 동안 겪은 일이다. 금융 상품 추천 챗봇이 고객에게 특정 상품을 추천했다. 알고리즘상으로는 맞는 추천이었다. 고객의 연령, 자산 규모, 투자 성향 — 모든 데이터가 그 상품을 가리키고 있었다. 하지만 운영팀의 시니어가 개입했다. “이 고객 최근 가족 관련 상담 이력 있지 않았나? 지금 이 상품을 추천하면 시기적으로 부담스러울 수 있어.”
데이터에는 없는 판단이었다. AI가 내놓은 ‘정답’에 ‘왜 이게 맞다고 확신할 수 있나?’를 물었기 때문에 가능한 개입이었다. 이 판단력은 하루아침에 생기지 않는다. 수많은 상황에서 ‘왜’를 물어보고, 답이 틀렸던 경험과 맞았던 경험이 쌓여서 형성된다.
신입이 이 판단력을 키우려면, AI의 답을 받았을 때 최소한 세 가지를 스스로에게 물어야 한다.
- 이 답의 전제 조건은 무엇인가?
- 우리 시스템에서 그 전제 조건이 성립하는가?
- 이 답이 틀렸다면 어떤 결과가 발생하는가?
이 세 질문만 습관화해도, AI를 ‘받아쓰기’하는 단계에서 ‘AI와 협업’하는 단계로 넘어갈 수 있다.
두 번째 근육: 맥락 — 행간을 읽는 감각
8화에서 이야기한 것처럼, AI는 행간을 읽지 못한다. 회의에서 팀장이 “이 건은 천천히 가자”라고 했을 때, 그 말이 정말 ‘천천히 하자’는 뜻인지, ‘다른 우선순위가 있다’는 뜻인지, ‘상위 보고가 끝나야 한다’는 뜻인지는 맥락을 아는 사람만 읽을 수 있다.
맥락을 읽는 감각은 어디서 오는가? 직접 그 맥락 안에 있어본 경험에서 온다. 비슷한 상황을 여러 번 겪어본 사람은, 표면적인 말 뒤에 숨은 의도를 감지하는 안테나가 생긴다. 그 안테나는 AI가 만들어줄 수 없다.
‘왜’를 묻는 습관이 맥락 읽기와 어떻게 연결되는가? 예를 들어보겠다.
신입이 코드 리뷰에서 “이 함수는 왜 이렇게 복잡하게 되어 있어요?”라고 물었다고 하자. 단순한 기술 질문이다. 하지만 이 ‘왜’를 따라가면 기술 너머의 맥락에 도달한다. “3년 전에 규제가 바뀌면서 이 로직이 추가됐어.” “왜 규제가 바뀌었어요?” “고객 보호 강화 정책 때문이야.” “그러면 이 복잡한 로직을 단순화하면 규제에 걸릴 수도 있는 건가요?” — 이 대화를 통해 신입은 코드가 아니라 코드 뒤에 있는 사업 맥락을 배운다.
금융IT에서 맥락을 모르는 코드 수정은 위험하다. “이 코드 비효율적인데요, AI가 더 깔끔한 방법을 알려줬어요”라고 하면서 규제 관련 로직을 건드리는 순간, 시스템은 규제 위반 상태가 된다. AI는 코드의 효율만 보지, 그 코드가 왜 그 자리에 있는지는 모른다. 왜를 물어본 사람만이 “이건 건드리면 안 돼”를 직감할 수 있다.
세 번째 근육: 도약 — 보간 너머의 창의
9화에서 다뤘던 보간(interpolation)과 외삽(extrapolation)의 구분이다. AI는 기존 데이터 사이를 채우는 보간의 천재다. 하지만 기존에 없던 영역으로 뛰어넘는 외삽 — 즉 창의적 도약 — 은 사람의 영역이다.
‘왜’를 묻는 습관은 창의의 씨앗이다. “왜 우리는 이 방식으로 하고 있지?” → “꼭 이래야 하나?” → “다르게 하면 어떨까?” 이 사고의 흐름이 기존 패턴 너머의 도약을 가능하게 한다.
사내 시스템 개선 사례가 있었다. 기존 보고서 생성 프로세스가 번거롭다는 불만이 오래됐다. AI에게 “보고서 생성 프로세스를 개선해줘”라고 물으면, 기존 프로세스를 최적화하는 방향의 답이 나온다 — 단계를 줄인다, 자동화한다, 템플릿을 만든다 등. 전부 기존 패턴 ‘안에서의’ 개선이다.
하지만 팀에서 한 사람이 “왜 보고서를 이 형식으로 만들어야 하지?”를 물었다. 추적해보니 5년 전 특정 상위 부서의 요청으로 시작된 형식이었는데, 그 부서는 이미 다른 방식으로 데이터를 보고 있었다. 즉, 아무도 읽지 않는 보고서를 매주 만들고 있었던 것이다. ‘왜’를 끝까지 추적한 결과, 프로세스 개선이 아니라 프로세스 자체를 없애는 것이 답이었다.
AI는 이런 판단을 하지 못한다. AI에게 “보고서 프로세스를 개선해줘”라고 물으면 보고서를 더 잘 만드는 방법을 알려주지, “그 보고서 자체가 필요 없어요”라고는 절대 말해주지 않는다. 기존 프레임 밖으로 나가는 것은 ‘왜’를 끝까지 물어본 사람만이 할 수 있는 일이다.
“그래도 AI가 더 빠르잖아요” — 가장 흔한 반론에 답하다
이 이야기를 하면 반드시 나오는 반론이 있다. 신입에게서도, 때로는 관리자에게서도 나온다.
“AI가 10분이면 해주는 걸, 왜 사흘씩 삽질하게 합니까? 비효율 아닙니까?”
맞는 말이다. 단기적으로는 비효율이다. 오늘 해야 할 업무를 놓고 보면, AI를 써서 빠르게 끝내는 것이 합리적이다. 나도 그렇게 일한다. 반복적인 코드 생성, 데이터 정리, 문서 초안 — 이런 건 AI에게 맡기는 것이 당연히 효율적이다.
하지만 신입 교육에는 다른 시간 지평이 적용된다. 오늘의 산출물이 아니라 3년 후의 역량을 보는 것이다.
간단한 사고 실험을 해보자. 두 명의 신입이 있다.
신입 A: 첫 6개월간 모든 업무에 AI를 적극 활용했다. 산출물 품질 높았고, 업무 속도 빨랐다. 팀에서 “에이스”라는 평가를 받았다. 하지만 기초를 직접 다진 적이 없다.
신입 B: 첫 6개월 중 절반은 AI 없이 기초를 다지는 데 썼다. 의도적으로 손으로 코드를 짜고, 버그를 직접 잡고, 시스템 구조를 하나씩 파악했다. 나머지 절반에서 AI를 도구로 활용하기 시작했다. 초반 속도는 A보다 느렸다.
1년 후, 두 사람에게 이런 상황이 닥친다. 프로덕션 환경에서 원인 불명의 성능 저하가 발생했다. 기존에 없던 패턴의 문제다. AI에게 물어봐도 일반적인 답만 돌아온다. 로그를 직접 분석하고, 시스템 아키텍처를 머릿속에 그리고, 가설을 세우고 검증해야 한다.
A와 B 중 누가 이 상황을 해결할 수 있을까? 대부분의 경험 있는 개발자는 B라고 답할 것이다. 왜냐하면 B는 기초 과정에서 ‘왜’를 직접 추적한 경험이 있기 때문이다.
여기서 핵심은, “삽질”과 “AI 활용”이 양자택일이 아니라는 점이다. 삽질을 통해 기초를 다진 후에 AI를 활용하면, AI의 답을 평가하고 맥락에 맞게 적용하는 능력이 비약적으로 올라간다. 반대로, 기초 없이 AI를 쓰면 AI가 주는 답을 넘어서는 것이 구조적으로 불가능하다.
또 하나 간과하기 쉬운 점이 있다. AI의 능력 자체가 급변한다. 올해 최고 성능을 내는 AI 도구가 내년에도 같을 거라는 보장이 없다. 특정 AI 도구에 종속된 워크플로우는 그 도구가 바뀌면 무너진다. 하지만 ‘왜’를 묻는 습관은 도구가 바뀌어도 유효하다. 새로운 AI가 나와도 “이 답이 왜 이러한가, 내 상황에 맞는가”를 물을 수 있으니까.
비효율의 반론에 대한 나의 답은 이것이다. “처음 6개월의 비효율이 이후 20년의 효율을 만든다.” 신입 교육에서 아끼면 안 되는 것이 바로 이 기초 투자 시간이다.
선배가 먼저 바뀌어야 한다
여기까지 읽으면 “그래, ‘왜’가 중요한 건 알겠어. 그런데 실제로 어떻게 가르치지?”라는 의문이 들 것이다. 솔직히 말하겠다. 이건 선배의 변화 없이는 불가능하다.
지난 20년간 신입 교육의 패러다임이 여러 번 바뀌는 것을 봐왔다.
- 2000년대: “모르면 책 봐.” 선배가 가르쳐주는 문화 자체가 약했다. 알아서 배우는 것이 미덕이었다.
- 2010년대: “구글링해봐.” 검색의 시대. 질문 전에 검색했냐고 되묻는 것이 일상이었다.
- 2020년대 초: “이 강의 들어봐.” 온라인 교육 플랫폼의 시대. 체계적인 커리큘럼이 풍부해졌다.
- 2025년~: “AI한테 물어봐.” 가장 편하고, 가장 위험한 시대.
각 시대에서 선배의 역할은 달랐다. 하지만 AI 시대에 선배의 역할은 이전 어느 때보다 중요하다고 나는 확신한다. 왜냐하면 AI가 모든 “답”을 주는 환경에서, “질문”을 가르칠 수 있는 것은 사람뿐이기 때문이다.
변화 1: ‘답’을 가르치는 선배에서 ‘질문’을 가르치는 선배로
과거에 선배는 답을 알려주는 사람이었다. “이건 이렇게 해.” “이 패턴을 써.” “이 라이브러리가 좋아.” AI 시대에 이런 역할은 의미가 줄었다. AI가 더 빠르고 더 많은 답을 가지고 있으니까.
이제 선배의 핵심 역할은 좋은 질문을 하게 만드는 것이다. 신입이 “이거 어떻게 해요?”라고 물으면, 답을 주는 대신 “왜 이걸 해야 하는지 먼저 생각해봤어?”라고 되묻는 것이다. 신입이 AI의 답을 가져오면, “그래서 이 답이 맞다고 생각해? 왜?”라고 묻는 것이다.
이것은 예전의 “나한테 묻기 전에 구글링부터 해”와는 다르다. 그때는 ‘정보 접근’이 병목이었다. 지금은 정보가 넘쳐난다. 병목은 ‘정보를 판단하는 힘’이다. 선배는 그 판단의 과정을 보여주는 롤모델이 되어야 한다.
변화 2: 삽질할 시간을 ‘허락’해야 한다
현실적으로 가장 어려운 부분이 이것이다. 프로젝트 일정은 빠듯하고, 신입도 바로 투입해야 하는 상황에서 “천천히 기초부터 해봐”라고 말하기가 쉽지 않다.
하지만 방법이 있다. 업무의 일부를 “학습 구간”으로 명시적으로 지정하는 것이다. 예를 들어, 한 주에 하루는 “AI 없이 직접 해보는 날”로 정한다. 또는 신입이 맡은 업무 중 비(非)긴급한 한 건은 AI를 쓰지 않고 처음부터 끝까지 직접 해보게 한다. 그리고 그 과정에서 막히는 부분을 기록하게 한다.
이때 중요한 것은, 삽질의 결과를 성과 평가에서 분리하는 것이다. 학습 구간에서 느리게 일한 것을 “생산성이 낮다”고 평가하면, 아무도 삽질하지 않는다. “이 기간은 투자다”라는 공감대가 팀 전체에 있어야 한다.
우리 팀에서는 올해부터 신입의 첫 3개월을 “기초 투자 기간”으로 공식화했다. 이 기간에는 산출물의 양보다 “왜 이렇게 했는지 설명할 수 있는가”를 평가 기준으로 삼는다. 이 변화만으로도 신입들의 학습 태도가 눈에 띄게 달라졌다.
변화 3: AI 활용을 ‘설명 가능한 수준’으로 가르친다
AI를 완전히 배제하라는 것이 아니다. 오히려 AI를 적극 쓰되, AI가 준 답을 설명할 수 있는 수준에서 쓰게 하는 것이다.
구체적으로는 이런 규칙이다. “AI를 써서 코드를 작성해도 좋다. 단, 코드 리뷰에서 모든 줄을 자기 입으로 설명할 수 있어야 한다.” 설명하지 못하는 코드는 AI가 짠 것이든 자기가 짠 것이든 허용하지 않는다.
이 규칙은 단순해 보이지만 강력하다. AI의 답을 그대로 복사-붙여넣기 하면 설명이 안 되니까, 필연적으로 ‘왜’를 물어야 한다. “AI가 이 패턴을 썼는데, 왜 이게 다른 방법보다 나은 거지?” 이 질문을 스스로 던지는 순간, 학습이 시작된다.
현장에서 바로 쓰는 실천법 다섯 가지
지금까지의 이야기를 구체적인 실천법으로 정리한다. 선배든 신입이든, 내일부터 바로 적용할 수 있는 다섯 가지다.
1. “5 Whys” 루틴 도입
토요타 생산 시스템에서 유래한 “5 Whys”를 코드 리뷰와 장애 복기에 적용한다. AI가 준 답이든 자기가 쓴 코드든, “왜?”를 다섯 번 연속으로 물어본다. 대부분 세 번째 “왜”에서 진짜 이유에 도달하고, 다섯 번째에서 시스템 전체의 맥락이 보인다.
예시:
- 이 변수는 왜 전역으로 선언했어? → “여러 함수에서 쓰니까요.”
- 왜 여러 함수에서 같은 값을 쓰지? → “같은 설정값을 참조해야 해서요.”
- 왜 설정값이 코드 안에 있어? 설정 파일에 빼면 안 돼? → “…아, 그렇게 하는 게 맞겠네요.”
- 왜 설정 파일을 쓰는 게 나을까? → “배포 없이 설정을 바꿀 수 있으니까요.”
- 왜 배포 없이 바꿀 수 있어야 하지? → “금융 시스템이라 점검 시간이 제한되어 있어서요.”
다섯 번의 “왜”를 거치니, 단순한 코딩 스타일 문제가 금융 시스템의 운영 제약이라는 맥락에 도달했다. 이런 경험이 쌓이면 신입도 자연스럽게 맥락을 고려하는 습관이 생긴다.
2. “AI 답안 분해” 연습
AI가 코드를 생성하면, 그 코드를 한 줄씩 분해해서 각 줄의 역할과 이유를 적어보게 한다. 문서 한 장이면 된다. 시간은 걸리지만, 이 과정을 3~4번만 반복하면 AI의 코드를 “읽는 눈”이 생긴다. 이후에는 AI 코드를 받아도 자연스럽게 “이 부분은 이래서 맞고, 이 부분은 우리 환경에 안 맞으니 수정해야겠다”는 판단이 가능해진다.
3. “AI-Free Day” 운영
주 1회, 특정 업무를 AI 도움 없이 수행하는 날을 정한다. 전체 업무를 AI 없이 하라는 것이 아니다. 한 가지 업무, 예를 들어 “이번 주 금요일 오전은 이 기능의 버그 수정을 AI 없이 해보자” 정도면 충분하다. 핵심은 AI 없이 일해보면서 “내가 실제로 아는 것과 모르는 것”을 스스로 파악하는 것이다. 자신의 지식 공백(knowledge gap)을 인식해야 학습의 방향이 잡힌다.
4. “설명 우선” 코드 리뷰
코드 리뷰의 첫 번째 질문을 “이 코드 설명해줄 수 있어?”로 바꾼다. 기존의 코드 리뷰가 “이 코드의 문제점은?”이었다면, AI 시대의 코드 리뷰는 “이 코드를 네가 이해하고 있는지”를 확인하는 데 초점을 맞춘다. 설명이 막히는 부분이 곧 학습이 필요한 부분이다.
이때 선배가 주의할 점이 있다. 설명을 못 한다고 질책하면 안 된다. “모르는 게 드러나는 것이 좋은 것”이라는 인식을 심어줘야 한다. 장기적으로 이것이 심리적 안전감과 학습 문화를 동시에 만든다.
5. “장애 복기” 공유 세션
실제 장애 사례(자사·타사 불문, 익명화된 것)를 가지고 팀 내 복기 세션을 진행한다. 장애의 현상부터 시작해서, “왜?”를 반복적으로 물으며 근본 원인에 도달하는 과정을 함께 경험한다. 신입이 직접 장애를 겪지 않아도, 이 세션을 통해 사고의 프로세스를 간접 체험할 수 있다.
이 다섯 가지를 모두 하지 않아도 된다. 팀 상황에 맞게 한두 가지만 골라서 시작해도 충분하다. 중요한 것은 “왜”를 묻는 행위가 팀의 일상에 자연스럽게 녹아드는 것이다.
신입도 알아야 할 것 — 성장의 주체는 결국 자신이다
여기까지 선배의 역할을 주로 이야기했지만, 신입 본인에게도 할 말이 있다.
AI 시대에 신입으로 입사한다는 것은 축복이자 위험이다. 축복인 이유는 분명하다. 이전 세대가 수년에 걸쳐 쌓아야 했던 지식에 AI를 통해 빠르게 접근할 수 있다. 하지만 위험한 이유도 분명하다. 빠른 접근이 깊은 이해를 대체할 수 있다는 착각에 빠지기 쉽다.
솔직히 말해서, 선배가 “왜를 물어라”라고 아무리 강조해도, 본인이 그 필요성을 느끼지 못하면 습관이 되지 않는다. 그래서 한 가지 현실적인 질문을 던지고 싶다.
“지금 AI 없이, 자기가 맡은 업무를 처음부터 끝까지 할 수 있는가?”
이 질문에 자신 있게 “예”라고 답할 수 없다면, 그것이 바로 학습이 필요한 지점이다. AI를 쓰되, AI 없이도 할 수 있는 자신을 만들어가는 것 — 이것이 AI 시대 신입의 생존 전략이다.
모순적으로 들릴 수 있다. AI를 쓰면서 동시에 AI 없이도 할 수 있어야 한다니. 하지만 생각해보면 당연하다. 자동차가 있어도 걸을 줄 알아야 한다. 계산기가 있어도 산수를 알아야 한다. 도구에 대한 이해 없이 도구를 쓰는 것은 의존이지 활용이 아니다.
그리고 한 가지 더. AI 시대에 커리어에서 차별화되는 것은 “AI를 얼마나 잘 쓰는가”가 아니라 “AI가 할 수 없는 것을 얼마나 잘 하는가”다. AI를 잘 쓰는 것은 곧 모두의 기본 소양이 된다. 모두가 AI를 쓸 수 있는 세상에서, 경쟁력은 AI 너머에 있다. 판단, 맥락, 신뢰, 창의 — 이 시리즈에서 계속 이야기해온 것들이다. 그리고 그 모든 것의 출발점이 ‘왜’를 묻는 힘이다.
챗봇 운영에서 배운 역설 — AI가 똑똑할수록 사람의 기초가 중요해진다
챗봇을 8년 운영하면서 목격한 역설이 하나 있다. 챗봇이 똑똑해질수록, 챗봇 운영자에게 요구되는 역량 수준이 낮아지는 게 아니라 높아졌다.
초기의 챗봇은 단순했다. 키워드 매칭으로 FAQ를 내보내는 수준이었다. 운영자의 역할은 FAQ를 관리하고, 자주 묻는 질문 패턴을 정리하는 것이었다. 기초적인 업무였다.
챗봇이 자연어를 이해하고 맥락을 파악하는 수준으로 올라오면서, 역설적으로 운영자에게 더 높은 수준의 판단력이 요구되기 시작했다. 왜냐하면 AI가 “그럴듯하게” 틀리는 빈도가 높아졌기 때문이다.
단순한 챗봇이 틀리면 답이 아예 엉뚱해서 고객도 운영자도 바로 알 수 있었다. 하지만 고도화된 챗봇이 틀리면, 답이 99% 맞는 것처럼 보이는데 치명적인 1%가 잘못되어 있는 경우가 생긴다. 금융 상품의 수수료를 미묘하게 잘못 안내한다든지, 특정 조건에서만 적용되는 예외 규정을 빠뜨린다든지.
이런 “그럴듯한 오류”를 잡아내려면, 운영자 자신이 해당 금융 상품과 규정을 깊이 이해하고 있어야 한다. AI가 내놓은 답을 읽고 “이건 맞아, 이건 아니야”를 순간적으로 판단할 수 있어야 한다. 그 판단력은 직접 공부하고, 실수하고, 교정받은 경험에서 온다.
챗봇 운영에서 배운 이 교훈은 모든 AI 활용 영역에 적용된다. AI의 성능이 올라갈수록, AI를 감독하는 사람에게 요구되는 기초 역량의 수준도 올라간다. “AI가 다 해주니까 사람은 덜 알아도 돼”라는 생각은 완전히 거꾸로다. AI가 다 해줄수록 사람은 더 깊이 알아야 한다. 왜냐하면 AI가 미묘하게 틀릴 때 그것을 잡아내는 것이 사람의 역할이고, 그 역할은 기초가 탄탄해야만 수행할 수 있으니까.
3화에서 다뤘던 “피드백 루프”를 떠올려보자. AI가 답을 내놓으면 사람이 검증하고, 검증 결과를 다시 시스템에 반영한다. 이 루프가 제대로 돌아가려면 검증하는 사람의 역량이 충분해야 한다. 역량이 부족하면 루프가 돌아가는 것처럼 보이지만 실제로는 아무것도 걸러지지 않는 형식적 루프가 된다.
그래서 신입 교육이 중요하다. 오늘의 신입이 내일의 검증자이고, 모레의 판단자이고, 1년 후의 의사결정자다. 기초가 없는 검증자는 루프를 형식적으로 만들고, 기초가 없는 판단자는 7화에서 말한 신뢰 자산을 쌓지 못하며, 기초가 없는 의사결정자는 5화에서 경고한 “AI가 시킨 대로 했어요”의 함정에 빠진다.
가르침의 본질은 바뀌지 않았다
어쩌면 “AI 시대 신입에게 가르쳐야 할 단 하나”라는 제목이 거창해 보일 수 있다. 결론이 ‘왜를 물어라’라니, 너무 단순하지 않은가?
단순하다. 의도적으로 단순하게 만들었다. 왜냐하면 도구가 바뀌어도 변하지 않는 원칙은 단순해야 살아남기 때문이다.
돌이켜보면, 좋은 선배들이 나에게 가르쳐준 것도 결국 같은 것이었다. “왜 그렇게 생각해?” “다른 방법은 없을까?” “이게 정말 최선이야?” 도구는 메모장에서 IDE로, IDE에서 AI 어시스턴트로 바뀌었지만, 가르침의 본질 — 스스로 생각하게 만드는 것 — 은 20년 전이나 지금이나 같다.
달라진 것은 하나다. AI 시대에는 이 가르침이 더 의식적으로 이루어져야 한다는 것이다. AI가 없던 시절에는 과정을 건너뛸 방법 자체가 없었기 때문에, ‘왜’를 묻는 습관이 자연스럽게 형성됐다. 막히면 직접 해결해야 했고, 해결하는 과정에서 자연히 ‘왜’를 추적하게 됐다.
하지만 AI가 과정을 통째로 대행해주는 지금, ‘왜’를 묻지 않고도 결과를 얻을 수 있게 됐다. 따라서 ‘왜를 물어라’는 더 이상 자연스럽게 발생하지 않는다. 의도적으로, 체계적으로 가르치고 연습시켜야 하는 것이 됐다.
이것이 AI 시대 교육의 역설이다. 가장 오래되고 가장 기본적인 원칙이, 가장 새롭고 가장 절실한 교육 과제가 되었다.
사람은 과정으로 만들어진다
이 글을 쓰면서, 아까 이야기했던 올해의 신입이 다시 떠올랐다. 입사 두 달째의 그 장애 이후, 우리 팀은 신입에게 조금 다른 방식을 제안했다.
“일단 이번 한 건은 AI 없이 처음부터 해볼래? 막히면 물어보고. 대신 ‘뭘 모르겠다’가 아니라 ‘왜 이런지 모르겠다’로 물어봐.”
신입은 일주일을 썼다. AI로 사흘이면 끝냈을 일에 일주일이 걸렸다. 하지만 그 일주일 동안 “왜”를 아홉 번 물었고, 그중 세 번은 선배들도 한 번 더 생각해봐야 하는 좋은 질문이었다. “이 테이블이 왜 이렇게 분리되어 있어요?” “이 로직이 여기에 있는 이유가 규제 때문인 건 알겠는데, 왜 이 방식으로 구현했어요?” “다른 팀 API를 호출하는 이 부분이 실패하면 우리 쪽 트랜잭션은 왜 롤백하지 않아요?”
마지막 질문은 실제로 잠재적인 버그를 짚어낸 것이었다. 수년 동안 아무도 발견하지 못한, 특수한 조건에서만 발생할 수 있는 데이터 불일치 가능성이었다. AI는 이 코드를 수천 번 봐도 이 질문을 하지 못했을 것이다. 왜냐하면 이 질문은 “이 코드가 왜 이렇게 돼 있지?”라는 인간의 의문에서만 출발할 수 있는 것이었으니까.
그 순간, 나는 확신했다. 이 신입은 잘 자랄 것이다.
AI가 아무리 발전해도, 사람의 성장은 과정에서 이루어진다. 과정을 겪으면서 ‘왜’를 묻고, 답을 찾고, 틀리고, 다시 묻는 — 그 순환 속에서 판단력이 자라고, 맥락을 읽는 눈이 트이고, 기존에 없던 것을 상상하는 힘이 생긴다.
AI 시대에 신입에게 가르쳐야 할 단 하나. 그것은 특정 기술이나 도구가 아니다. ‘왜’를 끝까지 묻는 습관이다. 이 습관 하나가 판단의 뿌리가 되고, 맥락의 안테나가 되고, 창의의 발판이 된다. 그리고 이 습관은 선배가 ‘답을 가르치는 사람’에서 ‘질문을 가르치는 사람’으로 스스로를 바꿀 때, 비로소 전해진다.
다음 화에서는 시선을 개인에서 팀과 조직으로 넓힌다. AI 시대에 루프가 돌아가는 팀은 어떤 모습인지, 리더는 이 루프를 어떻게 설계하는지 — “AI 시대, 팀이 살아남는 루프의 조건”을 이야기해보겠다.
이번 주 한 줄 노트: AI가 답을 다 줘도, ‘왜’를 묻는 사람만이 그 답 너머를 볼 수 있다.
이미지는 Leonardo AI 로 생성되었습니다.
이미지는 Claude AI 로 생성되었습니다.
◀ 이전 9화 (다음 차수는 아직 게시되지 않았습니다)