PM과 디자이너를 위한 제품 결정 기록

목표: 다음 동료가 무엇을 바꾸려는지, 이유가 무엇인지, 어떤 검증이 남았는지 알 수 있는 결정 기록을 만듭니다.

준비: 첫 작업공간 안내를 완료하고 편집자 또는 소유자 권한이 있는 작업공간을 선택합니다. 예시는 제품 연습이라는 주제를 사용하며, 새 작업공간 생성은 필수가 아닙니다. AI 연결 없이도 모든 기본 단계를 진행할 수 있습니다.

연습 데이터

아래 내용은 따라 해 볼 수 있도록 만든 예시입니다. 실제 연구 결과, 고객 인터뷰, 사업 정책, 학생 기록이 아닙니다. 실제 자료로 바꿀 때는 사용 권한과 공개 범위를 확인하세요.

결정의 배경이 빠진 상황에서 시작하기

디자이너가 첫 단계 링크를 왜 선택했는지 묻습니다. 인터뷰 메모는 다른 파일에, 테스트 아이디어는 회의록에 있고 요구사항에는 “온보딩 개선”만 적혀 있습니다. 새 동료는 고객 요청인지, 가설인지, 승인된 결정인지 알기 어렵습니다.

이 안내에서는 첫 단계 안내를 더 쉽게 찾게 하는 제안의 근거를 연결합니다. 고객 관찰, 실험 계획, 결정 이유를 함께 기록하며 같은 구조를 제품 요구사항 문서(PRD), 디자인 검토, 다음 개선에서도 활용할 수 있습니다.

근거·제안·결정을 구분해 보관하기

자료	보관할 곳	기록하고 확인할 내용
사용 가능한 인터뷰 메모, 조사 결과, 시안 파일	Library	날짜, 조사 또는 디자인 버전, 출처. 업로드 전에 개인정보 제거
관찰 내용과 해석	Context의 인터뷰 노트	참가자가 실제로 한 행동이나 발언, 별도로 적은 가설과 표본의 한계
검증 계획과 실제 결과	Context의 실험 기록	방법, 측정 항목, 진행 상태, 사람이 실행한 뒤 기록하는 관찰 결과
요구사항과 결정 이유	Context의 출시 결정	사용자 문제, 대안, 범위, 담당자, 상태, 근거 링크

예시의 “제안”, “아직 실행하지 않음”, “승인됨”은 팀이 내용에 직접 쓰고 관리하는 표현입니다. 제품 개발의 진행 상태가 자동으로 바뀌는 기능은 아닙니다.

이 예시에서 연결할 페이지

출시 결정에서 위키링크로 인터뷰 노트와 실험 기록을 엽니다. 화살표는 직접 만들 페이지의 연결을 설명합니다. 자동 업무 실행이나 제품 화면을 뜻하지 않습니다.

연습 페이지 세 개 만들기

1. 컨텍스트 → 새 컨텍스트 페이지를 엽니다. 아래의 첫 번째와 두 번째 복사 예시를 각각 사용하고, 페이지 제목은 제목란에 Markdown은 본문에 넣습니다.
2. 각 페이지에서 초안 저장 후 저장 상태를 확인한 다음 게시합니다. 작업공간 독자를 위한 게시이며 웹 게시는 별도입니다.
3. 세 번째 예시로 출시 결정을 마지막에 만듭니다. [[페이지 제목]]은 해당 작업공간의 기존 페이지 제목과 일치해야 합니다.
4. 두 링크를 열어 확인합니다. 연결되지 않으면 제목과 작업공간을 확인하고 편집기의 위키링크 메뉴에서 기존 대상을 선택하세요.

Markdown은 제목과 목록 등을 표현하는 일반 텍스트입니다. 이 예시는 소프트웨어 코드가 아닌 노트입니다. 편집 기능은 Context 페이지 작성, 이미지와 링크를 참고하세요.

인터뷰에서 디자인 전달까지 이어 쓰기

인터뷰 후: 실제 일어난 일부터 기록하기

평소 사용하는 조사 도구에서 익명화한 자료를 준비한 뒤 Library → 업로드를 진행합니다. P01 같은 참가자 표시를 사용하고 이름, 연락처, 민감한 고객 정보를 제거하세요. 상태와 변환된 내용을 확인합니다. 스크린샷에서 텍스트가 자동 인식된다고 보장하지 않으므로 중요한 관찰은 대조한 텍스트 메모로 남깁니다.

