아프니까 개발자다 아프니까 개발자다

코드 위키를 한 달 운영해 보면 같은 장면이 두세 번 반복된다. 누군가가 위키를 열어 "이 함수의 동작이 이렇다"라는 문장을 읽고, 안내된 위치로 가 보면 그 함수가 거기에 없다. 같은 이름의 다른 함수가 있거나, 함수가 다른 파일로 옮겨졌거나, 아예 삭제되었거나. 위키 본문은 자신만만하게 적혀 있고, 코드는 그 자신감을 배신한다.이 장면이 사람 독자에게는 짜증나는 정도지만, AI 에이전트에게는 다르다. 에이전트는 RAG(Retrieval-Augmented Generation) — 질문이 들어오면 외부 지식 베이스에서 관련 문서를 먼저 검색해 가져온 뒤 그걸 prompt에 끼워 답을 만드는 패턴 — 으로 동작한다. 위키가 가져다 준 문장을 ground truth(검증된 사실)로 받아 그 위에서 추론한다...

RAG를 만들었다 — 그런데 이게 잘 되는 건가?RAG(Retrieval Augmented Generation) 파이프라인을 구축하면 자연스럽게 드는 질문이 있습니다. "이 시스템이 진짜 잘 동작하고 있는 건가?"임베딩 모델을 바꿔봤는데 더 나아진 건지, 청킹 전략을 변경했는데 효과가 있는 건지, 체감으로는 알기 어렵습니다. 그렇다고 매번 사람이 질문 100개를 던져보고 답변을 일일이 채점할 수도 없고요.바로 이 문제를 해결하기 위해 등장한 것이 RAGAS(Retrieval Augmented Generation Assessment)입니다.RAGAS가 나오기 전 — RAG 평가의 한계RAGAS 이전에 RAG 시스템을 평가하려면 크게 세 가지 방법뿐이었습니다.1. 사람이 직접 채점: 정확하지만 느리고 비쌉니..