Projects는 지침과 지식을 한 번 설정해 두고 여러 대화에서 같은 바탕을 쓰는 자리입니다. 무엇을 지침에 넣고 무엇을 지식에 넣을지 헷갈리면 설정이 지저분해집니다. 이 수업에서는 둘의 구분과 설정을 키워 나가는 순서를 다룹니다.
지침과 지식의 구분
Projects에는 성격이 다른 두 가지를 넣습니다.
지침은 "어떻게 행동하라"입니다. 문체 규칙, 출력 형식, 지켜야 할 절차, 하지 말아야 할 것이 여기에 들어갑니다.
지식은 "무엇을 참고하라"입니다. 제품 자료, 사내 규정, 용어집, 과거 사례 같은 것입니다.
구분이 헷갈릴 때는 이렇게 묻습니다. 이것이 매번 지켜야 할 규칙인가, 아니면 필요할 때 찾아볼 자료인가.
| 내용 | 어디에 |
|---|---|
| "모든 답변은 존댓말로" | 지침 |
| "우리 제품 가격표" | 지식 |
| "숫자를 인용할 때는 출처를 함께" | 지침 |
| "작년 고객 문의 사례 모음" | 지식 |
| "고객 이름은 절대 쓰지 말 것" | 지침 |
잘못 넣으면 문제가 생깁니다. 규칙을 지식에 넣으면 참고 자료 취급이 되어 매번 지켜지지 않을 수 있습니다. 반대로 긴 자료를 지침에 넣으면 지침이 길어져 정작 중요한 규칙이 묻힙니다.
지침은 짧을수록 잘 지켜집니다. 다섯 줄이 스무 줄보다 낫습니다.
설정을 키워 나가는 순서
처음부터 완벽한 설정을 만들려 하면 무엇이 필요한지도 모른 채 추측으로 채우게 됩니다. 쓰면서 키우는 편이 낫습니다.
- 최소한만 넣고 시작한다 — 업무 성격 한 줄, 출력 형식 한 줄
- 실제로 작업한다
- 매번 손으로 고치게 되는 것을 찾는다
- 그것을 지침에 한 줄 추가한다
- 2~4를 반복한다
3번이 핵심입니다. 매번 같은 부분을 고치고 있다면 그것은 지침에 넣을 신호입니다. 반대로 한 번만 고친 것은 그 작업에만 해당하는 것이므로 지침에 넣을 필요가 없습니다.
이 방식의 이점은 지침의 모든 줄에 근거가 있다는 것입니다. 추측으로 넣은 규칙은 나중에 지워야 할지 판단하기 어렵지만, "이것 때문에 넣었다"가 분명하면 상황이 바뀌었을 때 판단할 수 있습니다.
그래서 지침에 줄을 추가할 때 왜 넣었는지 짧게 남겨 두는 것을 권합니다.
지식으로 넣기 전에
Projects의 지식은 그 안의 모든 대화에 영향을 줍니다. 그래서 넣기 전에 확인하는 편이 나중에 찾아다니는 것보다 훨씬 쌉니다.
넣기 전 확인할 것은 세 가지입니다.
- 최신인가. 작년 가격표를 넣으면 이후 모든 결과가 작년 가격을 씁니다
- 정확한가. 초안 상태의 문서를 넣으면 확정되지 않은 내용이 근거로 쓰입니다
- 넣어도 되는 자료인가. 민감한 정보가 섞여 있는지 확인해야 합니다
두 번째가 자주 문제가 됩니다. "일단 있는 자료라도 넣자"고 초안을 넣으면, 나중에 그 초안의 내용이 결과물에 반영되어 나갈 수 있습니다. 확정본만 넣는 편이 안전합니다.
그리고 자료가 많다고 좋은 것은 아닙니다. 관련 없는 자료가 많으면 정작 필요한 내용을 찾기 어려워지고, 엉뚱한 자료를 근거로 쓸 여지도 생깁니다. 그 업무에 실제로 쓰이는 것만 넣는 편이 낫습니다.
Projects를 나눌 때
하나의 Projects에 여러 업무를 담으면 지침이 서로 충돌합니다. 고객 응대와 내부 보고서 작성은 문체도 형식도 다른데 한 지침에 담으면 조건문투성이가 됩니다.
나누는 기준은 지침이 서로 충돌하는가입니다. 충돌하면 나누고, 겹치면 합칩니다.
| 상황 | 어떻게 |
|---|---|
| 문체와 형식이 다르다 | 나눈다 |
| 같은 자료를 쓰지만 결과물이 다르다 | 나누되 지식은 같은 것을 넣는다 |
| 형식은 같고 대상만 다르다 | 하나로 두고 요청에서 대상을 지정한다 |
세 번째가 판단이 필요한 자리입니다. 고객사 A용과 B용 제안서를 각각 Projects로 만들 필요는 없습니다. 형식이 같다면 하나로 두고 요청할 때 대상을 지정하는 편이 관리가 쉽습니다. 고객사가 열 곳이 되면 Projects도 열 개가 되어 지침을 고칠 때마다 열 번 고쳐야 합니다.
시험 함정
- 규칙을 지식에 넣어도 된다는 선택지 — 참고 자료 취급이 되어 매번 지켜지지 않습니다.
- 지침을 자세히 길게 쓸수록 좋다는 선택지 — 길면 중요한 규칙이 묻힙니다.
- 처음부터 완벽한 설정을 만들라는 선택지 — 무엇이 필요한지 모른 채 추측으로 채우게 됩니다.
- 초안 문서라도 일단 지식에 넣으라는 선택지 — 확정되지 않은 내용이 근거로 쓰입니다.
- 자료가 많을수록 결과가 좋아진다는 선택지 — 엉뚱한 자료를 근거로 쓸 여지가 생깁니다.
- 업무마다 Projects를 따로 만들라는 선택지 — 형식이 같으면 하나로 두는 편이 관리가 쉽습니다.
실습 시나리오
실제 시험과 같은 형식의 시나리오 문제입니다.
고객사 여덟 곳에 각각 제안서를 보냅니다. 형식과 문체는 모두 같고 고객사 이름과 제안 내용만 다릅니다. Projects를 어떻게 구성하는 것이 좋습니까?
빌드 연습 · 최소 설정으로 시작해 키우기
약 25분1.최소 지침 작성
업무 성격 한 줄과 출력 형식 한 줄만으로 Projects를 만듭니다.
기대 결과 · 지침이 두세 줄을 넘지 않습니다.
2.실제 작업 세 번
그 안에서 실제 업무를 세 번 수행합니다.
기대 결과 · 세 번의 결과가 남아 있습니다.
3.반복 수정 찾기
세 번 모두에서 손으로 고친 부분을 찾습니다.
기대 결과 · 매번 고친 것과 한 번만 고친 것이 구분되어 있습니다.
4.지침 추가
매번 고친 것만 지침에 한 줄씩 넣고 이유를 함께 적습니다.
기대 결과 · 추가된 줄마다 근거가 적혀 있습니다.
5.지식 점검
넣을 자료가 최신인지·확정본인지·넣어도 되는지 확인합니다.
기대 결과 · 세 항목을 확인한 기록이 남아 있습니다.