Agent는 이용 단계·GA·사용자 기록을 어떻게 의사결정으로 바꿀까

Google Analytics 4(GA4)에서는 사용자가 어느 화면까지 왔는지 확인할 수 있습니다. 서비스 기록에는 요청의 성공 여부와 오류 지점이, Agent 대화 기록에는 사용자의 기대와 망설임이 남습니다.

데이터는 충분했지만, 세 기록이 답하는 질문은 서로 달랐습니다.

• GA4에는 사용자가 어디에서 멈췄는지​가 남습니다.
• 서비스 기록에서는 제품 안에서 무슨 일이 일어났는지​를 확인합니다.
• Agent 대화와 작업 기록에는 그 과정에서 무엇을 묻고 어떻게 처리했는지​가 남습니다.

셋을 한 화면에 모은다고 곧바로 의사결정이 되지는 않습니다. 분석 대상의 범위와 사용자를 구분하는 기준이 다르고, 같은 이름의 행동 기록도 뜻이 다를 수 있습니다. 특정 화면에 도착한 사용자 수를 순서가 있는 전환율처럼 읽거나, 반복 방문자의 누적 대화를 첫 방문의 원인처럼 해석할 수도 있습니다.

고객 집단(세그먼트) 분석도 이 세 기록에서 출발했습니다. 신규·재방문·이탈 위험 사용자를 나누고 각 집단이 서비스 이용 단계를 어떻게 통과하는지 비교했습니다. 집단 이름만 붙이는 데 그치지 않고, 첫 사용 안내·재방문·이탈 방지 중 어디에 어떤 조치를 적용할지 정하는 단위로 삼았습니다.

목표는 데이터 요약보다 긴 흐름에 있었습니다. 데이터를 검사하고 답할 수 있는 질문만 분석한 뒤, 근거와 한계가 붙은 실행안을 만들고 같은 기준으로 결과를 다시 측정하는 Agent를 설계했습니다.

이 글에서는 BA(Business Analyst, 비즈니스 분석) Agent를 설계하며 정리한 분석 운영 구조를 소개합니다. 핵심은 한 줄로 정리할 수 있습니다.

분석 Agent의 결과물은 보고서가 아니라, 근거와 한계가 붙은 의사결정 흐름입니다.

세 데이터는 같은 사용자를 서로 다르게 봅니다

GA4 행동 자료에는 서비스를 방문한 사용자의 흔적이 남습니다. 아무 말 없이 떠난 사용자도 페이지 방문과 이탈 지점은 남깁니다. 반면 대화 기록에는 질문을 입력하고 Agent와 대화를 주고받은 사용자만 나타납니다. 서비스 기록은 이 둘과 또 다르게, 저장이나 요청 처리처럼 서버가 확인한 사건을 중심으로 남습니다.

검증 설계 원칙입니다. 세 데이터는 서로 다른 질문에 답하며, 조건을 통과한 경우에만 하나의 여정으로 묶습니다.

분석 대상 범위의 차이를 무시하면 설명은 그럴듯해도 결론이 어긋납니다. 이탈 원인을 대화 기록에서만 찾는 순간, 남아서 질문한 사람의 기록으로 말없이 떠난 사람을 설명하게 됩니다. GA4의 행동별 도달 수를 그대로 이어 붙이면 실제 순서와 상관없이 단계별 전환율처럼 보입니다. 대화 기록에서 반복된 주제 역시 재방문의 원인으로 단정할 수 없습니다.

저희는 세 데이터를 바로 합치지 않았습니다. 각 데이터가 답할 수 있는 질문부터 나눈 뒤, 연결 조건을 충족한 기록만 하나의 사용자 여정으로 묶습니다.

연결값은 행동, 저장 결과, Agent 작업을 같은 사용자의 여정으로 설명할 수 있는지 가르는 기준입니다. 연결값이 맞지 않으면 Agent는 빈칸을 추측으로 채우지 않고 해당 질문을 측정 과제로 돌려보냅니다.

