kivol-blog - Tumblr blog

kivol-blog · 5 years ago

Text

재택근무 후기

0. 대략 2월 마지막주부터 재택근무로 전환했으니 두 달 조금 넘는 시간동안 재택근무를 해왔던 것 같다. 우리 회사같은 경우에는 그 중 앞의 2주정도는 재택근무 권장, 그 다음 한달정도는 재택근무 의무, 그리고 (지금까지도) 재택근무 권장 정도로 운영되고 있었다. 사실 우리 회사는 코로나 이전부터 무제한의 재택근무와 휴가를 보장해 왔는데, 나는 그 동안 재택근무보다는 출근을 해서 루틴을 다잡는 것을 좀 더 선호하는 편이긴 해서 오랫동안 재택근무를 한 것은 이번이 사실상 거의 처음이다. 나는 오늘(5/6)부터 다시 출근모드로 돌아가게 되었는데, 이에 그간 느꼈던 것을 아무렇게나 두서없이 한 번 정리해 보고자 한다.

　 1. 일단 나는 우리 회사가 제공하는 무제한의 재택근무를 복지로 생각해 본 적이 없다. 면접이나 다른 상황에서 지원자 등이 재택근무를 복지로 받아들이는 경우를 볼 때가 있는데, 나는 사견을 전제로 이야기하면서 부정하는 편이다. 왜냐하면 재택근무든 뭐든 모든 방법은 ‘생산성‘이라는 목적함수의 최적화를 위한 수단이기 때문이다. 나는 사측(경영진)의 입장에서 이러한 정책을 ‘선택’했는데, 이유를 정리해 보면 다음과 같다:

1) 어차피 규율을 만들어도 그 규율때문에 생산성을 잃는 사람이 나온다. 이 선택에는 +와 -의 두 측면이 모두 있게 된다. 애초에 해당 규율이 필요 없는 사람으로 팀을 구성하는 것이 더 효율적이다. 2) 규율을 만들게 되면 그 규율을 감시하기 위한 매니지먼트 코스트가 든다. 3) 이는 괜찮은 인재를 붙잡아 둘, 혹은 끌어올 수 있는 인력으로 작용하며 이는 재무재표에 계상하기는 어렵지만 이득으로 돌아온다. 4) 나는 팀원들이 규율을 지키는지에 대한 매니징을 하고 싶지 않고, 하게 되면 나 자신의 생산성에 큰 악영향을 미치게 된다. 이는 팀에 큰 손해이다.

　 2. 나는 결국 모든건 생산성을 위한 수단이라고 생각하는 편이고, 그것이 이루이지지 않는다면 폐지하는 것이 낫다고 생각한다. - 물론 폐지할 때 반발을 누그러트리기 위한 아주 치밀한 계획이 있어야 할 것이다 - 그리고 재택근무가 그 생산성을 최적화하려면 어떤 조건과 전제들에 필요한지 분석을 해볼 필요는 있다. 기본적으로 회사에서 하는 행동들은 일로 이루어진 집합이다. 그러면 이 일을 한 번 환원주의적으로 분석해 본다. 일단 기본적으로 일은 혼자서 하는 일과 타인과 같이 하는 협업으로 나뉜다.

　 3. 일단 혼자서 하는 일의 경우 재택근무가 이루어지기 위한 필요조건은 대충 다음과 같다: 1) 일을 하는 툴들이 회사에만 깔려 있는 상용 소프트웨어가 아닌 편이 더 낫고, 2) 내부 툴은 퍼블릭 인터넷으로 접근이 가능하거나 VPN을 통해 접근할 수 있어야 한다. 우리 회사는 일을 하는데 상용 소프트웨어를 거의 쓸 일이 없거나 맥북 이용자의 비율이 높고, VPN 클라이언트로 접속하기만 하면 어느 장비에서든 작업을 할 수 있는 환경과 매뉴얼이 갖춰져 있다. 일단 이것부터가 잘 갖춰져 있지 않은 회사들은 재택근무에 곤란함을 겪게 되는 것 같다. 장비들에 쓸데없는 보안소프트웨어나 감시장치가 깔려있다든지, 무조건 RDP를 사용해서 회사 컴퓨터에 엑세스 해야만 한다든지 하는 경우들이다.

　 4. 협업의 경우에는 커뮤니케이션 방법이 중요해진다. 커뮤니케이션 수단을 동기적(synchronous) 수단과 비동기적(asynchronous) 수단으로 나눠보자. 전자는 전화나 오프라인 회의, 슬랙콜-행아웃-줌, 페어프로그래밍 등의 수단이 해당되고 후자는 이메일, 슬랙, 메신저 등의 수단이 해당된다. 전자의 ��점은 즉각적인 응답과 해결이기 때문에 이슈를 거는 사람의 편의에 맞춰져 있고, 후자의 장점은 이슈를 받는 사람이 일의 우선순위와 어떤 것에 집중할지를 스스로 선택할 수 있어 콜을 받는 사람의 편의에 좀 더 맞춰져 있는 것 같다.

　 5. 우리 회사의 문화가 어딘가에 명시되어있지는 않지만, 우리 엔지니어링 조직의 경우에는 비동기적 수단을 디폴트로 잡고 동기적 수단을 보완재로 잡는 경향이 있는 것 같다. 이슈 콜을 받는 사람을 좀 더 배려하는 것이다. 물론 비동기적 수단만으로는 생산성이 줄어들 때가 있다. 예를 들어 어떤 이슈에 대한 핑퐁의 횟수가 많아지게 되면 작업자의 입장에서도 어떤 일에도 집중할 수 없게 된다. - 전산용어로 번역하자면 비동기 이벤트 콜백을 위한 컨텍스트 스위칭 코스트가 커진다는 뜻이다 - 그래서 개인적으로 동기/비동기 중 어떤 수단을 택하냐를 결정할 때는 보통 핑퐁의 횟수로 판단하는 편인 것 같다. 짧은 시간 안에 많은 핑퐁이 예상되는 경우 동기적 수단을 택하거나, 비동기적 수단으로 시작했더라도 동기적 수단으로 전환하게 되는 것 같다. (핑퐁 하다가 아 이거 길어지는데 전화로 얘기하시죠 한 경험은 누구나 있을 것이다..)

　 6. 다만 모두가 재택근무를 하게 되며 불편해진 사소한 측면이 있는데, 온라인을 통한 동기적 커뮤니케이션시 그림을 그리며 설명하는게 약간 불편하다는 점이다. 비동기적인 커뮤니케이션의 경우 PPT나, 하다못해 노트에 그림을 그리고 사진을 찍어 올릴 수 있는데 행아웃이나 줌의 경우 이것이 약간 마땅치 않았다. 코로나 이전에는 동기적 커뮤니케이션이 필요할 때 보통 오프라인 회의를 미리 잡는 것을 선호해 왔고 팀원들 각각이 오프라인 회의가 잡힌 날에는 재택근무를 하지 않는 식으로 컨센서스를 맞춰왔는데, 그 때는 보지 못한 단점인 것 같다. 집집마다 칠판이 있는 것도 아니고 마우스나 트랙패드로 그림 그리는 것도 너무 고된 일이고.. 좋은 솔루션이 나오면 좋겠다.

　 7. 개인적인 측면에서 보면.. 출근을 할 때 되도록이면 일어나서 샤워를 하고, 잠옷 대신 의관을 정제한 상태에서 자리에 앉으려고 노력을 했다. 이건 확실히 개인차가 있을 것 같으나, 내 개인적으로는 출근길이 어떠한 리추얼로 작용하여 몸과 마음의 모드를 바꿔주는 역할을 했다고 생각하여 집에서도 비슷한 루틴을 따라 보았다. 이는 어느 정도 성공적인 편이었는데, 하다 보니 빌드나 패키지 설치, 배포 등으로 인해 10~30분 사이로 시간이 뜨는 이벤트시에 잠깐 침대에 누워있는다거나 하는 식으로 양쪽의 장점을 취하는 방식으로 발전할 수 있었다.

　 8. 두 달 동안의 재택근무 결산을 해 보면, 약간 불편했으나 개인적으로도 팀으로도 생산성이 크게 저하되었다는 느낌은 들지 않았다. 다만 같이 모여서 프로젝트의 큰 그림과 방향성을 논의할 기회가 조금 줄어들게 되었고, 그를 위한 온라인 회의에서의 집중력이 약간은 저하된다는 느낌이 있었다. 화상회의를 위한 솔루션들도 음성의 처리같은 면에서 아직은 많이 아쉬웠는데, 여러 명이 동시에 이야기를 하기 어렵다거나 네트워크의 미세한 딜레이들이 생각보다 상당히 신경쓰인다거나 하는 측면들이다. (근)미래에 회사 오피스가 필요 없어지거나 의미를 크게 잃는 날이 올 것인가 이런 생각을 많이 해 보았는데, 아직은 재택근무로 모든 것이 완벽히 대체되는 것은 쉽지 않을 것으로 생각된다.

　 9. 마지막으로, 내가 두 달동안 재택근무를 하는 동안 아내도 회사에서 비슷한 기간을 재택근무 모드로 돌리고 있었다. 그래서 우리 부부는 본의아니게 계속 떨어지지 않고 붙어있으면서, 마치 집에서 두 달짜리 신혼여행을 하는 기분을 내게 되었던 것 같다. 보통은 쉽게 할 수 없고 계획되어 있지 않았던, 하지만 너무나 행복한 경험이었다. 그 기간동안 보기 싫은 내 모습도 많았을텐데 싫은 소리 한 번 안해 준 아내에게 진심으로 감사함을, 당신과 결혼하게 되어 너무나 행운이라는 이야기를 전하고 싶다.

0 notes

kivol-blog · 7 years ago

Text

웹 개발 커리큘럼 2018 버전을 공개합니다

0. 회사를 창업한지 벌써 6년이 넘게 되었고, 정확히 세어 보지는 않았지만 세자리수 이상의 개발자들을 인터뷰 했을 것으로 생각됩니다. 그 과정에서, 특히 주니어급의 개발자를 인터뷰 하며 자주 느끼는 것들이 있었��니다. 왜 어떤 개발자는 해당 언어나 프레임워크의 튜토리얼 이상의 과업을 제대로 수행하지 못할까요? 왜 어떤 개발자는 인터넷 어플리케이션 을 만드는 프로그래머라면 기본적으로 알아야 할 개념과 구조를 알지 못할까요? 그런 것들을 잘 아는 사람과 모르는 사람의 차이를 가져오는 것은 무엇일까요?

1. 저는 그런 개발자들이 좋은 개발자로 성장할 가능성을 주기 위해서는, '프레임워크 예제 따라하기'를 벗어나 어플리케이션 프로그래머가 알아야 할 좀 더 일반적이며 근본적인 사항들을 알려주고 공부할 방향을 잡아줄 수 있는 체계적인 커리큘럼이 필요하다는 생각을 오랫동안 했습니다. 그런 고민의 일환으로, 저희 회사는 창립 당시부터 지금까지 계속 신입 개발자의 빠르고 안정적인 성장을 돕기 위한 교육 커리큘럼을 운영하고 있습니다.

2. 이러한 방식은 스타트업과 스타트업에서 커리어를 시작하려는 개발자 모두가 윈윈할 수 있는 방식이라고 생각합니다. 먼저 회사 입장에서는 더 적은 비용으로 좋은 개발자를 키워서 함께 성장해 나갈 수 있다는 장점이 있습니다. 그리고 개발자 입장에서는 스타트업의 (상대적으로) 불확실한 미래에 대한 리스크를 줄이며, 앞으로 어느 회사로 이직하게 되든 장기적인 커리어의 전망을 더 밝게 만들 수 있는 장점이 있다고 생각합니다.

3. 저는 그 중 웹 개발 커리큘럼을 2016년 초에 공개하였었습니다. 그리고 최근 신입 개발자 분들을 다수 모실 상황이 되어 커리큘럼을 최신 트렌드에 맞추어 2018버전으로 한 번 리뉴얼 하였습니다. 2016년 버전에 비해 달라진 부분은 다음과 같습니다: - ES6 이후의 새로운 문법을 반영하였습니다 - 최신 웹 기술을 소개하는 파트에서 Polymer, SVG, Websocket, OAuth가 빠지고 대신 Vue.js, Webpack, GraphQL, Jest와 Puppeteer에 대한 소개와 퀘스트가 들어갔습니다

4. 꼭 Knowre의 개발자가 아닐지라도, 이 커리큘럼이 많은 회사나 개발자들에게 도움이 되어 한국의 개발 생태계에 좋은 영향을 미칠 수 있다면 더 없이 기쁜 일일 것 같습니다. 그런 취지로 리뉴얼 된 커리큘럼 역시 깃헙을 통해 공개하고자 합니다.

https://github.com/Knowre-Dev/WebDevCurriculum

ps. 관련하여 책 집필 역시 준비하고 있습니다. 언제 나올지는 의문이나 최대한 빨리 열심히 쓰도록 하겠습니다 ㅠㅠ

pps. 현재 Knowre의 제품을 담당할 서버 개발자를 모시고 있습니다. 다음의 링크를 참조해 주세요. 많은 개발자 분들의 지원과 추천을 기다리고 있습니다!! 신입: https://www.wanted.co.kr/wd/10386?referer_id=143226 일반: https://www.wanted.co.kr/wd/10385?referer_id=143226

3 notes · View notes

kivol-blog · 7 years ago

Text

좋은 기술 인터뷰 질문은 어떤 질문인가

0. 막 회사의 명성과 평가가 대단해서 가만히 앉아있어도 좋은 사람들이 지원을 하고 그 중에 대충 골라서 모셔도 어느 정도의 퍼포먼스가 보장된다면 참 좋겠지만, 대부분의 경우는 그렇지 않다. 이미 많은 활동이나 레퍼런스 체크로 검증된 시니어가 아니라 신입~주니어에 해당하는 개발자를 뽑을 때는 더더욱 그렇다.

1. 페북에 일전에 인터뷰에서 심오한 알고리즘 문제를 내는 것은 좋은 방법이라고 생각하지 않는다는 이야기를 한 적이 있는데, 물론 그런 인터뷰를 보는 것이 실력과 양의 코릴레이션이 있겠지만, 양의 코릴레이션으로 따지면 하다못해 수능 수학문제를 내는 것도 업무 퍼포먼스와 상관관계가 없지는 않을 것이다. 우리는 더 높은 상관관계를 얻어낼 수 있는 면접 방식과 질문을 찾아야 한다.

