일정을 계속 못 지키셔서 어쩔 수 없이 근무 시간을 늘리기로 결정했습니다.

평소에도 사색을 하여 반면교사를 자주 하는 편이다. (안 믿기겠지만)
그때마다 글로 남기고 싶었지만 귀찮아서 잘 안 하기도 했었고.. 글로 적는다 하더라도 퍼블리싱 된 건 극히 일부.
아마 이 글 또한 퍼블리싱은 못할듯하다.

잠이 안온 가운데 문득 한가지 망상이 떠올랐다. 떠오른 망상은

어느 한 스타트업이 있고 그 회사 대표가 올핸즈미팅에서 “일정을 계속 못 지키셔서 어쩔 수 없이 근무 시간을 늘리기로 결정했습니다.”라고 통보를 했고 직원들은 받아들일 수 없다는 표정을 하고 있었지만 그 어느 누구도 이에 대해 발언을 하지 않고 있는 상황이었다.

이런 끔찍한 일이 일어나면 안 되겠지만, 충분히 일어날 수도 있는 일이다.
이 상황을 상상하며, 나라면 어떻게 했을까? 등의 생각을 해봤다.

사실 제일 먼저 떠오른 생각은
대표가 얼마나 답답했으면, 오죽했으면 이런 통보를 했을까?
대표 스스로도 저런 발언을 했을 때 직원들이 어떻게 받아들이지 뻔이 알 텐데, 저런 말을 하는 것이 과연 쉬웠을까?
스타트업에서 문화가 얼마나 큰 요소인지 알고 있을 텐데, 디모티베이션되는 저런 말을 하는 것이 과연 쉬웠을까?
저 발언을 하기까지 얼마나 많은 고민과 용기가 필요했을지 나 같은 범인은 상상조차 힘들다.

하지만 안타깝게도 대표의 고충을 퇴색시켜버리는 두 가지 실수를 범했다.

1 올핸즈미팅에서 ‘통보’를 해버렸다.

‘모든 사람이 손을 들고 발언을 할 수 있다’라고 해서 올핸즈미팅이라고 하는데, 이런 자리에서 일방적인 통보를 해버린다는 것은 굉장히 안 좋은(웃긴) 행동이다.
많은 스타트업들이 ‘올핸즈미팅’이라고 칭하는 것들을 하지만 정말로 의미에 부합하는 미팅이 이루어지고 있는가?
그게 아니고 일방적인 통보를 하는 것이라면 왜 ‘올핸즈미팅’이라고 하는가?
차라리 ‘주간 공지’ 혹은 ‘월간 공지’ 이렇게 명하는 게 희망고문도 안 하고 시맨틱하고 얼마나 좋은가?
이러한 상황에서 직원이 할 수 있는 것은 없다. 그냥 포기하고 들어주는척하면 된다.

반대로 대표는 정말로 올핸즈미팅을 원하고, 갖가지 질문에 대비해 답변도 충실히 준비해왔으나 그 어느 누구도 질문을 하지 않는 경우도 있다.
질문을 하게 하기 위해 상품을 주는 등 리워드 시스템을 도입하여 유도하는 것도 하나의 방법이겠으나.. 나라면 다른 방법을 선택할 것 같다.

동료들이 스스럼없이 질문을 하는 문화가 장착될 때까지 몇몇 사람을 섭외하고 내가 준비한 질문을 알려주고 질문하게 하는 것이다.
여기서 중요한 것은 사람들이 가지고 있는 기존의 틀을 깨주는것인데. 여기서 틀을 구성하는 것은 질문자와 질문 내용이다.
“누구나 어떤 내용이든 질문을” 할 수 있어야 진정한 올핸즈미팅이 아니겠는가?
고로 나는 가장 최근에 입사한 사람, 가장 나이가 어린 사람, 인턴 등 사내에서 파워가 없는 사람들로 선정을 하고 민감한 질문을 부탁할 것이다.
그러면 다른 사람들은 “아니? 인턴이 질문을 해? 심지어 이런 질문을??”라며 놀라 할 것이고,

57976e1d18aa0

아니? 이렇게 심한 말을!