실제 점검에서도 저장 기록을 바탕으로 한 이용 단계 자료는 비어 있었고 Agent 작업 기록은 별도로 존재했습니다. 사용자 정보와 연결되지 않는 구간도 있었습니다. 이 상태에서 통합 전환율을 만들면 숫자만 그럴듯해집니다. 기록이 연결되지 않는다는 사실부터 분석 결과로 남겼습니다.

Agent의 분석은 다섯 단계로 운영합니다

BA Agent의 흐름은 수집 → 검증 → 분석 → 의사결정 → 재측정으로 나눴습니다. 각 단계에는 다음 단계로 넘어가기 전에 확인할 결과물과 통과 조건이 있습니다.

목표 운영 구조입니다. BA Agent의 제안은 담당자 승인과 실행을 거친 뒤 다시 측정합니다. 일부 검증 과정은 동작하지만, 전체 자료를 함께 분석하고 결과를 다음 개선에 반영하는 흐름은 아직 설계·검증 중입니다.

1. 수집: 같은 기준의 분석용 사본을 만듭니다

첫 단계에서는 Agent가 자료를 실행마다 새로 해석하지 않도록 합니다. GA4, 서비스 행동 기록, Agent 작업 기록에서 분석 기간과 필요한 항목만 꺼내 분석용 사본으로 남깁니다.

분석용 사본에는 최소한 다음 정보가 붙습니다.

• 데이터 기준 시각과 분석 기간
• 자료의 출처와 행동 기록 정의 버전
• 사용자·방문·대화 연결값이 이어지는 비율
• 누락되거나 지연된 데이터
• 데이터를 묶어 세는 기준과 개인정보 보호 규칙

분석용 사본을 두면 다음 실행에서도 같은 기간을 같은 기준으로 읽습니다. 원본 자료에 접근하는 권한과 보고서에 쓸 수 있는 정보의 범위도 분리합니다. Agent가 원문을 읽더라도 결과물에는 허용된 정보만 내보냅니다.

2. 검증: 데이터가 답할 수 있는지 확인합니다

Agent가 분석 결과를 만들기 전에, 코드가 계산으로 확인할 수 있는 조건부터 검사합니다.

• 데이터가 정해진 시간 안에 갱신됐는가
• 서비스 이용 단계의 행동 기록이 정해진 순서와 의미를 따르는가
• 사용자와 방문을 잇는 연결값이 분석에 충분한가
• 전체 기준이 되는 수와 그중 조건을 만족한 수가 명시돼 있는가
• 작은 집단이나 단일 사용자를 드러낼 위험은 없는가
• 같은 기준 파일을 사용했고 파일 식별값이 일치하는가

검증 결과에는 통과와 실패 사이의 상태도 필요합니다. 범위를 줄여 분석을 계속할 수 있으면 제한 분석이라고 표시합니다. 사용자를 잇는 연결값이 없다면 통합 여정 분석은 멈추되, GA4 전체 이용 단계와 개인을 알 수 없게 처리한 대화 주제를 묶어 보는 분석은 각각 수행할 수 있습니다.

핵심 전제가 깨진 경우에는 결과 작성을 멈춥니다. Agent가 그럴듯한 설명으로 빈칸을 채우지 못하도록 값과 실패 사유를 정해진 형식으로 함께 남깁니다.

3. 분석: 네 가지 렌즈로 데이터를 읽습니다

검증을 통과한 데이터는 네 가지 분석 렌즈로 나눕니다.

목표 분석 구조입니다. 고객 집단은 개인 정보가 아니라 여러 사용자를 묶어 살펴보는 단위입니다. 분석에 필요한 최소 인원을 채우지 못한 집단은 더 큰 집단에 합치거나 측정 대기로 남깁니다.

서비스 이용 단계 분석

서비스 이용 단계는 용도에 따라 두 종류로 나뉩니다. 특정 행동까지 도달한 사용자 수는 제품 문제를 찾고 측정 기록을 점검하는 데 씁니다. 의사결정 단계에서는 사용자가 정해진 순서로 각 단계를 통과했는지 확인합니다.

