요약
AI 시대에도 프로그래머는 좋은 진로이며, 코드를 직접 쓰면서 다른 역량도 길러야 합니다.
htmx를 만든 카슨 그로스가 쓴 글입니다. 몬태나 주립대학교에서 컴퓨터과학을 가르치는 그는 AI 때문에 진로를 걱정하는 학생들에게 "네"라고 답한 뒤, 무엇을 더 해야 하는지를 덧붙였습니다.
왜 중요한가
- 신입이 AI로 코딩을 건너뛰면 코드를 읽고 검토하는 능력과 설계 감각을 함께 잃는다는 경고입니다.
- 회사에도 당장의 속도보다 신입이 코드를 직접 쓰게 하는 편이 결국 이득이라고 말합니다.
핵심 내용
- LLM(대규모 언어 모델)의 출력은 컴파일러와 달리 예측할 수 없어서 고급 언어의 등장과 같은 변화가 아니라고 봤습니다.
- 생성된 코드는 불필요한 복잡도를 더하기 쉬우므로, 이를 검토하려면 직접 써 본 경험이 필요하다고 했습니다.
- AI는 코드 생성기보다 막힌 개념을 풀어 주는 조교로 쓰라며, 에이전트를 튜터로 만드는 AGENTS.md 설정을 공개했습니다.
- 손으로 코드를 쓰는 일의 비중은 줄고 글쓰기와 소통, 업무 이해, 아키텍처 역량이 중요해진다고 했습니다.
- 취업 시장 부진은 일시적이며, 구인 게시판보다 가족·친구 인맥과 빅테크 밖의 일반 기업을 노리라고 조언했습니다.
HN 반응
- 손으로 짜던 페르시아 양탄자가 기계 생산에 밀려 시장이 거의 사라졌다는 반론에, 소규모 기업용 맞춤 도구로 돈을 번다는 경험담이 맞섰습니다.
- 소프트웨어 개발은 양탄자를 짜기보다 직조기를 만드는 일에 가까워서 손으로 원리를 익혀야 한다는 보충 의견도 나왔습니다.
저는 오랫동안 제 일을 갈고닦았고 그 과정에서 배운 것도 정말 많습니다. 그래서 이 주장을 믿고 싶고, 진심으로 그렇습니다. 하지만 이걸 산업화 이전 시대의 수많은 직업에 대입해 보면 확신이 서지 않습니다.
"스승님, 저는 이제도 아름다운 페르시아 양탄자를 손으로 짜는 법을 배워야 할까요?"
"그렇다. 그리고 말이다... 기계로 찍어낸 양탄자를 본 적이 있느냐? 하나같이 똑같고 품질은 형편없지 않더냐! 좋은 양탄자와 나쁜 양탄자를 가릴 줄도 모르면서 그 새 기계를 어떻게 다루겠느냐? 손으로 짜는 법을 배우면 알맞은 실을 고르는 법, 시장 아래쪽 상인과 제값을 흥정하는 법, 기술을 물려줄 좋은 제자를 고르는 법도 함께 배우게 된다. 이 모든 것은 언제까지나 쓸모가 있을 것이다!"
네, 지금도 아름다운 양탄자를 만들어 비싼 값에 파는 장인들은 있습니다. 하지만 요즘 사람 대부분은 몇 년마다 갈아치울 수 있는 싸구려 이케아 제품에 발을 올려놓는 것으로 만족하니, 그 시장은 거의 없다시피 쪼그라들었습니다.
하지만 지금은 거꾸로 된 상황이기도 합니다. 소프트웨어 대부분은 모두에게 똑같이 맞추는 획일적인 해법입니다. 작은 SaaS는 아마 다들 아주 만족하는 고객 몇몇으로 시작하겠지만, 규모를 키운다는 건 모두를 만족시킬 수 없다는 뜻이라서 만족은 불만으로 바뀝니다. 빅테크가 내놓는 소프트웨어도 상당수가 획일적이라 모두가 완벽히 만족하지는 못합니다.
맞춤형 소프트웨어를 만드는 비용이 꾸준히 내려가고 품질도 충분히 쓸 만해진다면, 가까운 미래는 훨씬 더 작은 고객층이나 소비자 집단을 위한 맞춤형 솔루션을 훨씬 더 많이 만드는 쪽이 될 겁니다.
그래도 기술을 이해하고, 시스템이 말한 대로 안전하고 효율적으로 동작하는지 검증할 사람은 여전히 필요하다는 점을 염두에 두세요. 기술 비전문가인 바이브 코더는 누구나 언젠가 깨닫게 됩니다. 자기가 가진 문제를 프롬프트로 다 풀 수는 있을지 몰라도 그것 역시 상당한 노력이 들고, 전문가가 이미 습관에서 걷어낸 온갖 실수를 고스란히 되풀이한다는 사실을요. 바이브 코딩으로 만든 프로젝트 중 상당수는 제 무게를 못 이겨 무너질 텐데, 기술을 염두에 두고 전략을 다시 짜는 일도 전문적인 노력이 필요합니다.
LLM이 언제나 완벽하고 질 좋은 코드를 만들어 낸다 해도, "완벽한" 프롬프트를 지시하는 건 여전히 사람의 문제입니다. LLM은 마음을 읽지 못하고 환경적·사회적 상황을 온전히 이해하지도 못합니다. 그런 것을 이해해서 솔루션에 녹여 내는 일 역시 사람의 문제입니다.
이 모든 일에는 여전히 깊은 기술 지식이 필요하고, 보안이 위협받는 지금은 더욱 그렇습니다.
그건 조건이 "규모를 키우지 말 것"이기 때문입니다.
억만장자가 될 일은 없을 테니, 기업을 위해 틈새 제품을 잘 만들어 주는 것으로 만족하세요. 사용자 80만 명은 필요 없습니다. 월 2,000달러를 내는 소규모 업체 여덟 곳이면 됩니다.
이제 직접 만들 수 있고, 아마 자기네 필요에 더 잘 맞게 만들 수 있는 걸 두고 월 2,000달러를 낼 사람은 없습니다.
회사의 핵심 업무 바깥이라면 충분히 낼 수 있습니다. 회사들은 늘 그렇게 합니다. 잘하는 일에 집중하려고 외주나 하청을 주잖아요.
물론 이제는 (비교적) 거의 공짜에 가까운 비용으로 돌아가는 소프트웨어를 만들 수 있을지도 모릅니다. 하지만 그걸 만들 추가 인력이라는 한계비용이 여전히 듭니다. 게다가 유지보수도 해야 하고, 바뀌는 내부 요구에 맞춰 업그레이드도 해야 하고, 보안도 챙겨야 하고, 제대로 동작한다고 믿을 수 있어야 합니다.
물론 그 모든 비용이 내려가기는 했지만, 여전히 일이 많이 듭니다. 차라리 다른 회사에 맡기고 감당할 만한 값을 치르는 편이 낫죠. 그리고 B2B 계약에서는 회사들이 큰돈을 내는 데도 기꺼이 응하는 경우가 많습니다.
한 번 더 강조하자면, 클라우드를 떠나면 비용이 얼마나 절감되는지 보세요. 그래도 회사들은 여전히 선뜻 클라우드에 구축합니다. FOSS도 수십 년 전부터 있었지만 회사들은 여전히 독점 제품에 돈을 냅니다. 직접 만들지 사 올지는 비용 말고도 따져 볼 축이 많습니다.
ㅋㅋ 저는 지금 바로 이걸로 먹고살고 있는데요.
회사가 원하지도 않는 기능이 잔뜩 붙은 소프트웨어 제품군에 연간 7만~10만 달러를 쓰고 있다면, 맞춤 도구를 연간 2만 4천 달러에 만들어 주겠다는 사람에게는 당연히 돈을 냅니다.
말 그대로 지금 하고 있는 일입니다.
고객은 어떻게 구하세요? 꽤 괜찮은 일 같은데요.
제가 너무 복잡하게 생각하는 걸 수도 있겠네요. 예전에도 비교적 단순한 워드프레스 사이트에 엄청난 돈을 쓰는 회사들이 있었으니까요(지금도 아마 있을 거고요).
지금까지는 전부 제가 속속들이 아는 업계에서 입소문으로 구했습니다. 그러니 사람마다 다를 수 있겠지만, 저는 "제가 뭘 하나 만들어 드릴게요, 마음에 드시면 어떻게 값을 치를지 얘기해 봐요"라고 말하면서 시작했고, 그러고 나서 그냥 이것저것 만들기 시작했더니 이분들이 청구서를 기분 좋게 계속 내주고 있습니다.
지금은 휴가 중인데, 제 주요 고객은 계속 새 기능을 요청합니다. 제가 휴가를 가기 전까지는 한 달에 고객 두세 곳에 맞먹는 일감이었어요. "이것도 되나요? 이건요?" 하는 식으로요. 솔직히 이분들이 좀 속도를 늦춰 주면 좋겠습니다. 비슷한 규모의 고객이 하나 더 있으면 좋겠는데, 이분들이 원하는 걸 다 얻기 전까지는 그렇게 만들 수 있을 만큼 시간을 쓸 여유가 거의 없거든요. 그래도 돈을 내주는 동안은 절대 멈출 생각이 없습니다.
또 재미있었던 건, 거기에 엔지니어가 아닌 직책으로 일하는 젊은 엔지니어가 한 명 있었다는 겁니다. 말하자면 사람 지게차 역할이었죠. 제가 "이거 전부 구현하는 데 도움이 필요해요"라고 했더니 그분은 지금 월급이 올랐고, 일종의 상주 고객지원 담당자처럼 일해 줘서 저는 신경을 훨씬 덜 쓰게 됐습니다.
어쨌든 일단 만드세요.
프런트 데스크용 전화 자동화는 고객에게 일정 등을 안내하려고 고객을 찾아보는 데 드는 시간만 해도 한 달에 40시간쯤 아껴 줍니다. 그건 도구 하나일 뿐이고 배포하는 데 나흘쯤 걸렸어요. 정말 어렵지 않습니다. 그냥 나가서 사람들의 삶을 편하게 만들어 주세요. 규모를 키우려고 애쓰지 말고요.
이런 도구들의 유지보수는 어떻게 하세요?
엄청 쉬워요. 뭐가 고장 나면 고칩니다. 95%는 Claude나 보통은 codex에게 문제를 가리켜 주고 커피를 마시는 게 전부예요.
저는 마운틴뷰에 있는 회사에서 일한 적이 있는데, 주력 제품이 해충 방제 업자를 위한 서식 자동 작성기와 캘리포니아 EPA 문서 작업이었습니다.
원래는 비주얼 베이직으로 쓴 것처럼 보였고, 그걸 태블릿용으로 리액트로 다시 짠 제품이었어요.
아직 NDA에 묶여 있긴 한데, 회사당 월 매출에 대한 위의 금액은 얼추 맞습니다.
그런데 연 2만 4천 달러면 빈곤선 수준 아닌가요?
제가 뭘 놓친 건가요? 이런 일을 대여섯 개씩 동시에 돌리시는 건가요?
그러면 사내에서 할 수 있는 마케팅 컨설팅에 월 2천 달러를 내는 사람도 없겠네요.
프랙셔널 CFO에게 월 2천 달러를 내는 사람도 없겠고요.
프랙셔널 영업 총괄에게 월 2천 달러를 내는 사람도 없겠고요.
제조업체의 환경 서류 컨설팅에 월 2천 달러를 내는 사람도 없겠죠.
전부 사내에서 할 수 있는데 뭐하러 그러겠어요.
그렇죠?
물론 이 모든 일이 실제로 벌어지고 있고, 하나하나가 다 큰 산업입니다.
이 업계는 작업 결과물의 문법이 난해하다는 장벽이 사라지자마자 상업적 수요가 아예 끝장난다고 호들갑을 떨기 시작했어요.
그런데 그 논리대로라면 법적 자격 장벽이 없는 업종에는 서비스 제공업체가 거의 없어야 합니다.
마이크로소프트가 방금 MXC를 내놨습니다.
"...신뢰할 수 없는 코드(모델 출력 ...)를 실행하기 위한"
https://github.com/microsoft/mxc
이건 일반 프로그램용으로 먼저 내놨어야죠.
정말 멋져 보이는데 설계가 좀 이상하네요. 애플리케이션에 포함하는 라이브러리라고요? 왜 외부 계층으로 만들지 않았을까요?
요점을 놓치셨네요. 소프트웨어 솔루션을 돌리려면 애플리케이션 보안은 여전히 제대로 갖춰야 합니다.
저는 무한히 커스터마이징되는 소프트웨어보다 더 믿을 만한 소프트웨어가 간절합니다.
제니 방적기도 멋지긴 하지만, 스타트렉 레플리케이터를 일상적으로 쓰는 세상에서 발명됐다면 혁명이라기보다 신기한 물건 정도였을 거라고 봅니다.
"수제 코드"는 cp 명령이 제대로 동작하지 않거나 돌리는 데 수천 달러가 든다면 분명 사라지겠지만, 그렇지 않으니 이 비유는 기껏해야 잘못된 것이고(최악의 경우 불성실한 것이고, 예를 들면 프런티어 랩들이 필사적으로 밀어붙일 때가 그렇습니다) 그래서 사라지지 않는 겁니다.
그리고 뒤집어 보면, 스타트렉 레플리케이터가 발명되면 수제 의류가 엄청나게 부활할 테고 이제 싸구려 착취 공장 제품을 원하는 사람은 아무도 없을 겁니다. 손으로 만든 구찌 실크 옷을 몇 달러에 가질 수 있는데 왜 그러겠어요?
손으로 짠 양탄자 시장 규모는 사실 그대로이고, 기계로 찍어낸 양탄자는 원래 손짜기 양탄자를 살 형편이 못 되던 넓은 계층의 빈자리를 채웠을 뿐일 수도 있지 않을까요?
정확히 그런 일이 벌어졌다고 생각합니다.
다만 소프트웨어는 만드는 비용이 내려가고 있다고 할 수는 있어도, 최종 사용자에게는 딱히 싸지고 있는 것 같지 않습니다.
역설적이게도 소프트웨어를 돌리는 비용은 로컬 머신에서 돌리든 구독으로 쓰든 계속 오르는 것 같습니다.
아이러니하게도 AI 기업들이 부품 가격을 끌어올리면 비용을 아끼려고 효율적인 소프트웨어에 대한 수요가 늘어날 수도 있겠네요.
맞아요. 올해 제가 직장에서 만든 작지만 쓸모 있는 코드들은 예전 같으면 외주를 줬을 수도 있었을 겁니다(저희는 규모가 작은 비기술 회사입니다). 하지만 비용 말고도 조율하고 QA하는 등의 번거로움이 있죠. 예전에는 수작업으로 하던 일을 자동화하려고 API 몇 개를 이어 붙이고 UI를 최소한으로 얹는 프로젝트에는 그런 게 정말 필요 없습니다.
외주를 줬어도 어차피 코딩 에이전트로 했을 겁니다.
소프트웨어에서는 예전 같으면 뭘 만들지도 못했고 개발자를 고용하지도 않았을 사람들이 이제 그걸 팔아 보겠다고 나서는 모습이 많이 보입니다.
그중 일부는 성공해서 그걸 뒷받침할 기술 인력이 필요해질 겁니다.
저는 같은 프로그램을 계속 반복해서 쓰지 않기 때문에, 이 산업화 비유가 소프트웨어 개발에 정확히 어떻게 들어맞는다는 건지 늘 헷갈립니다.
이렇게 생각해 보세요. 페르시아 양탄자도 매번 같은 무늬는 아닙니다. 기본 작업은 같지만 구현에는 계획 같은 것이 필요하죠. 양탄자 짜는 기계는 같은 것을 되풀이해서 만드는 데는 뛰어나지만 유연하게 대응하는 데는 그리 뛰어나지 않습니다.
소프트웨어는... 상당수가 기본적으로 같은 것(데이터베이스, API, 프런트엔드)이고 다른 점은 어떤 데이터와 어떤 비즈니스 규칙이냐뿐입니다. 하지만 코드를 쓰는 행위 자체는 크게 다르지 않아요. 소프트웨어 엔지니어가 나서는 건 어떤 코드를 어디에 쓸지의 문제입니다.
더 나은 비유는 소프트웨어 개발이 양탄자 짜는 기계를 만드는 일에 가깝다는 겁니다. 그 일을 한다면 양탄자가 정확히 어떻게 만들어지는지 속속들이 아는 게 유용할 테고, 그 경험을 쌓으려고 직접 조금 짜 보고 싶을 수도 있습니다. 그러고 나서 기계를 설계할 때는 앞서 꼼꼼히 공부했던 개념들, 아마 직접 손으로 해 보면서 익혔을 기어나 4절 링크 같은 기구들을 이미 잘 알고 있으니 그걸 씁니다. 그런 다음 설계도를 그리고 시뮬레이션하고 기계 공방에 보내면, 기계 자체는 어쩌면 한 번도 만져 보지 않을 수도 있습니다(실제로는 이런 맞춤형 1세대 기계는 제작 후에 디버깅이 필요하다고 생각하지만요).
즉 이걸 직접 손대지 않아도 되는 단계에 이르기까지, 아마 직접 손으로 해 보면서 그 밑바탕 개념을 깊이 배워야 했을 겁니다.
기계를 조작하는 일에는 늘 이런 현상이 있지는 않습니다. 예를 들어 전동 드릴을 쓰려고 손으로 돌리는 드릴을 써 본 경험이 필요하지는 않죠.
"뿐"이라고요? 와.
데이터베이스, API, 프런트엔드는 도구이자 범용 원자재라서, 깎고 다듬어 최종 모양을 만들어야 합니다.
그건 CRUD 앱에나 해당하는 얘기고, 그게 소프트웨어 프로그램 전체는 아니잖아요.