AI의 첫 번째 지루한 엔지니어링, TikZ에서 시작되다

새벽 2시, 논문 마감 6시간 전. 당신은 세 번째 그림 — 신경망 아키텍처 다이어그램 — 을 바라보며 \draw의 좌표를 몇 번째인지 모르게 미세 조정하고 있다. (4.5,3.2)를 (4.6,3.1)로 바꾸고, 컴파일하고, PDF를 보고, 아니라고 생각해서 다시 바꾸고, 다시 컴파일한다. 지도교수의 “그림이 예뻐야 리뷰어가 꼼꼼히 읽는다”는 말이 떠오르며, 시계 바늘은 3시를 향한다.

LaTeX 논문을 써본 사람이라면 누구나 겪어본 장면입니다. TikZ는 LaTeX 생태계에서 학술 그래픽을 그리는 사실상의 표준이지만, 이것은 ‘그래픽 도구’가 아니라 ‘그래픽 언어’입니다 — 저자 Till Tantau는 문서에서 일부러 강조하기까지 했습니다: TikZ ist kein Zeichenprogramm(TikZ는 그림 그리는 프로그램이 아니다). 당신은 코드로 그림을 그리고, 좌표를 미세 조정할 때마다 문서 전체를 다시 컴파일해야 합니다. 학계는 수십 년간 이렇게 버텨왔습니다.

2026년 6월, Dominik Peters라는 개발자가 HN에 프로젝트 하나를 올렸습니다: TikZ Editor — WYSIWYG TikZ 그래픽 편집기, Figma처럼 노드를 드래그할 수 있고 소스 코드는 동기화되어 업데이트됩니다. 293포인트, 58개 댓글. 이 프로젝트가 진정으로 논의할 가치가 있는 이유는 어떻게 만들어졌는가에 있습니다.

”인간이라면 절대 하려 하지 않을 일”

Dominik Peters는 Show HN 게시글에서 이 프로젝트의 핵심 논지를 직접 제시하는 문장을 썼습니다:

This approach essentially required reimplementing a large fraction of TikZ, which is the kind of task that no human would ever want to do.

이 문장을 더 직설적으로 번역하면: 드래그 방식의 TikZ 편집기를 만들려면 TikZ의 대부분 저수준 메커니즘 — 파서, 렌더러, 레이아웃 시스템, 색상 처리 — 을 다시 구현해야 한다. 이것은 ROI가 터무니없이 낮은 엔지니어링 작업이다. 정상인은 맡지 않는다.

하지만 Codex가 맡았습니다. 프론트엔드 인터페이스, Tauri 데스크톱 애플리케이션, TikZ 문법 파서, JavaScript 기반 SVG 렌더링 파이프라인, 다양한 포맷 변환기(SVG/PPTX/IPE → TikZ), 그리고 미칠 듯한 ‘사이드 퀘스트’ 몇 개까지, 프로젝트 전체가 거의 전부 Codex에 의해 생성되었습니다. Dominik은 2026년 2월부터 이 프로젝트를 추진해 약 7억 토큰을 소모했고, API 가격으로 환산하면 약 1.5만 달러 — 실제로는 약 500달러의 ChatGPT 구독료만 지불했습니다.

논리 사슬은 명확합니다: 개발 비용이 0에 가까워지면, 원래 ‘할 가치가 없던’ 프로젝트가 갑자기 할 가치가 생긴다. 이 명제 자체는 새롭지 않습니다. 그러나 TikZ Editor는 AI 코딩 도구가 도대체 어떤 종류의 엔지니어링 노동을 인수했는지 — 그리고 도대체 무엇을 인수하지 않았는지 — 를 해부할 수 있을 만큼 정밀한 사례를 제공합니다.

아웃소싱된 두 부류의 엔지니어링 작업

TikZ Editor의 구현에 수반된 작업은 두 부류로 나눌 수 있습니다. 필자는 여기서 구분을 해보겠습니다.

