AI 코딩 도구로 코드 생성 비용이 0에 수렴하는 지금, 정작 더 비싸진 건 ‘코드를 이해하는 비용’이었어요. htmx 창시자의 에세이를 직접 읽고 AI 시대 개발자 역량이 어디로 옮겨가는지, 개발자·비개발자·데이터 직무별로 정리했습니다.
AI 시대 개발자 역량, 코드를 잘 짜는 게 정말 경쟁력일까요?
안녕하세요! 혹시 요즘 이런 생각 해보신 적 있으세요? “내가 몇 년 동안 갈고닦은 코딩 실력이, AI가 30초 만에 뽑아내는 코드 앞에서 의미가 있을까?” 저는 솔직히 최근 들어 이 질문이 머릿속을 떠나지 않더라고요. AI에게 함수 하나 부탁하면 1분도 안 돼서 멀쩡하게 돌아가는 코드가 나오는 걸 보면, 묘하게 허탈하면서도 불안해지거든요. 😮
그러던 차에 GeekNews에서 htmx 창시자 Carson Gross의 ‘코드는 더 싸졌다(Code is Cheaper)’라는 에세이가 화제가 된 걸 봤어요. 커뮤니티에서도 “코딩이 애초에 문제가 아니었다”는 통념을 정면으로 반박한다며 반응이 뜨거웠는데요. 짧지만 핵심을 찌르는 글이라 직접 원문을 끝까지 다 읽고, 제 나름의 관점으로 정리해봤습니다.
⚡ 이 글의 핵심만 먼저 보기 (Key Takeaways)
- 코드 생성 비용은 폭락, 이해 비용은 폭등: AI가 사람보다 빠르게 코드를 찍어내면서 ‘아무도 이해 못 하는 코드’가 가장 큰 리스크가 됐어요.
- LLM ≠ 컴파일러: 컴파일러는 결정적이고 원본을 보존하지만, LLM은 비결정적이고 원본을 버리는 ‘범주가 다른 도구’입니다.
- 빼는 엔지니어(Subtractive Engineer): 코드를 더하는 사람보다 ‘제거하고 단순화하는’ 사람이 AI 시대의 핵심 역량으로 떠올랐어요.
- 복잡성은 여전히 최상위 포식자: 시스템 복잡성은 규모에 따라 기하급수적으로 증가하는데, LLM은 복잡성에 대한 두려움이 없는 다작 코더라 위험합니다.
- 직무 공통 핵심: 개발자·비개발자·데이터 직무 모두 ‘무엇을 만들지 결정하는 능력’으로 무게중심이 옮겨가고 있어요.
- 점진적 사용이 정답: 거대한 변경을 한 번에 생성하지 말고, 이해 가능한 단위로 쪼개 쓰는 게 안전합니다.
📌 목차
- 코드는 싸졌고, 이해는 비싸졌다 — 핵심 진단
- 개발자: 코딩보다 중요해진 설계·판단·빼기
- 비개발자: 누구나 코드를 쓰는 시대의 문해력·문제정의
- 데이터 직무: 파이프라인보다 통계적 사고·해석력
- 세 직군의 공통 정답: 무엇을 만들지 결정하는 힘
- 이런 분들께 적극 추천합니다
- 자주 묻는 질문 (FAQ)
1. 코드는 싸졌고, 이해는 비싸졌다 — 핵심 진단
에세이의 출발점은 명쾌해요. 지난 1년간 AI가 ‘꽤 괜찮은 품질의 코드를 매우 빠르게 대량으로’ 생성하면서, 코드를 만드는 비용 자체가 급격히 낮아졌다는 거예요. 여기까지는 누구나 공감하죠. 그런데 저자는 한 발 더 나아갑니다. “코딩은 애초에 문제가 아니었다”는 흔한 주장에 대해, 코딩 역시 분명히 문제의 일부였고, 그 부분이 AI로 크게 줄어든 것이라고 반박해요.
문제는 그다음입니다. 코드가 프로그래머의 손에서 힘겹게 나올 때는 만드는 과정에서 ‘이해’가 자연스럽게 따라왔는데요. AI가 대량으로 코드를 뱉어내면 그 코드에 대한 이해 자체가 처음부터 존재하지 않아요. 이해가 필요하면? 생성된 코드를 다시 ‘읽어서’ 확보해야 하는데, 통념상 남이 쓴 코드를 읽는 건 내 코드를 쓰는 것보다 더 어렵잖아요.
① Category Error — “컴파일러 출력도 이해 못 하잖아”라는 반론의 함정
AI 옹호론자들이 자주 하는 말이 있어요. “너 컴파일러가 만든 기계어도 이해 못 하면서 잘만 쓰잖아? LLM 코드도 똑같지.” 저자는 이걸 범주 오류(category error)라고 단호하게 규정합니다. 세 가지 결정적 차이가 있거든요. 컴파일러는 결정적이지만 LLM은 설계상 비결정적이고, 컴파일러는 원본 소스를 보존하지만 LLM 워크플로는 대개 원본을 버리며, 컴파일러 출력은 기계어라는 좁은 도메인에 한정되지만 LLM 출력은 소프트웨어 전체로 무한정 넓어요.
💡 실제 활용 시나리오 예시:
미션 크리티컬한 결제 모듈을 AI로 리팩토링한 팀이 있다고 해볼게요. “컴파일러 출력처럼 믿고 쓰면 되겠지” 하고 1만 줄 변경을 한 번에 머지했다가, 한 달 뒤 환율 처리 버그가 터졌을 때 아무도 그 코드를 설명하지 못해 롤백에만 사흘이 걸렸어요. 결정적이지 않은 출력은 ‘검증된 블랙박스’가 될 수 없다는 걸 비싸게 배운 거죠.
2. 개발자: 코딩보다 중요해진 설계·판단·빼기
이제 본론이에요. 코드 짜는 비용이 0에 수렴한다면, AI 시대 개발자 역량의 무게중심은 어디로 옮겨갈까요? 에세이가 제시하는 답이 정말 인상적이었는데, 바로 ‘빼는 엔지니어(Subtractive Engineer)’입니다.
① The Subtractive Engineer — 더하는 사람이 아니라 빼는 사람
이 엔지니어는 “아니오”라고 말할 줄 알아요. LLM 출력을 면밀히 검토하고, 단순화를 제안하며, 단호하게 통제력을 유지합니다. 가장 흥미로운 지점은 자부심의 원천이 바뀐다는 거예요. 내가 ‘만든’ 코드가 아니라, 시스템에서 제거하거나 애초에 진입을 막은 코드에 자부심을 둡니다. 저자는 이 태도를 건축가(builder)보다 조각가(sculptor)에 가깝다고 표현했는데, 돌을 깎아내며 형상을 드러내는 이미지가 딱 맞더라고요.
② The Sorcerer’s Apprentice — 제자가 아니라 마법사가 되어라
디즈니 판타지아의 ‘마법사의 제자’ 장면 기억하시나요? 청소가 귀찮았던 제자가 빗자루에 마법을 걸자, 빗자루가 점점 격렬하게 물을 길어 나르며 통제 불능에 빠지죠. 결국 마법사가 돌아와 사태를 수습하고 제자를 꾸짖어요. 저자는 이걸 AI 시대의 완벽한 비유로 봅니다. 교훈은 ‘마법사가 되어야 한다’는 것, 그리고 마법사는 자기가 부리는 마법(코드)을 이해해야 한다는 거예요.
③ Incremental Use — 점진적 사용으로 이해 속도를 지켜라
LLM은 누구도 따라잡지 못할 속도로 코드를 생산할 수 있어요. 그래서 이해 속도를 추월하는 위험이 생깁니다. 해법은 의외로 단순해요. 거대한 변경 목록을 한꺼번에 생성하지 말고, 이해 가능한 단위로 쪼개서 점진적으로 쓰는 거죠. 기계적 리팩토링에는 크게 풀어줘도 괜찮지만, 코드베이스에 새로운 의미(semantics)를 도입할 때는 극히 위험하다는 게 핵심이에요.
💡 실제 활용 시나리오 예시:
실무에서 저는 AI에게 PR 단위를 작게 끊어달라고 요청하는 게 큰 차이를 만든다고 느꼈어요. “이 기능 전체를 한 번에 구현해”가 아니라 “가장 작은 변경부터, 지울 수 있는 건 뭔지, 이 추상화가 제값을 하는지”를 매 단계 물으면, 200줄짜리 리뷰 가능한 PR이 나오거든요. 커뮤니티에서도 AGENTS.md나 CLAUDE.md에 이런 원칙을 박아두면 처음부터 단순한 코드를 유도할 수 있다는 얘기가 많았어요.
3. 비개발자: 누구나 코드를 쓰는 시대의 문해력·문제정의
여기서부터는 에세이를 제 관점으로 확장한 부분이에요. 코드가 싸졌다는 건 개발자만의 이야기가 아니거든요. 이제 기획자, 마케터, PM도 AI에게 “이런 자동화 스크립트 만들어줘”라고 요청하면 결과물이 나와요. 즉 누구나 코드를 ‘생성’할 수 있는 시대가 된 거죠. 그렇다면 비개발자에게 필요한 역량은 뭘까요?
1) Problem Definition — 무엇이 진짜 문제인지 정의하는 능력
AI는 시키는 걸 만들어요. 하지만 ‘무엇을 시킬지’는 사람의 몫입니다. 좋은 프로그래머는 단순한 요청을 던지는 관리자보다 훨씬 많은 맥락을 동원하고 대안을 제시하는데, 현재 LLM은 ‘올바른 질문을 던지는 데’ 아직 능숙하지 않아요. 그래서 비개발자에게도 문제를 정확히 정의하고 맥락을 풍부하게 전달하는 능력이 핵심 경쟁력이 됩니다.
2) Code Literacy — 결과물을 읽고 판단하는 최소한의 문해력
코드를 직접 쓸 필요는 없어요. 하지만 AI가 만들어준 결과물이 위험한지, 과한지, 신뢰할 만한지를 가늠하는 ‘코드 문해력’은 필요해요. 흥미롭게도 익숙하지 않은 코드를 분석하는 데는 AI가 굉장히 뛰어나거든요. AI에게 “이 코드를 부분별로 설명하는 문서를 만들어줘”라고 하면, 비개발자도 무슨 일이 벌어지는지 파악할 수 있어요. 다만 관례에서 벗어난 부분에서 AI가 그럴듯하게 지어내는(거짓말하는) 경우가 있어 검증 습관이 중요합니다.
💡 실제 활용 시나리오 예시:
마케팅팀 담당자가 AI로 광고 데이터 집계 스크립트를 만들었다고 해볼게요. 코드는 못 짜지만 “이 숫자가 중복 집계되는 거 아니야?”라는 질문을 던질 수 있다면, 잘못된 리포트로 예산을 날리는 사고를 막을 수 있어요. 생성은 AI가, ‘이게 맞는 문제를 푸는가’의 판단은 사람이 하는 분업이죠.
4. 데이터 직무: 파이프라인보다 통계적 사고·해석력
데이터 분석가, 엔지니어, 과학자도 이 흐름에서 자유롭지 않아요. 예전엔 Pandas 코드를 빠르게 짜고 SQL 쿼리를 능숙하게 다루는 게 큰 무기였는데, 이제 그 부분은 AI가 상당히 잘해주거든요. 그렇다면 데이터 직무의 AI 시대 개발자 역량은 어디로 향할까요?
① Statistical Reasoning — 통계적 사고와 복잡성에 대한 두려움
에세이의 ‘복잡성은 여전히 나쁘다(Complexity: Still Bad)’ 섹션이 데이터 직무에 그대로 적용돼요. 저자는 인간이 기하급수·지수 곡선을 잘 파악하지 못한다고 지적하는데, 이게 데이터 분석에서 치명적이에요. LLM은 복잡성에 대한 두려움이 없는 다작 코더라, 시키면 불필요한 피처를 끝없이 추가하고 과적합된 모델을 만들어내거든요. 여기서 “이 변수가 정말 필요한가, 이 복잡도가 제값을 하는가”를 판단하는 통계적 직관이 사람의 핵심 역량으로 남습니다.
② Interpretation & Domain Knowledge — 해석력과 도메인 지식
AI가 분석 코드를 짜줘도, 그 결과가 비즈니스적으로 무엇을 의미하는지는 도메인 지식이 있는 사람만 해석할 수 있어요. 숫자는 AI가 뽑지만, “이 상관관계가 인과인가, 교란변수가 있는가”를 묻는 건 사람이에요. 데이터 직무에서 코딩 비중이 줄어들수록, 오히려 도메인 맥락 위에서 해석하는 능력의 가치가 올라갑니다.
💡 실제 활용 시나리오 예시:
이탈 예측 모델을 AI로 빠르게 만든 데이터 과학자가 있다고 해볼게요. 정확도 92%가 나와서 좋아했는데, 알고 보니 ‘해지 신청 클릭’ 피처가 들어가 있어 사실상 정답을 미리 알려준 데이터 누수였어요. 코드는 완벽했지만 ‘이 피처가 예측 시점에 존재하는가’라는 도메인 판단이 빠졌던 거죠. 이게 바로 사람이 지켜야 할 자리입니다.
5. 세 직군의 공통 정답: 무엇을 만들지 결정하는 힘
개발자, 비개발자, 데이터 직무를 쭉 훑어보니 하나의 공통점이 보이지 않나요? 코드를 ‘어떻게 짜느냐’는 점점 AI의 몫이 되고, ‘무엇을 만들지, 무엇을 만들지 말지’를 결정하는 능력이 세 직군 모두의 핵심으로 수렴하더라고요.
| 직군 | 예전 핵심 역량 | AI 시대 핵심 역량 |
|---|---|---|
| 개발자 | 빠르고 정확한 코딩 | 설계·리뷰·빼는 판단(Subtractive) |
| 비개발자 | 도구 사용·실행 | 문제 정의·코드 문해력 |
| 데이터 직무 | 파이프라인·쿼리 작성 | 통계적 사고·해석·도메인 지식 |
저자의 표현을 빌리면, “코드는 저렴해졌고, 복잡성은 여전히 최상위 포식자(apex predator)”라는 이중 현실을 인정하는 게 출발점이에요. AI가 코드를 아무리 싸게 찍어내도, 복잡성을 다스리고 무엇을 만들지 결정하는 건 여전히 인간의 기예(craft)로 남는다는 거죠. 이 부분에서 저는 살짝 안도감이 들기도 했어요. 😊
물론 커뮤니티에서는 “LLM이 복잡성을 절대 존중 못 한다”는 표현은 과장이라는 반론도 있었어요. 적절히 안내하면 LLM도 읽기 쉽고 계층이 잘 나뉜 코드를 만들 수 있다는 거죠. 저도 여기엔 동의해요. 핵심은 AI의 한계가 아니라, 그 압력을 어떻게 설계하느냐가 사람의 역량이라는 점이에요. 이런 ‘AI 시대의 차별화 능력’에 대해 더 깊이 보고 싶다면 AI 빌더 시대의 방향·검수·장인정신 정리도 함께 읽어보시길 추천해요.
6. 이런 분들께 적극 추천합니다
- AI 코딩 도구를 쓰면서 “내 커리어가 어디로 가는 거지?” 불안한 주니어·미드레벨 개발자
- 바이브 코딩으로 빠르게 프로토타입을 만들지만 유지보수가 걱정되는 1인 개발자·창업자
- AI로 자동화 스크립트를 만들어 쓰는 기획자·마케터·PM 등 비개발 직군
- AI가 짜준 분석 코드의 결과를 어디까지 믿어야 할지 고민인 데이터 분석가·과학자
- 팀에 AI 코딩 도구를 도입하며 코드 품질·복잡성 관리 기준을 세우려는 테크리드·EM
- ‘코드 생성’이 아니라 ‘시스템 사고’로 무게중심을 옮기고 싶은 모든 실무자
7. 자주 묻는 질문 (FAQ)
Q. 그럼 이제 코딩 실력은 안 키워도 되나요?
A. 전혀 아니에요. 오히려 반대예요. 코드를 ‘읽고 이해하고 판단하는’ 능력은 더 중요해졌거든요. AI가 만든 코드를 검토하고, 위험한 부분을 잡아내고, 단순화를 제안하려면 탄탄한 코딩 기본기가 필수입니다. 달라진 건 ‘빠르게 타이핑하는 능력’의 가치가 줄었다는 것뿐이에요.
Q. ‘빼는 엔지니어’는 결국 코드를 적게 쓰자는 건가요?
A. 단순히 양을 줄이자는 게 아니라, 불필요한 복잡성과 레이어를 제거하는 판단력을 갖추자는 거예요. “이 추상화가 제값을 하는가”, “이 컴포넌트를 지워도 되는가”를 끊임없이 묻는 태도죠. 시스템 설계 수준에서는 여전히 ‘잘 조합하는 빌더’의 역량도 필요해요. 두 태도를 상황에 맞게 쓰는 게 핵심입니다.
Q. 비개발자도 정말 이 흐름을 신경 써야 하나요?
A. 네, 오히려 기회예요. 코드 생성 장벽이 낮아진 만큼, ‘무엇을 만들지 정의하고 결과를 판단하는’ 비개발자의 강점이 빛을 발할 수 있거든요. 코드를 직접 못 짜도, 문제를 정확히 정의하고 AI 결과물을 검증하는 최소한의 문해력만 갖추면 충분히 경쟁력이 됩니다.
✍️ 글을 마치며
결국 이 에세이가 던지는 메시지는 명확해요. 코드는 싸졌지만 이해와 복잡성 관리는 여전히 비싸고, 그게 사람의 자리라는 거예요. 개발자는 빼는 판단으로, 비개발자는 문제 정의로, 데이터 직무는 해석력으로 — 세 직군 모두 ‘무엇을 만들지 결정하는 힘’으로 무게중심이 옮겨가고 있습니다.
저는 당장 AI에게 일을 시킬 때 “가장 작은 변경으로, 지울 수 있는 건 없는지”를 먼저 묻는 습관부터 들여볼 것 같아요. 거대한 변경을 한 번에 받기보다 이해 가능한 단위로 끊는 것만으로도, 마법사의 제자가 아니라 마법사 쪽에 설 수 있다고 느꼈거든요.
여러분은 어떤 부분이 가장 인상적이셨나요? 댓글로 자유롭게 의견 남겨주세요! 😊