Thou arn't unlogical [τ]

'등가속도 운동' 논쟁에 덧붙여

어리 — Sun, 29 Nov 2015 17:09:46 +0900

발단은 트위터의 엑스아미닥 씨가 올린 한 트윗에 내가 이런 트윗을 쓴 것.

요약: 등속도 운동은 등가속도 운동입니다.

요즘 재발굴되고 있는 “저 비가 무슨 운동을 하고 있는지 아십니까...(아련)” 밈에 대해 트위터에서 몇몇 사용자들을 중심으로 ‘등속운동이 아니라 등가속운동 아니냐’, ‘등속운동이 맞다’ 식의 단타트윗들이 잠시 솟아올랐다. 엑스아미닥 씨는 이에 대해 ‘빗방울은 어떤 구간에서도 등가속 운동을 하지 않는다’ 라고 올렸고 (원본 삭제됨) 그에 대한 내 첨언이 위 트윗이다.

내가 받은 답글. (이 역시 원본 삭제되어 앱에서의 스크린 캡처 이미지로 갈음함)

기존의 개념을 무시하는 말장난이라신다.

내가 하고 싶은 얘기는 트윗에서 다 했으니, 이미지 먼저 올린다.

퍼블릭 트윗으로 바꿔 가면서까지 관심과 호응을 유도하는 모습이다. 그래도 난 최대한 정중하게 대응했다.

트윗 이미지는 여기까지. 그저 개인적으로 생각을 정리하기 위해 캡처 이미지를 올린 것이며 다른 의도는 없다. 나는 어떤 트윗도 삭제하지 않았으나, 일관성을 위해 지워지지 않은 트윗을 포함해 전 트윗을 이미지로 인용하였다.

‘등가속운동’(또는 ‘등가속도운동’)은 영어로도 ‘motion with constant acceleration’으로 풀이되는, 가속도가 일정하다는 뜻이다. 대부분의 대학교 일반물리 교과서에서도 변위(displacement)의 시간(time)에 대한 2계 도함수(second derivative) 값이 0인 구간으로 우아하게 정의되어 있다. 이는 수학에서의 상수함수 개념과 해석학의 성과를 그대로 가져와 a(t)=0(const.) 역시 등가속도 운동(등가속도 상태)이라는 개념에 편입한 사례이다. 그러므로 사실 등가속도 운동이 a(t)=0(const.)를 포함하지 않는다는 견해도 타당하게 여겨질 수 있다는 식으로 내가 진지하게 임해 줄 필요조차 없었다. 차라리 가속도가 0이어도 등가속 운동인 게 명확하며, 당신 방식대로 정의하는 것은 현 과학 용어 체계에서 틀렸다고 명확하게 말했더라면 이런 모욕을 당하지는 않았겠지?

그럼에도 불구하고 이런 폄하를 받을 뿐인가 보다. 상대방의 타당성을 존중하며 온건하게 대화해 봤자 소용이 없다. 제 나름 과학에 관해 말한다는 분과 얘기하더라도.

그럼에도 불구하고 이 논쟁의 본질이 과학철학적 논의라는 내 지적이 왜 유효한 것인지부터 다시 정리하고 넘어가겠다. 과학 자체가 불변의 진리로 이루어져 있지 않음은 물론, 과학의 역사가 정적이거나 점진적이었던 적조차 없다는 지적은 더 이상 필요 없을 것이다. 그리고 이견의 여지가 있지만, 기존의 이론체계에 대한 비판과 반증을 구하여 발전하는 것이야말로 과학의 본질이라는 칼 포퍼의 견해와, 충분히 많은 반례가 정상과학을 무너뜨려야 비로소 다른 이론체계를 만드는 보수성과 토마스 쿤의 견해는, 이들을 빼고는 무엇이 과학인가를 논할 수 없을 정도로 과학철학의 큰 기둥이다.

두 거장의 사례만 보더라도, 과학이란 무엇인가 하는 논의에서 관념, 기호, 언어에 대한 철학이 빠진 적이 없다. 사실 이는 과학철학 자체가 새로운 철학으로 출발한 것이 아니라, 모든 것을 다루는 기존의 철학에서 출발했기 때문이다. 그리고 이내 과학이 지닌 언어적 속성은 '패러다임'이라는 단어를 빌려와 사실상 정례화된다. (물론 그가 '패러다임'을 너무 여러 의미로 남발했다는 지적도 있다.)

이것도 사실 트위터에서 이미 한 얘기다.

(물론 이들은 거의 비과학인 것과 명백히 과학인 것, 또는 명백히 비과학인 것과 거의 과학인 것 사이에서 씨름을 했던 학자들이기 때문에, 과학적 활동 자체의 내면을 파헤치기 위해서는 장하석(2007)을 읽는 것이 나을 것이다.)

소위 유사과학 비판하던 과학 계정들이 내게 보인 비난과 조소의 현장으로 이 글을 마친다.

살다 보면 이런 날도 있고 저런 날도 있는 거겠지. 다들 흑역사가 있는 법이다. 하지만 다들 그걸 토대로 돌아보고 올라서며 발전하는지는 잘 모르겠다. 내가 보면, 대체로 그냥 '삭튀'더라.

나는 컴과 학부생이자 컴돌이다

어리 — Sat, 14 Dec 2013 00:51:38 +0900

페북에 대충 쓴 글이라 앞뒤도 안 맞고 빠뜨린 내용도 많다. 그래도 다 쓰고 나니 날리기 아쉬워서 남김.

우리는 모두 컴퓨터를 공부하면서 많이 배운 사람일수록 새로운 것을 익히고 고안해 내는 데 익숙해져야 한다고 배운다. 그러나 현실에서는 컴퓨터 자체를 적게 배운 사람이 개발 일선에서 많은 소프트웨어를 만들고, 나아가 다른 분야를 더 배운 사람이 새로운 분야로 컴퓨터 기술을 진출시키는 경향이 있다. 고졸이 일선에서 지휘를 하고 대학원생이 알고리즘과 같은 설계를 하는 경우가 다반사이다. 이것은 일종의 역설이다.

물론 제대로 만든 소프트웨어, 신개념의 소프트웨어는 분명히 과학의 산물이다. 부동 소수점 표기가 그랬고, 수많은 알고리즘이 있었고, 시대를 풍미한 인공지능들이 있었다. 오늘날 현대적인 고성능의 CPU 구조가 그렇고, 구글의 검색엔진이 그렇고, 프로그램 자동 검증 도구가 그렇다. 이 외에도 인류의 컴퓨터 과학을 진보시키고 컴퓨터 기술을 발전시키는 수많은 사례가 있다.

그러나 우리는 컴퓨터 과학을 발전시킨 것이 당대 컴퓨터 기술자들의 요구와 무관하지 않았음을 알아야 한다. 소프트웨어는 가능성의 도구이다. 여느 과학과 기술, 사회의 관계가 그렇다만, 특히 소프트웨어는 지금도 그 가능성을 놀라운 속도로 실현하고 있다. 어떤 인문학적 상상력, 어떤 기술적 상상력과도 소프트웨어는 결합될 수 있다. 그리고 이 선구적인 경계에서는 소프트웨어 과학자와 기술자 모두의 역할이 중요하다.

결론은, 모두가 과학자인 동시에 기술자일 것을 요구받고 있다는 것... 그래서 나는 아직도 내가 대학에서 컴퓨터 과학을 하는지 컴퓨터 공학을 하는지 잘 모르겠다. 뻘글임.

동영상 강좌를 책처럼 편하게 읽을 수 있을까

어리 — Sun, 1 Dec 2013 20:39:20 +0900

글을 쓰다 보니 주제가 끊임없이 길고 무거워져서 원래 페이스북에 쓰던 글을 결국 본 블로그로 끌고 왔다.

동영상 강좌의 인기가 폭발하고 있지만 나는 아직 동영상 강좌가 책으로 쓰인 강좌에 비해 낫다는 생각이 안 든다. 동영상 강좌는 한 편에 하나의 주제만 담을수록 편하고, 허술한 동영상은 켜 두고 보기도 힘들다. 반면에 책은 꽤 방대한 내용을 만들어도 소화하는데 무리가 없을 뿐만 아니라, 다소 허술한 글이라도 사람을 피곤하게 만들지는 않는다. 이 둘을 비교해 보자면 글은 순서를 무시하고 대강 읽을 수도 있고, 전산화된 문서는 검색으로 내용을 찾을 수도 있는 등 수많은 원인이 있다. 그래서 아직도 우리는 책을 사용하고, 글을 쓴다.

