실패 시나리오 미리 써 보기

원인이 다른 시나리오 3개(문서 최신성 · 아무도 안 씀 · 열람 권한)가 나왔고, 셋 다 "위키를 그대로 가져온다"는 한 문장으로 거슬러 올라갔다.

시나리오 3 — 볼 수 없는 문서가 답에 섞여 나왔다 최초의 결정: "위키를 그대로 가져온다"와 "전사에 연다"를 함께 정하면서 권한을 누가 반영할지 정하지 않은 것 그때 보였던 신호: 예산에 API 사용료만 있고 보안 검토 몫이 없다는 점

성공 기준은 사용률인데 계획 항목은 전부 만드는 일에만 배정돼 있다는 공통 원인이 마지막에 나왔다.

프리모템 프롬프트가 막으려는 것은 낙관입니다. 계획서를 주고 "어떻게 생각해?"라고 물으면 좋은 점 세 가지와 "다만 일정이 촉박할 수 있습니다" 정도가 돌아옵니다. 이미 실패했다고 못 박고 시작하면 대답의 방향 자체가 바뀝니다. 원인을 찾아야 하는 사람은 좋은 점을 적을 이유가 없기 때문입니다.

첫 문단의 역할은 조언자가 아니라 사후 분석 담당자입니다. 조언자는 균형을 맞추려 들지만, 조사관은 어긋난 지점만 찾습니다. 맥락 문단이 이 프롬프트의 핵심입니다. "실패할 수도 있다"가 아니라 "이미 실패했다"고 시제를 바꿔 두면, 모델이 가능성을 저울질하는 대신 경위를 서술하기 시작합니다.

단계 문단은 증상에서 최초의 결정까지 거슬러 올라가게 합니다. 실패 원인을 그냥 물으면 "리소스 부족" 같은 마지막 증상에서 멈춥니다. 네 칸을 순서대로 채우게 하면 그 부족이 어느 결정에서 시작됐는지까지 나오고, 오늘 바꿀 수 있는 것은 대개 그 첫 결정 쪽에 있습니다.

형식 문단이 시나리오를 세 개로 나눈 이유는 원인이 한 갈래로 몰리는 것을 막기 위해서입니다. 하나만 쓰게 하면 가장 뻔한 일정 이야기에서 끝나 버립니다. 서로 원인이 달라야 한다는 조건을 붙이면 기술, 사람, 외부 사정처럼 다른 축이 나옵니다. 마지막의 공통 원인 문단은 세 이야기가 결국 같은 곳을 가리킬 때 그것을 눈에 보이게 해 줍니다. 시나리오마다 예방책을 두 개로 묶은 것도 의도입니다. 열 개를 받아 봤자 오늘 시작하는 것은 하나도 없습니다.

이렇게 물으면 칭찬 두 문단에 "일정이 다소 촉박해 보입니다" 한 줄이 붙어 옵니다. 실패 원인 미리 찾기와는 거리가 먼 결과입니다. 지적이 나와도 계획서에 적힌 표현을 되돌려 주는 수준이라, 정작 계획서에 아예 빠져 있는 것은 끝까지 드러나지 않습니다.

"실패했다"는 가정을 무시하고 성공 요인을 함께 적어 주는 경우가 있습니다. 그럴 때는 "성공 요인은 빼고 실패 경위만 다시 써 줘"라고 이어서 요청하세요.