#go
go 태그가 붙은 글 9편. · 전체 태그 보기
- 누락 0건을 전수로 검증한 PR이, 주석 한 줄로 분석을 세 시간 멈췄다 26만 건 소급 재생성을 위해 락·롤링 배포·누락 행까지 따진 PR이었다. 마지막에 넣은 정렬 변경의 주석 안 치환 자리 하나가 SQL을 깨뜨렸고, 테스트 네 개는 전부 통과했다
- 빈 배열 하나가 한도 도달을 일반 실패로 만들었다 새벽 두 시간 동안 프로젝트를 가리지 않고 잡이 전부 실패했다. 남은 문구는 한 줄이고 원인 자리가 비어 있었다. 그리고 그걸 고치자 공시 본문의 "429억원"이 전역 정지를 부를 수 있게 됐다
- 파라미터를 하나씩 조이다 두 번 뚫리고, 조이기를 그만뒀다 형제 경로에 모양 검사가 없는 걸 고치러 갔다가 그게 핵심이 아니라는 걸 봤다. 캐시 키가 RequestURI 전체라 같은 응답을 가리키는 표기가 여럿이면 항목도 여럿이었다. 적중률을 포기하고 총량 상한 64MB를 걸었고, 그 뒤 리뷰가 상한 자체의 구멍을 셋 더 찾았다
- 폭주를 잡 단위로 판정하지 않기로 했다 호출 1회 비용 상한을 만들고, 올리고, 알림으로 바꾸고, 결국 없앴다. 나흘 동안 같은 장치를 네 번 고친 끝에 남은 건 총량 게이트와 타임아웃뿐이다. "알림만 주라고 했지 않아?"
- effort를 열어줬더니 effort가 비어 있었다 공유 큐에 잡별 모델·effort 선택을 붙였다. 자체 리뷰를 시키자 에이전트가 스크래치 세션 9개로 실측해 닷새 전에 끈 thinking이 effort를 무력화하고 있음을 찾았다. 요청값과 실제값을 컬럼 둘로 나눈 이유, 그리고 배포 뒤 문서와 프로덕션이 다섯 군데 어긋나 있던 것
- thinking을 껐다 요약 잡 출력 토큰의 85.8%가 thinking이었다. 환경변수 하나로 끄니 출력 −85%, 처리 시간 4.5배, 스키마 10/10, 요약엔 오히려 숫자가 늘었다. 그리고 끄는 코드 한 줄이 세 프로젝트 인증을 동시에 죽일 수 있었던 이유
- 64만 건 백필을 라이브 뒤에 세우는 장치 셋 2020~2025 공시 아카이브를 채우려면 외부 API 일일 한도와 LLM 처리량 안에서 몇 달을 돌려야 한다. 수집과 분석을 떼고, 아카이브를 신규 공시 뒤에 세우고, 한도 오류에 전 워커를 멈추는 장치를 만들었다. 완료 예상은 닷새 사이 네 번 바뀌었다
- dev 환경의 조용한 함정 둘 하루에 네 번 "수정이 안 먹는다"로 코드를 다시 읽었다. 범인은 코드가 아니라 dev와 build가 공유하는 .next 디렉터리, 그리고 로컬 DB를 고쳐도 옛 응답을 주는 두 겹 캐시였다. 사용자 눈에는 한 번도 안 보인 함정
- AI가 다시 써준다면 스택을 갈아타도 될까 — 12일 동안 세 번 갈아탄 기록 12일 동안 백엔드를 Spring Boot에서 Go로, 모바일을 세 번 갈아타며 전환 비용이 정말 0인지 확인한 기록