GOLDTAG (골드태그)

제 블로그 발행 스크립트에 grep 한 줄이 들어 있었습니다. 파일을 열어서 판정: 합격 이라는 문자열이 있는지 찾는 코드였고, 두 달 반쯤 돌리다가 7월 말에 지웠습니다. 그 한 줄이 오늘 갑자기 떠올랐습니다. 앤트로픽과 오픈AI, 구글이 AI 안전 표준기구를 같이 세우는 걸 논의하고 있다는 기사를 읽던 중이었습니다. 규모가 전혀 다른 이야기를 갖다 붙이는 것처럼 보일 겁니다. 한쪽은 프런티어 모델을 만드는 회사들이고 한쪽은 혼자 굴리는 블로그 파이프라인이니까요. 그런데 제가 그 grep 을 지우면서 얻은 게 하나 있는데, 그게 하필 이번 뉴스를 읽는 데 그대로 쓰였습니다. 그래서 그 얘기를 먼저 하고 뉴스는 뒤에 붙이겠습니다. 순서가 반대면 제가 하려는 말이 안 남을 것 같습니다. 검문소와 통행증 발급처가 같았습니다 당시 이 레포에는 보안 기준선이라는 게 번호로 붙어 있었고, 그중 하나가 "게이트 불합격 글은 업로드 차단" 이었습니다. 문장만 보면 꽤 단단해 보입니다. 실제로 하는 일은 이랬습니다. 발행 스크립트가 글을 올리기 전에 _workspace/briefs/{slug}-ai-check.md 라는 파일을 엽니다. 그 안에 판정: 합격 이라는 문자열이 있으면 발행하고, 없으면 멈춥니다. 딱 그겁니다. 문제는 그 파일을 누가 쓰느냐입니다. AI 문체 검사를 맡은 에이전트가 씁니다. 자기가 쓴 글을 자기가 읽고, 검사 결과를 자기가 파일에 적고, 코드는 그 파일에서 문자열을 찾습니다. 검사받는 쪽이 통행증을 발급하고, 검문소가 그 통행증을 확인하는 구조였습니다. 처음 이걸 걸었을 때는 기분이 좋았습니다. 파이프라인에 단단한 게 하나 생긴 느낌이었거든요. 문서에도 자신 있게 적어뒀습니다. 불합격이면 못 나간다고요. 그 느낌이 깨진 건 발행이 한 번 막혔을 때입니다. 원인을 찾으려고 브리프 파일을 열어봤는데, 거기 적혀 있는 문장이 제가 봐도 근거가 없었습니다. 무엇을 보고 그렇게 판정했는지가 파일 어디에도 없었습니다....

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

