June

Today I Learned 날짜 2024년 6월 28일 금요일 내용 스프린트 계획 스프린트 계획이 완성됐고, 다음주부터 시작된다. 플래닝미팅을 위한 공수를 작성하다가 놓치고 있는 부분을 몇 개 알게 되었다. 브랜드는 진짜 브랜드가 아니었다. 관리자 계정에 엮여있는 여러 계정들 하나하나를 브랜드라고 불렀던 것이고, 계정 내에 있는 캠페인을 분류할 필요가 없었다. 따라서 브랜드 테이블은 필요가 없게 되었고 고민은 해결되었다. 구글 드라이브 디렉토리 정보를 저장할 필요가 없었다. 구글 드라이브 내에 폴더들을 가져와 데이터베이스에 저장하려고 했는데, 생각해보니 굳이..? 싶다. 그냥 하위폴더나 상위 폴더를 열때 그 디렉토리 정보를 가져오도록 구글에 보내는 요청을 만들 계획이다. 각 계정(위에서 말한 브랜드)가 어떤 템플릿과 로우데이터를 사용중인지 알고 있어야 한다. 그에 대한 테이블도 만들었다. 데이터 임포트 상태를 표시하기 위한 작업이 필요하다. 임포트가 진행되는동안 또 다른 요청이 발생하지 않도록 상태를 추적하기 위해, 임포트 로그를 위한 테이블이 필요하다. 3주간 레츠고 ...

Today I Learned 날짜 2024년 6월 27일 목요일 내용 네이버 검색광고 데이터와 DB 매일 아침 스프레드시트에 데이터를 집어넣는 근로자들을 해방시켜주는 스프린트를 준비중이다. 우선 기본적인 데이터베이스 틀을 잡고 있는데, 네이버 검색 광고가 어떤 구조로 되있는건지 모르겠다! 전문가인 태웅님께 하루 한번 과외를 받은 덕에 드디어 큰 틀을 알게 됐다. 우선 최상위 테이블을 User로 설정했다. 이 서비스의 핵심은 데이터를 구글 스프레드시트에 집어넣는 것이니 구글드라이브와 연동이 필요하다. GoogleDriveAccount 테이블이 그 정보를 저장한다. 현재 회원가입과 로그인은 구글을 통해서만 이루어지도록 해놨기 떄문에 구글 로그인을 위한 테이블을 따로 만들었다. 원래 유저 테이블에 집어넣는 경우도 있지만, 앞으로 지원하는 소셜 로그인이 늘어날떄 마다 최상단 테이블을 마이그레이션 하는 불상사를 겪지 않기 위해 별도의 테이블을 만들었다. 네이버, 틱톡, 메타가 추가될 때마다 테이블을 추가할 예정. ...

Today I Learned 날짜 2024년 6월 26일 수요일 내용 JWT 토큰 기존 알파플러스 서비스에서는 클라이언트가 보내는 요청을 따로 검증하지 않는다. 접근 자체가 일반적으로 쇼피파이에 로그인 한 후에 이루어 지는 이유도 있을 것이고, 애초에 로그인이 되면 로컬 세션에 jwt로 생성한 토큰이 저장되기 때문이다. 이 토큰이 없으면 프론트 쪽에서 어드민 페이지에서 내보낸다. 사실 직접 URL을 입력해서 접속할 수 있기 때문에 첫번째 이유는 무력화 될 수 있겠으나, 우리만 그렇고 대부분의 유저들은 쇼피파이 어드민을 통해 접근할 것이다. ...

날짜 2024년 6월 25일 화요일 내용 0 Unknown error 요청에 대한 응답에 있는 에러 메시지는 여러가지 정보가 담겨있다. 200번 대는 성공에 대한 status_code, 300번대는 redirect 관련이다. 400번대는 요청이 잘못된것, 500번대는 코드가 잘못되었을 떄 나타난다. 이번엔 0이다. 이메일로 리뷰를 요청했을 때 어떤 경우에 오류가 발생하고 있다. 아직 무엇이 문제인지 몰라 TIlL을 쓸 수 갇없다. 도대체 어떤 경우에 왜 발생하는건가… 해결하게 되면 새롭게 배우게 되는게 참 많아 따로 TIL로 작성해야겠다. 회고 뭔지 모를 오류의 원인을 찾느라 하루종일 헤매었다.. ...

Today I Learned 날짜 2024년 6월 24일 월요일 내용 네트워크문제 elastic apm상으로 자꾸 에러가 발생한다. 구체적인 내용은 이메일로 발송된 리뷰 요청으로 리뷰를 작성할 때 오류가 발생한다는 내용이다. 굉장히 성가신 오류라는게 문제다. 특정 시간대에 한 곳(스토어)에서 몰려서 발생한다. 발생하는 스토어가 무작위 데이터가 이상없음(아마) 뭐가 잘못되었는지 모르니 재연이 불가능하다. 로직을 아무리 들여다봐도 데이터상 이상이 없으니.. 발생하는 오류 코드는 0 Unknown Error 라서 찾아보니 네트워크 문제라는 이야기가 많았다. 혹시나 싶어 이것저것 뒤져봤는데 심상치 않은 내용이 있긴하다. ...

