D'story

오늘까지 한 일

• 일이 엄청 많거나 너무 바쁜 건 아닌데, 그렇다고 하루하루 하는 일이 차근히 정리되고 있는 것 같진 않다. 사이트 개편 앞두고 일종의 마무리 작업 중이라서 그런 건지, 항상 느끼는 거지만 마치 깔끔하게 치워놓은 방이 어질러지듯이 처음엔 시작이 얼마나 정돈되었든 뒤로 갈수록 '일단 하고 본다'는 식의 임시방편성 코드가 많아지게 된다. 내 코드 내가 읽어도 정신이 하나도 없다.
• 하루종일 허둥대며 코드를 짜다 보면 퇴근하고 나서는 생산적인 일은 별로 하고 싶지 않다. 그래서 요 며칠 TIL도 안 남기고 아무런 의미 없는 시간을 보냈는데, 또 다른 분들 글을 읽고 나면 나는 지금 뭐하나 싶다. 잠깐 해찰하며 여유를 가졌던 것에 만족해야겠다. 슬슬 다시 힘을 내야지.
• 오늘은 동영상 인코딩 처리를 위한 큐를 구현하는 데 (완벽하게 성공했다고 장담할 수 없지만) 어떤 방법을 써야 할지 고민하면서 찾아봤던 반복문 사용의 차이점을 링크로 건다.

오늘 배운 것

• for ... in 반복문에 대한 링크. for ... in 을 통해 직접적으로 가져올 수 있는 건 객체의 key-value 중 key이다. 객체의 요소들을 순서대로 가져온다는 보장이 없으므로 인덱스가 중요한 배열 등에 사용하는 것은 권장되지 않는다.

• for ... of 반복문은 문자나 배열에 사용한다. 배열 안의 요소 자체를 가져온다. 아래 링크에 예시 코드와 함께 for ... in 과 for ... of 의 차이점이 잘 정리되어 있다. 나중에 다시 한번 읽어봐야 할 것 같다.

• 반복문들의 차이점에 대해 "한글로" 잘 정리해둔 곳을 찾았는데 뭐가 문제인지 모르겠지만 지금은 안 열린다(?!) 혹시 나중에 잘 뜰지도 모르니 일단은 저장..

https://jsdev.kr/t/for-in-vs-for-of/2938

오늘 한 일

• 사실 Amplify를 연계한 로그인, 회원가입 페이지 작업은 지난 주에 끝냈지만... 오늘은 동영상 인코딩 문제 때문에 하루종일 씨름만 하고 성취해 낸 건 딱히 없는 기념으로 뒤늦게 가져와 봤다. 아니 그나저나 도대체 왜 어떤 mov는 인코딩 속도가 느려?!
• AWS Amplify 문서는 정말 너무 깔끔하고 너무 좋다. 괜히 자꾸 읽고 싶고 정독해야 할 것 같고 다른 키워드도 다 클릭해봐야 할 것 같고 저 오렌지 색도 예쁘고 막... 어제 올린 멀티파트 업로드 쪽 문서가 Amplify의 반만 됐어도 그렇게까지 애먹지는 않았을 텐데, 같은 AWS여도 워낙 서비스가 다양해서인지 참 다르다.

오늘 아니고 그때 배운 것

• 지난 번에도 올렸던 링크다. 그때는 sign in/out만 구현했었고, 이번에는 sign up까지 완료했다. 아무래도 회원가입 페이지가 로그인보다는 만들 게 많으니까 뒤로 미뤘었다. 그리고 Amplify에서 제공하는 UI components를 사용하면 더욱 간단했겠지만, 무엇보다 뷰 자체는 회사 기획안에 맞추다 보니 시간이 좀 더 걸렸다.

• 이건 로그인 화면 어딘가에 위치한 '비밀번호 찾기'에서 쓰이는 함수를 포함한 부분이다.

• 근데 문제는 이 공식문서에서 소개하는 함수들을 그대로 사용하다 보면, 회원가입 절차가 [아이디(이메일), 비밀번호 입력 -> 회원가입 -> 입력한 이메일로 인증번호 발송 -> 인증번호 입력하면 회원가입 절차 완료] 이런 식으로 가게 된다. 하지만 기획안대로라면 [아이디(이메일) 입력 -> 입력한 이메일로 인증번호 발송 -> 인증번호 입력해서 확인되면 비밀번호 입력 -> 회원가입] 순서여야 한다. 인증 메일은 회원가입이 되고 난 후에나 보내주는 것인데, 우리는 가입을 완료하지 않은 시점에서 이메일만 우선적으로 확인하고 싶은 것이다. 회원가입 절차 자체를 커스터마이징 해야 하는 거라 이건 추후 Lambda Trigger를 활용하거나 해야 할 것 같다. 아직은 안 해봄

