2026 해킹캠프에서 들은 것: OAuth와 LLM 에이전트, V8, SBOM, AI 하네스

2026년 8월 해킹캠프에서 들은 발표를 정리했습니다. 발표자분들의 내용을 제가 이해한 대로 적었고, 질의응답에서 제가 물어본 것도 함께 남겼습니다.

LLM에 로그인했더니 내 계정이 아니게 됐다 — 남현석

LLM에게 비밀번호를 직접 주면 권한이 너무 넓고 관리가 어렵습니다. 그래서 OAuth, API 키, PAT 같은 위임 방식을 쓰는데, 최근 LLM 에이전트가 OAuth로 API 권한을 위임받는 경우가 많아졌습니다.

OAuth: 제3자 앱에 제한된 API 접근 권한을 위임하기 위해 설계된 규격. 사용자 인증은 그 위의 OpenID Connect가 담당
흐름: 서비스가 client id와 redirect URL 제공 → 사용자가 로그인하고 권한 승인 → 인증 코드 발급 → 코드로 접근 토큰 요청 → 토큰으로 API 호출

지켜야 할 값이 많아질수록 구현 실수가 생기기 쉽습니다. 소개된 사례는 사용자가 연결한 메타데이터 URL과 실제 인증 서버 URL을 비교하지 않아, 악성 MCP 서버로 토큰이 넘어갈 수 있었던 취약점이었습니다. 지금은 불일치하면 OAuth 흐름을 중단하도록 고쳐졌습니다.

발표자분은 LLM으로 OAuth 취약점을 찾는 프로젝트를 했는데, 할루시네이션 때문에 결과를 그대로 믿을 수 없어서 결과보다 검증 과정을 잘 만드는 쪽으로 방향을 바꿨다고 했습니다.

제 질문: 에이전트가 요청한 수준 이상으로 사용자 권한에 접근하지 못하게 하는 통제가 있나요?
답: 지금은 파일 단위로 정확히 나누기보다 샌드박스나 "매번 물어보기" 설정 정도이고, 세밀하게 구분하는 방법은 아직 없는 것 같다.

그대들은 어떻게 살 것인가 (feat. V8 CTF) — 박도영

V8은 브라우저의 JavaScript 엔진이고, v8CTF는 V8 취약점으로 서버의 플래그를 가져오는 대회입니다. 발표에서는 객체 저장 방식이 fast에서 slow로 바뀌는 순간에 미리 계산해 둔 위치를 버리지 않아 범위 밖 쓰기가 생기는 버그를 따라가며, 샌드박스 안의 읽기·쓰기에서 샌드박스 밖까지 이어지는 과정을 설명했습니다. 원인은 인덱스 접근 사이에 다른 동작이 끼어드는 것이었고, 보완책은 그 사이의 검증 로직 추가였습니다.

앞으로의 목표로 AI 하네스를 통한 취약점 탐색 자동화 연구를 들었습니다. V8 공부를 시작하려면 C++, 동작 이해용 JavaScript가 기본이고, 관련 CTF 문제를 풀며 익히는 것을 추천했습니다.

LLM 시대에서 살아남기 — 김용진

LLM으로 개발하면서 같은 실수가 반복되고, 어느 순간 버그를 하드코딩으로 덮고 있다는 걸 알게 됐다는 이야기로 시작했습니다.

LLM의 결과가 맞는지 판별하는 능력이 필요하다
LLM이 찾아 준 버그를 자기가 찾은 것처럼 착각하지 말 것
프런티어 모델을 못 쓰게 되는 상황에도 대비할 것

제 질문: LLM을 활용해 공부할 때 어떻게 해야 하나요?
답: LLM이 준 지식을 읽은 것을 학습했다고 착각하면 안 된다. 그 지식을 직접 쓸 수 있는지 검증해야 하고, 대표적인 방법이 직접 실습해 보는 것이다.

SBOM 야호! — 김상범 & 김유홍