첫 번째 부류: 기계적 포맷 변환. 여기에는 SVG → TikZ, PPTX → TikZ, IPE → TikZ 등의 변환기가 포함됩니다. 이 변환기들의 논리적 복잡도는 낮지 않습니다 — SVG의 패스 커맨드를 TikZ의 \draw 문법으로 매핑하고, PowerPoint의 도형 모델을 TikZ의 노드와 패스로 번역합니다 — 그러나 본질적으로는 매핑 규칙과 경계 조건의 엔지니어링입니다. 규칙은 열거할 수 있고, 경계 조건은 케이스로 커버할 수 있습니다. 경험 있는 엔지니어가 3주 동안 작업해서 끝낼 수 있는 종류의 일이며, 끝내고 나서 어떤 깊은 통찰을 얻었다고 느끼지는 않을 것입니다. 이 부류의 작업은 검증이 이진법적이기 때문에 AI 코딩 도구가 상대적으로 신뢰성 있게 처리합니다: 변환된 TikZ가 컴파일되는가? 렌더링 결과가 원본 포맷과 일치하는가?

두 번째 부류: 낯선 영역에서 고전 알고리즘을 재구현하기. 이것이 더 흥미로운 부류입니다. Dominik은 게시글에서 몇 가지 ‘사이드 퀘스트’를 언급했는데, 그중 두 가지를 전개할 가치가 있습니다:

1. LaTeX의 줄바꿈 알고리즘 (Knuth-Plass) 재구현. 여러 줄 텍스트 노드를 지원하기 위해, TikZ Editor는 브라우저 측(JavaScript 환경)에서 올바른 줄바꿈과 단어 분리를 구현해야 합니다. 이는 Donald Knuth와 Michael Plass가 1981년에 발표한 동적 계획법 기반 줄바꿈 알고리즘 — 전역적으로 단락의 ‘불량도(badness)‘를 최적화하는 알고리즘, 단순한 greedy 줄 채우기가 아님 — 을 재현하는 것을 의미합니다. 브라우저 측의 CSS text-align: justify는 개별 줄의 탐욕적 줄바꿈만 수행하여 결과가 거칠고, TeX의 알고리즘은 전역 최적을 계산하며 단어 간 glue의 신축, 하이픈 페널티, 단락 전체의 미적 평가 함수를 처리해야 합니다.

2. red!20!black 색상 혼합 시스템 구현. LaTeX 논문에서 색상은 종종 {색상1}!{비율}!{색상2} 문법으로 혼합됩니다. 예를 들어 red!20!black은 빨강 20%와 검정 80%를 섞는다는 의미입니다. 브라우저 측에서 이 문법을 지원하는 컬러 피커를 구현하려면 xcolor 패키지에서 정확한 혼합 모델을 리버스 엔지니어링하고, RGB/CMYK 변환, 투명도 계산, 그리고 ! 연산자의 중첩(예: red!20!blue!50!green)을 처리해야 합니다.

필자가 이 두 가지를 같은 부류로 묶는 이유는, 이들이 공통된 특성을 공유하기 때문입니다: 안 하면 기능이 불완전하고, 해도 핵심 역량이 더 명확해지지는 않는다. 이것이 전형적인 ‘지루한 엔지니어링’입니다 — 중요하지 않다는 게 아니라, ROI가 너무 낮다는 것입니다. 인간 엔지니어가 이런 작업을 보면 첫 반응은 “우회할 수 있는 기존 라이브러리 없나?”입니다. 없으면, 그 기능은 WONTFIX로 태그되는 경우가 많습니다.

