<div id="readability-page-1" class="page"><div><p>요즘 나는 거의 대부분의 일을 바이브로 코딩한다. 그리고 이번달부터는 거의 모든 업무(개인+회사)를 <a target="_blank" rel="noopener noreferrer" href="https://lylo-ai.vercel.app/">라일로(Lylo)</a>에서 작업하고 있다. 이유는 단순하다. 사용하기 편하고 맥락 파악이 쉽다. 이슈를 나누고, 기록하고, 이어가기도 쉽다.</p><p>바이브로 일 하다보면 순간순간 떠오르는 아이디어를 적어야한다. 예전처럼 메모장을 열 필요도 없고, 그냥 대화하는 세션에서 "갑자기 생각난건데 이거저거 이슈로 좀 만들어놔봐. 이따 살을 붙일께" 이렇게 생각을 캡쳐한다. 그리고 시간이 지나서 캡쳐된 이슈를 꺼내본다.</p><p>그럼 십중 팔구 뭔소린지 모른다. 왜냐면 내가 던진 개떡같은 한마디가 찰떡같이 소설로 만들어놨기에 나는 또 읽어보고 물어본다. "이거 무슨뜻이야?" / "아.. 이해했어. 이거라는거지" / "좋아. 그럼 이렇게 하자"</p><p>이렇게 살이 붙다보면 아이디어는 커진다. 그리고 하나의 거대한 피처가 기획된다. 예전같았으면 거대한 기획은 3일뒤에 열어보고 아.. 아니네 싶으면 대부분 접었다. 하지만 요즘은 그냥 한다. 오히려 3일까지 기다릴 여유가 없다. 3일이 지나면 오만가지가 이슈가 쌓인다.</p><h2 id="아이디어-관리하기">아이디어 관리하기</h2><p>오늘 내가 소개하는 라일로의 핵심 기능은 이슈관리다. 그동안 개밥 먹기를 열심히 하기도했고, 클로드 CLI를 쓰면서 불편하고 아쉬웠던 것들을 한풀이 하듯이 다 우겨 담았다. 참고로 타임라인 뷰는 v0.15+이상 버전을 설치해야한다.</p><p><img alt="스크린샷 2026-10-08 오전 12.14.13" loading="lazy" width="3298" height="1660" decoding="async" data-nimg="1" sizes="(max-width: 768px) 100vw, 768px" src="https://www.miconblog.com/_next/image?url=https%3A%2F%2Fimhvrmoopjoxneixdcmc.supabase.co%2Fstorage%2Fv1%2Fobject%2Fpublic%2Fmiconblog-images%2F2026%2F10%2F20f40b199fd81de882c6aa1c1c4102c7.png&amp;w=3840&amp;q=75"></p><p>관리되는 모든 이슈는 마크다운 파일 하나로 관리된다. 그리고 모든 이슈는 클로드 세션과 대화를 통해서 만들어지고 관리된다. 내가 직접 파일을 작성하는 일은 없다.</p><h2 id="개발-비용이-싼데-계획이-필요한가">개발 비용이 싼데 계획이 필요한가?</h2><div><p>과거 개발 비용은 매우 비쌌다. 특히 개발자의 몸값 만큼이나 비싼 개발비용은 늘 병목이었다. 비싼 비용이기에 관리와 계획이 필요했다. 때론 추정도 했지만 죄다 실패했다. 이해관계자 간의 의견조율도 필요했다. 그래서 지라에선 에픽을 타임라인 뷰에 올리고 이해관계자들과 소통하는데 사용한다. 그래서 지라의 타임라인 뷰는 비싼 비용을 컨트롤하기 위한 계획에 가깝다. </p><p>하지만 바이브 시대에 병목은 어디인가? 바로 무엇을 만들지 결정하는 기획의 영역과 AI 가 제대로 만들었는지 확인하는 검수 영역이다.  라일로는 이 병목을 빠르게 찾고 해소하는데 방점이 찍혀있다. 따라서 타임라인 위에 찍히는 칸트차트는 계획이 아니라 기록이다. 이 이슈가 언제 만들어졌고, 어떤 상태에서 지속되고 있는지를  보여준다. </p><p>이슈들의 묶음인 마일스톤은 이슈를 구체적화하고 성격을 드러내는데 사용된다. 이슈가 많아질수록 계획은 구체화되고, 다시 분화된다.  구체화된 일감은 개발도 쉬워진다. 이런 맥락에서 이슈 관리는 계획보다는 내가 해야할 일을 빨리 찾고 지속적으로 아이디어를 이어가기 위해 만들어졌다. 특히 2가지를 고민했다. 하나는 의존성이고 또 하나는 지연된 일감을 찾는 일이다.</p></div><h3 id="의존성-관리">의존성 관리</h3><p>현재 AI 모델은 LLM 특성상 컨텍스트 윈도우가 제한적일수밖에 없다. 즉, 이슈 파일을 적절하게 짤라서 컨텍스트로 넣어줘야한다. 실제로 작은 컨텍스트로 짤라서 위임할때가 더 빠르다. 문명(AI)이전에도 개발자가 하는 주요 업무중에 하나는 큰 이슈를 잘게 짤라서 관리하는 일이었다.</p><p>마크다운 파일로 관리되는 이슈는 의존성에 따라서 선행과 후행 이슈를 가지게 된다. 그리고 이렇게 의존성을 가진 이슈들을 연결해서보면 얼마나 많은 이슈들이 서로 엮여있는지 쉽게 파악된다.</p><p><img alt="스크린샷 2026-10-08 오전 12.43.55" loading="lazy" width="1510" height="948" decoding="async" data-nimg="1" sizes="(max-width: 768px) 100vw, 768px" src="https://www.miconblog.com/_next/image?url=https%3A%2F%2Fimhvrmoopjoxneixdcmc.supabase.co%2Fstorage%2Fv1%2Fobject%2Fpublic%2Fmiconblog-images%2F2026%2F10%2F59edc4677497e4b25e0136ca5f881cb2.png&amp;w=3840&amp;q=75"></p><p>처음엔 이런 의존성 그래프 하나만 있어도 일의 효율이 올랐다. 하지만 내가 작성한 이슈가 아니라면 어떨까? AI가 작성한 이슈는 때론 뭔소린지 모를때가 있다. 그래서 하나하나 들여다보고 있으면 가끔 현타가 온다. 내가 뭐하고 있는거지? 이게 맞나? 조각조각 낸 이슈는 마치 퍼즐조각같다.</p><p>퍼즐은 결국 맞춰봐야한다. 그래서 의존성을 가진 이슈들은 모두 긁어서 컨텍스트로 던진다. "야 이거 다 읽어서 하나의 html로 만들어줘. 이해가 안되니까 그림으로 그려줘봐"</p><p>이렇게 하나의 청사진으로 만들어놓으니 그제서야 의미파악이 가능해진다. 읽어보다 이건 아니지 싶은거 이야기한다. "야 이건 아닌거 같아. 이렇게 하자" 그렇게 내 의사결정이 반영되면 드디어 기획서가 완성된다. 이런 방식은 내가 그동안 클로드와 일하면서 매우 효과적이었다. 나는 이것을 블루프린트 기획이라 부른다.</p><p><img alt="스크린샷 2026-10-08 오전 12.14.39" loading="lazy" width="1148" height="868" decoding="async" data-nimg="1" sizes="(max-width: 768px) 100vw, 768px" src="https://www.miconblog.com/_next/image?url=https%3A%2F%2Fimhvrmoopjoxneixdcmc.supabase.co%2Fstorage%2Fv1%2Fobject%2Fpublic%2Fmiconblog-images%2F2026%2F10%2Fb01ec18ce6deccd38e3e1fe2a2c4c46f.png&amp;w=3840&amp;q=75"></p><p>블루프린트는 연결된 이슈를 모두 읽어서 하나의 청사진(html)을 만든다. 클로드의 아티펙트와 사실 동일한데, 아티펙트는 클로드 서버에서 만들어지고 공유에 방점이 찍히 녀석이라 내 로컬에서 나만 볼꺼면 블루프린트 한장이면된다.</p><p><img alt="스크린샷 2026-10-08 오전 1.05.12" loading="lazy" width="2204" height="1822" decoding="async" data-nimg="1" sizes="(max-width: 768px) 100vw, 768px" src="https://www.miconblog.com/_next/image?url=https%3A%2F%2Fimhvrmoopjoxneixdcmc.supabase.co%2Fstorage%2Fv1%2Fobject%2Fpublic%2Fmiconblog-images%2F2026%2F10%2Fd3f8eacf0e70408b81eb9f97c8832b37.png&amp;w=3840&amp;q=75"></p><p>블루프린트에는 내가 이해할수있는 그림과 설명 그리고 결정해야할 안건이 잘 정리되어 있어서 이것만 있으면 거대한 이슈 뭉치도 쉽게 풀어낼수있다. 특히 이슈간의 의존관계와 의사결정을 모두 풀어냈기 때문에 순서대로 그냥 실행만하면 충돌없이 문제가 해결된다.</p><p>요즘 시대에는 충돌도 사람이 아닌 AI가 하겠지만 AI에게 맡기면 생각보다 큰 비용을 치를 때가 있다. 그래서 왠만하면 충돌이 피하는게 시간과 토큰을 아끼는 지름길이다.</p><h3 id="지연된-일감-찾기">지연된 일감 찾기</h3><p>개발 작업이 끝나면 리뷰한다. 리뷰는 내가 직접 빌드해서 확인하는 경우도 있고, AI와 함께 크로스 체크하는 경우도 있다. 요즘은 개발하려고 기획한 시간보다 검수하는 시간이 더 오래 걸리는 경우도 많다. 예를 들면 어떤 리뷰 단계에서는 다른 이슈가 더 들어오거나 실제 데이터가 쌓여서 확인해야하는 조건이 있다. 그래서 2주간 리뷰 상태가 유지되는 경우도 있다.</p><p><img alt="스크린샷 2026-10-08 오전 12.30.51" loading="lazy" width="1764" height="584" decoding="async" data-nimg="1" sizes="(max-width: 768px) 100vw, 768px" src="https://www.miconblog.com/_next/image?url=https%3A%2F%2Fimhvrmoopjoxneixdcmc.supabase.co%2Fstorage%2Fv1%2Fobject%2Fpublic%2Fmiconblog-images%2F2026%2F10%2F828a6f3fa592fd155e9345a887d9eb6e.png&amp;w=3840&amp;q=75"></p><p>이럴때 리뷰 상태 이슈만 필터 해놓고 보면 누가 오래머문 녀석이 되고, 언제부터 리뷰중인지도 한눈에 파악된다. 나는 그런 녀석들을 골라서 먼저 해결한다.</p></div></div>

just quit your job

과거 개발 비용은 매우 비쌌다. 그래서 개발은 관리와 계획이 필요했다. 하지만 바이브 코딩 시대에 개발 비용은 매우 싸다. 계획하기도 전에 이미 개발이 끝나있다. 이런 시대에 계획이 과연 필요할까?

바이브 코딩할때 타임라인 뷰가 중요한 이유

댓글