AI 코딩 도구를 잘못 사용하고 있습니다

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

요약

이 영상에서는 코드 작성 자체가 소프트웨어 개발의 진짜 병목이 아니라고 지적합니다. 오히려 코드 리뷰, 테스트, 디버깅, 협업과 의사소통 같은 프로세스가 더 큰 장애물입니다. AI 코딩 도구는 프로토타입 제작과 반복 개선 속도를 획기적으로 높일 수 있지만, 전통적 개발 프로세스에 그대로 적용하면 오히려 부담만 늘어납니다. 따라서 AI를 도입하려면 프로세스를 재설계해 소수의 팀이 빠르게 프로토타입을 만들고 피드백을 반복하면서 진짜 가치 있는 기능을 찾아야 합니다.

주요 키워드

병목(bottleneck) 프로토타이핑(prototyping) 코드 리뷰 반복 개선(iterative improvement) 팀 이해 AI 코딩 툴 T3 스택 프로세스 재설계

하이라이트

🔑 코드 작성이 병목이 아니다: 코드 리뷰, 지식 전수, 디버깅, 협업이 실제 병목 요인이다.
🚀 AI 코딩 도구는 대형 코드베이스 검색과 프로토타입 제작에 강점을 발휘하지만, 전통적 프로세스에선 리뷰 부담만 늘린다.
⚡️ 빠른 프로토타입 루프: PM·디자이너·개발자 3인이 수일 내에 데모를 제작해 사용자 피드백을 받는 방식을 제안한다.
🌟 Throwaway code vs Production code: 임시 코드(프로토타입)와 프로덕션 코드는 목적이 다르므로 구분하여 활용해야 한다.
📌 프로세스 재설계: Identify→Prototype→Feedback 반복 후 최소 스펙만 작성하고, 프로덕션 빌드를 진행해야 한다.
🚀 T3 스택 사례: Twitch에서 GraphQL 대신 빠른 반복과 풀스택 타입 안전성을 살린 T3 스택으로 높은 생산성을 달성했다.
⚡️ 팀 이해가 핵심 병목: AI로 코드 작성 비용은 낮아졌지만, 팀 전체의 이해와 공유 노력은 여전히 필수다.

용어 설명

Throwaway code

프로토타입이나 테스트용으로 빠르게 만들어 나중에 버려지는 임시 코드

Production code

실제 서비스 환경에서 유지보수·운영되는 핵심 코드

T3 스택

Turborepo, TypeScript, tRPC, Tailwind CSS 등을 조합해 빠르고 타입 안전한 애플리케이션을 만드는 스택

AI 에이전트

사용자 요청에 따라 코드를 생성하거나 자동화 작업을 수행하는 인공지능 도구

LLM(대형 언어 모델)

대규모 텍스트 데이터를 학습해 자연어와 코드를 생성하는 언어 모델

Prototype(프로토타입)

아이디어 검증을 위해 최소 기능만 구현한 초기 버전

Augment Code

대규모 코드베이스를 인덱싱해 빠른 코드 검색·생성을 돕는 AI 도구

오늘날 우리는 AI 코딩 도구로 더 많은 코드를 생성하지만, 실제 제품에 적용되는 기능은 늘어나지 않습니다. 코드 작성이 개발 속도를 좌우하지 않으며, 더 근본적인 병목은 다른 단계에 있다는 의문으로 토론을 시작합니다.

[00:00] AI 코딩 도구로 인해 많은 사람들이 몇 년 전보다 훨씬 더 많은 코드를 작성하고 있지만, 실제 제품에서 더 많은 기능이 출시되거나 혁신이 일어나는 것은 보이지 않는다.

[00:30] 갑자기 코드 작성을 기다릴 필요가 없어졌다면 더 많은 기능이 나와야 할 것 같지만, 가혹한 현실은 코드가 결코 병목이 아니었다는 것이다.

[01:01] 기능 출시와 애플리케이션 구축에는 AI로 생성할 수 없는 너무 많은 부분들이 있으며, 이런 것들은 AI로 인해 약간 나아질 수는 있지만 기대 수준에는 못 미친다.

[01:26] 모든 엔지니어가 PM이 될 것은 아니지만, 몇 년 후 엔지니어의 역할에 대한 깊은 고민이 필요하며, 이 주제를 탐구하기 전 스폰서 소개를 하겠다.

Augment Code는 대규모 코드베이스 인덱싱을 통해 파일 검색과 코드 생성을 빠르게 지원합니다. React 같은 오픈소스 프로젝트 전체를 짧은 시간에 인덱싱해 질문만으로 구현 세부 내용을 확인할 수 있다는 점을 강조합니다.

[01:42] AI는 코드 작성에 뛰어나지만 큰 코드베이스에서는 컨텍스트 처리에 한계가 있다. Augment Code는 더 나은 컨텍스트를 제공하여 이 문제를 해결하며, 특히 거대한 오픈소스 프로젝트 탐색에 유용하다.

[02:18] Augment AI 도구의 놀라운 속도와 성능을 소개합니다. 59만 라인의 React 코드베이스를 몇 초만에 완전히 인덱싱하고, 어떤 질문에도 즉시 답변할 수 있는 능력을 보여줍니다.

[02:47] Augment의 우수성을 증명하는 사용자 후기들과 무료 시작 옵션을 소개하며, 대기업을 위한 AI 솔루션으로 추천합니다.

코드 리뷰, 지식 전수, 테스트, 디버깅, 그리고 팀 간 의사소통이 진짜 병목 요소입니다. LLM 덕분에 코드 작성 비용은 거의 제로에 가깝지만, 이해·검증 비용은 오히려 높아졌습니다.

[03:05] 소프트웨어 엔지니어링에서 코드 작성 자체는 병목이 아니었다고 강조합니다. 진짜 병목은 코드 리뷰, 지식 전수, 테스팅, 디버깅, 그리고 인간 간의 조정과 소통이었습니다.

[03:40] LLM으로 코드 생성이 쉬워졌지만, 코드를 이해하고 테스트하고 신뢰하는 비용은 오히려 더 높아졌다고 지적합니다. 새로운 소프트웨어 추가의 한계 비용은 거의 제로에 가까워졌지만, 품질 보증 비용은 증가했습니다.

가짜 마감일을 설정해 미리 구현을 끝내고, 남은 시간을 버그 수정·성능 개선·UI 다듬기에 활용했습니다. 이 전략으로 ModView 같은 주요 기능을 빠르게 출시하고 품질을 확보했습니다.

[04:00] Twitch에서의 개인적 경험을 공유합니다. 마감을 맞춰야 할 때 호출받는 역할을 했으며, 실제 마감보다 2주-2달 앞선 가짜 마감을 설정해 여유 시간으로 제품을 완성도 높게 다듬는 전략을 사용했습니다.

[04:33] 화자가 ModView on Twitch 프로젝트를 성공적으로 완성했던 경험을 설명하며, 채팅 기능을 제외한 모든 부분이 잘 작동하는 커스터마이즈 가능한 위젯들을 자랑스럽게 소개한다.

[04:49] 런칭 준비를 위해 PM에게 일찍 데드라인을 요청하여 한 달 일찍 완성한 후, 남은 시간을 버그 수정과 성능 개선, 완성도 높이기에 투자했다고 설명한다.

GraphQL의 타입 안전성은 좋았지만 도입 비용이 컸습니다. 대신 소규모 스택을 빠르게 결합해 반복 가능하게 만든 T3 스택을 고안했고, 이를 통해 초기에 잘못된 가정을 빠르게 검증하며 개선했습니다.

[05:08] 화자는 자신의 특별한 능력이 빠른 출시를 위해 적절한 부분을 잘라내면서도 품질을 타협하지 않는 것이라고 설명하며, 이것이 자랑이 아닌 고유한 스킬이었다고 강조한다.

[05:28] 현재도 팀의 T3 채팅 계획을 볼 때 문제 영역을 단순화하고 성공 경로를 개선하기 위해 제거할 수 있는 부분을 찾는 방식으로 일한다고 설명한다.

[05:47] GraphQL의 풀스택 타입 안정성이 트위치에서 큰 도움이 되었지만, 많은 인력이 필요한 점을 지적하며 T3 스택 개발의 동기를 설명한다.

문제 정의, 사용자 인터뷰, 디자인, PRD 작성, 프레젠테이션, 기술 스펙 작성, 구현, 출시까지 평균 6~18개월이 걸립니다. 안전 팀에서는 이 과정을 대폭 단축해 7개월 만에 주요 기능을 배포한 경험을 소개합니다.

[06:14] T3 스택으로 빠른 출시가 가능해진 것이 좋은 앱을 만든 이유라고 설명하며, 완벽한 첫 시도가 아닌 빠른 제작과 사용자 피드백을 통한 반복 개선이 핵심이었다고 강조한다.

[06:31] 이러한 능력 덕분에 오랫동안 큰 이점을 누리며 컨설팅 업무도 했지만, 현재는 AI 에이전트가 자신이 하던 일의 많은 부분을 대체할 수 있어 이점이 줄어들었다고 느낀다고 토로한다.

[06:52] AI 에이전트가 빠른 배포를 대신 처리해주어 기존 프로세스의 많은 단계들을 건너뛸 수 있다는 점을 설명하며, 트위치에서의 디자인 프로세스 사례를 소개합니다.

[07:05] 트위치의 제품 개발 프로세스 1-2단계로, 제품 매니저가 사용자 피드백이나 이벤트를 통해 문제를 식별하고, 해당 문제에 대해 사용자들과 심도있는 대화를 나누는 과정을 설명합니다.

PM-디자이너-개발자 3인이 수일 내 프로토타입을 제작한 뒤 실제 사용자에게 검증합니다. 스펙과 회의 단계를 최소화하고 피드백을 반영해 제품 방향을 빠르게 바꿀 수 있는 워크플로우를 제안합니다.

[07:35] 3-4단계에서는 디자인팀과 협력하여 해결책의 모습을 구상하고, 5-30페이지 분량의 제품 제안 명세서를 작성한 후 PM과 경영진에게 각각 프레젠테이션하는 과정을 다룹니다.

[08:18] 개발자들이 인계받아 명세서를 검토하고 제품팀과 논의한 후 자신들만의 긴 명세서를 작성하지만, 이 전체 프로세스가 6-18개월이라는 매우 긴 시간이 걸린다는 문제점을 지적합니다.

AI로 빠르게 코드를 생성하면 리뷰·머지 부담과 비생산적 회의가 늘어납니다. 도구는 코드 작성만 가속화할 뿐, 프로세스 상위 단계에서 필요한 의사결정·협업·검증은 그대로 남습니다.

[08:45] 보안팀에서는 긴급성 때문에 이런 단계들을 건너뛰고 신속하게 문제를 해결했지만, 다른 조직에서는 문제 식별부터 해결책 문서 완성까지 몇 개월에서 몇 년이 걸렸다고 설명합니다.

[09:06] 보안팀에서는 대부분 이런 긴 프로세스를 거치지 않았고, 드물게 거쳤을 때는 기존 해결책을 처음부터 재검토하고 싶을 때였으며, Mod View를 예로 들어 기존 스트림 관리 도구들의 한계를 설명합니다.

[09:25] 트위치 모더레이션 도구의 문제점과 개선 필요성을 설명하며, 기존 도구들이 스트리머들이 필요로 하는 수준의 모더레이션에 부족했고, 실제로 도구 재개발에 7개월이 걸렸다고 언급

[09:39] 잘못된 제품 개발 프로세스의 문제점을 지적하며, 스펙 단계를 훨씬 넘어선 프로젝트들이 실제 사용자의 요구를 반영하지 못하고 결국 실패하는 사례들을 경험했다고 설명

임시 프로토타입 코드는 가설 검증과 학습을 위해 버려져야 하고, 프로덕션 코드는 유지보수·신뢰성 확보에 초점을 둡니다. 두 코드 유형을 목적에 맞게 구분하고 전환해야 효율이 높아집니다.

[10:10] 프로젝트가 엔지니어 배정, 티켓 생성, 마감일 설정까지 진행된 후에야 문제가 발견되고, 결국 제품이 출시되어도 실패해서 되돌려야 하는 악순환이 트위치에서 반복되었다고 토로

[10:52] 실제 사용자 문제를 해결하지 못하거나 오히려 사용자 경험을 악화시키는 기능들이 개발되는 것이 매우 흔한 일이었으며, 이는 개발 프로세스의 근본적인 문제라고 진단

[11:11] 이런 문제의 해결책으로 자신이 사용한 빠른 코딩 접근법을 소개하기 시작하며, 코드가 병목이 아니라는 점을 강조하고 PM들이 자신의 제품에 대한 관심을 인정했다고 설명

[11:36] 기존 엔지니어들과 다른 자신만의 접근 방식을 설명하며, PM과 디자이너가 문제를 식별한 후 빠르게 프로토타입을 구축하고 실제 사용자 피드백을 받아 제품을 개선하거나 포기하는 방법론을 제시

AI를 도입하려면 Identify→Prototype→Feedback 반복 중심으로 프로세스를 재구성해야 합니다. 빠른 학습 루프를 통해 인사이트를 얻고, 스펙과 구현 단계에서는 핵심 부분만 다루며 팀 이해를 극대화합니다.

[12:24] 기존의 제품 개발 프로세스에서 많은 단계들이 제거될 수 있다고 설명합니다. 디자인 단계가 점진적 반복으로 대체되고, 제품 제안서나 스펙 문서 대신 실제 데모가 스펙 역할을 하게 됩니다.

[12:43] 전통적인 개발 핸드오버 과정이 사라지고, 처음부터 끝까지 같은 팀이 작업하게 됩니다. 이미 실제 구현을 해봤기 때문에 더 현실적이고 정확한 스펙을 작성할 수 있게 됩니다.

[13:06] 화자가 기존 프로세스에 대해 느꼈던 좌절감을 설명합니다. 며칠이면 증명할 수 있는 것들을 위해 긴 과정을 거치는 대신, 일찍 작업을 시작해서 실제 작동하는 버전을 먼저 만들어 보여줍니다.

코드 작성 비용은 낮아졌지만 팀 이해와 협업 비용은 여전히 병목입니다. AI 툴은 프로토타이핑과 피드백 주기를 빠르게 만들어주므로, 이를 활용해 개발 프로세스를 근본적으로 재설계해야 진정한 생산성 향상을 이룰 수 있습니다.

[13:30] 빠른 개발 능력을 활용해 불필요한 프로세스를 건너뛰고 시간 낭비를 줄이는 방법을 찾았다고 설명합니다. 참조 버전이 있으면 모든 단계가 더 효율적이고 현실적이 됩니다.

[14:00] 기존의 선형적 개발 프로세스(연구→디자인→스펙→개발→출시→기도→폐기)와 대비되는 새로운 접근법을 제시합니다. 식별, 프로토타이핑, 피드백 수집을 반복하는 순환적 프로세스를 제안합니다.

[14:36] 피드백 루프 구축에 집중하는 것이 핵심이라고 강조합니다. 만족스러운 상태에 도달할 때까지 특정 단계를 넘어가지 않으며, 사용자와 디자이너, 다른 팀원들을 과정에 참여시키면 더욱 강력해집니다.

