뒤처졌습니다. 이제 따라잡을 때입니다.

Theo - t3․gg 구독자 439,000명

요약

AI 도구의 등장으로 프로그래밍 환경이 근본적으로 변화하며 개발자들은 새로운 추상화 계층(에이전트, 플러그인, 맥락 관리 등)을 마스터해야 합니다. 개인 경험과 Carpathy, Ramp 팀의 인사이트를 바탕으로 AI 코딩 에이전트를 활용해 한계를 탐색하고, 일상 업무를 자동화하는 사고 전환을 제시합니다. 이어 다양한 에이전트와 도구를 오케스트레이션하는 방법과, 에이전 평가(evals), 시맨틱 검색 등 실용 기법을 통해 경쟁 우위를 확보하는 조직 차원의 전략을 안내합니다.

주요 키워드

AI 코딩 에이전트 오케스트레이션 Plan Mode vibe coding 에이전 평가(evals) 시맨틱 검색(Embedding) Agent MD 타입 안정성 프롬프트(prompt) fine-tuning(미세 조정)

하이라이트

🔑 AI 혁명: 프로그래밍이 AI 기반 에이전트와 도구로 재구성되며, 개발자가 단순 코드 작성에서 벗어나 새로운 추상화 계층을 이해해야 합니다.
⚡️한계 탐색: Claude Code, Cursor 같은 최신 AI 모델을 직접 써보며 Plan Mode로 단계별 과정을 익히고, 벤치마크로 발전 상황을 기록하는 것이 필수입니다.
🌟사고 전환: 이전에는 자동화 가치가 낮아 시도하지 않았던 아카이브 정리·자산 관리 등을 AI로 재해석해 비효율 업무를 제거합니다.
🚀오케스트레이션:여러 에이전트를 연결하고 MD 기반 참조 문서(예: Fish Bible)를 활용해 워크플로우를 자동화하는 역량이 성취도를 극대화합니다.
📌AI 리더십 플레이북: Ramp의 Raul이 제시한 도입 전략(모델 선택 자유, 타입 안정성, 에이전 평가, 세맨틱 검색 등)을 통해 조직이 뒤처지지 않을 수 있습니다.
🔧코드 리뷰 자동화: Grapile, CodeRabbit 등 AI 리뷰 도구를 적용해 코드 품질을 높이고 병목을 줄입니다.
📈비용 최적화: 미세 조정(fine-tuning)보다 우수한 프롬프트·모델 전환이 빠르며, 추론 비용은 빠르게 낮아지므로 과도한 걱정은 불필요합니다.
💡실험 문화: 오류를 두려워하지 말고 주도적으로 AI 도구를 업무와 사이드 프로젝트에 적용해 가능성을 확장해야 합니다.

용어 설명

AI 코딩 에이전트

AI 기반 도구로 코드 작성·리뷰·배포를 지원하는 시스템(예: Claude Code, Cursor)

프롬프트(prompt)

AI 모델에게 작업 의도와 조건을 전달하는 텍스트 입력

Plan Mode

AI 도구의 '계획' 기능으로, 단계별 과정을 자연어로 주고받으며 코드 생성 과정을 이해·제어하는 모드

vibe coding

간단한 커맨드나 아이디어를 AI에게 바로 전달해 즉시 코드 작업 및 테스트를 진행하는 빠른 실험 방식

오케스트레이션(orchestration)

여러 에이전트와 도구를 연결해 복합 워크플로우를 구성·자동화하는 기술

Agent MD

에이전트에게 프로젝트 구조, 규칙, 스타일 가이드 등을 설명해 코딩 기준과 맥락을 제공하는 문서

Embedding

시맨틱 검색을 위해 텍스트를 고차원 벡터로 변환, 의미 기반 검색을 가능하게 하는 기술

Evals(에이전 평가)

여러 AI 모델간 성능을 비교하기 위한 사용자 정의 벤치마크 평가

타입 안정성(Type Safety)

정적 타입 체크를 통해 코드 오류를 사전에 발견하고 에이전트에게 피드백을 제공하는 개념

fine-tuning(미세 조정)

특정 데이터로 AI 모델을 재학습시켜 성능을 개선하는 방법(빠른 모델 업데이트로 투자 대비 중요도 감소)

현재 프로그래밍 환경이 AI로 인해 격변 중임을 공유하며, 개인적으로 느끼는 '뒤처짐'의 감정과 Carpathy의 비유(매뉴얼 없는 강력한 도구)로 직업적 지진을 표현합니다.

[00:00] 프로그래머로서 느끼는 위기감과 새로운 AI 기술의 급속한 발전으로 인한 변화에 대한 고민을 토로합니다. 프로그래머의 기여도가 희박해지고 있으며, 새로운 추상화 계층을 마스터해야 한다는 부담감을 표현합니다.

[00:37] Karpathy의 포스트를 인용하며 AI 도구가 매뉴얼 없이 배포된 상황을 외계 도구에 비유합니다. 이로 인해 전체 프로그래밍 직업군이 지진과 같은 변화를 겪고 있다고 설명합니다.

[01:11] GPT-5 동영상 제작 당시의 경험을 회상하며, AI가 단순한 자동완성을 넘어 실제 애플리케이션 개발과 유지보수까지 가능해졌다는 변화를 강조합니다. 이런 변화 속도가 믿을 수 없을 정도로 빠르다고 언급합니다.

[01:37] 똑똑한 개발자들이 AI를 활용해 놀라운 것들을 만들고 있으며, 뒤처진다는 느낌을 받기 쉽다고 공감합니다. 하지만 앞서갈 수 있는 방법들이 있고, 이제는 개발자의 책임이라고 강조합니다.

[02:07] AI 개발 세계의 최신 동향을 따라잡기 위한 자신의 경험을 공유하겠다고 약속하며, 스폰서인 BuildJet을 소개합니다. GitHub Actions의 느린 속도 문제와 BuildJet의 솔루션을 언급합니다.

AI 개발 환경을 정복하기 위해 자신이 실천한 경험을 바탕으로 시청자에게 도움을 주고자 단계별 가이드를 제시할 것을 예고합니다. 조직적 생존과 경쟁력을 강조합니다.

[02:42] PostHog은 빌드 시간을 150분에서 4분으로 단축하여 37배 개선을 달성했고, gRPC 같은 오픈소스 프로젝트도 Depot을 통해 12배 빌드 개선을 이뤘다고 설명합니다.

[02:55] Depot이 이런 성능을 달성할 수 있는 이유는 더 좋은 CPU와 네트워킹을 사용하고, 캐시를 실제 작업 박스에 직접 연결된 NVME 드라이브에 저장하기 때문이라고 설명합니다.

[03:08] 이러한 기술적 개선으로 10배 빠른 처리량을 달성하면서도 GitHub 러너의 절반 가격으로 제공되며, 한 줄만 바꾸면 쉽게 시작할 수 있다고 소개합니다.

[03:24] 화자는 뒤쳐지지 않는 방법에 대한 가이드를 제시하면서, 역사적으로 대부분의 도구에 대해 '일찍 도입하는 것보다 늦는 게 낫다'고 주장해왔다고 말합니다.

[03:41] 아이폰 출시 전 Kaiora Echo용 Java 애플릿이나 MCP 같이 결국 쓸모없다고 판명된 기술들에 올인하는 사람들을 많이 봤다며, 실제로 매일 사람들에게 가치를 제공할 때까지 기다려야 한다고 강조합니다.

[04:02] AI의 경우 이미 그 지점에 도달했다고 선언하며, 자신은 현재 코드의 90% 정도를 AI로 작성하고 있고, 운영하는 팀들도 최소 70%의 AI 생성 코드를 사용한다고 밝힙니다.

[04:23] AI는 의사결정에는 뛰어나지 않지만 의사결정 과정 논의에는 좋으며, 이제 'AI가 성공할까'의 문제가 아니라 코딩이 영원히 바뀌었다고 강조합니다.

[04:43] 지금 AI를 시작하는 것은 더 이상 일찍 시작하는 게 아니라 늦게 시작하는 것이라고 경고하며, AI로 컴파일러나 프로그래밍 언어를 만드는 개발자들의 사례를 제시합니다.

[05:08] Railway의 CEO가 AI로 배포 시스템을 재구축하고 있고, 가장 똑똑한 개발자 중 하나인 Karpathy도 뒤처지고 있다고 느낀다며, AI가 취업 시장에 의미있는 영향을 미칠 것이라고 결론내립니다.

[05:19] AI가 취업 시장에 미칠 영향에 대해 논의하며, 이미 변화가 시작되었음을 강조합니다. 어떤 방향이나 규모인지는 모르지만 분명한 영향이 있을 것이라고 설명합니다.

[05:24] 사용자들이 AI 개발에 뒤처져 있다는 현실을 직시할 것을 촉구합니다. 부정하고 싶어도 이것이 현실이라고 강조하며, 따라잡는 방법에 대해 논의를 시작합니다.

[05:35] AI 도구를 따라잡는 가장 효과적인 방법으로 핫한 도구들을 직접 사용해보고 한계까지 밀어붙이는 것을 제안합니다. Claude Code, Cursor, Open Code 같은 최신 도구들을 시도해볼 것을 권장합니다.

Claude Code, Cursor, OpenCode 등 최신 AI 모델(GPT-5.2x, Opus 4.5)을 사용해 기능의 경계를 시험합니다. Plan Mode로 코드 생성 과정을 관찰하고, 벤치마크 저장으로 발전 추이를 기록하는 방법을 설명합니다.

[05:50] Opus 4.5나 GPT 5.2x high 같은 최신 모델들을 사용해서 실제 프로젝트의 기능 구현을 요청해보라고 조언합니다. 도구의 한계를 찾는 것이 첫 번째 목표라고 설명합니다.

[06:16] 코드가 더 이상 중요하지 않다는 것이 아니라, AI 도구를 사용해서 더 효율적으로 코드를 작성하는 방법을 가르치려는 것임을 명확히 합니다. 결과물을 읽는 것의 중요성을 강조합니다.

[06:39] Plan mode 사용을 강력히 추천하며, 특히 Cursor와 Claude Code의 plan mode가 우수하다고 설명합니다. Plan mode가 일반 언어로 소통할 수 있어 동료와 화이트보드 앞에서 계획하는 것 같은 느낌을 준다고 설명합니다.

[07:01] 에이전트가 코드베이스를 학습하고 파악하는 과정을 관찰하는 것의 중요성을 설명합니다. 궁극적인 목표 두 가지를 제시: AI 도구의 가능한 일과 불가능한 일에 대한 직감 기르기, 품질 확신은 유지하면서 코드 생산량 늘리기.

[07:25] 한계 찾기와 AI의 작업 방식 관찰을 동시에 해야 한다고 강조합니다. T3 chat 코드베이스를 테스트 환경으로 사용하여 점진적으로 복잡한 작업들을 시도했던 경험을 공유합니다.

[07:38] 새로운 모델들의 UI 개발 능력을 테스트하기 위해 모의 이미지 생성 스튜디오 구축을 요청했던 사례를 소개하며, 이런 방식으로 AI의 UI 구축 사고방식을 파악할 수 있다고 설명합니다.

[07:50] 이제는 모크업 제작을 요청하지 않고, Claude Code를 활용해 Convex와 FAL을 사용하여 실제 작동하는 이미지 생성 스튜디오를 한 번에 구축했다고 설명합니다.

[08:00] 백엔드와 동기화된 파일 스토리지를 갖춘 완전한 이미지 생성 스튜디오로, 바이브 코딩 코기 이미지 생성 예시를 통해 실제 작동 모습을 시연합니다.

