All Articles

2020년 회고: 개발자라는 환상

오랜만

1년만의 글이다. 아무리 블로그에 글을 안써도 한 해를 돌아보는 글은 작성하고 싶다.

19년 회고가 비전공자에서 개발자가 되는 과정이 담긴 글이었다면, 20년 회고는 개발자로 일하면서 느낀점을 얘기하고 싶었다.

2020년을 보내면서 비전공자 -> 개발자 취업 루트가 인기가 더 많아졌다는 것을 실감할 수 있었다. 이 글에서는 똑같은 길을 밟은 사람으로서 느꼈던 점을 중심으로 전달하고 싶다.

간략하게 소개하자면 연차로는 2021년 기준으로 3년차이다. 그치만 실질적인 업무 경력은 1년 2개월이다. 배움의 기간까지 포함하면, 처음 시작하고 공부 놓은 기간을 제외하고 총 1년 8개월이다.

어떻게든 경력을 후려치려는 이유는 실력에 관한 자신감 부족이라고 말하고 싶다. 후후…

개발자의 삶

(내가) 흔히하는 착각

1. 연봉

개발자가 되면 타 직군대비 좀 더 높은 연봉을 받을 수 있을 것이라고 착각했다.

솔직히 취업하기 전까지 막연히 이런 생각을 많이 했다. 당장은 못받더라도 열심히 하면 연봉을 크게 올릴 수 있을거라 생각했다. 현실은 생각과 꽤 다르다. 이 업계도 최저는 다른 업계랑 똑같다. 그리고 올리기도 쉽지 않다. 그냥 편차가 매우 클 뿐이다. 다른 직종처럼 어떤 회사를 다니는지에 달려있다고 생각하는게 맘 편하다. 타직군대비 높은 연봉이 아예 틀린 말은 아니긴 하지만, 취업과 연봉만 보고 오기에는 좋은 선택지는 아니라고 본다.

특히 비전공자 루트는 현재 포화시장에 가깝다고 생각하기 때문에, 양질의 삶을 살고 싶다면 즐기면서 할 수 있을 것 같은지 곰곰히 생각해봤으면 좋겠다. 초반에는 신나서 전직하고 싶어하는 친구들에게 개발자를 권유하고 그랬는데, 지금 생각하면 내가 미쳤나 싶다. 오지랖도 오지랖인데, 일하면서 느끼게 되는 개발자만의 고충을 고려하지 못했다. ‘개발 일에 재미를 느끼지 않는다면 과연 개발자는 할만한 직업인가?’ 라는 질문에 나는 예라고 대답할 수 없다.

‘뭐 엄청 미친듯이 해서 좋은 회사에 높은 연봉을 받고 들어가고, 이후는 적당히 현실에 안주하면서 산다’ 라는 선택지도 있을 수 있다. 그치만 그정도 열정이라면 굳이 개발자로?

아무튼 이직에 관해서 얘기하면서도 언급하고 싶은데, 이런 마음이 주가 되면 목표했던 높은 연봉은 힘들겠다는 생각이 요즘 많이 든다.

2. 커뮤니케이션

비개발자 출신이라 비개발자 입장으로 커뮤니케이션을 더 잘할줄 알았다.

내게는 이게 꽤 현타오는 부분이었다. 다른 일을 1년정도(사실 긴 경험은 아니다) 했기 때문에, 그래도 좀 더 비개발자 입장에서 잘 소통할 줄 알았다. 실제로는 전혀 그렇지 않았다. 오히려 비전공자라 개발자 문화에 더 빨리 스며들고 싶은 마음이, 다른 직군과의 커뮤니케이션에서 개발 용어를 남발하게 만들었다. 회의에서 나도 모르게 남발하는 개발 용어를 뒤늦게 인지하면서, 면접에서 비전공자 입장의 커뮤니케이션을 어필했던 내가 부끄러웠다.

약간 세는 부분은 있지만, 용어에 관해서 드는 생각이 하나 있다.

과거에는 업계의 용어를 능수능란하게 써서 얘기하는게 내 전문성을 잘 표현하는 것처럼 느껴졌다. 사실 일부 업계에서는 아직까지 꽤 먹히는 것 같다. 그치만 이건 좋은 커뮤니케이션 방법이라고 생각할 수 없다.

특히 이런 모습은 전문가라고 불리는 사람에게도 종종 볼 수 있었다. 다른 일을 했을때 운좋게도 업계에서 전문가라고 불리는 사람들과 일을 할 기회가 많았는데, 다른 이해관계에 있는 사람에게 전문 용어를 남발하는 모습을 꽤나 볼 수 있었다. 그리고 해당 용어를 모르는 상대방을 이해하지 못하기도 했다.

오히려 연차가 쌓일수록 쉽게 간과할 수 있는 부분이 아닐까라는 생각도 든다. 업무에서 커뮤니케이션의 목적은 주제에 관한 문제를 잘 해결하는 것이다. 그런데 개발 용어를 능수능란하게 사용해서 상대방이 본질에 집중하기 더 어렵게 만든다면, 과연 좋은 커뮤니케이션이라고 볼 수 있을까? 뭐 해당 용어를 이해하지 못한 상대방을 탓한다면 딱히 할말은 없다.