[14:56] 파트타임 작업을 통해 몇 달, 몇 년의 작업을 절약하고 나쁜 제품 출시를 방지할 수 있다는 점을 설명합니다.

[15:06] AI 코딩 도구의 진정한 가치는 스펙 작성에 몇 년을 쓰는 대신 빠르게 프로토타입을 만들어 올바른 방향을 찾는 것이라고 강조합니다.

[15:28] 코드로 병목 현상을 해결할 수 있지만, 파이프라인 끝단이 아닌 초기 단계의 제품 문제 해결이 중요하다고 설명합니다.

[15:59] AI 빌딩 도구를 활용해 실제 필요를 빠르게 파악하는 것이 강력한 접근법이라고 주장합니다.

[16:14] Pedro의 기사를 인용하며 언어모델이 업무량을 제거하는 게 아니라 이동시킬 뿐이며, 리뷰와 유지보수 담당자에게 부담을 준다고 설명합니다.

[16:37] AI 이전에도 프로토타입 단계에서는 불완전한 코드, 복사한 코드를 사용했으며, 목표는 코드 품질이 아닌 구축 가치 검증이었다고 개인 경험을 공유합니다.

[17:08] 임의의 패키지를 설치했다가 혼났던 경험을 예로 들며, 실제 사용 의도가 아닌 기능 검증이 목적이었다고 설명합니다.

[17:16] AI 코딩 도구를 사용할 때 프로토타입은 실제 제품이 아닌 이해를 구축하기 위한 도구라고 설명합니다. 패키지 추가나 코드 리뷰에 대한 부담보다는 기능의 가치를 확인하는 것이 목적이라고 강조합니다.

[17:26] 개발 과정에서 예상치 못한 엣지 케이스와 부작용들이 자주 발생한다고 설명하며, 팀원들의 도움으로 문제를 해결했던 경험을 공유합니다. 프로토타입 작업에 깊이 빠져 번아웃이 올 때 다른 사람의 새로운 시각이 큰 도움이 되었다고 합니다.

[18:04] 이런 방식으로 개발하는 이유는 코드를 실제 프로덕션에 배포하기 위함이 아니라, 무엇을 만들고 있는지에 대한 이해를 구축하기 위함이라고 명확히 합니다. 전통적인 개발 파이프라인의 빌드 단계나 지라 티켓 처리를 대체하는 것이 아니라고 설명합니다.

[18:26] AI 에이전트가 지라 티켓을 받아서 모든 것을 구현해주는 아이디어가 말이 안 되는 이유를 설명합니다. 코드 리뷰가 코드 작성보다 부담스럽고, 잘못된 스펙으로는 올바른 것을 구축하기 어렵다고 지적합니다.

[18:41] 개발 프로세스의 각 단계에서 실패 케이스가 발생할 수 있다고 설명합니다. 연구가 잘못된 결론에 도달하면 모든 하위 단계가 영향을 받는다고 하며, PM이 사용자 보이스의 무작위 요청을 바탕으로 잘못된 제안을 할 때의 문제점을 구체적으로 설명합니다.

[19:11] 디자인과 연구가 좋았어도 스펙 작성 단계에서 문제가 발생할 수 있다고 설명합니다. 사람들이 이해할 수 없는 방식으로 스펙을 작성하지만 당사자들은 그것을 모르고, 프레젠테이션을 듣고 완전히 이해했다고 생각해서 기술 스펙에 잘못된 가정들을 그대로 반영하게 된다고 합니다.

[19:28] PM과 개발자 간의 소통 문제와 잘못된 가정이 기술 명세에 어떻게 반영되는지, 그리고 이로 인한 회의에서의 문제점들에 대해 설명합니다.

[19:43] 빌드 과정에서 발생할 수 있는 문제들과 리뷰 프로세스의 어려움, 그리고 최종적으로 제품이 실패했을 때의 결과에 대해 논의합니다.

[20:15] 제품 실패 후 팀 해고 대신 재조직을 통해 문제를 해결하려는 회사들의 잘못된 접근법과 그로 인한 개발자들의 어려움을 설명합니다.

[20:33] 단순히 빌드 단계를 빠르게 만드는 것이 전체 개발 프로세스에 도움이 되지 않는 이유와 AI의 진정한 가치에 대해 논의합니다.

[20:52] AI가 빌드 과정을 초기 단계로 옮겨 올바른 개발 방향을 확인할 수 있게 해주는 장점을 설명하지만, 회사들이 기존 프로세스에 고집하는 것에 대한 우려를 표현합니다.

[21:08] GitHub Spark와 Kira 같은 AI 코딩 도구들이 상세한 PRD 작성에 집중하는 문제점과, 바이브 코딩의 본질적 장점이 훼손되는 상황에 대해 비판합니다.

[21:45] AI나 다른 개발자가 코드를 작성하게 하면 나중에 그 코드가 버려져도 기분 나쁘지 않다고 설명합니다. 평범한 개발자는 자신이 작성한 코드가 폐기되면 기분이 나쁘지만, AI가 작성한 경우나 코드가 버려지는 것을 좋아하는 개발자의 경우는 다릅니다.

[22:04] 하지만 이런 AI 코딩 접근법은 기존의 장점들을 제공하지 못하고 오히려 더 많은 단점만 가져온다고 비판합니다. 특히 제품 스펙의 경우 작성하는 것보다 읽는 것이 훨씬 더 어렵고 지루하다고 강조합니다.

[22:22] 긴 스펙 문서를 읽는 것이 얼마나 지루하고 힘든 일인지 설명하며, 이것이 코드 리뷰나 직접 코딩보다 훨씬 나쁘다고 말합니다. 차라리 프로토타입을 만들고 테스트하는 것을 선호한다고 합니다.

[22:50] 자신이 좋아하는 업무들을 나열합니다: 코드 작성, 대화, 새로운 아이디어 실험, 작동하지 않는 것들의 deprecation, 단순화 등입니다.

[23:12] 반대로 싫어하는 업무들을 나열합니다: 코드 리뷰, 긴 스펙 읽기, PM 설득, 10명 이상 참석하는 지루한 회의 등입니다. 코드 리뷰는 중요하지만 현재 팀에게 많은 리뷰 빚이 있어서 부담스럽다고 인정합니다.

[23:46] 만약 도구가 사람들로 하여금 싫어하는 일에 더 많은 시간을 쓰게 하고, 좋아하는 일에 더 적은 시간을 쓰게 한다면 그런 도구는 나쁘다고 주장합니다.

[23:53] AWS의 AI 코딩 IDE인 Hero를 예로 들어 비판합니다. 이 도구는 코딩을 덜 하게 하고, 대화를 덜 하게 하며, 에디터에서 기다리는 시간만 늘립니다. 새로운 아이디어 실험도 제한하고, 단순화나 개선에 대한 인센티브도 제거한다고 설명합니다.

[24:20] AI 도구들이 개발자들이 실제로 즐기는 창의적인 부분들을 제거하고, 대신 코드 검토와 스펙 읽기 같은 지루한 작업들로 대체하고 있다는 문제점을 지적합니다.

[24:35] PM들이 AI 도구로 직접 개발할 수 있다고 착각하게 되어, 개발자의 전문적 조언을 무시하고 무리한 프로젝트를 추진하려는 경향이 생겼습니다.

[24:46] 코딩 시간이 줄어든 대신 의미 없는 회의 시간이 늘어났고, 이는 생산성 향상이 아닌 단순한 노력의 이동일 뿐이라고 비판합니다.

[25:17] AI 도구의 혜택을 제대로 받으려면 기존 개발 프로세스를 근본적으로 재검토해야 하며, 현재의 접근 방식은 재미있는 부분을 죽이고 불필요한 텍스트 생성만 쉽게 만든다고 주장합니다.

[25:34] 타자기, 워드프로세서, AI 생성 도구의 도입에 따라 법률 문서의 길이가 급격히 증가한 역사적 사례를 통해, 도구가 쉬워질수록 결과물의 양은 늘어나지만 질은 반드시 개선되지 않는다는 점을 설명합니다.

[26:26] 더 많은 단어가 더 좋은 법률을 만들지 않듯이, 더 많은 코드가 더 나은 앱을 만드는 것은 아니라는 핵심 메시지를 전달합니다.

[26:42] AI 도구들이 잘못된 부분을 더 쉽게 만들었다고 지적합니다. 많은 코드를 작성하는 것은 쉬워졌지만, 좋은 코드를 작성하는 것은 더 어려워졌으며, 이는 법률 작성과 유사한 문제라고 설명합니다.

[27:00] AI가 생성한 코드를 단순히 리뷰만 하는 상황이 된다면 문제가 될 것이라고 경고합니다. 패턴이나 관행을 따르지 않는 거대한 코드 더미를 검토해야 하는 상황의 위험성을 강조합니다.

[27:15] AI 도구로부터 혜택을 얻으려면 프로세스를 재검토해야 한다고 주장합니다. 코드 생산은 쉬워졌지만 검증은 더 복잡해졌으며, 이는 팀의 전체적인 속도를 오히려 느리게 만들 수 있다고 설명합니다.

[27:33] 개발자들의 복사-붙여넣기 습관을 언급하며, LLM이 이런 습관을 더욱 증폭시켰다고 분석합니다. 이는 결국 구글 검색과 스택오버플로우 복사-붙여넣기의 고도화된 버전이라고 비유합니다.

[27:50] 코드를 이해하는 것이 여전히 가장 어려운 부분이며, LLM이 코드 생산 시간은 줄였지만 추론, 버그 식별, 유지보수성 보장에 필요한 노력은 변하지 않았다고 강조합니다.

[28:16] 코드를 두 가지 유형으로 분류합니다: 일회용 코드(벤치마크 스크립트, 프로토타입)와 프로덕션 코드(핵심 인프라, 라이브러리, 메인 기능). 최근까지 이 두 유형 간의 비용 차이가 크지 않았다고 설명합니다.

[29:17] 화자는 코드를 두 가지 유형으로 구분하는 것이 중요하다고 설명합니다. 많은 개발자들이 작은 사이드 프로젝트까지도 Rust로 작성해야 한다고 주장했던 시기를 언급하며, 이는 두 코드 유형의 차이를 인식하지 못했기 때문이라고 분석합니다.

[29:28] 자신이 특별했던 이유는 두 코드 유형을 잘 구별할 수 있었기 때문이라고 말합니다. 언제 일회용 코드를 빠르게 작성할지, 그리고 그 중 어떤 부분을 프로덕션으로 옮겨야 할지를 판단하는 능력이 핵심이었다고 설명합니다.

[29:42] 실제 업무에서 두 측면을 빠르게 전환하며 작업했던 경험을 공유합니다. 일회용 코드로 데모를 만들고, 사용자와 반복 작업을 통해 필요한 기능을 파악한 후, 프로덕션 버전을 구축하는 방식으로 진행했다고 설명합니다.

[30:05] 코드를 GitHub 승인과 사용자 배포용으로만 사용하지 않았다고 강조합니다. 무엇을 구축할지 파악하고, 기술 구현을 테스트하며, 이메일 처리나 리포트 분석 등 다양한 용도로 활용했다고 설명합니다. 이때 코드 자체는 중요하지 않았고 리뷰도 필요 없었다고 덧붙입니다.

[30:36] 대부분의 엔지니어들은 이런 구별을 할 수 없거나 하려 하지 않는다고 지적합니다. FAANG 회사 직원들의 사이드 프로젝트 사례를 들며, 개인 할 일 목록을 위해 Facebook이나 Netflix 수준의 복잡한 스택을 구축하는 문제점을 언급합니다.

[31:05] 사람들이 두 코드 유형을 구별하지 못하는 것이 현실적인 문제라고 진단합니다. 이로 인해 AI 도구들이 많은 사람들을 혼란스럽게 할 것이라고 예측하며, Lovable 같은 도구를 예로 들어 설명합니다.

[31:18] Lovable이 일회용 코드 영역에 속한다고 분류하면서, 대부분의 에이전트 코드 도구들도 마찬가지라고 설명합니다. 두 코드 유형을 구별하지 못하면 이런 도구들을 형편없고 쓸모없다고 판단하게 되지만, 실제로는 프로덕션 코드를 더 간단하고 좋게 만드는 방법으로 활용할 수 있다고 주장합니다.

[31:43] AI 코딩 도구를 사용할 때 프로토타입용 코드와 프로덕션 코드의 목적이 다름을 강조합니다. 프로토타입 코드는 빠르게 문제를 파악하기 위한 것이고, 프로덕션 코드는 유지보수와 협업을 위한 것입니다.

[32:10] 팀워크에서 신뢰와 공유된 맥락이 여전히 중요하지만, AI가 코드를 너무 빨리 생성하면 품질 검증이 제대로 이루어지지 않아 문제가 될 수 있다고 경고합니다.

[32:31] 멘토링 과정에서 AI 도구를 잘못 사용하면 오히려 팀원들의 성장을 방해하고 코드 품질 문제를 야기할 수 있음을 구체적인 예시로 설명합니다.

[32:57] 버릴 코드와 프로덕션 코드를 구별하지 않으면 문제가 발생하며, LM이 강력하지만 기본적인 개발 원칙을 대체할 수는 없다고 정리합니다.

[33:11] AI 도구의 진정한 가치는 개발자들이 예전에는 불가능했던 빠른 프로토타이핑을 가능하게 한다는 점입니다. 몇 개월 걸릴 일을 며칠에 해결할 수 있는 능력을 제공합니다.

[33:35] 딥테크가 아닌 일반적인 CRUD 애플리케이션의 경우 며칠 안에 사용 가능한 버전을 만들 수 있다고 주장하며, 프로덕션 개발 과정을 개선할 수 없다면 다른 사람에게 기회를 양보하라고 조언합니다.

[34:01] 6개월이 걸리는 건 프로토타입이 아니라고 강조하며, 진짜 프로토타입은 2-3주 정도로 만들어서 버려도 아깝지 않아야 한다고 설명합니다.

[34:20] LLM이 명확한 사고나 신중한 설계를 대체하지 못한다고 언급하며, AI 도구의 한계를 인정해야 한다고 주장합니다.

[34:34] 프로덕션 코드에만 집중하는 주요 엔지니어와 새로운 아이디어를 테스트하고 싶어하는 CEO/PM 간의 갈등 상황을 가상의 슬랙 대화로 재현합니다.

[35:41] 이런 갈등이 실제로 매우 현실적이라고 설명하며, 러버블뿐만 아니라 다른 기술들에 대해서도 비슷한 반응이 나온다고 언급합니다.

[36:23] 주요 엔지니어가 자신의 관점에만 갇혀 있어서 PM의 진짜 니즈를 이해하지 못한다고 지적하며, 엔지니어는 기술 사양에만 관심이 있고 제품의 유용성은 이미 가정하고 있다고 분석합니다.

