Google Analytics 도입: 코드보다 처리방침에서 먼저 막힌 이유
Google Analytics를 붙이는 코드를 다 짜고, 배포 직전에 개인정보 처리방침을 열었습니다. 이 문장이 있었습니다.
Google Analytics를 붙이는 코드를 다 짜고, 배포 직전에 개인정보 처리방침을 열었습니다. 이 문장이 있었습니다.
방문 분석은 하고 싶은데 쿠키 동의 팝업은 만들기 싫었습니다. 배너를 하나 붙이면 화면에 층이 하나 더 생기고, 동의 상태를 저장하고 갱신하고 철회까지 받는 코드가 따라옵니다. 방문자가 하루 수십 명인 회사 사이트에 그만한 장치를 두는 것은 과합니다.
로컬에 둔 영업 DB 가 원본보다 뒤처져 있었습니다. 리드가 254건인데 원본은 282건이었습니다. 활동 기록은 171건 대 281건으로 더 벌어져 있었습니다.
앞 글에서 Fargate + RDS + ALB + NAT로 짠 교과서 구성을 뜯어봤습니다. ALB와 NAT Gateway를 빼면 요금이 절반 아래로 떨어진다는 것까지 봤습니다.
AWS 비용 대시보드를 열었는데 NAT Gateway가 Fargate보다 비싼 경우가 있습니다. 앱을 돌리는 값보다 앱이 인터넷으로 나가는 통로 값이 더 나가는 겁니다. 트래픽이 거의 없는 서비스에서도 그렇습니다.
운영 데이터베이스를 Supabase에서 PlanetScale Postgres로 옮겼습니다. 옮기고 나서 사이트가 조금 굼떠진 것 같았습니다. 클라우드를 건너뛰게 됐으니 그 대가겠거니 생각했는데, 재보니 아니었습니다. 원인은 이관과 상관없이 원래 있던 커넥션 풀 설정이었고, 그것도 제 첫 측정으로는 보이지 않았습니다.
테이블에서 100만 행을 지웠습니다. DELETE는 성공했고 SELECT count()는 0을 돌려줍니다.
성경 지도 앱에 언어 다섯 개를 더했습니다. 영어, 일본어, 중국어 간체와 번체, 스페인어입니다. 화면이 하나뿐이고 서버도 없는 앱이라 붙이는 일 자체는 간단할 줄 알았는데, 번역문을 어디에 둘지에서 막혔습니다.
같은 요청을 두 번 보냈습니다.
애플리케이션에서 메일을 자동으로 보내려고 발송 전용 도메인을 하나 세웠습니다. DNS 레코드를 넣고 인증을 붙이는 작업 자체는 30분쯤 걸렸습니다. 나머지 세 시간은 전부 다른 데서 썼습니다.