10분 개발자

 가끔 커피챗 등으로 개발자들을 만나거나, 개발 업무에 대해 상대방에 설명해야 할 때가 있다. 그럴때면 가끔 듣는 말이 있다.

개발에 정말 열정적이시네요!

그런데, 나는 생각보다 개발에 열정이 있지는 않다. 오히려 요즘은 퇴근 후 집에 누워서 유튜브 보면서 드러누워있는게 일이라 오히려 반성하고 있을 정도다. 그런 내가 정말 열정적으로 개발에 임할 때가 있다. 보통 둘 중 하나인데, 다음과 같다.

• 아무것도 모를 때
• 분노했을 때

 아무것도 모를 때는 열심히 하는게 당연하다. 예를 들어 회사에서 JSP에서 React.js로 코드 마이그레이션 업무를 받았을 때, 나는 Java만 알고 Javascript에 대해서는 무지했으므로, 알지 못하면 일을 할수가 없어서 살아남기 위해 진짜 열심히 개발공부를 했다.

 그리고 오늘 얘기할 부분, '분노했을 때'이다. 부트캠프에 다니면서 정말 하루에 잠자는 시간 외에는 정말 공부만 했었다. 물론 개발이 재밌어서도 있고, 좋은 동료를 만나서도 있지만 그 이전에는 기저가 있었다.

 내가 수료한 부트캠프를 다니기 이전에, 다른 부트캠프를 다녔었다. 어떤 백엔드 언어의 바이블같은 책이 있었는데, 그 책의 저자가 직접 만든 부트캠프를 먼저 갔었다. 가격도 정말 비쌌다. 조금만 과장을 더하면, 지금 수료한 부트캠프의 전체 수강료가 그 부트캠프의 1달 수강료와 맞먹었다. 내가 모아둔 돈을 다 털어서 갔기에 정말 열심히 하려고 했고, 간절한 마음으로 갔다. 질문도 많이 하고, 매주 보는 시험에서 항상 최상위권의 성적을 유지했다.

 문제는, 다닌 지 2주일만에 학원에서 잘리게 되었다. 사유는 간단하고도, 어이가 없었다. '질문을 너무 많이 해서.' 처음에는 내가 다른 이유로 잘못했나 싶었다. 왜냐면 다닌지 1주일만에 학원에서 잘렸던 사람이 있었는데, 잘린 사유가 '질문을 너무 안 해서'였으니까. 이 글을 보는 사람들도 내가 잘못된 질문을 했겠거니 할 수도 있겠지만, 나는 맹세코 개발에 관련된 쓸데없는 질문을 하지도 않았고, 또 무슨 수다맨마냥 너무 여러번 질문을 하지도 않았다. 잘리던 날 내가 마지막으로 했던 질문은 '선생님, 컴퓨터는 1초를 어떻게 세나요?' 였다. 지피티도 없을 때라, 질문에 대한 해답을 개인적으로 찾아보기도 어려웠고, 블로그에 정말 많은 잘못된 정보를 봤던 때라 가장 빠르고 확실하게 정답을 알아낼 수 있는 방법은 질문 뿐이었다.

  당연히 잘리던 날 거의 울면서 '앞으로는 질문을 절대 안 하겠습니다' 라는 말을 해도, 그 외곬수의 마음에는 이미 내가 없었다. 무슨 짓을 해도 안 된다고 했고, 다음날 학원에서 만난 동기들은 너무나 의아한 표정으로 나에게 물어봤다. '니가 잘렸다고? 도대체 왜?' 그렇지만 나는 '질문을 너무 많이 했대'라는 말 밖에는 할 수가 없었다. 문제는 그 다음이었다. 환불 처리에서도 문제가 있었고, 음식점에 컴플레인 한번 걸어본적 없던 내가 국민신문고에까지 글을 남겼었다. 그제서야 일부 환불을 받을 수 있었다. 자기가 잘라 놓고. 그 후로는 머릿속에 단 한가지 생각밖에 안들었던 것 같다. '내가 정말 어마어마한 사람이 되어 복수해 주겠다'고. 그렇게 정말 한동안 미친듯이 공부했었던것 같다. 물론, 새로운 부트캠프에서 만난, 내 새로운 개발 인생을 열어준 매니저님이 '질문하시면 저도 답변해드리면서 공부할 수 있어서 좋으니, 질문을 꼭 해주세요'라고 말씀해주셨던 부분도 컸지만.

 그렇게 열심히 부트캠프를 다녀 최상위 수료생으로 마친 뒤, 몇 달간을 쉬고 첫 회사에 들어갔다. 쉬운 결정은 아니었다. 기존의 사업을 할 때보다 연봉이 1/3토막이 되었으니까. 그래도 원하던 연봉이 있어서(사규 신입 연봉테이블과 크지 않았다) 되지 않을까 하고 여쭈어봤는데, 답변이 충격적이었다. '보여준 일이 없으니 그만큼은 주지 못 할것 같아.' 그 날부터 내가 어떤 사람인지 보여주겠노라고 회사 입사 이후 정말 궂은일 가리지 않고 이 일, 저 일을 다 했다. 물론 불만은 있지만, 그래도 회사에서 백엔드, 프론트엔드, 또 AI 트랙까지 모두 경험해볼수 있었던것이 너무 감사하고 좋았다. 

 돌아보니, 그냥 열심히 살았던 것 같은데, 어떻게 보면 분노가 이끄는 삶을 살았던 것 같다. 나는 분노를 부정적 스트레스로 풀지 않고, 긍정적 스트레스로 받아들여 더 열심히 살고자 하는 경향이 강하지만, 그래도 분노가 주 원동력이 되는 것 보다는 앞으로는 재미를 원동력 삼아 나아가고자 한다. 세상에 '노력하는 자는 즐기는 자를 이길 수 없다'는 속담은 있지만, '즐기는 자는 분노하는 자를 이길 수 없다'는 속담은 없으니까.

