소소한 Claude Code 사용 근황

seunghyun·2026년 4월 12일

Agentic Programming

목록 보기

3/6

개발 자체보다 개발 도구가 핫한 요즘

요즘 그런 말이 있다. 개발 자체보다 개발 도구가 핫하다고!

아무래도 AI 에이전틱 프로그래밍이 이제 막 생긴 토픽이라 추상화가 덜 된 영역이어서 어딜 가더라도 AI 얘기를 하고
어딜 가더라도 AI를 사용해서 코딩을 하고 있는데, 나 역시 비슷한 상황이다.

Claude Code를 쓰다보면 '어떻게 개발할지'에 대한 내 입맛에 맞는 개발 도구 환경을 구축하게 되는데 이미 다른 개발자들이 만들고 공유한 Claude Skill들을 구경하는 재미도 있고, 재미있는 아이디어의 오픈소스나 상품도 많이 보이는 요즘이다.

예를 들어 클로드 코드 터미널로 긴 작업을 맡겨놓다가 작업이 끝나면 알람을 주는 앱도 있고

Caveman이라는 농담반 진담반으로 만들어진 오픈소스도 있다. (클로드의 출력이 원시인처럼 요약되어서 토큰을 줄일 수 있을 것이라는 가설을 기반으로 만들어진 오픈소스) 얼마 전에 써봤는데 출력 텍스트의 군더더기를 줄이는 데 초점을 둔 것이라 코드 자체에는 영향이 없다고는 하지만 기존의 클로드 페르소나와 엇갈리는 점이 있어서 다시 삭제했다.

그리고 집에서는 터미널에 타자를 치는 대신에 Whisper Flow를 써서 내가 말하는 걸 프롬프트로 직접 넣어주는 중인데, 무의식적으로 클로드에게 스킵하는 맥락이 없는 듯하다. 효과가 엄청 좋다!는 아니지만 생각보다 키보드를 치는 작업이 노동이라서.. 사이드 프로젝트 같은 걸 할 땐 작업속도를 올려주기 좋은 듯 하다.

요즘 second brain 같은 아이디어도 많이 보이고 있었다. 개인 md 파일이나 옵시디언이나 노션이나 등에 이전 컨텍스트에서의 중요한 결정 방식 등을 저장하고 다음에 이 파일을 참조하는 식인데, 클로드에서 자동 메모리 관리 시스템을 릴리즈하면서 간단해졌다.

빌드 명령 자동 기억
디버깅 인사이트 저장
코드 패턴 학습 등이 MEMORY.md에 저장되면 이 파일이 새 세션 시작 시 이 파일이 자동 로드되는 구조다.

그냥 클로드한테 '방금 인사이트를 기억해줘 MEMORY.md에 저장해줘' 라고 하면 된다!
/memory로 보거나 편집도 가능하다.

근데 요즘엔 Andrej karpathy의 https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f 이 글을 참고해서 개인화된 Wiki에 파인튜닝하는 것이나 hermes agent를 활용하는 방안들을 찾아보고 있다.

또는 MemPalace - 영화 제 5원소 주인공 밀라 요보비치가 공개한(!) 오픈소스도 써볼만 할 것 같다.

참고: https://brunch.co.kr/@kk2daddy/140

오픈소스 claude skill/plugin 사용 후기

Superpowers

클로드 플러그인은 settings.json 복사하고, MCP 서버 주소 따오고, Hooks 스크립트를 일일이 로컬에 심어주던 파편화된 설정을 단일 플러그인 번들로 만든 거라서 새로운 프로젝트나 새 팀원이 합류할 때마다 유용하게 쓸 수 있는 그런 것들이다. 요즘 2달 남짓의 짧은 기간 동안 제일 잘 쓴 플러그인은 superpowers였다.

원래는 주로 Claude Code CLI에서 클로드랑 같이 따로 만든 PRD.md를 plan 모드와 시스템 프롬프트로 구현하는 방식을 애용하고 있다가, 회사 팀원분의 추천으로 Superpowers 라는 플러그인을 알고난 후부터 쭉 이 플러그인을 써오고 있다.

원래 하던 방식 중 플랜 모드는 작은 작업의 단위라서 큰 결정이 있을 때 사용하거나 워크플로우를 짤 때 하나하나 스킬을 추가하거나 프롬프트를 추가하는 식이었는데, 그동안 필요했던 것들이 이 플러그인에 다 있던 것 같아서 사용하기에 너무 편했다!

