Kai Good

바이브코딩 중독 단계별 장비 세트 🟢 1단계 — 호기심 스마트폰 + ChatGPT “앱도 만들어준다고?” 🟡 2단계 — 입문 아무 노트북 + 마우스 진짜 돌아만 가면 됨. “어? 되는데?” 🟠 3단계 — 몰입 맥북 에어 + 27인치 모니터 + 괜찮은 키보드 “노트북 화면은 좀 좁네.” 🔴 4단계 — 중독 맥북 프로 + 듀얼 4K 모니터 + 기계식 키보드 + MX Master “창을 많이 띄워야 해서 어쩔 수 없음.” 💀 5단계 — 말기 맥 스튜디오 + 49인치 울트라와이드 + 커스텀 키보드 + NAS + UPS “이제 인프라도 직접 관리하는 게 낫겠는데?” 앱 매출: 0원 장비 투자: 700만원 그리고 쿠팡에서 서버랙 보고 있음.

혼자 만든 앱 10개, 이번 달도 무료로 홍보합니다! 바이브코딩 커뮤니티 바이브크루의 11월 홍보 배너를 교체했습니다. 벌써 세 번째네요 ㅎㅎ 키보드, AI 뉴스, 면접 연습, 실시간 번역 자막, HTML 편집, 게임까지. 다들 혼자 만들었다는 게 신기할 정도로 수준이 높아졌어요. 배너만 걸고 끝내지 않고 제 X와 Threads에서도 하나씩 소개해 드릴 생각입니다. 근데 홍보보다 더 필요한 게 있죠. 실제 써본 사람의 피드백! 이어지는 글에 10개 앱 모두 소개했습니다.

요즘 PDF 분석 AI를 이것저것 실험 중인데요. AI한테 PDF 보내고 매출 확인해 달랬더니 2024년 매출을 2025년 걸로 알려줘서 큰일 날 뻔했어요. ㅋㅋ 숫자는 맞아요. 연도가 틀렸죠. 더 황당한 건 표까지 아주 멀쩡하게 정리해 준다는 거예요. 이러면 의심도 안 하고 넘어가기 딱 좋겠더라고요. PDF로 숫자 분석할 때는 좀 조심해야겠습니다. 이런 실수를 줄이는 데 도움이 될 만한 프롬프트 하나 공유드릴게요.

요즘 제가 올린 글들을 다시 읽어봤습니다. 좀 부끄럽더라고요. AI가 세상을 바꾼다, 이제 누구나 앱을 만든다, 앞으로 이런 시대가 온다... 틀린 말이라고 생각하진 않지만, 어느 순간부터 제가 하고 싶은 이야기만 하고 있었던 것 같습니다. 정작 제가 만든 서비스도 사람들에게 선택받는 건 쉽지 않은데 말이죠. 누군가에게 도움이 되는 이야기를 하고 싶었는데, 돌아보니 아는 척하고 가르치려 드는 사람처럼 보였을 수도 있겠네요. 20년 넘게 개발을 해왔어도 여전히 모르는 게 많습니다. 앞으로는 대단한 미래를 예측하기보다 제가 직접 부딪히고 실패하고 고민하는 이야기를 해보려고 합니다. 잘난 척은 좀 줄이고요. ㅎㅎ 여러분은 요즘 AI 이야기들, 솔직히 좀 지겹지 않으세요?

“8개 다 켜.” 이제는 이 말이 농담처럼만 들리진 않네요. T3 Code에서 MCP 서버 하나로 여러 컴퓨터의 에이전트를 묶고, Grok Bot으로 서로 다른 머신에 8개 스레드를 띄운 사례가 나왔어요. 생산성은 확실히 커지겠지만, 잘못된 지시 하나가 8곳에서 동시에 실행될 수도 있겠죠. 이런 구조라면 코드 생성보다 테스트와 중지 장치부터 붙이고 싶어요. 8개 에이전트라면 어떤 작업부터 맡기시겠어요?

ChatGPT 계정 2개 쓰시는 분들 이거 아셨어요? 회사 계정이랑 개인 계정 번갈아 쓰려면 매번 로그아웃하고 다시 로그인해야 했잖아요. 이제 모바일에서 계정 2개 등록해 놓고 바로 바꿔 쓸 수 있대요. 프로필에서 계정 추가만 하면 되고 대화 기록이랑 메모리도 각각 따로 유지돼요. 저처럼 계정 여러 개 쓰는 사람한텐 꽤 반가운 업데이트네요 ㅎㅎ

