2024

Today I Learned 날짜 2024년 4월 19일 금요일 내용 혁명적으로 힘든 하루였다. 변수 통일 어제 말한대로, 잘못된 변수명을 모두 통일했다. 메일과 관련된 부분이고, 특히 우리 서비스의 가장 핵심적인 부분인 리뷰 작성에 대한 메일발송을 처리하는 부분이기 때문에 기존 기능에 문제가 생겨선 안된다. 그래서 일일이 모두 테스트해서 정상작동하는지 확인해야 했다. 웹훅을 이용해 로컬에서 주문 데이터를 생성하고 메일을 보내기 위한 메시징로그가 어떻게 처리되는지 확인했다. 이 과정에서 리뷰 작성을 유도하는 메일 시스템이 어떻게 진행되는지 더 잘 알 수 있었다. 우선 상품이 주문되어 Lineitem 데이터가 생성되면, 고객이 활성화한 모든 메일의 메시징 로그가 생성된다. First Review Request부터 Logn term Review Request까지. 하지만 First Review 요청을 제외하곤 target_datetime은 값이 비어있어 전송되지 않는다. 이후 배송처리(fullfill)되면 나머지 메시징로그들에도 고객이 설정한 것에 맞게 target_datetime 들이 설정된다. 이후 주기적으로 크론이 작동하며 보내야할 메시지를 보내는 로직이다. ...

Today I Learned 날짜 2024년 4월 18일 목요일 내용 이메일 레거시 코드 개선 이메일 보내는 로직이 2개로 나누어져있다. 하나는 message_sender로 클래스로 구현되어있고, 다른 쪽은 템플릿 만드는 함수, 데이터 처리하는 함수, 전송하는 함수가 구현되어있다. 클래스에는 이 함수들이 메서드로 구현되어 있는 형태인데 추상 패턴이라 이메일 뿐만 아니라 웹 푸시, SMS 전송에도 사용할 수 있다. 따라서 모든 이메일 전송은 전자의 클래스를 사용하도록 개선해야 한다. 단순히 사용 함수를 바꾼다고 해결할 문제는 아닌게, 받는 변수와 처리 로직이 다르다. 전송 클래스는 변수로 messaging_log 테이블의 레코드를 받게 되는데 누구에게 어떤 이유로 어떤 형식의 메일을 보냈는지가 기록되는 테이블이다. 이 테이블에 기록을 남기는 메일은 프로덕트 리뷰 서비스로 발생하는 것들만 포함된다. 첫 리뷰 요청 메일이라던가, 장기간 사용 리뷰 요청 등등 정책에 의해 메일이 전송되어야 할 경우, 해당 메일 전송을 예약하기 위해 전송 대기 상태로 저장해둔다. 1달 후 보내져야 할 메일은 그 시간이 기록된 채로 테이블에 저장되고, 어떤 타입의 메일들은 저장된 즉시 처리되어 전송완료 상태로 변경된다. ...

Today I Learned 날짜 2024년 4월 17일 수요일 내용 건강 이슈로 오전 반차. 이메일 템플릿3 나름 열심히 만드는데 여기저기 구멍이 숭숭 뚫려있다. 엑박이 뜬다던가, 버튼 크기가 개판이던가, 임의로 줄바꿈을 집어넣어서 모양이 개판이던가… 테스트를 안하는 것도 아니고, 분명 휴대폰으로도 확인하고 큰 모니터로도 확인하는데 왜 내 눈엔 안보일까. 철두철미한 자체 QA 가 필요하다. 한번에 OK 받도록 만들 것. 회고 그래도 끝이 보임.

Today I Learned 날짜 2024년 4월 16일 화요일 내용 건강 이슈로 오후 반차. 리스트 디자이너 개선 지난 스프린트(정확히는 그 이전)였던 리스트 디자이너 개선작업을 진행했다. 백엔드 쪽에선 크게 변경될 부분은 없었다. 기존에 위젯을 설정하는 화면에서 미리보기 기능이 백엔드에게 지속적으로 요청을 보내도록 구현해놨었는데, 이 부분을 프론트에서 처리하도록 수정해서 사용성이 훨씬 개선됐다(물론 내가 안함). 미리보기를 위해 구현해놓은 코드를 다 지웠다. 시-원 이메일 템플릿2 이메일 CSS를 계속 작업하면서, 우선 발송 로직을 구현했다. 웰컴 메일은 계정 생성시에 추가해두었고 각 서비스 개시 메일은 고객 정보를 업데이트 하는 부분에 가져다뒀다. 서비스에 가입했지만 세 가지 서비스(리뷰, AI, 리스트 디자이너) 모두 활성화하지 않은 유저에게는 1일 후 메일을 보내도록 구현했다. 몇달 전에 처음 태스크를 맡을 때 메일 보내는 함수를 설정했었다. 이때 스토어의 현지 시간을 변환하고 발송 시간대(오전 8시30분~ 9시 30분 사이)인지 체크하는 함수를 따로 만들어두었는데, 두고두고 요긴하게 쓰이니 나름 뿌듯하다. ...

Today I Learned 날짜 2024년 4월 15일 월요일 내용 나는 이메일 템플릿 만드는 기계다. 오늘 하루에만 무려 4개의 템플릿을 만들었다. 이정도면 스스로를 템플릿 공장이라고 불러도 될까? 물론 택도 없다. 개선해야 할 부분이 있기 때문이다. 공통 footer를 따로 처리하지 않았다. 모든 이메일 템플릿이 동일한 footer를 적용하는데 다 복붙했다. 별도의 html로 만들고 include 했어야 했는데.. 그러지 못한 이유는 footer를 포함하여 템플릿 전체를 하나의 table로 처리했기 때문이다. 시간이 허락한다면 분리 작업을 해야겠다. padding을 사용하지 않았다. 그동안 나름 터득한 방법은 여백이나 줄 간격, padding을 테이블의 한 요소(행 또는 열)로 처리하는 것이었다. 이에 대한 설명은 2월 16일 TIL을 참고하자. 어쩄든, 기존에 작성된 이메일 템플릿은 이 경우를 테이블의 열을 나타내는 td 에 style로 padding-left, padding-top등을 먹이는 방식이었다. 시간이 허락한다면 고쳐야겠다. 회고 하지만 시간은 쉽게 허락해주지 않음. ...