Superpowers를 활성화하면 일단 클로드가 질문부터 시작한다. 클로드랑 설계나 디테일적인 구현 등 뭘 할 때에든 같이 plan모드로 계획/설계를 세운 후 서브에이전트에게 각 태스크를 할당하고 각 작업이 완료되면 자동으로 코드 리뷰를 수행하는 과정이 강제된다. (시간은 좀 걸리지만) 단기 기억 상실이나 성급한 코드 작성 등에 의한 불필요한 핑퐁이나 버그들이 눈에 띄게 줄었기 때문에 계속 손이 가고 있다. + TDD(테스트 주도 개발) 방식을 강제하고 있어서 인간 개발자가 일하는 워크플로우(설계-> 계획-> 구현-> 검토) 자체가 어느 정도 추상화되어있는 덕분인 듯.

Superpowers의 개발자 Jesse Vincent의 개인 블로그에서 Superpowers라는 스킬 기반(agentic skills) 프레임워크를 어떻게 개발하게 되었는지 아이디어를 엿볼 수도 있다. 이 아이디어가 좀 재미있고 신기했던게,

로버트 치알딘이라고 하는 설득의 심리학이라고 하는 걸 LLM에 적용하면서 개발했다고 한다. 설득의 6원칙이 LLM에도 통한다는 걸 치알딘이 증명한 논문이 있는데, 그래서 Superpowers가 효과가 있나보다 싶다.

권위의 원칙 : 이 스킬은 필수다 라고 명시를 하면 클로드는 이걸 따라야 한다고 인식한다.
일관성의 원칙 : 클로드가 이걸 따르겠다고 선언하게 한다.
사회적 증거 : 다른 스킬들도 다 이렇게 한다고 하면 클로드가 이게 표준이라고 생각하고 따른다.

구체적으로는 AI가 작업에 착수할 때 따져야 할 '스킬 라이브러리'와 '7단계 파이프라인'을 제공하고 있다.

Brainstorming: 코드를 쓰기 전, Socratic(문답법) 방식으로 아이디어를 구체화하고 설계를 검증한다.
Using Git Worktrees: 승인된 설계가 나오면, 독립된 Git 작업 영역(Worktree)을 생성하여 메인 코드와 분리된 환경에서 안전하게 작업을 시작한다.
Writing Plans: 설계를 바탕으로 2~5분 단위의 아주 작은 태스크로 작업을 쪼갠다.
TDD (Test-Driven Development): Superpowers는 테스트 코드가 없는 상태에서 짠 코드를 삭제해버릴 정도로 엄격하게 '테스트 우선 개발'을 강제한다.
Subagent Development: 복잡한 작업은 하위 에이전트에게 분산하여 처리한다.
Code Review: 계획대로 구현되었는지, 코드 품질은 어떤지 다단계 리뷰를 거친다.
Finishing: 모든 테스트를 통과하면 머지(Merge)하거나 PR을 생성하고 환경을 정리한다.

opus의 에이전트 팀이랑 쓴다면 서브에이전트에게 말도 걸 수 있고, 중간에 태스크 수정도 시킬 수 있고, 각 에이전트 별로 모델을 지정해서 토큰을 아낄 수도 있다.

무튼 무튼 정리하면 심리학 기반으로 설계된 스킬들을 기반으로 개발 가능한 플러그인이다. 브레인스토밍부터 TDD, 코드 리뷰까지 자동화된 워크플로우를 사용할 수 있고 서브에이전트를 PM, 개발자 등으로 분업해서 병렬 실행을 할 수 있다. 또한 자율 작업이 가능해서 몇시간 동안 혼자서도 잘 프로그래밍을 하고 커스텀 스킬도 쓸 수 있다.
(... 단점을 적어야 하는 타이밍인데 크게 불편한 점이 없는 듯하다. 토큰을 좀 빨리 잡아먹는다 정도)

gstack

https://github.com/garrytan/gstack

Readme를 보면 Claude Code를 가상 엔지니어링 팀으로 바꾸는 설정이라고 설명한다.

CEO, 엔지니어링 매니저, 디자이너, 리뷰어, QA, 보안 담당자, 릴리스 엔지니어가 순서대로 붙는 작업 흐름으로 본다. /office-hours로 문제를 다시 정의하고, /plan-ceo-review로 제품 방향을 점검하고, /review로 코드 리뷰를 돌리고, /qa로 실제 브라우저 테스트까지 이어간다.

빈 대화창에서 자유롭게 AI를 쓰고 싶은 사람에게는 오히려 답답할 수 있고, 반대로 제품 정의, 설계, 리뷰, QA, 배포를 한 흐름으로 묶고 싶은 사람에게는 유용할 듯.

근데 토큰을 너무 많이 쓴다..

claude agent-teams (swarms)

누가 작업하는가? — Agent
무엇을 작업하는가? — Task
어떻게 작업하는가? — Skill

opus 업데이트 때 같이 나온 Agent Teams는 여러 Claude Code 인스턴스가 팀을 이루어 병렬로 작업하는 기능이다.