[08:26] AI 도구를 효과적으로 활용하려면 자신의 코드베이스와 작업 유형을 머릿속에 체계화해두어야 한다고 강조하며, 일주일 정도 걸린 잘 문서화된 작업을 AI로 재현해보는 방법을 제안합니다.

[08:45] 작업 설명을 마크다운 파일로 만들어 클라우드 코드를 실행해보고, 실패할 경우 프롬프트를 수정하거나 나중을 위해 보관하는 체계적인 접근법을 설명합니다.

[09:05] AI 도구의 능력과 한계를 파악하기 위한 개인적인 벤치마크를 구축하는 것이 매우 중요하며, 이미 완료한 작업을 AI와 비교 분석하는 것이 효과적이라고 조언합니다.

[09:35] 두 번째 단계인 '틀에서 벗어나 생각하기'를 소개하며, 코드로 해결할 수 있지만 직접 코딩하기엔 비효율적인 문제들이 자주 있다고 언급합니다.

전에는 자동화 가치가 낮아 시도하지 않았던 일상 업무(아카이브 정리, 자산 관리, 이미지 생성 스튜디오 구축 등)를 AI로 처리해 업무 효율과 창의성을 높이는 방식을 제안합니다.

[09:50] 대학 시절 안드로이드 폰에서 백업한 8년치 사진과 영상을 토파즈로 업스케일링하려다가 6개월 만에 포기했던 개인적 경험을 공유합니다.

[10:15] 클라우드 코드의 성능 향상을 깨닫고 윈도우 환경에서 이 작업을 다시 시도하기로 결정했으며, 매우 긴 스크립트들을 작성해주는 결과를 얻었다고 설명합니다.

[10:24] Cloud Code를 Windows에서 실행하여 복잡한 파일 관리 작업을 지시했고, AI가 3만 줄의 JavaScript 코드를 작성해 시스템 파일들을 재구성하고 인코딩하는 놀라운 결과를 보여주었습니다.

[10:41] 이런 작업은 개발자가 직접 할 수도 있지만, 시간 대비 이득을 고려하면 실제로는 하지 않는 종류의 일이며, 이러한 유형의 작업이 매우 많다는 것을 깨달았습니다.

[10:51] 현재 진행 중인 모든 프로젝트마다 3-4개의 서브 프로젝트가 있으며, 이미지 스튜디오 작업도 T3 Chat의 이미징 시스템 개편을 위해 여러 샌드박스에서 아이디어를 테스트하는 과정의 일부입니다.

[11:12] 피시 슬롭이라는 독특한 수족관 클론 게임을 만들면서, 에셋 관리를 위해 세 개의 별도 도구를 바이브코딩으로 개발했습니다. 이는 파일 추적, 정리, 생성, 수정, 테스트 등을 더 쉽게 만들어줍니다.

[11:37] 1만5천 줄 프로젝트를 위해 1만 줄의 에셋 관리 도구를 만드는 것은 전에는 정신병 같은 일이었지만, 지금은 새로운 도구를 시도하고 학습할 수 있는 훌륭한 실험이 되었습니다.

[12:01] 이제는 뇌를 다시 연결하고 고정관념에서 벗어나 생각해야 합니다. 코드 작성에 필요한 노력이 크게 줄어들면서, 전에는 말이 안 됐던 것들을 코드로 해결할 수 있게 되었기 때문입니다.

[12:14] AI 시스템의 한계와 능력을 이해하게 되면 세상을 다르게 보기 시작합니다. 스케이트보더가 엘토로 20 같은 거대한 계단을 보며 점프 가능성을 생각하는 것처럼, 일정 경험을 쌓으면 세상의 모든 것을 다른 관점에서 바라보게 됩니다.

[13:02] 스케이트보드를 배우면 세상을 다르게 보게 된다. 포장도로, 계단, 가장자리 등 모든 것이 스케이트보드 장애물로 인식되고, 새로운 공간에서도 항상 스케이트보드 관점에서 생각하게 된다.

[13:28] 코딩을 배우면 스케이트보드와 마찬가지로 세상을 다르게 인식한다. 웹사이트나 앱의 에러를 볼 때 다른 사람들과 달리 그 원인을 분석하고 작동 원리를 이해하려 한다.

[13:49] 뇌를 다시 연결하는 것은 매우 어려운 일이지만 필요한 과정이다. 개발자들에게는 힘들고 시간이 오래 걸리는 일이며, 화자도 1년 반 이상이 걸려서 깨달음을 얻었다.

[14:07] 이제는 랜덤한 아이디어가 있어도 3일이 아닌 몇 분 만에 구현할 수 있다. AI 모델 비교 실험을 위해 에세이 작성-피드백-재작성 자동화 시스템을 10분 만에 만든 사례를 소개한다.

[14:45] 개발자들이 매일 마주치지만 이전에는 자동화하기보다 수동으로 처리하는 게 쉬워서 방치했던 성가신 작업들이 이제는 쉽게 해결 가능하다.

[15:02] 새로운 API 실험이나 크롬 익스텐션 개발이 매우 간단해졌다. 소프트웨어로 해결 가능한 모든 문제가 100배 더 쉬워져서 자유로움을 느끼며, 반복 명령어를 하나로 통합하는 것 같은 사소한 자동화도 가능하다.

[15:41] 개발자가 git 자동화 명령어를 만드는 과정을 설명합니다. 파일 선택, 커밋, 푸시를 한 번에 처리하는 별칭을 Zsh 설정에 추가하고, YouTube DLP용 MP4 변환 명령어 등 자주 사용하는 작업들을 자동화하는 방법을 보여줍니다.

[16:29] AI 도구 활용의 다음 단계인 오케스트레이션 단계를 소개합니다. 여러 에이전트를 연결하고 글루 코드를 작성하여 복잡한 워크플로우를 구성하는 것으로, 이 부분이 진정한 가속화가 시작되는 지점이라고 설명합니다.

여러 에이전트를 연결하고, ‘Fish Bible’ 같은 마크다운 참조 문서를 사용해 워크플로우를 동기화하는 오케스트레이션 기법을 소개합니다. 복합 기능을 통합해 생산성을 극대화합니다.

[17:06] 게임 개발 프로젝트에서 픽셀 아트 생성 도구와 게임 기능들을 연결하는 오케스트레이션 사례를 제시합니다. '물고기 바이블'이라는 마크다운 파일을 만들어 게임의 모든 생물 정보를 중앙화하고, Claude MD를 통해 코드와 문서 간의 동기화를 자동화하는 방법을 설명합니다.

[18:14] 품질 기준에 대한 새로운 접근법을 제시합니다. 프로덕션 코드가 아닌 개인 업무용 도구나 자동화 스크립트의 경우, 완벽하지 않더라도 실용적인 코드가 충분히 가치 있다고 설명합니다.

[18:35] 모든 사람의 삶에 간단한 자동화가 도움될 수 있는 영역이 있다고 강조하며, 썸네일 분석 도구 개발 사례를 통해 실제 활용 경험을 공유합니다. 이제는 하루 만에 이런 도구를 만들 수 있게 되었다고 합니다.

[18:59] 오케스트레이션의 중요성을 언급하며, 여러 AI 도구들을 조합하고 관리하는 것이 핵심 과제라고 설명합니다. Claudebot을 예시로 들어 텔레그램이나 WhatsApp을 통해 AI 에이전트와 소통할 수 있는 통합 시스템을 소개합니다.

[19:26] 처음에는 억지로라도 자동화 기회를 찾아야 하지만, 곧 깨달음이 온다고 조언합니다. 일상의 지루한 작업들이 이전에는 자동화할 가치가 없었지만 이제는 충분히 가치 있는 대상이 되었다고 강조합니다.

[19:47] 개인적으로 아이디어 목록을 관리하고 있으며, 특히 코드 생성 작업을 계획, 구현, 리뷰 단계로 나누어 관리하는 칸반 보드 개발에 관심이 있다고 밝힙니다.

[20:01] 실제 기업 사례를 소개하며, RAMP의 응용 AI 책임자 Raul의 게시물을 인용합니다. 뒤처지면 반드시 실패한다는 경고와 함께 AI 리더를 위한 실수 없는 플레이북을 제시하며, 코딩 에이전트 사용과 엔지니어들의 도구 선택권 보장을 핵심 전략으로 언급합니다.

Ramp의 Raul이 제시한 AI 코딩 전략(모델 선택, 코드베이스 에이전트 문서화, 타입 안정성, 에이전 평가, 시맨틱 검색, 비용 관리 등)을 통해 조직 차원에서 AI 도구를 성공적으로 도입·운영하는 방법을 안내합니다.

[20:37] Meta 엔지니어들이 예전에는 Llama 4를 강제로 사용해야 했지만, 이제는 원하는 모델을 자유롭게 선택할 수 있게 되었고, GPT-4.5가 새로운 기준이 되었다는 상황을 설명합니다.

[21:00] 에이전트에게 Linear, GitHub, DataDog, Sentry 같은 모든 개발 도구에 대한 접근 권한을 제공해야 한다고 강조하며, 컨텍스트 부족으로 에이전트가 제약받는다면 개발자의 책임이라고 주장합니다.

[21:17] RAMP의 엔지니어가 만든 내부 inspect 봇 사례를 소개하며, 이 봇이 코어에서 가장 흔한 Sentry 이슈 20개를 찾아 각각에 대한 PR을 자동으로 생성하는 놀라운 능력을 보여준다고 설명합니다.

[21:54] 코드베이스별 에이전트 문서에 투자하고, 더 나은 프롬프팅과 agents MD 파일, 린팅, 코드 룰을 활용해야 한다고 조언하며, 에이전트들이 피드백을 받으면 훨씬 똑똑해진다고 강조합니다.

[22:11] 타입 언어 사용의 중요성을 강조하며, 타입으로 확인 가능한 오류를 에이전트에게 피드백으로 제공하면 에이전트가 오류를 수정할 수 있다고 설명합니다. OpenAI Code, Claude Code, Cursor 등의 도구들이 이런 기능을 지원한다고 언급합니다.

[22:42] agent MD 파일의 중요성을 강조하며, Claude Code 팀이 내부 repo의 Claude MD 파일을 하루에 여러 번 수정하는 사례를 들어 설명합니다. 에이전트가 잘못된 방향으로 갈 때마다 즉시 MD 파일에 지침을 추가하여 개선한다고 설명하며, 생성된 코드의 모든 수동 편집이 개선의 기회라고 조언합니다.

[23:07] AI 에이전트 개발을 위한 견고한 백그라운드 인프라 구축의 중요성을 강조하며, VM과 샌드박스에서 작동하는 완전한 개발 스택 구축을 권장합니다.

[23:20] 코드 리뷰가 병목 지점이 될 것이라 예상하며, 0단계로 AI 코드 리뷰 도구(Grapile, Code Rabbit 등)를 레포지토리에 추가할 것을 권장합니다.

[23:59] AI 코드 리뷰를 유일한 리뷰가 아닌 보완 도구로 사용하되, 보안 문제를 해결하고 위험 회피적이지 말고 필요한 접근 권한을 부여할 것을 조언합니다.

[24:28] AI 제품 구축 시 최신 세대 모델을 사용하고, 견고한 평가 없이는 구세대 모델에서 빠르게 이동할 것을 권장하며, GitHub Copilot의 구식 모델 사용을 예로 듭니다.

[25:00] 전통적인 퍼지 검색 대신 임베딩 시맨틱 검색 사용을 권장하고, Cursor나 Claude Code 같은 도구들이 더 나은 검색 시맨틱을 뒤에서 사용한다고 설명합니다.