[36:48] 엔지니어들은 AI 도구의 가능성을 무시하지만, PM들은 다른 사람들이 이런 도구로 유용한 것들을 만드는 것을 보고 자신들의 문제도 해결할 수 있다고 깨닫게 됩니다. 이로 인해 서로 다른 관점을 가진 PM과 수석 엔지니어 사이에 적대적 관계가 형성될 수 있습니다.

[37:25] Twitch에서의 경험을 통해 디자이너가 HTML과 JavaScript를 배워 Mod View 프로토타입을 만든 사례를 소개합니다. 실제로 작동하지 않지만 모더레이터들에게 보여줄 수 있는 데모를 만들어 피드백을 받을 수 있었습니다.

[38:04] 우수한 디자이너들이 AI 코딩 도구를 활용하면 더 반복적인 과정을 통해 올바른 해결책을 찾을 수 있습니다. 핵심은 다음 깨달음까지의 시간을 단축하고 통찰력을 최적화하는 것입니다.

[38:24] 가정에서 새로운 학습으로 가는 최단 경로를 찾는 것이 중요합니다. 사용자의 니즈나 기능의 작동 방식에 대한 가정을 빠르게 검증할 수 있는 방법을 모색해야 합니다.

[38:45] AI 도구를 통해 더 많은 통찰과 '아하' 순간을 얻을 수 있다면 유용하지만, 단순히 과정을 빠르게 진행하는 데만 사용한다면 의미가 없습니다. 현재 많은 도구들이 '개발자 대체'로 홍보되고 있지만, 실제로는 사용자 니즈를 더 빠르게 파악하고 효과적으로 반복할 수 있게 해주는 도구로 접근해야 합니다.

[39:11] AI 코딩 도구를 활용한 개발의 핵심은 더 빠른 반복과 피드백이다. 코드 작성 비용은 줄었지만, 팀이 함께 이해하는 비용은 여전히 병목지점이다.

[39:35] 거대한 스펙 문서의 문제점을 설명한다. 제품 리드, 디자인 리드, 기술 리드가 만든 방대한 스펙 중 실제로 좋고 올바른 부분은 극히 일부이고, 나머지는 버려야 할 내용이라고 지적한다.

[40:17] 스펙 대신 프로토타입 접근법을 제안한다. 작은 프로토타입은 비록 실패율이 높을 수 있지만, 빠른 시간 안에 아이디어의 타당성을 검증할 수 있고, 소통도 훨씬 쉬워진다.

[40:55] 프로토타입을 통한 반복적 개발 과정을 설명한다. 첫 번째 프로토타입의 좋은 부분을 확장하여 두 번째를 만들고, 실패를 통해 배운 교훈을 다음 버전에 적용하는 과정이다.

[41:21] 반복적 프로토타이핑을 통해 최종 제품이 원래 스펙보다 훨씬 작고 효율적이 되며, 이러한 접근법이 개발 업무를 더 재미있게 만든다고 강조한다.

[41:40] Jira 티켓 작업은 재미없다고 주장하며, 새로운 시도와 팀 협업을 통한 실제 문제 해결이 훨씬 즐겁다고 강조합니다.

[41:55] AI 도구들이 개발 과정의 각 단계를 훨씬 저렴하게 만들었다며, 20명이 9개월 걸릴 작업을 1명이 3일 만에 할 수 있다면 기존 방식은 비효율적이라고 비판합니다.

[42:15] AI 도구 덕분에 더 많은 팀이 빠른 프로토타입을 만들 수 있게 되었고, 이를 통해 진짜 문제를 찾은 후 전문가들에게 넘겨 제대로 개발할 수 있다고 설명합니다.

[42:36] 적은 수의 사람들이 참여하면 소통이 더 원활해지고 이해도가 높아진다며, 3명이 이해하는 것이 20-30명이 이해하는 것보다 효율적이라고 주장합니다.

[00:00] 많은 사람들이 몇 년 전보다

[00:01] 훨씬 더 많은 코드를 작성하고 있다고

[00:02] 말하는 것은 공정하다고 생각합니다. 그리고

[00:04] 말 그대로 모든 것을 직접 타이핑한다는

[00:06] 뜻은 아닙니다. 저는 이 모든

[00:07] 멋진 바이브 코딩 도구들, 여러분이

[00:09] 많은 코드를 생성하고 작성하는 데

[00:11] 도움을 주는 AI 에이전트들에 대해 말하고 있습니다.

[00:13] 그렇다고 해서 더 많은 배포가

[00:15] 일어나고 있다고 느끼지는 않습니다.

[00:17] 사람들이 사이드 프로젝트로 만든 것들의

[00:18] 멋진 데모를 트위터에 더 많이 올리고 있나요?

[00:21] 그럴지도 모르겠습니다. 하지만 저는

[00:22] 실제 제품에서 더 많은 기능이

[00:23] 나오는 것을 보지 못하고 있습니다. 제가 매일

[00:24] 사용하는 것들에서 더 많은

[00:26] 혁신이 일어나는 것을 보지 못합니다.

[00:28] 오히려 그곳에서는 덜 일어나고 있는 것 같습니다.

[00:30] 그럼 무슨 일이 일어나고 있는 걸까요?

[00:31] 갑자기 코드가 완성되기를 기다릴 필요가 없다면

[00:33] 훨씬 더 많은 기능들이 나와야 하지 않을까요?

[00:35] 그럴 것이라고 생각하겠지만, 가혹한 현실은

[00:38] 코드가 결코 병목이 아니었다는 것입니다.

[00:39] 저는 한동안 이것에 대해 생각해왔습니다.

[00:41] 왜냐하면 저는 역사적으로 프로젝트가

[00:43] 뒤처질 때 마무리 라인까지

[00:45] 밀어붙이는 사람이었거든요. 그리고 저는

[00:47] 정말 멋진 글을 봤는데 그것이 저로 하여금

[00:49] 정말로 앉아서 여러분들과 함께 이 개념을

[00:51] 분해해보고 싶게 만들었습니다. 왜냐하면

[00:54] 코딩은, 우리가 시간을 보내고 싶어하고

[00:55] 작업하고 싶어하는 것이지만

[00:58] 실제로 우리가 배포하고자 하는 것을

[00:59] 늦추는 것은 아니기 때문입니다.

[01:01] 기능을 출시하고 애플리케이션을 구축하는 데는

[01:03] AI로 생성할 수 없는 너무나 많은

[01:06] 부분들이 있습니다. 하루 중 몇 시간 동안

[01:08] 실제로 앉아서

[01:10] 코드를 작성하며 에디터에서 일어나는

[01:11] 일들이 아닌 것들 말입니다.

[01:14] 그리고 이런 것들은 AI 때문에 약간

[01:16] 나아질 수는 있지만, 실제로는 그렇지 않습니다.

[01:18] 확실히 여러분이 바라거나

[01:20] 인터넷에서 끊임없이 듣는 것들로부터

[01:22] 기대할 수 있는 수준은 아닙니다.

[01:23] 그것이 우리 모두가 PM이 될 것이라는 뜻일까요?

[01:26] 그렇지는 않습니다. 저는 이에 대해 깊이 들어가서

[01:28] 몇 년 후 엔지니어가 될 것에 대한

[01:30] 제 생각을 공유하려고 합니다.

[01:32] 이 미친 세상에는 너무 많은 일들이 일어나고 있습니다.

[01:34] 그리고 이 글이 정말 좋은

[01:35] 출발점인 것 같습니다.

[01:37] 들어가는 것이 흥미롭습니다만

[01:38] 만약 제가 엔지니어로서 일자리를 잃게 된다면

[01:40] 누군가는 제 청구서를 지불해야 합니다.

[01:41] 그래서 오늘의 스폰서로부터 간단히 한마디하고

[01:42] 바로 들어가겠습니다.

[01:44] AI가 코드 작성에 정말 뛰어나다는 것은 분명하지만

[01:46] 큰 코드베이스에서 작업한다면 그것이

[01:47] 많은 양의 컨텍스트를 잘 처리하지 못한다는 것도

[01:49] 분명합니다. 코드베이스에서 올바른 파일을

[01:50] 찾으려고 시도하겠지만

[01:52] 그 다음에 무엇을 할까요? 종종

[01:54] 잘못된 일을 합니다. 오늘의 스폰서인

[01:56] Augment Code를 사용하지 않는다면 말이죠.

[01:58] 캐치라인은 진부하지만, 정말로 말하는 그대로입니다.

[02:00] 더 나은 컨텍스트이고 그 결과는

[02:02] 훨씬 더 나은 코드입니다.

[02:04] 여러분을 위해 코드를 작성할 수 있지만

[02:05] 솔직히, 저는 주로 코드베이스에서 것들을 찾는 데

[02:07] 사용합니다. 왜냐하면 거대한 프로젝트들을

[02:09] 정말 잘 탐색할 수 있기 때문입니다.

[02:11] 특히 오픈 소스 프로젝트들을 말이죠.

[02:12] 그것이 제가 가장 좋아하는 남용 방법입니다.

[02:14] 저는 종종 React가 어떻게 작동하는지에 대한 질문이 있습니다. 그래서 여기에 전체 React 코드베이스가 있습니다. 59만 3천 줄의 코드

[02:18] 코드베이스입니다. 그런데 완전히

[02:19] 인덱싱되었어요. 몇 초만에

[02:21] 완료됐습니다. 이제 뭐든 물어보면

[02:22] 몇 초 안에 답을 받을 수 있어요. 이들은

[02:24] 실제로 용기 있게 UI에 타이머를

[02:26] 눈에 띄게 배치한 유일한 AI 에이전트예요.

[02:28] 너무 빨라서 가능한 거죠. 여전히

[02:30] 어떻게 이렇게 말도 안 되게

[02:31] 빠른지 모르겠어요. 그리고 보세요,

[02:33] 알아냈네요. 핵심 구현체와

[02:34] 별도의 서버 사이드 구현체를

[02:36] 찾아서 React 서버

[02:37] 컴포넌트에서 제대로 작동하도록

[02:39] 했어요. 이들이 별도의 가짜

[02:40] 스텁 처리된 uState를 가지고 있는지도

[02:42] 몰랐어요. 광고를 녹화하면서

[02:44] 새로운 걸 배우고 있어요. 그게 바로

[02:46] Augment의 실력입니다. 제 말을 믿지 못하겠다면

[02:47] 사이트에 있는 후기들을

[02:49] 살펴보세요. 정말 놀라워요.

[02:51] 이렇게 많은 사람들이 사랑한다는

[02:52] 후기가 있어요. 그리고 제가 소개하는

[02:53] 스폰서 중에서도 가장 긍정적인

[02:55] 반응을 받고 있어요. 여기서 정말 멋진

[02:57] 것들을 소개하거든요. 지금 사용해보고

[02:58] 싶다면 무료로 시작할 수 있고,

[02:59] AI 도입을 고려하는 대기업이라면

[03:01] 선택해야 할 회사입니다. 지금 확인해보세요.

[03:03] link/augment에서요. 코드 작성이

[03:05] 병목이 된 적은 없었습니다. 수년간

[03:07] 코드 라인을 작성하는 것이

[03:08] 소프트웨어 엔지니어링의 병목이

[03:10] 아니라고 느껴왔어요. 실제 병목은

[03:12] 지금도 여전히 코드 리뷰,

[03:14] 멘토링과 페어링을 통한 지식 전수,

[03:16] 테스팅, 디버깅, 그리고

[03:17] 조정과 소통의 인적 오버헤드입니다.

[03:19] 산 정상에서 외쳐주세요. 정말 현실적이에요.

[03:21] 이 모든 것들이 티켓, 계획 회의,

[03:23] 애자일 의식들의 미로 속에 감싸여

[03:26] 있어요. 품질을 높이려고 만든 이런 프로세스들이

[03:28] 실제로는 코드 작성 자체보다

[03:30] 더 우리를 느리게 만들어요.

[03:32] 사고와 공통된 이해,

[03:34] 그리고 건전한 판단력이 필요하거든요. 이제 LLM으로

[03:36] 작동하는 코드를 그 어느 때보다

[03:38] 빠르게 생성할 수 있게 되면서

[03:40] 새로운 이야기가 나왔어요. 코드 작성이

[03:42] 병목이었고, 우리가 드디어 해결했다고요.

[03:44] 하지만 완전히 맞지는 않아요. 새로운

[03:47] 소프트웨어를 추가하는 한계 비용은

[03:49] 특히 LLM과 함께라면 거의 제로에

[03:51] 가까워지고 있어요. 하지만 코드를

[03:53] 이해하고, 테스트하고, 신뢰하는 비용은

[03:56] 그 어느 때보다 높아요. 벌써

[03:58] 정말 많은 생각이 드네요. 그리고

[04:00] 약간의 스토리 타임도 있어요. 과거에

[04:02] 몇 번 이야기한 적 있는데, 제가 여러

[04:04] 회사에서 맡았던 역할에 대해서요. Twitch에

[04:05] 있을 때 대부분은 마감을 맞춰야 할 때

[04:07] 호출받는 사람이었어요. 이런 일을 위한

[04:10] 역할이 많았는데, 그 중 하나는

[04:11] 매니저들에게 실제 마감보다

[04:13] 2주에서 2달 먼저인 가짜 마감을

[04:15] 달라고 하는 거였어요. 그래야 그 마감을

[04:17] 맞추고 나서 남은 시간으로

[04:19] 다듬는 작업을 할 수 있거든요.

[04:20] 그리고 받는 모든 마감이 진짜라고

[04:22] 스스로를 깊게 확신시키곤 했어요.

[04:24] 그리고 마감을 맞추고 나면 남은 시간을

[04:26] 써서 훨씬 멋지고 완성도 높게

[04:28] 만들어주곤 했죠. 그렇게 해서 최고의

[04:29] 릴리스들이 나왔어요. 제가 개인적으로

[04:31] 가장 좋아하는 것 중 하나인 Twitch의 ModView처럼요.

[04:33] 이런 식으로 좋은 상태로 나올 수 있었던 거죠.

[04:34] 재미있게도 채팅 기능이 그렇게 망가져 있는 것도

[04:36] 꽤 웃기네요. 나머지는 다 잘 작동하거든요.

[04:38] 정말 웃긴 일이에요. 왜냐하면 나머지는 모두 훌륭하게 작동하거든요.

[04:40] 우리가 만든 것에 대해 정말 자랑스러워요.

[04:42] 이런 다양한 위젯들을 만들어서

[04:44] 모든 세부사항을 보여주는데 완전히

[04:45] 커스터마이즈 가능하고 이동도 가능해요.

[04:47] 언제든지 UI에 넣었다 뺐다 할 수 있거든요.

[04:49] 이 모든 걸 런칭 첫날부터 준비하는 게

[04:51] 정말 재미있었어요. 왜냐하면 PM에게

[04:54] 데드라인을 한 달 일찍 잡아달라고 했거든요.

[04:56] 그래서 실제 출시 전 달 말에

[04:58] 이걸 완성하고 작동하게 만들어놨죠.

[05:00] 그리고 나서 한 달 내내

[05:01] 버그 수정하고, 성능 이슈 찾고,

[05:03] 완벽하게 다듬는 작업을 했어요.

