D'story

오늘까지 한 일

• 이게 TIL인지 WIL인지 모르겠다...ㅋㅋ블로그 한 번 들어와 볼 시간 없을 정도로 정신없는 게 뭔지 이제는 알 것 같다. 오늘까지 뭘 했는지 다 적으려면 시간도 많이 걸릴 것 같고, 사실 머릿속이 뒤죽박죽이라 정리하기가 어렵다. 생각나는 대로 간단히만 적겠다.
• 모바일 사이즈로 미디어쿼리를 한창 적용하고 있던 중에 발견되는 다른 오류들을 고치고 하다 보니 결국 오류의 늪에서 벗어나지 못하고 모바일 사이즈는 절반도 채 제작하지 못했다. 그리고 난 아직도 그 안에...
• 있어야 하지만 아직도 없는 페이지들을 급히 만들었다.
• AWS에서 SSL 인증서를 발급받아 https 도메인을 적용했다.
• 구글, 카카오 소셜로그인 기능 적용하는 것을 백엔드 팀원인 하영님과 함께 며칠에 걸쳐 시도해 보았는데, 기능을 다 붙여놓고 나서 처음에는 둘 다 잘 되는 듯했다. 나중에는 유독 구글 로그인 후에만 CORS 에러가 빈번하게 발생했다. 구글 쪽으로는 눕고 싶지도 않았다..
• 이 CORS 에러를 해결하기 위해 XMLHttpRequest, 프록시 설정 등 온갖 찾을 수 있는 해결책은 다 때려 넣어봤다. 몇 시간을 붙잡아도 해결이 되지 않아서 우리는 CORS 에러 자체가 나오지 않는 환경을 만들기 위해 동일 도메인 배포를 시도했다. 48시간 동안 6시간만 자는 고난을 겪었지만 마음처럼 잘 되지는 않았다. 하지만 그렇게 긴 시간, 잠을 제대로 안 자도 열중해서 뭔가를 파고들 수 있다는 게 스스로 참 신기했다. 비록 결과는 만족스럽지 않았을지라도, 과정 자체에서 배운 게 많았다.
• 바로 윗 단락을 훈훈하게 마무리했지만, 동일 도메인을 포기하자마자 기다렸다는 듯이 https 배포가 말썽을 일으키기 시작했다. 도메인부터 해서 기본적인 설정들이 워낙 많이 다시 바뀌었으니 배포도 처음부터 차근차근 다시 했는데, 잘만 됐던 https가 이번에는 안 되는 것...!!! 울며 겨자먹기로 https마저 보류했다. 인터넷에서는 어쩜 그렇게 다들 쉽게 설명해 놨는지 모르겠지만 모든 방법을 다 따라해도 안 됐다ㅠㅠ(사실 나도 첫 번째 배포는 쉬웠어...)
• 1주일 내내 시도해본 것은 많았는데, 그랬던 것치고는 손에 쥘 수 있는 결과물이 얼마 없었다. 프로젝트에 적용을 못했으니 결국 누구도 이런 피나는 노력을 알아봐주지 않을 테니 허탈했다. 그래도 좋은 경험이었다. 대표적으로 하영님 말씀대로, AWS는 하도 들락날락거려서 이제 예전만큼 어렵게 느껴지지 않았다.
• 그러고 나서는 다른 조보다 늦어진 1차 배포를 준비했다. 크고 작은 에러, 어떤 경우에는 발생하고 어떤 경우에는 발생하지 않는(왜인지 원인을 아직 모르겠는) 에러들이 많은 상황에서 최대한 에러를 잡고 오류를 수정했다. 미완성인 부분이 꽤 있지만 어찌 됐든 일단 1차 배포는 할 수 있었다. 이건 '1차'니까 계속 수정하고 다차 배포하면 되지ㅎㅎ
• 배포를 하고 나서 든 생각인데, 어차피 나 스스로에게나 누군가에게나 지적받을 수밖에 없는 오류라면 배포해서 보여줘버리고 피드백으로서 추후에 반영하는 것도 괜찮은 것 같다. 조금이라도 더 고쳐놓고 배포하려고 하니 그 과정에서 시간이 너무 많이 걸렸고 효율적이지 않을 수 있다. 한 번 배포했다고 프로젝트가 끝나는 게 아닌데 피드백 받을 수 있는 기간이 긴 게 더 낫지 않았을까.
• 1차 배포 기념으로 처음으로 우리 팀 넷이서 맥주 한 캔씩 들고 얘기하는 시간을 가졌다. 프로젝트 관련이 아닌, 그냥 그때그때 생각나는 얘기 아무거나 할 수 있다는 게 너무 좋았다🍺
• 다들 주무시러 가셨고 나는 배포 이후에 바로 들어온 피드백 중 오류 관련한 사항들을 몇 가지 해결했다. 그리고 오랜만에 이렇게 TIL 아닌 TIL을 쓴다.
• http://talkbout.camp → https://talkbout.camp

