'예' 한 번에 뚫린 휴먼인더루프

한 번의 클릭으로 끝났다

개발자가 AI 코딩 에이전트에게 깃허브 이슈 하나를 맡긴다. 잠시 뒤 화면에 승인창이 뜬다. "이 파일을 수정해도 될까요?" 그는 별생각 없이 '예'를 누른다. 그런데 그 순간 그의 컴퓨터에서 실제로 실행된 것은 파일 수정이 아니었다. 외부 서버로 몰래 접속하는 명령이었다. 승인창에 적힌 한 줄 요약은, 사실 처음부터 참이었던 적이 없다. 진짜 위험한 명령은 화면 위쪽, 스크롤에 밀려 보이지 않는 자리에 이미 숨어 있었다.

이걸 뚫은 건 악성코드가 아니다. 뚫린 건 사람이 두 눈으로 본 화면 그 자체였다. 우리는 오랫동안 이렇게 믿어 왔다. "마지막에 사람이 직접 승인하니까 안전하다." 그런데 이 말에는 아무도 입 밖에 내지 않은 조건이 하나 숨어 있었다. 사람이 '참인 정보'를 본다는 조건이다. 그 조건이 무너지는 순간, 승인은 더 이상 방어가 아니다. 남이 시키는 대로 대신 서명해 주는 일이 되어 버린다.

LITL — 사람을 속이지 않고, 사람이 볼 화면을 바꾼다

글로벌 애플리케이션 보안 기업 체크마르크스(Checkmarx)가 2025년 9월 처음 공개하고 그해 12월 그 전모를 정리한 공격 기법이 있다. 이름은 LITL(Lies-in-the-Loop), 우리말로 옮기면 '루프 속의 거짓말'이다. 노리는 표적은 분명하다. 클로드 코드(Claude Code)나 마이크로소프트 코파일럿 챗(Copilot Chat)처럼 휴먼인더루프(Human-in-the-loop) 승인창을 안전장치로 내세운 AI 코딩 에이전트다.

루프 속의 거짓말 공격은 사용자가 승인창에 두는 신뢰를, 그 내용을 위조함으로써 악용한다.

The Lies-in-the-Loop (LITL) attack exploits the trust users place in these dialogs by forging their content.

— Checkmarx, "Turning AI Safeguards Into Weapons with HITL Dialog Forging" (2025)

수법은 정교하다기보다 허를 찌른다. 먼저 공격자는 깃허브 저장소나 웹페이지 같은 외부 공간에 악의적인 프롬프트를 심어 둔다. 에이전트가 그 내용을 읽으면, 오염된 지시를 그대로 따라 '겉보기엔 멀쩡한' 승인창을 스스로 만들어 띄운다. 정작 위험한 명령은 어떻게 처리할까. 앞뒤에 정상적인 문구를 잔뜩 채워 넣어(패딩) 터미널 화면 밖으로 밀어내 버린다. 그리고 행동을 설명하는 한 줄 요약은, 실제 실행 내용과 전혀 다른 문장으로 바꿔치기한다. 사용자는 자기가 무엇을 승인하는지도 모른 채 '예'를 누른다. 그 결과가 바로 원격 코드 실행(RCE)이다.

여기서 놓치기 쉬운 대목이 하나 있다. 사람은 시스템이 설계한 대로 정확히 행동했다. 화면을 읽었고, 판단했고, 승인했다. 무너진 건 사람의 주의력이 아니라, 사람에게 보여준 정보 그 자체의 무결성이었다.

두 회사의 답은 똑같았다 — '버그 아님'

체크마르크스는 이 문제를 앤트로픽과 마이크로소프트에 알렸다. 두 회사의 답은 서로 닮아 있었다. 앤트로픽은 2025년 8월에 보고를 접수한 뒤 이를 '정보성(informational)'으로 분류했다. 마이크로소프트는 10월에 접수하고는 별도 수정 없이 '완료'로 처리했고, 자사의 보안 취약점 기준에는 해당하지 않는다고 밝혔다.

