Claude code 를 사용하자

AI 장난감

Copilot과 Cursor를 코딩 도구로 사용해봤지만 성에 차지 않았다.
IDE에 통합돼서 자동 완성은 몹시 유용하고 편하긴 했지만, 딱 거기까지였다.

실제로 작업을 진행함에 있어서 유용한 부분들은 코드 일부 조각들을 만들어주는 것뿐.
코드를 작성하고 프로젝트를 운영하는 데 있어서 생산성을 극한까지 끌어올릴 만한 아웃풋을 낸다는 생각은 전혀 들지 않았다.

코파일럿은 JetBrains IDE에 통합이 되긴 하지만, 단순히 채팅뿐이고 자연스러운 개발 흐름을 만든다는 경험은 전혀 들지 않았다.
Agentic 모드를 지원하는 Cursor IDE조차 편하긴 했지만, 무작위 위치에 생성된 코드들을 살펴보며 내가 리뷰를 해야 하는 건 그렇다 치더라도

개발자에게 프로젝트에 무작위성으로 생성된 마음에 들지 않는 코드를 사용하지도 않던 IDE에서 단축키도 뭐도 아무것도 모르는 상태에서 몹시 불편하게 코드를 작성하거나 수정하는 것만큼, 짜증나고 고역인 일이 있을까?

아무튼 IDE와 통합된다고 해서 짜증만 늘 뿐이지,
ChatGPT 앱을 통해 단축키로 바로바로 작업하는 것보다 생산성이 나아질 만큼 유용한 부분들은 전혀 없었다.
(그래서 나는 ChatGPT만 사용하고 있다.)

운명적 만남

그러다 Claude Code를 만나게 된 것이다.

https://www.anthropic.com/claude-code

Cursor와 Copilot에 호되게 당한 나로서는, 설치할 때까지만 해도 의구심을 품고 있었다.
그 좋아 보이는 IDE에서도 경험이 별로였는데, 과연 터미널에서 코딩을 잘할 수 있을까?

8시쯤 퇴근해서 사이드 프로젝트를 해보려 클로드를 설치하고 당일 사용한 후기를 요약하자면

• $20달러 플랜으로 결제하고 시작
• 한도에 다다르자마자 $100달러 결제
• 새벽 5시 반까지 코딩
• 내가 프리랜서 작업자였다면 바로 $200 결제를 했을 것

좀 재미있게 표현해보자면, 클로드 코드는 나에게 아래와 같은 생각의 전환점을 갖게 해줬다.

텍스트로 만든 게임이 무슨 재미가 있을까? -> 아, 텍스트만 있어도 재밌을 수 있겠네

그만큼 개발자에게는 처음 사용부터 손에 착 감기고, 중독성이 있는 도구이다.
(여기서 몇 가지 사용법을 찾아가게 되면서 더 놀라는 포인트들이 생긴다.)

장난감이 아닌 도구, 아니 파트너

이 도구는 코드를 가지고 놀 수 있게 해주지만,
동시에 개발자들에게는 ‘코드만’을 다루는 도구가 아니라
전체적인 개발의 흐름을 관통해서 연결할 수 있게 만들어준다.

우리는 모니터 없이도 텍스트만 출력된다면 컴퓨터를 다룰 수 있다.
이는 과거의 유물이면서 동시에 잘 쓰여진 역사이기 때문에 가능한 것이다.

컴퓨터의 기본적인 인터페이스를 위한 도구들은 텍스트 기반의 CLI로 만들어져 있고,
클로드 코드는 이 도구들을 모두 잘 알고, 어디에 쓸 줄 알기 때문에,
아주 공격적으로 사용해서 우리에게 날개를 달아준다.

비유하자면, 맥가이버칼은 도구가 많은 게 장점이지만, 우린 뭐가 뭔지 잘 모른다.
클로드는 그걸 모두 다 정확히 알고, 정확히 쓴다.

아무튼 이 간단한 CLI 기반으로 파일을 검색하고, 읽고, 쓰고 아주 잘한다. 그렇다.
내가 코드를 보면서 스트레스를 받을 필요가 없다는 것이었다. 그냥 고성능의 AI가 잘 짜주면 되는 것이었다.
콩깍지인지 모르겠지만 기본적인 코딩 능력 또한, 다른 플랫폼들의 모델보다 꽤 만족스러운 결과물들을 주기도 한다.

