시간이 아니라 수준에 맞추기

스타트업에 있다보면 이런 이야기들을 많이 한다. 52시간을 넘어서 근무를 해야한다. 성장을 위해서 야근을 해야한다. 주 80시간, 100시간은 일을 해야한다. 는 등등. 왜 많은 시간을 들여야한다고 이야기를 할까? 나는 이 부분에 대해서 많은 부분 동의하지 않는다. 한 가지 재밌는 점은 이 이야기들은 대부분 리드 포지션이 아닌 분들은 이야기 하지 않는 다는 것이다.(일 자체가 많은데 사람이 적은 경우는 제외를 하겠다. 이 경우는 회사에서 사람을 뽑아야한다.) 많은 시간을 일하면 성장을 하는가? 성장에 대한 다양한 관점이 있겠지만, 여기서 성장은 돈, 월급이나 스톡옵션에 대한, 즉 내가 일을 해서 받는 가치에 대한 성장은 제외하고(엄밀히 이건 일과 상관관계가 거의 없다. 좀 더 운에 가깝다고 생각한다.) 이야기를 해보자. 즉, 여기서의 성장은 각자 개인의 수준이 전체 업권의 수준 대비 얼만큼 와 있는가? 해당 업권에서 나는 어떤 종류의 문제해결을 할 수 있는가(얼마나 어려운 문제를 해결할 수 있는가)로 생각해 볼 수 있다. 그렇다면 많이 일을 하면 더 어려운 일을 해결할 수 있을까? 한가지 확실한 건 더 일하는 시간을 많이 하면 더 많은 일은 처리할 수 있다는 것이다. 예를 들어보자. 더 많이 일을 하면 API를 더 많이 만들 수 있다. 하지만 하나의 엄청 만들기 어렵고 생각해야할 게 많은 API를 만드는 게 많은 시간만으로 될까? 어제와 똑같은 생각과 방식으로 x2 x3 x5의 시간을 투자 한다고 했을 때 그게 될까? 글쎄.. 의문이다. ☹️ 성장에 대해서 다시 돌아와서 왜 많은 시간을 투자해서 일을 해야할까? 라는 질문을 해보면, 결국 개인의 성장을 위해서이다.(회사의 성장이 아니다.) 개인과 회사의 자본주의적 관점, 일을 하고 돈을 받는다는 단순한 관계라고 봤을때

divide and conquer

제목이 분할정복 알고리즘인데 사실 알고리즘에 대한 이야기를 하려는 것은 아니다. 개발자를 하면서 여러가지 알고리즘들이 있지만 실생활에 그리고 일을하는데 있어서 그리고 개인 생활에서 생기는 여러가지 문제를 해결하는데 가장 많이 도움이 되는 것은 분할 정복에 대한 개념이었다. 실제로 알고리즘 자체가 어떻게 돌아가는지는 그렇게 중요하지 않고, 작게 나누고 그걸 해결한다는 개념 자체를 아는게 중요하다. 생각보다 우리가 접하는 하나의 문제라는건 대부분 여러가지 복합적인 문제와 그로 인한 현상들로 이루어진 경우들이 많다. 이런 경우 문제의 해결을 위해서 나는 분할정복 전략을 도입하곤 한다. 예를 들면, 인식된 문제 : 인테리어 진행이 마음에 들지 않는다. 현상 : 인테리어 진행이 마음에 들지 않아서 기분이 좋지 않다. 실제 문제 : 마감미팅에 대한 공유가 되지 않았다. 생각했던 주방내 특정 서랍장이 마음에 들지 않는다. 액션: 마감미팅 공유 요청 특정 서랍장 변경 요청 이런 문제에서 보면 결국 인테리어의 문제로 내가 불편함 감정을 느끼지만 그것을 해결하는데 현상과 문제를 분리해서 보면 결국 해야하는 액션(action)이 명확해지고 그것을 행함으로써 빠르게 현상이 해결이 된다. 인식된 문제 : 타 업체와 일이 잘 안되서 짜증이 난다. 현상 : 일이 진행이 안되는것 같아서 답답하다. 실제 문제 : API가 문서와 맞지 않는다. 요청을 하면 너무 늦게 답이 온다. 액션 최대한 빨리 응답을 달라고 요청한

