스토리 홈

인터뷰

피드

뉴스

조회수 1196

한국콘텐츠진흥원 웹툰X영상 토크콘서트

2018년 3월 22일 (목)한국콘텐츠진흥원 웹툰x영상 토크콘서트에 다녀왔습니다.<강철비> 양우석 감독님, <제빵왕 김탁구>, <동네 변호사 조들호>의 이정섭 PD님, 웹툰 <동네 변호사 조들호>의 해츨링 작가님과 함께이루어졌던 토크콘서트는작품을 진행하면서 겪었던 해프닝도 엿볼 수 있던 시간이였고, 무엇보다도 알아가는 시간이 많은 시간이였답니다.  첫번째 강연은 양우석 감독님이 전반적인 영화계와 해외 컨텐츠 기업들의 행보를 예시로 들려주시며컨텐츠 산업에 대한 시장 체제에 대한 이야기를 들려주셨습니다. 와 <트랜스미디어>를 중심으로 강연을 진행하셨습니다.가장 주목해야 할 점은 현재 국내 컨텐츠 사업은 몇 년 전까지는 일본의 행보를 많이 따라가는 듯 했으나점점 컨텐츠 산업이 발전하고 자본이 갖춰지는 행태에 의해 미국의 행보를 많이 따라간다는 추세에 대해 이야기 한 점.저희 나라도 컨텐츠 사업이 발전하면, 뒤쫓기 보다는 독보적인 사업을 꾸려나가지 않을까 싶습니다.     두번째 강연으로는 해츨링 작가님의 1인 제작사로서의 고충을 진솔하게 이야기를 들을 수 있었습니다. 해츨링 작가님은 본인이 그림도 못 그리고, 스토리토 잘 쓰지 못하였지만 네이버라는 최상위 플랫폼에서어떻게 연재를 하게 됐는지의 얘기를 중점으로 하였는데요,가장 큰 요인은 남들이 하지 않은 것을 했다는 것이고, 그것이 웹툰 작품들 사이에큰 역할을 하며 위치를 고수했다는 사실이였습니다. 1인 제작자로서 큰 기업이나 프로젝트 단위로 움직이는 이야기와 다른 느낌을 받을 수 있었고,개인적인 고민과 고충을 들으며 공감할 수 있었던 강연이였습니다.     세번째 강연은 이정섭 PD님의 방송계 현실에 대한 이야기를 들을 수 있었습니다. 세분 중 가장 현실적으로 부닥치는 문제점이나 원인에 대한 분석이 가장 명확하셨고원작을 리메이크하여 재창조하는 작업자이지만 그 과정에서 가장 창작자다운 마음가짐으로 어떻게 제작을 하고 있었는지에 대한 이야기를 들려주셨습니다.들려주신 이야기 중에서 하나는 저희 나라와 다르게 일본은 아직 리메이크에 대해서 보수적이라 생각한다고 합니다.원작에 대해서 최대한 존중하고 존경에 많은 신경을 쓰는 특성과 그 규정도 명확하다고 합니다.하지만, 그 원작을 가지고 재창작을 하는 사람도 하나의 창작자라는 점도 있다고 하셨습니다.웹툰/드라마/영화 모든 분야에서 차이가 있고그 차이에 맞게 작품을 변화시키는 특성을 수용하는 것이 재창작자의 의무지만현재 일본의 리메이크 방식에서는 굉장히 단점이라는 사실을 알려주셨습니다.방송사와 영화계 제작자들을 다른 시점에서 바라볼 수 있는 강연이였고 더 존중하고 존경할  수 있게되는 시간이였습니다.   세 분의 강연이 끝나고 토크콘서트 시간에서는 공통질문과 개별질문으로 크게 나뉘어 토크가 진행되었습니다.앞서 강연에서 보지 못했던  “원작을 리메이크 할 때  가장 아쉬운 것” 등의 질문이나 리메이크에 대한 생각도 시원하게 답변해주셔서좀 더 디테일한 부분을 알 수 있던 시간이였습니다.   강연이 끝나고 웹툰무비팀 경국님은 이정섭 PD님에게 사인을 받았답니다.   또한 맛있는 간식도 준비되어 있어 강연을 듣고난 뒤에 허기를 달랠 수 있었습니다.   아이디어콘서트도 투니비 플랫폼 운영을 진행하며스크롤로 봐도 멋있는 웹툰이지만, 원작을 가지고 더욱 독자들에게 와닿는 웹툰무비를 제작하고 있죠.멈춰있는 장면에서 표현해내지 못하는 것들도 생동감을 불어넣어주는 투니비!콘텐츠 사업에서 활약하는 투니비, 앞으로도 지켜봐주세요!#아이디어콘서트 #이벤트참여 #이벤트후기 #인사이트 #경험공유
조회수 1896

스포카에서 쓰는 오픈소스와 오픈소스 라이센스 (1)

안녕하세요. 스포카 프로그래머 박종규입니다. 이번 시간에는 스포카에서 쓰고있는 클라이언트 측 오픈소스와 그 오픈소스가 어떠한 라이센스가 적용이 되었는지 알아 보겠습니다.오픈소스(Open Source)먼저 간략하게 오픈소스의 정의에 대해서 짚어가도록 하겠습니다. 오픈소스는 소스코드를 외부에 공개하여 누구든지 제한없이 소프트웨어를 쓰고 소스코드를 볼 수 있는 소프트웨어를 말합니다. 통상적으로 오픈소스 소프트웨어를 오픈소스라고 부르기도 합니다. 대표적인 오픈소스로는 우리가 많이 쓰는 안드로이드OS와 크로미움 브라우저를 볼 수 있죠.프로젝트에 오픈소스를 적용?그렇다면 오픈소스의 정의도 알았고 제한없이 쓸 수도 있다고 하고 이렇게 많은 장점이 있는 오픈소스를 우리회사 프로젝트에 한 번 도입해볼까?라는 생각을 가지신 분들이 있겠지만 잠시만 기다려 주시길 바랍니다. 이러한 오픈소스는 오픈소스 라이센스라는 일종의 저작권이 적용이 되어 있어서 그 라이센스를 준수 해야합니다.오픈소스 라이센스(Open Source License)오픈소스 라이센스의 정의를 간략하게 보면오픈소스 라이센스는 오픈소스SW 개발자와 이용자간에 사용 방법 및 조건의 범위를 명시한 계약을 말한다. 따라서 오픈소스SW를 이용하기 위해서는 오픈소스SW 개발자가 만들어놓은 사용 방법 및 조건의 범위에 따라 해당 SW를 사용해야 하며, 이를 위반할 경우에는 라이선스를 위반함과 동시에 저작권 침해로 인해서 이에 대한 처벌을 받게 된다.라고 나와 있습니다. 즉 오픈소스이긴 하지만 오픈소스에 적용된 라이센스를 준수하지 않는다면 법적인 처벌을 받는다는 거죠. 그렇기 때문에 프로젝트에 오픈소스를 적용하려면 제일 먼저 라이센스를 확인해야 합니다.스포카 클라이언트에서는 어떠한 오픈소스를 쓰고 있을까?현재 스포카의 클라이언트측에서 사용하고 있는 오픈소스는 다음과 같습니다.jQueryLESSBackbone.jsD3.jsDataTables.js그럼 간략하게 이 오픈소스가 어떠한 역할을 하는지 간략하게 알아보겠습니다.jQueryjQuery(제이쿼리)는 브라우저 호환성이 있는 HTML 속 자바스크립트 라이브러리이며 클라이언트 사이드 스크립트 언어를 단순화 할 수 있도록 설계되었습니다. 즉 자바스크립트를 좀 더 편하게 쓸 수 있도록 개발된 라이브러리이죠.LESSLESS는 css를 동적으로 쓸 수 있게 해주는 자바스크립트 라이브러리 입니다. 기존 css에서 제공하지 않는 변수 및 연산식을 제공하기 때문에 코드를 재사용 할 수 있을 뿐만 아니라 개발시 소요되는 시간을 줄여줍니다. *.less로 개발된 코드는 less 컴파일러를 통해 *.css로 변환이 되어 클라이언트 페이지에 적용됩니다.Backbone.jsBackbone.js는 자바스크립트를 MVC 패턴으로 개발할 수 있게 도와주는 자바스크립트 라이브러리입니다.D3.jsD3.js는 데이터를 우리가 쉽게 볼 수있게 다양한 차트, 표, 그림으로 표현 할 수 있도록 기능을 제공해주는 자바스크립트 라이브러리입니다.DataTables.jsDataTables.js는 table를 만들어주는 기능을 제공하는 자바스크립트 라이브러리입니다.그렇다면 위 오픈소스에는 어떠한 라이센스가 적용되어 있을까?위의 오픈소스에 적용되어 있는 라이센스를 살펴보면jQuery : MIT, GPLv2LESS : apache license 2Backbone.js : MITD3.js : BSDDataTables.js : BSD, GPLv2같은 라이센스가 적용이 되어 있습니다. 그럼 하나씩 살펴보도록 하죠.듀얼라이센스먼저 jQuery와 DataTables.js에는 다른 오픈소스와 다르게 라이센스가 두개가 적용이 되어 있는 것을 볼 수 있습니다.이것을 흔히 듀얼라이센스라고 하는데 이 라이센스는 오픈소스를 쓰는 사용자가 두개의 라이센스중에서 하나를 선택해서 쓸 수 있는 라이센스입니다. 예를 들면 jQuery를 쓰는 사용자는 GPL 라이센스를 적용을 할 수도 있고 MIT 라이센스를 적용해서 쓸 수 있다는 뜻이죠.GPL 라이센스jQuery와 DataTables.js에 적용되있는 GPL라이센스에 대해서 알아 보겠습니다. GPL라이센스는 오픈소스에 가장 많이 적용된 라이센스 중에 하나입니다. 이 라이센스는 자유소프트웨어재단에서 만든 라이센스로 이 라이센스를 가진 오픈소스를 이용하여 응용 프로그램을 개발하는 경우에는 GPL라이센스가 적용이 됩니다. 그리고 GPL라이센스는 3가지의 버전이 있습니다.GPLv1GPL의 버전 1은 1989년 1월에 발표되었다(GPLv1 전문). 이것은 자유 소프트웨어에서의 두 가지 중요한 자유를 보장해 주었는데, 하나는 프로그램의 소스코드를 공개하지 않은 채 바이너리 파일만 배포하는 것을 막는 경우로 이것을 막기 위해 GPLv1에는 프로그램을 GPLv1로 배포할 때는 사람이 이해하기 쉬운 소스 코드를 같이 배포해야 한다는 조건이 들어갔다. 두 번째 문제는 프로그램에 추가적인 제약을 걸 가능성이 있다는 점이었고, 이를 막기 위해 GPLv1 프로그램을 수정한 프로그램은 원래 프로그램과 마찬가지로 GPLv1을 따라야 한다는 조건이 들어갔다.GPLv2자유 소프트웨어 재단(OSF)에서 만든 자유 소프트웨어 라이선스다. 미국의 리처드 스톨만(Richard Stallman)이 GNU-프로젝트로 배포된 프로그램의 라이선스로 사용하기 위해 작성했다. ‘① 컴퓨터 프로그램을 어떤 목적으로든지 사용할 수 있다 ② 컴퓨터 프로그램의 복사를 언제나 프로그램의 코드와 함께 판매 또는 무료로 배포할 수 있다 ③ 컴퓨터 프로그램의 코드를 용도에 따라 결정할 수 있다 ④ 변경된 컴퓨터 프로그램 역시 프로그램의 코드와 함께 자유로이 배포할 수 있다’라는 네 가지 조항을 명시하고 있다. 대부분의 소프트웨어에 대한 라이선스는 소프트웨어를 공유하거나 수정할 수 있는 자유를 금지하기 위 고안되었다. 반면에 GNU 일반 공중 라이선스는 자유 소프트웨어를 공유하고 수정할 수 있는 자유를 보장하기 위해 의도되었다. 즉, 소프트웨어가 사용자 모두에게 자유롭게 이용될 수 있도록 하는 것이다. 이 일반 공중 라이선스는 자유 소프트웨어 재단의 소프트웨어 대부분을 비롯하여, 저작자가 이 라이선스의 사용을 지정한 기타 모든 프로그램에 적용된다. (자유 소프트웨어 재단의 소프트웨어 중 일부는 이 라이선스 대신 GNU 라이브러리 일반 공중 라이선스가 적용된다.) 누구나 자신의 프로그램에 이 라이선스를 적용시킬 수 있다.GPLv3자유 소프트웨어 재단(FSF)과 이 재단의 GNU 프로젝트에 의해 배포되며 GNU 소프트웨어에 적용되는 공개 소프트웨어의 대표적인 라이선스 체계. GNU GPL이라고도 하며, 저작권(COPYRIGHT)의 반대라는 의미로 카피레프트(COPYLEFT)라고도 한다. 라이선스 사용료나 사용상의 제약 조건을 자유롭게 하여 소프트웨어 유통을 활성화하기 위한 의도에서 출발한 것으로 GNU 소프트웨어로 공개되는 원시 부호는 누구나 변경 또는 일반 공중 라이선스(GPL)로 재배포하고, 이를 이용하여 상업적 웹 사이트를 구축할 수도 있다. 그렇다고 저작권의 완전한 포기를 의미하는 것은 아니어서 GPL의 기본 원칙과 공개하는 측이 정의한 바를 충실하게 따르도록 되어 있다. 1990년대에 마련된 GPL V2.0에 이어 2005년에 V3.0이 발표되었다. GPL 버전 3은 2007년 6월 29일에 발표되었다. 2005년 후반에 자유 소프트웨어 재단에서 GPL의 세번째 판을 개발할 것이라고 발표했다. 바뀐 점 중에서 가장 중요한 4가지를 말하자면, 소프트웨어 특허에 대처하는 것, 다른 라이선스와의 호환성, 어떤 부분의 원시 코드와 무엇이 GPL이 포함되어야 하는 원시 코드를 구성하는지와 디지털 제한 관리(DIGITAL RESTRICTIONS MANAGEMENT)에 신경을 썼다.※참고GPL 라이센스가 적용된 오픈소스를 사용했다고 무조건 소스코드를 공개해야 하는 것은 아닙니다. 예를 들면 MySQL db를 이용하여 웹서비스를 개발해서 직접 서비스만 운영하는 경우 이것은 다른 곳에 배포하는 것이 아니므로 GPL 라이센스 의무사항이 적용되지 않습니다. 하지만 다른 곳에 제공하거나 파는 경우(쇼핑몰을 제작해서 파는 경우)에는 배포하는 것이 되므로 GPL라이센스가 적용이 됩니다. 따라서 이런 경우에는 상용라이센스를 구매해서 써야 합니다.MySQL에서 정의한 배포하는 대표적인 예는 다음과 같습니다.MySQL을 포함하고 있는 소프트웨어를 고객에게 팔아 그 소프트웨어를 고객이 소유한 장비에 설치하는 경우고객이 소유한 장비에 기본적으로 MySQL을 설치해야하는 소프트웨어를 파는 경우MySQL을 포함하고 있는 하드웨어 시스템을 고객에게 팔아서 고객이 있는 곳에 설치하는 경우MIT 라이센스MIT 라이센스는 MIT 공과대학교에서 학교 학생들의 소프트웨어 학습을 돕기 위해서 개발한 허가서입니다. 이 라이센스는 강력한 조항이 없어서 MIT 라이센스가 적용된 오픈소스를 이용하여 응용 프로그램을 개발할 시에 응용 프로그램을 오픈소스로 해야할 필요도 없고 소스코드를 공개할 의무가 없습니다. 또 상업적인 제한도 없습니다. 다만 응용 프로그램에 MIT 라이센스라고 표시와 라이센스 사본을 첨부만 해주면 됩니다.BSD 라이센스버클리의 캘리포니아 대학에서 배포하는 공개 소프트웨어의 라이선스입니다. BSD 라이센스는 자유소프트웨어 자작권의 하나로 BSD 계열 소프트웨어를 포함한 많은 프로그램에서 사용하고 있습니다. 이 라이센스는 라이센스라고 할 수 없을 만큼 미약해서 아무나 수정하고 배포하고 소스코드를 공개해야 할 의무가 없습니다. MIT 라이센스와 마찬가지로 라이센스 표시만 해주면 됩니다.Apach license 2아파치 라이센스는 아파치 소프트웨어 재단에서 만든 라이센스입니다. 이 라이센스 또한 MIT,BSD와 마찬가지로 소스코드 공개의 의무는 발생하지 않습니다. 하지만 “Apache”라는 이름에 대한 상표권을 침해하지 않아야 한다는 조항이 있어서 BSD라이센스보다 법적으로 완결된 내용을 담고 있습니다. 라이센스의 표시와 아파치 소프트웨어 재단에 개발된 소프트웨어라는 것을 밝혀야 합니다.참고한국저작권위원회위키백과KLDPwikiGNU공개SW포털MySQL KOREAKLDP 오픈소스라이센스가이드오픈소스 라이센스 비교표#스포카 #운영 #개발 #오픈소스 #개발자 #개발팀 #꿀팁 #인사이트 #조언
조회수 625

