과대광고 없는 AI: LLM을 사용해 잡음을 줄이고, 사고를 대체하지 않기

Source: Dev.to

번역할 텍스트를 제공해 주시면 한국어로 번역해 드리겠습니다. 현재는 소스 링크 외에 번역할 내용이 없습니다. 필요한 본문을 알려 주세요.

Source: (원본 링크는 그대로 유지됩니다)

Part 4 – AI & AppReviews

이 글은 **AppReviews**에 관한 시리즈의 4번째 파트입니다.

• Part 1: From “I should check the reviews” to a SaaS
• Part 2: From feature creep to focus – deciding what AppReviews would never be
• Part 3: Building AppReviews – the stack, the choices, and the compromises

Visuals

“just fetch reviews”에서 “let AI help me see the forest”까지

AppReviews를 만들면서 어느 순간 AI에 대해 생각하기 시작했습니다. “이건 AI가 필요해” 라는 식이 아니라, 조용하고 약간은 마지못해 하는 느낌이었죠.

이미 리뷰를 가져와 Slack에 전달하고, 피드백이 놓치지 않도록 하는 시스템은 갖추고 있었습니다. 그 자체만으로도 핵심 문제는 해결됐습니다. 하지만 리뷰가 언제든지 보이게 되면 새로운 문제가 생깁니다.

리뷰가 정말 많아요.

• 유용한 것도 있고,
• 애매한 것도 있고,
• 감정적인 것도 있고,
• 같은 문제를 약간씩 다르게 표현한 중복도 있습니다.

모든 리뷰를 일일이 읽는 것도 어느 정도까지는 가능하지만, 그 이후엔 다시 스캔하고 훑어보며 머릿속으로 잡음(노이즈)을 걸러내야 합니다.

그때 저는 다른 질문을 스스로에게 던졌습니다:

시스템이 내게 리뷰를 더 빨리 이해하도록 도와준다면 어떨까?
하지만 내 대신 생각해 주는 척은 하지 않는다면 말이죠.

내가 원하지 않았던 것

• AI가 생성한 요약이 인사이트인 척 하는 것
• 설명 없는 마법 점수
• 내 대신 사용자에게 답변하는 챗봇
• 똑똑해 보이지만 의사결정에 도움이 되지 않는 차트가 가득한 또 다른 대시보드

무엇보다도 나는 AI가 제품 자체가 되는 것을 원하지 않았다.

AppReviews는 사용자와 제품 팀 간의 피드백 루프를 단축하기 위해 존재한다. AI는 그 목표를 지원해야 하며, 방해해서는 안 된다.

AI가 매우 구체적인 방식으로 인지 부하를 줄이지 못한다면, 그것은 자리 잡을 수 없다.

AI가 돕는 실제 문제

실제 문제는 하나의 리뷰를 이해하는 것이 아니라,
시간에 걸쳐 많은 리뷰를 이해하는 것입니다.

열 명의 사용자가 같은 문제를 열 가지 다른 방식으로 설명할 때, 사람은 모든 열 개를 읽은 후에 패턴을 잘 파악합니다. 리뷰가 계속 들어오면 이는 확장성이 좋지 않습니다.

제가 원했던 도움은 다음과 같습니다:

• 유사한 피드백 그룹화
• 반복되는 주제 파악
• 감성 추세에 대한 대략적인 인식 얻기
• 무언가가 갑자기 급증할 때 긴급성 드러내기

답변이 아니라—신호입니다.

왜 임베딩을 먼저 사용하고, 프롬프트를 전부에 적용하지 않을까

제가 추가한 첫 번째 빌딩 블록은 임베딩입니다.

모든 리뷰는 그 의미를 포착하는 벡터로 변환할 수 있습니다. 이를 이용하면 키워드나 별점에 의존하지 않고 의미적으로 리뷰를 비교할 수 있습니다.

그렇게 하면 즉시 유용한 것들을 활용할 수 있습니다:

• 유사한 리뷰를 함께 그룹화할 수 있습니다
• 주제가 미리 정의되지 않고 자연스럽게 드러납니다
• “이것은 같은 문제인 것 같다”는 것을 감지할 수 있습니다

임베딩에는 nomic-embed-text를 사용합니다 – 빠르고 로컬이며 이 사용 사례에 충분히 적합합니다. 각 리뷰는 원본 텍스트와 함께 저장되는 768‑차원 벡터가 됩니다.

이 단계만으로도 대형 언어 모델이 텍스트를 생성하지 않아도 이미 가치를 추가합니다.

LLM이 들어가는 위치, 신중히

임베딩 위에 두 번째 선택적 레이어로 대형 언어 모델을 추가했습니다.

제가 사용하는 모델은 Ollama를 통해 로컬에서 실행되는 llama3.1:8b입니다. 이는 의도적인 선택이었습니다:

