회사를 고르는 기준

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

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

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

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

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

그렇다면 뭘 배우는건가?

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

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

Advertisements

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년도 전에 했던것이고 그때 나름의 결론을 도출해냈음에도 불구하고 멍청해서 그런지 매번 할때마다 고민을 하게 된다. 아니 유혹을 당한다.
‘좀 더 안전하게 짜야지, 에이~ 그럼 이 케이스는 어떻게 검증할꺼야?’ 등의 생각들이 나를 유혹한다.

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

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

기획자님. 복잡한 기능 요구시 최소한의 테스트 케이스는 작성해주세요

기획자가 복잡한 기능을 글(혹은 문서)로 써왔다.
근데 이 기능을 수식화(알고리즘) 하는 작업은.. 개발자가 해야하는 걸까? 기획자가 해야하는 걸까?

당연히 개발자가 수식화하겠지?
그럼 개발자가 수식화해서 코딩을 했다치자.

실제로 제대로된 결과값이 나오는걸 기획자가 검증할 수 있을까?
결과값이 ‘모’아니면 ‘도’처럼 제한되어 있다면 쉽게 검증하겠지만..
파라미터가 여러개고, 결과값 또한 여러 가지라면?

개발자가 테스트 코드를 작성했다고 하지만,
그건 개발자가 만든 것이다보니 기획자의 의도가 투영이 안되었을 수도 있다.

파라미터 A가 ‘1’이고, 파라미터 B가 ‘철수’면
기획자의 의도대로는 ‘꺄~~~ 조인성!!’이 나와야 하지만
실제 작성된 코드로는 ‘송혜교 겁나 이뿌다’가 나올 수도 있다는 얘기.

그 겨울 바람이 분다. 조인성

결국은 기획자가 QA를 해야하는데, 그럼 수식은 기획자가 짜야하는걸까?
그건 아니다.

이때까지(고작 11년 밖에 안되는 짧은 시간이지만) 경험에 비추어 보면,
대부분의 경우 기획자는 그냥 툭 던지고 가버린다.

예를들어 지하철 노선도 프로그램을 만든다고 치자.

기획자는 “‘길찾기’기능 필요해요~”라고 툭 던지고 가고..
개발자는 그냥 열심히 만든다.
열심히..
뚝딱뚝딱..
밤을 새가며
키보드 부셔져라
코딩한다.
그래서 완성했다.

근데 ‘길찾기’ 검증은 어떻게 하지?

‘그걸 기획자가 왜 검증해?’라고 생각했다면
난 되묻고 싶다. ‘당신 기획자 맞습니까?’
제대로 동작하는지 당연히 확인해야지.

소소한것들은 잘도 쪽쪽 찝어서 테스크 생산 해주시는데 (예를들어 버튼이 좌측으로 1px 밀려있다. 응? 이건 디자이넌가? 암튼 뭐 이런것들)
복잡한 기능의 ‘검증’은 그냥 개발자를 믿어버리는(떠밀어버리는)것 같다.
종종 ‘검증’을 아에 잊어버린 것 같다고 느낄 때도 있다.

위에도 썼지만 기능을 기획한 사람이 검증도 할 수 있어야 한다.
옛말에 결자해지라고.. 쿨럭;;

그러므로 ‘이게 좀 복잡한 기능이다~’ 라고 생각이 들면 테스트 케이스를 미리 만드는것이 바람직하다.
만들기 귀찮다고?
그래도 만들어야한다. 우리는 완성도 높은 제품을 만드는 공통 목적을 가진 팀이 아닌가?

개발자 믿는다고?
개발자는 기본적으로 커뮤니케이션 능력이 떨어지는 경우가 많고, 기획서(암호문)를 구독(해독)해서 이해하는 능력도 떨어지는 경우가 많다. (이건에 대해서 별도의 포스팅을 할려고 하는데.. 뭐 봐서)
분명 서로 오해하는 경우가 생긴다.

