# 모두가 AI를 가져도 회사는 여전히 아무것도 배우지 못할 때 > Clean Markdown view of GeekNews topic #29217. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29217](https://news.hada.io/topic?id=29217) - GeekNews Markdown: [https://news.hada.io/topic/29217.md](https://news.hada.io/topic/29217.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-05-06T11:25:34+09:00 - Updated: 2026-05-06T11:25:34+09:00 - Original source: [robert-glaser.de](https://www.robert-glaser.de/when-everyone-has-ai-and-the-company-still-learns-nothing/) - Points: 7 - Comments: 1 ## Topic Body - 직원 개인의 AI 생산성 향상은 자동으로 **조직 차원의 학습**으로 이어지지 않으며, 실제 발견이 개인에서 팀과 조직 역량으로 이동하는 경로가 핵심 과제가 됨 - AI 도입의 **복잡한 중간 단계**에서는 Copilot, ChatGPT Enterprise, Claude, Gemini, Cursor 같은 도구 사용이 널리 퍼졌지만 팀마다 활용 깊이가 다르고, 일부 학습은 숨겨져 비교와 확산이 어려움 - 기존 변화 관리 방식인 커뮤니티, 챔피언 네트워크, 데모, 설문, 대시보드는 실제 업무 중 생기는 AI 활용의 맥락·실패·검증·사람의 개입을 충분히 담기 어려움 - 에이전트형 엔지니어링은 반복 비용을 낮춰 의도에서 프로토타입과 평가까지 빠르게 이동하게 하지만, 조직의 Scrum·스프린트·인수인계 절차는 여전히 반복이 희소하다는 전제에 머물 수 있음 - 조직에는 **Agent Operations**, **Loop Intelligence**, Agent Capabilities가 함께 필요하며, 직원 감시가 아니라 실제 업무 루프를 이해해 재사용 가능한 역량과 더 빠른 학습으로 되돌리는 피드백 하네스가 중요함 --- ### 조직이 배우지 못하는 AI 도입의 복잡한 중간 단계 - [Ethan Mollick의 `Leadership, Lab, and Crowd`](https://www.oneusefulthing.org/p/making-ai-work-leadership-lab-and?ref=robert-glaser.de) 관점에서 개인의 AI 생산성 향상은 자동으로 **조직 차원의 성과**가 되지 않음 - 직원은 더 빨리 쓰고, 더 많이 분석하고, 자동화하고, “사이보그”처럼 일할 수 있지만 회사는 거의 아무것도 배우지 못할 수 있음 - GitHub Copilot, ChatGPT Enterprise, Claude, Gemini, Cursor 같은 도구가 회사 안에 들어왔고, 공식 교육 자료보다 훨씬 앞서 있는 사람이 각 팀에 있음 - 경영진은 라이선스 사용량, 프롬프트 수, 설문, 내부 PoC, 조향위원회 자료를 볼 수 있지만 실제 학습이 어디서 일어나는지는 잘 보이지 않음 - 일부 회사에서는 AI가 IT 부서로 바로 넘어간 뒤 더 이상 진전되지 않음 - AI 도입의 **복잡한 중간 단계**는 AI 사용이 널리 퍼졌지만 불균등하고, 일부는 숨겨져 있으며, 비교하기 어렵고, 아직 조직 학습과 연결되지 않은 상태에서 시작됨 - 도입 단위가 더 이상 조직 전체도, 어쩌면 팀도 아니며, 실제 업무 안의 루프(loop)로 바뀜 ### 모두 Copilot을 가진 이후에 벌어지는 일 - 첫 단계의 AI 도입은 기존 엔터프라이즈 롤아웃처럼 보여 비교적 익숙함 - 좌석을 구매하고, 허용 가능한 사용 범위를 정하고, 교육을 진행하고, 챔피언 네트워크를 만들고, Teams 채널에 유스케이스를 공유하게 함 - 이런 채널은 잠시 활발해졌다가 좋은 의도만 쌓인 기업 내부 창고처럼 될 수 있음 - 두 번째 단계에서는 같은 회사 안에서도 AI 활용 방식이 크게 갈라짐 - 어떤 팀은 Copilot을 자동완성 정도로만 사용함 - 다른 팀은 Claude Code를 테스트, 리뷰, 지속적 조정과 함께 촘촘한 루프로 돌림 - 제품 담당자가 Figma 화면을 만드는 대신 실제 소프트웨어를 프로토타이핑함 - 시니어 엔지니어가 근본 원인 분석을 에이전트에 맡겨 1시간 안에 유효한 해법을 얻고, AI 없이는 2주가 걸렸을 작업을 단축함 - 주니어가 세련된 코드를 만들지만 어떤 아키텍처 가정이 시스템에 끼어들었는지 모를 수 있음 - 지원팀은 반복 티켓을 조용히 워크플로 자동화로 바꾸며, Center of Excellence가 묻지 못한 실제 고통 지점을 알고 있음 - Mollick의 구조에서 리더십은 방향과 허가를 정하고, Crowd는 실제 업무를 하므로 유스케이스를 발견하며, Lab은 그 발견을 공유 관행, 도구, 벤치마크, 새 시스템으로 바꿈 - 핵심 난점은 발견이 개인에서 팀으로, 팀에서 조직 역량으로 실제로 어떻게 이동하는지에 있음 ### 기존 변화 관리 방식은 너무 느림 - 대부분의 회사는 기존 변화 관리 장치로 AI 도입을 처리하려 함 - 실천 공동체, 점심 세션, 챔피언 네트워크, 활성화 자료, 오피스아워, 월간 데모, 설문, 대시보드 등이 사용됨 - 아직 실험 허가 자체가 필요한 조직에서는 이런 방식도 도움이 됨 - 하지만 흥미로운 AI 활용은 다음 커뮤니티 미팅을 기다리지 않고 실제 업무 중에 생김 - 코드 리뷰, 영업 제안서, 리서치 작업, 제품 프로토타입, 운영 장애, 테스트 전략, 컴플라이언스 질문 안에서 나타남 - 특정 제품 컴포넌트 유형에서 “다크 팩토리”에 가까운 패턴이 만들어질 수 있음 - 의도를 작성함 - 에이전트가 느슨한 루프를 돌게 함 - 충분한 역압(backpressure)을 걸어 궤도를 유지함 - 강한 시나리오로 결과를 평가함 - 의도를 다듬고 반복적으로 높은 품질의 결과를 얻음 - 유용했던 학습은 베스트 프랙티스 슬라이드로 정리될 때 날카로움을 잃기 쉬움 - 실제 가치를 만든 것은 빠진 맥락, 실패한 테스트, 이상한 API 동작, 에이전트가 말도 안 되는 방향으로 퍼졌을 때 사람이 되돌린 마찰이었기 때문임 - [elastic loop](https://www.robert-glaser.de/the-elastic-loop-introducing-agentic-engineering-strategically/) 관점에서 AI 협업은 하나의 모드가 아님 - 촘촘하고 동기적인 공동 운전부터 더 느슨하고 비동기적인 위임까지 늘어남 - 중요한 질문은 “사람들이 AI를 쓰는가”가 아니라 팀이 어떤 루프 크기를 써야 하는지, 어디에 저항이 필요한지, 어떤 산출물이 루프 뒤에도 살아남아야 하는지, 그 산출물이 어떻게 조직 학습이 되는지임 - 이는 도구 사용량이나 토큰 수 계산보다 훨씬 어려운 질문임 ### Scrum은 비싼 반복을 전제로 만들어졌음 - [현대 소프트웨어 프로세스의 많은 부분](https://www.robert-glaser.de/what-if-iteration-is-all-we-need/)은 인간의 반복이 비쌌기 때문에 존재함 - 스프린트 계획, 추정, 스탠드업, 사용자 스토리, 티켓 정리, 인수인계, 조율과 위험 감소를 위한 의식이 여기에 포함됨 - 한 번의 반복이 며칠 또는 몇 주 걸린다면 낭비되는 반복을 막는 구조가 필요했음 - 에이전트형 엔지니어링은 반복의 경제성을 바꿈 - 더 많은 선택지를 실제로 만들어볼 수 있게 함 - 의도에서 프로토타입, 평가까지 더 빠르게 이동하게 함 - 제품 담당자가 동작하는 소프트웨어를 더 일찍 보게 함 - 엔지니어가 결정 전에 더 많은 가설을 시험하게 함 - 전달 자체를 마법처럼 쉽게 만들지는 않지만 제약을 구현에서 의도, 검증, 판단, 피드백 쪽으로 이동시킴 - 많은 조직은 20년 동안 스스로를 애자일이라고 불렀지만 애자일이 제거하려 했던 조직적 반사를 유지함 - AI는 실제 민첩성을 더 그럴듯하게 만들지만, 시스템은 여전히 2주 스프린트 약속, 인수인계 문서, 반복이 희소하다는 전제를 가진 절차를 요구함 - 루프는 조직이 그 루프에서 배운 것을 소화하는 속도보다 더 빠르게 움직일 수 있음 ### AI 사용료가 조직에 더 나은 질문을 강제함 - AI 사용은 더 명확하게 계량될 가능성이 큼 - 현재의 “모두 접근권이 있고 비용은 크게 걱정하지 않는” 엔터프라이즈 분위기는 오래 유지되지 않을 수 있음 - 모델 라우팅, 토큰 예산, 사용량 기반 가격, 추론 비용, 어떤 작업에 어떤 모델을 허용할지에 대한 거버넌스가 더 명시적으로 바뀜 - 중요한 질문은 추상적으로 토큰 비용을 줄이는 것이 아님 - 소프트웨어 전달에서 중요한 질문이 키 입력 수 최소화가 아니었던 것과 같음 - 더 나은 질문은 “그 토큰을 썼기 때문에 무엇이 바뀌었는가”임 - 풀 리퀘스트 수를 세는 방식은 피해야 함 - 어떤 루프가 더 빨리 닫혔는가 - 어떤 의사결정이 개선되었는가 - 어떤 근본 원인 분석이 더 날카로워졌는가 - 어떤 리뷰가 더 많은 문제를 잡았는가 - 어떤 팀이 재사용 가능한 패턴을 배웠는가 - 어떤 제품 아이디어가 프로토타입 덕분에 약점이 드러나 더 일찍 폐기되었는가 - AI가 어디서 학습을 만들었고, 어디서 단순히 더 많은 산출물만 만들었는가 - “토큰 대비 산출물”은 낡은 측정 반사가 새 옷을 입은 형태임 - 더 중요한 것은 **토큰 대비 학습**에 가까움 ### 빠진 피드백 경로로서의 Loop Intelligence - AI 도입의 복잡한 중간 단계에서 회사에는 세 가지 역량이 필요함 - ## Agent Operations - 어떤 에이전트와 AI 도구가 실행 중인지, 어떤 시스템을 건드릴 수 있는지, 어떤 데이터를 볼 수 있는지 관리함 - 어떤 행동에 승인이 필요한지, 정체성, 감사, 권한, 런타임 가시성이 어디에 있는지도 포함됨 - 에이전트형 작업은 결국 실제 시스템을 건드리기 때문에 통제 측면이 중요함 - ## Loop Intelligence - 어떤 AI 지원 또는 완전 에이전트형 루프가 실제 학습을 만드는지 파악함 - 어떤 루프가 열린 채로 남는지, 어떤 루프가 쇠퇴하는지, 에이전트가 어디서 레버리지를 만드는지, 어디서 곁가지로 퍼지는지 봄 - 어떤 팀이 테스트, 맥락, 직관 부족 때문에 촘촘한 감독에 묶여 있는지, 어떤 팀이 더 느슨한 위임을 할 준비가 되었는지 판단함 - ## Agent Capabilities - 유용한 역량을 조직 전체에 배포하되, 세 개의 거대한 에이전트가 모두의 일을 할 수 있다고 가정하지 않음 - AI는 단일 애플리케이션 범주보다 유동적인 기반 기술처럼 움직이기 시작함 - “HR 에이전트”, “엔지니어링 에이전트”, “영업 에이전트” 하나씩을 엔터프라이즈 동물원에 두는 방식에는 잘 맞지 않음 - 역량이 실제 일이 일어나는 곳으로 흘러가야 함 - 직원 하네스(harness) - 백그라운드 에이전트 - 제품 팀 - 플랫폼 서비스 - 로컬 스킬 - MCP 서버 - 평가 스위트 - 런북 - 예시 - 도메인별 절차 ### 플랫폼 질문과 피드백 하네스 - 플랫폼 차원에서 중요한 질문은 유용한 역량의 소유와 이동 방식임 - 한 팀에서 발견한 유용한 에이전트 스킬이 죽은 템플릿이 되지 않고 다른 팀에 전달되는 방법이 필요함 - 개발자의 하네스, 제품 담당자의 하네스, 지원팀의 백그라운드 에이전트, 컴플라이언스 워크플로는 서로 다르게 강화되어야 함 - 어떤 역량은 팀 가까이에 있어야 하고, 어떤 역량은 플랫폼 계층에 있어야 하며, 어떤 역량은 로컬 맥락 자체가 핵심이므로 일반화하면 안 됨 - 세 가지 역량 중 하나만 있으면 빠르게 이상해짐 - Agent Operations만 있고 Loop Intelligence가 없으면 통제 관료제가 됨 - Loop Intelligence만 있고 Agent Capabilities가 없으면 유용한 패턴을 발견하지만 다시 업무로 넣지 못하는 분석 계층이 됨 - Agent Capabilities만 있고 Operations와 Loop Intelligence가 없으면 더 나은 브랜딩을 가진 도구 난립이 됨 - 통제 경로, 학습 경로, 역량 경로는 어딘가에서 만나야 함 - 내부적으로는 이를 피드백 하네스라고 부를 수 있음 - 고객이 사는 것은 우아한 메커니즘이 아니라 자신감, 더 나은 의사결정, 더 빠른 학습, 더 적은 낭비, 더 안전한 위임임 - 고객에게 더 유용한 개념은 **Loop Intelligence Hub**일 수 있음 - 피드백 하네스는 실제 업무 루프를 듣는 장치임 - 작업, 프롬프트, 사양, 리뷰, 시나리오, 채택·거절된 가설, 운영 신호, 재작업, 사람의 결정과 개입을 봄 - 사람을 감시하기 위한 것이 아니라 루프를 이해하기 위한 것임 - 첫 버전이 거대한 플랫폼일 필요는 없음 - 몇 개의 실제 워크플로를 골라 의도, 에이전트 작업, 검증, 사람의 결정이 이미 흔적을 남기는 지점을 계측하고, 루프가 왜 성공하거나 실패했는지 이해할 만큼의 정성 피드백을 모아 반복적인 학습 산출물로 바꾸면 됨 - Loop Intelligence Hub는 신호를 조직이 행동할 수 있는 형태로 바꿈 - 활성화 백로그 - 역량 레이더 - 투자 브리프 - 거버넌스 공백 - 재사용 가능한 워크플로 - 교육 필요 - 평가 우선순위 - 모든 곳에 맞는 대시보드가 아니라 관련성에 맞춘 출력이 필요함 - 흥미로운 산출물은 대시보드 자체가 아니라 그 뒤의 결정임 - 어떤 팀은 더 많이 위임하기 전에 더 나은 역압이 필요함 - 어떤 제품 그룹은 좁은 컴포넌트 유형에 대해 반복 가능한 다크 팩토리 패턴을 가지고 있음 - 어떤 컴플라이언스 워크플로는 거버넌스가 적용된 도구 경계가 필요함 - 어떤 스킬은 다섯 팀이 잘못 재발명했기 때문에 플랫폼으로 옮겨야 함 - 하네스는 수집하고, 허브는 조직이 결정하도록 돕고, 역량 계층은 학습을 다시 업무로 넣음 ### 직원 감시가 되면 실패함 - 이 구조가 직원 점수 매기기로 변하면 전체가 무너짐 - 직원이 조직이 자신이 AI를 충분히 썼는지 측정한다고 믿으면 신호를 조작함 - 모든 실험이 생산성 기대치가 된다고 믿으면 실험을 숨김 - 최고의 워크플로가 곧 새로운 기본 업무량이 된다고 믿으면 그것을 비공개로 유지함 - 회사는 가시적인 준수와 보이지 않는 학습이라는 최악의 도입 형태를 얻게 됨 - 유용한 질문은 “누가 AI를 충분히 쓰는가”가 아님 - AI가 어디서 조직이 배울 수 있는 방식으로 일을 바꾸었는가 - 어떤 루프가 더 건강해졌는가 - 어떤 팀이 더 위임하기 전에 더 나은 역압이 필요한가 - 프로토타입이 실제 소프트웨어가 되고 있다면 어떤 제품 팀에 다른 환경이 필요한가 - 정책은 필요하지만 거버넌스도 학습처럼 사용을 통해서만 현실이 됨 - 에이전트가 운영 인접 작업을 건드릴 때 - 제품 담당자가 명세 작성 대신 프로토타입을 만들 때 - 개발자가 근본 원인 분석을 위임할 때 - 토큰 지출이 커져 경영진이 답을 원할 때 - 조직은 학습 시스템을 만들었는지, 단지 많은 좌석을 샀는지 알게 됨 ### 복잡한 중간 단계는 견뎌낼 단계가 아님 - AI 도입의 첫 단계는 접근권에 관한 것이었음 - 누가 도구를 받는지, 누가 허가를 받는지, 누가 계약을 협상하는지, 조달 티켓 없이 최신 모델을 시험할 수 있는지가 중요했음 - 이 단계는 여전히 중요하지만 오래 차별화 요소가 되지는 않음 - 최전선 지능에 대한 접근은 빌릴 수 있지만, 운영 통제와 조직 학습은 같은 방식으로 빌릴 수 없음 - 다음 우위는 **학습 속도**임 - 누가 실제 패턴을 더 빨리 찾는가 - 누가 발견을 개인에서 팀으로, 팀에서 조직 역량으로 옮기는가 - 누가 에이전트형 루프에 역압을 넣어 에이전트가 퍼지지 않게 하는가 - 누가 모두에게 맞지 않는 거대 엔터프라이즈 에이전트로 만들지 않고 유용한 에이전트 역량을 배포하는가 - 누가 AI를 기존 의식에 덧붙이는 대신 에이전트형 엔지니어링으로 애자일을 실제에 가깝게 만드는가 - 확정된 도입 플레이북을 기다려서는 이 변화를 이해하기 어려움 - 벤더, 컨설턴트, AI 연구소의 최종 답을 기다리는 대신 실제 업무를 계측하고, 지저분한 학습을 공유하고, 다른 사람이 허점을 찌르게 두고, 공개적으로 반복해야 함 ## Comments ### Comment 56923 - Author: neo - Created: 2026-05-06T11:25:35+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48020063) - 대기업 환경에서는 **AI 도입**이 개발팀 밖으로 거의 나가지 못했고, 개발자만 GitHub Copilot을 쓸 수 있음 코드가 커밋에서 운영 배포까지 가는 데 6~12개월이 걸리며, 개발 속도는 원래 병목이 아니었음 시간이 걸리는 건 인프라 프로비저닝, 테스트, 승인, 변경 관리, 배포 일정 같은 절차이고, AI는 개발 이후 병목을 더 악화시켜 변경 사항이 릴리스 열차 앞에 쌓이게 만듦 대기업이 토큰 비용의 투자수익률을 확보하려면 소프트웨어를 더 빨리 배포하는 법을 배워야 하며, **배포되지 않은 코드**는 자산이 아니라 부채임 - 경영진은 아직도 소프트웨어를 **조립 라인**처럼 보고, “Ford가 자동차를 만들듯 소프트웨어를 만든다”고 생각함 소프트웨어 개발이 비효율적인 건 맞지만, 핵심은 코드 작성이 아니라 어떤 코드를 써야 하는지 알아내는 조사와 설계인데 이 부분은 잘 고려되지 않음 Microsoft가 “코드 50% 더 빠르게!”라고 외치면 경영진은 “제품도 50% 더 빠르게, 돈도 50% 더 빠르게”라고 받아들임 투자수익률을 요구하는 순간 재앙이 될 가능성이 크고, 지금은 모두가 측정을 피하고 있을 뿐임 언젠가 투자자는 “200만 달러를 썼으니 순이익 400만 달러를 내라”고 요구할 텐데, 그런 결과는 나오기 어려움 Copilot과 Claude는 오래된 조직 지식, 문서화되지 않은 특수한 해결책, 미래 활용 가능성 같은 진짜 병목을 해결하지 못함 코드는 진짜 제품도, 진짜 일도 아니며, 건강한 코드베이스에서는 설계와 조사 과정의 거의 공짜 산출물에 가까움 “구매팀이 검색을 쓰기 어렵다”를 실용적인 티켓으로 다듬고 나면 React 검색 필터 컴포넌트는 사실상 이미 정해진 것이고, 코딩은 10분짜리 형식 절차에 가까움 Copilot이 그걸 5분으로 줄여도, 그 전에 들어간 **6시간 회의와 통화**를 생각하면 별로 인상적이지 않음 - 대기업은 아직 **코드는 적을수록 좋다**는 기본도 배우지 못했으니, 소프트웨어를 더 빨리 배포하는 같은 더 고급 개념을 갑자기 배울 거라고 기대하기 어려움 - 충분히 큰 시스템에서는 코드가 더 많아지는 것이 실제로 필요한 것과 반대가 되는 지점에 도달함 영양과 칼로리도 어느 선까지만 유용하고 이후에는 수익이 줄다가 결국 부정적 효과가 생김 완벽한 비유는 아니지만, 더 많이 찍어내는 것이 오히려 더 적은 가치를 낳는다는 사고 모델을 잡는 데 도움이 됨 고객에게서 문서가 완전하고 자세하지만 너무 압도적이라는 피드백을 받았고, 결국 핵심을 전하는 **짧은 bullet point** 몇 개가 5쪽짜리 문서보다 낫다는 걸 알게 됨 - 오래된 것이 다시 새로워졌을 뿐임: **제약 이론**의 AI 시대판 [0] [https://en.wikipedia.org/wiki/Theory_of_constraints]() [1] [https://www.goodreads.com/book/show/113934.The_Goal]() [2] [https://www.goodreads.com/en/book/show/17255186-the-phoenix-...]() - 오늘날 더 큰 대기업 환경에서는 AI 도입이 더 나쁜 방향으로 꺾인 것처럼 보임 재무팀에서 Copilot, Cursor, Claude로 재무 계획용 앱을 **바이브 코딩**해도 되냐고 물어왔고, “CFO가 Lovable을 테스트해보고 확신해서 우리에게 앱을 바이브 코딩하라고 했다”는 이유까지 들고 왔음 경영진이 “CFO가 말했다”는 말만 나오면 얼어붙는다는 걸 알고 그 논리를 앞세운 셈임 마지막에는 “적절한 데이터 보안과 유지보수성을 갖춘 바이브 코딩 앱이 기업 재무 영역에 존재할 수 있는지 확인해봐야 한다”는 그럴듯한 포장까지 붙였음 이게 연매출 200억 달러가 넘는 회사에서 나온 reasoning이라는 점이 더 놀라움 - 나 같은 평범한 엔지니어에게 회사에서 AI를 쓰는 건 실질적인 이점이 없음 회사가 우리를 서서히 끓이고 있고, HN의 엘리트층인 투자자, 임원, 유명인, 최상위 엔지니어들은 “혁신에 어떻게 반대할 수 있냐”고 말할 것임 AI/LLM은 TCP/IP, Linux, Postgres 같은 방식의 혁신이 아님 Claude, Codex, Gemini, Grok 같은 것들은 이윤을 위해 존재하며, 생산성을 마지막 한 방울까지 짜낸 뒤 더 이상 필요 없으면 해고 가능하게 만드는 도구임 AI가 좋다면 **오픈소스 모델**을 쓰고 개인 프로젝트에서 쓰는 편이 낫다 - 게임이 끝나는 게 아니라 바뀌는 중임 AI는 코드를 많이 뿌릴 수 있지만, 실제로 무슨 일이 벌어지는지 이해하는 엔지니어는 여전히 필요하고, 그게 늘 병목이었음 주니어 포지션은 사라질 수 있지만 **시니어 엔지니어**는 당분간 괜찮아 보임 나도 원래 반골이라 어렵게 배운 교훈인데, 고용된 이상 경영진이 원하는 일을 하라고 고용된 것임 저항한다면 그들이 눈치채지 못하거나 신경 쓰지 않기를 바라는 수밖에 없고, 큰 변화는 만들기 어려움 - 이점은 일이 훨씬 쉬워진다는 것 아닌가? 내가 뭘 놓치고 있는지 모르겠음 - 자본가에게 엔지니어가 착취당한다는 서사는 있지만, 임원 관점에서 봐도 “다음 분기 보너스”를 빼면 이 모든 게 미친 짓처럼 보임 SCO가 망해가며 업계에 무슨 일을 했는지 기억하는지 모르겠음 기업들이 내부의 **비밀 정보**인 코드, 프로세스, 고객 요구, 내부 정치, 리더십의 구상을 스타트업과 믿기 어려운 대기업 손에 넘기는 부분이 여전히 이해되지 않음 Microsoft도 한때 비밀유지계약과 거래 남용으로 유명했음 LLM 거대 기업들이 기업 자료로 학습하지 않을 리 없고, 아니라고 거짓말하지 않을 리도 없다고 봄 그들이 무너지기 시작하면 이 골드러시는 길고 추한 꼬리를 남길 수 있음 - CEO가 직원들을 어떻게 생각하는지, 해고가 왜 일어나는지에 대해 Hacker News에는 왜곡된 생각이 많아 보이고, 이건 아주 나쁜 해석임 실제로 해고되는 건 이런 기술을 도입하지 않는 쪽이고, 그렇게 행동하면 스스로 해고 범위 안에 들어가는 셈임 오늘 Coinbase 사례만 봐도, 미래를 받아들이지 않는 사람들을 정리하고 있음 그들은 발전을 돕지 않고, 앞으로 밀어붙이지도 않으며, 그렇게 하는 사람들을 붙잡기 때문임 - 글에서 **messy middle**을 정확히 짚었음 자기 책임과 일자리가 걸린 개발자가 이런 지능 루프를 만들 동기는 거의 없음 경영진이 아무리 좋게 부탁해도, 내 생산성 향상을 회사 전체에 무료로 이타적으로 공유할 생각은 없음 유용한 도구라면 공유할 수도 있지만, AI를 다루는 법이나 에이전트를 설정하는 법을 배우는 노하우는 공유에 대한 인정이 없다면 혼자 간직하는 편이 낫다 우리 회사는 도입 확산을 위해 “이번 주의 프롬프트” 상과 점심 세션을 만들었고, 이런 흐름을 개발하는 팀도 있음 하지만 실제 금전적 보상이나 고용 안정 없이 지식을 퍼뜨리는 위험과 비용은 전적으로 개발자에게 떨어짐 - 많은 사람이 왜 이렇게 생각하지 않는지 이해가 잘 안 됨 지금 AI가 이 정도가 되기 훨씬 전에도 업무를 쉽게 하고 자동화 스크립트를 작성하기 좋게 만들려고 개인 CLI를 만들었음 동료들이 그 도구를 보고 공유하라고 했지만, 외교적으로 표현한 답은 거절이었음 공유하면 지원 부담이 생기고, 모두가 나만큼 생산적으로 일하게 되어 내 이점이 사라지는 **부정적 수익**이 생김 더구나 리더십은 내 창의성을 자산으로 인정하지 않으니 고용 안정도 늘지 않음 가까운 미래에 어차피 해고될 수 있는데 선의로 회사를 도울 생각은 없음 지금 시장에서 개발자들이 일자리를 걱정한다면 개인 워크플로는 **영업비밀**처럼 다뤄야 함 이 예시는 AI에 한정된 건 아니지만 AI 워크플로에도 똑같이 적용됨 노동자 우위 시장에서는 그런 지식을 조직과 공유하는 게 가끔 재미있었지만, 고용주 우위 시장에서는 내 개인 선택에 접근하고 싶다면 돈을 내야 함 - 직장을 적대적으로 대해야 하는 건 별로지만, 회사가 “모두가 이렇게 생산적이고 많은 걸 달성하는데 왜 이렇게 사람이 많지?”라는 **제로섬 사고방식**을 갖는 한 어쩔 수 없음 직장을 가족이라고 보는 사람은 아니지만, 내 무덤을 파는 건 아닌지 걱정하지 않고 서로 일을 잘하고 공유할 수 있으면 좋겠음 - 고용주가 시간을 무료로 이타적으로 공유하길 기대한다면 착취당하는 것임 대부분의 사람은 일을 하라고 임금을 받고, 근무 시간에는 당연히 고용주를 위해 일해야 함 - 숨겨진다는 “비밀”들은 대체로 Gary Tan의 초강력 프롬프트 목록과 비슷한 수준임 사실 남들이 생각해낼 수 없을 만큼 대단한 건 거의 없음 내 경험상 프롬프트나 기술을 공유해도 쓰는 사람이 별로 없거나, 너무 기본적이라 이미 각자 자기 버전을 갖고 있었음 AI 전에도 누군가 xyz에 관심이 없었다면, 은쟁반에 담아 가져다줘도 AI 이후에 갑자기 관심을 갖지는 않음 - 또 다른 관점은 AI 도구가 처음에는 개인에게 이익을 주고, 사용자가 늘어난 생산성을 **여유 시간**으로 가져간다는 것임 지루한 일이 거의 사라지고, 어떤 문제는 넘겨두면 처리되면서 하루에 1~4시간이 되돌아옴 그 사람이 합리적으로 그 시간을 써서 더 많은 일을 찾아 나설까? 자기 회사이거나 특별한 동기가 있지 않은 한 그럴 가능성은 낮음 - 은퇴한 지 3년 된 시스템 분석가로서 젊은 동료들이 안쓰럽게 느껴짐 2023년에 팀에서 비교적 먼저 AI를 써서, 원 작성자가 오래전에 떠났고 주석이나 문서를 거의 남기지 않은 Perl 기반 **레거시 코드**를 풀어냈음 그 코드는 중요한 업무를 수행했고, AI가 곤경에서 꺼내줘서 모두가 이 신기술에 감탄했음 하지만 갈수록 이것은 내가 쓸 수 있는 도구라기보다 나에게 가해지는 무언가처럼 보임 아무도 이런 걸 요청하지 않았음 모든 것을 즉시 처리한다는 명목으로 영감과 사고가 언제부터 평가절하되고 무가치해지는 건지 모르겠고, 일에 영혼이 없어졌음 - AI 자체만으로는 그다지 유용하지 않음 에이전트는 잊어버리고 실수도 충분히 많이 해서 모든 작업을 확인해야 하며, 결과적으로 생산성이 오히려 낮아질 수 있음 진가를 발휘하는 건 AI를 **다른 도구를 만드는 도구**로 다룰 때임 예를 들어 작업이 특정 품질에 도달할 때까지 계속 진행하게 강제하는 도구를 만들게 하거나, 출력에 대한 준수 검사를 실행해 어디를 고쳐야 하는지 알려주게 하는 식임 그때야 비로소 작업을 신뢰할 수 있음 지금 대부분의 역할과 워크플로는 주어진 도구를 다뤄 특정 일을 해내는 구조로 설계되어 있고, 그런 체제에서는 AI가 가장자리에서만 끼어들 수 있음 - 좋은 글이고, 조직이 **일을 정의하는 방식**이 바뀐다는 부분이 특히 눈에 띄었음 예전 모델에서는 성과와 OKR이 직무 분야, 직함, 역할별 기대치에 묶여 있었음 AI 시대에는 그 경계가 무너지기 시작함 더 깊은 문제는 심리적·조직적이며, 사람들은 “이건 내 일이다”와 “이건 내 책임이 아니다” 사이의 선을 계속 협상하게 됨 그래서 핵심 도입 문제가 생김: AI 고급 사용자로 눈에 띄게 인정받는 것의 이점이 무엇인가? 내가 더 빠르고, 더 잘하고, 더 여러 기능을 넘나들어 일할 수 있다는 걸 알게 된다면, 회사가 인정·보상·커리어 성장을 위한 명확한 체계를 만들지 않는 한 왜 그걸 드러내야 하나? - 결국 운영 장애를 고치고 유지보수할 책임이 있는 사람이 소유권을 갖게 됨 에이전트들이 그 경계를 넘나드는 세상에서는 꽤 지저분해질 수 있음 에이전트 떼를 거느린 **AI 엔지니어**가 모든 걸 계속 운영할 책임까지 질까? 꽤 의심스럽지만 지켜봐야 함 - AI 고급 사용자에게 보상하는 체계를 만들면, 그 커리어 자체가 문제가 될 수 있음 그런 새 직업에 끌린 누군가가 회사별 맥락에 대한 조언을 몇 주 더 최신 접근법과 결합하면, 결국 그 사람은 제거될 **도메인 전문가** 역할에 놓이게 됨 - 팀원이 그런 것들을 기본값으로 해내기 시작하면, 그 사람과 나머지 팀 사이의 격차가 드러나기 전까지는 괜찮을 뿐임 - “작년에 Anthropic에 낸 200만 유로의 투자수익률은 어디 있나?”에 대한 답은, CEO 사무실에 걸린 YouTube 스타일의 **플래티넘 토큰 명패**임 - “작년에 Anthropic에 낸 200만 유로의 투자수익률은 어디 있나?”라는 질문에 깔린 가정의 편향이 정말 황당함 문제는 생성형 AI가 눈에 보이는 투자수익을 만들지 못한다는 것임 그런데 “해결책”은 개발 조직 전체를 그 기술 중심으로 재배치하고 새 도구를 발명하라는 식임 이런 글의 진짜 목적은 겉으로 다루는 내용이 아니라, 그 논의가 바탕으로 삼는 **가정의 정상화**에 있음 - LLM은 실패할 수 없고, 실패한다면 당신이 실패하게 만든 것뿐이라는 식임 - 지금 이 분야에서 일하는 건 정말 별로임 내가 다니는 회사에서는 상사들이 개발자가 아닌 사람까지 모두 AI를 쓰게 놔둠 정말 그만두고 다른 분야에서 일하고 싶지만, 내가 사는 곳에서는 초봉으로 월세를 감당할 수 없고 나이도 들어가고 있음 - AI의 약속을 **닷컴 붐**과 비교해 보면 이해에 도움이 됐고, 비슷한 점이 많음 하지만 인터넷은 기업 입장에서 더 단순한 개념이었음 기본적으로 이제 사람들이 자기 컴퓨터에서 물건을 살 수 있다는 뜻이었음 AI의 약속은 무엇인가? 사물에 대한 추론을 근사할 수 있다는 것인가? 이것은 진짜로 풀기 훨씬 어려운 구현 퍼즐임 코딩 작업 밖에서는 아직 실질적인 무언가를 본 적이 없는 것 같음