Claude Code 팀은 Claude Code를 이렇게 쓴다

Executive Summary

Claude Code 팀 3인(Thariq Shihipar·Sid Bidasaria·Robert Boyce)이 자기 팀이 실제로 Claude Code/Claude Tag(Slack 상주 에이전트)를 어떻게 쓰는지 대담한 인터뷰. 핵심 축: 개별 tool call을 감독하던 시절에서 "목표만 던지는" 시절로의 전환, 2개월 단위로 뒤집히는 모델 기술 위에서 제품을 짓는 법, 로컬 랩톱→원격 호스트 박스→Claude Code on the web→루틴으로 이어진 실행 환경의 진화, 코드리뷰에서 파생된 fan-out/워크플로 아키텍처, Claude Tag 자체를 Claude Tag로 만드는 자기호스팅 개발 루프, 그리고 이 변화 속에서 개인적으로 잃은 것들.

목표 위임: tool call 감독에서 goal 위임으로

1년 전 Claude Code는 프롬프트→피드백→퍼미션 승인의 반복이었다. 지금은 다르다. Thariq: 이제 업무 대부분을 Claude Tag(Slack 안의 Claude)로 처리하며, 맡기는 문제 자체가 "이 클래스를 구현해라/이 함수를 써라" 수준을 훨씬 넘어 "세상 더 복잡한" 수준이 됐다. Claude Tag가 Slack에 상주하는 것은 이와 결이 맞는다 — 팀이 내린 제품 결정, 왜 이렇게 만들기로 했는지 같은 컨텍스트를 스스로 찾아볼 수 있어 판단력이 좋아진다는 것.

"70에서 80%의 업무가 이제 Claude Tag에서 일어난다. 나머지 20%는 TUI나 데스크톱 앱을 열어서 뭔가를 다듬거나, 내 Claude들을 마이크로매니징하고 싶을 때다." — Sid Bidasaria

Sid는 이 전환을 "트랜스크립트 하나하나, tool call 하나하나를 신경 쓰던 것"에서 "줌아웃된 관점 — 목표가 있고 그 목표를 모델에게 달성해달라고 맡기는 것"으로의 이동이라 요약한다. Claude Code에서 축적한 프리미티브들이 결국 Claude Tag로 수렴해 검증(verification)·코드리뷰·브레인스토밍·모니터링까지 다 이 위에서 돈다.

2개월마다 바뀌는 기술 위에서 제품을 짓기

Sid: "제품이든 그 밑의 기술이든 항상 shelf life가 있다. 예전엔 그게 수년 단위였다 — '이 제품을 만들면 몇 년은 갈 거다'라고 확신할 수 있었다. AI 모델은 기술 자체가 2개월마다 근본적으로 바뀐다. 어쩌면 시간이 갈수록 그 주기가 더 압축되고 있는 것 같기도 하다." 그래서 프런티어에 서 있어야 하고, 실은 그 경계 너머까지 가봐야 그 edge를 체감할 수 있는데, 동시에 지금 모델을 쓰는 사람들에게 지금 가치를 줘야 한다 — "part art, part science"인 줄타기.

"처음 '파도를 제대로 탔다'는 느낌을 받은 게 아마 to-do list였다. Sonnet 3.5 즈음, 모델이 장기 과업을 전혀 못 했다 — 다섯 개를 시키면 세 개 하고 포기했다. 그래서 to-do 리스트를 줘보자 했고, 정말 잘 먹혔다. 딱 그 순간에 필요한 바로 그것이었다. 근데 1년 뒤엔 사라졌다 — 더 복잡한 메모리 상태들이 그걸 대체해서 to-do 리스트가 더는 필요 없어졌다." — Sid Bidasaria

여기서 얻은 원칙: "짓고 있는 것에 너무 집착하지 말아야 한다. 금방 사라질 것이기 때문이다." 하니스에 박아 넣는 기능들 다수는 사실 현재 모델의 실패 모드를 가리기 위한 것이고, 모델이 좋아지면 그 기능은 더 이상 필요 없어져 걷어낼 자유가 생긴다. 대신 균형추로, Claude Code로 처리하는 과업 자체가 점점 더 크고 어려워지므로 모델이 그 규모에서 일관성을 유지하려면 어떤 도구가 필요한지가 계속 바뀐다. Robert는 Claude Code 팀의 특이점으로 "모델을 아주 바짝 따라가야 한다"는 점을 꼽는다 — 퍼미션 시스템을 다시 쓰고 아티팩트를 만드는 동시에 완전히 새로운 프로액티브 에이전트를 위한 소규모 팀을 꾸려야 하는 식. "우리는 소프트웨어 개발이 어디로 가는지를 보여주는 일종의 hyperbolic time chamber다." 대부분의 제품은 이렇게 짧은 shelf life를 갖지 않지만, 엔지니어라면 어차피 역량이 어디로 가는지 이해해야 하고, 제품 쪽에서도 그걸 최대한 돕는다.

AskUserQuestion에서 아티팩트로

Sid가 AskUserQuestion 툴을 만들 당시 회고: Claude가 대화형이길 원했고, 처음엔 planning 단계 뒤에 붙여놨다가 "잠깐, 그냥 모델이 부를 수 있는 tool로 만들면 어떨까"로 바뀌었다. 툴 설계에 오래 걸렸고, Claude가 그 툴을 잘 호출하게 만드는 것 자체가 어려웠다. 결국 설계를 끝내자 모델이 그 툴 호출을 금세 아주 잘하게 됐다.

"최근엔 그 툴을 그다지 안 쓴다. 그냥 아티팩트를 만든다. 그 아티팩트가 나한테 질문을 한다 — HTML로, 다이어그램과 목업까지 들어간 채로. 그게 일어난 속도가 놀랍다. 툴이 겨우 되던 수준에서 지금은 되는 수준으로." — Sid Bidasaria

이 팀의 작업 방식 자체가 "퍼미션은 어떻게 동작하는가, 시각화는 어떻게 동작하는가" 같은 프리미티브들을 먼저 만들고, 그것들이 서로 층층이 쌓이게 두는 것이라고 정리한다.

루틴: 랩톱 → 원격 호스트 박스 → Claude Code on the web → 루틴

