AI가 소프트웨어 엔지니어를 대체하지 않은 이유, 그리고 앞으로도 대체하지 못할 이유

컴퓨터 산업 역사 내내 우리는 소프트웨어 엔지니어링 자동화를 공격적이고 열정적으로 해왔고, 그때마다 더 크고 좋은 것을 더 빨리 만들 수 있게 됐음
그렇게 생산성이 오르면 일의 가치도 커지고 기대치도 같이 올라갔으며, 지금까지 세계의 소프트웨어 수요는 끝이 없었음
AI가 소프트웨어 엔지니어를 대체하지 못한 이유는 생산성이 올라갈 때마다 목표 지점도 함께 이동했기 때문임
이 흐름이 끝나는 경우는 두 가지인데, 첫째는 마침내 세계의 소프트웨어 수요를 다 채울 만큼 생산성이 높아지는 것임
아직 그런 증거는 보이지 않고, 이번이 컴퓨터 산업 전체 역사와 왜 다른지 명확히 설명해야 함
둘째는 AI가 자율적으로 행동할 때 인간보다 뛰어난 소프트웨어 엔지니어가 되는 경우임
즉 AI+인간 개발자가 AI 단독보다 더 낫지 않은 상태인데, 지금까지 증거는 AI가 개발자의 증폭기이며 좋은 결과를 내려면 전문가가 방향을 잡고 AI가 최대 90%를 하는 정도로 보임
가까운 미래에 둘 중 하나가 일어날 강한 증거는 없어서 소프트웨어 엔지니어는 당분간 안전하다고 봄
다만 기술 폭이 좁고 특정 영역, 예컨대 프런트엔드 웹 개발에 집중한다면 더 걱정해야 함
AI가 소프트웨어 엔지니어 전체를 대체하지 못해도, 제너럴리스트가 지휘하는 형태로 특정 도메인을 완전히 흡수할 가능성은 꽤 높음

소프트웨어의 종착점이 그리 멀지 않았다고 봄
이미 전체적으로는 사람들이 정말 원하는 것보다 더 많은 소프트웨어를 만들고 있고, 그 상당수는 쓰레기에서 노골적 사기, 심지어 악성에 가까운 것까지 있음
최종적으로는 할 일 목록 관리나 파일 동기화처럼 일반인이 필요한 작은 소프트웨어를 각자의 AI가 맞춤형으로 작성하게 될 것 같고, 소프트웨어 엔지니어는 큰 기업 프로젝트에만 남게 될 듯함
지난 수십 년간 상용 소프트웨어의 압도적 추세는 극단적인 반사용자적 비맞춤화였음
하나의 행복 경로만 남기고, 필요에 맞지 않으면 알아서 하라는 식이 됐음
일상적인 사람들을 위한 상용 소프트웨어는 거의 없고, 오픈소스조차 일반 사용자에게서 멀어지는 중임
곧 평범한 사람들이 자기 방식대로 문제를 해결하는 소프트웨어를 직접 만들 수 있게 될 것임
대부분의 경우 품질과 정확성은 크게 중요하지 않고, 맞춤형이며 무료이고 침습적인 감시·광고 플랫폼이 아니라는 점이 더 중요함

프런트엔드 웹 개발 예시는 좀 웃기게 느껴짐
프런트엔드 개발자로서 현재 최첨단 모델은 내가 신경 쓰지 않는 지루한 뒤쪽 배관 작업은 잘하지만, 실제 고객이 원하는 맞춤형 디자인 작업은 아직 잘 못한다고 봄
누가 확실히 맞고 틀렸다는 뜻은 아니고, 더 일반적인 기술 폭이 새 시대에 성공하는 최선의 방법이라는 데는 동의함
다만 LLM이 스택의 어느 한 부분을 완전히 장악해서 그 분야 전문가가 사라질 정도는 아직 아님

