incident report에 AI agent 이름을 올릴 수 있는 회사는 아직 없습니다

이미지
2026년 3월 말에 앤트로픽이 Claude Code의 소스맵 파일을 공개 npm 패키지에 그대로 실어 보낸 일이 있었습니다. 빌드에 쓰는 Bun이 소스맵을 기본으로 만드는데 .npmignore 에 *.map 을 넣어두지 않아서, 난독화되지 않은 TypeScript 원본이 패키지 안에 들어갔습니다. 경위는 이미 공개되어 있습니다 . 그런데 사고 내용보다 더 눈에 남은 건 그 직후에 나온 반응이었습니다. 사람들이 제일 먼저 궁금해한 게 이거였습니다. "이거 사람이 놓친 거야, 에이전트가 놓친 거야?" 결과적으로 원인은 사람 쪽 설정 누락으로 정리됐습니다. 그러니 질문 자체는 금방 답이 났습니다. 그런데 저한테는 그 질문이 제일 먼저 튀어나왔다는 사실이 더 흥미로웠습니다. 이게 지금 풍경입니다. 사고가 나면 원인을 사람인지 AI인지부터 가르고 싶어지는 시대입니다. 그리고 그 질문 뒤에는 거의 자동으로 다음 질문이 붙습니다. "그래서 누가 책임지는데?" 요즘 진로 고민하는 학생들이나 취업 앞둔 컴공과 4학년, 주니어들이 반복해서 꺼내는 불안도 결국 이 자리로 모입니다. AI가 이렇게 빨라지면 내 자리가 남을까. 지금 배우는 게 5년 뒤에도 쓸모가 있을까. 지금 이 업계에 들어가는 게 맞는 선택일까. 이 고민의 가장 바닥에는 사실 질문이 하나밖에 없습니다. AI가 거의 다 하게 되면 사람한테 남는 일이 진짜 있긴 한가. 저는 이 질문에 꽤 오래 같은 답을 해왔습니다. 있습니다. 그리고 그 자리는 생각보다 잘 안 없어집니다. 리콜 발표문에 로봇 얘기가 나오는 걸 본 적 있습니까 불안을 줄이려면 추상적인 얘기부터 꺼내면 안 됩니다. 실제로 굴러가는 장면 하나를 먼저 보는 게 낫습니다. 리콜 발표문을 읽어보면 문장 구조가 대체로 똑같습니다. 어느 차종의 어느 부품에서 어떤 결함이 확인됐고, 제조사가 자발적으로 시정 조치를 실시한다는 내용입니다. 여기에 로봇이 등장하는 경우는 없습니다. 이게 좀 이상한 일입니다. ...

AI agent가 못 보는 건 코드가 아니라 코드 바깥의 context입니다

이미지
AI 때문에 개발자가 사라진다는 말을 요즘 정말 자주 듣습니다. 재미있는 건 이 말을 개발을 잘 모르는 사람이 아니라 AI를 매일 쓰는 개발자들이 더 많이 한다는 점입니다. 매일 눈앞에서 AI가 자기 대신 코드를 뽑아내는 걸 보고 있으면 흔들릴 수밖에 없습니다. 예전에는 "주니어 업무부터 줄어들겠지" 정도였는데 이제는 시니어도 안전하지 않다는 쪽으로 얘기가 넘어갔습니다. 얼마 전에 지인 한 명이 진지하게 커리어 전환을 고민한다고 했습니다. 30년 넘게 코딩한 사람입니다. 자기가 일주일 붙들 일을 AI가 몇 시간 안에 대충 형태를 만들어내는 걸 보면서 묻더군요. "내가 지금 쌓고 있는 숙련이 3년 뒤에도 값이 있을까?" 반대로 다른 한 명은 AI를 거의 안 쓰는 팀원들을 보면서 완전히 다른 불안을 말합니다. "저 사람들은 지금 뭘 준비하고 있는 거지?" 같은 시기에 정반대 방향의 공포가 동시에 생기고 있는 셈입니다. 둘 다 이해는 갑니다. 그런데 저는 이 불안의 출발점 자체가 조금 틀렸다고 보고 있습니다. 개발자가 없어지는 게 아니라 "개발자"라는 말이 가리키는 대상이 바뀌는 중입니다. 이 변화가 너무 빠르고 거칠게 오니까 사람들이 제일 쉬운 문장으로 번역해버립니다. "개발자 없어지는 거 아냐?" 실제로는 조금 다릅니다. 구현만 하던 개발자의 자리가 줄어드는 것이고, 무엇을 만들어야 하는지 정의하고 무엇을 버려야 하는지 판단하는 개발자의 자리가 다시 커지고 있습니다. 앞의 지인 질문으로 돌아가면, 저는 그때 제대로 답을 못 했습니다. 값이 있다고 말하기도 없다고 말하기도 애매했습니다. 30년 코딩한 사람의 숙련이 전부 같은 종류가 아니기 때문입니다. 같은 30년 안에 서로 다른 두 가지가 섞여 있습니다. 하나는 "이 언어로 이 구조를 이렇게 만든다" 쪽이고, 다른 하나는 "이 요구를 이대로 받으면 반년 뒤에 여기가 터진다...

