YC가 올해 돈 넣을 곳은...

DIGEST

YC, 2026년 여름 RFS 15개 공개 — AI 네이티브 서비스부터 대드론 방어까지
하네스 엔지니어링 — 모델보다 중요한 ‘작업 환경 설계’가 공학 분야로 부상
Claude Code + Codex 이중 에이전트 패턴 — 한 달 실전 운영기

오늘의 GeekNews는 세 가지 핵심 흐름으로 수렴한다. YC가 2026년 여름 배치를 앞두고 “이런 스타트업이 필요하다”는 목록 15개를 던졌고, 그 안에는 AI가 소프트웨어를 넘어 서비스 자체를 삼키는 시나리오가 가득하다. 한편 구글 엔지니어 애디 오스마니는 AI 코딩 도구의 경쟁력이 모델이 아니라 ‘하네스’에서 결정된다는 분석을 내놓았다. 그리고 현장에서는 이미 Claude Code와 Codex를 한 레포에서 동시에 굴리며, 서로의 사각지대를 메우는 이중 에이전트 패턴이 실전에 자리잡고 있다.

YC의 Requests for Startups – 2026년 여름

AI가 기반 기술이 된 시대, YC가 원하는 15개 스타트업

Y Combinator가 매 분기 공개하는 RFS(Request for Startups)가 2026년 여름 버전으로 갱신됐다. 이번 목록의 핵심 기조는 명확하다. AI가 단순 기능이 아닌 기반 기술로 자리 잡으면서, 소프트웨어와 서비스, 반도체까지 재구축해야 한다는 것이다. 15개 아이디어 중 눈에 띄는 주제를 추려보면 이렇다.

서비스를 삼키는 AI

YC는 “AI 네이티브 서비스 기업”을 가장 먼저 꼽았다. 2023~2025년 스타트업이 사람을 돕는 도구를 만들었다면, 다음 단계는 소프트웨어가 아닌 서비스 자체를 판매하는 기업이다. 보험 중개, 회계/세무/감사, 컴플라이언스, 의료 행정이 특히 관심 분야로 지목됐다. 서비스 지출 총액이 소프트웨어보다 수 배 크고, 이미 아웃소싱 구조가 잡혀 있어 AI 대체가 용이하다는 논리다.

에이전트 시대의 인프라

“에이전트를 위한 소프트웨어”도 별도 항목으로 올라왔다. 인터넷의 다음 1조 사용자는 사람이 아닌 AI 에이전트이며, 이들에게는 폼이나 버튼 대신 API, MCP, CLI 같은 기계 판독 가능 인터페이스가 필요하다는 것이다. “에이전트 워크플로우용 추론 칩” 항목도 흥미롭다. 현재 GPU가 에이전트 워크로드에서 피크 활용률 30~40%에 머문다는 지적과 함께, 빠른 컨텍스트 스위칭과 KV 캐시 유지 메모리를 네이티브로 지원하는 칩의 필요성을 강조했다.

SaaS 해자의 소멸

YC는 AI 코딩으로 소프트웨어 생산 비용이 10~100배 축소되면서, 수십 년간 수백만 줄의 코드로 형성된 레거시 SaaS의 해자가 소멸하고 있다고 진단한다. 칩 설계 소프트웨어, ERP, 산업 제어 시스템처럼 수십 년간 난공불락이던 1,000만 줄 규모 코드베이스를 공략할 때라고 권고한다. 또한 “Company Brain” 개념도 제시했는데, AI 자동화의 가장 큰 장벽이 모델 성능이 아닌 도메인 지식으로 전환됐다는 인식 하에, 기업의 분산된 노하우를 추출하고 구조화해 AI가 실행할 수 있는 스킬 파일로 만드는 인프라를 요구하고 있다.

Tech Insight — YC의 2025년 여름 RFS와 비교하면, AI 적용이 확실히 버티컬과 엔터프라이즈 쪽으로 이동했다. “AI 네이티브 서비스 기업”과 “에이전트를 위한 소프트웨어”가 별도 항목으로 분리된 것 자체가 시장 인식의 변화를 보여준다. 특히 대드론 군집 방어, 우주 전자부품 같은 물리 세계 항목이 등장한 것은 AI가 소프트웨어를 넘어 하드웨어 영역까지 재편하기 시작했다는 YC의 판단을 반영한다.

하네스 엔지니어링: 모델보다 중요한 작업 환경 설계

AI 에이전트 = 모델 + 하네스

