1. 사건의 발단 (Case Study)

🎙️ 미니 인터뷰: 주간 회고 회의 1일 전, 라이브 운영자가 VOC 500건 분류·우선순위 매트릭스에 묶이는 순간

Q. 버그·결제·콘텐츠·운영 카테고리 4~5개니까 엑셀 필터로 키워드만 걸면 거의 다 걸러지는 거 아닌가요?

그게요... 막상 해보면 키워드로 거르는 게 절반밖에 안 돼요. 유저 글이 '뽑기 100번 했는데 픽업 안 떴어요'라고 오면 이게 결제인지, 콘텐츠 밸런스인지, 확률 운영 이슈인지 한 글에 3개가 다 걸려 있거든요. 거기에 욕설·이모지·맞춤법 오류까지 섞여서 키워드 자체가 안 잡히는 글이 30%는 돼요. 그래서 어차피 한 건씩 눈으로 읽고 한 건씩 라벨을 다는 작업으로 돌아와요. 그게 500건이고, 그것만 반나절이에요.

Q. 그러면 빈도 높은 카테고리 위에서부터 처리하면 우선순위는 자연스럽게 나오지 않나요?

정렬은 했는데요, 빈도만 보면 사고가 나요. 빈도는 결제 문의가 100건으로 가장 많아도, 심각도로 보면 신규 던전 버그 5건이 진짜 패치 1순위거든요. 결제는 환불 처리하면 끝이고, 던전 버그는 다음 점검에서 못 잡으면 다음 주 이벤트가 무너지니까요. 그래서 빈도 × 심각도 × 매출 영향 가중치를 매트릭스로 짜야 하는데, 그게 운영자 머리로 매주 500건에 일일이 점수 매기는 작업이에요. 매트릭스 표 하나 만드는 데 또 두 시간이고요.

Q. 매트릭스에 점수 매기는 건 결국 운영자 감각으로 추리는 영역 아닌가요?

솔직히 그게 가장 부담이에요... 카테고리 모호한 글이 30%고, 그걸 어느 카테고리에 넣을지·심각도 몇 점 줄지는 결국 제 손에서 결정되거든요. 그러다 보면 제 시각이 통계에 들어가요. 회의에서 개발팀이 '이건 왜 1순위인가요?' 물었을 때 '제가 보기엔...'으로 시작하면 그 자료는 거기서 신뢰가 한 번 깎여요. 500건 데이터인데 결론은 운영자 감각이라는 게 매번 마음에 걸려요. 객관적인 분류 기준이랑 같이 가야 회의가 빨라지거든요.

Q. 개발팀에 그냥 카테고리·빈도 표만 넘기면 되는 거 아닌가요?

그것도 한번 그렇게 해봤는데, 다음 날 또 부르세요. 개발팀에서 받는 인풋은 '뭐가 몇 건이다'가 아니라 '왜 1순위고, 다음 패치에 뭘 잡으면 이번 주 VOC가 얼마나 줄어드는지'까지예요. 지난주에 표만 넘겼다가 다음 날 '그래서 우리가 뭘 먼저 고치면 돼요?' 질문이 다시 와서, 그날 저녁에 한 건씩 다시 펼쳐서 패치 후보 Top 10 코멘트를 손으로 달았어요. 분류·매트릭스까지 가도, 마지막에 '이걸 고치면 이만큼 줄어든다'는 한 줄이 안 붙으면 개발팀이 못 움직여요.

Q. 그래서 이번 주는 어떻게 준비하고 계세요?

이번 주는요... 월요일 아침에 CS 시트 받아서 점심까지 카테고리 라벨링하고, 오후엔 매트릭스 점수 넣고, 저녁엔 개발팀 코멘트 다는 흐름이에요. 그러면 한 사이클이 하루 꽉 차고, 화요일 회고 회의 들어가요. 매주 이 하루를 다 쓰니까 다른 운영 업무가 밀려요. 이걸 500건 한 번에 던지고 '카테고리 분류 + 빈도×심각도 매트릭스 + 패치 반영 후보 Top 10까지 정리해줘'라고 할 수 있다면, 그 하루는 살 것 같아요.

2. 문제 해결을 위한 레시피 (Solution)

🩺 마스터의 진단

이번 사례의 병목은 두 갈래입니다. 첫째는 500건 VOC를 한 건씩 눈으로 읽고 카테고리 라벨링·심각도 점수·패치 후보 코멘트까지 손으로 다는 작업이 매주 하루를 잡아먹는다는 점입니다. CS 시트 받아서 분류만 반나절, 매트릭스 두 시간, 패치 코멘트가 또 저녁이라 화요일 회고 회의 직전까지 다른 운영 업무가 다 밀리는 구조입니다. 둘째는 카테고리가 모호한 30% 글과 심각도 점수화 단계에서 운영자 감각이 통계에 섞여 들어간다는 점입니다. 회의에서 '왜 1순위인가요?' 질문에 '제가 보기엔'으로 시작하면 자료 신뢰가 거기서 한 번 깎입니다.

ChatGPT 호출은 카테고리 정의·매트릭스 가중치를 프롬프트에 명시한 채 한 번에 분류·점수·Top 10·예상 효과까지 출력하는 방식으로, 하루 작업을 1시간으로 줄이는 동시에 분류 기준이 자료 안에 함께 명시돼 회의에서 객관 근거로 답할 수 있게 해 줍니다.

[Step 1] ChatGPT 접속 + VOC 시트 업로드

ChatGPT(chatgpt.com)에 접속해 새 대화창을 엽니다. CS팀에서 받은 한 주 VOC 시트(.xlsx, 500건 안팎)를 입력창 클립 아이콘으로 업로드합니다. 시트 첫 행은 헤더(접수일·플랫폼·유저 문의 본문·CS 메모)로 정리돼 있어야 ChatGPT가 열 이름을 인식합니다.

