# AI는 소프트웨어 엔지니어링을 단순화하지 않았다: 나쁜 엔지니어링을 더 쉽게 만들었을 뿐

> Clean Markdown view of GeekNews topic #27510. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=27510](https://news.hada.io/topic?id=27510)
- GeekNews Markdown: [https://news.hada.io/topic/27510.md](https://news.hada.io/topic/27510.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2026-03-15T07:02:02+09:00
- Updated: 2026-03-15T07:02:02+09:00
- Original source: [robenglander.com](https://robenglander.com/writing/ai-did-not-simplify/)
- Points: 19
- Comments: 1

## Summary

**LLM의 등장은 코드 작성 속도를 높였지만, 소프트웨어 엔지니어링의 복잡성을 단순화하지는 못했습니다.** 오히려 코드 생성이 쉬워지면서 명세·테스트·구현 간의 **정렬(alignment)** 이 빠르게 무너지고, 시스템 신뢰성이 약화되는 현상이 가속되고 있습니다. 진짜 어려움은 코드를 쓰는 것이 아니라 시스템을 설계하고 일관성을 유지하는 일이며, LLM은 이 규율을 대체하는 도구가 아니라 강화해야 할 대상으로 다뤄져야 합니다.

## Topic Body

- **LLM** 은 코드 작성 속도를 높였지만, **소프트웨어 엔지니어링의 본질적 복잡성**을 줄이지 못함  
- 코드 생성이 쉬워지면서 **전문성의 필요성이 사라졌다는 착각**이 확산되고 있으며, 일부 조직은 이를 근거로 엔지니어를 감축 중임  
- 실제 어려움은 코드 작성이 아니라 **시스템 설계, 명세, 검증, 일관성 유지**에 있으며, AI는 이 영역의 부담을 오히려 가속함  
- **명세(specification), 테스트, 구현 간의 불일치(spec drift)** 가 빠르게 심화되어 시스템 신뢰성이 무너질 위험이 커짐  
- 40년 이상의 경력에서 반복적으로 관찰된 패턴으로, 1990년대 Visual Basic 시절에도 동일한 **"전문성 불필요" 주장**이 등장했다가 결국 엔지니어링 규율의 필요성이 재확인됨  
- LLM은 설계 탐색과 초기 구현 가속에 뛰어난 도구이지만, **엔지니어링 규율을 대체하는 것이 아니라 강화하는 방향**으로 사용해야 함   
  
---  
  
### 업계의 위험한 착각  
- LLM이 코드를 생성할 수 있게 되자, 소프트웨어 업계는 **소프트웨어 엔지니어링 자체가 더 이상 필요 없다**고 결론짓는 분위기  
- 아키텍처, 명세, 신중한 검증 같은 규율이 마치 구시대의 유물인 것처럼 취급되는 상황  
- 일부 조직에서는 이미 이 아이디어가 **정책에 반영**되어, AI 발전을 이유로 엔지니어를 대규모 해고하는 사례 발생  
- AI는 **잘못된 비즈니스 결정이나 시장 압력을 회피하기 위한 최신 핑계**에 불과  
- AI에 프롬프트를 입력하는 것이 소프트웨어 엔지니어링을 정의하던 규율을 대체하는 것으로 점점 포장되고 있음  
  
### 반복되는 역사적 패턴  
- 40년 이상의 경력에서 동일한 패턴이 반복적으로 관찰됨: 새로운 도구 등장 → 어려운 문제가 해결됐다는 선언 → 생산성 급증과 인상적 데모 → **인력 감축** → 시스템 복잡성 증가 → 결국 기대와 다른 결과  
- 도구와 주장은 바뀌지만 **패턴 자체는 거의 변하지 않음**  
  
### 항공기 정비 비유  
- 항공기 정비 분야는 도구 개선, **컴퓨터 진단**, 디지털 매뉴얼, AI 텔레메트리 해석 등 큰 발전을 이뤘지만, 숙련된 정비사의 필요성은 여전  
- 상용 항공기는 수백만 개의 부품과 수천 개의 상호 연결된 서브시스템을 포함하는 **극도로 복잡한 시스템**  
- 문제 진단은 올바른 도구나 체크리스트 따르기가 아니라, 실제 운용 조건에서 시스템이 어떻게 동작하는지에 대한 **경험과 판단력** 필요  
- 어떤 항공사도 도구 개선을 이유로 훈련된 정비사를 없애고 **게이트 에이전트에게 수리를 맡기겠다고 제안하지 않음**  
- 그런데 소프트웨어 업계는 바로 그와 매우 유사한 주장을 자기 자신에 대해 하고 있는 상황  
  
### DIY vs 전문 시스템  
- 취미 프로젝트, 개인용 소규모 앱, 새로운 아이디어 실험은 전혀 문제가 아니며, 컴퓨팅 역사상 가장 흥미로운 아이디어들이 이런 실험에서 탄생  
- 그러나 **전문 소프트웨어 개발은 완전히 다른 범주**: 결제 처리, 민감 정보 저장, 인프라 관리, 사람들이 매일 의존하는 시스템 운영  
- 고객은 시스템이 올바르게 동작하고, 진화하면서도 올바름을 유지하며, 빌드하는 사람들이 시스템 작동 방식을 이해하고 있다고 **당연히 기대**  
- 이러한 기대는 **전문 엔지니어링의 기본 조건**이며, 규율과 전문성이 불가피한 지점  
  
### 코드는 결코 어려운 부분이 아니었음  
- 소프트웨어 개발에서 코드 작성이 어려운 부분이라는 것은 **오래된 오해**  
- 구문(syntax)을 타이핑하는 것은 항상 시스템 구축에서 가장 덜 흥미로운 부분이었으며, 진짜 어려운 작업은 시스템 동작 결정, 컴포넌트 상호작용 설계, **복잡성 증가에 따른 이해 가능성 유지**  
- 이는 코딩 문제가 아닌 **엔지니어링 문제**  
- 코드 생산 노력 감소는 이 문제들을 제거하지 않으며, 단지 더 크고 복잡한 시스템을 더 빠르게 만들 수 있게 할 뿐  
- 이것이 생산성 향상이라는 것은 **착각**: 부담이 다른 곳으로 이동한 것  
  - 코드 리뷰와 생성된 코드를 다루는 데 필요한 **인지 부하**가 코드 작성보다 더 큰 생산성 저하 요인  
  - 기저 동작이 충분히 이해되지 않은 상태에서 속도만 빨라지면, 복잡성이 감당 불가능해지는 시점을 **가속화**할 뿐이고 결과물도 틀림  
  
### 이미 본 패턴: Visual Basic 시대  
- 1990년대 **Visual Basic**에 대해서도 유사한 약속 존재: 프로그래밍이 민주화되었고 전문 지식이 불필요해졌다는 주장  
- 실제로 Visual Basic은 그렇지 않았으면 만들어지지 않았을 많은 애플리케이션을 가능하게 한 면이 있음  
- 그러나 시스템이 커지고 상호 연결되면서, **소프트웨어 산출물 생산과 신뢰할 수 있는 시스템 엔지니어링은 같은 것이 아님**이 재발견됨  
- 현재는 동일한 패턴의 **증폭된 버전**: 애플리케이션 구축 장벽이 아니라 코드 생산 자체의 장벽을 낮춘 것  
- 여기서 **전문성이 더 이상 필요 없다는 유혹적 믿음** 탄생  
  
### 정렬(Alignment) 문제  
- 신뢰할 수 있는 소프트웨어는 엔지니어링 외부에서 거의 논의되지 않는 **정렬(alignment)** 에 의존  
- 시스템은 동작에 대한 아이디어에서 시작 → **명세(specification)** 로 문서화 → 엔지니어가 명세를 테스트와 프로덕션 코드로 변환  
- 시스템의 장기적 신뢰성을 위해 명세, 테스트, 구현 세 가지가 **항상 정렬 상태를 유지**해야 함  
- 세 가지가 어긋나기 시작하면 시스템은 서서히 무결성을 잃음  
  - 명세는 더 이상 구현되지 않는 동작을 기술  
  - 테스트는 동작의 일부만 검증하고 나머지는 누락  
  - 나중에 합류한 엔지니어는 원래 설계를 반영할 수도 반영하지 않을 수도 있는 코드를 읽으며 시스템 동작을 **추측**  
- 시간이 지나면서 추측이 누적되고, 결국 **아무도 진정으로 이해하지 못하는 시스템**이 됨  
- 이 현상을 **"스펙 드리프트(spec drift)"** 로 명명: 시스템 설명과 시스템 자체가 점진적으로 괴리  
  - 코드는 변경되었는데 명세는 그대로  
  - 명세는 진화했는데 테스트는 고정  
  - 동작이 점진적으로 변화하여 원래 의도가 무엇이었는지 아무도 확신 불가  
- 정렬이 깨지면 **신뢰성은 오래 유지되지 못함**  
  
### AI가 드리프트를 가속화  
- LLM은 코드 생산을 극적으로 가속화하며, 이것이 최대 강점이자 **위험이 나타나는 지점**  
- 코드가 그를 둘러싼 엔지니어링 규율보다 빠르게 생산될 때, 스펙 드리프트를 만드는 힘이 가속  
- 한때 신중한 사고와 수동 구현이 필요했던 변경이 이제 **몇 초 만에** 가능  
- 시스템의 전체 섹션이 동작이 여전히 명세에 부합하는지 아무도 확인하기 전에 **재작성 가능**  
- 코드는 대체로 합리적으로 보이고, 컴파일되고, 잘 읽히며, 기존 테스트를 통과할 수도 있지만, 시스템을 지배하던 **정렬은 이미 사라진 상태**일 수 있음  
- 생산성으로 보이는 것이 실은 이전보다 빠르게 **오정렬(misalignment) 방향으로 이동하는 능력**  
  
### AI가 실제로 도움이 되는 영역  
- LLM은 실수가 아니며, 사려 깊게 사용하면 엔지니어가 시스템을 탐색하고 설계하는 방식을 극적으로 개선 가능  
- 특히 뛰어난 영역: **문제에 대한 추론**, 설계 대안 탐색, 복잡한 시스템 요약, 구현 초기 단계를 가속화하는 초안 생성  
- 어려운 영역: 시간에 걸친 **엄격한 규율과 일관성**이 요구되는 분야  
- 명세, 테스트, 구현 간의 정렬 유지는 여전히 **엔지니어링 책임**이며, 어떤 도구도 이 책임을 대체할 수 없음(지원은 가능)  
- 진정한 기회는 LLM을 엔지니어링 프로세스를 조용히 대체하는 것이 아니라 **강화하는 방향**으로 사용하는 것  
  
### 대화형 소프트웨어 엔지니어링  
- LLM이 열어준 흥미로운 가능성 중 하나: 소프트웨어 엔지니어링의 일부가 더 **대화형(conversational)** 이 될 수 있음  
- 수십 년간 시스템 설계 도구는 경직되어 있었음: 명세는 문서, 아키텍처는 다이어그램, 그에 이르는 추론은 회의와 복도 대화 속으로 사라짐  
- LLM으로 엔지니어는 **아이디어를 인터랙티브하게 탐색**하고, 가정을 테스트하며, 자연스러운 대화에 가까운 방식으로 설계 작업 가능  
- 그러나 **대화는 엔지니어링이 아님**: 대화는 아이디어 탐색 방식이고, 엔지니어링은 아이디어가 검증·테스트·유지 관리 가능한 형태로 포착될 때 시작  
- 다음 세대 엔지니어링 도구의 과제는 복잡한 시스템이 요구하는 규율을 잃지 않으면서 **이 두 세계를 연결하는 방법**을 학습하는 것  
  
### 전문성은 여전히 중요함  
- 전문 소프트웨어는 자신이 구축하는 시스템의 실제 작동 방식을 이해하는 **엔지니어가 여전히 필요**  
- 도구는 개발을 가속화할 수 있지만, 복잡한 시스템을 설계·추론·유지하는 데 필요한 **전문성을 제거하지 못함**  
- 업계가 이 사실을 잊어버리기에 **위험할 정도로 가까운** 상황  
- LLM은 경험 있는 엔지니어를 훨씬 더 생산적으로 만들 수 있지만, 신뢰할 수 있는 시스템 구축에 필요한 **엔지니어링 규율을 대체하지 않음**  
- 이 도구들을 **숭배가 아닌 효과적으로** 사용해야 함

## Comments



### Comment 53030

- Author: neo
- Created: 2026-03-15T07:02:02+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47377262) 
- 나는 글의 전제에 동의하지 않음. **엔지니어링 전반**이 쉬워졌다고 생각함, 좋은 쪽이든 나쁜 쪽이든. 예전에도 이해보다는 **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를 쓰면 그 **두뇌 회로**가 덜 활성화됨
  - [DORA 리포트](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report) 같은 데이터도 이걸 뒷받침함
  - “AI는 기존 행동의 증폭기”라는 문장은 정말 적절함. 그대로 써야겠음

- 나는 **AI 회의론자**지만, 동료들의 일자리를 빼앗는다고는 생각하지 않음. 대신 내 시간을 절약해줌. Google보다 나은 **리서치 도구**로 쓰고, 코드베이스 탐색, 헬퍼 함수 생성, 오류 검토에 유용함
  - 나도 동의함. 이런 방식이 결국 **AI 활용의 종착점**이라고 생각함

- 요즘 **소프트웨어 엔지니어링**과 **리서치**의 구분이 뚜렷해지고 있음. AI는 탐색적 연구에선 놀라운 도구임. 가능성이 보이면 그때 SWE 모드로 전환해, 코드를 이해하고 수정하며 내 경험으로 다듬음. AI의 역할은 제한적이지만 여전히 유용함
  - LLM은 인간보다 훨씬 넓은 **지식 폭**을 즉시 탐색할 수 있음. 하지만 최종 판단은 인간의 **취향과 품질 감각**에 달려 있음

- 이런 사람들(비관론자)이 **포기할 때까지** 모델이 몇 번 더 나와야 할까? 두 번? 세 번?