“이런 일이 일어나는 증거가 보이지 않는다”는 말과 달리, 적어도 모바일 앱 스토어에서는 이미 비슷한 현상이 보임
최근 분석에 따르면 출시 앱 수는 크게 늘었지만, 전체 리뷰 수와 다운로드 수는 정체되어 있음
즉 앱은 훨씬 많아졌지만 사용자는 그다지, 혹은 거의 늘지 않았다는 뜻임
"WRITING CODE VS. SHIPPING CODE: PRODUCTIVITY EFFECTS ACROSS GENERATIONS OF AI CODING TOOLS"의 p40 / figure 12를 보면 됨: https://www.nber.org/system/files/working_papers/w35275/w352...
분석은 42~43쪽에 있음
파이가 고정됐다는 걸 증명할 수는 없지만, 반대로 파이가 무한하다는 것도 증명할 수 없음
소프트웨어의 경제 성장 이야기를 할 때 사람들이 놓치는 핵심은 돈이 어딘가에서 와야 한다는 점임
계속 성장하려면 지금 소프트웨어에 돈을 내지 않는 누군가가 새로 지불을 시작해야 하는데, 그들이 누구이고 얼마를 갖고 있으며 어떤 다른 비용과 경쟁하는지 봐야 함

“세계의 소프트웨어 수요는 끝이 없었다”는 말이 모두가 최신 최고 기술을 찾는다는 뜻은 아님
많은 기업은 여전히 맞춤 스프레드시트나 Microsoft Access 같은 기술에 의존함
원하는 일을 정확히 해주고, 비용이 고정적이며, 추가 수정이나 유지보수가 거의 필요 없기 때문임
우리가 갇힌 거품 밖으로 나가 보면 많은 사람이 업그레이드에 관심이 있는 게 아니라, 이미 아는 낡은 것이 그냥 계속 작동하길 원한다는 걸 알게 됨

AI가 전문가 지휘 아래 90%의 작업을 할 수 있다면, 그건 개발자의 90% 를 일자리에서 밀어낸다는 뜻임
그리고 그 비율이 99%가 되지 못할 이유도 잘 모르겠음

AI는 분명 소프트웨어 엔지니어를 대체할 것임
빠진 부분은 글에서 말하듯 전달·운영이고, 그건 소프트웨어 엔지니어보다 DevOps/SRE/Cloud 엔지니어의 영역임
클라우드 엔지니어로 일하는데, 비엔지니어 친구 여러 명이 이제 각자 사이드 프로젝트를 처음부터 여러 언어로 만들고 로컬, 웹앱, 네이티브 앱으로 실행할 수 있게 됐다고 연락해옴
그들에게 부족한 건 “보통 개발자”처럼 쉽게 배포하고 유지할 플랫폼임
지금은 이 발판을 만드는 일이 꽤 번거롭지만, AGENTS.md, skills, 엄격한 종합 테스트로 충분히 가능함
한 번 만들어두면 비기술 사용자는 claude/codex에 원하는 것을 말하는 방식으로 소프트웨어 엔지니어를 고용하지 않고도 계속 개발할 수 있음
claude/codex는 미리 정한 아키텍처를 바탕으로 판단하고 비기술 사용자를 안내할 수 있음
내 일화적 사례에서는 AI가 이미 여러 소프트웨어 엔지니어를 대체했음
이런 발판이 제품화되면 그린필드 프로젝트는 에이전트 코더와 플랫폼 엔지니어링을 통해 제품 관점에서만 관리될 수 있다고 봄
이것이 지금이고, 5년 뒤를 상상해보면 됨

이런 추론은 잘 이해되지 않는데도 널리 퍼져 있음
비엔지니어가 만든 앱을 들고 온다고 해서 AI가 소프트웨어 엔지니어를 대체했거나 대체할 것이라는 뜻은 아님
증상을 Dr. Google로 찾아보고 생활습관 변화, 약초 요법, 일반의약품을 시도해서 실제로 효과를 볼 수 있지만, 그렇다고 의사가 사라지는 건 전혀 아님
생성형 AI로 음악 이론도, 음악 감각도, 창의성도 없이 음악을 만들 수 있지만, 음악적 재능이 있는 사람들이 사라지는 것도 아님
AI 도움으로 집안 DIY를 할 수 있어도 엔지니어가 사라지는 것은 아님
도메인 전문가가 실제로 필요한 것을 프로토타입-개선 반복으로 명확히 하도록 누가 도울 것인가
취미 소프트웨어 제작자들이 의존하는 운영체제, 언어, 버전 관리 시스템, 편집기와 터미널 에뮬레이터, 지식·문서 관리 시스템, PaaS 플랫폼 등은 누가 작성하고 유지할 것인가
그들이 만든 것을 견고하다고 보장할 만큼 제대로 테스트했는가
생길 수 있는 경계 조건을 이해하고 있는가
보안은 괜찮은가
프롬프트로 빠르게 뭔가를 만들어내는 것은 엔지니어링과 같지 않음
소프트웨어 엔지니어링의 가치가 주로 산출된 코드, 즉 비트 배열 자체에 있다고 보는 오류 때문에 이렇게 보지 못하는 것일 수 있음
프로젝트의 주된 가치는 이론과 추상화를 만들어가는 과정에 있음: https://pages.cs.wisc.edu/~remzi/Naur.pdf

