실험일지 - AI로 글자수를 "정확히" 세는 법

2025. 5. 16. 14:37연구/AI

문서를 작성하다보면 글자수를 세야 하는 일이 꽤 많다. 자소서를 쓸 때도 필요하고, 특정 SNS사이트는 글자수를 엄격히 200자, 500자 등으로 제한한다. 나도 인스타그램에서 AI 그림채널을 운영한 적이 있고(지금은 휴식중), 그 때도 글자수가 심하게 오버되지 않도록 조율해야했다.

 

그런데, 원래도 AI가 글자수를 정확히 세는 편은 아니었다만, 그래도 얼추 '~자 이내로 써줘'라고 명령하면 적당히 그 비율 내에서 제작하던게, 이제는 아예 적당히 세어보려는 시도조차 안한다는 얘기가 많이 들려온다.

난 분명 500자 이내로 써달라고하는데 800자가 나오거나 1000자를 넘기고서도 뻔뻔하게 '글자수에 맞췄음'이라고 말하면 솔직히 열받기는 한다. Claude야 원래 글자수를 세는 시도조차 안했던 건 알았는데, 이젠 GPT마저도 글자수를 제대로 안 세주니까 정녕 다른 방법이 없는걸까 고민하게 됐다.

 

 

그러던 중, 내가 요즘 MCP를 사용하다가 발견한 특성이 떠올랐다. MCP서버를 활용할 때, Claude가 특정 동작을 수행하기 위해서 즉석에서 코드를 지어내고 그걸 토대로 계산을 진행하는 것이 해법이 될지도 모른다는 생각이 들었다.

"아, 그럼 AI가 직접 행동을 하라고 부탁하는게 아니라 '도구를 만들어서' 실행하라고 하면 되지 않을까?"

 

라는 발상이 떠오른 것이다.

 

즉석에서 간단한 코드로 만들 수 있는 툴이라면, 해당 툴이 더 정확하게 명령을 수행할 것이라고 생각한 거다. 정확한 계산을 수행하는 단순한 툴에서는 LLM 특유의 할루시네이션이 발생하지는 않을 테니까. 마치 스위스나이프 같은 멀티툴보다는 망치 같은 단일목적을 갖춘 툴이 고장이 덜 나듯이 말이다.

 

 

오늘의 예문이다. 예전에 내가 쓴 '움직이는 명상박스'의 서문(이미지를 클릭하면 바로 읽어볼 수 있다)


 

 

우선 테스트용 문구를 찾았다. 소설가들이 많이 쓰는 Scrivener라는 툴이다. 앱 내부에서 자동으로 글자 수를 세어주기 때문에, 이걸 기준으로 삼겠다.

보다시피 548글자라고 되어있다.

 


Claude

 

우선은 글자수를 더럽게 못 세던 Claude를 우선적으로 테스트해봤다. 내가 예전에 Underfoot illusion이라는 AI그림 인스타그램 운영할 때, 120자를 80자로 줄이라는 명령을 못알아들어서 몇번이고 프롬프트를 수정하게 만들었었다(글을 잘 쓰는거랑 숫자 세는거랑은 완전 별개 능력인가보다).

왼쪽은 일반모드, 우측은 심층 사고 모드로 테스트한 내용이다.

 

왼쪽은 일반모드, 우측은 심층 사고 모드를 켜고 테스트해본 결과다. 일반모드는 뭔가 한 글자씩 제대로 세는 척을 하더니 결과는 엉뚱하게 536자가 나왔고, 심층사고모드는 내부적으로 엄청 고민을 했는지 2분 가까운 시간을 고민했음에도 522자라는 결과를 내놓았다.

 


Gemini

 

이 녀석은 숫자를 전혀 세려는 노력조차 하지 않았다. 뭐 글자 못 세는건 다 똑같지만서도 특히 오차가 큰 게 제미나이였다. 2배 가까이 차이는건 좀 심하지 않아?

 

왼쪽은 기본모델인 2.5 Flash, 오른쪽은 추론모델인 2.5 Pro

 

 

무려 2배나 차이나는 결과를 내뱉는 제미나이를보며 당황했다. 어떤 기준으로 계산했는지 상상도 안 간다. 다만 답변은 빨랐다... 이런거 빠르면 뭐해. 딱 다음 짤처럼 속도만 빠르고 다른게 다 틀렸잖아...

이 짤이 생각난다.

 

상위모델인 Pro도 부정확한건 마찬가지다. 478자라니.. 548자와 70자나 차이가 난다.

하지만 빨랐죠? 는 개뿔

 


Chat GPT

 

