실제로 나의 업무 방식을 변화시킨 30가지 프롬프트 (그리고 실패한 것들)

지난 11월, 나는 처음부터 제품 사양서(product spec)를 작성하는 데 3시간을 보냈다. 꽤 괜찮은 작업이었다. 그런데 한 팀원이 내가 불렛 포인트(bullet points)만 주면 Claude에게 4분 만에 초안을 작성해달라고 할 수 있었다는 점을 지적했다. 나는 그 시간 내내 다른 탭에 Claude를 띄워놓고 있었다. 그 순간 내 머릿속의 무언가가 깨졌다. AI가 사양서를 쓸 수 있어서가 아니라, 내가 "내가 하는 진짜 업무"와 "AI를 사용하는 일" 사이에 심리적 장벽을 세웠기 때문이다. AI에 관한 대부분의 생산성 조언은 이 장벽을 다루지 않는다. 이 포스트는 그것을 다룬다.

대부분의 AI 프롬프트 리스트가 가진 문제점

그것들은 AI를 한 번도 사용해 본 적 없는 사람들을 위해 작성되었다. "ChatGPT에게 이메일을 요약해달라고 하세요!" 멋지다. 당신은 이미 2년 전부터 그렇게 해왔다. 당신은 그런 것을 보러 온 게 아니다.

개발자와 파워 유저(power users)들에게 실제로 유의미한 변화를 주는 것은, 현재 수동으로 하고 있지만 그것이 수동이라는 사실조차 인지하지 못하고 있는 워크플로우(workflows)를 대체하는 프롬프트들이다. 2019년부터 자동 항법 장치(autopilot)로 실행해 온 기본 설정들 말이다. 목표는 사고를 외주 주는 것이 아니다. 통찰력(insight) 대신 상투적인 인지 작업(boilerplate cognition)을 생성하고 있는 일주일 중 30가지 지점을 찾아내는 것이다.

다음은 나의 업무와 다른 빌더(builders)들을 관찰하며 수집한 내용이다. 얼마나 인상적으로 들리는가가 아니라, 맥락(context)에 따라 정리했다.

아침의 명확성과 계획 (프롬프트 1–8)

이것들은 복리 효과가 가장 크게 나타나는 것들이다. 대부분의 사람들은 이것이 일기 쓰기처럼 사치스럽게 느껴져서 건너뛰곤 한다. 하지만 그렇지 않다.

1. "이것은 나의 오늘 할 일 목록이다. 작성된 방식에 근거하여, 내가 가장 미루기 쉬운 항목 하나를 식별하고 그 이유를 말해줘."

2. "나에게는 4시간의 딥 워크(deep work) 시간이 있다. 여기 나의 작업들이 있다. 의사 결정 피로(decision fatigue)가 가장 낮을 때 가장 어려운 인지 작업을 수행할 수 있도록 작업 순서를 배치해줘. 내가 업무 시작 시점에 가장 명석하다고 가정해라."

3. "이 작업들을 활동 중심 문장(activity statements)이 아닌 결과 중심 문장(outcome statements)으로 다시 작성해줘." (예: "문서 작성하기"를 "주니어 개발자들이 나에게 묻지 않고도 온보딩할 수 있도록 문서를 배포하기"로 변환)

4. "[프로젝트]에서 가장 큰 진전을 이루기 위해 내가 오늘 반드시 답해야 하는 단 하나의 질문은 무엇인가?"

5. "[문제]에 대해 막혀 있는 기분이야. 해결책이 아니라, 실제 문제가 무엇일지에 대한 세 가지 재구성(Reframes)을 제시해줘."

6. "지난주에 내가 계획했던 것과 실제로 한 일이야. 어떤 패턴이 보여?"

7. "나를 위한 5분 스탠드업(Standup) 초안을 작성해줘. 내가 작업한 내용은 다음과 같아. 미화하지 말고 솔직하게 작성해줘."

8. "만약 오늘 8시간이 아니라 2시간만 있다면, 오늘의 계획에서 무엇을 뺄 것인가?"

프롬프트 6번은 제가 가장 오래 거부해왔던 것이지만, 이제는 매주 월요일마다 실행하고 있습니다. 이 프롬프트는 제가 시도했던 그 어떤 회고(Retrospective) 형식보다도 자기기만(Self-deception)을 더 빠르게 잡아냅니다.

딥 워크(Deep Work)와 글쓰기 (프롬프트 9–16)

이 영역은 대부분의 파워 유저들이 머무는 곳입니다. 함정은 AI를 당신을 '대신해서' 글을 쓰는 데 사용하는 것입니다. 그렇게 하면 당신의 목소리가 담기지 않은 결과물이 나오며, 회의실에서 그 내용을 방어할 수 없게 됩니다. 더 나은 패턴은 어려운 사고(Hard thinking)를 하기 전후의 마찰(Friction)을 줄이는 데 AI를 사용하는 것입니다.