nexters 컨퍼런스 - 개발자커리어 : 두려움이 이끄는대로

Nexters Conference에서 발표를 했다. 뭔가 커리어에 대해서 애기한다는게 여전히 어색하긴 한데, 그래도 조금이나마 나와 같이 꼬인 경력, 혹은 물경력이라고 자조하시는 분들에게 도움이 되고 싶었다. 발표 장표를 만들면서 그리고 준비하면서 되게 스스로 걸어온 길에 대해서 많이 생각했던것 같다. 아쉬움도 크다. 그렇지만 돌이켜보면 후회는 없는것 같다. 발표때에도 애기하긴 했지만 이건 그냥 한 사람에 대한 커리어의 경험일 뿐이지 로드맵이나 정답따위가 아니라는거. 각자의 길은 각자가 만들어 가는 것이고 나의 길 역시 아직 끝이 아니기에. 그래도 이런기회가 주어져서 너무 감사하다. 🙏 질문들 중에 이후의 커리어에 대해서 애기하는 질문이 많았는데 서버개발자 로 돌아가는 것을 상상하고 있다. CTO를 하다보니 개발자로 일하는 게 얼마나 행복한지를 더 깨닫게 되는것 같다.

중쇄를 찍자 리뷰

중쇄를 찍자는 넷플렉스에 얼마전에 올라온 일드를 봤다. 사실 그 전에 이 작품(드라마인지, 만화인지 모르겠지만)에 대해서 트위터에서(역시 트위타..) 재밌다는 의견들이 있었고 그런게 있구나.. 로만 지나쳤는데 이번에 넷플렉스에서 보면서 재밌게 봤던것 같다. 스토리 자체는 초보 만화 편집자가 거치는 우여곡절에 대한 이야기인데, 그 중심에는 중쇄 라는 키워드가 있다. 드라마 안에서는 중판출래(重版出来)라고 해서 책을 초판 다음에 찍어내는 것을 중판이라고 하는데, 그것을 편집자들이 뭔가 성공했다? 잘 되었다라는 의미, 결국 책이 잘 팔려서 한번 더 찍어내야하는 상황이니까, 그렇게 받아들여 지는 것 같았다. 보면서 몇개의 부분에서 감동/인사이트를 얻었던 부분은 이렇다: 드라마에서 보면 중쇄를 찍는 행위에 대해서 굉장히 서로 축하해주고, 그것을 담당자는 굉장한 성취로 느끼면서 감사하게

2021 회고 : CTO로서 1년

2020년 12월 TechAssemble 진행 TechAssemble이라는 Tech내부에서 현황을 공유하고 앞으로 해야할 일들을 공유하는 자리를 마련했다. 2020년 12월 어떤 식으로 일을 할 것이고, 코드리뷰를 하는 방식, git branch 전략을 Github Flow로 통일했다. 단순히 코딩을 한다는 것보다는 제품(product)/서비스를 만들고 가치를 만들어내는 중요한 역할을 하는 것이 우리의 역할이라고 상기시켰다. 2021년 3월에 다시 TechAssemble을 진행했고, 우리가 일하는 방식이 변화되면서 1분기 사이 PR과 배포 관련 지표상으로 어떻게 달라졌는지를 구성원분들에게 보여주었다. 2021년 12월에 TechAssemble: 성장에 대한 이야기 라는 주제로 진행, 1년동안 구성원, 서비스 그리고 일을 하는 프로

라이브 코딩 테스트를 위한 조언

