이런 논쟁들 전부 예전부터 정말 수도 없이 나왔다는 점을 감안하면 너무 회의적이고 싶진 않음
어셈블러에서 고급언어로의 이동, OOP 도입, 컴포넌트 아키텍처/COM/CORBA, 웹브라우저의 등장, Java 도입 등 2018년은 "쇠퇴가 시작된 시점"이 아니라 과거부터 쭉 이어진 데이터 포인트 중 하나에 불과함
태클 한번 걸자면 댓글을 작성한 분은 본 글에서 이야기하는 문제 정의를 이해하지 못한 것 같음. 위에 얘기한 high level의 언어로 이동하는 것과 AI 가 생성하는 코드의 취약점 및 시니어 엔지니어가 나올 수 없는 구조랑 전혀 관련없는 이야기임. 그냥 댓글 쓴 본인으로 인해 본문의 문제점이 증명 되어버림. 엔지니어링의 중요성에 대해 이야기하고 있는데 본인은 어려운 엔지니어링은 싫고 학습하기도 싫어서 변명을 너무 많이하는 것 같음. 혀가 너무길어
개발자가 아니라 내부 사정은 모르지만, 예전엔 이런 식으로 소프트웨어가 만들어지거나 운용되진 않았던 것 같음 더 신중하게 문제를 피하고자 하는 "어른들"이 더 많았던 느낌임
심지어 개발자도 아닌 거 같음..
Hacker News 의견
요즘 AI가 쓴 글을 구분하는 내 방식 중 하나가 "이건 X가 아님. 이건 Y임"이라는 문장 패턴임. 최근 이 표현이 너무 반복적으로 사용되고 있음
예를 들어,
1. "이건 AI 문제가 아님. 품질 문제는 ChatGPT 나오기 훨씬 전부터 시작됨"
2. "이건 점진적 저하가 아님—기하급수적임"
3. "이건 기능 요구사항이 아님. 이건 아무도 고치지 않은 메모리 누수임"
4. "이건 복잡한게 아니었음. 전산학 개론 수준의 오류처리인데, 아무도 구현하지 않음"
5. "이건 투자가 아니라, 항복임"
6. "시니어 개발자는 갑자기 생겨나지 않음. 그들은 주니어 개발자로부터 성장함"
7. "해결책은 복잡한게 아님. 다만 불편할 뿐"
이 수사적 장치가 지금 내겐 칠판 긁는 소리처럼 거슬림
아무튼, 이건 이 글의 주장에 대한 비판이 아니라, 그냥 내 잔소리임
나도 #5에서 해당 기사에 확 빠져버렸음
내 AI 감지기는 좀 늦게 켜졌는데, 다음 구절에서 확 올라감
"오늘의 진짜 체인: React → Electron → Chromium → Docker → Kubernetes → VM → managed DB → API gateways"
물론 이런 기술을 조합해서 쓰는 앱·서비스 백엔드를 상상할 수 있지만, 실제로 저 "체인"이 저렇게 붙어 있는 건 딱히 의미가 없어 보임
누가 Electron 앱을 Kubernetes로 배포한다는 건 손에 잡히지 않음
클라이언트-서버 아키텍처를 설명하고 싶었다면, API gateway를 Electron 앱과 서버사이드 사이의 연결 고리로 넣었겠지, Electron을 Chromium 위에 넣는 게 아니라
기사의 도입부는 정말 "분노의 블로그"처럼 느껴졌지만, 마지막엔 Axios 기사처럼 불릿포인트와 "기발한" 헤드라인들만 나열하는 공식화된 글 같았음
그리고 "The " 형식의 헤드라인이 너무 자주 보여서, AI 냄새가 플플 남
이 문장 패턴이 여러 곳에서 점점 더 많이 보임
특히 LinkedIn 피드에는 이 짧은 문장 패턴이 넘쳐나고, 댓글 역시 명백히 AI가 쓴 것 같음
이제는 이 흔하게 쓰이는 문구들을 피하는 것도 점점 지치기 시작함
나는 LLM을 사용하지 않음
앞으로 우리가 이런 표현을 점점 더 자주 접하게 될 거라는 걸 받아들이는 게 나을 거라고 생각함
이젠 굳이 지적하는 것도 의미 없어짐
이런 논쟁들 전부 예전부터 정말 수도 없이 나왔다는 점을 감안하면 너무 회의적이고 싶진 않음
어셈블러에서 고급언어로의 이동, OOP 도입, 컴포넌트 아키텍처/COM/CORBA, 웹브라우저의 등장, Java 도입 등
2018년은 "쇠퇴가 시작된 시점"이 아니라 과거부터 쭉 이어진 데이터 포인트 중 하나에 불과함
Elite 8-bit 게임이 몇 KB 테이프에 담기던 시절에서 MS Flight Simulator 2020이 DVD 여러 장에 달하는 지금까지의 흐름을 그래프로 그리면, 여전히 상승 곡선임
어디서 꺾일지는 불명확함
소프트웨어 품질은 항상 사람들이 돈을 기꺼이 지불하는 수준에 머무르고 그럴 것임
"아직 곡선이 꺾일 지점이 명확하지 않다"는 말에 대해 내 생각으론, Moore's Law가 끝나서 더 이상 획기적으로 빠른 기계를 만들 수 없게 되는 시점이 그때가 될 거라 예상함
나는 소프트웨어 업데이트가 문제의 원인이라고 봄
한때 소프트웨어는 출시 후에도 제대로 동작했지만, 어느 순간 완전히 달라짐
애자일 방법론이 기존의 존재하지 않는 폭포수(워터폴) 방식이라는 허수아비를 만들어내면서, "작동할 때까지 출시하지 않는다"는 방식은 실질적으로 기술부채를 없앰
누군가 이 방법을 실제 관리 방식으로 만들어줬으면 좋겠음
처음엔 힘들겠지만(업계 전체의 기술 부채 규모도 엄청나서), 일단 한번 해내면, "릴리즈하고 잊어버릴 수 있을" 진짜 퀄리티 있는 소프트웨어가 나온다면 업계의 판도가 바뀔 것임
참고로 관련해서 xkcd 2030 참고하면 좋음
또 한 가지 원인으로, 테크 업계가 유일하게 아직도 자기 자신을 객관적으로 바라보지 못하는 산업 같다고 느낌
코딩은 예술적이라고 하는데, 배관이나 전기배선, HVAC 작업이 예술적인 것과 똑같은 수준임
즉, 만족감은 얻을 수 있지만, 회사들은 딱히 길게 문제를 남기지만 않으면 결과만 나오면 됨
우리가 "기술 부채"라고 부르는 걸 전기공은 "알루미늄 배선"이라 하고, 배관공은 "납땜"이라 부름
결국 모든 산업이 초창기 실험적 혼돈기를 거치고, 이후 표준화되고 면허제 등 체계가 잡히듯, 소프트웨어 업계도 언젠가는 공식적으로 라이선스를 줘야 하는 분야가 될 거라 생각함
만약 소프트웨어 품질의 극적인 저하를 못 느끼고 있다면, 정말 관심 없거나 일부러 외면하고 있다는 얘기임
새로 유입된 개발자 급증과 "Move fast and break things" 문화, 요즘의 "AI" 열풍이 합쳐져 품질이 악화됨
주니어 개발자는 더 이상 시니어로 성장할 명확한 경로가 없음
대부분 시장 압박 때문에 "AI" 툴에 의존하고, 덕분에 디버깅하고 문제를 해결·예방하는 법을 스스로 배우기 힘듦
일부는 AI를 학습용으로 잘 쓰지만, 대부분은 그냥 반복해서 돌리는 데 그침
이런 추세는 대중의 불만이 극에 달해 한 번 더 업계 붕괴가 일어날 때까지 계속될 것 같음
아마 "AI 버블 붕괴"와 동시에 일어날 수도 있고, 따로 일어날 수도 있다고 봄
상업용 소프트웨어 엔지니어링에서 소프트웨어 품질이 전혀 중요하지 않다는 점이 LLM이 우리 자리를 쉽게 대체할 수 있다고 느끼는 이유임
버그가 그냥 중요하지 않음
과거엔 "결정적인 문제를 야기해서 고객과 사업을 잃으면 그때 가서 바뀔 것"이라 반박했겠지만, Crowdstrike 사태 이후도 그냥 일상이 계속됨
전 세계적으로 중요한 서비스를 멈추고, 100억 달러나 되는 경제적 손실을 냈지만, 시장의 인식이 크게 달라지지 않나 봄
고객을 이미 확보한 후라면 버그는 별로 중요하지 않음
그 전까진 정말 많은 영향을 미침
다만, 비즈니스가 사용자들을 자사 생태계에 가둬두는 "해자(moat)"를 구축하는 게 너무 쉬워진 게 문제임
비즈니스 관점에선 좋지만, 이런 구조가 혁신을 저해하고 사용자들은 기술에 무관심하고 좌절하게 만듦
사실 LLM은 보안과 관련된 버그(진짜 중요한 버그)를 꽤 잘 찾아낼 수 있어서, 앞으로 코드 점검 시 LLM 사용 안 하면 과실로 간주될 수도 있다고 생각함
최근에 nginx 설정 문제를 봐야 했는데, 내 주된 업무 아니지만 LLM이 보안상 중요한 두 가지 문제를 지적해줬음
이전 릴리즈 사용 문제 및 펜테스트 피드백 반영 사항도 알게 됨
LLM은 분석에 정말 강한 느낌이고, 몇 개 파일과 단편적인 정보만 줘도 원하는 방향으로 응답해줌
코드 실행 결과물 생성엔 아직은 신뢰가 덜 가지만, 분석 능력만으로도 내 업무에 큰 변화가 생김
버그는 중요함
LLM이 결국 누군가 인간이 결함을 악용할 때 도구로 활용될 뿐, 그 자체로 우리의 자리를 뺏진 않을 것임
70년대부터 신경망(뉴럴 네트워크) 개발은 이어져왔고, 소프트웨어 개발에서 실질적인 효용을 얻는 데 두 가지 큰 장벽이 있었음
첫번째 문제는 이제서야 처리/저장 용량의 증가와 오픈소스 확산 덕분에 풀린 것임
두번째 문제는, 출력이 상당히 오류가 많고, 후처리(검증) 절차도 엄청난 노력이 들어감
그리고 신경망 기반 코드 생성이 실제로 경쟁력이 생긴 건, 역설적으로 업계 전반의 품질 자체가 너무 나빠져서 오류 많은 코드라도 충분히 경쟁력이 생겼기 때문임
(참고: xkcd.com/2030)
아이러니하게도, AI를 비난하는 기사에서 "하드웨어에 3640억 달러가 들어가야 돌아가는 소프트웨어는 확장성 문제가 아니라 근본적인 엔지니어링 실패를 보완하려는 것"이란 구절이 나왔음
아는 사람은 아는 내용임
"내가 3년간 소프트웨어 품질 지표를 추적했다"고 하면서 정작 데이터는 하나도 없고, 온갖 경험적 사례만 나열함
기사 전체가 근거 없는 b급 카피 필(feel)임
개인적인 느낌으론, 2005년엔 역량 부족한 개발자들이 jQuery·WordPress·PHP로 웹앱을 막 찍어내는 게 일상이었음
근 몇 년간 업계 트렌드는 오히려 코드의 품질이나 구조를 더 신경 쓰는 쪽으로 발전했고, 지금은 CI/CD나 최소한의 테스트·버전관리(Git), 제대로 된 호스팅 인프라까지 매우 일반적임
20년 전엔 그냥 서버에 SSH로 들어가 고치다 깨지는 게 흔했음
이 글은 AI 자체에 분노하는 게 아니라, AI로 일관된 코드를 만들어낸다는, 그 발상 자체에 화가 난 것임
AI 도구가 문법 검사나 창의적 글쓰기를 도울 때 사용하는 건 환영임
단순한 향수에 속은 거임
20년 전에도 지금보다 특별히 더 나았던 건 아님
그 시절 소프트웨어가 기가바이트 램을 먹지 않은 건, 단순히 램이 없어서였음
지금 내가 쓰는 거의 모든 소프트웨어는 매일 사용하는 과정에서 최소한 두 개 이상의 문제가 있음
웹/모바일/콘솔 등 모든 앱에 명확한 버그가 있고, 문제를 진단하거나 보고하기도 힘듦
하루에 15~30분씩은 버그 우회에 소비함
오늘날 소프트웨어는 변화와 업데이트가 끊임없는 문화임
2주만 지나도 앱이 강제 업그레이드를 요구함
Kubuntu LTS도 끝없는 업데이트를 뿜음
롤링릴리즈 배포판(옛날엔 unstable branch라 하던)이 정식으로 사용됨
개발자가 아니라 내부 사정은 모르지만, 예전엔 이런 식으로 소프트웨어가 만들어지거나 운용되진 않았던 것 같음
더 신중하게 문제를 피하고자 하는 "어른들"이 더 많았던 느낌임
지금은 그저 문제를 받아들이거나 무시하는 분위기임
(물론 "아예 문제의 가능성을 인지 못하는 무지함"이라는 결론까진 내리고 싶진 않지만, 실제로 그런 가능성도 현실임)
아니, 내 생각에 예전에는 버그 한 번 나면 진짜 큰일이었고, 품질이 더 높았다고 확신함
예전 소프트웨어를 VM에서 객관적으로 테스트해보면 흥미로울 것 같음
요새는 끊임없는 업데이트가 가능해서 "빠르게 배포하고, 꾸준히 버그를 고치는" 게 "천천히 적게 배포하고 버그 적은" 것보다 모든 면에서 유리함
과거엔 물리 매체로 소프트웨어를 배송해야 해서, 크리티컬 버그의 리스크가 컸기 때문임
Windows 95~ME 시대를 기억하는 사람들은 다 기억함
그냥 무작위로 크래시가 나고, BSOD와 "불법적인 동작을 수행했음", "장치 오류 발생", "Windows가 레지스트리 수리 후 재시작" 같은 메시지가 일상임
단축키 Ctrl+S를 제일 먼저 배웠음
웹은 브라우저마다 박스 모델 다르고, DHTML이나 공유 호스팅 CGI 등도 온갖 혼돈 그 자체임
지금이 훨씬 쉽다고 생각함
20년 전엔 전화를 들면 늘 사람이 받아줬고, 문제 해결 가능했음
물론 당시에도 안 되는 게 많았지만, 요즘은 되게 만드는 시도 자체를 안 하는 듯함
전체적인 문화의 변화임
지금 시대는 개별 경험이 중요하지 않은 "확률적 규모의 시대"이고, AI가 컴퓨터를 예측 가능에서 예측 불가로 밀어붙이고 있음—둘 다 같은 방향에 있음
"A plea for lean software"라는 Wirth의 1995년 글을 보면, 예전엔 몇 킬로바이트로 되던 일이 요즘은 메가바이트 RAM을 필요로 한다고 한탄함
"오늘의 체인: React → Electron → Chromium → Docker → Kubernetes → VM → managed DB → API gateways. 각각 20~30% 오버헤드가 합쳐져서 2~6배 성능 저하가 된다"
걱정하는 대로 이렇게 누적되면 32GB 메모리를 새는 계산기 앱이 나오는 건, 누가 일부러 그런 게 아니라 아무도 누적 비용을 신경 쓰지 않기 때문임
MacOS 계산기는 위의 기술 아무것도 쓰지 않음
내용 자체도 아이러니함
이런 글을 옛날부터 여러 번 접했고, 한때는 이해했지만 지금은 "완벽한 소프트웨어의 이상향"만 쫓을 필요 없다는 걸 알게 됨
현실에서 소프트웨어는 항상 트레이드오프가 존재하고, 대부분은 비즈니스를 위한 수단임
"완벽 소프트웨어"와 "메모리 32기가 새는 소프트웨어" 사이에는 우리가 목표로 삼아야 할 꽤 넓은 구간이 있다고 생각함
기사를 좋아하지만, 기업들이 에너지라는 물리적 한계에 부딪힐 것이라는 저자의 주장에 동의함
에너지 이슈가 실제로 임계점이 될까 하는 의문도 있음
실제로 대기업들이 원자력이나 전력망 업그레이드에 투자하는 뉴스만 봐도 이미 이 문제는 인지하고 대책을 준비 중임
완벽한 이상향도 없고, 트레이드오프가 항상 있으며, 비즈니스 성공도 중요하지만, 이윤만이 전부가 되면 문제가 생긴다고 생각함
버그투성이인 소프트웨어가 더 많은 돈을 벌 수 있음
구독 요금제를 설득할 명분이 되기 때문임
실제 세계에서 "더 나쁜 계산기"로 얼마를 벌었을지 궁금함
Windows 98부터 동시대 앱을 써보면, 그 당시도 엄청 불안정했음을 알 수 있음
20~30년 전에도 사용자용 소프트웨어의 버그는 현재 못지않게 많았고, 보안도 전반적으로 훨씬 취약했음
Windows XP도 설치 중에 감염되는 일도 많았음
지금 절대 허용되지 않을 버그(세그폴트, 데이터 손실)가 과거엔 일상이었음
다만, 최근 눈에 띄게 퇴보한 건 UI 반응 속도 하나뿐임
브라우저와 Electron 앱이 요즘 램 사양에도 비효율적인 건 맞음
"Windows 98도 별로였다"는 건 그냥 Microsoft가 원래 코드 품질이 나빴다는 방증임
그 시절 Linux는 단점이 있어도 일관적으로 더 안정적이었음
50년간 형편없는 품질을 표준처럼 만들 정도로 Microsoft가 업계에 끼친 영향은 큼
"Windows 98도 꽤 엉성했다"는 주장에 대해, 패치 다 된 Windows 7과 Windows 11을 비교해보라 말하고 싶음
비교 시점이 딱 두 개만 있는 건 아님
2020년대 이후의 전반적인 트렌드도 고려해야 함
"UI 반응 속도만 좀 느려졌다"는 주장에도, 실제론 모든 컴포넌트에서 10~100배 정도 저하됨
MS Teams만 봐도 됨
고품질 코드의 이상은 좋지만, 에너지 효율 문제 자체에는 별로 동의하지 않음
데이터센터 전력 사용량이 전체 지구 에너지 예산에 비하면 극히 미미함
태양 에너지, 석유 소비, 전 세계 GDP 등과 비교해보면 디지털 산업은 오히려 에너지 효율 면에서 다른 산업에 비해 양호함
탄소 배출, 지구온난화 걱정할 자원이 있으면 내연기관 등 타 산업에 더 집중해야 한다고 생각함
오히려 소프트웨어 엔지니어의 생활 자체의 에너지 소비, 즉 출퇴근, 출장, 생활 자체가 더 큰 영향을 줄 수도 있음
2025년엔 재생에너지도 많이 저렴해져서, 진짜 중요한 이슈는 따로 있다고 생각함
최근 공항에서 형편없는 소프트웨어를 경험했음
여권 자동심사 게이트 15개 중 12개가 에러 메시지를 띄우며 중단됨
점점 더 많은 게이트가 고장나 직원이 직접 도와주기 시작했음
이런 명백히 준비가 안 된 시스템이 어떻게 도입되는지 궁금함
그리고 이런 문제 발생 시 왜 현장 직원이 재부팅도 못 하는지 의문임
아무도 다치진 않았지만, 소프트웨어 라이선스 계약이 품질 문제에 대해 공급자가 책임을 회피하도록 만드는 게 진짜 문제인 것 같음
다른 어떤 산업이라면 받아들이지 못할 수준임
왜 준비 안 된 소프트웨어가 출시되냐면, 요즘 업계의 최소 기준이 "소송만 안 당하고, 고객에게 거부당하지 않을 수준이면 OK"이기 때문임
모든 게 급하게 출시되고, 출시 여부 결정은 단순히 "회사에서 받은 돈을 회수할 수 있는지"에 달려 있음
요구 수익이 나오면 품질이 부족하더라도 그냥 납품되는 거임
너도 Heathrow 공항 터미널2에 있었단 얘기구나, 내 경험과 비슷해서 웃음이 나옴