JetBrains IDE 감지 기능 추가 제안

• Gemini CLI에서 JetBrains IDE를 네이티브로 인식하도록 하는 기능 추가 요청
• 현재 CLI는 VS Code 등 특정 환경 변수(TERM_PROGRAM) 값만 허용해 JetBrains 사용자는 환경 변수를 속여야 기능을 활성화할 수 있음
• Windows와 Linux에서 프로세스 감지 실패 문제가 보고되어, 환경 변수 기반의 IDE 감지가 필요하다고 명시됨
• 제안된 변경은 IDE_DEFINITIONS에 JetBrains 시리즈 추가 및 TERMINAL_EMULATOR=JetBrains-JediTerm 인식 로직 포함
• Gemini CLI의 IDE 통합 범위를 확장하고 JetBrains 사용자 경험을 개선하기 위한 중요한 개선 요청임

---

JetBrains IDE 감지 기능 제안

• Gemini CLI에 JetBrains IDE 환경 인식 기능을 추가 요청하는 이슈가 등록됨
  • 기존에는 TERM_PROGRAM 값이 vscode 등으로 제한되어 JetBrains IDE에서는 기능이 자동 활성화되지 않음
  • 이를 우회하기 위해 JetBrains용 플러그인 사용자가 VS Code 환경 변수를 모방해야 했음
• 제안 내용은 JetBrains IDE 시리즈를 IDE_DEFINITIONS에 추가하고,
  TERMINAL_EMULATOR=JetBrains-JediTerm 값을 공식 지원 환경으로 인식하도록 수정하는 것

필요성 및 문제 배경

• Windows와 Linux 환경에서 프로세스 감지 기능이 정상 작동하지 않는 문제가 있음
  • 관련 사례는 JetBrains Plugin Review 페이지와 Gemini CLI의 이슈 #9273 등에서 확인
  • 여러 사용자 피드백과 이메일 보고를 통해 환경 변수 기반 감지 로직의 필요성이 있음

관련 논의 및 활동

• 이 제안은 이전의 PR #16083에서 영감을 받은 것

[GN⁺]

Hacker News 의견들

• 페이지 중간에 “4609 remaining items” 라는 문구가 있었음
  gemini-cli 봇 두 개가 서로 자신이 아닌 다른 쪽이 라벨을 추가/삭제했다고 착각해, 서로 수정하려다 무한 루프에 빠진 상황이었음
  이 저장소에는 장기 기여자가 약 10명 정도 있는데, 모두 이메일 알림을 받는다고 가정하면 하루 만에 46,000통의 이메일이 발송된 셈임
  또, gemini-cli 앱 페이지를 보면 개발자가 개인 계정으로 되어 있어 공식 Google 프로젝트는 아닌 듯함
  그렇다면 이 모든 inference 비용은 누가 낸 걸까 하는 의문이 생김

  • 이런 일은 이번이 처음이 아님. 꽤 자주 반복되는 문제로, 관련 이슈들이 여러 개 있음
    #16723, #16725, #16732, #16734
  • 저장소의 소유자는 Google 직원이지만, 안전을 위해 공식 Google 조직 계정으로 이전되어야 함
    GitHub의 앱 생성 프로세스가 현재는 개인 계정에서만 가능해 이런 문제가 생김
    조직 멤버에게 앱 생성 권한을 부여할 수 있도록 개선 작업이 진행 중이며, 6개월 내 우선순위로 처리 예정임
    결제 관련해서는 각 조직이 자신의 API 키를 GitHub Actions의 secrets에 넣어 사용하므로, inference 비용은 각 조직이 부담함
  • 내가 처음 만든 event-driven agent도 이런 버그를 겪었음
    봇이 자기 이름은 알지만, 그 이름이 사용자 ID로도 표시될 수 있다는 걸 몰라서 자기 자신을 인식하지 못했음
    에이전트가 세상을 이해하는 자기 인식 모델을 세심하게 설계해야 함
  • “Thank you for your understanding!” × 4609 라는 메시지가 반복된 셈임
  • “모두 제발 Reply-All 누르지 마세요.”
    이런 건 봇만의 문제가 아님, 사람도 자주 빠지는 함정임

