데모신 툴 UI 구경기: 예쁘고 불편하고 이상하게 실용적인 화면들

• 데모신은 “코드로 예술한다”는 말이 꽤 문자 그대로였던 문화임.

  • 그래픽, 음악, 효과를 실시간으로 만들고, 그걸 제한된 하드웨어에서 최대한 멋있게 보여주는 쪽에 집착했음.
  • 그래서 툴도 상용 소프트웨어만 쓰는 게 아니라 직접 만들거나, 기존 아이디어를 베끼거나, 심지어 코드를 뜯어와서 자기들 식으로 바꾸는 경우가 많았음.

• 이 글의 핵심은 데모신 툴들의 UI가 이상해 보이지만, 그 이상함이 그냥 장난은 아니라는 점임.

  • 10대 개발자의 실험 정신, 오래된 습관, “일단 멋있어야 함”이라는 욕망, 하드웨어 제약이 한 화면에 섞여 있음.
  • 결과물은 가독성보다 개성, 표준 위젯보다 자체 화면, 친절한 안내보다 단축키와 암묵지가 앞서는 UI가 됐음.

계산을 피하기 위한 UI

• Elite Sinus Producer는 Amiga용 사인 곡선 생성 도구인데, 데모신의 “꼼수 미학”을 잘 보여줌.

  • 데모는 보통 실시간이라고 말하지만, 실제로는 느린 CPU에서 못 버티는 계산을 미리 해두는 경우가 많았음.
  • 이걸 precalc라고 부르고, 복잡한 수학 계산 대신 조회 테이블을 만들어 쓰는 방식임.
  • 7MHz급 CPU에서 매 프레임 비싼 계산을 돌리는 대신, 미리 만든 값으로 스프라이트 움직임이나 효과를 구성하는 식임.

• 이 툴의 UI는 실용성과 괴상함이 같이 있음.

  • 메뉴에서 기능을 고르면 해당 옵션이 강조되고, 뜬금없이 뻐꾸기 시계 샘플이 크게 재생됨.
  • “Flower” 옵션을 고르면 꽃 모양 경로가 나오고, 이걸 디스크에 어셈블리 소스 형태로 저장할 수 있었던 것으로 보임.
  • 도움말 화면은 파란 래스터 바가 움직이고, 배경이 빨강과 청록으로 번쩍이는 식이라 읽으라고 만든 건지 테스트하려고 만든 건지 헷갈리는 수준임.

텍스트 기반 툴의 세계

• Amiga 데모 코딩에서는 Seka, Asm-One 같은 어셈블러 계열이 자주 쓰였음.

  • Seka 2.0은 상용 어셈블러 기반이었고, 시작할 때 작업 메모리 크기를 직접 물어보는 식이었음.
  • 이후 명령줄 모드에서 RAM과 CPU 레지스터를 들여다보고, 소스 파일을 에디터로 불러오는 흐름을 가짐.
  • Asm-One은 Seka 계열의 개선판에 가까웠고, 기본 Workbench 창이 아니라 자체 화면을 띄우는 식으로 동작했음.

• ripper류 도구는 게임이나 프로그램이 종료된 뒤 메모리에 남은 음악, 그래픽, 샘플을 찾아내는 데 쓰였음.

  • Multi-Ripper 같은 툴은 메모리를 뒤져서 원하는 데이터를 건져내는 기능을 제공했음.
  • 심지어 컴퓨터가 크래시된 뒤 메모리에 남은 Seka 어셈블리 소스를 복구하려는 전용 ripper도 있었음.
  • Amiga에는 메모리 보호가 없었고, 데모 코딩은 크래시가 흔했기 때문에 저장을 깜빡한 코드를 운 좋게 되살리는 용도였음.

• The Sinus Creator 같은 또 다른 사인값 생성기도 등장함.

  • 두 개의 텍스트 창으로 구성된 UI를 쓰고, 결과를 Seka 소스 파일로 저장할 수 있었음.
  • 지금 보면 작고 투박하지만, 실제 작업 흐름은 “계산값 만들기 → 어셈블리 소스로 가져가기”로 꽤 명확함.

음악 트래커는 작곡 툴이자 개발 툴이었다

• 데모 음악은 역사적으로 tracker에서 많이 만들어졌음.

  • tracker는 전통 악보보다 프로그래밍 에디터에 가까움.
  • 음, 샘플, 효과 명령을 채널과 패턴 단위로 입력하고, 시간축을 따라 재생하는 구조임.
  • 악기 관리도 샘플 기반이거나 합성 기반으로 같이 다룸.

