GOLDTAG (골드태그)

같은 시기에 나온 뉴스 네 개를 나란히 보게 됐습니다. 하나는 AI가 전쟁의 판도를 바꾸고 있다는 이야기였습니다. 공습 과정에서 사람이 하는 일이 어느 쪽 버튼을 누르느냐 수준으로 줄었다는 대목이 나왔고, AI가 청소년의 자살이나 범죄를 돕는 사례가 늘어 미국에서 소송이 진행 중이라는 이야기도 붙었습니다. 그 흐름에서 우리 정부가 인공지능 윤리 원칙을 새로 내놨다고 했습니다. 나머지 셋은 전부 자폐 스펙트럼 장애 이야기였습니다. 뇌 영상에서 어떤 부위가 자폐와 관련 있는지 분석하는 기술, 영유아가 영상을 보는 동안의 반응을 AI가 읽어 조기에 선별하는 기술, 그리고 말수가 적은 자폐 아동과 부모 사이의 대화를 AI가 이어 주는 시스템이었습니다. 마지막 뉴스에 어머니 인터뷰가 하나 실려 있었습니다. "저한테 엄마라고 호명을 안 했거든요. 근데 이렇게 보면서 아 엄마구나, 그리고는 저한테 엄마 아빠 이렇게." 같은 기술입니다. 한쪽에서는 사람을 죽이는 판단에 들어가 있고, 다른 쪽에서는 아이가 처음으로 엄마를 부르게 만들고 있습니다. 이걸 보고 가장 자연스럽게 나오는 결론이 있습니다. 기술 자체에는 선악이 없고, 그걸 쓰는 사람과 기관과 국가가 방향을 정한다는 것입니다. 저도 오래 그렇게 생각했습니다. 그런데 이 네 개를 같이 놓고 며칠 들여다보니 그 결론이 편한 쪽으로 반쯤 잘려 있다는 생각이 들었습니다. 가장 많이 인용되면서 가장 많이 잘리는 문장 기술사학자 멜빈 크란츠버그가 1986년에 남긴 문장이 있습니다. 기술을 이야기할 때 거의 관용구처럼 쓰입니다. "기술은 선하지도 악하지도 않다. 그러나 중립적이지도 않다." 인용될 때 대개 앞쪽 절반만 옵니다. 선하지도 악하지도 않다는 말은 듣기 좋고, 논쟁을 끝내 주고, 무엇보다 우리를 편하게 해 줍니다. 크란츠버그가 정말 하고 싶었던 말은 뒤쪽입니다. 선악이 없다는 것과 중립이라는 것은 다른 말입니다. 이게 왜 다른 말인지를 그는 이렇게 설명했습니다...

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

제 블로그 발행 스크립트에 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 조직 하나를...