DarkGarden

Topics

Sections

3일차 | 1000억 벌기 | 매출 $0 | Victory or Valhalla

15 min read

3일차 | 1000억 벌기 | Victory or Valhalla — 프로젝트 관리 시스템 개발 여정

📺 원본 영상: 3일차 | 1000억 벌기 | 매출 $0 | Victory or Valhalla 🎙️ 채널: 코드팩토리 📅 정리 일자: 2026-05-20 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 이 영상은 라이브 코딩 스트림으로, 전체 202분 중 대부분의 시간 동안 화면의 코드 에디터 작업이 무음으로 진행됩니다. 화면에 표시된 코드, 터미널, 브라우저 등의 내용은 포함되지 않으며, 음성에서 파악 가능한 범위 내에서만 서술되었습니다.

개요

‘Victory or Valhalla’는 코드팩토리 채널이 진행하는 도전 시리즈로, 매출 $0에서 시작해 목표 수익을 달성하거나 실패하는 과정을 라이브로 공개하는 프로젝트다. 3일차에 접어든 이번 세션에서는 앞선 이틀간의 아이디에이션(Ideation) 결과를 바탕으로 구체적인 방향을 확정하고 실제 코딩에 돌입한다. 이날의 핵심 목표는 PMS(Project Management System, 프로젝트 관리 시스템) 웹 서비스의 기반을 닦는 것이며, 기술 스택 선택부터 핵심 도메인 설계까지 약 3시간 22분에 걸친 집중 세션이 이어진다.

방향 전환 — 1, 2일차를 버리고 다시 시작하다

3일차 시작과 함께 진행자는 단호한 결정을 내린다. 1일차와 2일차에 진행했던 내용을 모두 폐기하고, 두 세션에서 얻은 인사이트만을 결합해 완전히 새로운 접근을 시도하기로 한 것이다. “아이디에이션을 많이 했고 이제 무엇을 만들지 감이 왔다”는 발언이 이 결정의 배경을 설명한다. 프로토타이핑 초기에 방향을 자주 틀고 빠르게 검증하는 방식은, 스타트업 초기 단계에서 흔히 권장되는 접근법이기도 하다.

새로운 방향의 핵심은 소유자 보고서(Owner Report)를 생성하는 기능을 갖춘 프로젝트 관리 시스템을 웹 서비스 형태로 구축하는 것이다. 여기서 PMS는 단순한 할 일(To-do) 목록의 집합이 아니라, 관리자 관점에서 팀이나 조직의 프로젝트 상태를 요약하고 인사이트를 제공하는 제품으로 설계된다. 이 ‘Owner Report’라는 개념이 경쟁 제품들과의 차별점을 만들어낼 핵심 기능이 될 것으로 보인다.

기술 스택 선택 — Convex vs Supabase

프로젝트의 기반 기술을 결정하는 과정에서 진행자는 두 가지 백엔드 서비스를 놓고 비교 검토를 진행한다. 선택지는 Convex와 Supabase였으며, 이 두 서비스는 모두 현대적인 웹 애플리케이션 개발에서 빠른 프로토타이핑과 서버리스(Serverless) 아키텍처를 지원하는 BaaS(Backend-as-a-Service) 플랫폼이다.

검토 결과, 이 프로젝트에 대해서는 Convex를 선택하는 것으로 결론을 내린다. Supabase가 PostgreSQL 기반의 안정적인 관계형 데이터베이스 서비스를 제공하는 반면, Convex는 실시간 반응성(Reactivity), 함수형 백엔드 구성, 그리고 TypeScript와의 긴밀한 타입 통합이 강점이다. 프로젝트 관리 시스템이 실시간 협업과 상태 동기화를 필요로 한다는 점에서 Convex의 특성이 더 적합하다고 판단한 것으로 해석된다.

💡 [영상 참조] 진행자는 [16:19] 전후로 Convex와 Supabase를 비교하는 화면을 보며 분석합니다. 📺 원본 영상에서 확인하세요.

소프트웨어 아키텍처 — Vertical Slice Architecture 채택

기술 스택 결정에 이어 소프트웨어 아키텍처 패턴에 대한 고민도 이어진다. 진행자가 검토한 것은 **Vertical Slice Architecture(수직 슬라이스 아키텍처)**다. 이는 전통적인 레이어드 아키텍처(Controller-Service-Repository 계층 분리 방식)와 달리, 각 기능(Feature) 단위로 코드를 수직으로 묶어 관리하는 패턴이다.

Vertical Slice Architecture에서는 하나의 기능을 구현하는 데 필요한 모든 코드—데이터 접근, 비즈니스 로직, API 핸들러—가 동일한 폴더나 모듈 안에 함께 위치한다. 새로운 기능을 추가하거나 기존 기능을 수정할 때 여러 레이어를 넘나들 필요가 없어, 작은 팀이나 1인 개발 환경에서 개발 속도와 유지보수성 면에서 유리하다. ‘Victory or Valhalla’ 챌린지의 맥락, 즉 빠르게 수익을 창출해야 한다는 압박 속에서 이 아키텍처를 선택한 것은 합리적인 판단이다.

핵심 도메인 설계 — 무엇을 만드는가