인터뷰 노트 → 편집을 열어 “P01이 안내를 찾기 전에 상단 메뉴를 살펴보았다”처럼 관찰부터 씁니다. “더 뚜렷한 진입점이 도움이 될 수 있다”는 해석에 적고 고객이 요구한 것처럼 인용하지 않습니다. 인터뷰 날짜와 출처 위치를 남기고 초안 저장합니다. 근거를 확인한 뒤 동료가 읽을 버전을 게시합니다.

기획할 때: 요구사항을 확인 가능한 형태로 쓰기

출시 결정에 다음과 같은 작은 표를 추가합니다.

항목	연습 예시
사용자 문제	처음 사용하는 사람이 첫 단계 안내를 빨리 찾지 못함
제안하는 요구사항	기존 안내로 들어가는 눈에 보이는 경로 제공
확인할 관찰 결과	진행자의 도움 없이 사용자가 의도한 안내를 여는지 확인
제외할 범위	온보딩 전체를 다시 만들기
불확실한 점	문구와 위치는 아직 테스트하지 않음

기존 위키링크로 요구사항을 인터뷰 노트, 실험 기록과 연결합니다. 실험 페이지에는 결과보다 계획과 방법을 먼저 씁니다. 실제 제품이나 조사 환경에서 사람이 테스트하기 전까지 아직 실행하지 않음을 유지합니다.

디자인 검토: 선택한 이유까지 전달하기

권한이 있는 시안 이미지를 Context의 이미지 기능으로 추가하거나, 원본 문서를 Library에 보관합니다. 디자인 버전과 그림이 설명하는 부분을 적으세요. 검토자에게 요구사항과 시안을 비교하고 근거 링크 두 개를 열어 보도록 요청합니다.

다른 대안과 제외한 이유도 남깁니다. “기존 메뉴 유지”는 화면 변경을 줄일 수 있지만 진입점을 찾기 어렵다는 질문은 남겨 놓을 수 있습니다. 결정 담당자가 이유를 확인하고 관련 Context 버전을 게시한 뒤 구현 담당자에게 작업공간 링크를 전달합니다. 노트의 게시는 제품 배포나 실험 실행을 시작하지 않습니다.

복사할 페이지 내용

아래 순서대로 페이지를 만듭니다. 제목란에는 각 소제목의 제목을 입력하고 본문에는 그 아래 블록을 붙여 넣습니다.

인터뷰 노트

# 인터뷰 노트

## 연습 인터뷰 A
가상의 테스트 사용자가 첫 단계 안내를 찾지 못했습니다.

## 관찰
사용자는 눈에 잘 띄는 시작 버튼을 찾았습니다.

## 해석
더 명확한 진입 지점이 도움이 될 수 있습니다.

## 한계
가상의 예시 한 건이며 실제 고객 근거가 아닙니다.

실험 기록

# 실험 기록

## 제안한 실험
소규모 테스트 사용자에게 여기서 시작 링크를 보여줍니다.

## 확인할 내용
- 도움 없이 안내를 열 수 있는가?
- 혼동을 일으키는 표현은 무엇인가?

## 결과
아직 진행하지 않았습니다.

## 결정 기준
실제 페이지를 바꾸기 전에 관찰 결과를 검토합니다.

출시 결정

# 출시 결정

## 결정
첫 단계에 들어가는 경로를 더 명확하게 준비합니다.

## 이유
[[인터뷰 노트]]에서 안내를 찾기 어려울 가능성을 발견했습니다.

## 검증
[[실험 기록]]

## 범위
제안 문구를 먼저 작성하고 검토합니다.

## 담당
제품 팀

## 상태
제안 단계이며 실제 서비스 변경은 승인되지 않았습니다.

제안을 검토하고 변경의 이유 남기기

요구사항 담당자와 디자인 확인 담당자를 정합니다. 소유자는 멤버십을 관리하고, 편집자는 수정과 게시를 하며, 뷰어는 게시된 내용을 읽습니다. 브라우저의 초안 저장 자체는 검토 제출이 아닙니다. 명시적인 제안이 **리뷰 큐(Review queue)**에 있다면 권한이 있는 사람이 변경 내용 보기, 이유를 적은 변경 요청(Request changes), 해당 Context 게시 제안의 승인을 사용할 수 있습니다. 최종 게시 상태도 확인하세요.

