1년 반. 첫 직장 생활 회고 [1편]

마지막 퇴근한 지가 벌써 한 달이 다 되어간다.

퇴사하고 본가로 내려가게 된 터라 자취방에서 2주를 보내면서 주변 사람들과 인사하는 시간을 가졌고

본가로 내려와서 2주 동안은 코테 문제도 풀고 private 레포에 있는 못했던 사이드 프로젝트도 좀 진행하면서 지냈다.

더 늦기 전에 1년 반 동안 있었던 내 첫 직장 생활에 대한 회고를 시작해보려 한다.

회사 생활이 어땟는지는 보다는 개인 성장이 얼마나 어떻게 이뤄졌는지 초점을 맞춰보려 한다.

 

시작. 그리고?

ICT 학점연계 인턴십으로 전 직장을 만나게 되었다.

20년도 9월에 인턴으로 입사했고 총 3군데를 지원했는데, 두 곳은 떨어지고 한 곳만 붙었다.

백엔드 개발자를 목표로 공부했고 그중에서도 Spring을 중심으로 공부했었다.

그런데 내가 맡게 된 직무는 풀스택 개발. 그것도 node.js로 백엔드 업무를 수행했다.

학부생 때 한 학기 정도 웹 프로그래밍 과목 들으면서 HTML CSS Javascript 익힌 게 전부였고

AWS SA 자격증이나 공부했던 Spring이나 다른 지식이 조금은 아쉬웠지만 괜찮았다.

이 또한 쓸모가 있겠다는 생각으로 프론트엔드 공부를 시작했다.

같이 들어온 인턴 친구들은 이미 React를 어느 정도 공부하고 들어왔기 때문에 실력 차이는 많이 났지만 열심히 노력했다.

 

백엔드 엔지니어에서 풀스택 엔지니어로

나는 풀스택 엔지니어라 쓰고 프론트엔드 개발자인데 이제 백엔드를 곁들인 이라 읽었다.

백엔드를 더 공부하고 싶었지만 회사는 프론트엔드 업무가 더 급했고,

개인적으로 서비스 개발 측면에서는 프론트엔드를 위한 백엔드 정도를 구현하는 개발 범주였으며

인프라에 대한 지식도 필요했기 때문에 이전에 공부했던 게 많은 도움이 되었다.
쓸모가 없을 줄 알았는데 뭐든 배워두면 언젠간 쓸 일이 있나 보다.

사실 처음에는 풀스택 개발에 대한 환상이 있었다.

그중 큰 부분을 차지했던 건 그냥 막연한 생각 때문이었다.

 

둘 다 할 줄 알면 토이 프로젝트도 혼자 뚝딱!
나중에 창업을 하게 되면 도움이 되지 않을까?

 

달콤한 말이지만 실제로 쉽지 않다는 걸 몸으로 느낀 건 몇 달 후였다.

생각해보면 일이 두배가 되는 거고, 그만큼 하나의 분야를 깊게 파고들 시간은 부족해진다.

이때 할 줄 아는 것과 쓸 줄 아는 것의 차이를 느꼈다.

안다고 해서 쓴다고 해서 할 줄 아는 게 아니었고 원리를 파악하는 게 중요했다.

시간이 지나고 마음처럼 모든 걸 할 줄 알게 되진 않았다.

"일단 돌아가게" 만들어두면 자연스럽게 기술 부채가 되고 불과 몇 달 전에 짠 코드를 리팩토링 하게 되는 상황도 있었다.

시니어 개발자가 팀에 있다면 Frontend 코드 품질이나 구조에 대해서 상의하고 물어보겠지만

이미 시니어 개발자분은 퇴사하신 이후였고 주니어 개발자 2, 3명으로 이뤄진 팀이었다.

깊게 공부해서 코드 퀄리티를 높이면 좋겠지만, 일반적인 스타트업이 그렇듯 일은 넘치고 사람은 부족했다.

회사는 코드 품질을 높이고 기술 부채를 해결할 시간에 새로운 기능을 만드는 게 더 중요하다고 생각했다.

 

이런 점을 제외하고는 백엔드 일부 영역이 점점 프론트엔드 영역으로 넘어오고 있는 점,

더 늦기전에 첫 시작을 풀스택 개발자로 시작할 수 있었던 점은 한편으로는 행운이라고 생각하고

이게 스타트업에서만 경험할 수 있는 특별한 경험 이라고 생각한다.

 

풀스택 엔지니어로 개발 이력을 시작한 걸 다행으로 생각한다.

 

계획을 잘 세워야 해!

(테오님의 구글 스프린트 글에 있던 사진)

시간이 지나면서 신입 개발자분들이 들어오고 나도 부족하지만 알려줘야 하는 입장이 되다 보니

"이럴걸요?"가 아닌 확신을 기반으로 알려드리려고 많이 노력했다.