약 3시간이 넘는 코딩 세션 동안 진행자가 구현하는 기능들을 음성 단서들을 통해 파악하면, PMS의 핵심 도메인 구조가 서서히 드러난다. 워크스페이스(Workspace), 연결(Connection), 에이전트(Agent), 액션(Action), 도메인(Domain), 프로필(Profile) 등의 개념이 등장하며, 이는 단순한 태스크 관리를 넘어 AI 에이전트 기반의 자동화 기능을 통합한 시스템임을 시사한다.

인증 측면에서는 Clerk과의 통합이 언급된다. Clerk은 사용자 인증, 세션 관리, 소셜 로그인 등을 손쉽게 구현할 수 있는 서비스로, 이를 통해 인증 로직을 외부에 위임하고 핵심 제품 기능 개발에 집중하는 구조를 택한 것으로 보인다. 이 역시 초기 스타트업에서 흔히 사용되는 전략이다.

💡 [영상 참조] [137:12] 진행자는 새로운 연결(New Connection) 기능 구현 작업을 진행 중입니다. 📺 원본 영상에서 확인하세요.

AI 에이전트 통합 — MCP와 에이전트 스키마

세션 후반부에 접어들면서 AI 에이전트 관련 작업이 집중적으로 이루어진다. “에이전트 공식 스키마(Agent official schema)”, “상태 패치(status patch)”, “프로바이더 목(provider mock)” 등의 표현이 등장하면서, 단순한 CRUD 애플리케이션을 넘어 AI 에이전트를 시스템 내에 통합하는 아키텍처를 구현하고 있음이 명확해진다.

특히 **MCP(Model Context Protocol)**에 대한 언급이 주목할 만하다. MCP는 AI 모델이 외부 도구 및 시스템과 상호작용하는 방식을 표준화한 프로토콜로, 진행자는 “MCP만 오늘 외부 에이전트는 표시 안 된다”는 발언을 통해 MCP 기반의 에이전트 연동을 구현 중임을 내비친다. “게이트에 따라 전환(Transition depends on gate)“이라는 언급은 에이전트의 상태 머신(State Machine) 혹은 라우팅 로직을 구현하는 것으로 해석된다. 또한 “재사용 가능한 프로필(Reusable profile)“은 다양한 컨텍스트에서 에이전트 설정을 재활용할 수 있는 설계 개념으로 보인다.

💡 [영상 참조] [108:20] 진행자는 에이전트 스키마 작업 및 TypeScript 컴파일러 경고 처리를 진행 중입니다. 📺 원본 영상에서 확인하세요.

라이브 코딩 스트림의 특성 — 침묵 속의 집중

이 영상의 대부분, 약 3시간에 걸친 구간은 진행자가 코드를 작성하는 동안 거의 아무런 말도 하지 않는 순수한 코딩 세션으로 이루어진다. “Okay”, “Let’s see” 같은 짧은 독백이 간헐적으로 등장할 뿐이며, 이는 이 STT 데이터의 정보 밀도가 극히 낮은 이유이기도 하다. 라이브 코딩 스트림의 본질적인 가치는 ‘설명’보다는 실시간으로 개발자의 작업 흐름과 의사결정 과정을 함께 경험하는 데 있다.

세션 중간에는 시청자(채팅)와의 짧은 인터랙션도 등장한다. 구글이 기대와 달리 다른 서비스들과 비슷하게 변해버렸다는 시청자의 실망 표현에 진행자가 공감하는 장면, 특정 기술 서적(STT 오인식으로 원제 파악이 어려우며 ‘Antigravity book’으로 들린 도서)을 구매했다는 시청자와의 짧은 대화 등이 이어진다. 이러한 인터랙션은 이 콘텐츠가 단방향 강의가 아니라, 커뮤니티와 함께 만들어가는 라이브 개발 여정임을 보여준다.

마무리 — 오늘의 성과와 내일의 계획

약 202분의 세션을 마무리하며 진행자는 “일단 오늘은 여기서 멈추겠다”고 선언한다. 아직 모든 것이 의도대로 맞아 떨어지지 않는다는 솔직한 소감을 전하면서도, 함께한 시청자들에게 감사를 표하고 마무리 작업 후 내일을 기약한다. 이 챌린지의 이름 ‘Victory or Valhalla’가 암시하듯, 성공이든 실패든 끝까지 달려가겠다는 의지가 담긴 마무리다.

3일차까지의 진행 상황을 종합하면, 프로젝트의 기술 스택(Convex, Clerk)과 아키텍처 방향(Vertical Slice Architecture)이 확정되었고, 핵심 도메인(워크스페이스, 에이전트, 액션, 연결)의 구현이 시작되었다. PMS에 MCP 기반 AI 에이전트를 통합하는 야심찬 방향성은 단순한 할 일 관리 앱과의 차별화를 목표로 하는 것으로 읽힌다. 매출 $0에서 시작한 이 여정이 어디로 향할지는 앞으로의 세션들이 보여줄 것이다.

📚 출처 및 참고

구분내용
원본 영상3일차 | 1000억 벌기 | 매출 $0 | Victory or Valhalla
채널코드팩토리
영상 길이약 202분 (3시간 22분)
리포트 작성2026-05-20
작성 방식YouTube 영상 STT 변환 후 에디팅

💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 이 영상은 라이브 코딩 스트림 특성상 STT 품질이 낮으며, 실제 작업 내용의 대부분은 화면을 통해서만 전달됩니다. 정확한 내용은 원본 영상을 참조해 주세요.

그래프 뷰

Related Reports