Sid가 회고하는 loops의 기원 서사. 처음엔 모든 걸 랩톱에서 로컬로 돌렸다 — 퇴근하려고 랩톱을 끄면 "에이전트가 더는 안 돌아간다"는 게 싫었다. (랩톱을 켜놓고 갈 순 없었냐는 질문엔 "그럴 수야 있지만 주차장까지 들고 가야 하고 사람들이 이상하게 쳐다본다"고 농담.) 그래서 사내 원격 호스트 개발자 박스를 쓰기 시작했다 — 랩톱을 항상 켜둘 필요가 없어졌지만, 그마저도 매번 ssh로 들어가 호스트 서피스로 돌아와야 해서 불만족스러웠다. 그다음 나온 게 Claude Code on the web — 백그라운드에서 계속 돌아가는 호스트 컨테이너. 다만 초기엔 컨테이너에 개발 환경 접근권을 주는 설정 자체가 꽤 번거로웠다. "완전히 그럴 가치가 있었다. 그걸 도입한 뒤로 생산성이 10배는 늘었다고 본다."

로컬→클라우드로 옮겨가자 "매일 들어오는 피드백을 전부 보고, 중요도별로 버킷을 나누고, 확신이 높은 것만 고쳐라" 같은 루틴이 가능해졌다. 이게 Boris가 자주 언급하는 "loop journey" — 세션 안에서 모델에게 프롬프트하는 것에서, 세션이라는 경계 자체를 깨고 그보다 한 단계 위의 것을 프롬프트하는 것으로, 그리고 그게 알아서 버그를 고치거나 시킨 일을 처리하는 것으로.

코드리뷰가 다이내믹 워크플로를 낳은 경위

코드가 더 많이(더 빨리) 생성되는데 사람 업무가 "코드 리뷰하기"가 되는 걸 원치 않는다는 문제의식에서 출발. 팀은 이미 코드리뷰 봇을 운영 중이다. Robert가 짚는 큰 변화: 전통적 인간 코드리뷰에서는 리뷰어가 코드를 훑고 "작은 지적 세 개" 정도를 남기는 게 흔했는데, 그건 사실 "내가 이 코드를 제대로 읽었다"는 신호 보내기에 가까웠다. 이제 그런 사소한 것들은 Claude가 알아서 찾아 자율적으로 고치게 할 수 있으므로, 그게 더 이상 인간 코드리뷰의 핵심이 아니다.

"이제 중요한 건 더 큰 그림을 이해하는 것이다 — 이 API가 왜 이렇게 구조화돼 있는지, 서비스 경계가 왜 이 지점에 그어졌는지 같은, Claude가 PR을 쓸 때 완전히 내재화하지 못했을 수도 있는 이유들. 그런 정보를 코드리뷰에 끌어와 인간에게 넘겨주는 게 Claude가 할 수 있는 정말 가치 있는 일이다 — 한 줄 한 줄 읽으면서 사소한 걸 지적하는 데 끌려들어가지 않고, 인간 리뷰어가 생각하는 추상화 층위 자체를 끌어올려준다." — Robert Boyce

코드리뷰는 팀이 처음으로 대규모 fan-out을 한 사례였다 — "모든 버그를 어떻게 찾을까"를 위해 크게 fan-out한 뒤 결과를 coalesce하는 것, 이게 그들이 부르는 test-time compute(문제에 많은 추론 시간·연산을 쏟아붓는 것). 이게 그대로 워크플로(Sid가 구축)로 이어졌다. 구체적 커스텀 하니스: Claude에게 fan-out해서 버그를 찾게 하고, 찾은 버그마다 3가지 다른 관점/의견으로 그게 진짜 버그인지 적대적으로(adversarial) 재검토시킨다 — 이렇게 버그를 걸러내 정말 주의가 필요한 것만 남긴다. 이 패턴은 코드리뷰에 국한되지 않는다 — 성능 버그/성능 이슈에도, 범용 딥리서치에도 같은 기법을 쓸 수 있다(예시: "부모님 모시고 타호 여행 갈 곳 찾기"도 fan-out으로 도움이 된다).

Sid: "Claude는 자기 하니스를 스스로 아주 잘 만든다" — fan-out이 어떤 모양이어야 하는지, 토폴로지가 어때야 하는지, 한 에이전트의 출력을 다음 레벨로 어떻게 배선할지, 마지막에 어떻게 요약해서 돌려줄지를 스스로 파악한다. 타호 여행 예시 상세: 타호/배스하우스 타호/호텔 타호/에어비앤비 등 열 개 서로 다른 검색을 fan-out으로 던지고, 결과를 정렬·선별하는 에이전트, 그걸 검증하는 에이전트가 붙어 최종 결과를 준다. Thariq는 이를 "MapReduce 문제"라 부른다 — fan-out을 한번 하면 정보량이 너무 많아져서("fan-out 결과를 그대로 다 읽으면 미쳐버릴 것") 다시 사람이 소비할 수 있게 필터링해서 되돌려야 하고, 그 신뢰를 쌓는 방법은 결국 그 문제에 test-time compute를 더 던지는 것이다.

"워크플로에서 정말 흥미로운 또 다른 점은, 에이전트가 서브에이전트들을 오케스트레이션할 코드를 직접 작성한다는 것 — 결정론적(deterministic)인 코드로 정의된 동작과 에이전틱한 LLM 동작이 뒤섞인 멋진 조합이다. Claude가 반복 작업을 위한 워크플로를 쓸 때, '여기 이 아이템들을 순회할 for 루프가 있다'는 걸 보면 신뢰가 올라간다 — 그 for 루프가 아이템 하나를 건너뛰지 않고 모두에게 동일한 기법을 적용할 거라는 걸 아니까." — Sid Bidasaria

Claude Tag로 Claude Tag를 만들기: Slack 안의 검증·피드백 루프

Robert Boyce가 현재 Claude Tag를 빌드 중이며, Claude Tag를 만드는 데 Claude Tag를 "아주 공격적으로" 쓰고 있다고 밝힌다. Robert의 초점은 Claude Tag가 스스로를 개발하는 데 막힘이 없도록 하는 것 — 개발 환경과 dev loop를 Claude가 쓰기 쉽게 만들어서, 인간이 소프트웨어를 만들고 엔드투엔드로 테스트할 때 해야 하는 모든 일을 Claude가 대신 할 수 있게 하는 것. 소프트웨어가 더 복잡하고 통합적으로 커질수록 이 작업은 더 어려워진다.

