Flowkater.io · Nuggets

Google은 어떻게 신뢰를 잃어가고 있는가

Wed, 20 May 2026 08:00:00 GMT

Theo(t3.gg)가 또 한 번 커리어를 걸고 영상을 올렸다. 이번엔 Google이다. Google IO 직후, "내가 이 영상을 만드는 게 두렵다"는 고백으로 시작한다. 이전에 Google 제품을 비판했을 때 동영상 수익 창출이 차단되고 "부정직한 콘텐츠"로 플래그 처리됐던 경험 때문이라고 한다. 그럼에도 만들었다.

지난 달 Claude Code 비판 영상과 같은 패턴이다. 모델 성능보다 vendor 신뢰가 더 중요해진 시대의 표시이기도 하다.

Theo가 짚은 Google의 세 가지 실수는 이렇다.

1. Gemini 3.5 Flash — 숨겨진 가격

벤치마크 숫자는 GPT-5.5에 근접하다. Terminal Bench, SWB Pro 등에서 Opus 47, GPT-5.5와 어깨를 나란히 한다. 속도는 초당 300 토큰 수준으로 가장 빠르다.

문제는 발표 페이지에 달러 사인 자체가 없다. 실제 가격은 출력 $9/백만 토큰. 이전 Flash 3의 3배, Gemini 2.0 Flash의 20배 이상이다.

게다가 토큰 효율도 최악이다. 같은 벤치마크 실행에 GPT-5.5 Medium이 2,200만 토큰을 쓸 때, Gemini 3.5 Flash는 7,200만~7,300만 토큰을 쓴다. 3.3배. "2배 빠르지만 4배 많은 토큰을 쓴다면 결국 2배 느린 것"이라는 Theo의 말이 정확하다.

Theo가 직접 코딩 테스트(Fish Slop 게임 리라이팅)에서는 테스트한 모든 모델 중 유일하게 동작하는 코드를 만들지 못했다. 같은 작업을 GPT-5.5에게 시키자 3D 버전까지 완성했다고 한다.

2. Anti-gravity CLI — 오픈소스 배신

Gemini CLI는 100K GitHub 스타, 6,000개의 머지된 PR을 가진 오픈소스 프로젝트였다. Dmitri, Jack, Gal 세 명의 팀이 커뮤니티와 신뢰를 쌓아왔다.

Google은 Windsurf 창업자들을 인수했고, 그들이 anti-gravity 팀을 인계받았다. 기존 팀원 셋은 교체됐다. 그리고 Gemini CLI는 Anti-gravity CLI로 재작성되며 클로즈드소스가 됐다. 6월 18일부터는 Google AI Pro/Ultra 구독자는 Anti-gravity CLI만 사용 가능하다.

새 CLI는 스크롤 불가, 이메일 노출, Ctrl+C 작동 안 함, 재실행 시마다 재로그인. 공식 발표 영상에서 폴더명이 "Codeex"인 게 그대로 노출됐다. Cursor를 베끼고 있다는 증거다.

3. Railway 계정 차단 — 신뢰 못 할 클라우드

Railway는 월 $2M 이상을 Google Cloud에 쓰는 고객이다. 그런 회사의 계정을 Google Cloud가 예고 없이 전면 차단했다. railway.app 등 모든 웹 기반 서비스가 다운됐다.

2년 전 UniSuper 사건이 떠오른다. 호주의 $1,350억 규모 연금 펀드 계정을 Google Cloud가 실수로 통째로 삭제했다. 다른 클라우드에 백업이 있어서 데이터 손실은 면했지만, "이 규모의 조직 계정이 전부 삭제될 수 있다는 건 전례 없는 일"이라고 Theo는 말한다.

비교는 매섭다. Azure는 느리고 이상해도 알람 올리면 대응한다. AWS는 여전히 1위인 이유가 있다. Google Cloud는 "실제로 얼마나 신뢰할 수 없고 형편없는지 믿을 수 없을 정도"라는 게 Theo의 평이다.

여기서 단순한 vendor 흠집 잡기로 끝났다면 영상은 별게 아니다. 그러나 Theo가 짚는 더 큰 문제는 이거다.

Google은 다 갖췄다. 인프라, 인재, 생태계, TPU, 연구력. 그런데 결과가 없다. 정치가 제품을 죽인다. Windsurf 인수 → 기존 팀 교체 → 지역 커뮤니티 신뢰 붕괴. 1년 넘게 Dmitri, Jack, Gal의 DM 소통과 피드백 대응 덕분에 Theo가 공개 비판을 자제했었다는 고백은 의미심장하다.

신뢰는 한 사람 한 사람의 관계로 쌓이고, 인사이동 한 번에 무너진다.

지난 달 Claude Code 사건이 떠오른다. 그때 나는 모델 성능이 아니라 신뢰가 vendor를 가른다고 썼다. 지금 Google에 일어나고 있는 일도 정확히 그 연장선이다. 다만 강도가 더 세다. Claude Code가 과금 라우팅 한 건이었다면, Google은 가격 은폐 + 오픈소스 배신 + 고객 계정 차단의 3관왕이다.

Theo의 결론은 단호하다. "Google 것에 뭔가를 빌드하고 있다면, 빼내라. 이걸 신뢰할 수 없다."

세 가지 실용적 시사점이 남는다.

AI 모델 비용은 토큰 효율성 × 단가다. 벤치마크 점수만 보면 안 된다. 실제 작업당 토큰 소비량이 실 비용을 결정한다.

오픈소스 CLI의 가치는 코드가 아니라 커뮤니티 신뢰다. 클로즈드소스로 전환하는 순간 그 자산은 0이 된다.

