D'story

오늘 한 일

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

오늘 배운 것

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

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

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

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

오늘 한 일

• 팀원 두 분을 모시고 지금껏 해온 웹 프론트 작업에 대한 리뷰(라고 쓰고 발표라고 읽는다)의 시간을 가졌다. 프로젝트 폴더 구조를 어떻게 만들었는지, 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이 나오는 문제를 겪었다. 그건 아래 링크를 참고하고 해결했다. 갓스택오버플로우

오늘 한 일

• 아직 API도 붙이지 않은(그냥 내가 알아서 원래 있는 API 적당히 갖다 붙여놓고 시험 중인) 페이지만 계속 만지작거렸다. 오늘 안에 끝나지 않을까 싶어서 아침 스크럼 때 그렇게 말했는데 웬걸, 하루 웬종일 시간 다 잡아먹고 결국은 오늘을 넘기게 되었다. 언제나 그랬듯이...
• 게시판과 같은 종류의 페이지를 만드는 건 여러 프로젝트를 거치며 쉽게 할 수 있다고 생각했는데, 지금껏 해 온 것과는 조금 다른 형태를 다루게 되니 마냥 새롭기만 하다. 회사 일이다 보니 조금 더 신중히 작업하게 되는 것도 같다.
• DB에 저장된 항목들이 input(text, file)이나 select로 알아서 나열되어야 한다. 당연하게도, DB에 저장된 그 항목들은 언제든지 개수가 늘어날 수도, 줄어들 수도, 내용이 바뀔 수도 있다. 그러다 보니 input과 select가 어떤 순서로 몇 개가 나열될지는 알 수 없다. 그런 상황에서 useRef로 해당 태그의 값들을 가져오고 싶은데, 일일이 선언하자니 말도 안되는 짓인 것 같았다. 만약 input 태그가 극단적으로 많아져서 100개라면!? 1억개라면!? (생활코딩?ㅋㅋㅋ)

오늘 배운 것

• 그래서 찾아온, useRef의 초깃값을 애초에 배열로 줘버리고 배열로 관리하기 링크.

오늘 한 일

• 오우.. 회사에서 하루종일 맥북만 붙잡고 있다가 집에 돌아와서 윈도우를 쓰자니 키보드 단축키부터 헷갈리기 시작한다. 이것이 맥북의 힘인가! 역시 맥북을 사야 하나!
• 오늘은 어제까지 대강 뷰를 잡아둔 페이지에 실질적으로 DB에 들어 있는 데이터들을 연동하는 작업을 시작했다. DB에 들어가는 데이터에 따라 화면에 나타나는 내용이 달라지는 방식인데, 어제까지 더미 데이터를 씌워놓은 뷰에 갑작스레(?) DB를 얹으려니 처음에 조금 헤맸다. 프로젝트 할 때는 사전에 약속해둔 API 명세를 참고해서 그대로 잘 찍혀 나오는지만 확인해가면서 처리했었는데, 이번에는 API고 뭐고 없다. 그냥 일단 하는 거다.
• 그러다 보니 어디서부터 시작해야 하는지 조금 막막해져서 한동안 삽질을 계속하다가 어느 순간 정신을 차린 나를 발견할 수 있었다. 오오 이것도 회사의 은총인가요...!
• 근데 그러다가도 별 희한한 데서 시간을 무지 끌었다. select 태그에서 별도의 option을 선택하지 않아도 처음부터 특정 값을 보여주는, 그러나 사용자가 다른 값을 선택한다면 그걸로 바뀔 수도 있는, 그런 모양새를 만들고 싶었다. option 태그에 selected 속성을 주자니 리액트에서 경고 문구를 띄우며 option에 selected를 주는 대신 select에 value나 defaultValue를 주라고 했다. 그래서 평소 하던 대로 'css select default value' 등으로 구글링했더니, 하나같이 select에 초깃값을 지정해주면서도 사용자의 선택을 허용하고 싶다면 defaultValue 속성을 적용하라는 것이었다. 여기저기서 같은 해결책을 제시하기에 철석같이 믿고 그렇게 했는데 전혀 적용이 안됐다. 한참의 삽질 끝에 설마설마 하며 검색한 결과, select 태그에는 defaultValue 속성이 없다^^ 이 사람들아...

오늘 배운 것

• 그래서 적는 MDN의 select 태그 정보 링크. 바보같은 나 자신, 진작 검색했어야 했다.

오늘 한 일

