모도리는 공부중

2025년 초의 기록이다. 후일담 부분은 2026년 봄에 같은 에러를 다시 만나면서 보탰다.일주일 만에 켠 서비스에서 로그인이 안 됐다운영 서버에서 로그인이 안 된다는 보고가 들어왔다. 502가 떴는데, 다시 시도하니까 멀쩡하게 됐다고.확인해보니 그 서비스는 일주일 동안 아무 요청도 없던 상태였다.서버 로그를 열어보니 이런 게 찍혀 있었다.fastapi.exceptions.ResponseValidationError: 1 validation errors: {'type': 'get_attribute_error', 'loc': ('response', 'team_roles'), 'msg': 'Error extracting attribute: OperationalError: (pymysql.err.Ope..

회사에서 월별 데이터 조회 API가 느리다는 얘기가 계속 나왔다. 짧으면 3~5초, 길면 12~20초.20초면 보는 사람은 이미 새로고침을 눌렀을 시간이다.코드를 열어봤다. 반복문 안에서 쿼리를 날리고 있었다. 그것도 세 겹으로.참고로 아래에서 말하는 "배치"는 구역(zone) 단위로 입고·출고되는 재고 묶음이고, 매일의 재고 이력이 히스토리 테이블에 쌓이는 구조다.쿼리가 몇 번 나가고 있었나기존 코드 구조를 단순화하면 이랬다.for day in all_days: # 한 달 = 30일 반복 # 1) 해당 일자에 active한 배치 조회 active_batches = db.query(Batch)\ .filter(Batch.zone_id == zone.id)\ .filt..

2024년, 아직 회사 코드에 익숙해지기 전에 겪은 일의 기록이다.리뷰 중에 내가 짠 라우터 코드가 이렇게 지적당했다.def read_device_api( device_id: int, base_date: date = Query(default=date.today()), db: Session = Depends(get_db), current_user: UserRead = Depends(get_current_user)): ..."이거 문제 있어서 crud 단에서 이렇게 고쳤어요" 하면서 넘어온 코드는 이거였다.def read_daily_status(db: Session, zone_id: int, base_date: Optional[date], owner_id: int): if base_date is ..