지인의 추천으로 보게 된 영상인데, 정말 재밌다. 지난 번 영상 (엉클밥's)과 많은 결에서 닮아있지만, 전혀 다른 결론으로 뻗어간다.
감상평
말을 진짜 잘한다. 지적을 하면서도 기분이 나쁘지 않게 말하고, 절로 고개를 끄덕이게 만드는 대단한 화술을 지닌 사람이다. 그리고 내용이 너무 좋다. 이런 내용을 볼 때마다 나는... 아니다. 이 얘기는 나중에 하자.
아무튼 초반 좀 지루하고 어려운 내용들이 있는데, 마지막까지 참고(?) 볼 가치가 충분한 영상이다.
초반에 나오는 아래 장면의 사진의 의미를 잘못 이해해서, 중반까지 어버버했는데 "왼쪽이 현재고 오른쪽이 다가올 미래"로 이해해야 된다.
노트
미래를 알기 전에 과거를 보자. IBM 650 (1953)! 이 때 프로그래머들은 말그래도 불을 끄고 키는 방식으로 코딩했다. 기계어 그 자체. 시간이 좀 흐르자 어셈블리라는게 태어났다. 그러나 그 이전에 기계어를 조작하던 사람들은 그게 “쓸모없는 시간 낭비"라고 생각했다. 그냥 기계어를 만지면 되는데 왜? 본 노이만도 어셈블리하는 학생을 보며 화를 냈다고 한다. 시간이 더 흘러 포트란이 태어났을 때 - for loop 라던가 하는 것들이 있는 고급언어다 - 어셈블리를 하던 사람들은 마찬가지로 저항했다. 뭐하러 그런걸 배워야돼? 어셈블리 잘 쓰고 있는데?
무슨 말이 하고 싶냐면, 기술은 빨리 변하지만 사람들의 생각은 그렇지 않다는 것이다.
앞으로 다가올 네 가지 혁신에 대해 얘기해보자.
- 코딩 → 데이터의 직접 조작
Sketchpad (1962)를 보라. 사람이 그린 엉성한 네모를 컴퓨터가 직사각형으로 수정했다. 그러나 컴퓨터가 직사각형이 뭔지 아는건 아니다. 그냥 가로 세로 변의 길이를 조절했을 뿐이다.
비슷한 느낌으로, 미래엔 HTML 이라던가 CSS 하는 것들 대신 그냥 우리가 보는 그대로, 그리는 그대로 화면에 나오게 할 수 있을 것이다. (direct manipulation of data) 특히 비쥬얼적인 영역에서 이런 흐름이 두드러질 것이다.
- 절차 → 목적과 제약사항
Planner (1969)와 Prolog (1972)에 담긴 아이디어들을 보라. 구체적으로 이렇게 저렇게 하라는 지시를 하는대신, 미래의 개발자들은 원하는 결과를 명시할 것이다.
패턴매칭도 비슷한 예로 볼 수 있다. 직접 특정 글자들을 찾는 대신, 무엇을 찾아야되는지 패턴을 명시한다. (1962년의 Snobol)
이 아이디어는 훗날 알파넷, 혹은 인터넷이라고 불리는 시스템에서도 활용될것이다. 무슨 말이냐면 지금의 인터넷은 이렇다:
무엇을 받을 수 있는지, 어떻게 해야 그 정보를 얻을 수 있는지 클라이언트가 알고있고, 원격 서버의 수정사항은 클라이언트가 수정되도록 강요한다. 그러니 절대 무한하게 확장할 수 없다. 하지만 이런 형태라면 어떨까?:
서로가 결국 알아내는 것이다. 무엇을 원하는지, 뭘 어떻게 요청해야 원하는 결과를 얻는지를 생전 처음보는 두 개체가 노력하여 찾아내는 방법. 이게 미래에 찾아올 소통 방식이다.
- 텍스트 덩어리 → 공간적 표현
NLS (1968) 시스템을 보라. 데이터를 공간적으로 2차원에 표현했다.
Grail (1968) 도 마찬가지다. 타블렛에 박스를 그리면 컴퓨터는 이것을 컴포넌트로 인지할 수 있었다.
Smalltalk의 코드 문서는 Smalltalk Browser이라 불리는 형태로 표현된다. 텍스트로 표현되어있지만 메소드들, 클래스들, 변수들을 공간적으로 배치해서 표현했다.
이러한 접근은 컴퓨터와 즉각적으로 상호작용하려고 한 노력들이다. 눈에 보이는 데이터와 컴퓨터에서 일어나는 작업 사이에 딜레이가 없어야 한다는 것을 알고 있었고 그 컨셉을 현실화한 결과들이라 할 수 있겠다.
- 순차적 → 동시적 (병렬 프로그래밍)
본 노이만 컴퓨터 아키텍쳐에선 CPU와 Memory 사이에 bottleneck 이 있었다. 결국 CPU 는 메모리의 1 word 를 fetch 하고, 나머지 메모리 영역은 idle 하게 남는다. IC (집적회로)는 속도를 비약적으로 향상시켰지만 이러한 문제는 똑같이 남아있다.
따라서 Threads와 Locks 라는 모델을 버리게 될 것이다. 우리는 그보단 Actor model (혹은 그러한 새로운 컨셉의 다른 아이디어)로 일해야 할 것이다. 모든 프로세서가 저마다의 일을 하는, 그런 모델 말이다.
(여기부터 재밌음)
그런데.. 우리가 40년 후에도 코딩을, 절차적으로, 텍스트의 형태로, 순차적으로 하고 있다면 그건 좀 비극일 것이다.
그런데.. 이런 아이디어가 사용되지 않는 것들보다 더 큰 비극은 우리가 이러한 아이디어가 있었다는 것을 까먹어버리는 상황일 것이다.
그런데 그건 사실 비극이 아니다. 진짜 비극은 애초에 그런 아이디어가 처음에 존재했다는 것조차 모르는 상황이다. 그건 이런 상황이다: 한 세대가 태어나고, 이런 아이디어들에 노출되지 않은 채 프로그래밍을 한다. 딱 한 가지 방식으로. 그리고 그 세대는 다음 세대에게 본인들이 아는 것만 가르침으로서, 두 번째 세대는 “오, 우리는 프로그래밍의 모든 것을 알아"라고 생각하는 것이다. 즉, 도그마를 만들어버리는 것. 이러한 도그마는 한 번 생기면 정말 깨부시기 어렵다.
지금 보신 이 많은 아이디어가 왜 전부 특정한 시대, 그러니까 6-70년대에 태어났는지 아시는가? 그 때는 컴퓨터가 충분히 발전되었지만 사람들은 프로그래밍이 뭔지 잘 몰랐던 시대다. 누구도 프로그래밍이 어떻게 되어야 하는지 몰랐다. 그리고 그들은 자기들이 모른다는 것을 알았기에 모든 것을 해 본 것이다. 이렇게도 해보고, 저렇게도 해보고.
창의적인 사람이 되려고 할 때 가장 위험한 생각은 당신이 뭘 하는지 알고있다고 생각하는 것이다. 자기가 뭘 하고 있는지 알고 있다고 생각하는 순간 주변을 둘러보지 않게 되기 때문이다. 당신을 장님으로 만든다. 바이너리로 코딩하던 사람들이 어셈블리, 포트란을 보며 저건 프로그래밍이 아니라고 말하던 것처럼 말이다.
새로운 생각을 받아들이고, 새로운 관점으로 생각하고 싶다면 그 시작은 당신 스스로에게 “나는 뭘 하고 있는지 몰라”, “나는 프로그래밍과 컴퓨터가 뭔지 몰라”라고 말하는 것이다. 정말 진심으로 그걸 믿는 순간 당신은 자유로워지고 모든지 할 수 있게 될 것이다.
