Claude를 팀의 OS로 쓰고 있습니다

요즈음 업무에 AI를 쓴다는 이야기는 많이 듣습니다. 그런데 대부분은 궁금한 걸 묻고 답을 받거나, 바이브 코딩으로 있어 보이지만 정작 쓸 수는 없는 프로토타입을 뽑는 선에서 멈춥니다. 둘 다 한순간은 그럴듯해 보여도 일하는 방식까지 바뀌지는 않습니다. 개인이 가끔 꺼내 쓰는 도구에 머무는 거죠.

저는 Claude를 팀의 지식과 운영을 떠받치는 중추로 씁니다. 그렇게 묶고 나니 효율이 조금 오르는 데서 그치지 않았습니다. 원래 사람이 물리적으로 할 수 없던 일이 돌아가기 시작했습니다. 이 글은 그 과정을 정리한 기록입니다. 저는 여러 서비스를 운영하는 회사에서 개발 조직을 이끌고 있습니다.

시작은 막막함이었습니다.

출발점은 “도저히 제 시간안에 파악할 수 없는 10년간의 히스토리”였습니다. 거창한 비전 같은 건 없었습니다. 제가 맡은 조직에는 약 10년 넘게 쌓인 서비스와 코드, 운영 히스토리가 있었습니다. 새로 팀을 맡은 입장에서 이걸 파악해야 하는데, 사람이 다 읽는 건 애초에 불가능한 양이었습니다. 도메인 지식은 코드 어딘가에, 누군가의 머릿속에, 흩어진 문서에 조각조각 있었고, 결국 매번 사람에게 물어야 했습니다.

그래서 방향을 이렇게 잡았습니다. 히스토리를 사람이 읽는 대신, AI가 읽을 수 있는 컨텍스트로 바꾸자. 사람이 따라잡을 수 없으면 따라잡을 수 있는 형태로 정보를 옮기면 된다는 발상이었습니다. 이게 모든 작업의 출발점이 됐습니다.

핵심은 “구조”

가장 먼저 깨달은 건 잘 되는 이유가 모델 성능보다 구조에 있다는 점이었습니다. 같은 Claude라도 어떤 구조 위에 올리느냐에 따라 결과가 완전히 달라졌습니다. 제가 잡은 구조는 세 축입니다.

정리된 지식은 Google Drive에 둡니다. 검증된 정책, 도메인 지식, 운영 가이드처럼 한번 정리되면 오래 가는 것들입니다. 장기 기억에 해당합니다. 반면 지금 막 벌어진 일, 오늘의 대화와 실시간 상태는 Slack에 있습니다. 휘발성이 강한 실시간 정보죠. 그리고 Claude가 이 둘을 정해진 순서대로 읽고 판단합니다.

여기서 가장 중요한 원칙은 이겁니다. 정리된 진실과 지금의 진실을 구분한다. 정리된 지식은 Drive에 두고 거기서 가져옵니다. 지금 막 벌어진 일은 Slack에서만 가져옵니다. 정보마다 진짜 출처를 하나로 정해두는 거죠. 이 구분이 매 작업의 비용과 정확도를 가릅니다. 데모로 끝나는 AI와 실제로 일하는 시스템이 갈리는 지점도 정확히 여기였습니다. 가장 비싸고 불안정한 실시간 Slack부터 뒤지면, 그럴듯해 보여도 결과가 매번 흔들립니다.

정리된 것은 Drive에서, 지금 막 벌어진 것만 Slack에서. 이 순서가 비용과 정확도를 가릅니다.

정리된 지식이라고 전부 한곳에 두지는 않습니다. 팀 전체가 함께 봐도 되는 공개 영역과, 인사나 평가처럼 민감해서 한 사람만 봐야 하는 비공개 영역을 처음부터 갈라둡니다. 민감한 자료는 공개 영역에 아예 올라가지 못하게 막아두고요. 이렇게 해두면 ‘AI가 회사 문서를 읽고 답한다’는 편리함이 곧바로 정보가 새는 위험으로 이어지지 않습니다. 무엇을 어디까지 보여줄지를 구조가 대신 지켜주는 셈입니다.

구조에는 읽는 순서도 정해져 있습니다. Claude는 가장 가깝고 빠른 기억부터 확인하고 거기서 답이 나오면 멈춥니다. 없을 때만 한 단계씩 더 깊은 곳으로 내려갑니다. 그렇게 마지막에야 가장 비싸고 불안정한 실시간 Slack을 두드립니다. 순서를 지키면 같은 질문에 드는 비용이 확 줄고 답도 흔들리지 않습니다. 처음엔 이 순서를 자주 어겼습니다. 빠른 답이 급해 실시간부터 뒤지면 그럴듯한 결과가 나오긴 했어도 다음에 같은 걸 물으면 다른 답이 돌아오곤 했습니다.