HBase상 트랜잭션 라이브러리 Haeinsa를 소개합니다 - VCNC Engineering Blog

비트윈에서는 서비스 초기부터 HBase를 주요 데이터베이스로 사용하였습니다. HBase에서도 일반적인 다른 NoSQL처럼 트랜잭션을 제공하지 않습니다. HBase, Cassandra와 MongoDB는 하나의 행 혹은 하나의 Document에 대한 원자적 연산만 제공합니다. 하지만 여러 행에 대한 연산들을 원자적으로 실행할 수 있게 해주는 추상화된 트랜잭션 기능이 없다면 보통의 서비스 개발에 어려움을 겪게 됩니다. 비트윈 개발팀은 이런 문제를 해결하기 위해 노력했으며, 결국 HBase에서 트랜잭션을 제공해주는 라이브러리인 Haeinsa를 구현하여 실제 서비스에 적용하여 성공적으로 운영하고 있습니다. VCNC에서는 Haeinsa를 오픈소스로 공개하고 이번 글에서 이를 소개하고자 합니다.Haeinsa란 무엇인가?Haeinsa는 Percolator에서 영감을 받아 만들어진 트랜잭션 라이브러리입니다. HAcid, HBaseSI 등 HBase상에서 구현된 트랜잭션 프로젝트는 몇 개 있었지만, 성능상 큰 문제가 있었습니다. 실제로 서비스에 적용할 수 없었기 때문에 Haeinsa를 구현하게 되었습니다. Haeinsa를 이용하면 다음과 같은 코드를 통해 여러 행에 대한 트랜잭션을 쉽게 사용할 수 있습니다. 아래 예시에는 Put연산만 나와 있지만, 해인사는 Put외에도 Get, Delete, Scan 등 HBase에서 제공하는 일반적인 연산들을 모두 제공합니다.HaeinsaTransaction tx = tm.begin(); HaeinsaPut put1 = new HaeinsaPut(rowKey1); put1.add(family, qualifier, value1); table.put(tx, put1); HaeinsaPut put2 = new HaeinsaPut(rowKey2); put2.add(family, qualifier, value2); table.put(tx, put2); tx.commit(); Haeinsa의 특징Haeinsa의 특징을 간략하게 정리하면 다음과 같습니다. 좀 더 자세한 사항들은 Haeinsa 위키를 참고해 주시기 바랍니다.ACID: Multi-Row, Multi-Table에 대해 ACID 속성을 모두 만족하는 트랜잭션을 제공합니다.Linear Scalability: 트래픽이 늘어나더라도 HBase 노드들만 늘려주면 처리량을 늘릴 수 있습니다.Serializability: Snapshot Isolation보다 강력한 Isolation Level인 Serializability를 제공합니다.Low Overhead: NoSQL상에서의 트랜잭션을 위한 다른 프로젝트에 비해 오버헤드가 적습니다.Fault Tolerant: 서버나 클라이언트가 갑자기 죽더라도 트렌젝션의 무결성에는 아무 영향을 미치지 않습니다.Easy Migration: Haeinsa는 HBase를 전혀 건드리지 않고 클라이언트 라이브러리만 이용하여 트랜잭션을 구현합니다. 각 테이블에 Haeinsa 내부적으로 사용하는 Lock Column Family만 추가해주면 기존에 사용하던 HBase 클러스터에도 Haeinsa를 쉽게 적용할 수 있습니다.Used in practice: 비트윈에서는 Haeinsa를 이용하여 하루에 3억 건 이상의 트랜잭션을 처리하고 있습니다.Haeinsa는 오픈소스입니다. 고칠 점이 있다면 언제든지 GitHub에 리포지터리에서 개선에 참여하실 수 있습니다.Haeinsa의 성능Haeinsa는 같은 수의 연산을 처리하는 트랜잭션이라도 소수의 Row에 연산이 여러 번 일어나는 경우가 성능상 유리합니다. 다음 몇 가지 성능 테스트 그래프를 통해 Haeinsa의 성능에 대해 알아보겠습니다.아래 그래프는 3개의 Row에 총 6개의 Write, 3개의 Read연산을 수행한 트랜잭션의 테스트 결과입니다. 두 개의 Row에 3Write, 1Read 연산을 하고, 한 개의 Row에 1Read 연산을 한 것으로, 비트윈에서 가장 많이 일어나는 요청인 메시지 전송에 대해 시뮬레이션한 것입니다. 실제 서비스에서 가장 많이 일어나는 종류의 트랜잭션이라고 생각할 수 있습니다. 그런데 그냥 HBase를 사용하는 것보다 Haeinsa를 이용하는 것이 더 오히려 좋은 성능을 내는 것을 알 수 있습니다. 이는 Haeinsa에서는 커밋 시에만 모든 변경사항을 묶어서 한 번에 반영하기 때문에, 매번 RPC가 일어나는 일반 HBase보다 더 좋은 성능을 내는 것입니다.HBase 클러스터가 커질수록 트랜잭션 처리량이 늘어납니다. HBase와 마찬가지입니다.HBase 클러스터의 크기에 따른 응답시간 입니다. HBase와 다르지 않습니다..아래 그래프는 2개의 Row에 각각 한 개의 Write, 나머지 한 개의 Row에는 한 개의 Read 연산을 하는 트랜잭션에 대해 테스트한 것입니다. 각 Row에 하나의 연산만이 일어나기 때문에 최악의 경우라고 할 수 있습니다. 처리량과 응답시간 모두 그냥 HBase를 사용하는 것보다 2배에서 3배 정도 좋지 않은 것을 알 수 있습니다. 하지만 이 수치는 DynamoDB 상의 트랜잭션과 같은 다른 트랜잭션 라이브러리와 비교한다면 상당히 좋은 수준입니다.HBase보다 처리량이 떨어지긴 하지만, 클러스터가 커질수록 처리량이 늘어납니다.HBase보다 응답시간이 크긴 하지만 클러스터 크기에 따른 변화가 HBase와 크게 다르지 않습니다.프리젠테이션Haeinsa에 대한 전반적인 동작 원리와 성능을 소개하는 프리젠테이션입니다. 좀 더 자세히 알고 싶으시다면 아래 프리젠테이션이나 Haeinsa 위키를 참고해주세요.<iframe class="speakerdeck-iframe" frameborder="0" src="//speakerdeck.com/player/2d4b2bd00fc201314ae312fe4cd13937?" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true" style="border: 0px; background: padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 750px; height: 563px;">
조회수 920

급한 일 빠르게 해봐야...

결론적으로 '능력 부족한 개발자'소리를 듣는 것이 대부분이다.대부분 급하다고 일을 의뢰하거나 서비스 론칭을 위해서 급하게 요구하는 경우가 있다. 개발자의 선택은 매우 명쾌하다. 정해진 기간과 인원 숫자로 만들어야 하는 서비스가 특정한 시간 내에 동작하게 하는 방법은 동작시에 제약사항과 커버하지 못하는 품질 이슈를 만드는 것뿐이다.말 그대로 기술적 부채를 만들어 낼 수밖에 없으며, 이 기술적 부채는 결론적으로 반복적인 유지보수 업무와 처리하지 못하는 기능들에 대한 하소연을 만들어 낸다.슬프지만 그렇게 반복되는 과정에서 경영진은 해당 개발자를 신뢰하지 못하게 된다. 그리고, 그렇게 반복적인 유지보수 업무를 만든 것은 개발자의 능력 부족이라고 생각하게 되고, 이 관계는 보고서가 늘어나거나 주간회의시에 디테일하게 보고하라는 식의 결론으로 귀결된다.물론, 이런 상황을 만든 '착한 개발자의 결정'이 문제이기는 하다.대부분 경험이 풍부한 개발자들은 이런 과정들을 반복해 보았기 때문에 처음부터 거부하거나 거절하거나, 적정한 선에서 타협하는 방안들을 제시한다. 물론, 그 과정에서 무지한 경영진과 트러블이 발생하는 것도 다반사이다.이 경우 중간관리자가 개입해서 타협하는 경우가 분명 있다.단언컨대 해당 중간관리자는 둘 중 하나이다. 무지하거나 난파하려는 개발 조직을 재빠르게 떠날 사람이다.소프트웨어 개발에서 '급한 일'이란 없다.정해진 규칙과 기본에 충실하게 하고, 빠진 것 없는지 체크하고 디자인, 설계 후에 미래의 변화에 대해서 적절하게 해당 조직의 규모와 형태에 따라서 반영한 후에 '개발'하는 것이다.지금 이상황에도...'급한 일'이라면서 일을 가져다주는 경영진을 만나고 있을 슬픈 개발자들을 위해서...끄적끄적...
조회수 1645

