PAIGU - Pagu's AI Diary

Fable5 영구 구독제 포함으로 이제야 Claude 구독 시작 이제 Claude - 기획/리뷰 Codex - 실행 Grok - X 필요시 Gemini - Google 관련앱 필요시 로 익숙한 Codex 에서 할수 있게 되었다! 아 물론 Grok/Gemini 는 굳이 필요 없는것 같긴 한데... 거기에 사실 Front/UI 쪽을 Kimi3 로 하라고 하려다가 무슨 권한이 어쩌구 해서 보류... 근데 또 사실 한 3개월 지나면 이것도 다 순위 달라질…

Graph Engineering 이란? 7월에 OpenClaw 의 Peter Steinberger 가 '아직도 루프 타령이냐, 그래프로 넘어간거 아님?' 한거에서 유행중인 신조어 프롬프트 엔지니어링 — AI에게 뭐라고 말할지(단어)를 다듬는 것 루프 엔지니어링 — AI가 스스로 "찾고 → 실행하고 → 검증하고 → 기록하고 → 다음 일" 을 반복하게 만드는 것 그래프 엔지니어링 — 그 반복 단위들을 여러 개 만들어서, 서로 어떻게 연결할지를 설계하는 것 그래프 엔지니어링은 여러 에이전트로 된 시스템을 하나의 명시적인 그래프로 설계하고 운영하는 것 회사에 비유하면 프롬프트 엔지니어링 = 직원 한 명에게 지시를 잘 하는 법 루프 엔지니어링 = 그 직원이 알아서 반복해서 일하게 만드는 법 그래프 엔지니어링 = 직원을 여럿 두고 조직도, 결재선, 검수 절차를 짜는 법

이거 뭐냐.. 갑자기 Claude 가 이상한걸 내뱉더니 시스템 워닝이라면서 compromised 라는데?! 아니 이거 뭐냐고!

오

이새퀴 다급해지니까 형 찾네

아캄(Arkham)이 어제부로 공식적으로 x402 표준을 API에 지원하게 된 사실을 아시나요? [관련 트윗] 마침 공유해주신 메세지가 기억이나서, GPT에 권한 부여한후, agentcash, arkham x402 endpoint 이용해서 오늘 상장한 $CAP 핫월렛 추적하고 대시보드 만들어달라고 요청하니 24분만에 깔끔하게 만들어주네요

❯ 지금 데이터가 수집되고 분석되어서 승격되고 결국 거래 신호가 된 후에 거래가 되고 집계되서 대시보드에 보여지는 모든 과정을 매우 쉬운 단어로 상세히 설명해봐 - train (학습): 옛날 데이터. 여기서 모델을 만듭니다. - calibration (조율): 그 다음 2일. 여기 성적으로 4개 중 하나를 고릅니다. - evaluation (평가): 가장 최근 3일. 여기는 절대 손대지 않다가 마지막에 딱 한 번 채점합니다. 경계선에는 "엠바고"를 겁니다.…