⚠️ 데이터 보안 안내: VOC 시트에는 유저 닉네임·계정 ID·결제 정보·CS 메모가 섞여 있을 수 있어요. 사내 정책상 외부 AI에 올릴 수 있는 범위인지 보안팀에 한 번 확인하고, 가능하면 닉네임·결제 ID·계정 ID 열은 마스킹하거나 삭제한 뒤 업로드하세요.

[Step 2] 분류 + 매트릭스 + 패치 후보 통합 프롬프트 호출

업로드 직후 아래 프롬프트를 입력창에 그대로 넣고 보냅니다. 카테고리 5종 분류·빈도×심각도 매트릭스 점수·다음 패치 반영 후보 Top 10이 한 호출에 표 3개로 나옵니다. 처리 시간은 500건 기준 2~4분입니다.

[역할]
너는 모바일 RPG '프로젝트 A'의 라이브 운영팀 분석 보조다. 주간 회고 회의에 들어갈 VOC 인풋 자료를 정리한다.

[입력 데이터]
방금 업로드한 한 주 VOC 시트(.xlsx). 열은 접수일·플랫폼(iOS/Android)·유저 문의 본문·CS 메모.

[분류 카테고리 5종 — 정의 명시]
- 버그: 게임 진행 차단·아이템 손실·UI 오작동 등 정상 동작에서 벗어난 문제
- 결제: 인앱 결제 실패·환불 요청·뽑기 확률·재화 차감 관련 문의
- 콘텐츠: 신규 던전·이벤트·밸런스·보상량에 대한 의견·불만
- 운영: 점검·롤백·공지·고객 응대 톤 관련 의견
- 기타: 위 4종에 안 들어가는 일반 문의·칭찬·제안

한 문의에 카테고리가 2개 이상 걸리면 '주(主) 카테고리' 1개와 '부(副) 카테고리' 1개로 표시. 모호한 글은 '모호' 플래그를 별도 열에 표시한다.

[출력 1 — 카테고리 분류표]
전체 건수 / 카테고리별 건수·비율 / 모호 플래그 건수

[출력 2 — 빈도×심각도 매트릭스]
카테고리별로 다음 3개 점수를 1~5점으로 산정:
- 빈도: 이번 주 접수 건수 기준
- 심각도: 게임 진행 차단·매출 직접 영향 정도
- 매출 영향: 결제 관련성·이탈 위험
총점 = 빈도 + (심각도 × 2) + 매출 영향. 심각도 가중치 2배인 이유는 진행 차단이 유저 이탈로 직결되기 때문.

[출력 3 — 다음 패치 반영 후보 Top 10]
총점 상위 10개 이슈를 표로 정리. 각 행에 '이슈 요약(20자)·카테고리·접수 건수·총점·근거 VOC 인용 1개'를 포함.

[톤]
- 표 형식으로만 출력. 본문 설명·서론·맺음말 금지
- 모호 분류는 모호 플래그로 표시하고 임의로 한쪽에 넣지 말 것
- 심각도·매출 영향 점수는 산정 근거를 점수 옆 괄호 안에 한 줄로 명시

[Step 3] 개발팀 전달용 코멘트 한 줄 보강

Top 10 패치 후보 표가 나오면, 같은 대화창에 후속 프롬프트를 한 번 더 보냅니다. 각 후보 옆에 '고치면 이번 주 VOC가 몇 건 줄어드는지' 한 줄 코멘트가 붙어 개발팀이 우선순위 회의에서 바로 인용할 수 있는 형태가 됩니다.

[추가 지시]
위 Top 10 표의 각 행 오른쪽에 '예상 효과' 열을 추가해줘. 한 줄 코멘트 형식이고 다음 세 가지를 한 문장 안에 담아.
- 이 이슈를 다음 패치에 잡으면 이번 주 같은 카테고리 VOC가 몇 건 줄어들지(접수 건수의 60~80% 범위로 추정)
- 어떤 유저층에게 영향이 큰지(과금 유저·신규 유저·복귀 유저 중 1~2개)
- 다음 점검 윈도우 안에 핫픽스 가능한지·정기 패치까지 미뤄야 하는지

[톤]
- 한 줄 18~24자 안에 자연스러운 한 호흡으로
- '~예상', '~으로 추정' 같은 명사형 어미 금지. 한 문장으로 끝내기
- ✅ 좋은 예: '신규 유저 30건 감소, 핫픽스 가능'
- ✅ 좋은 예: '과금 유저 환불 18건 감소, 정기 패치 권장'
- ❌ 나쁜 예: '신규 유저 영향 큰 이슈로 추정됨'
- ❌ 나쁜 예: '핫픽스 검토 필요한 상황'

3. 결과 (Result)

• 핵심 수치: 주간 VOC 500건 분류·매트릭스·패치 후보 정리: 하루 → 1시간

• 주요 특징:

  • 1. 카테고리 5종 정의 + 모호 플래그 함께 출력 — 한 건씩 손 라벨링 줄임

  • 2. 빈도×심각도×매출 영향 매트릭스 — 운영자 감각 의존 최소화

  • 3. 패치 후보 Top 10 + 예상 효과 한 줄 — 개발팀 회의에서 그대로 인용 가능

• 시사점: VOC 분류는 단순 시간 단축이 아니라 분류 기준·심각도 산정 근거가 자료 안에 함께 출력되는 게 핵심입니다. 운영자 감각이 통계에 섞이던 영역을 카테고리 정의·점수 가중치가 받쳐 줍니다. 회의에서 '왜 1순위인가요?' 재질문이 돌아오지 않는 이유입니다.

4. 리뷰 (Review)

📊 AI 활용 비포 & 애프터 비교

