처음 만나는 속도의 차이

터미널에 클로드 코드를 처음 열었던 날을 떠올려 보겠습니다. 커서가 깜빡이는 검은 화면 앞에서 무엇을 입력해야 할지 몰라 한참을 머뭇거렸던 그 순간. 프롬프트 한 줄을 치고, 결과물을 받아보고, 다시 고치고, 또 고치고. 몇 시간이 지나도 원하는 결과물은 나오지 않았습니다. 그런데 같은 도구를 쓰는 다른 사람은 놀라울 정도로 빠르게 결과물을 뽑아냅니다.

도구가 다른 것이 아닙니다. 몇 가지 습관이 다를 뿐입니다.

이 장에서 소개하는 열 가지 팁은 클로드 코드를 처음 접한 사람이 가장 먼저 익혀야 할 기본기입니다. 하나하나는 작은 습관이지만, 이것들이 쌓이면 작업 속도와 결과물의 품질이 눈에 띄게 달라집니다.

팁 1. /init으로 프로젝트 초기화하기

이미 파일이 들어 있는 프로젝트 폴더를 클로드 코드로 열었다고 해 보겠습니다. 가장 먼저 해야 할 일은 /init 명령어를 입력하는 것입니다.

이 명령어를 실행하면 클로드 코드가 프로젝트 전체를 훑습니다. 폴더 구조, 파일 목록, 코드 컨벤션을 파악한 뒤 claude.md 파일을 자동으로 생성합니다. 이 파일은 프로젝트의 치트시트(cheat sheet)와 같습니다. 아키텍처가 어떻게 구성되어 있는지, 핵심 파일은 무엇인지, 어떤 규칙을 따르는지가 정리되어 들어갑니다.

/init을 실행해 두면 매 세션마다 프로젝트를 다시 설명할 필요가 없습니다. 클로드가 이미 맥락을 파악하고 있기 때문입니다.

새 프로젝트를 처음부터 시작하는 경우에는 어떨까요? 그때는 프로젝트의 목표, 기술 스택(tech stack), 주요 규칙 등을 직접 설명해 주면서 claude.md 파일을 함께 만들면 됩니다. 이 파일이 잘 갖춰져 있을수록 이후의 모든 작업이 수월해집니다.

[그림 27-1] /init 실행 후 자동 생성된 claude.md 파일 예시

팁 2. 상태줄(Status Line) 설정하기

코딩에 몰두하다 보면 지금 얼마나 많은 컨텍스트(context)를 소비하고 있는지 잊기 쉽습니다. 한참 작업하다 문득 확인해 보니 컨텍스트 창이 거의 가득 차 있었던 경험, 한 번쯤 있을 것입니다.

터미널에서 /statusline을 입력하고 어떤 정보를 보고 싶은지 알려 주면, 클로드 코드가 터미널 하단에 작은 대시보드를 만들어 줍니다. 현재 사용 중인 모델명, 컨텍스트 사용 비율, 비용 등을 실시간으로 표시할 수 있습니다.

상태줄의 진짜 가치는 컨텍스트 소진을 미리 감지할 수 있다는 점에 있습니다. 컨텍스트가 얼마 남지 않았는데 모르고 계속 작업하면, 클로드의 응답 품질이 급격히 떨어집니다. 상태줄이 있으면 그런 상황이 오기 전에 대비할 수 있습니다. 작은 스크립트 하나가 세션 전체의 품질을 좌우하는 셈입니다.

팁 3. 음성 입력 /voice 활용하기

키보드로 긴 프롬프트를 타이핑하는 것은 생각보다 시간이 많이 걸립니다. 머릿속에는 구체적인 요구사항이 있는데, 그것을 글로 옮기는 과정에서 핵심이 빠지기도 합니다.

클로드 코드에는 /voice라는 네이티브 음성 입력 명령어가 탑재되어 있습니다. 터미널에 직접 말로 지시할 수 있습니다. "이 함수의 에러 처리를 개선해 줘"라고 입에서 나오는 대로 말하면, 그대로 프롬프트가 됩니다.

음성 입력의 장점은 속도만이 아닙니다. 말로 설명할 때는 자연스럽게 맥락과 의도가 함께 전달됩니다. 타이핑할 때 무의식적으로 줄이게 되는 설명이 음성에서는 풍부해집니다. 결과적으로 클로드가 의도를 더 정확하게 파악하게 됩니다.

별도의 음성 딕테이션(dictation) 앱을 활용하는 것도 좋은 방법입니다. 운영체제나 서드파티 앱을 통해 어디서든 음성으로 텍스트를 입력할 수 있으니, 클로드 코드뿐 아니라 다른 작업에서도 효율이 올라갑니다.

팁 4. 컨텍스트를 작게 유지하기

