AI로 줄인 분석 시간, 검증까지 포함해도 줄었을까?

답변은 끝났는데, 분석도 끝난 걸까?

LLM에게 기술자료를 조사해 달라고 하면 답변은 빠르게 나옵니다. 생소한 용어를 풀어주고, 관련 문서를 정리하고, 긴 설명을 보고서에 넣을 만한 문장으로 바꿔줍니다. 예전 같으면 여러 문서를 오가며 읽었을 내용을 한 화면에서 살펴볼 수 있습니다.

그런데 답변을 읽다가 멈추는 순간이 있습니다.

“이 결론은 무엇을 확인하고 쓴 걸까?”

최근 Oracle WebLogic 취약점을 조사하면서 이 질문을 여러 번 떠올렸습니다. 8월 패치에서 다뤄진 취약점과 T3·IIOP 프로토콜, 원격 명령 실행과 관련된 공개 분석 및 알려진 exploit 자료를 이해하는 과정에 LLM을 활용했습니다. 프로토콜이 어떤 역할을 하고, 왜 필요한지 설명을 정리하는 데에도 도움을 받았습니다.

다만 결과를 그대로 받아들이기는 어려웠습니다. 단순한 핸드셰이크 성공을 취약 가능성의 근거로 과도하게 해석하는 경우가 있었고, 반대로 443 포트에서도 T3 계열 연결이 가능한 구성을 설명에서 놓치는 경우도 있었습니다.

한쪽에서는 결론이 증거보다 앞섰고, 다른 쪽에서는 익숙한 기본값이 실제 구성을 가렸습니다. 둘 다 사람이 다시 확인해야 하는 지점이었습니다.

이 글은 제 작업 시간을 측정한 실험 보고서는 아닙니다. 실제로 몇 분을 절약했는지, 검증에 몇 분을 더 썼는지는 수치로 제시하지 않습니다. 대신 이번 경험을 통해 생긴 질문을 정리해 보려 합니다. AI가 초안을 빨리 만들어 준 시간과, 내가 책임질 수 있는 분석을 완성한 시간은 얼마나 다를까요?

 

WebLogic 조사에서 먼저 구분해야 했던 것

WebLogic은 기업용 Java 애플리케이션을 실행하는 애플리케이션 서버입니다. 웹 요청을 처리하는 HTTP·HTTPS뿐 아니라 원격 객체 호출을 위한 통신도 지원합니다. T3는 WebLogic의 독자적인 RMI 통신 프로토콜이고, IIOP는 서로 다른 환경의 분산 객체가 통신하기 위한 프로토콜입니다. 기능 자체가 취약점인 것은 아닙니다. 어떤 업무에 사용하고, 어느 범위에 노출되어 있으며, 해당 구현에 어떤 보안 문제가 있는지가 중요합니다. Oracle 프로토콜 문서

 

그림 1. Oracle 공식 문서를 바탕으로 재구성한 개념도입니다. 실제 조사 대상의 네트워크 구성이나 제품 관리 화면이 아닙니다.

Oracle은 2026년 8월 18일 Critical Security Patch Update(CSPU)를 발표했습니다. 해당 공지에는 WebLogic의 T3·IIOP 관련 취약점들이 포함되어 있습니다. 아래는 차이를 살펴보기 위한 일부 항목입니다. Oracle 발표

항목	관련 프로토콜	공격에 필요한 권한	CVSS 3.1	공식 공지의 영향 설명
CVE-2026-60672	T3, IIOP	인증 불필요	9.8	WebLogic 서버 장악 가능
CVE-2026-60696	T3, IIOP	인증 불필요	9.8	WebLogic 서버 장악 가능
CVE-2026-60702	T3, IIOP	낮은 권한 필요	9.9	WebLogic 서버 장악 및 다른 제품까지 영향 가능

출처: Oracle August 2026 Risk Matrices.

같은 달, 같은 제품, 같은 프로토콜로 묶여도 필요한 권한은 다릅니다. 점수가 더 높다고 인증 없이 악용된다는 뜻도 아닙니다. 공식 공지의 ‘서버 장악 가능’이라는 영향 설명과, 특정 환경에서 원격 명령 실행을 실제로 확인했다는 보고 역시 구별해야 합니다.

제가 조사한 범위에는 원격 명령 실행 관련 자료가 포함되어 있었지만, 이 글에서 개별 CVE의 명령 실행을 재현했다고 하는 것도 아닙니다. 공개 자료의 설명, 벤더가 명시한 조건, 대상 환경에서 확인한 사실은 각각 다른 정보입니다. 이 경계가 요약 과정에서 구분하기 힘들었습니다.

 