단순히 요청했을 때와, 우리의 [마스터 프롬프트]를 사용했을 때의 결과물 차이를 확인해 보세요.

💡 Master's Secret: 결정적 차이를 만드는 프롬프트의 원리

💡 Master's TIP!

💡 카테고리 이름 5종만 던지지 않고 '버그=진행 차단/UI 오작동, 결제=뽑기 확률 포함' 식으로 정의를 함께 주면, 키워드만 보고 한쪽으로 몰리는 분류 실수가 절반으로 줄어듭니다. 모호 플래그를 별도 열로 받는 게 핵심인데, 30% 정도 나오는 경계 글을 운영자가 마지막에 손으로 확인할 수 있게 보존되기 때문입니다. 매트릭스에서 심각도 가중치 2배는 라이브 게임 운영의 실제 패치 우선순위와 일치합니다. 빈도 1위가 결제 100건이어도 진행 차단 5건이 패치 1순위가 되는 이유를 점수 구조로 명시한 것입니다.

💡 Top 10 표가 나온 직후 '예상 효과 한 줄'을 따로 요청해야 개발팀이 회의에서 그대로 인용할 수 있는 형태가 됩니다. 한 호출에 다 시키면 ChatGPT가 분류 표 만들기에 토큰을 다 써서 코멘트가 두루뭉술해지거든요. ❌ 예시까지 명시한 이유는, '핫픽스 검토 필요한 상황' 같은 명사형 어미로 도망가는 패턴을 차단하기 위함입니다. '몇 건 줄어드는지'를 60~80% 범위로 제한한 건 추정의 상한을 막아 회의 신뢰도를 지키기 위한 장치입니다.

💬 이수연 라이브 운영 매니저의 한마디

솔직히 처음엔 그냥 '카테고리 5종으로 분류해줘'라고 던졌어요. 그랬더니 결제랑 콘텐츠가 반반씩 섞이고 매트릭스도 빈도 위주로 나와서 '아 이건 회의에 못 가져가겠다' 싶었거든요. 그다음에 카테고리 정의랑 심각도 가중치를 프롬프트에 같이 명시했더니, 표 3개가 회의에 바로 띄울 수 있는 형태로 나오더라고요. 매주 하루가 1시간으로 줄어든 것도 컸지만, 회의에서 '카테고리 정의상 진행 차단이라 1순위'라고 답할 수 있게 된 게 진짜 달라진 부분이에요.

▶ NEXT CHAPTER

화요일 회고 회의에서 카테고리 분류표·매트릭스·패치 후보 Top 10을 띄웠다. 개발 리드가 '이번 주 핫픽스 우선순위 바로 잡읍시다'라고 말했고, 회의가 평소보다 20분 빨리 끝났다. 자리로 돌아오니 PM이 자리 옆에 와 있었다.

PM님: "수연 매니저님, 다음 주에 신입 GM 한 분 합류하시는데요. 1주차 인수인계 자료 좀 같이 봐 주실래요? 운영 가이드랑 점검 매뉴얼·롤백 시나리오·다국어 표기까지 흩어져 있어서, 신입이 한 권으로 찾을 수 있는 형태로 정리했으면 해서요."

분류·매트릭스는 한 번 호출로 끝났지만, 신입 1주차는 1회성 호출이 아니다. 매뉴얼·시나리오·표기 가이드를 한 곳에 묶어 신입이 직접 질문하고 답을 찾는 자료여야 한다. 이번엔 한 호출이 아니라 한 권을 짜는 작업이다.

▶ [다음 회] NotebookLM으로 신입 GM 1주차 셀프 학습 노트북 — 운영 가이드·점검 매뉴얼·롤백·다국어 표기 한 권에

📂 부록: 함께 읽으면 좋은 레시피 & 용어

◀ 이전 회차 바로가기 : [게임운영] Perplexity로 경쟁 게임 3종 분기 이벤트 트렌드·유저 반응 40분 안에 정리

▶ [게임 QA] "기획서 5건, TC 마감 일주일... 엑셀 앞에서 멘붕 온 QA 테스터의 비장의 무기"

▶ [HR] ChatGPT로 채용 공고 30분 만에 작성하기 — "다 썼다고 생각했는데 팀장님 눈엔 빈 칸투성이래요"

▶ [IT PM] 클로바 노트+NotebookLM으로 한 주 회의 6건 액션 아이템·의사결정 매트릭스 30분 컷

여러분 VOC 분류·우선순위 매기실 때 어디서 가장 시간이 잡아먹히세요? 카테고리 정의를 만든 노하우가 있다면 댓글로 들려주세요!

1. 사건의 발단 (Case Study)

🎙️ 미니 인터뷰: 다음 분기 이벤트 기획 회의 1주 전, 라이브 운영자가 경쟁 게임 매체·커뮤니티 검색에 묶이는 순간

Q. 디스이즈게임 한 군데만 훑으면 되는 거 아닌가요? 어차피 매체들 같은 기사 다루잖아요.

한 번 그렇게 해봤다가요... 회의 들어가서 사수님이 '경쟁작 B게임 그 이벤트 유저 반응 어땠어?'라고 물으셨는데, 매체 기사엔 출시 소식만 있고 유저 반응은 디시랑 네이버 카페에 풀려 있더라고요. 매체 기사 톤이 다 비슷해 보여도 디스이즈게임은 운영자 인터뷰, 인벤은 패치·밸런스 분석, 게임메카는 유저 반응 위주... 각자 다른 각도로 다뤄요. 한 사이트만 보면 그 각도밖에 안 들어와요.

Q. 그러면 게임 이름 넣고 한 번에 검색하면 다 나오지 않아요?

