단어 아래 빨간색·초록색 물결선을 남긴 Tony Krueger를 추모하며

• Tony Krueger는 Microsoft Word에서 맞춤법·문법 문제를 빨간색과 초록색 물결선으로 즉시 표시하는 기능에 참여해, 거의 모든 사용자가 본 UI 흔적을 남김
• 초기 Word의 맞춤법 검사는 사용자가 직접 실행해야 했고, Auto Spell Check도 저장·종료 같은 전경 작업을 막는 차단 작업이라 많은 사용자가 꺼두었음
• Krueger는 검사가 사용자를 멈춰 세우지 않도록 더 덜 거슬리는 방식을 만들었고, 문제가 발견되면 별도 실행을 기다리지 않고 단어 아래에 표시함
• 그는 Word 1.0, 1.1, 2.0, Word for OS/2, Word for Mac, Word 6.0과 이후 여러 버전에 참여했으며, Chip’s Challenge의 Windows 이식도 맡았음
• 오늘날 빨간색뿐 아니라 초록색·파란색 물결선은 워드프로세서와 다른 소프트웨어 전반에 퍼졌고, Krueger의 작업은 일상적인 편집 피드백 UI로 남아 있음

---

Tony Krueger와 Word의 물결선 UI

• Tony Krueger는 결과물은 널리 알려졌지만 이름은 상대적으로 덜 알려진 인물임
• Wikipedia에서는 Windows Entertainment Pack용 Chip’s Challenge를 Windows로 이식한 사람으로 남아 있음
  • 이 이식은 MS-DOS 버전의 소스 코드 없이 역공학한 뒤 Windows용으로 다시 구현한 작업이었음
• 더 많은 사람에게 닿은 코드는 Microsoft Word의 맞춤법·문법 표시 기능이었음

여러 Word 버전에 남긴 발자취

• Krueger는 여러 Word 버전 개발에 참여함
  • Word 1.0
  • Word 1.1
  • Word 2.0
  • Word for OS/2
  • Word for Mac
  • Word 6.0과 이후 여러 버전
• 그는 “가장 많은 Word 버전을 출시한 사람” 기록을 갖고 있을 가능성이 있는 인물로 언급됨

초기 맞춤법 검사가 불편했던 이유

• 초기 Word의 Spell Check는 사용자가 명시적으로 실행해야 하는 기능이었음
• 사용자는 프로그램이 잠재적 오타를 모두 찾을 때까지 기다린 뒤, 각 단어를 하나씩 보며 처리 방식을 결정해야 했음
• Word는 사용자가 유휴 상태일 때 미리 맞춤법 검사를 수행하는 Auto Spell Check를 도입함
  • 사용자가 Spell Check 버튼을 눌렀을 때 결과가 준비되어 있게 하려는 방식이었음
  • 하지만 Auto Spell Check도 여전히 사용자의 다음 작업을 막는 차단 작업으로 남아 있었음
• 많은 사용자가 이 기능을 꺼둔 이유도 여기에 있었음
  • 문서를 저장하고 종료하려는 순간 맞춤법 검사가 시작되면, 검사가 끝날 때까지 기다려야 했음

빨간색·초록색 물결선의 도입

• Krueger는 맞춤법 검사가 전경 작업을 방해하지 않도록 훨씬 더 덜 거슬리는 방식으로 바꿈
• 문제가 발견되면 사용자가 Spell Check를 실행할 때까지 기다리지 않고, 잠재적 오타 아래에 빨간색 물결선을 즉시 그림
• 이후 잠재적 문법 오류에는 초록색 물결선이 사용됨
• 이 방식은 오늘날 거의 모든 워드프로세서에서 볼 수 있고, 워드프로세서 밖에서도 자주 쓰임
  • 빨간색뿐 아니라 초록색과 파란색 물결선도 널리 쓰임

기능을 기억한 사람들

