속도에서 전략으로

초급 팁 열 가지를 익힌 뒤, 클로드 코드를 쓰는 패턴이 바뀌기 시작합니다. /init은 반사적으로 실행하고, 컨텍스트를 의식하며, 계획 모드로 먼저 설계하는 습관이 붙습니다. 그런데 어느 순간 벽에 부딪힙니다. 혼자 하나의 세션에서 하나의 작업을 처리하는 방식으로는 속도에 한계가 있습니다.

중급 팁은 이 한계를 넘기 위한 전략입니다. 여러 에이전트를 동시에 움직이고, 반복 작업을 자동화하고, 비용을 최적화하는 방법을 다룹니다.

팁 11. 보조 에이전트(Subagent) 병렬 작업 위임

한 사람이 조사, 코딩, 검증를 순서대로 하는 것과, 세 사람이 각각 하나씩 동시에 하는 것. 결과가 나오는 속도는 비교할 수 없습니다.

클로드 코드에서는 복잡한 작업을 줄 때 프롬프트 안에 "보조 에이전트를 활용해"라는 지시를 포함시킬 수 있습니다. 메인 세션이 작업을 분석한 뒤, 독립적인 보조 에이전트를 여러 개 생성합니다. 각 보조 에이전트는 자기만의 컨텍스트 창을 갖고, 자기만의 모델을 사용할 수 있습니다.

한 에이전트는 리서치를, 다른 에이전트는 검증 코드 작성을, 또 다른 에이전트는 대안적 접근법 탐색을 맡습니다. 이 모든 작업이 동시에 진행됩니다. 작업이 끝나면 각 보조 에이전트가 결과를 메인 에이전트에게 보고합니다. 메인 스레드(thread)는 깔끔하게 유지되면서, 실질적으로는 개발팀 여러 명이 붙은 것과 같은 효과를 얻습니다.

[그림 28-1] 메인 에이전트가 보조 에이전트에게 작업을 위임하는 흐름도

팁 12. 커스텀 스킬 파일 만들기

같은 종류의 작업을 반복할 때마다 프롬프트를 다시 작성하고 있다면, 커스텀 스킬(custom skill) 파일이 필요합니다.

.claude/skills/ 디렉터리 안에 마크다운 파일을 만들어 둡니다. 예를 들어 techdebt.md라는 파일에 기술 부채(technical debt)를 점검하는 절차를 상세히 기술해 놓으면, 이후에는 "기술 부채 점검해 줘"라고 말하는 것만으로 그 워크플로가 실행됩니다.

codereview.md에 코드 리뷰 기준을 정리해 두면, 매번 리뷰 기준을 설명할 필요 없이 일관된 품질의 리뷰가 나옵니다.

스킬 파일의 진짜 힘은 팀 공유에 있습니다. 이 파일들을 깃허브(GitHub)에 커밋하면 팀 전체가 동일한 워크플로를 사용할 수 있습니다. 사람마다 다르게 진행되던 코드 리뷰나 배포 전 점검이, 스킬 파일 하나로 표준화됩니다. 회사의 SOP(Standard Operating Procedure)를 자동화하는 것과 다르지 않습니다.

팁 13. 하이쿠(Haiku) 모델로 보조 에이전트 비용 절감

보조 에이전트를 적극적으로 활용하기 시작하면 비용이 신경 쓰입니다. 여기서 한 가지 전략이 있습니다.

보조 에이전트에게 맡기는 작업이 대량의 텍스트를 읽고 핵심만 추출하는 것이라면, 오퍼스(Opus)급 모델을 쓸 이유가 없습니다. 하이쿠처럼 가볍고 저렴한 모델을 지정하면 됩니다.

구체적인 예를 들어 보겠습니다. 수십 개의 기사를 읽고 요약해 와야 하는 리서치 작업이 있습니다. 수십만 모델이 세는 글 조각을 처리해야 합니다. 이 작업을 오퍼스로 돌리면 비용이 상당합니다. 하지만 보조 에이전트를 하이쿠로 설정하면 비용이 극적으로 줄어듭니다. 보조 에이전트가 읽고 추려낸 핵심 요약만 메인 에이전트(오퍼스)에게 전달되므로, 품질이 중요한 최종 분석 단계에는 여전히 강력한 모델이 투입됩니다.

비용이 부담된다고 보조 에이전트 활용 자체를 포기하는 것은 아깝습니다. 모델 선택을 전략적으로 하면 비용을 통제하면서도 병렬 작업의 이점을 누릴 수 있습니다.

