Claude Code 23가지 기능을 하루 개발 루틴으로 묶는 법 2026 – 딥 리서치부터 코드 리뷰까지

Posted on by

Claude Code는 2026년 기준 터미널, 웹, IDE, GitHub 흐름까지 이어지는 AI 코딩 에이전트다. 기능을 많이 아는 것보다 중요한 건 리서치, 계획, 실행, 검증, 팀 공유를 하나의 개발 루틴으로 묶는 것이다.

Claude Code 팁 영상을 보면 마음이 빨라진다. Deep Research, Ultra Code, Batch, Background, Ultra Plan, Goal, Skill Creator, Code Review 같은 기능이 줄줄이 나오면 “이거 다 쓰면 개발 속도가 몇 배는 빨라지겠는데?” 싶다.

문제는 기능을 많이 아는 순간부터 오히려 손이 꼬일 수 있다는 점이다. 리팩토링 하나 하려다가 리서치도 켜고, 배치도 켜고, 백그라운드도 켜고, 스킬도 만들고, 코드 리뷰까지 돌리면 갑자기 개발이 아니라 Claude Code 기능 시식 코너가 된다. 맛은 있는데 배가 산만하다.

그래서 이 글은 코드팩토리의 Claude Code 23가지 기능 요약을 기능 목록으로 다시 풀지 않는다. 실제 개발자가 하루 작업에서 어떻게 묶어 쓰면 좋은지, 리서치 -> 계획 -> 병렬 실행 -> 검증 -> 팀 온보딩 루틴으로 재정리한다.

먼저 기억할 한 줄

Claude Code 생산성은 “더 강한 기능을 켜는 것”보다 “작업 단계에 맞는 기능만 켜는 것”에서 나온다.

작은 버그 수정에는 Deep Research와 Ultra Code가 필요 없을 수 있다. 반대로 결제 로직 마이그레이션, 프레임워크 교체, 다중 저장소 리팩토링 같은 작업에는 일반 프롬프트 한 줄이 너무 가볍다.

즉 기능을 외우는 방식보다 작업을 분류하는 방식이 먼저다. 오늘 작업이 조사인지, 설계인지, 반복 수정인지, 품질 검증인지, 팀 공유인지부터 나눠야 한다.

먼저 볼 상황

이 글은 Claude Code를 처음 설치하는 입문서라기보다, 이미 몇 번 써봤는데 작업 흐름이 아직 들쑥날쑥한 사람에게 맞다. 프롬프트는 열심히 쓰는데 결과가 매번 다르고, 긴 작업을 맡기면 중간에 방향이 흔들리고, 마지막 리뷰에서 놓친 부분이 튀어나오는 경우다.

또 팀에서 Claude Code를 쓰기 시작했는데 사람마다 쓰는 방식이 달라지는 상황에도 맞다. 한 사람은 Deep Research부터 하고, 다른 사람은 바로 수정하고, 또 다른 사람은 Batch를 먼저 돌리면 나중에 리뷰 기준이 흔들린다. 기능보다 루틴을 먼저 맞춰야 팀 생산성이 올라간다.

1단계: 딥 리서치로 바로 코딩하지 않기

코드팩토리 요약에서 첫 기능으로 나온 Deep Research는 단계별 소스 수집과 검증을 통해 정확한 리서치를 수행하는 흐름이다. 개발에서 이 기능이 중요한 이유는 단순하다. AI 코딩 실패의 상당수는 구현력이 부족해서가 아니라 문제 이해가 얕아서 생긴다.

예를 들어 OAuth 오류를 고친다고 해보자. 바로 파일을 열고 고치게 하면 Claude는 현재 보이는 코드 안에서 답을 찾으려 한다. 하지만 실제 원인은 라이브러리 버전, 리다이렉트 URI, 배포 환경 변수, 공급자 정책 변경일 수 있다.

이때 첫 프롬프트는 “고쳐줘”가 아니라 리서치 요청이어야 한다.

이 버그를 바로 수정하지 말고 먼저 조사해줘.
1. 관련 코드 경로를 찾고
2. 관련 문서나 changelog에서 확인할 부분을 정리하고
3. 가능한 원인을 우선순위로 나누고
4. 수정 전에 내가 승인할 계획을 제안해줘.

