Python은 죽지 않을 것이다. 가장 큰 장점이 바뀔 수도 있다.

AI가 코드를 작성한다면, '쓰기 쉬움'은 프로그래밍 언어를 선택하는 이상한 이유가 될 수 있습니다.

개발자들을 짜증 나게 할 예측을 하나 해보겠습니다. 우리는 더 이상 사람이 직접 타이핑하는 사람의 편의성 때문에 프로그래밍 언어를 선택하는 시대를 끝내가고 있을지도 모릅니다.

수년 동안, 우리는 적은 노력으로 더 많은 것을 표현할 수 있게 해주는 언어들을 찬양해 왔습니다. 더 깔끔한 구문(syntax). 적은 보일러플레이트(boilerplate). 더 빠른 프로토타입 제작. 기억해야 할 것의 감소.

이러한 장점들은 아이디어를 코드로 구현하는 과정에서 우리의 주의력이 큰 부분을 차지했을 때 중요했습니다.

하지만 AI가 그 번역 작업의 상당 부분을 처리한다면 어떻게 될까요?

기계가 상세한 버전(verbose version)을 생성할 수 있다면, 짧은 버전을 작성하는 편리함은 가치를 일부 잃게 됩니다.

이것이 Python이 죽는다는 의미는 아닙니다. 이것은 'Python이 쓰기 쉽다'는 주장이 훨씬 약해질 수 있다는 것을 의미합니다.

가장 좋아하는 구문(syntax)이 어제의 문제를 해결할 수도 있다

두 언어 중 하나를 선택한다고 상상해 보세요.

하나는 작성하기에는 좋지만, 프로그램 실행 중에 발견해야 할 오류가 더 많이 남겨집니다. 다른 하나는 더 명시적인 구조(explicit structure)를 요구하지만, 배포 전에 더 많은 오류를 잡아냅니다.

사람이 모든 줄을 직접 작성할 때는 그 추가적인 구조가 비용이 많이 드는 것처럼 느껴질 수 있습니다.

하지만 AI가 초안을 생성할 때, 계산은 달라집니다.

어쩌면 보일러플레이트가 가정을 눈에 보이게 만든다면 환영해야 할지도 모릅니다. 어쩌면 컴파일러가 당황스러운 질문을 하는 것이, 기계가 우리가 검토하는 것보다 더 빨리 그럴듯한 코드를 생성할 수 있을 때 우리에게 정확히 필요한 일일지도 모릅니다.

그런 미래에는, 잘못된 코드를 받아들이기 가장 어렵게 만드는 언어가 승리할 수 있습니다. 가장 편리하게 느껴지는 키보드의 언어는, 생성된 소프트웨어에 가장 빡빡한 경계(tightest boundaries)를 제공하는 언어에게 패배할 수도 있습니다.

코드는 싸지고 있다. 자신감은 그렇지 않다.

이 주장의 도발적인 버전은 개발자들이 AI가 변화시키고 있는 비용 모델을 사용하여 자신이 좋아하는 언어를 방어하고 있다는 것입니다.

우리는 여전히 묻습니다:

'이것을 얼마나 빨리 작성할 수 있을까?'

더 유용한 질문은 다음과 같아질 수 있습니다:

“이것이 작동한다는 것을 얼마나 저렴하게 확립하고, 계속해서 작동하도록 유지할 수 있을까?”

그러한 질문들은 서로 다른 우선순위를 이끌어냅니다.

간결한 구현은 그 동작을 검토하는 데 시간이 더 오래 걸린다면 덜 인상적입니다. 아름다운 추상화는 의존성이 실패했을 때 무슨 일이 일어나는지 아무도 설명할 수 없다면 덜 도움이 됩니다. 작동하는 시연(demo)은 다음으로 생성된 변경 사항이 가정(assumption)을 조용히 깨뜨리면 거의 의미가 없습니다.

문자를 적게 입력하는 것이 그러한 문제들을 해결하지 못합니다.

더 많은 문자를 생성하는 것도 마찬가지입니다.

