효율성에 매몰되지 않기

Today I Learned 날짜 2024년 2월 2일 금요일 내용 삼지선다 나름 기가 막힌 아이디어가 떠올라서, 어제의 Task를 처리했다. 내가 달성해야 할 구현 목표는 다음과 같다. 구글 스프레드시트에 있는 데이터는 기존 행에 새로운 값을 덮어써준다. 구글 스프레드시트에 없지만 2024년 2월 이후 가입했거나, 기존에 가입했으나 새로 AI 서비스를 이용하게 된 고객의 데이터는 새로운 행에 추가해준다. 서비스에서 탈퇴해 데이터가 없어졌을 떈 스프레드시트에서도 삭제한다. 추가된 데이터를 한번 정제해서 쓰면 되니 굳이 API가 완벽하게 정리된 데이터를 만들 필요는 없다고 하셨지만 뭔가 놓치고 있다는 느낌이 자꾸 들어 기존의 걸림돌을 되짚어봤다. ...

2024년 2월 2일 · 2 분 · 배준수

구글 스프레드시트에 기존 데이터 업데이트하기

Today I Learned 날짜 2024년 2월 1일 목요일 내용 스프린트 결과가 배포됐다. 다행히 큰 빵꾸는 없었다. 많은 유저가 몰려왔으면 좋겠다. 구글 스프레드시트에 데이터 추가하기 새로 만든 기능에 대한 KPI 데이터를 구글 스프레드시트에 추가하는 태스크를 맡았다. 이전에, 작동이 멈췄던 커맨드를 다시 돌리는 작업을 했었는데 이와 비슷할거라고 생각해서 별로 어렵지 않겠다 싶었다. 약간의 차이점이 있었는데 이 부분을 너무 쉽게 생각했다. 기존에는 매일매일 새로운 행에 데이터를 추가했지만, 이번에는 기존 데이터에 덮어써야 했다. 1개의 샵 당 1개의 데이터를 가지게 되며, 이미 데이터가 존재한다면 새로 행을 추가하지 않고 수정해야 한다. ...

2024년 2월 1일 · 3 분 · 배준수

print와 logging의 차이 : stdout buffer

Today I Learned 날짜 2024년 1월 31일 수요일 내용 logging과 print 문의 차이 : stdout buffer logging과 print의 차이에 대해 많이 찾아봤는데 디버깅을 위해선 logging문을 쓰는 것이 좋다는 의견이 대다수다. 사실 그냥 다 logging을 쓰라고 한다. 단순 출력이 아닌, 오류 메시지나 변수 내용, 위치 등을 다양하게 출력할 수 있으니 print가 쓰기는 편해도 전체 디버깅 작업의 속도를 높이는데는 logging이 훨씬 효과적이다. backgrountasks에서 print가 작동이 안되는 이유에 대해선 정확한 내용을 찾기 힘들었는데, stdout buffer가 원인이라는 얘기가 있다.stdout은 표준 출력 데이터를 의미한다. 반대로 stdin은 표준 입력(ex. 키보드) 데이터를 의미한다. 백준에서 알고리즘을 풀다보면 키보드 입력을 input() 이나 sys.stdin.readline() 으로 받곤 하는데 여기서 stdin이 나오는 걸 알 수있다. print 함수는 stdout을 사용하여 출력한다. print문이 콘솔창에 찍히는 것도 표준 출력으로서 나타나는 것. ...

2024년 1월 31일 · 3 분 · 배준수

QA, 구글 API 비용 예측

Today I Learned 날짜 2024년 1월 30일 화요일 내용 계속 QA를 진행하고 있다. 키워드 추출 실패 갑자기 특정 경우에 키워드를 추출해내는데 실패하고 있다. 키워드는 nltk 관련 문제라 AI가 고장난 건 아니였다. 안되는 상품의 URL을 들어가보니 리뷰들이 모두 한글로 작성되어있었다. 그동안 리뷰가 당연히 영어로 가져와질 것이라고 생각했는데, 원어(작성 언어)와 접속시 설정한 언어 중 하나로 선택할 수 있었다. 문장을 단어 단위로 쪼개는 tokenize는 punkt 데이터를 사용하는데 어제 말했듯 정말 다양한 언어 데이터가 존재하지만, 긍정 부정을 판별하는 opinion_lexicon은 영어밖에 없었다. 리뷰를 항상 영어 번역하여 가져오도록 했더니 해결되었다. ...