예를 들어 화면 준비 → 메시지 제출 → 요청 수락 → 첫 응답은 각각 다른 사건입니다. 버튼을 눌러도 요청이 수락되지 않을 수 있고, 요청이 수락된 뒤 첫 응답이 오지 않을 수도 있습니다. Agent는 전체 전환율 하나로 뭉뚱그리지 않고 손실이 생긴 경계를 따로 짚습니다.

특정 행동에 도달했는지만 보는 방식과 정해진 순서까지 보는 방식은 이름부터 구분해 저장합니다. 전자는 문제를 찾는 데, 후자는 결정과 배포 여부를 판단하는 데 사용합니다.

GA 분석

GA4에서는 방문 경로, 처음 들어온 화면, 사용 기기, 재방문, 주요 행동 도달 여부를 봅니다. Agent는 숫자를 나열하는 대신 비교 기준을 관리합니다.

• 이번 기간과 직전 비교 기간은 같은 길이인가
• 광고·홍보를 통한 방문과 검색 등 자연스러운 방문이 섞이지 않았는가
• 전환율의 분모는 전체 방문자인가, 특정 단계 도달자인가
• 신규와 재방문 사용자를 같은 변화로 설명하고 있지 않은가
• 행동 기록의 이름이 바뀌는 전환 기간의 수치가 섞이지 않았는가

이 기준을 통과하면 Agent가 변화가 큰 구간과 확인할 가설을 제안합니다. 확인된 변화와 그 원인은 별도로 적습니다.

사용자 기록 분석

서비스 기록과 Agent 작업 기록에서는 오류·지연·도구 실행·응답 단계, 사용자가 남긴 질문의 반복 양상을 봅니다. 같은 사건이 여러 줄에 반복되는 경우가 많습니다. 기록을 그대로 세면 하나의 긴 대화가 여러 번 잡히므로, 가능한 경우 한 번의 방문이나 요청 처리 흐름을 한 건으로 셉니다.

사용자 특성을 해석할 때는 누적 대화와 첫 방문을 나눠 봅니다. 재방문 사용자는 대화량 자체가 많아 누적 계산에서는 거의 모든 주제가 커집니다. 재방문 이전의 첫 방문 신호를 따로 보면 결과를 원인처럼 읽는 오류를 줄일 수 있습니다.

이 분석은 원인과 결과를 증명하지 않습니다. Agent는 확인한 신호, 가능한 설명, 추가 확인이 필요한 가설을 분리해서 기록합니다.

고객 집단 분석

서비스 이용 단계가 사용자의 이동을 추적한다면, 고객 집단 분석은 서로 다른 사용자가 같은 단계를 통과하는 방식을 비교합니다. 전체 평균만으로는 신규 사용자가 막히는 지점과 재방문 사용자가 떠나는 구간을 가려내기 어렵습니다.

고객 집단 이름을 실행마다 새로 만들면 결과를 비교하기 어렵습니다. 어떤 기준으로 사용자를 나눌지 먼저 기준 파일에 고정합니다.

• 생애주기: 신규, 재방문, 장기 미방문, 이탈 위험
• 이용 단계: 첫 화면 이탈, 대화 시작, 첫 응답 도달, 후속 행동
• 관심 의도: 시세 탐색, 조건 비교, 자금 계획처럼 여러 사용자를 묶어 셀 수 있는 질문 주제
• 행동 강도: 방문 빈도, 방문 간격, 주요 행동 도달 여부
• 운영 상태: 오류·지연 경험, 미완료 요청, 다음 액션 부재

이 축을 모두 조합해 사용자를 잘게 나누지는 않습니다. 고객 집단이 작아질수록 한 사용자의 행동이 전체 결과를 좌우하고 개인을 짐작할 위험도 커집니다. 분석에 필요한 최소 인원을 채우지 못한 집단은 결과를 내지 않습니다. 비슷한 상위 집단으로 합치거나 측정 대기로 남깁니다.

GA4와 대화 기록의 분석 대상 범위 차이도 고객 집단 정의에 포함됩니다. 전체 방문자 중 대화를 시작하지 않은 집단은 GA4로 볼 수 있지만 대화 주제로 설명할 수 없습니다. 반대로 첫 방문에 특정 의도를 보인 집단은 대화 기록으로 정의할 수 있지만 전체 방문자를 대표한다고 말할 수 없습니다. 두 자료의 사용자 연결값이 이어진 경우에만 특정 의도를 보인 신규 사용자의 재방문율처럼 두 자료를 함께 보는 지표를 계산합니다.

