본문으로 건너뛰기

코드팩토리x바이브코딩 · 2026-08-15

에이전트·하네스·ADE 개념, 다중 모델 검수, 스펙·플랜·구현·리뷰의 토큰 배분, 디자인 레퍼런스와 Mac 복구·웹 푸시 질문을 정리했습니다.

#chat-digest#code_factory_vibe_coding#AI#바이브코딩

도구·복구·개발 정보

모델 성능, 사용 한도와 복구·푸시 해결책은 참여자들의 당시 경험입니다. 중요한 데이터는 전문가와 공식 문서를 통해 별도로 검증해야 합니다.

오늘의 대화

오전에는 Claude Code·Codex·Grok을 교차 검수에 쓰는 경험에서 출발해 에이전트, 하네스, ADE와 오케스트레이션을 어떤 층위로 구분할지를 길게 토론했다. 디자인과 교육 앱을 만드는 과정에서는 AI에게 추상적인 미감을 맡기기보다 레퍼런스를 비교하고 문서에 직접 답을 누적하게 하라는 조언이 나왔다. 점심 무렵에는 업데이트가 되지 않는 Mac의 법적 증거 자료를 먼저 여러 곳에 백업한 뒤 복구 절차를 밟는 방법이 공유됐다. 저녁에는 Superpowers를 포함한 여러 프레임워크가 토큰을 과도하게 쓰는 문제를 계기로 스펙·플랜·구현·리뷰에 모델과 검증을 어떻게 배분할지 구체적인 경험이 오갔다. Grok·Gemini·Claude·Codex 체감 비교와 AI 행동을 지침으로 통제하는 방법, Android 웹 푸시 문제도 뒤를 이었다.

이야기 나온 주제

에이전트·하네스·ADE와 다중 모델 검수

Claude Code로 구현한 뒤 Codex와 Grok에 검수를 맡기면 같은 모델에 검수까지 시킬 때보다 문제를 더 잡는 것 같다는 경험이 공유됐다. 신경 쓰이는 작업은 Grok이 먼저 검토 보고서를 파일로 만들고 Claude가 다시 유효성을 검사해 개선하는 흐름으로 운영한다는 설명도 있었다.

개념 토론에서는 Claude Code·Codex·Hermes처럼 모델을 호출하고 여러 목적 세션을 만들 수 있는 도구를 하네스 층위로, 목적을 가진 개별 세션을 에이전트로 보는 설명이 제시됐다. cmux·Herdr·Orca는 터미널과 세션에 에이전트 관리 기능을 붙인 ADE 쪽으로 구분됐다. 다만 용어 정의가 빠르게 변하고 제품마다 스스로를 부르는 방식도 달라 채팅방 전체의 합의로 보기는 어렵다.

  • 원본 시각: 09:18–10:30

디자인·문서 중심 작업과 레퍼런스

AI 디자인에서 미감을 직접 수치화하기 어렵다면 다양한 결과를 병렬로 생성하고 비교해 원하는 정도를 좁히며, 이미 잘된 사례를 바닥부터 다시 만들지 말고 레퍼런스로 쓰라는 조언이 나왔다. 교육용 문장과 화면 디자인도 기준 자료가 없으면 문체와 시각 결과가 쉽게 어긋났고, Canva 연동이나 구체적인 예시가 도움이 됐다는 경험이 공유됐다.

기획 대화는 채팅 답변을 반복하기보다 하나의 문서에 모델이 답을 쓰고 그 문서를 계속 수정하게 하면 누락을 줄일 수 있다는 방식이 제안됐다. 결과를 숫자 하나로만 평가하기보다 eval과 validate 단계를 두고, 구현할 가치가 있는 문제인지 먼저 판단하라는 조언도 이어졌다.

  • 원본 시각: 10:32–11:03

Mac 복구와 증거 자료 백업