[25:24] 구조화된 출력을 사용한 양식 미리 채우기와 모든 제품에서 구조화되지 않은 입력(자유 형식 텍스트, 문서) 허용의 중요성을 강조하며 양식의 종료를 선언합니다.

[25:38] 커스텀 파인튜닝이 더 이상 효과적이지 않다는 점을 강조하며, 프론티어 기술의 빠른 발전으로 인해 장기간의 파인튜닝 투자가 비효율적이라고 설명합니다.

[25:50] 더 나은 프롬프팅 기법과 지시어 개선을 통해 원하는 결과를 얻는 것이 더 효과적이며, 모델의 한계에 부딪혔을 때 극복하는 다양한 전략들을 제시합니다.

[26:15] 프롬프트 개선, 맥락 추가, Claude MD/Aider MD 조정, LSP 지원이나 린팅 같은 도구 추가를 통해 모델의 성능을 향상시킬 수 있다고 설명합니다.

[26:45] 절대 되돌리지 않고 프롬프팅만으로 문제를 해결하는 전략을 사용하는 개발자들의 예시로 QuadBot 제작자 Pete를 언급하며, 개인적으로는 학습을 위해 되돌리기를 선호한다고 합니다.

[27:15] AI 도구의 한계를 밀어붙이는 것의 중요성을 강조하며, 불편함을 감수하고 계속 도전해야 한다고 조언합니다. 많은 재능있는 개발자들이 이미 놀라운 성과를 내고 있다고 언급합니다.

[27:37] Stylex 라이브러리 제작자 Nean의 경험을 공유하며, 모델별로 되돌리기 전략의 효과가 다르다는 점(Codex vs Opus)을 설명하고, 실험과 경험을 통한 학습의 중요성을 강조합니다.

[28:15] AI 프로젝트에서 평가 시스템 구축의 중요성을 강조하며, 빠른 모델 업그레이드 결정을 위해 많은 평가를 만들어야 한다고 설명합니다. 완벽하지 않아도 되지만 모델들을 상대적으로 비교할 수 있어야 하며, 파레토 비용 대 성능 플롯에서 대부분의 결정이 명확해진다고 말합니다.

[28:30] 벤치마크를 즉흥적으로 코딩하는 것이 시작하기 좋은 방법이라며, AI가 잘하거나 못하는 부분을 발견하면 그것을 분리해서 빠른 일회성 벤치마크를 만들라고 권합니다. 자신만의 평가를 커스터마이징하고 구축하는 것이 매우 재미있다고 개인 경험을 공유합니다.

[28:57] 회사 리더들에게 필수적인 조언으로, 모든 엔지니어가 AI로 구축하도록 격려하고 모든 코드베이스에서 모델을 호출할 수 있는 기본 요소들을 구축해야 한다고 설명합니다. 구조화된 출력, 의미적 유사성 엔드포인트, 샌드박스 코드 실행 등이 포함됩니다.

[29:12] 추론 비용에 대한 걱정을 멈추라고 조언하며, 비용이 너무 빠르게 떨어지고 있어서 이것이 중요하지 않다고 설명합니다. 연간 비용이 아니라 주간 단위로 계산해야 하며, 새로운 것들이 출시되면서 상황이 매우 빠르게 변화하고 있다고 강조합니다.

[29:44] 이 조언들이 주로 리더들에게 초점을 맞춘 것임을 인정하며, 대부분의 시청자들은 개별 기여자나 개발자 지망생일 것이라고 말합니다. 직장에서 지원이 없다면 독립적으로 할 수 있는 기회를 찾거나 몰래 도입해보라고 권합니다.

[30:08] Ramp에서 채용 중이라는 것을 언급하고, 이 조언을 써준 라울에게 감사를 표합니다. 사이드 프로젝트로 독립적으로 시작하거나 직장에 몰래 도입할 방법을 찾으라고 조언하며, 지금은 허가보다는 용서를 구하는 것이 필수적이라고 강조합니다.

[30:38] AI 도구 사용으로 동료들보다 앞서거나 해고당할 수도 있지만, 그 경험은 다른 회사 면접에서 강력한 이야기가 될 것이라고 조언합니다.

[31:01] 모든 면에서 한계를 밀어붙이라고 강조하며, 도구 사용의 한계, 도구의 능력, 직장에서의 허용 범위를 최대한 테스트해보라고 권합니다.

학습자, IC, 매니저 등 각자의 위치에서 계속 실험하고 빌드할 것을 독려합니다. 조직 도입이 어려울 경우 사이드 프로젝트나 이직으로 AI 활용 환경을 찾아야 함을 제안합니다.

[31:17] 한계를 밀어붙이면 시스템의 놀라운 능력과 우회 방법, 그리고 엄청난 생산성 향상을 경험하게 될 것이라고 설명합니다.

[31:33] 매니저들에게 직접 메시지를 전하며, 최고의 엔지니어들은 이미 AI 도구를 주로 사용하고 있으므로 이를 허용하지 않으면 인재 유실과 회사 실패로 이어질 것이라고 경고합니다.

[31:56] 개발 분야에서 AI 반대는 고귀한 신념이 아니라 최고의 개발자들을 화나게 하는 방법이며, 승리를 위해서는 최고의 도구 사용을 허용해야 한다고 주장합니다.

[00:00] 프로그래머로서 이렇게 뒤처진다는 느낌을 받은 적이 없었습니다.

[00:01] 이 직업이 극적으로 재구성되고 있습니다.

[00:03] 프로그래머가 기여하는 비트들이

[00:05] 점점 더 희박해지고 있거든요.

[00:06] 지난 1년 동안 사용 가능해진 것들을

[00:09] 제대로 연결만 한다면 10배는 더

[00:10] 강력해질 수 있을 것 같다는 느낌이 듭니다.

[00:12] 하지만 이런 향상을 놓치는 것은

[00:14] 확실히 실력 부족으로 느껴집니다.

[00:16] 기존의 아래층 레이어들에 더해

[00:18] 마스터해야 할 새로운 프로그래밍 가능한

[00:20] 추상화 계층이 생겼습니다.

[00:22] 에이전트, 서브 에이전트들과

[00:24] 그들의 프롬프트, 컨텍스트,

[00:27] 메모리, 모드, 권한, 도구들,

[00:30] 플러그인, 스킬, 훅, MCP LSP/Commands,

[00:33] 워크플로우 등등... 좋아요, 여기서 끊어보겠습니다.

[00:37] 이건 Karpathy의 포스트인데 보고 나서

[00:39] 계속 생각해보게 되는 내용이에요.

[00:41] 어떤 면에서는 매우 비슷하게 느끼고

[00:43] 다른 면에서는 그렇지 않거든요.

[00:45] 이에 대해 하고 싶은 말이 많습니다.

[00:47] 특히 마지막 부분이 정말 흥미로웠어요.

[00:49] 분명히 강력한 외계 도구가 배포되었는데

[00:52] 매뉴얼도 없이 왔고, 모든 사람이

[00:54] 어떻게 들고 조작할지 알아내야 하는 상황이죠.

[00:56] 한편으로는 규모 9의 지진이

[00:58] 이 직업군을 흔들고 있고요.

[01:00] 뒤처지지 않으려면 소매를 걷어부쳐야 합니다.

[01:02] 네, 정말 많은 일이 벌어지고 있고

[01:05] 저도 그 어느 때보다 강하게 느끼고 있어요.

[01:08] GPT-5 동영상을 만들었을 때가 아직도 기억나는데

[01:11] 그때 처음으로 이런 징조를 느꼈어요.

[01:13] 더 이상 '아, 이런 것들이

[01:15] 자동완성이나 API 파일 스텁

[01:17] 생성에 도움이 될 수 있겠구나' 수준이 아니라

[01:19] 이제는 AI가 실제 애플리케이션을 구축하고

[01:22] 유지보수를 도와주며 우리가

[01:24] 수십 년 동안 해왔던 많은 종류의

[01:27] 작업을 할 수 있다고 느껴져요.

[01:29] 이런 변화가 일어나는 속도를 아직도 믿을 수 없지만

[01:32] 매우, 매우 현실적이에요.

[01:34] 제가 아는 가장 똑똑한 개발자들은 모두

[01:37] 지금 AI로 놀라운 것들을 만들고 있어요.

[01:39] AI를 제품의 일부로 사용하거나

[01:41] 개발 작업의 대부분에 활용하고 있죠.

[01:43] 그래서 뒤처진다는 느낌을 받기 쉬워요.

[01:45] 감히 말하건대 우리 대부분이

[01:47] 지금 이런 기분일 겁니다.

[01:49] 하지만 앞서갈 수 있는 방법들이 있어요.

[01:51] 개발자로서 우리 모두가

[01:53] 할 수 있는 일들이 있습니다.

[01:55] 덜 강력해지는 것이 아니라 더 강력해질 수 있도록요.

[01:58] 드디어 개발자로서 우리의 책임이 되었다고 생각해요.

[02:01] 특히 계속 고용되고 싶다면

[02:03] 이런 것들을 잘 알고 있어야 합니다.

[02:05] 그래서 이번 동영상에서는

[02:07] AI 개발 세계의 최신 동향을

[02:09] 따라잡기 위해 제가 한 일들을

[02:10] 최선을 다해 설명해드리겠습니다.

[02:12] 그리고 여러분에게 도움이 되길 바라요.

[02:14] 여러분에게 도움이 될 다른 것을 아세요?

[02:16] 오늘의 스폰서입니다. GitHub의 로딩 시간보다

[02:17] 더 느린 것을 아세요? PR을 열려고 할 때

[02:20] 실행되는 데 10초가 걸리고

[02:21] 액션들이 있잖아요. GitHub 액션이

[02:23] 얼마나 느린지 아직도 충격적이에요.

[02:26] 정말 믿을 수 없어요. 그래서 BuildJet이

[02:29] 대박을 치고 있는 거고, 그래서 GitHub이

[02:31] 그들을 두려워하는 거예요.

[02:33] 여러분의 액션을 우스꽝스러울 정도로 빠르게 만들어주고

[02:35] Docker 빌드도 마찬가지예요.

[02:37] 지난 주에만 개발자들의

[02:39] 143,000시간 이상을 절약했어요.

[02:42] 시간을 절약했습니다. PostHog 같은 회사들은

[02:46] 빌드 시간을 150분에서 4분으로 단축하여

[02:48] 37배 개선을 달성했습니다. gRPC 같은

[02:51] 오픈소스 프로젝트도 Depot을 사용해서

[02:53] 12배 빌드 개선을 이뤘습니다.

[02:55] 그들은 세부사항을 비밀로 하지 않습니다.

[02:57] 이렇게 빠른 성능이 가능한 이유는

[02:59] 훨씬 좋은 CPU와 네트워킹을 사용하고

[03:01] 캐시를 실제 작업을 수행하는

[03:03] 박스에 직접 연결된 NVME 드라이브에

[03:06] 저장하기 때문입니다. 이 모든 것이

[03:08] 10배 빠른 처리량 같은

[03:10] 놀라운 차이를 만들어냅니다. 그런데

[03:12] 이 모든 게 GitHub 러너의

[03:14] 절반 가격입니다. 정말 저렴하죠.

[03:16] 한 줄만 바꾸면 시작할 수 있고

[03:18] 사용해보면 정말 만족하실 겁니다.

[03:20] 신용카드 없이 무료로 체험해보세요.

[03:21] soy에서 확인하실 수 있습니다. 자, 이제

