...++
=

“뉴 미디어” 운운하는 이야기들을 보다가 최근 새삼스럽게 발견했다.


#1

KBS 아침뉴스타임 같은 공중파 뉴스 프로그램들은 매일 아침 시청자들에게 리스티클(스낵콘텐츠)을 공급하고 있다. 왜 그런 것 있잖은가 뒤뚱거리는 새끼오리 영상을 리포터가 1분간 열심히 해설하던 그런 방송들.


#2

교차로신문은 뉴시스, 경향신문 등의 정보성 기사를 2차 퍼블리싱하고 있다. 뿐만 아니라 독자적으로 사설칼럼(‘아름다운 사회’) 지면도 운용 중인데, 이 지면은 거쳐간 과거 집필진만 20명이 넘는 유구한 전통을 자랑한다.


뉴비들의 미디어는 있을지 모르겠다. 하늘 아래 새로운 미디어가 있다? 글쎄올시다.

'2 다른 이들의' 카테고리의 다른 글

#AnimeRight  (0) 2017.02.11
주식회사 버그햄버그버그  (0) 2016.03.21
시드노벨 표준 조판 양식.hwp  (2) 2015.11.30
봐야 될 다큐들  (0) 2015.11.13
“다음엔 어디를 공략할까”  (0) 2015.09.14
Posted by 엽토군
:

​최근 TV조선쨩의 상태가 조금 이상한 것 같다만?













크 백만년만에 방송국 가시내
집에 와봤더니 TV조선이 켜져있길래 잠깐봤다 15분 동안 저 병크가 실제로 다 터지는걸 보는데 뭔가 알수없는 방송 같았다.

'1 내 > ㄷ 그림' 카테고리의 다른 글

좃쭝똥 가시내 65  (0) 2016.07.17
지상파 가시내 64  (0) 2016.02.27
문사철은 괴롭다  (2) 2015.06.27
공중파 가시내 62  (0) 2015.04.25
지상파 가시내 61  (0) 2015.03.24
Posted by 엽토군
:

주어진 임무:

10팀의 아티스트가 만든 10개의 전시물에 대해 국문/영문 소개문, 사진, 아티스트 소개 등을 보여주는 그럴듯한 모바일 브로셔를 만들어라.


실제 돌아가는 결과물: upcyclingtree.dothome.co.kr


전체 소스:

github.com/yuptogun/Upcycling-Tree-Mobile-Flyer




Day 1

  • 백엔드가 의외로 고민거리였다. 아무 생각없이 정적 페이지 10*n개를 만들면 머리는 편하겠지만 손이 고생할 거다. 10개의 팀과 10개의 작업물과 각 작업물에 들어가는 n개의 사진을 그렇게 매뉴얼하게 관리하다 보면 분명 어딘가 하나쯤 꼬일 테니까.
  • 요컨대 데이터에 최소한의 체계성을 부여해야 한다. 그렇다고 DB 스키마 짜고 CI 같은 본격적인 프레임워크를 깔고 싶지도 않다. 너무 일이 된다. phpSlim 같은 간단한 라이브러리는 아직 건드려도 못 봤고... 음 어떡한다?
  • 일단 MVC 자체는 매뉴얼하게 가기로 결정하고 array.php를 작성. 내가 알아보고 관리할 수 있는 선에서 가장 원초적인 정적 데이터배열을 만든다. 이걸 include한 다음 get파라미터에 담긴 변수 따라서 원소 출력시키지 뭐. 어차피 모바일로 잠깐 보고 끌 페이지이기 때문에 URL prettify는 안 해도 된다고 판단.
  • 프론트엔드가 그 다음 골칫거리였다. 아무 생각없이 Bootstrap이나 PureCSS를 쓰면 손은 편하겠지만 눈이 고생할 거다. 애초에 모바일 브로셔로서 갖춰야 할 최소한의 미적 감각을 담보할 수가 없을 것이다. 뭐 괜찮은 프론트엔드 프레임워크 없나? 막 뒤져봄.
  • 예전에 한번 보고 지나갔던 Framework 7이라는 놈을 다시 찾아냄. 안드로이드/iOS 앱개발자들이 웹개발도 비슷한 느낌으로 해낼 수 있도록 만든 (것으로 생각되는) 소스이다. 지원하는 컴포넌트를 살펴보니 이건뭐 거의 아이폰 네이티브 앱 와꾸가 나오는 게 구상 및 설계상의 문제가 일거에 해결됨. CDN이 있나? 살펴보니 있었다! 오케이 너로 정했다.
  • index.php를 짜면서 CSS 클래스와 컴포넌트, js에 익숙해지는 데 하루의 나머지를 다 보냄. 아직은 전체 틀만 잡고 있었으므로 근본 원리는 파악하지 못한 (몰라도 괜찮았던) 단계. 이때는 $data[i][9](index에서 띄울 섬네일 url) 같은 것이 없었다.
  • 메뉴 구현은 다음과 같다. navbar사이드패널 여는 버튼을 넣고, 그 안에 사이드패널 닫는 버튼을 하나 만들어 넣기. 별문제없이 작동.
  • 이미지 호스팅은 비공개 텀블러를 사용하기로 함. 되는 거 확인하고 퇴근.



