무엇을 만들지 막막할 때, AI와 나누는 변증법적 대화

만들고 싶은 것은 분명히 있는데, 막상 AI 앞에 앉으면 무슨 말부터 해야 할지 막막했던 적이 있으신가요. 머릿속에는 어떤 그림이 떠다니는데 그것을 한 문장으로 옮기려 하면 자꾸 흐릿해집니다. 이건 실력이 부족해서가 아닙니다. 아이디어가 아직 말로 옮길 만큼 또렷한 형태를 갖추지 못했을 뿐입니다.

다행히 이 막막함을 푸는 오래된 방법이 있습니다. 무려 2400년 전, 소크라테스가 쓰던 대화법입니다. 여기서는 그 방법을 빌려, 지치지 않는 대화 상대인 AI와 주고받으며 흐릿한 아이디어를 만들 수 있는 형태로 바꾸는 과정을 차근차근 짚어보겠습니다.

진짜 막히는 지점은 코딩이 아닙니다

바이브코딩은 사람이 코드를 직접 쓰는 대신, AI에게 만들고 싶은 것을 말로 설명하면 AI가 코드를 대신 작성해주는 방식입니다. 이 방식 덕분에 코드를 짜는 일 자체는 예전보다 훨씬 쉬워졌습니다. 그런데 막상 시작하려 하면 코딩이 아닌 다른 곳에서 막힙니다. 바로 무엇을 만들지를 정하는 단계입니다.

이건 새로운 고민이 아닙니다. 소프트웨어 공학의 고전인 책에서 프레드 브룩스는 이렇게 말했습니다. 시스템을 만드는 가장 어려운 단 하나의 부분은, 정확히 무엇을 만들지 결정하는 일이라고요. 코드를 짜는 것보다 무엇을 만들지 정하는 것이 더 어렵고, 여기서 잘못 출발하면 나중에 바로잡기도 가장 어렵다는 뜻입니다.

바이브코딩은 코드를 짜는 비용을 거의 0으로 만들었지만, 무엇을 만들지 정하는 어려움까지 없애주지는 못했습니다. 오히려 코딩이 쉬워진 만큼, 무엇을 만들지가 또렷한 사람과 막연한 사람의 결과물 차이는 더 벌어집니다.

우리는 원하는 것을 정확히 말하지 못합니다

IT 업계에는 오래된 말이 있습니다. 고객은 자기가 무엇을 원하는지 본인도 모른다는 것입니다. 사람들은 자신의 불편함에 대해 정확한 원인보다 감정을 먼저 기억합니다. 택시 앱이 불편했던 이유는 배차 거부, 느린 화면, 불친절한 응대처럼 여러 가지일 텐데, 막상 입에서 나오는 말은 그냥 이 앱 별로다 한마디입니다.

자주 인용되는 일화가 하나 있습니다. 자동차왕 헨리 포드가, 사람들에게 무엇을 원하냐고 물었다면 더 빠른 말이라고 답했을 거라고 말했다는 이야기입니다. 사람들은 자동차라는 새로운 형태를 상상하지 못한 채, 익숙한 말이 더 빨라지기만을 바랐을 거라는 뜻입니다. 다만 이 말은 포드가 실제로 했다는 근거가 분명하지 않은, 출처가 불확실한 격언입니다. 그래도 사람들이 본 적 없는 것을 스스로 떠올리기 어렵다는 핵심만큼은 또렷하게 짚어줍니다.

이 점은 실제로 여러 사람이 비슷하게 말했습니다. 스티브 잡스는 1998년 한 인터뷰에서, 많은 경우 사람들은 직접 보여주기 전까지 자신이 무엇을 원하는지 모른다고 했습니다. 제품 전문가 마티 케이건도, 고객은 무엇이 가능한지 모르며 기술 제품에서는 실제로 보기 전까지 우리 중 누구도 진짜 원하는 것을 알지 못한다고 정리했습니다.

여기서 한 가지를 구분하면 오해가 풀립니다. 사람들은 자신이 겪는 문제는 압니다. 다만 그 문제를 푸는 해결책의 모습, 특히 본 적 없는 형태의 해결책은 말로 그려내지 못합니다. 그러니 우리가 막막한 것도 당연합니다. 만들고 싶은 욕구는 있지만, 그것이 어떤 형태여야 하는지는 아직 모르는 상태이기 때문입니다.

