YC가 돈 넣겠다는 분야…

YC가 2026년 여름 배치를 앞두고 15개 스타트업 아이디어를 공개했다. 에이전트 워크플로우 전용 추론 칩부터 반도체 공급망 2.0까지, 이번 목록은 버티컬과 엔터프라이즈에 한층 깊이 파고든다. 한편 개발자 세계에서는 ‘어떤 모델이 좋은가’라는 질문이 ‘모델 주변 환경을 어떻게 설계하느냐’로 이동 중이다. 하네스 엔지니어링이라는 새 공학 분야가 부상하고, Claude Code와 Codex를 한 레포에서 분담시키는 이중 에이전트 패턴이 실무에 안착하고 있다. 오늘의 개발자 필독 3선을 정리했다.

YC의 Requests for Startups — 2026년 여름

에이전트 시대, YC가 찍은 15가지 방향

Y Combinator가 2026년 여름 배치를 앞두고 ‘Request for Startups(RFS)’ 목록을 갱신했다. 지난 시즌에도 에이전트 관련 주제가 많았지만, 이번에는 버티컬과 엔터프라이즈 적용이 한층 구체적이다. 15개 아이디어를 관통하는 키워드는 세 가지다. 첫째, 에이전트 워크플로우 전용 추론 칩이다. 현재 GPU는 에이전트의 도구 호출-분기-역추적 루프에서 활용률이 30~40%에 그치는데, NVIDIA가 Groq를 200억 달러에 인수하고 Google이 추론 전용 TPU v7을 내놓았지만 에이전트 루프 자체를 위한 설계는 아직 없다.

SaaS 챌린저와 에이전트를 위한 소프트웨어

둘째, SaaS 챌린저 기회다. 소프트웨어 생산 비용이 10~100배 축소되면서 수십 년간 난공불락이던 칩 설계 소프트웨어, ERP, 산업 제어 시스템의 1,000만 줄 코드베이스를 공략할 수 있게 됐다. YC는 프로젝트 관리 도구 같은 단순 타겟이 아니라 이런 중량급을 노리라고 권고한다. 셋째, 에이전트를 위한 소프트웨어다. 인터넷의 다음 1조 사용자는 사람이 아니라 에이전트이고, 이들에게는 폼과 버튼이 아닌 API, MCP, CLI 같은 기계 판독 가능 인터페이스가 필요하다.

Company Brain과 반도체 공급망 2.0

그 외 눈에 띄는 아이디어로는 기업의 분산된 노하우를 추출해 에이전트가 실행할 수 있는 ‘스킬 파일’로 전환하는 Company Brain, 최첨단 칩 하나가 1,400개 공정 단계와 12개국을 경유하는데도 스프레드시트로 관리되는 반도체 공급망 2.0, 저가 드론 군집 방어를 Raytheon이 아닌 Cloudflare 방식으로 접근하는 Counter-Swarm Defense 등이 있다. 2~3명 팀이 법인 설립 전에 Fortune 10 기업이 쓸 제품을 출시하는 시대가 YC의 기본 전제가 됐다.

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

모델 탓이 아니라 설정 탓

구글의 Addy Osmani가 정리한 ‘하네스 엔지니어링(Harness Engineering)’ 분석이 GeekNews에서 40P를 받으며 주목받고 있다. 핵심 주장은 명확하다. 코딩 도구의 성과는 모델 자체보다 그 모델을 둘러싼 하네스–시스템 프롬프트, 도구, 샌드박스, 훅, 서브에이전트, 피드백 루프–에서 결정된다는 것이다. 같은 Claude Opus 4.6 모델이 기본 하네스에서는 터미널 벤치 2.0 하위권이지만, 직접 손본 하네스로 옮기면 상위권으로 뛰어오른 사례가 보고됐다. Viv Trivedy의 팀은 하네스만 바꿔 같은 모델을 30위권에서 5위권으로 끌어올렸다.

래칫 원칙과 컨텍스트 부패

