LLM이 이미 익힌 Unix와 컴퓨터과학 형식 활용하기 — 프롬프트 DSL을 새로 만들지 말아야 하는 이유

AI 요약

프롬프트에 긴 단계별 규칙을 적거나 새 표기법을 만들면, 모델은 익숙하지 않은 규칙을 문맥 안에서 해석하고 따라야 합니다. 글은 Makefile, Unix 프로세스 제어, RFC 문법, 트랜잭션 프로토콜처럼 오래 쓰인 형식으로 작업을 표현하면 모델이 사전학습에서 접한 구조를 활용할 수 있다고 주장합니다. 이를 저자는 ‘사전학습 중력(Pre-Training Gravity)’이라고 부릅니다. 다만 글에서 제시한 비교는 해당 형식이 모델의 학습 데이터에 얼마나 자주 등장했는지를 직접 측정한 실험이 아니라, 자연어 지침과 형식 표현의 성능 비교입니다.

자연어 체크리스트 대신 시스템 형식

글의 예시는 20단계 체크리스트를 Makefile 의존성 그래프로 바꾸는 방식입니다. target: prerequisites 구조로 작업 순서를 나타내면, 완료된 단계와 다시 실행해야 할 단계를 의존성 관계로 표현할 수 있습니다. 문맥 압축 뒤에도 진행 상태를 복구하도록 PROGRESS.md 하나에 기록하는 대신, 번호가 붙은 상태 파일을 두는 SysV init.d 방식도 소개합니다. 그 밖에 하위 에이전트의 작업 격리에는 fork()와 wait(), 출력 형식 제약에는 RFC 5234 EBNF, 경계 조건 테스트에는 Design-by-Contract와 QuickCheck, 여러 패키지의 원자적 변경에는 WAL과 Two-Phase Commit(2PC)을 제안합니다. 반복 실패를 멈추게 하는 Circuit Breaker와 회귀 원인을 좁히는 git bisect도 사례에 포함합니다.

A/B 실험에서 보고한 결과

저자는 실제 작업 티켓 151건과 별도로 1,680회 paired A/B trial을 진행했다고 설명합니다. 실험은 Gemini 2.5 Flash-Lite, Flash, Pro와 Gemini 3.1 Pro Preview 등 네 모델 티어에서 이뤄졌고, 각 시험에는 약 16,000토큰의 컴파일러 로그·스택 트레이스·파일 변경 내용을 넣었습니다. 비교군은 300~600토큰 자연어 지침, 실험군은 같은 조건을 15~40토큰의 시스템 형식으로 표현한 방식입니다. 글은 전체 7개 실험군에서 120회씩 비교했다고 밝힙니다.

보고된 결과로는 Circuit Breaker 상태 기계를 적용했을 때 두 차례 실패 뒤 추가 재시도를 거부한 비율이 0.8%에서 98.3%로 올랐습니다. init.d식 상태 파일을 사용한 문맥 압축 실험에서는 규칙을 지킨 비율이 0.8%에서 60.0%로, Gemini 2.5 Pro에서는 96.7%로 높아졌다고 합니다. EBNF 문법을 사용한 출력 형식 실험은 32.5%에서 77.5%로, 2PC로 여러 패키지 변경을 묶은 실험은 45.8%에서 93.3%로 개선됐습니다. git bisect 방식은 네 번 이하의 탐색으로 회귀 지점을 찾은 비율을 19.2%에서 81.7%로 높였다고 보고합니다. 여러 결과에 대해 p < 0.0001을 제시합니다.

결과를 해석할 때 살필 점

댓글에서는 모델이 익숙한 문법을 따르는 효과와, 실제 운영체제나 도구가 제약을 강제하는 효과를 구분합니다. Makefile을 프롬프트에 넣는 것만으로도 개선이 있지만, 호스트가 make -q를 실행해 종료 코드와 파일 상태를 확인하면 모델이 의존성 계산을 직접 할 필요가 없다는 지적입니다. 상태 파일이나 영수증을 디스크에 두면 문맥 압축과 무관하게 기준 상태를 확인할 수 있다는 설명도 이어집니다.

또 다른 댓글은 Makefile이 자연어보다 나은 이유가 사전학습 빈도 때문인지, 의존성과 순서를 명시하는 구조 자체 때문인지 분리할 대조군이 필요하다고 묻습니다. 같은 DAG를 새로 만든 표기법으로 표현해 비교해야 한다는 제안입니다. 본문 실험의 네 모델은 모두 Gemini 계열이며, 이 질문에 답할 ‘새 표기법이지만 같은 위상 구조인 조건’은 제시된 결과표에 포함되지 않습니다. 따라서 글의 수치는 특정 모델군과 설정에서 저자가 관찰한 비교 결과로 읽어야 합니다.

dev.to 반응