[03:24] 뒤쳐지지 않는 방법에 대한 제 최고의

[03:27] 가이드를 제공하겠습니다. 역사적으로 저는

[03:30] 대부분의 도구에 대해 항상 같은 말을

[03:32] 했습니다. 일찍 도입하는 것보다

[03:34] 늦는 게 낫다고요. 아직도 이걸 믿습니다.

[03:37] 명확히 하고 싶습니다. 여전히 이걸

[03:39] 강하게 믿습니다. 결국 쓸모없다고 판명된

[03:41] 것들에 올인하는 사람들을 너무 많이

[03:44] 봤거든요. 아이폰이 나오기 전에

[03:45] Kaiora Echo용 Java 애플릿을 만들거나

[03:48] MCP 같은 것들 말이죠. 이런 일들이

[03:50] 몇 년마다 일어납니다. 뭔가 확실히

[03:53] '오 마이 갓, 이게 미래야'처럼 보이다가

[03:55] 실제로는 일어나지 않는 거죠.

[03:57] 실제로 매일 사람들에게 가치를

[03:59] 제공할 때까지 기다려야 합니다.

[04:01] 그래야 투자할 가치가 있죠.

[04:02] 냉혹한 현실은 AI가 이미 그 지점에

[04:04] 도달했다는 것입니다. 저는 지금 제 코드의

[04:06] 대부분을 AI로 작성하고 있습니다.

[04:09] 대부분보다 많은, 90% 정도라고

[04:11] 할 수 있겠네요. 제가 운영하는 팀들은

[04:13] 최소 70%의 AI 생성 코드를 사용하고

[04:16] 때로는 더 많이 사용합니다.

[04:17] 제가 자문하고, 함께 일하고,

[04:19] 투자하고, 매일 대화하는 회사들도

[04:21] 비슷한 수치를 보입니다. AI는 의사결정에는

[04:23] 뛰어나지 않습니다. 하지만 의사결정 과정을

[04:26] 논의하는 데는 여전히 좋습니다.

[04:28] 미래에는 이것도 바뀔 수 있으니

[04:29] 계속 지켜봐야 합니다. 하지만

[04:31] 정말 강조하고 싶은 것은

[04:32] AI가 유용하다는 것입니다. 이건 더 이상

[04:34] 'AI가 성공할까, 우리가 사용하게 될까'의

[04:37] 문제가 아닙니다. 코딩은 영원히

[04:40] 바뀌었습니다. 우리는 이미 그 지점을

[04:43] 넘어섰습니다. 지금 시작하는 것은

[04:45] 더 이상 일찍 시작하는 게 아닙니다.

[04:47] 지금 시작하는 것은 늦게 시작하는 겁니다.

[04:49] 이런 기술이 유용할지 지켜보며

[04:51] 기다리고 있었다면, 우리는 이미 그 지점을

[04:53] 넘어섰습니다. 유용합니다. 이제 때가 됐습니다.

[04:56] 여러분이 작업하는 것이 AI에게는

[04:57] 너무 복잡하다고 생각한다면, AI로

[04:59] 컴파일러를 만드는 사람들에게 말해보세요.

[05:00] AI로 프로그래밍 언어와 시스템,

[05:02] 놀라운 애플리케이션들을 만드는 사람들에게

[05:04] 말해보세요. AI로 배포 시스템을

[05:06] 재구축하고 있는 Railway의 CEO에게

[05:08] 말해보세요. 지금까지 살았던 개발자 중

[05:10] 가장 똑똑한 사람 중 하나인 Karpathy도

[05:12] 뒤처지고 있다고 느끼고 있다고 말해보세요.

[05:14] AI는 이미 왔습니다. 더 이상 부정할 수 없어요.

[05:16] 이것은 취업 시장에 의미있는 방식으로

[05:17] 영향을 미칠 것입니다. 어떤 방향으로

[05:19] 어떤 방향으로, 어떤 규모로 변화할지는 모르지만

[05:21] 분명히 영향을 미칠 것입니다. 자, 이제

[05:24] 여러분이 공식적으로 뒤처져 있다는 걸 확인했습니다.

[05:26] 아무리 부정하고 싶어도, 댓글란에

[05:28] 온갖 반박이 달릴 거라는 걸 알지만

[05:29] 상관없습니다. 현실을 받아들이세요. 그럼

[05:32] 어떻게 따라잡을 수 있을까요? 방법은

[05:35] 여러 가지가 있습니다. 개인적으로 제가 가장 선호하는 방법은

[05:38] 가장 핫한 도구를 직접 써보고

[05:41] 그 한계까지 밀어붙이는 것입니다. 첫 번째 단계는

[05:43] 그 한계를 찾아내는 것입니다.

[05:45] Claude Code나 Cursor, Open Code

[05:48] 또는 이런 도구들을 한번 써보세요.

[05:50] 이 영상을 촬영하는 시점에서 최신 모델인

[05:51] Opus 4.5나

[05:54] 인내심이 있다면 GPT 5.2x high를

[05:56] 사용해 보세요. 한번 시도해 보고

[05:58] 한계까지 밀어붙여 보세요. 여러분이

[06:00] 한동안 구현하고 싶었던

[06:02] 제품이나 프로젝트의

[06:03] 어떤 기능을 골라서 에이전트에게 해달라고 요청해 보세요.

[06:05] Cursor를 열고 Opus를 선택한 다음

[06:08] "이런 기능을 원한다"고 말해보세요. 그리고

[06:11] 좋은 계획을 세우는지 확인하고

[06:13] 결과물을 읽어보세요. 저는 여기서 코드가

[06:16] 더 이상 중요하지 않다고 말하려는 게 아닙니다.

[06:18] 이런 도구들을 사용해서 어떻게

[06:21] 더 효율적으로 코드를 작성하는지 알려드리는 겁니다.

[06:23] 그리고 그 일부는 결과물을 읽는 것입니다.

[06:25] 제가 최근 Claude Code를 어떻게

[06:27] 사용하고 있는지에 대한

[06:28] 이전 영상들을 보셨다면 저를

[06:29] 반골이라고 부를지도 모르겠지만, 그건

[06:31] 잠시 후에 다룰 단계입니다. 이게 바로

[06:34] 시작하는 방법입니다. 한계를 찾아내고

[06:36] 그 한계를 찾는 과정에서 결과물을 읽어보세요.

[06:39] 또한 plan mode를 제공하는 도구들에서는

[06:41] plan mode를 사용하길 추천합니다. Open Code의

[06:42] plan mode는 아직 훌륭하지 않습니다.

[06:43] 여러분이 이 영상을 보실 때쯤이면

[06:45] 아마 수정되어 있을 겁니다. 그들은 정말

[06:47] 빠르게 개발하고 있거든요. Cursor와

[06:49] Claude Code는 모두 훌륭한 plan mode를 가지고 있습니다.

[06:51] plan mode가 좋은 이유는 일반 언어로

[06:52] 주고받을 수 있기 때문입니다. 마치 동료와

[06:55] 회의실에서 화이트보드를 앞에 두고

[06:57] 어떻게 이 일을 해낼지 계획하는

[06:59] 느낌입니다. 또한 에이전트가 코드베이스를

[07:01] 살펴보며 학습하고 파악하는

[07:03] 과정을 지켜볼 수 있습니다. 그리고 그것이

[07:05] 어떻게 하는지 배울 수 있죠. 그게 바로

[07:08] 여기서 궁극적인 목표입니다. 실제로는

[07:10] 맨 위에 두어야 했을 목표죠.

[07:12] 더 많은 목표가 생기면

[07:13] 여기에 추가하겠습니다. 하지만 이 두 가지가

[07:15] 핵심입니다. 이런 도구들이 할 수 있는 일과

[07:16] 할 수 없는 일에 대한 직감을 기르는 것과

[07:18] 품질에 대한 확신은 줄이지 않으면서

[07:20] 생산할 수 있는 코드의 양을 늘리는 것입니다.

[07:22] 그래서 첫 번째 단계는

[07:24] 이런 한계들을 찾아내려고 노력해야 한다는 것입니다.

[07:25] 그리고 한계를 찾는 과정에서

[07:27] 그들이 어떻게 일하는지도 지켜봐야 합니다.

[07:30] 저는 점점 더 복잡한

[07:31] 작업들의 목록을 가지고 있었는데, 결국

[07:33] 제 테스트 환경으로 사용하던 T3 chat 코드베이스에서

[07:36] 해보고 싶었던 것들이었습니다.

[07:38] 계속해서 난이도를 올려가면서 말이죠.

[07:39] 새로운 모델들과 그들이 UI에서

[07:41] 얼마나 뛰어난지 시연할 때 제가 자주 드는

[07:43] 재미있는 예시는 모의 이미지 생성 스튜디오를

[07:46] 구축해달라고 요청하는 것입니다. 그들이 UI 구축에 대해

[07:48] 어떻게 생각하는지 보여주는 방식으로요. 이제는 더 이상

[07:50] 모크를 만들어달라고 요청하지 않습니다. 방금

[07:52] Convex를 얼마나 좋아하는지에 대한

[07:54] 영상을 찍었는데, Claude Code에게 Convex와 FAL을

[07:57] 사용해서 실제 이미지 생성 스튜디오를 한 번에

[08:00] 만들어달라고 했습니다. 이건 백엔드와 동기화된

[08:02] 파일 스토리지를 갖춘 완전히 작동하는

[08:05] 이미지 생성 스튜디오로 원하는 걸 뭐든

[08:07] 생성해줍니다. 여기서 세 대의

[08:09] 노트북을 동시에 사용하는 바이브 코딩 코기

[08:11] 이미지를 생성해보겠습니다. 잠시 후

[08:13] Nano Banana Pro에서 응답이 오면,

[08:15] 여러 노트북을 사용하는 바이브 코딩 코기가

[08:17] 나타났습니다. 작동하는 저장 버튼과

[08:19] 좋은 UI까지. 이전에는 정말 짜증났던

[08:20] 이런 모든 걸 이제 그냥 해줍니다.

[08:22] 정말 놀라운데, 자신의 코드베이스를 아는 것처럼

[08:26] 이런 시스템들을 머릿속에 가지고 있어야 합니다.

[08:28] 어떤 종류의 작업을 하는지 알고

[08:30] 정신적으로 추적해야 합니다. 일주일이 걸린

[08:33] 작업이 있는데 상대적으로 잘 문서화되어 있다면,

[08:35] 그 작업을 하기 전 리포지토리의 복사본을 만들어서

[08:38] 어딘가 폴더에 넣고, 작업 설명을

[08:40] 적어두고, 그 폴더에 마크다운 파일로

[08:42] 넣은 다음, 그것에 대해 클라우드 코드를

[08:45] 실행해보세요. 그것을 입력으로 받아서

[08:47] 그 것을 만들 수 있는지 보세요.

[08:48] 가까이 갔지만 완전하지 않다면,

[08:50] 프롬프트를 조금 다시 써보세요.

[08:52] 그곳으로 안내할 수 있는지 보세요.

[08:55] 여전히 안 된다면 그것을 저장해두세요.

[08:57] zip 파일로 만들어서 어딘가에

[08:58] 보관해두세요. 도구가 더 나아지는 순간

[09:01] 콜드 스토리지에서 꺼내서 다시

[09:03] 시도해보세요. 이런 도구들이 어떤 능력을

[09:05] 가지고 있는지에 대한 자신만의 유사 벤치마크를

[09:07] 만들어서 그들이 무엇을 할 수 있고

[09:09] 얼마나 멀리 갈 수 있는지 알고,