난 천연덕스럽게 당황하지 않고 답변하는 연기(?)를 할 것이다. 가능하다면 쿨한 척도 하며
이렇게 몇 번의 짜고 치는 고스톱이 몇 판(?) 돌고 나면 자연스럽게 질문자들이 생길 것이다.

운이 좋게 처음 시도에서 문화가 정착이 될 수도 있겠지만, 그게 아니라면 정착이 될 때까지 난 이 짜고 치는 고스톱을 계속 칠 것이고 난 이 바닥의 타짜가 되어.. 응? 아 이게 아니고.. 연기의 신이 되어 배우로 데뷔를.. 아 이것도 아니고..

암튼 여러 번 시도를 하다 보면 언젠가는 이러한 문화가 정착이 된 후 동료들에게 ‘문화 정착을 위해 사실 질문을 짜고 했다’라고 해명을 할 것이다.

57976e1d18aa0

아니? 이렇게 깊은 뜻이!

그리고 또 하나 중요한 것은, 섭외한 사람들에게 “당신이 질문한 것에 대한 피드백을 누군가 해줬다면 그걸 나에게 공유해달라”라는 것이다.
무슨 말인고 하니 인턴이 속한 팀의 리더 혹은 사수가 와서 “야, 네가 뭔데 그런 질문을 해?” 라거나 “우와! 인턴 나도 그거 궁금했었는데 질문 잘했어!” 등등 말이다.

올핸즈미팅이 잘 이루어지지 않는 상태라면, 그들의 속내를 내가 알 방법이 없다.  그들의 목소릴 듣기 위해 부단히도 노력해야 한다.
리더는 함께 일하는 동료의 목소리에 항상 귀를 기울여야 한다.
설사 그들이 내게 아무 말을 해주고 있지 않더라도 들을 준비가 되어 있어야 한다.

2 사람들의 공감대 혹은 납득을 얻어내지 못했다.

만약 위 상황처럼 통보를 해야 한다면 일정이 늦어지는 게 정말로 직원들의 잘못이고, 징벌(?) 받아 마땅한 상황인지 납득할 수 있도록 설명을 할 것이다.
뿐만 아니라 의사 결정에 어떤 프로세스가 진행이 되었는지? 그 모든 것들이 투명하게 공개하는 게 기본이라 생각한다.

내가 대표라면 먼저 일정이 늦어지는 원인에 대해서 파악을 할 것이다.
리더나 담당자를 소환하여 회의할 것이고 필요하다면 1:1 미팅으로도 진행할 것이다.

Silicon.Valley.S03E08.720p.HDTV.x264-KILLERS.mkv_001004545

리더와 1:1 면담이라니..

여기서 중요한 것은 추궁이 아니라 “어떻게 하면 일정이 늦어지는 걸 방지할 수 있을까요?”, “내가 무엇을 도와드리면 될까요?”, “그러기 위해선 뭐가 필요하세요?”라는 뉘앙스와 멘트이다.
이러한 과정만으로도 이미 공감대를 형성하게 됨은 물론, 얻은 자료를 바탕으로 원인을 찾아낼 수 있다.
근데 원인만 찾아낼 수 있는 게 아니다. 이미 해결책의 힌트도 미팅을 통해 얻지 않았는가?
KakaoTalk_20141128_094809391

그들의 의견을 참고하여 나름의 해결책들을 생각한 후 올핸즈미팅을 연다. 미팅을 하여 얻은 데이터들은 수치화하여 공유를 하고 해결책들을 공유한다.
여기서 핵심은 바로 ‘올핸즈미팅’이라는것이다. 내가 생각한 혹은 추천받은 해결책들을 여러 사람과 논의하여 타당한지 더 좋은 해결방안은 없는지 논의를 하고 정할 것이다.

실제로 내가 저렇게 했었는데 사실 이 과정은 무척이나 번거롭고 귀찮으며 원치 않은 감정 소모가 일어나기도 한다.
하지만 그럼에도 불구하고 내가 이러한 과정들을 했던 것은 그게 올바른 리더라고 난 생각하기 때문이다.

아.. 적고 싶은 말 아직 많이 남았는데, 직원 입장 편도 남았는데.. 시간이 벌써 새벽 6시를 향해 가고있다.
내가 생각하는 리더, 동료 등에 대해 언제 한번 길게 적고 싶었는데..
오늘은 그날이 아닌가 보다. 아 몰라 잘래.