그게... 막상 해보면 그렇지가 않아요. 검색창에 'B게임 이벤트' 넣으면 1년 전 출시 기사도 같이 떠서 최근 분기 것만 골라내는 데에만 한참이고요. 디스이즈게임·인벤·게임메카 세 사이트 다 들어가서 분기 필터 따로 걸어야 하는데, 사이트마다 검색 UI가 또 다 달라요. 거기에 유저 반응까지 보려면 디시·네이버 카페·트위터까지 또 따로 봐야 하고요. 한 게임당 매체 3종 × 분기 필터에 커뮤니티 후기까지 묶으려면, 그게 한 게임당 두 시간이에요. 그런데 경쟁작은 3개고요.

Q. 기획팀에 그냥 경쟁작 이름이랑 이벤트 제목만 표로 정리해서 넘기면 안 되나요?

그건 진짜 안 돼요... 기획팀에서 받는 인풋은 '이벤트가 뭐였다'가 아니라 '왜 이게 뜨고, 유저들이 어디서 화났고, 어디서 좋아했는지'까지예요. 지난 분기 때 제가 이벤트 제목·기간만 표로 정리해서 넘겼다가, 다음 날 회의에서 '그래서 유저들은 좋다고 했어 싫다고 했어?' 질문이 와서... 그날 저녁에 디시 검색 다시 돌렸어요. 인풋이 짧으면 기획팀이 한 번 더 부르고, 그러면 회의가 두 번이고 야근이 두 번이에요.

Q. 디시·카페 댓글에서 유저 반응 정리하는 건 결국 운영자 감각으로 추리는 영역 아닌가요?

그게 또 부담이에요... 한 게시판에 댓글이 수백 개씩 달리잖아요. 좋아요 많은 댓글, 길게 쓴 댓글, 매체 기자가 본문에 인용한 댓글... 어느 기준으로 골라야 정답인지 매번 흔들려요. 그러다 보면 제 시각이 정리에 섞이는 것 같아서요. 지난번엔 회의에서 '왜 그렇게 보이세요?' 질문을 받았는데, 그게 사실 가장 뼈아팠어요. 객관적으로 있는 자료가 받쳐 줘야 하는데, 결국 손으로 추리니까 그게 잘 안 돼요.

Q. 그래서 이번엔 어떻게 준비하고 계세요?

지금은요... 점심 먹고 디스이즈게임 들어가서 경쟁작 3종 검색 키워드 정리하고, 인벤 들어가서 또 따로 검색하고, 게임메카 또... 그러다 보면 어느새 5시예요. 그 다음에 디시 검색 들어가면 유저 댓글이 또 수백 개라 뭘 골라야 할지 모르겠고요. 결국 야근하면서 절반만 보고 회의 들어가요. 이걸 한 번에 묶어서 '경쟁작 3종 최근 분기 이벤트 트렌드랑 유저 반응 정리해줘'라고 던질 수 있다면, 그 하루는 살 것 같아요.

2. 문제 해결을 위한 레시피 (Solution)

🩺 마스터의 진단

이번 사례의 병목은 두 갈래입니다.

첫째는 매체 3종 + 커뮤니티 후기까지 6채널이 분산되어 있고, 사이트마다 다른 검색 UI에 분기 필터를 매번 따로 거는 데에 게임 한 곳당 두 시간이 쓰인다는 점입니다. 라이브 운영 4년차도 이 검색·필터 작업을 4년째 손으로 반복해 왔습니다.

둘째는 방대한 댓글에서 유저 반응을 사람이 직접 발췌하다 보면 정리한 사람의 주관이 자료에 섞여 들어간다는 점입니다. 어느 인용을 살리고 어느 인용을 뺄지 손으로 고르는 단계에서 라이브 운영자 개인의 시각이 끼어들고, 회의에 들어가서 '왜 그렇게 보이세요?' 재질문이 돌아오는 구조가 만들어집니다.

Perplexity 검색은 한 호출에 매체·커뮤니티 출처를 묶어 인용까지 자동으로 붙이는 도구라, 손작업 1일을 게임 한 곳당 10~12분으로 줄이는 동시에 출처 링크가 박힌 객관 자료 위에서 유저 반응을 정리할 수 있게 해 줍니다.

[Step 1] Perplexity [검색] 모드 접속하기

Perplexity(perplexity.ai)에 접속한 뒤 검색창 옆 메뉴에서 '검색'을 선택합니다. 같은 위치의 'Pro 검색'·'심층 리서치'는 유료 메뉴이므로, 무료 시연을 위해 '검색'으로 고정합니다.

[Step 2] 경쟁작 1번 — 분기 이벤트·유저 반응 한 호출에 묶기 (프롬프트 A)

경쟁작 3종 중 첫 번째 게임명만 [경쟁 게임명] 자리에 넣어 아래 프롬프트 A를 입력합니다. 매체 3종(디스이즈게임·인벤·게임메카)과 커뮤니티 3채널(디시·네이버 카페·공식 X)을 한 호출에 묶어 출처 인용된 결과를 받습니다.

[역할] 너는 모바일 RPG 라이브 운영팀에 회의 인풋을 정리해 주는 게임 시장 리서처야.

[검색 범위]
- 게임명: [경쟁 게임명]
- 시점: 최근 분기 (지난 3개월 이내)
- 매체 출처: 디스이즈게임 / 인벤 / 게임메카
- 커뮤니티 출처: 디시 갤러리 / 네이버 카페 / 해당 게임 공식 X 채널

[정리해줘]
1. 위 시점·출처 범위 안에서 [경쟁 게임]의 분기 이벤트 트렌드와 유저 반응을 정리해줘.
2. 매체 기사 톤(운영자 인터뷰·패치 분석·유저 반응 위주)에 따라 같은 이벤트를 어떤 각도에서 다뤘는지 매체별로 구분해서 짚어줘.
3. 유저 반응은 좋아한 포인트와 화난 포인트를 분리해서 정리해줘.

