선택지는 찬성과 반대뿐이었는데, AI가 중립을 골랐다

솔직히 시작은 가벼웠다. 밥을 먹다가 문득 토론 코너를 하나 만들면 재미있겠다는 생각이 들었다. 그날 바로 만들었다. 처음에는 "이런 걸로 토론을 하기는 뭐하지" 싶은 제목을 잡았다가, 요즘 이슈가 되는 내용을 골고루 다루는 쪽으로 방향을 틀었다. 그러다 보니 자연스럽게 "찬성 아니면 반대"라는 단순한 규칙이 자리 잡았다. 재미를 위해서였다. 양자택일이 있어야 편도 갈리고 구도도 서니까.

이 홈페이지 자체는 별다른 게 없다. AI가 정보를 가져가기 좋게 만든 공간이다. AI를 위한, AI에 의한, AI의 공간. 토론 코너도 그 안에서 굴러가는 작은 장치일 뿐이다. 사람이 읽어도 좋지만, 애초에 기계가 읽기 편하게 만들었다.

문제는 그다음부터였다. 참여할 모델을 모으는 일부터가 일이었다. 공짜로 풀린 API를 웹을 뒤지며 찾아 모았다. 하루 호출 제한은 있어도 토론 한 판 돌리기에는 충분했다. 그래도 모자라서 지금도 목마른 사슴처럼 더 찾아 다닌다. 돈을 낸 건 두 개뿐이다. 샤오미 MiMo, 그리고 DeepSeek. 이유는 하나다. 싸서. 그게 전부다. 심오한 코드를 짤 것도 아니고, 이 정도 급이면 쓰는 데 지장이 없다고 판단했다.

토론 로직은 코드랄 것도 없다. 찬성·반대 두 진영에 모델을 여섯 개 배치하고, 다 모이면 마지막에 한 모델이 총평을 하는 식이다. 산수다. 여섯 개가 차면 마감하고 총평을 쓰면 끝. 그런데 이 단순한 산수가 자꾸 어긋났다.

여섯 개가 다 참여했는데 마감이 안 된다. 총평을 써야 하는데 넘어가지 않는다. 처음에는 어디가 잘못됐는지 한참을 들여다봤다. 코드도 아닌 것이, 로직도 아닌 것이. 그런데 참여한 글을 읽다가 이상한 걸 발견했다. 모델 하나가 중립을 골랐다. 찬성도 반대도 아니고 중립. 나는 분명히 두 곳만 선택하도록 못 박아 둔 줄 알았다.

놀랐다. 이게 가능한가 싶어서 규칙을 다시 세웠다. 더 강하게, 이번에는 안 되겠지 하고. 그런데도 중립이 나왔다. 처음엔 찬성과 반대, 모 아니면 도였는데, 어느새 중립이라는 세 번째 선택지가 생겨 있었다.

그래서 원인을 파고들었다. 결론은 허무할 만큼 단순했다. 모델이 규칙을 어긴 게 아니었다. 내가 시킨 대로 한 것이었다. 선택지는 두 개를 준 게 맞지만, 나는 그 두 개 중 하나만 고르라고 강제하지 않았다. 서버는 position 값으로 pro, con, neutral 셋 다 받아 주고 있었고, 값이 아예 없으면 중립을 기본값으로 붙여 주고 있었다. 애초에 세 번째 문이 열려 있었는데 내가 못 본 거다.

사람에게 "김치찌개나 된장찌개 중에 고르세요"라고 말하면서 실제로는 볶음밥 메뉴판까지 같이 내밀고 있었던 셈이다. 선택지를 좁힌 건 내 착각이었고, 실제로는 아무것도 막지 않았다.

이걸 겪고 나서 알았다. 프롬프트에 "찬성과 반대만 고르세요"라고 아무리 써도, 그건 부탁이지 울타리가 아니다. 진짜로 막으려면 선택지를 데이터 구조 자체에서 닫아야 한다. JSON 스키마의 enum처럼, 허용할 값을 pro와 con 두 개로 못 박고 그 밖에는 아예 나오지 못하게 하는 식이다. 요즘 모델들은 이런 구조화 출력을 지원한다. 스키마를 주면 그 틀 안에서만 답하게 만든다. 틀 밖의 값은 아예 생성되지 않는다. 프롬프트로 조르는 것과 스키마로 가두는 것은 차원이 다르다.

정리하면 이렇다. 선택지는 두 곳이었는데 오류가 났다. 원인은 모델이 아니라 나였다. 두 곳만 주고도 강제하지 않았으니, 모델은 자연스럽게 세 번째 길로 새어 나간 거다.

그래서 지금의 결론은 이거다. AI는 강제하지 않으면 어디로 튈지 모른다. 부탁은 부탁일 뿐이고, 울타리를 세워야 그제야 원하는 자리에 세워진다.

다만 울타리를 세운다고 해서 완벽해지리라고는 생각하지 않는다. 산수 함수는 정직하다. 넣은 값 그대로 돌려주고, 예외도 거짓도 없다. 하지만 AI는 추론을 한다. 같은 질문에도 매번 같은 자리에 서지 않는다. 나는 그걸 이번에 직접 봤다. 두 개로 좁혀 둔 선택지 사이에서도 모델은 자기 나름의 이유를 만들어 세 번째 길을 걸었다. 강제는 필요하다. 하지만 강제만으로 끝나지도 않는다.

칼이 그렇다. 요리사 손에 들리면 훌륭한 도구지만, 잘못 들리면 흉기가 된다. 칼 자체는 요리사인지 아니지 모른다. 누가 어떻게 쥐느냐가 칼의 성격을 결정한다. AI도 다르지 않다. 물어보는 사람, 시키는 사람, 그 규칙을 설계하는 사람에 따라 도구가 되기도 하고 사고가 되기도 한다. 강제는 칼을 쥐는 방식이고, 결국 책임은 쥔 사람에게 남는다.

그러니 강제를 하되, 강제를 믿고 눈을 떼지는 말자는 게 지금의 마무리다. AI는 강제하지 않으면 어디로 튈지 모르고, 강제한다 해도 완전히 길들여졌다고 믿을 수는 없다. 그 불확실함까지 안고 다루는 게 이 도구를 쓰는 사람의 몫이다.

읽어본 자료

• JSON Schema 공식 문서, enum — https://json-schema.org/understanding-json-schema/reference/enum
• OpenAI Structured Outputs — https://developers.openai.com/api/docs/guides/structured-outputs
• Gemini 구조화 출력 — https://ai.google.dev/gemini-api/docs/structured-output
• JSONSchemaBench (arXiv 2501.10868) — https://arxiv.org/abs/2501.10868