코파일럿 vs 에이전트

코파일럿은 다음 줄을 제안해요. 수락하거나 거부하면 됩니다. 코드를 쓰는 건 여전히 나예요.

에이전트는 달라요. "이 앱에 Google OAuth 추가해줘"라고 하면 — 파일을 만들고, 구현을 작성하고, 테스트를 실행하고, 에러를 고칩니다. 결과를 설명하면, 방법은 에이전트가 알아서 해요.

Claude Code, Cursor Agent, Devin — 이 도구들은 코드베이스를 읽고, 패턴을 이해하고, 여러 파일에 걸쳐 변경하고, 결과를 검증해요. 생산성 향상은 진짜입니다. 하지만 통제력을 잃는 위험도 진짜예요.

이해하는 것만 위임하라

이게 제가 따르는 규칙이에요. 틀릴 수도 있어요 — AI가 너무 빠르게 발전해서 아마 수정하게 될 겁니다. 하지만 지금은:

아키텍처 수준에서 이미 이해하고 있는 것만 AI에게 시키세요.

이미 코딩할 수 있는 것이 아니에요. 시스템 수준에서 이해하고 있는 것이요.

예를 들어볼게요. 최근에 라이브 카메라 스트리밍 기능을 만들어야 했어요. 카메라 하드웨어, RTSP 프로토콜, 모바일 앱에서의 실시간 비디오 표시. 이 중 어느 것도 해본 적 없었습니다.

에이전트에게 맡기고 기도한 게 아니에요. 질문부터 시작했어요:

• 비디오가 하드웨어 보드에서 어떻게 나오지?
• 실시간 스트리밍은 어떤 프로토콜을 쓰지?
• 앱이 스트림을 직접 받을 수 있나, 미디어 서버가 필요한가?

몇 시간 리서치 후에 머릿속에 아키텍처가 그려졌어요. 하드웨어에서 RTSP, 미디어 서버가 LL-HLS로 변환, 앱이 WebView로 소비. 그러고 나서 AI로 각 부분을 구현했습니다.

에이전트가 코드를 작성했어요. 하지만 코드가 뭘 해야 하는지, 각 컴포넌트가 왜 존재하는지는 제가 이해하고 있었어요.

규칙은 "모르는 걸 절대 위임하지 마라"가 아닙니다. "모른 채로 위임하지 마라"예요. 아키텍처를 먼저 배우세요. 그다음에 AI가 구현을 맡게 하세요.

제약이 에이전트를 더 좋게 만드는 이유

빈 디렉토리에서 작업하는 에이전트는 모든 걸 추측해요. 폴더 구조, 네이밍 규칙, 임포트 패턴, DB 접근 패턴. 각각은 괜찮을 수 있어요. 합치면 스스로와 싸우는 코드베이스가 돼요.

구조화된 프로젝트 안에서 작업하면 — 타입이 있는 스키마, 일관된 패턴, 정의된 규칙 — 시스템에 맞는 코드가 나와요. 제약은 제한이 아니에요. 아웃풋을 프로덕션 수준으로 만드는 거예요.

보일러플레이트가 더 이상 사람용 스타터 코드만이 아닌 이유가 여기 있어요. AI 에이전트를 신뢰할 수 있게 만드는 운영 환경이에요.

범용 vs 전문화

하나의 범용 에이전트는 유용해요. 전문화된 에이전트들이 함께 작업하면 더 유용합니다.

제가 도달한 접근법이에요. 도메인별로 분리된 에이전트. 계획 에이전트가 뭘 만들지 결정하고, 개발 에이전트가 코드를 쓰고, DB 에이전트가 스키마와 마이그레이션을 처리하고, 배포 에이전트가 인프라를 관리해요.

시스템이 작동하는 이유는 각 에이전트가 명확한 경계 안에서 운영되기 때문이에요 — 단일 에이전트가 더 똑똑해서가 아닙니다.