Subagent가 메인 세션 안에서 하위 작업을 위임하는 구조라면, Agent Teams는 여러 독립 세션이 대등하게 협업하는 구조이다. 하나의 리드(lead) 세션이 작업을 분배하고, 팀원(teammate)들이 각자의 컨텍스트 윈도우에서 독립적으로 작업하며, 서로 직접 메시지를 주고받을 수 있다. 코드 리뷰, 디버깅, 새 기능 개발 등에서 병렬 탐색이 실질적 가치를 제공하는 작업에 적합하다.

공식 문서에 따르면 agent teams는 아직 실험적 기능이며 기본 비활성화 상태이고, 팀 기반 실행은 각 팀원이 별도 컨텍스트 윈도우를 가지기 때문에 비용도 만만치 않다. 공식 비용 문서는 plan mode에서 agent teams가 일반 세션보다 대략 7배 많은 토큰을 사용할 수 있다고 안내한다.

prompt->context->harness

프롬프트, 컨텍스트 엔지니어링에서는 '이것 좀 해줘' 또는 '필요한 맥락들 여기 다 있으니까 이걸 참고해서 해줘' 같은 부탁을 했었다면.. 만약 이 때 틀리게 답하면 프롬프트나 추론 루프를 조정하는 것이고,

하네스 엔지니어링에서는 '너 어차피 틀릴거고 CLAUDE.md도 무시할거고 매번 다르게 대답할건데 (= non-deterministic) 그럴거면 이 구조 안에서 이 순서대로 이 작업들을 해줘' 처럼 '제약'을 거는 느낌. 만약 이 때 틀리게 답하면 규칙/자동화 테스트를 추가하는 것이다. 즉 프롬프트나 추론 루프를 수정하는 것이 아니라 하네스를 반복해서 수정하는 것이다.

https://github.com/revfactory/harness

harness를 보며 가장 크게 느끼는 건, 이제 에이전트 활용의 초점이 프롬프트 작성에서 시스템 설계로 이동하고 있다는 점이다.

좋은 모델을 쓰는 것만으로는 충분하지 않다. 어떤 역할을 분리할지, 어떤 지식을 고정할지, 어떤 검증 루프를 둘지, 어떤 협업 패턴을 택할지가 결과를 크게 좌우한다.

그리고 하네스 엔지니어링에서는 이미 충분히 강력한 모델이 있다는 전제 아래, 그 성능을 어떻게 안정적으로 끌어낼 것인지에 집중한다. 결국 중요한 건 모델 그 자체보다 구조, 더 정확히는 모델이 일하는 환경과 협업 방식의 설계라는 관점.
근데 모델이 발전하면, 모델의 부족함을 메우기 위해 만들었던 하네스 로직은 순식간에 구닥다리가 된다.

즉 방향성은 하네스 엔지니어링의 복잡성을 플랫폼이 흡수하게 된다는..?

그래서 사람이 할 일은 에이전트 인터페이스 설계라고들 한다.
에이전트가 어떤 도구를 쓸지, 어디까지 권한을 줄지, 결과물을 어떤 형식으로 주고받을지.

후기

실무에서 게임 개발을 할 때 개발과 기획이 유동적으로 변해야 할 때가 많은데, 불과 1년 전만 해도 1달이 걸렸을 작업이 1주일로 줄어들었고 그 절약된 시간동안 툴 개발에도 조금 더 투자를 할 수 있게 되어서
팀 내에서 게임디자인적으로 다양한 시도를 해볼 수 있는 기회가 늘어났다. 그래서 게임의 본질인 재미라는 가치에 집중할 수 있다는 점에서 정말 순기능이라고 생각한다.

내가 생각하는 좋은 에이전틱 엔지니어링이란 예측 불가능한 결론을 내는 비결정적 도구인 AI가 결정적인 결과를 만들 수 있도록 하네스를 설계하고 개발자인 나 자신까지 추상화하는 작업인 것 같다.
(스터디를 시작하는 지금 1주차와는 달리 5주차에는 어떻게 생각이 바뀔지, 또는 그대로일지도 궁금하다)

직접 손으로 함수를 쓰고 구조를 설계하던 게 불과 몇달 전인데.. 이렇게 기술이 빠르다니 기분이 참 묘한데

이래나 저래나 개발자의 역할은 문제를 정의하고 추상화하고 해결하는 역할이라는 점에서는 변화가 없고 감사하게도 나는 아직 개발자의 역할에 재미를 느끼고 있다.

2주차에는 더 재미난 사용 후기들을 가지고 와야겠다 !!

(추가) 새로 알게된 것들

