다들 누군지 아시죠?!

https://www.newspim.com/news/view/20260202000946

KALSHI RAISES $1B SERIES G AT $40B VALUATION, CO-LED BY SEQUOIA, WELLINGTON

SOURCE

바이낸스 해킹: 전체 이야기

10월 28일: 토네이도 캐시를 통해 지갑에 자금이 충전됨

10월 29일, 16:00 UTC: 악성 계약이 배포됨

20:20: 바이낸스 핫 월렛 14가 이를 가리키는 권한에 서명함

20:24: 하나의 트랜잭션이 월렛 14를 휩쓸음: 167K ETH + 16억 USDT

24초 후, 월렛 16이 동일한 주소로 28K ETH를 보냄

20:42: 7억 8천만 USDC가 월렛 34를 떠남

20:45: BTC가 하나의 캔들에서 $2,500 하락, 롱 포지션 $6억 2,700만 청산됨

21:11: 테더가 동결 시작, 15억 6,700만 USDT가 잠김

21:13: 서클이 8억 2,300만 USDC 동결

21:15: @cz_binance: "해킹처럼 보이네요"

21:29: @binance: "사용자 자금은 완전히 안전합니다"

그 이후로 추가 $2억 USDT가 유출됨

크립토 역사상 가장 큰 해킹.

#timeline

바낸 해킹 전체 흐름도

사용량 정상화

근데 GPT는 그록봇에 비하면 진짜 너무 오래걸려 ...

어제 바낸 해킹 사태 매매 복기

1. 바낸 해킹 의혹 터지자마자 비트와 동시에 이더 같은 메이저 알트들 하강.

2. 메이저들 추격숏 쳐봤자 크게 맛있진 않겠다 싶어서 해커 지갑 주소 찾아서 트래킹.

3. 처음에는 해커들이 지갑별로 코인을 쪼개서 전송(예를들어 페페를 팔거면 다른 버너지갑으로 가스비 + 페페만 옮겨서 처분하는 식)

4. 따라서 0x5227f603c1ee34ce3c06efe6477003bdfccb2f8c 지갑 트래킹 걸어놓고 알럿뜨면 고배율 숏 열어서 물량들 털때까지 홀딩.

5. 초기에는 트랜젝션 떠도 시장 반응이 그리 크진 않았는데, 나중에는 전송 트젝만 떠도 반응이 바로 와서 평단 좋게 가져가기가 힘들었음. 그래서 다른 방법 생각.

6. 근데 보다보니 털린 자산들은 총 70종류, 다른 체인은 동결 가능성때문에 이더에서만 처분 가능한 상황이고, 해킹 규모가 크고 시총 높은 코인들 부터 파는 패턴을 보임.

7. 마진 규모때문에 70종류를 전부 숏계장 깔수도 없었고, 페어마다 숏 원기옥을 모아서 씨게 한방 갈기고 다음 페어로 옮겨가야 수익을 더 극대화 시킬수 있었음.

8. 그래서 이친구들이 파는 패턴 따라서 시총 높은친구 + 해킹 규모가 큰 코인들을 순서대로 숏 계왕권 갈기면서 4~5페어씩 숏계장 까고 옮겨다니며 메뚜기 매매 시작 (LINK, ENA, ZAMA, RSR, ZRO, FET, ERA, GTC, CFG, RED, IMX, OGN, APE, RE, SYRUP, COTI, PROM, SOPH)

9. 한 중간 까지는 순서대로 쭉쭉가더니 갑자기 패턴을 꼬아서 본지갑에서 여러 페어들을 한꺼번에 처분하기 시작. 보니까 시총 100M 미만 따리들은 그냥 해킹한 지갑에서 바로바로 턴 듯. 이떄 RSR, COTI같은 저시총 페어(100M 미만)들은 1M씩만 던져도 미친듯이 빠졌음.

10. 라자루스(추정)해커가 유동성 고려해서 그런지 무슨 N천불씩 코인을 정리해서 시장 충격이 조금 완화되고 있었음 + 중간에 ERA 같이 동결 컨트랙 쓰는 돌연변이들 생김 + 물량 다 털자마자 숏 물량 정리분 거대양봉롱 나올때가 간간히 있어서 포지션 사이즈 줄이고 슬슬 피날레 준비.

