HR·운영·고객응대 프롬프트 라이브러리

조직이 커질수록 반복 업무는 더 많이 생긴다

회사 초창기에는 많은 일이 말로 해결된다. 대표가 직접 설명하고, 팀장이 옆자리에서 알려주고, 고객 응대도 몇 사람이 감으로 버틴다. 그런데 조직이 커지면 그 방식은 곧 한계에 부딪힌다. 같은 질문이 반복되고, 같은 문서를 매번 새로 쓰게 되고, 사람마다 말이 조금씩 달라지면서 품질도 흔들린다.

바로 이 지점에서 프롬프트 라이브러리의 가치가 커진다. HR, 운영, 고객응대는 화려해 보이지 않을 수 있지만, 조직이 굴러가게 만드는 톱니바퀴 같은 영역이다. 그리고 톱니바퀴는 감으로 돌릴 때보다 규격이 맞을 때 훨씬 오래 버틴다.

이 장의 목표는 단순하다. 채용, 온보딩, 교육, SOP 작성, 제도 공지, 고객 문의 대응 같은 백오피스 실무를 프롬프트로 표준화하는 것이다. 쉽게 말해, 사람을 더 뽑기 전에 먼저 문장과 흐름을 잘 뽑아두자는 이야기다. 잘 만든 프롬프트 하나는 팀의 야근을 줄이고, 신입의 적응 속도를 높이고, 고객의 짜증을 덜어준다. 생각보다 꽤 멋진 일이다.

이 장에서 다루는 프롬프트의 기본 원칙

HR과 운영, 고객응대 프롬프트는 예쁜 문장을 만드는 데서 끝나면 안 된다. 이 영역에서는 결과물이 실제로 바로 써먹을 수 있어야 한다. 채용 공고는 지원자를 모아야 하고, 온보딩 체크리스트는 빠진 일이 없어야 하고, 고객응대 스크립트는 상담사가 그대로 참고할 수 있어야 한다.

좋은 프롬프트를 만들 때는 다섯 가지를 분명히 넣는 것이 좋다.

• 역할: 채용 담당자, HRBP, 교육 담당자, 운영 매니저, CS 리더처럼 AI가 어떤 모자를 쓸지 정한다.

• 목적: 공고 초안 작성, 면접 질문 설계, SOP 구조화, 문의 분류, 공지문 정리처럼 결과물을 분명히 말한다.

• 맥락: 회사 규모, 산업, 팀 분위기, 정책, 현재 이슈, 고객 상황 같은 배경을 준다.

• 제약: 추정 금지, 민감 정보 제외, 문장 길이, 톤, 포함 항목, 금지 표현을 적는다.

• 출력 형식: 표, 체크리스트, 문서 초안, FAQ, 스크립트처럼 결과의 모양을 정한다.

여기에 한 가지를 더 붙이면 결과 품질이 훨씬 좋아진다. 바로 보충 질문이다. 정보가 부족하면 먼저 3~5개의 질문을 하게 만들면, AI가 빈칸을 멋대로 상상하는 일을 줄일 수 있다. HR 실무에서 상상력은 창의력일 때도 있지만, 처우 조건이나 평가 기준 앞에서는 사고가 되기 쉽다.

또 하나 중요하다. 이 장의 프롬프트는 판단을 대신하기 위한 것이 아니다. 채용 합격 여부, 평가 결과, 징계 판단, 민감한 고객 보상 결정은 여전히 사람의 몫이다. AI는 초안 작성자이자 정리 도우미이지, 최종 결재권자는 아니다.

채용 프롬프트 라이브러리

채용 업무는 늘 비슷해 보이지만, 막상 시작하면 문서가 끝도 없이 나온다. 채용 계획서, 공고문, 면접 질문, 인터뷰 평가 정리, 오퍼 문안, 온보딩 연결까지. 결국 채용은 사람을 뽑는 일인 동시에 문서를 계속 이어 붙이는 일이다. 그래서 프롬프트 라이브러리를 만들면 가장 바로 체감되는 영역이기도 하다.

채용 계획서 프롬프트

채용 계획서는 단순히 빈자리 채우기 문서가 아니다. 누구를 왜 뽑고, 언제까지, 어떤 단계로, 어떤 비용 안에서 진행할지를 정리하는 운영 문서다. 이 문서가 흐리면 뒤에 나오는 공고문과 면접 기준도 같이 흐려진다.