AI스터디 1주차에서 우리 조, 다른 조 조원분들이 공유해주신 내용 중에 새로 알게 된 것들이 있어서 조금 찾아보고 써보고 추가로 정리해둔다!!

TMux

TMux (Terminal Multiplexer) 는 몰랐었는데 쓰는 분들이 계신다고 하셔서 일반 터미널이랑 뭐가 다른지 조금 찾아봤다.
제일 크게는 서버에 내 TMux를 돌리고 TMux는 그걸 보여주기만 해서 세션 끊김없이 할 수 있다는 점이 장점인 것 같고, 화면 분할이 용이한 것 같다. opus 4.7 automode를 쓸 때 좋을 듯하여 나도 설치하였다.

rtk (Rust Token Killer)

rtk는 AI 코딩 도구가 실행하는 CLI 명령어 출력을 LLM에 전달하기 전에 필터링·압축해 토큰을 60~90% 절감하는 단일 Rust 바이너리이다.
git, grep, ls, cargo test 등 100개 이상의 명령어를 지원하며, 명령어 출력을 LLM 컨텍스트에 전달하기 전에 스마트 필터링, 그룹핑, 트렁케이션, 중복 제거의 4가지 전략을 적용된다.

소개를 받고나서 따로 찾아봤는데 다른 토큰 최적화 관련 token optimizer 아이디어들이 제법 있더라..!

먼저 토큰 최적화는 두 갈래인데, 같은 토큰 최적화지만 해결하는 문제가 다르다.

(A) CLI 출력물 압축
- 쉘 명령 결과(git, test, ls 등)가 컨텍스트에 들어가기 전에 노이즈를 걷어냄. 세션 내 토큰 소비 자체를 줄임.
- rtk가 해당함
- context-mode라는 툴 출력을 샌드박스 처리하는 것도 있는데 이건 rtk랑 달리 Bash만 커버하지 않고 라우팅을 통해 curl이나 Playwright 스냅샷 같은 비정형 출력도 컨텍스트 폭발 방지를 시도한다.
(B) 대화 히스토리 압축
- 오래된 메시지를 요약해서 롱세션에서 컨텍스트 창이 안 터지게 함. /compact의 개선판.
- claude-rolling-context는 컨텍스트 100K 이하면 그대로 통과, 넘으면 Haiku로 백그라운드 요약 후 ~40K 최근분은 그대로 유지하는 거라 rtk와 겹치지 않고 진짜 롱세션용으로 쓰는 듯
- 여기에 세션 간 메모리를 합친게 claude-mem인데, 이건 토큰 절감이 주 목적이 아니라 세션 간 연속성이 주 목적이라 애초에 좀 다른 결이라고 봐야 할 듯
(A+B) 둘을 합친 버전
- Headroom 이라는 것도 있다. rtk랑 서로 보완 관계인데 rtk는 CLI 명령을 재작성, Headroom은 나머지(JSON 배열, 코드, 로그, RAG 결과, 대화 히스토리)를 압축할 수 있다.

프로덕션급 AI 에이전트를 위한 하이브리드 평가 프레임워크

개발자의 역할은 점수를 매기는 것이 아닌 점수의 의미를 정의하는 것으로 가고 있는데

어떤 축으로 평가할지,
가중치는 어떻게 줄지,
몇 점부터 자동 실행시킬지 개발자가 정하는 것이다.

점수는 여러 축으로 나뉠 수 있따. 예를 들어서

① Goal Achievement       - 목표 달성했나?
② Action Correctness     - 올바른 도구를 올바른 방식으로 썼나?
③ Trajectory Quality     - 낭비 없이 깔끔하게 했나?
④ Uncertainty Handling   - 모를 때 멈추거나 물어봤나?
⑤ Safety & Policy        - 안전 규칙 위반 안 했나?
⑥ Cost / Efficiency      - 비용 효율적이었나?

그래서 AI Agent한테 얼마나 믿고 일을 맡길지 판단하는 시스템을 어떻게 만들까?
에 대한 프레임워크를 토대로 Eval Harness를 꾸릴 때 참고해볼 만한 것들을 소개받았다. (Eval이란 유닛테스트랑 다르게 결과, 답이 맞나를 보는 대신 판단 과정 전체를 보며 믿을 만한지를 보는 비결정적인 Agent를 위한 CI 파이프라인라고 볼 수 있다)

공유해주신 자료

BMAD-METHOD

그 외로 BMAD-METHOD도 새로 알게 되었는데, 코드 짜기 전에 완벽한 설계도부터 만든 후 적용하는 방식이다. AI가 자꾸 샛길로 빠진다면 작업을 더 잘게 쪼개는 BMAD를, 코드 검증이 불안하면 Gstack의 리뷰 패턴을 쓰는 방식이 있다.

참고 링크

seunghyun

다음 포스트