Agent-Native Development

Palantir가 공개한 “The Palantir Ontology"는 단순한 데이터 통합 전략이 아니라, 기업 운영을 의사결정 단위로 모델링해야 한다는 주장을 담고 있습니다. 이 글은 긴 원문을 실무 관점에서 빠르게 파악할 수 있도록 핵심만 압축한 정리입니다. TL;DR 핵심 정리 핵심 프레임: Ontology는 Data + Logic + Action + Security를 하나로 연결해, 분석 시스템이 아닌 운영 의사결정 시스템을 만든다. 중요한 포인트: 기업 데이터 자체보다, 누가/언제/어떤 맥락에서 어떤 결정을 내렸는지에 대한 의사결정 데이터와 계보 축적을 더 중시한다. 에이전트 활용 방식: LLM이 단순 조회(RAG)에 머무르지 않고, 기존 최적화 모델·시뮬레이터·업무 로직을 툴로 호출해 대안을 만들고 시나리오로 안전하게 검토한다. 실행과 통제: 액션(writeback)은 ERP/WMS/엣지 시스템까지 반영되지만, 권한·검증·감사 로그를 동일한 보안 체계로 강제해 자동화 리스크를 줄인다. 최종 메시지: 생성형 AI 도입 성패는 “모델 성능"보다 “의사결정 루프를 얼마나 안전하게 닫고 학습시키는 아키텍처를 갖췄는가"에 달려 있다는 주장이다. 원문: https://x.com/PalantirTech/status/2049136883528011954 ...

출처: https://alexop.dev/posts/the-software-factory/ 핵심 메시지 AI 코딩 에이전트(Claude Code 등)를 활용해 “software 팩토리” 를 구축하면, 개발 팀의 작업 방식이 완전히 바뀐다. 개발자는 더 이상 코드를 직접 많이 작성하지 않고, 설계·아키텍처·검토·의사결정 에 집중한다. 결과적으로 팀 규모는 크게 줄고, 출시 속도는 몇 시간 단위로 빨라진다. 기존 방식 vs. software 팩토리 기존 방식 (Beer Commerce 예시) 12명 체크아웃 팀 한 기능(할인 코드 추가) 추가에 10~14일 소요 대부분 시간이 핸드오프(BA → PO → Dev → QA)와 커뮤니케이션에서 사라짐 실제 코딩 시간은 고작 2~3일 software 팩토리 방식 ...

새로운 AI 시대의 가장 중요한 인재는 엔지니어가 아니라 연구자 입니다. 누구나 AI로 “무료로 만들 수 있는” 시대가 되면, 진짜 차별점은 “무엇을 만들 가치가 있는가? 과연 만들 수 있는가?” 를 판단하는 능력이다. 연구자는 해결책이 없을 수도 있는 문제를 붙잡고, “이 베팅에 목숨 걸 만한가?” 를 결정하는 사람들입니다. 시장도 이미 이 사실을 반영하고 있다 퀀트 펌들은 포트폴리오 한 번 관리해 본 적 없는 학부생에게 $600k 를 준다. AI 랩(Meta Superintelligence Labs 등)은 연구자 한 명에게 4년간 $3억 까지 제안한다. → 한 번의 학습 비용이 수억 달러인데, 데이터 효율을 1~2%만 올려도 그 연구자가 수십 배로 돈을 벌어줍니다. 왜 연구는 자동화하기 어려운가? ...

출처: https://every.to/guides/compound-engineering Every의 가이드 “Compound Engineering” 은 AI 에이전트를 활용한 새로운 소프트웨어 개발 패러다임을 설명하고 있습니다. 핵심은 “전통적인 개발은 코드가 쌓일수록 복잡해져 속도가 느려지지만, 컴파운드 엔지니어링은 할수록 다음 작업이 더 쉬워지고 빨라진다” 는 것입니다. 1. 핵심 철학 (The Philosophy) 복리 효과(Compounding): 모든 단위 작업(코드, 문서, 툴링)이 다음 작업을 더 쉽게 만들어야 합니다. 시스템에 ‘취향’ 반영: 코드 리뷰 시 매번 수동으로 수정하는 대신, 설정·스키마·자동 검사 도구에 판단 기준을 녹여내어 시스템 자체가 학습하게 합니다. 직접 하기보다 가르치기: 코드를 직접 타이핑하는 시간보다 AI 에이전트에게 더 많은 컨텍스트를 제공하는 데 시간을 투자합니다. 2. 4단계 루프 (The Loop) 컴파운드 엔지니어링은 다음의 반복적인 과정을 통해 완성됩니다. ...

