가장 아름다운 UI는 가장 좁은 곳에서 나왔다
1980~90년대 Amiga 데모씬 커뮤니티는 오늘날 기준으로 보면 터무니없이 열악한 환경에서 작업했다. 7MHz 이하 CPU, 플로피 디스크 단위의 저장공간, 메모리 보호조차 없던 운영체제. 그런데 Geeknews가 소개한 데모씬 UI 아카이브를 살펴보면 역설적인 장면과 마주하게 된다. 바로 그 제약 속에서 탄생한 도구들—Elite Sinus Producer, ProTracker, X-Copy—이 단순한 기능 구현을 넘어, 저마다 뚜렷한 시각 언어와 독창적인 인터랙션 패턴을 갖추고 있다는 것이다.
사인(sine) 조회 테이블 생성기인 Elite Sinus Producer는 복잡한 수학 연산을 런타임에 처리하는 대신 사전 계산 방식을 택했다. CPU가 감당할 수 없으니, 설계 자체를 바꾼 것이다. ProTracker는 전통적인 악보 표기 대신 격자형 패턴 편집기를 도입했다—샘플 기반 합성과 시퀀싱을 동시에 다루면서도 한 화면 안에 모든 정보를 욱여넣어야 했기 때문이다. 제약이 곧 설계 결정이었다.
'플럭시한' 도구가 남긴 UX 교훈
물론 데모씬 도구 모두가 훌륭한 UX의 표본은 아니었다. ProTracker의 파일 선택기는 스크롤 화살표 사이에 EXIT 버튼을 배치해 오클릭을 유발했고, ANSI 에디터는 하단 툴바에 현재 색상을 표시하면서도 정작 색 변경은 풀다운 메뉴에서만 가능했다. 데모씬 특유의 시각적 과시 욕구—움직이는 래스터 바, 점멸하는 배경, 가독성보다 스타일을 앞세운 글꼴—가 종종 사용성을 희생시켰다.
하지만 여기에도 중요한 통찰이 숨어 있다. 이 도구들은 불특정 다수를 위한 제품이 아니었다. 만드는 사람과 쓰는 사람이 동일한 커뮤니티였고, 오클릭과 혼동을 감수하면서도 기능의 밀도를 택한 것은 의식적인 트레이드오프였다. 사용자의 맥락을 정확히 알 때, 제약은 설계의 방향을 오히려 선명하게 만든다.
AI가 '그럴듯한 거짓말'을 할 때
시간을 현재로 옮겨보자. 덴마크의 개발자 Morten Tandrup이 dev.to에 공개한 와인 추천 엔진 Vinradar 개발기는 전혀 다른 환경—Python, SQLite, 정적 사이트 생성—에서 출발하지만, 결국 같은 교훈에 도달한다. 그는 처음에 LLM으로 데이터를 보강하려 했다. 결과는 단호하게 실패했다.
LLM은 완벽하게 설득력 있는 빈티지 설명을 생성했다. 문제는 그 설명이 실제 평점 데이터와 모순되는 경우가 있었다는 것이다. 더 심각한 건 파싱 버그로 인해 /100 분모가 다음 리뷰어의 점수에 잘못 합산된 상황에서, LLM이 오류를 감지하지 못하고 오히려 그 수치를 그럴듯하게 설명해버렸다는 점이다. 평범한 95점 와인이 100점짜리 걸작으로 둔갑했다. "언어는 아름다웠다. 데이터는 틀렸다." 그는 모든 AI 생성 수치 보강을 프로젝트에서 삭제했다.
제약을 설계 원칙으로 전환하는 법
두 이야기의 교차점이 바로 여기다. 데모씬 개발자들은 하드웨어 제약을 회피하는 대신 그 안에서 설계를 최적화했다. Morten은 데이터 신뢰성이라는 제약을 확인한 뒤 LLM의 역할을 명확히 제한했다. 그가 도달한 원칙들—"모든 수치 값은 검증 가능한 출처에서만", "LLM은 데이터를 설명할 수 있지만 발명하거나 완성할 수 없다", "추측된 정보보다 누락된 정보가 낫다"—은 고통스러운 실패 이후에야 작성됐다고 그는 고백한다.
AI 도구가 넘쳐나는 지금, 우리는 종종 제약을 없애야 할 장애물로 간주한다. 더 강력한 모델로, 더 많은 데이터로, 더 정교한 프롬프트로 제약을 우회하려 한다. 그러나 데모씬과 Vinradar가 보여주는 것은 다르다. 제약을 직면하고, 그것을 설계 원칙으로 전환하는 과정에서 오히려 더 신뢰할 수 있는 결과물이 만들어진다.
빠른 프로토타이핑 이후에 남는 것
프론트엔드 개발자로서 나는 v0.dev나 Cursor로 프로토타입을 10분 안에 만드는 흥분을 잘 안다. 그런데 그 흥분이 가라앉고 나면 반드시 묻게 되는 질문이 있다. "이 출력물을 신뢰할 수 있는가?" Morten이 발견한 것처럼, AI는 오류를 매끄럽게 포장한다. 파싱 버그를 고치지 않고 그럴듯한 문장으로 덮어버린다. 데모씬의 어셈블러들이 충돌 후 메모리에서 코드를 복구하던 것처럼—AI 생성 코드에도 우리만의 '리퍼'가 필요하다. 검증 루프, 출처 추적, 그리고 빈 필드를 두는 용기.
"사용자는 누락된 정보를 용서한다. 틀린 정보는 거의 용서하지 않는다." Morten의 이 한 문장은 UX 원칙이면서 동시에 AI 활용 원칙이기도 하다. 빈 칸을 그럴듯한 추측으로 채우고 싶은 유혹—그것이 30년 전 데모씬 개발자들의 CPU 제약이든, 오늘날 LLM의 환각이든—을 설계의 언어로 번역하는 것이 진짜 실력이다.
결국 AI 시대의 역설은 이렇다. 도구가 강력해질수록, 제약을 스스로 설정하는 능력이 설계 품질을 결정한다. 7MHz CPU가 데모씬의 창의성을 막지 않았던 것처럼, LLM의 한계를 명확히 규정하는 것이 더 나은 프로덕트로 가는 길이다.