업무일기는 그냥 내가 보고싶고 기억하고 싶어서 쓰는거였는데
뭔가 다른 사람들이 쓰는게 너무 멋져보여서 취준회고를 썼다.
그리고 월간회고도 뭔가 너무 멋져보였고, 한달의 나를 돌아보는 시간은 매우 재밌을 것 같아서 적어본다.
소주제가 연속적으로 이어지는 글이 아닌 소주제별로 한개의 글처럼 글의 구조를 잡아서 작성합니다. (몇 개는 이어질 수도 있습니다.)
신입 개발자의 온보딩 과제
내가 다니는 회사도 온보딩 과제가 있었다, 조금 더 실무에 가까운 온보딩 과제들
어떤 것을 처리했냐면 아래의 리스트들이다.
- 공통 모듈로 분리해서 Deprecated된 코드 수정
- 커스텀 데코레이터 리팩토링
- 스웨거 응답 코드 추가
- Repository 패턴 적용
- QueryService 분리
- 기존 운영 업무 인수인계
- rawQuery -> ORM(저는 쿼리빌더로 바꿈) 변경작업
그리고 내가 찾아서 했던 업무들은 이런 것들이 있었다.
- 속도가 느린 쿼리튜닝
- Swagger 공통 데코레이터 제작 및 문서화
- 운영 업무 문서화
- 일부 작동이 이상한 코드 리팩토링
그러면서 뭐랄까, 어렵지 않다 라는 생각이 들었다.
내가 걱정했던 것보다 훨씬 할만하다 라는 생각도 함께.
입사 첫날부터 PR 올리는 신입개발자
입사 첫날 온보딩 과제 리스트를 받고 쉬운 것부터 처리하자는 생각이 들었다.
그래서 올렸는데 찬사를 받았다.
입사 첫날부터 PR을 올리는 신입이 있네? 라며....
그리고 온보딩과제가 끝나는 날까지 거의 하루에 한개의 PR을 올리면서 Merge가 됐다.
그와 동시에 나의 평가와 기대감이 MAX치가 됐던 것 같다(?)
저는 사무실 근무가 좋아요 같은 소리는 하지말았어야 했는데
지금 다니는 회사는 풀리모트에 가까울 정도로 재택근무를 할 수 있다, 월 1회는 사무실에 와야하지만
그런데 나는 재택근무에 대하여 부정적인 인식을 가지고 있었기에, 재택근무를 허락받아도 사무실 근무를 할 것이라 이야기했다.
출근 2주가 넘어갔을 때, 그러니 11일차부터 재택근무 허락을 받았다.
근데 너무...좋네...?
재택근무, 그것이 문제로다! <- 9월 4일, 재택근무 허가가 났을 때 썼던 글
사람마다 재택근무를 바라보는 시선이 많은데, 나는 신입의 재택근무는 좋지 않다! 라고 보는 편이였다.
왜냐하면 신입은 모르는 것이 많고, 질문을 하고 싶은 것이 많을테니까
케어를 받기 위해서는 사무실에서 있는 것이 좋다고 판단을 했던 것이였는데
이것은 사람의 성격과 가치관, 그리고 회사의 문화에 따라서 다를 수 있다는 것을 알았다.
그러면서 지금의 회사와 나한테는 신입이 재택근무를 해도 전혀 영향이 없다는 결론이 났다.
현재 회사는 풀리모트가 가능하도록 업무 프로세스가 맞춰져있었고
나는 질문을 하는 것에 대하여 두려움이 없었기에 내가 궁금할 때 마다 자유롭게 질문을 할 수 있었다.
그래서 출퇴근 2시간으로 오는 체력적 부담을 줄였더니 업무효율이 미친듯이 끌어올라가는 것을 확인할 수 있었다.
물론 문제가 아예 없진 않았다.
업무효율이 너무 올라가다보니 점심도 거르고, 퇴근시간이 넘어가도 그냥 일을 하는 둥
일상과 업무의 분리를 하지 못하는 문제가 발생했다.
그래서 이 부분에 대해서는 조금 많은 고민을 해봐야겠다는 생각이 들었다.
또 한 개가 더 있었는데, 현재 내가 업무하는 것에 대한 의구심이 들 수 있다는 것이였다.
현재 작업하는 양이 너무 많다보니 의문에 빠졌다.
왜...이렇게 된거지? 라는 생각을 하게 됐고, 나는 그냥 리더님한테 허들요청을 하면서 풀어냈지만
만약 바로 옆에 있었더라면 이런 의구심이 들지 않았을텐데 라는 생각도 들었다.
신입개발자가 아닌 것 같아요
회사에서도 듣고 주변에서도 듣고 있는 이야기 중 하나다
현재 하고 있는 작업이 좀 많이 크다.
택배사 연동과 함께 현재 프로세스에 문제가 있던 것을 고치고
통합하는 과정을 함께하고 있는데, 에픽 두개를 뭉쳐서 하고 있다. (대충 리팩토링과 신규피쳐를 한번에 하고 있다.)
이 업무를 저번주 월요일 (9월 19일)에 받았으니 출근한지 대충 16일차에 받은 것이다.
물론 처음에는 이렇게 거대할 줄 모두가 모르고 있었다.
그런데 막상 내가 작업을 하면서 뒤집어 까보니(?) 거대해질 수 밖에 없는 상태였다.
하지만 누군가 같이 작업을 하면 오히려 복잡해질 수 있고
다른 분들도 하고 있는 작업이 있어서 도움을 줄 수 없는 상황인데
생각보다 할만하다는 생각이 들었고, 순탄하진 한데 계속 진행이 되고 있다.
그러면서 리더님과 이야기를 했을 때 이미 신입을 벗어났다고, 2인분 이상의 일을 해주고 있다는 답변을 듣게 됐다.
그와 함께 생각이 들었던 것은 무엇이냐면
당연히, 일은 이렇게 해야하지 않나 라는 생각이 들었다.
내가 일을 하는 방법
출근한지 일주일이 되기 전에, CTO님한테 이런 이야기를 들었다. 리더가 나를 보는 기대치가 엄청 높은 것 같다고.
내가 일하는 방식은 정말 단순하다.
- 모르겠으면 질문한다.
- 질문을 할 때는 몇가지 원칙을 잡고 질문을 한다.
- 현재 어떤 문제를 해결하고 있는지
- 어떤 것을 시도해봤는지
- 뭐가 정답이라고 생각하는지
- 그리고 생각한 것을 가져가서 물어보는 것이 아니라, 키워드라도 메모를 해서 물어본다. (사람의 기억력은 그리 믿음직스럽지 못하다.)
- 질문을 할 때는 몇가지 원칙을 잡고 질문을 한다.
- 나의 상황을 계속 보고한다.
- 리더(관리자)급이 모든 팀원의 일이 어느정도 진행된 것인지 파악을 하는 것은 불가능에 가깝다.
- 그렇기에 현재 어떤 작업을 하고 있는지, 어떤 문제가 있어서 진도가 안나가는지 알린다.
- 리더(관리자)급이 모든 팀원의 일이 어느정도 진행된 것인지 파악을 하는 것은 불가능에 가깝다.
- 대답은 말이 아니라 문서로 한다.
- 말로 설명을 하는 것은 오해의 소지라던가 불필요한 커뮤니케이션이 발생할 가능성이 매우 높다.
- 그래서 나는 모조리 문서를 만들어서 PR에 껴넣는 식으로 올렸다.
보통 리더가 일을 주더라도, 그 일의 세부적인 내용을 모르는 경우가 많기에 문서로 만들어서 제시를 한다면 불필요한 커뮤니케이션을 줄일 수 있다.
- 말로 설명을 하는 것은 오해의 소지라던가 불필요한 커뮤니케이션이 발생할 가능성이 매우 높다.
- 원하는 업무가 있다면 먼저 이야기를 한다.
- 사람마다 하고 싶은 일이 있다, 그리고 하고 싶은 일을 한다면 조금 더 즐겁게 일을 할 수 있다.
- 그래서 온보딩 과제가 한번에 받은 것이 아니라 점차 늘어난 것이기에 리스트를 다 완료했다면 내가 찾아서 일감을 받아갔다.
- 사람마다 하고 싶은 일이 있다, 그리고 하고 싶은 일을 한다면 조금 더 즐겁게 일을 할 수 있다.
- 이해가 안된다면 미팅을 잡는다.
- 개발자는 혼자 일을 못한다, 그 기능이 필요한 이유가 있을 것이며 원인이 있을텐데 이것은 개발자가 전부 알 수 없다.
- 그래서 나는 기획팀, 운영팀, 히스토리를 알고 있는 개발자와 끊임없는 미팅과 회의를 요청해서 조금씩 풀어나갔다.
- 개발자는 혼자 일을 못한다, 그 기능이 필요한 이유가 있을 것이며 원인이 있을텐데 이것은 개발자가 전부 알 수 없다.
원래 일을 이렇게 했고, 일의 흐름을 지켜보고 그 흐름에 따라서 일을 해왔다.
그러면 자연스럽게 일머리가 좋다는 이야기를 듣게 됐고 나는 일에만 집중하는 편인데 (사내 정치같은 것을 정말 싫어한다)
그냥 평판 자체가 좋아진다, 그냥 일만 열심히 하는 것으로 만족하는 사람이라서?
아무튼 그래서 출근 초기부터 리더님이 좋은 평가를 해주시지 않았나 한다.
개발자는 개발에 집중할 수 있으면 좋겠는데
현재 개발자들이 운영적인 업무도 처리하는 상태다.
다양한 사유로 인해 개발자가 처리를 해야하는 업무들이 있는데
이런 것 때문에 개발자의 경험(?)이 나빠진다는 생각이 들었다.
그래서 입사를 하고 계속 지켜보다가 이런 것들을 최소한으로 할 수 있는 API를 몇개 만들어놨다.
그러면서 이번에 하고 있는 거대한 작업에 프로세스에 대한 개선이 들어갈 예정이다.
현재 발생하고 있는 운영적인 다양한 업무를 처리할 수 있게 문제에 대한 정의를 하고, 해당 부분을 해결할 수 있도록
다양한 것을 체크하면서 가능성을 체크하고, 현재 작업에 대한 준비를 하고 있다.
주니어와 시니어를 구분할 이유가 없는 것 같은데
취준을 할 때 상당히 많이 들었던 이야기였다.
나는 구분을 해야 맞다! 라고 생각이 들었는데, 일을 하면서 느끼는 것은 정말 할 이유가 없구나 라고 느꼈다.
그냥 자기 능력에 맞게 하면 되는거지 뭔가 그렇게 계층을 나눠서 도움이 되는 것이 없더라.
그래서 신입 개발자라는 호칭을 가지고 있지만, 이것에 얶메여서 나의 한계를 줄이는 것보다
하고 싶은 일을 내가 할 수 있는 일을 해나가면 된다는 생각을 요즘 들어서 많이 하고 있다.
커뮤니케이션이 무엇보다 중요하다.
일을 하면서 코드를 짜는 시간보다 누군가 대화를 하는 시간이 매우 많다.
물론 지금 하고 있는 작업이 외부의 영향을 많이 받는 작업이라서 그런 것 일 수도 있는데
정말 회의를 할 것이 많더라(....)
리더급, 시니어가 회의(미팅)을 참여하는 것이 아니라 해당 기능을 개발하고 있는 내가 주체가 되어서 체크해야하는 것이 더 많았다.
또 소프트 엔지니어의 언어로는 말을 하면 안되는 것이 정말 중요했다.
모두가 소프트 엔지니어가 아니기에 내가 생각하는 것을 그대로 말을 하면 상대방이 이해를 못한다.
그래서 최대한 풀어서 비유를 통하여 설명을 하는 것이 정말 중요했다.
물론 그러다보니 더욱 어려운 것도 사실이고..
내가 코드를 짜는 방법
나는 마치 글을 쓰는 것처럼 코드를 짜고 있다.
몇일차의 일기에도 적긴 했는데
그냥 이 코드(API)가 왜 필요한지 정의부터 한다.
그리고 그 후부터는 로직을 짬에 있어서 왜 필요한지 체크를 하고 예외사항을 적어놓는다.
그런 손으로 적어놓은 코드 흐름의 뭉치를 가지고 코드로 옮겨적는 작업을 하고,
작동을 해보면 대부분 뭔가 틀어지는 일이 발생하지 않았다.
물론 내가 아는게 별로 없어서 코드가 내 마음처럼 동작을 안하는 경우가 있긴 했지만(....) 전반적으로 돌아가는 흐름에는 문제가 없었다.
요즘 걱정을 하고 있는 것, 일상? 취미?
요즘들어서 걱정을 하는 것이 몇가지가 있는 것 같다.
일단 회사일을 제외하고 취미라는게 없다, 회사일 아니면 코드짜기 둘 중 하나만 한다.
지금 내가 회사일이 재밌고, 코드를 짬에 있어서 조금 더 좋은 코드를 짜기 위해서 내가 이런 행동을 하고 있는 것은 알고 있다
그런데 너무....책상에 앉아서 키보드만 치고 있다는 생각이 들었다.
여러모로 사람을 만난다거나, 집에서 나가서 하는 무언가를 해야한다고 생각이 들고 있고
서울에 올라오고나니 아는 사람이 아예 없다보니 약속도 못잡고, 그저 혼자 돌아다니는 것이 최선이라서
외로움의 차원보다는 뭔가 너무 나 자신을 감옥에 넣고 살아가지 않나? 라는 생각이 들고 있다.
이러한 부분을 어떻게 개선할 수 있을지, 해결을 해야할지 고민이고
운동도 나의 생명(...)을 위해서 해야하는데 지금 하는 피쳐가 끝나면 여유가 생길 것 같으니 아마 할 수 있지 않을까?
월간회고라고 뭔가 거창하게 적어보려고 했는데, 일기에 썼던 것을 되짚어서 요약하는 느낌이라 그냥 정말 한 달을 되돌아보는 글이 된 것 같다.
뭔가 마음에 들지 않는 것 같기도하고... 글쓰는 방식에 조금 변형을 주는 편이 좋겠다 라는 생각이 들었다.
끗
