Today I Learned 날짜 2024년 11월 6일 수요일 내용 손님받아라! 하루에 20개의 고객 데이터가 추가된다! 이렇게 반응이 즉각적으로 이루어지는 건 진짜 처음이라, 문제 없이 잘 돌아가는지 하루종일 열심히 살폈다. 그 덕분인지 대참사가 터질뻔한걸 빠르게 캐치할 수 있었다. 엄격한 AI 인스타그램에 작성된 댓글을 이미지로 만드는데 선별하는 AI가 너무 엄격했다. 우리 서비스에 가입한 스토어들의 인스타그램 계정에는 댓글들이 그렇게 많지 않았다.. 적게는 게시글마다 1~2개 씩 총 20개 정도 되는 스토어들이 많았다. 이런 곳은 비록 그 댓글이 우리가 기획할 때 설정한 목표와 적확하게 일치하지 않더라도 이미지로 처리되길 바라지 않을까? 그리고 실제로 내용도 충분히 올라갈법 했다. ...

Today I Learned 날짜 2024년 11월 5일 화요일 내용 네이버 커머스 솔루션 진출! 하자마자 오류가 나버렸다! 오늘 오전 검수가 완료되고, 손님들이 물밀듯이 밀려들어온다. 무려 오늘 업무시간에만 13팀이나… 그런데 2개 정도의 스토어에서 오류가 난다. 가입시 네이버에서 상품정보를 불러와 저장하는데, 이미 존재하는 ID라고 뜬다. 분명 네이버에서 origin_product_no 라는 값을 받아 저장하는데… 데이터베이스를 확인해보니 그 스토어의 상품은 그 어떤것도 저장되지 않았다. 실제로는 400개가 넘게 있어야하는데도 말이다. 네이버에서 데이터를 받아와 확인해보니, 실제로 origin_product_no 가 동일한 상품이 2개씩 있는 경우가 있었다. 이들은 다 똑같은데, channel_product_no가 달랐다. 아니 상식적으로 origin이 들어가는게 달라야 정상 아닌가? 긴급하게 수정해서, 가입한 스토어들의 상품 데이터를 다시 싹다 받아왔다. 오픈 첫날부터 큰일날뻔 했다. ...

Today I Learned 날짜 2024년 11월 4일 월요일 내용 전환값이 두배! 전환 관련 데이터들의 오차를 해결중이다. 어떤 경우에는 실제 값보다 적고, 어떤 경우에는 실제 값보다 많다. 한마디로 엉망진창. 심지어 누락되는 경우도 있다. 혹시나 해서 살펴보니, 역시나 일부 키워드가 데이터베이스에 저장되어 있지 않은 경우였다. 캠페인과 광고그룹은 없을 경우 네이버에서 받아오도록 해놨는데 키워드는 안해놨더니.. 누락되는 부분은 없앴는데 이젠 전환 데이터가 정확히 2배가 들어온다. 한참을 찾은 끝에 원인을 찾았는데, 필요한 보고서를 생성한다. 현재 생성되어 있는 모든 보고서를 다운로드받는다. 라는 로직에서 발생한 문제였다. 네이버에선 보고서를 최대 100개 까지 동시에 저장할 수 있었다. 그래서 난 그동안 보고서를 딱 100개씩 만들어서 다운로드받았다. 그 이상 보고서를 생성하면 자동으로 가장 오래된 보고서가 삭제되는 방식이라… ...

Today I Learned 날짜 2024년 11월 1일 금요일 내용 드라이브 왜 안보여줌 데이터 오차 문제 뿐만 아니라, 아임리포트 테스트 중 발견한 여러 티켓들을 처리하는 중이다. 유저는 구글 드라이브를 조회해서 스프레드시트를 추가할 곳을 선택할 수 있는데, 이게 안먹혔다. 테스트서버에선 분명 되는데… 드디어 진상 규명에 성공했다. 구글 드라이브에서 파일들을 가져오기 위해선 https://www.googleapis.com/auth/drive https://www.googleapis.com/auth/drive.readonly 둘 중 하나가 필요하다. 파일들을 불러오고, 메타데이터를 조회해서 스프레드시트인지 폴더인지 다른 파일인지 확인해서 유저에게 보여준다. 처음에 이 권한을 추가했었으나, 구글이 검수 과정에서 빼는걸 권유해서 뻇다. 그 이후로 안되고 있던 것이었다. ...

Today I Learned 날짜 2024년 10월 31일 목요일 내용 누구나 알아볼 수 있는 코드 아임리포트를 떠나보내기 위한 나름의 작업을 착수했다. 그동안 동작하게만 만드느라 함수 이름, 파일 이름등을 개판쳐놨기 떄문이다. 열심히 문서작업도 해놨지만.. 그래도 코드를 보고 어디가 어딘지 쯤은 알 수 있게 해놔야 하지 않을까? 몇가지 규칙을 세워서 정리를 좀 했다. 사용하지 않는 것은 무조건 삭제한다. 데이터베이스에 접근하는 코드는 crud.py 에 다 모아둔다. 함수 이름은 길더라도 뭘 하는지 표현하도록 만든다. 함수 내용이 길면 각주로 어디서 어떤 짓을 하는지 써놓는다. 예외를 작성한 부분은 그 이유를 각주로 써놓는다. 정리하면서 느낀건.. 정말 코드 더럽게 써놨다. 단 한글자도 빠짐없이 내가 쓴 코드인데도 구조를 파악하기가 힘들었다… process 라는 표현이 드럽게 많고, 추상 클래스를 사용했는데 반복 코드가 한가득이였다. 게다가 중간에 의미 없는 과정이 괜히 들어가 있기도하고… 그때그떄 바로 다음 로직만 보면서 만들다보니 길이 S자로 만들어진 듯 했다. ...

