푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 1000편 · 1 / 100 페이지)
-
CarterPerez-dev/Cybersecurity-Projects 살펴보기 — 흐름 수집 다음에 무엇을 붙여 볼까
-
신호 세기와 클러스터 반응을 같은 시계로 — 무선 노드 3대에 붙인 측정기, 첫 1시간
홈랩 K3s 클러스터 6대 중 3대(louise·isagal·solomon)는 일부러 무선으로 둔다. 무선 IoT 조건에서 쿠버네티스 노드가 어떻게 버티는지 보려는 연구용 설정이다. 그런데 지금까지 쓴 무선 글(dBm 은 링크 품질이 아니다, RSSI 4점 실측과 변동성)은 전부 그 순간 한 번 잰 값이었다. 신호가 흔들릴 때 클러스터가 실제로 어떻게 반응하는지는 같은 시계 위에 올려 본 적이 없다.
-
Packetbeat 흐름 수집 3일 파일럿 — 초록불 말고 카나리로 판정하기
홈랩 K3s 클러스터의 워커 노드 1대에 Packetbeat 를 붙여 3일 동안 돌렸다. 목적은 하나다. 이 노드가 외부의 어느 주소·포트와 언제 얼마나 주고받았는지를 연결 단위로 남기는 것이다. 사고가 났을 때 “정말 밖으로 나갔나”에 답할 증거를 만들려는 것이다.
-
Jev 는 Claude Code·Codex 의 모델이 될 수 없다 — 그래서 하네스의 어디에 꽂히는가
“Codex·Claude Code 에 Jev 를 붙인다” 는 말을 들으면 흔히 모델을 Jev 로 바꾼다를 떠올린다. 하지만 그건 구조적으로 안 된다. Jev 는 글을 쓰지 않기 때문이다. 이 글은 Jev 가 코딩 에이전트 하네스의 어느 자리에 들어갈 수 있는지, 그리고 커뮤니티 구현들이 그 자리를 어떻게 설계했는지를 1차 문서와 README 기준으로 정리한다.
-
Omarchy — DHH 가 만든 '에이전트가 고치는' 리눅스는 왜 생겼나
공식 사이트: omarchy.org · 소스: github.com/omacom/omarchy (MIT)
-
인텔리제이 AI Assistant 잘 쓰는 법 — 규칙 파일·.aiignore·에이전트·MCP·크레딧까지
JetBrains AI Assistant 는 이제 “채팅 창 달린 자동완성 플러그인” 이 아니다. 공식 문서의 정의부터 바뀌었다 — AI 기능 묶음 + 코딩 에이전트 다(About AI Assistant). 채팅 창을 열면 기본값이 채팅이 아니라 에이전트 이고, 그 에이전트 자리에는 JetBrains 의 Junie 말고도 Claude Agent · Codex · GitHub Copilot 이 들어간다(AI Chat, Activate agents).
-
DataGrip AI 잘 쓰는 법 — 권한 4단계, 읽기 전용 계정, 요청 로그로 확인하기 (2026.2 기준)
DataGrip 의 AI 는 2026년 들어 성격이 바뀌었다. 예전에는 “SQL 을 설명하고 고쳐 주는 버튼”이었다. 2026.1 에서 AI 채팅 안에 Claude Agent 와 Codex 가 들어왔고(What’s New 2026.1), 2026.2 에서는 데이터베이스 전용 에이전트 스킬 세 개와 연결 관리 MCP 도구가 추가됐다(DataGrip 2026.2 블로그, 2026-07-16). 에이전트가 실제 커넥션에 쿼리를 날리는 도구가 된 것이다.
-
Jira Rovo AI 잘 쓰는 법 — 기능 지도, 실전 요령, 크레딧 함정
Jira 에 들어간 아틀라시안의 AI, Rovo는 기능이 많다. 그래서 오히려 “요약 버튼 한 번 눌러보고 끝”으로 끝나기 쉽다. 이 글은 아틀라시안 공식 문서만 근거로 세 가지를 정리한다. ① Rovo 가 Jira 안에서 실제로 할 수 있는 일, ② 결과를 좋게 만드는 요령, ③ 2026년 12월부터 돈이 되는 크레딧 구조.
-
깃헙 코파일럿 잘 쓰는 법 — 도구 고르기·지시문·클라우드 에이전트·리뷰·과금
GitHub Copilot 은 이제 자동완성 하나가 아니다. 인라인 제안, IDE 채팅(에이전트 모드 포함), GitHub 위에서 혼자 브랜치를 파고 PR 을 올리는 클라우드 에이전트, PR 코드 리뷰, CLI 가 한 구독에 묶여 있다. 그리고 2026-06-01 부터 개인 요금제의 과금 단위가 “프리미엄 요청 횟수” 에서 토큰 기반 AI 크레딧 으로 바뀌었다12.
-
GitHub Docs, “Usage-based billing for individuals” (AI 크레딧·요금제별 할당). https://docs.github.com/en/copilot/concepts/billing/usage-based-billing-for-individuals ↩
-
GitHub Docs, “Requests in GitHub Copilot (legacy)” (2026-06-01 이후 연간 요금제 잔류자, 코드 리뷰 배수 13). https://docs.github.com/en/copilot/concepts/billing/copilot-requests ↩
-
-
멀티 에이전트, 언제 이기고 언제 지는가 — 안트로픽·코그니션 논쟁과 구글·버클리의 실측
에이전트 하나로 부족하면 여러 개를 붙이면 된다는 직관은 강합니다. 사람도 팀으로 일하니까요. 그런데 2025년 6월, 같은 주에 두 회사가 정반대 제목의 글을 냈습니다. 안트로픽은 멀티 에이전트로 리서치 기능을 만든 방법을 공개했고, 코그니션(Devin 개발사)은 “Don’t Build Multi-Agents”를 냈습니다. 이 글은 이 논쟁을 출발점으로 삼습니다. 그리고 이후 나온 통제 실험(구글 리서치)과 실패 분류 연구(UC 버클리)로 “언제 이기고 언제 지는가”를 정리합니다. 사실에는 출처를 달았고, 제 해석은 (해석)으로 표시했습니다.