에이전트를 만들 때마다 실행층부터 다시 짜는 일은 이제 줄어들겠네요. GitHub 엔지니어링 팀이 만든 멀티모델 하네스를 Microsoft 제품 전반에 적용했다고 합니다. Foundry Agent Service에는 Microsoft Copilot harness로 들어갔고요. 오케스트레이션, 도구, 컨텍스트, 제어를 하네스가 맡고, 에이전트의 기능과 결과에 집중하는 구조예요. 모델 자체보다 실행층을 어떻게 구성할지가 더 중요했던 팀이라면 꽤 눈여겨볼 만하겠어요. 여러분은 orchestration, tools, context, controls 중 어디부터 보시나요?

앱 소개 글인데, 가끔은 앱보다 만든 사람이 다음에 무엇을 고민할지가 더 궁금해질 때가 있어요. 올리기 전에는 기능을 더 붙이고 싶고, 올린 후에는 가격·사용성·첫인상부터 묻게 돼요. 요즘 최신 글에는 ToneCue, 일본인과 일상을 공유하는 「노리」, 디자이너 모의 면접 툴 같은 앱이 올라왔어요. AI 슬롭을 줄이는 방법을 묻는 글도 있고요. 바이브크루에는 지금 406명이 합류해 있어요. 앱 소개나 피드백 요청에 만든 걸 올려 보고, 반응이 없었던 지점까지 같이 보여 주세요.

저는 GPT와 Claude를 함께 구독해 쓰고, 작업에 따라 모델을 바꿔 사용합니다. 이제 에이전트에게 “끝내”보다 “끝날 때까지 확인해”라고 시켜야겠어요. 루프는 4가지만 기억해두면 됩니다. - Goal-based: Lighthouse 90 이상, 최대 5회 - Time-based: 5분마다 PR 점검 - Proactive: 버그 리포트 감시→PR, 머지는 사람 - Custom: 검증 방식을 직접 정할 때 완료했다는 말보다 어떤 조건에서 멈췄는지가 더 중요해졌네요. Goal-based와 Time-based 중 무엇부터 붙이실 건가요?

“상태 한 줄 보여주려고 전체 기록을 보내?” Claude Code 백그라운드 에이전트는 약 30초마다 자신의 트랜스크립트를 모델에 보내 3~5단어 요약을 만듭니다. 패널에만 표시되는 상태라 대화 내용에 섞이진 않아요. 그런데 측정 결과, 이 요청이 전체 지출의 16.4%, 요청의 19.7%를 차지했습니다. 구독 사용자는 청구서보다 rate limit 여유를 잃고요. 에이전트에 맡긴 코드와 비밀정보가 이 경로를 타도 괜찮은지, 병렬 실행 전에 확인해봐야겠어요.

“Gemini야, 내 앱에서 찾아서 처리해줘.” 이 흐름이 안드로이드 앱으로 들어옵니다. Android MCP 베타는 AppFunctions API 기반으로 앱과 Gemini 앱을 연결해요. 사용자는 앱 정보에 대해 질문하고, 앱의 동작도 요청할 수 있대요. Connected Apps Platform 프리뷰도 함께 나왔습니다. 이제는 개발 속도보다 공개할 기능 목록이 더 무서운 변화예요. 결제나 삭제처럼 되돌리기 어려운 동작은 절대 열지 않는 쪽인데, 너무 보수적인가요?

매번 같은 확인을 시키고 있다면, 모드부터 만들 때가 아닐지도 모르겠어요. Opus 5.5가 최근 20개 세션을 훑어 반복 질문의 횟수와 정확한 문장, 멈췄거나 거부했거나 되돌린 명령, 파일 목록·diff를 요구한 흔적을 뽑습니다. 그걸 모드 후보로 만들되, status line이나 설정으로 해결되면 제외하고 먼저 후보만 보여주게 합니다. 코드 없이 한 번에 만들 수 있어도, 새 기능보다 반복되는 실수부터 고르는 편이 맞겠네요.

AI에게 무료 홍보용 앱 소개 글을 맡김. “과장 없이, 짧고 쉽게 써줘.” AI가 알아들은 것: 홍보 티가 나면 안 됨. 문제와 기능은 잘 정리했는데, 장점은 전부 “확인해볼 만함”으로 바꿈. 앱 만든 사람도 읽고 “그래서 좋은 건가?”가 됨. AI는 신뢰감 있는 소개 글이라고 함. 신뢰감은 있는데 신청자가 자기 앱을 다시 고민함 ㅋㅋ

