Claude Code 팀이 일하는 6가지 방법, 프롬프트와 함께

프롬프트 쓰는 법

각 장의 프롬프트를 복사하거나 화면을 캡처해 Claude나 Claude Code에 붙여넣으세요. ○○ 자리만 내 상황으로 바꾸면 됩니다.

프롬프트마다 끝났다는 기준과 보고 형식이 들어 있습니다. 머지, 배포, 삭제, 외부 발송은 하지 않도록 적었습니다. 그런 단계는 결과를 직접 확인한 뒤 진행하세요.

목표 하나를 던지고, 결과 하나를 받습니다

무엇

Claude Code 팀 엔지니어는 일의 70~80%를 슬랙에서 시킨다고 말합니다. 예전에는 에이전트가 어떤 도구를 부르고 어떤 값을 넘기는지 한 줄씩 지켜봤습니다. 지금은 목표 1개를 던지면 스레드에 결과 1개가 돌아오고, 과정은 전사 보기 링크 하나로 접혀 있습니다.

왜

과정을 지켜보는 대신 결과만 확인하면 사람이 붙어 있을 시간이 줄어듭니다. 대신 무엇을 원하는지와 언제 끝난 것인지를 처음에 분명히 적어야 결과 하나로 판단할 수 있습니다.

어떻게

다음 작업 하나를 세 줄로 시켜 보세요. 목표, 끝났다는 기준, 보고 형식입니다. 보고는 첫 줄에 결론, 그 아래에 증거 경로를 받습니다.

다음 작업을 해 줘.
목표: ○○ (예: 이 폴더의 README를 처음 보는 사람 기준으로 다시 쓰기)
끝났다는 기준: ○○ (예: README의 설치 명령을 새 터미널에서 그대로 실행해 성공)
보고 형식: 첫 줄에 결론 한 문장, 그 아래에 실행한 명령과 결과 파일 경로.

슬랙에서 쓰는 Claude Tag는 2026년 6월에 나온 베타로, Team·Enterprise 플랜 전용입니다. Pro·Max 같은 개인 플랜이라면 Claude Code 세션에 같은 세 줄을 그대로 넣으면 됩니다.

프롬프트를 세션이 아니라 루프에 넣습니다

무엇

노트북을 닫으면 에이전트도 멈췄습니다. 그래서 팀은 세션을 클라우드 컨테이너로 옮겼고, 거기서 루틴이 나왔습니다. 예를 들어 매일 9시에 피드백을 중요도별로 나누고, 확신이 높은 것만 고칩니다.

왜

매일 손으로 하는 확인은 사람이 기억해야만 돌아갑니다. 프롬프트를 넣는 자리를 세션에서 세션 위의 루프로 한 단계 올리면, 사람이 없어도 같은 확인이 매일 돌아갑니다.

어떻게

매일 손으로 하는 확인 1개를 루틴으로 바꿔 보세요. 프롬프트에는 이 말을 꼭 넣습니다. 확신 높은 것만 고치고, 나머지는 목록으로 보고.

매일 하는 확인 하나를 대신 해 줘.
대상: ○○ (예: 이 저장소의 지난 24시간 새 이슈와 피드백)
할 일: 읽고 중요도 상·중·하로 나눠. 원인과 수정이 확실한 것만 새 브랜치에서 고치고, 나머지는 한 줄씩 목록으로 보고해.
끝났다는 기준: 분류 목록 + 고친 파일 경로. 머지·배포는 하지 마.
한 번 돌려 보고 괜찮으면 매일 9시 루틴(/schedule)으로 만들어 줘.

Claude Code의 루틴(/schedule)은 아직 리서치 프리뷰이고, Pro·Max 개인 플랜에서도 쓸 수 있습니다. 처음 한 번은 직접 돌려 결과를 확인한 뒤 루틴으로 만드세요.

사소한 지적은 고치고, 사람은 이유만 묻습니다

무엇

변수 이름, 줄바꿈, 오타 같은 사소한 지적은 이제 Claude가 직접 고칩니다. 사람에게 남는 건 “왜 이 경계에서 나눴나?” 같은 질문입니다.

왜

API 구조나 서비스 경계처럼 Claude가 모를 수 있는 이유는 사람이 물어야 드러납니다. 사소한 지적까지 사람이 읽게 하면 정작 그 질문이 묻힙니다.

어떻게

리뷰를 맡길 때 두 줄을 더하세요. 스타일과 오타는 직접 고치고 보고하지 말 것. 설계 의도와 경계 위반만 질문으로 남길 것.

이 브랜치에서 main 대비 바뀐 코드를 리뷰해 줘.
스타일·오타·이름 같은 사소한 것은 직접 고치고 나에게 보고하지 마.
설계 의도, API 구조, 모듈·서비스 경계를 어긴 곳만 '왜 이렇게 했나요?' 질문으로 최대 3개, 파일:줄과 함께 남겨 줘.
끝났다는 기준: 질문 목록 + 직접 고친 파일 목록. 푸시·머지는 하지 마.

위 프롬프트는 푸시와 머지를 하지 않게 적혀 있습니다. 고친 내용은 직접 확인한 뒤 올리세요.