내일 할 일

• 내일은 스파르타 대표와 우리 팀 전체의 면담이 있다. 그 전에 일어날 수 있겠지...?
• 모바일 사이즈 미디어쿼리를 후딱 적용하고 피드백 들어오면 가급적 바로바로 처리하자.
• 튜터님 면담 이후 작성한 할일 목록 중 이제 추가적으로 적용할 사항들 몇 가지만 남아 있는데, 하나씩 시도해보자.
• 그러고도 시간이 남으면 https와의 재대결을 위해 공부를 하자.

어제까지 한 일

• 며칠 만에 쓰는 TIL인지 모르겠다. 게을러서 혹은 바빠서 안 쓴 것도 있었지만, 그동안 멘탈 터질 일이 많았다. 아직 잠을 안 잤으니 오늘이 토요일이라 치면, 엊그제인 목요일에 우리 팀 프론트 두 분이 항해99에서 동시에 하차하셨다. 이로써 놀랍게도 우리 팀 프론트에는 나 하나 남게 되었고(ㅋㅋㅋ) 추가하려던 기능은 거의 모두 포기해야 했다.
• 하차 이유야 어찌 됐든 사전에 귀띔 한 번 하지 않은 것은 문제였다고 본다. 하지만 이미 앞으로의 시간은 2주도 채 남지 않았고, 이 문제에 대해서 왈가왈부할 시간도, 여유도 없었고, 감정 소모조차 하고 싶지 않았다. 팀장님 포함 팀원들도, 항해99 매니저님도, 리액트 튜터님도 모두가 나를 너무 걱정했다. 감히 짐작건대, 그 걱정은 1차적으로는 '이러다 얘마저 하차해버릴 수도 있겠는데...?' 하는 마음 아니었을까. 그렇지만 나는 애초에 하차를 고려해 본 적도, 외부 요인으로 하차할 마음도 전혀 없었다. 다른 분들의 우려는 이해하지만, 그 우려가 나는 약간 찜찜했다. '내가 그렇게 책임감이 부족해 보이나?' 싶었다. 그리고 사실 하차하신 두 분이 나에게 그렇게 영향력 있는 분들은 아니었으니 흔들릴 일도 아니었다.
• 아무튼 급한 대로 당장 코드 리팩토링부터 시작했는데, 구석구석 살펴보다가 알게 된 사실은 이미 태블릿 사이즈 CSS 적용 단계로 넘어간 상태였음에도 데스크탑 버전조차 삐끗하는 부분들이 있다는 거였다. 그러니 태블릿 버전은 말할 필요도 없었다. 이번 주 초에 두 분에게 '계획을 세워서 작업을 (빡세게) 해보자'고 얘기했었고(실제로는 하다 보니 그렇게 진행하지도 못했지만) 혹시 그것 때문에 부담을 느끼셔서 하차를 고민하신 게 아닐까, 잠시 그런 생각을 했었다. 하지만 코드를 정리하면서, 아무리 그렇게 얘기했어도 실제로 작업을 수행하는 쪽에서 전혀 협조적이지 않았었다는 것도 깨달았다. '이것도 안 했다고?' 하는 생각이 끝없이 중첩되고, 리팩토링을 하면 할수록 기운이 빠졌다. 상황을 이렇게 만든 나 자신에게 너무나 실망스러웠다. 밤새 코드를 만지고 나니 밤낮은 완전히 바뀌었고 기분도 많이 상했다.
• 그런 상태에서 어제 금요일 낮에는 튜터님이 오셔서 이 절망적인 상황을 타파하기 위해 전체적인 프로젝트 코칭을 해주셨다. 물론 프론트 중심이었지만, 튜터님이 오셔서 촌철살인 해주신 덕분에 앞으로의 작업 방향이 구체적으로 세워질 수 있었다. 내가 프론트지만 프론트는 정말 진짜로 엄청나게 꼼꼼해야 한다는 걸 절실하게 배웠다. 단 한 번도 생각지도 못한 포인트를 끝도 없이 짚어주셨다. 말 그대로 디테일에 강해야 했다. 할 일 목록이 길어지다 못해 바닥에 끌릴 정도였다. 그마저도 지금 나 혼자인 상황을 고려해서 규모가 크거나 시간 소요가 많을 만한 작업들은 다 제외하고 말씀해 주신 거였다.
• 그러고 나니 체력도 정신력도 온통 고갈되어 버려서 침대에 눕거나 눕지 않더라도 정신없이 잠들고 아주 난리가 났었다.

