hoon

about my reading & writing. get in touch @twitter

[jihoonkimux]

앞으로 남은 인생을 살아가면서 함께 작업하는 일에 관대해져라. 다른 사람과 그들의 아이디어가 내 것보다 나은경우가 종종 있다. 당신에게 영감을주고 도전의식을 불어넣을 사람을 찾고, 그 사람과 함께 시간을 자주 보내다 보면 당신의 삶도 변할 것이다.

에이미 포엘러

[jihoonkimux]

오래전 재미있는 기사를 읽었는데, 기업들이 원하는 인재를 영입하는데에 어려움을 겪고 있다는 내용이었다. 기업이 인지하고 있는 기술적 부족분을 채워줄 수있는 인재를 ‘수급'하기 힘들다는게 기업의 입장이다. 디자인 인력시장만 들여다 봐도, 기업이 원하는 기술을 보유한, '적당한’ 인재를 채용하는것도 결코 쉽지가 않다. 기업이 원하는 기술은 시장 변화에 따라 빠르게 변화하지만, 디자이너의 스킬은 빠르게 습득하기가 힘들기 때문이다.

인터페이스 디자인 분야를 예로 들어보자. 흔히 유니콘으로 불리는 '여러 방면에서 특출난 스킬을 보유한 인재'는 언제나 공급이 모자라다. 하지만 그들은 분명 존재한다. 왜 그들은 그렇게 드문것일까.

일반화 하기는 힘들지만, 이렇게 괜찮은 인력의 공급이 줄어드는 원인으로는 인력시장의 양극화와 가장 큰 연관이 있다고 본다. 디자인 분야에서의 양극화는 이미 상당히 진행되고 있다. 실질적으로는 업무적 / 비용적 양극화로 나뉜다. 대부분 비용적(연봉) 의 양극화가 인력 공급과 연관이있다고 생각하겠지만, 사실 업무적 양극화가 이 현상의 원인이라고 본다. 그리고 여기에 '좋은’ 경험을 쌓아 성장할 수 있는 기회가 한정되어있다는 불편한 진실이 존재한다.

일단 취업시장 상황을 보면, 국내 디자인 분야 전공 (멀티미디어, 웹, UX)대학의 졸업생 수를 따져봤을 때, 대기업에 입사하는 수는 정말 극소수다. (물론 대기업에 들어간 인원들이 전부 커리어에 도움이 되는 '좋은’ 경험을 쌓을 수는 없다. 이것 또한 케바케.. ) 그럼 나머지는? 중소 / 벤처(스타트업, 게임) 기업, 디자인 에이전시, 기타 기업의 인하우스 디자이너로 들어간다.

입사 후 디자이너가 가질 수 있는 커리어에대한 가능성 순으로 나열해 보자.

마지막 기타 기업에 취직한 디자이너를 보자. 그들의 업무는 매우 다양하다. 리플렛 포스터 이메일 디자인 등. 주로 시각적인 작업물을 만든다. 일년간은 재밌을 수도 있겠다. 하지만 2년, 3년이 지난다면 이직이 하고 싶어진다. 하지만 마땅히 갈 곳이 없다. 이미 회사의 업무에 길들여져 다른 생각을 하기가 힘들다.

에이전시는 조금 낫다. 삼성이나 엘지 등의 굵직한 돈줄들과 연간 계약을 맺은 업체라면, 마켓에서 인기있는 선행 프로젝트들을 경험해볼 기회를 '운좋게’ 챙길수도 있다. 그렇게 4-5년 이상 열심히 한다면 팀장까지 달수도 있다. 축하한다. 이제 대기업에 경력직으로 찔러볼수라도 있겠다.

중소/벤쳐기업은 상황이 비슷하지만, 더 안좋은 케이스가 발생할 수 있다. 사업모델이 안정적이라 새로운 시도를 안하는 경우이다. 이런 케이스는 돈은 괜찮게 받을순있어도, 처리하는 업무의 범위는 매우 좁다. 요새 유행하는 웹이나 앱서비스를 만드는 기업이 아니라면, 이직은 힘들어진다. 더구나 경험없는 신입이라면, 자기가 정말 이 악물고 배우려하지 않는다면 에이전시를 다니는 것 보다 못한 상황이 올수도 있겠다.

이제 대기업이다. 보통 삼전이나 엘전에 입사하는 경우가 많다. ( 가장 많이 뽑는다..) 현대나 에스케이 같은 경우도 있지만 산업분야특성이 있어 인력을 많이 뽑지는 않는다. 이 경우의 진로는 크게 차이나지 않는다. 그냥 평생직장이라고 생각하고 다니거나, 그게 아니라면 경력을 쌓고 나서 벤쳐(또는 에이전시) 를 차리거나 유학을 가는경우가 있다.

확률 상 대기업을 첫 기업으로 가는 것이 제일 좋아보인다. 하지만 이 역시, 입사경쟁에서 살아남은 인재가 유니콘디자이너로 성장할 수 있는 확률이 더 많은 것이지, 입사자체가 성장을 보장해 주지는 않는다.

개인의 역량과 목적의식이 디자이너로서 성장할 환경을 찾게 해주고, 나아가 성장할 수 있는 기회를 가져다 줄 수 밖에 없는 것이다.

그럼, 어떻게 개인적 성장이 가능한 환경을 찾을 수 있을까? 물론 답은 정해져 있지 않다. 하지만 몇 가지 정도로 추려볼 순 있다.

1. 본인이 무엇을 잘하는가? 이 바닥은 개인의 역량이 모든것을 좌우한다. (또 그래야만 하고) 여러 업무 중 본인이 잘 하는 것을 찾고, 집중할 수 있어야 한다. 이런 측면에서는 신입시절 많은 것을 경험해보고 본인이 잘 하는 것을 찾는 것도 나쁘지 않다. 일단 이 질문에 답할 수 있다면 다음 질문으로 넘어갈 수 있겠다.

2. 본인이 어떤 업무를 원하는가? 본인이 하고 싶은 분야가 무엇인지 알아야한다. 1번에서 나왔던 답변과 다를 수 있지만 그것또한 괜찮다. 본인이 원하는 업무라면 좀 더 몰입할 수 있는 계기가 된다. 원하는 업무가 무엇인지, 또 그것을 감당할 수 있을지, 그게 아니라면 모자라는 역량은 어떤 것인지 측정하고, 모자라는 역량을 키울 계획을 세우라. 이것은 온전히 본인의 몫이다. 강의를 듣든, 조언을 구하든, 멘토를 구하든, 그 결과도 깨달음도 본인이 선택한 결과를 감당할 수 있어야 한다.

3. 본인이 왜 그것들을 원하는가? 다소 디자인과는 동떨어진 질문일 수 있겠지만, 디자이너도 어차피 피고용인일수밖에 없다는 점에서 매우 중요한 질문이 된다. 본인이 잘 하는 것을 알고 하고싶은 것을 알았다면, 이제 궁극적으로 왜 원하는지 알아야 한다. 회사에서 더 높은 직급을 다는것? 더 많은 돈을 버는 것? 여러분이 답해야 하는 건 이런 것들보다 더 고차원 적인 질문이다. 한마디로 이렇게해서까지 왜 원하는 것을 얻어야 하는가? 라는 질문이다. 그것을 진실로 원한다면, 이제 그 원하는 것을 얻기 위해 헌신하는 일만 남았다.

[radiofun]

디자이너의 3살 짜리 딸과 함께 구글을 사람처럼 만들기 (How A Designer's 3-Year-Old Daughter Is Humanizing Google)

Inspired by the way his daughter Anna Julia communicates, Hector Ouilhet is trying to make Google's voice search more human.

구글, 시리, 알렉사, 코타나, 누구에게 물어보아도 말문이 막히는 순간이 온다. 가끔은 보이스 커맨드를 잘못 입력했을 수도 있고, 아직은 할 수 없는 것을 시켰을 지도 모른다. 문제는 이것은 그냥 어느 쪽에건 “실패"라는 것이다. 

구글 검색 제품의 디자인 리드인 Hector Ouilhet은 이 문제의 대한 해답을 자신의 딸인 Anna Julia와의 대화에서 찾는다.  

중요하다고 생각한 내용만 요약한 글이니, 관심이 있으신 분은 링크를 따라가서 직접 확인해주세요.

구글은 왜 말을 하나

“우리는 3살짜리와 이야기를 하건, 90살 먹은 노인과 이야기를 하건 그들에 대한 일정한 기대가 있다” 달리 말하면 우리는 상대와 대화를 할 때 그 사람이 이전에 보여주었던 것에 기반하여 일정한 “능력”을 예상한다는 것이다. 

하지만 구글은 어떤가, 모든 것이 가능하거나, 아무것도 가능하지 않다. 수백만가지의 일을 처리할 수 있지만 어떻게 사용할 수 있는지는 모른다. 그렇다면 사용자는 구글만큼 크고, 파워풀한 대상과 어떻게 상호작용할 수 있을지 예상할 수 있을까?

Ouilet은 그 해답이 구글이 좀 더 사람처럼 행동하는 것에 있다고 믿는다. 이것은 단순히 구글을 의인화하거나, AI와 하는 것에 대한 문제만은 아니다. 오히려 “사람들이 머리를 감싸쥐고, 대체 내가 이야기하는 대상은 뭐지?”라고 고민하는 것을 돕는 일에 가깝다.

보이스 어시스턴트의 불협화음

음성으로 컴퓨터와 대화하는 것에 매달려있는 것은 구글만이 아니다. 애플은 시리, 마이크로소프트는 코타나가 있고, 아마존은 알렉사를 가지고 있다. 음성이 마이수 클릭이나 탭보다는 좀 더 자연스러운 방법이긴 하지만, 한편으로는 여러 문제들을 야기하기도 한다. 사람의 음성을 따라하지만, 사람처럼 행동하진 않기 때문이다.

아마존 에코와 이야기를 할 때를 상상해보면, 재즈를 플레이한다거나, 아이템을 아마존 위시리스트에 담는 일 같은 것은 잘 하지만 오븐을 끄라던가, 엄마에게 전화하라거나 하는 일은 불가능하다. 만약 잘 못들었거나, 커맨드가 예상한 대로 안온다면 마찬가지의 일이 벌어질 것이다. 사람과 다르게 컴퓨터는 애매한 상황에서 무력하기 때문이다.

결국 사람들은 가능한 몇가지의 커맨드에만 집중하고 다른 것은 시도조차 하지 않는다. 제품은 계속 진화하고 있는데도 말이다. 

왜 구글은 (아직) 3살짜리 아이보다 똑똑하지 못한가

Ouilet은 그의 딸 Anna Julia와의 관계에서 이 문제를 해결할 힌트를 찾는다. Anna Julia는 구글의 보이스 어시스턴트와 마찬가지로 아빠가 무슨 말을 하는지 잘 모를 때가 있다. 아빠가 말하고 있을 때 딴 생각을 해서 놓칠 때도 있다. 하지만 그녀가 반응하는 방법은 다른 “제품들"과는 많이 다르다.

저녁을 만드는 장면을 상상해보자. “테이블을 준비해(Set the table)”라는 말을 들었지만 고작 3살인 Anna Julia는 어떻게 해야 할 지를 모른다. 하지만 단순히 “몰라요"라고 말하는 대신 그녀는 그녀가 알아들은 몇 가지 단어를 가지고 아빠가 뭐라고 말한 지를 유추한다. 그리고는 이렇게 말할 지 모른다. “아빠, 식탁에 가서 앉으라고요?”

여기선 세 가지 정도에 주목할 필요가 있다. 1) 아빠의 말을 이해 가능한 단위로 쪼갤 수 있는 능력 2) 맥락을 이해한다는 점 - 저녁이 준비되고 있고, 아빠는 주로 식탁에 가서 앉으라는 말을 한다는 것을 알고 있다는 것 3) Anna Julia는 “준비해(set)”가 무슨 말인지는 정확하게 몰라서 그 말을 함과 동시에, 아빠를 실망시키고 싶지 않기 때문에 그녀가 해석한 최선의 안을 동시에 제안한다는 것이다.

