어제는 생일이라는 그럴싸한 핑계로 퇴근을 서둘렀다. 공식적으로 끝나는 시각인 오후 9시 이전에 나와 본 건 처음인 것 같다. 일찍 나오려면 작업을 미리, 많이 해둬야 하니 잠이 쏟아지는 점심시간에도 낮잠을 안 자고 버텼다. 내 몫의 API 콜 절반 이상을 완료했다.
Day66 한 일
그래서 어제는 나름대로 쉬었지만 잠은 평소와 다를 바 없이 늦게 잤다. 여느 때처럼 아침에 힘겹게 컴퓨터 앞에 앉아서 비몽사몽 팀원들과의 아침 인사를 마치고, 또 다시 반쯤 자면서 꾸역꾸역 일을 해나갔다. 밤새 API 리스트에 크고 작은 변경사항들이 있어서 결국 어제 한 번씩 짚고 넘어갔던 것들도 다시 봐야 했다. 그래도 기본 틀은 변하지 않아서 시간이 많이 걸리진 않았지만, 했던 걸 다시 한다는 것은 어쨌거나 고역이다. 복습(?)을 빨리 끝내고 남은 기능들을 마저 구현하는 데 오늘 하루를 다 보냈고, 덕분에 내일은 조금이나마 여유로울 것 같다. 대충 한번 훑고 지나갔던 부분들을 들여다 볼 수 있는 시간이 주어질 듯하다.
지금까지는, 좋아요 기능처럼 클릭했을 때 새로고침 없이도 그때그때 생김새(?)가 변하면서 상태가 저장되어야 하는 기능은 나 혼자만의 힘으로는 구현하지 못했었다. 그런데 운이 좋은 건지, 오늘은 처음으로 아무것도 참고하지 않았는데도 북마크 기능을 완성할 수 있었다! 그렇지만 아직도, 북마크 추가한 이후에 같은 페이지에서 바로 새로고침을 하면 북마크가 해제되지는 않더라도 해제된 것처럼 표시되고 있다. 다른 페이지로 이동한 후 새로고침하고 나서 다시 돌아오면 서버에 저장된 상태 그대로지만, 북마크 추가한 후 그 자리에서 곧장 새로고침을 해버리면 서버의 데이터는 건드려지지 않는다 할지라도 겉보기엔 북마크가 해제된 것 같다. 이걸 어떻게 해결해야 할지 여러 번 코드를 들쑤시다가 결국 무한루프에도 빠져보고 난리가 났다. 다시 원래대로 돌려놓고 이건 내일의 나에게 맡겨야겠다.
내일 할 일
북마크랑 유사한, 좋아요 기능을 구현하면서 오늘 약간은 모자랐던 북마크 기능의 부족함을 채워보자.
데이터 불러올 때 서버에서 페이징 처리한 데이터를 적절히 운용해야 한다. 오늘은 급한 마음에 다 건너뛰었지만 내일은 꼼꼼히 챙겨보자.
그저께는 일요일이었다. 쉬는 날이었지만 으레 그렇듯이 저녁 먹고 느지막이 출석 도장을 찍었다. 게더에는 사람도 별로 없고 해서 게더를 꺼놓고 온전히 코딩만 할 수 있었다. 전날 계획했던 대로 피그마에 디자이너님들이 그려놓으신 대로 CSS 규격을 최대한 정확히 맞춰서 뷰를 구현하는 데 시간을 쏟았다. 피그마에서는 CSS 코드도 어느 정도 확인할 수 있었지만 그렇다고 해서 그대로 갖다 붙인다고 원하는 그림이 나오는 건 아니었다. 바닥부터는 아니더라도 손을 대지 않을 수는 없었다. 그렇게 시작한 CSS 작업은 해가 뜨고 아침 8시가 되어서까지 이어졌다... 잠을 하나도 안 자고 밤을 넘겨 본 게 얼마 만이었는지 모르겠다. 대학생 때도 술 마실 때 아니고서는 과제할 때조차 밤을 꼬박 새진 않았었는데, 세상에나.
Day64 한 일
밤을 새버린 탓에 오늘은 시간이 조금만 나면 부족한 잠을 보충하기 일쑤였다. 오전 11시부터 4시간 자고, 또 오후 6시부터 2시간 자고. 잠이 안 올 때 밤샘 작업을 하면 그때만큼은 온전히 조용하게 시간을 쓰면서 집중할 수 있다는 장점이 있지만, 다음날 부작용이 너무 큰 것 같다. 오늘 뭘 했는지도 기억이 잘 안 난다. (어쩌면 한 게 없는지도)
밤 12시가 되자마자 팀장님을 비롯한 우리 팀 분들이 갑자기(!!!) 모여들어서 생일 축하 노래를 틀고 🍰 이렇게 생긴 스냅카메라의 케이크 필터로 내 생일을 축하해주셨다. ㅋㅋㅋㅋ다시 생각하니 또 웃기다. 당황스럽기는 했는데 재밌고 고마웠다. 0시부터 비대면으로 축하받는 생일이라니 너무너무 특별하다.
내일 할 일
백엔드에서 오늘 거의 모든 기능이 다 들어 있는 API 리스트를 주셨다. 내일 그래두 생일이니까 밤에 조금이라도 쉬려면 낮잠 절대 자지 말고 열심히 다 해버려야지.
큰 교훈을 얻었다. 앞으로는 새로운 툴을 발견(사용)하게 되면 무조건 공식문서나 튜토리얼 문서부터 보고 시작해야지. 프로젝트 처음부터 한창 사용 중이던 Figma. 앗, 아니, 사용했다고 말하면 안될 것 같다. 우리는 별 생각 없었다. 그냥 우리의 프로젝트가 남의 눈에 어떻게 보일지가 유난히 오늘따라 조금 더 궁금했을 뿐. 마침 오시영 튜터님이 계셔서 아주 가볍게 여쭤봤다. 그리고 돌아온 건 1톤 트럭이었다. 디자인을 단순히 보여주기만 한다고 생각했던 피그마에는 감히 짐작하지 못했던 너무나 많은 기능들이 있었고, 나는 그걸 사용하기는커녕 그 존재를 상상조차 하지도 못했다. 충격적이었다. 오시영 튜터님은 나를 포함한 프론트 멤버들에게 늦어도 월요일까지는 시간을 들여서 피그마 튜토리얼을 보라고 말씀하셨다. 피그마의 최대 장점인 기능들을 아무것도 이용하지 않고 있었으니 사실상 피그마 자체가 나에겐 무용지물이었다. 튜토리얼을 훑어보면서 샘플로 주어진 와이어프레임에서 이것저것 건드려보았다. 피그마 안에서 실시간으로 다른 사람들의 커서를 볼 수 있는 건 알았지만 채팅까지 가능한 줄은 몰랐다. 이래서 협업 툴 만드는 프로젝트가 어렵다고 한 거구나. 기본적이면서도 핵심적인 기능들을 사용하지 못하다 보니 디자인 요소들을 이해하는 것도 당연히 불가능했고, 디자이너분들이 차근차근 쌓아올린 정보의 토대(이를테면 베이스 디바이스 사이즈라든지, 그리드 시스템이라든지...)들을 제대로 보고 지나갈 생각도 하지 않았었다. 지금이라도 늦지 않았으니 고쳐봐야지. 다시 CSS의 지옥문이 열릴 것 같다.
이외에도 웹 퍼블리셔가 아닌 프론트엔드 개발자라면 CSS와 기능 구현 외에도 최적화, 보안 같은 것들을 두루 신경 쓸 줄 알아야 한다는 것을 또 한번 배우고 깨달았다. 그런 면에서 크롬 개발자 도구를 적극적으로 활용하라는 조언도 들었다. 꼭 공부해야겠다.
오늘은 리뷰를 작성하는 페이지에서 별점을 입력하는 방식을 어떻게 구현할지 끙끙 앓느라 하루를 다 보냈다. 어제였나, 숫자를 입력하면 입력한 숫자에 따라서 하얀 별과 회색 별이 총 5개 이내에서 적절히 비율을 나누어 나타나는 컴포넌트를 직접 만들었었다. 이걸 만들고 나니 거꾸로 5개의 별 중 하나를 클릭하면 그것이 점수로 바뀌어 입력되는 것도 쉽겠다 싶어서 무작정 도전했다. 그런데 의외로, 그 별모양 아이콘 자체도 material UI에서 가져온 것이다 보니 적용하는 게 까다로웠다. 결국 별점을 입력할 때 쓰는 react-star-rating-component 라이브러리를 찾았다. 깃허브에서는 전부 클래스형 컴포넌트로 설명하고 있어서 함수형으로 바꾸는 데도 애를 좀 먹었다. 코드를 약간 바꿔서 거의 비슷하게 구현했다고 생각해도 막상 돌려보면 별점이 0이나 undefined로 찍히기 일쑤였다. 결국 star-rating-component에 onChange를 먹여서 돌려보니 제대로 나오더라. 역시 쉬운 길 두고 멀리 돌아가면 못써.
별점 구현을 완성한 후에는 리뷰를 서버에 저장하는 API 테스트를 시도했다. 서버에 보내는 것까지는 어려운 일이 아니어서 시간이 많이 걸리지는 않았다. 다소 후련한 마음으로 서버의 응답 데이터를 콘솔에 찍어보는 순간, 이 API가 완성본이 아니라는 것을 깨닫고 다시 손을 놓았다. 너무 자주 만나는 { isCreated: true } .... 우리 그만 좀 보자.
내일 할 일
문제를 인식했을 때 바로 해결해야 한다. 내일 쉬는 날이지만 조금만 쉬고 피그마대로 CSS를 고친다. 디자이너님들의 숭고한 노력을 결코 무시 말자ㅠㅠ
말 그대로 간신히, 팀장님 주간 면담 참석 전에 2차 배포에 성공했다. 기능도 제대로 붙어 있는 게 별로 없는 프로덕트였지만 그래도 좋은 게 좋은 거라고 생각하자..
그래도 오늘은 어제보다 건강해진 서버가 잘 버텨주어서 큰 문제 없이 API 테스팅이 가능했다. 하지만 API 리스트 홍수 속에서 길을 잃은 나는 뭐부터 테스트해야 할지 모를 지경에 이르고야 말았다. 천천히 하나씩 테스트를 하고 있다. (아직도..)
텍스트 정렬이나 배경색이 적용되는 높이 같은 소소한 CSS를 수정하고, 사이트 로고 클릭 시 메인으로 이동하게 하고, 내가 맡은 게시판 안에서 탭 간 이동에 대한 라우팅을 처리하고, 이 게시판의 정보들을 처리할 수 있는 리덕스 모듈을 새로 짜고, API 테스트를 하면서 하나씩 적용하고, 필요한 곳에 페이지네이션을 넣고, 다른 사람이 보기에 다소 난해할 수 있는 코드에 주석을 달았다.
거짓말처럼 뭘 좀 본격적으로 해보려고 하면 서버가 터져버리고 말았다ㅠㅠ어제는 정말로 하루종일 한 게 거의 없었다. 서버가 없어도 할 수 있는 뷰 수정 정도? 그나마 디자이너분들이 세세한 부분까지 신경쓰고 계셔서 실시간으로 변화하는 디자인에 맞춰서 해야 하는 일들이 꽤 있었다.
Day60 한 일
벌써 60일차라니 말도 안 된다. 이제 1개월 남짓 남았다는 얘긴데... 프로젝트 진행 속도가 더뎌지니 그만큼 걱정이 쌓여간다. 잠을 줄여가며 바쁘게 자료를 찾아보고 에러 띄워서 해결해도 모자란데. 며칠간 서버가 연약했던 차에 작업이 거의 올스톱 상태였어서, 오늘은 서버가 비교적 잘 돌아가는 데 비해 머리가 돌아가지 않아 또 속도가 안 났다ㅠㅠ...
어제 오늘 API 리스트의 길이가 급격히 길어지고 있어 질문글과 이미지에 대한 리덕스 모듈을 짰다. 이미지는 게시글을 작성할 때 파일을 첨부할 수 있는데, 파일을 선택하자마자 미리보기를 띄워주는 것까지는 큰 문제가 없었는데 막상 서버에 업로드하는 부분에서 막혀서 시간이 좀 걸렸다. 한창 작업할 때는 몰랐는데, 잠깐 놓고 돌아섰을 때 생각해 보니 서버에 업로드를 정상적으로 하더라도 API가 준비되어 있지 않아 정작 게시글을 불러올 때 업로드한 이미지를 함께 가져올 수 없는 상황이었다. 그러다 보니 또 완결하지 못한 채로 다음으로 넘어가 버렸다.
내가 맡은 게시판의 페이지네이션을 해보았다. 예전에는 지금보다 더 간단한 형태의 페이지네이션을 했었는데, 그때 적어뒀던 스켈레톤 코드를 응용해서 좀 더 복잡시럽게 만들어 보았다. 세련되지 못한, 너무나 원시적인 코드라 또 어떤 문제가 있을지는 두고 봐야 알 것 같다. 그래도 기능을 혼자 구현해봤다는 것 자체가 의미 있는 걸까.
그리고 2차 배포를 앞두고 한창 작업을 하고 있는데 또 다시 서버에 문제가 생겨버렸다. 어제까지의 문제만큼 심각한 건 아니라는 것 같은데, 사실 프론트 입장에선 결과적으로 크게 다른 건 없는 듯하다. 어쨌든 또 다시 올스톱 상태가 되어버렸다.
내일 할 일
서버가 잘 돌아가는 것만 얼른 확인한 후, 다른 프론트 팀원분이 하신 로그인 유지 기능이 정상 작동하는지만 보고 2차 배포를 한다. 지난 1차 배포에 비해서 디자인적으로는 많은 게 변했지만 기능은 거의 붙어 있지 않은 상태라 영 마음이 편치 않다.
오전에는 우리 조 팀장님과 디자이너분들과 함께 의견 조율의 시간을 가졌다. 서로가 생각하는 데드라인이 어느 한쪽에는 너무 촉박하고, 또 다른 한쪽에는 너무 널널한 상황이었다. 작업할 거리가 없어 시간만 때우고 있는 프론트의 입장으로서는 꼭 필요한 자리였다. 우리 입장에서는 100%까지는 아니어도 원하는 것들을 충분히 얻어낼 수 있었다고 생각했다.
디자이너분들은, 어떤 사항들은 팀 내에서 결정된 바가 없어서 디자인 작업에 바로 착수하기가 어렵다고 하셨다. 그래서 점심 식사 직후부터 프론트끼리 지금까지 어떤 것들이 결정되지 않았는지 정리했다. 그러고 나서 백엔드에서 API 2차 작업이 끝난 후 우리가 정리한 내용을 가지고 수많은 결정들이 난무하는(ㅋㅋ) 회의를 진행했다. 그리고 다시 이 내용을 정리해서, 와이어프레임에 대한 프론트의 요청사항들과 함께 디자이너분들께 전달했다.
원하는 것을 글로 적는다는 건 생각보다 어려운 작업인 것 같다. 고치고 또 고치기를 여러 번, 그러고 나니 시간이 훌쩍 지났다. 연락을 마치고 나서 드디어 수정된 API를 다같이 테스트해보며 작업합시다, 하고 얼마 지나지 않아 서버에 뭔가 문제가 생긴 듯 보였다. 몇 초 전에만 해도 새로고침을 하면 컴포넌트 렌더링과 동시에 멀쩡히 로드되던 데이터들이 어느 순간 다시 새로고침하자 온데간데 없이 사라져버렸다. 컴포넌트에는 당연히 구멍이 뻥뻥 뚫렸다. 테스트용 데이터가 하나밖에 안 들어 있었던 상황이라, 프론트에서 삭제 버튼을 잘못 눌러서 없어진 게 아닌가 의심을 했었다. 하지만 셋 중 누구도 삭제 버튼에는 아무 기능도 달아놓지 않은 상태였다..!!(호러..?) 묻고 물은 끝에 AWS 인스턴스 자체의 문제인 것 같다는 얘기를 들었고, 아무도 예상치 못한 사태에 또 다시 길을 잃고 말았다..ㅠㅠ
엎친 데 덮친 격으로, 디자이너분들과 우리가 서로의 상황을 전혀 이해하지 못할 수밖에 없었던 이유를 알게 되었다. 디자이너분들은 우리가 이렇게까지 주6일 풀타임으로 모든 시간을 쏟아붓는 작업을 한다는 걸 모른 채로, 우리는 그분들이 현업에 계시며 오로지 포트폴리오만을 바라고 무보수로 참여하신다는 걸 모른 채로 진행했던 것이었다. 우리의 요구사항에 맞추기 위해 퇴근 후에 밤을 새며 작업하셨다는 걸 뒤늦게 듣고 나서 죄송하고 마음이 쓰렸다. 진작 알았다면 이렇게까지 서로 힘들지는 않았으리라. 아무리 이게 실전 프로젝트이고 협업하는 과정 자체가 중요하다고 하더라도 중간자 역할을 하는 항해 측에서 충분히 사전 고지를 해야 하지 않았나 싶다.
내일 할 일
서버가 복구된다면, 최대한 빠르게 많은 API를 테스트해보고 백엔드분들께 피드백을 드린다.
항상 남은 일이 많아 허덕이던 나에게 오늘 같은 상황은 낯설기 그지없었다. 피그마에서 본 디자이너분들의 와이어프레임도 금요일 이후 전혀 변화가 없었고, 그새 우리는 지금까지 나온 부분에 대한 뷰 작업을 모두 완료했다. 뷰에 관해서 할 수 있는 일은 이제 와이어프레임에서 실수로 누락된 버튼 같은 작은 요소들을 일단 적당히 임시로 끼워넣거나, 사소하게 어긋나거나 신경쓰이는 곳들을 수정하는 것뿐이었다(통일성을 갖추는 것은 나중으로 잠시 미루기로..). 리덕스는 지난번 변경 전의 와이어프레임에 붙여보느라 모듈을 미리 짜놨기 때문에, 게시판 종류별로 CRUD API가 있었다면 각 게시판 뷰에 맞게 API 콜을 해봤을 텐데 그것도 상황이 여의치 않았다. 본의 아니게 한가로웠다.
현재의 와이어프레임에 맞춰 내가 맡은 두 게시판의 뷰를 마저 조정하고, 누락된 글쓰기/수정/삭제 버튼을 적당히 붙여놓고, 클릭하면 메뉴 리스트가 나오는 형태를 포함하여 헤더를 분기시켰다.
주말이라는 걸 몸은 알고 있는 걸까? 금요일인 어제까지만 해도 이 정도는 아니었는데 오늘따라 왜 이렇게 힘이 쭉쭉 빠지고 아무것도 하기 싫은지 모르겠다. 프론트 팀원분들의 배려로 낮잠도 엄청 잤다. 슬슬 전격적으로 밤낮이 바뀌고 있는 것 같다.
오늘 뭘 했는지는 이제 깃허브 저장소 커밋 내역을 보면서 쓰는 게 빠르다. 오늘도 하루종일(이라고 말할 수 있나.. 거의 안 하고 쉬었는데) 뷰 작업만 했다. 와이어프레임이 바뀐 이후로 프론트 한 분의 컴퓨터에서만 유독 뷰가 다르게 보인다고 하셔서 그걸 해결한답시고 템플릿 파일을 하나 만들었다. 정말 신기한 건, 템플릿 코드를 붙여넣고 진행하니 뷰가 멀쩡해졌다고 하셨다. 진짜 원인 무엇이지..