멀티클라우드 백업은 비용이 아니라 보험이다. UniSuper가 살아남은 이유고, 단일 클라우드에 모든 걸 거는 회사가 죽는 이유다.

이게 더 무겁게 다가오는 이유가 있다. 한국 시장에서도 클라우드와 AI vendor 선택이 본격적으로 표면화되고 있는데, 우리가 지금 보고 있는 건 "가장 크고 강력한 곳이 가장 안전하다"는 가정이 깨지는 풍경이다. 인프라·인재·자본 다 갖춘 Google이 신뢰를 잃는다면, 모든 선택은 두 번씩 검토받아야 한다.

Theo의 영상은 단순한 비판이 아니다. vendor 신뢰가 모델 성능을 이긴 시대의 두 번째 증거다. 지난 번 Claude Code가 첫 번째였다면 이번엔 Google. AI 시대에 vendor 신뢰는 새로운 인프라 위기다.

모델은 외부에서 빌려 쓸 수 있다. 하지만 비용 통제, 정책 변경, 인사이동에 따른 팀 붕괴 — 이런 위험은 점점 사용자 쪽으로 내려온다. 그게 멀티클라우드가 왔던 방식이고, AI vendor도 같은 길로 갈 것이다.

좋은 회사는 좋다. 그렇다고 신뢰할 수 있는 건 아니다.

삼체 — 평범한 구원자의 계보

Tue, 19 May 2026 07:29:00 GMT

삼체 3부작을 완독했다.

1부가 제일 짧고 3부가 제일 긴데, 뒤로 갈수록 몰입해서 더 빨리 읽었다.

나에게 최고를 뽑으라면 2부다.

주인공 뤄지와 결말 스토리로, 간만에 소설책을 읽으면서 흥분과 도파민이 최대치였다. 면벽자들의 기상천외한 전략과 반전, 그리고 "삼체"라는 소설 이름에 가장 걸맞은 서사가 2부였다.

뤄지는 《반지의 제왕》의 프로도, 비슷한 장르로는 《프로젝트 헤일메리》의 그레이스와 계보를 잇는 "평범한" 구원자다.

이 인물들은 정말 평범한 인물들이라, 우리가 그들의 심리 상태에 극도로 공감하게 한다. 삶의 압박감에 우리네처럼 도망도 가고 좌절도 하고 소소한 행복을 느끼고, 또 그렇게 앞으로 나아가는 인물 서사는 정말 매력적이다.

스토너에게 구원의 책임을 묻는 느낌이랄까.

1부는 드라마를 먼저 보고 읽은 터라 재미와 별개로 기시감이 컸고, 3부는 거대한 스케일과 마지막 전개가 인물(청신)이 주는 몰입이 나에게는 떨어져 개인적으로 아쉬웠다.

그래도 3부 우주 묘사만큼은 정말 압도적이었다.

넷플릭스 드라마는 소설에 비해 혹평하는 사람들이 많은데, 1·2·3부 도입부 인물들과 스토리를 잘 엮어서 시즌 1으로 만들었고 나는 그건 그거대로 매력이 있어서 다시 봐도 재밌었다. 올해 4분기? 시즌 2도 그래서 기대 중이다.

특히 뤄지와는 반대의 이유로 너무 좋아하는 토마스 웨이드를 분한 리암 커닝햄이 너무 연기를 잘해서, 그 서사와 캐릭터를 어떻게 묘사해줄지 너무 기대된다.

그들을 이해하기 때문에 공감 가는 뤄지와 답답한 청신과 달리, 오직 전진만을 외치며 나아가는 토마스 웨이드.

삼체인들도 혀를 내두르며 이리 같은 남자라며 진절머리치는 이 인물은, 우리와는 다르기에 또 동경심과 매력을 주는 캐릭터다. 우리가 하지 못하는 선택과 정면돌파를 척척 해내는 인물을 보면 괜히 쾌감이 든달까.

하여튼, 사람들 말대로 삼체는 개쩌는 소설이다.

AI 오케스트레이터라는 환상

Mon, 11 May 2026 12:00:00 GMT

"이제 코딩은 AI 가 한다. 사람은 오케스트레이터이다"라는 환상?

'감독의 역설'이라는 말이 있다. AI 를 감독하려면 코딩을 할 줄 알아야 한다. Anthropic 이 직접 발표한 자체 연구 내용이다.

코딩 에이전트를 효과적으로 관리하는 데 필요한 바로 그 비판적 사고 능력이, 코딩 에이전트 사용 때문에 잠식되고 있다는 것.

인지 부채와 기술 퇴화는 이미 측정되고 있다.

AI 가 만들어 주는 생산성으로 당신은 더 똑똑해지고 있다고 느끼는가?

Anthropic 자체 연구: 개발자 디버깅 능력 47% 급락
30년차 시니어 Simon Willison: "애플리케이션의 멘탈 모델이 사라지고 있다"
LinkedIn 엔지니어링 50명 총괄 디렉터 Sandor Nyako 의 팀 지시: "비판적 사고가 필요한 작업에는 AI 툴을 사용하지 말라"

C++ 에서 Java 로 옮길 때 뇌 안개를 호소한 사람은 없었다. 시스템 관리자가 AWS 로 가도 네트워킹 이해를 잃지 않았다.

오케스트레이터, 더 높은 추상화, 개발자의 감독 역할 — 모두 환상이다.

코드를 못 읽으면 CTO 일 수 없고, 직접 짜보지 않으면 아키텍처를 설계할 수 없다.

(CTO 로 있으면서 코드를 보지 않았던 기간이 있었고 나는 개발자들에게 CTO 를 뽑아달라는 얘기를 들었다.)

스펙 주도 개발도 환상에 가깝다.

