무한한 선택지 속에서 길을 잃다? 오히려 '제한'이 위대함을 벼려냅니다.

이 글을 쓰는 데 2주를 쏟아부었다는 게 믿기지 않네요.

지난주, 커서(Cursor) 커뮤니티 행사에서 AI가 소프트웨어 개발 방식을 어떻게 바꾸고 있는지에 대해 발표했습니다. 강연은 성공적으로 마무리되었고, 예상보다 많은 분이 1:1 대화를 신청하며 다가오셨죠.

그중 한 분이 유독 기억에 남았습니다. 기술 전문가는 아니었지만, 흥미로운 질문을 던졌습니다.

"요즘처럼 수많은 도구와 기술이 넘쳐나는 시대에 도대체 어떻게 길을 찾고, 올바른 것을 선택하나요?"

그는 분명 압도적으로 느껴질 것이라고 생각하는 듯했습니다. 그리고는 웃으며, 이렇게 많은 선택지가 있으니 분명 더 위대한 것들이 많이 만들어질 거라고 기대했죠.

저도 잠시 생각에 잠겨 미소 지었지만, 미처 답변을 시작하기도 전에 그는 자리를 떠야 했습니다. 하지만 그의 질문은 제 뇌리에 깊이 박혔습니다.

며칠 뒤, 도서관에 앉아 읽을거리를 찾던 중 우연히 그 질문에 대한 답을 발견했습니다. 바로 W. 리처드 스티븐스(W. Richard Stevens)의 『UNIX Network Programming』였습니다. (정말 대단한 책이니 꼭 한번 읽어보세요!)

90년대 기술, 제한된 메모리, 부족한 처리 능력, 협소한 대역폭, 변변찮은 도구들... 모든 것이 부족했던 시절.

하지만 역설적이게도 유닉스, TCP/IP, 초기 운영체제, 놀라운 수학적 발견, 거대한 엔지니어링 프로젝트, 그리고 지금까지 만들어진 가장 우아한 기술 중 일부가 바로 그 시대에 탄생했습니다.

이런 생각이 들 수밖에 없었습니다.

우리를 제약했던 것들이 오히려 우리를 더 나은 존재로 만들었던 것은 아닐까? 위대함은 항상 더 많은 것을 가짐으로써 만들어지는 것이 아니라, 적은 것으로 더 많은 것을 해내야만 했을 때 비로소 탄생하는 것은 아닐까?

그분은 더 많은 도구가 위대함에 더 가까이 다가갈 기회를 준다고 생각했지만, 제 손에 들린 책은 그 반대의 증거를 제시하고 있었습니다.

제한이 만드는 역설

저는 무언가가 부족할 때 오히려 우리가 더 나아질 수 있는 분명한 이유가 있다고 생각합니다.

우리는 보통 제한을 극복해야 할 대상으로 여깁니다. 돈 부족, 시간 부족, 자원 부족, 지식 부족. 이 모든 것이 우리가 성취하고자 하는 목표와 우리 사이에 가로막혀 있다고 말이죠.

하지만 제한에는 우리가 충분히 이야기하지 않는 또 다른 면이 있습니다.

제한은 단순히 무언가를 빼앗는 데 그치지 않습니다. 그것은 또한 '될 수 있었던 것'도 함께 앗아갑니다.

그리고 어쩌면 바로 그것이 우리에게 필요한 것일지도 모릅니다. 모든 것이 가능하고, 모든 방향이 열려 있으며, 모든 도구가 손에 있고, 모든 접근 방식이 우리에게 개방되어 있을 때, 그것은 자유처럼 들립니다.

그러나 경계 없는 자유는 놀랍도록 살기 어렵습니다.

누군가에게 무한한 자원을 준다면, 그들은 평생을 무엇을 할지 결정하는 데 보낼 수 있습니다. 아무것도 주지 않으면, 질문은 갑자기 단순해집니다.

지금 가진 것으로 얼마나 많은 것을 이룰 수 있는가?

이 질문은 당신의 사고방식을 바꿉니다. 완벽한 도구를 찾는 것을 멈추게 됩니다. 그런 것은 존재하지 않으니까요. 대신 눈앞에 있는 것으로 무언가를 만들기 시작합니다. 평소에는 보이지 않았을 세부 사항에 주목하게 됩니다. 당신이 본래 더 관찰력이 뛰어나서가 아니라, 더 이상 무시할 여유가 없기 때문입니다.

어쩌면 이것이 제한의 진정한 선물일지도 모릅니다. 선택지를 줄이는 동시에 우리의 주의력을 날카롭게 벼려주는 것이죠.

아마 이것이 역설일 겁니다. 문이 적을수록, 우리는 그 앞에 서 있는 단 하나의 문을 더 선명하게 볼 수 있습니다.

참고로, 이 아이디어가 전혀 새로운 것은 아닙니다.

