Claude Code를 통한 에이전트 코딩의 미래

 

소스: https://youtu.be/iF9iV4xponk?si=Efw5EjUCihkcnQT6

가장 유용한 부분

Claude Code 팁 & 베스트 프랙티스: Claude Code 창시자 Boris의 모범 사용 팁

두 가지를 권합니다.

1) 처음엔 ‘코드 생성’부터 시작하지 마세요.

이상하게 들리겠지만, 스스로를 말려야 합니다. 처음에는 코드베이스에 대한 질문부터 하세요. “로거를 새로 추가하려면 어디를 봐야 하지?”, “이 함수 설계는 왜 이렇게 됐지?” 같은 것들요. Claude Code가 리포를 탐색하고, Git 히스토리까지 훑어 답을 내게 하세요. 이 패턴에 익숙해지면 그다음에 코드 작성을 맡기면 됩니다.

2) 작업 난이도에 따라 사용하는 모드를 달리하세요.

대략 ‘쉽다/보통/어렵다’로 나눠요.

쉬운 작업: 한 번의 프롬프트로 거의 완성될 것들. 저는 깃허브 이슈에 @Claude를 멘션해서 PR을 통째로 쓰게 합니다. 터미널을 안 잡아먹고 자동화하기 좋아요.

중간 난이도: 터미널에서 Plan 모드(Shift+Tab) 로 먼저 계획을 정렬(alignment)하고, 합의가 되면 Auto-accept로 실행시킵니다.

어려운 작업: 사람이 운전석에 앉고 Claude는 페어 파트너로 씁니다. 코드 리서치, 아이디어 프로토타입, 경계 탐색(vibe-coding) 등을 Claude에 보조시켜도, 실제 구현은 제가 주도하죠. 단위 테스트 정도는 Claude에게 맡길 수 있습니다.

핵심은 작업의 성격에 맞춰 에이전트를 배치하는 거예요.

---

아래는 유튜브 스크립트 번역 전문

(인트로)
알렉스:
처음 코딩을 배울 때를 떠올려요. 저는 중학교 수학 시간 맨 뒤에 앉아, TI-83 플러스 계산기를 들고 있었죠. 거기에 BASIC으로 프로그램을 짰어요. 어느 순간부터 ‘아, 수학 시험 답을 계산기에 넣어둘 수 있겠네’ 하고 깨달았거든요.
안녕하세요, 저는 알렉스입니다. Anthropic에서 Claude Relations를 맡고 있어요. 오늘은 Claude Code와 소프트웨어 엔지니어링의 미래를 이야기해 보려고 합니다. 함께한 동료는 보리스예요.
보리스:
안녕하세요, 보리스입니다. Anthropic에서 Technical Staff로 일하고 있고, Claude Code를 만들었습니다.에이전틱 코딩의 현재
알렉스:
지난 12개월 동안 정말 많은 변화가 있었고, 특히 코딩 영역은 말 그대로 폭발적으로 변하고 있어요. 매일매일 뉴스를 따라붙지 못하는 분들도 많고, 사실 저도 가끔 놓칩니다. 그동안 무슨 일이 있었고, 지금 어디에 와 있는지 정리해 줄 수 있을까요?
보리스:
작년과 지금은 완전히 다른 세계예요. 1년 전만 해도 코드를 쓰려면 IDE에서 자동완성 조금 쓰고, 별도의 채팅 앱에 코드를 복붙하며 쪼개서 수정하는 게 ‘AI 코딩의 최전선’이었죠.
그런데 약 1년 전부터 ‘에이전트’를 개발 워크플로에 진지하게 넣어 쓰기 시작했어요. 더 이상 장난감이나 프로토타입이 아니라, 개발자 ‘인너 루프(inner loop)’의 일부가 됐습니다.
지금은 코드를 짤 때 에이전트를 씁니다. IDE에서 텍스트를 직접 편집한다기보다, 모델이 코드를 대신 쓰게 하죠. 즉, ‘내가 직접 텍스트를 만지는 것’에서 ‘모델이 텍스트 조작을 해 주는 것’으로 무게중심이 이동했습니다. 그리고 이 흐름은 계속 가속될 거예요.
알렉스:
예전엔 웹앱에서 코드를 복사해 와서 국소적으로 수정하는 정도였다면, 이제는 더 핸즈오프(Hands-off)하게 “하고 싶은 일”을 에이전트에게 말하고, 수십 개의 수정과 심지어 앱 전체를 스스로 만들도록 맡기는 느낌이군요.
보리스:
맞아요. 그걸 1년 전엔 제대로 못 했던 이유가 몇 가지 있어요. 첫째, 모델 성능이 아직 부족했고, 둘째, 모델 위에 얹는 스캐폴딩—저는 ‘하네스(harness)’라고 부르는데—가 성숙하지 않았죠.
Claude Code의 초기 버전을 작년 말쯤, Sonnet 3.5로 시작했어요(지금 말하는 업그레이드된 3.5가 아니라 그 이전). 그때도 어느 정도는 쓸만했어요. 제 작업의 10%쯤은 도와줬죠. 출시 직후 사내 핵심 팀에 배포했는데, 다음 날 출근하니 이미 몇몇 엔지니어가 화면에 Claude Code를 띄워 쓰고 있는 거예요. 모델도, 하네스도 아직 거칠었지만 ‘이미 조금 유용한’ 단계였죠.
지난 1년 동안 모델은 에이전틱 코딩에 훨씬 강해졌습니다(3.7, 4.0, Opus 4.1로 오면서). 하네스도 크게 발전했고요. 모델은 API 뒤에 있는 ‘말 잘 듣는 말(馬)’이라면, Claude Code라는 하네스/안장은 그 말을 제대로 타게 해 주는 장비예요. 안장이 중요하듯, 하네스는 성능에 큰 차이를 만듭니다. (저는 기수는 아니지만요. ^^;)

