새벽 2시 온콜이 사라진 팀의 비밀
14개 마이크로서비스, 18만 줄 코드베이스, 세 개의 개발 스쿼드. dev.to에 올라온 한 엔지니어의 사례는 현실적인 숫자에서 시작한다. 4주 연속 금요일 새벽 온콜. 스택 트레이스 읽고, null 체크 추가하고, 테스트 쓰고, 배포하고 다시 잠드는 루틴. 이 패턴이 반복되면 좋은 엔지니어는 이직을 생각하기 시작한다.
해법은 Claude Code와 OpenClaw를 조합한 Codewatch라는 자동화 시스템이었다. Sentry 웹훅이 사고를 감지하면 → OpenClaw가 트리아지 판단을 내리고 → Claude Code가 코드를 직접 읽고 수정하고 테스트를 돌린 뒤 → GitHub PR을 만들어 Slack에 알림을 보낸다. 아침에 일어나면 리뷰할 PR이 생겨 있는 구조다.
두 도구는 서로 다른 존재다
이 사례에서 가장 인상적인 부분은 아키텍처 판단이다. Claude Code를 단독으로 쓰면 스케줄링, GitHub 연동, Slack 알림을 모두 직접 구현해야 한다. OpenClaw만 쓰면 이벤트 라우팅은 되지만 실제 코드 수정 깊이가 부족하다. 둘을 합쳤을 때 비로소 실용적인 시스템이 완성된다.
원문은 이를 명쾌하게 정리한다. "Claude Code는 레이저다. OpenClaw는 그것을 겨누는 신경계다." 자동화 수정 대상은 처음부터 범위를 좁혔다. 미처리 프로미스 거부, null 역참조, 스키마 드리프트, 누락된 에러 바운더리, API 응답 타입 강제 변환. 어렵지 않지만 반복적인 다섯 가지 오류 클래스. 여기서 핵심 통찰이 나온다—AI 자동화는 '어려운 문제'가 아니라 '반복적인 문제'에 먼저 써야 ROI가 나온다.
설정도 코드처럼 설계해야 한다
Claude Code를 팀에 심을 때 실무자들이 가장 많이 놓치는 부분이 있다. 설정 파일을 '붙여넣고 잊어버리는 문서'처럼 다루는 것이다. Jeff Reese가 2년 이상의 Claude Code 운용 경험을 바탕으로 정리한 Rules vs Skills 구분은 이 문제를 정면으로 다룬다.
Rules는 인식(recognition), Skills는 절차(procedure)다. Rules는 항상 컨텍스트에 로딩된다. Skills는 필요할 때만 불러온다. 언뜻 단순해 보이지만, 여기서 실패 모드가 두 가지로 갈린다. 행동해야 할 순간을 놓쳤다면 Rule 문제다. Rule이 컨텍스트에 없었으니 트리거가 조용히 지나간 것이다. 절차를 틀렸다면 Skill 문제다. 상황은 인식했지만 실행 방법이 로딩되지 않았다.
실제로 자신의 설정을 감사해보니 30~50줄짜리 Rule이 매 대화마다 로딩되고 있었는데, 그 중 실제 사용되는 세션은 5%에 불과했다. 5개 Rule을 분리하는 것만으로 항상 로딩되는 컨텍스트 120줄을 절약했다. 토큰은 돈이기도 하지만, 더 중요한 건 모델의 주의(attention)가 실제 작업에 집중되는가이다. 컨텍스트가 비대해질수록 모델은 더 똑똑해지는 게 아니라 더 산만해진다.
500명 교육이 가르쳐준 것: 도구보다 마인드셋이 먼저
이론은 충분하다. 실제로 팀 전체를 바꾸는 건 어떻게 가능한가. Jeff Reese는 ChatGPT 출시 직후부터 실험을 시작한 얼리어답터로, BambooHR에서 거의 500명 엔지니어에게 LLM 활용 교육을 진행한 경험을 공유한다.
시작은 VP 앞에서의 라이브 코딩 데모였다. Windsurf로 몇 분 안에 완성 앱을 만드는 장면을 전사 R&D 앞에서 보여줬을 때, 이미 AI를 쓰던 본인도 놀랐다고 한다. 이후 커리큘럼을 만들고 일주일 4일, 3개 반을 운영했다. 수업 전날 밤에 강의안을 쓰고 다음 날 아침 가르치는 속도였다. 결국 이 녹화 자료는 전사 신입 온보딩 표준 자료가 됐다.
가장 중요한 발견은 기술이 아니었다. "AI가 당신 일자리를 빼앗는 게 아니라 능력을 증폭시킨다"는 'AI 운영자 마인드셋'을 심는 것이 진짜 과제였다. 변화는 기술 스택을 바꾸는 것보다 사람들이 자신의 커리어 정체성을 어떻게 재정의하느냐에 달려 있다.
테크 리드가 지금 당장 실행할 수 있는 세 가지
세 사례를 하나의 플레이북으로 수렴시키면 실행 가능한 순서가 나온다.
첫째, 반복 오류 패턴부터 자동화하라. Codewatch 사례처럼, 온콜 로그를 30일치 뽑아서 반복되는 오류 클래스 다섯 개를 골라낸다. 거기에 Claude Code를 먼저 투입한다. 복잡한 비즈니스 로직이 아니라 지루한 반복 작업이 첫 번째 타깃이다.
둘째, CLAUDE.md를 감사하라. 팀의 설정 파일을 열고 각 Rule이 지난 한 달 동안 몇 퍼센트 세션에서 실제로 필요했는지 따져본다. 5% 미만이라면 Skill로 분리한다. "혹시 모르니까 항상 로딩"은 컨텍스트 오염의 원인이다.
셋째, 첫 교육은 데모로 시작하라. 슬라이드보다 라이브 코딩이 설득력이 높다. 팀에서 가장 지루한 반복 작업 하나를 골라, Claude Code가 실시간으로 처리하는 장면을 보여주는 것이 천 줄의 설명보다 효과적이다. 500명 교육의 출발점도 10분짜리 데모였다.
AI-First 팀의 진짜 무기는 구조다
솔직히 말하면, Claude Code 자체의 성능은 이미 충분히 검증됐다. 지금 팀마다 결과가 갈리는 이유는 도구의 차이가 아니다. 얼마나 구조적으로 심었느냐의 차이다.
자동화 파이프라인 없이 Claude Code를 쓰면 개인 생산성 도구에 머문다. 설정을 설계하지 않고 쌓아두면 컨텍스트가 오염되어 오히려 느려진다. 도구 교육 없이 도입하면 팀원 절반이 한 달 뒤에도 여전히 Stack Overflow를 쓰고 있다.
세 사례가 공통으로 가리키는 방향은 하나다. AI 도구는 혼자 쓸 때 도구지만, 팀 워크플로우에 구조적으로 심을 때 무기가 된다. 그 구조를 설계하는 것이 지금 테크 리드의 핵심 역할이다.