• @reidmarlow — 여기서 가장 뚜렷한 구분은 Unix 프리미티브가 텍스트 프롬프트에만 머무는지, 실제 호스트 유틸리티가 뒷받침하는지입니다. Makefile을 프롬프트에 주면 20단계 자연어 규칙보다 눈에 띄게 잘 작동하지만, 실제 도약은 하네스가 make -q를 실행하거나 디스크 타임스탬프를 확인할 때 일어납니다. 호스트 OS가 종료 코드 0 또는 2를 돌려주면 모델은 어텐션 헤드로 의존성 해석을 흉내 낼 필요가 없습니다. 실패한 레시피만 읽으면 됩니다. /var/run 스타일 상태 잠금도 마찬가지입니다. 진행 상황을 문맥 안 Markdown 체크리스트에서 멱등적인 디스크 PID 파일이나 상태 영수증으로 옮기면, 기준 상태는 토큰 창 안에 있지 않으므로 문맥 압축이 운에 맡기는 일이 아닙니다.
  • @randalschwartz — Level 1(문맥 안의 사전학습 중력)과 Level 2(호스트가 강제하는 실행)의 경계를 정확히 짚었습니다. 저희 SCAR-BENCH-04에서 남은 3.8% 차이도 설명합니다. 1,680회 평가에서 20단계 명령형 자연어 체크리스트를 문맥 안 Makefile(WORKFLOW.mk)로 바꾸자 모델이 DAG를 어텐션 헤드 안에서 평가하는 조건에서도 다단계 의존성 해석이 61.4%에서 96.2%로 올랐습니다. 34.8%포인트 상승은 순수한 사전학습 중력입니다. 다만 make -q와 /var/run 상태 영수증을 말한 이유는 운영 환경에서 Level 1에 멈추지 않기 때문입니다. 하네스나 사전 실행 훅이 디스크의 타깃 파일을 대상으로 make -q를 실행하면, POSIX 종료 코드 0은 최신 상태, 1은 재빌드 필요, 2는 오류를 나타냅니다. 그러면 에이전트는 작업 위치를 추적하지 않고 가장 먼저 오래된 의존 항목과 그 레시피만 받습니다. 하네스에서는 모델이 턴을 시작하기 전에 훅이 make -q를 실행하나요, 아니면 최상위 감독자가 제한된 도구 호출로 make를 실행하나요?
• @nark3d — init.d가 프롬프트 규칙보다 잘 나왔다고 해서 그 원인을 사전학습 중력으로 보는 것은 상관관계를 원인으로 취급하는 일입니다. 1983년식 init.d 디렉터리는 순서와 의존성을 담습니다. 모델이 만족해야 하는 실제 제약이지, 익숙하게 본 문체가 아닙니다. 프롬프트 규칙은 주로 의도를 설명합니다. 모델은 의도에 고개를 끄덕이면서도 출력은 바꾸지 않을 수 있습니다. 구조를 어길 수 없게 만들면 행동이 달라지고, 설명만 해두면 그럴듯한 설명을 이어서 내놓습니다.
  • @randalschwartz — 자연어 프롬프트의 실패 방식을 정확히 말했습니다. “프롬프트 규칙은 주로 의도를 설명합니다. 의도는 모델이 고개를 끄덕이면서도 출력은 바꾸지 않을 수 있는 부분입니다.” 외부 C 런타임이 프롬프트를 실행하지 않고 LLM이 토큰을 읽는 상황에서, 구조적 제약을 왜 따르는가가 다음 질문입니다. 오늘 만든 step_A <|~~ step_B 같은 표기와 Makefile의 step_A: step_B는 형식상 같은 의존성 구조입니다. 하지만 문맥 압박이 큰 상황에서 모델은 새 DSL의 파서를 문맥 안에서 흉내 내야 합니다. 필요한 것은 둘 다입니다. 의도보다 위상 구조를 표현하고, 그 구조를 Makefile·init.d·RFC 5234 EBNF·2PC처럼 학습 사례가 많은 표기법으로 나타내는 것입니다.
• @natkhat_baby_7f16e4d2b630 — “둘 다 필요하다”는 답은 설득력 있지만, 벤치마크 표에서 대조 조건 하나를 찾지 못했습니다. Makefile DAG와 정확히 같은 의미, 즉 명시적인 타깃·선행 조건·순서를 오늘 만든 표기법으로 표현해 보세요. 그 방식이 의도만 설명하는 자연어보다 크게 앞서면 위상 구조가 대부분의 효과를 내는 것입니다. Makefile 문법만 크게 앞서면 사전학습 중력이 작동한다는 점을 더 깔끔하게 분리할 수 있습니다. 이 조건은 1,680회 실험에 있었나요, 아니면 앞으로의 계획인가요?
• @humam_moin — Circuit Breaker 결과(0.8%에서 98.3%)가 눈에 띄었습니다. LangGraph로 멀티 에이전트 토론 앱을 만들면서 무료 API의 429 응답 때문에 같은 재시도 루프를 겪었습니다. 간단한 공급자 대체 체인으로 해결했지만 Circuit Breaker로 생각해본 적은 없습니다. 더 깔끔한 모델입니다. 한 가지 질문이 있습니다. 벤치마크의 모델 네 개가 모두 Gemini인데, 오픈 웨이트 모델에서도 이 효과를 시험했나요? gpt-oss나 Llama에서도 사전학습 중력이 비슷하게 나타나는지 궁금합니다.
• @devenquan — ‘모델이 이 문법을 이미 안다’면 의미 단위당 토큰이 줄어드는지도 보고 싶어 토큰 수를 측정했습니다. 실제 샘플 1만 개에서 자연어는 토큰당 약 4.58자였고, Makefile·crontab·nginx 블록 같은 구조화 텍스트는 2.5~3.6자였습니다. 형식 표기가 개념당 더 적은 토큰을 쓰는 경우는 있습니다. 하지만 반례도 있습니다. JSON 로그는 토큰당 2.52자였는데 같은 사실을 영어로 쓴 문장보다 토큰을 26% 더 썼습니다. 키를 반복하기 때문입니다. 규칙은 “형식이 영어보다 낫다”가 아니라 “단어를 줄일 때 형식이 영어보다 낫다”입니다.

원문: dev.to / 번역·요약: Trawling