• Amiga 샘플 기반 tracker의 조상은 1987년 Karsten Obarski의 Ultimate Soundtracker였음.

  • 상용 소프트웨어였지만 곧 데모신 쪽에서 뜯기고 변형되며 NoiseTracker가 나왔음.
  • 이후 ProTracker로 이어졌고, 다시 수많은 버전과 해킹판으로 갈라졌음.
  • 글쓴이는 이 계보가 Amiga 어셈블러 계보보다 더 복잡하다고 볼 정도로 퍼졌다고 설명함.

• NoiseTracker와 ProTracker의 UI는 이후 트래커 경험을 사실상 정의했음.

  • ProTracker의 파일 선택기는 “Disk Op.” 버튼을 눌러 들어가는 구조임.
  • 보라색 파일 목록 옆에 위아래 스크롤 버튼이 있고, 그 사이에 세로로 된 EXIT 버튼이 끼어 있음.
  • 익숙해지면 쓸 수 있지만, 보통의 Amiga 프로그램에 익숙한 사람에게는 묘하게 직관적이지 않은 UI였다는 평임.

• PC 쪽에서는 Fasttracker II가 자기만의 아이콘이 됐음.

  • Gravis UltraSound 같은 당시 고급 사운드 하드웨어를 지원했음.
  • 16비트 샘플, 말도 안 되게 많은 사운드 채널, 심지어 간단한 Snake 게임까지 들어 있었음.
  • 작업 도구인데 덤 기능까지 들어가는 이 느낌이 당시 씬 툴의 분위기를 잘 보여줌.

플로피, 복사, 압축, 배포

• 데모와 해적판 소프트웨어를 퍼뜨리려면 디스크 복사가 중요했음.

  • AmigaOS에도 디스크 복사기가 있었지만, 파일 시스템을 우회해 플로피 트랙에 직접 데이터를 쓰는 게임이나 데모를 복사하기엔 부족했음.
  • 그래서 X-Copy, D-Copy 같은 전용 복사 도구가 필요했음.

• X-Copy는 각 플로피 트랙을 격자로 보여주는 UI로 유명했음.

  • 복사 상태를 트랙별 사각형으로 표시해서, 사용자가 진행 상황을 바로 볼 수 있었음.
  • 복사가 끝나면 작은 “boing” 소리를 재생했다고 함.
  • 상용 출시됐지만 데모신에서 많이 불법 복제되었고, 여러 버전이 돌아다녔음.

• cruncher는 실행 파일을 압축해 디스크 공간을 아끼는 도구였음.

  • Titanics Cruncher 같은 도구가 예로 나오는데, 비대칭 압축을 써서 실행 파일 크기를 줄였음.
  • 대신 실행할 때 decrunching, 즉 압축 해제 시간이 더 걸림.
  • 플로피 용량이 빡빡한 환경에서는 로딩 시간을 조금 희생하고 배포 크기를 줄이는 선택이 꽤 합리적이었음.

통신과 그래픽 편집 도구들

• 인터넷이 대중화되기 전에는 BBS가 데모신의 중요한 유통 채널이었음.

  • 특히 “엘리트 BBS”는 해적판 소프트웨어를 내려받을 수 있는 곳을 의미하는 경우가 많았음.
  • 이런 BBS에는 ANSI나 C64의 PETSCII 그래픽으로 꾸민 메뉴 화면이 빠질 수 없었음.
  • 그래서 ANSI 편집기 같은 툴도 자연스럽게 많이 나왔음.

• Digital Intelligence의 Ansi-Editor v2.4는 UI가 꽤 특이했음.

  • 하단 툴바에 현재 활성 색상이 보이지만, 거기서는 색을 선택할 수 없음.
  • 색을 바꾸려면 실제로는 풀다운 메뉴를 써야 했음.
  • 보이는 것과 조작 가능한 것이 어긋나는, 요즘 UX 리뷰라면 바로 지적될 만한 패턴임.

• 스크롤 텍스트도 데모신의 커뮤니케이션 수단이었음.

  • 트위터, 페이스북, IRC는커녕 모뎀과 BBS 접근도 널리 퍼지기 전 이야기임.
  • 멋진 scroller에는 멋진 폰트가 필요했고, 그래서 문자셋 편집기나 폰트 편집기도 쓰였음.
  • MS-DOS용 Charedit 같은 툴이 그런 맥락에서 등장함.

하드웨어가 UI를 만든다