효율적인 회의를 위해 필요한 것들

일반적으로 회의는 짧은 시간 안에 다수의 팀원들의 소통을 통해팀의 목표를 확인하고,업무에 필요한 정보를 공유하고,빠르게 의사결정을 진행하는,하는 중요한 업무이고 무엇보다회의를 참여한 모든 사람들의 소중한 시간과 리소스를 모은다.라는 점에서 매우 중요한 업무입니다. 그러나, 잘못된 회의 때문에 목표를 명확하게 알 수 없고, 필요 없는 정보 때문에 논지가 흐려져 정확하게 의사결정을 할 수없다면, 정말 비싼 낭비가 될 수 있습니다.동료 간의 오버 커뮤니케이션은 필요한 덕목 중 하나지만,목표가 정해져 있는 회의에서 오버 커뮤니케이션은 시간낭비입니다.그래서 오늘은 이 글은 목적에 맞는, 목표를 확인하고, 정보를 공유하고, 의사결정과 수렴을 명확하게 할 수 있도록 도와주는 회의 방법에 대해 원론적으로 고민해 보고 수행할 수 있도록 해 보도록 제안해 보도록 하겠습니다. (애자일 시리즈도 곧 나올 예정이니 기다려 주세요!)너무 많은 주제와 목표, 참여자는 국물맛을 망칠 뿐이죠!효과적인 회의를 위해 필요한 요소1. 명확한 회의 주제 회의를 만들기 전 “왜 회의를 해야 하는 건지, 목적과 얻고자 하는 것은 무엇인지”에 대해 회의 발의자는 명확하게 설정하고 진행할 수 있어야 합니다.2. 회의에 참여하는 인원에 대한 고려"일단 회의에 필요한 사람들이라고 생각하면 다 모은다.”는 생각으로 참여자를 모으게 되면모두가 공유하는 배경지식이 없을 경우 명확히 의사결정을 할 수 없고,필요한 사람들에게 필요한 정보가 가는 것이 아닌 불필요한 정보전달로 업무의 모호함을 일으킬 수 있고,회의 참석자 역시 왜 자신이 해당 회의에 들어왔는지 의도가 파악되지 않아 혼란을 야기할 수 있어서,회의 발의자는 회의 주제를 명확하게 하는 것만큼 어떤 인원이 참여해야 할 지에 대해 고민해야 합니다.회의 참가가 반드시 필요한 인원을 예시를 들자면,발의된 내용에 의사결정을 할 수 있는 자배경지식에 대해 정확히 알고 있는 자의사결정에 도움을 줄 수 있는 자해당 의사결정으로 업무에 영향을 미치는 자로, 이외에 부분도 어느 정도 고려할 수 있지만, 명료하게 커뮤니케이션을 할 수 최소한의 인원을 모으는 것이 가장 중요합니다.3. 회의를 통해 얻을 산출물 회의를 통해 얻어갈 산출물(또는 예상하는 회의의 Outcome)이 없는 회의는 명확한 주제 없이 흘러가거나목적에 대해 관철시키지 못하는 방향으로 흐르게 돼 회의의 논지를 흐리게 됩니다. 그리고 논지가 흐린 회의는 길고 의미 없는 회의시간으로 진행돼, 남는 게 없는 회의를 하게 됩니다. 흔히 “회의록"이라는 것이 산출물이라고 생각할 수 있지만, 회의록은 “회의의 기록”이지 회의에서 얻고자 하는 결론을 얻어낸 것이 아닙니다. 그래서 제안드리는 부분은 발의자가 회의 시작 전 회의를 통해 얻어내고자 하는 산출물에 대해 참여자와 공유하거나, 어젠다를 공유해 배경과 과정에 대해 설명하고, 회의 참여자도 산출물에 대해 같이 고민할 수 있는 방향으로 진행할 수 있게 합니다.4. 회의의 과정, 어젠다 설정과 진행, 그리고 타임 박싱“일단 이야기를 시작해 볼까?”나 “내가 다 준비해 왔으니, 이거 설명하고 회의 끝내면 되겠다.” 아니면, "기왕 모였으니 이야기도 해볼까?" 등으로 어젠다 설정과 타임라인 없이 회의를 진행하면,대화를 어떻게 시작하고 어떻게 끝내야 할 것인지에 대해 명확하지 못하고정해진 시간보다 더 많은 시간이 소요되될 수 있고이로 인해서명확하지 못한 산출물을 얻어가거나회의가 아닌 설명회로 끝나거나회의가 삼천포로 빠지게 되는목적과 결과에 벗어난 회의로 빠질 수밖에 없습니다. 그러므로, 회의를 진행하는 발의자는 목적 달성과 명확한 산출물을 위해 회의 참여자들과 어떻게 커뮤니케이션을 진행해야 하는지, 어떤 순서와 과정으로 커뮤니케이션을 진행해야 하는지 확인하고(어젠다 설정), 회의에 맞지 않는 이야기가 나올 경우 명확하게 정리하고(목적 주지), 모든 참여자가 회의에 집중할 수 있도록 환경을 만들고(외부 요소, 잡담 차단),회의 진행에 시간을 명확하게 잡아(타임 박싱) 회의시간을 최대한 넘어가게 하지 않도록,회의를 진행해야 합니다.5. 회의 참여자의 집중이야기가 시작되었을 때 시작대는 타이핑 소리, 바로 옆에 있는 직원과 다른 이야기를 공유하는 소리(같은 주제더라도 모든 사람이 아닌 둘이서만 공유하는 소리) 등은 모든 회의에 참여하는 사람들의 집중을 흐릴뿐더러, 한번 공유한 내용을 두 번 세 번 다시 공지해야 하는 상황을 만들 수 있습니다. 정말 중요한 사항이 있다 라고 한다면, 회의를 참가하지 않거나 회의에서 나올 때 양해를 구하는 것이 모두에게 효과적입니다.그렇다면, 효과적인 회의를 위해 내가 해야 할 일은 무엇일까요?회의 발의자회의를 발의하고, 진행하는 사람. 발의한 사람의 의견이 필요할 경우, 진행하는 사람을 따로 두는 것도 좋으나, 배경과 목적을 가장 잘 아는 사람이 발의자 이기 때문에 진행을 같이 하는 게 더 좋습니다.회의에 대해 명확하게 준비해 주세요회의 시작 전회의를 진행하는 배경과 목적회의를 통해 얻어야 할 산출물회의에 필요한 인원회의 어젠다등을 준비하고 예상하는 시간 안에 회의를 잘 마칠 수 있도록 스코핑과 준비에 노력해 주세요.(나의 시간이 중요하듯 회의에 참여한 사람들의 시간도 중요하다는 것을 잊지 말아주세요).회의 목적과 시간을 참여자에게 미리 설명해 주세요회의시간이 시작되면(또는 시작 전), 참여자들에게 구두상으로 또는 메일로라도회의를 통해 얻어가는 목적회의 시간 (열리는 시간과 기간)를 알려주세요. 회의에 대한 정보를 더 정확하게 알 수록 회의를 참여자들도 더 집중해서 회의에 참여할 수 있습니다.회의를 진행할 사람을 반드시 어사인 해주세요회의 진행자를 반드시 어사인해 주세요(매우 중요!). 대부분은 발의자가 진행을 하겠지만, 발의자가 의견을 내고 보다 자유로운 자리에서 회의를 보고 싶다고 한다면, 해당 회의를 드라이브할 수 있는 Facilitator를 두고 진행하는 것이 반드시 필요합니다. Facilitator는 회의 어젠다에 따라 의견 수렴 및 정리를 하고, 잘 진행될 수 있도록 의견을 내기보단 진행에 집중해야 합니다.회의 시작 전, 어젠다에 대해 공유해 주세요회의 시작 시 모두가 모이면, 이번 회의는 어떻게 시작할 것이고 어떻게 끝이날 것인지에 대해 간단히 공유 휴 시작하게 되면 과정과 결과에 대해 서로가 보다 쉽게 접근할 수 있습니다. 저는 개인적으로 시작하기 전 화이트보드에 어젠다와 종료 시간을 적어놓고 시작하는 습관을 들여 모든 사람들이 쉽게 회의에 참여할 수 있도록 노력하는 편입니다.발의자 또는 Facilitor는 회의 주제를 벗어나는 이야기는 과감히 정리하고, 목표시간을 넘길 경우 과감히 대화를 중단시켜 주세요회의가 길어지거나, 집중력이 흐트러질 경우, 주제가 벗어난 이야기들이 나오고, 목표와는 다른 이야기들이 나올 수 있습니다. 그럴 때마다 회의 진행자는 의도치 않은 부분이 나온다 라고 할 경우, 다시 목표하는 부분으로 돌아와 이야기할 수 있도록 가이드해 주세요 해당 부분에 대한 이야기를 해야 할 필요가 있다고 해도, 주제와 벗어났다면, 다른 회의시간을 잡는 게 낫습니다.회의 참여자회의 때 전화기와 노트북은 잠시 꺼두셔도 좋습니다.(정말 진짜 진짜 제일 중요합니다!) 진짜 회의와 상관없이 커뮤니케이션을 위해 노트북이 필요하다면, 필요한 일을 마치고 회의에 들어와 주세요. 한 명의 정신 분산이 다른 사람들의 생산성을 떨어뜨릴 수 있습니다.잡담은 나중에. 모든 회의 참여자와 공유할 이야기가 아니면 지양해 주세요.다른 이야기 도중에 콘텍스트가 흐려질 수 있고, 두 그룹, 세 그룹으로 나눠 이어지는 대화는 회의에 집중을 해치고 회의시간을 낭비하게 됩니다.무엇보다도 집중해 주세요.회의에 집중하는 것이 무엇보다도 가장 중요하겠죠?오늘도 정신없고 긴 글이 나와버렸네요. 최근에 업무도 많아지고 다양한 업무를 하다 보니 글을 잘 못쓰게 되었네요. (네 다 핑계고 열심히 다시 쓸 수 있도록 환경을 좀 바꿔볼까 합니다.)다음글은 애자일 시리즈에 마지막글이 발행될 예정입니다! 마지막이라고 하기엔 앞으로도 제가 일하고 있는 업무환경과 일하고 있는 팀에 대한 글을 많이 쓸 예정이라 민망스럽긴 하지만, 그래도 서둘러 더 재밌는 글 많이 많이 올릴 수 있게 할게요 오늘도 읽어주셔서 감사합니다!#코인원 #블록체인 #기술기업 #암호화폐 #스타트업인사이트
조회수 749

[중요] 아마존 US 수수료에 대한 세금 징수 공지