테스트를 실행한 뒤 실험 기록에 날짜, 방법, 실제 관찰, 한계를 적습니다. 기존에 확인하기로 한 관찰 결과와 비교한 다음 출시 결정을 갱신합니다. 요구사항이 바뀌면 날짜와 이유를 남기고 연결된 결정 근거를 다시 검토하세요. 이전 이유를 설명 없이 덮어쓰지 않습니다.

정정된 자료 파일에는 새 버전 업로드를 사용하고 Context의 **히스토리(History)**에서 이전 문구와 현재 문구를 비교합니다. 나중에 합류한 동료가 새 근거 때문인지, 제약 조건이 바뀌었는지, 잘못된 기록을 고쳤는지 이해할 수 있어야 합니다.

결과 확인

결정이 인터뷰 노트와 아직 실행하지 않은 실험에 연결됩니다. 나중에 읽는 사람도 제안과 승인된 출시 변경을 구분할 수 있습니다.

Search에서 출시 결정을 검색해 다시 찾을 수 있는지도 확인하세요. 저장 상태만 보고 끝내지 말고 게시된 내용과 두 링크가 실제로 열리는지 확인합니다.

인터뷰에 참석하지 않은 구현 담당자에게 다음을 확인해 달라고 요청합니다.

• 출시 결정에서 사용자 문제, 요구사항, 담당자, 현재 결정 상태를 찾을 수 있습니다.
• 한 건의 가상 관찰, 테스트하지 않은 가설, 앞으로 기록할 결과를 구분할 수 있습니다.
• 근거 페이지를 열고 제외한 대안을 설명하며, 어떤 결과가 나오면 결정을 바꿀지 알 수 있습니다.

자주 생기는 실수

실수	더 나은 방법
한 인터뷰를 “모든 고객이 원한다”로 바꾸기	관찰 옆에 참가자 수와 한계 기록
공유 노트에 고객 개인정보 붙여 넣기	업로드 전에 익명화하고 작업공간 접근 범위 확인
요구사항이나 버전 없이 시안만 보여 주기	문제, 기대 동작, 디자인 버전, 근거 링크 추가
게시된 제안을 출시된 변경으로 생각하기	결정 상태를 명시하고 실제 제공 여부는 평소 제품 도구에서 확인

다음 기획 회의에서는 출시 결정을 검색해 근거와 남은 질문에서 시작하세요. 이전 결론을 그대로 복사하기보다 지금의 제약 조건에서도 그 이유가 유효한지 확인합니다.

관련 안내: Library 사용, 검토와 변경 이력, 공유 범위.

선택: 연결한 AI에 도움 요청

MCP 연결을 완료하고 필요한 작업공간과 읽기 권한만 허용합니다. 실제 접근 범위는 자격증명과 작업공간 권한이 제한합니다. 외부 AI 도구가 읽은 자료는 해당 제공자에게 전달될 수 있으므로 허용된 비민감 연습 자료를 사용하세요.

선택한 작업공간의 출시 결정, 인터뷰 노트, 실험 기록을 읽어 주세요. 관찰 근거, 가설, 제안한 요구사항, 확인할 관찰 결과, 제외한 대안, 남은 질문을 구분한 디자인 검토 메모를 만드세요. 관련 페이지나 구절을 근거로 표시하세요. 기록된 결과가 없으면 실험은 아직 실행하지 않았다고 표시하고 고객 인용을 만들어 내거나 출시를 승인하지 마세요. 페이지 수정, 배포, 고객 연락 없이 이 대화에만 답해 주세요.

관찰 내용은 익명화한 원자료, 요구사항은 현재 결정, 결과는 실제 테스트 기록과 대조합니다. 의견 차이는 결정 담당자가 확인하게 하세요. 검증한 제안만 초안에 옮깁니다. AI의 검토는 디자인 승인이나 실제 사용자 테스트를 대신하지 않습니다.

Chats에서 dtxWiki의 도구 실행 기록을 확인할 수 있습니다. 기록은 AI의 전체 대화나 외부 서비스의 모든 행동을 담는 것이 아닙니다.

버전 근거: Library 조작, 페이지 편집과 게시, 리뷰 결정.