하네스는 시스템 프롬프트, 컨텍스트 관리, 툴, MCP 서버 연동, 설정, 권한 등 모델과 맞물리는 모든 것이에요. 모델은 이 맥락과 출력들을 모두 보고 행동을 결정하죠. 지난 1년간 우리는 ‘모델에 맞춰 무엇을 어떻게 쌓아야 하는지’를 학습했고, 모델도 Claude Code와 타사 제품들의 피드백을 먹고 함께 공진화(co-evolve) 했습니다.코딩 모델의 진화

알렉스:
공진화라고 했는데, 그게 의도적인 트레이닝 전략 때문인가요? 아니면 제품 기능을 고도화하면서 자연스럽게 모델이 좋아지는 건가요?

보리스:
꽤 유기적이에요. Anthropic에서는 연구자까지 전원이 Claude Code를 씁니다. 모델을 만드는 사람들이 모델로 매일 일을 하니, 자연스럽게 한계가 드러나요. 예컨대 특정 종류의 편집을 모델이 유난히 못 한다면(예: “failed to replace string”—문자열 치환 실패), 그건 ‘모델 역량’ 문제이니 학습으로 개선할 수 있죠.
또 3.5 시절엔 자율로 ‘요리(cook)’하도록 30분 맡겨두면 금방 탈선했는데, 최근 모델일수록 자율 운행 시간이 점점 길어집니다. 사람이 개입해 코스를 수정해야 했던 부분들을 관찰해, 그 자체를 모델이 학습하도록 만들면서요.

알렉스:
새 모델을 평가할 때 개인적으로는 어떻게 체크하나요? 하네스의 새로운 기능을 넣을 때도요.

보리스:
그날 해야 할 진짜 작업을 합니다. 제가 가장 행복한 날은 하루 종일 코딩하는 날이에요. 그날의 실제 업무 파이프라인을 새 모델/새 하네스로 통째로 돌려보죠. 버그 수정, 새 기능, 슬랙/깃허브 이슈 대응, Sentry 로그 읽기… 실제 쓰임새가 가장 큰 시그널이에요. MCP로 컨텍스트 끌어오거나 자동 디버깅 붙여보는 것도 그렇고요.코딩 모델 평가(evals)

알렉스:
결국 최고의 평가(Eval)는 ‘현실과 가장 비슷한’ 사용이군요.

보리스:
맞아요. 제품화된 eval도 만들려고 많이 애썼어요. 시스템 프롬프트를 바꾸면 좋아졌는지 나빠졌는지 재보려고요. 약간은 갖추고 있지만, 진짜 어렵습니다. 제일 큰 신호는 솔직히 바이브(vibes)—즉 체감이 더 똑똑해졌느냐예요. SWE-bench 같은 벤치마크는 상향평준화가 빨라서, 요즘은 더 어려운 T-bench 같은 걸 보기도 하지만, 소프트웨어 엔지니어링의 복잡성을 한꺼번에 포착하는 합성 평가를 만들기는 정말 어려워요.Claude Code의 피드백 루프(내부 도그푸딩)