[09:11] 또한 무엇에 막히는지 아는 것은

[09:13] 매우 매우 가치 있습니다.

[09:15] 그래서 첫 번째 단계입니다. 실제로 하고 있는

[09:17] 일상 업무를 가져와서 세분화하고, 포장해서

[09:20] 에이전트에게 던져서 당신의 품질 기준을

[09:21] 만족하는 작업을 만들 수 있는지 보세요.

[09:23] 이미 한 작업에 대해서는 정말 좋습니다.

[09:25] 왜냐하면 어떻게 할지 알고 있고,

[09:27] 자신이 한 방식과 AI가 했을 방식을

[09:28] 비교 대조할 수 있기 때문입니다.

[09:30] 이제 조금 더 어려운 2단계가 있습니다.

[09:32] 틀에서 벗어나 생각하기. 이것은

[09:33] 제가 극복하는 데 시간이 좀 걸렸고,

[09:35] 다양한 이유로, 주로 콘텐츠 때문에

[09:36] 이미 이런 성향이 있었습니다만,

[09:39] 제가 일하는 방식 때문이기도 합니다.

[09:41] 코드로 해결할 수 있는 문제가 있지만

[09:43] 코드를 써서 해결하는 게 말이 안 되는

[09:45] 경우가 얼마나 자주 있는지 말할 수 없습니다.

[09:47] 대학 다닐 때 안드로이드 폰에서 백업한

[09:50] 오래된 자료들이 많이 있는데,

[09:52] 그냥 학교 다닐 때 찍은 영상과 사진들이

[09:54] 매우 정리가 안 되어 있고 그냥

[09:56] 컴퓨터의 임의의 폴더들에 있습니다.

[09:58] 그것들을 저장하고 토파즈 같은

[10:00] 도구로 업스케일링하고 싶었습니다.

[10:02] 수동으로 다 해볼 수도 있었고 실제로 했습니다.

[10:04] 8년간의 아카이브 중 6개월 정도는

[10:06] 끝마쳤지만 이걸 다 할 수 없다는 걸 깨달았습니다.

[10:08] 그래서 멈췄습니다. 클라우드 코드가

[10:11] 얼마나 좋아졌는지 깨달았을 때,

[10:13] 윈도우에서 그 한계를 테스트해보고 싶었는데

[10:15] 윈도우에는 많은 것들이 저장되어 있어서요.

[10:17] 그래서 윈도우에서 클라우드 코드를 실행했고

[10:19] 그것에게 해달라고 말했습니다.

[10:21] 그러자 매우 긴 스크립트들을 여러 개

[10:22] 작성했습니다.

[10:24] 저장된 자료들을 처리해야 했습니다. 그래서 Windows에서 Cloud

[10:25] Code를 실행시키고 이 작업을 지시했죠. 그러자

[10:28] 매우 긴 여러 개의 스크립트를 작성하기 시작했고,

[10:31] 심지어 3만 줄짜리 단일 JavaScript 파일까지 만들어서

[10:34] 시스템에 저장된 파일들을 재구성하고

[10:37] 다시 인코딩하는데 사용했습니다. 그리고 정말

[10:39] 놀라운 결과를 보여줬어요. 이런 건

[10:41] 제가 직접 작성할 수도 있었지만, 절대

[10:44] 그러지 않았을 거예요. 당장의 이득에 비해

[10:46] 시간이 너무 많이 걸리거든요.

[10:47] 그런데 깨달은 게 있어요. 이런 것들이

[10:49] 정말 많다는 거죠. 지금 진행하고 있는

[10:51] 모든 프로젝트마다, 서너 개의

[10:53] 서브 프로젝트가 있는데 그건 다 제가

[10:55] 그 프로젝트를 위해 하고 싶은 여러 가지

[10:57] 작업들이에요. 이미지 스튜디오 관련 작업을

[11:00] 하는 이유 중 하나도 T3 Chat에서

[11:01] 이미징이 작동하는 방식을 전면 개편하고

[11:03] 싶기 때문이거든요. 그래서 계속해서

[11:05] 샌드박스를 만들어서 T3 chat 코드베이스

[11:07] 밖에서 떠오르는 다양한 아이디어들을

[11:08] 가지고 놀면서 제가 원하는 UX를

[11:10] 찾고 있어요. 그리고 제가 작업하고 있는

[11:12] 다른 것들 중에는 피시 슬롭 게임도 있는데

[11:15] 이건 정말 독특하고 기괴한 수족관 클론이에요.

[11:18] 그렇게 독특하지는 않고요. 이 게임을

[11:20] 제대로 만들기 위해서는 작은 것들이

[11:22] 많이 필요해요. 특히 에셋 관리 같은 것들 말이죠.

[11:24] 이 게임의 에셋 작업을 위해서

[11:26] 바이브코딩으로 세 개의 별도 도구를 만들어서

[11:29] 추적하고 정리하고

[11:31] 생성하고, 수정하고, 테스트하고

[11:33] 다양한 처리 방법을 시도하는 등의

[11:35] 작업을 더 쉽게 할 수 있게 만들었어요.

[11:37] 완전한 에셋 관리 도구 세트를 구축하는 것은

[11:41] 아마 출시하지도 않을 랜덤한 게임을 위해서라면

[11:43] 정신병이죠. 하지만 지금은 훌륭한

[11:45] 실험이에요. 지금은 제가 새로운 도구를

[11:48] 시도하고, 배우고, 전에는 말이 안 됐던

[11:50] 것들을 만들 수 있는 방법이거든요.

[11:53] 1만5천 줄짜리 코드 프로젝트의 에셋 관리를 위해

[11:54] 1만 줄짜리 코드 프로젝트를 만드는 건

[11:57] 전에는 말이 안 되는 일이었어요.

[11:59] 하지만 이것이 바로 뇌를 다시

[12:01] 연결해야 하는 이유예요. 고정관념에서

[12:03] 벗어나 생각해야 해요. 전에는

[12:04] 코드로 해결하는 게 말이 안 됐던

[12:06] 것들을 코드로 해결할 수 있는

[12:07] 가능성에 대해 생각해봐야 해요. 너무 많은

[12:09] 코드가 필요하고, 그것은 너무 많은

[12:11] 노력을 의미했기 때문이죠. 코드 작성에

[12:12] 필요한 노력의 양이 크게 줄어들었어요.

[12:14] 그리고 이런 시스템들의 한계와

[12:17] 능력을 이해하게 되면, 세상을

[12:18] 조금 다르게 보기 시작해요.

[12:20] 정말 이상한 비교를 해보겠어요.

[12:22] 이 이미지를 보면

[12:23] 뭐가 보이나요? 여러분의 99.5%는

[12:27] 계단이라고 말할 거예요. 일부는

[12:30] 엘토로 20이라고 할 거고요. 이 계단은

[12:33] 스케이트보드계에서 매우 중요해요.

[12:36] 말로 표현하기 어려운 전설이 있거든요.

[12:39] 그 이유는 이 계단이 엄청나게 크고

[12:44] 여기서 점프하는 것은 정말 미친 짓이기

[12:46] 때문이에요. 많은 스케이터들이 그걸 했고

[12:50] 시도하다가 크게 다친 사람도 많아요.

[12:51] 스케이트보더들은 세상을 조금

[12:53] 다르게 봐요. 일정 시간 이상

[12:55] 스케이트보드를 타게 되면, 더 이상

[12:57] 거리를 같은 방식으로 보지 않게 돼요.

[12:59] 보드를 타고 그 위를 지나가는 게

[13:00] 어떤 느낌일지 생각하게 되거든요.

[13:02] 포장도로를. 계단도 더 이상 똑같이 보지 않아.

[13:04] 몇 개나 되는지 세어보고

[13:06] 뛰어내리기 얼마나 어려운지 계산하게 돼.

[13:07] 계단 가장자리나 난간, 벤치나

[13:09] 피크닉 테이블도 더 이상 똑같이 보지 않아.

[13:11] 새로운 방에 들어가거나

[13:13] 새로운 거리를 걸을 때

[13:16] 스케이트보드로 어떻게 탈 수 있을지

[13:19] 생각하지 않는 경우가 거의 없어. 스케이트보드를 배우면

[13:21] 세상을 조금 다르게 보게 돼.

[13:24] 모든 것이 이제 일종의 장애물이 되지.

[13:26] 그리고 코딩을 배우면 똑같은 일이 벌어져.

[13:28] 웹사이트에 가거나 앱을 열거나

[13:30] 공항 화면에서 이상한 에러를 봐도

[13:32] 다른 사람들과 같은 걸 보는 게 아니야.

[13:35] 좀 더 깊이 생각하게 돼

[13:37] 어떻게 작동하는지 더 많이 알고 있으니까.

[13:39] 이런 것들을 인식하는 방식이 달라져.

[13:40] 앱에서 에러가 나면

[13:42] 무엇이 그런 상황을 만들었는지 생각하게 돼.

[13:44] 다른 사람이 앱에서 에러를 보면

[13:45] 그냥 짜증이 나지. 또 다시 해야 하네.

[13:47] 미안한데, 뇌를 다시 연결하는 것은

[13:49] 할 수 있는 가장 어려운 일 중 하나야.

[13:51] 세상이 조금 다르게 보이지만, 이제 그래야 해.

[13:54] 그리고 다른 크리에이터들, 다른 개발자들,

[13:56] 이 영상을 보고 있는 다른 사람들에게 말하자면

[13:58] 정말 힘들고 어려워. 나도 시간이 걸렸어.

[14:01] 이런 것들을 매일 사용하면서

[14:03] 깨닫기까지 1년 반도 넘게 걸렸어.

[14:04] 그냥 뭐든 만들 수 있다는 걸 말이야.

[14:07] 랜덤한 아이디어가 있으면

[14:09] 더 이상 만드는 데 3일이 걸리지 않아.

[14:10] 몇 분이면 돼. 내가 서로 다른 AI 모델들이

[14:12] 어떻게 문장을 쓰는지 비교하고 싶었을 때

[14:15] 이런 참신한 아이디어가 떠올랐어.

[14:18] 한 모델이 에세이를 쓰고

[14:21] 다른 모델이 피드백을 주고

[14:23] 그러면 원래 모델이 에세이를 다시 쓸 수 있다면 어떨까?

[14:26] 그냥 궁금해서 이걸 자동화하고 싶었어.

[14:28] 바이브 코딩과 커서로

[14:31] 10분 정도 걸려서

[14:32] 그런 일을 할 수 있는 작업공간을 만들었어.

[14:35] 이제 이런 질문들에 답할 수 있어.

[14:37] 이런 것들을 알아낼 수 있고

[14:39] 전에는 절대 할 가치가 없었던

[14:42] 일들을 할 수 있게 됐어. 그게 정말 미친 거야.

[14:45] 개발자로서 매일 마주치는

[14:46] 온갖 것들의 세계가 있는데

[14:49] 전에는 귀찮아서 다루지 않았어.

[14:51] 자동화하는 것보다

[14:53] 손으로 하는 게 더 쉬웠거든.

[14:55] 그냥 성가셨던 작은 것들이

[14:58] 이제는 너무 사소해졌어.

[14:59] 새로운 API로 놀고 싶으면

[15:02] 문서를 클로드에 던지고

[15:04] "뭘 할 수 있어?"라고 물어봐.

[15:06] 새로운 크롬 익스텐션을 만들고 싶으면

[15:09] 커서를 열고 "이거 같이 만들어줘"라고 해.

[15:10] 소프트웨어로 해결할 수 있는

