[ "길벗 출판사에서 책을 협찬 받아 작성된 서평입니다." ]
우리, 프로그래머들
로버트 C. 마틴: 로버트 C. 마틴(엉클 밥)은 1970년부터 프로그래머로 일해 왔다. 그는 엉클 밥 컨설팅(Uncle Bob Consulting, LLC)의 설립자이며, 아들 미카 마틴과 함께 클린 코더스(Clean Coders, LLC)를 공동 설립했다. 각종 업계 저널에 글을 수십 편 기고했고, 국제 콘퍼런스와 전시회에서 정기적으로 강연하고 있다.
저서 및 편저로는
『Designing Object-Oriented C++ Applications Using the Booch Method』,『Pattern Languages of Program Design 3』,『More C++ Gems』,『Extreme Programming in Practice』,『Agile Software Development: Principles, Patterns, and Practices』,『UML for Java Programmers』,『Clean Code』,『The Clean Coder』,『Functional Design: Principles, Patterns, and Practices』등이 있다. 소프트웨어 개발 업계의 선도적 인물로 3년간 ‘The C++ Report’의 편집장을 지냈고, 애자일 얼라이언스(Agile Alliance)의 초대 의장을 맡았다. 개발자에겐 너무 익숙한 우리 엉클밥 형님..
🔥 길벗 책 링크 - https://gilbut.co/c/26015205VE
리뷰
요새 개발자의 미래에 대한 글과 견해가 쏟아져 나옵니다. 더구나 온라인 세션, 멘토링을 하다 보면 “AI가 코딩 다 하는데 왜 배워요?”, “개발자는 이제 뭐가 남아요?” 같은 질문을 정말 자주 받습니다. 하꼬인 저도 그러는데 로버트 C. 마틴(엉클 밥)은 이런 질문을 얼마나 오래, 얼마나 많이 받아왔을까 싶어 웃음이 나기도 했습니다.
그 쏟아지는 담론 중 제가 가장 오래 붙잡게 된 키워드는 “대체”가 아니라 업의 재정의였습니다. 개발자는 사라지느냐/남느냐의 문제가 아니라, ‘개발자’라는 직업이 어떤 핵을 중심으로 다시 정의되느냐의 문제라는 관점입니다. 웹 퍼블리셔, 웹 디자이너가 “증발”하지 않았듯이, 다들 역할과 책임이 재배치되며 타이틀과 경계가 다시 그려지는 중이니까요.
최근에 꽤 재미있게 본 "AI가 코딩 다 하는데 왜 배워요?" 에 대한 하버드 세션을 공유합니다. >> 1편, 2편
거시적으로는 이 책이 말하는 바와 꽤 닮아 있다고 느꼈습니다.
추가로 Velog 에서도 아주 감명깊게 읽었던 테오님의 AI 시대의 개발자: 현업 개발자의 솔직한 이야기 도 같이 붙여봅니다!
이 책은 “미래 예언서”가 아니라 “정체성의 정의서”에 가깝다!
책 자체는 자서전을 포함한 에세이에 매우 가깝습니다. 처음에는 솔직히 “내가 말이야~ 수십 년을 했는데~ 미래는 이래~” 같은 류의 에세이라고 짐작했습니다. 그런데 실제로는 반대에 가까웠습니다. 이 책은 프로그래밍/컴퓨터 영역에서 ‘사실’과 ‘계보’를 쌓는 데 유난히 집요합니다.
그리고 그 사실들의 누적이 결국 1장(그리고 후반부 20장)에서 나오는 “미래에 대한 태도”를 떠받치는 근거가 됩니다. 저는 이 구조가 매우 설득력 있게 다가왔습니다. “내가 이렇게 생각한다”가 아니라, “내가 이런 사실들을 지나왔고, 그래서 이런 결론에 닿았는데, 당신은 이 사실들을 보고 무엇을 그리겠는가” 쪽에 더 가깝게 읽혔습니다.
근데 좀 의아한 건 AI에 대해 생각보다 많이 냉소적으로 평가했다는 점
좀 더 찾아보니 책의 초안이 2023년 말 ~ 2024년 사이에 작성되었다고 하네요. 놀랍게 여기에 대해 리서치를 좀 해보니 같은 의문을 가진 사람이 리서치 내용을 요약한게 있습니다! (클릭)
책 소개에서는 각 부를 아래와 같이 설명합니다.
1부에서 우리의 정체성을 되짚고,
2부에서 거장들의 길을 따라가며,
3부에서 저자의 경험을 통해 전환점을 마주하고,
4부에서 우리가 맞이할 미래를 바라본다.
저도 이 흐름에 거의 동의합니다. 특히 1부/2부가 책의 절반 이상을 차지하는 이유는, ‘미래’보다 ‘뿌리’를 보여주기 위해서라고 느꼈습니다. 개발자라는 역할의 시발점, 존재 가치, 정체성. 전쟁과 알고리즘, 루틴과 서브루틴, 추상화의 탄생 같은 이야기들이 여기서 살아납니다.
읽는 내내 대학 1학년 때 배웠던 개론 수업의 기억도 자꾸 떠올랐습니다. 저는 오히려 그때보다 한참 뒤에 개론을 더 깊게 찾아보고 공부했습니다. 그리고 C를 제대로 배울 때(재수강했을 때), 포인터와 주소, 메모리, 컴퓨터 구조, 운영체제의 가상 메모리가 하나로 맞물리며 머릿속에서 “번쩍”하던 순간—마냥 어렵기만 했던 공학적 지식이 실제 코딩 경험과 함께 퍼즐처럼 맞춰지던 순간을 아직도 잊기 어렵습니다. 비록 그 코드가 단순 출력 함수 호출이었더라도요.
그리고 지금은, 언어를 “학습해서 사용”하는 건 이미 너무 쉬워진 세상입니다. 그래서 모두가 학습의 재정의, 일의 재정의를 이야기합니다. 저 역시 1년 전과 비교하면 일을 처리하는 방식이 하늘과 땅 차이입니다.
그럼 순수 작업 시간이 줄었는가? 솔직히 꼭 그렇진 않습니다. 다만 단위 시간에 처리할 수 있는 일의 양이 체감상 5배 이상 늘었고, 퀄리티가 떨어졌다고 느끼지도 않습니다. 저는 여전히 ‘바이브 코딩’을 하진 않습니다. (솔직히 한 끗 차이긴 합니다. 그런데 그 한 끗이 진짜 큰 차이를 만든다고 믿습니다.)
바이브 코딩과 LLM에 대한 대규모 서베이, 논문 리뷰 와 켄트 벡(Kent Beck) 형님과 함께하는 Augmented Coding, "증강 코딩" 글 참조
체감적으로, 예전에는 [설계 & 문서화 & 구현(테스팅/코딩)/리팩터링] 의 비중이 대략 3, 3, 4 정도였다면, 지금은 6, 3, 1 정도로 바뀌었습니다. 그리고 “코딩 & 리팩터링”은 무조건 diff(view diff)로 달라진 부분 위주로 끝까지 눈으로 최종 검토 합니다. 저는 이 변화가 “AI가 코딩을 대신해 준다”의 결론이라기보다, 사람이 책임져야 하는 지점이 더 선명해지는 방향 이라고 느낍니다.
2부의 거장 파트는 디지털 논리 회로와 컴퓨터 구조에 대한 기본적인 이해—적어도 진공관, 레지스터, 플립플롭에 대한 최소한의 감각—이 없으면 솔직히 지루할 수도 있습니다. 그런데 저자가 풀어내는 방식은, 이해가 부족해도 몰입할 수 있을 만큼 ‘이야기’로 설계되어 있다고 느꼈습니다. (그리고 그 몰입이 결국, “지금 우리가 쓰는 추상화들이 어디서 왔는지”를 체감하게 만듭니다.)
3부는 엉클 밥이 살아온 환경에서 컴퓨터와 프로그래밍이 얼마나 폭발적으로 성장했는지를 보여줍니다. 자연스럽게 개론과 저자의 배경 위로 올라타게 되고, 정말 거시적인 관점에서 “미래가 어떻게 될지”(정확히는 저자가 어떤 미래를 상정하는지)가 어렴풋이 보이기 시작합니다.
저도 변화의 흐름이 파도처럼 거대하다고 느끼지만, 90년대 태생인 제가 체감하는 변화조차 엉클 밥 같은 형님이 눈앞에서 겪었던 변화의 결에 비하면 “생각보다 빠른 게 아닐 수도 있겠다”는 상대화가 되기도 했습니다.
그리고 4부에서 책은 덤덤하게 마무리합니다. 과장된 예언 대신, “프로그래밍의 핵은 생각보다 잘 안 바뀐다”는 태도에 가깝게요. 다만 그 덤덤함이 체념은 아니었습니다.
목차별 리뷰
1부. 서막을 열며
1장. 우리는 누구인가?
1장의 기능은 “정의”다. 프로그래머를 ‘문제를 해결하는 사람’으로만 두지 않고, 디테일을 사랑하고 조합하여 의미를 만드는 사람으로 다시 규정한다. 이 규정은 기술 스택의 변화(언어/프레임워크/플랫폼)를 뛰어넘어, 직업적 정체성의 코어를 고정시키는 문장처럼 작동한다.
“디테일”이라는 단어가 AI 시대에 더 도발적으로 들리는 이유는, 생성형 AI가 바로 그 디테일(코드/문장/구현)을 대량 생산하기 시작했기 때문이다. 그러나 여러 서평이 공통으로 붙드는 축은 "산출물"이 아니라 "책임"이다.
내가 느낀 1장의 정의는 “AI가 대체할 것/못할 것”을 나누는 얄팍한 직업 전망이 아니라, AI와 함께 일할 때 무엇을 끝까지 붙들 것인가를 묻는 선언에 가까웠다.
PS. 사실 1장이 책에서 하고 싶은 말을 다 담고 있다는 걸, 다 읽고 다시 깨닫게 되었다.
2부. 거장
2장. 배비지, 최초의 컴퓨터 엔지니어
“명령어(카드)와 데이터(숫자계기)의 분리”라는 감각은, 오늘날 관점에서 보면 너무 당연해 보이지만, 당시에는 “계산을 하는 장치”를 “계산을 기술하는 장치”로 끌어올리는 발상이었다.
배비지 장에서 인상적인 것은, 천재성보다도 실패의 형태다. 차분기관이 “실패했다”는 사실보다, 실패가 남긴 유산(레지스터적 사고, 반복 가능한 연산 단위, 표준화된 절차)이 더 중요하다.
3장. 힐베르트, 튜링, 그리고 폰 노이만: 최초의 컴퓨터 아키텍트
3장에선 힐베르트의 아래 3가지가 주요 내용이었다.
- 힐베르트의 공리화 시도 → (괴델) 불완전성의 충격
- 그 흐름이 “증명=알고리즘(절차)”로 이어진다는 통찰
- 그 다음, 계산 장치의 설계 철학(내장식 컴퓨터)로 연결
1) 수학의 충격(형식체계의 한계)
- “수학 전체를 공리화”하려는 열망과 그 좌절은, ‘인간이 완전한 체계를 만들 수 있다’는 낙관의 붕괴로 읽힌다.
- 하지만 “폰 노이만이 자연수는 러셀의 역설에 해당하지 않는다” 는 서포팅도 있었다.
2) 계산의 정의(Computability)
- 배비지 해석기관이 명령어(나무카드 구멍), 데이터(회전식 숫자계기) 완전 분리된 방식이 포인트였고, 이를 튜링이 해당 사고를 확장했다. 튜링머신이 제공한 것은, ‘컴퓨터’가 아니라 “무엇이 계산 가능한가”에 대한 정의였다.
- 계산 가능성을 엄밀히 정의할수록, “계산 불가능한 것(혹은 계산 비용이 과도한 것)”이 더 선명하게 남는다.
PS. 독일에서 폰(von) 귀족 칭호라고 한다.
- 위 그림은 튜링 머신의 계산 방식을 도식화 한 그림이다. 책에서는 전혀 다른 표를 활용한다.
- 서브루틴(재사용) 개념과 상태 전이의 압축(표를 다 들고 있지 않아도 되는 방식)
- SD(표준 기술)로 “프로그램을 숫자/기호로 표현”
- 그 SD를 테이프에 담아 실행하는 U(범용 기계)
이 흐름은, 오늘날 관점에서 “해석기/컴파일러/VM/런타임”으로 계속 환생한다.
다익스트라 장에서 언급한 P-코드와 런타임(가상 머신과 닮음)까지 연결하면, 2부의 거장들은 서로 떨어져 있지 않다. 같은 아이디어가 다른 언어로 재등장한다.
더욱이 "존 폰 노이만이 작성" 이 작성한 EDVAC(에드박) 설계 초안, [ 입력, 출력, 연산, 제어, 기억 장치 ] 구성 요소 다섯개, 오늘날까지 사용하는 내장식 컴퓨터 기초가 된다.
PS. 여기서 전쟁에 대한 얘기, 탄도연구소를 넘어 맨해튼 프로젝트 (오펜하이머 영화 ㅎㅎ), 마크 I 와 ENIAC(에니악)을 경험. 트리니티 프로젝트에 대한 얘기가 나온다.
4장. 그레이스 호퍼: 최초의 소프트웨어 엔지니어
개발자라면 누구나 겪어본 그것! '버그'를 발견한 최초의 프로그래머, 그레이스호퍼
주석, 서브루틴, 멀티프로세싱, 개발 방법론, 디버깅, 컴파일러, 오픈 소스, 사용자 계정 및 그룹, 주소, 이진수, 비트, 어셈블러, 브레이크포인트, 문자, 코드, 디버그, 편집... 이 모든 개념에 그레이스 호퍼의 노력이 묻어있다고 한다.
호퍼가 밀어붙인 것은 “추상적 언어 → 자동 변환(컴파일)”이었다. 여기서 핵심은 기술이 아니라 사회적 합의다. 당시에도 “천공판 구멍 뚫는 사람 다 어디감?” 같은 공포가 등장했고, 그 공포는 단순히 무지의 산물이 아니라 생계의 문제였다.
그런데도 호퍼의 방향은 분명하다.
- 더 읽기 쉽고 쓰기 쉬운 표현
- 더 많은 사람이 협업 가능한 언어
- 기계어로 내려가는 과정을 자동화
AI가 코드를 만든다는 말이 결국 “더 높은 추상화로 올라간다”는 말이라면, 호퍼의 자동 프로그래밍은 전례라고 볼 수 도 있다. 개인적인 견해로 그레이스 호퍼 얘기를 굳이 현 시대의 AI 확장에 대한 해석을 붙이자면, 나는 아래 2개가 중요하다 이해되었다.
- (일부 역할은 줄거나 바뀌지만) 전체 산업의 총량은 오히려 커진다.
- 문제는 기술이 아니라, 전환을 관리하는 사회적/교육적 장치다.
그녀는 해군에 입대했으며, 그 경험이 그녀를 ‘진정한 소프트웨어 엔지니어’의 길로 이끌었다. 처음에는 암호 해독 업무를 하게 될 것이라 예상했지만, 결과적으로 세계에서 두 번째 컴퓨터로 알려진 자동 순차 제어 계산기(ASCC, Mark I의 다른 이름)에서 부책임자이자 세 번째 프로그래머로 일하게 된다.
Who Invented the Mark I Computer?
베티 스나이더의 사례도 흥미롭다. 정렬은 ‘매개변수’에 따라 동작했다. 여러 레코드를 정렬하려면 정렬 기준이 되는 필드의 위치, 크기, 정렬 방향 같은 정보가 필요하고, 이 매개변수를 입력받아 레코드를 정렬하는 방식으로 일종의 “프로그램 생성”이 가능했던 셈이다.
그리고 핵심은, 호퍼가 그 무렵 ACM 논문을 통해 “자동 프로그래밍”을 언급했다는 점이다. 그러자 곧바로 “천공판 구멍 뚫는 사람 다 어디감?” 같은 두려움이 따라붙는다. 다만 이 변화는 대체(replace)라기보다 완화(relieve)에 가까웠다는 맥락으로 읽힌다. A형 컴파일러가 등장하고, 프로그래머의 일자리를 빼앗을지 모른다는 공포가 생기면서도 A-1, A-2 개발이 가속화되고, 이어 A-3(일명 B형 컴파일러)로 이어진다. MATH-MATIC 언어도 그 흐름 안에 있다.
또 한 가지 인상적인 지점은 표현 방식의 선택이다. 호퍼는 A × B = C 같은 수학적 표기 대신, 비즈니스와 더 일반적인 대중을 위해서는 아래처럼 문장형 표현이 선호될 수 있다고 판단한 것으로 정리된다.
MULTIPLY BASE-PRICE AND DISCOUNT-PERCENT GIVING DISCOUNT-PRICE
이러한 맥락에서 영어 기반 언어인 B-0 개발로 이어지고, “추상적인 언어가 프로그래머들이 훨씬 자유롭게 협업할 수 있게 해준다”는 관점이 강조된다. 그리고 COmmon Business-Oriented Language, 즉 코볼(COBOL)의 탄생으로 연결된다. (놀랍게 아직도 살아 있다. 전 세계 금융 트랜잭션의 약 70~80%가 코볼로 작성된 시스템을 거치는 것으로 추정)
5장. 존 배커스: 첫 번째 고수준 언어
하이파이 오디오에 빠져 있던 시절, 훌륭한 스승을 만나 수학으로 방향을 틀었다. 이후 IBM 시설을 구경하던 중 SSEC 프로그래머로 취업했고, 이 일을 계기로 본격적으로 프로그래밍의 세계로 들어간다.
한국 전쟁 시기, IBM의 군수 컴퓨팅 맥락에서 IBM 701이 등장한다. 배커스가 SSEC 다음으로 마주한 대상이 바로 이것이었다. 완전한 전자식 컴퓨터였고, 진공관이 약 4천 개 들어갔다.
현대와 달리 IBM 701에서는 반복문이나 배열 순회를 구현하려면 명령어 자체를 바꾸는 기법이 필요했다. 입력 처리까지 포함해 전반적으로 번거로운 작업이 많았는데, 배커스는 이를 줄이기 위해 “스피드코딩(Speedcoding)”이라는 프로그램을 만든다.
본인 표현으로는 “게으름 때문”이었다고 한다. 부동소수점 연산을 지원하는, 일종의 인터프리터에 가까운 도구였고, 인덱스 레지스터 증가 또는 감소 작업 수행, 간접 주소 지정 같은 기능도 제공했다. 한때 A-0 컴파일러를 폄하하기도 했고, 이후 FORmula TRANslation—포트란(Fortran)이라는 이름의 “예비 보고서”로 이어진다.
6장. 에츠허르 다익스트라: 첫 번째 컴퓨터 과학자
GOTO문을 쓰지 말자고 강조한 인물 중 하나다. 세마포어 개념을 처음 고안했고, 여러 유명 알고리즘을 만들었으며, ALGOL 60 컴파일러 최초 버전 공동 개발 등으로도 알려져 있다. 네덜란드 로테르담 출신. 초반에는 프로그래밍 자체보다 이론 물리학자로 성장하려 했지만, 빈가르덴의 영향이 인생의 전환점이 된다.
다익스트라는 “호출 가능한 서브루틴”의 장점을 분명히 본 사람이다. 제어 흐름이 동일한 명령어 집합을 한 번만 정의해 두고 필요할 때 실행할 수 있다면 얼마나 좋은가를 언급했고, 호퍼식의 “명령어 중복” 방식은 비효율적이며 메모리 낭비라고 봤다.
다익스트라 알고리즘은 최단 경로 알고리즘이다. (요즘은 모르겠지만, 나의 시대에는 꽤 단골 문제였다.) 한 지점에서 다른 특정 지점(혹은 모든 다른 지점)까지의 최단 경로를 구한다. “로테르담에서 흐로닝언까지 가장 짧은 길을 어떻게 찾지?” 같은 질문에서 출발해 설계한 알고리즘으로, 20분 만에 아이디어를 떠올렸고 논문 완성까지는 3년이 걸렸다고 한다.
너무 TMI지만, 나는 이 내용이 유독 기억에 남는다. 네덜란드에 교환학생 경험이 있었고, 사실 나는 네덜란드를 굉장히 IT 친화적으로 생각했다.(python..) 그리고 헤이그에 있으면서 로테르담, 흐로닝언까지 자전거를 타고 다닌 적이 있기 때문이다 ㅎ
하여튼, 이 알고리즘을 기반으로 ARMAC의 성능을 보여주려고 했었다. 그런데 이 코드를 포인터 없이, 재귀 없이, 심지어 서브루틴 호출 명령어조차 없이 작성해야 했다. 각 명령어의 내부 주소를 직접 수정해야 했고, 드럼 메모리와 코어 버퍼 사이에서 데이터가 밀리거나 덮어쓰이지 않도록 최적화도 직접 해야 했다. 아찔한 제약이다.
심지어 차기 컴퓨터 X1의 뒷판 구리 회로가 비싸서, 구리 배선을 최적화하기 위한 “MST(최소 신장 트리)” 알고리즘까지 활용했다.
다익스트라와 존테벨트는 언어와 기계 사이에 추상화 경계(abstraction boundary)를 만들어, 당시 다른 팀보다 앞서나갈 수 있었다. 컴파일러가 ALGOL을 P코드(포터블 코드)로 내리고, 별도의 런타임이 이를 해석해 실행하는 구조였는데, 이 런타임은 오늘날의 가상 머신(VM)과도 닮아 있다.
이후 멀티프로그래밍 시스템 프로젝트를 시작한다. 당시로서는 매우 독창적이었다. 이를 위해 HW level에서 상위 계층이 하위 계층의 복잡한 내부 동작을 알거나 의존하지 못하도록 만들었다. 그리고 여기서 세마포어가 등장한다. 동시 실행되는 프로세스들이 공유 자원을 업데이트할 때 생기는 race condition을 다루는 방법이다. 이 과정에서 “임계 구역(critical section)”과 “불가분 연산(indivisible action)” 같은 용어도 도입된다.
나아가 다익스트라 팀은 해당 시스템의 정확성을 “수학적으로 증명했다”고 믿었다. 「프로그램의 신뢰성에 대하여」 같은 글에서 “프로그래밍은 점점 더 수학적인 활동이 될 것이다”라고 주장하기도 했는데, 저자 관점에서는 이것이 오판이라고 본다.
본질적으로 수학 OK, 두 분야의 접점도 당연히 OK다. 그런데 문제는 “증명”으로 접근했다는 점이다. 그리고 소프트웨어가 그 증명으로 이루어진 수학적 시스템이 되리라 생각했던 것 같다. 지금 보면, 누구도 위와 같은 수학적 증명을 실제 개발에서 하지는 않는다. 소프트웨어 세계의 ‘기하학 원론’은 없고, 앞으로도 없을 것이다. 저자는 소프트웨어가 수학이라기보다 과학에 가깝다고 보기 때문이다. 과학은 어떤 이론이 “옳다”를 증명하는 접근이 아니라, 그 이론이 틀렸다는 것을 관찰할 수 있는가에 가깝다. 소프트웨어를 만들면 “잘 설계된 테스트를 통해 프로그램이 잘못되었는지 관찰하고 오류를 찾아낸다”는 방식이다.
그리고 다익스트라의 “구조적 프로그래밍”이 이어진다. GOTO문에 반대하는 논거를 발표했고, 시장에 파장을 일으켰다. (네, Verilog 하시는 분들은 여전히 GOTO를 볼 수 있습니다.) 순차, 선택, 반복 세 가지만으로 프로그램을 구성하자고 제안한다. 왜 이런 구조인가? → 수학적 증명을 하지 않아도, 코드 자체가 “증명 가능”하도록 만들기 위해서다. 단순히 GOTO를 없앤 것 이상으로, 만들어낸 가치는 크다고 본다. 아키텍처 관점까지도.
7장. 니가드와 달: 첫 번째 OOPL && 8장. 존 케메니: 모두를 위한 첫 번째 언어, BASIC
니가드와 달은 "객체 지향의 발전" 얘기다. SIMULA 67 와 같은 최초 객체 지향 프로그래밍(Object-Oriented Programming Language)이 등장했고 이는 C++ 창시자에게도 영향을 줬다.
더욱이 클래스와 서브클래스 선언 논문 발표하며 "처음으로 객체 용어" 사용 했다.
존 케메니 얘기는 누구나 프로그래밍 영역 접근 할 수 있어야 한다고 믿었던 프로그래머들의 여정에 대한 얘기다. 하지만 자기 천재성에 스스로 눈과 귀 닫아버린 이들의 이야기이기도 하다.
그리고 폰 노이만의 First Draft of a Report on the EDVAC 비공식 문서 보고 엄청 큰 깨달음 얻었다고 한다.
"타임셰어링 혁명" 을 만들었지만 시장에서 고집으로 인해 역사속으로 사라졌다.
9장. 주디스 앨런 && 10장. 톰프슨, 리치, 커니핸
위 2장은 직접 책에서 보길 바란다. 특히 10장의 C언어 얘기, 독자들이 꽤 시대적 흐름으로 더 많은 동감을 할 수 있지 않을까 생각한다.
3부. 급격한 전환점
1970년대부터 2020년까지 얼마나 폭발적으로 성장했는지!
11장. 1960년대
"반(反)문화의 시기" 라고 정의한다. 어릴 때 Digi-Comp I 기계를 가지고 놀며 플립플롭을 “장난감”처럼 다뤘는데, 그걸 제대로 쓰려면 결국 매뉴얼을 공부해야 했다. 그 경험을 바탕으로 릴레이 장치로 더 다양한 시도를 해보고, 트랜지스터·저항기·커패시터 같은 부품을 직접 배우고 만들고 조립해 본 기억이 이어진다.
고등학교에서는 ECP-18을 통해 전자식 컴퓨터 세계를 처음 제대로 경험했고, 이때 첫 프로그래밍 시도가 나온다.
12장. 1970년대
16세에 프로그래머로 일을 시작했다. EASYCODER 책과 함께 허니웰 H200 시리즈용 어셈블리 언어를 다루며, 펀치 카드 더미를 실제로 겪는다. 이후에는 프로그래머 애널리스트 경험도 하고, 대형 미니컴퓨터 프로젝트에 참여했으며, 컴퓨터로 제어되는 레이저 절삭 시스템까지 경험한다.
특히 이 시기에는 여유 시간이 있어 팀과 “방식”에 대한 깊은 논의가 가능했다고 한다.
정렬 알고리즘, 탐색 알고리즘, 인덱싱 방식, 큐잉 방식 등
이직 후에는 System/7을 위한 어셈블리 경험을 하고, 그러던 중 “구조적 프로그래밍 (다익스트라)”의 "GOTO 가 해롭다는" 글을 보고 충격을 받는다. System/7에 곧바로 적용하면서 받아들였다고 한다 ㅎ.
"서브루틴은 좋은 것이지만, 모듈 사이를 마구 뛰어다니는 점프는 나쁘다"
이 구분에 완전히 매료된다. 그리고 이에 대한 글을 쓰고, 인생 첫 출장 비행을 하고, 프로그래머 그룹을 처음으로 교육하는 경험도 한다.
그러다 해고를 당하고 TAS로 돌아간다. 일종의 스타트업 같은 곳이었다. 개인을 갈아 넣으며 돌아가는 시스템. 많은 프로젝트, 많은 경험, 압도적으로 많은 코드 경험이 쌓인다. 후반부로 갈수록 컴퓨팅 능력 자체가 커지면서 시장도 더 빠르고 크게 성장한다.
13장. 1980년대
벨 텔레콤과 미팅 기회가 생겨서 “MLT 엔지니어는 어떤 언어를 쓰냐?”라는 질문에 돌아온 답은 "당연히 C였다." 거기에 꽂혔다. 바로 책을 사서 읽었고, 빠져들어 “C 컴파일러를 반드시 구해야 한다”는 생각까지 하게 된다.
회사에서는 시스템 관리자가 된다. 80년대 전화 회사들의 디지털 혁명 배경에는 구리 가격 상승이 있었다. 엄청난 양의 구리선을 회수하고 싶었고, 오래된 릴레이식 스위치를 디지털 스위치로 교체하는 대대적인 아키텍처 변화가 진행된다. 이 과정에서 C와 BOSS를 적극적으로 사용한다.
수년간 몰두하게 만드는 거대한 프로젝트도 이어진다. (E.R. 특허/프로젝트 등)
그리고 애플 II가 등장한다. 회사 사무실에 개인용 컴퓨터가 들어오고, 스프레드시트가 실제 업무 도구가 된다. 이어지는 매킨토시까지. 흥미로운 점은, 이 시기에 폭포수 프로세스가 아니라 특별한 제약 없이 칸반을 이용해 개발했다는 대목이다.
E.R 프로젝트는 H/W, N/W까지 포함해 밑바닥부터 만들었지만 시대 흐름과 맞지 않았던 것 같다고 한다. 프로젝트와 특허는 모두 무산. 개인용 컴퓨터 보급이 본격화된다. 이후 GUI와 개인용 서비스 몇 가지(wator 등) 개발, 그리고 객체 지향에도 도전한다.
14장. 1990년대
시장의 낙관적인 전망과 빠른 성장이 이어지며 “성장”이 눈에 보이던 시대. 동시에 세계 전쟁, 테러 사건 같은 균열도 함께 있었다. 닷컴 버블로 절정까지 치닫는다.
스타트업 경험, 인터넷 경험, 온라인 세상의 체감이 깊어진다. 선 마이크로시스템스에서 C++ 컴파일러가 등장하고, 유즈넷/뉴스그룹에 가입해 폭발적인 성장의 공기를 직접 겪는다. 저자가 감명 깊게 본 그래디 부치의 <Object Oriented Design with Applications>도 나온다. (불확실한 정보지만 아직 대학교 강의 교재처럼 쓰는 곳이 있는 것 같기도 하다.)
회사는 사업적으로 어려웠지만 경력은 오히려 상승 곡선을 탄다. 뉴스그룹 활동이 주목을 받으며 글 투고를 시작한다. 그러다 헤드헌터에게 전화가 온다(래셔널 와라!). 인하우스로 가는 대신 역으로 컨설턴트를 제안했고, 그 제안이 받아들여진다. 이후 이것이 싹이 되어 프로그래밍 컨설팅 역량을 펼친다. 그중 비네트 프로젝트를 통해 “재사용 가능한 프레임워크”의 성공과 실패를 모두 경험한다.
또한 GOF(Gang of Four)의 <Design Patterns> 책 온라인 리뷰어 경험도 있다. (이 책은 언제 대체재가 나오려나ㅎㅎ.)
현 시대의 거장들 얘기가 갑자기 확확 와닿았다. 그들도 르네상스처럼 일종의 그들만의 "장" 이 있었고 그 "장"을 만들고 이어온게, 이게 정말 중요한게 아닐까 싶기도 하다.
또 저자는 켄트 벡의 XP에 큰 감명을 받아서 직접 만나 이야기한다. 이를 교육과 컨설팅으로 확장한다. TDD를 처음 경험하고 보고 느끼며 충격을 먹는다. 완전히 새로운 코딩 방법이었다고 한다.
PS. TDD는 나에게도 너무 혁명이었다. 물론 저자와 상황과 시대도 달랐었지만, 진짜로 TDD를 프로젝트에 적용했을때 그 새로움, 특히 신규 feature를 추가할때 그 쾌락을 잊을 수 가 없다.
15장. 밀레니엄
불확실성과 침체가 함께 온 시기. 9.11, 전쟁, 2008년 글로벌 금융 위기 등.
그럼에도 XP 교육과 컨설팅은 한동안 호황이었다고 한다. 소프트웨어 전문가 17명이 모여 애자일 선언문(아직 살아있다!! - https://agilemanifesto.org/iso/ko/manifesto.html)을 작성했고, 이것이 큰 파도를 일으켰다고 한다. 그러는 와중에 9.11, 그리고 2001년부터 닷컴 버블 붕괴가 시작된다.
이후 2년간 수요 감소와 침체가 이어지고, 오히려 책을 집필할 수 있었다고 한다. 이때 나온 것이 <Agile Software Development, Principles, Patterns, and Practices> 출간. 그리고 이후 <Clean Code> 집필로 이어진다.
PS. 사견으로 이 두 권이야말로 아직까지 전 세계 개발자에게 로버트 C. 마틴 “엉클밥”을 알리게 만든 결정적 계기가 아니었나 싶다.
그리고 이후에는 SICP를 기반으로 함수형 프로그래밍의 매력에 빠졌다고 한다. 생각보다 현 시대, 동시대의 거장들이 함수형 프로그래밍을 “매우 맛있게” 표현하는 경우가 있는데, 내가 느끼기엔 이게 약간 예술의 경지가 아닐까 한다.
4부. 미래
16장. 프로그래밍 언어
요즘 프로그래밍 언어 진짜 개많다. 왜 그렇게 많을까? 정말 그렇게 다양할 필요가 있을까? Java, C#, 거시적으로 객관적으로 보면 사실상 거의 동일해 보이기도 한다. 사실 우리가 “모든 것을 지배할 단 하나의 언어”, “성배 같은 언어”를 끊임없이 찾아서 그런 거 아닐까?
저자는 과거에 비해 새언어가 주는 depth 있는 메커니즘 차이가 거의 없는 것처럼 느껴진다고 한다. 그래서 이 상황을 성경 전도서의 “이미 있던 것이 다시 있을 뿐. 태양 아래 새로운 것이 없도다”에 비유하게 된다.
사실 컴퓨터 분야에서만 그런 게 아니라 다른 산업 분야에서도 비슷한 일이 반복되어 왔다. 단 하나의 언어만 남기자고 사회적 협의가 될 수도 있지 않을까? 이러면 모두가 편해질 텐데…
PS. ‘새로움’이 사라졌다기보다 새로움의 무대가 런타임/생태계/운영 비용으로 옮겨 간 것 같기도 하다. 물론 이 새로움이 저자가 원하는 니즈를 충족시키진 못할 것 같다.
PS. 근데 이제 실제로 LLM이라는 것을 “언어” 관점으로 본다면, 하나로 합일화 되고 있는 것 같기도 하다. 다만 전혀 다른 방식이긴 하지만… 이 경우의 합일화는 “프로그래밍 언어가 하나로 통일된다”기보다, 입력 방식(자연어 프롬프트) 이 통일되는 쪽에 가까워 보인다.
타입에 대한 것도, 컴파일에 타입을 검사할까, 런타임에 검사할까? 수십 년째 줄다리기. 정적 언어는 퍼즐처럼 제자리에 다 끼워야 해서 귀찮고 어려운 언어, 동적 언어는 이 단점을 상쇄하지만 그만큼 잘못 끼울 위험이 있는 것이다.
저자는 두 가지를 절충해서 "타입 검사를 형식적으로 엄격하게 하되, 런타임으로 미루자고 제안함. 그리고 언제 적용할지 프로그래머가 선택할 수 있게" 하자고 제안한다.
저자는 언어를 합일화 한다고 하면 리스프 계열 언어가 남는다고 생각한다. (매우 의외)
1) 대부분 극도로 단순함. 요즘 유행하는 언어들이 좀 과하게 문법이 방대하다고 생각함. 그래서 트릭과 기교까지 배워야 한다는 점.
2) 단순하기 때문에 생기는 표현력. 언어 제약에서 벗어나 내가 표현하고 싶은 것을 표현할 수 있게 됨.
3) 리스프는 프로그래밍 언어보다는 데이터를 표현하는 언어에 가까움. 여기에 데이터가 프로그램처럼 해석될 수 있도록 하는 런타임이 결합되어 있는 것.
이 리스프 얘기의 핵심은 결국 “단순함” 자체보다, 코드=데이터(code-as-data) 감각에 있는 것 같다. Clojure 가 리스프를 설명할 때도, 코드-데이터와 매크로 시스템이 리스프 계열을 구분 짓는 특징이라고 정면으로 말한다.
그리고 “폰 노이만 아키텍처 같다”는 비유는, 저장 프로그램 개념(명령과 데이터가 같은 저장소에 있고, 프로그램이 데이터처럼 취급될 수 있음)을 떠올리게 한다는 점에서 의미가 있다. 실제로 Britannica도 폰 노이만 머신의 원리 중 하나로 “데이터와 명령을 한 저장소에 두고, 프로그램을 데이터로 취급할 수 있다”는 점을 강조해왔다.
17장. AI
미래학자들이 우리 모두가 AI 혁명 벼랑 끝에 서 있다고 말한다. 하지만 저자는 이 기술들이 초자연적인 무언가이거나, 인간의 지능이나 창의력에 조금이라도 근접하게 될 것이라고는 보지 않는다.
그 근거로 저자는 인간의 뇌 구조와 뉴런을 꺼내 든다. 뉴런이 얼마나 강력한 계산 단위이며, 뉴런 간 연결(시냅스)의 규모가 얼마나 압도적인지 이야기하면서, “스카이넷” 같은 도약은 쉽게 오지 않을 것이라고 선을 긋는다.
실제로 인간 뇌의 뉴런 수와 시냅스 연결 수에 대한 대표적 추정치만 보아도, 규모 면에서 아직은 우리가 ‘비슷한 것’을 만든다고 말하기 어려운 구간이 있다는 느낌을 준다(뉴런 약 860억, 시냅스 약 100조 수준의 추정 등).
이어서 “신경망(Neural Nets)”으로 넘어간다. 아마 LLM을 포함한 현대 AI의 핵심을 설명하기 위한 길목이다.
여기서 포인트는 분명하다. 여전히 블랙박스이며, 가중치는 미리 예측할 수 없고, 결과값이 “어떤 공식”으로 딱 떨어지게 정해지는 것도 아니라는 것. 즉, 입력을 넣고 출력에서 원하는 것이 나오기를 “기도하듯” 바라는 상태가 생길 수 있다는 말이다. 이 문제의식은 오늘날 XAI(Explainable AI) 논의가 왜 반복되는지와도 맞닿아 있다. 딥러닝 모델은 성능이 뛰어나더라도 내부 작동을 설명하기 어렵다는 이유로 “블랙박스”로 불려 왔고, 그래서 ‘설명 가능성’이 별도의 연구 축이 되어 왔다.
저자는 “학습을 다시 시켜서 더 나아지기를 바라는 것”을 운에 맡기는 전략과 비슷하다고 본다. 그리고 신경망을 만드는 일을 소프트웨어 엔지니어링보다는 “현수교를 만드는 것에 가깝다”고 평가한다.
그런데 저자는 여기서 한 번 더 꺾는다. 신경망은 SW 없이 존재할 수 없고, 이를 둘러싼 도구와 인프라는 소프트웨어가 깊이 관여할 수밖에 없다. 다만, 그 소프트웨어는 운에 맡기는 게 아니다. 프로그래머가 다루는 본질은 여전히 결정론적 결과물이며, 애매한 희망이 아니라 확실한 이진적 사실을 다룬다는 것.
이 주장이 장 전체를 관통하는 “태도”처럼 남는다. AI가 불확실하다는 말이 곧 프로그래밍 자체가 불확실해진다는 뜻은 아니다. 오히려 불확실한 블록을 끼워 넣을수록, 주변의 결정론적 장치(검증·테스트·제약·관측)가 더 중요해진다는 뉘앙스로 읽혔다.
이 장에서 저자가 특히 강조하는 또 하나는, LLM이 현시대 “신경망의 걸작”처럼 보이더라도 지능적·창의적으로 보이는 순간들이 곧장 ‘창의성’의 증거는 아니라는 점이다.
그리고 아주 단적으로 GIGO(garbage in, garbage out) 를 떠올리게 하는 예시(학습 데이터가 범죄적이면 출력도 범죄적으로 기울 수 있음)를 통해, 결국 모델이 무엇을 반사(reflect)하는지 다시 보게 한다.
PS. 출력 품질은 곧 입력 품질(데이터·프롬프트·컨텍스트·정책)의 그림자다. 그러니 책임도 결국 ‘모델 바깥’에 남는다.
그리고 저자는 LLM을 활용해 얻어낸 코드를 직접 리뷰하면서 그 출력물을 신랄하게 비판한다. 여기서는 웃음이 나왔다ㅋㅎㅋㅎㅋㅎ. “코드는 나왔지만, 설계가 없다”는 느낌. 즉, 그럴듯한 구현은 쉽게 생성되지만, 요구사항의 모서리·예외·장기 유지보수·실패 모드·테스트 전략 같은 디테일은 여전히 사람이 붙들어야 한다는 주장으로 이어진다. (이 부분이 가장 의아했는데, 위에서 언급했듯, 최근의 의견은 조금 달라진 듯 하다.)
LXM(X 자리에 Music, Art, Code 등). LXM은 결국 도구이며, C도 도구, IDE도 도구, 결국 사람이 이용해야 한다는 것. 이때 책은 “도구가 사람을 대체한다”는 공포가 역사적으로 반복되어 왔음을 상기시킨다.
초기 프로그래머들—바이너리 코드로 직접 프로그램을 짜던 사람들—이 그레이스 호퍼의 A-0 같은 컴파일러를 두려워했지만, 결과는 정반대였다는 이야기. 실제로 호퍼의 A-0 시스템은 1952년 무렵의 초기 컴파일러(혹은 컴파일러에 준하는 시스템)로 종종 언급되며, 이후 고수준 언어와 도구 생태계의 확장을 여는 흐름에 놓인다. 요지는 “대체”가 아니라 “확장”이다.
왜 지난 세월간 전 세계 프로그래머 수가 폭발적으로 증가했는가? 저자의 답은 간결하다. 컴퓨터를 활용할 수 있는 분야가 아직도 무궁무진하기 때문이다. 그리고 “그렇다면 인간의 어떤 점 때문에 LXM이 프로그래머들을 대체할 수 없을까?”라는 질문으로 다시 돌아온다. 저자는 결국 1부 1장 “우리는 누구인가?”에서의 답, 즉 디테일을 다시 꺼낸다. 불확실한 결과를 ‘쓸 수 있는 결과’로 바꾸는 일, 맥락을 정의하고 책임을 지는 일, 실패를 설계하고 복구를 설계하는 일—이 디테일이 있는 한, 도구는 사람의 자리를 빼앗기보다 사람의 능력을 증폭시키는 방향으로 진화한다는 것이다.
장 끝에서 남는 감정은 묘하게 담백하다. AI는 불가해하고, 그래서 더 조심스럽게 다뤄야 한다. 그러나 그 불가해함이 곧바로 “프로그래머의 종말”을 뜻하지는 않는다. 오히려 프로그래머의 일은 더 명확해진다. 불확실한 것을 시스템 안에 안전하게 배치하는 사람, 그 디테일을 책임지는 사람. 저자가 말하는 미래는 그 점에서 과장되지 않는다. 다만 그래서 더 현실적이다.
18장. 하드웨어 && 19장. 월드 와이드 웹 && 20장. 프로그래밍
저자는 월드 와이드 웹의 미래를 말하면서 “브라우저 같은 것이 사라진다”가 아니라, 브라우저가 ‘인식에서 사라질 것’ 이라고 본다. 이게 가장 인상 깊었다. 마치 지금 우리가 전화번호를 외우지 않고, 통신 인프라를 의식하지 않듯이, 웹도 특정한 형태(브라우저, 주소창, 탭)로 ‘보이는 것’이 아니라 서로 소통하는 프로그램들만 남고, 사용자는 그것을 웹이라고조차 부르지 않게 될 거라는 전망이다.
그렇다면 앞으로의 프로그래밍은 어떻게 바뀔까?
저자는 지난 50년을 되돌아보며 50년 후를 상상했을 때, 자신은 여전히 if, while, 대입문 같은 기본 구문을 쓰고, 컴파일하고, 테스트하고 있을 것 같다고 말한다. 이건 보수적인 선언이라기보다 “핵심은 생각보다 잘 안 바뀐다”는 쪽에 가깝다.
더 흥미로운 건, “근래의 세월에 소프트웨어 역사상 소프트웨어 원칙에 대한 눈에 띄는 발전은 거의 없었다”는 진단이다.
구조적/함수형/객체지향이라는 세 주요 패러다임은 이미 70년대에 등장했고, SOLID 같은 것이 이후에 널리 퍼졌지만, 그 밑바탕 자체는 이미 오래전에 확립되어 있었다는 말이다. 그래서 앞으로 50년 동안 무언가가 극적으로 뒤집힐 거라는 기대를 크게 하지 않는다. 이름이 바뀌고 포장이 달라질 수는 있어도, 본질은 비슷하게 남을 거라는 태도다.
대신 저자가 “진짜로” 기대하는 건 기술의 급진적 변화가 아니라, 프로그래밍 직군에 전문 윤리와 기준, 기법이 자리 잡는 것이다. 도구나 방법론이 늘어나는 것 못지않게, “직업 윤리 의식”이 필요하다는 주장인데, 나는 이 부분이 이 책 전체의 결론처럼 들렸다. 결국 프로그래머의 미래는 더 강력한 도구가 아니라, 더 강한 책임감과 기준에서 갈린다는 식으로.
개인적으로는 이후 집필 후기와 톰 길브의 소감이 정말 재미있었다. 조금 자극적인 농담도 섞여 있는데, 예컨대 “노인은 누군가 들어주는 사람이 있으면 자신의 이야기를 무척 좋아한다” 같은 문장이나, “이 책에 나오는 사람들은 이제 ‘원로’들이다”라는 식의 표현이 그렇다.
그 ‘원로’들의 지혜가 닿길 바라는 마음에서 이 책을 만진다는 말이, 어떤 면에서는 이 책의 가장 솔직한 동기처럼 느껴지기도 했다. 다익스트라가 자기 자신을 거만한 컨설턴트라고 적었다는 이야기나, 그레이스 호퍼 강연에서 감명 깊었던 포인트를 풀어놓는 대목도 그 연장선에서 읽히면서, 본문과는 다른 결로 웃게 만든다.