Today I Learned 날짜 2024년 4월 12일 금요일 내용 고객의 서비스 활성화 확인을 끝마치고, 사용자 이메일 개선작업을 시작했다. 이 Task 자체는 이메일 템플릿을 만드는 거라 난이도 자체가 어렵진 않다. 상당하 귀찮고 성가실 뿐.. 대신 이 작업이 끝나고 전반적인 이메일 관련 레거시 코드를 처리해야 하는 부분이 꽤 클 듯하다. 회고 라라스윗 팥모나카 맛을 먹었다. 팥으로 만든 하모니카 모양이라 팥모니카 인 줄 알았는데 모나카였다. 디저트 이름이라고 한다. 잘 배웠습니다!

Today I Learned 날짜 2024년 4월 9일 화요일 내용 고객들의 기능 활성화 여부를 체크하는 기능을 만들었다. 코어스크립트 고객이 위젯을 스토어에 설치하기 위해선, “코어 스크립트”를 활성화 해야한다. 위젯이 정상적으로 작동하도로록 해준다. 우리 서비스에서 위젯은 핵심적인 부분이기 떄문에 코어스크립트가 활성화되어 있지 않다는 의미는 우리 서비스를 제대로 활용하지 못하는 뜻이다. 각 서비스(알파리뷰, 리스트 디자이너)는 제각각 코어스크립트를 가지는데 이를 활성화했는지를 알아봐야한다. 스토어가 사용하고 있는 메인 테마를 찾아야 한다. Shopify로 요청을 보내면 된다. 이렇게 목록들이 나타나니 원하는 값을 찾으면 된다. 한번도 활성화한 적이 없는 항목은 나타나지 않는다. 따라서 없거나, “disabled”가 true일 떄가 비활성화인 상태다. ...

Today I Learned 날짜 2024년 4월 8일 월요일 내용 아마존에서 리뷰를 Import하는 기능을 열심히 고쳤다. 이미지를 사이즈별로 저장하기 2주 전 금요일이였나? 급하게 이슈 관리가 발생했었다. 아마존에서 리뷰를 가져올 때, 이미지를 사이즈 별로 원본, 중간 크기, 작은 크기, 썸네일 별 링크로 저장한다. 원본과 썸네일을 제외한 사이즈 사진이 나타나지 않았던 문제였다. 이미지의 사이즈는 파일명 가장 뒤에 숫자를 이용해 조절한다. 아마존에 있는 사진의 파일명 가장 끝은 “_SY” 가 붙어있는 형식인데 이 뒤에 숫자에 따라 크기가 조절된다. 예를 들어, 썸네일은 {파일명_SY88.jpg}, 중간 크기는 {파일명_SY300.jpg} 로 저장하면 된다. 문제가 되었던 사진은 “_SY”가 없이 숫자만 저장되어, 사진을 찾을 수 없다는 오류를 출력하고 있었다. ...

Today I Learned 날짜 2024년 4월 5일 금요일 내용 개발보단, 팀이 나아갈 방향에 대해 하루종일 고민했다. 리퀴드 쇼피파이에서는 리퀴드를 쓴다. 리퀴드는 루비를 기반으로한 HTML 템플릿 언어이다. 쇼피파이에 올라간 데이터들을 주고 받는게 Liquid로 작성된 앱블록에서 이루어지는데, 정말 놀랍게도 Shopify 정책상 1개의 앱이 사용할 수 있는 앱블록의 총 용량은 고작 100KB로 정해져있다. WOW 그리고 수 많은 위젯을 구현한 우리 서비스는 한계에 봉착했다. 더이상 여유 용량이 없다. 해결을 위한 여러 고민들을 더 자세히 쓰고 싶은데, 들은걸 100% 이해하지 못해서 못쓰곘다! 결론은, 새로운 앱을 만들되, 서버와 DB는 같이 쓰고, 어드민 페이지도 하나로 유지하기로 했다. 별개의 앱 사용자들이 하나의 서버와 어드민으로 들어오기 떄문에 이에 대한 여러 장치가 필요하다. 그리고 앱을 출시하는 과정 자체에 대한 공수도 필요하고.. 자연스레 할 일이 많아졌다! ...

Today I Learned 날짜 2024년 4월 4일 목요일 내용 고객 체크 계속 고민했던대로, 고객에 대한 데이터를 얻기 위해 수정이 필요했다. 다른쪽에서도 비슷한 결의 문제가 발생했는데, 프론트에서 유저가 받아야 할 쿠폰이 무엇인지 알 수 없었다. 쿠폰을 받기위한 이벤트의 진행 과정은 프론트에서 개별적으로 발생하는 반면, 쿠폰은 서버에서만 처리하니 둘의 싱크가 안맞아서 발생하는 문제 같았다. 결국 쿠폰을 발급할 때, 고객이 로그인하도록 과정을 추가해야 했다. 테스트 코드 약 2시간을 투자해서 테스트 코드를 작성했다. 무려 몇개월 전에 만들었던 AI 관련된 기능들에 대해서 작성했다. 리뷰의 키워드를 분석하고 횟수를 계산하는 것, 긍정과 부정을 분류하는 것, 요약을 만드는 것 3가지를 만들어주었다. ...