여기에 더해 한 번에 읽는 양도 구조가 눌러줍니다. 흔히 컨텍스트가 크고 깊어지면 토큰 비용이 가파르게 불어난다고들 걱정합니다. 그런데 매 세션 vault를 통째로 읽지는 않습니다. 한 줄짜리 색인을 먼저 보고 필요한 노트만 펼치니 지식이 아무리 깊어져도 한 번에 읽는 양은 거의 일정합니다. 온톨로지로 정리해둔 구조가 곧 비용을 누르는 장치인 셈입니다. 실제로 이 모든 게 월 100달러 안팎, 프리미엄 시트 하나로 돌아갑니다. 그 하나로 수많은 MCP와 스킬을 붙여 쓰고 개발 작업까지 얹는데도 지금까지 단 한 번도 모자란 적이 없습니다.

그렇다고 실시간 정보를 매번 새로 긁어오면 느리고 불안정합니다. 그래서 자주 들여다보거나 매번 받아오기엔 무거운 값만 골라 그날의 스냅샷으로 따로 저장해둡니다. 하루가 지나면 만료시켜 다시 받아옵니다. 어디서 언제 가져왔는지를 함께 적어두니 이 값이 어느 시점의 것인지 헷갈릴 일이 없습니다. 한 번 보고 마는 정보까지 다 쌓아두지는 않습니다. 정리된 기억과 자주 쓰는 값의 스냅샷을 분리해두는 셈입니다.

Slack을 이렇게까지 쓰게 된 데에는 현실적인 이유가 있었습니다. 처음엔 협업 도구가 여기저기 흩어져 있었습니다. Google Workspace는 팀 협업용으로는 손에 잘 안 붙었습니다. Notion과 JIRA는 값은 비싼데 정작 제공하는 기능의 10%도 채 못 쓰고 있었습니다. 비싼 도구를 깔아두고 일부만 겉도는 상태였던 거죠. 그래서 그 둘은 정리했습니다. 그러고 나니 남는 건 어차피 메신저로 돈을 내고 있는 Slack이었습니다. 이미 비용을 치르는 도구가 마침 리스트와 캔버스까지 들고 있으니 거기에 무게를 싣기로 했습니다.

그러면서 Slack은 단순한 메시지 앱에 머물지 않게 됐습니다. 한쪽에서는 표 형태의 리스트를 가벼운 데이터베이스처럼 써서 업무와 기록을 쌓습니다. 다른 한쪽에서는 캔버스라는 문서를 회사의 공식 기록이자 지식의 뼈대로 씁니다. 같은 도구를 데이터 저장소와 문서 창고로 동시에 굴리는 거죠. 덕분에 팀이 이미 매일 쓰는 공간 안에서 모든 게 돌아갑니다. 새 시스템을 따로 익힐 필요가 없습니다.

여기서 놓치기 쉬운 게 하나 있습니다. 결국 새로운 데이터를 만들어내는 건 사람이라는 점입니다. 아무리 구조를 잘 짜도 사람이 입력하기 번거로우면 데이터는 쌓이지 않습니다. 그래서 사람이 접근하기 쉬운지를 무엇보다 신경 썼습니다. Slack 워크플로우를 적극적으로 써서 데이터를 적재하는 번거로움을 최대한 덜었습니다. 캔버스에는 어떻게 쓸지 규칙을 정해두고 리스트는 JIRA 못지않게 체계적으로 관리합니다. 체계는 단단하게 가져가되 사람이 손대는 입구는 최대한 가볍게 둔 셈입니다.

그래서 무엇이 돌아가고 있나

이 구조 위에서 실제로 가동 중인 것들이 있습니다. 하나씩 보면 별것 아닌 것 같지만, 공통점은 분명합니다. 전부 사람 혼자서는 매일 해내기 어렵던 일이라는 점입니다.

먼저 도메인 지식입니다. 10년치 히스토리를 30여 개의 정리된 노트로 옮겨, 매 세션마다 Claude가 자동으로 읽습니다. 덕분에 도메인 질문이 들어오면 사람에게 묻기 전에 1차 답이 나옵니다. 신규 합류자가 몇 달 걸려 익히던 맥락을, 이제는 에이전트가 매번 로드합니다. 도메인 전문가를 붙잡지 않고도 코드와 데이터, 정책 요구사항을 한 자리에서 맞춰볼 수 있게 됐습니다.