[15:13] 모든 문제가 100배 더 해결하기 쉬워졌다는 걸 깨닫는 건

[15:15] 정말 자유로워. 그리고 이건 단순히

[15:18] 또 다른 새로운 바이브코드 앱이나 프로젝트가 아니야.

[15:22] 계속 반복해서 입력하는

[15:24] 명령어 세트가 있는데

[15:27] 하나의 명령어로 할 수 있으면 좋겠다는

[15:29] 성가신 것만큼 단순할 수도 있어.

[15:30] 예시를 하나 들어볼게.

[15:33] 요점을 확실히 하기 위해

[15:35] 텍스트로도 말해볼게.

[15:37] 나한테 별칭을 만들어줘

[15:41] 모든 파일을 선택해서 커밋 메시지와 함께 커밋하고

[15:45] 즉시 푸시하는 별칭을 만들어줘. 이제 내 Zsh RC에

[15:48] git 별칭을 만들어줄 거야. 거의

[15:49] 확실히 안 될 줄 알았는데, 알고 보니

[15:51] git config global을 통해 직접

[15:53] 설정할 수 있더라고. git ACP. 이번엔

[15:55] 좀 다르게 해보자고 해보자. 한 단어로만

[15:58] 했으면 좋겠어. 이걸 내

[16:00] Zsh RC에 넣어줄 수 있을까?

[16:02] 됐다! 이제 새로운 명령어가

[16:06] 추가됐어. 이런 식으로 대부분의 사람들한테는

[16:08] 시간 투자할 만큼 가치가 없었던

[16:10] 것들이 이제는 정말 간단해졌어. 보다시피

[16:12] 전에도 이런 걸 했었는데, YTDL로

[16:14] 항상 MP4로 다운받고 싶었거든. 그래서 여기서

[16:16] 자동으로 후처리를 해주도록 했지. 이 커스텀 명령어로

[16:20] YouTube DLP를 사용하면

[16:22] MP4로 나와. 내 Zsh RC에

[16:24] 이런 게 엄청 많아졌어.

[16:25] 자주 하는 일이 있을 때마다

[16:27] 추가하거든. 자, 됐다.

[16:29] 이런 식으로 생각하기 시작하면 거의

[16:31] 다 온 거야. 하지만 다음 단계가

[16:33] 진짜 재미있는 부분이지. 사실 공정하게 말하면

[16:35] 2단계도 정말 재미있어. 하지만

[16:37] 다음 부분은 오케스트레이션이야. 그리고

[16:39] 솔직히 말하면, 이 부분은 나도

[16:41] 아직 배우고 있어. 이 부분이

[16:43] 진짜로 가속이 붙기 시작하는

[16:45] 곳이거든. 그리고 나는 지금

[16:47] 여기에 있는 기능들을 중심으로

[16:49] 내 운영체제 전체를 다시

[16:50] 생각해보고 싶은 지점에 와 있어.

[16:53] 다양한 에이전트를 어떻게 구동하고

[16:55] 각 부분들을 어떻게 연결하고

[16:56] 실제로 내가 직접 작성하지도 않는

[16:59] 글루 코드를 어떻게 작성해서

[17:01] 이런 멋진 도구들과

[17:03] 부품들을 연결할지, 모든

[17:04] 부분들을 파악하는 것들 말이야. 내가

[17:06] 게임을 작업할 때, 픽셀 아트를

[17:09] 생성하는 도구를 찾았는데 괜찮았어. 훌륭하지는 않지만

[17:12] 괜찮았지. 그걸 게임과

[17:14] 내가 작업하고 싶은 모든 다양한 기능들

[17:16] 사이에서 오케스트레이션하고

[17:18] 이 모든 걸 하나로 모으는 게 도전적이었어.

[17:21] 내가 생각해낸 부분 중 하나는

[17:22] 정말 바보같지만, 게임이 물고기 게임이야.

[17:26] 그래서 게임의 모든

[17:28] 다양한 물고기를 추적하기 위해서

[17:30] 물고기 바이블을 만들었어. 물고기 바이블은

[17:32] 게임의 모든 다양한

[17:34] 물고기와 펫을 설명하는 마크다운 파일이야. 그리고

[17:37] 게임에 변화가 생길 때마다 이 파일이

[17:39] 업데이트되어야 해. 이 파일에

[17:41] 변화가 생길 때마다 게임도

[17:42] 업데이트되어야 하고. 이걸 claude MD를 통해

[17:45] 강제하는데, 여기서 물고기 바이블 파일이

[17:47] 게임의 모든

[17:49] 생물, 물고기, 펫, 외계인에 대한

[17:50] 권위있는 참고자료라고 명시했어.

[17:52] 모든 세부사항이 담겨있고

[17:54] 동기화를 유지해야 해. 이건

[17:56] 내 claude MD에 있어. claude code를

[17:58] 사용할 때마다 이걸 최대한

[18:00] 따르려고 할 거야. 이는 또한 내가

[18:01] 코드를 많이 보지 않는다는 뜻이기도 한데, 그게

[18:03] 이 프로젝트의 요점이야. 프로젝트에서

[18:05] 코드를 얼마나 신경 쓰고 신경 쓰지 않을지의

[18:07] 범위를 갖는 것은 필수적이야.

[18:08] 그리고 이런 상자 밖에서 생각하는 부분에는

[18:10] 프로젝트에서 하고 싶어할 많은

[18:11] 일들이 있는데 시간을 투자할 만한 가치가 없는

[18:14] 코드를 작성하거나 읽을 가치도 없는 일들이죠. 하지만

[18:16] 이런 것들이 단순한 설정 스크립트나

[18:18] 이전에 손으로 하던 작업들의 자동화라면,

[18:20] 그 코드가 실제 프로덕션 서버에서

[18:22] 돌아가지 않고,

[18:24] 단지 자신의 업무를 돕기 위한 용도라면,

[18:25] 품질에 대한 기준이 달라야 하고, 실제로 그렇습니다.

[18:28] 자신의 업무에서 어디에

[18:30] 조금 허술한 코드를 넣을 수 있는지 파악하는 것이

[18:31] 이런 기술들을 더 많이 활용할 수 있는

[18:34] 좋은 기회를 제공할 것입니다.

[18:35] 그리고 장담하건대,

[18:37] 이 영상을 보는 모든 분들의 삶에는

[18:39] 조금 허술한 코드라도 유용할 수 있는

[18:41] 영역들이 있을 겁니다. 제가

[18:43] 얼마나 많은 곳에서 이런 것들을

[18:45] 활용할 수 있는지 놀랍습니다. 제 업무에서도 말이죠.

[18:48] 모든 썸네일을 추적하고

[18:50] 어떤 유형의 썸네일이

[18:52] 가장 많은 조회수를 얻는지 파악하는 도구를 만드는 것만 해도

[18:54] 이런 것들을 시각화하는 것이

[18:56] 번거로웠는데, 이제는 하루 만에 또는

[18:58] 그보다 빠르게 만들 수 있어요. 하지만 다시 말하지만,

[18:59] 오케스트레이션이 어려운 부분입니다.

[19:00] 이런 것들을 어떻게 추적하고 정리하고 조합해서

[19:03] 멋진 것들을 만들어낼 것인가? 이를 위한

[19:05] 도구들이 많이 개발되고 있고,

[19:06] 많은 개발자들이 이런 것들을 중심으로

[19:08] 자신만의 도구를 만들고 있습니다. Claudebot이

[19:10] 좋은 예시죠. Peter는 온갖 미친

[19:12] 작업들을 하고 있고, Claudebot은

[19:14] 그의 모든 것을 하나로 묶어서

[19:16] 모든 도구들을 AI 에이전트가 접근할 수 있게 만들려는

[19:19] 시도 중 하나입니다. 텔레그램이나 WhatsApp을 통해

[19:21] 대화할 수 있고 컴퓨터를 제어하는

[19:22] AI 에이전트 말이에요. 정말 멋지죠.

[19:25] 채팅에서 누군가 제가 억지로

[19:26] 슬롭 코드를 쓸 곳을 찾는다고 하는데,

[19:28] 처음에는 억지로라도 해야 하고, 그러면 깨달음이 옵니다.

[19:31] 그게 핵심이에요. 자신의 삶에서 얼마나 많은 무작위적인 작업들이

[19:34] 지루하고 자동화할 수 있는지,

[19:36] 이전에는 자동화할 가치가 없었지만

[19:38] 이제 갑자기 충분히 가치 있는 것들을 깨닫게 됩니다.

[19:41] 그런 것들이 정말 많아요.

[19:43] 저는 아직도 그런 것들이 얼마나 많은지,

[19:45] 그리고 얼마나 더 많이 찾아내고 있는지

[19:47] 놀라고 있어요. 제가 가진 모든

[19:48] 아이디어들을 목록으로 만들어 두고 있습니다.

[19:50] 정말 작업하고 싶은 것 중 하나는

[19:52] 계획 단계, 구현 단계, 리뷰 단계 사이에서

[19:54] 코드를 생성하고 싶은 작업들을 관리하는

[19:56] 칸반 보드입니다.

[19:58] 이런 기회들이 정말 많고,

[19:59] 실제 회사에서도 마찬가지예요.

[20:01] 이 영상을 만들게 된 큰 동기 중 하나는

[20:02] RAMP의 응용 AI 책임자인

[20:04] Raul의 이 게시물입니다.

[20:06] Ramp는 실제로 어려운 일을 하는 진짜 회사이고,

[20:09] AI로 정말 멋진 일들을 하고 있어요.

[20:11] 특히 오픈 코드 같은 도구들의 오케스트레이션에서 말이죠.

[20:14] 이것은 그가 이 영상을 시작하게 한

[20:15] 원래 Carpathy 게시물을

[20:17] 리트윗한 것입니다.

[20:18] 그는 여기서 상단에 대담한 발언을 합니다.

[20:20] 뒤처지면 반드시 질 것이라고.

[20:22] 실수 없는 AI 리더 플레이북은

[20:24] 다음과 같습니다.

[20:26] 이것들은 팀이 앞서 나가기 시작하는

[20:27] 좋은 아이디어들입니다.

[20:29] 코딩 에이전트를 사용하세요. 모든 엔지니어들이

[20:31] 하네스, 모델, 백그라운드 에이전트를

[20:33] 자유롭게 선택할 수 있게 하세요.

[20:35] 클로드 코드, 커서, 데본과 함께

[20:37] 모델들이죠. Meta 엔지니어들은 예전에 Llama 4를 강제로

[20:39] 써야 했는데, 정말 웃긴 일이었어요. 하지만

[20:42] 더 이상은 아니죠. 이제 원하는 걸

[20:43] 뭐든 쓸 수 있어요. 지금은 GPT-4.5가

[20:45] 기본이에요. 아마 이것도 곧

[20:46] 바뀔 거예요. 이 영상이 너무 빨리

[20:48] 구식이 되지 않았으면 좋겠는데요.

[20:50] 어떻게 될지 모르겠어요. 만약 그런 일이

[20:52] 일어나면 새 영상을 꼭 만들겠습니다.

[20:54] 그런데, 여기까지 보셨다면

[20:55] 계속 따라오고 싶으시면 구독 버튼을

[20:56] 눌러주세요. 꽤 좋은 방법이고

[20:58] 채널에도 엄청 도움이 됩니다. 다음은

[21:00] 에이전트에게 모든 개발 도구에 대한

[21:03] 접근 권한을 주는 거예요. Linear,

[21:05] GitHub, DataDog, Sentry, 내부 툴링

[21:07] 같은 것들 말이죠. 만약 에이전트가

