IBM은 전설적으로 과잉 관리가 심했음
예전에 같이 일하던 사람이 90년대 중반 런던 IBM에서 여름 인턴으로 지금의 QA 엔지니어링 같은 일을 했는데, 당시 모두 정장을 입고 출근하던 문화가 바뀌는 중이라 인턴들이 금요일만 캐주얼 복장을 허용해 달라고 요청했다고 함
고객과 만날 일도 없이 뒷방에 갇혀 일하던 처지라 큰일이 아니라고 생각했지만, 몇 달 뒤 인턴십이 끝나기 직전에야 답장이 왔고, 요청은 런던 사무실의 4단계 결재선을 거쳐 미국 본사로 넘어간 뒤 부사장 책상까지 올라갔음
각 계층이 이런 중대한 사안을 처리할 권한이 있는지 고민하느라 몇 주가 걸린 듯했고, 답장은 다시 같은 경로를 한 단계씩 내려와 대서양을 건너 런던의 정장 입은 인턴들에게 도착했는데, 그때는 인턴십이 며칠밖에 남지 않았음
답은 불허였음
90년대 후반 다른 나라로 이주하면서 일자리를 찾다가 OS/2 경험이 있어서 현지 IBM 사무실에 지원했는데, 곧 다른 곳에서 제안을 3개 받고 하나를 수락한 뒤 IBM 지원 사실은 완전히 잊어버렸음
그런데 8개월 뒤 IBM 인사팀에서 다음 주 목요일 면접을 보고 싶다고 전화했고, 더 이상 관심 없다고 하자 완전히 당황해했음
대체 무슨 생각이었는지 모르겠지만, 좋은 연봉을 제시하는 것도 아니면서 유난히 자의식이 강했음
아버지가 IBM에서 평생 일했는데, 검은색이 아닌 정장을 입어도 된다고 하자 파란 정장을 입고 갔고 상사가 “버스 타고 출근했냐”고 물었다고 함
1988~89년에 영국 Winchester의 IBM 연구개발 사이트에서 1년 인턴을 했는데, 인턴 중 누구도 정장이나 넥타이를 하지 않았고 정규 IBM 직원들도 많이 그러진 않았던 것으로 기억함
꽤 비공식적인 분위기였고, 앞 이야기 자체를 부정하려는 건 아니라 다른 관점을 보태는 것임
이런 사례가 몇 개 있음
근무 외 시간에 만드는 지식재산에 대해 IBM이 우선권을 갖는 계약 조건에서 예외를 달라고 요청했음
기술지원 콜센터에서 일했을 뿐이라 IBM 독점 정보에 접근하지도 않았고 개발 역할도 없었으며, 이 측면에서는 위험이 전혀 없었음
실제로 물리적으로 만날 수 있는 사람들은 모두 매우 합리적인 요청이라고 봤지만, 첫 번째 거절 답변이 오기까지 6주가 걸렸고 직속 관리자가 중재를 시도하면서 검토에 2주가 더 추가됐으나 답은 여전히 거절이었음
보고 라인을 따라 미국까지 올라가 법무 쪽으로 갈라졌다가 다시 내려온 듯했고, 결국 친구와 작은 소프트웨어 프로젝트를 해도 IBM이 권리를 주장할 위험을 피하려고 회사를 떠났음
또 HR 양식은 80년대 초반에 작성되어 2000년대에 디지털화된 것이었고, 고객 대면이 아닌 우리 팀은 매우 다양했음
다른 성별·대명사 조합을 인정하도록 양식을 업데이트하려는 시도가 있었는데 검토에 12주쯤 걸렸고, 결국 누가 양식을 고쳐야 하는지 파악하고 싶어 하는 사람이 없어서 거절된 것 같음
팀에는 LGBT 구성원이 많았고 이들의 유지가 중요해 보였는데도 단호히 거절됐음
성희롱 예방 교육은 2010년에 테이프로 제공됐고, “업데이트된 버전”이라고 되어 있었으니 이전에는 비닐 레코드였을지도 모르겠음
이 이야기가 이상하게 느껴지는 건 IBM이 여러 제품에서 키보드 명명법을 일관되게 썼고, 3270 계열 메인프레임 터미널은 현대 키보드의 Tab 위치에 있는 Tab 키로 커서를 다음 필드로 이동시켰기 때문임 https://www.bitsavers.org/pdf/ibm/3278/GA27-2890-4_3278_Disp... PDF 73쪽
참고로 IBM 터미널에서는 필드 간 이동이 중요해서 Tab 키 반대쪽에 전용 Back Tab 키도 있었음
원래 IBM PC에서는 두 기능을 하나의 키로 합쳤고, 그래서 고전 PC 키보드의 Tab 키에는 전방 Tab과 후방 Tab 기호가 함께 있으며, 후방 Tab 기호가 위쪽에 있는 건 Shift를 눌러야 한다는 뜻임
추가로 5250 계열 터미널은 Tab/Back Tab 대신 “Field Advance”와 “Field Backspace”라는 용어를 썼지만, 키의 기호와 위치는 3270 계열과 대략 같았음
참고: https://www.bitsavers.org/pdf/ibm/5291/GA21-9409-0_5291_Disp...
실제 IBM 3270 키보드는 이렇다[1]
왼쪽의 “Next field” 키와 오른쪽의 대응되는 “Previous field” 키를 보면 됨
IBM 3270은 양식 입력용 장치였고, 메인프레임이 빈칸이 있는 양식을 터미널로 보내면 사용자가 빈칸을 채웠음
터미널 하드웨어가 양식의 고정 부분을 덮어쓰지 못하게 막고 숫자 필드 같은 제약도 적용했으며, 이 모든 처리는 터미널에서 이루어졌음
양식을 다 채우면 사용자가 ENTER를 누르고 완성된 양식이 하나의 트랜잭션으로 메인프레임에 전송됐음
이 방식 덕분에 하나의 메인프레임이 엄청난 수의 터미널을 처리할 수 있었고, 사용자는 입력 중 지연을 느끼지 않고 보지 않고도 빠르게 타이핑할 수 있었음
PC에는 이런 사용 모델이 없었고, PC 쪽 사람들은 “타자기”를 떠올렸음
초기 가정용 컴퓨터 터미널 중 하나도 “TV Typewriter”라고 불렸음
웹 양식은 이런 모델을 갖고 있지만 일관성은 더 떨어짐
[1] https://sharktastica.co.uk/resources/images/model_bs/themk_1...
IBM에서 일해 본 입장에서 추측하자면, Tab 키를 이런 식으로 쓰는 것이 IBM이 추진하던 특허의 일부였고 Microsoft가 그렇게 사용하면 “자명한 것”으로 보여 특허화가 어려워질 수 있었던 것 같음
다만 추측일 뿐임
80년대 IBM에는 “Systems Engineers”라는 고위 기술직군이 있었는데, 그들의 전체 직무는 특정 시스템의 장단점을 논평하는 것이었음
시스템을 작성하거나 디버깅하거나 설명하는 것도 아니고, 그냥 “당신은 잘못하고 있다”고 판단하는 역할이었음
IBM이 사업부 전반의 기업 규범을 보통 철저히 지켰다는 점을 생각하면 이상하지만, IBM PC의 기원을 다룬 책들을 보면 Boca의 PC 조직이 IBM 기준으로는 비정상적인 예외였다는 점과 관련 있을 수 있음
Microsoft 팀에는 절망적으로 기업적인 조직처럼 보였지만, IBM 내부에서 Boca 사람들은 “반란 부대”로 여겨졌고, 사실 IBM 대부분은 그 존재조차 몰랐음
IBM 시간 감각으로는 거의 하룻밤 사이에 시작됐고, 엄청난 속도로 움직였으며, Thomas Watson Jr.가 부하들의 반대를 누르고 이런 스컹크웍스를 승인했기 때문에 가능했음
그래서 Boca에는 보통 그 규모의 프로젝트라면 있었을 감독, 조율, 통제가 거의 없었음
초기 Boca는 정상적인 보고 체계 밖에서 움직였고, IBM의 다른 부서에서 기술이나 부품을 조달하려고 할 때 자신들이 실제로 IBM 소속이라는 사실을 설명해야 하는 경우도 있었음
기억하기로 IBM 3270 터미널에는 “Enter/Return” 키가 두 개 있었음
하나는 오늘날의 일반 Return 키로, 다음 필드로 이동할 뿐 양식을 제출하지 않았음
또 하나의 Enter 키가 지금의 오른쪽 Ctrl 위치에 있었고, 그 키가 양식을 제출했음
그래서 IBM이 Tab 키 자체를 반대한 게 아니라, 3270 사용자가 다음 필드로 이동한다고 기대하는 Return 키를 양식 제출 키로 쓰는 것에 반대했을 수 있음
DOS 프로그램도 이런 경우가 많아서 Return을 누르면 양식 제출이 아니라 다음 필드로 갔고, Windows에서는 익숙해져야 했던 부분 중 하나였음
Tab을 선호하는 사람으로서 논쟁을 벌이려는 건 아니지만, 예전에 Twitter에서 Brendan Eich에게 왜 공백을 선호하느냐고 물어본 적이 있음
그의 답은 예상보다 더 사려 깊었음
현대 운영체제와 사용자 인터페이스 동작이 Tab 키 자체를 가로채기 때문에, 특히 브라우저 같은 맥락에서는 실제 탭 문자를 입력하기가 복잡해진다는 것임
그래도 나는 여전히 Tab을 선호하고 Go 개발자이지만, 이게 정말 성가신 문제라는 점에서는 그가 완전히 맞음
예를 들어 Hacker News의 텍스트 영역에 탭 문자를 넣어 보려고 하면 바로 알 수 있음
그래도 리터럴 탭 문자를 쓰지 않는 사람들도 코드를 쓸 때는 Tab 키를 누르지 않나? 설마 공백을 N번 누르나?
주장은 어느 정도 이해하지만, 탭/공백이 중요한 코드를 HN 텍스트 영역에서 작성하고 있다면 그 자체로 뭔가 잘못된 것임
코드 편집기라면 Tab 키를 제대로 처리함
다만 Enter에는 Shift+Enter, Alt+Enter, Cmd+Enter 식으로 어느 정도 관습이 있는데, 운영체제 전반에 쓸 수 있는 탭 문자 입력 방식이 거의 없는 건 여전히 화가 남
Shift/Alt/Ctrl+Tab도 대개 이미 다른 동작에 가로채여 있음
“탭”과 “다음 필드”를 위한 키를 분리하고, “줄바꿈”과 “전송”도 별도 키로 두는 것이 합리적일 수 있음
다만 탭과 줄바꿈이 모든 맥락에 적용되는 것은 아님
또한 어떤 프로그램에서는 ^V를 쓰듯, 제어 문자를 명령이 아니라 데이터로 입력하는 키나 키 조합을 두는 것도 합리적일 수 있음
기존 컴퓨터와 같을 필요가 없는 새 컴퓨터를 설계할 때 고려할 만한 요소이고, 나도 이런 것들을 생각해 봤으며 실제로 고려할 수도 있음
대부분의 사람이 Tab 키가 올바른 선택이라고 생각한다는 사실이야말로, 왜 그 선택이 올바르지 않았는지를 보여주는 완벽한 예임
Tab 키에는 원래 목적이 있었는데 가로채였고, 그 실제 목적을 쓰기 더 어렵게 만들었음
Apple이 처음 Touch Bar를 도입하면서 Escape 키를 없앤 것과 크게 다르지 않음
평균 사용자는 그 키를 거의 쓰지 않을 수 있지만, 평균 개발자는 그 키의 본래 목적을 오래 쓰지 않고 지내기 어렵다
영어가 모국어가 아니라 Brendan이 한 말을 이해해 보려는 중임
예전에 탭 키는 시스템마다 다르게 표현될 수 있어서, 항상 같은 방식으로 표현되는 공백이 더 안전하다는 말을 들은 적이 있음
Brendan이 말하려던 게 그 뜻인가?
사람마다 탭 간격을 똑같이 설정해 두지 않는다는 문제도 있음
훌륭한 글이지만, IBM이 Tab 키를 이렇게 쓰는 것에 반대한 이유가 무엇이었는지는 여전히 궁금함
Tab이 입력 문자이면서 동시에 제어 문자가 되는 걸 원치 않았기 때문일까?
즉 어떤 입력 필드에는 Tab을 입력할 수 있고, 어떤 경우에는 입력할 수 없는데, 어느 쪽인지 즉시 알기 어렵다는 이유일까?
2026년이 된 지금도 이런 관점에는 공감할 수 있음
개인적으로는 필드 이동에 Tab 키를 쓰는 걸 좋아하지 않음
첫째로 DOS에서의 호환성 깨짐이었음
DOS 프로그램은 Enter를 썼고, 숫자 키패드에도 Enter 키가 있어서 한 손으로 숫자 데이터를 입력할 수 있었음
왼손은 종이 원본에 두고 오른손으로 입력할 수 있었고, 사람들은 여기에 매우 빨라졌음
이 패턴은 Excel 같은 일부 프로그램에도 남아 있음
많은 고객들은 키보드에 양손을 올려야 하는 걸 싫어했고, 우리 프로그램 다수는 Enter=Tab 매핑을 허용했음
중요한 건 키의 “이름”이 아니라 위치임
키의 이중 용도는 우리가 감수하는 성가심일 뿐이고, 어떤 때는 탐색키처럼 동작하지만 다른 때는 공백 입력키처럼 동작함
Enter도 같은 문제가 있었을 것임
압도적으로 좋은 해법은 키보드에 새 키를 하나 추가하는 것이었고, 가능하면 숫자 키패드에 두는 편이 좋았을 것임
그 시기에 새 키가 많이 생겼는데, 돌이켜 보면 그때 “다음으로 이동” 키를 추가했어야 했음
브라우저 안에서 실행되는 텍스트 편집기를 설계한다면 Tab 키 기능에 대한 사용자 기대를 완전히 깨야 함
그런 환경에서는 Tab 키가 수행할 수 있는 완전히 논리적이고 직관적인 역할이 두 가지 있는데 서로 충돌하기 때문임
같은 문제는 Enter 키에서도 훨씬 자주 발생하며, 현대에도 우리는 ctrl+crlf가 줄바꿈인지 메시지 전송인지, 단독 crlf와 shift+crlf가 각각 무엇을 하는지에 대한 꽤 복잡한 규칙을 외우고 있음
HN 편집기에서는 shift+crlf와 단독 crlf가 줄바꿈을 만들고 ctrl+crlf는 아무 일도 하지 않음
하지만 다른 곳에서는 ctrl+crlf가 양식이나 메시지 제출을 트리거하고, shift+crlf가 원시 줄바꿈을 넣으며, 단독 crlf는 둘 중 하나일 수도 있고 둘 다 아닐 수도 있음
흔한 바인딩은 이렇지만 예외와 반전도 봤고, shift+crlf가 양식 제출을 하고 ctrl+crlf가 원시 줄바꿈을 넣어야 하는 경우도 있었음
이런 것들은 전부 정말 성가시고 사용자 마찰을 크게 만들며, 한동안 Microsoft 스타일 가이드는 요즘 사람들에게는 아이러니하게 보일지 몰라도 모범 사례의 핵심 참고문헌으로 여겨졌음
CAPSLOCK을 “다음 입력 선택”으로 쓰고 TAB을 문자로 쓰는 세계를 상상하게 됨
그렇게 봐도 될 것 같음
수많은 움직이는 부품이 있는 조직을 관리하는 것과, 사용자를 위해 빠르게 무언가를 만드는 것은 분명 관심사가 크게 다름
내가 읽기에는 완전한 “IBM의 이유”가 있었던 것 같지는 않음
IBM 관료제의 한 사람이 끼어들어 일을 멈춰 세웠고, 그게 문화 차이를 보여준다는 식으로 읽었음
애초에 그 글 자체가 그런 문화 차이에 대한 글이기 때문임
IBM은 MS-DOS가 옵션에 “-”를 지원하지 않는 이유이기도 하고, 모든 드라이브의 “\DEV” 디렉터리에 장치를 두지 않게 된 이유이기도 함
“/”를 경로 구분자로 지원하는 건 살아남았음
Microsoft의 많은 사람들은 Xenix를 썼고 Unix 팬이었으며, 아주 초기 DOS에는 이런 용도의 SWITCHCHAR와 AVAILDEV config.sys 옵션이 있었음
하지만 내가 알기로 IBM이 이에 대해 크게 반발했고 제거를 강요했음
특히 DEV 문제가 짜증나는 건 DOS 1에는 디렉터리가 없었으니 호환성 문제가 클 수 없었다는 점임
그런데 그 결과 DOS/Windows는 장치 파일이 모든 디렉터리에 존재한다고 가정하기 때문에 “CON”이나 “COM1”이라는 이름의 파일 생성을 지원하지 못하는 상태에 묶여 있음
Microsoft는 MS-DOS에서 그것을 제거한 적이 없음
다만 수년 동안 이를 위해 필요한 호출을 문서화하지 않았을 뿐임
나도 항상 IBM 표준은 TAB으로 이동하고 ENTER로 양식을 확정하는 것이라고 생각했음
내 기억도 정확히 그럼
Tab을 쓰는 건 거의 제2의 천성이었고, GUI 앱으로 넘어갔을 때 특히 Visual Basic 앱에서 탭 순서가 잘못되어 있으면 짜증났음
IBM 그린스크린을 쓴 지 오래됐지만, 우리 애플리케이션에서는 Tab이 필드 사이를 이동했던 것으로 기억함
다만 그 목적에 예약된 기능키들도 있었던 것 같음
미드레인지 시스템은 어땠는지 궁금함
AS/400은 써본 적 없지만, 별도의 Field Exit 키 개념이 있는 것으로 알고 있음
“Microsoft 사람들은 IBM 동료들을 쓸데없는 관료주의에 빠진 사람들로 보고, IBM 사람들은 Microsoft 사람들을 규율 없는 해커로 봤다”는 대목이 크게 웃겼음
MSFT에서 일하는데, 그 시절 Microsoft는 지금과 아주 다른 회사였던 모양임
지금은 끝없는 회의, AI 지시, 승진 연극 등으로 나와 동료들이 쓸데없는 관료주의에 갇혀 있다고 느낀다
보수는 괜찮지만 관료주의가 영혼을 갉아먹음
모든 기계에 게임 컨트롤러를 연결해서 방향 버튼으로 필드 사이를 이동하고, ‘A’ 키로 계층 메뉴에서 한 단계 위로 가며, ‘B’ 키로 하위 메뉴에 들어가게 해야 함
그러면 필드 사이를 이동하려면 데이터를 입력한 다음 키보드에서 손을 떼고 게임 컨트롤러를 집어 들고 오른쪽이나 왼쪽 버튼을 누른 뒤 다시 키보드에 손을 올리면 됨
생산성이 정말 엄청나게 올라갈 것임
30년 넘게 Mac 사용자였지만 Raymond Chen의 역사 글은 정말 좋아함
folklore.org는 알고 있지만, Apple 내부에도 그에 해당하는 무언가가 있으면 좋겠음
아쉽게도 그런 건 Apple 문화의 일부가 아님
Apple 문화는 어쩔 수 없지만, 시간이 충분히 지났으니 이야기를 하나 공유해도 아무도 문제 삼지 않을 것 같음
1992년에 System Software 팀의 여름 인턴이었고, 내 프로젝트 중 하나는 디스크 초기화 중 발견된 불량 블록을 표시하는 Disk Initialization Package 기능을 개선하는 것이었음
기존 기능은 동작했지만 매우 느렸고 진행 상황도 보여주지 않았으며 취소도 할 수 없었음
가장 까다로운 부분은 사용자 인터페이스였음
속도는 많이 개선했지만 전체 과정이 얼마나 걸릴지 알 수 없어서, 남은 시간을 보여주려는 모든 휴리스틱이 형편없었음
몇 칸 떨어진 곳에 직함이 “User Interface”인 사람이 보여 도움을 줄 수 있을지 궁금해졌고, 잠깐 시간이 있느냐고 물은 뒤 Apple 직원 4번이자 두 Steve를 서로 소개한 Bill Fernandez와 앉아서 문제를 풀어봤음
그 여름에 만난 사람 중 내 매니저를 제외하면 정말 가장 친절한 사람이었고, 문제를 즉시 완전히 이해한 뒤 훌륭한 해법을 냈음
남은 시간 추정은 버리고, 각 디스크 트랙을 테스트할 때마다 진행되는 불확정 진행 막대로 바꾸자는 것이었음
잘 동작했고 사람들이 좋아했으며 7.1 이후 포인트 릴리스에 포함됐음
Raymond 글들만큼 놀랍지는 않지만 시작으로는 충분함
모든 시대가 거의 모든 세부 사항을 두고 싸움으로 가득했다는 점이 존경스럽게 느껴짐
키도 그렇고, 배열, 모양, 의미까지 모두 포함됨
그런데 지금은 아무도 이런 것들에 신경 쓰지 않는다는 게 매우 이상하면서도 웃김
Hacker News 의견들
IBM은 전설적으로 과잉 관리가 심했음
예전에 같이 일하던 사람이 90년대 중반 런던 IBM에서 여름 인턴으로 지금의 QA 엔지니어링 같은 일을 했는데, 당시 모두 정장을 입고 출근하던 문화가 바뀌는 중이라 인턴들이 금요일만 캐주얼 복장을 허용해 달라고 요청했다고 함
고객과 만날 일도 없이 뒷방에 갇혀 일하던 처지라 큰일이 아니라고 생각했지만, 몇 달 뒤 인턴십이 끝나기 직전에야 답장이 왔고, 요청은 런던 사무실의 4단계 결재선을 거쳐 미국 본사로 넘어간 뒤 부사장 책상까지 올라갔음
각 계층이 이런 중대한 사안을 처리할 권한이 있는지 고민하느라 몇 주가 걸린 듯했고, 답장은 다시 같은 경로를 한 단계씩 내려와 대서양을 건너 런던의 정장 입은 인턴들에게 도착했는데, 그때는 인턴십이 며칠밖에 남지 않았음
답은 불허였음
그런데 8개월 뒤 IBM 인사팀에서 다음 주 목요일 면접을 보고 싶다고 전화했고, 더 이상 관심 없다고 하자 완전히 당황해했음
대체 무슨 생각이었는지 모르겠지만, 좋은 연봉을 제시하는 것도 아니면서 유난히 자의식이 강했음
꽤 비공식적인 분위기였고, 앞 이야기 자체를 부정하려는 건 아니라 다른 관점을 보태는 것임
근무 외 시간에 만드는 지식재산에 대해 IBM이 우선권을 갖는 계약 조건에서 예외를 달라고 요청했음
기술지원 콜센터에서 일했을 뿐이라 IBM 독점 정보에 접근하지도 않았고 개발 역할도 없었으며, 이 측면에서는 위험이 전혀 없었음
실제로 물리적으로 만날 수 있는 사람들은 모두 매우 합리적인 요청이라고 봤지만, 첫 번째 거절 답변이 오기까지 6주가 걸렸고 직속 관리자가 중재를 시도하면서 검토에 2주가 더 추가됐으나 답은 여전히 거절이었음
보고 라인을 따라 미국까지 올라가 법무 쪽으로 갈라졌다가 다시 내려온 듯했고, 결국 친구와 작은 소프트웨어 프로젝트를 해도 IBM이 권리를 주장할 위험을 피하려고 회사를 떠났음
또 HR 양식은 80년대 초반에 작성되어 2000년대에 디지털화된 것이었고, 고객 대면이 아닌 우리 팀은 매우 다양했음
다른 성별·대명사 조합을 인정하도록 양식을 업데이트하려는 시도가 있었는데 검토에 12주쯤 걸렸고, 결국 누가 양식을 고쳐야 하는지 파악하고 싶어 하는 사람이 없어서 거절된 것 같음
팀에는 LGBT 구성원이 많았고 이들의 유지가 중요해 보였는데도 단호히 거절됐음
성희롱 예방 교육은 2010년에 테이프로 제공됐고, “업데이트된 버전”이라고 되어 있었으니 이전에는 비닐 레코드였을지도 모르겠음
이 이야기가 이상하게 느껴지는 건 IBM이 여러 제품에서 키보드 명명법을 일관되게 썼고, 3270 계열 메인프레임 터미널은 현대 키보드의 Tab 위치에 있는 Tab 키로 커서를 다음 필드로 이동시켰기 때문임
https://www.bitsavers.org/pdf/ibm/3278/GA27-2890-4_3278_Disp... PDF 73쪽
참고로 IBM 터미널에서는 필드 간 이동이 중요해서 Tab 키 반대쪽에 전용 Back Tab 키도 있었음
원래 IBM PC에서는 두 기능을 하나의 키로 합쳤고, 그래서 고전 PC 키보드의 Tab 키에는 전방 Tab과 후방 Tab 기호가 함께 있으며, 후방 Tab 기호가 위쪽에 있는 건 Shift를 눌러야 한다는 뜻임
추가로 5250 계열 터미널은 Tab/Back Tab 대신 “Field Advance”와 “Field Backspace”라는 용어를 썼지만, 키의 기호와 위치는 3270 계열과 대략 같았음
참고: https://www.bitsavers.org/pdf/ibm/5291/GA21-9409-0_5291_Disp...
왼쪽의 “Next field” 키와 오른쪽의 대응되는 “Previous field” 키를 보면 됨
IBM 3270은 양식 입력용 장치였고, 메인프레임이 빈칸이 있는 양식을 터미널로 보내면 사용자가 빈칸을 채웠음
터미널 하드웨어가 양식의 고정 부분을 덮어쓰지 못하게 막고 숫자 필드 같은 제약도 적용했으며, 이 모든 처리는 터미널에서 이루어졌음
양식을 다 채우면 사용자가 ENTER를 누르고 완성된 양식이 하나의 트랜잭션으로 메인프레임에 전송됐음
이 방식 덕분에 하나의 메인프레임이 엄청난 수의 터미널을 처리할 수 있었고, 사용자는 입력 중 지연을 느끼지 않고 보지 않고도 빠르게 타이핑할 수 있었음
PC에는 이런 사용 모델이 없었고, PC 쪽 사람들은 “타자기”를 떠올렸음
초기 가정용 컴퓨터 터미널 중 하나도 “TV Typewriter”라고 불렸음
웹 양식은 이런 모델을 갖고 있지만 일관성은 더 떨어짐
[1] https://sharktastica.co.uk/resources/images/model_bs/themk_1...
다만 추측일 뿐임
80년대 IBM에는 “Systems Engineers”라는 고위 기술직군이 있었는데, 그들의 전체 직무는 특정 시스템의 장단점을 논평하는 것이었음
시스템을 작성하거나 디버깅하거나 설명하는 것도 아니고, 그냥 “당신은 잘못하고 있다”고 판단하는 역할이었음
Microsoft 팀에는 절망적으로 기업적인 조직처럼 보였지만, IBM 내부에서 Boca 사람들은 “반란 부대”로 여겨졌고, 사실 IBM 대부분은 그 존재조차 몰랐음
IBM 시간 감각으로는 거의 하룻밤 사이에 시작됐고, 엄청난 속도로 움직였으며, Thomas Watson Jr.가 부하들의 반대를 누르고 이런 스컹크웍스를 승인했기 때문에 가능했음
그래서 Boca에는 보통 그 규모의 프로젝트라면 있었을 감독, 조율, 통제가 거의 없었음
초기 Boca는 정상적인 보고 체계 밖에서 움직였고, IBM의 다른 부서에서 기술이나 부품을 조달하려고 할 때 자신들이 실제로 IBM 소속이라는 사실을 설명해야 하는 경우도 있었음
하나는 오늘날의 일반 Return 키로, 다음 필드로 이동할 뿐 양식을 제출하지 않았음
또 하나의 Enter 키가 지금의 오른쪽 Ctrl 위치에 있었고, 그 키가 양식을 제출했음
그래서 IBM이 Tab 키 자체를 반대한 게 아니라, 3270 사용자가 다음 필드로 이동한다고 기대하는 Return 키를 양식 제출 키로 쓰는 것에 반대했을 수 있음
DOS 프로그램도 이런 경우가 많아서 Return을 누르면 양식 제출이 아니라 다음 필드로 갔고, Windows에서는 익숙해져야 했던 부분 중 하나였음
CUA는 Tab과 Backtab이 필드 사이를 이동한다고 명시적으로 말함
그러니 IBM은 자기 표준을 상대로 7단계 관리 계층을 올려가며 반대했던 셈임: https://archive.org/details/ibmsj2703E/page/n13/mode/2up
Tab을 선호하는 사람으로서 논쟁을 벌이려는 건 아니지만, 예전에 Twitter에서 Brendan Eich에게 왜 공백을 선호하느냐고 물어본 적이 있음
그의 답은 예상보다 더 사려 깊었음
현대 운영체제와 사용자 인터페이스 동작이 Tab 키 자체를 가로채기 때문에, 특히 브라우저 같은 맥락에서는 실제 탭 문자를 입력하기가 복잡해진다는 것임
그래도 나는 여전히 Tab을 선호하고 Go 개발자이지만, 이게 정말 성가신 문제라는 점에서는 그가 완전히 맞음
예를 들어 Hacker News의 텍스트 영역에 탭 문자를 넣어 보려고 하면 바로 알 수 있음
주장은 어느 정도 이해하지만, 탭/공백이 중요한 코드를 HN 텍스트 영역에서 작성하고 있다면 그 자체로 뭔가 잘못된 것임
코드 편집기라면 Tab 키를 제대로 처리함
다만 Enter에는 Shift+Enter, Alt+Enter, Cmd+Enter 식으로 어느 정도 관습이 있는데, 운영체제 전반에 쓸 수 있는 탭 문자 입력 방식이 거의 없는 건 여전히 화가 남
Shift/Alt/Ctrl+Tab도 대개 이미 다른 동작에 가로채여 있음
다만 탭과 줄바꿈이 모든 맥락에 적용되는 것은 아님
또한 어떤 프로그램에서는 ^V를 쓰듯, 제어 문자를 명령이 아니라 데이터로 입력하는 키나 키 조합을 두는 것도 합리적일 수 있음
기존 컴퓨터와 같을 필요가 없는 새 컴퓨터를 설계할 때 고려할 만한 요소이고, 나도 이런 것들을 생각해 봤으며 실제로 고려할 수도 있음
Tab 키에는 원래 목적이 있었는데 가로채였고, 그 실제 목적을 쓰기 더 어렵게 만들었음
Apple이 처음 Touch Bar를 도입하면서 Escape 키를 없앤 것과 크게 다르지 않음
평균 사용자는 그 키를 거의 쓰지 않을 수 있지만, 평균 개발자는 그 키의 본래 목적을 오래 쓰지 않고 지내기 어렵다
예전에 탭 키는 시스템마다 다르게 표현될 수 있어서, 항상 같은 방식으로 표현되는 공백이 더 안전하다는 말을 들은 적이 있음
Brendan이 말하려던 게 그 뜻인가?
훌륭한 글이지만, IBM이 Tab 키를 이렇게 쓰는 것에 반대한 이유가 무엇이었는지는 여전히 궁금함
Tab이 입력 문자이면서 동시에 제어 문자가 되는 걸 원치 않았기 때문일까?
즉 어떤 입력 필드에는 Tab을 입력할 수 있고, 어떤 경우에는 입력할 수 없는데, 어느 쪽인지 즉시 알기 어렵다는 이유일까?
2026년이 된 지금도 이런 관점에는 공감할 수 있음
첫째로 DOS에서의 호환성 깨짐이었음
DOS 프로그램은 Enter를 썼고, 숫자 키패드에도 Enter 키가 있어서 한 손으로 숫자 데이터를 입력할 수 있었음
왼손은 종이 원본에 두고 오른손으로 입력할 수 있었고, 사람들은 여기에 매우 빨라졌음
이 패턴은 Excel 같은 일부 프로그램에도 남아 있음
많은 고객들은 키보드에 양손을 올려야 하는 걸 싫어했고, 우리 프로그램 다수는 Enter=Tab 매핑을 허용했음
중요한 건 키의 “이름”이 아니라 위치임
키의 이중 용도는 우리가 감수하는 성가심일 뿐이고, 어떤 때는 탐색키처럼 동작하지만 다른 때는 공백 입력키처럼 동작함
Enter도 같은 문제가 있었을 것임
압도적으로 좋은 해법은 키보드에 새 키를 하나 추가하는 것이었고, 가능하면 숫자 키패드에 두는 편이 좋았을 것임
그 시기에 새 키가 많이 생겼는데, 돌이켜 보면 그때 “다음으로 이동” 키를 추가했어야 했음
그런 환경에서는 Tab 키가 수행할 수 있는 완전히 논리적이고 직관적인 역할이 두 가지 있는데 서로 충돌하기 때문임
같은 문제는 Enter 키에서도 훨씬 자주 발생하며, 현대에도 우리는 ctrl+crlf가 줄바꿈인지 메시지 전송인지, 단독 crlf와 shift+crlf가 각각 무엇을 하는지에 대한 꽤 복잡한 규칙을 외우고 있음
HN 편집기에서는 shift+crlf와 단독 crlf가 줄바꿈을 만들고 ctrl+crlf는 아무 일도 하지 않음
하지만 다른 곳에서는 ctrl+crlf가 양식이나 메시지 제출을 트리거하고, shift+crlf가 원시 줄바꿈을 넣으며, 단독 crlf는 둘 중 하나일 수도 있고 둘 다 아닐 수도 있음
흔한 바인딩은 이렇지만 예외와 반전도 봤고, shift+crlf가 양식 제출을 하고 ctrl+crlf가 원시 줄바꿈을 넣어야 하는 경우도 있었음
이런 것들은 전부 정말 성가시고 사용자 마찰을 크게 만들며, 한동안 Microsoft 스타일 가이드는 요즘 사람들에게는 아이러니하게 보일지 몰라도 모범 사례의 핵심 참고문헌으로 여겨졌음
수많은 움직이는 부품이 있는 조직을 관리하는 것과, 사용자를 위해 빠르게 무언가를 만드는 것은 분명 관심사가 크게 다름
IBM 관료제의 한 사람이 끼어들어 일을 멈춰 세웠고, 그게 문화 차이를 보여준다는 식으로 읽었음
애초에 그 글 자체가 그런 문화 차이에 대한 글이기 때문임
IBM은 MS-DOS가 옵션에 “-”를 지원하지 않는 이유이기도 하고, 모든 드라이브의 “\DEV” 디렉터리에 장치를 두지 않게 된 이유이기도 함
“/”를 경로 구분자로 지원하는 건 살아남았음
Microsoft의 많은 사람들은 Xenix를 썼고 Unix 팬이었으며, 아주 초기 DOS에는 이런 용도의 SWITCHCHAR와 AVAILDEV config.sys 옵션이 있었음
하지만 내가 알기로 IBM이 이에 대해 크게 반발했고 제거를 강요했음
특히 DEV 문제가 짜증나는 건 DOS 1에는 디렉터리가 없었으니 호환성 문제가 클 수 없었다는 점임
그런데 그 결과 DOS/Windows는 장치 파일이 모든 디렉터리에 존재한다고 가정하기 때문에 “CON”이나 “COM1”이라는 이름의 파일 생성을 지원하지 못하는 상태에 묶여 있음
다만 수년 동안 이를 위해 필요한 호출을 문서화하지 않았을 뿐임
메인프레임 3270에서는 Tab 키가 필드 사이 이동에 쓰였던 것으로 기억해서 이상함
Operator's Guide PDF를 찾았음
https://news.ycombinator.com/item?id=48028227를 보면 됨
Tab을 쓰는 건 거의 제2의 천성이었고, GUI 앱으로 넘어갔을 때 특히 Visual Basic 앱에서 탭 순서가 잘못되어 있으면 짜증났음
다만 그 목적에 예약된 기능키들도 있었던 것 같음
AS/400은 써본 적 없지만, 별도의 Field Exit 키 개념이 있는 것으로 알고 있음
“Microsoft 사람들은 IBM 동료들을 쓸데없는 관료주의에 빠진 사람들로 보고, IBM 사람들은 Microsoft 사람들을 규율 없는 해커로 봤다”는 대목이 크게 웃겼음
MSFT에서 일하는데, 그 시절 Microsoft는 지금과 아주 다른 회사였던 모양임
지금은 끝없는 회의, AI 지시, 승진 연극 등으로 나와 동료들이 쓸데없는 관료주의에 갇혀 있다고 느낀다
보수는 괜찮지만 관료주의가 영혼을 갉아먹음
모든 기계에 게임 컨트롤러를 연결해서 방향 버튼으로 필드 사이를 이동하고, ‘A’ 키로 계층 메뉴에서 한 단계 위로 가며, ‘B’ 키로 하위 메뉴에 들어가게 해야 함
그러면 필드 사이를 이동하려면 데이터를 입력한 다음 키보드에서 손을 떼고 게임 컨트롤러를 집어 들고 오른쪽이나 왼쪽 버튼을 누른 뒤 다시 키보드에 손을 올리면 됨
생산성이 정말 엄청나게 올라갈 것임
표준 운영체제 컨트롤을 쓰는 비디오 게임을 게임패드로 자연스럽게 제어할 수 있게 하려는 목적임
반드시 특허를 내야 함
그동안 우리는 차선책인 마우스를 써야겠음
30년 넘게 Mac 사용자였지만 Raymond Chen의 역사 글은 정말 좋아함
folklore.org는 알고 있지만, Apple 내부에도 그에 해당하는 무언가가 있으면 좋겠음
아쉽게도 그런 건 Apple 문화의 일부가 아님
1992년에 System Software 팀의 여름 인턴이었고, 내 프로젝트 중 하나는 디스크 초기화 중 발견된 불량 블록을 표시하는 Disk Initialization Package 기능을 개선하는 것이었음
기존 기능은 동작했지만 매우 느렸고 진행 상황도 보여주지 않았으며 취소도 할 수 없었음
가장 까다로운 부분은 사용자 인터페이스였음
속도는 많이 개선했지만 전체 과정이 얼마나 걸릴지 알 수 없어서, 남은 시간을 보여주려는 모든 휴리스틱이 형편없었음
몇 칸 떨어진 곳에 직함이 “User Interface”인 사람이 보여 도움을 줄 수 있을지 궁금해졌고, 잠깐 시간이 있느냐고 물은 뒤 Apple 직원 4번이자 두 Steve를 서로 소개한 Bill Fernandez와 앉아서 문제를 풀어봤음
그 여름에 만난 사람 중 내 매니저를 제외하면 정말 가장 친절한 사람이었고, 문제를 즉시 완전히 이해한 뒤 훌륭한 해법을 냈음
남은 시간 추정은 버리고, 각 디스크 트랙을 테스트할 때마다 진행되는 불확정 진행 막대로 바꾸자는 것이었음
잘 동작했고 사람들이 좋아했으며 7.1 이후 포인트 릴리스에 포함됐음
Raymond 글들만큼 놀랍지는 않지만 시작으로는 충분함
모든 시대가 거의 모든 세부 사항을 두고 싸움으로 가득했다는 점이 존경스럽게 느껴짐
키도 그렇고, 배열, 모양, 의미까지 모두 포함됨
그런데 지금은 아무도 이런 것들에 신경 쓰지 않는다는 게 매우 이상하면서도 웃김