11. PROM 같은 친구들은 지갑을 아예 따로 옮겼는데, 털지 않고 있길래 뭐지? 싶었음. DWF라인이라 물량 통제를 MM에서 많이 하고 있을거라고 가정했고 따라서 숏사이즈도 제일 크게 들어갔으나 알고보니 DEX에 유동성이 없어서 못털고 있었던 것.

12. 찾아보니 SOPH, NIL, LA, RE 같은 애들 전부 Dex에 유동성이 없어서 못팔고 있었던 것임.

13. 크라임 페어들 여태 쭉 찾아댕기면서 풀 얼마나 되는지 항상 체크하고 매매했었는데, 잠을 못자서 그랬던건지 포지션 여러개 관리하느라 정신이 없었던 건지 뭐 여튼 가장 기본적인 실수를 해버리면서 수익 꽤 뱉었고 소소한 수익으로 다 정리하고 나옴.

14. 뱉기전에는 바낸에 있는 시드는 약 5배정도 불릴 수 있었고, 다 뱉고나니 2.5배 정도에서 마감. 그리 큰 시드는 아니라 막 기쁘고 이러진 않는데, 잠을 제일 중요하게 생각하는 본인은 철야 비용 치고 인권비가 부족했다라는 느낌이 들었음.

느낀점

- 해킹 당시 시총 빌리언 단위 위 코인들은 생각보다 큰 타격이 없음. (LINK, PEPE.. ETC) $30M 박아도 크게 문제 없이 소화해내는거 보니 이런 해킹 이슈가 생기면 저시총들 잘 째리는 연습을 해야할 듯.

- 마켓캡 $100M 미만 페어들은 $1M 만 던져도 진짜 휘청휘청함 뭐 유동성에 따라 다르긴 하겠지만 특히 마켓캡 $10M 대 코인들은 그냥 100k 위로 털리면 재앙 그자체니 다음부터 해킹 소식이 보인다면 미친개처럼 숏을 갈겨버릴 것.

- 숏 물량이 모두 정리될 때 정리롱 나오는거 보면서 모두가 아는 플레이와 해결하기 쉬운 병목을 해결하는것에는 엣지가 없다는걸 다시금 느낌.

- 아무리 바쁘고 정신 없더라도 유동성 풀 반드시 반드시 꼭 제발 체크하는 습관을 들이기.

- 따리꾼 형님들은 스테이블 디페깅 여기저기 렌딩하고 엿바꿔 먹으시면서 돈 꽤나 버신듯. 자신의 주요 플레이가 무엇이냐에 따라 수익화 전략도 다양하다는 걸 느낌.

- 아캄 안되는거 진짜 개고통스러움 난센은 UX가너무 구림.

- 복기글은 반드시 남겨놓기. 복기하면서 상황을 전체적으로 그려보고 내가 무엇을 잘했고 무엇을 못했으며 어떤게 베스트 플레이였는지 생각해볼 수 있게 되고 다음에도 똑같은 상황이 발생한다면 조금 더 기민하고 정확하게 대응이 가능할 듯.

다들 고생하셨습니다이 저는 좀 쉬다가 다시 크라임 열심히 쫓아보께요이

https://x.com/JukovCrypto/status/2116110920690684308

글이 좋아서 가져옴. 담백하긴 한데 관통하는 느낌.

올해 우리가 배운 것.

- 개별 주식 투자는 쉽지 않다, 단지 한때 쉬웠을 뿐이다.
- 대부분의 사람들은 인덱스 펀드에 투자하는 것이 훨씬 낫다.
- 암호화폐 투자에서 제대로 된 보안을 확보하는 것은 쉽지 않으며, 앞으로 더 어려워질 가능성이 높다.
- 전쟁과 세계적인 석유 부족은 갑자기 심각해지기 전까지는 중요하지 않다.
- 투자자들은 AI처럼 유망한 신기술에 투자하는 것을 좋아하지만,
결국에는 돈이 어디에 있는지 알아야 하고, 그렇지 않으면 매우 짜증을 낸다.
- 메모리 관련 자산은 여전히 ​​경기 순환적일 수 있다.
- 어떤 기술이 획기적이라고 해서 경제성이 그 가치를 정당화할 만큼 빠르게 따라오는 것은 아니다.

- 우리는 아는 것이 거의 없으며, 항상 그 사실을 명심해야 한다.

막줄에서 한대 맞았음.