이번이 처음으로 UI가 트랜스크립트에서 완전히 분리된 경우다 — 실제로 Claude가 출력하는 토큰 그 자체보다 한 단계 위의 추상화 층위에서 작업하게 됐다는 것. Slack에서 Claude Tag의 메시지를 볼 때, 그건 Claude가 그 메시지를 당신에게 보내기 위해 "툴을 호출"한 것이다 — 내부 독백(internal monologue)은 Slack에서 보이지 않는다. 전체 트랜스크립트를 볼 수 있는 링크는 있지만, 주된 UI는 메시징 툴 자체다.

"그 추상화는 처음엔 좀 무서웠다 — '어, Claude가 뭘 생각하고 있는지 실시간으로 다 볼 수가 없잖아.' 하지만 동시에 정말 해방감을 줬다 — Claude가 나한테 무엇을 언제 말할지 스스로 고르고, 나는 그게 어떤 툴을 부르는지, 어떤 파라미터를 보내는지 세세히 신경 쓰지 않게 됐다. '렛 클로드 쿡(let Claude cook)'을 반강제로 하게 된 셈이고, 트랜스크립트를 세세히 감독하지 않아도 좋은 결과가 돌아오는 걸 보면서 모델이 이제 정말 충분히 좋아졌다는 걸 확인하는 강제 함수가 됐다." — Robert Boyce

Robert에게 Claude Tag가 최근 "정말 딱 맞아떨어진(clicked)" 순간: 새 툴을 개발하며 사람들의 동의(buy-in)가 많이 필요했는데, 먼저 Claude Tag에게 "이 아이디어를 생각 중인데 누구한테 얘기하면 좋을까"를 물어 이해관계자를 찾고, 목업을 Slack 안에서 만들어(휴대폰으로도 볼 수 있게) 구현까지 시켰다. 그 구현이 실제로 먹히는지 몰라 이벤트(계측)를 많이 붙이고 사내 배포해 사용 양상을 지켜봤는데, Claude Tag가 그걸 대신 모니터링해주며 누가 피드백을 주면 태그해줘서 더 빠르게 반응하고 더 높은 확신을 가질 수 있었다. 이후 퍼널을 개선하려 할 때도, 처음엔 자기 아이디어를 직접 구현시키려다가 "잠깐, Claude에게 퍼널을 개선할 아이디어를 내보라고 하자, 내 아이디어는 예시로만 주자"로 바꿨고, 이렇게 더 높은 레벨에서 함께 일하는 방식이 "정말 딱 맞아떨어졌다."

Thariq는 이걸 검증(verification)·코드리뷰·피드백 수집이라는 세 가지 프리미티브가 결합된 사례로 정리한다 — 데이터 스토어/이벤트 스토어(메트릭, Slack, GitHub 이슈 등)에 연결하는 것이 전부 Claude Code의 프리미티브다. 검증은 특히 중요하다고 강조된다 — 팀이 검증에 많은 주의를 기울여왔고, Claude가 Claude Code용 PR을 만들 때 직접 테스트하고 실제로 어떻게 보이는지 스크린샷을 보내준다. 이게 확신을 만든다. Robert 본인은 검증할 때 먼저 Claude에게 TUI로 스스로 녹화하게 시켰고, 그 후에는 "만약을 위해서" 직접 클론해서 본인이 써봤다고 밝힌다 — 다만 "결국엔 그마저도, 클론조차 안 하고 Claude에게 맡기게 될 것 같다"고 전망한다.

옛 소프트웨어 엔지니어링 방식에서 그리운 것

지난 1년을 돌아보면 Claude Code에서 시작해 auto mode·memory·workflows 같은 프리미티브들이 계속 얹어졌고, 개발자로서 챙겨야 할 게 계속 늘었다("이게 다 뭐지?"). 요즘 소프트웨어 엔지니어의 어려운 부분은 오히려 "마음을 비우는 것" — 뒤로 물러나 더 크게 생각하는 것이라고 짚는다.

한 화자(성능 엔지니어링에 기쁨을 느끼던)는 시스템에 깊이 파고들어 성능을 올리는 일에서 즐거움을 얻었었는데, 이제는 Claude가 그 일을 자신보다 훨씬 잘한다고 인정하면서도 그 성능 개선의 결실은 여전히 누린다고 말한다. 대신 관심의 초점이 "새 아이디어를 더 빨리 만들어내는 것"으로 옮겨갔다 — 아이디어에서 프로토타입, 프로토타입에서 프로덕션까지 가는 속도가 훨씬 빨라졌고, 그만큼 새 아이디어와 그걸 얼마나 빨리 구현하느냐에 더 많은 주의를 쏟게 됐다. 깊이 파고드는 마스터리에서 더 줌아웃된 패러다임으로 옮겨간 셈이다.

"개인 웹사이트에 맥 OS 10.4 아쿠아(Aqua) 버튼을 초정밀 CSS로 재현한 적이 있다 — 방사형 그라디언트 레이어를 정확히 쌓느라 하루쯤 썼다. 그런 종류의 일은 이제 'Claude가 그냥 해줄 수 있는' 일이 됐고, 이젠 그걸 손수 하러 가는 일은 없을 것 같다." (UI 디자인 디테일을 좋아한다고 밝힌 화자)

이 화자는 이게 일곱 살 여덟 살 무렵으로 자신을 데려갔다고 말한다 — 그땐 비디오게임을 정말 만들고 싶었지만 코딩을 몰라서, 대신 파워포인트로 클릭 가능한 것들과 도형을 그려 만들었다("그 나이에 내가 쓸 수 있던 도구였다"). 지금 Claude는 소프트웨어 엔지니어링 전체를 자신에게 접근 가능하게 만들어준다고 말한다 — 어떤 아이디어든 "기술이 없어서 못 한다"고 할 필요 없이, "이걸 이루고 싶다"고 말하고 그걸 쪼개 Claude와 함께 어떻게 해낼지 찾아가면 된다는 것. "소프트웨어 엔지니어링이라는 영역 안의 모든 것이 이제 내 손이 닿는 곳에 있다는 게 정말 신난다."

마무리 정리: 소프트웨어 엔지니어링은 "변화의 직업"이다 — 10~20년 전엔 프레임워크 없이 자바스크립트를 손으로 짜다가 프레임워크와 컴파일러를 발명했고, 지금은 그 속도가 더 빨라졌을 뿐 본질은 같다 — "이런 도구들을 어떻게 써서 더 훌륭한 소프트웨어를 계속 더 많이 만들어내는가"라는 문제 해결(problem solving) 그 자체라는 것.

영상 정보

원본 (완역)

번역