9. "[대상]을 작성해야 해. 시작하기 전에, 결과물을 더 좋게 만들 수 있는 질문 다섯 가지만 나에게 해줘. 아직 아무것도 작성하지 마."

10. "이것은 나의 초안이야. 다시 쓰지 말고, 내 논리가 가장 취약한 부분이 어디인지 말해줘."

11. "이 문서 전체가 증명하려고 하는 단 하나의 문장은 무엇인가? 내가 의도한 것이 아니라, 내가 실제로 쓴 내용에서 그 문장을 추출해줘."

12. "이 문서에서 내가 취하고 있는 입장과 반대되는 입장을 스틸맨(Steelman, 상대의 논리를 가장 강력한 형태로 재구성하는 것) 해줘."

13. "이 글은 기술적인 독자를 대상으로 작성했어. 이제 구현(Implementation)이 아닌 결과(Outcomes)에 관심이 있는 사람에게 맞게 내용을 조정해줘."

14. "내 글이야. 내가 불필요하게 말을 흐리고(Hedging) 있는 부분이 어디지? 모든 '일지도 모른다(might)', '할 수도 있다(could)', '잠재적으로(potentially)'와 같은 표현에 표시를 하고, 내가 실제로 더 강력한 주장을 믿고 있는 것인지 알려줘."

15. "이 포스트를 위한 다섯 가지 제목 옵션을 생성해줘. 그중 두 개는 불편하게 만들어줘. 내가 게시하기를 망설일 정도로 말이야."

16. "이 글을 읽고 말해줘: 회의적인 독자가 이 글을 묵살하기 위해 어떤 근거를 사용할 것 같은가?"

프롬프트 16은 셀 수 없을 정도로 여러 번 저를 당혹스러운 게시물로부터 구해 주었습니다. 게시 버튼을 누른 후가 아니라, 누르기 전에 실행하세요.

코드, 시스템, 그리고 기술적 작업 (프롬프트 17–23)

개발자들은 메타 레벨 (meta-level)에서의 AI 활용은 저평가하는 경향이 있는 반면, 오브젝트 레벨 (object level)에서의 활용은 과하게 하는 경향이 있습니다. 네, AI가 함수를 작성할 수는 있습니다. 하지만 더 가치 있는 점은, 함수를 작성해야 하는지 여부 자체를 판단하는 데 도움을 줄 수 있다는 것입니다.

17. "내가 구축하려는 기능은 다음과 같습니다. 내 가정이 맞는지 확인하기 위한 가장 단순한 버전은 무엇인가요?"

18. "이 PR (Pull Request)을 버그가 아니라, 6개월 뒤에 내가 후회할 만한 요소들을 중심으로 리뷰해 주세요."

19. "[시스템]을 리팩터링 (refactor)하려고 합니다. 시작하기 전에 내가 아직 파악하지 못했을 가능성이 있는 정보는 무엇인가요?"

20. "내가 고려 중인 세 가지 접근 방식은 다음과 같습니다. 하나를 추천하지 말고, 내가 올바른 선택을 하기 위해 답해야 할 질문이 무엇인지 알려주세요."

21. "구현 (implementation) 전에 테스트를 작성해 주세요. 내가 필요로 하는 동작은 다음과 같습니다."

22. "이 코드가 무엇을 하는지 쉬운 언어로 설명한 다음, 이 코드가 무엇을 '가정'하고 있는지 알려주세요. 숨겨진 입력값, 환경적 의존성(environmental dependencies), 조용히 문제를 일으킬 수 있는 요소들 말입니다."

23. "[문제]를 디버깅 (debugging) 중입니다. 내가 시도해 본 것들은 다음과 같습니다. 내가 아마도 무시했을 법한, 가장 지루하고 당연한 설명은 무엇인가요?"

프롬프트 23은 자존심을 우회하는 도구입니다. 지루하고 당연한 것이 거의 항상 정답입니다.

결정, 전략, 그리고 사고 (프롬프트 24–30)

이것은 대부분의 사람들이 아직 탐구하지 않은 카테고리입니다. AI에게 실제 제약 조건 (constraints)을 부여하고 낙관적으로 대답하라고 요구하는 것을 멈춘다면, AI는 구조적 추론 (structured reasoning)에 놀라울 정도로 능숙합니다.

24. "나는 [A]와 [B] 사이에서 결정하려고 합니다. 내가 명시하지 않았지만 전제하고 있는 가정들을 나열해 주세요."

25. "[내가 기울이고 있는 결정]이 틀렸다는 것을 증명하려면 나는 무엇을 믿어야 합니까?"

