5부 21장. 프롬프트가 아니라 워크플로를 설계하라

많은 사람이 AI를 처음 배울 때 가장 먼저 묻는 것은 이것이다. "어떻게 질문해야 잘 대답할까?" 이 질문은 틀리지 않았다. 실제로 좋은 프롬프트는 꽤 큰 차이를 만든다. 같은 모델이라도 어떻게 지시하느냐에 따라 결과가 눈에 띄게 달라진다.

그런데 AI를 조금 더 오래 써 본 사람은 곧 다른 문제를 만나게 된다. 어제는 잘 됐던 프롬프트가 오늘은 애매해지고, 한 번 멋지게 나온 결과를 다시 재현하려니 생각보다 어렵다. 운 좋게 좋은 답을 받은 적은 있는데, 그걸 매번 같은 품질로 뽑아 내지는 못한다. 이 지점에서 비로소 중요한 질문이 바뀐다.

이제 질문은 "어떻게 한 번 잘 나오게 할까?"가 아니라, "어떻게 계속 잘 나오게 할까?"가 된다.

바로 여기서 프롬프트 중심 사고와 워크플로 중심 사고가 갈린다. 프롬프트 중심 사고는 좋은 문장을 찾는 데 집중한다. 반면 워크플로 중심 사고는 좋은 결과가 나오기까지의 흐름을 설계한다. 무엇을 먼저 하고, 어디서 점검하고, 어떤 입력을 넣고, 어떤 기준으로 고칠지를 정하는 것이다.

성과는 대개 한 줄짜리 마법의 프롬프트에서 나오지 않는다. 성과는 반복 가능한 작업 흐름에서 나온다.

왜 한 번의 좋은 답으로는 부족한가

우리는 종종 AI의 가장 인상적인 순간만 기억한다. 한 번에 근사한 초안이 나왔던 순간, 복잡한 내용을 말끔하게 정리해 준 순간, 생각보다 괜찮은 아이디어를 던져 준 순간 말이다. 이런 경험은 강력하다. 그래서 사람은 자꾸 "그때 썼던 그 프롬프트"를 찾게 된다.

하지만 실전에서는 그렇게 움직이지 않는 경우가 많다. 일을 하는 과정에는 늘 변수가 끼어든다. 목표가 조금 달라지고, 입력 자료가 바뀌고, 독자가 바뀌고, 형식이 바뀌고, 마감 시간이 달라진다. 그러면 어제 잘 먹혔던 프롬프트도 오늘은 어딘가 안 맞는다.

예를 들어 보고서 초안을 만든다고 해 보자. 누군가는 이렇게 생각할 수 있다.

"보고서 초안 작성 프롬프트 하나만 잘 만들어 두면 되지 않을까?"

처음에는 그럴듯하다. 하지만 실제 업무에서는 그 전에 해야 할 일이 많다. 먼저 자료를 모아야 하고, 무엇이 핵심인지 추려야 하며, 독자 수준을 정해야 하고, 원하는 형식을 맞춰야 한다. 초안이 나온 뒤에도 사실 확인, 문장 정리, 톤 조정, 길이 조절, 누락 점검이 따라온다. 즉, 결과물은 하나의 프롬프트가 아니라 여러 단계가 이어진 흐름 속에서 만들어진다.

그래서 AI 활용이 자꾸 들쭉날쭉하다면, 프롬프트를 더 영리하게 고치는 것만으로는 한계가 있다. 오히려 이런 질문을 던져야 한다.

• 이 작업은 어떤 순서로 진행되는가

• 각 단계의 목적은 무엇인가

• 어느 단계에서 AI를 쓰고, 어느 단계에서는 사람이 판단하는가

• 중간 결과는 어떻게 점검하는가

• 다음 번에도 같은 흐름으로 다시 실행할 수 있는가

이 다섯 가지를 보기 시작하면, AI는 "대답 잘하는 도구"에서 "작업 흐름의 일부"로 바뀐다.

워크플로란 무엇인가

워크플로는 어려운 말처럼 들리지만 뜻은 단순하다. 어떤 결과를 만들기 위해 거치는 일의 순서와 연결 방식이다.