오늘 한 일

• 지난 주에도 뭔가 많은 걸 해내서 뿌듯했던 것 같은데 기록을 남기지 않았더니 기억이 안 난다. 이번 주부터는 그러지 맙시다...ㅠㅠ
• 오늘은 지난 주 후반부터 작업한 AWS S3에 멀티파트 업로드하는 코드에, 업로드 진행상황을 알려주는 프로그레스바를 붙이는 작업을 했다. 프로그레스바 작업은 딱히 참고한 문서나 링크 없이 한 거라 별 게 없다. progress를 useState로 관리하고, progress의 setter 함수를 멀티파트 업로드 함수에 인자로 넘겨서 그 안에서 업로드 상황에 따라 progress를 설정하게끔 했다. 5MB 단위로 분할하게 해 놨기 때문에, 파일 전체 크기를 1024 * 1024 * 5로 나눈 후 그걸로 다시 100을 나눠서 파트 하나당 몇 %를 먹는지 계산하고, 그걸 그대로 progress에 넘겨서 프로그레스바의 너비로 지정해주었다. 뭔 소리..
• AWS S3 멀티파트 업로드를 공부하며 애먹었던 가장 큰 이유는, 일단 AWS 사이트 내에 산재된 수많은 사용설명서들 중에 어떤 게 가장 직접적으로 큰 도움을 줄지 알 수 없었던 것이었다. 자꾸 아래에 레퍼런스라면서 다른 링크가 걸려 있는데 들어가보면 너무 예전 링크인 것도 있고, 딱히 별 도움이 안 되는 이론만 적혀 있는 것도 있고, 아까 봤던 링크를 다시 걸어놓은 것도 있었다. 혹시 나중에 또 멀티파트 업로드를 시도할 일이 있을까 봐 미래의 나 분명 삽질하고 있을 테니 그만하고 보라고 가장 도움 되었던 링크를 아래 붙인다.

오늘 배운 것

• AWS S3 기본 사용설명서 링크. 영어로 보다가 속도가 안 나서 손절하고 한국어로 갈아탔다.

• 위 링크를 통해 멀티파트 업로드가 어떤 원리로 돌아가는지 알게 되었다면, 그 다음은 SDK 문서를 보면 된다. 이게 가장 도움이 많이 되었는데 개인적으로는 가장 찾기 어려웠다. SDK로 제공하는 모든 함수들이 예제 코드와 함께 자세히 나열되어 있다.

• 위 링크에 함수들이 있는 건 알겠는데 혹시 언제 어떤 함수를 써야 할지 헷갈린다면 이걸 보면 좋다. 여긴 한국어 지원이 안 된다.

• 실제로 AWS SDK를 이용한 멀티파트 업로드로 동영상을 업로드한 코드를 올려놓은 블로그. 멀티파트 업로드는 말 그대로 업로드 과정만 지원하기 때문에 파일은 업로드하기 전에 알아서 분할을 해야 하는데, 파일을 분할한다는 게 감이 잘 안 잡혀서 조금 헤맸었다. 파일 분할하는 부분이 특히 참고할 만했다.

오늘 한 일

• 어제 퇴근 전에 주어진 게시판 모듈 만들기 작업을 하고 있다. 해당 컴포넌트에 DB에 저장된 리소스 이름, 테이블 형태로 보여줄 데이터 중 선택한 키 배열을 props로 넘기면 자동(?)으로 게시판을 생성하는 기본적인 기능은 거의 구현했고, 좀 더 사용성 좋게 만드는 일만 남았다. 물론 그게 하루 이틀 만에 될 일은 아니겠지만.
• 게시판 모듈에 반드시 포함되어야 하는 기능 중 하나가 페이지네이션이었다. 예전에 프로젝트 할 때 서버에서 페이지별로 데이터를 어떻게 끊어서 보내줄 것인가, 그 다음 페이지가 있는지 없는지를 어떻게 확인하도록 해줄 것인가를 가지고 백엔드 분하고 같이 고민해본 기억이 난다. 이사님께 말씀드렸더니 서버에서 보내주는 응답 헤더에 있는 Content-Range를 확인하면 DB에 저장된 데이터의 총 개수를 알 수 있다고 하셨다. 오... 전혀 몰랐다...
• 요청에 대한 응답이 올 때마다 헤더로 데이터 총 개수를 확인할 수 있고, DB로 API 요청을 보낼 때 range 쿼리를 날리면 딱 그만큼의 범위에 해당하는 데이터만 돌아온다. 그렇다면 페이지네이션은 내가 쿼리만 잘 날리고 헤더만 잘 보면 되는 것이었다! 고민했던 그때의 경험에 비하면 너무 손쉽게 해결되어 버렸다.