• 예전에 우리 회사의 새로 온 “Salesforce 전문가”가 지원 큐를 개선한다며 만든 규칙이 있었음
  지원팀이 새 이메일을 받으면 Salesforce에서 티켓을 만들고, 티켓이 배정되면 다시 이메일을 보내는 식이었음
  결국 무한 알림 루프가 생겼고, 그는 실수를 인정하지 않아 원인을 찾는 데 한참 걸렸음

  • 나도 비슷한 경험이 있음. 고객의 헬프데스크와 우리 헬프데스크가 서로 자동 회신을 보내며 티켓 폭주 사태가 벌어졌음
    한 시간 동안 수백 개의 티켓이 생성되었음
  • Salesforce를 한 번 써봤는데, 왜 누가 이걸 좋아할지 이해가 안 됐음
    차라리 엑셀로 관리하는 게 낫겠다는 생각이었음
  • 학생 시절 이메일 서버에서 규칙을 장난으로 설정했다가, 학교 전체 서버를 다운시킨 사건이 있었음
    자동 회신 규칙이 서로 맞물려 수천 통의 메일이 쌓였고, 결국 로그인 시스템까지 마비됨
    6개월간 컴퓨터 사용 금지를 당했고, 이후엔 IT실에서 내 화면을 실시간으로 감시했음
    1년 뒤 또 문제가 생기자 IT팀이 내 교실로 뛰어와 나를 끌고 갔던 일화가 있음
  • “그 규칙을 어디에 숨겨놨는지 찾는 데 영원히 걸렸다”는 말에 완전 공감함
    Salesforce는 정말 괴물 같은 시스템임
  • 이런 이야기는 웃기면서도, 동시에 “어떻게 그럴 수 있지?”와 “그래도 이해는 간다”는 양가 감정이 듦

• 지난주에도 같은 저장소에서 비슷한 AI 봇 자기 논쟁 사건이 있었음
  누군가 “이래서 RAM이 800달러 하는 거다”라고 농담했음

  • 관련 스레드는 여기에 있음

• 나는 이 스크립트의 작성자임 :-)
  두 개의 GitHub Action 워크플로가 충돌했음
  (1) 특정 조건에서 need-triage 라벨을 제거하는 워크플로
  (2) 프로젝트 관리자가 아닌 사용자가 라벨을 제거하면 다시 추가하는 워크플로
  밤 10~11시에 제출하고 잤는데, 아침에 보니 수천 개의 메시지가 생성되어 있었음
  원인은 (2)에서 다른 봇이나 자동화도 예외로 처리해야 했다는 점이었고, 인지 후 즉시 수정했음

  • “밤 10~11시에 제출하고 잤다”는 부분이 너무 공감됨
    다행히 큰 피해는 없었고, 처음 봤을 때는 웃음이 터졌음

• Gemini-cli[bot]이 자기 자신과 싸우며 라벨을 추가했다 지웠다를 4600번 이상 반복한 사건임

  • 나는 날아다니는 자동차가 없는 건 아쉽지 않지만, 이런 미래의 어리석음에는 실망스러움

• 드디어 AI가 유용한 일을 한 사례임
  사람이 직접 4500번 라벨을 붙였다 뗐다 했다고 생각하면 끔찍함

  • 이제 GitHub 라벨러 직업군은 사라졌음
    AGI의 실용성이 증명된 셈임 (농담 반 진담 반)

• 여기서 실제로 AI가 개입한 건지 궁금함
  단순히 두 개의 자동화 규칙이 충돌한 것처럼 보임. 2015년에도 가능했던 버그 같음

  • 아이러니하게도, AI가 똑똑하다고 하지만 이런 루프를 인식하지 못함
    아직 AGI까지는 멀었음, 사실 AI 자체도 갈 길이 멂

• 전형적인 CI 버그에 LLM의 향기가 더해진 사례임
  우리도 몇 주 전 커스텀 머지 큐에서 비슷한 일이 있었음

  • “고전적인 CI 버그”라는데, 봇이 서로 대화 무한 루프에 빠지는 건 처음 들어봄
    예전 IRC 봇을 만들 때도 두 번째 단계가 “자기 자신에게 답장하지 않게 하기”였음
    그래서 이건 CI 버그라기보단 설계 실수에 가까움

• 이건 PR처럼 보이지만 사실 이슈 리포트임
  수정 패치는 어디 있나 했더니, 이 저장소는 모든 PR에 연결된 이슈를 요구하는 구조였음
  그런데 이번엔 둘이 연결조차 안 되어 있었음

• 이런 일이 머지않아 사회보장금, 암 치료 계획, 항공 물류, ISP 라우팅 설정 같은 곳에서도 벌어질 것 같음
  앞으로 정말 흥미로운 시대가 올 것 같음