행복한디벨로퍼

안녕하세요 오늘은 "개발자가 적성에 맞는지?" 에 대한 주제로 포스팅 해볼까 합니다.

일단 저는 판교 IT회사에서 7년차 개발자로 일하고 있습니다.

개발자분들이시라면 아니 대한민국에서 직장을 다니시는 모든 분들이시라면 한 번쯤은 "내가 하는 일이 내 적성에 맞는건가?" 라는 질문을 해보셨을거라 생각합니다.

저 또한 그렇습니다.

개발자로 처음 회사에서 일하던 2014~2015년 정말 하루 하루 수십번도 더 고민했습니다. 왜냐구요???

너무 못하는 것 같아서요. 주변 사람 동료들과 비교했을 때 너무 부족하다고 느꼈고 그로 인해 자신감과 자존감을 바닥을 향해 달려가고 있었으니까요. 경쟁사회에서 내가 남들에 비해 잘하지 못한다고 생각이 드는데 그 일이 재미있을 수가 있을까요??? 하물며 전혀 못해도 밥먹고 사는데 지장없는 게임을 하는데도 이 룰이 적용되는 걸 본다면요.

개발자로 일을 해서 밥벌이를 해야 하는 것은 결국 개발자로서의 능력을 갖추어야 하는 것이 첫 번째입니다. 이 기본적인 능력이 갖추어지지 않는 이상  '개발이 내 적성에 맞는건가'라는 고민이 뒤를 따라다니며 괴롭힐 것 입니다. 기본적인 능력이 갖추어지지 않은 상태라면 매번 회사에서의 일이 고되고 남들과의 비교에서 오는 자괴감에 더 이상 개발자로 일하고 싶지 않을 것 입니다.

저 또한 그랬습니다.

신입으로서 부족한게 당연한거지만 그럼에도 불구하고 잘하는 주변 동기들을 보며 한 없이 작아지는 저의 모습을 마주했습니다. 특히나 '개발'이라는 분야는 더욱 그런 것 같습니다. 같이 입사한 신입사원임에도 그 실력차이는 비교도 안 될 만큼 크게 날 수 있습니다. 하지만 그렇게 포기하고 싶지는 않았습니다. 정말 자존감은 하루 하루 바닥을 칠 정도로 힘들었지만 이렇게 포기한다면 어떤 일을 하더라도 잘해낼 수 없을 것 만 같았습니다. 정말 나중에 너무 힘들어 회사를 그만 두더라도 최소한 내 스스로에게 "그래 할 만큼 했어"라는 최소한의 핑계거리라도 있어야 아쉬움이 남지 않을 것 같았습니다. 

그래서 공부했습니다. 저의 목표는 남들에게 엄청난 인정은 받지 못할 지언정 스스로 '아 이 정도면 그래도 나는 최소한 개발자의 능력은 갖추었어!'라는 생각이 들정도였습니다. 그 정도 까지 가는데는 최소 2년에서 3년은 필요할 것 같다는 생각이 들었습니다. 그래서 공부했습니다. 회사가 끝나고 회사에 남아 최소 3~4시간 이상 공부하였습니다. 하지만 이 정도 공부는 저 뿐만 아니라 동기들 대부분이 하였습니다.

저는 이 정도로는 안된다고 생각했고 집 주변에 독서실을 끊어 주말 공휴일 독서실을 다니며 동기들보다 조금이나마 더 공부하려고 노력했습니다. 지금은 그 때처럼 주구장창 독서실에 앉아 책을 읽으며 개발공부를 하지는 않습니다. 하지만 그 당시 제대로 된 공부 방법도 몰랐고 무엇을 어떻게 해야 할지 감도 안잡히던 시절 내가 공부하고 있는 분야의 지식을 이론적으로 습득하는 것만으로도 제 스스로에게 굉장히 힘이 되었습니다. 그리고 회사에서 프로그래밍을 할 때 이해가 되지 않던 부분들에 대해서도 차근 차근 이론적인 공부가 뒷받침되니 이해되는 부분이 굉장히 넓어졌습니다. 그렇게 시작하였습니다.

