[생각정리] 생애 첫 퇴사 건에 대해서 (신입개발자 편)

안녕하세요!

Dev. Pluto입니다.

 

요 며칠간 포스팅이 꽤나 뜸했었습니다. 😭

 

이유는 물론 이래저래 바쁜 것은 둘째 치고(?) 백엔드 신입 개발자로 입사하여 2년 4월가량의 경험을

쌓았던 첫 번째 회사에서 퇴사하게 돼서 업무를 마무리하고, 평소에 미루어두었던 것들을 정신없이 하며 시간을 보냈었습니다.

이번 시간에는 첫 직장에서의 경험과 회고를 기록으로 남기기 위해 글을 작성하게 되었습니다.

이 글은 IT 직군 개발자로 커리어를 시작하시려는 분들이나, 이미 첫 번째 퇴사를 해보셨던

혹은 퇴사를 고민중에 있으신 분들이 읽어보시면 직 / 간접적으로 공감을 하실 수 있지 않을까? 싶은 글입니다.

(물론 다른 분들이 읽어보셔도 괜찮습니다! !:)

 

 

퇴사했던 이유? 

  첫 번째 회사를 다니면서 처음에 입사하였던 직군과 직무가 생각보다 많이 넓은 점이 있었고, 2년이 넘는 시간 동안 재직하면서 업무의 스펙트럼을 넓혀가고 있었던 와중에 이제는 한 분야 (FE or BE)를 정해서 집중적으로 역량을 향상해 보고 싶다!

라는 갈증이 점점 커 저서 이직을 하게 되었습니다. (광고산업 이외의 산업도 개발자가 어떤 역할을 하는지 궁금하기도 했구요.)

 

현재 다니고 있었던 회사는 시리즈 A 규모의 투자를 받은 Ad-Tech 스타트업을 다니고 있었고

이제 합류할 회사는 헬스케어 산업에서 DT(Digital Transformation)를 만들고 있는 솔루션 회사에 백엔드 포지션으로
재직할 예정입니다. 투자 규모는(전 직장과) 같습니다.

 

무엇을 배웠나?

첫 번째 재직하였던 회사에서는 주로 메이저 한 기술 스택들을 사용하는 게 저에게는 행운이었다고 생각합니다. 

Spring Boot 프레임워크, Typescript 기반의 React 라이브러리를 사용하고

풀스택 개발자로서 관련된 인프라 (AWS, Redis, DB) 등에 대해서 넓고 얕게 전반적으로 배워볼 수 있었던 좋은 경험이었다고 생각합니다

 

또한 개발팀을 리딩하시는 분께서 기술적으로 새로운 것에 대한 거부감 없이 많은 관심을 보이셔서 여러 가지 시도를 하는 과정이나

B2C 고객 서비스에 준하는 구조와 프로그래밍을 어렴풋이라도 배울 수 있었다고 생각합니다.

 

또한 개발자는 결코 코드만... 짜는 사람이 아니라는 것을 크게 배웠습니다. 

요구사항을 보고 코드를 잘 작성하는 것은 기본이고, 회사에서 일감을 받을 때나 진행 중인 일을 보고할 때.

그리고 혹시나 업무 지시사항을 엉뚱한 방향으로 받아들인 건 아닌지 생각하고 싱크를 (업무를 건네준 상사와) 맞춰가는 

과정에 꼭 필요하고, 이게 정말 쉽지 않은 일이구나.. 라는걸

 

첫 번째 회사에서는 배웠다고 생각합니다. 

"이상적인 개발자는 이런 모습이구나!" 하는 개발자분도 만나보고.

정말 절체절명의 순간(?) 일 때 영웅같이 나타나셔서 저를 몇 번이고 구원해 주셨던 감사한 개발자분도 만나 뵙고

 

여러 가지 감사한 경험을 하였습니다.

 

 

첫 직장을 다니면서 잘했다고 생각한 점 / 아쉬웠다고 생각한 점

  첫 번째 직장을 나오고 신입 개발자로서, 풀스택 개발자로서 어떤 점을 잘했다고 생각하고 아쉬웠다고 생각했는지 개인적으로 정리해 보았습니다. (이 글을 읽어주시고 독자분들의 의견을 댓글로 남겨주시면 같이 공유해 볼 수 있는 좋은 시간이 될 것 같으니. 참여해 주시면 감사하겠습니다!) 

 

잘했다고 생각한 점

1. 처음 해보는 언어를 비롯해 기반 라이브러리 혹은 프레임워크를 습득하여 결과물을 내었던 점
2. 개발자이지만 문서작성에 좋은 역량이 있다는 것을 느낀 점
3. 근무 태도에 대한 부분