SBOM은 소프트웨어에 들어간 오픈소스 구성 요소를 목록으로 정리한 명세서입니다.

형식: CycloneDX(취약점 관리 중심), SPDX(라이선스 관리 중심)
들어가는 것: 이름·버전, 만든 곳, 패키지 식별자(purl), 라이선스, 전이 의존성, 취약점 조치 상태(VEX)
만드는 법: syft로 SBOM 생성, grype로 CVE 매칭
라이선스 위험: GPL은 전체 소스 공개 의무, LGPL은 단순 링크면 공개 의무 없음

공급망 사고 사례로 Log4j(CVE-2021-44228)와 SolarWinds가 소개됐습니다. 취약점이 나오면 버전 업데이트, 마이그레이션, 위험 수용(지속 확인), 사용 중단 중에서 고릅니다. SBOM은 표준 규격이라 검증(validation)이 필수이고, CVE 번호가 있는 것만 잡을 수 있다는 한계도 있었습니다.

TrustGate 프로젝트를 하던 시기라, SBOM이 "무엇이 들어 있는가"를 본다면 TrustGate는 "그것이 어떤 경로로 배포됐는가"를 본다는 점에서 연결해서 들었습니다.

Web3 Audit Agent Benchmark — 김휘성

AI 벤치마크는 여러 모델을 같은 조건에서 비교하는 것입니다. 보안 감사(audit)에서는 취약점이 있는지조차 확실하지 않고 목표가 불명확해서, CTF나 알려진 버그 찾기 같은 기존 평가 기준이 잘 맞지 않습니다.

데이터 오염, 의심스러운 정답이 섞인 데이터셋, LLM과 Scaffold(파일 탐색·명령 실행을 돕는 틀)를 분리하지 않은 평가 등이 문제로 지적됐습니다.
보안에서는 오탐도 중요한 평가 지표입니다. 편하려고 쓴 AI가 오탐을 쏟아내면 의미가 없습니다.
프롬프트는 모델 가이드에 맞춘 짧은 지시 정도였고, 두세 줄 차이로 유의미한 변화는 잘 보이지 않았다고 했습니다.

AI를 이용한 개발, "잘" 하는 법 — 김성우

AI를 안 쓰면 흐름을 못 따라가고, 쓰기만 하면 내가 한 일을 설명하지 못하게 됩니다. 그래서 기본기(CS, 해킹, 보안의 예방·탐지·차단·추적, 개발)를 다지면서 에이전트로 아이디어를 구현하라는 이야기였습니다.

이미 있는 것이면 개선에 집중
빨리 만들고, 별로면 빨리 버리기
도구가 어떤 작업에 어떤 결과를 내야 하는지 먼저 정의하기
검증 기준: 원하는 작업 수행 여부, 속도, 비용

AI 에이전트로 AI 에이전트 해킹하기 — 류석준 & 정태영

챗봇과 에이전트의 차이는 권한입니다. 에이전트는 도구를 호출해 여러 명령을 실행하므로, 발신자 판정 → 권한 범위 검사 → 승인 → 실행 정책으로 이어지는 검사 중 하나만 빠져도 높은 권한을 얻을 수 있습니다. 오픈소스 에이전트에서 나오는 취약점도 대부분 이런 권한 문제였습니다.

에이전트 활용은 프롬프트 → skills/rules 자동화 → 플러그인·MCP → 하네스 엔지니어링 순으로 발전하고, 원칙은 "가능한 단순하게"였습니다. 아직 LLM은 로직 버그를 잘 못 찾는다는 점도 강조됐습니다.

정리

여러 발표에 공통으로 나온 이야기는 두 가지였습니다.

AI 에이전트의 보안 문제는 새로운 것이라기보다 권한 위임과 검증의 문제다
AI를 쓰더라도 결과를 검증할 수 있는 기본기가 있어야 한다

이 캠프 이후로 AI 에이전트 보안과 레드티밍 쪽으로 관심을 넓히게 됐습니다.