4부 16장. 한 번에 끝내려 하지 말 것

많은 사람이 AI를 처음 쓸 때 가장 먼저 기대하는 장면이 있다. 한 번에 길고 정교한 요청을 넣고, 곧바로 완성된 결과물을 받아내는 장면이다. 마치 자판기에 동전을 넣듯, 프롬프트를 넣으면 완성본이 나오는 식이다.

물론 가벼운 작업에서는 이런 방식도 잘 통한다. 짧은 요약, 간단한 문장 수정, 아이디어 몇 개 뽑기 같은 일은 한 번의 요청으로도 충분하다. 하지만 작업이 조금만 복잡해지면 상황이 달라진다. 보고서를 써야 하고, 기획안을 잡아야 하고, 자료를 비교해야 하고, 어조와 형식을 맞춰야 하는 순간부터, 한 번의 완성형 요청은 오히려 비효율적이 되기 쉽다.

이유는 단순하다. 복잡한 일은 처음부터 완전히 정의되어 있지 않기 때문이다. 무엇을 만들고 싶은지, 무엇이 중요한지, 무엇을 빼야 하는지, 어디까지가 괜찮고 어디서부터는 아닌지, 이런 기준은 일을 진행하면서 더 분명해진다. 다시 말해, 좋은 결과는 처음 한 번의 질문에서만 나오지 않는다. 여러 번의 상호작용 속에서 모양이 잡힌다.

이번 장에서는 왜 이제 AI를 한 번 답하는 기계가 아니라, 여러 턴에 걸쳐 함께 일하는 파트너처럼 써야 하는지 살펴보겠다. 핵심은 단순하다. 잘 쓰는 사람은 한 번에 끝내려 하지 않는다. 대신 일을 나누고, 확인하고, 고쳐 가며 전진한다.

왜 우리는 자꾸 한 번에 끝내고 싶어 할까

사람이 AI 앞에서 자꾸 완성형 요청을 만들려는 데에는 그럴 만한 이유가 있다. 검색 엔진에 익숙한 습관도 있고, 질문 한 번으로 정답을 얻고 싶은 마음도 있다. 무엇보다 여러 번 주고받는 것이 번거롭게 느껴진다. 괜히 말을 더 해야 할 것 같고, 시간이 더 걸릴 것 같고, 내가 설명을 잘 못하면 오히려 품질이 떨어질 것 같기도 하다.

그래서 많은 사용자가 이렇게 생각한다.

"내가 처음부터 완벽하게 말하면, AI도 완벽하게 답하겠지."

겉보기에는 매우 합리적인 생각이다. 하지만 실제 작업에서는 이 가정이 자주 무너진다. 왜냐하면 문제는 프롬프트가 짧아서가 아니라, 작업 자체가 아직 덜 정리되어 있어서 생기기 때문이다.

예를 들어 기획안을 쓰려는데 독자가 누구인지 아직 선명하지 않다. 보고서를 요약하려는데 어떤 기준으로 요약해야 하는지 애매하다. 글을 고치려는데 더 전문적으로 할지, 더 친근하게 할지, 더 짧게 할지, 무엇이 우선인지 스스로도 모호하다. 이런 상태에서 한 번의 요청으로 최종본을 뽑으려 하면, AI는 대체로 무난하고 평균적인 답을 내놓는다. 틀리지는 않지만, 딱히 쓸모가 크지도 않은 결과다.

즉, 한 번에 끝내고 싶어 하는 마음은 자연스럽지만, 복잡한 작업에서는 종종 잘못된 출발점이 된다.

복잡한 작업은 하면서 선명해진다

초보자는 종종 결과를 만들기 전에 목표가 완전히 정리되어 있어야 한다고 생각한다. 하지만 현실의 일은 반대인 경우가 많다. 써 보면서 주제가 선명해지고, 비교해 보면서 기준이 생기고, 고쳐 보면서 품질이 무엇인지 알게 된다.

AI와의 작업도 마찬가지다. 처음 요청은 출발점일 뿐, 모든 것을 확정하는 계약서가 아니다. 오히려 첫 요청의 역할은 완성본을 얻는 데 있다기보다, 문제를 바깥으로 꺼내는 데 있다.

예를 들어 이런 식이다.

