조용한 개발 노트

6편까지의 결론은 명확하다.LLM은 언제든 틀릴 수 있고, RAG를 붙여도 그 가능성은 사라지지 않는다.이 지점에서 다음 질문이 나온다.“그럼 이걸 어떻게 운영에 넣을 수 있는가?”1. LLM 출력은 항상 실패할 수 있다는 전제부터 깔아야 한다LLM 기반 시스템에서 가장 위험한 가정은 이거다.“대부분은 맞을 것이다”운영 관점에서는 이 문장이 이렇게 번역된다.“언젠가는 반드시 사고가 난다”그래서 LLM 출력은 처음부터 이렇게 다뤄야 한다.항상 틀릴 수 있다틀렸을 때 감지할 수 있어야 한다감지했을 때 피해가 제한돼야 한다이게 가드레일의 출발점이다.2. 출력 검증은 “맞는지 확인”이 아니라 “위험한지 감지”다많은 팀이 출력 검증을 이렇게 접근한다.“정답인지 확인하자”대부분 실패한다. 정답 여부를 자동으로 판단..

3편까지의 내용을 받아들이면, 프롬프트에 대한 기대부터 바뀌어야 한다.프롬프트는 모델에게 “잘 설명하면 알아서 이해하는 글”이 아니다. 확률 분포를 유도하기 위한 입력 인터페이스다.이 관점을 놓치면, 프롬프트를 계속 고치는데도 시스템은 안정되지 않는다.1. 왜 프롬프트는 항상 기대를 배신하는가프롬프트를 작성하다 보면 이런 경험을 한다.어제까지 잘 되던 프롬프트가 오늘은 흔들린다설명을 더 붙였는데 오히려 결과가 나빠진다사소한 표현 변경으로 출력 성격이 바뀐다이건 프롬프트를 잘못 써서가 아니다. 프롬프트에 지나친 책임을 맡기고 있기 때문이다.2. 자연어는 계약이 될 수 없다사람끼리는 자연어로도 계약을 맺을 수 있다. 맥락, 상식, 책임이 공유되기 때문이다.하지만 LLM과는 그렇지 않다.자연어 프롬프트에는 다..