오늘 배운 것

• 서버의 응답 헤더 속 Content-Range에 대한 설명

오늘 한 일

• 팀원 두 분을 모시고 지금껏 해온 웹 프론트 작업에 대한 리뷰(라고 쓰고 발표라고 읽는다)의 시간을 가졌다. 프로젝트 폴더 구조를 어떻게 만들었는지, styled-component를 이용한 CSS는 어떤 식으로 짰는지, 작업한 페이지는 어떻게 구성했는지, 첨부파일은 왜 리덕스를 거쳐 업로드 하는지 등등.. 말하다 보니 내가 무슨 말을 하고 있는지도 잘 모르겠지만 어떻게든 끝내긴 했다. 관객이 둘뿐이어도 난 역시 무대 체질은 아닌 것 같다ㅠㅠ 내가 그냥저냥 주워섬기는 두서없는 말들을 잘 이해해주신 두 분이 그저 대단하시다.
• 어제 진행해 본 AWS Amplify 튜토리얼을 토대로 공식문서를 참고해서, 직접 만든 로그인 폼에 로그인/아웃 기능을 붙여 보았다. 뷰를 직접 짰다고는 하지만 레퍼런스 자체가 Amplify UI를 이용해 만들어진 것이었어서 생김새는 똑같다는 게 함정ㅋㅋ.. 아무튼 지금 기본 기능만 제대로 돌아가게 해놓으면, 나중에 기획이 나왔을 때 UI를 그대로 가져다 쓰는 것보다는 더욱 자유로운 커스터마이징이 가능할 테니 좋은 게 좋은 거라 생각하고 있다. 

오늘 배운 것

• UI 없이 Amplify Authentication 기능 붙이기에 관한 링크

오늘 한 일

• 아직 출근한 지 3주도 지나지 않았지만, 돌이켜 생각해보자면 (총 3번에 걸친 면접 중) 첫 면접을 볼 때였는지 아니면 합격하고 나서였는지, 이사님이 구글링을 할 때 다른 건(그 중 특히 블로그, 그 중 특히 한글로 쓰인) 다 볼 필요 없고 공식문서만 보면 충분하다고 하셨었다. 항해 때도 귀에 딱지가 내려앉도록 들었던 얘기였지만 언어의 장벽을 무시하기란 결코 쉽지 않았다. 영어 읽기를 싫어하지도 않는데 한글이어도 익숙지 않을 용어들이 그것도 영어로 자꾸 나와서 그런지 왠지 거리를 두곤 했었다.
• 하지만 역시 회사란 나로 하여금 많은 것을 하게 만드는 존재인가 보다. 어느새 나도 모르게 영어로 검색하고 영어로 된 자료를 찾아보고 있다. 물론 한글로 된 자료도 많이 참고하고 있지만, 낯설게만 느껴졌던 용어들은 오히려 영어일 때가 쉬운 경우도 있었다. 원래부터 영어였던 그 말들을 한글로 옮기는 과정에서 해석의 여지가 있으면 그게 더 나를 헷갈리게 만들었다.
• 오늘은 드디어 그간 부여잡고 있던 페이지 작업을 얼추 마무리하고 로그인 페이지로 넘어갔다. 퇴근이 가까워진 시간이어서 로그인 관련해서는 이렇다 할 진전이 있지는 않았고, AWS Amplify 튜토리얼 정도만 진행했다.
• 와 근데 이건 뭐 프론트에서 백엔드 작업까지 할 수 있고, 그래 어쩐지 소제목부터 Set up fullstack project 혼자서 토이 프로젝트 하거나 할 때는 말 그대로 진짜 혼자 하는 것도 가능할 것 같다.

오늘 배운 것

• Amplify 공식문서 튜토리얼 링크. Amplify CLI를 다운 받을 때는 npm 사용하고 모듈 에러 나서 PATH 맞춘다 뭐다 죽어라 애쓰지 말고 마음 편히 curl로 받자...^^

오늘 한 일

