답변은 깔끔하고, 형식이 잘 갖춰져 있으며, 확신에 차서 도착합니다. 하지만 실행해 보면, 해당 설정 플래그(config flag)는 존재하지 않습니다.

응답의 그 어떤 부분도 모델이 확신하는 부분과 임의로 채워 넣은 부분 사이의 차이를 알려주지 않았습니다. 구문(syntax)은 올바랐습니다. 설명은 합리적이었습니다. 플래그의 이름은 타당했고 목적도 명확했습니다. 단지 실재하지 않을 뿐이었습니다.

이것은 신뢰의 문제가 아니라 보정(calibration)의 문제입니다. "AI를 믿지 마세요"라는 조언은 쓸모가 없습니다. 그 조언은 모든 것을 의심하라고 말하는데, 이는 아무것도 의심하지 않는 것과 같습니다. 실제로 그런 방식으로 일할 수는 없기 때문입니다. 대신 여러분에게 필요한 것은 답변의 어느 부분이 근거(grounded)가 있고 어느 부분이 임의로 채워졌는지 구별할 수 있는 방법입니다. 찾아내야 할 패턴들이 있으며, 일단 그 패턴을 알고 나면 놓치기 어렵습니다.

🔍 이것이 특히 초보자에게 영향을 미치는 이유

이것은 지능의 문제가 아닙니다. 경험의 문제입니다.

몇 년의 경력을 가진 엔지니어는 이미 존재하지 않는 함수 때문에 시간을 허비해 본 경험이 있습니다. 그들은 다른 엔진에 속한 것으로 밝혀진 설정 파라미터(config parameter) 때문에 오후 시간을 허비해 보기도 했습니다. 그들은 "맞아 보였지만 사실은 아니었던" 기억들을 수집해 왔으며, 이제 그 기억들은 자동으로 활성화됩니다. 실행하기 전에 _이것 좀 확인해 봐_라고 말하는 작은 직감이 생기는 것입니다.

초보자들은 아직 그런 오후를 겪어보지 못했습니다. 반복된 실패로부터 오는 패턴 인식(pattern recognition)이 존재하지 않는데, 왜냐하면 아직 실패를 경험하지 않았기 때문입니다. 모든 답변이 동일하게 확신에 찬 어조로 전달되며, 비교할 과거의 실수가 없기에 근거 있는 답변과 지어낸 답변을 분리해낼 내부 신호가 없습니다.

이것은 성격 결함이 아닙니다. 경험의 부재일 뿐이며, 이는 찾아봐야 할 세 가지 구체적인 요소로 부분적으로 대체될 수 있습니다.

✅ 세 가지 신호

이 방법들이 완벽하지는 않습니다. 이것들은 최소한의 기준이며, 흔히 발생하는 사례들을 잡아냅니다. 마지막에 이 방법들이 놓치는 부분에 대해 명확히 말씀드리겠습니다.

신호 1: 출처가 없는 매우 구체적인 세부 정보

답변에 정밀한 세부 정보(특정 설정 플래그 (config flag), 특정 함수 시그니처 (function signature), 정확한 버전 번호 등)가 포함되어 있지만, 그 정보가 어디에서 왔는지 명시하지 않는다면, 그 부분이 답변에서 가장 위험도가 높은 부분입니다.

근거가 있는 (Grounded) 답변은 모델이 확신이 없을 때는 일반적인 내용을 말하고, 확신이 있을 때는 구체적인 내용을 말하는 경향이 있습니다. 반면, 지어낸 답변은 출력물에 눈에 보이는 불확실성 신호가 없기 때문에 종종 모든 부분에서 구체적입니다. 실제 Spark 설정 파라미터와 지어낸 파라미터는 외관상 완전히 동일하게 보입니다.

확인 방법: 만약 어떤 세부 정보가 코드에 바로 복사해서 쓸 수 있을 정도로 구체적이라면, 코드를 실행하기 전에 사용 중인 버전의 실제 문서에 해당 내용이 존재하는지 확인하십시오. 논리가 타당한지 확인하는 것이 아니라, 그 대상 자체가 실제로 존재하는지를 확인해야 합니다.

