PDF가 우리가 AI와 대화하는 인터페이스가 될 때

모든 일은 흔히 일곱 번째 페이지의 잠깐 멈칫하는 순간에서 시작됩니다. 몇 달 동안 다듬어 온 논문 원고를 통독하며 익숙한 논증의 흐름을 따라 내려가는데, 문득 한 서브타이핑 관계식에서 시선이 멈춥니다. 기호도 전부 눈에 익고 수식도 정갈하게 조판되어 있지만, 두 타입 사이의 관계 방향이 슬그머니 뒤집혀 있습니다. 두 문단쯤 더 내려가 보니 본문의 인라인 기호도 이 뒤집힌 방향을 그대로 따르고 있고, 옆으로 눈길을 돌리니 그림 캡션 하나도 똑같은 표기를 쓰고 있습니다. 문제가 지면 위에서 하나의 선으로 또렷하고 온전하게 이어집니다. 심사위원이 어디에서 의문을 제기할지 단번에 알 수 있고, 이 페이지의 어디부터 손을 봐야 할지도 명확합니다.

하지만 막상 수정을 하려고 손을 뻗는 순간, 눈앞의 그 페이지는 사라지고 맙니다.

렌더링된 PDF 페이지 위에서 떠오른 직관에 응답하기 위해, 기존의 학술 집필 도구들은 언제나 우리에게 PDF 페이지를 떠나 달러 기호와 백슬래시로 가득 찬 .tex 소스 파일 속으로 물러나기를 요구합니다. 수십 년 동안 '지면 위에서 사고하고, 소스 코드 속에서 작업하는' 이 단절은 정교한 조판을 얻기 위해 치러야만 하는 당연한 대가로 여겨져 왔습니다. 오늘날의 AI 에이전트가 다중 파일 프로젝트를 꽤 능숙하게 다룰 수 있게 되었음에도, 주류 LaTeX 도구들의 상호작용 방식은 여전히 소스 코드 편집 중심의 경로 의존성에서 벗어나지 못하고 있습니다. 놀랍게도 이들은 더 똑똑해진 AI 어시스턴트를 코드 창 안에 우겨넣고, 날것의 마크업 언어가 주 작업 공간을 계속 독차지하게 두며, 조판이 끝난 논문 원고는 파이프라인 맨 끝에 매달린 부속 미리보기 창 정도로 취급합니다.

제가 Papilot을 만든 이유는 바로 이러한 단절과 엇갈림을 견디기 어려웠기 때문입니다. 저는 저자가 자신이 읽고 있는 바로 그 페이지 위에서 원고를 어떻게 고칠지 AI와 직접 논의할 수 있기를 바랐습니다. 저자가 이야기를 풀어내고, AI에게 수정 의도를 전달하며, 최종적으로 학술적 표현이 성립하는지 살필 때 마주하는 대상은 언제나 조판된 페이지입니다. 그래서 Papilot은 주 작업 공간을 PDF 원고 자체에 온전히 돌려주고, 인터페이스 안에서 상주형 소스 코드 편집기를 위한 자리를 아예 비워 두지 않았습니다. 물론 디스크 안에서 프로젝트는 여전히 로컬 .tex, .bib 등의 파일로 구성되며 Git으로 관리됩니다. 코드를 직접 확인하거나 손으로 고치고 싶을 때는 언제든 손에 익은 외부 편집기로 열 수 있지만, 인간과 AI의 대화만큼은 이제 동일한 원고 페이지 위로 돌아왔습니다.

소스 코드 중심의 AI 협업이 시대에 뒤처진 이유

화면 분할 인터페이스가 오랫동안 이어져 온 것은 결코 우연이 아닙니다. 그 이면에는 코드를 고치는 곳만이 진짜 작업대라는 관성적인 전제가 깔려 있습니다. Overleaf를 떠올려 보십시오. 화면 왼쪽에는 편집 창이, 오른쪽에는 PDF 뷰어가 자리 잡고 있습니다. 사용자는 코드 편집기와 비주얼 편집기 사이를 오가고, 창 크기를 조절하거나 접고, 재컴파일로 결과를 새로고침하며 소스 코드와 지면 사이를 이리저리 뛰어다닙니다. 일부 패널을 숨기거나 비주얼 모드를 켜더라도 저자가 실제로 손을 대어 수정하는 조작 패널은 최종 완성본의 조판 지면과 분리되어 있으며, 무대의 한가운데는 여전히 소스 코드 편집이 차지하고 있습니다.