“개발자를 이해시키면 안되요?” 라고 생각할 수도 있다.
개발자가 이해를 해야 개발에 들어갈 수 있으므로 설명은 당연히 해야하는 것이다.
기획서 휙 떤져주고 가면 안된다.

네비게이션 길찾기 처럼
파라미터와 결과값이 너무 방대한 경우라 하더라도 테스크 케이스는 만드는것이 좋다.
간략하게 본인집과 동사무소가는길, 본인집과 시골집가는길 등등으로 말이다.

만약 테스트 케이스 만들기가 너무 막막하다면
개발자에게 도움을 요청해서 함께 만들어 보는것도 괜찮은 방법이다.

개발시 테스트 케이스가 있다면
개발자는 불안감 없이 개발할 수 있고(검증을 믿을 수 있으니깐)
기획자 또한 빠른 시일내에 제대로 된 프로그램을 받아볼 수 있게 될 것이다.

가장 중요한 것은, 검증은 기획자만 하는게 아니다.
기획자, 디자이너, 개발자 등 팀원 모두가 함께 해야하는 것이다.
소소한 것부터 복잡한 기능까지 모두 함께 하는 것이다.
우리는 완성도 높은 제품을 만드는 공통 목적을 가진 팀이고 거기서 보람을 느끼는 족속들이기 때문이다.

“팀웍이라는게 뭐야?
그저 도와주고, 막아주고 그런걸로 되는거야?”

“그렇게 생각하는 녀석들도 있겠지만 말야,
나에겐 입에 발린 말이라는 생각밖에 안들어.

각자가 자신이 할 수 있는 일을 죽을 각오로 한 뒤에,
‘난 다했다. 다음은 네 차례다. 못하면 죽여버릴거야!’
라고 말할 정도의 기합이 있고서야 비로써 팀웍이라는게 형성되는게 아닐까?

그렇게 생각하면 우리는 각자 한 마리의 외로운 늑대들이라고 해도 괜찮지 않을까?”

– 원피스, 조로와 쵸파의 대화 中

개발자에게 이런 질문(부탁) 하지마! 제발! 쫌!

본 포스팅은
반말로 작성되어 있습니다.
그리고 개발자 입장으로 편중된 글로 다소 싸가지없게공격적입니다.
그렇다고 맹목적으로 기획자와 디자이너를 까고자 하는 글은 아닙니다.
이 글의 쓴 의도는 기획자와 디자이너가 개발자를 이해하게 되고, 결론적으로 더 완성도 높은 프로덕트를 낼 수 있는데 도움이 되었으면 하는 마음에 쓴 글입니다.

서비스 오픈 할려는데 서버 구축 비용 얼마나 들어?


우녀: 이게 CPU에요?
중남: ㅋㅋㅋ
좌남: 뭐?
출처: http://article.joinsmsn.com/news/article/article.asp?total_id=3436698&cloc=

그럼 난 되묻고 싶다.

  • 평균적으로 한 페이지당 트래픽 얼마나 소모되?
  • 예상하는 UV는?

이 질문에 답할 수 없어?
그럼 그 만큼 서비스 준비를 안 했다는 반증이야.

시장 예측도 안 하고 무슨 서비스를 오픈해.
“일단 오픈부터 하고 보자”라고?
그래 린(lean)하게 가는건 좋아. 근데 이건 린하게 하는게 아니야.

서비스를 빨리 오픈하고자 하는 성급함 때문에
마땅히 준비해야 할 걸 준비 안한거야.

예상 유저수와 백단(서버)에서 어떤 프로세스가 돌아가는지 알아야
서버 스펙과 라인(트래픽)을 정하지.
그냥 서버 나와라 뚝딱 하면, 뚝딱 나오는거 같지? ㅋㅋ

위 질문은 마치 가정주부한테
“상하수도 공사하는데 비용 얼마나 들어?”
라고 밑도 끝도 없이 앞뒤 다 짤라먹고 질문하는거나 마찬가지야.
아니 가정주부가 그런걸 어떻게 알어 -_-;

얘기가 산으로 갔는데 돌아와서..

