한 번 분석한 영상을 다시 가져왔는데 또 기다려야 한다면, 이용자는 왜 같은 일을 다시 하는지 궁금할 수 있습니다. 전에 결과까지 받았으니 이번에는 바로 열릴 것이라 기대하기 쉽습니다. 다시 분석하다 실패하기라도 하면, 잘되던 기능을 고장 낸 것처럼 보일 수도 있습니다.
그런데 이전 결과에 문제가 있었다면 어떨까요. 불리거나 재우는 시간을 빼고 계산한 조리시간을 다시 보여주면, 화면은 빨리 열려도 그 시간을 믿고 요리를 고른 사람은 곤란해집니다. 이미 받았던 답이라는 이유로 계속 써도 되는지 고민해야 했습니다.
VidDish의 조리시간 기준을 고칠 때 이 문제가 연결됐습니다. 공개 레시피의 시간을 바로잡아도, 자료를 다시 만드는 과정에서 예전 분석 결과를 가져오면 고친 값을 덮을 수 있었습니다. 그래서 화면에 보이는 숫자를 수정하는 일과 예전 AI 답을 다시 쓸지 정하는 일을 함께 처리했습니다.
같은 결과를 쓰는 데도 이용자에게 이점이 있었다
VidDish는 영상의 재료와 조리 단계를 분석한 결과를 서버에 저장합니다. 같은 영상을 같은 요청 언어로 다시 분석하려 할 때, 쓸 수 있는 결과가 있으면 모델을 새로 호출하지 않고 돌려줍니다. 이런 재사용을 위해 둔 저장소가 캐시입니다.
이용자에게는 기다리는 작업 하나가 줄어듭니다. 개발하는 쪽에서도 같은 내용을 반복해서 분석하는 비용을 피할 수 있습니다. 이미 쓸 만한 답이 있는데 매번 다시 물으면, 재료 이름이나 단계가 조금씩 달라질 가능성도 생깁니다.
그렇다고 한 번 저장한 답을 끝까지 쓰기로 할 수는 없었습니다. 설명에서 재료 몇 개만 얻었던 영상에 이번에는 자막도 들어올 수 있습니다. 전에 조리 단계를 못 뽑았는데 이번 입력으로는 채울 수 있을지도 모릅니다. 이용자는 같은 영상을 가져왔어도, 앱이 분석할 수 있는 자료는 달라진 셈입니다.
현재 코드는 이런 경우에 다시 분석합니다. 새로 자막이 들어왔는데 이전 결과는 설명만 읽었거나, 자막으로 분석했던 결과에 조리 단계가 비어 있다면 그대로 돌려주지 않습니다. 재료 목록이 비어 있는 문서도 재사용 대상에서 뺍니다. 빠르게 돌려줄 수 있다는 이유만으로 빈 결과를 계속 내보내지는 않도록 한 것입니다.
날짜보다 바뀐 기준을 먼저 봤다
조리시간 문제는 자료가 더 들어온 경우와도 달랐습니다. 같은 자료를 읽더라도 무엇을 시간에 넣을지에 대한 앱의 기준이 바뀌었습니다. 예전에는 빠졌던 필수 대기를 이제 포함해야 했습니다.
‘하루가 지나면 다시 분석한다’고 정해도 이 문제에는 맞지 않았습니다. 예전 기준으로 만든 답이라면 방금 저장했어도 고칠 대상입니다. 반대로 규칙과 입력이 그대로인 답을 하루 지났다는 이유만으로 버리면, 이용자는 달라질 이유가 없는 결과를 다시 기다리게 됩니다.
그래서 분석 결과에 규칙의 버전과 모델 이름을 남기고, 이번 요청에 쓸 것과 맞는지 확인하도록 했습니다. 조리시간처럼 결과의 뜻이 바뀌는 수정에서는 버전도 함께 올립니다. 프롬프트 문장만 고치고 이 표시를 그대로 두면, 서버는 예전 답을 쓸 수 있다고 판단해 모델을 부르기 전에 돌려줄 수 있습니다.
이용자에게 버전 번호를 알려줄 필요는 없습니다. 다만 앱에서 분석을 개선했다고 안내하려면, 실제로 받는 결과에도 그 변경이 적용돼야 합니다. 새로 가져온 영상만 달라지고 전에 가져온 영상은 그대로라면, 이용자가 느끼는 개선은 제각각일 수밖에 없습니다.
다시 분석하다 실패하면 어떻게 할까
예전 답을 건너뛰기로 하면 그다음 문제가 생깁니다. 모델이 응답하지 않거나 분석이 실패할 때, 전에 받아 둔 답이라도 보여줄 것인지입니다.
현재 분석 함수는 새 기준에 맞지 않는 캐시를 건너뛴 뒤 재분석합니다. 그 요청이 실패하면 오류를 반환합니다. 예전 답을 꺼내 성공한 응답처럼 돌려주는 처리는 없습니다.
잘못된 조리시간을 고치는 상황에서는 이 동작을 이해할 수 있습니다. 새 분석이 실패할 때마다 옛 시간을 돌려주면 이용자는 어느 값을 믿어야 할지 알기 어렵습니다. 하지만 이용자에게는 ‘전에는 되던 영상인데 오늘은 안 된다’는 경험이 될 수도 있습니다. 수정이 필요한 답을 막은 결과, 이번 요청에서는 결과를 받지 못하게 됩니다.
예전 결과에 ‘이전 분석’이라는 표시를 붙여 보여주는 방법도 있습니다. 다만 표시 하나로 충분한지는 다시 따져야 합니다. 그 답을 보고 장을 보거나 조리시간으로 요리를 고를 수 있는데, 앱은 고쳐야 한다고 아는 정보를 계속 제공하게 됩니다. 어떤 내용은 참고용으로 남겨도 되고 어떤 내용은 사용을 막을지, 실제 행동을 기준으로 나눠야 합니다. 현재 함수에는 이런 별도의 제공 방식이 없습니다.
이 흐름을 다시 기획한다면, 기다리는 동안에는 이전 결과를 고치기 위해 재분석 중이라는 사실을 알리고 싶습니다. 실패한 뒤에는 분석을 다시 시도할지, 가져오기를 그만둘지 선택할 수 있게 하고 싶습니다. 무엇을 다시 하는지도 설명하지 않은 채 같은 링크를 계속 넣게 만들면, 캐시를 고친 이유가 이용자에게는 전달되지 않습니다. 현재 함수가 오류를 반환하는 것에 더해 필요한 안내입니다.
고친 답이 계속 유지되는지도 봐야 했다
조리시간을 고칠 때는 이미 공개한 레시피의 값을 다시 매기는 작업과, 이후 분석에서 예전 캐시를 허용하지 않는 작업을 나눴습니다. 이용자가 지금 보는 답을 고치는 것과 다음에 같은 자료를 만들 때 수정이 유지되게 하는 일이었습니다.
분석 버전만 올려서는 기존 공개 레시피가 저절로 바뀌지 않습니다. 반대로 공개 레시피만 고쳐두고 예전 분석을 계속 허용하면, 나중에 자료를 다시 만드는 작업이 그 값을 되돌릴 수 있습니다. 당시에는 공개된 시간도 고치고, 사용자 요청과 관리용 자료 생성이 함께 쓰는 분석 버전도 올렸습니다.
그래도 같은 버전이라는 이유만으로 모든 재사용을 믿을 수는 없습니다. 이미 자막으로 분석한 영상에서 자막 내용이 달라져도, 현재 영상용 캐시는 그 원문 전체가 바뀌었는지 대조하지 않습니다. 이번에 한 일은 앱의 분석 기준이 달라졌을 때 옛 답을 그대로 쓰지 않게 한 것입니다.
이제 남은 고민은 다시 기다리거나 실패하게 되는 이유를 어떻게 알릴지입니다. 서버는 기준에 맞지 않는 옛 답을 거절하지만, 이용자는 그 기준이 바뀌었다는 사실을 모를 수 있습니다. 결과를 고치는 작업에 더해, 왜 전에 되던 요청을 다시 해야 하는지 설명하는 일이 남아 있습니다.