이 영상은 튜링상 수상자이자 분산 시스템 분야에 크게 기여한 레슬리 램포트와의 인터뷰를 담고 있습니다. 램포트는 자신의 주요 연구인 베이커리 알고리즘, 분산 시스템의 시간과 이벤트 순서, 비잔틴 장군 문제, 팍소스 알고리즘 등의 배경과 개발 과정에 대한 흥미로운 이야기를 들려줍니다. 특히, 그의 추상화 능력이 성공의 핵심이었음을 강조하며, 명확한 사고와 문제 해결을 위한 글쓰기와 증명의 중요성을 역설합니다. 또한, 학계 대신 산업계에서 일하게 된 이유와 대규모 동시성 이론에 대한 그의 생각 등 개인적인 경험과 철학을 공유하며, 후배들에게 practical하면서도 깊이 있는 조언을 건넵니다.
1. 베이커리 알고리즘: 동시성 프로그래밍의 시작 🍞
인터뷰는 레슬리 램포트의 베이커리 알고리즘에 대한 설명으로 시작됩니다. 이 알고리즘은 1965년 에츠허르 다익스트라(Edsger Dijkstra)가 제시한 동시성 프로그래밍의 문제, 즉 여러 프로세스가 동시에 한정된 자원(예: 프린터)을 사용하려 할 때 발생하는 동기화 문제를 해결하기 위해 고안되었습니다. 다익스트라는 이 문제를 크리티컬 섹션(Critical Section)이라는 개념으로 정의했는데, 이는 한 번에 하나의 프로세스만 실행할 수 있는 코드 영역을 의미합니다.
램포트는 1972년에 이 문제에 대한 해법을 담은 ACM(Association for Computing Machinery) 논문을 접하고 흥미를 느꼈다고 합니다. 처음에 그는 2개 프로세스를 위한 간단한 알고리즘을 만들었지만, 곧 버그를 발견하게 됩니다. 이 경험은 그에게 동시성 프로그램은 올바르게 만들기 매우 어렵고, 정확성을 증명해야 한다는 깨달음을 주었습니다. 이로 인해 그는 "젠장, 그 문제 꼭 풀고 말 거야!"라는 집념을 가지게 됩니다.
"Concurrent programs were hard to get right and that you needed a proof that they were correct." (동시성 프로그램은 제대로 만들기 어려웠고, 정확하다는 증명이 필요하다는 것을 깨달았습니다.)
이후 램포트는 델리 카운터에서 번호표를 뽑아 순서대로 서비스를 받는 아이디어에서 영감을 받아 베이커리 알고리즘을 개발했습니다. 이 알고리즘은 중앙 제어 없이 각 프로세스가 고유한 번호표를 선택하는 방식으로, 선착순(first-come, first-served) 원칙을 최초로 구현했습니다. 또한, 이 알고리즘의 놀라운 점은 공유 메모리(shared registers)의 원자성(atomic actions)을 가정하지 않아도 동작한다는 것이었습니다. 일반적으로 두 프로세스가 동시에 메모리에 쓰거나 읽을 때 문제가 발생할 수 있다고 생각했지만, 베이커리 알고리즘은 하나의 프로세스만 메모리에 쓰도록 설계되어, 동시 읽기가 발생해도 올바르게 작동했습니다. 이 점은 당시 학계에서 불가능하다고 여겨지던 문제였기에, 그의 동료인 아나톨 홀(Anatol Hol)조차 처음에 믿지 못했다고 합니다. 램포트의 베이커리 알고리즘은 다익스트라의 기존 해법보다 더 단순하고 선착순 원칙을 충족시켰다는 점에서 큰 의미를 가집니다.
2. 다익스트라와의 경험: 추상화 능력의 발견 ✨
램포트는 1976년 한 달간 네덜란드에서 다익스트라와 그의 동료들과 함께 일했던 경험을 공유했습니다. 다익스트라는 EWD(Edsger W. Dijkstra)라고 불리는 작은 논문들을 통해 자신의 아이디어를 공유했는데, 그 중 하나는 최초의 동시성 가비지 컬렉션(Concurrent Garbage Collection) 알고리즘에 관한 것이었습니다. 이 알고리즘은 프로그램이 더 이상 사용하지 않는 메모리를 자동으로 회수하는 방법으로, 동시성 환경에서 이 작업을 처리하는 것이 매우 복잡했습니다.
램포트는 다익스트라의 알고리즘을 보고 프리 리스트(free list) 처리 방식을 단순화할 수 있음을 깨달았습니다. 다익스트라는 프리 리스트를 위한 별도의 프로세스를 두어 다른 프로세스와의 조율을 신경 써야 했지만, 램포트는 프리 리스트를 일반 데이터 구조의 일부로 통합하여 특별한 처리가 필요 없게 만들었습니다. 그는 이 아이디어가 매우 간단하고 당연하다고 생각했지만, 다익스트라는 그의 아이디어에 깊은 인상을 받아 램포트를 공동 저자로 포함시켰습니다. 램포트는 나중에야 이 아이디어가 대부분의 사람들에게는 명확하지 않았고, 자신의 추상화 능력이 빛을 발한 순간이었음을 깨달았다고 회고합니다.
"I later realized much later that it was not an obvious idea to most people and that that had actually impressed Dijkstra." (나중에야 깨달았는데, 그 아이디어는 대부분의 사람들에게는 당연한 것이 아니었고, 실제로 다익스트라에게 깊은 인상을 주었다는 것을 알게 되었습니다.)
다익스트라는 훗날 램포트에게 "놀라운 추상화 능력"을 가졌다고 말했고, 램포트는 튜링상을 수상한 후 비로소 자신의 성공 비결이 특별히 똑똑해서가 아니라 이 추상화 능력 덕분이었음을 이해하게 되었다고 합니다. 네덜란드 체류 중 다익스트라와 칼 홀튼(Carl Holten)과 주 1회 토론하며 맥주를 마시던 중, 베이커리 알고리즘의 변형 아이디어가 탄생하여 논문으로 출판되기도 했습니다.
3. 가장 많이 인용된 논문: 분산 시스템의 시간과 사건 순서 ⏰
램포트의 가장 많이 인용된 논문은 "분산 시스템에서 시간, 클럭, 이벤트의 순서(Time, Clocks, and the Ordering of Events in a Distributed System)"입니다. 이 논문의 아이디어는 분산 데이터베이스를 구축하는 과정에서 발생했습니다. 당시 사람들은 여러 곳에 분산된 데이터의 사본들을 동기화하는 데 어려움을 겪고 있었는데, 램포트는 기존 해결책이 이벤트의 실제 발생 순서와 시스템이 인식하는 순서가 다를 수 있다는 문제점을 발견했습니다.
램포트는 특수 상대성 이론의 시공간 개념에서 영감을 얻었습니다. 특수 상대성 이론에서 한 사건이 다른 사건보다 먼저 발생했다고 말하는 것은, 첫 번째 사건에서 방출된 신호가 두 번째 사건이 발생하기 전에 수신되었을 때를 의미하며, 이 신호는 빛의 속도보다 빠르게 전달될 수 없습니다. 램포트는 이를 분산 시스템에 유추하여, "happens before" (선행 발생) 관계를 정의했습니다. 즉, 한 이벤트가 다른 이벤트에 정보를 전달하는 메시지를 통해 영향을 줄 수 있다면, 첫 번째 이벤트가 두 번째 이벤트보다 선행한다고 본 것입니다. 이 "happens before" 정의는 당시 분산 시스템 연구자들에게 큰 충격을 주었습니다.
이 논문의 또 다른 중요한 아이디어는 상태 기계(State Machine)를 이용한 분산 시스템 구축 방법을 제시했다는 것입니다. 램포트는 시스템을 상태와 명령의 순차적인 실행으로 구성된 상태 기계로 모델링할 수 있으며, 이 상태 기계의 동기화를 통해 분산 시스템의 일관성을 유지할 수 있음을 보였습니다. 그는 이 아이디어가 자신에게는 너무나 당연했지만, 실제로 분산 시스템을 구축하는 데 매우 중요한 개념이었음에도 불구하고 많은 사람이 이 부분을 간과했다고 합니다.
"It it turned out that this was very obvious to me, but that's really in practice the important idea in that paper because it showed that this method of building distributed systems by thinking in terms of state machine and and can thinking about concurrent systems in terms of state machines." (이것은 저에게는 매우 당연한 것이었지만, 실제로는 분산 시스템을 상태 기계로 생각하고 동시성 시스템을 상태 기계로 생각하여 구축하는 이 방법이 그 논문에서 중요한 아이디어였습니다.)
램포트는 동시성 프로그램을 이해하는 데 있어서 불변식(Invariant) 증명의 중요성을 강조합니다. 대부분의 동시성 프로그램은 원자적(atomic) 동작을 가정하고 순차적인 실행으로 이해하려 하지만, 이는 복잡성을 기하급수적으로 증가시키고 오류를 유발하기 쉽습니다. 반면, 불변식은 프로그램의 각 지점에서 항상 참인 상태 속성을 정의하며, 이를 통해 시스템의 정확성을 훨씬 효과적으로 증명할 수 있습니다. 불변식 증명의 복잡성은 프로세스 수에 비례하여 2차적(quadratic)으로 증가하는 반면, 순차적인 실행을 추론하는 방식은 지수적(exponential)으로 증가합니다.
4. 비잔틴 장군 문제: 배신자 속에서의 합의 🛡️
이어서 램포트는 비잔틴 장군 문제(Byzantine Generals Problem)에 대한 이야기를 풀어냅니다. "시간, 클럭, 이벤트 순서" 논문이 실패가 없는 시스템을 가정했다면, 비잔틴 장군 문제는 오류가 발생할 수 있는 분산 시스템을 다룹니다. 특히, 비잔틴 오류(Byzantine fault)는 프로세스가 단순히 멈추는 것을 넘어 임의의 악의적인 동작을 할 수 있는 최악의 시나리오를 가정합니다.
램포트는 SRI 인터내셔널(SRI International)에 합류하기 전에 이 문제에 대해 연구하며 디지털 서명(Digital Signatures)을 활용한 알고리즘을 고안했습니다. 디지털 서명은 메시지의 출처를 신뢰할 수 있도록 보장하는 기술로, 결함 있는 프로세스가 다른 프로세스의 서명을 위조할 수 없다는 가정하에 작동합니다. 당시 디지털 서명은 널리 알려지지 않았지만, 램포트는 친구인 윗 디피(Whit Diffie)와의 대화에서 영감을 받아 최초의 디지털 서명 알고리즘을 개발하기도 했습니다 (비록 당시에는 비실용적이었지만, 해시 함수를 통해 문서 전체가 아닌 해시 값에 서명하는 아이디어를 제안).
SRI에서 그는 비슷한 문제를 풀고 있던 동료들을 만났습니다. 그들은 디지털 서명을 사용하지 않는 다른 알고리즘을 개발했는데, 이 알고리즘은 하나의 결함을 허용하기 위해 4개의 프로세스가 필요했습니다. 반면, 디지털 서명을 사용하는 램포트의 알고리즘은 3개의 프로세스만으로도 가능했습니다. 초기 논문에는 두 가지 알고리즘이 모두 포함되었으며, 디지털 서명 없는 알고리즘은 훨씬 복잡했지만 마샬 피스(Marshall Pease)의 천재적인 아이디어가 담겨 있었다고 램포트는 회고합니다. 램포트는 훗날 더 간단한 귀납적 증명을 발견하기도 했습니다.
램포트는 비잔틴 오류가 실제 항공기 제어 시스템과 같이 악의적인 오작동이 발생할 수 있는 환경에서 매우 중요한 문제임을 강조했습니다. 1970년대 오일 쇼크 시기에 에너지 효율적인 항공기 개발을 위해 제어면을 줄여 공기역학적으로 불안정한 비행기를 컴퓨터가 제어해야 할 필요성이 커졌고, 이때 컴퓨터 오류의 종류를 예측할 수 없었기 때문에 비잔틴 오류 해결이 필수적이었습니다.
이러한 중요한 결과를 널리 알리기 위해, 램포트는 다익스트라의 "식사하는 철학자 문제"처럼 흥미로운 이야기를 덧붙이는 것의 중요성을 깨달았습니다. 그래서 그는 "비잔틴 장군 문제"라는 이름을 고안했습니다. 네 명의 장군이 공동으로 공격 여부를 결정해야 하는데, 그 중 한 명은 배신자일 수 있다는 시나리오입니다. 처음에는 "알바니아 장군 문제"를 생각했지만, 알바니아인이 실존한다는 이유로 비잔틴 제국의 이름을 사용하게 되었습니다. 이 문제의 핵심은 임의의 오류를 허용하는 분산 시스템에서 어떻게 합의를 이룰 것인가에 대한 본질적인 질문이었습니다.
5. 팍소스 알고리즘: 실용적인 합의 해결책 🛠️
램포트는 그의 또 다른 유명한 업적인 팍소스 알고리즘(Paxos Algorithm)에 대해 설명합니다. 이 알고리즘은 비잔틴 장군 문제와 마찬가지로 결함 허용 상태 기계(fault-tolerant state machine)를 구축하는 문제, 즉 여러 컴퓨터가 협력하여 하나의 일관된 서비스를 제공하도록 하는 문제를 해결합니다. 하지만 팍소스는 비잔틴 오류와 달리, 산업계에서 더 흔한 "멈춤(crash) 오류", 즉 프로세스가 단순히 멈추거나 동작을 멈추는 경우만을 가정합니다.
램포트는 1985년 DEC SRC(Digital Equipment Corporation Systems Research Center)에 합류하여 분산 운영 체제를 개발하던 중 팍소스 알고리즘을 고안했습니다. 당시 DEC SRC 팀은 제록스 파크(Xerox Park) 출신들로, 이더넷(Ethernet)을 발명하고 분산 개인 컴퓨팅 개념을 가지고 있었습니다. 그들은 공유 스토리지를 일관되게 유지하는 시스템 코드를 가지고 있었지만, 램포트는 그것이 "코드는 있지만 알고리즘은 아니다"라고 생각했습니다. 여기서 램포트는 알고리즘이 프로그램보다 더 추상적인 개념이며, 동시성 시스템을 구축할 때 코드 레벨의 복잡성보다는 추상적인 알고리즘 레벨에서 동기화 문제를 먼저 해결해야 한다는 철학을 밝힙니다.
"An algorithm is something that's more abstract than a pro than than a program... It's something that's that's at a higher level of of of abstraction." (알고리즘은 프로그램보다 더 추상적인 것입니다... 그것은 더 높은 수준의 추상화입니다.)
팍소스 알고리즘은 개발된 후 8년이 지나서야 "파트 타임 의회(The Part-Time Parliament)"라는 제목으로 출판되었습니다. 이는 초기 심사위원들이 논문의 중요성을 인지하지 못했기 때문입니다. 하지만 버틀러 램슨(Butler Lamson)과 같은 동료들이 팍소스 알고리즘의 중요성을 깨닫고 시스템 구축에 활용하기 시작하면서 아이디어가 퍼져나갔고, 램포트는 출판에 서두르지 않았다고 합니다. 결국 새로운 편집자에 의해 논문이 수정되고 보완되어 출판되었습니다.
램포트는 팍소스 논문의 배경 이야기를 고대 팍소스 섬에서 발견된 문서라는 가상의 설정으로 재미있게 엮었습니다. 심지어 발표 시에는 인디아나 존스 스타일의 고고학자 복장을 하고 나타나기도 했습니다. 하지만 그는 당시 강연에서는 사람들이 알고리즘의 중요성을 제대로 이해하지 못했다고 회상합니다. 버틀러 램슨만이 팍소스의 진정한 가치를 알아보았는데, 이는 그가 분산 시스템 구축에 대한 깊은 이해를 가지고 있었기 때문입니다.
6. 팍소스 vs 래프트 알고리즘 ⚖️
램포트는 팍소스와 유사한 문제를 해결하는 래프트 알고리즘(Raft Algorithm)에 대한 자신의 견해를 밝힙니다. 래프트 알고리즘의 저자들이 그에게 초고를 보냈을 때, 그는 "알고리즘을 가지고 오거나 증명을 가지고 와라"고 답했다고 합니다. 램포트는 래프트가 기본적으로 팍소스와 같은 아이디어를 다르게 설명한 것이라고 생각합니다.
팍소스는 두 단계(two phases)로 나뉘어 리더 선출(phase 1)과 의사 결정(phase 2)을 수행합니다. 리더가 바뀌지 않는 한 첫 번째 단계는 한 번만 수행해도 되지만, 래프트는 이를 반대 순서로, 즉 리더가 실패할 때까지 두 번째 단계를 계속하다가 실패하면 다시 첫 번째 단계로 돌아가는 방식으로 설명합니다. 램포트는 팍소스가 왜 이해하기 어려운지 모르겠다고 말하며, 자신은 5분 만에 설명할 수 있다고 합니다.
래프트 개발자들은 래프트가 더 간단하고 이해하기 쉽다고 주장했으며, 실제로 학생들을 대상으로 한 실험에서도 래프트가 더 이해하기 쉽다는 반응이 나왔다고 합니다. 하지만 램포트는 이와 관련하여 중요한 일화를 소개합니다.
"There was a bug discovered in Raft and fixed, but I believe that the algorithm that they found more understandable was one with that bug." (래프트에서 버그가 발견되어 수정되었지만, 사람들이 더 이해하기 쉽다고 여겼던 알고리즘은 그 버그가 있던 버전이라고 생각합니다.)
이는 램포트에게 "이해"의 의미에 대해 다시 생각하게 했습니다. 램포트에게 진정한 이해는 "증명을 쓸 수 있는 것"을 의미하지만, 대부분의 사람들에게 이해는 "따뜻하고 포근한 느낌(warm fuzzy feeling)"에 가깝다고 말합니다. 래프트의 설명 방식이 프로그래머들에게 그런 "따뜻한 느낌"을 주었지만, 버그가 포함되어 있었다는 사실은 직관적인 이해가 반드시 정확성을 보장하지 않음을 시사합니다. 램포트의 설명 방식은 알고리즘이 "왜 실제로 작동하는지"에 대한 더 깊은 이해를 돕는다고 그는 믿습니다.
7. LaTeX 개발: 글쓰기가 사고를 개선하는 이유 ✍️
램포트는 그의 또 다른 중요한 기여인 LaTeX(레이텍) 개발 이야기도 들려줍니다. 그는 책을 쓰기 시작하면서 텍(TeX)이라는 조판 시스템을 사용해야 했지만, 자신에게 필요한 기능을 구현하려면 매크로(macros)가 필요하다고 느꼈습니다. 그래서 그는 약간의 노력을 더하여 이 매크로를 다른 사람들도 사용할 수 있게 만들기로 했습니다.
LaTeX는 문서의 논리적 구조를 기술하고, 서식은 시스템이 자동으로 처리하는 방식(예전에 사용했던 Scribe 시스템의 아이디어)을 따릅니다. 램포트는 내용(ideas)이 중요하지, 조판(typesetting)이 중요하지 않다는 추상화적 관점을 가지고 있었습니다. 그는 출판사 편집자와 협력하여 LaTeX의 표준 스타일을 개발했습니다. 이 모든 작업은 그의 "여가 시간"에 이루어졌는데, 사실은 다른 프로젝트에 시간을 할당한 것으로 되어 있었다고 농담조로 고백합니다.
램포트는 "글쓰기가 사고를 개선하는 이유"에 대한 그의 명언을 다시 한번 강조합니다.
"If you're thinking without writing, you only think you're thinking." (쓰지 않고 생각한다면, 그저 생각하고 있다고 착각할 뿐입니다.) "If you think you know something but don't write it down, you only think you know it." (무언가를 안다고 생각하지만 적어두지 않으면, 그저 안다고 착각할 뿐입니다.)
이는 컴퓨터 시스템을 구축하는 사람들에게 특히 중요합니다. 어떤 아이디어가 작동할 것이라고 생각하거나, 다른 사람들이 사용할 것이라고 생각한다면, 그것을 글로 써서 설명해 보라는 것입니다. 그는 "프로그램을 작성하기 전에 사용 설명서를 먼저 작성하라"는 옛 격언을 인용하며, LaTeX 책을 쓰면서 설명하기 어려운 부분은 알고리즘을 변경해야 한다는 것을 깨달았다고 말합니다.
글쓰기는 스스로를 속이기 쉽기 때문에 좋은 사고를 촉진합니다. 램포트는 이 점이 증명을 작성하는 철학과도 연결된다고 말합니다. 복잡한 동시성 알고리즘의 증명을 작성하면서, 그는 세부 사항이 너무 많아 기존의 수학적 증명 방식으로는 부족하다는 것을 깨달았습니다. 그래서 그는 계층적(hierarchical) 증명 구조를 고안했습니다. 전체 문제를 더 작은 단계들로 나누고, 각 단계에 대한 증명을 제공하는 방식입니다. 이를 통해 증명의 모든 세부 사항이 명확하게 드러나고, 누락된 부분이 없도록 합니다.
램포트는 이 계층적 증명 방식을 수학자들에게 소개했을 때, 그들의 격렬한 분노에 직면했다고 합니다. 그는 수학자들이 "컴퓨터 프로그램이 이해할 수 있는 방식으로 증명을 작성해야 할 것"이라는 두려움 때문에 비합리적인 반응을 보였다고 분석합니다.
"Their reaction shocked me. They became angry. I really thought they might physically attack me." (그들의 반응은 저를 충격에 빠뜨렸습니다. 그들은 화를 냈고, 저는 그들이 저를 물리적으로 공격할 수도 있다고 생각했습니다.)
그는 자신의 방식이 더 형식적일 필요가 없으며, 단지 조직화의 문제일 뿐이라고 설명했지만, 수학자들은 여전히 "컴퓨터를 위한 증명을 쓰고 싶지 않다"고 반발했습니다. 램포트는 이런 방식이 더 많은 작업을 요구하는 이유는, 그것이 "명확하게 드러나지 않은 부분을 드러내기" 때문이라고 말합니다. 우리가 당연하다고 생각하며 적지 않은 단계들을 명시하게 만들어, 오류를 줄이고 진정으로 정직하게 만들 수 있다는 것입니다.
8. 학자가 아닌 산업계에서 일한 이유 & 대규모 동시성 이론 💡
램포트는 평생 산업계에서 일하며 연구를 수행했습니다. 그는 처음에 자신이 "컴퓨터 과학"을 하고 있다는 사실조차 인지하지 못했으며, 1970년대 중반이 되어서야 컴퓨터 과학이 학문 분야라는 것을 깨달았다고 합니다. 그는 컴퓨터 과학이 굳이 대학에서 배워야 할 학문이라고 생각하지 않았고, 가르치는 것이 재미있을 것 같지도 않았다고 합니다.
램포트는 과거에 자신이 "대규모 동시성 이론(grand theory of concurrency)"을 개발하지 못해 실패했다고 느꼈던 각주에 대한 질문에 답합니다. 많은 연구자들이 튜링 기계(Turing machine)가 컴퓨팅의 본질을 포착했듯이, 동시성 컴퓨팅의 본질을 포착할 수 있는 추상화를 찾고 있었다고 합니다. 페트리 넷(Petri nets)과 같은 시도들이 있었지만, 램포트는 대부분의 시도가 언어 기반이었다고 지적합니다. 그는 언어 자체보다는 언어가 표현하는 것(즉, 아이디어)에 관심이 많았습니다.
램포트는 이제 자신이 동시성 컴퓨팅의 튜링 기계가 상태 기계(State Machine)라고 생각한다고 말합니다. 그가 정의하는 상태 기계는 훨씬 단순하여, 명령 없이 오직 상태와 다음 상태 간의 관계만을 가집니다. 하지만 이 상태 기계는 튜링 기계와 같은 기능을 제공하지는 않습니다. 튜링 기계가 "무엇이 가능한가"를 설명한다면, 상태 기계는 "무엇이든" 설명할 수 있기 때문입니다. 램포트는 예를 들어, 변수가 "어떤 정수"든 가질 수 있다고 설명할 때, 이를 유한한 컴퓨터 정수로 제한하면 오히려 복잡해진다고 지적합니다. 무한의 개념은 오히려 복잡성을 단순화하기 위해 도입되었다는 것입니다.
"The people have this funny idea that you know because something is infinite it's more complicated. They got it backwards. Infinity was introduced to simplify things." (사람들은 무한한 것이 더 복잡하다고 생각하는 이상한 아이디어를 가지고 있습니다. 그들은 거꾸로 생각하고 있습니다. 무한은 오히려 일을 단순화하기 위해 도입되었습니다.)
램포트는 컴퓨터 과학자와 프로그래머들이 언어에 집착하는 경향이 있다고 비판합니다. 그들은 온갖 종류의 언어를 발명하고, 이 언어들이 사고를 개선한다고 믿지만, 램포트는 수학이 이해를 위한 가장 강력한 도구이며, 프로그래밍 언어와 유사한 방식으로 동시성을 다루려는 시도는 잘못된 접근 방식이라고 주장합니다. 컴퓨터 언어는 효율성 때문에 사용되지만, 이해를 위해서는 수학을 이길 수 없다는 것입니다.
9. 자신은 똑똑하지 않다는 생각 & 후배를 위한 조언 🧠
램포트는 자신의 성공에도 불구하고 스스로를 똑똑하다고 생각하지 않는다는 말을 자주 했다고 합니다. 그는 다른 사람들이 어려워하는 것을 자신은 쉽게 이해하거나 해결할 때가 많았지만, 그것이 자신에게는 당연했기 때문에 자신의 특별함을 깨닫지 못했다고 설명합니다.
그는 심리학자들이 이야기하는 현상을 언급합니다: 어떤 일에 능숙한 사람은 그것이 자신에게 쉽기 때문에 자신이 얼마나 잘하는지 깨닫지 못한다는 것입니다. 반대로, 어떤 일에 서툰 사람은 자신이 실제보다 더 낫다고 생각합니다. 램포트는 이를 좀 더 간결하게 표현합니다.
"Stupid people think they're smart because they're too stupid to realize they're not." (어리석은 사람들은 자신이 똑똑하다고 생각합니다. 너무 어리석어서 자신이 그렇지 않다는 것을 깨닫지 못하기 때문입니다.)
그의 재능은 "추상화(abstraction)"에 있으며, 최근 10년이 되어서야 자신이 다른 사람들보다 이 능력이 얼마나 뛰어난지 깨달았다고 합니다.
마지막으로, 램포트는 젊은 자신에게 줄 수 있는 조언이 무엇이냐는 질문에 답합니다. 그는 인생에서 "답할 필요가 없는 질문"에 시간을 낭비해서는 안 된다고 배웠다고 말합니다.
"One thing I've learned fairly early in my life is that I shouldn't waste time trying to answer questions that I don't have to answer." (인생에서 꽤 일찍 배운 한 가지는, 답할 필요가 없는 질문에 답하려고 시간을 낭비해서는 안 된다는 것입니다.)
그는 과거에 "무엇을 했어야 했나"와 같은 질문에 대해 생각하지 않는다고 말하며, 이는 스스로 답할 필요 없는 질문이기 때문이라고 합니다. 이는 현재에 집중하고, 불필요한 고민에 에너지를 소모하지 않는 그의 실용적인 태도를 보여줍니다.
마무리
레슬리 램포트와의 대화는 분산 시스템 분야에 대한 그의 깊이 있는 통찰력뿐만 아니라, 명확한 사고, 추상화, 그리고 글쓰기를 통한 증명의 중요성을 깨닫게 하는 시간이었습니다. 그의 경험은 기술적 문제를 해결하는 데 있어 단순히 코드를 작성하는 것을 넘어, 근본적인 아이디어와 그 아이디어의 정확성을 증명하는 과정이 얼마나 중요한지를 보여줍니다. 특히, "쓰지 않고 생각한다면, 그저 생각하고 있다고 착각할 뿐"이라는 그의 메시지는 모든 엔지니어와 연구자에게 큰 울림을 줍니다. 복잡한 시스템을 구축할 때는 직관에만 의존하지 않고, 명확한 알고리즘과 엄밀한 증명을 통해 오류를 줄이고 신뢰성을 확보해야 한다는 교훈을 얻을 수 있었습니다.