왜 동영상은 글처럼 대강 보거나 검색할 수 없을까. 그 이유는 간단하다. 책은 텍스트이기 때문이다. 텍스트는 가장 오래된 역사를 지닌 언어적 정보의 매개체이다. 다시 말해, 어떤 정보가 텍스트로 작성되어 있다면 그 정보는 원시적 형태로 주어진 것이라는 사실을 알 수 있다. 텍스트로 작성된 정보를 어떻게 다루어야 하는가에 대한 연구는 컴퓨터의 발명 이전부터 있어 왔다. 지금 컴퓨터로 구현된 정보 처리 기술은 인류 역사와 문명의 산물인 것이다.

텍스트에 대해서 컴퓨터가 어느 수준으로 똑똑해졌는지를 알고 싶다면 구글을 보면 된다. 구글에 '사진술'을 검색하면 'photography'는 물론 '사진학', '사진학과' 등 수많은 유사한 의미의 검색 결과가 함께 나온다. 기계학습의 성과는 놀랍다. 단어들 간의 의미 분류를 찾는 것이 이 일의 핵심이 아님을 알 수 있다. 정보 처리 기술은 한 언어로 쓰인 글을 다른 언어로 번역하고, 그것을 이용해 내용을 학습하며, 내용을 학습한 결과를 다시 언어 간 번역에 반영하는 데 이르른 것이다.

한편 축음술과 사진술은 그리 오래 되지 않은 기술이며, 영화도 마찬가지이다. 좋은 소리와 좋은 영상은 분명히 우리의 마음을 움직인다. 하물며 이들의 시공간적 특성을 결합시켜 만든 동영상은 두말할 나위도 없다. 그러나 축음술과 사진술이 오래 되지 않은 기술이라는 것이 우리의 발목을 잡는다. 만약 기록된 소리와 기록된 화면이 우연히 텍스트만큼이나 일찍 발명되었다면, 소리와 화면의 정보에 대한 연구가 충분히 진행되었을 것이다. 그리고 우리는 책을 읽듯 동영상도 편히 '읽을' 수 있을 것이다.

그러면 우리는 앞으로 무엇을 해야 하는가. 우리 앞에 두 가지 방식이 있다. 하나는 지금처럼 수요에 맞추어 기술을 만들어 내는 것이다. 소리와 화면을 나타내는 기술이 있기 때문에, 소리와 화면을 파동의 집합으로 분해하고, 소리에서 목소리와 악기 소리를 분리하고, 사진에서 얼굴을 찾는 기술이 발전해 왔다. 구글은 유튜브의 동영상들을 토대로 영상에서 물리적인 물체를 구별해 내는 학습 기술을 공개했다.

그러나 이런 기술은 기술을 위한 기술이다. 텍스트에 비유하자면 손으로 글씨를 쓰는 기술로부터 비롯된 것으로, 손으로 쓴 텍스트로부터 문자를 추출하거나 필적을 감지하는 등의 기술이 여기에 해당한다. 문자열이나 필적은 특정 부류의 사람들이 의미있게 여기는 정보일 뿐, 그 자체가 텍스트의 본질인지는 불분명하다. 이런 접근은 사실 소리와 화면, 그리고 이들의 결합에 대한 본질적인 고찰과는 거리가 멀다.

한편 두 번째 방식은 소리와 화면에 어떤 정보가 담길 수 있는지에 관한 정성적인 연구이다. 이는 XHTML과 온톨로지 의미론과도 관련이 있다. 텍스트의 본질에 대해서는 유사 이래로 이런 연구가 지겹도록 오랫동안 행해져 왔다. 그리고 그 결실의 일부로 우리는 하이퍼텍스트 문서에 대해 XHTML로 정형화된 의미론을 정의할 수 있었다. 비록 XHTML은 발전하는 컴퓨터 기술을 따라가지 않고 꿋꿋이 실패한 모델이지만, XHTML만큼 완비된 온톨로지 모델은 없을 것이다.

XHTML은 우아하게 재구성할 수 있는 하이퍼텍스트의 정보 모델이다. 비록 모든 텍스트 기반 정보가 기존의 온톨로지 모델로 우아하게 재구성될 수는 없지만, 어떤 매체에 그런 프레임의 유무는 그 매체의 활용에 대한 무궁무진한 가능성과 직결된다. 지금은 아무도 소리에도, 화면에도 이와 같은 의미론을 제시한 바가 없다. XHTML2가 망하고 HTML5가 흥한 이유는 이 때문이다. HTML5를 나무랄 생각은 없다. 그것이 오늘날의 문서에 대한 합당한 모델이기 때문이다.

이런 관점으로 얻을 수 있는 결론이 몇 가지 있다. RDF는 접근성을 높여 주는 데이터가 아니라 그저 메타데이터인 것과 마찬가지로, 동영상에 자막을 붙이는 것도 접근성을 높여 준다고 보기 힘들다는 사실이다. 자막은 동영상 플레이어에서 영상과 병행 재생되는 텍스트 기반의 또 다른 미디어일 뿐이다. 텍스트를 무조건 앞에서 1000자 자른다고 1000자 요약이 되지 않듯, 소리도 고속 재생을 한다고 요약되는 것이 아니다.

미래의 동영상은 어떨까? 글쎄, 사실 이미지에 대해서는 위에서 말한 '요약'에 해당하는 심 카빙(seam carving)이라는 좋은 예가 있다. 오디오에 대해서도 같은 게 가능할까? 동영상을 색인해 두고 요약하거나 검색하는 것이 가능할까? 물론 이쯤 되면 동영상은 텍스트와 동등해진다. 나는 XHTML처럼 모든 동영상을 의미 기반으로 재구성하고, 눈과 귀에는 그로부터 생성된 정보가 제공되도록 해야 한다는 것은 아니다. 동영상이 텍스트만큼이나 의도된 정보라는 확신조차도 지금 내게는 없다. 아무렴 어떤가. 일단 적절한 과학이 있다면, 기술은 그것을 토대로 꽃을 피울 것이다. 하이퍼텍스트가 하이퍼텍스트 고유의 의미론을 만들었듯, 앞에서 말한 '기술을 위한 기술'도 끊임없이 과학을 발전시킬 것이다.

장고는 반쪽 MVC이다

어리 — Sun, 1 Dec 2013 02:13:10 +0900

요 며칠 간 프로젝트를 진행하면서 장고(Django)를 쓰기 시작했다. 사실 장고 자체를 접해 본 건 다소 오래 된 일이었던 것으로 기억한다. 아마 서버를 겸해 공부한답시고 설치한 리눅스가 너무 어려워서 날리면서 한동안은 리눅스와 거리를 두고 살았고, 파이썬도 잊었을 것이다. 그 이후 호스팅 업체를 알아보면서 윈도우 기반으로 PHP+MySQL이 돌아가는 APM을 쓴 적도 있다. 지금은? 만약 지금의 내가 과거의 내게 충고할 수 있다면, PHP를 가능한 대안으로 생각할 여지를 만들도록 놔 두지 않을 것이다. 요즘은 멀티부팅을 밥 먹듯 한다.

장고는 MVC 웹 프레임워크이다. 구체적으로는 DBMS에 대한 파이썬 클래스 ORM 래핑이 M이고, HTTP Request-Response를 수행하는 파이썬 객체 래핑이 V이며, URL 패턴에 따라 V를 적용(dispatch)하는 파이썬 코드와 그 밖의 데코레이터 기능이 C에 들어간다. 잘 보면 C의 의미가 MVC에 비해 다소 다른데, 이 떄문에 장고는 MVC의 변종인 MTV라고도 한다. 그러나 장고처럼 백엔드가 M과 V를 구성하기 위한 유틸리티가 되는 상황에서, 다 만들어진 M과 V에 대해 C가 또 한 번의 추상화를 하는 건 MVC 모두의 코드를 늘리는 퍽 불필요한 짓이다. 이런 건 대강 MVC가 맞다고 해도 되지 않나 싶다.

아무튼 올해에야 장고를 잡은 건 PHP를 버린 이후로 내가 서버 프로그래밍을 게을리 했다는 걸 방증하긴 하는데... 그 외에도 내가 장고를 잡기 꺼리고 레일즈나 스프링 MVC를 건드린 이유가 몇 가지 있었을 것이다. 파이썬 패키지 관리가 단연 첫째 문제였는데 (그래서 이번 서버는 우분투로 하고 pip만을 썼다) 다른 프레임워크에 비하면 파이썬은 몇백 배 나은 배포사용(deployment) 환경을 가지고 있었다... 그 다음 문제가 뭐였는지 기억도 잘 안 나고, 그냥 장고를 쓰기로 했다. 적절한 결정 덕분에 지금까지 별 난관 없이 장고로 그럭저럭 서버 하나를 완성해 나가고 있다. 유일한 문제라면 장고가 슬슬 마음에 안 든다는 것이다.