생성과 유지보수는 완전히 다른 짐승임
2주짜리 앱을 만들고 다시는 손대지 않는 엔지니어도 있겠지만, 그런 걸로 생계를 유지하는 사람은 잘 모르겠음
“당신의 사업을 위한 WordPress 사이트” 같은 일은 가능할지 모름
문제는 기능이 432개 있는데 433번째 기능을 추가하면서 나머지를 건드리지 않아야 할 때 생김
조금이라도 틀리면 안 되는 경우도 있고, 기능 하나가 엔지니어가 감당하는 속도보다 더 빠르게 복잡도를 늘려 시간이 지나며 프로젝트가 관리 불가능한 크기가 되는 경우도 있음

우리 회사에서는 비기술 팀이 기술 팀의 과부하 때문에 스스로 도구를 만들기 시작했음
큰 시스템과 연동되는 작은 애플리케이션 아이디어였고, 23일 만에 34커밋으로 개념 증명이 만들어졌음
인상적이긴 했지만 만든 사람이 지난 3개월 동안 그 프로젝트에 400커밋을 더 했고, 수정이 이어지면서 사실상 그 앱을 만들고 유지하는 일이 파트타임 또는 풀타임 일이 됐음
그 사람은 훈련받지 않은 소프트웨어 개발자가 됐고, 보안이나 모범 사례는 이해하지 못함
Claude가 더 좋아지면 부담이 줄어 하루를 잡아먹지 않을 수도 있지만, 현재 우리 회사의 이런 초기 “바이브 앱”들은 모두 유지보수 업무가 되어 점점 더 많은 시간을 먹고 있음
사람들은 소프트웨어를 덜 원하는 게 아니라 더 원한다는 게 분명함
전통적 소프트웨어 엔지니어링은 사라질 수 있어도, 확장되는 플랫폼 관리, 보안, 복잡성, 문서화, 비즈니스 로직은 여전히 우리 회사 앞에 남아 있음
텍스트로 프로젝트를 만들 수 있다는 말은 맞지만, 가장 단순한 소프트웨어가 아닌 이상 “설정하고 잊기”는 없었다고 느낌
여전히 누군가는 전체를 관리해야 함
그 사람이 소프트웨어 엔지니어링 훈련을 받았든 아니든 말임
경험 있는 개발자는 여전히 훈련받지 않은 사람보다 더 잘할 가능성이 큼
물론 호기심 많은 빌더들은 빠르게 따라잡겠지만, 전통적 개발자에게는 큰 우위가 있음
우리는 늘 내부가 어떻게 작동하는지 알고 싶어 했기 때문임
그들이 몇 달 걸려 만든 현재 바이브 앱은 AI를 쓰면 내가 한 시간 안에 만들 수 있었음

소프트웨어 배포는 터미널에서 vercel을 실행하는 수준까지 내려왔고, 에이전트도 요청만 받으면 아무 문제 없이 할 수 있음
데스크톱 소프트웨어 배포는 플랫폼에 따라 조금 더 어렵긴 함
그래도 사이드 프로젝트와 훌륭한 소프트웨어 사이의 간극은 여전히 매우 넓고, 그 간극이 언젠가 메워질 거라고 믿기 어려움
AI 이전에도 이미 풀린 문제가 먼저 대체되지 않을 이유가 뭔지 모르겠음
개인 프로젝트에 복잡한 인프라가 필요하다고 믿기도 어렵다