저는 동기들보다 더 많이 노력하고 공부하여야 했습니다. 그렇게 시작한 공부했던 시절들이 "개발자 안했으면 어쩔 뻔 했어"라는 생각을 가지게 된 지금의 저를 만들었습니다. 6년 동안 기술블로그를 운영하고 회사가 끝나면 토이프로젝트를 하고 개발 관련 유튜브 영상을 찍고 있는 저를 만들었습니다. 신기하지 않습니까?

그래서 저는 생각합니다.

개발자가 적성에 맞는지? 고민하는 시간에 조금이라도 시간을 투자해 공부해야 한다고, 적성에 맞는지 안맞는지는 스스로가 그 분야에 대해 어느 정도 실력이 생기고 나서 해보는 것이라고, 그러지 않을거면 적성에 맞지 않아 그만뒀다고는 하지 말자고.

정말 잘하는 실력을 갖추었음에도 그 일이 재미없고 일을 하는 동안 지겹고 따분하기만 하다면 그게 바로 적성에 맞지 않는 것 입니다. 제가 생각하기엔 그렇습니다. 제가 경험했고 컴퓨터공학부 시절 코딩은 나랑 안맞는다며 살아온 제가 이렇게 변했습니다.

이 글을 읽는 모든 분들은 그래도 내면에 '개발을 잘하고 싶다'라는 생각은 조금이나마 다들 가지고 있으실 거라 생각합니다. 그렇기 때문에 이렇게 고민하고 계시는 거고 이 글을 여기까지 읽고 계실거라 생각합니다. 

그렇다면 '개발자가 적성에 맞는지' 확인하기 위해 그만 둘 땐 그만 두더라도 '밑져야 본전'이다는 심정으로 1년만 투자해보세요.

달라집니다.

해당 내용을 영상으로 만들어보았습니다.

www.youtube.com/watch?v=Z5EVaaKSx9A

1. 안정적이고 완벽한 코드를 짜는 것도 중요하지만 때로는 시간과 타협해서 돌아가는 코드를 짜는 것만으로 만족해야 할 때가 있다.

이 문구를 읽고 너무 공감이가서 정말 속이 다 시원했다. 물론 내가 짠 코드를 최대한 우아하게 짜고 싶고 각 종 패턴들까지 적용은 아니더라고 누가봐도 읽기 쉽고 잘짰다는 소리를 들을 수 있길 원한다. 하지만 보통 실무에서 이렇게 여유롭게 코드를 리팩토링 할 수 있는 여유가 보통은 없을 것이다. 그러면 가끔 실무에서 손을 뗀 사람들 혹은 소위 아가리어터들(입으로만 떠드는)은 얘기한다. 그 짧은 시간 안에 코드를 잘짜는게 실력이다'라고 하기도 한다. 이게 반은 맞고 반은 틀린 말이다. 물론 그 짧은 시간안에서도 뇌의 CPU가 300%돌아가며 최적의 코드를 짜내는 사람도 분명 있긴 있을 것이다(이런분들이 저런 얘길 하면 아무말도 안한다...그저 존경의 대상일뿐)

하지만 보통은 울며겨자먹기 식으로 급하게 패치를 해야 하는 경우나 기능개발에 비해 일정이 너무나도 짧아 본인이 만들어 놓은 코드를 리팩토링 한 번 제대로 못한 채 테스트만 통과한 상태로 나가는 경우도 비일비재하다. 전에는 경력 많으신 관리직분들의 얘기나 혹은 개발 관련 글들을 읽고 생각했었다. '아 내가 아직 많이 부족해서 그래.. 짧은 시간안에서도 SOLID(객체지향설계)원칙을 지키는 코드를 짜내고야 말겠다고!' 풉🙊 

시간과 타협해 버그 없이 돌아가는 코드를 짜내는 것만으로도 훌륭하다고 생각한다. 하지만 제일 중요한 것은 거기서 끝나면 안된다. 바쁠때는 어쩔 수 없더라도 좋은 개발자가 되기 위해서는 시간을 내든 여유 시간이 생겼든, 뒤로 돌아와 '시간과 타협해 돌아가게 만든 코드를 리팩토링 하는거!' 정말 중요하다고 생각한다. 이 때 우리는 좀 더 발전할 수 있다.

2. 우리는 개발자이다. 맘만 먹으면 생각하고 있는 동작을 얼마든지 만들 수 있는 능력을 가진 대단하면서도 신기한 사람들이다.

