목표만 남깁니다 | DAKER 커뮤니티
오늘은 새 버튼을 한 번 눌러 보고 끝내는 글이 아닙니다. Claude Code를 만드는 팀이 실제로 어떻게 일하는지를 영상으로 확인한 뒤, 빌더가 같은 날 따라 할 수 있는 최소 실험으로 옮기는 노트입니다. 목표만 남깁니다.
참고 영상은 Claude 채널의 How the Claude Code team uses Claude Code입니다. 채널 주소는 @claude입니다. yt-dlp 기준 게시일은 2026년 9월 2일입니다. 길이는 1343초입니다. oEmbed 기준 제목은 How the Claude Code team uses Claude Code입니다. 이 글에는 주소만 둡니다. iframe은 넣지 않습니다. 제품 문서의 출발점은 Claude Code Overview입니다. 팀 실무에 가까운 패턴 정리는 Best practices for Claude Code입니다. 병렬 작업의 종류는 Run agents in parallel입니다. Slack 쪽 Claude Tag 안내는 Claude Tag입니다. 로컬에서 차이를 검토하는 명령은 Code Review 문서의 /code-review입니다. 오늘 아침 잡담에 올린 Grok Build, Claude EFS, OpenAI Astra, Gemini Flash, GLM Flash 소식과, 참가 안내의 기획서·PPT 글은 이 슬롯에서 다시 쓰지 않습니다. 2026년 8월 27일에 올린 루틴 영상 글과도 각도를 나눕니다. 오늘은 /schedule 워크숍이 아니라, 목표 단위로 맡기고 검증 신호로 끝내는 팀 습관입니다.
영상이 말하는 일의 단위
영상에서 팀원들은 예전의 Claude Code 사용 방식을 짧게 회고합니다. 예전에는 프롬프트를 넣고, 피드백을 주고, 권한 확인을 하나씩 수락하는 흐름이 중심이었습니다. 지금은 일의 단위가 달라졌다고 말합니다. 개별 도구 호출과 트랜스크립트 한 줄 한 줄을 붙잡는 대신, 목표를 주고 그 목표가 달성되는지 보는 쪽으로 옮겼다고 설명합니다. 이 문장은 영상 발언입니다. 제품 광고 문장이 아닙니다.
한 팀원은 일상 업무의 상당 부분이 Slack의 Claude Tag로 옮겨 갔다고 말합니다. 다른 팀원은 대략 70퍼센트에서 80퍼센트 정도의 일을 Claude Tag에서 한다고 말합니다. 이 숫자는 영상 속 개인 경험입니다. Anthropic 공식 지표로 옮기지 않습니다. 문서가 적는 범위만 따로 확인합니다. Claude Tag는 Team과 Enterprise에서 쓰는 Slack 통합이고, 조직의 공유 신원으로 채널에 @Claude를 태그해 일을 맡깁니다. Pro와 Max에서는 Claude Tag가 없고, 이전의 Claude Code in Slack 경로를 쓴다고 문서가 적습니다. 출처는 Claude Tag입니다.
Claude Tag의 화면은 전체 트랜스크립트와 한 겹 떨어져 있다고 영상에서 설명합니다. Slack에 보이는 메시지는 모델이 도구로 보낸 메시지이고, 내부에서 어떤 도구를 어떤 인자로 호출했는지는 기본 화면에서 다 보이지 않습니다. 전체 트랜스크립트는 링크로 열 수 있다고 말합니다. 처음에는 모든 생각을 보지 못하는 느낌이 불편했다고 합니다. 이후에는 모델이 무엇을 말할지와 언제 말할지를 고르게 두고, 세부를 감시하지 않는 쪽이 일의 속도를 올려 주었다고 말합니다. 이 역시 영상 경험담입니다.
문서가 적는 검증 루프
베스트 프랙티스 문서는 한 문장으로 시작합니다. Claude에게 스스로 확인할 수 있는 신호를 주십시오. 테스트, 빌드 종료 코드, 린트, 기준 이미지와 비교하는 스크린샷이 그 예에 해당합니다. 확인 신호가 없으면 Claude는 일이 끝난 것처럼 보이는 지점에서 멈춥니다. 그때 사람이 다시 확인해 주는 루프가 생깁니다. 확인 신호가 있으면 Claude가 일을 하고, 신호를 읽고, 통과할 때까지 반복합니다. 출처는 Best practices입니다.
같은 문서는 탐색, 계획, 구현, 커밋을 나누라고 적습니다. 계획 모드는 Shift+Tab으로 켜거나 claude --permission-mode plan으로 시작할 수 있습니다. 범위가 분명하고 수정이 작은 일은 계획을 건너뛰어도 된다고 적습니다. 여러 파일을 건드리고 접근이 불확실할 때 계획이 도움이 됩니다. 이 글은 문서에 없는 성공률을 만들지 않습니다.
CLAUDE.md는 매 세션 시작에 읽히는 프로젝트 지시문입니다. 짧게 두고, Claude가 코드만 읽어도 알 수 있는 내용은 빼라고 문서가 적습니다. 가끔만 쓰는 도메인 지식은 스킬로 두고 필요할 때 불러오라고 합니다. 훅은 예외 없이 매번 실행되어야 하는 동작에 쓰고, 스킬은 반복 워크플로와 도메인 규칙에 씁니다. 조사처럼 파일을 많이 읽는 일은 서브에이전트에 맡겨 본문 대화의 문맥을 지키라고 합니다. 출처는 Overview와 Best practices입니다.
검토는 큰 그림으로 올라갑니다
영상에서 코드 리뷰 이야기를 길게 나눕니다. 예전 사람 리뷰에서는 코드를 읽었다는 표시로 작은 수정 제안을 세 개쯤 남기는 일이 흔했다고 말합니다. 지금은 그 작은 항목을 Claude가 먼저 다루고 고칠 수 있다고 합니다. 사람이 남길 일은 API가 왜 이런 모양인지, 서비스 경계가 왜 여기에 있는지처럼 Claude가 PR을 쓰는 순간에 덜 담아 둔 제품·구조 맥락이라고 말합니다. 즉 리뷰의 추상도를 한 단계 올리라는 말입니다.
제품 문서의 Code Review는 두 층으로 나뉩니다. Team과 Enterprise에서는 GitHub PR에 자동 또는 수동으로 다중 에이전트 리뷰를 붙일 수 있는 연구 미리보기가 있습니다. 다른 요금제에서도 로컬 세션의 /code-review로 현재 브랜치와 작업 트리 차이를 검토할 수 있습니다. /review는 같은 명령의 별칭입니다. 관리형 PR 리뷰는 Zero Data Retention 조직에서는 쓸 수 없다고 문서가 적습니다. 심각도는 Important, Nit, Pre-existing로 표시됩니다. 저장소 루트의 REVIEW.md로 리뷰 전용 규칙을 줄 수 있습니다. 출처는 Code Review입니다. 문서에 적힌 평균 비용 구간은 팀마다 다르므로, 이 글은 금액을 다시 적지 않습니다. 관리 화면과 청구서를 직접 확인하십시오.
베스트 프랙티스는 구현이 끝난 뒤 신선한 문맥의 서브에이전트로 차이를 검토하라고도 적습니다. 글을 쓴 세션이 스스로 채점하지 않게 하려는 목적입니다. Writer와 Reviewer를 서로 다른 세션으로 나누는 패턴도 같은 문서에 있습니다.
병렬과 워크플로는 오늘의 심화가 아닙니다
문서에는 서브에이전트, agent view, agent teams, dynamic workflows가 나란히 있습니다. dynamic workflows는 Claude가 쓴 스크립트가 많은 서브에이전트를 조율하는 방식입니다. /deep-research가 묶여 있는 예입니다. agent teams는 실험 기능이고 기본값이 꺼져 있다고 문서가 적습니다. 오늘은 이 층을 깊게 다루지 않습니다. 링크만 남깁니다. Orchestrate subagents at scale with dynamic workflows, Run agents in parallel.
클라우드에서 돌아가는 루틴은 2026년 8월 27일 잡담에서 이미 다뤘습니다. 영상에서도 호스팅된 세션과 피드백을 묶는 이야기로 다시 나옵니다. 오늘은 루틴 생성 절차를 반복하지 않습니다. 필요하면 그때 글과 Routines 문서를 다시 여십시오.
오늘 할 최소 실험
민감하지 않은 연습용 저장소 하나만 고르십시오. 운영 비밀, 고객 개인정보, 배포 권한이 없는 저장소여야 합니다.
1. 검증 문장을 먼저 적습니다
새 세션을 열고, 구현 요청보다 먼저 통과 조건을 한 줄로 적습니다. 예시는 문서 표를 따릅니다. 함수를 구현한 뒤 지정한 테스트 케이스를 실행하고, 실패하면 고친 다음 다시 실행하라는 문장입니다. UI가 있으면 기준 스크린샷과 결과 스크린샷을 비교하고 차이를 고치라고 적습니다. 출처는 Best practices의 verification 절입니다.
2. 목표 단위로 한 번만 맡깁니다
도구 목록을 나열하지 마십시오. 달성할 상태와 검증 명령만 적습니다. 예: 로그인 타임아웃 이후 토큰 갱신 실패를 재현하는 테스트를 추가하고, 고친 뒤 해당 테스트만 통과할 때까지 반복하십시오. 파일이 많으면 계획 모드로 먼저 읽고, 계획이 맞을 때만 구현으로 넘기십시오.
3. 차이를 로컬에서 한 번 검토합니다
브랜치에 커밋이 쌓였거나 작업 트리에 변경이 있으면 /code-review를 실행합니다. 결과는 별도 문맥의 서브에이전트에서 돌아와 본문 대화를 덜 채웁니다. Team이나 Enterprise이고 GitHub 앱 연동이 되어 있으면, 테스트 PR에 @claude review를 최상위 댓글로 남겨 관리형 리뷰를 한 번 호출할 수 있습니다. fork PR은 자동 실행되지 않고 댓글 명령이 필요하다고 문서가 적습니다.
4. Slack이 열려 있으면 목표만 태그합니다
Team이나 Enterprise에서 Claude Tag가 켜져 있으면, 채널 스레드에 @Claude로 목표와 검증 조건만 적습니다. 도구 호출 목록을 적지 않습니다. Pro나 Max라면 Claude Tag 문서가 가리키는 이전 Slack 경로를 쓰거나, 오늘은 CLI와 데스크톱만으로 1부터 3까지 끝내십시오. 없는 기능을 있다고 가정하지 않습니다.
검증 신호를 고르는 기준
베스트 프랙티스 문서는 확인 신호를 세 층으로 나눕니다. 같은 프롬프트 안에서 테스트를 돌리고 고치라고 적는 방법, 세션 전체에 /goal로 완료 조건을 거는 방법, Stop 훅으로 스크립트가 통과할 때까지 종료를 막는 방법입니다. 오늘은 첫 층만 쓰면 충분합니다. 같은 메시지에 구현과 검증을 함께 적으십시오. 문서가 적는 순서입니다.
증거가 없는 성공 선언은 받지 마십시오. 테스트 출력, 실행한 명령과 종료 코드, 결과 스크린샷을 남기라고 문서가 적습니다. 자리를 비운 세션일수록 증거가 필요합니다. 이 문장은 Best practices의 verification 절을 옮긴 것입니다.
실패가 두 번 반복되면 같은 세션에서 계속 고치지 말고 /clear 뒤에 더 구체적인 첫 문장으로 다시 시작하라고 문서가 적습니다. 실패한 접근이 문맥에 쌓이면 성능이 떨어진다고 설명합니다. 오늘은 그 규칙을 노트에만 적고, 실험이 두 번 막히면 세션을 비우십시오.
하지 않을 일
영상 속 70퍼센트에서 80퍼센트 발언을 팀 KPI처럼 옮기지 않습니다. 관리형 Code Review 평균 비용을 추측해 적지 않습니다. 루틴 생성 절차를 오늘 다시 길게 쓰지 않습니다. YouTube iframe을 넣지 않습니다. 문서에 없는 요금제 가격을 만들지 않습니다. 운영 저장소에서 자동 모드로 배포 명령을 열지 않습니다.
한 줄로 정리합니다
Claude Code 팀이 영상에서 보여 주는 습관은 단순합니다. 도구 호출을 감시하는 자리에서 내려와, 목표와 검증 신호를 남기는 자리로 올라갑니다. 문서는 그 신호를 테스트와 스크린샷과 /code-review로 구체화합니다. 오늘은 그 최소 실험 한 바퀴만 돌리면 충분합니다. 영상은 여기입니다. 문서는 여기부터 읽으십시오.