AI 상담사례 분석의 한계, 프롬프트에 조건을 붙여도 남는 문제

AI 상담사례 분석 프롬프트에 조건을 많이 붙여도 기록의 애매함이 자동으로 사라지는 것은 아닙니다. 관찰한 사실과 해석을 나누고, 여러 가능성을 남겨 두는 사례 다시보기의 기준이 필요합니다.

상담기록을 AI에게 읽혀보면서 명령은 점점 길어졌다.

처음에는 “이 사례를 분석해줘”에 가까웠던 명령에 조금씩 조건이 붙기 시작했다.

역할을 정해주고, 관점을 나누고, 근거를 표시하라고 요청했다.

확정하지 말 것, 여러 가능성을 나눌 것, 상담자의 판단을 대신하지 말 것 같은 조건도 붙었다.

그렇게 하면 문제가 해결될 줄 알았다.

하지만 실제로는 그렇지 않았다.

AI 상담사례 분석에서 어려웠던 부분은 단순히 프롬프트가 짧다는 데 있지 않았다.

문제는 AI가 답변을 만들어가는 방식 자체에 있었다.

조건을 붙여도 답변이 하나의 설명으로 모이는 이유

프롬프트에 조건을 붙이면 분명 답변은 달라졌다.

근거를 요청하면 근거를 적어주었다.

여러 가능성을 요청하면 몇 가지 가능성을 나누어주었다.

상담자의 판단을 대신하지 말라고 하면 “가능성이 있는 것으로 보입니다”라는 표현을 사용했다.

겉으로는 내가 요구한 형식에 가까워졌다.

그런데 답변을 다시 읽어보면, 여러 가능성을 펼쳐 달라고 했는데, 마지막에는 다시 하나의 핵심 설명으로 모였다.

근거를 표시하라고 했는데, 근거와 추정이 자연스럽게 이어졌다.

그 추정은 다시 무언가의 근거가 되었다.

확정하지 말라고 했는데, 문장의 흐름은 이미 어느 쪽으로 기울어 있었다.

AI는 조건을 무시한 것이 아니었다.

오히려 조건을 꽤 잘 반영했다.

그런데도 답변 전체는 다시 안정적인 설명을 향해 움직였다.

이 지점이 어려웠다.

프롬프트를 조금 더 길게 쓰면 해결되는 문제가 아니었기 때문이다.

상담기록의 애매함을 남겨 두어야 하는 이유

상담기록을 다시 읽을 때는 애매함이 중요할 때가 있다.

어떤 장면은 바로 해석하기보다 잠시 남겨두어야 한다.

어떤 반응은 내담자의 방어일 수도 있지만, 관계 안에서 생긴 조심스러운 탐색일 수도 있다.

어떤 반복은 중요한 패턴일 수도 있지만, 단지 기록 방식 때문에 반복되어 보이는 것일 수도 있다.

상담기록에는 이런 애매한 지점들이 많다.

하지만 AI는 애매함을 남겨두기보다 설명하려는 쪽으로 움직였다.

흩어진 장면들을 연결하고, 반복되는 표현을 묶고, 눈에 띄는 장면을 중심에 세웠다.

그리고 그 결과를 읽기 좋은 문장으로 정리했다.

일반적인 글쓰기나 요약에서는 이것이 장점일 수 있다.

하지만 상담기록 다시보기에서는 이 장점이 단점이 되었다.

상담기록을 다시 읽는 목적은 매끄러운 요약을 얻는 것이 아니었다.

내가 보지 못했던 것을 다시 탐색하는 것이었다.

그러려면 설명이 너무 빨리 완성되면 안 됐다.

틀린 답변은 오히려 알아차리기 쉽다.

문제는 그럴듯한 답변이었다.

상담 맥락에도 맞는 것 같고, 문장도 자연스럽고, 근거도 있어 보이는 답변이 더 어려웠다.

특히 AI는 상담기록 안의 여러 요소를 잘 연결했다.

내담자의 말, 상담자의 반응, 부모상담의 내용, 반복되는 정서 표현을 하나의 흐름으로 묶어냈다.

그 흐름은 읽기에는 좋았다.

하지만 읽기 좋은 흐름이 곧 좋은 사례 이해는 아니었다.

상담기록에는 연결되는 부분도 있지만, 연결되지 않는 부분도 있다.

반복되는 부분도 있지만, 반복되지 않는 예외도 있다.