알렉스:
Claude Code는 내부 도그푸딩 사이클이 유난히 좋다고 느껴져요. 그 루프를 특별히 잘 만든 비결이 있나요?

보리스:
저는 늘 하던 방식—사용자 이야기를 듣고, 사용자가 피드백 주기 쉽게 만드는 데서 시작했어요. 초기에 슬랙에 피드백 채널을 하나로 단일화했죠. “거기에 남겨 주세요.” 사람들이 피드백이 공허로 사라진다고 느끼면 주저하잖아요. 우리는 처음부터 ‘가능한 한 빨리 고치고, 고쳤다고 코멘트로 되돌려주기’를 했어요. 출근해서 2~3시간을 버그 털기에 몰아넣고, 고칠 때마다 스레드에 “고쳤습니다”를 달았죠. 그게 선순환을 만들었고, 지금도 피드백 채널은 소방호스급 트래픽이에요.
사실 저도 정답을 모릅니다. AI는 모두가 만들면서 발견하는 중이에요. 최고의 나침반은 사용자 요구이고, 결국 귀 기울이는 것이 핵심이죠.‘해커빌리티(Hackability)’—CLAUDE.md, MCP, 슬래시 커맨드

알렉스:
제품 관점에서 Claude Code의 최신 상태와 흥미로운 포인트를 들려주세요.

보리스:
Claude Code는 처음부터 단순하지만 해킹하기 쉬운 도구로 설계했어요. 초기에 확장 포인트는 CLAUDE.md였죠. 리포지터리 루트나 하위 디렉터리에 두고, 코드베이스에 함께 커밋하는 추가 컨텍스트 파일이에요.
시간이 지나면서 설정/권한 시스템을 고도화했고, 팀 동료 Dixon이 유저 요청을 모아 Hook 시스템을 만들었습니다. MCP는 말할 것도 없이 강력한 확장 포인트고요. 여기에 슬래시 커맨드와 서브 에이전트가 들어왔습니다. 사용자 정의 슬래시 커맨드는 마크다운 워크플로 파일로 코드를 같이 버전 관리할 수 있어요.
예를 들어 저는 커밋용 슬래시 커맨드를 둡니다. “좋은 커밋 메시지 이렇게 써라” 지침을 넣고, git commit 같은 명령은 선승인해 두죠(매번 허용 안 눌러도 되게). 슬래시 커맨드와 에이전트는 관점만 다를 뿐, 본질적으로 같은 축에 있어요—에이전트는 분기된 컨텍스트 창을 가진 슬래시 커맨드처럼 볼 수 있습니다.
앞으로도 확장성이 핵심이에요. 더 쉽게 얹고, SDK를 더 유용하게 만들 겁니다. 코딩 에이전트를 만들 때도 좋고, 그 외의 임의의 에이전트를 만들 때도 그대로 쓸 수 있게요. 동시에 모델이 더 자율적으로 오래 동작하고, 지시 준수와 기억력이 향상될수록 전체 스택이 함께 이득을 보죠.에이전틱 코딩의 미래

알렉스:
6~12개월 뒤, 저는 Claude Code(혹은 그 변형)를 어떻게 쓰고 있을까요? 하루 종일 PR만 리뷰하나요? 일과가 어떻게 달라질까요?

보리스:
핸즈온 코딩은 남아 있을 겁니다. 다만 형태가 달라질 거예요. 지금의 ‘직접 텍스트 편집’이, 앞으로는 Claude를 통해 텍스트를 조작하게 하는 방식으로 바뀌겠죠. 동시에 Claude가 선제적으로 뭔가를 하고, 심지어 스스로 리뷰까지 한 결과를 사람이 승인/거절하는 비중이 커질 겁니다.
12~24개월 뒤에는 개별 작업(Task)보다 목표(Goal) 중심으로 추상화 레벨이 올라갈 거라고 봐요. 엔지니어가 한 달 목표를 세우고 작은 변화를 누적하듯, Claude도 비슷한 방식으로 움직이게 될 수 있어요. 파일 단위 변경 → PR 단위 변경 → ‘앱을 완성하라’ 같은 목표 단위로 올라가는 식으로요.에이전틱 코딩 시대에 어떻게 업스킬할까

