그래도 프로그래밍을 배워야 합니다

AI 요약

Montana State University에서 컴퓨터과학을 가르치는 Carson Gross는 AI 시대에도 프로그래머를 진로로 삼아도 되는지 묻는 학생과 가족에게 “그렇습니다. 그리고…”라고 답합니다. 프로그래밍은 컴퓨터로 문제를 풀고, 그 과정에서 복잡성을 제어하는 일입니다. AI 도구가 코드를 작성해도 이 두 능력의 가치는 사라지지 않는다는 주장입니다.

초급 개발자는 코드를 직접 써야 합니다

Gross는 AI가 초급 개발자에게 특히 위험할 수 있다고 봅니다. 과제를 AI에 맡기면 코드를 만들며 시행착오를 겪고, 코드에 대한 감각을 기를 기회를 잃습니다. 코드를 직접 쓰지 않으면 결과물을 효과적으로 읽기도 어렵습니다. 이해하지 못하는 시스템을 만들어 통제력을 잃는 ‘마법사의 제자(The Sorcerer’s Apprentice)’ 상황을 피하려면, 읽고 쓰는 경험을 쌓아야 한다고 말합니다.

고급 언어에서 AI 생성 코드로 옮겨가는 일을 어셈블리에서 고급 언어로 넘어간 것과 같다고 보는 비유에도 동의하지 않습니다. 컴파일러는 대체로 결정적으로 동작하며, 특정 언어 구조가 어떤 기계어로 바뀌는지 어느 정도 예측할 수 있습니다. 반면 LLM에 같은 프롬프트를 줘도 결과를 같은 수준으로 예측하기 어렵습니다. 고급 언어는 어셈블리에서 우발적 복잡성을 덜어냈지만, LLM 생성 코드는 부적절한 접근이나 지름길을 택해 복잡성을 되레 늘릴 수 있습니다. 코드를 읽고 판단하는 능력 없이는 그 차이를 알아채기 어렵다는 설명입니다.

AI는 코드 생성기보다 조교로 활용합니다

AI를 개념과 기법을 이해하는 파트너로 쓰면 학습에 큰 도움을 줄 수 있습니다. 프로그래밍을 배우다 막히는 이유가 문제 해결 능력 부족이 아니라 도구 체인이나 개발 환경의 우발적 복잡성인 경우도 있습니다. AI는 이런 장애물을 넘도록 도와 학습에 쓸 시간을 확보해 줍니다. Gross는 학생들이 AI를 코드 생성기가 아니라 좋은 조교처럼 쓰도록 설정한 AGENTS.md 파일도 공개했다고 설명합니다.

AI가 코드를 대신 쓰는 비중이 커지면, 글쓰기와 명확한 의사소통, 사업과 실제 업무에 대한 이해, 소프트웨어 아키텍처의 중요성이 커질 수 있습니다. 코드를 많이 쓰는 능력의 상대적 가치는 낮아져도, 시스템을 조직하고 복잡성을 제어하는 능력은 필요합니다. 특히 아키텍처 감각은 작은 부분을 만들고 실패하며 쌓은 경험에서 나오므로, 초급 개발자가 ‘쉬운 코드’를 AI에 전부 맡기면 설계에 필요한 직관도 키우기 어렵다고 봅니다.

경력에 따라 AI 활용법을 달리합니다

경력자는 좋은 코드와 대규모 시스템을 이미 경험했으므로 LLM을 더 효과적으로 쓸 기반이 있습니다. Gross는 기존 코드 분석과 불일치 탐색, 큰 프로젝트의 생각 정리, 작은 코드 조각 생성, 정규식이나 CSS처럼 직접 작성하기 꺼리는 코드 생성, 폐기할 탐색용 데모, 테스트 제안 등에 LLM을 활용합니다. 반면 유지보수할 전체 해법을 맡기거나 자신이 만드는 시스템의 API 설계를 맡기지는 않습니다. 프롬프트를 던진 뒤 결과를 기다리며 화면만 계속 넘기는 ‘영원한 스크롤(The Eternal Scroll)’에 빠져 프로그래밍을 멈추는 일도 경계합니다.

초급자는 AI가 제시한 코드를 그대로 받아들이고 싶은 유혹을 이겨내야 합니다. AI는 코드베이스 구조, API와 기법, 빌드 시스템과 언어를 이해하는 데 도움을 줄 수 있지만 직접 코드를 작성해야 합니다. 회사도 초급 개발자에게 적어도 일부 코드를 작성할 기회를 줘야 한다고 주장합니다. 속도만 좇는 바이브 코딩은 복잡성을 빠르게 키울 수 있으며, Gross는 기업들이 이를 깨닫고 더 신중한 AI 보조 개발을 택할 것으로 예상합니다.

구직은 주변 관계와 업무 도메인도 살핍니다