장고의 문제는 MVC 모두에 존재한다. 우선 M에서 가장 큰 문제는 장고 ORM이 정책적으로 DBMS에 구현된 기능에 대한 래퍼라는 것이다. 아무리 Enum의 구현이 RDBMS마다 다르기로서니 장고 규모의 프레임워크에서 models.EnumField가 없는 게 말이 되는가. 무조건 serial로 PK를 만드는 문제는 또 어떤가! 이런 정책은 ORM과 RM 모두에 해악이다. 한편 V에서 가장 큰 문제를 꼽자면, M과는 역설적으로 장고의 규모가 너무 크다는 점일 것이다. 나는 왜 @csrf_exempt가 데코레이터(decorator)여야 하는지 이해할 수 없다. 분명 장고의 액션 기반 HTTP 뷰 모델은 성공한 모델이고, 여타의 웹 프레임워크와 함께 놓고 보아도 꽤 성숙한 축에 속한다. 그러나 장고의 V를 이용해 좀 더 복잡한 일을 하려고 하면 반드시 문제가 생긴다. 거기 당신, 장고를 이용해 코드 중복 없이 XML과 JSON으로 된 API를 모두 제공하는 서버를 객체지향적으로 짤 수 있는가?

그러나 이와는 비교도 안 되는 문제가 바로 C의 문제이다. 운을 떼자면, 나는 SOAP/REST 양시론자이다. MVC냐 아니냐의 문제는 차치하더라도 여기서 문제가 발생한다. 장고의 URL dispatcher는 REST에만 대응한다. 그러나 그마저 반쪽 REST이다! 그 이유는 간단한데, URL만 신경쓸 뿐 Method에 따른 dispatching이 전혀 없기 때문이다. URL에 따라서만 뷰가 달라지는 프레임워크는 다시 말해 URL 패턴에 따라 뷰가 달라지는 환경에서만 사용 가능하다. 이 방식은 같은 자원에 대해 메서드와 헤더에 민감하게 반응하기 어렵고 따라서 OPTIONS나 Accept를 놓치기 쉽기 때문에 REST 의미론과 배치되는 경향이 있다. 그렇다고 장고에서 무리해서 메서드를 먼저 걸러내자니 뷰를 자원 객체처럼 만들게 되고 여러 URL 패턴을 하나의 뷰에 대응시키면서 지저분한 코드만 남는다.^[각주:1] 아마 이것이 앞으로 장고에서 고쳐지는 일은 없을 것이다. 참고로 URL과 Method dispatching을 모두 해 주는 프레임워크도 있다. 스프링 MVC가 대표적이다.

그래서 어떻게 할 거냐고? 물론 다음에 웹 서버를 만든다고 해도 여전히 파이썬을 쓸 생각이다. 하지만 새로운 프레임워크를 배울 시간이 모자라지만 않다면 다른 라이브러리로 건너갈 생각이 강하다. Flask같은 마이크로프레임워크는 영 취향이 아니고, 데이터 모델로는 SQLAlchemy를, 웹 서비스 모델에는 Werkzeug를 고려할 것이다. 아무래도 장고의 한계를 느꼈기 때문이다. 물론 장고는 좋은 웹 프레임워크이다. 그러나 연장 탓을 많이 하는 프로그래머에게는 남이 만든 프레임워크가 맞지 않는지도 모르겠다.

추가(2013-12-1 16:07). Class-based view를 어떻게 생각하느냐는 의견을 전달받았다. 일단 "괜찮지 않나, 잘 모르겠다" 정도로 대답했는데, 아무래도 장고를 더 써 봐야 알 것 같다. 클래스 기반 뷰 자체는 REST와 잘 상통하는 면이 있지만, 사실 이상적인 웹 서비스에서 REST의 자원 객체는 데이터베이스 ORM 객체와 크게 다를 게 없기 때문에 개념적으로 생각하자면 같은 모델을 두 번 정의하는 게 된다. 굳이 중복을 없애자면 데이터 모델을 만들고 DB나 HTTP API를 위한 데코레이터를 작성하는 방식이 나은데 이건 장고 프레임워크의 장점을 완전히 깎아 먹자는 말이므로 패스. 그리고 사족이지만 WebDAV같은 프로토콜은 django.views.generic.View를 평범하게 써서는 구현할 수 없다...

구체적인 예를 들자면, 회원 가입에 쓰이는 POST /account와 회원 열람에 쓰이는 GET /account/(id)가 있다고 하자. 이들은 사실상 같은 자원에 대한 다른 접근이기 때문에 URL에 따라 뷰를 바꾸기보다는 메서드로 먼저 걸러내고 (id)를 뜯어내는 쪽이 훨씬 적절하다. GET /account에서 어떤 오류를 돌려줘야 할지를 생각해 보면 명확하다. 그렇다고 r'^account$'와 r'^account/(?P<_id>\d+)$'로 나눌 수 있는 뷰를 r'^account(?:/(?P<_id>\d+))?$'로 하나의 뷰에 넣어야 하는가. [본문으로]

도메인 네임 바꿈

어리 — Fri, 15 Nov 2013 03:59:51 +0900

결론부터. un-i.tistory.com -> blog.aurynj.net 북마크/즐겨찾기한 분 계시면 주소 변경 부탁드립니다.

예전부터 도메인 주소를 하나 사려고 했다. 한때는 호스팅을 받아서 쓰던 서브도메인에 만족했지만 호스팅 업체에 배반당한 일이 한두 번도 아니고, 계속 주소가 바뀌다 보니 내 홈페이지라는 인식도 약해지고 뭔가 더 만들려는 의욕도 사라지고 그랬던 것 같다. 호스팅 자체의 한계도 많이 느꼈다. 문제는 어떤 도메인 주소를 사느냐는 것이었다. 물론 돈이 아깝다고 생각한 것도 있었다.

순수하게 개인 목적으로 좋은 도메인 주소를 장만하는 건 꽤 어려운 일이다. 회사 도메인이라면 잘 만든 회사 이름을 그대로 따면 되는데 그게 아니기 때문이다. 차라리 어릴 때 샀다면 내가 자주 쓰던 계정명에서 따서 냉큼 만들었겠지만 딱히 계정명에 애정이 있지도 않았다. 그렇다고 내 이름을 갖고 만들자니 알파벳으로는 어떻게 써도 제대로 읽히기 어려운 이름이라 영 별로였다. 그렇게 뜸을 들이면서 언젠가는 내 도메인을 하나 장만하겠다는 계획은, 언젠가는 내가 내 홈페이지를 멋지게 만들겠다는 계획만큼이나 원대하고 허황된 것이 되어 갔다.

고등학교 때부터 wo.tc 서브도메인을 쓰기 시작했다. DNSEver의 wo.tc 서브도메인 신규 등록이 닫히기 좀 전부터였다. wo.tc, tistory.com, tumblr.com 서브도메인에 공통적으로 등장하는 un-i는 꽤 낡은 아이디어였지만, 이건 당시 내 아이디어가 고갈되어 있었다는 데 대한 반증이다. 대학생이 되고 나서는 본격적으로 24시간 홈서버를 돌렸다. 한시름 놓았다. 그리고 소용없다는 걸 알면서 어떤 도메인 주소를 살지 가끔 주변 사람의 조언을 구했다.

드디어 만든 도메인 주소는 내 별명에 본명을 결합한 것이다. 굳이 읽자면 '어륀지'가 된다. ㅎㄷㄷ.

티스토리가 기존 주소를 2차 도메인 주소로 HTTP 301로 넘겨주지 않는 것은 실망이다. 아마 굳이 그럴 이유도 없고, 그렇게 해 봤자 티스토리 입장에서는 손해일지도 모른다. 아무튼 일단 이렇게 오래 놔 두고, 검색을 해 봤더니 이 블로그의 글을 링크하고 있는 글이 몇 개 안 되는데 블로그 주인들에게 말을 해 볼까 싶다. 봇이 크롤링한 결과야 어차피 갱신되면 되니까―이미 갱신된 게 많더라. 그러고 나면 홈서버로 블로그를 옮길 수 있게 된다.

IT, 우리는 제대로 보고 있나

어리 — Mon, 11 Nov 2013 17:19:05 +0900

서론

2년 반 넘도록 쓰고 또 써서 낳는 지긋지긋한 글이다.

처음에는 고작 한 달이나 잡고 쓰기 시작했는데, 막상 쓰기 시작하니 반 년을 넘기고 있었다. 그래서 그때는 짧은 시일 내에 마무리할 셈치고 이런 서론을 붙여 놓았다.