그래도 한 번 쯤은 봤을거라고 짐작해본다. 개발 용어를 남발하는 나와 약간 벙찐 상대방의 모습을. 회의 구성원이 모두 이해할만한 용어가 아니라면 최대한 풀어서 설명하자.

장점과 단점

그래도 개발자로 일해서 좋은 점이 많다.

장점

  1. 업무 환경이 비교적 자유롭다

    일 자체가 재택근무를 해도 지장이 없는 경우가 더 많다. 사실 올해 내내 거의 재택근무를 한 나로서는 마냥 긍정적이지는 않다. 자유만큼 뒤따르는 책임이 많다. 정신적으로 고립감을 느낄 수도 있다. 가끔 워라밸의 붕괴를 경험할 수도 있다. 그치만 할 수 있는데 안하는 것과 할 수 없는 것은 천지차이라고 생각한다. 스스로의 업무 환경을 주도적으로 가져갈 가능성이 있다는 점은 메리트가 있다.

  2. 도메인에 크게 얽매이지 않는다

    일반적으로 이직시 도메인의 영향을 많이 받는다는 점을 고려해보면, 꽤 큰 장점이다. 물론 문제 해결 측면에서 도메인에 관한 이해도가 중요하기는 하지만, 주변을 봤을때 이직시에는 크게 구애받지 않아보인다. 경력에 상관없이 원하는 도메인으로 이직하는 분들을 많이 봤고, 얘기를 들어봤을때 기존 경력과 도메인 영역이 달라서 연봉을 낮췄다느니 이런 소리는 들어본 적이 없다. 오히려 높였으면 높였지.

  3. 관종이라면 행복할 수도 있다

    오바해서 표현했다. 나는 관종은 인정받고 싶은 욕구가 좀 더 표출된 형태라고 생각한다. 그래서 개발자는 관종에게 좋은 직업이다. 개발자의 세계에는 내가 좋아하는 관심사를 공감해줄 사람과 환경이 준비돼있다. 관심사를 공유하는 일이 보편적이기 때문이다. 업계에서는 좀 바람직한 예처럼 보여지는 것 같다. 뭔가 자기가 한 결과물을 보여주거나, 평소에 관심있는 기술 글을 공유하면서 의견을 나누는 것. 문화 자체가 이런 부분에 있어서 굉장히 긍정적이다. 나는 이렇게 적극적으로 공유하는 직업을 본 적이 없다. 관종끼가 어느정도 있고 개발을 싫어하지 않는다면, 꽤 즐거운 경험일거라고 생각한다.

적고보니 많지는 않다.

개인적으로는 이 일을 하면서 몰입감을 느낄 때가 많아서 좋다^^