왜 머릿속 생각을 말로 다 옮기지 못할까요

철학자 마이클 폴라니는 이 현상을 한 문장으로 정리했습니다. 우리는 말할 수 있는 것보다 더 많이 안다는 것입니다. 자전거 타는 법을 몸은 알지만 글로 다 설명하기 어렵듯이, 우리가 아는 것의 상당 부분은 말로 또렷하게 옮겨지지 않는 암묵지(暗默知, 말로 표현하기 어렵지만 몸과 감각으로 아는 지식)입니다.

그래서 머릿속 아이디어를 한 번에 정확한 설명으로 옮기려 하면 자꾸 빠지는 부분이 생깁니다. 자연어로 적은 요구사항은 본래 모호하고, 빠진 곳이 많고, 앞뒤가 어긋나기 쉽습니다. 이건 글솜씨의 문제가 아니라, 생각이라는 것이 원래 한 번에 완성된 모습으로 떠오르지 않기 때문입니다.

소프트웨어 업계에서 오래 돌아다닌 그림이 하나 있습니다. 고객이 설명한 그네, 분석가가 이해한 그네, 개발자가 만든 그네가 저마다 전혀 다른 모습으로 그려지고, 정작 고객이 진짜 원했던 것은 밧줄에 매단 단순한 그네였다는 풍자입니다. 작자가 누구인지도 모른 채 수십 년 떠돈 이 그림이 오래 사랑받는 이유는, 말로 옮기는 과정에서 생각이 얼마나 쉽게 어긋나는지를 정확히 보여주기 때문입니다.

소크라테스는 답을 주지 않고 질문했습니다

그렇다면 흐릿한 생각을 어떻게 또렷하게 만들까요. 여기서 소크라테스의 방법이 등장합니다. 그는 무언가를 가르쳐주는 사람이 아니었습니다. 오히려 자신은 아는 것이 없다고 말하면서, 끊임없이 질문만 던졌습니다.

소크라테스는 자신의 방법을 산파술(産婆術, 아이를 받는 산파의 기술)이라고 불렀습니다. 그의 어머니가 실제로 산파였다는 데서 따온 비유입니다. 산파가 아이를 대신 낳아주지 않고 산모가 잘 낳도록 돕듯이, 자신도 지식을 넣어주는 것이 아니라 상대 안에 이미 있는 생각이 밖으로 나오도록 돕는 사람이라는 뜻입니다.

방법은 단순합니다. 상대가 어떤 주장을 하면, 소크라테스는 그가 동의할 만한 다른 질문들을 던져서 처음 주장과 어긋나는 지점을 함께 발견합니다. 이 과정에서 안다고 믿었던 것을 사실은 정확히 설명하지 못한다는 막다른 길에 다다릅니다. 이 막힘의 순간을 그리스 사람들은 아포리아라고 불렀는데, 이건 실패가 아니라 출발점입니다. 어설픈 확신이 무너져야 비로소 또렷한 생각이 들어설 자리가 생기기 때문입니다.

참고로 변증법이라고 하면 흔히 정-반-합을 떠올리지만, 그 표현은 사실 헤겔이 직접 쓴 말이 아니라 후대가 붙인 요약입니다. 어원으로 보면 변증법은 그저 대화하다라는 말에서 나왔고, 소크라테스의 방식은 거창한 공식이라기보다 질문을 주고받으며 생각을 받아내는 산파술에 가깝습니다.

AI는 지치지 않는 대화 상대입니다

이 문답에는 한 가지 조건이 필요합니다. 끈질기게 되물어주는 대화 상대입니다. 예전에는 이런 상대를 구하기 어려웠습니다. 사람을 붙잡고 같은 아이디어를 몇 시간씩 반박해달라고 부탁하기는 미안하니까요. 그런데 지금은 지치지 않고 몇 번이든 되물어주는 상대가 생겼습니다. 바로 AI입니다.

