Claude와 Codex를 활용하여 프리모템 (Premortem)을 사용하는 방법
요약
LLM을 활용해 계획의 실패를 가정하고 원인을 분석하는 '프리모템(Premortem)' 프롬프팅 기법을 소개합니다. 단순한 검토를 넘어, 모델이 실패 시나리오를 재구성하도록 유도하여 숨겨진 리스크와 엣지 케이스를 효과적으로 찾아내는 방법을 다룹니다.
핵심 포인트
- 단순 검토 대신 '이미 실패했다'고 가정하는 프레임워크 사용
- 코딩 결정(마이그레이션, 인증 변경 등) 시 리스크 최소화
- 모델의 과도한 긍정 편향을 방지하고 구체적인 실패 원인 도출
- 아이디어 구상 및 제품 출시 전 잠재적 결함 파악
저는 다소 지루한 이유로 프리모템 (premortems)을 사용하기 시작했습니다. 바로 기본 검토 질문을 신뢰하지 못했기 때문입니다.
코딩 에이전트 (coding agent)에게 "이 계획이 괜찮아 보이나요?"라고 물으면, 답변은 보통 유용하지만 지나치게 정중합니다. 계획이 작동할 수 있는 이유를 찾아내고, 몇 가지 엣지 케이스 (edge cases)를 인지하며, 깔끔한 개선 사항 목록을 제공합니다. 좋습니다.
하지만 구현 경로를 선택하거나, 아이디어를 발표하거나, 인증 (auth)을 변경하거나, 데이터를 이동하거나, 에이전트가 대규모 디프 (diff)를 작성하게 하기 직전에 제가 원하는 체크는 그것이 아닙니다.
그 시점에서 제가 원하는 것은 결정을 무너뜨리려고 시도하는 두 번째 검토입니다.
그래서 저는 프리모템 (premortem)을 요청하기 시작했습니다.
프레임 (The frame)
이 방법은 제 것이 아니라 Gary Klein의 것입니다. 그는 2007년 Harvard Business Review에 프로젝트 프리모템 (project premortems)에 대해 썼습니다. Daniel Kahneman은 나중에 이 기술을 과도한 자신감에 저항하는 실질적인 방법으로 지목했습니다. 아이디어는 간단합니다. 계획이 이미 실패했다고 가정하고, 그 이유를 설명하는 것입니다.
LLM (Large Language Models)에서는 그 작은 변화가 중요합니다.
약함:
이 계획이 좋은가요?
더 나음:
지금으로부터 6개월이 지났습니다. 이 계획은 실패했습니다.
어떻게 이런 일이 일어났는지 설명하세요. 구체적으로 말해주세요.
두 번째 프롬프트 (prompt)는 모델에게 다른 업무를 부여합니다. 모델은 더 이상 계획을 승인하는 것이 아니라, 실패를 재구성하는 것입니다.
"무엇이 잘못될 수 있을까요?"라는 질문은 종종 일반적인 리스크 목록을 제공합니다. 반면 "이것은 이미 실패했습니다. 왜일까요?"라는 질문은 저에게 이야기를 들려줍니다. 첫 번째 균열. 숨겨진 가정. 제가 아마도 무시했을 신호. 제가 설계하는 것을 잊어버린 롤백 (rollback).
그것이 실행에 옮기기가 더 쉽습니다.
활용 분야
저는 두 가지 상황에서 두 번째 체크로서 프리모템 (premortems)을 사용합니다.
첫째, 코딩 결정입니다.
모든 코드 변경에 이것이 필요한 것은 아닙니다. 저는 계획을 변경하는 비용은 아직 저렴하지만, 나중에 되돌리는 비용은 비싼 경우에 이를 사용합니다. 예를 들어 마이그레이션 (migrations), 인증 (auth) 변경, 데이터 모델 (data model) 변경, 릴리스 계획 (release plans), 많은 파일을 건드릴 수 있는 에이전트 워크플로우 (agent workflows), 또는 충분한 마찰 없이 "그래, 이 정도면 괜찮겠지"라고 말하려는 모든 상황이 이에 해당합니다.
둘째, 아이디어입니다.
기사 작성, 작은 오픈 소스 출시, 또는 제품 아이디어에 시간을 쏟기 전에, 무엇이 그것을 조용히 실패하게 만들지 자문합니다. "이것이 흥미로운가?"가 아니라, "6주 뒤에 아무도 관심을 갖지 않는다면, 무슨 일이 일어난 것인가?"라고 묻습니다. 이는 대개 제가 쓰려고 했던 주제보다 더 나은 문제를 표면 위로 끌어올려 줍니다.
이것은 안목 (taste), 테스트 (tests), 리뷰 (review), 또는 사람들과 대화하는 것을 대체하는 것이 아닙니다. 계획이 굳어지기 전의 저렴한 추가 점검일 뿐입니다.
왜 이것을 스킬 (skill)로 패키징했는가
저는 그동안 프레임워크 (frame)를 수동으로 다시 입력해 왔습니다. 효과는 있었지만 일관성이 없었습니다. 때로는 너무 모호하게 질문했고, 때로는 답변이 일반적인 목록이 되도록 방치했습니다. 때로는 모델이 마지막에 계획을 수정하도록 강제하는 것을 잊기도 했습니다.
그래서 작은 스킬을 만들었습니다:
https://github.com/PabloNAX/premortem-skill
이미 시중에 다른 프리모템 (premortem) 프롬프트와 에이전트 워크플로우 (agent workflows)들이 나와 있습니다. 저는 제가 실제로 Claude Code와 Codex를 사용하는 방식에 맞춰 이것을 만들었습니다:
- 채팅 내에서의 짧은 출력
- HTML 보고서 없음
- 중요한 실패 모드 (failure mode)당 하나의 조사
- 마지막에 수정된 계획과 체크리스트 제공
채팅 출력 방식이 중요합니다. 결과가 제가 따로 열어봐야 하는 별도의 보고서가 되면 나중에 읽게 되고, 이는 종종 영원히 읽지 않는 것을 의미합니다. 저는 계획이 머릿속에 남아 있는 동안 동일한 대화 맥락 안에서 비판을 받고 싶습니다.
이 스킬이 하는 일
이 스킬은 구체적인 계획을 기대합니다. 계획이 너무 모호하면, 내용을 지어내는 대신 누락된 컨텍스트 (context)를 요청합니다.
그런 다음 실패 프레임 (failure frame)을 실행합니다:
- 계획이 이미 실패했다고 가정합니다.
- 계획과 일치하는 실패 모드 (failure modes)를 생성합니다.
- 중요한 모드들을 별도로 조사합니다.
- 결과를 짧은 채팅 답변으로 합성 (synthesize)합니다.
제가 원하는 출력물은 다음과 같이 간단합니다:
가장 발생 가능성이 높은 실패 (most likely failure)
가장 위험한 실패 (most dangerous failure)
숨겨진 가정 (hidden assumption)
...
그 후에는 특정 부분에 대해 더 깊이 파고들 수 있습니다:
롤백 실패 (rollback failure)에 대해 더 자세히 조사해줘.
마이그레이션 시작 전까지 시간이 두 시간밖에 없다고 가정해줘.
코딩 예시 (Coding example)
한 가지 사이드 프로젝트 예시를 들자면: 주말 동안 작은 앱을 SQLite에서 Postgres로 옮기고 싶었습니다. 스테이징 환경 없이 혼자 진행하는 작업이었고, 몇 달 치의 실제 로컬 데이터가 있었습니다.
일반적인 검토(review)라면 아마도 덤프(dump), 복구(restore), 테스트, 그리고 백업 유지를 권했을 것입니다. 맞는 말이지만, 충분히 날카롭지는 않았습니다.
프리모템 (premortem)을 통해 더 유용한 실패 시나리오를 얻을 수 있었습니다:
가장 발생 가능성이 높은 실패 (Most likely failure)
SQLite의 느슨한 타이핑 (loose typing)으로 인해 Postgres가 거부하거나 다르게 강제 변환 (coerce)하는 행(row)들이 허용되었습니다.
임포트(import)는 대부분 괜찮아 보이지만, 전환 (cutover) 후에 몇몇 레코드가 잘못됩니다.
...
이 중 어느 것도 생소한 것이 아닙니다. 바로 그것이 핵심입니다. 제가 가장 간과하기 쉬웠던 지루한 실패 요인을 찾아낸 것입니다. 롤백 경계 (rollback boundary)가 마이그레이션을 시작하기도 전에 계획을 수정하게 만들었습니다.
아이디어 예시 (Idea example)
저는 이 기술을 해당 기술 자체의 출시 계획 (launch plan)에도 적용해 보았습니다.
유용한 포착 사항은 간단했습니다: 리포지토리 (repo)는 아이디어를 설명했지만, 출력물이 어떤 모습인지는 보여주지 않았습니다. 방문자는 설치 명령어와 텍스트는 보겠지만, 실제 경험에 대한 증거는 볼 수 없을 것입니다. 이 점이 README를 바꾸게 만들었습니다. 저는 짧은 터미널 데모를 녹화하여 상단 근처에 배치했습니다.
또한 이 과정은 제가 생각하던 지표 (metric)에 대해서도 재고하게 만들었습니다. 저는 GitHub 스타 (stars)를 생각하고 있었습니다. 프리모템은 스타가 세기도 쉽고 잘못된 방식으로 최적화하기도 쉽다는 점을 지적했습니다. 더 나은 신호는 몇 명의 사람들이 실제 계획에서 이를 시도해 보고, 출력물이 어디서 잘못되었는지 저에게 알려주는 것이 될 것입니다.
제가 원하는 비판은 바로 그런 종류입니다. 거창한 철학적 논쟁이 아니라, 제가 아이디어의 잘못된 버전에 더 많은 시간을 쏟기 전에 이루어지는 작은 수정 말입니다.
질문하는 방법
입력값은 구체적이어야 합니다.
약한 예시:
내 스타트업 아이디어에 대해 프리모템 (Premortem)을 해줘.
더 나은 예시:
이 출시 계획에 대해 프리모템 (Premortem)을 해줘:
나는 프리모템 (Premortem)을 위한 Claude/Codex 스킬을 출시하려고 해.
대상: 이미 코딩 에이전트 (coding agents)를 사용 중인 개발자들.
...
이렇게 하면 모델이 검토할 수 있는 대상(audience), 목표(goal), 채널(channel), 제약 사항(constraint), 그리고 실패 조건(failure condition)을 제공하게 됩니다.
코딩의 경우도 마찬가지입니다. "내 마이그레이션에 대해 프리모템 (Premortem)을 해줘"는 약합니다. "이 SQLite에서 Postgres로의 마이그레이션에 대해 프리모템 (Premortem)을 해줘. 단독 작업이며, 스테이징 (staging) 환경은 없고, 롤백 (rollback)이 필요함"이라고 하는 것이 유용합니다.
시도해보기
Claude Code용 설치:
git clone --depth 1 https://github.com/PabloNAX/premortem-skill && ./premortem-skill/install.sh claude
대신 Codex용 설치:
git clone --depth 1 https://github.com/PabloNAX/premortem-skill && ./premortem-skill/install.sh codex
저는 여전히 에이전트 (agents)에게 계획을 검토해달라고 요청합니다. 다만 이제는 거기서 멈추지 않을 뿐입니다. 중요한 결정의 경우, 계획이 이미 실패했다고 가정하고 에이전트가 그 이유를 나에게 말해주는 추가적인 단계를 한 번 더 거치고 싶습니다.
출처
- Gary Klein, "Performing a Project Premortem," Harvard Business Review, 2007. https://hbr.org/2007/09/performing-a-project-premortem
- Daniel Kahneman, Thinking, Fast and Slow, 2011.
- D. J. Mitchell, J. E. Russo, N. Pennington, "Back to the future: Temporal perspective in the explanation of events," Journal of Behavioral Decision Making, 1989.
- M. Sharma et al., "Towards Understanding Sycophancy in Language Models," Anthropic, 2023. https://arxiv.org/abs/2310.13548
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기