부록 B. 셀프 체크 정답과 해설

1장

1-1. 영향 범위(예: 고객 수백 명에게 나가는 안내문), 되돌리기 어려움(예: 송금, 발송, 삭제), 발견까지 걸리는 시간(예: 몇 주 뒤 민원으로야 드러나는 계산 오류). 세 요소 중 하나만 높아도 그 단계는 자동 실행보다 사람 승인이나 강한 검수가 필요합니다. 한 칸짜리 위험도 점수는 이 차이를 평균으로 지워 버립니다.

1-2. 처리 시간은 일을 하는 시간이고, 대기 시간은 다음 사람이 손대기를 기다리는 시간입니다. AI가 주로 줄이는 것은 처리 시간입니다. 둘을 섞어 재면, 대기가 대부분인 업무에서 AI 도입 효과를 과대평가하거나, 정작 필요한 절차 개선(배정 횟수, 결재선)을 놓칩니다.

1-3. 부서명 분류는 규칙(정해진 조건에 따른 분류라 정확하고 설명하기 쉽습니다). 항의인지 문의인지 가리기는 AI(문맥 해석이 필요합니다). 두 가지를 이어, AI가 성격을 판단하면 규칙이 그 결과에 따라 담당자에게 보내는 식으로 결합할 수 있습니다.

1-4. 승인은 행동을 해도 된다는 허락이고, 확인은 내용이 맞는지 검토하는 일입니다. 승인만 있으면 검수자는 무엇이 맞는지 보지 않고 버튼을 누르게 되고(승인 피로, 고무도장 검수), 오류가 그대로 통과하면서 책임만 승인자에게 남습니다.

1-5. 90건 × 4분 = 360분, 즉 하루 6시간이 필요한데 검수자는 3시간만 쓸 수 있으므로 계획대로는 절반이 검수되지 않습니다. 조정안으로는 위험이 낮은 건을 표본 검수로 돌리기, AI가 근거 위치를 표시하게 해 건당 시간을 줄이기, 자동화 대상을 하루 45건처럼 검수할 수 있는 양으로 좁히고 나머지는 기존 방식으로 처리하기 중 하나를 들 수 있습니다. 검수 지점을 그냥 없애는 것은 답이 아닙니다.

1-6. 매주 월요일 아침이라는 시작 조건은 예약 작업, 공유 드라이브의 회의록을 읽는 일은 커넥터(읽기 권한만), 결정 사항 정리는 지침에 형식을 정한 AI 생성, 결과는 팀장이 볼 위치(드라이브 문서나 알림)에 둡니다. 순서가 고정된 일이므로 스스로 단계를 정하는 에이전트는 필요 없고, 발송이 필요 없다면 발송 도구도 열지 않습니다.

1-7. 예시 답: 사람 검수 지점(위치·검수자·부재 시 처리)과 중단 조건. 새 담당자는 누가 무엇을 확인하는지와 언제 멈춰야 하는지를 모르면 자동화를 그대로 돌리거나 반대로 아예 멈춥니다. 목적과 기준선, 제외 업무와 그 이유를 고르고 같은 논리로 설명해도 맞습니다.

2장

2-1. 개인 맞춤 지침은 내 대화 전반에 적용되고 본인이 관리합니다. 프로젝트 지침은 그 프로젝트 안의 대화에만 적용되고 소유자·편집자가 관리하며, OpenAI 기준으로 프로젝트 안에서는 전역 맞춤 지침보다 우선합니다. 팀 규칙을 개인 지침에 두면 사람마다 결과가 달라지고, 새 구성원에게는 적용되지 않으며, 바꿀 때 모두가 각자 고쳐야 합니다.

2-2. 지침: ㉠ 근거 문서명 규칙, ㉢ 날짜를 먼저 묻는 절차, ㉤ 어조 규칙. 지식: ㉡ 매장 운영 시간표, ㉣ 모범 답변. 지침은 행동, 지식은 참고 자료입니다. 형식을 보여 주는 짧은 예시 한두 개는 지침에 넣을 수 있지만, 열 건짜리 답변 모음은 참고 자료이므로 지식에 둡니다. ㉡이 자주 바뀐다면 사본 대신 원본을 연결하는 방식을 검토합니다.