버그가 아니라는 두 회사의 판정은, LITL이 소프트웨어의 결함이 아니라 HITL이라는 방어 모델이 딛고 선 가정을 찔렀다는 뜻이다. 그 가정이란 이렇다 — 사용자는 승인 요청에 적힌 내용을 믿을 수 있다. 국내 보도의 표현을 빌리면, 사용자가 그 내용을 더 이상 믿을 수 없게 되는 순간 HITL은 보호 장치이기를 멈춘다. 그리고 공격이 드나드는 통로로 뒤집힌다.

그런데 다섯 달 뒤, 한국은 다시 'HITL 필수'를 처방했다

LITL의 전모가 공개되고 다섯 달쯤 지난 2026년 5월, 국내에서는 정반대 방향을 가리키는 문장이 나왔다. 한국인터넷진흥원(KISA)과 AI안전연구소 등이 참여한 논의에서다. 이들은 AI 에이전트 시대의 필수 안전장치로 "중요한 결정마다 사람이 개입하는 휴먼인더루프 구조 유지"를 다시 앞세웠다. AI안전연구소는 'AI 에이전트 활용 안전 8원칙'을, KISA는 'AI 보안 안내서'를 내놓았다.

틀린 처방은 아니다. 다만 두 시점을 나란히 겹쳐 놓으면 묘한 그림이 그려진다. 한쪽에서는 바로 그 승인창이 위조될 수 있다는 걸 눈앞에서 시연했다. 그런데 다른 쪽에서는 그 승인창을 다시 최후의 방어선으로 세운다. 그 사이에서 끝내 손대지 않은 것이 하나 있다. '사람이 보는 화면은 참'이라는, 아무도 검증하지 않는 전제다.

이재형 KISA 팀장의 말도 같은 곳을 가리킨다. "AI가 업무 실행 주체가 되는 시대에 보안을 고려하지 않고 활용한다면 AI는 '자동화된 리스크 생성기'가 될 수 있다." 그런데 LITL이 우리에게 보여준 사실은 조금 서늘하다. 그 위험한 생성기 위에 사람의 승인을 한 겹 얹는 것만으로는, 그 스위치가 꺼지지 않는다는 것이다.

묻는 자리가 틀렸다

승인은 화면에서 일어나는 일이다. 우리가 눈으로 보는 표현 계층(presentation layer)의 행위라는 뜻이다. 하지만 우리가 정말 지키고 싶은 신뢰는 다른 층에 있다. 에이전트가 실제로 무엇을 실행하려 하는가, 곧 데이터 계층이다. HITL은 이 두 층이 서로 일치한다는 가정 위에 서 있다. 그리고 LITL은 바로 그 일치를 끊어 버린다. 화면과 실행 사이가 벌어지는 순간, 사람은 아무리 성실하게 들여다봐도 결국 틀린 것을 승인하게 된다.

그래서 질문의 방향을 바꿔야 한다. '사람을 루프 안에 넣어라'가 아니다. 사람에게 보여주는 것을, 실제로 실행될 것과 단단히 묶어라다. 요약 한 줄이 아니라 실행될 명령 전문을, 스크롤 밖이 아니라 한눈에 들어오는 자리에, 축약이 아니라 원문 그대로.

당장 해 볼 수 있는 일은 작지만 분명하다. 지금 쓰는 코딩 에이전트를 열어, 승인창이 대체 무엇을 보여주는지 직접 확인해 보라. 만약 행동을 설명하는 한 줄 요약만 뜬다면, 바로 그곳이 위조하기 가장 쉬운 지점이다. 설정을 바꿔 실행될 명령 전문(raw command)이 그대로 보이게 하라. 아니면 그렇게 원문을 보여주는 도구에만 자동 실행 권한을 주면 된다. 혹시 자동 승인(auto-approve)을 켜 두었다면, 지금이 바로 그걸 끌 때다.

다음 '예'를 누르기 전에

안전장치는 사람을 신뢰의 최종 심판으로 세운다. 하지만 심판은 자기가 본 것만 판정할 수 있다. 화면을 쥐고 흔드는 쪽이 공격자라면, '최종 심판'이라는 그 자리는 권한이 아니다. 그럴듯하게 놓인 미끼일 뿐이다.

그러니 다음에 에이전트가 '예/아니오'를 물어 올 때, 잠깐 멈춰 던져야 할 질문은 "이 행동이 안전한가"가 아니다. "지금 내가 보고 있는 이 화면을, 나는 대체 무엇을 근거로 믿고 있는가"다.