처음에는 "이 주제로 발표 개요를 잡아줘"라고 시작한다. 그러면 AI가 몇 가지 방향을 제안한다. 그 순간 사용자는 비로소 자신의 기준을 발견한다. "아, 나는 설명형보다 설득형 구조가 좋구나." "이 예시는 너무 일반적이네." "청중 수준을 더 낮춰야겠어." 이런 판단은 요청 전에 완벽히 정리되어 있지 않았을 수 있다. 하지만 상호작용을 시작하면 금방 드러난다.

즉, 멀티턴 대화는 단지 결과를 조금씩 나누어 받는 방식이 아니다. 내가 무엇을 원하는지 더 잘 알게 되는 과정이기도 하다.

한 번의 완성형 요청이 자주 실패하는 이유

복잡한 작업에서 한 번의 요청이 자주 빗나가는 데에는 몇 가지 공통 이유가 있다.

• 숨은 기준이 많다.

• 중간 점검이 없다.

• 애매한 부분이 뒤늦게 드러난다.

• 결과를 고칠 기회가 늦게 온다.

먼저, 복잡한 일에는 생각보다 숨은 기준이 많다. 길이, 톤, 독자 수준, 형식, 금지 표현, 강조할 포인트, 피해야 할 주장 같은 것들이다. 처음부터 이 모든 것을 정확히 담아내기란 쉽지 않다.

다음으로, 한 번의 요청에는 중간 점검이 없다. 방향이 맞는지 확인하지 못한 채 곧바로 최종 결과로 가 버린다. 그러면 초반 가정이 조금만 어긋나도 결과 전체가 미끄러진다.

또한 애매한 부분은 보통 결과를 본 뒤에야 드러난다. 막상 받아 보니 너무 길거나, 너무 딱딱하거나, 핵심이 빠져 있거나, 전혀 엉뚱한 독자를 상정하고 있을 수 있다. 문제는 그때 가서야 비로소 진짜 기준을 알게 된다는 점이다.

마지막으로, 수정의 타이밍이 늦다. 처음부터 끝까지 한 번에 달려가면 잘못된 방향을 중간에 바로잡기 어렵다. 반대로 여러 턴으로 나누면, 틀린 방향을 초기에 고칠 수 있다.

결국 한 번의 완성형 요청은 효율적으로 보이지만, 실제로는 뒤늦은 재작업 비용을 키우기 쉽다.

멀티턴은 돌아가는 길이 아니라 제대로 가는 길이다

많은 사람이 여러 번 주고받는 방식을 비효율이라고 생각한다. 하지만 복잡한 작업에서는 오히려 그 반대다. 멀티턴은 일을 느리게 만드는 방식이 아니라, 헛수고를 줄이는 방식이다.

왜 그럴까. 첫째, 문제를 더 잘게 볼 수 있다. 전체를 한 번에 해결하려 하지 않고, 먼저 방향을 정하고, 그다음 구조를 만들고, 그다음 초안을 쓰고, 마지막으로 고친다. 이렇게 하면 각 단계에서 무엇을 확인해야 하는지가 분명해진다.

둘째, 품질을 올리는 기준이 생긴다. 처음에는 막연했던 요구가 대화 속에서 구체화된다. "좀 더 좋게"가 아니라 "전문 용어를 줄이고 사례를 앞에 배치해"처럼 수정 가능한 기준으로 바뀐다.

셋째, 사용자가 작업에 더 깊이 개입할 수 있다. 이때 개입은 귀찮은 일이 아니라 중요한 장점이다. AI가 혼자 달리도록 두는 대신, 사람이 중간에 방향을 잡아 주면 결과는 훨씬 쓸 만해진다.

그러므로 멀티턴은 AI를 덜 믿는 방식이 아니라, AI를 더 현실적으로 잘 쓰는 방식이라고 보는 편이 맞다.

좋은 결과는 보통 중간 산출물을 거친다

사람이 함께 일할 때도 그렇다. 처음부터 "최종본 주세요"라고 말하기보다, 보통은 초안부터 본다. 목차를 먼저 맞추고, 방향을 확인하고, 샘플을 보고, 수정 의견을 준다. AI와 일할 때도 이 상식은 그대로 적용된다.

중간 산출물은 생각보다 큰 힘을 가진다. 전체 보고서보다 목차가 먼저 필요할 수 있고, 전체 글보다 첫 단락 샘플이 더 중요할 수 있다. 발표 자료라면 전체 슬라이드보다 메시지 구조가 먼저 맞아야 한다. 코드 작업이라면 완성 코드보다 접근 방식과 위험 요소를 먼저 보는 편이 낫다.