나도 정말 그렇게 생각한다. 우리는 무에서 유를 창출해내고 있는 사람들이며 내 머릿속 생각을 실제 서비스로 혹은 시스템으로 만들 수 있는 연금술사 같은 사람들이다. 이 문구는 내가 개발자로서의 삶을 살아가고 있는 지금의 모습에 감사함을 느끼게 해주었다. 하지만 제일 중요한 것은 '맘만 먹지말자'는 것이다. 다이어트도 그렇고 신년 계획도 그렇고 맘만먹는 것과 행동하는 것은 다르다. 우리에게 주어진 감사한 능력을 맘껏 발휘해 나만의 서비스를 만들고 운영해보자.

3. Stack Overflow Driven Development (SODD) 라는 말이 있듯이 개발은 사실 엄청난 성능과 최적의 알고리즘을 요하는게 아니라면 개발자 간의 경쟁력은 일반적인 개발실력 이외엔 시간과 경험의 차이인것 같다.

이 말인 즉슨 보통 '개발과 구글링과는 뗄레야 뗄 수 없는 존재이기 때문에 굳이 엄청난 알고리즘 지식들을 머릿속에 넣고 있는게 중요하지 않다'라고 생각된다. 일반적인 서비스를 개발하는 영역에서는 사실상 학부시절 배웠던 DFS(깊이우선탐색)이나 BFS(너비우선탐색)과 같은 기초로 여겨왔던 알고리즘 조차 쓸일이 거의 없다. 실제로 필요하다고 해도 해당 부분을 처음부터 끝까지 직접 개발하는 일은 더더욱 드물다. 보통은 나보다 머리가 똑똑한 사람들이 라이브러리 형태로 왠만한 언어로 다 만들어놓았고 우리는 잘 검색해 믿음직스러운 코드를 가져다가 테스트해보고 커스터마이징 하여 사용하는 수준일 것이다.

그렇기에 알고리즘을 많이 알고 있다는 것이 그렇게 중요한 요소로 생각되진 않는다. 취업준비생들 혹은 구글과 같이 알고리즘에 대한 것을 많이 물어보는 기업에 취업하고 싶다면 필수로 공부가 필요하긴 하다. 하지만 연차가 쌓여가면서 얻는 경험은 단순히 공부한다고 배울 수 있는게 아니다. 항상 어른들이 말씀하실 때 모든건 때가 있듯 각 개발연차마다 배워야 할, 배울 수 있는 것들의 시기라는게 있다고 생각한다.

그렇기에 지금 내가 하는 일에 대해 항상 단순 워커 모드로 기능 개발만 하고 끝낼 것이 아니라 영향 가는 부분에 어떤 문제가 발생할 수 있는지 추가적인 기능으로는 어떤 것들이 필요할지 등 확장시켜 생각해보는 것이 중요할 것 같다. 더 나아가서는 이러한 부분을 직접 구현해보고 문서화 시켜서 사람들에게 설명해보는 연습도 한다면 금상첨화일 것 같다.

긴 글 읽어주셔서 감사합니다🙏 

안녕하세요.

저는 현재 판교에서 데이터 엔지니어로 일하고 있는 개발자1(Beom)입니다. 이번 포스팅에서는 같은 회사에 다니고 있는 동기인 개발자2(Gary)와 약 1년여간 진행했던 토이프로젝트에 대해서 회고해보려고 합니다. 

먼저 간략히 1년간 어떤 토이프로젝트를 진행했는지에 간단히 설명하도록 하겠습니다. 저희가 만든 서비스는 Moobe(무브)라는 서비스로 유튜버들이 다녀간 장소들을 맵(MAP)화 시켜주는 서비스입니다. 먹방 컨텐츠를 보며 한 번씩은 '나도 저기 꼭 가봐야겠다!'라고 생각한적 없으신가요? 그럴때 도움이 될만한 서비스입니다.

백문이불여일견이라고 한 번 직접 보고 오시죠!!!

https://moobe.co.kr/

대충 감이 오시나요???

저희가 1년 동안 토이프로젝트로 개발한 무브(Moobe)는 Map of Youtube의 약어이자 Move(움직이다) 와의 비슷한 발음을 통해 '유튜버들이 다녀온 곳으로 이동하다'라는 느낌을 줄 수 있는 중의적 의미를 내포하고 있습니다. 맛집 찾을 때 자주 사용해 주시면 감사하겠습니다😃

