운영자가 보는 라이브러리 내부 코드

트랜잭션 트레이스를 들여다보다 보면, 가끔 모르는 클래스가 호출 스택에 떠 있을 때가 있습니다. com.fasterxml.jackson.databind.ser.std.NumberSerializer$Long 같은 이름이 나타나면, "이게 왜 여기서 응답 시간 200ms를 잡아먹고 있지?" 하고 잠깐 멈추게 됩니다.

이런 순간 가장 확실한 답을 얻는 방법은 그 클래스를 직접 들여다보는 것입니다. 다행히 Java는 .class 파일을 다시 사람이 읽을 수 있는 형태로 복원할 수 있는 구조를 가지고 있습니다.

이 글에서는 운영자가 디컴파일을 실무에서 어떻게 활용하는지 중심으로 살펴봅니다. 왜 가능한지, JD-GUI로 어떻게 확인하는지, 그리고 운영 중 어떤 순간에 실제로 도움이 되는지까지 함께 정리해보겠습니다.

‍

Java가 디컴파일 가능한 이유

운영 중에는 소스 코드를 직접 확인할 수 없는 상황이 더 많습니다. 그래서 라이브러리 내부 동작을 확인하려면 디컴파일이 사실상 유일한 방법이 되는 경우가 많습니다.

Java 라이브러리는 .class 파일 형태로 배포됩니다. 그리고 Java는 이 바이트코드를 다시 사람이 읽을 수 있는 형태로 복원할 수 있습니다.

운영자 입장에서 중요한 점은 하나입니다.

소스가 없어도 라이브러리 내부를 직접 확인할 수 있는 방법이 있다는 것

‍

JD-GUI로 .class 들여다보기

JD-GUI는 가장 널리 쓰이는 GUI 기반 Java 디컴파일러입니다. Windows·Linux·macOS 모두 지원하며, 다운로드 후 바로 실행할 수 있습니다.

→ http://java-decompiler.github.io/

기본 흐름은 단순합니다. (설치는 간단하니 바로 사용하는 흐름만 보면 됩니다)

1. JD-GUI 실행
2. 파일 → JAR 열기로 분석할 라이브러리 선택
3. 패키지 트리에서 클래스 클릭
4. 디컴파일된 Java 코드 확인

핵심은 JAR 파일만 있으면 내부 코드를 바로 확인할 수 있다는 점입니다.

소스가 없을 때의 기본 상태

소스가 없으면 IDE에서는 이런 식으로 바이트코드만 보이게 됩니다.

이 상태에서는 사람이 읽기 어렵고, 실제 동작을 파악하기 힘듭니다.

‍

JD-GUI로 확인하면

JD-GUI를 사용하면 위와 같이 Java 코드 형태로 바로 확인할 수 있습니다.패키지 구조와 클래스 관계까지 함께 볼 수 있어, 라이브러리 동작을 빠르게 이해할 수 있습니다.

‍

운영에서 디컴파일이 필요한 3가지 순간

운영자가 디컴파일을 알아두면 좋은 이유는 개발이 아니라 장애 상황에서의 속도입니다.

1. APM 트레이스에 모르는 라이브러리 클래스가 보일 때

트랜잭션 트레이스를 따라가다 보면 자체 코드가 아닌 라이브러리 메서드가 병목으로 잡히는 경우가 있습니다.

이때 메서드 이름만으로 동작을 추측하기 어렵다면, 해당 JAR을 JD-GUI로 열어 메서드 내부를 직접 확인하는 것이 가장 빠른 방법입니다.

락을 잡고 있는지, 외부 호출이 있는지 확인하면 다음 조치로 바로 이어집니다.

2. 보안 취약점(CVE) 영향 범위 확인

보안 취약점(CVE)이 공개되면 가장 먼저 드는 질문은“우리 서비스도 영향받는가?”입니다.

하지만 실제 운영에서는 단순히 라이브러리 버전만으로 판단하기 어려운 경우가 많습니다.

같은 버전이라도 특정 메서드 호출 경로에서만 취약점이 발생하거나,실제 서비스 코드에서는 해당 기능을 전혀 사용하지 않는 경우도 있기 때문입니다.

이럴 때 디컴파일을 통해 실제 코드 흐름과 호출 구조를 직접 확인하면,영향 범위를 훨씬 빠르게 판단할 수 있습니다.

문서상으로는 안전해 보여도 실제로는 취약 경로를 타고 있었던 경우도 있고,반대로 버전만 보고 급하게 교체했지만 실제 영향은 거의 없었던 경우도 운영에서는 자주 발생합니다.

3. 서드파티 SDK 동작 검증

결제, 인증 같은 외부 SDK가 예상과 다르게 동작할 때, 문서만으로는 답이 안 나오는 경우가 많습니다.

이럴 때는 디컴파일을 통해 실제 동작을 직접 확인하는 것이 가장 빠릅니다.

‍

디컴파일의 한계: 난독화된 코드

‍

난독화된 JAR도 디컴파일은 가능합니다. 하지만 코드 가독성은 크게 떨어집니다.

• 클래스명: a, b, c
• 변수명: 의미 없는 문자열
• 흐름은 보이지만 이해는 어려움

즉,

디컴파일은 가능하지만 항상 이해 가능한 것은 아니다

‍

JD-GUI 사용 시 알아둘 점

• Java 8 람다 표현식은 일부 정확하지 않을 수 있습니다
• 난독화된 코드의 가독성은 낮습니다
• 디컴파일된 코드는 원본과 완전히 동일하지 않을 수 있습니다
• 다시 컴파일하려면 원본 의존성이 필요합니다

‍

마치며

운영 환경에서 디컴파일은 매일 쓰는 도구는 아닙니다.

하지만 한 번 필요할 때는 다른 방법으로 대체하기 어렵습니다.

결국 운영에서 중요한 건

“어디서 느린가”를 넘어서 “그 코드가 실제로 무엇을 하는가”까지 얼마나 빠르게 이어지냐입니다.

트레이스에서 모르는 클래스가 잡히는 순간,

그 코드가 실제로 무엇을 하는지 빠르게 확인할 수 있으면 문제 해결 속도는 크게 달라집니다.

👉 이런 상황을 바로 확인하고 싶다면 와탭 APM에서 트랜잭션 흐름을 직접 확인해 보세요.

‍

더 읽을거리

• 와탭 애플리케이션 모니터링 소개
• 스타트업이 TPS 지표를 봐야 하는 순간 — APM 운영의 가장 첫 지표 한 가지