AI 시대의 노동: 창조하는 인간에서 '확률을 관리하는 인간'으로
본의 아니게, 마치 스프린트 후 회고처럼, 주말에 시간이 나면 그동안 했던 일을 이렇게 한 번씩 리뷰하게 되네요. 나름 의미 있는 일이 되었으면 하는 바람입니다.
아시다시피, 혹은 모르시는 바와 같이. 저는 요즘 끌로드 코드로 일의 대부분을 처리하고 있습니다. 심지어 주말에도 일하면서 프로젝트 두 개 이상을 돌리자, 사용량이 모자라서 'MAX 200달러'로 업그레이드 했습니다.
원래 제가 해오던 일의 방식이 '끌로드 코드'라는 툴을 이용해 '자동화'되고, 그리고 그게 '빠르게' 이루어지다보니 생산성이 올라가는 것이죠.
생산성이 올라가도 여전히 하는 일은 기획과 QA
현재 안정화에 접어든 제 프로젝트를 잠깐 요약해보면 다음과 같습니다.
- 총 커밋: 1,855회
- 릴리즈 버전: v1.72.2 (107회 태그)
- 소스 코드: 564파일, 10만 라인
- 테스트 코드: 163 유닛, 18 E2E, 5.2만 라인
- API 엔드포인트: 11개
- Cloud Function: 4개
- 의존성: 46개 (prod 10 + dev 36)
결제를 다루고, 도메인 로직이 있고, 클라이언트 사이드 암호화를 처리하고, 장애 대응 절차를 갖추고 있고, 운영 인프라(개발/운영 분리, 클라이언트 에러 추적, 데이터 클렌징)를 갖추는 서비스를 안정화 시키기까지 4개월 정도 걸렸습니다. 분명 1인이 이 규모로 처리했다는 것 자체가 '압도적 생산성'을 증명한 거라 봅니다. 하지만 여기엔 '사람'의 수많은 개입과 확인, 상호 검증이 있었죠.
물론 이 또한 작업을 좀 더 처음부터 세밀하게 계획을 세워서 아예 '원자화'시키고, 그 원자화된 작업에 대한 '규칙'을 미리 세세히 세워두고 적용하는 '노하우'가 쌓여 있었다면 '사람'의 개입은 훨씬 줄어들었을 수 있을 겁니다. 그만큼 '빠른 자동화'가 더 생산성을 가속화 시킬 수 있을 거라 봅니다. 그런데 그 '노하우'를 AI가 알아서 정리하는 것이 끌로드 코드의 '오토메모리' 기능인데, 메모리가 철칙이 될까요? 제가 아이디어를 내고, 의사결정을 하고, 만들어낸 결과물을 검증해야하지 않을까요? 이미 E2E 자동화 케이스와 시나리오를 추가해도 '확률 싸움'이니까요.
CLAUDE.md는 철칙이 아니다.
끌로드 코드 공식 문서에는 CLAUDE.md 파일에 참조할 문서 등 전반적인 설명을 요약해서 정리하라고 되어 있습니다. 왜냐하면 매 세션마다 저 내용을 모두 컨텍스트에 주입하거든요. 게다가 이제 컨텍스트 크기도 기본이 1M인 시대입니다. 그럼에도, 끌로드 코드는 자주 저 CLAUDE.md 의 내용을 무시합니다. 철칙이 아닌 거죠.
제가 일을 해야하는 데 몇 가지 원칙이 있습니다.
1. 모든 작업은 MECE(Mutually Exclusive, Collectively Exhaustive)하게 정의하고 진행. -> 매킨지 컨설팅의 핵심 프레임이죠. 이건 언제나 모든 일의 기초가 되어야 합니다.
2. 단일 진실 공급원(SSOT, Single Source of Truth)을 유지한다. -> 파일, 변수 등등을 여기 저기 복사해서 버전2, 버전3 관리도 안 되는 상황을 피해야 합니다.
3. 언제나 근거(Evidence before claims)를 먼저 확인한다. -> LLM 모델은 '학습된 것'입니다. 그렇기 때문에 '추측'으로 내뱉는 게 많습니다. 이 상황을 피해야 합니다. 세상은 미친듯이 빠르게 돌아갑니다.
위 세 가지 원칙은 항상 유지해야하는 것이기 때문에 글로벌 레벨의 CLAUDE.md에 둡니다. 그리고 프로젝트 특화 사항은 프로젝트 내부에 배치하는 것이죠. 그렇게 운영하다가 새로운 노하우가 생기면 '범용'일 경우 '유저 레벨(글로벌)'에, '프로젝트 특화'면 프로젝트 레벨에 배치를 합니다. 그리하여 상속 받을 것은 상속받게 하고, 오버라이드 해야할 것은 오버라이드 처리하죠.
그리고 유저 레벨의 끌로드 코드 폴더(맥의 경우 ~/.claude)에서 '로컬'에서 쓰이는 것은 gitignore로 처리해두고, 모두 제 깃허브 프라이빗 리포에 자동으로 푸시해두도록 쉘 스크립트로 자동화해둡니다. 이 또한 'hook'을 이용해 파일 변경이 생기면 자동으로 리모트에 푸시하고, 제가 일하는 디바이스 - 맥북프로, 맥미니 등 - 에서 zsh alias 명령어로 claude를 처리해 두면 git에서 pull 부터 받고 claude가 구동되도록 처리해 두었습니다. 이러면 어느 환경에서든 늘 동일한 '글로벌'의 끌로드 코드를 사용할 수 있겠죠.
문제는 이겁니다. 제가 다음 문단에 언급할 claude-code-guide 스킬부터 시작해서 MECE, SSOT, Evidence before claims 모두 사실 '확률 싸움'입니다. AI 모델은 본질적으로 '확률적(Probabilistic)' 모델이고, LLM은 본질적으로 다음 단어를 확률적으로 예측할 뿐, 논리를 완벽하게 연산하는 기계가 아니므로 훅과 룰로 이 '확률적 빗나감'을 억눌렀을 뿐입니다.
인간과 비슷해요. 인간도 철칙, 십계, 신조, 강령, 계명, 불문율, 좌우명. 다 있어도 잊거나 그 때 그 때 자기가 처한 상황에 따라 무시합니다. 인간처럼 작동하는 게 당연한 걸지도 몰라요. 그렇기에 hook, rule, skill 이 필수입니다. - 심지어 지난 주 업데이트로 rule과 skill의 경계도 모호해지기 시작했네요. - 잠시 제가, 우리가 어떻게 일했는지를 돌이켜봅시다.
끌로드 코드가 없던 시절 우리는 어땠나요? 다이어리에 할일(To Do)을 적어놓던가, 아니면 Things 같은 앱을 써서 To Do를 관리하고, 캘린더로 약속을 잡고, 리마인더로 까먹지 않으려 노력하고, 매뉴얼을 만들어 프로세스를 지키려 노력하고. 그럼에도 '어디에 적어뒀는지' 까먹고, 매뉴얼이 있어도 '무시하고'.
끌로드 코드도 CLAUDE.md 만으로 안 되는 겁니다. 마치 매뉴얼처럼 skill을 정의해서 작업의 순서와 사용도구, 참조문서 등을 모두 정리해 두고, rule을 둬서 어떤 파일을 수정할 때는 어떤 원칙을 따라야하는지 기록해두고, hook을 둬서 해당 프로세스를 처리한 후 반드시 이행해야 하는 것들에 대해서 '통제'하고.
결국 이 모든 프로세스를 '관리 감독'하면서 구멍나거나, 문제가 생기는 부분들에 대해서 방어책과 재발방지를 만들어나가고, 이를 '자동화'해나가면서 더 견고하게 만들고.
원래 인간이 하던 일들을 조금 더 '빠르게 자동화'하는 것입니다. 그리고 남는 시간을 좀 더 창의적이고 '인간적인 일'에 투자할 수 있어야할텐데, 정작 사람은 AI의 QA가 되어가고 있지요.
하루 시작 루틴
아침에 터미널에서 'claude update'를 합니다. - 물론 끌로드 코드는(제 경우에는 네이티브 설치 사용자입니다만) 사용 중에 백그라운드 업데이트가 됩니다. - 그리고 'claude'를 실행하면 미리 만들어둔 세션 시작 'hook'이 마찬가지로 미리 만들어둔 'claude-code-guide' 스킬의 버전을 체크하고 현재 끌로드 코드 버전과 다르면 '가이드 업데이트가 필요하다.'고 시스템 메시지를 보여줍니다. 그리고 이 시스템 메시지가 보이면 'upgrade-guide'라는, 마찬가지로 커스텀으로 만든 스킬(현재 유저 레벨 - 글로벌 - 의 hook, rule, skill 전수를 검토해서 release-note의 내용을 반영할 게 있는지 체크해서 반영하고, 그 다음으로 하위의 프로젝트 레벨의 hook, rule, skill 전수를 동일하게 처리)로 현행화를 합니다.
'claude-code-guide' 스킬을 직접 만든 이유는 간단합니다. 플러그인 중에 '최신 문서'를 검색해서 알려주는 'context7'이란 것이 있는데, 이걸 신뢰를 못합니다. 우리가 살면서 '문서 현행화'가 잘 되는 경우가 많았나요? 턱없는 바람이죠. 게다가 context7 확인도 대충해요. 차라리 웹 fetch를 하는 게 낫습니다. 앞서 언급했듯이 CLAUDE.md 파일도 대충 읽습니다. 그래서 'context7 확인해서 현재 작성한 스킬이 끌로드 공식문서에서 권장하는 방식인지 알려줘'라고 얘기해봤자 큰 의미가 없다는 걸 깨닫게 됩니다. 그 사이 변경된 것이나, 오류 수정, 패치 등이 많거든요. 거의 일주일에 두 세개씩 굵직한 기능이 나옵니다.
이 뿐만이 아닙니다. 끌로드코드 공식 플러그인도 100개가 넘습니다. 새로운 플러그인이 추가될 때마다 그 플러그인이 어떤 용도고, 현재 설치한 플러그인이나 제가 사용하는 스킬과 충돌이 있는지 없는지 검증해서 '채택' 또는 '무시'할지 판단하는 것도 자동화해두었습니다.
개발자들이 git에서 pull을 받아 현행화 하는 것과 프로세스는 다를 게 없죠. '원래 하던 일하는 방식'입니다. 이 툴에 의존해서 일을 해야하니, 사용하는 툴의 최신 현행화를 해서 적용해나가야 하는 거죠.
맺으며...
사실 매일이 즐겁긴 합니다. 간만에 빨리 일어나 책상 앞에 앉아 일을 이어가고 싶은 생각이 머릿속에서 떠나질 않아요. 그리고 이런 끌로드 코드의 '환경'이 확률의 위험도를 현저히 낮춰줄 거라 판단됩니다.
그럼에도, 어느 주말 깊은 밤. 여러가지 고민에 맥주 한 캔과 함께 우리의 미래가 걱정되는 건 이 또한 '확률' 때문이겠지요.