[05:04] 이게 제가 한 일의 많은 부분이었죠.

[05:06] 제가 이 모든 얘기를 꺼내는 이유는

[05:08] 이게 생각하시는 만큼 저에게 도움이 되지 않았기 때문이에요.

[05:11] 이 말이 제가 얼마나 훌륭한 엔지니어인지

[05:13] 자랑하는 것처럼 들릴 수 있지만

[05:15] 그런 게 아니에요. 이건 그냥 제가 가진

[05:17] 이상한 고유 스킬이었어요.

[05:19] 빠른 출시를 위해 어떤 부분을 잘라낼지

[05:21] 찾아내는 이상한 능력이 있었거든요.

[05:24] 품질을 크게 타협하지 않으면서도

[05:25] 빠른 출시가 가능했어요. 보통은

[05:26] 적절한 모서리를 다듬는 방식으로요.

[05:28] 지금도 여전히 이런 식으로 일해요. 팀이

[05:30] T3 채팅 관련 계획을 보여줄 때

[05:33] 우리가 제거할 수 있는 부분을 찾으려 해요

[05:35] 작업하는 문제 영역을 단순화해서

[05:38] 더 나은 성공 경로를 얻기 위해서요.

[05:39] 잘 작동하는 것들을 보면서

[05:41] 어떻게 하면 간단하고 유익한

[05:43] 버전을 만들어 더 나은 출시를

[05:44] 할 수 있을지 생각해보기도 해요.

[05:47] GraphQL의 풀스택 타입 안정성 같은 것들은

[05:48] 제가 작업했던 팀들과 트위치에서의 개발 방식에

[05:50] 엄청난 도움이 되었어요.

[05:52] GraphQL 쪽은 실제로

[05:54] 개발자와 사용자 모두에게 잘 작동하도록 만들기 위해

[05:56] 여러 사람으로 구성된 팀이 필요했기 때문에

[05:57] 반대편의 이익을 얻기 전에

[05:59] 많은 직원이 있어야 했죠.

[06:01] 다루기 가치가 있을 정도로요.

[06:02] 어떻게 하면 이런 이익과

[06:04] 그에 따라 오는 안전성과 민첩성을

[06:05] GraphQL의 엄청난 투자 없이도

[06:07] 얻을 수 있을지 알아내고 싶었어요.

[06:09] 그래서 T3 스택이 탄생했죠.

[06:11] 이 부분들을 제대로 연결하는

[06:12] 방법을 찾아서 더 빨리 출시할 수 있게 되었어요.

[06:14] 우리가 만든 앱들이 그렇게 좋았던

[06:16] 큰 이유 중 하나죠. 제가 첫 시도에

[06:18] 완벽하게 만들었기 때문이 아니에요.

[06:19] 사실 정반대예요.

[06:21] 틀릴 수는 있지만 빠르게 만들고

[06:23] 사용자들의 피드백을 통한 반복 과정으로

[06:24] 빠르게 개선할 수 있었어요. 이런 방식으로 구축된

[06:27] 시스템에서는 확신을 가지고

[06:29] 변경사항을 만들기가 너무 쉬웠거든요.

[06:31] 이게 제가 생각하는 방식이에요. 이건 저에게

[06:33] 오랫동안 엄청난 이점을 줬어요.

[06:36] 컨설팅 일도 받게 되었고, 회사들의

[06:37] 빌드 파이프라인을 정리하고

[06:39] 실제 아키텍처를 어떻게 구성할지

[06:41] 다시 생각해보도록 도와줬어요. 하지만

[06:43] 이제는 이런 이점들이 훨씬 덜 실제적으로 느껴져요.

[06:45] AI 에이전트를 사용해서 제가 예전에

[06:47] 하던 일의 많은 부분을 할 수 있거든요.

[06:49] 저는 들어와서 일이 어떻게 돌아가는지 파악하고

[06:51] 최선을 다해 단순화시키는 사람이었는데

[06:52] 빠른 배포를 다시 가능하게 만들 수 있습니다. AI 에이전트가

[06:54] 빠른 배포를 대신 처리해주고

[06:56] 많은 단계들을 건너뛸 수 있죠. 하지만

[06:57] 제가 정말 유용하다고 발견한

[06:59] 또 다른 측면이 있었습니다. 트위치에서의

[07:01] 디자인 프로세스를 살펴보면

[07:03] 이런 모습이었습니다. 1단계는 제품

[07:05] 매니저가 문제를 식별하는 것입니다. 이는

[07:07] 사용자 피드백을 검토하거나, 이벤트에 가서

[07:08] 사람들과 대화하거나,

[07:11] 트위치에 대해 깊이 생각하고

[07:12] 부족한 부분을 찾아

[07:14] 공백을 채우려고 시도하는 방식으로 이뤄집니다.

[07:16] 제품 매니저들이 해결해야 할 문제를

[07:18] 찾으려고 노력하는 것은 매우 일반적이었습니다.

[07:20] 그것이 바로 그들의 업무였거든요. 2단계는

[07:23] 그 문제에 대해 사용자들과 많은 대화를 나누는 것입니다.

[07:26] 공정하게 말하자면, 많은 PM들이

[07:28] 이 단계를 건너뛰곤 했지만, 건너뛰지 않았을 때는

[07:29] 정말 좋았습니다. 그래야

[07:31] 문제가 실제로 무엇인지, 무엇을

[07:33] 해결해야 하는지에 대한 더 많은 정보를 얻을 수 있었거든요.

[07:35] 3단계는 디자인팀과 협력하여 해결책이

[07:39] 어떤 모습일지 파악하는 것이었습니다. 문자 그대로의 의미와

[07:41] 정신적인 의미 모두에서 말이죠.

[07:44] 디자인과 PM 시간을 투자해서

[07:46] 어떤 모습이 될지 보여주는 데 집중했습니다.

[07:47] 때로는 목업이나 앱의 가짜 버전을 만들기도 했지만,

[07:49] 이것이 어떤 느낌이어야 하고

[07:51] 어떻게 작동해야 하는지 깊이 파악하려고 노력했습니다.

[07:53] 그다음 4단계는

[07:55] 제품 제안 명세서였습니다. 이것은

[07:59] 제품에 대한 그들의 비전이었습니다.

[08:01] 목업이 포함되어 있었고, 그들이

[08:03] 생각하는 내용을 문서화한 5페이지에서

[08:05] 30페이지 분량이었습니다. 그런 다음

[08:07] 해당 명세서에 대한 프레젠테이션을 진행했습니다.

[08:10] PM들에게는 별도의 프레젠테이션을 해서

[08:12] 승인을 받고, 그다음에는

[08:13] 일반 팀이나 그들이 속한 조직에

[08:15] 프레젠테이션을 해서

[08:16] 경영진 등의 승인을 받았습니다.

[08:18] 그리고 나서 개발자들이 인계받아 거의 같은 일을 반복했습니다.

[08:22] 개발자들은 명세서를 살펴보고

[08:24] 필요한 것이 무엇인지 파악한 다음, 제품팀과

[08:26] 사용자들과 논의한 내용에 대해

[08:27] 대화하고, 그다음 자신들만의

[08:29] 매우 긴 명세서를 작성했습니다.

[08:32] 하지만 여기에는 문제가 있었습니다.

[08:34] 이 프로세스는 너무 오래 걸렸어요.

[08:37] 1단계에서 8단계까지, 전체 스펙트럼을

[08:41] 처음부터 끝까지 진행하는 데 6개월에서 18개월이 걸렸습니다.

[08:44] 물론 더 긴급한

[08:45] 문제가 있으면 훨씬 빠르게 진행했습니다.

[08:47] 제가 보안팀에 있었을 때처럼

[08:49] 이런 단계들을 많이 건너뛰곤 했는데,

[08:51] 중요하지 않아서가 아니라

[08:52] 정말 중요했기 때문이었습니다.

[08:54] 보안 문제는 존재를 알게 되는 즉시

[08:56] 최대한 빨리 해결해야 했거든요.

[08:58] 하지만 다른 조직에서는 문제가 식별된 후부터

[09:01] 해결책을 위한 문서가 작업할 준비가 될 때까지

[09:04] 몇 개월, 심지어 몇 년이 걸리기도 했습니다.

[09:06] 하지만 앞서 언급했듯이 제가

[09:08] 이전에 있었던 보안팀에서는

[09:09] 이런 프로세스를 거의 하지 않았습니다.

[09:11] 드물게 했던 경우는

[09:13] 이미 작동하는 해결책이 있었지만

[09:14] 처음부터 다시 생각해보고 싶을 때였습니다.

[09:16] 다시 말해서, Mod View 같은 경우

[09:19] 트위치에서 스트림을 관리할 수 있는

[09:20] 해결책들이 있었지만, 그 해결책들은

[09:22] 스트리머들이 해야 하는

[09:23] 관리 유형에 비해 우리가 원하는 만큼 깊이 있지 않았습니다.

[09:25] 모더레이터들은 정말 열심히 일합니다.

[09:27] 지금 도움을 주고 있는 모든 모드분들께 감사드립니다.

[09:28] 이런 도구들은

[09:30] 재검토가 필요했고, 우리도 그걸 알고 있었습니다.

[09:32] 그래서 우리는 가서 다시 생각했습니다. 그런데도

[09:35] 결정을 내린 후 실제로 출시하기까지 7개월이 걸렸습니다.

[09:37] 시작하는 데만 18개월이 아니라 말이죠.

[09:39] 이게 정말 고통스러워진 부분은

[09:41] 제가 이런 프로젝트들을 마주했을 때였습니다.

[09:43] 프로덕트의 스펙 발표를 훨씬 지나쳐서

[09:45] 이 정도까지 만들어진 프로젝트들을요.

[09:47] 그런데 저한테는 아주 명백했습니다.

[09:49] 이 프로덕트는 엉망일 거라는 게 말이죠.

[09:51] 왜냐하면 저는 실제로 스트리머들과 대화하고

[09:52] 크리에이터 세계를 신경 썼거든요.

[09:54] 그런데 프로덕트가 여기까지 와서

[09:56] 쓰레기가 된다는 사실이

[09:59] 저에게는 무서웠습니다. 어떻게 이렇게 깊숙이 들어와서도

[10:01] 이 과정에서 깨닫지 못할 수 있을까요?

[10:04] 아무도 실제로 원하지 않는 것이라는 걸

[10:06] 심지어 사용자들에게는

[10:07] 퇴보가 될 수도 있다는 걸 말이죠. 더 나쁜 건

[10:10] 프로젝트가 여기까지 와서

[10:12] 엔지니어들이 배정되고

[10:15] 지라 티켓이 몇 달에서 몇 년 미리 만들어지고

[10:19] 그러고 나서 마감일이 설정되는데

[10:23] 그 마감일은 맞춰지지 않을 거고

[10:27] 그러면 그들이 저에게 물어봅니다.

[10:32] 그들은 여기까지 와서 그제서야

[10:34] 저에게 이걸 구해달라고 요청하는데

[10:36] 제가 들어가서 이건 나쁜 아이디어라고 말하면

[10:40] 한바탕 논쟁이 벌어지고

[10:41] 그러고도 그들은 그냥 가서 출시해버리죠.

[10:43] 그러면 프로덕트는 엉망이 되고

[10:44] 결국 되돌려야 합니다.

[10:46] 이런 일이 트위치에서 근무하는 동안 여러 번 일어났는데

[10:48] 특히 트위치 마지막 팀에서 마지막 시간에

[10:50] 더욱 그랬습니다.

[10:52] 아무도 깨닫지 못한 채 그렇게 오랜 시간이 갈 수 있다는 사실이

[10:54] 그들이 만들고 있는 프로덕트가

[10:56] 어떤 실제 사용자의 실제 문제도 해결하지 못한다는 걸

[10:58] 그리고 실수라는 걸, 아니면

[11:00] 더 나아가 중요한 사용자들에게

[11:02] 퇴보를 일으킬 수 있다는 걸 말이죠.

[11:03] 이건 아주 흔한 일이었는데, 새로운 기능이

[11:05] 사이트나 앱을 훨씬 더 나쁘게 만드는 것

[11:08] 그들이 본래 도우려고 했던

[11:09] 사용자들에게 말이죠. 정말 흔한 일이었어요.

[11:11] 그럼 제가 왜 이 모든 얘기를 하는 걸까요?

[11:13] 병목이 코드가 아니라는 걸

[11:14] 강조하기 위해서일까요? 아니요, 사실은

[11:16] 그 반대입니다. 제가 빠른 코딩을 사용해서

[11:19] 우리의 막힘을 해결한 방법 중 하나를 보여드리고 싶습니다.

[11:23] 운 좋게도 몇몇 PM들이 깨달았습니다.

[11:25] 제가 프로덕트를 많이 신경 쓴다는 걸 말이죠.

[11:27] 솔직히 말하면, 대부분의 엔지니어는 그렇지 않거든요.

[11:29] 그게 대부분 엔지니어가 일하는 방식이 아닙니다.

[11:31] 그들은 자신의 코드를 작성하고

[11:33] 주어진 티켓을 닫고 싶어 합니다.

[11:36] 그럼 제가 다르게 한 것을 소개하겠습니다.

[11:39] PM들과 디자이너들이,

[11:40] 저는 트위치 경력의 상당 부분에서

[11:42] 디자인과 아주 가깝게 일했고

[11:43] 그들은 이 단계에서 저를 끌어들이는 걸 좋아했습니다.

[11:44] 프로덕트 매니저가 문제를 식별합니다.

[11:47] PM이 디자이너와 테오를 불러서 그에 대해 논의합니다.

[11:50] 1.6 테오가 이것이 무엇을 의미하는지 대략적인 아이디어를 가지고

[11:56] 3일에서 2주 만에 그걸 구축합니다.

[12:00] 1.7 PM이 테오 버전을 실제 사용자들에게 보여줘서

[12:06] 피드백을 받습니다. 그리고 1.8

[12:09] 훨씬 더 나은 제안을 작성하거나

[12:12] 해당 피드백을 바탕으로 아이디어를 완전히 없애버립니다.

[12:15] 이제 이런 방식으로 해봤으니까

[12:20] 대신에, 얼마나 많은 단계를 없앨 수 있는지 보겠습니다.

[12:22] 우리가 제거할 수 있는 것들 말이죠.

[12:24] 제거할 수 있습니다. 그 단계는 없어졌죠. 이제

[12:26] 디자인 단계도 어느 정도 사라졌습니다

[12:27] 왜냐하면 점진적으로 반복하고 있거든요

[12:29] 계속 앞뒤로 반복하면서요. 좋은

[12:31] 피드백 루프가 모든 과정에 있습니다. 제품

[12:32] 제안서나 스펙도 더 이상 필요 없어요.

[12:34] 스펙은 보통 그냥 데모가 됩니다.

[12:36] 우리가 만든 것이 바로 스펙이에요. 아마도

[12:38] 한 페이지 분량의 문서를 만들어서

[12:40] 우리가 이것을 하는 이유를 설명하죠. 발표자료도

[12:42] 더 이상 필요 없습니다.

[12:43] 데모 앱의 영상을 보내면서 말하죠