첫 개발자로서 회사에 입사하여 여러모로 생소한 환경에 더불어

회사에서 다루는 여러 가지 새로운 기술과 언어를 빠르게 학습해야만 하는 특성이 있었습니다. 

 

거기에서 오는 압박감이나 스트레스들이 있었지만 잘 습득해서 기여한 바가 있었습니다. 

스타트업 특성상 빠르게 배워야 하는 부분에 대해서는 이후 아쉬웠던 점에서 다루겠지만 

 

속도를 제외한 부분에서는 착실히 학습하여 결과를 내지 않았나 생각이 듭니다.

 

그리고 전혀 몰랐지만 

사내 발표 세션을 위한 문서 작성이나, 업무 인수인계 혹은 사내 위키 문서를 정리할 때 

글을 읽기 쉽게 잘 작성한다는 평을 들었습니다. 

(글처럼 코드도 읽기 쉽게 잘 작성하고 싶습니다만...😭)

 

글을 잘 작성하는 능력이 지금으로서는 어떻게 저에게 이로움을 줄지는 모르겠지만 

이런 장점을 다음 회사에서, 아니면 당장 이 글을 읽으시는 독자분들께라도 이로움으로 

느끼게 해 드리자 라는 생각으로 계속 갈고닦을 생각입니다.

 

잘했다고 생각한 부분을 새롭게 들어간 회사에서는 어떻게 유지할지?

• 회사에 적극 어필해서 테크블로그에 문서를 작성하고 기고하기.
• 전 직장에서 받았던 근무 태도 유지해서 앞으로 합류할 회사에서도 좋은 평 듣기
• 처음 습득해야 하는 기술이나 언어등을 거리낌 없이 배우는 태도와 도전하는 자세 취하기

 

아쉬웠다고 생각한 점

1. 생각한 것만큼 소통하기가 쉽지 않았다. (커뮤니케이션이 미숙했다)
   1. 커뮤를 하는 대상의 의도를 파악하지 못한 것.
   2. 업무 진행상황을 제때제때 보고를 하지 않고 미스 커뮤니케이션의 Loss를 크게 만든 것
   3. 잘 모르는 것을 제때제때 물어보지 않은 것
2. 업무를 비효율적으로 한 것
   
   1. 최대한 작은 단위로 테스트할 수 있게 하지 못한 것 (최대한 빠른 실패를 하지 못한 것)
   2. 업무를 할 때 더 좋은 방법을 찾으려고 적극적이지 않았던 것
3. 개발자로서, 기존 개발자분들이 어떻게 일을 하는지 (코드 컨벤션은 어떤지) 빠르게 파악하지 못했다
4. 내가 작성한 코드를 내가 제대로 설명하지 못한 것
5. 기획이나, 업무 진행상황에 대한 히스토리를 정확히 인지하지 못한 것. 
6. 처음 배우는 것을 빠르게 학습하고 실무에 적용하지 못한 것.

 

솔직히 이번 회고 글은 이 파트를 위해 작성됐다고 해도 무방합니다..ㅎ
정말 많은 내용들이 있는데, 분류별로 자세하게 작성해 보겠습니다.

 

첫 번째로 생각한 것만큼 소통하기가 쉽지 않았습니다. 

상사에게 업무를 전달받을 때에도, 기획서를 볼 때에도 "이렇게 하는 게 맞나?"라는 

싸한 이해도를 가지고 업무를 시작했다가 결과적으로 전혀 엉뚱한 결과물을 생산한 경우가 있었습니다. 

(애처롭게 시간만 왕창 지나가버린 상황 말이죠..ㅠ)

 

어떤 의도로 이런 말을 하였던 것인지.. 

전달할 때의 컨텍스트는 어떠하였는지.. 

이런 것들을 생각하고 이해해야 결과물의 퀄리티가 정확하고 높아진다는 것을 깨달았습니다. 

 

그리고 이어지는 것이지만 업무 진행상황을 제때제때 보고하지 않음으로써 시간만 점점 흘러가고

결과물은 점점 다른 방향으로 크게 틀어지는 상황이 됩니다 (정말 최악의 상황입니다.)

 

두 번째로 업무를 꽤나 비효율적으로 진행하였습니다.

구현한 서버단 API이나, 화면이 테스트를 필요로 할 때 가장 빠르게 확인할 수 있는 방법이

분명히 있음에도 불구하고.

최초로 "어? 된다!" 하는 방법으로 (가장 빠르게 확인하는 방법이 아닐 수도 있는) 

