AI 코딩 시대, 개발자의 역할은 어떻게 변해야 할까?

by DD
1주 전
조회수 0

AI 코딩 도구의 발전으로 코드 생성 비용이 급격히 저렴해졌음

코드 생성보다 코드 이해의 중요성이 더욱 커지고 있음

LLM의 비결정성(Non-determinism)복잡성 증가 위험성을 경고함

빼기 엔지니어링(Subtractive Engineering)을 통해 복잡성을 관리해야 함

AI 코드 생성의 비결정성과 위험성

커뮤니티에서는 AI가 생성하는 코드의 비결정성(Non-determinism)을 컴파일러와 명확히 구분해야 한다고 지적합니다. LLM은 의도적으로 예측 불가능한 결과를 생성할 수 있으며, 이는 소스 코드 추적(Source Code Traceability)을 어렵게 만듭니다. 또한, AI는 기하급수적인 복잡성(Geometric/Exponential Complexity)에 대한 두려움이 없어 대규모 코드베이스에서 통제 불가능한 복잡성(Uncontrollable Complexity)을 야기할 위험이 있다고 언급됩니다.

코드 이해 비용의 증가

글쓴이는 AI가 생성한 방대한 양의 코드를 이해하는 데 드는 비용이 증가했다고 주장합니다. 코드가 프로그래머의 손을 거치지 않고 생성되므로, 코드 작성 후 리딩(Reading)을 통해 이해해야 하는 상황이 발생합니다. 이는 기존의 '자신의 코드를 작성하는 것보다 남의 코드를 읽는 것이 더 어렵다'는 통념을 더욱 심화시키며, 특히 미션 크리티컬 소프트웨어(Mission-Critical Software)에서는 LLM 생성 코드라도 반드시 이해가 선행되어야 한다고 강조합니다.

'마법사 견습생' 함정과 '빼기 엔지니어링'

AI의 무분별한 코드 생성을 디즈니 애니메이션 '마법사의 제자(The Sorcerer's Apprentice)'에 비유하며 경고합니다. 여기서 개발자는 마법사(Sorcerer)로서 AI를 통제하고 이해해야 하며, 단순히 견습생(Apprentice)처럼 마법(AI)에 휘둘려서는 안 된다고 말합니다. 이를 해결하기 위한 방안으로, 생성된 코드를 면밀히 검토하고 불필요한 코드를 제거하며 시스템을 단순화하는 '빼기 엔지니어링(Subtractive Engineering)'을 제안합니다.

시스템 설계에서의 '빼기' 마인드셋

과거 개발자들이 코드 작성 능력에 자부심을 느꼈다면, 이제는 제거하거나 방지한 코드의 양에 자부심을 느껴야 한다고 주장합니다. 이는 조각가와 빌더의 차이에 비유됩니다. 시스템 설계 레벨에서도 불필요한 컴포넌트와 경계를 제거하여 배포 및 상호작용을 단순화하는 '빼기' 접근 방식이 유용할 것이라고 설명합니다. 이러한 태도는 AI 시대의 복잡성을 관리하고 프로그래밍의 본질을 유지하는 데 기여할 것이라고 덧붙입니다.

Code is Cheap(er)