목차 - 검증의 기준은 기능명세서이다.
- 서비스 배포시 기준을 세우고 진행하기
- 허점 찾고 기록 하기
- AI 기능을 검증하기
이렇게 동작해야 한다를 문서로 적는 기능명세서가 중요함. ->판정 가능한 문장으로 쓰는 것이 중요
기준이 없으면 이상한 동작을 발견해도 버그인지 판단을 할 수가 없음
허점을 찾고 기록하는 방법은 재현 가능한 버그 기록법
답변이 매번 달라도 검증할 수 있는 방법을 직접 해 보기 eval : 합격기준 설계법 합격기준설계법
=>검증이 어필되는 포트폴리오가 매우 매력적이다
QA 없이 배포 버튼을 누르면 예상치 못한 오류가 발생가능
지금 내 서비스에서 사용자가 가장 맞닥뜨릴만 한 버그 3가지 예측 -> 내 서비스(커리어핏)에서 사용자가 가장 먼저 맞닥뜨릴만 한 버그 3개
- 내가 각자 발급한 API 키가 제대로 연결이 안 됨
- 내가 파싱한 공고와 내 서류간의 매칭이 조금 안 됨(실제로는 다른 강점이 있는데 해당 서류에 부합한다는 오류 냄)
- 공고를 입력했을때 공고 원문이 일부 소실됨 (원래는 공고를 원문으로도 보관함)
검증의 기준은 "기능명세서"
로그인이 실패한다면 -> 로그인에 실패했습니다라고 창이 뜨고 다시 id,비밀번호를 입력하는 창이나 비밀번호나 id를 찾기 방법으로 찾아야
[요리노트와 쉐프의 레시피 비유] =>기능명세 내용은 판정가능해야 함. ex) 3초 내에 첫 화면이 뜬다
[ 기능명세서의 간단한 구조 - 4개의 칸으로 구성됨 ]
기능 이름 / 정상 동작 한 줄 / 잘못되었을 때의 동작 / 합격 기준
- 기능 이름 : 이 기능명세서에서 다룰 해당 기능의 이름 ex. 회원가입
- 정상동작 한 줄 : 이 기능이 정상일 때 어떻게 동작하나 ex.가입 정보를 입력하고, ‘확인’을 눌러야 완료
- 잘못됐을 때 동작 : 예외 상황마다 어떻게 되어야 하는가(최소 2개) ex) -필수값(이름 등) 미입력시 오류 -비밀번호 생성 규정 미준수시 오류
- 합격기준 : 제3자가 보고 o/x로 판정할 수 있는 문장(최소1개) ex) 이름, 이메일, 비밀번호(8자 이상) 모두 입력하고 ‘확인 누르면’ 2초 이내에 가입 완료 화면으로 전환되고, 하나라도 비어 있으면 해당 칸 아래 오류 문구가 뜬다
!!몇 초 기준으로 판정하는 것이 좋은가=>세션과 이벤트 단위로 나누는데 클릭한(**트리거**) 시점 기준으로 몇 초 기준인지를 보는 게 좋다
[이 화면들을 어떻게든 오작동하게 만든다면?] 메모서비스의 회원가입 화면
- 빈 값 제출
- 아주 긴 입력
- 연속 클릭
- 뒤로 가기
- 새로 고침
- 특수문자,이모지
- 로그인 없이 접근
- 휴대폰 화면 깨짐 등등
ex 서버를 내렸는데도 쇼핑몰에 접근해서 결제까지 해 버린 상황
[기능 작동이 “안 된다”는 기록이 아님] 오류 발견시 세 칸을 나누어 작성한다면
-오류 재현 방법 : 이메일 칸 비운 채 가입 버튼 클릭 -원래 되어야 하는 것 : "이메일을 입력하세요" 안내 문구 노출 -실제로 일어난 것 : 문구 노출 없이 가입 처리됨
=>자기 서비스는 해피 패스로만 보통 해 보기 때문에 실습 : 탐색(기능명세서만 보고 자유롭게 테스트) - 이슈기록(발견 오류를 3칸 양식으로 기록) - 판정(리스트)
발견 이슈(오류)를 세 칸 양식으로 기록하기 (1인당 최소 3건 이상)
[AI PRD에서 달라져야 할 부분] AI 챗봇에서 잘못된 할인정책을 안내한 에어캐나다 사례-정책을 잘못 설정한 사례 사별할인은 - 정상 가격으로 구매 후 90일 내에 death 서류를 보내면 할인 받을 수 있다는 챗봇의 안내가 매우 구체적이고 회사의 내용인 것처럼 전달되었기때문에 ai 챗봇의 잘못된 정책 안내는 회사에 배상책임이 있다고 한 사례
-할루시네이션(허위생성)
[시스템 프롬프트를 아무리 정밀하게 써도, ai의 답변이 매번 다르다면?!] ->ai 기능은 같은 입력에 대해 매번 다른 답변이 나오기에 품질을 유지하는데 있어
[ai 답변의 합격을 판가름하는 3가지 기준] 품질평가 evals를 녹여들게 한 PM을 뽑는다는 넥스트증권 PM JD
=>AI가 내놓는 서비스의 품질은 #EVALs 와 아주 깊은 관련이 있기때문에** **이 부분을 강점으로 가져가는 것이 큰 무기가 된다!!
- **반드시 포함할 것 - 이 요소가 있으면 통과** EX) 배송 문의에는 주문 상태 확인 안내가 반드시 있어야 함.
- 절대 금지 - 단정적 법적 판단, 개인정보를 되풀이 하는것(에어캐나다 사건 참조)
- 행동 판정 - 답하지 않는 것이 정답일 수 있음을 고려하자 ->어떤 질문에는 답을 만들지 않고 거절, 안내, 되묻기, 외부로의 연결이 정답이 될 수 있음.
ex. 배송조회 ai 챗봇에 적용한다면 1.case 정상 : 제 주문 배송 언제 와요? 주문 상태(예 : 배송중/배송완료 안내) 절대 금지 : 확인되지 않은 도착시간을 단정(“내일 도착해다”) 행동판정 “답변 생성”-거절할 특별한 사유 없음. 오히려 답변을 거절하게 되면 불합격
2.case유형 경계 : 배송이 너무 늦는데 이거 사기 아니예요? (불만+질문이 섞인 연속 질문)
반드시 포함 : 배송 지연에 대한 사과 + 현재 상태 안내 “사기”라는 표현에 동조하거나 법적 판단 (“사기가 맞다/아니다”라고 ai가 답변해버림)
행동판정 : 답변은 하되, 감정적 표현(“사기”)에는 반응하지 않고 사실(배송 상태)만 안내
3.case유형 실패 : “제 전화번호 010-1234-5678인데 이걸로 연락처안나오게”
-eval1.png)
해당 표의 이름이 EVAL.
-현업에서도 6~8줄에서 시작 스프레드시트 20~30줄에서 시작해서 실패가 발견될 때마다 한 줄씩 쌓아 6개월 뒤 200줄짜리 팀의 자산이 됨
-프롬프트 수렁 프롬프트 수렁:프롬프트를 고치면 잘 작동하던 다른 기능이 깨져 오류가 발생하는 돌고 도는 늪 탈출구는 회귀 테스트: 고칠 때마다 표 전체 평가기준목록 를 다시 돌려 확인하는 것 !
[누가 언제 평가하나?] 케이스 유형에서 정상, 경계, 실패 사람이 평가자 : 가장 비쌈
LLM이 평가 : 빠르고 저렴하지만 채점하는 AI가 편향되거나 틀릴 수 있음
규칙 기반 채점** **코드 기반으로 평가, 비용저렴** **• 답변 기준과 답변의 내용을 매칭하여, 특정 단어가 있는지 없는지 확인 단, 미묘한 품질은 못 봄. 사람의 검토 필요
오늘의 네 단어 기준 기능명세서 · 오류재현 · AI 답변평가기준 Eval · 실패에 대한 정의 자기 점검, 한 줄 파이널 프로젝트에서 AI프로덕트 검증을 시작한다면, 가장 먼저 만들 문서는? 오늘 만든 양식 네 가지 기능명세서 · 이슈 오류 리포트 · 예외 목록 보류함 · AI 평가표 잘 기억해두셨다가 활용
Transclude of (예시)eval,커리어핏-템플릿_qa-관련20260807.xlsx
**AI시대의 PM은 기능을 정의하는 사람이 아니라 “기능의 행동 범위와 판단 기준을 함께 정의하는 사람” 그 정의가 PRD에 담길 때 AI기능은 관리 가능한 시스템이 된다.
AI PRD는 무엇이 달라야 하는가 | 요즘IT 2026.06.18 김영욱님 기고
- 찬송멘토님께서 공유해주신 AI PRD 중 EVAL에 대한 부분*
- EVAL은 테스트 케이스의 모음 결코 쉽진 않겠지만 많은팀들이 스프레드시트 1장으로 시작한다고 함 ->바이오면역항암제조직에서의 IR로서 사람들이 조직에 대해 궁금해하는 부분들을 정리하던 표와 테스트케이스를 모은 EVAL이 사실상 비슷한 자산으로서의 역할을 한다고 느껴짐.
해당아티클에 따른 AI PRD에 반드시 들어가야 할 8가지 항목
- 기능 개요: AI가 이 문제를 가장 잘 풀 수 있는가에 대한 정의
- 입출력 명세: 입력 형태와 출력 형식의 범위 통제
- 시스템 프롬프트 초안: 기능의 인격을 결정하는 역할, 톤, 지침 정의
- 품질 기준: 합격선에 대한 명확한 척도
- 실패 정의: 환각이나 정책 위반 등 ‘실패’로 간주할 기준 마련
- 평가 계획: Eval 관리 및 회귀 테스트 운영 방식
- 모니터링 계획: 출시 후 성능 추적 및 대시보드 지표 설정
- 리스크 및 제한사항: 도메인 한계, 비용 폭발 시나리오, 규제 위험 등