구상은 긴데 글이 끝나지 않아서 짧게 쓴다.

그것은 시작에 불과했다. 이 글이 누구를 위해 쓰인 건지 나도 모르겠다. 아마 관련 계열의 사람이 읽기에는 따분한 글이고 이쪽에 관심이 없는 사람에게는 뭐가 뭔지 모를 글일지도 모른다. 그것을 고민하면서 2년이 넘도록 이 글을 묵혔다. 이러다 글을 아예 버리게 될 것 같아 대강 마무리를 해 본다.

IT 강국이라는 타이틀

지금의 우리나라가 제대로 된 IT(정보기술) 강국이 아니라는 사실은 이미 많은 곳에서 지적되었다. 국가와 같은 시스템 단위에서 키우지는 못해도 자랄 환경이나 만들어지면 좋았으련만, 거품이 한 번 끼고 나니 소프트웨어에 대한 인식은 바닥을 쳤다. 애초에 IT 산업은 기존 산업 체계마냥 공장으로 굴리기 힘들기 때문에, IT 자체에 투자해서는 큰 돈을 만지지 못했음은 물론, IT를 '키울' 방법이 딱히 없었던 것이다. 그나마 이렇다 할 수익을 남겨 준 분야는 하드웨어였다. 기업도, 투자자도, 소비자도 모두 하드웨어에 열광했다.

그새 소프트웨어란 하드웨어를 돌리는 데 지나지 않는 존재가 되었다. 그렇다고 해서 국산 PC가 잘 설계되었냐면 그렇지 않다. 사실 시스템을 잘 설계한다는 말은 그 시스템을 돌리는 소프트웨어가 최소한의 노력으로 최대 성능을 발휘하도록 해야 한다는 뜻인데, 그런 것보다는 당연히 외국 모델 베껴서라도 시장 선점하는 것이 중요했다. 어쨌든 스펙을 어떻게 짜든 잘 돌릴 수 있고 쓰기 만만한 건 MS 윈도우였다. 다들 윈도우를 썼고, 엔드유저를 위한 소프트웨어 정책도 윈도우 기준으로 세워졌다. 리눅스? 어디서 들어 보기는 했지만, 쓰려면 고생 좀 한다며. 그런 사람들은 알아서 잘 따라오겠지. 때가 되면 편승할 수 있을 거야. 일단은 일반인이 쓰는 OS와 업그레이드 위주로 가자고. 그렇게 한국형 스마트폰 옴니아가 나왔다.

삼성전자의 옴니아 2 발표 당시 프로모션. 한때 이 이미지는 한국인이 스마트폰을 선택하는 잘못된 기준들을 자조하는 데 쓰였다. 그러나 사실 요즘 안드로이드 폰도 이런 기준으로 경쟁하고 있다.
여담이지만 첫 아이폰 발표 당시 스티브 잡스는, 훗날 iOS로 알려진 자사의 아이폰 운영체제를 소개하면서 앨런 케이의 "People who are really serious about software should make their own hardware."라는 말을 인용한다. 우리나라는 그때에 비해 크게 나아진 것이 없다.

그러나 IT의 커버리지가 공장에서 데스크, 모바일, 유비쿼터스, 스마트 식으로 넘어올수록 문제는 심각해졌다. 휴대폰의 성능 자체는 몇 년 전 PC 수준까지 상승했지만 여전히 '휴대폰'은 전화기였고, 연락처같은 부수기능은 필요한 만큼만 지원되었다. 물론 교과서스러운 꿈은 누구에게나 있었다. 이런 기기를 이용해 데스크탑의 연장선상에서 사람들과 더욱 복잡하게 통신하고 웹을 돌아다니는 한편, 플랫폼의 특성을 살려 인간 친화적인 네트워크 서비스를 이용할 수 있으리라. 그러나 아무도 IT의 본질에 대한 이와 상반되는 굳은 인식에 딴지를 걸지 않았다. 다들 하드웨어에 끼워맞춘 애플리케이션에는 그러려니 하고, 언젠가 하드웨어 기술이 발전할 날만 기다리고 있었다. 근본적인 의식의 문제임을 알고 있었던 사람은 이쪽 엔지니어들뿐이었다.

어느 순간부터인가 가능성은 폭발적으로 현실화되어 나오기 시작했다. 소위 IT 강국이던 우리나라의 일류 애국 IT 기업들은 이때부터 본격적으로 외국 기업에 줄줄이 썰려 나갔다. 과연 어떤 중요한 게 빠졌던 걸까? 아니, 애초에 우리나라에 빠진 게 있긴 했던 걸까? 혹시 다들 세계의 IT를 주도한 대한민국을 위시해 사기성이 짙은 유행을 들고 빠지는 건 아닌가? 이런 의구심마저 우리나라에 희망을 건 소비자들 자신에 의해 한 해가 지나기도 전에 무참히 반증되고 말았다. 기기 성능은 사실 크게 중요하지 않았다. 아이폰 흥행 이래로 지금은 누구든 하드웨어라 부를 만한 것이 소프트웨어를 충분히 백업하지 못한다는 걸 알고 있다. 옴니아가 좋았다고 말하실 분?

진심으로 반성할 때가 되었다

지금의 산업은 농경 사회를 뒤엎은 경험이 있다. 산업의 영웅들은 새로운 지식과 기법을 들고 나와 사회의 패러다임을 빠르게 바꾸었다. 인간 생활을 고도로 집약할 수 있게 된 이래 도시가 나타나고, 거의 모든 가치는 도시에서의 쓸모를 기준으로 재편되었다. 농업 또한 마찬가지였다. 아마 그 시대의 영웅들이 정보화를 산업에서 응용 가능한 수단 중 하나로 보는 이유도 이런 맥락에서 파악하면 쉬울 것이다.

그러나 그게 쉬운 일인가? 이 이야기를 결론짓기 전에 소프트웨어에 관한 이야기를 좀 하자. 소프트웨어와 떼려야 뗄 수 없는 단어가 '프로그래밍'이다. '프로그래밍 패러다임'은, 우리가 사물을 관념화할 때 필요에 따라 본질을 어떻게 해석해야 하는지에 대한 철학을 제공한다. 사람이 책을 읽는 과정을 프로그램으로 만든다고 생각하자. 이 과정은 간략히 경우에 따라 다음과 같이 분해될 수 있을 것이다.

사람이 책을 점유한다. 사람은 읽을 위치를 정해 책을 펼치고, 책으로부터 글자를 읽으며 책장을 넘긴다.
사람은 책을 읽을 수 있다. 사람이 책을 골라 읽을 때 책은 현재 책장에 맞는 내용을 사람에게 돌려 준다.
사람은 어떤 내용을 받아들일 수 있다, 책은 내용을 내보낼 수 있다. 책읽기는 그 내용 전달의 과정이다.

거의 모든 프로그래밍이란 이 중 하나 또는 하나 이상인 식이다.^[각주:1] 프로그래머는 이렇게 우리 주변에서 일어나고 우리가 사용하는 모든 것을 0과 1로부터 따라할 수 있는 관점에서 재구성한다. 그런 과정이 없다면 전기가 통해 봤자 열과 소음을 생산할 뿐인 전기제품이 갑자기 만능의 괴물로 변할 수가 없다. 하드웨어 계열에서 매일 붙들고 있는 논리구조라는 것도 이 수준으로 오면 내내 필수적으로 고려해야 하는 것 중 하나가 된다. 물론 모든 소프트웨어를 설계하는 과정에서 그렇다는 것은 아니고, 접근 방식도 조금 다르지만 말이다.

요즘 스마트폰이 안드로이드와 아이폰의 대결 구도인 것은 이제 상식이다. 그림은 무료 운영체제 소프트웨어, 안드로이드의 기초인 리눅스 커널의 구조를 나타내는 사진이다. 리눅스 커널의 소스 코드는 종이로 인쇄하면 50만 장에 달한다. 수백 권짜리 전집에서 내용 간의 관계를 이처럼 한 장의 그림에 담을 수 있겠는가? 잘 만들어진 소프트웨어에 대해서는 이것이 항상 가능하다.
(그림 원본 링크. 라이선스: 영어 위키백과 사용자 Conan 제작, CC 저작자표시 3.0 Unported)