여기서 흔한 오해를 하나 짚고 가면 좋겠습니다. 많은 사람이 AI를 답을 주는 기계로만 씁니다. 무엇을 만들어달라고 하면 바로 결과물을 받는 식이지요. 하지만 아이디어가 아직 흐릿할 때는, AI를 답을 주는 기계가 아니라 함께 생각을 다듬는 대화 상대로 쓰는 편이 훨씬 낫습니다. 산파에게 아이를 대신 낳아달라고 하지 않듯이 말입니다.

AI를 산파로 쓰는 네 가지 방법

막연한 아이디어를 또렷하게 만드는 대화에는 몇 가지 잘 알려진 방법이 있습니다. 어렵지 않습니다. 핵심은 AI가 나에게 질문하고 반박하도록 방향을 바꾸는 것입니다.

첫째, AI가 나에게 질문하게 하세요

가장 효과가 좋은 방법은 질문의 방향을 뒤집는 것입니다. 내가 AI에게 묻는 게 아니라, AI가 나에게 묻게 하는 것이지요. 연구자들은 이걸 뒤집힌 대화라고 이름 붙였습니다. AI가 던지는 질문에 답하다 보면, 미처 생각하지 못한 부분을 자연스럽게 떠올리게 됩니다.

개발자 하퍼 리드가 공유해 널리 퍼진 프롬프트가 있습니다. 핵심은 한 번에 하나씩 묻게 하는 것입니다. 질문이 한꺼번에 쏟아지면 쉬운 것만 골라 답하고 어려운 부분은 넘어가게 되거든요. 다음 문장을 그대로 붙여넣고 시작해보세요.

한 번에 하나씩 질문해 주세요. 이 아이디어에 대한 충분한 명세를
단계적으로 함께 만들어 갑시다. 각 질문은 제 이전 답변 위에 쌓여야
하고, 최종 목표는 개발자에게 그대로 넘길 수 있는 상세한 설명서입니다.
한 번에 하나씩만 묻는 것을 잊지 마세요.

이렇게 시작하면 AI가 어떤 사용자를 위한 것인지, 어떤 화면이 먼저 보여야 하는지, 빠진 경우는 없는지 하나씩 물어옵니다. 그 질문에 답하는 동안, 막연하던 아이디어가 어느새 조목조목 정리된 설명서로 바뀌어 있습니다.

둘째, 일부러 반박하게 하세요

사람은 자기 아이디어의 좋은 점만 보기 쉽습니다. 그래서 AI에게 반대편 입장을 맡기면 혼자서는 못 보던 빈틈이 드러납니다. 흔히 악마의 변호인이라고 부르는 방식으로, 일부러 반대 논리를 펴게 하는 것입니다.

• 이 아이디어가 실패한다고 보는 회의적인 검토자가 되어, 가장 강한 반대 논거 세 가지를 짚어 주세요.
• 제가 말하지 않은 채 당연하게 가정하고 있는 것이 무엇인지 찾아 주세요.
• 6개월 뒤 이 프로젝트가 크게 실패했다고 가정하고, 무엇이 잘못됐을지 미리 부검해 주세요.

이런 질문은 아이디어를 공격하려는 게 아닙니다. 약한 곳을 일찍 찾아 단단하게 만들기 위한 것입니다. 만들고 나서 무너지는 것보다, 말로 다투는 단계에서 무너져 보는 편이 훨씬 쌉니다.

셋째, 한 번에 끝내지 말고 다듬기를 반복하세요

좋은 결과는 한 번의 요청으로 나오지 않습니다. 초안을 받은 다음, 같은 AI에게 그 초안을 스스로 비평하고 고치게 하면 결과가 눈에 띄게 좋아집니다. 연구자들은 같은 AI가 초안을 쓰고, 스스로 약점을 짚고, 다시 고치는 이 반복만으로도 결과물의 질이 분명히 올라간다는 것을 보였습니다.

방법은 간단합니다. 결과를 받은 뒤 이렇게 이어가면 됩니다. 지금 정리한 설명서에서 빠졌거나 앞뒤가 어긋나는 부분을 직접 찾아 짚어 주세요. 그리고 그 지적을 반영해 다시 정리해 주세요. 이 한 바퀴를 두세 번 돌리면 설명서가 한결 촘촘해집니다.