이렇게 시작하면 Claude Code는 코딩 도구가 아니라 조사자 역할을 먼저 한다. 병렬 실행, 계획, 자동화, 검증, 커스터마이징은 각각 다른 작업 패턴이다. 한 번에 다 하는 에이전트가 아니라 단계별로 역할을 바꾸는 도구로 보는 편이 맞다.

2단계: Ultra Plan과 Goal로 작업의 끝을 먼저 정하기

복잡한 작업은 계획 없이 시작하면 거의 반드시 길어진다. 코드팩토리 요약의 Ultra Plan은 복잡한 작업에서 웹 환경으로 더 정밀한 계획을 만드는 용도로 소개된다. 여기에 Goal 프롬프트를 붙이면 작업 성공 조건이 선명해진다.

Goal은 “무엇을 만들 것인가”보다 “어디까지 되면 끝인가”를 적는 장치로 보는 게 좋다. 예를 들어 “로그인 리팩토링 해줘”는 너무 흐리다. “기존 로그인 테스트가 모두 통과하고, 소셜 로그인 콜백 중복 코드를 제거하고, 신규 토큰 갱신 실패 케이스 테스트를 추가하면 완료”처럼 써야 한다.

내가 운영한다면 Goal 프롬프트는 아래처럼 둘 것이다.

목표:
- 기존 동작을 깨지 않고 인증 모듈 중복 코드를 줄인다.
- 완료 기준은 npm test, npm run lint 통과다.
- 변경 전 계획을 먼저 제시하고 승인 후 수정한다.
- 보안 관련 판단은 추측하지 말고 근거를 표시한다.
- 마지막에 변경 파일, 남은 리스크, 후속 테스트를 표로 정리한다.

이런 문장이 있으면 Claude Code가 중간에 멋진 우회로로 빠질 확률이 줄어든다. AI 에이전트에게도 작업표가 필요하다. 사람도 티켓 없이 일하면 갑자기 대청소를 시작한다. AI도 비슷하다.

3단계: Ultra Code는 어려운 작업에만 켜기

Ultra Code는 고강도 추론과 에이전트 협업을 통해 복잡한 코드 마이그레이션이나 리팩토링을 처리하는 용도로 소개된다. Claude Code에는 effort 조정과 ultracode 같은 고강도 작업 옵션이 있다. 다만 더 강한 추론은 대체로 더 많은 비용과 시간을 쓴다.

그래서 Ultra Code는 기본값이 아니라 특수 장비로 봐야 한다. 타입스크립트 에러 3개 고치는 일에 매번 대형 장비를 부르면 현장이 아니라 쇼룸이 된다.

Ultra Code를 켤 만한 작업은 이런 쪽이다.

작업 Ultra Code 적합도 이유
프레임워크 마이그레이션 높음 여러 파일과 설계 판단이 얽힘
인증/결제/권한 리팩토링 높음 실패 비용이 크고 검증이 중요
단순 UI 텍스트 수정 낮음 일반 모드가 빠르고 충분
테스트 누락 보강 중간 범위가 넓으면 유용
레거시 구조 분석 높음 코드 이해와 계획이 먼저 필요

핵심은 비용 대비 리스크다. 실패 비용이 큰 작업에는 강한 추론이 값어치를 한다. 실패해도 바로 되돌릴 수 있는 작은 작업에는 과하다.

4단계: Batch는 반복 작업을 쪼갤 때 쓴다

코드팩토리 요약의 Batch는 다수 반복 작업을 병렬로 처리해 효율을 높이는 기능이다. 큰 마이그레이션을 먼저 인터뷰하듯 쪼갠 뒤 여러 worktree 에이전트로 나눠 처리하는 흐름에 잘 맞는다.

이 기능은 “한꺼번에 많이 해줘”가 아니라 “독립 가능한 단위로 나눠줘”에 가깝다. 예를 들어 컴포넌트 80개에서 같은 prop 이름을 바꾸는 작업, 테스트 파일에 같은 패턴을 추가하는 작업, 폴더별 API 클라이언트 마이그레이션 같은 일에 잘 맞는다.

반대로 파일들이 서로 강하게 얽혀 있으면 Batch가 오히려 충돌을 만든다. 병렬화는 마법이 아니다. 독립성이 있어야 병렬이 된다.

