코드는 더 싸졌다

1 hour ago 1

AI 코딩 도구 확산으로 코드 작성 비용은 급격히 낮아졌지만, 정작 생성된 코드를 이해하는 비용은 더 커진 현실
LLM은 비결정적이고 원본 소스를 보존하지 않으며 출력 범위가 일반 소프트웨어 전체로 넓어, 컴파일러 출력과 동일시할 수 없음
LLM은 사람이 이해할 수 있는 속도보다 훨씬 빠르게 코드를 생성하므로, 아무도 이해 못 하는 대규모 변경을 막기 위한 점진적(incremental) 사용 권장
코드가 저렴해질 때의 핵심 위험은 복잡성(complexity) 이며, 시스템 규모에 따라 최소 기하급수적으로 증가하는 반면 LLM은 복잡성에 대한 두려움이 없는 다작 코더
해법으로 코드를 더하기보다 제거·단순화하는 빼는 엔지니어(subtractive engineer) 를 제시하며, 컴퓨터 프로그래밍의 기예 유지 강조

코드가 저렴해진 시대

코드가 프로그래머의 손에서 힘겹게 나오는 대신 대량 생성될 때, 그 코드에 대한 이해 자체가 존재하지 않음
- 이해가 필요하다면 코드 작성 이후 코드를 읽어서 확보해야 함
- 통념상 남이 쓴 코드를 읽는 것은 자기 코드를 쓰는 것보다 더 어려움
"컴파일러 출력도 이해하지 못하지 않느냐"는 AI 옹호론을 범주 오류(category error) 로 규정
- 컴파일러는 결정적이지만 LLM은 설계상 비결정적
- 컴파일러 워크플로는 원본 소스 코드를 보존하지만 LLM 워크플로는 대개 보존하지 않음
- 컴파일러 출력은 기계어라는 좁은 도메인에 한정되지만 LLM 출력은 일반화된 소프트웨어로 한정되지 않음
대부분의 경우, 특히 미션 크리티컬 소프트웨어에서는 LLM 생성 코드라도 개발자가 기저 코드를 이해해야 함
LLM은 누구도 따라잡지 못할 속도로 코드를 생산할 수 있어, 이해 속도를 추월하는 위험 존재
- 따라서 거대한 변경 목록을 한꺼번에 생성하기보다 점진적 사용 권장
- 기계적 리팩토링에는 적절할 수 있으나, 코드베이스에 새로운 의미(semantics)를 도입할 때는 극히 위험

Disney 영화 Fantasia 의 "The Sorcerer's Apprentice" 장면을 AI 시대의 적절한 비유로 제시
- 제자가 청소의 고역을 덜려고 빗자루에 마법을 걸자, 빗자루가 점점 격렬하게 청소하며 상황이 통제 불능에 빠짐
- 결국 마법사(Sorcerer)가 다시 나타나 상황을 장악하고 제자의 어리석음을 질책하며 혼란 수습
이 비유의 교훈은 제자가 아니라 마법사가 되어야 함이며, 마법사는 코드를 이해해야 함

인간은 기하급수·지수 곡선을 잘 파악하지 못하며, 복리(compound interest) 같은 것을 동화처럼 믿음
코드가 저렴해질 때의 핵심 위험은 복잡성(complexity) 이며, 시스템 규모에 따라 최소 기하급수적, 종종 지수적으로 증가한다고 (증명 없이) 주장
LLM 이전에도 다작 코더(prolific coder) 가 존재
- 복잡성에 대한 두려움이 없는 다작 코더는 기존 문제 위에 코드를 계속 쌓아, 어떤 변경이든 고치는 만큼 버그를 만드는 수정 불가능한 정체 상태로 시스템을 붕괴시킴
LLM은 복잡성에 대한 두려움이 없으면서 동시에 다작 코더이므로 위험

LLM 생성 코드의 위험에 대응하기 위해 빼는·제약하는 엔지니어(subtractive, constraining engineer) 제안
- 이 엔지니어는 "아니오"라고 말하고, LLM 출력을 면밀히 검토하며, 단순화를 제안하고, 단호하게 통제력 유지
- 자신이 만든 코드가 아니라 시스템에서 제거하거나 진입을 막은 코드(및 레이어) 에 자부심을 둠
- 이 태도는 건축가(builder)보다 조각가(sculptor) 에 가까움
건축가(builder)적 태도는 시스템 설계 수준에서 여전히 유효
- 좋은 엔지니어는 컴포넌트를 효과적으로 조합해 시스템을 구성할 줄 알아야 함
- 다만 이 수준에서도 불필요한 컴포넌트와 시스템 경계를 제거해 배포·상호작용을 단순화하는 빼는 사고방식이 유용
빼는 엔지니어는 과거 대다수 코더와 다른 유형이며, "아니오" 말하기와 영웅적 재작성 대신 기존 시스템 다듬기를 선호하는 태도와 친화적
이 접근은 코드는 저렴해졌고 복잡성은 여전히 최상위 포식자(apex predator) 라는 이중 현실을 인정하며, 컴퓨터 프로그래밍의 기예를 지키는 생산적 방식