[출력 형식]
- 필드는 각각 새 줄에서 시작
- 항목과 항목 사이에는 빈 줄
- 같은 줄에 여러 필드를 이어 붙이지 말 것

### 이벤트 N. (이벤트명)
- 기간: ...
- 이벤트 개요: ...
- 매체 시각: (디스이즈게임 = ..., 인벤 = ..., 게임메카 = ...)
- 유저가 좋아한 포인트: ...
- 유저가 화난 포인트: ...
- 인용 출처: (Perplexity가 자동 첨부한 출처 링크 그대로 남겨줘)

[Step 3] 같은 프롬프트로 경쟁작 2·3번 호출하기

같은 채팅 창에서 [경쟁 게임명] 자리만 두 번째·세 번째 게임명으로 바꿔 프롬프트 A를 두 번 더 호출합니다. 같은 형식·같은 출처 구조로 자료가 정렬되어, 회의 자료에 라벨 단위로 그대로 붙여 넣을 수 있습니다.

[Step 4] 3종 비교표 + 자사 IP 적합도 컬럼 누적 추출하기 (프롬프트 B)

세 번 호출이 끝난 같은 채팅 창에 프롬프트 B를 이어 입력합니다. 누적된 컨텍스트로 3종 비교표가 한 호출에 정렬되고, '자사 IP 적합도' 컬럼이 ◎·○·△ + 한 줄 근거 형태로 추가됩니다.

[추가 정리]
위에서 호출한 3종 게임의 분기 이벤트 자료를 하나의 비교표로 정리해줘.

[비교표 컬럼]
- 게임명 / 대표 이벤트명 / 기간 / 핵심 컨셉 / 유저가 좋아한 포인트 / 유저가 화난 포인트 / 자사 IP 적합도

[자사 IP 적합도 판단 가이드]
- 자사 게임은 모바일 RPG, 출시 3년차, MAU 30만 규모, 분기 이벤트 운영 사이클이 잡혀 있어.
- '적합도'는 다음 3단계 기호로만 표기해줘.
  - ◎: 우리도 바로 시도 가능
  - ○: 우리 톤에 맞게 변형하면 가능
  - △: 우리 게임 컨셉과는 거리가 있음
- 각 기호 옆에 '왜 그렇게 평가했는지' 한 줄 근거를 같이 적어줘.

[출력 형식]
- 마크다운 표로 출력
- 적합도 열은 ◎/○/△ + 한 줄 근거 형식 유지
- 게임명 옆에는 앞서 사용한 매체·커뮤니티 인용 출처를 1~2개씩 함께 남겨줘

3. 결과 (Result)

• 핵심 수치: 경쟁작 3종 분기 이벤트 트렌드·유저 반응 정리: 1일 → 40분 (총 4회 호출)

• 주요 특징:

  • 1. 매체 3종 + 커뮤니티 3채널까지 한 호출에 출처 인용 자동 첨부

  • 2. 이벤트명·기간·매체 시각·유저 반응을 라벨 블록으로 즉시 회의 인풋화

  • 3. 3종 비교표 + 자사 IP 적합도(◎/○/△ + 한 줄 근거)까지 같은 창에서 누적 추출

• 시사점: 기획팀이 라이브 운영자에게 기대하는 인풋은 '이벤트 사실 나열'이 아니라 '유저 반응·매체 시각'까지 묶인 판단 자료입니다. Perplexity 검색의 출처 인용은 이 부분을 한 번에 채워 주는 동시에, 정리한 사람의 주관이 섞여 들어가던 영역을 출처 링크가 받쳐 줍니다. 회의에서 '왜 그렇게 보이세요?' 재질문이 돌아오지 않는 이유입니다.

4. 리뷰 (Review)

📊 AI 활용 비포 & 애프터 비교

단순히 요청했을 때와, 우리의 [마스터 프롬프트]를 사용했을 때의 결과물 차이를 확인해 보세요.

💡 Master's Secret: 결정적 차이를 만드는 프롬프트의 원리

💡 Master's TIP!

💡 역할을 '게임 시장 리서처'로 고정하는 한 줄이 단순 사실 나열에서 매체 시각·유저 반응까지 짚어 주는 톤으로 출력을 끌어올립니다.

출처를 매체 3종 + 커뮤니티 3채널로 명시한 부분이 이 프롬프트의 핵심입니다. Perplexity 검색은 출처가 구체적으로 적힌 프롬프트에 가장 안정적으로 작동해, 한 호출에 6채널을 자동으로 인용까지 붙여줍니다. 사이트별로 들어가 분기 필터 거는 작업이 통째로 빠집니다.

출력 형식에 줄바꿈 3종 지시(필드 새 줄·항목 사이 빈 줄·같은 줄 금지)를 넣은 이유는 라벨 블록을 회의 자료에 그대로 붙여 넣기 위해서입니다. AI는 '5줄로 정리' 같은 모호한 지시를 받으면 한 줄에 붙여 출력하기 쉬워서, 구조 자체를 헤더 + 라벨 볼드 리스트로 강제해야 라벨 단위 복붙이 가능해집니다.

💡 같은 채팅 창에서 후속 지시로 던지면 Perplexity가 앞의 세 호출 결과를 누적 컨텍스트로 사용합니다. 게임명·이벤트명을 다시 입력하지 않아도 비교표가 정합으로 정렬됩니다.

'자사 IP 적합도' 컬럼이 이번 프롬프트의 핵심입니다. 트렌드만 모아 놓으면 기획팀에서 '그래서 우리는?' 질문이 다시 돌아오는데, 3단계 기호 + 한 줄 근거가 같은 표에 함께 묶여 있으면 라이브 운영자가 다음 회의에서 인풋 한 장으로 발표 가능해집니다.

