주니어가 합류한 첫 주, 팀장이라면 한 번쯤 겪는 장면이 있습니다. "이 코드가 뭘 하는 건지 모르겠어요"라는 말을 하루에 열 번도 넘게 듣는 순간입니다. 저도 그랬습니다. 코딩 부트캠프 출신 팀원이 처음 실무 코드베이스를 마주하던 날, 그 눈빛이 아직도 기억납니다. 기본 문법은 아는데, 수천 줄짜리 실제 프로젝트 앞에서 완전히 얼어버리더군요. AI를 온보딩 도구로 도입하게 된 건 그때부터였습니다.
코드베이스 앞에서 얼어버린 주니어, 팩트부터
신규 입사자가 실질적인 업무 기여자로 자리잡는 데 걸리는 시간을 온보딩 기간(Onboarding Period)이라고 합니다. 온보딩 기간이란 단순히 회사 시스템에 적응하는 것을 넘어, 팀의 맥락과 코드 구조를 이해하고 독립적으로 작업할 수 있는 상태가 되기까지의 전체 구간을 말합니다. 일반적으로 개발 직군에서는 이 기간이 2~3개월로 알려져 있는데, 비전공자 주니어의 경우 그보다 더 길어지는 경우가 많습니다.
심리적 안전감(Psychological Safety)이 온보딩에 미치는 영향도 무시할 수 없습니다. 심리적 안전감이란 팀 내에서 질문하거나 실수해도 불이익이 없다고 느끼는 상태를 말합니다. 구글의 Project Aristotle 연구에 따르면 팀 성과를 결정하는 가장 중요한 요인이 바로 이 심리적 안전감이었습니다.
팀원이 "이것도 모르면 어떡하지"라는 두려움 없이 질문할 수 있어야 온보딩도 빨라집니다. 제가 AI를 도구로 도입한 것도 사실 이 두려움을 낮추려는 의도가 컸습니다. 사람에게 같은 질문을 반복하기 눈치 보일 때, AI는 아무런 표정 변화 없이 열 번이든 대답해주니까요.
이 부분에서 제가 느낀 게 있는데, 팀장 입장에서 AI 도입의 실질적인 효과는 "내가 덜 불리는 것"이 아니었습니다. 물론 반복 질문이 줄어드는 건 사실이지만, 더 중요한 건 팀원이 "내가 멍청한 질문을 하고 있다"는 자기 검열 없이 탐색할 수 있게 됐다는 점입니다. 학습의 질이 달라진 겁니다. 심리적 안전감을 설계하는 것이 팀장의 역할인데, AI가 그 환경을 구조적으로 보완해줬습니다.
솔직히 말하면, 팀장이 심리적 안전감을 직접 만들어주는 데는 한계가 있습니다. 아무리 "편하게 질문해"라고 해도, 팀원은 팀장의 표정과 반응을 읽습니다. AI는 그 감정 노동을 대신해줍니다. 이건 팀장으로서 불편한 진실이기도 합니다. 내가 아무리 좋은 팀장이라도, 팀원이 나에게 느끼는 심리적 부담을 완전히 없애줄 수는 없다는 것을요.
제가 만든 루틴은 간단했습니다. 모르는 코드를 ChatGPT에 붙여넣고, 다음 세 가지를 순서대로 물어보게 했습니다. 이 코드가 무엇을 하는가, 왜 이렇게 짰을까, 내가 수정하려면 어디를 바꿔야 하는가. 이 세 가지 질문을 먼저 AI에게 던지고, 그래도 이해가 안 되면 그때 저에게 오도록 했습니다.
GPT-4 Technical Report에서도 대규모 언어 모델(LLM)의 코드 설명 능력이 교육적 맥락에서 유의미하게 활용될 수 있다는 점을 언급하고 있습니다. 대규모 언어 모델(LLM)이란 방대한 텍스트 데이터를 학습해 문장을 이해하고 생성하는 AI 모델로, ChatGPT가 대표적인 사례입니다.
결과는 제 예상보다 훨씬 빨리 나왔습니다. 3개월이 걸릴 것으로 봤던 온보딩 기간이 약 6주로 단축됐습니다. 그리고 팀원이 저에게 오는 질문의 수준이 완전히 달라졌습니다. "이게 뭐예요?"에서 "AI가 이렇게 설명해줬는데, 우리 프로젝트에서는 왜 다르게 써요?"로 바뀐 겁니다. AI가 학습 속도를 높이는 것을 넘어, 질문의 질 자체를 끌어올리는 역할을 하고 있었습니다.
주니어 온보딩에 AI를 썼을 때, 진짜 주의해야 할 것
저는 이 방식을 권하면서도 한 가지 부분에서 늘 경고를 붙입니다. AI는 틀린 답을 자신 있게 말합니다. 환각(Hallucination) 현상이라고 부르는 이 특성 때문에 실제로 문제가 생긴 적이 있었습니다. 환각이란 AI가 존재하지 않는 정보나 잘못된 코드를 마치 사실인 것처럼 출력하는 현상을 말합니다. 비전공자 주니어는 그 답이 맞는지 틀렸는지 검증할 기준 자체가 없습니다. 제 팀원도 AI가 알려준 방식대로 코드를 수정했다가 전혀 다른 방향으로 가버린 적이 있었습니다.
이 문제가 생각보다 심각한 이유는, AI의 틀린 답이 대부분 "그럴듯하게 틀려있다"는 점입니다. 완전히 틀린 답은 주니어도 금방 알아챕니다. 하지만 70%는 맞고 30%가 우리 프로젝트의 맥락에서는 잘못된 경우, 주니어는 그 답을 통째로 신뢰하게 됩니다. 그게 습관이 되면 나중에 고치기가 훨씬 어렵습니다. 저는 이것이 AI 온보딩에서 가장 과소평가된 리스크라고 생각합니다.
그래서 AI 온보딩은 반드시 시니어 개발자의 코드 리뷰(Code Review)와 함께 설계해야 합니다. 코드 리뷰란 작성한 코드를 다른 개발자가 검토하여 오류, 스타일, 구조적 문제를 점검하는 과정을 말합니다. AI가 제안한 방향을 시니어가 주기적으로 확인해주지 않으면, 오히려 잘못된 습관을 빠르게 굳혀버릴 수 있습니다. 학습 속도가 빨라지는 만큼, 방향이 틀렸을 때의 리스크도 커진다는 뜻입니다.
또 하나, 제 경험상 이건 좀 다릅니다. AI를 너무 일찍 열어주면 스스로 디버깅(Debugging)하는 능력이 발달하지 않습니다. 디버깅이란 코드에서 오류를 찾아 원인을 파악하고 수정하는 과정으로, 개발자의 핵심 역량 중 하나입니다. 막히면 즉시 AI에게 물어보는 습관이 들면, 혼자서 문제를 추적하는 근육이 생기지 않습니다. 그래서 저는 순서를 명확히 정해두었습니다. 먼저 30분 스스로 고민한다. 그다음 AI에게 묻는다. 그래도 해결이 안 되면 팀원이나 팀장에게 온다.
이 30분이라는 기준이 처음에는 주니어 입장에서 답답하게 느껴진다고 했습니다. 바로 AI에게 물어보면 되는데 왜 굳이 혼자 고민해야 하냐고요. 그때 제가 한 설명은 이겁니다. 에러 메시지를 읽는 법, 어디서 찾아야 하는지를 아는 법, 문제를 분해하는 법. 이 능력들은 AI에게 물어보는 것으로는 생기지 않습니다. 직접 막혀보고 뚫어보는 과정에서만 생깁니다. 이 설명을 들은 팀원이 나중에 "그 30분이 제일 많이 배운 시간이었던 것 같다"고 했을 때, 그게 꽤 인상 깊었습니다.
김창준의 『함께 자라기』에서도 학습은 속도보다 방향이 중요하며, 피드백 루프(Feedback Loop)를 어떻게 설계하느냐가 성장의 질을 결정한다는 점을 강조합니다. 피드백 루프란 행동의 결과를 다시 자신에게 되돌려 다음 행동을 조정하는 순환 구조를 말합니다. AI를 잘 쓰는 것도 결국 이 루프를 얼마나 잘 설계하느냐의 문제입니다.
AI가 온보딩의 속도를 높여주는 건 분명합니다. 하지만 판단의 기준을 세워주지는 않습니다. 기준은 여전히 사람인 시니어가 제공해야 하고, AI는 그 기준을 학습하는 과정을 돕는 도구입니다. 이 관계를 뒤집으면 온보딩이 빨라지는 게 아니라 오히려 위험해집니다. 제가 이 방식을 도입하면서 배운 가장 중요한 것은 그 점이었습니다. 비전공자 주니어를 맡고 있는 팀장이라면, AI 도구를 열어주기 전에 "어떤 순서로 쓰게 할 것인가"를 먼저 설계해보시길 권합니다.
참고: Michael D. Watkins "The First 90 Days", 김창준 『함께 자라기』, Google re:Work Project Aristotle, OpenAI GPT-4 Technical Report