Python 3.15 정식 출시 - 지연 임포트, 불변 딕셔너리, UTF-8 기본 인코딩 도입

• 프로그래밍도 예술이며, 기능적인 결과물을 만든다는 이유로 다른 창작 분야와 달리 AI 사용을 정당화할 수는 없음
• 예술은 초월적인 작품에만 한정되지 않으며, 광고 문구와 일상적인 코드처럼 실용적인 창작 노동도 같은 기술과 연습을 바탕으로 함
• 비동기 처리 도구 Deferred는 반복적인 콜백 전달의 지루함과 불편함에서 탄생했으며, 코드의 미학과 사용 경험을 개선하려는 시도가 기술적 영향력으로 이어진 사례
• AI로 평범한 창작 업무를 없애면, 실무에서 연습하고 숙고하며 솜씨를 기를 기회와 뛰어난 결과물에 도달할 가능성도 사라짐
• 추상화와 자동화 자체가 문제가 아니라 이해와 창의적 의사결정을 없애는 것이 문제이며, 소프트웨어에서도 다른 창작 분야만큼 이에 저항할 가치가 있음

프로그래밍만 AI 사용의 예외가 될 수는 없음

• 창작 업계에서는 AI를 거부하고 보호 장치를 마련하려는 움직임이 이어짐
  • 작가들의 파업과 AI 보호 조항, 수천 명의 예술가가 서명한 항의 성명, 창작 업계의 저작권 소송 등이 대표적
  • 유튜버들의 비판 영상 여러 편과 음악가의 비판도 이어짐
• 프로그래머들은 AI가 가져온 업무 변화와 소진을 싫어하면서도 계속 사용하고 있음
• 그 배경에는 프로그래밍은 예술이 아니고, 기능적인 작업만 완수하면 된다는 생각이 있음
• 하지만 프로그래밍도 예술이므로, AI로 예술을 만들어서는 안 된다는 기준에서 예외가 아님

예술도 평범하고 실용적인 노동임

• 프로그램은 기능적이고 평범한 반면 예술은 표현적이고 초월적이라는 구분은 예술을 지나치게 신비화함
• John Berger의 《Ways of Seeing》는 이를 신비화, mystification라고 부름
  • 미술사가가 숭고한 작품처럼 묘사한 단체 초상화도, 실제로는 일감이 필요했던 가난한 노년 화가가 관리들의 의뢰를 받아 그린 작업
  • 아름답고 훌륭한 그림이지만 평범한 목적을 충실하게 달성한 의뢰 작업이지 신성한 유물은 아님
• 회화와 음악, 영화에도 장식, 오락, 기분 전환이라는 기능이 있음
• 작품의 미학과 문화적 의미를 탐구하는 것은 가치 있지만, 창작 과정 자체가 신비롭거나 다른 노동보다 숭배받아야 하는 것은 아님
• 소설가, 기자, 카피라이터 사이에도 초월적인 경계는 없음
  • 많은 기술을 공유하며, 직업의 차이는 상업적 조건과 기회에서 생김
  • 카피라이터로 일했던 유명 작가들처럼, 평범한 문구를 직업적으로 다루는 일도 예술적 글쓰기를 위한 연습이 됨

‘코드 시인’과 Deferred의 탄생

• Glyph는 십 대 후반 자신을 “코드 시인”이라고 소개했지만, 허세라는 조롱을 받고 이메일 서명과 소개에서 그 표현을 지움
• 코드와 시의 유사성에 대한 생각은 버리지 않았고, 대표적인 작업인 Deferred도 미학적인 불편함에서 출발
• RPC 클라이언트/서버에서 호출할 때마다 성공 처리용 callback과 오류 처리용 errback을 전달해야 했음
• 두 콜백은 기능적으로 충분했지만, 보기 좋지 않고 사용하기 번거로웠음
• Deferred는 이 문제를 비동기 작업 실행의 미학과 사용 경험을 고려해 다시 구성한 결과물
• 수많은 콜백 인자를 직접 전달하는 지루함을 겪지 않았다면, 이를 만들 기술도 동기도 생기지 않았을 것임