아침에 커피를 내리는 일도 작은 워크플로다. 원두를 고르고, 갈고, 물 온도를 맞추고, 추출하고, 맛을 본다. 여기서 원두를 갈기도 전에 물부터 붓는 사람은 거의 없다. 순서가 있기 때문이다.

AI 작업도 똑같다. 그런데 많은 사람이 AI 앞에서는 순서를 잊는다. 갑자기 모든 걸 한 번에 시키려 한다. 조사도 하고, 요약도 하고, 기획도 하고, 초안도 쓰고, 검토도 해 달라고 한다. 물론 때로는 그럴 수도 있다. 하지만 대부분의 경우 결과가 흐려지는 이유는 AI가 멍청해서가 아니라, 작업 순서가 섞였기 때문이다.

워크플로를 설계한다는 것은 이 순서를 다시 세우는 일이다. 단순히 "좋은 답을 달라"고 말하는 것이 아니라, 일을 작게 나누고, 단계마다 기대하는 산출물을 정하고, 중간 점검 지점을 만드는 것이다.

쉽게 말하면 이런 차이다.

프롬프트 중심 사용자는 묻는다. "뭐라고 써야 잘 나올까?"

워크플로 중심 사용자는 묻는다. "이 일을 어떤 단계로 나누면 안정적으로 잘 끝낼 수 있을까?"

둘 다 중요하지만, 두 번째 질문이 실전에서 훨씬 오래 간다.

프롬프트는 부품이고, 워크플로는 설계도다

이 장에서 꼭 잡아야 할 감각이 하나 있다. 프롬프트는 워크플로의 일부이지, 워크플로 전체가 아니다.

이 비유로 생각해 보자. 프롬프트는 망치 같은 도구에 가깝다. 잘 쓰면 매우 유용하다. 하지만 집을 짓는 데 필요한 것은 망치 하나가 아니라 설계도와 공정 순서다. 기초를 놓고, 골조를 세우고, 배선을 하고, 마감을 해야 집이 완성된다.

AI 작업에서도 마찬가지다. 프롬프트는 각 단계에서 AI를 움직이는 지시문이다. 하지만 결과 품질을 좌우하는 것은 그 지시문 하나보다, 그 지시문이 언제, 어떤 입력과 함께, 어떤 기준 아래 사용되는가다.

그래서 같은 프롬프트라도 흐름 안에 넣으면 훨씬 강해진다. 예를 들어 "이 문서를 요약해 줘"라는 평범한 요청도 그냥 던질 때와 아래 순서로 쓸 때의 결과는 다르다.

먼저 문서의 목적을 확인한다. 그다음 독자가 누구인지 정한다. 이어서 무엇을 남기고 무엇을 버릴지 기준을 준다. 초안을 받은 뒤에는 누락된 핵심이 있는지 검토한다. 마지막으로 최종 형식에 맞게 다시 변환한다.

여기서 진짜 힘은 "요약해 줘"라는 한 문장에 있는 것이 아니라, 그 문장을 어떤 작업 흐름 속에 배치했는가에 있다.

잘하는 사람은 답변이 아니라 흐름을 관리한다

AI를 잘 쓰는 사람을 보면 공통점이 있다. 그들은 AI의 한 번 한 번의 답변에 일희일비하지 않는다. 대신 전체 흐름을 본다.

결과가 마음에 안 들면 "모델이 별로네"에서 멈추지 않는다. 어디서 문제가 생겼는지 본다. 입력이 부족했는지, 작업이 너무 크게 뭉쳐 있었는지, 중간 검토가 없었는지, 마지막 형식 변환이 빠졌는지 따져 본다. 즉, 그들은 답변을 소비하는 사람이 아니라 작업 시스템을 조정하는 사람에 가깝다.

이 차이는 생각보다 크다. 프롬프트 중심 사용자는 좋은 답이 나오면 만족하고, 안 나오면 답답해한다. 워크플로 중심 사용자는 좋은 답이 나오면 "왜 잘 됐지?"를 보고, 안 나오면 "어느 단계가 흔들렸지?"를 본다.