"많이 넣으면 많이 알겠지"라는 생각은 자연스럽지만, 클로드 코드에서는 오히려 독이 됩니다.

전체 코드베이스를 대화에 쏟아붓지 마십시오. 현재 작업에 필요한 정보만 제공해야 합니다. 큰 문제는 작은 단계로 쪼개고, 각 단계마다 해당 부분의 코드와 맥락만 전달합니다.

컨텍스트 창 안의 잡음(noise)이 줄어들수록 클로드의 성능은 올라갑니다. 이것은 사람도 마찬가지입니다. 회의실에서 열 가지 안건을 동시에 논의하면 어느 하나도 제대로 결론이 나지 않습니다. 한 번에 한 가지씩 집중해야 깊이 있는 결과가 나옵니다.

[그림 27-2] 컨텍스트를 작게 유지했을 때와 과도하게 채웠을 때의 응답 품질 비교

팁 5. /context로 모델이 세는 글 조각 소비 진단하기

컨텍스트를 작게 유지하라고 했는데, 대체 지금 무엇이 모델이 세는 글 조각(token)을 잡아먹고 있는지 어떻게 알 수 있을까요?

/context 명령어를 사용하면 됩니다. 이 명령어는 현재 세션에서 모델이 세는 글 조각이 어디에 얼마나 소비되고 있는지를 백분율로 보여 줍니다. 시스템 프롬프트가 차지하는 비중, 파일 내용이 차지하는 비중, MCP 연결 서버 정의가 차지하는 비중 등이 한눈에 드러납니다.

세션이 무겁게 느껴질 때, 응답이 느려지거나 품질이 떨어질 때, /context를 한번 실행해 보십시오. 의외의 곳에서 모델이 세는 글 조각이 대량으로 소모되고 있는 경우가 많습니다. 원인을 찾으면 구조를 재편해서 여유를 확보할 수 있습니다.

이 진단 습관은 팁 4의 "컨텍스트를 작게 유지하기"와 짝을 이룹니다. 원칙을 알더라도 현재 상태를 측정하지 못하면 실천이 어렵기 때문입니다.

팁 6. 60% 압축 규칙과 작업 간 초기화

컨텍스트 사용량이 60% 근처에 도달하면 /compact 명령어를 실행할 타이밍입니다.

이 명령어는 대화 히스토리를 압축합니다. 중요한 정보는 보존하면서 불필요한 부분을 걸러내는 방식입니다. 압축 후에도 작업을 이어갈 수 있으므로, 대화를 처음부터 다시 시작할 필요가 없습니다.

여기서 한 가지 유용한 기법이 있습니다. /compact을 실행할 때 보존할 내용을 명시적으로 지정할 수 있습니다. 예를 들어 "/compact, 하지만 API 연동 결정사항과 데이터베이스 스키마는 유지해 줘"라고 입력하면, 클로드가 나머지는 줄이면서 지정한 정보는 그대로 남겨 둡니다.

완전히 다른 작업으로 전환할 때는 /clear를 사용합니다. 대화 히스토리를 깨끗이 지우고 새 세션처럼 시작하는 것입니다. claude.md 파일과 프로젝트 파일은 그대로 남아 있으니, 맨땅에서 시작하는 것과는 다릅니다. 작업의 성격이 바뀔 때마다 /clear로 리셋하는 습관을 들이면, 이전 작업의 잔여 맥락이 새 작업을 오염시키는 일을 막을 수 있습니다.

팁 7. 계획 모드(Plan Mode) 우선

Shift+Tab을 누르면 클로드 코드의 모드를 전환할 수 있습니다. 그중 계획 모드는 클로드가 코드를 읽고 조사할 수는 있지만, 아무것도 수정하지 않는 모드입니다.

이것이 중요한 이유가 있습니다.

계획 모드에서 클로드는 작업 계획을 세웁니다. 어떤 파일을 수정해야 하는지, 어떤 순서로 접근할 것인지, 추가로 확인해야 할 사항은 무엇인지를 정리합니다. 필요하면 명확하지 않은 부분에 대해 질문을 던지기도 합니다.

이 과정을 거친 뒤 계획 모드를 해제하고 실행을 지시하면, 클로드가 잘못된 방향으로 코드를 수정해서 되돌려야 하는 횟수가 눈에 띄게 줄어듭니다. 계획 없이 바로 코딩에 뛰어드는 것과 설계를 먼저 하고 코딩에 들어가는 것의 차이. 사람이든 AI든 원리는 같습니다.

[그림 27-3] 계획 모드에서 클로드가 작성한 작업 계획 예시

팁 8. 에이전트를 주니어 개발자처럼 대하기