단점

  • 업무 외의 시간 투자가 지속적으로 필요하다

    개발 자체가 너무너무 즐거운 사람에게는 해당하지 않는다. 그치만 개발자를 하나의 직업으로만 바라봤을때 이 부분이 제일 중요한 단점이라고 생각한다. 이 부분은 크게 두 가지로 나누고 싶다. 미리 말하자면 전공이든 비전공이든 중요한건 실력이지만, 비전공자는 보통 배움의 기간이 절대적으로 짧고 나도 비전공자니까 그냥 비전공자로 퉁치겠다.

    1. 비전공자 신입의 입장

      이건 어디까지나 개인적인 경험에 의거한 입장이다. 일단 비전공자가 처음 취업을 하면 당장 업무를 진행하기에 실력적으로 부족한 부분이 많다. 보통 비전공자를 뽑는다고 하면, 당장의 실력보다는 어느정도 간단한 실무는 처리할 수 있으면서 앞으로의 성장 가능성을 우선하여 본다고 생각한다.

      그런데 내가 생각했을 때 성장 가능성을 본다는 말의 의미는 ‘취업하고 나서도 공부 열심히해서 회사에 보탬이 되어라.’ 대충 이런 느낌이다. 솔직히 업무 외에 따로 공부 안하면 성장하기 힘들다. 사실상 뽑는 순간부터 염두해 둔 부분이라고 볼 수 있다.

      취업해서 회사 코드를 보는 순간 체감이 된다. 일단 공부하면서 혼자 짜던거랑 회사의 프로덕트 코드랑 규모가 당연히 다르다. 물론 공부하면서 프레임워크나 꽤 큰 라이브러리 코드를 어느정도 뜯어본 사람이라면 딱히 회사 프로덕트 코드라고 방대하게 느끼지는 않을 것 같다. 이런 사람은 어떤 환경이든 잘 적응할 것이다.

      암튼 처음에는 솔직히 약간 막막한 느낌이 있다. 나같은 경우에는 첫 회사에서 처음 1-2주는 코드 파악하라고 시간을 줬는데, 코드 파악이 아니라 잠만 쏟아져가지고, 그냥 이슈 티켓에서 간단해보이는거 하겠다고 하고 코드를 파악했다. 목표가 좀 뚜렷하게 있어야지 잠에 들지 않는다.

      여기에 두 가지 관문이 더 있다. 구현과 구현 코드의 품질이다. 비개발자 입장에서는 구현만 되면 끝이지만, 개발자는 어떻게 구현했는지가 굉장히 중요하다. 서비스는 유지하는 동안 지속적인 관리(기능 신규 추가, 삭제, 변경)이 필요하고, 이 작업은 미래의 나 혹은 누군가가 해야한다. 코드의 퀄리티를 신경쓰지 않으면 미래의 나를 포함한 구성원이 힘들어지기 때문에(결과적으로 비즈니스의 일정에 차질이 생길 수 있다), 개발팀은 이 부분에 많은 신경을 기울인다.

      코드 파악하고 적응하는건 자연스럽게 된다고 해도, 구현 품질을 신경쓰면서 구현하는 일은 쉽지 않다. 지금도 구현은 어떻게든 시간만 주면 한다고 쳐도, 구현 품질까지 신경쓰면 어렵고 앞으로도 어려울 것 같다. 결론적으로 주니어일때 업무 외 시간 투자는 필연적이다.

    2. 이직러의 입장

      현재에 만족한다면 해당 사항은 아니다. 큰 욕심 부리지 않고, 비슷한 회사로 이직해 나가거나 계속 회사에 남을 수도 있다. 하지만 비전공자라면 처음 취업한 회사의 환경이 그렇게 좋지않은 경우가 많을 거라고 감히 예상해본다. 그리고 개인적으로는 개발자가 가지는 장점을 많이 포기하는 선택이라고 생각한다. 내가 생각하는 개발자는 노력 여하에 따라 연봉을 포함한 업무 환경을 주도적으로 가져갈 가능성이 높은 직업이다.

      다시 이직러의 관점으로 보면 업무 시간만 가지고는 비교 우위를 가지기 어렵다. 업무에 익숙해져서 반복된 일상이라면 당연한 얘기다. 업무를 굉장히 능동적으로 대하고, 스스로가 도전적인 환경을 계속 만들어나간다면 조금 다를 수도 있을 것 같다. 그치만 회사는 스스로의 통제 범위에서 벗어나는 부분이 있기 때문에 항상 성립하는 경우는 아니라고 생각한다.

      앞서 말한 개발자가 전문성을 공유하는 이 문화는 개발자 개개인의 노력의 산물이다. 직장인 신분에서 개발자만큼 블로그 글을 쓰고, 책을 집필하고, 강의를 촬영하는 직업이 있을까? 심지어 자기만의 프로덕트를 만들어서 공유한다. 이 결과물은 당연히 업무 외 시간에 행해지는 것들이고, 전 세계의 수 많은 개발자가 이런 일들을 지속해나감으로서 생태계가 활성화된다.

      뭐랄까 한마디로 열심히 하는 사람이 많다. 당장 우리 회사를 봐도 자정이나 새벽에 작업물을 올리는 사람이 종종 있다. 대부분이 개발자다. 누가 시켜서 하는 일은 아니다. 그냥 작성한 코드가 별로 맘에 안들거나, 일을 마무리하고 싶으면 남아서 계속 하는 것 같다. 혹은 밤 중에 최근 개인적으로 작성한 코드를 공유하기도 한다.

      이것 때문에 지속적인 성장에 관한 압박이 스스로의 목을 죄어 올 수도 있다. 현재 직장보다 좋은 곳을 가려면 열심히 해야하는 것은 어떤 일이나 마찬가지지만, 문화적으로 좀 더 강요받는 느낌이랄까? 겉은 사람 좋아 보이게 웃지만 내면에는 비수를 품고 있는 그런 느낌이 들 때가 있다.

위에서 언급한 이유가 개발자 추천을 망설이는데 크게 일조했다. 대부분의 사람에게 직업은 생계 수단이다. 대부분의 사람이 맡은 일은 책임감 있게 수행하려고 노력하긴 하지만, 일과 관련하여 그 이상의 시간을 쏟고 싶어 하지는 않는다. 하지만 개발자는, 특히 짧은 기간 배우고 취업했다면, 취업 이후에도 지속적으로 시간을 투자해야만 한다. 개발에 재미를 느끼지 않는다면 금방 번아웃 될 거라고 생각한다. 그래서 개발을 체험해보면서 한번이라도 몰입해본 경험이 없다면 이 직업을 권하고 싶지 않다.

구직, 일, 이직

나는 돈미새다. 돈을 많이 벌고 싶다. 이 생각은 당분간은 바뀌지 않을 것 같다. 다만 말미에 지난 1년을 돌아보면서 생각의 변화가 조금 있었다.

첫 구직과 연봉

처음 개발자로서 항상 구직의 지향점은 돈에 맞춰져 있었다. 물론 아직까지 실현은 못하고 있다^^. 평범한 비전공자 입장에서 첫 선택지의 연봉은 꽤 가혹하다. 내 경험은 아니지만 주변까지 고려했을때 크게 두 가지 선택지가 있다. 100% 내 경험은 아니기때문에 추측이 있다는 점은 감안하면 좋겠다.

  • 서비스 스타트업
  • SI 업체

