# AI 시대의 개발자 법칙

> Clean Markdown view of GeekNews topic #23943. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=23943](https://news.hada.io/topic?id=23943)
- GeekNews Markdown: [https://news.hada.io/topic/23943.md](https://news.hada.io/topic/23943.md)
- Type: news
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-10-27T11:16:01+09:00
- Updated: 2025-10-27T11:16:01+09:00
- Original source: [bvp.com](https://www.bvp.com/atlas/developer-laws-in-the-ai-era)
- Points: 28
- Comments: 1

## Summary

AI가 단순한 도구를 넘어 **개발 과정의 동료이자 사용자**로 자리 잡으며, 개발자 플랫폼의 규칙이 다시 쓰이고 있습니다. Anthropic과 Cursor 같은 리더들이 제시한 새 **8대 법칙**은 이제 **에이전트 경험(AX)** 과 **개발자 경험(DX)** 의 균형, 모델 친화적 문서화, 가격 전략, 플랫폼 엔지니어의 역할 변화까지 포괄합니다. 특히 ‘에이전틱 개발’ 시대에는 코드 작성보다 **검증·거버넌스·지속적 진화**가 경쟁력의 핵심으로 부상하며, 플랫폼의 방어 가능성은 속도와 통제력에서 결정됩니다. AI와 함께 일하는 개발자의 정의가 확장되는 지금, 이 글은 “플랫폼을 어떻게 설계해야 AI와 함께 성장할 수 있을까”라는 질문에 가장 현실적인 힌트를 줍니다.

## Topic Body

- AI 에이전트와 인간 개발자가 **동시에 사용자이자 협력자**가 되는 새로운 소프트웨어 환경을 반영해, 12년 전 발표한 개발자 플랫폼 법칙을 **AI 패러다임에 맞춰 재정립**  
- 2025년 현재는 **에이전틱 개발(agentic development)** 패러다임이 등장하며, AI 에이전트가 개발자와 협업해 소프트웨어를 설계·구축·배포·유지보수하는 환경으로 전환  
- Anthropic, Cursor, Port 등 **주요 개발자 플랫폼 리더들의 직접적인 인사이트**를 바탕으로 8가지 핵심 법칙을 도출  
- 에이전트 경험(AX)과 개발자 경험(DX)의 균형, 모델 친화적 문서화, 새로운 가격 전략, 플랫폼 엔지니어의 역할 변화 등 **개발 도구 시장의 구조적 변화**를 다룸  
- AI가 주도하는 소프트웨어 혁신 물결 속에서 개발자 플랫폼이 새로운 인프라의 선두를 이끌며, **지속적 진화와 플랫폼 통제력이 방어 가능성의 핵심**으로 부상  
  
---  
  
### 배경: 개발자 법칙의 진화  
  
- Bessemer Venture Partners가 2013년 발표한 최초의 "개발자 플랫폼 8대 법칙"과 2019년 개정판은 DevOps, 오픈소스, 클라우드 네이티브 아키텍처, API 우선 생태계의 부상을 추적  
- 2025년 현재 **에이전틱 개발**이라는 새로운 패러다임이 등장  
  - AI 에이전트가 개발자와 협업해 소프트웨어를 대규모로 설계, 구축, 배포, 유지보수  
- Anthropic, Cursor, Port, Fal AI, Fern, Render, Appwrite, Netlify, Recall, Vapi, Resolve AI, Graphite, Marimo, Resend 등 업계 리더들의 직접적인 인사이트 반영  
  
### AI 개발 플랫폼의 8대 법칙  
  
#### 법칙 #1: 에이전트 경험(AX)이 개발자 경험(DX)만큼 중요  
  
- **에이전트 경험(AX)과 개발자 경험(DX) 모두에 동등한 관심** 필요  
  - DX가 AX를 직접 보완하고 향상시킴  
  - 문서의 포괄성, API 표면 영역, 이해하기 쉬운 스키마 등이 인간과 에이전트 모두에게 유용  
  - 지난 5~10년간 OpenAPI 명세, REST API, SDK에 투자한 결과가 양쪽 모두에게 도움  
- **Resend CEO의 증언**: DX 개선을 위한 온보딩 플로우 최적화가 에이전트의 Resend 사용에도 큰 차이를 만듦  
- ### 인간과 에이전트를 위한 차별화된 기능  
  - 인간 개발자는 모호한 문서를 해석하고 일관성 없는 API에 적응 가능  
  - **에이전트는 구조화되고 예측 가능한 인터페이스 필요**  
    - 포괄적인 오류 처리가 포함된 OpenAPI 스키마  
    - 다단계 워크플로우를 위한 세션 지속성  
    - WebSocket 스트림과 같은 실시간 피드백 메커니즘  
    - Netlify의 배포 에이전트는 전체 CI/CD 파이프라인에서 상태를 유지하며 즉각적인 빌드 피드백 제공  
- ### Model Context Protocol(MCP)의 등장  
  - MCP는 개발자 도구가 사용자를 서비스하는 방식의 **근본적 변화** 표현  
  - 많은 기업이 Prefect의 FastMCP 같은 솔루션으로 자체 MCP 서버 호스팅  
    - 개발자들이 Cursor와 Claude Code에서 작업하기 때문  
    - IDE 내에서 개발자가 에이전트를 강화해 플랫폼의 라이브 데이터에 직접 접근하고 작업 수행  
- ### 대시보드와 API의 통합  
  - 현재 인간은 정보 수집을 위한 중앙 창으로 대시보드에 직접 로그인  
  - **Recall 같은 팀은 모든 대시보드 기능을 API로 접근 가능하게 만들어** 에이전트도 문제 해결에 기여  
  - 에이전트의 컨텍스트 전환(버전 관리, 통합, API 사용, 프로덕션 배포) 감소 또는 제거에 대한 미해결 질문  
    - MCP 서버가 에이전트가 대시보드나 CLI로 컨텍스트 전환 없이 실시간 정보를 가져오고 명령 실행 가능하게 함  
  
#### 법칙 #2: 문서화는 모델과 인간 모두를 서비스해야 함  
- 엔지니어링 팀 내 문서는 종종 선의를 가지고 작성되지만 제대로 유지보수되지 않음  
  - 실시간 변경사항을 반영하지 못하고 오래된 가이드 제공  
  - 개발자는 불완전하거나 불완벽한 문서에 대해 일정 수준의 관용 발휘  
- ### LLM을 위한 문서화의 특수성  
  - LLM에게는 탐색, 광고, JavaScript가 포함된 복잡한 HTML 페이지를 **LLM 친화적인 평문으로 변환하는 것이 어렵고 부정확**  
  - **에이전트는 단일하고 접근 가능한 위치에 모인 간결하고 전문가 수준의 정보로부터 큰 이익**  
    - 개발 환경 같은 사용 사례에서 특히 중요 (LLM이 프로그래밍 문서와 API에 빠르게 접근 필요)  
  - LLM은 **최신의 구조화된 API 참조**와 인간 및 에이전트 작업을 추적하는 감사 로그 필요  
    - 정보 아키텍처에 대한 근본적 재고 요구  
- ### Generative Engine Optimization(GEO)  
  - SEO가 검색 엔진의 검색 가능성을 보장하듯, **GEO는 모델이 문서 내에서 정확한 답변을 빠르게 파싱하고 표시**할 수 있도록 보장  
  - 개발자가 컨텍스트 전환 검색으로 중단되지 않고 흐름을 유지하도록 지원  
- ### 이중 목적 기술 문서  
  - 코딩 에이전트의 확산으로 **기술 문서는 이중 목적 제품 자산**이 됨  
  - 에이전트와 인간 개발자 청중 모두를 효과적으로 서비스  
    - 에이전트를 위한 적절한 버전 관리, 변경 관리, 검색 가능성  
    - 인간 개발자에게도 유용하게 유지  
  - **Fern 공동 창업자의 관찰**: "개발자는 세련된 문서 사이트를 원하고, 에이전트는 파싱할 깨끗한 마크다운 필요. 팀들은 문서를 먼저 마크다운으로 작성한 후 개발자 친화적 웹사이트와 llms.txt 같은 기계 판독 가능 파일로 게시하는 docs-as-code 접근법으로 전환 중"  
  
#### 법칙 #3: 가격 전략은 온보딩 마찰 감소에 집중  
  
- 가격 책정은 **비용 구조와 가치 전달 모두를 고려**해야 함  
- AI 네이티브 애플리케이션의 경우 특히 중요  
  - 전통적 SaaS에서 한계 사용자 서비스 비용이 0에서 추론 비용으로 인한 의미 있는 항목으로 전환  
- ### 개발자 대상 기업들이 실험 중인 3가지 가격 책정 경로  
  - 1\. **사용량 기반 가격과 대규모 고객 계정 확장**  
    - 제품의 놀라운 유용성으로 인한 확장  
    - 모든 플랫폼이 AI와 재통합되고 있으며, 모든 물결마다 그랬듯 개발자가 선두를 이끌며 인프라와 도구 지출 주도  
    - 사용량과 수익화가 고객과 함께 성장 (현재 가장 일반적인 가격 패턴)  
  - 2\. **기업의 지출 예측 가능성 선호**  
    - 벤더가 AI를 추가 기능이 아닌 **핵심 좌석 기반 제품 경험의 일부**로 통합  
    - 종종 사용량 기반 초과 요금과 함께 제공  
  - 3\. **결과 기반 가격 또는 활동 번들링**  
    - 활동을 의미 있는 비즈니스 프로세스로 번들링하고 완료된 워크플로우 기반 청구  
- ### 업셀 트리거의 차이  
  - 초기 데이터는 전통적 개발자와 바이브 코더 간 **업셀 트리거가 다를 수 있음**을 시사  
  - 구축과 배송의 제약 요소가 소프트웨어 제작자가 기꺼이 지불할 의향에 영향  
    - 예: 바이브 코더 vs 전통적 개발자를 위한 CI/CD 기능  
- ### 온보딩 마찰 감소는 여전히 최우선  
  - 어떤 경로를 선택하든 모든 플랫폼은 여전히 **온보딩 마찰 감소에 가장 집중**  
    - 매력적인 무료 티어 유지  
    - 훌륭한 문서  
    - 강력한 개발자 커뮤니티 (확장 가능하게 온보딩 마찰 감소)  
  - **Resolve CEO 의견**: "낡은 SaaS 모델을 새로운 제품에 강요하지 않음. 가치는 결과에 매핑되어야... 에이전트가 실제 엔지니어링 작업을 수행하고 시스템이 다운타임 감소, 시스템 안정성 유지, 배송 가속화 같은 측정 가능한 가치를 제공할 때 가격이 합리적"  
  
#### 법칙 #4: AI 개발자 도구 지출이 전통적 예산을 벗어남  
- **전용 AI 예산**을 만드는 기업이 늘어나며 새로운 지출 카테고리 등장  
  - 초기에는 CIO를 통해 조직의 모든 부분으로 이동  
- 많은 기업이 이미 **AI 도구 지출과 추가 엔지니어 채용 사이에서 트레이드오프** 진행  
  - 인력 추가 대신 에이전트로 목표 달성 가능 여부를 지속적으로 질문  
- ### 주니어 엔지니어의 보완 및 대체  
  - 역사적으로 서비스 중심 산업에 판매하는 다른 수직 소프트웨어 기업에서 관찰한 것처럼  
  - **코딩 에이전트로의 위임과 워크플로우가 주니어 엔지니어를 보완하고 대체하기 시작**  
  - 생산성 향상과 비용 절감뿐 아니라 **기술 극대화에 초점**  
  - 개인이 완전히 새로운 능력을 갖춰 다른 사람에 대한 의존도 감소  
- ### 다중 이해관계자 구매 환경  
  - 예산 출처가 더 복잡한 다중 이해관계자 구매 환경 드러냄  
  - **개발자 주도 GTM이 시끄러운 경쟁 환경에서 여전히 왕**  
  - 기업 내에서 CIO, 엔지니어링 리더, 제품 팀, 개인 개발자 모두가 **비결정적 시스템 통합에 필요한 가드레일 수준** 때문에 이전 세대 개발자 도구와 다르게 구매 결정에 영향  
- ### 성공 지표의 변화  
  - 즉각적인 가치와 마법 같은 경험에 대한 **소비자 수준 기대로 전환**  
  - 전통적 개발자 도구 생산성 지표가 결과 기반 측정으로 보완  
    - 아이디어에서 작동 프로토타입까지의 시간  
    - 전체 개발 주기 감소  
    - 비즈니스 사용자 생산성 향상  
  - Cursor의 분석은 **세밀한 지표 추적**  
    - 표시된 제안 수, 수락된 제안, AI 지원으로 생성된 코드 라인, AI 생성 제안의 수락률  
  
#### 법칙 #5: 개발자의 정의가 극적으로 확대됨  
- AI가 더 많은 사람들에게 소프트웨어 제작을 접근 가능하게 만들며 **"개발자"의 정의를 근본적으로 확장**  
  - Zapier에 대한 10년 전 시드 투자부터 이 트렌드 목격  
- **바이브 코딩과 AI 지원 개발의 광범위한 확산**으로 코드를 직접 작성하거나 신경 쓰지 않고 맞춤형 소프트웨어를 만드는 새로운 빌더 카테고리 생성  
- ### 새로운 사용자 코호트의 특성  
  - Lovable, Bolt, Create, v0 같은 플랫폼이 전통적으로 기술 사용자만 서비스하던 개발자 플랫폼으로 사용자 유도  
  - 이 코호트는 **질문 유형으로 쉽게 식별 가능**  
    - 문제 해결 능력, 오류 코드 읽기, 데이터베이스 서버와 웹 서버 분리, 로드 밸런서 등의 의미 이해 능력이 아직 없음  
  - 이러한 사용자는 프로토타이핑과 프로덕션 사이 단계에서 막히는 경우가 많음  
    - 기업들은 이 사용량을 **양질의 수익보다는 효율적인 마케팅으로 분류**  
    - 개발자가 더 높은 추상화 수준에서 작업하기 시작하면서 시간이 지남에 따라 변화할 것으로 예상  
- ### 비기술 팀원의 역할 확대  
  - 비기술 팀원이 코딩 및 기업 주요 제품 외부 엔지니어링 작업을 위해 **귀중한 개발자 시간을 확보하는 데 도움**  
  - 올바른 도구가 주어지면:  
    - AE가 기술 제품을 위한 맞춤형 데모 제작  
    - 마케터가 X에서 공유할 샘플 앱 제작  
    - 콘텐츠 마케터가 기술 블로그 게시물 작성  
- ### 가치 있는 기술의 재정의  
  - **도메인 전문성과 고객 커뮤니케이션이 모든 역할에서 코딩 능력보다 중요**  
  - **시스템 사고**가 작업이 저수준 구현에서 오케스트레이션 및 전략으로 진화하면서 더욱 중요  
  - 복잡한 조각들이 어떻게 연결되는지 이해하고, 자동화를 신뢰할 곳을 알고, 인간 개입이 필수적인 시기를 인식하는 개인과 팀이 성공  
  - 소프트웨어 배송이 그 어느 때보다 빠르고 쉬워졌지만, **개발자의 정의 변화는 지속 가능한 비즈니스의 기본 원칙의 중요성을 복원**  
  - **Netlify CEO**: "현재 1,700만 명의 JavaScript 개발자가 있는데, 이들은 전통적 개발자입니다. 하지만 향후 10년 안에 그 수가 1억 명에 이를 것으로 예상"  
  
#### 법칙 #6: 강력한 네트워크 효과가 조기 생태계 포지셔닝을 장려  
- 전통적 개발자 기업은 오픈소스와 커뮤니티 기여, 통합 및 플러그인을 통해 네트워크 효과 육성  
- 이제 **에이전틱 개발의 확산으로 네트워크 효과가 재정의되고 재상상**됨  
- ### 에이전트 간 네트워크 효과  
  - **AI 에이전트가 다른 에이전트와 통신하고 구성할 수 있을 때 더 유용**해지는 에이전트 간 네트워크 효과 출현  
  - 예: 회의를 예약할 수 있는 스케줄링 AI 에이전트가 다른 사람의 여행 에이전트, 경비 관리 에이전트, 캘린더 에이전트와 통신할 수 있을 때 더 강력  
  - MCP 같은 프로토콜을 통해 가능  
- ### 데이터 네트워크 효과의 증폭  
  - **컨텍스트로 인해 데이터 네트워크 효과가 증폭**  
  - AI 에이전트가 가진 컨텍스트가 많을수록 원하는 작업을 더 많이 완료 가능  
  - 해당 컨텍스트를 보유한 제품의 가치 증가  
  - **Linear의 Product Intelligence** 예시  
    - 수천 개 엔지니어링 팀이 실제로 작동하는 방식에 대한 수년간 축적된 데이터 보유  
    - 작업 할당 제안, 이슈 분류, 제품 운영 간소화 가능  
- ### 통합 락인 효과의 약화  
  - 통합 락인 효과가 전통적으로 전환 비용을 생성했던 곳에서 네트워크 효과 약화  
  - **Recall CEO David Gu**: "이제 서로 다른 API 간 전환이 그 어느 때보다 쉬움. 인간이 통합 코드를 수동으로 작성할 필요 없이 AI 에이전트가 도움을 주기 때문"  
  - **MCP는 AI 에이전트가 자동으로 도구를 발견하고 통합할 수 있게 하여 락인을 더욱 감소**  
  - LLM은 일반적으로 평가 프로세스 중 옵션을 연구하고 종합하는 것을 누구에게나 더 쉽게 만듦  
- ### AI 주도 추천 환경에서의 역설  
  - AI가 개발자 도구 추천 결정을 주도하는 생태계에서 **인간의 주관적 피드백 역할이 역설을 제시**  
  - AI 에이전트는 사용 편의성 같은 주관적 선호도를 무시하고 성능과 지연시간 같은 객관적 성능 지표에만 집중할 수 있음  
  - 반면 AI 에이전트는 시간이 지남에 따라 학습하면서 주관적 인간 피드백에 더 의존할 수 있음  
  - 이 역설은 **최고 품질 제품이 어떤 경우든 이익**을 본다는 것을 의미  
    - 개발자 주도 성장, 제품 출시, 문서, 교육 콘텐츠, 컨퍼런스, 커뮤니티 포럼, 리뷰가 훨씬 더 중요  
    - **속도가 그 어느 때보다 중요하며 선점자 우위가 복리로 작용**  
- ### 리더들의 다양한 관점  
  - 이 법칙들은 여전히 WIP이며 기업 리더들이 다른 관점 제시  
  - **Vapi CTO Nikhil Gupta**: "AI는 비객관적 기반 네트워크 효과를 약화시키고 객관적 네트워크 효과를 강화. 예를 들어, 사람들은 Stripe의 API가 다른 것보다 사용하기 가장 쉽다고 생각할 수 있지만, AI 에이전트는 Stripe API와 Ayden API를 비교할 때 사용 편의성을 신경 쓰지 않을 것. 하지만 Stripe가 더 신뢰할 수 있다면 모든 AI 에이전트가 그것을 선택"  
  - **Resolve CEO Spiros Xanthos**: "에이전트 우선 GTM은 과대 광고가 아닌 증명에 관한 것. 고객 환경에 나타나 중요한 결과를 제공하면 채택이 자연스럽게 증가. 그것이 새로운 전도"  
  
#### 법칙 #7: 플랫폼 엔지니어가 자율 플로우 아키텍트로 진화  
- **플랫폼 엔지니어링의 역할이 소프트웨어 관리에서 자율 엔지니어링 플로우 생성으로 확장**  
- 플랫폼 엔지니어는 모든 기술 팀의 사용자 경험에 책임  
- 조직 내 중요성이 채용 시급성에 점점 더 반영  
- ### 책임 영역의 변화  
  - 플랫폼 엔지니어는 이제 다음 기술 필요  
    - 명확한 인간 감독 단계로 에이전틱 플로우 설계  
    - 에이전트가 잘못된 작업을 수행하는 위험을 관리하기 위한 강력한 가드레일 시행  
    - 가동 시간과 신뢰성을 넘어 시스템 및 정보 아키텍처 소유  
  - 가장 복잡한 전략적 결정을 위한 **AI 제어 센터를 구축**하면서 에이전트가 일상적 작업 처리  
- ### 소프트웨어 엔지니어의 역할 전환  
  - **AI 에이전트가 더 많은 실제 코드 생성을 처리함에 따라 소프트웨어 엔지니어는 장인에서 자신의 시스템의 제품 소유자로 전환**  
  - 이 근본적 변화는 엔지니어가 구현 세부사항보다 **결과에 점점 더 관심**을 갖는다는 것을 의미  
- ### 새로운 워크플로우 요구사항  
  - **강력한 테스트 및 모니터링이 중요**해짐  
  - 문서는 코드 구조뿐 아니라 시스템 동작을 설명해야 함  
  - 코드 리뷰가 구문 검사에서 **비즈니스 로직 및 아키텍처 결정 검증으로 전환**  
- ### 조직적 함의  
  - 개별 생산성을 넘어 확장되는 함의  
    - 팀이 지식 전달을 위한 새로운 프로세스 필요  
    - 원래 구현 논리를 인간이 완전히 이해하지 못할 때 사고 대응이 더 어려워짐  
    - 생성된 코드가 인간이 읽을 수 없을 때 기술 부채가 다르게 축적  
  - 엔지니어가 자신의 코드의 작성자가 아닌 운영자가 될 때 **시스템 신뢰성을 유지하기 위해 관찰 가능성, 자동화된 테스트, 아키텍처 거버넌스에 막대한 투자** 필요  
- ### 검증 병목현상  
  - AI가 전례 없는 속도로 코드를 생성함에 따라 **주요 병목현상이 코드 작성에서 정확성 검증으로 전환**  
  - 개발 속도를 근본적으로 변화  
    - 팀이 몇 분 만에 수천 줄의 코드 생성 가능  
    - 의도대로 작동하고, 기존 시스템과 적절히 통합되며, 보안 및 성능 요구사항을 충족하는지 검증하는 데 훨씬 더 오래 걸림  
  - **더 나은 테스트 프레임워크, 실시간 검증 도구, 시각적 확인 시스템을 통해 검증 속도를 최적화하는 기업이 AI 지원 개발 주기에서 상당한 이점** 보유  
- ### Render CEO의 관점  
  - "플랫폼 관리에서 가장 중요한 지속적 변화는 **인프라 관리에서 개발자 워크플로우 최적화로의 전환**"  
  - 엔지니어링 팀은 이제 맞춤형 내부 개발 및 배포 플랫폼 구축 및 유지관리가 종종 핵심 비즈니스에서 리소스를 소진하는 차별화되지 않은 작업임을 인식  
  - Render 같은 관리형 플랫폼을 활용해 기본 인프라를 처리함으로써 플랫폼 엔지니어는 **더 높은 가치의 자동화에 집중** 가능  
  
#### 법칙 #8: 방어 가능성은 지속적 진화와 플랫폼 통제에 관한 것  
- 핵심적으로 **플랫폼이 된다는 것은 제3자가 함께 그리고 그 위에 구축할 수 있는 확장 가능한 인프라를 만드는 것**  
  - 더 많은 사용자가 기여하고 진정한 커뮤니티 사랑을 보일수록 더 가치 있어지는 생태계 활성화  
- ### SaaS 시대와의 연속성  
  - 이 개념은 SaaS 시대부터 일관되게 유지  
  - **AI 시대는 방어 가능성의 특정 기둥을 격상**  
- ### 주요 방어 가능성 요소  
  - 1\. **진입점 통제**  
    - GitHub의 코드 저장소 소유 또는 VS Code의 텍스트 편집 지배  
    - 확립된 사용자 행동 위에 기능을 확장할 **전략적 권리를 플랫폼에 부여**  
  - 2\. **데이터 우위**  
    - 독점적 제품 데이터세트와 경쟁자가 복제할 수 없는 기능을 가능하게 하는 **회사별 컨텍스트를 통해 나타남**  
- ### 가장 근본적인 변화: 지속적 진화  
  - **지속적 진화가 가장 중요**함  
  - 최고의 플랫폼은 **여러 AI 모델, 데이터 소스, 워크플로우를 적극적으로 조정해 자율적 행동** 수행  
    - 생태계로부터의 고유한 데이터를 보유하는 경향  
    - 에이전틱 및 고객 상호작용으로부터 실시간 피드백 루프를 위해 데이터를 빠르게 활용 가능  
- ### 속도의 중요성  
  - **속도가 핵심**이며, 추가 기능 제공과 전략 수립 측면 모두에서 중요  
  - 기업은 **SaaS 시대에 필요했던 것보다 훨씬 더 일찍 Act 2와 Act 3 비전을 고민**해야 함  
  - 이것이 어떻게 계속 진화하는지 보는 것에 기대  
- ### Port CEO의 관점  
  - "일을 수행하는 방식을 변경하는 첫 번째가 되는 것이 중요. 제품 관점에서는 **지속적으로 진화할 무언가를 구축하는 것**"  
  - "예를 들어 CRM 같은 플랫폼 - 누군가가 관리하고, 통제하고, 의견을 갖고, 핵심 빌딩 블록으로부터 반복"  
  
### 추가 권장 읽기 자료  
  
- [Software 3.0을 위한 개발자 도구 로드맵](https://www.bvp.com/atlas/roadmap-developer-tooling-for-software-3-0)  
- [why, try, buy, fly 방법으로 개발자 관계 플라이휠을 활성화하는 방법](https://www.bvp.com/atlas/how-to-activate-the-developer-relations-flywheel-with-the-why-try-buy-fly-method)  
- [엔지니어링 팀을 1명에서 50명 이상으로 확장하기](https://www.bvp.com/atlas/scaling-your-engineering-team-from-one-to-50-and-beyond)  
- [Research to Runtime](https://www.youtube.com/playlist?list=PLUG9J4vFAkeb52_uCYwKMVzBPQcSDmFC0)  
- [AI 기반 R&D—바이브코딩, 취향, 풀스택 디자인의 진화](https://www.bvp.com/atlas/ai-powered-rd-vibecoding-taste-and-the-evolution-of-full-stack-design)  
- [Bessemer의 AI 에이전트 자율성 척도—사용 사례 성숙도를 이해하는 새로운 방법](https://www.bvp.com/atlas/bessemers-ai-agent-autonomy-scale)  
- [B2B AI 앱 리더를 위한 이탈 방지를 위한 7가지 제품 전략](https://www.bvp.com/atlas/seven-product-strategies-to-prevent-churn-for-b2b-ai-app-leaders)  
- [Data Shift Right 시장을 주도하는 것은 무엇인가?](https://www.bvp.com/atlas/whats-driving-the-data-shift-right-market)  
- [개발자 플랫폼을 위한 8대 법칙 (2017)](https://www.bvp.com/atlas/eight-laws-for-developer-platforms)  
- [더 어렵고, 더 좋고, 더 빠르고, 더 강력한 새로운 개발자 법칙 (2019)](https://www.bvp.com/atlas/developer-laws-2019)

## Comments



### Comment 45527

- Author: progdesigner
- Created: 2025-10-28T08:52:37+09:00
- Points: 1

그래서 어떻게 해야 되는지는 아직 아무도 모름  
빠르게 대응하고 변화하는 것만이 생존 전략이 되는  
시대인 듯
