까만 화면 위로 커서가 한 글자씩 깜빡입니다. 주니어 개발자는 요구사항을 적었다가 지웁니다. 원하는 동작을 설명하고, 예외를 덧붙이고, 기존 코드가 지켜야 할 규칙을 붙입니다. 잠시 뒤 코딩 에이전트가 파일 여러 개를 고칩니다. 결과를 실행한 다음에는 또 다른 모델에게 변경 내용을 검토시킵니다.
이 장면은 더 이상 낯선 실험이 아닙니다. 직접 코드를 쓰는 시간보다 무엇을 시킬지 정하고, 나온 코드를 읽고, 틀린 부분을 찾아내는 시간이 길어진 주니어가 이미 많습니다. 생산성은 분명 올라갔습니다. 동시에 “지금 배우는 게 몇 년 뒤에도 남을까”라는 불안도 커졌습니다.
그 불안을 “기본기만 열심히 하면 된다”는 말로 달래기는 어렵습니다. 반대로 “코딩은 곧 사라진다”며 도구 사용법만 익히는 것도 위험합니다. 지금 필요한 건 어느 한쪽을 고르는 일이 아니라, 기본기를 배우는 순서와 증명하는 방식을 바꾸는 일입니다.
코드를 쓰는 시간보다 판단하는 시간이 길어졌다
예전의 주니어는 작은 기능을 맡아 직접 구현하며 언어와 프레임워크를 익혔습니다. 지금은 같은 기능의 초안을 AI가 몇 분 안에 만듭니다. 그 덕분에 더 빨리 움직일 수 있지만, 빈칸도 생깁니다. 코드가 돌아간다는 사실과 그 코드를 이해했다는 사실은 같지 않습니다.
Stack Overflow의 2025년 개발자 설문에서 AI 결과를 신뢰한다는 응답보다 신뢰하지 않는다는 응답이 더 많았습니다. 가장 흔한 불만은 “거의 맞지만 완전히 맞지는 않는” 답이었고, 응답자의 45%는 AI가 만든 코드를 디버깅하는 일이 더 오래 걸린다고 답했습니다. AI가 무용하다는 뜻이 아닙니다. 속도와 책임이 서로 다른 곳에 있다는 뜻입니다.
화면에 나타난 코드는 빠르지만, 그 코드가 결제 중복을 만들지 않는지, 로그에 개인정보를 남기지 않는지, 장애 때 되돌릴 수 있는지는 사람이 판단해야 합니다. 주니어가 이 질문을 건너뛰면 AI는 실력을 키워 주는 도구가 아니라 이해하지 못한 코드를 쌓는 지름길이 됩니다.
기본기는 사라지지 않았다. 쓰임이 달라졌다
자료구조, 네트워크, 데이터베이스, 운영체제를 공부하라는 조언은 여전히 맞습니다. 다만 시험 문제를 풀기 위해 외우는 기본기와, AI가 낸 답을 검증하기 위해 쓰는 기본기는 느낌이 다릅니다.
예를 들어 에이전트가 캐시를 추가했다면 주니어는 최소한 세 가지를 물을 수 있어야 합니다.
- 캐시가 없어도 정합성이 유지되는가?
- 만료와 무효화는 어떤 사건을 기준으로 일어나는가?
- 장애가 났을 때 원본 데이터로 돌아갈 수 있는가?
이 질문은 프롬프트 기법이 아니라 시스템 이해에서 나옵니다. SQL을 직접 빠르게 쓰지 못하더라도 실행 계획이 왜 느린지 읽을 수 있어야 하고, HTTP 헤더를 모두 외우지 않더라도 인증 정보가 어디까지 전달되는지 추적할 수 있어야 합니다. 기본기는 코드를 손으로 많이 쓰었다는 증명보다 틀린 결과를 알아볼 수 있는 눈에 가깝습니다.
AI가 빠를수록 주니어의 책임은 더 선명해진다
2025년 Stack Overflow 조사에서 개발자 다수는 배포·모니터링이나 프로젝트 기획을 AI에 맡길 계획이 없다고 답했습니다. 이유는 단순합니다. 이 단계부터는 “정답을 만들었는가”보다 “잘못됐을 때 누가 멈추고 설명할 것인가”가 중요하기 때문입니다.
주니어가 처음부터 거대한 아키텍처를 결정할 필요는 없습니다. 하지만 자신이 맡은 작은 기능의 경계는 설명할 수 있어야 합니다. 입력은 어디서 오고, 어떤 데이터가 바뀌며, 실패하면 무엇이 남고, 누가 다시 실행할 수 있는지 말입니다.
포트폴리오도 같은 기준으로 달라집니다. 화면 열 장과 기능 목록보다 아래 기록이 더 많은 것을 보여줍니다.
| 남겨야 할 기록 | 실제로 보여주는 능력 |
|---|---|
| 처음 적은 요구사항과 바뀐 이유 | 문제를 좁히는 능력 |
| AI가 제안했지만 쓰지 않은 코드 | 선택 기준과 기술 판단 |
| 재현 가능한 실패 사례 | 디버깅과 관찰 능력 |
| 테스트와 운영 로그 | 결과를 검증하는 습관 |
| 장애 시 되돌리는 방법 | 책임 범위와 운영 감각 |
이 기록은 “AI를 썼다”는 고백이 아닙니다. 도구를 쓴 뒤에도 누가 판단했는지를 보여주는 증거입니다.
체감 속도와 실제 속도는 다를 수 있다
AI를 켜면 일이 빨라진다는 느낌은 강합니다. 하지만 느낌만으로 학습 방식을 정하면 안 됩니다. METR은 2025년 초 도구를 대상으로, 자신이 잘 아는 오픈소스 저장소에서 일하는 숙련 개발자들을 관찰했습니다. 참가자들은 AI가 시간을 줄여 줄 것이라고 예상했지만 실제로는 작업 시간이 평균 19% 늘었습니다.
이 결과를 주니어에게 그대로 적용할 수는 없습니다. 대상도 숙련 개발자였고 도구도 빠르게 바뀌었습니다. 그래도 한 가지는 분명합니다. 생성 속도만 재면 검토, 수정, 되돌리기에 쓴 시간을 놓칩니다. 주니어라면 “몇 줄 만들었나”보다 “설명할 수 있는 변경을 얼마나 안전하게 끝냈나”를 재는 편이 낫습니다.
12주 동안 해볼 만한 연습
거창한 커리큘럼보다 작은 서비스 하나를 끝까지 책임져 보는 편이 낫습니다. 로그인, 데이터 저장, 외부 API 한 개, 간단한 관리 화면이 있는 정도면 충분합니다.
1~3주: AI와 함께 만들되 모든 변경을 읽습니다. 에이전트가 고친 파일마다 목적을 한 줄로 적습니다. 설명하지 못하는 변경은 합치지 않습니다.
4~6주: 실패를 일부러 만듭니다. 네트워크 지연, 잘못된 입력, 중복 요청, 만료된 인증을 넣어 봅니다. 먼저 로그로 원인을 좁힌 뒤 AI에게 해결안을 묻습니다.
7~9주: 운영 흔적을 남깁니다. 핵심 요청에 로그를 넣고, 오류를 재현하는 테스트를 만들며, 문제가 생겼을 때 이전 버전으로 돌아가는 절차를 적습니다.
10~12주: 다른 사람에게 넘깁니다. README만 보고 실행할 수 있는지, 왜 이 구조를 골랐는지, 어떤 한계가 남았는지 설명합니다. 동료가 없다면 하루 뒤의 자신이 읽어도 됩니다.
매주 남길 것은 네 줄이면 됩니다.
- 이번 주에 해결하려던 문제
- AI가 만든 변경 중 받아들인 것과 버린 것
- 실제로 발견한 실패 한 가지
- 다음에는 먼저 확인할 항목
이 메모가 쌓이면 유행하는 도구가 바뀌어도 학습은 남습니다.
AI를 끄는 시간도 필요하다
AI 없이 모든 것을 다시 만들라는 뜻은 아닙니다. 다만 자신의 이해가 어디까지인지 확인하려면 짧게라도 도구를 꺼야 합니다. 버그 원인을 종이에 그려 보고, 데이터 흐름을 말로 설명하고, 테스트 케이스를 먼저 적어 보는 식입니다.
반대로 AI를 쓸 때는 숨기지 말고 적극적으로 써야 합니다. 반복 코드를 만들고, 낯선 라이브러리의 진입점을 찾고, 테스트 후보를 넓히는 데 유용합니다. 핵심은 AI 사용 여부가 아니라 어디까지 맡겼고 무엇을 직접 확인했는지입니다.
주니어에게 남는 자리
AI가 코드를 쓰는 시대에도 누군가는 문제를 정의해야 합니다. 누군가는 사용자의 불편을 발견하고, 결과가 틀렸을 때 멈추며, 왜 그런 선택을 했는지 설명해야 합니다. 그 역할은 시니어에게만 예약돼 있지 않습니다.
주니어가 AI와 타자 속도로 경쟁할 필요는 없습니다. 대신 AI가 만든 결과에서 이상한 냄새를 맡고, 근거를 확인하고, 작은 기능 하나를 운영 가능한 상태까지 가져가는 경험을 쌓아야 합니다. 백엔드를 해왔다면 그 위에 AI를 얹으면 됩니다. 프론트엔드를 해왔다면 사용자가 AI의 불확실성을 다룰 수 있는 화면을 설계하면 됩니다.
도구 이름과 직무 이름은 계속 바뀔 겁니다. 문제를 좁히고, 맥락을 이해하고, 결과를 책임지는 태도는 쉽게 사라지지 않습니다. 주니어 개발자가 지금 붙잡아야 할 것은 바로 그 부분입니다.