• 어제 적었듯, 지금 하고 있는 일은 이미 있는 회사의 웹페이지를 클론하는 작업(겸 연습)이다. 비록 무에서 유를 창조하는 류의 개발은 아니지만 어쨌든 회사 일이기에 개인 혹은 팀 프로젝트를 하거나 혼자서 뭔가를 만들어 보는 때와는 그래도 마음가짐이 달라지는 것 같다. 물론, 프로젝트는 대충 해도 된단 건 절대 아니다. 아무튼 코드 한 줄 한 줄 작성하면서 내가 할 수 있는 범위 내에서의 가장 효율적인 방법을 찾게 된다. 예전에는 마음 가는 대로 일단 손가락부터 움직이고 봤다면, 지금은 손에도 뇌가 달려 있는 느낌ㅋㅋㅋ이랄까.. 고민하느라 속도가 더뎌지기도 하지만 능력이 허락하는 한 고민을 거듭하게 되는 건 좋은 일이라고 생각한다. 지금 당장은 부족한 점이 많더라도 고민의 끝에는 발전의 여지가 있다는 뜻이 아닐까. 그게 언제일지는 아무도 모르지만^^
• 지금껏 나름대로 여러 번의 팀 프로젝트에 참여하면서 기획 단계에서나 API를 구상할 때나, 백엔드 담당이었던 분들과 충분히 소통했다고 생각하고 있었다. 하지만 오늘 API 관련해서 쿼리스트링에 대한 질문을 받았을 때에서야 내가 얼마나 서버와의 통신에 무지했는지를 깨달았다ㅠㅠ 프론트와 백의 경계를 나누는 것 자체가 애매하다손 쳐도, 프론트라고 해서 프론트만 해도 되는 게 아닌 것을.. 죽을 때까지 공부만 해도 모자라겠다.

오늘 배운 것

• 라우팅되는 여러 페이지에서 공통적으로 사용되는 컴포넌트가 있다면 라우팅에서 제외시켜버리면 된다. 예를 들어, 헤더가 여러 페이지에 걸쳐 계속 나타난다면 헤더는 라우팅 범위에서 빼 버리고 나머지 컴포넌트들만 페이지별로 다르게 보이도록 하는 것이다. 어쩌면 당연한 이 작업을, 나는 지금껏 한 번도 시도해본 적이 없었다. 위에서 말한 것처럼, 부족한 내가 회사 덕분에 발전한다..

• 아이콘을 사용해야 하는 경우 react-icons를 자주 쓰곤 하는데, 이번에도 필요한 형태의 svg 파일을 찾다찾다 결국 마음에 드는 걸 찾지 못하고 돌고 돌아서 react-icons으로 회귀했다. 이걸 쓰지 않으려고 했던 이유 중 하나는 커스터마이징이 잘 안 된다(고 생각했던, 특히 색상 같은 부분)는 거였는데, 사용하려는 아이콘의 원 출처로 링크를 타고 넘어가면 커스터마이징에 관한 문서가 있다. 이것도 참 당연한 수순인데.. 회사만이 너의 눈을 뜨게 하리라. 오늘 찾은 링크를 예시로 들어 붙인다.

내일 할 일

• 금요일이다! 신나게 코딩하자!

오늘 한 일

• 어제부터 연습 삼아 떨어진, 말하자면 '회사 홈페이지 클론코딩' 작업을 하고 있다. 작업 순서도 내 맘대로, 커밋도 내 맘대로, 폴더 구조도 내 맘대로, 아무리 연습이라 해도 처음부터 너무 엉망으로 시작한 게 아닌가 싶다. 착수하기 전에 뭔가 계획을 짜고 시작해야 했나? 매일 공식문서들만 들여다 보다가 오랜만에 코딩만 해도 되는 시간이 오니 반가워서 이성을 잃었었나.. 하지만 이미 돌이키긴 늦었지.
• 나는 지금까지 프로젝트를 하면서 깃허브만 이용했었는데, 회사에서는 비트버킷에서 코드를 관리한다. 처음으로 깃허브가 아닌 다른 플랫폼을 접해봤고, 말로만 들었던 소스트리도 한정적인 부분에서나마 직접 사용하게 되었다.
• 환경이 약간 달라져서 그런지 git add 해놓고 금방 후회하고, commit 해놓고 또 후회하는 일이 자꾸만 생겼다. 이것까지 추가해서 넣었어야 했는데...!!

오늘 배운 것

• 그래서 준비한 git add, commit, push 되돌리는 방법 링크

• 예전 글이긴 하지만 깃허브, 비트버킷, 깃랩은 여러 차이점이 있다고 한다.