다음은 매일 자정에 도착하는 팀 활동 정리입니다. 팀원 열 명의 하루 활동을 모아 네 개 섹션 보고서로 만들고 정리된 링크를 제게 보냅니다. 이게 2주 넘게 하루도 빠짐없이 자동으로 돌고 있습니다. 예전엔 팀 현황을 알려면 수십 개 채널을 직접 순회하거나 데일리 미팅 구두 공유에 기대야 했고 그러다 보면 늘 빠지는 게 생겼습니다. 사람이 매일 수십 개 채널을 빠짐없이 읽는 건 사실 불가능에 가깝습니다. 그 불가능을 자정의 자동 작업이 대신합니다.

이 자동 정리가 잘 도는 데에는 전제가 하나 있습니다. 그 전에 제가 Slack을 잘 쓰는 문화를 먼저 깔아둔 겁니다. 제가 먼저 진행 상황과 결정, 이슈를 Slack에 적극적으로 남기며 본을 보였습니다. 팀원들이 그걸 따라 하면서 점차 익숙해졌습니다. 동시에 따로 보고를 받던 관행을 걷어냈습니다. 대신 그만큼 Slack에 더 잘 남겨달라고 팀에 전파했습니다. 자동 정리의 품질은 결국 팀이 Slack에 무엇을 남기느냐에 달려 있습니다. 사람이 먼저 기록 문화를 다져둔 덕분에 자동화가 제대로 돌기 시작한 겁니다.

전사 채널에서 도는 봇도 있습니다. 누구든 온보딩이나 행정 질문을 올리면, 회사 문서를 근거로 출처를 달아 답합니다. 재직증명서 발급은 어떻게 하는지, 우리 팀이 무슨 일을 하는지 같은 질문들이죠. 답이 문서에 없으면 그 사실을 솔직히 밝히고 추가할 내용과 위치를 제안한 뒤 승인을 받아 문서를 스스로 키웁니다. 답할수록 회사의 지식 베이스가 두꺼워지는 구조입니다.

회의도 바뀌었습니다. 예전엔 제가 있어야 주간회의가 제대로 굴러갔습니다. 지금은 진행 매뉴얼과 업무 리스트 필터 뷰를 Claude가 정리해둔 덕분에, 누가 진행을 맡아도 비슷한 품질이 나옵니다. 특정 사람에게 묶여 있던 일이 풀린 거죠.

막히는 곳은 늘 있었습니다

물론 매끄럽게만 흘러오진 않았습니다. 오히려 막히는 지점에서 배운 게 더 많았습니다.

초반에 자주 한 실수는 Claude가 “처음 보는 정보”라고 단정하는 것이었습니다. 자동으로 주입되는 메모리 색인에 없으면 모르는 거라 여기고, 곧장 Slack 실시간 검색으로 점프해 한참을 헤맸습니다. 그런데 실제로는 정리된 작업 폴더에 그 내용이 글자 그대로 있던 경우가 많았습니다. 색인에 없는 것과 어디에도 없는 것은 다릅니다. 그래서 단정하기 전에 반드시 정리된 폴더부터 직접 뒤지도록 규칙을 설정해뒀습니다.

기술적인 벽도 있었습니다. Drive를 공유 컨텍스트로 쓰다 보니 엑셀이나 워드 같은 압축 기반 파일이 마운트 환경에서 자꾸 깨졌습니다. 처음엔 원인을 몰라 한참 붙잡았습니다. 그러다 드라이브에서 파일 존재를 먼저 확인한 뒤 로컬에서 바이트로 읽어 메모리에서 푸는 방법을 찾아냈습니다. 이 방식을 스킬로 만들어둔 덕분에 이제는 같은 파일이 와도 곧바로 풀립니다. 한 번 부딪힌 벽이 다음부터는 벽이 아니게 된 셈이죠.

Slack을 다루는 방식도 한 번에 정리되지 않았습니다. 검색에 쓰는 권한과 글을 쓰는 권한이 서로 달라서 토큰을 두 갈래로 나눠 쓰게 됐습니다. 검색은 한쪽으로, 리스트와 문서 작성은 다른 쪽으로요. 처음엔 빈 줄이 생기거나 빈 행이 만들어지는 자잘한 사고가 이어졌고 그때마다 함정을 하나씩 메모로 남겼습니다. 공용 에이전트를 로컬 모델로 돌려보려다 품질이 받쳐주지 않아 접은 적도 있습니다.