스펙은 개발의 시작점이지 도착점이 아니다. 코드 구현과 아키텍처는 복리 구조다. 누적된 컨텍스트에서, 즉 코드를 짜는 중간에 정해질 수밖에 없다.

AI 가 코드를 작성하는 걸 잘 지켜보라. 스펙과 결과물은 절대 100% 동일하지 않다.

언어는 당신의 생각을 부분적으로만 표현하는 표상이다. 그 불완전한 정보의 빈틈을 AI 는 확률 모델로 레버를 당겨 메운다. 어쩌다 내 생각과 맞으면 가챠 성공, 아니면 계속 확률 레버를 돌린다. 그게 지금 우리가 하고 있는 일의 실상이다.

더 높은 수준의 모호성은 더 높은 수준의 추상화가 아니다.

"지금 AI 에이전트에 올인하는 사람들은 스스로 퇴물이 되는 길을 보장하는 것이다. 생각을 컴퓨터에 아웃소싱하면, 기술 향상, 학습, 더 유능해지는 것을 멈추게 된다."

— Jeremy Howard, fast.ai 창설자

관련 글

에이전트 코딩은 함정이다 (Agentic Coding is a Trap)

Mon, 11 May 2026 11:30:00 GMT

"AI가 코딩하고 사람은 오케스트레이터"라는 산업 내러티브에 대한 정면 반박 — 인지 부채와 기술 퇴화는 이미 측정되고 있다

15년차 개발자 Lars Faye가 쓴 글. SDD(Spec Driven Development) / 오케스트레이션 워크플로우가 미래라는 현재의 과대 선전이 이미 측정 가능한 트레이드오프를 만들고 있다는 주장
글의 핵심 명제: 코딩 에이전트를 효과적으로 관리하는 데 필요한 바로 그 비판적 사고 능력이 AI 툴링 자체에 의해 잠식되고 있다는 것이 이미 증명되었다. 이는 자기 모순적 시스템이다
저자가 제시하는 정량 가능한 4가지 트레이드오프: ① AI 비결정성을 완화하려는 주변 시스템 복잡도 증가, ② 광범위한 인구의 기술 퇴화, ③ 개인·팀 단위 벤더 종속(Claude 장애 시 팀 마비 사례 다수), ④ 토큰 비용 변동성(고정된 인건비 대비 끊임없이 움직이는 타겟)

"또 다른 추상화일 뿐"이라는 반론에 대한 반박 — 이번엔 데이터가 있다

커뮤니티에서 자주 듣는 변호: "프로그래머들이 스택 위로 이동하며 더 높은 추상화로 진입하고 있을 뿐". 저자 반박: 더 높은 수준의 모호성은 더 높은 수준의 추상화가 아니다
FORTRAN 출시 시 비판("어셈블리가 더 효율적"), 컴파일러 도입 시 비판("마법 과다") 모두 추측적·이론적 두려움이었음. 반면 오늘의 AI 비판은 불과 몇 년 만에 측정 가능한 영향이 데이터로 나오고 있다
C++ → Java 전환자가 뇌 안개를 호소하지 않았고, 시스템 관리자가 AWS 가서 네트워킹 이해를 잃지 않았다. 코드 마찰을 거치지 않은 사람이 시니어 워크플로우로 점프하는 트렌드는 역사적으로 처음
Simon Willison — 약 30년 경력의 시니어 — 도 자기 고백: "애플리케이션이 무엇을 할 수 있고 어떻게 작동하는지에 대한 확고한 멘탈 모델이 사라지고 있으며, 그로 인해 추가적인 기능을 추론하기가 점점 더 어려워지고 있다"

Anthropic 의 "감독의 역설"(Supervision Paradox) — 모델 제공자 본인이 인정한 모순

최근 Anthropic 연구 인용: "코딩 기술 퇴화가 우려되는 한 가지 이유는 '감독의 역설'이다. Claude를 효과적으로 사용하려면 감독이 필요하고, Claude를 감독하려면 AI 과다 사용으로 인해 퇴화할 수 있는 바로 그 코딩 기술이 필요하다."
50명을 총괄하는 LinkedIn 엔지니어링 디렉터 Sandor Nyako가 팀에 내린 지시: "비판적 사고나 문제 해결이 필요한 작업에는 AI 툴을 사용하지 말라." 이유: "AI가 정확하지 않을 경우 어떻게 의문을 가질 수 있겠는가, 비판적 사고 능력이 없다면?"
별도 Anthropic 연구: 디버깅 능력이 47% 급락했다는 측정 결과. "개발자들은 중요한 기술, 특히 문제가 생겼을 때 디버그하는 능력을 키우는 것보다 빠른 결과를 제공하기 위해 AI에 의존할 수 있다."
무엇이 "과다 사용"인지의 임계점은 아직 불명확하지만, 이런 기술들이 몇 달 안에 퇴화할 수 있다는 일화적·데이터 기반 증거가 이미 누적 중

LLM은 잘못된 부분을 가속한다 — 우선순위 목록이 뒤집힌다

AI 이전 (좋은) 개발자의 우선순위 ① 코드와 코드베이스와의 이해 → ② 문서화된 효율적 기준 부합 → ③ 가독성 유지하며 최소 코드 줄 수 → ④ 처리 시간
에이전트 코딩은 이 순서를 정반대로 뒤집어, 지정된 시간 내에 생성할 수 있는 코드의 양(속도)에 집중시킨다
저자의 핵심 통찰: 속도는 높은 적성의 자연스러운 부산물이다. 강제될 때 그것은 항상 낮은 정확도로 이어진다. 깊은 이해나 간결함에는 통합이 집중하지 않는다
가능한가? 결단력이 있다면 가능. 현재 그렇게 사용되는가? 아니다 — 조직 전반의 강제적 토큰 소비 의무화와 과대 선전이 정반대 방향을 가리키고 있다