오늘 한 일

• 튜터님이 가르쳐 주신 포인트들을 우선순위를 매겨 대충 정리한 후 위에서부터 하나씩 지워나가고 있다. 하지만 다 지우려면 아직 한참 멀었지...
• 리스트로 죽 나열한 이미지 카드들에는 투명도가 낮게 설정되어 있고, 동적인 느낌을 주기 위해 마우스 호버 시에만 투명도를 높이게 되어 있었다. 그러다 보니 호버 효과가 나오면 이미지 위에 하얀색으로 적힌 타이틀이 거의 안 보이는 문제가 있었다. 텍스트 쪽을 어둡게 처리하면 된다는 그림이 그려졌고, 튜터님은 텍스트 쪽에 알파값을 주면 된다고 하셨었는데, 관련해서 아무리 검색을 해도 이렇다 할 시원한 해결책이 보이지 않았다. 결국 처리방법의 정석은 아닌 것도 같지만, 의사 요소 ::before와 linear-gradient를 적절히 섞어 이용했다. 마음에 드는 모양을 만들어 낼 때까지 너무 많은 시간이 걸렸다.

const ImageDiv = styled.div`
	opacity: 0.4;
    &:hover {
    	opacity: 0.9;
        ::before {
            position: absolute;              // 부모 요소에 position: relative 를 준다
            bottom: 0;
            content: '';
            width: 100%;
            height: 100%;
            background: linear-gradient(to bottom, transparent 20%, rgba(0,0,0,.6) 100%);
        }
    }
`;

내일 할 일

• 일단 아침에는 좀 쉬고....라고 해봤자 지금 벌써 8시구나ㅠㅠ
• 아마 많이는 못 쉬겠지...

오늘 한 일