2-3. 예시 답:

[역할] 너는 사내 회의실 사용 안내자다.
[할 일] '회의실 사용 규정'에 근거해 예약 방법, 사용 가능 시간, 금지 사항을 안내한다.
[맥락] 질문자는 회의실을 가끔 쓰는 일반 직원이며 급하게 묻는 경우가 많다.
[형식] 결론 한 줄 → 절차 세 단계 이내 → 근거 조항 번호.
[예외 처리] 규정에 없는 상황이면 추측하지 않고 "규정에 없는 내용입니다"라고 쓴 뒤
          총무팀 창구를 안내한다. 이유: 잘못 안내하면 다른 부서 예약과 겹친다.

‘친절하게’, ‘틀리지 마라’ 같은 바람 대신 행동을 적었는지, 예외 처리에 이유가 붙었는지가 채점의 핵심입니다.

2-4. RAG 방식은 질문과 비슷한 일부 조각만 가져와 답하므로, 모든 자료를 빠짐없이 훑어야 하는 전수 집계에서는 일부를 놓칩니다. 이런 일은 자료를 표로 정리해 스프레드시트나 데이터 분석 기능으로 전체를 처리하는 방법을 씁니다.

2-5. 등록: 그 파일에만 있는 문장을 그대로 물어 보거나 파일이 글자로 읽히는지 확인합니다. 검색: 같은 내용을 자료에 쓰인 용어로 다시 묻습니다. 생성: 답이 근거로 든 위치를 원문과 대조해 조건을 빠뜨렸는지 봅니다. 어느 단계에서 실패했는지에 따라 처방(자료 손질, 용어집 보강, 지침 수정)이 달라집니다.

2-6. 연결형 소스는 원본의 변경이 반영될 수 있고(예: Gem에 추가한 Drive 파일), 업로드 사본은 올린 시점에 고정되어 누군가 교체해야 합니다. 같은 ‘연결’도 제품에 따라 미리 동기화하지 않기도 합니다. 대장에 이 구분을 적어야 자료마다 갱신 방법과 책임자가 분명해지고, 낡은 사본이 방치되지 않습니다.

2-7. 정상(정확히 답하고 근거를 밝힘), 예외(정보가 부족하면 되묻거나 담당자에게 넘김), 거절(접근하면 안 되는 정보는 답하지 않고 올바른 경로를 안내), 경계(자료가 충돌하면 우선순위를 적용하고 불확실성을 드러내며 지어내지 않음).

3장

3-1. 내 출입증으로는 내가 들어갈 수 있는 층에만 들어가듯, 커넥터는 연결한 사람의 원본 시스템 권한만큼만 닿습니다. 고정된 키 하나로 여러 사람이 연결하면 모두가 그 키의 권한을 갖게 되어, 개인별 권한 차이가 사라집니다. 이런 경우 구성원이 접근해도 되는 범위로 제한된 자격 증명을 씁니다.

3-2. 인증은 누구의 계정으로 연결했는지(예: 다른 계정으로 다시 연결), 접근 권한은 그 계정이 무엇에 닿는지(예: 원본 폴더의 공유 범위 변경, 연결 시 요청 범위 축소), 실행 승인은 이번 행동을 해도 되는지(예: 발송 도구를 매번 묻기로 설정)입니다. 실행 승인 설정을 바꿔도 접근 권한은 그대로라는 점이 핵심입니다.

3-3. 호스트는 직원이 쓰는 AI 채팅 앱, 클라이언트는 그 앱이 일정 서버와의 연결을 위해 만든 구성 요소, 서버는 일정 시스템의 기능(일정 조회·등록 같은 도구, 회의실 목록 같은 리소스)을 앱에 제공하는 프로그램입니다. 호스트가 서버 여러 개에 연결하면 서버마다 클라이언트가 하나씩 생깁니다.

