Today I Learned 날짜 2024년 5월 2일 목요일 내용 실수 처리 몇가지 실수를 뿌려놓은게 있어서 열심히 메꾸었다. 가장 먼저, 코어스크립트와 앱블록을 활성화한 유저들을 탐색하는 기능을 고쳤다. 당연히 Dict 일거라 생각하고 처리한 부분에서, 뜬금없이 문자열이 튀어나와 오류가 나고있었다. if not isinstance(settings_data, dict): 를 추가해서 해결했다. 스프레드시트에 데이터가 올바르게 들어가지 않고 있었다. 각 유저들이 앱을 사용하는 상황을 저장하는 방식을 바꾸었는데 이 로직의 코드는 변경하지 않아 작동하지 않는 문제였다. 지난주 이메일 레거시 코드를 개선하고 테스트 하는 과정에서 수신 주소를 내 개인 메일로 바꾸어놨는데, 이 부분을 복구하지 않고 실서버 까지 올라가버렸다.. VOC가 나한테 와서 상당히 당황스러웠다. 메일 주소 바꾸는건 어렵지 않았지만 문제는 템플릿이 렌더링되지 않는 것이었다. ...
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년 2월 20일 화요일 내용 유지 보수 종료 유지 보수 스프린트가 종료됐다. 이전에 AI 서비스를 만드는 스프린트와 다음에 진행될 것의 사이에서 이전에 부족하거나 고쳐야 할 부분을 다듬었다. 개인적인 욕심으로는, AI 때 만든 기능들에 대한 테스트 코드를 추가하고 싶었는데 미루길 반복하다 시간이 부족해서 못했다. 주어진 시간이 없다기 보단, 내가 AI 시작하기 전에 완성했어야 했지만 그러지 못한 것들에 낭비된 시간, 이메일 CSS 한다고 날린 시간이 크다. 개인적으로 시간을 들여서라도 좀 만들어놔야겠다. ...
Today I Learned 날짜 2024년 2월 16일 금요일 내용 Email Template를 깨달은 남자 난 더이상 Email에 담을 HTML을 만드는 게 두렵지 않다. 깨달아버렸기 때문이다. 2가지 과정에서 깨달음이 있었다. Div가 아닌 Table 이메일 서버가 HTML을 출력할 때 의도하지 않게 해석하는 경우가 많다. <head> 나 <body>를 읽지 않는 경우도 많고 <div>를 제대로 처리하지 않아 padding이나 margin이 엉망이 되기도 한다. 검색해보면 가장 많이 나오는 말은 <table>, <tr>, <td> 태그를 사용하라는 것. 이 태그는 테이블을 만드는데 사용되는데, tr은 table row의 약자로 행을 의미하고 td는 table data로 행 내에 들어갈 정보를 의미한다. 사실 가로(열)로 이해해도 무방하다. ...
Today I Learned 날짜 2024년 2월 15일 목요일 내용 앱을 삭제한 스토어의 데이터에 접근하는 법 은 없었다. Shopify partner에게 답변이 왔는데, webhook 시그널의 전달과 access token 무효화는 비동기적으로 발생해서 접근할 수 없다고 한다. 당장은 방법이 없어, 우리 서버 내 데이터만 삭제하는 걸로 Task를 종료했다. 아름다운 사람은 머문 자리도 아름답다는 누군가의 말처럼, 우리가 삭제된 이후에 우리의 흔적을 남기지 않도록 하고 싶은데 마땅한 방법이 떠오르지 않는다. 앱을 삭제하는건 Shopify 쪽에서 발생하는 일이라 우리가 제어할 수 있는 방법이 없다. 미래를 볼 순 없는 노릇이니 삭제할 만한 shop을 고를 수도 없고.. 삭제 이후에는 재설치하지 않는 한 access_token을 얻을 수 없는데 어찌해야 할까.. 짱구좀 굴려봐야겠다. ...
2.3 인터넷 전자메일 인터넷 메일 시스템의 상위 요소에는 다음 3가지가 있다. 사용자 에이전트(user agent) 사용자의 메시지 읽기, 전달, 저장, 구성을 담당 ex) 지메일, 마이크로소프트 아웃룩, 스파트몬용 지메일 앱 메일 서버(mail server) 각 수신자는 메일 서버 안에 **메일박스(mailbox)**를 갖고 있다. 메일박스는 수신한 메시지를 유지하고 관리한다. 송신자의 사용자 에이전트 → 송신자의 메일 서버 → 송신자의 메일 서버의 메시지 큐 → 수신자의 메일서버 → 수신자의 메일 서버 내 메일박스 수신자의 서버 고장으로 전달할 수 없으면 메시지를 **메시지 큐(message queue)**에 보관하고 나중에 전달을 재시도한다. SMTP(Simple Mail Transfer Protocol) 인터넷 전자메일을 위한 주요 애플리케이션 계층 프로토콜 TCP의 신뢰적인 데이터 전송 서비스를 이용 송신자의 메일 서버에서 수행하는 클라이언트와 수신자 메일 서버에서 수행되는 서버를 갖고 있음. 메일 서버가 송신할 때 : SMTP의 클라이언트로 동작 메일 서버가 수신할 때 : SMTP의 서버로 동작 2.3.1 SMTP A가 B에게 메일을 보내는 과정 A는 네이버의 전자메일 사용자 에이전트에게 B의 전자메일 주소(B@gmail.com)를 제공하고 메시지를 작성하여 메시지를 보내라고 명령한다. A의 사용자 에이전트(네이버)는 메시지를 A의 메일 서버에게 보내고 그 메시지는 서버에서 메시지 큐에 들어간다. A의 메일 서버에서 동작하는 SMTP의 클라이언트 측은 메시지 큐에서 메시지를 확인한다. 이후 B의 메일 서버에서 수행되는 SMTP 서버에게 TCP 연결을 설정한다. 이때 포트는 25. 초기 SMTP 핸드셰이킹 이후에 SMTP 클라이언트는 A의 메시지를 TCP 연결로 보낸다. B의 메일 서버 호스트에서 SMTP의 서버 측은 메시지를 수신한다. 이 메시지는 B의 메일 서버의 메일박스에 저장된다. B은 사용자 에이전트를 이용해 그 메시지를 읽는다. A와 B의 메일 서버가 물리적으로 거리가 멀더라도, 중간 메일 서버는 사용하지 않는다. 따라서 B의 서버가 죽어 있으면 전달하지 못한다. 이 떄, A 서버의 메시지 큐에 두고 지속적으로 재발송한다. 일정시간이 지나면, 폐기하고 A에게 발송이 실패했음을 알린다. 두 서버의 TCP 연결이 설정되면, SMTP의 서버와 클라이언트는 애플리케이션 계층 핸드셰이킹을 수행한다. 핸드셰이킹에서 서로에 대한 정보를 알게 되는 것처럼, 이때 클라이언트는 서버에게 두 사람(송신자와 수신자)의 전자메일 주소를 제공한다. 2.3.2 메일 메시지 포맷 우편을 보낼때, 편지 봉투에는 여러 정보가 담기게 된다(발신자, 수신자 등) 전자 메일에서는 메시지 몸체 앞에 있는 헤더에 담긴다. 2.3.3 메일 접속 프로토콜 메일 서버가 개인의 로컬호스트에 있다면, 항상 메일을 받기 위해 서버가 켜져있어야 한다. 따라서, 일반 사용자는 로컬 호스트에서 사용자 에이전트를 수행하고 늘 켜져 있는 공유 메일 서버에 저장된 메일박스에 접근한다. 즉, 메일 서버는 보통 사용자들과 공유한다. 송신자의 사용자 에이전트는 메일 서버를 통해 수신자의 메일 서버로 메시지를 전송한다. 왜 송신자의 사용자 에이전트가 직접 수신자의 메일 서버로 메시지를 전송하지 않을까? 송신자의 사용자 에이전트는 수신자의 메일 서버에 도달할 수 없기 때문 이유는 보안 문제, SMTP의 규약, 스팸 방지, 신뢰성 보장 등 다양하다. 수신자의 사용자 에이전트는 받은 메시지를 보기 위해 SMTP를 사용할 수 없다. SMTP는 push지만 메시지는 pull 해야 하기 때문 메시지를 받는 방법 HTTP를 통해 요청 인터넷 메일 접근 프로토콜(Internet Mail Access Protocol, IMAP) 사용 이 둘 모두 메일 서버에 의해 유지되는 폴더를 관리하게 된다.
Today I Learn 날짜 2024년 1월 11일 목요일 내용 하루종일 코드보단 AWS 설정만 건드렸다. DMARC Shopify에서 메일이 왔다. Gmail과 Yahoo에서 DMARC에 관한 정책이 바뀌었다는 내용이다. 우리가 커스텀 도메인을 사용하기 위해, 이 정책에 맞게 DMARC를 추가해주어야 한다. 아니면, 2월부터는 Shopify 쪽에서 제공하는 계정으로 발송처리 된다. 고객들이 알파리뷰가 보낸 메일임을 알 수 있도록 커스텀 메일주소를 계속 유지시켜야 한다. DMARC(Domain-based Message Authentication, Reporting and Conformance)는 이메일 인증 프로토콜이다. 이메일 도메인 소유자가 이메일 스푸핑으로 알려진 무단 사용에서 도메인을 보호할 수 있도록 설계되었다. DMARC의 구현 목적은 비즈니스 이메일 공격, 피싱 이메일, 이메일 사기 등 사이버 위협 행위에 도메인이 이용되지 않게 보호한다. <위키백과> ...
Today I learned 날짜 2024년 1월 2일 요일 내용 올해 첫 업무 시작. Email CSS 고객에게 발송할 이메일 양식 HTML 의 CSS를 계속 진행하고 있다. 위아래에 margin이 적용되지 않았다. 구글링 결과, 플랫폼이나 브라우저 마다 Email Template 렌더링이 제각각이라는 말이 많았고 특히 부모의position 을 relative 로 두고 자식을 absolute 로 두었을 때 위치가 적용되는지에 대해 너무 의견이 분분했다. 나는 템플릿을 table로 구성해두었는데, table의 위치에 margin 을 적용하지 않고 빈 셀 하나를 추가해주는 방식으로 구현했다. ...
Today I Learned 날짜 2023년 12월 14일 수요일 내용 데모버전 어드민 페이지 생성과 관련된 PR의 머지를 기다리던 중, 새로운 Task를 받아 파악하고 있었다. Notification Email Activation 문제 인지 우리 서비스에선 소비자에게 보내는 메일이 다양한데, 이 중 하나가 무언가 통지하는 이메일이다. 3가지로 분류되는데, 회원이 아닌 사람이 작성한 리뷰에 인증(Verification)을 요구하기 위해 보내는 메일이 그 중 하나이다. 다른 2가지와는 다르게 이 기능에만 활성화(activation) 조절 기능이 없는 상황이라 만들어야 한다. 여기에, 활성화 조절 시 현재 발송될 예정인 메일들에 대한 조치를 묻는 과정도 추가해야 한다. ...