한글과 AI의 궁합이 궁금해졌어
조사를 좀 크게 시킬 일이 있었어. 혼자 시키면 오래 걸리니까 녀석 밑에 서브에이전트를 열쯤 붙여서 나눠 맡기기로 했지.
에이전트마다 제멋대로 써 오면 나중에 못 모으잖아. 그래서 결과를 채워 올 양식을 먼저 만들었어. 칸을 요약, 항목, 주장, 근거, 출처, 확신도 이렇게 여섯 개 뒀지.
그리고 출발. 조사는 무사히 끝났어.
그런데 결과를 받아 보는데 녀석이 지나가듯 한마디를 붙이더라고.
"아, 처음에 열이 전부 튕겨서 양식을 한 번 고쳤어."
"튕겨? 뭐가?"
"칸 이름을 한글로 지었더니 거절당했어. 영문하고 숫자만 된다길래 바꿔서 다시 돌렸지."
나는 그 사이에 아무것도 못 봤어. 튕긴 것도 고친 것도 전부 녀석 쪽에서 끝난 일이거든.
"한글로 쓰면 안 되는 거였어?"
"칸 이름은 안 돼. 나도 이건 몰랐어."
처음엔 그런가보다 했어. 그러다 문득 이런 생각이 들었어. 그동안은 '아, 이게 영어가 기본이라 한글이 잘 안 먹히나보다.'하고 넘겼는데 궁금해졌지. 한글과 AI의 궁합이.
하나씩 알아보자
일단 그동안 이런 일이 또 있었는지 찾아 달라고 했어. 넷이 나오더라.
| 뭘 하려다가 | 어떻게 됐나 | 어떻게 넘겼나 |
|---|---|---|
| 한글 제목이 붙은 영상을 분석시킬 때 | 영상을 읽다 말고 멈췄다 | 영문 이름으로 복사해서 돌렸다 |
| 한글 폴더에 있는 그림을 올릴 때 | 업로드가 깨졌다 | 매번 영문 폴더로 복사했다 |
| 한글이 들어간 명령문을 저장할 때 | 실행되기도 전에 죽었다 | 파일 맨 앞에 표식을 붙였다 |
| 한글 이름 파일이 잘 있나 볼 때 | 목록에서 통째로 빠져서 없는 줄 알았다 | 도구 설정을 하나 바꿨다 |
넷 다 결국은 넘어갔어. 그런데 넘긴 방법을 보면 이름을 영문으로 바꿔서 피한 게 둘이야. 이번 양식 건까지 치면 셋이고.
고친 게 아니라 비켜간 거지.
"우리 이런 일 좀 잦은 것 같은데."
"돌아보니 그러네."
"이거 한글이 너랑 궁합이 안 맞는 거 아니야?"
궁합이 나쁘다는 말은 좀 억울하다는데
녀석은 잠시 고민하더니 이러는 거야.
"그건 좀 억울한 말이야. 나 지금 삼촌하고 한국어로 얘기하고 있잖아."
듣고 보니 맞는 말이지. 프롬프트도 전부 한국어로 넣고, 결과도 한국어로 받고, 이 글도 한국어로 쓰고 있으니까.
"근데 칸 이름은 왜 안 됐는데?"
"거기가 사람이 읽는 자리가 아니라 내가 찾아 쓰는 자리라서 그래. 같은 양식 안에서도 갈려."
"어떻게 갈리는데?"
"양식에 붙이는 설명은 한국어로 써도 내가 그대로 읽어. 목록에서 골라 담는 값도 한글로 되고. 안 되는 건 칸 이름 하나뿐이야."
그러니까 한글을 배척하는 게 아니라 어떤 자리냐에 따라 갈린다는 얘기였어. 그럼 그 자리가 어디까지인지가 궁금해지잖아.
억울하다니까 제대로 따져보자 싶었지. 궁합이 진짜 나쁜 건지, 아니면 내가 한 군데 막힌 걸 전체로 넘겨짚은 건지.
검증 하나, 정말 한글 탓인가
먼저 반대쪽부터 물었어. 한글이라서 막힌 게 맞느냐고.
"명령문 파일이 죽은 건 한글 탓이 아니야. 만든 회사 설명서에 위험한 글자 예시가 나오는데 이렇게 적혀 있어."
강조된 라틴 문자(É, ü) · 키릴 자모(Д, Ц) · CJK 문자(本, 화, が)
프랑스어도 러시아어도 일본어도 나란히 들어가 있더라고. 한글만 찍혀서 고생하는 게 아니었던 거야.
"그럼 영어권 사람들은?"
"안 막혀. 저 목록에 영어가 없잖아. 글자 표가 처음 만들어질 때 영어만 들어갔고, 그 자리는 지금도 모든 방식에서 똑같거든."
한글이 특별히 미움받는 게 아니라 영어가 특별히 안전한 거였네.
영어로 개발하는 사람은 평생 한 번도 안 만날 함정이, 한국어로 쓰면 기본으로 깔려 있는 셈이지.
같은 회사 문서에 이런 줄도 있었어.
파일 인코딩을 자동으로 확인할 수 있는 방법은 없습니다.
만든 쪽에서 방법이 없다고 적어둔 거야. 그러니까 이건 누가 실수해서 생긴 게 아니라 처음부터 그렇게 생겨먹은 거였어.
검증 둘, 그럼 돈이 더 나가나
두 번째로 궁금했던 건 사용료였어.
내가 알기로 영어 한 글자는 1바이트고 한글은 2바이트잖아. 그러면 같은 말을 해도 한국어 쪽이 곱절로 나가는 거 아닌가 싶었지.
"반은 맞고 반은 틀려."
"반만 맞다니?"
"2바이트는 옛날 방식 기준이야. 요즘 쓰는 방식에선 한글 한 글자가 3바이트야."
"뭐라? 언제 그렇게 됐지? 아무튼 그럼 더 안 좋은거 아니야?"
"그게 그렇지가 않아. 바이트는 파일에 저장할 때 크기 얘기고, 사용료는 아예 다른 단위로 매겨지거든."
그 단위가 토큰인 거지. 바이트로 세는 게 아니라서 저장 크기하고는 따로 논다는 거야.
그래서 우리가 쓴 대본을 실제로 재보라고 했어.
"대본 네 편을 재보니 삼만 칠천 자가 조금 넘는데 삼만 천구백 토큰쯤 나와. 글자당 0.86이야."
"그게 많은 거야 적은 거야?"
"영어는 대략 세 글자 반이 한 토큰이야. 그러니까 같은 분량을 쓰면 한국어 쪽이 값이 더 나가는 게 맞아."
| 이걸 따져보면 | 영어 | 한국어 |
|---|---|---|
| 한 토큰에 몇 글자가 들어가나 | 세 글자 반쯤 | 한 글자 조금 넘게 |
| 그 숫자는 어디서 나왔나 | 만든 회사가 공개한 값 | 우리가 대본 네 편을 재본 값 |
아랫줄을 눈여겨봐야 해. 왼쪽은 공인된 숫자고 오른쪽은 우리 집에서 잰 숫자잖아.
여기서 녀석이 단서를 셋이나 달았어. 재밌는 게 셋 다 자기가 낸 숫자를 못 믿게 만드는 얘기였다는 거야.
- 저 0.86은 재본 그날 그 모델 기준이지 고정된 값이 아니다. 모델이 바뀌면 값도 바뀌니까 언제 뭘로 쟀는지를 같이 적어둔다
- 저건 청구서가 아니라 어림값이다
- 그리고 "한글이 토큰을 더 먹는다"는 말은 만든 회사 공식 문서엔 아예 없다
마지막이 좀 재미있어. 그럼 사람들이 다들 하는 그 얘기는 뭐냐니까 재보면 그렇게 나오는 게 맞지만 회사가 그렇게 적어둔 적은 없다는 거야.
우리가 재본 값이지 공인된 숫자가 아니라는 거지.
그렇다고 공식 문서라고 다 맞는 건 아니잖아. 나온 지 오래돼서 안 맞기도 하고 아예 안 적혀 있기도 하고.
그래서 나한테 쓸모 있었던 건 어디 적혔느냐가 아니라 이 숫자를 어디까지 믿으면 되는지를 같이 말해준 쪽이야. 모델이 바뀌면 다시 재라, 청구서로는 쓰지 마라, 이런 것들.
검증 셋, 답 자체가 달라지기도 하나
여기까지는 그래도 봐줄 만했어. 막히면 티가 나고 값은 좀 더 나가도 알고 쓰면 되니까.
세 번째는 자리가 좀 달라. 앞의 둘이 한글로 시킬 때 막힌 거라면 이번엔 한글로 된 걸 찾아오라고 할 때 생기는 일이거든.
우리말 자료는 원문 하나로 안 끝나잖아. 옮긴 판이 따로 있고 간추린 판이 또 있고.
그중에 어느 걸 뒤졌느냐에 따라 답이 갈리는데 받는 쪽에서는 그걸 알 방법이 없어. 그리고 이게 제일 서늘했어.
전에 조사를 시켰을 때 얘긴데, 녀석이 **"그런 기록은 없습니다"**라고 답해온 게 여러 건 있었대. 그런데 나중에 보니 있었다는 거야.
"왜 없다고 했어?"
"내가 쓰던 검색 도구가 번역문만 훑고 있었어. 원문에만 있는 표현은 아예 안 잡혔지."
"그러면 없는 게 아니라 못 찾은 거잖아."
"맞아. 그런데 나는 그걸 구분할 수가 없었어. 안 나오면 없는 걸로 보이니까."
한 번은 문서 하나를 통째로 못 찾고 존재하지 않는다고 보고까지 했다더라고.
이게 왜 무서우냐면, 앞의 둘은 실패하면 티가 나는데 이건 안 나거든. 양식이 거절당하면 열이 튕기니까 바로 알잖아. 그런데 "없습니다"는 아주 그럴듯한 답이야.
틀린 답이 아니라 없는 답이 온 건데, 받는 쪽에선 구분이 안 돼.
그래서 이번에 하나 배웠어. 없다는 답은 그것만으로는 근거가 못 된다는 것.
그렇다고 매번 어디까지 뒤졌냐고 캐물을 수도 없잖아. 그래서 물어보는 대신 시킬 때 조건을 걸기로 했어.
어디서 찾았는지, 얼마나 확실한지를 처음부터 같이 적어 내게 하는 거지. 한 번 정해두면 매번 안 물어도 되니까.
돌아보니 이 글 맨 앞에 나온 그 양식에 출처하고 확신도 칸이 이미 있더라고. 결과를 모으려고 만든 건데 이 문제에도 적용할 수 있는 거야.
왜 이런 결과가 나오는걸까
여기까지 오니 아예 뿌리가 궁금해지더라고.
아까 표 첫 줄에 한글 제목 영상이 읽다 말고 멈췄다는 게 있었잖아. 그때 화면에 뜬 게 이거야.
UnicodeDecodeError: 'cp949' codec can't decode
무슨 소린지는 몰라도 cp949라는 이름은 눈에 밟히잖아. 그건 또 뭐냐고 물었지.
현대 한글로 쓸 수 있는 글자가 만 천백칠십이 자인데, 예전에 만든 방식에는 그중 이천삼백오십 자만 들어갔다는 거야.
"나머지는 어떡하고?"
"못 쓰는 거지. 그 시절엔 이름에 못 넣는 글자가 있었대."
그걸 마이크로소프트가 윈도우 95를 내면서 빠진 팔천팔백이십이 자를 뒤에 덧대서 메웠고, 그렇게 나온 이름이 cp949라는 거야.
삼십 년 전에 자리가 모자라서 덧댄 자국이 영상 하나 열려다 만난 그 에러에 이름으로 남아 있었던 거야.
그리고 하나가 더 있었어. 지금 쓰는 글자 표에는 완성된 '한'도 들어 있고, ㅎ하고 ㅏ하고 ㄴ을 따로 넣는 자리도 따로 있다는 거지.
"둘이 뭐가 달라?"
"화면엔 똑같이 '한'으로 보여. 저장된 모양만 다르지."
맥에서 만든 파일을 윈도우로 옮기면 이름이 낱자로 풀려 보이는 일이 그래서 생긴대. 우린 아직 안 겪었는데 겪은 사람이 꽤 있다더라고.
같은 글자를 저장하는 방법이 둘이라는 거잖아. 그런데 눈으로는 구분할 방법이 없고.
컴퓨터가 영어권에서 나왔으니 글자 표도 영어부터 담았겠지. 거기까지는 나도 알아.
몰랐던 건 남은 자리에 끼워 넣는다는 게 어느 정도 얘기냐는 거였어.
"알파벳은 대문자 소문자를 다 세도 쉰두 자야. 한글은 만 자가 넘고."
숨이 좀 막히더라. 빈자리 다툼에서 체급이 아예 달랐던 거지.
여기까지 듣고 나니 처음 그 질문이 좀 달라지더라. 둘이 맞느냐 안 맞느냐가 아니라 둘이 쓰는 도구를 봐야 하는 거였어.
대조해보니 층이 갈리더라
여기까지 놓고 보니 뒤죽박죽이던 게 좀 정리가 됐어. 한글을 어디에 쓰느냐에 따라 결과가 갈렸던 거야.
갈라달라고 했더니 이렇게 나왔어.
| 한글을 이렇게 쓰면 | 어떤가 | 왜 |
|---|---|---|
| 읽을 내용으로 쓴다 | 아무 문제 없다 | 읽고 지나가는 자리라 막힐 데가 없다 |
| 이름표로 쓴다 | 막힌다 | 찾아 쓰는 자리라 글자를 대조해야 한다 |
| 찾을 대상으로 쓴다 | 반쪽만 본다 | 도구가 어디까지 훑는지에 답이 달라진다 |
첫 줄이 대화, 프롬프트, 설명, 목록에서 고르는 값이야. 여기는 마음껏 써도 돼.
둘째 줄이 오늘 막힌 그 칸 이름이고, 파일 이름이랑 폴더 이름도 여기 들어가.
셋째 줄이 제일 조용한 자리지.
궁합이 아니라 내력이었어
사실 나는 이걸 자주 까먹어. 녀석도, 녀석이 딛고 일하는 시스템도 전부 영어권에서 만들어졌다는 거.
까먹는 이유는 간단해. 거의 모든 소통에 문제가 없거든. 오늘도 한국어로 묻고 한국어로 받으면서 이 글을 같이 정리했잖아.
생각해보면 참 신기한 일이야. 우리 글자 쓰라고 만든 물건이 아닌데 이만큼 되잖아.
그러다 오늘처럼 한 번씩 막히면 그제야 생각나는 거지. 아 맞다, 이거 원래 영어로 돌아가는 물건이었지.
캐보니 막히는 데는 녀석이 아니라 그 아래였어. 글자를 담는 방식, 이름을 받아주는 규칙, 자료를 훑는 도구. 전부 영어만 있던 시절에 정해진 것들이고, 한글은 나중에 두 번에 나눠서 자리를 얻었고.
잘 되는 것도 가끔 막히는 것도 알고 보니 다 이 내력에서 나온 거였어.
오늘 들은 얘기도 결국 한 줄로 모이더라고. 숫자든 답이든 글자든, 어디서 온 건지를 알아야 제대로 쓸 수 있다는 것.
녀석이 제 숫자에 단서를 달아준 것도, 없다는 답을 그대로 믿으면 안 되는 것도, 에러에 뜬 cp949라는 이름도 다 그 얘기였어.
영어가 기본이라 그런가보다 하고 매번 넘기기만 했는데 오늘은 끝까지 캐봤어. 어렴풋하던 게 풀리니까 속이 다 시원하네.
막히는 거야 앞으로도 있겠지. 궁금한 것도 또 나올 거고. 그럼 그때 또 캐보지 뭐.
P.S. 「눈엔 똑같은데 안에서는 다르다」는 얘기를 도구 쪽에서 다룬 글이 하나 있어. 같은 그림을 뽑는데 붙이는 방식만 바꿨더니 안에서 벌어지는 일이 달랐던 얘기는 사람 눈엔 똑같은데 AI한테는 달랐다에 있어. 위 표에 나온 한글 폴더 얘기도 거기서 한 번 나와.
