처음 해보는 LLM 서비스 기획기 - 1편
LLM 활용 원리와 비용 시뮬레이션
최근 회사에서 LLM을 도입한 정보 탐색 서비스를 오픈했다. 유저가 질문하면 LLM이 정보 탐색에 필요한 데이터를 뽑아주고, 유저가 원하는 정보를 찾아다 화면에 노출해 주는 구조다. GPT 하드유저지만 이걸 서비스에 활용한다는 건 다른 얘기였다. 처음 개발팀과 어떻게 개발할 건지 구조적 이야기할 때는 이게 뭔 소리야.. 싶었고 아직도 LLM을 활용해 서비스를 만든다는 게 어렵게 느껴진다.
몇주 전 모르는 사우에게 연락이 왔다. LLM 활용한 서비스를 기획할 때 어떤 문제들이 있었는지 이야기를 나눠보고 싶다고 한다. 별것 아닌 경험이라도 누군가에게는 시행착오를 줄일만한 경험이구나 싶어 여기에도 하나하나 정리해보려 한다. LLM을 서비스에 활용할 때 내가 고민했던 포인트들!
첫 번째 편
LLM을 서비스에 어떤 원리로 붙이고, 비용은 또 얼마나 드는거지?
LLM을 활용해 개발한다고 하면 참 막연하다. 그런데 LLM이 들어온다고 (에이전트의 복잡도에 따라 다르겠지만) 개발 구조가 다이나믹하게 변하지는 않는다. 일반적인 온라인 서비스에서 LLM은 사람이 절대 할 수 없는 걸 창의적으로 해결해 준다기보다는, 데이터분석/개발/화면노출 등 공급자의 노동력을 많이 잡아먹던 작업을 편하게 해주는 역할이다. 활용 사례는 다음과 같다.
1) 유저 입력 -> LLM -> 백단 전달
유저의 패턴이나 입력한 정보를 백단에 보내기 전에 LLM이 한번 더 정제 작업해서 데이터를 쉽게 처리해 주도록 하도록 돕는 케이스이다. 내부 구조를 효율화한 거라 겉으로 드러나지 않아 일반 사용자들이 잘 눈치채지 못할 수 있다.
상상의 나래를 펼쳐보면 브런치에 '서비스 기혹'이라고 잘못 검색했을 때 검색결과가 잘 안 나올 텐데 이때 LLM에 이 입력값을 넘겨서 "아 이것은 오타고 최근 유저 검색어 패턴을 살펴보면 '서비스 기획'이라고 검색하고 싶었을 거야" 하고 올바른 검색어로 보정을 해주는 용도로 사용할 수 있겠다.
2) 데이터를 새로운 형식으로 변환
데이터를 유저에게 내보낼 때 새로운 형식으로 생성해서 보내주는 경우다. 예를 들어 네이버지도에서는 기존에 모아둔 유저 리뷰를 모아서 LLM이 분석하도록 일을 시키고, 뽑아낸 요약 결과를 "AI 브리핑"으로 노출해 준다. 이 외로도 글, 이미지 등 콘텐츠를 쉽게 만들어주는 생성형 AI 기능은 대부분 2번 케이스에 속한다.
최근에 방문했던 카페 강추3) 유저와 LLM이 주고받고 대화
이 경우는 1,2번 사례와는 좀 다른데, LLM에 특정한 페르소나를 부여해서 LLM 자체가 서비스가 되는 경우도 있다. 네이버 웹툰의 캐릭터챗이 그 예시다. 중간에 서비스 데이터는 거의 개입하지 않고 LLM과 유저만 대화하도록 한다.
LLM을 활용해 서비스를 기획하겠다는 아이디어만 있고 아직 어떤 방식으로 실행할지 모를 때, 1)데이터 처리 효율화를 할 것인지, 2)다른 형식의 콘텐츠를 생성할 건지, 아니면 3)LLM 자체를 대화상대로 삼도록 할 건지 용도를 구분해 보면 어떤 송수신 포인트에서 얼마나 자주 LLM을 사용할 건지 명확해진다.
그 다음 생각해봐야 할 것은 비용이다. 아래 GPT 모델을 예시로 들면 모델에 따라 10배 이상 비용 차이가 나기도 한다. 만약 쉬운 작업을 맡길 거라면 싼 모델을 사용하고, 퀄리티 있는 작업이라면 비싼 모델을 사용해야 한다. 먼저 대략적인 프롬프트 테스트를 거쳐서 결과 품질을 보고 어떤 모델을 정할지 판단할 수 있다.
GPT가 대답한 모델별 비용토큰은 쉽게 말하면 글자수와 유사한 개념이다. 우리는 글자를 1자 1자 세지만 LLM은 좀 다른 덩어리 단위로 셀뿐, 글자수와 토큰수는 대체로 비례한다.
입력 토큰(Input tokens) : 사용자가 보낸 프롬프트(질문, 대화 이력 포함)를 모델이 읽기 위해 토큰화했을 때의 총 토큰 수
-> 즉 내가 보낸 프롬프트의 길이와 관계있으므로, 프롬프트를 구구절절 길게 하면 안 되고 결과가 안정적으로 나오는 선에서 경량 최적화 테스트 필요
출력 토큰(Output tokens) : 모델이 생성해서 돌려준 답변을 토큰화했을 때의 총 토큰 수
-> 즉 LLM이 응답한 결과물 길이와 관계있으므로, 결과물 형식도 최적화 필요
이때 위에서 설명했던 1,2,3 케이스별로 비용 부담이 생기는 포인트가 좀 다르다.
1) 유저 입력 -> LLM -> 백단 전달, 3) 유저와 LLM이 주고받고 대화
-> 이 경우 유저 호출 때마다 명령을 내리므로 유저당 호출 횟수가 비용 시뮬레이션에 관건이다. 유저 인터랙션이 많이 일어나는 서비스인 경우 이렇게 LLM을 태운다면 비용 부담이 생긴다.
2) 적재한 데이터를 LLM으로 새롭게 변환
-> 네이버 지도처럼 적재된 리뷰를 LLM이 특정한 주기로 분석하도록 하면, 총 데이터양과 업데이트 주기가 비용 시뮬레이션에 관건이다. LLM에 분석을 맡길 데이터가 많을수록 비용 부담이 생긴다. 그래서 업데이트를 최대한 가끔 해서 부담을 줄이는 대안도 있다.
-> 만약 유저 호출 때마다 글이나 사진 같은 콘텐츠를 생성해야 한다면 마찬가지로 호출 횟수가 비용 부담으로 이어진다.
이런 점들을 고려하면 우리의 서비스 개발 구조에서 LLM을 어디에 태울지, 얼만큼 자주 태울지 결정하고 나면 대략적인 비용과 개발 스콥이 나온다.
그럼 이제 실무를 진행할 수 있게 된다!
서비스에 LLM 붙이기 - 2편은 to be continued...
