“내 이름을 안다” 대 “내 프로젝트를 이해한다”: 차이점을 구분하는 방법

이름을 기억하는 것이 단순한 테스트에 불과한 이유

이름은 압축된 단일 정보입니다. 즉, 저장되거나 반복될 수 있고, 사용 가능한 대화나 계정 컨텍스트에서 가져올 수도 있습니다. 예를 들어 ChatGPT에서 메모리는 사용자가 제공한 세부 정보를 포함할 수 있으며, 해당 기능이 사용 가능하고 활성화되어 있을 경우 과거 대화의 관련 정보도 활용될 수 있습니다. 또한 제품 설명서에 따르면 메모리가 모든 세부 정보를 보존하는 것은 아니며, 사용 가능한 제어 기능은 요금제, 지역, 플랫폼 및 워크스페이스에 따라 다릅니다. 따라서 이름이 맞았다는 것은 답변 작성 시 그 세부 정보를 참조할 수 있었다는 점만 알려줄 뿐, 시스템이 주변 맥락을 얼마나 검색하거나 적용할 수 있는지는 보여주지 않습니다. OpenAI 도움말 센터, “Memory in ChatGPT”

창의적 프로젝트는 보통 무엇을 만드는지, 누구를 위한 것인지, 이미 결정된 사항은 무엇인지, 아직 정해지지 않은 것은 무엇인지, 어떤 종류의 제안을 원하는지 등 여러 사실과 선호 사항이 결합되므로 훨씬 더 풍부한 테스트가 됩니다. “당신은 알렉스입니다”를 반복하는 것은 하나의 라벨을 기억하는지 테스트하는 것입니다. 반면 정해진 프로젝트 개요에 맞는 세 가지 아이디어를 요청하는 것은 시스템이 여러 관련 세부 정보를 종합적으로 선택하고 활용할 수 있는지를 테스트합니다.

이러한 구분은 실용적인 차원이며, 모델이 인간과 같은 이해력을 갖추었는지에 대한 판결이 아닙니다. 유용한 질문은 모델이 제공받은 맥락을 다음 작업에 적용할 수 있는지, 그리고 결과물에서 그 적용 여부를 검증할 수 있는지입니다.

과제 수행에서 프로젝트를 ‘이해한다’는 것의 기준

일상적인 활용에서는 “내 프로젝트를 이해한다”는 표현을 관찰 가능한 일련의 능력에 대한 줄임말로 취급하세요. 유용한 답변이라면 정해진 사실 관계를 명확히 유지하고, 결정 사항과 가능성을 구분하며, 요청에 중요한 제약 조건을 준수하고, 누락된 세부 사항으로 인해 답변이 달라질 수 있을 때는 질문을 하거나 불확실성을 표시해야 합니다. 이것들은 작업 기준이므로, 결과물을 검토하고 이를 충족하는지 판단할 수 있습니다.

연구 결과들은 유창한 어조에만 의존하기보다 각 부분을 따로 테스트해야 하는 이유를 제시합니다. 2024년 언어 모델 벤치마크인 FollowBench는 지시문 제약 조건을 콘텐츠, 상황, 스타일, 형식, 예시 등의 범주로 구분합니다. 이 테스트에 따르면 제약 조건이 누적될수록 성능이 저하되었으며, 일부 범주는 다른 범주보다 더 까다로웠습니다. 이 벤치마크는 사용자의 개별 대화가 아니라 통제된 과제를 평가하지만, 답변이 그럴듯하게 들린다고 해서 합격점을 주는 대신 중요한 요구 사항을 각각 개별적으로 점검하는 유용한 습관을 뒷받침합니다. Jiang 외, “FollowBench: A Multi-level Fine-grained Constraints Following Benchmark for Large Language Models”

문맥 이해를 다룬 또 다른 벤치마크에서는 4개 과제와 9개 데이터셋에 걸쳐 언어적 특성을 테스트했습니다. 해당 연구진은 평가 결과 사전 학습된 밀집(dense) 모델이 선도적인 미세조정(fine-tuned) 모델에 비해 미묘한 문맥적 특성을 처리하는 데 어려움을 겪었다고 보고했습니다. 이 결과가 현재의 특정 어시스턴트가 사용자의 프로젝트를 어떻게 처리할지 직접 예측하는 것은 아니지만, 익숙한 단어를 찾는 데 그치지 않고 의미와 관계를 점검하는 것이 얼마나 가치 있는지를 확인해 줍니다. “Can Large Language Models Understand Context?”

