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