AX 도입 파일럿 95%가 실패하는 자리는 모델이 아니라 구두로 끝난 회의다

6월 첫 주에 조직 개편 공지가 올라왔다. 명분은 AI 대응이었다. 그리고 얼마 지나지 않아 사내 AI 업무 에이전트가 열렸다. 사내 문서와 위키, 이슈 트래커, 메신저, 코드 저장소를 한데 모아 지식 베이스를 만들었고 거기 붙어서 답한다고 했다. 나는 이걸 보고 좀 들떴다. 넉 달째 내 블로그를 에이전트로 굴리고 있었으니까, 이 정도면 나한테는 그냥 익숙한 물건이 하나 더 생긴 거라고 생각했다. 제일 먼저 시킨 게 주간보고였다. 한 주 동안 내가 남긴 것들을 수집해서 위클리를 쓰게 했다. 잘 됐다. 예상보다 잘 됐다. 화요일에 처리하고 완전히 잊어버린 이슈 하나가 목록에 올라와 있었다. 내가 손으로 썼으면 그건 100% 빠졌을 항목이다. 그런데 같은 도구를 받은 옆자리는 아무것도 못 뽑았다. 실패한 게 아니라 결과가 거의 비어 있었다. 처음엔 프롬프트를 잘못 넣었나 싶었는데 아니었다. 그 사람의 한 주가 어디에도 적혀 있지 않았을 뿐이다. 회의는 했고 결정도 났고 일도 돌아갔는데, 그게 전부 말로 끝나 있었다. 에이전트 입장에서는 수집할 대상 자체가 없었던 것이다. 그때부터 AX라는 단어가 좀 다르게 보이기 시작했다. 6월에 세 그룹이 동시에 같은 말을 했다 내 회사만의 일이 아니었다. 2026년 6월, 국내 주요 그룹들이 거의 같은 시기에 AX를 경영 전면에 내걸었다는 보도가 쏟아졌다. 삼성은 ChatGPT와 Gemini, Claude 같은 외부 생성형 AI를 계열사 전반에 공식 도입하고 임원 대상 집중 교육에 들어갔다. 자체 모델로 가두는 대신 성능 좋은 걸 그냥 쓰는 개방 노선이다. SK는 6월 11일부터 사흘간 이천에서 포럼을 열고 최태원 회장과 경영진이 AX 전략을 집중적으로 다뤘는데, 민감 데이터는 자체 모델과 사내 플랫폼으로 통제하고 범용 영역만 외부 모델을 쓰는 내재화 쪽에 무게를 뒀다. LG는 구광모 회장이 AX를 핵심 과제로 못박았고 자체 모델 ExaOne을 중심에 두되 일부 계열사가 글로벌 모델을 병용하는 하이브리드로 간다( ...

내 커밋 훅은 커밋되는 파일을 안 보고 있었다

내 커밋 훅은 커밋되는 파일을 안 보고 있었다 7월 8일 Wiz가 GhostApproval을 공개했다. 코딩 에이전트 6종이 공통으로 가진 신뢰 경계 결함이고, 그 목록에 Claude Code가 들어 있었다. 내가 매일 쓰는 도구다. 기사 제목만 보고 "샌드박스 우회 하나 더 나왔군" 하고 넘길 참이었는데, 원문의 작동 방식 설명을 읽다가 손이 멈췄다. 이건 샌드박스를 뚫는 얘기가 아니었다. 그래서 지난주에 손본 내 커밋 훅이 떠올랐다. 이 레포의 pre-commit-check.sh 는 커밋 직전에 시크릿을 스캔한다. 지난 세션에 탐지 패턴을 0/6에서 6/6으로 올리고, 값이 stdout에 찍히던 것도 막고, 공백 든 파일명으로 우회되던 것도 git diff -z 로 고쳐놨다. 회귀까지 돌려서 오탐 0건을 확인했다. 그러니까 GhostApproval과 같은 형태가 여기 있는지 찔러보는 건 30분이면 끝날 확인 작업이라고 생각했다. 찔러보니 심링크는 정말 차단됐다. 워크스페이스 밖을 가리키는 심링크를 스테이지하고 커밋을 시도했더니 훅이 exit=1로 차단했다. 여기까지는 의도한 결과였다. 그런데 차단된 이유 를 확인하려고 로그를 읽다가, 훅이 나에게 보고한 경로와 훅이 실제로 읽은 파일이 다르다는 걸 알았다. 그 사실을 따라가다 심링크와 무관한 훨씬 단순한 경로를 하나 찾았다. 그 경로로는 AWS 액세스 키가 커밋에 그대로 들어갔고, 훅은 exit=0으로 통과 신호를 냈다. 그리고 그걸 고친 패치를 다시 찔러봤을 때, 같은 병이 방향만 뒤집혀 남아 있었다. GhostApproval은 샌드박스 우회가 아니다 먼저 원문을 정확히 짚어야 한다. Wiz의 분류는 CWE-61(symlink following)과 CWE-451(UI misrepresentation)의 조합이다. 두 번째 항목이 핵심이다. 공격 순서는 이렇다. 악성 레포가 정상 설정 파일처럼 보이는 심링크를 심어둔다. 예를 들어 project_settings.json 이 실은...

시크릿 스캔을 걸어뒀는데 AWS 키가 그냥 통과했다

회사에서 보안점검을 하자는 이야기가 내려왔다. 티빙 유출 건 때문이었다. 다니는 곳이 미디어 쪽이라 남의 일처럼 읽히지 않았고, 점검 항목이 돌기 시작하면서 사내 맥에는 MDM이 들어왔다. 소스가 회사 밖 클라우드로 나가는 경로를 통제하는 쪽이었다. 코드가 저장소에 들어가는 순간에도 검사를 거치게 만드는 작업도 같이 진행됐다. 나는 그 흐름을 보면서 개인 레포는 이미 대비가 돼 있다고 생각했다. 이 블로그를 굴리는 레포에는 커밋 직전에 도는 훅이 하나 있다. 시크릿이 스테이지되면 커밋을 막는다. 몇 달 전에 직접 짜서 붙였고, 그 뒤로 한 번도 의심해본 적이 없었다. 실제로 잘 돌긴 했다. scripts/credentials.json 을 실수로 git add 한 적이 있었는데 그때 정확히 막혔다. 막힌 경험이 있으니 신뢰가 생겼다. 그래서 이번엔 순서를 바꿔봤다. 훅이 있다는 걸 확인하는 게 아니라, 훅이 무엇을 잡는지 확인해봤다. 사내 보안 점검 스킬을 내 레포에 그대로 돌리고, 훅이 쓰는 정규식만 따로 떼어내 가짜 시크릿 여섯 개에 던졌다. 탐지 0건이었다. 훅은 자기가 아는 것만 알고 있었다 내 훅이 찾던 건 다섯 가지였다. GOOGLE_API_KEY 계열, OAuth JSON의 client_secret 과 refresh_token , 그리고 sk- 로 시작하는 OpenAI 키와 sk-ant- 로 시작하는 Anthropic 키. 이 목록을 짤 때의 나를 기억한다. 이 레포에서 실제로 쓰는 자격증명이 Google OAuth와 두 LLM API 키뿐이었으니까, 내가 가진 걸 기준으로 목록을 만든 것이다. 논리적으로는 틀린 데가 없다. 문제는 사고가 내가 가진 것 안에서만 나지 않는다는 데 있다. 던져본 여섯 개는 이런 것들이었다. AWS_ACCESS_KEY_ID = AKIAIOSFODNN7EXAMPLE aws_secret_access_key = wJalrXUtnFEMIK7MDENGbPxRfiCYEXAMPLEKEYxx GITHUB_TOKEN ...

ChatGPT Work로 브라우저 탭 일곱 개를 줄여봤다

아침마다 브라우저 탭 일곱 개를 순서대로 훑는 게 루틴이 됐다. 메일 하나, 캘린더 하나, 슬랙 하나, RSS 리더 하나. 몇 년째 그러고 있었다. 그래서 ChatGPT Work에 Sites가 붙었다는 얘기를 들었을 때 제일 먼저 떠오른 게 이거였다. 저 일곱 개를 한 화면에 밀어넣을 수 있겠다. 그날 저녁에 바로 붙잡고 앉았고, 화면은 정말 나왔다. 반나절 만에 도는 대시보드를 봤다. 절반만 나왔다는 걸 안 건 그 다음이었다. 내가 원했던 화면 설계라고 부르기도 뭐한 수준의 스케치부터 그렸다. 왼쪽 컬럼에 오늘 할 일. 체크박스 누르면 바로 반영되는 흔한 todo. 가운데에 오늘 일정과 액션이 필요한 메일 몇 줄. 오른쪽에 구독 중인 개발 블로그 RSS와 GitHub 알림. 하단에 이번 주 커밋 히트맵. 특별할 게 없다. Notion이나 Raycast로도 되고, 시간 들이면 Supabase로 짜도 된다. 굳이 Sites를 본 이유는 하나였다. 인증과 배포를 안 짜도 된다는 것. 오랫동안 이 일을 하면서 제일 지겨웠던 게 사내 툴 만들 때 로그인 붙이는 작업이다. 기능은 두 시간이면 되는데 OAuth 붙이고 세션 관리하고 권한 테이블 짜다 보면 이틀이 간다. 그 이틀에서 나오는 산출물이 제품 가치랑 아무 상관이 없다는 게 특히 그렇다. 로그인이 잘 된다고 대시보드가 좋아지진 않으니까. Sites는 그걸 없앴다고 했다. 그 지점 하나 때문에 들여다봤다. 그리고 여기서 내가 무의식적으로 한 가정이 하나 있었는데, 그게 나중에 반나절을 잡아먹는다. "연동된다"는 말이 숨기는 것 Sites를 다룬 글들을 몇 개 읽었는데 대부분 이런 톤이었다. 프롬프트로 앱을 만들고, 호스팅되고, Gmail이나 Slack 같은 서비스와 연동된다. 세 번째 항목이 문제다. 저 문장은 참인데, 참인 위치가 사람들이 생각하는 곳이 아니다. ChatGPT의 커넥터는 OpenAI가 관리하는 MCP 래퍼다. Gmail도 캘린더도 Slack도 전부 그 층...

내 업무에 알고리즘 진화를 들일 자리를 찾아봤다

원래는 그냥 스크롤을 내리려던 참이었다. 주말에 밀린 뉴스레터를 훑다가 "AlphaEvolve, 이제 모든 구글 클라우드 고객에게"라는 줄을 봤다. 7월에 GA로 풀렸다는 소식이었다. 나는 이미 머릿속으로 분류를 끝내고 있었다. 또 코딩 에이전트겠지. Gemini CLI, Claude Code, Copilot 계열에 하나 더 붙는 이름이겠거니 하고 엄지를 아래로 밀었다. 그런데 그 아래 딸려온 한 문장에서 손가락이 멈췄다. "코드 스니펫을 생성하는 게 아니라, 알고리즘을 반복적으로 평가하고 개선한다." 짧은 문장인데 이상하게 걸렸다. 코드를 생성하지 않는 코딩 에이전트라니. 그게 무슨 말인가 싶어서 원래 하려던 걸 멈추고 구글 딥마인드 공개 문서와 작년 논문을 열었다. 그날 밤 나는 이게 뭔지 얼추 이해했다. 이해하는 데는 성공했다. 그런데 이해가 끝나기 무섭게 머리가 멋대로 다음 계산을 시작했다. 그럼 이걸 내 일에 들이면 어디에 꽂히지. 내가 매일 만지는 코드 중에 이 진화 루프한테 던질 만한 게 있긴 한가. 그 질문에 답해보려다가, 생각보다 훨씬 곤란한 자리로 끌려 들어갔다. 미리 밝혀둔다. 나는 AlphaEvolve를 직접 돌려본 적이 없다. 그러니 이 글은 써본 후기가 아니다. 공개된 자료만 읽고, 이걸 내 개발 업무에 들인다면 어디에 쓰고 어디선 무용한지를 머릿속으로 설계해본 사고 실험에 가깝다. 실전 경험담이 아니라 아직 안 써본 사람의 가정과 계산이라고 생각하고 읽어주면 좋겠다. 코딩 도구가 아니라는 게 진짜 핵심이었다 먼저 이름 때문에 생기는 오해부터 걷어내야 한다. AlphaEvolve는 딥마인드가 붙인 이름이고, 이 회사의 Alpha 계보를 안다면 감이 온다. 바둑의 AlphaGo, 단백질 구조의 AlphaFold. 전부 "인간이 손으로 다 뒤져볼 수 없는 거대한 공간에서 좋은 수를 찾아내는" 계열이다. AlphaEvolve도 정확히 그 자리에 있다. 다만 이번에 뒤지는 공...