2024년 1월 30일 · 4 분 · 배준수

NLTK 데이터 파일 저장하기

Today I Learned 날짜 2024년 1월 29일 월요일 내용 기능 개발이 끝나고 QA를 시작했다. nltk 지난주에 nltk 패키지에서 필요한 데이터들을 templates 폴더에 추가하여 추가적인 다운로드 없이 사용하도록 코드를 작성했었다. 테스트 서버에서 오류가 발생했는데, 범인은 금요일이 연차여서 존경하는 선배님께서 원상복구 해주셨다. 문제 해결을 위해, 고민의 원점에 서서 차근차근 생각하며 다양한 방법을 생각했다. 현재 해결하고자 하는 것은 무엇인가? nltk 패키지에서 사용할 데이터 다운로드 횟수를 최소한으로 만들자. 그 목적은 무엇인가? 불필요하게 반복되는 데이터 다운로드는 리소스 낭비기 때문이다. 해결하기 위한 방법들은 무엇들이 있는가? templates 디렉토리 내에 데이터를 저장한다(현재). S3, Git Large File Storage 등의 스토리지 서비스를 이용한다. dockerFile에 이미지 빌드 시 필요한 데이터를 다운로드 하도록 한다. 방법 (a)의 동작을 정상화 시킨다고 하더라도, 간과한 문제가 있었다. nltk에서 다운로드 하는 데이터는 3가지다. ...

2024년 1월 29일 · 3 분 · 배준수

누구나 이해할 수 있는 코드 짜기

Today I Learned 날짜 2024년 1월 25일 목요일 내용 낫 놓고 기억자도 모름 알리익스프레스에서 크롤링을 제한해두었다. 어제 겪은 문제의 원인이다. 상품 정보를 가져오지 못하는 이유를 온갖 곳에서 찾았을 때 분명 보았던 글이고, 생각도 해봤지만 특정하지 못했다. 개발 실력을 키우는 수준에서 가능한 것과 그렇지 않은 것을 구별해내는 능력은 아직 먼 일일지도 모르겠지만, 좀 갖고싶다. 코드개선 오늘은 전체적으로 내가 작성한 코드의 퀄리티를 높이는 작업을 했다. 타입 힌팅 : 함수들의 반환 타입을 지정해주었다. 재사용성할 필요성은 느끼지 못해서 스키마에 추가하진 않았다. 키워드인자 : 함수를 정의할 때 parameter도 정의한다. 함수를 호출할 때 정의한 순서대로 값을 넣을 수도 있고(위치인자), 정의한 parameter 이름으로 넣을 수도 있다(키워드인자). 키워드 인자는 어떤 값이 어떤 인자로 쓰여있는지 확실히 알 수 있기 때문에, 여러 사람이 보는 코드에서 불필요한 혼동을 줄여준다. nltk 데이터 : 받은 리뷰들을 각 단어의 원형으로 토큰화하고, 긍부정을 판별하기 위해서 데이터가 필요하다. 데이터가 자주 업데이트 되지 않다보니 한번만 다운로드 하도록 변경했다. 기존에는 분석함수 호출할 떄마다 다운로드했는데, 큰 것은 용량이 122MB다 보니 너무 비효율적이다. S3 버킷에 넣을까 고민했는데, 매번 가져와서 조회하는 것도 효율적이지 않다고 생각했다. 그럼 docker-compose에 빌드할 때 다운로드하도록 추가할 것도 고민해봤다. 하지만 애초에 데이터를 저장해두는 이유는, 이 데이터가 업데이트가 잘 되지 않기 떄문이다. 최근 업데이트가 2016년이였으니까.. 그냥 위젯이나 이메일 템플릿 저장하듯이 디렉토리에 추가해주었다. 괜히 어렵게 생각했네. 회고 평탄할 줄 알았지만 힘든 한주였다. ...

2024년 1월 25일 · 1 분 · 배준수

열심히 집중하여 최선을 다해 아무것도 못하기

