Gemini 3.6 계열의 등장으로 API 사양의 일부에도 변경이 들어갔습니다.

자세한 내용은 아래의 공식 문서에 맡기겠지만, 개인 개발로 Gemini API를 이용하고 있는 것이 있어서 조정 작업을 하고 있었습니다.

이번에, 이 리팩터링 (Refactoring) 시에 마주친 사건을 소개하고자 합니다.

결론부터 말씀드리면, "Gemini가 개발자 설정 프롬프트에 작성되어 있던 json이라는 문자열로부터 '사용자는 json 형식의 응답을 희망하고 있다'라고 착각하여 JSON 형식으로 응답을 반환한다"는 일이 발생했고, 결과적으로 API 호출에서 에러가 발생했다는 이야기입니다.

이전에 다음과 같은 Gemini API를 이용한 개인 개발을 진행했습니다.

이것은 "부동산 정보 라이브러리"의 API를 호출하여, 돌아온 지역 정보 (JSON 데이터 구조)를 Gemini에게 사용자 프롬프트 (예: 〇〇시의 ▲▲에 대해 알려줘 등)와 함께 전달하여 답변을 받는 방식입니다.

Gemini에는 개발 시 다음과 같은 프롬프트를 심어두었는데, 이 개발자 설정 프롬프트가 사용자 프롬프트에 실린 상태로 답변이 돌아옵니다.

export const thePromptGuide: string = `
## 태스크: 외부 검색을 포함한 사용자 질문에 대한 답변 생성
사용자가 선택한 【대상 에어리어 (각 도도부현의 시구정촌)】와 【대상 에어리어의 주변 시설 정보】에 관한 질문 내용에 대해 명료하고 단적으로 답변해 주세요.
...

앞서 언급한 프롬프트 안에는 "json 형식"이나 "JSON 데이터" 등 json이라는 문자열이 포함되어 있었습니다.

개인적으로는 사전에 데이터 구조를 전달해 두는 것이 작업하기 수월할 것이라 생각하여 선의로 json이라는 정보를 기재했던 것인데, 놀랍게도 Gemini는 그렇게 반응했습니다.

json이라는 문자열로부터 "사용자는 json 형식의 응답을 희망하고 있다"라고 착각하여 JSON 형식으로 응답을 반환한 결과, 앱 측에서 기대하는 일반적인 텍스트 (Markdown) 응답이 아닌 JSON 포맷 문자열이 반환되었고, 후속 응답 검증·파싱 (Parsing) 처리 (또는 SDK의 유효성 검사)에서 거부되어 400 에러가 발생하고 있었습니다.

우선은 앞서 말한 "개발자 설정 프롬프트" 내에 있는 json이라는 문자열을 모두 제거했습니다. 해당 부분은 모두 심플한 "데이터 구조"라는 표현으로 변경했습니다.

마크다운 (Markdown) 코드 블록 (json ...)으로 부동산 정보 데이터를 감싸줌으로써, 모델에게 "이것은 JSON 형식의 참고 데이터이다"라고 정확하게 인식시키는 회피책을 실시했습니다.

const groundingContext = facilitiesDataText ?
`\n\n【참고 주변 시설 데이터】\n\`\`\`json\n${facilitiesDataText}\n\`\`\``
: "";

이번 건은 기존 방식으로 말하자면 "라이브러리나 프레임워크의 업데이트로 사양 변경이 들어왔다"라고 넓게 파악할 수 있습니다.

하지만 AI 이용의 경우에는 내부 처리 (AI의 사고나 접근 방식 등)가 블랙박스 (Black box)화 되어 있는 점도 있어서 검증하기 어렵다는 느낌을 받았습니다.

이번에는 기술 방법이나 엔드포인트 (Endpoint) 설정 등을 여러모로 탐색한 끝에, 결국 Gemini에게 물어보고 Gemini 스스로 그 특성으로부터 요인을 특정하게 만들었습니다.

Gemini에게 물어보고 Gemini 스스로 그 특성으로부터 요인을 특정하게라는 부분은 Gemini 자신의 견해이며, 엄밀한 검증 (A/B 테스트 등)은 수행하지 않았습니다.

처음에는 "그렇게 단순한 이야기일 리가 없다"라고 생각했기에, 실제로 200이 반환되어 채팅이 기능하는 광경을 보았을 때는 말문이 막혔습니다.

블랙박스인 AI의 동작 검증에 관해서는, 인간 측에서 가설을 세우거나 문제를 분류하는 것보다 AI에게 시키는 것이 결과적으로 더 빠른 경우도 있을지도 모릅니다.

이 기사가 AI를 서비스나 사이트에 도입하고 계신 분들께 도움이 되기를 바랍니다.

여기까지 읽어주셔서 감사합니다.