2. 스피드퀴즈 방식의 질문 역시 좋은 가늠자는 아니라고 생각한다. 입사 프로세스는 객관적인 1차원적 수치로 사람을 줄세우는 방식으로 진행할 수 없기 때문이다. 일전에 번역했던 이런 글과 같은 극단적인 케이스가 아닐지라도, 어떤 지식을 아느냐 모르느냐의 리스트를 만드는 것 보다는 좀 더 그 사람을 깊게 알아볼 수 있는 방식이 있었으면 좋겠다고 생각했다.

3. 그러한 고민 끝에 우리 회사의 인터뷰 질문은 자연스럽게 이런 방식으로 정립되었다. 어떤 주제를 잡고, 쉬운 개념에서부터 계속 확장시켜 질문을 던지며 그 사람의 기술적 깊이를 알아보는 방식이다. 예를 들면 서버 개발자를 인터뷰한다고 할 때, 다음과 같은 식으로 질문을 이끌어나갈 수 있을 것이다.

나: 해시 함수에 대해 알고 계신가요? 아시는 대로 설명해주실 수 있을까요? 후보자(이하 후): 데이터를 일정한 규칙에 의해 암호화 해서 일정 길이의 문자열로 압축해 주는 함수라고 알고 있습니다. 나: 해시 함수의 예로는 어떤게 있을까요? 후: MD5나 SHA같은 것이 있습니다. 나: 혹시 SHA 함수를 어떻게 구현하는지 알고 계신가요? 후: 잘 모르겠습니다. 나: 그렇다면 본인께서 해시함수를 직접 구현하신다면 어떤 식으로 구현하실 것 같으신가요? 후: (잠시 생각한 후) 바이트의 숫자들을 배열로 만든 후 몇 바이트씩 덧셈, 뺄셈, 곱셈같은 연산을 해서 그걸 256으로 나눈 나머지를 가지고 만들 것 같습니다. 나: 감사합니다. 다시 현실적인 이야기로 돌아와서, 해시 함수는 어떤 곳에서 쓸 수 있을까요? 가장 일반적인 예를 한 가지만 들어보신다면? 후: 서버에 비밀번호를 저장할 때 사용합니다. 나: 서버에 비밀번호를 저장하는 과정을 좀 더 자세히 설명해주실 수 있나요? 후: 사용자가 입력한 평문에 해시함수를 적용하여 나온 결과를 저장하고, 나중에 사용자가 로그인할 때 역시 해시함수의 함수값과 저장된 값을 비교하여 맞는 비밀번호인지를 알 수 있습니다. 나: 그런 방식으로 충분한 보안이 될까요? 후: 추가적으로 Salt라는 것을 사용한다고 알고 있는데, 자세한 것은 잘 모르겠습니다. 나: 인위적으로 특정한 해시값이 나오도록 입력을 만들 수 있을까요? 후: MD5의 경우에는 그것이 가능하기 때문에 더이상 쓰지 않는다고 알고 있습니다. 나: 만약 입력의 비트를 바꿔가며 모든 가능성을 순서대로 시도해보면 어떻게 될까요? 후: 그러면 시도를 정말 많이 한다면 가능할 것 같습니다. 나: 그런 방식의 해시함수를 적극적으로 활용하는 분야가 있을까요? 후: (잠시 생각한 후) 잘 모르겠습니다. 나: 블록체인 기술이 어떻게 구성되는지 혹시 알고 계신가요? 후: 대충 들어보긴 했지만 정확한 원리는 잘 모르겠습니다.

4. 이 가상의 문답을 통해 면접자는 후보자가 어디까지를 알고 있는지, 또 프로그래머의 덕목 중에 어떤 것을 가지고 어떤 것을 가지지 못했는지를 엿볼 수 있다. 이 후보자는 대상이 되는 기술을 사용하는 데에는 능숙한 편인 것으로 보인다.(코딩 인터뷰를 통해서도 이러한 성향은 비슷하게 드러난다) 하지만 그 기술의 원리나 내부 구현에 대해 평소 적극적으로 파고드는 스타일은 아닌 것으로 보인다. 그리고 업계의 최신 기술이나 이슈를 적극적으로 찾는 성향 역시 아닐 가능성이 있다고 짐작할 수 있다.

5. 만약 후보자가 저 문답에서 블록체인 기술에 대해 잘 설명했다면, 이후 GPU를 통한 채굴이나 ASIC에 대해 질문을 이어나갈 수도 있을 것이며, 자연스럽게 CUDA 등의 GPU를 이용한 컴퓨팅에 대해 질문할 수도 있을 것이다. 혹은 블록체인을 DBMS 관점에서 비교하며 DBMS에 관한 질문을 해 볼수도 있을 것이다. 그리고 이러한 과정을 몇 가지 주제에 대해 반복하면 면접이 끝날 때 쯤에는 그 사람에 대해 제법 많은 것을 알 수 있게 된다.

6. 이러한 방식의 단점이 없는 것은 아니다. 무엇보다 면접자가 이러한 질문과 답변을 계속해서 이어나갈 수 있을 정도가 되어야 하며, 이는 많은 준비와 평소의 노력을 필요로 한다. 더구나 면접 자체에 들이는 노력과 시간도 커지기 때문에, 이러한 방식은 고비용-고퀄리티에 속한다고 볼 수 있다. 실제로 디렉터님께서 팀 내에서 추산하신 바로는 탈락한 후보를 포함하여 한 명에게 오퍼를 드리기까지 대략 50 Man*Hr가 들어갔다.

7. 이 비용을 줄이기 위해 챗봇을 만들어서 진행할 수 있는 날이 온다면 좋겠지만 아직은 비현실적인 대안이고, 50 Man*Hr이 커 보이지만 10명이서 오후 반나절을 쓰는 정도이다. 결국 중요한 것은 좋은 사람을 뽑기 위해 이 정도의 시간을 팀이 투자할 수 있느냐의 결정에 달려있다고 생각한다. 채용 실패의 비용이 큰 소규모의 팀이나 스타트업 일수록 한 번 고려해봄직한 방식이라는 생각이 들어, 이 방식을 한 번 공유하고자 한다.

5 notes · View notes

kivol-blog · 7 years ago

Text

자랑글

0. 얼마 전 회사에 크다면 크고 작다면 작은 일이 하나 있었습니다. 스타트업..이라고 하기에는 수백억의 투자를 이미 받아 규모가 커진 어떤 회사에서, 저희 회사 프로덕트 개발팀의 대부분 인원에게 동시에 스카웃 제의를 한 것입니다. 심지어 ��쟁하는 분야도 전혀 겹치지 않는 상황에서의 일이었습니다. 제 업계에서의 경력(12년)이 길다고 할 수 없겠습니다만, 이런 식으로 크지도 않은 한 회사의 대다수 개발자에게 동시에 스카웃 제의를 하는 경우가 있다는 이야기는 들어본 바가 없습니다.

1. 저희 대표님을 통해 해당 회사의 대표분께 연락하여 어찌된 일인지 해명을 들어보았으나 별로 소득은 없었습니다. 그 분은 특정 회사를 타게팅한 적이 없고 지인 추천을 받았을 뿐이라는 이야기를 했으나 그 지인이 누구인지, 왜 본인에게조차 알리지 않고 추천을 한 것인지에 대해서는 제대로 설명하지 못했습니다. 그리고 논리가 곤궁해지자 '애초에 너네가 남고 싶은 회사를 만들면 되는거 아니냐'라는 식의 이야기로 대화는 끝났습니다.

2. 6년 전에 창업을 하고 운영을 해 오면서 많은 사람들이 개발팀을 거쳐갔지만, 저는 떠나겠다는 사람을 억지로 붙잡아 앉히거나 한 적이 한 번도 없었고, 앞으로도 그럴 것입니다. 그리고 역으로도 마찬가지입니다. 언제나 사람은 부족하지만, 그렇다고 해서 이직 의사가 딱히 없는 분을 감언이설로 꼬셔 데려오고 몇개월 후에 후회하며 내보내는 일은 하고싶지 않습니다. 그런 식의 진정성 없는 행동은 그 분의 전 회사에도, 우리 회사에도, 그리고 그 분에게도 큰 피해를 끼치는 것이고, 넓지도 않은 한국 스타트업계 전체의 발전을 위해서도 도움이 되지 않는 일이라 생각하기 때문입니다. 꼼수를 배제하고 고지식할 정도로 투명한 선택만을 하는 괜찮은 팀도 업계에 있고, 그런 회사가 실력으로 성공할 수 있다는 것을 저는 증명하고 싶습니다.

3. 결론적으로는 다행히도, 그리고 정말 감사하게도 스카웃 제의를 받은 분 중 한 명을 제외하고는 모두 노리에 남아 주시는 선택을 하셨습니다. 6년간 많은 노력을 하고 또 실수와 시행착오도 많이 했지만 어쨌거나 '남고 싶은 회사'를 만드는 데에는 성공한 것 같습니다. 만약 타게팅이 있었다면 외부의 시선으로도 좋은 개발문화를 가진 회사로 인정받은 것이니 기쁜 일이고, 저들의 주장대로 Knowre의 많지도 않은 개발자의 상당수가 스카웃 제의를 받은 그 모든게 기막힌 우연이더라도 적어도 좋은 개발자들로 이루어진 팀이 되었다는 사실은 조금이라도 객관적으로 증명이 되었다는 생각이 듭니다.

4. 사실 이 글은 자랑글을 빙자한 광고글입니다. 현재 저희 개발팀에 열려있는 포지션은 다음과 같습니다. 관심있는 분들의 많은 지원이 답지하기를 기대합니다.

제품 엔지니어링 디렉터(관리자급): https://www.wanted.co.kr/wd/5802?referer_id=143226

node.js 서버 개발자: https://www.wanted.co.kr/wd/3244?referer_id=143226

8 notes · View notes

kivol-blog · 8 years ago

Text

테크 스타트업의 CTO로 아직 안망하기 - 6. 에필로그

테크 스타트업의 CTO로 아직 안망하기 - 0. 서문 테크 스타트업의 CTO로 아직 안망하기 - 1. 두 번째 팀원 테크 스타트업의 CTO로 아직 안망하기 - 2. 착한 아이 컴플렉스 테크 스타트업의 CTO로 아직 안망하기 - 3. 지속가능한 개발팀 테크 스타트업의 CTO로 아직 안망하기 - 4. 성장통 테크 스타트업의 CTO로 아직 안망하기 - 5. 평가의 딜레마 테크 스타트업의 CTO로 아직 안망하기 - 6. 에필로그

0. 이 글을 준비하면서 CTO에 관한 많은 글을 찾아보았는데 공통점이 없던 것은 아니었다. CTO는 결국 '기술'을 책임지는 자리라는 것. 다만 이 시리즈에서는 스타트업의 초기에서부터 지금까지의 성장과정을 이야기하려 했기 때문에, 결국 비기술적인 관리와 '사람'에 대한 이야기가 오히려 더 많을 수밖에 없었던 것 같다. '개발팀의 수장이면서 가장 기술적으로 큰 책임과 권한을 지는 자리'가, 엔지니어링 팀이 15~20명 규모가 될 때까지 내가 생각해온 CTO의 정의였다.

1. 사실 이러한 역할이 지속가능하기 어렵다는 생각은 예전부터 해왔다. 일단 나에게 주어진 할 일이 너무 많다는 것이 문제였고, 나 자신이 딱히 대단히 탁월한 관리자의 자질을 가지고있는 것 같지 않다는 점도 문제였다. (엔지니어링쪽은 그래도 그보다는 좀 낫다고 생각한다.) 어느 순간부터 프로덕트의 지나치게 디테일한 부분에 신경을 덜 쓰기 시작했고, 시니어 엔지니어들에게 해당 부분을 위임할 수 있었다. 그러다 보니 내가 하는 업무 중 관리를 제외한 엔지니어링쪽의 실무가 자연스럽게 한가지로 수렴하고 있는 것이 보였다. 그것은 데브옵스였다.

2. 의외로 상당히 오랜 시간동안 우리 서비스는 모니터링도 페일오버도 오토 스케일링도 제대로 설정되어있지 않았다. 또한 디플로이 역시 서버에 직접 들어가서 git pull을 하고 서버를 다시 띄우는 방식이었다. 이랬던 이유는 결국 그런 프로세스에 신경을 쓸 사람이 CTO 뿐이지만 그 자신이 실무에 너무 매몰되어있었기 때문이었다. 마침 코어 라이브러리에 대한 설계 정리가 끝났고 네트워크와 VPN도 얼추 정리가 된 시점이었고, 나는 그 때 비로소 하나의 파이프라인으로 된 CI 프로세스를 준비하기 시작했다. 리포에 푸시를 하면 빌드서버가 테스트를 거친 뒤 도커 이미지를 생성하고 그것을 즉석 생성된 클라우드 서버에 올리는 방식을 제시했다.

3. 파편화되어 돌아가고 있던 기존 서비스들에 이 프로세스를 공통 적용하는 것은 생각보다 지난한 과정이었다. 기존에 돌아가고 있던, 또 중간에 치고 들어오는 서비스 일정과의 충돌 문제도 있었고 파트너사의 이상한 방화벽이나 네트워크 정책과 같은 문제도 있었다. 레거시의 정리도 필요했다. 서버 인스턴스 한 대만을 쓰던 구조를 도커와 여러 대의 인스턴스를 쓰는 구조로 바꾸기 위해서는 로깅이나 세션처리, 캐싱 등 고려해야 할 점이 의외로 많았다. 결국 모든 것이 끝나기까지는 1년 가까이의 시간이 걸렸고, 이 과정에서 깨달은 것이 하나 있었다.

4. 그것은 프로덕트가 어떻게 분화하고 무엇을 만들게 되든 그 과정에 필요한 공통적인 것들은 결국 CTO가 챙겨야만 한다는 것이었다. 그 공통적인 것이 기술스택일수도, 개발 플로우나 프로세스일수도 있다. 중요한 것은 한 엔지니어링 팀에 그런 시스템을 잡아주는 일이 필요하고 그것을 CTO가 해야 한다는 점이다. 만약 그것을 처음에 알았더라면 훨씬 더 편했을까? 나는 그렇다고 생각한다. 첫 프로덕트가 나오기까지는 약간의 시간이 더 걸렸을지 몰라도 그 시간투자를 회수하는 것은 굉장히 빨랐으리라 생각한다. 물론 그러한 공통적인 시스템을 제대로 만들 역량이 회사 초기의 나에게 있었는지는 의문스럽지만.

5. 이렇게 데브옵스 프로세스를 갖춰놓고 나니 그 다음 스텝이 명확해지기 시작했다. 이러한 시스템에 더해 엔지니어링 조직, 회사 전체가 공통적으로 의존하게 될 기술을 생산할 사람들이 있어야 한다는 생각이 들었다. 이 일을 하는 사람들은 프로덕트에 너무 깊게 발을 담그지 않아야 한다. 이를 위해서는 제품과 독립된 별개의 조직이 필요했다. 나는 경영진 회의에서 연구조직의 설립을 제안했고, 나는 이러한 업무에 전념하기 위해 나머지 프로덕트 엔지니어링 조직을 관리하고 이끌 사람이 필요하다고 이야기했다. 이 제안은 받아들여졌다. 엔지니어링 조직으로서의 우리 회사의 개발팀은 이제 또 다른 진화를 준비하고 있다.

