개요
AI가 소프트웨어 개발의 모든 단계를 바꾸고 있는 지금, 개발자로서 살아남으려면 무엇이 달라져야 할까. 이 영상은 샌프란시스코 스타트업에서 AI를 총괄하고 스탠포드에서 “모던 소프트웨어 개발자” 강의를 가르치는 미하일이 직접 관찰한 현장 이야기를 담고 있다. 그는 주니어 개발자의 취업 위기, 멀티 에이전트 오케스트레이션, 에이전트 친화적 코드베이스, 그리고 AI 네이티브 제품 개발이라는 네 가지 큰 주제를 통해 지금 이 시대 개발자에게 실제로 필요한 역량이 무엇인지를 구체적으로 설명한다.
이 영상은 EO Korea가 제작한 콘텐츠로, 현직 AI 리드와 하버드 비즈니스 스쿨 교수의 인터뷰를 함께 엮어 현장감 있는 시각을 전달한다.
주니어 개발자에게 무슨 일이 벌어지고 있나
미하일은 버클리를 갓 졸업한 친구가 1,000군데에 지원해서 겨우 두 곳에서만 연락을 받았다는 사례를 직접 언급했다. 면접까지 간 것도 아니고, 단순히 답장을 받은 것이 두 곳뿐이었다.
왜 이렇게 됐을까. 그는 세 가지 요인이 동시에 맞물렸다고 설명한다. 첫째, 2021년 이후 기업들이 과잉 채용을 했다가 20~30%씩 구조조정을 단행했다. 둘째, 지난 10~15년 사이 CS 전공 졸업생 수가 두 배에서 세 배로 늘었다. 셋째, AI가 부상하면서 많은 고용주들이 “더 많은 인원을 뽑을까, 아니면 AI에 능숙한 소수를 뽑을까”를 저울질하기 시작했다.
이 세 가지가 한꺼번에 터졌다. 결과적으로 지금 막 취업 시장에 진입하는 세대는 탄탄한 기초 실력과 완전한 AI 활용 능력을 동시에 갖춰야 하는 첫 번째 세대가 됐다.
상위 1%의 에이전트 오케스트레이션
미하일은 멀티 에이전트 워크플로를 다루는 능력을 “게임의 마지막 보스”에 비유한다. 잘하면 오늘날에도 상위 1% 사용자가 될 수 있다는 얘기다.
가장 흔한 실수는 처음부터 에이전트를 10개씩 돌리는 것이다. 그 대신 이런 순서를 권한다.
먼저 에이전트 하나로 복잡한 소프트웨어를 제대로 만들 수 있을 때까지 숙달한다. 그다음, 본 작업과 독립적으로 분리될 수 있는 작은 작업을 찾아 두 번째 에이전트를 추가한다. 예를 들어 로고 수정은 헤더 카피 수정과 완전히 별개다. 두 번째가 잘 돌아가면 세 번째를 추가한다. 핵심은 각 작업 사이의 경계를 명확히 아는 것이다.
두 번째로 중요한 기술은 컨텍스트 전환이다. 에이전트들은 터미널이나 IDE에서 묵묵히 코드를 써 내려가는 열정적인 인턴과 같다. 그런데 가끔 막힌다. 그때 에이전트 1이 뭘 하고 있었는지, 에이전트 2는 어디까지 갔는지 파악하면서 각각을 의미 있게 앞으로 밀어주는 능력이 필요하다.
그는 이 능력이 결국 좋은 인간 관리자의 역량과 같다고 말한다. 실제로 인간 개발자 팀을 이끌어본 경험이 있는 사람들이 멀티 에이전트 워크플로에서도 두각을 나타내는 이유가 여기에 있다.
에이전트 친화적 코드베이스 만들기
에이전트를 코드베이스에 풀어놓는다고 생각해보자. 그 에이전트가 코드베이스 안에서 무슨 일이 벌어지고 있는지 이해할 수 있을까. 미하일은 “에이전트 친화적 코드베이스”라는 개념을 통해 이 질문에 답한다.
테스트 커버리지: 에이전트는 명시적으로 정의된 계약에 따라서만 움직인다. 그 계약이 바로 테스트다. 테스트 커버리지가 충분하지 않으면 에이전트가 무언가를 만들어도 그것이 맞는지 틀린지 확인할 수가 없다.
README와 코드의 일관성: README는 코드가 바뀌는 즉시 구식이 되어버린다. README는 이걸 말하는데 코드는 저걸 하고 있으면, 에이전트는 어느 쪽을 따라야 할지 모른다. 이 두 가지를 일치시키는 것은 단순하지만 결정적인 일이다.
오류 복합화 방지: 에이전트는 오류를 굉장히 빠르게 증폭시킨다. 1단계에서 잘못 이해한 것을 2단계에서 더 크게 강화한다. 그러므로 에이전트가 처음 보는 코드가 완전히 견고해야 한다. 잘 테스트되고, 린팅과 스타일 검사가 적용되고, 일관된 형식을 갖춰야 한다.
일관된 디자인 패턴: 코드베이스 한쪽에서는 객체를 API A로 만들고, 다른 쪽에서는 같은 객체를 API B로 만들면 에이전트도 헷갈리고 인간도 헷갈린다. 에이전트에게만 적용되는 얘기가 아니다. 새로운 팀원이 합류했을 때 같은 혼란을 겪는다면, 그 코드베이스는 누구에게도 친화적이지 않은 것이다.
평범한 소프트웨어와 탁월한 소프트웨어의 차이
그는 이 차이를 한 단어로 “취향”이라고 표현한다. 취향이 있는 사람과 없는 사람이 있는 게 아니라, 취향을 발전시키는 데 더 많은 시간을 쓰는 사람이 있을 뿐이다.
스탠포드 수업에서 그가 관찰한 것은 이렇다. 과제 요구사항인 다섯 가지 플로를 만들고 그것으로 끝내는 학생이 있다. 반면, 100점을 받았어도 “더 어려운 보너스 문제를 해보고 싶다”며 계속 파고드는 학생이 있다. 점수가 아니라 문제 자체를 더 잘 풀고 싶다는 욕구에서 나오는 행동이다.
수업이 끝난 뒤에도 같은 프로젝트로 스타트업을 차리고 있는 학생들이 바로 이 부류다. 탁월한 소프트웨어는 그 “마지막 1마일”에서 만들어진다.
실험을 일하는 방식의 일부로 만드는 것도 여기에 속한다. 클로드를 만드는 앤트로픽 팀조차도 클로드를 이용해 클로드를 매주 또는 격주로 다시 쓴다. 그들도 답을 다 알고 있는 게 아니라 계속 발견해가는 중이다. 전문가도 실험하고 있다는 사실은, 실험을 두려워하지 말라는 강력한 신호다.
세상이 여전히 주니어 개발자를 필요로 하는 이유
시니어 개발자들은 20년간 자신만의 방식에 익숙해진 탓에 AI 도구에 저항하는 경향이 있다고 그는 솔직하게 말한다. “Vim밖에 없다”는 식으로 굳어버린 사고 방식이다.
반면 처음으로 업계에 진입하는 사람들은 스펀지와 같다. 헬스케어가 얼마나 어려운지, 특정 산업이 얼마나 복잡한지 아직 몸에 새기지 않았다. 그래서 “왜 이게 안 돼? 내가 해볼게”라는 태도로 접근한다. 이 긍정적인 순진함이 스타트업 창업가에게 딱 맞는 자질이다.
더 근본적인 이유도 있다. 소프트웨어 개발은 디지털 수단으로 복잡한 시스템을 구축하는 방법을 생각하는 훈련이다. 이것은 CS보다 수학에 가깝고, 결국 사고 훈련이다. 개발자들은 무언가가 작동하지 않을 때 “왜 그런지 알아보자”며 내부로 들어가려는 성향이 있다. 시스템이 안 되면 포기하는 게 아니라 고치려 한다. 미하일은 이것을 “개발자의 오만”이라고 부르는데, 긍정적인 의미에서의 오만이다. 어떤 문제든 소프트웨어로 해결하겠다는 자신감.
AI 네이티브 제품이란 무엇인가
하버드 비즈니스 스쿨 교수 렘 코닝은 이 질문에 명쾌하게 답한다. AI 네이티브의 핵심은 AI로 일을 처리하는 것에 그치지 않고, AI를 제품 안에 내장해서 AI가 고객과 직접 일하게 만드는 것이다.
인간인 나를 루프에서 빼내는 것. 그것이 AI 네이티브 조직을 만드는 열쇠라고 그는 말한다.
그리고 그는 한 가지 흥미로운 질문을 던진다. AI들이 서로 대화하기 시작하면 어떻게 될까. AI들이 협업하기 시작하면 서로에게 무엇을 필요로 할까. 이 질문에 답하는 데서 수조 달러짜리 회사들이 나올 가능성이 있다고 그는 본다.
반면, 한 달 동안 매일 “클로드야 이것 만들어줘”를 반복해서 과하게 정교한 소프트웨어를 만들어놓고 출시했더니 아무도 원하지 않더라는 시나리오도 경고한다. 도구를 다루는 능력과 무엇을 만들어야 하는지 아는 능력은 별개다.
실전 가이드
영상에서 다룬 핵심 개념들을 지금 당장 적용해볼 수 있는 순서로 정리했다.
먼저 에이전트 하나로 숙달한다. 단일 에이전트로 복잡한 작업을 완수하는 경험을 여러 번 쌓는다. 이 과정에서 에이전트가 어떤 맥락을 요구하고, 어디서 막히며, 어떤 지시가 명확한지 몸으로 익혀야 한다.
다음으로 코드베이스를 점검한다. 지금 작업하는 코드베이스에 테스트 커버리지가 있는지, README가 실제 코드와 일치하는지, 비슷한 작업을 하는 방식이 일관되게 통일되어 있는지 살펴본다. 에이전트를 쓰기 전에 이것들부터 정리하면 오류 복합화를 크게 줄일 수 있다.
그 다음, 작업의 경계를 명확히 나눈 뒤 에이전트를 하나씩 추가한다. 두 번째 에이전트를 추가할 때 기준은 “이 작업이 첫 번째 에이전트가 하는 일과 완전히 독립적인가”이다. 독립적이지 않으면 분리하거나 하나의 에이전트로 처리하는 편이 낫다.
마지막으로 실험을 두려워하지 않는다. 앤트로픽 팀도 매주 자신들의 제품을 다시 써가며 발견해나가고 있다. 어떤 도구가, 어떤 지시 방식이 내 워크플로에 맞는지는 직접 부딪혀봐야 안다.
비판적 검토
영상은 현직 AI 리드가 실제로 관찰한 사례들을 중심으로 구성되어 있어 현장감이 높다. 특히 에이전트 오케스트레이션을 “게임의 마지막 보스”로 표현하고, 관리자 경험이 있는 사람들이 이 영역에서 두각을 나타낸다고 말하는 부분은 실무적으로 납득할 수 있는 통찰이다.
다만 영상은 미하일 개인의 경험과 스탠포드 강의실 관찰에 상당 부분 기댄다. 더 넓은 데이터나 산업 전반의 통계 없이 “주니어 개발자가 여전히 필요하다”는 결론으로 이어지는 부분은 희망적인 해석에 가깝다. 실제로 많은 회사들이 주니어 채용을 줄이고 있다는 사실과 함께 읽어야 균형 있는 시각을 가질 수 있다. AI 네이티브 역량을 쌓아도 취업 시장이 단기간에 달라지지 않을 수 있다는 점도 염두에 둬야 한다.
핵심 요점
- 지금 취업 시장에 진입하는 개발자들은 탄탄한 기초와 AI 네이티브 역량을 동시에 요구받는 첫 번째 세대다. 과잉 채용 후 구조조정, CS 졸업생 폭증, AI의 부상이라는 세 가지 요인이 동시에 작용하고 있기 때문이다.
- 멀티 에이전트 오케스트레이션은 처음부터 많이 돌리는 게 아니라, 에이전트 하나를 잘 다루는 것에서 시작해 작업의 경계를 명확히 하면서 하나씩 추가하는 방식으로 숙달한다.
- 에이전트를 코드베이스에 풀기 전에 먼저 코드베이스 자체를 정비해야 한다. 테스트 커버리지, README와 코드의 일관성, 통일된 디자인 패턴이 없으면 에이전트는 오류를 빠르게 복합화한다.
- 탁월한 소프트웨어는 과제를 채우는 것에서 멈추지 않고 그 이후에도 계속 파고드는 “마지막 1마일”에서 만들어진다. 이 습관을 기르는 것이 결국 취향이 된다.
- AI 네이티브 제품의 핵심은 AI를 써서 일하는 것이 아니라, AI를 제품 안에 내장해 고객과 직접 상호작용하게 만드는 것이다. 인간인 나를 루프에서 빼내는 것이 목표다.