핸드셰이크 성공이 말해주는 범위

핸드셰이크는 통신을 시작하기 위해 필요한 초기 교환입니다. 관련 응답을 확인했다면, 해당 경로에서 프로토콜을 처리하는 서비스에 도달했다는 단서가 될 수 있습니다.

하지만 그 사실만으로 보안 패치가 빠져 있다거나, 특정 취약점의 조건이 성립한다거나, 원격 명령 실행이 가능하다는 결론까지 이어지지는 않습니다. 정상적으로 운영되고 패치된 서비스도 필요한 프로토콜에 응답할 수 있습니다.

이번에 LLM을 활용하면서 불편했던 부분은 그 중간이 생략되는 순간이었습니다. 관측은 초기 통신 응답인데 설명은 취약성 판단 쪽으로 빠르게 넘어갔습니다. “가능성이 있다”는 표현을 붙였더라도, 왜 그 가능성을 주장하는지 근거가 없다면 확인 부담은 그대로 남습니다.

그림 2. 각 칸은 서로 다른 확인 범위입니다. 왼쪽 사실이 확인되었다고 오른쪽 결론이 자동으로 성립하지 않습니다.

보고서 문장도 이 차이를 드러내야 합니다. 다음은 실제 로그 인용이 아니라, 표현의 차이를 보여주기 위한 예시입니다.

 

근거보다 앞선 표현: T3 응답이 확인되므로 원격 명령 실행 취약 가능성이 높습니다.

확인 범위를 드러낸 표현: T3 초기 응답을 확인했습니다. 이 응답만으로 특정 CVE의 영향 여부는 판단할 수 없으며, 제품·패치·설정 정보와의 대조가 필요합니다.

 

두 번째 문장은 마치 사용자가 지시한 프롬프트를 덜 이행한 것처럼 보입니다. 하지만 다음 사람이 무엇을 더 확인해야 하는지는 훨씬 분명합니다. 보안 분석에서 필요한 문장은 이런 쪽에 가깝다고 생각합니다.

또 하나 주의할 점이 있습니다. 판단을 위해 반드시 운영 환경에서 공격을 실행해야 하는 것은 아닙니다. 자산의 정확한 패치 정보와 벤더 공지를 대조하는 것만으로도 조치 필요성을 판단할 수 있습니다. 검증은 곧 exploit 실행이라는 등식도 경계해야 합니다.

 

443이라는 숫자가 설명을 좁히는 순간

반대 방향의 문제도 있었습니다. 443 포트는 HTTPS라는 익숙한 연상 때문에, 해당 포트에서 T3 계열 통신이 가능한 구성이 설명에서 빠지는 경우입니다.

포트 번호는 프로토콜을 강제하지 않습니다. WebLogic은 리슨 포트와 네트워크 채널을 구성할 수 있고, 일반 통신과 TLS로 보호하는 통신도 구분합니다. 실제 사용 프로토콜은 서비스 설정과 중간 장비의 전달 방식에 따라 달라집니다. Oracle 네트워크·프로토콜 설정

여기서 ‘443에서 T3가 가능하다’는 말도 다시 풀어 써야 합니다. 일반 T3인지 TLS로 보호된 T3S인지, HTTP(S) 터널링을 이용하는지에 따라 구성이 다릅니다. 이들을 같은 연결 방식으로 뭉뚱그리면 설명이 또 부정확해집니다. TLS를 쓴다는 사실만으로 그 안의 응용 프로토콜이 HTTP라고 확정할 수도 없습니다.

그렇다고 443을 서비스하는 모든 웹 서버가 T3를 받는다는 뜻은 아닙니다. HTTP(S)만 처리하는 구성도 있습니다. 제가 말하고 싶은 것은 포트 번호에서 출발한 추정과 실제로 확인한 구성을 구별해야 한다는 점입니다.

핸드셰이크 사례에서는 약한 증거를 크게 해석했고, 포트 사례에서는 흔한 구성을 유일한 구성처럼 좁혀 생각했습니다. 결국 과장된 주장만 찾는 검토로는 부족합니다. 설명에서 빠진 조건도 함께 살펴봐야 합니다.

 

절약한 시간 옆에, 다시 확인한 시간을 놓아보기

LLM은 빠르게 설명을 만들어 줬습니다. 그러나 저는 그 설명을 이해한 뒤에도 주장에 맞는 근거를 찾고, 누락된 조건을 확인하고, 최종 문장을 조정해야 했습니다.