결과적으로 Anna Julia는 아빠가 시킨 것을 수행하지는 못했더라도 아빠에 대한 멘탈 모델에 정보 하나를 추가할 수 있게 되었다. 다음에 테이블을 준비하라고 하면 아마도 그녀는 성공적으로 일을 수행할 수 있을 것이다. 또한 Ouilhet의 경우에도 딸을 독려하면 다음에는 결과를 얻을 수 있다는 것을 알았다. 이것은 단순히 하나의 과업을 수행하는 것에 그치지 않는다. 관계를 만들어가는 것이다.

구글을 안나 줄리아 처럼 만들기

음성 인식 기술 뿐 아니라, 구글은 사용자의 요구를 이해하는 능력도 좋아지고 있다. 지식 그래프(Knowledge Graph)는 검색어에 맞는 결과 이상의 것을 사용자에게 제공하고 있다. 구글 나우와 나우 온 탭은 맥락을 이해한다. 사용자에 대한 멘탈 모델을 만들어, 개개인에게 딱 맞는 결과를 제공하는 것이다. 개인정보 문제가 있긴 하지만, 구글은 사용자가 이전에 무엇을 했는지 점점 더 잘 이해하게 되고, 그래서 다음에는 더 나은 결과를 전달해 줄 수 있다.

Ouilhet은 음성 검색이나 “Zero UI”의 문제들은 기술적인 것이라기보다는 디자인적인 문제에 가깝다고 말한다. 만일 voice ux를 컴퓨터와 대화하는 느낌이 아닌, Anna Julia와 이야기하는 것처럼 바꿀 수 있다면 - 아빠를 기쁘게 해 주고, 배우고 싶어하고, 추측하는 것을 두려워 하지 않는 - 우리에 대해 더 알고싶어하고, 우리로 하여금 그들을 더 알고싶게 만들게 할 수 있다면 어떨까.

Ouilhet은 몇 년 안에 그런 일이 가능할 거라 생각한다. “사람들은 맥락에서 의미를 파악해내는 것을 참 잘하죠. 마치 양파 껍질을 까듯이 말이예요. 컴퓨터가 그 양파를 잘 깔 수 있게 되었을 때, 얼마나 강력해질 지 상상해 보세요.”

[jihoonkimux]

아직 갈길이 멀지만 얼마나 더 발전할지 기대가 된다.

[jihoonkimux]

디자이너의 몰락

-

실제 유저들이 사용하는 디지털 프로덕트를 만들어가면서 느끼는 것들 중 하나는 웹앱이든 모바일앱이든 전통적인 의미의 ‘프로토타입'은 존재의 가치를 상실해 가고 있다는 점이다. 스타트업 - 벤처 업계에서만, 특히 SaaS 스타트업에 국한된 상황일 수도 있겠지만 내가 몸담고 있는 환경에서는 프로토타입이 큰 의미를 가지지 않는다. 중요하지 않다는 의미가 아니다. 프로토타입이라는 산출물의 용도와 함의가 변하고 있기 때문이다.

먼저 프로토타입이란 단어의 의미를 짚어보면, 실제처럼 혹은 실제와 비슷하게 동작하는 인터랙션이 가능한 산출물을 의미한다. 한마디로 실제 제품의 모든 동작을 만드는데는 많은 비용과 리소스가 들어가니, 그 제품이 유용한지, 가설이 맞는지 실제 제품을 만드는 리소스를 투자하기 이전에 검증하기 위해서 ‘비교적 적은 (또는 값싼)’ 리소스를 투입하여 만드는 산출물이다.

하지만 고도화되고 복잡성이 높은 프로덕트를 디자인하게 되면 ‘프로토타입’ 이지만 요구되는 feasibility는 매우 높아지게 된다. 한마디로, 실제 만들게될 프로덕트와 최대한 유사한 (a.k.a 똑같은) 프로토타입을 제작해야 한다는 이야기다. (웹 같은 경우, 마크업과 스타일시트를 통해) 이는, 더이상 프로토타입이라는 단어의 개념이 이전에 의미하던 무게가 아니게 되어버렸다는 것이다.

웹앱 같은 경우(saas 같은 경우는 특히 그러한데 )디자인이 독립적인 팩터가 아닌, 실제 제품의 동작과 밀접하게 연계되기 때문에 비쥬얼 디자인을 함과 동시에 인터랙션을 같이 디자인하게 된다. 그리고 그것을 다른 부서 사람들과 공유하려면, 실제 동작하는 것과 똑같이 '동작'하는 최종 아웃풋과 동일한 사용자 경험을 줄 수 있는 프로토타입이 필요하게 되는 것이다.

결국 프로토타입은 실제 디자인이 반영되고, 실제와 똑같은 인터랙션을 제공하며 버려질 가능성을 전제로 한 중간 산출물이 되어간다. 불과 2-3년 전에 고수준 저수준 프로토타입이란 용어가 쓰여졌던 것을 생각하면, 요즘의 아이티업계의 변화가 정말 무섭기까지 하다.

개인적으로는 이런 변화가 거치고 나서, 이 변화에 적응한 디자이너와 그렇지 못한 디자이너들 사이의 전문성에 커다란 갭이 생길거라 예측하는데, 다음과 같은 이유에서이다.

1. 프로토타입 툴의 함정 먼저 시장에 쏟아져나오는 프로토타입 툴들을 보면 '개발지식없이도 실제처럼 동작하는 고수준의 프로토타입을 만들 수 있는 툴'이라는 키워드로 홍보한다. 개발자가 아닌 디자이너, 기획자를 위한 툴이다. 시장의 반응도 좋다. 더이상 개발자들에게 만들고 싶은 인터랙션을 만들어달라고 부탁하지 않아도 될 것 같다. 프로토타입툴로 만든 산출물을 가지고 놀고 있자니 세상을 다가진 것 같다. 잘 만든 프로토타입을 가지고 개발자에게 당당히 커뮤니케이션 할 수 있다. 오랜시간 공들여 만들수록 퀄리티는 좋아져 간다.

하지만 여기까지만 오게된다면, 디자이너로서 한 걸음 더 나아갈 수는 없다.

왜냐하면 이렇게 만든 프로토타입은 '실제 제품에 적용될 수 없는’ 프로토타입일 뿐이기 때문이다. 결국 이러한 프로토타입은 실제 개발이 고려되지 않고 동작하는 목업 정도이기 때문에 개발은 프로토타입처럼 '동작'하는 제품으로 만들기 위해 처음부터 다시 진행해야 하는게 현실이다. 또한 그렇게 만들어진 실제 제품은 프로토타입과 정확히 일치하지 않을 확률도 있다. 개발지식 없이 만들어낸 프로토타입은 만들어낸 인터랙션이 어떻게 동작할지, 상상으로만 생각했던 인터랙션이 실제 어떤 경험을 줄 수 있을지 대략적으로 파악하기 위해서만 사용될 수 있다.

이렇게 만든 프로토타입처럼 이상적인 상황을 실제 제품에 녹여내는 것은 대단한 수고로움이 투입되는 일이고, 그 책임이 개발자에게만 있다고 할 것인가? 비단 개발자의 몫만은 아니다. 필요하다면 과한 인터랙션 효과를 덜어낸다거나, 조정하는 의사결정도 요구된다.

프로덕트 팀이 정말 효율적으로 일하려면 결국 디자이너가 코드를 통해 (웹이든, 앱이든) 해당기능을 구현해 보고, 가능하다면 프로덕션 레벨의 코드를 작성해내어 개발자보다 먼저 기능의 적합성과 효용성을 판단하고, 그러한 근거를 바탕으로 커뮤니케이션을 하는 방향으로 리소스를 관리해나가야 한다. (실제로 옵티마이즐리나, 인터컴 같은 경우 ui engineer 포지션이 있어 이러한 역할을 수행한다.)

2. 디자이너의 유리천장 당신이 디자인업계에 몸담고 있고, 컨설팅 업계나 에이전시 (오로지 돈을 벌기 위해서만 존재하며 디자인 업계와 문화를 망치고 있는) 가 아니라 디지털 프로덕트 업계의 미래에 관심을 가지고 있다면 한 번쯤은 해외에 눈을 돌려봤을 것이다. 유망하고 잘나가는 디자이너, 아니면 유명한 직장에서 일하고 있는 디자이너들의 이력을 가만히 들여다 보면, 디자인 커리어만 가지고 있는 사람은 찾아보기 힘들다. 그렇다. 디지털 프로덕트 업계에서 두각을 드러내는 사람들은 엔지니어링 커리어에 대한 경험이 있다는 것을 알 수있다.

이유는 여러가지로 들 수 있겠지만 ..

결국 어떻게 동작해야 하는가? 에 대한 해결책을 제시하는 것 만큼, 그 해결책을 실제로 만들어 내는것이 중요하다는 이야기다. 출판 디자이너가 최종적으로 인쇄될 종이에 대해 모든것을 알아야 하는 것처럼, 디지털 프로덕트가 어떻게 동작하고 유기적인 연결성을 가져야 하는지, 프로덕트의 인터랙션들이 일관성을 유지하도록 만들어내는 것을 디자이너의 몫으로 가져가야만 한다.

이런 일들의 가치를 공감하지 못하고, 스크린 디자인과 프로토타입의 달콤함에 매몰되어 본인이 상상했던 것 과 다르게 나온 제품을 두고 개발자와 논쟁을 벌이는 디자이너들은 점점 설자리를 잃어갈 수 밖에 없다.

3. 해답은 소프트웨어에 있다 디지털 프로덕트 디자인이란 결국 디바이스에 종속된다. 역사적으로 다른 무엇인가에 종속된 산업군들은 오래 살아남지 못했다. 모바일, 웨어러블도 모두 그러한 유행의 흐름속의 일부분일 뿐이다. 그렇다면 디자인은 이제 소용 없는 것일까? 그렇지 않다. 어떤 형태로든 그 role은 유지될 것이다. 다만 그 업무들의 난이도에 따른 대우는 완전히 달라질 것이다. 정보 설계와 인터랙션 디자인, 비쥬얼 디자인으로 말이다. 얼마전에 읽었던 기사도 훌륭한 근거가 되어준다. 이제는 그래픽 디자인 학위로는 밥벌이를 하기가 힘든 것이 현실이다. 그래픽 디자인 학위를 가지고 많은 가치를 만들어 낼 수 있는 시대는 지났다. 부흥기에는 이같은 전문성이 환영받을 수 있었겠지만, 이제는 상황이 완전히 달라졌다.

애초에 디자인이란 직군을 선택한 이유가 아름다움이나 창작에 대한 몰입, 집착에 있었다면 현 시대의 상황은 받아들이기 힘든 것일 수 있겠다. 하지만 애석하게도 시대는 빠르게 움직이고 있고, 뒤쳐진 사람들을 추스려주지는 않는다.