4월 회고록

 4월은 정말 바빴다. 부트캠프 튜터와 함께 회사에서 첫 메이저 개발업무에 투입되었다.

부트캠프 튜터는 내가 배웠던 대로, 가르침을 받았던 대로 치어리딩과 함께 기술지원 업무만 있는 줄 알았는데 커리큘럼이 바뀌어서 그런지 먼저 알고리즘을 3주동안 가르치게 되었다. 다행히도 알고리즘은 백준 골드1을 쌓아놔서 이해하는 데에는 어렵지 않았지만, 하루에 매일매일 알고리즘을 최대 7문제씩 풀어야 하니 3시에 취침 ~ 7시에 기상하는 날이 많았다.

정말 고된 나날이었지만, 한편으로는 정말 즐거웠다.

 처음 개발공부를 하러 부트캠프에 갔을 때 누가 시키지 않았어도 항상 공부하느라 새벽 5시에 취침하고 오전 9시에 기상하고, 너무 바빠서 밖에 나가지도 못했었던 생활을 지속하다가 몸이 아파서 취직 전까지는 매일매일 멍하니 하루를 보내는데 허송세월을 보냈다. 취직을 해서도 물론 매일매일 공부했지만, ‘잠이 세상에서 제일 달다’는 다시는 못 느껴봤었다.

 우테코 입학 설명회 영상을 본 적이 있었는데, 포비님께서 ‘몰입 경험’에 대한 강조를 하셨었다. 그 때에는 나에게 있어서 ‘몰입’이라는 것이 얼마나 크게 다가왔는지 못 느꼈는데, 이번에 정말 바쁜 삶을 살면서 예전 부트캠프 때가 생각나 몸은 힘들었지만 새삼 행복함을 느꼈고 동시에 나의 몰입 경험이 바로 그 시절이었다는 것을 떠올렸다.

 알고리즘 주간이 끝나고는 MSA에 대해 튜터를 해야 했다. 멀티 모듈 프로젝트를 해 본적은 있었지만 MSA에 대해서는 만져본적이 없어서 당황했지만 어찌됐든 수강생들을 이끌고 프로젝트에 대한 도움을 줘야 했다. 그래서 그때부터 MSA에 대해 정말 많이 공부를 했다. 주말에는 MSA와 관련된 DDD에 대해 세션까지 들었다. DDD 세션을 듣고 나니 MSA도 MSA였지만, ‘개발이란 무엇인가’와 함께 회사에서 작성 중인 기고문에 대한 블루프린트가 명확해져 좋았다.

 회사에서는 Agile PMS 개발을 진행했다. PMS는 예전에 부트캠프에서 최종 프로젝트로 B2B SaaS 형태의 PMS를 개발해봐서 플로우는 대충 이해했지만, 회사 자체의 도메인이 정말 어려워서 개발하는데 힘이 들었다. 다만 Agile PMS가 아닌 다른 프로젝트가 이미 개발되어 있어서 참고를 많이 했다.

 개발하면서 힘들었던 점은 Query에 대한 이해도가 낮아서 문제가 되었다는 것이다. 나는 QueryDsl+Spring Data JPA를 배우고 회사에 들어왔는데, 회사에서 구버전으로 개발 시Mybatis+native query를 이용하기도 하고, 기존 쿼리들 중 recursive query가 많아서 이런것들을 처음 봐서 매우 어려웠다. 그래서 원래 공부 계획은 Kafka + Lang chain을 이용한 LLM 프로젝트를 혼자 해보고 싶었는데, 5월부터 신버전에 들어가는 jsp → react migration 작업만 하고 kafka보다는 java와 db에 대한 이해도를 높이는 것이 우선이라는 생각이 들었다.

 회사의 도메인이 법때문에 굉장히 핫해져서 그런지, 회사의 크기도 엄청 커지고 이에 따라 신입분들도 많이 들어오고 계신다. 다음달에만 해도 신입 사원 10명을 추가 충원한다고 하니, 곧 100명 사원을 보유한 회사가 되는게 머지 않은 것 같다. 그래서 지금보다 더 노력해야 어떤 사람이 들어온다 해도 나의 identity와 irreplaceable함을 증명할 수 있을 것 같다.

 5월에는 신규 프로젝트로 기존 jsp로 되어있던 프론트엔드 소스들을 react로 migration해야 한다. 나는 프론트엔드를 해본 적이 없기에 정말 기대가 되고 열심히 공부해야 할 것 같다는것을 온몸으로 느끼고 있다. 항상 겸손의 자세로 빠르게 배워서 회사에 도움이 되는 좋은 소스코드를 만들어내고 싶다.