팁 14. claude.md 지속 갱신

claude.md 파일은 살아 있는 문서입니다. 프로젝트가 진행되면서 새로운 패턴이 발견되고, 예상치 못한 함정이 드러나고, 규칙이 추가됩니다. 이런 발견이 있을 때마다 claude.md에 반영해야 합니다.

클로드에게 직접 지시할 수 있습니다. "방금 발견한 패턴을 claude.md에 기록해 줘." 다음 세션에서 클로드는 이미 그 교훈을 알고 있게 됩니다. 같은 실수를 반복하지 않고, 프로젝트에 대한 이해가 점점 깊어집니다.

하지만 주의할 점이 있습니다. claude.md는 시스템 프롬프트(system prompt)처럼 작동합니다. 이 파일의 내용이 매 대화에 로드되며, 그 분량만큼 컨텍스트 창을 차지합니다. 그래서 이 파일은 150에서 200줄 이내로 유지하는 것이 좋습니다. 정보를 계속 추가만 하면 파일이 비대해지고, 정작 대화에 쓸 컨텍스트가 부족해집니다.

새 정보를 추가할 때는 오래되거나 덜 중요한 정보를 동시에 정리하십시오. 이 균형이 claude.md의 품질을 결정합니다.

[그림 28-2] claude.md 파일의 적정 분량과 구조 예시

팁 15. claude.md에서 외부 파일로 라우팅

claude.md를 150에서 200줄로 유지하라고 했지만, 프로젝트에 필요한 정보는 그보다 훨씬 많을 수 있습니다. 스타일 가이드, 비즈니스 맥락, 참조 문서, API 명세 등. 이 모든 것을 claude.md 안에 넣으면 파일이 금방 터집니다.

해결책은 라우팅(routing)입니다. claude.md에는 각 정보가 어디에 있는지만 적어 둡니다. "스타일 가이드는 /docs/style-guide.md 참조", "API 명세는 /docs/api-spec.md 참조"처럼요. 클로드는 필요할 때 해당 파일을 찾아가서 읽습니다.

이 방식의 장점은 분명합니다. claude.md가 가벼워지므로 컨텍스트 낭비가 줄어듭니다. 동시에 클로드가 접근할 수 있는 정보의 총량은 오히려 늘어납니다. 시스템 프롬프트에 모든 프로젝트 상태를 적을 필요는 없습니다. 그 상태가 기록된 파일의 위치만 알려 주면 충분합니다.

팁 16. 잘못된 방향 즉시 탈출 (Escape)

클로드가 응답을 생성하는 도중, 방향이 틀렸다는 것이 눈에 보일 때가 있습니다. 요청하지 않은 라이브러리를 설치하려 하거나, 전혀 다른 접근법으로 코드를 작성하기 시작할 때입니다.

이때 끝까지 기다리지 마십시오. Escape 키를 누르면 생성이 즉시 멈춥니다.

잘못된 방향으로 갈수록 소비되는 모델이 세는 글 조각은 낭비입니다. 이미 쓴 모델이 세는 글 조각은 되돌릴 수 없고, 잘못된 맥락이 컨텍스트에 쌓이면 이후 응답에도 영향을 줍니다. 빨리 끊고 방향을 수정해서 다시 프롬프트를 보내는 것이 전체적으로 훨씬 경제적입니다.

"어쩌면 마지막에 바로잡을지도 몰라"라는 기대로 기다리는 것은 대부분 시간과 모델이 세는 글 조각의 이중 손실로 끝납니다. 조타는 빠를수록 좋습니다.

팁 17. 출력물에 공격적 수정 의견

클로드가 내놓은 결과물이 "그럭저럭" 수준이라면, 그냥 받아들이지 마십시오.

"이건 충분하지 않아. 완전히 다른 접근으로 다시 해 봐." "이 부분은 너무 장황해. 더 간결하고 우아한 방식으로 바꿔 줘." 이렇게 높은 기준을 명시적으로 요구하면, 클로드는 놀라울 정도로 다른 결과물을 내놓는 경우가 많습니다.

두 번째 시도에서 더 나은 결과가 나오는 이유는 분명합니다. 첫 번째 결과물에 대한 수정 의견이 "하지 말아야 할 것"을 명확히 해 주기 때문입니다. 클로드는 이제 어떤 방향이 아닌지를 알고, 다른 경로를 탐색합니다.

여기서 한 단계 더 나아갈 수 있습니다. 개선된 결과물이 나오면, 그 개선 포인트를 claude.md나 스킬 파일에 기록하도록 지시하십시오. "이 실수를 다시 반복하지 않도록 업데이트해 줘." 같은 종류의 실수가 반복되는 것을 구조적으로 차단할 수 있습니다.