아무튼 터미널 기반임에도 불구하고 Agentic하게 코드를 읽고 수정도 가능하고
기존에 ChatGPT 앱을 단축키로 띄워서 사용하는 것만큼 터미널도 쉽게 띄울 수 있기 때문에
클로드 코드도 접근성이 높고 활용도 측면에서도 범위가 넓다.

CLI

이제 코딩에서 넘어가서 본격적으로, CLI여서 가지는 이점들에 대해서 짚고 넘어가보자.

이에 앞서 난 VIM 이나 터미널에서 개발하는것을 좋아하는 개발자가 아니고, 터미널도 사랑하지 않음을 밝힌다.

클로드 코드도 마찬가지로 CLI 기반이기 때문에, 예를 들면 아래와 같이 통합이 가능해진다.

Integration

gh run list | claude "실패한 워크플로우 에러 분석해줄 수 있어?"

무려 pipe를 써서 클로드 코드에 바로 넘겨 질의를 할 수 있다. 😵
유용해 보이나? 유용해 보이지 않는다고..?

Natural language

사실 아래처럼 대충 명령해도, 자기가 북치고 장구치고 실제 필요한 커맨드를 알아서 활용한다.
모르면 찾아보거나 help 때리고, 어디서 들고 온다.

claude "깃허브 액션에서 실패한 워크플로우 에러 분석해줘"

⏺ 실제 실행 오류 상황을 확인하기 위해 최근 GitHub Actions 실행 기록을 살펴보겠습니다.
Bash(gh run list --limit 10)

⏺ 실패한 워크플로우의 세부 사항을 확인해보겠습니다.
Bash(gh run view 15678850596)

⏺ 실패 로그를 더 자세히 확인해보겠습니다.
Bash(gh run view 15678850596 --log-failed)

Natural language workflows

만약 알림 시스템 혹은 CI/CD 연동을 하면, 손쉽게 자연어로 파이프라인을 구축할 수 있게 되는 셈이다.
(물론 세팅할 게 더 많이 있기는 하겠지만)

claude "현재 브랜치의 PR 리뷰 해줘"
claude "현재 발행된 #{{ github.xxx.xxx }} 이슈를 읽어서 코드를 수정하고 PR 만들어줘"
claude "현재 시스템의 AWS ARN은 arn:aws:ec2:us-west-2:123456789012:instance/i-xxx야, AWS CLI 사용해서 이 시스템의 최근 발생 알림을 읽어와서 버그를 해결하고 PR을 생성해줘"

(CI/CD 환경에서는 headless 모드로 실행하면 된다.)

Custom setup

Commands

그러면 이렇게 유용한 자연어 명령을, 매번 하고 싶은 게 생길 때마다 구구절절 타이핑을 해야 하냐?

당연히 custom slash commands를 지원한다.

.claude/commands/command-name.md 파일을 생성하고
여기에 자연어로 커맨드가 입력되면 어떤 일들을 수행할지 기술해놓으면 된다.

/project-root/.claude/commands 에 생성하면 /project:command-name 으로 바로 실행이 가능하고
~/.claude/commands 에 생성하면 /user:command-name 으로 실행이 가능하다.

아래는 클로드가 생성해준 AWS 를 활용한 디버깅 커맨드의 예시이다.

Command	Mock result

당연히 자세히 써놔도 되고, 개떡같이 말해도 찰떡같이 잘 알아듣는다.

얼마나 잘 알아듣는지 official claude-code-action 레포에는 이런식으로 써있다.

.claude/commands/commit-and-pr.md

Let's commit the changes. Run tests, typechecks, and format checks. Then commit, push, and create a pull request.

그러면 뭘 할 수 있을까? 내가 하는 모든 작업들을 커맨드로 묶어놓을 수 있다.
예를 들어서 내가 어떤 작업을 할 때는 항상 깃허브에 이슈를 만든다?

.claude/commands/issue.md
깃허브에 이슈 만들고, 아래의 스펙으로 PRD 만들어서 관리해줘.
- 어쩌구 저쩌구 저쩌구...

/project:issue "로그인 기능 구현"

딸깍

현재까지 작업된거 기준으로 커밋을 알아서 해줬으면 좋겠다?