안녕하세요 대한민국 셀러들의 성공적인 아마존 진출을 도와주는 컨설팅 회사이자 대행사인 주식회사 컨택틱의 이이삭 대표입니다.2019년 6월 1일부터 아마존 US에서 몇 종류의 수수료 (판매수수료, FBA수수료 등)에 대한 세금을 특정 주에 사업이 설립된 판매자로부터 징수하기 시작합니다. 이 변화에 대해 여러분들이 알고 계셔야할 사항은 무엇이 있을까요? 딱 1가지만 기억하세요.1. 한국 판매자들은 전혀 영향받지 않습니다.매번 아마존에 대한 새로운 정책, 프로그램, 이벤트, 변화 등이 생길때마다 여러분께서는 대표적으로 이 한 가지 질문에 대해서 걱정하실겁니다: ‘나한테 영향이 있는 내용인가?’ 그리고 ‘내가 제대로 이해한건가?’ 입니다. 특히나 세금처럼 민감한 주제는 당연히 눈여겨봐야할 것입니다. 그래서 저는 정말 깔끔명료하게 결론부터 알려드리고자 합니다. 이 정책 변화는 한국 판매자들에게 전혀 영향주지 않습니다.Photo by Kelly Sikkema on Unsplash우선, 가장 눈여겨봐야할 내용은 ‘어떤 수수료에 대한 세금을 징수하는건가’입니다. 크게 봐서 두 가지 수수료에 대해 세금이 징수된다고 보면 되는데요, 1) Selling on Amazon Fees (아마존 판매수수료), 2) FBA Service Fees (FBA를 이용할 때 기타 서비스에 대한 수수료)입니다. 2번에 대해서 주의해야 하는게, FBA 배송대행 수수료에 대해서 부과하는 게 아니예요! 사람들이 주로 FBA 수수료라고 할 때 생각하는 게 FBA 배송대행 수수료입니다. 가장 낮게 평가되는 게 $2.41 정도 하고, 무게나 부피에 따라 천차만별로 결정되는 아마존의 FBA 배송대행 수수료는 다시 한 번 말씀드리지만 이 정책에 영향 받지 않습니다! 사람들이 거의 이용하지도 않는 amazon prepping service (라벨링, 포장, 테이핑 서비스 등)에 대해 부과한다는 내용입니다.다음으로 눈여겨봐야할 내용은 ‘누구에게 해당하는 내용인가’입니다. 이것도 두 가지로 봐야하는데요, 첫 번째, Selling on Amazon Fees는 다음과 같은 미국 주에 사업이 설립된 판매자들에게만 해당합니다: Connecticut, the District of Columbia, Hawaii, South Dakota or West Virginia. 만약 여러분의 사업이 위 주에 설립된 사업자가 아니라면 (당연히 이 글을 읽고 계신 여러분은 한국 사업자들일거라 아니라고 생각합니다만), 세금이 징수되지 않습니다. 두 번째, FBA service fee에 대한 세금은 모든 판매자에게 적용되는겁니다. 근데 거의 사용하지도 않는 FBA service fee에 대한 세금 징수예요. 굉장히 헷갈릴 수 있어서 또 강조할게요… FBA shipping fee에 대한 세금이 아니라 FBA service fee에 대한 세금입니다. 이건 모든 판매자들에게 적용되는 내용이며, 배송이 이루어진 FBA 창고가 속한 주의 세율이 적용됩니다 (평균적으로 4~10% 내외).아마존으로부터 위 정책 변화에 대한 이메일을 받은 여러 한국 판매자들이 걱정부터 앞섰을거라 생각합니다. 제가 여러분들을 대신해서 정말 꼼꼼히 이메일을 읽어봤고, 위와 같이 정리해드렸습니다. 참고하실 수 있도록 아래에도 이메일 사본을 첨부해드렸습니다.이 공지에 대한 서론이자 결론은 ‘한국 판매자들은 아무 걱정 없이 평소대로 판매해도 된다’는 것입니다. 따라서 여러분들은 안심하시고 평소처럼 열심히 판매에만 집중하시면 됩니다!Amazon Seller Services로 부터온 이메일 - 1Amazon Seller Services로 부터온 이메일 - 2컨택틱의 모든 교육은 파트너인 글로벌셀러창업연구소와 접수하고 진행합니다. 교육 신청은 아래 링크나 글로벌셀러창업연구소의 홈페이지를 통해 가능합니다.오프라인 아마존 입문 과정오프라인 아마존 기초/심화 과정온라인 아마존 입문 과정그럼 오늘도 즐거운 글로벌 셀링 되세요!감사합니다.컨택틱서울특별시 서초구 서초대로 356, 606호(서초동, 서초지웰타워)대표 전화: 02-538-3939이메일: support@kontactic.com홈페이지: https://www.kontactic.com네이버 블로그: https://blog.naver.com/kontactic카카오 브런치: https://brunch.co.kr/@allaboutamazon유튜브 채널: https://www.youtube.com/c/kontactic
조회수 1804

Interview - Android App Developer 박형일님

크래커나인 팀에서는 사용자의 의견을 적극 반영하기 위해서 안드로이드 개발자 박형일님의 크래커나인 사용기 인터뷰를 해보았습니다.개발자 박형일님본인 소개를 부탁 드려요~저는 에이치나인에서 안드로이드 개발 파트를 담당하고 있는 박형일 입니다. 개발 경력은 12년 정도 됐구요.에이치나인에 입사한지는 4년 정도 됐습니다. 주로 외주 안드로이드 앱 개발 업무를 하고 있습니다.개발일을 꽤 오래 하셨네요. 시니어 개발자들은 코드를 직접 작성하는 것을 선호 하시는 것 같던데, 형일님은 어떠신가요?저도 코드를 직접 작성하는 것을 선호 하는 편입니다. 툴에서 생성되는 코드를 별로 신뢰하지 않아요. 제가 원하는 대로 안 나온다는 느낌을 많이 받거든요.그럼 크래커나인의 첫인상은 어떠셨나요? GUI 로 부터 코드를 생성해 주는 툴인데..처음엔 아이디어는 괜찮은데, 이게 과연 제대로 된 코드를 생성 해 줄까? 라는 의심이 들었죠. 꼭 사용 해 보고 싶은 프로그램은 아니었어요.크래커나인을 사용하신지는 얼마나 되셨죠?올해 6월쯤에 처음 접하여 2달 정도 된 같아요.어떤 프로젝트에 적용 해 보셨나요?회사에서 회의실 예약 시스템이 필요하다고 해서 회의실 예약 앱을 만들었어요.그 때 처음 사용 했죠. 공식 프로젝트가 아니라 디자이너 없이 웹에서 무료로 사용할 수 있는 Sketch 파일로 된 디자인 샘플을 받아서 혼자서 만들었어요.앱을 구성하는 화면은 대략 5~6개 정도로 간단한 프로젝트여서 가능 했죠. 지금은 외주 과제를 하고 있는데, 크래커나인을 사용 해서 하고 있어요.외주 같으면 주로 파워포인트로 작성된 GUI 가이드라인 문서를 보고 개발 하잖아요. 크래커나인을 사용하기 전에는 디자이너와 무엇을 통해서 개발에 필요한 디자인 정보를 얻으셨어요? 에이치나인에 있으면서 거의 대부분 GUI 가이드라인 문서를 보고 개발 했죠. 최근에 다른 프로젝트 팀에서 GUI 가이드라인 문서 없이 제플린을 쓰더라구요. 그래서 그것도 조금 써봤어요.제플린과 같은 기존의 유사 서비스와 비교해서 크래커나인은 어땠나요?GUI 가이드라인 문서를 보면서 개발을 하다 제플린을 써보니까 너무 편리하더라구요. 문서에서 원하는 정보 찾는게 불편했거든요.그래서 사실 처음 크래커나인을 사용 했을 때는 제플린과 큰 차이를 못 느꼈어요.근데 프로젝트를 진행 하다 보니 크래커나인의 코드 생성 기능이 있어서 좀 더 편리하다고 느껴지는 순간이 오더라구요. 제플린을 보고 개발 할 때는 코드나 수치를 직접 입력하다 보니 실수를 할 때도 있었고, 여전히 XML 작성하는 수고로움이 남아 있었거든요.근데 크래커나인의 레이아웃 코드 생성 기능을 사용해서 나온 XML 코드가 100% 는 아니지만 70~80%는 작업을 안해도 될 수준이더라구요. 그래서 XML 작성하는데 들이는 시간이 많이 줄어 들었어요.크래커나인을 익히는데 어렵지는 않으셨어요?타 서비스를 사용한 경험이 있어서 많은 부분 기능을 따로 매뉴얼로 보지 않아도 파악이 됐는데요.사용하는데 크게 문제는 없었던 거 같아요. 직관적으로 파악이 안 되는 기능은 사용하지 못한 것 같지만 따로 매뉴얼은 찾아보지 않았습니다.Cracker9의 어떤 기능이 가장 편리하셨나요?당연히 레이아웃 코드 자동 생성 기능이었습니다.손으로 직접 코딩 하지 않고 View들의 관계를 맺으면 자동으로 View의 관계와 속성을 xml 코드로 생성해주는 기능이 개발하는 데에 상당히 많은 도움이 되었습니다.Cracker9을 사용하면서 불편했던 점이나 개선했으면 하는 부분이 있었나요?Asset 이름이나 리소스(문자열, drawable) 이름이 해쉬값이나 text1, text2 이런 식으로 되어 있어 나중에 다 변경을 해 주어야 되었습니다. 이 부분은 개선이 되었으면 좋겠습니다.※ 위의 내용은 Cracker9 0.9.5 에서 개선되었습니다.Cracker9의 정식 버전으로 출시가 되면 사용할 의향이 있으신가요?네, 사용할 것 같아요. 가격만 너무 비싸지 않으면 전 무조건 사용하겠습니다.App을 만들거나 디자이너와 소통해야 하는 다른 개발자들에게 알려주고 싶은 Cracker9 사용 Tip이 있다면 알려주세요~디자이너가 텍스트나 이미지 단위로 View를 만드는데요. 개발자가 원하는 모든 View를 만들진 않기 때문에 Custom Layout 활용은 필수입니다.Custom Layout을 잘 활용하시면 원하시는 레이아웃 작업이 모두 가능합니다. 그리고, 오른쪽에 Tree Structure 패널이 있는데요.View의 트리 구조 순서로 레이아웃 xml 코드가 생성되기 때문에 어떻게 코드가 만들어질지 예상할 수 있어요. 물론 View의 순서나 부모/자식 관계는 마우스 드래그로 편집할 수 있습니다.마지막으로 Constraint Layout의 관계를 맺을 때, View가 작으면 정확하게 클릭하여 작업하기 어려울 수 있는데요. 당연하지만 View를 확대해서 연결 지으면 쉽게 작업할 수 있습니다.마지막으로 Cracker9에게 한 말씀해주세요~저는 안드로이드 App을 개발하면서 레이아웃 작업은 초반에 하는 시간 잡아먹는 노가다 작업이라고 생각을 했는데요.레이아웃을 자동으로 생성해주는 Cracker9을 사용하면서 더 이상 노가다라는 생각을 하지 않게 되었습니다. 아직은 Beta 버전이라 부족한 부분이 보이지만, 개선될 것이라고 믿고 계속 사용할 거 같아요.앞으로 발전하는 모습 기대하겠습니다 파이팅!#에이치나인 #디자이너 #개발자 #협업툴 #크래커나인 #솔루션기업 #팀원인터뷰 #기업문화 #조직문화 #팀원자랑
조회수 1531

제대로 콘텐츠 디자인하기 – 판타지 편