이렇게 보는 순간 AI 활용은 감에 의존한 요행이 아니라, 점점 다듬을 수 있는 작업 방식이 된다.

좋은 워크플로는 일을 단계로 바꾼다

좋은 워크플로의 첫 번째 특징은 일을 한 덩어리로 다루지 않는다는 점이다. 막연한 목표를 작고 분명한 단계로 바꾼다.

예를 들어 "블로그 글 쓰기"는 너무 큰 작업이다. 이걸 그대로 AI에 맡기면 글이 그럴듯해 보여도 어딘가 흔들리기 쉽다. 반면 이렇게 나누면 이야기가 달라진다.

• 글의 목적 정하기

• 독자 정하기

• 핵심 주장 한 문장으로 만들기

• 개요 만들기

• 섹션별 초안 쓰기

• 사실과 논리 점검하기

• 문체 다듬기

• 제목과 요약 만들기

이렇게 나누면 무엇이 좋아지느냐. 먼저 각 단계의 성공 기준이 분명해진다. 개요 단계에서는 구조가 중요하고, 초안 단계에서는 내용이 중요하며, 퇴고 단계에서는 표현과 흐름이 중요하다. 한 번에 다 잘하려 하지 않으니 AI도 덜 흔들리고, 사용자도 어디를 손봐야 하는지 알기 쉬워진다.

여기서 핵심은 단순 분해가 아니다. 각 단계마다 역할이 다르다는 점이다. 탐색 단계에서는 넓게 보고, 정리 단계에서는 줄이고, 작성 단계에서는 만들고, 검토 단계에서는 의심해야 한다. 이 역할 차이를 무시하면 한 대화 안에서 기준이 충돌한다.

워크플로는 품질뿐 아니라 재현성을 만든다

한 번 잘 나온 답보다 더 중요한 것은 다음에도 비슷하게 잘 나오느냐다. 이때 필요한 것이 재현성이다. 같은 종류의 작업을 반복할 때 품질이 크게 흔들리지 않는 상태 말이다.

워크플로가 있으면 재현성이 생긴다. 이유는 간단하다. 매번 기억에 의존하지 않고, 정해진 순서를 따라가기 때문이다. 자료를 넣는 방식, 초안을 받는 방식, 검토하는 방식, 최종본을 만드는 방식이 어느 정도 고정되면 결과도 안정된다.

반대로 워크플로가 없으면 매번 즉흥적으로 움직이게 된다. 오늘은 먼저 초안을 쓰고, 내일은 먼저 개요를 짜고, 어떤 날은 검토를 건너뛴다. 그러면 결과가 흔들리는 것이 이상하지 않다. 실력이 없는 것이 아니라, 구조가 없는 것이다.

이 점은 특히 실무에서 중요하다. 업무에서는 "가끔 잘함"보다 "대체로 안정적으로 잘함"이 더 가치 있다. 상사가 원하는 것도, 고객이 원하는 것도, 팀이 원하는 것도 결국 꾸준함이다. AI 활용도 똑같다. 감탄할 만한 한 번보다 믿고 맡길 수 있는 반복이 더 중요하다.

워크플로를 설계할 때 먼저 봐야 할 것

워크플로는 화려하게 만들 필요가 없다. 오히려 처음에는 소박해야 한다. 중요한 것은 복잡성이 아니라 흐름의 선명함이다.

처음 설계할 때는 최소한 다음 다섯 가지를 보자.

• 시작점: 이 작업은 무엇으로 시작되는가

• 중간 단계: 어떤 순서로 처리되는가

• 점검 지점: 어디서 멈추고 검토하는가

• 사람의 판단: 무엇은 사람이 최종 결정하는가

• 종료 조건: 어디까지 가면 끝난 것으로 보는가

이 다섯 가지가 있으면, 대충 감으로 하던 작업도 구조가 잡히기 시작한다.

