요약
1963년 왓슨 주니어는 직원 34명짜리 회사에 업계 선두를 빼앗긴 이유를 따지는 메모를 썼습니다.
컴퓨터 역사 박물관이 슈퍼컴퓨터 전시에서 소개한 IBM 내부 문서입니다. IBM을 이끌던 토머스 왓슨 주니어가 1963년 8월에 컨트롤 데이터(CDC)의 CDC 6600을 두고 직접 쓴 메모입니다.
왜 중요한가
- 업계 최강자였던 IBM이 작은 경쟁사에 기술 선두를 내줬다고 스스로 인정한 기록입니다.
- 작은 회사와 그 컴퓨터가 IBM 경영진을 흔들 만큼 충격이 컸다는 점을 보여 줍니다.
핵심 내용
- 왓슨은 IBM이 어떻게 업계 선두 자리를 잃었는지 따져 물었습니다.
- 상대 회사는 "청소부까지 포함해 34명"뿐이라고 적어 IBM의 큰 덩치와 대비했습니다.
- 이 대목 때문에 메모는 '청소부 메모(The Janitor Memo)'라는 별명으로 불립니다.
- 박물관은 IBM 기업 기록 보관소가 소장한 메모 사진을 함께 실었습니다.
HN 반응
- 여러 이용자는 질문 속에 이미 답이 있다고 봤고, 시모어 크레이도 왓슨이 스스로 답했다고 받아친 일화가 소개됐습니다.
- IBM은 위신과 고성능 컴퓨터 시장을 잃었지만 System/360 덕에 매출은 크게 늘어 실제 타격은 작았다는 반론도 나왔습니다.
흥미로운 건 질문 속에 이미 답이 들어 있었다는 점이죠. 아주 작은 노력이 어떻게 거대한 조직을 앞지를 수 있었겠습니까?
그가 그런 실수에 걸려들 줄은 상상도 못 했어요.
크레이의 대답은 냉소적이었습니다. "왓슨 씨가 스스로 자기 질문에 답을 한 것 같군요."
https://en.wikipedia.org/wiki/CDC_6600
크레이는 정말 재미있는 사람이었나 봐요.
"논리 설계 담당 조금, 프로그래머도 여기저기 조금 있으면 됩니다"
--
"그럼 대형 컴퓨터를 만들 때 겪는 문제와 해결책을 몇 가지 말씀드리죠. 우선... 저는 대형 컴퓨터는 가능한 한 가장 적은 인원으로 만들어야 한다고 생각합니다. 한 명이면 완벽하겠지만 한 명으로는 도저히 일이 안 됩니다. 그러니... 차선책은 한 12명쯤입니다."
"12명이 필요한 이유는 필요한 분야마다 한 사람씩은 있어야 하기 때문입니다. 컴퓨터가 들어갈 상자를 만들 기계공학자가 필요하고, 회로를 조립할 전기공학자가 필요하고, 논리 설계 담당이 조금, 프로그래머도 여기저기 조금 필요합니다. 그리고 물론 비서도 있어야 하고요. 하지만 그렇게 많이는 필요 없습니다."
https://managingdesignanddevelopment.blogspot.com/2022/09
크레이는 병렬 처리보다 빠른 CPU가 낫다는 얘기를 하면서 재미있는 말을 남겼습니다. "밭을 간다면 어느 쪽을 쓰겠습니까? 힘센 소 두 마리입니까, 병아리 1024마리입니까?" 물론 역사는 업계가 "병아리" 전략으로 갔다는 걸 보여 주었죠.
맞아요, 소만큼 힘센 닭을 키워 내고 나서의 얘기지만요.
그건 절반만 맞는 얘기입니다. 소가 낼 수 있는 힘에는 한계가 있고, (크레이 3으로 가는 길 어딘가에서) 시모어는 그 한계에 부딪혔습니다. 그 한계는 닭이 낼 수 있는 힘의 한계와 꽤 가깝고, 우리는 시모어가 만든 최고의 소만큼 힘센 닭을 키워 내는 데까지 왔습니다. 그러자 문제가 생겼죠. 앞으로 나아갈 유일한 길은 소만 한 슈퍼 닭을 잔뜩 모으는 것뿐이었으니까요.
누가 이 비유를 교육용 영상으로 만들어 줬으면 좋겠네요.
아니었습니다. CDC 6600 때문에 IBM의 위신은 좀 깎였지만, 매출에는 흠집 하나 나지 않았고 곧 360 시리즈 덕분에 매출이 치솟을 참이었습니다.
CDC 6600 때문에 IBM은 오늘날 고성능 컴퓨팅(HPC)이라 부를 시장을 거의 완전히 잃었습니다. 그 시장은 이후 30년 동안 CDC가, 그리고 시모어 크레이가 CDC를 떠난 뒤에는 크레이가 지배했습니다.
하지만 그 시기에 저가이면서 성능은 쓸 만한 컴퓨터 시장이 아주 빠르게 커지고 있었기 때문에, IBM은 더 작은 시장을 잃고도 영향받지 않은 채 매출과 이익이 계속 늘었습니다.
IBM은 오히려 미니컴퓨터의 주요 공급업체로 떠오른 DEC의 영향을 더 크게 받았습니다. DEC가 IBM의 저가 시장을 가져갔으니까요. 그래도 가장 큰 이익을 낼 수 있는 중간 성능대 시장, 특히 기업용 데이터 처리 시장은 계속 IBM이 지배했기 때문에 크게 걱정할 일은 없었습니다.
CDC 6600에 대응해 IBM은 ACS(Advanced Computer Systems)라는 내부 개발 프로젝트를 진행했지만, 돈줄인 IBM System/360 라인에서 자원을 빼돌린다는 이유로 결국 취소되었습니다.
ACS가 취소되지 않았다면 세계에서 가장 빠른 컴퓨터가 될 가능성이 높았을 겁니다. 설계팀이 거의 사반세기 뒤에야 컴퓨터에 도입된 여러 기법, 예컨대 제약 없는 비순차 실행(out-of-order execution)과 슈퍼스칼라 실행, 세밀한 단위의 멀티스레딩 같은 것을 이미 발명했으니까요.
이 스레드에는 전설적인 Don Hopkins가 쓴 죽은(dead) 댓글이 하나 있는데, 제가 짐작할 수 있는 이유는 딱 하나예요. 일론 머스크에 대해 사실이지만 부정적으로 말했다는 것. 댓글을 죽이다니 부끄러운 일이에요, 정말 부끄럽습니다.
HN에는 트랜스젠더의 권리를 논쟁거리이자 검열해야 할 주제로 여기는 사람이 많다고 생각합니다.
일론에 대해 말하자면, 저는 그 사이트를 계속 트위터(Twitter)라고 부를 겁니다. 그가 자기 딸의 옛 이름(deadname)을 부를 수 있다면, 저도 그의 회사들의 옛 이름을 부를 수 있으니까요.
트위터 인수 이후 재능 있는 사람들이 대거 떠났습니다. 상당 부분은 일과 삶의 균형에 대한 그의 태도 때문이었고, 이후 그의 가장 어두운 면이 점점 더 공개되면서(트럼프 취임식의 닥터 스트레인지러브 사건에서 정점을 찍었죠) 남아 있던 인재 상당수도 더 건강한 곳으로 떠났다고 봅니다. 그 시기는 장애와 데이터 손실로 가득했습니다.
@DonHopkins에 대해서는, 그의 "FORTH ?KNOW IF HONK ELSE FORTH LEARN THEN"을 정말 좋아합니다.
린 콘웨이(Lynn Conway)는 꼭 언급할 만한 ACS 발명가 중 한 명입니다. 1965년에 그녀는 일반화된 동적 명령어 스케줄링을 발명해, 여러 명령어를 비순차로 한 클록 사이클에 발행할 수 있게 했습니다. 슈퍼스칼라 아키텍처의 기초가 되는 진전이었죠. IBM은 1968년에 성전환을 이유로 그녀를 해고했습니다. 회사가 사과하기까지 52년이 걸렸습니다.
사업적 손실은 재능 있는 직원 한 명을 잃은 데 그치지 않았습니다. IBM은 근본적인 아키텍처 문제를 푸는 비범한 능력을 이미 보여 준 사람의 앞으로의 기여를 내던진 겁니다. 그녀는 이후 제록스 PARC에서 Mead-Conway VLSI 설계 혁명을 일으키는 데 기여해, 훨씬 더 많은 사람이 칩 설계에 접근할 수 있게 했습니다. IBM의 편견이 그 재능을, 그리고 그녀의 다음 돌파구를 키울 기회를 회사 밖으로 내몰았습니다.
그 손실에 금액을 매길 수는 없고, 그녀가 남아 있었다면 ACS가 살아남았을 거라고 단정할 수도 없습니다. 하지만 System/360의 이익이 늘었다고 해서 IBM이 "크게 걱정할 일이 없었다"는 게 입증되는 건 아닙니다. 오히려 잘나가는 기존 사업이 뛰어난 인재를 내던진 기회비용을 얼마나 쉽게 가려 버리는지를 보여 줍니다. IBM은 편견과 편협함을 부릴 여유가 있다고 생각했는지도 모르지만, 건전한 경영 판단은 아니었습니다.
어쩌면 콘웨이에 대한 IBM의 처사가 왓슨의 질문에 대한 또 다른 답일지도 모릅니다. 거대한 조직도 뛰어난 인재를 두고 그 재능을 허비할 수 있다는 것. 콘웨이의 해고는 CDC 6600 이후의 일이지만, 개척적인 컴퓨터 아키텍트를 성전환을 이유로 내보낸 일은 IBM의 문제가 자원 부족이 아니었음을 잘 보여 줍니다. 때로는 엔지니어와 미래 사이를 가로막는 장애물이 경영진 자신의 편견이기도 합니다.
일론 머스크는 얼마나 많은 인재를 쫓아냈을지 궁금합니다. 트랜스젠더 직원, 트랜스젠더 가족과 친구가 있는 사람들, 그리고 자기 딸을 공개적으로 모욕하고 옛 이름으로 부르고 잘못된 성별로 지칭한 그의 행태에 질려 버린 모든 사람들 말입니다. 그를 상대하고 싶지 않았던 발명가들 때문에 앞으로 얼마나 많은 돌파구가 다른 곳에서 나올까요? 그런 손실 역시 재무제표의 항목으로는 나타나지 않을 겁니다.
흥미로운 연결 고리가 하나 있습니다. 시모어 크레이의 손자 앤드루 크레이(Andrew Cray)는 트랜스 남성이자 LGBTQ 의료 옹호 활동가였습니다. 그는 2014년에 암으로 세상을 떠나기 나흘 전 새라 맥브라이드(Sarah McBride)와 결혼했습니다. 맥브라이드는 훗날 미국 연방 의회에 선출된 최초의 공개 트랜스젠더가 되었습니다.
6600은, 그리고 왓슨도 틀림없이 이 점을 듣고 갔겠지만, 극도로 특화된 기계였습니다. 60비트 워드가 전부였고 바이트나 쇼트 같은 건 없었습니다. 부동소수점 연산용으로 설계된 기계였죠. IBM은 360 이전에는 과학용과 업무용 기계를 완전히 다르고 호환도 안 되게 만들었습니다.
게다가 개별 트랜지스터로 만들었고 IC는 하나도 안 들어갔습니다. 퍼듀 대학에서 처음 들은 프로그래밍 수업은 CDC6500과 6600에 천공 카드를 썼습니다. 퍼듀의 옛 6500은 지금 시애틀의 박물관에 있습니다.
그건 메모의 요점을 놓친 말씀 같습니다. 6600은 IBM이 설계하고 판매할 자원이 분명히 있었던 물건인데도, 어떤 이유에서인지 그러지 못했다는 게 핵심이니까요.
여러 면에서 6600은 IBM으로서는 생각조차 할 수 없는 기계였습니다. 60비트 워드에 문자 단위 주소 지정도 안 되는 아주 제한적인 기계였고, 그저 터무니없이 빠를 뿐이었죠(생긴 것도 멋졌고요). 중앙 프로세서에 더해 주변 프로세서 12개가 입출력과 기타 작업을 CPU 대신 맡았습니다(IBM이 그렇게 했는지는 잘 모르겠지만, 이런 방식, 즉 채널 프로세서와 채널 프로그램은 적어도 360 이후 IBM 메인프레임에서 흔한 패턴이었습니다).
새 모델의 출시를 늦춰서 기존의 확고한 라인의 매출을 너무 잠식하지 않게 하는 건 아주 흔한 일입니다. CDC는 아주 군살 없는 회사였지만, IBM은 스스로의 파괴적 혁신으로부터 지켜야 할 제품 라인이 아주 많았습니다.
언제나 기억해야 할 점은, 캐시카우를 죽일 제품은 내가 먼저 개발하는 편이 낫다는 겁니다. 어차피 누군가는 만들 테고, 그게 경쟁사이길 바라는 사람은 없을 테니까요.
무슨 말씀이시죠? 문자 단위 주소 지정이 없었다니요? 1963년에 IBM이 팔던 과학용 기계인 704x/709x는 36비트 워드 주소 지정 방식이었습니다. 6600은 여러 면에서 분명 그런 기계들과 비슷했고요. 그리고 업무용 애플리케이션에 문자 단위 주소 지정은 필요 없었습니다. 그 기계들에도 코볼 컴파일러가 있었으니까요. 6600에서 더 특이한 점은 중앙 프로세서와 주변 프로세서의 분리였습니다. 360을 그런 식으로 설계했다면 운영체제 상당 부분이 채널에서, 아니면 당시 오프라인 천공 카드/프린터 지원에 쓰던 소형 컴퓨터에서 돌아갔을 겁니다.
훨씬 더 큰 누락은 IBM이 너무 늦을 때까지 시분할(time-sharing)을 고려하길 거부했다는 점이고, 그러고 나서는 TSS/360으로 완전히 망쳐 버렸죠. (360/67은 좋은 기계였고 저도 좋은 기억이 있지만, 다른 OS가 필요했습니다. 저희 쪽에서는 Michigan Terminal System이었습니다.) IBM은 대화형 컴퓨팅의 필요성을 이해하는 데 오랜 시간이 걸렸습니다.
《맨먼스 미신(The Mythical Man-Month)》은 1975년에야 나왔는데요.
그럼 CDC 6600은 RISC 머신으로 보지는 않고, 선구자 격으로 보는 건가요?
RISC라는 용어는 15년도 더 지나서 만들어졌고, 최초의 RISC CPU인 IBM 801은 "RISC"라는 용어가 도입되기 몇 년 전에 설계되었습니다.
IBM 801이 최초의 RISC 머신이라 불릴 만한 이유는, 그 설계 방법론이 명령어 집합을 단순화해 IBM 370보다 높은 성능을 내겠다는 분명한 목표를 가졌고, 훗날 버클리와 스탠퍼드의 RISC 설계(나중에 SPARC과 MIPS로 발전했습니다)가 채택한 원칙을 모두 도입했기 때문입니다.
CDC 6600은 이전 아키텍처를 단순화해서 만든 게 아닙니다. 오히려 그전의 아주 단순했던 CDC 컴퓨터들보다 더 복잡했습니다.
그렇더라도 당시 기술로 가능한 최대 성능을 내도록 설계되었고, 제임스 E. 손턴과 시모어 크레이는 둘 다 극도로 유능한 컴퓨터 설계자였기 때문에, 그들의 설계 결정 중 상당수가 오랜 뒤 RISC CPU가 선호한 결정과 일치합니다.
주목할 점은, CDC 6600이 빠른 레지스터 간 연산에 의존하는 단순한 명령어 집합을 가졌지만, 일부 잘못 설계된 RISC처럼 ISA가 지나치게 단순하지는 않았다는 겁니다. 예를 들어 주소 레지스터를 자동 갱신하는 인덱스 주소 지정을 포함한 최초의 ISA 가운데 하나였습니다(최초일 수도 있고요). 이는 배열에 접근하는 최고 성능의 루프를 구현하는 데 아주 유용합니다(명령어 쌍 융합은 로드/스토어 명령어마다 자동 갱신을 지정하는 비트 1개를 두는 것보다 훨씬 열등한 해법입니다).
IBM 801에도 자동 갱신 주소 지정 모드가 있었고, 이는 ARM, HP PA-RISC, IBM POWER가 물려받았습니다. Aarch64도 32비트 ARM에서 이어받았습니다. x86-64는 자동 갱신 주소 지정이 일부 특수 명령어에만 있지만, 대부분의 경우 같은 성능을 내는 다른 방법으로 최대 3개 구성 요소와 스케일 인덱스를 쓰는 인덱스 주소 지정(DEC VAX에서 가져왔습니다)을 갖추고 있습니다. 이 덕분에 루프 카운터를 여러 배열에 접근하는 인덱스 레지스터로도 쓸 수 있어, 별도의 인덱스 갱신 명령어가 필요 없어집니다.
CDC 6600 ISA에는 앨런 튜링이 처음 제안하고 페란티 마크 1 컴퓨터가 ("sideways add"라는 이름으로) 구현한 명령어도 들어 있었습니다. 이 명령어는 나중에 크레이 1 ISA에서 "population count"로 이름이 바뀌었고, AMD 바르셀로나 CPU, 이어서 인텔 네할렘 CPU가 x86-64 ISA에 추가했습니다. 이 명령어는 NSA의 요청으로 CDC 6600에 추가되었다고 하는데, NSA는 이후 CDC 슈퍼컴퓨터, 나중에는 크레이 슈퍼컴퓨터의 중요한 고객이 되었습니다.
"population count"는 흔히 정보 이론, 부호 이론, 암호학에서 쓰이는 해밍 거리와 연결됩니다. 그런데 제 생각에 이 명령어가 실제로 쓰인 용도는 따로 있는데, 바로 코사인 유사도입니다.
두 벡터 A와 B의 일반적인 정의는 A.B = |A||B|cos ø입니다. A와 B가 이진 벡터라면 A and B = popcnt(A)popcnt(B)cos ø가 됩니다. 유사도는 cos ø가 1에 얼마나 가까운가로 잴 수 있습니다.
요즘 용어로 말하면, 메시지와 검색 조건 집합이 있고 메시지에 워드 임베딩을 쓴다고 할 때, 각 검색 조건과의 유사도는 cos ø = (A and B)/(popcnt A * popcnt B)로 계산합니다. 이는 popcnt 명령어가 내장되어 있어야만 벡터화할 수 있습니다. cos ø가 0보다 큰 결과는 어느 정도 유사성이 있다는 뜻입니다.
그러니 특정 키워드가 들어 있는 모든 메시지를 포착하고 (재)스캔하고 표시하려면, KEYSCORE를 생성하는 시스템을 설계하면 됩니다. 거짓 양성을 줄이도록 확장(eXtended)하면 XKEYSCORE라는 후속 시스템이 되고요.
마지막 문단은 순전히 추측이지만 일리가 있다고 생각합니다. 직접 가진 데이터로 한번 해 볼 만하지 않을까요?
하지만 슈퍼스칼라가 등장한 뒤에는 그런 RISC도 주소 갱신 명령어를 메모리 접근 명령어와 동시에 실행할 수 있습니다.
맞는 말이지만, 명령어 1개 대신 2개가 되면 명령어 캐시와 명령어 디코더에서 여전히 많은 자원이 낭비됩니다.
모든 슈퍼스칼라 CPU에는 가져오고(fetch), 디코드하고, 이름을 바꾸고(rename), 디스패치할 수 있는 명령어 수에 한계가 있습니다. 배열 처리 루프에서 로드와 스토어마다 명령어가 1개가 아니라 2개가 되면 그 한계 중 어느 하나를 넘어서서, ALU/AGU 실행 유닛이 충분히 남아 있어도 실행이 느려질 수 있습니다.
그래서 주류 ISA는 모두 CDC 6600과 IBM 801의 해법인 인덱스 레지스터 자동 갱신 방식, 아니면 DEC VAX의 해법인 스케일 인덱스와 최대 3개 구성 요소(베이스 + 인덱스 + 변위)를 쓰는 인덱스 주소 지정 방식 중 하나를 구현합니다. 자동 갱신이 가능하면 인덱스 스케일링 없는 2요소 인덱스 주소 지정만으로 충분합니다(2개 요소는 베이스 + 인덱스 레지스터와 베이스 + 변위 중에서 고를 수 있습니다).
자동 갱신 방식은 언제나 명령어 수가 최소인 루프를 가능하게 하고, 스케일 인덱스 주소 지정은 적절한 데이터 구조(즉 SoA)를 쓰면 대부분의 경우 명령어 수가 최소인 루프를 가능하게 합니다.
의욕 넘치는 소규모 팀이 자유재량을 갖고 일한 것과 IBM의 위원회식 개발이 맞붙은 전형적인 사례입니다. 아이러니하게도 20년도 안 지나 IBM은 똑같은 일을 하게 되고, 그 결과가 IBM PC였죠.
IBM은 PC를 성공작으로 여겼을까요? 특히 시간이 지나면서 PC가 IBM의 주력인 메인프레임 시장을 잠식했고, 최종 사용자용 컴퓨팅에서는 레노버에 넘기고 손을 뗐잖아요. 반대로 IBM이 안 했더라도 다른 회사들이 이미 시도하고 있었고요.
이 시기 IBM 메모에서 저에게 가장 인상적인 점은 임원들의 문장력이 얼마나 뛰어났느냐는 겁니다. 요즘 부사장들은 읽을 만한 문장 하나 쓰기도 힘겨워하는 경우가 대부분이거든요.
그때는 비서도 있었습니다(임원급에서는 더더욱요). 비서가 편지를 교정해서 상사에게 돌려주면 상사가 수정하거나 서명했죠. 요즘은 누구든 그냥 전송 버튼을 누르면 끝이잖아요. 덜 정리된 생각과 문법 오류까지 그대로 나가 버립니다.
의사소통 능력을 키우고 싶다면, 이메일을 다 쓴 뒤 30~40분쯤 임시 저장 상태로 둬 보세요. 그런 다음 새로운 시각으로 다시 읽어 보는 겁니다.
하나 더 추천하자면, 미 공군에 이 주제를 다룬 매뉴얼이 있는데, 명확하고 간결하고 구체적으로 쓰는 법을 안내해 줍니다.
https://static.e-publishing.af.mil/production/1/saf_aa/publication/afh33-337/afh33-337.pdf
관련이 있을지 모르겠는데, 저는 오래된 백과사전을 몇 질 갖고 있습니다. 1940년대 Collier's와 1960년대, 1980년대 World Book인데, 오래된 쪽의 글이 얼마나 더 잘 쓰였는지 확연히 느껴져요.
1921년판 예시는 여기 있습니다. https://archive.org/details/colliersnewencyc01newy/page/40/mode/2up
그리고 이상한 오류도 하나 있어요. 예시를 찾다가 봤는데, 위키백과의 Collier's 항목은 1949년에 시작했다고 하는데 제가 가진 책은 저작권 표시가 1932~1944년이라 아마 1944~45년에 인쇄됐을 겁니다.
그 시대 사람들은 대체로 책도 많이 읽고 말도 잘했습니다. 특히 그는 공군 조종사, 소련 주재 대사, 보이스카우트 회장 등등 흥미로운 인생 경험을 한 사람 같았습니다.
저는 정부 기관에서 일하면서, 제가 태어나기도 전에 입찰 공고가 나서 서른 번쯤 수정된 아주 오래된 비(非)IBM 메인프레임 계약을 둘러싼 소송에 관여한 적이 있습니다.
그 파일에 든 메모와 편지는 놀라우면서도 우울했습니다. 70년대 후반에서 2010년경까지 쭉 훑어보면 글의 질이 꾸준히 떨어졌거든요.