dohaii040603 님의 블로그

1. 프롬프트 인젝션은 모델 취약점이 아니라 경계 설계의 실패다프롬프트 인젝션이라는 개념이 처음 알려졌을 때, 많은 팀은 이를 모델의 문제로 받아들였다. 모델이 너무 순진해서 사용자 입력을 그대로 믿는다거나, 지시를 구분하지 못한다는 식의 해석이 뒤따랐다. 그러나 실제 운영 환경에서 반복적으로 드러난 사실은 조금 다르다. 프롬프트 인젝션 사고의 대부분은 모델이 약해서 발생한 것이 아니라, 모델이 어떤 입력을 받아도 되는지 정의되지 않은 채 외부와 직접 연결되었기 때문에 발생한다.LLM은 본질적으로 텍스트를 이해하고 따르는 시스템이다. 입력 안에 지시가 섞여 있으면, 그것을 구분해서 거부하는 것이 아니라 “의미 있는 텍스트”로 처리하려 한다. 이는 결함이라기보다 설계 의도에 가깝다. 문제는 이 특성을 고려..

1. 왜 배포 사고의 대부분은 “몰라서”가 아니라 “안 물어서” 발생하는가대부분의 배포 사고는 기술 부족에서 비롯되지 않는다. 오히려 충분한 경험과 실력을 갖춘 팀에서도 반복적으로 발생한다. 장애가 터진 뒤 돌아보면 항상 비슷한 말이 나온다. “그건 생각 못 했다”, “설마 거기서 문제가 날 줄은 몰랐다”, “그 상황은 가정에 없었다”. 이 말들의 공통점은 명확하다. 문제를 몰랐던 것이 아니라, 배포 전에 그 질문을 스스로에게 던지지 않았다는 것이다.배포는 코드나 모델을 옮기는 행위가 아니라, 불확실성을 사용자에게 넘기는 결정이다. 이 불확실성은 기능 오류일 수도 있고, 비용 폭증일 수도 있으며, 성능 저하나 데이터 누락, 심지어 조직 내부 혼란일 수도 있다. 문제는 이 모든 리스크가 이미 배포 전에 존..

1. LLM A/B 테스트가 실패하는 가장 흔한 이유LLM 기반 서비스에서 A/B 테스트를 시도하는 팀은 많지만, 그 결과를 신뢰하는 팀은 생각보다 적다. 테스트를 했음에도 불구하고 “결론을 내리기 어렵다”거나 “결국 감으로 결정했다”는 말이 반복된다면, 이는 실행력이 부족해서가 아니라 설계 단계에서 이미 실험이 흔들렸기 때문일 가능성이 높다. 특히 프롬프트, 모델, 검색 조합이 동시에 얽혀 있는 경우라면 그 위험은 훨씬 커진다.전통적인 A/B 테스트는 비교적 단순하다. 버튼 색상, 문구, 레이아웃처럼 하나의 변수만 바꾸고 나머지는 고정한다. 그러나 LLM 환경에서는 이 전제가 쉽게 무너진다. 프롬프트를 조금만 바꿔도 모델의 응답 분포가 달라지고, 모델을 바꾸면 검색 결과의 활용 방식이 변하며, 검색 구..