Hacker News 의견
  • 오랫동안 고객 관리를 하는 Django 사이트가 있음, 고객이 자주 아주 작은 수정 요청을 하는데, 그럴 때마다 시스템 실행부터 코드 확인, 커밋, 푸시, 서버 업데이트 등으로 한 시간씩 소요됐음, 지난주에 Railway로 전체 인프라를 옮기고 고객에게 Jules 사용법을 알려줌, 이제는 고객이 직접 PR을 생성하고 Railway가 변경사항을 반영한 환경을 띄워서 직접 확인함, 대략 75%는 문제없이 작동하고, 안 될 때는 고객이 먼저 깨닫게 됨, 고객이 변경사항에 만족하면 그때 내가 코드 리뷰 후 머지 작업을 하는 방식으로 바뀜, 정말 엄청난 시간 절약 효과를 보고 있음

    • 고객에게 예전과 같은 금액을 계속 청구하는지 궁금함

    • API 사용료가 궁금함, 설정이 제대로 되지 않으면 고객이 사소한 수정을 여러 번 테스트하면서 요금이 과도하게 나올 걱정이 있음

    • 고객 앱에서 사용자 데이터를 저장하지 않기만을 바람, LLM을 무조건 신뢰하는 것은 위험하다고 생각함

    • 고객 데이터베이스 관리는 어떻게 하는지 알고 싶음, 전체를 VM에 업로드하는지 궁금함

    • 솔직히 정말 멋진 접근법이라고 생각함, 이 경험을 예시와 함께 블로그 글로 소개해주면 좋겠음, 특히 고객이 PR에 요청하는 구체적인 예시가 궁금함

  • 개인적으로 MCP 서버를 구축해서 Jules API에 연결해 사용 중이며, Copilot Chat in VS Code에서 Jules로 작업을 전송하는 방식임
    시연 영상

    • 이미 copilot을 쓰고 있다면 copilot coding agent를 그대로 쓰는 게 훨씬 낫다고 생각함, 개인적으로 Jules는 시장에서 최악의 코딩 에이전트임
  • 이런 에이전트를 사람들이 비동기적이고 감독 없이 믿고 사용하는지 의문임, 내 경험상 코딩 에이전트는 기대 수익보다 번거로움과 잡음이 더 많았던 기억임, 그냥 VS Code에서 쓰던 루프랑 비슷하다면 굳이 외부 도구를 쓸 필요가 있나 생각하게 됨

    • 이런 코딩 에이전트가 기대만큼 ROI를 주지 않는다는 의견에 대해, 시야를 길게 봐야 의미가 있다고 생각함, 당장 한두 개의 작업이나 몇 주치만 본다면 투자할 가치가 없지만 3년 뒤 엔지니어링팀의 워크플로우를 생각한다면 지금부터 이런 시스템을 도입해보는 것이 의미 있다고 봄, 예를 들어 봇이 라이브러리 업데이트시 자동으로 환경을 띄우고, 테스트하고, 코드베이스가 왜 동작하지 않는지 식별하고, 수정까지 해서, 사람에게 리뷰용 PR까지 만들어주는 자동화가 너무 유용하다고 생각함

    • 외부 도구 대신 VS Code처럼 통합으로도 할 수 있는데 굳이 외부 도구를 왜 쓰냐는 질문에, 개인 컴퓨터에 사진, 이메일, 브라우저 쿠키 등 민감 데이터가 있어서, 에이전트가 분석 작업을 내 로컬에서 실행하는 게 불편했음, 그래서 Jules에게 내 GitHub 프로젝트만 접근하게 하는 게 더 안전하게 느껴졌음, 실제로 Gemfile 읽고 Rails 테스트 실행까지 해줘서 유용했음, 코드 품질은 완벽하지 않았지만 기능 개발 시작에 도움을 많이 받았음

    • 내가 직접 경험해보니, 적어도 GitHub copilot과 비교하면 외부(클라우드) 환경에선 자동 승인 및 샌드박스에서 작동해서 더 깔끔하게 느껴졌음

    • 실제 사용해보면 계속 신경 써서 봐줘야 함

    • 참고로 VS Code는 에이전트가 아니라 코드 생성/자동완성 기능 중심임

  • Google이 Jules에 틀린 시스템 설계를 선택한 것이 아쉬움, Claude Code 쪽 시스템 디자인이 현 시점에선 훨씬 우수하다고 생각함, 결국 Jules가 또 하나의 벤더 락인 및 폐쇄적 생태계로 변할 것 같음

    • (전형적인 Google 스타일로) 둘 다 만든다고 생각함, 오픈소스 Gemini cli도 있는데, 꽤 넉넉한 무료 티어가 있어서 Claude code와 더 직접적으로 경쟁함
      https://github.com/google-gemini/gemini-cli
      런칭 때는 좀 거칠었지만 지금 많이 나아졌음, Claude code도 많이 발전해서 결국 갈아타진 않았음

    • 나처럼 Aider 초기 시절부터 AI 코딩 에이전트 활용해본 입장에서는 이야기 다름, 비동기 에이전트와 협력형 에이전트 모두 각자의 역할이 있다고 봄, 앞으로 협력형 에이전트가 비동기 에이전트 여러 개에 위임하고 결과를 합치는 방식이 나올 수도 있음, 생각보다 디자인 스페이스가 훨씬 복잡하고 우리는 아직 살짝 쿼터 밖에 못 본 상황임, 인간 중심 워크플로우에 억지로 AI를 끼워 맞추고 있으니, AI만의 특이하고 재밌는 가능성을 충분히 실험해볼 필요가 있다고 느낌

    • Jules와 Claude Code의 비교 자체가 적절하지 않다고 생각함, 두 시스템은 완전히 다름, Jules와 비교할 상대는 오히려 OpenAI Codex임, Claude Code의 Google 버전은 Gemini Code Assist CLI임

    • 비교하자면 Jules는 GitHub Spark와 더욱 닮았다고 생각함

  • workspace 사용자 지원이 10월 이후에 제공된다는 메시지에, 왜 항상 유료 사용자가 뒤로 밀리는지 이해할 수 없음, 매우 이상한 일임

    • 이렇게 하는 이유는 workspace가 보장하는 데이터 규정 준수를 확보해야 하기 때문이라고 이해함, 최신 기능이나 신기술보다는 비즈니스에 필수적인 지원, 컴플라이언스, 보장에 대한 대가라고 생각함

    • 유료 사용자는 기능을 빨리 원하는 게 아니라, Audit Trail, 규정 준수, SLA, 관리자 콘솔 연동 같이 한 발 늦더라도 안전하게 들어오는 걸 원함, 변동성도 적고 검증된 프로세스를 선호함, 오히려 workspace 계정을 개인용도로 쓰다가 릴리즈가 느리다고 불평하는 사람이 많던데, 20년째 이런 패턴이고 바뀌지 않을 것임, 빠른 기능을 원하면 개인용 Gmail 계정을 추천함

  • 의미 없는 인명(anthropomorphized) 브랜드 네이밍이 짜증남, 지금은 Amazon Rufus 같은 사례가 특히 심하다고 생각함, 차라리 Google Wave 같이 제품의 속성과 의미를 상징하면 낫겠음

    • Jules라는 이름은 Jenkins에서영감을 받은 것 같았음

    • Claude는 Claude Shannon에서 온 것임, Google Wave는 비록 흥하지는 못했지만 그 아이디어의 미래가 매우 필요했다고 생각함

    • 이런 네이밍에 너무 신경 쓸 필요 없다는 입장임, 인간이 기계나 물건에 이름을 붙이고 애정을 갖는 건 본능임, 예전부터 배, 기차, 총, 차, 심지어 AI에도 인간 이름을 붙여왔고, 1966년 Eliza 때부터 이미 시작된 전통임, 멈출 수 없으니 마음 편하게 받아들이길 바람

  • rust/go와 같은 단일 바이너리 실행파일로 돌아가고 싶음, nodejs 기반 cli는 설치가 번거로워서 불만임

    • Discord가 피드백 수단이라는 게 더 불편함, 회사에서 Discord가 차단되어 있어서 사용 불가능함
  • 이 프로젝트에 구글에서 몇 명이 참여하는지 궁금함, 나는 비슷한 기능을 가진 툴을 사내에서 단독으로 개발 중이고, 개인 시간(퇴근 후, 주말)에 작업하는 입장임

    • 왜 개인 시간을 들여 고용주를 위해 만드는지 궁금함, 실질적으로 본인 돈을 주주에게 기부하는 셈임
  • Jules와 Claude Code의 가격 비교 자료가 있는지 궁금함, 최근에는 비용 절감을 위해 repl.it에서 Claude max로 옮겼음

    • replit은 약간 실험적인(vibe) 코딩용이고, Claude Code는 진짜 개발 작업용이라는 점에서 서로 완전히 다른 제품으로 보임