하네스 엔지니어링의 핵심 규율은 ‘래칫(ratchet)’ 원칙이다. 한 번 발생한 실수는 규칙 문서에 한 줄을 추가하고, 자동 차단 장치를 붙이고, 검토 담당 보조 에이전트를 두는 식으로 한 칸씩 조여 나간다. 좋은 규칙 문서의 모든 줄은 과거의 구체적인 실패와 연결돼야 한다. 또한 ‘컨텍스트 부패(context rot)’ 문제도 중요하다. 컨텍스트 한도에 가까워질수록 판단력이 떨어지므로, 오래된 내용의 요약 압축, 큰 출력물의 파일 분리, 도구의 점진적 공개 같은 장치가 필수다. Anthropic은 “긴 작업에서는 요약만으로 부족하고 구조화된 인수인계 문서로 새로 시작해야 할 때가 있다”고 짚는다.

업계가 수렴하는 방향

Claude Code, Cursor, Codex, Aider, Cline 같은 코딩 도구들은 속에 든 모델은 다르지만 하네스의 모양은 점점 닮아가고 있다. 모델이 좋아지면 일부 하네스 부품은 불필요해지지만, 모델이 새로 닿는 영역에서는 새로운 약점이 생기고 새 하네스가 그 자리를 메운다. “하네스의 모든 부품은 모델이 혼자 못하는 일이 무엇인지에 대한 가정을 담고 있다”는 Anthropic의 표현이 핵심이다. 하네스 서비스(Harness-as-a-Service)로 Claude Agent SDK, Codex SDK, OpenAI Agent SDK처럼 작업 루프와 도구를 미리 묶어 주는 제품들이 빠르게 자리 잡고 있다.

Claude Code + Codex 이중 에이전트 분담 패턴

같은 모델의 셀프 리뷰는 빈틈을 못 잡는다

rubric.im에 공개된 8챕터 커리큘럼이 Claude Code와 Codex를 한 레포에서 분담시키는 실무 패턴을 정리했다. 핵심 구조는 단순하다. 같은 모델에게 자기 코드를 리뷰시키면 자기가 세운 가정을 그대로 받아들여 빈틈이 안 잡힌다. 그래서 Claude Code를 메인 작성자, Codex를 advisory 리뷰어로 옆에 두는 이중 구조를 쓴다. 가장 중요한 룰은 advisory를 절대 차단(blocking)으로 만들지 않는 것이다. Codex가 CRITICAL을 잡아도 push는 통과시킨다. 차단으로 바꾸는 순간 모델 다운에 작업 전체가 멈추고, false positive 한 번에 사용자가 hook을 통째 우회하기 시작한다.

CLAUDE.md와 AGENTS.md는 다르게 채운다

작성자에게는 ‘어떻게 만드는지’, 리뷰어에게는 ‘무엇을 의심해야 하는지’를 넣는다. 두 파일의 내용이 80% 이상 겹치면 분담이 사실상 안 되고 있다는 신호다. codex review –base는 git을 직접 읽어 깔끔하지만 큰 PR에서 토큰이 폭주하고, codex exec는 prompt에 diff를 직접 넣어 비용 통제가 가능하다. 100파일 넘는 변경은 exec로 갈아타는 패턴을 권장한다.

한 달 실전 후기

저자의 한 달 사용 후기에서 가장 인상적인 변화는 머지 직전에 잡히는 버그가 늘었다는 점이다. Claude가 자신만만하게 짠 부분에서 Codex가 race condition과 누락된 null 체크를 짚어내는 케이스가 자주 발생했다. PR을 올린 다음 날 ‘이거 왜 이렇게 짰지’ 하는 일이 거의 사라졌고, 셀프 리뷰 피로가 확연히 줄었다. 마이그레이션 SQL이나 결제 흐름처럼 되돌리기 어려운 변경 직전에 다른 모델이 한 번 더 본다는 점이 심리적으로 가장 큰 차이였다고 한다.

관련 글

• YC의 Requests for Startups – Summer 2025
• 하네스 엔지니어링이란?
• Claude Code(~100시간) vs. Codex(~20시간) 비교
• 프롬프트에서 하네스까지 – 에이전틱 패턴 4년의 기록
• Claude Code 활용 방식: 계획과 실행의 분리

출처

1. YC Requests for Startups – Summer 2026 (ycombinator.com)
2. Addy Osmani – Agent Harness Engineering (addyosmani.com)
3. Claude + Codex Dual Agent Workflow Curriculum (rubric.im)
4. GeekNews (news.hada.io)