몬태나주립대에서 컴퓨터과학을 가르치는 카슨 그로스(htmx 제작자)는 최근 학생과 지인들로부터 같은 질문을 반복해서 받는다고 한다. "AI가 이렇게 발전했는데, 그래도 프로그래머가 되는 게 맞을까요?" 채용 시장이 얼어붙은 지금, 컴퓨터과학을 공부하는 이들에게는 절박한 물음이다. 그의 답은 단호하다. 프로그래밍은 본질적으로 '컴퓨터로 문제를 푸는 것'과 '그 해법의 복잡성을 통제하는 것' 두 가지이며, 이 능력의 가치가 AI 때문에 떨어지는 미래는 상상하기 어렵다는 것이다. 다만 그 과정에서 AI를 어떻게 쓰느냐에 따라 결과가 극명하게 갈린다고 본다.
코드를 쓰지 않으면 읽을 수도 없다
그로스가 가장 경계하는 대상은 주니어 개발자다. AI는 많은 과제의 코드를 곧바로 생성해 주지만, 주니어가 코드를 직접 쓰지 않고 생성에만 의존하면 '참호 속에서 몸으로 익히는' 코드에 대한 감각을 스스로 포기하게 된다. 그는 수업에서 "그래, AI가 이 과제 코드를 만들어 줄 수 있다. 하지만 그렇게 하지 마라. 네가 직접 써야 한다"고 강조한다. 핵심 논리는 간단하다. 코드를 쓰지 못하면 읽지도 못하게 되는데, AI가 코드를 생성하는 미래일수록 '읽는 능력'은 오히려 더 중요해진다는 것이다. 읽지 못하면 자신이 만들었으나 이해하지도 통제하지도 못하는 시스템에 갇히는 '마법사의 제자' 함정에 빠진다.
그는 AI 코드 생성을 어셈블리에서 고급 언어로의 전환에 비유하는 시각에도 선을 긋는다. 컴파일러는 for문이나 if문이 어떤 어셈블리로 번역될지 상당히 결정론적으로 예측할 수 있지만, 같은 프롬프트에 대한 LLM의 출력은 그렇지 않다. 더 중요한 차이는 복잡성이다. 고급 언어는 우발적 복잡성(accidental complexity)을 걷어내 꼭 필요한 복잡성만 남기지만, LLM이 생성한 코드는 부적절한 접근이나 지름길 때문에 오히려 우발적 복잡성을 더 얹기 쉽다. 코드를 읽지 못한다면 이를 분간할 방법조차 없다.
코드 생성기가 아니라 뛰어난 조교로
그렇다고 그가 AI를 적대시하는 것은 아니다. 올바르게 쓰면 AI는 대단히 유능한 조교(TA)가 된다고 말한다. 학습에서 가장 괴로운 순간은 '막히는' 때인데, 특히 도구 체인이 무엇인지도 모른 채 환경 문제로 막히는 경우다. 이는 학습자의 잘못이 아니라 환경의 문제이며, 쓸데없이 막혀 허비한 시간이 적지 않은 이들을 컴퓨터과학에서 이탈시킨다. 그로스 자신도 버클리에서 유닉스를 독학하다 막혀 CS 과정을 중퇴한 경험이 있다고 털어놓는다. AI는 이런 장애물을 넘게 도와줄 수 있으며, 그는 코딩 에이전트를 코드 생성기가 아니라 조교처럼 행동하도록 설정한 AGENTS.md 파일을 학생들에게 제공한다.
순수한 코딩 실력 너머의 역량
그로스는 AI가 프로그래밍을 바꾸긴 하되, 일부의 예상만큼 극적이지는 않을 것이라 본다. 다만 '코딩이라는 행위'의 상대적 가치는 낮아질 수 있다고 인정한다. 손으로 무언가를 만들어 내는 즐거움과 미학이 있기에 아쉬운 일이지만, 대신 다른 역량의 가치가 올라간다. 첫째는 LLM과 사람 모두를 상대로 명료하게 쓰고 사고하고 소통하는 능력으로, 책을 읽고 글을 쓰는 훈련이 도움이 된다. 둘째는 자신이 푸는 비즈니스나 현실 문제를 이해하는 능력이다. 그는 "AI 덕에 프로그래머가 필요 없다"는 경영진의 시각이나 "AI 덕에 비즈니스 담당자가 필요 없다"는 프로그래머의 시각 모두 근시안적이라고 지적한다.
셋째는 소프트웨어 아키텍처, 즉 거대한 시스템을 효과적으로 조직하고 복잡성을 통제하는 능력이다. 그는 '아키텍트'라는 말에 양가감정을 품고 있으면서도 그 중요성은 커질 것이라 본다. 문제는 좋은 아키텍처 감각이 전통적으로 작은 부분을 직접, 처음엔 서툴게 만들어 보는 경험에서 나온다는 점이다. 그가 만난 나쁜 아키텍트 대부분은 코딩을 못하거나 경험이 거의 없었다. AI에게 '쉬운' 코드를 맡겨 버리면 아키텍트가 될 직관을 어디서 기르겠는가. 그래서 다시, 코드는 직접 써야 한다.
경험 수준에 따라 다른 AI 활용법
LLM을 잘 쓰는 법은 경험에 따라 다르다. 좋은 코드가 무엇인지 아는 시니어는 유리한 위치에 있지만, 코딩을 아예 놓고 프롬프트만 던진 뒤 대기 중 '무한 스크롤'에 빠지는 '브레인 롯(brain rot)'을 조심해야 한다. 그로스 자신은 지원해야 할 전체 해법을 LLM에 맡기지 않고, 수작업 코딩 중 API와 선택지를 이해하는 보조로만 쓰며, 시스템의 API 설계는 절대 LLM에 맡기지 않는다고 한다. 주니어는 더 어렵다. 동료들이 '바이브 코딩'으로 빠르게 치고 나가는 사이 더 느리다는 비판을 감수하며 더 열심히 일해야 할 수도 있다. 속도를 이해보다 우선하는 회사 분위기를 당장 바꿀 수는 없으니 해고당하지 않을 만큼은 맞춰야 하지만, 그는 이것이 일시적 현상이며 결국 신중하고 깊이 이해한 코딩이 복잡성 폭발을 덜 겪는다는 점이 드러날 것이라 전망한다.
네 개의 F, 그리고 회사를 향한 당부
질문의 본질은 결국 괜찮은 일자리를 구할 수 있느냐다. 그로스는 현재 프로그래머 채용 시장이 나쁘다는 점을 인정하면서도, 이 시장이 호황과 불황을 오가는 순환적 성격을 지녔으며 지금의 침체는 영구적이지 않다고 본다. 구직 조언은 구체적이다. 온라인 채용 사이트는 복권이나 다름없으니 무료라 써볼 만하되 많은 시간을 들일 가치는 없고, 대신 '네 개의 F' — 가족(Family), 친구(Friends), 친구의 가족(Family of Friends) — 라는 인맥을 활용하라는 것이다. 100명이 넘는 회사라면 대개 개발 조직이 있다. 그는 코스트코 본사에서 일하는 부모를 둔 학생에게 "너는 엄청나게 운이 좋다"며, 꼭 프로그래머로 시작하지 않고 분석가 같은 역할로 들어가더라도 프로그래밍 능력을 얹으면 훌륭한 커리어가 열린다고 조언했다고 한다. 글을 맺으며 그는 회사들을 향해서도 한마디를 남긴다. 주니어에게 적어도 일부 코드는 직접 쓰게 하라. 그것이 회사 자신에게도 이득이다.