서비스 스타트업에 갔을때의 초봉은 대부분이 3500 아래이다. 경험상 대부분은 2600 ~ 3200 정도에서 맞춰진다. 물론 더 많이 받는 경우도, 더 적게 주는 경우도 있다. 그치만 막 엄청 열심히 하지 않고, 나처럼 그냥저냥 공부해왔다면 대부분 이정도 선에서 취업할 것이다. SI는 더 낮은 경우도 있긴 하지만, 주변 얘기를 들어보면 입사 난이도에 비해서 은근히 잘 챙겨주는 곳이 많은 것 같다. 그래서 경우에 따라서 3200 ~ 3500+ 정도를 받을 수 있는 것 같다. 당장의 돈이 더 중요하다면 오히려 적당한 규모의 SI 업체에 들어가는게 더 좋을수도 있다.

그치만 내 경우 SI는 일절 고려하지 않았다. 이유는 단순히 돈미새의 관점에서 봤을때 업계에서 고액의 연봉을 주는 회사는 SI 업체의 업무 방식이나 기술 스택과 거리가 멀었다. 시작은 조금 더 받을 수 있어도, 미래를 생각하면 가치가 떨어지는 선택이라고 판단했다. 여기에도 당연히 예외 케이스는 존재한다.

참고로 개인적으로 조사하고 여기저기 줍줍한 정보로 보면, IT 대기업에 가도 연봉 수준은 드라마틱하게 높아지지 않는다. 대부분은 4500 ~ 6000에서 결정되는 것 같다. 이 부분이 개발자의 연봉 수준이 타 직종대비 크게 메리트 있지는 않다고 말하고 싶은 부분이다. 이 금액은 우리가 생각하는 일반적인 대기업 연봉과 다르지 않다. 이후에도 그렇게 드라마틱하게 높아지지 않는다. 4년제 졸업했고 단지 취업과 돈이 목표라면 대기업 취준을 더 열심히 하는게 낫다고 생각한다.

특히 개발자는 상여가 별로 없다. 일단 스타트업의 경우 거의 대부분이 없다. 이게 꽤 큰 부분인데. 보통 대기업이 아니더라도 일반적인 중견기업 이상은 인센티브가 어느정도 나오는 경우가 많아서, 실질적으로 받는 돈은 최소 연 500-1000 이상 차이가 날 수도 있다.

우리가 생각하는 드라마틱한 연봉은 대부분 실리콘밸리(+다른 지역의 Google 같은 글로벌 기업)의 경우다. 이 동네 회사들의 대략적인 연봉은 구글 검색으로 쉽게 찾아볼 수 있는데, 이것저것 다 포함해서 대충 초봉 1억 8천 내외라고 보면 될 것 같다. 높은 세금을 감안해도 넘사벽 연봉임을 부정할 수 없다. 특히 경력이 쌓일수록 연봉이나 기타 대우가 좋아지는게 훨씬 드라마틱한 것 같다. 자세한 내용은 levels.fyi를 참고하면 좋다. 뭐 한국도 일부 뛰어난 개발자는 높은 연봉을 받는다. 그치만 나한테는 해당 사항이 없으므로 차치하자.

과거의 나처럼 연봉을 크게 기대하지 말라는 얘기를 예시를 들어서 하고싶었다. 뭐 현실은 현실이고, 어쨌든 높은 연봉을 받고싶은 마음은 변하지 않는다. 개인적으로 직장인의 가치는 연봉이 결정한다고 생각한다. 그렇다면 높은 연봉을 받기 위해서 어떻게 일을 해나가야 하는지, 회사 업무와 이직의 관점에서 얘기해보고 싶다.

회사와 일