"코딩 === 계획 수립" — 코드로 사고하는 사람의 입장

모든 사람이 스펙을 먼저 쓰고 코드를 나중에 쓰는 게 아니다. 일부 개발자에게 코드 작성 자체가 사고 과정이다. OpenCode 창작자 Dax 인터뷰 인용:

"새롭거나 도전적인 것을 작업할 때, 내가 코드를 타이핑하는 것 자체가 우리가 무엇을 해야 할지 파악하는 과정이다. (...) 나는 타입을 작성하는 것을 좋아한다. 일부 함수들이 어떻게 함께 작동할지 적어보는 것을 좋아한다. (...) 그게 내가 무엇을 해야 할지 파악하는 방식이기 때문이다."
코드 작성은 보안·성능·UX·유지보수 모두를 동시에 강제로 고민하게 만든다. SDD는 이 사고 통로를 외부화·생략한다
LLM의 비결정성 문제: "당신이 말하는 것이 항상 당신이 의미하는 것과 일치하지 않으며, LLM은 모호성을 가정(또는 환각)으로 채운다." 더 많은 검토 → 더 많은 에이전트 수정 → 더 많은 토큰 → 결과물로부터의 더 큰 단절
핵심: "결정론적 시스템을 확률론적 시스템으로 대체하고 모호성이 제로가 되기를 기대할 수는 없다." LLM은 컴파일러가 아니라 다음 토큰 예측 엔진

벤더 종속과 토큰 비용 — 키보드 한 대로 가능했던 일이 구독 의존으로

Claude 장애 직후 LinkedIn에 "팀이 완전히 정지됐다"는 게시물 다수. 키보드와 텍스트 에디터만으로 실행할 수 있었던 기술이 갑자기 AI 모델 제공업체 구독을 필요로 하게 된 상태
모델 제공업체는 막대한 보조금을 받고 있으며, 모델 자체도 불안정. 새 모델 릴리스 패턴: 높은 벤치마크 → 과대 선전 → 실사용에서 "너프됐다"는 불평 → 같은 작업에 2~3배 토큰 소모
직원 비용은 알 수 있지만, 토큰 비용이 하루·달·해 단위로 얼마가 될지는 전혀 알 수 없다. ThePrimeagen: "이런 완전한 에이전트 워크플로우를 사용할 때, 모델 제공업체들이 사실상 당신을 소유하게 된다"
시나리오: 업계 전체의 기술셋이 벤더에 종속되어, 과거 자신의 비판적 사고와 문제 해결로 달성했던 것을 이제는 토큰 소비로 사야 하는 구조. 금전적·지적 러그풀은 언제든 가능하고, 로컬 LLM은 그 수준의 사용을 아직 흡수 불가

저자의 처방: AI를 강등시켜라 — 함선의 컴퓨터처럼 쓰지, Data처럼이 아니라

저자는 수동 타이핑을 옹호하지 않음. Emmet, 자동완성, 스니펫, jQuery "write less, do more", COBOL의 "영어 같은" 명령어 모두 코드 작성을 줄이려는 역사적 시도. LLM은 그 도구 배열의 새 멤버
그러나 LLM을 보조 프로세스로 두고 인간이 구현에 적극 참여하는 워크플로우의 역전이 필요. 위임 가능한 부분만 위임하고, 이해 부채를 적극 차단
저자의 일상 워크플로우:
- 스펙·계획 생성은 LLM 활용, 구현은 직접 진행. 작업에 따라 직접 코딩 비율 20~100%
- 모델 협업 시 의사 코드(pseudo-code)를 작성해 요청과 생성 코드 사이 거리를 좁힘
- 모델을 즉석 코드 생성·인터랙티브 문서화 위임 유틸, 그리고 자기 접근에 대해 끊임없이 질문·반복·리팩토링·명확화하는 연구 도구로 사용
- 한 자리에서 검토할 수 있는 양보다 더 많이 생성하지 않는다. 너무 많으면 속도를 줄이고 분할
- 자기가 직접 해본 적 없거나 혼자서 할 수 없는 것을 LLM에 구현시키지 않는다 (순수 교육·튜토리얼 목적은 예외, 나중에 버림)
한 줄 요약: "함선의 컴퓨터처럼 사용하라, Data처럼이 아니라" (스타 트렉 레퍼런스 — 명령에 응답하는 도구 vs 자율적 동료)

결론: 우리는 더 위험한 실험을 하고 있다

코딩 민주화 시도가 반복적으로 실패한 이유: 코드와 참여하지 않고서는 코드를 이해할 수 없다는 현실. 코드를 계속 참여하지 않으면 이해와의 접촉이 끊긴다. 끊기면 처음부터 덜 유능한 오케스트레이터가 된다
소셜 미디어 도입 시 장기 영향을 이해하지 못한 채 도입했고, 이제 광범위한 주의력 결핍에 직면. 이번엔 더 위험한 것을 도박 중
마무리 인용 — fast.ai 창설자 Jeremy Howard:

"지금 AI 에이전트에 올인하는 사람들은 스스로 퇴물이 되는 길을 보장하는 것이다. 생각을 컴퓨터에 아웃소싱하면, 기술 향상, 학습, 더 유능해지는 것을 멈추게 된다."

🔗 메타데이터