화이팅!

부트캠프 멘토링 중 부트캠프 프로젝트의 도전 과제가 1인 MSA 프로젝트로 나왔는데,

많은 멘티들이 MSA의 개념을 모르거나, 구현하는 데에 많은 어려움을 겪고 계셨다.

그 와중 넥스트스텝에서 카카오, 무신사, 우형등의 기술이사를 맡고 계셨던, 객체지향의 사실과 오해라는 책을 집필하셨던

조영호 강사님의 DDD 세션이 열려서 들으러 갔다가 마침 알고만 있던 개발자분과 같이 세션을 듣게되어서 만나뵙고 식사를 하게 되었다.

작년 중순 즈음 처음 개발 단톡방에서 뵌 것 같은데, 항상 열심히 사시고 열심히 공부하고 계신 것 같아, 처음으로 용기를 내어 친한 개발자가 아닌, 다른 개발자분께 커피챗을 신청하게 되었다. 나는 항상 소심하고 폐를 끼치기 싫어서 커피챗을 신청하지 못했는데, 이 분은 한번은 꼭 뵙고 싶었다.

다음 질문들을 하고 싶었다. 물론 내가 이렇게 따라가고자 여쭌 건 아니고, 많은 사람들의 고견을 들으면서 선택지를 넓히고 싶었다.

• 언제부터 개발을 시작하셨는지?
• 공부 방법을 어떻게 가져가시는지?
• 개발에 대해 어떤 생각을 가지고 계신지?
• 신입 / 주니어때는 어떤 공부를 해야 할지?
• 그 외에 개인적인 질문들

전공자라고 하셔서 정말 개발을 열심히 하셨을 것 같은데, 생각외로 그런건 아니고 대학 시절때 열심히 게임을 하면서 시간을 보내셨다고 했었다. 그래서 친구분들은 다 대기업에 계신데, 혼자 그러지 못해 작년에 조금 불안한 시간을 보내셨다고 한다. 물론 그래도 올 해 너무나 좋은 회사를 가셨지만.

이 말부터 굉장히 공감했다. 내 학창시절 친구들도 대학교때라도 개발을 시작한 친구들은 다들 다른 회사에서 CTO를 하고 있거나, 네카라쿠배의 개발자를 하고 있으니까. 그래서 내가 조금 더 급했는지도 모른다.

그래서 그런지는 모르겠는데, 사실 이 커피챗을 신청한 이유를 관통하는 대화였다.