Day 2

  • 출근하자마자 원래 index.php에 통째로 들어 있던 header.php 부분과 footer.php 부분을 분리. 잘 작동하는 것 확인. (개인적으로 뷰를 아예 새로 작성할 때 !doctype html로 시작해서 전체를 다 짜둔 다음 header, footer 등으로 오려내는 습관이 있다. 좋은 습관이 아니다.)
  • 최소한의 그리드가 필요하다는 것을 알게 되어 pureCSS의 base.css만 따로 로딩함.
  • 사이드패널에 뿌려놓은 메뉴 링크들을 눌렀는데, 404나 에러페이지로 넘어가지 않고 그냥 깜박이고 마는 것이 너무 신기했다. 이개모지? 나중에 쓰겠지만, 프레임워크7의 핵심 작동 원리인 "AJAX 프리로딩" 덕분에 가능한 것이었음.
  • framework 7의 기본 CSS는 사이드패널에 리스트로 띄운 메뉴 텍스트를 죄다 자동으로 ellipsis로 줄여버리더라. 작품들의 이름이 좀 길고, 모바일에서 그걸 다 볼 필요가 있기 때문에, 걍 CSS를 뜯어고쳐 다 띄우게 만들어둠.
  • 이제 핵심이라고 할 수 있는 detail.php를 작성하기 시작. 원래 구상은 이랬다.
    - 적당한 GET파라미터가 지정이 안돼있으면 홈 주소로 리디렉션시킨다. 최소한의 url 에러처리.
    - tree 파라미터가 지정돼 있을 경우 "작품소개" 탭을 활성화시켜 작품 소개를 바로 띄운다.
    - team 파라미터가 지정돼 있을 경우 "작가소개" 탭을 활성화시켜 작가 소개를 바로 띄운다.
    - 작품소개 탭 페이지에서는 "한국어"를 누르면 국문 설명이, "English"를 누르면 영문 설명이 나오게 한다.
    - 사진 쪽을 누르면 갤러리를 띄운다. 갤러리에 들어갈 사진들은 array.php에서 하위배열 하나 넣어서 foreach로 뿌리기로.
    뭐 더 설명할 것 없이 무쟈게 기초적인(≒무식한) 네비게이션이다.
  • 작품소개-사진-작가소개는 탭바를 이용하기로 했고, 한국어/English 전환은 을 쓰기로 했다. (이름은 비슷한데 영 달라서 되게 헷갈림.) 사진 갤러리는 포토브라우저로 처리.
  • 갤러리에 넣을 사진은 곧 받기로 했었으므로 일단 lorempixel을 채워넣음. "Close"를 "닫기"로 고칠 순 없을까? 생각했지만 일단 넘어감. 작가 소개문은 따로 제공받지 않았었으므로 일일이 웹사이트나 SNS를 찾아가서 소개문 및 로고를 찾아 array.php를 보강함. 페이지별로 멀쩡하게 뜨는 것 확인.
  • 쫙쫙 잘 뜨길래 야 신난다! 하고 이것저것 눌러보다가… 버그 발견. 사이드메뉴로 detail 뷰에 진입했다가 다른 detail 뷰를 보려고 하면 탭바가 동작을 하지 않는다. 그냥 흰 화면이 뜨고 아무 일도 일어나지 않음. 읭??? 이거 뭐냐??? 모바일 사용자는 눈에 보이는 모든 것을 다 눌러보는 법인지라, 이건 무시할 수 없는 문제상황이라는 판단이 서서 패닉에 걸림.
  • 세 시간 동안 스택오버플로를 ㅈ나게 뒤지고 Framework 7 공식 문서를 눈 빠지게 읽음. "해결법"은 못찾음. 설마 싶은 것들은 한두 개 눈에 띄었지만, 이리저리 코드를 고치고 뒤집다 보니 이젠 뭐가 뭔지 모르겠다 싶어서 그만두기로 하고 퇴근. (진짜 뇌도 스택으로 돌아간다면 이런 게 오버플로일까 싶은 걸 경험했다. undo redo를 아무리 눌러봐도 기억이 돌아오질 않았다…)