알렉스:
그런 변화 속에서, 개발자는 무엇을 배우고 어떤 역량을 길러야 할까요?

보리스:
다시 제 초등/중등 시절 얘기로 돌아가 볼게요. 저는 투명한 회색 TI-83 플러스를 썼고, BASIC으로 작은 해킹을 했죠—시험 답을 계산기에 넣어두는 식으로요. 즉시 수정→바로 실행되는 짧은 피드백 루프가 주는 짜릿함이 있었어요. 그 덕에, 예전엔 상상도 못 한 것들을 쉽게 만들 수 있었죠.
그런데 에이전틱 코딩 이전의 세상은 스택이 너무 복잡해졌어요. 단순히 자바스크립트로 웹사이트를 만들고 싶어도 React, Next.js, 빌드 시스템 셋, 배포 시스템까지 알아야 했죠. 에이전트는 이 허들을 낮춥니다. 아이디어가 중심이 되고, 구현 디테일은 에이전트가 메꿔 주는 비중이 커져요. 코드는 더 이상 ‘신성불가침’이 아니라, 필요하면 여러 번 갈아엎을 수 있는 재료가 됩니다. (우리 팀도 Claude Code를 자주 리라이트해요.)
그렇다고 ‘공부하지 않아도 된다’는 뜻은 아니에요. 기초 체력—언어, 컴파일러/런타임, 웹앱 빌드, 시스템 디자인—은 여전히 필수입니다. 다만 그 위에 창의성을 얹으세요. 스타트업 아이디어나 제품 아이디어가 있으면 이제는 정말로 바로 만들어볼 수 있어요. 그 파급력은 아직 다 이해하지 못했지만, 곧 엄청난 잠재력이 열릴 겁니다.Claude Code 팁 & 베스트 프랙티스

알렉스:
마무리로, Claude Code 창시자로서의 모범 사용 팁을 알려주세요.

보리스:
두 가지를 권합니다.

1) 처음엔 ‘코드 생성’부터 시작하지 마세요.
이상하게 들리겠지만, 스스로를 말려야 합니다. 처음에는 코드베이스에 대한 질문부터 하세요. “로거를 새로 추가하려면 어디를 봐야 하지?”, “이 함수 설계는 왜 이렇게 됐지?” 같은 것들요. Claude Code가 리포를 탐색하고, Git 히스토리까지 훑어 답을 내게 하세요. 이 패턴에 익숙해지면 그다음에 코드 작성을 맡기면 됩니다.

2) 작업 난이도에 따라 사용하는 모드를 달리하세요.
대략 ‘쉽다/보통/어렵다’로 나눠요.

• 쉬운 작업: 한 번의 프롬프트로 거의 완성될 것들. 저는 깃허브 이슈에 @Claude를 멘션해서 PR을 통째로 쓰게 합니다. 터미널을 안 잡아먹고 자동화하기 좋아요.
• 중간 난이도: 터미널에서 Plan 모드(Shift+Tab) 로 먼저 계획을 정렬(alignment)하고, 합의가 되면 Auto-accept로 실행시킵니다.
• 어려운 작업: 사람이 운전석에 앉고 Claude는 페어 파트너로 씁니다. 코드 리서치, 아이디어 프로토타입, 경계 탐색(vibe-coding) 등을 Claude에 보조시켜도, 실제 구현은 제가 주도하죠. 단위 테스트 정도는 Claude에게 맡길 수 있습니다.

핵심은 작업의 성격에 맞춰 에이전트를 배치하는 거예요.
알렉스:
멋진 팁이네요. 고마워요, 보리스.
보리스:
감사합니다, 알렉스.

번역 메모 (용어 선택)

• Agentic coding: 에이전틱 코딩 또는 에이전트 중심 코딩
• Harness: 하네스(테스트 하네스/스캐폴딩 포함 의미로 사용)
• Scaffolding: 문맥에 따라 스캐폴딩/보조 프레임워크
• Inner loop: 인너 루프(개발자의 핵심 반복 루프)
• MCP: Model Context Protocol (원문 표기 유지)
• Slash commands / Subagents: 슬래시 커맨드 / 서브 에이전트
• Dogfooding: 내부 실사용(도그푸딩)
• Vibes: 체감/감(바이브)
• Cook for 30 minutes: 자율로 오래 굴려본다는 은유적 표현으로 자연화