Zed 1.0이 출시됐다. Rust로 처음부터 다시 쓴 GPU 셰이더 기반 편집기, 수십만 명의 일간 사용자, 그리고 'AI-native'라는 수식어. 단순한 버전 숫자가 아니다. Zed 팀은 AI를 기존 편집기 위에 얹은 플러그인이 아니라, 편집기의 기초 구조 안에 통합했다고 명시한다. CRDTs 기반 동기화 엔진 DeltaDB는 사람과 에이전트가 동시에 코드베이스를 수정할 때 단일한 맥락을 유지하게 설계됐다. Agent Client Protocol을 통해 Claude, Codex, Cursor 등 외부 에이전트를 연결하는 구조도 갖췄다. 이 흐름이 시사하는 건 하나다—에디터는 이제 더 이상 텍스트를 다루는 도구가 아니라, 에이전트 오케스트레이션 레이어로 진화하고 있다.
그런데 정확히 이 시점에 불편한 반론이 나온다. dev.to에 올라온 "Agentic Coding is a Trap"은 에이전트 코딩의 구조적 모순을 조목조목 짚는다. 핵심 논지는 이렇다: 에이전트가 생성한 수천 줄의 코드를 제대로 검토하려면 숙련된 비판적 사고가 필요한데, AI 도구의 과도한 사용이 바로 그 비판적 사고를 갉아먹는다는 것이다. Anthropic의 내부 연구조차 이 "감독의 역설"을 인정했다. LinkedIn 엔지니어링 디렉터 Sandor Nyako는 50명의 팀에서 이 현상을 직접 목격하고, 비판적 사고가 필요한 작업에는 AI 도구 사용을 자제할 것을 요청했다. 30년 경력의 Simon Willison도 에이전트가 만든 코드에 대해 "확실한 멘탈 모델이 없다"고 고백했다.
이 두 흐름이 충돌처럼 보이지만, 나는 오히려 같은 질문을 가리킨다고 읽는다. 도구가 강력해질수록 도구를 '어떻게 배치하느냐'가 개발자의 핵심 역량이 된다는 것. 세 번째 기사, SysMaster 개념이 여기서 유용한 프레임을 제공한다. 2000년대 초 웹마스터는 HTML, PHP, 서버 설정, 카피라이팅을 혼자 다뤘다. 그것이 가능했던 건 도메인이 좁아서가 아니라, 시스템 전체를 조망하는 판단력이 있었기 때문이다. LLM 시대의 SysMaster는 그 웹마스터가 오더 오브 매그니튜드의 레버리지를 얻은 버전이다. 문법과 보일러플레이트는 AI에 위임하되, 아키텍처 결정·기술 부채의 수용 범위·시스템 설계의 일관성은 여전히 사람의 판단 영역이다.
프론트엔드 개발자에게 이 구도는 더 직접적으로 와 닿는다. 빠른 프로토타이핑 → 사용자 검증 → 고도화라는 흐름에서, AI는 첫 번째 단계의 속도를 극적으로 높여준다. v0.dev로 컴포넌트 뼈대를 만들고, Zed의 에이전트 패널에서 로직을 붙이고, Cursor로 리팩토링하는 루프는 실제로 유효하다. 그런데 Agentic Coding is a Trap이 지적하는 것처럼, 이 루프를 맹목적으로 돌리다 보면 검증 단계에서 판단의 질이 서서히 떨어진다. Core Web Vitals 수치 해석, 컴포넌트 경계 설계, 접근성 구조 판단—이것들은 에이전트에 위임할 수 없는 영역이고, 아이러니하게도 에이전트를 더 많이 쓸수록 이 판단력이 무뎌질 수 있다.
그렇다면 설계해야 할 것은 무엇인가. 세 가지를 제안하고 싶다. 첫째, 에이전트에게 넘길 경계와 넘기지 않을 경계를 의도적으로 설정하는 것이다. 보일러플레이트, 반복적인 타입 정의, 테스트 케이스 초안은 에이전트 영역이다. 컴포넌트 계층 구조와 상태 설계는 직접 손으로 써보는 루틴을 유지해야 한다. 둘째, 코드 리뷰의 질을 설계하는 것이다. Zed의 DeltaDB처럼 에이전트가 만든 변경 이력을 추적하는 도구가 성숙해지고 있다. 에이전트가 PR을 올리는 팀이라면, 리뷰어가 "이 코드가 왜 이 구조인가"를 스스로 설명할 수 없다면 머지하지 않는 규칙이 필요하다. 셋째, 인지 부채를 모니터링하는 습관이다. 스프린트 회고에서 버그 발생 패턴을 추적하듯, "내가 직접 이해하지 못한 채 배포한 코드의 비율"을 팀 지표로 들여다볼 필요가 있다.
앞으로 에디터는 더 많은 에이전트를 더 깊이 통합할 것이다. Zed의 방향성이 그걸 명확히 보여준다. 이 환경에서 살아남는 개발자는 에이전트를 가장 잘 다루는 사람이 아니라, 에이전트가 만든 결과물을 시스템 수준에서 판단할 수 있는 사람이다. SysMaster라는 개념이 낭만적으로 들릴 수 있지만, 그 본질은 간단하다—판단을 위임하지 않는 것. AI 도구가 성숙기에 접어든 지금, 개발자가 설계해야 할 가장 중요한 환경은 자신의 판단력이 살아있을 수 있는 워크플로우다.