중간 산출물을 보면 두 가지가 빨리 드러난다. 하나는 방향이 맞는지이고, 다른 하나는 내가 정말 중요하게 생각하는 기준이 무엇인지다. 이것이 드러나면 이후의 요청은 훨씬 좋아진다.

결국 작업의 질은 첫 질문의 화려함보다, 중간 결과를 보고 어떻게 다음 질문을 던지느냐에 더 크게 좌우된다.

한 번에 끝내면 안 되는 작업은 따로 있다

모든 작업을 여러 턴으로 해야 하는 것은 아니다. 간단한 정리나 짧은 변환은 한 번에 처리해도 된다. 하지만 아래와 같은 작업은 처음부터 멀티턴으로 접근하는 편이 훨씬 안전하다.

• 목표가 아직 애매한 작업

• 정답보다 판단이 중요한 작업

• 여러 제약을 동시에 만족해야 하는 작업

• 길이가 길거나 구조가 복잡한 작업

• 정확성 검토나 위험 점검이 필요한 작업

예를 들어 "이 글을 5줄로 요약해줘"는 한 번에 해도 된다. 하지만 "임원용 보고 메모를 만들되, 낙관적 톤은 피하고, 숫자는 보수적으로 쓰고, 반대 의견도 대비하게 해줘" 같은 요청은 여러 턴이 더 낫다. 글쓰기, 기획, 조사, 분석, 비교, 의사결정 지원 같은 일은 대개 처음부터 완성형으로 던질수록 평균적인 답으로 흐르기 쉽다.

특히 정답이 하나가 아닌 작업일수록 멀티턴이 중요하다. 이때는 맞고 틀리고의 문제가 아니라, 어떤 방향이 지금 상황에 더 맞는가가 핵심이기 때문이다.

먼저 큰 방향을 맞추고, 나중에 디테일을 다듬어라

복잡한 작업을 잘하는 사람은 처음부터 모든 디테일을 요구하지 않는다. 먼저 큰 방향부터 맞춘다. 이것은 생각보다 매우 실용적인 습관이다.

예를 들어 글을 쓴다고 해 보자. 처음 요청에서 바로 "완성 원고 2000자를 써줘"라고 하기보다, 먼저 "핵심 주장 세 가지와 전체 구조를 제안해줘"라고 물을 수 있다. 방향이 맞으면 그다음에 초안을 만들고, 초안이 맞으면 그다음에 문체를 조정하면 된다.

이 방식의 장점은 분명하다. 큰 방향이 틀렸을 때는 빨리 수정할 수 있고, 디테일은 나중에 다듬으면 된다. 반대로 처음부터 디테일까지 넣어 완성본을 받으면, 구조가 틀렸을 때 손봐야 할 양이 너무 많아진다.

쉽게 말해, 멀티턴은 "조금씩 만든다"기보다 비싼 실수를 초반에 막는다는 점에서 중요하다.

실전 예시: 보고서를 한 번에 쓰게 하지 말 것

보고서 작성은 한 번에 끝내려 할수록 자주 망가지는 작업이다. 사용자는 보통 이렇게 말하고 싶어진다.

"이 자료를 바탕으로 경영진 보고서를 써줘."

물론 AI는 그럴듯한 문서를 준다. 하지만 받아 보면 대개 이런 문제가 생긴다. 독자 수준이 안 맞고, 핵심 메시지가 흐리고, 강조 순서가 어긋나고, 내가 중요하게 보는 리스크가 약하게 다뤄진다.

이럴 때 더 나은 방식은 단계를 나누는 것이다.

먼저 "이 자료에서 경영진이 가장 궁금해할 쟁점이 무엇인지 세 가지로 정리해줘"라고 묻는다. 그다음 "그중 무엇을 1순위 메시지로 둘지 추천해줘"라고 묻는다. 이어서 "이 방향으로 1페이지 구조를 잡아줘"라고 요청한다. 구조가 맞으면 초안을 쓰게 하고, 마지막에 톤과 표현을 다듬는다.

같은 보고서라도 이렇게 가면 결과가 훨씬 실전적이다. 이유는 단순하다. AI가 처음부터 정답을 맞힌 것이 아니라, 사용자와 함께 기준을 맞춰 가며 만들었기 때문이다.

실전 예시: 공부할 때도 한 번의 설명으로 끝내지 말 것

학습에서도 마찬가지다. AI에게 "이 개념 설명해줘"라고 한 번 묻는 것만으로는 충분하지 않은 경우가 많다. 설명은 들었지만, 정말 이해했는지는 별개의 문제다.