[21:08] 컨텍스트 부족으로 제약을 받는다면

[21:11] 그건 당신 잘못이에요. 정말 과감한

[21:14] 말이죠. 저도 아직 완전히 받아들이고

[21:15] 있는 중이지만, 너무 많은 설득력 있는

[21:17] 사례들을 봐서 무시하기 어려워요.

[21:20] 여기 RAMP의 한 엔지니어가 자신들이

[21:22] 만든 멋진 봇 중 하나인 내부 inspect 봇을

[21:24] 데모하는 예시가 있어요. 그들이

[21:27] 추가한 건 '코어에서 가장 흔한 Sentry

[21:29] 이슈 20개가 뭐고, 그걸 고치는 하위

[21:32] 세션을 시작해'라는 거였어요. 그래서 봇이

[21:34] 가장 흔한 오류 20개를 찾고 각각에 대해

[21:37] PR을 하나씩 만들었어요. 정말

[21:38] 미친 거죠. 그리고 이건 그들이

[21:40] 파는 도구가 아니에요. 어떤

[21:41] 미친 제품을 내놓으면서 '모두들

[21:44] inspect를 설치하세요'라고 말하려는

[21:45] 게 아니라, 그냥 그들만의 내부

[21:47] 탐색과 사용이에요. 왜냐하면 이런 걸

[21:49] 하는 게 이제 그 어느 때보다 정당화되거든요.

[21:51] 시간 측면에서 그렇게 비싸지 않으니까요.

[21:54] 또 다른 중요한 부분은 코드베이스별

[21:57] 에이전트 문서에 투자하는 거예요.

[21:59] 'X를 잘 못한다'고 말하는 걸 그만하세요.

[22:01] 그게 문제라면 더 나은 프롬프팅과

[22:03] agents MD 파일, 린팅, 코드 룰을

[22:05] 시도해보세요. 이것들은 실제로 정말

[22:07] 중요한 부분들이에요. 에이전트들은

[22:09] 뭐가 잘못됐는지 피드백을 받으면 훨씬

[22:11] 똑똑해져요. LSP를 설정하고

[22:13] 사용하세요. 제발, 하나님을 위해서라도

[22:15] 아직 안 쓰고 있다면 타입 언어를 쓰세요.

[22:17] 그러면 코드에 타입으로 확인 가능한

[22:19] 오류가 있을 때, 그 오류들을 에이전트에게

[22:22] 피드백으로 줄 수 있고 고칠 수 있어요.

[22:24] OpenAI Code는 기본적으로 이걸 해요.

[22:26] Claude Code가 이걸 추가했어요.

[22:28] 아직 완전히 지원되지는 않지만요.

[22:30] Cursor는 이걸 기본적으로 정말 잘 작동하게 만들었어요.

[22:33] 좋은 린팅과 코드 룰, 타입 안전성이 있으면

[22:35] 갑자기 이 에이전트들이 첫 번째

[22:36] 시도에서 생겼을 많은 오류들을 고칠 수

[22:38] 있게 되고, 처음부터 작동할 가능성이

[22:40] 더 높은 결과를 가져다 줄 거예요.

[22:42] 그리고 특히 agent MD는 정말

[22:43] 중요한 부분이기도 해요. Claude Code 팀이

[22:46] 내부 repo의 Claude MD 파일을

[22:48] 하루에 여러 번 바꾼다고 알려져 있어요.

[22:50] 팀의 누군가가 Claude가 뭔가에 대해

[22:53] 잘못된 길로 갔다는 걸 알아차리면

[22:55] 다음번엔 그러지 않기를 바라는 게 아니라

[22:57] CloudMD 파일로 가서 '이렇게 하지 마'라는

[22:59] 지침을 추가해요. 이걸 생각하는 좋은

[23:01] 방법은 생성된 코드에서 당신이 하는

[23:02] 모든 수동 편집이 개선을 위한 기회라는

[23:05] 거예요.

[23:07] 에이전트 MD 개선을 위한 기회입니다. 다음으로,

[23:09] 견고한 백그라운드 에이전트 인프라에 투자하세요.

[23:12] VM과 샌드박스에서 작동하는

[23:14] 완전한 개발 스택을 구축하세요. 설정하기는 어렵지만,

[23:16] 그만한 가치가 있을 것입니다. 이제 엔지니어들이

[23:18] 여러 작업을 병렬로 실행할 수 있습니다. 코드

[23:20] 리뷰가 곧 병목 지점이 될 것입니다.

[23:21] 이는 제가 실제로

[23:22] 추가하고 싶은 또 다른 사항입니다. 0단계처럼 말이죠.

[23:25] 정말로 이런 것들을 시작하는데

[23:27] 어려움을 겪고 있다면, 최소한

[23:30] 여러분의 레포지토리에 AI 코드 리뷰 도구를

[23:33] 추가해 주세요. 많은 도구들이 있습니다.

[23:35] 일부 도구들에 대한 논란도 있고요.

[23:37] 개인적으로는 주로 Grapile과 Code

[23:39] Rabbit을 사용합니다. 모든 개인 작업과

[23:42] 사이드 프로젝트에서 Grapile을 사용하고요. 팀은 여전히

[23:44] T3 채팅에서는 Code Rabbit을 약간 더 선호하지만,

[23:46] 둘 다 정말 좋습니다.

[23:48] 꽤 좋은 다른 옵션들도

[23:49] 많이 있습니다. 이런 도구들은

[23:51] 시작하기에 매우 도움이 됩니다. AI의 가치를

[23:53] 정말 빠르게 확인할 수 있는

[23:56] 훌륭한 방법입니다. 네, 코드 리뷰가 병목이 될 것이지만,

[23:57] AI 코드 리뷰도 사용해 주세요.

[23:59] 유일한 코드 리뷰가 아니라,

[24:00] 그냥 보완용으로 말입니다. AI가 실수를

[24:02] 사람이 리뷰하기 전에

[24:04] 미리 잡아내는 것은 정말 좋습니다. 또한,

[24:06] 중요한 것은, 보안 문제를

[24:07] 해결하는 것입니다. 위험 회피적이지 말고

[24:09] 접근을 차단 해제하기 위해 필요한 일을

[24:10] 하세요. 여기에 완전히 동의합니다. 그리고

[24:13] 초급 엔지니어들에게도

[24:15] 같은 것을 말하고 싶습니다. 저는 너무 많은

[24:16] 걱정을 했었죠. 오, 이런 사람들에게

[24:18] 배포 권한을 주면

[24:21] 모든 프로덕션을 망가뜨릴 수 있다고요.

[24:28] 그리고 이제 실제로 AI로

[24:29] 제품을 구축할 때 중요한 부분들에서는, 항상

[24:32] 최신 세대 모델을

[24:34] 기능에 사용하세요. 견고한 평가가

[24:36] 달리 나타내지 않는 한, 구세대

[24:38] 모델에서 가능한 한 빨리 옮기세요. 매우 드물어요.

[24:40] Gemini 같은 것을 쓰지 않는 한

[24:41] 세대 변화가 실제로

[24:43] 다운그레이드인 경우는요. 몇 주마다

[24:44] 변경 사항을 만들어야 할 거에요. GitHub

[24:46] Copilot 모바일 앱이 여전히

[24:48] GPT 4.1과 Sonnet 3.5로 코드 리뷰를 제공하고 있어요.

[24:52] 정말 웃기네요. Sonnet 4나

[24:54] GPT40을 사용하지 않음으로써

[24:56] 돈을 테이블에 남겨두고 있는 거죠. 절대적으로요.

[24:58] 이런 것들을 따라가세요. 퍼지 검색 대신

[25:00] 임베딩 시맨틱 검색을 사용하세요. 어떤 일반

[25:02] 임베딩 모델이라도

[25:04] 전통적인 퍼지 검색 휴리스틱보다 더 잘 할 것입니다. 네,

[25:07] 검색은 그런 큰 부분들 중 하나입니다.

[25:09] 이런 도구들 중 많은 것들이 이제,

[25:11] cursor나 claude code 같은 것들이

[25:14] 더 이상 전통적인 검색을 사용하지 않습니다.

[25:15] 그들은 모델에게 그렇다고 말해서

[25:17] 모델이 새로운 것을 배울 필요가 없게 합니다. 그리고

[25:18] 뒤에서 조용히 더 나은

[25:20] 검색 시맨틱을 사용해 더 나은

[25:22] 결과를 얻습니다. 어떤 양식도 비워두지 마세요.

[25:24] 사용자에 대한 어떤 맥락에서든

[25:26] 구조화된 출력을 사용해 더 나은 최선의

[25:29] 노력 미리 채우기를 하세요. 좋은 아이디어네요.

[25:31] 저도 여러 가지에서 그것을 더

[25:32] 고려해봐야겠습니다. 모든 제품 표면에서

[25:35] 구조화되지 않은 입력을 허용하세요. 자유 형식 텍스트와

[25:36] 문서를 받아들여야 합니다. 양식은 죽었습니다. 또한

[25:38] 매우 흥미로운데요. 제가 완전히 동의하는

[25:40] 또 다른 점은 커스텀 파인튜닝은

[25:41] 죽었다는 거예요. 더 이상 시간 낭비 그만하세요.

[25:43] 프론티어가 너무 빠르게 발전해서

[25:45] 8주나 걸리는 파인튜닝에 투자할 가치가 없어요.

[25:47] 비용도 너무 빨리 떨어지고 있어서

[25:49] 가격은 더 이상 중요하지 않습니다.

[25:50] 더 나은 프롬프팅이

[25:52] 훨씬 멀리 갈 수 있게 해줄 거예요.

[25:54] 지시어 따르기가 개선될수록

[25:56] 이건 더욱 사실이 되고 있어요. 정말로

[25:58] 이 점을 강조하고 싶습니다.

[26:00] 제 목록으로 다시 돌아가서요.

[26:03] 한계를 발견했을 때, 모델에

[26:05] 프롬프트를 작성했는데 원하는 걸 못할 때,

[26:07] 그 한계를 넘어서도록 노력해보세요.

[26:10] 이를 위한 전략들이 있어요. 프롬프트를 개선하거나,

[26:15] 특히 프롬프트에 더 많은 맥락을 제공하거나,

[26:16] Claude MD나 Aider MD를 조정해서

[26:18] 코드베이스와 작업 방식에 대한 더 나은 리소스를 제공하는 거예요.

[26:21] 모델에 더 나은 피드백을 주는 도구를 추가하기도 해요.

[26:23] LSP 지원, 린팅 같은 것들이죠.

[26:26] 한계를 발견했을 때

[26:28] 모델이 그 한계를 넘을 수 있는지 확인해보세요.

[26:31] 저는 정말 놀랐어요.

[26:34] 조금 더 나은 도구를 제공하고

[26:36] claim MD 파일을 조정하는 것만으로도

[26:38] 얼마나 많은 것을 할 수 있는지요.

[26:40] 똑같은 프롬프트를 똑같은 코드베이스에서 써도

[26:42] 더 나은 결과를 얻을 수 있어요.

[26:45] 절대 되돌리지 않고

[26:47] 작동할 때까지 계속 프롬프팅하는

[26:49] 전략을 맹신하는 사람들이 있어요.

[26:51] 예를 들어 QuadBot을 만든 Pete는

[26:53] 이 전략을 맹신하죠.

[26:54] 그가 여기서 말하듯이, 기본적으로

[26:56] 절대 되돌리거나 체크포인트를 사용하지 않아요.

[26:58] 뭔가 마음에 들지 않으면 모델에게 바꿔달라고 요청하죠.