Today I Learned 날짜 2024년 6월 21일 금요일 내용 새로운 서비스와 가상환경 다음 스프린트로 아예 새로운 서비스를 만들게 됐다. 구글 워크스페이스 마켓플레이스에 출시할 앱이라 새롭게 서버를 파야했다. 기존에 만들어져 있는 것에 기능을 더하거나 고치는게 아니라 처음부터 싹 다 해야한다. 몇 달전, 우리 서비스가 어떻게 돌아가는지 이해가 안되서 혼자 해본적이 있는데 다행히 그 떄 도움이 많이 됐다. 따라할 수 있는 기본 코드도 있기도 하고… 기본적인 로컬 빌드 상태를 만들고 alembic, docker 까지는 설치해서 틀은 잡았다. ...

Today I Learned 날짜 2024년 6월 20일 목요일 내용 실서버 에러처리 실서버에서 이것저것 에러 알람이 또 뜨고있다. 첫번째는 웹훅으로 상품이 수정되었을 때 발생하는 것이고, 두번쨰는 이메일로 온 리뷰작성 요청을 통해 리뷰를 작성할 때 발생한다. 아예 기능이 안된다기보다는 종종 불규칙적으로 발생하는 문제였다. 리뷰 작성하는 부분은 워낙 어렵고 복잡하고 볼 게 많아 머리가 터질 것 같았다. 문득, 두 문제의 공통점을 알게 되었는데 shop을 못찾았음에도 불구하고 코드에서 감지하지 못해 진행하다가 발생한 문제라는 점이다. if not shop: 이라는 예외처리가 있는데도 건너 뛰어진다. elastic apm으로 구체적인 값을 살펴보면 분명 shop의 모든 값은 None으로 되어있다. ...

Today I Learned 날짜 2024년 6월 19일 수요일 내용 슈퍼어드민 우리가 고객사를 관리하는 사이트가 슈퍼어드민이다. 모든 고객의 알파리뷰 어드민에 접근할 수 있고 대략적인 정보도 볼 수 있다. 다만 여기엔 브라우즈 부스터 앱과 관련된 정보가 없어서 추가해야 했다. 만든지 상당히 오래됌 + 서비스 구조와는 사뭇 다름 문제가 겹쳐 머리 아팠다. 앱이 하나 추가되면서, 쇼핑몰을 나타내는 샵 테이블은 2개로 나누어졌다. 두 개를 조회해야 한다는 효율성 문제보다는, 두 테이블이 연관된 것이 다르다는게 자꾸 문제로 나타났다. 예를 들어, 알파 플러스 앱에선 온보딩 데이터가 닮긴 shop_initial_info 테이블이 있는 반면, 브라우즈 부스터에는 (필요도) 없다. 해당 쇼핑몰이 우리 서비스를 사용한 지속기간은 여기 있는 installed_at 이라는 필드를 참조해야 하는데 이 부분이 꽤 거슬렸다. 두 테이블이 필요한 값을 다른 테이블의 다른 필드에서 가져와야 했고 기존에 있던 함수들의 타입 힌팅이 계속 어긋났다. 무작정 함수를 나누기엔, 어디서 어떻게 또다른 오류가 발생할지 몰라 그럴 수 없었다. ...

Today I Learned 날짜 2024년 6월 18일 화요일 내용 오늘도 미비된 자잘자잘한 마무리들을 열심히 처리했다. 웹훅 쇼피파이에 앱을 출시하기 위해선, 쇼피파이에서 요구하는 웹훅을 처리해야 한다. 대표적으로 앱을 삭제하는 웹훅이 있는데, 어쩄든 여러 종류의 웹훅이 오면 알맞게 처리하는 기능은 만들어놨다. 사실 이번 앱은 테마와 관련된 데이터만 처리하기 때문에 고객정보나 주문정보를 위한 웹훅은 필요없어 쉬웠다. 그런데 앱을 삭제해도 데이터가 사라지지 않았다. 열심히 테스트를 해봐도 요청 자체가 날라오지 않아 어디서 뭐가 잘못됐는지 알 수가 없었다. 기존에 있는 다른 앱들의 코드를 살펴보니 애초에 웹훅을 내가 만들어 줬어야 했다.. 난 쇼피파이에서 알아서 해주는 줄 알았지.. 샵을 설치할 떄 필요한 웹훅을 설치해주는 함수를 추가했더니 잘된다. ...

Today I Learned 날짜 2024년 6월 17일 월요일 내용 스프린트 마무리 인스타그램에서 댓글을 가져오는 기능을 마무리했다. 물론 QA가 남긴했으나.. 이것저것 마무리가 필요한 부분을 PRD를 다시 보면서 고쳤다. 게시된 댓글 저장 : 계정 연동을 해지하더라도 게시된 댓글은 냅둬야 했다. 따라서 기존처럼 샵의 하위 테이블을 모두 삭제하는 대신, 미게시된 댓글만 삭제하도록 했다. 단, 다시 가져올때 그 스토어의 그 댓글이 기존 테이블에 존재하는지 중복검사를 추가했다. 앱 메타필드 업데이트 각 데이터들이 변동될 때마다 앱 메타필드에도 업로드 되도록 기능을 추가했다. 메타필드는 일부 수정은 안되고 항상 덮어쓰기 형식으로 처리된다. 따라서 매번 위젯에서 사용하는 자바스크립트와 스타일 파일은 별도의 key로 두었다. 데이터가 자주 변경되는 것은 댓글이나 위젯 옵션들이 포함된 템플릿 부분이라 이 부분만 별도의 key로 설정했다. ...