잘 설명되는 장면도 있지만, 아직 설명하지 말아야 할 장면도 있다.

AI의 답변은 자꾸 이 남는 부분들을 정리하려 했다.

나는 그 정리되는 부분 때문에 계속 멈춰야 했고 이 질문들이 계속 생겼다.

“이건 실제 기록에서 확인되는 말인가?”

“이건 관찰인가, 추정인가?”

“이 장면이 정말 전체를 대표한다고 볼 수 있나?”

“반복된다는 이유만으로 핵심이라고 말해도 되나?”

처음에는 프롬프트를 더 잘 쓰면 된다고 생각했다.

조건을 더 자세히 쓰고, 금지사항을 더 넣고, 원하는 출력 형식을 더 분명하게 만들면 해결될 줄 알았다.

하지만 어느 순간부터는 프롬프트 문장만의 문제가 아니라는 생각이 들었다.

필요한 것은 단순한 명령문이 아니었다.

이 작업을 어떤 태도로 할 것인지에 대한 기준점이었다.

그래서 AI와 작업하면서 반복적으로 부딪힌 문제들을 따로 적기 시작했다.

관찰과 추정을 구분할 것.

하나의 장면을 하나의 원인으로 줄이지 말 것.

한 장면이 전체를 대표한다고 너무 빨리 보지 말 것.

반복되는 것을 곧바로 핵심으로 보지 말 것.

설명이 가능하더라도, 탐색을 멈추지 말 것.

현재 단계에서 할 일을 다하기전에 최종 해석으로 미리 가지 말 것.

이런 문장들은 처음에는 주의사항에 가까웠다.

하지만 시간이 지나면서 점점 작업의 기준이 되었다.

나는 그것을 나중에 일종의 OS처럼 생각하게 되었다.

거창한 의미의 OS는 아니었다.

정답을 정하기 위한 규칙도 아니었다.

프롬프트보다 중요한 사례 다시보기의 기준

AI가 가진 장점은 분명히 있었다.

흩어진 내용을 연결하고, 여러 관점을 빠르게 제안하고, 내가 미처 생각하지 못한 방향을 보여주는 힘이 있었다.

문제는 그 힘이 너무 빨리 결론으로 향할 때였다.

그래서 기준점의 역할은 AI의 앞을 막는 것이 아니라, 속도와 방향을 바꾸는 데 있었다.

설명은 하되 확정하지 않기.

연결은 하되 남는 부분을 지우지 않기.

반복은 보되 예외를 함께 남기기.

가능성은 제안하되 상담자의 판단을 대신하지 않기.

이후 프롬프트는 점점 복잡해졌다.

하지만 그 복잡함은 기능을 늘리기 위한 것이 아니었다.

더 멋진 분석을 얻기 위한 것도 아니었다.

오히려 반대에 가까웠다.

AI가 너무 빨리 분석을 완성하지 못하게 하기 위한 장치였다.

상담기록을 읽을 때는 “잘 정리된 답”보다 중요한 것이 있었다.

추정은 추정으로 남아 있어야 했다.

여러 가능성이 하나의 결론으로 빨리 합쳐지지 않아야 했다.

상담자가 다시 검토할 수 있는 형태로 남아 있어야 했다.

그래서 프롬프트는 점점 길어졌다.

무엇을 보라는 말만 들어간 것이 아니었다.

무엇을 조심해야 하는지, 어디에서 멈춰야 하는지, 어떤 구분을 유지해야 하는지가 함께 들어갔다.

그때부터 프롬프트는 단순한 질문이 아니었다.

상담기록을 어떻게 읽어야 하는지 태도를 설명하는 절차에 가까워졌다.

이 과정을 지나면서 질문도 달라졌다.

처음에는 “AI가 상담사례 분석을 할 수 있을까?”에 가까웠다.

하지만 점점 그 질문은 중요하지 않게 되었다.

사례 다시보기 작업은 AI가 상담사례를 대신 분석하는 방향으로 가지 않게 되었다.

AI의 답을 완성된 해석으로 받는 것이 아니라, 상담자가 다시 읽을 수 있는 구조를 만드는 방향으로 움직이게 되었다.

프롬프트가 고도화된 이유도 여기에 있었다.

더 정교한 답을 얻기 위해서가 아니라,

더 조심스럽게 다시 보기 위해서였다.

그 기준점 위에서 프롬프트는 조금씩 다른 모양이 되어갔다.

Similar Posts