# AI 시대의 새로운 개발자 패턴들 > Clean Markdown view of GeekNews topic #21115. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=21115](https://news.hada.io/topic?id=21115) - GeekNews Markdown: [https://news.hada.io/topic/21115.md](https://news.hada.io/topic/21115.md) - Type: news - Author: [xguru](https://news.hada.io/@xguru) - Published: 2025-05-26T11:03:01+09:00 - Updated: 2025-05-26T11:03:01+09:00 - Original source: [a16z.com](https://a16z.com/nine-emerging-developer-patterns-for-the-ai-era/) - Points: 48 - Comments: 8 ## Summary 1. AI-Native Git: AI 에이전트를 위한 버전 관리의 재정의 2. Dashboards → Synthesis: 동적 AI 기반 인터페이스로의 진화 3. 문서는 도구, 인덱스, 인터랙티브 지식 베이스의 결합체로 진화 중 4. 템플릿에서 생성으로: create-react-app을 대체하는 바이브 코딩 5. .env를 넘어서: 에이전트 중심 환경에서의 시크릿 관리 6. 접근성을 보편적 인터페이스로: LLM의 시각에서 본 앱 7. 비동기 에이전트 작업의 부상 8. MCP: 범용 표준에 한 걸음 더 가까워진 Model Context Protocol 9. 추상화된 프리미티브: 모든 AI 에이전트가 필요로 하는 인증, 결제, 저장소 ## Topic Body - AI를 단순한 도구가 아닌 **기반 기술**로 다루는 개발 문화가 형성되고 있음 - 기존의 버전 관리, 대시보드, 템플릿, 문서화, 시크릿 관리 방식등이 AI 시대에 맞춰 변화 중 - Git은 더 이상 코드의 라인별 변경보다는 **프롬프트와 테스트 결과 중심의 상태 관리 방식**으로 재해석되고 있음 - 에이전트는 **코드 작성자이자 소비자**가 되어, 도구 자체를 다시 설계해야 할 필요성이 커짐 - **대시보드와 UI는 자연어 기반 인터페이스**로 전환되며, 사람과 AI 에이전트가 함께 사용하는 형태로 발전 중 - **문서화는 사람과 AI 모두를 위한 지식 베이스로 변화**, 에이전트가 이해할 수 있는 형식으로 재구성됨 ### 1. AI-Native Git: AI 에이전트를 위한 버전 관리의 재정의 - Git은 원래 사람이 직접 작성한 코드의 **라인 단위 변경 이력**을 추적하기 위해 설계됨 - 하지만 AI가 자동으로 코드의 많은 부분을 생성·수정하는 상황에서는 이러한 **세밀한 추적이 덜 중요**해짐 - 개발자는 더 이상 변경 내용보다 **결과 동작의 적절성**(테스트 통과 여부, 정상 작동 등)에 주목하게 됨 - SHA는 변경이 있었음을 알려주지만, **왜 변경되었는지** 또는 **변경이 유효한지**에 대한 정보는 담고 있지 않음 - 특히 대규모 변경이나 자동 생성 코드의 경우, 개발자가 일일이 diff를 검토하지 않음 - **AI-first 워크플로우**에서는 다음 요소의 조합이 더 유용한 단위가 됨 - **프롬프트(prompt)**: 코드 생성을 유도한 입력 - **테스트(test)**: 기대 동작 검증을 위한 테스트 - **명세(spec)** 및 **제약조건(constraints)** 등 설계 상의 요구 - 이들을 하나의 **버전 가능한 번들(bundle)** 로 간주하여 관리하고 추적 - 이를 한 단계 더 발전시켜 보면, Agent-Driven 워크폴로우에서는 Source of Truth가 프롬프트, 데이터 스키마, API 컨트랙트 및 아키텍처적 의도(intent)를 향해서 Upstream으로 이동할 수 있음 - 결과적으로 **코드는 컴파일된 산출물처럼 간주**되며, 소스가 아닌 이 입력들의 결과(byproduct)로 다뤄짐 - Git은 코드 작업 공간(workspace)이 아닌, **아티팩트 로그(artifact log)** 로 작동 - 누가 어떤 모델로 어떤 프롬프트를 사용해 코드를 만들었는지 - 어떤 테스트가 통과되었는지 - 어느 부분이 사람이 검토해야 하는지 등의 **메타데이터**를 함께 저장 - 변경 이력에는 **프롬프트와 목적, 관련 테스트, 생성한 모델 정보** 등을 포함 - Diamond 같은 **AI 리뷰어 도구**와의 연계로 자동화된 리뷰 흐름 가능 - 에이전트가 생성한 코드와 사람이 관리하는 보호 구역을 구분하여 다룰 수 있는 구조등 더욱 풍부한 메타 데이터를 계층화 - AI-Native Git 워크플로우를 예상해보면 - 프롬프트와 그 기반한 변경 흐름, 테스트 결과, 동작한 에이전트 정보 및 번들 정보가 함께 보이는 새로운 Git 대시보드 형태가 나타날 수 있을 것 ### 2. Dashboards → Synthesis: 동적 AI 기반 인터페이스로의 진화 - 수년간 대시보드는 관측 시스템, 분석 도구, 클라우드 콘솔(AWS 등)과 같은 복잡한 시스템과 상호작용하는 **주요 인터페이스** 역할을 해왔음 - 그러나 지나치게 많은 조작 요소, 차트, 탭 등으로 인해 **UX 과부하**가 발생했고, 정보 탐색과 액션 사이에서 사용자가 길을 잃기 쉬웠음 - 특히 비전문가나 여러 팀이 협업하는 상황에서, 이러한 대시보드는 **위협적이고 비효율적인 도구**로 인식될 수 있음 - 사용자는 자신이 이루고 싶은 목적은 알지만, **어디를 찾아야 할지, 어떤 필터를 적용해야 할지 모르는 경우가 많음** - 최신 세대의 AI 모델은 이러한 문제를 해결할 가능성을 제시함 - **대시보드를 고정된 캔버스가 아닌, 탐색과 상호작용이 가능한 공간**으로 재해석할 수 있음 - LLM은 다음과 같은 방식으로 사용자를 지원할 수 있음: - “이 API의 속도 제한 설정은 어디서 바꾸나요?”와 같은 **제어 위치 탐색** - “지난 24시간 동안 staging 환경의 모든 서비스에서 발생한 에러 트렌드를 요약해줘”와 같은 **데이터 통합 요약** - “내 비즈니스 상황을 바탕으로 이번 분기에 주목해야 할 지표를 추천해줘”와 같은 **숨겨진 인사이트 제안** - 현재 이미 [Assistant UI](https://www.assistant-ui.com/docs/copilots/make-assistant-tool)와 같은 기술은 에이전트가 React 컴포넌트를 도구처럼 활용할 수 있도록 지원함 - 콘텐츠가 동적이고 개인화된 것처럼, **UI 자체도 사용자 의도에 따라 재구성되고 대화형으로 진화 중** - 정적인 대시보드는 곧 시대에 뒤떨어진 것으로 인식될 수 있음 - 예시: - 사용자가 “지난 주말 유럽에서 발생한 이상 현상을 보여줘”라고 말하면, **필터를 수동 조작하지 않고도 요약된 로그와 트렌드가 자동 제공됨** - “왜 지난주에 NPS 점수가 떨어졌지?”라는 질문에 대해, AI가 **설문 감정 분석, 제품 배포 내역과의 상관관계 분석, 진단 요약**까지 제시함 - **더 넓은 관점에서, 에이전트가 소프트웨어 소비자가 된다면 ‘대시보드’라는 개념 자체도 재설계가 필요함** - 예를 들어, 대시보드는 [Agent Experience](https://agentexperience.ax/)에 최적화된 뷰를 렌더링할 수 있음 - 시스템 상태를 인식하고, 의사결정하며, 행동할 수 있도록 구조화되고 **프로그램적으로 접근 가능한 인터페이스** 제공 - 결과적으로 **인간 사용자용 UI와 에이전트용 UI가 함께 존재하는 이중 인터페이스 구조**가 생겨날 수 있음 - 두 UI는 동일한 상태를 공유하지만, **소비 방식에 따라 구성 방식이 다름** - 에이전트는 기존의 알림, 크론잡, 조건 기반 자동화의 역할을 대신하면서도, **훨씬 더 많은 문맥과 유연성을 갖춘 실행자**가 됨 - 예시: - 기존: `if error rate > threshold then send alert` - 에이전트 기반: “에러율이 상승 중입니다. 원인은 이 서비스이며, 영향을 받은 컴포넌트와 권장 조치는 다음과 같습니다” - 이처럼 대시보드는 단순히 관측하는 장소가 아니라, **사람과 AI가 협업하고 통합하며 행동을 수행하는 공간**으로 재정의됨 ### 3. 문서는 도구, 인덱스, 인터랙티브 지식 베이스의 결합체로 진화 중 - 개발자의 문서 활용 방식이 변화하고 있음 - 과거에는 목차를 따라 읽거나 위에서부터 스펙을 읽는 방식이었지만, 이제는 **“질문을 먼저 던지는 방식”** 이 일반화됨 - “이 스펙을 공부해야지”보다는 “**내가 원하는 방식으로 정보를 재구성해줘**”라는 사고 전환이 나타나고 있음 - 이러한 변화는 문서의 형태에도 영향을 주며, **정적인 HTML이나 마크다운이 아닌**, 인덱스, 임베딩, 도구 인식 에이전트가 뒷받침하는 **인터랙티브 지식 시스템**으로 진화 중 - 이에 따라 [Mintlify](https://mintlify.com/) 같은 도구들이 등장하고 있음 - Mintlify는 문서를 **의미 기반으로 검색 가능한 데이터베이스**로 구성할 뿐 아니라, **다양한 플랫폼에서 에이전트의 컨텍스트 소스로 활용됨** - 예: AI IDE, VS Code 확장, 터미널 에이전트 등에서 Mintlify 문서가 **실시간 참고 자료**로 사용됨 - 이유는 코드 생성 에이전트가 **최신 문서를 학습 기반 컨텍스트로 활용**하기 때문임 - **이로 인해 문서의 목적 자체가 변화하고 있음** - 문서는 단순히 인간 독자를 위한 정보 전달이 아니라, 이제는 **에이전트 소비자를 위한 구조**로 설계되어야 함 - 새로운 다이내믹에서, 문서는 **AI 에이전트를 위한 사용 지침서** 역할을 하게 됨 - 이는 단순한 콘텐츠 노출이 아니라, **시스템을 어떻게 올바르게 활용할 수 있는지를 설명하는 형식**임 ### 4. 템플릿에서 생성으로: create-react-app을 대체하는 바이브 코딩 - 과거에는 프로젝트를 시작하려면 `create-react-app`, `next init`, `rails new` 같은 **정적 템플릿**을 선택하는 것이 일반적이었음 - 이런 템플릿은 일관된 앱 구조를 제공하지만, **개발자의 의도나 스택에 맞춘 커스터마이징이 어려웠고**, 프레임워크의 기본값에 따라야 했음 - 그 결과, 기본 설정에서 벗어나려면 **많은 수작업 리팩터링**이 필요했음 - 이제 이러한 흐름이 **Replit, Same.dev, Loveable, Chef by Convex, Bolt** 같은 **text-to-app 플랫폼**과 **Cursor 같은 AI IDE**의 등장으로 바뀌고 있음 - 개발자는 예를 들어 “Supabase, Clerk, Stripe가 포함된 TypeScript API 서버”라고 설명하면, **AI가 맞춤형 프로젝트를 몇 초 안에 자동 구성** - 생성된 스타터는 일반적인 템플릿이 아니라, **개발자의 의도와 스택에 최적화된 구조**로 만들어짐 - 이 변화는 생태계의 배포 구조도 바꾸고 있음 - 과거처럼 몇 개의 프레임워크가 생태계의 중심을 차지하는 것이 아니라, **다양한 도구와 아키텍처가 조합된 맞춤형 생성 흐름**이 확산되고 있음 - 핵심은 **프레임워크를 고르는 것보다 ‘무엇을 만들고 싶은가’를 설명하는 것**으로 바뀜 - 어떤 개발자는 Next.js와 tRPC 조합, 다른 개발자는 Vite와 React를 선택해도, **각각 바로 실행 가능한 프로젝트로 생성 가능** - 물론 표준 스택이 가지는 장점도 있음: - 팀 생산성 향상, 온보딩 효율, 디버깅 용이성 등 - 하지만 **프레임워크 간 리팩터링은 단순한 기술 문제가 아니라, 제품·인프라·조직 역량과 얽혀 있음** - 변곡점은 바로 **프레임워크 전환 비용이 낮아졌다는 점** - AI 에이전트가 프로젝트의 의도를 이해하고 **대규모 리팩터링을 반자동으로 수행**할 수 있게 됨 - 이로 인해 실험이 쉬워지고, **초기 단계에서 다양한 스택을 시도하거나 되돌릴 수 있는 여지**가 생김 - 결과적으로, **프레임워크 선택은 가역적(decision reversible)** 이 되어감 - 예: Next.js로 시작했다가 Remix + Vite로 변경하고, 에이전트가 전체 리팩터링 처리 - 프레임워크 락인(lock-in)이 줄어들며, **의견이 강한(opinionated) 스택도 부담 없이 시도 가능** ### 5. .env를 넘어서: 에이전트 중심 환경에서의 시크릿 관리 - 수십 년간 `.env` 파일은 개발자가 API 키, 데이터베이스 URL, 서비스 토큰 등의 시크릿을 **로컬에서 간단하게 관리하는 기본 방식**이었음 - 이 방식은 단순하고 휴대 가능하며 개발자 친화적이지만, **AI IDE나 에이전트가 코드를 작성하고 서비스를 배포하며 환경을 조율하는 상황**에서는 문제가 발생함 - 즉, **.env 파일의 소유 주체가 누구인지 불분명**해짐 - 이 문제를 해결하기 위한 흐름이 나타나고 있음 - 예를 들어, 최신 MCP 스펙에는 [OAuth 2.1 기반의 인증 프레임워크](https://modelcontextprotocol.io/specification/draft/basic/authorization#2-authorization-flow)가 포함됨 - 이 구조는 AI 에이전트에게 **원시 시크릿 대신 범위 제한된 토큰(scope-based, revocable tokens)** 을 부여하는 방향을 시사함 - 예: 에이전트가 AWS 전체 키를 받는 대신, “S3에 파일 업로드”처럼 제한된 액션만 허용하는 **단기 인증 자격(credential)** 을 받는 구조 - 또 다른 흐름은 **로컬 시크릿 브로커(secret broker)의 등장**임 - 이는 로컬 또는 앱 옆에서 실행되며, **에이전트와 민감한 시크릿 사이를 중개하는 서비스** 역할을 함 - 에이전트는 `.env`에 직접 접근하거나 하드코딩하지 않고, 특정 작업 요청 시 브로커가 이를 실시간으로 판단하고 권한을 부여함 - 예: “Staging에 배포” 또는 “Sentry로 로그 전송” 요청 - 브로커는 이를 **Just-in-time 방식으로 처리하며, 모든 접근은 감사 추적 가능** - 이 방식은 **시크릿 접근을 파일 시스템이 아닌 API 기반 권한 모델**로 전환함 - 결과적으로, 시크릿 관리는 `.env` 구성에서 **OAuth 기반 권한 제어 구조**로 발전하게 됨 ### 6. 접근성을 보편적 인터페이스로: LLM의 시각에서 본 앱 - 최근 Granola, Highlight 같은 앱들은 macOS의 접근성 설정을 요청하지만, 이는 **전통적인 장애인 지원 목적이 아닌, AI 에이전트가 UI를 관찰하고 상호작용하기 위한 용도**임 - 이는 일시적인 해킹이 아니라, **더 근본적인 인터페이스 전환의 예고**로 볼 수 있음 - 접근성 API는 원래 시각·운동 장애 사용자를 위한 디지털 접근성 향상을 위해 만들어졌음 - 그러나 이 API를 확장하면 **AI 에이전트를 위한 보편적인 인터페이스 계층**으로 작용 가능 - **픽셀 위치 클릭이나 DOM 스크래핑 대신**, 보조 기술이 UI를 해석하듯 **의미 기반(semantic)** 으로 앱을 관찰하고 동작할 수 있음 - 접근성 트리는 이미 버튼, 제목, 입력 필드 등 **구조화된 UI 요소**를 노출하고 있음 - 여기에 **의도(intent), 역할(role), 작동 가능성(affordance)** 등의 메타데이터를 추가하면, **에이전트가 목적과 맥락에 맞게 정밀하게 조작 가능** - 이 방향성은 다음과 같은 기능으로 확장될 수 있음: - **Context extraction**: 접근성/시맨틱 API를 통해 화면에 보이는 요소, 상호작용 가능 항목, 사용자의 현재 동작을 질의하는 방식 - **Intentful execution**: 여러 API 호출을 수동으로 연결하는 대신, “카트에 항목 추가하고 가장 빠른 배송 선택”처럼 **고수준 목표를 선언**하고 백엔드가 실행 절차를 구성 - **Fallback UI for LLMs**: 접근성 기능은 **공개 API가 없는 앱도 에이전트가 사용할 수 있도록 하는 백업 인터페이스** 제공 - 개발자는 시각적 UI나 DOM 외에도, **에이전트가 인식 가능한 렌더 표면(render surface)** 을 structured annotation이나 접근성 중심 컴포넌트로 정의 가능 - 요약하자면, 접근성 API는 이제 **사람만을 위한 기능이 아닌, AI와 시스템이 상호작용하는 핵심 인터페이스 계층**으로 발전하고 있음 ### 7. 비동기 에이전트 작업의 부상 - 개발자들이 코드 작성 에이전트와 자연스럽게 협업하게 되면서, **비동기 워크플로우**로의 전환이 가속화되고 있음 - 에이전트는 **백그라운드에서 병렬 작업을 진행하고**, 일정 수준까지 진행되면 결과를 보고하는 방식으로 동작함 - 이러한 상호작용은 점점 페어 프로그래밍보다는 **태스크 오케스트레이션(task orchestration)** 에 가까워지고 있음 - 즉, 개발자는 목표를 전달하고, 에이전트는 수행한 뒤 나중에 확인하는 방식 - **중요한 점은 단순히 일을 덜어주는 것이 아니라, 협업 자체를 압축한다는 것** - 예를 들어, 다른 팀에 구성 파일 업데이트 요청이나 에러 트리아지, 컴포넌트 리팩터링을 요청하는 대신, 개발자가 **에이전트에게 직접 의도를 전달하고 백그라운드에서 처리하도록 지시** 가능 - 기존에는 동기식 회의, 부서 간 핸드오프, 장기 리뷰 사이클이 필요했지만, 이제는 **요청 → 생성 → 검증(request → generate → validate)** 의 루프가 자연스럽게 이루어짐 - 에이전트와 상호작용하는 방식도 확장되고 있음 - 단순히 IDE나 CLI에서 프롬프트를 입력하는 방식 외에도 다음과 같은 방식 가능: - Slack 메시지로 작업 요청 - Figma 목업에 코멘트 작성 - 코드 diff나 PR에 인라인 주석 달기 (예: Graphite 리뷰 어시스턴트) - 배포된 앱 프리뷰에 피드백 추가 - 음성 또는 통화 기반 인터페이스를 통해 변경사항을 구두로 설명 - **이러한 변화는 에이전트가 개발 생애주기 전반에 존재하게 만듦** - 코드 작성에 그치지 않고, 디자인 해석, 피드백 반영, 플랫폼 전반의 버그 트리아지까지 수행 - 개발자는 어떤 작업 스레드를 진행·제외·병합할지 결정하는 **오케스트레이터(orchestrator)** 역할을 맡음 - 이런 흐름은 궁극적으로 **에이전트 기반 작업 스레드가 새로운 ‘Git 브랜치’ 개념으로 자리잡을 가능성**을 시사 - 더 이상 정적인 코드 포크가 아니라, **목적 중심의 동적 스레드**가 비동기로 실행되며 완성 시 통합되는 방식 ### 8. MCP: 범용 표준에 한 걸음 더 가까워진 Model Context Protocol - 최근 [MCP에 대한 심층 분석 글](https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/)을 공개한 이후, MCP 채택 속도가 가속화되고 있음 - OpenAI가 공식적으로 MCP를 채택했고, 여러 신규 기능이 스펙에 병합되었으며, 점점 더 많은 도구 제작자들이 MCP를 **에이전트와 실제 세계 사이의 기본 인터페이스로 수용**하고 있음 - MCP는 본질적으로 두 가지 중요한 문제를 해결함: - LLM이 처음 접하는 작업도 수행할 수 있도록 **필요한 컨텍스트를 제공** - N×M 방식의 맞춤형 통합을 없애고, **도구가 표준 인터페이스(서버)를 노출하고, 모든 에이전트(클라이언트)가 사용할 수 있는 구조**로 단순화 - 향후 MCP 채택이 더 확대될 것으로 예상되며, **원격 MCP와 사실상의 MCP 레지스트리(de-facto registry)** 가 등장할 경우, 많은 앱이 기본적으로 MCP 인터페이스를 탑재한 상태로 출시될 수 있음 - 과거 API가 SaaS 도구를 연결하고 워크플로우를 구성하게 했던 것처럼, **MCP는 AI 에이전트를 위한 상호운용 가능한 구성 요소의 생태계**를 만들어낼 수 있음 - MCP 클라이언트를 내장한 플랫폼은 단순히 “AI 지원” 수준이 아니라, **에이전트가 접근 가능한 기능 네트워크에 바로 연결 가능한 생태계의 일부**가 됨 - **MCP의 클라이언트와 서버는 논리적 개념일 뿐, 물리적으로 구분되지 않음** - 이는 어떤 MCP 클라이언트도 서버가 될 수 있고, 반대도 가능하다는 의미임 - 이로 인해 다음과 같은 **고도의 조합 가능성(composability)** 이 열림: - 예: 한 코딩 에이전트는 클라이언트로서 GitHub 이슈를 가져오고, 동시에 서버로서 다른 에이전트에게 **테스트 커버리지나 코드 분석 결과를 제공** 가능 - MCP는 도구와 에이전트가 유기적으로 상호작용하는 생태계를 위한 **기본 인터페이스 계층으로 자리잡고 있음** ### 9. 추상화된 프리미티브: 모든 AI 에이전트가 필요로 하는 인증, 결제, 저장소 - 바이브 코딩 에이전트가 점점 강력해질수록 분명해지는 사실은, 에이전트가 많은 코드를 생성할 수는 있지만 **그 코드가 연결될 신뢰 가능한 기반이 필요**하다는 점임 - 인간 개발자가 결제는 Stripe, 인증은 Clerk, 데이터베이스는 Supabase에 의존하듯, **에이전트도 신뢰할 수 있고 조합 가능한 서비스 프리미티브**가 필요함 - 이들 서비스는 명확한 API 경계, 사용하기 쉬운 SDK, 합리적인 기본 설정을 제공하며, 점점 더 **에이전트의 런타임 인터페이스 역할**을 하게 됨 - 예를 들어 SaaS 앱을 생성하는 도구를 만들 때, 에이전트가 직접 인증 시스템이나 결제 로직을 구현하는 대신, Clerk와 Stripe를 사용해 **빠르고 안전하게 통합**함 - 이 패턴이 성숙해지면, 서비스는 단순한 API 제공을 넘어 다음을 공개할 수 있음: - **스키마(schema)**: 구조화된 데이터 정의 - **기능 메타데이터(capability metadata)**: 수행 가능한 작업 명세 - **예제 플로우(example flows)**: 통합 방법에 대한 사례 → 이를 통해 에이전트가 더욱 안정적으로 통합 가능 - 일부 서비스는 아예 **MCP 서버를 내장한 채 출시**될 수 있음 - 예: Clerk가 MCP 서버를 통해 사용 가능한 상품 목록 조회, 새 요금제 생성, 구독 수정 등의 기능을 노출 - 에이전트는 API 명세나 문서를 찾는 대신 자연어로 요청하고, MCP 서버는 **권한 범위와 제약조건 내에서 요청을 검증하고 처리** - 예: > “월 $49의 Pro 요금제를 만들고, 사용량 기반 추가 과금 설정해줘” → Clerk의 MCP 서버가 이 요청을 해석하고 실행 - 초창기 웹 시대에 `rails new`가 빠른 개발을 가능하게 했던 것처럼, **에이전트 시대에는 신뢰할 수 있는 프리미티브(drop-in identity, 결제, 접근 제어 등)** 가 필요함 - 이들은 충분히 **추상화되어 에이전트가 생성용으로 활용**할 수 있으면서도, 앱의 성장과 함께 확장 가능한 구조여야 함 ### 결론 - 이 9가지 패턴은 단순히 기존 개발 방식에 AI를 얹는 것이 아니라, **에이전트·맥락·의도 중심으로 소프트웨어 제작 방식 자체가 재정의되고 있음**을 보여줌 - 이에 따라 기존의 개발자 행동 양식도 변화하고 있으며, 이를 뒷받침하는 **신규 툴체인과 프로토콜(MCP 등)** 이 빠르게 등장 중 - Git, 템플릿, 대시보드, 문서화 방식 등 **기존의 핵심 도구 계층들이 AI와 함께 근본적으로 재설계**되고 있음 - 이러한 전환기를 맞아, **새로운 개발 생태계를 구성할 차세대 도구와 인프라에 대한 구축과 투자가 활발히 이루어질 것**으로 기대됨 ## Comments ### Comment 39386 - Author: aa1567 - Created: 2025-05-28T12:11:43+09:00 - Points: 1 1번을 실제로 하는 사람이 있다고..? ### Comment 39343 - Author: hhcrux - Created: 2025-05-27T15:12:58+09:00 - Points: 2 LLM은 같은 입력에 대해 같은 출력을 보장하지 않는데 저런 식의 형상관리가 통한다는걸까요... 아직 내가 너무 1차원적으로만 사용중인건가 ### Comment 39351 - Author: beoks - Created: 2025-05-27T18:21:46+09:00 - Points: 1 - Parent comment: 39343 - Depth: 1 temperature 옵션을 0으로 설정하면 같은 입력에 대해 같은 출력을 보장하는 걸로 알고 있습니다 ### Comment 39375 - Author: fanotify - Created: 2025-05-28T09:12:14+09:00 - Points: 1 - Parent comment: 39351 - Depth: 2 어차피 몇달 지나면 또 모델 자체가 바뀌니까 의미없지 않을까요 ### Comment 39352 - Author: beoks - Created: 2025-05-27T18:29:04+09:00 - Points: 1 - Parent comment: 39351 - Depth: 2 이건 둘째치고 아예 인간의 개입을 고려하지 않는다는 점이 너무 단정적이네요, 간단한 수치나 메시지 수정의 경우 LLM 보다 인간이 개입하는게 더 효율적일텐데요. ### Comment 39284 - Author: nicewook - Created: 2025-05-26T18:27:38+09:00 - Points: 1 깊은 통찰을 느끼는 글입니다. 역시 a16z입니다. ### Comment 39249 - Author: ruinnel - Created: 2025-05-26T11:26:48+09:00 - Points: 1 https://news.hada.io/topic?id=21091 이글 읽고나서 읽으니 이게 맞나 싶네요. ### Comment 39248 - Author: ahwjdekf - Created: 2025-05-26T11:13:32+09:00 - Points: 4 1번은 정말 악몽과도 같은 , 절대로 받아들이고 싶지 않는 변화네요. 소스코드 이력 추적의 무의미해지는 꼴.