금요일 오후, 운영팀 PM 지원 담당 민서에게 일이 몰립니다. 오전 장애 회의록 정리, 주간 보고 초안, 협력사에 보낼 요청 메일 — 모두 오늘까지입니다.
옆자리 선배는 같은 양을 절반 시간에 끝냅니다. 비결을 물으니 "생성형 AI한테 초안을 시켜요"라고 합니다. 다만 한마디를 덧붙입니다. "대신 고객사 이름이나 실제 로그는 절대 안 넣어요. 그리고 숫자랑 고유명사는 내가 다시 확인해요. AI는 초안만 빠르게 뽑고, 맞는지 틀린지는 사람이 봐야 하거든요."
민서는 두 가지를 동시에 배웁니다. 하나는 AI가 반복 문서·요약·초안을 정말 빠르게 만들어 준다는 것. 다른 하나는 함부로 넣으면 안 되는 정보가 있고, 사실은 사람이 확인해야 한다는 것. 이 모듈은 그 두 가지 — AI를 보조자로 쓰는 사고법과 안전수칙 — 를 다룹니다.
- 1"모델 하나가 아니라 작업별로 AI를 라우팅한다"는 2026년 핵심 관점을 설명할 수 있다
- 2Claude·ChatGPT·Gemini·Perplexity·회의도구·코드AI의 강점을 IT PM 업무에 매핑할 수 있다
- 3같은 모델군의 3-tier(최고성능·균형·저렴)를 비용/성능에 맞춰 고르는 라우팅 사고를 적용할 수 있다
- 4좋은 프롬프트의 4요소(역할·맥락·제약·출력형식)를 구분하고 직접 한 줄로 조합할 수 있다
- 5외부 AI에 넣어도 되는 정보를 데이터 분류표로 정하고, "사실은 사람이 확인한다"는 검증 기준을 적용할 수 있다
핵심 사고 전환 — 모델 하나가 아니라 '작업별 라우팅'
가장 좋은 AI 하나는 없다, 일에 맞는 AI가 있다
2026년 AI 활용의 핵심을 한 문장으로 요약하면 이렇습니다. "LLM 하나를 고르는 게 아니라, 작업별로 모델·도구를 라우팅한다." 성공하는 팀은 한 챗봇에 모든 걸 맡기지 않고, 일의 성격(긴 문서 분석인지·범용 초안인지·출처 있는 사실 확인인지)에 따라 능력·지연·비용으로 도구를 나눠 씁니다. 엔지니어가 워크로드에 맞춰 서버·캐시·DB를 나눠 쓰는 것과 같은 발상입니다.
IT PM 업무는 의외로 종류가 많습니다 — 회의록 정리, 주간 보고, RFP 검토, 장애 보고서, 벤더 비교, 협력사 커뮤니케이션. 이 각각에 "대체로 잘 맞는" AI가 다릅니다. 아래는 그 라우팅 지도입니다.
업무를 입력으로, 적합 AI를 출력으로 보는 라우팅 지도 — 보안 허용 여부가 모델 선택보다 먼저 온다.
어떤 일에 어떤 AI가 강한가 (2026년 6월 기준)
제품 기능은 빠르게 바뀌므로, 절대적 우열이 아니라 "대체로 이런 작업에 잘 맞는다"는 경향으로 받아들이세요.
| 도구 | 대체로 강한 것 | IT PM 업무 매핑 |
|---|---|---|
| Claude | 긴 문서 분석·정확도·안전성, 환각 적음 | RFP·계약서·장애보고서 장문 정독·요약·교차검증, 구조화 출력, 스크립트 리뷰 |
| ChatGPT | 성숙한 생태계·멀티모달·웹검색, 범용 기본값 | 문서 초안·브레인스토밍·도식 생성·창의적 재작성 |
| Gemini | Google Workspace 통합·초장문 컨텍스트 | Docs/Sheets/Gmail/Meet 안에서 자료 요약·표 추출, 대용량 문서 처리 |
| Perplexity | 출처를 번호로 인라인 인용, 실시간 정보 | 벤더 비교·기술 동향·ITIL/ISO 표준 출처 검증 가능한 빠른 사실 확인 |
| 회의도구(Otter·Granola류) | 실시간 전사·요약·액션아이템 추출 | 회의록 자동화 — 단, 액션아이템이 티켓으로 안 넘어가는 한계는 사람이 메움 |
| 코드AI(Copilot·Cursor) | 코드 생성·다파일 수정·PR 요약 | PM이 코딩 안 해도 운영 스크립트 초안·IaC 리뷰·"이 PR 뭐 바꾸나" 요약 |
핵심 교훈 한 줄: "가장 좋아하는 데모가 아니라, 가장 비싼 실수를 기준으로 도구를 골라라." 고객 보고에 들어갈 RFP 분석은 정확도(Claude)가, 빠른 사실 확인은 출처 인용(Perplexity)이 비싼 실수를 막아 줍니다.
같은 모델군 안에서도 3-tier — 비용/성능 라우팅
라우팅은 "어느 회사 AI냐"에서 끝나지 않습니다. 같은 모델군 안에도 3단계가 있습니다. 주요 LLM은 공통적으로 이런 구조입니다.
| 등급 | 성격 | IT PM 사용 예 |
|---|---|---|
| 최고 성능(Opus급) | 복잡 추론·장문·코딩 정확 | RFP 100쪽 분석, 다단계 장애 RCA, 까다로운 계약 검토 |
| 균형(Sonnet급) | 빠르고 똑똑, 일상 기본값 | 회의록 정리, 주간 보고 초안, 일반 문서 작업 |
| 저렴·고속(Haiku급) | 단순·대량 처리 | 장애 1건 한 줄 요약, 대량 티켓 분류, 반복 라벨링 |
라우팅 사고의 실전 예: "장애 1건 요약은 저렴한 모델로, RFP 100쪽 분석은 최고 성능 모델로." 모든 일을 최고 모델에 맡기면 느리고 비싸고, 모든 일을 저렴한 모델에 맡기면 중요한 분석에서 실수가 납니다. 일의 무게에 모델 무게를 맞추는 것이 라우팅입니다.
AI를 '검색'이 아니라 '초안 보조자'로 본다
무엇을 잘하고, 무엇을 못하는가
많은 사람이 생성형 AI를 "더 똑똑한 검색"으로 씁니다. 그런데 검색은 "존재하는 사실을 찾아 주는 것"이고, 생성형 AI는 "그럴듯한 문장을 만들어 주는 것"입니다. 이 차이를 모르면 거짓을 사실로 착각하게 됩니다.
PM·운영 업무에서 AI의 진짜 쓸모는 반복되고, 형식이 정해져 있고, 사람이 처음부터 쓰면 지치는 일을 빠르게 초안화하는 것입니다.
| AI가 잘하는 일(보조 적합) | AI에게 맡기면 위험한 일 |
|---|---|
| 긴 회의 메모를 요약·정리 | 숫자·날짜·고유명사의 사실 확정 |
| 보고서·메일의 초안 작성 | 우선순위 결정과 승인 |
| 같은 형식 문서의 반복 생성 | 외부에 나가는 최종 보고의 책임 |
| 문장 다듬기·말투 통일 | 고객사 정보·계약·개인정보 처리 |
| 표·체크리스트 양식 만들기 | "이게 사실이냐"의 최종 판단 |
핵심은 한 문장입니다. AI는 초안을 빠르게, 사람은 사실과 책임을 확실하게. AI가 만든 결과는 "다 된 답"이 아니라 "사람이 다듬을 재료"입니다.
좋은 프롬프트의 4요소
역할 · 맥락 · 제약 · 출력형식
같은 AI라도 어떻게 시키느냐에 따라 결과가 크게 달라집니다. "회의록 정리해 줘"는 막연하지만, 누구처럼, 어떤 상황에서, 무엇을 지키며, 어떤 모양으로 만들지를 알려 주면 바로 쓸 수 있는 초안이 나옵니다. 이 네 가지가 좋은 프롬프트의 4요소입니다.
| 요소 | 무엇을 정하나 | 나쁜 예 → 좋은 예 |
|---|---|---|
| 역할(Role) | AI가 어떤 입장에서 답할지 | (없음) → "너는 IT 운영팀 PM 보조다" |
| 맥락(Context) | 배경·대상·목적 | (없음) → "주간 운영 회의 메모를 임원 보고용으로 정리한다" |
| 제약(Constraints) | 지켜야 할 규칙·한계 | (없음) → "사실만, 추측 금지, 5문장 이내, 고유명사는 그대로" |
| 출력형식(Format) | 결과의 모양 | (없음) → "표로, 열은 항목·현황·조치, 3행" |
이 넷을 한 줄로 조합하면 이렇게 됩니다.
[역할] 너는 IT 운영팀 PM 보조다.
[맥락] 아래는 주간 운영 회의 메모이고, 임원 보고용 요약이 필요하다.
[제약] 메모에 있는 사실만 쓰고 추측은 하지 마라. 숫자·고유명사는 바꾸지 마라.
[출력형식] 표로 정리해라. 열은 '항목 / 현황 / 다음 조치', 5행 이내.
(여기에 회의 메모 본문 — 단, 민감정보는 제거하거나 가상값으로)
특히 제약에 "추측 금지·사실만"을 넣으면 할루시네이션을 줄이는 데 도움이 되고, 출력형식을 정하면 결과를 바로 문서에 붙일 수 있어 재가공 시간이 줄어듭니다.
네 요소를 한 줄씩 조립하면 막연한 "정리해 줘"가 바로 쓸 수 있는 초안으로 바뀝니다. 특히 제약에 "사실만·추측 금지"를 넣으면 할루시네이션이 줄고, 출력형식을 못 박으면 결과를 그대로 문서에 붙여넣을 수 있어 재가공 시간이 사라집니다.
넣어도 되는 정보, 절대 넣으면 안 되는 정보
입력 전에 멈추고 분류한다
생성형 AI에 무언가를 입력하는 순간, 그 내용은 외부 서비스의 서버로 전송됩니다. 회사·고객사의 민감정보를 그대로 넣으면 정보 유출, 계약 위반, 개인정보보호법 위반으로 이어질 수 있습니다. 그래서 입력 전에 이 정보가 나가도 되는 것인가를 한 번 멈추고 분류하는 습관이 필요합니다.
| 분류 | 예시 | 처리 원칙 |
|---|---|---|
| 입력 금지 | 고객사 실명, 계약 단가·조건, 운영 서버 실제 로그, 개인정보(주민번호·연락처·계좌) | 외부 AI에 절대 입력 금지. 필요하면 마스킹·가상값으로 대체 |
| 승인 필요 | 사내 내부 문서, 미공개 일정·구성도, 식별 가능한 사내 정보 | 사내 AI 사용 정책 확인 후, 승인된 범위에서만 |
| 비교적 안전 | 공개된 표준·용어 정의, 일반적 문장 다듬기, 가상 예시 데이터 | 민감정보가 없는지 한 번 더 확인 후 사용 |
실무에서는 이렇게 합니다. 고객사 이름은 'A사', 단가는 'XXX원', 로그의 IP·계정은 가상값으로 바꿔 입력합니다. 형식과 문장만 AI에게 다듬게 하고, 진짜 값은 결과를 받은 뒤 사람이 채워 넣습니다. 그러면 AI의 도움을 받으면서도 민감정보는 회사 밖으로 나가지 않습니다.
회사마다 규정이 다릅니다. 사내 AI 사용 정책(어떤 도구를 허용하는지, 무엇을 입력해도 되는지, 승인이 필요한지)을 먼저 확인하는 것이 모든 것에 앞섭니다.
직접 해보기 — 4요소 프롬프트 만들고 검증하기
아래 막연한 지시를 4요소(역할·맥락·제약·출력형식)를 갖춘 프롬프트로 다시 써 보세요. 단, 입력할 회의 메모에는 민감정보가 없도록 가상값으로 바꾸는 것까지 포함합니다.
막연한 지시:
"이 회의 내용 정리해 줘."
(회의 메모 원문에는 고객사 실명과 담당자 연락처가 들어 있다고 가정)
직접 해야 할 일은 세 가지입니다. (1) 역할·맥락·제약·출력형식을 각각 한 줄로 적는다. (2) 메모의 고객사 실명·연락처를 가상값(A사, 010-0000-0000)으로 바꾼다. (3) 결과를 받은 뒤 무엇을 사람이 확인할지 미리 정한다. 예시 답은 ObserveBlock에 있습니다.
역할 + 맥락 + 제약 + 출력형식- 역할 한 줄 예: "너는 IT 운영팀 PM 보조다."
- 맥락 한 줄 예: "주간 운영 회의 메모를 임원 보고용으로 정리한다."
- 제약 한 줄 예: "메모에 있는 사실만, 추측 금지, 고유명사는 그대로, 5줄 이내."
- 출력형식 한 줄 예: "표로 — 열은 항목·현황·다음 조치, 5행 이내."
- 민감정보 처리: 고객사 실명 → "A사", 담당자 연락처 → "010-0000-0000" 등 가상값으로 치환한 뒤 입력했는가
- 결과 검증 항목: 표 안의 날짜·숫자·고유명사가 원본 메모와 일치하는지 사람이 한 줄씩 대조했는가
- 핵심 감각: 프롬프트가 좋아져도 "사실 확인"은 사라지지 않는다 — 형식은 AI, 사실은 사람
현장에서 자주 보는 함정
증상: AI에게 주간 보고 초안을 시켰더니 표가 깔끔하게 나왔습니다. 그대로 임원 보고에 올렸는데, 회의에서 "이 장애 건수 숫자 어디서 나온 거냐", "이 협력사 이름이 왜 여기 있냐"는 지적을 받았습니다. AI가 그럴듯하게 지어낸 숫자와 이름이었습니다.
원인: 생성형 AI는 사실을 보증하지 않고 통계적으로 그럴듯한 문장을 만듭니다(할루시네이션). 형식이 깔끔해 보이면 사람은 내용도 맞다고 착각하기 쉽습니다. "AI가 만들었으니 맞겠지"라는 검증 생략이 진짜 원인입니다.
해결 방향:
- 틀리면 안 되는 사실(숫자·날짜·고유명사·인용·명령어)은 원본(공식 문서·실제 로그·시스템 화면)으로 사람이 교차 확인한다.
- AI에게 "확실해?"라고 다시 묻는 것은 검증이 아니다 — 같은 거짓을 반복할 수 있다.
- 프롬프트 제약에 "메모에 있는 사실만, 없는 값은 비워 둬라"를 넣어 지어내기를 줄인다.
- 외부에 나가는 최종 보고의 책임은 사람에게 있다 — AI는 초안, 검토·승인·제출은 사람.
AI는 시간을 아껴 주지만, 책임까지 대신 져 주지는 않습니다. 빨라진 만큼 확보된 시간을 "사실 확인"에 쓰는 것이 안전하게 빨라지는 방법입니다.
한국 SI·운영(SM) 현장에서 생성형 AI는 빠르게 업무 도구로 들어오고 있지만, 동시에 정보 유출 사고의 새로운 통로이기도 합니다. 실제로 사내 코드·고객사 자료를 외부 AI에 넣었다가 유출로 번진 사례가 알려지면서, 많은 기업이 사내 AI 사용 정책을 만들고 허용 도구·금지 정보·승인 절차를 규정합니다.
PM·운영 담당으로 일한다면 두 가지를 항상 기억하세요. 첫째, 고객사 정보·계약·실제 로그·개인정보는 외부 AI에 입력하지 않는다 — 개인정보보호법과 고객사 계약(보안 서약)을 위반할 수 있고, 책임은 입력한 사람과 회사에 돌아옵니다. 둘째, 회사의 AI 사용 정책을 먼저 확인한다 — 어떤 도구가 허용되는지, 무엇을 넣어도 되는지, 승인이 필요한지는 회사마다 다릅니다.
AI를 잘 쓰는 관리자는 "AI에게 다 맡기는 사람"이 아니라, AI로 초안을 빠르게 뽑되 사실과 보안은 사람이 통제하는 사람입니다. 협력사 보고를 검토할 때도 "이 숫자는 어디서 확인했나"를 물을 수 있어야, AI가 지어낸 값에 속지 않습니다.
이 트랙이 가르치는 한 문장으로 마무리합니다. "AI는 초안 작성자이지 결정권자가 아니다. PM의 일은 줄어드는 게 아니라 검증·판단으로 이동한다." 2026년 거버넌스 기조도 AI를 "능력"이 아니라 **"신뢰성·거버넌스"**로 평가합니다. 무엇을 어느 도구에 넣을지(데이터 분류), 어떤 일에 어떤 AI를 쓸지(라우팅), 결과를 누가 검증할지(휴먼 인 더 루프) — 이 세 가지를 설계하는 것이 AI 시대 관리자의 핵심 역량입니다.
관련 모듈로 더 깊이:
- AI로 회의록·문서 자동화 — 이 기본기를 회의록·문서 자동화에 곧바로 적용하는 첫 실전
- 고급 프롬프트 패턴과 AI 도구 연계 — 여러 AI 도구를 업무에 안전하게 연계하는 큰 그림과 보안 경계
- 정보보안 관리 — AI 입력 시 지켜야 할 정보보안·개인정보 통제의 원리
다음 모듈에서는 이 기본기를 실제 업무에 적용해, AI로 회의록·문서 자동화 — 음성/메모를 회의록으로, 회의록을 액션 아이템·보고 초안으로 빠르게 바꾸는 실무 흐름을 다룹니다.