결국 해답은 소프트웨어에 있다고 생각한다. 소프트웨어를 개발하는 개발자와, 디자인하는 디자이너의 업무적 무게감이 비슷해지는 상황이 올 것이다. (그러한 전문성을 갖춘 사람들에 한 해서) 그렇지만 그러한 역량을 갖춘 사람들이 얼마나 될 것인가? 미래의 상황은 지금보다 암울할 것이다. 시장에서 스타트업들은 기존 플레이어들이 제공하던 가치를 전혀 다른 방식으로 제공함으로써 파괴하고, 재구성하고 있다. 디자이너도 이 격변에서 자유로울 수 없다. 아마 많은 사람들이 저임금 노동에 시달리게 될지도 모른다. 하지만, 소프트웨어를 만들었던 경험과 역량이 있다면 앞으로 미래에서 조금은 더 오래 살아남을 수 있지 않을까. 10년후에는, 그 나름대로의 새로운 패러다임이 생길 것이므로.

[jihoonkimux]

자유로움에 대한 정신을 가장 잘 보여주는 데이빗 패커드의 연설문은 널리 알려지지 않았기에 이번에 소개해볼까 한다. HP창립자 패커드의 1960년 연설은 자유로운 방향과 권한을 분권화를 가장 잘 표현하는 연설문이다. 이 연설문에서 드러나는 HP적 조직 철학은 조직의 주요 인사들이 철저하게 희생 정신으로 무장하고, 스스로에게 엄격하고, 기업의 전체를 바라볼 수 있는 혜안을 갖추고 있을 때에만 성공적으로 구현될 수 있을 것이다.

이 연설문을 접한 지 꽤나 오랜 시간이 흘렀지만, 다시 봐도 참 명문이다 싶다. 저런 직업정신을 가지고 일하는 사람들이 있는 환경은 어디서 찾을 수 있을까? 아니, 존재하기는 할까? 

—– “그러나 우리는 가치있는 일을 하는 각자가 업무에 종사하는 것은 그 개인이 그 일을 가치있다고 느끼기 때문이란 단순한 사실을 명심해야 합니다. 돈만을 위하는 사람들은 어떤 기여도 만들어 내지 못한다는 것을 여러분은 알고 있습니다. 

 나는 사람들이 일하는 이유는 무언가에 대하여 기여를 하기 위함이라고 생각합니다. 즉, 각자가 진정한 목표를 갖추고, 그들이 이룩하고자 하는 것이 무엇인지 알때에, 그들의 능력의 전부를 발휘할 것입니다. 

 이것이야 말로 ‘관리에 의한 경영(Management By Control)’과는 다른 ‘목표에 의한 경영’(Management By Objective)’의 기본 철학인 것입니다. 우리의 목표는 무엇을 하는지 서로 이해하고, 자신이 가진 능력을 스스로 알아서 활용할 수 있을 사람들에 의하여 가장 잘 달성될 것입니다. 엔지니어링 분야에서, 우리가 최선을 다했다고판단하는 두 개의 핵심적인 기준이 있습니다. 

 첫 째는 디자인입니다. 우리가 새 계측기를 개발할 때 그 기계가 새로운 디자인을 갖추었다면 일을 할 때 그 계측기가 더 도움이 될 것입니다. 이것과 관련된 여러가지 예가 있습니다. 작년에 우리 엔지니어들이 개발했던 파동분석기, 클립식 밀리암페어계(전류측정기), 샘플링 스코프등은 정말로 새로운 디자인을 가졌습니다. 이 제품들은 기존 제품들로는 할 수 없었던 새로운 계측방법을 고객에게 제공하여 주었습니다.

 그러나 창의적 디자인 하나로는 충분하지 않고, 절대로 충분할 수도 없습니다. 이것들이 유용한 기기가 되기 위해서는 아주 세부적인 사소함 하나도 놓쳐서는 안됩니다. 엔지니어들은 이것을 이해하고 있습니다. 기계가 동작할 준비가 되었다면 일의 반정도 끝난겁니다. 제작과정에서도 마찬가지입니다. 우리는 우리의 슬로건인 ‘Inexpensive Quality’을 달성하기 위해서 제품을 효율적으로 생산해야하는 것은 물론 중요합니다. 비용은 생산에서 매우 중요한 부분이긴하지만, 모든 제품의 디테일이 제대로 되어있지 않는 한, 빠른 생산은 의미가 없습니다. 디테일에 집중하는 것은 생산이나 기술에 집중하는 것 만큼 중요합니다. 기기가 뭔가 헐거워진 부분이 있는채로 출고되었다면 고객에게 깊은 인상을 줄 수 없을 겁니다. 그 고객은 우리 조직을 신뢰하지 못할겁니다. 이런 결과에 대해서는 조직의 가장 위부터 가장 아래까지 변명할 수 없습니다. 

 당신이 관리직으로 위로 올라감에 따라, 당신 조직의 각자가 어떤것이 스스로에게 요구되는지 깨닫게 하고 그의 일을 꼼꼼하게 하는지 확인하는 것이 당신의 일이 될 것입니다. 회사의 첫번째 의무는 앞선 언급하였습니다. 바로 여러분이 의미있는 일을 하고 있다는 것을 스스로가 깨닫는 것입니다. 우리는 직원들의 일이 의미있다는 사실을 알려주어야 합니다. 관리자로서, 여러분은 여러분의 팀에 이 사실을 반드시 전달해 주십시오. 그들에게 지시를 내리지 마십시오. 여러분들의 사람들에게 기회를 주는 것은 중요합니다. 그들을 북돋아 주십시오. 관리자가 그의 팀의 일의 의미를 완전히 알고, 그 일에 대하여 완전히 깨닫는 것은 매우 중요합니다. 그리고 우리는 이것과 관련된 정책을 계속 개발해왔습니다. 수년간 이 때문에 경영자들 사이에서 논쟁이 있어 왔습니다. 몇몇은 여러분이 여러분이 관리해야할 일에 대한 이해 없이도, 기술적인 방법으로 모든 것을 잘 해낼 수 있다고 이야기했습니다. 실제로 이러한 방식으로 돌아가는 많은 조직들이 있습니다. 나는 그런 방식으로는 일을 할 수 없다고 말하는 것이 아닙니다. 내가 강력하게 말하는 것은 팀의 리더들이 그의 팀의 일에 아주 깊은 진정한 이해를 하고 있을때, 그 팀은 최고가 될 수 있다는 사실입니다.”

[jihoonkimux]

6개월간의 웹 프로덕트 디자인

어느새 새 회사로 이직한 지 반년이 흘렀다. 아직 많은 것을 이루기엔 짧은 시간이라 생각되지만, 앞으로도 더 많은 배움과 성장을 이룰 수 있길 기대하며 그 동안의 업무에 대해 기록 해본다.

1. 실제 웹앱 프로덕트에 들어가는 마크업은 신경쓸게 정말많다.

 먼저 각기 다른 브라우저에 대응하는 점이 무척이나 시간을 잡아먹는다. 파폭과 사파리, 크롬만 잡는데도 언제나 오류는 발생하더라.

 그렇지만 디자이너가 마크업을 만드는 방식의 장점은 디자인사이드에서 최종 아웃풋의 형태를 구현되기 전에 미리 그려보고 디자인 오류를 미리 잡을 수 있고, 디테일한 인터랙션과 스타일을 만들어낼 수 있다. 단점은 익숙해지기까지 시간이 걸리고, 구현에 초점을 맞춘 디자인을 하기가 쉽다는 것.

2. 디자인에 움직임 주는 것은 아름다움과 프로덕트의 속도 사이의 트레이드 오프.

 소프트웨어란 기본적으로 기능이 잘 동작해야하는 것이 필수다. 소프트웨어 인터페이스 디자인도 그 범주에서 크게 벗어나지 않는다. 따라서 막연히 이쁜 애니메이션을 넣는다거나, 속도에 부담을 주면서까지 화려한 것은 지양해야하는 경우가 많다. 또 그래야만 하고. 그뿐인가, 트랜지션을 어느 속성만 줄 지, 가속도를 어떻게 어떤 딜레이와 타이밍을 줄 것인지도 고민하는 괴롭고도 재밌는 시간들이 있다. 소프트웨어의 인터페이스는 오로지 효율성만을 최고 가치로 꼽기에, 디자인을 하는 사람으로서는 많은 제약에 실망할 수 있지만 넣으려 하는 효과가 왜 필요한지에 대해 고민을 하고, 설득하는 과정을 거쳐 프로덕트에 적용되면 훨씬 뿌듯할 때가 많다. 디자인은 결국 커뮤니케이션 그 자체이기 때문이다. 

3. not typography,  it's all about information.

 레이블 = 정보. 텍스트의 배치나 크기 등이 그 자체로 인터페이스가 된다. 전통적인 웹사이트와 소프트웨어가 다른점 중 한가지는, 소프트웨어가 다루는 정보의 양이 훨씬 많고 방대하다는 점에서 큰 차이가 있다. 때문에 디자인할때 가장 신경써야하는 부분이 정보 설계이고, 정보의 무게에따른 분류 등이 가장 신경써서 작업해야하는 부분이다.

설계가 잘못되었는데, 그것을 해결하는 방법이 비주얼 디자인이 되어서는 안된다. 잘못된 설계는 설계 단계에서 오류를 수정해야만 한다.

4. 다양한 사이즈에 대응하기.

 굳이 모바일과 데스크탑을 나누지 않더라도, 우리는 매순간 다양한 사이즈의 디바이스를 접한다. 이것은 한 시대의 흐름인 것이다. 이러한 다양한 사이즈와 인풋에서 살아남을 수있으려면 여러 상황에 맞게 확장가능한 디자인이 필요하다.

아토믹 디자인이라는 용어로도 사용되는데, 요는 각 컴포넌트를 정의하고, 그 컴포넌트가 모아져서 구성되는 형태를 정의하는 단계로 확장하여 디자인의 일관성을 유지하도록 하는것이다.

이것은 작업 초기부터 고려되어야하며, 디자인 언어와 패턴을 만드는 것 또한 도움이 된다.

5. 작은 것을 먼저 개선하기.

 보통의 리디자인 작업들이라고 하면, 기존의 것을 혁신적으로 바꾼다거나, 완전히 제로베이스에서부터 새로운 것을 만든 이상적인 작업물들을 떠올리기 쉽다. 하지만 현실에서는 그럴 수 없고, 또 그래서도 안된다. 흔히 스타트업이라고 해서 본인이 하고싶은 디자인을 마음껏 펼치고 싶은 환상에 부풀어 오는 사람들이 많은데, 이미 많은 사용자들이 사용중인 프로덕트라면 그럴 수 없다. 디자이너가 보기에 만족스럽지 않은 인터페이스 일지라도 쉽게 갈아엎을 수 가 없는 것이 현실이다. 따라서, 디자인 개선은 작은 부분 부터 점진적으로 개선해 나가야 한다.

팀에 합류 후에 개선했던 부분들은 매우 작은 요소였다. 드롭다운 리스트, 셀렉트 박스 버튼, 로딩 애니메이션, 프로그레스 바 등등.. 하지만 이런 작은 요소부터 개선하면, 다른 요소들간의 불균형이 생겨나게 되고, 그것은 곧 전체적인 인터페이스의 문제점에 대한 구성원들의 공감대를 얻을 수 있게 된다. 

[wonnyz]

왜 "애자일", 특히 스크럼이 끔찍한가.

