모든 새로운 프로젝트는 똑같은 유혹을 속삭입니다. 에디터를 열고, 프레임워크를 선택한 뒤, 바로 타이핑을 시작하라는 유혹 말입니다. MaxOS의 제작자인 Max Paardekam은 그 유혹을 강렬하게 느꼈습니다. 불과 몇 주 전만 해도 이 프로젝트는 그의 노트 속에 흩어진 아이디어에 불과했습니다. 그의 즉각적인 본능은 Cursor 안에서 TypeScript를 작성하며 근육 기억과 자동 완성 기능에 몸을 맡긴 채 시간 가는 줄 모르고 코딩하는 것이었습니다. 하지만 그는 이를 견뎌냈습니다. 애플리케이션 코드를 작성하는 대신, 그는 더 희귀하고도 깨지기 쉬운 것, 즉 완성된 아키텍처를 만들어냈습니다.
처음에는 그 결정이 마치 정체된 것처럼 느껴졌습니다. 도구들은 준비되어 있고 보일러플레이트는 몇 초 만에 설치되는데, 잠시 멈춰서 상자와 화살표를 그리며 설계하는 것은 불합리해 보일 수 있습니다. 하지만 MaxOS는 단순히 웹 뷰를 감싼 또 하나의 단순한 Electron 래퍼가 되려는 것이 아닙니다. 목표는 수년간의 사용, 리팩터링, 그리고 확장을 견뎌낼 수 있는 무언가를 구축하는 것입니다. 그러한 수명을 가진 시스템은 빠른 시작 그 이상의 깊이를 요구합니다. 첫 번째 import 문을 작성하기 전에 일관된 사고가 필요합니다.
IDE는 나중에 시작해도 되는 이유
현대의 개발 환경은 계획과 실행 사이의 경계를 모호하게 만듭니다. Cursor와 같은 AI 지원 에디터는 주석 하나만으로 전체 컴포넌트를 생성하는 것을 가능하게 합니다. 피드백 루프는 즉각적이며, UI가 눈앞에 구현되는 것을 지켜볼 때 느끼는 도파민의 쾌감은 매우 강력합니다. Paardekam도 정확히 그런 가정에서 시작했습니다. 초기 에너지의 대부분이 TypeScript 파일로 직접 흘러 들어갈 것이라고 말이죠. 하지만 그는 점차 그 시간들을 순수한 설계 작업으로 돌렸습니다.
이는 1인 개발자에게 매우 어려운 전환입니다. 혼자서 전체 엔지니어링 팀의 역할을 수행할 때, 다이어그램 도구나 텍스트 문서에서 보내는 모든 시간은 제품 출시를 위해 써야 할 시간을 훔치는 것처럼 느껴지기 때문입니다. 하지만 초기에 작성된 코드는 종종 '진전'이라는 가면을 쓴 '부채'가 되곤 합니다. 첫날 오후에 세워둔 가설을 바탕으로 코드를 짜다 보면, 새로운 기능이 추가될 때마다 기존 코드를 억지로 수정해야 하는 상황이 발생하며 실행 가능한 프로토타입이 주는 신선함은 금방 사라집니다. 에디터로부터 자신을 강제로 멀어지게 함으로써, Paardekam은 시간이 흐를수록 복리로 쌓이는 단 하나의 자산, 즉 '명확성'을 확보했습니다.
기능이 아닌 시스템으로 생각하기
지난 몇 주간 가장 큰 변화는 기술적인 것이 아니라 인지적인 것이었습니다. 소프트웨어 아키텍처를 진지하게 다루기 시작하면, 스스로에게 던지는 질문 자체가 재구성됩니다. Paardekam은 프로젝트에 접근할 때 '기능 중심적 사고'를 버렸습니다. 특정 기능을 어떻게 덧붙일지 고민하는 대신, 더 어려운 질문에 직면했습니다. '어떤 근본적인 구조가 미래의 모든 기능을 더 쉽게 추가할 수 있게 만들 것인가?'
이 차이는 매우 중요합니다. 기능 중심적 사고는 소프트웨어를 할 일 목록(to-do list)처럼 취급합니다. 검색 기능을 구현하고, 그다음 알림 기능을, 그다음 내보내기 버튼을 만드는 식입니다. 반면 시스템 중심적 사고는 검색, 알림, 내보내기 기능이 어떻게 동일한 데이터 모델, 동일한 이벤트 버스, 그리고 동일한 권한 계층을 공유할 수 있을지를 묻습니다. 이는 문장을 쓰기 전에 애플리케이션의 문법을 설계하는 것을 의미합니다. 초기 비용은 더 높습니다. 하지만 그 보상으로 미래의 작업은 단순한 조립이 아닌, 하나의 조화로운 구성을 이루는 과정이 됩니다.
이는 보통 10개의 서로 다른 애플리케이션에 나뉘어 있는 기능들을 통합하려는 MaxOS와 같은 프로젝트에 특히 중요합니다. 시스템적 사고 없는 긴밀한 통합은 취약한 연결 고리와 일관성 없는 상태가 뒤엉킨 악몽이 됩니다. 반면 시스템적 사고가 뒷받침된다면, 워크스페이스는 짜깁기된 도구들의 집합이 아니라 하나의 유기체처럼 작동하게 됩니다.
운영체제가 아닌 워크스페이스
Paardekam은 자신의 야망이 가진 경계에 대해 솔직하게 밝혀왔습니다. MaxOS는 Windows나 macOS를 대체하지 않을 것입니다. 드라이버, 메모리 할당 또는 하드웨어 추상화 계층을 관리하려는 야심도 없습니다. 목표는 그보다 더 밀접한 영역인 '워크스페이스'입니다.
대부분의 지식 노동자들은 파편화된 환경에서 살아갑니다. 이메일 클라이언트에서 캘린더로, 메모 앱에서 터미널로, 디자인 도구에서 메시징 플랫폼으로 끊임없이 이동합니다. 이 이동 하나하나에는 마찰이 따릅니다. 맥락(context)은 소실되고, 주의력은 분산됩니다. 운영체제는 무대를 제공하지만, 연극을 연출하지는 않습니다.
MaxOS는 사용자의 작업 흐름을 이해하고 더 빠르게 움직일 수 있도록 적극적으로 돕는 하나의 통합된 환경을 지향합니다. 이는 전통적인 OS를 만드는 것과는 다른 엔지니어링 과제입니다. 워크플로우에 대한 깊은 공감, 범위에 대한 냉혹한 편집, 그리고 사용자가 도구에 맞추는 것이 아니라 사용자의 의도에 적응하는 인터페이스가 필요합니다. 워크스페이스를 대체한다는 것은 습관을 대체한다는 뜻이며, 습관은 대안이 학습 곡선이 아닌 '해방감'으로 느껴질 때에만 바뀝니다.
고요한 몇 주 동안 만들어진 것들
Paardekam의 설계 단계에서는 두 가지 구체적인 결과물이 도출되었습니다. 첫째는 명확한 비전과 미션 정의입니다. 이는 단순한 마케팅용 미사여구가 아닙니다. 1인 기술 창업자에게 이는 궁극적인 범위 관리자(scope guard) 역할을 합니다. 채팅 사이드바를 추가할지, 아니면 플러그인 마켓플레이스를 만들지 결정해야 하는 상황에서, 미션 선언문은 이를 수용하거나 거부하는 기준이 됩니다. 둘째로, 그는 전체 프로젝트 청사진을 완성했습니다.
전체 계획이 처음부터 끝까지 펼쳐지는 것을 보는 것은 프로젝트의 심리적 상태를 변화시켰습니다. 노트에 적힌 아이디어는 가설처럼 느껴지지만, 청사진은 필연적인 것처럼 느껴집니다. 청사진은 수정 비용이 저렴한 단계에서 공백을 드러내 줍니다. 또한 가장 까다로운 리스크가 어디에 숨어 있는지도 보여줍니다. 이 단계에서는 정교한 문서가 코드 몇 줄보다 진정으로 더 중요합니다. 코드는 리팩터링할 수 있지만, 모호한 전제는 밤샘 디버깅으로도 해결할 수 없는 기술 부채로 고착화됩니다.
종이에서 모노레포로
설계가 완료됨에 따라 다음 단계가 시작되었습니다. Paardekam은 문서를 넘어 코드로 넘어가고 있으며, 그 시작은 모노레포의 초기화입니다. 이러한 전환에는 그 자체의 불안감이 따릅니다. 청사진은 약속이고, 코드베이스는 증거입니다. 그는 설계가 실제 구현 과정에서도 살아남을 수 있을지에 대해 긴장된다고 인정했습니다. 이러한 솔직함은 이론이 라이브러리 버전, 엣지 케이스, 그리고 크로스 플랫폼 동작의 현실과 맞닥뜨릴 때 비로소 나타나는 미지의 영역에 대한 건강한 경외심을 반영합니다.
모노레포를 초기화하는 것은 단순히 형식적인 git init 이상의 의미를 갖습니다. 이는 논리적 아키텍처를 반영할 물리적 구조를 설정하는 작업입니다. 패키지가 어디에 위치할지, 패키지 간의 의존 관계는 어떠할지, 그리고 레이어 간의 경계가 어디에 놓일지는 지난 몇 주간의 계획을 그대로 투영하게 됩니다. 초기 폴더 구조와 빌드 파이프라인이 잘 구축된다면 향후 기여(contribution)를 이끄는 가이드가 되겠지만, 잘못 구축된다면 프로젝트를 건드리는 모든 개발자에게 수년간 소리 없는 형벌을 내리게 될 것입니다.
핵심 교훈
Paardekam의 경험은 현대 소프트웨어 문화의 상당 부분을 지배하는 속도 지상주의(cult of velocity)에 경종을 울립니다. 빠르게 출시하고, 성장을 보여주고, 대화 대신 코드로 대체하라는 엄청난 압박이 존재합니다. 하지만 어떤 프로젝트들, 특히 오래 지속되기를 목적으로 하는 프로젝트들은 인내에 보답합니다. 변수를 선언하기 전에 비전을 정의하고, 청사진을 그리고, 시스템을 설계하는 절제력은 결코 변하지 않는 오래된 조언입니다.
지금 당장 아이디어를 품고 에디터를 열고 싶어 안달이 나 있다면, 며칠간의 의도적인 설계가 몇 달간의 분산된 재작업을 줄여줄 수 있을지 고민해 보십시오. 실행 중인 앱이 주는 도파민은 사라지지만, 훌륭한 아키텍처가 주는 명확성은 복리로 쌓입니다. 당신이 무엇을, 왜 만드는지 정확히 아는 것부터 시작하십시오. 타이핑은 나중에 해도 됩니다.