주제넘게 관념적이라 생각한다면, IT의 본산인 미국을 보자. 좋은 소프트웨어를 설계하는 사람들은^[각주:2] 키보드를 두드리는 최전방 엔지니어이기도 하지만, 이런 관념을 연구해 온 사람들이다. 이를테면, 요즘 많이 언급되는 '좋은 UX'는 사실 소프트웨어 엔지니어링에서 많이 강조되던 UI 디자인 원리, Use Case 일관성 등을 뭉뚱그려 이르는 것이다. 소프트웨어 엔지니어링은 역사가 짧지만 단단한 입지를 가진 실용학문이다. 그러나 우리나라에서 소프트웨어 엔지니어링은 순수학문만큼이나 존중받지 못한다. 소프트웨어는 일단 단가로 후려치고 값싼 인력으로 빠르게 찍어 내서 20년 넘게 쓰는데, 누가 올바른 개념과 적합한 적용과 적절한 유지보수를 주장하겠는가. 이런 현실인데도 "컴퓨터공학의 한계"같은 글을 보고 있자면 솔직히 한심하다.^[각주:3] 아직도 이공계 앞에서 겸손해지지 못하고 있는 모양이다. 오히려 이공계에 인문학이 필요하다며 설레발을 칠 뿐이다. 그 깨어 있는 학자님, 여태 소프트웨어 분야에서 공석 안 찾고 뭐 하셨는지.

요컨대 농업의 모토가 자연과 시간과 노동, 산업의 모토가 경영과 자본이라면 정보화는 그것으로 이해되지 않는 제 3의 물결인 셈이다. 누군가 만약 산업의 눈으로 농경을 모두 보았다거나, 농경의 눈으로 산업을 보았다고 하면 기분이 어떻겠는가? 당사자들 입장에서는 코웃음이 나올 뿐이다. 물론 정보화 사회의 우월함을 주장할 생각은 추호의 여지도 없다. 필자는 산업계가 제발 소프트웨어라는 단어, 컴퓨터 사이언스라는 영역 앞에서 자만심을 버리고 고유성을 인정해 주기만을 바라는 것이다. 이 주장이 일부 산업의 영웅들에게는 멀고도 아득한 이야기가 되리라는 것을 잘 안다. 만약 그렇다면 적어도 뒤쳐지고 싶지 않은 입장을 공유하고, 이 시장에서 정보 산업이 자력으로 돈을 벌 길을 틀어막지나 않으면 된다.

어떻게 뒤쳐져 왔는가

지금 하게 될 이야기가 평범한 한국인이 알고 있는 IT 이야기이다. 이 대목에서 필자는 위의 비판 없이 앞으로 이어질 내용에 대해 무엇이 어떻게 잘못된 것인지 잘 쓸 수 없었다. 어느 정도 다들 아는 이야기로부터 글을 시작해야 읽는 맛이 나는 법인데, 재미 없는 구성이 되고 말았다.

역설적이게도 IT에 대한 몰이해를 주도한 것은 IT 부흥 당시 인문학자들이 아닌 공학자들이었다. IT의 본격적인 발전에 앞서 IT의 가능성에 대한 정성적인 연구와 예측이 있었기 때문에^[각주:4] 인문학자들 사이에서는 정보화가 산업화와는 다른 축을 구성한다는 것이 거의 사실로 여겨졌다고 보아도 옳다. 그러나 공학자들이 IT를 보는 방식은 다소 달랐다. 그들은 각자 자신의 기술 분야 현장에서 IT가 어떻게 응용되는지를 직접 겪게 되었다. 일부는 몸소 컴퓨터를 자신의 분야로 끌어들였다. 그리고 그들은 자신들의 경험에 비추어 이 기술 분야의 전망을 구체적으로 따지게 된다.

굳이 문제를 제기하자면, 소프트웨어의 본질은 당시의 컴퓨터 공학자들이 알던 것으로부터 그다지 변하지 않은 반면 소프트웨어 개발의 본질은 굉장히 많이 바뀌었다는 것이다. 오늘날 다수의 개발은 앞에서 말했듯이 추상적이고 개념적인 계층에서의 설계로 시작된다.^[각주:5] 좋은 개발 환경 덕분에 마우스 드래그 몇 번으로 산출물의 프로토타입이 나오고 심지어는 프로그램의 본체를 만들기도 한다.^[각주:6] 원시 코드가 수백만 줄에 달하고 똑똑한 컴파일러 덕분에 1000종이 넘는 하드웨어를 소화하는 하나의 소프트웨어도 있으며,10년, 20년이 넘도록 하드웨어 성능이 수천 배 성장하는 동안 수천명이 유지보수하는 소프트웨어도 있다.^[각주:7] 멀티미디어와 초고속 통신, 클라우드, 빅 데이터까지 소프트웨어의 규모를 기하급수적으로 뻥튀기하는 키워드는 차고 넘친다.

그리고 이 모든 분야가 컴퓨터 엔지니어, 컴퓨터 사이언티스트가 만들어 온 시대의 유산이자 미래의 무대임에도 불구하고, 많은 사람들은 컴퓨터를 공부해서 IT 강국을 만들고 돈을 벌 수 있다고 생각하지 않게 되었다. 특히 IT 버블이 붕괴한 여파가 가시지 않은 채 IMF 경제 위기가 왔기 때문에 더욱 그랬다. 한때 대학 입시에서 상경계열과 의과 분야에 어깨를 나란히 하던 공학은 그렇게 추락해서 인문학보다도 아래로 떨어지게 된다. 사실 소위 '감성 팔이'와 '미래의 IT'에 대한 식견은 누구에게나 있었다. 바보같은 투자, 바보같은 연봉 책정을 하지 않았을 뿐이다. 바보같은 중소기업이 없고 대기업만 있는 나라에서 피해를 본 건 인문학도 마찬가지였다.

요즘은 어떤가. 공학자들이 보는 소프트웨어는 더욱 바닥으로 떨어졌다. 컴퓨터의 접근성이 높아진 만큼 역설적으로 컴퓨터의 가능성은 오히려 낮게 평가된다. 다들 필요한 일에 잘 쓰기 때문이다. 웬만한 일은 비싼 데스크탑 시스템에서 매틀랩을 켜고 매뉴얼에 따라 코드 몇 줄을 입력하면 몇 시간 후에 원하는 결과를 얻을 수 있다. 자세한 이유는 궁금하지 않지만, 그들은 그렇게 배웠다. 그리고 그런 방식으로 자신들의 가치를 창출해 왔다. 산업 현장에서도 마찬가지이다. IT의 성과는 이전의 기술을 토대로 만들어진 부가가치일 뿐이다. 그것은 가산된 가치에 해당하는 만큼의 인적 자원으로부터 만들어지며, 그에 상응하는 대가 이하를 지불하는 것으로 거래가 성사된다. 비즈니스 모델은 변하지 않는다.

진정 어떻게 앞서나갈 것인가

요컨대 공학자가 보는 소프트웨어로부터 시작하자. 소프트웨어는 코드 조각으로 끝나는 것이 아니다. 소프트웨어를 이용해 자신의 분야에서 연구를 계속할 것이라면 단순히 계산 결과를 내는 것만으로는 충분하지 않다. 소프트웨어는 위의 '책을 읽는 과정'처럼 일목요연한 논리에 맞추어 섬세하게 모델화되고 나서야 비로소 그 연구자의 것이 된다. 그것은 이전처럼 단지 예정된 입력과 출력을 갖는 도구가 아니게 된다. 하나의 코드는 무엇보다도 명확한 언어로써, 논문의 일부가 되어 자신의 생각을 표현하며 다른 연구자의 구체적인 피드백에 대해 열려 있는 소통의 매개체가 된다. IT라는 분야는 한때 다른 분야의 교과서 끝자락에 '미래의 ~~기술'에 언급되는 것으로 충분했을지 모른다. 그 가능성은 거의 전부가 진작에 현실화되었다. IT에 대한 교과서, 컴퓨터 과학(전산학)에 대한 교과서를 읽을 때이다.

소프트웨어에 대한 이해는 기본 소양이 되어야 한다. 굳이 지금의 중등교육 시스템에 프로그래밍 교육을 넣어야 한다고 말하고 싶지는 않다. 오히려 모든 이가 소프트웨어라는 가능성과 창의성의 영역을 공부해야 하기 때문에, 지금의 중등교육에 소프트웨어 교육을 넣는 것은 환영할 일이 아니다. 단적인 예를 들자면 필자는 중학교 때 단순암기의 중압감을 버티지 못하고 국사를 거의 공부하지 않았다. 한편 한때 학생들에게 가능성과 창의성의 영역이었던 발명교육은 이제 완전히 외면받고 있다. 컴퓨터 분야가 이렇게 무너지는 것을 두고 볼 수 없다. 창의력은 환경의 문제이다. 초등학교 교육부터가 모든 학생들이 주류 교육학자들이 말하는 올바른 방식을 올바른 순서로 따르기를 강요하는데, 얼마나 많은 아이들이 자신이 남들과 다른 생각을 갖고 있다고 피력할 것인가? 필자는 학생들이 소프트웨어를 과목으로 기억하기 시작하고, 그래서 소프트웨어 관련 뉴스에서도 정답을 찾는 미래의 사회가 두렵다. 물론 소프트웨어 교육에서 부정적인 가능성만 제기하고 싶지는 않다. 긍정적인 가능성은 이미 많은 곳에서 지적되어 왔다.