이 과정이 있었다는 이유만으로 AI가 비효율적이었다고 결론 내릴 수는 없습니다. AI를 사용하지 않았어도 검증은 필요했을 것입니다. 중요한 것은 AI를 썼을 때의 검증 시간이 원래보다 줄었는지, 늘었는지, 그리고 결과의 품질은 같았는지입니다.

그림 3. 업무 시간을 기록하기 위한 개념도

 

저는 앞으로 AI 활용의 효과를 볼 때, 최소한 다음 항목을 나누어 보는 편이 좋겠다고 생각합니다.

기록할 항목	보고 싶은 것
맥락 준비	자료를 모으고 환경, 목표, 제약을 설명하는 데 든 시간
조사와 초안	자료를 읽고 설명이나 산출물을 만드는 데 든 시간
검증	출처 확인, 환경 대조, 중요한 주장 검토에 든 시간
수정과 인계	잘못된 결론을 고치고 다른 사람이 이해할 수 있게 정리한 시간
결과 품질	검토 후 남은 오류, 빠진 조건, 미확인 주장

같은 품질 기준에서 이 시간의 합을 비교해야 생산성을 말할 수 있습니다. 사용자가 집중해서 일한 시간과 결과를 기다린 경과시간도 구분할 필요가 있습니다. 여러 에이전트를 동시에 돌리면 각 실행시간을 더한 값이 내 노동시간과 같지 않기 때문입니다.

결과물이 길어지고 참고문헌이 많아졌다는 사실도 곧 성과는 아닙니다. 확인할 주장이 늘어났다면 검토 대상도 늘어난 셈입니다. 제게 더 유용한 답변은 문장 수가 많은 답변보다 중요한 주장을 적절한 근거와 연결해 주는 답변입니다.

 

체감 속도와 측정값이 다를 수 있다는 연구

이 질문을 생각할 때 참고할 만한 연구가 있습니다. METR은 2025년 2~6월의 AI 도구를 대상으로, 숙련된 오픈소스 개발자 16명이 수행한 246개 작업을 연구했습니다. 해당 조건에서 AI 사용 시 작업시간은 19% 늘었지만, 참가자들은 연구 후에도 AI가 시간을 20% 줄였다고 추정했습니다. METR 2025년 연구

그림 4. AI 미사용 대비 작업시간 변화율(%). 연구기간: 2025년 2~6월, 발표: 2025-07-10, 자료 확인: 2026-09-19. 체감값은 참가자의 사후 추정이며 측정값과 성격이 다릅니다. 저자의 WebLogic 작업시간이나 현재 모델의 성능을 나타내는 그래프가 아닙니다. 출처: METR 원문, 후속 설명.

다만 이 그래프만 보고 “AI를 쓰면 느려진다”고 결론 내리는 것도 제가 경계하는 과장과 다르지 않습니다. 특정 시기의 도구, 특정 개발자와 작업에서 얻은 결과입니다.

METR은 2026년 2월 후속 글에서, 새로운 실험에 참여자·작업 선택 편향이 생겼고 병렬 에이전트 사용 시 시간 측정에도 어려움이 있다고 설명했습니다. 생산성 개선 가능성을 언급하면서도 개선 폭을 신뢰성 있게 추정하기 어렵다고 밝혔습니다. METR의 연구 설계 변경 설명

제가 이 연구에서 가져오고 싶은 것은 하나입니다. 빨라졌다는 느낌은 중요한 경험이지만, 그 자체로 절약한 시간을 입증하지는 않습니다. 반대로 과거의 한 측정값으로 현재의 도구와 모든 업무를 평가해서도 안 됩니다.

 

 

모델이 좋아져도 남는 일

제가 느끼기에도 최근 모델은 과거보다 많이 나아졌습니다. 기술적인 설명을 이어가는 능력이나 복잡한 맥락을 정리하는 품질이 좋아졌습니다. 이번 경험이 LLM의 활용 가치를 부정하는 이유가 되지는 않습니다.

다만 성능이 좋아질수록 확인 방식도 달라져야 한다고 생각합니다. 눈에 띄는 엉뚱한 답변은 쉽게 걸러낼 수 있습니다. 전반적으로 매끄러운 설명 속에 한두 개의 잘못된 전제가 섞여 있으면 그 전제를 따로 찾아내야 합니다.