여러 사람이 이어 쓰는 소프트웨어의 미학

• 소프트웨어의 미학적 전통은 완성된 순수예술 작품보다 여러 사람이 이어 만드는 민속 서사시에 가까움
• Deferred의 영향은 MochiKit.Async, jQuery Deferred, JavaScript Promises, async/await로 이어졌고, 각 개발자가 무언가를 더하면서 최초 형태는 거의 사라짐
• Deferred 자체도 E 언어의 Promises 등에서 영향을 받았으므로 절대적인 출발점은 아님
• 대부분의 코드가 누군가를 울릴 만큼 감동적이지 않다고 해서 예술과 무관한 것은 아님
  • 대부분의 글은 광고 문구이고, 시각 예술의 상당 부분은 광고이며, 많은 라이브 공연은 술집의 배경음악
  • 평범한 창작에도 같은 기술과 미학적 판단이 쓰임

소프트웨어를 읽고 경험하는 문화

• Abelson의 말처럼, 프로그램을 기계뿐 아니라 사람이 읽는 표현물로 보는 전통이 있음
• Unix 철학, Python의 철학, Perl의 철학적 논의도 소프트웨어의 설계와 표현을 탐구하는 사례
• 미학적 경험은 소스 코드와 API에만 한정되지 않음
  • Federico Viticci의 Apple 운영체제 리뷰는 사용자 경험에 대한 미학적 비평이기도 함
  • 비디오게임 리뷰 역시 소프트웨어 리뷰
• 다만 소프트웨어 공동체에는 비판적으로 읽는 전통이 충분하지 않고, 문학적 프로그래밍, Literate Programming도 칭찬에 비해 실천은 드묾
• 사용자의 프로그래밍 문해력은 낮고, 일부 개발 관행은 실제 동작과 동떨어진 이해를 만들기도 함
• 이런 문제는 AI 이전부터 존재했지만, AI로 더 악화시킬 이유는 없음

평범한 작업을 지켜야 하는 이유

• 광고 문구, 그래픽 디자인, 맞춤형 WordPress 테마 같은 평범한 업무를 AI로 없애면 연습과 숙고를 통해 솜씨를 발전시킬 실무 기회도 사라짐
• 교육도 중요하지만, 실제 기술 발전의 상당 부분은 현장 업무에서 이루어짐
• 그렇다고 추상화와 자동화로 일을 쉽게 해서는 안 된다는 뜻은 아님
  • 프로그래밍은 작은 아이디어를 큰 아이디어로 조합하는 추상화의 예술
  • 작은 시스템의 규칙과 결합 방식을 이해하면서 더 큰 시스템의 자동화를 이해하는 작업
• AI가 이해를 더 높은 수준으로 끌어올리는 대신 없애고 창의적 의사결정을 파괴한다면, 프로그래머와 사용자, 그 결과물에 의존하는 다른 개발자 모두에게 해가 됨
• 자신의 창작물 대신 자동 생성한 빈약한 결과물을 제공하는 문제는 그림과 음악, 소프트웨어에서 다르지 않음

평범한 프로젝트에도 뛰어난 성취의 가능성이 있음

• 평범한 프로젝트 하나가 경력을 결정할 작품이 될 가능성은 매우 작을 수 있음
• 원문의 0.1%는 이를 설명하기 위한 가정한 수치
• 하지만 모든 프로젝트를 AI에 맡기는 습관은 실무에서 뛰어난 성취에 도달할 기회 자체를 없앰
• 어느 범위에서 어떤 AI 사용에 저항할지는 각자가 결정할 문제
• 소프트웨어에서도 다른 창작 매체만큼 저항할 가치가 있으며, 프로그래밍은 예외적인 활동이 아니라 인간의 보편적인 예술임