이 글은 Michael O. Church의 ‘Why “Agile” and especially Scrum are terrible’을 글쓴이의 허락을 받고 번역한 글이다. 퍼가는 것은 보는 사람 맘대로지만, 가끔 번역이 마음에 안든다 싶은 부분은 수정될 수도 있다.

프로그래밍을 감염시킨 “애자일”의 유행을 내가 싫어하는 것은 비밀도 아닐 것이다. 그 중 최악의 종류인 스크럼은 악몽과도 같은데, 나는 이것이 실제로 기업을 살해하는 것을 본 적이 있다. 여기서 “살해”란 “나중에 보니 별로 좋지 않은 문화였다” 정도가 아니라, 기업 주가가 실제로 85% 이상 폭락했다는 것이다. 이 잡것은 유독하며, 예전에 없어졌어야 했다. 여기에 익숙하지 않은 사람들을 위해, 우선 용어를 정의하자. 그리고 왜 이것이 끔찍한지, 그리고 진짜 ‘민첩함’(agility)을 해치는지를 다룰 것이다. 그리고 “애자일” 개발이 실제로 유용한 하나의, 임시적인 사용 사례(use case)를 논할 것이며 그 사례를 통해 왜 이것이 “영구적 합의” (permanent arrangement) 만큼 유해한지 설명하겠다.

그래서 “애자일”이란 무엇인가?

“애자일” 유행은 웹 컨설팅 업계가 키웠는데, 그 업계에서는 어느 정도 가치가 있었다. 스스로 뭘 원하는지도 모르는 까다로운 고객을 다룰 때, 두 가지 정도의 선택지가 있다. 하나는 고객을 관리하는 것이다. 기대치를 설정하고, 수정 요청에 적절한 비용을 부과하고, 고객에게 굴종하지 않고 동등한 관계를 유지하는 것이다. 두번째는 고객의 진상짓을 감수하고 (그러니까.. 많은 그래픽 디자이너들이 그래야 하는 것처럼) 작업 방향을 고객 입장에서 문제라고 생각하는 것을 해결하는 쪽으로 맞추는 것이다. 프로그래머들은 - 고객을 관리하는 - 첫번째 선택지에 능숙하지 못하다. 그런 것을 잘 하려면 사회적 감각이 엄청 요구되는데다가, 두번째 선택지가 이제 막 승진했고, 실제 업무를 처리하지 않아도 되는 의사결정권자에게 매력적이기 때문이다.

“컨설팅”이라는 이름을 가진 업무의 범위는 매우 다양하다. 훌륭한 컨설팅 회사도 있고, 가장 질 낮은 업무를 떠맡는 곳도 있다. 기업은 컨설팅 회사에 두 가지 종류의 업무를 주곤 한다. 내부에서 일을 맡을 사람이 없는 최고 수준의 업무이거나, 그런 업무에 1년 정도 사람을 투입하면 사기가 박살나는 종류의 쓰레기같은 질 낮은 업무이다. 스크럼은 그런 질 낮은 업무를 처리하는 곳을 위한 것이다. 프로그래머를 쥐어짜고, 고객과의 관계를 제대로 관리하지 못하고 있으며, 아무도 하고 싶어하지 않고 경력이 꼬이는 저질 업무를 떠맡는 그런 곳 말이다.

자 그래서 스크럼과 “애자일”이란 무엇인가? 여러 종류의 미팅이나 (“회고”, “백로그 다듬기”, “계획”) 이론을 들 수 있겠으나, 핵심적인 공통 특성은 보통 일방적인 지독한 투명성 이다. 프로그래머는 대부분의 경우 자신의 업무 내용과 시간에 대한 굴욕적일 정도의 가시성을 제공해야 한다. 즉 실제 업무량에 더해서 생산성을 보여주는 일방적인 게임을 해야만 한다는 것이다. 사람을 신나게 하는 실질적인 장기 프로젝트에서 일하는 대신, 그들은 세분화된, 기능 단위의 “유저 스토리” 작업으로 격하되고, 단기간의 (보통 윗선에서 떨어지는) 사업적 요구와는 관련없는 개선사항을 처리하는 것은 허락되지 않는다. 애자일은 오너십이라는 개념을 없애버리고, 프로그래머를 교체 가능한 일반적인 부품처럼 다룬다.

사람을 어린애 취급하고 역겨운데다가, 스크럼은 개인의 생산성이 미세하게 요동치는 것에 대해 쓸데없는 걱정을 하게 만든다. 폭력적인 투명성이란, 이론적으로 사람의 매 시의 생산성 변동이 모두에게, 아무런 이유 없이 보이게 된다는 것이다. 이런 종류의 가짜 만병통치약이 실제로 일을 빠르게 끝내게 하거나 결국엔 더 낫게 한다는 아무런 증거가 없는데도. 평균 장기 생산성을 측정했을 때 괜찮은 성과를 내고 프라이버시 침해에 굉장히 민감하며, 불안증이나 감정 장애가 있는 사람들에게는 이것은 노골적인 차별이다.

“애자일"과 스크럼의 구체적인 결함

1. 사업부 주도의 엔지니어링

“애자일”은 종종 “폭포수(Waterfall)”라는 소프트웨어 설계 방법과 비교하여 팔리곤 한다. 둘 다 똑같이 끔찍한 허수아비다. 애자일과 폭포수 모델이 공유하는 것은 (그리고 둘 모두의 장애 원인) 사업부 주도의 개발이라는 것이다. 폭포수 모델에서 프로젝트는 회사 경영진이 처음 정의하고 중간 관리자와 아키텍트들이 설계하며, 그 다음에야 여러 층의 말단 노동자들이 구현과 운영 및 테스트를 수행하는데, 각 기능은 하나가 끝나야 다음을 진행할 수 있는 여러 단계를 거쳐서 구현한다. 폭포수 모델이 제대로 동작하지 않는 것은 악명 높고, 애자일 진영의 아무도 여기에 이의를 달지 않는다. 폭포수 모델에서 엔지니어들은 어떤 설계를 구현하는 역할로 격하되는데, 이 설계의 모든 중요한 결정은 이미 끝났고 되돌릴 수 없다. 따라서 재능 있는 엔지니어라면 그러한 프로젝트를 맡고 싶어하지 않는다.

폭포수 모델은 명확한 계급구조가 있는 문제 조직의 사회적 모형을 복제한다. 가장 흥미로운 업무를 먼저 진행하고 작업 완료가 선언된 다음, 지저분한 나머지는 아래 사람들에게 넘긴다. “폭포수”라고 불리는 까닭은 의사 소통이 단방향이기 때문이다. 설계에 잘못이 있더라도 반드시 구현되어야 한다. (아마도 설계한 사람들은 이미 다른 프로젝트로 넘어갔을 것이다) 그리고 애자일은, 문제 조직의 사회적 모형을 복제하는데, 명확한 계급구조를 빼고 복제한다. 이것은 꽤 명백하게 다른 모든 이의 아래에 엔지니어를 두는데, “프로젝트 소유자”와 “스크럼 마스터”는 “팀 구성원”보다 계급이 높고, “팀 구성원”은 하위 계층에서도 가장 낮은 위치에 있다. 이러면 시니어급의 능력있는 엔지니어에게 주니어를 위한 보고 구조를 (나눠준 티켓을 처리할 것, 상태 보고 회의에 주당 5-10시간씩 참가할 것) 충실히 따르도록 하여 그들의 자존감을 박탈하는 효과가 있다. 빈곤을 전파하여 모두를 동등하게 만드는 실패한 공산주의 국가처럼, 가장 순수한 형태의 스크럼은 모든 엔지니어링을 동일한 가장 낮은 계층에 둔다. 잘 설명하지는 않지만, 분명히 ‘무슨 일을 먼저 해야 하는가’에 대한 완전한 결정권을 쥐고 있는 사업부 조직의 밑으로.

“애자일”은 엔지니어에게 아무런 권력을 주지 않으면서 업무보고의 빈도를 늘린다. 이것은 손해인데, 일정이 필요한 만큼보다 늘어지는 것처럼 “보이면” 엔지니어들이 곤란해지거나 처벌받을 수 있기 때문이다. 이러한 결정은 언제나 사업부 사람들이 내리는데, 그들은 기술적 난제나 개발 업무의 특성에 대한 깊은 통찰 대신 그들의 감정에 기반하여 상황을 지휘할 것이다.

실리콘 밸리에서 특히 지난 5년간 잘못 생각한 것도 많지만, 제대로 하고 있는 것중 하나는 ‘엔지니어가 주도하는 회사'라는 개념이다. 엔지니어가 모든 회사를 이끄는 것이 항상 최선은 아니지만, 엔지니어가 엔지니어링을 주도하고 우선 순위를 세우면 모두가 승리한다. 엔지니어는 자신에게 할당된 일에 (스스로 정한 것이면 더 좋고) 만족하고, 사업부는 훨씬 질이 높은 결과물을 얻는다.

2. 주니어로 끝남

“애자일”은 주니어로 끝나는 (terminal juniority) 문화이며, 프로그래밍은 “젊은 남성들의 게임”이라는 (엄청 잘못된) 생각에 신빙성을 더해준다. 대부분의 최고급 엔지니어들은 그렇게 젊지도 않고, 일부는 남자도 아닌데 말이다. 애자일에는 출구 전략이 없다. “이걸 했으니 이제 더이상 이렇게 할 필요가 없다”는게 없다. “유저 스토리”와 사업부가 주도하는 엔지니어링과 끝없는 상태 미팅은 사라지지 않으며, 그 자리에 항상 남아있게 되어 있다. 구조 잡기(아키텍쳐), 연구 개발, 제품 개발은 프로그래머가 할 일이 아닌데, 그런 것은 세분화된 “유저 스토리” 또는 2주 단위 스프린트에 맞지 않기 때문이다. 따라서 프로그래머들이 한 분야의 기초를 익힌 다음에 맡고 싶어하는 그런 프로젝트는 무시되는데, 세분화할 수 없거나 세분화하는 것이 그냥 하는 것보다 훨씬 더 어렵기 때문이다.

스크럼 팀에 실제 시니어 엔지니어의 역할은 없는데, 문제는 스크럼을 도입한 많은 회사에서 보통 전사적으로 시행한다는 것이다. 관리직으로 넘어가는 것 말고는, “스크럼 마스터”가 되어 이것을 말단에 도입하는 책임을 지는 선택지가 있다. 권한이 없는, 헛소리에 불과한 가짜 관리직 말이다. 스크럼 팀을 떠나서 해로운 마이크로매니지먼트를 받으면서 살지 않으려면 괴물 안으로 깊숙히 파고들어서 다른 사람에게 유해한 마이크로매니지먼트를 강요하는 수 밖에 없다. “애자일”과 스크럼이 나에게 말하는 것은 시니어 프로그래머는 반드시 필요하지 않다고 여겨지므로, 무시해도 좋으며, 마치 프로그래밍이란 35세 이전에 접어야 하는 유치한 것이라고 하는 것 같았다. 나는 그런 사고방식에 동의하지 않는다. 사실 해롭다고 생각한다. 나는 30대 초반이 되어서야 이제 프로그래밍 좀 하는 것 같다고 느끼기 시작했다. 이런 “애자일”/스크럼 쓰레기가 컴퓨터 과학과 아무런 상관이 없고, 아무런 가치가 없다는 것을 알게 된 경험 많은 연장자들을 내쫓는 것은 끔찍한 생각이다.

3. 어리석고, 위험할 정도의 짧은 주기