이번 바낸 해킹은 실시간으로 보면서 저도 좀 의아했음

해커도, 짱펑도 너무 여유로워 보였고
(해커라면 스프레드 신경안쓰고 차트 박살내면서 빨리 튀는게 맞지않나? 오히려 MM과 비슷한 느낌을 받았음)

의도된거같은 느낌을 많이 받았고
생각보다 코인가격도 별로안내렸음
저점매수를 위한 쇼인가..

https://x.com/KookCapitalLLC/status/2116103315234934933

Anthropic, IP침해 게임 단속강화

Claude Code는 10월 27일 tengu_heron_brook 라는 내부 플래그에 새로운 규칙을 추가했습니다. 때문에 앞으로 디아2 뱀서 같은 게임은 클로드로 만들기 어려워질 것으로 보입니다.

“원본 게임, 장르 내 게임, 그리고 사용자의 자체 디자인과 자산을 기반으로 한 게임을 제작하라. 특정 기존 게임의 재현을 제작하지 마라. 심지어 이름이 변경되거나 독창적이라고 불리더라도.”

앤트로픽, 클로드 Max 요금제 이름 변경·Ultra 5시간 한도 폐지

: Max 5x는 Max(월 $100), Max 20x는 Ultra(월 $200)로 이름만 바뀜. 가격은 그대로, 기존 구독자는 따로 할 일 없음

: 인증된 Ultra 계정은 5시간 사용 한도 폐지. 오늘부터 기존 구독자 대부분에 적용

: 신규 계정은 인증 전까지 임시 한도 유지(사기·악용 방지 목적). 해제되면 이메일로 안내

: 주간 한도는 변동 없음

https://x.com/claudeai/status/2116220869479428500

바이낸스 해킹. 그 이면에서 벌어진 일

20분 만에 63억 6천만 달러.

가스비 전쟁, 샌드위치 공격, 블록 포함을 위한 뇌물 경쟁.
급락장에서 진행된 프로젝트 팀들의 바이백.
온체인에서 활동한 1,000개 이상의 차익거래 지갑, 그리고 수백만 달러의 수익을 올린 CIS(독립국가연합) 및 한국의 스마트머니.

지금 확인해 보세요 👇
https://how2onchain.substack.com/p/251

오픈AI, 모바일 다중 계정 전환 지원

: 모바일에서 여러 계정 간 간편 전환 기능을 사용할 수 있음.

: 데스크톱에도 해당 기능을 곧 제공할 예정.

: 향후 이틀은 '리셋'과 '적립(banked)'을 예고했으며, 구체적인 내용은 아직 밝히지 않음.

https://x.com/thsottiaux/status/2116405414921384099

오픈AI, 법률용 GPT-6 Astra, API 가격표에 등재

: gpt-6-astra-law가 API 가격 페이지에 ‘법률용 모델 구성’으로 표시됐다.

: 100만 토큰당 입력 10달러, 출력 50달러, 캐시 입력 1달러다.

: 프로모션 가격은 최소 2026년 12월 31일까지 제공된다.

https://x.com/testingcatalog/status/2116443618659455284

Standx 바낸해킹으로 클레임 연기

https://x.com/StandX_Official/status/2116453957568536643?a=2j7ed7LYoMzYLUOCFgQ&s=19

토큰에 대한 재밌는 글! "The Crypto End-game (Belief assets & Cashflow assets)"

토큰을 만들고 단기적으로 가격을 펌핑하는 방법은 너무 잘 알려졌는데, 이런 것 말고 과연 사람들이 1년 이상 들고 있을 만한 토큰은 어떤 것인가?에 대한 글

작성자는 오래 살아남는 토큰을 크게 사람들의 "믿음으로 버티는 자산 / 실제로 돈을 벌어 홀더에게 돌려주는 자산"이라는 두 가지 관점에서 설명함

1) 믿음으로 살아남으려면 상징적인 인물, 죽었다 살아난 경험, 초기 홀더를 부자로 만든 역사와 커뮤니티 등이 필요

예를 들어, 하이퍼리퀴드 에어드랍을 통해 증거금 청산을 복구한 사례, 라이터 블라드와 같은 신앙적 설립자 등등

2) 반면 현금흐름으로 살아남으려면, 지속적으로 돈을 버는지 → 그걸 검증할 수 있는지 → 그 돈이 토큰에 돌아오는지를 봐야 함

