[Portfolly] 스프린트 3주차 회고

마지막 개발 주간이 끝났습니다.

 

포트폴리오 조회/등록 관련 주요 기능은 구현되었지만 아직 100%라고 딱 잘라 말할 수 없어 불안한 마음이 큽니다.

 

계획했던 의뢰 요청 기능은 데모데이 이후 백엔드 팀원분과 별도로 추가 개발을 하기로 했고,

디테일한 프론트 성능 개선 리펙토링은 배포 후 정확하게 측정해보려 합니다.

 

당장 이번주에는 서버 통신 테스트를 했어야 하는데 계획에 차질이 생겨 이것저것 다른 디테일한 부분들을 개선하는 것에 집중하게 되었습니다.

 

1. 나의 약점은 무엇인가

 

1) 코드를 어느 범위까지 분리해야 하는지 기준을 잡지 못 합니다.

 

당장 지난주만 해도 '코드를 잘 분리한다'라고 자만해놓고 이번주에 다시 자신감이 누그러들었습니다.

 

함수를 어디까지, 무슨 기준으로 분리해야 하는지 갈팡질팡하는 제 모습을 보며 아직 한참 부족하구나라는 걸 다시금 깨달았습니다.

 

TitleForm.tsx 컴포넌트 파일이 너무 복잡해서, TitleForm.tsx에서 굳이 신경 쓸 필요 없는 함수를 훅으로 분리하라는 멘토님의 조언을 얻었습니다. 그런데 당장 TitleForm의 코드는 줄었으나 useTitleForm의 코드가 복잡해졌습니다.

 

무한 굴레였습니다... 물론 지금은 멘토님의 코드 리뷰를 통해 해결책을 찾게 되었지만 그 과정에서 깨달은 바가 있었습니다. 지금껏 분명한 기준도 없이 그저 쪼개는 것에만 초점을 둔 것입니다.

 

해당 파일에서 무엇이 중요한지, 무엇을 알 필요가 없는지 기준을 세우고 분리하는 법을 터득해야겠습니다.

 

2) 큰 기능을 구현하느라 디테일한 중요 사항을 놓치곤 합니다.

 

사실 기획 단계에서 문서화를 제대로 안 해서 까먹고 놓친 부분들이 많습니다.

 

구현을 막 시작할 땐 전혀 모르고 있었는데 큰 틀이 잡히고 나니까 이것도 부족하고 저것도 빠트렸고 다양한 허점들이 눈에 들어왔습니다.

 

에러 처리도 제대로 꼼꼼하게 구현하지 못했고,

유효성 검증도 백엔드 팀원과 회의해서 에러 메세지에 대해 더 자세하게 정했어야 하는데

백엔드, 프론트가 각자 따로 노는 느낌이 되었습니다.

 

데모데이가 끝나고도 계속해서 리펙토링을 할 예정이니 그때 다시 회의 해야겠습니다.

 

2. 나의 강점은 무엇인가

 

다른 팀원의 코드를 보고 배울 점을 골라 찾아낸 다음 제 것으로 만들고자 합니다.

 

제 코드만 바라보고 있으면 스스로 개선사항을 찾기가 어렵습니다.

그냥 뭐가 잘못된지도 모르는 바보 상태...

 

그래서 종종 다른 팀원들의 코드를 주기적으로 찾아보는 걸 좋아하는데, 그런 과정에서 배울 점이 있으면 제 코드에도 곧바로 적용해 보곤 합니다.

 

이번주는 Category 타입을 관리하는 측면에서 다른 팀원의 Object Mapping 방식을 보고 따라 해보았습니다.

 

Category 타입은 "웹" | "앱" | "사진/영상" 이런 식의 한글 문자열 유니온 방식이었는데,

서버에 전달할 때는 "web" | "app" 이렇게 영어여야 했습니다.

 

한글로 타입을 정의했을 땐 카테고리 메뉴 버튼, 카테고리 드롭다운에 들어가는 글자들을 편하게 정의할 수 있었는데, 영어↔한글 매핑이 필요해졌습니다.

 