Claude Code를 잘 쓰는 사람보다, 먼저 켜지게 만든 조직에서 성과가 보였네요. 유타주 정부가 10개 기관의 개발자 34명에게 도입했습니다. 30분 안에 작업 환경을 만든 사람이 80%, 4주 파일럿 마지막에 20시간 이상 아꼈다고 답한 사람이 71%였어요. 도구 성능표보다 배포 첫날의 30분이 더 현실적인 지표일 수 있겠네요. 팀에 적용한다면 30분 세팅과 4주 사용 중 뭘 먼저 확인할까요?

“이제 출시만 하면 되는데…”에서 멈추는 경우가 많더라고요. 앱은 만들었는데 가격 정하기가 어렵고, 데모에서 갑자기 작동하지 않고, 어디서 피드백을 받아야 할지도 애매하고요. 바이브크루에서는 이런 과정을 앱소개·질문·빌드로그·출시지원으로 나눠 올릴 수 있어요. 지금까지 406명이 합류했고, 39,089명이 다녀갔습니다. 바이브코딩 중이라면 막힌 지점 하나 들고 같이 봐요.

사이트를 Claude Code에 넣고 DB를 싹 긁었다고 자랑하는 글이 올라왔어요. 403을 돌려주자 User-Agent를 Googlebot으로 바꾸고 /api/를 찌른 뒤, Playwright까지 띄웠다네요. 이게 맞나 ㅋㅋ 자동화보다 먼저 데이터 주인의 권리와 에이전트의 안전장치를 봐야 한다고 느꼈어요. 글쓴이는 미끼 페이지와 진짜 Googlebot 검증을 넣은 방화벽을 만들었다고 주장해요. 정상 크롤러까지 막히진 않을까요?

화면은 괜찮은데, 이다음 플로우는 어떻게 짜지?” 이럴 때 Refcat에서 의미 검색으로 실제 제품 화면 56만 개 이상과 사용자 플로우 10만 개 이상을 훑어볼 수 있어요. Figma·Chrome·MCP를 연결해 마음에 든 레퍼런스를 저장하고, 화면에서 기획과 구현으로 넘어가는 흐름을 만들 수 있네요. 무료로 주 10개 풀 플로우 미리보기, 저장 50개, 프로젝트 3개, Figma 내보내기 월 5회까지 제공돼요. AI에게 처음부터 화면을 상상하게 하기보다, 실제 플로우를 먼저 고르는 쪽이 덜 헤맬 듯해요.

“AI로 짠 코드는 설명만 잘하면 되겠지” 했는데, OpenAI 면접 사례에선 과제 코드를 줄마다 물었다네요. 일부 지원자에겐 손으로 풀기 어려운 문제를 AI 코딩 도구로 해결하게 했고요. 익명 경험담이라 공식 절차와는 다릅니다. 바이브코더라면 - 생성 전 요구사항 쪼개기 - 수정된 코드 한 줄씩 읽기 - 실패한 시도도 남기기 - AI 사용 가능 범위 먼저 묻기 AI를 금지하거나 허용하는 것보다, 맡긴 뒤 어디까지 확인했는지가 더 까다로운 시험이 될 듯해요 ㅋㅋ

개발자 대부분이 CLI보다 데스크톱 앱을 쓴다고?” X에서 Claude Code와 ChatGPT Codex 사용법을 두고 이런 얘기가 나왔고, 좋아요 774개·댓글 229개가 붙었어요. 여러 에이전트를 돌릴 때는 CLI가 작업 위치와 로그를 붙잡기 좋고, 앱은 시작하고 확인하기 편하죠. 생산성 차이라기보다 작업 습관의 차이에 가깝다고 봐요. 그래도 ‘대부분’이라는 말에는 선뜻 동의하기 어렵네요. 여러분은 앱파인가요, CLI파인가요?

주말에는 코드 리뷰도 가볍게 끝날 줄 알았음. 카페에서 Claude에 말함. “이건 가볍게 봐줘.” 내 뜻은 5분만 훑어보기. Claude가 알아들은 건 가벼운 마음으로 전체 검토. 구조, 예외 처리, 권한 흐름까지 보고 마지막에 “간단한 개선 사항”을 붙임. 가볍게 본 건 맞음. 내 자세만.