사내 RAG 검색에서 문서 권한을 답변 전부터 검사하는 법
사내 RAG가 비밀 문서를 검색한 뒤 마지막 답변에서 문장만 지우면 안전할까요? 아닙니다. 검색 결과가 모델 입력에 들어간 순간 이미 노출 경로가 생깁니다. 문서 권한은 답변 후처리가 아니라 검색 단계에서부터 적용해야 합니다.
NOTES
현장에서 배운 것들
모델을 만들고, 웹과 앱을 짓고, 업무를 자동화하며 확인한 것을 기록합니다. 통한 방법만이 아니라 통하지 않았던 시도까지 남깁니다.
TOTAL 288
AI 에이전트 업무를 대화가 아닌 상태 기계로 관리해야 하는 이유
에이전트가 '해 두었습니다'라고 말했지만 실제 외부 시스템에는 반영되지 않은 경험이 생기면 운영자는 대화를 믿기 어렵습니다. 여러 API를 거치는 업무는 채팅 기록보다 명시적인 작업 상태와 재시도 규칙으로 관리해야 합니다.
고객게시판 스팸, CAPTCHA 하나로 막기 어려운 이유
고객게시판 스팸을 막으려고 CAPTCHA를 붙였는데도 글이 올라온다면 한 단계 방어가 뚫린 것입니다. 자동화 공격은 네트워크, 폼, 업무 규칙의 빈틈을 모두 찾습니다. 정상 고객 문의를 어렵게 만들지 않으면서 여러 층에서 비용을 올리는 설계가 필요합니다.
웹사이트가 떠도 버튼이 늦게 반응한다면: INP 원인 찾기
웹사이트가 빠르게 화면에 나타나도 버튼을 누른 뒤 반응이 늦을 수 있습니다. 로딩 속도와 상호작용 속도는 다른 문제입니다. INP를 개선하려면 클릭부터 다음 화면 갱신까지의 지연을 입력 대기, 이벤트 처리, 화면 표시 단계로 나눠 보아야 합니다.
구조화 데이터는 검색 순위 버튼이 아니다: 본문과 일치시키는 법
웹페이지에 구조화 데이터를 넣으면 검색 결과가 무조건 더 화려해지고 순위가 오른다는 기대는 위험합니다. 구조화 데이터는 검색 엔진이 페이지의 내용을 이해하도록 돕지만, 표시 여부는 보장되지 않습니다. 무엇보다 마크업이 사용자에게 보이는 본문과 일치해야 합니다.
백업이 있어도 복구 연습이 없다면: RPO·RTO 실전 점검
백업 파일이 존재한다는 사실과 서비스를 복구할 수 있다는 사실은 다릅니다. 장애 때 어느 시점까지 데이터를 되돌릴 수 있고 언제 다시 업무를 시작할 수 있는지 테스트해야 합니다. RPO와 RTO를 문서에만 적지 말고 복구 훈련의 측정값으로 만들 필요가 있습니다.
API 사용량 제한, 큰 고객 한 곳이 모두를 느리게 하지 않으려면
멀티테넌트 API에서 전체 요청 수만 제한하면 한 고객의 급증이 다른 고객의 응답까지 늦출 수 있습니다. 반대로 고객별 제한만 두면 전체 서버가 버티지 못할 수 있습니다. 좋은 사용량 정책은 공유 자원과 고객별 몫을 함께 보호합니다.
멀티테넌트 SaaS에서 고객 데이터 삭제 요청을 증명하려면
SaaS 고객이 계약을 끝내며 데이터 삭제를 요청했을 때, 운영 DB의 행만 지우면 끝일까요? 검색 인덱스, 파일 저장소, 로그, 백업, 분석 데이터에 같은 정보가 남을 수 있습니다. 삭제를 약속하려면 데이터가 어디에 있는지와 각 저장소의 삭제 상태를 추적해야 합니다.
신제품 수요 예측, 과거 판매 데이터가 없을 때 시작하는 법
신제품은 판매 이력이 없으므로 시계열 모델에 넣을 '과거'가 없습니다. 그렇다고 예측 없이 초도 생산량을 감으로 정할 수도 없습니다. 유사 제품, 사전 주문, 채널 계획을 이용하되 불확실성을 크게 표시하는 출발점이 필요합니다.