특히 사업이 잘된다고 토큰도 좋은 것은 아니며, 이익은 지분 보유자가 가져가고 토큰 홀더에게는 기대감만 남을 수도 있다는 것

개인적으로는 마지막 부분이 생각해볼 거리가 많다고 느껴짐
> 초기 프로젝트가 번 돈을 전부 바이백에 쓰는 게 항상 좋은 건 아니고, 성장에 재투자하는 게 더 나을 수도 있음
> 다만 그렇게 커진 사업의 가치가 나중에 어떻게 토큰에 돌아오는지 불명확하다면, 홀더는 사업의 성공뿐 아니라 ‘성공한 뒤 팀이 그걸 나눠줄 의지’까지 같이 믿고 있는 셈이라는 것
> 최근 바이백을 진행하겠다고 나서는 팀들도 이 부분과 연결해서 볼 수 있지 않나 싶고, 실제로 가격 반응이 좋았던 프로젝트들도 많음 ($CHIP, $ATH, $ENA, $ZRO 등등)

그리고 결과적으로 작성자는 $HYPE 를 가장 높게 평가함 → 실제 수익이 토큰 매수로 연결되는 구조가 있으면서도, 초기 참여자들의 수익 경험, 커뮤니티, 상징적인 인물 등 믿음 쪽 요소도 함께 갖추고 있기 때문

이외에도 각 카테고리나 특징을 설명하면서 몇몇 프로젝트를 더 언급하는데, 요건 각자 한번 읽어보셔도 좋을 듯 (베리에이셔널, 익텐, 펄, 엔트로피 등)

여튼 크립토 유저라면 프로젝트를 평가할 때 한 번쯤 생각해봤을 법한 내용이라 다들 재밌게 읽어보실 수 있을 듯!

바이브코딩을 하면서 가장 크게 느끼는 장벽은 용어와 개념이다.

막연하게 원하는 것은 있다. 이런 기능이 있었으면 좋겠고, 이 과정이 조금 더 편해졌으면 좋겠고, 머릿속에 있는 무언가가 실제로 돌아갔으면 좋겠다. 어떻게 만드는지는 잘 모르겠지만, 그 부분은 에이전트가 알아서 해주기를 기대한다.

그런데 요구사항이 항상 일반적인 것은 아니다. 여러 조건이 복잡하게 얽혀 있기도 하고, 설명하는 사람조차 무엇을 원하는지 정확히 모를 때도 있다. 분명 머릿속에는 어떤 모습이 있는데, 말로 꺼내놓으면 이상하게 중요한 부분이 빠져 있다.

그래도 에이전트는 일을 한다. 전달받은 요구사항을 나름의 방식으로 이해하고, 비어 있는 부분을 채우고, 코드를 작성한다. 그리고 매우 친절하게 설명한다. 어떤 작업을 했고, 어떤 구조를 선택했으며, 무엇을 개선했는지. 테스트를 통과했다는 말도 덧붙인다.

여기서 묘한 안도감이 생긴다. 설명이 정돈되어 있고, 작업 내역이 구체적이며, 내가 미처 생각하지 못한 부분까지 챙긴 것처럼 보인다. 그런데 설명을 끝까지 읽고 나서도 어딘가 찜찜하다. 작업을 많이 했다는 것은 알겠는데, 그 작업이 내가 원했던 방향인지는 여전히 확신하기 어렵다.

나는 개발자다. 코드를 읽을 수 있고, 익숙한 영역에서는 구현이 적절한지 판단할 수 있다. 그런데도 낯선 분야의 작업을 맡기면 비슷한 순간을 만난다. 문장은 읽히는데, 그 문장에 담긴 선택의 무게가 잘 느껴지지 않는다. 각각의 단어는 검색하면 나오지만, 왜 지금 이 선택을 했는지, 다른 선택을 했다면 무엇이 달라지는지까지 이해하려면 시간이 필요하다.

그래서 개발 경험이 없는 사람이 에이전트의 작업 보고를 읽는 상황을 생각하게 된다. 요구사항을 전달할 때 한 번 막히고, 결과를 설명받을 때 다시 막힌다. 처음에는 무엇이라고 요청해야 할지 몰랐고, 나중에는 무엇을 확인해야 할지 모른다. 그 사이에서 에이전트는 열심히 일했다.