이 인터뷰는 Anthropic 공식 Claude 유튜브 채널에 2026년 9월 2일 올라온 것으로, Claude Code 팀의 세 사람 — Thariq Shihipar(진행), Sid Bidasaria, Robert Boyce — 가 한자리에 모여 팀이 일상에서 Claude Tag, 목표 위임, 워크플로를 어떻게 쓰고 있는지 나눈 대화다. 아래는 22분 23초 분량 전체를 빠짐없이 한국어로 재구성한 것이다.

0:00 — 인트로

Thariq: "내년에 대해 어떤 생각들 있어요?"라고 인터뷰를 연다. Sid는 웃으며 두 달 뒤조차 가늠하기 힘든데 1년 뒤는 더더욱 어렵다고 답한다. 그러다 문득, 자신이 Claude Code 팀에 합류한 지 거의 1년이 됐다는 사실을 떠올린다. 1년 전만 해도 Claude Code에게 프롬프트를 주고, 피드백을 주고, 권한 요청(permission prompt)을 하나하나 수락해주던 게 전부였는데, 지금 여기까지 온 게 믿기지 않는다고 말한다.

0:35 — Claude Tag로 일하기: 툴 호출에서 목표로

Thariq: "그래서 — 요즘 Claude Code랑 어떻게 일하고 있어요?"

Sid: 요즘은 업무의 상당 부분을 Claude Tag를 통해 처리하고 있다고 답한다. Claude Tag에 맡기는 문제들은 예전보다 차원이 다르게 복잡하고 도전적이다 — Claude Code 초창기의 "이 클래스를 구현해줘", "이 함수를 작성해줘" 수준과는 완전히 다르다는 것.

Robert: 이건 Claude Tag가 Slack 네이티브 에이전트로 설계된 것과 잘 맞아떨어진다고 덧붙인다. Slack 안에 살고 있기 때문에 "이 제품에 대해 우리 팀이 어떤 결정을 내렸는지" 같은 추가 맥락을 직접 찾아볼 수 있고, 그 정보를 판단에 반영할 줄 알아서 의사결정의 질이 훨씬 좋아진다고 말한다.

Sid: 자기도 비슷하다며, 이제 업무의 70~80%는 Claude Tag 위에서 이뤄지고, 나머지 20% 정도만 TUI나 데스크톱 앱을 열어서 뭔가를 다듬거나, 혹은 Claude들을 세세하게 관리(micromanage)하고 싶을 때 쓴다고 말한다. 예전에는 트랜스크립트 하나하나, 툴 호출 하나하나, 모델이 내리는 개별 결정 하나하나를 다 신경 썼다면, 지금은 훨씬 줌아웃된 시야로 — "나에게는 목표가 있고, 이 목표를 달성하고 싶다"는 식으로 목표 자체를 모델에게 던져주고 그걸 대신 달성하게 만드는 쪽으로 옮겨갔다고 회고한다. 그리고 이 변화 자체가 소프트웨어 개발 생애주기(SDLC)가 얼마나 많이 바뀌었는지를 보여주는 것 같다고 말한다 — Claude Code를 만들고, 서로 맞물리는 여러 primitive를 만들고, 그게 결국 Claude Tag로 수렴해서 검증부터 코드 리뷰, 브레인스토밍, 모니터링까지 다 해내게 된 과정에서 얻은 교훈들이라는 것.

2:17 — 두 달마다 바뀌는 기술 위에서 제품 만들기

Thariq: Claude Code에서 일하는 게 예전에 만들던 다른 소프트웨어 제품들과 비교해서 어떤지 묻는다.

Sid: 어떤 제품이든 기술적 유효기간(shelf life)이 있기 마련인데, 예전엔 그 유효기간이 보통 몇 년 단위였다고 답한다. "이 제품을 만들면 몇 년, 혹은 그 이상은 갈 거야"라는 확신을 가질 수 있었다는 것. 그런데 AI 모델은 다르다 — 기술 자체가 밑바닥부터 두 달마다 근본적으로 바뀐다. 게다가 시간이 갈수록 그 주기가 더 짧아지는 것 같기도 하다고 덧붙인다. 그래서 어려운 지점은, 계속 프런티어(frontier)에 머물러야 하고 사실상 그 프런티어를 넘어서야 그 가장자리를 체감할 수 있다는 것이다. 동시에 지금 당장 모델을 쓰는 사람들에게 지금 이 순간의 가치를 제공해야 한다. 그래서 이건 일종의 균형잡기이고 예술 반 과학 반인 일 — 밑에서 이렇게 빠르게 움직이는 기술 위에 어떻게 제품을 지을 것인가 하는 문제라고 말한다.

Thariq: 그 파도를 제대로 탔다고 느낀 순간이 있었는지 묻는다.

Sid: 처음으로 "파도를 탄다"는 느낌을 받은 게 아마 to-do 리스트였을 거라고 답한다. 그게 대략 Sonnet 3.5 시절이었는데, 당시 모델들은 긴 호흡의 작업(long horizon work)을 전혀 해내지 못했다 — 할 일 다섯 개를 주면 세 개만 하고 포기해버리는 식이었다. 그래서 "할 일 목록을 줘보면 잘 하지 않을까?" 하고 시도했는데, 정말 잘 해냈다. "와, 지금 이 순간에 딱 필요한 게 바로 이거다" 싶었다고 한다. 하지만 1년쯤 지난 지금은 그 to-do 리스트가 사실상 사라졌다 — 더 이상 필요가 없어졌다. 더 복잡한 메모리 상태(memory state) 같은 걸 이제 믿고 쓸 수 있게 됐기 때문이다. 이게 바로 "만들고 있는 것에 너무 집착하면 안 된다"는 걸 보여주는 완벽한 예시라고 말한다 — 만든 것들은 꽤 빨리 사라지게 마련이니까. Claude Code 하네스(harness)에 이런 기능들을 만들어 넣는 이유 중 많은 부분이 지금 모델이 가진 실패 모드(failure mode)들을 커버하기 위한 것이고, 모델이 좋아질수록 "어, 사실 이 기능들 이제 필요 없네, 없애도 되겠다"고 말할 수 있는 자유가 생긴다. 그리고 그걸 상쇄하는 건, 이제는 Claude Code에서 훨씬 더 크고 도전적인 작업을 하고 있다는 것 — 모델이 그 더 큰 작업에서도 일관성(coherent)을 유지하며 잘 해내려면 어떤 도구가 필요한지, 그리고 작업의 스코프가 바뀔수록 필요한 도구도 점점 다르게 생기기 시작한다는 것.

