이 블로그는 방문자 통계를 위해 티스토리 기본 기능과 Woopra를 사용합니다. 원하지 않으신다면 사용하시는 웹 브라우저에 내장된 DNT 헤더를 켜고, JavaScript를 끄셔도 무방합니다.
이 블로그 방문자의 약 60%는 네이버 검색을 사용하십니다. 을 이용하시면 더 유용한 정보를 쉽게 얻게 되실 수도 있습니다. [mediatoday]
« 2017/12 »
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
블로그 이미지
제가 주제인 블로그... 그냥 주제 없는 블로그입니다. 전공 분야나 예전 관심 분야 등등에 관한 글이 우선입니다만, 두어 문단을 넘길 만한 글이라면 대강 정리해 기록합니다. 학부생입니다. 트위터에서 볼 수 있습니다. http://aurynj.net/ 어­리


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

분류없음 | 2013.12.14 00:51 | Posted by 어­리

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

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

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

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

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

저작자 표시
신고

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


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

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

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

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

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

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

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

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

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

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

저작자 표시
신고

장고는 반쪽 MVC이다

Sablog Models/인터넷·웹 | 2013.12.01 02:13 | Posted by 어­리

요 며칠 간 프로젝트를 진행하면서 장고(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를 평범하게 써서는 구현할 수 없다...

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