"이 기능을 구현해"라고 직접 명령하는 것과 "사용자 이탈률을 줄이려면 어떤 접근이 좋을까?"라고 문제를 던지는 것. 이 둘의 차이는 생각보다 큽니다.

클로드에게 구체적인 명령만 내리면, 클로드는 시킨 대로만 합니다. 하지만 문제를 던지면 클로드가 스스로 추론하고, 여러 선택지를 비교하고, 왜 특정 접근을 택했는지 설명합니다.

이 과정에서 두 가지 이점이 생깁니다. 우선, 클로드가 자기 논리를 세우고 나서 코드를 작성하기 때문에 결과물의 품질이 올라갑니다. 그리고 클로드의 추론을 검토하면서, 우리가 미처 생각하지 못한 고려사항을 발견할 수도 있습니다.

주니어 개발자에게 일을 맡길 때를 떠올려 보십시오. "이렇게 해"라고만 하면 그 사람은 성장하지 못합니다. "이 문제를 어떻게 풀면 좋을까?"라고 물으면 그 사람이 생각하고, 그 생각을 검토해 줄 수 있습니다. 클로드도 마찬가지입니다. 생각할 기회를 주면 더 나은 결과를 내놓습니다.

팁 9. 질문 유도 프롬프팅(Question-Driven Prompting)

계획 모드에서 클로드가 스스로 질문을 던지기도 하지만, 이것을 좀 더 적극적으로 활용하는 방법이 있습니다.

프롬프트에 이런 지시를 추가합니다. "내가 원하는 것과 네가 해야 할 일을 95% 확신할 때까지 계속 질문해 줘." 이렇게 하면 클로드가 모호한 부분을 하나씩 짚어가며 확인합니다. 타깃 사용자가 누구인지, 에러 발생 시 어떤 행동을 기대하는지, 성능 기준은 무엇인지. 우리가 미처 명시하지 못한 요구사항이 질문을 통해 드러납니다.

이 정렬 과정이 없으면 어떻게 될까요? 클로드가 나름대로 가정을 세우고 작업을 진행합니다. 결과물을 받아 보면 의도와 다른 부분이 세 군데, 네 군데 나옵니다. 수정을 요청하고, 또 수정하고. 이 왕복이 세 번만 반복돼도 컨텍스트는 빠르게 소진됩니다.

질문 유도 프롬프팅은 이 왕복 비용을 사전에 차단합니다. 처음에 5분 더 투자해서 요구사항을 명확히 하면, 이후의 30분을 아낄 수 있습니다.

팁 10. 투두 리스트에 자가 검증 삽입하기

클로드 코드는 작업을 시작할 때 투두 리스트(to-do list)를 만듭니다. 이 리스트에 검증 단계를 직접 끼워 넣는 것이 열 번째 팁입니다.

예를 들어 웹사이트를 만드는 작업이라면, 투두 리스트를 이렇게 구성할 수 있습니다.

1. 웹사이트 레이아웃 구현
2. 웹사이트 스크린샷을 찍고 레이아웃이 의도대로 나왔는지 확인
3. 크롬 개발자 도구(Chrome DevTools)를 열어 기능 오류가 없는지 점검
4. 반응형 디자인이 모바일에서도 정상 동작하는지 확인
5. 확인 결과를 반영하여 수정

이렇게 하면 클로드가 무언가를 만들고 바로 우리에게 넘기는 것이 아니라, 스스로 만든 것을 점검하고, 문제를 발견하면 수정한 뒤에 결과를 보여줍니다.

한 가지 추가 기법이 있습니다. "다음 투두로 넘어가기 전에, 현재 항목이 95% 완성됐다고 확신할 때까지 반복해"라고 지시하는 것입니다. AI가 한 번에 완벽한 결과를 내기는 어렵지만, 자가 검증 루프를 돌면 60%짜리 결과물이 90%까지 올라옵니다. 그 차이가 쌓이면 전체 프로젝트의 완성도가 확연히 달라집니다.

[그림 27-4] 자가 검증 단계가 포함된 투두 리스트 구성 예시

작은 습관이 만드는 큰 차이

열 가지 팁을 하나씩 돌아보았습니다. /init으로 시작하고, 상태줄로 현황을 파악하고, 음성으로 빠르게 지시하고, 컨텍스트를 가볍게 유지하며, 진단하고 압축하고, 계획을 먼저 세우고, 문제를 던지고, 질문을 유도하고, 검증을 자동화하는 것. 어느 하나 복잡한 기술이 아닙니다. 그저 습관입니다.

이 기본기가 몸에 배면, 다음 단계로 넘어갈 준비가 된 것입니다. 보조 에이전트를 활용한 병렬 작업, 커스텀 스킬 파일 제작, 비용 최적화처럼 좀 더 정교한 기법들이 기다리고 있습니다.