[12:45] 우리가 만든 것을 보세요. 얼마나 유용한지

[12:46] 보시죠. 개발자가 인수받는다? 인수받을 개발자가 없어요

[12:49] 우리가 처음부터 끝까지 있었거든요.

[12:50] 이제 그들이 할 일이 아무것도 없습니다.

[12:52] 우리는 그냥 앱을 재구축하고

[12:53] 우리가 얻은 모든 학습 내용을 적용하거나

[12:55] 정말로 스펙을 작성하길 원한다면

[12:57] 솔직히 가끔 그런 일이 생기는데

[12:59] 갑자기 우리는 실제로

[13:01] 좋고 현실적인 스펙을 작성할 수 있게 됩니다

[13:04] 모든 문제점들을 알고 있거든요

[13:05] 이미 그 빌어먹을 걸 만들어봤으니까요.

[13:06] 냉혹한 현실은 제가 정말 좌절했다는 겁니다

[13:08] 우리가 이 전체 과정을 거쳐가면서

[13:10] 제가 며칠만에 명백히 틀렸다고 증명할 수 있는

[13:12] 것들에 대해 말이죠. 그래서 저는

[13:13] 아주 일찍부터 작업을 시작했고

[13:15] 우리가 과정을 부분적으로라도 진행할 때쯤이면

[13:18] 손을 들고 말할 수 있었습니다. '이봐요

[13:20] 이것의 작동하는 버전이 있어요

[13:21] 이 모든 과정을 거치기 전에

[13:22] 테스트해볼 수 있어요.' 그리고 만약 당신이

[13:24] '아니야, 우리는 과정을 먼저 거쳐야 해'

[13:26] 라고 말하는 사람이라면

[13:27] 당신은 빌어먹을 바보처럼 보입니다

[13:29] 왜냐하면 실제로 빌어먹을 바보거든요.

[13:30] 제가 이것을 보여드리는 이유는

[13:32] 빠르게 만들 수 있는 제 능력을 활용해서

[13:35] 수많은 과정을 건너뛰고

[13:37] 모든 것을 훨씬 더 합리적으로 만들고

[13:40] 무엇보다 중요하게는 시간 낭비를

[13:42] 크게 줄이는 방법을 찾았기 때문입니다.

[13:44] 우리가 여전히 이 모든 단계를 거친다 해도

[13:46] 그 단계들이 훨씬 더 효율적이고

[13:48] 우리가 만드는 것에 대해 훨씬 더 현실적입니다

[13:50] 참조 버전이 있거든요. 그리고

[13:51] 확실하지 않은 것이 있으면

[13:52] 참조 버전을 업데이트하고

[13:54] 사용자들이 어떻게 반응하는지 보고

[13:56] 그에 따라 우리의 과정과 계획을

[13:58] 업데이트할 수 있습니다. 기존 과정이

[14:00] 연구, 디자인, 스펙 작성, 개발, 출시, 기도하기

[14:04] 보통 이렇게 되죠. 아, 그 뒤에 또 다른 단계가 있어요

[14:08] 폐기하기. 형편없었거든요.

[14:09] 이것이 과정이 되는 대신

[14:11] 저는 매우 다른 것을 추진했습니다.

[14:13] 제 과정은 식별하기

[14:14] 프로토타입 만들기, 피드백 수집

[14:17] 좋아질 때까지 반복하기

[14:19] 스펙 작성, 하지만 실제로는 그냥 짧은 목록을 작성하거나

[14:23] 어떻게 만들지 적어두는 것이죠

[14:27] 맞나요? 베타 버전 만들기, 피드백 수집하기

[14:32] 훌륭해질 때까지 5번으로 돌아가기. 그리고 이것이

[14:36] 저에게는 큰 차이점입니다. 저는

[14:38] 피드백 루프를 구축하는 아이디어에 집중했어요

[14:41] 그냥 피드백 루프를 만들고

[14:42] 우리가 좋아하는 상태가 될 때까지는

[14:45] 특정 단계를 넘어가지 않는 것이죠. 이 루프는

[14:47] 특히 당신이 사용자와 디자이너

[14:49] 그리고 다른 사람들을 이 과정에 참여시키면

[14:51] 매우 강력합니다. 엔지니어 한 명

[14:53] 디자이너 한 명, PM 한 명이 모두

[14:56] 이런 파트타임 작업이 몇 달, 심지어 몇 년의 작업을 줄여줄 수 있고

[14:58] 잠재적으로 7명의 엔지니어로 나쁜 제품을

[15:00] 개발하고 출시하는 것을

[15:01] 이 부분을 먼저 하는 것만으로도 막을 수 있습니다.

[15:03] 그리고 이 모든 AI 코드와 바이브 코딩에서

[15:06] 제가 기대하는 것 중 하나는

[15:07] 사람들이 이런 방식으로 먼저 구축할 수 있다는

[15:08] 작은 희망의 빛입니다. 스펙에 몇 년을 쓰고

[15:12] 나서 며칠 만에 만드는 대신

[15:14] 올바른 것을 만드는 데 며칠을 쓸 수 있고

[15:16] 더 중요한 것은 잘못된 것을 만드는 데 며칠을 써서

[15:18] 올바른 것이 무엇인지 알아낼 수 있다는 것입니다.

[15:20] 더 중요한 건 잘못된 것을 며칠 만들어보면서

[15:22] 올바른 것이 무엇인지 파악하고

[15:23] 며칠 더 재사양화하면

[15:24] 이를 파악한 후에는

[15:26] 일이 훨씬 순조롭게 진행됩니다.

[15:28] 그래서 저는 코드를 사용해 병목이 되는

[15:30] 다른 문제들도 해결할 수 있다고 믿습니다.

[15:31] 다만 파이프라인 끝단이 병목이라고 생각하지는 않습니다.

[15:33] 이 과정에는 엄청나게 많은 병목이 있습니다.

[15:35] 각각의 단계마다 사람이 다양한 일을 해야 하고

[15:37] 언제 다음 단계로 넘어갈지 결정해야 합니다.

[15:39] 이는 엄청나게 많은 중단점이 있다는 뜻이고

[15:41] 여기 아래쪽 부분을 더 빠르게 만드는 것은

[15:43] 이것을 빠르게 하는 것은 큰 도움이 되지 않습니다.

[15:45] 제가 아무리 빨랐어도

[15:47] 여기 아래를 빠르게 한다고 해서

[15:49] 체인 훨씬 앞단에 존재하는

[15:51] 제품 문제들은 해결되지 않았기 때문입니다.

[15:53] 이런 AI 빌딩 도구들을 사용해

[15:55] 반복하고 프로토타입을 만들어서

[15:59] 실제로 필요한 것이 무엇인지를

[16:02] 상당히 빠르게 파악할 수 있다면

[16:05] 이는 정말 강력합니다.

[16:07] 다시 기사로 돌아가서 Pedro가

[16:09] 뭐라고 하는지 보겠습니다.

[16:10] 그가 제게 이런 얘기를 하도록

[16:12] 영감을 줬거든요. 언어모델은 업무량을 이동시키지 제거하지 않습니다.

[16:14] 네, 클로드 같은 도구들이 초기

[16:17] 구현을 빠르게 해줄 수 있습니다.

[16:18] 하지만 결과적으로는 시스템을 통해

[16:20] 더 많은 코드가 흘러가게 되고

[16:22] 리뷰하고 통합하고

[16:23] 유지보수해야 하는 사람들에게

[16:24] 더 많은 압박이 가해집니다.

[16:26] 특히 작성자가 자신이 제출한 것을

[16:28] 완전히 이해하고 있는지 불분명할 때

[16:30] 이는 더욱 명확해집니다. 생성된 코드는

[16:32] 낯선 패턴을 도입하거나 기존 관례를 깨뜨리고

[16:33] 엣지 케이스나 명확하지 않은

[16:35] 의도하지 않은 부작용을 일으킵니다.

[16:37] 또 다른 핫테이크인데, 이런 것들은

[16:39] AI가 나오기 전에도 제가 하던 일입니다.

[16:42] 프로토타입 단계에서 작업할 때

[16:45] 저는 이런 것들에 대해 괜찮았고

[16:48] 종종 이런 것들을 마주칠 거라고 예상했습니다.

[16:50] 제가 제출한 코드를 완전히 이해하지 못해도 괜찮았습니다.

[16:52] 절반은 문제를 해결하기 위해

[16:53] 다른 곳에서 복사한 것들이었습니다.

[16:55] 목표는 좋은 코드를 제출해서

[16:57] 프로덕션에 배포하는 게 아니었습니다.

[16:58] 이것이 구축할 가치가 있는지

[17:00] 알아내는 것이었습니다.

[17:01] 결코 코드 품질이 목표가 아니라 누군가 앞에 놓고

[17:04] 보여주는 것이 목표였습니다.

[17:05] 생성된 코드가 낯선 패턴을 도입하거나

[17:07] 기존 관례를 깨뜨린다고요? 오 맨,

[17:08] 제가 임의의 패키지를 설치해서

[17:09] 다른 사람한테 혼났던 횟수를 생각해보면

[17:11] "네, 저는 실제로 그 패키지를 쓸 계획이 없었어요.

[17:13] 저는 이 기능이

[17:15] 구축할 가치가 있는지 알아내려고 했을 뿐이에요."

[17:16] 기능이 구축할 가치가 있는지, 그리고 이

[17:18] 패키지가 그 작업을 더 쉽게 만들어주는지 확인하는 거예요.

[17:20] 코드 리뷰하는 걸 싫어한다고 해서 죄송하지만,

[17:21] 어차피 머지할 것도 아니거든요.

[17:23] 그냥 조용히 하세요. 그리고 물론

[17:24] 예상치 못한 엣지 케이스와 부작용들이

[17:26] 명확하지 않게 나타나죠. 특히 그런 상황을

[17:28] 얼마나 많이 겪었는지 말로 다 할 수가 없어요.

[17:29] 그리고 우리 팀에게 정말 큰 감사를 표하고 싶어요.

[17:31] 특히 제가 안전팀에 있을 때,

[17:33] 때로는 이런 스펙이나

[17:35] 기술 프로토타입 작업을 하면서 각 부분들이

[17:37] 어떻게 결합되는지에 정말 집중하느라

[17:38] 프로토타입 작업에 너무 깊이 빠져서

[17:41] 끔찍한 엣지 케이스에 부딪히고

[17:43] 해결하지 못해서 만들고 있던 것에

[17:45] 번아웃이 오기 시작하면,

[17:47] 다른 사람이 새로운 시각으로 와서

[17:48] 제 엉망인 코드를 다 살펴보고

[17:49] 각 부분들이 제대로 결합되지 않는

[17:51] 방식을 파악해서

[17:53] 한 시간 만에 고쳐버리곤 했어요.

[17:55] 네, 저도 이 모든 것을 경험했어요. AI 없이도

[17:58] 이런 방식으로 구축할 때 정말로

[18:00] 겪는 일이었어요.

[18:01] 하지만 이런 방식으로 구축하는 목적과

[18:04] 제가 괜찮다고 생각하는 이유는

[18:05] 이 코드를 머지해서 프로덕션에

[18:07] 배포할 거라고 기대해서가 아니에요.

[18:09] 우리가 실제로 무엇을 만들고 있는지에 대한

[18:11] 이해를 구축하려고 하기 때문이에요.

[18:13] 이것은 전통적인 파이프라인의

[18:15] 빌드 단계를 대체하기 위한 것이 아니에요.

[18:17] 지라 이후에 하는 작업이 아니에요.

[18:19] 이것이 바로 리니어나 지라 티켓을 받아서

[18:21] 모든 걸 구현해주는 아이디어를 중심으로

[18:23] 구축된 모든 AI 에이전트들이

[18:25] 전혀 말이 안 되는 이유예요.

[18:26] 코드 리뷰가 코드를 작성하는 것보다

[18:28] 절반 정도는 더 부담스럽거든요.

[18:30] 일단 스펙이 나오면

[18:31] 그것을 구축하는 건 쉬워요. 하지만

[18:33] 잘못된 스펙을 작성했다면 올바른 것을

[18:35] 구축하기는 쉽지 않아요.

[18:36] 이런 각 단계마다

[18:38] 실패 케이스가 있다고 생각하면

[18:40] 이렇게 생각해볼 수 있어요.

[18:41] 연구가 잘못된 결론에 도달하면

[18:43] 아래 모든 것들이 망가지게 되죠.

[18:46] 저도 이런 걸 많이 봤어요.

[18:48] PM이 사용자 보이스에서 무작위 요청을 보고

[18:50] 말도 안 되는 것을 구축하자고 제안하면

[18:52] 그것이 디자인팀에 넘겨지죠.

[18:54] 그리고 디자인팀은 PM보다 사용자에 대해

[18:56] 더 안다고 가정하지 않아요. 그래서 PM이 와서

[18:58] 이걸 해야 한다고 하면

[19:00] 그냥 그대로 해버리죠. 그러면 이제

[19:02] 실패한 스펙에 맞춰서 뭔가를

[19:03] 디자인하게 되거나, 스펙은 좋았어도

[19:05] 사용자에게 말이 안 되는 것을

[19:06] 디자인하게 되는데, 우리는 여기

[19:08] 맨 아래까지 가야만 그걸 알 수 있어요.

[19:10] 그리고 나서 그들이 스펙을 작성하죠.

[19:11] 디자인과 연구는 좋았을 수도 있지만

[19:13] 스펙이 사람들이 실제로

[19:15] 이해할 수 없는 방식으로 이야기하고 있는데

[19:17] 그들은 그걸 모르죠. 계획을 듣고

[19:20] 프레젠테이션을 들으면서

[19:22] 이게 정확히 무엇이 될지

[19:23] 완전히 이해했다고 생각하고

[19:25] 가서 기술 스펙을 작성하는데, 그것이

[19:26] 그 잘못된 가정들을 그대로 가져가죠.

[19:28] 그 잘못된 가정들을 그대로 가져와서

[19:30] PM이 기술 명세를 이해하지 못한다고 말해요.

[19:32] 그래서 PM이 기술 명세 계획 회의에 나타나면

[19:33] 그들의 눈이 멍해져요

[19:36] 소프트웨어 개발 쪽에는 관심이 없으니까요.

[19:37] 그래서 명세에 대한 잘못된 가정들을

[19:39] 들어도

[19:41] 아예 눈치채지도 못해요.

[19:43] 하지만 그 모든 게 잘 진행돼서

[19:45] 빌드를 시작한다고 해도, 만약

[19:47] 제대로 조화되지 않거나

[19:49] 실제로는

[19:51] 해결하려는 문제를 해결하지 못하는

[19:52] 방식으로 빌드하고 있다면? 그걸 알아차리는 데

[19:54] 얼마나 걸릴까요? 아마 리뷰 과정에서

[19:56] 많은 것들이 막힐 거예요.

[19:58] 개발자들이 다른 개발자들의 코드를 리뷰하는데

[19:59] 왜 그걸 하는지 모르면

[20:00] 이미 잘못된 가정이