고객 집단 이름은 기준 시점별 파일에 고정하고, 같은 기간의 모든 분석이 같은 이름을 사용하도록 설계했습니다. 사용자 특성은 첫 방문과 누적 기준을 함께 기록하고, 지표에는 어떤 고객 집단 중 무엇을 한 사용자의 비율인지 계산 기준을 붙입니다.

Agent는 고객 집단 결과를 고정된 고객 유형 목록 대신 분석 카드로 남깁니다. 카드에는 다음 항목이 붙습니다.

• 고객 집단 정의와 적용 기간
• 분석 대상의 범위와 최소 인원 조건
• 서비스 이용 단계별 차이
• 자주 확인된 행동·질문 신호
• 데이터 한계와 해석 금지 조건
• 첫 사용 안내, 재방문, 이탈 방지 관점의 실행 후보

분석 카드는 “전체 전환율을 높이자”는 막연한 목표를 “첫 방문에서 조건 비교를 시도한 사용자의 첫 응답 도달 실패를 줄이자”처럼 대상과 행동이 분명한 의사결정 후보로 바꿉니다.

4. 의사결정: 분석 결과를 실행 카드로 바꿉니다

분석 결과를 실행으로 옮기려면 누가 무엇을 언제 바꿀지 정해야 합니다. BA Agent는 이 정보를 의사결정 카드 형태로 넘깁니다.

{
  "관찰": {
    "지표": "<확인한 수치>",
    "계산_기준": "<전체 기준과 조건을 만족한 수>",
    "대상_집단": "<분석할 고객 집단>",
    "분석_기간": "<분석 기간>",
    "근거_자료": ["GA4", "서비스 기록", "Agent 작업 기록"]
  },
  "주의사항": ["<자료의 한계>", "<원인으로 단정하면 안 되는 조건>"],
  "가설": "<왜 이런 현상이 나타났는가>",
  "실행안": "<제품·운영 변경안>",
  "담당자": "<결정 또는 실행 담당>",
  "검토_기한": "<검토 기한>",
  "성공_기준": "<변경 전에 확정할 판단 기준>",
  "되돌림_조건": "<중단하거나 이전 상태로 되돌릴 조건>"
}

BA Agent는 근거와 후보를 만듭니다. 제품을 맡은 Agent나 사람 담당자가 우선순위와 실행 여부를 결정합니다. 후보와 결정을 분리하는 이유는 분석 결과가 곧바로 제품 변경 명령이 되는 것을 막기 위해서입니다.

결정되지 않은 제안도 버리지 않습니다. 채택, 보류, 기각, 측정 대기로 상태를 남기고, 보류와 측정 대기에는 다시 여는 조건을 붙입니다. 그래야 같은 제안이 다음 실행에서 처음 보는 아이디어처럼 반복되지 않습니다.

5. 재측정: 실행 전 기준으로 다시 판정합니다

변경을 배포한 뒤 같은 지표를 다시 계산해야 의사결정 흐름이 마무리됩니다.

성공 기준은 결과를 보기 전에 정합니다. 서비스 이용의 어느 단계가 얼마나 개선돼야 하는지, 어떤 부작용이 나타나면 되돌릴지, 최소 관찰 기간은 얼마인지 실행 전에 확정합니다.

재측정 결과는 세 갈래로 처리합니다.

• 기준을 충족하면 변경을 유지하고 결정 기록을 마무리합니다.
• 변화가 불충분하면 가설과 실행안을 분리해 다시 검토합니다.
• 측정 기록이 불완전하면 성패를 판정하지 않고 측정 과제로 되돌립니다.

그러면 Agent는 매주 새 분석 결과를 쌓는 데 그치지 않고, 이전 결정이 실제로 어떤 결과를 냈는지도 관리할 수 있습니다.

자동화는 실행 경로를 고정합니다