이런 분할 화면 구조 안에 아무리 더 강력한 AI 모델을 집어넣는다 한들 저자의 효율은 높아지지 않습니다. 곧 막을 내릴 예정인 OpenAI Prism 프로젝트가 바로 그렇습니다. 편집기에 내장된 어시스턴트가 '유지' 또는 '취소' 옵션이 달린 LaTeX 코드 조각을 생성하고, 인라인 소스 오류를 표시하며, 프로젝트 파일을 수정해 재컴파일을 실행하는 한편 별도의 PDF 미리보기 창으로 결과를 보여줍니다. 하지만 이 일련의 흐름 속에서 대화는 여전히 소스 코드를 중심으로 맴돕니다. 저자가 제기한 문제는 PDF에서 비롯되었는데, AI가 내놓는 수정안은 코드로 먼저 제시됩니다. 그 효과를 판단하려면 컴파일된 원고로 돌아가 수정된 부분에 해당하는 위치를 찾아낸 뒤, 수정 전의 내용과 하나하나 대조해 보아야 합니다.

바로 이렇게 위치를 찾아 오가며 대조하는 과정이 사고의 연속성을 끊어 놓습니다. 다시 일곱 번째 페이지의 방향이 뒤집힌 서브타이핑 관계식으로 돌아가 봅시다. 소스 코드 우선 인터페이스에서 어시스턴트에게 요청을 마치고 나면, 눈앞에 펼쳐지는 것은 붉은색과 초록색이 뒤엉킨 소스 코드 diff입니다. 판단식의 \Gamma, \vdash를 비롯해 추론 규칙을 조판하는 \inferrule, 그리고 프로젝트에서 자체 정의한 서브타이핑 판단 매크로까지 온갖 요소가 변경 내역에 뒤섞여 나타날 수 있습니다. 물론 재컴파일을 하면 수정된 PDF를 볼 수 있겠지만, 새로 생성된 원고가 이전 원고와의 차이점을 직접 짚어 주지는 않습니다. 결국 해당하는 수식을 다시 찾아내어 이전 판본과 곳곳을 대조하며 서브타이핑 관계의 방향이 제대로 고쳐졌는지, 본문과 그림 캡션도 함께 업데이트되었는지 일일이 확인해야 합니다. 소스 코드 diff가 표시해 주는 것은 명령어의 추가와 삭제일 뿐이지만, 저자가 진정으로 검토해야 하는 것은 그러한 추가와 삭제가 원고 위에 남긴 변화입니다.

조판된 페이지가 공동의 맥락이 될 때

조판된 PDF가 더 이상 파이프라인 끝단의 수동적인 미리보기에 머물지 않고 모든 수정의 출발점이자 도착점이 되는 순간, 인간과 AI의 관계도 함께 달라집니다. 우리와 에이전트가 눈에 보이는 동일한 원고 페이지를 마주하게 되면, '뒤적이며 찾기'를 '가리키며 짚기'가 대신하게 됩니다.

Papilot에서의 수정 작업은 마치 두 공동 연구자가 테이블에 마주 앉아 출력된 원고를 두고 논의하는 것처럼 자연스럽습니다. 일곱 번째 페이지의 수식 둘레에 바로 상자를 그리고, 아래쪽 본문에서 잘못된 방향을 그대로 이어받은 문장을 하이라이트한 뒤, 서브타이핑 관계의 방향이 반대로 적혔으니 이를 바로잡고 뒤따르는 유도 과정도 확인해 달라고 짧은 주석을 남기면 됩니다. 해당하는 \begin{mathpar}를 찾으려고 여러 파일을 뒤질 필요도 없고, 조각난 코드 단락을 복사해 채팅 사이드바에 붙여넣을 필요도 없습니다. 지면 자체가 지닌 공간적 위치와 전후 문맥이 곧 우리가 AI에게 건네는 가장 명확한 맥락이 됩니다.

주석을 보내고 나면 연결된 AI 에이전트가 로컬 프로젝트의 .tex 소스 파일에서 작업을 수행합니다. 에이전트가 파일을 찾아 수식과 본문 마크업을 수정하고 나면, 백그라운드에서 컴파일러가 새로운 조판 결과를 만들어 냅니다. 컴파일이 끝난 뒤 눈앞에 놓이는 것은 메마른 코드 패치가 아니라, 원고 페이지 위에 그대로 펼쳐지는 수정 전후의 비교 화면입니다. 실제 글자 크기와 줄 간격, 그리고 도표와의 배치 관계 속에서 신구 판본의 내용을 나란히 살피며 그 자리에서 수락할지, 거절할지, 아니면 추가 질문을 남겨 더 다듬게 할지 결정하면 됩니다.