[20:01] 들어있을 수도 있는 명세를

[20:03] 확인하러 가죠.

[20:05] 그리고 마침내 출시해요.

[20:07] 이게 사용자들이 원하는 건지 기도하죠.

[20:09] 그런데 맨 처음 리서치 단계에서

[20:11] 했던 것들이

[20:12] 잘못된 가정이었다는 걸 깨닫죠.

[20:15] 그러면 전체 제품을 죽이고

[20:16] 팀을 해고해야 해요. 팀들이

[20:17] 특정 제품을 중심으로 구성됐는데

[20:19] 그게 실수였거든요.

[20:20] 하지만 팀을 해고하지는 않죠.

[20:22] 대신 재조직을 하고

[20:23] 갑자기 저는 C 레벨 개발자들에게

[20:26] React 코드 쓰는 법을

[20:27] 가르쳐야 하는 상황이 돼요.

[20:29] 회사가 실수를 인정할 용기가 없었거든요.

[20:31] 여기서 실제 경험을 토로하는 건 절대 아니에요.

[20:33] 그래서, 이 빌드 단계를 빠르게 만드는 건

[20:35] 전혀 도움이 안 돼요. 완전히

[20:38] 동의해요. 이걸 빠르게 만들려고 한다면

[20:40] 아무 도움이 안 되죠. 왜냐하면

[20:42] 리뷰 과정을 더 느리고

[20:44] 어렵고 잠재적으로 더 위험하게 만들거든요.

[20:46] 이 단계가 실패할 가능성을 높여요.

[20:48] 그리고 똑같이, 아니 그보다

[20:50] 더 느린 위쪽 부분들은 전혀 도와주지 못하죠.

[20:52] AI가 빌드를 도와주는 장점은

[20:54] 여기 4단계에 있던 빌드를

[20:57] 1단계의 일부로 옮겨서

[20:59] 올바른 일을 하고 있는지 확인할 수 있다는 거예요.

[21:01] 그리고 이걸 제대로 활용한다면

[21:03] 정말 대단한 성과죠. 하지만 저는 회사들이

[21:05] 이 과정에 너무 고집스럽게

[21:07] 매달리려고 하는 게 걱정돼요.

[21:08] 이런 멋진 바이브 코딩 도구들에서

[21:10] 많이 본 것처럼, 저는 방금

[21:13] GitHub Spark에 대한 비디오를 찍었는데 바로

[21:15] PRD를 하는 혼란에 부딪혔어요.

[21:17] 정확히 무엇을 빌드할지

[21:18] 자세히 설명하는 거죠. 또는 얼마 전에

[21:21] Kira로 했던 것들을 보면

[21:23] 여기서 뭘 하려고 했는지의 완전한 혼란을

[21:26] 볼 수 있어요. 아마 명세를 삭제했을 거예요.

[21:26] 다루기 싫었거든요.

[21:28] 맞아요, 그랬어요. 그래서

[21:30] 명세를 삭제했는데, 그게

[21:32] 수천 줄의 마크다운을 써서

[21:34] 무엇을 하고 싶고

[21:37] 어떻게 생각하고 싶은지 설명했었어요.

[21:40] 여기 상위 부분들을 바이브 코딩하고 있는 거예요.

[21:42] 이건 오히려 더 나쁘다고 주장하고 싶어요.

[21:44] 바이브 코딩의 멋진 점 중 하나는

[21:45] 버리는 것에 대해 나쁘게 느끼지 않는다는 것입니다. 만약

[21:47] 평범한 개발자가 정말 초기에 빌드하고,

[21:49] 제품이 안 좋다는 걸 깨닫고 폐기한다면,

[21:51] 그들은 정말 기분 나쁠 거예요. 하지만 AI가

[21:53] 하게 하거나 저같은 사람이 하게 하면,

[21:54] 저는 제 코드가 버려지는 걸 좋아해요.

[21:56] 더 말이 되는 것으로 교체되거나

[21:57] 말이 안 되기 때문에 deprecate되는

[21:58] 것을 알면 기분이 좋습니다. 저는

[22:00] 그런 바이브를 좋아해요. 하지만 이 부분을

[22:01] 코딩 아웃한다고 해서 그런 장점들을

[22:04] 얻을 수 있는 건 아니고, 오히려 더 많은

[22:06] 단점들만 생깁니다. 정말 별로예요.

[22:07] 이건 우리 모두 동의할 수 있을 것 같은데,

[22:09] 이런 제품 스펙의 어려운 부분은

[22:10] 실제로 작성하는 것도 아닙니다. 그런 걸

[22:12] 작성하는 것은 그렇게 어렵지 않아요.

[22:15] 진짜 문제는 억지로 앉아서

[22:16] 그걸 읽는 것이 세상에서 가장 끔찍한 일이라는 것입니다.

[22:18] 그리고 이게 제 ADHD 때문인지는 모르겠지만,

[22:21] 틀렸다면 채팅으로 말해주세요.

[22:22] 하지만 그냥 거기 앉아서

[22:24] 이런 스펙들을 읽어나가는 것이

[22:27] 세상에서 가장 최악입니다. 코드 리뷰보다 훨씬 나쁘고,

[22:30] 더 중요하게는 직접 코딩하는 것보다

[22:32] 훨씬 더 나쁩니다. 그리고 저는

[22:34] 프로토타입과 데모를 만들고

[22:36] 이런 것들을 직접 테스트하는 것을

[22:39] 거기 앉아서 스펙을 읽으면서

[22:41] 흥미를 잃지 않으려고 애쓰고

[22:43] 실제 문제를 찾으려고 하는 것보다

[22:46] 훨씬 더 선호합니다. 개인적으로

[22:47] 제가 좋아하는 것들은 그런

[22:50] 일반적인 마인드셋에 맞습니다. 저는 코드를 좋아해요.

[22:52] 대화도 좋아하고, 새로운 아이디어와

[22:54] 솔루션을 가지고 놀아보는 것도 좋아합니다.

[22:58] 그리고 개인적으로는 작동하지 않는

[23:01] 것들을 deprecate하는 것도 좋아해요.

[23:04] 또한 가능한 곳에서는 단순화하는 것도요.

[23:07] 이런 것들은 모두 제가 좋아하는 일들입니다.

[23:09] 그리고 여기는 제가 좋아하지 않는 것들이에요.

[23:12] 코드 리뷰, 긴 스펙 읽기,

[23:15] PM에게 8개월에서 12개월간

[23:18] 계획해온 프로젝트를 끝내라고

[23:21] 설득하는 것,

[23:23] 10명 이상이 참석하는 회의에 앉아있는 것

[23:26] - 지루해서 아무도 주의를 기울이지 않는

[23:30] 그런 회의들 말이에요. 저는 이런 것들이 싫어요.

[23:33] 사실 코드 리뷰는 어느 정도 좋아해요.

[23:34] 코드 리뷰를 좋아해야 한다고 말해야겠네요.

[23:37] 아무도 정말 사랑하지는 않지만,

[23:38] 그래도 중요한 과정이고 지금 팀에게

[23:40] 리뷰를 너무 많이 빚져서

[23:41] 말 그대로 속이 메스꺼워요.

[23:43] 하지만 여기서 요점은, 도입하는 툴이

[23:46] 사람들이 이 부분에 시간을 쓰기 더 쉽게 만들고

[23:48] 이 부분에 시간을 쓰기 더 어렵게 만든다면,

[23:50] 그러면 그 툴들은

[23:51] 정말 별로라는 겁니다. 그러니까

[23:53] AWS의 AI 코딩 IDE인 Hero 같은 걸 보면,

[23:55] 그것은 제가 코딩을 덜 하게 만들어요.

[23:59] 다른 사람들과도 덜 대화하게 하죠.

[24:00] 왜냐하면 저는 그냥 에디터에서

[24:01] 일이 끝나기를 기다리고 있으니까요.

[24:02] 새로운 아이디어를 가지고 놀기 더 쉽게

[24:04] 해주지도 않아요. 왜냐하면 모든 것이

[24:06] 그것이 생성하는 거대한 마크다운

[24:07] 파일들에 구워져 있어야 하거든요.

[24:09] 그것이 반드시 deprecation을

[24:11] 더 쉽게 하거나 어렵게 하는 것도 아니에요.

[24:12] 거기서는 그냥 noop 같은 건데,

[24:14] 하지만 당신은 뭔가를 제거하거나

[24:16] 단순화할 인센티브가 전혀 없어요.

[24:18] 그냥 AI가 일하게 놔둘 뿐이죠. 그래서 그것은

[24:20] 하위 부분에 대한 인센티브를 제거하고

[24:23] 상위 부분을 더 이상 할 수 없게 만듭니다.

[24:24] 이런 것들을 대체하고 있어요.

[24:26] 제가 싫어하는 부분은 무엇일까요?

[24:27] 훨씬 많은 코드를 검토해야 한다는 거죠.

[24:29] 에디터에서 절반의 시간을

[24:30] 스펙 읽기에 보내야 합니다.

[24:32] 저는 스펙 읽기를 피하려고

[24:34] 에디터에 오는 건데, 왜 그걸 제 일로 만드나요?

[24:35] PM들이 프로젝트를 끝내도록

[24:37] 설득하는 데도 도움이 안 됩니다.

[24:39] 이제 그들은 이 도구를 사용해서

[24:40] 직접 만들 수 있다고 확신하거든요.

[24:41] 제가 나쁜 아이디어라고 말하면

[24:43] '그냥 Cursor 써서 빨리 만들어보고

[24:44] 그러면 어떻게 느끼는지 보자'고 해요.

[24:46] 그리고 이제 코딩에 시간을 쓰지 않으니까

[24:48] 쓸데없는 회의에 앉아서

[24:49] 많은 사람들과 보낼 시간이 훨씬 많아졌죠.

[24:51] 네, 제가 가진 문제는

[24:53] 이런 도구들이 우리가 실제로 즐기는 부분,

[24:55] 실제로 재미있게 할 수 있는 것들,

[24:57] 그리고 그 과정에서 잠재적으로

[24:59] 제품을 개선할 수 있는 것들을 빼앗고

[25:00] 우리가 실제로 즐기지 않는

[25:02] 것들로 대체한다는 거예요.

[25:03] 그리고 우리를 더 생산적으로 만드는 방식이 아니라

[25:05] 단순히 노력을 다른 곳으로 옮기는 방식으로요.

[25:07] 에디터에서 직접 손으로 코드를 작성하는 것을

[25:09] 코드를 검토하는 것으로 대체했습니다.

[25:10] 프로토타입 만들기를

[25:13] AI가 거대한 스펙을 작성하도록 하는 것으로 대체했어요.

[25:15] 이건 좋지 않은 거래입니다.

[25:17] 이런 도구들로부터 혜택을 받으려면

[25:19] 맨 위로 올라가서 우리의 프로세스를

[25:21] 다시 생각해야 합니다.

[25:24] 기존 프로세스는 이런 새 도구들과

[25:25] 잘 맞지 않습니다.

[25:27] 사실상 재미있는 부분들을 죽이고

[25:30] 별로인 부분들을 훨씬 쉽게 만들어서

[25:32] 너무 많은 텍스트를 생성하게 만들죠.

[25:34] 그런데 이 차트를 오래전에 봤는데,

[25:35] 지금 찾고 싶지 않으니까 그냥 넘어갈게요.

[25:38] 하지만 그 차트는 정말 웃긴 곡선이었는데

[25:41] 몇 개의 포인트가 있었어요.

[25:43] 단어 수로만 세면 평균적인 법률의 길이가

[25:46] 상대적으로 짧았던 시점들이 있었고

[25:49] 시간이 지나면서 꽤 의미있게

[25:51] 급증하기 시작했고, 그러다가 갑자기

[25:53] 다시 급증했습니다. 그리고 최근에는

[25:56] 훨씬 더 심하게 급증했어요.

[25:58] 이런 급증 시점들은 이해가 되는 것들이었습니다.

[26:00] 첫 번째는 타자기의 도입이었어요.

[26:02] 갑자기 법률이 훨씬 길어지기

[26:03] 시작했고, 정말 빠르게 늘어났죠.

[26:06] 그다음에는 복사 붙여넣기가 가능한

[26:08] 워드 프로세서가 나왔습니다.

[26:11] 복사 붙여넣기나 법률이 없던 시절이

[26:12] 있었는데, 그 일을 하는 건

[26:15] 생각도 하기 싫어요.

[26:18] 하지만 지금 AI 생성으로 인해

[26:20] 법률의 길이가 급증하고 있습니다.

[26:22] 어떤 것을 하기 훨씬 쉽게 만들면

[26:24] 결국 그것이 훨씬 많아지거든요.

[26:26] 하지만 문제가 그 것의 양이 아니라

[26:28] 질이라면, 이건 나쁘다는 거죠.

[26:31] 미국이나 다른 곳의 법률 문제는

[26:33] 법률에 충분한 단어가 없다는 게 아니에요.

[26:35] 더 많은 단어가 더 좋은 법률을

[26:37] 만든다는 데 모두 동의할 수 있기를 바랍니다.

[26:38] 더 많은 코드가 더 나은 앱과 같지 않다는 것도

[26:41] 마찬가지로 동의할 수 있을 거예요. 사실 저는

[26:42] 종종 그 반대를 의미합니다. 여기엔

[26:44] 역상관관계가 있어요. 그리고 이러한

[26:46] 새로운 기술들은 잘못된 부분을

[26:48] 더 쉽게 만들었습니다. 많은 글을

[26:50] 쓰는 것은 쉽게 만들었지만

[26:51] 좋은 법률을 작성하는 것은 더 쉽게 만들지 못했어요. 그 결과

[26:53] 좋은 법률을 통과시키기가 더 어려워졌습니다

[26:55] 왜냐하면 이제 핵심에 도달하기 전에

[26:56] 훨씬 더 많은 헛소리를 파악해야 하거든요.

[26:58] 그리고 만약 우리가 AI 코드로 그렇게 된다면

[27:00] 우린 망할 겁니다. 만약 정말로

[27:02] 우리 일이 이제 그냥 코드 리뷰하는 것이라면

[27:04] 패턴이나 관행을 따르지 않는

[27:06] 거대한 쓰레기 더미를 말이죠

[27:08] 다른 누군가가 우리에게 가서

[27:11] 헛소리를 생성하라고 했다는 이유로요

[27:13] 그건 정말 최악일 겁니다. 그래서 우리는

[27:15] 이런 것들로부터 혜택을 얻고 싶다면

[27:17] 우리의 프로세스를 다시 생각해야 합니다. 우리는

[27:19] 코드는 생산하기가 더

[27:20] 간단하지만 검증하기는 더

[27:21] 복잡한 상황에 처하게 됩니다. 이는

[27:22] 팀이 전체적으로 더 빨리 움직이게 만든다고

[27:24] 반드시 말할 수는 없어요. 절대 그렇습니다.

[27:25] 아마 우리를 더 느리게 만들 겁니다. 리뷰 프로세스,

[27:27] 스펙 프로세스, 이 모든 것이

[27:29] 처리해야 할 코드가 더 많다면 더 느려질 겁니다.

