화요일 아침, 헬스장. 벤치프레스 첫 세트를 쉬는 동안, 어제의 과제 현황과 오늘 챙길 일이 정리된 브리핑 한 장을 읽습니다. 오늘 예정된 중요한 회의 준비를 클로드 코드의 Remote Control(원격으로 AI 세션에 접속해 대화하는 기능)로 던져놓고 다음 세트에 들어갑니다. 세트를 하며 다음 논점을 떠올리고, 쉬는 시간에 AI가 정리해둔 내용을 확인하며 이어갑니다. 운동이 끝날 즈음엔 주요 회의 준비가 어느 정도 진행되어 있습니다.
저는 컬리 딜리버리프로덕트에서 개발 리드를 맡고 있는 한경훈입니다.
어제 하루를 돌아보고, 오늘 있을 중요한 회의를 미리 챙겨두는 일은 제 오래된 루틴입니다. 하루를 준비해서 시작하느냐 아니냐에 따라 그날의 밀도와 산출물이 꽤 달라진다고 오래 느껴왔습니다. 이 작업을 어떻게 효율적으로 할지 고민해봤지만, 직접 모으고 정리하는 일 외에는 답을 찾지 못했습니다.
다만 지금은 같은 투자가 훨씬 적은 시간에 끝납니다. 오래 고민했던 아침 루틴을 마침내 풀게 되어, 후련하네요.
1. 반복되는 업무를 자동화하여 시간을 확보한다
Before — 오전이 통째로 들어가던 시절
1년 전, 이 루틴은 이른 아침 집 책상 앞에서 시작됐습니다. 슬랙·Jira·Confluence를 직접 돌아다니며 정리해야 했고, 출근 후엔 여러 스쿼드의 데일리 스크럼에 연달아 들어가다 보면 오전이 통째로 흘렀습니다. 한때 노션에 한 땀 한 땀 정리해보기도 했지만, 노동력으로는 오래가지 못했습니다.
올해 3월 처음 클로드 코드를 손에 잡았을 때, 가장 먼저 떠오른 것이 그 한 땀 한 땀의 기억이었습니다. 이번엔 자동화해볼 수 있지 않을까 싶었습니다.
After — 지금의 하루
아침에 완성된 브리핑 한 장을 읽습니다. 최근 어느 목요일 분량에는 프로젝트 현황, 오늘 챙길 것, 내가 요청한 일 등 여러 항목이 정돈되어 있었습니다. 직접 모으면 꽤 오래 걸리고 몇 건은 반드시 빠지던 양이, 15분이면 다 읽는 분량으로 압축됩니다.
브리핑은 슬랙 스레드·Jira 상태·PR 변경 내용 같은 여러 시스템의 원본을 대조해 정리한 편집본입니다. 스크럼에서 나오지 않는 배경과 디테일까지 한 장에서 보입니다. 덕분에 지금은 각 스쿼드의 데일리 스크럼을 스쿼드 자율에 맡기고, 저는 전체 흐름을 브리핑으로 파악합니다.
확보된 하루 한 시간 가까이는 예전에는 엄두도 못 내던 일로 흘러갑니다. 그 일이 무엇인지는 뒤에서 다시 이야기합니다.
수집은 스크립트, 판단은 AI에
브리핑이 처음부터 이런 모습은 아니었습니다. 첫 버전에서는 AI가 MCP(AI가 외부 시스템을 도구처럼 호출하는 표준 규격)로 슬랙·Jira·Confluence를 매번 직접 조회했는데, 가져온 텍스트가 전부 AI의 처리 비용(토큰)으로 계산되어 2~3일치만 수집해도 비용과 속도가 급격히 악화됐습니다.
해결은 단순했습니다 — 수집을 AI에서 떼어냈습니다. 외부 시스템 원본을 먼저 파일로 저장하는 수집 스크립트로 분리하고, AI는 그 위에서 요약·판단·페이지 생성만 맡게 했습니다.
반복되는 일은 스크립트로, 판단은 AI에.
이 원칙은 AI에게 상시 규칙으로도 지시해두었습니다 — 반복 작업은 직접 하지 말고, 스크립트로 만들어 재사용하라고요. 수집 단계에서 토큰은 거의 쓰이지 않게 되었고, 속도도 눈에 띄게 빨라졌습니다. 부수 효과로 결과의 일관성도 올라갔습니다 — 매번 같은 모양이 나오니 신뢰할 수 있게 됐습니다.
한 덩어리 명령을 네 단계로
같은 명령을 돌려도 세션마다 결과가 달라지는 문제도 있었습니다. 한 번에 너무 많은 일을 시키니 단계가 얽혀 매번 다른 결과가 나왔던 거죠.
“브리핑 생성”을 네 단계로 쪼갰습니다 — 수집 → 사람·과제별 요약 → 브리핑 페이지 생성 → 페이지 업로드. 어느 구간이 문제인지 바로 보이고, 해당 단계만 다시 돌리면 됩니다.
중간 데이터가 여러 용도로
중간 결과물인 요약 DB가 여러 작업에 재활용됩니다. 사람·과제별 요약이 DB에 쌓이니, 매번 다시 모으고 요약할 필요가 없습니다.
- 매주 두 가지 위클리 문서 draft가 이 DB에서 출발
- 사람별·과제별 최근 현황을 클로드에게 물으면 바로 응답
- 분기 타운홀 준비에도 같은 요약 정보 활용
2. 중요한 일을 더 잘하는 환경을 만든다
엔지니어가 해야 할 중요한 일은 엔지니어링 역량을 바탕으로 비즈니스 문제를 해결하는 일이라고 봅니다. 요구사항을 깊이 들여다보면 표면 뒤에 진짜 풀어야 할 이유가 보이고, 도메인과 시스템 구조를 함께 고려하면 구조적인 해법이 눈에 들어옵니다. 첫 대응은 임시 해결책일 수 있지만, 근본을 이해한 상태에서 고른 임시책에서 지속 가능한 솔루션은 자연스럽게 따라오더군요.
배차 정책 관련 과제 논의를 앞두고 있었습니다. 왜 이것을 해야 하는가, 무엇이 좋아지는가 — 얽힌 목적이 여럿이라 정리하고 얼라인하는 데 예전 같으면 꽤 긴 시간이 필요했을 일입니다. 이번엔 평소보다 빠른 시간 안에, 더 분명하게 정리를 마칠 수 있었고, 실제 회의에서 훨씬 수월하게 이야기를 풀어갈 수 있었습니다.
저는 이런 준비를 클로드 코드와 과제를 토론하는 라운드테이블이라는 공간에서 합니다. 개발을 제외한 거의 모든 업무를 여기서 논의하고, 지난 한 달 동안 13개의 과제와 19개의 구상이 이 라운드테이블을 거쳐갔습니다.
논의하면서 맥락(context)이 쌓인다
속도의 비결은 기술적 트릭이 아닙니다. 이전 대화로부터 발견된 운영 지식이 이미 맥락(context)에 남아 있기 때문입니다. 배차·배송·입고 같은 운영 정책을 한 번 풀어놓으면 클로드가 기억하기 쉬운 형태로 파일에 정리해두고, 다음 논의에서 이해한 상태로 바로 의견을 줍니다.
회의가 열릴 때마다 이 루프가 돕니다. 새 용어는 용어집에, 확정된 사항은 결정 파일에, 주제별 사실은 해당 주제 파일에 — 클로드가 스스로 판단해 자리를 잡아둡니다. 예를 들어 SPD(기사 1명이 하루에 배송하는 건수) 같은 용어가 새로 등장하면 그 자리에서 용어집에 추가되고, 다음 주 다른 과제 논의에서 제가 “SPD가 떨어지면” 한 마디만 해도 클로드는 바로 알아듣고 반응합니다.
네 관점으로 토론한다
딜리버리 조직 단독으로 진행하는 과제가 아닐 땐, 연관 조직의 정책과 의견을 함께 수렴해야 합니다. 물류센터의 출고 효율을 끌어올리는 과제가 있었는데, 출고 쪽만 손대선 안 되고 연결된 배송 프로세스까지 함께 바꿔야 해서 한 관점으로는 답이 나오지 않더군요. 클로드에게 한 세션 안에서 네 자리를 번갈아 맡기는 페르소나 시뮬레이션을 돌렸습니다 — 출고 운영, 출고 프로덕트, 배송 운영(컬리 넥스트마일), 딜리버리 프로덕트. 혼자 생각하면 놓치는 관점을 챙기는 장치이고, 실제 논의는 이 정리를 가지고 해당 조직과 함께 합니다.
제가 라운드테이블에 던지는 시작 프롬프트는 단순합니다. 과제 맥락을 한두 줄 얹고 “네 페르소나가 논의해서 결론을 도출해보자”라고 덧붙이면, 네 관점이 여러 턴에 걸쳐 서로 의견을 내고 받으며 대화가 이어집니다.
한 관점에서 “이 정도면 됐다”로 넘어갔을 지점에서 다른 관점이 놓친 연결고리를 드러내주더군요. 여러 바퀴 돌고 나면 제 판단이 한결 또렷해집니다.
늘 날카로운 의견이 나오지는 않습니다. AI는 아는 만큼 답할 뿐이라, 잘못된 전제를 잡아내는 일과 최종 판단은 제 몫입니다. 다만 “이건 이런 이유로 정했었지” 같은 맥락 리마인드만으로도 충분히 유용할 때가 많고, context가 풍부해지고 AI의 버전이 올라갈수록 이 라운드테이블은 점점 더 똑똑해질 거라고 봅니다.
3. 함께 나아지는 시스템을 만든다
데일리 브리핑이 시간을 확보해주고, 라운드테이블이 깊이를 더해줬다면, 이 장은 그 아래의 기반을 함께 올리는 이야기입니다.
앞의 두 개는 시작에 불과했습니다. 저는 업무의 시작점을 최대한 클로드 코드로 두려 합니다. 그래야 각 워크플로우마다 context가 쌓이고, 그 누적을 다음 작업에 재활용할 수 있기 때문입니다. 그렇게 반복되는 업무나 판단 단위로 워크플로우를 쪼개 만들다 보니 어느 순간 10개가 넘어 있었습니다. 주요한 것들을 소개하면 이렇습니다.
| 워크플로우 | 풀려 한 문제 |
|---|---|
| 데일리 브리핑 | 어제 진행된 현황과 오늘 챙길 일을 파악하기 |
| 중요 과제 논의 | 중요한 일을 더 잘할 수 있는 환경 만들기 |
| 배포 브리핑 | 릴리즈노트와 실제 배포 변경을 한 장에서 보기 |
| 인터뷰 스크리닝 | 지원자를 빠르고 일관된 기준으로 검토하기 |
| 개인 스터디 | 공부한 내용을 업무에 꺼내 쓰기 |
| 리더십 조언 | 상황에 맞는 리더십 조언을 빠르게 활용하기 |
이렇게 쌓이다 보니 같은 교정을 여러 워크플로우에 반복하고 있는 게 눈에 들어왔습니다.
- “내 의견에 무조건 동조하지 말고, 더 나은 판단은 근거와 함께 적극 제안하기”
- “축약어는 풀어서 설명하기”
- “요청한 범위만 손대기 — 같이 고칠 수 있어 보여도 다른 곳까지는 건드리지 말고, 특히 Git push처럼 되돌리기 어려운 동작은 꼭 요청이 있을 때만”
워크플로우마다 따로 규칙을 관리하니 매번 같은 말을 해야 했습니다.
‘팀장’ 역할의 프로젝트를 하나 만들어 이를 해결했습니다. 공통 규칙을 한 곳에 모아두고, 모든 워크플로우가 여기를 보게 했습니다.
이 팀장은 세 가지 일을 함께 맡습니다.
- 공통 규칙·보조 규칙 배포
- 각 워크플로우에 자기개선 루프 심기
- 한 곳의 개선을 전체로 퍼뜨리는 구조
공통 규칙이 모든 워크플로우로 반영된다
각 프로젝트의 CLAUDE.md(프로젝트 설정 파일) 맨 위에는 팀장의 공통 규칙과, 워크플로우별로 필요한 보조 규칙이 import 줄로 걸려 있습니다. 개발용 워크플로우라면 이런 두 줄이 걸립니다.
@../control_tower/shared.md
@../control_tower/refs/coding.md첫 줄은 모든 워크플로우가 공유하는 공통 규칙, 둘째 줄은 팀장이 “이 워크플로우엔 코딩 보조도 필요하겠다”고 골라 심어준 것입니다. 공통 규칙을 고치면 다음 세션부터 모든 워크플로우에 즉시 반영됩니다. 어떤 워크플로우를 새로 짜더라도 시니어 동료가 이미 옆에 앉아 있는 상태에서 시작하는 이유가 이것입니다.
자기개선 루프 — 어제의 실수가 오늘의 규칙이 된다
각 워크플로우 안에서는 자기개선 루프가 돌고 있습니다. 세션이 끝날 때마다 “이번에 뭘 잘못했나, 새로 알게 된 건 뭔가”를 자동으로 점검하고, 다음 세션에서 안 틀리도록 규칙에 반영하는 사이클입니다.
처음부터 전부 세팅할 필요는 없습니다. CLAUDE.md에 “마무리 때 이번 세션의 실수와 새로 확인된 사실을 제안해줘” 한 줄만 걸어두면 루프가 돌기 시작합니다. 아래에서 소개할 점검 항목들도 쓰면서 하나씩 붙은 결과입니다.
마무리 시 검사하는 항목들
마무리 루틴이 실행되면 클로드가 두 가지를 점검합니다.
첫째, 이번 세션에서 생긴 이슈:
- 위반 — 규칙을 안 지킨 경우
- 재발 — 고친 문제가 다시 발생
- 불만 — 사용자가 교정한 행동
- 환경 — OS·네트워크 한계
예를 들어 “축약어는 풀어서 설명하라”고 교정한 적이 있는데 다음 문서에서 또 약어가 등장하면 재발로 잡혀 규칙에 추가됩니다.
둘째, 규칙 저장소 자체의 건강: 접근성·완전성·실행력·경량성·일관성·범위, 여섯 관점으로 규칙이 비대해지거나 충돌하지 않는지 점검합니다.
두 가지에서 올라온 항목 중 규칙으로 만들 만한 것을 클로드가 제안하고, 승인된 것만 반영됩니다.
이 루프의 핵심은 기록이 아니라 다음번의 행동 변화입니다.
한 곳의 개선을 전체로 퍼뜨리는 방법
한 워크플로우 안에서만 배우면 그 안에서만 똑똑해집니다. 그래서 한 곳에서 배운 것을 전체에 퍼뜨리는 구조를 만들었습니다.
작동 방식은 이렇습니다:
- 세션 마무리에 워크플로우가 “이건 공통으로 기억할 안건”이라고 스스로 제안
- 승인하면 팀장 프로젝트의 제안함(
inbox.md)에 쌓임 — 개별 워크플로우는 공통 규칙을 직접 고치지 않고 제안만 올림 - 팀장 세션이 열리면 제안함을 열어 공통 규칙으로 분류해 배치
승격 기준은 단순합니다.
- 둘 이상에서 반복되거나
- 어떤 업무에든 통하거나
- 한번 정해두면 계속 쓸 원칙이거나
이 글을 쓰면서도 같은 루프가 돌았습니다. 세션이 끝나자 “이런 문제가 있었다 → 이렇게 해결했다 구조를 쓰라”, “3개 이상 나열은 불릿으로” 같은 교정 패턴이 정리되었고, 그중 범용성 있는 것들이 공통 후보로 올라갔습니다.
워크플로우가 똑똑해지는 속도는 시간이 아니라 얼마나 자주 쓰고, 얼마나 자주 고치느냐에 비례합니다. 매일 쓰는 워크플로우일수록 루프가 빠르게 익어, 한 달이면 다른 물건이 되어 있습니다. 여러 워크플로우가 따로 굴러가지 않고 같은 방향으로 함께 나아지도록 잡아주는 것이 팀장의 공통 규칙입니다.
AI 도구를 잘 쓴다는 것은 프롬프트를 잘 쓰는 일이 아니라, 기반 역량이 상향평준화되는 시스템을 설계하는 일이라고 생각하게 됐습니다.
다음 고민: 개인에서 조직으로
여기까지는 모두 제 개인의 하루였습니다. 개인에서 이렇게까지 바뀌고 나니, 이번엔 자연스럽게 조직의 일하는 방식으로 눈이 향했습니다.
AI Native 조직이라면, 어떻게 일해야 할까?
개인에서 통한 원리를 조직 층위에 그대로 올려보고 있습니다. 세 가지 질문을 고민 중입니다.
- 어디가 병목인가 — 지금의 프로세스에서 시간이 새고 있는 구간을 먼저 찾는 일.
- 어디가 AI의 몫이고, 어디에 사람이 꼭 들어가야 하는가 — 역할 경계를 다시 그리는 일.
- 조직 공통 context를 어떻게 쌓을 것인가 — 개인 라운드테이블에서 본 힘을 조직 규모로.
쉽지 않습니다. 이해관계자가 많고 합의도 만만치 않죠. 다만 한번 돌기 시작하면 조직 전체가 같은 바퀴를 함께 타게 된다는 건 분명해 보입니다. 첫 실험은 간단한 프로젝트부터 이미 시작했습니다. 레슨이 쌓이면 다음 기술 블로그로 다시 찾아뵙겠습니다.
마치며
제 경우엔 AI 도구 도입이 생산성 N% 향상의 문제가 아니었습니다. 같은 시간으로 하루의 구조를 다시 짤 수 있게 해주는 일이었습니다. 브리핑이 시간을, 라운드테이블이 깊이를, 팀장 구조가 이 전체의 기반을 함께 움직입니다.
1년 전의 저는 아침 책상 앞에서 슬랙에 파묻혀 있었습니다. 지금의 저는 헬스장에서 데일리 브리핑을 읽습니다. 시간에 쫓기던 아침은 여유가 되었고, 단순 처리에 묻히던 하루는 근본을 붙잡는 하루가 되었고, 작은 실수는 규칙으로 바뀌어 다음 날 돌아옵니다.
이 방식이 모두에게 맞지는 않을 수 있고, 단기적으로는 오히려 시간이 더 드는 구간도 있습니다. 그럼에도 하나 덧붙이자면 — 지금 하고 있는 일부터 자동화해보시길 권합니다. 반복되는 정보 수집 한 가지를 스크립트로 떼어내거나, CLAUDE.md에 마무리 한 줄을 걸어두는 것부터요. 한두 번의 지시로 첫 버전이 돌아가는 시대입니다.
부록: 오프닝 이미지 변천사