그런데 AI 코딩 도구는 이런 시나리오에서 꽤 시사적인 성능을 보여줍니다. Dominik은 HN 댓글에서 구체적인 작업 흐름을 공유했습니다: 그는 먼저 LaTeX 엔진(dvisvgm)과 JavaScript 렌더러로 같은 TikZ 그림들을 각각 처리한 다음, 사람이 수동으로 비교하여 차이점을 찾고, 틀린 부분을 Codex에 알려줘서 고치게 했습니다. 그는 멀티모달 모델로 자동 비교를 시도했지만 효과가 좋지 않았다고 합니다 — 모델이 “여전히 약간 눈이 멀어서, 명백히 다른 두 그림도 같다고 판단한다”.

여기 미묘한 디테일이 있습니다: 루프 안에서 인간의 역할은 판단을 내리는 것입니다. 어떤 렌더링 차이가 버그인지, 어떤 것이 폰트 렌더링의 정상적 편차인지, 어떤 것이 허용 가능한지를 판단합니다. 인간은 사라지지 않았습니다. 단지 구현자에서 품질 심판으로 바뀌었을 뿐입니다.

Armin Ronacher의 후반부

TikZ Editor가 발표되기 하루 전, Flask와 Jinja2의 저자 Armin Ronacher는 자신의 블로그 “The Coming Loop”에서 이 사건과 정확한 대화를 이루는 판단을 적었습니다:

I absolutely love loops already that take the boring parts out of my day to experiment and measure and to give me ideas.

그리고 그는 말을 돌립니다:

On the other hand using that same looping methodology to write lasting code does not yet sit well with me.

Ronacher의 핵심 우려는: harness loop가 계속 돌아가고, 매 반복마다 국소적 방어 코드가 추가되며, 사람이 보지 않는 사이에 코드가 자기 성장할 때, 최종 산출물은 자기 자신을 유지보수해야 하는 유기체로 변해버린다는 것입니다. 그는 이것을 “소프트웨어가 결정론적 기계에서 유기체로 바뀌는 것”이라고 부릅니다 — 당신은 그것을 모니터링하고 안정화하지만, 이해하지는 않습니다.

하지만 그의 또 다른 말이 아마도 더 핵심적일 수 있습니다:

Porting code is one of them. There are already impressive examples of large automatic porting efforts, including the reported work around moving parts of Bun from Zig to Rust. I have used it with success myself to port MiniJinja to Go.

Ronacher는 루프가 이미 두 가지 시나리오에서 잘 작동한다고 봅니다: 코드 변환(code transformation — 포팅, 벤치마크, 보안 스캔을 포함)과 오래 살 필요가 없는 코드(proof-of-concept, 실험적 탐색).

여기 흥미로운 대응 관계가 나타납니다. 필자는 이것을 표로 그려보겠습니다:

부류	대표 작업	AI 숙련도	이유
기계적 변환	코드 포팅, 포맷 변환	능숙함	매핑 열거 가능, 검증 이진화
지루한 엔지니어링	Knuth-Plass 재구현, 색상 혼합	능숙함	논리 확정적, 인터페이스 명확, ROI가 인간의 투입 의사를 꺾음
아키텍처 결정	프로젝트 구조, 추상화 계층	불확실	가치관 트레이드오프 수반
디자인 결정	어떤 그림을 그릴지, 어떻게 배치할지	대체 불가	의도와 미적 판단 필요

TikZ Editor는 정확히 앞의 두 행에 걸쳐 있습니다. 포맷 변환은 첫 번째 행, 알고리즘 재구현은 두 번째 행입니다. 그리고 프로젝트의 아키텍처 — Dominik은 “먼저 가장 단순한 파서→SVG 렌더러+기본 드래그로 아키텍처의 실현 가능성을 검증했다”고 말했는데 — 이 결정은 그가 직접 내렸습니다. Codex는 plan mode에서 그에게 선택지 형태로 의견을 물을 뿐이었습니다.

어떤 그림을 그릴지는 사용자의 결정입니다. 편집기가 제공하는 것은 도구이지, 미적 감각이 아닙니다.

« 루프에는 명확함이 필요하다 » — 이 판단을 TikZ Editor에 대입하면 정확히 맞아떨어진다

