JKH

Essay · 4분

내 자동화를 4개 AI 페르소나로 심사했더니, 가장 아픈 한 방은 '나' 자신이 날렸다

AI 4명에게 내 자동화 PoC를 평가시켰다. 셋은 기술 위험을 짚었고, '6개월 뒤에도 이걸 쓸까'를 짚은 건 나를 시뮬레이션한 페르소나 하나였다. 그날 이후 모든 설계 리뷰에 '나'를 한 명 넣는다.

진짜 BLOCKING을 짚은 건 누구였나

내가 만든 글쓰기 자동화 PoC를, 출시 전에 AI 페르소나 4명을 동시에 띄워 심사에 부쳤습니다. 시니어 자동화 엔지니어, 보안 검토자, 콘텐츠 전략가, 그리고 6개월 뒤의 나를 그대로 시뮬레이션한 페르소나 한 명. 각자 다른 렌즈로 같은 시스템을 찢어보게 했습니다.

세 외부 페르소나는 정확히 자기 직무대로 "기능적 위험"을 잡았습니다.

  • 엔지니어: measurement·복구·운영 비용
  • 보안: NDA·credentials·incident response
  • 콘텐츠 전략가: 톤 일관성·자동 발행 신뢰성

안전한 시스템 설계의 표준 체크리스트이고, 셋 다 맞는 말이었습니다. 그대로 반영하면 "잘 동작하는" 시스템이 나왔을 겁니다.

그런데 누구도 짚지 못한 게 있었습니다.

"이 시스템이 6개월 후에도 사용될까?" "회사 스프린트 시즌에도 매일 7분이 가능한가?" "한 달 쉬었다가 다시 시작할 동기가 있는가?"

이 질문들은 시스템이 동작하는지가 아니라 살아남는지를 묻습니다. 외부 페르소나의 모범 답변지에는 없는 항목입니다.

답을 짚은 건 본인 페르소나였습니다.

"honest_likelihood_of_sustained_use: 35%" "내가 가장 두려운 건 검토 부담이 아니라 회사 정보 유출 1건이다."

왜 '나' 페르소나만 이걸 봤나

외부 페르소나 셋은 "오늘 출시되는 시스템"을 봅니다. 평일 9시-6시 가상 시나리오에서 잘 돌아가는지를 검증하죠. 반면 '나' 페르소나는 그 시스템 안에서 6개월을 살아야 하는 사람의 시점에 섭니다.

차이는 거기서 나왔습니다. 스프린트 마감 주의 압박, 회의 폭증, 휴가 빈도 — 진짜 회사 일정은 나만 압니다. 새 시스템에 대한 흥미가 첫 2주에 정점을 찍고 누적적으로 식는다는 것도, 자동화가 떠넘긴 검토 부담을 30일째의 내가 견딜 수 있는지도, 솔직하게 답할 수 있는 건 나뿐입니다. 외부 페르소나의 모범 답안지에는 이 항목 자체가 없습니다.

"지속률 35%"라는 숫자가 의미하는 것

본인 페르소나가 "지속률 35%"라고 적었다는 건 이런 의미입니다.

  • 14일 PoC 중 약 5일만 실제 운영할 것
  • 사이클이 깨지면 다시 시작할 동기 없음
  • 회사 일정에 밀리면 자연 중단

세 외부 페르소나가 "기술적으로 완벽"이라고 결론 내려도, 본인이 "안 쓸 것 같다"고 하면 시스템 가치는 0입니다. 35%는 BLOCKING입니다. 아니, 외부 페르소나가 짚을 수 없는 차원의 BLOCKING이라 더 위험합니다.

이게 보이지 않으면, "기능적으로 완벽한 시스템을 만들고 6개월 후 폐기"가 반복됩니다. 자동화 시스템의 흔한 묘지 패턴입니다.

시스템 설계에 본인 페르소나를 포함하는 패턴

오늘 이후 저는 시스템 설계 시 다음 패턴을 적용하기로 했습니다.

외부 페르소나 N명 + 본인 페르소나 1명.

본인 페르소나는 다른 페르소나와 다른 출력을 냅니다.

honest_likelihood_of_sustained_use: 35%  ← 정량 추정
honest_concern: "이게 진짜로 무서운 부분이다"  ← 솔직한 우려
fail_cases: [
  "회사 스프린트 마감 주에 3일 연속 스킵 → 영구 중단",
  "redaction false positive 누적 → 회피 행동 시작"
]

핵심은 honest_concern입니다. 외부 페르소나의 top_3_fixes는 "이걸 어떻게 고칠까"입니다. 본인 페르소나의 honest_concern은 "이걸 만들지 말까"입니다. 두 출력이 충돌하면 후자가 우선입니다.

35%를 받았다고 폐기하지는 않았다

그렇다고 '나' 페르소나를 맹신하지는 않습니다. 자칫하면 모든 제안이 "그냥 안 만드는 게 낫다"로 끝나 진전이 멈춥니다. 사람은 자기 행동을 평균적으로만 맞히기 때문에 "지속률 35%"는 실제로 60%일 수도, 15%일 수도 있죠. 그래서 외부 페르소나의 "어떻게든 만들어야"와 반드시 교차 검증을 겁니다.

대신 35%를 폐기 사유가 아니라 재설계의 출발점으로 씁니다. "35%인 이유가 manual 트리거를 까먹기 때문이라면, passive trigger와 알림을 붙여 70%까지 끌어올릴 수 있는가?" — 이렇게 BLOCKING 하나를 잡고 시스템을 다시 짜자, 외부 페르소나만으로는 보이지 않던 sustainable한 설계가 나왔습니다.

결론

시스템이 돌아갈지는 AI가 알지만, 시스템이 살아남을지는 그걸 매일 써야 하는 내가 압니다. 그래서 나는 잘 돌아가는 PoC를 만드는 데서 멈추지 않고, 그걸 6개월 뒤에도 쓰게 만드는 데까지 책임지는 사람으로 일합니다 — 그날 이후 모든 설계 리뷰에 '나'를 한 명 넣은 이유입니다.