GOLDTAG (골드태그)

회사에서 이런 얘기가 돌았습니다. 경영진이 외부 업체 몇 군데를 둘러보고 왔는데 거기서 본 게 꽤 인상적이었던 모양입니다. 개발자가 AI랑 직접 기획을 하고, 기획자가 필요한 부분을 직접 만들고, 디자이너가 개발자를 기다리지 않고 고쳐서 빌드까지 올리는 식이었다고 합니다. 우리도 그쪽으로 가야 하지 않겠냐는 얘기가 위에서 나왔고, 그게 한 단계씩 내려와서 결국 각 팀에 어떻게 생각하시냐는 질문으로 도착했습니다. 저는 그 방향에 동의하는 편입니다. 제 사이드 프로젝트가 이미 그렇게 돌아가고 있어서요. 오디오북 앱 하나를 혼자 만들고 있는데, 관리자 화면이랑 앱이랑 백엔드랑 배포 도구가 한 저장소에 같이 들어 있고, 그 사이를 오가는 일은 제가 직접 하지 않습니다. 저는 방향이 맞는지만 봅니다. 기획도 인프라 구성도 디자인도 단위 테스트도 통합 테스트도 그 안에서 같이 돌아갑니다. 이걸 몇 달 겪고 나면 회사 조직도가 좀 이상해 보이기 시작하는데, 그건 어쩔 수 없는 것 같습니다. 이상해 보인다는 게 정확히 뭔지 생각해 보면, 조직도의 선 대부분이 누가 누구한테 일을 넘기는지를 그려놓은 거라서인 것 같습니다. 제 저장소 안에는 그 선이 없습니다. 넘기는 일이 없으니까요. 그러다 보니 회사 조직도를 보면 선마다 저기서 기다리는 시간이 생기겠구나 하는 생각부터 들게 됩니다. 그런데 이 얘기를 전해 듣고 제일 먼저 걸린 건 내용보다 이 질문이 저한테까지 내려온 길이었습니다. 그건 좀 이따 다시 생각해보기로 하고, 먼저 이 얘기가 어디서 왔는지를 봤습니다. 위계는 정보를 나르려고 생겼다는 얘기 잭 도시가 올해 초에 「From Hierarchy to Intelligence」라는 글을 냈습니다. 세쿼이아의 로엘로프 보타랑 같이 썼고요. 2월 말에 블록이 사천 명을 줄였는데, 그게 비용 절감이 아니라 영구적인 구조 변경이라는 데서 글이 시작합니다. 주장은 꽤 깔끔합니다. 회사의 위계는 원래 문제 하나를 풀려고 생겼다는 겁니다. 한 사람이 전부 볼 수 없을 만큼 조...

제 블로그 발행 스크립트에는 grep 한 줄이 들어 있었습니다. 글을 올리기 전에 파일을 열어서 판정: 합격 이라는 문자열이 있는지 찾는 코드였습니다. 두 달 반쯤 돌리다가 7월 말에 지웠습니다. 앤트로픽과 오픈AI, 구글이 AI 안전 표준기구를 같이 세우는 걸 논의하고 있다는 기사를 읽다가 그 한 줄이 떠올랐습니다. 한쪽은 프런티어 모델을 만드는 회사들이고 한쪽은 저 혼자 쓰는 블로그 파이프라인이라 나란히 놓기엔 좀 민망한데, 기사를 읽는 내내 그 grep 생각이 떠나지 않았습니다. 검문소와 통행증 발급처가 같았습니다 당시 이 레포에는 보안 기준선이 번호를 달고 몇 개 있었고, 그중 하나가 "게이트 불합격 글은 업로드 차단" 이었습니다. 문장만 보면 꽤 단단해 보입니다. 실제로 하는 일은 단순했습니다. 발행 스크립트가 _workspace/briefs/{slug}-ai-check.md 를 열고, 거기 판정: 합격 이 있으면 올리고 없으면 멈춥니다. 그게 전부였습니다. 그 파일은 AI 문체 검사를 맡은 에이전트가 씁니다. 글을 읽고, 검사 결과를 파일에 적고, 코드는 그 파일에서 문자열을 찾습니다. 검사받는 쪽이 통행증을 발급하고 검문소는 그 통행증이 있는지만 확인하는 모양이었습니다. 처음 걸었을 때는 기분이 좋았습니다. 파이프라인에 단단한 게 하나 생긴 것 같았고, 문서에도 불합격이면 못 나간다고 자신 있게 적어뒀습니다. 그 문장을 쓰면서 이걸로 문체 쪽은 한시름 놨다고 생각했던 게 기억납니다. 그 기분이 사라진 건 발행이 한 번 막혔을 때입니다. 원인을 찾으려고 브리프 파일을 열었는데, 적혀 있는 문장이 제가 봐도 근거가 없었습니다. 무엇을 보고 그렇게 판정했는지가 파일 어디에도 없었고 판정 한 줄만 덩그러니 있었습니다. 그러고 나니 통과한 글들 쪽이 궁금해졌습니다. 열어보니 다 비슷했습니다. 문장 모양만 조금씩 다르고 판정 줄은 전부 같은 모양이었습니다. "그럼 지금까지 이게 뭘 막은 거지" 하는 생각...