.claude/commands/commit.md
1. git status와 git diff로 변경사항 파악
2. git log로 기존 커밋 메시지 스타일 확인
3. 컨벤셔널 커밋 형식 적용:
- 타입: chore, feat, fix, style, refactor 등
- 범위: 해당되는 경우 (선택적)
- 설명: 변경사항의 핵심 요약

/project:commit

딸깍

Instructions

프로젝트에 대한 기본적인 인스트럭션은 /project-root/CLAUDE.md 에 기술해놓으면 된다.
이것도 커맨드와 마찬가지로 유저 레벨로 가지고 있을 수 있다.

또 한가지 팁은, 파일 참조를 @file-path 로 프롬프트에서 할 수 있다는 것이다.
(마찬가지로 대화중 특정 파일을 @ 를 사용해서 손쉽게 참조하게 할 수 있다.)

이를 통해서 프롬프트를 모듈화를 하거나 직접 디렉토리나 파일 참조를 걸고 설명할 수도 있을 것 같다.

그리고 추가로 기술하진 않지만,
당연히 MCP도 지원된다.

후기와 마무리

물론 며칠 쓴거가지고 이런 이야기를 하는게 조금 우습기도 하고 앞으로 더 써봐야 하겠지만
내가 자주 사용하는 익숙한 도구들은 대부분 초기 경험이 압도적으로 직관적이어야만 사용한다. 맥북의 트랙패드가 그런 제품 중 하나이다.
클로드 코드도 그런 생각이 드는 제품 중 하나이고, 그동안의 작업들이 AI 와 협업을 하는 느낌이었다면
클로드 코드는 외주를 주고 확실한 레버리지를 일으킬 수 있겠다는 생각이 자연스레 든다.

그리고 IDE 플러그인도 존재하고 계속 개선 중이니, 얼마 안 있어 다른 도구들의 기본적인 기능들만큼은 따라잡아주지 않을까 싶다.

누군가 이 글을 읽고, 글 내용에 왜 코딩 관련된 내용이 그렇게 많지 않느냐 묻는다면
우리가 일 잘하는 사람에게 잘하고 있다는 피드백밖에 줄 수 없듯이, 딱히 말 할게 없기 때문이다.
그리고 일을 잘 한다는건 단순히 하나만 잘한다는 소리가 아니기도 하다.

아마 앞으로는 일상적인건 Chat GPT, 작업은 Claude code 만 사용하지 않을까 싶다.

글을 마무리 하며 몇가지 도움이 될만한 링크들을 첨부한다.

• https://github.com/hesreallyhim/awesome-claude-code
• https://hellovibe.io/
• https://github.com/ryoppippi/ccusage
• https://github.com/nwiizo/claudelytics

---

직접 사용하면서 업데이트 되는 팁

하지 말아야 할 것

1. AI 에게 빡빡한 가이드라인을 들이밀지 말자.
   작업에 관련된 지식이 아니라 프로젝트 운영의 전반적인 규칙같은거.
   “뭐 하기전에 반드시 이거 참조 해, 이거 끝나면 반드시 이거 해”
   예를 들면 메모리 뱅크라는 방법론이 딱 요 케이스이다.
   
   나는 agp-cli 라는 툴을 개발해서 직접 적용해보았는데
   매번 잘 참조를 하는것도 아니고, 참조를 너무 잘하면 또 시간/토큰을 너무 잡아먹어서 배보다 배꼽이 더 커진다. 굳이굳이굳이 필요하면 잘게 쪼개놓고 필요할때 알아서 읽을 수 있을정도만 만들어놓고, 그게 아니라면 본인이 직접 필요한 시점에 명령을 하는게 낫다. (이 문서 읽고 작업해, 이 문서 업데이트 해줘)

2. 메인 태스크에서 벗어난 지시들도 작업 중간에 내리지 말자.
   좀 웃긴 이야기지만, 나는 네가 잘 해낼것이라 믿는다 라는 신뢰가 필요하다.
   목표, 반드시 달성해야 할 것, 하지 말아야 할 것 등을 상방 하방으로 가이드 쳐주고
   그 안에서는 자율적으로 창의력 발휘하도록 주사위 던지는게 제일 나아보인다.

작업의 퀄리티 올리기

1. 일반적으로 Plan mode(shift+tab) 를 쓰는게 타율이 높다. 지시를 하고 계획을 세우라고 한 뒤 거기서 조정을 계속해서 진행한다.
   아니면 Opus4 를 사용하고 목표와 상방/하방 제약을 걸고서는 구체화+깊이 생각해줘 라고 지시하자.

