D'story

오늘 한 일

• 어제 오후부터 회원가입과 로그인 절차에 대한 전체적인 테스트를 (혼자) 해보고 있었는데, 퇴근 직전부터 회원가입 페이지에서 이메일을 입력하면 날아오는 인증메일이 발송되지 않았다. 회원가입 페이지를 완료한 지가 며칠이 지나서 그동안은 확인해볼 일이 없었는데 오랜만에 해보니 갑자기 안되는 것이었다. 메일은 오지도 않고 콘솔창에는 "Email address is not verified. The following identities failed the check in region US-EAST-1: id@email.address"라고 에러 메시지가 찍히는데 이것만 보고는 무슨 상황인지 이해할 길이 없었다. 구글링해봐도 다들 나와는 다른 상황인 것 같고 별로 참고할 만한 내용이 없었다. 무슨 에러인지 알고 나서야 뒤늦게 스택오버플로우에 있던 해결책이 보였다.
• 사용자 인증을 AWS cognito를 통해 처리하고 있다. cognito에서 인증메일을 보내는 방식은 cognito 자체에서 보내주는 디폴트 설정과 AWS SES를 통해서 보내는 설정, 두 가지 중 선택할 수 있다. 처음에는 디폴트 설정으로 진행했었는데, 그러면 발신 주소가 no-reply@verificationemail.com이라는 별로 예쁘지 않은 걸로 자동 설정된다. 이사님이 이걸 좀 더 보기 좋은 계정으로 바꾸려고 하셨는데, 이 FROM email address를 바꾸려면 반드시 디폴트가 아닌 AWS SES를 이용해야 하기 때문에 이 설정을 바꾸셨다.
• 디폴트로 설정을 돌려놓으면 다시 인증메일이 제대로 오기 시작하고, AWS SES만 선택하면 다시 에러가 떴다. 에러 메시지에 나온 것처럼 이메일 주소를 확인되게 하려면 AWS SES의 해당 리전에 접속해서 직접 처리해야 한다. 처리한 후에는 확인한 이메일 주소에 인증메일을 보낼 수 있게 된다.
• 하지만 여기서 문제: 회원가입을 하고 싶어하는 사용자가 입력하는 사용자의 이메일 주소인데, 그리고 이건 불특정 다수에게 발송될 메일인데, 이 메일을 받을 그 모두의 이메일 주소를 등록해야 한다고? 그럴 리가 없다.
• 이 문제의 근본적인 원인은, AWS SES를 처음 사용하면 계정이 샌드박스에 들어간다는 데 있었다. 누구에게 어떤 메일을 보낼지 알 수 없는 AWS 입장에서는 콘솔에서 인증 처리를 거치지 않은 이메일 주소에는 어떤 메일도 발송할 수 없게 제한해둔 것이었다. 물론, 메일을 보낼 발신자의 주소 역시 인증을 거쳐야 한다.
• 한 마디로, 인증메일에서 no-reply@verificationemail.com이 발신자 주소로 찍히는 게 보기 싫어서 이 주소를 바꾸고자 한다면 반드시 AWS SES에 연결하고 + AWS SES 계정을 샌드박스에서 나가게 해야 한다. 여기에까지 이르느라 시간을 얼마나 썼는지

오늘 배운 것

• 내가 맞닥뜨린 오류는 아래 링크에서 'Email address is not verified' 부분에 해당한다.

• '이메일 계정 구성' 또는 '사용자 풀에 대한 이메일 구성' 항목에서 2단계(Amazon SES 샌드박스에서 계정 이동)를 참고하면 좋다.

• AWS SES에서 메일 주소 확인 처리를 할 때 참고하면 좋다.

• 마지막으로, 이 모든 상황을 전부 파악하고 나서야 찾았던 스택오버플로우. 아는 만큼 보인다 했던가.

오늘까지 한 일

• 일이 엄청 많거나 너무 바쁜 건 아닌데, 그렇다고 하루하루 하는 일이 차근히 정리되고 있는 것 같진 않다. 사이트 개편 앞두고 일종의 마무리 작업 중이라서 그런 건지, 항상 느끼는 거지만 마치 깔끔하게 치워놓은 방이 어질러지듯이 처음엔 시작이 얼마나 정돈되었든 뒤로 갈수록 '일단 하고 본다'는 식의 임시방편성 코드가 많아지게 된다. 내 코드 내가 읽어도 정신이 하나도 없다.
• 하루종일 허둥대며 코드를 짜다 보면 퇴근하고 나서는 생산적인 일은 별로 하고 싶지 않다. 그래서 요 며칠 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를 이용한 멀티파트 업로드로 동영상을 업로드한 코드를 올려놓은 블로그. 멀티파트 업로드는 말 그대로 업로드 과정만 지원하기 때문에 파일은 업로드하기 전에 알아서 분할을 해야 하는데, 파일을 분할한다는 게 감이 잘 안 잡혀서 조금 헤맸었다. 파일 분할하는 부분이 특히 참고할 만했다.

오늘까지 한 일

• 금요일 퇴근하자마자 집에 다녀오느라 TIL도 남기지 못했다. 집에 갈 땐 가벼운 게 최고라며 노트북도 팽개치고 빈손으로 내갔다. 금요일 하루 빵꾸난 게 좀 아쉽지만 어쩌겠나, 뭐..
• 금요일에는 게시판 모듈은 어떤 기능을 더 넣어야 할 지 아직 확실하지 않아서 기본적인 부분만 마무리했다. 그러고 나서 시작한 건 로그인, 회원가입 페이지였다. 여기서부터는, 앞으로 얼마큼이나 변경사항이 있을지 모르지만 일단 현재 나와 있는 기획안에 맞춰서 작업하기로 했다. 프로젝트에서는 기획에도 직접 참여했는데 회사에서는 기획을 담당하는 다른 누군가가 그 프로세스를 맡아준다는 것 자체가 새롭다. 뷰가 기획안대로 짜여져 나갈 때의 쾌감이란.. 기능이 하나 둘씩 붙고 코드가 점점 복잡해질수록 매 순간 당황하게 되겠지만 지금으로서는 충분히 행복하다.
• 주말은 실컷 놀고 오늘 다시 서울로 돌아왔다. 동생이랑 이런저런 얘기를 하다가 갑작스럽게 프로젝트 하나를 하게 되어 버렸다(?!!) 코인이나 주식 투자에 관심이 많은 동생이 매수 최적 포인트를 찾기 위한 전략을 짰다는데(난 들어도 잘 모르겠고) 그 전략에 맞춘 프로그램이 필요한 상황이었다. 얘기를 들어보니 사실은 그 전략이라는 게 전부고 프로그램은 거들 뿐이라 아주 복잡하진 않을 것 같다. 일단 해봐야겠지만. 이거야말로 가내 수공업 아니고 프로젝트 아닌가ㅋㅋㅋ 암튼 재밌겠다 히히

오늘 한 일

• 어제 퇴근 전에 주어진 게시판 모듈 만들기 작업을 하고 있다. 해당 컴포넌트에 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로 받자...^^