Intent: 코드를 안 보여주는 IDE

AI 네이티브 개발 도구 회사인 Augment가 Intent를 공개했습니다. IDE라는 도구가 본질적으로 무엇이어야 하는지를 매우 과감하게 다시 해석한 제품입니다.

이 도구에는 코드 에디터가 없습니다.

파일 탐색기도, 문법 강조도, 탭 분할도, 심지어 터미널 열기 버튼조차 없습니다. 화면 전체가 오직 하나의 핵심 사이클을 위해 설계되어 있습니다:

스펙(의도) 작성
에이전트 팀의 분업과 실행
결과물 검증

이게 전부입니다. 개발자는 코드를 들여다보지 않고 기계가 그 코드를 직접 소화합니다.

올 한 해 내내 뜨겁게 이어져 온 논쟁의 극단적인 귀결점인 셈입니다. Phillip Su는 AI 에이전트의 등장으로 개별 실무자(IC)의 역할이 끝났다고 보았고, 저 역시 검증의 공백에 대해 적은 바 있습니다. 즉각적인 구현 피드백이 사라진 의사결정은 공허해지기 쉽다는 이야기였습니다.

Intent는 아예 코드 레벨의 의사결정을 인터페이스에서 덜어내는 방식으로 이 문제에 답합니다. 사람이 코드를 치거나 읽을 필요 없이, 명확한 스펙으로 에이전트 군단을 지휘해 시스템을 구축하도록 만듭니다.

Intent가 실제로 하는 일

공개된 제품 설명에서 눈에 띄는 특징들을 추려 보면 이렇습니다:

살아있는 스펙(Living Specs). 에이전트가 작업을 마칠 때마다 스펙이 실시간으로 갱신됩니다. 요구사항이 바뀌면 현재 일하고 있는 모든 에이전트에게 변경사항이 즉각 전파됩니다. 스펙 문서 자체가 단일 진실 공급원이자 자체 유지보수되는 시스템이라 “우리가 지난번에 뭘 결정했더라?” 하고 헤맬 일이 없습니다.

에이전트 오케스트레이션. 조율자(Coordinator) 에이전트가 스펙을 작은 하위 태스크로 분해합니다. 전문화된 에이전트들이 이를 병렬로 실행하고 검증자(Verifier)가 스펙과 결과물을 비교 대조합니다. 조율자는 이 전체 흐름이 어긋나지 않도록 정렬을 맞춥니다.

단일 통합 작업창. 결과물을 바로 확인할 수 있는 내장 브라우저와 커밋 및 브랜치 관리를 위한 Git 연동을 한 화면에 품었습니다. IDE, 터미널, 웹 브라우저 사이를 정신없이 오가는 컨텍스트 스위칭을 없앴습니다.

이어하기 가능한 세션. 작업을 닫았다가 다음 날 다시 열어도 직전 상태가 그대로 유지되며, 자동 커밋이 단계별 완료 상태를 차곡차곡 기록합니다.

제품 설계 전반이 개발 생태계의 변화를 가감 없이 인정합니다: 이제 개발의 병목은 코딩 자체가 아닙니다. 어떤 결정을 내리고, 어떻게 의도를 명시하며, 에이전트를 어떻게 조율할 것인가가 핵심입니다. 인터페이스는 이를 냉정할 만큼 충실하게 구현하고 있습니다.

이게 무엇을 의미하는가

Intent의 지향점은 개발자가 코드를 더 잘 짜도록 돕는 것이 아니라, 코드를 아예 만지지 않도록 만드는 데 있습니다.

기존의 Copilot이나 Claude Code 같은 도구와는 결이 완전히 다릅니다. 기존 도구들은 여전히 사람이 주연이고 AI는 옆에서 거드는 보조자 역할을 전제합니다. 반면 Intent는 주객을 뒤집습니다. 실제 행동의 주체는 에이전트이며 사람은 전체 판을 짜는 지휘자가 됩니다.

개발자는 코드를 짜는 대신 의도를 작성합니다. 버그를 쫓으며 디버깅하는 대신 결과를 검증합니다. 코드를 한 줄씩 쌓아가며 시스템 구조를 몸으로 익히기보다, 시스템에 대한 내 설계 판단이 옳았는지를 가늠하는 작업에 집중하게 됩니다.

이는 Phillip Su가 말한 “IC의 종말”이라는 화두가 제품 레벨에서 구현된 모습입니다. 에이전트의 생산성을 극대화하기 위해 실무자가 매니저의 일로 이동해야 한다면, 전통적인 코드 에디터가 달린 IDE를 굳이 유지할 이유가 없다는 논리입니다. 스펙을 입력하고 에이전트의 작업을 지휘하는 제어판만 주어지면 충분합니다.

검증 루프가 닫히는 새로운 방식

제가 이전 글에서 짚었던 핵심 고민을 떠올려 봅니다. 에이전트를 통해 시스템을 만들다 보면 손끝으로 전해지던 즉각적인 피드백 루프가 끊겨 버리고 내 결정이 정말 옳았는지를 확인하기까지 긴 시차가 생깁니다.

Intent의 해결책은 그 시차 자체를 제품의 핵심 구조로 인정하고 정면 돌파하는 것입니다. 피드백 지연을 억지로 감추려 하지 않습니다. 스펙은 엄격한 계약서가 되고, 에이전트는 계약대로 물건을 만들며, 검증 시스템은 계약이 제대로 이행되었는지를 증명합니다.

이 구조는 꽤 정교합니다. 막연한 감에 의존해 내 결정의 유효성을 점치는 대신, 다음과 같은 단단한 장치를 쥐게 되기 때문입니다:

영구적이고 실행 가능한 산출물(스펙)
이를 향해 일사불란하게 움직이는 에이전트 조직(조율자, 전문가, 검증자)
명확한 통과 여부를 가르는 성공 증명(스펙 대비 검증)

마치 아키텍처 의사결정을 위한 단위 테스트 체계를 구축한 모양새입니다. 사람이 테스트(스펙)를 작성하면 에이전트가 구현을 해내고 테스트의 통과 여부가 판가름 납니다.

검증의 공백 때문에 고민하던 제 입장에서도 이 방식은 대단히 흥미롭습니다. 자동화된 검증 체계를 제품의 근간으로 삼았기 때문입니다.

지불해야 하는 대가

하지만 얻는 것이 있으면 잃는 것도 분명합니다. 직접 구현하면서 자연스럽게 얻던 우연한 배움이 증발합니다.

코드를 직접 한 땀 한 땀 작성할 때는 언어의 미묘한 문법, 프레임워크의 내부 동작, 자주 쓰이는 관용구가 자연스럽게 체화됩니다. 예상치 못한 엣지 케이스를 만나며 시스템이 한계에 부딪히는 지점을 배우고 디버거를 붙잡고 씨름하면서 엔지니어링 직관이 단단해집니다.

Intent 환경에서는 스펙을 정의하고 에이전트의 산출물을 검증할 뿐입니다. 코드 라인 단위에서 오는 감각적 배움은 0에 수렴합니다.

Su의 관점이라면 이것 역시 자연스러운 진화라고 여길 것입니다. 이제는 실무자 대신 오케스트레이터의 자리에 섰으니 더 선명한 스펙을 작성하고 더 현명한 아키텍처를 결정하는 데 집중하면 된다는 논리입니다. 배움의 영역이 구현에서 의사결정으로 이동했다는 이야기입니다.

그러나 현실적인 역량의 간극은 여전히 큽니다. 사실 스펙을 빈틈없이 쓰는 것은 코드를 짜는 것보다 훨씬 높은 수준의 추상적 사고를 요구합니다. 에이전트가 코드를 만들기 전에 내가 진짜로 원하는 것이 무엇인가를 머릿속에서 완벽하게 시뮬레이션해야 하기 때문입니다. 대부분의 개발자는 코드를 치면서 생각을 구체화하는 훈련을 받아왔습니다. 스펙 우선(Spec-first) 사고는 완전히 다른 근육을 쓰는 일입니다.

Intent는 이 전환을 강제하는 방식이 궁극적으로 더 낫다고 베팅하고 있습니다. 스펙 중심 설계와 에이전트 실행, 그리고 자동 검증의 결합이 코드 중심의 수동 구현보다 우월한 제작 방식이라는 믿음입니다.

이 베팅이 맞을 수도 있습니다. 혹은 피아니스트에게 갑자기 오케스트라 지휘봉을 쥐여준 것처럼, 전혀 다른 재능을 요구하는 일일 수도 있습니다.

우리에게 남겨진 과제

만약 Intent 같은 제품들이 시장에 안착한다면, 우리는 지금 전통적인 IDE가 저무는 과정을 목격하고 있는 셈입니다.

개발 도구 자체가 사라진다는 뜻이 아닙니다. “코드를 손으로 입력하는 텍스트 편집기”로서의 IDE가 수명을 다하고 있다는 뜻입니다. 에디터가 주던 가치는 무엇보다 코드를 타이핑하기 편한 환경이었습니다. 기계가 타이핑을 전담하는 순간 그 가치는 희석됩니다.

Intent가 제시하는 대안은 스펙 오케스트레이션 플랫폼입니다. 의도를 기술하고, 에이전트가 실행하며, 사람이 검증하고 개선하는 플라이휠(스펙 ↔ 에이전트 ↔ 검증)이 작업의 중심이 됩니다.

이는 Su가 예견했던 흐름을 한층 앞당깁니다. 단순한 스크립트보다 조금이라도 복잡한 시스템을 에이전트와 함께 만들고자 한다면 우리의 핵심 역량은 코딩에서 이런 영역으로 옮겨갑니다:

명확하고 빈틈없는 스펙 정의
에이전트 군단의 효율적인 역할 분담과 지휘
산출물의 정밀한 검증과 피드백
의도의 지속적인 반복과 정제

이 역량들을 의식적으로 길러야 합니다. Intent 같은 도구들이 보여주듯 이제 이것들은 부가 기술에 머물지 않고 개발자의 본업 그 자체가 되어가고 있기 때문입니다.

본질적인 질문

중요한 질문은 Intent라는 특정 프로덕트의 상업적 흥행 여부가 아닙니다. 개별 개발자의 역할이 이토록 급격하게 매니저나 오케스트레이터로 전환되는 방향이 과연 옳은가 하는 점입니다.

그 방향이 맞을 수도 있습니다. 다만 Intent 스타일의 개발 방식을 처음 맞이하는 지금 세대의 엔지니어들은 꽤 험난한 과도기를 건너야 할 것입니다. 코드로 사고하던 습관을 억지로 내려놓고 스펙 우선의 사고방식을 어렵게 학습해야 하기 때문입니다. 반면 다음 세대의 개발자들은 처음부터 스펙을 1급 산출물로 다루며 자라날 것입니다.

오늘날 에이전트를 적극적으로 도입해 제품을 만들고 있다면 우리는 바로 그 과도기의 첫 세대입니다. 피할 수 없다면 끌려가기보다 의식적으로 이 변화를 받아들이고 훈련하는 편이 낫습니다.

AI 에이전트로 제품을 만드는 고민을 담은 글들: 배움은 어디로 갔을까, 두 가지 분석 접근법, 사람의 역할. Intent는 이 개발 패러다임 전환의 가장 선명한 제품적 종착점을 보여줍니다.