"만들고 있는 것들에 너무 집착하면 안 된다. 어차피 꽤 빨리 사라지게 마련이니까." — Sid

Robert: 사람들이 자주 "Claude Code 팀은 대체 어떻게 일하나요?"라고 묻는다며, 팀만의 독특한 점 하나는 모델을 정말 바짝 따라잡아야(keep up) 한다는 것이라고 말한다. 그래서 가끔은 아주 빠르게 큰 변화를 만들어야 한다 — "어, 모델이 이제 이렇게 좋아졌으니 완전히 새로운 proactive agent를 만들어야겠다"는 식으로, 그것도 작은 팀이 해내야 하는데, 동시에 권한(permission) 시스템을 다시 쓰고 아티팩트(artifacts) 같은 것도 만들고 있는 중이라는 것. 그래서 어떤 면에서는 팀 자체가 소프트웨어 개발이 앞으로 어디로 가는지를 미리 보여주는 "하이퍼볼릭 타임 챔버(hyperbolic time chamber)" 같다고 말한다. 대부분의 제품은 이렇게 짧은 유효기간을 갖지도, 이렇게까지 최전선을 따라잡아야 하지도 않을 것이다.

화자 미상: 그래도 엔지니어라면 어느 정도는 이런 걸 해야 하는 게 맞다 — 능력이 어디로 향하고 있는지 스스로 이해해야 한다는 데 동의하며, 물론 제품을 통해 최대한 그걸 도와주려 하지만, 동시에 Claude에 대한 자기만의 멘탈 모델을 계속 업데이트하는 것도 좋은 일이라고 덧붙인다.

4:48 — Claude Code 팀은 Claude Code를 이렇게 쓴다: AskUserQuestion, 아티팩트, Claude Tag

Thariq: AskUserQuestion 툴을 추가했을 때도 "파도를 타는" 또 다른 사례였다며, 그 툴을 만들 때 무슨 생각을 하고 있었는지 묻는다.

Sid: Claude가 상호작용(interactive)하길 원했다고 답한다. 처음엔 플래닝(planning) 뒤에 붙이는 방식으로 만들었다가, "어, 잠깐, 그냥 호출할 수 있는 툴로 만들면 어떨까?" 하는 생각이 들었다고 한다. 그 툴을 디자인하는 데 시간이 정말 오래 걸렸다 — Claude가 그 툴을 잘 호출하게 만드는 게 정말 어려웠고, 결국 다시 디자인해서 잘 작동하게 만들었다. 그런데 그렇게 잘 호출하게 되기 시작하자마자, 최근에는 오히려 그 툴 자체를 예전만큼 쓰지 않는다고 말한다 — 대신 그냥 아티팩트를 하나 만들고, 그 아티팩트가 자신에게 질문을 던지게 한다는 것. HTML로 되어 있고, 다이어그램이나 목업(mockup) 같은 것도 들어간다. "이게 이렇게 빨리 일어났다는 게 신기하다"고 말한다 — 툴이 거의 못 하던 수준에서 지금은 할 수 있는 수준으로. 그리고 이런 일이 Claude Code 안에서 꽤 자주 일어나는 것 같다고 덧붙인다. 팀이 일하는 방식은, 이런 primitive들을 만드는 것 — "권한은 어떻게 작동하는가", "시각화(visualization)는 어떻게 작동하는가" 같은 것들을 하나하나 만들고, 그것들이 나중에 서로 층층이 맞물린다(layer together)는 것.

6:41 — 루프와 루틴을 원격으로 돌리기

Thariq: 루프(loops)에 대해 얘기해달라고, 어떻게 쓰고 있는지 묻는다.

Sid: 루프에 도달하기까지의 여정을 짚어보는 게 흥미롭다며 이야기를 시작한다. 예전엔 모든 걸 자기 노트북에서 로컬로 돌렸는데, 어느 시점엔 사무실에서 퇴근해 집에 가야 했다. 그래서 노트북을 꺼야 했고, "아, 짜증나. 내 에이전트가 더는 안 돌아가네" 싶었다고 한다.

Thariq: 장난스럽게 "그냥 켜두고 가지 그랬어요?" 하고 묻는다.

Sid: 그렇게 할 수도 있었지만, 그러면 노트북을 들고 주차장까지 가야 했고 사람들이 자길 이상하게 쳐다봤을 거라고 농담을 섞어 답한다. 그래서 대신 회사의 원격 호스팅 개발자 박스(remote hosted developer box)를 쓰기 시작했다 — 노트북을 항상 켜둘 필요가 없어졌고, 호스팅된 환경에서 계속 돌아가니 자기 할 일을 할 수 있었다. 하지만 이것도 완전히 만족스럽진 않았다 — 결국 SSH로 그 환경에 접속해서 호스팅된 화면으로 다시 돌아가야 했으니까. 그래서 등장한 게 웹 버전의 Claude Code였다 — 백그라운드에서 계속 돌아갈 수 있는 호스팅 컨테이너. 그런데 이것도 처음엔 시작하기가 좀 까다로웠다 — 컨테이너가 개발 환경을 호스팅하려면 그 컨테이너에 개발 환경 접근 권한을 줘야 하는데, 그 셋업 자체가 좀 번거로웠다는 것. 그래도 그만한 가치는 충분했다고 — 그걸 한 이후로 자기 생산성이 10배(10x)는 늘었다고 말한다. 그게 바로 "Claude가 로컬에서 돌던 시절"에서 "Claude가 클라우드에서 돌아야 하는 시절"로 넘어온 기원 이야기다. 그리고 클라우드에서 돌아가게 되니 정말 흥미로운 일들을 할 수 있게 됐다 — 예를 들어 루틴(routine)을 만들어서, 매일 들어오는 피드백을 전부 살펴보고, 중요도별로 버킷(bucket)으로 나누고, 확신이 높은(high confidence) 것들은 알아서 고치게 할 수 있다. 이게 바로 Boris가 자주 이야기하는 "루프 여정(loop journey)"이라고 말한다 — 한 세션 안에서 모델에게 프롬프트를 주는 것에서, 그 세션이라는 경계 자체를 깨고 한 단계 위에서 뭔가를 프롬프트하는 것으로 넘어가는 과정. 그러면 그게 알아서 버그를 고치거나 당신의 일을 대신 처리해주게 된다.

8:52 — 코드 리뷰가 일깨운 동적 워크플로

