업데이트 (2026년 7월 6일): 여러 최신 LLM들에게 간단한 ASCII 상자를 그려보라고 요청했더니 모두 완벽하게 성공했다. 따라서 아주 기초적인 상자 그리기 문제는 프론티어 모델 수준에서는 거의 해결된 것으로 보인다. 지금 내 생각으로는, 대화가 길어지거나 다단 레이아웃이 들어가거나 모델이 여러 제약 조건을 동시에 저글링해야 하는 복잡한 컨텍스트가 주어질 때 정렬 문제가 다시 고개를 든다. 단순한 상자는 쉽지만, 복잡하고 지저분한 컨텍스트 윈도우 안에서의 정교한 ASCII 아트는 여전히 무너지기 십상이다.
아무 LLM에게나 간단한 ASCII 상자를 그려달라고 해보자. 대략 이런 형태다.
+----------+
| |
| |
+----------+너무 쉬워 보이는가? 하지만 대부분의 모델들은 이를 엉망으로 망쳐놓곤 한다. 세로선 줄이 맞지 않고, 모서리는 글자 하나씩 어긋난다. 점심때 맥주 두 잔을 걸친 사람이 그린 상자처럼 삐뚤빼뚤하다.
왜 이런 일이 일어나는지 궁금해져서 제미나이(Gemini)와 함께 깊이 파보았다. 알게 된 사실들을 정리해 본다.
핵심 문제: LLM은 개별 문자를 보지 못한다
LLM은 한 글자 한 글자씩 글을 읽거나 쓰지 않는다. ’토큰(token)’이라는 덩어리 단위로 텍스트를 처리한다. 공백(스페이스) 6개짜리 연속된 문자열도 단 하나의 토큰으로 묶일 수 있다. 모델은 [ ][ ][ ][ ][ ][ ]를 각각의 칸으로 보는 것이 아니라, ’어느 정도의 공백’을 나타내는 하나의 추상적인 덩어리로 인식한다.
따라서 윗줄의 세로선에 맞추기 위해 파이프(|) 기호 사이에 공백을 몇 개나 넣어야 할지 결정할 때, 모델은 사실상 ’추측’을 하고 있는 셈이다. 실제 공간 감각이 전혀 없는 상태에서 공간 배치를 시도하기 때문에 짐작은 번번이 빗나간다.
이것이 바로 토큰화의 사각지대다. 모델은 투박하고 모호한 단위들을 쥐고서 정밀한 격자 기반의 수학 연산을 해내려 애쓰고 있는 것이다.
엎친 데 덮친 격: 비례 폰트 편향
ASCII 아트는 모든 문자의 너비가 동일한 고정폭(monospace) 폰트 환경에서만 제대로 작동한다. 하지만 LLM이 사전 학습한 수십억 페이지 분량의 텍스트는 대부분 가변폭(proportional) 폰트로 작성되어 있다. 가변폭에서는 i가 m보다 훨씬 좁다. 모델이 지닌 텍스트 간격에 대한 통계적 이해 전체가 이 가변폭을 기본 가정으로 깔고 형성되어 있다. 이런 모델에게 고정폭 격자 안에서 생각하라고 요구하는 것은, 필기체만 읽어본 사람에게 완벽한 고딕체 인쇄용 글자 격자를 쓰라고 시키는 것과 같다.
게다가 되돌아가서 고칠 수도 없다
LLM은 왼쪽에서 오른쪽으로, 위에서 아래로 글을 생성한다. 한 번에 토큰 하나씩이다. 캔버스도 없고, ’실행 취소(Ctrl+Z)’도 없다. 완성된 출력을 바라보며 “3번째 줄이 삐뚤어졌네, 다시 고쳐야지” 하고 수정할 능력이 없다.
완벽한 상자를 그리려면, 모델은 아직 2번째 줄을 생성하고 있는 와중에 시각적 피드백 없이 4번째 줄의 공간 배치까지 미리 계산해 두어야 한다. 초반에 계산이 조금이라도 어긋나면 그 오류는 아래로 갈수록 눈덩이처럼 불어난다.
틀린 상자를 고쳐달라고 하면 어떻게 될까?
여기가 가장 흥미로운 지점이다. 줄이 맞지 않는 부분을 지적하고 고쳐달라고 요청하면 대개 두 가지 반응이 돌아온다.
- 아주 자신만만하게 사과한 뒤, 똑같이 망가진 상자를 그대로 출력한다.
- 과하게 교정하려다 더 엉망으로 망쳐놓는다.
왜 그럴까? 근본적인 조건이 바뀌지 않았기 때문이다. 여전히 투박한 토큰 단위로 작업하고, 비례 폰트 편향을 안고 있으며, 좌에서 우로 생성할 뿐이다. 게다가 방금 망가진 상자가 컨텍스트 윈도우 안에 그대로 남아 있어, 깨끗한 백지 상태에서 시작하는 대신 망가진 패턴 쪽으로 어텐션(attention) 가중치가 끌려가게 된다.
삐뚤어진 그림을 눈앞에 들이밀면서 “이 그림 보면서 다시 똑바로 그려봐”라고 하는 꼴이다. 잘못된 참조가 수정을 오염시킨다.
실제로 제대로 그리게 만드는 요령
실제로 통하는 몇 가지 방법이 있다.
문자 단위 로직을 강제한다. 상자를 직접 그리지 말고, 정확한 문자열 길이를 이용해 상자를 출력하는 파이썬 코드를 작성해 달라고 요청한다. print("+" + "-" * 10 + "+") 같은 코드는 수학적으로 오류가 생길 수 없다. 모델은 공간을 추론할 필요 없이 그저 숫자를 세기만 하면 된다.
구체적인 수치를 제시한다. 단순히 “상자를 그려줘”라고 하지 말고, “맨 윗줄은 대시(-) 20개, 중간 줄들은 파이프 기호 사이에 공백 정확히 18개”처럼 지시한다. 시각적 레이아웃 문제를 LLM이 잘 처리하는 단순 산수 문제로 바꿔주는 것이다.
공백 대신 눈에 보이는 문자를 쓰게 한다. 빈 공간에 스페이스 대신 마침표(.)를 채워 상자를 그리게 한 뒤 나중에 직접 공백으로 치환한다. 공백 문자는 예측하기 힘든 덩어리로 토큰화되지만, 마침표는 비교적 균일하게 처리된다.
어떤 모델은 완벽히 그리고, 어떤 모델은 실패하는 이유
이 과제에서 모델 간의 성능 차이는 극명하다. 성공하는 모델들은 대체로 다음과 같은 특징을 지닌다.
정교한 토크나이저. 최신 모델들(특히 Qwen-Coder 같은 코드 특화 모델이나 최근의 Claude/GPT 계열)은 훨씬 잘게 쪼개진 세분화된 토크나이저를 사용한다. 이들은 공백 16개를 모호한 하나의 덩어리가 아니라 정확히 16개의 독립된 단위로 인식할 수 있다.
방대한 코드 사전 학습. 코드는 주석, 마크다운 표, 터미널 출력, 아키텍처 다이어그램 등 구조화된 ASCII로 가득 차 있다. 코드를 깊게 학습한 모델은 구조화된 블록에서 | 기호 다음에 무엇이 와야 하는지에 대한 내부적인 ’통계적 지도’를 갖고 있다. 고정폭 텍스트에 대한 공간적 직관이 훨씬 뛰어난 것이다.
추론(Reasoning) 능력. 사고 과정(Chain-of-thought)을 거치는 모델(o-시리즈나 DeepSeek-R1 등)은 글자를 출력하기 전에 시각적 문제를 명시적인 수학 계산으로 먼저 변환한다. 파이프가 어디에 들어갈지 ’어림짐작’하는 대신 실제로 센다: “1번 라인은 20자 너비였으니, 이번 줄은 파이프 하나, 공백 18개, 파이프 하나가 필요하다.”
이것이 전반적인 모델 성능의 척도가 될 수 있을까?
대체로 그렇다. 어떤 모델이 ASCII 상자를 오차 없이 깔끔하게 그려낸다면, 이는 다음과 같은 기본기를 갖추고 있다는 강력한 신호다.
- 정밀한 토큰 제어 능력 (코드 작성, 문자열 조작, 인덴트 관리에 필수적)
- 공간적 추론 능력 (표 파싱, 레이아웃 분석, 와이어프레임 이해에 필수적)
- 철저한 지시사항 이행 및 제약 조건 추적 능력
운동선수의 민첩성 훈련(agility drill)을 떠올리면 된다. 훈련을 잘 통과했다고 해서 모든 종목을 다 잘한다는 뜻은 아니지만, 순발력, 균형감, 공간 지각력 같은 기초 신체 능력이 탄탄하다는 증거는 된다.
물론 예외는 있다. 코드에만 극단적으로 최적화되어 ASCII 상자는 기가 막히게 그리면서도 감성적인 작문이나 미묘한 뉘앙스 분석은 형편없는 모델도 있을 수 있다. 특화의 영역은 존재한다.
하지만 단순한 네모 상자 모서리조차 맞추지 못하는 모델이라면, 그 또한 분명한 신호다. 토크나이저가 너무 뭉툭하거나, 공간 추론이 부실하거나, 제약 조건을 지키는 끈기가 부족하다는 뜻이다. 그리고 이러한 약점들은 다른 작업에서도 반드시 드러나기 마련이다.
요약하자면
ASCII 상자 문제는 LLM을 테스트하기에 훌륭하고 직관적인 진단 도구다. LLM이 텍스트를 처리하는 방식(토큰 덩어리, 좌에서 우로, 시각 피드백 없음)과 인간이 처리하는 방식(한 자 한 자, 공간적, 반복 수정) 사이의 간극을 적나라하게 드러내기 때문이다. 이 간극을 뛰어넘는 모델이 진짜 뛰어난 모델이다. 단순히 네모 상자를 잘 그리는 게 중요해서가 아니라, 그것을 가능하게 만드는 기반 역량이 다른 모든 지능적인 작업의 성패를 가르기 때문이다.