그럼 오늘 포스팅을 남기는 본 목적으로 돌아와 1년 동안 개발을 어떻게 진행해왔는지 Moobe서비스는 어떻게 만들어 졌는지에 대해 이야기해보도록 하겠습니다.

때는 바야흐로....2019년 8월 7일...

동기 몇 명이 모여있는 방에 개리의 위와 같은 발언에서 시작되었습니다. 다른 동료들은 별관심을 보이지 않았지만 이전 토이프로젝트를 한 번 진행해보고 또 다른 토이프로젝트를 물색하고 있던 찰나였기에 '한 번 들어나 볼까?' 하는 마음으로 ✋손을 들어봅니다.  (혹시 개인적으로 진행했던 이전 프로젝트가 궁금하시다면 2018 개발자 Life 회고 참고해주세요_)

이렇게 둘의 프로젝트는 시작되었고 '쇠뿔도 단김에 빼라'는 말이 있지 않겠습니까? 개리의 아이디어와 저의 추진력이 합쳐지며 바로 작업에 돌입하게 되었습니다.

Again..사실 개리와의 토이프로젝트는 처음이 아니였습니다. 기존 한 번 시도했었던...........프롲ㅌ 있었습니다. 넘어가겠습니다.

기왕하는거 제대로 하고 싶어 서비스 개발에 대한 기획문서를 작성했습니다. 서비스 기획 배경과 컨셉 그리고 1차 구현 목표들을 PPT로 만들어 보았습니다. 대충대충 하고 싶지 않았습니다. 이 프로젝트는 '진지'했으니까요

다음에 기회가 되면 처음 시작이되었던 기획 문서와 PPT도 공개해보도록 하겠습니다.

그렇게 저희는 개발스펙을 정하기 시작했습니다. 일단 저와 개리는 현재 막 7년 차에 접어든 개발자로 신입당시에 웹개발 직무로 시작하였습니다. 지금도 물론 웹개발을 하고 있긴하지만 데이터쪽과 오픈소스를 다루고 있습니다. (뭐 크게 궁금하시진 않을테니 넘어갈게요.)

1. 토이프로젝트의 목적 (익숙한 기술을 조심하라)

일단 토이프로젝트의 목적 자체가 머릿속의 아이디어를 취미삼아 개발하는데 목적이 있을 수 있습니다. 이러한 경우 익숙한 기술로 빨리 만드는 것도 중요하지만 회사 업무에서 다루지 않는 언어나 프레임워크를 학습하며 적용해보는 것도 큰 도움이 될 수 있습니다.

그래서 프론트(Front)쪽은 처음 Vue.js를 사용해 볼까 하였지만 이미 개리는 Vue.js를 사용하고 있었고 React를 사용하는게 어떻겠냐고 물었습니다. 이에 저는 아주 명쾌히 대답해주었습니다. 

"그래 그럼 너가 리액트로 프론트를 해라^^" 라고  😊

그리고 저는 백엔드(Backend) 쪽을 맡기로 하였습니다. 

정리해보자면

Front : React & Redux + Javascript +Kakao MAP  

Backend : SpirngBoot + Java + JPA + MYSQL + Google Oauth

2.  소스코드 관리의 꽃 GIT

저희는 협업을 위한 툴로 Git을 사용하였고 개발하기전 모든 기능 개발에 대한 Issue를 발행하고 각자가 맡은 기능들은 해당 feature에 개발한 후 검토하고 Merge하는 방식으로 진행하였습니다. 개리는 프론트 쪽을 진행하였고 저는 백엔드 쪽을 진행하였기에 각자가 맡은 Feature을 Merge할 때에 크게 충돌이 나거나 하는 문제는 발생하지 않았습니다.  약 1년 동안 84개의 Issue를 등록하였고 그 중 82개가 Closed된 상태입니다.

지금에 와서 보니 뿌듯뿌듯🍀하네요...

이슈를 만들 때 커스텀 라벨(label)도 만들어 사용하였습니다. 해당 이슈가 기존 기능을 보완하는 이슈인지 새로운 기능을 개발하는 이슈인지 라벨만 보고도 알 수 있습니다.

저희는 Git에서 무료로 제공하는 private repo를 사용하고 있습니다.

