3주 만에 새 모델이 나오고, 하룻밤 사이에 오픈소스 에이전트 프레임워크가 공개된다. 2026년 여름의 코딩 에이전트 시장은 말 그대로 전국시대다. 선택지가 많아진 건 좋은 일이지만, 기준 없이 흐름에 휩쓸리면 워크플로우만 복잡해지고 생산성은 제자리다. 지금 동시에 벌어지고 있는 세 가지 움직임—딥시크 하니스의 오픈소스 선언, 구글 제미나이 3.7 플래시의 가격 파괴, Claude Code의 자율화 명령어—을 프로덕트 사고로 읽어보면, 도구 선택의 기준이 비로소 보인다.
딥시크 하니스: 오픈소스로 진입장벽을 무너뜨리는 전략
딥시크가 공개한 '하니스(Harness) v0.1'은 단순한 코딩 보조 도구가 아니다. 자체 개발한 '코디스(Cordis)' 메타 프레임워크 위에서 "모든 것은 플러그인이다(Everything is a Plugin)"라는 철학으로 설계된 에이전트 프레임워크다. 모델, 도구, 스킬, 샌드박스, 실행 루프, UI까지—구성 요소 전체를 플러그인으로 교체하고 조합할 수 있다. npx @deepseek-ai/dsh web 한 줄이면 당장 실행해볼 수 있고, MIT 라이선스로 전체 코드가 공개됐다.
업계에서 이 발표를 앤스로픽의 Claude Code를 정조준한 도전으로 읽는 이유가 있다. 지금까지 코딩 에이전트 시장은 Claude Code, OpenAI Codex처럼 폐쇄형·상용 제품이 주도해왔다. 딥시크는 이 구도에서 '오픈소스 + 플러그인 아키텍처'라는 무기를 꺼내들었다. 특정 벤더에 종속되지 않고, 서드파티 개발자가 생태계를 직접 확장할 수 있는 구조를 만들겠다는 것이다. 저비용 오픈웨이트 모델로 폐쇄형 LLM 시장에 균열을 낸 딥시크의 플레이북이 코딩 에이전트 영역에서 반복되는 셈이다.
그러나 지금 당장 프로덕션에 쓰기엔 이르다. 저장소에는 "호환성이 깨지는 변경사항이 있을 수 있다"는 경고가 명시돼 있다. 개발자 프리뷰 단계라는 뜻이다. 프론트엔드 실무에서 하니스를 선택할 실질적인 타이밍은 아직 아니다. 하지만 플러그인 생태계가 성숙하는 속도를 지켜보며 '언제 넘어갈 것인가'를 미리 판단 기준으로 세워두는 것은 충분히 의미 있는 일이다.
제미나이 3.7 플래시: 가성비 모델이 에이전트 경제학을 바꾼다
구글이 3.6 플래시 출시 3주 만에 공개한 제미나이 3.7 플래시는 속도 경쟁의 민낯을 보여준다. 구글은 이 모델을 "코딩과 에이전트 작업에 특화된 가장 지능적인 워크호스 모델"이라고 소개했다. 숫자가 이를 뒷받침한다. 디버깅·이슈 해결 능력을 측정하는 DeepSWE v1.1 벤치마크 점수가 3.6 플래시의 49.0%에서 3.7 플래시의 65.3%로 뛰었다. 3주 사이에 16퍼센트포인트가 오른 것이다.
더 주목할 건 가격이다. 입력 토큰 100만 개당 0.75달러, 출력 토큰 100만 개당 3.75달러—직전 모델 출시 가격의 절반이다. 코딩 에이전트를 대규모로 운용할 때 토큰 비용이 가장 큰 변수 중 하나라는 점을 고려하면, 이 숫자는 단순한 가격 정책이 아니라 에이전트 경제학의 판을 흔드는 결정이다. 여러 태스크를 병렬로 돌리거나, 긴 컨텍스트를 자주 다뤄야 하는 프론트엔드 자동화 파이프라인에서 모델 선택의 무게중심이 이동할 수 있다.
다만 한 가지 신호는 눈여겨봐야 한다. 구글이 오랫동안 예고해온 플래그십 모델 '제미나이 3.5 프로'는 아직 출시되지 않았다. 경량 모델의 잦은 업데이트로 실사용 저변을 빠르게 넓히는 전략이 최상위 모델 개발의 지연을 가리고 있는 건지, 아니면 실제로 경량 모델에서 충분한 성능을 뽑아낸 자신감의 표현인지—이 맥락은 3.7 플래시를 실무에 투입하기 전에 한 번 따져볼 필요가 있다.
Claude Code의 /goal과 /loop: 자율화는 설계가 먼저다
새 모델이 쏟아지는 외부 경쟁과 별개로, 지금 가장 많은 프론트엔드 개발자의 일상 워크플로우에 직접 파고드는 도구는 여전히 Claude Code다. 그리고 그 안에서 제대로 활용되지 않고 있는 명령어가 있다—/goal과 /loop다.
두 명령어는 언뜻 비슷해 보이지만 작동 원리가 완전히 다르다. /loop는 시간을 기준으로 반복을 제어한다. 크론 잡처럼 "N분마다 이 프롬프트를 실행해라"는 식이다. /goal은 조건을 기준으로 반복을 제어한다. "이 문제가 완벽히 해결될 때까지 멈추지 마라"는 해결사에 가깝다. /goal의 핵심은 실행 모델과 평가 모델의 분리에 있다. AI가 스스로 "다 했다"고 착각하는 것을 막기 위해, 별도의 독립된 평가 모델(기본적으로 Haiku 같은 작은 모델)이 대화 기록을 검토해 목표 달성 여부를 판정한다.
실제로 /goal에 "이 폴더의 pytest 테스트가 모두 통과할 때까지"라는 조건을 주면, Claude는 별도 지시 없이 코드를 수정하고 테스트를 실행하고 에러를 확인하는 과정을 스스로 반복해 목표를 달성한다. 여기에 /loop 1m을 결합하면, 평소엔 대기하다가 tasks.md에 새 할 일이 추가되는 순간 스스로 처리하는 자동화 파이프라인이 된다. 구조적으로 완성도 높은 에이전트 루프를 CLI 레벨에서 설계할 수 있다는 뜻이다.
단, 설계 없이 쓰면 독이 된다. /goal의 평가 모델은 대화 기록에 남은 텍스트만 보고 판단한다—파일을 직접 열거나 코드를 실행할 수 없다. 따라서 "코드를 예쁘게 고쳐줘" 같은 모호한 조건이 아니라, "pytest 실행 결과가 에러 없이 0으로 떨어질 때까지"처럼 기계적으로 검증 가능하고 대화창에 결과가 출력되는 조건을 줘야 한다. 완전한 무인 실행을 위해 Auto mode를 켜는 것은 그다음 단계다—초기엔 기본 모드로 사람이 지켜보는 것이 안전하다.
선택 기준은 '무엇을 자동화할 것인가'에서 시작한다
세 가지 흐름을 한 줄로 정리하면 이렇다. 딥시크 하니스는 '언젠가 쓸 오픈소스 옵션'으로 레이더에 올려두되 지금 당장 프로덕션에 투입할 수준은 아니다. 제미나이 3.7 플래시는 토큰 비용에 민감한 대규모 에이전트 파이프라인에서 즉시 검토할 만하다. Claude Code의 /goal + /loop 조합은 지금 당장 실무에 적용할 수 있는 가장 구체적인 자율화 레버다.
하지만 이 중 무엇을 고르든, 가장 먼저 답해야 할 질문은 도구가 아니라 태스크다. '어떤 반복 작업을 에이전트에게 넘길 것인가', '완료 조건을 기계적으로 정의할 수 있는가', '자율 실행이 사고로 이어질 때 복구 비용은 감당할 수 있는가'—이 세 가지를 먼저 설계하지 않으면, 전국시대의 선택지는 기회가 아니라 소음이 된다. 코딩 에이전트가 강해질수록, 개발자의 역할은 더 좋은 도구를 찾는 것이 아니라 더 명확한 조건을 설계하는 것으로 이동하고 있다.