이때 멀티턴은 매우 강력하다. 먼저 쉬운 설명을 듣고, 다음 턴에서 예시를 요청하고, 그다음에는 내가 이해한 내용을 말해 보게 하고, 마지막에는 틀린 부분을 교정받을 수 있다. 이렇게 하면 AI는 단순한 설명기가 아니라, 이해를 도와주는 학습 상대가 된다.

특히 어려운 개념일수록 한 번의 완벽한 설명보다, 설명-확인-질문-교정의 반복이 훨씬 효과적이다. 사람이 공부할 때도 질문을 주고받으며 이해가 깊어지듯, AI와의 학습도 그렇게 진행되는 편이 더 자연스럽다.

실전 예시: 글쓰기는 초안보다 수정에서 차이가 난다

AI로 글을 쓸 때 초보자는 초안 생성에만 집중한다. 하지만 실제 차이는 초안보다 수정 과정에서 크게 난다. 한 번에 초안을 받아 끝내는 사람과, 여러 턴에 걸쳐 다듬는 사람의 결과물은 전혀 다르게 나온다.

예를 들어 블로그 글을 쓴다고 해 보자. 한 번에 전체 글을 받아 보면 문장은 매끈할 수 있다. 하지만 독자의 수준에 안 맞거나, 도입이 밋밋하거나, 사례가 약하거나, 결론이 뻔할 수 있다. 이때 중요한 것은 새 글을 다시 통째로 뽑는 일이 아니라, 어느 부분을 왜 고칠지 분명히 말하는 것이다.

"도입부만 더 궁금증이 생기게 바꿔줘."

"두 번째 단락의 전문 용어를 더 쉬운 말로 바꿔줘."

"결론을 요약형이 아니라 행동 제안형으로 바꿔줘."

이런 식의 대화가 쌓이면 글은 점점 살아난다. 결국 좋은 글은 한 번에 생성된 결과라기보다, 여러 번의 선택과 수정이 누적된 결과에 가깝다.

좋은 사용자는 첫 질문보다 두 번째 질문을 잘한다

AI 활용 실력은 첫 프롬프트를 얼마나 멋지게 쓰느냐로만 갈리지 않는다. 오히려 진짜 차이는 두 번째 질문, 세 번째 질문에서 크게 난다.

좋은 사용자는 결과를 받고 나서 곧바로 이런 판단을 한다. 무엇이 맞았는가, 무엇이 어긋났는가, 무엇을 유지할 것인가, 무엇을 버릴 것인가. 그리고 그 판단을 바탕으로 다음 요청을 더 구체적으로 만든다.

반대로 익숙하지 않은 사용자는 결과가 애매해도 그냥 다시 "더 좋게 해줘"라고 말하기 쉽다. 하지만 이런 요청은 방향을 뚜렷하게 바꾸지 못한다. AI도 무엇이 문제였는지 정확히 모른 채 다시 평균적인 수정을 할 가능성이 크다.

그러므로 멀티턴의 핵심은 단지 대화를 많이 한다는 뜻이 아니다. 매 턴마다 판단을 남기고, 그 판단을 다음 턴의 입력으로 쓰는 것이다.

AI를 정답 기계가 아니라 작업 파트너로 보라

여기서 관점이 한 번 바뀌어야 한다. AI를 정답을 뽑아 주는 기계로만 보면, 사용자는 늘 한 번의 요청으로 끝내고 싶어진다. 하지만 AI를 함께 일하는 파트너로 보면, 자연스럽게 일하는 방식이 달라진다.

파트너와 일할 때는 보통 이런 흐름이 있다. 먼저 문제를 꺼내고, 방향을 이야기하고, 대략적인 안을 보고, 의견을 나누고, 다시 다듬는다. AI와의 멀티턴도 바로 그런 흐름에 가깝다.

물론 AI는 사람과 다르다. 책임을 지는 주체도 아니고, 스스로 목적을 세우는 존재도 아니다. 그렇지만 작업 방식의 측면에서는 충분히 협업 대상으로 다룰 수 있다. 특히 아이디어 정리, 초안 작성, 비교, 요약, 수정, 비평 같은 일에서는 더 그렇다.

이 관점이 생기면 질문도 달라진다. "한 번에 최고의 답을 뽑아내야지"가 아니라 "이번 턴에서 무엇을 진전시킬까"를 생각하게 된다. 이것이 멀티턴 활용의 출발점이다.