Gross는 현재 프로그래머 취업 시장이 어렵지만, 업황은 호황과 불황을 반복해 왔으므로 지금 상황이 영구적이라고 보지는 않습니다. 특히 초급자에게 온라인 구직 사이트는 당첨 가능성이 낮은 복권에 가깝다고 말합니다. 대신 가족, 친구, 친구의 가족을 뜻하는 ‘네 가지 F’ 관계를 활용해 아는 사람이 있는 회사에 지원하라고 조언합니다. 꼭 대형 기술 기업일 필요는 없습니다. 상당한 규모의 회사에는 컴퓨터로 풀 문제가 있고 개발 조직도 있습니다. 부모가 Costco 본사에서 일하는 한 학생에게는 분석가 같은 직무로 시작해 프로그래밍 능력을 보태는 길도 좋은 기회가 될 수 있다고 설명합니다.

Hacker News 반응

• @samstress — 저는 “아니요, 하지만…”이 더 나은 답이라고 생각합니다. 프로그래밍을 배워 전문가 수준의 소프트웨어를 만들려면 상당한 시간을 들여야 합니다. 지난 12개월 동안 AI 코딩 능력이 향상된 속도를 앞으로도 이어진다고 보면, 그 시간을 쓰는 선택은 좋지 않습니다. 대신 글에서 말하듯 현실 세계와 AI 코드 생성을 연결하는 사람이 되는 법을 배우세요. 기술 혜택을 충분히 누리지 못한 건설, 광업, 폐기물 관리, 석유·가스, 제조, 물류, 정부 같은 산업을 알아보세요. 그런 산업과 AI의 가치 창출 능력을 잇는 역할을 맡으세요.
  • @notpushkin — 요점을 놓쳤습니다. 코드를 이해하지 못하면 AI가 만든 코드를 믿을 만하게 활용할 수 없습니다.
• @smcg — 교수가 오늘 취업 방법으로 결국 네트워킹을 권한다니 씁쓸합니다. 업계에 아는 가족이나 친구가 없는 사람들을 생각하면 안타깝습니다.
  • @trentnix — 네트워킹을 업계에서 일하는 가족이나 친구에게만 한정한다면 시야가 좁습니다. 동아리, 학회, 온라인 커뮤니티, 직접 만들어 배포하고 실제로 쓸 만한 것을 내놓는 일도 효과적인 네트워킹입니다. 취업 시장은 바닥이고, 능력과 윤리를 평가하기보다 음악 의자 뺏기처럼 느껴집니다. 예전 경로는 좁아지거나 사라지고 있지만, 이제는 혼자서도 큰 것을 만들 도구가 있습니다.
  • @chaps — 오히려 당신 쪽 시야가 훨씬 좁습니다. 새 도시로 이사한 사람이나 출소한 사람을 생각해 보세요. 당신이 말한 네트워킹을 쌓는 데는 시간이 듭니다. 사람은 먹고 살아야 하고 네트워킹으로는 배를 채울 수 없습니다.
• @tengbretson — 코드를 쓰는 능력과 읽는 능력은 서로 관련은 있지만, 따로 연습하고 다듬어야 하는 별개의 기술일 수도 있습니다. 학교를 졸업할 때 코드를 쓰는 능력은 크게 늘었지만 읽는 능력은 거의 나아지지 않았다고 느꼈습니다. 10년 넘게 일한 뒤에도 코드를 읽고 내면화하는 능력은 기대만큼 늘지 않았습니다. 직장에서 다른 사람이 쓴 코드를 읽어야 했을 때 비로소 읽는 법을 익히기 시작한 것 같습니다. 쓰지 않고 읽는 법을 배울 수는 있을지도 모릅니다. 반대로 읽지 않고 쓰는 법을 배우는 건 분명 가능한 것처럼 느껴집니다.
  • @skydhash — 좋은 코드베이스에는 문제와 해결책을 이루는 자료구조·알고리즘이란 개념 모델이 있습니다. 문법과 구현의 여러 추상화 층 뒤에 모델이 가려져 있을 뿐입니다. 리스트와 트리 같은 자료구조, 스케줄링과 동시성, 파일·프로세스·네트워킹 같은 플랫폼 개념을 알면 구현 세부 사항과 핵심 모델을 구분하기 쉬워집니다. 예를 들어 장치 탐색이 트리라는 점을 알면 트리 순회와 실제 장치 설정 코드를 나눠 읽을 수 있습니다.
  • @rspeele — 학교에서는 기껏해야 수천 줄 코드를 직접 썼고, 다른 사람이 만든 큰 코드베이스를 접한 경험은 드물었습니다. 첫 직장에서는 익숙하지 않은 언어와 수십만 줄 규모의 남이 쓴 코드베이스를 마주했습니다. 다른 사람의 코드를 읽고 탐색하는 능력은 그 뒤 십여 년 동안 길렀습니다. 그런데 AI는 거대한 코드베이스에서 미묘한 버그를 찾아내는 등 저보다 코드를 더 잘 읽기도 합니다. 이제는 AI에게 “Foo의 승인이 취소되면 어떻게 처리하나요?”처럼 구체적으로 물어보는 편이 코드를 한 줄씩 읽는 것보다 더 많은 도움을 줍니다. GPS만으로 꽤 멀리 갈 수 있는 것처럼, 코드 읽기 능력은 위축될 수 있습니다.