일단 개발자는 서버구축을 하는 사람이 아냐.
서버구축을 하는 분들이 있어. 우리는 이들을 SE라고 불러.

규모가 작은 회사는 어쩔 수 없이 개발자가 서버 구축도 하겠지만.
우리가 흔히 말하는 개발자의 일은 “소프트웨어 개발”이야.
그런 개발자에게 서버 구축 비용에 대해 물어본다?
근데 트래픽에 대한 준비도 안되어 있다?

그렇다면 이 질문을 한 기획자는 제대로 된 기획자가 아냐.
개발자가 무슨 일 하는지도 모르는데.. 그게 기획자야?
아 그래 그래. 개발자랑 친해서 그냥 참고나 할려고 물어본 거라고?

근데 말이야. 내가 위에 적은 2가지 질문있지.
그거에 대해서 스스로 답할 수 있다면 말이야.
그냥 본인이 직접 호스팅업체 홈페이지가서 견적 뽑아봐.
홈페이지 가면 다 나와있어. 괜히 개발자 괴롭히지 말고 말이야.
확실하게 알고 싶으면 홈페이지 잘 찾아보면 전화번호나 메일 주소가 있거든.
거기에다가 위에 적은 항목들을 말해주면, 그 쪽에서 스펙이랑 라인은 알아서 추천해줌과 동시에 비용도 알려줄꺼야.

사실 우리들도 위 적은 정보들을 이용해서 각 업체 홈페이지들에 접속해서 알아보는거야.

프린터(인터넷)가 안되는데 어떻게 해?

아직까지 이런 기획자, 디자이너 심지어 개발자중에도 있더라.
개발자가 프린터 AS기사님이니?

토너(잉크)가 떨어졌는지, 용지가 떨어졌는지, 종이가 씹혔느지
직접 확인해봐. 그리고 직접 해결해볼려고 좀 해봐.

프린터가 안 잡혀?
프린터 제조사 홈페이지 가면 Driver있거든? 그거 다운받고 설치해

지들은 왕족이고, 개발자는 무슨 하인이냐?
문제만 생기면 다 개발자한테 부탁해.
개발은 언제 하라고?

본인들이 알아서 문제 해결할려고 노력이라도 해봐.
해보고 해보고 해봐도 안되면 그때 도움 요청해.
그리고 도움 요청할때 그냥 도와줘요! 하지 말고.

  • 어떻게 했더니 문제가 생겼다
  • 이러이러한 시도들을 했다
  • 원인은 xx인거 같다.

등등의 정보를 알려줘.
그래야 개발자든 아니든 도움을 받은 사람이 “아 이사람이 이 문제를 해결할려고 노력했구나”라고 생각하고 도와주고, 똑같은 작업 두번 반복 안 하게 되자나.

아.. 이렇게 반문하는 사람이 있을꺼야.
“쉽게 빨리 해결해 줄 수 있는 사람이 있는데, 그 사람한테 부탁해서 빨리 해결하는게 좋지 않냐? 그래야 시간도 아끼고”
그래.. 너의 시간은 소중하고 남의 시간은 안소중하냐?

개발자들은 몰입해서 코딩을 하는데..
하찮은 부탁 때문에 몰입이 깨지고,
그로인해 스트레스 받고,
짜증나지만 이런걸로 짜증내면 속좁은 사람으로 보일까봐 짜증도 못내고..
기껏 해결해줬더니, 또 다른거 해결해 달라고 하질 않나,
고맙다는 말이라도 들을 수 있을라나,
그렇게 더러운 기분으로 일할려고 자리에 앉으면 바로 일이 되겠니?
더군다가 다시 몰입하는게 쉬운 일도 아냐.

가장 지혜로운 해결책은, 각 회사마다 각종 기자재 관리하는 팀이 있을꺼야.
예를들면 총무팀? 이런곳에 문의해.
작은 회사라서 그런거 없다고? 그럼 본인이 해결할려고 노력 좀 해줬으면 좋겠어.