예를 들어 회의 내용을 정리하는 작업이라면 시작점은 회의록과 녹취일 수 있다. 중간 단계는 핵심 안건 추출, 결정 사항 분리, 해야 할 일 정리다. 점검 지점은 누가 무엇을 언제까지 하는지 빠짐없이 들어갔는지 확인하는 순간이다. 사람의 판단은 우선순위나 민감한 표현 조정일 수 있다. 종료 조건은 공유 가능한 회의 요약본과 액션 아이템 목록이 완성된 상태다.

이렇게 보면 AI 활용이 훨씬 현실적인 일처럼 느껴진다. 실제로도 그렇다. AI는 마술사가 아니라 공정 안의 작업자다.

한 번에 다 시키면 왜 성과가 떨어지는가

초보자는 종종 이렇게 말한다. "어차피 AI가 똑똑한데, 그냥 한 번에 다 시키면 안 되나요?" 물론 가능할 때도 있다. 간단한 작업이라면 한 번에 끝내는 것이 빠르다. 문제는 조금만 복잡해져도, 한 번에 다 시키는 방식이 급격히 불안정해진다는 점이다.

그 이유는 크게 세 가지다.

첫째, 목표가 섞인다. 조사와 요약, 창작과 검토, 발산과 수렴은 서로 다른 모드다. 그런데 한 요청에 다 집어넣으면 AI는 어디에 힘을 줘야 할지 애매해진다.

둘째, 오류를 찾기 어렵다. 결과가 별로일 때 어디서 잘못됐는지 알 수가 없다. 입력이 나빴는지, 구조가 나빴는지, 검토가 빠졌는지, 표현이 문제였는지 추적이 안 된다.

셋째, 고치기 힘들다. 한 번에 다 만들어진 결과물은 수정할 때도 범위가 너무 넓다. 그래서 작은 문제를 고치려다가 전체가 다시 흔들린다.

결국 한 번에 다 시키는 방식은 빠른 듯 보이지만, 실패했을 때 복구 비용이 크다. 반대로 워크플로를 나누면 한 단계씩 개선할 수 있다. 어디서 틀어졌는지 보이고, 필요한 부분만 다시 돌릴 수 있다. 실전에서 강한 방식은 대개 후자다.

워크플로를 설계하면 AI의 약점도 관리할 수 있다

AI는 빠르고 유연하지만, 늘 안정적인 것은 아니다. 그럴듯한 말을 하지만 사실 확인이 부족할 수 있고, 긴 작업에서는 초점을 잃을 수 있으며, 문체나 기준이 미묘하게 흔들릴 수도 있다.

워크플로의 좋은 점은 이런 약점을 없애 주는 것이 아니라, 약점이 드러나도 관리 가능하게 만든다는 데 있다.

예를 들어 조사 단계와 작성 단계를 분리하면, 확인되지 않은 내용을 초안에 바로 섞는 일을 줄일 수 있다. 초안 단계와 검토 단계를 분리하면, 잘 써진 문장 때문에 허술한 논리가 가려지는 문제를 막을 수 있다. 최종 변환 단계를 따로 두면, 내용은 괜찮은데 형식 때문에 망하는 일도 줄어든다.

이 말은 곧 이런 뜻이다. 워크플로는 AI를 더 똑똑하게 만드는 기술이 아니라, AI를 더 믿을 수 있게 쓰는 기술이다.

작은 워크플로 하나가 큰 차이를 만든다

워크플로라고 하면 거대한 시스템을 떠올리는 사람이 많다. 무슨 자동화 도구를 붙이고, 파일을 연결하고, 여러 모델을 돌리고, 복잡한 규칙을 짜야 할 것처럼 느낀다. 물론 나중에는 그렇게 확장될 수 있다. 하지만 시작은 아주 작아도 된다.

예를 들어 이런 것만 있어도 이미 워크플로다.

자료를 넣기 전에 먼저 목적 한 문장을 적는다. 그다음 AI에게 자료의 핵심만 뽑게 한다. 이어서 그 핵심만 바탕으로 개요를 만든다. 개요를 승인한 뒤에만 초안을 쓰게 한다. 초안이 나오면 사실 점검과 문체 수정을 분리한다. 마지막에 최종 형식으로 변환한다.

