Intent: 코드를 안 보여주는 IDE
AI 네이티브 IDE 회사 Augment가 Intent를 출시했어요 — IDE가 뭐여야 하는지에 대한 근본적인 재고예요.
코드 에디터가 없어요.
파일 브라우저도 없고. 신택스 하이라이팅도 없고. 탭도 없고. “터미널에서 열기” 버튼도 없어요. 전체 인터페이스가 한 가지 루프 중심으로 만들어져 있어요:
- 스펙 작성 (당신의 의도)
- 에이전트가 오케스트레이션하고 실행
- 결과 검증
이게 다예요. 코드를 본 적이 없어요. 머신이 하는 일을 보죠.
올해 내내 쌓여온 대화의 끝점이에요. Phillip Su가 AI 에이전트가 IC 역할을 죽였다고 주장했고, 저는 검증 갭에 대해 썼어요 — 즉각적인 피드백 없는 의사결정이 공허하다는 거.
Intent는 의사결정 포인트 자체를 없앰으로써 해결해요. 코드를 짜고 있지 않아요. 코드를 보지도 않아요. 에이전트를 오케스트레이션해서 스펙으로부터 뭔가를 만드는 거예요.
Intent가 실제로 하는 것
랜딩 페이지에서 본 범위:
Living specs. 스펙이 에이전트가 일을 완료하면서 자동으로 업데이트돼요. 요구사항이 바뀌면 → 모든 활동 중인 에이전트에 업데이트 전파. “우리가 뭘 정했지?” 가 사라져요. 스펙이 진실의 원천이고 자기 자신을 유지하니까요.
에이전트 오케스트레이션. Coordinator 에이전트가 스펙을 작업으로 쪼개요. Specialist 에이전트들이 병렬로 실행. Verifier가 스펙 대비 결과 확인. Coordinator가 정렬 유지.
통합 윈도우. 로컬 변경 미리보기용 브라우저 내장. 커밋과 브랜치용 Git 통합. IDE, 터미널, 브라우저 사이의 컨텍스트 전환 없음.
재개 가능한 세션. 종료했다가 내일 다시 열면 정확히 그대로. Auto-commit이 작업 완료를 캡처.
프로덕트 설계가 뭐가 일어났는지에 대해 정직해요: 코딩은 더 이상 병목이 아니에요. 결정이. 스펙이. 오케스트레이션이. UI가 그것을 무자비하게 반영해요.
이게 뭘 의미하는지
Intent는 코드를 더 잘 짜는 걸 도와주려는 게 아니에요. 코드를 안 짜도록 도와주려는 거예요.
이건 Copilot이나 Claude Code나 다른 LLM IDE 확장과 달라요. 그 프로덕트들은 여전히 사람이 주 액터이고 에이전트가 도우미라고 가정해요. Intent는 반대예요: 에이전트가 주 액터이고 사람이 오케스트레이터.
코드를 짜고 있지 않아요. 의도를 쓰고 있어요. 디버깅하지 않아요. 검증하고 있어요. 시스템을 만들어가며 어떻게 동작하는지 배우지 않아요 — 시스템에 대한 결정이 맞는지 배워요.
Su의 “IC는 죽었다” 논리의 살아있는 끝점이에요. Su가 IC 역할이 매니저 일로 전환된다고 했는데 그게 에이전트 생산성을 최대화하기 때문이에요. Intent는 그 로직을 끝까지 가요: IC 역할이 매니저 일이면 왜 IDE가 있어야 해요? 왜 코드 에디터가? 그냥 스펙 윈도우랑 오케스트레이션 컨트롤만 주면 되지 않아요?
검증 루프는 다르게 닫혀요
핵심 문제 기억해요: 에이전트를 통해 아키텍처 결정을 내리면 즉각적인 피드백 루프를 잃어요. 몇 주 뒤까지 자신이 맞는지 측정할 수 없어요.
Intent의 답: 그걸 전체 프로덕트로 만들어. 지연성을 숨기려고 하지 말고. 파고들어. 스펙이 계약이에요. 에이전트들이 스펙에 맞춰 만들어요. 검증이 계약이 맞는지 증명해요.
이게 실제로 우아해요. 당신의 결정들이 좋은지 모르고 날고 있는 대신 다음을 얻어요:
- 영구적인 실행 가능한 산출물 (스펙)
- 에이전트 팀이 그쪽으로 일하기 (coordinator + specialists + verifier)
- 성공 증명 (스펙 대비 검증)
아키텍처 결정에 대한 유닛 테스트 같아요. 테스트를 짜고 (스펙), 에이전트가 뭔가 만들고, 테스트가 통과 또는 실패.
검증 갭에 계속 신경 썼던 저한테 이건… 사실 흥미로워요. 검증뿐이 아니라 자동 검증이에요. 스펙이 테스트예요. 통과 또는 실패.
비용
명백한 트레이드오프가 있어요: 구현에서 오는 우연한 배움을 잃어요.
코드를 직접 만들 때 언어, 프레임워크, 이디엄을 배워요. 엣지 케이스를 만나서 시스템이 어떻게 동작하는지 배워요. 디버거에 앉아서 직관을 키워요.
Intent로는 스펙을 작성해요. 에이전트가 만들어요. 당신이 검증해요. 코드 라인 0의 배움.
Su라면 괜찮다고 할 거예요 — 당신은 IC가 아니라 오케스트레이터예요. 당신의 일은 더 나은 스펙을 쓰고, 더 나은 아키텍처 결정을 만들고, 더 똑똑하게 검증하는 거예요. 배움이 구현이 아니라 결정에 이동해요.
하지만 실제 스킬 갭이 있어요. 스펙을 쓰는 게 코드 짜는 것보다 어려워요. 에이전트가 만들기 전에 당신이 뭘 원하는지 명확하게 생각해야 해요. 대부분 개발자들은 경력을 코드로 생각하는 법 배우며 보냈어요. Spec-first 사고는 다른 근육이에요.
Intent는 그 전환을 강제하는 게 좋다고 내기하고 있어요. Spec-first + 에이전트 실행 + 검증이 코드 우선 + 수동 구현보다 더 나은 빌드 방식이에요.
맞을 수도 있어요. 또는 피아니스트한테 오케스트라 지휘하라고 하는 것처럼. 완전히 다른 스킬.
당신한테 이게 뭘 의미하는지
Intent가 광고한 대로 동작하면, IDE가 실시간으로 죽는 걸 보는 거예요.
“IDE가 사라진다”는 의미가 아니에요. “코드 에디터로서의 IDE는 진부했다”는 의미예요. IDE의 핵심 가치는 코드 짜기 좋은 장소였어요. 에이전트가 짜면 그 가치는 사라져요.
Intent의 대체물: 스펙 오케스트레이션 플랫폼. 의도를 지정하고, 에이전트가 실행하고, 당신이 검증하고 반복해요. 전체 플라이휠이 스펙 ↔ 에이전트 ↔ 검증.
이게 Su가 예측한 모든 걸 가속화해요. 스크립트보다 더 복잡한 뭔가를 에이전트로 만든다면, 당신 일은 코딩이 아니에요. 다음이에요:
- 정확한 스펙 작성
- 에이전트 팀 오케스트레이션
- 결과 검증
- 의도에 대한 반복
이 스킬을 배워요. Intent가 암시하는 게 더 이상 선택이 아니니까. 일이에요.
진짜 질문
질문은 Intent가 프로덕트로 성공할지가 아니에요. IC 역할이 완전히 전환되는 게 맞는지예요.
맞을 수도 있다고 생각해요. 근데 동시에 Intent 스타일 개발자의 첫 세대는 불운할 거라고 생각해요 — Spec-first 사고를 어렵게 배우고 있는 동안 그 다음 세대는 스펙이 주 산출물이라고 예상하면서 자라날 거 같아요.
오늘 에이전트로 뭔가 만들고 있으면 당신이 불운한 세대예요. 그냥 의도적으로 파고들어요.
이건 AI 에이전트로 만드는 시리즈를 계속하고 있어요: 배움은 어디로 갔을까, 두 가지 분석 접근법, 사람의 역할. Intent는 이 전환의 프로덕트 끝점을 대표해요.