앤트로픽, 클로드 Max 요금제 이름 변경·Ultra 5시간 한도 폐지
: Max 5x는 Max(월 $100), Max 20x는 Ultra(월 $200)로 이름만 바뀜. 가격은 그대로, 기존 구독자는 따로 할 일 없음
: 인증된 Ultra 계정은 5시간 사용 한도 폐지. 오늘부터 기존 구독자 대부분에 적용
: 신규 계정은 인증 전까지 임시 한도 유지(사기·악용 방지 목적). 해제되면 이메일로 안내
: 주간 한도는 변동 없음
https://x.com/claudeai/status/2116220869479428500
: Max 5x는 Max(월 $100), Max 20x는 Ultra(월 $200)로 이름만 바뀜. 가격은 그대로, 기존 구독자는 따로 할 일 없음
: 인증된 Ultra 계정은 5시간 사용 한도 폐지. 오늘부터 기존 구독자 대부분에 적용
: 신규 계정은 인증 전까지 임시 한도 유지(사기·악용 방지 목적). 해제되면 이메일로 안내
: 주간 한도는 변동 없음
https://x.com/claudeai/status/2116220869479428500
X (formerly Twitter)
Claude (@claudeai) on X
We’re renaming our Max plans:
Max 5x → Max
Max 20x → Ultra
Max is still $100/month, and Ultra is still $200. If you’re a subscriber, there’s nothing you need to do.
We’re also removing the 5-h…
Max 5x → Max
Max 20x → Ultra
Max is still $100/month, and Ultra is still $200. If you’re a subscriber, there’s nothing you need to do.
We’re also removing the 5-h…
Forwarded from 온체인 레이더
바이낸스 해킹. 그 이면에서 벌어진 일
20분 만에 63억 6천만 달러.
가스비 전쟁, 샌드위치 공격, 블록 포함을 위한 뇌물 경쟁.
급락장에서 진행된 프로젝트 팀들의 바이백.
온체인에서 활동한 1,000개 이상의 차익거래 지갑, 그리고 수백만 달러의 수익을 올린 CIS(독립국가연합) 및 한국의 스마트머니.
지금 확인해 보세요 👇
https://how2onchain.substack.com/p/251
20분 만에 63억 6천만 달러.
가스비 전쟁, 샌드위치 공격, 블록 포함을 위한 뇌물 경쟁.
급락장에서 진행된 프로젝트 팀들의 바이백.
온체인에서 활동한 1,000개 이상의 차익거래 지갑, 그리고 수백만 달러의 수익을 올린 CIS(독립국가연합) 및 한국의 스마트머니.
지금 확인해 보세요 👇
https://how2onchain.substack.com/p/251
Substack
바이낸스 해킹. 그 이면의 이야기
무슨 일이 있었나
오픈AI, 모바일 다중 계정 전환 지원
: 모바일에서 여러 계정 간 간편 전환 기능을 사용할 수 있음.
: 데스크톱에도 해당 기능을 곧 제공할 예정.
: 향후 이틀은 '리셋'과 '적립(banked)'을 예고했으며, 구체적인 내용은 아직 밝히지 않음.
https://x.com/thsottiaux/status/2116405414921384099
: 모바일에서 여러 계정 간 간편 전환 기능을 사용할 수 있음.
: 데스크톱에도 해당 기능을 곧 제공할 예정.
: 향후 이틀은 '리셋'과 '적립(banked)'을 예고했으며, 구체적인 내용은 아직 밝히지 않음.
https://x.com/thsottiaux/status/2116405414921384099
X (formerly Twitter)
Tibo (@thsottiaux) on X
Day 26/ You can now easily switch between multiple accounts on mobile, and coming soon to desktop too. Next two days will be resets… banked… do with this what you may 👀.
https://t.co/iQxsqbuk0f
https://t.co/iQxsqbuk0f
오픈AI, 법률용 GPT-6 Astra, API 가격표에 등재
: gpt-6-astra-law가 API 가격 페이지에 ‘법률용 모델 구성’으로 표시됐다.
: 100만 토큰당 입력 10달러, 출력 50달러, 캐시 입력 1달러다.
: 프로모션 가격은 최소 2026년 12월 31일까지 제공된다.
https://x.com/testingcatalog/status/2116443618659455284
: gpt-6-astra-law가 API 가격 페이지에 ‘법률용 모델 구성’으로 표시됐다.
: 100만 토큰당 입력 10달러, 출력 50달러, 캐시 입력 1달러다.
: 프로모션 가격은 최소 2026년 12월 31일까지 제공된다.
https://x.com/testingcatalog/status/2116443618659455284
X (formerly Twitter)
🚨 AI News | TestingCatalog (@testingcatalog) on X
OPENAI 🔥: gpt-6-astra-law is now listed on the API pricing page. There, it is referenced as "Legal model configuration".
> Pricing: input $10, Output $50, Cached input $1.
> "GPT-6 Astra for L…
> Pricing: input $10, Output $50, Cached input $1.
> "GPT-6 Astra for L…
Standx 바낸해킹으로 클레임 연기
https://x.com/StandX_Official/status/2116453957568536643?a=2j7ed7LYoMzYLUOCFgQ&s=19
https://x.com/StandX_Official/status/2116453957568536643?a=2j7ed7LYoMzYLUOCFgQ&s=19
X (formerly Twitter)
StandX (@StandX_Official) on X
📢 StandX $DUSD Airdrop Claims Update
StandX airdrop claims, originally scheduled for November 1st at 00:00 UTC (08:00 HKT), have been postponed while Binance withdrawals remain closed.
To ensur…
StandX airdrop claims, originally scheduled for November 1st at 00:00 UTC (08:00 HKT), have been postponed while Binance withdrawals remain closed.
To ensur…
Forwarded from EWL's doomscroll
토큰에 대한 재밌는 글! "The Crypto End-game (Belief assets & Cashflow assets)"
토큰을 만들고 단기적으로 가격을 펌핑하는 방법은 너무 잘 알려졌는데, 이런 것 말고 과연 사람들이 1년 이상 들고 있을 만한 토큰은 어떤 것인가?에 대한 글
작성자는 오래 살아남는 토큰을 크게 사람들의 "믿음으로 버티는 자산 / 실제로 돈을 벌어 홀더에게 돌려주는 자산"이라는 두 가지 관점에서 설명함
개인적으로는 마지막 부분이 생각해볼 거리가 많다고 느껴짐
> 초기 프로젝트가 번 돈을 전부 바이백에 쓰는 게 항상 좋은 건 아니고, 성장에 재투자하는 게 더 나을 수도 있음
> 다만 그렇게 커진 사업의 가치가 나중에 어떻게 토큰에 돌아오는지 불명확하다면, 홀더는 사업의 성공뿐 아니라 ‘성공한 뒤 팀이 그걸 나눠줄 의지’까지 같이 믿고 있는 셈이라는 것
> 최근 바이백을 진행하겠다고 나서는 팀들도 이 부분과 연결해서 볼 수 있지 않나 싶고, 실제로 가격 반응이 좋았던 프로젝트들도 많음 ($CHIP, $ATH, $ENA, $ZRO 등등)
그리고 결과적으로 작성자는 $HYPE 를 가장 높게 평가함 → 실제 수익이 토큰 매수로 연결되는 구조가 있으면서도, 초기 참여자들의 수익 경험, 커뮤니티, 상징적인 인물 등 믿음 쪽 요소도 함께 갖추고 있기 때문
이외에도 각 카테고리나 특징을 설명하면서 몇몇 프로젝트를 더 언급하는데, 요건 각자 한번 읽어보셔도 좋을 듯 (베리에이셔널, 익텐, 펄, 엔트로피 등)
여튼 크립토 유저라면 프로젝트를 평가할 때 한 번쯤 생각해봤을 법한 내용이라 다들 재밌게 읽어보실 수 있을 듯!
토큰을 만들고 단기적으로 가격을 펌핑하는 방법은 너무 잘 알려졌는데, 이런 것 말고 과연 사람들이 1년 이상 들고 있을 만한 토큰은 어떤 것인가?에 대한 글
작성자는 오래 살아남는 토큰을 크게 사람들의 "믿음으로 버티는 자산 / 실제로 돈을 벌어 홀더에게 돌려주는 자산"이라는 두 가지 관점에서 설명함
1) 믿음으로 살아남으려면 상징적인 인물, 죽었다 살아난 경험, 초기 홀더를 부자로 만든 역사와 커뮤니티 등이 필요
예를 들어, 하이퍼리퀴드 에어드랍을 통해 증거금 청산을 복구한 사례, 라이터 블라드와 같은 신앙적 설립자 등등
2) 반면 현금흐름으로 살아남으려면, 지속적으로 돈을 버는지 → 그걸 검증할 수 있는지 → 그 돈이 토큰에 돌아오는지를 봐야 함
특히 사업이 잘된다고 토큰도 좋은 것은 아니며, 이익은 지분 보유자가 가져가고 토큰 홀더에게는 기대감만 남을 수도 있다는 것
개인적으로는 마지막 부분이 생각해볼 거리가 많다고 느껴짐
> 초기 프로젝트가 번 돈을 전부 바이백에 쓰는 게 항상 좋은 건 아니고, 성장에 재투자하는 게 더 나을 수도 있음
> 다만 그렇게 커진 사업의 가치가 나중에 어떻게 토큰에 돌아오는지 불명확하다면, 홀더는 사업의 성공뿐 아니라 ‘성공한 뒤 팀이 그걸 나눠줄 의지’까지 같이 믿고 있는 셈이라는 것
> 최근 바이백을 진행하겠다고 나서는 팀들도 이 부분과 연결해서 볼 수 있지 않나 싶고, 실제로 가격 반응이 좋았던 프로젝트들도 많음 ($CHIP, $ATH, $ENA, $ZRO 등등)
그리고 결과적으로 작성자는 $HYPE 를 가장 높게 평가함 → 실제 수익이 토큰 매수로 연결되는 구조가 있으면서도, 초기 참여자들의 수익 경험, 커뮤니티, 상징적인 인물 등 믿음 쪽 요소도 함께 갖추고 있기 때문
이외에도 각 카테고리나 특징을 설명하면서 몇몇 프로젝트를 더 언급하는데, 요건 각자 한번 읽어보셔도 좋을 듯 (베리에이셔널, 익텐, 펄, 엔트로피 등)
여튼 크립토 유저라면 프로젝트를 평가할 때 한 번쯤 생각해봤을 법한 내용이라 다들 재밌게 읽어보실 수 있을 듯!
Forwarded from 언제 일일이 손으로 다하냐
바이브코딩을 하면서 가장 크게 느끼는 장벽은 용어와 개념이다.
막연하게 원하는 것은 있다. 이런 기능이 있었으면 좋겠고, 이 과정이 조금 더 편해졌으면 좋겠고, 머릿속에 있는 무언가가 실제로 돌아갔으면 좋겠다. 어떻게 만드는지는 잘 모르겠지만, 그 부분은 에이전트가 알아서 해주기를 기대한다.
그런데 요구사항이 항상 일반적인 것은 아니다. 여러 조건이 복잡하게 얽혀 있기도 하고, 설명하는 사람조차 무엇을 원하는지 정확히 모를 때도 있다. 분명 머릿속에는 어떤 모습이 있는데, 말로 꺼내놓으면 이상하게 중요한 부분이 빠져 있다.
그래도 에이전트는 일을 한다. 전달받은 요구사항을 나름의 방식으로 이해하고, 비어 있는 부분을 채우고, 코드를 작성한다. 그리고 매우 친절하게 설명한다. 어떤 작업을 했고, 어떤 구조를 선택했으며, 무엇을 개선했는지. 테스트를 통과했다는 말도 덧붙인다.
여기서 묘한 안도감이 생긴다. 설명이 정돈되어 있고, 작업 내역이 구체적이며, 내가 미처 생각하지 못한 부분까지 챙긴 것처럼 보인다. 그런데 설명을 끝까지 읽고 나서도 어딘가 찜찜하다. 작업을 많이 했다는 것은 알겠는데, 그 작업이 내가 원했던 방향인지는 여전히 확신하기 어렵다.
나는 개발자다. 코드를 읽을 수 있고, 익숙한 영역에서는 구현이 적절한지 판단할 수 있다. 그런데도 낯선 분야의 작업을 맡기면 비슷한 순간을 만난다. 문장은 읽히는데, 그 문장에 담긴 선택의 무게가 잘 느껴지지 않는다. 각각의 단어는 검색하면 나오지만, 왜 지금 이 선택을 했는지, 다른 선택을 했다면 무엇이 달라지는지까지 이해하려면 시간이 필요하다.
그래서 개발 경험이 없는 사람이 에이전트의 작업 보고를 읽는 상황을 생각하게 된다. 요구사항을 전달할 때 한 번 막히고, 결과를 설명받을 때 다시 막힌다. 처음에는 무엇이라고 요청해야 할지 몰랐고, 나중에는 무엇을 확인해야 할지 모른다. 그 사이에서 에이전트는 열심히 일했다.
가령 “오류가 나면 자동으로 다시 시도하게 해줘”라는 요청을 했다고 해보자. 사용하는 사람 입장에서는 자연스러운 요구다. 잠깐 문제가 생겼다고 매번 버튼을 다시 누르고 싶지는 않으니까.
그런데 여기에는 서로 다른 상황이 들어 있다. 요청이 서버에 도착하지 않았을 수도 있고, 서버가 요청을 거절했을 수도 있다. 서버에서는 이미 처리가 끝났는데, 완료됐다는 응답만 돌아오지 않았을 수도 있다. 화면에는 모두 비슷한 오류로 보이지만, 다음에 해야 할 일은 달라질 수 있다.
예약 신청이 이미 처리된 상태에서 같은 요청을 다시 보내면 어떻게 될까. 사용자는 한 번 신청했다고 생각하는데, 시스템에는 두 번 접수될 수도 있다. 이때 필요한 것은 단순히 재시도 횟수를 늘리는 것보다 구체적인 판단이다. 어떤 실패에 다시 시도할 것인지, 이미 처리된 요청은 어떻게 알아볼 것인지, 결과를 확인할 수 없는 동안 사용자에게 무엇을 보여줄 것인지.
에이전트가 “재시도 로직과 멱등성을 적용했습니다”라고 설명하면 작업은 꽤 잘 마무리된 것처럼 들린다. 하지만 멱등성이라는 단어가 낯선 사람에게는 그 문장도 또 하나의 숙제다. 같은 요청을 여러 번 보내도 한 번 처리했을 때와 같은 효과를 유지한다는 뜻을 알아야, 비로소 다음 질문을 할 수 있다. 어디까지 같은 요청으로 보는지. 시간이 지난 뒤 다시 보낸 요청도 같은 것으로 취급하는지. 그 처리가 실제로 확인됐는지.
이런 순간에 용어를 안다는 것의 의미를 다시 생각한다. 개발하면서 쓰는 단어들에는 반복해서 겪었던 문제가 압축되어 있다. 어떤 일이 잘못될 수 있고, 그것을 어떤 방식으로 다뤄왔는지에 대한 흔적이 들어 있다. 단어 하나를 이해하면 이전에는 보이지 않던 갈림길이 보이기 시작한다.
물론 단어를 외우는 것만으로 판단이 생기지는 않는다. 나도 설명에 등장한 용어를 알아듣는다는 이유로, 설명 전체를 이해했다고 착각할 수 있다. 캐시가 무엇인지 아는 것과 이 서비스에서 얼마나 오래된 정보를 허용해도 되는지 결정하는 일에는 차이가 있다. 인증이 무엇인지 아는 것과 누가 어떤 정보까지 볼 수 있어야 하는지 정하는 일에도 차이가 있다.
결국 그 선택은 내가 만들려는 것의 성격으로 돌아온다. 조금 늦어도 정확해야 하는지, 잠시 오래된 정보가 보여도 빠른 편이 나은지. 사용자가 실수했을 때 되돌릴 수 있어야 하는지, 한 번 확정한 뒤에는 바꿀 수 없어야 하는지. 이런 질문에는 프로젝트마다 다른 답이 있다.
그런데 처음 요구사항을 적을 때는 여기까지 생각하기 어렵다. 보통은 잘되는 장면부터 떠올린다. 버튼을 누르면 저장되고, 로그인하면 내 정보가 나오고, 신청하면 완료 화면이 뜬다. 중간에 연결이 끊기거나, 버튼을 두 번 누르거나, 서로 다른 사람이 같은 정보를 동시에 바꾸는 장면은 나중에 생각난다.
직접 구현할 때는 이런 문제와 부딪히며 생각을 구체화한다. 어떤 값을 저장할지 정하다가 요구사항의 빈틈을 발견하고, 오류를 처리하다가 애초에 결정하지 않은 조건을 만나기도 한다. 귀찮고 더디지만, 코드를 쓰는 과정에서 내가 만들고 있는 것을 이해하게 되는 부분이 있다.
에이전트는 그 구간을 빠르게 통과한다. 덕분에 훨씬 적은 수고로 결과물을 볼 수 있다. 동시에 내가 충분히 생각해보지 않은 선택까지 이미 코드 안에 들어가 있을 수 있다. 에이전트가 선택한 기본값과 관행이 쌓여서 하나의 서비스가 된다.
그 결과를 보면서 “내가 원한 건 이게 아닌데”라고 느낄 때가 있다. 하지만 처음 전달했던 문장을 다시 읽어보면, 지금 불만인 부분을 설명한 적이 없기도 하다. 내 머릿속에서는 너무 당연해서 말하지 않았던 조건이다. 또는 실제 화면을 보고 나서야 중요하다는 사실을 알게 된 조건이다.
이럴 때는 누구의 잘못인지부터 가리기 어렵다. 에이전트가 성급하게 판단한 부분도 있고, 내가 막연하게 넘긴 부분도 있다. 무엇보다 처음부터 완성된 요구사항이 내 안에 있었는지조차 돌아보게 된다. 나는 원하는 것을 전달하고 있다고 생각했지만, 사실은 원하는 것을 함께 찾아가는 중이었을 수 있다.
나는 이 과정 자체에는 큰 가치가 있다고 느낀다. 머릿속으로 생각할 때와 실제로 눌러보며 확인할 때는 다르다. 작동하는 결과물을 보고 나면 없던 질문이 생긴다. 이 버튼은 왜 여기에 있어야 하는지, 이 정보는 정말 필요한지, 이 과정은 왜 두 번 거쳐야 하는지. 막연했던 생각에 구체적인 모양이 생기면서 판단도 조금씩 가능해진다.
다만 결과물이 빨리 나온다고 해서 판단까지 같은 속도로 끝나지는 않는다.
에이전트가 바꾼 내용을 읽고, 실행해보고, 내가 중요하게 생각하는 상황에서도 제대로 동작하는지 확인하는 일은 여전히 남아 있다. 작업을 맡기는 속도에 비해 이해하는 속도가 느려지면, 어느 순간 내가 설명할 수 없는 부분이 계속 늘어난다. 기능은 많아졌는데 전체를 다루기는 오히려 어려워질 수 있다.
나에게도 이 부분은 부담스럽다. 직접 작성한 코드는 적어도 왜 그렇게 썼는지에 대한 기억이 남는다. 에이전트가 작성한 코드는 그 판단의 맥락을 별도로 읽어야 한다. 수정된 파일이 많고 설명이 길수록, 꼼꼼하게 확인했다는 감각과 실제로 이해한 범위가 어긋나기 쉽다.
“테스트를 통과했습니다”라는 말도 비슷하게 받아들이게 된다. 반가운 말이지만, 무엇을 확인한 테스트인지는 알아야 한다. 내가 중요하게 생각한 상황이 빠져 있다면 그 부분은 여전히 모르는 상태다. 에이전트가 요구사항을 다르게 이해했다면, 그 이해를 기준으로 작성된 테스트는 통과할 수도 있다.
이런 경험을 생각하다 보면, 에이전트에게 요청하는 방식도 조금 달라져야겠다는 생각이 든다. 구현 방법을 길게 지시하기 전에, 내가 무엇을 중요하게 여기는지부터 분명히 할 필요가 있다. 사용자가 입력한 내용은 사라지면 안 된다. 처리 여부가 확인되지 않았는데 완료됐다고 보여주면 안 된다. 화면은 단순해도 괜찮지만, 잘못된 상태를 정상처럼 보이게 해서는 안 된다.
이런 문장은 어려운 기술 용어 없이도 쓸 수 있다. 그리고 구현하는 쪽에서 어떤 선택을 해야 하는지 판단하는 데 도움이 된다. 모든 세부사항을 알고 시작할 수는 없어도, 어떤 결과를 받아들일 수 없는지는 생각해볼 수 있다.
설명을 요청할 때도 마찬가지다. 사용한 기술의 이름만 나열되면 여전히 멀게 느껴진다. 그 선택 때문에 사용자가 무엇을 경험하게 되는지, 문제가 생겼을 때 어떤 일이 벌어지는지까지 연결되어야 이해가 된다. 전문 용어를 쉬운 말로 바꿔달라는 요청에 더해, 실제 상황을 하나 들어 설명해달라고 할 필요가 있다.
에이전트가 판단한 부분도 드러나면 좋겠다. 내가 명시한 요구사항과, 작업을 진행하기 위해 에이전트가 가정한 조건이 구분되어 있으면 확인하기가 한결 수월하다. 특히 나중에 바꾸기 어렵거나 다른 기능에 영향을 많이 주는 선택은 먼저 질문해주기를 바라게 된다.
그렇다고 사소한 것까지 전부 물어보는 에이전트가 편한 것도 아니다. 맡길 수 있는 일을 맡기려고 사용하는데, 모든 결정을 다시 돌려받으면 금방 지친다. 적당히 알아서 해줬으면 하는 마음과, 중요한 것은 내 의도를 확인해줬으면 하는 마음이 동시에 있다. 어떤 부분을 맡겨도 되는지 서로 맞춰가는 과정이 필요하다고 느낀다.
그래서 바이브코딩을 하려면 어디까지 공부해야 하는지에 대한 질문에도 쉽게 답하기 어렵다. 시작하기 전에 개발자가 배우는 모든 것을 공부할 필요는 없다고 생각한다. 실제로 무언가를 만들어볼 수 있는 기회가 넓어진 것은 반가운 일이다. 작은 불편을 해결하는 도구 하나를 만드는 데 반드시 긴 준비 과정이 필요한 것은 아니다.
다만 만들다 보면 이해가 필요한 순간을 만나게 된다. 그때 용어와 개념이 내 일에 연결된다. 저장한 내용이 사라지고 나서야 데이터가 어디에 남는지 궁금해지고, 여러 사람이 사용하기 시작하면 권한이라는 말이 구체적으로 느껴진다. 같은 동작이 두 번 실행되는 문제를 겪으면 중복 처리라는 단어를 이전과 다르게 읽게 된다.
그렇게 배우는 것은 기억에도 오래 남을 것 같다. 내가 해결하려는 문제가 있고, 그 문제를 설명하는 이름을 뒤늦게 만나는 경험이기 때문이다. 에이전트는 구현을 도와주는 동시에, 지금 눈앞에서 벌어진 일을 설명해줄 수도 있다. 조금씩 이해가 쌓이면 다음 요청은 더 구체적이 되고, 결과를 확인할 때도 더 나은 질문을 할 수 있다.
나 역시 그 과정에서 예외가 아니다. 익숙한 기술을 사용한다는 이유로 요구사항까지 명확하다고 생각하지 않으려 한다. 코드를 읽을 수 있다는 자신감 때문에 사용자가 실제로 겪을 상황을 건너뛰고 있지는 않은지도 돌아보게 된다. 에이전트가 구현을 빠르게 해줄수록, 내가 무엇을 만들고 있는지 설명할 수 있어야 한다는 부담은 오히려 더 또렷해진다.
아직도 에이전트가 알아서 잘해주기를 바란다. 반복되는 작업은 맡기고 싶고, 익숙하지 않은 분야에서도 도움을 받고 싶다. 설명이 친절하고 결과가 빨리 나오는 것도 좋다.
다만 작업이 끝났다는 말을 들었을 때, 잠깐 더 들여다보고 싶다. 내가 요청한 문장이 어떤 의미로 구현되었는지. 설명을 읽고 고개를 끄덕인 부분을 정말 이해했는지. 지금 보이는 결과가 내가 원했던 것에 가까워졌는지.
바이브코딩을 통해 결과물과 함께 내 생각도 조금씩 구체적이 되었으면 한다. 처음에는 막연하게 “이런 게 있었으면 좋겠다”고 말했더라도, 마지막에는 무엇이 필요했고 왜 이렇게 만들었는지 내 말로 설명할 수 있으면 좋겠다.
에이전트와 일하면서 내가 얻고 싶은 감각은 그쪽에 가깝다.
막연하게 원하는 것은 있다. 이런 기능이 있었으면 좋겠고, 이 과정이 조금 더 편해졌으면 좋겠고, 머릿속에 있는 무언가가 실제로 돌아갔으면 좋겠다. 어떻게 만드는지는 잘 모르겠지만, 그 부분은 에이전트가 알아서 해주기를 기대한다.
그런데 요구사항이 항상 일반적인 것은 아니다. 여러 조건이 복잡하게 얽혀 있기도 하고, 설명하는 사람조차 무엇을 원하는지 정확히 모를 때도 있다. 분명 머릿속에는 어떤 모습이 있는데, 말로 꺼내놓으면 이상하게 중요한 부분이 빠져 있다.
그래도 에이전트는 일을 한다. 전달받은 요구사항을 나름의 방식으로 이해하고, 비어 있는 부분을 채우고, 코드를 작성한다. 그리고 매우 친절하게 설명한다. 어떤 작업을 했고, 어떤 구조를 선택했으며, 무엇을 개선했는지. 테스트를 통과했다는 말도 덧붙인다.
여기서 묘한 안도감이 생긴다. 설명이 정돈되어 있고, 작업 내역이 구체적이며, 내가 미처 생각하지 못한 부분까지 챙긴 것처럼 보인다. 그런데 설명을 끝까지 읽고 나서도 어딘가 찜찜하다. 작업을 많이 했다는 것은 알겠는데, 그 작업이 내가 원했던 방향인지는 여전히 확신하기 어렵다.
나는 개발자다. 코드를 읽을 수 있고, 익숙한 영역에서는 구현이 적절한지 판단할 수 있다. 그런데도 낯선 분야의 작업을 맡기면 비슷한 순간을 만난다. 문장은 읽히는데, 그 문장에 담긴 선택의 무게가 잘 느껴지지 않는다. 각각의 단어는 검색하면 나오지만, 왜 지금 이 선택을 했는지, 다른 선택을 했다면 무엇이 달라지는지까지 이해하려면 시간이 필요하다.
그래서 개발 경험이 없는 사람이 에이전트의 작업 보고를 읽는 상황을 생각하게 된다. 요구사항을 전달할 때 한 번 막히고, 결과를 설명받을 때 다시 막힌다. 처음에는 무엇이라고 요청해야 할지 몰랐고, 나중에는 무엇을 확인해야 할지 모른다. 그 사이에서 에이전트는 열심히 일했다.
가령 “오류가 나면 자동으로 다시 시도하게 해줘”라는 요청을 했다고 해보자. 사용하는 사람 입장에서는 자연스러운 요구다. 잠깐 문제가 생겼다고 매번 버튼을 다시 누르고 싶지는 않으니까.
그런데 여기에는 서로 다른 상황이 들어 있다. 요청이 서버에 도착하지 않았을 수도 있고, 서버가 요청을 거절했을 수도 있다. 서버에서는 이미 처리가 끝났는데, 완료됐다는 응답만 돌아오지 않았을 수도 있다. 화면에는 모두 비슷한 오류로 보이지만, 다음에 해야 할 일은 달라질 수 있다.
예약 신청이 이미 처리된 상태에서 같은 요청을 다시 보내면 어떻게 될까. 사용자는 한 번 신청했다고 생각하는데, 시스템에는 두 번 접수될 수도 있다. 이때 필요한 것은 단순히 재시도 횟수를 늘리는 것보다 구체적인 판단이다. 어떤 실패에 다시 시도할 것인지, 이미 처리된 요청은 어떻게 알아볼 것인지, 결과를 확인할 수 없는 동안 사용자에게 무엇을 보여줄 것인지.
에이전트가 “재시도 로직과 멱등성을 적용했습니다”라고 설명하면 작업은 꽤 잘 마무리된 것처럼 들린다. 하지만 멱등성이라는 단어가 낯선 사람에게는 그 문장도 또 하나의 숙제다. 같은 요청을 여러 번 보내도 한 번 처리했을 때와 같은 효과를 유지한다는 뜻을 알아야, 비로소 다음 질문을 할 수 있다. 어디까지 같은 요청으로 보는지. 시간이 지난 뒤 다시 보낸 요청도 같은 것으로 취급하는지. 그 처리가 실제로 확인됐는지.
이런 순간에 용어를 안다는 것의 의미를 다시 생각한다. 개발하면서 쓰는 단어들에는 반복해서 겪었던 문제가 압축되어 있다. 어떤 일이 잘못될 수 있고, 그것을 어떤 방식으로 다뤄왔는지에 대한 흔적이 들어 있다. 단어 하나를 이해하면 이전에는 보이지 않던 갈림길이 보이기 시작한다.
물론 단어를 외우는 것만으로 판단이 생기지는 않는다. 나도 설명에 등장한 용어를 알아듣는다는 이유로, 설명 전체를 이해했다고 착각할 수 있다. 캐시가 무엇인지 아는 것과 이 서비스에서 얼마나 오래된 정보를 허용해도 되는지 결정하는 일에는 차이가 있다. 인증이 무엇인지 아는 것과 누가 어떤 정보까지 볼 수 있어야 하는지 정하는 일에도 차이가 있다.
결국 그 선택은 내가 만들려는 것의 성격으로 돌아온다. 조금 늦어도 정확해야 하는지, 잠시 오래된 정보가 보여도 빠른 편이 나은지. 사용자가 실수했을 때 되돌릴 수 있어야 하는지, 한 번 확정한 뒤에는 바꿀 수 없어야 하는지. 이런 질문에는 프로젝트마다 다른 답이 있다.
그런데 처음 요구사항을 적을 때는 여기까지 생각하기 어렵다. 보통은 잘되는 장면부터 떠올린다. 버튼을 누르면 저장되고, 로그인하면 내 정보가 나오고, 신청하면 완료 화면이 뜬다. 중간에 연결이 끊기거나, 버튼을 두 번 누르거나, 서로 다른 사람이 같은 정보를 동시에 바꾸는 장면은 나중에 생각난다.
직접 구현할 때는 이런 문제와 부딪히며 생각을 구체화한다. 어떤 값을 저장할지 정하다가 요구사항의 빈틈을 발견하고, 오류를 처리하다가 애초에 결정하지 않은 조건을 만나기도 한다. 귀찮고 더디지만, 코드를 쓰는 과정에서 내가 만들고 있는 것을 이해하게 되는 부분이 있다.
에이전트는 그 구간을 빠르게 통과한다. 덕분에 훨씬 적은 수고로 결과물을 볼 수 있다. 동시에 내가 충분히 생각해보지 않은 선택까지 이미 코드 안에 들어가 있을 수 있다. 에이전트가 선택한 기본값과 관행이 쌓여서 하나의 서비스가 된다.
그 결과를 보면서 “내가 원한 건 이게 아닌데”라고 느낄 때가 있다. 하지만 처음 전달했던 문장을 다시 읽어보면, 지금 불만인 부분을 설명한 적이 없기도 하다. 내 머릿속에서는 너무 당연해서 말하지 않았던 조건이다. 또는 실제 화면을 보고 나서야 중요하다는 사실을 알게 된 조건이다.
이럴 때는 누구의 잘못인지부터 가리기 어렵다. 에이전트가 성급하게 판단한 부분도 있고, 내가 막연하게 넘긴 부분도 있다. 무엇보다 처음부터 완성된 요구사항이 내 안에 있었는지조차 돌아보게 된다. 나는 원하는 것을 전달하고 있다고 생각했지만, 사실은 원하는 것을 함께 찾아가는 중이었을 수 있다.
나는 이 과정 자체에는 큰 가치가 있다고 느낀다. 머릿속으로 생각할 때와 실제로 눌러보며 확인할 때는 다르다. 작동하는 결과물을 보고 나면 없던 질문이 생긴다. 이 버튼은 왜 여기에 있어야 하는지, 이 정보는 정말 필요한지, 이 과정은 왜 두 번 거쳐야 하는지. 막연했던 생각에 구체적인 모양이 생기면서 판단도 조금씩 가능해진다.
다만 결과물이 빨리 나온다고 해서 판단까지 같은 속도로 끝나지는 않는다.
에이전트가 바꾼 내용을 읽고, 실행해보고, 내가 중요하게 생각하는 상황에서도 제대로 동작하는지 확인하는 일은 여전히 남아 있다. 작업을 맡기는 속도에 비해 이해하는 속도가 느려지면, 어느 순간 내가 설명할 수 없는 부분이 계속 늘어난다. 기능은 많아졌는데 전체를 다루기는 오히려 어려워질 수 있다.
나에게도 이 부분은 부담스럽다. 직접 작성한 코드는 적어도 왜 그렇게 썼는지에 대한 기억이 남는다. 에이전트가 작성한 코드는 그 판단의 맥락을 별도로 읽어야 한다. 수정된 파일이 많고 설명이 길수록, 꼼꼼하게 확인했다는 감각과 실제로 이해한 범위가 어긋나기 쉽다.
“테스트를 통과했습니다”라는 말도 비슷하게 받아들이게 된다. 반가운 말이지만, 무엇을 확인한 테스트인지는 알아야 한다. 내가 중요하게 생각한 상황이 빠져 있다면 그 부분은 여전히 모르는 상태다. 에이전트가 요구사항을 다르게 이해했다면, 그 이해를 기준으로 작성된 테스트는 통과할 수도 있다.
이런 경험을 생각하다 보면, 에이전트에게 요청하는 방식도 조금 달라져야겠다는 생각이 든다. 구현 방법을 길게 지시하기 전에, 내가 무엇을 중요하게 여기는지부터 분명히 할 필요가 있다. 사용자가 입력한 내용은 사라지면 안 된다. 처리 여부가 확인되지 않았는데 완료됐다고 보여주면 안 된다. 화면은 단순해도 괜찮지만, 잘못된 상태를 정상처럼 보이게 해서는 안 된다.
이런 문장은 어려운 기술 용어 없이도 쓸 수 있다. 그리고 구현하는 쪽에서 어떤 선택을 해야 하는지 판단하는 데 도움이 된다. 모든 세부사항을 알고 시작할 수는 없어도, 어떤 결과를 받아들일 수 없는지는 생각해볼 수 있다.
설명을 요청할 때도 마찬가지다. 사용한 기술의 이름만 나열되면 여전히 멀게 느껴진다. 그 선택 때문에 사용자가 무엇을 경험하게 되는지, 문제가 생겼을 때 어떤 일이 벌어지는지까지 연결되어야 이해가 된다. 전문 용어를 쉬운 말로 바꿔달라는 요청에 더해, 실제 상황을 하나 들어 설명해달라고 할 필요가 있다.
에이전트가 판단한 부분도 드러나면 좋겠다. 내가 명시한 요구사항과, 작업을 진행하기 위해 에이전트가 가정한 조건이 구분되어 있으면 확인하기가 한결 수월하다. 특히 나중에 바꾸기 어렵거나 다른 기능에 영향을 많이 주는 선택은 먼저 질문해주기를 바라게 된다.
그렇다고 사소한 것까지 전부 물어보는 에이전트가 편한 것도 아니다. 맡길 수 있는 일을 맡기려고 사용하는데, 모든 결정을 다시 돌려받으면 금방 지친다. 적당히 알아서 해줬으면 하는 마음과, 중요한 것은 내 의도를 확인해줬으면 하는 마음이 동시에 있다. 어떤 부분을 맡겨도 되는지 서로 맞춰가는 과정이 필요하다고 느낀다.
그래서 바이브코딩을 하려면 어디까지 공부해야 하는지에 대한 질문에도 쉽게 답하기 어렵다. 시작하기 전에 개발자가 배우는 모든 것을 공부할 필요는 없다고 생각한다. 실제로 무언가를 만들어볼 수 있는 기회가 넓어진 것은 반가운 일이다. 작은 불편을 해결하는 도구 하나를 만드는 데 반드시 긴 준비 과정이 필요한 것은 아니다.
다만 만들다 보면 이해가 필요한 순간을 만나게 된다. 그때 용어와 개념이 내 일에 연결된다. 저장한 내용이 사라지고 나서야 데이터가 어디에 남는지 궁금해지고, 여러 사람이 사용하기 시작하면 권한이라는 말이 구체적으로 느껴진다. 같은 동작이 두 번 실행되는 문제를 겪으면 중복 처리라는 단어를 이전과 다르게 읽게 된다.
그렇게 배우는 것은 기억에도 오래 남을 것 같다. 내가 해결하려는 문제가 있고, 그 문제를 설명하는 이름을 뒤늦게 만나는 경험이기 때문이다. 에이전트는 구현을 도와주는 동시에, 지금 눈앞에서 벌어진 일을 설명해줄 수도 있다. 조금씩 이해가 쌓이면 다음 요청은 더 구체적이 되고, 결과를 확인할 때도 더 나은 질문을 할 수 있다.
나 역시 그 과정에서 예외가 아니다. 익숙한 기술을 사용한다는 이유로 요구사항까지 명확하다고 생각하지 않으려 한다. 코드를 읽을 수 있다는 자신감 때문에 사용자가 실제로 겪을 상황을 건너뛰고 있지는 않은지도 돌아보게 된다. 에이전트가 구현을 빠르게 해줄수록, 내가 무엇을 만들고 있는지 설명할 수 있어야 한다는 부담은 오히려 더 또렷해진다.
아직도 에이전트가 알아서 잘해주기를 바란다. 반복되는 작업은 맡기고 싶고, 익숙하지 않은 분야에서도 도움을 받고 싶다. 설명이 친절하고 결과가 빨리 나오는 것도 좋다.
다만 작업이 끝났다는 말을 들었을 때, 잠깐 더 들여다보고 싶다. 내가 요청한 문장이 어떤 의미로 구현되었는지. 설명을 읽고 고개를 끄덕인 부분을 정말 이해했는지. 지금 보이는 결과가 내가 원했던 것에 가까워졌는지.
바이브코딩을 통해 결과물과 함께 내 생각도 조금씩 구체적이 되었으면 한다. 처음에는 막연하게 “이런 게 있었으면 좋겠다”고 말했더라도, 마지막에는 무엇이 필요했고 왜 이렇게 만들었는지 내 말로 설명할 수 있으면 좋겠다.
에이전트와 일하면서 내가 얻고 싶은 감각은 그쪽에 가깝다.
앤트로픽, AI 개발 도구·요금제 변경 소식
: Antigravity가 Android Studio에서 제공되며, 백그라운드 작업용 Running 탭을 테스트 중이다.
: Google Cloud 할당량에 GPT 모델이 등장했다.
: Omni Flash 1.2에서 1080p·4K 출력, 프레임 보간·영상 확장 기능이 포착됐다.
: Anthropic의 Max 5x는 Max(100달러), Max 20x는 Ultra(200달러)로 변경됐으며, 인증된 Ultra에는 5시간 제한이 없다.
https://x.com/testingcatalog/status/2116472441211933144
: Antigravity가 Android Studio에서 제공되며, 백그라운드 작업용 Running 탭을 테스트 중이다.
: Google Cloud 할당량에 GPT 모델이 등장했다.
: Omni Flash 1.2에서 1080p·4K 출력, 프레임 보간·영상 확장 기능이 포착됐다.
: Anthropic의 Max 5x는 Max(100달러), Max 20x는 Ultra(200달러)로 변경됐으며, 인증된 Ultra에는 5시간 제한이 없다.
https://x.com/testingcatalog/status/2116472441211933144
X (formerly Twitter)
🚨 AI News | TestingCatalog (@testingcatalog) on X
DAILY AI BRIEF 🗞 — Oct 31
GOOGLE 🔥:
- Antigravity is now available in Android Studio.
- Antigravity is testing a Running tab for background tasks (via testingcatalog).
- Varun Mohan teased a bi…
GOOGLE 🔥:
- Antigravity is now available in Android Studio.
- Antigravity is testing a Running tab for background tasks (via testingcatalog).
- Varun Mohan teased a bi…
인터컨티넨털익스체인지, 하이퍼리퀴드 기반 무기한 선물 미국 출시 추진
: ICE와 Trade[XYZ]는 규제 승인 조건으로 미국 규제 체계 내 무기한 선물 시장 운영을 추진한다.
: 새 거래 플랫폼은 ICE의 기관용 선물 사업과 별도로 운영하며 개인 투자자 참여에 맞춰 설계한다.
: 출시 후 미국 트레이더에게 암호화폐·주식·지수·원자재·외환의 연중무휴 24시간 거래를 제공할 계획이다.
: 이용자는 고객확인·자금세탁방지 심사를 수행하는 미국 규제 선물중개회사(FCM)를 통해 접속한다.
https://x.com/ICE_Markets/status/2116494325265674252
: ICE와 Trade[XYZ]는 규제 승인 조건으로 미국 규제 체계 내 무기한 선물 시장 운영을 추진한다.
: 새 거래 플랫폼은 ICE의 기관용 선물 사업과 별도로 운영하며 개인 투자자 참여에 맞춰 설계한다.
: 출시 후 미국 트레이더에게 암호화폐·주식·지수·원자재·외환의 연중무휴 24시간 거래를 제공할 계획이다.
: 이용자는 고객확인·자금세탁방지 심사를 수행하는 미국 규제 선물중개회사(FCM)를 통해 접속한다.
https://x.com/ICE_Markets/status/2116494325265674252
X (formerly Twitter)
ICE (@ICE_Markets) on X
ICE and Trade[XYZ] plan to bring Hyperliquid-based perps to the U.S.
Subject to regulatory approvals, ICE will operate U.S. regulated versions of Trade[XYZ]’s markets, leveraging their expertise…
Subject to regulatory approvals, ICE will operate U.S. regulated versions of Trade[XYZ]’s markets, leveraging their expertise…
Glassnode | Strategy Watch #9: 디지털 자산 기관 자금 흐름과 전략 성과
• 비트코인 30일 순유입은 9월 22일 약 135억 달러로 지난해 11월 이후 최대치를 기록했다.
• 방향성 전략 수익률은 10.35%, 이벤트 드리븐 전략은 21.70%, 시장 중립 전략은 0.98%였다.
• 운용사 평균 현금 비중은 19.1%에서 12.2%로 하락했고, 집계된 온체인 볼트 예치금은 약 15% 증가한 98억 달러로 2025년 11월 이후 최대였다.
📄 https://research.glassnode.com/strategy-watch-09-2026/
• 비트코인 30일 순유입은 9월 22일 약 135억 달러로 지난해 11월 이후 최대치를 기록했다.
• 방향성 전략 수익률은 10.35%, 이벤트 드리븐 전략은 21.70%, 시장 중립 전략은 0.98%였다.
• 운용사 평균 현금 비중은 19.1%에서 12.2%로 하락했고, 집계된 온체인 볼트 예치금은 약 15% 증가한 98억 달러로 2025년 11월 이후 최대였다.
📄 https://research.glassnode.com/strategy-watch-09-2026/
Binance, 보안 사고 복구 계획 공개…약 34시간 내 출금 재개 목표
• 출금은 단계적으로 재개하며 각 단계가 준비될 때마다 안내할 예정이다.
• 손실 토큰 자산의 잔여 20%를 매입 중이다.
• 12시간 뒤 첫 준비금 증명 스냅샷을 진행하고 2026년 11월 2일 월요일까지 결과를 준비할 계획이다.
• 동결된 도난 자금 회수를 위해 법 집행기관과 협력 중이다.
https://x.com/binance/status/2116258356109496479
• 출금은 단계적으로 재개하며 각 단계가 준비될 때마다 안내할 예정이다.
• 손실 토큰 자산의 잔여 20%를 매입 중이다.
• 12시간 뒤 첫 준비금 증명 스냅샷을 진행하고 2026년 11월 2일 월요일까지 결과를 준비할 계획이다.
• 동결된 도난 자금 회수를 위해 법 집행기관과 협력 중이다.
https://x.com/binance/status/2116258356109496479
X (formerly Twitter)
Binance on X: "Security Incident | Recovery Update #2" / X
Binance, 해킹 손실 90% 충당…상위 10개 자산은 100% 확보
• BTC, ETH, USDT, BNB, SOL, USDC, XRP, USD1, RLUSD, ZEC는 100% 충당됐다.
• 남은 10%는 상위 10개 외 유동성이 낮은 토큰으로, 시장·OTC를 통해 계속 매입 중이다.
• 손실은 이용자가 아닌 바이낸스가 부담한다.
• 재원은 SAFU 일부(향후 24시간 내 집행), 선물 보험기금 초과분, 회사 자금이며, SAFU는 약 10억 달러 규모로 다시 채운다.
• 10월 31일 00:00(UTC) 기준 준비금 증명(PoR) 스냅샷을 반영했고, 영지식 증명은 11월 3일(UTC)까지 생성될 예정이다.
• 출금 재개는 기존 일정대로 11월 1일(일) 목표다.
https://x.com/binance/status/2116538196259684457
• BTC, ETH, USDT, BNB, SOL, USDC, XRP, USD1, RLUSD, ZEC는 100% 충당됐다.
• 남은 10%는 상위 10개 외 유동성이 낮은 토큰으로, 시장·OTC를 통해 계속 매입 중이다.
• 손실은 이용자가 아닌 바이낸스가 부담한다.
• 재원은 SAFU 일부(향후 24시간 내 집행), 선물 보험기금 초과분, 회사 자금이며, SAFU는 약 10억 달러 규모로 다시 채운다.
• 10월 31일 00:00(UTC) 기준 준비금 증명(PoR) 스냅샷을 반영했고, 영지식 증명은 11월 3일(UTC)까지 생성될 예정이다.
• 출금 재개는 기존 일정대로 11월 1일(일) 목표다.
https://x.com/binance/status/2116538196259684457
X (formerly Twitter)
Binance on X: "Security Incident | Update #3: 90% of Stolen Assets Replenished; Proof of Reserves Snapshot Provided" / X
Forwarded from 돈포하 I Dont focus on hype
바이낸스 해커가 팔 때마다 숏을 쳤으면 어땠을까. 👀
일단, $ENA같은 매도 & 시총 규모가 큰 토큰보다는 시총이 작은 토큰에 집중해서
매도 노셔널이 $10M 이하인 토큰만 따로 집계해봤는데,
총 99개 중 75개가 매도 시점 대비 60분 뒤 하락했고,
하락한 토큰들의 평균 하락률이 약 2.7%였음.
대상 토큰당 평균 매도 규모는 약 $1.1M.
현재 매도가 모두 끝났으므로, 당시 흐름이 궁금했던 분들은 하나씩 눌러보시면 좋을듯.
이런 건 시간이 지나고 나서라도 참고해두면,
다음에 비슷한 상황이 왔을 때 큰 도움 될 것 같음.
대종현님이 바이낸스 해커 토큰 매도 대시보드를 만들어주셨는데, 개인적으로 궁금했던 내용이라 가져옴.
사이트에서 토큰을 하나씩 누르면 첫 매도 컨트랙트와 매도 시점 이후 바이낸스 선물 60분 차트를 볼 수 있음.
해커 매도를 온체인 알람으로 받아서 바로 숏을 쳤다면, 실제로 얼마나 기회가 있었을지 궁금하기도 했음.
일단, $ENA같은 매도 & 시총 규모가 큰 토큰보다는 시총이 작은 토큰에 집중해서
매도 노셔널이 $10M 이하인 토큰만 따로 집계해봤는데,
총 99개 중 75개가 매도 시점 대비 60분 뒤 하락했고,
하락한 토큰들의 평균 하락률이 약 2.7%였음.
대상 토큰당 평균 매도 규모는 약 $1.1M.
현재 매도가 모두 끝났으므로, 당시 흐름이 궁금했던 분들은 하나씩 눌러보시면 좋을듯.
이런 건 시간이 지나고 나서라도 참고해두면,
다음에 비슷한 상황이 왔을 때 큰 도움 될 것 같음.
Forwarded from 오스왈드
[👮♀️ FBI공식] 북한은 최소 60억 달러 이상 규모의 바이낸스 해킹 공격 배후이며, 미국 당국은 북한을 중심으로 수사 착수에 들어갔습니다. ( fbi.gov )
Please open Telegram to view this post
VIEW IN TELEGRAM
Federal Bureau of Investigation
North Korea Responsible for $6 Billion+ Binance Attack | Federal Bureau of Investigation
The FBI is releasing information advising the Democratic People's Republic of Korea (North Korea) was responsible for the theft of more than $6 billion USD in virtual assets from cryptocurrency exchange Binance.
OpenAI, Codex 사용량 페이지에 'GPT-6.2 Astra' 노출
— 한 사용자의 Codex 사용량 차트에서 71.1%가 gpt-6.2-astra로 집계됐다 (6 Astra는 25.9%).
— 6 Astra로 보낸 요청 일부가 6.2로 라우팅되는 것으로 보인다.
— 티보의 28일 챌린지 막바지와 겹쳐 곧 발표 가능성이 거론된다.
https://x.com/VeknQAQ/status/2116817688215576904
— 한 사용자의 Codex 사용량 차트에서 71.1%가 gpt-6.2-astra로 집계됐다 (6 Astra는 25.9%).
— 6 Astra로 보낸 요청 일부가 6.2로 라우팅되는 것으로 보인다.
— 티보의 28일 챌린지 막바지와 겹쳐 곧 발표 가능성이 거론된다.
https://x.com/VeknQAQ/status/2116817688215576904
오픈AI, Codex 사용량에 GPT-6.2 Astra 별도 표기
일부 Codex 계정에서 모델 선택기와 사용량 내역의 Astra 모델명이 다르게 나타났다는 제보다. 출처는 이를 GPT-6.2 Astra의 A/B 테스트로 해석했다.
💬 한줄평: 사용량 내역의 새 모델명 표기만으로 사용자가 새 버전을 직접 선택할 수 있다는 뜻은 아니다.
https://x.com/TokenGremlin/status/2116834891744600291
일부 Codex 계정에서 모델 선택기와 사용량 내역의 Astra 모델명이 다르게 나타났다는 제보다. 출처는 이를 GPT-6.2 Astra의 A/B 테스트로 해석했다.
💬 한줄평: 사용량 내역의 새 모델명 표기만으로 사용자가 새 버전을 직접 선택할 수 있다는 뜻은 아니다.
https://x.com/TokenGremlin/status/2116834891744600291