위에서 보시다 시피 첫 커밋은 8월 11일⭐️ 입니다.  시간 진짜 빠르다......

3. 악당(마음속 악당)이 너무 많다.

프로젝트를 1달도 아니고 2달도 아니고 6달도 아니고 1년😱 동안 진행하다 보니 서로가 손을 놓고 지냈던 적도 있었습니다. 그 이유야 다양하겠지만 사실 저의 경우는 귀찮음이 제일 컸습니다...아니 회사 일도 하고 운동도 해야되고 개인 공부도 하고 포스팅도 해야하는데 프로젝트까지 해야한다고 생각하니 가끔은 가슴이 너무 먹먹했습니다....너무 해야할게 많다보니 빨리 빨리 움직여서 하면 좋으련만.....그 반대였습니다...그냥 회사 일 끝나면 그냥 쉬고 싶은건 저뿐만이 아니겠죠...? 물론 개리도 저와 같은 생각과 감정을 겪었을 것이라고 생각합니다. 그렇게 저희는 서로가 두 세 달을 별다른 진척없이 보내기도 하였습니다.

하지만 함께 꾸는 명확한 목표가 있었기에 서로가 서로를 일으켜 세워주곤 하였습니다. 매주 한 번씩은 만나 서로 개발하기로 했던 기능들에 대해 리뷰하는 시간을 가지려 노력했고 한 주 마다 스스로가 해야할 기능에 대한 목표를 설정하였습니다. 

지금에와서 드는 생각은 이건 분명히 혼자 진행했다면 중간에 때려치고도 남았을 것이라는 겁니다ㅎㅎ 유독 한 문구가 떠오르네요  '멀리가려면 함께 가라' 

마치며

쓰다보니 길이 너무 길어질 것 같아 이번 포스팅은 여기서 마무리 해보려고 합니다.

1년 길다면 길고 짧다면 짧은 시간 동안 (짧지는 않았음...) 같이 개발하며 귀찮아서 손을 놓고 싶었던 적도 있었습니다. 하지만 그럼에도 여기까지 올 수 있었던 데에는 같은 곳을 바라보며 함께 해주는 동료가 있었기 때문이라고 생각합니다.

함께 토이프로젝트를 시작했을 때 1차 목표에 이르기 까지 1년이라는 시간이 걸렸습니다. 빠르진 않았지만 완성도 있는 서비스를 만드는데 집중하였습니다. 이제부터가 진짜 시작이라고 생각합니다. 아직 많이 부족한 시스템이지만 이 글을 보시는 분들께서 방문해주시고 피드백 주신다면 앞으로 서비스가 커나가는데 정말 많은 힘이 될 것 같습니다. 

 2편에서는 시스템을 개발하면서 겪었던 이슈들에 대해서 다뤄 보도록 하겠습니다.

긴 글 읽어주셔서 감사합니다.🙏

이전에 적어놓았던 독서노트 문구중 공유할만한 문구 몇 가지를 소개해볼까 한다. 어떤 책인지는 적어놓지 않아 모르겠다ㅠㅠ

개발자로 일을 하고 있지만 나 또한 처음 개발자로 취업한 것이 결코 코딩을 하는 것이 즐겁거나 재미있어서가 아니였다. 하지만 지금은 하루 하루 코딩하며 개발자로서의 삶을 살아 갈 수 있다는 것이 큰 기쁨이다. 어떻게 이렇게 된걸까?라고 생각을 해보면 분명 힘든 시절이 있었다. 남들과의 비교로 내 실력이 형편없어 보일 때 오는 좌절감과 특정 기능 구현에서 막혔을 때의 막막함이 있었지만 그런 고통 속에서 나는 하루 하루 성장해 나갔던 것 같다. 그렇게 다양한 문제들에 직면하고 해결하는 과정, 비교로부터오는 좌절감을 극복하기 위한 공부는 내 개발실력을 조금씩 향상시켜주었다. 사람은 이기적인 동물이라 내가 잘하는 것은 재밌다고 느낄 확률이 크고 잘 하지 못하는 것에 대해서는 하기 싫은 법이다. 적성에 맞는지 안맞는지는 내가 그 일을 '잘한다'라는 생각이 들 위치까지 올랐을 때 잘함에도 불구하고 흥미를 느끼지 못하거나 더이상 하고 싶지 않을 때 생각해봐도 충분하다고 생각한다. 일단 지금의 일을 잘하기 위해 노력부터 해보자.