내 기준의 Batch 전 체크는 네 가지다.

질문 통과 기준
파일 단위로 나눌 수 있나 폴더/모듈별 담당이 분리됨
각 작업자가 테스트할 수 있나 로컬 테스트 명령이 명확함
충돌이 생겨도 병합 가능하나 shared 파일 수정이 적음
결과를 사람이 검토할 수 있나 PR 또는 diff 단위가 작음

이 표가 비어 있으면 Batch보다 Plan이 먼저다.

5단계: Background와 BTW/Fork로 흐름을 끊지 않기

Background는 Claude 작업을 유지하면서 터미널을 자유롭게 쓰는 흐름으로 소개된다. 웹 세션과 로컬 세션을 함께 쓰는 경우에는 & 명령으로 세션을 백그라운드 처리하거나, --teleport로 로컬과 웹 사이 컨텍스트를 옮기는 패턴도 활용할 수 있다.

이 기능은 은근 중요하다. AI 코딩에서 생산성이 끊기는 순간은 Claude가 느릴 때가 아니라, Claude가 일하는 동안 내가 아무것도 못 하고 기다릴 때다. 긴 테스트나 리서치가 도는 동안 사람은 로그를 보거나, 다른 작은 이슈를 정리하거나, PR 설명을 다듬을 수 있어야 한다.

BTW와 Fork도 비슷한 맥락이다. 기존 세션을 망치지 않고 옆길 질문을 던질 수 있어야 한다. /btw는 프롬프트 흐름을 분기하는 패턴으로 볼 수 있고, 세션 분기는 /branch 또는 --fork-session 같은 방식으로 처리할 수 있다.

실전에서는 이런 식이다.

메인 세션: 인증 리팩토링 진행
BTW 질문: 이 라이브러리 버전 변경 이슈만 따로 조사
Fork 세션: 같은 문제를 다른 접근으로 해결 가능한지 비교
Background: 긴 테스트 실행 중 사람은 PR 설명 작성

중요한 건 메인 작업의 맥락을 오염시키지 않는 것이다. 옆길 질문 하나 때문에 Claude가 갑자기 전체 계획을 바꾸면, 생산성은 좋아진 게 아니라 대화가 샜다.

6단계: Skill Creator는 반복될 때만 만든다

Skill Creator는 나만의 자동화 스킬을 만들고 리소스 절약을 측정하는 기능으로 요약됐다. 이건 꽤 매력적이다. 반복되는 작업을 스킬로 만들면 매번 긴 프롬프트를 쓰지 않아도 된다.

하지만 스킬은 한 번 쓴 프롬프트를 저장하는 기능이 아니다. 반복 가능하고 검증 가능한 작업을 포장하는 방식이다. 예를 들어 “PR 리뷰 전 체크”, “마이그레이션 계획서 작성”, “블로그 초안 품질 검사”, “테스트 실패 원인 분류”처럼 자주 반복되는 흐름에 맞다.

스킬로 만들기 전에는 세 번만 수동으로 해보는 편이 좋다. 세 번 반복해도 입력, 처리, 출력 형식이 비슷하면 스킬 후보가 된다. 매번 조건이 달라지면 아직 스킬로 만들 때가 아니다.

스킬 후보 메모는 이렇게 남기면 된다.

스킬 이름: code-review-preflight
입력: 변경 diff, 테스트 결과, 작업 목표
출력: 위험도, 필수 수정, 선택 수정, 추가 테스트
검증: npm test/lint 결과와 사람이 확인한 리뷰 코멘트
사용 빈도: 주 3회 이상이면 유지

스킬은 많을수록 좋은 게 아니다. 안 쓰는 스킬은 오래된 자동완성 문구처럼 된다. 누르면 뭔가 나오는데, 묘하게 지금 일이랑 안 맞다.

7단계: 코드 리뷰는 마지막 장식이 아니라 별도 단계다

코드팩토리 요약의 Code Review는 작업 마무리 단계에서 최적화된 코드 리뷰 리포트를 만드는 기능이다. 이 흐름은 GitHub PR을 분석해 논리 오류, 보안 취약점, 엣지 케이스, 회귀 가능성을 찾고 인라인 댓글로 남기는 데 특히 잘 맞는다.

