'AI한테 맡겼더니 됐어요'와 'AI랑 같이 만들었어요'는 결과물이 비슷해 보여도 과정이 완전히 다르다. 요즘 AI 코딩 에이전트를 둘러싼 논의도 정확히 이 지점에서 갈린다. 코드를 빠르게 뽑아내는 도구로 쓸 것인가, 아니면 사용자 가치를 함께 설계하는 동반자로 키울 것인가. 세 가지 실전 사례가 이 질문에 각기 다른 각도로 답을 내놓고 있다.
에이전트가 IDE 밖으로 나간 대가
dev.to에 공개된 AgentBridge 실험은 불편한 사실 하나를 짚는다. 현재 AI 코딩 에이전트의 주류 작동 방식—파일 읽기, 텍스트 수정, 셸 명령 실행—은 개발자가 실제로 일하는 방식과 괴리가 있다는 것이다. IntelliJ 같은 풀 IDE에서 작업할 때 개발자는 편집과 동시에 피드백을 받는다. 타입 오류, 미사용 임포트, 정적 분석 경고가 코드를 입력하는 순간 화면에 뜬다. 이 '즉각 피드백 루프'가 바로 fail-fast 개발의 핵심이다.
그런데 대부분의 에이전트는 이 루프 밖에서 작동한다. 파일을 수정하고, 다음 작업으로 넘어가고, 나중에 별도 검사를 돌린다. AgentBridge가 문제로 지적하는 장면은 구체적이다. 에이전트가 기능을 구현하고, 나중에 자신이 쓴 코드를 리뷰하다가 경고를 발견하고, 원래 의도와 무관하게 동작을 바꾸는 방식으로 '수정'해버린다. 경고는 잡혔지만 맥락은 이미 사라진 뒤다. 에이전트에게 IDE 수준의 피드백이 tool response 안에 바로 담겨야 하는 이유다.
이 논점은 단순히 IntelliJ 플러그인 이야기가 아니다. MCP가 'AI 애플리케이션을 외부 시스템에 연결하는 USB-C 포트'로 자리잡고 있는 지금, 에이전트가 어떤 인터페이스를 통해 도구를 쓰느냐가 에이전트가 할 수 있는 일의 천장을 결정한다는 테제다. LSP 수준의 심볼 검색은 시작이고, IDE가 이미 알고 있는 PSI(Program Structure Interface)—타입, 참조, 리팩토링 충돌—를 에이전트가 직접 쓸 수 있어야 한다는 것. 함수 이름 하나를 바꿀 때 LLM이 코드베이스를 텍스트로 뒤지게 하는 건, 이미 정답을 알고 있는 도구를 놔두고 짐작으로 푸는 것과 같다.
사용자 문제가 먼저, 코드는 그다음
dev.to에 올라온 또 다른 사례는 스펙트럼의 반대편을 보여준다. 한 개발자가 하루 반 만에 아들을 위한 한자 학습 게임을 만든 이야기다. 흥미로운 건 결과물이 아니라 과정이다. 에이전트에게 첫 번째로 던진 질문이 '코드 짜줘'가 아니었다. '유아 한자 학습에 관한 최신 교육심리학 연구', '프리스쿨러에게 적합한 기억 학습 이론', 'PAW Patrol IP의 서사 구조'—이렇게 세 가지 리서치였다.
이 접근은 프로덕트 사고를 에이전트 워크플로우에 이식한 사례로 읽힌다. 에이전트가 한 시간 동안 리서치를 돌린 결과, 개발자 본인의 가정 여러 개가 틀렸음이 드러났다. 중국 교육부 커리큘럼이 2016년에 이미 파닌(병음) 우선에서 한자 우선으로 전환했고, 유아가 한자 하나를 익히는 시간은 초등학생의 서너 배라는 데이터가 나왔다. 이 인사이트가 게임 메커니즘 설계 전체를 바꿨다. 스페이스드 리피티션 기반의 '3단 버킷' 구조, PAW Patrol 에피소드의 반복 공식을 레벨 디자인에 활용하는 방식이 리서치에서 나왔다.
에셋 파이프라인도 흥미롭다. 별도 에이전트가 YouTube에서 원본 에피소드 오디오를 추출하고, ASR로 대화를 분리하고, 비전 모델로 각 클립의 캐릭터를 식별하고, TTS로 인게임 보이스를 생성하는 전체 파이프라인을 스스로 설계했다. 중간에 개발자가 '어떤 캐릭터가 화면에 나오는지 직접 알려달라'는 요청을 받았을 때 에이전트는 접근을 스스로 바꿨다—ASR로 텍스트 먼저 뽑고 비전 모델로 정렬하는 방식으로. 이건 단순 자동화가 아니라 에이전트가 제약을 인식하고 플랜을 재설계하는 모습이다.
에이전트를 직접 만든다는 것의 의미
세 번째 사례는 Claude Agent SDK로 TypeScript 코드 리뷰 에이전트를 처음부터 구축하는 과정이다. 핵심 구조는 단순하다. model → tool calls → results → model 루프를 stop_reason === 'end_turn'이 나올 때까지 반복한다. 개발자가 직접 루프를 소유한다는 것이 중요하다. 재시도 정책, 반복 횟수 상한, 에러 처리—모두 개발자 코드 안에 있다.
이 아키텍처가 드러내는 시사점이 있다. Tool description을 얼마나 잘 쓰느냐가 에이전트 품질에 직접 영향을 미친다. Claude는 description을 읽고 언제, 어떻게 툴을 쓸지 결정한다. 즉 tool description은 프롬프트의 일부다. 또한 대규모 코드베이스를 다룰 때는 토큰 예산 관리가 필수다. 메시지 배열이 누적되면 컨텍스트 윈도우가 빠르게 찬다. 파일을 배치로 처리하거나 중간 결과를 요약하는 전략이 없으면 에이전트가 도중에 멈춘다.
더 근본적인 지점은 '에이전트를 직접 만든다'는 행위 자체가 프로토타이핑 방식을 바꾼다는 것이다. 특정 SaaS 에이전트 플랫폼에 갇히지 않고, 도메인에 맞는 툴셋과 루프 논리를 직접 설계할 수 있다. 교육 게임 사례의 에셋 파이프라인처럼, 문제의 구조를 먼저 파악하고 에이전트 아키텍처를 거기 맞추는 것이 가능해진다.
에이전트를 신뢰 가능하게 만드는 세 가지 조건
세 사례를 교차하면 패턴이 보인다. 첫째, 피드백 루프의 속도. IDE-native 에이전트가 주장하는 것처럼, 에이전트가 편집 직후 오류를 인식할 수 있어야 한다. 나중에 별도 검사가 아니라, tool response 안에 즉각 피드백이 담겨야 에이전트의 reasoning이 맥락을 유지한다. 둘째, 도메인 리서치를 워크플로우 앞단에 배치하는 습관. 코드부터 짜는 게 아니라 문제 구조를 먼저 탐색하게 시키면 에이전트의 산출물 방향 자체가 달라진다. 셋째, 루프의 소유권. 에이전트를 블랙박스로 쓰는 것과 루프를 직접 설계하는 것 사이에는 통제 가능성의 차이가 있다. 재시도, 비용 상한, 에러 격리—이것들을 직접 코드로 갖고 있어야 에이전트가 예측 가능하게 작동한다.
앞으로 무엇이 달라지나
에이전트가 '코드 생성기'에서 '개발 동반자'로 격상되는 조건은 모델 성능 개선만이 아니다. 에이전트가 접근하는 인터페이스의 품질—IDE의 시맨틱 모델, 도메인 리서치, 명확하게 정의된 툴셋—이 함께 높아져야 한다. 동시에 개발자가 에이전트에게 어떤 문제를 어떤 순서로 주느냐, 즉 워크플로우 설계 역량이 새로운 핵심 역량이 된다. 에이전트는 이미 잘 정의된 문제를 놀라운 속도로 푼다. 문제를 잘 정의하는 일은 여전히 사람 몫이고, 그게 점점 더 중요해지고 있다.