• 토큰당 비용에 대한 불안감 없음
• 외부 API 의존성 없음
• 내 컴퓨터나 작은 서버에서도 실행 가능

LLM은 매우 구체적인 작업에 사용됩니다:

• 감정 추정
• 고수준 주제 추출
• 어조 감지 (분노, 중립, 긍정)
• 관련 있을 때 긴급성 표시

각 리뷰는 독립적으로 처리됩니다.

• 긴 컨텍스트 없음
• 에이전트 없음
• 오케스트레이션 복잡성 없음

그리고 가장 중요한 점:

이 전체 파이프라인은 선택 사항입니다.

AI 프로세서가 비활성화되었거나 사용할 수 없는 경우에도 AppReviews는 동일하게 작동합니다: 리뷰는 여전히 가져오고, 저장하고, Slack에 전송되며, 대시보드에 표시됩니다. AI는 향상 기능일 뿐, 의존성이 아닙니다.

비동기적이며 격리되고 쉽게 끌 수 있음

아키텍처 관점에서 AI 처리 과정은 핵심 흐름과 완전히 분리되어 있습니다.

1. 리뷰가 먼저 저장됩니다.
2. 그 다음에 분석을 위해 대기열에 넣습니다.
3. 처리는 비동기적으로, 작은 배치 단위로 이루어집니다.
4. 실패는 몇 번 재시도한 뒤에 버려집니다.

Ollama가 실행 중이 아니어도 아무것도 깨지지 않습니다. 사용자에게 보이는 오류가 없으며, 시스템은 단순히 분석을 건너뜁니다.

AI 시스템은 이상한 방식으로 실패합니다. 이러한 문제가 제품의 주요 작업에 영향을 주어서는 안 됩니다.

왜 “AI‑생성 인사이트”가 아닌가

아마도 제가 가장 많이 받는 질문일 겁니다.

“사용자들이 온보딩에 불만을 가지고 있다” 혹은 “대부분의 불만은 성능에 관한 것이다”와 같은 요약을 생성하지 않는 이유는 무엇인가요?”

간단한 답변은 다음과 같습니다:

저는 그것들을 신뢰하지 않습니다.

그러한 요약은 보기에는 좋지만 불확실성을 숨깁니다. 뉘앙스를 압축해 마치 권위 있게 보이게 만들지만 실제로는 그렇지 않을 때도 있습니다.

대신, AppReviews는 원시 신호를 보여줍니다:

• 이 리뷰들은 유사합니다
• 이 주제가 자주 등장합니다
• 감정 …

소리 이 기능이 지난 주에 출시되었습니다

그곳에서 인간이 의미를 결정할 수 있습니다.

AI는 당신이 어디를 봐야 할지 도와주어야지, 무엇을 생각해야 할지를 말해줘서는 안 됩니다.

비용, 제어, 그리고 지루한 결정

Ollama로 모든 것을 로컬에서 실행하는 것이 가장 확장 가능한 선택은 아니지만, 제약 조건에 완벽히 맞습니다.

• 변동 비용 없음
• 예상치 못한 일 없음
• 교체할 API 키가 없음
• 사용자 피드백을 다른 곳으로 보내는 것에 대한 개인정보 문제 없음

If AppReviews가 성장하면 AI 백엔드를 교체하는 것이 비교적 쉽습니다—인터페이스가 이미 분리되어 있기 때문입니다.

현재로서는 이 설정이 예측 가능하고 제어 가능하다는 것이 중요합니다. 이는 정확도의 마지막 퍼센트를 짜내는 것보다 더 큰 의미가 있습니다.

What AI does not do, on purpose

To be very clear, AppReviews does not:

• 자동으로 리뷰에 답변한다
• 어떤 피드백이 중요한지 결정한다
• 리뷰 읽기를 대체한다
• 사용자 행동을 예측한다
• 제품 결정을 생성한다

AI does not:

• 사용자와 대화한다
• 그들을 대신해 행동한다
• 인간 판단을 무시한다

그것은 단지 반복을 줄이고 패턴이 더 빨리 드러나도록 도와줍니다.

지금까지의 결과

실제로, 이 접근법은 놀라울 정도로 잘 작동합니다.

• 여전히 리뷰를 읽습니다.
• 여전히 직접 답변합니다.
• 여전히 결정을 내립니다.

하지만 더 많은 맥락과 덜한 잡음으로 이를 수행합니다.

그리고 그것이 제가 편안하게 약속할 수 있는 유일한 약속입니다.

1. 인간 워크플로우부터 시작합니다.
2. 주의가 낭비되는 지점을 파악합니다.
3. 그런 다음 AI가 이를 줄이는 데 도움이 될 수 있는지 확인합니다.