무능한 개발자로 만드는 질문들.

1_(2)

기술에 대한 이해도가 전혀 없이 질문을 하는 경우가 더러 있어.
그럼 개발자들은 대부분 짜증썩인 부정적 대답을 할 수밖에 없다~

“그거 못해요”, “못만들어요” 라는 말만 하게 되기 때문에
개발자의 자존감도 낮아지고.. 주변의 눈치를 보게 되.
무능한 개발자로 낙인 찍히면 누가 좋아하겠어?

“저 개발자한테 물어보면 맨날 안된데, 실력이 떨어지는거 아냐?”
이런 소문 돌까봐 속으로는 끙끙거릴 수도 있다는 말이야.

하지만 우리같이 순진한(?) 엔지니어들은
“기술에 대한 이해도 없이.. 터무니 없는걸 가져와서 만들어 달라고 하는거야!!”
라고 윽박지르거나 자신의 입장을 피력하지 못하는 경우가 대다수야.
왜냐고? 위에 적었자나.. 멍청순진해서 그래 ㅋㅋ

암튼 이런식으로 서로에 대한 감정의 골만 깊어지게 되면
결국 크게 한번 터져 걷잡을 수 없는 파국으로 치닫고 둘은 결혼해서 행복하게 살았습니다.
응? 뭐 암튼 그렇다는거야. 요지는 알겠지?

사람마다 다르겠지만 대다수의 개발자가 그래.
못믿겠다고? 그럼 이때까지 일한 개발자들을 떠올리며 생각해봐.
곰곰히 생각해봤는데 아냐? 그럼 우수한 개발자와 일하고 있는거야.
감사의 마음을 담아서 커피나 한잔 사줘봐봐 ㅋ
개발자들은 대다수 공돌이들이라 커뮤니케이션 능력이 딸리거든
당신은 축복받은거야.

결론은.
기획 및 디자이너들이여 제발 기술에 대해 이해를 하고 기획하고 그림을 그려라!

최소한의 기술은 좀 익히자.

응?

그래. 얘기 나온 김에 좀 더 해보자.
한 자동차 디자이너가 있어.
이 디자이너가 겁니 예술적으로 쌈빡하게 차를 디자인 했어.

그런데 이 사람의 디자인대로 차를 만들면..
엔진 놓을 곳이 없고, 사람은 운전자 한명도 간신히 타며, 에어로다이네믹은 전혀 고려가 안된 차량이 된다면…
이 사람을 디자이너라고 할 수 있을까?
그래 예술가라고 할 수 있을지는 몰라도, 산업 디자이너는 절대 아니라고 생각해.

자동차 디자이너가 LSD의 작동원리와 세팅법, 서스펜션의 bar와 스프링 장력의 관계 등등 같은건 몰라도 되.
하지만 자동차를 디자인하기 위해서 최소한으로 알아야 할 것들이 있는것 아니겠어?
예를들면 FF, FR, MR, RR, 쿠페, 세단 뭐 이런거? (주변에 자동차 디자이너가 없어서 적절한 예인지 모르겠지만..)

웹도 마찬가지야. 최소한으로 알아야 할 것들이 있어.

javascript 바라지도 않어.
html, css코드 작성은 아니더라도 원리 정도는 이해해줘.
코드를 읽을 줄 알면 더 좋지만 여기까지도 안바래.(적어도 나의 경우엔 말이지)
inspector같은 툴도 자유자재로 사용할 줄 알고 말이야.

이 정도도 힘들어? 그럼 개발자 그만 괴롭히고 다른 직업 찾아봐줬으면 좋겠어.

사실 이것들 말고도 수없이 많어. 알고 있지? ㅋㅋㅋ
하지만 이 정도만 할께.
뭐 소스들이 계속 모이면 시즌2로 돌아올 수도 있지만, 안그랬으면 좋겠어.

아무튼, 제발 우리한테 이런 무리한 요구는 하지 말아줘!!

우리는 톰 크루즈도 아니고, 톰 크루즈가 되고픈 마음도 없어!