• Krueger는 마술·코미디 듀오 Penn and Teller의 초기 팬이었음
• 한 친구이자 동료가 공연 후 두 사람에게 Tony를 위한 사진 사인을 부탁하며, 그가 Word의 빨간색·초록색 물결선 팀에 있었다고 말함
• Penn Jillette는 극장 전체에 울릴 정도의 목소리로 “The red and green squiggles!? I love the red and green squiggles!”라고 반응했고, Teller도 조용히 동의함
• Krueger는 생일 선물로 그 사인 사진을 받았고, 사인 사진 자체와 Penn and Teller가 그의 기능을 좋아했다는 사실 중 무엇을 더 기뻐했는지는 분명하지 않았음
• 훗날 “Weird Al” Yankovic의 패러디 영상 Word Crimes 에 Word의 빨간색 물결선이 잠깐 등장했고, 같은 친구가 해당 화면 캡처에 사인을 받음

남은 흔적

• 빨간색 물결선은 사용자의 실수를 잡아내는 일상적 편집 피드백으로 남아 있음
• Krueger가 먼저 한 작업은 이후 여러 소프트웨어의 텍스트 오류 표시 방식으로 확산됨

[GN⁺]

Hacker News 의견들

• 회사에서 소프트웨어를 만드는 업계에 계속 있으면서 소스 코드에 이름을 남기면, 언젠가는 전혀 예상하지 못했던 제품이나 기능으로 기억되게 됨
  정작 가장 열심히 만들었고 그걸로 알려지길 바랐던 것들은 시간이 지나며 잊혀짐. 무언가를 만드는 과정은 완전히 자기 통제 안에 있지만, 무엇으로 알려질지는 완전히 통제 밖에 있음

• Amiga의 Prowrite는 Word보다 먼저 실시간 맞춤법 검사를 제공했음
  그보다 앞서 같은 기능을 가진 프로그램이 더 있었을 수도 있지만, Prowrite는 틀린 단어 아래에 빨간 물결 밑줄을 그어 줬음
  https://www.atarimagazines.com/compute/issue123/P215_1_REVIE...

  • 정말 확실한가? 링크한 페이지에는 “10만 단어 맞춤법 검사기가 텍스트 범위 검사, 단일 단어 조회, 연속 검사, 사용자 사전 추가를 지원한다”고만 되어 있고, 단어 밑줄은 언급하지 않음
    그 기능의 스크린샷도 찾지 못했음. AmigaOS 1.x 색상표라면 표준 색상이 검정/흰색/파랑/주황이었으니 물결선은 아마 빨강이 아니라 주황이었을 것 같음. AmigaOS 2 이후는 3D 효과를 위해 검정/흰색/회색/파랑이었으니 강조색은 파랑이어야 했을지도 모름
  • DOS의 PC-Write에도 있었음

• 여러 언어로 작업하는 환경에서는 물결 밑줄이 쓸모없을 때가 많음
  시스템이 내가 쓰는 텍스트의 언어를 추측하려 하지만 대개 틀리고, 그 결과 시각적 잡음이 되어 싸우거나 무시해야 함. 매번 상호작용할 때마다 언어 설정을 수동으로 바꾸는 것도 너무 불편함

  • 교정 언어를 지정하는 문자 스타일에 단축키를 붙여 썼음. 예를 들어 shift-alt-1은 영어, shift-alt-2는 독일어로 설정하는 식임
    문자 스타일이라 입력 중인 현재 위치에도 적용되고 선택한 범위에도 적용됨. 미리 설정하는 걸 깜빡해서 한 줄에 물결선이 잔뜩 생겼을 때도 처리 가능함. 아니면 전체 텍스트의 교정 언어를 None으로 설정해서 맞춤법·문법 진단을 전부 없앨 수도 있음
  • 같은 문제가 있음. 프로그램마다 처리 수준이 다른데, Affinity 제품군은 특히 나쁨

