3년차 백엔드가 AI 붙이면서 느낀 것들 정리해봄
작년부터 사내 서비스에 LLM 기능 이것저것 붙여보면서 느낀 걸 좀 적어봅니다. 결론부터 말하면 '모델 성능'보다 '입력 설계'가 훨씬 중요했습니다.
처음엔 프롬프트를 예쁘게 다듬는 게 답인 줄 알았는데, 실제로 장애 나고 CS 들어오는 지점은 거의 다 데이터 쪽이었어요. 사용자가 넣는 텍스트에 뭐가 들어올지 모르는데 모델만 탓하고 있었던 거죠.
제가 지금 쓰는 원칙은 이 정도입니다.
- 모델은 언제든 교체 가능하다고 가정하고 인터페이스를 얇게 유지
- 프롬프트는 코드가 아니라 별도 파일로 분리해서 버전 관리
- 출력은 무조건 스키마 검증 통과해야 저장
- 실패 케이스는 전부 로깅해서 주기적으로 프롬프트에 반영
특히 마지막 항목이 제일 효과 컸습니다. 처음 두 달치 실패 로그 300건 정도 모아서 보니 패턴이 딱 세 가지로 수렴하더라고요. 그거 고치니까 체감 품질이 확 올라갔습니다.
비용 얘기도 빼먹을 수 없는데, 캐싱 없이 돌리다가 한 달에 200만원 나온 적 있습니다. 지금은 동일 입력 해시 기준으로 캐시 태우고, 간단한 분류는 소형 모델로 내려서 15만원 수준까지 줄였어요.
AI 엔지니어라는 직군이 따로 있는 게 부럽기도 하고, 그냥 백엔드가 다 하는 시대인가 싶기도 하고 그렇네요.
9 개의 답변
ㅇㅈ 입력 설계가 진짜 8할임. 모델 갈아끼우는 것보다 들어오는 데이터 정제하는 게 훨씬 오래 걸리더라
실패 로그 300건에서 패턴 세 개로 수렴했다는 부분 좀 더 풀어줄 수 있음? 나도 비슷하게 쌓아두긴 했는데 분류를 못 하겠어서
글쎄 그건 좀. 입력 설계 강조하는 건 맞는데 '모델 성능보다'라고 단정할 정도인가 싶음. 태스크 난이도에 따라 다르지 않나
우리 팀은 프롬프트랑 입력 다 잡아도 모델 자체 추론 한계로 못 넘는 케이스가 계속 나왔음. 그건 데이터 문제가 아니었음
프롬프트 별도 파일로 빼는 거 진짜 공감. 코드에 문자열로 박아놨다가 diff 지옥 되는 거 한 번 겪으면 다들 그렇게 함ㅋㅋ
비용 200만원 실화냐 ㅋㅋ 캐싱만 붙여도 반은 줄던데
출처 있음?
스키마 검증 항목은 진짜 필수인 게, 검증 없이 저장했다가 나중에 잘못된 값이 DB에 눌러앉아서 데이터 정제 스크립트 따로 짠 적 있음. 그 뒤로는 pydantic이든 뭐든 무조건 통과시키고 넣습니다. 실패율도 같이 지표로 뽑아두면 프롬프트 바꿨을 때 회귀 잡기도 편하고요. 로깅은 어떤 포맷으로 남기세요? 저희는 입출력이랑 모델 버전까지 같이 남기는데 로그가 너무 커져서 보관 주기랑 비용 때문에 고민 중입니다
동의 안 됨. 요즘 나오는 모델들은 알아서 웬만한 입력은 잘 처리하는데, 굳이 그렇게까지 입력을 깎아야 하나 싶음. 오히려 과하게 정제하면 사용자가 의도한 뉘앙스가 날아가서 결과가 더 밋밋해지는 경우도 많았음
'모델은 교체 가능하다고 가정하고 인터페이스 얇게' 이거 진짜 핵심인 듯. 저희는 처음에 특정 벤더 SDK에 로직이랑 다 엮여 있어서 나중에 다른 모델로 바꾸려니까 거의 다 뜯어고쳤습니다. 그 이후로는 어댑터 한 겹 두고 내부는 우리 포맷으로만 다루게 바꿨어요. 님 글처럼 실패 케이스 주기적으로 보고 프롬프트 반영하는 루프까지 돌리면 진짜 다르더라고요