WebLogic 사례에서 “응답이 왔다”와 “취약하다” 사이의 간격, “443이다”와 “HTTPS만 가능하다” 사이의 간격이 그런 부분이었습니다. 전문용어가 자연스럽게 이어진다는 사실은 이 간격을 메워주지 못했습니다.

이를 보완하기 위해 앞으로는 답변의 형식부터 조금 바꿔 요청해 보려 합니다. 다음은 이번 경험을 바탕으로 정리한 검토용 요청 예시입니다.

답변을 ‘자료에서 확인한 사실’, ‘그 사실에서 도출한 추론’, ‘아직 확인하지 못한 조건’으로 나눠 주세요. 중요한 주장에는 직접 근거가 되는 문서와 해당 부분을 연결해 주세요. 포트 번호, 기본 설정, 초기 통신 응답만으로 보안 영향을 단정하지 말고, 현재 정보로 결론 내릴 수 없는 부분은 그대로 남겨 주세요.

 

이렇게 요청한다고 오류가 사라지지는 않습니다. 대신 사람이 검토할 지점을 찾아내기 쉬워질 수 있습니다. LLM에게 다른 답변을 검토하게 하는 것도 도움이 될 수 있지만, 두 모델이 동의했다는 사실만으로 독립적인 증거가 생기지는 않습니다. 같은 공개 자료나 전제를 공유했다면 같은 오류를 반복할 수 있습니다.

 

 

이번 경험에서 더 생각해 보게 된 것들

첫째, 검증 가능성도 답변의 품질입니다. 정확한 말이라도 출처와 조건을 다시 찾는 데 오래 걸린다면 실무 비용이 큽니다. 무엇을 근거로 말했는지, 어디까지 적용되는지를 짧게 확인할 수 있는 산출물이 더 쓸모 있습니다.

둘째, 오류에는 과장과 누락이 함께 있습니다. 사실이 아닌 위험을 크게 말하면 불필요한 대응을 만들 수 있고, 가능한 구성을 설명에서 빼면 점검 범위를 놓칠 수 있습니다. “틀린 문장이 있는가”와 함께 “필요한 조건이 빠졌는가”를 물어야 합니다.

셋째, 완료 기준을 먼저 정해야 시간을 비교할 수 있습니다. 문서 초안 생성이 완료인지, 근거 검토가 끝난 상태인지, 담당자가 조치 여부를 판단할 수 있는 상태인지에 따라 같은 작업의 종료 시점이 달라집니다. 제게 보안 분석의 완료는 적어도 중요한 결론의 근거와 남은 불확실성을 설명할 수 있는 상태에 가깝습니다.

넷째, 최종 책임은 사용자의 주의력만으로 감당할 문제가 아닙니다. 사용자가 마지막 판단을 맡는다면, 판단에 필요한 자료도 함께 남아 있어야 합니다. 중요한 주장에 대한 근거, 확인일, 적용 환경, 검토 여부를 기록하는 방식이 필요합니다. “사람이 마지막에 잘 봐야 한다”는 말보다, 사람이 실제로 검토할 수 있는 구조를 만드는 편이 현실적입니다.

 

 

내가 줄이고 싶은 것은, 책임질 수 있는 결론까지의 시간

이번 WebLogic 조사에서 LLM은 설명과 자료 정리를 도와줬습니다. 동시에 제가 다시 확인해야 할 과장과 누락도 보여줬습니다. 두 경험은 함께 있었습니다.

모델은 계속 좋아질 것입니다. 저도 앞으로 계속 활용할 생각입니다. 다만 초안이 완성된 순간에 분석까지 끝났다고 생각하지는 않으려 합니다. 최종 검증과 판단의 책임은 여전히 결과를 사용하는 사람에게 있습니다.

그래서 앞으로 AI가 얼마나 빨라졌는지를 이야기할 때는 질문 하나를 더 붙이고 싶습니다.

“그 시간에는, 내가 이 결론을 책임질 수 있게 되기까지의 확인도 포함되어 있을까?”

 

 

참고 자료

기술자료 확인일: 2026-09-19. WebLogic 항목은 2026년 8월 공지를 기준으로 비교했습니다. 실제 운영 조치에는 이후 공지와 환경별 패치 안내도 함께 확인해야 합니다.

1. Oracle — August 2026 Critical Security Patch Update 발표
2. Oracle — August 2026 CSPU Advisory
3. Oracle — August 2026 Risk Matrices, 상세 설명
4. Oracle — Domain Configuration: T3, IIOP 및 네트워크 설정
5. METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
6. METR — We Are Changing Our Developer Productivity Experiment Design, 2026-02-24