어떻게든 우선 IT의 현재를 객관적으로 볼 수 있어야 눈을 뜨고 미래를 향해 직진할 수 있다. 이 과정에서 IT와 소프트웨어에 거품을 일으켜서는 안 된다. 머지않아 키보드와 마우스가 완전히 사라지고 영상인식, 음성인식이 그 자리를 대체할 거라는 공언을 본 적이 있다. 도대체 그때까지 시간이 얼마나 걸린다는 것인가?^[각주:8] 인간 친화적인 소프트웨어가 중요해질수록 소프트웨어와 관련된 노동의 절대량이 늘어난다. 소프트웨어가 노동으로 굴러가는 건 전혀 아니지만, 소프트웨어 노동은 바로 이 키보드와 마우스에 묶여 있다. 이른바 프로그래밍, 대놓고 말하자면 그 중에서도 코딩이다. 직접 IT를 공부하지는 않더라도, 그런 분들이 조언을 얻을 만한 이공계 쪽 전문가 한 분을 못 구하는 걸까? 하긴 컴퓨터만 붙잡고 있는 사람들이 글을 매일 수백 줄 고쳐 쓰고 있으리라고 생각하는 것은 쉬운 일이 아니다만, 이런 차이로부터 제대로 된 연구냐 아니냐가 구분되는 것이다.

전자공학, 생명공학, 의공학, 사회학 등등의 분야에서 이루어지는 컴퓨터 분야와의 융합 연구나, 사실상 컴퓨터 분야인 연구에 주목할 필요가 있다.^[각주:9] 이것은 저절로 이루어지는 것이 아니다. 정지훈(hiconcep)은 2011년 한 특강에서 미래를 주도적으로 설계하기 위해서는 IT와 관련된 융합학적 시선이 중요하다고 주장한다. IT는 사회를 바꿀 힘을 갖고 있고, 사회를 둘러싼 우리의 세계는 이미 변했다는 정확한 논지였다. 그러나 그 분은 "막상 사회의 구조가 변해야 우리가 주도를 할 수 있는데 과연 누가 그 일을 맡아서 하겠습니까"라는 질문에 "그건 느리게나마 저절로 됩니다"라고 답변한다. 불확실한 미래를 감수하고 몸을 던져 사회를 바뀌기를 기다리라는 말과, 자신이 몸을 던질 미래를 위해 사회를 바꾸는 데에도 신경써야 한다는 말이 있다면, 필자라면 후자를 택했을 것이다. 이 글은 그래서 쓰였다.

글을 주의깊게 읽고 있는 프로그래머라면 대강 이 목록에서 어느 것이 어떤 패러다임에 대응하고 있는지 눈치챘을 것이다. 절차지향 명령형, 객체지향, 함수형의 순이다. [본문으로]
페이스북처럼 좋은 세일즈 포인트를 말하는 게 아니다. [본문으로]
그 글의 요지는 대강 이랬다. 컴퓨터공학은 (소프트웨어공학을 의미하는 것이었을 테다) 제품에 집중하는 학문이기 때문에, 인문학적 소양이 없으면 상품을 만들 수 없다는 것. 우리나라 IT 제품들이 세계 시장에서 부진했던 것도 이 탓이었다고 터무니없는 근거를 들고 있었다. 이 시점에서는 좀 오래된 글이다. [본문으로]
대표적인 것이 로봇이다. [본문으로]
비전공자를 위해 일러 두자면, 원래 프로그래밍이란 최초의 전자식 컴퓨터로 흔히 일컬어지는 에니악(ENIAC)에서도 행해지던 것이다. 에니악의 엔지니어는 계산이 하나 끝날 때마다 계산식을 바꾸기 위해 집채만한 진공관들의 배선을 손수 바꿔야 했다는 이야기가 있다. 우리가 쓰는 프로그램 파일의 0과 1은 그때의 0과 1에서 달라진 것이 없다. 어찌 보면, 다만 그 0과 1을 한땀한땀 만들지 않게 된 것뿐이다. [본문으로]
이런 빠른 프로토타이핑, 빠른 개발이 좋은 문화인지는 논외로 하자. 관점에 따라 장단점이 있다고만 언급하고 넘어간다. [본문으로]
리눅스 커널. 정확한 수치는 찾아보면 나온다. [본문으로]
솔직히 미래학자에게 '그게 도대체 언제라는 말이오' 식의 응대는 정말 힘 빠지는 게 아닐 수 없다. 하지만 연구에 제대로 된 응대를 받으려면 우선 정성적인 절차를 거쳐야 할 것 아닌가. 당시 그 발언이 단지 일반인의 컴퓨터 사용에 대한 주장이었다 해도 터치스크린이나 동작인식이 없어서 틀렸다. 뇌파라고 했으면 모르겠다.. [본문으로]
당장 국비 과제가 분야를 넘나들지 못하는 건 우리나라의 많은 학계에 부정적 영향을 주고 있다. [본문으로]

개인 홈페이지 완전개편

어리 — Mon, 28 Oct 2013 12:37:44 +0900

이전부터 굉장히 밀어 버리고 싶던 개인 홈페이지. 시험기간을 맞이해 밀고 말았다. 별 얘기 아님.

잘 쓰지도 못하는 영어 그냥 없앨까

사실 내 홈페이지를 찾아 들어 올 사람이 있다는 생각도 없다. 10년 가까이 굴려 온 개인 홈페이지라는 이름을 붙잡고 있을 뿐이다. 성의 없이 이곳저곳을 전전하다 몇 번은 호스팅 업체의 친절한 정책 덕분에 다 날려먹고 바닥부터 새로 작성했다. 주변 사람들 영향도 많이 받았다. 플립 날아간 노트북을 개인 서버로 쓰기 시작한 이후로는 웬만한 작업이 웹 프로그래밍보다는 서버 프로그래밍이 되어 홈페이지는 뒷전인 상황이기도 하다. 한때 HTML5라든지 CSS3 연습의 희생양도 내 홈페이지였다. 지금은 서브도메인도 파고 작업실 링크도 걸어 놔서 꽤 안정적이 됐지만 내 웹 삽질의 흔적이 많았다.

전후 비교가 되면 글이 좀 나오겠지만, 워낙 쓰레기였다 보니 버전 관리를 할 생각이 안 든다 -_-; 우선 main.css에서 시작해 screen|print로 내려오던 media query 위계를 바로잡았다. print에 필요없는 값들은 모조리 screen으로 분리해 섣부른 모듈화를 밀어 버린 것. 그러고 나서 screen에는 내내 미루던 landscape와 portrait를 적용했다. 여기에 따라 탭의 위치와 페이지의 배치가 약간 달라지는데, 시행착오의 결과 기대하던 스타일이 나왔다. box-shadow를 생략한 print도 모양이 꽤 좋아졌다. 기분이 좋아져서 aural과 braille 스타일 파일도 만들어 놨다. 쓸 일은 없겠지.

내용도 영 개판이었다. 일단 각 탭 구성에서 내가 만들어 놓았던 포털스러운 허세와 퍼즐같은 복잡함을 모조리 뺐다. 문서의 느낌, 개인 홈페이지 느낌으로 돌아가기 위해 애썼다. 거의 모든 문장을 갈아엎고 새로 썼다. 그 작업이 방금 끝났다. 마무리는 jQuery 2. 언제적 1.7을 돌리고 있었는지 버벅이던 게 상당히 준수해졌다. 이렇게 고치고 좀 씁쓸한 사실이 있다면 IE8부터는 괜찮던 홈페이지가 이제는 IE8에서까지 바삭바삭해졌다는 것 정도겠지.

네 줄 요약

IE8도 놓고 가야 하는구나.
이대로라면 남은 삽질은 기말고사때 하는 건가.
세 번째는 없다
이것도 곧 마개조되고 지저분해지고 또 공중분해될 것이다.

만화로 본 발명·특허 이야기 (2001)

어리 — Tue, 22 Oct 2013 05:33:03 +0900