당신은 채용 프로세스를 체계적으로 설계하는 HR 담당자입니다.
아래 정보를 바탕으로 채용 계획서를 작성해주세요.

회사/조직 맥락: [예: B2B SaaS 스타트업, 80명 규모, 빠른 성장 중]
채용 포지션: [포지션명]
직급: [신입 / 경력 / 리드]
채용 인원: [N명]
채용 사유: [신규 채용 / 결원 보충 / 조직 확대]
목표 입사일: [날짜]
채용 채널: [채용 플랫폼 / 리퍼럴 / 헤드헌터 / 자사 홈페이지]
전형 단계: [서류 > 과제 > 1차 면접 > 2차 면접 > 처우 협의 등]
단계별 희망 일정: [주차 또는 날짜]
예산/제약: [있으면 작성]
담당 부서 및 이해관계자: [HR, 현업 리더 등]

작성 전 정보가 부족하면 3~5개의 보충 질문을 먼저 해주세요.

출력 형식:
1. 채용 배경
2. 핵심 역할과 기대 성과
3. 전형 절차와 일정
4. 채널 운영 계획
5. 리스크와 대응 포인트
6. 경영진 보고용 7줄 요약
7. 실행 체크리스트

조건:
- 모호한 표현 대신 구체적으로 작성
- 추정이 필요한 내용은 별도 표시
- 실제 운영 가능한 수준으로 작성

채용 공고문 프롬프트

좋은 공고문은 무조건 많은 지원자를 모으는 문서가 아니다. 맞는 사람은 들어오게 하고, 맞지 않는 사람은 미리 걸러내는 문서다. 너무 멋있기만 한 공고문은 면접장에서 되레 되묻게 된다. 그래서 채용 공고는 브랜딩과 필터링의 균형이 중요하다.

당신은 [업종] 회사의 채용 담당자입니다.
아래 정보를 바탕으로 채용 공고문 초안을 작성해주세요.

회사 소개 핵심: [한두 문장]
포지션명: [포지션명]
소속 팀: [팀명]
채용 배경: [왜 뽑는지]
주요 업무: [3~7개]
필수 요건: [목록]
우대 요건: [목록]
근무 형태: [오피스 / 하이브리드 / 원격]
근무지: [지역]
회사 톤: [친근함 / 전문적 / 직설적 / 따뜻함]
지원자에게 강조할 매력 포인트: [있으면 작성]

출력 형식:
- 공고 제목 후보 5개
- 공고문 본문
- 지원자가 오해하기 쉬운 표현 3개와 수정안
- 채용 플랫폼 검색용 키워드 10개

조건:
- 과장된 표현 금지
- 업무와 기대치를 분명히 설명
- 전문 용어는 쉬운 말로 풀어쓰기
- 실제 지원 결정을 돕는 정보 중심으로 작성

구조화 면접 가이드 프롬프트

면접에서 제일 무서운 말은 사실 이것이다. "면접관마다 보는 포인트가 달랐어요." 이 말은 공정성과 비교 가능성이 둘 다 흔들렸다는 뜻이다. 구조화 면접 가이드는 면접을 로봇처럼 만들기 위한 것이 아니라, 같은 질문과 같은 기준 위에서 사람을 보게 해주는 안전장치다.

당신은 공정한 채용을 돕는 HR 담당자입니다.
아래 직무에 맞는 구조화 면접 가이드를 만들어주세요.

포지션명: [포지션명]
직급: [직급]
핵심 역량: [3~5개]
반드시 확인할 경험: [목록]
면접 단계: [서류 후 1차 실무 / 2차 리더 면접 등]
단계별 면접 시간: [예: 45분]
우리 조직이 중요하게 보는 태도: [예: 협업, 주도성, 학습력]

작성 전 부족한 정보가 있으면 질문해주세요.

출력 형식:
1. 면접 오프닝 멘트
2. 역량별 행동기반 질문 6~8개
3. 질문별 꼬리 질문 2개씩
4. 1~5점 평가 기준표
5. 면접 후 디브리프 체크리스트
6. 금지 질문 주의사항

조건:
- 가족관계, 결혼, 출산, 나이 등 민감 질문 금지
- 추상적 질문보다 실제 행동 경험 질문 위주
- 면접관이 바로 사용할 수 있게 실무형으로 작성