회사에서 연봉을 높이는 방법은 당연히 연봉협상을 잘하는 것이다. (아 참고로 나는 아직 연봉협상을 한 적이 없다 ㅎㅎ) 연봉협상을 잘하려면 어떤게 필요할까? 당연히 회사 일(개발 업무)를 잘해서 성과를 증명하는 것이다. 처음 취업한 입장에서 굉장히 어려운 일이다. 당장 업무에 적응하기도 힘들고, 시켜주는 일도 간단한 업무일 확률이 높은데 어떻게 해야할까?

  • 주인의식을 조금 다르게 보기

    회사에서 주인의식을 가져야 한다는 말은 아니다. 주인의식을 가지고 일하라는 말, 많이 들어봤을 것이라 생각한다. 실제로 이전에 회사 대표님에게 이런 얘기를 들어본 적도 있다. 그치만 현실적으로 회사와 나(개인)의 관계는 갑을 관계로 볼 수 밖에 없다. 주인의식에 동의할 직장인이 얼마나 있을까?

    대신 이 말의 본질을 살펴보자. 회사의 대표인 것 처럼 일에 관심을 가지고, 책임을 가지고, 열심히 하는 것. 결과론적으로 그냥 일을 잘하는 것으로 귀결시켜도 된다고 본다. 회사에서 일을 잘하는 것은 개인에게도 큰 도움이 된다. 주인의식이란 말이 아니라 일 잘하기에만 집중해서 생각해보자.

    짧은 경험상 일을 잘하려면 프로덕트에 관심이 있어야 한다. 가장 좋은 방법은 회사의 프로덕트가 내가 사용하는 서비스(혹은 관심있었던 분야)면 된다. 평소에 사용하니까 좀 더 사용자 입장에서 생각해볼 수 있다. 그리고 결국 회사의 전반적인 구조는 수익을 내고 있는 프로덕트 중심으로 형성될 수 밖에 없기때문에, 포지션이 다른 동료들의 입장을 이해하는데도 큰 도움이 된다. 이게 잘 되면 회의에서 프로덕트에 관한 의견을 내는게 가능해지고, 그냥 시키는것만 하는 개발자에서 벗어날 수 있다. 개발할 때 엣지케이스를 줄일 가능성도 올라간다.

    신입은 코드에 관한 기여도가 상대적으로 떨어질 수 밖에 없다. 대신 프로덕트에 관한 의견을 적극적으로 개진하면, 개발팀을 비롯한 구성원에게 업무를 주도적으로 한다는 인상을 줄 수 있다고 생각한다. 더 좋은건 의견에 기술적인 기여가 더해지는 것이다. 관심 있으면 일도 알아서 몰입감 있게 할 수 밖에 없게돼서, 조금 모르는 부분이 있어도 의욕이 생긴다.

    그래서 처음 취업할때 웬만하면 회사 자체의 비즈니스에 관심이 가는 곳으로 갔으면 좋겠다. 내 경우에는 이전 회사와 현재 회사 모두 내가 사용하지 않는 서비스를 개발한다는게 아쉽다. 솔직히 자연스레 제품에 관한 관심이 멀어진 것 같다. 이런 경우에는 어떻게든 정을 붙이는 방법밖에는… 일을 하다보면 생각 외로 정이 생긴다. 이 글을 읽는 분들도 애정을 가지고 업무를 하면 좋겠다.

  • 기록하기

    시작은 항상 내가 한 일을 기록하는 것이라고 생각한다. 이게 습관이 돼야 여러모로 나중에 편해진다. 가장 작게는 오늘 무엇을 해야하는지 무엇을 했는지 기록한다. 해결하기 어려운 문제가 있었다면 어떻게 해결했는지 기록한다. 도움을 받았다면 어떤 도움을 받았고, 이 도움이 해결하는데 어떤 역할을 했는지 기록한다. 특히 어려운 문제의 경우 누구에게나 어려운 문제일 수도 있다. 업무 차원에서 공식적으로 관련 문서를 만들어서 기록한다면, 미래의 나 혹은 팀원이 코드의 컨텍스트를 파악하는데 도움이 된다.

    연봉협상은 앞서 말했듯이 스스로의 가치를 증명하는게 중요하다. 기록이 잘 돼있으면 당연히 연봉협상 때도 할 말이 정리된다. 사람은 망각의 동물이다. 아무리 임팩트 있는 일이었더라도 시간이 지나면 효과적으로 풀어내기 어렵다. 협상은 어려운 일이지만 흘러가는대로만 살면 회사에서 정해진 틀에서 벗어날 수 없다. 그리고 대부분의 회사는 가능한 적게 주려고 할 것이다. 그게 회사한테는 이득이니까. 그러니까 기록하자. 주도적으로 스스로의 커리어를 이끌어나갈 가능성이 높아지고, 이직시에도 큰 도움이 되니까 일석이조다.

  • 개발을 비즈니스 차원에서 생각하기

    지금 하는 개발이 비즈니스 차원에서 얼마나 임팩트가 있는 일인지 생각해보자. 기획에 따른 구현과 코드 퀄리티는 항상 중요하다. 하지만 여기에 너무 얽매이면 비즈니스 차원에서 손실이 발생한다. 모든 일은 결국은 비즈니스의 가치를 만들기 위한 것임을 상기하자.

    회사에서 특정 데이터를 보여주기 위한 라인 차트를 개발해야 하는 일이 있었다. 이 일은 라이브러리를 쓰면 단시간에 개발이 가능하고, 오랜 기간 투자할만큼 프로덕트 차원에서 가치있는 일은 아니었다. 그런데 기획상 기능과 디자인 시안을 동일하게 반영하기 위해서 커스텀이 꽤 필요했고, 나는 이걸 구현하려고 꽤 많은 시간을 소비했다. 도중에는 기능 구현하다가 라이브러리에서 버그도 발견해서 수정전까지 대체하기 위한 이상한 코드를 추가하기도 했다. 기능을 개발하기 전에 좀 더 비즈니스 차원에서 생각했다면, 당장 스펙을 줄이고 가장 필요한 부분만 먼저 구현하자고 제안할 수 있었다.

    너무 개발 자체에만 몰입하면 진짜 중요한 것들을 잊게 되는 것 같다. 때로는 구현 스펙을 과감하게 쳐내는게 회사 차원에서 더 도움이 될 수 있다.

자기개발과 이직

사실 연봉을 높이는데 제일 좋은 방법은 이직이다. 이직만큼 드라마틱한 연봉 인상률을 보여주는 건 없다. 스타트업에 취업한 신입의 경우는 중고신입으로 대기업에 가는게 제일 좋다.