여기서 중요한 점은 코드 리뷰가 “예쁘게 정리해줘”가 아니라는 것이다. 기본 초점은 형식 취향보다 실제 버그와 정확성이다. 좋은 리뷰 흐름은 여러 에이전트가 diff와 주변 코드를 병렬 분석하고, 검증 단계로 거짓 양성을 줄이는 식으로 설계된다.

개인 개발자도 비슷한 리뷰 루틴을 만들 수 있다.

리뷰 기준:
- 요구사항을 충족했는가
- 기존 동작을 깨뜨릴 가능성은 없는가
- 테스트가 바뀐 위험을 충분히 덮는가
- 보안/권한/데이터 손실 리스크는 없는가
- 문서나 CLAUDE.md 업데이트가 필요한가

이 리뷰는 개발 완료 후 한 번만 돌리는 것보다, 큰 작업에서는 중간에도 돌리는 편이 좋다. 특히 Batch나 Ultra Code를 쓴 작업은 사람이 다 기억하지 못하는 변경이 생긴다. 마지막 검수 없이 바로 병합하면 속도는 빨라졌는데 사고도 빨라진다.

8단계: /copy와 팀 온보딩은 작지만 오래 간다

슬래시 카피(/copy)는 이전 프롬프트를 드래그 없이 복사하는 작은 기능으로 요약됐다. 사소해 보이지만 반복 작업에서는 이런 기능이 은근히 크다. 좋은 프롬프트를 다시 쓰는 건 생산성이고, 매번 새로 쓰는 건 손목 운동이다.

팀 온보딩도 마찬가지다. 세션 기록을 기반으로 팀원 가이드를 자동 생성하면, “이 프로젝트는 어떻게 일하나요?”라는 질문을 줄일 수 있다. CLAUDE.md를 프로젝트 메모리처럼 두고, 빌드 명령어, 테스트 명령어, 아키텍처, 규칙을 담아두면 사람과 AI가 같은 작업 기준을 공유하기 쉬워진다.

내가 팀에 적용한다면 온보딩 산출물은 세 개로 나눌 것이다.

파일 목적
CLAUDE.md AI와 팀원이 읽는 프로젝트 작업 규칙
REVIEW.md 코드 리뷰에서 꼭 볼 기준
ONBOARDING.md 새 팀원이 1시간 안에 이해할 흐름

Claude Code 세션을 많이 썼다면 거기에는 이미 프로젝트의 암묵지가 남아 있다. 그걸 그냥 흘려보내지 말고 팀 문서로 바꾸는 게 좋다. 생산성은 작업을 빨리 끝내는 데서만 나오지 않는다. 다음 사람이 덜 헤매는 데서도 나온다.

23가지 기능을 루틴으로 묶은 운영표

기능을 전부 외우기보다 아래처럼 묶어두면 쓰기 쉽다.

단계 쓸 기능 목적 주의점
조사 Deep Research 소스 수집, 원인 후보 정리 바로 수정 금지
계획 Ultra Plan, Goal 작업 범위와 완료 기준 확정 승인 전 수정 금지
고난도 실행 Ultra Code 복잡한 마이그레이션, 리팩토링 비용과 과추론 확인
병렬 처리 Batch, worktree 반복 작업 분산 충돌 가능성 체크
흐름 유지 Background, BTW, Fork 긴 작업과 옆길 질문 분리 메인 맥락 오염 방지
재사용 Skill Creator, /copy 반복 프롬프트와 절차 저장 3회 이상 반복 후 스킬화
검증 Code Review, 테스트, lint 버그, 보안, 회귀 확인 리뷰 비용과 트리거 관리
팀화 CLAUDE.md, REVIEW.md, 온보딩 문서 팀 규칙과 세션 지식 공유 문서가 오래되지 않게 갱신

이 표의 핵심은 “강한 기능을 언제 켤 것인가”다. Claude Code는 똑똑하지만, 모든 작업에 최대 출력을 쓰는 건 좋은 운영이 아니다.

안 써도 되는 경우

Claude Code 기능은 많지만, 모든 기능을 매일 켤 필요는 없다. 생산성 도구에서 제일 위험한 착각은 “기능을 안 쓰면 손해”라는 생각이다. 실제로는 기능을 덜 쓰는 쪽이 더 빠른 날도 많다.

