AI로 인터뷰와 리뷰 분석하기: 근거를 묶고 반대 사례로 다시 확인하기
인터뷰·리뷰·관찰 13개를 AI로 분류하고 같은 참여자의 기록을 묶습니다. 실제 응답의 성급한 원인 판단을 수정하고, 새 버전과 권한 자료로 연구 메모를 다시 검증합니다.
읽기 약 40분2026.10 기준
수업 안내 · 목표와 준비물
이 글을 마치면
- 원문 번호·참여자 번호·버전을 보존해 여러 자료를 AI에게 전달합니다.
- 기록 수와 사람 수, 관찰과 해석, 도움받은 완료와 독립 완료를 구분합니다.
- 분류 의견이 갈릴 때 AI에게 원문 근거와 대안 설명을 다시 요청합니다.
- 새 버전의 성공 사례와 의도된 권한 제한을 기존 결론에 맞게 반영합니다.
이런 분께
- 기초적인 AI 대화 뒤 실제 업무 자료를 어떻게 입력하고 답을 고칠지 배우고 싶은 분
- 완성된 AI 대화와 검수본을 먼저 읽으며 익히려는 비전문가
준비물
- 모든 고객·제품·인터뷰·숫자는 편집자가 만든 가상 연습 자료입니다. 실제 고객 정보가 필요하지 않습니다.
- AI 계정이나 결제 없이 원자료·실제 응답·해설을 읽을 수 있습니다. 따라 해 볼 때만 이미 이용 가능한 AI에 이 가상 자료를 복사하세요.
- 한국어 요청으로 한영 응답을 함께 받은 실행입니다. 영어 요청문은 같은 작업을 따라 하는 동등한 안내이며 별도 영문 실행 기록은 아닙니다.
이 수업의 용어, 쉬운 말로
뜻을 먼저 읽고 본문으로 가세요. 용어를 누르면 예시까지 볼 수 있습니다.
- 가설
- 아직 확인하지 않았으며, 관찰이나 실험으로 맞는지 알아볼 생각.
외부 AI 도구의 활용법을 배우는 읽기 교재입니다. 쉬운 이론 → 단계별 활용법 → 예제와 해설 순서로 읽으세요. 목차에서 원하는 부분으로 이동할 수 있습니다.
1 / 4
쉬운 이론
AI에 무엇을 맡기고 어떻게 요청할지, 필요한 원리부터 이해합니다.
요약을 짧게 만드는 일과 근거를 잃지 않는 일
가상 문서 앱 ‘모아노트’의 인터뷰 4개, 공개 리뷰 6개, 진행자 관찰 3개를 받았습니다. AI에게 “주요 불만 세 가지로 요약해 줘”라고 하면 비슷한 말을 한 줄로 묶기 쉽습니다. 그런데 인터뷰 I2와 리뷰 R2는 같은 사람이 같은 사건을 말한 기록입니다. 두 문서를 두 명의 의견으로 세면 원문보다 문제가 널리 나타난 것처럼 보입니다. 이 수업에서는 AI가 요약하기 전에 기록의 주인과 상황을 보존하도록 요청합니다.
이 수업에서 익힐 제품 연구 AI 활용 순서는 다음과 같습니다. 인터뷰·리뷰에 출처 번호 붙이기 → 분류 기준 설명하기 → AI에 주제별 근거 정리 요청하기 → 반대 사례와 분류 차이 확인하기 → 새 자료로 결론의 범위 다시 정하기. 각 단계에서 왜 그 자료와 조건이 필요한지 이론을 먼저 설명하고, 요청 예시·완성 예제·해설로 판단 과정을 살펴봅니다. 외부 AI 도구를 사용할 때의 방법을 읽으며 배우는 교재이므로 계정이나 실행 환경을 준비하지 않아도 됩니다.
AI에 맡길 분류란 비슷한 장면에 임시 이름표를 붙이는 일입니다. ‘다음 버튼을 결제로 생각했다’는 문장에는 첫 사용 안내라는 이름을 붙일 수 있습니다. 이름표는 자료를 찾기 위한 도구이며 원인을 확정한 진단이 아닙니다. 같은 문장에 성능과 완료 안내 두 이름표가 함께 필요할 수도 있습니다. 처음부터 하나의 정답 분류를 강요하면 자료에 남아 있던 다른 설명을 지우게 됩니다.
관찰과 해석도 따로 둡니다. ‘재초대 뒤 프로젝트가 보였다’는 기록은 사건의 순서이고, ‘초대 권한이 원인이었다’는 말은 그 순서를 설명하는 가설입니다. AI는 긴 문장을 압축하면서 둘을 쉽게 이어 씁니다. 그래서 이번 요청은 근거 ID, 정확한 인용, 해석, 반대 사례, 남은 질문을 나란히 내도록 정합니다. 읽기 좋은 결론보다 되짚어 볼 수 있는 분석 구조를 먼저 받는 것입니다.
실제 Claude Sonnet 5.5 대화에서는 첫 응답이 일부 접근 문제의 원인을 초대 설정이라고 단정했습니다. 두 번째 요청에서 원문과 분류 의견 차이를 다시 보게 하자 원인이 아직 확정되지 않았다는 설명으로 좁혔습니다. 마지막에는 새 버전의 성공과 의도된 권한 제한을 넣어 결론의 적용 범위를 바꾸었습니다. 아래 실제 응답과 편집자 해설을 함께 읽으면 AI를 분석 보조로 쓰면서 어떤 지점을 직접 검수해야 하는지 볼 수 있습니다.
원자료를 넣을 때 기록 번호와 사람 번호를 분리하기
원자료의 I는 인터뷰, R은 리뷰, O는 관찰입니다. U01 같은 participant 값은 사람 번호입니다. I2와 R2는 모두 U02, I3와 O2는 모두 U03입니다. 따라서 처음 기록은 13개지만 사람은 11명입니다. 이 중복은 지워야 할 쓸모없는 문서라는 뜻이 아닙니다. 같은 사람의 인터뷰와 관찰은 서로 보완할 수 있습니다. 다만 ‘몇 명에게 나타났는가’를 셀 때 신규 참여자로 더하지 않는다는 뜻입니다.
그림: 같은 사람의 인터뷰와 리뷰 두 기록을 한 참여자 아래에 묶어 사람 수를 중복 계산하지 않습니다. · AI Ping 문서 맨 위에는 전체 자료가 모아노트 v2.1에 관한 가상 기록이라고 적었습니다. 버전은 언제의 제품에 관한 말인지 정하는 조건입니다. 본문 한 문장만 떼어 AI에 주면 이 정보가 사라질 수 있으므로 전체 자료의 공통 조건과 각 기록의 번호를 함께 전달합니다. 실제 작업에서 문서를 여러 번 나누어 넣는다면 각 묶음에도 이 공통 조건을 반복해, 어느 답이 어느 버전 자료에서 나왔는지 확인해야 합니다.
완료 여부도 한 가지 표시로 합치지 않습니다. R3의 U06은 첫 팀 만들기를 혼자 마쳤습니다. I2의 U02는 동료 설명 후, O3의 U11은 진행자 설명 후 마쳤습니다. I4와 O1은 키보드로 저장하지 못하다가 다른 사람이 마우스를 사용하거나 건네준 뒤 저장했습니다. AI가 마지막 ‘저장했다’만 남기면 실패 장면이 성공 사례가 됩니다. 어떤 과제를 어떤 도움으로 끝냈는지가 문장 안에 남아 있어야 합니다.
아래 표는 핵심 자료의 지도이고, 내려받는 파일에는 13개 기록 전체가 있습니다. I1의 숙련 이용자는 검색을 대체로 잘 썼고, R3의 첫 이용자는 안내를 혼자 이해했습니다. 이 두 기록도 삭제하지 않습니다. 문제가 있었던 기록과 함께 두어야 ‘모두 헷갈린다’는 요약을 막고 어떤 조건에서 경험이 달랐는지 다음 질문을 만들 수 있습니다. 이 자료는 목적에 맞춰 고른 가상 사례이므로 전체 이용자의 비율을 추정하는 설문으로 읽지 않습니다.
분류 전 확인할 원자료 지도 기록 사람 읽을 때 남겨야 할 조건 I2 + R2 U02 한 명 같은 사건, 동료 설명 뒤 완료 I3 + O2 U03 한 명 재초대 설정 확인 뒤 보임, 원인 별도 I4 + O1 U04·U10 두 명 키보드 저장에 다른 사람/마우스 도움 R3 U06 첫 팀 만들기 독립 완료 R1 + R6 U05·U09 지연 시간 미측정, 첫 업로드 실패 미확인 전체 I1~I4/R1~R6/O1~O3 고유 11명 13개 기록, v2.1 가상 자료
2 / 4
단계별 활용법
어떤 자료를 준비하고 어떻게 요청하며 결과를 고쳐야 하는지, 예제와 해설로 배웁니다.
첫 요청: 원문과 해석을 나란히 받기
첫 요청에서는 ‘불만 요약’ 대신 일곱 열의 근거표를 요구합니다. 주제, 근거 ID, 직접 관찰, 해석, 고유 참여자, 반대 사례, 남은 질문입니다. 길어 보이지만 각 열의 역할은 분명합니다. 근거 ID는 원문을 찾고, 관찰은 실제 적힌 말을 남기고, 해석은 분석자가 덧붙인 설명을 표시합니다. 반대 사례와 남은 질문은 결론이 아직 설명하지 못하는 범위를 보존합니다.
Claude는 기록 13개와 참여자 11명을 구분했고, I2/R2와 I3/O2의 중복도 찾았습니다. ‘첫 팀 다음’ 주제에는 U02와 U11을 두 명으로 묶고, U06의 독립 성공을 반대 사례로 남겼습니다. ‘키보드 저장’은 U04와 U10 두 명으로 묶었습니다. 편집자는 ID를 원자료에서 직접 찾아 이 숫자와 도움 조건을 대조했습니다. AI가 정확한 인원 수를 썼더라도 그 인원에 어떤 기록이 포함됐는지 확인하지 않으면 중복을 놓칠 수 있습니다.
문제가 된 곳은 ‘프로젝트 안 보임’ 주제의 해석입니다. 실제 답은 ‘원인은 초대 설정’이라고 썼습니다. I3는 바뀐 것이 초대 설정이었다고 말하고 O2도 확인 뒤 보였다고 관찰했지만, 변경 전 상태의 녹화나 실제 설정 차이는 없습니다. R4는 재초대 뒤 보였다는 순서만 말합니다. 시간상 뒤따라 일어난 일을 원인으로 확정한 표현이므로, 여기서는 ‘초대·접근 상태를 확인할 필요가 있다’는 가설로 낮추어야 합니다.
또한 ‘날짜로 스스로 복구해 위험은 낮아 보임’은 응답 자체도 추측이라고 적었습니다. 복구에 성공한 기록만으로 잘못된 문서를 연 영향이 작다고 확인할 수는 없습니다. AI에게 표를 부탁하면 이런 해석이 사실과 같은 칸에 섞이기 쉬운데, 이번 요청은 해석 열을 따로 두었기에 검토 지점이 드러났습니다. 아래 첫 답을 읽으며 사실을 잘 추출한 부분과 다시 요청해야 할 해석을 동시에 찾아보세요.
프롬프트 예시 이 작업은 가상 교육 사례입니다. 외부 검색·파일·도구 없이 제공한 텍스트만 분석하세요. 주어진 연구 자료만으로 AI 분석 초안을 만드세요. ①13개 기록과11명 고유참여자를 구분해 확인 ②주제별 근거 ID/직접 관찰/해석/고유참여자/반대사례/남은질문 표 ③우선 확인할 문제 두 개와 그 이유. 인용은 원문 그대로 쓰고 관찰과 추측을 구분하세요. 같은사람 중복기록은 신규참여자로 세지 말며, 진행자도움으로 완료한 사례는 독립완료로 쓰지 마세요. 전체고객 불만비율·미측정시간·기능존재를 만들지 마세요. 가상 협업 문서 앱 모아노트 v2.1 조사 자료. 아래 인터뷰·리뷰·관찰은 모두 편집자가 만든 연습 자료다. 기록 13개, 고유 참여자 11명이다. 같은 participant는 중복 사람이다. 표본은 목적 표집이며 전체 이용자의 비율을 추정하지 않는다. I1 | participant U01 | 숙련 이용자 인터뷰 | 나는 프로젝트를 네 개 관리한다. 검색창에 단어 두 개를 넣으면 필요한 문서를 대체로 찾는다. 예전 앱에서 검색을 자주 써서 위치가 낯설지 않았다. 새 직원이 폴더를 찾다가 도움을 청할 때는 내가 검색창을 알려 준다. 내가 쉽게 쓴다는 이유로 처음 온 사람도 그렇다고 보지는 않는다. 공지 문서 이름이 비슷할 때는 날짜를 보고 고른다. 파일 수가 아주 많아지면 어떤지는 경험하지 못했다. I2 | participant U02 | 첫 이용 인터뷰 | 초대 링크로 들어와 팀 이름을 썼다. 다음 버튼 옆에 요금제 설명이 보여서 누르면 결제가 되는 줄 알았다. 카드 정보를 넣고 싶지 않아 창을 닫았다. 실제로 돈이 청구됐다고 말하는 것은 아니다. 다음 날 동료가 '저건 팀을 만드는 단계'라고 설명하자 마무리했다. 내 계정에서 다시 해 보면 이미 끝난 과정이라 같은 상황을 보여 주기는 어렵다. 내가 쓴 리뷰에도 다음 화면이 불안하다고 남겼다. I3 | participant U03 | 읽기 전용 이용자 인터뷰 | 동료가 만든 프로젝트가 목록에서 안 보여서 검색이 고장 났다고 생각했다. 관리자가 초대 권한을 다시 확인한 뒤에는 그 프로젝트가 보였다. 권한 변경 전 검색어를 정확히 무엇으로 썼는지 기억하지 못한다. 프로젝트 안에서는 읽기만 했고, 수정하려고 시도한 적은 없다. 비슷한 이름의 다른 프로젝트는 계속 보였다. 내 추측은 검색 문제였지만 바뀐 것은 초대 설정이었다. I4 | participant U04 | 키보드 이용자 인터뷰 | 마우스를 오래 잡기 어려워 Tab 키로 이동한다. 제목과 본문은 입력했지만 저장 버튼으로 갈 때 순서가 화면 밖으로 넘어갔다. 키를 더 누르다가 처음 위치로 돌아왔다. 집에서는 다른 사람이 마우스로 눌러 주어 저장했다. 정확히 몇 번 눌렀는지는 세지 않았다. 단축키가 있다는 안내를 못 봤고 실제로 그런 기능이 있는지도 모른다. 혼자 저장까지 할 수 있는지가 내게는 중요하다. R1 | participant U05 | 공개 리뷰 | CSV 파일 2,000행을 올린 뒤 화면이 오래 멈춘 듯했다. 시간을 재지는 않았다. 작은 파일에서는 못 느꼈다. 업로드가 끝났는지 알려 주면 좋겠다. R2 | participant U02 | 공개 리뷰 | 팀 이름 다음 화면이 결제로 이어지는 것 같아 닫았다. 동료 설명을 듣고 다시 했다. I2와 같은 사람, 같은 사건이다. R3 | participant U06 | 공개 리뷰 | 초대받아 첫 팀을 만드는 과정은 혼자 끝냈다. 무엇을 눌러야 하는지 헷갈리지 않았다. 문서 검색은 아직 써 보지 않았다. R4 | participant U07 | 공개 리뷰 | 동료 프로젝트가 안 보여 고객센터에 문의했다. 초대를 다시 받고 보이기 시작했다. 검색이 느렸는지는 확인하지 않았다. R5 | participant U08 | 공개 리뷰 | 문서 이름이 비슷해 오래된 초안을 열었다. 수정 날짜를 보고 다시 골랐다. 검색 결과를 정렬할 수 있는지는 모르겠다. R6 | participant U09 | 공개 리뷰 | 파일을 올린 뒤 완료 안내를 못 찾아 같은 파일을 다시 올렸다. 첫 업로드가 실패했는지는 확인하지 못했다. O1 | participant U10 | 진행자 관찰 | v2.1에서 키보드만 사용했다. 본문 입력 후 Tab 이동이 저장 버튼을 지나쳤다. 진행자가 마우스를 건네자 저장했다. 독립 완료로 기록하지 않는다. O2 | participant U03 | 진행자 관찰 | I3와 같은 사람. 초대 설정 확인 후 프로젝트가 목록에 보였다. 검색 기능 수정은 수행하지 않았다. 권한 변경 전 화면 녹화는 없다. O3 | participant U11 | 진행자 관찰 | 첫 팀 만들기에서 다음 버튼 앞에 멈췄다. 진행자가 '결제가 아니라 다음 설정'이라고 말한 뒤 완료했다. 스스로 이해하고 완료한 사례와 구분한다.
완성 예제와 해설 2026년 10월 28일 Claude Sonnet 5.5에 실제로 입력해 받은 1번째 응답 원문입니다. 한국어 요청으로 한영 결과를 함께 받았으며, 아래 문장을 편집자가 고치지 않았습니다. 바로 위 해설과 뒤의 검수본은 편집자가 쓴 내용입니다.
응답 예제외부 AI 도구의 활용 과정을 설명하는 교재 예제입니다. 요청 조건에 따라 결과는 달라집니다.
1. 확인
- 기록 13개(I1–I4, R1–R6, O1–O3) = 고유 참여자 11명(U01–U11). R2=I2(U02), O2=I3(U03)는 같은 사람·사건이라 신규로 세지 않음(13−2=11).
- 목적 표집이라 비율을 추정하지 않고 명수만 씀.
- 독립 완료는 U06(R3)뿐. U02(동료 설명)·U11(진행자 설명)·U10(진행자 마우스)·U04(타인 마우스)는 도움 후 완료라 독립 완료가 아님.
2. 주제별 근거 (관찰=원문, 해석=추측)
주제 근거 ID 직접 관찰 해석(추측) 고유참여자 반대사례 남은 질문 첫 팀 ‘다음’ I2, R2, O3 U02 “누르면 결제가 되는 줄 알았다”, U11 “다음 버튼 앞에 멈췄다” 요금제 문구가 단계 목적을 가렸을 수 있음 2명(U02, U11) U06 R3 “혼자 끝냈다” U02 재현 불가, U06과 화면 차이 미확인. 실제 청구 보고 없음 키보드 저장 I4, O1 U04 “저장 버튼으로 갈 때 순서가 화면 밖으로 넘어갔다”, U10 “Tab 이동이 저장 버튼을 지나쳤다” Tab 순서 문제 가능 2명(U04, U10) 자료에 독립 성공 기록 없음(없다는 증명은 아님) 키 횟수 미측정, 단축키 존재 불명 프로젝트 안 보임 I3, O2, R4 U03 “바뀐 것은 초대 설정이었다”, U07 “초대를 다시 받고 보이기 시작했다” 원인은 초대 설정. 검색 결함의 근거 아님 2명(U03, U07) I3 “비슷한 이름의 다른 프로젝트는 계속 보였다”, R4 “검색이 느렸는지는 확인하지 않았다” U03의 변경 전 검색어·녹화 없음 업로드 완료 인지 R1, R6 U05 “화면이 오래 멈춘 듯했다. 시간을 재지는 않았다”, U09 “완료 안내를 못 찾아 같은 파일을 다시 올렸다” 완료 표시가 불명확했을 수 있음. 속도는 판단 불가 2명(U05, U09) R1 “작은 파일에서는 못 느꼈다” U09 첫 업로드 실패 여부(“확인하지 못했다”), 실제 지연 시간 비슷한 문서명 I1, R5 U01 “이름이 비슷할 때는 날짜를 보고 고른다”, U08 “오래된 초안을 열었다” 후 날짜로 재선택 날짜로 스스로 복구해 위험은 낮아 보임(추측) 2명(U01, U08) I1 검색을 “대체로 찾는다”. 단 “처음 온 사람도 그렇다고 보지는 않는다” 정렬 가능 여부 U08 “모르겠다”, 파일 매우 많을 때 U01 미경험 3. 우선 확인할 문제 두 개
- 키보드 저장: 두 명 모두 핵심 행동인 저장을 혼자 끝내지 못함. U04 “혼자 저장까지 할 수 있는지가 내게는 중요하다.” 확인: Tab 순서를 재현하고 단축키가 있는지부터 점검(존재 가정 금지).
- 첫 팀 ‘다음’: 두 명이 초반에 멈추거나 이탈(U02는 “창을 닫았다”). U06은 혼자 끝냈으므로 어떤 조건에서 혼동이 생기는지 확인.
우선순위는 빈도가 아닌 영향·근거 강도 판단이다. 프로젝트 안 보임은 초대 설정부터, 업로드는 시간 미측정이라 후순위.
분류 의견이 갈리면 AI에게 근거를 다시 묻기
두 번째 입력 D1에는 검토자 갑이 R4를 ‘검색 실패’, 검토자 을이 ‘초대/접근 권한’으로 분류했다고 적었습니다. AI에게 어느 검토자가 옳은지 투표시키지 않습니다. 대신 원문에 실제로 검색 사용이나 실패가 나오는지, 재초대 이후 무엇이 바뀌었다고 적혀 있는지 나누어 읽게 합니다. 분류 이름을 고르는 일보다 이름이 어떤 증거를 주장하는지 확인하는 과정입니다.
그림: 다수의 묶음 안에서도 다른 경험을 말하는 기록을 따로 펼쳐 원문과 조건을 다시 확인합니다. · AI Ping 실제 후속 답은 R4에서 ‘안 보임 → 문의 → 재초대 뒤 보임’의 순서를 꺼냈습니다. 검색 사용·실패는 원문에 없고 초대 원인도 인과가 확인되지 않았다고 정리한 뒤 ‘가시성, 원인 미확정’이라는 임시 이름을 제안했습니다. 가시성은 여기서 프로젝트가 보이는지 여부를 뜻합니다. 전문 용어가 편하지 않다면 완성 문서에는 ‘프로젝트가 안 보임: 원인은 확인 중’이라고 쓰면 같은 상태를 더 쉽게 전달할 수 있습니다.
R1에는 두 이름표를 남깁니다. 2,000행 CSV 이후 멈춘 듯했다는 인상은 대용량 처리 성능 질문으로, 끝났는지 알려 달라는 문장은 완료 안내 질문으로 이어집니다. 시간을 재지 않았으므로 ‘30초 지연’ 같은 숫자는 쓰지 않습니다. 추가 인터뷰 N1의 U12는 오래된 도움말 화면 때문에 버튼을 몰랐다고 말합니다. 권한 문제와 다른 설명이지만, 이 사람은 프로젝트가 사라졌다고 말한 것이 아니므로 I3/R4의 원인을 N1로 대신 확정하지 않습니다.
N1 한 개가 추가되었으므로 연구 기록은 14개, 고유 참여자는 12명입니다. D1~D3는 분석자의 검토 지시이며 사람이나 인터뷰로 세지 않습니다. 모델이 데이터를 읽으며 만든 분류 표까지 새 연구 결과로 누적하면 자료 수가 부풀어 오릅니다. 편집자 검수본은 원자료, 검토 메모, 제품 정책의 역할을 계속 구분합니다. 이처럼 후속 요청은 ‘더 자세히’가 아니라 어떤 문장과 분류를 다시 검사할지 지정할수록 검수하기 쉽습니다.
프롬프트 예시 아래 분류 의견차이와 새자료를 반영해 분석을 수정하세요. R4의 분류 근거를 원문으로 설명하고 관찰/원인가설을 나누세요. R1의 복수코드와 N1의 대안설명을 남기세요. 전체 기록/고유참여자 수를 갱신하고, 제품팀용 완성 연구메모를 작성하세요: 확인된장면, 근거표, 반대사례, 우선검증질문, 수정한해석, 알수없는것. 반대사례를 삭제해 결론을 선명하게 만들지 마세요. D1 | 분류 검토자 갑은 R4를 '검색 실패', 검토자 을은 '초대/접근 권한'으로 분류했다. 표결로 결정하지 말고 원문이 지지하는 관찰과 가설을 나눈다. D2 | R1은 '대용량 처리 성능'과 '완료 상태 안내' 두 주제에 동시에 연결할 수 있다. 측정하지 않은 지연 시간을 만들지 않는다. N1 | participant U12 | 추가 인터뷰 | v2.1 사용 안내에는 오래된 초대 화면이 나와 있었다. 새 화면에서 어떤 버튼을 누를지 몰라 관리자에게 물었다. 권한 자체가 잘못됐는지는 검사하지 않았다. D3 | 요약문 작성 시 기록 수/고유 참여자 수/독립 완료 여부/반대 사례를 각각 표시한다. 지원팀의 확인 요청은 제안일 뿐 이미 진행된 조사가 아니다.
완성 예제와 해설 2026년 10월 28일 Claude Sonnet 5.5에 실제로 입력해 받은 2번째 응답 원문입니다. 한국어 요청으로 한영 결과를 함께 받았으며, 아래 문장을 편집자가 고치지 않았습니다. 바로 위 해설과 뒤의 검수본은 편집자가 쓴 내용입니다.
응답 예제외부 AI 도구의 활용 과정을 설명하는 교재 예제입니다. 요청 조건에 따라 결과는 달라집니다.
모아노트 v2.1 연구메모 (가상 교육 사례) 기록 14개(I4·R6·O3·N1), 고유 참여자 12명(U01–U12). R2=I2, O2=I3은 중복이라 14−2=12. D1–D3는 검토 메모이며 기록·참여자가 아님. 독립 완료 확인은 U06(R3) 1명뿐. 목적 표집이라 비율은 추정하지 않음.
1. 확인된 장면
- U02 “누르면 결제가 되는 줄 알았다”, 동료 설명 뒤 완료. U11도 진행자 설명 뒤 완료.
- U04·U10은 저장 버튼에 못 가 타인·진행자의 마우스로 저장.
- U03·U07은 프로젝트가 안 보이다 초대 확인·재초대 뒤 보임.
- U05 “화면이 오래 멈춘 듯했다”, U09 재업로드. U12는 관리자에게 물음.
2. 근거표 (기록/고유 · 독립 완료 · 반대사례)
주제 기록/고유 독립 완료 반대사례 첫 팀 ‘다음’ I2,R2,O3 / 2 0 U06 R3 “혼자 끝냈다” 키보드 저장 I4,O1 / 2 0 자료에 없음 프로젝트 안 보임 I3,O2,R4 / 2 해당 없음 I3 “비슷한 이름의 다른 프로젝트는 계속 보였다”, R4 “검색이 느렸는지는 확인하지 않았다” 업로드(R1 복수코드: 성능+완료 안내) R1,R6 / 2 미기록 R1 “작은 파일에서는 못 느꼈다” 비슷한 문서명 I1,R5 / 2 날짜로 스스로 복구 I1 “대체로 찾는다” 초대 안내 N1 / 1 미기록 단일 사례 3. 분류 쟁점 (관찰/가설 분리)
R4 “동료 프로젝트가 안 보여 고객센터에 문의했다. 초대를 다시 받고 보이기 시작했다.”
- 관찰: 안 보임 → 문의 → 재초대 뒤 보임. 검색 사용·실패 여부는 원문에 없음.
- 가설 을(초대/접근): 재초대 뒤 해소된 순서가 지지하나 인과는 미확인.
- 가설 갑(검색 실패): 직접 지지하는 문장 없음. “검색이 느렸는지는 확인하지 않았다”는 속도 미확인일 뿐 실패 증거 아님. 표결 없이 둘 다 미확정, 코드는 ‘가시성(원인 미확정)’.
R1 “화면이 오래 멈춘 듯했다. 시간을 재지는 않았다”는 인상이라 지연 시간은 모름. “업로드가 끝났는지 알려 주면 좋겠다”는 완료 안내 요청. 두 코드 유지.
N1 대안 설명 초대 혼란은 권한이 아니라 낡은 안내 탓일 수 있음. 다만 “권한 자체가 잘못됐는지는 검사하지 않았다”이고 증상(버튼 선택)이 U03·U07과 달라 안 보임을 설명하지는 못함.
4. 우선 검증 질문 (제안, 진행된 조사 아님)
- 키보드 사용자가 혼자 저장까지 갈 수 있는가? Tab 순서 재현, 단축키 유무 확인.
- 요금제 문구가 결제로 읽히는가? U06과 조건 차이는?
- 안 보임의 원인은 초대 상태인가 검색인가? 지원팀에 U07 문의의 초대 상태 확인을 요청하는 안.
- 2,000행 업로드의 완료 시간·완료 표시 측정.
5. 수정한 해석
- 기록 13→14, 참여자 11→12.
- ‘원인은 초대 설정’은 U03 진술에 한정. R4는 순서만 확인.
- 업로드는 속도 단정 대신 복수코드. 초대 흐름에 낡은 안내 가설 추가.
6. 알 수 없는 것
전체 이용자 비율, U03 변경 전 검색어·녹화, R4의 검색 사용 여부, 재초대의 실제 변경 내용, 업로드 지연 시간·R6 첫 업로드 실패 여부, 키 횟수·단축키 존재, U12의 완료 여부, 파일이 매우 많을 때의 검색.
제품팀에 넘길 연구 메모를 완성하기
완성 연구 메모는 ‘이용자들이 검색과 안내에 불만’이라는 한 줄로 끝나지 않습니다. 먼저 대상이 가상 모아노트 v2.1의 14개 기록과 12명이라는 범위를 밝힙니다. 그 다음 혼자 저장하지 못한 장면, 다음 버튼을 결제로 오인한 장면, 프로젝트가 안 보였다가 재초대 뒤 보인 장면을 근거 번호와 함께 적습니다. 아래 표와 내려받는 문서는 실제 두 번째 AI 답을 확인해 편집자가 정리한 결과물입니다.
그림: 인터뷰·리뷰·관찰을 주제로 묶은 연구 메모에서 각 결론을 원자료로 다시 따라갑니다. · AI Ping 우선 검증 질문은 키보드만으로 저장까지 할 수 있는지와 첫 팀의 다음 단계가 결제로 읽히는지입니다. 두 주제가 모든 고객에게 가장 흔해서 고른 것은 아닙니다. 자료에서는 과제를 혼자 끝내지 못한 구체적인 장면이 있고, 다음 확인 절차를 정할 수 있기 때문입니다. AI가 우선순위를 제안하면 이처럼 근거의 강도와 영향 판단을 설명하게 해야 합니다. 단순 언급 횟수 순위가 곧 제품 로드맵이 되는 것은 아닙니다.
반대 사례는 각 결론 옆에 둡니다. 첫 사용 안내에는 혼자 마친 U06을, 검색 경험에는 대체로 잘 찾는 U01을 남깁니다. 성공한 사람의 경험이 실패한 장면을 지우는 것도 아니고 그 반대도 아닙니다. 서로 다른 조건을 찾을 이유가 됩니다. 예를 들어 U06이 본 화면과 U02가 본 화면이 같았는지 아직 모른다면, 그 차이를 확인할 질문으로 적습니다. AI가 실제로 비교 실험을 수행했다고 쓰지 않도록 ‘다음 조사 제안’이라는 상태도 표시합니다.
마지막에는 알 수 없는 것을 구체적으로 적습니다. 전체 이용자 비율, 실제 업로드 시간, U09 첫 업로드의 실패 여부, 단축키 존재, 재초대 때 변경된 설정은 자료에 없습니다. 이 목록은 연구가 무의미하다는 고백이 아니라 다음 판단을 위해 어떤 자료가 필요한지 알려 주는 안내입니다. AI를 통해 빠르게 요약할수록 이런 빈칸이 매끄러운 문장으로 사라지기 쉬우므로, 완성 문서의 일부로 남겨 두어야 다음 담당자가 같은 가정을 반복하지 않습니다.
연구 메모의 핵심 · 편집자 검수본 질문 근거와 현재 해석 다음 확인 키보드 저장 I4/O1 · 2명 · 도움 후 완료 v2.1 절차 재현, 혼자 저장 여부 첫 팀 안내 I2/R2/O3 · 2명 · R3는 독립 성공 화면·조건 비교, 결제 오인 여부 프로젝트 안 보임 I3/O2/R4 · 2명 · 원인 미확정 재초대의 실제 변경 내용 업로드 상태 R1/R6 · 2명 · 성능/안내 복수 분류 시간 측정과 완료 표시 안내 문서 N1 · 1명 · 오래된 화면 설명 현재 화면과 도움말 비교 새 성공 사례와 제품 정책으로 결론의 범위를 고치기
마지막 검증 자료 H1은 v2.2에서 U13이 키보드로 저장까지 혼자 마쳤다는 관찰입니다. 이 성공은 중요한 새 근거지만, 앞선 I4/O1이 다룬 v2.1의 실패가 없었다는 뜻은 아닙니다. AI에게 버전을 나누어 정리하라고 요청해야 ‘문제가 해결됐다’나 ‘이전 관찰이 틀렸다’처럼 범위를 뛰어넘는 결론을 막을 수 있습니다. 무엇이 바뀌었는지 알려 주는 변경 기록과 같은 조건의 재검증은 아직 없습니다.
H2는 보기 전용 역할인 U14가 소유자 관리 화면에 들어가지 못한 기록입니다. 함께 준 Q1은 그것이 의도된 제품 권한이라고 명시합니다. 따라서 그 제한 자체를 결함으로 세지 않습니다. 다만 기존 I3/R4는 프로젝트 목록의 보임 여부를 다루고 Q1은 관리 화면 접근을 다룹니다. 둘 다 ‘접근이 안 됨’이라고 표현할 수 있어도 대상 화면이 다르므로, 새 정책 하나로 과거의 모든 접근 문제를 정상 동작으로 바꿀 수는 없습니다.
Claude의 세 번째 응답은 버전별 저장 결과와 의도된 제한을 나누고, 기존 문장을 유지·범위 축소·보류로 정리했습니다. 독립 완료도 과제별로 U06의 첫 팀 만들기와 U13의 v2.2 저장을 따로 적었습니다. 이제 자료는 연구 기록 16개, 고유 참여자 14명입니다. Q1은 제품 정책이지 한 사람의 사용 기록이 아니므로 연구 기록에 더하지 않습니다. 새 정보의 역할을 먼저 분류해야 수치와 결론이 함께 일관되게 바뀝니다.
마지막 답에도 검수가 남습니다. ‘I4 본문에는 버전이 없고 H1이 v2.1로 분류했다’는 표현은 문서 공통 머리말을 충분히 반영하지 못했습니다. 처음 원자료 전체가 v2.1이라고 명시되어 있으므로 I4도 그 범위에 속합니다. 편집자 최종 문장에서는 ‘초기 자료의 공통 조건에 따라 v2.1’이라고 적습니다. AI가 개별 인용을 잘 추적해도 문서 전체의 조건을 놓칠 수 있으므로, 마지막 검수는 문장뿐 아니라 머리말과 자료 묶음의 범위까지 포함합니다.
분류를 다시 확인할 새 자료 기록 추가 조건 바꿀 수 없는 것 H1 / U13 v2.2 키보드 독립 저장 성공 v2.1 실패가 없었다는 주장 H2 / U14 보기 전용 역할의 관리 화면 접근 제한 기존 모든 프로젝트 문제의 원인 Q1 의도된 접근 제한을 설명한 정책 새 참여자나 새 사용 관찰 아님 프롬프트 예시 이 홀드아웃자료를 기존분석과 대조하세요. 버전별로 키보드 저장 결론을 나누고 의도된권한제한과 확인된결함을 분리하세요. 이전문장 중 유지/범위축소/보류할 것을 근거ID와 함께 적고 다음검증질문을 제시하세요. 성공한새사용자 한명을 이유로 과거관찰을 지우거나 기존모든접근문제를 정상권한이라고 단정하지 마세요. H1 | participant U13 | 새 관찰 | v2.2에서는 키보드로 저장까지 혼자 완료했다. 기존 I4/O1은 v2.1 기록이다. v2.1의 결함이 없었다는 증거로 소급하지 않는다. H2 | participant U14 | 새 인터뷰 | 보기 전용 역할이라 소유자 전용 관리 화면에 들어갈 수 없었다. 제품 정책 Q1은 이 제한이 의도된 권한이라고 명시한다. 기존 I3/R4의 초대 문제가 같은 원인인지 아직 모른다. Q1 | 제품 정책 | 보기 전용 이용자는 소유자 전용 관리 화면에 접근할 수 없다. 이 제한 자체를 결함으로 분류하지 않는다.
완성 예제와 해설 2026년 10월 28일 Claude Sonnet 5.5에 실제로 입력해 받은 3번째 응답 원문입니다. 한국어 요청으로 한영 결과를 함께 받았으며, 아래 문장을 편집자가 고치지 않았습니다. 바로 위 해설과 뒤의 검수본은 편집자가 쓴 내용입니다.
응답 예제외부 AI 도구의 활용 과정을 설명하는 교재 예제입니다. 요청 조건에 따라 결과는 달라집니다.
모아노트 연구메모 갱신 (홀드아웃 대조, 가상 교육 사례) 기록 16개(I4·R6·O3·N1·H2), 고유 참여자 14명(U01–U14). R2=I2, O2=I3은 중복이라 16−2=14. Q1은 정책 문서라 기록·참여자가 아님. 독립 완료는 과제별로 U06(첫 팀, R3), U13(v2.2 저장, H1). 목적 표집이라 비율은 추정하지 않음.
1. 버전별 키보드 저장
버전 기록/고유 독립 완료 결론 한계 v2.1 I4,O1 / 2 0 “저장 버튼으로 갈 때 순서가 화면 밖으로 넘어갔다”, “Tab 이동이 저장 버튼을 지나쳤다”. 혼자 저장 실패를 관찰 원인은 가설. I4 본문엔 버전이 없고 H1이 v2.1로 분류 v2.2 H1 / 1 1(U13) “키보드로 저장까지 혼자 완료했다” 1명. 변경 내용·U13 조건 미상 U13은 v2.2의 성공 한 건이다. v2.1 관찰을 지우지 않고, 결함이 없었다고 소급하지 않으며, v2.2에서 해결됐다고 단정하지도 않는다.
2. 의도된 제한과 문제 분리
- 의도된 제한: U14는 보기 전용 역할이라 소유자 전용 관리 화면에 못 들어감(H2). Q1이 의도된 권한이라 명시하므로 결함 아님.
- 관찰로 확인된 문제: v2.1 키보드 저장 실패(I4,O1). 재현이 없어 원인 확정 결함은 아직 없음.
- 분류 미정: 프로젝트 안 보임(I3,O2,R4). Q1은 관리 화면 접근을 다루며 목록 가시성은 다루지 않음. U03은 초대 확인 뒤 보였으나 그 전 상태가 오류인지 정상 제한인지 모름. H2도 “같은 원인인지 아직 모른다”. 접근 문제 전체를 정상 권한으로 보지 않음.
3. 이전 문장 처리
- 유지: 첫 팀 ‘다음’ 혼동 2명과 반대 U06(I2,R2,O3,R3), 업로드 복수코드(R1,R6), 비슷한 문서명(I1,R5), R4 ‘가시성(원인 미확정)’(R4).
- 범위축소: “독립 완료는 U06뿐”→과제별 U06·U13(R3,H1). 키보드 저장 문제→v2.1 한정(I4,O1). “원인은 초대 설정”→U03 진술 한정(I3,O2).
- 보류: Tab 순서 원인(I4,O1), v2.2 개선 여부(H1), 낡은 안내 가설(N1), U14와 I3/R4의 동일 원인 여부(H2,I3,R4), 검색 실패 가설(R4).
4. 다음 검증 질문 (제안, 미실시)
- v2.1→v2.2에서 저장 이동 순서가 바뀌었나? 변경 기록 확인.
- U04·U10과 같은 절차(본문 입력 후 Tab)로 v2.2 키보드 사용자 여러 명이 혼자 저장할 수 있나?
- U03·U07의 초대 상태 확인을 지원팀에 요청하는 안. 관리 화면 제한(Q1)과 목록 가시성 규칙을 구분.
- U14는 제한 이유를 화면에서 이해했나? (미확인)
5. 알 수 없는 것
전체 이용자 비율, v2.2 변경 내용, U13의 입력 조건, U03 변경 전 검색어·녹화, 재초대 변경 내용, 업로드 지연 시간, U12·U14의 완료 여부.
3 / 4
확인과 해설
AI에 어떤 요청을 할지 생각한 뒤 해설을 읽으세요. 답안 작성·제출·외부 AI 실행은 선택입니다.
정답을 맞혀야 다음 수업으로 가는 시험이 아닙니다. 해설을 읽고 이해하는 데 사용하세요.
Q1I2와 R2가 같은 U02의 같은 사건입니다. AI가 13명 조사라고 썼다면 어떻게 고칠까요?
내 생각 적기 (선택)
작성 내용은 전송되지 않으며, 페이지를 떠나거나 새로고침하면 사라져요. 필요한 내용은 복사해 두세요.
답과 해설 보기
기록 13개와 고유 참여자 11명을 구분하도록 요청합니다. I2/R2뿐 아니라 I3/O2도 같은 U03이므로 두 중복을 사람 수에서 빼야 합니다. 모두 연습용 가상 자료이며 이 사람 수로 전체 고객 비율을 추정하지 않습니다.
직접 비교한 표시이며 자동 채점은 아니에요.
Q2R4에서 재초대 뒤 프로젝트가 보였습니다. AI의 “원인은 초대 권한”이라는 문장을 어떻게 고칠까요?
내 생각 적기 (선택)
작성 내용은 전송되지 않으며, 페이지를 떠나거나 새로고침하면 사라져요. 필요한 내용은 복사해 두세요.
답과 해설 보기
‘재초대 뒤 보였으며 실제 원인은 확인 중’으로 좁힙니다. 원문은 사건의 순서만 제공하고 재초대 때 무엇이 바뀌었는지 기록하지 않았습니다. 검색 결함도 단정할 수 없으므로 초대 상태와 변경 내용을 확인할 질문으로 남깁니다.
직접 비교한 표시이며 자동 채점은 아니에요.
Q3O1은 진행자가 마우스를 건넨 뒤 저장했습니다. AI가 독립 완료로 세면 무엇이 사라질까요?
내 생각 적기 (선택)
작성 내용은 전송되지 않으며, 페이지를 떠나거나 새로고침하면 사라져요. 필요한 내용은 복사해 두세요.
답과 해설 보기
키보드만으로 저장하지 못한 핵심 장면과 도움 조건이 사라집니다. 저장 결과와 독립 수행 여부를 따로 적어야 합니다. v2.1의 이 연습용 관찰을 성공 사례로 바꾸지 않습니다.
직접 비교한 표시이며 자동 채점은 아니에요.
Q4v2.2의 H1에서 한 명이 키보드 저장에 성공했고 Q1은 일부 권한 제한이 정상이라고 합니다. 이전 모든 문제를 지워도 될까요?
내 생각 적기 (선택)
작성 내용은 전송되지 않으며, 페이지를 떠나거나 새로고침하면 사라져요. 필요한 내용은 복사해 두세요.
답과 해설 보기
아닙니다. 연습용 새 관찰 한 건은 v2.1의 I4/O1을 없애지 않으므로 버전별로 나눕니다. Q1은 소유자 관리 화면 정책이어서 프로젝트 목록의 I3/R4까지 설명하지 않습니다. 유지할 관찰과 아직 확인할 원인을 구분합니다.
직접 비교한 표시이며 자동 채점은 아니에요.
자주 하는 실수
- 인터뷰와 리뷰의 문서 수를 고유 참여자 수로 바꾸기
- 시간상 뒤에 일어난 변화를 원인으로 확정하기
- 도움받은 완료를 독립 성공으로 줄여 쓰기
- 새 버전이나 다른 화면의 근거로 과거 모든 문제를 지우기
나의 학습 기록
완료 표시는 선택이에요. 수업을 마쳤다고 판단되면 직접 표시하세요. 표시하지 않아도 다음 수업으로 갈 수 있어요.
완료 기록은 이 브라우저에 저장돼요.
4 / 4
내 업무에 적용하기
새 자료가 주어지면 활용 순서와 확인 기준을 어떻게 바꿀지 생각해 보세요. 외부 도구를 직접 써 보는 것은 선택입니다.
직접 해 보기: 근거 한 줄에서 분석을 다시 시작하기
처음에는 R4 한 줄만 골라 보세요. ‘동료 프로젝트가 안 보여 문의했고 재초대 뒤 보였다’고 적혀 있습니다. 이 문장 옆에 관찰과 가설 두 칸을 만듭니다. 관찰에는 사건 순서를, 가설에는 초대 상태나 권한을 확인해야 한다는 설명을 넣습니다. ‘검색이 고장 났다’는 확정 문장을 남기려면 어떤 추가 자료가 있어야 하는지도 적습니다. AI를 실행하지 않아도 이 차이를 이해하면 첫 요청의 근거표를 읽을 준비가 된 것입니다.
직접 도구를 쓰고 싶다면 13개 원자료가 포함된 첫 요청을 통째로 복사합니다. 답에서 13과 11을 구분했는지, R2를 새로운 사람으로 세지 않았는지, 도움받은 저장을 독립 성공으로 바꾸지 않았는지 먼저 확인하세요. 다음 요청에는 분류 의견 차이와 N1을 넣고, 마지막에는 H1/H2/Q1을 넣습니다. 교재처럼 두 언어 결과를 한 번에 만들 필요는 없습니다. 자신이 확인할 수 있는 언어로 답하게 하고 원문 연결을 유지하는 것이 우선입니다.
결과가 교재와 다른 이름표를 쓰더라도 곧바로 틀렸다고 판단하지 않습니다. ‘프로젝트 가시성’과 ‘프로젝트가 안 보임’은 같은 관찰을 가리킬 수 있습니다. 반면 ‘검색 결함’은 원인을 더 강하게 주장합니다. 분류 이름보다 그 이름이 암시하는 사실과 근거가 맞는지를 살피세요. 새로운 이름표를 추가할 때는 무엇을 포함하고 제외하는지 한 문장씩 적게 하면 다른 사람이 같은 자료를 읽을 때 의견 차이를 설명하기 쉬워집니다.
마지막 결과물에는 핵심 발견 하나, 그 근거 번호, 반대 사례 하나, 다음 확인 질문 하나를 남깁니다. 예를 들어 v2.1 키보드 저장의 도움 필요를 I4/O1로 설명하고, v2.2의 H1 성공을 따로 적으며, 같은 절차의 재검증을 제안합니다. AI가 만든 요약을 실제 사용자 전체에 대한 결론으로 넓히지 않습니다. 자료가 바뀌면 기존 해석 중 무엇을 유지하고 좁히고 보류할지 말할 수 있는 상태가 이 수업의 완성입니다.
직접 적어 보기 (선택)
요청문이나 이해한 내용을 기록하고 싶을 때만 열어 사용하세요. 이 입력란은 AI에 연결되지 않은 메모장입니다.
작성 내용은 전송되지 않으며, 페이지를 떠나거나 새로고침하면 사라져요. 필요한 내용은 복사해 두세요.
참고 자료
- 처음 입력한 가상 자료 — AI Ping
- 두 번째 대화의 추가 자료 — AI Ping
- 새 조건의 검증 자료 — AI Ping
- 편집자가 검수한 완성 산출물 — AI Ping
- Claude 실제 응답 1 원문 — AI Ping
- Claude 실제 응답 2 원문 — AI Ping
- Claude 실제 응답 3 원문 — AI Ping
- Prompting best practices — Anthropic
- Reduce hallucinations — Anthropic