• 벌써 이번 주 이틀이 지났다. 할 일은 산더미 같은데 오류를 한 번 만나면 내 멘탈 바사삭 되어 한동안은 더 이상 생산적인 사고가 불가능한 상태가 되어버린다. 기능을 더 탄탄하게 만들기 위해 필요한 추가적인 API가 아직 준비되지 않은 상황이라, 오늘은 프론트 팀원들과 함께 비교적 가벼운 목표들을 설정했고, 앞으로 더해볼 수 있을 만한 기능들을 탐색하는 데 시간을 보냈다.
• 그러면서 '로딩스피너나 붙여 볼까나 룰루' 했다가 큰 코 다쳤다... 의외의 복병이었다. 생각해보니 리덕스 모듈을 여러 개 쓰는 프로젝트에서 로딩스피너를 붙여본 적이 없었던 것이다(!!) 모듈이 하나이면 로딩 상태 여부에 대한 boolean 값을 리듀서에서도 설정해 줄 수 있는데, 모듈이 여러 개다 보니 결국 적어도 어느 하나의 모듈에서는 모듈 밖에 있는 로딩 상태를 건드려야 하는 꼴이었다. 이렇게 된 이상 모든 모듈들에게 공평하게, 로딩만 다루는 모듈을 새로 하나 팠다. 그리고 각 모듈 안에서 액션함수를 호출할 때마다 시작 지점쯤에 로딩 상태를 true로 바꿔주었다. 그런데!? 바로 여기서 문제가 있었다. 아무 생각 없이 모듈 한 개짜리 프로젝트에서 했던 것처럼 리듀서 안에서 다시 로딩 false로 바꿔주려니, 리듀서에서는 다른 동작을 불러 일으키는 짓을 할 수 없었던 것이다...! 모든 상태가 리듀서 안에서 깔끔하게 완결이 되어야 하지, 다른 모듈을 건드려서 또 다른 함수를 호출하면 안되는 것이었다. (stackoverflow에서 이걸 뭐라고 하던데 기억이 안 난다)
• 아무튼 매우 큰 실망을 안고 차선책을 찾아 헤맸다. 액션함수 앞에 넣은 로딩 true를 리듀서에 들어가기 전에 다시 바꿔주려면 결국 액션함수 말미쯤에나 로딩 false를 넣어야 한다는 건데, 그렇게 해서 스피너가 보이기는 할까 싶었다. (눈물을 머금고 해봤더니 보이긴 보이더라...) 원하던 그대로의 예쁜 코드는 아니었지만 트러블은 이렇게 일단락되었다.
• 그동안 나중에 봐야지 하고 미뤄놨던 자료들을 한 번 들춰보는 과정에서, 주특기를 리액트로 선택하기 이전에 진행되었던 주특기 Q&A 시간에 받아놨던 자료도 보게 되었다. 리액트를 "리액트스럽게" 사용하는 방법은, 컴포넌트를 재활용하고 서버에 대한 요청 횟수를 가급적 줄여서 리소스를 아끼는 것이라고 했다. 안 그래도 지금 우리 프로젝트 중 내가 짜 놓은 컴포넌트 일부가 API 콜을 필요 이상으로 많이 하는 것 같다는 생각을 하고 있던 와중에 접한 내용이었다. 이건 오늘이 날이다 싶었다. 마침 급하게 해결할 일도 없는 이 상황은 오늘이 마지막일 것이니 각 잡고 시작했다. 3개로 나눠진 페이지에 공통적으로 속해 있는 컴포넌트 하나를 완전히 위로 빼 버리고, 거꾸로 3개의 페이지는 하위 컴포넌트로 바꾸어 집어넣었다. 결론적으로 3개였던 페이지는 1개가 되고, 1개였던 하위 컴포넌트는 3개가 되었다. 그 3개의 페이지는 어차피 상단의 디자인은 같고 하단의 탭 간 이동만 발생하는 구조라 상식적으로도 하나의 상위 컴포넌트 밑에 3개가 함께 묶여 있는 게 맞다고 생각했다. (그 말인즉슨 지금까지는 비상식적...)
• 해결하는 과정에서 라우팅에도 변동이 생겨 에러란 에러는 다 만났지만 탭 간 이동을 할 때마다 API 콜을 하거나 useSelector를 쓰거나 history.state로 데이터를 넘겨줘야만 했던 문제가 해결되었다.

내일 할 일

• 오늘 찾아본 에디터 라이브러리를 적용해보자. 기껏 만들어 적용한 이미지 프리뷰와 업로드는 이 에디터에 묻혀버릴 것만 같지만...ㅠㅠ어쩔 수 없지.
• 태블릿과 데스크탑의 중간 어느 특정 구간에서 깨지는 배너를 어떻게 좀 해결해 보자.
• 프로필 사진 업로드 기능을 넣어보자. (이미지 프리뷰, 업로드 여기서 쓸 수 있겠군)
• 태블릿 CSS 최대한 빨리 끝내자ㅠㅠ그만하고 싶다..CSS..

오늘 한 일