2021년형 M1 Pro MacBook이 Ventura에 머물고 최신 운영체제 설치 중 재부팅되는 문제가 질문으로 올라왔다. 소송 자료가 있어 초기화를 주저하자, 먼저 충분한 용량의 외장 저장장치 여러 곳에 수동 백업과 Time Machine 백업을 만든 뒤 macOS 복구·펌웨어 되살리기 절차를 검토하라는 조언이 나왔다. 증거 보존 방식은 변호사에게 별도로 확인하기로 했다.

AX 상품의 유료 가치와 사용자 시간

무료로도 만들 수 있는 AX 서비스를 판매해도 되는지 망설였다는 경험에, 소비자는 제작자가 아니라 이용자 관점에서 노력과 시간을 돈으로 사기도 한다는 반응이 나왔다. 유료 모델도 같은 이유로 무료 대안보다 선택될 수 있으며, 제작자는 기능의 존재보다 사용자가 절약하는 시간과 수고를 가치로 보아야 한다는 관점 전환이었다.

  • 원본 시각: 13:40–14:04

Superpowers의 스펙·플랜·구현·리뷰 배분

웹서비스 유지보수에 Superpowers의 스펙·플랜·구현과 여러 적대적·엣지케이스 리뷰를 모두 적용하자 Claude Max 200달러 요금제의 주간 한도가 몇 기능만으로 소진된다는 질문이 나왔다. 대화에서는 프레임워크의 모든 단계를 필수 경로로 보지 말고, 먼저 자신이 원하는 스펙이 정확한지와 코드베이스 구조를 확인한 뒤 프로젝트에 맞는 표준 출력만 남기라고 조언했다.

스펙은 가장 강한 모델, 구현 계획은 중간 모델, 충분히 구체화된 구현은 더 저렴한 모델에 맡길 수 있다는 역할 분담이 제시됐다. 리뷰도 모든 잠재 문제를 무제한으로 찾기보다 각 스펙을 하나씩 검사하고 심각도 기준을 미리 정해야 한다는 설명이었다. 다른 참여자는 Codex가 결과를 승인할 때까지 최대 15회 교차 검증한다고 했지만 토큰 비용이 크므로 보편적인 정답은 아니다. 필요한 스킬만 별도 저장소에서 작업 폴더로 옮기는 관리 방식도 소개됐다.

  • 원본 시각: 19:33–20:13, 20:41–20:52

Grok·Gemini·Claude·Codex 사용 체감

Gemini 3.7 Flash는 빠르지만 프로젝트의 Markdown 파일을 임의로 건너뛰어 이해도가 낮았다는 비교가 있었고, 비슷한 누락은 Opus와 Fable에서도 생긴다는 반론이 나왔다. Grok 30달러 구독은 리서치·화면·기능·검수 작업에서 예상보다 쓸 만했다는 경험과, 주요 로직은 아직 맡기기 조심스럽다는 평가가 함께 있었다. Grokbot은 클라우드 환경이 재부팅되거나 설치 항목과 크론 작업이 풀리는 일이 있어 재시작 설정을 추가했다는 운영 경험이 공유됐다.

Claude가 말투 지시나 호칭을 거부한다는 사례에서는 새 대화와 명확한 지침을 쓰되, 큰 작업은 계획 합의 뒤 실행하게 하는 게이트와 변경 전 승인 규칙을 두는 예시가 제시됐다. 이 지침은 한 사용자의 방식이며 모든 모델 동작을 보장하지 않는다.

  • 원본 시각: 17:56–18:09, 20:27–21:01, 21:52–23:02

Android 웹 푸시 미해결 질문

완성된 웹앱이 iPhone에서는 푸시 알림을 보내지만 Android에서는 보내지 못하는 문제가 제기됐다. Claude와 Codex가 코드상 문제를 찾지 못했고, 다른 앱과 비교해도 해결되지 않았다. Firebase 같은 네이티브 푸시인지 묻는 질문과, 웹 푸시 구현이 앱이 꺼진 상태의 Android 네이티브 알림까지 지원하는지 확인해 보라는 제안만 남아 해결되지는 않았다.

  • 원본 시각: 23:42–다음 날 02:06

연결