[27:31] 새로운 도전은 아닙니다.

[27:33] 개발자들은 오랫동안

[27:34] 복사붙여넣기 엔지니어링에 대해 농담해왔지만

[27:36] LLM이 가능하게 하는 속도와 규모는

[27:38] 그런 복사붙여넣기 습관을 증폭시켰습니다.

[27:40] 완전히 동의합니다. 모든 LLM과

[27:43] 백엔드 에이전트, 이런 것들이

[27:45] Google로 Stack Overflow를 검색하고

[27:47] 스테로이드를 맞은 코드 복사붙여넣기라고 말할 수 있어요.

[27:50] 코드를 이해하는 것은 여전히 어려운 부분입니다.

[27:52] 가장 큰 비용은 코드를 이해하는 것이지

[27:53] 작성하는 것이 아닙니다. 완전히 동의합니다.

[27:56] LLM은 코드를 생산하는 데 걸리는 시간을 줄였지만

[27:58] 동작에 대해 추론하고

[27:59] 미묘한 버그를 식별하거나

[28:01] 장기적인 유지보수성을 보장하는 데 필요한

[28:03] 노력의 양은 바뀌지 않았습니다. 이런 작업은

[28:05] 리뷰어들이 생성된 코드와

[28:07] 직접 작성된 코드를 구별하는 데 어려움을 겪거나

[28:08] 특정 솔루션이 선택된 이유를

[28:10] 이해하지 못할 때 더욱 어려워질 수 있습니다.

[28:12] 완전히 동의합니다. 그리고 다시

[28:14] 제가 앞서 했던 요점을 강조하자면

[28:16] 거의 두 가지 종류의 코드가 있는 것처럼 느껴집니다

[28:17] 일회용 코드와 프로덕션 코드가요.

[28:20] 여기서 목표는 왼쪽에는

[28:24] 제품이 무엇인지 알아내는 것이나

[28:25] 그것이 작동할지 여부를 알아내는 것이 목표이고

[28:27] 모든 것이 사라져도 상관없는 경우이고

[28:29] 오른쪽은 오랫동안

[28:31] 유지보수될 것으로 예상되는 코드이며

[28:33] 더 오랫동안 해야 할 일을

[28:35] 계속 수행해야 하는 코드입니다.

[28:37] 일회용 코드는

[28:39] 벤치마크를 위한 제 허접한 스크립트나

[28:41] 샌드박스 또는 어떤 새로운

[28:44] 기능을 위한 프로토타입 같은 것들입니다.

[28:48] 반면 프로덕션 코드 측면은

[28:51] 메인 제품을 위한 핵심 인프라나

[28:56] 수백만 개의 앱을 지원하는 Rust 라이브러리나

[29:01] 12명의 개발자가 구축하는 새로운 기능입니다.

[29:05] 문제는 최근까지

[29:08] 이 두 가지 사이의 비용 차이가

[29:10] 그렇게 크지 않았다는 것입니다. 이제

[29:13] 왼쪽의 것들은 구축하기 매우 쉽고 오른쪽의 것들은

[29:15] 구축하기 쉽다는 것이 명백해 보입니다

[29:17] 오른쪽은 그렇지 않다는 걸 알 수 있죠. 하지만 우리는 아직도

[29:19] 사람들이 진심으로

[29:21] 모든 것을 Rust로 작성해야 한다고

[29:22] 말하던 시대의 여파에 있습니다. 작은 사이드 프로젝트까지도 말이에요.

[29:24] 사람들이 이 두 가지

[29:26] 코드 유형 사이의 차이를 전혀

[29:28] 인식하지 못했기 때문이죠. 저를 특별하게 만든 것은

[29:30] 이 둘을 구별하는 데 능숙했다는 점이었습니다.

[29:32] 언제 일회용 코드를 작성하는 것이

[29:34] 최선인지 아는 것, 이 부분을 정말 빠르게 작성하고

[29:36] 그런 다음

[29:38] 어떤 부분을 프로덕션화해서

[29:40] 다른 쪽으로 가져갈지 파악하는 것이었죠.

[29:42] 저는 작업하고 있는 프로젝트에서 이 두

[29:45] 측면 사이를 빠르게 전환했습니다.

[29:46] 일회용 코드 쪽에서 데모를 만들었죠.

[29:48] 사용자들과 반복 작업을 하고

[29:51] 그들이 실제로

[29:52] 원하는 기능이 무엇인지 파악했습니다. 그런 다음 더

[29:55] 프로덕션 버전을 구축하고

[29:58] 어떤 이상한 기술적 문제에 부딪히면

[30:00] 다시 돌아가서 다른

[30:03] 기술 구현을 프로토타입했습니다. 저는 코드를

[30:06] 다른 사람이 승인하기 위해

[30:08] GitHub에 올리는 것으로만 사용하지 않았습니다.

[30:10] 그리고 사용자에게 배포하지도 않았어요. 저는 코드를

[30:12] 다른 많은 용도로도 사용했습니다. 저는

[30:14] 무엇을 구축할지 파악하는 데 사용했습니다. 저는

[30:16] 다른

[30:17] 기술 구현을 테스트하는 데 사용했습니다. 저는

[30:19] 이메일을 처리해서 어떤

[30:21] 보고서를 더 자주 받고 있는지 파악하는 데 사용했습니다. 저는

[30:22] 코드 자체가 중요하지 않은

[30:24] 모든 종류의 일에 사용했고

[30:25] 아무도 리뷰하기를 원하지 않았습니다.

[30:27] 그게 요점이 아니었거든요. 만약

[30:29] 코드에서 리뷰할 가치가 있는 것이 있다면

[30:30] 저는 그것을 복사해서 붙여넣어

[30:32] 실제 PR이나 어딘가의 gist에 넣고

[30:34] 팀에게 보내서 보게 했습니다.

[30:36] 하지만 이런 구별은

[30:38] 많은 엔지니어들이 할 수 있거나 하려고 하는 것이 아니었습니다.

[30:40] 대부분의 엔지니어들은

[30:42] 무엇을 하든 상관없이

[30:44] 같은 방식으로 코드를 작성하기 때문입니다. 제가 얼마나 많은

[30:46] FAANG 회사에서 일하는 사람들의

[30:48] 사이드 프로젝트를 봤는지 말할 수 없어요. 그리고 이런 FAANG 인턴들이

[30:50] 사이드 프로젝트를 할 때

[30:52] Facebook이나

[30:54] Netflix의 스택과 동등한 것을 개인 할 일 목록을 위해

[30:57] 구축하고 있습니다. 그리고 사람들이 이것들을 구별하지 못하고

[30:59] 다른 부분에서

[31:00] 작동하는 패턴을 찾지 못하고

[31:02] 각 쪽에서 배우지 못하는 것은

[31:05] 매우 현실적인 문제입니다. 그리고 결과적으로

[31:07] 이런 AI 도구들이 많은 사람들을 혼란스럽게 할 것입니다.

[31:09] 왜냐하면 만약 여러분이

[31:10] Lovable 같은 것을 보고 있는데

[31:13] 일회용 코드와 프로덕션 코드가

[31:14] 같은 것이라고 생각하고

[31:16] 같은 방식으로 작성한다면, 솔직히 말해서 Lovable은

[31:18] 일회용 코드 쪽에 속합니다.

[31:21] 대부분의 에이전트 코드 도구들이 그렇듯이. 만약

[31:23] 그것이 이런 것들을 하기 위해 만들어진 곳인데

[31:26] 여러분이 머릿속에서 이 둘을

[31:27] 의미 있게 구별하지 않는다면, 여러분은 이것을

[31:29] 나쁘고 이것을 좋다고 보게 됩니다. 다른 목적을 위한

[31:31] 다른 가치가 아니라요. 이제 여러분은

[31:34] 이것을 형편없고 쓸모없는 도구로 봅니다. 하지만

[31:36] 만약 여러분이 이것을

[31:37] 프로덕션 코드를 더 간단하고 좋게 만드는 방법으로 생각한다면

[31:39] 실제 것을 작성하는

[31:40] 같은 방식으로 프로토타입을 만들 필요가 없기 때문입니다.

[31:43] 여러분도 이런 도구들로부터 많은

[31:44] 혜택을 얻기 시작할 거예요. 제가 여기서

[31:46] 정말 강조하고 싶은 점은, 러버블 같은

[31:49] 도구에서 여러분이 작성한 코드나

[31:50] 제가 프로토타입 단계에서 작성한

[31:52] 코드를 팀에게 리뷰를 위해

[31:54] 던져준다면, 팀원들이 여러분을

[31:56] 싫어하게 될 거라는 거예요. 왜냐하면

[31:57] 그 코드는 리뷰를 위해 작성된 게

[31:59] 아니거든요. 그 코드는 읽히기 위해

[32:00] 작성된 게 아니라, 뭔가를 알아내기

[32:02] 위해 작성된 거예요. 반면 이 코드는

[32:04] 유지보수를 위한 거고, 이 코드는

[32:06] 문제를 해결하기 위한 거죠. 보통은

[32:08] 지식 격차라는 문제를 말이에요. 팀은

[32:10] 여전히 신뢰와 공유된 맥락에

[32:12] 의존합니다. 맞아요. 소프트웨어

[32:13] 엔지니어링은 항상 협력적이었어요.

[32:15] 공유된 이해, 정렬, 멘토링에

[32:17] 의존하죠. 하지만 코드가 논의되거나

[32:18] 리뷰될 수 있는 속도보다 빠르게

[32:20] 생성될 때, 팀은 품질이 보장되는

[32:22] 게 아니라 당연히 있을 거라고

[32:24] 가정하는 모드로 빠질 위험이

[32:26] 있어요. 그러면 리뷰어와 멘토에게

[32:28] 스트레스가 생기고, 더 미묘한

[32:31] 방식으로 속도가 느려질 가능성이

[32:33] 있죠. 이 부분도 완전히 동의해요.

[32:34] 멘티가 코드베이스를 따라잡을

[32:36] 때쯤이면, 누군가 PR을 올려서

[32:38] 기존에 있던 모든 걸 파괴해버렸기

[32:40] 때문에 절반이 바뀌어 있을 거라면,

[32:42] 행운을 빌어요. AI가 생성해주면

[32:43] 더 오래 걸릴 일을

[32:44] 그냥 해결할 수 있다고 생각해서

[32:46] 이 사람을 멘토링할 올바른 마인드셋이

[32:48] 없다면, 당신은 망한 거예요.

[32:50] 멘티가 AI로 뭔가를 생성했는데

[32:51] 그게 당신이 보통 AI로 생성하는

[32:53] 코드와 똑같아 보여서 머지를

[32:55] 눌렀는데 실제로는 작동하지 않는다면,

[32:57] 당신은 망한 거예요. 이런 문제들은

[32:59] 우리가 버릴 코드와 프로덕션

[33:01] 코드를 구별하지 않을 때 발생합니다.

[33:04] 이 글의 마지막 포인트는

[33:05] LM이 강력하지만 기본기를 고쳐주지는

[33:06] 않는다는 거예요. 더 빠른 프로토타이핑,

[33:08] 스캐폴딩, 자동화에는 진짜 가치가

[33:11] 있어요. 오, 봐라. 끝에서 완전히

[33:13] 일치하네요. 그럴 줄 알았어요.

[33:16] 네, 제가 흥미롭게 생각하는

[33:18] 점은 예전에는 대부분의 개발자들이

[33:19] 버릴 버전을 훨씬 빠르게

[33:21] 만들 능력이 없었다는 거예요.

[33:23] 솔직히 말해서 트위치에서 제

[33:25] 팀원들에게 이 기능이 작동하는지

[33:27] 확인하기 위해 뭔가를 만들어보라고

[33:28] 하고, 프로덕션 준비 버전은

[33:30] 9개월이 걸릴 것 같다고 하면서,

[33:32] 우리가 가지고 놀 수 있는 데모

[33:35] 버전은 얼마나 빨리 만들 수

[33:36] 있냐고 물으면, 아마 2-3개월

[33:39] 정도라고 할 거예요. 하지만 그걸

[33:42] 2-3일에 할 수 있어요. 딥테크

[33:43] 베팅 같은 게 아닌 이상, 며칠

[33:45] 안에 사용 가능한 버전을 만들

[33:48] 수 없는 제품은 거의 없어요.

[33:50] 하지만 여러분의 쓰레기 CRUD 앱은

[33:53] 그런 경우가 아니에요. 그만

[33:54] 가짜짓 하세요. 만약 여러분이

[33:55] 프로덕션 프로세스를 몇 개월에서

[33:57] 몇 개월로 줄이는 게 최선이라고

[33:59] 정말로 생각한다면, 더 빨리

[34:01] 프로토타입을 만드는 데 6개월이 걸린다면,

[34:03] 그건 프로토타입이 아니에요. 그걸

[34:05] 프로토타입이라고 부르면 안 됩니다.

[34:07] 6개월간의 작업을 버리는 게

[34:08] 너무 아까울 테니까요. 제가 2주 동안

[34:10] 데모 버전을 만들거나 3일 동안

[34:12] 데모 버전을 만들어서 전체를

[34:14] 버린다고 해도, 저는 전혀

[34:15] 신경 안 써요. 그게 바로 핵심이거든요.

[34:17] 우리는 여전히 교훈을 얻었으니까요.

[34:20] 저자의 말처럼, LLM은 명확한

[34:21] 사고, 신중한 검토, 사려 깊은

[34:22] 설계의 필요성을 없애주지 않습니다.

[34:24] 그런 건 우리가 무엇을 만들지

[34:26] 파악한 후의 문제예요. AI가 그런

[34:28] 부분들을 대체해주지는 않아요.

[34:31] 하지만 여기서 이 격차를 인정하지

[34:32] 못한다면, 정말 바보처럼 들립니다.

[34:34] 제가 자주 보는 문제가 이거거든요.

[34:36] 프로덕션 코드 쪽에 인생을 걸고 있는

[34:40] 사람이 있어요. 주요 엔지니어라고 해봅시다.

[34:42] 어떤 임원이나 PM이 이 주요

[34:43] 엔지니어에게 가서... 가짜 슬랙

[34:46] 대화를 만들어볼게요. CEO: 안녕,

[34:50] 주요 엔지니어님, 러버블로 새로운

[34:54] 아이디어를 테스트할 수 있을까요? 안 좋은 기능을

[34:59] 그만 만들기 위해 유용할 것 같은데. ㅋㅋ

[35:04] 주요 엔지니어: CEO님, 진심이세요?

[35:08] 감정적 코딩 헛소리가 저희

[35:11] 최고급 개발팀보다 낫다고 생각하세요?

[35:13] 제가 Azure 인증을 받았다는 걸

[35:17] 상기시켜 드려야 하나요? 지난주에

[35:22] 애자일 수업도 훌륭하게 들었는데요.

[35:24] 더 뭘 원하세요? 이게 바로

[35:25] 문제예요. 이 CEO나... 사실 CEO가

[35:28] 아니라고 해봅시다. 그냥 일반적인

[35:30] PM이 이렇게 말하고, 그 제품

