글을 쓰다가 제목의 크기와 문단 간격을 고치기 시작하면, 방금 쓰려던 문장을 잊기도 쉽습니다. 화면이 정돈되는 일과 생각이 정돈되는 일은 비슷해 보이지만, 언제나 같은 작업은 아닙니다. 긴 글을 끝까지 고치려면 원고의 내용과 최종 출력의 모양을 잠시 나누어 보는 편이 좋겠습니다. 어떤 도구를 쓰느냐보다, 지금 어느 쪽을 바꾸고 있는지 알 수 있어야 합니다.
2026년 10월 31일 공개된 「Novellas with groff」의 저자는 자신이 소설을 쓰고 조판한 방식을 자세히 설명합니다. groff로 출력 형식을 만들고, 이후 원고를 간단한 Markdown 형태로 다듬었으며, 버전 기록도 남겼다고 합니다. 글을 쓴 기간과 출력 속도는 저자의 환경에 관한 보고입니다. 여기서는 그 수치를 생산성의 약속으로 옮기기보다, 내용과 출력 규칙을 구분하는 작업 방식에 주목하려 합니다.
참고 원문: movq의 관련 원문
같은 문장을 여러 모양으로 확인하기
가령 짧은 기술 안내서를 쓰고 있다고 가정해 보겠습니다. 첫 문단은 문제를 설명하고, 다음 문단은 조작 방법을 알려 주며, 마지막 문단은 실패했을 때 돌아갈 위치를 말합니다. 이 세 문단을 먼저 평범한 텍스트로 적어 둡니다. 처음부터 화면을 가득 채운 완성 문서를 만들 필요는 없습니다. 내용이 바뀔 때마다 따라 바뀌어야 할 요소를 적게 두는 것이 목적입니다.
별도 출력 설정에는 제목의 크기, 본문 폭, 줄 간격과 페이지 여백을 둡니다. 같은 원고를 좁은 화면용과 인쇄용으로 각각 내보내 보면, 문장을 고쳐야 할 문제와 배치만 고치면 될 문제가 나뉩니다. 긴 단어가 잘리는 현상을 해결하려고 설명 자체를 빼 버릴 필요는 없습니다. 반대로 문단이 이해되지 않는 문제를 글꼴 변경으로 덮어 두어서도 곤란합니다.
이 구분은 파일을 꼭 두 개로 나누라는 규칙은 아닙니다. 문서 편집기의 스타일 기능으로도 비슷한 경계를 만들 수 있습니다. 본문을 직접 꾸미기 전에 제목과 문단에 역할을 붙이고, 그 역할에 적용할 모양을 한곳에서 정해 보는 것입니다. 이미 익숙한 도구가 이 일을 잘한다면, 새 도구로 옮기는 비용부터 들일 이유는 없겠습니다.
작은 원고에서 출력 경계를 시험하기
시험 원고에는 보기 좋은 짧은 문장만 넣지 않는 편이 낫습니다. 아주 긴 제목, 괄호가 들어간 문장, 줄이 넘어가는 링크, 강조 표시가 붙은 낱말을 함께 넣어 봅니다. 이 예시들은 실제 원고 전체를 대신하지는 않지만, 평소 문장을 쓸 때 쉽게 만나게 될 경계를 드러냅니다. 인쇄용 문서라면 페이지의 마지막 줄과 다음 페이지의 첫 줄도 함께 봅니다.
문제가 나타나면 원고를 먼저 복제해 놓고 어느 규칙을 바꾸었는지 적습니다. 예를 들어 제목이 두 줄로 넘어갈 때 본문과 겹친다면, 제목 문장을 무조건 짧게 만들기 전에 제목 영역과 다음 문단 사이의 간격을 확인해 볼 수 있습니다. 긴 제목이 애초에 독자에게 도움이 되지 않는다면 그때 내용의 문제로 돌아가면 됩니다. 두 판단을 한 번에 해치우지 않는 것이 좋겠습니다.
검토 결과는 ‘PDF 생성 성공’보다 조금 더 구체적으로 남겨 봅니다. 세 문단이 빠지지 않았는지, 강조한 낱말이 유지되는지, 링크의 표시와 목적지가 맞는지 정도입니다. 파일이 열렸다는 사실은 이 항목들을 대신하지 않습니다. 특히 여러 형식으로 내보낼 때에는 한 형식에서 잘 보인다는 이유로 다른 결과까지 확인했다고 적지 않는 편이 정확합니다.
문장 수정과 모양 수정을 다른 묶음으로 남기기
내용을 바꾸는 날에는 무엇을 말하려는지가 달라졌는지 살핍니다. 출력 설정을 바꾸는 날에는 같은 문장이 어떻게 보이는지가 달라졌는지 봅니다. 이 두 종류의 변경을 기록에서 구분해 두면, 나중에 문제가 생겼을 때 돌아갈 위치를 찾기 수월합니다. 꼭 개발 도구를 쓸 필요는 없습니다. 날짜와 변경 이유를 적은 사본만으로도 출발할 수 있습니다.
가상의 안내서에서 경고 문장을 고치고 여백도 넓혔다고 해 보겠습니다. 두 일을 한 파일에서 한꺼번에 저장하면 어느 변경 때문에 분량이 늘었는지 바로 알기 어렵습니다. 내용이 고쳐진 원고와 같은 내용으로 새로 출력한 결과를 나누어 남기면, 문장의 길이 때문인지 출력 규칙 때문인지 비교할 수 있습니다. 기록의 가치는 파일 수보다 설명 가능한 차이에 있습니다.
다만 이 방식에도 관리할 것이 생깁니다. 원고에 새 표현을 넣었는데 변환 규칙이 그 표현을 지원하지 않으면, 화면에서는 자연스러워도 출력에서 사라질 수 있습니다. 제목, 강조, 표처럼 실제로 쓰는 요소가 늘어날 때 시험 원고도 함께 갱신해야 합니다. 간단한 문법을 고른다는 것은 아무 문법이나 써도 된다는 뜻이 아닙니다.
협업하는 글에서는 다른 사람이 원고를 여는 방법도 중요합니다. 한 사람에게만 익숙한 설정으로 출력이 이루어진다면, 도구를 가볍게 만들고도 전달 과정은 무거워질 수 있습니다. 원고 위치와 내보내는 방법, 마지막으로 확인한 결과를 짧게 남겨 두면 좋겠습니다. 특별한 장치를 늘리기보다 다음 사람이 같은 결과를 얻을 수 있는지가 판단 기준이 됩니다.
끝내는 기준을 작게 정해 두기
출력의 모양을 계속 바꿀 수 있다고 해서 원고가 계속 좋아지는 것은 아닐 것입니다. 오늘은 문장의 뜻을 고치는 날인지, 정해 둔 형식에서 읽히는지를 확인하는 날인지 먼저 정해 보면 어떨까요. 두 작업을 모두 해야 한다면 순서를 정하면 됩니다. 문장이 정해지지 않은 상태에서 모든 출력 형식을 완벽하게 맞추려 하면 작은 수정도 여러 번 되풀이하게 됩니다.
예시의 세 문단이 읽히고, 필요한 표시가 남아 있고, 내보내는 방법을 다시 따라 할 수 있다면 일단 한 단계는 마친 셈입니다. 그 결과를 다음 글에도 적용할지는 별도의 판단으로 남길 수 있습니다. 한 번 만든 출력 규칙을 모든 종류의 문서에 억지로 쓰지 않아도 괜찮습니다. 소설과 설명서가 필요한 모양은 다를 수 있으니까요.
나는 글을 끝낸다는 말을 화면을 더는 손댈 수 없게 만드는 일로 생각하고 싶지는 않습니다. 다음에 다시 열었을 때 문장과 모양 중 무엇을 고치려는지 알 수 있으면 좋겠습니다. 지금 쓰고 있는 글에서도 내용과 출력이 서로를 방해하는 지점이 있다면, 전체 도구를 바꾸기 전에 그 경계 하나부터 나누어 볼 수 있겠습니다.
함께 읽기: AI 버그 수정, 재현 테스트부터 준비해야 하는 이유
공개 원문을 참고하고 AI의 도움으로 구성한 글입니다. 자체 예시는 본문에 구분했으며, 원문의 제품이나 실험을 직접 실행한 후기가 아닙니다.