AI 보조 코딩은 훌륭하지만, 바이브 코딩은 폐기 가능한 프로토타입에나 좋다고 봄
무기한 유지해야 하는 금융 앱을 바이브 코딩으로 만들지는 않을 것임
레거시 시스템도 건드리지 않을 것임
AI가 일부 엔지니어를 대체한 것은 분명하지만, 비엔지니어 친구들이 사이드 프로젝트를 만든 사례는 관련성이 낮음
이제 가능해졌기 때문에 만든 것이지, 원래 누군가를 고용해서 만들 예정은 아니었을 가능성이 큼
지금까지 고용하지 않았던 것처럼 말임

개발 에이전시에서 일하고, 고객 대부분은 빠르게 시장에 나가야 하는 스타트업임
약 1년 반 동안 에이전트 기반 개발을 써왔고, 그동안 우리의 역할은 크게 바뀌었음
프로젝트 유입량은 정확한 숫자를 몰라 말하기 어렵지만, 보이는 변화는 전달 가능 범위에 대한 기대치가 달라졌다는 점임
예전에는 5명이 하던 프로젝트를 이제 보통 1~2명이 함
현실적으로 그린필드 프로젝트는 상당 부분 자동화됐음
UX/UI 디자인 반복, 시스템 아키텍처 반복, 명확한 측정 지표가 없는 어려운 문제에 여러 접근을 시도하는 등의 많은 수작업이 이제 즉시 일어남
머릿속으로 이해할 수 있다면, 100분의 1 시간에 세상에 내놓을 수 있는 셈임
이 기간 동안 일하는 방식과 시스템을 생각하는 방식도 많이 바뀌었음
LLM과 공생하게 됐고, 이제 없이는 정말 어렵다
그렇다고 LLM이 쓰는 코드를 이해하지 못한다는 뜻은 아니고, 모든 변경을 따라가며 코드베이스도 LLM보다 훨씬 크게 이해하고 있음
다만 수동으로 코드를 작성하는 능력은 크게 퇴화했고, 그 점은 괜찮다고 생각함
현재는 비즈니스 목표와 그것을 가장 잘 뒷받침하는 기술 사이의 번역 계층처럼 느껴짐
여전히 문제 해결이지만 훨씬 높은 수준의 문제 해결이고, 여전히 흥미롭고 재미있음
개발자에게 이 시대의 최선 전략은 비판적 사고를 유지하고 도구를 유리하게 쓰는 것 같음
이제 모두가 초능력을 얻었음
꼭 회사에서 일할 필요도 없고, 1인 개발자가 엄청난 것을 만들 수 있으니 다른 사람에게 의존할 필요도 예전만큼 없음
어쩌면 미래는 각자가 세상에 고유한 무언가를 제공하는 매크로 제품 경제일지도 모름

“이제 모두가 초능력을 얻었다”는 식의 해석은 AI 열광론자들이 상황을 이상하게 오해하는 것 같음
에이전트 코딩으로 그린필드 프로젝트를 만들 만큼 충분히 좋아진다면, 개발자뿐 아니라 회사 전체와 산업 부문 전체에도 영향을 줌
개발 에이전시 사업 모델은 기술이 약한 회사들이 소프트웨어를 다루는 법을 모르기 때문에 존재하고, 어떤 경우에는 초기 인력 집약 작업을 외주화하려는 기회주의도 있음
그런데 이제 그 기술이 에이전시 고객 손끝에 이미 있으니, CEO와 관리자들이 바이브 코딩을 시작하고 “기술 감각이 조금 있는 개발자 한 명”만 필요하다고 깨닫는 건 시간문제임
이것은 많은 SaaS 사업에도 확장될 수 있음
여전히 많은 소기업이 수작업을 없애려고 맞춤 소프트웨어를 원하지만, 진지한 소프트웨어 개발자는 항상 너무 비쌌음
그래서 누군가의 조카가 만든 엉성한 코드나 겨우 작동하는 SaaS를 쓰곤 했음
이제는 여전히 꽤 엉성하겠지만 자기 맞춤 솔루션을 만들고 더 많은 것을 얻을 수 있음
빅테크가 하는 일은 경기침체에 맞춘 재조정에 가깝고, 더 걱정되는 건 중소 기술 부문의 혼란임