• 으으 예정보다 늦어지는 것 같은데 아무튼 지난 주부터 붙잡고 있던 페이지를 아직 차마 놓아주지 못하고 마무리 작업에 돌입했다. 물론 지금 단계에서야 마무리라고 해도 새로운 기획이 나오면 재시작이지만.
• 이 페이지를 처음 작업하기 시작했을 때, type 속성이 file인 input을 만들 때 일단 그 못생긴 브라우저 기본 버튼을 숨겨놓고 다른 element를 클릭하면 파일 창이 나오게 했다. 거기서 조금 더 욕심을 냈던 게 라이브러리 없이 drag&drop 기능을 넣는 거였는데, 잘 안 됐었다. 원하는 위치로 파일을 드래그하기만 하면 콘솔창이 온통 새빨개지기 일쑤였다. 그땐 뭐가 문젠지 몰랐었다. 사실 지금도 모른다.
• 아무튼 그때 알 수 없는 원인으로 실패해버리고 만 그 작업을 오늘 다시 시도해보았다. 지난번과 같은 레퍼런스를 참고하면 또 같은 일이 일어날 것이었으므로 아예 검색부터 새로 하기로 했다. 그리고 참고한 갓MDN 덕분에 드디어 성공했다.
• 생각해 보면 이 작업을 처음 시도했을 때는 input을 클릭해서 파일을 넣어서 aws s3로 보내는 기능조차 완성되어 있지 않은 상태였다. 만약 drag&drop이 성공했다 하더라도 input을 클릭해서 파일을 첨부하는 것과 input에 drag&drop 해서 첨부하는 것, 이 두 갈래길을 처음부터 만들어놓고 파일을 가공해야 했을 것이다. 하지만 지금은 이미 클릭으로 파일을 첨부하면 어떻게 처리할지를 모두 정하고, 단순히 파일을 첨부하는 방식만 한 가지 더 추가하는 것이므로 어쨌든 지금이 훨씬 더 나은 방법인 것 같다.

오늘 배운 것

• 갓MDN의 File drag and drop 링크.

• 여기서 나는 dataTransfer를 사용하는 과정에서, 분명히 파일을 첨부했는데도 dataTransfer.files의 length가 0이 나오는 문제를 겪었다. 그건 아래 링크를 참고하고 해결했다. 갓스택오버플로우

오늘 한 일

• 아무리 프론트만 해와서 백엔드 서버가 돌아가는 시스템(까지 갈 것도 없다)이나 DB에 관해서는 문외한이라 하더라도 이 정도까지 기본 소양이 부족할 수 있는 걸까 하는 생각에 자괴감이 들었다.
• 처음에는 비록 리팩토링이 아주 많이 필요할지라도, 시간이 좀 걸려서라도, 어쨌든 결과적으로는 생각한 대로 코드가 잘 짜여져 나간다고 느꼈다. 하지만 한 가지 간과하고 있었던 건, API가 아직 짜여지는 중이라는 것이었다. 그러니까 한 마디로 백엔드 서버와 통신할 수 있는 매개체가 없는 것이다. 뭔가 그 비슷한 역할을 하는 것이 있다 하더라도 그것은 계속해서 변화를 거듭할 것이었고, 절대적일 수는 없었다(사실 이건 어떤 상황에서든?).
• 프로젝트를 할 때는 다같이 무에서 시작하니 유를 창조해내기 위해 기획부터 시작했고, 기획이 어느 정도 마무리 지어져야 또 다같이 개발이라는 다음 단계를 밟아나가는 식이었다. 하지만 여기는 회사인걸, 모두 다같이 어떻게 무에서 시작할까. 심지어 내가 신입인데! 이미 돌아가고 있는 프로세스를 파악해서 거기에 맞게 단계를 맞춰서 빨리 따라붙든 해야 하는 건데.
• API가 아직 만들어지고 있다, 라는 말을 처음 들었을 때 이미 상황 파악이 끝났어야 하는 거였고, 그걸 잊어버리거나 간과해서는 안됐다. 이미 DB에 저장되어 있는 데이터의 구조를 파악하기 용이하게끔 DB에 접근할 수 있게 해주셨던 건 말 그대로 '파악'에 중점을 둔 거였고, 내가 DB로 뭔가를 할 필요가 있어서는 아니었다. 원래는 프론트단에서도 DB를 직접 다루는 방식이었지만, 지금은 그렇게 하지 않는 쪽으로 서버가 재개발되고 있었다. 그러니 더더욱 DB에는 손댈 필요가 없다. 기존 코드를 분석하면서 그 흐름을 따라가다 보니 나도 모르게 DB를 만지고 있었던 것 같다. 뭐.. 돌이켜 생각해보니 그렇다.
• 백엔드와의 첫 협업 프로젝트 때 이런 것들을 포함한 중요하거나 사소한 다양한 부분에서 각종 마찰, 잡음이 있었고 서로를 이해하느라 많은 대화가 필요했었다. 그 많은 대화의 시간들을 통해 우물을 벗어났다고 생각했는데, 고개를 들어보니 그저 더 큰 우물 안이다.