올해 초, 앤트로픽이 조용히 하나의 숫자를 꺼냈다. 자사 프로덕션 코드베이스에 병합되는 코드의 80% 이상이 이제 Claude가 작성한다는 것. 심지어 내부 엔지니어 한 명은 5개월째 코드를 직접 한 줄도 작성하지 않았다고 했다. 처음 이 글을 봤을 때 솔직히 반응이 두 갈래로 갈렸다. “그게 가능하다고?” 하는 의심과, “그럼 나도 한번 해봐야 하는 거 아닌가” 하는 호기심.
나는 LangGraph 기반 에이전트 시스템을 운영하고 있다. RAG 파이프라인도 직접 설계해서 쓴다. 그 과정에서 크고 작은 디버깅을 반복하면서, 어느 순간부터 Claude Code를 끼워 넣기 시작했다. 이 글은 그 경험을 정리한 것이다. 잘 됐다는 이야기만 쓰면 재미없으니, 막힌 것도 솔직하게 쓴다.
왜 Claude Code를 RAG 디버깅에 쓰게 됐나
계기는 청킹 버그였다. LangGraph로 구성한 RAG 파이프라인이 있었는데, 특정 문서 유형에서 검색 정확도가 갑자기 뚝 떨어지는 현상이 생겼다. pgvector에서 가져오는 청크가 내용이 뚝뚝 끊겨 있었고, 문맥이 달아나 있었다. 원인은 짐작이 갔다. 청킹 로직 어딘가에서 문서 헤더 기준 분리가 제대로 안 되고 있을 거라는 감.
문제는 그 코드를 처음부터 내가 짠 게 아니었다. 전임자가 남긴 파이프라인 일부를 이어받아 개선하는 중이었다. 파일이 7개에 걸쳐 있었고, 청킹 설정이 어디에 숨어 있는지 파악하려면 한참 뒤져야 했다.
그때 Claude Code를 프로젝트 루트에서 열어봤다. / 명령으로 “이 프로젝트 구조 설명해줘”를 먼저 쳤다. 3분도 안 돼서 전체 파일 구조와 각 모듈의 역할이 정리된 요약이 나왔다. 그리고 “청킹 로직이 어디에 있어”라고 물었더니 두 파일을 짚어줬다. 내가 확인하는 데 30분이 걸렸을 걸 Claude Code는 2분 만에 했다.
코드 안 짜고 버그 고친 실제 과정
청킹 문제를 파악하고 나서 수정을 어떻게 했냐는 게 핵심이다. 나는 Claude Code에 이렇게 입력했다. “헤더 기준으로 문서를 분리하는데, 헤더 다음에 오는 소제목까지 같은 청크에 포함되게 수정해줘. 지금은 헤더만 떼어내고 나머지가 이어지지 않는 것 같다.”
Claude Code는 파일을 열고, 기존 로직을 분석한 다음, 수정 제안을 보여줬다. 그리고 실제로 파일을 수정하기 전에 어떤 라인을 어떻게 바꿀 건지 먼저 설명했다. 나는 그걸 읽고 “맞는 방향이다” 싶어서 승인했다.
결과는 청크 품질이 눈에 띄게 개선됐다. 검색해서 올라오는 컨텍스트가 끊기지 않고 문단 단위로 유지됐다. 이전에는 512 토큰으로 기계적으로 자르던 걸, 헤더와 소제목을 기준으로 semantic하게 분리하는 구조로 바꾼 것이다. 내가 직접 짰으면 아마 1시간쯤 걸렸을 작업을 20분 만에 끝냈다.
여기서 중요한 포인트가 있다. Claude Code가 단순히 코드를 써주는 게 아니라, 내가 무엇을 원하는지를 파악하고 맥락 안에서 제안한다는 점이다. 전체 파이프라인 구조를 이미 읽고 있기 때문에, 내 요청이 다른 모듈에 영향을 주는지도 같이 체크해줬다. 나는 그 판단을 보면서 최종 결정을 했다.
LangGraph 에이전트 노드 수정, 실제로 어디까지 되나
RAG 파이프라인 다음으로 가장 많이 Claude Code를 쓴 건 LangGraph 에이전트 노드 작업이다. 나는 Supervisor 패턴으로 멀티에이전트를 운영하고 있는데, 특정 조건에서 라우팅이 예상대로 안 되는 경우가 생겼다. Supervisor가 엉뚱한 서브에이전트로 태스크를 보내는 상황이었다.
이 문제를 Claude Code에 가져갔다. “Supervisor 노드에서 이 조건일 때 route_to_researcher로 가야 하는데 계속 route_to_writer로 빠진다. 왜 그런지 찾아줘.” 그러자 Supervisor 노드 코드를 분석하면서 조건 분기 로직에서 우선순위 체크 순서가 잘못됐다는 걸 찾아냈다. 조건 A보다 조건 B를 먼저 평가하고 있어서 의도와 반대로 작동하고 있었던 것이다.
이건 내가 직접 코드를 읽었으면 한 20분은 쳐다봤을 부분이다. 조건 분기가 길고 중첩돼 있어서 흐름을 따라가기 쉽지 않았다. Claude Code는 5분 만에 짚어줬고, 수정 방향도 제시했다.
다만 여기서 한계가 있다. 수정 제안은 맞는데, 그 수정이 실제 비즈니스 로직에 맞는지는 내가 판단해야 한다. “조건 순서를 바꾸면 이 에이전트가 더 자주 호출된다”는 기술적 결과는 알려주지만, “그래서 비즈니스 목적에 맞는가”는 내 몫이다. Claude Code는 코드의 인과관계를 설명하지, 목적을 이해하지는 못한다. 이 경계를 분명히 알고 쓰는 게 중요하다.
Cursor랑 뭐가 다른가! 실무에서 느낀 차이
개발자라면 당연히 Cursor와 비교하게 된다. 나도 둘 다 쓰면서 차이를 정리해봤다.
Cursor는 IDE 안에 AI가 들어온 형태다. 코드를 쓰면서 인라인으로 제안받고 싶을 때 편하다. 특히 새 파일을 작성하거나 빠르게 초안을 잡을 때 속도가 빠르다. 반면 Claude Code는 터미널 기반이라 파일 시스템 전체를 보는 맥락이 더 넓다. 이미 있는 코드베이스를 분석하고, 여러 파일에 걸친 변경을 조율하는 데는 Claude Code가 훨씬 자연스러웠다.
내가 찾은 패턴은 이렇다. 새 기능을 처음 짤 때는 Cursor를, 기존 시스템에서 버그를 잡거나 리팩토링할 때는 Claude Code를 쓰는 것이다. 특히 LangGraph처럼 상태 관리가 복잡하고 파일 간 의존성이 높은 코드에서는 Claude Code의 코드베이스 전체 인식 능력이 확연히 빛난다. Cursor는 현재 열린 파일을 잘 보지만, Claude Code는 프로젝트 전체를 본다.
물론 같이 쓰는 게 가장 좋다. Cursor에서 빠르게 초안 잡고, Claude Code로 전체 맥락에서 점검하는 방식이다. 이게 지금 나한테 맞는 워크플로다.
비용 현실, 매달 얼마 쓰게 되나
솔직한 이야기를 하자면 비용이 생각보다 올라간다. 나는 Claude Max 플랜($100/월)을 쓰는데, 일일 작업량이 많은 날은 사용량 제한에 걸리기도 한다. Pro($20/월)로는 RAG 파이프라인 디버깅 같은 큰 작업을 하루에 한두 번 하면 한계가 온다.
다만 이걸 시급으로 환산하면 이야기가 달라진다. 청킹 버그 잡는 데 내 시간 1시간이 들어갔다면, 시간당 비용을 생각했을 때 Claude Code가 그 시간을 20분으로 줄여준 게 훨씬 싸다. 나는 AI 도구 비용을 “월 구독료”로 보지 않고 “생산성 향상에 쓰는 도구 비용”으로 본다. 그 기준으로 보면 충분히 가치가 있다.
다만 주의할 점이 있다. 명확한 의도 없이 Claude Code를 계속 대화하듯 쓰다 보면 컨텍스트 토큰이 빠르게 소진된다. 목적을 분명하게 잡고 짧게 요청하는 게 비용을 줄이는 방법이다.
솔직한 한계! 이건 안 된다
좋은 얘기만 하면 광고글이 된다. 실제로 Claude Code가 못 하는 것도 있다.
첫째, RAG 파이프라인의 검색 품질을 높이는 전략적 판단은 못 한다. “BM25와 벡터 검색 중 어느 걸 더 가중치 줄까”는 데이터를 보고 내가 판단해야 한다. Claude Code는 내가 “BM25 가중치를 0.3으로 바꿔줘”라고 하면 바꿔주지만, 먼저 제안하지는 않는다.
둘째, vLLM처럼 인프라 레이어로 내려가면 신뢰도가 떨어진다. GPU 메모리 관리나 tensor-parallel-size 설정 같은 하드웨어 레벨 최적화는 Claude Code보다 내가 더 잘 안다. 이 부분에서 섣불리 Claude Code 제안을 따르다가 추론 서버가 뻗은 적도 있다. 로컬 코드와 달리 인프라는 실수가 크게 돌아온다.
셋째, 에이전트 설계의 “왜”는 알려주지 않는다. LangGraph에서 Human-in-the-Loop를 어느 노드에 걸지, 체크포인터를 어느 타이밍에 쓸지 같은 설계 결정은 전적으로 개발자 몫이다. 구현을 도와줄 뿐, 아키텍처를 고민해주지는 않는다.
앤트로픽 엔지니어 이야기가 나한테 의미하는 것
앤트로픽 엔지니어가 5개월째 코드를 안 쓴다는 이야기로 돌아가보자. 나는 그게 “코드를 안 짠다”가 아니라 “코드를 직접 타이핑하지 않는다”는 뜻이라고 해석한다.
그 엔지니어는 여전히 무엇을 만들지를 결정하고, 설계하고, 결과를 검토한다. 다만 구현의 물리적인 행위를 Claude Code가 대신한다. 이건 내 경험과 정확히 일치한다. Claude Code를 잘 쓰는 날은 내가 “더 많이 생각”하고 “덜 타이핑”하는 날이다. 생각의 비중이 올라가는 것이다.
이 흐름이 지금 AI 엔지니어링 전체에서 진행되고 있다. 코드를 못 쓰는 개발자가 살아남는 게 아니라, 코드 너머를 보는 개발자가 Claude Code를 더 잘 쓰게 된다. RAG 파이프라인 품질을 결정하는 건 코드가 아니라 청킹 전략이고, LangGraph 에이전트 성능을 결정하는 건 구현이 아니라 설계다. Claude Code는 구현을 빠르게 해줄 뿐이다. 빠른 구현 덕분에 나는 설계에 더 집중할 수 있게 됐다.
도구가 좋아진다는 건 결국 그 도구를 쓰는 사람의 판단이 더 중요해진다는 뜻이기도 하다. Claude Code를 쓰면 쓸수록 그 생각이 강해진다.