애자일은 한계에 달한 컨설팅 회사들을 위해, 그들에 의해 만들어졌다. 즉, 고객과 동등한 위치에서 협상할 수 있는 신뢰도를 갖추지 못하였으므로 빠듯한 데드라인에 맞춰야 하고, 각 고객 프로젝트가 실존의 위기인 회사들을 위한 것이다. 그러니까 “헝그리한” 약자(underdog)들을 위한 것이다. 자 여기서 문제: 흔히 큰 회사, 또는 펀딩받은 스타트업에서도 스크럼을 사용한다. 그런데 (고용자가 가져가도록 금전적 조건이 적힌 서류를 남기고) 이런 회사에 입사하는 사람들은 패배자(underdog)가 되고 싶지 않아서 입사하는 것이다. 아무도 타당한 개인적 보상이 없다면 뒤치닥거리를(play from behind) 하고 싶어하지 않는다. 기업 업무에서 “애자일”이란 보상이 없는 고통과 위험을 말한다.

각 개별 프로젝트가 실존 문제이거나 심각한 평판 위험에 해당할 때, 애자일은 괜찮은 선택지일 수도 있다. 회사가 위기에 처했을 때 반복적인 단기 목표에 집중하는 것은 유용하며 오랫동안 지속되지는 않을 것이기 때문이다. 비상 시에 공격적인 프로젝트 관리는 이치에 맞다. 영구적인 합의로써는 적절하지 않다. 적어도 스트레스를 덜 받고 더 즐거운 선택지가 있는 인재들에게는 말이다.

애자일 하에서, 기술적 부채는 쌓이기만 하지 처리되지 않는다. 명령권을 가진 사업부서 사람들은 너무 늦거나, 고치려니 너무 비용이 많이 드는 지경에 처하기 전까지는 문제를 보지 못할 것이기 때문이다. 게다가, 엔지니어 개인은 오로지 2주 단위의 현재 “스프린트”를 완료했는가 하지 못했는가에 따라 보상을 받거나 처벌을 받으므로, 아무도 한 다섯번 뒤의 “스프린트”를 내다보지 않는다. 애자일은 단지 아무 생각없는 근시안적인 “스프린트”의 연속일 뿐이다. 진척도 없고, 개선도 없고, 단지 티켓에 티켓이 이어질 뿐이다.

4. “경력 일관성”을 전혀 고려하지 않는다

세분화된 유저 스토리는 엔지니어의 경력에 좋지 못하다. 사람들은 당신이 30세가 되기 전에 프로젝트 전체를 담당할 수 있다는 것을 보여주길 기대한다. 또한 적어도 기반 인프라, 구조(아키텍쳐), 연구 또는 리더십 등의 분야에서 어느 단계를 뛰어넘을 준비가 되었기를 바란다. 애자일/스크럼 경험은 주니어 일자리를 잡을 때는 어느 정도 도움이 되지만, 중간 정도나 시니어 엔지니어에게 적합한 일자리를 구할 가능성을 없애버린다.

비상시에, 그러니까 컨설팅 회사가 중요한 고객을 달래려고 안간힘을 쓰고 있든 기업의 “위기 상황실”(War Room) 상황이든, 경력 일관성은 잠시 유보할 수 있다. 자신이 일하고 있는 회사에게 정말 필요한 일이라면, 몇 주 동안 불쾌하거나 경력이 꼬이는 업무를 못하겠다고 거부하는 사람은 거의 없을 것이다. 최소한 그 작업의 중요성이 경력에서 인정된다. 그러나 비상 상황이 아닐 때는, 프로그래머들은 자신의 경력 증진을 중요하게 여겨주길 바라고, 그렇지 않으면 떠날 것이다. 모두가 싫어하고, 누구의 경력에도 가치가 없는 밑바닥 작업을 “잡일(Fish Frying)”이라고 하자. 비상시 또는 모두의 주목을 받아서 누구도 개의치 않는 “잡일”이라면 (조직 안팎으로) 경력에 충분한 가치가 된다. “나는 상황실에 있었고, CEO랑 하루에 20분씩 같이 있었다”고 하면 잡일은 정당화된다. 이것은 당신은 귀중하고 중요한 인재라는 뜻이다. 자 “나는 스크럼 팀에 있었다”는 어떨까, “나 좀 잘라줘”이다. “유저 스토리”를 할당 받았기 때문에 잡일을 처리했다는 것은 당신이 패배자로 보였다는 것을 알려준다.

5. 저성과자를 가려내는 것이 목적이지만, 잘못 판단할 가능성이 높아서 써먹을 수가 없다

스크럼을 팔아먹는 쪽에서는 “장애물을 없애는” 과정이라고 하는데, 이 말은 “게으름뱅이 가려내기”를 좀 부드럽게 말한 것이다. 문제는 뿌리뽑는 것보다 더 많은 저성과자를 만든다는 것이다. 이는 각 엔지니어들이 자신의 업무와 생산성 척도를 세밀하게 관찰할 수 있도록 제공해야 하는 감시 상태이다. 이를 “꺼리는게 없으면 숨길 것도 없다”는 식의 주장으로 무마하려고 하는데, 조직의 대들보에 해당하는 고성과자들에게도 감시 상태는 불안감을 주는 상태인 것이 사실이다. 누가 나를 관찰한다는 사실에 사람들은 일하는 방법을 바꾼다. 특히 창의성이 필요한 분야에서는 상황을 악화시킨다.

여기서 떠오르는 첫번째 주제는 지위 민감성 (status sensitivity)이다. 프로그래머들은 자신들이 사회적 지위에 대해 영장류의 수백만년 진화를 초월했다고 믿고 싶어한다. 그러나 사실은: 사회적 지위는 중요하다. 그 사실을 인정하기 전까지는 당신은 “정치적”일 수 없다. 나이든 사람들, 여성, 소수 민족과 장애인들은 자신들의 지위에 민감한데, 생존의 문제이기 때문이다. 누군가의 업무를 지속적으로 감시한다는 것은 그 사람을 신뢰하지 못하고 사회적 지위가 낮다는 것을 나타내며, 대부분의 “지위에 민감한” 사람들이 (그들이 최고의 직원이라고 해도) 제일 먼저 위축될 것이다. 반면 스크럼과 “애자일”은 “지위에 민감하지 않은” 사람들이 대부분인 집단을 위해 만들어졌다. 즉 시험이나 도전을 받아보지 못했거나 아직 업무에 치여보지 않은 (burned) 젊은 특권층 남성들을 위한 것이다. HR과 관리 업무는 시간낭비이며 이 사람들은 모욕을 당하거나 비하를 당해도 그저 알랑거려야 한다고 생각하는 그런 사람들 말이다.

애자일/스크럼이 소개되면 최고의 직원들이 제일 심하게 추락하곤 하는데, 연구 개발이 사실상 제거되었기 때문이고, 단기간의 “반복” 또는 스프린트에 대한 강박이라는 것은 실패할지도 모를 작업을 시도할 틈이 없다는 것이기 때문이다.

저성과자에 대한 진실은 그들이 누구인지 찾아내기 위해 “애자일”을 도입할 필요는 없다는 것이다. 사람들은 스스로를 안다. 어떤 팀이 한가하거나, 무능하거나, 유해한 사람들로 가득 차는 것은 그들에게 아무런 조치를 하지 않기 때문이다. 사람에 대한 관리 문제이지, 작업 흐름과 절차에 대한 문제가 아니다.

6. 주정뱅이 효과 (The Whisky Goggles Effect)

(주: 술에 취하면 앞에 있는 사람이 더 멋있어 보이게 된다는 뜻임)

애자일과 스크럼이 살짝 무능한 사람을 간당간당하게 쓸만한 사람으로 만든다는 증거가 일부 있는 것처럼 보인다. 나는 이것을 주정뱅이 효과라고 부르는데, 3점이나 4점짜리를 5점으로 바꾸지만, 당신을 너절하게 보이게 하여 7점이나 9점짜리 사람은 당신이 별볼일 없다고 여길 것이다. 공격적인 마이크로매니지먼트 환경에서 그들의 흘러넘치는 창의력을 짜내는 것은 불가능하고, 최고의 프로그래머들은 떠나게 된다.

'관리자는 소프트웨어가 어떻게 동작하는지 알지 못한다'는 관점에서 보면 이것은 해볼만한 거래로 보인다. 7점 이상의 “프리마돈나”들은 '멋진 스크럼'을 받아들이지 못하고 떠날테지만, 3점이나 4점짜리 직원들은 딱 아슬아슬한 5점짜리 직원이 된다. 문제는 7점짜리 프로그래머와 5점짜리 프로그래머의 차이는 5점과 3점짜리의 차이와 비교하면 꽤 크다는 점이다. 최고의 직원들과 (조직도 상의 관리직으로는 올라가지 않은) 리드들을 잃는다면, 무능력자들을 살짝 업그레이드할 수 있다는 스크럼의 장점은 아무런 쓸모가 없다.

스크럼과 애자일은 내가 '상황 이득 편향’ (Status Profit Bias) 이라 칭하는 것에 빠진다. 기본적으로 많은 사업부 사람들은 객관적으로 (in objective terms) 성공과 실패를 평가하는게 아니라, 성취한 상황 변화를 근거로 평가한다. “3"점 프로그래머의 시장 가치가 연 $50,000이라 하고, "5"점 프로그래머는 $80,000이라 하자. (실제 프로그래머 급여는 중구난방이다. 나는 3점짜리가 $200,000을 버는 사례도 알고, 7점이 $70,000 아래인 경우도 알고 있지만 무시하자) "5"점짜리 프로그래머에게 "3"점짜리의 급여를 주는 것을 납득시킨다면 심리적으로 와닿을 것이다. 겨우 $30,000 이득이 아니라 2점이나 이득이기 때문이다.

애자일/스크럼과 연령 차별 문화는 보통 실제 경제적 이득보다는 제일 인상적인 상황 이득을 얻는 방법에 대한 것이다. 젊은이들은 자신이 “실제로 대접 받아야 하는” 사회적 지위에 대해 거의 알지 못한다. 자신이 3점 정도라고 생각하는 22세 6점짜리를 찾아서 스크럼에 합류시킬 수 있겠지만, 50세 9점 프로그래머는 마지못해 8.5점 대우를 받아들일지도 모르지만 6점짜리 대접을 받으려고 하지는 않을 것이다. 그러나 상황 이득을 찾는 것은 매우 근시안적이다. 업계 전체적으로 5점 엔지니어를 데려와서 4점처럼 대접하려고 (급여도) 하겠지만, 현재 시장 상황에서는 8점 엔지니어를 데려와서 8점 대접을 해주는 것이 훨씬 이득이다.

7. 거짓으로 팔아먹고 있다

이 점을 다루기 전에, 나는 “스크럼”이라 알려진 특급 애자일 프로세스가 특정 상황 조건에서는 잘 작동한다는 점을 인정해야겠다. 거짓 약팔이들은 이것이 '영구적인 합의'처럼 모든 상황에 잘 맞는다고 말한다.

스크럼이 잘 맞는 경우