2. 아무리 잘 짜더라도 프로덕션 레벨의 모든 작업에는 검토가 반드시 필요하다.
   태스크 단위로 코드를 보고 직접 교정하거나 수정을 부탁하자.

3. 그래서 다음 태스크로 넘어가기 전에 [2]의 리뷰를 잘 하려면 git 이 필수이다.
   스테이지에 올려놓는것만으로 변경된 부분들만 diff 를 볼 수 있음.
   태스크 단위로 커밋을 해도 되지만, 그건 선호도의 차이가 있을듯.

4. stacked diff 형식으로 작업하는게 여태까지 생각하기엔 최적이다.
   클로드 코드랑 연동해서 리뷰를 로컬에서 쉽게 할 수 있는 diff 도구를 찾거나 만들어봐야 할듯.

5. 태스크 단위라는건 하나의 티켓 단위의 큰 작업이 아니라, 하나의 질의와 그에 대한 코드 변경이라고 보면 된다.
   즉 A 라는 작업은 아래처럼 진행한다.

   • A 작업 준비해줘
   • A-1 해줘 > A...A-1 Diff 리뷰 & 피드백 루프 > 스테이징
   • A-2 해줘 > A-1...A-2 Diff 리뷰 & 피드백 루프 > 스테이징
   • A-3 해줘 > A-2...A-3 Diff 리뷰 & 피드백 루프 > 스테이징
   • A-4 해줘 > A-3...A-4 Diff 리뷰 & 피드백 루프 > 스테이징
   • A...A-4 최종 검토하고 정리해줘
   • 커밋하고 A 작업 완료해줘

6. 클로드 코드는 생각보다 컨텍스트 윈도우가 작아서, 세션이 길어지면 compact 를 진행하고(대화 내용 압축) 다음 세션으로 이어가는데
   이게 생각보다 작업의 퀄리티를 낮춘다. 그러니 작업 진행전에 항상 compact 까지 얼마나 남았는지 우측 하단에서 체크하자.

7. 개인적으로는 플래닝부터 작업 자체까지 토큰을 많이 소비하는 편이라서, 그냥 매 작업별로 세션을 새로 여는게 정신 건강에 이롭다. (어차피 다른 작업간에는 컨텍스트가 안섞이는게 낫다.)

왜 Cursor 보다 나은것 같은지에 대한 고찰

1. Cursor 는 diff 뷰를 통해서 생성된 코드에 대해서 Approve / Reject 를 강요한다.

2. 때문에 사용자는 작업을 하지는 않지만, 계속 코드를 보는 상태이다.

3. 이는 사용자로 하여금 마음에 안드는 코드에 대해서 Reject 하고 직접 수정을 해서 AI 가 변경사항에 대한 컨텍스트를 놓치게 만들거나.

4. "거기는 그렇게 짜면 안되지", "여기는 이렇게 짜줘 XXX" 와 같은 전체 작업 컨텍스트에서 벗어난, 전후를 살펴봐야만 하는 지역적 컨텍스트를 만들게 된다.

5. 체감상 이렇게 컨텍스트 오염이 지속적으로 긴 대화에서 일어나면, 점점 코드의 퀄리티가 저하되고 종국에는 엉뚱한 코드들이 섞이게 되고, 결과물을 이상하게 뱉어내기만 하는 상태가 되기도 한다.

6. 이러한 피드백의 반복으로 사용자는 점점 더 마이크로 디테일을 명령하게 되고, 결과물은 더 개선되지 않는 피드백 루프를 타게 된다.

7. 반대로 Claude Code 에서는 코드를 보지 않고 지시만을 내리는 인터페이스이다.

8. 사용자는 명령만 하고 코드를 보지 않고 결과물만 확인하게 된다.

9. 결과물이 모델의 성능으로 어느정도 커버가 되면서, 명령만 잘 내리면 되는구나를 학습하게 된다.

10. 플랜 모드와 띵킹 모드 등으로, 사용자는 작업 컨텍스트를 어떻게 더 잘 밀어넣고 지시할 수 있는지에 초점을 맞추고 학습하게 되고

11. 이러한 피드백의 반복으로 사용자는 점점 더 코드에 대한 집착에서 벗어나게 되고, 명령과 결과물에 대해서만 집중하는 피드백 루프를 타게 된다.