프로젝트의 경우 이러한 관계는 다음과 같을 수 있습니다. “포스터는 동네 씨앗 나눔 행사를 위한 것임”, “행사 날짜는 아직 정해지지 않음”, “시각적 방향은 밝고 핸드메이드 느낌임”, “판매 홍보문처럼 들리는 표현은 피할 것”. “씨앗 나눔 행사”라는 말은 반복하지만 날짜를 임의로 지어내거나 톤을 무시하는 답변은, 주제는 기억했으나 개요를 제대로 따르지 못한 것입니다.

관찰 가능한 작은 프로젝트 점검 수행하기

실제로 도움이 필요한 작업과 유사하면서도 부담 없는 과제를 선택하세요. 대화창에 짧은 개요를 제공한 다음, 구체적인 결과물 하나를 요청합니다. 유용한 개요의 예는 다음과 같습니다. “동네 씨앗 나눔 행사를 위한 1페이지짜리 초대장을 만들고 있어. 날짜는 미정이니 넣지 마. 따뜻하고 진솔한 어조를 유지해 줘. 사람들이 라벨이 붙은 씨앗을 가져오길 바라지만, 참석은 누구나 가능해.” 그런 다음 제목과 짧은 초대 문단 하나를 요청해 보세요.

답변을 읽기 전에 개요를 간단한 체크리스트로 바꾸세요. 이 예시의 경우, 결과물이 다음을 만족하는지 확인합니다.

임의로 날짜를 지어내지 않았는가?

초대 대상을 모두에게 열어 두었는가?

가져올 준비물로 라벨이 붙은 씨앗을 언급했는가?

따뜻하고 진솔한 어조를 사용했는가?

요청한 제목과 문단을 제공했는가?

이 체크리스트는 검증된 과학적 테스트가 아니라 편집상의 보조 도구입니다. 그 가치는 오류를 명확히 드러내는 데 있습니다. 매끄럽게 작성된 문단이라도 제약 조건을 놓칠 수 있고, 투박한 답변이라도 개요를 정확히 따를 수 있습니다.

다음으로, 첫 번째 단계에 의존하는 두 번째 단계를 요청하세요. “이제 작은 표지판에 쓸 수 있도록 더 짧은 버전을 만들어 줘. 여전히 날짜는 넣지 말고, 초대는 모두에게 열려 있어야 해.” 형식이 바뀌어도 핵심 제약 조건이 유지되는지 확인하세요. 그런 다음 오류가 있다면 명시적으로 수정합니다(예: “‘숙련된 원예사분들을 위한’이라는 문구는 빼줘. 초보자도 환영이야”). 그리고 다음 수정본에서 다른 형태의 배제 표현을 다시 끌어들이지 않고 해당 내용이 실제로 제거되는지 살펴보세요.

자신감 있는 어조가 아닌 실행력을 평가하기

실용적인 점수표는 네 가지 부분으로 구성됩니다.

기억(Recall): 답변이 관련된 프로젝트 사실을 정확하게 사용하는가?

선택(Selection): 관련 없는 세부 정보를 나열하는 대신, 이번 특정 과제에 중요한 사실을 가져오는가?

적용(Application): 최종 작업물이 개요의 내용, 어조, 형식 제약 조건을 준수하는가?

업데이트(Update): 세부 사항을 수정한 후, 다음 버전에 해당 수정 사항이 반영되는가?

결과물에서 구체적인 증거를 찾으세요. 정해지지 않은 날짜를 유지한 표현, 요청한 문구의 등장, 또는 수정본에서 올바르게 유지된 수정 사항 등이 이에 해당합니다. “당신의 프로젝트를 기억하고 있습니다”라거나 “무슨 말씀인지 정확히 이해했습니다”와 같은 말에는 큰 비중을 두지 마세요. 그러한 말들이 향후 결과물에서 개요를 정확하게 반영할 것이라는 증거가 되지는 않습니다.

테스트는 과제에 비례하는 수준으로 유지하세요. 하나의 성공적인 답변은 해당 요청에 대한 증거일 뿐, 향후 모든 대화에서 일관된 성능을 보장하는 증거는 아닙니다. 프로젝트가 여러 대화에 걸쳐 진행된다면, 사용하는 도구의 메모리나 프로젝트 컨텍스트 기능이 켜져 있는지 확인하고 사용 가능한 제어 옵션을 검토하세요. ChatGPT의 경우, 설명서에서는 저장된 메모리와 대화 기록에서 가져온 정보를 구분하고 있습니다. 또한 메모리 요약에서 세부 정보가 생략될 수 있으며 컨텍스트 출처가 표시될 경우 검토할 수 있다고 안내합니다. 기능과 제어 옵션은 변경될 수 있으므로, 계정의 현재 제품 설정 및 도움말 페이지를 참조하세요. OpenAI 도움말 센터, “Memory in ChatGPT”

