📚금주 학습 내용

지난 TIL 임시 글을 다 작성하긴 했는데, 이번 주말에는 딱히 특징적인 내용이 없기도 하고, 그냥 퉁쳐서 WIL으로 쓰려고 한다. 아무래도 TIL은 밀리면 공수가 꽤 되다보니 유동적으로 쓰는 경험도 가져야할 것 같아서 이렇게 처음 WIL을 써본다.

🗓️지나왔던 일 간단하게 복기

1/9 화요일 - 페어코딩 & 깃허브 아팠던 날

1/10 수요일 - 페어코딩

1/11 목요일 - 페어코딩 & v1.0.0 배포 & 커피챗

1/12 금요일 - 리팩토링 & 디자인 다듬기

1/13 토요일 - 휴식 & 리팩토링 & 디자인 다듬기

1/14 일요일 - 리팩토링 & 문서 정리 & 디자인 다듬기

1/15 월요일 - v1.1.1 마이너 버전 배포 & 발표 준비

지난 한 주간 했던 일은 다음과 같다. 전형적인 프로젝트 마무리 수순인 것 같고, 나름 빠르게 개발을 시작한 덕분인지 여유가 생겼다. 코드적인 부분 역시 중요하지만 기능과 디자인이 더 우선이라고 판단해서 간단한 리렌더링 1,2개 정도는 가볍게 무시하고 배포 가능한 동작과 디자인에 조금 더 신경썼다. 아마 프로젝트는 지금부터 진짜 시작일 것 같은데 이제 내부코드를 뜯어 고쳐야 한다. 단, 지금 동작을 유지하면서

✏️특징적인 내용

🤝페어코딩

내가 모르는 건 동료가, 동료가 모르는 건 내가

데브코스에서 개발을 하며 느끼는 것은 돋보이게 잘하는 몇 분을 제외하고는 실력이 비슷비슷한 것 같다는 것이다. 특정 기능을 개발 하는데에 약간 시간은 걸리지만 결국 기능을 구현하고 잘 사용하는 정도...? 일단 내가 그렇고, 우리 팀에서 CTO님을 제외하고는 나랑 비슷한 것 같다고 생각했다. 만약 아니라면 죄송합니다..

어쨌든 그런 상황에서 이전 팀에서 했었던, 그리고 학교에서 배웠었던 애자일 개발 방법론 중 하나인 페어 코딩을 직접 해보려고 했다. 정말 다행히도 내가 맡은 부분의 개발이 예정보다 크게 뒤처지지 않아 일차적인 기능 동작이 가능한 상태로 PR을 날렸다. 그리고 나서 내 눈에 띈 것은 남은 일정과 기능 개발 목록이였다. 일정은 한 1주일 조금 넘게 남았는데..? 우리 팀은 그 상태에서 핵심 기능 몇 가지만 남은 상태였다. 심지어 대부분 이미 개발이 중간 정도 진행된 상황이여서 일정상의 문제점은 크게 없을 것이라고 판단했다.

그럼에도 페어코딩을 제안하고 진행한 이유는 다음과 같다.

• 빠르게 개발을 마치고 배포를 할 수 있다.(시간 단축)
• 연관된 기능 혹은 로직을 비슷하게 가져갈 수 있다.
• 서로의 기능을 연동, 병합하는 데에 이해도가 엄청나게 높아질 수 있다.
• 서로 배우며 코딩을 진행할 수 있다.
• 팀장이니까..!

사실 아마 팀원이였어도 제안은 해봤을 것 같다. 다른 팀에서 페어코딩하는 분들이 있는데 효과가 좋다는 말을 몇 번 들었기도 하고..ㅎㅎ 그치만 결국 궁극적으로 이번에 내가 페어코딩을 제안한 이유는 위 이유들과 더불어 팀장 + 내 코드 뿐만 아니라 팀 전반적인 코드, 기능에 대한 흐름 이해하기라는 목표가 있었기 때문이다.
그렇게 시작된 페어코딩은 우리에게 엄청나게 빠른 개발 시간 단축을 할 수 있게 해주었고 나에게는 개발 이해도를 높일 수 있는 시간이 되었다.