원문: https://larsfaye.com/articles/agentic-coding-is-a-trap
저자: Lars Faye
번역·요약: Tony (flowkater) — 2026-05-11
태그: #AI #에이전트코딩 #SDD #개발자 #벤더종속 #인지부채
관련 글(국내):
- AI 오케스트레이터라는 환상 — 이 글에서 출발한 토니의 단정과 가챠 비유
- AI는 코드를 쓴다. 결정도 한다. 책임만 못 진다. — AI가 흡수하는 것은 코드가 아니라 책임 회피의 안전지대
- AI Native Engineer — 원리 위의 감각 — Taste·결정 능력의 안전지대 한계
- 조직에 Claude Code를 설치한다고 AX가 되지 않는다 — 도구 설치 vs 구조 변화

왜 Anthropic은 SpaceX와 손을 잡았나?

Fri, 08 May 2026 10:30:00 GMT

Anthropic이 SpaceX/XAI와 컴퓨트 공급 계약을 체결했다.

불과 몇 달 전만 해도 Anthropic은 XAI 직원들의 Claude 모델 사용을 차단했고, Elon Musk는 Claude를 두고 "misanthropic(반인류적)"이라며 수십 차례 비판해왔다. 그런 두 회사가 손을 잡았다.

이유는 단순하다. 컴퓨트 위기.

Anthropic은 2025년 1분기에 연환산 80배 성장을 기록했다. 계획은 10배였다. CEO Dario Amodei가 직접 "컴퓨트 부족으로 서비스 운영에 차질이 생겼다"고 공개적으로 인정한 이례적 상황이다. Claude Code를 Pro 플랜에서 잠시 빼려 한 것도 매출이 아니라 컴퓨트 확보가 진짜 목적이었다.

지금 AI 업계는 세 가지 자원 게임이다. 연구(Research) · 데이터(Data) · 컴퓨트(Compute). 세 박자를 모두 가진 건 OpenAI 하나뿐이다.

Anthropic: 연구·데이터는 톱이지만 컴퓨트가 부족하다.
XAI: 컴퓨트는 넘치지만 연구·데이터가 부족하다. 그래서 Cursor에 $10B(데이터만) 또는 $60B(전사) 인수 제안을 던졌다.
Google: 셋 다 있지만 쓸만한 제품을 못 만든다.

SpaceX의 Colossus 1은 442MW, H100 약 28만 개 규모다. 이 중 300MW(약 70%)를 Anthropic에 넘긴다. 정작 XAI가 Grok 추론에 쓰는 건 100MW에 불과하다. Grok을 쓰는 사람이 거의 없기 때문이다. SpaceX는 이미 학습(Training)을 1.5GW의 Colossus 2로 이전했고, Colossus 1은 사실상 잉여 자원이 됐다.

미판매 컴퓨트는 시간이 지나면 소멸하는 자원이다. Elon은 너무 일찍·너무 많이 샀고, Anthropic은 너무 늦게·너무 적게 샀다. 매치 메이드 인 헤븐.

이 딜이 사용자에게 미치는 영향은 실질적이다. Claude Code의 5시간 사용량 제한이 대폭 완화된다. Tier 3 기준 시간당 800k → 5M 토큰, Tier 2는 450k → 2M 토큰으로 늘어난다.

한편 Anthropic의 진입장벽은 빠르게 무너지고 있다. OpenAI가 곧 AWS Bedrock에 올라온다. Anthropic이 누려온 클라우드 독점 시대의 종말이다. OpenAI Codex의 폭발적 성장으로 코딩 영역의 우위도 빠르게 좁혀지고 있다.

이념보다 컴퓨트가 우선인 시대다. 적의 적이 컴퓨트를 가지고 있다면, 손을 잡는다.

AX 이후의 일과 조직구조

Thu, 07 May 2026 02:35:00 GMT

"AX는 0에서 1을 만드는 변화가 아니라, 노동의 거품을 걷어내고 본질적인 제자리를 찾는 과정입니다."

RecruitFirst Korea가 준비한 〈AX 이후의 일과 조직구조〉 인터뷰 시리즈 두 번째 편에 제 인터뷰가 발행됐습니다.

아젠다는 셋입니다.

1. 본질로의 회귀 — 기술 스킬을 익히는 게 목표가 되어선 안 됩니다. 모든 구성원이 자기 업무가 비즈니스 목표와 고객에게 전달되는 진짜 가치에 어떻게 정렬되는지 고민해야 합니다.

2. 분절된 R&R의 종말 — 부서 간의 벽이 책임의 흐름을 잘라냅니다. AI를 통해 한 사람이 전체 비즈니스 맥락을 파악할 수 있게 된 만큼, 직무 중심의 분업이 아닌 고객 여정을 통째로 책임지는 미션 단위의 조직 운영이 필요합니다.

3. 생산 중독 경계 — 노동의 총량이나 바쁜 느낌에 취해 '열심히 하는 척'하는 건 위험합니다. AI를 활용해 곁가지 일을 덜어내고, 인간만이 할 수 있는 진짜 일에 몰입하는 소수 정예 조직의 생존 조건.

전문 보기 →

철이 들수록, 당신이 사라진다

Thu, 07 May 2026 00:00:00 GMT

철이 들수록, 당신은 사라진다.

사회성을 잘 갖춘 사람은 정말 혁신할 수 없는 걸까?

내 직관이 "이건 좀 다른데"라고 말하는데도 어김없이 고개를 끄덕인 순간이 있다. 나도 그렇게 자주 끄덕인다. 매번 끄덕이다 보면, 만들고 싶었던 미래는 사라지고 누군가 듣고 싶어 하는 이야기만 남는다. 어른이 되어간다는 건 자기 안의 가장 거친 부분을 차곡차곡 잘라내는 일이다.

예전에 일론 머스크 책을 읽고 정리한 글이 있다. 거기 이런 문장을 옮겨 적었다.