애자일이 유행하기 전에는 “스크럼”이란 말은 회사가 “적색 경보” 또는 “위기 상황”이라 부르는 상황에서 사용되곤 했다. 이것은 조직경계를 넘어 (cross-cutting) 대응팀을 빠르게 꾸려서 예상치 못한, 보통 빠르게 퍼져나가는 문제에 대처하는 것이다. 정해진 관리자를 두지는 않지만 리더를 (“스크럼 마스터”같은) 선출하고 권한을 부여하는데, 보통 공식적인 "관리직"이 아닌 사람이 제일 적합하다. (가능한 공정해야 하므로) 위기는 단기간이므로, 각 개인의 경력 목표는 잠깐 보류할 수 있다. 이것을 “전력질주”(sprint)라고 할 수 있는 까닭은 최대한 빠르게 일해서 문제를 해결해야 하기 때문이고, 상황이 종료된 다음에는 평상시의 작업으로 돌아갈 수 있기 때문이다.

두 가지 시나리오를 생각할 수 있다. 첫번째는 기업의 “위기 상황실”에 대한 것인데, 어떤 사람이 (경영진 말고) 1년에 6주 이상 '위기 상황'에 있었다면, 이것은 회사에 뭔가 문제가 있는 것이다. 위기가 그렇게 잦으면 안되기 때문이다. 두번째는 컨설팅 회사가 자리잡으려고 애쓰고 있는 상황이거나, 고객 관리나 독자적인 평판 구축에 실패하여 항시 비상 상황으로 운영해야 하는 경우이다.

두 가지 문제

스크럼과 애자일은 비상시에 리더를 "떠맡은” 사람에게, 빠르게 일을 처리하기 위해 그가 필요하다고 생각하는 모든 것을 할 수 있도록 우선 비상 지휘권을 부여해야 한다는 생각을 대변한다. 시시비비는 일단 나중에 따지더라도 말이다. 예로부터 비상 지휘권에 대한 문제는, 가끔 없어지지 않는다는 것이다. 대부분의 경우 지휘권을 가진 사람은 이것을 유지해야 한다고 생각한다. 그리고 틀림없이, 관리의 문제가 된다. 장애 상황, 비상 상황에는 평상시 잘 돌아가던 때보다 더 많은 경영상의 노력이 필요하다.

출세지향적인 선동가 (“스크럼 마스터”) 에게는 우선 마을에 드래곤이 꼬이지 않게 하는 것보다 “드래곤 슬레이어”가 되는 것이 더 멋져 보일 것이다. 스크럼의 사업부 주도 엔지니어링에 대한 공격적인 주장의 문제점은, (“요구사항”이라 하는) 용을 꾀어내어 처치하는 것을 (“고객의 협력”이라는) 미덕으로 삼는 것이다. 처음부터 동굴에서 용을 꾀어내지 않는 편이 더 사려깊었을 것이지만.

“애자일”과 스크럼은 비상시를 미화한다. 그게 첫 번째 문제이다. 그것은 비디오 게임 업계에서 “크런치”라고 하는 것의 재발명일 뿐이다. 지속 가능하지 않다. 공세적으로 개인의 성과에 집중하고, 업무 할당에서 개인의 경력 목표를 배제하고, 최우선 순위로 정해진 것만 작업하도록 강요하는 것은 단기간의 비상 상황에서나 가치가 있지, 장기간으로 보면 독이 된다. 사람들은 자신의 자율성을 돌려받게 될 명확한 목표가 눈앞에 있어야 그러한 변화를 감내할 것이다.

두 번째 문제는 이러한 사례가 거짓으로 팔리고 있다는 것이다. 회사들의 소프트웨어 개발 업무에 “애자일”을 도입하도록 교육하면서 성장한 가내 수공업 업계가 있다. 문제는 핵심 아이디어에 새로운 것이 없다는 것이다. 용어는 신선한데, 개념은 대부분 진부하고, 실패한 “과학적 관리법”이다. (과학적이지도 않았고, 잘 되지도 않았다)

“애자일”과 스크럼의 장단점이 모두 다뤄졌다면 나는 이러한 개념이 그렇게 문제라는 생각을 갖지 않았을 것이다. 주니어 개발자들 뿐인 회사에서 어떤 기능을 빠르게 제공해야 한다면, 이러한 기법을 잠시동안 사용해보고, 구성원들이 성장하고 납기일에 조금 여유가 생기면 이후에는 쓰지 않는 것을 생각해볼 수 있을 것이다. 그러나 스크럼이 '있는 그대로’ - 생산성 향상을 위해 긴급히 써볼 수 있는 몇 가지 방법이지만 영구적으로 쓸 수는 없는 - 팔렸다면 이런 방법론을 도입하는 고객은 훨씬 적었을 것이고, “애자일” 컨설팅 업계는 없었을 것이다. 이러한 기법에 대한 거짓 약팔이 수법으로만 (항시 수정(permanent fixes)으로 포장된 “크런치"에 대한 미화) 팔아먹을 수 있는 것이다.

앞으로의 기대

이제 대부분의 “애자일”, 특히나 스크럼은 없어져야 한다. 이들은 그냥 나쁜 생각이기만 한게 아니다. 한 세대의 소프트웨어 엔지니어들이 이보다 더 나은 것을 알지 못하고 받아들이고 있기 때문이다. 너무나 많은 젊은 프로그래머들이 사업부 주도 엔지니어링과 “유저 스토리”를 마땅히 따라야 하는 것으로 받아들이고, 단지 평범한 회사원이 되어버릴 운명이다. 이것을 막아야 한다. 우리 업계가 앞으로도 얼마나 멀쩡하게 남아있을지가 여기에 달려있다. “애자일”은 양동이에 가득찬 헛소리에 불과하며, 프로그래밍 및 컴퓨터 과학과도 아무런 상관이 없고, 원래 튀어나왔던 똥덩어리 속으로 다시 던져넣어야 한다.

[doshkim]

VISAs for International Founders Doing Startups in U.S.

Hello there foreigners and immigrants. Yeah that’s you (and me).

Today, I’m going to save you few bucks from expensive consulting fees with the immigration lawyers. Sadly, below does not cover the details, but will give you an idea of which route you can take.

There are five VISA types for international founders/entrepreneurs entering the U.S.: L1, E2, EB5, H1B, O

Let’s go through each of them briefly below:

1. L1

For whom? Expats(execs, managers, specialists) working at US Entity (with minimum of 1 year employment history at the foreign company)

Duration & Extension 3 yrs + 3 yrs (+ 1 yr for execs/managers) (total 6 ~ 7 yrs max)

Difficulty Depends on the company (must show that it will survive, easier with $1M+ previous funding)

Quota Any time (get the result in 15 days after filing using premium processing)

Family/Spouse can work? Yes

Greencard Yes 

2. E2

For whom? Executives/Managers in US Subsidiary

Duration & Extension 2 yrs + unlimited extension of 2 yrs each

Difficulty Relatively easier with money/investment >= $300k (but also lots of paperwork)

Quota Any time (takes longer than L1)

Family can work? Yes

Greecard Nope (can be switched later, but initially, it’s not meant for this)

3. EB5

For whom? Rich people

Duration & Extension 2 yrs + unlimited extension of 2 yrs each

Difficulty Easy with personal investment >= $500k or $1M (depending on the type you choose)

Quota Any time

Family can work? Yes

Greecard Yes

4. H1B

For whom? For employees with specialties (e.g. engineers, M.S.); Cannot be an employer or majority shareholder

Duration & Extension 3 yrs + 3 yrs ext. (total 6 yrs max)

Difficulty Medium ~ Hard (because there’s only a limited quota)

Quota 65k per year (apply April, results October)

Family/Spouse can work? Nope

Greencard Yes

5. O

For whom? Talented people who are being hired at a US firm (usually arts, athletes, but biz as well)

Duration & Extension 3 yrs + unlimited extension of 1 yr each

Difficulty Hard (need to prove that you are special somehow)

Quota Any time

Family can work? Yes

Greecard Yes

So basically, you can get L1 or E2 if you are setting up a US entity and the VISA is tied to the business. For L1, you will need the proof that you were an employee of the foreign entity for 1 year prior to the filing. Go for EB5 if you are a rich individual (since you are not tied to the business entity). H1B for people who are being hired by a US company, or O for few of those really talented people (or at least your lawyer needs to be really talented).

Will adjust the table above accordingly as I learn more, and let me know for any corrections that needs to be made.

Good luck!

[jihoonkimux]

요새는 버튼 문구 하나하나를 들여다보게 된다.

[jihoonkimux]

Hackers & Painters / Paul Graham

[jihoonkimux]

새벽 보딩 @비발디파크

[jihoonkimux]

코드로 디자인하기

회사에서 개발 환경을 갖추고 Git을 사용하기 시작한지 약 10개월이 되었으므로 그간의 소회를 적어봅니다.

 글의 내용을 보면 '코드'로 디자인이라기 보단, 협업에 관한 내용에 무게가 더 실린 것 같다. 좋은 내용이고, 이러한 내용들이 공유되고 많은 사람들이 관심을 가지는 건 정말 좋은 일이다.

 그런데.. 코드를 할 줄아는 디자이너, 디발자, 개자이너 이런 용어들이 많이 회자되고 있는데, 내 생각은 이렇다. 코드를 볼 줄 아는 것, 이해하는 것, 이런 능력들은 디자이너가 갖추면 좋은 '스킬'이 아니라, 더 나은 결과물을 만들기 위한, 더 나은 협업을 위한 '배경지식'인거다. 그 자체로는 디자이너의 경쟁력이 되는 스킬이 될 수 없다. 물론 버젼관리 프로그램인 Git 을 다룰 줄 알고 익숙해진다는 건 어디서나 도움이 되는 제네럴한 스킬이 될 수는 있겠지만 HTML 과 CSS 로 코드를 작성하고 수정하는 일련의 태스크들을 수행가능한 능력이 디자이너의 스킬이 될 수 는 없다. 이건 웹개발 환경에만 국한되는 이야기이고, 맥 개발환경에서는 또 다른 얘기가 된다.

 중요한 건, '디자이너가 갖춰야 할 스킬 x가지' 에 집중하기 보다는, 같이 일하는 사람들과 무엇을 만들 지, 어떻게 더 잘 만들지 고민하고 의사결정하는 시간이 훨씬 더 디자이너로서 성장하는 데 도움이 되지 않을까하는 생각이 드는 요즘이다.

[jihoonkimux]

Coursera : HCI course 1-1.Human Computer Interaction

Take free online classes from 80+ top universities and organizations. Coursera is a social entrepreneurship company partnering with Stanford University, Yale University, Princeton University and others around the world to offer courses online for anyone to take, for free. We believe in connecting people to a great education so that anyone around the world can learn without limits.

Coursera Global Translator Community (GTC) 활동에 참여하여,

HCI 강의를 번역해보았습니다.

플레이어 우측하단의 cc 로 Korean 을 선택할 수 있습니다.

[radiofun]

FORM SF 2014: Panel - Design Tooling

얼마 전에 샌프란시스코에서 있었던 디자인 컨퍼런스, FORM 세션 중 하나이다. 최근 화제가 되고 있는 프로토타이핑 툴의 제작자들이 나와 “디자인 툴”에 대한 이야기를 했는데, 꽤 흥미로웠다. 간단한 내용을 요약:

(Noah Levin, Google) 포토샵이나 스케치는 기존의 매체를 디자인하는 데에는 최적화되어있지만, 스와이프, 탭, 드래그하는 인터랙티브 미디어 디자인에는 부적절하다.

(Noah Levin, Google) 왜냐하면, 우리는 결국 인터랙티브한 결과물을 놓고 판단을 하게 되는데, 정적인 목업만으로는 인터랙티브한 결과물을 상상하기 어렵기 때문이다. 결국엔 개발자가 2-3주 이상 개발을 해서 내놓은 결과물을 보고 새로운 문제들을 떠올리게 되는데 이미 그 때가 되면 비용이 너무 커진다.