6. 이제 이 글도 결론을 낼 때가 온 것 같다. 나는 CTO가 무엇을 하는 역할이냐 하는 오랜 질문에 대해 이렇게 대답하기로 결심했다: "기술 스택의 큰 줄기를 결정하고, 그것의 Best Practice를 찾아 제시하고, 전체적인 개발 플로우와 프로세스를 정립하고, 최대한 그것을 자동화하여 모두의 시간을 절약할 수 있게 하는 포지션. 그리고 더 나아가 제품과 회사에 도움이 될 수 있는 새로운 기술적 비전을 제시하는 사람"

7. 내가 CTO라는 직함을 달고 있는 동안에는 계속 이러한 역할 하에서 방향을 고민하고자 한다. 이러한 가정 하에서 내가 지난 6년간 잘해왔는지를 생각해 보았으나 너무 부끄러워서 생각하는 것을 이내 그만두었다. 그래도 위안인건 최근으로 올수록 나아지고 있는 것 같기는 하다는 점이다. 그래도 이 정도면 어디가서 CTO로든 엔지니어로든 굶어죽지는 않을 것 같으니 다행이다. 글의 앞부분에서 '어디 가서도 1인분을 하는 개발자'를 키우는 것이 목표였다고 이야기한 적 있는데, 과연 나는 1인분은 하는 CTO일까?

8. 사실 그래도 나름 오랫동안 긴 글을 쓴지라 뭐라도 임팩트 있게 마무리를 하고 싶은데 잘 떠오르지 않는다. 아마 이 문장이 그대로 올라간다면 결국 떠올리지 못한 것으로 하고 이 글을 마칠까 한다. 지금까지 긴 글 읽어주신 모든 분들께 진심으로 깊은 감사를 드립니다. 진짜 진심이에요!

(끝)

PS. 현재 Knowre 개발팀에는 주니어 웹 개발자와 제품 엔지니어링을 총괄 매니징할 디렉터 포지션이 오픈되어 있습니다. 주니어 안드로이드 개발자 포지션은 마감되었고, 다른 포지션들도 마감이 임박해올 수 있으니 혹시 관심있으신 분들께서는 다음의 링크를 참조해 주세요!

제품 엔지니어링 디렉터: https://www.wanted.co.kr/wd/5802 주니어 웹 개발자: https://www.wanted.co.kr/wd/3244

[레퍼런스: 이 글을 쓰기 위해 읽었던 많은 글 중 한국어로 된 일부] http://www.zdnet.co.kr/column/column_view.asp?artice_id=20140630075815 https://www.slideshare.net/lqez/ss-36301654 https://brunch.co.kr/@leehosung/40 https://minorblend.com/cto-vs-vp-engineering-4a36124c098c http://woowabros.github.io/woowabros/2017/05/15/woowa_techcamp.html

4 notes · View notes

kivol-blog · 8 years ago

Text

테크 스타트업의 CTO로 아직 안망하기 - 5. 평가의 딜레마

0. 인사평가만큼 사람들마다 극과 극으로 견해가 갈리는 요소도 없는 것 같다. 어떤 사람은 극단적으로 평가 자체가 무의미하다고 주장하기도 하고, 어떤 사람은 철저하게 수치화되고 체계화된 평가시스템을 통해 사람들의 퍼포먼스를 측정해야 한다고 주장하기도 한다. 대부분의 문제에 대해 그렇듯이 나는 그 극단 사이 어딘가에서 어정쩡한 타협을 하기로 결심했다.

1. 우리 회사의 평가시스템은 대단히 정교하거나 한 것은 아니고 4년 이상의 기간동안 큰 변화 없이 이어져내려왔다. 해보니 큰 문제도 없고 딱히 대안도 없기 때문이기도 한데, 360도 다면평가라 불리는, 대략 이런 방식이다: 1) 피평가자가 해당 반기에 본인과 업무적으로 밀접한 관련이 있던 사람들과 상대적으로 밀접한 관련까진 적었지만 자신을 평가할 정도는 되는 사람을 매니저와 함께 정한다 2) 이 사람들과 피평가자의 매니저(프로덕트 매니저와 기능조직의 매니저)를 합쳐 설문을 돌린다 3) 설문에는 이 사람의 퍼포먼스는 어떤지, 동료들을 존중하는지, 회사 문화에 좋은 영향을 미치는지 등을 몇 가지 문항을 통해 물어본다. 또 엔지니어의 경우에는 기술적으로 성장하고 있는지, 프로젝트 일정의 예측력과 실행력이 어떠한지, 일할 때에 기술부채를 신경쓰는지 등을 물어본다. 주관식으로도 설문에 들어가기 어려운, 어떤 부분이 좋고 나쁜지를 물어본다. 4) 설문을 취합한 후 적절한 가중치와 노멀라이징을 거쳐 최종 결과를 내고, 본인에게 문항별 결과를 알려주며 이런 부분을 사람들이 부족하다고 생각한 것 같다, 이런 부분은 사람들이 높게 평가하는 것 같다는 사실을 피드백해 준다. 주관식 답변의 경우 적당히 패러프레이징하여 알려준다.

2. 이 방식의 장점은 제법 정확하다는 점이다. 사람들의 생각 차이도 생각만큼 크지 않고 무엇보다 매니저들이 보는 피평가자와 실제 일하는 동료들이 보는 피평가자의 차이가 크지 않다. 그렇기 때문에 우리회사에서도 이 방식이 4년 이상 별 변화 없이 살아남을 수 있었던 것 같다. 다만 본인이 그러한 평가에 동의하지 않을 경우가 문제가 되는 면이 있다. 본인을 둘러싼 많은 사람들이 본인을 자기자신이 바라보는 것과 다르게 보고 있다는 생각이 들게 되면 그 자체로 회사생활의 고통이 시작되고, 그런 경우 중 적지 않은 수가 오래지 않아 본인의 퍼포먼스와 무관하게 퇴사를 선택했다.

3. 이 글을 쓰며 레퍼런스를 찾으려니 잘 찾아지지 않는데, 이런 기사를 본 적이 있다. 여러 가지 평가시스템 중 가장 직원들의 만족도(실제 정확성과 무관한)가 가장 높은 평가시스템은 아무 디테일 없이 그냥 조직장이 블랙박스로 나온 결과를 S/A/B/C/D 중 하나의 숫자로 주는 방법이라고. 일견 말도 안되는 소리같지만 생각해보면 그럴싸한 면도 있다. 많은 정보가 있을수록 그 속에는 논란거리가 생긴다. 반면에 평가과정이 불투명하면 할수록 평가에 대한 불만은 있을지언정 그 불만은 리더(개발팀의 경우에는 CTO)가 흡수하거나 탱킹할 수 있을 것이다. 그런 면에서 이런 의문을 스스로에게 던져보기도 한다. 혹시 지금의 360도 평가가 단지 내 손에 피를 묻히기 싫은 선택이지는 않을까? 물론 그런 불투명한 방식이 내 성향과 전혀 맞지 않기 때문에 지금의 시스템을 유지하고 있는 것이지만.

4. 어쨌거나 나는 다면평가 방식이 마음에 드는 편이다. 일단 가장 먼저 보이는 점은 사람들이 눈에 보이는 성과에 매몰되지 않을 수 있다는 점이다. 기존 프로젝트를 잘 유지보수 하는 것 역시 새로운 프로젝트만큼이나, 혹은 더 중요할수도 있다. 하지만 이 역할은 화려하지도 재미있지도 않다. 그런 현실 속에서 많은 회사들이 기존의 핵심 프로덕트의 유지보수 자리를 어떠한 한직이나 인기없는 자리로 만들어버리는 우를 범하기도 한다. 하지만 다면평가에서는 좀 더 필요한 곳에 필요한 시간을 들이는 사람들이 인정받는 면이 있고, 이런 점은 마음에 든다.

5. 사내정치를 통해 평가 결과가 좌우되는 일도 의외로 적다고 생각한다. 사적으로 아무리 친하더라도 자신의 일을 분담해야 할 사람이 일을 못한다면 그 일이 자신에게 돌아올 것이기에, 좋은 평가는 나오지 않는다. 또한 평가자를 취사선택하는 것도 평가자의 선정과정을 매니저와 함께 하기 때문에 막을 수 있다. 물론 작은 조직에서 다른 사람과의 업무상 접점이 적은 사람이 있을 수 있다. 이런 경우 평가자의 수가 너무 작아 바이어스가 발생할 수 있고 실제로 가끔 일어나는 현상인데, 이에 대한 고민은 많이 해보았지만 뚜렷한 답이 나오지는 않았다.

6. 특히 엔지니어에게 있어서 '정량적 평가'라는게 얼마나 무의미한가를 언제나 떠올린다. 유저 수와 리텐션? 본질적으로 엔지니어가 컨트롤할 수 있는 것이 아니다. 작성한 코드의 수와 커밋 수는 이야기하지도 말도록 하자. 버그가 많이 발견되는 경우 낮은 평가를 주어야 할까? 그렇다면 개발자는 버그가 발생하는 족족 최대한 이를 숨길 것이다. 아니면 처리한 버그의 수를 중요하게 평가할까? 본질적으로 한 개의 버그인 것을 최대한 여러 개의 버그로 뻥튀기하는 경우는 어떻게 될까? 결국 개발자의 평가는 그 어떤 정량화된 방식으로도 답이 나오지 않는다. 그런데 이런 코미디같은 일이 의외로 많은 회사에서 벌어지고 있다는 것이 문제지만.

(마지막 6편에서 계속)

제품 엔지니어링 디렉터: https://www.wanted.co.kr/wd/5802 주니어 웹 개발자: https://www.wanted.co.kr/wd/3244

4 notes · View notes

kivol-blog · 8 years ago

Text

테크 스타트업의 CTO로 아직 안망하기 - 4. 성장통

0. '성장통'이라는 말은 분명 좋은 말인데, 가끔은 규모가 작고 체계적이지 않은 조직이 실수나 잘못을 저질렀을 때의 핑계로 오용되는 경우가 있는 것 같기도 하다. 그런 관점에서 볼 때 성장통이라는 말이 적절한지는 잘 모르겠으나, 나는 그때 우리 회사는 성장통을 겪고 있다고 생각했다. 몇 번의 실패한 채용이 있었다. 어느 시점부터 팀에 완전한 신입이 아닌 어느 정도 경력이 있는 개발자도 합류하기 시작했지만, 좋은 퍼포먼스를 보여주지 못하거나 팀에 녹아들지 못하는 경우가 있었다.

1. 그때까지의 채용 기준은 간단했다. 그냥 해온 경력을 보고 그 경력이 사기인지 아닌지 정도를 판단해 보는 '느낌 채용'이었다. 큰 회사들이 그렇게 한다고 하길래 별 생각없이 따라하는 차원에서 몇 가지 자료구조나 알고리즘을 물어보기도 했었다. 어차피 회사도 인지도가 높지 않았고, 나의 인맥도 넓지 않았고, 따라서 지원자의 풀도 많지 않았는데 그 안에서 한 명은 선택해야 하는 제약이 있었다. 이전 글에서 이야기 했듯 오히려 신입의 경우에는 큰 문제가 없었다. 경력이 적을수록 나쁜 습관을 교정하고 좋은 설계와 프랙티스로 나아가게 할 수 있으나, 본인을 어느정도 연차가 쌓인 시니어라고 생각하는 경우에는 그것이 쉽지 않았다.

2. 더 큰 문제는 시니어와 밑그림을 같이 그려나갈 때에 있었다. 밑그림을 채색하는 데에는 대부분 무리가 없었으나, 밑그림 자체가 점점 방대해 지면서 그 밑그림을 그릴 역할 역시도 나누어가질 필요가 있었다. 본인의 경험 범위에서 절대 벗어나지 못하고 새로운 것을 받아들이지 못하는 시니어도 있었고, 또 반대로 일을 완성하는 데에 관심이 없이 새로운 기술만 찾아다니는 시니어도 있었다. 실패한 경우였고 그 대가는 컸다. 10명 내외의 팀에서 1명의 시니어의 역할은 좋은 쪽으로든 안좋은 쪽으로든 컸다. 30명짜리 팀에서 1명이 실패하는 것과는 비교도 안되게 수습하는 비용이 컸고, 오히려 그 사람과 함께하기 전에 비해 내가 디테일에 신경쓰게 되는 시간이 더 들어가는 현상이 발생하기도 했다.

3. 그와는 달리 운좋게도 성공적인 채용도 있었다. 운이 좋다고 표현한 이유는 지금 돌이켜보건대 채용 과정이 치밀하지 않았으나 좋은 결과를 냈기 때문이었다. 그렇게 합류한 시니어들이 팀의 기둥의 역할을 지금까지도 해 주고 있다. 프로덕트의 이터레이션을 돌면서도 지금의 구조가 가지고 있는 문제점을 끊임없이 같이 개선하고, 그러면서 채용 프로세스 역시 조금씩 갖춰나갈 수 있었다.

4. 결국 '채용 프로세스'라는 문제는 궁극적으로 '이 사람이 어떤 퍼포먼스를 보일 것인가'를 예측하는 문제로 환원된다. 그를 위해 지금까지의 데이터를 모으고 유효하다고 생각되는 팩터들을 정리한다. 그 팩터들에는 여러가지가 있을 수 있다. CS 전공여부, 알고리즘 지식, 설계능력, 기술스택이나 그를 바라보는 관점, 업계를 바라보는 관점 등등 수 많은 요소들이 팩터가 될 수 있다. 이러한 팩터는 회사마다, 또 시간에 따라 달라질 수 있다. 회사의 비지니스모델에 따라 좀 더 핵심적인 알고리즘이 중요한 경우도 있을 것이고 어떤 비지니스모델 하에서는 빠른 이터레이션 주기에서 기술부채를 쌓지 않고 기민하게 움직이는 능력이 중요한 경우도 있을 것이다. 또 회사의 팀 규모에 따라서도 어떤 사람이 필요할지는 언제나 달라진다.