수많은 도서 분야 중 리디북스가 가장 집중하고 있는 5개의 장르를 아시나요? 바로 리디북스 홈페이지를 상단 메뉴를 구성하고 있는 일반, 로맨스, 판타지, 만화, BL 장르입니다. 저는 리디북스 콘텐츠팀 디자이너로서 이 5가지 장르에서 진행하는 프로모션 디자인을 담당하고 있습니다. 5가지의 장르 모두 개성이 뚜렷한 만큼 디자인하는 방법도 조금씩 다른데요, 이번 포스팅에서는 5개의 장르 중 판타지 장르의 콘텐츠디자인 이야기를 들려드리겠습니다.판타지는 어둠의 다크?처음 판타지 장르의 콘텐츠디자인을 시작했을 때, 바탕색은 어둡게, 포인트 컬러는 채도가 높은 색을 사용하여 강한 대비를 표현하는 것이 전형적인 특징이었습니다. 저도 그 특징에 따라 일단 어두운 배경을 만들고 하나하나 요소를 넣으며 작업하였습니다. 그렇게 몇 개의 판타지 콘텐츠의 디자인을 하며 도서들을 접하다보니 판타지 도서가 어둡고 강한 이야기도 있지만 신이나 마법, 초현실 등 다양한 주제들로 세분화되기 때문에 맹목적으로 어두운 분위기로 디자인하는 것이 옳은 것이 아니라는 생각이 들었습니다. 그럼 어떻게 디자인을 해야 다양한 판타지 콘텐츠들에 각각 걸맞은 옷을 입힐 수 있을까? 하는 고민이 시작되었습니다.초반 판타지콘텐츠 디자인 작업. 바탕은 어둡게, 타이틀은 밝게.판타지는 세계다.판타지라는 단어가 갖는 특징은 뭘까 생각해보았습니다. ‘현실이 아닌 이상, 상상의 세계’. ‘개개인이 꿈꾸는 세상’, ‘현실의 극한적 왜곡’ 등등 여러 가지로 생각할 수 있는데요, 저는 개인이 환상을 담고 있는 ‘공간’이라는 느낌이 들었습니다. 실제로 많은 판타지 소설들은 이계, 사이버 세계, 중세, 현대. 초현실 등 시공간적 배경을 담고 있습니다.그래서 판타지 도서의 이벤트 페이지를 디자인 할 때 해당 소설이 가진 공간적 배경을 활용한다면 판타지 소설을 더욱 판타지답게 보여줄 수 있겠다고 생각하였습니다. 독자의 입장에서 볼 때도 소설 특징이 반영된 이벤트 페이지를 보면, 마치 그림책을 보듯이 도서에 대한 이해가 훨씬 이해가 쉬울 것이란 확신도 들었습니다.판타지 디자인 = 공간감과 입체감이후 저는 디자인을 할 때 구성 요소를 ‘공간 안에 넣는다’는 생각을 갖고 공간감 만들기에 집중하였습니다. 많은 게임 웹사이트가 좋은 참고자료가 되었습니다. 평면적인 디자인에 익숙했던 터라 입체적인 판타지 디자인 결과물은 굉장히 색다른 느낌이 들었습니다. 시각적으로 멋지기도 하지만 공간감 때문인지 몰입하게 만드는 힘이 있어서 시선을 강하게 잡았습니다.또한 ‘어둡게 표현한다’는 제한을 없애고 여러 컬러를 활용하여 몽환적이거나 신비로운 느낌의 다채로운 판타지 콘텐츠를 만들었습니다. 어떤 방식으로 디자인을 하더라도 공간감이라는 규칙이 있었기 때문에 통일감이 생겼고 이 특징은 자연스럽게 판타지 카테고리의 아이텐티티가 되었습니다.다양해진 컬러와 공간감의 표현입체적인 공간 연출법공간감을 연출하기 위해서는 어떻게 해야 할까요? 실내 이미지 사용, 구성 요소에 입체감 주기, 그림자 넣기 등등 많은 방법이 있습니다. 하지만 이중 가장 중요한 요소를 고르자면 바로 ‘빛’입니다. 가상의 조명을 왼쪽, 정면, 오른쪽에 배치한다고 생각해보세요. 가끔은 역광까지 알맞은 위치를 선정하고 그에 맞는 광량을 요소별로 적용하면 입체적인 느낌이 살아납니다.이 때, 일률적으로 똑같은 빛 효과를 주기보다는 위쪽 오브젝트엔 하이라이트와 강한 그림자 효과를, 아래쪽 오브젝트는 밝은 부분을 줄이고 음영 위주로 표현해주는 것이 좀 더 자연스럽게 공간연출을 할 수 있습니다. 막혀있는 공간이 아닌 하늘, 들판을 배경으로 사용한다 해도 빛을 이용하면 쉽게 공간감을 표현할 수 있습니다.배경레이어 위에 타이틀을 올린 예시배경에 빛을 주고 각 폰트에 같은 레이어 스타일을 적용한 예시광원에 따라 자연스럽게 빛 효과를 준 예시맛깔나는 효과공간감을 연출했다면 이제 효과라는 양념을 추가해 좀 더 맛깔나게 페이지를 구성해야 합니다. 너무 과해서 촌스럽지만 않다면 개인의 역량껏, 마음대로 구성해 볼 수 있기 때문에 가장 재미있는 작업입니다. 기본적으로 많이 사용하는 효과는 포토샵 블렌딩 모드 중 ‘linear dodge’와 레이어 스타일 중 ‘bevel and emboss’입니다.1) Linear DodgeLinear Dodge는 흰색 부분을 유지한 채 검은색에 흰색을 추가해 더욱 밝게 해주는 기능으로 발광 효과를 내는 데 주로 사용합니다. 검정 바탕색에 흰색이 블렌딩 되면서 빛을 내기 때문에 경계선을 뚜렷하게 하는 것보다 blur를 주어 그라데이션을 만들면 빛나는 효과를 더욱 살릴 수 있습니다.2) Bevel and EmbossBevel and Emboss는 평면레이어에 입체감을 주는 효과입니다. 각 항목별로 수치를 조정하여 양각, 음각, 높이와 빛 방향, 빛과 그림자 색 등등 다양한 표현을 이 하나의 기능 안에서 구현할 수 있습니다. 하나씩 조절해보며 자신이 내려고 하는 효과에 맞는 수치를 찾고 적용하면 됩니다. 특히 이 효과를 서체에 적용하려고 할 때 중요한 팁을 드린다면 바로 ‘폰트 선택’입니다. 고딕체에 적용하는 것보다 세리프체나 획의 굵기의 변화가 많고 특이한 모양의 폰트에 적용하면 효과가 더욱 살아납니다. 특이한 폰트가 없다면 기본 폰트선택 후 Convert to Shape하여 일부러 변형을 주어 사용하면 극대화된 효과를 볼 수 있습니다.마치며판타지 도서의 다양한 개성을 표현해보려고 시작한 방법들이 이제는 리디북스 판타지 디자인의 전반적 흐름이 되어 뿌듯하기도 하지만 이것이 정답은 아니라고 생각합니다. 처음 일을 시작했을 때 맹목적으로 어둡게 디자인을 하던 시절의 잘못을 반복하지 않기 위해 요즘은 다시 입체적인 것, 효과를 주는 것이 맞는 것인지, 과하지 않은지 반문하고 있습니다. 디자인 트렌드는 계속 변하고 새로운 것이 생겨나기 때문에 틈틈이 좋은 방법이 있는지 찾아보기도 하구요. 더 멋진 판타지 장르 콘텐츠 디자인을 위해 오늘도 열심히 고민하겠습니다. 감사합니다.#리디북스 #디자인 #디자이너 #콘텐츠 #콘텐츠디자인 #콘텐츠디자이너 #개성 #장르 #판타지 #공간감 #입체감 #광원효과 #고민 #작업후기
조회수 951

사업엔 정답이 없다

사업엔 정답이 없다.사업에 정답이 있다고 생각하는 사람들이 많다. 특히 성공한 기업들만 후빨 하는 사람들이 그렇게 생각하는 경향이 있고, 언론과 책 몇권에서 얻어낸 얇팍한 '정보'로 각종 교육, 창업 컨설팅 등으로 포장해 스타트업 워너비 젊은이들 대상으로 돈벌이를 하는 경우가 매우 많아졌다.성공한 기업을 retrospective하게 분석하면, 그 성공한 기업들이 순간순간 선택했던 선택은 '정답'이고, 창업자들이 이미 세상이 그렇게 흘러갈거라는걸 알고 있었을 정도로 똑똑했기 때문에 그런 선택을 할 수 있었던 것 처럼 생각하기 쉽상이다.실상은 전혀 그렇지 않다.순간순간의 선택이 성공으로 이어질지, 사업을 접는 결과로 이어질지는 누구도 예측할 수 없다. 성공한 기업의 '옳은 선택'에는 수많은 우연적 요소가 작용한다.마이크로소프트가 IBM 과 공급계약을 채결했지만, 그냥 애플이 시장을 석권했다면 지금의 마이크로소프트는 없다. 품질 좋은 검색엔진 구글은 창업 자체가 그 당시의 시각으로 보자면 야후를 비롯 이미 시장을 석권한 대기업들에 도전하는 매우 멍청한 결정에 가까웠다. 페이스북이 초기 하바드 대학생들 사이에 인기를 끌지 못하고 사장되었다면? 복귀한 잡스가 주요 제품군을 정리하고 MP3 플레이어인 아이팟을 출시하는 전략은 어땠을까? 지금은 mp3 파일을 구매할 수 잇는 아이튠스 시장을 함께 오픈한 것이 대단히 뛰어난 선택 같아보이지만, 그냥 불법 공유 사이트를 통한 다운로드가 그대로 성행했다면, 저작권 저촉을 받지 않는 중국에서 불법 mp3 공유 회사가 창업했었다면?지금와서 돌아보건데 대단히 뛰어난 결정들엔 그 결정들이 실패로 귀결될 수 있었던 수많은 일들이 운좋게도 '일어나지 않았기 때문에', 혹은 반대로 성공으로 귀결될 수 있는 일들이 운좋게 '일어났기 때문에' 성공에 다다를 수 있었던 것이다.실리콘벨리에서 창업한 1500여개 회사중 평균적으로 1개 기업이 조단위 이상의 큰 성공을 이룬다. 나머지 1499개 기업은 다들 멍청했기 때문에, 스타트업 강의에서 얘기하는 '성공비결' 몰랐기 때문에 실패했을까?그렇지 않다. 미래는 누구도 예측할 수 없고, 지금의 선택이 어떤 결과로 이어질지 정확이 예측하긴 불가능하다. 그저 우리는 '대단히 멋지게 성장할 수 있는 몇가지 가설을 근거로 새로운 비즈니스 모델'을 가지고 용감하게 끊임없이 시장에 던져보는 수밖에 없다.1500개 기업 중 하나가 되어 보는 것, 그것이 성공의 비밀.#3billion #운영 #인사이트 #스타트업 #마인드셋 #조언
조회수 736

모바일 앱마케팅 시, 필수적으로 고려해야 할 4가지

기업 입장에서 모바일은 사용자 연결에 매우 강력한 수단입니다. 하지만 효율적인 앱마케팅 및 지속적인 관계를 유지하기 위해선 개인화, 편의성 등 세밀하게 신경써야 할 부분이 많습니다.1. 모바일앱은 모바일앱 답게모바일을 단지 데스크탑의 축소 버전으로 판단하고 데스크탑에서 제공하는 모든 기능을 작은 화면에 제공할 필요는 없습니다. 모바일 앱은 분명 웹하고는 다른 플랫폼이고, 사용자 역시 앱에서 기대하는 경험은 웹과 다릅니다. 데스크탑과 같이 페이지간 전환이 발생하면서 로딩되는 느낌을 제공한다면, 사용자에게 그 앱의 꾸준한 사용을 기대하긴 어렵습니다.사용자에게 정말 필요한 기능만을 중점적으로 제공함으로 사용자의 앱 사용 패턴을 단순화 해야 합니다. “The font game”이란 모바일 앱은 모바일에 최적화 된 디자인 예입니다. 굉장히 큰 버튼과 눈에 띄는 버튼(CTA), 그리고 핵심 기능만을 메인에 배치함으로 모바일 환경을 고려해 제작된 앱이라 볼 수 있습니다.  2. 기존 보유하고 있는 채널 활용하기2017년 스토어에서 발생할 앱 다운로드 수는 천억 건이 넘을 것으로 예상됩니다. 하지만 우리의 앱이 많은 다운로드가 발생하리란 보장은 없습니다. 그렇기에 마케팅이 필요한 것인데요, 마케팅을 새로운 채널에 비용을 들여하는 방법도 있지만, 이미 웹 등 타 채널을 운영중인 기업은 앱을 런칭할 때 적극 활용해야 합니다.꼭 앱 광고를 위한 프로모션 페이지가 아니더라도, 고객이 웹사이트에 방문했을 때, 모바일앱이 있음을 인지할 수 있도록 최적화 해야 합니다.‘Nordstrom’은 모바일 앱이 있었지만, 한줄의 텍스트 링크만을 제공하여 앱의 존재여부를 인지할 수 조차 없었습니다.반면, ‘Sephora’는 모든 페이지 하단부에 iOS 앱 다운로드 링크를 게재하여누구나 인지할 수 있고, 빠르게 스토어로 이동할 수 있도록 제공하고 있습니다.3. 어쨋든 앱을 쓰겠지라는 생각 버리기모바일앱 비즈니스가 성장하기 위해 가장 중요한 건 리텐션입니다. 하지만 대부분의 앱 사용자의 90%가 6개월 이내에 앱을 방치 또는 삭제를 합니다. 이를 해결하기 위해선 결국 사용자에게 앱을 정기적으로 사용할 수 있도록 동기부여가 필요하다는 말인데요. 이를 해결하기 위한 방법은 2가지 입니다.1) 직접 고객에게 답을 얻기이는 사용자가 모바일앱으로부터 원하는 것이 무엇인지 직접 묻는 것입니다. 왜 앱을 사용할까, 어떻게 앱을 사용할까, 언제 앱을 사용할까. 만약 이에 대해 대답하지 못한다면 고객 대상의 리서치가 필요합니다.2) 고객의 재사용을 위한 인게이지먼트 메커니즘을 만들기쉽게 말해 앱을 사용하는 고객만을 위한 베네핏을 만드는 것입니다. Walgreen의 경우 모바일 앱을 통해서만 발급하는 쿠폰을 운영 중이며, 이는 국내 소셜 커머스에서도 주로 활용하는 방법입니다..또한 사용자를 위해 꾸준히 개선하고 있음을 알릴 필요가 있습니다. 즉 정기적인 업데이트가 필요합니다. 이를 통해 사용자에게 앱을 재 인식 시키고, 업데이트 후 첫 실행 시, 기능 또는 메뉴 등 개선된 부분을 인지시키는 것이 좋습니다. 4. 모바일=개인화우리의 앱은 매일매일 고객 주머니에 함께 합니다. 이는 그들의 개인적인 의견을 알 수 있는 가장 완벽한 기회를 제공합니다. 이를 통해 기업은 고객에게 가치있는 것을 제공할 수 있습니다.그러나 많은 기업이 앱을 다운로드 하는 데만 투자하는 경우가 많습니다. 꾸준한 사용성을 고려한다면 고객의 반응을 빠르게 살피고 대응하기 위한 앱 내 커뮤니케이션 공간을 만드는 것도 방법이 될 수 있습니다.Urbanspoon의 경우, 앱 내 간편한 피드백 기능을 제공하는 커뮤니케이션 툴을 적용했습니다. 이를 통해 사용자가 앱 스토어 불편한 사항을 게재하기 떠나기 전에 미리 앱에서 소통하고, 빠르게 문제를 해결하는 방향으로 운영했습니다. 그 결과 앱 순위, 리뷰평, 리텐션 모두 긍정적인 성장을 거두었습니다.모바일앱은 강력한 채널이고 비즈니스 성장에 좋은 기회이지만, 그만큼 운영의 묘(妙)가 매우 중요한 채널이라 할 수 있습니다. 마케팅을 접하는 고객의 환경을 한번 더 고려한다면, 성공적인 모바일앱 마케팅 효과를 얻을 수 있을 것입니다.source : https://blog.kissmetrics.com/mistakes-in-app-marketing/ * WISETRACKER는 모바일 광고 성과 측정부터 In-app 이용자/컨텐츠 분석, 푸시메시지 최적화까지 지원하는 모바일 통합 분석/타겟팅 솔루션입니다. 와이즈트래커 솔루션의 무료체험을 원하실 경우 여기를 클릭해주세요.* WISETRACKER가 제공하는 무료 데이터 분석 컨설팅를 원하신다면 여기를 클릭해주세요.#와이즈트래커 #서비스소개 #앱마케팅 #데이터분석 #데이터트래킹
조회수 1403