업무를 확인하며 진행하여서 개인적으로 생각해 보건대 항상 일은 늦게까지 하지만

"왜 이렇게 한 게 없는 것 같지??"라는 의문이 계속 있었던 것 같습니다. 

 

세 번째로 스스로 작성한 코드를 본인이 설명하지 못하는 경우가 왕왕 있었습니다. 

초기 기능 요구사항을 받고 해당 기능에 세부적인 결정사항이나 동작 방식을 

개발했던 순간에는 신선하게 남아있지만 시간이 조금 흐른 뒤

다른 개발자가
"이거 어떻게 동작하는 거예요?"
"~이러이러한 경우에는 어떻게 동작하죠?"
와 같이 질문이 들어오면, 다시 기억을 더듬는 게 참. 느리고 

무엇보다 정확하지 않았습니다. 

 

그래서 본인이 코드를 짜놓고도 본인이 설명하지 못해

동작을 물어본 개발자는 그럼 도대체 누구에게 물어야 하나 답답한

상황이 벌어지기도 하였습니다. 

 

네 번째로 기존에 개발팀이 어떻게 일하고 있는지 빠르게 파악하지 못했습니다.

코드 컨벤션 룰은 어떻게 이루어지고 있는지. 

파악을 빠르게 해서 팀에 스며들지 못했던 게  좀 아쉬웠다고 생각합니다. 

 

아쉽다 생각한 부분을 어떻게 수용하고 고쳐나갈지?

 큰 맥락으로는 의식적인 훈련이 필요한 사항들이 대다수로 보입니다.

• 솔직한 태도로 동료나, 상사에게 질문을 하고 피드백 요청하기
  • 한번 질문한 것은 두 번 묻지 않기 위한 장치 마련하기 (회의록이나, 녹음?)
  • 잘 모르는 것은 모른다 말하기. (애매하게 설명하지 않기)
  • 질문한 것은 꼭! 꼭! 기록해서 기억으로만 남기지 않기
  • 업무 진행상황은 어떻게 보고하는 게 좋을지 먼저 물어보고 (상사의 성향 등 파악해 보고, 적절한 형태로 보고하기)
  • 잘 모르겠는 것 30분 이상 고민하지 많기.
    • 물어볼 때 "이게 안됩니다.." 로만 묻지 말기. (최소한 업무의 컨텍스트나 내가 테스트해보았던 것들 등 질문할 때 최대한 많은 정보를 제공하기)
• 회사 코드뿐만 아니라 오픈소스 많이 분석하여 다양한 구현패턴을 눈에 익히기
  • 의식적으로 "더 빠르게 할 방법은 없을까?" 고민하고 적용하기
• 코드 구현하였던 방법 그림이나, 간단한 글로 설명 가능하게 문서로 만들어놓기

 

정리

길게.. 길게!

 

  "실패는 나침반이다"라는 말씀을 최근 실리콘 밸리에서 긴 시간 동안 재직하며 경험을 쌓으셨던 한기용 저자께서 하셨던 기억이 납니다.

첫 번째 직장에서 좋은 평보다는 그렇지 못한 피드백을 많이 받았던 것은 사실이지만. 바꿔 말하면 내가 방향을 잡아가야 할 나침반들이 더더욱 저에게 방향을 명확하게 알려주고 있다고도 생각할 수 있습니다. 

 

여기서 중요한 것은 피드백에 대한 낙심이 아니라 건전한 수용과 의식적인 개선의 훈련이 필요할 것입니다. 

그리고 무엇보다 중요한 것은 어찌 보면 정말 정말 긴 커리어를 보내게 되는 요즈음. 

길게 바라보면서 개발자 인생에 거쳐가는 회사 하나하나에 너무 일희일비하지 않고 자신을 사랑하고 소중히 여기며 앞으로 단단히 나아가는 마음도 필요하지 않을까 생각합니다. 

 

돌이켜보면 예체능계에서 아예 다른  공학계열로 진로를 바꾸고, 쉽지 않았을 공부를 거쳐 관련된 직업까지 가지게 되었는데. 

이 모든 과정은 혹독할지언정 순탄한 과정은 아니었다고 생각합니다. 

 

지금까지의 과정을 묵묵히 걸어가고 있는 제 스스로에게 오글거리지만(?) 감사의 마음을 이번 기회를 비롯해 전하고 싶습니다.

그리고 주변에 저를 지지해 주신 분들이 없었다면 이 자리에 있을 저는 감히 상상이 가지 않습니다.
주변사람들에게도 항상 감사합니다