이전에 사용해본 적이 없거나, 잘 모르는 제품을 살 때는 언제 필요로 하게 될지 모른다는 막연한 불안감 때문에 기능이 많은 제품을 선호하는 경향이 있다. 이미 비슷한 제품을 사용해보았고, 기능들에 대해 속속들이 알고 있는 경우라면 간결함이나 조작편의성을 중요하게 고려할 것이다.
특정 이미지가 얼마나 얼굴과 유사한지 그 정도에 따라 반응하는 좌뇌 부위가 있고, 이 데이터를 기반으로 얼굴이 맞는지 여부를 범주적 관점에서 판정하는 우뇌 부위가 따로 있다고 한다. 대다수의 사회가 조사-결정, 수사-재판 같은 분업 체계를 가지고 있는 것이 단순히 은유적 연관에 그치는 것이 아니라, 기본적인 뇌의 작용에 의한 것일 수도 있다.
프톨레미와 그의 후손들(왕위에 오를 때 모두 ‘프톨레미’라는 이름을 이어받음)은 정치 상징주의의 대가들이었다. 알렉산더와 직계 관계도 아니면서 궁전 안에 그를 위한 거대한 신전을 짓고 자신들의 가문에서 누군가 죽으면 그곳에 같이 묻었다. 어느 시점에 와서는 원래 황금이었던 알렉산더의 관을 유리관으로 바꿨다. 이제 이집트 백성들과 외국에서 온 고위 인사들은 위대한 정복자인 알렉산더가 불사신인 듯 썩지 않은 채 프톨레미 가문 사람들의 시신에 둘러싸여 있는 모습을 볼 수 있었던 것이다.
평균적으로, 사람들은 누군가와 함께 식사를 할 경우, 혼자 먹을 때보다 약 35%를 더 먹는다. 네 명이 함께 할 경우에는 75%를 더 먹으며, 일곱 명 이상이 함께 식사할 때에는 96%를 더 먹는다.
— “넛지”, 리처드 탈러, 캐스 선스타인
하지만 늘 뭔가가 켕겼다. 소심하게 살면서 무언가를 놓치고 있다는 것이었다. 즉 결과가 좋은 도전과 좋지 않은 도전을 분간하기가 어려웠다. 예를 들어 시도하지 않은 기회가 본인의 삶에 풍요를 가져다줄까 아니면 오히려 탈출하기 위해서 스스로의 팔을 입으로 씹어 끊어서 도망쳐야 하는 그런 지독한 위험을 가져다줄까? 삶의 풍성함 그리고 팔을 씹어버리는 위험은 시작점부터 보면 서로 비슷해 보인다.
주석 과용
기술 문서라 할지라도 불필요하게 주석을 남발하는 글을 볼 때마다, 주석 많이 쓰면 있어 보이는 줄로 아는 기이한 풍조를 괴이하게 생각해왔는데, 급기야는 본문에서 주석을 참조하는 글을 봤다. 움베르토 에코 덕분에 주석 과용을 일종의 스타일로 봐줄 수 있는 길이 열렸지만, 본문에서의 주석 참조는 프로그래밍에서의 순환 참조(Cyclic Reference)를 즉각 연상시키기에 배드스멜이 스멀스멀 난다. 문학과 프로그래밍 양 분야 대가들의 문체(style)에서 나타나는 공통점을 취합해보는 것도 재미있을 것 같다.
브랜치 정책의 종결 문서인 듯.
Capability Detection
안드로이드 호환성에 관한 문서를 읽다가 ‘능력 탐지(Capability Detection)’라는 용어를 발견했다. 프로그래밍에 있어 이 용어가 지시하는 개념은 상당히 유용한 것인데, 소위 우아한 퇴화(Graceful Degradation) 전략을 구현함에 있어 기초가 되는 기법을 말한다. 이 기법은 웹 애플리케이션을 만들면서 다양한 종류의 브라우저 및 에이전트를 적절하게 지원하려고 할 때에도 자주 활용되었던 것으로써, 웹 애플리케이션과 안드로이드 애플리케이션 모두 표준과 구현의 엄격한 책임 분리 및 자율성이라는 개념을 기반으로 하기 때문에, 그로 인한 파편화(Fragmentation)라는 공통의 문제에 대응하기 위한 기술적 해결책이라고 할 수 있다.
이 용어를 접하기 전까지만 해도 나는 ‘기능 탐지(Feature Detection)’라는 용어가 많이 쓰였던 것으로 기억하고 있어서, 과연 어느 쪽이 더 적절한 용어 선택인지 알아보려고 위키피디아를 찾아봤다. 위키피디아에는 능력 탐지 항목이 존재하지 않는다. 즉, 현재 많이 사용되는 용어는 아닌 것 같다. 기능 탐지라는 항목은 신경생물학과 컴퓨터 비전 분야에서 사용하는 용어로 잘 확립이 된 것으로 보인다. 두 분야 모두 흥미로운 현상을 설명하고 있지만, 유감스럽게도 프로그래밍 기법 차원에서의 의도와는 크게 다른 것 같다. 능력 탐지든 기능 탐지든 이 용어에 담고 싶은 의미는, 서로 다른 의도와 기술적 배경을 가진 여러 응용 환경에서, 비슷한 내용을 최적의 형태로 보여줄 의도를 가지고 사용되는 기술을 말한다. 좀더 쉽게 말하면, 원작자의 의도가 가장 잘 드러날 수 있도록 어떤 내용을 표현하기 위해 기초가 되는 기술적 해법이라고 말할 수 있을 것이다. 기능 탐지라는 용어는 비슷한 분야에서 상당히 다른 의미로 이미 사용되고 있으므로, 나는 앞으로 능력 탐지라는 용어를 선호하게 될 것 같다.
말이 나왔으니 말인데, 이 업계 사람들 중에도 이런 개념을 이해하지 못하는 사람들이 더러 있다. 수차례 설명을 해도 못 알아 듣는 것을 보면, 이해할 수 있는 뇌 구조를 개발시키지 못했다고 하는 편이 나으리라. 합리적인 사람이라면, 문제가 닥쳤을 때, 그 문제를 특정하고 구체적인 상황에 한정하지 않고, 좀더 일반적이고 추상적인 수준으로 끌어올려서 문제를 해결하려고 노력한다. 좀더 쉽게 표현하면, 똑똑한 사람들은 특수해가 아닌 일반해를 찾으려 노력한다. 이 용어가 지시하는 개념도 그렇게 이해할 수 있다. 어떤 스마트폰 기종 혹은 어떤 브라우저 버전에서 사용성의 문제가 발생했을 때, 그것을 해당 스마트폰 기종 혹은 해당 브라우저 버전으로 한정하여 문제를 해결하는 것은 당장 쉬워 보일지는 몰라도 대단히 근시안적인 접근이다. 똑똑한 사람이라면, 그 문제를 한차원 높게 추상화시켜 유사한 구현을 가졌을 다른 응용 환경에도 문제를 해결한 방법이 적용될 수 있게 하려고 노력할 것이다.
당장 눈에 보이는 결과와 성과로 평가받는 사회에서, 조금 더 시간과 머리를 많이 써야 하는 방식으로 골치 아픈 일을 해냈다고 해서 그 사람에게 어떤 직접적인 보상이 돌아오는 것은 아니다. 이것은 프로그래머의 직업 윤리로써, 최소 기준을 만족하는 것에서 그칠 수도 있고, 좀더 높은 기준을 향해 나아가도록 재촉하는 무엇일 수도 있다. 선택은 각자의 몫이지만 똑똑한 방식으로 일하는 다른 동료들로부터 바닥이 보이는 인간으로 평가받기 싫다면, 그 선택에 신중을 기해야 할 필요는 있을 것이다. :)
스티브 예게 이 사람은 요점 없이 말 늘이는 데 재주가 있다. 구글 플랫폼이 엿 같다고? 외부 사람들 눈에 확 띄는 구글을 대표할 만한 인터페이스가 없을 수는 있지만, 그래서 어쩌라고? 필요한 사람들은 그냥 구글 홈에서 gmail api 라고 쓰면 된다. 그것이 구글 플랫폼이다.
