❗️ 스압주의 ❗️
짧지 않은 3개월간의 기록입니다.
회사와 무관하게 오로지 팀에서 경험한 내용들로 작성되었습니다.
무슨 일을 하였나
FE팀에 합류하여 프로젝트의 대시보드 페이지를 담당하여 개발하였습니다. 초반에는 프로젝트를 혼자 담당하게 되어 FE리드분에게 물어물어가며 개발 환경 구축과 작은 컴포넌트부터 개발하는 업무를 하였습니다. 이후에 FE개발자분들의 합류로 FE개발자분과 협업 하였습니다. 팀 내의 디자이너분들, 백엔드 개발자분들과 의논이 필요한 상황이 많았어서 함께 논의 후 결정하는 업무도 하였습니다.
어떻게 일을 하였나
스프린트
개발팀은 스프린트를 2주 단위로 하여 첫 날에는 task(담당하게 될 업무) 정리와 서로 이슈사항에 대해 공유하였고 마지막 날에는 회고를 진행하였습니다.
FE의 task는 다양한 방법으로 정리하였었는데 (FE리드분의 주도하에 진행)
- 큰 단위의 task가 주어지고 각자가 쪼개서 해보기
- 처음부터 작게 task를 정하여 하루 단위로 정하기
- 적절한 크기로 task를 정하여 기간은 알아서 정하기
1~3번까지 순서대로 해보며 장단점을 느끼고 더 나은 방향으로 task를 정할 수 있었습니다.
마지막 날 회고를 진행하며 어떤 이슈가 있었는지 업무 강도는 어떠하였는지 등을 이야기하며 task에 대해서 우리는 중간중간 블로킹 이슈가 있더라도 못한 것에 대해 탓하지 않고 이런 상황들을 다음 스프린트 때에 좀 더 잘 적용할 수 있도록 개선하는 것에 초점을 맞추었습니다.
코드 리뷰
우리는 PR을 2명 이상에게 approve를 받았을 때 코드를 머지할 수 있는 룰이 있습니다. 이런 룰에 의해 리뷰를 빠르게 받아 머지하고 싶다면 다른 개발자분이 파악하기 쉽도록 PR을 만들어야 합니다.
예를 들어서 typescript 설정과 eslint 설정이 있다면
[PR 1] Set Typescript
[PR 2] Set ESLint
[PR 3] Config Typescript & ESLint
위와 같이 PR을 쪼갤 수 있습니다.
위와 같은 작업들은 코드량이 적을 수 있어 한번에 PR을 올릴 수 있지만 이렇게 나누어 PR을 올리면 작업자도 업무를 쪼개어 빠르게 개발할 수 있고 리뷰어도 해당 PR의 역할 자체만 확인하여 코드를 파악하기 편해집니다.
또한 gitmoji를 사용하면서 커밋 단위를 의미있는 단위로 쪼갤 수 있었습니다.
기술 결정
개발을 하다보면 기술의 선택을 해야 하는 시간이 한번쯤은 오는데 우리는 스스로 선택할 수 있는 한해서는 스스로 결정을 하고 논의가 필요한 사항은 자신이 담당하지 않더라도 선택적으로 논의에 참여해 다같이 의견을 나누어 결정하였습니다.
또한 기술에 대해 자료 조사가 필요한 경우에 스터디 시간을 정하여 고려하는 기술에 대해 공부하고 이후 미팅을 잡아 기술에 대해 토의하여 결정하였습니다. 미팅의 토의 내용을 기록하여 왜 이 기술을 선택 하였는지에 대하여 정리하였습니다.
컨디션 관리
우리는 FE리드분께서 매주 1on1(1대1 미팅)을 진행을 하였습니다. (인원이 늘어나면서 2주에 한 번으로 바뀌었습니다.)
1on1은 자신이 고민하고 있는 것, 업무에 관한 것, 요즘 자랑거리 등 개인적인 것부터 업무적인 것 까지 자유롭게 이야기하는 자리입니다.
이런 미팅이 초반에는 어떤 이야기를 해야할 지, 솔직하게 이야기해도 될 지 등 회사이기 때문에 얼마나 솔직해야 할 지 고민이 많이 되었는데 사실 미팅을 가지면서 '이런 얘기 하면.. 나를 이상하게 보지 않을까?', '이런 얘기 해도 될까?' 하는 것들을 많이 이야기하게 되었고 정말 도움이 많이 되었습니다.
정신적으로 업무적으로 내가 정말 모르는 것도 있었고 사실 답은 정해져있는데 내가 그 답을 정리를 못하는 상황도 있었습니다.
그래서 결과적으로는 팀 내에서 더 효율적으로 업무할 수 있게 되었고, 이런 과정을 거치며 나에게 좋은 리더가 있다는 점은 다음 회사를 고를 때 정말 중요한 요소가 되었습니다.
비동기 방식
우리는 메신저로 슬랙을 사용하였는데 기본적인 소통의 룰은 비동기 방식이었습니다.
질문 대상자가 바로 대답을 할 수 없는 상황이라면 질문을 던져놓고 다음번째 업무를 하였습니다. 이런 상황에서 1번일을 끝내지 못하고 2번일을 하는 것에 대해 팀원들 모두 인지하고 있었고 1번의 일을 빠르게 마무리하지 못하여도 답을 얻기 전까진 스스로 할 수 없는 일이라는 것을 알고있기에 팀원을 탓하는 일은 없었습니다.
비동기 방식에서 나타나는 문제들이 얼마동안까지 기다려야 하나였는데 이런 부분들은 상황이 발생하였을 때 팀 내에서 의견을 나누어 중요한 사안은 1시간이나 태그하여 바로, 아닌 사안들은 하루정도로 정하기도 하였습니다.
그래서 초반에는 뭔가 하나를 끝내고 다음것을 해야하는 습관이 있었는데 우리 모두가 대답을 바로해줄 수 있는 상황이 아니었다는 것을 인지하고 동기적으로 일하지 않으려고 노력하였고 이로써 시간 분배를 좀 더 잘 할 수 있게 되었습니다.
이전의 두 회사를 거치며 혼자 일하는 것에 익숙했던 저는 팀원분들을 만나고 이러한 업무 방식을 통해 협업을 더 잘 할 수 있게 되었습니다.
어떤 것을 배웠나
질문은 좋은 것!
그라운드 룰에 어느정도 시간이 지났을 때도 해결이 되지 않으면 무조건 질문하자는 룰이 있었는데 코로나로 인해 대부분의 날들을 재택근무 하면서 질문 내용이 애매하다고 느껴지면 질문이 어렵다고 느꼈졌습니다.
그래서 스스로 찾아보는 것이 많았는데 그럴 때마다 시간도 시간이고 업무적으로 피로도 많이 쌓이고 머리도 아팠습니다.
'이런 질문을 해도 되나?' 라던지 너무 기초적인 것이 아닐까, 내가 아직 찾지 못한 것이 아닐까 라는 생각들을 많이 했었는데 직접 부딪혀보니 어느정도 찾아봤을 때 모르겠으면 바로 물어보는 것이 좋은 것이라고 생각합니다.(질문할 수 있는 분이 계시다는 전제하에..)
질문이 막 따끈따끈할 때 물어봐야 그 당시에 궁금한 점들을 모두 얻을 수 있고 내가 생각하지 못한 답을 얻을 수도 있습니다. 또한 시간적으로도 낭비가 줄어듭니다.
그런 소통의 과정에서 서로에게 부족한 것과 알고 있는 것을 공유하며 제품과 기술에 대한 이해도가 더 빠르게 올라간다고 생각합니다.
문서의 중요성
항상 작성되어있는 문서만 보며 업무를 했었는데 초기에 혼자 작업을 하다보니 다른 개발자분이 합류 하였을 때 볼 수 있도록 히스토리를 남겨야 겠다는 생각이 들어 문서를 작성해 보았습니다.
문서를 작성하며 많이 느낀 것이 내가 개발은 했지만 왜 이걸 사용했고 어떤 장단점이 있고 등 조금씩 내가 부족했던 부분들을 알 수 있었습니다.
사실 나만 볼 문서라면 나만 알아보기 쉽게 하여도 되는데 다른 분들이 본다는 생각에 몇번이나 읽으면서 어느 부분이 부족한 지 어느 부분이 불필요한지를 스스로 많이 검토하였습니다.
또한 작성한 문서를 피드백을 받을 수 있었는데 이 부분도 정말 중요합니다.
아무리 내가 스스로 검토하여도 나는 이미 이 문서에 익숙해져 있기 때문에 찾지 못하는 부분이 분명히 생깁니다.
이 때 다른분께서 검토를 해주신다면 부족한 부분을 금새 찾을 수 있습니다.
마치 오늘 공부한 내용을 복습하듯이 개발에도 내가 오늘 했던 업무나 습득한 기술을 문서화 시켜보는 것은 나의 성장을 위해서도 중요한 과정이라고 생각합니다.
결론적으로 문서를 작성하는 것은 내 실력을 확실하게 알아갈 수 있고 팀원들이 프로젝트에 대한 이해도를 더 빠르게 높일 수 있습니다.
개발 관련 부분들
내가 무엇을 했는지 기억하기 위해 남긴다..
- gitmoji
- typescript
- eslint
- next.js
- monorepo
- tdd
- browser cookie
얼마나 성장하였나
기술적으로 알게 된 것도 많고 유튜브 강의나 개발 관련 책도 많이 알게 되었습니다.
이런 것들을 통해 내가 학습한 만큼 성장했다고 확신합니다.
저는 여태 구글의 도움을 주로 받았는데 좋은 책과 좋은 영상이 많이 있다는 것도 알게 되었습니다.
어떤 도구들을 통해 어떤 방향으로 성장할 준비가 되었습니다.
아쉬운 점이 있는가
오피스
3개월동안 오피스를 한 달도 가보지 못했습니다.. 오피스에서의 개발과 팀원들과 북적북적대며 업무를 하지 못한 것이 아쉽습니다.
코드 리뷰
코드 리뷰만으로도 많이 성장할 수 있는 것을 느껴(네이밍이나 왜 이렇게 개발하였는지 설명 등) 나중에는 내 코드에 👍🏻만 있는 approve를 받고 싶었었는데 초기에 구축과 설정을 주로 하다 보니 뭔가 직접 만드는 개발을 많이 못하여 코드리뷰를 많이 못 받았다는 점이 아쉽습니다.
작은 발표
팀 내의 미팅에서 지금까지 구현한 것을 시연한 적이 있었는데 준비를 너무 못해서 말도 버벅이고 설명도 잘 못한 것 같아서 너무 아쉬웠습니다. 다시 되돌아가서 제대로 준비해보고 싶다는 마음이 듭니다.(팀원분들은 엄청난 칭찬을 해주셨지만.. 그래서 그랬는지 더욱 더 부끄러웠다..)
앞으로 어떤 것을 어떻게 하고 싶은가
이 곳에서 업무를 하며 팀원들이 저를 믿어주기에 불필요한 의심을 줄일 수 있었고 그것이 곧 일의 능률을 향상시킬 수 있었습니다.
나 스스로도 나를 의심하지 않을 수 있게 되었습니다.
'이것을 내가 해도 되는걸까?', '이런 결정을 내가 해도 되는걸까' 등의 생각들을 많이 하였었는데 이런 생각들을 접게 되었고 이런 일을 맡겨주었으니 잘 해보자 라는 생각이 들게 되었습니다.
그래서 나 또한 그런 사람이 되고 싶다라는 생각도 갖게 되었습니다.
또한 여기서 배웠던 것들을 잊지 말고 꾸준히 해 나가는 것 입니다.
그래서 이 글을 쓰게 되었고 여기서 겪었던 마음들을 계속 되새기면서 계속 성장하고 함께하고 싶은 동료가 되고 싶습니다.
마무리
사실 3개월이면 100일도 채 안되는 기간이고 한 계절의 기간이 될 수 있어 각각 짧고 길게 느껴질 수 있는 시간이라고 생각합니다.
저에겐 이전의 경력의 시간보다도 많이 경험하였고 배울 수 있었던 시간이었다고 확신합니다.
얼마나의 시간을 어떻게 보내느냐에 따라 의미있게 보낼 수 있는지 느낄 수 있는 시간이 었고 앞으로도 계속 의미있는 시간을 보내고 싶다고 생각할 수 있는 시간이었습니다.
나의 성장 가능성도 정말 중요하지만 그 상황에 어떠한 환경인지도 매우 중요하다고 느꼈습니다.
어떤 팀원들과 어떤 리더와 함께 일하며 모두의 성장을 함께 이루는 것이 회사와 우리에게 모두 좋은 일이 아닐까요?
좋은 경험도 기록을 남기지 않으면 '좋았다'라고만 기억할 수 있기에 스스로 나태해질 때마다 돌아볼 수 있게 기록을 남깁니다.
앞으로 이 글을 보며 '아 이 때 이렇게 했었지!'라며 스스로 깨달으려고 합니다.
이런 글을 공개적으로 처음 써보는데 읽으시면서 불편한 점이 있었다면 너그러이 양해 부탁드립니다.