Advertisements

회사를 고르는 기준

꽤 오랫동안의 백수 생활을 하면서 많다면 많고 적다면 적은 회사와 인터뷰를 봤었다.
그 중 데스벨리에 있는 스타트업들은 송구하게도 모두 고사를 했다.
더 이상 스타트업에 있다간 인생이 망하겠단 생각이 들기도 했지만아래 2가지 이유에 의해 판단을 했다.
이 기준은 내가 퇴사를 준비하면서 부터 가졌던 기준들인데, 정리할겸 한번 끄적여봤다.

내가 배울 수 있는 동료들이 있는가?

꽤 오랜 기간동안 스타트업에서 일을했고 헤더로 지내기도 했다.
아시다시피 스타트업은 실력있고 좋은 사람을 모셔오는것이 사실상 불가능에 가깝다.
결국 비용 절약을 위해 쥬니어를 뽑을 수 밖에 없다. 그렇게 뽑은 대다수의 쥬니어들은 내게 기술적 제안을 하거나 건의를 하지 않고, 수동적인 태도로 일은 한다. (물런 아닌 사람도 있었다. 지금 기억나는 사람은 미리야정도..? 그리고 수동적임을 비난하는것은 아니다.)
그들에게 나의 지식을 알려주는 형태로 수년간을 보내다보니, ‘내 지식은 제자리’라는 생각에 불안감이 종종 날 휘감았다.
이 불안감은 결국 내가 회사를 볼때 ‘내가 배울 수 있는 동료가 있는가?’ 라는 기준으로 자리잡게 되었다.
그리고 우리 모두 알고있는 사실. 좋은 동료랑 일하면 특별한 노력을 하지 않더라도 자연스럽게 그들에게서 많은것들을 배우게 된다. 하지만 그들에게 받아 먹기만 한다면 이치에 맞지 않는다.
스스로도 ‘그들에게 뭔가를 나눌 수 있는 사람으로 성장해야만 한다’는 의식을 가지고 성장을 한다면, 이러한 선순환 구조가 생긴다면 더할 나위 없지 않은가?

내가 배울 수 있는 기술이 있는가?

사실 내가 적은 기술은 ‘대용량 처리’를 의미하지만, 좀 더 범용적으로 표현하다보니 ‘기술’로 퉁치게 적었다.
스타트업에서만 일을 해보다보니, 대용량 처리를 할 일이 없었다.
그러다보니 대용량 처리를 늘 배우고 싶었고, 그렇게 지원한 큰 회사들은 아이러니하게도 내게 대용량 처리 기술을 요구를 했다.
뭐 꼭 ‘대용량’이 아니어도 상관없다. 회사 차원 혹은 팀 차원에서 내가 배울 수 있는 기술이 있는가? 그리고 그 기술은 앞으로도 꾸준하게 사용될 기술인건가?  로 판단을 했다.

그렇다면 뭘 배우는건가?

위 2가지 말고도 한가지 더 말하고 싶은것이 있었다.
바로 ‘배움’의 범위를 ‘기술’에 국한짓지 말라는것이다.
커뮤니케이션 능력, 대인관계, 태도, 가치관, 취미, 육아, 연애, 정치등 그 어떤것도 포함 된다.
우리는 소처럼 죽을때까지 개발만 하는것이 아니다. 우리는 삶을 살고 있다.
즉 기준을 ‘개발’에만 국한시킬 것이 아니라, 우리의 ‘인생’으로 초점을 넓혀서 바라봐야한다.
남은 삶을 살아가는데 참고가 되고 도움이 될만한 그 모든것들이 다 ‘배움의 대상’인것이다.

많은 개발자들이 ‘개발’의 배움과 성장을 갈구한다. 물런 이것이 나쁘다는것은 아니다.
다만 너무 ‘개발’에만 국한 시키기보다 좀 더 넒은 시야를 가지고 배움을 해나간다면, 좀 더 나은 삶을 살 수 있게 되고, 이러한 에너지가 결국은 더 나은 개발자로 성장하는데 사용되지 않을까?

Sorcery VS Devise

Sorcery 소개