이건 거창한 자동화가 아니다. 하지만 이런 작은 순서만 있어도 결과 품질은 크게 달라진다. 무엇보다 사용자 스스로가 덜 흔들린다. 지금 무엇을 해야 하는지 알기 때문이다.

실제로 많은 생산성 향상은 대단한 기능에서 나오지 않는다. 헷갈리던 일을 순서 있게 만든 것에서 나온다.

실전 예시: 프롬프트 사용자와 워크플로 사용자의 차이

같은 목표를 가진 두 사람이 있다고 해 보자. 둘 다 "신제품 소개 글"을 만들어야 한다.

프롬프트 사용자 A는 이렇게 요청한다.

"우리 제품의 장점을 살린 소개 글을 써 줘. 친근하고 설득력 있게."

운이 좋으면 꽤 괜찮은 글이 나온다. 하지만 제품 특징이 많거나, 대상 고객이 분명하거나, 채널별 형식이 달라지면 결과는 금방 흔들린다.

반면 워크플로 사용자 B는 흐름을 나눈다. 먼저 제품 핵심 가치 세 가지를 정리한다. 다음으로 목표 독자를 한 문장으로 정의한다. 그다음 소개 글의 목적이 판매인지, 관심 유도인지, 정보 제공인지 명확히 한다. 그 뒤에 구조를 만든다. 초안을 받은 뒤에는 과장 표현을 걷어 내고, 마지막에 블로그용인지 랜딩 페이지용인지 형식에 맞춘다.

둘 중 누가 더 화려한 프롬프트를 썼느냐는 중요하지 않다. B가 더 안정적으로 좋은 결과를 낼 가능성이 높은 이유는, 작업 흐름이 있기 때문이다.

A는 답을 받고 나서 반응한다. B는 답이 나오기 전에 구조를 만든다.

이 차이가 반복되면 성과 격차는 점점 커진다.

워크플로의 핵심은 중간 산출물이다

많은 사람이 최종 결과물만 본다. 하지만 실제로 좋은 워크플로는 최종본보다 중간 산출물을 잘 만든다.

중간 산출물이란 예를 들면 이런 것이다. 핵심 요약, 개요, 체크리스트, 비교표, 가설 목록, 검토 메모, 수정 지시문 같은 것들이다. 이들은 겉보기에 덜 화려하다. 그러나 바로 이런 것들이 전체 품질을 지탱한다.

중간 산출물이 중요한 이유는 두 가지다. 첫째, 점검이 쉬워진다. 개요가 이상하면 초안을 쓰기 전에 바로 잡을 수 있다. 둘째, 재사용이 가능하다. 한 번 잘 정리한 기준과 구조는 다음 작업에서도 다시 쓸 수 있다.

즉, 워크플로를 설계하는 사람은 최종본만 바라보지 않는다. 그 최종본이 잘 나오도록 도와주는 중간 결과들을 의도적으로 만든다.

이 습관이 생기면 AI 활용은 훨씬 안정된다. 매번 "잘 써 줘"라고 빌지 않아도 된다. 이미 잘 쓸 수밖에 없는 바닥을 깔아 두기 때문이다.

사람은 어디에 개입해야 하는가

워크플로를 설계할 때 자주 생기는 오해가 있다. "그럼 다 자동으로 돌리면 좋은 거 아닌가요?" 꼭 그렇지는 않다. 좋은 워크플로는 AI가 잘하는 것과 사람이 맡아야 하는 것을 나눈다.

AI는 빠르게 초안을 만들고, 대안을 많이 내고, 형식을 바꾸고, 긴 자료를 압축하는 데 강하다. 반면 사람은 목표를 결정하고, 우선순위를 정하고, 맥락상 중요한 예외를 판단하고, 최종 책임을 지는 데 강하다.

그래서 워크플로를 설계할 때는 "얼마나 많이 맡길까"보다 "어디서 사람이 개입해야 품질이 안정될까"를 봐야 한다. 보통은 시작점과 중간 점검, 마지막 승인에서 사람의 개입이 중요하다.

