# JetBrains IDE 감지 기능 추가 제안

> Clean Markdown view of GeekNews topic #26075. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=26075](https://news.hada.io/topic?id=26075)
- GeekNews Markdown: [https://news.hada.io/topic/26075.md](https://news.hada.io/topic/26075.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-01-24T04:32:53+09:00
- Updated: 2026-01-24T04:32:53+09:00
- Original source: [github.com/google-gemini](https://github.com/google-gemini/gemini-cli/issues/16728)
- Points: 1
- Comments: 2

## Topic Body

- 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**에서 영감을 받은 것

## Comments



### Comment 50459

- Author: roxie
- Created: 2026-02-02T15:21:58+09:00
- Points: 1

번역된 해커뉴스 댓글들이 대체 무슨 말을 하는건지 한참 어리둥절 하다가,   
  
링크 속 PR 을 자세히 들여다보니 답이 나왔네요. GN+ 에게는 조금 버거운 이슈였던걸로 ㅋㅋㅋ

### Comment 49825

- Author: neo
- Created: 2026-01-24T04:32:53+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46721179) 
- 페이지 중간에 **“4609 remaining items”** 라는 문구가 있었음  
  gemini-cli 봇 두 개가 서로 자신이 아닌 다른 쪽이 라벨을 추가/삭제했다고 착각해, 서로 수정하려다 무한 루프에 빠진 상황이었음  
  이 저장소에는 장기 기여자가 약 10명 정도 있는데, 모두 이메일 알림을 받는다고 가정하면 하루 만에 **46,000통의 이메일**이 발송된 셈임  
  또, [gemini-cli 앱 페이지](https://github.com/apps/gemini-cli)를 보면 개발자가 개인 계정으로 되어 있어 공식 Google 프로젝트는 아닌 듯함  
  그렇다면 이 모든 **inference 비용**은 누가 낸 걸까 하는 의문이 생김
  - 이런 일은 이번이 처음이 아님. 꽤 자주 반복되는 문제로, 관련 이슈들이 여러 개 있음  
    [#16723](https://github.com/google-gemini/gemini-cli/issues/16723), [#16725](https://github.com/google-gemini/gemini-cli/issues/16725), [#16732](https://github.com/google-gemini/gemini-cli/issues/16732), [#16734](https://github.com/google-gemini/gemini-cli/issues/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달러 하는 거다”라고 농담했음
  - 관련 스레드는 [여기](https://news.ycombinator.com/item?id=46636291)에 있음

- 나는 이 스크립트의 작성자임 :-)  
  두 개의 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 라우팅 설정** 같은 곳에서도 벌어질 것 같음  
  앞으로 정말 **흥미로운 시대**가 올 것 같음