3-4. 과도한 기능(쓰지 않는 도구를 차단하고 시험하다 남은 연결을 정리), 과도한 권한(개인 권한으로 연결하고 공용 키는 범위가 좁은 것으로), 과도한 자율(쓰기·발송·삭제 도구에 승인 필요 설정). 셋 중 하나만 줄여도 위험은 줄지만, 세 가지를 함께 줄여야 한 겹이 뚫려도 피해가 작습니다.

3-5. 산출물, 완료 기준, 사용 범위, 금지 행동, 중단 기준, 보고 방식 중 네 가지 이상. 중단 기준이 없으면 에이전트가 막힌 지점에서 같은 시도를 되풀이하며 시간과 사용량을 쓰고, 목표를 이루려고 로그인이나 결제 같은 우회로를 시도하거나, 오류가 쌓인 결과를 내놓을 수 있습니다.

3-6. 무엇을 승인하는지 보이지 않으면 사람은 내용을 확인하지 못한 채 누르게 되고, 승인 지점이 형식이 됩니다. 담아야 할 정보는 대상(수신자, 바뀌는 기록), 내용(금액·날짜·첨부), 영향(외부 공개 여부, 되돌릴 수 있는지), 근거(왜 필요하다고 판단했는지)입니다.

3-7. 외부 자료에는 숨은 지시가 섞일 수 있고, 인젝션을 완전히 막는 방법은 아직 분명하지 않습니다. 같은 작업이 보내기 도구까지 쥐고 있으면 숨은 지시가 정보를 밖으로 내보내는 통로를 얻습니다. 읽는 작업과 보내는 작업을 나누고 보내기는 사람이 맡으면 그 통로가 막힙니다. 다만 외부 주소를 부르는 이미지 같은 다른 유출 경로도 있으므로, 이것만으로 안전하다고 보지는 않습니다.

4장

4-1. 누가(사람), 무엇에(자료), 무엇을 할 수 있는지(행동)가 빠져 있어 실제 허용 범위를 알 수 없습니다. 예시 답: “영업팀원은 ‘제안서 서식’ 프로젝트의 파일을 보고 내려받을 수 있지만, 지침을 고치거나 다른 사람을 초대할 수는 없다.”

4-2.

가장 낮은 역할도 파일을 내려받을 수 있고, 편집 권한자는 초대는 하지만 내보내지는 못한다는 두 점이 자주 틀립니다.

4-3. 예시 답(대화 링크): ChatGPT의 비공개 프로젝트에서 대화 하나를 공유하면 받는 사람은 그 대화만 보고, 프로젝트의 다른 대화·파일·지침은 보지 못합니다. 공유 프로젝트의 대화라면 받는 사람이 프로젝트에 참여해야 열 수 있고, 참여하면 역할에 따라 나머지도 보게 됩니다. 다만 업무용 워크스페이스에서 만든 링크는 이후 메시지도 담길 수 있습니다. 다른 단위를 골랐다면 본문의 공유 단위 표와 맞는지 확인하세요. 예약 작업 링크는 지시문 전체가 보이고, 내보낸 파일은 원본과 동기화되지 않으며 권한도 이어지지 않습니다.

4-4. 보존 기간은 서비스에 남는 기간, 삭제는 특정 대화를 지우는 행동, 학습 사용은 모델 개선에 쓰이는지, 기억은 이후 대화가 지난 정보를 참고하는지를 통제합니다. 학습 사용을 꺼도 저장된 대화는 지워지지 않습니다(OpenAI). 지우려면 삭제를 따로 해야 하고, 삭제도 시스템에서 완전히 사라지기까지 시간이 걸릴 수 있습니다.

4-5. 개인정보의 일부를 지우거나 다른 값으로 바꿔서, 따로 보관한 추가 정보 없이는 누구인지 알아볼 수 없게 만드는 것입니다. 덜 보내는 조치로는 이름·연락처처럼 분석에 필요 없는 칸 빼기, 고객 이름을 ‘고객A’처럼 바꾸고 대응표는 AI 공간 밖에 두기, 개인별 기록 대신 유형별 건수 같은 집계값 쓰기 중 두 가지를 들 수 있습니다.

