AI와 주니어 개발자
최근 한 기술 블로그에서 'Yes, and…'라는 제목의 흥미로운 글을 읽었다. 몬태나 주립대학교에서 컴퓨터 과학을 가르치는 한 교수가 쓴 글이었는데, AI 시대에도 여전히 프로그래밍을 배워야 하는가에 대한 그의 고찰이 담겨 있었다. 그는 프로그래밍이 근본적으로 컴퓨터를 이용한 문제 해결과 복잡성 제어에 관한 것이기에 그 가치는 변하지 않을 것이라고 주장한다. 하지만 주니어 개발자들에게는 매우 엄격한 태도를 보인다. AI가 코드를 생성해줄 수 있더라도 절대로 그렇게 하지 말고 직접 코드를 짜야 한다고 강조한다. 코드를 직접 짜지 않으면 코드를 읽는 능력을 기를 수 없고, 결국 자신이 이해하지 못하는 시스템을 만드는 ‘마법사의 제자’ 함정에 빠지게 된다는 논리다. 그는 AI를 코드 생성기가 아니라 개념 이해를 돕는 유능한 조교(TA)로 활용하라고 조언한다.
하지만 내 생각은 다르다. 저자의 시각은 고전적인 교육자의 관점에서는 타당할지 모르나, 지금 우리가 겪고 있는 거대한 패러다임의 전환기를 지나치게 보수적으로 해석하고 있다는 생각이 들었다. 나는 그가 말하는 '직접 코드를 짜야 한다’는 원칙이 이제는 일종의 낭만적인 고집이 되어버렸다고 생각한다. 우리는 지금 프로그래밍이라는 행위 자체가 재정의되는 과도기에 서 있다. 나처럼 이미 10년 넘게 현업에서 구르며 기본 지식과 경험을 쌓은 사람들에게는 AI가 날개를 달아주는 도구임이 분명하다. 하지만 주니어 개발자나 학생들에게 '옛날 방식’을 고수하라고 강요하는 것이 과연 그들의 미래에 도움이 될지는 의문이다.
저자는 주니어 개발자가 AI로 코드를 생성하기만 하면 '참호 속의 전투’에서 얻는 생생한 이해를 놓치게 된다고 경고한다. 하지만 나는 이 '참호 속의 전투’가 이제는 불필요한 고행이 되고 있다고 본다. 과거에는 어셈블리어를 알아야 C언어를 잘 이해할 수 있다고 했고, C언어를 알아야 자바나 파이썬의 메모리 구조를 이해할 수 있다고 했다. 하지만 지금 자바스크립트로 훌륭한 서비스를 만드는 개발자들 중에 어셈블리어를 만져본 사람이 얼마나 되겠는가? 추상화의 단계가 올라가면 하위 단계의 고통은 자연스럽게 도구의 몫으로 넘겨야 한다. AI는 그저 그 추상화의 층위를 한 단계 더 높인 것뿐이다.
저자는 고수준 언어로의 전환과 AI 생성 코드의 차이점을 설명하며, 컴파일러는 결정론적이지만 AI는 그렇지 않다는 점을 지적한다. AI가 생성한 코드는 우발적 복잡성을 추가할 수 있고 부적절한 접근 방식을 선택할 수 있다는 것이다. 맞는 말이다. 하지만 이것은 기술의 불완전성에서 오는 일시적인 문제일 뿐이다. 컴파일러 초기 시절에도 생성된 기계어 코드가 비효율적이라는 비판이 있었지만, 결국 도구는 발전했고 인간은 그 도구를 신뢰하게 되었다. AI가 내뱉는 코드에 버그가 있거나 비효율적일 수 있다는 사실은 주니어 개발자가 코딩을 직접 해야 할 이유가 아니라, AI가 내놓은 결과물을 검증하고 조율하는 능력을 키워야 할 이유가 된다.
이제 책 맨 앞장에서 'hello world’부터 찍어보고 문법을 달달 외우는 방식의 학습은 아무런 의미가 없다. 그런 정보는 AI가 세상에서 가장 잘 알고 있기 때문이다. 중요한 것은 이 굉장한 도구를 어떻게 활용하여 내가 원하는 결과물을 만들어낼 것인가 하는 '오케스트레이션’의 능력이다. 주니어 개발자가 AI에게 '이 코드를 짜줘’라고 말하는 것을 금지할 것이 아니라, 'AI가 짠 이 코드가 왜 이렇게 작동하는지, 더 나은 방법은 없는지’를 AI와 토론하며 배우게 해야 한다. 이것이 저자가 말한 ‘조교로서의 AI’ 활용법과 맞닿아 있는 듯 보이지만, 핵심적인 차이는 '코드 생성 자체를 두려워하지 말아야 한다’는 점이다.
나는 이전에도 강조했듯이 코드는 예술 작품이 아니라고 생각한다. 코드는 문제를 해결하기 위한 도구이자 수단일 뿐이다. 누군가는 한 땀 한 땀 코드를 직접 짜며 장인정신을 느낄 수도 있겠지만, 산업 현장에서의 코딩은 철저하게 비즈니스 가치를 창출하기 위한 공학적 프로세스다. 사용자는 그 코드가 AI에 의해 1초 만에 생성되었는지, 사람이 며칠 밤을 새우며 짰는지 전혀 관심이 없다. 그들에게 중요한 것은 오직 그 프로그램이 자신의 문제를 제대로 해결해주는가 하는 점이다. 저자가 우려하는 ‘영혼 없는 복제품’ 같은 코드가 양산되는 것은 AI의 잘못이 아니라, 그 코드를 사용하는 인간의 책임감이 부족하기 때문이다.
생산성이라는 측면에서 AI는 축복이다. 예전에는 단순한 기능을 구현하는 데만도 수많은 보일러플레이트 코드를 작성하며 시간을 허비해야 했다. 하지만 이제는 그런 지루한 작업은 AI에게 맡기고, 개발자는 더 높은 수준의 아키텍처와 사용자 경험을 고민하는 데 시간을 써야 한다. 저자는 주니어가 간단한 작업을 AI에게 맡기면 나중에 아키텍트가 될 직관을 기를 수 없다고 말한다. 하지만 나는 반대로 생각한다. AI 덕분에 주니어 시절부터 더 넓은 시스템의 구조를 조망할 기회를 일찍 갖게 된다면, 그들이 훨씬 더 빠르게 아키텍트의 시야를 가질 수 있지 않을까?
소위 말하는 '바이브 코딩(vibe coding)'에 대한 비판도 다시 생각해볼 필요가 있다. 저자는 시니어들이 AI를 쓰면서도 직접 코딩하는 감각을 잃지 않으려 노력해야 한다고 말하지만, 사실 경험이 풍부한 이들은 이미 무엇이 좋은 코드인지에 대한 기준이 머릿속에 박혀 있다. 그들에게 AI는 타자기를 대신해주는 비서와 같다. 그렇다면 주니어들은? 그들은 AI를 통해 수많은 '좋은 코드’의 사례를 접하며 자신의 기준을 만들어나가야 한다. 직접 타이핑하는 고통을 겪어야만 지식이 습득된다는 생각은 펜으로 글을 써야만 문장력이 늘어난다는 주장만큼이나 구시대적이다.
최근 개발자 취업 시장이 어렵다는 이야기가 많다. 저자는 이를 일시적인 경기 순환의 문제로 보고 인맥을 동원하라는 지극히 현실적이고도 씁쓸한 조언을 한다. 하지만 나는 시장이 변한 근본적인 이유 중 하나가 바로 AI로 인한 생산성 폭발에 있다고 본다. 기업은 이제 단순히 '코드를 짤 줄 아는 사람’을 원하지 않는다. AI를 활용해 혼자서 서너 명의 몫을 해낼 수 있는 '문제 해결사’를 원한다. 이런 상황에서 주니어들에게 '기본을 다지기 위해 AI를 쓰지 마라’고 가르치는 것은, 전쟁터에 나가는 병사에게 총 대신 칼을 들고 연습하라고 말하는 것과 다를 바 없다.
결국 소울이나 장인정신이라는 단어는 기술적 변화에 대한 공포를 가리기 위한 멋들어진 핑계에 불과할지도 모른다. 변화에 적응하지 못하고 과거의 수작업 방식에 매몰된 이들이 AI라는 거대한 흐름을 거부하기 위해 꺼내든 카드 말이다. 하지만 기술의 역사는 언제나 효율적인 도구를 선택한 이들의 손을 들어주었다. 코딩에서 소울을 찾는 것이 아니라, 당신이 만든 서비스가 사용자에게 줄 수 있는 가치에서 소울을 찾아야 한다. 개발자는 예술가가 아니라 해결사여야 하며, AI는 그 해결 능력을 무한히 확장해주는 가장 강력한 무기다.
저자가 말한 'Yes, and…'는 주니어들에게는 'Yes, but AI first’가 되어야 한다고 생각한다. 프로그래밍의 가치는 여전하지만, 그 방식은 완전히 달라졌다. 직접 코드를 짜는 고통이 실력을 보장해주던 시대는 끝났다. 이제는 얼마나 영리하게 도구를 다루느냐가 실력의 척도가 된다. 회사가 주니어들에게 코드를 짜게 해야 한다는 저자의 말에도 동의한다. 하지만 그 방식은 AI와 협업하여 더 크고 복잡한 문제를 풀 기회를 주는 것이어야지, AI로 1분 만에 할 일을 1시간 동안 직접 하게 만드는 고문을 가하는 것이어서는 안 된다.
나 역시 AI와 함께하는 이 시대가 즐겁다. 예전에는 상상만 하고 포기했던 아이디어들을 이제는 퇴근 후 몇 시간 만에 프로토타입으로 만들어낼 수 있기 때문이다. 이것이 진정한 개발의 즐거움이지, 오타를 잡느라 밤을 새우는 것이 즐거움은 아닐 것이다. 시대는 변했고, 그 변화를 온몸으로 받아들이는 개발자만이 살아남을 수 있다. 고리타분한 원칙 뒤에 숨어 변화를 깎아내리기보다는, 이 강력한 파도를 타고 더 멀리 나아가는 법을 배워야 한다. 우리는 지금 인류 역사상 가장 강력한 '지능의 지렛대’를 손에 쥐고 있다.
관련 글