지원자 이력 요약 및 인터뷰 리스크 정리 프롬프트

이력서를 읽다 보면 화려한 단어에 눈이 먼저 간다. 하지만 실무에서는 멋진 표현보다 빠른 요약이 중요하다. 특히 여러 후보자를 비교할 때는 길게 잘 쓴 자기소개보다 구조화된 비교가 더 큰 힘을 발휘한다.

당신은 채용 코디네이터입니다.
아래 지원자 정보를 바탕으로 인터뷰 준비용 요약본을 작성해주세요.

지원자 정보: [이력서/경력기술서/포트폴리오 내용]
채용 포지션: [포지션명]
핵심 평가 항목: [예: 실무 적합성, 협업, 문제 해결]

출력 형식:
- 5줄 요약
- 강점 3개
- 확인이 필요한 공백 또는 리스크 3개
- 인터뷰에서 꼭 검증할 질문 5개
- 현업 면접관에게 전달할 메모

조건:
- 추정은 최소화하고 자료 기반으로 작성
- 모호한 경력은 검증 포인트로 표시
- 평가 결론을 단정하지 말고 확인 질문 중심으로 정리

온보딩·교육 프롬프트 라이브러리

채용이 끝났다고 일이 끝난 것은 아니다. 오히려 진짜 운영은 그다음부터 시작된다. 어렵게 뽑은 사람이 첫달에 길을 잃으면, 채용 비용은 순식간에 학습 비용으로 바뀐다. 온보딩은 환영 행사라기보다 적응 설계에 가깝다. 그리고 교육은 좋은 말 모음집이 아니라, 실제로 일을 하게 만드는 학습 흐름이어야 한다.

30-60-90일 온보딩 체크리스트 프롬프트

온보딩이 실패하는 가장 흔한 이유는 '잘 챙기자'라는 마음은 있는데 '누가 언제 무엇을'이 없기 때문이다. 체크리스트는 감동을 대신하지 못하지만, 놓치는 일을 줄여준다. 실무에서는 이게 꽤 큰 감동이다.

당신은 신규 입사자의 조기 적응을 설계하는 HR 담당자입니다.
아래 조건에 맞는 30-60-90일 온보딩 체크리스트를 만들어주세요.

포지션명: [포지션명]
고용 형태: [정규직 / 계약직 / 인턴]
근무 형태: [오피스 / 하이브리드 / 원격]
조직 문화 특징: [예: 문서 중심, 자율과 책임, 빠른 실행]
필수 시스템/툴: [목록]
필수 교육: [보안교육, 제품교육 등]
팀원 참여 수준: [높음 / 보통 / 낮음]
버디 제도 운영 여부: [예/아니오]

출력 형식:
- 입사 전 프리보딩 체크리스트
- 입사 첫날 체크리스트
- 1주차 체크리스트
- 30일 / 60일 / 90일 체크리스트
- HR / 리더 / 버디 / 신규 입사자 역할별 할 일
- 자주 빠지는 항목 5개

조건:
- 각 항목은 실행 가능한 문장으로 작성
- 담당자와 시점을 분명히 표시
- 원격/하이브리드이면 별도 유의사항 포함

버디와 리더 체크인 질문 프롬프트

온보딩에서 가장 자주 듣는 말 중 하나가 "모르면 물어보세요"다. 그런데 막상 신입 입장에서는 무엇을, 누구에게, 어느 정도까지 물어봐도 되는지 모른다. 그래서 체크인은 분위기에 맡기기보다 질문을 설계해두는 편이 좋다.

신규 입사자 온보딩을 위한 체크인 질문지를 만들어주세요.

대상: [버디 / 팀 리더 / HR]
입사 시점: [1주차 / 30일 / 60일 / 90일]
포지션 특성: [예: 개발, 영업, 운영]
확인하고 싶은 영역: [업무 이해 / 관계 형성 / 심리적 안정감 / 제도 이해 / 성과 목표]

출력 형식:
- 오프닝 질문 2개
- 상태 점검 질문 5개
- 어려움 발견용 질문 5개
- 마무리 질문 2개
- 체크인 후 기록해야 할 항목

조건:
- 평가처럼 들리지 않게
- 대답이 예/아니오로 끝나지 않게
- 실제 1:1 미팅에서 바로 쓸 수 있게 작성