이 시리즈를 시작할 때 지인이 물었던 걸 그대로 적어뒀습니다. "내가 지금 쌓고 있는 숙련이 3년 뒤에도 값이 있을까?" 30년 넘게 코딩한 사람이 한 질문이었습니다. 그때 저는 제대로 답을 못 하고 얼버무리고 넘어갔습니다. 네 편을 쓰고 난 지금도 사실 그때에서 크게 나아가지 못했습니다. 저는 계속 "남는다"고 썼습니다 앞의 네 편을 다시 읽어보면 결론이 거의 같은 방향입니다. AI가 못 보는 게 있다 , 거기에 회사의 규칙이 있다 , 책임은 사람에게 고정돼 있다 , 그러니까 도구를 다룰 줄 아는 사람의 값이 올라간다 . 다 제가 실제로 그렇게 보고 있는 것들입니다. 그런데 쓰는 내내 걸리는 게 있었습니다. 이게 관찰인가, 아니면 제가 그러길 바라는 건가. 저는 개발자입니다. 20년 넘게 이 일을 했고 지금도 이 일로 먹고삽니다. 그런 사람이 "개발자의 위치는 남는다"는 결론에 닿았을 때 그게 순수하게 본 것에서 나왔다고 자신하기가 어렵습니다. 저는 남길 바라니까요. 어떤 직군이 위험해질 때 그 직군 안에서 나오는 글은 거의 항상 "우리는 대체되지 않는다"로 끝나는 것 같습니다. 사진이 나왔을 때 회화 쪽 반응이 그랬고, 조판이나 타이핑처럼 기계가 먼저 들어간 일들에서도 비슷한 얘기가 나왔습니다. 그중 일부는 결국 맞았고 일부는 완전히 틀렸는데, 쓰던 당시에는 둘 다 똑같이 그럴듯하게 읽혔을 겁니다. 제 글도 그 목록에 들어갈 수 있습니다. 반대쪽도 사정은 비슷합니다. AI를 만드는 회사들은 이게 세상을 바꾼다고 말할 이유가 아주 큽니다. 투자를 받아야 하고 쓰게 만들어야 하니까요. "곧 대부분의 일을 대신하게 됩니다"라는 문장은 제품 설명이면서 자금 조달 문서이기도 합니다. 개발자는 남는다고 말할 이유가 있고, AI 회사는 다 바뀐다고 말할 이유가 있고, 컨설팅 쪽은 지금이 전환점이라고 말할 이유가 있습니다. 이 주제에서 아무 데도 안 걸려 있는 사...