5. 정리하고 보면 당연한 얘기다. 알고리즘만이 프로그래머의 유일한 본질이며 전부이고, 다른 것들은 모두 허상이라고 생각하는 근본주의자가 아니라면 대부분의 사람들은 저러한 팩터들이 유효하다고 생각할 것으로 생각한다. 나는 알고리즘 실력 말고도 다른 중요한 팩터가 많다고 생각하고, 그렇기에 약간은 독특한 채용 프로세스( http://bit.ly/2AymAKG )가 만들어졌다. 그리고 이 프로세스는 글 쓴 이후에도 계속해서 조금씩 진화중이다.

6. 한편 채용만큼이나 이별도 중요한 것 같다. 러프하게는 네 가지의 케이스가 나온다. 1) 괜찮은 사람이 계속 남아있으려는 경우 2) 괜찮은 사람이 이직을 하려는 경우 3) 별로인 사람이 계속 남아있으려는 경우 4) 별로인 사람이 이직을 하려는 경우. 1)과 4)의 경우는 그냥 해피한 경우이고, 2)의 경우도 나는 굳이 붙잡으려 하지는 않는 편이다. 결국 회사가 줄 수 있는 것은 세 가지이다. 일과 삶의 밸런스, 기술적 성장의 기회, 그리고 연봉 등의 보상이 그것이다. 나는 이 회사가 이 세 가지를 현실적으로 할 수 있는 최대한 주려고 노력하고 있다고 생각하는데, 그런데도 더 나은 조건을 찾아 이직을 하는 경우는 막기 어렵다고 생각한다. 가장 큰 문제는 3)이다. 나는 이 부분을 평가시스템을 통해 해결해야 한다고 생각했다.

(5편에서 계속)

제품 엔지니어링 디렉터: https://www.wanted.co.kr/wd/5802 주니어 웹 개발자: https://www.wanted.co.kr/wd/3244

6 notes · View notes

kivol-blog · 8 years ago

Text

테크 스타트업의 CTO로 아직 안망하기 - 3. 지속가능한 개발팀

0. 나는 선의를 그렇게 믿지 않는 편이다. 믿지 않는다기보다는 선의만으로 맺어지는 관계가 오래도록 지속될 수 있다고 생각하지 않는 쪽이다. 스타트업에서의 선의는 이렇게 작동한다고 생각한다. '우리는 세상을 이러이러하게 바꿀 프로덕트를 만든다'는 이야기를 하며 강력한 비전으로 사람들을 사로잡는다. 기존의 회사와 다른 복지와 업무환경은 덤이다. 주니어든 시니어든 이러한 비전 하나만을 보고 조인하고, 자신을 깎아가며 일을 한다. 그러다 어떤 사람들이 현실을 깨닫고 회사를 떠나고, 비전에 공감할만한 다른 사람들이 그 자리를 채운다.

1. 스타트업에서 커리어를 시작하는 것, 혹은 스타트업에서의 커리어를 만드는 것은 사실 그러한 선의만으로 굴러가지 않는 측면이 있다. 개발자로 한정하면 모든 문제의 핵심은 '자신의 기술을 갈고닦는 데에 최적화되어 있지 않다'라는 데에 있다. 확실한 롤이 없고 자연스럽게 풀스택 속의 어떤 스택들을 조금씩은 건드리게 되며, 적은 자본과 빡빡한 일정으로 이터레이션을 완료해야 하기 때문에 자기계발을 할만한 시간이 좀처럼 주어지지 않는다. 그러던 와중에 계획한만큼의 매출은 나오지 않고, 헤드카운트를 줄여나가고, 마지막까지 남은 사람들은 자신이 어떤 일을 하고 있는지에 대한 자각도 없이 갈려나간다.

2. 나는 비전만으로 사람들을 잡아두는 것은 지속가능한 일이 아니라고 생각했다. 그런데 사실 스타트업이 '지속가능한 일'을 먼저 생각하는 것은 굉장히 모순적이고 자기기만적인 것이고, 넓은 의미에서는 투자자들에 대한 배임으로 비추어질 가능성이 있었다. 하지만 나는 개발자들에게 비전 이상의 이익을 주는 것이 회사의 의무라고 생각했고, 또 그게 장기적으로, 심지어 단기적으로도 회사에 최적의 방향이라고 믿었다.

3. 내가 생각한 '비전 이상의 이익'은 단순한 금전적 보상만을 생각한 것은 아니었다. 어차피 스타트업이 줄 수 있는 금전적 보상은 뻔한 ��이 있다. 매출이 얼마나 나오는지에 따라 나갈 수 있는 연봉이 결정되고, 스톡옵션의 풀 역시 정해진 범위이며, 밸류에이션에 따라 불확실한 보상일 수밖에 없다. 나는 이런 보상보다도 그 사람의 인생에 가장 도움이 될 수 있는 방향이 무엇인지를 계속해서 고민하고 있었다.

4. 일단 그 방향의 목적함수를 생각해 보았다. 먼저 회사가 언젠가 갑자기 망하더라도 어디에서든 1인분을 할 수 있는 개발자로 취업할 수 있는 사람으로 만드는 것이었다. 그리고 시니어의 경우에도 최대한 최신기술을 따라갈 수 있으면서도 기본적으로 개발자라면 갖춰야 할 내공을 가진 사람이 되었으면 좋겠다는 생각을 했다. 장기적으로는 우리 회사에서 일했다는 경력이 어디에서든 환영받을 수 있는 회사 자체의 평판을 만들고 싶었다. 그리고 무엇보다, 그 사람의 가족과의 행복이나 일상을 방해하지 않기를 바랐다.

5. 앞의 글에서 이야기 했던 '지속가능성'에 대한 고민은 여러 측면에서 바라볼때 공통적으로 작용한다. 비지니스와 매출과 재무재표가 지속가능해야 한다. 그러면서도 개발 프로세스 역시 지속가능해야 한다. 나는 이것을 고려하지 않는 경영은 아무리 좋은 복지와 근무환경을 준다 해도 사람들의 커리어를 망치는 일이라고 생각했다. 업계에는 이미 자기자신을 속인 허상에 취해 모든 것을 망치는 '스타트업 힙스터'들이 많았다. 결국 이 모든 것은 개발팀 내의 문화에 달려 있었다.

6. 가장 먼저 도입한 것은 테크토크였다. 개발자들, 게다가 항상 트렌드가 바뀌는 자바스크립트와 모바일 씬은 언제나 최신기술에 대한 갈증이 큰 편이었다. 하지만 직접 찾아보기에는 귀찮고 누군가가 아웃라인만이라도 떠먹여줬으면 하는 욕구를 나 역시도 가지고 있었다. 그래서 일주일에 15분씩 돌아가면서 자신이 관심있는 기술에 대해 발표하는 자리를 만들었고, 이 전통은 3년째 이어지고 있다.

7. 그리고 자율출퇴근과 자율휴가, 자율적인 재택근무를 도입했다. 이 중 기술적으로 문제가 되는 부분은 재택근무였다. 보안을 유지하면서도 자유롭게 재택근무를 할 수 있게 하기 위해 VPN을 도입하고, 기존의 모든 인프라를 VPN 안으로 이전하는 작업을 했다. 하지만 기술적인 문제보다도 더 중요한 것은 이러한 자율성을 각자가 책임지는 문화였고, 그 과정에서 자율성을 책임질 수 없었던 몇 명의 팀원들이 팀을 떠날 수밖에 없었다. 부끄럽게도 채용과정에 대한 본격적인 고민을 그 때 처음 시작했던 것 같다. 어떤 사람을 어떤 과정으로 어떻게 뽑아야 할까?

(4편에서 계속)

PS. 현재 Knowre 개발팀에는 몇 개의 포지션이 오픈되어 있습니다. 주니어 웹 개발자, 주니어 안드로이드 개발자, 그리고 제품 엔지니어링을 총괄 매니징할 디렉터가 그 포지션들입니다. 혹시 관심있으신 분들께서는 다음의 링크를 참조해 주세요!

제품 엔지니어링 디렉터: https://www.wanted.co.kr/wd/5802 주니어 안드로이드 개발자: https://www.wanted.co.kr/wd/6103 주니어 웹 개발자: https://www.wanted.co.kr/wd/3244

3 notes · View notes

kivol-blog · 8 years ago

Text

테크 스타트업의 CTO로 아직 안망하기 - 2. 착한 아이 컴플렉스

0. 정도의 차이는 있겠지만 거의 모든 사람은 결국 '착한 아이 컴플렉스'를 가지고 있지 않을까. 개발자의 경우에는 요구사항을 완벽히 구현하고 기획자와 디자이너에게 칭찬받고 싶은 욕구가 강한 시기가 있었고, 나도 마찬가지였다. 어떤 요구사항이든 현실로 실현하는 실력있는 개발자임을 과시하고 싶은 욕망, 그리고 동료들이 기뻐하는 모습의 달콤함은 컸다. 하지만 언젠가는 그로 인한 기술부채를 갚을 수 있으리라는 생각이 실현되기 어려워보인다는 현실에 마주하게 되었다.

1. 그때쯤 'No를 말할 수 있는 사람이 되어야 한다'는 생각을 했던 것 같다. 요구사항 중 급하지 않은 것을 판단해야 하고, 불가능한 것 역시 판단해야 한다. 마치 하이젠베르크의 불확정성 원리에서 위치와 속도를 정확히 맞추어내는 것이 어렵듯, 스펙과 일정 사이에 상보적인 관계가 있다는 사실을 깨닫게 되었다. 문제는 커뮤니케이션 라인이었다. 개발팀원들은 나를 빼고 모두 신입이나 인턴이었고, '할 수 있는 것'과 '제대로 할 수 있는 것'의 차이를 정확하게 판단하는 데에 아직 한계가 있었다.

2. 나는 당시 아직도 상당 부분의 프로덕트 실무를 하고 있었다. 나의 일에 대해 'No라고 말하는 것'은 어렵지 않았다. 그리고 그렇게 하기 시작하자, 개발팀 바깥의 동료들은 자신들이 필요하다고 생각하는 일을 내가 아닌 다른 개발팀원에게 직접 요구하기 시작했다. 그리고 점점 코드는 망가져갔다. 이러한 방식에 대해 어필을 하기도 했으나 마음으로 받아들이지 않는 것 같았다. 업데이트와 스펙에 대해 빠르고 간단하게 의사결정을 할 수 있다는 것이 스타트업의 장점 아닌가? 좋은 프로덕트를 만들겠다는데 저 CTO는 왜 막아서고 있을까? 이런 생각들을 하며, 나에게 이러한 불만을 직/간접적으로 말하기도 했다.

3. 사실 비개발자가 코드의 퀄리티가 중요하다는 교훈을 얻을 수 있는 가장 빠른 길은 아예 말아먹어버리는 것이다. 끝없이 나오고 수습되지 않는 버그들, 하나를 고치거나 한 개의 기능을 추가하면 서너개씩 새로 생기는 버그들. 이런 것을 경험하고 나면 대부분의 사람은 느끼는 바가 있다. (물론 '개발자가 실력이 없군'이라고 생각해 버리는 사람도 있지만 우리 회사는 다행히도 그런 사람이 존재하지는 않았다) 하지만 이렇게 말아먹는다는 것은 '실패할 기회'가 많이 주어지지 않는 스타트업에게는 선택하기 어려운 옵션이었다.

4. 이 문제의 해결책 중 모두가 행복할 수 있는 해결책은 사실 아직도 찾지 못했다. 대화를 통해 스펙과 일정을 타협하고, 모두가 약간씩의 불만을 가지고 '지속가능한 이터레이션'을 반복해 나가는 것 외에 어떤 방법이 있을지 잘 모르겠다. 나는 위의 '불확정성 원리'를 도입하기로 결정했다. 디자이너나 사업부가 스펙이나 일정 중 하나를 결정하고, 개발자가 결정되지 않은 나머지 한 개의 요소에 전권을 가지고 모든 책임을 지는 것이다. 주니어 개발자의 경우 과신때문에 일정을 너무 타이트하게 잡을 수도 있지만, 그것은 일단 자신의 책임으로 하고 다음 이터레이션에서의 결정에서는 그러한 실수를 다시 하지 않도록 만들 수 있었다.

5. 지금도 이런 식의 불확정성 원리는 아직 노리 개발팀에서 최대한 유지하려 하는 원칙이다. 이런 원칙이 세워지고 난 후에 나는 좀 더 코드의 전반적인 구조와 설계에 신경을 쓸 수 있었다. 그리고 그러면서도 리스크를 줄이는 방법을 경험을 통해 깨달을 수 있었다. 주니어 개발자가 좋은 코드를 생산할 때도, 나쁜 코드를 생산할 때도 분명 있다. 당시에 가장 중요한 것은 그 리스크를 내가 수습할 수 있는 범위로 줄이는 것이었다. CTO가 칸막이를 처음에 잘 쳐 놓았다면 어떤 컴포넌트에 배설을 하더라도 그 부분만 어떻게든 수습할 수 있게 되는 것이다.

6. 그 무렵 Swint, Oreesh, Sinod 등의 야구팀 이름의 애너그램을 딴 내부 라이브러리나 프레임워크들이 생겨났다. 자바스크립트 프론트엔드와 node.js는 지나치게 자유도가 높았고 망칠 여지가 컸다고 판단했기 때문에 그 자유도를 줄여서 칸막이를 만드는 작업이었다. 당시에 유행하던 몇 가지 기술스택이 있었지만 우리의 목적과 자주 쓰는 인터페이스와 맞지 않는 경우가 있었다. 그런 경우에는 과감히 자유도를 줄인 비슷한 목적의 라이브러리를 처음부터 다시 만들었다. 바퀴의 재발명이었다.

7. 이런 식으로 아랫쪽 레이어를 정리하며 프로덕트의 세세한 부분을 조금씩 더 넘길 수 있었고, 나는 점점 더 뒷쪽의 구조 설계와 라이브러리 작업에 더 많은 시간을 쏟게 되었다. 그러면서 CTO의 개발팀 내에서의 역할은 자연스럽게 오픈소스 프로젝트의 '자비로운 독재자'와 같이 포지셔닝 되었다. 어쨌거나 그와 관계 없이 회사는 점점 규모가 커지고 있었고, 이제는 정말 시니어 개발자의 영입이 필요한 시기가 되었다. 또 다른 페이즈였다.

(3편에서 계속)

제품 엔지니어링 디렉터: https://www.wanted.co.kr/wd/5802 주니어 안드로이드 개발자: https://www.wanted.co.kr/wd/6103 주니어 웹 개발자: https://www.wanted.co.kr/wd/3244

3 notes · View notes

kivol-blog · 8 years ago

Text

테크 스타트업의 CTO로 아직 안망하기 - 1. 두 번째 팀원