Day 3

  • 출근해서 서브라임 텍스트를 딱 켰는데 생각해 보니 해결된 게 아무것도 없었다. 최악의 경우 이 조치를 단행하면 되겠지… 라고 짐작하고 있던 조치를 단행했다. 모든 링크에 .external 클래스를 부여한 것. 해놓고서 다시 열어보니, 프레임워크7 특유의 스무스한 페이지 움직임(써보면 안다. 진짜 앱 사용하는 것처럼 움직인다)은 없어졌는데 내용 출력 자체는 멀쩡하게 잘 되었다. 허탈.
  • 차차 원인을 이해할 수 있었다. 프레임워크7은 기본적으로 모바일앱이 갖는 페이지 개념 아래 개발돼 있어서, 하나의 "페이지(URL 엔드포인트)"가 경우에 따라서 여러 데이터를 가진다는 개념을 이해하지 못함. 그런데 나는 index 아래의 모든 뷰가 detail.php?team=foo 아니면 detail.php?tree=bar 꼴이었던 것이다.
  • JS 입장에서는 할 말을 잃고 동작을 중단할 수밖에 없다. 아까 detail 페이지 안에 들어 있는 #tab_tree 하나를 active 걸었는데, (사용자 입장에서는 별개의) detail 페이지 안에 있는 #tab_tree에 active를 또 걸라니 뭔 소리냐 싶겠지.
  • 이런 일이 있을까봐, 그리고 Framework 7의 기술적 특성상 준비돼 있던 것이 a태그에 붙일 수있는 .external 클래스였다. 프레임워크7은 페이지를 쫙 읽어본 다음 href 붙은 모든 url을 미리 ajax로 읽어놓는다. 그 다음 스마트하게 동작한다. 예컨대 A라는 링크를 요청했을 때 서버가 404를 외쳤다면, JS는 A를 기억해 놨다가, 사용자가 A를 누를 때 아무 일도 안 일어나게 만든다. 이게 그야말로 모든 링크에 대해 작동할 경우 외부 사이트 DOM까지 읽게 되면 보통 큰일이 아니게 되므로, 구분자를 제공하는 것.
  • 이 구분자의 기능은 DOM7 편입을 안 시키는 것. 그러면 ajax 프리로딩 없이 그냥 매번 요청된 URL을 새롭게 요청하게 된다. 당연히 "문제"는 해결된다. 하지만 더 좋은 사용(스무스한 이동 등 진정한 framework 7 사용경험 구현)으로서의 진정한 해결은 안된 상태. (미숙…)
  • 그리고 어제의 패닉 리서치 과정에서 한 가지 더 알게 된 사실은, 탭바는 DOM7 전체에서 항상 나오는 메뉴로서 쓰는 것이 best practice라는 것. 생각해 보면 메인화면에 안 나오던 탭바가 세부사항 페이지에서는 나오는 일은 거의 없다. 이것도 아마 스크립트 충돌에 일조한 사항일 것.
  • 전날 뒤집어엎으면서 엉망진창 만들어놓은 코드를 재정리. 공식 문서에 따르면 Framework 7의 전형적인 페이지는 다음 구조를 따른다.
    body
    - panel (상단 전체메뉴. 싫으면 넣지마슈~)
    - views (상단을 뺀 나머지 화면 전체 wrapper. 전체DOM에서 유일)
    -- view .view-main (기본화면, 전체DOM에서 유일)
    --- navbar
    --- pages
    ---- page (data-page=home)
    ----- page-content
    ------ content-block
    --- toolbar
    ---- tabbar 등등
    -- view .foobar (만약 이 웹페이지가 아이패드 메모앱처럼 split된 화면을 가져야 할 경우 추가해서 사용함)
  • 그렇게 허탈하게 버그를 때려잡고 나니 힘이 빠져서, index.php의 대표이미지들 위에 그라데이션을 뿌린다든가 하는 세부적인 스타일링을 트윅하며 기운을 되찾음.
  • 2일째에 정신없이 문서 읽고 깃헙 레포 뒤지다가 문득 발견한 것이 있어 "음 그럼 해볼까?" 하고 footer.php에 넣어둔 포토뷰어 JS 변수를 건드려봄. 'Close'를 '닫기'로 고치는 게 생각보다 너무 간단하게 되었다. photos 배열 넣는 배열 자리에 원하는 변수명의 값을 새로 지정해준 것만으로 적용이 됨. (이걸 간단한 일로 만들어준 개발자가 대단한 거다…)
  • 최종 점검 마치고, 아이패드/아이폰 뷰 체크한 다음 최종본으로 발행.




교훈

  • Framework 7은 앱 개발을 하는 기분으로 모바일웹을 개발하는 도구이다. 단순 컴포넌트 CSS를 묶어서 이쁘게 만들어주는 정도가 아니라, 각 개별 페이지들이 웹앱으로 작동하도록 AJAX로 처리한다.
  • 따라서 Framework 7을 쓰려면 get 파라미터 대신 URL 라우팅과 data-page에 신경을 쓸 것이며, 막무가내로 아무데나 컴포넌트를 끌어다 쓰면 안 된다(요소들 위치 정해져 있는 정도가 꽤 까다롭다). 가급적 문서를 처음부터 천천히 읽고 제대로 개념을 이해한 다음 쓰기. 나처럼 실전 case위주로 막덤비면 공부도 안되고 효율도 떨어진다.
  • 모바일 브로셔는 무료호스팅으로도 유지 가능한 트래픽을 자랑한다. (…) 여러분 올해가 가기 전에 코엑스 B홀 앞에 가 보세요!


'1 내 > ㅎ 열외' 카테고리의 다른 글

닷홈에 라라벨 설치하기  (7) 2018.04.09
세상에서 가장 무식하게 React 써보기  (0) 2018.01.07
새 블로그 스킨 작업중!  (0) 2015.03.05
fontclub, font.co.kr 미리보기 렌더러 스펙  (4) 2014.01.31
⊥ED Conference  (0) 2013.05.19
Posted by 엽토군
:

순전히 나의 fails를 case studies로 바꾸기 위한 기록. 눈물 없인 읽을수 없을껄!!!

거의 프리티어 php EB 기준입니다.

한동안 내 목표 = 이 글 업데이트 안해도될만큼 fail study 쌓는것 ^.^ ㅜ.ㅜ