신뢰는 구조에서 옵니다

이 시행착오들을 지나며 분명해진 게 하나 있습니다. AI 시스템이 믿을 만해지는 건 모델 지능 덕분이 아닙니다. 한 번 어긋난 판단이 같은 실수를 막는 규칙으로 바뀌어 시스템에 남기 때문입니다.

사람도 비슷합니다. 한 번 실수한 일을 다음엔 안 하려고 메모를 남기고 습관을 바꾸죠. 다른 점은, AI 시스템에서는 그 교훈을 메모리에 명시적으로 박아두면 다음 세션부터 자동으로 적용된다는 것입니다. 사람의 학습은 사람을 떠나면 사라지지만, 이 구조에서는 한 번의 사고가 영구적인 규칙이 됩니다. 그래서 저는 잘 도는 것보다 어긋났을 때 그게 규칙으로 남는지를 더 신경 씁니다.

한 번의 사고가 규칙이 되어 시스템에 남으면, 같은 실수는 다음 세션부터 반복되지 않습니다.

가장 아찔했던 건 채용 평가 기록을 정리할 때였습니다. 한 후보의 평가 메모에 바로 앞 후보의 회사 이름이 섞여 들어간 적이 있습니다. 사람으로 치면 치명적인 실수죠. 채용 판단의 근거가 통째로 흔들릴 수 있는 일이니까요.

이걸 잡아낸 건 작성한 내용을 스스로 한 번 더 점검하는 단계였습니다. 그 점검은 정식 규칙이 됐습니다. 이제 평가를 쓰기 전에 본인 프로필과 이력서로 신원을 자동으로 대조합니다.

앞서 이야기한 ‘단정하기 전에 정리된 곳부터 확인하기’나 파일이 깨지던 문제의 해결책도 같은 식으로 굳은 규칙입니다. 전부 한 번의 사고에서 나와 시스템에 내재화됐습니다. 근육이 부하를 받아 미세하게 찢어졌다 회복되며 더 강해지듯, 이 시스템도 사고를 한 번 겪고 그 자리를 규칙으로 메울 때마다 더 단단해집니다. 화려한 데모는 이런 부하를 겪을 일이 없습니다. 실제로 일하는 시스템에만 쌓이는 자산이죠.

여기서 제가 가장 마음에 들어 하는 부분은 이 축적이 제 손을 거의 타지 않는다는 점입니다. 따로 날을 잡아 시스템을 정비하지 않아도 됩니다. 그냥 평소처럼 Claude로 일을 시키면 한 세션이 끝날 때마다 새로 배운 규칙과 정리된 문서, 그날의 스냅샷이 알아서 남습니다. 팀이 Slack에 기록을 남길수록 다음 날 정리가 좋아집니다. 사람들이 봇에게 물을수록 회사 문서가 두꺼워집니다. 쓰면 쓸수록 시스템이 알아서 조금씩 단단해집니다.

무엇이 달라졌나

가장 크게 바뀐 건 제 일의 무게중심입니다. 흔히 “AI 덕분에 수집에서 판단으로 넘어갔다”고들 말하지만, 제 경우엔 정확하지 않습니다. 수집은 여전히 해야 합니다. 다만 그 부담을 시스템이 덜어주니, 저는 판단에 집중할 수 있게 됐습니다. 예전 같으면 도메인 히스토리를 다시 뒤지고 수십 개 채널을 훑고 회의 자료를 챙기고 반복되는 질문에 답하느라 적잖은 시간을 썼습니다. 그 시간이 줄어든 만큼 어디에 개입하고 무엇을 결정할지에 더 많이 쓸 수 있게 됐습니다.

솔직히 정량 지표로 “몇 퍼센트 개선”을 말하지는 못합니다. 그런 측정 체계를 따로 두지 않았으니까요. 대신 2주 넘게 멈추지 않은 자동 작업, 누구나 진행할 수 있게 된 회의, 사람에게 묻기 전에 답이 준비된 도메인 지식이 그 자리를 대신합니다.

결국 제가 배운 건 이겁니다. AI의 실제 가치는 그걸 어떤 구조와 규칙 위에 올리느냐에서 나옵니다. 모델이 얼마나 화려한지는 그다음 문제입니다. 아카이브와 실시간 정보를 구분하는 것, 사고를 규칙으로 남기는 것. 별로 멋있어 보이지 않는 이 두 가지가, 제 팀에서는 불가능을 가능으로 바꾼 진짜 엔진이었습니다.

