프로젝트
뎁코 시작 6월부터 기다리던 두근두근 최종 프로젝트가 시작되었다.
중간 프로젝트에서 최종 프로젝트를 위한 준비 과정이라 생각하고 기획보다는 기술적 성장에 초점을 두었던 만큼 기획부터 개발까지 꼼꼼하게 잘 만들어봐야겠다는 의욕이 샘솟는다.
기획 단계에서 프롱이 백둥이 모두 상용화할 수 있는 서비스로 만드는 데 초점을 두고 시작한 터라 포폴용 뿐만 아니라 퀄리티 높은 서비스가 될 거 같아 기대가 크다.
서비스와 협업 방식에 대해서는 따로 작성하도록 하겠다.
Keep
일단 쓰기 금지
지난 회고 때 일단 개발이라는 키워드로 기능 구현은 되는 코드를 작성해두고 마감일까지 리팩토링을 거치는 것을 Keep으로 두었다. 일단 코드를 빠르게 작성하고 리팩토링을 거치면서 보완해나가는 작업을 하다보니 굴러가는 결과물은 빠르게 낼 수 있었지만 리팩토링 과정에서 구조를 바꾸고 짜놓은 코드를 다시 보는 과정을 반복하다 보니 최종 결과물로 만드는 데는 결과적으로 시간이 더 들어가게 되었다.
그래서 Keep을 180도 바꿔서 구현하기 전에 미리 설계하고 코드를 짜는 연습을 많이 했다. 아직 부족하지만 코드를 수정해야 하는 번거로움을 조금이나마 줄일 수 있었다.
기술이나 툴에 대해 틈틈이 공부하기
이번 프로젝트에서 tanstack-query, zustand, msw를 처음 사용하게 되었다. 기술 스택을 어느 정도 정해두고 기획, 디자인 할 때 틈틈이 공부를 했다.
tanstack-query와 msw는 최근에 업데이트가 되어 공식문서를 위주로 공부를 했다. (공식 문서로만 공부하는 게 괜히 멋져보여서 블로그를 최대한 참고하지 않지 않으려고 했지만 달콤한 맛에 자꾸만 손이 가게 된다.)
프로젝트에 기술을 바로 도입하기에는 막힘이 있지만 미리 공부해 둔 게 도움이 많이 되었다. 앞으로도 시간이 날 때 마다 관심있는 기술을 개요 정도만 파악해두는 것도 꽤 괜찮은 방법인 것 같다.
스터디에서 스터디하자
위에 적은 내용의 연장선 상에 있는 내용이다.
최종 프로젝트에서 피그마를 편리하게 사용하기 위해 2차팀 팀원들과 피그마 스터디를 함께 들었다. 왕초보 반이라 대단한 걸 배워오진 않았지만 거기서 배운 내용을 바탕으로 툴을 다루다 보니 디자인할 때 확실히 편리했다👍
ui/ux 디자이너, 프론트엔드 개발자 뿐만 아니라 pm, 기획 총괄로 발령나신 50대 직장인 분들이 오셨다. 직장 들어가서도 주말에 시간 내어서 공부하시는 모습을 보고, 공부에는 끝이 없고 기왕 끝이 없다면 이런 스터디를 적극적으로 활용해서 재밌게 공부해야겠다는 생각이 들었다.
Problem
쫄보가 되어버린,,
전에는 새로운 걸 시도해보거나 변화를 마주할 때 오히려 좋아~의 태도를 취했는데 요즘에는 그 반대가 되었다. 이걸 할 수 있을까,일정 내에 소화할 수 있을까 하고 방어적으로 나오게 된다.
새로운 걸 많이 배우고 시도해봐야 하는 입장에서 좋은 태도는 아닌 것 같다.
취업 준비
2차 프로젝트를 시작하면서 바쁘다는 핑계로 코테 풀기, 포폴 정리를 미뤘다. 데브코스 수료까지 한 달 여 정도 남았기 때문에 하루 일정을 잘 안배해서 취준에도 신경을 써야겠다.
문서화
트러블 슈팅이나 새로 배운 내용에 대한 문서화를 자꾸 미루게 되는 부분이 아쉽다. 정해진 기한 내에 해야하는 일이 있다 보니 빨리 할 일부터 끝내야겠다는 조급함이 있어 바로바로 작성하기가 힘에 부친다.
학습에 대한 내용 뿐만 아니라 프론트엔드 회의 내용도 문서화가 필요하다. 안건에 대해 다시 회의하게 되거나 프로젝트가 끝나고 다시 볼 일이 생겼을 때 요긴하게 쓰일 것이다.
Try
열심히 하자
보수적인 태도로 나오는 것이 결국에는 실력에 대한 자신감이 없어서가 아닐까 싶다. 궁극적으로는 열심히 해서 실력을 쌓자!가 되겠지만 그 과정에서 성취감을 느끼고 자기 효능감을 높일 수 방법에 대해 고민을 해봐야겠다.
취업 준비
하루에 코테 30분/이력서 30분 총 1시간 정도 취준 타임을 가져야겠다.
기존에 써둔 이력서를 점검하고 채용공고를 매일 봐야겠다.
스켈레톤 문서화
바로 바로 작성하기가 시간적으로든 체력적으로든 어려움이 있어서 문서화 자체를 생략한 것이기 때문에 문제가 발생하거나 회의가 끝나고 대강 틀만 작성해놓은 뒤에 일이 끝나고 보강하는 식으로 진행해야겠다. 보강할 때도 문서화에 너무 많은 비용을 들이지 않도록 주의하자!
정량적인 일정 관리
팀에서 일정 산정에 대한 어려움이 있어 이슈 예상 해결 시간, 실제 해결 시간을 비교해보고 회고를 작성하여 일정 관리를 보다 더 정량적으로 할 수 있도록 Git Discussion에 데일리 로그 작성를 작성하기로 했다.
