구글 문서에서 작업하던 파일을 워드로 내려받아 열면 처음 몇 초는 멀쩡해 보입니다. 그러다 쪽 수가 하나 늘어 있거나, 마지막 줄이 다음 장으로 넘어가 있거나, 목차 번호가 어긋난 것을 발견합니다.
내려받기는 같은 파일을 다른 이름으로 저장하는 일이 아닙니다. 구글이 자기 문서를 워드가 알아듣는 구조로 다시 쓰는 일이고, 두 프로그램이 같은 이름으로 부르지만 다르게 다루는 요소들이 그 과정에서 조정됩니다.
어디가 어떻게 조정되는지는 정해져 있습니다. 글꼴, 쪽 나누기, 문서 안을 가리키는 링크, 협업 흔적, 그리고 텍스트 위에 얹힌 개체. 이 다섯을 알고 넘기면 받는 쪽에서 고칠 일이 크게 줄어듭니다.
목차
내려받기는 복사가 아니라 번역이다
두 프로그램이 문서를 다르게 담는다
구글 문서는 원래 워드 파일이 아닙니다. 서버 안에 자기 방식으로 담겨 있고, 화면에 보이는 쪽 경계는 브라우저가 그때그때 계산해 그린 것입니다. 워드 파일로 내려받는 순간 그 내용이 docx라는 다른 그릇으로 옮겨집니다.
옮기는 쪽에서 가장 많이 손대는 것은 양쪽에 다 있지만 기준이 다른 요소들입니다. 줄 간격을 어디서부터 재는지, 문단 뒤 여백을 얼마로 잡는지, 글꼴이 없을 때 무엇으로 대신하는지가 프로그램마다 다릅니다.
두 방향이 서로 다른 문제다
워드 파일을 구글 문서로 올릴 때는 구글이 자기 그릇에 맞게 읽어 들입니다. 원본 파일은 그대로 남습니다.
구글 문서를 워드로 내려받을 때는 새 파일이 만들어집니다. 원본은 여전히 구글에 있고, 내려받은 파일을 고쳐도 원본은 그대로입니다. 여기서부터 두 벌이 따로 굴러가기 시작합니다.
그래서 내려받은 파일을 원본과 한 글자씩 대조하는 일은 의미가 없습니다. 대조해야 할 것은 글자가 아니라 구조입니다. 제목이 제목으로 남았는지, 목록이 목록으로 남았는지, 쪽이 의도한 자리에서 넘어가는지 이 셋만 보면 대부분 걸러집니다.
한 번만 넘기고 끝낼 문서라면 신경 쓸 일이 아닌데, 넘긴 뒤에도 양쪽에서 고치게 되면 어느 쪽이 최신인지 사람이 기억해야 합니다. 파일 이름에 날짜를 붙이는 관행이 여기서 나옵니다.
글꼴부터 어긋난다
그 컴퓨터에 없으면 다른 글꼴로 대신 그린다
구글 문서의 글꼴 목록에는 웹에서 바로 끌어다 쓰는 글꼴이 많습니다. 브라우저는 그 글꼴을 그때 받아서 그리지만, 워드는 그 컴퓨터에 설치된 글꼴만 씁니다. 설치돼 있지 않으면 워드가 비슷한 것으로 대신 그립니다.
대신 그려진 글꼴은 글자 폭이 미세하게 다릅니다. 한 줄에 들어가는 글자 수가 달라지고, 그래서 줄이 하나 늘고, 그 줄이 쪽 끝에 걸리면 쪽이 하나 늘어납니다. 쪽 수가 달라지는 사고의 절반은 여기서 시작합니다.
주의 — 글꼴 이름은 그대로 남아 있습니다
워드가 대신 그리는 중에도 리본의 글꼴 칸에는 원래 이름이 표시됩니다. 이름이 맞으니 문제가 없다고 넘어가기 쉬운데, 그 문서를 인쇄하거나 다른 사람에게 다시 넘기면 또 다른 글꼴로 그려집니다.
넘기기 전에 글꼴을 양쪽에 다 있는 것으로 바꿔 두면 이 문제가 통째로 사라집니다. 받는 사람이 무엇을 쓰는지 모를 때는 기본으로 깔려 있는 글꼴 쪽이 안전합니다.
어느 글꼴이 안전한지는 받는 쪽 환경에 달려 있습니다. 윈도우와 맥에서 이름이 같은 글꼴이라도 판이 다를 수 있어, 자간이 미세하게 벌어지는 일까지 막지는 못합니다.
어쩔 수 없이 특정 글꼴을 써야 하는 문서라면 워드에서 글꼴을 파일에 포함해 저장하는 방법이 남아 있습니다. 파일이 커지고 글꼴 자체가 그것을 허용해야 하지만, 모양이 규격인 문서에서는 쓸 만한 카드입니다.
쪽이 한 장 늘어나는 이유
글꼴 말고도 쪽을 미는 것들
글꼴을 맞췄는데도 쪽 수가 다르면 다음 후보는 여백과 줄 간격입니다. 두 프로그램의 기본값이 애초에 다르고, 문단 뒤에 붙는 여백을 어느 쪽이 얼마나 주는지도 다릅니다.
1빈 줄로 만든 쪽 나누기
엔터를 여러 번 쳐서 다음 장으로 밀어 둔 자리입니다. 줄 높이가 조금만 달라져도 그 빈 줄들이 다음 장 맨 위로 넘어가 빈 쪽을 만듭니다.
2표가 쪽 경계에 걸린 자리
표는 행 높이가 조금만 늘어도 통째로 다음 장으로 넘어갑니다. 넘어간 자리에 남은 빈 공간이 그대로 보이면서 문서가 성기게 보입니다.
3머리글과 바닥글의 높이
머리글 영역의 기본 높이가 다르면 본문이 시작되는 자리가 몇 밀리미터 내려갑니다. 한 쪽에서는 티가 안 나다가 열 쪽쯤 가면 한 줄이 밀립니다.
세 가지 모두 원인이 같습니다. 쪽이 어디서 끝나는지를 사람이 정해 두지 않고 프로그램의 계산에 맡겨 둔 자리들입니다. 계산 기준이 바뀌면 그 자리부터 밀립니다. 어느 쪽이 맞고 틀린 문제가 아니라 기준이 둘이라는 문제입니다. 사람이 정해 둔 자리는 어느 쪽에서 열어도 그대로 남습니다.
빈 줄 대신 쪽 나누기를 넣어 두면 첫 번째 원인이 사라집니다. 구글 문서에서 넣은 쪽 나누기는 워드에서도 쪽 나누기로 남기 때문에, 글꼴이 바뀌어도 그 자리는 밀리지 않습니다. 표는 행이 쪽 경계에서 갈라지도록 설정해 두면 빈 공간이 줄어듭니다.
목차와 링크, 각주는 어디까지 따라오나
스타일로 만든 것과 손으로 만든 것
문서 안을 가리키는 것들은 기준이 하나입니다. 프로그램이 알아보는 구조로 만들었으면 따라오고, 보기만 그렇게 만들었으면 글자만 따라옵니다. 목차가 대표적입니다.
| 문서에 든 것 | 워드에서 | 무엇이 가르나 |
|---|---|---|
| 제목 스타일로 만든 목차 | 그대로 온다 | 제목 스타일이 양쪽에서 같은 뜻으로 읽힌다 |
| 손으로 친 목차 | 글자만 온다 | 가리킬 대상이 애초에 없다 |
| 바깥 주소로 가는 링크 | 그대로 온다 | 주소가 값으로 저장돼 있다 |
| 문서 안 특정 자리로 가는 링크 | 대체로 온다 | 구글의 책갈피가 워드 책갈피로 옮겨진다 |
| 각주 | 그대로 온다 | 양쪽 다 각주라는 구조를 갖고 있다 |
| 문서 개요 패널 | 화면 기능이라 안 온다 | 워드에는 탐색 창이라는 자기 것이 있다 |
표 여섯 줄을 가르는 한 문장
가리킬 대상을 프로그램이 알아보는 구조로 만들어 뒀으면 따라오고, 사람 눈에만 그렇게 보이게 만들어 뒀으면 글자만 따라옵니다. 어느 줄이든 이 문장으로 설명됩니다.
개요 패널은 사라지는 게 아니라 옮겨 갈 자리가 없는 쪽입니다. 제목 스타일을 제대로 썼다면 워드의 탐색 창에 같은 목록이 그대로 뜨기 때문에, 실제로 잃는 것은 없습니다.
손으로 친 목차는 원래도 자동으로 갱신되지 않던 것이라, 워드로 넘어와서 나빠진 것이 아닙니다. 다만 쪽 번호가 어긋난 채로 굳어 버리기 때문에 넘기기 전에 제목 스타일로 다시 만드는 편이 낫습니다.
목차가 왔는데 쪽 번호가 안 맞는 경우가 있습니다. 쪽이 밀렸으니 당연한 일이고, 워드에서 목차를 한 번 갱신하면 그 문서의 실제 쪽 번호로 다시 적힙니다. 이 갱신은 목차를 다시 만드는 것이 아니라 번호만 새로 읽어 오는 동작입니다.
댓글과 수정 제안, 기록
협업 흔적은 셋이 서로 다르게 움직인다
여럿이 붙어 있던 문서를 넘길 때 가장 헷갈리는 부분입니다. 댓글과 수정 제안과 버전 기록은 화면에서 비슷하게 보이지만 내려받을 때 각각 다르게 처리됩니다.
1댓글은 메모로 따라온다
워드에도 같은 구조가 있어 옮겨집니다. 다만 누가 썼는지 표시되는 이름은 구글 계정 쪽 이름이라, 사내 규칙상 넘기면 안 되는 이름이 문서에 박혀 나갈 수 있습니다.
2수정 제안은 변경 내용으로 바뀐다
구글의 제안 모드에서 쌓인 수정은 워드의 변경 내용 추적 표시로 옮겨집니다. 아직 반영 안 된 상태로 오기 때문에, 받는 사람이 모두 적용을 누르기 전까지는 본문이 제안 전 모습입니다.
3버전 기록은 남지 않는다
이건 파일 안에 든 것이 아니라 구글 쪽에 쌓인 기록이라 따라올 방법이 없습니다. 되돌릴 일이 생기면 원본 문서로 돌아가야 합니다.
셋의 차이를 한 줄로 가르면, 문서 안에 들어 있던 것은 따라오고 서비스가 들고 있던 것은 안 따라옵니다. 댓글과 제안은 문서에 붙어 있던 것이고 기록은 구글이 따로 들고 있던 것입니다.
넘기기 전에 댓글을 정리하는 쪽이 대체로 낫습니다. 읽는 사람에게 필요 없는 내부 논의가 그대로 따라가는 일이 흔하고, 그 상태로 다시 다른 사람에게 전달되면 원래 의도와 상관없이 퍼집니다. 남겨야 할 댓글이라면 누가 썼는지 이름이 나가도 되는지부터 봅니다.
그림과 표가 든 문서라면
텍스트 위에 얹힌 것들이 제일 많이 움직인다
글자만 있는 문서는 대체로 무난하게 넘어갑니다. 문제는 글자 위에 얹혀 있는 것들입니다. 그림, 도형, 표, 차트가 그렇고, 이들은 문서 안에서의 위치를 정하는 방식이 두 프로그램에서 다릅니다.
줄 안에 끼워 넣은 그림은 글자와 같이 움직이니 안전한 편입니다. 반면 글자 뒤나 앞으로 띄워 놓은 그림은 기준점이 옮겨지면서 몇 밀리미터씩 이동합니다. 표지처럼 도형을 겹쳐 만든 장에서 특히 티가 납니다.
구글 그리기로 만든 도형은 한 덩어리가 된다
여러 도형을 모아 만든 그림은 워드에서 하나의 이미지로 들어옵니다. 모양은 그대로인데 각 도형을 따로 고칠 수는 없습니다.
고칠 일이 남아 있는 그림이라면 원본 구글 문서에서 고친 뒤 다시 내려받는 쪽이 빠릅니다. 워드에서 뜯어 고치려다 시간을 더 씁니다.
주의 — 표지와 마지막 장을 먼저 봅니다
도형을 겹쳐 만든 장은 몇 밀리미터만 어긋나도 눈에 바로 띕니다. 본문 쪽은 한두 줄 밀려도 넘어가지만 표지는 받는 사람이 제일 먼저 보는 화면이라, 넘긴 뒤 확인 순서를 앞뒤부터 잡는 편이 낫습니다.
표는 열 너비가 가장 자주 어긋납니다. 자동 맞춤으로 잡아 둔 표가 워드에서 다시 계산되면서 좁아지거나 넘칩니다. 숫자 열이 줄바꿈 되어 두 줄로 보이면 대개 이 경우입니다.
넘어간 뒤 표를 한 번 훑어 보면 어긋난 열이 바로 보입니다. 머리글 줄만 확인해도 대개 판가름이 납니다. 머리글이 두 줄로 접혔으면 그 아래 데이터 열도 같이 좁아져 있습니다.
열 너비를 고정 값으로 잡아 두면 이 부분은 상당히 안정됩니다. 엑셀 표를 워드에 붙일 때 폭이 넘치는 문제에서 다룬 자동 맞춤과 고정 폭의 차이가 여기서도 그대로 작동합니다.
넘기기 전에 보는 순서
받는 사람이 고칠 일을 줄이는 쪽으로
아래 그림은 내려받기 전에 손봐 둘 만한 세 자리를 한 장에 모은 것입니다. 글꼴 칸, 쪽 나누기가 들어간 자리, 그리고 그림이 얹힌 방식입니다.
넘기기 전에 훑는다
□ 글꼴을 양쪽에 다 있는 것으로 바꿔 뒀나
□ 빈 줄로 밀어 둔 자리를 쪽 나누기로 바꿨나
□ 목차를 제목 스타일로 만들었나
□ 넘기면 안 되는 댓글을 정리했나
□ 수정 제안을 반영할지 남길지 정했나
□ 표의 열 너비를 고정으로 잡았나
□ 내려받은 파일을 워드에서 한 번 열어 쪽 수를 봤나
마지막 줄이 나머지를 다 합친 것만큼 중요합니다. 내려받은 파일을 워드에서 직접 한 번 열어 보면 위의 여섯 가지가 어디서 어긋났는지 몇 초 만에 드러납니다. 브라우저의 미리 보기로는 그 차이가 안 보입니다. 미리 보기는 구글이 그린 화면이라 워드의 계산이 들어가지 않습니다.
목록의 앞 세 줄은 내려받기 전에 구글 쪽에서 할 일이고, 뒤 네 줄은 넘기는 맥락에 따라 달라지는 판단입니다. 앞 세 줄만 습관으로 만들어 두면 사고의 대부분이 없어집니다. 나머지는 문서가 어디로 가는지에 따라 매번 다시 정하게 됩니다.
한쪽으로 자주 넘기는 문서라면 아예 처음부터 워드 형식으로 만들어 구글에 올려 두고 쓰는 방법도 있습니다. 편집 기능 몇 가지를 포기하는 대신 변환 단계가 사라지니, 넘기는 횟수가 잦을수록 손익이 뒤집힙니다.
#구글문서 #워드 #docx #파일변환 #문서작업
