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