이커머스 Product Manager의 AKM 활용법

AKM의 핵심 전략: 다듬기(Refinement)와 검증(Verification)의 분리

시작점은 AKM의 대표적인 특징 하나를 살펴보는 것입니다. 바로 '다듬기'와 '검증'을 완전히 따로 다룬다는 점입니다.

LLM(대형 언어 모델)은 문장을 그럴듯하게 가다듬는 데에는 정말 뛰어납니다. 하지만 문장이 그럴듯하다고 해서 내용이 사실인 것은 아니죠. 오히려 깔끔하게 잘 쓰인 문장일수록 그 안에 숨어 있는 날짜, 수치, 조건, 정책 오류를 놓치기 쉽습니다.

그래서 AKM은 이 두 과정을 아예 별개의 트랙으로 나눕니다. 문장을 아무리 예쁘게 잘 다듬어도 그 자체로 합격점을 받을 수는 없습니다. 판정(PASS, HOLD, FAIL, NOT_TESTED)은 오직 원문 기준(앵커)과 확실한 증거를 통해서만 내립니다. '문장을 보기 좋게 만드는 것'과 '사실관계를 맞추는 것'을 시스템이 혼동하지 않도록 만드는 것, 이것이 아래 모든 영역에 관통하는 기본 원리입니다.

검증 강도 설정: Tier 0~3 기준

검증을 얼마나 까다롭게 진행할지는 Tier 단계를 통해 결정합니다. 판단 기준은 딱 두 가지입니다.

1. 틀렸을 때의 대가 (다시 되돌릴 수 있는가?)

2. 산출물의 수명 (한 번 보고 버리는가, 저장해 두고 계속 쓰는가?)

만약 경계가 모호하다면 대외용 작업은 높은 Tier를, 내부 탐색용 작업은 낮은 Tier를 적용하면 됩니다. 그리고 이 Tier는 문서 전체 단위가 아니라 '주장 단위'로 나누어 적용합니다. 예를 들어 같은 기획서 안이라도 내부 시스템 설계 확정 건은 Tier 2, 고객 대상 공지글은 Tier 3를 적용하는 식입니다.

AKM의 4대 적용 분야

AKM은 잘 써진 문장 뒤에 숨은 팩트 오류(날짜, 숫자, 조건, 정책 등)가 실제 비즈니스 손실로 이어질 수 있는 곳에서 가장 큰 효과를 발휘합니다.

1. 법무·계약·규제 준수 (Tier 3)

글자나 날짜 하나만 틀려도 법적 책임, 계약 파기, 고객 보상 문제로 바로 이어지는 분야입니다.

• 해당 업무: 약관 제·개정, 개인정보처리방침 변경 기획, 대외 제안서 작성.

• AKM의 역할: AI가 법무 가이드라인을 그럴듯하게 요약했더라도 절대 그대로 쓰지 않습니다. 조항마다 "실제 규제나 약관 원문과 부딪히는 부분이 없는가?"를 별도로 묻고 원문과 하나하나 대조합니다. 기준이 되는 원문(앵커)이 시스템(볼트)에 없다면 PASS를 줄 수 없어 'NOT_TESTED'로 강제 분류되며, 충돌 가능성이 보이면 'HOLD'로 묶여 승인 자체가 보류됩니다. 실제 케이스 스터디에서도 약관 원문을 확보한 덕분에 판정이 'NOT_TESTED'에서 'HOLD'로 바뀌고 배포일이 공지 기간에 맞춰 조정된 사례가 있습니다.

2. 의존성이 복잡한 시스템 기획·예외 처리 (Tier 2)

기존 정책과 기능 정의가 수십 개씩 얽혀 있어, 새 기획이 기존 규칙을 은근슬쩍 깨뜨리거나 누락할 위험이 큰 분야입니다.

• 해당 업무: 유저스토리 정의, 화면 단위 PRD, DB 마이그레이션 기획.

• AKM의 역할: 초안을 일정 시점에 그대로 동결(라운드 스냅샷)해 둔 뒤, 기존 기능정의서나 정책서(20-knowledge/) 수십 개를 기준점 삼아 교차 검증합니다. 새 기획이 기존의 예외 처리 규칙(예: 복합 결제 취소 정책 등)을 훼손하지 않았는지 훑어보고, 충돌하는 부분만 최소한으로 수정(diff)합니다. 실제 케이스 스터디에서 발견된 역반영 누락, 금액 규칙 승계 누락, 상태 변화 충돌 문제들이 모두 이 과정을 통해 잡혀냈습니다.

