AI 네이티브 엔지니어 시대, 개발자의 일은 어떻게 바뀌는가
AI 네이티브 엔지니어가 온다
나는 지금 새로운 유형의 엔지니어가 등장하고 있다고 본다.
내가 말하는 그 유형은 AI 네이티브 엔지니어다.
예전에는 프로그래밍 언어를 익히는 게 핵심이었다면, 이제는 AI 자체가 하나의 새로운 언어가 되고 있다.
지금 막 노동시장에 들어오는 주니어 개발자, 주니어 엔지니어 세대는 이 변화를 가장 먼저 자기 몸으로 겪는 첫 세대가 될 가능성이 크다.
앞으로 개발자 한 명은 단순히 코드를 직접 치는 사람이 아니라, 여러 에이전트를 관리하는 사람이 되기 쉽다.
나는 이 변화가 꽤 크다고 본다.
다만 여기서 많이들 착각하는 게 있다.
에이전트를 더 많이 붙인다고 해서 시스템이 자동으로 더 좋아지는 건 아니다.
오히려 그냥 풀어놓으면 더 나쁜 시스템이 되기 쉽다.
여러 에이전트를 제대로 다루는 능력은 게임의 마지막 보스 같은 역량이고, 이걸 정말 잘하는 사람은 지금도 상위 0.1%에 가깝다.
내가 보는 지금의 주니어 시장
나는 샌프란시스코의 초기 스타트업에서 AI를 맡고 있고, 스탠포드에서 현대 소프트웨어 개발자라는 수업도 가르친다.
그 수업은 SDLC 전반에서 AI를 어떻게 쓰는지에 초점을 맞춘 수업인데, 공지 후 몇 시간 만에 100명이 넘는 학생이 몰렸다.
그만큼 학생들도 이 변화가 진짜라는 걸 감지하고 있다고 본다.
그런데 채용 시장은 훨씬 더 거칠다.
나는 버클리를 막 졸업한 학생이 거의 천 군데에 지원하고도 두 군데에서만 답을 받았다는 이야기를 들었다.
면접을 본 것도 아니고, 그냥 답장을 받은 곳이 그 정도였다는 뜻이다.
이건 단순히 경기가 안 좋아서 생긴 일이 아니다.
몇 가지 큰 흐름이 한꺼번에 겹쳤다.
첫째, 2021년 전후로 기업들이 대규모 채용을 했다가 과잉채용이었다는 걸 깨닫고 대규모 감원으로 돌아섰다.
둘째, 지난 10~15년 동안 CS 전공과 관련 교육과정이 엄청나게 커지면서 시장에 나오는 졸업생 수 자체가 크게 늘었다.
내 체감으로는 두 배, 많게는 세 배 가까이 불어난 느낌이다.
셋째, AI가 대중화되면서 기업들이 “정말 더 많은 사람을 뽑아야 하나, 아니면 AI에 익숙한 적은 인원으로 같은 일을 할 수 있나”를 본격적으로 고민하기 시작했다.
그래서 지금의 주니어는 예전과 다르다.
이제는 단순히 코딩을 배운 사람이 아니라, 탄탄한 기본기를 갖추면서도 동시에 AI 네이티브하게 일할 수 있는 사람이어야 한다.
지금 노동시장에 들어오는 세대가 바로 그 전환의 첫 세대라고 나는 생각한다.
상위 1%는 에이전트를 어떻게 다루나
나는 학생들에게 처음부터 “에이전트 10개를 동시에 돌려라”라고 말하지 않는다.
누가 어디서 한 번에 10개를 굴린다고 해도, 그 숫자 자체가 목표가 되면 안 된다.
그건 결과일 뿐이지 출발점이 아니다.
내가 더 중요하게 보는 건 순서다.
먼저 에이전트 하나로 복잡한 작업을 안정적으로 끝낼 수 있어야 한다.
그 다음에야 서로 충돌하지 않는 독립적인 작업을 나눠서 두 번째, 세 번째 에이전트를 붙일 수 있다.
예를 들어 한 에이전트가 로고를 수정하고 있다면, 다른 에이전트는 헤더 문구를 바꾸는 식으로 완전히 분리된 일을 맡길 수 있다.
핵심은 병렬화 그 자체가 아니라, 사람이 먼저 작업의 경계를 제대로 설정하는 데 있다.
나는 멀티 에이전트 운영이 결국 관리의 문제라고 본다.
실제로는 아주 똑똑하고 열정적인 인턴 여러 명을 동시에 굴리는 것과 비슷하다.
그들이 터미널이나 IDE 안에서 코드를 쓰고 뭔가를 계속 만들어내는 걸 보면 생산성은 놀랍다.
하지만 어느 순간 막히고, 서로 다른 작업 맥락을 동시에 기억해야 하는 순간이 온다.
그래서 가장 중요한 역량 중 하나가 컨텍스트 스위칭이다.
1번 에이전트가 어디까지 했는지, 2번은 왜 막혔는지, 3번에는 어떤 맥락을 추가로 줘야 하는지 빠르게 복구하고 밀어주는 능력이 있어야 한다.
이건 사실 AI만의 문제가 아니다.
좋은 인간 관리자가 갖는 능력과 거의 같다.
내가 보기에 에이전트를 잘 다루는 사람은 대체로 사람을 관리해본 경험이 있거나, 최소한 그 방식으로 사고할 줄 아는 사람이다.
에이전트 친화적인 코드베이스가 필요하다
나는 코드베이스도 이제 사람만을 위한 공간이 아니라고 생각한다.
에이전트가 들어왔을 때도 이 프로젝트가 어떻게 움직이고, 무엇이 정답이고, 어디까지가 안전한 변경인지 이해할 수 있어야 한다.
그래서 테스트는 단순한 QA 절차가 아니라 계약이다.
테스트가 충분하지 않으면 소프트웨어의 경계도 충분히 정의되지 않은 것이다.
경계가 정의되지 않으면 에이전트는 안전하게 움직일 수 없다.
README와 실제 코드가 어긋나 있는 상태도 굉장히 위험하다.
사람이 봐도 헷갈리는 상태라면, 에이전트는 그 혼란을 더 빠르게 증폭시킨다.
에이전트는 실수를 빠르게 누적시키는 데 아주 능하다.
처음 본 문맥이 조금만 틀려도, 그 오해를 기반으로 다음 단계에서 더 큰 오류를 만들어낸다.
그래서 나는 에이전트가 처음 보는 코드의 상태가 정말 중요하다고 본다.
첫인상이 단단해야 한다.
설계가 일관돼 있어야 하고, 테스트가 있어야 하고, 빌드가 안정적이어야 하고, 린트와 스타일 규칙도 분명해야 한다.
디자인 패턴과 API 사용 방식도 코드베이스 전체에서 최대한 일관돼야 한다.
사람이 봐도 “여기서는 왜 저 API를 쓰고, 저기서는 왜 다른 API를 쓰지?”라는 질문이 나오면, 에이전트도 똑같이 헷갈린다.
에이전트 친화적인 코드베이스는 사실 사람 친화적인 코드베이스이기도 하다.
좋은 소프트웨어와 뛰어난 소프트웨어의 차이
기능적으로 돌아가는 소프트웨어와 정말 인상적인 소프트웨어를 가르는 건 결국 취향이라고 생각한다.
여기서 말하는 취향은 겉모양만의 문제가 아니다.
무엇을 더 밀어붙여야 하는지, 어디서 한 번 더 고민해야 하는지, 무엇이 제품을 한 단계 더 낫게 만드는지 아는 감각에 가깝다.
학생들에게 과제를 주면 대부분은 요구사항을 충족하는 데서 멈춘다.
그 자체로도 나쁘지 않다.
하지만 어떤 학생들은 거기서 멈추지 않는다.
보너스 과제나 extra credit을 스스로 찾아 들어가고, 점수를 더 받기 위해서가 아니라 문제를 더 잘 풀고 싶어서 자기 시간을 더 쓴다.
그 마지막 구간에서 차이가 난다.
기능을 조금 더 확장하고, 조금 더 견고하게 만들고, 조금 더 가능성을 열어놓는 사람들.
그런 사람들이 결국 더 큰 제품을 만든다.
내 수업에서 가장 인상적인 학생들은 과제가 끝난 뒤에도 프로젝트를 계속 붙들고 있었고, 어떤 경우에는 아예 그 프로젝트를 스타트업으로 밀고 나갔다.
나는 그 태도가 상위 엔지니어를 만드는 핵심 중 하나라고 본다.
실험을 워크플로에 넣어야 한다
나는 AI 네이티브 소프트웨어 개발의 핵심 단어가 실험이라고 생각한다.
겉으로 보기엔 다 답을 알고 있는 것처럼 보이는 팀들도 실제로는 계속 시행착오를 겪는다.
예를 들어 Anthropic의 Claude 팀처럼 아주 강한 팀들도 자기들이 만든 도구로 자기 제품을 다시 쓰고, 다시 검증하고, 피드백을 받아 계속 바꾼다.
그들도 실험하면서 배우는 중이라는 뜻이다.
그래서 중요한 건 “정답 도구 하나를 찾는 것”이 아니다.
실험 자체를 일상적인 워크플로로 만드는 일이다.
나는 학생들에게 도구 추천은 해줄 수 있다.
어떤 툴이 왜 괜찮은지, 어디서 강한지 설명도 해줄 수 있다.
하지만 결국에는 스스로 벽에 머리를 좀 부딪쳐 봐야 한다.
직접 써보고, 왜 잘 되는지, 왜 안 되는지, 자신에게 맞는 방식이 뭔지를 몸으로 알아내야 한다.
실험, 해킹, 반복 개선이 자연스럽게 자기 일하는 방식 안에 들어가야 한다.
그래도 나는 주니어 개발자를 믿는다
오히려 나는 지금 같은 시기에 주니어 개발자가 더 중요해질 수도 있다고 본다.
많은 시니어 개발자는 AI 도구에 저항적이다.
그들이 게을러서가 아니라, 이미 너무 오랫동안 자기 방식으로 잘해왔기 때문이다.
“나는 이렇게 해왔고, 이게 맞아”라는 관성이 강할 수밖에 없다.
반대로 업계에 처음 들어오는 사람은 스펀지처럼 흡수한다.
아직 산업의 복잡함에 겁먹지 않았고, 어떤 문제를 보면 “이건 너무 어려워”보다 “한번 해보면 되지 않을까?”에 더 가깝다.
나는 그 순진함이 오히려 큰 자산이라고 본다.
특히 스타트업에서는 더 그렇다.
새로운 툴과 새로운 패턴을 가장 빨리 자기 것으로 만드는 건 종종 처음 배우는 사람들이다.
취업 시장이 어렵다는 사실과, 주니어가 앞으로 더 중요해진다는 사실은 동시에 참일 수 있다.
나는 지금 배우기 시작하는 사람들이 오히려 더 민첩하고, 더 빠르게 AI 네이티브한 습관을 자기 것으로 만들 수 있다고 본다.
그래서 그들은 어떤 영역에서는 경력이 더 긴 개발자보다 더 빠르게 앞서갈 수 있다.
소프트웨어 교육의 본질은 사고 훈련이다
나는 소프트웨어를 가르친다는 게 결국 사고 방식을 가르치는 일이라고 생각한다.
복잡한 시스템을 쪼개고, 작동 방식을 이해하고, 문제를 고치고, 다시 확장하는 과정은 컴퓨터 과학이면서 동시에 일종의 수학적 훈련에 가깝다.
그래서 나는 개발을 배우는 일이 단지 언어 문법을 익히는 일이라고 보지 않는다.
생각하는 법을 배우는 일에 더 가깝다고 본다.
좋은 개발자는 문제가 생겼을 때 그냥 돌아서지 않는다.
“왜 이런 일이 생겼지?”
“안쪽에서는 무슨 일이 벌어지고 있지?”
이 질문을 붙잡고 더 깊이 들어간다.
어쩌면 그건 약간의 오만함일 수도 있다.
어떤 문제를 봐도 소프트웨어로 풀 수 있다고 믿는 태도 말이다.
그런데 나는 바로 그 자신감이 개발자의 가장 강한 자질 중 하나라고 생각한다.
