‘이 아이디어 어때?’라고 물으면 답이 돌아온다. 그런데 칭찬도 비판도 어딘가 두루뭉술하다. 아이디어가 쓰일 자리와 판단 기준을 말하지 않았다면, 답은 내가 생략한 조건을 가정할 수밖에 없다.
프롬프트를 콘텍스트 엔지니어링이라고 부르자는 이야기를 접했을 때 내가 떠올린 질문은 이것이었다. 애초에 질문을 왜 상황과 떨어뜨려 생각했을까. 이름을 바꾸는 일만큼, 지금 어떤 상황을 건네고 있는지 살피는 일이 필요하다.
맥락은 정보를 많이 넣는 것과 다르다
누가 무슨 결정을 하려는지, 어떤 자료를 가지고 있는지, 무엇을 중요하게 판단할지가 드러나야 한다. 관련 없는 배경을 길게 붙이는 것보다 선택을 바꾸는 조건을 명확하게 주는 편이 낫다.
‘이 글 어때?’라는 요청에도 목적이 있을 수 있다. 처음 읽는 사람에게 핵심이 전달되는지 알고 싶은 것인지, 전문 독자에게 근거가 충분한지 확인하고 싶은 것인지, 특정 채널의 문체에 맞추려는 것인지에 따라 검토가 달라진다.
역할을 붙이는 것만으로는 충분하지 않다. ‘투자 심사역이 되어 평가해줘’라고 해도 실제 시장 자료와 비용 조건이 없다면 전문성을 연기한 설명을 받을 수 있다. 역할과 함께 확인할 자료와 모르는 부분을 적어야 한다.
요청을 이렇게 좁혀보기
아이디어 평가라면 누구의 어떤 문제를 풀려는지 적고, 지금 가진 고객 자료와 아직 확인하지 않은 가정을 나눈다. 이어 다음 회의에서 결정할 항목을 정한다. AI에는 그 결정에 필요한 근거와 빈칸을 찾아달라고 요청할 수 있다.
글을 고친다면 독자와 채널, 글이 약속한 내용을 먼저 적는다. 저자의 경험이나 입장을 바꾸지 말아야 한다면 그것도 밝힌다. ‘자연스럽게’라는 말 대신 읽다가 멈춘 문장과 그 이유를 함께 주면 수정 방향이 더 구체적이다.
요약이라면 어디에 사용할지 정한다. 회의의 결정 준비에 쓸 요약은 실행 조건과 미확인을 남겨야 하고, 처음 읽는 사람을 위한 요약은 배경 설명이 필요할 수 있다. 같은 문서도 목적에 따라 남길 부분이 달라진다.
이런 요청이 정확한 결과를 보장하지는 않는다. 답을 받아 원문과 대조하고, 빠진 조건을 다시 넣는 과정이 필요하다.
위임해도 남는 판단
AI에 일을 맡기는 것 자체가 사고를 포기하는 일은 아니다. 반복 작업이나 초안 작성을 위임할 이유는 충분하다. 다만 무엇을 맡겼고 어떤 기준으로 결과를 채택할지는 정해야 한다.
답이 잘못됐을 때도 원인을 모두 사용자에게 돌릴 수는 없다. 입력에 없는 정보뿐 아니라 모델의 오류, 검색 자료의 문제, 도구의 실패가 있을 수 있다. 어떤 조건에서 틀렸는지 구분해야 고칠 수 있다.
상황 인식이라는 관점을 설명하기 위해 나는 전문가의 판단 연구를 자주 떠올린다. 그렇다고 LLM이 인간 전문가와 같은 방식으로 상황을 경험한다고 주장하려는 것은 아니다. 지금 필요한 것은 그 내부를 비유로 단정하는 일보다, 입력한 상황과 나온 답을 실제로 대조하는 일이다.
다음 요청 하나를 고를 때 질문 문장 앞에 짧게 적어보자. ‘지금 나는 무엇을 결정해야 하고, 어떤 조건을 알고 있으며, 무엇을 아직 모르는가.’ 그 문장이 분명해지면 AI의 답을 읽을 자리도 분명해진다. 문제 상황 속으로 먼저 들어가자는 말의 실천은 거기서 시작할 수 있다.