회사에서 일하는 이유가 개발자가 혼자 결과물을 낼 수 없어서만은 아님
고객을 따낼 연결망이 없기 때문임
대부분의 개발자는 자신이 잘하는 일에 집중할 수 있도록 회사가 적어도 마케팅을 맡아주길 필요로 함

이론적으로 가능한 것과 현실적으로 가능한 것을 혼동하면 안 됨
실제 세상에서 성공한 회사들은 데이터, 특허·지식재산, 네트워크 효과 등으로 해자를 갖고 있음
개발 시간이 100분의 1이 됐다고 해서 곧바로 새 사업을 만들 수 있는 것은 아님
지금 기술 업계를 둘러보면 민첩한 AI 기반 빌더에게 와해될 수 있어 보이는 회사가 많지만, 잠금 효과 때문에 실제로는 그렇게 되지 않고 있음

“1950년 미국 인구조사의 270개 직업 중 자동화로 사라진 것은 엘리베이터 운전원 하나뿐”이라는 주장은 오해를 부름
같은 기간 농업 일자리는 노동력의 15%에서 2%로 줄었음

글에서도 그 부분을 다루는 것 같음
농업처럼 기계화와 자동화로 노동 수요가 크게 줄어든 직업과는 다르다고 함
사람들이 소비하는 칼로리 양은 비교적 고정되어 있고 25% 증가만으로도 비만 유행이 생겼지만, 생산되는 소프트웨어의 양은 백만 배 커졌다는 차이임

농장 고용 자체는 1950년 대비 4분의 1로 줄었음
비율 수치는 전체 노동력이 커졌기 때문에 감소를 과장함
하지만 더 넓은 식품 산업 고용을 보면 상당히 늘었음
그래서 “코더” 고용은 줄어도 더 넓은 “소프트웨어/기술” 산업 고용은 늘어날 수 있음

벌목 산업을 찾아보면 됨
그 일자리의 95% 정도는 이미 자동화됐지만, 그들은 올빼미 탓을 하곤 함

통계를 선택적으로 쓰는 전형적인 방식임
공장, 컨베이어 벨트도 마찬가지임
자동화가 들어올 때마다 사람들은 계속 일자리를 잃고, 우리는 그들이 다른 일을 찾길 “희망”하거나 “제너럴리스트가 돼라”, “전문가가 돼라”, “서비스업으로 가라”, “코딩을 배워라”, “석탄을 캐라” 같은 극단적이고 앞뒤 안 맞는 희망론을 오감
@pmarca만 들어봐도 기술 리더십이 얼마나 길을 잃고 incoherent한지 보임
산업 자동화에 관한 Stripe Press 최신 책도 참고할 만함: https://press.stripe.com/origins-of-efficiency

가장 순진하게 AI를 믿는 사람들은 대체로 땜질하는 사람들이었음
LLM 보조 코딩 덕분에 뭔가를 만지작거리는 속도는 놀라울 정도로 빨라졌으니 그럴 만함
땜질은 과정이고, 사람들은 만들고 조정하는 행위 자체에서 큰 즐거움을 얻음
결과는 2차나 3차 고려사항임
AI는 우리가 행동하고 따라서 만지작거릴 능력을 크게 넓혔지만, 스스로 의미 있는 영향, 즉 “엔지니어링”을 만들어내지는 못함
활동보다 영향이 중요함

땜질은 조직이 그 주변에 프로세스를 만들기 전의 엔지니어링처럼 보일 때가 많음
프로토타이핑, 디버깅, 테스트 등은 빨리 일어난다고 해서 가짜 일이 아님
컴파일러도 스스로 영향을 만들지는 않음
CI, IDE, 프레임워크, 클라우드 인프라도 마찬가지임
그것들은 사용하는 사람의 레버리지를 높여줌

아내는 AI에게 대체됐음
프로그래머였고, 회사가 공개적으로 아내와 몇몇 사람을 대체할 목적으로 에이전트를 만들었으며, 작동하기 시작한 지 약 한 달 뒤에 해고했음