일단은 이 슬라이드를 읽고 오자. 온갖 실패를 겪고 나니, 이 슬라이드가 얼마나 잘 만든 것인지 비로소 보임.

잘 이해가 안 되면 이제부터 아래를 읽도록 합니다.


  • 기본적으로 AWS는 “너는 서버를 굴릴 줄 알고 우리는 남는 서버가 있으니 우리 한 번 잘해보자”의 방침임. AWS가 나쁜놈인 케이스는 거의 없고 나의 서버 구축 운용 지식의 문제인 경우가 대다수.

  • 엘라스틱 빈스톡일 경우, 로컬에서 테스트 끝난 소스를 deploy하는 것이 기본. 워드프레스 관리자 메뉴에서 플러그인, 테마 등을 바로 받아 서버에 추가로 설치하는 것들은 version으로 관리가 안 된다. 따라서 오토 스케일링이 작동되거나 인스턴스가 재부팅되고 나면 추가 설치했던 요소들은 다 날아가고 없어짐.
    싫으면 위에 소개한 슬라이드에 설명된 대로, ①원하는 추가변경 작업 완료 → ②백업 플러그인으로 내려받기 → ③그걸 다시 application version으로써 deploy 를 하도록 한다. 해봤는데, 생각 이상으로 문제없이 깔쌈하게 돌아가서 매우 놀람.

  • 일반 EC2의 경우는 모르겠는데, EB로 환경 구성했을 경우 DeliciousBrain에서 만든 Amazon Web Service와 WP S3 Offload는 필수로 깔아야 함. 안그러면 이미지 올릴 때마다 EB를 돌리기 때문에 맨날 WARN 뜨고 degraded됨.

  • 이미지를 S3로 처리하게 해놨다 하더라도, user avatar와 featured images는 기본적으로 home_url() 기반으로 세팅하는 것이 wp의 철학임. 따라서 인스턴스를 새로 구성하거나 버전을 EB에서 다시 deploy할 경우 다른 이미지는 남는데 유저 아바타와 특성이미지는 날아가는 경우가 있을 수 있다. 영어로는 dead라고 부름. 일반 호스팅 업체에서는 s3 개념이 없으므로 아무 문제가 없었을 것이다.

  • 프리티어가 뭘 돌리든 월 750시간 무료라고 하는데, 이게 총합에 대해서 그렇다는 말임. RDS 물린 environment를 한달 내내 4개 켜놓으면 유료 결제되는 사용량은 = EC2 3개 * 750시간 * 1시간비용 + RDS 3개 * 750시간 * 1시간비용 = 요금폭탄!!!

  • 프리티어 첫 과금이 깜짝 놀랄 정도로 발생했을 경우 침착하게 다음 순서에 따른다.
    1. 결제 물려놓은 카드의 잔액을 없애거나 해외결제를 중지한다. (이건뭐 각자 알아서들 하시라. 일단 결제를 시도하기 때문에...)
    2. 내가 뭘 create해봤다 싶은 모든 서비스에 들어가 불필요한 인스턴스를 모두 terminate할것. 특히 월초 시작됐을 경우. 지금 이 시간에도 과금은 되고 있으므로
    3. 우상단의 support center로 가서 create case를 눌러 자초지종을 영어로 설명하도록 한다. "나 프리티어인데 요금이 너무 많이 부과가 됐다 어떻게 하면 좋으냐" 정도의 의사를 전달하고, 답장 받는 방식을 web으로 지정해 전송.
    이후 기다리다 보면 알아서 처리해줌. 첫 청구는 거의 대부분 캔슬해 준다고 함. 내 경우에는 답장 받는 데 5일 걸림. 한번 100불 넘는 청구를 받아보고 나면 정신이 확 든다. 수시로 우상단의 (자기이름) > billing & cost management를 확인하도록 한다. 이번 달 청구요금이 별로 없거나 줄어들어 있는 것을 확인하면 정신 건강에 도움이 된다.

  • 일반 웹호스팅 때 하던 나쁜 버릇이 문제가 된다. 예컨대 예전 호스팅 업체 쓸 땐 루트폴더에 phpmyadmin도 깔고 codeigniter도 깔아서 썼었는데(물론 아무 문제가 없다) 이걸 워드프레스와 같이 묶어서 버전으로 배치하려니 개노답.
    RDS 따로 쓰기 싫고 이것저것 자기 맘대로 하고 싶다면 그냥 EC2에 콘솔로 DB, 언어 등등을 다 깔아 구축하든지 차라리 코드이그나이터만 굴리는 AWS 계정을 하나 새로 만들어서 쓰는 게 훨씬 건강에 도움이 된다. (그냥 돈을 내고 새 환경 하나 구축해도 되긴 됨…)

  • 파일 이름이 한글로 된 이미지 등이 제대로 올라가지 않는다. 뭐 모든게 ascii latin-1로 맞춰져 있는 동네이니 당연한 일인데, 다음 두 가지 방법을 병행하면 도움이 된다.
    1. non-latin 파일명 통제 플러그인 설치. 난이도 낮음, 효과 큼, 문제해결력 작음. 내 경우에는 안형우님이 만든 플러그인을 쓴다.
    2. RDS(데이터베이스)의 파라미터 그룹 고쳐주기. 난이도 중간, 효과 중간, 문제해결력 큼. RDS 콘솔의 좌측 메뉴에서 Parameter Groups를 누르면 default.mysql.5.6 어쩌구 하는 것 하나만 보일 것이다. 이 밑에 비슷한 걸 하나 더 만드는데 다만 character_set_ 부분과 collation_ 부분을 죄다 utf8(-general-ci)로 고쳐준다. 저장한 다음 원하는 RDS에 적용하고 reboot 한번 해주면 됨. 다른 블로그 글들을 검색해서 하는 게 더 정확한데, (다행히 난 안 그랬지만) 인코딩 설정을 기존 환경과 충돌하게 설정하고 reboot하면 몇십 분간 in-sync로 안돌아온다는 케이스 문의들도 있었다. 주의해서 해볼일인듯.

  • Route53을 쓴다면 기본 요금으로 매달 50센트는 낸다고 보면 된다.

  • 한 달 좀 넘게 이리저리 굴러 봤는데, 결론을 말하자면 이미지(미디어) 호스팅만 S3로 받고 애플리케이션(코드)은 일반 웹호스팅으로 받는 조합이 가장 적절하다는 것이 내 생각.
    AWS가 지향(상정)하는 웹애플리케이션 개념에 워드프레스는 해당되지 않는다. 문제의 워드프레스가 기본 트래픽이 아주 높아서 일반 서버호스팅으로 비용 감당이 안 되거나, 상당한 양의 real-time 서비스를 한다거나 하지 않는 이상에는, 코드와 저장소와 DB를 모두 AWS에 넣어놓는 워드프레스는 확실히 '가성비 꽝'이다. 워드프레스는 24시 꾸준하게 운영되는 서버에서 대단히 정적으로 움직이는 CMS이기 때문에.

  • 다시 일반 웹호스팅으로 옮길 때는 DB 테이블 설정에 주의하도록 하자. 나의 경우에는 닷홈으로 다시 옮기고 나서 1주 정도 간격으로 자꾸 테이블 "일부"가 없어지는 기현상을 겪었는데, 문제를 해결하고 원인을 파악하다 보니 AWS에서 넘어온 데이터베이스의 테이블들이 다 InnoDB로 되어 있다는 사실을 발견. 나머지 안 날아가는 테이블들은 MyISAM이길래 모두 MyISAM으로 맞췄고, 현재까지는 문제 반복 안됨.


