D'story

어제까지 한 일

• 며칠 만에 쓰는 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 리스트 수정사항을 확인하고 테스트한 후 피드백을 한다.

Day59 한 일

• 거짓말처럼 뭘 좀 본격적으로 해보려고 하면 서버가 터져버리고 말았다ㅠㅠ어제는 정말로 하루종일 한 게 거의 없었다. 서버가 없어도 할 수 있는 뷰 수정 정도? 그나마 디자이너분들이 세세한 부분까지 신경쓰고 계셔서 실시간으로 변화하는 디자인에 맞춰서 해야 하는 일들이 꽤 있었다.

Day60 한 일

• 벌써 60일차라니 말도 안 된다. 이제 1개월 남짓 남았다는 얘긴데... 프로젝트 진행 속도가 더뎌지니 그만큼 걱정이 쌓여간다. 잠을 줄여가며 바쁘게 자료를 찾아보고 에러 띄워서 해결해도 모자란데. 며칠간 서버가 연약했던 차에 작업이 거의 올스톱 상태였어서, 오늘은 서버가 비교적 잘 돌아가는 데 비해 머리가 돌아가지 않아 또 속도가 안 났다ㅠㅠ...
• 어제 오늘 API 리스트의 길이가 급격히 길어지고 있어 질문글과 이미지에 대한 리덕스 모듈을 짰다. 이미지는 게시글을 작성할 때 파일을 첨부할 수 있는데, 파일을 선택하자마자 미리보기를 띄워주는 것까지는 큰 문제가 없었는데 막상 서버에 업로드하는 부분에서 막혀서 시간이 좀 걸렸다. 한창 작업할 때는 몰랐는데, 잠깐 놓고 돌아섰을 때 생각해 보니 서버에 업로드를 정상적으로 하더라도 API가 준비되어 있지 않아 정작 게시글을 불러올 때 업로드한 이미지를 함께 가져올 수 없는 상황이었다. 그러다 보니 또 완결하지 못한 채로 다음으로 넘어가 버렸다.
• 내가 맡은 게시판의 페이지네이션을 해보았다. 예전에는 지금보다 더 간단한 형태의 페이지네이션을 했었는데, 그때 적어뒀던 스켈레톤 코드를 응용해서 좀 더 복잡시럽게 만들어 보았다. 세련되지 못한, 너무나 원시적인 코드라 또 어떤 문제가 있을지는 두고 봐야 알 것 같다. 그래도 기능을 혼자 구현해봤다는 것 자체가 의미 있는 걸까.
• 그리고 2차 배포를 앞두고 한창 작업을 하고 있는데 또 다시 서버에 문제가 생겨버렸다. 어제까지의 문제만큼 심각한 건 아니라는 것 같은데, 사실 프론트 입장에선 결과적으로 크게 다른 건 없는 듯하다. 어쨌든 또 다시 올스톱 상태가 되어버렸다.

내일 할 일

• 서버가 잘 돌아가는 것만 얼른 확인한 후, 다른 프론트 팀원분이 하신 로그인 유지 기능이 정상 작동하는지만 보고 2차 배포를 한다. 지난 1차 배포에 비해서 디자인적으로는 많은 게 변했지만 기능은 거의 붙어 있지 않은 상태라 영 마음이 편치 않다.
• 제발 내일은 서버야 건강하렴... 나도 일을 좀 해야 하지 않겠니ㅠㅠ