모도리는 공부중

개인 프로젝트로 세금 계산기를 만들다가 겪은 일이다. PDF 파서 얘기인데, 결론은 PDF와 별로 상관이 없다.초록불이 뜬 상태로 넘어와 있었다연말정산 원천징수영수증에서 값을 뽑는 일을 AI에게 맡겼다. 뽑을 필드는 16개. 총급여, 과세표준, 산출세액 같은 것들이다.파서가 왔고, 테스트도 같이 왔다. 55개 전부 초록이었다.그래서 진짜 서식을 넣어봤다. 16개 중 한 개도 안 나왔다.에러는 안 났다. 그게 제일 이상했다. 파서는 찾은 게 하나도 없다고 조용히 보고했을 뿐이다.초록불의 정체, 그리고 첫 번째 개입테스트를 열어보고 알았다. 픽스처를 AI가 직접 만들어 놓고 있었다."원천징수영수증은 이렇게 생겼겠지" 하고 합성 PDF를 만들고, 그 PDF로 테스트를 짰다. 그 파서는 그 상상을 정확히 파싱한..

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..

2024년 말에 겪은 인시던트의 회고다.운영 DB에 걸어놓은 인덱스가 사라졌다어느 날 운영 DB를 확인하다가 소름 돋는 걸 발견했다. 분명히 걸어놨던 인덱스가 없어져 있었다. 지운 사람은 없다고 한다. 그럼 누가 지웠을까.인덱스는 없어져도 서비스가 죽지는 않는다. 대신 쿼리가 조용히 느려진다. 그래서 더 무섭다. 에러 한 줄 없이 성능만 야금야금 나빠지고 있었던 거다.삽질 1: 언제 사라졌는지부터 추적일단 "언제" 없어졌는지를 알아야 "누가/왜"를 좁힐 수 있을 것 같았다.현재 상태 확인은 간단하다.SHOW INDEX FROM your_table_name;근데 이건 지금 걸려있는 인덱스만 보여주지, 언제 생기고 언제 사라졌는지는 안 알려준다. information_schema.STATISTICS를 조회하..

2024년 말, 작은 운영 서버에서 정리한 기록이다. 본문의 디스크 수치는 그 시점 값이다. 다만 그때 내가 근거로 삼았던 설명이 틀렸다는 걸 나중에 알게 됐고, 그 부분은 이 글에 그대로 적었다.운영 중인 서버를 살펴보다가 문득 궁금해졌다. journalctl로 보는 이 로그들, 일정 기간 지나면 오래된 것부터 알아서 없어지는 걸까? 아니면 무한정 쌓이고 있는 걸까?백엔드 애플리케이션 로그는 애플리케이션 단에서 라이브러리로 따로 쌓고 있어서, journal에 쌓이는 로그는 "지금 잘 돌아가고 있나" 확인하는 용도면 충분했다. 그런데 이게 디스크를 야금야금 먹고 있다면 얘기가 달라진다.현재 상태부터 확인일단 서버의 journald 설정 파일을 열어봤다.sudo cat /etc/systemd/journal..

로그 시리즈 3편. 1편에서 systemd로 옮기며 상한을 걸었고, 2편에서 syslog 이중 적재를 잡았다. 이 글은 그 뒤 일주일이다. 포워딩을 끊고 사용률이 100%에서 77%로 내려왔다. 이번엔 진짜 끝난 줄 알았다.매일 오후 5시 기록을 그대로 옮기면 이렇다.날짜엔진 서버1/16 (조치 직후)77%1/1783%1/20 오전89%1/20 오후90%1/2193%1/2497%하루에 2~3%씩 꾸준히. 이번엔 폭발이 아니라 등속이었다.이번엔 시스템 로그가 아니었다/var/log를 봤더니 journal이 500M 근처에서 얌전했다. syslog는 상위 목록에서 아예 사라졌고. 2편에서 한 조치는 잘 먹고 있었다.그럼 뭐가 차는 건가.찾기 전에 급한 불부터 껐다. journal은 이 명령 하나로 그 자리에..