Ronacher는 글 말미에 필자가 세 번이나 다시 읽게 한 문장을 썼습니다:

Adopting the idea of harness loops means that the harness decides when work is finished.

TikZ Editor 개발에서 ‘언제 고쳐졌다고 볼 수 있는지’는 줄곧 Dominik이 판단했습니다. 그는 두 렌더러의 출력을 나란히 놓고, 차이를 주시하며, Codex에게 어디가 아직 틀렸는지 알려주었습니다. 루프의 종료 조건은 올바른 출력이 어떻게 생겼는지 아는 사람이 정의합니다. 이것이 Ronacher가 말한 “루프의 전제는 명확함이다”입니다 — 당신은 충분히 많은 엉망인 버전을 먼저 겪어야, 무엇이 맞는 것인지 알게 됩니다. 에이전트는 시행착오 과정의 지루한 부분을 단축해줄 수 있지만, ‘맞다’가 무엇인지 당신 대신 정의해주지는 못합니다.

이 논리는 TikZ Editor의 사용자 측에서도 똑같이 적용됩니다. 한 학술 연구자가 편집기를 열어 양자 상태의 Bloch 구 표현을 그리려 하거나, Transformer의 셀프 어텐션 메커니즘 다이어그램을 그리려 합니다 — 이 그림들이 어떻게 생겼는지는 그의 머릿속에 먼저 있는 의도입니다. 에이전트는 이 논문의 핵심 다이어그램이 어떻게 배치되어야 하는지, 어떤 흐름이 강조되어야 하는지, 색상은 초록색으로 할지 회색으로 할지를 대신 결정해주지 못합니다. 에이전트는 당신이 아이디어를 떠올린 후에 \draw[->] (-0.866,-0.5) -- (0.866,0.5) 같은 좌표를 손으로 쓰지 않아도 되게 해줄 뿐입니다.

다시 말해: 지루한 엔지니어링은 기계에 아웃소싱할 수 있지만, 의미 판단은 인간의 손에 남아 있어야 한다. 이것이 TikZ Editor라는 구체적 사례 위에 투영된, 현재 AI 코딩 도구의 능력 경계에 대한 정밀한 투사입니다.

낙관적인 부분, 그리고 불확실한 부분

필자는 이 분석을 싸구려 중용 — “AI에는 좋은 면도 있고 나쁜 면도 있다” — 으로 쓰고 싶지 않습니다. TikZ Editor는 실질적으로 좋은 것입니다. 이것은 학계의 수십 년 묵은 난제를 코드로 메웠고, 메운 방식은 오픈소스(MIT 라이선스), 멀티 플랫폼(Web + Linux/Windows/macOS 데스크톱), 심지어 논문 전체 .tex 파일을 열어 그 안의 TikZ 그래픽을 직접 편집할 수 있기까지 합니다. Hacker News에서 가장 높은 추천을 받은 댓글 중 하나는 독일의 한 대학원생이 쓴 것입니다: “모든 STEM 학생과 연구자가 당신에게 감사합니다.”

불확실한 부분은: 이 패러다임이 얼마나 멀리 갈 수 있는가입니다.

Dominik은 7억 토큰을 소비해 이 프로젝트를 완성했습니다. Ronacher는 모델이 생산하는 코드 품질이 퇴보하고 있다고 우려합니다 — 과도한 방어성, 국소적 추론, 불변량 회피. 그러나 TikZ Editor 사례에서는 GitHub의 한 관찰자가 “코드 구조가 꽤 좋아 보인다”고 평가했습니다. 이 격차는 어디에서 오는 것일까요?