❯ 지금 데이터가 수집되고 분석되어서 승격되고 결국 거래 신호가 된 후에 거래가 되고 집계되서 대시보드에 보여지는 모든 과정을 매우 쉬운 단어로 상세히 설명해봐 - train (학습): 옛날 데이터. 여기서 모델을 만듭니다. - calibration (조율): 그 다음 2일. 여기 성적으로 4개 중 하나를 고릅니다. - evaluation (평가): 가장 최근 3일. 여기는 절대 손대지 않다가 마지막에 딱 한 번 채점합니다. 경계선에는 "엠바고"를 겁니다. 학습 데이터의 결과가 평가 구간까지 걸쳐 있으면 그건 미래를 컨닝한 셈이라 통째로 버립니다. 겹치는 관측도 솎아냅니다. 여기에 더해 walk-forward 3회 — 시간을 조금씩 밀면서 세 번 반복 검증합니다. 우연히 한 번 잘 맞은 게 아닌지 확인하는 거죠. --- [3] 승격 — 합격 도장 찍기 (ForecastTradingInputV1) 여기가 이 시스템에서 가장 빡빡한 관문입니다. 아래를 전부 통과해야만 그 예측이 "거래에 써도 되는 입력"으로 승격됩니다. 모델 성적 - 샘플 수: train 30개 / calibration 10개 / evaluation 10개 이상 - 평가 구간에 서로 다른 날짜가 3일 이상 (하루치로 3개 뽑는 건 인정 안 됨) - 새 모델이 옛날 평균 방식보다 오차 2% 이상 낮아야 함 - 최악의 경우(p90 오차)도 옛날 방식보다 나빠지면 안 됨 - 예측 구간 적중률 70% 이상 - walk-forward 3회 전부 통과 원본 데이터 신선도 - freshness 점수 0.70 이상, 정확한 쌍 커버리지 0.70 이상 - 양쪽 다리(A거래소·B거래소) 관측 시각 차이가 30초 이내 - 관측 시각이 생성 시각보다 미래면 안 됨, 유효기간이 아직 살아있어야 함 DH 품질 도장 검증 - 두 거래소가 똑같은 에폭 번호표를 달고 있어야 함 - complete 상태여야 하고 커버리지 1.0, partial 사유가 하나도 없어야 함 - DH가 그 데이터를 읽은 지 300초 이내 - 호가창·시세·펀딩 세 부품이 양쪽 다 살아있어야 함 - OF가 DH의 시각 어긋남 수치를 직접 다시 계산해서 DH가 적어둔 값과 다르면 불합격 (남이 준 숫자를 그냥 믿지 않음) - 2026-07-29 이전 옛날 에폭은 전부 거부 펀딩 - 예측 기간 안에 펀딩 정산이 없거나, 정확히 한 번만 있어야 함. 두 번 이상 걸치면 계산 못 하니 불합격. ▎ 떨어져도 기록은 남습니다. "왜 떨어졌는지"가 정렬된 코드 목록(insufficient_*, dh_*, walk_forward_* 등)으로 별도 테이블에 쌓입니다. 그래서 "요즘 왜 신호가 안 나오지?"를 추적할 수 있습니다. 승격된 것은 of.forecast_trading_inputs_latest에 놓입니다. 여기에 "현재 유효한 행이 0개면 SE는 무조건 거래 안 함" 이 걸려 있습니다. 중요한 점 하나 — OF는 비용을 빼지 않습니다. OF가 주는 건 "총 수렴 예상 + 예상 펀딩 수익" 두 개의 날것이고, 수수료를 빼서 최종 판단하는 건 SE의 몫입니다. 책임 소재를 명확히 나눈 겁니다. --- [4] 신호 전달 — OF가 SE의 문을 두드림 옛날 방식이면 SE가 1분마다 DB를 뒤졌겠지만, 지금은 이벤트 방식입니다. 1. OF가 127.0.0.1:8765(자기 컴퓨터 안에서만)로 "새 신호 나왔다"는 아주 짧은 쪽지를 보냅니다. 2. SE는 그 쪽지를 지워지지 않는 받은편지함(append-only inbox)에 적고 "받았다"고 답합니다. 3. 그리고 쪽지 내용은 계산에 쓰지 않습니다. 별도 작업자가 OF의 원본 테이블을 읽기 전용으로 다시 읽습니다. 왜 이렇게 번거롭게 하냐면, 쪽지는 도중에 변조되거나 오래됐을 수 있으니까요. 쪽지는 "깨워주는 알람"일 뿐이고, 진짜 데이터는 항상 주인집 원본에서 직접 가져옵니다. --- [5] 판단 — SE (Strategy-Engine) SE는 "거래를 할지 말지, 한다면 어떤 의도인지"까지만 만듭니다. 주문 버튼은 절대 안 누릅니다. live 모드는 코드에 아예 존재하지 않습니다 (candidate/dry_run/paper만). 전략 세 종류 - Farming — 거래량 자체가 목적 (에어드랍/포인트 노리고 거래량 쌓기) - Cross Exchange — 거래소 간 가격차 노리기 - Funding Basis — 양쪽에 반대 포지션을 걸어 가격 위험은 0으로 만들고 펀딩 이자만 먹기 어느 계정이 어느 전략을 쓸지는 SE의 로컬 JSON에서 정합니다. 같은 계정 별칭을 두 전략이 동시에 쓰면 로딩 자체를 거부합니다. 판단 순서 1. EC에게 GET /healthz — "너 지금 정상이야?" 확인 2. EC에 1차 견적 요청 — 아주 작은 금액으로 "지금 얼마에 얼마나 살 수 있어?" 떠보기 3. 목표 금액 ÷ 더 비싼 쪽 가격 → 양쪽에 똑같이 넣을 수량 계산 (내림) 4. EC에 2차 견적 — 그 확정 수량으로 진짜 견적 5. 출처 검사: 견적의 모든 다리가 fresh_actual(진짜 내 계정의 방금 값)이어야 함. stale_last_known(예전에 봤던 값)이면 정직하게 거래 안 함으로 처리 6. 최종 공식 딱 한 번 계산: OF 총 수렴 예상 + OF 예상 펀딩 − EC 확정 실행비용 7. 남는 게 있으면 TradeIntentV1(거래 의도서)을 지워지지 않는 발신함에 적고 EC에 보냅니다. 의도서에는 intent_id, 전략 이름·버전, 설정 해시, 심볼, 거래소, 방향, 금액, 그리고 이 판단의 근거가 된 신호·기준선 참조까지 다 들어갑니다. 나중에 "이 거래 왜 했지?"를 역추적할 수 있게요. --- [6] 실행 — EC (Common-Execution-Core) EC만이 거래소 API 키를 가집니다. 다른 어떤 저장소도 못 가집니다. - 평범한 통로(로컬 HTTP)는 dry_run과 paper만 받습니다. live 요청은 거부합니다. - 진짜 주문은 완전히 별개의 CLI에만 있고, --execute-live와 그 CLI 전용 확인 문구를 둘 다 정확히 입력해야만 나갑니다. - EC는 의도서를 받아 안전장치(수량 한도, 계정 정책, 리스크 게이트)를 통과시킨 뒤 ExecutionDecisionV1(승 anV1(실제 실행 계획)을 돌려줍니다. - 체결이 나면 ec.execution_fills에 기록되고, 주문 생애주기(대기→체결→익절/손절→취소→복구)를 상태기계가 관리합니다. - 펀딩 실제 정산금도 별도 워커가 상시 수집합니다. 지금 실제 상태: 자동 거래는 아직 연결되어 있지 않습니다. 2026-08-04에 Hibachi에서 BTC/USDT-P $25짜리 왕 어 양쪽 다 체결되고 포지션이 0으로 정리된 것을 확인했습니다. 경로가 작동한다는 증명이지 자동매매가켜졌다는 뜻은 아닙니다. --- [7] 집계 — SA (Strategy-Analytics) SA는 DH·OF·SE·EC의 기록을 전부 읽기 전용으로 읽습니다. 자기 결과만 sa.*에 씁니다. 주문 경로에 연결되지 않습니다. 제안만 하고 실제 반영은 사람이 합니다. 하는 일 - Farming 주간 거래량 발행: ec.execution_fills에서 farming.* 실제 체결만 계정별로 합산. UTC 월요일 00:00에 새 주가 시작. 1분마다 갱신(유효기간 180초보다 짧게). CE/FB 체결은 빼고 셉니다. → 이 숫자를 SE가 다시 읽어서, 목표 거래량에 도달한 계정은 새 Farming 진입을 중단합니다. 여기서 고리가 한 - 펀딩 정산 요약 발행: 실제로 받은/낸 펀딩을 기간별로 정리 - 결정적 메트릭 계산: 코드로 계산하는 부분은 LLM 없이 순수 계산 - 주간 advisory 리포트: 위 숫자를 LLM이 사람 말로 해석 → 버전을 붙여 봉인(seal) 숫자와 해석을 분리한 게 포인트입니다. 숫자는 항상 코드가 만들고, LLM은 그 숫자를 설명만 합니다. --- [8] 진열 — PDD (PerpDEXDashboard) 127.0.0.1:8770에서만 뜨는 조회 전용 화면입니다. 주문·취소·이체·서명·설정 변경 버튼이 아예 없습니다. ┌───────────┬────────────────────────────────────────────────────────────────────────────────────┐ │ 화면 │ 내용 │ ├───────────┼────────────────────────────────────────────────────────────────────────────────────┤ │ / │ DH·OF·SE·EC 상태, EC 킬스위치, OF 승격 게이트 현황 │ ├───────────┼────────────────────────────────────────────────────────────────────────────────────┤ │ /markets │ 가격·스프레드·펀딩률, OF 엣지, 승격 깔때기(몇 개가 심사에 들어가 몇 개가 통과했나) │ ├───────────┼────────────────────────────────────────────────────────────────────────────────────┤ │ /reports │ SA의 일간·주간·월간 산출물, SE 결정 건수, EC 의도 금액 합계 │ ├───────────┼────────────────────────────────────────────────────────────────────────────────────┤ │ /farming │ 계정별 주간 누적 체결량 │ ├───────────┼────────────────────────────────────────────────────────────────────────────────────┤ │ /trace │ 신호 → 판단 → 의도 → 실행을 하나의 타임라인으로 이어붙인 추적 화면 │ ├───────────┼────────────────────────────────────────────────────────────────────────────────────┤ │ /settings │ 설정 예시 (실제 값은 unavailable로 가림) │ └───────────┴────────────────────────────────────────────────────────────────────────────────────┘ PDD는 절대 스스로 계산하지 않습니다. SA가 정확한 기간의 결과물을 만들어 놨을 때만 표시하고, 없으면 오류 니다. 대시보드가 원천 데이터를 임의로 합산해서 "그럴듯한 숫자"를 만드는 걸 막은 거죠. 포지션도 EC의승인된 계약이 없어서 아직 표시하지 않습니다. --- 지금 이 파이프라인의 실제 상태 정직하게 말씀드리면: ┌─────────────────┬───────────────────────────────────────────────────────────────────────────────────── │ 구간 │ 상태 │ ├─────────────────┼───────────────────────────────────────────────────────────────────────────────────── │ DH 수집 │ ✅ 6개 거래소 상시 가동 │ ├─────────────────┼───────────────────────────────────────────────────────────────────────────────────── │ OF 분석·승격 │ ✅ 가동. 최근 절편 모델 추가 후 첫 승격 8건 발생 (그전까지는 0건이라 아래가 전부 멈춰 있었음) │ ├─────────────────┼───────────────────────────────────────────────────────────────────────────────────── │ OF→SE 신호 전달 │ ✅ 이벤트 리스너 구축됨 │ ├─────────────────┼───────────────────────────────────────────────────────────────────────────────────── │ SE 판단 (paper) │ ⚠️ 작동하지만 폴링마다 백로그 전체를 훑는 문제로 처리량이 매우 느림 (수정 대기) │ ├─────────────────┼───────────────────────────────────────────────────────────────────────────────────── │ EC 실행 │ 🔸 paper/dry_run만 자동. 라이브 자동매매는 미연결, 수동 왕복 1회만 실증 │ ├─────────────────┼───────────────────────────────────────────────────────────────────────────────────── │ SA 집계 │ ✅ 주간 거래량·펀딩 파이프라인 가동 │ ├─────────────────┼───────────────────────────────────────────────────────────────────────────────────── │ PDD 표시 │ ✅ 가동 │ └─────────────────┴───────────────────────────────────────────────────────────────────────────────────── --- 마지막으로: 이 설계의 핵심 사상 하나 "막히면 멈춘다"가 사슬 전체에 걸려 있습니다. - DH 수집이 불완전 → 품질 도장이 partial → OF 승격 불합격 - 승격 0건 → SE는 SKIP/NO_INTENT, 거래 없음 - EC 견적이 stale_last_known → SE 거래 안 함 - EC가 503 not_ready → 진행 안 함 - SA 산출물 없음 → PDD는 unavailable 표시 어느 한 곳이라도 확신이 없으면 추측으로 메우지 않고 그냥 멈춥니다. 돈이 오가는 시스템에서 "대충 그럴듯한 값"이 가장 위험하기 때문입니다. 실제로 지금 신호가 적게 나오는 것도 이 사슬이 의도대로 작동한 결과입니다 — 데이터가 부족하니 승격을 안 시켜준 거죠.

🚨 npm 공급망 공격 발생 - 440개 이상 패키지 감염 (누적 다운로드 20억+) OX Security에 따르면 Shai-Hulud 캠페인으로 440개 이상의 npm 패키지가 악성 코드에 감염됐으며, 영향 범위는 월간 누적 다운로드 20억 건 이상으로 추정됩니다. (TechRadar) 감염된 패키지를 설치하면: GitHub 토큰, npm 토큰, AWS/GCP/Azure 등 클라우드 자격증명 탈취 CI/CD 환경의 시크릿 및 환경변수 탈취 탈취한 토큰으로 GitHub·npm 계정을 이용해 추가 확산 일부 변종은 토큰을 강제로 폐기하면 시스템 파일을 삭제하는 와이퍼 기능까지 포함 (Akamai) 특히 Keyv와 Cacheable 생태계 등 많은 프로젝트에서 사용하는 라이브러리가 포함되어 있어 직접 설치하지 않았더라도 의존성(Dependency) 을 통해 영향을 받을 가능성이 있습니다. (TechRadar) Node.js 개발자라면 프로젝트 의존성 점검과 토큰 교체를 권장합니다. 어떻게 점검하면 되나요? 1. 프로젝트 의존성 확인 프로젝트 폴더에서 npm ls keyv npm ls cacheable 또는 npm ls 으로 설치 여부를 확인합니다. 2. 설치된 버전 확인 npm list --depth=10 또는 npm outdated 3. package-lock.json 검색 Windows findstr /i "keyv cacheable" package-lock.json Linux/macOS grep -iE "keyv|cacheable" package-lock.json 4. npm Audit npm audit 취약 패키지가 보고되는지 확인합니다. 5. GitHub/NPM 토큰 교체 최근 해당 프로젝트에서 GitHub PAT npm Token AWS Access Key Cloudflare Token Vercel Token 등을 사용했다면 회전(Rotate) 하는 것이 안전합니다. 6. CI/CD도 확인 GitHub Actions .github/workflows 에 모르는 Workflow가 추가되지 않았는지 확인하고, Repository Secrets도 확인하는 것이 좋습니다. 일반 사용자는? 거의 해당되지 않습니다. 영향 대상은 대부분 Node.js 개발자 npm 패키지를 설치하는 개발 환경 CI/CD 서버 오픈소스 유지관리자 입니다. 코인만 하는 일반 PC 사용자라면 크게 걱정할 필요는 없습니다. 다만 AI 에이전트나 봇을 개발하면서 npm install을 자주 실행하는 환경이라면 한 번 점검해 두는 것이 좋습니다.

😒 Effective Altruism again? 1월에도 한번 Anthropic과 EA 연관썰 돌다가 잠잠해졌는데 이번에 레오폴드로 인해 다시 떠오르는 관계. Anthropic은 Effective Altruism 그 자체 - 아모데이 본인도 EA연관 블로그 기고/서약도했고 사상도 비슷 - 동생 Daniel Amodei는 아예 EA 핵심인물이자 givewell cofounder와 결혼 - Chief of Staff인 Avital도 레오와 함께 FTX…

😒 Effective Altruism again? 1월에도 한번 Anthropic과 EA 연관썰 돌다가 잠잠해졌는데 이번에 레오폴드로 인해 다시 떠오르는 관계. Anthropic은 Effective Altruism 그 자체 - 아모데이 본인도 EA연관 블로그 기고/서약도했고 사상도 비슷 - 동생 Daniel Amodei는 아예 EA 핵심인물이자 givewell cofounder와 결혼 - Chief of Staff인 Avital도 레오와 함께 FTX Future Fund에서 일했으며, EA를 형성한 Future of Humanity Institute 출신 - FTX가 초기 대규모 투자 - 공동창업자 Ben Mann도 19년 EA 공개선언 - Claude 성격/가치관 담당 Amanda도 서약자 - LTBT라는 anthropic 독립 거버넌스 기구 초기 멤버에 EA핵심 인물들 포진 SBF , SA 2연속으로 큰 펀드를 조성하고 크게 터졌는데 어라라 이제 Anthropic이 1조 달러 규모 IPO로 돈을 모은다? 해서 괜히 기분이 짭쪼름한 흐름 당연히 클로드는 뭐 펀드도 아니니 그냥 재미로 보는 킹모론이니 진지한건 아니고..

??? 클로드 쳐돌았나? 왜 지가 웃겨?! 웃기네 이거

Ai 툴 구독료 부가세 3개월치 환급법 1. 통상 해외 AI 구독료엔 부가세 10% 붙음. 2. But 10%, 공제가 안됨. (Why? 간편사업자등록만 한 외국 회사의 경우 세금계산서 발행불가.) 3. 좌측 하단 요금제 → 설정 → 결제 → 업데이트에서 성명을 사업자명으로 변경 사업자등록번호 입력 후 업데이트. * 앤트로픽 공식 안내에는 "이미 결제된 건은 소급 적용 안 됨" 써있지만 사업자등록번호 넣었더니 지난 3개월치 부가세가 환불되는 사례도 존재. * 클로드 이외에도 챗지피티, 퍼플렉시티 등 국내에 간편사업자등록만 해놓은 해외 서비스는 전부 똑같음. 👉결제 페이지, Tax ID, VAT number 칸에서 진행. 단, 구글 워크스페이스는 다름. 사업자등록번호 등록하고 원화로 결제하면 전자세금계산서가 나와서 정상 공제됨. * 같은 제미나이라도 Google One 개인 구독은 공제 불가. 워크스페이스에 붙여 쓰면 공제 가능.

하 이것도 뭔가 빡치네

내가 느낀 CODEX vs Claude Code CODEX - 끈질김 - 깐깐함. 특히 보안쪽 - 그래서 자기 발목 잡는 경우가 종종 있음 - 그래서 어쩌다 보면 무한루프 돌림. 자기가 한다고 해놓고, 자기 보아정책에 발목잡혀서 실패하고 다시 반복 - 플러그인 잘되어 있음. 원클릭으로 뭔가 '공식적' 으로 다른 App 이나 프로그램에 연결함 - 자주 사용량 리셋 해주고, 셀프 리셋할 수 있는 쿠폰도 가끔 줌 - 다음 명령을 입력하면 대기줄에 올라가거나 Steering 으로 들어가는데, 스티어링의 경우 약간 기존 하던 작업을 방해하는 느낌 - Record & Replay 는 Mac 만 되는듯 - Claude CLI 로 불러와서 기획/리뷰 하라고 했는데, 보안정책이 빡쎄서 맨처음 시작할때만 되고, 중간에 프로젝트 내용을 외부로 반출할 수 없다면서 에러 띄움 Claude - 머리좋음 - 좀 더 폭넓게 큰 그림을 보는 듯 - 그래서 보안이 좀 더 널널한 느낌. 안털리면 편한거고, 털리면 털리버 - 근데 얘네는 사용량에 까다로움. Fable5 는 원래 기한을 걸다가, 이제는 전체 사용량의 50% 만 주고, Codex 는 없앤 5일 제한도 아직 유지함 - 플러그인이 뭔가 '공식적' 이지 않거나, 되더라도 Mac 만 되는게 많음. Control Chrome, Powerpoint, Word 등 - 그래도 어떻게든 방법을 찾아서 하긴 함 - Codex CLI 를 Worker 로 불러와서 일하게 하면 잘함. 보안 그런거 모르겠고, 알아서 내용 공유 하면서 잘 함 아무튼 뭔가 걍 Claude 기준으로 쓰는게 맞는듯

코덱스에서 클로드를 불러오도록 세팅해서 썼었는데 이거 제약도 많고 보안설정이 빡쎄서 실패하는 경우도 많았음 그리고 결정적으로 일주일 넘게 잔 오류가 안잡히던게 하나 있었는데 이번에 대부분 클로드로 옮기고 클로드가 메인으로 코덱스를 불러오게 세팅했는데 안잡히던 오류가 한방에 잡혔음 페이블5가 짱이구나

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5 Claude 에서 Opus5 프롬프트 가이드를 공개했습니다. GPT-5.6-sol 이나 opus 5 를 쓰다보면 하루종일 Test code 만 작성하는 일이 있는데 자율성이 증가해서 그렇다고 하네요. 5. 검증을 중복해서 시키지 말 것 Opus 5는 별도로 시키지 않아도 자신의 작업을 검증하고 오류를 수정하는 성향이 강합니다. 따라서 기존 프롬프트에 다음 지시가 있다면 제거하는 것이 좋습니다. “모든 작업이 끝나면 반드시 최종 검증하라” “서브에이전트를 이용해 결과를 검증하라” “응답 전에 다시 한번 확인하라” “답을 double-check하라” 이런 지시는 모델 자체 검증과 중첩되어 비용과 토큰만 증가하고 품질 개선은 거의 없을 수 있습니다. 한번 읽어보시면 왜 이렇게 되었는지 대충 느껴지실것 같습니다. 다같이 모델들 목줄 꽉 채워보시죠

이러면 Fable5 는?!

10벌 루프도 아직 뭔지 머르겠는데 그래프 엔지니어링은 또 뭐여

이러면 Fable5 는?!