나는 글의 전제에 동의하지 않음. 엔지니어링 전반이 쉬워졌다고 생각함, 좋은 쪽이든 나쁜 쪽이든. 예전에도 이해보다는 null 체크만 잔뜩 넣는 사람들을 많이 봤음. 지금은 그게 단지 대규모로 확장된 것뿐임. 반대로 뛰어난 엔지니어링은 더 증폭되어, 예전엔 몇 주 걸리던 기능을 며칠 만에 만드는 경우도 봤음
글이 약간 과장되어 있다고 봄. 좋은 엔지니어링도 LLM 기반 에이전트의 도움을 받을 수 있지만, 여전히 결과 검증은 사람 몫임. 나쁜 엔지니어링은 그 단계를 건너뛰기 때문에, Amdahl의 법칙 관점에서 보면 LLM은 나쁜 엔지니어링을 더 크게 가속함
나쁜 엔지니어링은 훨씬 쉬워졌고, 좋은 엔지니어링은 약간 쉬워졌음. 그래서 예전엔 좋은 엔지니어링을 하던 사람들이 이제는 세 배 더 많은 나쁜 엔지니어링을 하게 됨
기업용 앱 개발에서는 mock 테스트가 예상값을 반환하는지만 확인하는 경우를 봤음. 이게 무슨 의미가 있나 싶음
LLM은 마법의 오라클이 아님을 잊기 쉬움. 출력물을 어떻게 다루느냐가 결과의 품질을 결정함. 그대로 써도 되는 경우도 있지만, 대부분은 수정이 필요함. “LLM이 그랬으니 맞겠지”라는 함정에 빠지기 쉬워서 나쁜 엔지니어링이 쉬워짐
원글에 동의하더라도, 실제로는 소프트웨어 품질이 좋든 나쁘든 상관없는 애플리케이션 영역이 많음. 작동만 하면 충분한 경우가 많음
단위 테스트 백 개로도 코드의 정확성을 증명하기 어려운 경우가 있음. 대부분의 개발자는 무엇이 충분한지 모름. vibe coding을 많이 쓰는 사람들은 테스트조차 기계에 맡김. 시스템 설계 단계로 가면, 전체적인 안전성과 시간적 불변성을 보장할 수 있는 설계가 필요함. 하지만 대부분은 단순히 박스와 화살표를 그리며 “베스트 프랙티스”를 인용함. 소프트웨어는 자연과학에 더 가깝다는 Sussman 효과처럼, 관찰에 더 많은 시간을 쓰게 됨. GenAI를 도구로 쓰는 건 유용할 수 있지만, 사고를 멈추고 도구에 의존하는 건 위험함
나는 단위 테스트가 뭔지도 모르지만, AI 덕분에 실제 업무에 큰 도움이 되는 프로그램을 만들 수 있음. 엘리트 프로그래머들은 돈을 줘도 이메일 답장조차 안 해줌
몇 년마다 새로운 도구가 나올 때마다 “소프트웨어 엔지니어링의 어려운 부분이 해결됐다”는 말이 나옴. 생산성은 급등하고, 데모는 인상적이며, 업계는 스스로를 칭찬함. 하지만 곧 인력 감축이 뒤따름. 진짜 돌파구가 있다면 좋겠지만, 그 결과가 해고라면 의미가 없음. 결국 질문은 같음 — 일자리를 줄이는 게 목표라면, 사람들이 생계를 유지할 수 없을 때 기업의 비전은 무엇인가?
목표는 개인의 고용이 아님. AGI 구축이 궁극적인 목표이고, 그 과정에서 개발자 연봉과 고용은 이미 정점을 지났다고 봄. 일부 AI 슈퍼 개발자만 예외임
복잡성을 제거하는 건 불가능하다고 생각함. 현실과 사람 자체가 복잡함. 소프트웨어가 단순할 수 있다는 생각은 비현실적임. 더 큰 관점에서 보면, 목표는 결국 중산층의 소멸 같음
수요가 없으면 다른 일을 해야 함. 거부하면 굶어야 함
자본주의는 하층 계급의 존재에 의존함. 그들이 다른 노동자들에게 압박을 주어, 더 낮은 임금과 더 나쁜 조건을 받아들이게 만듦. 프로그래머들은 그 현실에서 잠시 보호받았을 뿐임. 이 구조는 이민자 노동과도 연결되어 있으며, 기업은 위험한 일을 시키고 불복종하면 추방시킬 수 있음. 결국, 이 모든 건 노동비용을 낮추기 위한 시스템임
“코딩은 원래 어려운 부분이 아니었다”는 말에 동의함. 전문가들은 이미 무엇을 만들지 알고 있었고, 단지 반복 작업이 귀찮았을 뿐임
코드 유지보수는 여전히 사람과 경험의 문제임. “무슨 코드를 쓰지 말아야 하는가”가 더 중요해졌음. 지금은 코드 생성이 너무 쉬워서, 스파게티 코드를 양산하기 쉬운 시대임
LLM 논쟁의 핵심은 여기에 있음. 어떤 사람은 결과물만 원하고, 어떤 사람은 유지보수성과 안정성을 원함. 두 입장 모두 필요하며, 프로토타입과 프로덕션 역할이 자연스럽게 분리될 것임
진짜 실력 있는 사람은 여전히 직접 하길 원함. LLM 때문이 아니라 원래 그랬음. 오히려 “문법 입력은 재미없다”고 말하던 사람들이 가장 혜택을 보고 있음. 나에게는 타이핑 자체가 유일하게 흥미로운 부분임
AI에 과도하게 의존하는 주니어 개발자들은 나중에 기본기를 몰라서 대가를 치를 것임. 결국 경험 많은 사람에게만 일자리 안정성이 생김
“코드 작성은 어려운 부분이 아니었다”는 주장에는 동의하기 어려움. 물론 항상 어려운 건 아니지만, 시간 제약이 있을 때는 코드 작성이 병목이 됨. AI는 과거엔 불가능했던 시도를 가능하게 하고, 더 많은 엔지니어링 시간을 확보하게 함
“진지하게 받아들이기 어렵다”면서도 결국 동의하는 모순이 있음. 원문은 훨씬 더 세밀한 뉘앙스를 담고 있음
코드 작성은 가장 시간을 잡아먹는 작업이었고, AI는 그걸 강조함. 누구나 타이핑은 할 수 있지만, 코드를 읽는 능력이 진짜 실력임. 도끼 대신 전기톱을 쥔 나무꾼처럼, 효율은 높지만 피해도 커질 수 있음
AI는 좋은 엔지니어링도 쉽게 만들었음. 결국 행동 증폭기임
좋은 엔지니어는 더 잘할 수 있게 되었지만, 대부분은 property testing이 뭔지도 모름. 그런 사람들에게 AI가 얼마나 유용할지는 의문임
인터넷이 전 세계 지식을 연결했지만, 인간은 결국 잡담과 소모적 콘텐츠에 빠졌음. 인간 본성을 고려하면 AI도 비슷한 길을 갈 것임
창의적 문제는 직접 코드를 쓰는 과정에서 해결되는 경우가 많음. AI를 쓰면 그 두뇌 회로가 덜 활성화됨
Hacker News 의견들
나는 글의 전제에 동의하지 않음. 엔지니어링 전반이 쉬워졌다고 생각함, 좋은 쪽이든 나쁜 쪽이든. 예전에도 이해보다는 null 체크만 잔뜩 넣는 사람들을 많이 봤음. 지금은 그게 단지 대규모로 확장된 것뿐임. 반대로 뛰어난 엔지니어링은 더 증폭되어, 예전엔 몇 주 걸리던 기능을 며칠 만에 만드는 경우도 봤음
단위 테스트 백 개로도 코드의 정확성을 증명하기 어려운 경우가 있음. 대부분의 개발자는 무엇이 충분한지 모름. vibe coding을 많이 쓰는 사람들은 테스트조차 기계에 맡김. 시스템 설계 단계로 가면, 전체적인 안전성과 시간적 불변성을 보장할 수 있는 설계가 필요함. 하지만 대부분은 단순히 박스와 화살표를 그리며 “베스트 프랙티스”를 인용함. 소프트웨어는 자연과학에 더 가깝다는 Sussman 효과처럼, 관찰에 더 많은 시간을 쓰게 됨. GenAI를 도구로 쓰는 건 유용할 수 있지만, 사고를 멈추고 도구에 의존하는 건 위험함
몇 년마다 새로운 도구가 나올 때마다 “소프트웨어 엔지니어링의 어려운 부분이 해결됐다”는 말이 나옴. 생산성은 급등하고, 데모는 인상적이며, 업계는 스스로를 칭찬함. 하지만 곧 인력 감축이 뒤따름. 진짜 돌파구가 있다면 좋겠지만, 그 결과가 해고라면 의미가 없음. 결국 질문은 같음 — 일자리를 줄이는 게 목표라면, 사람들이 생계를 유지할 수 없을 때 기업의 비전은 무엇인가?
“코딩은 원래 어려운 부분이 아니었다”는 말에 동의함. 전문가들은 이미 무엇을 만들지 알고 있었고, 단지 반복 작업이 귀찮았을 뿐임
AI에 과도하게 의존하는 주니어 개발자들은 나중에 기본기를 몰라서 대가를 치를 것임. 결국 경험 많은 사람에게만 일자리 안정성이 생김
“코드 작성은 어려운 부분이 아니었다”는 주장에는 동의하기 어려움. 물론 항상 어려운 건 아니지만, 시간 제약이 있을 때는 코드 작성이 병목이 됨. AI는 과거엔 불가능했던 시도를 가능하게 하고, 더 많은 엔지니어링 시간을 확보하게 함
AI는 좋은 엔지니어링도 쉽게 만들었음. 결국 행동 증폭기임
나는 AI 회의론자지만, 동료들의 일자리를 빼앗는다고는 생각하지 않음. 대신 내 시간을 절약해줌. Google보다 나은 리서치 도구로 쓰고, 코드베이스 탐색, 헬퍼 함수 생성, 오류 검토에 유용함
요즘 소프트웨어 엔지니어링과 리서치의 구분이 뚜렷해지고 있음. AI는 탐색적 연구에선 놀라운 도구임. 가능성이 보이면 그때 SWE 모드로 전환해, 코드를 이해하고 수정하며 내 경험으로 다듬음. AI의 역할은 제한적이지만 여전히 유용함
이런 사람들(비관론자)이 포기할 때까지 모델이 몇 번 더 나와야 할까? 두 번? 세 번?