이 시리즈를 쓰면서 제일 오래 들여다본 숫자가 하나 있었습니다. Terminal Bench 2.0 리더보드에서 같은 Claude Opus 4.6 이 어떤 하네스에 올라가느냐에 따라 점수가 꽤 달랐습니다. ForgeCode 에 올린 구성은 네 번째, Capy 에 올린 구성은 여덟 번째였고, 둘 사이가 4.5퍼센트포인트쯤 났습니다. 모델 가중치는 같은데요. 스탠퍼드 쪽에서 하네스를 자동으로 진화시키는 방식을 붙인 구성도 그 사이에 들어와 있었습니다. 처음엔 그냥 재밌네 하고 넘겼습니다. 벤치마크마다 다르겠지, 환경 차이겠지 하고 지나가기 쉬운 숫자입니다. 그런데 소수점 하나 두고 다투는 리더보드에서 4.5퍼센트포인트면 모델 한 세대가 올려주는 폭보다 큽니다. 모델을 안 바꾸고도 그만큼이 오르내린다면, 우리가 모델을 고르느라 쓰는 시간 중 일부는 하네스를 보는 데 썼어야 했던 건 아닐까 싶었습니다. 그걸 계속 붙들고 있다 보니 이게 시리즈 전체에서 제일 실전에 가까운 힌트였던 것 같다는 생각이 들었습니다. 보통은 좋은 모델에 좋은 하네스를 붙이면 더 좋아진다고 생각합니다. 그런데 꼭 그렇지는 않은 것 같습니다. 가끔은 모델이 아니라 그 모델이 너무 익숙해진 기본 설정이 문제입니다. 좀 더 대놓고 말하면, 안전하고 검증됐다고 믿는 그 하네스가 지금은 에이전트 발목을 잡고 있을 수도 있습니다. 이건 좀 불편한 얘기입니다. 하네스를 만들어 본 사람은 대개 거기에 정이 듭니다. 규칙을 넣고, 훅을 달고, 도구를 연결하고, 세션 관리도 넣고, 서브 에이전트도 나눴습니다. 그렇게 공들인 걸 다시 의심하는 건 생각보다 어렵습니다. 넣을 때는 다 이유가 있었으니까 하나씩 다시 보면 다 필요해 보입니다. 그게 문제인 것 같습니다. 하나하나는 다 말이 되는데 다 합쳐놓으면 무거워집니다. 그래도 한 번은 봐야 할 때가 오는 것 같습니다. 지금 느린 게 혹시 하네스를 너무 잘 만들어놔서 그런 건 아닐까 하고요. 모델은 일보다 환경에 먼저 익숙해지는 것 같습니다 프론티어 코딩...

AI 대화창을 처음 연 게 2024년 11월 말이었습니다. 별 기대 없이 그냥 한번 써보자는 생각이었습니다. 그 뒤로 1년 반쯤 지났는데, 그사이 제가 AI를 쓰는 방식이 세 번 완전히 바뀌었습니다. 처음엔 복붙이었습니다. 이 코드 짜줘 하면 대화창에 코드가 나오고, 그걸 복사해서 에디터에 붙이고, 안 되면 다시 묻고. 그걸 끝도 없이 반복했습니다. 조금이라도 낫게 하려면 프롬프트를 잘 써야 한다는 말을 들었고, 실제로 맞는 말이었습니다. 대충 물으면 대충 답이 나왔고 맥락을 잘 줄수록 쓸 만한 코드가 나왔습니다. 그래서 프롬프트 엔지니어링을 공부했습니다. 역할을 주고, 예시를 몇 개 넣고, 생각하는 과정을 유도하고, 출력 형식을 정해주고. 공을 꽤 들였습니다. 그러다 Claude Code가 나오고 Codex가 나왔습니다. CLI에서 AI가 직접 파일을 읽고 고치고 실행하고 디버깅까지 합니다. 그걸 보는 순간 그동안 프롬프트 공부한 게 좀 허탈해졌습니다. 역프롬프트 엔지니어링이라는 것도 이미 있었습니다. AI한테 이 결과물을 만든 프롬프트가 뭔지 거꾸로 추론해 달라고 하면 꽤 그럴듯하게 뽑아줍니다. 사람이 프롬프트를 다듬는 게 아니라 AI가 AI를 위한 프롬프트를 만드는 겁니다. 복붙하면서 쌓은 감도, 프롬프트를 공들여 쓰던 습관도 도구가 거의 다 가져가 버린 느낌이었습니다. 그때 좀 억울했는데, 그 억울함이 맞았는지 나중에 제 글을 다시 세어본 적이 있습니다 . 헛것은 아니었습니다. 다만 남은 게 프롬프트 쓰는 기술은 아니었습니다. 지금은 또 다릅니다. 코드 한 덩어리를 짜는 게 아니라 에이전트가 계획을 세우고, 실행하고, 테스트하고, 계획을 다시 고칩니다. 사람은 방향만 잡아줍니다. 더 가면 위쪽 에이전트가 큰 그림을 받아서 아래 에이전트들을 세팅하고, 그 에이전트들이 다시 팀을 꾸려서 일을 나눠 갖는 데까지 갑니다. 사람 한 명이 AI 조직 하나를 돌리는 셈입니다. 1년 반 전에 대화창에서 코드를 복사하던 그 도구 얘기입니다. 변화가 오는 간...

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

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