Uncomputable Introduction 북리뷰

<Uncomputable 계산할 수 없는>^[1] 서문 발췌 (Gemini 번역)

이 책은 계산 가능한 것과 계산 불가능한 것에 관한 것입니다. 일반적인 이론 대신 일련의 역사적 에피소드를 이야기합니다. 이 이야기들은 광범위하게 생각되는 계산 및 디지털 미디어 아카이브에서 가져온 것입니다. 목표는 계산이 어떻게 나타나거나 나타나지 않는지 , 디지털이 어떻게 번성하지만 또한 위축되는지, 네트워크가 어떻게 상호 연결되면서도 닳고 해체되는지를 보여주는 것입니다.

이러한 교대, 즉 어떤 것은 실행되고 어떤 것은 실행되지 않으며, 어떤 것은 계산되고 어떤 것은 계산되지 않는다는 것은 사이버네틱스와 네트워크에서부터 셀룰러 오토마타 등에 이르는 디지털 기계의 실제 역사를 구성합니다. 그리고 컴퓨터는 최근 몇 년 동안 전 세계를 장악했지만, 다양한 배제 관행에도 탁월합니다. 배제된 용어는 '직관'일 수도 있고 '미적 경험'일 수도 있습니다. '육체' 또는'정서'일 수도 있습니다. 배제된 용어는 특정 시, 신비주의 또는 낭만주의를 불러일으킬 수 있습니다. 또는 단순히 평범하고 특별할 것 없는 삶일 수도 있습니다. '계산 불가능'은 이 모든 것을 의미하며 그 이상을 의미합니다. 요점은 이산적인 기호가 자리 잡지 못하거나 적어도 지배력을 행사하지 못하는 존재 방식이 있다는것입니다.

그리고 그러한 합리적인 상징이 없는 상태에서 계산은 표류하기 시작하고 다른 형태를 띠게 됩니다. 때로는 이를'삶' 또는'경험'의 영역이라고 부르기도 합니다. 때로는'아날로그' 영역이라고 부르기도 하지만, 아날로그 컴퓨터는 가장 오래된 컴퓨터 중 일부입니다.
…

—

GPS 지도 없이는 만나고 싶은 친구를 만나지 못해 미끄덩거리는 신형 아이폰을 사게 된 것처럼^[2], VScode, Windsurf, Cursor 같은 IDE(Integrated Development Environment)에 커서만 갖다대면 코드의 다음 줄을 추천해 매끄럽게 이어주는 자동완성 기능을 나는 거부할 틈이 없었다.

문득 나보다 AI가 내 의도를 먼저 읽어내고 있다고 느낄 때가 있다. 사실 AI는 내가 만든 코드베이스의 맥락(context)을 끊임없이 학습하고 논리적인 추론을 할 뿐이지만. 그래도 감각적으로는 이 녀석(?)이 깔아둔 경로를 겨우 따라간다는 기분을 지울 수가 없는건 왜일까?

이 ‘기분’은 사실 어느정도 맞고, 어느정도 틀리다. AI는 이미 작성된 코드베이스의 언어적 문법, 코딩 컨벤션, 도메인 로직들을 훑고 그에 맞춰 가장 적절하다고 판단되는 코드를 완성해준다. 하지만 아무리 합리적인 시스템 룰을 설정해두었더라도, 엔지니어들은 모니터 앞에서 ‘탭’ 혹은 ‘아니야, 중복을 없애고, 더 간결한 코드로 작성해줘.’를 반복한다. 그 말은, AI도 코드의 주인을 겨우 따라간다는 뜻이다.

나는 솔직히 말해서 IDE에 프롬프트를 입력하고, ‘탭’을 연발하며, 모든걸 AI에게 맡기고 싶은 게으른 욕망을 참느라 애쓸 때도 있다. ‘AI가 세상을 지배하게 될까, 인간이 언제쯤 AI에게 대체될까, AI시대에 엔지니어는 무엇을 해야 될까…’ 같은 고민보다는 그냥 이 녀석을 믿어버리고 싶은 마음이 앞선다. 이 녀석은 언제나 내가 ‘토큰이 아까우니 잘못된 변경점을 만들어도 사과하지 말라’고 성질을 내는지, 제안된 코드를 실제로 제대로 써먹었는지는 상관 않고, 매달 정해진 크레딧만큼 ‘최선’을 다해 일을 해준다.

–