상황 굳이 안 써도 되는 기능 이유
텍스트 수정, 작은 UI 문구 변경 Ultra Code, Batch 일반 세션이 더 빠름
원인이 명확한 단일 버그 Deep Research 조사 비용이 더 큼
파일 1~2개만 고치는 작업 worktree 병렬 실행 격리 비용이 과함
한 번만 할 작업 Skill Creator 스킬 유지비가 더 큼
개인 토이 프로젝트의 작은 PR 자동 Code Review 전체 트리거 비용 대비 효과가 낮을 수 있음

이 표는 Claude Code를 덜 쓰라는 뜻이 아니다. 기능을 작업 크기에 맞게 쓰자는 뜻이다. 망치가 좋다고 모든 물건을 못으로 보면, 책상도 언젠가 울기 시작한다.

처음 쓰는 사람의 1일 루틴

처음부터 23개 기능을 다 쓰려고 하지 말자. 첫날은 다섯 단계면 충분하다.

오전에는 Deep Research로 오늘 고칠 문제를 조사한다. 바로 코딩하지 않고, 원인 후보와 관련 파일, 확인해야 할 문서를 정리하게 한다.

그다음 Goal 프롬프트를 쓴다. 완료 기준, 테스트 명령, 수정 금지 범위, 리뷰 기준을 명시한다.

실행은 일반 모드로 시작한다. 작업이 커지거나 설계 판단이 많아지면 그때 Ultra Code나 Ultra Plan을 올린다.

반복 작업이 보이면 Batch 후보로 표시만 한다. 첫날부터 병렬로 뿌리기보다 “이 작업이 독립 가능한가”를 먼저 확인한다.

마지막에는 Code Review 또는 리뷰 프롬프트를 돌린다. 변경 파일, 테스트 결과, 남은 리스크, 다음 액션을 표로 남긴다. 이 표가 다음 날의 컨텍스트가 된다.

FAQ

Claude Code 23가지 기능을 다 익혀야 하나?

아니다. 먼저 Deep Research, Goal, Background, Code Review, CLAUDE.md 정도만 익혀도 체감이 크다. Batch, Ultra Code, Skill Creator는 반복 작업과 대형 리팩토링이 생길 때 붙이면 된다.

Ultra Code는 항상 좋은가?

항상 좋지는 않다. 복잡한 작업에서는 강하지만, 작은 수정에는 비용과 시간이 과할 수 있다. effort level은 속도, 비용, 추론 깊이의 trade-off로 봐야 한다.

Batch는 언제 위험한가?

공유 파일을 여러 작업자가 동시에 수정하거나, 테스트 기준이 불명확하거나, 모듈 경계가 흐릴 때 위험하다. Batch를 쓰기 전에 worktree, 테스트 명령, 병합 전략이 있어야 한다.

팀에서 바로 코드 리뷰 자동화를 켜도 되나?

트래픽이 많은 저장소라면 수동 트리거부터 시작하는 편이 낫다. 모든 푸시 리뷰는 비용이 커질 수 있고, PR 크기와 복잡도에 따라 리뷰 비용이 증가한다.

마무리

Claude Code의 23가지 기능은 따로 보면 기능 모음이지만, 묶어 보면 하나의 개발 운영 루틴이 된다. 조사할 때는 Deep Research, 설계할 때는 Ultra Plan과 Goal, 반복 수정에는 Batch, 긴 작업에는 Background, 분기 질문에는 BTW/Fork, 반복 절차에는 Skill Creator, 마지막 검증에는 Code Review를 쓰는 식이다.

중요한 건 기능 수가 아니라 흐름이다. 기능을 많이 켜는 개발자가 아니라, 지금 작업에 맞는 기능만 켜는 개발자가 더 오래 빠르다.

첫날 목표는 단순하게 잡자. 오늘 작업 하나에 Deep Research로 시작하고, Goal로 끝을 정하고, 마지막에 Code Review로 닫는다. 이 세 개만 제대로 써도 Claude Code는 그냥 코딩 챗봇이 아니라 개발 루틴의 한 축이 된다.

관련 글

공식 출처