필자의 한 가지 추측은: 작업 경계의 명확성 정도가 산출물 품질을 결정한다. Knuth-Plass 알고리즘의 입력은 텍스트와 줄 너비, 출력은 줄바꿈 위치 — 정확성은 렌더링 결과에서 직관적으로 검증할 수 있습니다. 색상 혼합의 입력은 두 색상과 비율, 출력은 하나의 색상 — 맞고 틀림이 한눈에 보입니다. TikZ 파서의 입력은 텍스트, 출력은 AST — 렌더링이 깨지지 않고 좌표가 맞기만 하면 맞는 것입니다.

검증 기준이 시각화 가능할 때, 루프는 더 신뢰할 수 있다. 검증 기준이 경험적 판단을 필요로 할 때, 루프에는 인간이 필요하다.

이것은 AI를 ‘믿거나 말거나’ 하는 명제가 아닙니다. 이것은 엔지니어링 명제입니다: 어떤 종류의 작업이 자동으로 검증 가능한가? 답이 “자동 검증 가능”이라면 에이전트가 맡기에 적합합니다. 답이 “인간의 판단이 필요”라면 에이전트의 가치는 루프의 각 반복을 가속하는 것이지, 마침표를 찍어주는 것이 아닙니다.

‘지루한 엔지니어링’에서 ‘할 가치가 있는 엔지니어링’으로

Dominik이 했던 말로 돌아가 봅시다 — “이것은 인간이 하려 하지 않을 작업이다.” 이 문장에서 가장 흥미로운 함의는: 못해서가 아니라, 하기 싫어서라는 점입니다.

TeX의 줄바꿈 알고리즘은 1981년부터 있었고, 공개 문헌에 알고리즘 설명은 완전하며, JavaScript 구현도 하나가 아닙니다. red!20!black의 색상 혼합 모델은 xcolor 소스 코드에 명확히 적혀 있습니다. 문제는 “아무도 구현할 수 없다”가 아니라 “아무도 최종 제품의 핵심 가치에 2% 기여하는 이 작업에 4주를 쓰고 싶어하지 않는다”는 것입니다.

AI 코딩 도구가 이 계산을 바꾸고 있습니다. 2%의 한계 가치에 필요한 시간 비용이 4주에서 4시간, 심지어 4분으로 줄어들면, 그것은 ‘할 가치가 없는 것’에서 ‘그냥 겸사겸사 하는 것’으로 바뀝니다. 이것이 인간이 소프트웨어 개발에서 차지하는 역할이 사라진다는 뜻은 아닙니다 — 인간이 무엇을 할지 결정하는 데 더 집중하고, 어떻게 할지의 지루한 부분은 기계에 맡길 수 있다는 뜻입니다.

Ronacher의 마지막 문장은 어떤 의미에서 같은 이야기의 부정적인 면을 말하고 있습니다: ‘무엇을 할지’조차 기계에 넘겨졌을 때, 우리는 시스템을 이해하는 능력을 잃을 수도 있다. 이 두 문장은 함께 놓일 때, 어느 한 문장보다 진실에 더 가깝습니다.

TikZ Editor의 GitHub 페이지는 여전히 업데이트되고 있습니다. Dominik은 다음 단계로 pgfplots 지원을 도입할 수도 있다고 합니다. 필자는 “AI 코딩이 소프트웨어 개발을 재편하고 있다”고 말하지 않겠습니다 — 이 표현은 너무 포괄적입니다. 그러나 말할 수 있는 것은: 인간이 다시 쓰고 싶어 하지 않던 TeX 줄바꿈 알고리즘을, 에이전트가 몇 차례의 대화로 구현해내고 브라우저 측에서 여러 줄 노드를 올바르게 렌더링할 때, 어떤 임계값이 이미 넘어섰다는 것입니다. 앞으로 주목해야 할 것은 더 이상 “AI가 코딩할 수 있는가”가 아니라, “어떤 엔지니어링 결정을 인간이 아웃소싱해서는 안 되고, 어떤 것은 상관없는가”입니다.

이 구분 자체가 아마도 앞으로 몇 년간 소프트웨어 엔지니어링에서 가장 진지하게 고민해야 할 질문일 것입니다.