이 방식을 팀과 나누는 일

처음 이 구조를 짤 때는 제 개인 도구에 가까웠습니다. 제가 맡은 일을 제가 편하려고 묶은 것이었죠. 그런데 한동안 돌려보니 혼자 쓰고 끝나면 의미가 절반이라는 생각이 들었습니다. 제가 자리를 비우면 그대로 멈추는 시스템은 결국 저에게 묶인 또 하나의 일거리일 뿐이니까요.

그래서 방향을 팀이 제게 의존하지 않는 것으로 잡았습니다. 주간회의를 누가 진행해도 같은 품질이 나오게 만든 것도 같은 맥락입니다. 제가 있어야만 돌아가던 일을 매뉴얼과 정리된 데이터로 옮겨두면, 그 일은 더 이상 저 한 사람의 것이 아니게 됩니다. 팀의 일이 되는 거죠.

전파는 위에서 아래로 내려보내는 방식으로는 잘 되지 않았습니다. 오히려 팀이 이미 쓰는 공간 안에서 자연스럽게 번졌습니다. 매일 도착하는 활동 정리의 품질은 팀원들이 Slack에 얼마나 남기느냐에 달려 있으니 시간이 지나며 기록하고 공유하는 문화가 함께 자랐습니다. 전사 채널의 봇은 다른 팀 사람들이 회사에 대해 묻고 답을 받는 사이, 그 답이 문서로 쌓여 회사 전체의 지식을 두껍게 만들었습니다.

그리고 그다음 고리가 이 글입니다. 팀 안에서 검증된 방식을 글과 뉴스레터로 바깥에 풀어놓는 것까지가 제게는 전파의 마지막 단계입니다. 한 사람의 생산성이 조금 오르는 데서 멈추면, 그 사람이 떠나는 순간 같이 사라집니다. 시스템과 규칙으로 남겨 다음 사람에게 건너가게 만드는 일, 저는 그게 AI를 제대로 쓰는 마지막 조건이라고 봅니다.

아직 남은 숙제

이 시스템이 일을 깊이 떠안을수록 도구 자체에 묶이는 정도도 같이 커졌습니다. Claude가 잠깐 흔들리거나 점검에 들어가면 그날 일정이 함께 멈출 수 있습니다. 매니징과 기획까지 얹어둔 터라 한 곳에 생긴 문제가 미치는 범위가 작지 않습니다. 그래서 정말 중요한 작업은 도구가 멈춰도 손으로 이어갈 수 있는 최소 절차를 따로 남겨두는 쪽으로 보완하고 있습니다.

외부에서 실시간으로 끌어오는 실제 현실정보는 생각보다 자주 늦게 업데이트됩니다. 조직도처럼 바깥 시스템이 원천인 데이터는 갱신이 밀려 있어서 그대로 믿으면 틀린 판단으로 이어집니다. 그래서 외부 값은 가져오되 내부에 정리해둔 문서와 반드시 대조하도록 해뒀는데, 이 대조를 더 자동화하는 게 다음 과제입니다.

성과를 숫자로 보여주지 못한다는 점도 계속 마음에 걸립니다. 가동 증거는 쌓이는데, 그게 시간을 얼마나 아꼈는지까지 추적하는 체계는 아직 없습니다. 거창한 대시보드까지는 아니어도 처리 건수와 개입 시점 정도는 가볍게 기록해두면 다음 판단에 쓸 수 있겠다고 봅니다.

마지막으로, 이 구조의 정확도는 결국 정리된 내용이 얼마나 최신인지에 달려 있습니다. 노트가 오래되면 답도 같이 낡습니다. 봇이 문서에 없는 내용을 자신 있게 답해버린 적도 있었습니다. 그래서 답이 흔들릴 때 스스로 출처와 불확실성을 드러내게 했습니다. 빈 곳을 발견하면 그 자리에서 문서를 채우도록 하는 장치도 조금씩 늘려가고 있습니다.

완성된 시스템이라고 생각하지 않습니다. 다만 어디가 약한지를 압니다. 약한 곳마다 다음 수를 두고 있고요. 지금은 그걸로 충분합니다.

그래서 마지막으로 묻고 싶습니다. 여러분의 AI는 쓸수록 단단해지고 있나요? 오늘 한 작업이 내일의 시스템에 남고 있는지, 한번 돌아보면 좋겠습니다.