분석 자동화라고 하면 대규모 언어 모델(LLM)에 긴 지시문을 주는 장면부터 떠올리기 쉽습니다. 반복 운영에서 실제로 흔들리는 부분은 자료의 기준, 실행 순서, 결과물의 상태입니다.

저희는 판단은 Agent에, 고정된 규칙은 파일과 코드에 맡겼습니다.

• Agent가 판단하는 것: 어떤 변화가 중요한지, 가능한 설명은 무엇인지, 어떤 후속 질문이 필요한지
• 파일과 코드가 지키는 것: 행동 기록의 정의, 이용 단계의 순서, 연결값, 계산 기준, 개인정보 보호, 자료의 최신 상태, 결과물의 상태 변경 규칙

자동화 실행은 다음 결과물을 차례로 남깁니다.

1. 입력 자료: 어떤 자료와 기준 버전을 읽었는가
2. 검증 결과: 무엇을 계산할 수 있고 무엇이 막혔는가
3. 분석 결과: 확인한 수치, 계산 기준, 비교 기준, 한계
4. 의사결정 카드: 가설, 실행안, 담당, 기한, 성공 기준
5. 재측정 결과: 유지, 재검토, 되돌림, 측정 대기 판정

각 결과물은 다음 단계의 입력이 됩니다. 검증을 건너뛴 분석이나 담당자가 없는 실행안은 다음 단계로 넘어가지 않습니다. 실패한 실행도 사라지지 않고 분리 보관하거나 보류 상태로 남깁니다.

이 기록 덕분에 Agent가 실행마다 새로 시작해도 이전 기준과 결정 상태를 파일에서 복원할 수 있습니다. 모든 것을 기억하는 Agent보다, 기억에 기대지 않고 같은 경로를 지나는 실행 구조가 반복 운영에 더 적합했습니다.

분석 결과를 제품 결정으로 옮기는 과정

예를 들어 첫 화면에서 어떤 질문을 먼저 제안할지 결정한다고 해보겠습니다.

1. GA4의 서비스 이용 단계는 첫 화면에 도달한 뒤 실제 대화 시작까지 어느 지점에서 사용자가 줄어드는지 보여줍니다.
2. 첫 방문 대화를 묶어 본 결과는 처음 온 사용자가 어떤 종류의 질문을 시도하는지 보여줍니다.
3. 고객 집단 분석은 신규·재방문 사용자와 관심사별로 이탈 지점이 어떻게 다른지 비교합니다.
4. 서비스 기록은 메시지 제출과 요청 수락, 첫 응답 사이에 기술적인 문제가 있는지 보여줍니다.
5. BA Agent는 이 네 근거를 묶어 고객 집단별 질문 제안, 화면 사용 방식 개선, 측정 체계 보완을 서로 다른 실행안으로 나눕니다.
6. 담당자는 실행할 안을 고르고, 배포 전에 대상 고객 집단과 순서가 있는 이용 단계의 성공 기준·되돌림 조건을 정합니다.
7. 배포 후 Agent가 같은 고객 집단 정의와 이용 단계 기준으로 다시 계산해 결정 기록을 갱신합니다.

분석 결과는 화면 변경 후보가 되고, 채택된 후보만 사전 정의된 지표로 재측정합니다.

이 예시에서도 대화 주제가 자주 나타났다는 이유만으로 첫 화면을 바꾸지는 않습니다. GA4의 실제 이탈 구간, 기술적인 실패의 개입 여부, 변경 후 성공 판정 기준을 함께 확인합니다.

숫자와 함께 정의와 상태를 관리합니다

반복 분석에서는 숫자 자체보다 숫자의 뜻이 자주 흔들렸습니다. 같은 자료도 전체 기준과 조건을 만족한 수를 뒤집으면 다른 질문이 됩니다. 누적 대화와 첫 방문을 섞으면 재방문의 결과가 원인처럼 보이고, 행동 기록의 이름이 바뀌는 동안 이전 기록과 새 기록을 합치면 전환율이 갑자기 좋아진 듯한 착시가 생깁니다.