내가 앞으로 라이브 서비스 서버를 바꾸느니 종교를 바꾼다 ^_T


'4 생각을 놓은' 카테고리의 다른 글

무식이 배짱이라고 한두 줄 더 얹어 보자면  (0) 2016.07.18
의제에 대한 생각 둘  (0) 2016.04.30
아 XE 부르다가 내가 죽을 이름이여  (0) 2015.09.16
백업  (0) 2015.06.16
둠칫둠칫  (0) 2015.05.14
Posted by 엽토군
:

생산성의 덫

2015. 12. 9. 10:00

0.
미리 전제를 깔고 시작합니다. 이것은 "저격글"이 아닙니다. 다만 습관대로 해 왔던 일반론 펼치기의 일환이며, 그래서 언제나 그래 왔듯 이 글(과 글 속의 오만함) 역시 오로지 필자의 정보 부족에 기인해 있습니다. 반론 받습니다.


1.
멸치볶음을 팔려고 합니다. 무엇이 필요할까요? 마케팅? 유통망? ICT 솔루션? 페이스북 페이지와 '멸치삼촌' 관리자? 엔젤투자자의 마음을 사로잡는 5분 피칭과 그것을 위해 미끈하게 잘 만들어진 애플식 키노트? "모두의 멸치"라든가 "iMyeolchi" 같은 뭔가 잇한 브랜딩? 아뇨! 멸치볶음을 팔려면 멸치볶음이랑 비닐봉지만 있으면 됩니다! 왜? 멸치볶음은 그냥 더도 덜도 말고 딱 멸치볶음이니까! 시장통에서 20년 넘게 멸치볶음을 팔고 있는 아무나 붙잡고 내 말이 맞는가 틀린가 물어보세요!


2.
머리 꼬리 다 자르고 보면 결국엔 한마디로 멸치 사 와서 멸치볶음 만들어 파는 장사에 불과한 것이, 무슨 솔루션과 브랜딩과 각종 슬라이드쇼와 웹/앱 애플리케이션으로 뒤범벅된 iMyeolchi 같은 것이 되어 (실은 전혀 안) 팔리고 있는 광경을 최근 굉장히 많이 보고 있습니다. 무슨 창업지원센터 투자대회, 무슨 스타트업 대상 특강, 무슨 네트워킹 파티, 강남구 종로구 중구 일대의 무슨무슨 스타벅스와 무슨무슨 임대 오피스를 돌아다니다 보면, 그 위대하시고 거창하신 야망과 포부의 빅 플랜을 우스울 정도로 손쉽게 엿듣게 됩니다.