"때때로 위대한 혁신가들은 배변 훈련을 거부하고 리스크를 자청하는 어른아이일 수 있다. 무모하고, 사람을 당황하게 만들고, 때로는 해를 끼칠 수도 있다. 그리고 미치광이일 수도 있다. 자신이 세상을 바꿀 수 있다고 믿을 만큼 미친 사람."

거친 표현이다. 그런데 이 거친 표현이 가리키는 게 있다. 어른의 매끈함을 갖추는 동안 같이 죽는 게 있다는 것.

마이크 메이플스 주니어는 《패턴 파괴자들》에서 답한다. 우리가 사회에 순응하도록 설계된 건 의지의 문제가 아니라 인간의 기본값이라고.

"가족, 학교, 또래, 미디어는 우리가 무엇을 욕망하고 어떻게 행동해야 하는지 계속 가르친다. 생물학적으로도 우리는 또래의 인정을 구하도록 설계되어 있다. 거절은 아프고, 대세를 따르는 편이 인지적으로 덜 피곤하다."

순응은 약한 사람의 문제가 아니다. 그래서 자기도 모르게 빠진다. 신호는 이렇다.

"주변 사람들이 다 동의하니까" 자기 직관을 접는다.
"남들도 다 그렇게 하니까" 같은 길을 간다.
"상대가 원한다고 했으니까" 검증 없이 따른다.
"분위기 깨기 싫어서" 중요한 반대를 삼킨다.
"이 분야에서는 원래 이렇게 하니까" 자기 메시지를 바꾼다.

다섯 줄 중 한 번이라도 자기 모습이 보였다면, 당신은 평범한 사람이다. 모두가 이렇게 산다. 나도 자주 이 다섯 줄 안에서 산다.

미치광이가 되라는 말이 아니다. 반항적인 척하라는 것도, 사람을 함부로 대하라는 것도 아니다. 다른 사람 기준에 맞추느라 자기가 원래 들고 있던 게 뭐였는지 잊지는 말자는 거다. 자기 기준과 충돌하는 순간에는 NO라고 말할 수 있어야 한다. NO는 사람을 밀어내는 말이 아니다. 자기가 만들고 싶었던 걸 끝까지 만들기 위해 들고 있는 거의 유일한 도구다.

무서운 건 그다음이다. 그 한계가 자기 사고방식 안에 너무 깊이 박혀 있어서, 자기는 그게 한계인지도 모른 채 산다는 점.

"가장 근본적인 한계는 타인의 규칙을 기준삼아 자신의 성공을 정의하는 것이다."

당신의 AI 프로젝트가 실패하는 이유

Mon, 04 May 2026 13:00:00 GMT

당신의 프로젝트가 실패하는 이유는 AI 모델이나 하네스 엔지니어링의 문제가 아니다.

이전 시절을 돌아보면, 도구를 먼저 결정한 케이스가 한두 번이 아니었다. Notion을 깔면 지식이 흐를 거라고 생각했고, Slack을 깔면 소통이 빨라질 줄 알았다. 결과는 부서별 위키, 부서별 채널. 도구만 바뀌고 구조는 그대로였다.

지금 AI도 똑같은 길을 가고 있다. 회사들이 Claude Code나 Codex를 도입한다. "이제 우리도 AX가 되겠지" 기대한다. 그런데 실제로 일어나는 건, 그 도구로 옛날 워크플로우를 더 빨리 돌리는 것뿐이다. 멋진 도구로 잘못된 일을 더 빨리 하는 시스템이 된다.

"실행 속도는 한 번도 어려운 부분이었던 적이 없다. 어려웠던 건 '무엇을 만들지'고, 그건 지금도 변하지 않았다. 싸게 만들 수 있어졌기 때문에 발견(discovery)은 덜 중요해진 게 아니라 더 중요해졌다." - Continuous Discovery Habits 저자

빠르게 만들 수 있을수록 무엇을 만들지 결정하는 일이 더 어려워진다. 도구는 그 결정을 대신해 주지 않는다. 제약은 실행이 아니라 방향이다.

데이터도 이미 같은 얘기를 한다. 스탠퍼드 HAI 공동소장은 최근 인터뷰에서 "AI가 전반적 생산성 향상을 제공한 영역은 프로그래밍과 콜센터뿐"이라고 정리했다. 나머지 직무에서는 의미 있는 향상이 측정되지 않는다. 모델 성능의 한계가 아니라, 적용 영역이 잘못된 결과다.

또 다른 솔직한 고백이 있다. SNS에 "AI 50개로 회사를 돌린다"고 자랑하던 어느 스타트업 창업자는 인터뷰에서 직접 말했다.

"50개는 거짓이다. 실제로 작동하는 건 5개고, 나머지는 데모용이다."

이건 그 회사 한 곳의 문제가 아니다. SNS에서 매일 보는 "AI 자동화 워크플로우 N개" 캡처들 대부분이 같은 구조다. 데모는 화려하지만 실제 production에서 매일 도는 건 그 중 일부뿐이다.

실패하는 AI 프로젝트들의 공통 패턴은 결국 단순하다.

문제를 정의하기 전에 도구를 선택한다
멋있어 보이는 데모를 먼저 만들고 사용 시나리오는 나중에 끼워맞춘다
데이터 품질을 무시한다
사람의 일을 통째로 대체할 수 있다고 기대한다
기존 워크플로우 안에 통합되지 않는, 별개의 AI 섬을 만든다

다섯 가지 중 하나만 걸려도 프로젝트는 실패한다. 그리고 보통은 다섯 가지가 한꺼번에 걸린다.

잘못된 문제 정의 위에 AI를 얹으면, AI는 그 잘못을 더 빨리 양산한다.