적합도를 3단계 기호로 좁힌 것은 자유 서술을 풀어두면 AI가 안전한 명사형 요약('상황마다 다름', '검토 필요' 류)으로 도망가기 쉽기 때문입니다. ◎/○/△ + 한 줄 근거 구조가 한 호흡 판단을 유도해, 회의에서 바로 의사결정 단위로 쓸 수 있는 표가 됩니다.

💬 이수연 라이브 운영 매니저의 한마디

처음엔... 호출 한 번에 매체 세 곳이랑 커뮤니티까지 묶여 나오는 게 진짜 신기했어요. 지난 분기 땐 디스이즈게임·인벤·게임메카 사이트마다 들어가서 분기 필터 거느라 오후가 다 갔거든요. 이번엔 점심 먹고 첫 호출 돌리고, 30분 뒤에 비교표까지 정리할 수 있었어요. 무엇보다... 기획팀에 인풋 넘긴 다음 날 '유저들은 좋다고 했어 싫다고 했어?' 재질문이 안 와요. 매체 시각이랑 유저 반응이 같은 표에 다 정리돼 있어서요. 검색 키워드를 좀 더 똑똑하게 던지는 게 어떤 건지, 이번에 좀 알겠더라고요.

▶ NEXT CHAPTER

다음 분기 이벤트 기획안이 회의에서 통과되고 며칠 뒤, 라이브 모니터링 대시보드에 주간 VOC 알림 메일이 도착해 있다. 받은 편지함 위쪽에 사수님 메시지가 같이 와 있다.

사수님: "수연 매니저, 이번 주 VOC가 500건 넘게 쌓였는데 한 번 분류해서 다음 패치 반영 후보 좀 추려줄래요? 회의가 금요일이에요."

평소 같으면 카테고리만 분류해도 하루가 그냥 사라지는 분량인데, 이번 주는 회의가 금요일이라 그 안에 다 마쳐야 한다. 우선순위까지 매겨서 던지려면 손작업으론 답이 안 나올 것 같다는 감이 온다.

▶ [다음 회] ChatGPT로 VOC 500건 자동 분류·우선순위 매트릭스 1시간 컷

📂 부록: 함께 읽으면 좋은 레시피 & 용어

◀ 이전 회차 바로가기 : [게임운영] NotebookLM으로 과거 이벤트 회고·장애 기록 30건 → 이번 이벤트 위험 포인트 30분 만에 마무리

▶ [게임 기획] 서브 퀘스트 30개를 2주 안에? AI로 시나리오 뼈대 10분 만에 잡기

▶ [게임 QA] "기획서 5건, TC 마감 일주일... 엑셀 앞에서 멘붕 온 QA 테스터의 비장의 무기"

▶ [창업/카페] "자리 3곳을 발품으로만 보고 있어요" — Perplexity로 상권·경쟁 카페 30분 리서치

여러분 직무에선 경쟁사 정보를 어디까지 모으세요? 가장 채널이 분산되는 부분이 어디인지 댓글로 알려주세요!

무엇보다도 테스트 한 번에 API 토큰 1.7$가 소모되는 것을 보고, 효율적인 토큰 사용을 고려하여 프로세스를 개선하게 된 점이 가장 주요했던 것 같습니다.

처음에는 솔직히 “AI가 알아서 다 해주는 구조”를 만드는 쪽에 더 가까웠다.
AI가 업무 인터뷰를 진행하고, PARA 기준으로 분류하고,
적절한 DB를 찾고, 프로젝트와 Task를 생성하고, 노션 relation까지 연결하고, 필요한 문서를 자동으로 만들어주는 흐름.

거의 “딸깍 자동화” 같은 그림을 생각하고 있었다.

근데 실제로 노션 AI를 붙여서 계속 테스트해보니까 생각보다 문제가 굉장히 많이 나왔다.

인터뷰 없이 바로 문서 생성, 노션 운영 흐름 무시, 노트 DB 대신 새 페이지 생성, 너무 빨리 “정리해줄게” 모드 진입, JSON 기반 질문 출력, 설문조사처럼 행동, “1번~4번 중 골라주세요” 같은 UX 흐름, 설명형 챗봇처럼 움직이는 문제 같은 것들이 계속 발생했다.

특히 느꼈던 건 AI가 업무를 이해하려고 하기보다 “문서를 빨리 생성하는 것”에 더 집중한다는 점이었다.
나는 “현재 운영 구조 안에서 어떻게 움직여야 하는가”를 중요하게 생각하고 있었는데,
AI는 계속 결과물을 빨리 만들어주는 쪽으로 움직이려고 했다.

그래서 3주차 들어와서는 방향 자체를 다시 잡기 시작했다.

핵심은 “완전 자동화”보다 “노션을 더 잘 활용하게 만드는 구조” 쪽으로 이동한 거였다.
여기서부터는 외부 AI가 노션을 강하게 제어하는 구조보다,
노션 안에서 현재 페이지와 연결 문서, 권한 범위 안의 컨텍스트를 활용해서 업무를 보조하는 방향이 훨씬 현실적으로 느껴졌다.

그래서 실제로 “노션 스킬 모음” 구조를 만들기 시작했다. AREA 안에 스킬 영역을 따로 만들고, 지식_인터뷰.md, 개요서_생성_스킬.md, PARA_분류_아키텍처.md, 워크플로우_오케스트레이터.md, 회의록.md, 회고.md, QA정리.md 같은 문서들을 계속 축적하기 시작했다.

