시킨 대로 적혔는데, 다르게 그려졌습니다

들어가며 — “파일 형식만 바꾸면 되겠네”

어느 교육 과정에서 자료를 인쇄하지 않기로 했습니다. 참가자가 직접 채워 넣는 워크북을 종이 대신 워드 파일로 주기로 한 거죠. 원래 PDF로 뽑던 걸 워드로 바꾸면 되니까, 30분짜리 일이라고 생각했습니다.

AI에게 시켰습니다. “PDF로 만들던 그 표를 워드로 만들어 줘.” 금방 만들어졌고, 열어 봤습니다. 표 안이 이렇게 찍혀 있었습니다.

연령대      대출권수
20 대          9
60 대         10
70 대 이상     3

제가 넣은 값은 20대입니다. 화면에는 20 대가 있었습니다.

띄어쓰기 하나가 뭐 대수냐 싶지만, 데이터 표에서는 이게 그냥 못생긴 게 아닙니다. 값이 잘못 들어간 것처럼 보입니다. 참가자가 “이거 오타 아니에요?”라고 묻는 순간 실습은 거기서 멈춥니다.

그런데 파일 안을 열어 보니, 거기엔 20대라고 붙여서 잘 적혀 있었습니다. AI는 시킨 대로 정확히 썼습니다. 띄운 건 워드였어요.

1. 값은 맞는데, 그 값을 읽는 쪽이 달랐습니다

찾아보니 워드에는 autoSpace라는 옵션이 기본으로 켜져 있습니다. 한글과 숫자가 붙어 있으면 사이를 자동으로 벌립니다. 문서를 만들 때 아무도 안 건드리는 옵션이에요. 왜냐면 보통은 그게 보기 좋으니까요. 본문 문장에서는 확실히 그렇습니다.

표 안에서는 아닙니다. 표 안의 글자는 문장이 아니라 값이거든요.

여기서 이 글의 뼈대가 나옵니다. 저는 지금까지 문서 작업을 이렇게 이해하고 있었습니다 — 내가 값을 정하면, 그 값이 화면에 나온다. 그런데 실제로는 칸이 하나 더 있었습니다.

내가 적은 값 → 그 값을 읽는 규칙 → 화면에 그려진 것

가운데 칸은 제가 만든 게 아닙니다. 프로그램이 이미 갖고 있는 것이고, 파일 어디에도 안 적혀 있습니다. 그런데 최종 결과를 정하는 건 그 칸입니다.

PDF와 워드의 차이도 여기 있었습니다. PDF는 제가 그린 대로 나오고, 워드는 워드가 다시 그립니다. 같은 내용을 옮기는 일이 아니라, 다시 그리는 엔진에 넘기는 일이었어요.

2. 0.36cm가 0.56cm가 된 이유

다음 벽은 숫자였습니다.

스무 줄짜리 표와 규칙을 적는 칸을 한 페이지에 넣어야 했습니다. 스크롤이 생기면 안 되는 활동이었거든요. 표를 보면서 적어야 하는데 화면이 잘리면, 표 보려고 올리고 적으려고 내리기를 20분 내내 반복하게 됩니다. 그러면 활동 자체가 망가집니다.

행 높이를 0.36cm로 지정했습니다. 20행이면 7.2cm. 계산상 넉넉했어요. 뽑아 보니 12cm였습니다.

두 가지가 겹쳐 있었습니다.

첫째, 워드에서 행 높이 지정은 “높이”가 아니라 “최소 높이”입니다. 안에 든 내용이 더 크면 그냥 늘어납니다. 저는 상한을 정했다고 생각했는데, 프로그램은 하한으로 읽고 있었어요.

둘째, 줄 간격을 1.0(배수)으로 준 게 문제였습니다. 배수는 폰트 자체가 가진 줄 높이에 곱해집니다. 맑은 고딕은 그 값이 약 1.5배예요. 그래서 9pt 글자가 “1.0배” 줄 간격으로 0.56cm를 차지하고 있었습니다. 제가 지정한 0.36의 1.5배죠.

여기서 한참을 멍하니 있었습니다. 1.0이라고 적을 때 저는 “그대로”라고 생각했거든요.

“1.0배”는 “그대로”라는 뜻이 아닙니다. 저는 “무엇의” 1.0배인지를 한 번도 안 물어봤습니다.