이 부분을 어떻게 깔끔하게 만들어볼까 하다가, Object Mapping 코드를 보고 그대로 따라 적용해 봤습니다.

 

결과도 마음에 들었고, 이런 식으로 다른 팀원의 좋은 코드를 따라 함으로써 전체적인 코드 스타일도 비슷해지는 것 같았습니다.

 

3. 나의 팀워크 방식은 어떠한가

 

함께 했을 때 더 빠르고 정확한 일은 무조건 같이 빠르게 해결합니다.

 

서버 API 통신 테스트를 시작해야 하는데 API 명세서가 불명확했습니다.

 

'프론트에서 테스트 -> 문제 발생 -> 해당 문제를 백엔드 팀원에게 전달' 이런 방식으로 테스트를 했다간 며칠이 걸려도 다 못 하겠다는 생각이 들어 제가 맡은 부분을 담당한 백엔드 팀원과 밤에 시간을 잡고 모든 통신 테스트를 동시에 같이 진행했습니다.

 

역시 서로 잘못 알고 있던 타입, key들이 많았고 그 자리에서 발견하는 즉시 수정해 가며 에러를 처리했습니다. 그렇게 끊임없이 서로의 상태를 보고하며 테스트를 했더니 (피곤했으나) 3시간 정도 만에 문제가 거의 해결되었습니다.

 

그리고 그 이후로는 별다른 통신 에러가 발생하지 않았고, 발생하더라도 프론트와 백의 불일치로 인한 문제는 없었습니다.

 

긴 시간을 계속해서 마주 보듯 대화하며 테스트하는 게 쉬운 일은 아니지만, 피곤해도 끝까지 함께 하려는 마음이 백엔드 팀원과 저 모두 충실했기 때문에 오히려 힘이 되었습니다. 따로 작업하고 그때그때 에러만 보고했다면 분명 발생했을 문제들이 더 이상 나타나지 않아서 편안했습니다.

 

4. 나의 열정은 어떤 방식으로 표출되는가

 

개발을 하면서 기록하고 싶은 순간들이 많아졌습니다.

 

과거에는 대체 무엇을 블로깅 해야 할까, 어떤 글이 있어 보일까(?) 따위의 고민들을 하곤 했습니다.

 

그 당시에는 개발에 대한 열정이 지금만큼 가득하지도 않고, 진짜 깨달음이 무엇인지에 대해 깊게 생각해보지 않아 그랬던 것 같습니다. 코드 한 줄이라도 진심으로 이해하고 작성하려 했더니 모든 순간들에 기록이 필요해졌습니다.

 

이 과정을 절대 잊지 말아야 할 것 같고, 나중에 보면 '와 이것도 몰랐단 말이야?'라는 생각이 들지언정 그런 바보 같은 과정들도 기록한 뒤 반성하고 싶을 만큼 진실되고 싶어 졌습니다.

 

확실히 개발에 대한 태도가 이렇게 변하고부터 블로그 글도 많아지고, 블로깅 자체에 큰 재미를 느끼고 있습니다. 이전보다 제대로 공부하려는 마음가짐이 잡힌 것 같아 뿌듯하고 정말 즐기면서 개발하는 게 무엇인지 점점 깨닫고 있습니다.

 

5. 나의 근면성실을 어떻게 설명할 수 있는가

 

백로그

백로그에 작성한 기술들을 점검하고 현재 상황을 계속 파악했습니다.

 

혹시 구현을 하다가 놓친 부분은 없는지, 부족한 점은 없는지 백로그를 확인하며 계속 검토하였습니다.

 

구현한 부분에 대해서는 노란색으로 글자를 채우면서 점차 기능이 구축되고 있다는 걸 확인했습니다.

 

또한 추가되어야 할 부분들에 대해서 끊임없이 고민하면서 새롭게 작성하고, 또 그 부분을 해결하길 반복했습니다.

 

사실 처음부터 백로그를 작성하고 구현에 돌입한 건 아니었습니다.

프로젝트 초기 단계에 백로그를 작성하자는 의견이 기각.. 되어서 아무런 문서 없이 그냥 머릿속에 그려지는 기능들을 추상적으로 구현했습니다.

 