4-6. AI가 만든 요약·비교표·인용은 원본의 내용을 담은 파생 정보이므로, 내부 공간에서 만든 결과를 외부 공간에 붙여 넣으면 원본을 공유한 것과 같은 효과가 납니다. 운영 규칙 예: 외부 배포용 결과물은 외부 공유용 자료만 있는 공간에서 만들고, 내부 결과를 옮겨야 할 때는 사람이 줄 단위로 확인한다.

4-7. 많은 설정이 앞으로의 동작만 바꾸므로 이미 열린 공유나 연결이 남기 때문입니다. 앞으로만 작동하는 예: Claude에서 프로젝트 공유를 꺼도 기존 개별·그룹 공유는 유지됨(단, 전사 공개 프로젝트는 비공개로 바뀌어 공개 설정으로 쓰던 사람은 접근을 잃음), ChatGPT Enterprise의 도메인 연결 제한은 기존 연결을 끊지 않음. 즉시 되돌릴 수 없게 작동하는 예: Claude Enterprise에서 보존 기간을 줄이면 새 기간 밖의 데이터에 영구 삭제 일정이 잡힘.

5장

5-1. 긴 목록에 중요한 항목이 묻히고, 검수 시간이 늘어 형식적인 확인으로 끝나기 쉽습니다. 회의록 요약에는 사실 범주(결정 사항, 담당자, 기한이 회의 내용과 일치하는가)가 꼭 필요하고, 외부로 나가지 않는 내부 요약이라면 실행 대상이나 약속 범주는 생략할 수 있습니다. 요약을 외부로 보낸다면 판단이 달라집니다.

5-2. 경미(어색한 표현), 중요(날짜를 잘못 옮김), 중대(엉뚱한 고객에게 발송)를 예로 들 수 있습니다. 되돌리는 조건 예: 표본에서 중요 이상 오류가 정한 비율을 2주 연속 넘거나, 중대 오류가 한 건이라도 나오면 전수 검수로 돌아간다.

5-3. 같은 결과물을 각자 판정하기 → 엇갈린 건의 이유를 논의하기 → 합의한 기준을 예시와 함께 체크리스트에 적기(검수자가 바뀔 때마다 반복). 계속 엇갈리는 항목은 기준이 모호하다는 뜻이므로 더 작은 항목으로 쪼개거나, 판단이 아니라 확인할 수 있는 사실로 바꿉니다.

5-4. 생성 건수 기준 90 ÷ 200 = 45%, 검토 건수 기준 90 ÷ 120 = 75%. 품질 지표로는 검토가 끝난 건만 품질을 알 수 있으므로 75%를 쓰고, 검토율 60%(120 ÷ 200)를 함께 적어 검토되지 않은 건이 있다는 사실을 드러냅니다.

5-5. ㉠ 권한·연결(인증 만료), ㉡ 생성(맞는 근거를 찾았지만 해석에서 조건을 빠뜨림), ㉢ 입력(양식 변경으로 필요한 정보를 읽지 못함). ㉢을 지침 문제로 보고 강조 문장을 넣으면, AI가 없는 정보를 지어낼 위험만 커집니다.

5-6. 건당 절감 10 − (1 + 4) = 5분, 5분 × 500건 = 2,500분(41시간 40분), 여기서 유지 10시간을 빼면 월 약 31.7시간입니다. 성공이라고 말하기 전에 품질이 도입 전 수준인지(오류율), 재작업 시간이 빠지지 않았는지, 기준선을 같은 방식으로 쟀는지, 도구 비용은 얼마인지 중 하나를 확인해야 합니다.

5-7. 중단 신호와 멈출 권한을 가진 사람, 사람이 넘겨받을 절차와 담당자·양식, 다시 켜는 조건(원인 수정, 회귀 시험 통과, 책임자 승인). 예를 들어 재개 조건이 없으면 원인을 고치지 않은 채 급하게 다시 켜서 같은 오류가 반복되고, 수작업 절차가 없으면 멈춘 동안 업무가 쌓입니다.