Thariq: 코드 리뷰와 보안 얘기를 더 하고 싶다고 말한다 — 코드를 훨씬 더 많이 쓰게 되고 더 많은 코드가 생성되는 상황에서, 우리 일이 "코드 리뷰하기" 자체가 되어버리는 건 원치 않는다는 것. 지금은 코드 리뷰 봇이 있긴 하지만, 팀 안에서 코드 리뷰가 실제로 어떻게 바뀌었고 지금 어떻게 하고 있는지 묻는다.

Robert: 큰 변화 하나는, Claude가 사람 리뷰어들이 자기 시간과 에너지를 어디에 쓸지 고르는 걸 정말 잘 도와준다는 것이라고 답한다. 전통적인 사람 코드 리뷰에서 흔히 보던 패턴은 — 누군가 코드를 리뷰하면서 사소한 지적(nitpick) 서너 개를 골라서 남기는 것이었는데, 사실 그건 "내가 이 코드를 읽었다는 걸 당신에게 신호로 보내는" 행위에 가까웠다. "이게 내가 발견한 사소한 것들이야, 내가 진짜 꼼꼼히 읽었다는 걸 보여주려고" 정도였다는 것. 이제는 Claude가 그런 사소한 것들을 알아서 찾아내고 자율적으로 고쳐버릴 수 있다. 그래서 그게 더 이상 사람 코드 리뷰의 핵심이 아니게 됐다. 진짜 중요한 건 오히려 더 큰 그림을 이해하는 것 — 예컨대 Claude가 "왜 이 API가 이런 식으로 짜여 있는지", "왜 이 서비스 경계(service boundary)가 이 지점에 그어져 있는지" 같은, PR을 작성할 때 완전히 내면화하지 못했을 수도 있는 맥락을 사람이 채워주는 것이다. 그런 정보를 코드 리뷰에 끌어와서 사람에게 넘겨주는 게 Claude가 할 수 있는 정말 가치 있는 일이고, 이게 사람이 코드를 한 줄 한 줄 읽으며 사소한 트집을 잡는 데 빠지지 않게 해주면서, 사람 코드 리뷰어로서 생각하는 추상화 수준 자체를 한 단계 끌어올려 준다고 말한다.

Robert: 코드 리뷰가 팀이 처음으로 "거대한 팬아웃(fan out)"을 해본 지점이었다고 말한다 — "모든 버그를 어떻게 찾지?", "잠재적 버그를 어떻게 전방위로 검색하지?" 하는 문제. 이렇게 크게 팬아웃한 다음 결과를 하나로 모으는(coalesce) 것, 이게 바로 팀이 부르는 "테스트 타임 컴퓨트(test time compute)"다 — 추론(inference) 시간을 많이 써서 한 문제에 많은 사고와 연산을 쏟아붓는 방식. 그리고 이게 결국 워크플로(workflows)로 이어졌다며, Thariq에게 Sid가 워크플로를 어떻게 만들었는지 이야기해달라고 넘긴다.

Sid: 워크플로가 만들어진 데는 코드 리뷰가 큰 몫을 했다고 답한다. 거의 커스텀 하네스(custom harness)에 가까운 거대한 팬아웃 구조를 만들었는데 — Claude에게 나가서 버그를 찾아 팬아웃하라고 지시하고, 각 버그마다 세 가지 다른 관점(perspective)에서 그 버그를 적대적으로(adversarial) 재검토해서 그게 진짜 버그가 맞는지 확인하게 한다. 이렇게 하면 수많은 버그 후보들을 걸러내서 정말 주의를 기울여야 할 가장 중요한 것들만 남겨준다. 그리고 이건 코드 리뷰에만 국한되지 않는다 — 성능 버그나 성능 이슈에도 똑같이 쓸 수 있고, 범용적인 딥 리서치(deep research)에도 쓸 수 있다. 예를 들어 다음 주에 부모님을 모시고 타호(Tahoe)에 여행을 가는데 "어디서 묵어야 하나" 같은 걸 알아볼 때도, 이런 식으로 팬아웃을 돌리면 도움이 된다고 말한다. Claude는 사실 자기 자신만의 하네스를 만드는 데 정말 능하다 — 이 팬아웃이 어떤 모양이어야 하는지, 토폴로지(topology)가 어때야 하는지, 한 에이전트의 출력을 다음 단계로 어떻게 연결(wire in)해야 하는지, 그리고 마지막에 그걸 요약해서 돌려주는 것까지 스스로 알아낼 수 있다. 이게 그 이야기의 기원이라고 한다.

Thariq: 여행 계획을 예로 들며 확인한다 — 타호에 관해 열 개쯤 되는 서로 다른 검색 요청(bathhouse Tahoe, Hotel Tahoe, Airbnb 같은 것들)을 돌리고, 결과를 정리하는 에이전트, 가장 흥미로운 결과를 골라내는 에이전트, 그리고 그걸 검증하는 에이전트가 있어서 최종 결과물을 주는 거냐고 묻는다.

Sid: "정확히 그거다(Exactly)"라고 확인하며, 진짜 문제는 일단 팬아웃을 하면 정보가 너무 많아져서 그걸 다시 걸러내야 한다는 것 — 일종의 맵리듀스(MapReduce) 문제라고 말한다. 팬아웃된 결과를 그대로 읽으면 미쳐버릴 테니, 사람이 소비할 수 있게 다시 걸러내야 하고, 그러려면 확신을 쌓아줄 무언가가 필요하다. 그 확신을 쌓는 방법이 바로 이 문제에 테스트 타임 컴퓨트를 쏟아붓는 것이라고 한다. 워크플로에서 또 하나 흥미로운 점은, 에이전트가 서브 에이전트들을 오케스트레이션하는 코드를 직접 짜기 때문에, 결정론적인 코드로 정의된 동작(deterministic code-defined behavior)과 에이전틱한 LLM 동작이 섞이는 멋진 조합이 된다는 것. 그리고 이게 신뢰를 준다고 — 예를 들어 Claude가 반복문(iterate)을 도는 워크플로를 짤 때 "여기 이 항목들을 순회할 for 루프가 있다"고 하면, "아 그래, 이 for 루프는 항목 하나를 빼먹지 않을 거고, 이 모든 것에 똑같은 기법을 동등하게 적용할 거다"라고 믿을 수 있다는 것. 이게 정말로 자신의 신뢰를 크게 높여준다고 — "아, Claude가 여기서 내가 원하는 걸 정확히 하고 있구나"라는 확신이 생긴다는 것.

14:04 — Claude Tag로 Claude Tag 만들기: 검증과 Slack 피드백 루프