Today I Learned 날짜 2024년 1월 24일 수요일 내용 하루종일 아무것도 해낸 게 없다. 다행히 오늘은 딱히 프론트쪽에 심어둔 폭탄이 없어서 급하게 바꾸거나 할 부분은 없었다. 지금 스프린트에서, 리뷰들을 수집해오면 기존에 존재하는 테이블에 리뷰 수집 기록을 남기고, 이 테이블의 자식 테이블 격인 분석 기록 테이블에 레코드를 추가한다. 그리고 리뷰를 분석하여 결과 테이블에 결과를 기록한다. 상품에 대한 정보 중 일부(제목, 판매량 등)이 DB에 저장되지 않는 문제가 발생했으나 해결하지 못하고 있다. 상황이 참 꼬여있는게, 로컬에서는 받아오는데 전혀 문제가 없고 로컬에서 테스트 서버의 데이터베이스에 연결해서 테스트서버를 구동해봐도 DB에 정보를 잘 저장한다. 하지만 테스트서버에서 API를 테스트 했을때만 일부 정보를 찾지 못한다. 따라서 해결을 위한 테스트는 모두 테스트 서버에서 이뤄져야 하는데 나는 아직 코드싸개라 권한이 없다보니 참 힘들다. ...

2024년 1월 24일 · 1 분 · 배준수

피그마 안 본 카르마

Today I Learned 날짜 2024년 1월 23일 화요일 내용 코드를 그지같이 짠 댓가를 톡톡히 치뤘다. 문제는 나만 치룬게 아니라는게.. 기획안과 피그마 피그마와 기획안 현황을 제대로 숙지하지 않았다. 그래서 여러 문제가 생겼는데, 여러 분석 결과를 보여주는 화면에 관련된 API를 만들지 않았다. 리뷰의 판정에 중립을 설정하지 않았다. 필요한 데이터를 제대로 넘기지 않았다. 이외에도 수두룩하다. API 자체는 급하게 만들었으나 여러가지 수정해야할 것들도 존재했고 똑바로 만들지 않아서 고쳐야 할 것도 많았다. 애초에 내가 잘 테스트해서 끝내놨어야 했는데 그러지 못해서 발생한 일이었다. ...

2024년 1월 23일 · 2 분 · 배준수

ECS 망령

Today I Learned 날짜 2024년 1월 22일 월요일 내용 진척이 많이 됐지만, 디테일이 많이 부족한 상황. ECS Task 이쯤되면 ECS가 일본 축구선수 (이) 시바사키 가쿠의 약자는 아닐까 의심된다. 오늘 weekly review report 메일이 발송되지 않았다. 지금은 스프린트 중이라 나중에 고쳐야하지만 얼추 봤을땐 cron식이 잘못된 것으로 보인다. 구글 스프레드시트에 데이터를 추가하는 Task에서도 오류를 발견했다. 작동자체는 잘 되지만 데이터 상의 날짜가 이틀 전으로 들어간다. 내가 넣고자 하는 날짜는 오늘이었으나, UTC 시간 상 한국 시간 8시는 전날 오후 11시다. 따라서 Task가 동작하는 시간의 “오늘”은 실제론 어제다. 그리고 내가 작성한 cronjob은 날짜를 어제로 설정한다. 이 cronjob은 어제의 “어제”, 즉 그저께를 가리키게 된다. ...

2024년 1월 22일 · 2 분 · 배준수

Fastapi의 Background task

Today I Learned 날짜 2024년 1월 19일 금요일 내용 오늘은 어쩌다보니 내 생각의 흐름을 적지 않았다. 막혀서 깊게 고민한 적이 없어서 그런가.. API 어제 리뷰들에 대한 세부 정보를 만드는 함수들을 다 만들었다. 오늘은 프론트에서 해당 데이터를 요청할 때를 응답하는 API를 만들었다. 이미 데이터를 저장하는 건 완성되어 있었기 떄문에, 알맞게 받아서 주는 것은 어렵지 않았다. 프론트를 내가 하는게 아니다보니 다른 사람도 쉽게 이해할 수 있도록 작성하려고 나름 노력했다. 각주에도 헷갈릴 만한 부분도 적고, parameter나 변수, 함수 이름도 최대한 직관적으로 적었다. 너무 이름이 길어서 좀 거슬리긴 한데, 이도 저도 아닌 이름보다 낫기도 하고 정 거슬리면 실서버 배포 전에 바꾸면 되겠지. ...

2024년 1월 19일 · 2 분 · 배준수