몇년 전만 하더라도 웹 접근성이니 웹 표준이니 하면서 장애인과 함께 주요 시나리오로 예를 들었던 게 모바일 장비들이였는데, 이제는 상황이 역전되어 오히려 모바일 장비에서만 돌아가고 컴퓨터에서는 쓰지도 못하는 카카오톡이나 Path 같은 서비스들이 한가득 세계를 점령하게 되었다.
생각해보면 이 모든 것이 “접근성”(accessibility)을 소극적으로 해석해왔기 때문에 일어난 일들이 아닐까 하는 생각도 든다. 접근성을 프로그램 가능성(programability)까지 포함하는 것이라고 광의적으로 해석하는 Steve Yegge의 관점도 생각해 볼만한 화두인 것 같다.
JSON이 PostgreSQL 9.2의 기본 타입으로 들어간다. 이미 이전부터 xml, hstore 등의 타입을 가지고 있었기 때문에 예상된 수순이었지만 그럼에도 놀라운 소식. 이게 들어가면… 긴 말 필요 없고 HN에 누가 단 댓글을 인용해보자.
이게 표현식 색인과 함께 쓰이면 JSON 데이터를 저장할 수 있을 뿐만 아니라 JSON 안쪽에 들어있는 값들을 색인할 수도 있게 된다. 즉, 달리 얘기하자면, PostgreSQL의 성숙한 구현을 희생하지 않고 NoSQL 데이터 모델의 장점중 하나를 누릴 수 있게 된다.
Heuristics
실제로는 아무런 관련이 없는 독립적인 사건일지라도, 시간적으로 비슷한 시기 혹은 공간적으로 비슷한 장소에서 연달아 일어나는 사건들에 대해 특별히 과학적 사고 방법을 훈련받지 않은 대개의 사람들은 인과적 관계가 있다는 느낌을 받는다. 예를 들어 어떤 음식을 먹고 나서 식중독에 걸렸으면, 그 음식이 잘못된 것이라는 믿음이 생기는데, 진실은 그것만으로는 알 수 없는 법이다. (훈련이라 함은 그런 느낌을 애써 무시하고 의심하는 습관을 만드는 것이라고 볼 수도 있다.) 이는 매우 흔한 인지적 오류인데, 그렇다고 이것만 보고서 인간의 모든 인지 능력이 비합리적이라고 결론지을 수도 없다. 그것이야 말로 부분만을 보고 전체를 규정하는 인지적 오류의 하나이다.
비슷한 시점에 사건이 연달아 일어나기만 해도 인과성을 느끼는 것은 사실 인지적 ‘기능’으로, 계산적 모형에 입각해서 설명하자면 자주 발생하지 않는 1할의 케이스를 무시하고 비교적 심플하고 거친 가정들(assumptions) 위해서 적은 비용으로 구현할 수 있는 데다 나머지 9할에서 매우 잘 작동하는 휴리스틱(heuristic)1이다. 인간이 현재 누리고 있는 인지 능력이 진화적으로 적응했던 환경(EEA)에서는 매우 잘 작동하고 효과적이었던 전략이었고, 지금도 많은 부분에서는 그렇다. 예를 들어 어떤 음식을 먹고 식중독에 걸린 적이 있으면, 원인이 그것이 아니라고 해도 당분간 그 음식을 피하고 보는게 상책이다.
보다 느리고 큰 비용(컴퓨팅 파워와 마찬가지로 생각하는 것도 엄연히 칼로리를 소모하는 한정적 자원이다)으로 엄밀한 판단을 내릴 수도 있고, 그러한 개체가 때때로 존재했겠으나 천적 앞에서 생각만 오래하다가 잡혀먹었는지 어쨌는지, 결론적으로 나이브하지만 더 빠르게, 그리고 그럼에도 9할의 상황에서 대부분 들어맞는 결론을 내리는 개체들이 전략이 현재 인류에게 더 많이 남아있다.
물론 이러한 휴리스틱이 때때로 만나는 1할의 드문 상황에 대해 잘못된 결론을 내리는 것은 엄연히 오류이다. 그래서 이러한 버그를 어뷰징하는 무리도 종종 나타나게 된다. 쉽게 생각해서 종교를남을 속이는 것을 생각해보면 된다.
역사가 오래된 소프트웨어가 모두 그렇듯, 오래된 버그는 기능으로 둔갑한다. 오랫동안 멀쩡하던 버그가 더이상 일어나지 않으면 사용자에게 반발을 받게 된다. 오랫동안 인지 API의 유명하고 유서 깊은 버그를 스타트업 시절부터 이용해왔던 종교들은 이제 오래된 거대 기업으로 변해 해당 버그를 우회하는(workaround) 과학 교육들을 훼방놓기 시작하는데… =3==3
-
이 단어는 인지 과학과 컴퓨터 과학 양쪽에서 모두 쓰이는 용어인데, 대상만 다를 뿐 뜻하는 바가 같다. ↩
비동기 I/O 라이브러리 아이디어
요즘 gevent 등의 비동기 I/O 라이브러리들을 쓰면서 생각하고 있는 새 비동기 I/O 라이브러리 디자인 아이디어들이 있다. 일단 크게 두 라이브러리로부터 영감을 얻었다.
- Twisted
- Twisted가 오래됐는데도 불구하고 여러 부분에서 봤을 때 가장 잘 디자인되어 있다. Twisted가 다 잘해둔 것들을 오히려 나중에 가서 그보다 못하게 리엔지니어링하면 안된다.
gevent- 코루틴을 이용하여 직렬적인 루틴은 CPS 없이 자연스럽게 쓸 수 있어야 한다. node.js처럼 하면 안된다.
이미 있던 것들과 전체적으로는 비슷하고, 중요한 부분만 적자면:
Python 2.5에서 들어온 강화된 제너레이터(enchanged generators)는 사실 코루틴이다. CPython, PyPy, Jython 등의 여러 구현체에서 모두 쓸 수 있도록 Greenlet 같은 것을 쓰지 말고 강화된 제너레이터를 사용한다.그런데 좀 생각해보니 제너레이터는 다 좋은데yield를 항상 써야 해서 맨 아래 항목에서 언급할 멍키패쳐를 구현할 수 없다. 대신 CPython에서는 Greenlet를 쓰고 Stackless Python과 PyPy에서는stackless모듈을 쓰는 방향으로 가야할 것 같다.Twisted가 세상에 존재하는 리액터/IO 루프의 공통적인 부분을 찾아서 일반적인 인터페이스를 정의한 뒤, 그 인터페이스의 다양한 구현을 포함한 것은 매우 훌륭한 결정이라고 생각한다. Twisted는
select, 쓰레드select, IOCP, kqueue, epoll 등 뿐만 아니라 심지어 GTK, GTK 2, Qt 메인루프까지 일반 인터페이스 아래 죄다 구현해뒀다. GTK 등은 사실 GUI 애플리케이션에서 비동기 I/O를 구현하기 위해 필요한 것으로 서버 구현에서는 필요 없겠지만, 일반적인 인터페이스가 있다면 저런 것도 구현이 가능한 것이다. 그리고 라이브러리를 사용한 애플리케이션 코드는 플랫폼 이식성이 매우 높아진다.그런 가운데
gevent가 하듯 표준 라이브러리의 I/O 모듈을 갈아치우는 멍키패쳐를 제공해야 한다. 안 그러면 아무리 코루틴을 써도 이미 존재하는 거의 모든 라이브러리에서 블럭이 되기 때문에 자동으로 모든 코드가 동기화되어버린다.
요는 Twisted의 이식성과 gevent의 사용성 모두가 필요하다는 것. 아직 아이디어 수준이고 실제로 구현하게 될지는 아직 모르겠다.
세상이 망하려는지 딕셔너리 키에 문자열밖에 안 들어가고, 문자열과 배열 외에는 변변찮은 자료구조도 전혀 없으며, 반복에 관한 공통 인터페이스도 없고, 모듈 시스템도 없어서 저마다 각자의 패키지 라이브러리를 만들어서 쓰지만 결국 그 패키지 시스템 스스로는 불러올 수 없으므로 손으로 엮어야 하는, 약 5년 전까지 과소평가를 받았다고는 하지만 또 지금 보기에는 현대적인 언어라고 하기에는 어색한 부분이 많은, 내가 보기에는 현대의 어셈블리에 가까운 언어가 사람들 입에서 다음 세대의 언어라고 찬양받는 것을 보니 참 답답하다. 과연 말세다.