10갈래로 찾고, 반대 근거로 거릅니다

무엇

프롬프트 1개가 에이전트 여러 개로 갈라져 각자 후보를 찾아옵니다. 후보마다 반박을 붙입니다. 재현되는지, 반대 근거는 없는지, 영향이 얼마나 큰지입니다. 대부분은 여기서 떨어지고, 남은 몇 개만 사람이 봅니다.

왜

찾는 일은 나눠서 동시에 할수록 빠르지만, 후보가 많아지면 사람이 다 읽을 수 없습니다. 반박 단계를 따로 두면 사람이 읽을 양이 남은 몇 개로 줄어듭니다.

어떻게

리서치 질문 하나를 10갈래로 찾고, 반대 근거로 검증하고, 상위 3개만 출처 링크와 함께 받아 보세요. 개발이 아니어도 구조는 같습니다. 원본의 타호 여행 예시라면 숙소, 온천, 에어비앤비, 맛집을 따로 찾고 검증해서 3곳만 남깁니다.

질문: ○○ (예: 1박 2일 타호 여행에서 묵을 숙소)
이 질문을 서로 다른 검색 10갈래로 나눠 서브에이전트로 동시에 조사해 줘.
후보마다 반대 근거를 찾는 검증을 따로 돌려 줘: 출처가 확인되는지, 반대 사례는 없는지.
끝났다는 기준: 살아남은 상위 3개만, 출처 링크와 탈락한 후보 수를 함께 보고. 출처 없는 주장은 빼 줘.

서브에이전트를 여러 개 띄우면 사용량도 그만큼 늘어납니다. 처음에는 갈래 수를 줄여 시험해 보세요.

“완료했습니다” 대신 볼 수 있는 증거를 받습니다

무엇

완료했다는 한 줄 대신, 볼 수 있는 증거로 보고받습니다. 스크린샷, 녹화, 그리고 HTML 보고서입니다. 다이어그램과 목업이 들어간 HTML은 질문을 받을 때도 씁니다.

왜

열어 볼 수 없는 “완료”는 확인할 방법이 없습니다. 증거를 붙이는 규칙을 한 번 정해 두면 매번 다시 물어볼 필요가 없습니다.

어떻게

CLAUDE.md에 한 줄을 넣으세요. 완료 보고에는 스크린샷이나 실행 결과 경로를 붙인다. 내가 열어 볼 수 없으면 완료가 아니다.

이 프로젝트의 CLAUDE.md에 아래 규칙을 추가해 줘. 비슷한 줄이 이미 있으면 그 줄을 고쳐 줘.
"완료 보고에는 스크린샷이나 실행 결과 파일 경로를 붙인다. 내가 열어 볼 수 없으면 완료로 보고하지 않는다."
끝났다는 기준: 바뀐 줄을 diff로 보여 주고, 지금 하던 작업 하나를 이 규칙대로 다시 보고해 줘.

CLAUDE.md는 Claude Code가 프로젝트를 열 때마다 읽는 지침 파일입니다.

모델이 바뀌면 규칙도 다시 묻습니다

무엇

투두 리스트는 모델의 약점을 메우던 부품이었고, 모델이 좋아지자 필요 없어졌습니다. CLAUDE.md도 같습니다. 실수가 나오면 규칙 한 줄이 생기고, 반복되면 테스트가 붙습니다.

왜

원본의 마지막 말처럼 소프트웨어 엔지니어링은 원래 변화의 직업이고, 지금은 그 주기가 2개월입니다. 예전 모델에 맞춰 쓴 규칙이 새 모델에서는 오히려 방해가 될 수 있습니다.

어떻게

모델 업데이트 날, CLAUDE.md 줄마다 물어보세요. 이 줄을 빼도 같은 결과가 나오나? 남길 줄은 반복된 실수에서 나온 줄뿐입니다.

모델이 업데이트됐어. 이 프로젝트의 CLAUDE.md를 줄마다 점검해 줘.
줄마다 '이 줄을 빼도 같은 결과가 나오나?'를 묻고 남길 줄 / 뺄 후보로 표를 만들어 줘.
남길 줄은 반복된 실수에서 나온 줄뿐이야. 근거(커밋, 이슈, 대화)를 함께 적어 줘.
끝났다는 기준: 표만 보여 주고 파일은 아직 고치지 마. 내가 확인한 뒤에 지울게.

위 프롬프트는 표만 만들고 파일은 고치지 않게 적혀 있습니다. 지울 줄은 직접 확인한 뒤 지우세요.

이번 주 체크리스트

• 다음 작업 하나를 목표, 끝났다는 기준, 보고 형식 세 줄로 시키기
• 매일 하는 확인 1개를 루틴으로 바꾸기
• 리뷰를 맡길 때 “사소한 건 고치고, 설계 질문만 남겨” 한 줄 더하기
• 리서치 질문 하나를 10갈래로 찾고 반박해서 3개만 받기
• CLAUDE.md에 “열어 볼 수 있는 증거로 보고” 한 줄 넣기
• 다음 모델 업데이트 날 CLAUDE.md 줄마다 “빼도 되나?” 묻기