문제를 불편한 채로 두기보다해결하려고 합니다
AI 에이전트를 만들며 부딪힌 것과, 그러다 다시 들여다본 웹·백엔드 기본기를 적습니다.
지금까지 쓴 글
· 인프라·운영
nginx reverse proxy는 그대로, Kubernetes는 Gateway API로
단독 nginx의 reverse proxy는 여전히 유효하지만, Kubernetes에서는 ingress-nginx 은퇴에 맞춰 Gateway API로 단계적으로 전환해야 한다.
· 백엔드
worker가 모델을 기다리는 동안 책임이 흐려져요
Slack 봇은 3초 안에 답해야 하는데 모델은 몇 분을 씁니다. 그 사이를 worker가 붙잡고 있으면 타임아웃·취소·중복이 한 실행에 뒤엉켜요. 완료를 이벤트로 받아 내부 상태에 한 번만 모으는 구조를 정리했습니다.
· 웹·네트워크
HTTP 캐시는 만료 뒤에도 다시 쓸 수 있다
Cache-Control로 신선도를 정하고 ETag와 If-None-Match, 304로 만료된 응답을 재검증하는 흐름을 정리한다.
· 인프라·운영
어제까지 잘 되던 캐시가 오늘 0%가 됐다면
프롬프트 앞부분을 다시 계산하지 않는 기능은 켜는 것보다 깨지지 않게 두는 게 어려워요. 날짜 한 줄이 앞에 끼면 그날부터 적중률이 0이 돼요. provider 넷의 규칙 차이와 무엇을 기록해야 원인을 찾는지 정리했어요.
· 백엔드
외부 작업을 재시도하기 전에 상태부터 확인해야 하는 이유
timeout 뒤에도 외부 write는 성공했을 수 있으므로 postcondition 검증, idempotency key, receipt를 결합해 중복 부작용을 막아야 한다.
· 백엔드
Slack 봇 기능, 어디까지 skill 이고 어디부터 MCP server 인가
Slack 슬래시 명령으로 만든 업무 에이전트를 ChatGPT·Codex plugin 으로 옮길 때 기능을 skill-only, MCP server tool, MCP server + UI 로 가르는 선을 OpenAI 공개 문서에서 뽑아 정리한다. 실제 이관과 측정은 아직 하지 않았다.