3.
왜 그렇게 되는 것일까요? 수많은 멸치볶음 장사 스타트업들이 브랜딩이며 애플리케이션 따위를 마구 도입하는 이유는 뭘까요? 저는 그게, 특히 한국 스타트업 생태계에서 더욱 만연해 있는 "생산성의 덫" 때문이라고 보고 있습니다. 풀어서 말하자면, 찔끔찔끔 생산하는 재미에 빠져서 일정 임계치 이상의 생산(과 그에 상응하는 필요악적 고통)에까지는 도달하지 않는 생산 집단이, 최근 급증하고 있는 것으로 보인다는 말입니다.
이는 비단 스타트업 업계뿐 아니라 현대 사회 각처에 만연해 있는 현상입니다만, 그렇다고 이걸 병리 내지 암적 징후 덜컥 진단하고 싹둑 잘라내려 하는 것 역시 쉽지 않아 보이기 때문에 문제가 됩니다. 미리 짧게 말하면, 어쩌면 생산성의 덫이란 최후의 인류에게 허락되는 최후의 처지인지도 모른다는 것입니다.


4.
일단 범위를 좁혀서 스타트업 위주로 이야기해 봅시다. "도대체 쟤네들은 밥 먹고 하는 일이 뭘까" 싶은 사업체들이 있습니다. ".kr" 도메인 붙여서 예쁘게 (하지만 알고 보면 부트스트랩 기반으로 좀 황량하게) 만들어 놓은 홈페이지만 보면 어떤 편견들이 생기는 것이 사실입니다. 이 사람들은 임대오피스 하나 빌려서 인테리어만 예쁘게 해 놓고 정작 하는 일이라곤 시시콜콜한 회의나 페이스북 돌아다니기 정도뿐이지 않을까, 그렇지 않고서야 어떻게 몇 주 몇 달 동안 이렇게 공식 홈페이지에 업데이트 하나가 없을까, 등등 말이죠.
문제는 그게 아닙니다. 진짜 문제는, 겉으로 보기에는 홈페이지 공지사항 하나 바꿀 일도 없는 한가해 보이는 사람들이, 정작 내부로 들어가서 보면 홈페이지 공지사항 하나 끄적일 여유도 없이 눈코 못 떠 가면서 데바쁘게 일하고 있다는 데 있습니다. 무슨 기획안을 작성하고, 견적을 내고, 미팅을 다니고, 수많은 대행업자들에게 하루에도 오십 건씩 전화를 돌려 가면서 말이죠. 매일이 아침 열 시에 출근 저녁 8시 퇴근의 연속이지만, 하루가 어떻게 가는지는 그들 중의 누구도 알지 못합니다. 오직 근무일지, 이메일과 영수증만이 파악하고 있죠.


5.
"뭐야? 그럼 잘된 것 아니냐?"라고 생각하실 수 있겠습니다. 그게 그렇지가 않습니다. 그 바쁨, 그 분주함의 내역이 실속 없고 사소하다는 데 문제가 있습니다. 예컨대 경쟁입찰용 PPT의 일곱 번째 슬라이드에 저 단어를 쓰는 것이 맞느냐, 최종보고서 제목에 연도를 넣느냐 마느냐 같은, 사업 자체에 그다지 크리티컬하지 않고 부차적인 것들, 아무래도 좋은 것들에 상대적으로 생산성이 과도하게 집중되는 경우가 적지 않습니다. 다시 짧게 말씀드릴까요? 본질이 바쁘게 생산되는 게 아니라, 곁가지가 바쁘게 생산되고 있는 겁니다.
그러므로 어정쩡한 스타트업 쪽에서 이런 일이 비일비재하다는 사실이 납득 가능하게 됩니다.
뭔가 하고는 싶은데, 자기들이 하고 싶은 것의 실상이 정확히 무엇인지, 세상이 이것 없어도 잘 굴러가는 이유는 뭔지, 세상을 이것 없이 굴러가지 않게 만들려면 뭘 해야 하는지, 도대체 하필 내가 이걸 하고 싶게 된 이유는 뭔지 등등 근본적인 고민은 접어두고 ‘글쎄~~ 그냥 우리 하던거 사업화하면 어떻게든 되지 않을까? ㅎ’ 하고 덤비시는 최고경영자 분들이 너무 많아서 그런 것이죠.


6.
본질이 없는 존재자는 그 존재의 우연적 요소에 집착하게 됩니다. 우연적이라는 말은 “사실은 없어도 그만인데 우연히 있는”이라는 뜻입니다. 예컨대 디자인이 바로 그렇지요. ‘좋소기업’들이 그토록 디자이너 구인에 매달리는 데는 이런 이유가 있습니다. 상품 자체의 본질이 기깔나게 좋으면 그냥 흰 배경에 수직 수평 맞춰 틱 찍어 올려도 아이폰처럼 와르르 팔려나갑니다. 하지만 생산성의 덫에 빠져 있는 생산자들은 그렇지 못하므로―그들의 상품의 본질이 너무 많거나 조잡하거나 흔들리고 있으므로―어쩔 수 없이 디자이너들이 투입됩니다.
사실 그들이 하고 있는 일이라고는 그저 없는 본질을 시각적으로 가설(假設)하는 일일 따름이죠. ‘[클라이언트]_[상품명]_진짜최종3-fontbreak.ai’ 만들고 있을 때 그들이 혼잣말로 욕하는 내용은 이런 겁니다. “아니 이런 건 애초부터 지들이 다 ‘그림’을 갖고 있어야 할 거 아냐? 이걸 왜 내가 다 ‘만들어’?”


