터미널에서 에이전트와 함께 코드를 만들며 배운 것들, 실제로 출시한 것들, 그리고 나만의 agents.md 워크플로우.
지난 4개월 동안 30억 토큰을 썼다. 전부 터미널을 통해서였고, 내가 스스로는 작성할 수 없는 코드를 에이전트가 써 내려가는 걸 지켜봤다.
사람들은 나를 ‘바이브 코더(vibe-coder)’라고 부를지도 모른다. 하지만 그 말은 이 작업에 들어가는 어떤 기술(스킬)도 놓치고 있는 표현이라고 생각한다. 2019년 무렵(내가 노코드 교육 회사를 시작했고 나중에 Zapier에 인수됐던 때) ‘노코드’라는 용어가 그랬던 것처럼.
나는 코드를 읽지 않는다. 하지만 에이전트의 출력은 집요할 정도로 읽는다. 그러면서 코드가 어떻게 동작하는지, 프로젝트가 어떻게 굴러가는지, 어디서 실패하고 어디서 성공하는지에 대한 지식을 엄청나게 흡수하고 있다.
그게 내가 생각하는 ‘프로그래밍을 배우는’ 방식이다. 새로운 기술 계층(the new technical class).
지난 몇 달 동안 내가 실제로 출시한 것들 몇 가지:
개인 사이트. 내 개인 사이트를 개편해서 터미널 CLI 도구처럼 보이게 만들었다. 올해 초에 했던 이전 시도보다 훨씬 나았다.
피드(Feed). 트위터에서 Factory 언급, 우리 서브레딧 글, GitHub 이슈를 추적하는 간단한 소셜 트래커를 만들었다. 오픈소스이고 별이 100개 이상 달렸고, 여러 사람이 포크/클론해서 자기 용도로 쓰고 있다.
Factory Wrapped. 우리 ‘wrapped’ 제품의 첫 버전을 만들었다. 팀에 보여줬더니 좋아해서 실제 제품에 포함하자고 했고, 지금은 라이브로 운영 중이다. 새 가이드를 추가하고 구성을 재배치하는 작업까지. 엄밀히 말하면 코딩처럼 느껴지지 않을 수도 있지만, 내겐 코딩이다. 과정은 똑같다.
커스텀 CLI들. 몇 가지 CLI를 만들었다. 예를 들어 Pylon CLI를 만들었는데 팀에서 고객지원 문의를 처리하는 데 쓰기 시작했다. 사용자가 계정에 토큰을 추가하는 걸 돕는 CLI도 만들었다. 그리고 Linear CLI, Gmail CLI도.
크립토 트래커. 나는 동적인 데이터(금융, 날씨, 피트니스, 단백질 접힘 등)에서 긍정/부정/중립 신호를 정확히 예측하는 회사에 투자했다. 그래서 그 예측에 기반해 숏/롱 포지션을 자동으로 열고 닫는 트래커를 만들었다. 미니 헤지펀드 같은 느낌.
Droidmas. 12일 동안 12개의 실험 또는 게임을 만들었다. 트위터에서 사람들이 이야기하는 다양한 테마—메모리, 컨텍스트 관리, 바이브 코딩 같은 것들—를 건드렸다.
AI가 연출하는 비디오 데모 시스템. 프롬프트 하나를 주면 영상이 만들어진다. ghostty를 열고, 커맨드를 실행하고, 브라우저 같은 다른 창도 열고, 화면을 녹화한다. 스스로 감독/프로듀서/편집자 역할을 한다. 에이전트는 녹화 중에 무슨 일이 일어나는지 보고 있고, 상황에 따라 반응한다. 이슈나 버그가 있거나 응답을 기다려야 하면 그렇게 한다. 이걸로 OpenAI가 게시한 비디오도 만들었다.
Droid Exec 기반 텔레그램 봇. 로컬 레포를 VPS와 동기화하고 레포와 챗봇처럼 대화하기 위해 만들었다. 최대한 CLI 경험을 메시징 앱에서 흉내 내려고 했다(텔레그램은 별로지만, WhatsApp Business 설정은 너무 번거로워서).
그리고 언급하지 않는 것들, 혹은 방치되어 죽어버린 것들까지 합치면 50개쯤 더 있다.
나는 CLI만 쓴다. 웹 인터페이스보다 터미널이 항상 우선이다. 일반적인 에이전트로서 더 강력하고, 작동 과정을 직접 볼 수 있기 때문이다.
뭔가 아이디어가 있거나, 불편이 있거나, 코드로 해결할 수 있을 것 같은 문제가 생기면(요즘은 거의 전부) Droid(Factory의 CLI)에서 새 프로젝트를 바로 띄운다.
처음에는 모델에게 몇 번 이야기하면서 내가 하려는 일에 대한 컨텍스트를 넣어주고, 그다음에는 spec 모드로 전환해서 무엇을 만들지에 대한 계획을 세운다.
spec 모드에서는 사실상 이것저것 다 따져 묻는다. 예를 들면 “이게 뭔지 모르겠는데?”, “왜 이걸 저것보다 써야 해?”, “이렇게 하면 안 돼?” 같은 질문들.
에이전트가 탐색할 문서 링크나 GitHub 레포도 붙여준다.
그다음엔 Opus 4.5를 autonomy high로 두고 그냥 돌린다. 스트림을 보면서 무슨 일이 일어나는지, 에러가 나는지 확인한다. 필요하면 중간에 끼어들어 질문하거나 다른 방향으로 안내한다.
서버를 띄우고, 테스트하고, 피드백을 주고, 반복한다.
그래서 나는 종종 ‘내 실력보다 앞서서’ 먼저 만들어버린다. 일단 만들고, 그 과정에서 생기는 빈틈과 이슈들이 내가 배울 기회가 된다. 이게 다른 레포들에서도 반복해서 보이는 시스템의 일부라면 템플릿화해서 처리해야 할까? 이런 내용은 내가 앞으로 작업할 다른 레포에서도 따라다니도록 agents.md에 넣어야 할까?
요즘은 나에게 가장 좋은 agents.md 셋업이 뭔지 찾는 데 더 많은 시간을 쓰고 있다. 이건 사실상 ‘사용 설명서’다.
로컬에 repos 폴더가 있다—내가 코딩한 모든 프로젝트가 들어간다. 그 repos 폴더 안에 agents.md가 있고, 새 레포를 만들 때마다 무엇을 해야 하고 하지 말아야 하는지, GitHub를 어떻게 쓰는지, 커밋은 어떻게 하는지 같은 걸 명시한다. 그리고 내 업무용 GitHub 계정을 쓸지 개인 GitHub 계정을 쓸지도.
테스트 실행. 엔드투엔드 테스트는 예전엔 별로 신경 쓰지 않았다. 하지만 지금은 모든 것에 엔드투엔드 테스트를 넣고 싶다. 내 현재 지식과 역량으로는, 만들고 테스트하는 과정에서 사실 “테스트가 있었다면 애초에 잡혔어야 할” 어이없는 버그들이 종종 나온다.
그리고 다른 사람들의 agents.md 파일을 자주 보면서 내가 가져올 수 있는 걸 찾는다. 매 세션이 더 매끄러워지도록 내 문서를 계속 개선하고 있다.
또 내가 만드는 모든 레포에 Droid GitHub 앱도 설치해 둔다. 그래서 GitHub에 배포할 때는 PR을 올려서 Droid가 리뷰하게 하고, Droid를 태그해서 커스텀 프롬프트로 스스로 수정하게 만들 수 있다. 이슈나 PR에서 트리거할 수도 있다.
이렇게 하면 폰으로도 코딩할 수 있고, 밖에 돌아다니다가도 새 기능을 추가할 수 있다. 텔레그램 봇과 조합하면 책상 앞이 아닐 때도 작업하기가 정말 쉽다.
Slack도 에이전트와 함께 쓴다. 레포마다 새 채널을 만들고 그때그때 할 일을 던진다. 새 아이디어가 생기면 채널을 또 만든다. Slack은 1인 제품(+ 에이전트들)로 정말 좋다.
Bash 커맨드. 한동안 변경 로그(changelog) 프로세스를 돌리다 보니 “아, 이게 매번 같은 과정이구나”가 확 와 닿았다. 마침내 ‘워크플로우’를 이해한 느낌이었다. 그래서 droid에게 슬래시 커맨드 플로우를 만들게 했고, 이게 내가 처음으로 제대로 사용한 슬래시 커맨드가 됐다. 여러 bash 커맨드를 실행하고, 모델에게 GitHub diff 읽기, 피처 플래그 뒤에 뭐가 있는지 확인하기, 새 기능/버그 수정 섹션에 올바르게 분류하기 같은 작업을 프롬프트로 시킨다.
그 후로 bash + CLI에 더 빠져들었다. MCP는 이제 잘 안 쓴다—대부분 MCP보다 CLI 버전을 쓴다. MCP가 컨텍스트를 잡아먹어서이기도 하지만, 대부분은 더 단순하다고 느낀다. MCP에 들어있는 도구 전부가 필요한 게 아니라 대개 몇 개만 필요하다. 그래서 Supabase, Vercel, GitHub은 MCP보다 CLI를 항상 쓴다.
난 종종 필요한 건 직접 CLI로 만든다. 예를 들어 내 이슈를 조회하고 데스크톱/웹 인터페이스를 열지 않고 터미널에서 모든 걸 처리하려고 Linear CLI를 만들었다.
VPS. 개념적으로는 알고 있었다—어딘가에 항상 켜져 있는 또 다른 컴퓨터 같은 거. 하지만 진짜 필요해지기 전까진 거기서 무엇을 해야 하는지 잘 몰랐다. 아직 배울 것도 많다. 하지만 지금은 크립토 트래커를 돌리면서 매분 데이터를 엄청나게 끌어오고 있고, 그게 항상 돌아가야 한다.
VPS는 Droid 텔레그램 봇을 쓸 때도 쓴다. SyncThing이라는 걸로 로컬 레포를 VPS에 동기화해서, 레포가 항상 최신 상태로 유지되고 내가 떠난 시점과 동일한 상태가 된다. 그래서 이동 중에도 바로 이어서 할 수 있다.
스킬(Skills). 좀 더 써보려고 노력 중이다. 지식 용도뿐 아니라 bash 커맨드 + CLI와 함께 쓴다. 루트 디렉터리에 두고 어떤 프로젝트든 가져다 쓸 수 있는 Gmail CLI가 있다. 시스템에서 Gmail이 필요할 때마다(나는 Gmail 트리아지 시스템을 쓴다) 그냥 그 CLI를 쓴다.
트위터에서 다들 Andrej Karpathy가 뭐 트윗하면 비슷한 말을 하긴 하지만, 이 말은 정말 공감됐다: 마스터해야 할 새로운 프로그래머블 추상화 레이어가 생겼다.
노코드 시절 내가 마스터하던 추상화 레이어는 Webflow, Zapier, Airtable 같은 드래그 앤 드롭 툴이었다. 그것들을 이어붙여서 진짜 소프트웨어처럼 보이게 만들었다(한계에 부딪히기 전까지).
하지만 지금은, 이걸 다 하기 위해 “코드를 처음부터 직접 쓰는 법”을 배워야 한다고 생각하는 대신, 내가 배워야 하는 건 사실 AI 에이전트와 일하는 법이다. 어떻게 프롬프트를 잘 쓰는지? 어떻게 올바른 컨텍스트를 주는지? 그리고 에이전트가 우리가 하는 일을 이해하는 데 어떻게 도움을 주는지, 조각들이 어떻게 맞물리는지, 내 시스템을 시간이 지나며 어떻게 개선할지?
에이전트, 서브에이전트, 프롬프트, 컨텍스트, 메모리, 스킬, 훅 같은 모든 것들을 포함해서.
나는 Peter Steinberger 같은 사람을 읽는다. 그는 ‘진짜’ 프로그래머이고 엄청난 속도로 계속 출시한다. 그리고 그의 글을 보면 시스템이 놀라울 정도로 단순하다. 그냥 모델과 대화하고, 일을 시키고, 추가 슬래시 커맨드나 서브에이전트, 훅, 스킬(물론 그는 스킬도 점점 쓰는 쪽으로 오고 있지만)에 크게 집착하지 않는다. 그걸 보면서 나도 초복잡 시스템이 없어도 된다는 허락과 자신감을 얻는다.
트위터를 보면 많은 사람들이 자기 시스템을 최적화하거나, 어쩌면 과도 최적화하고 있다. 나 같은 사람에겐 부담스럽게 느껴질 수 있다. 하지만 동시에 이게 아름다운 점이라고 생각한다: 완전히 커스터마이즈 가능한 시스템이라서, 원하는 대로 작동하게 만들 수 있다. Kieran처럼 20분짜리 커스텀 슬래시 커맨드로 플랜 모드를 돌릴 수도 있고, Peter처럼 그냥 모델과 대화만 할 수도 있다.
또 다른 엔지니어들을 따라가며 얻는 것은 오픈소스를 보고 클론해서 직접 써보고, 개선하거나, 일부만 떼어 내 것으로 만드는 것이다. 예를 들어 Peter가 최근에 만든 YouTube 요약 도구를 나는 가져와서 Chrome 확장 부분을 제거하고 CLI로만 남겼다. 그래서 이제 어디서든 그걸로 대화하듯 쓸 수 있다.
그리고 Mario처럼, 그의 MCP 글에서 “MCP보다 CLI”를 이야기하는 걸 보고 bash와 CLI 쪽으로 더 들어가야겠다는 계기가 됐다.
나는 수만 명이 프로덕션에서 쓰는 제품을 만드는 게 아니다. 그래서 버그도 있고 이슈도 있고, 나도 많이 부딪힌다. 하지만 그건 “지금 내 역량의 한계”가 아니라 “내 지식의 빈틈”이라는 걸 상기시켜 준다.
내 역할은 그 빈틈을 찾는 것이다. 그리고 생각한다: 어떻게 하면 이런 일이 다시는 안 생기게 할까? 또는 다시 생기더라도 내가 시스템의 이 부분을 충분히 이해해서 잡아낼 수 있게 하려면 어떻게 해야 할까?
에이전트로 코딩을 처음 시작했을 때의 아주 단순한 질문들조차 그랬다. 예를 들면 동적 데이터가 있고 여러 사용자가 쓰게 하려면 왜 GitHub Pages를 못 쓰는지? 프로그래머에겐 너무 쉬운 사실이다. 하지만 나는 무언가를 만들고 있었고, 도구가 허용하는 것과 다른 걸 만들려다 보니 그걸 배웠다.
그래서 “그럼 뭘 해야 하지?”라고 묻게 된다. 사실 그냥 모델에게 물으면 된다. 모델은 내가 모르는 걸 알고 있다. 계속 물으면 된다. 항상 참을성 있게 어깨 너머에서 도와주는, 전문가 프로그래머다. agents.md에 “나는 프로그래머가 아니니 아주 쉽게 설명해 달라”고 넣어도 된다. 원하는 대로 정확히 조정하면 된다.
나는 우리 제품에도 개선을 기여했다—단순한 것들이지만 개선은 개선이다. Factory에는 매우 경험 많고 뛰어난 엔지니어 팀이 있고, 그들을 지켜보고 PR을 보면서 많이 배운다. 내부적으로 런치 앤 런(lunch and learn)도 있어서 “새 기능 스코프를 이렇게 잡는다”, “버그는 이렇게 고친다” 같은 내용을 공유하는데 정말 도움이 됐다.
그래서 이 전체가 나에게는 큰 학습 경험이고, 나는 ‘코딩을 배우는 것’, 혹은 ‘코드와 함께 일하는 법을 배우는 것’을 정말 즐기고 있다.
나는 인생에서 코딩을 여러 번 배우려 했다. 매번 “이 문자들을 치고 엔터를 누르세요. 헬로 월드 보이죠?” 같은 방식이었다. 이걸 하고, 저걸 하고, 그러면 이런 일이 일어난다…
그걸 배우는 게 도움이 됐을 수도 있다. 하지만 지금의 현실과는 너무 다르다고 생각한다.
내가 지금 만든 것들을 만들기 위해, 만약 그 옛날 방식의 길을 택했다면, 스스로 코드를 쓸 수 있을 만큼의 단계에 이르기까지 몇 달, 몇 년은 코딩을 해야 했을 것이다.
대신 나는 ‘시스템 사고’ 관점에서 접근한다. 코드로 만든 프로젝트가 어떤 시스템으로 구성되는지 이해하는 것. 그건 내가 노코드 교육 회사를 운영할 때 우연히 배웠다. Webflow는 프런트엔드, Zapier는 API 라우트이자 연결 조직과 데이터 흐름, Airtable은 데이터베이스… 이런 시스템을 이미 배웠고, 그게 오늘날 조각들을 이해하는 데 도움을 주고 있다고 생각한다.
배울 게 정말 많다. 그리고 종종 트위터에서 누군가 무언가를 올리면 “저게 뭔지, 뭘 할 수 있는지 모르겠는데… 그래도 갖고 놀 수는 있겠다”라고 생각한다.
이제는 어떤 소프트웨어도 나에게 ‘도달 불가능’하게 느껴지지 않는다. 그냥 git clone 하고 “이게 대체 뭘 하지?”라고 묻는다. “오케이, 내가 생각하던 게 있었는데—이게 그거랑 관련이 있나?” 전부 탐험이다. 너무 재밌다.
내가 ‘바보 같은 질문’을 떠올리는 순간이 수도 없이 많다. 나한테만 바보 같거나, 다른 프로그래머라면 절대 묻지 않을 질문들. 하지만 물어도 된다. 누가 보고 있는 것도 아니고, 누가 멍청하다고 쏘아붙이는 것도 아니고, 틀린 말을 했다고 깎아내리는 사람도 없으니까.
예를 들어 “왜 이렇게 많은 프레임워크, 다양한 종류의 프레임워크를 쓰지?” 프레임워크는 인간이 코드를 쓰기 위한 추상화다. 그런데 LLM이 엄청 똑똑하다면, 왜 더 단순한 코드로 못 쓰지? 의존성도 줄이고, 버그가 생길 수 있는 표면적도 줄이고… 이건 바보 같은 생각일까, 좋은 생각일까?
알아보면 그게 꼭 바보 같은 생각만은 아닐 수 있다. 다만 모델이 학습한 프로젝트들이 많고, 그래서 보통 특정 프레임워크로 구축되는 경우가 많다는 걸 이해하게 된다.
이렇게 나는 내가 원래 있을 자격이 없다고 느꼈던 코드 세계, 엔지니어링 세계에 대한 이해를 쌓아간다. 하지만 이제는 그 세계의 일부가 됐다.
그래, 바이브 코딩이라고 부를 수도 있다. 하지만 나는 바이브 코딩이라는 말이 핵심을 놓친다고 생각한다. 나는 시스템을 배우려는 중이다. 무슨 일이 일어나는지 진짜 이해하려 한다. 어떻게 개선할지, 어떻게 새로운 시대의 프로그래머가 될지, 이 새로운 기술 계층이 무엇인지.
이게 가장 흥미로운 부분이라고 생각한다. 나는 단정적으로 비기술적이라고 말할 수도 없고, 그렇다고 프로그래머라고 부를 수도 없다. 그리고 그렇게 부르고 싶지도 않다. 나는 이 새로운 기술 계층의 일부인데, 그게 뭐라고 불려야 하는지 모르겠다. 하지만 ‘바이브 코딩’은 노코드가 그랬던 것처럼 부정적인 뉘앙스를 준다.
어떤 사람들은 이 새로운 프로그래밍 방식이 게임 같다고 한다. 사람들이 자주 언급하는 게임이 Factorio인데, 나는 해본 적 없다. 나는 게이머도 아니다.
하지만 이 패러다임은 내게 정말 게임처럼 느껴진다. 결과물로는 내가 만들고 싶은 걸 만들고 있다. 많은 것들은 GitHub에도 안 올라가고, 라이브로 배포되지도 않는다. 시스템이나 주제의 일부를 탐색하는 실험일 뿐이다. 어떤 것들은 공개되고 다른 사람들이 사용하기도 한다—어떤 CTO는 내 개인 사이트를 포크해서 자기 사이트로 썼다. (나한텐) 완전 ‘빅보스’급 사건이었다.
누군가 “예를 들어 React 잡기(grab) 툴을 만들었어요”라고 올리면, “오케이 멋지네. 나도 내 걸 만들 수 있을까? 왜? 그냥 해보고 싶어서.” 이런 식이다. 이건 되게 좋아 보이는데, 그래도 그냥 내가 원해서 탐험하는 거다.
지금까지 떠올렸던 모든 아이디어는 실행해 볼 수 있고, 탐험해 볼 수 있으며, 꼭 ‘좋은’ 아이디어일 필요도 없다. 하면서 배우면 된다.
예전에는, 코딩을 배워서 내가 생각한 어떤 큰 아이디어의 정말 허접한 버전을 만들고, 그런데 아무도 원하지 않으면, 그 아이디어에 너무 감정적으로 투자돼 있어서 그냥 버리기가 어려웠을 것이다.
노코드 시절엔 큰 아이디어의 버전을 한 시간, 두 시간, 주말 정도에 만들 수 있었다. 아무도 좋아하지 않고, 돈을 내지 않고, 별로라면 그냥 버릴 수 있었다. 결국 누군가에게 좋은 것이 되지 못할 작업에 내 시간과 에너지를 크게 쓰지 않아도 됐다.
지금도 똑같다고 느낀다. 소프트웨어가 폭발적으로 늘어날 것이다. 많은 것들은 좋지 않을 수도 있지만, 이미 훌륭한 것들도 많다. 전문가 프로그래머들이 미친 듯이 많은 프로젝트를 ‘출시’하고 있고, 그게 다 좋은 프로젝트들이다. 우리는 엄청난 수의 코드 프로젝트를 갖게 될 것이고, 그걸 쓰고, 클론하고, 수정하고, 리믹스할 수 있다.
직접 코딩을 배워야 하거나, 파일을 읽거나, 파일을 쓰거나 하는 것보다 훨씬 시간이 덜 든다. 피드백 루프가 더 빠르고, 프로세스가 더 빠르다. 언제든 뭐든 할 수 있고, 계속해서 산출물을 뽑아낼 수 있다.
코드를 배우는 방법은 내 역량보다 앞서서 만들고, 실패하며 전진하는 것이다.
오늘 비기술적인 사람들 중에서도 이 세계에 들어오고 싶은 사람, 이런 걸 하고 싶은 사람이라면 누구나 할 수 있다고 생각한다. 필요한 건 그걸 해도 된다는 ‘허락’이다. 가지고 놀아도 된다는 허락. 놀이처럼 생각해야 한다.
Droid 같은 CLI 에이전트에 가입하라. 개인 웹사이트를 만들고 싶다고 해보자. 작은 RSS 피드 트래커, 작은 투두 리스트, 작은 운동 앱… 무엇이든 좋다. 그냥 띄워서 시작하면 된다. 마주치는 작은 막힘, 버그, 이슈마다 질문하라. “왜 이게 나왔지? 왜 이런 에러가 났지?” 네가 코딩을 모른다는 걸 알고 있으니, 버그에 너무 매달릴 필요도 없다—전문가 프로그래머도 늘 버그를 만난다.
또 다른 곳으로 가져갈 수도 있다. ChatGPT나 Claude 같은 곳에 가져가서 다른 모델로 다른 관점을 얻을 수 있다. 선택지는 늘 많고, 변형도 많다.
도구도 너무 많고 옵션도 너무 많다. 결국 하나만 골라서 계속 써라. 그 시스템을 익혀라. 다 비슷해 보이고, 비슷하게 작동한다.
물론 나는 Factory에서 일하니 Droid를 쓴다. 하지만 그건 모델 출력도 제일 좋기 때문이다(모델 무관성 만세).
결국 내가 도구에서 원하는 건 이거다: 가장 적은 시간에, 가장 적은 문제로, 내가 최대한 멀리 갈 수 있게 해주는가? 도구를 쓰는 데 내가 더 많은 일을 해야 할수록 더 어렵다.
IDE 같은 것들—여러 개를 써봤고, 예전에 특정 IDE를 오래 쓰기도 했다. 하지만 너무 많은 부가 기능이 있다. 난 필요도 없고 관심도 없다. 난 그냥 모델과 대화하고, 코드가 써지길 원한다. 마크다운 파일을 살펴봐야 한다면, 최근에 알게 된 터미널 파일 매니저를 쓰면 된다. 거기서 훑어보거나, 내가 요즘 쓰는 Zed로 열어서 마크다운을 보기/편집한다. 예를 들어 changelog라면 잠깐 손보고 다시 CLI로 돌아가서 그다음부터는 그냥 쭉 돌린다.
그리고 내가 놓치고 있다고 느끼는 어떤 도구나 기능이 있으면, 직접 만들어 보려고 한다—예를 들면 터미널 파일 뷰어 같은 것.
이 모든 건 나에게 정말 큰 학습 경험이고, 나는 이걸 정말 즐기고 있다. 만들고, 실패하며 전진하고, 계속 출시하라.
