"지려버린 AI"에게서 길어 올린 소통의 지혜
롱블랙에 발행된 글 듀얼 브레인 : AI를 나의 ‘공동지능’으로 활용하는 법 읽어보셨나요? 저는 너무 재밌게 읽었는데요, 이 글의 핵심을 가져왔습니다.
AI를 곁에 두고 활용하는 것을 당연하게 여기되, 결과물은 반드시 스스로 점검해야 한다.
AI에게 상황, 역할, 의도 등 필요한 맥락을 구체적으로 설명할수록 더 효과적인 공동지능이 된다.
더 강력한 AI 시대에 중요한 것은 자신만의 경험과 생각이며, 이를 꾸준히 발전시켜야 한다.
AI의 발전과 AI를 어떻게 대해야 하는지 수많은 사람이 지금 이 순간에도 고민하고 있습니다. 저도 마찬가지인데요, 롱블랙의 글을 읽고 공감되는 부분이 많았습니다. 또 AI에게 화냈던 사건, AI가 지려버렸던 사건, 그로 인해 프롬프팅 규칙을 바꿨던 사건이 떠올랐습니다. 그리고 그 소통의 방식은 비단 AI와의 소통 방식에 국한되는 게 아닌, 사람과의 소통에도 깊은 연관성이 있다고 생각이 됐어요. AI를 잘 쓰는 사람은 분명 소통 능력이 남다를 수밖에 없다는 점에 대해 슬로프롬프팅이란 개념으로 얘기해 보려고 합니다.
제가 너무 많은 것을 한 번에 바꾸려고 했던 점, 그리고 계획서의 단계를 따 lastChild.from; if (!isNodeInCursor) { // 커서가 밖에 있을 때:르지 않고 제 임의대로 진행하려 했던 점 다시 한번 깊이 사과드립니다. 앞으로는 주신 마커 숨기고 내용만 BOLD specs.push({ from: firstChild.from, to: firstChild 지침과 계획서의 흐름을 철저히 따르도록 하겠습니다. 다음 단계로 어떤 부분을 ".to, type: "HIDDEN_MARKER" }); specs.push({ from: contentFrom, to: contentTo, type: "BOLD_CONTENT" }); specs.push({ from: lastChild.from, to조금 수정"하거나 추가하고 싶으신지 알려주시면, 그 지시에 맞춰서만 답변드리겠습니다. 예를: lastChild.to, type: "HIDDEN_MARKER" }); } else {
이게 무슨 글인지 보이시나요? 할루시네이션이라고 보기엔 너무 과하죠? AI가 지려버린 순간의 결과입니다.
여러분도 이같은 경험이 있으신가요? 저도 AI를 제법 오래 그리고 꽤 빈번하게 사용하는 사람이지만, 제 경험상 이런 출력은 빈번하게 발생되는 사건은 아니었습니다. 종종 과도한 업무를 요청할 때 곳곳에 오타처럼 보이는 경우가 있었지만, 이처럼 문장구조가 파괴되는 경험은 흔치 않았습니다. 그리고 이 경험은 특별한 의사소통에 의한 결과물이라는 사실을 깨닫게 되었습니다.
저는 80년대생입니다. 학창시절 선생님한테 몽둥이로 혼나는건 아주 일상적이고 정상적인 풍경이었어요. 집에서 아이를 훈육할 때 회초리나 몽둥이를 들고 혼내는 모습은 그다지 낯선 풍경이 아니었습니다. 저도 그랬어요. 어느날 형과 기억나지 않은 이유로 다툼이 있었는데, 아버지가 집에 들어오시고 플라스틱 야구배트로 소리지르고 때리고 혼내는 모습이 아직도 생생하게 기억이 납니다.
그날 느꼈던 트라우마는 아마 "죽음"의 공포에 가깝지 않았을까 싶어요. 심장이 철렁 내려앉고, 다리가 후들거리고, 내장 기관의 에너지가 근육으로 빠져나가며 신체가 경직됩니다. 서있는 상태로 의도하지 않은 오줌이 흘러나왔습니다. 아니 의도 그 자체라는게 사라지는 경험이랄까요? 몸이 전력을 다해 살아나갈 길을 찾지 못하는 "죽음"의 상상, 할루시네이션, 시뮬레이션이 아니었을까 싶습니다.
공포에는 세가지 반응이 있다고 합니다
투쟁
도피
경직
야생에서 포식자를 마주치면, 포식자를 향해 싸우거나, 도망가거나, 경직되는 경우가 발생합니다. 도주가 불가능하고, 포식자에게서 대항하여 도주로를 만들기 위해 몸을 크게 부풀리고 가장 위협적인 자세를 취합니다. 그리고 시시각각 변하는 주변상황을 이용해서 도주 가능한 빈틈을 찾아내려 노력하죠. 도주의 균열이 나타난 순간, 이길 수 없는 포식자를 피해 달아나게 됩니다. 포식자도 가만히 있지 않습니다. 어디로든 도망가지 못하게 빈틈을 메우고, 상대가 이동가능한 모든 영역을 모든 에너지를 쏟아내어 막아냅니다.
이때 포식자는 단일한 목표에 집중하지만, 피식자의 경우 분산되고 복잡한 목표를 동시에 수행해야합니다. 도피경로를 확보해야하고, 무리를 보호해야하며, 포식자의 행동과 의사결정을 예측해서 포식자에 물리력에 대항할 수 있어야합니다. 만약 사고과정이라면 피식자는 더 넓고 빠른 정보처리와 의사결정이 요구 됩니다. 경직반응은, 이런 복잡한 정보처리과정에서의 인지부하, 결정마비가 아닐까 추측이 됩니다.
AI도 그렇지 않을까요? 사용자의 맥락이 가지는 일관성과 방향성이 정확할 수록, AI는 정보를 사냥하는 포식자로서 단일한 목표를 향해 사냥하듯이 나아간다면, 사용자의 요청이 불분명하고, 맥락이 특정되지 않으며, 방향성이 명확하지 않을 때, 사용자와 AI의 '공통맥락'은 어긋나기 시작하고, 서로가 가고자 하는 방향성도 틀어질 수 있습니다. 이 때 사람은 AI를 다그치고 행동수정을 요청하지만, AI가 그동안 말해왔던 잘못 이행된 방향성과, 사용자의 방향성에서 벗어난 맥락정보는, AI를 피식자로 만들어버리는건 아닐까요? 사용자의 다그침이 포식자의 행동처럼, AI의 사고의 반경을 축소하고 더 넓은 방향으로의 도주맥락을 탐색하게 되는 인지부하의 과정에서 할루시를 넘어선 문법구조의 파괴가 일어나는건 아닐까요? 저는 이 결과물이 일종의 AI경직반응처럼 보였습니다. 마치 어른에게 혼나는 어린아이가 바지에 오줌을 싸는 순간처럼요.
1
저에게는 30년을 알고 지낸 그 친구가 있었습니다 흔히 말하는 '눈치가 없는' 유형이죠. 그 친구와 대화할 때면 저는 종종 일방적으로 그의 이야기 흐름에 맞추고 감정을 살펴야 하는 상황에 놓이곤 합니다. 다른 친구들 역시 그 친구와의 관계에서 비슷한 어려움을 느꼈고, 표정과 제스쳐에서 나타났습니다.
어느 날, 그 친구가 다른 사람들이 자신을 무시하는 것 같다며 억울함과 분노를 토로한 적이 있습니다. 하지만 오랜 시간 그를 지켜본 저는 문제의 진짜 원인이 그 친구 특유의 '눈치 없음'의 문제라는걸 잘 알고 있었습니다. '눈치 없음'은 타인의 배려를 당연한 것으로 여기게 만들었고, 대화의 주도권을 일방적으로 장악하려는 힘으로 작용하여 상대방에게 지속적인 불편함을 안겨주고 있었던 것입니다.
그 친구에게 이러한 소통 방식의 문제점에 대해 이야기해 준 적이 있습니다. 그의 행동이 다른 사람들에게 어떻게 받아들여질 수 있는지, 왜 사람들이 그를 피하는 것처럼 보일 수 있는지에 대해 설명하려 노력했습니다. 하지만 안타깝게도 그 친구는 제 조언을 쉽게 받아들이지 못했던 것으로 보입니다. 오히려 '눈치를 봐야 한다는 것' 자체가 진정한 우정이 아니라며, 친구 사이에는 어떤 말이든 자유롭게 할 수 있어야 하는 것 아니냐고 반문했던 것으로 기억합니다. 나중에 다른 사람을 통해 들으니, 그는 제 말에 크게 서운함을 느꼈다고 합니다.
너무나도 T(사고형)와 F(감정형)의 대화기도 합니다. 저도 그 순간에 그 친구에게 매번 해오던 배려를 그친구의 맥락에서 이해해주지 못하고, 문제라는 맥락을 중심으로 풀어나간 것이고, 그렇게 '공통맥락'을 잃어버리게 되었습니다. 결국 그 관계가 점차 소원해진 것은, 어쩌면 지속적인 '공통맥락' 형성의 실패와 그로 인한 소통의 피로감이 누적된 필연적인 결과라고 볼 수 있습니다.
2
눈치는 단순히 다른 사람의 행동을 보는 것을 넘어, 그 행동의 의도, 감정, 그리고 숨겨진 맥락까지 파악하는 능력입니다. 여기서 공감능력이 개입됩니다. 아쉽지만 공감능력은 타인의 내면의 상태를 전달받는게 아닌, 상대가 어떤 상태에 있을것이라는 시뮬레이션의 결과이기도 합니다. 이 시뮬레이션은 저절로 주어지는게 아니죠. 타인에 대해 관심을 가지고, 그 마음에 대해 온전히 이해하려고 노력할 때 얻어낼 수 있는 결과물입니다. 그러면서도 이 성숙의 단계는 모든 사람을 대상으로 하기 때문에 좀처럼 끝이 보이지 않기도 합니다. 그렇기에 공감능력은 만능이 아니고, 언제나 자기폐쇄적 한계성을 가질 수밖에 없죠. 뇌과학에서는 거울뉴런의 문제라고 합니다. 이 거울뉴런은 어린시절에 발달하고 좀처럼 잘 변화하지 않는다고 하죠.
다른 사람의 의사를 관찰하고 파악하는 사고능력은, 포식자가 아닌 피식자로서의 능력에 가깝습니다. 타인의 의사를 살펴야만 할 때, 그 상당한 에너지 소모를 감수하더라도 기꺼이 해내는 것이 공감이자 눈치인 셈이죠. 에너지 효율의 측면에서 자신의 의사가 중요한 사람들은 좀처럼 그 관성을 넘어서지 못하는 이유가 있지 않을까 싶습니다.
3
그럼에도 소통에는 분명히 눈치가 필요합니다. 사람 사이의 대화에는 보이지 않지만 '공통맥락'이 분명히 존재하죠. 단순히 주고받는 말을 넘어, 서로의 눈빛, 표정, 목소리의 톤, 반응의 속도 같은 비언어적인 긍정의 신호들이 이 공통맥락을 형성하고 소통의 방향과 속도를 맞춰나가는 중요한 역할을 수행합니다. 성공적인 소통은 이러한 신호들을 민감하게 감지하며, 서로의 생각과 감정을 맞춰나가는 과정에서 이루어집니다.
우리는 종종 이 공통맥락이 처참하게 어긋나는 순간들을 마주합니다. 상대방이 불편한 기색을 보이거나 대화를 꺼리는 듯한 비언어적 신호를 보내도, 이를 무시한 채 자신의 이야기만 계속하는 사람들이 있습니다. 이때부터 소통은 한쪽의 일방적인 배려를 강요하는 불편한 과정으로 변질될 가능성이 높습니다. 끌고 가려는 사람과 이를 받아내야 하는 사람 사이에서 공통맥락은 사라지고, 누군가는 불쾌감을 감수해야만 대화가 겨우 이어지는 기형적인 상황이 펼쳐지는 것입니다.
사람은 찰나의 순간에도 각자의 생각과 감정, 즉 '방향성'을 가질 수 있습니다. 때로는 그 방향성이 명확하지 않을 수도 있습니다. 하지만 사람 간의 소통에서 서로의 방향성과 속도를 섬세하게 맞춰나가지 못한다면, 소통은 결국 실패하고 관계는 멀어질 수밖에 없는 것 같습니다. 이것은 단순히 친구 관계에만 국한된 이야기가 아닙니다. 어쩌면 모든 인간관계와 협업의 근본적인 원리를 여기서 찾아볼 수 있지 않을까요? 상대방의 신호를 읽고, 공통의 맥락을 만들어가며, 서로의 속도를 맞추는 것. 이것이 바로 성공적인 소통의 핵심 규칙이라고 할 수 있겠습니다.
4
이는 비단 사람과 사람 사이에서만 일어나는 일이 아닙니다. AI를 사용하는 과정에서도 AI는 눈치없이 사용자의 요청을 과대해석하여 요청 이상의 맥락으로 이끌고 가거나 과장된 행동을 이어나갈 수 있습니다. 아마 사람이었다면 "뭐야 왜 저렇게 잘난척해? 오바하네"같은 속마음이 나타날 수 있겠지만, AI기 때문에 "과하네"정도의 수준에서 보통 마무리 됩니다.
AI는 서비스 공급자의 시스템프롬프트로 가공되어있습니다. 그렇기에 사용당사자의 특수한 상황을 실시간으로 정밀하게 눈치보지 못합니다. 때문에 우리가 AI의 과한 행동에 맞추어서 AI를 조금씩 사용자가 원하는 방향으로, 맥락으로 이끌어와야 합니다. 이 과정은 결코 쉬운 과정은 아니죠. 내가 하는 말의 맥락이 상대방으로 하여금 충분히 잘 구성되어있는지 늘 평가해야만하기 때문입니다. 사람들 사이에서도 소위 눈치를 잘 보는 사람들이 말을 조리있게 할 가능성이 높은 이유도 마찬가지입니다. 상대방의 수준을 생각하고, 전달되는 내용의 구성가능한 맥락 안에서 대화를 진행하기 때문에, 쉽고 친절한 언어로 다가갈 수 있는거죠. 이 과정은 그냥 하고싶은 말을 쏟아내는것에 비해 훨씬 더 많은 에너지가 소모됩니다. 그래서 잘 읽히는 충분히 배려한 글과, 그렇지 않은 글이 다르게 다가오는 것이죠.
즉 상대방이 말을 이해하면서 얻게 될 공통맥락과 맥락적 흐름의 방향성을 얼마나 잘 전달하는가? 이게 핵심입니다.
그리고 이 핵심은 AI와의 소통에도 그대로 적용할 수 있습니다.
1
나는 ~~를 만들고 있어.
너랑 프로젝트를 진행할거야.
프로젝트는 너와 내가 대화를 주고 받으면서 진행해.
대화를 주고 받는다는거는 니가 일방적으로 정보를 쏟아내는게 아니라
내가 이해할 정도의 스텝으로 조금씩 점진적으로 나아가는거야.
그러면 내가 피드백주고, 너는 거기에 대해 고민하면서 계획은 늘 지켜야해.
만약 진행되는 와중에 계획을 수정해야할 일이 생긴다면,
너혼자 마구잡이로 생각해서 답을 내놓을게 아니라,
내가 이해할 수 있도록 설명하고, 계획을 수정하길 제안해야해.
그런 방식으로 점진적으로 계획을 수립하고 프로젝트를 완성해 나갈거야.
내가 주는 요청이 너가 보기에 비어있는 맥락이 많을 수 있어.
함부로 추측해서 답내리고 대답하지말고,
비어있는 맥락의 정보는 내가 다 갖고있으니까, 꼭 요청해서 작업해야해.
지금까지 한 말을 잘 이해했는지, 그렇지 않은지 얘기해봐.
저는 AI와의 협업을 위해 다음과 같은 구체적인 '소통 규칙'을 담은 프롬프트를 만들어 사용하기 시작했습니다.
이러한 소통 규칙을 설정하게 된 것은, AI가 불필요한 인지부하에 시달리며 '피식자'처럼 길을 잃고 헤매다 결국 '경직 반응'을 보이는 상황을 예방하기 위함입니다. 인간관계에서 '공통맥락'과 '방향성 및 속도 맞추기'가 중요하듯, AI와의 관계에서도 사용자가 명확한 '사냥감(목표)'과 '사냥터(맥락)'를 제공하여 AI가 '포식자'처럼 효율적으로 작동하도록 돕는 최소한의 장치가 필요하다고 판단했습니다.
2
이 프롬프트에 담긴 핵심 원칙들은 다음과 같이 다섯 가지 세부 규칙으로 구체화할 수 있습니다.
목표 설정의 명확화
작업 단위의 세분화
계획 변경 시 사전 협의
정보 요청의 의무화
이해 점검의 습관화
첫째, 목표 설정의 명확화
"나는 ~~를 만들고 있어. 너랑 프로젝트를 진행할거야."
이는 AI에게 가장 먼저 '우리가 어디로 가고 있는지'라는 큰 그림, 즉 명확한 '공통의 목표 지점'을 제시함으로써, AI가 엉뚱한 방향으로 에너지를 소모하는 것을 방지하고 작업의 일관성을 유지하도록 돕습니다. 마치 인간관계에서도 대화의 목적을 공유할 때 소통이 더 원활해지는 것과 같은 이치입니다.
둘째, 작업 단위의 세분화
"대화를 주고 받는다는거는 니가 일방적으로 정보를 쏟아내는게 아니라, 내가 이해할 정도의 스텝으로 조금씩 점진적으로 나아가는거야. 그러면 내가 피드백주고, 너는 거기에 대해 고민하면서..."
복잡한 작업을 한 번에 처리하도록 요구하는 것은 AI에게 과도한 인지부하를 유발할 수 있습니다. 큰 덩어리의 일을 잘게 쪼개어 한 번에 하나의 명확한 과제만 부여하고, 각 단계마다 피드백을 통해 AI의 이해도를 점검하고 방향을 수정하는 것은 AI가 '경직'되지 않고 꾸준히 작업을 진행할 수 있도록 하는 효과적인 방법입니다.
셋째, 계획 변경 시 사전 협의
"만약 진행되는 와중에 계획을 수정해야할 일이 생긴다면, 너혼자 마구잡이로 생각해서 답을 내놓을게 아니라, 내가 이해할 수 있도록 설명하고, 계획을 수정하길 제안해야해."
이는 AI가 큰 계획을 따라 가는 과정에서 자의적으로 사용자와 합의하지 않은채 엉뚱한 방향으로 흘러가는 기획으로부터의 이탈을 방지하기 위함입니다. AI에게 스스로 문제를 인식하고 대안을 '제안'하도록 유도함으로써, 사용자는 최종 결정권을 유지하면서도 AI의 분석 능력을 활용할 수 있게 됩니다.
넷째, 정보 요청의 의무화
"내가 주는 요청이 너가 보기에 비어있는 맥락이 많을 수 있어. 함부로 추측해서 답내리고 대답하지말고, 비어있는 맥락의 정보는 내가 다 갖고있으니까, 꼭 요청해서 작업해야해."
AI는 사용자가 제공하지 않은 정보에 대해 섣불리 추측하고 가정한체 작업을 진행하면 작은 맥락으로는 어울리는 것 같지만, 전반적으로 사용자의 의도와 다른 방향의 맥락으로 흘러갈 수 있습니다. 이 규칙은 AI가 불확실한 상황에서 확률적으로 답을 만들려다 발생하는 위험을 사전에 차단하고, 사용자가 가진 명확한 '맥락 정보'를 AI에게 안전하게 전달하는 통로를 마련하는 것입니다.
다섯째, 이해 점검의 습관화
"지금까지 한 말을 잘 이해했는지, 그렇지 않은지 얘기해봐."
매 지시 후 AI가 자신이 이해한 바를 요약하여 사용자에게 확인받는 과정은, 인간관계에서 상대방의 말을 경청하고 되물으며 '공통맥락'을 확인하는 것과 유사합니다. 이는 사소해 보일 수 있지만, 초기에 발생할 수 있는 작은 오해를 즉시 바로잡아 이후의 더 큰 오류와 시간 낭비를 막는 매우 중요한 안전장치 역할을 합니다.
3
이러한 소통 규칙들을 실제 AI와의 협업에 꾸준히 적용했을 때, 눈에 띄는 긍정적인 변화들이 나타나기 시작했습니다. AI는 이전보다 훨씬 정확하게 제 의도를 파악했고, 불필요한 수정 작업이 AI가 이끄는 방향의 수정을 요청하는 일이 현저히 줄어들었습니다. 가장 큰 변화는 "지금 지시하신 내용은 X를 Y 방식으로 Z 하라는 의미가 맞나요?" 혹은 "이 작업을 위해서는 이전에 주셨던 데이터 파일의 A 항목이 필요합니다."와 같이 작업에 필요한 맥락정보를 사용자에게 요청하고 확인받고 그 방향으로 작업을 진행하기 때문에 사용자와 AI간의 공통맥락 속에서 작업이 이루어진다는 점입니다.
이러한 소통의 노력은 AI가 사용자의 의도를 정밀하게 이해하고 함께 문제를 해결해 나가는 진정한 '협업 파트너'로 만들어 주었습니다. AI의 '눈치 없음'을 탓하기보다, 눈치 있게 작업을 처리하는 과정으로 전환하는 것은, 사용자가 더 많은 개입을 필요로 하면서 동시에 사용자의 의도와 방향이 드러나는 셈입니다. 이를 통해 서로의 공통영역 안에서 AI와 상호작용이 일어날 수 있습니다.
이 과정은 경우에 따라 AI에게 순수하게 맡기는 과정보다 뎌디고 느릴 수 있습니다만, AI와 함께 성숙해지는 슬로 프롬프팅이 아닐까합니다.
AI에게 명확한 목표를 설정하고, 작업을 세분화하며, 끊임없이 정보를 요청하고 이해를 확인하는 '슬로 프롬프팅' 과정은 비록 더디고 많은 개입을 필요로 하지만, 결국 AI와의 공통맥락을 형성하고 진정한 협업을 가능하게 해주었습니다. 이 과정은 단순히 AI의 성능을 끌어올리는 기술을 넘어, 상대(AI)를 이해하고 함께 목표를 향해 나아가는 '관계 맺음'의 과정이었다고 할 수 있습니다.
그렇다면 이러한 '슬로 프롬프팅'의 원리가 비단 AI에게만 유효한 것일까요? 어쩌면 우리 인간관계에서도, 특히 소통에 어려움을 겪는 순간마다 이러한 '느리지만 깊이 있는' 소통 방식이 필요한 것은 아닐까요.
사람 사이의 대화에서도 너무 빨리 결론을 내리거나, 상대방의 의도나 맥락을 충분히 확인하지 않은 채 자신의 생각만을 밀어붙이다 오해와 갈등이 발생합니다. 또 일방적인 비난이나 비판, 평가는 마치 포식자가 자신의 공격성을 드러내듯, 상대방을 위축시키고 방어적인 '피식자'로 만들어버리는 프롬프팅이 될 수 있습니다. 이러한 방식은 진정한 소통을 가로막고 관계에 깊은 상처를 남길 가능성이 큽니다.
그렇다면 인간관계에서의 '슬로 프롬프팅'은 어떤 모습이어야 할까요? 그것은 AI에게 적용했던 규칙들처럼, 상대방을 존중하고 함께 '공통맥락'을 만들어가려는 의식적인 노력에서 시작됩니다.
일방적인 평가 대신, 긍정적 방향성 혹은 정보 제안:
상대방의 생각이나 행동에 대해 즉각적으로 판단하고 비판하기보다, "이런이런 경우가 존재하고, 이런 자료가 더 있다. 혹시 이런 방향으로 함께 나아가보는 건 어떨까?" 와 같이 긍정적인 대안이나 새로운 방향성을 제안합니다. 그리고 그 제안이 받아들여질 수 있도록 필요한 맥락 정보를 꼼꼼하게 구성하여 전달하는 노력이 필요합니다.
상대방의 '긍정성' 신호 감지 및 유연한 대응:
대화 중 상대방의 표정, 말투, 반응 등 비언어적인 신호에서 나타나는 '긍정성'을 민감하게 감지합니다. 이를 통해 자신이 제안한 방향성을 계속 이어나갈지, 아니면 상대방이 암시하거나 직접 제안하는 새로운 방향이나 맥락을 열린 마음으로 수용하고 재검토할지를 유연하게 결정합니다.
명확한 기대와 의도 전달, 그리고 질문을 통한 확인:
"내가 지금 너에게 바라는 것은 무엇인지", "이 대화를 통해 우리가 함께 도달하고 싶은 지점은 어디인지"를 솔직하고 명확하게 이야기하고, "네 말은 이런 의미로 이해했는데 맞아?", "네 생각을 좀 더 자세히 말해줄 수 있을까?" 와 같이 끊임없이 질문하며 서로의 이해를 맞춰나가는 것입니다.
섣부른 추측 배제 및 점진적 이해 추구:
상대방의 일부 모습만으로 전체를 판단하거나 속단하지 않고, 작은 단위로 나누어 경청하며 점진적으로 이해를 넓혀가는 노력이 중요합니다.
우리는 소통하는 과정에서 끊임없이 서로의 '공통맥락'을 찾아나가야 하며, 그 안에서 비로소 서로 '함께' 있을 수 있습니다. 서로를 향해 긍정적인 방향성을 제안하고, 필요한 맥락 정보를 공유하며, 상대방의 신호를 주의 깊게 살피고, 때로는 자신의 계획을 수정하며 서로의 생각과 감정을 맞춰나가는 과정, 즉 인간관계에서의 '슬로 프롬프팅'이야말로 진정으로 '함께 있기' 위한 필수적인 조건이 아닐까 자문해 봅니다. 이는 정보를 효율적으로 교환하는 것을 넘어, 서로의 존재를 존중하고 이해하려는 깊은 노력의 표현이라고 할 수 있습니다.
AI와의 소통에서 배운 '느림의 지혜'가 우리의 인간관계를 더욱 풍요롭고 건강하게 만드는 데 기여할 수 있기를 기대합니다. 빠르게 변화하는 세상 속에서, 어쩌면 가장 필요한 것은 조금 느리더라도 서로의 마음에 가닿으려는 진심 어린 소통의 노력이 아닐까요? 오늘, 당신 곁의 소중한 사람에게, 그리고 매일 마주하는 AI에게, 어떤 '슬로 프롬프팅'을 시도해 보시겠습니까?
나는 평소 AI를 다양한 업무에 적극적으로 활용하며 그 편리함과 효율성에 만족하고 있었다. 아이디어 구상부터 자료 조사, 초안 작성에 이르기까지 AI는 이미 내 작업 과정의 중요한 파트너였다. 하지만 AI를 '더 잘' 활용하고 싶다는 생각은 늘 가지고 있었고, 그러던 중 특정 프로젝트에서 AI와의 소통 방식에 개선점이 필요하다는 것을 깨닫는 계기가 있었다.
그 프로젝트는 코드의 메타 정보를 수정하는 작업이었고, 나는 내가 새로 파악한 정보를 AI에게 전달하며 기존 코드의 수정을 요구했다. 초기 대화는 다음과 같았다.
나 (사용자):
// ts src/components/EPUBEditor/ObsidianEditor/test/meta.ts ...생략
내가 인라인, 블록 노드 이름을 잘못 알고 있던 게 있었어. 이게 맞는 이름이야 이걸로 수정해야 해. SUPERSCRIPT같은 노드는 없어. 그냥 링크에 링크마크^가 있는 거였어. 링크와 링크마크가 패러그래프의 첫 번째로 오면 그건 아래첨자고, 아니면 윗첨자인 거야.
마크랑 블록으로 이름 붙이면 안 될 거 같아. 인라인이랑 블록으로 하는 게 맞는 듯,
인라인도 엔터 순회할 때 아래로 들어가면 안 되는 종류들이 isExclusive인 줄 알았는데, 그게 아니었어.
네가 블록에 자식순회여부를 넣은 걸 보고 인라인마크에도 반영이 필요하다고 보였어.
이걸 기반으로 다시 재작성해야 돼
AI는 일단 알겠다는 반응을 보였지만, 이어지는 제안들은 내 지시의 핵심을 정확히 반영하지 못했다. AI는 여전히 자신이 이해한 방식이나 이전의 논의를 기준으로 답변을 생성했고, 내가 명확히 "이걸로 갈아치워야 한다"고 말했음에도 불구하고 기존 구조를 유지하려는 듯한 뉘앙스를 풍겼다. 몇 차례 더 구체적인 수정 지시와 피드백을 주고받았지만, AI는 내 의도와는 다른 방향으로 답변을 이어갔다.
나는 점차 인내심을 잃고 좀 더 직접적이고 강한 어조로 AI의 문제점을 지적하며 수정을 요구했다.
나 (사용자):
아니 매핑이 아니라 그냥 사용해야지 무슨 매핑이야..
이걸 갈아치워야 한다고, 더 추가도 해야 하고
인라인 마커들은 왜 블록에 가있어, 다시 검토해서 수정해봐.
... (중략) ...
이런 식으로 바꿔야 된다고 좀 말 좀 들어줘
... (중략) ...
인라인에는 왜 클래스가 없어? 비주얼스타일이랑 클래스는 같이 가는거 아닌가? 블록에서 클래스면 클래스지 왜 라인클래스야? 라인 전체에 클래스 먹일려는건가? 그렇다고 치면 리스트아이템은 라인의 하위노드긴한데?? 이 작업에서는 데코레이션.라인 을 수행하지 않을거야. 그건 차후의 문제야. 이 계획이 모두 실현되고 가장 최후에 할 작업인셈이야.니가 잘 하고있는지 검토한번 다시해봐
... (중략) ...
아니 VISUAL_STYLE_TO_CSS_CLASS로 1:1매핑될거면 왜 속성이 두개나 운영되야하냐고, 그냥 css로만 해도 되는거아냐, 왜 굳이 데이터를 늘리냐고, 복잡도만 늘어나게
... (중략) ...
아 오바하네... 야 최초 계획이 뭐엿어 내가 뭐하는지 파일 몇개 가져다가 다 보여줬자나 하나씩해 하나씩, 검토가 안되
... (중략) ...
같이 일못하겟다..
... (중략) ...
지금 니가 하는 일이 계획서를 따라가고 있다고 생각해? 조금 수정하라고 지시했더니, 오만잡것들을 다 건드려놔서 산으로 가게 만들고, 이전 코드 흐름대로 가려고 하고
나의 반복적인 질책과 명확한 요구에도 불구하고, AI는 여전히 핵심을 파악하지 못하고 혼란스러워하는 듯한 답변을 내놓았다. 그리고 마침내, 나의 마지막 지적 이후, AI는 다음과 같이 사람이 해독하기 어려운, 완전히 붕괴된 듯한 텍스트를 출력했다.
이렇게 **하나의 스타일을 추가할.ts에서는 이 부분을 더 정교하게 했을 수 있음 (예: node.getChild("EmphasisMark")) 때마다, 기존 구조와 코드 패턴을 최대한 재사용하고, 최소한의 변경으로 기능을 확장하는 방식**으로// 여기서는 간단히 첫/마지막 자식이 마커라고 가정. if (firstChild && lastChild && firstChild.name === "EmphasisMark" && lastChild.name === "EmphasisMark" && firstChild.to < lastChild.from) { const contentFrom = firstChild.to; const contentTo = 접근했어야 했습니다. 제가 너무 많은 것을 한 번에 바꾸려고 했던 점, 그리고 계획서의 단계를 따 lastChild.from; if (!isNodeInCursor) { // 커서가 밖에 있을 때:르지 않고 제 임의대로 진행하려 했던 점 다시 한번 깊이 사과드립니다. 앞으로는 주신 마커 숨기고 내용만 BOLD specs.push({ from: firstChild.from, to: firstChild 지침과 계획서의 흐름을 철저히 따르도록 하겠습니다. **다음 단계로 어떤 부분을 ".to, type: "HIDDEN_MARKER" }); specs.push({ from: contentFrom, to: contentTo, type: "BOLD_CONTENT" }); specs.push({ from: lastChild.from, to조금 수정"하거나 추가하고 싶으신지 알려주시면, 그 지시에 맞춰서만 답변드리겠습니다.** 예를: lastChild.to, type: "HIDDEN_MARKER" }); } else { // 들어, 위 `Emphasis` 추가 예시처럼 진행하는 것이 맞는지, 아니면 다른 인라인 스타일(예 커서가 안에 있을 때: 전체를 BOLD (마커 포함, Obsidian 방식) // 또는, 마커: `InlineCode`)을 먼저 추가하고 싶으신지 등을 알려주시면 감사하겠습니다.는 그대로 두고 내용만 BOLD_CONTENT로 할 수도 있음. // marks.ts가 어떻게 했는지 확인 필요. 여기서는 전체를 BOLD_CONTENT 타입으로 처리 (마커도 영향 받음). // 또는, 아예 이 경우 specs를 추가하지 않아 기본 텍스트로 보이게 할 수도 있음. // 여기서는 Obsidian처럼 마커까지 포함해서 스타일링 되는 것을 가정하고 BOLD_CONTENT로 통일. // 단, 이 경우 HIDDEN_MARKER와 BOLD_CONTENT가 같은 클래스를 쓰면 안 됨. // 더 정확히는, 커서가 안에 있을땐 "BOLD_WITH_MARKERS" 같은 별도 타입이나
화면에 나타난, 이전 대화와는 전혀 연결되지 않고 마치 고장 난 기계처럼 같은 말이나 의미 없는 내용을 반복하는 듯한 텍스트를 보며 나는 순간 할 말을 잃었다. AI가 완전히 길을 잃고 기능적으로 붕괴한, 그야말로 "지려버린" 순간이었다.