듣기에 그럴듯하고, 명명 규칙 (naming convention)을 따르며, 정확히 필요한 기능을 제어하는 것처럼 보이는 Spark 설정 플래그가 정작 존재하지 않는다면, 그것이 바로 신호 1입니다.

신호 2: 존재하지만 다른 도구에 있는 함수

이는 신호 1과 밀접하게 관련되어 있지만, 다른 형태로 나타납니다.

Snowflake에서 특정 작업을 수행하는 방법을 물었습니다. 답변은 깔끔한 구문과 합리적인 이름을 가진, 당신이 정확히 필요로 하는 기능을 수행하는 함수를 사용합니다. Snowflake 문서를 확인해 보니 해당 함수가 없습니다. 더 찾아보니, 그 함수는 BigQuery에 존재합니다.

그 함수는 실재합니다. 기능도 실재합니다. 단지 다른 엔진에 속해 있을 뿐입니다. 이는 완전히 지어낸 함수보다 더 위험합니다. 왜냐하면 '거의' 맞기 때문입니다. 해당 함수에 대한 문서를 찾을 수는 있지만, 당신의 시스템을 위한 문서는 아닙니다.

확인 방법: 생소한 함수가 등장하면 일반적인 웹 검색이 아니라, 반드시 당신의 엔진에 특화된 문서를 통해 확인하십시오. "이 함수가 존재하는가"와 "이 함수가 Snowflake에 존재하는가"는 서로 다른 질문이며, 오직 두 번째 질문만이 중요합니다.

신호 3: 중요한 문맥을 제거해도 변하지 않는 답변

이는 가장 눈에 띄지 않으면서도 가장 신뢰할 수 있는 신호입니다.

이것을 시도해 보세요: 특정 제약 조건(constraint)을 가지고 질문합니다. 답변을 얻습니다. 그런 다음 그 제약 조건을 제거하고 같은 질문을 다시 합니다. 만약 답변이 거의 변하지 않는다면, 해당 제약 조건은 실제로 사용되지 않았다는 의미이며, 이는 모델이 일반적인 답변을 생성한 후 당신의 세부 정보로 포장했을 수 있음을 의미합니다.

예를 들어: 5억 개의 행과 날짜 컬럼에 대한 높은 읽기 트래픽(read traffic)을 가진 테이블에 대한 파티션 전략(partition strategy)을 요청한다고 가정해 봅시다. 상세한 답변을 받습니다. 이제

목표는 모든 잘못된 답변을 제거하는 것이 아닙니다. 특정 패턴을 따르는 답변들을 저렴한 비용으로 잡아내어, 여러분의 실제 사고 시간을 패턴을 따르지 않는 답변들에 집중할 수 있도록 하는 것입니다.

🎯 핵심 요약 (The takeaway)

세 가지 신호. 실행하기 전에 확인하세요.

1. 출처가 없는 매우 구체적인 세부 정보. 만약 코드에 바로 붙여넣을 수 있을 정도로 구체적이라면, 해당 내용이 사용 중인 버전의 문서(documentation)에 실제로 존재하는지 확인하십시오.

2. 잘못된 도구의 함수 사용. 일반적인 검색이 아니라, 여러분이 사용하는 엔진(engine)을 기준으로 구체적으로 확인하십시오.

3. 컨텍스트(context)를 제거해도 변하지 않는 답변. 핵심 제약 조건(constraint)을 제거하고 다시 질문해 보십시오. 만약 답변이 동일하다면, 모델은 여러분의 컨텍스트를 사용하지 않은 것입니다.

이 방법들이 모든 것을 잡아내지는 못할 것입니다. 하지만 패턴을 따르는 실패 사례들을 잡아낼 수 있으며, 바로 그 사례들이 현재 여러분의 시간을 가장 많이 낭비하게 만들고 있습니다.

이 글은 데이터 엔지니어를 위한 AI 실무 시리즈의 두 번째 포스트입니다. 다음 편: 데이터 엔지니어링에서 가장 덜 사용되는 프롬프트 (The Most Underused Prompt in Data Engineering).