PM 이야기 목록으로
PM 이야기

AI가 엉뚱한 결과를 낼 때, 먼저 의심할 곳은 우리가 준 맥락이다

요지

  • AI 에이전트에게 맡긴 일이 엉뚱하게 돌아왔다면 모델을 탓하기 전에 우리가 넘긴 작업 설명과 문서부터 점검해 볼 만합니다. 그 점검 기준을 다섯 가지로 묶은 틀이 CAFE(S)입니다.
  • 틀은 개발자 경험 연구 회사 DX의 연구에서 나왔고, 2026년 9월 24일 Atlassian 블로그가 소개했습니다. Atlassian이 만든 틀은 아닙니다.
  • 출처마다 다루는 범위가 조금 다릅니다. 이 글에서 PM 업무로 넓혀 읽은 부분은 우리 해석입니다.

무엇이 바뀌었나

CAFE(S)는 Brian Houck, Max Kanat-Alexander, Eirini Kalliamvakou, Margaret-Anne Storey, Nicole Forsgren이 만든 틀로, ACM Queue에 실렸다고 DX가 밝혔습니다. 항목 이름은 원문대로 두고, 항목마다 PM이 확인할 것을 우리 말로 적으면 이렇습니다.

  • Clarity: 작업 설명을 처음 보는 사람이 다른 뜻으로 읽을 여지가 남아 있지 않은지 봅니다.
  • Actionability: 무엇을 내놓으면 끝인지, 손대지 말아야 할 범위가 어디인지 적혀 있는지 봅니다.
  • Fidelity: 넘기는 문서가 최신 승인본인지, 문서끼리 숫자와 날짜가 어긋나지 않는지 봅니다.
  • Efficiency: 이번 작업과 상관없는 자료가 섞여 판단을 흐리지 않는지 봅니다.
  • Security: 에이전트가 보면 안 되는 자료가 섞이지 않았는지, 외부에서 들어온 문서에 숨은 지시(프롬프트 주입)가 없는지 봅니다.

Atlassian 글은 맥락 파일 검토와 출처마다 책임자 두기 같은 실천 방법도 함께 제안합니다.

범위는 출처마다 다르게 읽힙니다. DX의 ACM Queue 게재 소개 글은 제목에서 코딩 에이전트를 대상으로 내세웁니다. DX 연구 페이지는 우리가 확인한 범위에서 대상을 코딩 에이전트로 좁혀 적지 않았고, Atlassian 글은 고객 상담 챗봇 같은 사례까지 다룹니다.

프로젝트에 무엇이 달라지나 (우리 해석)

PM(프로젝트 관리자)이 AI에게 넘기는 맥락은 대개 작업 항목 설명, 인수기준(acceptance criteria), 회의록, 계획 문서입니다. 다섯 항목을 여기에 대 보면 이렇습니다.

  • Clarity와 Actionability: 한 줄짜리 작업 설명과 인수기준 없는 백로그 항목은 사람에게도 모호합니다. AI는 모호한 곳을 되묻기보다 그럴듯하게 채우는 일이 많습니다. 그 품질 문제는 결과물에서 드러나 재작업 일정으로 돌아옵니다.
  • Fidelity: 승인된 일정 기준선(schedule baseline)과 지난달 초안이 같은 공간에 섞여 있으면 AI는 어느 것이 기준인지 모릅니다. 문서 버전 관리가 리스크 관리의 일부가 됩니다.
  • Efficiency: 회의록 전체를 통째로 넣는 습관은 비용은 늘리고 정확도는 떨어뜨릴 수 있습니다.
  • Security: 고객 자료나 계약 문서를 에이전트가 읽을 수 있는지는 권한 설계의 문제이고, 이해관계자와 맺은 정보 보호 약속과 직결됩니다.

어느 문서를 현재 기준으로 삼을지, 에이전트에게 무엇을 보여 줄지는 AI에게 맡길 판단이 아니라 PM이 정하고 책임질 일이라고 우리는 봅니다.

누구에게 맞고 언제 이른가

이미 AI를 작업 초안, 요약, 분류에 쓰고 있는데 결과가 들쭉날쭉한 팀에 맞는 점검표입니다. 반대로 AI를 아직 쓰지 않는 팀이 이 틀부터 도입할 필요는 없습니다. 그 경우에도 다섯 항목은 사람에게 주는 작업 지시를 점검하는 데 그대로 쓸 수 있다고 우리는 봅니다. 이 틀이 Rovo나 Jira 기능과 공식으로 연결된다는 설명은 확인되지 않았습니다.

PM과 PMO가 바로 할 일

  1. 다음 스프린트 계획 때 AI에게 맡길 작업 항목 몇 개를 골라 다섯 항목으로 점검해 봅니다.
  2. 작업 항목 양식에 목표, 제약, 인수기준 칸을 둡니다(Actionability).
  3. 프로젝트 공간에서 “현재 기준” 문서와 지난 초안을 나누고, 핵심 문서마다 관리할 사람과 점검 주기를 정합니다(Fidelity).
  4. AI가 읽을 수 있는 공간과 읽으면 안 되는 자료를 PMO 기준으로 정하고, AI에게 주는 공용 지침 문서는 고칠 때 다른 한 사람이 읽고 넘기게 합니다(Security).
  5. AI 결과를 다시 고친 일이 생기면 회고에서 원인이 맥락의 어느 항목이었는지 적습니다.

예를 들어 여러 공장 프로젝트를 맡은 제조업 PMO라면 먼저 표준 작업 양식 하나를 고치는 데서 시작하는 것이 부담이 적습니다.

참고(확인 2026-10-04)

혼자 배운다면 공개 과정, 팀 단위라면 기업 맞춤 출강이 있습니다. 프로젝트 관리 과정 보기 → 새 창

목록으로 돌아가기