제약이 강제하는 창의성

책 속에서 찾은 지혜

잠시 스티븐스의 책을 살펴봅시다. 이 책은 기본적으로 소켓 API(socket(), bind(), listen(), accept(), connect(), read(), write(), close())에 대한 상세한 설명서입니다.

지구 반대편에 있는 두 컴퓨터가 안정적으로 통신하게 만드는 데 필요한 어휘는 이게 전부입니다.

하지만 스티븐스가 이 호출들을 발명한 것은 아닙니다. 버클리 소켓은 1983년경 4.2BSD의 UC 버클리 CSRG에서 탄생했습니다. 스티븐스는 한 세대의 프로그래머들에게 이 API가 실제로 어떻게 작동하는지를 가르치는 책을 썼죠.

그는 무한한 컴퓨팅 파워의 세상을 위해 설계하지 않았습니다. 비싼 메모리, 느린 CPU, 신뢰할 수 없고 저대역폭 링크의 시대에 구축된 API를 문서화한 것입니다. 실수나 모든 것을 하는 광범위한 인터페이스, 혹은 일반적인 "모든 것을 수용하는" 계약을 위한 여지는 없었습니다.

모든 함수는 그 자리를 스스로 증명해야 했습니다.

그리고 그 설계자들이 강제로 부여받은 제약 덕분에, 그 결과는 너무나 최소적이고 잘 구성된 API가 탄생했습니다. 40년이 지난 지금, 원래의 제약 조건 중 어느 것도 존재하지 않는 세상에서, 여전히 거의 모든 프로그래밍 언어가 네트워킹을 위해 래핑하는 인터페이스로 남아 있습니다.

파이썬의 socket 모듈, Node의 net 모듈, Go의 net 패키지를 보십시오. 이들은 모두 그 여덟 개 정도의 기본 요소들로부터 그 형태를 계승하고 있습니다.

작은 규모의 역설이죠. 비대해질 여유가 없었기에, 그들은 어쩔 수 없이 시대를 초월하는 무언가를 만들어야 했습니다. BSD는 부족함 속에서 만들었고, 스티븐스는 왜 그것이 그토록 간결했는지 문서화했습니다.

개인적으로 90년대 책을 집어 들었을 때 시대에 뒤떨어졌을 거라 생각했지만, 오히려 지금 제가 만드는 소프트웨어에 적용할 만한 깊이 있는 인사이트를 얻어 정말 놀랐습니다. 10년 차 IT 실무자로서 이런 고전에서 얻는 배움은 최신 프레임워크를 따라가는 것만큼이나 값지다는 것을 다시 한번 깨달았습니다.

C 언어

오늘날 우리가 가진 모든 것의 토대를 마련한 언어, C를 살펴봅시다.

C는 좋은 예시입니다. 우아하면서도 놀라울 정도로 적은 것만을 제공합니다. 가비지 컬렉터도 없고, 정교한 표준 추상화도 없으며, 메모리와 당신 사이에 어떤 안전망도 없습니다. 무언가를 원한다면, 종종 그 아래에서 무슨 일이 벌어지고 있는지 이해해야 합니다.

오늘날 기준으로 보면 우리는 이것을 안전하지 않다고 부르거나 약점으로 치부할 것입니다. 하지만 그 제한은 특정 종류의 사고방식을 강요합니다. 세부 사항에 더 많은 주의를 기울여야 하고, 메모리, 데이터 레이아웃, 소유권, 그리고 기계가 실제로 무엇을 하는지에 대해 더 의식하게 됩니다.

이 언어는 많은 선택지나 답을 주지 않지만, 더 나은 질문을 하게 만들고 더 현명하고 시대를 초월하는 결정을 내리도록 이끕니다.

Go 언어

미래로 돌아와 Go 언어를 살펴봅시다. Go는 다른 방향을 택했습니다. Go의 제약은 하드웨어에 의해 부과된 것이 아니라, 주로 설계자들이 의도적으로 선택한 것이었습니다.

그 시대에 사용 가능한 모든 것이 있었음에도 불구하고, 이 언어는 의도적으로 최소적이고 단순한 기능을 유지하도록 설계되었습니다. 구문, 타입 시스템, 동일한 아이디어를 표현하는 더 적은 방법들.

언어가 문제를 해결하는 더 적은 방법을 제공할 때, 어떤 영리한 추상화를 사용할지 논쟁하는 데 시간을 덜 쓰고 문제 자체를 해결하는 데 더 많은 시간을 할애하게 됩니다.

Go의 절제는 그 자체로 기능입니다. 무엇을 포함할지 의도적으로 결정했듯이, 무엇을 배제할지도 마찬가지로 의도적인 선택입니다.

음악에서 배운 교훈

저는 피아노를 칩니다. 그래서 이 이야기는 이론적인 것이 아닙니다.