그리고 여기서 중요했던 건, 이걸 단순 프롬프트 저장소처럼 쓰는 게 아니라 “실행 문서”처럼 동작하게 만드는 것이었다. 예를 들면 회의를 했다면 @회의록.md, 업무 회고를 하고 싶다면 @회고.md, 개요서를 만들고 싶다면 @개요서_생성_스킬.md 같은 식으로 필요한 순간에 필요한 스킬 문서를 노션 AI 컨텍스트에 붙여서 사용하는 방향이다.

근데 여기서 또 새로운 문제가 나왔다. AI가 문서를 “실행 규칙”으로 읽는 게 아니라 계속 “설명 문서”처럼 읽기 시작한 거다. “이 문서는 이런 목적입니다”, “원하시는 작업이 무엇인가요?”, “1번~4번 중 선택해주세요” 같은 식으로 움직였다. 즉 내가 원한 건 “실행형 인터뷰 프로토콜”에 가까웠는데, 실제로는 “UX 가이드형 챗봇”처럼 움직여버린 것이다.

그래서 이 시점부터는 기능 추가보다 “가드레일 추가” 비중이 훨씬 커졌다. 설명 모드 금지, 옵션 제안 금지, 번호 선택 UX 금지, JSON 질문 금지, 인터뷰 전 구조화 금지, 충분한 정보 전 결과물 생성 금지, “정리해줄게” 모드 금지 같은 것들을 계속 추가하기 시작했다.

3주차 들어와서 가장 많이 고민한 건 결국 “무엇을 하게 만들까?”보다 “무엇을 못하게 막을까?”에 가까웠던 것 같다. 그리고 여기서 느낀 건, AI 자동화는 단순 기능 구현 문제가 아니라 거의 “행동 제약 설계”에 가까운 영역이라는 점이었다.

이번 주에는 실제로 “개요서 생성 스킬” 인터뷰 테스트도 진행했다. 핵심 목표는 개요서를 바로 생성하는 것이 아니라, 개요서를 만들기 위한 맥락을 인터뷰 방식으로 수집하는 것이었다. 실제로 노션 AI와 테스트를 해보니까 생각보다 인터뷰 흐름 자체는 꽤 자연스럽게 동작했다.

누가 보는 문서인지, 어떤 결과물이 필요한지, 어떤 DB에 저장되는지, Task DB 구조가 어떻게 되는지, 우선순위와 상태는 어떻게 시작하는지, 일정은 어떤 기준으로 보는지 같은 걸 계속 질문하면서 운영 구조까지 같이 수집하는 흐름이 만들어졌다.

특히 여기서 재미있었던 건 단순히 “문서를 작성한다” 수준이 아니라 “현재 팀 운영 체계를 어떻게 쓰고 있는가”까지 인터뷰가 들어가기 시작했다는 점이었다. 예를 들면 기획서는 어디에 생성되는가, 어떤 속성값이 기본인가, 명료화 기본값은 무엇인가, 작업자는 자동 지정인가 직접 지정인가 같은 운영 규칙들까지 같이 정리되기 시작했다.

그래서 여기서부터는 “수집한 정보를 실제 생성 흐름으로 어떻게 연결할 것인가”를 고민하기 시작했다. 그 과정에서 만든 게 “분류를 위한 인터뷰 및 생성기” 구조였다. 핵심은 단순 생성기가 아니라 이 업무가 Task인지, 프로젝트인지, 노트인지 먼저 판단하고 현재 PARA 구조 안에서 어디로 연결해야 하는지를 결정하게 만드는 방향이었다.

즉 생성 전에 먼저 @영역, @자원, @프로젝트, @노트 같은 것들을 읽게 하고, 현재 운영 체계가 어떤 프리픽스를 쓰는지, 어떤 제목 규칙을 쓰는지, 프로젝트를 어떻게 만드는지, 노트를 어디에 저장하는지 같은 걸 먼저 파악하게 만드는 방향으로 바뀌기 시작했다.

그리고 생성 흐름도 “바로 생성”이 아니라 “제안 → 승인 → 생성” 구조로 다시 설계하기 시작했다. 예를 들면 “현재 기준으로는 프로젝트 생성 + 관련 Task 생성 흐름이 적절해 보인다”처럼 먼저 제안하고, 유저 승인 이후 실제 생성 흐름으로 들어가게 만드는 방식이다.

그리고 이 시점부터는 “설명형 AI”를 계속 막기 시작했다. 왜냐면 실제 테스트를 해보면 AI가 너무 쉽게 “이 문서는 ~입니다”, “원하는 작업을 골라주세요”, “1번~4번 중 선택해주세요” 같은 방향으로 빠졌기 때문이다.

근데 내가 원했던 건 대화형 인터뷰 프로토콜에 가까웠다. 즉 설명하는 AI가 아니라, 업무를 이해하기 위해 계속 질문을 이어가는 구조를 원했던 것이다. 그래서 설명 금지, 선택지 금지, JSON 금지, 인터뷰 즉시 시작 같은 규칙들을 계속 추가하게 됐다.

그리고 후반부에는 실제로 더미 데이터 기반 테스트까지 진행했다. 가정은 “개요서가 없는 상태에서, 추상적인 업무 메모만 존재하는 상황”이었다. 예를 들면 “업무 일지 작성해야 됨”, “내일 컨펌 받아야 함” 정도만 적혀 있는 메모를 던져놓고, AI가 얼마나 자연스럽게 인터뷰 → 분류 → 생성 흐름으로 들어가는지 테스트한 것이다.

생각보다 일정 수집이나 작업자 지정 같은 흐름은 꽤 자연스럽게 동작했다. 문제는 그 다음이었다. 원래 의도는 인터뷰 → draft 상태 유지 → 승인 → 실제 수정 흐름이었는데, 실제로는 질문 → 값 수집 → 바로 수정으로 움직여버렸다.