0. 창업을 하기 전에는 3년간 산업기능요원을 했었다. 앞의 절반은 리눅스 시스템 엔지니어 역할을 했고, 뒤의 절반은 연구소에서 Layer 4~7의 전송 알고리즘 관련한 연구를 했었다. 어찌보면 극과 극의 레이어였는데, 여기에 계속해서 취미로 해오던 웹개발까지 합쳐지니 얼추 풀스택 비슷하게 넓고 얇은 지식을 알게 되었고, 혼자서도 어느 정도 프로토타입을 개발할 수 있었다. 문제는 이 모든 조직에서 나는 항상 막내였다는 사실이다. 나는 한 번도 부사수를 둔 적이 없었기 때문에 새로운 인턴과 일하는 것은 상당한 도전이었다. 그때쯤, '좋은 개발팀이란 무엇인가'에 대한 고민을 본격적으로 시작해왔던 것 같다.

1. 프로덕트의 복잡성은 기하급수적으로 커지고 있었고, 모든 일을 다 혼자 하기에는 물리적으로 어려운 시기가 다가오고 있었다. 수 많은 바쁜 사람들이 부질없이 상상하듯 나는 '나의 복제인간이 있어서 일을 좀 나눠갔으면 좋겠다'라는 생각을 했고, 일단 새로 온 인턴을 최대한 나의 복제인간으로 빚어내기 위한 준비를 시작했다. 먼저 내가 알고 있는 지식을 가르치고, 내가 중요하다고 생각하는 문서들을 읽게 하고, 또 내가 옳다고 ��는 설계 방향을 나누었다. 그러한 준비를 하는 데에 3개월정도가 걸렸고, 그 동안 전혀 실무를 나누지 않았다. 다행히도 이 인턴은 실무에서도 훌륭한 개발력과 생산력을 보여주었다. 이후 이런 식으로 실무 없이 3개월간의 교육 -> 조금씩 실무 투입의 패턴은 회사에 들어온 모든 인턴과 신입에게 비슷하게 적용되는 전통이 되었다.

2. 어쩌다 보니 이렇게 한 것이었지만, 이런 방식이 성공적일 수 있는 이유가 어느 정도 감이 잡히는 측면은 있다. 프로스포츠를 생각해 보자. 강팀을 만드는 가장 쉬운 방법은 좋은 선수를 돈으로 사오는 것이다. 물론 이게 가능할 정도로 돈이 많다면 걱정할 이유가 없다. 그렇기 때문에 많은 팀이 대안으로 선택하는 것은 좋은 팜 시스템을 만드는 것이다. 육성에 방점을 찍고 좋은 선수를 키워내는 것은 이미 완성된 인재를 사오는 것보다 더 효율적이다. 다만 여기에는 두 가지의 전제조건이 필요한데, 1) 가능성 있는 사람을 알아보는 것과 2) 그 사람을 유능한 선수로 키워내는 것이다. 결국 생각해 보면 1)은 회사의 채용과 면접 시스템과 관계있을 것이고, 2)는 내부적인 문화와 시스템과 관계있을 것이다.

3. 그 시기쯤 그런 상상을 한 적이 있다. '언젠가 돈을 많이 벌면 회사에서도 진짜로 프로스포츠의 2군처럼 팜을 만들 수도 있지 않을까?'.. 커리큘럼을 잘 만들고 10~20명정도를 받아 개발을 교육하고, 막바지쯤에는 실무와 지나치게 연관이 있지는 않지만 회사에 필요한 작은 프로젝트를 하나쯤 해 보고, 성과가 좋다면 정식으로 입사, 그렇지 않은 경우에도 다른 회사 어디에서라도 자기 몫을 할 수 있는 개발자로 만들어 줄 수 있다면 괜찮은 선순환 구조일 것이라는 생각이 들었다. 다행히도 나와 비슷한 생각을 한 사람들이 더 있었던 것 같다. 우아한형제들 같은 회사가 비슷한 발상으로 캠프를 운영하는 것을 보니 대단하고 부럽다는 생각이 든다.

4. 다시 회사로 돌아와서, 첫 번째 인턴이 합류하고 얼마 후 회사는 시리즈A 투자를 유치하는데 성공한다. 개발팀은 3명정도의 규모였지만 나를 제외한 모두는 인턴이거나 신입 개발자였다. 서비스의 퍼블릭 베타 오픈이 2주정도 미뤄졌고, 그 미뤄진 2주가 지나 이제 진짜 오픈을 앞두고 있던 상황에서도 제품의 스펙은 이리저리 바뀌고 있었고 화면 디자인은 마치 한국 드라마 쪽대본처럼 한장씩 전달되기 시작했다. 코드의 질이 점점 관리되지 않고 있다는 느낌이 커졌고, 오픈 이틀 전에 코드를 제로베이스에서 다시 쓰는 결단을 하기도 했다. 테스트 코드만 유지한 채로 밤을 새어 혼자 코드를 제로베이스에서 다시 쓰며(운 좋게도 이 결단은 성공적이었다), 나는 이 회사의 개발조직이 이대로는 지속가능하지 않다고 생각했고 몇 가지 결단을 내렸다.

(2편에서 계속)

제품 엔지니어링 디렉터: https://www.wanted.co.kr/wd/5802 주니어 안드로이드 개발자: https://www.wanted.co.kr/wd/6103 주니어 웹 개발자: https://www.wanted.co.kr/wd/3244

PPS. 후일담으로, 그 '최초의 인턴'은 1년 반정도, 생각보다 오랜 기간 팀에 있다가 학교로 돌아갔다. 자신은 좋은 개발자가 될 자신이 없는 것 같다며 행정고시 전산직을 준비했고 무려 수석합격했다는 소식을 작년에 알려왔다.

1 note · View note

kivol-blog · 8 years ago

Text

테크 스타트업의 CTO로 아직 안망하기 - 0. 서문

0. 어찌어찌 살다 보니 벌써 만으로 6��이 되었다. 한 회사의 시작부터 참여하여 20대의 중후반과 30대의 초반을 모두 바치게 되었고, 놀랍게도 아직도 망하지 않고 회사는 계속 성장하며 나는 여전히 그 자리에 있다. 그러면서 한편 언젠가는 지금까지의 여정을 정리해 봐야겠다는 생각을 한지도 오래 되었다. 더 큰 조직에서의 CTO는 경험해보지 않았으니 알 수 없지만, 적어도 지금 정도의 50명 이상의 전체 규모, 그리고 15~20명의 개발조직 규모로 오기까지의 CTO의 역할은 무엇일까. 그리고 여기 오기까지 내가 잘한 일과 잘못한 일은 무엇일까. 이런 이야기들을 정리해 보고자 한다. 예전에 누군가가 '너님은 리크루팅이나 뭔가 이득이 되는 일이 있을 때만 글을 쓴다'라고 지적한 바가 있는데, 지금이 바로 정확히 그 때인 것 같아 한 7부작 내외의 짧은 글들로 정리해 보고자 한다..

1. 방어코드를 잘 넣는 것이 중요하듯 글에서도 먼저 방어를 해놓고 가는 것이 좋을지도 모르겠다. 이 글은 개인적인 생각일 뿐이며 이게 무조건 맞다는 얘기도 아니며 따라했다가 망하는 것을 책임지지 않을 것이며 블라블라...등의 상식적인 얘기들은 생략하도록 하고, 'CTO는 그런 역할이 아니다' '정의부터가 잘못되었다'는 의견도 이 글을 통해 나올 수 있으리라고 생각한다. 그 자체가 결국 다양한 의견들이고 이 글 역시 one of them이라고 생각하며, 이 글 자체가 그 정의를 찾아나가는 과정이라고 생각한다. 무엇보다 나 역시도 CTO가 무엇인지를 아직 잘 안다고 생각하지 않으니 일단 CTO의 정의를 추상적으로 가져가 보려고 한다. 이 글에서의 CTO는 단지 '회사의 기술 관련한 모든 것을 최종적으로 마지막의 마지막까지 책임지는 사람'으로 정의한다. 이렇게 정의하면 아마도 다른 이견들은 '허허허 각론에서 조그만 견해차가 있군요 일정부분 존중하는 측면이 있습니다' 하는 미꾸라지같은 태도로 넘어갈 수 있을 것이다.

2. 나의 문제의식은 여기에서 출발한다. 먼저 '스타트업의 CTO는 좋은 개발자여야 하는가?'라는 질문을 스스로에게 해 본 적이 있다. 귀류법을 써 보자. 만약 스타트업의 CTO가 좋은 개발자가 아니라면 어떻게 될까? 좋은 제품을 개발할 수 없어서 망하거나, 아니면 외주를 통해, 혹은 좋은 개발자가 운 좋게 영입되어 완성도 있는 제품을 개발할 수 있을 것이다. 제품을 통해 돈을 벌기 위해 하는 것이 사업이라면 외주를 통해 시작하는 것은 지속가능하지 않다. 또한 제품을 만들어 준 좋은 개발자가 떠나고 나면 그 다음에 영입될 개발자가 또 좋은 개발자이라는 보장이 없고, CTO가 좋은 개발자가 아니라면 그것을 알아볼 안목도 없을 가능성이 크기 때문에 역시 지속가능하지 않다. 그렇게 생각하면 스타트업의 CTO는 좋은 개발자여야 하는 것이 맞는 것 같다.

3. 그 후에 자연스럽게 따라온 고민은 저 질문의 역이었다. '좋은 개발자는 좋은 CTO가 될 것인가?' 이 질문에 대한 답은 조금 더 트리키하다. 나는 좋은 개발자들로 이루어진 스타트업을 많이 본 적 있고, 또 정말 좋은 개발자를 CTO로 두고 출발한 회사 역시 많이 보았으나 항상 그 결과가 좋은 것은 아니었다. 일반적으로 보았을 때 이런 관찰은 있었다. 좋은 개발자로 출발한 스타트업은 초기의 데모버전의 완성도가 높고, 엔젤이나 시리즈A단계의 투자를 유치하는 데에 수월한 편이었다. 문제는 보통 그 다음에 일어났다. Time to market이 늦거나, 개발조직 관리를 제대로 하지 못해 성장하지 못하고 항상 사람들이 들어왔다 나갔다 하는 불안정한 팀이 되는 경우도 있었다. 최악의 경우에는 창업자간의 불화로 CTO가 회사를 나오는 경우도 있었다.

4. 결국 좋은 개발자가 항상 좋은 CTO가 되는 것은 아닌 것 같았다. 그렇다면 좋은 개발자가 좋은 CTO가 되는 조건이 있을 수 있지 않을까? 나는 스타트업의 성공은 많은 부분(7할 이상)이 운에 달렸다고 생각하고 여러 가지 경영 전략이나 방법론들은 나머지를 채우는 역할을 할 뿐이라고 생각하는 쪽이다. 하지만 좋은 개발조직을 만드는 데에는 그보다는 훨씬 적은 운이 필요하다고 생각한다. 수학적으로 볼 때, 여섯 개의 숫자가 모두 맞아야 낮은 확률로 복권에 당첨되지만 그 중 단 하나의 숫자를 맞출 확률은 이보다 훨씬 높기 때문이다. 그런 이유에서 나는 좋은 CTO가 되는 조건이 분명히 있을 것이라고 처음부터 생각했다.

5. 2011년, 회사를 차리면서 CTO를 맡게 되었다. 라마다 호텔 건너편 모 전직 대통령 자택에서 200m 떨어진 오래된 건물에 사무실을 잡고, 우리 제품의 프로토타입을 위한 서버와 아이패드 클라이언트를 개발하고 있었다. 공동창업자가 컨텐츠를 관리하는 시스템을 같이 개발하고 있었지만, 제품을 만드는 것은 나 혼자였다. 그리고 그러던 어느 날인 2012년 봄, 다른 공동창업자 중 한 명의 소개로 실무적인 개발을 공부해보고 싶다는 인턴이 들어온다. Knowre 개발"팀"의 여정은 바로 여기에서부터 시작한다.

(1편에서 계속)

제품 엔지니어링 디렉터: https://www.wanted.co.kr/wd/5802 주니어 안드로이드 개발자: https://www.wanted.co.kr/wd/6103 주니어 웹 개발자: https://www.wanted.co.kr/wd/3244

1 note · View note

kivol-blog · 9 years ago

Text

우리 회사의 개발자 인터뷰

0. 오늘은 기술적인 얘기는 아님. 지난번 글을 올리고서, 개발 블로그이면서도 기술적인 이야기를 써놓으면 호응이 별로 없다는 놀라운 사실을 깨달았음...

1. 원래 우리 개발팀의 면접은 오랫동안 2단계로 진행되어왔었다. 팀 인터뷰와 매니저 인터뷰. 후자는 뭐 최종면접의 성격으로 보는 것이었기 때문에 사실상 프로그래머서의 역량을 보는 핵심은 팀 인터뷰에 있었는데, 많은 사람들이 생각하고 또 많은 회사에서 보는 기술면접이었다. 기술면접에서는 보통 인턴 신입 할 것 없이 팀 전체가 들어가는데, 그건 같이 일할 사람이니 같이 보자는 뜻도 있지만 사실 주니어들에게 인터뷰 과정이나 시니어들이 '이것은 알아야 한다'라고 생각하는 토픽들, 그리고 지원자들이 돌아가고 난 뒤 어떤 피드백을 받는지 등에 관한 경험치를 쌓게 해 주고 싶어서가 컸다.

2. 어쨌든 그 취지와 성과는 좋았으나, 팀이 점점 커지다 보니 팀 인터뷰 자체에도 꽤 많은 시간적 비용이 들어가기 시작했다. 모두가 1 ~ 1.5시간 정도를 뺏기는 일이었으니까. 그래서 이번 포지션 오픈때는 팀 인터뷰 전에 새로운 단계를 하나 도입했다. 나와 해당 포지션 리더만 참여하는 '비디오 인터뷰'가 그것이다. 그렇다면 그 비디오 인터뷰에서는 어떤 것을 물어봐야 할까?

3. 그 이전에 '인터뷰에서 어떤 것을 물어봐야 하��'에 대해서도 개인적으로 상당한 고민이 있었다. 몇년 전까지는 이상한 브레인 티저들이 유행하기도 했다. 서울시에 있는 피아노 개수를 물어본다든지, 혹은 퍼즐같은 것을 풀게 하는 회사들도 있었다. 지금은 그 유행도 많이 사그라들었지만, 이 방식에 대한 비판은 너무 많이 나왔기 때문에 굳이 말을 얹고 싶지도 않다.

4. 많은 회사들이 사용하고 있는 알고리즘 테스트에 대해서도 그러하다. 알고리즘 테스트라는건 어떤 의미가 있을까? 이 것을 통해 우리는 어떤 사람과 함께할 수 있을까? 사실 생각해보면 잘 떠오르지 않는다. 나는 여러 가지 복잡한 알고리즘을 좋아하지만 딱히 그것들을 암기하고 있는 편은 아니다. 이미 많은 문제들에 대한 좋은 알고리즘들이 구글링 하면 슈도코드와 수학적 배경까지 설명되어 있고, 그마저도 잘 나오지 않는다면 나는 운좋게도 그 문제에 대해 지인찬스를 쓸 수 있는 세계구급 지인들을 알고 있는데, 실제로 그 찬스를 사용해야 한 적은 없다.