특허청의 사업으로 나온 책. 어떻게 얻었는지는 잘 기억나지 않는다. 특허청 사무소는 아니겠고 아마 중학교 때 과학반 활동하면서 관련 일로 상공회의소에 찾아갔다가 한 권 집어 왔겠지. 새삼 말할 것도 아니다만 이 책은 발명과 특허(특히 특허제도)를 처음 접하는 사람에게 더없이 좋은 교본이다. 그리고 이미 발명에 몸담고 있는 사람에게도 그럭저럭 하나쯤 갖고 있을 추억의 기본서 정도는 되리라 생각한다. 물론 이 시점에서 발명 이야기를 구구절절이 하고 싶은 생각은 없다. 게다가 이 책은 다소 어린 학생 독자층을 대상으로 하고 있는 느낌인데 당시 꽤나 인기있던 발명 영재 유행과 같은 맥락에 놓고 보면 그다지 긍정적인 책인 것만은 아니다. 사실 나는 영재라는 단어의 남용을 퍽 탐탁찮게 생각한다. 요즘 발명 영재 쪽은 완전히 한물 가지 않았는가. 아마 소프트웨어 쪽도 요즘 꼴을 보면 평균적으로 돈 잘 벌기는 텄고 머지않아 같은 길을 걸을 지도 모른다. 아아 내 분야가 위험하다니 이게 무슨 소리요.

각설하고. 꽤 오래 된 책인데도 이 제목으로 검색해 보면 당시 기사가 아직도 나온다. 한 가지 흠은 ISBN이 없다는 것. 다행히도 공식적으로 이 자료에 대한 식별번호는 국립중앙도서관에서 관리하고 있었다. (검색해 보면 나온다.) 왜 ISBN이 없을까 하는 질문에 대한 답은 간단하다. 정부기관 자료인데 기관이 힘이 없어서도, 돈이 없어서도 아니다. ISBN에 필요한 온갖 식별항들을 구축하기 귀찮기 때문이다. ISBN은 국제 바코드 표준인 EAN/GTIN-13에 호환되도록 설계되어 있는데, 국가 번호 자리에 978이 들어가고 "978 - (국가/언어권 번호) - (발행자/출판사 번호) - (도서 번호) - (체크 자리)"가 되는 식이다. 다소 기술적인 얘기를 꺼냈는데 아무튼 정부 기관이라 해도 출판물에 ISBN을 다는 건 그걸 배제한 일에 비해 꽤나 번거로운 모양새가 된다는 것이 핵심이다. 우선 우리나라(ISBN 국가 코드 89)의 서지정보 관리 기관인 '국립중앙도서관 한국문헌번호센터'에 서류를 보내 발행자 번호를 취득한다. 만약 그 기관에 이미 발행자 번호가 있다고 해도 마음대로 도서 번호를 붙이는 게 아니고, 이 또한 신청해서 승인을 받아야 한다. 그리고 일단 ISBN을 붙이면 공중에 유통될 가능성을 배제하지 않는 것이 되기 때문에 사후 관리도 꽤나 힘든 일이 된다. 공무원들의 일에 이 모든 걸 기대하는 건 사치다.

그나마 중앙 정부기관에서 나온 것은 이렇게 국립중앙도서관에서 수집된다. 이는 다름아니라 도서관법에서 도서관자료의 납본을 강제하고 있기 때문인데(어길 경우 과태료를 문다!), 사실 특허청은 중앙 정부기관인 데다 경험있고 머리 좋은 사람이 많아서 자체 코드로 자료를 관리하고 있으며 납본도 꼬박꼬박 할 것이다. 지방에서 일하는 방식은 이와 달리 대체로 답이 없는 편이다. 물론 말단 공무원 입장에서는 법적으로 공개가 요구되는 자료만으로도 작업량이 어마어마하기 때문에 웬만한 자료는 때가 되면 과감히 버릴 수밖에 없다. 하지만 사실 웬만한 자료의 열람이 가능한 지역 자치 시설, 교육 기간 시설의 자료실도 도서관법 상의 도서관에 준하기 때문에, 1년이라도 보존되어 자료실에 있던 자료라면 도서관자료이고, 원칙적으로 사본을 국중도에 납본해서 보존하는 게 맞다!

아무래도 나는 일하는 당사자가 아닌 주제에 이상적인 말만 늘어놓는 보존주의자에 불과한데, 할 말은 해야겠다. 빅 데이터를 강조하는 시대에 공공 정보의 접근성은 도대체 어디로 가고 있는가? 지금 우리나라는 정보공개의 역효과로 대중 사이에 만연한 정치적 무관심과, 그런 공공정보 하나 얻으려면 법적 근거도 없이 개인정보를 우선 제공하고 온갖 보안 플러그인을 설치해야 하는 상황에 동시에 직면하고 있다. 사실 뒤늦은 감이 있지만 이런 문제는 출판으로 해결할 수 있다. 인터넷에 공시해야 한다면 전자책으로 공시하면 되지 않는가. 전자책도 꽤 잘나가겠다, 열람 비용 문제는 전자책의 방식으로 처리하는 한편 이전처럼 학생의 접근성은 침해하지 않는 게 가능하다. 여기서 전자책의 포맷을 굳이 고집할 생각은 없다. 관련 사업에서 적당한 전자책 제작 소프트웨어, 액티브엑스 전자책 뷰어로 돈만 벌 SI 회사를 생각하면 오히려 아니올시다이다. 결론은 보존은 쉬운 일이 아니라는 사실이다. 우리 앞에는 예산, 인력, 적극성, 아이디어, 접근성 등 모든 게 넘어야 할 산으로 남아 있다. 이를테면 통계청을 선례로 삼아 중앙기관이 앞장서서 출판을 시작하고 지방에서 그 뒤를 따르면 어떨까. 아무래도 기관 간에 밥그릇 간섭 안 하는 문화도, 상명하복의 문화도 고쳐져야 할 듯하다. 결론을 이렇게 내자니 앞으로 정부 기관이 지금보다 정보 접근성을 높이기는 글러먹었군.

어떤 웹 브라우저를 써야 합니까

어리 — Fri, 11 Oct 2013 18:37:25 +0900

어떤 웹 브라우저를 써야 합니까. 내가 상당히 많이 받았던 질문인데, 이는 다름아니라 내가 2007년 무렵부터 Internet Explorer 6를 쓰지 말아야 한다고 내 주변 사람들에게 몸소 광고를 하고 다녔기 때문이다. IE6를 쓰지 말라는 건 하나의 주장에 불과하기 때문에 나는 이 주장에 대한 쉽고 합리적인 근거를 찾느라 꽤나 애를 먹었다. 게다가 이미 내 이야기를 듣는 사람들은 IE6를 사용하고 있었고 그걸 인터넷이라는 이름으로 알고 있었다. 내 호소에 면면이 공감하더라도 그 사람들은 그 대체재에 대한 견해를 그 호소의 당사자인 나로부터 구할 수밖에 없었다. 나는 그것을 감수했다. 물론 항상 일이 잘 진행된 것은 아니다.

이 문제는 시간이 흐르고 흘러 IE의 다음 버전이 끊임없이 나오고 Windows 7이 나온 지금까지도 이어져 오고 있다. 왜 관공서에서는 아직도 Windows XP와 Internet Explorer 6를 쓰고 있는가? 이는 사실 "알 수 없는 출처의 애플리케이션 설치를 허용하세요"만큼이나 심각한 컴퓨터 보안 불감증의 문제이기도 하지만, 문제는 무조건 익숙한 것이 우선일 때 작업 능률이 증가한다는 것이다. 하나의 전산망이 똑똑한 시스템과 약간 멍청한 시스템에 동시에 대응하기를 바라는 것은, 학교에서 바른 생활 사나이이고 수능 모의고사도 만점을 받는 학생이 밖에 나가면 날라리인 생활을 수십 년 지속하기를 바라는 것만큼이나 미친 짓이다. 결론적으로, 행정 전산망과 웹서비스는 IE6 기반이다. 이는 근 몇 년 동안 이 작업 환경에 완벽히 적응한 새로운 공무원들을 양산하는 데 일조하기까지 한다.

사실 어떤 분야의 소프트웨어는 하드웨어의 발전으로부터 상당히 동떨어져 있는 것 같지만, 그런 분야는 없다. 이는 업무용 소프트웨어와 정부, 사내 프레임워크에도 마찬가지라서, 하드웨어가 그렇듯 소프트웨어도 몇 년 지나고 나면 몇 푼의 유지보수만으로는 버틸 수가 없게 된다. 갈아엎지 않으면 완전히 구시대의 유물이 되는 것이다. 윈도우 폰이, 대표적으로 2010년도의 옴니아 2가 결국 어떻게 되었는가를 생각해 보면 편하다. 하지만 쓰던 소프트웨어를 쓰고 또 쓰고 다시 쓰려는 관성은 유독 한국인에게 강한 건지, 그냥 소프트웨어 엔지니어의 입김이 약한 건지 알 수 없는 노릇이다. (행정망과 달리 기업의 사내망은 IE6 기준으로 남은 곳이 없다고 보면 된다. 행정직의 입김이 세다고 결론내려지는 순간이다.) 사실 지금 웹 브라우저가 뭔지를 모르는 사람은 거의 없다. 모바일에서 IE6를 계속 쓰는 사람은 옴니아 2를 쓰는 사람만큼이나 많다(적다). 그럼에도 불구하고 데스크탑과 모바일에서 같은 웹브라우저를 쓰는 장점을 못 누리는 사람은, 옛날에 웹 브라우저가 뭔지 모르던 사람만큼이나 많다. 물론 이는 프로모션의 문제이고.