출처: https://cra.mr/context-management-and-mcp/ 이 글은 Sentry의 창립자인 David Cramer가 작성한 것으로, 최근 개발자들 사이에서 벌어지는 “MCP(Model Context Protocol)냐 CLI(명령줄 인터페이스)냐” 의 논쟁이 본질을 벗어난 것임을 지적하며 ‘컨텍스트 관리와 조종(Steering)’ 의 중요성을 강조하고 있습니다. 1. MCP vs CLI 논쟁의 핵심 잘못된 비교: 많은 사람들이 CLI가 나왔으니 MCP를 쓸 필요가 없다고 말하지만, 이는 LLM이 컨텍스트를 어떻게 처리하는지 이해하지 못한 결과입니다. MCP의 진정한 가치: MCP는 단순한 API 프록시가 아니라, LLM이 도구를 더 정확하게 사용하도록 ‘조종(Steering)’ 하는 데 최적화되어 있습니다. MCP는 마크다운, XML 구조, 힌트 등을 활용해 모델이 이해하기 쉬운 형태로 정보를 전달합니다. 2. 조종(Steering)의 중요성 LLM 맞춤형 응답: 일반적인 API나 CLI는 기계(Machine) 중심의 출력을 내놓지만, 우수한 MCP 서버(예: Sentry MCP)는 LLM이 다음 행동을 결정하기 좋게끔 요약된 정보와 가이드를 제공합니다. 토큰 효율성: “항상 켜져 있는 MCP 도구가 토큰을 낭비한다"는 비판도 있지만, 초기 조종 컨텍스트에 토큰을 투자하는 것이 나중에 모델이 길을 잃어 발생하는 ‘컨텍스트 부패(Context Rot)‘를 막는 데 더 효과적입니다. 3. 점진적 공개(Progressive Disclosure)의 한계 필요할 때만 도구 설명을 불러오는 방식은 모델로부터 ‘도구의 의도’를 숨기게 되어, 결국 모델의 추론 능력을 떨어뜨리고 API 호출기 수준으로 전락시킵니다. 4. 해결책: 서브에이전트(Subagents) 저자는 현재의 한계를 극복하기 위해 서브에이전트 방식 을 제안합니다. 특정 작업에만 필요한 MCP 도구와 컨텍스트를 격리된 서브에이전트에 할당함으로써, 컨텍스트 부패를 최소화하고 각 모델이 전문적인 작업을 수행하도록 만들 수 있습니다. 요약 결론 결국 중요한 것은 어떤 프로토콜을 쓰느냐가 아니라 “어떻게 하면 모델이 실수 없이 작업을 완수하도록 컨텍스트를 잘 설계하고 전달(Steering)하느냐” 입니다. 저자는 이를 위해 모델의 한계를 인정하고 서브에이전트와 같은 구조적 접근이 필요하다고 주장합니다.

출처: https://deadneurons.substack.com/p/chat-is-going-to-eat-the-world 1. 인터페이스의 혁명: 채팅이 모든 것을 삼킨다 과거 소프트웨어는 복잡한 메뉴와 버튼으로 구성된 GUI(그래픽 사용자 인터페이스) 중심이었습니다. 하지만 이제 ‘채팅’은 단순한 기능이 아니라, 사용자가 컴퓨터와 상호작용하는 기본 운영 체제(OS) 가 되고 있습니다. 마크 안드레센이 “소프트웨어가 세상을 먹어치운다"고 했듯, 이제는 “채팅이 소프트웨어를 먹어치우고” 있습니다. 2. ‘앱’의 종말과 ‘에이전트’의 시대 사용자는 더 이상 특정 목적을 위해 개별 앱을 찾아다니거나 복잡한 사용법을 익힐 필요가 없습니다. 대신 자연어로 요청하면 AI 에이전트가 뒤에서 필요한 도구와 데이터를 호출해 결과를 가져다줍니다. 이로 인해 기존의 수많은 개별 앱과 웹사이트의 경계가 무너지고, 모�어와 비즈니스는 도태될 것이라는 경고와 기대를 동시에 전달합니다. ...