ca62lrg

얘는 소서리스에요..

Devise는 워낙 유명해서 별도의 설명이 필요 없겠지만 Sorcery의 경우 상대적으로 덜 유명해서 간략하게 소개를 먼저 해본다.

이스라엘 개발자 Noam Ben Ari(이후 NoamB)가 만든 Authentication Gem으로 2010년 10월에 첫 커밋이 나왔다.
필자는 이전까진 restful-authentication를 사용했는데 Rails 3가 출시했음에도 불구하고 대응이 늦었다.
그때 혜성처럼 나타난 게 몇 가지 있었는데 Sorcery, Devise도 그것들 중 하나였다. (지금까지 살아남은 녀석들도 아마 이 두 녀석뿐일 듯)
처음에는 Devise를 사용했었지만 RailsCasts에서 Sorcery를 소개해줬고, 이때부터 쭉 Sorcery를 사용해왔다.

NoamB 거의 혼자서 개발을 해오다시피 했고, 지금은 개인 Repository가 아닌 Sorcery의 Repository를 만들어서 관리하고 있고, NoamB는 현제 일선에서 물러나 Chase GilliamJosh Buker 이 두 사람이 Maintainers로 관리를 하고 있다.

Sorcery만 소개해주면 Devise한테 미안하니 간략히 소개하자면 SimpleForm을 만든 plataformatec이 만들고 관리하고 있다.

기능 비교

사실 처음에는 그냥 느낀 점만 간략하게 쓸려고 했는데.. 그럼 너무 성의 없어 보일까 봐 간략하게 정리해봤다.
기능 위주로 선택하려 한다면 아래 표가 도움이 되시리라

기능설명 Sorcery Devise
Authentication Core Database Authenticatable
OAuth External Omniauthable
회원가입시 메일 인증 프로세스 User Activation Confirmable
암호 리셋 프로세스(메일 전송) Reset Password Recoverable
회원가입 Core Registerable
자동 로그인 Remember Me Rememberable
로그인/아웃등 유저 행적 기록 Activity Logging Trackable
Session Timout 설정 Session Timeout Timeoutable
Validation email, password Validatable
로그인 실패 여러번시 계정 잠금 Brute Force Protection Lockable
HTTP Authentication Basic HTTP Authentication Database Authenticatable

Validation이 Sorcery에는 없지만 이건 Rails의 Validators를 이용하면 해결된다. (Rails를 아시는 분이라면 Devise가 Validation을 왜 따로 제공하는지 이해가 안가실 수도 있는데, 그건 아래에 설명하겠다)
보면 알겠지만 방법의 차이만 있을 뿐 제공하는 기능은 동일하다.
그러므로 기능의 수는 안타깝게도 무승부.

간단히 Authentication 위주로만 쓸 경우

문서 살펴보고 맘에 드시는 걸로 선택하면 된다.

57f8la

장난 아니고, 진짜에요..;;

여러 부가기능을 쓰지만 수정 안 하고 쓸 경우

Devise를 추천한다.
Devise는 Boilerplate가 아주 많이 제공되어서 여러 부가 기능을 사용할 때 편리하다.
하지만 많은 커스터마이징이 필요한 경우에는 적합하지 않다. (우리가 알고 있듯 Boilerplate는 양날의 검인데, 그 단점이 여기에도 해당된다고 보면 된다)
왜냐하면 Devise는 많은 부분들이 감추어져 있다 보니, 구현 단계에서의 수정이 쉽지 않다.
그래서 커스터마이징이 필요한 사람들을 위해 Registerable, Validatable 같은 부가기능을 통해 커스터마이징을 하도록 하고 있지만 안타깝게 이마저도 쉽지 않다.  더욱이 문서 또한 레퍼런스가 아닌 API만 제공하다 보니 실제 Usage를 알기가 어렵다.

여러 부가기능 및 커스터마이징이 필요한 경우

Sorcery를 추천한다.
Sorcery는 Boilerplate가 없다고 봐도 무방하다. 그렇기 때문에 많은 부분들을 처음부터 쌓아올려야 한다.
별도의 수정 없이 사용할 때는 이게 그렇게나 귀찮고 짜증 나지만, 반대로 커스터마이징을 많이 해야 하는 경우 이처럼 좋을 수도 없다.
기본적인 건 다 Sorcery가 제공하고 그것들을 어떻게 사용할지는 내 입맛에 맞춰서 만들 수 있으니!!