멀티턴 대화에서 중요한 것은 턴마다 역할이 다르다는 점이다

모든 턴이 같은 일을 할 필요는 없다. 어떤 턴은 탐색을 위한 것이고, 어떤 턴은 정리를 위한 것이며, 어떤 턴은 비평을 위한 것이다. 이 구분이 없으면 대화가 길어질수록 목적이 섞인다.

예를 들어 아이디어를 넓히는 단계에서 너무 빨리 최종안처럼 써 달라고 하면 생각의 폭이 줄어든다. 반대로 이미 구조가 정해졌는데도 계속 새로운 아이디어만 늘어놓으면 진도가 안 나간다. 결국 각 턴의 역할을 구분해야 한다.

이번 턴은 방향을 고르는 턴인지, 초안을 만드는 턴인지, 약점을 찾는 턴인지, 표현을 다듬는 턴인지가 분명해야 한다. 그래야 대화가 앞으로 나아간다.

이 점은 다음 장에서 더 자세히 다루겠지만, 지금 여기서 기억할 것은 하나다. 멀티턴이란 그냥 오래 대화하는 것이 아니라, 단계에 따라 다른 일을 시키는 방식이라는 점이다.

한 번에 끝내려는 습관이 만드는 착각

한 번의 요청으로 끝내려는 습관은 자주 두 가지 착각을 만든다.

첫째는 "결과가 길수록 잘한 것이다"라는 착각이다. 하지만 긴 답이 꼭 좋은 답은 아니다. 오히려 복잡한 작업에서는 짧은 구조안이나 비교표 하나가 긴 완성본보다 더 유용할 때가 많다.

둘째는 "처음 요청이 부족해서 실패했다"는 착각이다. 물론 프롬프트가 부실하면 문제가 생긴다. 하지만 실제로는 처음 요청이 부족해서라기보다, 중간 조정이 없어서 결과가 빗나가는 경우도 많다.

이 두 가지를 이해하면 마음이 한결 편해진다. 처음부터 완벽하게 말하지 못해도 괜찮다. 중요한 것은 결과를 보고 기준을 더 분명히 하고, 다음 턴에서 방향을 조정하는 일이다.

바로 써먹는 기본 원칙

복잡한 작업을 AI와 함께 할 때는 다음 원칙만 기억해도 품질이 눈에 띄게 달라진다.

• 처음부터 최종본을 요구하지 말고 방향부터 확인할 것

• 큰 구조를 먼저 맞추고 세부 표현은 나중에 다듬을 것

• 결과를 받으면 막연한 만족보다 구체적인 수정 기준을 말할 것

• 한 턴마다 무엇을 진전시키려는지 분명히 할 것

• AI의 답을 끝으로 보지 말고 다음 작업의 재료로 볼 것

이 원칙들은 거창한 기법이 아니다. 오히려 사람끼리 일할 때 너무나 당연해서 잘 의식하지 않는 상식에 가깝다. 그런데 AI 앞에만 서면 이상하게 이 상식을 잊고, 처음부터 완성본을 요구하게 된다. 실전에서는 그 반대가 더 잘 통한다.

이 장의 정리

복잡한 작업일수록 한 번의 완성형 요청보다 여러 차례의 상호작용이 더 효과적이다. 이유는 간단하다. 복잡한 일은 처음부터 완전히 정리되어 있지 않고, 작업을 진행하면서 목표와 기준이 더 선명해지기 때문이다.

한 번에 끝내려 하면 숨은 기준이 빠지고, 중간 점검이 사라지고, 수정 비용이 뒤늦게 커진다. 반대로 멀티턴으로 접근하면 방향을 먼저 맞추고, 중간 산출물을 확인하고, 점차 품질을 끌어올릴 수 있다. 이때 AI는 일회성 답변기가 아니라, 초안 작성과 정리, 비평과 개선을 함께 하는 협업 파트너에 가까워진다.

AI를 잘 쓰는 사람은 처음부터 완벽하게 말하는 사람이 아니다. 한 턴의 결과를 다음 턴의 발판으로 바꾸는 사람이다.

다음 장에서는 이 감각을 더 구체화해서, 멀티턴 대화를 어떤 순서와 구조로 설계하면 좋은지 살펴보겠다. 탐색하고, 정리하고, 초안을 만들고, 비평하고, 개선하는 흐름이 왜 강력한지 그때 본격적으로 다룰 것이다.