리눅스 터미널에서 man 명령으로 매뉴얼 페이지를 읽어본 사람이라면 그 문서를 렌더링하는 엔진이 groff라는 사실을 알고 있을 것이다. 그런데 groff/troff는 매뉴얼 페이지 전용 도구가 아니라 완결된 조판 시스템이고, 실제 책도 만들어낼 수 있다. 한 블로거는 이 도구를 써서 자신이 쓴 두 편의 '노벨라(중편소설)'를 직접 조판한 경험을 기술적으로 정리해 공개했다. 첫 작품은 A5 기준 약 50쪽(1만 5천 단어), 두 번째는 약 120쪽(4만 단어) 분량이다. 흥미로운 지점은 집필 속도인데, 첫 작품은 일곱 달 넘게 걸린 반면 더 긴 두 번째 작품은 열흘 만에 끝냈다고 한다. 글쓴이 본인은 학창 시절 수학·물리 같은 기술적 주제가 아닌 '글쓰기'는 질색했다고 밝히면서도, 2025년 7월 이후 30권가량의 소설을 읽으며 흥미가 붙어 직접 써보게 됐다고 설명한다.
왜 워드프로세서가 아니라 groff인가
실무자의 관점에서 눈여겨볼 대목은 성능이다. 13년 반 된 PC에서 50쪽 문서를 PDF로 만드는 데 약 700밀리초, 120쪽 문서는 전처리를 포함해 1.6초가 걸린다. 요즘 소프트웨어 상당수가 '진흙 속을 걷는 느낌'이라는 글쓴이의 표현과 대비되는 속도다. groff의 매력은 비교적 작고 빠르면서도 고품질 출력이 가능하다는 데 있다. 소설이나 노벨라처럼 목차·상호참조·도표·코드 블록·목록이 필요 없고 흐르는 본문과 가끔의 강조만 있으면 되는 문서에는 거창한 기능이 오히려 군더더기다. 그래서 그는 아주 작은 자체 매크로 패키지를 직접 만들었다. .de로 매크로 정의를 시작해 ..까지가 한 매크로가 되는 식이며, 개별 명령은 man 7 groff에서 찾아볼 수 있다. 매뉴얼 페이지를 많이 써온 습관 탓에 장 제목 매크로 이름을 (챕터라는 뜻의 CH나 CT가 더 나았을) SH로 붙여버린 것도 솔직하게 적어두었다.
페이지 조판의 핵심, '트랩'
기술적으로 가장 많은 분량을 할애한 부분은 쪽번호와 여백 처리다. groff에서는 페이지의 특정 세로 위치에 '트랩(trap)'을 심어두고, 출력이 그 지점에 도달하면 지정한 매크로가 실행된다. 글쓴이는 바닥 여백 크기를 레지스터에 담아두고 페이지 하단에서 일정 거리 떨어진 곳에 트랩을 설치해 바닥글을 그리는 방식을 쓴다. 트랩이 걸리는 원리를 설명하면서, 어떤 단어가 트랩 위치에 닿으면 그 뒤에 삽입할 텍스트가 이어진다는 점, 그리고 이미 수집된 줄을 깨지 않고 다음 줄로 넘기려면 .ev로 환경(environment)을 전환해 빈 버퍼를 새로 얻어야 한다는 점을 예시로 풀어낸다. 또 하나 실무적으로 중요한 세부는 .으로 시작하는 요청 대신 '(작은따옴표)를 쓰면 이미 모아둔 줄을 강제로 끊지 않고 공백만 넣을 수 있다는 차이다.
다만 저자 스스로 '내가 이해한 최선'이라는 단서를 반복해서 단다. A5 페이지 크기 설정 때문에 마지막 줄의 베이스라인이 페이지 밖으로 밀려나는 현상, 머리글과 바닥글 길이가 완벽히 대칭이 아닌 문제, 특정 상대 좌표를 쓰면 무한 루프에 빠지는 이유 등을 아직 모른다고 TODO로 남겨두었다. groff는 '본격 조판 시스템'이라 이런 부분이 복잡하고, 자신은 아직 모든 측면을 마스터하지 못했다는 고백이다. 이는 groff로 책을 만들려는 사람에게 현실적인 기대치를 보여준다. 결과물의 품질은 높지만, 세밀한 레이아웃 제어에는 문서를 파고드는 시간과 시행착오가 든다.
독일어 조판과 쓰기 환경
언어별 조판 관습도 다룬다. 영어권에서는 문장 끝 뒤에 공백을 두 칸 넣어 troff가 문장 경계를 인식하고 문장 간 추가 공백을 넣도록 하지만, 독일어 책에서는 이런 추가 간격이 관례가 아니라서 저자는 보충 문장 간 간격을 0으로 끄고 최소 단어 간격은 기본값 12로 유지했다. 또 독일어 하이픈 규칙은 2006년 신규칙(den, 'de new')을 사용한다. 독일어 책에서 선호되는 기요메(« ») 따옴표로의 변환이나 문자 치환 같은 전처리는 파일 전체를 읽어 여러 줄에 걸친 정규식 처리를 하기 쉽다는 이유로 파이썬 대신 간단한 Perl 스니펫으로 처리했다.
두 작품 모두 처음에는 순수 groff로 썼지만, 두 번째 작품은 사람이 읽기에 더 편하고 창작에 집중하기 좋다는 이유로 극소수 요소만 쓰는 '마크다운'에 가까운 형식으로 바꿔 작성한 뒤 매크로용 groff로 변환했다. 다만 HTML로 바로 만들지 않은 이유는 분명하다. 브라우저의 양쪽 정렬은 눈에 거슬릴 정도로 엉망인 반면 groff나 TeX이 만들어내는 양쪽 정렬 결과는 훨씬 낫기 때문이다. 집필 환경은 단출하다. Vim을 전체화면으로 띄워 바탕화면을 가리고, UW ttyp0 글꼴의 11x22 변형을 쓰며, 브라우저도 시계도 없는 '방해 없는 글쓰기' 상태를 만든다. 텍스트는 문단마다 한 줄로 두는 방식 대신 직접 줄바꿈하는 하드랩 방식을 택했는데, 읽고 탐색하기 쉽고 과거 DOS 시절 T 에디터의 감각을 떠올리게 하기 때문이다. 협업에는 불리하지만 혼자 쓰는 글이라 문제가 되지 않는다는 판단이다.
이 사례가 한국 실무자에게 주는 시사점은 '올바른 도구'의 기준이 꼭 기능의 많고 적음이 아니라는 점이다. 목차도 다이어그램도 필요 없는 단순한 책 한 권에는 거대한 조판 프로그램보다 수백 밀리초 만에 PDF를 뽑아내는 작은 매크로 집합이 더 생산적일 수 있다. 동시에 groff의 트랩·환경·레지스터 개념은 매뉴얼을 깊이 읽어야 비로소 손에 익는 종류의 것이어서, 진입 장벽과 미해결 과제가 공존한다는 현실도 함께 보여준다. 결국 이 글은 특정 도구의 우월함을 주장하기보다, 익숙한 터미널 도구 하나가 생각보다 멀리까지 데려다줄 수 있다는 가능성의 기록에 가깝다.