시리즈 · AI시대의 주니어 생존법
2회 · AI시대의 주니어 생존법 2 - 쥬니어의 성장일지
이 시리즈는 여러 해 동안 주니어를 채용하고 제품을 만들어 온 한 실무자의 경험을 바탕으로, AI 시대의 주니어 개발자에게 요구되는 역량과 성장 방향, 채용 현장의 질문을 차례로 살펴봅니다. 2편에서는 코드를 만드는 비용이 급격히 낮아진 지금, 주니어가 무엇을 공부하고 어떤 경험을 쌓아야 하는지, 그리고 AI 생산성을 개인의 실력으로 착각하지 않으려면 무엇을 봐야 하는지 이야기하겠습니다.
저는 금융 자금세탁방지 분야의 창립 멤버 중 한 명으로 약 10년간 CTO 역할을 맡았고, 현재는 회사명을 밝히지 않은 B2C 플랫폼 조직에서 제품화와 CTO 전략 업무를 이끌고 있습니다. 이 글의 판단은 스타트업과 중소기업에서 제품을 만들고 사람을 채용한 제 경험에 한정됩니다. 대기업, 연구조직, 게임, 임베디드 등 다른 개발 분야에는 다른 성장 경로가 있을 수 있습니다.
코딩의 가치가 아니라 코딩 비용이 바뀌었다
“코딩은 100% AI로 대체됐다”는 표현은 현장의 충격을 전달하기에는 좋지만, 문자 그대로 받아들이면 위험합니다. 더 정확히 말하면 반복적인 코드 작성과 초안 생성의 비용이 극적으로 낮아졌습니다. 사람이 며칠 걸리던 화면과 API를 AI가 몇 시간 안에 만들 수 있고, 익숙하지 않은 언어도 예제를 따라 빠르게 시작할 수 있습니다.
그러나 코드가 만들어졌다는 사실과 제품이 완성됐다는 사실은 다릅니다. 요구사항이 서로 충돌하는지, 데이터가 유실될 수 있는지, 인증과 권한이 안전한지, 장애 때 복구할 수 있는지, 실제 사용자가 원하는 흐름인지 판단하는 일은 여전히 사람의 책임입니다. 바이브코딩의 한계도 결국 생성 자체보다 완성도와 검증에서 드러납니다.
AI가 코드를 많이 만들수록 기초 기술이 덜 중요해지는 것도 아닙니다. Git, 테스트, 네트워크, 데이터베이스, 서버 인프라, 클라우드 비용 구조를 모르면 결과를 검증할 기준이 없습니다. 예전에는 문법을 몰라 코드가 멈췄다면, 이제는 코드가 너무 쉽게 실행되어 잘못된 설계를 늦게 발견하는 일이 더 위험합니다.
주니어에게 필요한 하드 스킬의 깊이는 업무마다 다릅니다. 모든 것을 저수준부터 통달한 뒤 AI를 써야 한다는 뜻은 아닙니다. 다만 AI가 낸 답이 왜 맞는지, 어느 조건에서 깨지는지 설명할 수 있을 만큼의 기초는 반드시 쌓아야 합니다.
성장의 단위는 기능이 아니라 제품의 전 과정이다
앞으로 주니어의 성장은 “어떤 프레임워크로 기능 하나를 만들 수 있는가”보다 “제품 프로젝트의 어느 구간까지 책임질 수 있는가”로 측정될 가능성이 큽니다. 제가 현장에서 보는 제품화 과정은 대략 다음과 같습니다.
- 모호한 요구를 수집하고 우선순위를 정해 스펙으로 바꿉니다.
- 화면, 플랫폼 환경, 데이터, 기술 제약을 함께 보고 프로젝트를 설계합니다.
- 주요 사용자 흐름과 예외 흐름을 화면 기획으로 구체화합니다.
- 디자인과 구현 스펙을 연결하고 AI가 일할 수 있는 개발 환경을 구성합니다.
- 테스트, QA, DevOps, 배포를 통해 품질을 제품 수준으로 끌어올립니다.
- 이행과 오픈 이후 발생하는 장애와 사용자 피드백을 운영에 반영합니다.
- 전 과정에서 일정, 위험, 의사결정을 관계자에게 설명합니다.
이 가운데 코딩은 중요한 한 부분이지만 전부는 아닙니다. AI는 정리된 입력과 명확한 성공 조건이 있을 때 강합니다. 반대로 경영진의 매출 요구가 바뀌고, 기획과 디자인이 충돌하고, 기존 시스템의 한계가 뒤늦게 드러나는 상황에서는 사람이 맥락을 연결해야 합니다.
제품 아키텍처도 예쁜 구성도를 그리는 일이 아닙니다. 바뀔 가능성이 높은 요구와 실패 비용이 큰 영역을 찾아 경계를 정하고, 지금의 팀과 예산으로 감당할 수 있는 선택을 하는 일입니다. 특정 기술이 유행한다는 이유가 아니라, 이 제품의 트래픽·보안·운영 인력·출시 일정에 맞는지를 판단해야 합니다.
바이브코딩 다음에는 하네스와 루프가 있다
개인적으로 학습의 중심은 단일 언어나 최신 웹 프레임워크만 파는 방식에서 넓어져야 한다고 봅니다. 출발점은 바이브코딩일 수 있습니다. 자연어로 기능을 요청하고 빠르게 시제품을 만들면서 AI와 협업하는 감각을 익힐 수 있기 때문입니다.
그다음은 하네스 엔지니어링입니다. 여기서 하네스는 AI 에이전트가 안정적으로 일하도록 규칙, 도구, 컨텍스트, 테스트, 권한, 완료 조건을 둘러싸는 실행 환경을 뜻합니다. Claude Code와 OpenAI Codex처럼 도구마다 컨텍스트를 읽는 방식과 강점이 다르므로, 같은 프롬프트를 반복하는 대신 환경을 목적에 맞게 설계해야 합니다.
더 나아가 루프 엔지니어링이 필요합니다. 계획하고 구현하고 검사하고 실패를 수정하는 순환을 사람이 매번 손으로 지시하지 않아도 되도록 만드는 것입니다. 소프트웨어 3.0이라는 관점에서 보면 자연어, 모델, 도구, 기존 코드가 하나의 실행 시스템이 됩니다. 주니어는 단순 사용자가 아니라 그 시스템의 실패 조건을 설계하고 관찰하는 사람이 되어야 합니다.
마지막 단계는 에이전틱 제품 파이프라인입니다. 요구사항에서 배포와 운영까지 여러 AI 작업을 연결하되, 승인 지점과 감사 기록, 롤백 경로를 포함하는 구조입니다. AI 코딩 에이전트가 강력해질수록 중요한 것은 더 많은 권한을 주는 일이 아니라, 권한의 범위와 검증 방식을 명확히 하는 일입니다.
AI가 못하는 기술은 경험 사이의 연결이다
공부만으로 알기 어려운 영역이 있습니다. 고객이 말하지 않은 요구를 대화 속에서 발견하는 일, 서로 다른 부서의 표현을 하나의 스펙으로 번역하는 일, 기술 선택의 한계를 사업 위험으로 설명하는 일입니다. 출시 직전 발견되는 엣지 케이스를 예측하고, 장애가 발생했을 때 무엇부터 복구할지 결정하는 능력도 경험을 통해 자랍니다.
AI는 유사한 패턴과 선택지를 빠르게 제안할 수 있습니다. 하지만 조직이 어떤 위험을 감수할지 대신 책임지지는 않습니다. “정답으로 보이는 설계”와 “우리 팀이 운영할 수 있는 설계” 사이의 차이는 코드만 읽어서 알기 어렵습니다.
커뮤니케이션도 소프트 스킬이라는 이름으로 가볍게 다룰 일이 아닙니다. 요구 변경의 영향을 추적하고, 지연 가능성을 일찍 알리고, 기술 부채를 비용과 일정의 언어로 설명하는 것은 전문 기술입니다. 화면 설계와 데이터 구조, 매출 목표와 배포 계획 사이의 연결을 관리하는 능력이 개인의 전문성으로 축적됩니다.
프로젝트의 개인 성과는 커밋 수처럼 단순하게 드러나지 않습니다. 그러나 관계자들은 누가 문제를 먼저 발견했고, 누가 정보를 투명하게 공유했으며, 누가 마지막까지 마무리했는지 생각보다 면밀히 기억합니다.
AI 생산성은 모두에게 주어진 출발선이다
조금 쓴소리를 하겠습니다. AI로 생산성이 높아졌다는 사실만으로 개인의 경쟁력이 생기지는 않습니다. 같은 도구는 동료와 경쟁자도 사용합니다. AI가 10배 빠르게 초안을 만들어 준다면, 시장은 머지않아 그 속도를 기본값으로 받아들입니다.
차이는 남는 시간을 어디에 쓰느냐에서 생깁니다. 생성된 코드를 검증하고, 실패를 재현하고, 사용자에게 물어보고, 프로젝트의 다음 병목을 공부하는 사람은 더 넓은 책임을 맡게 됩니다. 반면 결과가 그럴듯하다는 이유로 이해와 검증을 건너뛰면 생산성은 숫자의 허상에 머뭅니다.
전문직에서 시간은 결국 돈과 기술로 바뀝니다. 기술을 얼마나 짧은 시간에 필요한 만큼 습득하고, 현장 경험으로 전환하느냐가 성장의 갈림길입니다. 제가 만난 사례만 놓고 보면 업무 밖에서 자신의 기술을 드릴하는 사람은 드물었고, 학습을 미루는 습관은 몇 년 뒤에도 쉽게 바뀌지 않았습니다.
조금 불편하게 들릴 수 있지만, 워라밸과 SNS 생활을 우선하면서 휴일에도 제품을 만들거나 기술을 실험하는 시간을 전혀 쓰지 않는다면 개발자로서의 성장은 취약해질 수밖에 없다고 생각합니다. 회사가 모든 학습 시간을 마련해 주기를 기다리는 것도 현실적이지 않습니다. 물론 건강을 망칠 정도의 장시간 노동을 권하는 말은 아닙니다. 각자의 사정 안에서 지속 가능한 시간을 확보해야 하지만, 기술에 시간을 쓰지 않고 전문성이 저절로 쌓이기를 기대할 수는 없습니다.
주니어의 목표는 프로젝트 전체를 보는 사람이 되는 것
AI 시대의 주니어 개발자는 모든 분야의 전문가가 될 필요가 없습니다. 대신 자신이 맡은 한 부분이 요구사항, 디자인, 데이터, 인프라, QA, 운영과 어떻게 연결되는지 볼 수 있어야 합니다. 처음에는 한 구간을 깊게 맡고, 다음 프로젝트에서 앞뒤 구간으로 책임 범위를 넓히는 방식이 현실적입니다.
하드 스킬은 AI 덕분에 더 빨리 습득할 수 있습니다. 쉬워진 것은 시작이지 공부의 종료가 아닙니다. 낮은 수준의 기초 기술, AI 코딩 환경, 하네스 엔지니어링, 제품 아키텍처, 팀 프로젝트 관리가 새로운 학습 묶음이 되어야 합니다.
3편에서는 이 성장 방향이 실제 채용 질문으로 어떻게 바뀌는지 다루겠습니다. 개인 프로젝트와 팀 프로젝트에서 무엇을 확인하고, AI 기술 트렌드를 안다는 말을 어떤 경험으로 증명해야 하며, 면접관과 지원자가 서로를 어떻게 평가할 수 있는지 제 경험의 범위 안에서 정리하겠습니다.
댓글 없음:
댓글 쓰기