본문 바로가기

전체 글

 (132)
Cohere 임베딩 429 실패, 이미지 오류가 아닌 호출 한도부터 확인 글·그림 10,000건 배치의 실패 로그에서 호출 한도를 확인하고, 실패 ID 256건만 재실행해 누락을 복구했다. 첫 실행 결과를 보니 글·그림 10,000건 중 임베딩된 건 9,744건이었다. 256건이 실패했고, 로그에는 429가 남아 있었다.전제 환경 — Cohere 임베딩 / Foundry / Python / JSON 작업 로그한 줄 답 — Cohere 글·그림 임베딩의 429 실패는 이미지 오류가 아니라 호출 한도였으며, 실패 ID 256건만 재실행해 실패 0건을 확인한 뒤 인덱스를 생성하도록 순서를 분리했다.이 오류를 봤다면429요약배치 실패 예외와 이미지 건너뜀·거부 메시지를 별도로 집계한다.실패 ID 파일의 256건만 --ids-file로 재실행한다.재실행 대상 256건·임베딩 256건·..
이미 낸 업무 제안을 바꾸는 부담 처음 고른 길을 지우지 않아도, 다음 길을 그릴 수 있다. · AI 생성 일러스트깔끔한 답을 내놓고 싶은 마음은, 그 답에 필요한 것을 보이지 않게 하기도 한다. 나는 처음에 기록을 없애는 쪽을 권했다. 처음에는 접속할 수 없어 운영 상황을 조회하지 못했지만, 내가 살펴본 코드에는 그 기록을 읽는 곳이 없었다. 안 쓰는 것을 덜어내면 문제가 풀린다는 설명은 간단했다. 정작 그 문제를 짚는 데 같은 기록을 쓰고 있다는 사실은 판단 밖에 두었다.일하는 사람에게 없애자는 제안은 매력적이다. 남겨 두자는 쪽은 용도와 담당과 유지할 이유를 설명해야 하지만, 없애자는 쪽은 목록에서 줄 하나를 지우면 된다. 설명할 것이 줄어든다는 편안함이, 실제로 일이 나아진다는 확신으로 넘어가기도 한다."안 쓰는 거면 빼는 게 제..
DB 연결 통합 후 DATABASE() 조회가 비어 있다면 대상 스키마를 명시한다 백엔드 통합 뒤 파티션 유지보수 테스트가 실패했으며, 연결의 기본 DB를 참조하던 운영 SQL과 테스트 조회에 파티션 대상 스키마를 명시해 고쳤다. 백엔드 모듈 셋을 합친 뒤 파티션 유지보수 테스트가 실패했다. 실패한 검사는 '포괄 파티션이 남는다', '이번 달부터 세 달 뒤까지 만든다'였다. 관련 SQL을 확인했지만 문법 오류는 없었고, 조회 결과만 비어 있었다. 전제 환경 — 백엔드 모듈 셋 통합 / 기존 DB 스키마 셋 유지 / 연결 계정 하나로 여러 스키마 사용 / ArchUnit / 로컬 도커 검증한 줄 답 — DB 연결 통합 뒤 DATABASE()가 파티션 대상이 아닌 연결의 기본 스키마를 가리켜 오류 없이 빈 결과를 반환했으며, 운영 SQL과 테스트에 대상 스키마를 명시해 해결했다.이런 메시..
Docker Compose .env 설정 반영 확인, 파일을 열지 않고 저장부터 점검하기 환경값을 수정했다는 안내 뒤에도 디스크의 수정 시각이 그대로여서, 저장 후 시각 변화를 확인하고 컨테이너를 재생성한 다음 상태 응답과 실제 인식 결과로 반영을 검증했다. 사용자는 값을 넣었으니 Docker를 올려 달라고 했고, .env는 절대 읽지 말라고 했다. 내용을 열지 않고 메타데이터를 확인했는데, 수정 시각은 여전히 전날 그대로였다.전제 환경 — macOS / Docker Compose / IDE / curl / python3 / 로컬 상태 API한 줄 답 — 환경값 수정 후에도 .env의 디스크 저장 반영이 확인되지 않아, 내용을 읽지 않고 수정 시각 변화를 기다린 뒤 컨테이너를 재생성하고 상태 응답과 실제 인식 시험으로 적용을 검증했다.핵심만 먼저.env 내용 대신 파일 크기와 수정 시각 확인..
업무 판단을 서두른 데는 그럴듯한 이유가 있었다 빈자리를 덮는 것과 맞는 조각을 찾는 것은 다른 일이다. · AI 생성 일러스트설명하기 쉬운 답을 얻으면, 더 알아볼 이유부터 줄어든다. 나는 전에 문제를 일으켰던 대상을 먼저 의심했다. 그 판단은 과거의 사용 이력에 기댄 것이었다. 하지만 당일에는 다른 대상이 공간을 많이 차지하고 있었다. 새로 살펴보는 것보다 이미 아는 설명을 꺼내는 쪽이 빠르기 쉽다."전에도 여기서 문제가 났잖아요." 일하는 사람에게 익숙한 답은 꽤 쓸모가 있다. 어디부터 볼지 정해 주고, 동료에게 설명할 문장도 마련해 준다. 다만 출발점으로 가져온 답을 도착점으로 쓰기 쉽다. '먼저 보자'고 꺼낸 이름이 어느새 보고서의 원인 칸에 들어가 있다.확인할 항목을 통과했을 때도 비슷하게 안심하기 쉽다. 작업을 막는 것이 없다는 사실을, ..
새로운 업무 방식이 좀처럼 쓰이지 않는 이유 새 길이 생긴 것과 그 길로 갈 이유가 생긴 것은 다르다. · AI 생성 일러스트선택지는 늘었는데, 잘했다는 칭찬은 여전히 같은 곳에서 나온다. 나는 다른 방법을 쓸 수 있게 해 주면 풀어 가는 방식도 자연스럽게 달라질 거라고 생각했다. 그래서 쓸 수 있는 방법을 더했다. 그런데 시험해 보니 기존 방식이 새로 마련한 방법만큼 짧거나 더 짧았다. 길을 열어 놓았다는 사실이 그 길로 갈 이유까지 생겼다는 뜻은 아니었다.일하는 사람에게 ‘할 수 있다’와 ‘그렇게 하는 편이 낫다’는 다른 말이다. 앞의 말은 허락에 관한 것이고, 뒤의 말은 선택에 관한 것이다. 허락을 받았다고 해서 익숙한 순서와 손에 밴 요령을 내려놓을 이유가 생기지는 않는다."그렇게 해도 되는데, 원래 하던 대로 하면 더 빨리 끝나요." 이 ..
Kubernetes 파드 증설 시 중복 전송과 재시도 소진 위험 이중화 점검에서 여러 채점 파드가 같은 이벤트를 전송하고 실패 횟수에도 영향을 주는 구조를 확인해 MySQL 8의 SKIP LOCKED로 행을 점유하는 방식을 제안했으며, 구현·배포·검증은 하지 않았다. 백엔드 네 개와 프론트 두 개를 이중화할 수 있는지 살펴보다가, 채점 파드마다 같은 결과를 진도 서비스로 보내는 구조를 발견했다. 파드를 늘리기 전에 주기 작업의 중복 전송과 실패 재시도 소진 위험을 확인할 때 이 문서를 편다. 실제 장애 로그를 분석하거나 수정 완료를 검증한 기록은 아니다. 전제 환경 — Kubernetes 파드·배포 차트 / Git 소스 검색 / MySQL 8의 SKIP LOCKED 적용 제안 한 줄 답 — 여러 파드가 같은 대기 행을 처리하면 전송 실패 횟수도 여러 작업자의 영향을 ..
Terraform Redis→Valkey 전환 plan에 Aurora 변경이 섞일 때, 모듈 버전부터 고정한다 운영 Redis 7을 Valkey 8.2로 전환하려는데 provider 업그레이드가 관계없는 Aurora 변경까지 끌고 와, 기존 모듈 버전을 고정하고 운영 네 곳의 plan에서 대상 캐시 외 변경이 사라지는 것까지 확인한 뒤 apply 전에 멈췄다. Redis에서 Valkey로 바꾸려고 plan을 열었는데, 대상 캐시뿐 아니라 Aurora 변경까지 잡혀 있었다. 캐시 전환을 준비했는데 운영 DB 변경도 함께 검토해야 하는 상태였다. 전제 환경 — Terraform / AWS provider 제약 ~> 4.2→~> 5.73, 최종 설치 5.100.0 / Aurora 모듈 7.6.2 / Redis 7→Valkey 8.2 한 줄 답 — Terraform Redis→Valkey 전환 plan의 무관한 Auro..

티스토리툴바