AI가 코드를 짜주는 시대에 프로그래밍을 커리어로 추천할 수 있는가? htmx 창시자이자 몬태나주립대 컴퓨터과학 교수인 Carson Gross가 이 질문에 “Yes, and…” 로 답합니다. 즉흥극에서 빌려온 이 표현처럼, 긍정하되 조건을 덧붙이는 구조입니다.

원문: Yes, and… — Carson Gross

Yes: 왜 여전히 배워야 하는가

Gross의 출발점은 명확합니다. 프로그래밍의 본질은 “코드를 타이핑하는 행위"가 아니라 컴퓨터로 문제를 풀고 복잡성을 제어하는 능력이라는 것. AI가 코드 생성을 대신해주더라도, 이 능력의 가치는 사라지지 않습니다.

그는 학생들에게 한 가지를 강하게 경고합니다: AI가 코드를 생성할 수 있더라도, 직접 작성해야 한다.

이유는 세 가지입니다.

  1. 코드를 쓰지 않으면 읽을 수도 없다. 읽기 능력은 쓰기 훈련에서 나옵니다.
  2. “마법사의 제자” 함정. 이해하지 못하는 시스템을 생성하면, 그 시스템이 문제를 일으켰을 때 손을 쓸 수 없습니다.
  3. 내장적 이해(Visceral Understanding). 실제로 코딩해본 경험에서만 나오는 직관이 있습니다.

Assembly 비유는 틀렸다

“코딩→프롬프팅"이 “어셈블리→고급언어” 전환과 같다는 주장이 있습니다. Gross는 이를 정면으로 반박합니다.

컴파일러는 결정론적이다. for나 if 같은 고수준 구문은 예측 가능한 기계어를 생성한다. LLM은 결정론적이지 않으며, 부적절한 접근법을 선택할 수 있다.

컴파일러는 우발적 복잡성(accidental complexity)을 제거했지만, LLM은 오히려 복잡성을 더할 수 있습니다. 추상화 수준이 올라간 게 아니라, 예측 불가능한 번역기를 끼워넣은 것에 가깝다는 진단입니다.

And: 무엇이 달라져야 하는가

“Yes” 이후의 조건부가 이 글의 핵심입니다. Gross는 코드 작성 행위 자체의 상대적 중요도는 낮아질 수 있음을 인정하면서, 대신 부상할 역량 네 가지를 짚습니다.

1. 커뮤니케이션

LLM과 인간 모두를 상대로 명확하게 사고하고 표현하는 능력. Gross는 많은 프로그래머가 이미 문학적 성향을 갖고 있다고 말하면서, 책을 읽고 글을 쓰라고 권합니다.

2. 비즈니스 이해

컴퓨터 프로그래밍은 문제 해결이고, 기업은 많은 문제를 가진다.

AI가 일부 프로그래머의 역할을 자동화하더라도, 도메인 지식을 가진 프로그래머의 가치는 오히려 올라갑니다. 그는 수업에서 한 학생의 부모가 Costco 본사에서 일한다는 사실을 듣고, 그것이 “극도로 운이 좋은” 상황이라고 말합니다. 대형 테크 기업이 아니더라도, 직원 100명 이상인 회사라면 어디든 개발팀이 있고, 그 안에서 비즈니스를 이해하는 프로그래머는 대체 불가능합니다.

3. 시스템 아키텍처

대규모 시스템을 효과적으로 조직하고 복잡성을 제어하는 능력. 전통적으로 이 역량은 작은 부분부터 직접 만들어보며 쌓아올리는 것이었습니다. 여기서 역설이 생깁니다:

나쁜 아키텍트 대부분이 좋은 코더가 아니었거나 코딩 경험이 부족했다.

AI에게 “단순한” 코드를 맡기면 효율적이지만, 그렇게만 하면 아키텍트가 될 직관을 영영 쌓지 못할 수 있습니다.

4. LLM을 제대로 쓰는 법

Gross 본인의 AI 활용법이 솔직합니다:

  • 기존 코드 분석 및 이슈 발견
  • 대규모 프로젝트 사고 정리
  • 정규표현식, CSS 같이 즐기지 않는 코드 생성
  • 데모·일회용 탐색 코드
  • 테스트 제안

반대로, 유지보수해야 하는 전체 솔루션이나 API 설계는 AI에 맡기지 않습니다. 그리고 경고합니다 — “Eternal Scroll”, 즉 AI가 생성한 코드를 끝없이 스크롤하며 읽기만 하다가 정작 프로그래밍을 멈추는 함정에 빠지지 말라고.

주니어에게는 더 엄격합니다. 주변 동료들이 AI로 빠르게 코드를 찍어내는 걸 보면서도, 직접 작성하는 훈련을 포기하지 말라고 합니다. 단기적으로는 느려 보이지만, 신중한 코딩과 AI 보조의 조합이 장기적으로 더 나은 복잡성 관리를 가져온다는 판단입니다.

생각

이 글에서 가장 인상적인 부분은 Assembly 비유에 대한 반박입니다. 컴파일러와 LLM의 차이를 “결정론 vs 비결정론"으로 자르는 건 단순하지만 정확합니다. 추상화 계층이 하나 올라간 것과, 예측 불가능한 번역기가 끼어든 것은 질적으로 다른 상황입니다.

아키텍처 역량에 대한 역설도 날카롭습니다. 아키텍트는 코딩 경험의 축적 위에서만 나오는데, AI가 코딩을 대체할수록 그 축적의 기회가 줄어듭니다. 이건 개인의 커리어 문제이기도 하지만, 산업 전체의 인재 파이프라인 문제이기도 합니다. Gross가 기업에게 “주니어가 적어도 일부 코드를 직접 작성하게 하라"고 호소하는 건 그래서입니다.

결국 이 글의 메시지는 균형에 있습니다. AI를 거부하라는 게 아니라, AI가 대체할 수 없는 것 — 복잡성에 대한 직관, 도메인 이해, 아키텍처 판단력 — 을 의도적으로 쌓아라는 것. “Yes, and…“는 AI 시대 프로그래머에게 꽤 좋은 태도인 것 같습니다.