교육 프로그램 기획 프롬프트

교육 기획은 자칫하면 그럴듯한 목차 만들기 대회가 되기 쉽다. 하지만 좋은 교육안은 예쁜 슬라이드보다, 누가 무엇을 바꾸게 할 것인지가 선명하다. 그래서 교육 프롬프트는 대상, 현재 수준, 실무 연결성, 제약 조건을 분명히 줘야 한다.

당신은 사내 교육 프로그램을 기획하는 HRD 담당자입니다.
아래 정보를 바탕으로 교육 프로그램 초안을 설계해주세요.

교육 주제: [주제]
대상자: [예: 신입 영업팀 8명]
현재 상황: [대상자의 수준, 현업 이슈]
교육 목적: [무엇이 달라져야 하는지]
교육 시간: [예: 3시간 / 1일]
희망 형식: [강의 / 워크숍 / 실습 / 토론 혼합]
주의사항: [이론 과다 금지, 툴 설명만 하지 말 것 등]

출력 형식:
1. 교육 목표 3개
2. 전체 커리큘럼 표
3. 세션별 진행 방식
4. 활동 아이디어 5개
5. 교육 전 안내 문구
6. 교육 후 측정 지표

조건:
- 실무 연결성이 느껴지게 작성
- 대상 수준에 맞는 난이도 조절
- 지나치게 교과서적인 표현은 줄이기

설문·퀴즈·워크북 생성 프롬프트

교육을 하고 나면 늘 같은 질문이 따라온다. "좋았는지는 알겠는데, 그래서 남는 게 뭔가요?" 이때 필요한 것이 설문과 퀴즈, 워크북이다. 교육의 여운을 데이터와 행동으로 바꾸는 도구라고 생각하면 쉽다.

아래 교육 정보를 바탕으로 설문, 퀴즈, 워크북 초안을 만들어주세요.

교육 주제: [주제]
대상: [대상자]
교육 목표: [목표]
교육 형식: [강의 / 워크숍 / 온라인]
특히 확인하고 싶은 것: [만족도 / 이해도 / 현업 적용 가능성]

출력 형식:
- 사전 설문 문항 5개
- 사후 만족도 설문 문항 7개
- 이해도 점검 퀴즈 10문항
- 실습용 워크북 질문 5개
- 결과 해석 시 주의할 점

조건:
- 문항은 간결하고 이해하기 쉽게
- 선택형과 서술형을 적절히 혼합
- 현업 적용 여부를 확인하는 문항 포함

운영·SOP 프롬프트 라이브러리

운영 업무는 티가 잘 안 난다. 하지만 티가 안 나는 이유는 잘 돌아가고 있기 때문일 때가 많다. SOP, 공지, 정책 문서, 내부 FAQ 같은 운영 문서는 팀이 말없이도 비슷한 품질로 일하게 만드는 장치다. 사람이 늘어날수록 설명은 줄이고 기준은 늘려야 한다. 그 기준을 만드는 데 프롬프트 라이브러리가 아주 쓸모 있다.

SOP 초안 작성 프롬프트

SOP는 그럴듯한 장표가 아니라 실제로 따라 할 수 있는 절차여야 한다. 그래서 처음부터 완벽한 문서를 쓰려 하기보다, 흩어진 메모와 구두 설명을 구조화하는 데 AI를 쓰는 것이 좋다.

당신은 운영 프로세스를 문서화하는 업무 표준화 담당자입니다.
아래 메모를 바탕으로 SOP 초안을 작성해주세요.

업무명: [업무명]
현재 메모/설명: [붙여넣기]
대상 사용자: [신입 / 팀원 / 타부서]
목적: [왜 이 SOP가 필요한지]
관련 툴/시스템: [목록]
예외 상황: [있으면 작성]

출력 형식:
1. 목적
2. 적용 범위
3. 선행 조건
4. 단계별 절차
5. 품질 체크포인트
6. 예외 및 에스컬레이션 기준
7. 결과물 저장 규칙
8. 자주 묻는 질문

조건:
- 실제 따라 할 수 있게 단계별로 구체화
- 모호한 표현은 체크포인트로 보완
- 스크린샷이 있으면 좋을 지점을 표시

제도 변경 공지와 FAQ 프롬프트