구글의 애디 오스마니(Addy Osmani)가 “하네스 엔지니어링(Harness Engineering)”이라는 개념을 정리해 큰 반향을 일으켰다. 핵심 주장은 이것이다. AI 코딩 도구의 실제 성과는 모델 자체보다 그 모델을 둘러싼 하네스에서 결정된다. 여기서 하네스란 시스템 프롬프트, 도구와 MCP 서버, 컨텍스트 관리 정책, 훅(hook), 샌드박스, 서브에이전트, 피드백 루프까지 모델을 제외한 모든 것을 포괄한다.

모델 탓이 아니라 설정 탓

같은 Claude Opus 4.6 모델이라도 기본 하네스에서는 벤치마크 하위권에 머물지만, 직접 손본 하네스로 옮기면 상위권으로 뛰어오른 사례가 소개됐다. 비브 트리베디(Viv Trivedy)의 팀은 하네스만 바꿔서 같은 모델을 30위권에서 5위권으로 끌어올렸다. 오스마니는 이를 “모델 문제가 아니라 설정 문제(skill issue)”라고 표현한다.

래칫 원칙과 컨텍스트 부패

하네스 엔지니어링의 핵심 규율은 “래칫(ratchet)”이다. AI가 한 번 저지른 실수를 우연으로 넘기지 않고, 규칙 문서에 한 줄을 추가하고 자동 차단 장치를 붙여 같은 실수가 반복되지 않게 한 칸씩 조여 나간다. 또한 AI의 컨텍스트 창이 차오를수록 판단력이 떨어지는 “컨텍스트 부패” 문제를 다루는데, 오래된 내용을 압축하거나, 큰 출력물은 파일로 분리하거나, 아예 인수인계 문서를 만들어 새 세션에서 시작하는 패턴이 제시됐다.

Tech Insight — 클로드 코드, 커서, 코덱스, 에이더, 클라인 같은 코딩 AI들이 속에 든 모델은 다르지만 하네스의 모양은 점점 닮아 가고 있다는 오스마니의 관찰이 인상적이다. 이는 하네스 설계가 특정 제품의 기능이 아니라 하나의 공학 분야로 수렴하고 있다는 증거다. “하네스의 모든 부품은 모델이 혼자 못하는 일이 무엇인지에 대한 가정을 담고 있다”는 Anthropic의 표현이 본질을 잘 짚는다.

Claude + Codex 이중 에이전트 워크플로우 실전기

같은 모델에게 셀프 리뷰를 맡기면 안 되는 이유

한 개발자가 Claude Code와 OpenAI Codex를 한 레포에서 한 달간 병용한 실전기를 공유했다. 핵심 구조는 단순하다. Claude Code는 메인 작성자, Codex는 advisory(차단 없는) 리뷰어. 같은 모델에게 자기 코드의 리뷰를 맡기면 자기가 세운 가정을 그대로 받아들여 빈틈을 못 잡는다. 다른 모델을 옆에 두는 것만으로 race condition이나 누락된 null 체크 같은 버그가 머지 직전에 잡히기 시작했다고 한다.

advisory는 절대 차단이 아니다

가장 중요한 규칙은 Codex의 리뷰 결과가 CRITICAL이라 해도 push를 차단하지 않는 것이다. 한 번이라도 차단으로 만들면 모델 다운에 작업 전체가 멈추고, false positive 한 번에 개발자가 –no-verify로 hook을 통째 우회하기 시작한다. 또한 CLAUDE.md와 AGENTS.md를 같은 내용으로 채우면 안 된다. 작성자에게는 “어떻게 만드는지”, 리뷰어에게는 “무엇을 의심해야 하는지”를 담아야 분담이 실질적으로 작동한다.

한 달 써보고 달라진 점

PR 올린 다음 날 “이거 왜 이렇게 짰지” 하고 되돌아보는 일이 거의 사라졌고, 셀프 리뷰 피로가 확연히 줄었다고 한다. 마이그레이션 SQL이나 결제 흐름처럼 되돌리기 어려운 변경 직전에 다른 모델이 한 번 더 본다는 점이 심리적으로 가장 큰 차이였다는 평가다. 8챕터짜리 커리큘럼 형태로 셋업부터 보일러플레이트까지 정리돼 있어, 도입을 고민하는 팀에게 실용적인 가이드가 된다.

Tech Insight — 이 글은 앞서 다룬 하네스 엔지니어링의 구체적 실천 사례로 읽힌다. “어떤 도구를 쓰느냐”보다 “여러 도구의 사각지대를 어떻게 겹쳐 덮느냐”가 결정적이라는 결론은, 사람 코드 리뷰를 둘 이상에게 받는 이유와 정확히 같은 구조다. AI 코딩 도구 시장이 단일 도구 경쟁에서 조합 전략 경쟁으로 넘어가고 있다는 신호다.

출처

AI Biz Insider · Tech Digest · aibizinsider.com

YC가 올해 돈 넣을 곳은…