실패한 건 모델이 아니다. 그 위에 얹힌 결정과 설계가 실패한 거다.

Claude Code는 어떻게 신뢰를 잃어가고 있는가

Sat, 02 May 2026 07:00:00 GMT

Theo(t3.gg)는 최근 커밋 메시지에 openclaw.inbound_meta.v1 같은 OpenClaw 관련 JSON 조각이 들어간 상태에서 claude -p "hi"를 실행했다. Claude Code가 You're out of extra usage, 즉 추가 사용량 소진 오류를 반환했다. OpenClaw를 사용한 게 아니다. 비어있는 프로젝트 저장소에서 커밋 메시지만 작성한 것이다.

Claude Code 논란을 단순히 "OpenClaw를 막았냐"라는 이슈로 오해할 수 있지만, 핵심은 그것이 아니다. 경쟁사 제품 메시지가 커밋에만 들어간다고 구독 사용이 거부되고 추가 사용량 과금으로 라우팅된 것이다.

AI 에이전트가 저장소, 커밋, 이슈, 내부 문서, CI/CD 까지 읽고 실행하는 시대에, 개발자가 구매한 도구의 실행 조건과 과금 경로를 예측할 수 있느냐는 질문이다.

OpenClaw 뿐일까? Hermes 도 동일한 이슈가 있었다. 대문자 HERMES.md가 최근 깃 커밋 메시지에 있으면 Claude Code 요청이 맥스 플랜 기본 사용량이 아니라 추가 사용량 과금으로 라우팅됐다고 한다.

이 이슈 또한 파일명이 아니라 커밋 메시지 문자열이 트리거였고, 이슈 작성자는 기본 플랜 사용량이 많이 남아 있는 상태에서 extra usage credit, 추가 사용량 크레딧 $200.98이 소진됐다고 밝혔다.

Anthropic은 이를 "과하게 동작한 남용 방지 시스템"이라고 설명했고, 나중에 환불과 크레딧을 제공한다고 했다.

이게 의도적인 경쟁 툴 검열이었는지, 단순한 남용 방지 버그였는지는 사실 지금 단계에서 단정하기 어렵다. 그리고 굳이 단정할 필요도 없다.

기업과 개발자 입장에서는 의도보다 예측 가능성이 더 중요하다. 내 repo(저장소)의 커밋 메시지, 문서, 이슈, config(설정) 안의 어떤 문자열이 벤더의 숨은 정책을 건드려서 요청 거부나 과금 경로 변경을 일으킬 수 있다면, 그건 이미 인프라 리스크다.

흥미로운 대비는 OpenAI의 Where the goblins came from이다. OpenAI도 이상한 문제가 있었다. GPT 모델이 goblin, gremlin 같은 표현을 과하게 쓰는 현상이 있었고, OpenAI는 그 원인을 성격 시스템 프롬프트, 보상 신호, 강화학습 과정에서 생긴 문체 이슈의 확산으로 설명했다. 완벽한 해결책이었다는 말은 아니다.

다만 최소한 "무슨 일이 있었고, 왜 생겼고, 뭘 조치했는지"를 공식적으로 공개했다. 비용 문제는 아니었지만 어쩌면 그들의 핵심 경쟁력이라고 할 수 있는 모델 성능의 결함을 오픈하고 설명한 것이다.

AI 제품(아니 모든 소프트웨어)에서 신뢰는 "문제가 없음"으로만 만들어지지 않는다. 오히려 문제는 반드시 생긴다. 모델은 이상한 말을 하고, 라우팅은 꼬이고, 과금 예외 상황은 터진다. 중요한 건 그다음이다.

사용자가 납득할 수 있게 설명하는가. 정책과 과금 기준을 명확히 공개하는가. 영향을 받은 사용자를 먼저 찾아 보상하는가.

이 세 가지가 안 되면, 아무리 모델이 좋아도 개발자들은 마음속으로 탈출 계획(exit plan)을 만들기 시작한다.

요즘 Claude Code와 Codex를 가르는 기준이 순수 성능이라고 생각하지 않는다. 둘 다 충분히 좋고, 둘 다 이상한 짓을 한다. 솔직히 그 둘을 성능으로 가르는건 여기 스레드에 계시는 탑급 개발자 1%도 안될 것이다. 대부분 사람들에게는 둘의 차이는 근소하다.

하지만 개발자들은 사용자이자 소비자이다. 소비자가 결국 보는 것은 제품 너머의 브랜드와 신뢰다.

"이 회사가 내 작업 흐름을 갑자기 흔들지 않을까?" "내가 비용과 제한을 예측할 수 있을까?" "문제가 생기면 공개적으로 설명하고 바로잡을까?" 이 질문에 답하는 회사가 이긴다.

Anthropic은 Claude라는 강력한 브랜드를 갖고 있다. 그래서 더 아쉽다. AI는 엄청난 산업 변화를 가속화하는 대가로 각 회사들은 엄청난 출혈 경쟁을 하고 있다. 그들 입장에서는 OpenAI 와 Google 과의 경쟁도 골치아픈데, 토큰 물량 공세를 하는 중국발 모델들의 위협도 어마어마하다. (한국은.. ㅠ)

상장을 위해 기업 생존을 위해 비용 최적화는 필수로 따라야 하는 것이다.

Anthropic 는 직원 유지율, 특히 개발자 근속 기간이 다른 AI 회사에 비해 월등히 높은 회사다. 하지만 기업 운영은 개발자들의 빛나는 아이디어와 실행력으로만 완성되지 않는다. 그것을 뒷받침하는 운영, 재무 관리, 고객 대응에 대한 전략도 따라줘야 한다. 그들을 탑으로 올려주었던 필요조건들이 뒷밤침되어지지 못하는 충분조건으로 신뢰를 잃는 건 안타깝다.