그런데 이직이나 중고신입이나 내 수준을 높여야 가능하다. 자기개발이란 것을 해야하는데, 주변 개발자분들과 얘기를 나누면서 이 부분에 관한 여러가지 생각을 하게 됐다.

  • 목표 설정

    기존에는 앞으로 가고 싶은 회사를 연봉 중심으로 생각했다. 당연히 내가 공부해야 하는 부분도 해당 회사의 요구조건이 중심이 됐다. 내 방향성을 이렇게 설정해도 취준하듯이 의도적으로 시간을 투자하고 꾸준히 해나갈 수 있을줄 알았다. 그리고 공부를 안하면 순전히 게으른 내 책임이라고만 생각했다.(물론 맞는 말이긴 하다)

    그러다 개인적으로 참여하는 프론트엔드 챕터 미팅에서 다른 개발자분들과 얘기하다가 이 부분을 다시 생각해보게 됐다. 너무 돈미새가 되다보니까 정작 가장 중요한 나에 대해서 생각해본 적이 별로 없었다. 항상 회사에 나를 맞추려고 했던 것 같다. 어떻게 보면 강압적인 이 방식이 지속될 수 있을까 의문을 많이 가졌다.

    누군가는 가능할 수도 있다. 하지만 적어도 나는 해당하지 않았던 것 같다. 공부를 지속하는데 재미가 없어서 쳐지는 경우가 많았다. 어떤 회사를 가기위해서 특정 지식을 우선적으로 공부하는게 제일 빠른 길이라고 아직도 생각하긴 한다. 하지만 이 얘기는 지속성이 보장되어야만 성립한다. 보장되지 않는다면 빠른지 느린지 판단할 수도 없다. 차라리 흥미가 있는 부분을 지속적으로 파는 게 낫겠다는 생각을 했다. 적어도 이렇게 한다면 나라는 사람을 정의하고 표현하기는 훨씬 쉬워질 것이다. 그리고 회사에도 그만큼 명확하게 어필할 수 있을거라 생각한다.

    그래서 먼저 나라는 사람부터 정의해 나가려고 한다. 어떤 회사에 필요한 기술을 공부한다기 보다, 흥미가 생겨서 지속적으로 공부할 수 있는 기술에 집중하려고 한다. 좀 더 즐기는 사람이 되고 싶다. 물론 높은 연봉을 포기한 것은 아니다. 그치만 연봉부터 생각하면서 회사를 고려하지는 않으려고 한다.

    전문가라고 불리는 것도 이런 요소가 하나씩 쌓이면서 탄생하는 것 같다. 흥미 있는 부분을 공부하고, 점점 더 깊게 고민해 나갈수록 나만의 지식이 쌓일 것이다. 회사에서도 당연히 이런 경험을 고려해서 일을 맡길 가능성이 높아진다. 일련의 행위가 반복되다보면 결론적으로 나만의 전문성이 생기게 될 것이라 믿는다. Interactive Developer라는 유튜브 채널을 운영하고 계신 김종민님의 영상을 보면서 더욱 확고해진 생각이다.

  • 구직이나 이직이나 임팩트 있는 일을 자세히 보여주는 게 좋다

    일반적인 내용만 서술하는 건 어쩌라고다. 그런 문제는 당연히 처리할 수 있을거라고 생각한다. 문제 해결 경험을 기록하는게 습관이 되면, 이런 임팩트 있는 정보가 필요할때 아주 상세하게 적어내려갈 수 있다. 해당 문제가 상대방에게는 딱히 어려운 문제가 아니어도 괜찮다. 이 사람이 어려운 문제에 당면했을 때 어떤 자세를 가지고 어떻게 해결하는지 보여주는 것도 중요하다. 내가 가진 경험과 회사에서 원하는 경험이 일치하면 좋은건 당연한거니까 이 부분은 따로 얘기하지 않겠다.

    개발 일을 하다보면 얼떨결에 해결하는 경우가 생긴다. 문제는 해결했지만, 왜 해결됐는지 모르는 경우다. 이럴때 업무 시간에 조금 더 원인을 찾아보거나, 따로 시간을 내서 깊게 파보는게 좋다고 생각한다. 이런 과정에서 생각지도 못한 것들을 알게 되기도하고, 이거 자체가 임팩트 있는 일 중 하나가 될 수도 있다.

    내 경우에는 첫 이직을 하면서 프로덕트에서 발생하는 Memory leak을 일부 해결한 경험을 이력서에 적었는데, 내용 자체는 굉장히 별거 없고 거의 노가다식으로 해결했지만, 면접관 분들이나 아는 개발자 형님이 주니어치고 꽤 신선한 경험이라고 생각해주셨다. 그때 당시의 맥락을 생각해보면, 내가 해결할 수 없는 문제라고 생각하면서도 약간의 패기로 한번 봐보고싶다고 개발 리드분한테 얘기를 드렸었다. 삽질을 꽤나 많이 했고 완벽하게 해결하지는 못했다. 그래도 어느정도 Memory leak을 잡았고, 이때 일을 따로 정리했던게 결국은 나한테 도움이 됐다.

내용을 더 적어내려가고 싶지만, 이 글을 꽤 오래 붙잡고 있는 상태라 생략한다(…)