요즘 개발이 너무 재미있는 시즌이기도 하고 성장에 메말라있던 때라, 또 내 욕심때문에도 계속 모르는 분야를 줄이고 싶었다. 그런데 '개발'이라는 필드가 너무나 광범위하기도 하고, 주위에 다들 잘하는 개발자들만 있으니 항상 이야기를 할 때 모르는 단어들이 너무 많이 나왔다. 그래서 계속 탐구하다보니 깊이보다도 계속 지식의 범위가 수평적으로만 확장되고, '이걸 다 어떻게 공부하지...'라는 생각만 들고, 결국에는 공부하려고 했던것들만 쌓이고 받아들이는 것은 한정되는, 소위 말하는 '체하는 현상'이 발생하기 직전이었다.

그래서 이것저것 너무 '찍먹'만 하고 있다고 생각했는데, 이분께서도 신입 시절은 기초를 탄탄히 하면서 퍼포먼스에 집중하는 때를 보내는게 어떻겠냐고 말씀하셨다. 너무 맞는 말이라 반박할 수가 없었는데, 현재 회사를 다니면서도 가장 힘든 부분이 디버깅을 하며 코드 플로우를 분석하는 것인데, 이걸 위한 공부보다는 내가 좋아하는 분야, 내가 개발하고 싶은 분야만 공부하고 있는게 아닌가 하는 생각이 들었다. 물론 회사에 도움되는 개인 프로젝트긴 해도, 백투베이직에 조금 더 신경써야 했었는데...

그래서 나온 대화가, 회사에서의 겸업 금지 조항이었다.

이분의 회사는 겸업을 원천적으로 금지하고 있었다. ~~콘에 나가서 강연을 하는것은 물론이고, 작은 멘토링까지 전부 금지 규정에 포함되어 있었다. 생각해보니 유명한 스타트업에 가 계심에도 불구하고, 이 회사에 대한 어떤 기술 블로그나 강연자를 본 적이 한 번도 없었다. '회사에 베스트 퍼포먼스를 보이러 왔지, 타 업무로 회사에 지장이 가는 어떤 일도 금지하자'라는 게 핵심인데, 그래서 회사에서 친목도모를 위한 업무시간 외의 모임이나 만남도 금지하고 있었다. (너무 사적인 모임 등) 중요한 결정의 순간에, 조금의 추가적인 정이 최선의 결정을 방해할 수 있다는 것이 그 이유였다.

어떻게 생각해보면 조금 가혹하다고 할 수도 있으나, 우리 회사에서 개발자들이 '왜 개발 외의 타 업무까지 해야하나'라는 상황을 고려해보건대, 정말 프로페셔널하다고도 생각했다. 대신 복지나, 다른 베네핏에 대해서는 확실하게 보장해 준다고도 했다. 그래서 사내에서는 워커홀릭도 많다고 하셨다. 베네핏 뿐 아니라 회사 내의 커뮤니케이션 또한 워커홀릭을 만들고 있었는데, B2B 기업과는 달리 B2C 서비스 기업이라 마케터들이 원하는 그런 기능을 개발할 때 오는 피드백이 큰 도파민을 가져다준다고 하셨다.

그래서 말씀드린 것이, 나는 강남언니처럼 테크블로그가 있는, 사내 개발 실력 증진도 좋지만 외부에도 사내 개발에 대한 이야기를 풀어갈 수 있는 컬쳐를 가진 회사가 너무 부럽다고 했다. 내가 처음 개발공부를 할 때 물론 개인 블로그에서도 인사이트를 많이 얻었지만, Naver D2, 우아한테크블로그, 강남언니등의 회사 블로그에서도 양질의 좋은 글을 많이 읽었기 때문이었다. 내가 개발자가 된 이유와도 얼추 겹쳐보여서 멋있다고 말씀드렸더니, 그것또한 공감을 해 주셨다.

외에도 많은 이야기를 나누었다. 자신이 정말 좋아해서 커피챗을 신청하기 위해 정말 긴 편지까지 써서 만났던 개발자에게 취직 축하를 받은 이야기, 사내에서 개발한 기능들이 어떻게 반영되는지, 또 본인이 다니고 있는 회사에 대해 어떻게 생각하는지, 지금 앞둔 목표는 무엇인지 등등, 정말 이야기 하는 내내 즐거워서 시간이 가는 줄 몰랐다.