5. '좋은 알고리즘을 짤 수 있는 사람과 함께 하면 더 좋은 퍼포먼스가 나오지 않을까?'라는 질문의 답은 참이다. 그런데 맞는 말이긴 한데 그 정도가 어느 정도일지 나는 잘 모르겠다. 만약 예를 들어 구글같은 거대한 시스템의 프로그래머라면 그런 알고리즘의 작은 개선으로 25만불어치의 절약효과를 낼 수 있을지 모른다. 하지만 냉정하게 이야기해서 스타트업에서 그런 튜닝이 가져오는 결과는 너무나도 미미하다. O(n^2)를 O(n log n)으로 바꿔봐야 n이 작다면 둘 다 찰나의 시간들이니까.

6. 결국 서비스나 어플리케이션을 만드는 - 업계의 대부분을 차지하는 - 스타트업은 그런 알고리즘 튜닝보다는 생산성이 중요하게 된다. 다른 방식으로 이야기하자면, 프로그램이 수행되는 시간보다 프로그램이 만들어지는 시간이 더 중요하다는 이야기다. 그리고 이런 사람을 뽑는데 B-Tree의 삽입 과정을 아느냐 모르느냐는 크게 중요하지 않다고 생각한다. 정말로 퍼포먼스 관련해서 필요한 스킬이라면, 느린 부분이 생겼을 때 어느 부분이 느린가를 프로파일링하는 능력일 것이다. (사실 이마저도 대부분의 경우에는 알고리즘보다는 네트워크에 나갔다 들어오는 시간비용이 지배한다.)

7. 이런 고민끝에 우리 회사의 비디오 인터뷰는 실제의 간단한 어플리케이션을 만드는 과정을 보여주는 식으로 진행하기로 했다. 실무에서 만드는 프로덕트의 기능 일부 미니어처 버전을 제시하고 40분 ~ 1시간 정도의 시간을 주고 만들어보게 하는 것. 인터넷을 통해 무엇이든 찾아봐도 되고 어떤 방법과 라이브러리를 써도 된다. 본인에게 가장 익숙한 방식으로 본인이 현업을 하는 것과 똑같이 설계하고 프로그래밍을 하는 것을 보는 것이다. 그리고 이 모든 과정은 전체화면 공유를 통해 우리에게 공유된다.

8. 담당하는 포지션 리더의 취향에 따라 이 방식 없이 그냥 평범한 비디오 인터뷰를 하기도 했고 이런 식의 라이브코딩을 한 포지션도 있었는데, 스무 명 가량을 이 방식으로 해본 바 이 방식은 기대 이상으로 성공적이었다. 우리도 생각하지 못했던 정보들을 많이 얻을 수 있었다. 사소하게는 이 사람이 구글링을 어떻게 하는지(혹은 아주 심하게는 네이버 블로그에서 코드를 긁어오려 하는지), 문서를 어떻게 활용하는지, IDE는 어떻게 설정하고 정리하는지를 볼 수 있었고, 더 중요하게는 에러에는 어떻게 대응하는지, 단위 테스트를 어떻게 작성하는지(작성 하긴 하는지) 하는 것들을 알 수 있었다.

9. 이 사람이 객체지향과 디자인패턴의 개념을 가지고 있는 사람인지, 아니면 수십개의 앱을 만들어 보았지만 그저 정해진 템플릿에 어떻게든 우겨넣는 스크립트키드에 가까운지 역시 비디오 인터뷰를 통해 알 수 있었다. 그리고 무엇보다 가장 중요하게, 이 사람이 들여쓰기를 위해 탭을 쓰는 이타적이고 고운 심성을 가진 사람인지, 스페이스를 쓰는 이기적이고 파괴적인 심성을 가진 사람인지도 볼 수 있었다. (하지만 아쉽게도 우리와 함께하게 된 분들 중에는 그런 파괴적인 사람들이 대부분이었다..)

10. 이렇게 해 본 결과는 놀랍다면 놀라운 것인데, 대부분의 경우 좋은 퍼포먼스를 보여주지는 못했다. 40분 ~ 1시간이라는 시간에 비해 미션이 너무 복잡했을수도 있다고 생각하여, 완성보다는 실제 현업을 하듯이 최선의 설계에 중점을 두어달라고 이야기 하기도 했다. 하지만 완성도보다도 더 근본적인 문제들이 보여 안타까웠던 경우가 너무나도 많았다.

11. 수행해야 할 미션을 너무 늦게 주었나 싶어서 인터뷰 시간 10분전 -> 1시��전 -> 2시간전 까지 미션의 발송시간을 당겨 보았으나 유의미한 차이는 없었다. 미션의 스펙을 제대로 읽어보지 않고 수행하는 사람도 적지 않았으며, 꽤 긴 이력서를 가지고 계셨으나 처음 시작부터 막히는 케이스도 있었다. 그리고 가장 당황스러운 경우로, 비디오 인터뷰를 통해 라이브 코딩을 해야 한다고 이야기 하니 스케쥴을 이야기 하며 갑자기 지원을 포기하는 경우도 있었다. 그 분의 꽉 차있던 스케쥴에 평안함이 돌아오셨기를 기원한다.

12. 코딩 시간이 종료된 이후에는 과정중 생긴 의문점들에 대해 메모해 놓았다가 관련한 질문을 했다. 예를 들어 iOS 클라이언트를 개발하는데 변수에 weak/strong 프로퍼티를 쓴 이유가 무엇인지, 웹 클라이언트를 개발하는 데 CSS의 float 속성을 사용한 이유가 무엇인지 하는 것들. 이를 통해 그 사람의 지식을 좀 더 심층적으로 알 수 있었고, 이렇게 해 놓으니 팀 인터뷰에서 더 깊은 것을 물어보는 데에도 훨씬 수월해지는 장점이 있었다. 면접은 그 사람이 모르는 것을 억지로 후벼파는 과정이 아니라 그 사람이 어디까지 아는지를 밝혀가는 과정이니까.

13. 회사를 시작하고부터 중요하게 하던 생각 중 하나는 '갑질하는 압박면접을 하지는 말자'는 것이었기 때문에 이 인터뷰의 진행에 있어서도 고민이 많았다. 압박감을 최대한 줄이는 방법에 대해서도 고민을 하고, 만약에 오타나 (예를 들면 ==을 =로 쓰는 등의) 치명적인 사소한 실수 때문에 진행에서 몇 분 이상 막히고 있으면 이쪽에서 알려주는 규칙을 정하기도 했지만, 아마도 대부분의 지원자 분들은 처음 접하는 방식에 당황스러우셨을 것이라고 생각한다. 계속 고민해 보아야 할 문제겠지만, 그래도 우연히 이 글을 읽으실 분들께 도움이 되기를 바라며 이번 글을 마쳐보고자 한다..

ps. 이렇게 해서 몇 분을 모시는 데에 성공했습니다만, 아직 몇 자리 더 모시고 있습니다! 추천해 주신 분들께 현금도 드립니다! https://www.wanted.co.kr/wdlist?search=knowre

17 notes · View notes

kivol-blog · 9 years ago

Text

내가 사내 프레임워크를 만드는 이유

0. 아웃사이더님의 "사내 프레임워크 만들지 말자" 라는 글이 요즘 화제인 것 같다. 사내 라이브러리나 프레임워크를 적극적으로 만드는 입장에서의 자기변호같은 것을 할 필요가 있을 것 같아 간단히 내 생각을 정리해 보고자 한다..

1. 쓸데없는 거대담론이긴 한데, '프로그래밍이란 무엇일까'를 먼저 생각해 본다. 지금은 할머니 혹은 할아버지가 되신 분들이 하셨을 옛날 선사시대의 프로그래밍, 혹은 무언가 연구를 위해 시뮬레이션이나 통계분석을 돌리는 식의 (주로) 절차적인 프로그래밍을 제외한다면 프로그래밍은 결국 모듈을 나누고, 또 나누어져 흩어져 있는 모듈을 적당히 합쳐서 패키지, 혹은 프레임워크같은 것으로 만들고 하는 과정의 반복이었던 것 같다. 그러니까 결국 대부분의 프로그래밍의 본질은 추상화된 모듈에서 나오는 것이다.

2. OS 커널의 코드와 OS UI(셸)의 코드를 신묘하게 섞어서 코드도 좀 더 짧고 용량도 좀 더 적으며 퍼포먼스도 좀 더 나은 무언가를 만들어낼 수 있다고 가정해 보자. 그런 것이 나왔다 하더라도 아마도 그 용량과 퍼포먼스의 차이가 획기적인 수준이 아니라면 이 것을 긍정적으로 받아들이는 프로그래머는 많지 않을 것이다. 왜냐하면 서로 다른 모듈을 한 곳에 섞어버리는 것은 여러 가지 문제를 가지고 있기 때문이다. 1) 호환성의 문제. 커널과 셸이라는 이질적인 구성요소들이 합쳐졌기 때문에 기존의 커널과 호환되는 다른 셸을 만드는 것은 몹시 어려워질 것이다. 2) 유지보수의 문제. 정말 주의를 잘 기울이지 않는다면 셸의 수정이 커널에 영향을 주는 코드가 만들어질 것이다.

3. 이것을 건축으로 비유를 해 보자면 이런 것이다. 집을 지을 때 장농은 모두 붙박이로, 액자를 걸 수 있는 못도 벽에 이미 녹아 있는 형태로, 식탁은 물론이고 심지어 TV도 벽에 이미 박혀있는 형태로 짓는다면 초기비용은 적게 들고 더 예쁜 집이 만들어질 수 있을지 몰라도 위의 두가지, 호환성과 유지보수에 있어서 몹시 불편할 것이다. 그렇기 때문에 프로그래머들은 끊임없이 소프트웨어를 나누어서 관리한다. 한 가지 작은 일을 잘하는 단위를 만들고 그 단위들을 엮어서 궁극적으로 내가 원하는 것을 만들어내고자 하는 것이다. IT산업은 전체가 이런 식으로 발전해 왔다. TCP와 IP 레이어가 나뉘고, 회로 레벨에서도 계산을 하는 부분과 통신을 하는 부분이 나뉜다.

4. 결국 그렇다면 대부분의 경우 프로그래밍의 핵심은 결국 이 모듈들의 '인터페이스를 결정하고 조합하는 일'이 된다.(API의 I는 인터페이스다) A라는 모듈을 이렇게 사용하려면 이렇게 명령을 보내야 한다의 명세를 결정하는 것들의 반복. 이상적인 경우라면 이러한 모듈들을 잘 조합해서 모두모두 영원히 행복하게 살았습니다..가 되어야겠지만, 이 과정에서 오픈소스 프로젝트들과 현업 사이의 충돌이 생겨나게 된다. 왜냐 하면 우리가 오픈소스 프로젝트를 가져다 쓸 때에는 이 '인터페이스'를 결정할 권한을 잃게 되기 때문이다.

5. 러프한 구분이지만 거대한 오픈소스 프로젝트와 영세한 오픈소스 프로젝트가 있다고 해 보자. 거대한 오픈소스 프로젝트들은 그 자체로 기업처럼 돌아가는 경향이 있고, 점점 더 많은 것을 커버하려 하는 경향이 있다. 즉 그 프로젝트를 역시 하나의 모듈로 본다면 그 모듈의 인터페이스는 대부분의 경우 지나치게 일반화되어 있는 것이다. 우리 회사에서 필요한 것은 인터페이스에서 스위치 두세개를 내렸다 올렸다 하는 정도인데 주어지는 것이 거대한 스위치 100개짜리 제어 판넬이라면, 그래도 공부해서 할 수는 있겠지만 영 효율적인 방법은 아닌 것이다. 이 차이는 당연하다. 큰 오픈소스 프로젝트는 넓은 도메인을 커버해야 하지만, 정작 회사일이란건 대부분 domain-specific하기 때문이다.

6. 이 인터페이스가 함수나 클라스 수준이라면 Facade로 감싸든 하겠으나 우리의 현실은 그렇게 간단히 행복해지지 않는다. 그렇다면 해당 프로젝트 자체를 degeneralize한 래퍼를 만드는 것이 답일까? 사실 나는 그러고 있다. 우리 회사의 사내 프레임워크를 예로 들자면 서버는 express에 몇 가지 다른 컴포넌트를 붙여 만들었고, 또 다른 컴포넌트들은 다른 프레임워크를 기반으로 하고 있다. 그리고 회사의 웹서버들이 하는 일은 결국 다 비슷비슷하기 때문에 이 컴포넌트들을 합쳐서 하나의 패키지로 만들게 된다. 그런데 하다 보면 여러 가지 이슈와 요청사항들이 생기고 원래 기반이 된 프레임워크와 관계 없이 규모가 커지는 것은 어쩔 수 없다. 그렇다면 이 것을 또 하나의 새로운 프레임워크라고 부르지 못할 이유는 무엇이란 말인가.

7. 반면에 영세하고 작은 오픈소스 프로젝트의 경우를 생각해 보자. 오 이 모듈 괜찮아보인다 하고 github에 가봤더니 일단 Latest commit이 a year ago인 것이 일단 꺼림칙하다. 버그를 발견하여 Pull Request를 날렸으나 응답이 없거나 석연찮은 이유로 거부된다. fork하여 내가 만들려다 보니 나에게 필요한 최적의 인터페이스와 다른 불편한 부분도 꽤 보인다. 그 부분을 코드를 뜯어가며 고치다 보니 이런 생각이 들게 된다. '아 이럴 시간에 그냥 만들걸'...

8. 이런 프로젝트들을 보고 있자면 리누스 토발즈의 "보고 있는 눈이 충분히 많으면 찾지 못할 버그는 없다"라는 말은 그의 시대에나 통했던 이야기로 보이기까지 한다. 아니, 심지어 큰 프로젝트에서도 어처구니 없는 버그들이 몇 년 동안이나 잠복해 있기도 한다. 작년과 재작년에 여러 번 터졌던 OpenSSL의 보안문제들을 생각해 보자. 이제는 프로그래머의 수에 비해 오픈소스 프로젝트가 너무 많다. 대규모의 오픈소스 프로젝트들은 점점 더 시장의 패권을 위해 좋은 설계나 사용의 편리함이 아닌 다른 "마케팅 기법"들을 동원한다. 이런 곳에서 프로젝트들간에 제대로 된 경쟁이 가능할지 나는 잘 모르겠다.

