Greatness Is Forged by Limitation
Can't believe I spent 2 weeks writing this. Last week, I gave a talk at a Cursor community event...
개요 #
Cursor 커뮤니티 행사에서 AI와 소프트웨어 개발 방식의 변화를 주제로 발표를 마친 개발자 Adam에게, 비개발자 한 명이 다가와 질문을 던졌다. "요즘 도구와 기술이 이렇게 많은데, 그중에서 뭘 골라야 할지 어떻게 판단하나요?" 질문한 사람은 선택지가 많으니 좋은 것들이 많이 나오길 기대한다는 말을 남기고 자리를 떠났다.
며칠 뒤 도서관에서 W. Richard Stevens의 *UNIX Network Programming*을 집어 든 순간, 그는 답을 찾았다고 말한다. 메모리도 연산 능력도 대역폭도 도구도 전부 부족했던 90년대 기술. 그런데 그 시절에서 UNIX와 TCP/IP, 초기 운영체제들, 그리고 지금도 쓰이는 가장 우아한 기술들이 나왔다.
여기서 그는 두 가지 질문을 던진다. 우리를 제약했던 것들이 오히려 우리를 더 나아지게 만든 요인이라면? 위대함은 더 많이 가져서가 아니라, 적은 것으로 더 많이 해내야 하는 상황에서 만들어지는 것이라면?
제약의 역설 #
우리는 보통 제약을 극복 대상으로 본다. 돈이 부족하고, 시간이 부족하고, 자원이 부족하고, 지식이 부족하다. 모두 목표와 나 사이를 가로막는 장애물이다.
그런데 제약에는 잘 이야기되지 않는 다른 면이 있다. 제약은 무언가를 빼앗는 데서 그치지 않고, 가능했을 수도 있는 것들까지 함께 지워버린다. 글쓴이는 바로 그게 필요한 부분일 수 있다고 본다.
모든 것이 가능하고 모든 도구가 손안에 있는 상태는 자유처럼 들린다. 하지만 경계 없는 자유 안에서 지내기란 생각보다 어렵다. 무한한 자원을 주면 사람은 그걸 어디에 쓸지 고민하다 평생을 보낼 수 있다. 반대로 아무것도 주지 않으면 질문이 단순해진다. 지금 가진 것으로 어디까지 갈 수 있을까?
이 질문은 사고방식을 바꾼다. 존재하지도 않는 완벽한 도구를 찾는 일을 멈추고, 눈앞에 있는 것으로 만들기 시작한다. 원래는 보이지 않았을 디테일이 눈에 들어온다. 관찰력이 뛰어나서가 아니라, 놓쳐도 되는 여유가 더 이상 없어서다.
선택지는 좁히고 주의력은 날카롭게 만드는 것, 글쓴이는 이게 제약의 진짜 선물이라고 말한다. 문이 적을수록 지금 서 있는 문이 더 선명하게 보인다.
Photo by 제약이 창의성을 강제한 사례들 #
Stevens의 책 #
Stevens의 책은 본질적으로 소켓 API 안내서다. socket(), bind(), listen(), accept(), connect(), read(), write(), close(). 지구 반대편에 있는 두 기계가 안정적으로 대화하기 위한 어휘가 이게 전부다.
그 호출들을 Stevens가 발명한 건 아니다. Berkeley 소켓은 1983년경 UC Berkeley CSRG의 4.2BSD에서 나왔고, Stevens는 그것이 실제로 어떻게 동작하는지 한 세대의 프로그래머에게 가르친 책을 썼다.
Stevens가 상정한 세계는 무한한 컴퓨팅 파워가 아니었다. 메모리가 비싸고 CPU가 느리고 링크가 불안정하고 대역폭이 좁던 시대에 만들어진 API를 문서화한 것이다. 실수할 여지가 없었다. 모든 걸 다 하려는 비대한 인터페이스도, 뭐든 다 받아주는 범용 계약도 들어설 자리가 없었다. 함수 하나하나가 자기 자리를 증명해야 했다.
그렇게 설계자들에게 강제된 제약 아래에서 나온 결과물이 지금은 어떤가. 40년이 지나 원래의 제약이 하나도 남지 않은 세상에서도, 거의 모든 프로그래밍 언어가 네트워킹을 하려면 그 인터페이스를 감싼다. Python의 socket 모듈, Node의 net 모듈, Go의 net 패키지. 전부 그 여덟 개 남짓한 원시 함수에서 형태를 물려받았다.
역설이 작은 규모로 드러난 사례다. 비대한 것을 만들 여유가 없었기에, 시대를 넘어서는 것을 만들 수밖에 없었다. BSD는 결핍 속에서 만들었고, Stevens는 그것이 왜 그렇게 단단한지를 기록했다.
글쓴이 본인도 90년대 책을 집어 들면서 놀랐다고 한다. 낡은 내용일 거라 예상했지만 실제로는 배울 게 많았고, 지금 만드는 소프트웨어에도 여전히 적용할 수 있는 것들이었다.
C #
모든 것의 시작이 된 언어. 지금 우리가 가진 거의 모든 것의 토대다.
C는 우아하지만 주는 게 놀랄 만큼 적다. GC도 없고, 정교한 표준 추상화도 없고, 나와 메모리 사이에 안전망도 없다. 뭔가 필요하면 대개 그 아래에서 무슨 일이 벌어지는지 직접 이해해야 한다.
지금 기준으로는 안전하지 않다거나 약점이라고 부를 만하다. 하지만 그 제약은 특정한 사고방식을 강제한다. 디테일에 더 신경 쓰게 되고, 메모리와 데이터 레이아웃, 소유권, 기계가 실제로 하는 일을 더 의식하게 된다. 언어가 선택지나 답을 많이 주지 않는 대신, 더 나은 질문을 하게 되고 시간이 지나도 유효한 결정을 내리게 된다.
Go #
시간을 현재로 돌려 Go를 보자. Go의 제약은 하드웨어가 강요한 게 아니라 설계자들이 상당 부분 직접 고른 것이다.
당대에 쓸 수 있는 온갖 것들이 있었지만, Go는 기능을 의도적으로 최소화하고 단순하게 유지하는 방향으로 설계됐다. 문법도, 타입 시스템도, 같은 아이디어를 표현하는 방법의 수도 그렇다.
한 문제를 푸는 방법이 적으면, 어떤 영리한 추상화를 쓸지 논쟁하는 시간이 줄고 문제 자체를 푸는 시간이 늘어난다. Go의 절제가 곧 기능이라는 게 글쓴이의 정리다. 무엇을 빼놓았는지가 무엇을 넣었는지만큼 의도적이라는 것이다.
음악 #
피아노를 치는 글쓴이에게 이 부분은 이론이 아니다.
지금은 노트북에 DAW와 플러그인 수천 개, AI 보컬 보정까지 올려놓고 어디서든 음반을 만들 수 있다. 70~80년대에는 그 작업 상당 부분이 물리적이었다. 테이프를 잘못 자르면 그 부분은 그대로 사라졌다. 트랙 수도, 스튜디오 시간도 제한적이었고 장비는 비쌌다. 밴드는 자기 파트를 확실히 알고 있어야 했다. 한 번 망치면 전원이 처음부터 다시 시작하는 경우도 있었다.
녹음 시간이 실제 돈이 되면 스네어 하나에 여섯 시간을 쓰지 않는다. 트랙이 여덟 개뿐이면 어떤 소리가 한 자리를 차지할 자격이 있는지 판단한다. 그 시절 음반에서는 그게 들린다. 연주, 불완전함, 그리고 결정들.
테이프를 다시 자르자는 주장이 아니다. 무한한 되돌리기가 하지 못하는 일을 제약이 해냈다는 이야기다.
모든 걸 가진 상태의 문제 #
풍요는 안일함을 부른다. 선택지가 끝없이 많으면, 무슨 문제든 일단 더 쏟아부어서 해결하려는 유혹이 생긴다.
AI로 돌아와 보자. 현대의 DAW처럼 AI도 작업의 훌륭한 파트너라고 글쓴이는 말한다. 다만 그와 동시에, 우리가 본 어떤 것보다도 빠른 속도로 제약을 걷어내고 있다.
몇 년 전만 해도 요청받은 기능 하나에 1~2개월이 걸렸다. 다른 아키텍처를 시도하려면 실제로 만들어봐야 했다. 코드 블록 하나를 다시 쓰는 데도 시간이 들었고, 내가 쓴 코드가 아니면 먼저 맥락을 이해해야 했다.
이제는 AI에게 부탁하면 몇 초 만에 끝난다. 예전에 우리를 멈춰 세운 건 노력이었다. 그 비용이 떨어지면, 이걸 애초에 해야 하는지 묻기를 그만두기 쉽다. 하나를 고르는 대신 다섯 버전을 뽑는다. 모델이 이미 아는 라이브러리라는 이유로 하나를 더 추가한다. 잘 돌아가는 코드를 새 초안이 더 깔끔해 보인다는 이유로 다시 쓴다.
질문이 "만들 수 있나?"에서 **"만들어야 하나?"**로 옮겨갔다는 게 글쓴이의 진단이다. 아무것도 없을 때는 한계가 밖에서 주어진다. 모든 걸 가졌을 때는 스스로 한계를 세워야 한다.
그래서 무엇을 할 것인가 #
글쓴이는 행사에서 만난 그 사람에게 답할 기회를 놓쳤다. 다시 기회가 온다면 도구 목록을 건네지는 않겠다고 한다.
선택지가 많다고 결과물이 좋아지는 건 아니고, 결정하지 않은 상태로 머무는 게 쉬워질 뿐이라고 말하겠다는 것이다. 90년대가 UNIX를 만든 이유는 더 많이 가졌기 때문이 아니다. 덜 가졌기 때문이고, 그 부족함이 작업을 정직하게 만들었기 때문이다.
AI를 버리라거나, 테이프 자르던 시절로 돌아가라거나, 전부 C로 쓰라는 말은 아니다. 이제는 환경이 한계를 공짜로 주지 않는다는 뜻이다. 날카로워지고 싶다면 직접 하나를 골라야 한다. 유스케이스 하나를 출시하기. 지루한 부분은 모델에게 생성시키고 핵심 결정은 내가 쥐기. 계속 추가하기 어려울 만큼 지독한 마감을 스스로에게 주기.
이번 주에는 스택을 하나로 묶어보기.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.