[35:32] 관리자는 정말로 어떤 기능이 좋은

[35:34] 아이디어인지 나쁜 아이디어인지를

[35:35] 더 일찍 파악하고 싶어해요. 무의미한

[35:38] 일들에 너무 많은 시간을 낭비하는 게

[35:41] 지겨웠거든요. 제가 이걸 비꼬게

[35:43] 만들었지만, 이건 정말 현실적인

[35:44] 일이에요. 실제로는 이렇게

[35:45] 보일 겁니다. '3개월 미만으로 만든

[35:47] 것에서 의미 있는 정보를 얻을 수

[35:49] 있다고 생각하지 않아요. 러버블은

[35:51] 개발자가 아닌 사람들이 개인 앱을

[35:54] 만드는 용도지, 실제 업무용이 아니에요.'

[35:55] 저는 PM들로부터 이런 메시지를

[35:57] 본 적이 있어요. 이런 일이 정말

[35:59] 일어나지 않는다고 생각한다면, 이걸 보세요.

[36:04] '러버블'이라는 단어를 다른 걸로

[36:07] 바꿀 수도 있어요. Electron이나

[36:09] React나 JavaScript나 Supabase나

[36:11] Convex나 우리가 여기서 얘기하길

[36:13] 좋아하는 기술들 중 아무거나요.

[36:14] 그러면 이런 사람들이 항상 보내는

[36:16] 아주 현실적인 메시지라는 걸

[36:18] 깨달을 거예요. 러버블이 그런

[36:21] 것들 중 하나라는 사실이 제 말의

[36:23] 의미를 보여줍니다. 여기서 핵심은

[36:26] 주요 엔지니어가 자신의 관점 밖에서

[36:28] 생각하지 못한다는 거예요. 그들에게

[36:30] 의미 있는 정보는 '제품이 유용한가?'가

[36:33] 아니에요. 그들이 이 지점에서

[36:35] 말하는 건 훨씬 다릅니다. 그들이

[36:37] 말하는 의미 있는 정보는 '기술

[36:39] 사양이 작동하는가?'예요. 그들은

[36:41] 제품이 이미 작동한다고 가정해요.

[36:43] PM이 어떤 상황에 있는지 듣지

[36:45] 못해요. 그들이 생각할 수 있는 건

[36:46] 만들면서 그것을 어떻게 만들지

[36:48] 그들은 그런 경로와 가능성을

[36:49] 완전히 무시할 것입니다. 하지만 PM은

[36:52] 다른 사람들이 이 도구로

[36:53] 유용한 것들을 만드는 걸 보게 됩니다.

[36:54] 그들이 해결하고 싶어하는

[36:56] 문제들을 이런 도구들로

[36:58] 충분히 해결할 수 있다는 걸 깨닫게 됩니다.

[37:00] 그들은 서로 다른 말을 하고 있어서

[37:02] 깊은 좌절감을 느끼게 될 거예요.

[37:03] 바로 이렇게 적대적인 관계가 생기는 겁니다.

[37:05] 저는 이런 종류의 대화가

[37:08] 앞으로 정말 많이 일어날 거라고

[37:09] 확신하고, PM들과 수석 엔지니어들이

[37:11] 엄청 많이 싸우게 될 거라고 생각합니다.

[37:13] 왜냐하면 이쪽 사람들은 프로토타입의 가치를

[37:16] 전혀 보지 못하고, 저쪽 사람들은

[37:19] 수석 엔지니어가 여기서 생각하는 게

[37:20] 기술적인 세부사항이지

[37:22] 그 기능이 만들 가치가 있는지 없는지가

[37:24] 아니라는 걸 이해하지 못하거든요.

[37:25] 제가 Twitch에서 가장 멋진 순간 중 하나는

[37:26] 제 디자이너가 갑자기

[37:27] HTML과 JavaScript에 대한

[37:29] 무작위 질문들을 저에게 하기 시작했을 때였어요.

[37:31] 정말 혼란스러웠는데 왜냐하면

[37:32] 그건 그녀의 역할과는 전혀 상관이 없었고

[37:34] 우리가 Twitch에서 사용하는 것들에 대한

[37:36] 질문도 아니었거든요. 그래서

[37:38] 그녀가 뭘 하고 있는지 물어봤어요.

[37:39] 그녀가 스크린샷을 보내줬는데

[37:40] 알고 보니 Mod View의

[37:42] 프로토타입 버전을 만들려고 하고 있었어요.

[37:44] 보기에는 정말 매력적이었지만

[37:46] 실제로는 전혀 작동하지 않았어요.

[37:48] 실제 데이터도 사용하지 않았고요. 그냥

[37:50] 데모용 데모였어요. 이게 어떨지

[37:52] 보여주는 용도로 만든 거였죠.

[37:53] 그래서 그걸 모더레이터들 앞에 놓고

[37:56] 이게 어떻게 보이는지, 얼마나 유용한지

[37:58] 물어볼 수 있게요. 제가 함께 일한

[38:00] 최고의 디자이너 중 한 명인

[38:02] 아이리스 같은 사람이라면 이런 도구들로

[38:04] 엄청난 도움을 받을 거예요.

[38:06] PR을 많이 올리게 되어서가 아니라

[38:08] 훨씬 더 반복적인 과정을 통해

[38:09] 올바른 것이 무엇인지 알아낼 수 있기 때문이죠.

[38:12] 이게 제가 강조하고 싶은 핵심입니다.

[38:15] 다음 깨달음까지의 시간을 개선하는 것은 정말 좋은 일입니다.

[38:19] 우리는 통찰력을 최적화해야 합니다.

[38:21] 가정에서 새로운 학습으로 얼마나 빨리 갈 수 있을까요?

[38:24] 사용자가 어떤 것을 원한다는 가정이 있다면

[38:27] 그들이 정말 원하는지 알아내는

[38:29] 가장 짧은 경로는 무엇일까요?

[38:30] 이 버튼이 이런 식으로 작동해야 한다고 생각한다면

[38:32] 정말 그래야 하는지 알아내는

[38:34] 가장 짧은 경로는 무엇일까요?

[38:36] 다음 학습, 다음 통찰, 다음 이해,

[38:39] 전에는 이해하지 못했던 것을

[38:41] 이해하게 되는 다음 순간으로

[38:44] 얼마나 빨리 갈 수 있을까요?

[38:45] 이런 도구들을 사용해서 더 많은 통찰을 얻고

[38:48] 우리가 뭔가를 알아낼 때 더 많은

[38:50] '아하' 순간을 가질 수 있다면

[38:52] 그들은 유용합니다. 하지만 그 과정에서

[38:55] 아무런 통찰도 얻지 못하고

[38:56] 스피드런을 하는 데만 사용한다면 최악이죠.

[38:59] 이런 도구들 중 많은 수가

[39:01] 이런 방식으로 홍보되지 않는다고 생각해요.

[39:02] 이런 도구들은 '개발자들이 느려요.

[39:04] 그들을 대체하고 더 빠르게 만드세요'라고

[39:06] 홍보되고 있어요. '우리 사용자가 원하는 걸

[39:08] 더 빨리 알아낼 수 있어요. 더 효과적으로

[39:11] 더 효과적으로 할 수 있습니다. 더 빠른

[39:13] 반복 루프를 만들고 더 빠른 피드백을

[39:15] 받을 수 있죠. 이것이 바로 마법입니다.

[39:18] 코드 작성 비용은 확실히 떨어졌지만,

[39:19] 팀이 함께 이해하는 비용은

[39:21] 그대로입니다. 그게 여전히

[39:23] 병목지점이에요. 그렇지 않은 척

[39:25] 하지 맙시다. 완전히 동의합니다.

[39:27] 팀의 이해는 대부분의 경우에

[39:30] 엄청난 병목지점입니다. 여기서 제가

[39:32] 강조하고 싶은 추가 포인트는 이겁니다.

[39:35] 거대한 스펙이 있다고 해봅시다. 이

[39:38] 사각형이 스펙이라고 하죠. 그리고 이건

[39:41] 주로 제품 리드, 디자인 리드,

[39:44] 기술 리드가 함께 만든 것으로

[39:47] 여기 들어갈 모든 요소들을

[39:48] 구상한 겁니다. 관대하게 말해서, 아마

[39:52] 이 정도만이, 실제로

[39:55] 좋고 올바를 겁니다. 그리고 나머지,

[39:58] 이 상자에 남아있는 부분은

[40:00] 버려야 할 쓰레기입니다.

[40:02] 저는 여기서 비율이 종종

[40:04] 훨씬 더 나쁘다고 주장합니다. 제가

[40:06] 스펙을 읽고, 전체 팀이

[40:08] 스펙에 동의했는데, 실제로 우리가

[40:10] 배포한 것은 스펙과 전혀 달랐던

[40:12] 경우가 얼마나 많은지 모릅니다.

[40:14] 스펙이 나빴고 많은

[40:16] 잘못된 가정이 있었기 때문이죠.

[40:17] 스펙 대신에 프로토타입을 만들고,

[40:20] 이런 거대한 것 대신

[40:21] 프로토타입이 이렇게

[40:24] 작은 것이라면 어떨까요? 그리고 비율이

[40:26] 훨씬 더 나쁠 수도 있어요. 프로토타입이

[40:28] 좋은 것보다 나쁜 것이 더 많을 수도 있죠. 하지만

[40:30] 여기서 좋은 통찰을 얻습니다. 아마

[40:32] 전체 프로토타입이 나빠서 이

[40:34] 아이디어 자체가 처음부터 나빴다는

[40:36] 통찰을 얻을 수도 있어요. 이 부분을

[40:38] 만드는 데 훨씬 적은 시간이 걸립니다.

[40:40] 그리고 훨씬 간단한 이걸

[40:42] 만들면 소통도 더 쉬워집니다.

[40:43] 2-3명이 작은 프로토타입에 대해

[40:45] 소통하는 것이 20명 이상이

[40:47] 거대한 스펙에 대해 이야기하는 것보다

[40:49] 훨씬 쉽거든요. 그리고

[40:50] 뭔가를 배우고 발견할

[40:52] 가능성이 이런 방식으로 시작할 때

[40:55] 훨씬 높아집니다. 아마 그 다음에

[40:57] 두 번째 프로토타입을 만들어서

[40:58] 좋은 부분들을 가져와 확장할 겁니다.

[41:01] 그러면 좋은 부분이 더 많아지고

[41:02] 조금 더 큰 것을 만들지만

[41:04] 나쁜 부분도 더 많아집니다. 그리고

[41:07] 좋은 부분들로 또 다른

[41:08] 프로토타입을 만드는데, 좋은 부분들이

[41:10] 더 작아졌어요. 잘못된 가정 때문에

[41:11] 망가졌고 이제 나쁜 부분이

[41:13] 엄청 많아졌습니다. 하지만

[41:14] 나쁜 부분들이 좋은 이유는 많은

[41:16] 교훈을 얻었기 때문입니다. 이제

[41:18] 이 모든 나쁜 부분들을 영원히

[41:19] 버리고 다시는 하지 않을 수 있어요.

[41:21] 그리고 다음 버전은 두 배로

[41:23] 커지고, 훨씬 더 좋아지며, 여전히

[41:25] 거친 부분이 있지만 그게 무엇인지

[41:27] 정확히 알고 있습니다. 그리고 얼마 전에

[41:28] 배운 많은 교훈들이 여기에

[41:30] 적용됩니다. 그런 것들을

[41:32] 다듬어내면 여러분이 만드는

[41:34] 제품이 다른 스펙이 제안했던 것보다

[41:36] 훨씬 작다는 것을 알게 됩니다. 그리고

[41:38] 채팅에서 사람들이 말하듯이, 이것은 또한

[41:40] Jira 티켓에 시달리는 건 재미없어요.

[41:42] 그렇다고 말하면 믿지 않을 거예요.

[41:44] 새로운 걸 시도하고, 새로운 솔루션으로 놀아보고,

[41:46] 팀과 함께 반복 작업하면서

[41:48] 실제 문제를 해결하려고 시도하는 게

[41:49] 훨씬 재미있어요.

[41:51] 그리고 이런 툴들이 각각의 단계를

[41:53] 예전보다 훨씬 저렴하게 만들어 줘요.

[41:55] 만약 팀이 이걸 만드는데 3개월이 걸리고

[41:57] 저걸 만드는데 9개월이 걸린다면

[42:00] 망설이는 걸 이해할 수 있어요.

[42:01] 하지만 20명의 개발자가 9개월 걸려서 이걸 만드는데

[42:04] 개발자 1명이 3일 만에 이걸 만들 수 있다면

[42:07] 아직도 이런 식으로 처음부터 만들고 있다면 정말 바보죠

[42:10] 제품이 실제로 필요한지도 모르는 상황에서 말이에요.

[42:12] 정말 멍청한 일이에요.

[42:13] 그래서 저는 이런 AI 도구들에 흥미가 있어요.

[42:15] 제가 생각하는 방식은

[42:17] 갑자기 훨씬 더 많은 팀들이

[42:19] 프로토타입을 훨씬 빠르게 만들고

[42:21] 집중적으로 반복 작업을 해서

[42:24] 진짜 해결하고 싶은 문제를 찾은 다음

[42:26] 전통적인 방식으로

[42:28] 제품 리드나 PM, 수석 엔지니어들에게 넘겨서

[42:31] 제대로 스펙을 짜고 올바른 방식으로 개발하는 거예요.

[42:34] 하지만 그 과정에서 훨씬 적은 부분들만 있다면

[42:36] 훨씬 더 잘 소통할 수 있고

[42:39] 모든 사람이 훨씬 더 잘 이해할 수 있어요.

[42:41] 3명이 이걸 이해하려고 하는 것이

[42:43] 20명에서 30명이 이걸 이해하려고 하는 것보다

[42:45] 항상 더 좋은 경험이 될 거예요.

[42:47] 이건 꽤 명백한 일이라고 생각해요.

[42:49] 이 글을 써준 Pedro에게 큰 박수를 보냅니다.

[42:51] 정말 훌륭했고

[42:52] 한동안 제가 가장 좋아했던 토론 중 하나를 영감을 줬어요.

[42:54] 이걸 공유해 주셔서 감사합니다.

[42:56] 정말 고마워요

[42:57] 그리고 이것에 대해 반응할 수 있게 해주셔서도 감사해요.

[42:59] 정말 좋았습니다.

[43:00] 아직 안 봤다면 그의 블로그를 확인해 보시고

[43:01] 트위터에서 팔로우도 해주세요.

[43:03] 이 토론을 봐주신 모든 분들 감사합니다.

[43:04] 정말 재미있었어요.

[43:05] 확실히 털어놓고 싶은 것들이 있었거든요.

[43:07] 여러분들이 어떻게 생각하시는지 궁금해요.

[43:08] 이게 좋은 내용이었나요?

[43:10] 잘못된 방향이었나요?

[43:11] 프로토타입과 더 전통적인

[43:12] 프로덕션용 개발 사이의 구분이

[43:14] 이상하다고 생각하시나요?

[43:16] 여러분의 생각을 알려주세요.