아래의 문구들은 나의 위의 생각들을 뒷받침해주는 내용이기에 공감이 가서 노트에 적어 놓았던 것 같다.

• 인생을 행복하게 보내려면 자신이 좋아하는 일을 해야 한다고 말하는 사람이 많다. 자신이 좋아하는 일을 해야 능률이 오르고 집중할 수 있다고 말이다. 그러나 처음부터 자신이 좋아하는 분야를 선택해 평생 자신의 직업으로 삼는 사람이 얼마나 될까? 애석하게도 그런 사람은 1,000명 중 한 명이 될까 말까다. 더구나 자신이 좋아하는 회사에 들어갔더라도 본인이 희망하는 부서에 배치되고, 자신이 원하는 일을 하는 사람은 1만 명 중 한 명도 되지 않는다. 그렇다면 1,000명 중 999명 1만 명 중 9,999 명은 불행하고 좋아하지도 않는 일을 억지로 해야 하기 때문에 능률이 떨어진다고 봐야 할까? 그렇지 않다. 오히려 자신이 좋아하지 않는 분야에서 출발했지만 그 분야에서 두각을 나타내는 사람이 크게 성공할 수 있다.

• 자신에게 주어진 일이 천직이라는 마음으로 즐겁게 일하는 것이 중요하다. 주어진 일이라서 어쩔 수 없이 한다는 생각을 버리지 않으면 절대로 일하는 고통에서 벗어날 수 없다.

• 자기가 좋아하는 일을 추구하는 것은 유토피아를 찾는 것과 같다. 유토피아는 화려하지만, 현실에서는 절대 이루어질 수 없다. 유토피아는 유토피아일 뿐이다. 그래도 유토피아를 현실에서 이루고 싶다면, 지금 자신 앞에 놓인 일을 먼저 사랑하라.

• 할 수 없다고 생각하면 아무것도 할 수 없지만, 할 수 있다고 믿으면 아무리 캄캄한 어둠 속에서도 반드시 길어 보이는 법이다.

해당 내용은 '소프트웨어 장인'이라는 책의 Chapter11장의 '잘못된 면접 방식'이라는 주제에서 와닿는 내용 몇 개만 발췌한 내용이다. 많은 분들이 공감할 거라 생각한다. 물론 아닌 분들이 계실수도 있겠지만 그 회사의 그 업무에 맞는 면접질문을 하는게 가장 좋다고 생각한다. 읽어보면서 공감가는 부분과 공감가지 않는 것에는 어떤 것이 있는지 생각해보며 읽으면 좋을 듯하다. 해당 내용들은 내게 공감이 많이 되었던 내용들만 추려 포스팅한 것이다.

1. 똑똑한 척하는 면접관을 세운다.

면접관이 지원자보다 똑똑하거나 더 우월해봉고 싶어해서는 안 된다. 면접관의 사사로운 즐거움을 위해 지원자를 힘든 상황으로 몰아붙이고, 자신의 직함, 권한, 지식같은 것들로 지원자를 압도하고 싶어 해서는 안된다. 어느 정도 경험이 있고 실력있는 개발자라면 면접관의 성향을 즉시 알아채고 같이 일하기 싫다는 생각을 할 것이다. 지원자 앞에서 겸손하고 정직해야 한다. 지원자를 프로페셔널 개발자로서 대하고, 채용을 위한 평가나 취조가 아니라 당신이 존주우하는 누군가와의 유익한 기술 토론이 되도록 면접을 이끌어야 한다. 무엇보다도, 지원자의 이야기를 경청하고 그에게 마음을 여는 것이 중요하다. 

2. 답을 모르는 질문을 한다.

면접관으로서 어떤 질문에 어떤 답변이 나와야 하는지 잘 모르겠다면 채용중인 직무와 관련해서는 그다지 중요한 질문이 아닐 가능성이 높다. 해당 직무에 대해서 잘 알고 있다면 무엇이 중요하고 무엇이 중요하지 않은지 이미 알고 있을 것이다. 엉뚱한 질문으로 지원자를 혼란스럽게 하거나 잘못 이끌지 말자. 팀 동료에게 흔히 하지 않는 질문이라면, 팀 동료가 짜증을 낼 질문이라면, 지원자에게도 삼가해야 한다.