갑자기 돌아와서 2020년 벌어진 일

올해 가장 큰 일은 루비콘 밖에 없었던 것 같다. 하루 일과의 중심이 회사가 된 영향도 있고 개인적으로 많이 게을렀던 한 해라고 생각한다.

강제 퇴사

첫 회사의 본사 병합으로 2월 말에 퇴사하게 됐다. 선택지는 본사로 가거나 퇴사하거나 둘 중 하나였다. 결론적으로 퇴사를 결정했다. 같이 일하던 분들이 좋았는데 생각보다 일찍 헤어지게 돼서 아쉬움이 컸다. 첫 회사를 다니면서 제일 크게 느꼈던 부분은 회사가 직원을 어떻게 생각하는지에 관한 부분이다. 구직자 입장에서는 회사가 직원의 성과를 인정해주고 최대한 보상하려고 해주는지, 직원의 임금을 절감해서 이익을 얻는 것에 더 집중하는지 확인할 필요가 있다. 아쉽게도 내가 속한 회사와 본사는 후자에 가까웠다. 얘기하고 싶은 부분이 많지만 생략한다(…)

루비콘

이직 준비 겸 개발자로서의 팀 프로젝트를 경험해보고 싶었다. 마침 블로그가 인연이 돼서 한번 뵌 적 있었던 분이 루비콘 멘토링 프로젝트를 진행한다는 것을 알게 됐고 바로 지원했다. 각 멘토를 중심으로 팀을 나눠서 프로젝트를 진행했고 3월 - 5월은 작업 & 6월은 발표를 했다.

결과물과 과정에 아쉬운 부분도 있었지만, 나와 다른 포지션에 있는 사람들과 협업하는 경험이 처음이라 좋았다. 6월 발표는 오랜만에 문콘 경험을 되살리며 PPT도 열심히 만들고 팀원분과 발표도 직접 했다.

이후에도 루비콘 커뮤니티에 참여하고 있다. 한 10월, 11월쯤 돼서 루비콘에서 진행하는 프론트엔드 챕터 미팅과 UI Kit 만들기에 참여하게 됐다. 프론트엔드 챕터 미팅은 여러가지 개발 주제나 직장 생활 전반에 관해 얘기하는 자리였다. 개인적으로 개발자분들과 얘기하는게 즐겁기도 하고, 가볍게 동기부여 하기 좋은 모임이라고 생각한다.

회사에서 디자인 시스템을 구축한다는 얘기가 나오고, 마침 루비콘 내에서도 관련 얘기가 나와서 UI Kit 만들기에 동참하게 됐다. 이 프로젝트를 주도했던 분이 굉장히 많은 부분을 커버하고 있는데 정말 찐 개발자라고 생각하고 열정이 대단하다고 다시 생각한다. UI Kit에서 사용하는 기술 스택을 거의 경험해본 적이 없어서, 멘토였던분이 진행하는 리액트 스터디도 참여하게 됐다.

돌아보니까 정말 루비콘 활동이 중심이 됐던 한 해 였다…!

새 직장

2월말부터 3월 중순 사이에 여러 회사를 지원했다. 3월 중순에 최종적으로 한 회사를 합격하고, 4월부터 두 번째 직장에 다니게 됐다.

이때 면접을 보면서 엄청 의욕이 없는 상태였다. 과제를 수행하는 것 외에 면접 준비를 거의 안했다. 서류는 한 15개 정도 넣었던 것 같은데 1곳을 제외하고 전부 떨어졌다. 사실 이 1곳의 면접 경험이 별로 안좋아서 속으로는 여기는 절대 안가야지라고 생각하고 있었다. 그치만 현실적인 벽에 부딪혀 결국 다니게 됐고, 지금은 굉장히 만족하고 있다. (사람의 운명이란 정말 알 수 없다…) 아직 불만족스러운 금액이지만 연봉도 20% 정도 올랐다. 첫 연봉이 그만큼 작았기 때문이라고 생각한다. 앞으로 더 잘해서 올려야지^^.

이전 직장이나 현재나 회사나 도메인보다는 같이 일하는 사람이 중심이었다. 물론 이번 회사는 선택권이 없었지만, 지금 만족하고 있는 이유 중 하나는 같이 다니는 분들이 좋아서다. 사실 가장 중요한 부분이 될 수도 있다. 다만 내 경우에는 운좋게도 직장 동료때문에 회사가 싫어진 경험이 없어서 요즘 이 부분을 간과하고 있는 것 같다 😅