이틀 전에 GPT-6 Astra는 아직 안 나왔다고 썼다. 이틀 뒤에 나왔고, 틀린 건 시점만이 아니었다.

이미지
9월 1일에 AGI 얘기를 하나 발행했습니다 . 오픈AI가 연내에 AGI를 만들겠다고 한 인터뷰를 놓고, 4월에 아는 형이랑 카톡으로 했던 얘기를 겹쳐본 글이었습니다. 그 글에 이렇게 써놨습니다. 아스트라는 아직 나오지도 않았습니다. 출시는 하겠다는데 새 안전장치 승인을 받아야 하고, 언제 나올지는 자기들도 모른다고 했습니다. 그러니까 지금 우리가 보고 있는 건 제품이 아니라 시연입니다. 9월 3일에 나왔습니다. 제 글이 올라간 지 이틀 뒤였습니다. 그 글은 채점 가능한 기록이 채점 불가능한 확신보다 쓸모 있다는 얘기로 끝났습니다. 그러니까 제가 쓴 문장도 채점 가능한 형태였고, 이틀 만에 채점됐고, 틀렸습니다. 이건 뭐 할 말이 없습니다. 며칠 자료를 들여다보니 시점을 틀린 건 오히려 별일이 아니었습니다. 걸리는 건 틀린 방향이었습니다. "나왔다"는 시점이 하나가 아니었습니다 먼저 이상한 걸 하나 봤습니다. 출시 당일에 로이터 기사가 오픈AI 쪽 공식 페이지보다 먼저 나갔습니다. 기사가 돌기 시작한 뒤에도 정작 발표 페이지는 한동안 열리지 않았고, 그 사이에 공식 블로그 포스트가 한 번 올라갔다가 지워졌다는 얘기도 있습니다. 한 시간 반쯤 지나서야 제대로 열렸습니다. ( 포브스 기사 가 이 경과를 짚었습니다.) 이걸 보고 좀 웃었습니다. 제가 틀린 걸 인정하려는데, 틀린 대상이 흐릿합니다. 기자들은 엠바고를 걸고 미리 받았습니다. 기업 고객 일부는 Daybreak라는 프로그램으로 먼저 만졌습니다. 보안 쪽 사람들은 그것보다 더 센 기능을 따로 받았습니다. 챗지피티 유료 사용자는 그 뒤 며칠에 걸쳐 순차로 열렸습니다. 이 중 어느 시점이 출시입니까. 제가 "아직 안 나왔다"고 쓴 9월 1일에도 이미 누군가는 만지고 있었을 겁니다. 엠바고 자료를 받은 기자라면 최소한 발표문은 읽고 있었을 거고요. 제 문장이 틀린 게 아니라, 제가 쓴 "나왔다"라는 단어가 실물에 안 맞는 단어였던 것에...

코드보다 먼저 바꿔야 할 개발 프로세스 intent.md, AI-Native SDLC Playbook 분석

이미지
앤트로픽이 The AI-Native SDLC Playbook 이라는 글을 8월 21일에 올렸습니다. 쓴 사람은 Louis Claxton 이고, 카테고리는 Enterprise AI 와 Claude Code 입니다. 같은 이름으로 무료 코스 도 같이 열렸습니다. 14차시에 전체 1시간, Claude Academy 쪽에 올라가 있고 로그인하면 진행 상황이 저장되는 형태입니다. 차시 제목이 글의 소제목과 거의 그대로 겹치니까, 글을 읽고 나서 코스를 보면 같은 내용을 목소리로 한 번 더 듣는 셈입니다. 읽어보게 된 단순한 이유입니다. 제가 지금 만들어 왔던것이 글에 적힌 파일 이름들과 상당히 유사합니다. CLAUDE.md 가 있고, 스킬이 있고, 커밋 직전에 도는 훅이 있고, 서브에이전트를 정의해 둔 폴더가 있습니다. 그러니까 이 문서는 제가 어쩌다 그렇게 쌓아 올린 것들을 누군가 정리해서 이름을 붙여 놓은 문서일 가능성이 있었습니다. 실제로 절반은 그랬고, 절반은 제가 이미 해보고 실패한 구조였습니다. 먼저 여섯 단계를 차례로 정리하겠습니다. 이제 코드가 병목이 아니라는 것 전제는 하나입니다 문서의 첫 주장이 "Code is no longer the bottleneck" 입니다. 근거로 드는 문장이 이겁니다. Organizations have started using AI to write code at a speed unthinkable one year ago, yet the processes around the code haven't changed at the same pace. 코드는 1년 전에는 상상하기 어려웠던 속도로 나오는데, 코드 주변의 프로세스는 같은 속도로 바뀌지 않았다는 겁니다. 그래서 "Many engineering teams still have the same approval gates, reviews, handoffs, and policies, stalling productivity gain...

새 모델 발표를 언제부턴가 안 열어보고 있습니다

