👱♂️간헐적 회고
시간이 너무 빠른 것 같습니다.
벌써 입사한지 두달이 지났는데 회사에 들어오길 잘했다는 생각이 조금 들곤합니다.
항상 best pratice에 집착하면서 더 좋은 방법.. 더 좋은 방법..을 고민하는 것이
제 장점이자 단점이라고 생각하는데
그러면서도 마감기한은 맞춰야하는 상황이 있다보니
코드퀄리티와 속도를 적절히 타협하는 연습이 된 것 같습니다.
회사일과 개인적인 목표 두가지로 나누어서 정리하고 회고해보는 시간을 가져보고자합니다.
회사
1. 회사일은 생각보다 반복되는 작업이 많다.
-> 기술적으로 난이도가 있는 일은 아닌데 귀찮은,
일일이 하면 자동화할 수 있는 여지가 많은 일들이 꽤 있었습니다.
이것들이 자동화되면 참 좋을 것 같다는 생각이 들기도하면서
내 몸은 하나다보니 적절히 리소스를 분배해야 했습니다.
2. 간소화할 수 있는 일은 최대한 간소화해야한다.
-> 1과도 이어지는 문제인데 인원이 적은 스타트업이다보니
조직원 각각의 생산성이 조직에 바로 영향을 준다는 걸 체감했습니다.
그래서 이 부분들을 해결할 수 있는 여러가지 방법, 아키텍처들을 고민하고
일부분은 적용을 해봤습니다.
3. jira의 도입
-> 기존에는 의사소통은 slack / 스프린트 일정 및 타임플랜과 같은 계획은 노션에 작성해왔습니다.
그런데 제가 느끼기에는 팀의 스프린트 방식에 여러가지 문제가 있다고 느꼈었는데요
제가 다니는 회사에서 하나의 스프린트는
기획 -> 디자인 -> 개발 -> QA -> 배포
순서로 진행됩니다.
그런데 문제는 각각의 업무들이 병렬적으로 처리될 수 있는 것도 있지만
앞선 작업이 끝나야만 가능한 작업들이 존재한다는 것인데요
예컨대 디자인 시안이 확정되지 못하면 프론트엔드 개발 역시 완성될 수 없습니다.
또한 기획 역시 마찬가지로 기획이 확정되지 못하면 프론트엔드, 디자인이 나올 수가 없습니다.
그런데 한 스프린트에서 기획이 차일피일 미루어지고 디자인도 같이 미루어지게되는 경우
프론트엔드가 개발에 쓸 수 있는 시간이 말도안되게 줄어들게 되고
결국 스프린트 막바지에 저품질의 코드를 생산할 수 밖에 없었습니다.
또한 한 스프린트의 기간내에 할 수 있는 일을 정하는게 아니라
일단 하고싶은 일을 다 나열해놓고 그 스프린트에 하고싶은 일에 스프린트 기간을 우겨넣는 식으로 진행이 되었는데
이것 역시 뭔가.. 주객이 전도된거 아닌가..? 싶었습니다.
그래서 팀내에서 스프린트 체계를 바꾸어야할 것 같다는 공감대가 형성된 덕에
스프린트 방식을 변경하면서 jira도 같이 도입하게 되는... 결과가 나왔어요
사실 입사하기전에 스타트업이면 jira를 쓰고있겠지..?라고 설레발 치면서
jira 쓰는 법 찾아보고 그랬었는데 이번에 실제로 써보면서 익힐 수 있을 것 같습니다.
4. 비개발자와 잘 소통할 방법 만들기
국비 프로젝트나 개인프로젝트에서는 나 혹은 팀원 프론트엔드 개발자가 디자인까지 다루다보니
개발하기 쉬운 디자인 위주로 만들어오곤 하였어서 이런 어려움이 있을줄은 몰랐는데요..
디자이너가 화면을 바라보는 시각과 개발자가 화면을 바라보는 시각이 다르다보니
디자이너 입장에서는 이게 외 어렵다는거지?? 싶고
개발자 입장에서는 이걸 어떻게 구현하라는거지?? 싶은 상황이 많이 발생하였습니다.
물론 일차적으로 디자인 시스템에 대한 규칙을 잘 정의해야겠지만
역시나 쉽지않은 일이다보니 시행착오가 좀 있습니다.
별개로 개발자가 고려하게되는 여러가지 엣지케이스에 비개발자들도 쉽게 공감할 수 있도록
스토리북을 도입하고 배포하여서 디자이너, 기획자 등 비개발인원들도
컴포넌트에 접근해서 우리 컴포넌트가 이런 상황에선 어떻게 되는지를 쉽게 알 수 있고..
피그마에 통합해서 바로 써먹을수도 있게... 해보고... 싶은데...
크로미움 기반으로 바로 배포하는 것은 public하게 배포할 수 밖에 없는 것 같더라구요
디자인도 회사자산이다보니 특정 ip만 허용하는 식으로 배포를 해야할 것 같은데
그러자니 aws를 쓰는 게 국룰인 것 같아 보여.. 고민이 조금 있습니다.
개인
사실 저는 회사일 말고도 개인적으로 이루고 싶은 성취들이 몇가지 있습니다.
1. 블로그로 유의미한 수익을 이루기
어저께 광고수익이 하루에 10달러가량이 발생해서 아주 기분이 좋았습니다.
광고 많이 눌러서 제 사리사욕 추구에 도움을 주시면 감사하겠습니다.
평소에는 보통 평균적으로 한달 2달러 정도의 수익을 거두고있었는데요
매달 출금을 하면 기분이 좋을테니까 한달에 출금 최소한도 100달러씩 수익을 목표로 하고있습니다.
2. 인프런 강의 찍어보기
이게.. 제 버킷리스트 중 하나인데 이래저래 내적 갈등이 많습니다.
네가 뭐라고 강의를 찍냐 ㅇㅅㅇ... 하는 자아와
강의 찍어서 밥사먹고 다니면 기분 굿일듯 ㅇㅅㅇ.. 하는 자아가 매일 싸우고있어요
당장 몇달전에 작성한 블로그글만 봐도 저떄는 왜 저게 맞다고 생각했지? 싶은 것들 투성이인데
돈받고 파는 강의에서 그런 실수를 저지르면... ㅇㅅㅇ...할 것 같네요..
근데 또 제가 눈높이 맞춰서 쉽게 설명하는거는 나름대로 자신이 있어서
초보자 타겟으로는 나도 가르쳐줄만하지 않나..? 하는 근거없는 자신감도 조금 있고..
모르곘네염
3. 더 잘하는 개발자 되기
무엇이나 다 그렇겠지만 개발은 공부하면 공부할수록 내가 부족한 것 투성이다.
라는 것을 꺠닫게 되는 것 같습니다.
몇달전의 내가 생각하던 잘하는 개발자와
지금의 내가 생각하는 잘하는 개발자도 다르니까 아마 몇달뒤에도 다른 기준을 가지겠죠?
그래도 일단 제가 다음 단계로 넘어가기 위해서 뭘 해야할까?를 생각해봤는데
1. aws로 next.js 프로젝트 배포하고 관리해보기
-> 버셀의 그늘에서 벗어나 직접 배포를 해보는 경험은 중요할 것 같다.
feconf에서 next.js 프로젝트의 메모리누수 원인 트래킹하는 컨퍼런스 영상이 있었는데
그걸 보면서 아.. 직접 배포해보면 저런 어려움도 겪어볼 수 있겠구나 싶어서 버킷리스트에 넣었습니다.
2. 테스트, 스토리북 생활화 하기
-> 저 둘은 개발속도를 당장은 낮추게 하는 것처럼 보이지만 나중에는 생산성을 끌어올려주더라구요
특히 스토리북을 통해 ui를 관리하고자 하다보니 자연스럽게 ui와 데이터를 분리하게되고
순수한 ui 컴포넌트를 만들게되니 관심사가 잘 분리되고
관심사가 잘 분리되니 나중에 코드를 수정하거나 확장하기 쉬워지는
선순환 구조가 만들어지게 되는게 정말 좋았습니다.
근데 스토리북 hmr이 너무 느려서 이거 뭐 방법없나.. 하는데 잘 모르겠어서 고민인것도 추가하고..
테스트 같은 경우에는 내가 짠 코드가 잘 동작하는지 /
내가 리팩토링한 코드가 이전과 동일하게 동작하는지를 검증하는데에 너무 큰 도움을 주는 것 같습니다.
사내에 건드릴 수 없는 괴물 메서드들이 여럿있는데 이런 것들을 어찌저찌 리팩토링하고 난다음
느끼는 감정은 내가 고친게 동작에 영향을 주진 않았을까? 였거든요
테스트가 잘 마련되어있으면 그런 부분에서 두려움을 느끼지 않아도 되는게 참 좋았습니다.
3. npm 라이브러리 만들어보기
클린한 코드를 작성하기 위해 노력하면서 느끼게 된 것은
외부종속성 , 라이브러리, 프레임워크 역시도 최대한 배제하는게 예측가능한 코드를 만드는 길이라는 것이었습니다.
그러다보니 외부종속성을 억제하고 싶어지고 그러다보니 직접 구현하고
직접 구현해보니 다른 프로젝트에서도 쓰고싶고...
그러면 매번 복붙하는거보다 우아하게 npm으로 깔고싶고..
4. 모노레포 터보레포 마이크로프론트엔드 등등..
요즘 좀 인스타 광고같은 데에 많이 뜨는 키워드라 오히려 비호감이 되긴하는데
모노레포, 터보레포가 제공하는 경험이 얼마나 좋길래
대규모 기업에서 너도나도 채택하는 것일까?
그리고 예전엔 즐겨썼지만 이젠 정이 떨어져버린 yarn berry와
아직 안써본 pnpm... 얘네들도 언젠간 친해져야겠지..란 생각을 하고 있습니다.
마치며
사실상 사수, 개발문화가 없는 수준인 환경에서 혼자 개발하는 것이 내 성장에 도움이 될까?
주변에 시니어 개발자, 잘하는 동료개발자들이 많은 환경에서 업무하는 사람들을 내가 이길 수 있을까?
같은 고민들을 가끔 했는데
반대로 생각하면 내가 필요하다 생각이 들면 프로젝트 코드를 마음대로 뒤엎을 수 있고
컨벤션도 내가 정할 수 있고 시도해보고 싶은 것들도 다 해볼 수 있고
내가 하기만하면 뭐든지 다 해볼 수 있는 환경에 놓여있는 것이더라구요
쪼렙떈 죽어도 경험치 안깎이니까 실컷 죽어보면서....
더 레벨업해보겠읍니다..
'간헐적 회고' 카테고리의 다른 글
2024년의 첫번째 간헐적 회고 (3) | 2024.01.11 |
---|---|
9월 10일의 간헐적 회고 통장만들자.. (1) | 2023.09.10 |
아주 간만에 돌아온 간헐적 회고 (1) | 2023.09.03 |
7월 31일의 간헐적 회고 (0) | 2023.07.31 |
7월 12일의 간헐적 회고 (0) | 2023.07.13 |