7.
그런데 사실, 이게 비단 영세한 ‘클라이언트’와 영세한 ‘에이전시’ 사이에서 벌어지는 일이기만 한 것은 아닙니다. 이 짓을 “본질을 만들 시간은 갖지 않고 우연적 요소에 생산성을 과다 투입하기”로 정의한다면, 대한민국 전체가 이 짓 이 놀음에 한바탕 미쳐돌아가고 있다고 보는 것이 좀더 정직하다 하겠습니다.


8.
조금 엉뚱한 예를 들어 볼까요. 요즘 대학가는 학생회 선거와 운영상의 문제가 너도나도 워낙 많아서 어느 대학이 어떻다더라고 수군거리기 민망할 정도라 합니다. 왜 그러겠어요? 학생회가 뭐 하는 곳인지는 인수인계된 적이 없고 지난 몇 년 간 “작년 축제 때 연예인 섭외한 업체 연락처와 본판 무대 일정표” 따위에만 모두의 관심이 쏠려 있었으니 그런 것이지요.
물론 투표나 선거운동상의 문제들은 모두 우연히 겹쳐 일어나는 것처럼 보입니다. 하지만 이건 생산성의 덫이 부르는 필연입니다. 학생들을 대표하는 자치기구라는 더 큰 차원의 본질이 사라지고 그저 축제 주관기관 정도로 전락하는 일이 만연해지자, 학생회는 학생회대로 매 학기 쓸데없이 바쁘고, 학생들은 “이번 학생회는 어떻게 된 게 예산 집행 내역 하나를 안 올리죠? 일 안 해요?” 불만인 거지요.


9.
국회를 통과하지 못하는 온갖 법안들은 어떻습니까? 내수 진작이다, 부동산 위기 해결이다 하면서 정부가 내놓는 정책 방안들은 또 어떻고요? 각종 운동, 정당, 단체의 지도부라는 분들은 또 어떻습디까? 되도 않는 전략으로 빈축을 사는 B급 C급 아이돌들과 그들의 기획자들은 어떨까요? 그들이 과연 놀고 먹을까요? 천만에! 눈코 뜰 새 없이 일합니다! 이 나라는 OECD 회원국 중 제일 많이 일하는 숫소 같은 국민들의 나라인걸요!
그런데 왜 이 모양 이 꼴이냐? 생산성의 덫 때문입니다. “우리는 열심히 하고 있다, 이 일은 열심히 하면 될 일이다, 그러므로 우리는 뭐가 어떻게 돌아갈지는 몰라도 하여튼 잘 될 거라 믿고 열심히 한다”의 악순환 때문이라고요!


10.
20세기의 근대적 대기획은 양차 대전으로 개발살이 났고, 본질만 좋으면 뭔 짓을 해도 좋으니 추진하자는 생각은 아무래도 현대에 들어와서 좀 시들해진 것이 사실입니다. 하지만 지금은 오히려 역전이 일어나 있지 않은가 합니다. 본질 따위 아무래도 좋으니, 우연히 획득된 부가적 요소들이 좋고 재밌으면 그만인 거지요. 왜 그런가를 생각해봤을 때, 20세기의 기획 중 포드주의가 신자유주의적 경제 기획으로 옹졸하게 대물림된 이후 오늘날 유일하게 판치고 있기 때문인 것으로 짐작됩니다. 말하자면 ‘최대 이윤 추구’가 만사의 잠정적 본질로 전제돼 버린 것이죠. 뭐든지 돈이 되면 그만인 겁니다.
SNS가 그렇게 하나둘 망해 갑니다. SNS는 친구 사귀는 서비스지 광고를 보여주는 서비스가 아닙니다. 하지만 장사꾼들이 마케팅을 한답시고 들어와서 별로 친해지고 싶지도 않은 사용자들의 ‘Like’와 ‘팔로우’를 받아내려고 이 성화 이 난리입니다. 그것도 (광고주로부터) 정해진 기한 내에 최대 성과를 달성하라는 식으로요. 이들 덕분에 실제 SNS 사용자들은 ‘친구는 없고 광고계정만 많다’라는 본질적 배반감을 느끼고 하나둘 떠납니다. 이런 일이 반복되는 걸 보면서 느낍니다. 그러면, ‘친구를 사귄다’, ‘좋은 물건을 필요한 사람에게만 정확하게 공급한다’ 등등의 본질을 결여하고 이윤 추구 따위 되도 않는 가짜 본질과 부차적인 모든 것에만 몰두하는 이 생산성의 덫은, 그럼 대체 누구 좋으라고 있는 생산성인가?


11.
이쯤에서 가장 받아들이기 힘들 만한 제 생각을 적어 보죠. 이 쳇바퀴 도는 생산성은, 사실은 현대인들에게 필요한 것입니다. 바꿔 말해 볼까요? 현대인들은 이런 류의 생산성이라도 자기 삶에 주어지지 않으면, 그 실존적 공허를 견딜 길이 없습니다.


12.