Thariq: Claude Tag 얘기를 하고 싶다며, Robert가 지금 Claude Tag를 만들고 있는 걸 안다고, 어떻게 쓰고 있는지 들려달라고 청한다.

Robert: 앞서 잠깐 언급했지만, 팀이 Claude Tag를 Claude Tag로 정말 공격적으로(aggressively) 만들고 있다고 말한다. 그리고 그게 사실 자신의 초점이었다고 — Claude Tag가 Claude Tag 자체를 개발하는 데 막힘이 없도록(unblocked) 만드는 것. 개발 환경과 개발 루프(dev loop)가 Claude에게 정말정말 쉬워지도록 만드는 것. 자신이 사람으로서 소프트웨어를 만들고 그게 엔드투엔드로 작동하는지 테스트하기 위해 해야 하는 모든 걸, Claude가 그대로 할 수 있게 만드는 것이다. 점점 더 복잡하고 촘촘하게 통합된(heavily integrated) 소프트웨어를 만들수록 이 일은 점점 더 어려워지기 때문에, Claude가 이걸 해낼 수 있게 만드는 게 자신의 큰 초점이었다고 말한다.

이번이 처음으로 사용자 인터페이스가 트랜스크립트로부터 훨씬 더 완전히 분리(decoupled)된 경우라고 짚는다. 즉 실제로 Claude가 내놓는 토큰들로부터 한 단계 떨어진 추상화 수준에서 일하고 있다는 것. Slack에서 Claude Tag가 보낸 메시지를 보면, 그건 그 메시지를 당신에게 보내기 위해 툴을 하나 호출한 것이다. 하지만 그 내부 독백(internal monologue)은 기본적으로 Slack에서는 보이지 않는다 — 전체 트랜스크립트를 볼 수 있는 링크는 있지만, 주된 사용자 인터페이스는 메시징 툴을 통한 것이다. 이 추상화는 처음엔 좀 무서웠다고 고백한다 — "어, Claude가 지금 뭘 생각하고 있는지 그 순간순간을 다 볼 수가 없네"라는 느낌. 하지만 동시에 정말 해방감(freeing)을 주기도 했다고 — Claude가 나에게 무엇을 언제 말할지 스스로 고르고 있고, 자신은 어떤 툴을 호출하는지, 그 툴에 어떤 파라미터를 보내는지 같은 세부사항을 신경 쓰지 않아도 된다는 것. 그리고 어떤 의미에서는 "그냥 Claude가 요리하게(let Claude cook) 둘 수밖에 없는" 상황으로 떠밀린 것이기도 하다고 말한다. 모델들이 이제 충분히 좋아져서, 트랜스크립트를 세세하게 감독하지 않아도 좋은 결과를 돌려받고 있다는 걸 체감하고 있다고 — 이게 일종의 강제 함수(forcing function)가 되어 "아, 이 모델들 지금 정말 좋아지고 있구나"를 깨닫게 해줬다는 것.

"어떤 의미에서는 그냥 Claude가 요리하게 두는 것 — 그게 강제 함수가 됐다." — Robert

Robert는 최근 Claude Tag가 제대로 "딸깍" 하고 와닿은(clicked) 경험을 들려준다. 새로운 툴을 개발하고 있었는데, 거기엔 사람들의 동의(buy-in)가 많이 필요했다. 그래서 처음 시도한 게 "이런 아이디어를 생각하고 있는데, 관심 가질 만한 사람이 누구일까?"라고 물어본 것이었다. 그러자 이해관계자들(stakeholder) 목록을 받았고, 그다음엔 목업(mockup)을 몇 개 만들었는데, 이 모든 게 Slack 안에서 이뤄져서 휴대폰으로도 볼 수 있었다. Claude Tag가 목업을 만들어줬고, 구현도 해줬다. 그런데 그 구현이 실제로 잘 작동하는지 확신이 없었던 터라, 여기에 이벤트(event)들을 잔뜩 추가했다. 그걸 내부에 배포하고 사람들이 어떻게 쓰는지 지켜봤다. Claude Tag가 그걸 대신 모니터링해줬고, "누가 피드백을 주고 있나?" 궁금할 때 바로 확인할 수 있었다. 누군가 피드백을 주면 Claude Tag가 자신을 태그(tag)해주니 더 빠르게 반응할 수 있었고, 그게 작동한다는 확신도 훨씬 높아졌다고 한다. 그리고 가끔은 이벤트를 들여다보다가 퍼널(funnel)의 일부를 개선하고 싶어졌다 — 사용자들이 끝까지 가지 않는 것 같았다는 것. 처음엔 "나한테 아이디어가 있으니 이 아이디어대로 해달라고 시켜야지" 했다가, 문득 "잠깐, 그냥 Claude에게 퍼널을 개선해달라고 부탁하자"는 생각이 들었다. 여기서 몇 가지 아이디어를 스스로 내보라고 하고, 자기 아이디어는 그중 하나의 예시로만 줄 수도 있다는 것 — 그렇게 더 높은 레벨에서 함께 일하고 싶었고, 그게 정말 "딸깍" 하고 와닿았다고 말한다.

Thariq: 이게 정말 좋은 지점들을 건드리고 있다고 짚어준다 — 사실상 검증(verification), 코드 리뷰, 그리고 피드백을 받는 것, 이 세 가지가 다 관련돼 있다는 것. 즉 데이터 저장소나 이벤트 저장소에 연결되어 피드백을 받는 것 — 어떤 식으론 메트릭(metrics)일 수도 있고, Slack일 수도 있고, GitHub 이슈일 수도 있다. 그리고 이 세 가지 모두 Claude Code의 primitive라고 짚는다.

Sid: "맞다(Yes)"고 동의하며, 검증이 정말 중요한 이유는 — 특히 자기 팀은 검증에 정말 많은 신경을 써왔다는 것이라고 말한다. 그래서 Claude가 Claude Code를 위해 PR을 만들어줄 때, 그걸 직접 테스트하고 어떻게 보일지 스크린샷까지 보내준다. 그러면 확신이 생긴다는 것.

Thariq: Robert에게, 그러면 검증을 요청할 때 TUI를 직접 열어본 적이 있는지 묻는다.