예를 들어 AI가 회의 정리 초안을 아주 빨리 만들 수는 있다. 하지만 민감한 표현을 순화할지, 어떤 결론을 공식 결정으로 적을지, 누구의 책임 범위를 어떻게 써야 할지는 사람이 확인하는 편이 안전하다. 이 구분이 없는 자동화는 편해 보여도 사고가 나기 쉽다.

좋은 워크플로는 AI를 많이 쓰는 흐름이 아니라, AI와 사람의 역할 분담이 또렷한 흐름이다.

처음부터 완벽한 워크플로를 만들 필요는 없다

여기서 겁먹을 필요는 없다. 워크플로 설계는 거대한 설계 프로젝트가 아니다. 처음에는 오히려 어설픈 버전이 필요하다. 지금 하고 있는 일을 대충이라도 단계로 적어 보는 것만으로도 시작된다.

가장 쉬운 방법은 최근에 AI로 했던 작업 하나를 떠올리는 것이다. 그리고 거꾸로 복기해 보는 것이다.

무엇을 하려고 했는가. 실제로는 어떤 순서로 했는가. 어디서 막혔는가. 어느 단계에서 결과가 좋아졌는가. 다음에는 어떤 순서를 고정하면 덜 흔들릴까.

이 질문에 답하다 보면 자연스럽게 개인 워크플로의 첫 버전이 나온다. 처음부터 정답일 필요는 없다. 중요한 것은 매번 즉흥적으로 하지 않게 되는 것이다.

워크플로는 한 번 설계하고 끝나는 것이 아니다. 써 보고, 막히고, 줄이고, 고치면서 좋아진다. 마치 자주 걷는 길이 점점 닦이는 것과 비슷하다.

바로 적용할 수 있는 가장 단순한 워크플로 틀

처음 시작하는 사람이라면 복잡하게 생각하지 말고 아래 틀만 기억해도 충분하다.

• 목표를 한 문장으로 적는다.

• 입력 자료를 모은다.

• AI에게 먼저 정리만 시킨다.

• 정리본을 보고 사람이 방향을 고른다.

• 그다음에 초안을 만든다.

• 초안과 검토를 분리한다.

• 마지막에 형식을 맞춘다.

이 일곱 단계는 놀라울 만큼 많은 작업에 적용된다. 글쓰기에도, 조사에도, 학습에도, 회의 정리에도 쓸 수 있다. 핵심은 초안 작성 전에 정리 단계가 있고, 최종본 전에 검토 단계가 있다는 점이다.

이 두 칸만 추가해도 AI 활용의 품질은 확 달라진다. 많은 실패가 사실은 모델의 문제가 아니라, 정리 없이 쓰고 검토 없이 끝내는 흐름에서 오기 때문이다.

이 장의 정리

AI를 잘 쓴다는 것은 좋은 프롬프트를 몇 개 외우는 일이 아니다. 진짜 차이는 반복 가능한 작업 흐름을 설계하는가에서 난다.

프롬프트는 여전히 중요하다. 하지만 그것은 부품이다. 성과를 만드는 것은 부품 하나가 아니라, 입력을 받고, 정리하고, 만들고, 검토하고, 마무리하는 전체 흐름이다. 한 번 멋진 답을 받는 것보다, 다음에도 비슷한 품질을 안정적으로 얻는 것이 실전에서는 훨씬 중요하다.

이제부터는 AI에게 무엇을 말할지만 보지 말고, 일을 어떤 순서로 굴릴지를 보기 시작해야 한다. 그러면 AI는 그때부터 대화 상대를 넘어 성과를 만드는 작업 시스템이 된다.

다음 장부터는 이런 관점을 바탕으로, 실제로 자주 쓰게 되는 워크플로들을 하나씩 살펴볼 것이다. 먼저 조사형 작업부터 보자. 정보를 찾고, 비교하고, 정리하는 흐름을 어떻게 설계해야 하는지 알게 되면, AI 활용은 훨씬 덜 운에 맡겨지고 훨씬 더 실무적이 된다.