그래도 아직 부족한 짬바라고 많이 느꼈다.

회사 밖으로 나가면 나는 1, 2년 차 개발자일 뿐이고 스스로 많이 부족하다고 느끼고 있었기 때문에

다른 분들이 치켜세워주실 때는 기분이 좋기도 했지만, 사실 조금은 부끄러웠다.

이때쯤에 어떻게 하면 일을 빨리 잘할 수 있을지 고민했다.

잦은 커뮤니케이션과 회의, 질문들로 인한 소위 말하는 컨텍스트 스위칭과 쏟아지는 일들,

온전히 개발할 수 있는 시간이 부족했기 때문에 일들의 우선순위를 잘 매겨서 처리하는 게 중요했다.

최소한 내가 스프린트 별로 해야 하는 일들은 제대로 관리하고 다음 스프린트 설계도 같이 할 수 있어야 했다.

우리는 ClickUp을 사용했는데 기능별 & 처리 시간에 따라 카드를 쪼개서 만들다 보니 관리할 카드들이 많았다.

다행히 커스텀이 가능한 대시보드를 제공해서

TODO, Doing, Review, QA 등의 상태로 분리된 카드들을 한 곳에 모아서 관리할 수 있었다.

개인적으로 쓰다 보니 좋아서 사내에 공유했는데,

이걸 계기로 "스프린트 다운 스프린트를 보내려면 어떻게 해야 하는지?"를 주제로 한 사내 세미나도 진행했다.

요점은 본인의 퍼포먼스를 파악하고 그에 맞게 스프린트 계획을 정리하되,

중간중간 생기는 회의나 일 들을 고려해서 약간의 버퍼를 두고 관리한다.

이번 스프린트에 과도하게 일을 잡게 되면 다음 스프린트까지 영향을 줄 수 있기 때문에 태스크 분배를 잘하는 게 중요한데,

업무를 시작한 지 얼마 안 된 신입분들은 본인의 퍼포먼스가 어느 정도 나오는지 가늠하기 어렵다.

그래서 2 ~ 3 스프린트 정도 지켜보면서 본인의 퍼포먼스를 파악하고 수치화해서 관리할 수 있도록 해야 한다.

어느 회사나 그렇듯 수치화된 데이터만큼 관리하기 쉬운 건 없기 때문에 관리자 입장에서나 본인 업무를 관리할 때 수치화는 중요하다.

어떤 일이던 수치화 하고 객관적으로 바라보는 게 중요하다.

 

만 1년 경력이 안 되는 응애 개발자인 내가 리더?

입사하고 약 10개월 정도 되던 시기였다.

회사가 커지면서 사람들이 조금씩 늘어날 때 대표님께서 새로 만들어질 프로덕트 팀을 리딩 해보는걸 어떻게 생각하냐고 물어보셨다.

 

ㅈ..제가요..? ㅎㅎㅎ

띠용 반 흥분 반으로 관심 있다고 했고 기존 팀에서도 신제품을 기획부터 개발까지 진행했던 경험이 있어서 나름 되게 설레었다.

하지만 그 프로젝트는 시작도 해보지 못하고 퇴사했다.

기존 팀에서 진행하는 프로젝트조차 사람이 부족해서 인력난을 겪고 있었는데,

두 프로젝트를. 거기에 프로젝트 기획부터 리딩 하면서 진행할 수 있는 시간적 여력이 되지 않았다.

그렇게 직책만 "리더"로써 회사 생활을 이어갔다.

다른 팀 리더들은 팀원 관리와 프로덕트 관리 등으로 바빴다면 나는 "리더급"인 개발자로 열심히 기존 프로덕트 발전에 힘썼다.

그렇게 몇 달 지나고 내가 왜 리더 자리에 있는지 모르겠는 생각이 들었다.

적재적소에 배치되지 않은 것 같은 기분이었고 불필요한 리소스가 낭비되고 있는 것 같았다.

내가 속한 팀은 이미 나와 비슷한 연차를 가진 사람이 리더를 맡고 있었고 잘해주고 있었다.

이렇게 사람들과 프로덕트를 리딩 하는 게 리더이지 직책만 올려두고 회사 돌아가는 내용을 듣고 의견을 내는 건 리더가 아니었다.

짬바(라고 해봤자 1년이지만, 연차로는 상위권에 속했다.)만으로 리더 자리를 꿰차고 있는 것 같아 불편하기도 했다.

그리고 내가 리딩 하기로 한 프로젝트보다 우선순위가 높은 다른 신사업 프로젝트 프로토타입을 만들어야 했기 때문에

올해 연봉 협상을 진행할 때 리더 직책은 내려놓겠다고 말했다.

사람은 적재적소에. 아닌 건 아니다 말할 수 있게.

 

 

 

2편에서 계속..

 

 

 

 

2편 preview.

입벌려. 장애들어간다.