마지막 퇴근한 지가 벌써 한 달이 다 되어간다.
퇴사하고 본가로 내려가게 된 터라 자취방에서 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년이지만, 연차로는 상위권에 속했다.)만으로 리더 자리를 꿰차고 있는 것 같아 불편하기도 했다.
그리고 내가 리딩 하기로 한 프로젝트보다 우선순위가 높은 다른 신사업 프로젝트 프로토타입을 만들어야 했기 때문에
올해 연봉 협상을 진행할 때 리더 직책은 내려놓겠다고 말했다.
사람은 적재적소에. 아닌 건 아니다 말할 수 있게.
탈도 많고 배운 것도 많은 장애 대응
대부분 인프라 측 장애가 많았다.
서비스를 클라우드 환경으로 제공했는데 사용자의 사용률이 높아지거나
순수하지 않은 목적으로 서비스를 악용하는 사람들이 주된 원인이었다.
감사하게도 대부분은 인프라 엔지니어분들과 개발자들의 활약으로 큰 문제없이 넘어갔다.
필자가 입사하고 크게 장애 대응한건 3번 정도 있었다.
개발자와 인프라 엔지니어가 같이 대응했던 장애 였는데,
그 중 입사하고 몇 달 되지 않았을 때 터진 첫 장애 대응 때는 정말 정신이 없었다.
오후 시간에 장애가 갑자기 터지고 다음날 새벽이 되어서야 복구된 적이 있었는데,
이때 직종을 불문하고 한자리에 모여 각자 포지션에 맞는 대응책을 내놓았다.
정말 인상 깊었는데, 특히 마케팅 팀에서 고객 대응에 대한 매뉴얼을
명료하고 정확하게 제시해주신 게 정말 멋있었다.
이게 스타트업인가? 이게 회사인가? 싶었고
필자도 저렇게 전문적이고 침착하고 당당한 시니어가 되어야겠다는 다짐도 생겼다.
그리고 이때 복잡했던 인프라 구조를 파악할 수 있었다.
업무 진행을 위해서 서비스 구조를 이해하는 게 중요했는데, 몇 번 설명으로만 들었을 때는 잘 몰랐다가
장애 대응 한 번에 깨달은걸 보면 역시 실전이 최고다.
며칠 후, 장애에 직접 관련된 개발자가 당시 상황, 원인, 대응 절차 등과 함께
재발 방지를 위해 어떤 노력을 했는지 모두에게 발표했다.
이 재발 방지 대책은 필자가 만약 다른 곳에서 실수를 하더라도
기록한 후 재발 방지 대책은 반드시 필요하다고 생각했다.
비슷한 실수를 여러 번 반복하지 않기 위해서는,
특히 여러 사람의 협업이 필요한 회사에서는 기록과 회고가 꼭 필요하다.
문제는 이런 재발 방지 대책을 세워도 또 다른 이유로 서비스 알람은 계속 울린다는 것.
대부분의 문제는 오래전에 작성된 레거시와 개선되지 않는 성능 문제라고 생각했다.
하지만, 오래된 레거시를 작업할 인력도 없었고
주석이 없어 “이때는 왜 이렇게 코드를 작성했는가?”는 기존 멤버에게 물어보지 않으면 모른다.
무엇보다 끊임없이 밀려오는 새로운 프로젝트들을 처리하기 바빴던 날들을 돌이켜보면 조금은 아쉽다.
새로운 것도 중요하지만 기술 부채를 해결하는 것도 중요했다.
레거시들을 보면서 최신 문법으로 작성되었느냐 아니냐가 중요한 게 아니라
나중에 다른 사람이 봤을 때 편한 코드가 좋은 코드라고 생각했다.
결국 최신 문법에 익숙한 사람이라면 최신 문법으로 작성해야 읽기 편하겠지만
그걸 뛰어 넘어서 깔끔하게 짤 수 있는 클린 코드를 작성하도록 하자.
같은 실수를 반복하지 않기. 누가 봐도 의도가 분명한 코드 작성.
질문 좀 자주 하세요!
필자는 첫 인턴으로 들어갔을 때 질문을 하기 참 힘들어했다.
물어보는 게 창피하다기 보단 그때는 회사 분위기가 정말 일만 하는 분위기였고
업무시간에는 키보드 소리가 대부분이었으며 잡담 소리도 듣기 힘들었다.
회사의 강압적인 분위기라기 보단 그런 성격을 가지신 분들이 많아서 그랬는데
실제로 비타민 같으신 분들이 많이 들어오시면서 분위기는 많이 달라졌다.
그전에는 원래 회사가 그렇게 일만 하는 공간인 줄 알았다.
자리도 멀어서 정적을 깨고 질문을 하러 가기보다
혼자서 해결해보자는 오기 아닌 오기가 생겼다.
그러다 보니 물어보면 10분 만에 해결할 수 있는 문제를 몇 시간에 걸쳐 고민한 적도 있었고
생산성이 너무 떨어져서 혼자 해결하는 게 능사는 아니라는 걸 느꼈다.
그래서 그 뒤로는 제대로 된 질문을 하도록 노력했다.
그때 느낀 게 커서 그런지 새로 입사하시는 분들에게는 꼭 “질문 좀 자주 하세요!”라고 조언드린다.
처음부터 사수 눈치 보면서 부담감에 질문하지 않고 혼자 해결하려고 하는 것보단
질문을 통해서 조금 더 빠르고 정확하게 답에 도달하는 게 낫다고 생각했다.
물론 구글링으로 얻을 수 있거나 조금 고민해서 답을 낼 수 있는 법한 질문을 이야기하는 게 아니다.
고민하면서 얻는 소득도 많겠지만 몇 시간짜리 고민들은 혼자 공부할 때나 필요한 거지
시간과 생산성이 직결되는 회사 일을 하면서 해야 할 건 아니라고 생각한다.
약간 오해의 소지가 있을 수 있는데, 요지는 불필요하게 긴 고민은 사수에게 도움을 요청하라는 뜻이다.
그럼 어떻게 해야 질문을 “잘” 할 수 있는걸까?
질문은 양날의 검과 같다.
CPU에도 콘텍스트 스위칭이 있듯 사람도 똑같다.
다른 주제로 넘어갔다가 다시 원래 주제로 넘어와서 효율을 내려면 어느 정도 시간이 필요하다.
질문은 사수의 시간을 뺏는 거고 그만큼 사수의 생산성은 낮아질 것이다.
반대로 내 시간은 절약되고 내 생산성은 높아질 것이다.
따라서 필요한 질문만 잘 정리해서 물어보는 게 중요한데
필자는 급한 게 아니라면 메신저를 많이 활용했다. 회사마다 다르지만 필자는 슬랙을 사용했다.
직접 찾아가서 물어보는 것보다 서로의 시간을 아껴줄 수 있고
당장 자리에서 답변해주지 않아도 되기 때문에 답변자의 부담도 덜어 줄 수 있다.
무엇보다 질문에 대한 배경 설명과 어디까지 알아봤는지를 잘 정리해서 공유하고 물어보는 게 중요하다고 생각한다.
대충 정리해서 그냥 물어보면 질문받는 입장에서도 기분이 좋지는 않다.
질문을 하는 거에 대해서 눈치는 보지 말되 잘 정리해서 물어보고
어떤 고민이 생겼을 때는 제품의, 조직의 성장을 위해서 어떤 방향으로 하는 게 좋을까? 를 기준으로 생각해보자.
얼마 되지는 않았지만 처음에 하기 쉬운 실수 중 하나가 개발하기 편하게 먼저 생각한다는 것이다.
개발하기 편하게 가 아니라 유저가 편하게 제품이 나아가야 한다.
질문을 하되 일목요연하고 최대한 남 시간 뺏지 않도록.
제품과 조직이 성장할 수 있는 방향으로.
나에게 아쉬웠던 부분
하나씩 나열해보자.
- 처음에 적극적으로 질문하지 않은 것.
- 커뮤니케이션 능력이 좋다고 생각했으나 사실상 회사에서, 스타트업에서 필요한 커뮤니케이션 능력은 달랐던 것
- 건강을 챙기지 않은 것
- 자기 계발을 소홀히 한 것
1번은 위에서 살펴보았으니 패스.
스타트업에서 필요한 커뮤니케이션 능력은 달랐던 것
필자는 학부생 때 동아리장을 한 경험이 있다. 100명이 넘는 인원에 나름 체계적인 동아리였고
학교에서도 매년 상을 받을 만큼 인정받는 동아리였다.
그렇게 1년 동안 잘 이끌어본 경험이 있었고 평소에 사람을 둥글둥글하게 대하다 보니
나름 커뮤니케이션 능력에는 문제가 없을 거라 생각했다.
하지만 회사에서는 달랐다.
회사에서는 싫은 말도 똑바로 할 줄 알아야 하고 무엇보다 틀린 건 틀렸다 말할 수 있어야 했다.
설령 나보다 높은 연차를 가지고 있다고 해도 필자는 같이 일해야 하는 한 명의 개발자로서
납득되지 않는 방향성이라면 이해하려고 노력하고 더 나은 방향으로 나아갈 수 있도록 토론해야 한다.
처음 적응기간에는 어쩔 수 없다고 하더라도
그 이후에는 제품을, 조직을 나은 방향으로 이끌 수 있는 하나의 열쇠가 되어야 한다.
그러기 위해선 당당해져야 한다.
“나 따위가 감히 선배에게?” 같은 흔히 말하는 “꼰대” 마인드를 가지고 있으면 안 된다고 생각한다.
시간이 지나고 본인이 선배가 되면 똑같이 생각할 거기 때문에..
물론 정도를 알아야겠지만 최소한 제품의 방향성에 관한 내용에서는 토론하면서 최선의 방향으로 갈 수 있도록 해야 한다.
건강을 챙기지 않은 것
입사 전보다 10킬로나 몸이 불었다.
늦은 출근 늦은 퇴근이 반복되면서 집에 오면 오늘 하루도 고생한 나에게 배달음식을 자주 선물한 게 주된 원인이었다.
회사에서 먹는 저녁식사는 대부분 고칼로리의 음식이었고 앉아있는 시간이 많다 보니 자연스럽게 체중은 불었다.
스트레스를 받으면 코인 노래방을 찾아가는 게 국룰이였는데
코로나 시국이 겹쳐서 퇴근 후에는 어떤 활동을 하는 게 어려웠다.
결국 스트레스는 음식으로 푸는 악순환이 반복되었다.
불어나는 체중을 조금이나마 잡기위해 운동도 하기 위해서 PT도 받았다.
식단 조절도 하면서 조금 되찾았지만 공용시설 이용 시간이 점점 제한되고 퇴사 몇 달 전에 PT는 그만두었다.
운동을 그만두고 스트레스가 극에 달했던 연초에 다시 조금씩 몸무게가 불었고 최고점을 찍은 상태로 퇴사를 했다.
이후에 꾸준히 운동해서 입사 전 몸무게로 돌아왔다.
자기 계발을 소홀히 한 것
2021년 개인 github 잔디밭은 가뭄이었다.
반면 회사 github 잔디밭은 풍요로웠다.
주말 커밋도 심심치 않게 찾아볼 수 있었고
이때는 개인 개발 시간에 회사 제품을 더 발전시키려는 목적도 있었다.
그만큼 제품에 애정을 쏟았다.
지금 생각해보면 그보다 개인 공부를 하는 게 더 필요했다.
개인의 성장이 회사의 성장이라고 하지만 반대말이 지켜지는건 쉽지 않은 것 같다.
회사일을 하면서 개인이 성장하는 건 어느 정도 한계가 있고
회사에서 얻을 수 있는 경험치와 개인 공부에서 얻을 수 있는 경험치는 다르다고 느꼈다.
주말 근무를 제외한(휴가로 줬음) 평균 초과 근무 시간은 법정 기준을 아슬아슬하게 넘지 않았고
퇴근하면 자고 다시 출근하기 바빴다.
주말에도 회사 출근을 찍지 않고 집에서 일한 적도 많았다.
주변의 만류에도 불구하고 계속 1년이 넘는 시간 동안 열심히 할 수 있었던 건
제품에 대한 애정이 있었고 동료들이 같이 으쌰 으쌰 하면서 열심히 했기 때문이었다.
그러다가 회사가 대내외적으로 상황이 변하고 제품에 대한 방향성도 점점 달라진다고 느껴서 이직을 결심하게 되었다.
스타트업에서 얻을 수 있는 많은걸 얻었기 때문에 열심히 한 과거에 후회는 없다.
다음 회사에서도 열심히 하겠지만 그때는 개인의 발전이 곧 회사의 발전이라는 기준에 맞게 개인 공부도 열심히!
당당하기. 개인의 성장에도 집중하기.
앞으로는?
할 수 있다면 이직에 성공하고 퇴사하는 게 베스트였지만 퇴사하고 하고싶은게 많았다.
국토종주고 가보고 싶고, 무엇보다 건강한 프레임을 갖추고싶다.
어느 회사에 갈지는 모르겠지만 사람을 중요시하는 회사에 가고 싶다.
사용자가 편하게 쓸 수 있는 결과물을 만들고 싶다. (사용자를 생각하게 하지 마!)
단순히 개발을 하는 게 아닌 문제점을 해결하는 사람이 되고 싶다.
앞으로가 기대된다!