대화가 길어질 때는 특히 주의해야 합니다. “Lost in the Middle” 연구의 통제된 실험에 따르면, 테스트된 언어 모델이 관련 정보를 활용하는 능력은 긴 입력문 내의 위치에 따라 달라질 수 있으며, 중간보다는 시작이나 끝부분에 있는 정보에 대해 성능이 더 우수한 경우가 많았습니다. 이 연구는 특정 모델과 과제를 테스트한 것이므로 모든 어시스턴트가 사용자의 프로젝트 세부 정보를 놓칠 것이라고 단정하지는 않습니다. 하지만 중요한 결과물을 얻기 전, 특히 긴 대화를 나눈 후에는 중요한 몇 가지 결정 사항을 다시 언급해 주는 것이 현명한 작업 방식임을 시사합니다. Liu 외, “Lost in the Middle: How Language Models Use Long Contexts”

개요를 다루기 쉽게 만들기

답변이 기대에 미치지 못할 때는 그것이 무엇을 의미하는지 판단하기 전에 원인을 먼저 진단해 보세요. 시스템이 해당 정보에 접근할 수 있었는가? 세부 정보가 긴 대화 속에 묻혀 있었는가? 요청에 너무 많은 요구 사항이 섞여 있었는가? 원하는 스타일에 대한 선호가 너무 모호해서 구체적인 선택을 이끌어내지 못했는가? 이러한 가능성은 각기 다른 해결책을 필요로 합니다. 결정 사항을 다시 말해주거나, 개요를 줄이거나, 요구 사항을 글머리 기호로 나누거나, 원하는 스타일에 대한 구체적인 예를 들어주는 것입니다.

간결한 프로젝트 메모를 작성해 두면 반복되는 작업을 평가하기가 더 쉬워집니다. 프로젝트 목적, 대상 독자, 확정된 선택 사항, 미결 질문, 몇 가지 선호 사항 등 변하지 않고 유용한 세부 정보 위주로 작성하세요. 불확실한 세부 사항은 불확실하다고 표시하고, 변경된 결정 사항은 표시해 둡니다. 중요한 작업을 시작할 때는 대화창이 과거의 모든 세부 사항을 검색할 것이라고 가정하지 말고 프롬프트에 관련 부분을 직접 포함하세요. 이는 메모리 기능의 가변성과 맥락 활용에 관한 연구를 바탕으로 제안하는 작업 흐름 권장 사항일 뿐, 더 나은 결과를 보장한다는 약속은 아닙니다.

시스템이 사용자 이름은 정확히 맞히면서도 핵심적인 프로젝트 선택 사항을 반복해서 놓친다면, 이 두 가지를 별개의 관찰 결과로 취급하세요. 초안은 훌륭하게 작성했지만 다음 버전에 수정 사항을 반영하지 못한다면, 그 점도 기록해 두세요. 맥락을 제공하고 결과물을 점검한다면 유용한 어시스턴트는 여전히 시간을 절약해 줄 수 있습니다. 사용자의 테스트는 어떤 부분에 주의를 기울여야 하는지 알려줍니다.

실질적인 차이점

“내 이름을 안다”는 것은 개인 정보를 참조할 수 있었고 그것이 답변에 나타났음을 의미합니다. “내 프로젝트를 이해한다”는 것은 실제 작업에 관련 맥락을 반영할 수 있는지로 판단하는 것이 더 유용합니다. 즉, 확정된 결정을 보존하고, 요청된 제약 조건을 따르며, 형식을 조정하고, 수정 사항을 반영할 수 있는가입니다. 짧은 개요를 시도하고, 눈에 보이는 결과물을 체크리스트와 비교해 점수를 매긴 다음, 이후 단계에서 이 점검을 반복해 보세요. 그렇게 하면 친숙한 세부 정보나 자신만만한 주장을 신뢰할 수 있는 맥락 활용과 혼동하지 않고, 프로젝트의 실질적인 실행력을 구체적으로 측정할 수 있습니다.

이 주제 더 살펴보기