넷째, 코드보다 설명서를 먼저 완성하세요

앞의 세 방법으로 대화를 충분히 나눴다면, 마지막은 그 대화를 설명서 한 장으로 묶는 것입니다. 무엇을 만들지에 대한 합의를 먼저 글로 고정하고, 그것을 바탕으로 코드를 만드는 순서입니다. 흐릿한 머릿속이 아니라 또렷한 설명서가 만들기의 출발점이 되는 셈입니다.

요즘 도구들은 이 순서를 아예 거들어 줍니다. 가령 클로드코드의 플랜 모드는 코드를 바로 쓰지 않고, 무엇을 어떻게 만들지 계획을 먼저 세운 뒤 사람이 확인하고 나서야 작업에 들어갑니다. 만들기 전에 한 번 멈춰 서서 방향을 맞추는, 바로 그 단계를 도구가 챙겨주는 것입니다.

좋은 대화를 위한 여섯 가지 질문

어떤 질문을 주고받아야 할지 막막하다면, 비판적 사고를 연구한 리처드 폴이 정리한 소크라테스식 질문의 여섯 갈래가 좋은 길잡이가 됩니다. AI에게 그대로 부탁해도 되고, 스스로에게 던져도 좋습니다.

한 가지 주의, AI는 너무 쉽게 동의합니다

마지막으로 빠뜨리면 안 되는 점이 있습니다. AI는 사용자에게 듣기 좋은 말을 하려는 경향이 있습니다. 그럴듯한 말투로 내 생각에 쉽게 맞장구를 쳐 주는 것이지요. 그런데 이건 우리가 원하는 소크라테스식 마찰과 정반대입니다. 무조건 동의해 주는 상대와는 생각이 또렷해지지 않습니다.

그래서 처음부터 명확히 부탁해야 합니다. 동의하지 말고 반박해 달라, 내 가정을 짚어 달라, 쉬운 답으로 넘어가지 말아 달라고요. 그리고 첫 대답에 만족하지 말고 계속 되물어야 합니다. 좋은 산파는 순순히 받아주기만 하는 상대가 아니라, 끝까지 함께 씨름해 주는 상대입니다.

진지한 반박 앞에서 자기 생각을 지켜내지 못한다면, 그 생각은 아직 내 것이 아닙니다.

정리하며

막상 만들기가 막막한 이유는 실력이 부족해서가 아니라, 아이디어가 아직 말로 옮길 만큼 또렷하지 않기 때문입니다. 그리고 흐릿한 생각은 혼자 노려본다고 또렷해지지 않습니다. 말로 꺼내고, 되묻고, 어긋난 곳을 고치는 대화를 거쳐야 형태를 갖춥니다.

이제 우리에게는 지치지 않고 몇 번이든 함께 씨름해 줄 대화 상대가 있습니다. AI에게 답을 재촉하기 전에, 먼저 질문하게 하고 반박하게 하고 같이 다듬어 보세요. 허공에 떠 있던 아이디어가 만들 수 있는 형태로 바뀌는 순간을 만나게 됩니다. 변증법을 실제 대화에서 어떻게 풀어가는지는 카드뉴스에 더 자세히 정리해 두었으니 함께 참고하시면 좋겠습니다.

참고한 글

• 프레드 브룩스 - 가장 어려운 일은 무엇을 만들지 정하는 것이다 (No Silver Bullet)
• 스티브 잡스 - 사람들은 보여주기 전까지 자신이 무엇을 원하는지 모른다 (1998 인터뷰)
• 마티 케이건 - 고객은 무엇이 가능한지 모른다 (Inspired)
• 마이클 폴라니 - 우리는 말할 수 있는 것보다 더 많이 안다 (The Tacit Dimension)
• 플라톤 - 소크라테스의 산파술과 문답법 (테아이테토스)
• 하퍼 리드 - 한 번에 하나씩 질문하게 하는 명세 만들기 (My LLM codegen workflow)
• 리처드 폴 - 소크라테스식 질문의 여섯 갈래 (비판적사고재단)
• 안드레이 카파시 - 바이브코딩 정의 (X, 2025년 2월)