첫 커밋에서 라이브 제품까지 48시간 만에

2025년 11월 21일, 오전 9:14

우리가 첫 번째 커밋을 푸시한 순간입니다. 빈 프로젝트. 백지 캔버스. 11월 23일 자정까지 우리는 실제 사용자에게 서비스를 제공하는 커스텀 도메인을 가진 라이브 제품을 갖추게 되었습니다.

이 이야기는 절차를 생략하거나 결함이 있는 소프트웨어를 배포하는 것에 관한 것이 아닙니다. 정확히 무엇을 만들고 있는지 알고, 다른 것에 시간을 낭비하지 않겠다는 결단에 관한 이야기입니다.

48시간 내에 배포된 것

이틀째 끝날 무렵 라이브 상태였던 것은 다음과 같습니다:

실시간 AI 채팅 인터페이스. API를 감싸는 것이 아닙니다. 세션 관리, 메시지 이력, 스트리밍 응답이 있는 제대로 된 채팅 시스템입니다. 사용자는 실제로 맥락을 기억하는 AI 에이전트와 대화할 수 있었습니다.

가상 파일 시스템. 사용자는 폴더를 만들고, 파일을 업로드하고, 이름을 바꾸고, 작업 공간으로 정리할 수 있었습니다. AI는 대화 중에 이 파일을 읽고 쓸 수 있었습니다. 장난감 데모가 아니라 MongoDB로 지원되는 실제 파일 시스템입니다.

에이전트 전환이 가능한 작업 공간. 서로 다른 작업 공간은 서로 다른 기능을 가진 AI 에이전트를 사용할 수 있습니다. 사용자는 코딩 작업 공간, 글쓰기 작업 공간, 연구 작업 공간을 가질 수 있으며, 각 작업 공간은 고유한 맥락과 파일을 가집니다.

사용자 인증 및 동기화. RabbitMQ를 통해 우리의 인증 시스템에 연결되었습니다. 사용자는 로그인하고 그들의 데이터가 즉시 모든 장치에서 나타났습니다.

이미지 생성. AI는 대화 중에 이미지를 생성할 수 있었습니다. 단순한 텍스트 응답이 아니라 실제 시각적 출력입니다.

템플릿. 사용자가 첫 방문 시 빈 화면을 마주하지 않도록 미리 구축된 시작점입니다.

배포 파이프라인. Docker화되어 배포되었고, 적절한 환경 구성으로 커스텀 도메인에서 실행되고 있습니다.

가능하게 한 결정들

이런 속도는 48시간 내내 일하는 것에서 오는 것이 아닙니다(물론 그런 시간도 많았습니다). 첫 번째 코드 줄을 작성하기 전에 내리는 결정에서 옵니다.

결정 1: Mongoose 대신 MongoDB. 우리는 약 4시간 동안 Mongoose를 사용했습니다. 그 후 원시 MongoDB 드라이버로 전환했습니다. Mongoose는 대규모 팀에 유용한 스키마 검증 레이어를 추가하지만, 데이터 모델을 아는 소규모 팀에게는 순수한 오버헤드입니다. 4시간이 “낭비"되었지만, 그 덕분에 이후 몇 주 동안 수십 시간을 절약했습니다.

결정 2: 서버와 클라이언트를 하나의 레포지토리에서 구축. 모노레포. 하나의 docker-compose.yml. 하나의 배포 명령. 레포 간 조정 없음. “API는 배포되었지만 프론트엔드는 아니다” 같은 일은 없습니다. 빠르게 움직일 때는 동기화가 어긋날 수 있는 요소를 줄이는 것이 조직의 순수성보다 더 중요합니다.

결정 3: 이틀째에 프로덕션으로 배포, 20일째가 아님. 우리는 “준비가 되기 전에” 배포했습니다. 도메인이 구성되고, SSL이 설정되었으며, 환경 변수가 제자리에 있었습니다 — 절반의 기능이 구축되기 전이었습니다. 왜 그럴까요? 배포는 당신을 놀라게 하는 부분이기 때문입니다. 이틀째에 세 가지 기능으로 그런 놀라움을 발견하는 것이, 20일째에 서른 가지로 발견하는 것보다 낫습니다.

우리가 만들지 않은 것

우리가 배포한 것만큼이나 중요하게 의도적으로 제외한 것들도 있습니다:

• 관리자 패널 없음. 우리는 MongoDB Compass를 직접 사용했습니다.
• 커스텀 디자인 시스템 없음. 우리는 깔끔한 기본값을 사용하고 나중에 반복했습니다.
• 분석 없음. 우리는 서버 로그를 관찰했습니다.
• 자동화된 테스트 없음. (그건 3일째에 이루어졌습니다.)
• 문서 없음. 코드가 문서였습니다.

이 각각은 “책임감 있는” 선택으로 여겨질 수 있었습니다. 각각 하루를 소모했을 것입니다. 그리고 그 중 어느 것도 이틀째에 실제 사용자 앞에 제품을 내놓음으로써 우리가 배운 것들을 가르쳐주지 않았습니다.

교훈

이 이야기에는 우리가 아키텍처 다이어그램에 2주를 소비하는 버전이 있습니다. Google 문서에서 데이터베이스 스키마에 대해 논의하는 버전이 있습니다. 애플리케이션 코드를 작성하기 전에 적절한 CI/CD 파이프라인을 설정하는 버전이 있습니다.

그 이야기의 버전은 아름다운 계획으로 끝나고 제품은 없습니다.

실제로 일어난 버전은 작동하는 제품과 개선할 사항의 긴 목록으로 끝났습니다. 우리는 매번 그 거래를 선택할 것입니다.

48시간. 첫 커밋에서 라이브 제품까지. 우리가 천재여서가 아닙니다. 빠르게 결정을 내리고, 더 빠르게 배포하며, 실제로 모두가 하는 대로 프로덕션에서 문제를 수정했기 때문입니다 — 하지만 이를 인정하는 사람은 드뭅니다.

오늘 여러분이 보는 제품은 84일과 632개의 커밋 후에 바로 그곳에서 시작되었습니다. 48시간 안에.