사용자 문의를 보면 보통 하나의 글에서 서로 다른 여러 가지 문맥이 섞여 있는 경향을 확인할 수 있습니다.
"이번 이벤트 보상은 괜찮은데, 업데이트 후로 자꾸 로그인이 안 돼요. 이것부터 먼저 해결해 주실 수 있나요?"
예를 들자면 위의 예시 내용입니다. 여기에 '긍정' 또는 '부정' 라벨을 단 하나만 붙여야 한다면, 운영팀은 여전히 다음에 무엇을 해야 할지 알 수 없습니다. 사용자가 인정한 것은 이벤트 보상이고, 겪고 있는 것은 로그인 문제이며, 지금 당장 필요한 것은 도움입니다. 이 신호들을 각각 따로 식별해야, 비로소 알맞은 프로세스로 답변을 처리 할 수 있습니다.
최근 주목받는 Jev를 보며 한 걸음 더 나아간 질문을 하게 됐습니다. AI 에이전트가 일하는 과정에서 나오는 이런 구체적인 판단을, 더 적합한 모델에게 맡길 수는 없을까요?
1. Jev는 어떠한 기능을 제공하나
Jev는 TypeSafe가 선보인 System One 모델입니다. 간단하게 설명하면, 비즈니스 맥락과 명확하게 정의된 질문을 주면, 프로그램이 그대로 사용할 수 있는 판단 결과와 확률을 돌려줍니다. 예를 들어 여러 개의 후보 중 하나를 고르거나, 어떤 조건이 성립하는지 아닌지 판단하거나, 이미 정해져있는 등급에 따라 점수를 매기는 식입니다.
이런 출력은 소프트웨어 프로세스에 바로 끼워 넣기에 적합합니다. 같은 피드백 한 건을 두고 "사용자가 무엇에 대해 말하는가", "어떤 대상에 불만이 있는가", "도움을 명시적으로 요청했는가"를 각각 따로 묻고(병렬식), 답을 프로그램이 조합하면 됩니다. 여러 주제가 얽혀 있을 때도 주제마다 성립 여부를 하나씩 판단하되, '기타'나 '불확실'이라는 출구를 남겨 둘 수 있습니다.
GPT 같은 범용 대형 언어 모델(LLM)은 계속해서 복잡한 과제를 이해하고, 분석을 구성하고, 콘텐츠를 생성하고, 결과를 설명하는 일을 맡습니다. Jev는 그보다는 범위가 명확하고 반복적으로 등장하는 판단을 담당합니다. 그리고 Agentic Engine이 기업 데이터, 비즈니스 지식, 스킬(Skills), 실행 프로세스를 제공하며 서로 다른 모델의 결과를 이어 붙입니다.
2. Agentic Engine 전방위 인사이트: 피드백 한 건마다 더 쓸모 있는 신호를 남기다
사용자의 피드백을 볼 때 중점으로 봐야 할 것은 감정의 좋고 나쁨만이 아닙니다. 같은 게시글 하나가 이벤트의 긍정적인 반응을 남기면서도 동시에 특정 문제에 불만을 담고 있을 수 있기 때문입니다. 이런 태도를 총점 하나로 정리한다면, 이후 처리 과정에서 중요한 정보를 잃기 쉽습니다.
ThinkingAI팀은 피드백 샘플 6건을 준비하고, Jev가 각 피드백에 대해 네 가지 질문을 대입해 평가하게 했습니다.
- 긍정 평가가 포함되어 있는가?
- 제품 문제를 반영하는가?
- 도움을 명시적으로 요청하는가?
- 결제와 관련이 있는가?
한 건의 피드백이 여러 항목에 동시에 해당할 수 있으며, 반드시 하나의 카테고리에만 넣을 필요는 없습니다.
예를 들어 "이번 이벤트 보상은 괜찮은데, 업데이트 후로 자꾸 로그인이 안 돼요. 이것부터 먼저 해결해 주실 수 있나요?"라는 문의 글을 Jev에게 입력하면, Jev는 1,2,3 세 항목에 높은 점수를, 4번의 '결제 관련'에는 낮은 점수를 줬습니다. 이 문장에 대응해 보면, 보상은 인정하고, 로그인 장애를 겪고 있으며, 도움을 원하고, 결제 언급은 없다는 뜻입니다. 물론 이 점수는 각 판단에 대한 모델의 지지 정도를 나타내는 것이지, 정확도가 아닙니다.
이어서 출력을 미리 정해 둔 라벨과 항목별로 비교했더니, 24개 판단 중 21개가 일치했습니다. 나머지 3개는 의견이 갈렸는데, 이는 라벨 정의를 더 명확히 해야 한다는 문제도 함께 드러냈습니다.
그 다음에는 본문이 더 명확한 커뮤니티 게시글 2건을 골랐습니다. 하나는 같이 게임할 사람을 찾는 글로, 본문은 주로 플레이 성향과 파티 조건을 설명하고 있었습니다. Jev는 이를 '파티·소셜'로 분류하고, 파티원 모집과 캐주얼 플레이 선호 같은 신호를 식별해 냈습니다.
다른 하나는 이벤트 대회를 다룬 글이었습니다. 사용자는 대회 방식이 '꽤 재미있다'고 느끼면서도, 유명 선수를 더 많이 초대했으면 좋겠다고 의견을 남겼습니다. Jev는 이를 '긍정·부정 공존'으로 판단하고, 대회 방식에 대한 관심과 출전 라인업에 대한 요구를 따로 뽑아냈습니다.
운영팀에게 이런 분리의 가치는 다음 단계로 이어서 처리할 수 있다는 데 있습니다. 구체적인 주제 별로 피드백을 추적하고, 사용자가 무엇을 긍정하고 무엇이 바뀌길 바라는지 구분한 뒤, 버전·이벤트·사용자 행동과 결합해 후속 조치 여부를 정하는 것입니다. 범용 LLM은 이를 바탕으로 문제를 정리하고 변화를 설명할 수 있습니다. Jev는 그 안에서 경계가 분명한 라벨 판단을 맡습니다.
3. Agentic Engine 자동화 운영: 플로우 캔버스에 시맨틱 조건을 더하다
기존의 타깃 세그먼트 추출은 행동과 비즈니스 규칙에 따라 최근 활동이 줄었거나 아직 핵심 액션을 완료하지 않은 사용자를 찾아낼 수 있습니다. 하지만 같은 허들에 막혔다고 해서, 모두 같은 종류의 도움이 필요한 것은 아닙니다.
모바일 게임 이탈 유저 리텐션 검증에서, 저희는 시맨틱 레이어가 플레이어의 최근 피드백을 읽고 미리 정의된 처리 방안 중 하나를 고르게 했습니다. 조작 안내가 필요한 플레이어는 공략 푸시를 보내고, 오류를 겪은 플레이어는 CS 처리로 보낸 뒤 내부 규정에 따라 보상 여부를 결정합니다. 메시지를 받고 싶지 않다고 분명히 밝힌 플레이어는 수신 거부 경로로, 미리 정의된 프로세스를 벗어난 것 같은 의견은 담당자 검토로 넘깁니다.
테스트에서는 플레이어 피드백 8건을 Jev에 넘기고, 공략 안내·CS 처리·수신 거부·담당자 검토라는 네 가지 처리 경로를 선택지로 제공한 뒤, 피드백마다 하나를 고르게 했습니다. "이 기능은 아직 쓸 줄 모르겠어요"에는 '공략 안내'를, "여기까지 하면 오류가 나요"에는 'CS 처리'를, "요즘은 필요 없으니 그만 보내 주세요"에는 '수신 거부'를 돌려줬습니다. 8건의 분류 결과는 모두 사전에 설정한 예상과 일치했습니다.
그 중에서 한 건은 "다음 시즌은 언제 열려요? 만렙 찍고 할 게 없어요"였습니다. 조작이나 장애 문제를 제기한 것도 아니고, 메시지 수신 중단을 요구한 것도 아닙니다. 이번에 제공한 분류 규칙에 따라 Jev는 '담당자 검토'를 돌려줬습니다. 현재 처리 경로가 다루지 않는 요구에 대해서도 Jev의 선택은 마찬가지로 정확했습니다.
이 협업 구조에서 Agentic Engine의 규칙은 어떤 사용자가 프로세스에 들어올지 결정하고, Jev는 사용자의 표현이 어떤 경로에 더 잘 맞는지 판단을 돕습니다. 범용 LLM은 경로 이후의 전략 설명과 콘텐츠 생성에 참여합니다. 실제 발송·보상·실행은 여전히 기업이 설정한 권한, 발송 빈도 제한, 승인 절차의 통제를 받습니다. 모델의 분류 결과 자체가 비즈니스 액션을 승인하지는 않습니다.
전략이 효과적인지는 실행 후의 클릭, 전환, 리텐션, 사용자 피로도를 관찰하고 실험으로 비교해야 알 수 있습니다. 모델이 피드백 한 건을 특정 경로로 분류한 확률을, 그 전략이 전환을 높일 확률로 바로 받아들여서는 안 됩니다.
4. Agentic Engine 시맨틱 레이어: 데이터를 조회하기 전에 기준부터 분명히
자연어로 데이터를 조회할 때도 명확히 해야 할 판단들이 들어 있습니다.
"요즘 신규 사용자 결제율은 어때?"는 간단하고 명료한 질문처럼 보입니다. 하지만 '신규 사용자'는 가입 기준일까요, 첫 로그인 기준일까요? '요즘'은 어느 기간일까요? 결제율은 당일을 볼까요, 가입 후 7일을 볼까요? 기준이 달라도 숫자는 하나씩 나오지만, 그 비즈니스 의미는 매우 다릅니다.
저희가 구축 중인 프로젝트 시맨틱 레이어는 지표 정의, 비즈니스 용어, 데이터 출처, 사용 규칙을 에이전트가 재사용할 수 있는 맥락으로 정리하는 데 초점을 둡니다. 이 질문을 두고 소규모 샘플 검증을 두 단계로 나눠 진행했습니다. 조회 전에는 기준을 고르고 빠진 조건을 찾아내는 것, 조회 후에는 문장으로 된 결론이 주어진 데이터로 뒷받침되는지 확인하는 것입니다.
첫 번째 단계에서는 실제 프로젝트에서 가져온 이벤트 후보 4개를 제공했습니다. 계정 가입, 앱 설치, 온보딩 완료, 사용자 로그인입니다. Jev는 이 사례의 신규 사용자 기준으로 '계정 가입'을 골랐고, 동시에 '요즘'에 명확한 기간 범위가 없어 추가 확인이 필요하다는 점을 짚어 냈습니다. 이 결과는 Jev가 후보 선택을 도울 수 있음을 보여 줍니다. 다만 '신규 사용자'에 대한 기업의 공식 정의는 여전히 시맨틱 레이어가 제공해야 합니다.
두 번째 단계에서는 이번 주 4.2%, 지난주 4.4%라는 두 기간의 결과를 주고, "결제율은 약 4.2%로, 지난 4주간 계속 하락했다"라는 문장을 검증하게 했습니다. Jev는 입력과 일치하는 4.2%는 그대로 두면서, '4주간 계속 하락'이라는 서술은 부정했습니다. 2주치 데이터만으로는 4주 추세를 도출할 수 없기 때문입니다.
이 검증은 Jev 실무 활용에서의 구체적인 방향 하나를 제시합니다. 사용 권한이 있고 거버넌스를 거친 후보 지표와 자산 안에서 선택을 돕고 조건이 불완전하면 먼저 되묻고, 결과가 나온 뒤에는 기간 범위·지표 의미·문장 결론이 서로 대응하는지 다시 확인하는 것입니다.
샘플 몇 건을 확인했다고 해서 모델의 검산을 믿을 수 있다고 보장할 수는 없습니다. 그래서 수치 계산, 날짜 비교, 수치 일관성 검사, 쿼리 실행처럼 정확성이 중요한 작업은 여전히 데이터 엔진과 규칙 기반 프로그램이 맡습니다. Jev가 검사를 돕는 것은 기준과 문장의 의미가 서로 맞는지 확인하는 것입니다. 지표를 잘못 고르거나, 조건을 빠뜨리거나, 결론이 근거 범위를 벗어나는 일을 줄이는 것. 이것이 저희가 앞으로 더 많은 실제 문제에서 검증해 나갈 목표입니다.
ThinkingAI에게 이번 Jev 검증의 핵심은, 모델의 판단을 기업이 이미 갖고 있는 데이터·지식·비즈니스 프로세스에 연결해 핵심 단계를 점검하고 재검토할 수 있게 만드는 것이었습니다.
저희는 Jev를 기존 프로세스에 이식해 실무에 충분히 활용할 수 있다는 결론을 내렸습니다. 다만 이번 검증에서 라벨 기준과 경계 사례 판단에 관한 과제도 확인했습니다. 다음 과제로는 비즈니스 샘플을 늘리고, 재검토 메커니즘을 보완하며, 실제 프로세스 안에서 효과를 검증할 계획입니다.
대량의 사용자 피드백을 처리하고 계시거나, 운영 흐름을 더 세분화하려 하시거나, 자연어 데이터 조회에서 기준이 모호해 고민이거나, Jev를 실무에서 사용할 수 있을지 고민 중이시라면, 간단한 비즈니스 시나리오 하나만 가지고 저희와 이야기를 나눠 보세요.