아직 남아 있는 동료들의 사기는 나쁠 것 같음
우리 팀은 18개월 전에 새 상사를 맞았는데, 노골적인 편애가 있었고 그가 좋아하는 사람은 팀플레이어가 아닌 유일한 사람이었음
그는 18개월 동안 원격 근무자를 과거 성과와 무관하게 모두 해고할 방법을 찾아냈음
그중 한 명은 상사보다 높은 레벨의 상도 여러 번 받았지만, 상사는 항상 그 유해한 사람만 인정했음
AI 대체는 아니었지만, 사람들이 가치 없다고 느끼는 분위기는 AI로 대체될 때와 비슷할 것 같음
내 감독자를 포함해 그 팀의 모두가 다른 직장에 지원 중임
감독자는 고기능 자폐가 있고, 상사에게 자주 조롱당함
그들의 정신 건강을 위해 꼭 성공하길 바람
HR에 문제를 몇 번 제기했고, 업무 규정에서 상사가 위반하는 조항도 찾았지만, 적어도 여기서는 그런 규정이 그냥 글자일 뿐이라는 걸 배웠음
오히려 내 등에 표적을 그리는 셈이라 떠나야 했음
다른 여러 명도 우려를 제기했고, 그중 대부분은 이후 다른 일을 찾은 사람들임
다행히 곧 갈 새 직장을 구했고 기대하고 있음

힘들겠다
괜찮길 바람
이후 어떻게 됐는지, 새 직장을 구했는지, 여전히 소프트웨어 쪽인지 궁금함

AI 해고에 관한 기업 커뮤니케이션이 가짜라고 해서 위험이 무효화되지는 않음
기업 쪽 이야기가 거짓일 수 있어도 기술의 영향은 실제가 될 수 있고, 이 맥락에서는 잡음일 뿐임
글의 버거 도표처럼 실행 단계는 줄어드는데 다른 모든 단계가 커져서 전체 버거 크기가 그대로라는 가정도 그다지 그럴듯하지 않음
다만 소프트웨어 엔지니어링의 일부 영역은 아직 위협받기 매우 먼 것 같음
특히 정확성이 핵심인 영역이 그렇다
웹 개발은 대충 밀어붙일 여지가 훨씬 많지만, 로켓 항법 코드는 다름
LLM은 둘 다 할 수 있겠지만, 후자를 조만간 바이브 코딩하는 사람은 없을 것 같음

AI는 말 그대로 이미 일부를 대체했고 앞으로 더 그럴 것임
모든 소프트웨어 엔지니어를 대체하지는 않겠지만, 판도라의 상자가 열린 이상 저노력·저위험 작업은 AI가 하게 됨
Lovable 같은 서비스에는 실제 운영 중인 프로젝트가 매우 많고, 대안은 사람이 만드는 것이었음

Lovable에서 비소프트웨어 전문가가 작성하거나 프롬프트한 것 중, 완전한 SaaS 도구로 유용할 만한 “훌륭한” 프로젝트를 보여줄 수 있나

대안이 사람이 만드는 것이 아니라, 아예 존재하지 않는 것이었을 수도 있음

일자리를 대체하는 것은 언제나 사업주임
그래픽카드 묶음을 의인화하지 말아야 함

그 그래픽카드 묶음이 정말 더 효율적이 된다면, 인간을 고용하려는 사업주는 경쟁할 수 없게 됨

글의 이 부분은 확신이 안 듦
“진짜 병목은 (1) 무엇을 만들지 결정하고 명세하는 것, (2) 전달된 것을 검증하고 책임지는 것, (3) 코드베이스·비즈니스·환경에 대한 깊은 인간적 이해”라는 주장임
코딩이 비싸고 병목으로 여겨졌기 때문에, 그 입력이 맞고 출력물을 버리지 않도록 상류와 하류 모두에서 많은 노력이 들어갔던 것일 수 있음
코딩이 빠르고 싼 단계로 여겨진다면, 출력물을 버려도 되므로 상류에서 같은 수준의 감독이 필요하지 않을 수도 있음

잘못된 코드를 버리는 비용이 잘못된 것을 만드는 주된 비용은 아님
소프트웨어가 오작동했을 때의 영향과 하위 호환성 유지가 훨씬 더 나쁨