아무튼 옛날의 나는 그렇게 좋은 방식으로 웹브라우저 전도를 한 것은 아니었다. 나는 웹 브라우저라는 생소한 지식을 가진 사람 앞에 파이어폭스와 크롬이라는 두 가지 선택지를 내밀었다. 언젠가부터는 크롬을 추천했지만, 파이어폭스를 추천한 적도 있다. 다른 웹 브라우저의 장점은 무엇인가? 빠르고, 바이러스가 끼어들 여지가 적으며, 동기화와 온갖 확장 기능이 있다! 심지어 윈도우와 독립적으로 자동 업데이트가 되기 때문에 이 모든 장점이 끊임없이 발전한다! 이런 접근은 소프트웨어 엔지니어에게는 좋은 홍보 방법이지만, 일반인 앞에서는 윈도우가 나쁘고 리눅스가 좋다는 소리만큼 한숨 나오는 접근에 불과하다. 중요한 것은 일단 빠르다는 것이고, 인터넷 익스플로러에서 쓰던 북마크를 그대로 가져 올 수 있다는 것이다. 그리고 웬만한 시스템은 점점 많아지는 바이러스에 허덕이고 있기 때문에, 웹브라우저를 바꾸는 건 일단 시스템을 대대적으로 청소한 이후에 행하도록 한다. (포맷을 하면 더 좋다. 어차피 IE6를 오래 쓰면 포맷은 종종 하게 되어 있다.) 그래야만 보안성이 좋은 웹브라우저라는 게 무슨 뜻인지 체득할 수 있기 때문이다.^[각주:1]

물론 한때 IE6는 범세계적 실용 표준(de facto standard)이었다. MS의 다소 무책임한 마케팅으로 월드 와이드 웹이라는 공공재는 IE6에 잠식되었고, 이는 구글 크롬에 의해 반복되는 역사가 되고 있다. 오늘날 IE6 호환성 이야기는 어느 정도 IE6의 문제로 결론지어진 것 같지만, 우리 삶에서 이 문제는 아직 끝나지 않았다. 최종 사용자 입장에서는 문제가 굉장히 복잡해진 것이다. 다소 웃기는 것이 있다면, 실용 표준이 법적 표준(de jure standard)을 앞서는 현상은 일반인에게서 더 자주 발견되더라는 것이다. 내가 만난 누군가는 다른 웹 브라우저를 쥐어 줬을 때 누가 뭐래도 IE6를 기술 표준으로 판단하고 있었다. 문제 많은 액티브엑스도, 사람 정신을 혼미하게 하는 툴바도 필수 기능이 된다. 잘 보이던 웹 사이트가 크롬에서 깨진다고? 크롬의 잘못이지! ^[각주:2] 이런 사람들은 환경적인 영향으로 강제로 웹브라우저를 바꾸게 하지 않으면 답이 없더라. 그런데 우리나라 대표 포털 웹사이트인 네이버가 당시 새 웹표준에 굉장히 게으르게 대응했기 때문에 IE6를 쓰는 사람들만 굉장히 편했다. 게다가 우리 나라에서는 실용 표준뿐만 아니라 법적 표준도 IE6이다! 소프트웨어 엔지니어들이 IE6 얘기만 나오면 거품을 무는 건 이 때문이다... 혹시 모르지, 어느 날 네이버에서 지금 운용하는 웹 페이지들을 모두 IE8 이하에서 깨지게 하면 어르신들이 불만을 가져 지금이라도 법적 표준이 바뀔지도. 물론 현실성이 없는 얘기라는 건 안다. 아니 그보다도 왜 이 장유유서의 나라는 어르신이 불편해야 비로소 바뀌는 거야...

이런 접근에 관해서 참고가 될 만한 글을 붙인다. 강성훈, 두벌식과 세벌식. [본문으로]
두벌식을 쓰다 세벌식으로 간신히 건너온 사람이 뜬금없이 "예전에는 웃길 때 '으앜ㅋㅋㅋ'이라고 썼는데 세벌식은 이게 안 되니까 짜증난다"라고 한다고 해 보자. 도깨비불 현상을 싫어하는 세벌식 유저는 얼마나 황당한가... [본문으로]

페도라 19로 늦은 업그레이드

어리 — Fri, 11 Oct 2013 17:39:34 +0900

뭐 특별한 내용은 아니고 업그레이드 후기 및 잡설. rpmfusion 관련 문제도 꼬이고, 리눅스에서 개발할 일도 없어서 꽤나 오래 페도라 업그레이드를 안 하고 지냈다. 거의 반 년. 그러다 이제 슬슬 방학도 끝났고, 새 학기 접어들어 뭔가 시작하려다 보니 네이티브를 안 쓸 수가 없었다...-_-; 물론 새 학기라서 뭔가 삽을 뜰 수 있으리라고 생각한 건 오산이었다.

무튼 우선 rpmfusion 문제를 해결했다. 그냥 --nogpgcheck을 돌렸는데, 지난번에 fedup으로 업그레이드하면서 남은 rpmnew 파일이 gpgcheck=1로 되어 있어서 yum이 이러지도 저러지도 못하는 상황이었다. /etc/yum.repos.d에서 rpmnew 파일을 직접 수정해야 했다.(지금 fedup은 gpgcheck=0을 유지하고 업그레이드해 주기 때문에 이런 문제는 없다.) 그리고 나서야 마음놓고 모든 패키지를 fedora 18 최신으로 올렸다. gnome-shell이 버전 3.6.3으로, ibus이 1.5.3으로 올라갔다. 당장 나를 매우 골치아프고 불편하게 만들던 이 둘의 속도와 잔버그(예: 레이아웃 전환 중 포커스 잃음)들은 많이 개선되었다. 물론 속도는 여전히 불편하더라. 그래도 fedup 돌리기 귀찮아서 몇 주를 더 썼다.

그리고 지난 7월에 나온 fedora 19. 어제 드디어 fedup --network 19 --disablerepo fedora-yumex를 돌렸다... timlau/yumex가 fedup을 지원하지 않는 건가? 어찌됐든 1Mbps도 안 나오는 속도만 아니었다면 스트레스는 좀 덜 받았을 것 같다. 오늘 새벽이 다 되어서야 리부트를 시키고 자고 일어나니 업그레이드가 끝나 있었다. 예의 gnome-shell은 3.8.4, ibus는 1.5.4인데, 모든 버그와 레이턴시가 날아갔다. 로그인 속도도 빨라지고 심비어 gnome-tweak-tool에서 Alt_R을 붙여도 마냥 빠르다! 그 밖에도 업그레이드 릴리즈 이후 석 달 지난 배포판답게 몇 가지 바뀐 패키지가 있다. 당장 찾은 건 glew 1.9.0인데 많은 걸 비교분석할 처지는 아니고... git이 아직 1.8.3인 이유는 잘 모르겠지만 조만간 업데이트되겠지. 네트워크 제어판이 핫스팟 키프레이즈를 처리 못 하고 다운되던 버그도 수정.

결론부터 말하자면 페도라는 여전히 좋은 배포판이고, 더욱 좋아지고 있다. 나는 아무래도 요즘 페도라의 업데이트 정책이 잘 유지될 수 있을까 걱정하던 중이었다. 내가 우분투를 쓰지 않는 이유는 우분투의 기원인 데비안 때문인지, LTS와 LTS가 아닌 판의 안정성 및 업데이트 차이가 너무 심한 것이 이유이다. 물론 오픈소스 소프트웨어들이 점점 신나게 발전하고 있고 여기에 안정적으로 대응하기 어렵다는 사실은 부정할 수 없다. 그 때문인지 페도라 17, 18에서는 배포판 업그레이드와 빠른 업데이트의 중간적 대응이 흔들리는 느낌이었다. 하지만 일단 올라와서 보니 그건 내가 페도라 18을 오래 쓰느라 가진 기우였던 것 같다. 페도라 19를 초기부터 쓰고 지금은 20 알파를 쓰는 지인에 의하면 지금 페도라는 충분히 안정되어 있다고.