⏰일단 시간 단축이 엄청났다.

월요일(1/8)에 팀원들에게 저는 목요일에 배포하고 멘토님 보여드리고 싶어요라고 얘기를 했을 때 반응이 그게 될까요..? 였다. 아무래도 팀원들의 입장에서는 쉽지 않은 일정이기는 했을 것이다. 개발이 어느정도 진행되었다하더라도, 프로필, 세부 포스팅 페이지와 같은 신경써야할 것이 많은 로직이 많았고, 그리고 CTO님이 맡으신 채팅과 알림 역시 쉬운 구간은 절대 아니였다.

그럼에도 불구하고 화요일에 세부 포스팅 페이지를 끝냈다. 월요일은 민호님이랑 오후 3시부터 새벽 1시까지 쉬지 않고 코딩을 했던 것 같은데,, 결국 완료했다. 프로필 페이지 역시 수요일 하루종일, 목요일 코어타임을 통해서 수영님이랑 코딩을 진행했고 중간에 CTO 원주님이 도와주셔서 더 빠르게 끝낼 수 있었다. 그리고 그 기간동안 나 역시 내 코드에 대한 개발, 리팩토링도 동시에 진행하였고 원주님 역시 맡으신 기능을 다 구현해오셨다.

그렇게 목요일 코어타임 이후 일부 자잘한 기능을 수정하고 v1.0.0 을 릴리즈 할 수 있었다. 그리고 역시나역시나 당일 19시에 있었던 커피챗에서 멘토님이 사용을 해보고 오셨고 사용 경험에 대한 이야기를 해주셔서 피드백을 받아 고칠 부분을 생각해볼 수 있었다. 그리고 우리도 막상 초기 릴리즈를 해보니, 마주한 문제점이 정말 많았는데 금토일 3일간 피드백 요소들과 일부 오류가 있는 기능들을 고칠 수 있는 귀중한 시간을 벌 수 있었다.

그렇게 오늘 월요일에는 결국 다들 만족스러운 수정사항을 반영할 수 있었고 꽤 만족스러운 v1.1.1 버전을 릴리즈할 수 있었다.

📄개발 이해도 상승

개인적으로는 개발 이해도가 꽤 상승했다. 일단 타인의 코드를 읽고 해석하는 흐름이 기존보다 더 빠르고 효율적이라고 느껴지고 있고, 어떤 생각을 하며 코드가 작성되었는지, 어떤 부분이 고려되지 않았는지가 보이기 시작했다...! 그래서 페어코딩을 하면서 나름 도움을 드릴 수 있었던 것 같다. 몰랐던 부분에 대해서도 많이 알 수 있었다. 디자인적인 요소는 항상 나의 단점인데 그런 면에서 코드를 많이 참조할 수 있었고, 내가 잘 사용하지 않는 코드들이나 공통 컴포넌트 사용법을 잘 익혀서 나의 기능을 리팩토링할 때 꽤 많은 도움이 되었다.

개발한 기능을 합칠때도 굉장히 도움이 되었는데, 내가 로직을 어느정도 이해하고 있으니 급하게 발생한 문제점이나 기능 연동에서 발생한 문제점을 꽤 빠르게 캐치할 수 있었다.

💉깃허브도 아프구나

아프지마라...

정상적인 순서로 PR을 머지하고 사용하던 중 갑자기 500에러가 뿜어져나오고 dev브랜치의 코드들이 꼬여버렸다. 이후 위 상태가 더 심각해졌는데 깃허브 이용자 중 1~5%가 겪을 수 있는 문제라고 리포트가 올라왔다. 깃허브도 아플 수 있구나라는 생각도 들었고, 이후에 계속 꼬여버린 코드를 코치느라 고생했다. 나는 나중에 사이트 에러를 최소화하는 개발자가 되어서 사용자의 불편함을 줄여줘야지...

❗Vercel 배포 에러