이 시리즈를 쓰면서 제일 오래 들여다본 숫자가 하나 있었습니다. Terminal Bench 2.0 리더보드를 보면 같은 Claude Opus 4.6이 어떤 하네스에 올라가느냐에 따라 점수가 갈립니다. ForgeCode에 올린 구성이 79.8%로 네 번째에 있고, Capy에 올린 구성이 75.3%로 여덟 번째에 있습니다. 모델 가중치는 같은데 4.5퍼센트포인트 차이입니다. 스탠퍼드 쪽에서 하네스를 자동으로 진화시키는 방식을 붙인 구성도 76.4%로 그 사이에 들어옵니다. 처음 봤을 때는 그냥 흥미로운 관찰 정도로 넘겼습니다. 벤치마크마다 다를 수도 있지, 환경 차이겠지 하고 지나가기 쉬운 숫자입니다. 그런데 소수점 한 자리를 두고 다투는 리더보드에서 4.5퍼센트포인트는 모델 세대 하나가 올려주는 폭보다 큽니다. 여기서 미리 밝혀둘 게 있습니다. 이 수치는 2026년 4월 30일자 리더보드를 정리해둔 2차 자료 에서 봤고, tbench.ai 리더보드 원본을 열어 대조하지는 못했습니다. 표 내용이 제 쪽에서 읽히지 않았습니다. 그리고 Claude Code 하네스 자체가 몇 위였는지도 확인하지 못했습니다. 하네스에 따라 같은 모델의 점수가 갈린다는 것까지가 제가 확인한 범위입니다. 그런데 이걸 계속 붙들고 있다 보니, 오히려 이 관찰이 시리즈 전체에서 제일 실전적인 힌트였다는 생각이 들었습니다. 보통 우리는 이렇게 생각합니다. 좋은 모델이 있고 좋은 하네스가 있고, 둘을 합치면 더 좋은 결과가 나온다고. 그런데 실제로는 꼭 그렇지 않습니다. 가끔은 모델이 문제가 아니라 그 모델이 너무 익숙해진 기본 설정이 문제입니다. 더 노골적으로 말하면, 안전하고 검증된 기본값이라고 믿는 그 하네스가 지금은 에이전트 발목을 잡고 있을 수도 있습니다. 이건 꽤 불편한 이야기입니다. 하네스를 만들기 시작한 사람은 대개 거기에 애착이 생기기 때문입니다. 규칙을 추가했고 훅을 달았고 도구를 연결했고 세션 관리도 넣었고 서브 에이전트도 나눴습니다. 그렇게 공들여 만든 구조를 ...

2024년 11월 말에 처음 AI 대화창을 열었습니다. 특별한 기대는 없었습니다. 그냥 써보자는 거였습니다. 그 1년 반 사이에 제가 AI를 다루는 방식은 세 번 완전히 바뀌었습니다. 처음엔 복붙이었습니다. "이 코드 짜줘"라고 하면 대화창에 코드가 나오고, 복사해서 에디터에 붙여넣고, 안 되면 다시 묻고. 이 사이클을 무한 반복했습니다. 그나마 효율을 높이려면 프롬프트를 잘 써야 한다는 말을 들었고, 맞는 말이었습니다. 모호하게 물으면 모호한 답이 나왔고 맥락을 잘 줄수록 쓸 만한 코드가 나왔습니다. 그래서 프롬프트 엔지니어링을 공부했습니다. 역할 부여, 예시 몇 개 넣기, 사고 과정 유도하기, 출력 형식 지정하기. 꽤 공을 들였습니다. 그러다 Claude Code가 나왔고 Codex가 나왔습니다. CLI에서 AI가 직접 파일을 읽고 수정하고 실행하고 디버깅까지 합니다. 그 순간 프롬프트 엔지니어링 공부가 갑자기 허탈해졌습니다. 허탈했던 이유가 하나 더 있습니다. 역프롬프트 엔지니어링이라는 게 이미 있습니다. AI한테 "이 결과물을 만든 프롬프트가 뭔지 역으로 추론해줘"라고 하면 꽤 그럴듯하게 뽑아줍니다. 프롬프트를 사람이 직접 최적화하는 게 아니라 AI가 AI를 위한 프롬프트를 만드는 구조입니다. 복붙하면서 쌓은 경험도, 프롬프트를 공들여 쓰던 습관도 도구가 대부분 흡수해버렸습니다. 그때 좀 억울했는데, 그 억울함이 맞았는지 나중에 제 글을 다시 세어본 적이 있습니다 . 결론부터 말하면 헛것은 아니었습니다. 다만 남은 게 프롬프트 작성 기술은 아니었습니다. 지금 시점에서 AI 활용의 최전선은 또 다릅니다. 코드 하나 짜는 게 아니라 에이전트가 계획을 세우고 실행하고 테스트하고 계획을 수정합니다. 사람이 개입하는 건 방향을 잡아주는 것뿐입니다. 더 나아가면 상위 에이전트가 비전을 받아서 하위 에이전트를 세팅하고, 각 에이전트가 다시 팀을 구성해서 업무를 분배하는 구조까지 갑니다. 사람 한 명이 AI 조직 하나를...

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

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