예를 들어 봅시다. 당신이 어제 어떤 일을 인수인계 받았습니다. 왜 하는지 듣긴 들었고 이해는 했는데 별로 동의는 되지 않았죠. 그래서 그걸 오늘 착수하는데, 오늘 요일이 목요일입니다. 내일도 똑같이 출근해서 별로 동의되지 않는 이 일을 끝내놔야 하게 생겼습니다. 동의가 안 되는 이유는 간단합니다. 그 실상이 분명하지 않거나, 실상은 뚜렷하지만 자기에게 좋아 보이지 않거나 한 거죠. 예컨대 ‘이걸 세모로 바꾸면 귀여울 거야’라거나 ‘이게 70세 이상 노인들한테는 없어서 못 파는 거야’ 같은 본질(?)들 말입니다.
당신은 어떻게 할까요? 전임자를 쫓아가서 총책임자 이름이랑 기획자 연락처를 요구할까요? 아뇨, 당신은 웹툰을 보기 시작합니다. 어차피 이 일에 자기를 투신할 본질이 없는데 뭣 하러 열심히 합니까? 대충 요구되는 선까지만 하자는 생각으로 만화보기 페이지 스크롤을 굴리며 꾀를 부리기 시작합니다. 그리고 뭐 어떻게든 끝내 놓겠지요. 특근이든 야근이든 박카스든 해서요.
자 이제 물어봅시다. 이런 일이 당신의 근무 시간에 빈번하게 일어납니까? 만약 YES라면, 네 그렇습니다, 당신의 직장은 생산성의 늪에 빠져 있습니다. 당신이, 당신 동료가, 당신 회사가 아무리 열심히 일한들, 아무리 생산성을 올리고 얼마나 오랜 시간 얼마나 쎄빠지게 노동을 하든, 당신도 당신 동료도 당신 회사도 그다지 행복하지는 않을 겁니다. 그냥 위에서 정해 준 목표에 자신이 동의하는 체하며 아무도 알아주지 않는 불행한 성실함을 끝없이 발휘해야 할 거예요. ‘페이지 좋아요 수’ 따위나 매일 우러러보면서.


13.
해결책을 제시하고 싶은데 그 해결책이 너무 허무맹랑한 것이라서 말하기가 부끄럽습니다. 제 블로그니까 뭐 엄청나게 책임성 있는 발언만 구비하고 싶지는 않고 그냥 제 망상을 간단히 적고 끝내겠습니다. 할 수만 있다면 이 경제, 이 미친 생산체제를 다만 한 달이라도 좋으니 일시정지 아니면 리셋을 좀 시켜볼 수는 없을까? 생각합니다. 생산성의 악순환을 강제로 잠시 끊고 나면, 정신이 좀 들지도 모른다는 생각입니다. “야 우리 지금 허벌나게 일해서 ㅈ나게 돈을 벌고는 있는데 이게 대체 뭔데 이걸로 누구 입에 뭘 넣자고 이러는 거냐?”
독일은 양차대전으로 그걸 겪었고 스웨덴은 원체 빈곤국가였다고 하지요. 미국은 대공황을 겪고 나서 케인즈주의를 들여왔습니다. 사실 신자유주의-외적인 경제 체제들이 항상 묻는 것은 이윤 추구라는 본질의 본질입니다. “대체 그렇게 벌어서 누구 입에 뭘 넣자는 거냐?”의 문제가 맑스주의적으로든 러스킨주의적으로든 헨리주의적으로든 다루어졌던 거고요.
우리는 어떤 기회를 얻게 될까요? 글쎄 잘 모르겠습니다. 특정 임계값(그게 얼마인지는 잘 모르겠습니다)까지의 최저임금 상승도 방법일 수 있겠습니다만 기본소득도 요즘 많이 논의가 되고 있지요. ‘돈이야 어차피 국가에서 굶어죽지 않을 만큼 주는데, 그럼 내 성실성은 대체 어떤 일을 위해 팔아 줘야 할 것인가?’를 다함께 고민할 좋은 제도적 근거가 될 테니까요.


14.
이 글은 제가 관여하고 있는 각종 홍보대행 업무와 아무 관계가 없습니다. 저는 이 일을 매우 성실히 하고 있습니다. 제 자신이 성실성의 덫에 빠지지 않으려고, 이 일이 세상에 어떻게 기여할 것인가를 하루에 네 번씩 생각하려고 애쓰는데 너무 바빠서 이틀에 한 번 정도밖에 생각하지 못합니다. 대단히 감사합니다.

'1 내' 카테고리의 다른 글

척수반사  (0) 2016.04.04
To Make Nothing Happen  (0) 2016.03.02
그 유물론은 성간 안팎으로 선전하기 참 좋은  (8) 2015.07.18
“경기(京畿)”를 없애야 한다  (0) 2015.06.18
자기만의 100점  (0) 2015.02.03
Posted by 엽토군
:

카테고리

분류 전체보기 (801)
0 주니어 PHP 개발자 (6)
1 내 (326)
2 다른 이들의 (253)
3 늘어놓은 (37)
4 생각을 놓은 (71)
5 외치는 (76)
9 도저히 분류못함 (31)

최근에 올라온 글

최근에 달린 댓글

달력

«   2024/05   »
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