오늘날 노트북 하나에 DAW, 수많은 플러그인, AI 보컬 보정 도구를 넣으면 어디서든 음반을 만들 수 있습니다. 70년대와 80년대에는 그런 작업의 많은 부분이 물리적이었습니다. 테이프를 잘못 자르면 되돌릴 수 없었죠. 제한된 트랙, 제한된 스튜디오 시간, 비싼 장비. 밴드는 각 파트를 완벽하게 알고 있어야 했습니다. 한 번의 테이크를 망치면 때로는 모두가 처음부터 다시 시작해야 했죠.

녹음 시간이 실제 돈으로 계산될 때, 스네어 드럼 하나에 6시간을 쓸 수는 없습니다. 8개의 트랙밖에 없다면, 무엇이 그 트랙을 차지할 자격이 있는지 결정해야 합니다. 이러한 결정은 그 시절의 음반에서 고스란히 들립니다. 연주, 불완전함, 그리고 그 모든 의도적인 선택들이 말이죠.

저는 우리가 테이프를 자르던 시절로 돌아가자고 주장하는 것이 아닙니다. 저는 무한정 되돌리기가 제공할 수 없는 작업을 제약이 해냈다고 말하고 싶은 겁니다.

모든 것을 가졌을 때의 문제점

풍요로움은 자만심을 낳고, 끝없는 선택지는 모든 문제를 단순히 더 많은 것을 쏟아부어 해결하려는 유혹을 만들어냅니다.

다시 AI 이야기로 돌아가 봅시다. 현대의 DAW처럼, AI는 우리 작업의 훌륭한 파트너라고 저는 믿습니다. 하지만 동시에, AI는 우리가 이전에는 거의 보지 못했던 속도로 엄청난 양의 제약을 제거하고 있습니다.

불과 몇 년 전만 해도, 기능 하나를 요청하면 1~2개월이 걸렸습니다. 다른 아키텍처를 시도한다는 것은 실제로 그것을 구축하는 것을 의미했습니다. 코드 블록을 다시 작성하는 데는 시간이 걸렸고, 제 코드가 아니었다면 먼저 그 맥락을 이해해야 했습니다.

이제 AI에게 이 모든 것을 몇 초 만에 처리해 달라고 요청할 수 있습니다. 예전에는 '노력'이 우리의 발목을 잡던 것이었습니다. 그 비용이 급격히 떨어지면, '과연 이걸 해야 할까?'라는 질문 자체를 멈추기 쉬워집니다. 하나를 선택하는 대신 다섯 가지 버전을 생성하고, AI 모델이 이미 알고 있다는 이유로 라이브러리를 하나 더 추가하며, 작동하는 코드를 새 드래프트가 더 깔끔해 보인다는 이유로 다시 작성합니다.

이제는 "이걸 만들 수 있을까?"가 아닌, **"이걸 만들어야 할까?"**로 질문이 바뀌고 있습니다.

아무것도 없을 때는 제한이 우리에게 부과됩니다. 모든 것을 가졌을 때는, 스스로에게 제한을 두어야 합니다.

그렇다면 무엇을 해야 하는가?

그 행사에서 그분께 답을 해드릴 기회가 없었습니다. 만약 지금 그에게 답할 수 있다면, 도구 목록을 알려주지 않을 겁니다.

저는 그에게 더 많은 선택지가 더 나은 작업물을 보장하지 않으며, 오히려 결정을 내리지 못하게 할 뿐이라고 말해줄 것입니다. 90년대에 유닉스가 탄생한 것은 사람들이 더 많은 것을 가졌기 때문이 아닙니다. 그들은 부족했기 때문에, 그 부족함이 솔직하고 핵심에 집중하는 작업을 강요했기 때문입니다.

이것이 AI를 버리거나, 테이프를 자르던 시절로 돌아가거나, 모든 것을 C로 작성하라는 의미는 아닙니다. 이것은 더 이상 환경이 우리에게 공짜로 제한을 부여하지 않는다는 의미입니다. 만약 날카로움을 원한다면, 스스로 하나를 선택해야 합니다. 하나의 사용 사례에 집중하여 배포하세요. AI에게 지루한 부분은 생성하게 하고 핵심 결정은 당신이 내리세요. 마감을 너무나 빡빡하게 잡아 더 이상 추가할 여유가 없게 만드세요.

이번 주에는 스택의 사용을 제한해 보는 것도 좋은 시작이 될 겁니다. 제가 실무에서 10년간 개발자로 일하며 깨달은 점은, 무작정 최신 기술이나 도구를 좇기보다는 당면한 문제를 해결하는 데 집중할 때 훨씬 효율적이라는 겁니다. 때로는 '없는 것'이 최고의 스승이 되곤 하죠.

---

원문: https://dev.to/adamthedeveloper/greatness-is-forged-by-limitation-e20 수집일: 2026-08-20 00:30:11