들어가며 — 왜 갑자기 웹앱을 만들겠다고 했나
저는 13년차 서버/스토리지/가상화 엔지니어입니다. 매일 Proxmox 클러스터를 만지작거리고, 스토리지 볼륨을 쪼개고, 장애가 나면 새벽에도 눈을 뜨는 그런 삶을 살고 있습니다. 거기에 4명의 아이를 키우고 있으니 하루가 어떻게 지나가는지 모를 때가 정말 많습니다.
"오늘 뭐 했지?" 하고 멍하니 천장을 바라보는 날이 점점 늘어났습니다. 분명히 바빴는데, 뭘 했는지 모르겠는 그 느낌 아시죠? 아이 넷을 재우고 나면 이미 밤 10시인데, 하고 싶었던 건 하나도 못 하고 하루가 끝나버리는 날들이 반복됐습니다.
그래서 시작한 게 타임박싱입니다. 처음에는 A4 용지에 표를 직접 그려서 썼습니다. 15분 단위로 칸을 나누고, 왼쪽에 PLAN을 적고, 오른쪽에 실제로 한 일을 기록했어요. 형광펜으로 색을 칠하면 하루가 한눈에 보였습니다. 꽤 효과가 있었습니다.
문제는 종이였습니다.
지난주에 뭘 했는지 보려면 서랍을 뒤져야 했고, 매일 같은 일정을 새로 그려야 하는 게 귀찮았습니다. 밖에 나가면 볼 수가 없었고, 무엇보다 "이번 달에 회의에 몇 시간을 썼지?" 같은 통계를 내려면 수작업이 필요했습니다. 엔지니어한테 수작업이라니, 이건 자동화 대상이죠.
그래서 결심했습니다. 이걸 웹앱으로 만들자고요. 문제는 저는 프론트엔드 개발자가 아니라는 겁니다. 서버는 다룰 줄 알지만 HTML/CSS/JS는 기초 수준이거든요. 여기서 Claude의 도움을 받기 시작했습니다.
바이브 코딩이란? — 비개발자가 웹앱을 만드는 시대
2025년 초, 테슬라 전 AI 디렉터 안드레이 카파시가 바이브 코딩(Vibe Coding)이라는 개념을 소개했습니다. 핵심은 간단합니다. 코드를 한 줄 한 줄 직접 쓰는 대신, 원하는 걸 자연어로 설명하면 AI가 코드를 생성해주는 방식이에요. "어떻게(How)" 만들지가 아니라 "무엇을(What)" 만들지에 집중하는 겁니다.
2026년 현재, 개발자의 84% 이상이 AI 도구를 사용하고 있다고 합니다. Claude Code, Cursor, Windsurf 같은 도구들이 코딩의 진입 장벽을 확 낮춰버렸어요. 저처럼 서버는 만질 줄 알지만 프론트엔드는 기초 수준인 사람도 웹앱을 만들 수 있는 세상이 된 겁니다.
저는 Claude와 대화하면서 코드를 만들었습니다. "타임그리드를 HTML 테이블로 만들어줘, 15분 단위로 5 AM부터 1 AM까지" 이런 식으로 설명하면 Claude가 뼈대를 잡아주고, 제가 수정하고, 다시 물어보고… 이 과정을 반복했어요. 옆에 시니어 프론트엔드 개발자가 앉아있는 느낌이었습니다. (다만 아이 네 명이 뛰어다니는 거실에서 코딩하는 건 좀 다른 환경이지만요.)
중요한 건, 바이브 코딩이라고 해서 코드를 아예 이해하지 않아도 된다는 뜻은 아니라는 점입니다. 그대로 복붙만 하면 반드시 문제가 생깁니다. "왜 이렇게 동작하는지" 이해하면서 가야 나중에 디버깅도 되고, 기능 확장도 됩니다. 저는 이걸 "이해하면서 하는 바이브 코딩"이라고 부르기로 했습니다. 아직 아무도 쓰지 않는 용어지만, 이 시리즈를 통해 그 과정을 보여드리려 합니다.
Alt: "야간 홈오피스 책상 위 모니터에 표시된 컬러풀한 타임박싱 웹앱 화면과 주변에 놓인 아이들 장난감과 커피잔" -->
타임박싱이 뭔데? — 일론 머스크도 쓴다는 시간 관리법
혹시 타임박싱을 모르시는 분을 위해 간단히 설명드리면, 일론 머스크나 빌 게이츠도 쓴다고 알려진 시간 관리 기법입니다. 핵심은 간단해요.
하루를 시간 블록으로 나누고, 미리 뭘 할지 정한 뒤, 실제로 뭘 했는지 비교합니다.
일반적인 To-Do 리스트와의 차이점은 "언제 할 건지"가 정해져 있다는 겁니다. "보고서 쓰기"가 아니라 "2시~3시: 보고서 쓰기"로 구체적으로 잡아요. 이렇게 하면 하루가 끝났을 때 계획 대비 실제를 비교할 수 있고, 시간을 어디에 쓰는지 패턴이 눈에 보이기 시작합니다.
타임박싱을 시작하고 나서 충격적인 사실을 발견했습니다. 하루에 "회의 준비"에 쓰는 시간이 실제 회의 시간보다 더 길었어요. 회의 시작 30분 전부터 자료를 찾고, 끝나고 30분 동안 정리하고… 회의 1시간에 전후 작업 1시간. 이걸 눈으로 확인하고 나니까 회의 방식 자체를 바꾸게 됐습니다. 데이터가 행동을 바꾼다는 걸 몸소 체험한 셈이죠.
기본 구조 설계 — 종이를 그대로 웹으로 옮기자
종이 플래너의 구조
처음부터 거창하게 만들 생각은 없었습니다. 매일 쓰던 종이 플래너를 최대한 비슷하게 웹으로 옮기는 게 첫 번째 목표였어요. 기능을 잔뜩 넣고 싶은 유혹이 계속 있었지만 참았습니다. 사이드 프로젝트가 망하는 가장 흔한 이유가 바로 스코프 크리프(Scope Creep)이니까요.
종이 플래너의 구조는 이랬습니다.
왼쪽에 시간이 5 AM부터 1 AM까지 적혀있고, 가운데에 PLAN 칸 4개가 15분 단위로 나뉘어 있습니다. 오른쪽에는 DONE 칸 4개가 있어서 실제로 한 일을 기록해요. 상단에는 날짜와 BIG 3(오늘의 핵심 목표 3가지)를 적고, 하단에는 Brain Dump(할 일 목록)와 자유 메모를 적는 공간이 있습니다.
이걸 HTML 테이블로 구현했습니다. 한 행이 1시간이고, 15분 단위로 4칸씩 나눠서 PLAN 4칸 + DONE 4칸 + 시간 라벨 = 총 9열 구조입니다. 5 AM부터 다음날 1 AM까지 21행이에요. 이 구조가 나중에 오버레이형으로 전면 개편되지만(4편 스포일러), 처음에는 이게 최선이었습니다.
색상 시스템 — 형광펜을 디지털로
종이에서는 형광펜으로 색을 칠했습니다. 웹에서도 똑같이 8가지 파스텔 색상을 준비했어요.
노랑은 점심/저녁 같은 식사 시간, 초록은 회의와 미팅, 파랑은 출근 관련, 분홍은 개인 일정, 보라는 취침, 주황은 기타 잡무, 민트는 퇴근 관련, 카키는 예비용입니다. Brain Dump에 할 일을 적으면 자동으로 색상이 배정되고, 타임그리드에서 해당 색으로 블록을 칠하는 방식이에요.
색상을 고를 때 가장 신경 쓴 건 "파스텔 톤"입니다. 형광색처럼 눈이 아픈 색이 아니라, 종이 플래너의 부드러운 느낌을 살리고 싶었거든요. 나중에 DONE을 표시할 때는 같은 색의 진한 버전을 사용해서, 한눈에 "계획 vs 실행"이 구분되도록 설계했습니다.
Alt: "5AM부터 1AM까지 파스텔 색상 블록으로 구성된 타임박싱 웹앱 타임그리드 UI 목업"
핵심 기능 구현 — 드래그, 팝업, 그리고 DONE
드래그로 시간 블록 칠하기
이 웹앱의 핵심 기능입니다. 마우스로 PLAN 칸을 쭉 드래그하면 시간 범위가 선택되고, 손을 떼면 팝업이 뜨면서 할 일을 고르고 색을 칠합니다.
처음에는 셀 하나하나 클릭하는 방식이었는데, 1시간짜리 일정을 등록하려면 4번 클릭해야 했습니다. 너무 비효율적이라서 드래그로 바꿨더니 훨씬 직관적이었어요. 3칸을 쭉 드래그하면 자동으로 "45분" 시간 블록이 만들어집니다. 터치도 지원해서 모바일에서도 손가락으로 드래그하면 블록이 칠해져요. (이 터치 지원 때문에 나중에 5편에서 꽤 고생하게 됩니다.)
구현 자체는 mousedown → mousemove → mouseup 3단계 이벤트 흐름인데, 여기에 터치까지 합치면 touchstart, touchmove, touchend까지 6개 이벤트를 관리해야 합니다. 생각보다 꽤 복잡해요. 특히 "드래그 중에 선택 범위를 실시간으로 하이라이팅하는 것"이 처음에 까다로웠는데, Claude한테 "드래그하면서 지나가는 셀에 실시간으로 배경색 넣어달라"고 했더니 깔끔하게 풀어주었습니다. 바이브 코딩의 힘이죠.
기본 항목 — 매일 반복되는 것들
매일 반복되는 일정은 기본 항목으로 등록해두었습니다. 🏢 출근(파랑), 🍚 점심(노랑), 🍽️ 저녁(주황), 🏠 퇴근(민트), 😴 취침(보라). Brain Dump에 적지 않아도 팝업에서 바로 선택할 수 있어요. 4자녀 아빠의 하루는 이 기본 항목들 사이에 아이 등원, 하원, 밥 먹이기 같은 일정이 빼곡하게 끼어드는 구조입니다.
DONE 토글 — 계획 vs 현실
PLAN을 세웠으면 실행 여부를 기록해야 의미가 있습니다. DONE 칸을 클릭하면 계획한 색상의 진한 버전으로 채워집니다. "이 시간에 계획대로 했다"는 뜻이에요. 계획과 다른 일을 했으면? 클릭 후 팝업에서 실제로 한 일을 선택하면 다른 색의 테두리로 표시됩니다.
하루가 끝나고 나서 PLAN과 DONE을 비교해보면 꽤 흥미롭습니다. 계획의 60%만 달성해도 나름 선방한 날이에요. 아이가 넷이면 변수가 워낙 많기 때문에, 60% 달성률도 현실적으로 충분히 높은 수치입니다.
길게 누르면 DONE을 취소할 수 있습니다. 실수로 잘못 누른 경우를 대비한 기능인데요, 이 "길게 누르기" 제스처가 나중에 모바일 최적화에서 상당한 골칫거리가 됩니다. 모바일에서 길게 누르기, 드래그, 일반 클릭을 동시에 인식해야 하는 상황이 오기 때문이에요. (5편에서 자세히 다룰 예정입니다.)
팝업 시스템
드래그가 끝나면 팝업이 뜹니다. 팝업에서는 계획 시간을 선택하고(15분, 30분, 45분, 1시간…), 할 일을 고릅니다(기본 항목 + Brain Dump 항목). 드래그한 범위에 따라 시간이 자동 설정되는 구조예요. 예를 들어 3칸을 드래그하면 "45분"이 미리 선택된 상태로 팝업이 열립니다.
Alt: "종이 타임박싱 플래너와 디지털 웹앱 타임박싱 비교 일러스트레이션"
삽질 포인트 — 여기서부터가 진짜입니다
팝업이 열리자마자 닫히는 미스터리
이건 꽤 당황스러운 버그였습니다. 드래그를 끝내면 팝업이 떠야 하는데, 열리자마자 바로 닫혀버려요. 마치 유령이 클릭하는 것 같은 현상이었습니다.
원인은 이거였습니다. 드래그가 끝나면 mouseup 이벤트 직후에 click 이벤트가 자동으로 발생합니다. 그런데 팝업 오버레이의 클릭 핸들러가 "바깥 클릭하면 닫기"로 설정되어 있어서, 팝업이 열린 직후 이 유령 클릭이 "바깥 클릭"으로 인식돼버린 거예요.
해결은 의외로 간단했습니다. 팝업이 열린 시각을 기록하고, 300ms 이내의 오버레이 클릭은 무시하도록 가드를 넣었어요.
var _popupOpenedAt = 0;
function closePopupOutside(e) {
if (e.target === overlay && Date.now() - _popupOpenedAt > 300) closePopup();
}고작 세 줄짜리 코드인데, 이게 없으면 드래그할 때마다 팝업이 안 열리는 치명적인 버그가 됩니다. 사소한 타이밍 이슈 하나가 전체 UX를 망칠 수 있다는 교훈을 얻었어요. 인프라 쪽에서는 "5초 타임아웃이 서비스를 살린다" 같은 이야기가 있는데, 프론트엔드에서는 300ms가 그 역할을 하는 셈입니다.
날짜 자동 입력과 달력 연동
페이지를 열면 오늘 날짜가 자동으로 입력됩니다. 2026. 03. 18 WED 형식으로요. 날짜 텍스트를 클릭하면 브라우저의 date picker가 열려서 다른 날짜로 이동할 수 있습니다.
구현은 <input type="date">를 숨겨놓고, 텍스트 클릭 시 showPicker()를 호출하는 방식입니다. 모바일에서도 네이티브 달력이 뜨기 때문에 별도의 달력 라이브러리 없이도 깔끔하게 동작해요. 라이브러리 의존성 하나라도 줄이는 게 장기적으로 유지보수에 이득입니다. 인프라 엔지니어 특유의 의존성 최소화 습관이 여기서도 적용된 셈이죠.
Alt: "팝업 300ms 타이밍 버그를 해결하는 순간을 표현한 개발자 일러스트"
첫 번째 결과물 — 새로고침하면 다 날아가는 MVP
여기까지 만들고 나니 기본적인 타임박싱은 할 수 있는 상태가 됐습니다.
브라우저에서 열면 오늘 날짜의 타임테이블이 나오고, 드래그로 PLAN을 세우고, 클릭으로 DONE을 기록합니다. BIG 3에 오늘의 핵심 목표를 적고, Brain Dump에 할 일을 쭉 적을 수 있어요.
아직 데이터 저장이 안 돼서 새로고침하면 전부 날아갑니다. MVP 중에서도 아주 미니멀한 MVP예요. 하지만 "종이를 웹으로 옮기겠다"는 첫 번째 목표는 달성했습니다. 여기서 중요한 건, 완벽하지 않아도 일단 돌아가는 걸 만들었다는 점이에요. 사이드 프로젝트는 완벽을 추구하는 순간 끝없이 미뤄집니다. 일단 만들고, 쓰면서 고치는 것이 훨씬 빠르다는 걸 다시 한번 느꼈습니다.
이 프로젝트에서 배운 것
첫 번째, HTML 테이블이 생각보다 강력합니다. 타임그리드처럼 정형화된 레이아웃에는 div 지옥보다 테이블이 오히려 깔끔해요. CSS Grid나 Flexbox도 좋지만, 때로는 오래된 기술이 딱 맞는 경우가 있습니다.
두 번째, 드래그 구현은 간단해 보이는데 생각보다 복잡합니다. 마우스 3개 이벤트 + 터치 3개 이벤트 = 6개 이벤트를 동시에 관리하면서 상태를 추적해야 해요. 그래도 Claude와 대화하면서 하니까 "이거 어떻게 하지?"에서 멈추는 시간이 확 줄었습니다.
세 번째, 바이브 코딩의 핵심은 "대화"입니다. AI한테 한 번에 완벽한 결과를 기대하면 안 됩니다. "이거 해줘 → 결과 확인 → 이 부분 수정해줘 → 왜 이렇게 됐지? → 이해했어, 그러면 이렇게 바꿔줘" 이 루프를 반복하는 거예요. 마치 옆에 앉아있는 동료한테 화이트보드 그리면서 설명하는 것과 비슷합니다.
네 번째, 사이드 프로젝트는 일단 돌아가게 만드는 게 첫 번째입니다. 새로고침하면 데이터가 날아가는 웹앱이라도, 일단 만들어놓으면 다음 단계가 보입니다.
다음 편: [Homelabs] Claude와 함께 타임박싱 웹앱 만들기 #2 — Proxmox LXC에 Nginx + PocketBase로 서버 구축하기
👉 #1화 — 타임박싱이란? 앱 만들게 된 이유
👉 #2화 — PocketBase + Nginx + Proxmox 서버 인프라 구축
👉 #3화 — 멀티유저 인증과 데이터 동기화
👉 #4화 — 전면 리디자인: 오버레이형 통합 레이아웃
👉 #5화 — 모바일 최적화: 터치와의 전쟁
👉 #6화 — PWA: 웹앱을 앱처럼 쓰는 마법
👉 #7화 — 가족끼리 일정 공유
👉 #8화 — 가족끼리 일정 공유