[27:02] 저는 아직 거기까지는 아니에요. 개인적으로는

[27:05] 여전히 되돌리는 걸 좋아해요.

[27:07] 구조를 배워서 첫 번째 시도에서

[27:09] 제대로 할 수 있게 되려고요.

[27:11] 하지만 이건 사람마다 다르죠. 계속 작업하고,

[27:15] 놀아보고, 실험해보세요.

[27:16] 정말 이런 도구들뿐만 아니라

[27:18] 자신의 한계도 밀어붙여봐야 해요.

[27:20] 이상하고 불편하게 느껴질 거예요.

[27:23] 가치를 못 느끼고 있다면

[27:25] 아직 거기까지 못 간 거예요.

[27:27] 가치를 느낄 때까지 계속 밀어붙이세요.

[27:29] 정말 많은 재능있는 개발자들이

[27:31] 이런 도구들로 말도 안 되는 일들을 하고 있어요.

[27:34] 여러분도 그렇게 할 수 있지만, 더 많이 가지고 놀아봐야 해요.

[27:36] 정말 똑똑한 사람들 얘기가 나왔으니,

[27:37] Nean이 채팅에 있네요.

[27:39] Nean은 Stylex의 제작자인데,

[27:41] 제가 본 것 중 가장 멋진 스타일링 라이브러리 중 하나예요.

[27:43] Meta에서 대규모 스타일링을 처리하는 데 사용되었죠.

[27:46] 라이브러리는 정말 멋지고 Nean은 정말 똑똑해요.

[27:48] Nean이 방금 채팅에서 되돌리기는

[27:51] 모델에 따라 다르다고 했어요.

[27:53] Codex는 자신이 만든 나쁜 변경사항을

[27:55] 고치는 데 훨씬 낫고

[27:57] Opus는 그게 덜해서

[27:58] 되돌리기의 이점을 받는다고 했어요.

[28:00] 이건 이런 것들을 실험하고

[28:02] 더 가지고 놀아보면서 얻는 지식이에요.

[28:04] 그냥 해야 해요. 깊이 들어가세요.

[28:06] 손을 더럽히세요. 불편해하세요.

[28:08] 적어도 조금이라도 불편하지 않다면

[28:09] 충분히 노력하지 않는 거예요.

[28:11] 가혹한 현실이지만 우리가 지금

[28:13] 처한 현실이에요. 머릿속과 업무에서

[28:15] 여기서 더 이야기하고 싶은 것들이 있습니다.

[28:16] 평가 시스템 구축이 필수적입니다.

[28:18] 빠른 모델 업그레이드 결정을 위해 많은 평가를 만들어야 합니다.

[28:20] 완벽할 필요는 없지만

[28:22] 최소한 모델들을 서로 비교할 수 있어야 합니다.

[28:24] 대부분의 결정은 파레토 비용 대 벤치마크 성능

[28:26] 플롯에서 명확해집니다.

[28:28] 맞습니다. 정말 맞습니다.

[28:30] 벤치마크를 즉흥적으로 코딩하는 것은 정말 쉽습니다.

[28:33] 시작하기에 가장 좋은 방법 중 하나입니다.

[28:35] AI가 당신과 당신의 업무에서 잘하고 있거나

[28:37] 잘하지 못하는 부분을 발견하면

[28:40] 그것을 분리해서 벤치마크로 만드세요.

[28:42] 빠르고 특이한 일회성 벤치마크를 만들어보세요.

[28:44] 자신만의 평가를 커스터마이징하고 구축하는 것은 정말 재미있습니다.

[28:47] 저도 정말 재미있게 해왔습니다.

[28:48] 다른 사람들이 더 쉽게 할 수 있도록

[28:50] 도구를 내놓으려고 했지만

[28:51] 더 이상 그럴 필요가 없다고 느꼈습니다.

[28:53] 그냥 즉흥적으로 코딩하세요.

[28:54] ASDK와 오픈 라우터를 사용하라고 하고 마음껏 해보세요.

[28:57] 마지막 부분인데, 이건 회사 리더들에게 필수적입니다.

[28:59] 저도 똑같이 하려고 노력하고 있습니다.

[29:00] 모든 엔지니어들이 AI로 구축하도록 격려하세요.

[29:02] 모든 코드베이스에서 모델을 호출할 수 있는 기본 요소들을 구축하세요.

[29:04] 구조화된 출력, 의미적 유사성 엔드포인트

[29:05] 샌드박스 코드 실행 등등

[29:07] 정말 좋은 것들이 많습니다.

[29:09] 마지막으로 한 가지 더. 이건 제가 정말로 내재화하고 있는 부분입니다.

[29:12] 추론 비용에 대해 너무 걱정하지 마세요.

[29:14] 추론 수익과 손실이

[29:16] 훨씬 더 높아야 합니다.

[29:17] 비용이 너무 빠르게 떨어지고 있어서

[29:19] 이것이 중요하지 않습니다.

[29:21] 연간 x백만 달러가 아닙니다.

[29:22] 앞으로 y주 동안 주당 x를 52로 나눈 것입니다.

[29:25] 맞습니다. 이번 주 추론 청구서가

[29:28] 주당 3,000달러라면

[29:31] 새로운 것들이 출시되고 변화하고

[29:33] 다르게 동작함에 따라

[29:36] 주간 기준으로 상승할 가능성만큼이나 하락할 가능성도 높습니다.

[29:38] 상황이 정말, 정말, 정말 빠르게 변화하고 있습니다.

[29:40] 그리고 여러분은 이 모든 새로운 것들을 시도하기 위해

[29:42] 적극적으로 나서야 합니다.

[29:44] 이제 이 대부분이 리더들에게 초점을 맞춘 것이라는 걸 알고 있습니다.

[29:46] 시청하는 모든 사람이 아니라요.

[29:48] 사실 시청하는 대부분의 사람들은

[29:49] 아마 매니저가 아닐 겁니다.

[29:51] 아마 개별 기여자, 개발자 지망생이거나

[29:54] 코드 작업을 독립적으로 하는 사람들일 것입니다.

[29:56] 여러분의 직장에서 그런 종류의

[29:58] 지원이 없다면

[29:59] 이 모든 것을 할 수 없을지도 모릅니다.

[30:01] 독립적으로 할 수 있는

[30:02] 모든 기회를 찾아보세요.

[30:04] 가능하다면 직장에 몰래 도입해보세요.

[30:06] 그것이 잘 안 된다면 더 좋은 직장을 찾으세요.

[30:08] 예를 들어 Ramp에서 채용 중이라는 걸 알고 있습니다.

[30:10] 라울이 실제로 이것을 언급해달라고 부탁했습니다.

[30:11] 이것을 써준 라울에게 감사합니다.

[30:13] 여러분도 그를 확인해보고

[30:15] 관심이 있다면 그와 이야기해보세요.

[30:16] 링크는 이 게시물의 설명에 있을 것입니다.

[30:18] 이런 일을 할 수 있는 곳을 찾으세요.

[30:20] 사이드 프로젝트로

[30:21] 독립적으로 그런 곳을 직접 만들 수도 있습니다.

[30:23] 직장에서 그런 종류의 것을 허용한다면

[30:24] 직장에 몰래 도입할 방법을 찾을 수도 있습니다.

[30:26] 일반적으로 지금 그 어느 때보다

[30:28] 허가보다는 용서를 구하는 것이

[30:30] 거의 필수적으로 느껴집니다.

[30:34] 직장에서 이런 도구들 사용을 허가하지 않는다면

[30:35] 어쨌든 사용하세요.

[30:38] 이제 동료들보다 훨씬 앞서게 되어

[30:40] 회사에서 선구자로 인정받거나

[30:42] 아니면 그것 때문에 해고당하겠지만

[30:44] 다른 곳 면접에서 할 멋진 이야기가 생길 거야

[30:46] 약속하는데 만약 라울 같은 사람에게 가서

[30:48] "야, 네가 쓴 글에 나온

[30:50] 직장에 AI를 도입하는 방법들을 다 시도해봤는데

[30:52] 아무도 그 가치를 인정하지 않아서

[30:53] 해고당했어. RAMP에서 일하는 것이

[30:56] 어떨지 얘기해볼 수 있을까?"라고 했다면

[30:59] 분명히 좋은 대화가 될 거야

[31:01] 모든 면에서 한계를 밀어붙여라

[31:02] 그것이 내가 여기서 강조하고 싶은 주제야

[31:05] 도구를 얼마나 많이 사용할 수 있는지

[31:06] 도구가 무엇을 할 수 있는지

[31:09] 그리고 직장 동료들이

[31:11] 무엇까지 허용하려 하는지의 한계를 찾아라

[31:13] 그 한계들을 최대한 강하게 밀어붙이고

[31:15] 어디로 이끌어가는지 봐라

[31:17] 놀라게 될 거야. 먼저 그 한계들이

[31:20] 얼마나 멀리 떨어져 있는지

[31:22] 이 시스템들이 얼마나 능력이 있는지

[31:25] 그 한계들을 얼마나 잘 우회할 수 있는지

[31:26] 그리고 결과적으로 얼마나 많은 일을

[31:29] 해낼 수 있는지 말이야

[31:31] 만약 매니저가 확신하지 못한다면

[31:33] 이 부분을 보내줘라

[31:35] 안녕, 기술회사 X의 매니저님

[31:38] 엔지니어들이 이런 도구들을 사용하도록 하는 것이

[31:40] 정말 중요해요. 최고의 엔지니어들은 이미

[31:42] 업무 대부분에서 대부분의 시간 동안

[31:44] AI 도구를 사용하여 도움을 받는 방향으로

[31:46] 움직였습니다

[31:47] 만약 직원들이 이를 하지 못하게 한다면

[31:49] 의도적으로 뒤처지게 만드는 것이고

[31:51] 그들은 떠날 것이며

[31:52] 회사는 실패할 거예요

[31:54] 개발 세계에서 AI에 반대하는 것은

[31:56] 어떤 미친 고귀한 신념이나

[31:58] 사용자를 보호하는 방법이 아닙니다

[31:59] 회사 최고의 개발자들을 화나게 하고

[32:01] 승리하지 못하게 막는 방법이에요

[32:03] 이기고 싶다면 팀이 최고의 도구를

[32:04] 사용하도록 해야 합니다

[32:06] 그리고 지금 그 도구들 대부분에는

[32:08] AI가 포함되어 있어요

[32:10] 고집 버리고 직원들이 원하는 것을

[32:12] 사용하게 하세요

[32:13] 그들이 얼마나 더 생산적이 되는지

[32:15] 놀라게 될 거예요

[32:17] 여기서 할 말은 다 한 것 같네요

[32:20] 앞서 나가는 방법에 대한

[32:21] 정말 재미있는 심층 분석이었어요

[32:24] 최고 댓글이 뭘지 알겠어요. "안녕 테오, 나는 학생인데 어떻게 따라잡을 수 있을까요?"

[32:28] 모르겠어요. 지금 시점에서

[32:30] 학생이 아닌 것이 감사해요

[32:32] 답을 찾게 되면

[32:33] 미래에 그에 대한 비디오를 꼭 만들겠어요

[32:36] 하지만 지금은 계속 만들고, 계속 출시하고

[32:38] 계속 일하고, 계속 한계를 밀어붙이세요

[32:40] 그러면 아마도 멋진 곳에

[32:41] 도착하게 될 거예요

[32:43] 이번 영상은 여기까지예요. 따라잡기 힘들겠지만 행운을 빌어요. 다음에 또 만나요, 너드들아