가령 “오류가 나면 자동으로 다시 시도하게 해줘”라는 요청을 했다고 해보자. 사용하는 사람 입장에서는 자연스러운 요구다. 잠깐 문제가 생겼다고 매번 버튼을 다시 누르고 싶지는 않으니까.

그런데 여기에는 서로 다른 상황이 들어 있다. 요청이 서버에 도착하지 않았을 수도 있고, 서버가 요청을 거절했을 수도 있다. 서버에서는 이미 처리가 끝났는데, 완료됐다는 응답만 돌아오지 않았을 수도 있다. 화면에는 모두 비슷한 오류로 보이지만, 다음에 해야 할 일은 달라질 수 있다.

예약 신청이 이미 처리된 상태에서 같은 요청을 다시 보내면 어떻게 될까. 사용자는 한 번 신청했다고 생각하는데, 시스템에는 두 번 접수될 수도 있다. 이때 필요한 것은 단순히 재시도 횟수를 늘리는 것보다 구체적인 판단이다. 어떤 실패에 다시 시도할 것인지, 이미 처리된 요청은 어떻게 알아볼 것인지, 결과를 확인할 수 없는 동안 사용자에게 무엇을 보여줄 것인지.

에이전트가 “재시도 로직과 멱등성을 적용했습니다”라고 설명하면 작업은 꽤 잘 마무리된 것처럼 들린다. 하지만 멱등성이라는 단어가 낯선 사람에게는 그 문장도 또 하나의 숙제다. 같은 요청을 여러 번 보내도 한 번 처리했을 때와 같은 효과를 유지한다는 뜻을 알아야, 비로소 다음 질문을 할 수 있다. 어디까지 같은 요청으로 보는지. 시간이 지난 뒤 다시 보낸 요청도 같은 것으로 취급하는지. 그 처리가 실제로 확인됐는지.

이런 순간에 용어를 안다는 것의 의미를 다시 생각한다. 개발하면서 쓰는 단어들에는 반복해서 겪었던 문제가 압축되어 있다. 어떤 일이 잘못될 수 있고, 그것을 어떤 방식으로 다뤄왔는지에 대한 흔적이 들어 있다. 단어 하나를 이해하면 이전에는 보이지 않던 갈림길이 보이기 시작한다.

물론 단어를 외우는 것만으로 판단이 생기지는 않는다. 나도 설명에 등장한 용어를 알아듣는다는 이유로, 설명 전체를 이해했다고 착각할 수 있다. 캐시가 무엇인지 아는 것과 이 서비스에서 얼마나 오래된 정보를 허용해도 되는지 결정하는 일에는 차이가 있다. 인증이 무엇인지 아는 것과 누가 어떤 정보까지 볼 수 있어야 하는지 정하는 일에도 차이가 있다.

결국 그 선택은 내가 만들려는 것의 성격으로 돌아온다. 조금 늦어도 정확해야 하는지, 잠시 오래된 정보가 보여도 빠른 편이 나은지. 사용자가 실수했을 때 되돌릴 수 있어야 하는지, 한 번 확정한 뒤에는 바꿀 수 없어야 하는지. 이런 질문에는 프로젝트마다 다른 답이 있다.

그런데 처음 요구사항을 적을 때는 여기까지 생각하기 어렵다. 보통은 잘되는 장면부터 떠올린다. 버튼을 누르면 저장되고, 로그인하면 내 정보가 나오고, 신청하면 완료 화면이 뜬다. 중간에 연결이 끊기거나, 버튼을 두 번 누르거나, 서로 다른 사람이 같은 정보를 동시에 바꾸는 장면은 나중에 생각난다.

직접 구현할 때는 이런 문제와 부딪히며 생각을 구체화한다. 어떤 값을 저장할지 정하다가 요구사항의 빈틈을 발견하고, 오류를 처리하다가 애초에 결정하지 않은 조건을 만나기도 한다. 귀찮고 더디지만, 코드를 쓰는 과정에서 내가 만들고 있는 것을 이해하게 되는 부분이 있다.

에이전트는 그 구간을 빠르게 통과한다. 덕분에 훨씬 적은 수고로 결과물을 볼 수 있다. 동시에 내가 충분히 생각해보지 않은 선택까지 이미 코드 안에 들어가 있을 수 있다. 에이전트가 선택한 기본값과 관행이 쌓여서 하나의 서비스가 된다.