고친 방법은 단순했습니다. 줄 간격을 배수가 아니라 절대값(Pt) 으로 못 박았습니다. 그러자 워드가 그 값을 “고정”으로 처리했고, 그제서야 지정한 높이가 실제 높이가 됐습니다. 상대값을 절대값으로 바꿔 쥐는 순간, 가운데 칸이 할 일이 없어진 겁니다.

3. 세 줄이 한 줄이 된 건, 워드의 배려였습니다

세 번째가 제일 오래 걸렸습니다.

“고른 모델과 그 이유”를 세 줄로 적게 하고 싶었습니다. 그래서 밑줄 세 개를 그렸어요. 정확히는 빈 문단 세 개에 각각 아래쪽 테두리를 넣었습니다. 파일에는 문단 세 개, 테두리 세 개가 분명히 들어 있었습니다.

화면에는 한 줄만 나왔습니다. 맨 아래 하나.

워드는 테두리가 똑같은 연속 문단을 하나로 합칩니다. 표를 만들 때 셀 경계선이 겹쳐 두 겹으로 보이는 걸 막으려는 배려예요. 대부분의 문서에서는 정확히 옳은 동작입니다. 그 배려가 여기서는 “세 줄짜리 칸”을 “한 줄짜리 칸”으로 만들었습니다.

이게 제일 무서웠던 이유는 따로 있습니다. 파일에는 아무 문제가 없습니다. 문단 셋, 테두리 셋. 값을 아무리 검사해도 안 걸립니다. 뽑아서 눈으로 볼 때까지 아무도 모릅니다.

세 사례 모두 파일에는 시킨 값이 정확히 적혀 있었습니다. 달라진 것은 가운데 칸을 지나면서입니다.

4. 그래서 검사가 못 잡습니다

세 사례를 나란히 놓으면 공통점이 하나 보입니다. 셋 다 파일에는 시킨 값이 정확히 적혀 있었습니다.

그래서 검사가 전부 통과합니다. 검사는 내가 넣은 값을 보거든요. 20대라고 적었나 — 적었습니다. 0.36cm라고 적었나 — 적었습니다. 문단 셋을 만들었나 — 만들었습니다. 전부 통과입니다.

그런데 결과를 정하는 건 그 값이 아니라 그 값을 읽는 규칙이었습니다. 그 규칙은 파일 안에 없고, 프로그램 안에 있습니다. 그러니 파일을 아무리 들여다봐도 안 나옵니다.

여기서 처방이 갈립니다. “더 꼼꼼히 검사하자”는 답이 안 되는 자리예요. 검사를 열 배로 늘려도 검사 대상이 왼쪽 칸에 머무는 한 결과는 똑같습니다. 필요한 건 검사의 양이 아니라 검사할 지점을 오른쪽으로 옮기는 일입니다.

실무에서는 이렇게 정리했습니다.

① 지정한 값이 아니라 나온 결과를 셉니다. 세 줄을 시켰으면 화면에 세 줄인지 셉니다. 20행이 한 페이지에 들어가는지 뽑아서 봅니다. 지정값 확인은 “내가 제대로 시켰나”를 알려주고, 결과 세기는 “그래서 됐나”를 알려줍니다. 다른 질문입니다.

② 상대값을 절대값으로 바꿔 쥡니다. “1.5배”, “자동”, “최소”, “적당히” 같은 말은 전부 가운데 칸에 판단을 넘기는 표현입니다. 18pt, 고정처럼 해석의 여지가 없는 값으로 바꾸면 그 칸이 개입할 자리가 사라집니다.

③ 값을 정하기 전에 그 값의 단위를 물어봅니다. AI에게 시킬 때 이 한 줄을 같이 붙이면 됩니다. “이 프로그램에서 그 값은 무엇을 기준으로 읽히나 — 고정인가 최소인가, 절대값인가 배수인가?” 몰라서 못 물어보는 게 아니라, 물어볼 게 있다는 걸 몰라서 안 물어봅니다.

5. 비슷해 보이지만, 다른 자리입니다

이 블로그에 인접한 글이 몇 개 있어서 선을 그어 두겠습니다. 헷갈리기 쉬운 자리라서요.

더블클릭은 ‘여는’ 게 아니라 ‘해석하는’ 것이라고 쓴 적이 있습니다. 그 글에서 도구는 모르는 것을 추측했습니다. CSV 파일이 자기가 어떤 인코딩인지 안 알려주니까 엑셀이 짐작해서 읽은 거죠. 처방도 그래서 “추측할 자리를 없애라”였습니다. 오늘은 반대입니다. 제가 명시했습니다. 추측할 게 없었어요. 그런데도 어긋났습니다. 값이 아니라 그 값을 읽는 뜻이 서로 달랐기 때문입니다.