• @johsole — LLM이 코딩을 잘할수록 시스템을 유지하고 발전시키는 데 필요한 개발자 수가 줄어들 것이라고 봅니다. 우리 회사에서는 이미 새 기능 개발 속도가 약 30% 늘었고, 같은 개발자 수로 훨씬 많은 일을 합니다. 개발자들이 코드가 맞는지 확인하지 않고 믿는 모습도 봅니다. 아이들에게 프로그래밍을 권하기보다 코딩을 활용할 기업가가 되라고 하겠습니다.
  • @simonw — 컴퓨터와 소프트웨어가 어떻게 작동하는지 아는 사람이 새로운 아이디어를 더 잘 만들어낼 것이라고 생각합니다.
  • @bluefirebrand — 제 경험상 새 아이디어는 소프트웨어와 무관한 일을 하는 사람이 주로 냅니다. 광산의 혁신적인 채굴법이나 로봇 아이디어는 광산에서 일하는 사람이 떠올릴 수 있습니다. 예전에는 소프트웨어 엔지니어를 찾아 아이디어를 검증했지만, 이제는 AI를 찾게 될지도 모릅니다.
  • @simonw — 가장 좋은 아이디어는 도메인 지식과 무엇이 가능한지 아는 능력을 함께 갖춘 사람에게서 나온다고 봅니다. 지금 대학에 간다면 컴퓨터과학과 다른 전공을 복수전공하고 싶습니다.
• @layer8 — 컴파일러와 LLM의 차이는 단순히 결정성에 있지 않습니다. 소스 코드의 변화가 컴파일된 프로그램의 어떤 동작을 어떻게 바꿀지 형식적으로 추론할 수 있다는 점이 중요합니다. 난수원을 고정하면 AI도 결정적으로 만들 수 있겠지만, 프롬프트에 단어를 추가하거나 빼면 출력이 어떻게 바뀔지 추론할 수는 없습니다. 알아보려면 모델을 실행해야 합니다. 프로그래밍 언어는 그 동작을 추론할 수 있도록 설계됐지만, LLM은 매번 실험해야 합니다.
  • @glimshe — 바이브 코딩과 컴파일을 비교하는 건 중요한 지적이지만, LLM을 그렇게 쓸 필요는 없습니다. 코딩할 때는 달성할 목표를 구상하고, 그 구상을 코드로 옮긴 뒤, 결과를 검토하고 커밋합니다. LLM을 쓰면 앞뒤의 구상과 검토는 사람이 맡고 코드 입력만 모델에 맡길 수 있습니다. 출력을 이해하고 자기 모델에 맞게 고치면, 비결정성은 검토에 필요한 작업량만 바꿉니다.
• @sajithdilshan — 몇 년 뒤에는 사람이 소프트웨어를 만들 때 쓰는 언어가 자연어가 될 것이라고 생각합니다. LLM이 고급 프로그래밍 언어를 추상화하고, 지금 우리가 어셈블리어를 직접 쓰지 않는 것처럼 바뀔 수 있습니다. 그렇더라도 네트워킹과 암호화·암호학 같은 컴퓨터과학과 공학의 이론 및 개념은 배울 가치가 있습니다.
• @ibejoeb — 정답은 아키텍처입니다. 현재 모델은 구현을 잘하고 엣지 케이스를 찾아 계획하는 능력도 상당합니다. 하지만 성공적인 소프트웨어 프로젝트에는 여전히 적절한 구성 요소를 고르는 일이 필요합니다. 앞으로 모델의 설계 판단도 나아지겠지만, 지금 실제 부하를 처리하는 시스템에는 사람 설계자가 필요합니다. 좋은 소프트웨어가 어떤 모습인지 아는 사람은 에이전트를 활용하지만, 그런 지식이 없는 사람은 아직 고품질 시스템을 만들기 어렵습니다.
• @recursivedoubts — 저는 컴퓨터과학 전공을 고민하는 학생들을 돕고 싶어 이 글을 썼습니다. 제 아들도 대학에서 컴퓨터과학을 공부하기 시작했습니다. 최근 AI 발전에 놀랐지만 글에서 말한 주장을 여전히 믿습니다. 제가 본 가장 효과적인 바이브 코더들은 이미 뛰어난 개발자입니다. 직접 작성하는 코드가 줄어들더라도 코드와 기술 시스템의 작동 원리를 아는 능력은 계속 가치가 있고, 더 중요해질 수도 있습니다.
  • @Imustaskforhelp — 저도 대학에서 컴퓨터과학을 막 공부하기 시작한 학생으로서 이 글을 써 주셔서 감사합니다. 컴퓨터과학과 대학 생활, 그리고 어쩌면 실존적 위기까지 걱정하며 한동안 불안에 빠졌습니다. 좋은 대학 생활을 보내고 좋은 친구와 인연을 만들어 아드님의 미래에 도움이 되기를 바랍니다.

원문: htmx Essays / 번역·요약: Trawling