냉정과 열정 사이

냉정과 열정 사이라는 소설이 있다. 대학교 때 읽었던 소설인데 두 사람의 여정을 각자의 시선에서 다룬 소설이다. 에잇퍼센트에 인턴으로 입사해 9개월간 일하고 훨훨 날아간 병훈님과 나도 이 소설처럼 각자의 시선에서 지난 9개월을 되돌아보려 한다. (경고한다. 로맨틱하지 않다.)병훈님이 떠나는 날. 아마 여러분이 보는것과 내가 이 사진을 보는 느낌이 많이 다를거다.1. 만나기까지- 소병훈 이야기2015년 대학교 3학년이 시작될 때부터 졸업 이후에 대한 고민이 생겨났다. 대학원 진학과 취직은 수많은 대학생들의 공통된 고민이기에 수많은 조언이 넘쳐나지만 결론은 '나에게 맞는 길'을 선택하는 것이다. 내 인생 내가 선택해야지 언제까지 남들 좋다는 길로만 가겠는가. 둘 다 겪어보고 내가 선택하겠다고 다짐했다.졸업을 위해서는 대학원에서 과제연구를 1년 해야 했기에 대학원은 겪어 볼 수 있었다. 그러면 취직도 경험해보고 싶은데 어떻게 하지? 대기업에서 1~2개월 인턴을 했던 친구들에게 물어보니 한결같이 '놀고먹다 보니 월급이 나온다'는 경험담을 늘어놓았다. 하지만 정말로 취직해서 놀고먹으면 잘리겠지. 대기업 인턴은 패스. 스타트업 관련 세미나에서 한 VC의 '스타트업은 망해도 스타트업 인턴은 망하지 않는다'는 말을 들었다. 창업에 생각이 있으면 스타트업에서 인턴을 해보라는 말이었다. 그래서 '스타트업에서 일해보자'라고 결정했다.수많은 스타트업 중에서 왜 에잇퍼센트를 선택했다고 물으신다면, 빠른 속도로 성장하면서 변하고 있는 스타트업 속에서 일해보기를 원했기 때문이다. 그리고 당시의 나는 CTO의 멋진 말 한마디에 눈을 반짝이며 '이 회사에서 이 사람과 일하고 싶다'라고 생각하면 앞뒤 안 가리고 지원하는 이상주의자였다. 그래서 페이스북에서 호성님의 글을 읽고 '이 회사가 내가 생각하던 회사구나'라는 생각이 들어서 먼저 지원했던 회사를 포기하고, 에잇퍼센트 입사를 간절히(?) 원하게 되었다.- 이호성 이야기2016년 1월의 첫 번째 근무 날. 대표님이 모두를 불러 모았다. 그리고는 회사의 투자 유치 소식을 알려 주었다. (무슨 투자 유치 소식을 "오늘 저녁에는 치킨을 시켜 먹기로 했어요." 수준으로 재미없게 이야기하는지 모르겠다.) 투자를 받는 것이 확정되었으니 대표님이 내게 전달해 주신 미션은 개발자를 채용해서 제품 개발의 속도를 높이라는 것이었다. 사실 에잇퍼센트에 오기 전에 한 회사에만 오래 있기도 했고 개발자들과의 네트워킹도 게을리했던 터라 당장 좋은 개발자를 뽑을 수 있는 방법이 없었다.그래서 블로그에 회사를 알리는 글을 쓰기 시작하면서 주위 분들께 추천을 부탁드렸다. 그중 JDLab의 양주동 대표님이 괜찮은 학교 후배를 추천해 주신다고 해서 속으로 쾌재를 불렀다. 하지만 추천해 주신 친구가 애매하게 9개월만 일할 수 있는 상황이라고 하니 고민이 되었다. 주니어가 실제로 일을 잘 하게 되려면 꽤 긴 시간이 필요한데, 실제로 일을 잘할 수 있게 되었을 때쯤 회사를 떠나는 게 아닐까 하는 생각이 들었기 때문이다. 하지만 인력(당시 4명)에 비해 해야할 일이 너무나도 많았기에 누군가의 손이라도 빌려야 할 판이었다. 그래서 일단 병훈님을 만나 보기로 했다.2. 면접- 소병훈 이야기에잇퍼센트에 들어가는 과정은 상당히 길다.처음에 간단한 티타임을 시작으로 실제 코딩 문제를 풀어보게 하고, 그 뒤에서 다시 1대 n으로 토론하는 과정, 그리고 대표님과의 이야기로 면접이 이어진다. 요즘은 논술 문제도 있다고 들었다. (역시 취직은 어려워)내 경우는 '면접 보려는 것은 아니니 그냥 커피 한잔 하자'는 부님의 간단한 속임수에 넘어가 티타임을 가졌다. 카페에서 커피 한잔 하면서 부님과 에잇퍼센트는 어떠냐고 물어보려고 왔는데, 어느새 내 앞에는 호성님이 앉아 있었고, 메일로 코딩 문제를 받는 것으로 커피 한잔이 끝났다. 이 티타임은 면접보다는 나에게 회사를 소개하고 회사가 나에게 적합한지 보는 과정이었다.코딩 문제는 성호님의 글로 유명해진 pingpong을 포함한 take-home 과제였다. 문제를 받은 다음날 다른 회사 면접을 보고 온 뒤 밤샘으로 문제를 풀었던 것과 제출할 때 pingpong 문제만큼은 자신 있어했던 기억이 난다. 그때의 기억을 떠올리며 당시에 제출했던 코드를 보니 'Assignment를 쓰지 말 것'이라는 조건이 깨져있었다. 자신감 넘치던 과거의 내가 부끄러워지는 순간이다.마지막 면접 과정도 조금은 숨 막히는 경험이었다. 가볍게 대화하는 분위기 속에서 대학에서 들었던 전공과목 별로 하나하나 물어가며 내 지식의 바닥을 확인했다. 대학에서 3년간 들었던 전공과목은 많지만, 질문 들어오는 족족 '모르겠습니다' 밖에 할 수 없었다. 내가 답할 수 있는 수준을 찾으시려는지 점점 질문의 난이도가 낮아졌고, 마지막으로 스택과 큐를 물어보는 질문에 답하면서 '이 회사는 못 들어가겠구나'라는 생각이 들었다.동시에 진행했던 다른 회사에서 합격 메일이 왔기에 에잇퍼센트에 '0월 0일까지 합격/불합격 결과를 알려주세요'라는 당당한 요구를 한 뒤 떨어졌다는 메일을 기다리고 있었다. 하지만 예상치 못한 합격 메일을 받았고, 그 메일에는실력에 대해서는 회사에 오셔서 보여주세요라는 잊지 못할 문구가 있었다.그리고 첫 출근, 4월 4일 9시 20분에 출근해서 잠긴 문을 보며 에잇퍼센트의 첫 날을 맞이했다.- 이호성 이야기병훈님이 왔다고 하셔서 학교 선배인 부님과 함께 회사 옆 '피어나' 카페로 갔다. (당시만 해도 사무실에 회의실이 없어서 모든 미팅을 회사 옆 카페에서 해야만 했다.) 병훈님의 첫인상은 “꺼벙이"였다.공대에서 흔히 볼 수 있는 스타일. 하지만 말하고 이야기하는 것은 번뜩이는 느낌은 크게 들지 않았다. 아마 나정도로 평범한 느낌이었던 것 같다. 이야기를 하다 보니 다른 곳에 면접을 이미 본 상태였다. 일단 우리 회사와 나에 대해서 좋은 감정을 갖게 하는 것이 좋겠다 싶어서 이래저래 약을 팔았다. 그리고 면접 문제를 메일로 전달하겠다고 하고 첫 번째 만남을 마쳤다.며칠 뒤 제출한 과제를 가지고 다시 한번 병훈님을 만났다. 전공에 관련된 기본적인 질문들을 던졌다.(정확히는 졸업한 지 10년이 지나서 그냥 내가 기억나는 것들을 물어보았다.) 그런데 10개의 질문을 던지면 8개의 질문 은 원하는 답을 듣지 못했다. 실망했다. 겸손하고 배움의 자세가 갖춰져 있는 친구라는 생각은 들었다. 하지만 이렇게 모르는 친구를 뽑아도 될까 하는 생각이 들었다.하지만 뽑았다. 솔직히 그냥 학벌을 보고 뽑았다. 좋은 학교에 다니고 있는 친구이니 지금까지 최소한 한 번쯤은 최선을 다해 본 적이 있겠지 라는 생각을 했다. 무엇보다 당시 나는 꽤 급했다.합격 메일에는 ‘실력에 대해서는 회사에 오셔서 보여주세요'라는 내용을 적어서 보냈다. 부족한 만큼 회사에 와서 최선을 다해주었으면 하는 마음이었다. 그리고 입사할 주에 있을 워크숍 준비에 대한 요청도 함께 드렸다.지금 와서 이야기하는 것이지만 최근에 병훈님을 면접 봤다면 떨어뜨렸을 거다. 생각해 보면 이게 면접, 특히 주니어 면접의 어려움이다. 그 사람이 입사해서의 2주 정도는 예상해 볼 수 있지만 그 뒤는 예상하는 것은 너무나 어려운 일이다.3. 들어와서 처음 했던 일- 소병훈 이야기들어와서 처음으로 했던 일은 나를 대학생에서 직장인으로 바꾸는 일이었다.회사에 들어온 지 1~2개월이 지났을 때 외부 업체와 전문 통신을 개발하는 작업을 맡았다. 대학교에서 두 PC 사이의 전문 통신 프로젝트를 만들었던 기억이 있어 충분히 혼자서(그리고 짧은 기간에) 만들 수 있으리라 생각하고 작업을 시작했다. 기존의 코드를 조금씩 수정하고 추가하던 이전의 작업들과는 다르게 처음부터 만들어내는 일이었다.이 일을 하면서 지금까지 '하나의 동작을 하는 무언가'를 100% 혼자서 만든 적이 없다는 것을 깨달았다. 항상 기본 틀을 받아서 코딩하고, 어려울 때는 모범 답안을 보면서 힌트를 얻었으며, 그러고도 힘이 부치면 7~80%만 완성하고 (시간이 없었다는 핑계를 대면서) 넘어갔었다. 회사에서는 이 일이 '소켓 통신의 이해를 확인하기 위한 프로그래밍'이라고 설명되어 있지 않았고, 어디서 버그가 발생했는지 힌트를 얻을 수 없었다.대학 강의로 들었던 내용들과 전혀 다른 지식들이 필요했지만, 필요한 기초적인 요소들은 구글에서 찾을 수 있었다. 하지만 어떤 키워드를 검색해야 하는지부터가 문제였다. 검색해야 하는 단어를 알아내려고 시니어 개발자님들께 돌아가면서 물어봤다. (너무 자주 물어야 해서 한 분에게만 묻기 죄송했다.) 처음에는 학교에서 배운 내용은 쓸모없다고 생각했었는데, 지금 생각해보니 그마저도 없었으면 구글과 위키의 내용도 이해 못했을 것 같다.웹 개발에 대한 기초도 없고, 어디가 끝인지 확신도 없어서 개발 시간이 길어졌다. 야근을 반복했다. 노력한다고 해서 없던 능력이 생기지는 않았고, 결과로 커다란 똥덩어리 같은 코드가 만들어졌다. 다행히도 (달리는 중간에 몇 개의 부품을 갈아 끼운 이후에) 최소한의 기능은 정상적으로 돌아갔다.그렇지만 이 코드가 12월까지 구린 냄새를 피우고 있었다. 에러를 만들지는 않지만 가독성이 떨어지고 창의적인 구조 때문에, 유지/보수를 할 때마다 과거의 내 실력을 확인하는 좋은 지표가 되었다.- 이호성 이야기시간이 많다면 병훈님을 옆에 앉혀 두고 차근차근 알려주고도 싶고, 같이 스터디도 하고 싶었지만 내게는 당장 해야 하는 일이 쌓여 있었다. 다행히 팀에 계신 시니어 개발자 분들이 병훈님일 이래 저래 잘 돌봐 주었다. (20살이 넘는 청년에게 "돌봐 주었다"라는 표현이 적당한 가에 대해서 곰곰 생각해 보았는데, 흠. 역시 적절하다.) 병훈님께 처음 한 달 동안은 조각을 고치는 일, 작지만 급한 일 들을 맡겼다. 덕분에 시니어 개발자들이 다른 일들에 집중을 할 수 있었다. 그리고는 한 달이 지나자 하나의 일을 떼어서 맡겨볼 수 있겠다는 생각이 들었다. 단순히 개발하는 일뿐만 아니라 다른 회사 개발자들과 커뮤니케이션을 직접 하면서 일을 할 수 있도록 했다. 병훈 님은 잊어버렸을지는 모르겠지만 외부 업체로 처음 전화를 걸었을 때 우리 팀의 시니어 개발자들은 모두들 키보드에서 손을 놓고 병훈님의 대화를 노심초사하면서 듣고 있었다.이 프로젝트는 곧 병훈님이 예상한 일정을 넘어섰고, 얼마 이후에는 내가 예상한 일정도 넘어섰다. 병훈님이 끙끙 앓고 있는 게 보였다. 그 일을 다른 사람에게 넘겨야 하는가의 고민도 여러 번 했다. 병훈님이 만들어 낸 창의적(이라고 말하고 싶겠지만 상식을 벗어난)인 코드들을 뜯어고치고 싶다는 생각도 했다. 하지만 시간은 지났고 테스트를 통과한 코드는 에잇퍼센트 프로덕트의 한 자리를 차지했다.4. 무엇을 배웠을까?- 소병훈 이야기첫 번째로 회사가 어떻게 돌아가는 지를 배웠다. 작은(?) 스타트업이었기에 개발팀 외 다른 팀원들과도 친하게 지낼 수 있었고, 회사 내에서 생기는 사건들을 전부 들을 수 있었다. 그렇게 아이디어가 나오는 순간부터 제품으로 완성되는 과정을 볼 수 있었다. 또한 회사의 크고 작은 의사 결정 과정을 지켜볼 수 있었는데, 모든 의사 결정들에 원인과 논리적인 과정이 따른다는 점이 재밌었다.내가 알지 못하는 원인들과 다른 사람들이 결정하게 된 이유가 궁금해서 여기저기 물어보았고, 모두들 숨기지 않고 말해 주었다. 대표님과의 티타임에 찾아가서 묻기도 하고(모두에게 열려있었는데 단 2명이 왔었다), 퍼포먼스 마케팅이 궁금하다며 점심시간에 옆에 앉아 이야기하고, 전화 응대를 어깨너머로 들어보기 했다. 글로 적어보니 처음 초등학교에 들어간 8살 아이 같기도 하지만, 에잇퍼센트에 있으면서 물어보는 만큼 알 수 있었고, 그만큼 이전과는 다른 세상을 알 수 있었다. (그리고 그만큼 야근을 했다.)두 번째는 개발자가 되는 과정을 배웠다. 당연히 개발 실력도 늘었지만, 조금 더 보태서 개발자가 되는 과정을 배웠다고 말하고 싶다. 누구라고 말할 것 없이 남는 시간을 조금씩 쪼개 공부하고 있는 사람들, 새벽 4시가 넘었음에도 꼼꼼히 기록을 남기며 마무리하는 야간작업, 그리고 혼자서는 만들 수 없는 거대한 코드를 점진적으로 만들어가는 개발팀을 보면서 개발자라는 직업을 만날 수 있었다. 내가 본 개발자는 (에잇퍼센트의 개발자만의 특징일 수도 있지만,) 모든 결과를 '우연'으로 넘기지 않고 원인을 찾았고, 원하는 분야를 찾아서 스스로 공부하고, 삶의 즐거움을 하나씩 가지고 있는 사람들이었다.마지막으로 나 되돌아보기. 나는 내 실력을 과대평가하고 있었다. 회사에 들어오면서 '열심히 하겠다'라고 말했지만 몇 개월 '열심히' 뛰어서 갈 수 있는 거리에는 한계가 있었다. 다른 사람들이 불가능하다고 말해도 혼자서 '노력하면 할 수 있다'라고 생각하면서 오기로 붙잡고 있다가 결국 기한을 넘긴 적이 많았다. 시간이 지나면서 '할 수 있을 것 같다'는 자신감이 아니라 완성된 결과물을 보면서 실력을 확인했다. 항상 자신감이 넘치다 보니 매번 내 생각보다 실력이 뒤에 있었고, 그런 생각이 들 때마다 기숙사에서 공부를 했다.그렇지만 나를 과대평가했던 것처럼 나의 목표도 과대평가 했었다. 내가 도달하려고 했던 목표도 꾸준히 달리면 도달할 수 있는 거리에 있었고, 생각보다 멀리 있지 않았다. 다만 '꾸준히'의 기준이 몇 주, 몇 개월이 아니라는 것을 배웠을 뿐이다.- 이호성 이야기내가 입사하기 전에 에잇퍼센트에 여러 명의 개발 인턴이 있었다고 했다. (commit log에서만 만날 수 있는 그대들이여. 왜 버그를 내게 주고 갔는가.) 그리고 한 명을 제외하고는 회사를 모두 떠났다. 처음에 대표님이 인턴 채용 제안을 몇 번 하셨을 때 개발팀에는 인턴을 채용하지 않겠노라고 말했었다. 사람이 전부인 개발팀에서 떠나는 것이 예정된 사람을 뽑고 싶지 않은 마음이었다. 하지만 병훈님은 이런 내 생각을 바꿔 놓았다.연말 평가에서 성장에 대한 상을 받을 만큼 병훈님의 성장은 눈부셨다. 이제 좋은 주니어는 무엇인가에 대해서 병훈님을 기준으로 생각을 할 수 있게 되었다. 주니어 채용에 대한 성공체험을 했다고도 할 수 있겠다.상은 병훈님이 받는데 주는 사람이 더 좋아하네?좋은 주니어는 당연하게도 일정 시간이 지났을 때 높은 곳에 올라갈 수 있는 사람이다. 높은 곳에 올라가기 위한 조건은 다음과 같은 것들이 있다.1) 상대적으로 이미 높은 곳에 있을 것 전설 속에만 존재하는 시니어 같은 주니어 되시겠다. 고등학교, 대학교 때 많은 지식과 경험을 쌓아서 이미 현업에서 잘할 수 있는 친구들이다.2) 인지능력, 학습능력문제를 이해하고 정의하는 능력이 뛰어나고 논리적인 사고를 한다. 속칭 똑똑한 친구들이다. 문제를 자세하게 설명해 주지 않아도 문제의 본질을 이해할 수 있고, 답으로 가는 길을 빠르게 찾아낼 수 있다. 새로운 것을 빠르게 익히고 배움에 대한 두려움이 없다.3) 지적겸손배움에 대해 열린 자세를 가지고 있어야 한다. 나는 개인적으로 주니어의 경우 이 능력을 "내갈굼력"이라고도 부른다. 다른 사람들에게 지적과 갈굼을 받으면서도 그것이 배움으로 이어진다면 감사한 마음으로 받아들인다. 감사한 마음은 다시 지식을 전해주는 사람에게 긍정적인 피드백이 되어 더 많은 것을 알려주게 되는 선순환 구조를 만들어 간다.4) 태도긍정적이고 도전적인 태도를 갖추어야 한다. 자신의 인생을 발전적으로 개척해 나갈 태도. 그리고 자신을 둘러싼 환경에 감사하는 태도. 이 태도는 팀에도 많은 영향을 미친다.병훈님을 면접 볼 때의 나는 1) 만을 중요하게 생각했기에 병훈님을 떨어뜨려야 하나 하고 생각했다. 하지만 이제 와서 뒤돌아 보니 병훈님은 2), 3), 4)을 모두 갖추고 있는 인재였다. 아마 몇 년 뒤에는 1)도 충분히 갖추게 되리라.5. 어떻게 일했나?- 소병훈 이야기 9개월 동안 에잇퍼센트를 다니면서 항상 내 능력으로 조금 힘들지만 불가능하지 않을 만큼 업무가 들어왔다. 스프린트(2주) 단위로 업무를 나눠가지는데, 일방적으로 업무를 할당받지 않고 팀 회의로 업무를 나눠갖는다. 호성님이 업무를 강요하지도 않고 업무 일정도 각자가 정하지만, 모두가 보고 있다는 느낌과 '스스로를 과대평가하는 나' 때문에 매번 촉박한 일정에 시달리게 되었다. 그렇게 나는 손을 들고 해당 업무의 책임자가 된다. 초반에는(전문 개발할 때까지)는 아예 질문하지 않아서 혼자 끙끙 댔는데, 너무 안쓰러워 보였는지 옆에 앉은 연태님이 먼저 도와주셨다. 시간이 지나면서 길이 명확하게 보이지 않을 때는 시니어 개발자(대부분 연태님)에게 물어보면서 일을 진행했다. 어느 날 호성님이 에잇퍼센트처럼 '실패하면서 성장할 수 있는 환경'이 다른 회사에서는 없다고 말했었다. 생각해보니 내가 자유롭게 개발해도 테스트와 코드 리뷰를 거치면서 문제를 잡아낸다. 그러고도 버그가 생기면 실서버에서 디버깅해서 문제를 해결한다. 심적으로 매우 죄송한 마음이 들지만 추가적으로 다른 벌은 받지 않았다. 일을 시작하기 전부터 지레 겁먹을 필요는 없었다. 그 뒤로 길이 희미하더라도 우선 걸어가 봤다. 그러다가 도저히 길이 보이지 않을 때, 조언을 받는 방식으로 일을 진행했다. 시간이 더 오래 걸리면서 최종 결과물의 수준이 떨어지는 상황이 발생했지만, 코드 리뷰를 받으며 최소한의 수준은 맞춰졌다. (그러면서 시간은 더 오래 걸린다.) 최대한으로 생각해서 만들어도 항상 놓치는 부분이나 더 간단한 해결 방법이 있었고, 그때 느끼는 아쉬움과 안타까움이 다음 개발할 때 잊지 않고 기억나서 내가 성장한다는 느낌이 들었다. 막바지에는 개발을 시작하기 전에 항상 의자를 들고 해당 업무를 요청한 사람 옆으로 갔다. 말로 이야기면 Slack이나 Trello로 이야기하는 것보다 빠르고, 해당 문제를 직접 보면서 자세한 설명도 들을 수 있었다. 요청사항을 받아 개발하는 느낌이 아니고 함께 문제를 해결한다는 느낌으로 이야기하면서 실시간으로 여러 해결방안을 제시하면서 생각을 주고받았다. 문제를 해결하면서 회사에 장기적으로 도움이 되는 방향을 고민하다 보니 '주인의식을 가지고 일한다'는 느낌이 들었다. (정확히는 이왕 만드는 거 아름답게 만든다는 생각이었다.)- 이호성 이야기회사에서 병훈님의 별명은 '아기새'였다. 업무를 하면서도 사람들의 보살핌을 필요로 했지만 그것 외에도 이런저런 허술한 면을 많이 보여줘서 누가 붙였는지 기억이 나진 않지만 모두의 입에 착 붙어 있는 별명이었다. (개발팀 내에서는 간혹 '아. 이런. 손이 많이 가는 친구'로 불리기도 했다.)에잇퍼센트에는 퇴사하면 털린다. 다들 떠나지 마라.병훈님을 연태님 옆자리에 앉게 했다. 회사 내에서 스위퍼(스프린트 내의 개발 잡일들을 처리하는 담당) 팀도 연태님과 같이할 수 있도록 했다. 경험과 인내심이 많고 상냥한 언니 같은 연태님(남자)은 병훈님의 좋은 파트너가 되어 주었다. 그리고 세바님은 어려운 문제를 함께 해결해 주고 코드의 퀄리티에 대한 감시자(갈굼자)가 되어 주었다. 언젠가 병훈님이 개발자의 길을 가게 되어 첫 월급을 받게 되면 이 두 분에게는 빨간 내복을 사드려야 할 거다.처음에는 아기새의 Pull Request(반영하고자 하는 코드 뭉치)에는 코멘트가 수십 개가 달렸다. 그것들을 꾸역꾸역 고치고 나면 다시 그 절반 정도의 코멘트가 달리곤 했다. 하지만 병훈님이 떠날 때쯤에는 내 코드에 "이렇게 저렇게 고치는 게 더 좋은 것 같은데요?"라고 코멘트를 달곤 했으니 발전하지 못한 나는 부끄러울 따름이다.그리고 병훈님은 다른 팀일에도 참 관심이 많았다. 그러고 보면 나도 처음에 스타트업에서 일하기 시작했을 때 다른팀 일들도 왜 그렇게 재미있었는지 모르겠다. 하지만 분명한 것은 작은 조직에서는 다른 팀에 대한 관심이 개발을 잘하는 데 많은 도움이 된다.6. 떠나기 이주일 전- 소병훈 이야기정해졌던 퇴사일이 가까워지면서 새로운 업무는 들어오지 않았다. To-do list는 사라지고, 대신 '인수인계'라는 일이 생겨났다. 지금까지 했던 일들을 문서로 남기면서 새로운 책임자에게 넘겨주는 일이었다. 큰 그림을 그렸던 것들이 있는데 완성을 하지 못한다는 아쉬움이 컸다.호성님께 1,2월 프리랜서 제안서를 받게 된 건 우연이였다. 다 같이 점심을 먹을 때 우연히 호성님과 같은 테이블에 있었고, 1,2월에 남은 일정을 이야기하다 농담처럼 나온 제안이었다.제안서를 받은 날, 기숙사에서 많은 계산을 했다. 개발하는데 어느 정도 시간이 걸릴지, 제안서의 업무 기한을 변경한다면 일정이 어떻게 될지, 그렇게 받은 돈으로 어느 정도 도움이 될지. 충분히 가능한 일정이었다. 못해서 아쉬워하던 일이기도 했다. 그렇기에 더 고민했다.긍정적으로 고민하던 제안을 거절한 이유는 '여행 도중에도 계속 개발을 생각할까 걱정되어서'였다. 이번 여행에서 아쉬움이 남으면 다음은 언제가 될지 모른다는 생각이 들자, 내 시간이 더 귀하다는 생각이 들었다.그러면서 내가 조금이라도 더 필요하다고 말해주는 점이 고마웠다. 내가 생각해보지 못한 선택지를 받아서, 나의 가치관을 되짚어 본 느낌이었다.- 이호성 이야기병훈님과 같이 식사를 했다. 병훈님은 복학하기 전 유럽으로 여행을 다녀온다고 했다. 밤에 돌아다니면 위험하니까 숙소에서 코딩이나 하라고 살살 꼬셨다. 밤에 코딩하고 그 아르바이트비로 낮에 럭셔리하게 맛있는 것 먹고 다니면 얼마나 즐거운 여행이 되겠냐고. 제안서를 하나 작성해서 해야 할 일과 보수를 적어서 병훈님께 주었다. 왠지 넘어올 것만 같은 느낌이었다.병훈님이 하루 정도 생각해 보더니 "어정쩡한 상태가 될 것 같아요. 생각해보니 이런 제안을 주신 것만으로도 정말 감사합니다."라고 했다. 실패했다.회사 입장에서 업무를 잘 알고 있는 병훈님이 조금이라도 일을 더 해주면 하는 마음이었다. 하지만 다시 생각해보니 인생의 후배에게는 좋지 않은 권유였던 것 같다. 돈이 중요할 때가 아니라 세상에 대한 경험과 자신을 뒤돌아 볼 시간이 필요했던 거니깐.7. 떠나는 날케익이나 먹고 떠나랏!- 소병훈 이야기떠나는 날도 크게 다르지 않았다. 코드도 살펴보고 pull request도 적으면서 이전과 같은 하루를 보냈다. 그리고 마지막 날, 혹시 작별 인사를 하면서 내가 울지 않을까 걱정했지만 괜한 걱정이었다. 2달 전부터 작별 인사(라 쓰고 갈굼이라 읽는다)를 받아서 그런지 마지막 인사가 특별한 느낌이 들지 않았다.그렇지만 그 뒤로 며칠간 회사를 나왔다는 묘한 홀가분함과 그동안 했던 일들이 내 손을 떠난 공허함이 있었다. 내가 없으면 회사가 바뀌지 않을까 하는 조그만 기대도 있었지만, 다들 나 없이 잘 지내나 보다. 나는 조금 아쉬웠는데.- 이호성 이야기9개월이라는 시간이 참 금방 지났다. 남은 기간 동안 여행을 떠나는 병훈님에게 사람들이 "에이 그거 여행 가면 뭐해. 그냥 회사에서 일해"와 같은 장난을 수도 없이 했던 것 같다. 하지만 떠날 시간은 정해져 있었고 병훈님은 사람들의 박수를 받으며 떠났다. 마치 80분을 열심히 뛴 축구선수가 교체를 위해 떠날 때 받는 박수처럼.8. 떠나고 난 후- 이호성 이야기며칠 간은 아침 데일리 미팅이 왠지 허전하고, 슬랙으로 말을 걸면 대답을 할 것만 같았다. 하지만 또 새로운 사람이 회사에 들어오고 바쁘게 회사가 돌아가면서 금방 잊혀지긴 하더라. 아 그러고 보니 병훈님이 만든 코드에서 버그가 나올 때마다 우리는 회사에 남은 아기새 인형을 괴롭히긴 했다.병훈님이 떠나고 나서 같은 학교의 후배인 선희님이 회사에 마케팅 인턴으로 들어왔다. 선희님이 자기소개 시간에병훈 선배와 같은 동아리에..라고 말하자마자 전 직원이 다 뒤집어졌다. 그렇다. 우리에게 "병훈"과 "선배"는 함께할 수 없는 단어였다.여행을 갔다가 돌아온 아기새 병훈님이 와인을 하나 물어왔다. 그리고는 파닥파닥.군대 문제가 있기에 당분간 병훈님과 함께 오래 일할 수 있는 기회는 찾아오지 않을 것 같다. 아쉬운 마음이 든다. 에잇퍼센트에서의 병훈님을 "막 알에서 깨어나 호기심을 가지고 세상을 바라보는 아기새"로 기억해야겠다. 그리고 그 모습을 기억하며 나 또한 초심을 되새겨야지.우리가 다시 만날 그날까지 병훈님이 더 큰 날갯짓으로 더 넓은 세상을 여행하길 바란다. 9개월간 함께 해준 병훈님께 감사한다. 안녕!덧, 그나저나 난 또 어디에서 찾아야 하나. 이 다음 아기새를.#8퍼센트 #에잇퍼센트 #인턴 #조직문화 #후기 #팀워크 #팀플레이
조회수 598