기계와 AI는 무엇이 정확하다고 판단할까? 무엇이 옳고, 합리적이라고 볼까? ELC(Electronic Line Calling) 시스템 ‘호크아이(Hawkeye)’를 도입한 테니스 매치에서 호크아이의 오작동으로 볼이 라인 바깥으로 아웃됐음에도 지연 판단되는 일이 벌어졌다. 선수들은 해당 라운드에서 라인콜링 없이 6-7샷 정도를 이어 경기를 진행했고, 실제 볼이 아웃되는 시점에 포인트를 얻는 대신 30포인트부터 재경기를 해야했다. 호크아이의 정확도와 합리성을 이유로. 직감적으로 아웃된 공을 느끼고 고개를 들었던 선수, 심지어 높은 의자에 올라 앉아 테니스 코트를 보고 있던 심판조차 볼이 아웃된 시점에 이 ‘호크아이의 냉정한 경기^[3]’를 멈출 수 없었다.

• 해설위원의 경기방송해설 : “공이 아웃이면, 그냥 아웃이죠. (Once the ball is out it’s out)”.

• 선수가 심판에게 : “왜 경기를 멈추지 않았어요? 의자에 앉아 있었고 그걸 봤잖아요. (Why didn’t you stop it? You’re in the chair and you saw that.)”

• 심판이 선수에게 : “당신도 그 포인트를 멈출 수 있었어요. 너무 늦었어요. 저도 아웃으로 봤지만, 제가 그렇게 할 수는 없어요.(You could have stopped the point. It’s too late. For me I thought that was out too but I can’t do that)”.

소프트웨어 엔지니어라면 누구나 고칠 필요없는 견고한 코드를 작성하고 싶어한다. 내가 짠 코드가 제대로 동작하는지 테스트하는 테스트코드가 소프트웨어의 안정성과 확장성을 보장한다고 믿는다. 그에 따라, TDD(Testing Driven Development) 방법론이나 테스트코드의 필요성, 더 나아가 테스트 자동화에 대한 많은 연구와 기술적 시도가 있다. 그러나 코드의 정확성과 객관성을 테스트하는 테스트 코드엔 함정이 있다. 결함이 있는데도 발견하지 못한 경우(False-Positive), 실제 결함이 없음에도 결함이라고 판단하는 경우(True-Negative)와 같은 판정 결과 유형의 함정.

그럼 코드를 테스트하는 테스트 코드, 테스트 코드를 테스트하는 테스트 코드를 작성해야할까? 호크아이의 ‘호크아이’를 도입했더라면 30포인트 재경기를 하지 않을 수 있었을까? 인간들의 테니스 매치에서 인간이 할 수 있고, 할 수 없는 건 뭐였을까? 6-7샷이 오가는 동안 선수들이 제대로된 경기를 했거나 하지 않았다고 말할 수 있을까? 공은 언제 아웃됐을까?

–

정정당당하고 편파판정 없는 경기를 플레이하고, 영원히 고칠 필요없는 소프트웨어를 만들고 싶은 인간의 정직하지만 게으른 욕구는 자동화와 정밀한 컴퓨팅(computing)으로 해소되었을까? 인간 활동의 효율화를 위해 등장한 수많은 기계장치와 컴퓨터는 스스로 가치 판단하지 않고, 여전히 테니스 경기엔 ELC 시스템 오류에 포인트를 리셋하는 추가 규칙이 필요하고, IDE엔 태스크 플래닝과 ‘탭’ 이 필요하다. 우리는 앞으로도 인간 스스로의 욕망을 위한, 그리고 컴퓨터의 완전무결함을 위한 룰셋만 무한히 만들게 될지도 모른다.

컴퓨터는 인간이 계산할 수 없는 것을 계산하고 인간의 눈으로는 볼 수 없는 것을 볼 수 있게 해주었지만, 스스로 할 수 없는 것이 있다. 최근 본 피지컬AI·로보틱스 관련 기사에서는 우리가 휴머노이드를 굳이 인간처럼 만드는 이유는 인간과 닮게 만들기 위함이 아니라, 그 형태로 인간이 적응해온 환경에 맞춰 더 많은 것을 수행할 수 있는 범용성을 확보하기 때문이라고 했다. 원래 인간이 하던 일 중에 기계에 위임하고 싶은 일은 뭘까?

귀찮고 성가신 일, 반복되는 일, 어렵고 복잡한 일, 정교한 일, 정확성이 요구되는 일, 공평한 일, 빠르게 해야되는 일, 너무 오래 걸리는 일, 누구나 할 수 있어서 내가 하지 않아도 되는 일, 사람들이 하기 싫어하는 일, 나중에 해도 되는 일, 인간은 할 수 없는 일…

인간의 외형으로 범용성을 획득한 ‘웬만한’ 휴머노이드는 위임받은 일을 스스로 해낼 수 있을까? 그리고 또 생각해볼 수 있다. 인간의 것을 모두 떠안고 인간처럼 해내는 휴머노이드의 욕망을. 그리고 휴머노이드가 보지 못하는 것들을.