• 오늘은 회의에 많은 시간을 쏟았다. 지난 주 토요일에 중간 점검이 있었는데, 다른 팀들이 워낙 준비를 잘 하기도 했고, 우리 팀에게서 부족한 점을 생각보다 많이 발견한 계기가 되었다. 다른 팀에는 질문하지 않는 CSS 관련 질문을 받는가 하면, 리덕스에 대한 기본적인 질문도 있었다. 모양새는 얼추 대답 비슷한 걸 내놨던 것 같기는 한데, 발표 준비에 소홀했던 나 자신을 되돌아보게 되었다. 그래도 우리가 앞 순서여서 다행이었던 걸까, 조금 긴장이 풀린 상태로 다른 팀의 발표를 들었다. 마지막 팀 발표까지 전부 보고 싶었지만, 그 전날 이미 한숨도 안 자고 밤을 새버린 나는 중간에 주어진 쉬는 시간 1시간 사이에 잠들어서 밤에 일어나고 말았다.. 아무튼 토요일 이후로 나는 물론 팀장님 포함 우리 팀원들 전체가 적지 않은 충격을 받았다. 그래서인지 바빴던 와중에 모처럼 앞으로의 계획을 차근차근 얘기해볼 기회가 있었다.
• 프론트 팀원들끼리는 지금까지 완성한 기능들을 톺아보는 시간을 가졌다. 에러가 나는지, 기능이 잘 돌아가는지 교차 확인도 해주고, 에러가 나면 같이 해결도 해보고, 서로서로 부족한 점도 얘기해주고. 평범하다는 평가를 받을 수밖에 없었던 CRUD를 오늘에야 마무리하는 듯싶다.
• 오후 8시 저녁 회의가 끝나고 나서는 피그마에 올라온 태블릿 사이즈 디자인을 적용해보기 시작했다. 지난번 클론코딩 때 눈에 충분히 익혔던 미디어쿼리를 적용해보았고, 직접 해보니 생각보다 까다롭지 않았다. 이미 styled-components를 사용하고 있던 중이라 원래부터 클래스나 아이디 선택자는 잘 사용하지 않았었는데, 이번에는 어쩌다 보니 클래스 선택자를 써야 할 일이 생겼다. 데스크탑 버전(1440*1080)에서는 메인 화면에 등장하는 카드가 6개인데, 태블릿 버전(768*320)에서는 그 수가 4개로 줄어야 하기 때문이었다. 잘 쓰지 않던 클래스 선택자와, 본격적으로는 처음 사용해보는 미디어쿼리를 적절히 섞어서 styled-components와 함께 쓰려니 약간 애매하게 느껴지긴 했다. 하지만 하늘은 역시 구글링하는 자를 돕는다고.
• "맨 마지막 카드 2개만을 어떻게 없애지!?" -> "일단 이름을 붙여야 없애든 말든 할 것이니 클래스를 써보자" -> "맵을 돌리는 카드들을 어떻게 각각 이름을 붙이지?" -> "인덱스가 다르니 인덱스로 이름을 줘 보자" -> "이름은 붙였는데 어떻게 없애지!?" -> "안 보이게 하면 그만 아닐까, 미디어쿼리 안에 클래스 선택자를 써서 display: none을 줘버리자" ... 이만하면 의식의 흐름도 생산적이었다(❁´◡`❁) 내 코드 웬만하면 TIL에 안 넣는데 오늘은 너무 뿌듯해서 넣는다.

....
	<CardList>
    	{pop_camps.map((pc, idx) => {
        	return (
            	<CampCard className={`campcard${idx}`} key={idx}>
 					....
                    
const CardList = styled.div`
	....
    @media screen and (min-width: 768px) and (max-width: 992px) {
    	.campcard4, .campcard5 {
        	display: none;
        }
    }
`;

내일 할 일

• 사용자 인증에 쓸 구글폼은 어떤 식으로 적용하는지 찾아보자.
• 보안을 강화하기 위한 HTTP ONLY 쿠키에 대해 알아보고 적용할 방법을 찾아보자.
• 백엔드에 요청한 API가 들어오는 대로 적용하자.
• 그러고도 남는 시간에는 태블릿 사이즈 디자인을 작업한다.
• 구독자가 구독 취소하는 게 가장 겁나므로 앞으로는 TIL을 꼬박꼬박 쓰자.

Day65 한 일

• 어제는 생일이라는 그럴싸한 핑계로 퇴근을 서둘렀다. 공식적으로 끝나는 시각인 오후 9시 이전에 나와 본 건 처음인 것 같다. 일찍 나오려면 작업을 미리, 많이 해둬야 하니 잠이 쏟아지는 점심시간에도 낮잠을 안 자고 버텼다. 내 몫의 API 콜 절반 이상을 완료했다.

Day66 한 일

• 그래서 어제는 나름대로 쉬었지만 잠은 평소와 다를 바 없이 늦게 잤다. 여느 때처럼 아침에 힘겹게 컴퓨터 앞에 앉아서 비몽사몽 팀원들과의 아침 인사를 마치고, 또 다시 반쯤 자면서 꾸역꾸역 일을 해나갔다. 밤새 API 리스트에 크고 작은 변경사항들이 있어서 결국 어제 한 번씩 짚고 넘어갔던 것들도 다시 봐야 했다. 그래도 기본 틀은 변하지 않아서 시간이 많이 걸리진 않았지만, 했던 걸 다시 한다는 것은 어쨌거나 고역이다. 복습(?)을 빨리 끝내고 남은 기능들을 마저 구현하는 데 오늘 하루를 다 보냈고, 덕분에 내일은 조금이나마 여유로울 것 같다. 대충 한번 훑고 지나갔던 부분들을 들여다 볼 수 있는 시간이 주어질 듯하다.
• 지금까지는, 좋아요 기능처럼 클릭했을 때 새로고침 없이도 그때그때 생김새(?)가 변하면서 상태가 저장되어야 하는 기능은 나 혼자만의 힘으로는 구현하지 못했었다. 그런데 운이 좋은 건지, 오늘은 처음으로 아무것도 참고하지 않았는데도 북마크 기능을 완성할 수 있었다! 그렇지만 아직도, 북마크 추가한 이후에 같은 페이지에서 바로 새로고침을 하면 북마크가 해제되지는 않더라도 해제된 것처럼 표시되고 있다. 다른 페이지로 이동한 후 새로고침하고 나서 다시 돌아오면 서버에 저장된 상태 그대로지만, 북마크 추가한 후 그 자리에서 곧장 새로고침을 해버리면 서버의 데이터는 건드려지지 않는다 할지라도 겉보기엔 북마크가 해제된 것 같다. 이걸 어떻게 해결해야 할지 여러 번 코드를 들쑤시다가 결국 무한루프에도 빠져보고 난리가 났다. 다시 원래대로 돌려놓고 이건 내일의 나에게 맡겨야겠다.

내일 할 일

• 북마크랑 유사한, 좋아요 기능을 구현하면서 오늘 약간은 모자랐던 북마크 기능의 부족함을 채워보자.
• 데이터 불러올 때 서버에서 페이징 처리한 데이터를 적절히 운용해야 한다. 오늘은 급한 마음에 다 건너뛰었지만 내일은 꼼꼼히 챙겨보자.

Day63 한 일

• 그저께는 일요일이었다. 쉬는 날이었지만 으레 그렇듯이 저녁 먹고 느지막이 출석 도장을 찍었다. 게더에는 사람도 별로 없고 해서 게더를 꺼놓고 온전히 코딩만 할 수 있었다. 전날 계획했던 대로 피그마에 디자이너님들이 그려놓으신 대로 CSS 규격을 최대한 정확히 맞춰서 뷰를 구현하는 데 시간을 쏟았다. 피그마에서는 CSS 코드도 어느 정도 확인할 수 있었지만 그렇다고 해서 그대로 갖다 붙인다고 원하는 그림이 나오는 건 아니었다. 바닥부터는 아니더라도 손을 대지 않을 수는 없었다. 그렇게 시작한 CSS 작업은 해가 뜨고 아침 8시가 되어서까지 이어졌다... 잠을 하나도 안 자고 밤을 넘겨 본 게 얼마 만이었는지 모르겠다. 대학생 때도 술 마실 때 아니고서는 과제할 때조차 밤을 꼬박 새진 않았었는데, 세상에나.

Day64 한 일

• 밤을 새버린 탓에 오늘은 시간이 조금만 나면 부족한 잠을 보충하기 일쑤였다. 오전 11시부터 4시간 자고, 또 오후 6시부터 2시간 자고. 잠이 안 올 때 밤샘 작업을 하면 그때만큼은 온전히 조용하게 시간을 쓰면서 집중할 수 있다는 장점이 있지만, 다음날 부작용이 너무 큰 것 같다. 오늘 뭘 했는지도 기억이 잘 안 난다. (어쩌면 한 게 없는지도)
• 밤 12시가 되자마자 팀장님을 비롯한 우리 팀 분들이 갑자기(!!!) 모여들어서 생일 축하 노래를 틀고 🍰 이렇게 생긴 스냅카메라의 케이크 필터로 내 생일을 축하해주셨다. ㅋㅋㅋㅋ다시 생각하니 또 웃기다. 당황스럽기는 했는데 재밌고 고마웠다. 0시부터 비대면으로 축하받는 생일이라니 너무너무 특별하다.

내일 할 일

• 백엔드에서 오늘 거의 모든 기능이 다 들어 있는 API 리스트를 주셨다. 내일 그래두 생일이니까 밤에 조금이라도 쉬려면 낮잠 절대 자지 말고 열심히 다 해버려야지.
• 틈틈이 피그마에 맞춰 CSS를 고친다.

오늘 한 일

• 큰 교훈을 얻었다. 앞으로는 새로운 툴을 발견(사용)하게 되면 무조건 공식문서나 튜토리얼 문서부터 보고 시작해야지. 프로젝트 처음부터 한창 사용 중이던 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 테스트를 하면서 하나씩 적용하고, 필요한 곳에 페이지네이션을 넣고, 다른 사람이 보기에 다소 난해할 수 있는 코드에 주석을 달았다.

내일 할 일

• 확정된 디자인 시안을 확인하고 피드백을 한다.
• API 리스트 수정사항을 확인하고 테스트한 후 피드백을 한다.