JetBrains는 Igor Kulakov가 작성한 자료에서 IntelliJ IDEA 2026.2 안에서 Logpoint를 사용해 실행 중인 Java 애플리케이션의 오류를 진단하는 실용적인 방법을 소개한다. 이 방식은 프로그램에 println 문을 추가하는 것과 비슷하지만, 코드를 수정하거나 애플리케이션을 다시 빌드하거나 재배포할 필요가 없으며 실행도 중단하지 않는다. 따라서 로컬에서, Docker 컨테이너 안에서 또는 원격 호스트에서 실행되는 서비스를 검사하는 데 적합하다.
예제가 다루는 문제
예제는 gRPC를 통해 통신하는 클라이언트와 서버를 기반으로 한다. 서버가 일부 테넌트에 잘못된 할인 값을 반환한다. JetBrains 테넌트와 EMEA 리전에 관한 요청을 보내면 콘솔에 discount_bps=0인 100.00달러의 가격이 표시되지만, 예상값은 discount_bps=2000인 80.00달러다.
서버는 리스닝 포트와 디버깅을 노출한 상태로 Docker를 사용해 실행되며, 클라이언트는 주기적으로 요청을 보낸다. 서버와 클라이언트를 실행한 뒤에는 로컬 디버깅 세션에서 시작되지 않은 프로세스에도 IntelliJ IDEA 디버거를 연결할 수 있다. 설명에 따르면 디버거는 로컬 상황, 분리된 환경 및 원격 호스트에서 소켓을 통해 통신하므로 Java 프로세스가 실행되는 위치가 달라도 연결 원리는 달라지지 않는다.
Logpoint는 오류의 원인을 어떻게 밝혀내는가?
IntelliJ IDEA 2026.2에서는 실행 가능한 두 줄 사이의 편집기 여백을 클릭한 다음 기록하려는 표현식을 입력하는 방식으로 더 빠르게 Logpoint를 만들 수 있다. 개발자는 요청 처리 초기부터 정보를 기록하기 시작한 뒤, 요청이 계속 들어오는 동안 점진적으로 포인트를 추가하거나 수정한다.
호출 체인을 추적하면 discountBpsFor() 함수에 도달한다. 출력 결과는 테넌트 이름이 JetBrains 형식으로 전달되는 반면 비교 로직은 jetbrains 값을 예상한다는 사실을 보여준다. 또한 출력 결과는 할인이 적용되지 않았음을 보여주는데, 이는 2,000 베이시스 포인트를 반환하는 코드 분기가 실행되지 않았다는 뜻이다. 예제에서는 equalsIgnoreCase를 사용해 비교를 수정한 다음 예상 동작을 테스트할 것을 제안한다.
이점은 콘솔에 텍스트를 표시하는 데 그치지 않는다. 출력 결과의 한 줄을 클릭하면 IntelliJ IDEA가 해당 Logpoint 또는 연결된 코드 부분으로 이동할 수 있다. 프로세스가 IntelliJ IDEA 디버거에서 실행 중이라면 이 탐색은 println 문에서도 작동한다.
println과 중단점보다 유리한 경우
자료는 Logpoint가 코드를 오염시키지 않으며, 실수로 프로덕션 환경에 전송될 수 있는 디버깅 문을 남기지 않는다고 설명한다. 또한 무엇을 언제 기록할지 변경할 수 있다. 여기에는 반복되는 이벤트의 샘플링, 종속성 내부에 로깅 추가, 비용이 큰 재배포 방지가 포함된다.
반면 기존 중단점은 서비스 중단 자체가 문제의 일부일 때 적합하지 않을 수 있다. 예제에서 클라이언트는 gRPC 요청에 시간 제한을 설정하며, 이 시간 제한은 서버로 전달될 수 있다. 디버거가 서버를 중단하면 시간 제한이 만료되고 요청은 취소 경로로 넘어가므로, 개발자는 오류를 일으킨 상태를 더 이상 확인할 수 없다. 이때 중단점을 사용하려면 요청을 하나씩 보내고 시간 제한 범위 안에서 작업해야 한다.
반대로 Logpoint는 서버를 일시 중지하지 않고 정보를 제공하므로 요청이 실행되는 동안 요청을 관찰하고 시간 제한 만료로 발생하는 취소 경로의 활성화를 피할 수 있다.
실행 중 동작을 일시적으로 수정하기
자료는 Logpoint를 사용해 수정 또는 동작 변경의 효과를 일시적으로 테스트하는 방법도 보여준다. 다만 Logpoint는 기본적으로 기록을 위한 기능이지 애플리케이션을 변경하기 위한 기능은 아니라는 점에 주의해야 한다. 부작용이 있는 표현식을 사용하면 실행 중에 gRPC 라이브러리 내부의 시간 제한 값을 수정할 수 있다. 예제에서는 timeoutNanos를 5분의 시간 제한으로 변경한다.
이 변경의 영향을 줄이기 위해 Debug 헤더가 있는 요청에만 적용하고 나머지 요청에는 일반적인 시간 제한을 유지할 수 있다. 예제에는 헤더를 읽고 그 값이 일치할 때만 시간 제한을 재설정하는 여러 줄 로직이 포함되어 있으며, 분기를 실제로 방문했는지 확인하기 위해 Timeout reset 메시지도 표시한다.
무엇을 주의해야 하는가?
JetBrains는 핫 패스에 무거운 계산을 넣지 말라고 경고한다. 로깅 표현식은 가상 머신 자체에서 실행되므로 시간 측면에서 비용이 없지 않기 때문이다. 또한 IntelliJ IDEA 2026.2가 instrumentation으로 인해 디버거가 유발하는 부하를 제거한다고 설명하지만, 그렇다고 표현식이나 과도한 로깅의 비용까지 사라지는 것은 아니다.
자료는 표현식 필드에서 임의의 객체에 접근하기 위해 Mark Object 기능을 사용할 수 있다는 점도 언급한다. 또한 첨부된 ij-debugger 인공지능 에이전트 스킬은 시간 제한을 읽는 위치를 찾고 테스트 요청을 대상으로 하는 표현식을 만들 수 있다. 하지만 이 방법은 수동으로 이해하는 과정을 대체하는 수단일 뿐이며, 일시적인 수정이 모든 환경에서 안전하다는 증거는 아니다.
certi.news의 편집자 견해
여기서 실질적인 가치는 새로운 종류의 로그 메시지를 추가하는 데 있지 않고, 실행 중 수정할 수 있는 계층으로 진단을 옮기는 데 있다. 이는 원격 서비스나 경쟁 상태 또는 시간 제한이 있는 서비스에서 특히 중요하다. 실행을 중단하면 문제 자체가 숨겨질 수 있기 때문이다. 반면 이 방식은 표현식을 신중하게 선택하고 비용을 모니터링해야 하며, 동작을 수정하기 위해 부작용을 사용하는 방법은 명확하고 일시적인 디버깅 시나리오로 제한해야 한다. 이를 소스 코드 수정의 대안으로 바꿔서는 안 된다.