권한 관리가 필요한 경우

Devise의 막강한 기능 중 하나가 CanCan, Rolify 같은 녀석들 때문이다.
CanCan은 권한 관리 Gem으로 페이지, Row(DB의 row) 단위로도 권한 설정이 가능하다고 한다. (실 서비스에 써본 적은 없다. 사용하려고 했는데, 커스터마이징을 너무 많이 해야 해서 그냥 하나 만들어서 사용했다)
CanCan은 Object에 대한 권한 관리라면, Rolify는 역할 관리라고 보면 된다. 예를 들자면 ‘유저’, ‘관리자’, ‘스텝’ 등으로 역할별로 권한을 관리할 때 사용하는 Gem이다.
(역시 실 서비스에 써본 적은 없다. Rolify가 등장하기 전에 이런 기능이 필요해서 만들어서 쓰고 있..)

암튼 이러한 녀석들이 공식적으로 Devise에 잘 붙는다고 적혀있고, 많은 사람들이 Devise + CanCan + Rolify 이렇게 트리플 콤보세트로 사용한다.

근데 CanCan, Rolify를 써보니 어랏? 딱히 Devise와의 Dependency가 안 보인다. 즉 Sorcery에서도 사용할 수 있을 것 같긴 한데.. 나중에 시간 나면 한번 해봐야겠다.
혹 해보신 분 계시면 알려주세요~!

정리

Sorcery Devise
소상공인 기업
가난하다 부자다
Screen Shot 2018-04-04 at 11.19.22 PM Screen Shot 2018-04-04 at 11.19.09 PM
로고도 없다 부자는 다르다.
가난해서 Boiler못킨다. 돈 많아서 Boilerplate가 빵빵하다
가난해서 감출게 없다. 많은 부분들이 감추어져 있다.
그래서 커스터마이징이 쉽다. 그래서 커스터마이징이 어렵다.
github wiki가 아주 깔끔하게 정리가 되어있어서 다른 문서 볼 필요가 없다.
Boilerplate와 설명까지 다 빵빵하다.
github wiki 또한 보기 어렵게 되어있다.
공식 문서는 API만 제공되고, Usage는 찾기 힘들다.
Boilerplate가 있긴 하지만 설명도 없고, Boilerplate를 어떻게 사용해야 하는지 알려주는 문서 또한 없다.
github wiki 페이지 수가 25개로 아주 깔끔하게 되어 있다.
(내가 만들거나 기여한 페이지들도 몇 개 있..읍읍)
github wiki 페이지 수가 130개다. 역시 부자는 다르다.

Sorcery를 오랫동안 사용하기도 했고, 기여도 해서 그런지.. 나도 모르게 글 자체가 Sorcery에 조금 더 편향되게 쓰여진것긴 한데.. 사실 아주 오래전 Devise를 주제로 글을 썼었다. 그것도 2개나! (언제까지 restful-authentication을 쓸것인가! devise도 써보자!devise에서 sign_out시 서버가 기절할 경우. (Ruby Or Rails Bug인듯))
블로그 이사하면서 양식이 다 깨져서 지금은 내용을 알아보기 힘들지만, 어쨌든 썼었다!

아, 그게 중요한 게 아니고.. 흠흠
둘 다 모두 검증된 Authentication 툴이니 믿고 사용하시길

Contributor가 10개가 되었다.

2일전에 오픈소스에 PR을 날렸었다.
그리고 어제 저녁에 Merge가 되었다.

Screen Shot 2018-03-31 at 11.42.55 AM

며칠 전 Github 상단에 Pull Requests가 있는걸 첨 알았다.
맨날 회사 계정으로 접근하고, 회사 Repository만 접근하다보니 몰랐었다.

Screen Shot 2018-03-31 at 11.45.12 AM.png

 

Merge된 PR을 보고있다 문득 상단의 Pull Requests가 생각나서 눌러서 찬찬히 둘러보았다.
크고 유명한곳에 PR을 날린적도 있었고, 심지어 merge도 될번했던것도 2개나 있었는데 2개 모두 Owner가 남긴 코멘트를 늦게 보는 바람에 물건너가버렸다.