• 흥미롭게도 Chen의 글은 Tony Krueger가 이식했다는 근거로 Wikipedia 페이지를 가리킴
  그런데 최신판에서 그 항목의 근거는 다시 Chen의 글로 돌아가는 링크임

  • 시간순으로 보면 이렇다: Chen의 글이 참조로 추가되기 전 Wikipedia 페이지는 https://en.wikipedia.org/w/index.php?title=Chip%27s_Challeng...였고, “Tony Krueger가 코딩했다”는 내용은 “게임의 About 상자”를, “[Krueger가] 한 여름에 작성했다”는 내용은 포럼 글을 출처로 삼고 있었음
    Chen의 글은 “Tony Krueger는 Wikipedia에서 …를 이식한 사람으로 기억된다”고 쓴 뒤, “그가 소스 코드 없이 이 일을 해냈다는 점은 아마 그만큼 널리 문서화되어 있지 않을 것이다. 그는 MS-DOS 버전을 역공학한 뒤 Windows용으로 다시 구현했다”는 각주를 덧붙임. 이후 Wikipedia 문서가 이 추가 정보를 위해 Chen의 글을 인용한 것임. 전부 문제없고 적절하며, 방금 인용이 다시 명확해지도록 편집했음
  • 참고로 Raymond Chen 블로그 인용은 구체적으로 소스 코드가 없어서 MS-DOS 이식판을 역공학했다는 주장에 붙어 있음
    편집 전에는 게임 자체가 Tony와 Ed Halley를 개발자로 적은 근거였는데, Chen 블로그의 역공학 일화를 추가한 사람이 문장을 나누면서 개발자 이름에 대한 인용이 다른 사람에게만 적용되도록 만들어 버렸음
    https://en.wikipedia.org/w/index.php?title=Chip%27s_Challeng...
  • Chen은 Krueger가 게임을 이식했다는 근거로 Wikipedia를 쓰는 게 아님
    Wikipedia가 그를 가장 잘 알려진 일로 무엇을 적고 있는지 가리킨 뒤, Krueger에 대해 또 하나 주목할 만한 것, 즉 물결 밑줄을 덧붙이는 구조임. Chen의 글 전체를 읽으면 아래쪽에 이식에 관한 세부 내용도 더해 두었으니 그 사실을 분명히 알고 있음. 이 글을 이식의 근거로 써도 괜찮음. Wikipedia에서 이런 순환 근거 사슬이 실제로 생기긴 하지만, 이 경우는 아닌 것 같음

• 이런 글이 좋음. 가능한 수많은 갈래 중에서 하필 물결선이 선택됐고, 그것도 한 사람이 즉흥적으로 내린 결정에서 나온 것인데 결국 세상을 완전히 바꿔 버림

  • 모든 갈래가 다 일어났고, 지금 우리는 그중 물결선이 된 우주에 있는 것뿐임

• 물결 밑줄을 항상 좋아하진 않지만, UI 패턴으로는 인정할 만함
  “이 단어에 뭔가 문제가 있다”를 나타내는 시각적 표시 중에서 가장 직관적이고 알아보기 쉬운 축에 듦

• 제출 제목과 microsoft.com 도메인만 봐도 항상 Raymond 글이라는 걸 알아차릴 수 있음. 정말 좋아하는 사람임

• “그는 소스 코드 없이 이 일을 해냈다”라니, 물론이지. 여긴 HN인데 누가 소스 코드가 필요하겠음
  다만 역공학 대신 나였다면 에뮬레이터를 찾거나 만들었을 것 같음. 다른 소프트웨어도 “이식”하라는 요청을 받을 수 있으니까. 우리가 쓰는 소프트웨어의 좋은 기능과 나쁜 기능을 누가 책임졌는지 대부분 모른다는 건 사실 슬픈 일임. 영화는 끝에 크레딧을 길게 보여 주는 관행이 있고, 나는 그걸 자세히 읽는 걸 좋아함. 소프트웨어 개발에도 그런 문화가 있어야 함. 일부 게임은 그렇게 하고, 몇몇 Easter egg도 그런 역할을 함