Pro에서 갑자기 Claude Code 를 뺐다가 넣었다가 토큰이 급격하게 사라지는(최근 캐싱 이슈 등) 등의 사용량 정책을 투명하지 않게 운영하는데서 오는 사용자들의 피로감, 고객 지원 흐름이 엔지니어링 버그를 제대로 라우팅하지 못하는 모습이 반복되면 개발자 신뢰는 생각보다 빨리 사라진다.

개발자는 까다롭지만 단순하다. 좋은 도구는 좋아한다. 다만 블랙박스 과금과 모호한 정책 변경은 정말 싫어한다. 지금 Codex 의 위상을 봐라. 3개월 전이 기억나는가? OpenAI 가 잘해서일까? 내가 볼때 Anthropic 의 삽질에 대한 반대급부가 더 크다.

결국 이 사건이 말하는 방향은 꽤 분명하다. 모델은 외부에서 빌려 쓸 수 있다. 하지만 에이전트 실행 레이어, 정책 레이어, 비용 통제 레이어는 점점 사용자와 기업 쪽으로 내려올 것이다. 멀티 클라우드가 그랬듯이, LLM도 "가장 똑똑한 하나"보다 "예측 가능하고 교체 가능한 시스템"을 요구받게 된다.

Claude가 좋아도 Anthropic만 믿을 수 없고, Codex가 좋아도 OpenAI만 믿을 수 없는 시기가 온다.

내 결론은 이렇다. 이번 논란의 핵심은 Claude Code가 아니다.

핵심은 AI 에이전트를 인프라로 쓸 때 필요한 신뢰의 기준이 바뀌고 있다는 점이다. 앞으로 개발자들이 원하는 건 단순히 더 똑똑한 모델이 아니라, 더 투명한 실행 조건, 더 예측 가능한 과금, 더 빠른 사후 분석, 더 쉬운 escape hatch(탈출구)다.

AI 회사의 브랜드 파워는 모델 성능에서 나오는 것 같지만, 마지막에는 결국 사용자 신뢰에서 나온다.

왜 그들은 GitHub를 떠나고 있나?

Thu, 30 Apr 2026 15:00:00 GMT

요즈음 바이브 코딩 덕분에 비개발자들도 Github에 들어가서 별을 찍고 푸시를 하고 있다. SNS 화 되어가는 부분에 우려를 가진 사람도 있지만 Github는 명실상부 최고의 코드 플랫폼이다.

하지만 최근 6개월, GitHub은 장애가 아니라 붕괴를 겪고 있다. PR 탭이 하루 종일 죽었고 이미 머지된 코드가 되돌아갔다. 그리고 VP가 쓴 대응글에 "죄송합니다"는 한마디도 없었다.

최근의 사태는 단순히 서비스 장애 수준이 아니다.

PR 탭이 하루 종일 안 열리거나 장애가 생기는 건 이번이 처음이 아니다. 근데 최근의 사용자들이 공유한 장애는 정도가 심하다.

이미 머지된 2,804개의 PR이 무작위로 되돌아감
Github Webhook 장애로 자동 배포가 불가능
git push -o로 수백만 개 저장소에 접근 가능한 RCE 취약점이 발견

기능, 가용성, 지속성, 보안. 신뢰의 4개 기둥이 전부 무너졌다.

가장 웃긴 건 구조다. GitHub에는 CEO가 없다. 이전 CEO가 떠난 후 Microsoft는 대체자를 임명하지 않았다. 현재는 Core AI EVP에게 직접 보고하는데, 이 사람은 인프라 전문가이며 코드를 한 번도 짜본 적 없는 Atlassian 이사회 멤버다. CEO가 없으면 실패를 소유할 사람이 없고, CTO나 COO가 책임을 지면 해고될 수 있다. 책임질 사람이 없으면 아무도 진정한 변화를 추진하지 않는다. 그냥 악순환이다.

GitHub의 Product팀과 Engineering팀은 완전히 분리돼 있다. 다른 체계, 다른 프로세스. 개발자를 위한 제품을 만드는 회사에서 Product와 Engineering이 분리됐다는 건, 마치 식당에서 주방장은 요리만 하고, 홀 매니저는 주문 들어본 적 없고, 둘 사이에 소통할 사장님도 없는 거다. 음식은 나오는데, 손님이 원하는 게 아니다. CEO 없이 이 구조는 그냥 죽은 회사다.

Mitchell Hashimoto, Vagrant/Terraform/Ghosty의 창시자가 GitHub user #1299로 18년 동안 매일 열어봤다. Vagrant를 만든 이유 중 하나도 GitHub에 취직하기 위해서였다. 그가 떠나는 이유는 명확하다. "GitHub 장애로 업무에 차질이 생긴 날마다 일기에 X를 찍었다. 거의 매일 X가 찍혔다."

TanStack의 Tanner Linsley는 수년간 npm name squatting을 신고했으나 GitHub은 무시했고, 결국 해당 이름으로 malware가 배포되어 사용자의 .env 파일이 탈취되었다. Microsoft에 수십억 달러에 팔린 회사가 유지보수자들을 고통 속에 방치하고, 이제는 직접 해치고 있다.

"신뢰가 0이면 수리할 수 없다. 다 망가뜨려버렸으니 쌓을 기초도 없다. 끝났다."

신뢰의 종말. AI 시대에 항상 유지되는 건 없다. 전세계 모든 개발자가 쓰는 Github 플랫폼은 신뢰가 무너지기 전에 그들은 다시 정상화될 것 인가?