시리즈 · AI시대의 주니어 생존법
1회 · AI시대의 주니어 생존법 1 - AI가 등장하기 이전의 시대
이 시리즈는 여러 해 동안 주니어를 채용하고 제품을 만들어 온 한 실무자의 경험을 바탕으로, AI 시대의 주니어 개발자에게 요구되는 역량과 성장 방향, 채용 현장의 질문을 차례로 살펴봅니다. 1편에서는 그 출발점으로 돌아가, AI가 등장하기 전 스타트업과 중소기업의 개발자 채용이 어떤 현실 위에서 이루어졌고 당시 무엇을 기술과 가능성의 신호로 보았는지 이야기하겠습니다.
먼저 제 경험의 범위를 밝혀두는 편이 좋겠습니다. 저는 금융 자금세탁방지 분야의 창립 멤버 중 한 명으로 약 10년간 스타트업 CTO 역할을 맡았고, 지금은 일반 소비자 대상 B2C 플랫폼 조직에서 제품화와 CTO 전략 업무를 이끌고 있습니다. 구체적인 회사명은 공개하지 않겠습니다. 이 글은 대기업이나 모든 산업을 대표하는 이야기가 아니라, 제가 주로 경험한 스타트업·중소기업의 채용과 협업에 한정된 개인적인 관찰입니다.
여기서 주니어는 신입부터 경력 3년 정도까지를 뜻합니다. 같은 연차라도 맡은 업무와 학습 환경에 따라 격차가 크므로, 연차 자체를 능력의 등급으로 보지는 않습니다.
작은 회사의 채용은 가능성을 고르는 일이었다
AI 이전의 작은 회사는 지원자를 여유 있게 비교하기 어려웠습니다. 이름이 알려진 회사와 달리 채용 공고를 내도 지원자가 많지 않았고, 좋은 후보가 나타나면 서로를 오래 재기보다 가능한 한 함께 일할 방법을 찾았습니다. 냉정하게 말하면 회사가 사람을 가려 받는 위치가 아닌 경우도 많았습니다.
그래서 신입의 기술을 완성품처럼 평가하지 않았습니다. 자격증이나 학벌이 성실함을 보여주는 참고 자료가 될 수는 있어도, 그것만으로 실무 적응력을 판단하기는 어려웠습니다. 학교에서 배운 알고리즘과 언어 문법은 필요하지만, 실제 제품에서는 Git으로 충돌을 풀고, 낯선 코드의 흐름을 읽고, 장애 원인을 좁히고, 기획자와 요구사항을 다시 확인해야 했습니다.
작은 회사가 주니어 개발자에게 기대한 것은 당장 뛰어난 코드를 쓰는 능력보다 배울 수 있는 태도였습니다. 맡은 일을 숨기지 않고 공유하는가, 약속한 내용을 지키는가, 팀의 긴장을 불필요하게 높이지 않는가가 중요했습니다. 이직률이 높은 환경에서는 기술 교육에 큰 기대를 걸기 어려웠기 때문에, 인성과 협업 태도를 더 무겁게 본 것도 사실입니다.
다만 “착한 사람”을 순응적인 사람과 혼동해서는 안 됩니다. 반대 의견을 말하지 않는 사람이 아니라, 문제를 솔직히 드러내면서도 상대를 존중하고 공동의 결과를 향해 움직이는 사람이 팀에 필요했습니다. 신뢰는 말수가 적어서 생기는 것이 아니라, 정보와 약속을 다루는 방식에서 생깁니다.
가르친 만큼만 성장하는 구조의 한계
제가 만난 주니어들은 대체로 성실했고, 필요하다고 판단하면 근무시간 밖에서도 책임을 다하려 했습니다. 그러나 교육받은 범위를 넘어 스스로 문제를 확장하는 사람은 많지 않았습니다. 이것을 개인의 의지 부족만으로 설명하면 현실을 놓칩니다. 작은 조직은 체계적인 온보딩과 멘토링이 부족하고, 선임은 당장 처리할 업무에 쫓기며, 주니어는 무엇을 모르는지조차 설명하기 어려운 경우가 많았습니다.
그럼에도 차이는 분명히 생겼습니다. 같은 내용을 배운 뒤 한 사람은 그대로 반복했고, 다른 사람은 “이 방식이 실패하는 조건은 무엇인가”를 확인했습니다. 후자는 작은 실험을 해보고 문서를 읽고, 다음 업무에서 이전의 원리를 변형해 적용했습니다. 제가 말하는 프로젝트 수행력은 단순히 지시를 빨리 끝내는 속도가 아니라, 불명확한 과제를 작은 문제로 나누고 위험을 공유하며 결과를 마무리하는 힘입니다.
고연차도 기술을 모두 아는 것은 아닙니다. 과장·차장급 개발자의 강점은 최신 문법을 더 많이 외우는 데 있다기보다, 일정과 품질, 이해관계자, 장애 가능성을 함께 보며 프로젝트를 끝내 본 경험에 있습니다. 반대로 말하면 저연차에게도 명확한 역할이 있습니다. 문제를 빠르게 탐색하고, 기존 관성을 의심하며, 새로운 도구를 검증하는 일은 주니어가 충분히 기여할 수 있는 영역입니다.
국내 개발 환경의 변화는 웹 기술 변천사만 보더라도 빠릅니다. Java와 Spring을 오래 다룬 선임도 새로운 실행 환경에서는 다시 학습해야 합니다. 연차가 학습을 면제해 주지 않는다는 점에서 주니어와 시니어의 출발선은 생각보다 자주 가까워집니다.
개발자 질문은 가장 저평가된 기술이었다
주니어 개발자와 일하며 가장 아쉬웠던 점은 질문의 양이 아니라 질문이 사라지는 순간이었습니다. 질문을 하지 않는 이유는 다양합니다. 무능해 보일까 두렵고, 선임이 바빠 보여 말을 걸기 어렵고, 스스로 더 찾아봐야 한다는 압박도 있습니다. 하지만 질문이 없으면 팀은 일이 잘되는지, 조용히 막혀 있는지 구분할 수 없습니다.
좋은 개발자 질문은 정답을 대신 달라는 요청이 아닙니다. 다음 네 가지가 들어가면 질문 자체가 업무가 됩니다.
- 제가 이해한 목표는 무엇입니다.
- 지금까지 무엇을 확인하고 시도했습니다.
- 어디까지는 알겠고 어느 지점부터 막혔습니다.
- 제가 생각한 선택지는 무엇이며 어떤 판단이 필요합니다.
이렇게 질문하려면 먼저 읽고 실험해야 합니다. 동시에 회사도 질문을 환영한다는 신호를 줘야 합니다. “왜 그것도 모르느냐”는 반응이 반복되는 조직에서 질문이 사라지는 것은 개인의 소극성만이 아니라 조직 설계의 결과입니다.
질문의 반대편에는 기록이 있습니다. 질문하고 답을 들은 뒤 작업 노트나 팀 문서로 남기는 사람은 같은 문제를 두 번 묻지 않습니다. 이 습관은 훗날 Git 이력, 배포 로그, 인프라 구성과 같은 코딩 기반 환경을 이해하는 토대가 됩니다.
잘하는 사람에게 일이 몰리는 역설
현장에서는 신뢰받는 사람에게 일이 몰립니다. 회사의 할 일은 많고, 마감은 기다려주지 않으며, 선임은 이미 결과를 내본 사람을 다시 찾게 됩니다. 일을 잘하는 주니어에게 더 큰 과제가 주어지는 것은 성장 기회이지만, 어느 순간 개인의 학습 시간을 삼키는 부채가 되기도 합니다.
반대로 성과가 부족한 사람에게 중요한 일을 계속 맡기지 않는 것도 흔한 선택입니다. 기회가 줄면 경험이 쌓이지 않고, 경험이 없으니 다시 기회를 얻지 못하는 악순환이 생깁니다. 제가 시행착오 끝에 택했던 현실적인 방식은 초반 약 2주간 업무의 기본을 집중적으로 알려주고, 실제 과제를 맡긴 뒤 결과와 학습 방식을 함께 평가하는 것이었습니다. 잘하면 무한히 일을 얹고, 부족하면 방치하는 방식이 아니라 책임의 크기와 피드백 주기를 조절해야 했습니다.
여기서 회사의 책임도 분명합니다. 유능한 사람을 붙잡는다는 명목으로 과도한 업무를 몰아주면 단기 성과는 나올지 몰라도 장기적으로는 학습 동력과 건강, 팀의 지식 분산을 해칩니다. 개인에게 성장을 요구하려면 조직도 회고와 학습, 재사용 가능한 문서를 위한 시간을 비용으로 인정해야 합니다.
AI 이전의 교훈은 사라지지 않았다
AI 이전에 요구되던 하드 스킬은 언어, 프레임워크, 데이터베이스, 서버와 배포 환경을 직접 다루는 힘이었습니다. 그러나 실제 채용과 성장의 갈림길은 기술 목록보다 질문, 학습, 협업, 프로젝트 수행력에서 더 자주 나타났습니다. 도구가 바뀌어도 문제를 정의하고 끝까지 책임지는 사람의 가치는 줄지 않았습니다.
이제 바이브코딩과 AI 코딩 에이전트가 코드 생산의 상당 부분을 빠르게 대신합니다. 그렇다고 과거의 역량이 폐기된 것은 아닙니다. 오히려 질문할 줄 모르는 사람은 AI에도 모호하게 지시하고, 검증할 줄 모르는 사람은 더 빠르게 잘못된 결과를 만듭니다.
2편에서는 이 변화가 주니어의 성장 경로를 어떻게 바꾸는지 다루겠습니다. 코드 작성 속도만 높이는 것을 넘어, AI가 잘하는 일과 사람이 책임져야 하는 일을 구분하고 프로젝트 전체를 보는 능력을 어떻게 길러야 하는지 살펴보겠습니다.
댓글 없음:
댓글 쓰기