매우 충격적이고 배울 점이 많음: Claude Code 담당자도 Cursor를 사용하는가?
요약
Anthropic의 기술 스태프 Boris가 Claude Code의 탄생 배경과 개발 과정을 인터뷰했습니다. Claude Code는 Anthropic의 공개 API를 활용한 도그푸딩(Dogfooding) 프로젝트로 시작되었으며, 현재는 코드 리뷰와 PR 작성 등 개발 워크플로우의 상당 부분을 자동화하고 있습니다.
핵심 포인트
- Claude Code는 Anthropic의 공개 API만을 사용하여 개발됨
- PR 작성 및 코드 리뷰 작업의 80~90%를 Claude가 수행
- 해커톤 프로젝트로 시작하여 도구 사용(Tool Use)의 가능성을 확인
- 모델의 진화 속도에 맞춰 제품을 설계하는 것이 중요함
매우 충격적이고 배울 점이 많습니다.
Claude Code 담당자도 Cursor를 사용하나요?
거의 Claude가 코딩을 하고 있으며, 우리가 사용하는 것과 동일한 도구로 개발하고 있습니다.
이하, 비디오 대화 요약 (By Gemini 웃음)
- Claude Code의 탄생과 초기 개발
실제로, 풀 리퀘스트(Pull Request)의 거의 100%(메시지 작성 및 커밋 등)는 Claude가 작성합니다. 코드 리뷰(Code Review)에 대해서도 현재는 대부분을 Claude가 수행하고 있으며, 아마도 작업의 80%에서 90%는 Claude가 담당하고 있습니다. 우리는 Claude Code SDK와 /codereview 명령어를 사용합니다. 태스크(Task)가 조금 복잡한 경우에는 '플랜 모드(Plan mode)'부터 시작합니다. 함께 계획을 세운 뒤 실행을 지시합니다.
인터뷰어:
자기소개와 함께, Claude Code가 탄생하게 된 계기를 조금 말씀해 주시겠습니까?
보리스 (Boris):
Tolia 님, 초대해 주셔서 감사합니다. 저는 보리스입니다. Claude Code의 크리에이터이자 Anthropic의 기술 스태프 멤버입니다. Claude Code의 기원은 약 1년 전의 해커톤(Hackathon) 프로젝트였습니다. 처음에는 코딩용 제품으로 의도된 것도, 제품화를 생각했던 것도 아니었습니다. Anthropic의 공개 API(현재도 Claude Code가 사용하고 있는 것)의 사용법을 이해하기 위해 만들었습니다. API의 감각을 익히고, 우리 스스로 테스트(Dogfooding)하기 위한 것이었습니다. 현재도 Claude Code는 Anthropic의 공개 API만을 사용하고 있으며, 여러분이 사용하고 있는 것과 동일한 공개 모델을 사용합니다. 도그푸딩(Dogfooding)은 성공적이었다고 할 수 있겠네요.
인터뷰어:
처음부터 Claude Code를 만들기 위해 입사하신 것은 아니군요. 입사 당시에는 어느 팀에 계셨으며, 어떻게 Claude Code를 만들게 되었고, 어떻게 대량의 리소스를 투입하게 되었나요?
보리스:
제가 참여한 곳은 'Anthropic Labs'라는 팀이었습니다. Anthropic의 공동 창립자 중 한 명인 벤 만(Ben Mann)과 초기 멤버인 라프(Raph)가 이끌고 있었습니다. 이전에 Instagram에 있을 때도 비슷한 Labs 팀에 있었는데, 새로운 프로젝트를 시작하며 '다음에 무엇을 만들어야 할까'를 모색하곤 했습니다.
AI 연구소에서의 이러한 혁신 팀은 매우 특수합니다. 언제든 무수히 많은 것을 만들 수 있는 가능성이 있으며, '모델은 아직 어떤 제품도 커버하지 못하는 모든 태스크를 수행할 수 있는 능력이 있다'는 압도적인 느낌을 받습니다. 이러한 상황에서 그들은 무엇을 해야 할지 고민하고 있었습니다. MCP(Model Context Protocol)나 Claude 데스크톱 앱도 멤버는 다르지만 같은 팀에서 탄생했습니다.
처음에는 터미널(Terminal) 위의 단순한 채팅 앱이었습니다. 그러다 어느 날, 장난 삼아 Bash 도구에 대한 접근 권한을 부여해 보았습니다. 터미널에서 Claude에게 "내 음악 플레이어를 제어해 줘"라고 부탁하자, Claude는 즉시 Bash 도구를 사용하여 AppleScript를 작성하고 이를 실행하여 지금 듣고 있는 곡을 알려주었습니다. 게다가 AppleScript로 음악의 재생 및 정지까지 할 수 있었습니다. 이에 큰 충격을 받았습니다. 당시 저는 LLM의 API로 도구 사용(Tool Use)을 해본 적이 없었습니다. 텍스트를 보내면 텍스트가 돌아오는 것뿐이라고 생각했던 모델이, 도구를 사용하여 현실 세계와 상호작용하고 싶어 한다는 사실을 깨달은 것입니다.
- 모델의 진화에 맞춰 제품을 만들기
인터뷰어:
모델의 진화가 제품에 어떤 영향을 미치는지에 대해 여쭙겠습니다. "현재의 모델이 아니라, 6개월 후의 모델을 향해 제품을 만들어라"라는 조언을 듣고 계신다고 하는데, 현재의 기능에 과적합(Overfit)되지 않으면서 제품의 기반(Scaffolding)을 구축하는 균형에 대해 어떻게 생각하시나요?
보리스:
정확히 그렇습니다. "오늘의 모델"을 위해 만들어서는 안 됩니다. 3~4개월 후에는 완전히 다른 능력을 가진 다음 모델이 나올 것이기 때문입니다. Claude Code에서는 의도하지 않았더라도 이를 실천하고 있었습니다. 우리가 처음 Claude Code를 만들기 시작했을 때는 Claude 3.5 시대였고, 커밋 메시지나 코드는 생성할 수 있었지만 컴파일 에러(Compile Error)나 린트 에러(Lint Error)도 많아서 완벽하지 않았습니다.
하지만 3.6이나 3.7로 진화함에 따라 좋아졌고, Sonnet 3.5 (Claude 3.5 Sonnet)나 Opus가 나왔을 때 갑자기 모든 것이 맞아떨어졌습니다. 모델과 스캐폴딩(Scaffolding)이 완벽하게 기능하게 된 것입니다. 모델이 항상 같은 실수를 한다면 그것을 수정하기 위한 발판을 구축하지만, 우리는 의도적으로 "가공되지 않은(Raw)" 상태를 남겨두려 노력합니다. 예를 들어 모델이 문자열 치환(string replace)에서 실수를 했다면, 일부러 사용자에게 그것을 보여줍니다. 모델이 무엇을 할 수 있고 무엇을 할 수 없는지에 대한 직관을 사용자가 잡는 것이 중요하기 때문입니다. 모델이 진화할 때마다 발판을 변경하고, 불필요해진 프롬프트나 도구는 삭제합니다. "이전 시스템 프롬프트의 절반을 삭제했다"는 일도 있었습니다. 새로운 모델에는 그것이 필요하지 않았기 때문입니다.
인터뷰어:
엔지니어와 코드의 관계는 어떻게 변하고 있나요?
보리스:
이전에는 자신이 작성한 코드에 집착하며 "이것이 올바른 방법이다"라고 방어적으로 굴 때도 있었습니다. 하지만 지금은 시스템 프롬프트도 Claude Code 자체도 빈번하게 다시 작성하며, 일주일에 몇 번씩 도구를 추가하거나 삭제합니다. 실험 비용이 매우 저렴해졌기 때문에, 모델을 자유롭게 두고 자율성(Agency)을 부여해야 합니다.
- 일상적인 개발 워크플로우와 "터미널"의 부활
인터뷰어:
개인적인 셋업이나, Claude와 Cursor를 어떻게 구분해서 사용하고 있는지 알려주세요.
보리스:
소프트웨어 개발 생명주기(SDLC: 계획, 코딩, 디버깅, 유지보수)에 따라 나누어 생각하고 있습니다.
계획 (Planning): Claude Code를 사용합니다. BigQuery 서버에 접근시켜 데이터를 쿼리하게 하고, "코드는 쓰지 말고 아이디어만 짜보자"라고 지시하여 접근 방식을 결정합니다.
코딩 (Coding): 태스크에 따라 Claude Code와 Cursor(또는 VS Code)를 구분해서 사용합니다.
디버깅 (Debugging): Claude Code를 사용합니다. MCP를 통해 Puppeteer를 사용하여 브라우저의 에러 로그를 보여주거나, 터미널에서 로그를 tail하여 직접 Claude Code에 파이프(pipe)로 전달해 컨텍스트를 제공합니다.
유지보수 (Maintenance): 불필요한 코드나 실험용 코드를 삭제하는 등의 작업은 Claude Code에 맡깁니다.
코딩 태스크는 주로 세 가지로 분류합니다.
간단한 태스크: 한 번의 프롬프트로 완료되는 것. GitHub Issue에서 @claude라고 멘션하여 PR을 만들게 합니다.
중간 단계 태스크: 터미널 상에서 대화하며 진행합니다. 모델이 잘못된 방향으로 가려고 하면 중간에 중단(escape)시켜 궤도를 수정합니다. 플랜 모드(Plan Mode)를 사용하면 성공률이 2030%에서 7080%로 급증합니다.
어려운 태스크: 사전에 Markdown 파일로 계획을 세우고, 그것을 Claude가 구현하게 합니다. 최종적으로는 Cursor와 같은 IDE를 열어 직접 미세 조정합니다. 현재 제 작업의 40~50%는 원샷(One-shot, 한 번의 지시)으로 완료됩니다.
- 커밋의 규율, 프라이버시, 보안
인터뷰어:
거대한 자동 커밋이 이루어지는 가운데, 팀 내에서 어떻게 커밋의 규율을 유지하고 있나요?
보리스:
초기에는 제가 거대한 PR을 직접 main 브랜치에 푸시했기 때문에 모두에게 불평을 들었습니다 (웃음). 규모가 커짐에 따라 브랜치와 PR 사용을 철저히 하고, 강력한 정적 분석(Static Analysis)과 린트(Lint)를 도입했습니다. Claude는 변경 세트를 논리적으로 분할하여 여러 개의 커밋이나 PR로 만들어주기 때문에, 지금은 매우 초점이 명확하고 깔끔한 PR이 생성되고 있습니다.
인터뷰어:
API 키나 시크릿(Secret) 관리, 보안에 대해서는 어떻게 하고 계신가요?
보리스:
기본적인 수준으로는, 모델의 정렬 (Alignment, 안전성 조정)에 막대한 노력을 기울여 악의적인 Bash 명령어를 실행하지 않도록 하고 있습니다. 또한, 프롬프트 인젝션 (Prompt Injection)을 방지하기 위한 분류기 (Classifier)를 배치하고, 웹 검색의 생(raw) 출력을 Claude에게 직접 보여주지 않도록 하는 중간 모델도 준비해 두었습니다.
사용자 측에서 할 수 있는 방법으로는, settings.json의 Deny (거부) 규칙을 사용하는 것이 확실합니다. 읽기 (read) 권한을 거부하는 것만으로도 충분합니다. 또한, "Post-hooks (포스트 후크)"를 사용하여 모델에 데이터가 전달되기 전에 시크릿 (Secret) 정보를 스크럽 (Scrub, 제거)하는 것도 가능합니다.
- "서브 에이전트 (Sub-agents)"라는 새로운 개념
인터뷰어:
화제가 되고 있는 "서브 에이전트"에 대해 알려주세요.
보리스:
서브 에이전트는 메인 Claude가 호출하는 "자식 Claude"를 말합니다. 메인 프로세스를 "Mama Claude (마마 클로드)"라고 부르며, 그녀가 특정 서브 태스크 (Sub-task, 코드 리뷰, 코드 단순화, 계획 수립 등)를 위임하기 위해 "Baby Claudes (베이비 클로드)"를 생성합니다.
이것은 Reddit에서 "MCP 서버를 사용하여 PM, 디자이너, 프론트엔드, 백엔드 서브 에이전트를 만들었다"라는 게시물을 본 팀원이 해커톤에서 만든 것이 시작입니다. 컨텍스트 윈도우 (Context Window)나 도구가 해당 태스크에만 집중되도록 제한되기 때문에 매우 효율적입니다. 향후 모델 자체의 컨텍스트 관리 능력이 완벽해지면 불필요해질(권장되지 않을) 수도 있지만, 현재 모델의 기반으로서는 매우 강력합니다.
- 비엔지니어 계층으로의 확산과 미래의 엔지니어
인터뷰어:
엔지니어 이외의 멤버들이 사용하는 비기술적인 유스케이스 (Use case)에 대해 알려주세요.
보리스:
놀랍게도, 지금까지 터미널 (Terminal)을 한 번도 만져본 적이 없던 사람들이 Claude Code를 사용하고 있습니다.
디자이너: Figma 디자인을 Claude Code에 전달하여 프로토타입을 만들게 합니다. 몇 번의 이터레이션 (Iteration)만으로 엔지니어가 작성하는 것과 같은 프로덕션 레벨의 코드를 생성합니다.
데이터 사이언티스트: BigQuery와 연결하여 터미널에서 자연어로 고도의 데이터 분석 쿼리 (Query)를 자동 생성하게 합니다.
프로덕트 매니저 (PM): 시장 조사를 위해 "20개의 리서치용 에이전트를 실행해서 요약해줘"라고 지시하며, 30분 후에는 완벽한 PDF나 표 형식의 보고서를 받습니다.
인터뷰어:
마지막으로, 엔지니어의 역할은 앞으로 어떻게 변화하며, Anthropic에서는 어떤 인재를 찾고 있나요?
보리스:
현재 저희가 요구하는 기술은 과거와는 완전히 다릅니다. 가장 중요한 것은 지적 탐구심과 성실함, 제1원리 (First principles)로부터 사고할 수 있는 능력, 그리고 자신이 틀렸을 때 그것을 인정할 수 있는 능력입니다. 단일 기술 스택에 집착하는 것이 아니라, 다양한 스택을 넘나들며 해킹할 수 있는 능력입니다.
대기업에서 성공해 온 전통적인 "엔지니어"라기보다는 "과학자"나 "해커"에 가까운 인재를 찾고 있습니다. 제너럴리스트 (Generalist)의 부활이죠. 한 명의 엔지니어가 10인분의 일을 할 수 있는 지금, 유일한 병목 현상 (Bottleneck)은 "아이디어"뿐입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 X AI 사용법/팁의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기