• 맞춤법 검사를 완전히 끌 수 있으면 정말 좋겠음
  아주 틈새 취향이라는 건 알지만, 내 실수와 함께 살아도 괜찮고, 속어·기술 용어·약어 같은 것들을 매번 “학습”시키고 싶지 않음. 비표준 영어로 쓰는 사람들은 요즘 어떻게 버티는지 자주 궁금함. James Joyce가 좋아했을 거라고는 상상하기 어려움

  • 뭐가 막고 있나? 내 모든 기기에서는 맞춤법 검사를 꺼 두었음
    원어민도 아니어서 분명 도움은 되겠지만, 의도적으로 쓴 문자열에 불평하거나 자동 수정하는 게 싫다는 점은 같음
  • MS Word에는 “입력할 때 맞춤법 검사” 옵션이 있고 끌 수 있음. 문법 검사도 마찬가지임

• Larry Constantine이 물결 밑줄을 정말 싫어했던 걸로 기억함
  그의 표현대로라면 글을 쓸 때는 항상 다음 단어를 생각해야 하는데, 물결선은 이미 쓴 단어로 주의를 끌어감. “이봐, 들어봐! 네가 정말 철자를 쓸 줄 안다고 생각해? 방금 쓴 ‘fatouos’는 대체 뭐야?”라고 외치며, 멈춰서 물결 밑줄이 그어진 단어를 클릭해 고칠 때까지 계속 괴롭힘. 사실상 Clippy의 원시적 형태임
  Word가 vi처럼 두 가지 모드를 가지면 해결될 수 있음. 쓰기 모드에서는 아무것도 방해하지 않고 글만 쓰게 하고, 편집 모드로 전환하는 버튼을 누르는 순간 물결선과 AI 제안을 마음껏 쏟아내게 하면 됨

[GN⁺]

Lobste.rs 의견들

• 재미있는 유산임. 물결 밑줄이 좋은 반응을 얻어서 다행임
  그리고 이 각주는 꽤 대단함: “아마 널리 알려지지는 않았겠지만, 그는 [Chip's Challenge 이식]을 소스 코드 없이 해냈다. MS-DOS 버전을 역공학한 뒤 Windows용으로 다시 구현했다.”
  • Penn and Teller / Weird Al에 대한 고개 끄덕임도 분명 엄청난 기분이었을 듯함
    방금 찾아보니 Tony는 1989년부터 Microsoft에서 끝까지 일했고, 계산이 맞다면 37년 조금 넘게 근무한 셈임
• 처음 반응은 “와, 이걸 멈춤 없이 몇 초씩 잡아먹지 않게 만드는 게 쉬워 보이는데”였음
  그런데 곧 90년대 초라면 RAM이 4~8MB였을 테고, 영어 단어 목록 전체를 그냥 메모리에 올려둘 수 없었겠다는 생각이 듦. 게다가 90년대 초 C++의 다중 스레드 처리가 어땠는지는 몰라도, 2000년대 후반에도 불쾌했으니 꽤 까다로운 문제였을 가능성이 큼
  • Word ’95는 Windows 95/NT 위에서 돌아갔으니 이미 선점형 멀티태스킹과 Win32를 썼고, Windows 3.x보다 다중 스레딩이 더 쉽고 안정적이었을 것임. 빨간 물결 밑줄 UI가 가능해진 주된 이유도 그쪽으로 보임
    사전 크기와 관련해서는, 초기 맞춤법 검사기 중 하나가 1970년대 후반에 영어 사전을 64KB RAM에 넣는 데 성공했음(Jon Bentley의 Programming pearls 참고). DAWG를 쓰면 중간 규모 영어 사전 10만 단어를 400KB로 압축했고, 철자 제안 검색도 빨랐음: https://www.strchr.com/ternary_dags
• 좋은 기능이긴 한데, 사람들이 스크린샷을 쓰는 탓인지 물결 밑줄이 인쇄물이나 발표 슬라이드에 그대로 들어가면 볼 때마다 움찔함
  • 보통은 Google Docs나 Apple Notes에서 나온 경우가 많아 보이고, 기본 스타일만 봐도 구분 가능함