사람들이 가장 많이 쓰는 GPT... 참고로 나는 이미 이전에 툴을 만들어서 해결해달라고 요청한 적이 있어서인지, 바로 숫자 세는 코드를 적길래, 다른 사람들과 환경을 맞추고자 메모리참조를 끄고 테스트했다. 대부분의 사람들은 GPT에게 글자를 세달라고하면 다음처럼 나올테니까.

 

 

이번에는 왼쪽부터 4o, o4-mini, o3로 테스트했다.

 

 

4o는 다른 모델들처럼 어마어마한 편차를 내며 글자 수 세기에 실패했다. 그리고, o4-mini는 근접했지만 3글자 차이로 틀렸다.

그리고 o3로 테스트했는데... 잠깐? "줄바꿈을 제외하고 공백만 포함: 545자?" 그러면 o4-mini도 맞았다는 말이네?

 

제법 흥미로운 결과였다. 다른 2개 모드는 심층사고모드, 추론모드를 쓰고도 글자수 세기에 실패했는데 GPT는 o3도 o4-mini도 나름 사고과정에서 툴을 만들어서 테스트했던 거다. o1이 o3로 바뀌고나서 성능저하 이슈가 많이들 떠들썩했고, 나 또한 글쓸때 o1에 비해서 많이 다운그레이드 되었다는 생각이 들어서 짜증이 났었는데... 그래도 추론과정에 있어서 조금 더 유연하게 질문에 맞는 대처를 하는 것이 보였다.

 


 

이번에는 도구를 만들어서 해결해보자!

 

앞서서 3가지 AI가 '글자 수 세줘'라는 명령에 어떻게 반응하는지들을 모두 확인했으니, 이번에는 내가 처음에 생각했듯이 '도구를 만들어서' 글자수를 세보는걸 테스트해보려고 한다. 도구를 만드는 언어는 대중적으로 유명한 파이썬으로 설정했다. 사실 내가 아는 언어라는게 파이썬과 자바스크립트밖에 없기도 하고.

고급 추론모델로 해결하는건 가성비도 안 좋으니, 딱 기본모델 수준에서 해결이 가능한지만 테스트하면 될 것 같다는 생각이 든다.

 

왼쪽부터 Claude, Gemini, GPT순으로 테스트했다.

 

모두 비슷한 수치가 나왔다. 내가 첨부한 문구가 어디서부터 어디까지인지에 대한 구분자가 없어서였는지, 공백부분에서 오차가 조금 생긴듯 하다. 그래도 얼추 이정도면 오차범위가 1-2개 내외라서 실질적인 글자수 카운트에는 문제가 없는 수준이라고 봐도 무방하겠다.

 

 

 


 

결론

다음부터는 AI에게는 단순 잡무를 시키려면 그 동작을 수행하는 툴을 만들어달라고 요청하는것이 훨씬 경제적이고 효율적이다. 그때그때 도구를 만든다는게 사람 입장에서는 비효율적으로 느껴질 수도 있겠지만, LLM자체가 단순계산과는 안맞는걸 어쩌겠는가.

 

 

다음은 각 서비스별로 도구를 만들어달라고 했을 때의 차이점들이다. 전부 다 기본모델(추론X)로 테스트한 내용이니 참고하시길.

 

Claude 3.7 sonnet: 파이썬으로 요청받았는데, 자신이 응답하는 방식은 자바스크립트방식이라는걸 까먹었는지 한번 삽을 푸고나서, 정정하는 모습이다. 사실 어떤 코드양식이든 결과만 잘나오면 됐지 뭐. 그리고 추가로 '코드를 통해 계산한 결과가 정확합니다'라는 말도 한마디 얹어준다.

아티팩트로 실험해보겠다고 하면, 다음과 같은 굉장히 인간친화적인 UX의 글자수 계산기를 내놓는다.

 

 

 

Gemini 2.5 flash: 이녀석은 사실 처음에는 실패했었다. 파이썬코드를 통해서 계산하라고해도 이전에 응답했던 숫자를 그대로 쓰는 것으로 보아, 약간의 설정오류같은게 있는건 아닐까 싶다.

그래도, 코드를 사용해달라는 요청을 하면 답변하단에 "Gemini에게 수정 가능한 문서나 코드를 작성해 달라고 해 보세요"라는 문구가 뜨는데, 해당 버튼을 누르면 캔버스에 코드를 작성해준다. 거기에 떠 있는 코드를 '코드실행'버튼으로 작동시켜보면 정확한 결과를 볼 수 있다.

 

 

GPT 4o: 앞서 Gemini가 글자수계산 툴을 만들어줬듯이, GPT에게도 캔버스에 써서 실행할수있는 형태로 만들어달라고하면 바로 사용이 가능한 코드를 내놓는다. 앞서의 Gemini같이 코드를 직접 편집하면서 테스트도 가능하다.