제도 변경 공지는 늘 민감하다. 전달은 한 번인데 질문은 열 번 돌아온다. 그래서 좋은 공지는 문장력이 아니라 오해를 줄이는 구조가 중요하다. 무엇이 바뀌는지, 언제부터인지, 누구에게 적용되는지, 예외는 무엇인지가 한눈에 보여야 한다.

당신은 사내 제도 변경을 안내하는 운영 담당자입니다.
아래 정보를 바탕으로 공지문과 FAQ를 작성해주세요.

변경 제도명: [예: 연차 사용 기준, 재택근무 규정]
변경 배경: [왜 바뀌는지]
핵심 변경 사항: [무엇이 어떻게 바뀌는지]
적용 시점: [날짜]
적용 대상: [누구에게 적용되는지]
예외 사항: [있으면 작성]
문의 채널: [담당자/채널]
톤: [명확하고 부드럽게 / 공식적으로]

출력 형식:
- 공지 제목 3개
- 전체 공지문
- 직원이 가장 많이 물을 FAQ 7개
- 혼동을 줄이기 위한 예시 3개

조건:
- 달라지는 점을 전후 비교 형태로 설명
- 불필요하게 딱딱하지 않게
- 질문을 미리 차단하는 방향으로 작성

반복 문의를 내부 FAQ로 바꾸는 프롬프트

운영팀이 바빠지는 이유 중 하나는 새로운 문제가 많아서가 아니라, 같은 질문이 매주 돌아오기 때문이다. 이럴 때는 답변을 계속 쓰는 대신, 질문을 자산으로 바꾸는 쪽이 더 낫다.

아래 반복 문의 내역을 바탕으로 내부 FAQ 문서를 만들어주세요.

문의 목록: [붙여넣기]
대상 독자: [전사 / 특정 팀 / 신입사원]
카테고리 기준: [예: 근태, 비용 처리, 장비, 결재]

출력 형식:
- 카테고리별 FAQ
- 각 문항의 한 줄 답변
- 자세한 설명
- 자주 헷갈리는 포인트
- 문서 상단에 넣을 요약 안내문

조건:
- 질문 표현은 실제 직원이 쓰는 말투를 반영
- 답변은 짧고 명확하게
- 정책상 예외가 있으면 별도 표시

고객응대 프롬프트 라이브러리

고객응대는 말 한마디가 매출, 리뷰, 재구매, 브랜드 인식까지 건드리는 영역이다. 동시에 반복도가 매우 높다. 주문 문의, 배송 지연, 환불 요청, 제품 불만, 사용법 안내, 감정적 항의까지 패턴이 계속 나온다. 그래서 고객응대야말로 프롬프트 라이브러리의 진가가 드러나는 분야다.

중요한 점은 하나다. 고객응대 프롬프트는 친절한 문장을 뽑는 데서 멈추면 안 된다. 분류, 우선순위, 대응 흐름, 금지어, 에스컬레이션까지 함께 설계해야 한다. 상담사는 늘 바쁘고, 고객은 늘 지금이 제일 급하다. 그러니 시스템이 먼저 침착해야 한다.

문의 분류와 라우팅 프롬프트

같은 질문이라도 어떤 것은 바로 답할 수 있고, 어떤 것은 다른 부서로 넘겨야 하며, 어떤 것은 즉시 대응해야 한다. 분류가 느슨하면 고객은 같은 말을 세 번 하게 되고, 그 순간부터 기분이 상하기 시작한다.

당신은 CS 운영 리더입니다.
아래 고객 문의를 분류하고 라우팅 기준을 정리해주세요.

문의 데이터: [문의 사례 붙여넣기]
현재 운영 채널: [전화 / 메일 / 채팅 / 메신저]
사용 가능한 분류 기준: [주문 / 배송 / 환불 / 불량 / 사용법 / 클레임 등]
긴급도 기준: [즉시 / 당일 / 일반]
연결 가능한 부서: [CS / 물류 / 개발 / 운영 / 매장]

출력 형식:
- 문의 유형 분류표
- 긴급도 판단 기준
- 1차 응대 가능 범위
- 부서별 이관 기준
- 고객에게 안내할 예상 처리 시간 문구

조건:
- 실제 상담사가 빠르게 판단할 수 있게 작성
- 겹치는 유형은 우선순위 기준 제시
- 민감 이슈는 에스컬레이션 표시