Python은 “쉽다”는 것보다 더 나은 방어가 필요하다

Python이 명백한 목표가 되는 이유는 그 접근성(accessibility)이 매력의 매우 두드러진 부분이기 때문입니다.

하지만 이를 일축하는 것은 게으른 태도일 것입니다. 라이브러리, 기존 시스템, 통합 요구 사항, 그리고 프로젝트를 유지 관리하는 사람들이 모두 중요합니다. 다른 언어가 종이에 더 보기 좋다고 해서 작동하는 생태계(ecosystem)를 대체하는 것은 비싼 실수가 될 수 있습니다.

과제는 더 좁고—더 불편합니다:

만약 Python에 대한 당신의 가장 강력한 주장이 코드를 작성하는 동안 인간의 노력을 절약한다는 것이라면, AI가 상당 부분 작성을 할 때 그 주장은 얼마나 강할까요?

생태계를 방어하십시오. 당신의 작업 부하(workload)에 적합하다는 점을 방어하십시오. 팀이 문제를 조사하고 해결할 수 있는 속도를 방어하십시오.

하지만 “이것 보세요, 몇 줄밖에 안 걸려요”라는 주장은 논쟁에서 승리하는 것을 멈출 수도 있습니다.

불편한 반론: 인간은 여전히 그것을 읽어야 한다

여기서 예측이 무너질 수 있습니다.

만약 AI가 코드를 풍부하게 만든다면, 읽기 쉬운 코드(readable code)가 더 가치 있어질 수 있습니다. 누군가는 여전히 사고(incident)를 조사하고, 가정을 의심하며, 변경 사항을 승인해야 합니다.

이해하기 쉬운 언어는 작성하기 쉬운 것보다 중요할 때도 있지만, AI 감독의 비용을 줄일 수 있습니다.

그 구분이 매우 중요합니다.

작성하기 쉽다는 것이 검증하기 쉽다는 것과 같지는 않다.

때로는 그들이 겹치기도 합니다. 때로는 짧은 표현이 리뷰어의 작업을 더 어렵게 만들 만큼 충분한 동작을 숨기기도 합니다.

미래는 인간의 가독성을 보상할 수도 있습니다. 다만 그 가독성이 다른 종류일 수 있습니다. 명시적인 계약(explicit contracts), 눈에 보이는 효과(visible effects), 예측 가능한 동작(predictable behaviour), 그리고 적은 놀라움이 그것입니다.

프로그래밍 언어가 사라지는 것은 아닙니다. 우리가 언어를 선택하는 이유를 업데이트할 필요가 있습니다.

저는 AI가 언어 간의 경쟁 구도를 바꿀 것이라고 예상합니다.

키스트로크(keystrokes) 절약에 대한 강조는 줄어들 것입니다. 실수 포착에 대한 강조가 높아질 것입니다.

작은 구현체에 대한 감탄은 줄어들 것입니다. 그것이 무엇을 보장하는지에 대한 검토가 더 많아질 것입니다.

편안하게 느껴지는 것에 대한 충성심은 줄어들 것입니다. 시스템을 실행하고, 검토하고, 변경하는 비용에 대한 관심이 높아질 것입니다.

하나의 만능 승자는 없을 것입니다. 데이터 실험, 모바일 앱, 결제 서비스는 각기 다른 제약 조건을 가집니다.

하지만 자신의 언어 선호도를 재고하기를 거부하는 개발자들은 더 이상 큰 비용을 발생시키지 않는 직무의 일부를 최적화하고 있는 자신을 발견할 수도 있습니다.

만약 AI가 당신의 다음 10,000줄을 작성한다면, 생성하기 가장 쉬운 언어를 선택하시겠습니까—아니면 틀리게 만들기 가장 어려운 언어를 선택하시겠습니까?

이것은 예측일 뿐, 벤치마크는 아닙니다. 저는 이 주장에 도전하는 반례에 관심이 있습니다.

AI 공개: 저는 AI와의 대화를 통해 이 논거를 발전시켰으며, AI가 이 글의 초안 작성과 구조화에 도움을 주었습니다.