9. 무의미한 결론을 내자면, 나는 여전히 사내에서 만드는 라이브러리나 프레임워크가 유효하다고 생각한다. 일단 하위호환을 위해 억지로 남아있는 레거시 비용이 필요없다는 장점이 있고, 인터페이스(다시 한번, API의 I는 인터페이스다)의 설계나 변경도 훨씬 자유롭게, 나의 필요에 맞게 할 수 있다. 그리고 이런 장점은 생산성에 유의미하게 도움을 준다. 오픈소스 프로젝트들이 기성복이라면 사내 프레임워크는 맞춤옷이다. 맞춤옷을 만들든 기성복을 수선하여 내 몸에 잘 맞게 만들든 잘 입을 능력이 있다면 기성복이 무슨 수로 맞춤옷의 퍼포먼스를 따라갈 수 있을까?

10. 나의 경험을 다시 한 번 이야기하자면, 현재 웹 서버/클라이언트쪽에서 내가 쓰고 있는 (규모있는) 오픈소스 프레임워크는 jQuery(아직 몇몇 레거시에서 쓰고 있다), SceneJS, Polymer, express, sequelize 정도이다. 이들 사이에는 직접 구현하려면 어마어마하게 귀찮은 부분들을 안정적으로 구현해 놓았다는 공통점이 있다. 반대로, 그런 경우가 아니라면 굳이 오픈소스를 찾고 그 인터페이스를 맞추고 적용하는 것이 시간낭비일 확률이 크다고 생각한다.

11. 냉정히 말해, 사내 프레임워크의 품질이 낮아지고 유지비용이 늘어나는 것은 사내 프레임워크라는 개념 자체와는 다른 문제다. 그냥 잘못짰기 때문에 그런 것이고, 그렇게 잘못 짜던 사람들이 프레임워크가 아닌 다른 일을 하면 아마도 그쪽의 코드를 망가트릴 것이다. 현업 어딘가에 안보이는 부분을 오픈소스들을 가져다 조합해서 만드는데, 모듈간의 인터페이스가 맞지 않으면 덕테잎이나 찰흙으로 대충 붙여서 '나의 생산성은 세계 제이이일!!'이라고 자부하고 있을지도 모르겠다. 반려동물을 키울때도 그렇지 않은가. 어차피 배변을 알맞은 곳에 하지 않을거라면 잘 보이는 곳에 배변하는 것이 차라리 더 고맙다. 심지어 배설물을 알아보고 처리할 사람조차 없다면 이미 뭘 해도 망한 조직일 것이고.

12. 일전에 어떤 지인이 나와 개발얘기를 하면 무조건 기승전똥이더라는 뼈아픈 지적을 했기 때문에 이대로 끝낼 수 없어 진짜 무의미한 결론으로 끝내자면, 결국 모든 문제는 좋은 개발조직을 갖추는 것으로 수렴한다고 생각한다. 나쁜 개발조직에서는 뭘 해도 안되고 좋은 개발조직에서는 그냥 뭘 해도 된다. 그게 애자일이든 워터폴이든 사내 프레임워크든 오픈소스 조합이든. 아, 이 결론으로 수렴하는 것도 전형적인 내 글쓰기 패턴이긴 하지만....

2 notes · View notes

kivol-blog · 9 years ago

Text

2016 KnowRe 웹 개발 커리큘럼 & 인턴 모집

https://github.com/KnowRe/WebDevCurriculum