(Paul Colton, Pixate) 이러한 프로토타입 툴들이 각광받기 시작한 것은 디자인 흐름의 변화와도 관계가 있다. 스큐몰픽 디자인에서는 그림자 하나를 위해서 픽셀을 세밀하게 조정하며 작업을 했지만, 그것이 사용자와 어떻게 인터랙션하는 지는 두번째 문제가 되었다. 하지만 애플이 iOS7에서 스큐몰픽 레이어를 걷어내버리고 인터랙션을 전면으로 꺼내놓으며 이런 분위기가 조성된 것 같다. 디자이너들은 이제 내가 원하는 인터랙션을 어떻게 하면 구현할 수 있을지에 대해 관심을 가지며, 무엇보다 시간을 적게 들이며 iteration을 할 수 있는 방법을 찾는다. 하지만 개발자들은 매번 디자이너들을 위해 코드를 새로 짜 줄 수 없다. 그렇기 때문에 이런 툴들을 찾게 된 것 같다.

타임라인 베이스로 작업하지 않는 이유는?

(Koen Bok, Framer) 시간이 일정하지 않다. 인터랙션에 따라 다른 상태로 이동하게 되는데 이렇게 되면 타임라인 베이스로 만들 경우 효과적이지 않게 된다. (Paul Colton, Pixate) 이런 요청을 많이 받았지만 사실 쉽지 않다. 타임라인은 순서가 있다는 것을 가정하고 만들어야 하는데, 사실 인터랙티브 모델의 경우엔 사용자가 그 순서를 완전히 뒤집어버릴 수도 있다. 

배우기 어렵다는 이야기가 많은데?

(Brandon Walkin, Facebook) 사실 내가 처음부터 이 툴을 만든 것이 아니기 때문에 뭐라 말하긴 어렵다. 하지만 중요한 건 이런 툴을 만들 때에는 “어떤 것이든” 만들어낼 수 있어야 한다는 것이다. 제작자들도 생각해내지 못한 것들을. 쿼츠 컴포저는 그것이 가능하다. 어렵다는 것도 알고 처음에 보면 헷갈리기 때문에 처음부터 만든다면 이렇게 하진 않겠지만, 그래도 그 자유도는 굉장히 중요하다고 생각한다.

자유도 이야기가 나왔는데, 자유도가 높아서 오히려 뭘 어떻게 해야 할 지 모르는 경우도 있지 않나?

(Paul Colton, Pixate) 자유도가 높다고 해서 어려울 필요는 없다고 생각한다. Pixate는 “연필”과도 같은 역할을 하려고 목표하고 있다. 연필은 쓰기는 매우 쉽지만, 정말 아무거나 다 그릴 수 있지 않나? 인터랙션 디자인에서도 마찬가지로, 매우 심플하고 쓰기 쉽지만, 거의 뭐든 만들 수 있도록 하고 있다.

(Adam Debreczeni, Relative Wave) 일관성이 중요하다고 생각한다. Form도 처음 열면 어쩔 줄 모르겠는 게 사실인데, 기본 패치들을 일관되게 만들고 그것들을 가지고 재사용 가능한 패치들을 만들어내게 하려고 했다. 그렇게 커스텀 패치들을 만들어가며 확장해나가는 형식으로…

이런 툴이 디자인 단계의 어느 수준에서 많이 활용될 수 있을 것 같나? 

(Koen Bok, Framer) 툴이 어느 정도로 유연하느냐에 따라 달려있다. 작은 인터랙션에 집중해서 제작하는 것은 당연하고, 코드나 스그널 플로우 기반의 유연한 툴이라면 전체 앱 경험을 만들 수도 있다. 물론 쉽지는 않겠지만 Framer에서는 이런 일이 가능하다. (Brandon Walkin, Facebook) 쿼츠 컴포저를 프로세스 초반부터 시작한다. 마크 주커버그에게 보고할 때에도 쿼츠 컴포저로 거의 완성된 형태로 만들어서 보고한다. 실제 사용자가 마주하게되는 그 형태로 만든다.

(Clark Valberg, Invision) 투자를 하면 할 수록 그 형태로 편항되기 쉽다. 열심히 만들었기 때문에 버리기 싫은 생각에 빠져들면 안된다. (좀 더 가볍게 만들어야 한다는 취지의 이야기인것 같지만…)

앞으로에 대해서 말해달라, 이 중 한두개의 툴만 살아남게 될까?

(Koen Bok, Framer) 선택의 폭이 넓어졌다는 면에서 환영하고 싶다. 예전에는 디자인 한다고 하면 “포토샵”이었지만, 이젠 정말 많은 선택지가 있다. 어떤 것이 살아남느냐에 대해서는..시간이 해결해주지 않을까? 이들 중 장점만을 잘 택해 훌륭하게 진화하는 툴이 있을 것 같다.

(Brandon Walkin, Facebook) 결국엔 디자이너들이 이런 툴을 당연히 쓸 줄 알아야 하는 시대가 올 것이다. 우리가 현재 포토샵이나 스케치로 창의적인 결과물을 내놓듯이 말이다. 지금은 이 앱에서 조금, 저 앱에서 조금씩 빼 와서 인터랙션을 구현하지만 조금 지나면 포토샵으로 개성있게 디자인하는것만큼 다양한 인터랙션 디자인들을 볼 수 있게 될 것이다.

(청중 질문) 이런 툴로 프로토타입을 만들 때 사실 꽤 많은 로직들이 들어가는데, 이러다보면 앱을 만들 수도 있겠다는 생각이 든다. 앞으로 어떻게 될 것 같은지?

(Adam Debreczeni, Relative Wave) 거의 다 왔다고 생각한다. Form도 지금 만든 컴포지션을 바로 앱으로 돌릴 수 있도록 제작되었고. 결국에는 파일 익스포트해서 엑스코드로 넘길 수 있는 때가 올거라고 생각한다.

(Clark Valberg, Invision) 몇줄의 코드를 짜는 것과, 소프트웨어 아키텍트는 큰 차이가 있다고 생각한다. 개발자들이 해야하는 일은 그런 부분 말고도 훨씬 많은데, 이런것까지 커버하기에는 아직 갈 길이 멀다고 생각한다.

(Brandon Walkin, Facebook) 프로토타입이 실제 앱과 다른 점은 다양한 케이스를 신경쓰지 않아도 된다는 것이다. 내가 해결하고자 하는 문제 이외의 다양한 문제들 (해상도, 기기)에 신경을 쓰지 않고 집중할 수 있다는 것이 장점이다. 또, 개발을 할 때에는 기본 컴포넌트 (UIKit) 들을 써서 해결할 수 있는 문제들이 많은데, 나만의 환경에서 앱을 돌리게 되면 그런 부분들을 많이 놓치게 될 것이다.

(Koen Bok, Framer) 갈 길이 멀다고 생각은 하지만, 해결할 수 있는 문제들은 많다. 아직도 리소스를 주고받기 위해서 .zip 파일을 주고 받는데, 이건 좀 바보같은 일이고 곧 해결이 가능할 거다. 마찬가지로 spring physics 값이나, 상태 값 같은 것은 바로 전달이 가능할 수 있다. 어찌 보면 당연한 일인데 되지 않고 있다. 

—

예전부터 계속 이 블로그에 쓰던 내용이긴 하지만, 이젠 이런 소프트웨어를 디자인하는 데 있어 포토샵만을 고집할 순 없게 되었다. 포토샵이 쓸모없다는 이야기를 하는 것도 아니고, 비쥬얼적인 부분을 무시하는 것도 아니다. 다만 신경써야 할 영역이 하나 더 생겼고, 그 영역은 기존의 툴로는 해결할 수 없는 문제들을 안고 있다는 이야기를 하고 싶은 것이다.

이 중에서 Invision을 빼고는 다 써봤다. 하나 이상의 프로토타입을 만들어보았는데, 다들 개성이 뚜렷하고 장단점이 확실하다. 어떤 것이 주류가 될 지는 모르겠지만, 이런 툴에 대한 관심을 놓지 않으려 한다. 간략하게 정리한 내용 이외에도 다양한 내용이 많이 있으니 링크로 가서 꼭 전체 내용을 다 확인해 보시길!

[jihoonkimux]

프로토타이핑 만을 위한 툴. 이전에는 안그랬는데, 요새는 약간 부정적으로 바뀌어간다. 프로덕트를 만들어가는 과정에서 과하다 싶을 정도로 업무를 세분화시키고 있다. 본질에서 점점 멀어져 가는 느낌.

[five0203]

본문은 Y-Combinator의 Sam Altman이 작성한 ‘Advice for ambitious 19 year olds'을 번역한 글입니다.

"저는 야망 넘치는 19살 입니다. 무엇을 하면 좋을까요?"

저는 이 질문을 자주 듣습니다. 그리고 이제는 그것에 대한 신빙성 있는 데이터가 어느 정도 쌓여 이 질문에 대한 답변을 좀 더 많은 분들과 나누려 합니다. (미국에서는 19살이 고등학교를 졸업하고 사회에 나오는 나이의 기준으로 주로 사회 초년생이라는 의미를 담고 있습니다. - 역자)

대부분의...

[jihoonkimux]

"결론은 여러분이 받는 월급이 우선순위가 되어서는 안 된다는 것입니다. 최근에 어떤 친구가 이러한 성공 가도를 달리는 스타트업에 들어가지 않고 3만 달러 연봉을 제시한 마이크로소프트에 들어가기로 했다는 소식을 들었습니다. 개인적으로는 옳지 않은 선택이라고 생각 합니다. 그는 이제 흥미로운 것을 만들 기회를 놓쳤을 뿐만 아니라 보다 현명한 사람들과 일 할 수 있는 기회를 놓치고 만 거죠. 시간이 지나고 새로운 변화가 필요한 때가 되었을 때 그는 그가 가질 수 있었던 기회보다 더 적은 선택권을 가질 수 밖에 없습니다."

정말 공감. 하지만 경력이 쌓이고 나이를 먹을수록 힘들어진다는게 함정..

[jihoonkimux]

(*note : 예전에 인터컴 블로그에 올라왔었던 '디자이너를 채용하는 방법'을 번역해보았습니다. Julie Zhuo가 쓴 '페이스북이 디자이너를 채용하는 방법' 과 비교해서 보면 또 다른 재미를 느낄 수 있습니다.)

A beautiful product that solves a problem no one has will fail. An ugly product that solves a real problem well can succeed. 

아름답지만 어느 누구도 가지고 있지 않은 문제를 해결하는 제품은 실패한다. 못생겼지만 실재하는 문제를 잘 해결하는 제품은 성공할 수 있다.

 이전 포스팅 '디자인의 드리블화'에 아주 멋진 답변들이 달렸습니다. 많은 분들이 기본적인 전제에 동의하여 의견을 덧붙여주시고, 몇몇 분들은 동의하지 않고 반대의견을 제시해 주셨습니다.

 저는 여러분들의 의견에 답변을 해드리고, 특별히 '드리블'이 저로하여금 그 포스팅을 쓰도록 영감을 주었던 것은 아니라는 것을 설명해 드리고 싶네요. 그리고 우리가(인터컴이) 어떻게 디자이너들을 채용하는지에 관해 이야기하려 합니다.

