이 블로그는 방문자 통계를 위해 티스토리 기본 기능과 Woopra를 사용합니다. 원하지 않으신다면 사용하시는 웹 브라우저에 내장된 DNT 헤더를 켜고, JavaScript를 끄셔도 무방합니다.
이 블로그 방문자의 약 60%는 네이버 검색을 사용하십니다. 을 이용하시면 더 유용한 정보를 쉽게 얻게 되실 수도 있습니다. [mediatoday]
« 2018/04 »
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          
블로그 이미지
제가 주제인 블로그... 그냥 주제 없는 블로그입니다. 전공 분야나 예전 관심 분야 등등에 관한 글이 우선입니다만, 두어 문단을 넘길 만한 글이라면 대강 정리해 기록합니다. 학부생입니다. 트위터에서 볼 수 있습니다. http://aurynj.net/ 어­리


장고는 반쪽 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+))?$'로 하나의 뷰에 넣어야 하는가. [본문으로]

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

Views/Overview | 2013.11.11 17:19 | Posted by 어­리

서론

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

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

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

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

IT 강국이라는 타이틀

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

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

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

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

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

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

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

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

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

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

http://en.wikipedia.org/wiki/File:Linux_kernel_map.png요즘 스마트폰이 안드로이드와 아이폰의 대결 구도인 것은 이제 상식이다. 그림은 무료 운영체제 소프트웨어, 안드로이드의 기초인 리눅스 커널의 구조를 나타내는 사진이다. 리눅스 커널의 소스 코드는 종이로 인쇄하면 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는 사회를 바꿀 힘을 갖고 있고, 사회를 둘러싼 우리의 세계는 이미 변했다는 정확한 논지였다. 그러나 그 분은 "막상 사회의 구조가 변해야 우리가 주도를 할 수 있는데 과연 누가 그 일을 맡아서 하겠습니까"라는 질문에 "그건 느리게나마 저절로 됩니다"라고 답변한다. 불확실한 미래를 감수하고 몸을 던져 사회를 바뀌기를 기다리라는 말과, 자신이 몸을 던질 미래를 위해 사회를 바꾸는 데에도 신경써야 한다는 말이 있다면, 필자라면 후자를 택했을 것이다. 이 글은 그래서 쓰였다.

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

개인 홈페이지 완전개편

System Idle Talks/어리::일상 | 2013.10.28 12:37 | Posted by 어­리

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

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

사실 내 홈페이지를 찾아 들어 올 사람이 있다는 생각도 없다. 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도 놓고 가야 하는구나.
  • 이대로라면 남은 삽질은 기말고사때 하는 건가.
  • 세 번째는 없다
  • 이것도 곧 마개조되고 지저분해지고 또 공중분해될 것이다.


'System Idle Talks > 어리::일상' 카테고리의 다른 글

개인 홈페이지 완전개편  (0) 2013.10.28
흔한 교회 선전물 단상  (0) 2013.05.26
근황 + 분류를 갈아엎었습니다  (0) 2013.02.22
990원짜리 채소모듬  (2) 2012.06.12