팁 18. /rewind로 빠르게 되돌리기

Escape로 생성을 중단하는 것은 아직 진행 중인 응답을 멈추는 것입니다. 하지만 이미 완료된 응답이 문제였다면? 이미 클로드가 파일을 수정하고 대화가 진행된 뒤에 "아, 세 단계 전이 더 나았는데"라고 깨달았다면?

/rewind 명령어가 이 상황을 해결합니다. 대화의 이전 지점으로 되돌아갈 수 있습니다. 세션을 처음부터 다시 시작할 필요가 없습니다. 잘못 틀어진 지점까지만 되감고, 거기서 다른 방향으로 진행하면 됩니다.

/rewind는 Escape와 함께 사용하면 강력한 조합이 됩니다. 진행 중인 잘못은 Escape로 멈추고, 이미 지나간 잘못은 /rewind로 되돌립니다. 이 두 가지 수단이 있으면 클로드 코드 세션에서 돌이킬 수 없는 실수란 사실상 없습니다.

팁 19. 훅(Hooks) 알림 설정

클로드 코드 세션 여러 개를 동시에 돌리기 시작하면 새로운 문제가 생깁니다. 어느 세션이 끝났는지, 어느 세션이 내 입력을 기다리고 있는지 파악하기 어려워집니다.

/hooks 명령어를 사용하면 알림 훅을 설정할 수 있습니다. 자연어로 지시할 수도 있습니다. "이 세션이 끝나면 알림 소리를 울려 줘." 클로드 코드가 작업을 완료했을 때 시스템 알림이 울리도록 설정하는 것입니다.

이렇게 해 두면 작업이 끝날 때까지 터미널을 쳐다보고 있을 필요가 없습니다. 다른 작업을 하다가 알림이 울리면 돌아가서 결과를 확인하고, 다음 지시를 내리면 됩니다.

15개의 세션을 동시에 돌리고 있다고 상상해 보십시오. 알림 없이는 어느 것이 끝났는지 확인하려고 터미널을 하나하나 전환해 봐야 합니다. 알림이 있으면 "딩" 소리가 나는 곳에만 가면 됩니다. 사소해 보이지만, 다중 세션 운영에서는 필수적인 설정입니다.

[그림 28-3] 훅 설정 후 알림이 동작하는 화면 예시

팁 20. 스크린샷 활용 시각적 자가 점검

클로드는 볼 수 있습니다. 텍스트만 처리하는 것이 아니라, 이미지를 분석할 수 있다는 의미입니다.

이 능력을 가장 효과적으로 활용하는 방법은 시각적 자가 점검 루프(self-check loop)를 만드는 것입니다. 웹사이트를 만드는 작업이라면, 이런 흐름을 구성합니다.

1. 웹사이트 디자인 구현
2. 스크린샷 촬영
3. 스크린샷을 분석하여 레이아웃 문제 식별
4. 문제 수정
5. 다시 스크린샷 촬영 및 분석

이 루프를 세 번 정도 반복한 뒤에 첫 번째 버전(V1)을 보여주도록 설정하면, 자가 점검 없이 바로 나온 V1과는 완성도 차이가 확연합니다.

스크린샷 활용은 웹 디자인에만 국한되지 않습니다. 에러 메시지 화면을 찍어서 보여줄 수도 있고, 참고하고 싶은 다른 사이트의 디자인을 찍어서 영감의 소스로 제공할 수도 있습니다. 텍스트로 설명하기 어려운 시각적 정보를 전달하는 데 스크린샷은 가장 효율적인 수단입니다.

[그림 28-4] 스크린샷 기반 자가 점검 루프 다이어그램

기본기 위에 전략을 얹다

중급 팁 열 가지를 살펴보았습니다. 이 팁들의 공통점은 "혼자서 하나씩"이라는 한계를 넘는 전략이라는 것입니다. 보조 에이전트로 병렬화하고, 스킬 파일로 자동화하고, 모델 선택으로 비용을 최적화하고, 훅으로 여러 세션을 관리하고, 수정 의견과 되감기로 품질을 끌어올립니다.

이 전략들이 손에 익으면, 한 걸음 더 나아갈 준비가 됩니다. 브라우저를 자동화하고, MCP 연결 서버를 연결하고, 에이전트가 스스로 에이전트를 만들게 하는 고급 기법들이 그 다음 단계에 있습니다.