그 결과를 보면서 “내가 원한 건 이게 아닌데”라고 느낄 때가 있다. 하지만 처음 전달했던 문장을 다시 읽어보면, 지금 불만인 부분을 설명한 적이 없기도 하다. 내 머릿속에서는 너무 당연해서 말하지 않았던 조건이다. 또는 실제 화면을 보고 나서야 중요하다는 사실을 알게 된 조건이다.

이럴 때는 누구의 잘못인지부터 가리기 어렵다. 에이전트가 성급하게 판단한 부분도 있고, 내가 막연하게 넘긴 부분도 있다. 무엇보다 처음부터 완성된 요구사항이 내 안에 있었는지조차 돌아보게 된다. 나는 원하는 것을 전달하고 있다고 생각했지만, 사실은 원하는 것을 함께 찾아가는 중이었을 수 있다.

나는 이 과정 자체에는 큰 가치가 있다고 느낀다. 머릿속으로 생각할 때와 실제로 눌러보며 확인할 때는 다르다. 작동하는 결과물을 보고 나면 없던 질문이 생긴다. 이 버튼은 왜 여기에 있어야 하는지, 이 정보는 정말 필요한지, 이 과정은 왜 두 번 거쳐야 하는지. 막연했던 생각에 구체적인 모양이 생기면서 판단도 조금씩 가능해진다.

다만 결과물이 빨리 나온다고 해서 판단까지 같은 속도로 끝나지는 않는다.

에이전트가 바꾼 내용을 읽고, 실행해보고, 내가 중요하게 생각하는 상황에서도 제대로 동작하는지 확인하는 일은 여전히 남아 있다. 작업을 맡기는 속도에 비해 이해하는 속도가 느려지면, 어느 순간 내가 설명할 수 없는 부분이 계속 늘어난다. 기능은 많아졌는데 전체를 다루기는 오히려 어려워질 수 있다.

나에게도 이 부분은 부담스럽다. 직접 작성한 코드는 적어도 왜 그렇게 썼는지에 대한 기억이 남는다. 에이전트가 작성한 코드는 그 판단의 맥락을 별도로 읽어야 한다. 수정된 파일이 많고 설명이 길수록, 꼼꼼하게 확인했다는 감각과 실제로 이해한 범위가 어긋나기 쉽다.

“테스트를 통과했습니다”라는 말도 비슷하게 받아들이게 된다. 반가운 말이지만, 무엇을 확인한 테스트인지는 알아야 한다. 내가 중요하게 생각한 상황이 빠져 있다면 그 부분은 여전히 모르는 상태다. 에이전트가 요구사항을 다르게 이해했다면, 그 이해를 기준으로 작성된 테스트는 통과할 수도 있다.

이런 경험을 생각하다 보면, 에이전트에게 요청하는 방식도 조금 달라져야겠다는 생각이 든다. 구현 방법을 길게 지시하기 전에, 내가 무엇을 중요하게 여기는지부터 분명히 할 필요가 있다. 사용자가 입력한 내용은 사라지면 안 된다. 처리 여부가 확인되지 않았는데 완료됐다고 보여주면 안 된다. 화면은 단순해도 괜찮지만, 잘못된 상태를 정상처럼 보이게 해서는 안 된다.

이런 문장은 어려운 기술 용어 없이도 쓸 수 있다. 그리고 구현하는 쪽에서 어떤 선택을 해야 하는지 판단하는 데 도움이 된다. 모든 세부사항을 알고 시작할 수는 없어도, 어떤 결과를 받아들일 수 없는지는 생각해볼 수 있다.

설명을 요청할 때도 마찬가지다. 사용한 기술의 이름만 나열되면 여전히 멀게 느껴진다. 그 선택 때문에 사용자가 무엇을 경험하게 되는지, 문제가 생겼을 때 어떤 일이 벌어지는지까지 연결되어야 이해가 된다. 전문 용어를 쉬운 말로 바꿔달라는 요청에 더해, 실제 상황을 하나 들어 설명해달라고 할 필요가 있다.

에이전트가 판단한 부분도 드러나면 좋겠다. 내가 명시한 요구사항과, 작업을 진행하기 위해 에이전트가 가정한 조건이 구분되어 있으면 확인하기가 한결 수월하다. 특히 나중에 바꾸기 어렵거나 다른 기능에 영향을 많이 주는 선택은 먼저 질문해주기를 바라게 된다.