디자인에 대한 몰이해의 악순환

 수 년동안 소프트웨어 개발 분야에서 훌륭한 디자인의 중요성은 오해받고, 과소평가 되어왔습니다. 애석하게도 전 세계의 디자이너들은 프로덕트 매니지먼트나 개발 분야의 동료들에게 이미 정의되어 있는 무언가의 시각적인 부분에 대한 관리를 요청 받아왔죠. 그들은 자조섞인 목소리로 스스로를 "포토샵쟁이" 라고 불렀습니다. "포토샵쟁이"인 디자이너들은 항상 새로운 팀, 새로운 직업을 찾아다닙니다. 그들은 이런 것은 디자인이 아니라는 걸 알았으니까요.

수 많은 사람들이 이런 오해를 바꿔나가기 위해, 디자인이란 어떻게 보여지는지가 아니라 어떻게 작동하는 지에 대한 것이라는 걸 설명하며 쉬지않고 노력해왔습니다. 스티브 잡스가 훌륭한 말을 남겼죠.

대부분의 사람들은 디자인이 보여지는 것이라고 생각하는 실수를 하지요. 사람들은 이렇게 겉모양만을 꾸미는 거라고 생각합니다. 

디자이너들이 박스를 건네받고, "이쁘게 만들어봐!" 라고 듣는 것 처럼 말이죠.

그건 우리가(애플이) 생각하는 디자인이 아닙니다. 디자인은 단지 어떻게 보여지는 지, 어떻게 느껴지는 지에 관한 것이 아닙니다. 디자인은 어떻게 작동하는 가에 대한 것입니다.

 느리지만 확실하게, 소프트웨어 기업들은 디자인에서 두각을 보이는 기업들이 경쟁사들 보다 앞서 나간다는 걸 깨달았습니다. 애플은 가장 명확하고 가장 도움이 되는 예시가 될 겁니다.

 훌륭한 디자인이 가지는 힘에 대한 이해도가 높아지면서 디자이너의 일자리가 점점 많아지게 되었고, 기업들이 다른 기업들과 경쟁하기 위해 훌륭한 디자인에 대한 수요도 점점 높아졌습니다. 하지만, 이런 기업들에게 있어 디자인은 새로운 분야였기 때문에, 정말로 그들이 무엇을 필요로 하는 지 이해하지 못하고 드리블 같은 커뮤니티에서 "좋은 디자이너" 를 찾았습니다. 그러나 드리블은 디자인이 정말로 무엇인지를 대표하는 공간이 아닙니다. 그리고 여기서 악순환이 이루어지죠.

( Images from Insideintercom.io )

#1. Recruiters mistakenly judge design by Dribbble portfolios

리크루터들은 드리블 포트폴리오로만 디자인을 판단하는 실수를 범합니다.

#2. Designers looking for work create Dribbble portfolios

디자이너들은 드리블 포트폴리오를 만들 수 있는 직장을 찾아다니죠.

#3. Young designers conclude that Dribbble represents what is most important in design

어린 디자이너들은 드리블을 보고, 디자인에 있어서 무엇이 가장 중요한 지 결론을 내립니다.

  #4. Dribbble dominates discussion + assessment of design skills.

드리블이 토론의 중심이 되고, 디자인 스킬을 평가하는 도구가 됩니다. 

(repeat)...

(반복)

 이런 악순환은 결국 우리의 기술을 퇴보하게 합니다. 왜냐하면 디자인에 대한 오해와, 디자인은 원래 미학에 대한 것이라는 근거없는 믿음을 영속시키기 때문입니다. 그래서 비쥬얼 디자이너들은 이런 리크루터들에게 채용되어, 그들로부터 훌륭한 프로덕트 디자이너가 될 거라는 기대를 받으며, 모두를 실패하게 만듭니다.

청소기에는 비쥬얼 디자인이 존재하지 않습니다.

 저의 첫 글에서, 디자인의 네 가지 레이어에 대해 짚어보았습니다. 저는 이 레이어들 중, 그 어떤 것도 독립적으로 존재하지 않는다고 믿습니다. 최고의 디자이너들은 네 가지 레이어를 모두 이해하며, 최고의 비쥬얼 디자이너들은 어떻게 환상적인 인터랙션을 디자인할지 알고 있습니다. 저의 경험에 비춰보면, 같이 일해 보았던 최고의 디자이너들은 한 가지 또는 두 가지 레이어에서 훌륭한 능력을 보였고, 다른 레이어에서도 매우 좋은 능력을 보여주었습니다.  다른 레이어의 디자인을 할 수 있는 능력의 합은, 개개의 레이어들에서 뛰어난 것 보다 훨씬 더 대단합니다.

여러분이 필요로 하는 레이어들에 반대되는 디자이너들을 고려하세요.

 제가 디자이너를 채용할 때, 보통 두가지 레이어에서 뛰어난 사람을 찾습니다. 그리고 나머지 레이어에 대해 배우려는 열정이 충만한 사람들을요.

가장 최근에 찾고 있던 디자이너의 프로필은 아래 형태입니다.

 적어도 비쥬얼 디자이너들은 이런 형태를 띄어야 하죠.

 "우리에겐 디자이너가 필요해!" 라고 얘기하기 전에, 여러분의 기업에서 어떤 유형의 디자이너가 필요한지 한 번 생각해보세요. 스타트업 환경에서, 프로덕트 디자인 성향에 치우친 CEO에게는 재무적 / 분석적 성향의 CEO보다 무언가 다른 디자이너가 필요할겁니다. 그리고 한 가지 더, 모든 것을 잘하는 사람이 필요하다는 결론을 내기 전에 아래 유형의 사람은 정말로 드물다는 걸 알아두세요.

인터랙션 디자인과 비쥬얼 디자인은 따로 분리해낼 수 없습니다.

 비쥬얼 디자인은, 인터랙션 디자인과 밀접한 관계에 있습니다. 반복, 상태 변화, 데이터 변화 등등. 이것은 프린트 디자인이 아닙니다. 어떻게 보여지는가를 제공함과 동시에, 어떻게 작동할 것인가도 제공해야 합니다. 만약 당신이 인터랙션 디자인 레이어를 더 많이 이해하고 싶어하는 비쥬얼 디자이너라면, 댄 새퍼의 책, 마이크로 인터랙션 을 강력하게 추천합니다.

 몇몇 분 들은, 비쥬얼 디자인은 사람들의 관심을 갖는 데 있어 중요하므로, 가장 중요한 레이어라고 말합니다. 저는 다르게 생각합니다. 비쥬얼 디자인은 물론 정말 중요하지만, 사람들은 가치를 제공받는 것으로도 역시 관심을 갖습니다. 프로덕트가 무엇인지, 프로덕트가 어떤 가치를 제공할 수 있는 지로요. 바꿔말하면 더 높은 레벨의 디자인 레이어가 동작하는 것에 관한 겁니다. 역사적으로도 이쁘지 않은 프로덕트가 성공하는 것을 우리에게 증명해주었죠. (크레이그리스트 craiglist 같은) 그리고 아름다운 프로덕트가 실패하는 것도요. (컬러 color 같은) 이쁜 프로덕트는 아마도, 사람들의 이목을 집중시킬 수 있겠지만, 사람들은 비쥬얼 디자인을 제외한, 다른 부분들에서 조악한 프로덕트들에는 열광하지 않습니다. 모든 레이어가 전부 중요합니다.

사람들이 말하는 드리블 보다는, 사람들이 드리블을 어떻게 사용하느냐를 주목해야 합니다.

 드디어, 드리블에 대해 얘기해봅시다. 첫 번째 글은 드리블이라는 프로덕트를 비난하는 게 아니었습니다. 디자인에 영향을 끼치는 좀 더 넓은 주제를 얘기한 것이었죠. 디자인에 대한 몰이해의 악순환은, 없어져야 합니다. 드리블을 지지하는 사람들의 반응에 관련한 제 의견은 이렇습니다. 드리블은, 사람들이 어떻게 말하는 지에 대한 것이 아니라, 사람들이 어떻게 사용하는 지에 대한 것입니다. 플랫폼을 만드는 사람이라면 누구나 알 것 입니다. 여러분은 사람들이 플랫폼을 어떻게 사용할 지 예측할 수 없습니다. 그렇게 때문에 플랫폼은 반응하고, 발전하며, 진화하는 겁니다. 사람들이 말하는 드리블은 - "쇼케이스 사이트", "작품을 보여주고 설명하는 사이트", "디자이너를 위한 트위터", "현실에서의 제약에 대한 걱정없이 디자인 하는 공간" 등등으로 불립니다. 이 들 중 어떤 설명도 말이 되지 않습니다. 만약 드리블이 진행중인 작업과 간결성을 보여주기 위한 거라면, 좀 더 엉성한 작업, 스케치들, 만들다 만 것들이 올라와야 합니다. 아직까지는 드리블에 올라오는 작업 들 대부분이 완벽한 픽셀만을 지향합니다. 만약 드리블이 시각적 영감을 얻기 위한 거라면 좋은 장소이죠. 하지만 그건 디자인보다 예술에 가깝습니다. 그리고 확실히 훌륭한 디자이너들을 찾기에 적합한 장소는 아닙니다. 훌륭한 예술가들, 훌륭한 그래픽 아티스트들은 확실히 있습니다. 하지만 디자이너들은 아닙니다. 

 제가 본 드리블의 가장 큰 장점은 여러분의 웹사이트로 리크루터들을 끌어올 수 있는 광고처럼 활용된다는 겁니다. 당신의 생각과, 스케치와, 프로세스를 보여줄 수 있는 공간으로요.

드리블에서 유명해진다고 해서 여러분이 훌륭한 디자이너가 되는 것은 아닙니다.

 물론 드리블에는 몇명의 멋진 디자이너들이 있습니다. 그리고 그러한 작업물들은 [1] [2] 비쥬얼 디자인 레이어가 아닌 것에 초점이 맞춰져 있어요. (예시 작업물을 제공해준 Alex 와 DC Townson 에게 감사의 말을 전합니다.) 하지만, 그들은 예외적이죠. 대부분의 경우, 드리블에서 유명한 포트폴리오 들은 단순히 그래픽 소프트웨어의 달인이라던지, 최신의 디자인 트렌드를 이해하고 있다는 증거밖에는 되지 못합니다. 그리고 몇몇은 여러분이 디자인의 네 레이어 중 하나를 잘 다룬다는 걸 보여주죠. 그러나 드리블에서의 인지도와 훌륭한 디자인 작업물을 만들어 내는 것과의 인과관계는 존재하지 않습니다. 

우리가 이런 악순환을 깨야 한다는 것이 가장 중요합니다.

 저는 드리블에 대해 그렇게 신경쓰지 않습니다. 다른 포트폴리오 사이트에도요. 제가 가장 신경 쓰는 건, 이 악순환을 깨는 것입니다. 저는 어린 디자이너들이 훌륭한 디자인이 가지는 진정한 영향력에 대해 알지 못하게 될까봐 걱정이 됩니다. 저는 어린 디자이너들이 누구도 이해하지 못하는 인터랙션이나, 누구도 원하지 않는 프로덕트인지 모르고 디자인하지 않는 것, 그들을 실패하게 만드는 회사에 채용되지 않도록 하는 것에 신경 씁니다.

 이 글은 디자인 교육과, 그리고 무엇보다도, 디자인이란 기본적으로 어떻게 보이느냐가 아닌 어떻게 작동하느냐에 대한 것이라는 생각에 관한 이야기입니다.

[bjornamherd]

Design Inspiration: Social UI kit via Dribbble > Alex Gilev

[jihoonkimux]

Clean & simple