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

• 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은 경험 있는 엔지니어를 훨씬 더 생산적으로 만들 수 있지만, 신뢰할 수 있는 시스템 구축에 필요한 엔지니어링 규율을 대체하지 않음
• 이 도구들을 숭배가 아닌 효과적으로 사용해야 함

[GN⁺]

Hacker News 의견들

• 나는 글의 전제에 동의하지 않음. 엔지니어링 전반이 쉬워졌다고 생각함, 좋은 쪽이든 나쁜 쪽이든. 예전에도 이해보다는 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 리포트 같은 데이터도 이걸 뒷받침함
  • “AI는 기존 행동의 증폭기”라는 문장은 정말 적절함. 그대로 써야겠음

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

  • 나도 동의함. 이런 방식이 결국 AI 활용의 종착점이라고 생각함

• 요즘 소프트웨어 엔지니어링과 리서치의 구분이 뚜렷해지고 있음. AI는 탐색적 연구에선 놀라운 도구임. 가능성이 보이면 그때 SWE 모드로 전환해, 코드를 이해하고 수정하며 내 경험으로 다듬음. AI의 역할은 제한적이지만 여전히 유용함

  • LLM은 인간보다 훨씬 넓은 지식 폭을 즉시 탐색할 수 있음. 하지만 최종 판단은 인간의 취향과 품질 감각에 달려 있음

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