3. 종이에 코드를 작성하게 한다.

지원자에게 종이나 화이트보드에 코드를 작성토록 하는 것은 참으로 바보 같은 면접 방법이다. 면접관 스스로도 할 수 없는 일이나 실제 업무 현장에서 부딪히지 않을 상황을 지원자에게 요구해서는 안된다. 실제 업무에서도 종이에 테스트 코드 작성, 코드 리펙토링을 하는가? 고등학교 교사가 학생들에게 알고리즘의 의사 코드를 작성하라고 하는 것과 프로페셔널 소프트웨어 개발자를 채용하는 것은 다르다. 자신의 도구와 기술을 마스터하고 테스트와 리펙토링을 통해 잘 작성된 코드를 만들 수 있는 개발자를 찾아야한다.

4. 알고리즘 문제를 낸다.

알고리즘 무누제를 코딩 면접 과제로 선택하는 면접관들이 많다. 시스템 개발에 필요한 상당수의 업무들이 알고리즘에 대한 깊은 이해를 필요로 하지 않는다. 그럼에도 불구하고 "지원자의 문제 해결 능력을 보아야 한다"라고들 이야기한다. 물론 틀린 이야기는 아니지만 알고리즘 문제 대신 회사의 실제 프로젝트와 가까운 연습문제를 통해서도 '문제 해결 능력'을 평가할 수 있다. 여러 시스템의 문제들 중 거의 대부분이 알고리즘이 어떻게 작성되었느냐와는 관계가 없었다. 테스트가 덜 되었거나 또는 좋은 테스트 방법이 준비되지 못했거나, 잘못된 설계, 떨어지는 응집성, 깊은 종속성, 새 기능 추가 시 부족했던 리팩토링, 지속적인 요구사항 변경, 도메인 모델이 꼼꼼하지 못했거나 등이 가장 흔한 문제였다. 이러한 것들이 '실전 문제'였다. 알고리즘은 절차적이고 함수적인 형태로 구현된다. 알고리즘을 만들 때 비지니스 도메인 모델이나 클래스를 만들지는 않는다.

시스템의 주요 문제가 알고리즘이 아니라면 코딩 면접 때 알고리즘 문제 대신 실제 문제와 가까운 과제를 제시해야 한다. 지원자가 비즈니스 도메인을 표현하고 솔루션을 설계할 역량이 있는지 집중해야 한다. 테스트 주도 개발이나 설계에 스킬이 뛰어난 개발자를 찾고 있다면 그 부분을 반영할 수 있는 코딩 문제를 제시해야 한다. 애플리케이션이 온통 알고리즘에 대한 것이라면 당연히 알고리즘 개발 역량을 평가해야 한다. 요지는 코딩 면접에 알고리즘 문제를 내야 하느냐의 여부가 아니라 프로젝트를 위해 실제 필요한 역량이 무엇인지, 무엇이 가장 가치 있는지를 면접용 코딩 문제에 잘 반영하고 있어야 한다는 것이다.

블로그를 처음 시작하게 된 건 2014년이었다. 처음 시작은 네이버 블로그에서 부터시작했었다.

처음에 블로그를 시작하게 된 계기는 2014년 9월쯤 회사에서 블로그를 만들고 일주일에 하나씩 글을 쓰라는 반강제적인 요구에 의해서 였다. 그렇게 나는 처음 포스팅이라는걸 해보게 되었다. 내가 이렇게 포스팅 하는 글을 남들이 본다고 생각하니 어디서 부터 어떻게 써야할지도 되게 막막했었던 기억이 난다. 그래서인지 포스팅 하는 것 자체가 나에겐 스트레스로 다가왔고 자연스럽게 각자의 팀에 배정되고 나서 부터 터치를 받지 않게 되자 포스팅과는 당연시스럽게 거리가 멀어졌다.

