D'story

오늘 한 일

• 팀원 두 분을 모시고 지금껏 해온 웹 프론트 작업에 대한 리뷰(라고 쓰고 발표라고 읽는다)의 시간을 가졌다. 프로젝트 폴더 구조를 어떻게 만들었는지, 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를 만지고 있었던 것 같다. 뭐.. 돌이켜 생각해보니 그렇다.
• 백엔드와의 첫 협업 프로젝트 때 이런 것들을 포함한 중요하거나 사소한 다양한 부분에서 각종 마찰, 잡음이 있었고 서로를 이해하느라 많은 대화가 필요했었다. 그 많은 대화의 시간들을 통해 우물을 벗어났다고 생각했는데, 고개를 들어보니 그저 더 큰 우물 안이다.

오늘 한 일

• 사용자가 파일을 첨부하면 해당 파일을 aws s3 버킷에 업로드하는 기능을 붙였다.
• 현재의 프로덕션 페이지에서는 파일을 첨부하면 즉시 s3에 들어가는데, 첨부한 파일이 사용자가 실제로 제출하기를 원치 않는 것이었다 할지라도 무조건 업로드 된다. 물론 오늘 구현한 기능도 첨부할 파일 목록에서 사용자가 삭제할 수 있는 것까지는 포함하지 않지만, 이것도 언젠가는 추가되어야 하지 않을까 추측해본다.
• 아무튼 이번에는 사용자가 파일을 첨부하면 파일 데이터를 리덕스에 저장해놨다가, 제출 버튼을 누르면 리덕스에 저장된 데이터를 이용해 그때서야 s3로 넘어가게 했다.

오늘 배운 것

• 오늘 하루종일 열심히 이용한 SDK란 무엇인가에 관한 링크

• AWS SDK for JavaScript 링크. 여기서 Uploading a file to an Amazon S3 bucket 항목을 참고했다.

오늘 한 일

• 어제 기껏 useRef 어쩌고 하며 TIL을 써놓은 게 무색하게, 오늘은 useRef를 적용한 모든 코드를 이벤트 핸들링으로 변경했다. 각 항목에 대한 입력을 마칠 때마다 그 값을 state에 저장하고 싶었기 때문이다. 어차피 서버에 넘길 때 또 가공해야 할 테니 객체에 key-value로 저장하는 게 나을 것 같았다. 이번에는 지금껏 자주 쓰던 onClick, onChange가 아닌, onBlur를 써 봤다. onBlur는 focus를 가졌다가 잃었을 때 작동하는 이벤트 핸들러다. (focus가 있었는데 없었습니다!?)
• 이벤트 핸들링 얘기가 나와서 말인데, 오전 내내 특정 div에 외부 파일을 드래그하면 div의 모양새(?)가 바뀌게 하는 작업에 매달려 있었다. 그때는 onDragOver를 썼었다. 근데 이게 DB에 있는 항목들을 배열로 받아 input에 넣어 나열하는 상황 때문인지, 파일이 드래그 오버되는 그 div에만 변화를 주는 게 쉽지 않았다. 어쩌면 그냥 내 머리가 안 돌아간 걸 수도 있고.

오늘 배운 것

• 지금 TIL 작성하면서 찾은 링크인데 진작 이게 있었어야 했다... onDragOver를 찾아 헤맨 과거의 나를 위해 첨부.

오늘 한 일

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

오늘 배운 것

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

오늘 한 일

• 본의 아니게 TIL도 주5일제가 되어가고 있다. 주말에 노는 거 너무 티나는데..!?
• Open door 회의가 있었다. 선이해 후기획, 이런 건 둘째치고 일단 다같이 붙어서 와이어프레임부터 그려보자, 하고 시작한 시간이었다. 피그마는 분명히 튜토리얼 공부를 했었는데 한동안 안 쓰다 보니 새까맣게 잊어버렸고, 단축키 같은 건 버려두고 가장 원시적인 방식으로 '막' 그려버렸다. 다른 분들이 기획과 관련해 열띤 토론을 진행하시는 동안 성미 급한 나는 일단 뭐라도 만들어보려는 생각에 이것저것 끄적여봤는데 칭찬을 해주셔서 매우 민망했다... 어쨌든 결과적으로 진전이 있었던 것 같아 마음이 편하다. 뭔가 되어가는 게 눈에 보여야 속이 시원한 한국인.