26. "내가 보내려는 이메일입니다. 수신자가 실제로 이 글을 어떻게 읽을까요? 내가 집중하지 않는 부분 중 그들이 집중하게 될 부분은 무엇인가요?"

27. "관계를 망치지 않으면서 [요청]에 대해 거절하고 싶습니다. '거절'은 명확하면서도 관계는 유지될 수 있도록 글을 쓰는 것을 도와주세요."

28. "제 계획은 이렇습니다. 사전 사후 분석 (pre-mortem)을 해주세요. 지금으로부터 6개월 뒤, 무엇이 이 계획을 망쳤을까요?"

29. "결정을 내리는 대신 조사를 하고 있음으로써, 내가 회피하고 있는 결정은 무엇인가요?"

30. "제가 [대상]에 대해 과도하게 생각하고 있습니다 (overthinking). 제가 앞으로 나아갈 수 있도록, 지금 바로 취해야 할 가역적인 기본 행동 (reversible default action)은 무엇인가요?"

29번 프롬프트는 뼈아픈 질문입니다. 저는 일주일에 한 번씩 저 자신에게 이 질문을 던집니다.

이 프롬프트들을 실제로 활용하기 위한 프레임워크

5단계 테스트 (The 5-Layer Test) — 프롬프트를 정기적인 워크플로우 (workflow)에 추가하기 전에 다음을 질문해 보세요:

• 이것이 현재 내가 수동으로 수행하는 작업을 대체하는가?
• 결과물이 나에게 사고를 요구하는가, 아니면 모델이 나를 대신해 사고하는가?
• 결과물을 다시 읽지 않고도 회의에서 방어할 수 있는가?
• 20분 이상의 시간을 절약해주거나 의사결정을 가능하게 하는가?
• 실패 없이 최소 세 번 이상 사용해 보았는가?

만약 프롬프트가 2번 항목에서 실패한다면 — 즉, 모델이 말하는 것을 그대로 수용하기만 한다면 — 그것은 도구가 아니라 지팡이 (crutch)일 뿐입니다. 이 목록에 있는 프롬프트들은 당신을 다시 운전석으로 돌려보내기 위해 설계되었습니다. 이 프롬프트들은 단순히 답을 내놓는 것이 아니라, 더 나은 질문을 생성합니다.

또한, AI 상호작용을 일괄 처리 (batch) 하세요. 10분마다 채팅창으로 컨텍스트 스위칭 (context-switching)을 하는 것은 몰입 (flow)을 해칩니다. 저는 오전 프롬프트는 한 번에 처리하고, 글쓰기 프롬프트는 전용 세션 동안 수행하며, 의사결정 프롬프트는 하루 일과를 마치는 검토 시간에 사용합니다. 이 규율은 프롬프트에 관한 것이 아니라, AI를 전혀 사용하지 않는 시간을 보호하는 것에 관한 것입니다.

AI Handler가 이 문제에 접근하는 방식

제가 AI Handler를 만드는 이유는 기존의 어떤 도구도 실제 문제를 해결하지 못하기 때문입니다. 당신은 훌륭한 프롬프트들을 가지고 있고 — 어쩌면 그것들로 가득 찬 Notion 문서도 있을 것입니다 — 그럼에도 불구하고 적절한 워크플로우 컨텍스트 (workflow context)에서 적절한 프롬프트를 띄워주는 시스템이 없기 때문에 여전히 그것들을 일관되게 사용하지 못하고 있습니다.

AI Handler는 프롬프트가 주제(topic)가 아닌 _워크플로우 상태(workflow state)_에 따라 정리되어야 한다는 아이디어를 중심으로 구축되었습니다. 계획 모드(planning mode)에 있을 때는 계획 관련 프롬프트를 띄워줍니다. PR(Pull Request)을 리뷰할 때는 이를 인지합니다. 무언가를 초안 작성(drafting)할 때는 이미 사용자의 글쓰기 선호도와 과거 피드백이 로드되어 있습니다. 모델 컨텍스트(model context)가 사용자를 따라다니는 것이지, 사용자가 컨텍스트를 따라가는 것이 아닙니다.

위의 30가지 프롬프트는 개별적으로도 강력합니다. 하지만 이 프롬프트들이 컨텍스트를 기억하고, 출력을 체이닝(chaining)하며, 실제로 사용하는 도구들 전반에 걸쳐 통합되는 시스템의 일부가 될 때 그 효과는 복리로 작용합니다.

그것이 바로 제가 만들고 있는 것입니다. 공개적으로 말이죠. 모든 당혹스러운 피벗(pivots) 과정까지 포함해서 말입니다.

AI Handler는 제가 만들고 있는 통합 AI 워크플로우(workflow) 도구입니다. 2026년 6월 출시 예정입니다. 베타 액세스 권한을 원하시면 ceo@eternalsix.com으로 이메일을 보내주세요.