그렇게 하나하나 보다가.. 생각보다 Contributor로 된게 많은것 같아 세어보니..
이번에 머지된게 10번째였다!!

이때까지 오픈소스에 총 28개의 PR을 날렸었고, 3개가 오픈상태, 25개가 닫힘상태
25개의 닫힌 PR중 18개가 merged
생각보다 merged되는 확률은 높은것 같으나, 생각보다 PR수가 적어서 놀랐다.
아마 이슈를 남기는것까지 같이 생각해서 PR을 많이 날린줄 알았나보다.

이 정도면 많은건지 적은건지 모르겠지만, 개인적으론 적다고 생각하고..
앞으로 기회가 있다면 더 많은 기여를 하고싶다.

어쨋든 10번째 Contributor가 되었다.

스펙 짤때마다 유혹 당한다

해결책을 제시하는 글이 아니라, 문득 단상이 들어 그냥 생각없이 막 쓴것입니다.

 

오픈소스에 코드를 수정해서 PR 날렸다.
창피하지만 코드를 수정해서 PR날린건 실로 오랜만이다.
맨날 문서만 수정해서 PR 날렸는데..
이번엔 스펙도 같이 작업해서 PR 날렸는데 왠지 부족한것 같아 찜찜한 생각이 들었지만 딱 이 정도가 합리적이라는 생각에 그만 두었다.

솔직히 사람들에게 얘기할 수 있을 만큼 TDD, BDD등을 다양하고 깊게 해보진 않았다.
(컨퍼런스나 밋업 가면 다들 완벽하게 스펙 설정하고 개발하는것 같던데.. 부럽고 나만 도태되는듯해 자괴감에 빠진다. 지구의 모든 개발자중에 나만 스펙 짤 시간이 없나보다.)

하지만 몇 번 안되는 경험에 비춰보면, 매번 스펙을 짤때마다 느끼는건데, 어디까지 짤것인가? 이건 항상 고민이된다.
사실 이러한 고민은 처음 TDD를 시작했던 10년도 전에 했던것이고 그때 나름의 결론을 도출해냈음에도 불구하고 멍청해서 그런지 매번 할때마다 고민을 하게 된다. 아니 유혹을 당한다.
‘좀 더 안전하게 짜야지, 에이~ 그럼 이 케이스는 어떻게 검증할꺼야?’ 등의 생각들이 나를 유혹한다.

스펙을 짠다는것 자체가 ‘안전’하게 개발하기 위함이라  ‘좀 더 안전하게, 촘촘하게’ 즉 수비적인 사고로 짜게된다.
그러다보니 어느덧 나도 모르게 끝 없이 스펙의 골짜기로 빠지기 십상이다.

결국은 가이드가 있거나, 많은 경험 말고는 해결책이 없는걸까?
하긴.. 인생사 전부 마찬가지구나.

UX디자이너 채용한다지만, 실제론 UX디자이너가 채용되지 않는 상황

이미지 출처: https://www.haikudeck.com/ux-designer-art-and-design-presentation-1VktYIu7sD#slide0

디자이너 채용 공고를 쓸려고 다른 회사들은 어떻게 하고 있나 하고 살펴보니, 대다수 타이틀이 “UX/UI 디자이너”

이걸보고 들었던 단상들

– UX 디자이너의 의미가 UX까지 가능한(즉 섭렵한) 디자이너일텐데
기업은 정말로 UX까지 가능한 디자이너를 뽑을려는 의미로 하는걸까?
아니면 그냥 “웹(모바일) 디자이너”의 의미일까?
(“UX까지 가능한 디자이너가 뽑히면 좋겠다”라는 의미로 썻다는건 알겠다. 하지만 그런 의미라면 제목이 아닌 우대사항에 적는게 적절한게 아닌가?)

– 수많은 회사가 UX디자이너를 채용하는데, 정말로 그 만큼 UX 디자이너가 있을까?
그렇다면 나 혼자 뻘 생각한거지만, UX 디자이너가 많아지는건 기뻐할일!

 

만약 그렇지 않다면..