이미지
9월 1일에 Fable 5.1 이 나왔고, 다음 날 Gemini 3.8 Flash 가 나왔고, 그다음 날 GPT-6 Astra 가 나왔습니다. 사흘 연속이었습니다. 처음에는 정리해두려고 했습니다. 뭐가 나왔고 뭐가 달라졌고 어느 쪽으로 옮기는 게 나은지. 문서를 열고 목록을 만들다가 세 줄쯤에서 닫았습니다. 이걸 다 채워놔도 다음 주에 또 나올 텐데, 그때 이 문서는 뭐가 되나 싶었습니다. 그래서 이 글에는 9월 첫 주에 무엇이 나왔는지 정리한 표가 없습니다. 정리하고 싶어지는 마음 쪽을 보는 글입니다. 그리고 문서를 닫고 나서야 알았는데, 저는 이미 한참 전부터 안 따라가고 있었습니다. 그만두기로 정한 날이 없는데도 그렇게 돼 있었습니다. 따라가면 앞선다는 감각은 어디서 왔나 이 믿음에는 출처가 있습니다. 2023년에서 2024년 사이에는 실제로 그랬습니다. 그때는 새 모델이 나오면 못 하던 일이 됐습니다. 파일 하나를 통째로 못 넣던 것이 들어가게 되고, 대화가 열 번을 못 넘기던 것이 오십 번을 넘겨도 앞을 기억했습니다. 늦게 옮긴 사람은 그 몇 달 동안 실제로 못 하는 일이 있었습니다. 그러니 "새 게 나오면 바로 확인한다"는 습관은 그 시절에는 합리적인 투자였습니다. 문제는 그 시절 학습이 몸에 남아 있다는 겁니다. 새 모델 발표를 보면 "지금 안 옮기면 뒤처진다"는 감각이 먼저 옵니다. 감각이 틀린 게 아니라 그 감각이 만들어진 조건이 사라졌습니다. 지금은 새 모델이 나와도 못 하던 일이 갑자기 되지는 않습니다. 하던 일을 조금 더 잘합니다. 그 "조금 더"는 발표 자료를 읽어서는 확인이 안 됩니다. 벤치마크 점수는 남이 고른 문제로 잰 값이고, 제가 실제로 시키는 일과 겹치는 구간이 얼마인지는 아무도 안 알려줍니다. 그래서 확인하려면 제 작업으로 직접 돌려봐야 하는데, 제대로 하려면 반나절이 갑니다. 두 달 사이에 제가 알림으로 받은 발표만 여덟 번이었습니다. 여덟 번을 전부 ...

ego lite vs Aside 나에게 맞는 브라우저는 무엇일까?

이미지
에이전트가 제어하는 브라우저를 하나 설치해볼까 하다가 두 개를 같이 보게 됐습니다. ego lite 와 Aside 입니다. 둘 다 macOS Chromium 앱이고, 둘 다 2026년에 나왔고, 둘 다 Claude Code 나 Codex 가 제어할 수 있습니다. 내세우는 설명도 거의 같습니다. 내가 로그인해 둔 사이트에서 에이전트가 대신 일하고, 내 탭은 내 것으로 남는다는 겁니다. 그런데 로그인을 넘기는 방식이 정반대입니다. ego lite 는 Chrome 쿠키를 통째로 물려주고, Aside 는 비밀번호를 에이전트에게 안 보여준 채로 페이지에 채워 넣습니다. 같은 편의를 제공하는데 신뢰 경계를 놓는 자리가 다릅니다. 그래서 둘을 아홉 항목으로 비교했습니다. 제어 방식, 속도 주장의 근거, 로그인 위임, 격리, 게이트, 프롬프트 인젝션, 설치 경로, 구현 검증, 가격. 장면마다 어느 쪽이 가져갔는지 밑에 한 줄로 적었습니다. 미리 말하면 3승 4패 1무 1보류인데, 이긴 판과 진 판이 서로 물려 있어서 총점으로는 안 정해집니다. 어느 판이 내 작업에 해당하는지가 정합니다. 붙이는 방식은 둘이 달랐습니다. ego lite 는 저장소를 클론했고, Aside 는 공식 문서와 벤치마크 저장소를 읽었습니다. 왜 그렇게 갈렸는지도 이 글에 나옵니다. 두 회사가 공개한 게 서로 달랐습니다. ego lite 저장소에는 브라우저가 없습니다 먼저 ego lite 부터. citrolabs/ego-lite , 스타 14,812개. 4월 16일에 만들어진 저장소인데 다섯 달 만에 그만큼 붙었습니다. 클론이 6초 만에 끝나서 좀 이상했습니다. Chromium 기반 브라우저라고 소개되어 있는데요. 파일 목록을 봤습니다. 브라우저가 없었습니다. 정확히는 이렇습니다. package/ego-browser/ 아래에 TypeScript 소스가 33개 있고, 그게 Chrome DevTools Protocol 로 브라우저를 조작하는 드라이버입니다. skills/ego-browser...