찾아보니 저희 회사의 신입 웹 개발 커리큘럼을 공개했던 것(http://blog.kivol.net/post/106994756243)이 딱 1년전이었습니다. 새 인턴을 맞을 준비를 하며 살짝 정비를 했던 교육 커리큘럼을, 1년 뒤에 또 다른 인턴을 맞을 준비를 하며 다시 재정비해 보았습니다.

작년의 커리큘럼에 대한 소개는 위 링크에서 확인해보실 수 있습니다. 그때 생각했던 것들 중 지금도 똑같이 생각하는 것도 있고 그렇지 않은 부분도 있습니다만, '회사는 좋은 개발자를 키울 수 있어야 한다'라는 철학만은 그때와 변한 것이 없습니다.

작년 버전에 비해 달라진 부분이 크다면 크고 적다면 적습니다. 달라진 부분은 다음과 같습니다.

* 공부하는 당사자에게 오해를 줄 수 있는 부분을 좀 더 명확히 서술하고, 각각의 퀘스트를 통해 무엇을 해야 하는지, 그리고 무엇을 알아야 하는지 좀 더 명확한 가이드라인을 주었습니다. * 퀘스트들의 연계성을 좀 더 강화했습니다. 앞에서 수행했던 퀘스트의 결과물을 바탕으로 진행하는 퀘스트를 더 늘려, 좀 더 많은 내용을 커버하면서도 완료에 걸리는 시간을 약간이나마 단축할 수 있도록 했습니다. * Checklist라는 섹션이 추가되었습니다. 기술면접 등에서 흔히 물어볼만한 주제들에 대해 스스로 생각해 보고 미리 연습하는 기회를 주기 위함입니다. 그러면서 단순히 구현만 하는 것이 아닌 이론적인 배경을 더 탄탄히 갖추는 계기가 되기를 바라는 바입니다.

개인적으로는 입사 후 별다른 현업 없이 총 6~8주정도의 과정으로 이 커리큘럼을 끝내는 것을 이상적으로 생각하고 있습니다. 사실 이러한 커리큘럼을 통한 교육의 성패는 커리큘럼 자체보다도 이끌어주는 사람의 면밀한 코드 리뷰와 피드백이 좌우한다고 생각합니다. 혹시 다른 회사에서 이 커리큘럼이나 그 변형을 도입하시고자 한다면 그 점을 유념하시면 좋을 것 같습니다.

==============================================

그리고 이 커리큘럼을 통해 저희와 인턴으로 함께하실 분을 모십니다. 기초 프로그래밍 과목을 수강한 적이 있거나 개인적으로라도 무언가 간단하게 만들어 보신 경험이 있으신 분들께 추천드리고 싶은 자리입니다.

최대한 빨리 인턴을 시작하여 최소 6개월 이상 저희와 함께할 수 있어야 하며, 서로가 원한다면 더 오래 함께하거나 정식 입사를 하는 것도 물론 가능합니다.

인원은 한~두분정도를 모시고자 합니다. 혹시 의향이 있으신 분들께서는 [email protected] 으로 간단한 자기소개를 보내주시면 연락드리도록 하겠습니다..!

마감되었습니다!

1 note · View note

kivol-blog · 10 years ago

Text

비공식 구인글

0. 2월 4일에 포지션을 닫은 이후로 4개월만에 다시 KnowRe의 개발팀 포지션을 열게 되었습니다. 이 글은 비공식 구인글입니다. 공식 구인은 이곳(http://about.knowre.kr/jobs/)에서 보실 수 있습니다.

1. 기본적으로 현재 개발팀의 인원수인 13명의 팀은 결코 작은 규모는 아닙니다. 게임회사를 생각해 보면 작은 스튜디오 둘, 큰 스튜디오 하나를 만들 수도 있는 정도의 인원입니다. 포지션을 닫은 후 4개월동안의 변화라면 처음으로 드디어 팀이 갖춰진듯한 느낌이 든다는 것입니다. 저는 제가 좋은 매니저라고 꿈에도 생각해 본 적이 없을 정도인데, 팀원들�� 모두들 잘 도와주셔서 그래도 꽤 멋진 팀이 만들어질 수 있었던 것 같습니다.

2. 회사 이야기는 대표님이나 부대표님이 여기저기서 저보다 훨씬 달콤한 이야기를 해 주고 계시고 회사 웹사이트에도 잘 나와 있기 때문에, 이번 글에서는 회사 얘기보다는 개발팀만의 얘기 위주로 한 번 해볼까 합니다. 저는 로켓에 올라타라느니 이런 이야기는 오글거려 잘 하지 못합니다. 일에 있어서는 남을 속이거나 남에게 무언가를 떠넘기는 일도 잘 하지 못합니다. 생각해 보면 저번에 스타트업 힙스터 계정은 어떻게 운영했던 것인가 모르겠습니다. 아마도 제 깊은 곳의 욕망이 분출된 것이겠지요. 사실 다른 회사의 그런 '스타트업 스타일'의 구인글을 보면 걱정 반, 비웃음 반으로 보는 편입니다. (이 분야로 유명한 왓차의 수장 박태에게는 미안한 일입니다..)

3. 그래서 저는 최대한 담백하게 팀 이야기를 해볼까 합니다. 이 글에서는 팀의 문화, 지향하는 방법론, 복지, 자기성장, 보상, 원하는 인재상, 채용과정 정도를 다루려 합니다. 하지만 어디까지나 '2015년 6월 현재의 개발팀'에 관한 글입니다. 팀의 문화는 여러 가지 이유로 매일매일 바뀌고 있다고 생각합니다. 눈에 보이는 변화도 있을 것이고 구성원들이 눈치채지 못하는 경우도 있겠지요. 그리고 새로운 사람들이 합류하면 또 달리 바뀔 것입니다.

4. 저는 팀장으로서 자비로운 독재자를 지향합니다. (뭐 언젠가는 민중의 힘에 의해 끌어내려지는 독재자가 되기를 고대하고 있습니다..) 다만 아직 과반수의 판단에 따르지 않은 적은 없습니다. 팽팽한 사안에 캐스팅보트가 된 적은 있습니다. 그리고 북한같은 독재국가가 그렇듯이 외교적으로 강경한 발언을 많이 하는 편입니다. 제법 많은 스타트업, 아니 많은 회사에서 개발팀이 사업팀이나 기획자, 디자이너의 정제되지 않은 상상력을 당장 실현해주는 도구와 같은 역할을 하고 있습니다. 저는 그런 식의 그림을 원하지 않습니다. 개발팀이 하게 될 모든 일은 설득과 협상을 거쳐야 한다고 생각합니다.

5. 다만 팀 구성원들의 다양성은 중요하다고 생각합니다. 성향의 다양성도 중요하지만 배경의 다양성도 중요하다고 생각합니다. 저희 개발팀에는 한국인, 미국인, 독일인, 캐나다인, 60년대생, 70년대생, 80년대생, 90년대생, 여성, 남성, 흑인, 황인, 백인, 고졸, 대졸, 대학원졸이 모두 섞여 있습니다. 피똥을 싸며 SI개발을 하던 사람도 있고 금융권에서 거액을 받으며 일하던 사람도 있습니다. 다른 스타트업을 하던 사람도 있고 시스템 엔지니어링으로 커리어를 시작한 사람도 있습니다. 윈도우 유저도 있고 리눅스 유저도 있습니다. vi를 좋아하는 사람도 있고 서브라임 텍스트를 좋아하는 사람도 있으며 웹스톰같은 IDE를 선호하는 사람도 있습니다. 학부 몇 년만 다니다 인턴을 하러 온 사람도 있고 20년 이상을 개발자로 살아온 사람도 있습니다. 저는 비슷한 사람보다 다른 사람으로부터 더 많은 것을 배울 수 있다고 믿고 있습니다.

6. 꼭 그런 이유때문은 아니지만 서로의 호칭은 '선생님', 혹은 줄여서 '쌤'이라고 합니다. 강요하는 것은 아니고 권장사항인데, 저는 인턴들에게도 그렇게 부릅니다. 비한국어권 화자의 경우에는 그냥 이름을 부릅니다. 왠지 오그라들 것 같지만 해 보면 그렇게 이상하진 않습니다. 다른 회사에서 시도하고 있는 '~~님'이나 영어이름 부르기도 시도해 보았으나 지금의 방법이 제일 나았습니다. 비슷하게 직급도 따로 없고 팀별로 매니저만 한 명씩 있습니다. 중간관리자도 없습니다. 개발팀은 제가 독재자니까요.

7. 애자일을 지향하지 않는 편입니다. 스크럼은 고문의 도구라고 생각합니다. 페어 프로그래밍은 때에 따라 똥싸개 두 명이 큰 똥을 만드는 작업일 수 있다고 생각합니다. 자신도 해당 유닛의 스펙을 잘 모르는데 테스트를 먼저 만드는 것은 삽질이라고 생각합니다. 다만 자동화된, 그리고 제대로 된 테스트 자체는 중요하다고 생각합니다. 두 명의 실력차가 클 때의 페어 프로그래밍은 교육적 의미가 있다고 생각합니다. 기저에 깔린 부분은 항상 실행보다는 설계가 중요하다고 생각하며, 면밀히 논의하고 결정합니다. UI로 만질 수 있게 당장 보여주고 실시간으로 수정사항을 받아 반영하는 것보다, UI로 보여지지 않는 부분의 설계에 시간을 많이 들여야 한다고 생각합니다.(우리는 스티브 잡스가 아닙니다. 디자인팀 역시 그렇습니다.) 다른 팀들은 이런 철학을 약간은 답답해 하는 경향이 있습니다.

8. 자율적으로 출근과 퇴근을 합니다. 규칙이나 규율보다는 태스크 위주로 돌아가는 팀을 만들고 싶은 마음이 있습니다. 원하는 때에 출근하고 원하는 때에 퇴근합니다. 저는 할 일이 많아 주7일로 점심때 출근하여 자정 전후에 퇴근합니다만 다른 분들은 또 각자의 타임라인이 있습니다. 팀원들은 저녁마다 제가 언제나 있기 때문에 퇴근에 있어서 전혀 저의 눈치를 보지 않습니다. (사실 혼자 코딩에 집중좀 하게 저녁엔 다른 사람들 빨리 좀 갔으면 좋겠습니다.) 휴가 역시 마찬가지입니다. 연차에 제한은 두지 않습니다. 원한다면 언제나 재택근무�� 할 수도 있습니다. 그래도 어뷰징은 쉽지 않습니다. 제가 알기 전에 팀원들이 압니다. 저는 Managed pressure가 아닌 Peer pressure로 돌아가는 팀을 만들고 싶은 마음이 있습니다.

9. 생각해 보니 개발팀에 규칙이 하나 있기는 합니다. 이변이 없는 한 수요일 오후마다 주간회의를 하고 돌아가면서 회의의 호스트를 맡아야 합니다. 호스트는 회의에 앞서 15분정도 기술 관련된 아무 주제나 테크토크를 해야 합니다. 자신이 잘 아는 것이라 공유하고 싶은 것이든, 몰랐는데 이번 기회에 알고 싶은 것이든 상관 없습니다. 현업에 관련이 있든 없든 상관 없습니다. 보통 권장하는 주제는 '관심있지만 찾아보긴 귀찮고 누가 떠먹여줬으면 하는 것'들이지만 항상 그런 것은 아닙니다. 1년 가까이 한 것 같은데, 휴일과 겹친 서너번을 제외하고는 매주 했습니다.

10. 한 달에 한 번 회사 전체가 리프레시 데이를 갖습니다. 야외에 가서 피크닉을 하거나 영화나 공연을 보거나 하는 것들을 합니다. 3년 근속시 1개월짜리 유급휴가를 줍니다. 개발팀에는 아직 없으나 이제 슬슬 해당자가 나오려 합니다. 세미나 참여 지원이나 원하는 도서를 대신 구입해 드립니다. 회사차원에서의 복지는 이 정도가 생각납니다. 그리고 팀 차원에서는 매달 점심 혹은 저녁시간을 잡아 번갈아 팀 회식을 합니다. 팀장이자 애주가인 저는 남에게 술 먹이는 사람을 이해하기 어렵습니다. 내가 먹기도 아까운데 저 맛있는 것을 왜 남을 먹이려고 할까요? 며칠 전에 워크샵을 갔는데, 소주는 6병을 사갔으나 12명이서 한 병만 마시고 5병을 도로 가져 왔습니다. 물론 제가 먹을 술을 빼앗아 드실 분도 언제나 환영합니다.

11. 개발팀 내의 꽤 중요한 행사로, 분기별로 한 번씩 Dev Day를 갖습니다. 하루 날 잡아서 정해진 주제로 해커톤을 하고 그 다음날은 쉽니다. 벌써 6번이나 했네요. 무엇을 했었는지 자세한 사항은 다음과 같습니다.

[1st KnowRe Dev Day 2014 Spring] - 주제: "파일럿" - 첫 Dev Day입니다. 팀구성도 자유, 주제도 자유입니다.

[2nd KnowRe Dev Day 2014 Summer] - 주제: "팀 플레이" - 자유주제의 팀 대결입니다.

[3rd KnowRe Dev Day 2014 Autumn] - 주제: "축소된 인디언 홀덤" - 축소된 카드 덱과 규칙(J, Q, K 없음, 공유카드 두장, 개인카드 한장)으로 벌이는 AI 알고리즘 배틀

[4th KnowRe Dev Day 2014 Winter] - 주제: "아두이노" - 팀을 결성하여 아두이노 보드를 이용해 무엇이든 만들어 보세요!

[5th KnowRe Dev Day 2015 Spring] - 주제: "Go or Rust" - 모두에게 생소한 언어인 Go와 Rust 중 하나를 각자 경연 전날 추첨하여, 당일 반나절동안 언어를 익히고 무엇이든 만들어 봅니다.

[6th KnowRe Dev Day 2015 Summer] - 주제: "Testing Seminar" - 인천 을왕리에서의 워크샵을 겸하여 세미나를 가졌습니다. 웹 서버/웹 클라이언트/안드로이드 클라이언트/iOS 클라이언트 네 분야에서의 현실적인 자동화된 테스팅 방안들을 고민하고 발표하는 자리였습니다.

12. 데브데이도 그렇고 테크토크도 그렇고, 저는 KnowRe에서 개인이 많이 성장했으면 좋겠습니다. 회사의 성장도 중요하지만 개인의 성장이 더 중요하다고 생각합니다. 특히 망할 가능성이 높은 스타트업에서는 더더욱 그렇습니다. 언제 망할지 모르는데 성장이라도 해야지요. (뭐 다행히 객관적으로 봐도 노리가 막 당장 망할 리는 없어 보입니다..) 그런 의미에서 본인이 원한다면 매너리즘이 생길때쯤 포지션의 순환을 추천하는 편이고, 신입이나 인턴의 경우에는 첫 3개월을 오롯이 교육에만 투자합니다. 주로 웹개발을 그런 방향으로 진행하는데, 다른 글에 밝혔듯 커리큘럼은 공개하고 있습니다. 저는 기업들이 대학들에 현업을 가르치라는 요구는 투자 없이 날로 먹으려는 부당한 발상이라고 생각합니다.

13. 보상은 스타트업 평균에 비해 적은 편은 아니라고 생각합니다. 스톡옵션도 적지 않은 편이고, 결정적으로 때때로 사람에 따라 상당히 큰 편의 인상율을 받아드는 경우가 있습니다. 저는 넥센 히어로즈 스타일의 연봉제가 이상적이라고 생각합니다. 그 사람이 전에 얼마를 받았는가에 관계 없이 그 사람의 절대적인 기여도가 곧 그 사람의 다음 연봉이 되어야 한다고 생각합니다.

14. 팀에 관한 이야기를 많이 했으니 어떤 분들을 좋은 동료로 모시고 싶은지에 관한 이야기는 짧게만 하고 싶습니다. 이런 얘기를 길게 하는 것은 왠지 갑질 같은 느낌도 들고요. 어쨌거나 기본적으로 이번에 저희 팀에 조인하시게 된다면 웹 클라이언트와 서버를 담당하시게 됩니다. 서버는 node.js 기반이고 클라이언트는 jQuery로 만들어진 레거시와 Polymer 기반으로 작성될 프로젝트가 섞여 있습니다. 다만 저는 웹개발 자체에 큰 경험이 있어야만 업무를 잘 수행할 수 있을거라는 생각은 하고 있지 않습니다. 어떤 플랫폼이 됐든, 그것이 경험이든 재능이든, 깊이있는 인사이트를 보여줄 수 있는 사람이라면 더없이 좋다고 생각합니다.

15. 그렇다고 경력이 있는 분들만을 원하는 것은 아닙니다. 이번엔 신입과 경력자를 섞어서 모시려 합니다. 이는 현실적인 예산의 문제도 있습니다. 프로야구에서 증명되었듯이, 거액의 FA선수를 사오는 것보다 팜 시스템을 잘 갖추는 것이 더 저렴한 전력보강 방법이라고 생각합니다. 그렇기 때문에 저희 개발팀은 더더욱 개인의 성장을 중요하게 생각합니다. 성장가능성이 엿보이는 분이라면 경험이 적더라도 언제나 모시고 싶습니다.

16. 인턴을 모실 때를 제외하면 채용 과정은 기본적으로 서류와 두 번의 면접으로 진행됩니다. 서류의 경우 예전에는 결과통보를 따로 해드리지 않던 시절도 있었는데 잘못된 일이었다고 생각합니다. 요즘에는 서류만 넣어 주셔도 모시지 못했을 경우에도 모두 답장으로 알려드립니다. 1차 면접은 팀내 면접입니다. 같이 일할 사람들이 모두 들어와서 여러 가지 기술적인 이야기들을 하게 됩니다. 저는 인턴이나 주니어급 개발자들의 면접 참관을 권장하는 편입니다. 이런 면접과정의 참여가 주니어 개발자들에게, 경험 많은 개발자들이 실제 실무에서 중요하게 생각하는 것은 무엇이고 어떤 것을 주로 물어보는지, 혹시 다른 면접을 보게 된다면 어떻게 대답하는 것이 좋은지에 관한 중요한 경험치를 준다고 생각하기 때문입니다. 하지만 지원자분께서 이를 원하지 않으신다면 실제 질문과정에 참여하는 경험 많은 팀원들만 면접에 참여하게 됩니다.

17. 그리고 2차 면접은 매니저들의 면접입니다. 각 팀의 매니저들과 함께 기술적인 이야기보다는 좀 더 일반적인 이야기들을 하게 됩니다. 그리고 때에 따라 드물게 1차 면접과 2차 면접 사이에 미션을 드릴 때도 있습니다. 실제 과제를 드리고 take-home으로 그 것을 어떻게 구현하는지를 보는 퀘스트입니다.

18. 대강 생각나는 이야기들은 다 한 것 같습니다. 아마도 팀원들이 이 글을 읽으면 분명히 거짓말은 없는데 뭔가 미화된 것 같은 묘한 느낌이 들 것입니다. 저는 언제나 제가 상당히 안 좋은 매니저라고 생각하는 편입니다. 구인글이니 당연히 좋은(좋다고 생각하는) 이야기만 써놓았지만 분명히 저희 팀에도 문제점은 있을 것입니다. 구성원들이 느끼는 문제점은 빠르게 고치려고 하고 있고, 구성원들도 느끼지 못한 점은 새롭게 들어오는 분들께서 이야기해 주시고 고쳐나갈 수 있으면 좋을 것 같습니다. 저의 쓸데없이 긴 글을 읽고 혹시라도 저희 팀에 관심이 있으시다면 [email protected] 으로 당신이 누구인지를 알려 주세요. 사진이나 생년월일, 성별같은 것은 필요 없습니다. 님께서 어떻게 살아왔는지, 또 어떻게 살고 싶은지, 이런 필요한 것들을 알려 주세요. 모시고 싶습니다.

19. 다시 한 번, 공식 구인은 이곳(https://www.wanted.co.kr/wdlist?search=knowre)에서 보실 수 있습니다. 아 참, 산업기능요원(병특)은 받지 못하고 있습니다. 아시는 분은 아시겠지만 이건 제 탓이 아니에요... 2017년 3월 현재 산업기능요원 보충역/전직 모집중입니다! 이곳을 참고해 주세요.

#구인 #KnowRe

7 notes · View notes

kivol-blog · 10 years ago

Text

Developer experience

0. 한 개의 인풋만 있는 프로그램은 짤 수는 있겠으나 대부분의 경우 별 의미는 없다. 그렇기 때문에 프로그램에는 당연히 여러 가지 가능한 인풋이 존재하고 그 인풋은 옵션의 형태로 존재하는 경우가 많다. 만약 이미지에 필터를 먹이는 라이브러리라면, 채도를 낮추는데 얼마를 낮출 것인가 이런 옵션을 넣거나 하겠지. 그러니까 하고 싶은 말은, 입력하려는 이미지 자체 만큼이나 이 옵션을 어떻게 설계할 것이냐가 중요한 것이다.

1. 그런 이미지 라이브러리를 짠다고 가정해 보자. 결국 우리가 해야 할 일은 이미지의 각 픽셀들을 옵션에 맞게 잘 변환시키는 것인데, 우리는 로우 레벨 라이브러리를 하나 가지고 있어서 막 왼쪽에서 20번째, 윗쪽에서 70번째 픽셀의 RGB값을 바꾸는 그런 일도 할 수 있을 것이다.

2. 결국 궁극적으로는 그걸 옵션으로 줄것이냐의 선택의 문제가 생긴다. 뭐 옵션을 줄 수도 있겠지. 필터링을 위한 라이브러리, 혹은 함수에 변수로 가로세로 몇번째 픽셀을 어떻게 바꿔라 이런 옵션을 넣을 수 있을 것이다. 문제는 그런 옵션들을 잘 짜서 버그가 없게 동작한다고 해서 쓰기좋은 라이브러리가 되진 않을 것이라는거다. 그 라이브러리를 처음 접하는 사람이, 혹은 어느 정도 쓰던 사람이라도 수천가지의 옵션이 깨알같이 abc순으로 나열된 문서를 상상해 보면 정말 끔찍한 일이다.

3. 결국 우리는 추상화된 라이브러리를 만들고 쓴다. (머신러닝은 논란의 여지가 있으니 제외하고) 대부분의 이 라이브러리들은 로우레벨에서도 할 수 있는 것들, 즉 원래 가능하던 것들이다. 그리고 그 원래 되던 것들 중 사람들이 많이 쓰는 80%(그냥 질러본 숫자다)의 기능만 간단한 옵션으로 할 수 있게 포장하는 것이 추상화의 핵심일 것이다. 그리고 그 라이브러리가 커버하지 못하는 20%는 raw/advanced 옵션을 만들어서 직접 로우레벨에 접근할 인터페이스만 뚫어 주거나 아니면 다 포기하고 그냥 로우레벨을 쓰게 만들거나..

4. 생각해 보면 이건 UX의 원리와 상당히 비슷하다. 좋은 UX는 제공할 수 있는 모든 것을 유저가 어떻게든 할 수 있게 만들어 주는 것이 아니다. 제공할 수 있는 것들 중에 유저가 정말 많이 사용할만한 것을 추려서 그것만큼은 최대한 편리하게 할 수 있는 것이 (적어도 현대적 관점에서의) 좋은 UX인 것이다. 그렇기 때문에 함수, 라이브러리, 프레임워크, 심지어 언어의 경우에도 Developer experience, 즉 DX가 좋은 것과 기능이 좋은 것은 다르다. 기능이라는게 굳이 퍼포먼스가 아니라 다양함과 강력함을 말하는 경우에도.

5. 개발자에 대한 스테레오타입 중에, 뭘 갖다주든 그냥 대충 어떻게든 할 수 있게 옵션만 만들어 주면 알아서 쓸거라고 보는 관점이 있다. 뭐 그게 진짜 맞는 사람도 일부 있겠으나 나라면 그렇게 만들지는 않을 것 같다. 개발자라고 왜 그냥 편하게 함수 하나 갖다 쓰고 옵션 튜닝 딱히 안하고 대충 쓰고싶지 않겠는가. 그리고 실제로 갑자기 뜬 라이브러리/프레임워크/언어들을 떠올려 보�� 대부분은 이 DX가 훌륭했기 때문에 사람들이 사랑했던 경우가 많다. 바닐라 자바스크립트로 어차피 다 되는데 왜 jQuery가 흥했을까. 왜 엄청 강력한 기능을 가졌다고 주장하는 Dart는 지지부진할까. 뭐 이런 일화들.

6. 결국 뭐 정도의 문제겠지만, 나는 어느 순간부터 팀 안에서 쓸 라이브러리를 만들 때 옵션들을 최대한 단순화 시키고, 있던 옵션들(중 이미 사람들이 쓰고 있는 것일지라도)도 버리기 시작했다. 왜냐 하면 개발은 대부분의 경우 현재 있는 라이브러리들에 대한 옵션질이고 그 옵션의 인터페이스의 편리성이 결국 코드의 질을 결정한다고 생각하기 때문이다. 특히 스타트업 업계에 '결국 존잘 뽑아 놓으면 다 해결된다'는 믿음이 많지만 어차피 존잘은 잘 없고 더구나 진정한 존잘은 우리에게 올리 없지 않는가.

7. 애자일 진영은 한동안 이것을 프로세스와 습관의 문제로 환원하고 싶어 했지만 여러차례 얘기했듯이 거기엔 함정이 많다고 생각한다. 결국 문제는 DX다..라고까지 이야기하고 싶진 않지만, 존잘이 아니더라도 일정 수준 이상의 결과물을 낼 수 있을만한 그 팀 만을 위한 추상화 레이어도 굉장히 중요하다는 생각이 드는 것이다. 결국은 자기자랑이네 헤헤..

ps. 이 얘기를 왜 하냐 하면 그냥 요즘 DX가 좀 아쉬운 라이브러리를 (선택의 여지가 없이) 가지고 일하다 보니 갑자기 생각나서..

#developer experience

4 notes · View notes