3. 정기 보고서·지표 데이터 분석 (Tier 1~2)

매주, 매달 수많은 숫자를 반복해서 다루고, 지표의 변화를 통해 원인을 파악하여 의사결정을 돕는 분야입니다.

• 해당 업무: 주간·월간 지표 분석 보고서(GA, DB 추출 데이터 기반), 매월 재검증하는 프로덕트 플래닝.

• AKM의 역할: AI 데이터 분석에서 자주 발생하는 할루시네이션(환각)은 두 가지입니다. 없는 숫자를 진짜처럼 만드는 것, 그리고 원인을 알 수 없는 지표 하락에 그럴듯한 소설을 쓰는 것이죠. AKM은 자동 추출된 원본 데이터와 해당 주의 배포 로그 같은 확실한 증거를 우선적으로 대입하며, 근거가 부족한 추측성 문장은 판정 단계에서 걸러냅니다.

4. 자율 AI 파일 에이전트의 통제 (Agent System)

사람의 개입 없이 배경 데이터를 분석해 결과물 파일을 직접 생성하고 수정하도록 만든 에이전트 자동화 분야입니다.

• 해당 업무: 정기 지표 대시보드 자동 발행, 외부 동향 자동 수집 및 비교 리포트 생성.

• AKM의 역할: 에이전트의 동작 지침 안에 검증 규칙을 넣어둡니다. 작업 전 원본 상태를 고유값(체크섬)으로 동결해 두고, 수용 기준에 모자라거나 출처가 불분명하면 마음대로 수정하지 못하게 막습니다. 과도한 수정이나 잘못된 고침을 시스템 단에서 원천 차단하는 구조입니다.

현재 단계 및 구성 현황

처음부터 모든 과정을 AI가 알아서 만들고 검증까지 마치도록 하지는 않습니다. 분야에 따라 사람과 AI의 역할 비중을 다르게 나누어 진행하고 있습니다.

• 서비스 기획 (분야 1·2): 당분간은 사람의 손을 많이 거치는 방식을 유지합니다. 초안은 사람이 주도적으로 쓰고, AKM은 기존 정책이나 약관 원문, 기존 정책서와의 대조 및 판정을 보조하는 데 활용합니다.

  • 현 AKM의 검증루프는 딥리서치 보고서 품질 차원의 검증이라, 기획문서를 위한 평가기준을 별도로 구성했어요. ①기존규칙 확인 (기존정책), ②서비스 영향범위 전수, ③서비스Flow 점검, ④확정/미확정 항목의 분리, ⑤확정/미확정 항목 분리, ⑥롤백에 대한 검토, ⑦보안,법적 정합성

• 정기 보고서·지표 (분야 3): 현재 초안 작성 자동화를 구축해 나가는 단계입니다. AI가 원본 데이터를 바탕으로 초안을 만들면, 검증 루프가 수치와 근거를 검토해 판정하는 분업 구조를 목표로 합니다.

• 에이전트 통제 (분야 4): 아직 구축 전 단계입니다. 초안 자동화 작업이 안정적으로 자리를 잡은 뒤 다음 단계로 추진할 예정입니다.

AKM 활용 요약

단순히 한 번 묻고 답하는 일회성 대화(Tier 0)에는 굳이 AKM을 쓸 필요가 없습니다. 하지만 시간이 지나도 조직 내에서 계속 재사용되고 정확성이 유지되어야 하는 지식 자산 영역에서는 다듬기와 분리된 자가검증 루프가 매우 강력하게 작동합니다.

• 신규 기획 (30-context/projects/)

• 서비스 정책, 약관 (20-knowledge/)

• 관련 법령 등 (10-source/ — 전자상거래법, 약관규제법, 표시광고법, 개인정보보호법, 국가법령정보센터, 공정위 표준약관 등)

• 상시 업무 (30-context/standing/)

도입 방식 역시 한 번에 전면 적용하기보다는, 사람이 작성하는 기획의 검증을 돕는 것부터 시작하여 보고서 초안 자동화를 우선 구성하고, 에이전트 통제 단계로 차근차근 확장해 나가려 합니다.