그렇게 하다 보니 역시나 하나둘 빠트리는 부분들이 많았고 제대로 바로 잡을 필요가 있겠다 싶어 혼자라도 다시금 기술을 정리했습니다.

 

그리고 하나둘 체크해 나가며 구현을 했더니 훨씬 기능이 뚜렷해지고 사용자 흐름도 깔끔하게 정리되었습니다.

 

6. 나는 왜 업무를 즐기는가

 

같은 로직의 코드를 다양하게 표현할 수 있고, 그중에서도 최고의 방법을 골라내는 과정이 재밌습니다.

 

useTitleForm 훅은 작성한 포트폴리오에 대한 submit 함수를 반환합니다.

 

그런데 포트폴리오를 POST 하기 전에 후처리가 조금 복잡했습니다.

 

portfolio 객체에서 서버에 보낼 필요 없는 두 개의 키를 제거해야 했고,

htmlContent에 들어가는 큰따옴표를 작은따옴표로 바꿔야 하고,

'수정'을 한 경우 기존 portfolioId 페이지로 이동해야 하고,

새 포트폴리오를 작성한 경우 response로 portfolioId를 받아 페이지를 라우팅 해야 했습니다.

 

그 모든 게 submit 함수에 들어가 있던 겁니다.

 

작성한 함수를 바라보며 이게 최선이 아니라는 걸 알면서도 도대체 어찌할 바를 모르고 있었습니다.

 

함수는 다섯 줄 이상 작성하지 말라는 규칙(?)을 깡그리 무시하고... 멘토님이 else문은 잘 쓰지 말랬는데 이런 경우는 어떻게 해야 하지 멘붕이 오고...

 

결국 멘토님께서 직접 가르쳐주셨는데 정말 머리를 한 대 맞은 것 같았습니다. 제 자신이 바보라는 걸 들켜서 창피한 것보다 지금이라도 깨닫게 된 것에 느끼는 기쁨이 더 클 정도... 차라리 더더더 바보스러움을 보여주고 새로운 걸 많이 배우고 싶었습니다.

 

이 복잡하고 둔해빠진 코드를 어떻게 이렇게 바꿀 수 있을까 큰 충격을 받았고,

마음먹고 고민한다면 이런 방법들이 수십 가지는 더 다양한 버전으로 존재할 것입니다.

그런 생각을 하면 빨리 더 공부하고 싶어지는 걸 봐선 확실히 발전하는 재미로 업무를 즐기나봅니다.

 

7. 내 능력 중, 내가 구직하고자 하는 회사가 기대하는 것 이상의 능력이 무엇인가

 

매번 느끼지만 너무 어려운 질문 같습니다. "내 능력"이 불분명한 게 가장 큰 문제 같습니다.

 

과연 기대하는 것 이상의 능력이라고 자신 있게 말할 수 있는 걸까 의문이 듭니다.

 

이번주 동안 깨달은 '내 능력'은 기본적인 것에 가까워서 기대 이상이라고 자부하기엔 힘든 것 같습니다.

조금 더 고민이 필요할 것 같습니다. 슬프네요...

 

8. 내가 신뢰할만한 사람인 걸 어떻게 설명할 수 있는가

 

Lighthouse를 분석하여 수치를 증명하고 개선하려고 합니다.

 

지난주 멘토님께 신뢰는 곧 수치로 증명되어야 한다는 말을 듣고 곰곰이 생각해 보았습니다.

 

내 코드에 신뢰를 줄만한 수치란 무엇이 있을까? 당장 생각나는 건 Lighthouse 분석이었습니다.

 

곧바로 제가 담당한 페이지를 검사하여 수치를 확인하고 분석 작업에 들어갔습니다.

비록 지금 당장 성능 개선을 한 부분은 없지만 이렇게 구체적이고 명백한 방식으로 코드를 증명할 방법을 찾은 것 자체는 시도가 좋았다고 생각합니다.

 

어서 다음 주 동안 코드를 리펙토링 하고 성능 개선을 경험하면 좋겠습니다.

 

9. 내가 체계적인 사람이란 걸 어떻게 증명할 수 있는가

 