주니어 서버 엔지니어 포지션을 오픈한 이후에 요즘 일주일에 최소 3번의 기술면접을 들어가고 있는데 예전에 비해서 다양한 분들이 면접을 보셔서 세상이 변했다는것을 많이 느끼고 있다. 1차 면접에서 30분 정도 라이브코딩 테스트를 진행하고 있는데 몇몇 안타까운 경우들이 많아서 몇가지 팁을 적는다. 1) 사용하는 프로그래밍 언어 자체에 익숙하기 너무 당연한 부분이다. 아무리 신입/주니어라고 해도 코딩테스트가 있다고 하면 기본적인 본인이 제일 잘 사용하는 프로그래밍 언어에 대해서 잘 다뤄야 한다. 여기서 잘 다룬다는게 syntax sugar를 잘 쓰거나 그 언어를 깊게 이해한다는 게 아니고(그런걸 기대하는건 아니다.) 최소한의 기본적인 반복문과 분기문, 함수 작성과 호출 정도는 잘 사용해야한다는 것이다. 어떤 분들은 반복문의 문법 조차도 완성하지 못하는 경우도 있고, 완성하더라도 실제 실행하지 못하는 분들도 있는데, 코드를 짜고 실행을 시킨다. 는 것은 기본중에 기본이기 때문에 당연히 익숙해야한다. 간혹 우리회사에서 쓰는 언어에 맞춰서 코딩테스트를 보시는 분들이 있는데, 본인이 진짜 평소에 잘 쓰던 언어로 테스트를 봐도 라이브 코딩 테스트라는 압박감에서 제 실력으로 제한시간내 풀기란 쉽지 않다. 본인이 제일 잘 하는 언어를 이용해서 시험을 보길 추천한다. 2) 매일쓰는 코드 편집기 사용 할 것!! 이것도 1번과 비슷한 맥락인데 특정 편집기를 강제하지 않는 상황에서 본인이 매일 사용하는 코드 편집기(IDE)를 사용하는 것을 추천한다. 생각보다 도구는 중요하다. 어떤 분들은 거의 본인의 노트북이 맞나 싶을정도로 처음에 헤매는 분들이 있는데, 대부분 결과가 좋지 않았다. 예를 들어 Intellij를 사용하시는 분이 갑자기 본인 개인 노트북으로 eclipse로 테스트를 진행하는 경우도 있었고, 익숙하지 않은 vim으로 보는 분들도

2020 회고

2020년 이글을 쓰는 시점은 12월 30일이라 올해가 가기 전에 회고를 해보려고 한다. 올한해 아쉬웠던 점은 나 뿐만 아니라 모든 사람들이 그렇겠지만 코로나로 인해서 우리의 생활들이 그리고 계획했던 것들을 많이 이루진 못했다. 특히 올해는 PyconUS2020을 가기 위해서 행사 티켓 뿐만 아니라 비행기, 호텔 그리고 휴가 계획까지 모두 거기에 맞춰있었는데 못 가게 되었고, 이 컨퍼런스 뿐만 아니라 국내에서 진행하는 컨퍼런스들도 모두 유투브로 시청해서 현장감은 아쉬웠다. 그래도 올해 꽤 알차게 보냈던 것 같고 역시 인생은 의도치 않았던, 상상하지 못했던 일이 벌어지면서 재밌는 것 같은데 올해 기억남는 것을 몇가지 뽑아보자면 이렇다. 부캐, 캠핑, 포도나무 코로나 사태로 인해서 주말에 사람이 많은 곳에 가기 보다는 부모님이 일하시는 목장에가서 포도나무를 심거나 캠핑을 하거나 강아지랑 놀거나 하는 시간들을 주로 금, 토, 일을 보냈던 것 같다. 처음에는 자연을 보는것 자체가 힐링이 되었고, 개인적으로 2-3월 많이 심적으로 지쳐있는 상태라서 약간의 도피처가 되었던 것 같다. 그리고 아이들도 마음껏 뛰어놀 수 있고, 다양한 놀이를 할 수 있게 되어서 좋았다. 처음에는 토, 일만 갔는데 나중에는 금요일에 빨리 퇴근해서 바로 금요일 밤에 가서 좀 더 길게 보냈던 것 같다. 프로젝트와 성장 본의아니게 타임어택이 걸린 프로젝트를 리드하게 되었고, 사실 이 회사에서는 리드하는 포지션은 아니였는데(이전 회사에서 리드하는 포지션에서 약간 질려서..😨) 리드를 하고 새로운 사람들과 새로운 팀을 꾸려 나가면서 열심히 했던것 같다. 다행히 성과도 좋았고. 그 안에서 개인적으로 많이 성장하고, 성찰하고, 깨달음을 얻게 되었던 것 같다.