– UX의 일부를 안다고 UX 디자이너라 칭할 수 있는걸까?
알파벳 외운다고 해서 영어 할 줄 안다고 말할 수 없듯이..
(끝이 없는 분야이기 때문에 ‘전부’를 알 수 없다. 하지만 일부를 아는것과 엄연학 격의 차이가 있다.)

– “UX”라는 분야가 그리 만만한것인가?

– 이제는 정말 마케팅 용어인건가?

– 아니면 이제는 GUI디자이너 뽑을때 UX를 옆에 붙이는게 당연한건가?(트랜드인가?)
트랜드라고 당연한건 아닌데.

– UX/UI 디자이너 잡타이틀이 트랜드라면,
진짜 UX 디자이너를 채용하려는 입장에선 UX디자이너와 UI디자이너를 구분하기가 힘들고,
이렇게 되면 최종적으로는 UX디자이너가 피해를 입게 된다.

– “UX나~ UI나~ 뭐 비슷한거, 그게 그거자나?” 라는 의식이 업계를 지배하면
각 분야를 열심히 판 디자이너 입장에선 어이가 없을뿐이다.
결국 UX, UI디자이너 모두 피해를 입게 된다.

– 그리고 채용공고의 타이틀에 UX를 걸었으면, 사측은 책임을 져야한다.
UX타이틀이 있으면 실무에서 당연히 UX를 해야지.

– 누가보면 UX 전문가인줄 알겠네.

더 깊게 들어가서 그 원인에 대해서 생각하는 바를 적으려했지만,
자칫하면 오해를 살 민감한 내용들이라.. 아래 결론 정도로 정리 및 마무리.

결론
사측에서 UX 디자이너를 채용한다고 공고하고,
구직자는 UX 디자이너로 지원하여 채용되었는데,
구직자는 실제론 UX 디자이너가 아니고,
다행스럽게도 업무에는 UX가 없고..

npm ‘kik’사건을 얘기하는 페북의 글과 코멘트를 보고..

블로터의 “11줄의 코드, 인터넷을 패닉에 빠뜨리다(http://www.bloter.net/archives/253447)”

Screen Shot 2016-04-04 at 2.45.50 PM

kik 홈페이지 캡쳐

흠.. 오늘의 뜨거운 감자는 요 녀석인거 같은데..
본문 글도 코드 라인을 강조하고 있고, 페북에서 공유된 글 및 글의 코멘트에도 코드 라인에 대해서 비아냥거리는 사람이 있던데..
이들 중에 실제로 한 줄짜리, 두 줄짜리 패키지 코드를 봤다고 말하는 사람은 없었다. 그리고 실제로 찾아서 본 사람도 없을 것이다.

모두의 예상처럼 거지 같은 패키지일 수 도 있다.
근데.. 단순히 코드 라인 수로 코드의 퀄리티를 얘기한 건.. 어거지 아닌가?
자 그럼 구구단 코드를 1,000줄로 짠 거랑, 1줄로 짠 거랑 비교하면..
1,000 줄인 코드가 훨씬 훌륭한 것인가?

코드 라인수는 중요하지 않다.
해당 코드가 나오기까지의 많은 고민과 경험이 중요한 것이다.

 


 

바퀴 만드냐 사용하냐 하며 싸우는 분들 보고..
실소가 나온다. 너무나 오래 묵혀서 묵은내만 나는 소재거리를 가지고 얘기하다니 ㅋㅋ
내 생각은 아래와 같다.
그냥 상황에 맞게 쓰면 된다.
오픈소스 중에 개발하려고 하는 것과 동일한 패키지가 있고 라이센스가 문제없으면 사용하고
수정할 부분이 있으면 수정해서 사용하고
맘에 안 들거나 기능상 문제가 있으면 다른 걸 찾거나 만들면 그만이다.
“있는 바퀴를 쓰거나”, “바퀴를 만들거나” 이렇게 두 가지의 선택지만 있는 게 아니란 거다.
중요한 것은 기획한 의도대로 기능이 동작하고, 개발하기 편하며, 유지 보수도 좋은 걸 선택하는 거다.
그게 있는 바퀴를 사용하는 걸 수 도 있고, 새로운 바퀴를 만드는 걸 수 도 있다는것이다.