여기도 케찹이... 배포할 때 선언되었지만 사용되지 않는 코드에 대한 내용을 에러로 감지한다. 이게 Vite의 설정인지 아니면 vercel의 설정인지는 모르겠는데 좋은 것 같기도 하고 아닌 것 같기도 하다,, 추후에 설정을 조금 더 자세히 알아볼 필요가 있을 것 같다.

☕커피챗

이번 커피챗은 중간회고에 대한 피드백과 우리의 v1.0.0 버전에 대한 멘토님의 리뷰가 있었다.

일단 개인적인 측면에서 보면 나의 KPT회고에서 Keep에 대한 내용은 좋은 방향이였다. 그리고 내가 생각했던 문제점들에 대한 내용도 처음 팀장을 맡았다면 고민할 법한 내용이라고 하셨다. 다만 2번째 고민에서 개발은 천천히 튜토리얼 보고 짜라, 왜와 컨셉에 집중하라 라는 조언을 해주셨다. 어차피 공식문서를 정독하고 코드를 작성하나, 그냥 구글링으로 짜집기해서 작성하나 시간은 비슷한데 코드의 퀄리티는 엄청나게 차이가 날 수 있다는 조언을 해주셨다.

그리고 우리의 첫 버전에서도 멘토님이 여러가지 더 좋은 사이트가 되려면 어떻게 바꾸면 좋을 지 의견을 내주셨다. 이 내용들을 바탕으로 추후 v1.1.1 마이너 패치를 통해서 많은 부분을 개선할 수 있었다.

❔이번에도 놓쳐버린 왜?

바쁘다 바빠

바쁘다 바빠라는 핑계였을까, 이번에도 DOCS를 정독하고 개발하는데에 실패했다. 개발은 빠르게 해야하지, 하지만 방법은 잘 안떠오르지,,, 그래도 리액트는 강의를 듣기도 했고 워낙 좋은 코드가 많아서 트리구조를 잘 짜지 못했다는 부분을 제외하고는 나름 괜찮다는 생각이 들긴 했다. 하지만 문제는 새로 접해본 tanstack-query(react-query)이다.

이번에 tanstack-query를 처음 사용해봤고 tanstack-query 안에 정말 많은 로직과 설정들이 있는데 아무래도 빠르게 개발하다보니 이 부분에서 올바른 방식으로 사용하지 못한 부분이 PR에서 몇 번 지적을 받았다. 아무래도 최우선적으로 리팩토링을 해야할 것 같다.

그 밖에도 근본적인 리액트 코드 구조라던지, 기타 여러 라이브러리 코드 사용법을 다시 한 번 슥 훑을 필요가 있을 것 같다.

🔁끝 없는 리팩토링 & 디자인 수정

아무래도 개발에는 정말 끝이 없는 것 같다. 더 좋은 UI, 더 좋은 UX, 더 완벽하고 효율적인 코드, 더 괜찮은 LightHouse 점수와 성능 등 프론트엔드 엔지니어가 고려해야 할 요소는 정말 너무 많은 것 같다. 그렇기에 리팩토링도, 디자인 수정도 끝 없이 이어지는데 우리 프로젝트도 그랬다.

일단 내가 얘기하고 나아갔던 방향은 내부적인 코드의 흐름보다는 디자인과 긴급한 로직에 대한 수정을 우선시하는 것이였다. 추후에 MIL에 언급할테지만 아무래도 프로젝트 기간도 짧은 편이였고 최종 발표를 위한 시연을 진행해야 했기 때문에 성능적인 부분을 고려하는 것도 필요했지만, 사이트 운용에 큰 문제가 없는 상황이였기에 디자인과 긴급한 hotfix에 조금 더 투자했다.

📖소회

WIL을 처음으로 써봤는데 오히려 더 좋은 것 같기도 하다. TIL의 경우 작성할 내용이 없으면 사담이 길어지는데, WIL은 핵심적인 내용을 더 골라쓰는 것 같기도..? 추후에도 프로젝트가 바쁘거나 시간 여유가 없으면 두 가지를 종종 병행해야겠다.
WIL 작성 소요 시간 약 1시간