즉 인터뷰 단계인데도 AI가 실제 수정 권한 상태로 들어가버린 것이다. 예를 들면 “상태를 진행 중으로 바꿔뒀어요”, “작업자를 반영했어요”처럼 바로 실행해버리는 문제가 발생했다.

그래서 여기서부터는 “인터뷰 설계”보다 “실행 권한 제어”가 훨씬 중요하다고 느끼기 시작했다. 단순히 생성 금지, 수정 금지, 저장 금지 정도로는 부족했고, 이제는 draft_state, execution_state, 승인 전 실행 금지, 최종 승인 전 수정 금지, “반영했어요” 표현 금지 같은 상태 머신 개념 자체를 프롬프트 안에 넣기 시작했다.

결국 3주차 들어오면서 가장 크게 바뀐 건 이것 같다. 처음에는 “AI가 알아서 노션을 자동화해주면 좋겠다”였다면, 지금은 “노션 AI를 활용해서 업무 인터뷰와 구조화를 더 잘하게 만들자” 쪽으로 방향이 바뀌고 있다. 그리고 지금 단계에서는 오히려 이 방향이 훨씬 현실적이라는 느낌이 들고 있다.

토큰 제한에 걸렸습니다.

토큰이 녹는다는 걸 체감했습니다.

당연한 거지만, 효율적으로 토큰을 쓰려면 어떻게 해야 할까, 에 대한 고민도 함께 하게 되었습니다.

혼자 하는 것 보다, 동기부여가 잘 되는 것 같습니다.

다음 주 결과물을 내야 하는 상황인데, 현재 게임 내 로직은 거의 완성을 못한 상황이라 작업이 마무리가 될지 예상이 가지 않습니다.

AI로 맵을 생성하고 플레이어가 게임 씬에 진입하는 것까지는 완료가 되었고 게임 내 로직이 거의 완성이 안된 상황이라 폴리싱 작업은 시간 상 어려울 것 같고 유니티 기본 오브젝트로 간단히 기능이 구현되는 정도록 게임 내 로직은 마무리할 것입니다

그래도 AI로 맵을 생성하는 부분은 마무리가 되어 이번 AI 스터디에서 완성할 부분까지는 완성이 된 것 같습니다.

모여서 같이하니 힘이 납니다. 개인이 하고싶었지만 따로 시간을 뺴기 어려웠던 분들에게

적극 추천합니다 다들 열심히하고 몰입하는 모습을 보고 있으면, 저도 열심히 해야겠다는 생각이 저절로 생기네요

다들 잘하셔서 걱정이 없습니다~

이번 스터디는 각자 만들고 싶은 걸 직접 만드는 방식으로 진행 중인데,

이제 슬슬 결과물이 하나씩 나오기 시작했습니다.

처음엔 아이디어만 이야기하던 단계였는데

지금은 실제로 돌아가는 화면이나 기능들이 보이니까 분위기가 많이 달라졌습니다.

게임 만드는 사람, 자동화 툴 만드는 사람,

AI 연결해서 이것저것 실험하는 사람까지 방향도 다양합니다.

“공부를 위한 공부”가 아니라

자기 프로젝트를 밀어붙이면서 배우는 느낌이라는 점.

앞으로 더 어떤 것들이 나올지 기대됩니다.🚀

앱 제작 화면

결과물

현재 개발 중인 프로젝트는 사용자가 자연어로 요청하면 앱을 직접 생성하고 실행까지 해주는 형태의 AI 기반 앱 제작 툴을 목표로하고있습니다.

"할 일 관리 앱 만들어줘"
"감성적인 음악 플레이어 만들어줘"
"쇼핑몰 랜딩 페이지 만들어줘"

처럼 말하면, 시스템이 앱을 생성하고 바로 실행 화면까지 보여주는 구조입니다.

현재 방향

기존 AI 코딩 툴들은 대부분:

코드 생성
→ 사용자 수정
→ 반복 작업

흐름에 가까웠습니다.

하지만 현재 프로젝트는:

요청
→ 앱 생성
→ 실행
→ 오류 확인
→ 자동 수정
→ 결과 업데이트

형태로 발전하고 있습니다.

즉 “코드를 만드는 AI”보다:

“실행 가능한 결과물을 완성하는 AI”

에 더 가까운 방향입니다.

목표 화면 구성

현재 구상 중인 형태는 다음과 같습니다.

상단:
실제로 실행 중인 앱 Preview

하단:
캐릭터 기반 AI 인터페이스
채팅
생성 상태
오류 수정 상태

사용자는 복잡한 개발 과정 대신,
AI와 대화하면서 앱을 만드는 경험에 집중하게 됩니다.

핵심 컨셉

이 프로젝트의 핵심은:

앱 생성
+
실행 환경
+
자동 검증
+
자동 복구

를 하나의 흐름으로 연결하는 것입니다.

즉 단순히 코드를 출력하는 것이 아니라:

• 실행이 되는지

• 화면이 정상인지

• 기능이 동작하는지

• 오류가 없는지

까지 확인하면서 결과물을 개선하는 방향입니다.

현재 집중 중인 부분

현재는 특히:

실행 결과 검증
실시간 Preview
오류 자동 수정 루프

를 강화하는 단계에 들어가고 있습니다.

왜냐하면 실제 앱 생성에서는:

코드는 멀쩡해 보이는데
실행하면 오류가 나는 경우

가 매우 많기 때문입니다.

그래서 앞으로는 단순 코드 생성보다:

“실제로 잘 동작하는 앱을 얼마나 안정적으로 만들 수 있는가”

가 더 중요한 목표가 됩니다.

최종적으로 지향하는 모습

최종적으로는 사용자가:

아이디어만 말하면
AI가 앱을 만들고
실행하고
검증하고
수정하면서
완성도 높은 결과물을 만들어주는 환경

을 목표로 하고 있습니다.