포도는 어떻게 되었을까?🍇

이전 글들에서 포도나무를 심고 주말마다 가꾼 부캐의 썰을 풀었는데, 그 이후 포도는 어떻게 되었는지에 대해서 애기하려고 한다. 우선 잡초를 뽑는 것 이상으로 생각보다 할 일이 많다는 것을 깨닫게 되었다. 사실 그냥 심어보자는 무계획적인 부분이 많았고 전문적으로 포도재배에 대해서 공부한 것도 아니여서 부족한 부분이 많았고 그런 부분들은 그때 그때 몸으로 때웠다. 예를 들면, 무럭무럭 자라나는 포도의 가지들, 그리고 거기서 나오는 줄기와 잎에 대해서 어떻게 해야할지를 몰랐다. 진짜 무럭무럭 자랐고 잘 자라고 있구나로 여겼는데 나중에 큰 부채로 다가왔다. 그리고 포도송이가 맺히기 시작했을 때 이게 포도인지 꽃인지 분간을 못했다. 나는 분명 포도라고 생각했고, 다른 사람은 꽃이라고 주장했다. 결과적으로 당연히 포도였고, 그 시간에 봉지를 씌우거나 포도알들을 골라내는 작업들을 하지 못했다. 그래서 중간에 포도알들이 겹치면서 터져나가는 경우가 많았다. 그래도 약 40~50 송이 포도에 대해서 봉지씌우는 작업을 했고, 20~30 송이 정도 수확을 하게 되었던 것 같다. 아쉽게도 태풍 하이선이 오는 날이라서 내려가지 못하고 아이들과 함께 포도를 따는 체험을 하지는 못했고 부모님이 대신 따주셨다. 막상 결과물을 받아 봤을 때, 첫 해의 수확이지만 너무 만족스러웠다. 포도를 직접 돈을 주고 사먹지 않아도 된

우리에겐 그라운드 룰이 필요하다.

부캐의 일상은 계속 진행 중인데, 보통 금요일 밤 늦게 9시 넘어서 내려가서 토요일 오전 6시 정도부터 일을 시작하고 11시~4시 정도는 여름으로 접어들어서 시에스타를 즐기고 있다. 여름으로 넘어오면서 잡초들이 진짜 무섭게 자라는 것을 느끼고 있는데, 일주일마다 잡초가 다시 무성하게 자라는 것을 보고 왜 이게 잡초라고 불리는지를 새삼느끼고 있다. 처음 포도나무를 심었을 때, 부모님이 포도나무 바닥에 검은색 비닐을 깔아서 눌러주면 잡초가 번창하는 것을 방지할 수 있다고 알려주셨다. 사실 뭐 잡초 뽑는 게 어렵겠나? 운동삼아 하지 라고 생각하며 매주 잡초를 뽑았는데 이젠 한계에 부딪혔고(2시간씩 뽑으면 죽을 것 같다. 🤯), 2주전에 검은색 비밀을 깔아서 더 이상 잡초는 올라오지 않는다. 부캐의 일상과 함께 본캐는 프로젝트를 진행하면서 많은 것들을 느끼고 있다. 프로젝트의 완성이 결국 포도나무를 키우고 포도 열매를 맛보는 것이라면, 잡초는 뭘까? 내 생각에 잡초는 목표에 상관없는 의견이나 코드, 프로세스 등이다. 다양성도 중요하고 소수의견도 중요하지만 프로젝트를 진행함에 있어서, 그리고 일정이 매우 중요한 프로젝트에 있어서 그러한 것들은 의사소통 비용을 증가 시키고 협업과 생산성을 저해 시킨다. 프로젝트를 진행하면서 더 이상 잡초가 올라오지 않게 하는 바닥에 까는 검은색 비밀의 역할이 그라운드 룰(GroundRule)이다. 같이 일하는 개발자, 협업하는 개발자, 팀 내