두 값이 모두 맞을 수 있기 때문에, 수치만 저장하지 않고 질문의 방향을 함께 저장합니다.

운영 범위에는 대시보드 숫자와 함께 다음 항목이 들어갑니다.

• 행동 기록 사전과 서비스 이용 단계 정의
• 고객 집단 정의와 적용 기간
• 지표의 전체 기준·조건 충족 수·계산 방향
• 자료의 최신 상태와 연결값이 이어지는 비율
• 분석·결정·실행·재측정 상태
• 정의를 바꾼 이유와 적용 시점

기준 파일에는 버전과 파일 식별값을 붙이고, Agent와 계산 프로그램은 같은 파일을 참조합니다. 기준이 바뀌면 과거 수치와 단순 비교하지 않고 기준 변경으로 표시합니다.

답할 수 없는 질문도 운영 항목입니다

Agent 분석은 데이터가 비어 있을 때 가장 위험합니다. 언어 모델은 빈칸 앞에서도 문장을 완성할 수 있기 때문입니다.

지표는 세 가지 상태로 관리합니다.

• 지금 데이터로 답할 수 있는 지표는 계산합니다.
• 측정 기록이 채워지면 답할 수 있는 지표는 계산식과 판단 조건을 확정해 측정 과제로 등록합니다.
• 구조적으로 답할 수 없는 질문은 값을 비우고 사유를 적습니다.

측정 과제에는 필요한 행동 기록, 연결값, 담당자, 완료 조건을 붙입니다. 그러면 분석 Agent가 측정 문제를 제품 또는 데이터 업무로 넘길 수 있습니다.

비어 있는 보고서는 실패처럼 보일 수 있습니다. 그래도 연결되지 않은 기록을 억지로 합친 숫자보다는, 무엇이 부족해 답할 수 없는지 밝히는 편이 의사결정에 유용합니다.

아직 자동 분석이 완성됐다고 말할 수는 없습니다

기술적인 연결이 완성돼도 해석의 한계는 남습니다. 이용 단계와 사용 기록은 함께 움직이는 경향과 순서를 보여줄 뿐 원인과 결과를 자동으로 증명하지 않습니다. 작은 집단은 개인정보 보호와 수치의 불안정성 때문에 계산에서 제외될 수 있습니다. 자동화가 이 한계를 없애지는 못합니다. 대신 실행할 때마다 같은 방식으로 드러냅니다.

Agent가 분석한다는 의미

Agent가 GA4와 사용자 기록을 분석하려면 화면의 숫자를 자연어로 옮기는 것보다 더 많은 일이 필요합니다.

• 서로 다른 데이터가 답할 수 있는 질문을 구분하고
• 서비스 이용 단계의 순서와 지표의 계산 기준을 고정하고
• 고객 집단의 정의·분석 대상 범위·최소 인원을 관리하고
• 신호와 원인, 후보와 결정을 분리하고
• 답할 수 없는 질문을 측정 과제로 전환하고
• 실행 전 성공 기준을 정한 뒤 같은 기준으로 다시 측정하는 일입니다.

파일과 코드가 이 흐름을 관리하면 Agent는 반복 가능한 운영 역할을 맡을 수 있습니다.

좋은 분석 Agent는 답을 많이 만드는 Agent가 아니라, 조직이 어떤 근거로 무엇을 결정했고 그 결과가 어땠는지를 계속 이어 주는 Agent입니다.

주간회의 글에서는 Agent 팀이 기록을 읽어 상태와 우선순위를 판정하는 구조를 다뤘고, 평가 하네스 글은 상담 하나의 실패를 재현 가능한 평가 자산으로 만드는 과정을 다뤘습니다. 이번 글은 사용자 행동과 Agent 실행을 묶어 제품 의사결정의 입력으로 관리하는 방법을 다룹니다.

분석 품질을 좌우하는 것은 프롬프트 한 줄보다 데이터와 정의, 결정이 이어지는 경로입니다.

이 글의 사례는 운영 기록에서 확인한 구조와 문제를 식별 정보 없이 일반화한 것입니다. 사용자 발화와 예시 값은 실제 운영 데이터를 재현한 것이 아닙니다.