그렇다고 사소한 것까지 전부 물어보는 에이전트가 편한 것도 아니다. 맡길 수 있는 일을 맡기려고 사용하는데, 모든 결정을 다시 돌려받으면 금방 지친다. 적당히 알아서 해줬으면 하는 마음과, 중요한 것은 내 의도를 확인해줬으면 하는 마음이 동시에 있다. 어떤 부분을 맡겨도 되는지 서로 맞춰가는 과정이 필요하다고 느낀다.

그래서 바이브코딩을 하려면 어디까지 공부해야 하는지에 대한 질문에도 쉽게 답하기 어렵다. 시작하기 전에 개발자가 배우는 모든 것을 공부할 필요는 없다고 생각한다. 실제로 무언가를 만들어볼 수 있는 기회가 넓어진 것은 반가운 일이다. 작은 불편을 해결하는 도구 하나를 만드는 데 반드시 긴 준비 과정이 필요한 것은 아니다.

다만 만들다 보면 이해가 필요한 순간을 만나게 된다. 그때 용어와 개념이 내 일에 연결된다. 저장한 내용이 사라지고 나서야 데이터가 어디에 남는지 궁금해지고, 여러 사람이 사용하기 시작하면 권한이라는 말이 구체적으로 느껴진다. 같은 동작이 두 번 실행되는 문제를 겪으면 중복 처리라는 단어를 이전과 다르게 읽게 된다.

그렇게 배우는 것은 기억에도 오래 남을 것 같다. 내가 해결하려는 문제가 있고, 그 문제를 설명하는 이름을 뒤늦게 만나는 경험이기 때문이다. 에이전트는 구현을 도와주는 동시에, 지금 눈앞에서 벌어진 일을 설명해줄 수도 있다. 조금씩 이해가 쌓이면 다음 요청은 더 구체적이 되고, 결과를 확인할 때도 더 나은 질문을 할 수 있다.

나 역시 그 과정에서 예외가 아니다. 익숙한 기술을 사용한다는 이유로 요구사항까지 명확하다고 생각하지 않으려 한다. 코드를 읽을 수 있다는 자신감 때문에 사용자가 실제로 겪을 상황을 건너뛰고 있지는 않은지도 돌아보게 된다. 에이전트가 구현을 빠르게 해줄수록, 내가 무엇을 만들고 있는지 설명할 수 있어야 한다는 부담은 오히려 더 또렷해진다.

아직도 에이전트가 알아서 잘해주기를 바란다. 반복되는 작업은 맡기고 싶고, 익숙하지 않은 분야에서도 도움을 받고 싶다. 설명이 친절하고 결과가 빨리 나오는 것도 좋다.

다만 작업이 끝났다는 말을 들었을 때, 잠깐 더 들여다보고 싶다. 내가 요청한 문장이 어떤 의미로 구현되었는지. 설명을 읽고 고개를 끄덕인 부분을 정말 이해했는지. 지금 보이는 결과가 내가 원했던 것에 가까워졌는지.

바이브코딩을 통해 결과물과 함께 내 생각도 조금씩 구체적이 되었으면 한다. 처음에는 막연하게 “이런 게 있었으면 좋겠다”고 말했더라도, 마지막에는 무엇이 필요했고 왜 이렇게 만들었는지 내 말로 설명할 수 있으면 좋겠다.

에이전트와 일하면서 내가 얻고 싶은 감각은 그쪽에 가깝다.

앤트로픽, 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

인터컨티넨털익스체인지, 하이퍼리퀴드 기반 무기한 선물 미국 출시 추진

: ICE와 Trade[XYZ]는 규제 승인 조건으로 미국 규제 체계 내 무기한 선물 시장 운영을 추진한다.

: 새 거래 플랫폼은 ICE의 기관용 선물 사업과 별도로 운영하며 개인 투자자 참여에 맞춰 설계한다.

: 출시 후 미국 트레이더에게 암호화폐·주식·지수·원자재·외환의 연중무휴 24시간 거래를 제공할 계획이다.

: 이용자는 고객확인·자금세탁방지 심사를 수행하는 미국 규제 선물중개회사(FCM)를 통해 접속한다.

https://x.com/ICE_Markets/status/2116494325265674252