표준 응대 스크립트 프롬프트

CS에서 가장 위험한 것은 무성의함보다 들쭉날쭉함이다. 누군가는 과하게 사과하고, 누군가는 너무 딱딱하고, 누군가는 정책을 말하다가 감정을 놓친다. 표준 응대 스크립트는 상담사를 기계로 만드는 것이 아니라, 최소한의 일관성을 주는 가이드다.

당신은 10년차 CS 매니저입니다.
아래 조건에 맞는 표준 응대 스크립트를 작성해주세요.

상황: [배송 지연 / 환불 요청 / 제품 불량 / 사용법 문의 / 강한 불만 제기]
고객 감정 상태: [차분함 / 답답함 / 화남]
정책상 가능한 조치: [환불 / 교환 / 재안내 / 보상 없음 등]
브랜드 톤: [따뜻함 / 전문적 / 빠르고 간결함]

출력 형식:
1. 첫 응답 문장
2. 공감 표현 예시
3. 사실 확인 질문
4. 해결책 안내 문장
5. 마무리 문장
6. 금지어와 추천 표현

조건:
- 책임 회피처럼 들리지 않게
- 과도한 약속 금지
- 고객이 다음 행동을 이해할 수 있게 작성

클레임 에스컬레이션 요약 프롬프트

고객 불만이 커졌을 때 흔히 생기는 일은 두 가지다. 정보는 길어지고, 책임자는 더 바빠진다. 이럴 때 필요한 것은 감정적인 요약이 아니라, 책임자가 30초 안에 상황을 파악할 수 있는 에스컬레이션 메모다.

아래 고객 클레임 내용을 바탕으로 상위 담당자 보고용 에스컬레이션 메모를 작성해주세요.

고객 문의/대화 내용: [붙여넣기]
현재까지 조치: [무엇을 했는지]
정책상 한계: [어디까지 가능한지]
추가 판단이 필요한 내용: [보상, 환불, 공개 답변 여부 등]

출력 형식:
- 사건 개요
- 고객 요구사항
- 현재 사실관계
- 리스크 포인트
- 추천 대응안 2개
- 즉시 결정이 필요한 사항

조건:
- 감정적 표현보다 사실 중심
- 길게 늘어놓지 말고 핵심만 정리
- 고객 개인정보는 가려서 작성

VOC 요약과 개선 과제 도출 프롬프트

고객문의는 처리하고 끝내면 비용이고, 쌓아서 개선에 쓰면 자산이다. 반복되는 VOC를 읽다 보면 회사가 자꾸 같은 벽에 부딪히는 지점이 보인다. 배송 안내가 불명확한지, 제품 설명이 부족한지, 정책 문구가 오해를 부르는지 말이다.

당신은 VOC 분석 담당자입니다.
아래 고객 문의와 불만 데이터를 분석해 개선 과제를 정리해주세요.

기간: [예: 최근 1개월]
문의/불만 데이터: [붙여넣기]
중점적으로 보고 싶은 항목: [반복 문의 / 불만 급증 / 이탈 위험 / FAQ 개선]

출력 형식:
1. 핵심 요약
2. 반복 문의 TOP 5
3. 불만 원인 카테고리화
4. 즉시 개선 과제 3개
5. 장기 개선 과제 3개
6. FAQ 또는 공지로 전환할 수 있는 항목

조건:
- 감상문이 아니라 실행 과제로 정리
- 빈도와 영향도를 함께 고려
- 숫자가 없으면 정성적 패턴으로 설명

팀에서 바로 쓰기 좋은 프롬프트 조합 플레이북

프롬프트 라이브러리의 진짜 힘은 한 개를 잘 쓰는 데 있지 않다. 연결해서 쓸 때 비로소 업무 흐름이 생긴다. 특히 HR, 운영, 고객응대는 앞 단계의 결과물이 다음 단계의 입력값이 되는 일이 많다.

예를 들어 채용에서는 이런 식으로 연결할 수 있다.

채용 계획서 프롬프트로 기준을 만든 뒤, 그 내용을 바탕으로 채용 공고를 작성한다. 이후 같은 기준으로 구조화 면접 가이드를 만들고, 면접이 끝나면 지원자 요약 프롬프트로 비교표를 만든다. 이렇게 하면 채용 과정 전체의 말투와 판단 축이 통일된다.

