LLMOps

LLMOps는 LLM을 쓰는 앱을 개발·배포·운영하면서 프롬프트 버전, 응답 품질, 토큰 비용을 관리하는 방법이다. 프롬프트 한 줄만 바꿔도 동작이 달라지는 LLM 앱을 시제품을 넘어 실제 사용자에게 서비스할 때 본격적으로 필요하다.

프롬프트도 코드처럼 버전을 남긴다

LLM 앱에서는 프롬프트가 곧 소프트웨어다. 누가 언제 어떤 프롬프트를 바꿨는지 기록해 두어야, 품질이 떨어졌을 때 원인을 찾고 이전 버전으로 되돌릴 수 있다. 프롬프트를 코드 곳곳에 흩어 두지 말고 한곳에서 버전별로 관리하며, 지금 어느 버전이 운영 중인지 분명히 해 둔다.

모델을 바꾸는 일도 같은 무게로 다룬다. 같은 프롬프트라도 모델이 바뀌면 답의 형식과 품질이 달라질 수 있어서다.

도구를 연결하면 모든 호출이 기록된다

LangSmith, Langfuse, Phoenix(Arize), Helicone 같은 도구를 앱에 연결하면 LLM 호출마다 입력과 출력, 응답 지연, 토큰 비용이 자동으로 쌓인다. 예를 들어 LangChain 앱에 LangSmith를 연결하면 별도 코드 없이 호출이 추적된다. 여러 단계를 거치는 에이전트나 RAG 앱은 트레이스를 따라가며 어느 단계가 느리고 어디서 틀렸는지 찾을 수 있다.

바꾸기 전에 같은 테스트셋으로 비교한다

프롬프트나 모델을 바꿀 때는 감으로 판단하지 않는다. 대표 질문과 기대 답을 모은 테스트셋을 만들어 두고, 변경 전후로 똑같이 돌려 결과를 비교한다. 채점은 사람이 직접 하거나, 기준을 정해 다른 LLM에게 맡기는 방식을 함께 쓴다.

운영 중에는 기준에 못 미친 응답에 태그를 달아 이슈로 관리하고, 그 사례를 테스트셋에 다시 넣는다. 그러면 다음 변경 때 같은 실수가 반복되는지 바로 확인할 수 있다. 새 버전을 일부 사용자에게만 먼저 내보내는 A/B 테스트도 자주 쓰는 방법이다.

작게 시작하고, 로그 속 개인정보를 조심한다

혼자 써 보는 시제품이라면 무거운 체계는 필요 없다. 호출 로그와 비용 추적부터 붙이고, 사용자가 늘면 평가 파이프라인을 더하는 순서가 현실적이다.

로그에는 사용자가 입력한 내용이 그대로 남는다. 개인정보나 민감한 데이터는 가리거나 보관 기간을 정해 두고, 외부 서비스형 도구를 쓴다면 데이터가 어디에 저장되는지 먼저 확인한다. 필요하면 직접 설치해 쓸 수 있는 도구를 고른다.

챗봇·RAG·에이전트 운영에 붙여 쓴다

가장 흔한 방식은 이미 서비스 중인 LLM 앱에 추적 도구와 테스트셋을 붙여 두는 것이다. 문제가 생기면 트레이스로 원인을 찾고, 고친 뒤에는 테스트셋으로 확인하고 내보낸다.