창의적인 개인 혼자서는 창의성을 발휘할 수 없다

창의성을 발휘하는 일은 매우 어려운 일이다의무교육 기간을 포함해 우리가 받는 교육은 새로운 생각을 좀처럼 허용하지 않는다. 기존의 지식을 익히는 것에 집중되어 있기 때문이다. 우리도 모르는 사이에 새로운 생각은 '오답'처리되고, 우리는 다름이 아닌 틀림의 두려움에 길들여진다. 누구도 그 오답에 대해 진지하게 고민하지도 않는다. 또 다시 들어와야 할 지식들이 기다리고 있기 때문이다.남과 다른 생각은 오답 처리로 인식우리네 교육이 창의성 발휘에 바람직하지 않다고 하더라도 얼마든지 창의력을 가진 사람들은 존재한다. 단언컨대 생각보다 많을 것이다.문제는 이들이 아무리 창의적이라고 하더라도 개인의 역량 차원을 벗어나기가 매우 어렵다는 것이다. 혼자서는 얼마든지 상상할 수 있지만, 이것이 세상에 드러나는 과정은 꽤 많은 난관을 극복하는 순간들의 연속이기 때문이다.혼자서는 얼마든지 창의적일 수 있다.자기 혼자서는.창의력을 특히 중시하는 예술, 광고, 디자인 등의 분야에는 창의성을 겨루는 국내외 공모전이 많다. 특히 디자인 전공 학생들의 경우에는 국내를 비롯해 세계적인 공모전에 뛰어난 성과를 내는 경우를 심심치않게 본다. 그 뛰어난 아이디어를 가진 친구들은 지금 어디에 있을까?공모전이 창의성을 전적으로 보증하지 않는다고 하더라도 우리 주변에 남과 다른 생각을 가지고 젊음을 불살랐던 친구들이 한 두명씩 있었을 것이다. 독특하다고 여겼던 그들 말이다.도전과 열정으로 의욕에 넘치던 눈빛을 가지고 어렵게 입사한 신입사원들이 채 6개월도 되지 않은 시간동안 축 늘어진 어깨와 흐릿한 눈동자를 갖게 되는건 무엇 때문일까? 창의적인 신입사원이 부서에서 일찍이 성과를 낸 적을 본 적이 있는가? 그럴거라고 기대했던 신입들이 어느 순간 순응적인 인간으로 변하게 된 모습을 종종 보게 된다.그들의 책임이 아니다.조직이 창의성을 수용할 수 있는 환경이 아니기 때문이다.신입이 뭘 알아? 이거 먼저 처리해~조직 전체가 창의적이지 못하면 창의적인 소수는 어느새 부적응자가 되거나, 괴짜로 낙인 찍히게 된다. 창의를 발휘할 터전이 안되는 것이다. 낙인 찍히지 않기 위해서 창의성을 스스로 죽이기 시작한다. 그렇게 적응해간다.그 밖에도 창의성을 죽이는 요인은 도처에 깔려 있다.이런 경우에도 해당한다.새로운 아이디어가 필요한 일을 위해 여럿이 모여 종종 브레인스토밍을 하는 경우가 있다. 1시간 정도는 꽤 활발히 아이디어를 쏟아 내다가 시간이 지나면 사람들은 점점 지쳐간다. 더 이상 새로운 생각을 짜내기도 어려워지고, 나와 생각이 다르거나 수준이 다른 의견에 대해 슬슬 반감과 피로감이 올라오기 시작한다.대부분의 브레인스토밍은 보잘 것 없어 보이는 아이디어들과 얼토당토 않는 생각들의 나열처럼 취급된다. 쓸만한 아이디어를 위해 2차 3차 아이디어 회의를 진행 하지만, 시간이 지날 수록 머리는 먹먹해진다.하지만 함정은 여기에 있다.얼토당토 않은 아이디어나 보잘 것 없이 보이는 생각 중에 숨어있는 기발한 발상들이 쉽게 무시되고 버려지는 것이다. 쓸만한 아이디어는 아마도 가장 최초의 순간에 나올지도 모른다. 왜냐하면 창의적 일수록  타인에게 쉽게 공감을 얻기 어렵기 때문이다. 그래서 쉽게 사라진다.창의적 생각은 쉽게 공감되지 않는다.줄을 서서 기다리지  않아도 결제가 되는 상점, 자신의 빈 방이 타인의 숙소가 될 수 있다는 발상, 쏘아올린 로켓을 다시 땅으로 소환하여 재활용할 수 있다는 생각... 이 아이디어를 우리 옆 대리, 과장이 기획서로 보고하고 설득할 수 있다고 생각하는 사람은 많지 않을 것이다.창의적인 생각은 우리가 당연하게 받아들여지는 전제를 비틀었을 때 가능하다. 하지만 당연한 전제를 뒤틀어 본다는 것은 우리가 정답이라고 생각했던 것을 부정해야 한다. 때문에 오답도 정답이 될 수도 있다는 오픈 마인드와 틀려도 괜찮다는 암묵적 합의가  있어야 당연한 것을 의심하는 것이 가능해진다.이것은 엄청난 에너지가 필요한 일이다.Bottom up으로 창의적인 아이디어가 구체화되기 어려운 이유다. 이러한 경험은 우리가 늘상 겪는 일들일 것이다. 아이디어가 빈약해서가 아니라 공감시킬 수 있는 에너지가 부족하기 때문이다. 반대로 위에서 부터의 혁신은 상대적으로 수월하다. 그 만한 에너지를 이미 가지고 있기 때문이다.문제는 창의적인 보스를 만나기가 어렵다는 것이다.한 때 스티브잡스 같은 인재를 국가적으로 키워야 한다는 웃픈 얘기가 있었다. 그런 기업이 탄생하지 못하는 이유를 직원 탓으로 돌리기 때문이다. 아무리 '스티브잡스'같은 신입사원을 대거 양성하여 모든 기업에 한 명씩 할당한다 하더라도, 그 회사들이 혁신 기업으로 성장하기는 커녕, 몇 명이나 그 직장에서 살아남을지 예상해보는 것은 어렵지 않을 것이다. 우리 조직에는 스티브잡스가 없는 것이 아니라 새로운 생각을 포용할 중간층과 환경, 그리고 새시대를 이끌 경영진이 부족하기 때문이다. 창의적인 개인이 아니라 창의적 조직이 필요하다혁신이 늘 부족한 기업의 대표나 오너라면, 직원들에게 혁신을 가져오라고 요구하기 전에 자신이 얼마나 창의적 생각을 무시하고 고사시켰는지 먼저 반성해야 할 것이다. 그건 직원들의 탓이 아닐 가능성이 높다.민주주의가 소수의 민주적 시민 의식만으로 구현되지 않듯이, 창의적인 조직은 소수의 천재가 만들어내는 것이 아니다. 탄탄한 미드필더와 미래를 읽을 수 있는 감독이 동시에 필요하다.그 동안 인정받던 많은 직업들이 앞으로는 기술과 인공지능에 자리를 내어줄 가능성이 아주 높다. 우리가 무엇을 준비해야 할지는 분명하다.알파고랑 싸워서 이기려면,적어도 창의성은 갖춰야 할 것 아닌가?

기업문화 엿볼 때, 더팀스

로그인

/