AI가 ‘됐다’고 해도 일이 끝난 게 아니라고도 썼습니다. 그 글은 처방이었습니다 — 글자 말고 그림으로, 끝까지 눈으로 보라는. 오늘은 그 처방의 이유 쪽입니다. 왜 하필 눈으로 봐야만 하는가. 어긋남이 값에 안 남고 그림에만 남기 때문입니다.

AI를 켰는데 답은 켜기 전과 똑같았다는 글과도 형태가 닮았습니다. 다만 그 글은 상태의 문제였습니다. 표시등이 “돌고 있나” 대신 “켜져 있나”를 보고 말한 것이죠. 오늘은 단위의 문제입니다. 같은 숫자를 나는 고정으로, 프로그램은 하한으로 읽었습니다. 앞은 무엇을 보고 말하느냐이고, 뒤는 같은 것을 뭐라고 읽느냐입니다.

6. AI로 만들수록 이 칸이 커집니다

여기까지는 워드 이야기처럼 들립니다. 그런데 이 구조는 AI에게 문서를 맡기면서 오히려 커졌습니다.

예전에는 제가 워드를 직접 열어서 만들었습니다. 표를 그리고, 행 높이를 끌어 보고, 화면을 보면서 다시 끌었죠. 느렸지만 그 대신 값을 넣는 순간과 결과를 보는 순간이 붙어 있었습니다. 0.36을 넣었는데 안 줄어들면 바로 알았습니다.

지금은 나뉘어 있습니다. AI는 파일을 만들고, 화면은 다른 프로그램이 그립니다. AI가 내놓은 건 완성된 화면이 아니라 지시서예요. 그 지시서를 받아 읽는 쪽이 나와 같은 뜻으로 읽는지는, 아무도 보장해 주지 않습니다. 그리고 AI는 자기가 만든 결과가 화면에 어떻게 그려지는지 못 봅니다.

이건 문서 작업만의 이야기도 아닙니다. 숫자로 지시하는 자리마다 같은 칸이 있습니다.

엑셀에서 “열 너비 8.43”은 센티미터가 아니라 기본 폰트 기준 문자 수입니다. 폰트를 바꾸면 실제 너비가 달라집니다.
슬라이드에서 “여백 좁게”는 프로그램마다 다른 수치입니다.
AI에게 “10% 줄여 줘”라고 하면 글자 수의 10%인지 문단 수의 10%인지가 안 정해져 있습니다.
“세 문단으로”라고 시켰을 때, 인용문과 목록을 문단으로 셀지도 안 정해져 있습니다.

전부 같은 모양입니다. 내가 준 값은 하나인데, 그 값을 읽는 규칙이 내 쪽과 상대 쪽에 각각 하나씩 있습니다. 둘이 같으면 아무 일도 안 생기고, 다르면 조용히 다른 결과가 나옵니다. 경고는 없습니다. 어느 쪽도 틀린 짓을 하지 않았으니까요.

마무리 — 이 숫자는 무엇의 숫자입니까

그날 막힌 것이 여섯 개였는데, 그중 다섯 개는 뽑아서 눈으로 보기 전까지 아무 경고도 없었습니다. 코드는 전부 정상 종료했고, 파일은 멀쩡히 열렸습니다.

그래서 얻은 습관은 대단한 게 아닙니다. 값을 하나 지정할 때마다 한 번 더 묻습니다.

“이 숫자는 무엇의 숫자입니까 — 고정입니까, 최소입니까? 절대값입니까, 무엇의 배수입니까?”

이 질문 하나로 그날 막힘 세 개 중 두 개가 미리 잡혔을 겁니다. 코드를 몰라도 할 수 있는 질문이고, 알아도 안 물으면 소용없습니다.

저는 도구 사용법을 가르치지 않습니다. 일하는 방식을 바꾸자고 말합니다. AI가 만드는 일을 가져간 자리에서 사람에게 남는 건 더 정확하게 지시하는 능력이 아니라, 내가 준 값이 저쪽에서 어떻게 읽히는지를 한 번 확인하는 습관입니다. 지시는 이미 정확했거든요. 어긋난 건 그다음 칸이었습니다.

본문의 사례는 필자가 진행한 교육 자료 제작 과정에서 나온 것이며, 특정 기업·기관과 무관합니다. 해석과 현장 관점은 박상훈의 견해입니다.