아쉬웠던 일들

  • 효율적인 재택근무

    코로나 상황으로 올해 대부분을 재택근무로 보내게 됐다. 전에는 재택근무를 마냥 긍정적으로 봤었는데, 직접 해보고나니 나랑 잘 맞는가에 의문이 들었다.

    일단 재택근무를 하면 시간관리 하기가 꽤 힘들다. 인터넷을 보면 더 의도적으로 규칙적인 패턴을 가져가고, 회사 나가서 일하는 것처럼 몸과 복장을 유지하는게 좋다라는 것은 알겠다. 그치만 현실적으로 게을러지게 된다. 어쨌든 컴퓨터 앞에만 앉으면 일을 시작할 수 있으니, 출근 시간에 맞춰서 일어나서 (심지어 우리 회사는 출퇴근 시간도 어느정도 자율적이다) 대충 세수만 하고 일을 시작할 때가 많았다.

    가장 큰 문제는 초과 근무를 하는 경우가 많아진다.

    내 경우에는 퇴근 시간이 돼도 퇴근하는 느낌이 없어서 그냥 일을 마무리하려고 더 붙잡는 경우가 하나 있었고, 업무 시간에 잘 집중을 못해서 밤에 더 보는 경우도 종종 있었다. 코로나 때문이기는 하지만, 계속 집에만 있는 상황을 답답해하는 분들도 꽤 많았다. 그리고 확실히 리모트 워크는 커뮤니케이션적인 부분에서 아쉬운 부분이 있다.

    아 덕분에 구글 행아웃으로 온라인 회식이라는 뭔가 기이한 현상(?)을 자주 체험하게 됐다.

  • billboard.js 기여(X)

    위에서 언급한 차트 라이브러리로 billboard.js를 사용했다. 사용하다가 버그를 발견하고 수정했는데, 수정해놓고 테스트 코드를 돌려보니 깨지는 부분이 많이 생겼다. 생각보다 해당 로직이 연관되어 있는 부분이 많았다😅

    빨리 이슈 리포팅을 해야했는데, 어떻게든 내가 수정해서 PR을 날리고 싶다는 마음에 리포팅하지 않았다 ㅎㅎ… 처음으로 svg에 관해 이것저것 알아보는 계기가 되기도 하고, 라이브러리 코드를 clone 해서 직접 이리저리 만져본 것도 처음이라 꽤 뜻깊은 경험이었다. 올해에는 꼭 수정해서 PR을 날리고싶다.

  • 개발의 포커스

    2019년에 비해 2020년 많이 게을렀다는 생각이 든다. 뭐때문일까 곰곰히 생각해봤는데, 회사의 일을 대하는 자세가 많이 달랐다. 생활패턴에도 영향을 꽤 준 것 같다.

    19년에는 회사 일은 딱 정해진 시간만 했다. 이때 아래의 패턴을 반복했다.

    • 오전 5시 30분 정도에 기상
    • 간단한 식사 후 출근
    • 회사 도착 후 10시까지 개인 학습
    • 퇴근 후 집에서 저녁 식사
    • 카페에서 2시간 정도 공부 후 귀가

    막 모든 날을 다 저렇게 지키고 그랬던건 아니지만, 특별히 저녁약속이 없거나 늦게 일어난 날이 아니면 평일에는 대부분 저렇게 살았던 것 같다.

    2020년은 회사의 업무에 집중했다. 일단 회사에 교육 프로그램이 있어서 한 2-3개월 정도는 관련된 공부만 했고, 재택근무를 주로 하다보니 늦게 일어나고 늦게 자는 일이 반복됐다.

    그래서 패턴이 바뀌게 됐다.

    • 오전 7시-9시 30분 랜덤기상
    • 회사 일
    • 저녁
    • 뒹굴뒹굴 + 멍때리기 혹은 회사 일 혹은 사이드 프로젝트
    • 보통 새벽 2시에서 4시 사이에 마무리하고 유튜브 보다가 취침

    특히 신규 기능 개발이 처음이라서 일정 산정을 능력에 비해서 너무 타이트하게 했는데, 이거 지키려고 새벽까지 하는 경우가 종종 있었다. 확실히 이런 패턴을 가져가다 보니까 작년에 비해서 좀 더 주도적으로 학습하지 못했던 것 같다. 보통 독서 같은 경우도 출퇴근 시간을 활용했는데, 출퇴근 자체를 안하다보니 자연스럽게 안 읽게됐다.

    뭐 업무가 유지보수 중심에서 기능 추가 위주로 변경된 것도 큰 역할을 했다고 볼 수 있지만, 스스로도 회사 일을 중심으로 처리하려는 면모가 확실히 두드러졌다고 생각한다. 이렇게 살다보니까 건강도 좀 나빠진 것 같기는하다. 2021년은 근무 시간의 업무 집중도를 최대한 올리고, 이전의 생활 패턴으로 돌아가는게 목표다.

아직까지는 나를 평범한 주니어 개발자라고 포장하고 싶다. 학생으로 빗대자면 공부하는 척은 열심히 하는데 실질적으로는 별로 안하는(?) 학생이다. 그래서 내 얘기가 보편적인 사람들에게 적용한다고 생각하기도 한다(사실 그러고 싶다 ㅎ). 아무튼 전직하고 1년 넘게 일하면서 때려치고 싶다는 생각은 들지 않았다. 매일 새벽까지 코딩하다가 현타온 적은 있긴하다. 2021년도 이 일을 하는 사람들에게 활기가 가득찼으면 좋겠다. 그리고 이 일을 해보고 싶은 사람은 내가 적은 내용을 한번 생각해봤으면 좋겠다.

이거 회고가 맞나…?

Published 3 Jan 2021

주 7일 공부 잊지마