Robert: 처음엔 Claude에게 TUI를 써서 스스로 녹화(record)해보라고 시켰고, 그다음엔 "그래도 그냥 직접 한번 클론해서 써봐야겠다"는 생각이 들었다고 답한다 — 그저 마음의 안정을 위해서(just for sanity's sake), 적어도 자기가 한 번은 직접 확인해봤다는 걸 확실히 하고 싶었다는 것. 언젠가는 이마저도 없어질 것 같다고 — "결국엔 그냥 Claude에게 맡기고, 클론조차 하지 않게 될 것 같다"고 덧붙인다.

Robert: 지난 한 해를 돌아보면, Claude Code로 시작해서 auto mode, 메모리(memory), 워크플로 같은 여러 primitive를 하나씩 더해온 과정이었던 것 같다고 말한다. 개발자로서 챙겨야 할 게 정말 많았다 — "아니 이게 다 무슨 일이지" 싶을 정도로. 하지만 그건 어쩔 수 없이 해야만 하는 일이었고, 이게 요즘 소프트웨어 엔지니어라는 직업의 어려운 부분이라고 생각한다 — 마음을 비우고(freeing your mind), 한발 물러서서 더 크게 생각하는 것.

18:37 — 옛날 방식의 소프트웨어 엔지니어링에서 그리운 것

Thariq: 옛날 방식의 소프트웨어 엔지니어링에서 그리운 게 있는지 궁금하다고 묻는다.

Sid: 예전엔 성능 엔지니어링(performance engineering)에서 큰 즐거움을 얻었다고 답한다 — 시스템 깊숙이 파고들어서 성능을 끌어올리는 일. 지금은 Claude가 자기보다 그 일을 훨씬 더 잘한다고 인정하면서도, 그 성능 개선의 결실은 여전히 자기가 누리고 있어서 좋다고 말한다. 요즘 훨씬 더 신경 쓰고 있는 건 새로운 아이디어를 더 빠르게 만들어내는 것 — 아이디어가 있으면 프로토타입을 거쳐 프로덕션까지 가는 속도가 훨씬 빨라졌다는 것. 그래서 자신의 관심은 이제 새로운 아이디어와, 그걸 얼마나 빨리 현실로 만들 수 있는지에 더 많이 쏠려 있다고 한다. 한마디로 예전엔 아주 깊은 디테일까지 파고드는 쪽이었다면, 지금은 훨씬 더 줌아웃된 시야로 패러다임이 옮겨갔다는 것.

Thariq: 그 특정 분야(성능)에 쏟던 만큼의 숙련(mastery)은 이제 덜해졌다는 뜻이냐고 확인한다.

Sid: "정확히 그렇다(Exactly)"고 답한다.

Robert: 자기도 비슷하다며, 자신은 디테일에 정말 집착하는 편이라고 말한다. UI 디자인의 세세한 부분까지 파고드는 걸 좋아했는데, 예를 들어 자기 개인 웹사이트를 위해 Mac OS 10.4 Aqua 버튼을 CSS로 픽셀 단위까지 완벽하게 재현한 적이 있다고 한다. 레이디얼 그라디언트(radial gradient) 레이어를 정확히 쌓아 올려서 완벽한 재현을 만드는 데만 거의 하루를 썼다고 — 그런데 이제 그런 건 그냥 Claude가 대신 해줄 수 있는 일이 됐고, 이제는 자기가 수동으로 그런 작업을 직접 하는 일은 없을 거라고 말한다.

이 이야기는 그를 7~8살 때로 데려간다 — 그때 정말 비디오 게임을 만들고 싶었는데, 코딩을 어떻게 하는지는 전혀 몰랐다. 그래서 "아, 나한테 파워포인트(PowerPoint)가 있잖아"라고 생각했고, 파워포인트로 클릭 가능한 요소들을 만들고 도형을 그려서 비슷한 걸 만들어봤다는 것. 그게 그 나이의 자신이 쓸 수 있었던 도구였다고 회상한다. 지금 Claude가 소프트웨어 엔지니어링 전체를 자신에게 얼마나 접근 가능하게(accessible) 만들어주는지를 생각하면 — 이제는 어떤 아이디어가 있어도 "난 기술적 능력이 없어서 이 문제를 못 풀어"라고 말할 필요가 없다는 것. 그냥 "내가 이루고 싶은 게 이거야"라고 말하고, 그걸 쪼개서 Claude와 함께 어떻게 실현할지 알아내면 된다는 것이다. 소프트웨어 엔지니어링이라는 영역 안의 모든 것이 이제 자기 손 안에 있는 것처럼 느껴져서 정말 신난다고 말한다.

대화는 소프트웨어 엔지니어링이 본질적으로 "변화의 직업(the profession of change)"이라는 데로 흘러간다. 10년, 20년 전을 돌아보면 프레임워크 하나 없이 자바스크립트를 손으로 쓰던 시절이 있었고, 그러다 프레임워크와 컴파일러 같은 것들을 발명해왔다. 지금은 그 속도가 더 빨라졌을 뿐, 본질적으로 소프트웨어는 여전히 "이런 것들을 어떻게 활용해서 놀라운 걸 만들고, 점점 더 훌륭한 소프트웨어를 더 많이 만들어낼 것인가"에 관한 것이다 — 결국 문제 해결(problem solving)이라는 것. Sid가 "정확히 그렇다(Exactly)"고, 풀어야 할 문제 자체는 계속 달라지지만 여전히 문제를 푸는 일이라는 데 동의하고, 다른 한쪽이 "전적으로 동의한다(Totally)"고 화답하며 인터뷰를 마무리한다.

영상 설명란은 두 개의 CTA로 마무리된다: Claude Code 시작하기와 X에서 ClaudeDevs 팔로우하기.

원본 링크·인용

원문 유래 링크는 본문 의미 위치에 유지한다. 아래는 보조 목록이다.

• How the Claude Code team uses Claude Code
• Claude 채널 @claude
• Get started with Claude Code
• x.com/ClaudeDevs

기타

원문은 영어 인터뷰(캡션 영어 수동 트랙). 한국어는 의미 보존 재구성이다. 캡션 타임스탬프 일부는 종료 시각이 깨져 있어 챕터 기준으로 대화를 재조립했다. 화자 라벨은 질문/답변 패턴과 설명란 세 이름에 근거하며, 짧은 맞장구 두 줄은 화자 미상으로 남겼다.

부분 추출: 트랜스크립트는 Aside youtube.getTranscript(영어 수동 캡션)로 확보. 영상 자체는 임베드만 두고 다운로드하지 않았다. 썸네일은 i.ytimg.com에서 로컬 복사.

캡처 2026-09-17 · 원문 게시 2026-09-02 · 디자인 레퍼런스 openai · 영상 iframe은 이미지 게이트 밖.