프로그래밍은 특별하지 않습니다

AI 요약

저자는 다른 창작 분야에서 AI 사용을 거부하는 목소리가 큰 반면, 프로그래밍에서는 불만을 느끼면서도 AI를 쓰는 개발자가 많다고 지적합니다. 그 배경에는 프로그램이 예술이 아니라 기능을 만드는 일이라는 생각이 있습니다. 하지만 저자는 프로그래밍도 예술이며, 그중 상당수는 일상적인 목적을 위해 만들어지는 실무 작업이라고 설명합니다.

일상적인 창작도 예술입니다

저자는 John Berger의 《Ways of Seeing》을 들어 예술을 신비화하는 태도를 짚습니다. Berger는 한 집단 초상화를 두고 ‘깊고 빛나는 검정의 미묘한 변화’, ‘조화로운 융합’ 같은 표현으로 찬사를 늘어놓은 미술사가를 비판합니다. 그림의 실제 배경은 생계를 위해 일감을 찾던 화가가 의뢰를 받아 관계자들의 초상화를 그렸다는 것입니다. 저자는 이 그림이 잘 만들어졌고 아름다울 수도 있지만, 평범한 목적에 맞춰 수행한 노동이라는 사실도 함께 봐야 한다고 말합니다.

이런 신비화는 순수미술과 소설에만 머물지 않습니다. 저자는 기자의 글이 소설가의 글보다 덜 존중받고, 카피라이터의 글은 그보다 더 낮게 평가되는 현실을 듭니다. 그러나 소설가와 카피라이터가 쓰는 기술은 상당 부분 겹칩니다. 글쓰기의 목적이나 상업적 조건이 다르다고 해서 창작의 성격까지 완전히 달라지는 것은 아닙니다. 평범한 글도 창작이며, 같은 논리를 프로그램에도 적용할 수 있다고 설명합니다.

코드의 미학과 Deferred

저자는 젊은 시절 자신을 ‘코드 시인’이라고 불렀다가 주변의 조롱을 받고 표현을 거둬들였지만, 코드와 시의 유사성에 대한 생각은 버리지 않았다고 말합니다. 그가 만든 Deferred는 원격 프로시저 호출(RPC)에서 매번 콜백과 에러백을 넘겨야 하는 지루함에 대한 미적 반응이었습니다. 기존 방식도 기능은 했지만 사용하기 번거롭고 보기 좋지 않았습니다. 저자는 Deferred를 비동기 작업 실행을 다룬 의도적인 ‘시’라고 설명합니다.

그는 이 작은 기여의 의미를 과장하지 않습니다. 다만 미적 고민이 기술의 다음 단계를 낳는 데 영향을 줬다고 봅니다. E 언어의 Promise에서 영향을 받은 아이디어는 MochiKit.Async, jQuery Deferred, JavaScript Promises를 거쳐 async/await로 이어지는 흐름에 보탬이 됐습니다. 여러 개발자가 각자의 기여를 더하면서 최초의 형태가 거의 녹아들었습니다. 저자는 이런 결과를 낳으려면 문제 영역을 오래 고민하고, 반복되는 불편을 직접 겪어야 한다고 말합니다.

대부분의 코드는 사람을 울릴 만큼 아름답지 않습니다. 저자는 이를 카피라이팅에 빗댑니다. 대부분의 글이 일상적인 목적을 위해 쓰이듯, 대부분의 코드도 실무를 처리합니다. 그러나 일부러 미학을 고려해 만든 코드는 문화와 기술에 영향을 줄 수 있습니다. Abelson의 말처럼 프로그램은 기계가 실행하기에 앞서 사람이 읽도록 작성해야 한다는 관점도 소개합니다. 소프트웨어의 미적 경험은 소스 코드를 읽는 개발자에게만 한정되지 않습니다. 운영체제 리뷰와 비디오게임 리뷰 역시 소프트웨어가 사용자에게 주는 미적 경험을 다룹니다.

평범한 프로젝트를 지켜야 하는 이유

저자는 소프트웨어 공동체에 비평적으로 코드를 읽는 전통이 약하고, 사용자는 소프트웨어가 어떻게 만들어지는지 잘 모른다고 우려합니다. 현대적인 개발 관행이 사용자가 내부 동작을 이해하기 어려운 정신 모형을 만들기도 한다고 덧붙입니다. 이런 문제는 AI 이전부터 있었지만, AI를 적극적으로 쓰며 더 악화시킬 이유는 없다는 주장입니다.

AI가 카피라이팅, 그래픽 디자인, 지루한 예술 작업, 맞춤형 WordPress 테마 개발까지 없애면 사람들이 실력을 연습하고 숙고할 기회도 줄어듭니다. 교육만으로 숙련이 완성되지는 않습니다. 저자는 실제 일에서 기술을 익히는 과정이 큰 몫을 한다고 말합니다. 추상화와 자동화 자체를 거부하자는 뜻은 아닙니다. 작은 규칙을 이해하고 조합해 더 큰 시스템을 다루는 것이 프로그래밍입니다. AI가 이해를 높이는 대신 창작 과정의 판단을 없애면 개발자와 사용자 모두에게 해가 된다고 주장합니다.

저자는 평범한 프로젝트 하나가 뛰어난 성과로 이어질 가능성을 0.1%라고 가정합니다. 프로젝트 하나에 AI를 썼다고 그 가능성이 크게 달라지지는 않겠지만, 모든 프로젝트를 AI에 맡기는 습관이 자리 잡으면 그런 성과가 나올 기회도 사라진다고 말합니다. 어떤 사용을 거부할지는 각자 판단할 문제지만, 프로그래밍도 다른 창작 분야처럼 AI의 확산에 저항할 이유가 있다고 글을 맺습니다.

Lobsters 반응

• @toastal — ‘코드는 아름다울 수 있다’거나 스스로를 ‘코드 시인’이라고 부른다는 대목에 공감합니다. 인터뷰에서 예술가라는 넓은 범주의 사람들이 예술은 의미를 가지려면 인간에게서 나와야 하지만, 코드는 AI가 잘한다고 말하는 걸 들으면 서글픕니다. 프로그래머와 예술가가 같은 범주에 있다고 느낄 때가 있습니다. 함수형 프로그래밍에 빠지고 비슷한 주제를 파고든 뒤라서 그런지도 모르겠습니다.
• @cblake — 현대 컴퓨팅의 태동기, 이를테면 트랜지스터 기반 컴퓨터가 쓰이던 1960년대에 Don Knuth는 책 제목을 말 그대로 《The Art of Computer Programming》이라고 붙였습니다. 저는 지금도 그 책들을 좋아합니다. 하지만 소프트웨어 개발자들은 수십 년 동안 그 책에서 다룬 주제를 대부분 블랙박스 라이브러리에 맡겨 왔습니다. 무엇을 블랙박스로 두고 무엇을 직접 다룰지 정하는 문제는 분야 내내 이어진 긴장이었습니다.

원문: Glyph 블로그 / 번역·요약: Trawling