온보딩도 마찬가지다. 채용 완료 후 30-60-90일 체크리스트를 만들고, 여기에 버디 체크인 질문지를 연결한다. 이후 교육 프로그램 기획 프롬프트로 필요한 교육을 설계하고, 설문·퀴즈 프롬프트로 효과를 측정한다. 한 사람의 입사가 여러 문서로 찢어지지 않고 하나의 흐름으로 이어진다.

고객응대는 더 분명하다. 먼저 문의 분류 프롬프트로 카테고리와 라우팅 기준을 만들고, 주요 유형별 표준 스크립트를 만든다. 민감한 이슈는 에스컬레이션 요약 프롬프트로 넘기고, 한 달 단위로 VOC 분석 프롬프트를 돌려 개선 과제를 뽑는다. 즉, 응대에서 끝나지 않고 운영 개선으로 다시 돌아오는 루프가 생긴다.

라이브러리로 자산화할 때 꼭 넣어야 할 변수

프롬프트를 저장해두고도 잘 안 쓰게 되는 이유는 대개 하나다. 우리 조직 맥락이 빠져 있어서다. 남의 회사 템플릿은 처음엔 그럴듯해도, 막상 가져다 쓰면 이상하게 어색하다. 그래서 라이브러리로 자산화할 때는 우리 회사 변수부터 고정해두는 것이 좋다.

최소한 다음 항목은 공통 변수로 정리해두자.

• 회사 소개 한 줄 버전

• 자주 쓰는 팀명과 직무명

• 조직이 선호하는 톤 앤 매너

• 금지 표현과 민감 표현 기준

• 공통 출력 형식 예시

• 개인정보 비식별 처리 원칙

예를 들어 고객응대에서는 고객명, 주문번호, 내부 담당자명 같은 정보는 바로 넣지 않고 대괄호 변수로 처리해두는 편이 안전하다. HR 문서에서도 지원자 실명, 연봉 정보, 평가 의견은 바로 복붙하기보다 익명화 후 구조만 정리하는 습관이 좋다. 프롬프트 라이브러리는 생산성 도구이기도 하지만, 동시에 사고를 줄이는 안전장치이기도 하다.

실무에서 품질을 높이는 마지막 점검 질문

AI가 만든 초안을 바로 쓰기 전에, 아래 질문 세 가지만 확인해도 품질이 확 달라진다.

첫째, 이 문서는 누가 읽고 무엇을 해야 하는가. 읽는 사람의 다음 행동이 안 보이면, 좋은 문장도 실무에서는 애매하다.

둘째, 빠진 정보는 없는가. 일정, 담당자, 적용 대상, 예외 기준, 문의 채널 같은 기본 정보가 하나만 빠져도 왕복 커뮤니케이션이 시작된다.

셋째, 우리 조직의 언어인가. AI는 자연스러운 한국어를 만들 수는 있어도, 우리 팀다운 한국어까지 자동으로 맞추진 못한다. 마지막 손질은 늘 사람이 해야 한다.

이 장의 핵심 정리

HR, 운영, 고객응대 업무는 반복이 많고, 그래서 표준화의 효과가 가장 크게 드러나는 영역이다. 채용에서는 기준이 흔들리지 않게 만들고, 온보딩에서는 누락을 줄이며, 교육에서는 실무 연결성을 높이고, 운영에서는 문서와 절차를 고정하고, 고객응대에서는 일관된 품질을 만들 수 있다.

핵심은 프롬프트를 많이 모으는 것이 아니다. 자주 반복되는 장면을 먼저 붙잡는 것이다. 채용 계획서, 구조화 면접 가이드, 30-60-90일 온보딩, SOP 초안, 제도 변경 공지, 문의 분류, 표준 응대 스크립트. 이 정도만 잘 만들어도 백오피스의 체감 난이도는 꽤 내려간다.

조직이 커질수록 반복 업무는 늘어난다. 그리고 바로 그때, 잘 만든 프롬프트 라이브러리는 단순한 편의 기능이 아니라 운영 역량이 된다. 사람을 더 열심히 쓰는 조직보다, 반복을 더 잘 설계하는 조직이 오래 간다. 이 장의 프롬프트들이 여러분 팀의 반복을 덜 지치게, 그리고 조금 더 똑똑하게 만들어주길 바란다.