그렇게 6개월 정도 흐르고 다시 포스팅을 시작하게 된 것은 내가 다른 블로그 글들로 부터 많은 도움을 받고 있고 나도 이렇게 글을 남기면 남들이 내 글을 보고 도움을 받을 수 있겠다는 생각에서였다. 그렇게 나는 회사에서 업무를 하다가 처리했던 기술 이슈들 삽질, 그리고 경험들을 블로그에 남겼다. 하지만 이전과 같이 블로그에 글을 쓸 때 마다 정말 내가 겪고 처리한 이슈이외에도 관련된 내용들을 수집해 정말 누가 봐도 괜찮은 포스팅을 하기위해 노력하다보니 글 하나를 쓰는데 많은 시간이 걸렸다. 그렇다보니 일주일에 포스팅을 하나씩 하자고 마음먹었던 것과는 달리 한 달에 하나 두 달에 하나씩 쓰고 있는 나의 모습을 발견하였다.

그렇게 포스팅을 하는데 회의감을 느꼈고 또 잠깐의 공백이 생겼던 것 같다. 포스팅을 하고 있지 않던 그 기간동안 느꼈던 것은 '그래 그냥 누군가 보는데 의식하지말고 정말 그냥 내 개인 웹 노트라고 생각하고 너무 부담갖지 말고 포스팅을 해보자'라는 생각이 들었다. 그즈음이 광고관련 팀으로 이동을 했을 때라 어느정도 광고에 대한 개념도 생겨있었고 adsense를 달아 수익화도 해보고 싶다는 생각이 들었다.

그래서 나는 naver블로그에서 tistory블로그로 갈아타게 된다. 기존의 naver블로그의 글들을 evernote를 통해 tistory로 옮기고 정말 내 개인 노트에 글을 작성하듯 단순 한 것부터 내가 문득문득 든 생각, 읽었던 좋았던 문구들을 가볍게 써나가기 시작했다. 그렇게 포스팅을 하는데 부담감이 사라지니 자연스레 글을 쓰는 횟수도 많아졌고 자연스레 방문자수도 증가했다. 물론 심도 있는 글들을 많이 쓰지 못해 이탈률이 높긴 했지만 그 전처럼 포스팅 하나하나를 쓰는데 너무 많은 시간과 노력을 들이며 부담감을 느끼고 싶지 않았다. 

그렇게 티스토리 블로그를 운영한지 벌써 4년차가 되어가고 작년 2019년의 평균 하루 방문자수는 400~600정도 사이에 이르렀다. 그러다가 최근 처음으로 하루 방문수가 2020/02/18, 2020/02/19 이틀 동안 1,000이 넘었다.

구글 애널리틱스를 보면 /267 개발자 직장생활과 실력향상 관련 좋은 글 번 글이 소히 말하는다른 외부 sns를 통해 공유되어 트래픽이 터진 것이다.

해당 글은 이전에 내가 읽었던 개발자의 커리어와 관련된 글 중 인상깊었던 글을 모아 포스팅했던데 지나지 않았다. 포스팅을 하는데 오래걸리지도 않았을 뿐더러 많은 노력을 하진 않았지만 해당 글로 인해 이틀간이나 하루 방문수가 1,000을 넘게 되었던 것이다.

물론 하루 방문수가 중요한 것은 아니다. 내가 느꼈던 것은 '뭐라도 하지 않으면 아무것도 일어나지 않고 내가 들인 노력, 시간과는 별개로 컨텐츠가 사람들에게 많이 검색되고 읽힐 수 있다는 것이다.' 나는 작년부터 유튜브 컨텐츠도 만들고 있지만 블로그 글들의 통계를 보며 정말 유튜브도 너무 컨텐츠를 잘만드려고 노력하다가 한달에 한번도 안올리는 것 보다는 가볍게 자주 올리는 것이 내 목표인 구독자 천명에 더 빨리 다다를 수 있을 거라는 생각이 들었다. 

그리고 항상 느끼지만 꾸준함에 대한 어려움을 느끼고 무엇인가를 꾸준히 하는 사람들에 대한 존경심을 가지게 된다. 꾸준함은 또 하나의 재능이라고 생각하고, 지금 내가 하고 있는 기술블로그, 유튜브, 운동, 개발 모두 남들과 비교했을 때 느리더라도 꾸준히 앞으로 한 발짝 한 발짝 나아가다 보면 좋은 결과가 있을 거라고 생각한다. 아래의 말로 포스팅의 마무리를 지어보려 한다. 모두 원하는 목표에 도달할 때 까지 화이팅이다!

사람마다 꽃피는 시기는 다른 법이다.