Today I Learned 날짜 2024년 10월 30일 수요일 내용 또이터 오차 또 데이터에 오차가 있다는 이야기를 듣고, 아임리포트 수리에 들어갔다. 실제로 다운로드 받아서 추려낸 데이터와 비교헀을 떄, 각 날짜보다 실제 나와야할 값보다 적은 값들이 찍혀있었다. 각 날짜는 모든 캠페인이나 광고그룹이 가지는 값의 합을 의미하니 어떤 캠페인이나 광고그룹이 누락되지 않았을까 싶어 뒤져보니 몇 개의 광고그룹이 시트에 포함되지 않아있었다. 예전에는 키워드 문제로 발생한 오류 떄문에 들어오지 않는 유형의 캠페인들이 있었으나 이번에는 불규칙했다. ...

Today I Learned 날짜 2024년 10월 29일 화요일 내용 VS코드 검색 제외 개인적으로 각 서비스마다 가상환경을 만들어서 패키지나 인터프리터 설정을 열심히 관리하고 있다. 아임리포트 작업 중, 로깅문을 로거로 설정하는 과정에서 대참사가 발생했다… 검색 기능에서 logging을 찾았는데 수천 개가 떴다. 원인은 가상환경의 패키지를 관리하는 lib 폴더 내에 것들도 검색됐기 떄문이다. logging이야 워낙 기본적으로 많이 쓰이니까 당연한거긴 한데.. lib 내의 패키지 관련 코드들은 건드리면 안되지만.. 실수로 싹 다 바꿨다. 다시 logger를 logging으로 싹다 바꿀수도 없는게, 내가 바꿔서 logger가 된건지 원래 logger였는지 수천 개를 구분할 수 가 없다.. 어쩔수 없이 가상환경을 싹 밀어버리고 다시 설치했다. ...

Today I Learned 날짜 2024년 10월 28일 월요일 내용 cherry-pick 드디어 네이버 커머스 솔루션 서비스를 실서버 배포했다. 아직 심사 전이라 고객은 없긴하지만… 이전에 실서버 운영 관련해서 인수인계를 받을때 실서버 배포 후 처리해야할 것들(환경 변수, 커맨드, 크론 등등)을 미리 적어놓으라고, 정신없어서 까먹는다고 들었었는데 어느샌가 잘 안하고 있었다. 사실 실서버 배포후 하는 일은 거진 비슷하긴 해서.. 커맨드는 거의 안돌리고 크론작업 추가하거나 환경변수 새로 업로드 하는 정도? 물론 그러다가 피 볼 뻔한 일이 한 번 있긴 했어서 이번엔 슨배임께 배운대로 했다. 이번엔 페이스북 앱 설정, 네이버 커머스 솔루션 설정 등 할게 산더미지만 깔쌈하게 처리했다. ...

Today I Learned 날짜 2024년 10월 25일 금요일 내용 천 번의 오류 우리 슬랙의 무료 평가판 기간이 끝나면서, 마지막에 추가한 sentry 알람이 사라졌다.. 이제 에러가 나는지 직접 들어가서 확인해봐야 한다. 요즘 설치 수가 많아지면서 그래도 잘 작동하는 줄 알았는데.. 똑같은 오류가 천 번 이상 지속적으로 나고 있었다. 오류 메시지는 쇼피파이 상품 미디어의 ID가 이미 존재하는 값이라, DB가 롤백된다는 내용이다. 모두 쇼피파이 설치 로직에서 발생했다. 쇼피파이 상품 미디어의 ID는, 쇼피파이에서 제공하는 값이다. 쇼피파이에서 globally unique id라 했으니까 분명 중복이 된 값이 들어올리는 없고.. 이미 저장된 상품을 또 저장해서 발생한 문제인지 알아봤는데, 이 에러가 터진 샵들 중 첫 설치인 샵들이 많았다. ...

Today I Learned 날짜 2024년 10월 24일 목요일 내용 알림톡에서 손님받기 알림톡에는 3가지 링크가 포함된다. 완성된 배너이미지 보러 가는것, 다운로드 받기, 삭제하기 버튼이다. 해당 버튼을 누르면 기존 어드민과는 별개의 페이지로 이동하고 해당 액션을 취할 수 있다. 그 내부에서 처리하는 건 이미 존재햐는 기능이라, 버튼을 누르면 서버 엔드포인트로 요청을 보내도록 구현할 수도 있겠으나, 그 요청을 검증해야 한다고 생각했다. 리소스를 건드리는 작업인 만큼, 권한이 있는 클라이언트의 요청임을 확인하고 싶었다. 버튼을 누르면, 하고자 하는 행동과 jwt 토큰이 path로 포함된 채 이동한다. 클라이언트에선 jwt 토큰을 서버로 보내 검증을 요청한다. 서버는 토큰이 올바르다면, 필요한 유저정보 (서비스 ID, 액세스 토큰, 플랫폼)와 배너이미지의 ID를 반환한다. 토큰이 올바르지 않다면 웬놈이냐며 쫒아낸다. 만약 이 과정이 없었다면 ID만 알아도 URL로 접근해 남의 리소스를 처리할 수 있을수도 있다. ...