PDF를 대화 인터페이스로 삼는다는 것은 논문을 출처를 추적할 수 없는 블랙박스로 만드는 일도 아니고, 소스 코드가 없는 임의의 PDF를 역공학하는 일은 더더욱 아닙니다. Papilot은 언제나 실제 로컬 LaTeX 프로젝트 위에서 동작하며, 디스크 위의 일반 플레인 텍스트 파일이 여전히 유일한 진실의 원천(single source of truth)으로 남고, Git 역시 프로젝트가 발전해 온 이력을 그대로 보존합니다. 인터페이스 안에서 수정 사항을 검토하는 일과 버전 이력을 관리하는 일은 명확히 분리되어 있습니다. 페이지 위에서 '수락'을 누르는 것은 당신의 검토 판단을 기록하는 것일 뿐이며, 검토를 통과한 변경 사항을 실제 원고에 반영하고 커밋을 실행하거나 원격 저장소로 푸시하는 과정은 언제나 당신이 주도적으로 통제하는 별도의 단계로 남아 있습니다.

모든 수정에 책임지기

상호작용 인터페이스를 소스 코드에서 다시 원고로 옮겨 오는 일은 한층 더 무거운 주제와도 맞닿아 있습니다. 바로 연구자의 기명 책임입니다. AI가 증명을 매끄럽게 다듬고, 장과 절을 넘나들며 표기를 통일하고, 장황한 단락을 압축하는 데 갈수록 능숙해지면서, 눈치채기 더 어려운 위험 하나도 함께 수면 위로 떠올랐습니다. 바로 '그럴듯하고 매끄러워 보이는 환각과 오류'입니다. 에이전트는 더할 나위 없이 단정하게 조판된 원고 한 페이지를 만들어 내면서도, 문장을 고쳐 쓰는 와중에 정리의 전제 조건을 슬그머니 느슨하게 풀거나 경계 조건을 누락하고, 혹은 특정 실험 곡선이 뒷받침할 수 있는 결론을 과장할 가능성이 얼마든지 있습니다.

만약 저자가 소스 코드 diff를 대조하고, 표 구분자를 맞추며, 화면과 화면 사이를 오가는 데 막대한 에너지를 소모해야 한다면, 정작 학술적 숙고에 쏟아야 할 정신적 여유는 묽어질 수밖에 없습니다. Papilot이 소스 코드 계층의 시각적 소음을 걷어 내고 지면 위에서 수정 전후의 변화를 직접 비교하게 하는 목적은 당신을 대신해 결정을 내리기 위해서가 아니라, 학자의 안목과 검토를 더욱 예리하게 만들기 위해서입니다. 지면 위의 시각적 명쾌함이 과학적 정확함을 뜻하지는 않습니다. 정리가 여전히 성립하는지, 표기에 모호함은 없는지, 모든 주장이 동료 학자들의 질문을 견뎌 낼 수 있는지에 답할 수 있는 사람은 여전히 저자 자신뿐입니다. 번거로운 마크업 언어가 무대 뒤로 물러날 때, 인간 고유의 학술적 판단은 비로소 스포트라이트 한가운데에 서게 됩니다.

로컬 프로젝트를 설정하기 전에 이러한 상호작용 방식을 먼저 경험해 보고 싶다면, 브라우저에서 바로 열 수 있는 대화형 데모를 준비해 두었습니다. 실시간 AI를 연결하거나 로컬 LaTeX 환경을 설치하지 않고도 지면 위에서 주석을 달고 수정 전후 비교를 검토하는 전 과정을 체험해 보실 수 있습니다. 자신의 논문 프로젝트에 평소 쓰던 에이전트를 연결해 본격적으로 집필을 시작할 준비가 되셨다면, Papilot GitHub 저장소를 방문해 MIT 오픈소스 라이선스로 배포되는 데스크톱 클라이언트와 전체 소스 코드를 받아 보시기 바랍니다.

다시 그 원고 페이지로

오랫동안 기계와 협업하여 글을 쓴다는 것은, 인간이 기계의 중간 언어를 배워 그 언어로 자신의 사유를 들여다보아야 함을 뜻했습니다. 우리는 디렉터리 트리와 코드 패치, 그리고 분할된 창들 사이에서 글의 의미를 조각조각 맞추는 데 익숙해졌고, 정작 제대로 조판된 그 한 페이지의 종이는 컴파일이 성공한 뒤에야 비로소 엿볼 수 있는 보상처럼 여겨 왔습니다.

이제 다시 일곱 번째 페이지로 돌아가 봅시다. 방향이 뒤집혔던 그 서브타이핑 관계식은 이미 여백에 동그라미로 표시되었고, 수정된 수식은 제자리에 차분히 내려앉았으며, 아래로 이어지는 연역은 엄밀하고도 명료합니다. 문제를 발견한 순간부터 수정을 마칠 때까지, 당신의 시선은 단 한 번도 자신의 논증에서 떠나지 않았습니다. 갈라져 있던 원고가 마침내 다시 하나로 합쳐졌습니다. 당신은 이곳에서 읽고, 이곳에서 AI와 대화를 나누며, 또한 이곳에서 지면 위의 모든 글자에 책임을 집니다.