AI에게 질문을 고쳐 넣었더니 더 좋은 답이 나왔다. 이 경험은 유용하다. 다만 답이 좋아졌다는 사실만으로 내가 그 문제를 더 잘 이해하게 됐다고 말할 수 있을까. 다음에 비슷한 상황을 만나면 무엇을 확인해야 하는지 스스로 설명할 수 있는지도 묻고 싶다.
내가 ‘경험적·인지적 프롬프트’라는 표현으로 강조하려는 것은 이 차이다. 입력 문장을 다듬는 기술과 함께, 문제를 보고 답을 검토하며 자기 판단을 고치는 과정을 살피자는 제안이다.
빠른 생각과 느린 생각 중 하나를 고르는 문제가 아니다
기존 글에서는 시스템 1과 시스템 2의 구분을 허상이라 부르고 프롬프트 엔지니어링의 한계를 설명했다. 그러나 그 이론 전체를 부정하거나 프롬프트 설계가 모두 같은 가정에서 출발했다고 말하려면 더 구체적인 근거가 필요하다. 여기서는 실제로 확인할 수 있는 질문에 집중하려 한다.
직관적으로 떠오른 답을 언제 믿고, 어떤 조건에서 다시 살필 것인가. 분석을 오래 했다는 이유만으로 그 답이 현재의 상황에 맞는다고 볼 수 있는가. 빠름과 느림을 각각 오류와 정답으로 나누면 이런 질문이 사라진다.
[클라인의 RPD 설명](https://www.gary-klein.com/rpd)은 경험으로 그럴듯한 행동을 알아보는 전문가의 판단을 다룬다. 이를 AI 협업에 가져올 때 내가 얻고 싶은 질문은 ‘어떤 단서를 보고 그렇게 판단했는가’다. 이 모델을 제시했다고 AI의 능력이나 학습 효과가 증명되는 것은 아니다.
답을 개선하는 동안 내 판단도 드러내기
질문을 수정할 때 왜 고쳤는지 적어보자. 답의 형식을 바꾸고 싶었는지, 필요한 조건이 빠졌는지, 문제 정의 자체가 달라졌는지 구분한다. 같은 수정처럼 보여도 하는 일은 다르다.
AI가 제안한 설명에는 맞는 부분과 내가 확인하지 않은 부분이 함께 있을 수 있다. 설명이 길고 논리적으로 보인다는 이유로 통째로 채택하지 않고, 현재 판단에 중요한 주장부터 원자료와 대조한다.
낯선 연결을 아이디어로 탐색하는 일도 가능하다. 다만 사실 오류를 창의성이라는 이름으로 유지해서는 안 된다. 가상의 설정으로 써볼 것인지, 실제 주장으로 사용할 것인지 먼저 구분해야 한다.
배웠는지는 다른 순간에 확인한다
대화가 끝난 뒤 AI 답을 보지 않고 핵심을 설명해 볼 수 있다. 어떤 조건에서 그 설명이 맞고, 상황이 바뀌면 무엇을 다시 봐야 하는지도 적는다. 설명이 막힌다면 그 부분으로 돌아가 질문을 바꾼다.
다른 사례에 적용했을 때도 확인이 필요하다. 예전 답을 그대로 가져왔는지, 달라진 조건을 찾아 수정했는지 살핀다. 한 번 잘 설명했다는 사실만으로 장기적인 학습을 단정할 수는 없지만, 무엇을 더 익혀야 하는지 단서는 얻을 수 있다.
내 제안은 모든 프롬프트 기술을 버리자는 명령보다 작업의 목적을 분명히 하자는 요청에 가깝다. 결과물을 빨리 만드는 일이 필요할 때도 있다. 배우려는 작업이라면 좋은 결과물을 얻는 것에 더해 자신의 이해와 판단이 어떻게 달라졌는지 확인하자는 것이다.
AI가 원하는 말을 찾는 데 몰두하기 전에 내가 어떤 문제를 보고 있는지 묻고 싶다. 답이 좋아진 이유를 설명할 수 있을 때, 질문을 고치는 일이 내 사고를 돌아보는 경험으로 이어질 수 있다.