브라우저의 동작, 코드의 동작을 꼼꼼하게 살펴봅니다.

 

이번주에는 로고 버튼을 클릭했을 때 '정말 나가시겠습니까?'라는 popstate 이벤트 알림 창을 오픈하는 기능을 구현하였습니다.

 

여러 기술 블로그를 참고한 결과 popstate 이벤트를 등록한 뒤 언마운트 되면 제거해야 한다는 걸 알았습니다.

 

언마운트 시 이벤트를 삭제하는 코드를 한 줄 작성했지만 저는 그 동작 과정을 직접 확인하고 싶었습니다.

 

이벤트가 어디에 저장되고, 삭제되는지 확인하기 위해 브라우저 콘솔창에 getEventListner(window)를 실행하였습니다.

 

그런데 콘솔창에 확인해보지 않았더라면 전혀 몰랐을 문제를 발견했습니다.

 

언마운트가 발생하고도 이벤트가 삭제되지 않은 것입니다. alert는 정상적으로 작동하지만 그 부분에서 예상한 대로 코드가 작동하지 않음을 발견했기 때문에 또 해결해야 할 새로운 문제가 추가되었습니다.

 

이 과정을 통해 아주 단순한 코드라도 제대로 작동되는 게 맞는지 그 흐름을 잡아 출력해 봐야겠다는 다짐이 생겼고, 지금껏 체계적이란 건 무엇일까 고민이 많았는데 이런 사소한 부분에서도 체계성이 드러날 수 있다는 걸 깨달았습니다.

 

10. 내가 고객중심으로 사고하는지 어떻게 설명할 수 있는가

 

스켈레톤 UI를 도입할 계획입니다.

 

포트폴리오 상세 페이지의 경우 이미지가 뜨지 않아도 포트폴리오 영역 Box가 줄어들거나 화면에 보이지 않는 게 아니기 때문에, 따로 추가 작업은 필요 없다고 생각했습니다.

 

이미지가 나타나지 않았을 때 컴포넌트 밀림 현상만 없으면 된다고 생각했습니다.

 

그런데 이번주 유튜브 영상 임베드 기능을 추가하고 나서 문제를 발견했습니다. 유튜브 썸네일이 고화질 이미지 로딩보다 더 느리다는 걸 알게 되었습니다.

 

만약 유튜브 영상 아래 글/이미지 내용이 들어간 경우 글과 이미지는 벌써 나타났는데 영상이 출력되어야 하는 부분만 몇 초간 커다랗게 뻥 뚫려있었습니다.

 

그게 너무 보기 안 좋다는 생각이 들었고, 유튜브 영상이 나오기까지 보여줄 스켈레톤 UI가 필요하겠다는 생각이 들었습니다.

 

다만 htmlContent의 iframe 태그로 불러와지는 영상을 어떻게 그 부분만 인식하고 스켈레톤 UI를 보여줄지 고민할 필요가 있어 당장 적용을 성공하진 못 했습니다.

 

11. 내가 다른 팀원과 다르다면 어디가 다른가

 

똑같은 코드라도 또 보고 또 보며 개선하고자 합니다.

 

코드 자체에 뭔가 추가된 부분이 없더라도, 같은 코드를 보고 또 보면 어찌 됐건 새로운 문제가 눈에 띄기 마련이라고 생각하기 때문에 계속해서 검토하는 주의입니다.

 

그래서 멘토님께도 다시 한번 리뷰를 부탁드리고 개선하기를 반복했습니다.

 

분명 지난주 멘토링 때와 크게 달라진 게 없는 코드지만 며칠 뒤에 다시 보면 또 고칠 부분들이 많았고 분명히 더 개선된 결과를 얻을 수 있었습니다.

 

12. 내가 한 모든 업무를 나열해 보시오

 

1. TitleForm 중간 저장

2. 에디터 화면에서 로고 클릭 시 브라우저 경고 alert 오픈

3. 에디터 다중 이미지 업로드, 이미지 삭제, 유튜브 동영상 임베드

4. 전체적인 코드 정리 및 서버 통신 테스트