• Atari Falcon의 DSPdit은 Motorola 56001 DSP 프로그래밍을 위한 에디터 겸 어셈블러였음.

  • Atari Falcon에는 전용 디지털 신호 처리기(DSP)가 들어 있었음.
  • DSPdit은 그 DSP56k 프로그래밍을 겨냥했고, 표준 GEM 툴킷을 써서 비교적 깔끔하고 전문적인 느낌을 줬음.

• Amiga 최초의 바이러스와 바이러스 킬러 이야기도 나옴.

  • 첫 Amiga 바이러스는 플로피 부트 섹터를 감염시키는 bootblock 바이러스였음.
  • 만든 쪽은 Swiss Cracking Association, 즉 SCA였고, 이후 자기들이 만든 바이러스를 막기 위한 최초의 Amiga 바이러스 킬러도 만들었다고 함.
  • 죄책감이었는지는 몰라도, 결과적으로 공격자와 방어자가 같은 곳에서 나온 묘한 사례임.

• trackmo 제작 도구는 파일 시스템을 쓰지 않는 데모 배포 방식과 연결됨.

  • 많은 Amiga 데모는 데이터를 플로피 트랙에 직접 저장하는 trackmo 구조였음.
  • TrackmoDOS 같은 툴은 그런 플로피에 파일을 쓰고 지우는 기능을 제공했음.
  • 보통 파일 관리자처럼 보이지만, 대상은 일반 파일 시스템이 아니라 데모 전용 트랙 구조였다는 점이 다름.

• 마지막으로 RAW 같은 diskmag도 UI 문화의 일부로 소개됨.

  • diskmag는 플로피 디스크로 배포되는 잡지였고, 데모신 글뿐 아니라 시, 소설, 역사, 정치 에세이까지 실리곤 했음.
  • RAW는 1990년대 초반 인기 있던 Amiga diskmag였고, 반짝이는 질감의 UI와 내장 팔레트 편집기를 갖고 있었음.
  • 요즘 시각으로 보면 Frutiger Aero 이전부터 이미 번쩍이는 질감 UI를 실험하고 있었던 셈임.

• 전체적으로 이 글은 “옛날 UI 웃기다”에서 끝나는 글이 아님.

  • 데모신 툴들은 사용성이 덜 정돈돼 보여도, 실제 사용자들이 필요로 한 기능을 매우 직접적으로 담고 있었음.
  • 계산을 미리 해두고, 메모리를 뒤지고, 트랙 단위로 플로피를 다루고, 음악을 코드처럼 입력하는 UI는 전부 당시 작업 방식의 산물임.
  • 그래서 프론트엔드나 툴링 만드는 사람에게도 은근히 생각할 거리가 있음. 좋은 UI는 보편적인 예쁨보다 사용자가 처한 제약을 얼마나 정확히 이해하느냐에서 출발하니까.

---

기술 맥락

• 데모신 툴의 UI가 이상하게 보이는 이유는, 이 도구들이 일반 사용자를 넓게 받기 위한 제품이 아니었기 때문이에요. 느린 CPU, 작은 메모리, 플로피 디스크, 크래시가 흔한 개발 환경에서 이미 맥락을 아는 사람들이 빨리 결과물을 만들기 위한 화면이었거든요.

• precalc 도구가 따로 있었던 건 런타임 계산 비용이 너무 비쌌기 때문이에요. 7MHz급 CPU에서 매 프레임 사인 계산을 돌리기보다, 미리 테이블을 만들고 어셈블리 소스로 저장해 데모 코드에 붙이는 편이 훨씬 현실적이었어요.

• tracker UI가 악보처럼 생기지 않은 것도 같은 맥락이에요. 데모 음악은 샘플, 채널, 효과 명령을 제한된 하드웨어 안에서 촘촘히 제어해야 했고, 그래서 음악가용 악보 도구보다 개발자용 패턴 편집기에 가까운 인터페이스가 더 잘 맞았어요.

• 디스크 복사기와 trackmo 도구가 트랙 단위 UI를 가진 이유는 파일 시스템 바깥에서 데이터를 다뤘기 때문이에요. 게임과 데모가 플로피 트랙에 직접 데이터를 쓰면 일반 복사기로는 부족했고, 어느 트랙이 읽히고 쓰였는지 보여주는 화면이 실무적으로 필요했어요.

• 지금 기준으로는 버튼 배치나 색상 선택 방식이 엉망처럼 보일 수 있어요. 그래도 이 사례들이 재밌는 건, UI가 당시의 기술 제약과 배포 문화, 사용자 숙련도를 거의 그대로 반영하고 있다는 점이에요.