이야기를 듣는 내내 T스러움이 정말 많이 느껴졌는데, 본인의 의견을 강단있게 말씀하시면서도 겸손까지 갖추신 모습을 보니 멋있었다. 사실 나도 멘토활동을 하면서 항상 '제가 뭐라도 되는 사람은 아니지만'이라고 했을 때 그래도 나에게 항상 응원과 환호를 보내주신 멘티님들이 이해가 됐다.

그래서 결론은, 지금 하고 있는 개발 공부까지만 해 보고, 이제는 회사에서 사용하는 기술스택에 대한 딥다이브를 해야겠다고 생각했다. 또, 새로운 목표를 가지게 되었다.

대림역 근처의 한 스시집에서 2년차 개발자 두 분을 만나뵈었다.

두분 다 비전공 부트캠프 출신으로,

한 분은 나와 나이가 비슷하지만 어려서부터 정말 많은 고난과 역경을 딛고 올라와서 풀스택 개발자로 성장 중이며 현재 개인사업을 계획중이고,

다른 한 분은 정말 어린 나이에 생산직을 하다가 부트캠프로 직무전환을 한 후 현재 강남에 있는 모 기업으로의 이직을 준비중이다.나는 정말 다양한 사람들을 만나는 것을 좋아하는데, 그 중에서도 정말 한 명도 똑같거나 비슷한 인생을 살아온 사람이 없다.또 이런 얘기들을 듣는것이 나에게 다양한 사람을 만나게 하는 즐거움이기도 하다.두 분의 이야기를 들으면 정말 개발자 문화는 다른 문화에 비해 내가 생각하는 '이상적인 문화'에 가깝다.긍정적인 스트레스와 선의의 경쟁을 통해 윈윈을 이끌어내는 개발자 문화가 너무 좋아 이 직업을 동경하기도 했다.

그리고 오늘의 포스팅을 하게 된 이유.

두 분의 이야기를 들으면서, 또 요즘 살면서 느낀 것이 있다.개발자 취준이나 그것을 떠나서 사람 바탕에 깔려있는 두 분의 '자신감'이 너무 멋있었다.

일단 되든 안되든 해 보는 그 자신감이 알게 모르게 그들을 성공으로 이끈 것 같다.

나의 최대 단점이라고 하면, 완벽하지 못한 일에는 나서기를 주저하는 것인데조금 더 나서서 자신감을 가지고 도전해야겠다. 화이팅 :)

첫 팀이 분배되고, 프론트 지향 2명과 백엔드 지향 2명이 같은 팀이 되었다. 

문제점

프로젝트 주제에 대해서는 많은 아이디어가 나왔지만, 그 주제에 어떤 기능을 넣어야 할지, 모여서 무엇을 해야 할 지, 또 어떻게 일감을 나누어야할지, 내가 아는것은 무엇인지에 대해 정의할수가 없었다.

시도해본것 

아는것이 제일 많은 고수님께 PM을 맡기고,

팀장님이 정한 주제에다 기능구현을 몇개 입히기로 했다. 각 기능 구현은

https://hanghae99.spartacodingclub.kr/v2/exhibitions

여기서 재밌어보이는 기능을 하나씩 가져와서 넷이서 구현해보기로 했다.

결국

우리는 유튜브의 데이터를 긁어와서 모두가 같이 유튜브를 재생하는 프로젝트를 구성하기로 했다.

Discord에 있는 뮤직 봇같은 경우에는 대화방을 파서 유튜브 파일을 가져와서 재생하는데,

우리는 재생중인 화면에서도 대화방을 팔 수 있도록 할 것이다.

느낀 점

프로젝트는 아이디어만 있다고 되는 것이 아니라,

• 내가 무엇을 알고, 무엇을 할 수 있는가 / 남이 무엇을 알고, 무엇을 할 수 있는가
• 기능은 어떤 것을 구현할 수 있는가
• BE/FE의 관점에서 어떻게 일을 분배할 수 있는가

를 알아야 한다. 기능도 '이런 기능이 있으면 좋겠어'가 아니라, '이 기능은 어떻게 동작하고 구현하고 나타내야 되겠어'를 생각하고 있어야 비로소 좋은 프로젝트로 가는 길이 될 것 같다.