딥페이크 얼굴 판별, 1시간 훈련으로 정확도가 두 배 오를까?

2026. 7. 14 (화) · 약 10분

낯선 사람의 프로필 사진이 지나치게 반듯하다. 영상통화 전에 송금이나 본인 확인을 요구받는 순간이라면 ‘뭔가 이상하다’는 감각만으로 충분할까. 한 연구는 사람이 AI 얼굴을 가려내는 능력도 훈련할 수 있다고 말한다.

확인한 사실과 의미, 직접 살펴볼 지점을 차례로 정리했다.

오늘의 관점

이 소식들이 연결되는 지점

오늘 세 소식은 AI가 더 많이 만드는 시대에 사람이 무엇을 확인해야 하는지 묻는다. 딥페이크 연구는 얼굴 전체의 인상을 반복해서 비교하라고 하고, GitHub은 위험한 값이 시스템 프롬프트까지 흘러가는 경로를 코드에서 찾기 시작했다. 이어 개발자 에세이는 AI가 코드를 대신 써도 직접 코딩하는 시간이 시스템의 약점을 알아채는 수단으로 남는다고 주장한다. 사람의 눈, 정적 분석, 손으로 짜는 코드의 모양은 다르지만 공통점은 결과보다 생성 경로를 본다는 데 있다.

이 글에서 볼 것

01AI 얼굴은 너무 완벽하다? 1시간 훈련 뒤 식별 정확도 40%에서 80%대로

02GitHub CodeQL, AI 시스템 프롬프트로 흘러가는 사용자 입력을 찾는다

03AI가 코드를 쓰는 2026년에도 사람이 직접 코딩해야 하는 이유

오늘의 뉴스 3개

오늘의 메인 이슈 · NEWS 01 · AI타임스 · 2026. 7. 13 · 일반 독자

AI 얼굴은 너무 완벽하다? 1시간 훈련 뒤 식별 정확도 40%에서 80%대로

애버딘대학교와 호주국립대학교 공동 연구진은 StyleGAN3 얼굴을 반복 비교하는 훈련 뒤 참가자의 평균 식별 정확도가 약 40%에서 80% 이상으로 올랐다고 보고했다.

무슨 일이 있었나

영국 애버딘대학교와 호주국립대학교 공동 연구진은 사람이 AI 생성 얼굴을 구별하도록 훈련하는 방법을 PNAS에 발표했다. 실험은 StyleGAN3로 만든 얼굴과 실제 얼굴을 참가자에게 반복해서 보여주되, 특정 오류를 외우게 하지 않고 전체 인상의 차이를 익히도록 설계됐다. 연구진이 정리한 단서는 좌우 대칭, 얼굴 비례, 매력도, 독창성, 표현력, 기억 용이성 여섯 가지다. 훈련 전 평균 정확도는 약 40%였고 한 시간 뒤에는 80% 이상으로 올랐으며, 별도 참가자를 대상으로 한 재현 실험에서도 비슷한 효과가 보고됐다.

왜 우리에게 중요한가

예를 들면 중고 거래나 채용 연락에서 낯선 계정이 얼굴 사진을 내세워 신뢰를 요구할 때, 사람은 손가락 개수처럼 눈에 띄는 오류만 찾기 쉽다. 이번 연구는 오히려 지나치게 균형 잡히고 평균적이며 기억에 남지 않는 얼굴 전체를 비교하는 훈련에 초점을 맞춘다. 다만 ‘완벽해 보이는 얼굴’은 의심을 시작하는 단서일 뿐 사기 여부를 확정하는 증거가 아니다. 실제 피해를 막으려면 프로필 사진 판단과 별개로 공식 연락처 재확인, 실시간 영상 요청, 송금 전 계정 검증 같은 절차가 함께 있어야 한다.

직접 확인할 점

이번 결과가 모든 딥페이크에 그대로 적용되는지는 확인되지 않았다. 기사와 연구 문서에서 먼저 볼 항목은 StyleGAN3 외 다른 이미지 모델을 포함했는지, 압축된 메신저 사진이나 영상 프레임에서도 정확도가 유지되는지, 훈련 효과가 며칠 뒤에도 남는지다. 의심스러운 계정은 사진 한 장만 확대해 결론내리지 말고 게시 이력과 생성 시점, 다른 채널의 공식 계정, 영상통화 응답을 함께 확인해야 한다. 얼굴 판별 설정이나 탐지 앱 점수도 단독 증거가 아니라 여러 확인값 가운데 하나로 다루는 편이 안전하다.

원문 보기

728x90

 

함께 볼 흐름 · NEWS 02 · GitHub Changelog · 2026. 7. 11 · 실무 독자

GitHub CodeQL, AI 시스템 프롬프트로 흘러가는 사용자 입력을 찾는다

CodeQL 2.26.0은 JavaScript·TypeScript 코드에서 신뢰할 수 없는 값이 AI 모델의 시스템 프롬프트로 들어가는 경로를 찾는 쿼리를 추가했다.

무슨 일이 있었나

GitHub은 코드 스캐닝의 정적 분석 엔진인 CodeQL 2.26.0을 공개했다. 이번 버전은 Kotlin 2.4.0까지 지원하고, JavaScript와 TypeScript용 ‘js/system-prompt-injection’ 쿼리를 새로 넣었다. 이 쿼리는 사용자가 넣은 신뢰할 수 없는 값이 AI 모델의 시스템 프롬프트로 흘러가 공격자가 모델 동작을 바꿀 수 있는 경로를 찾는다. OpenAI·Anthropic·Google GenAI SDK의 추가 API도 분석 대상으로 넓혔고, C#·Go·Python·Swift·GitHub Actions 관련 분석 정확도와 모델링도 손봤다.

왜 우리에게 중요한가

예를 들면 고객 문의 내용을 받아 답변 규칙과 합쳐 AI에 보내는 기능에서, 문의 문장이 구분 없이 시스템 지시문 안으로 들어가면 공격자가 원래 규칙을 덮으려 시도할 수 있다. CodeQL은 이런 데이터 흐름을 배포 전에 코드 수준에서 표시해 리뷰할 위치를 좁힌다. 개인 프로젝트도 GitHub code scanning을 켜두면 AI 기능을 추가한 뒤 사람이 놓친 입력 경로를 다시 살필 수 있다. 다만 정적 분석은 코드에 드러난 흐름을 찾는 도구라서 검색 문서, 외부 도구 응답, 실행 중 권한 변화까지 자동으로 모두 판단해주지는 않는다.

직접 확인할 점

GitHub.com의 code scanning 사용자는 새 CodeQL 버전을 자동으로 받지만, 오래된 GitHub Enterprise Server는 향후 릴리스를 기다리거나 수동 업그레이드가 필요하다. 저장소의 Actions 로그에서 실제 CodeQL 버전과 ‘js/system-prompt-injection’ 쿼리 실행 여부를 확인해야 한다. 이어 사용자 입력을 시스템 프롬프트에 직접 합치는 최소 예제를 별도 브랜치에 만들고 경고가 뜨는지, 메시지 역할을 분리하거나 입력값을 제한한 뒤 경고가 사라지는지 비교할 수 있다. 경고가 없더라도 모델 호출 권한과 외부 도구 허용 목록 설정은 따로 검토해야 한다.

원문 보기

함께 볼 흐름 · NEWS 03 · GeekNews · 2026. 7. 14 · 깊이 읽기

AI가 코드를 쓰는 2026년에도 사람이 직접 코딩해야 하는 이유

개발자 Doug Turnbull은 AI 에이전트를 위한 자동화와 평가 장치를 만들면서도, 코드의 취약한 구조를 이해하고 설계 원칙을 다듬기 위해 사람이 직접 코딩할 시간이 남는다고 주장했다.

무슨 일이 있었나

GeekNews가 소개한 개발자 Doug Turnbull의 글은 소프트웨어 엔지니어의 일이 코드 생산에서 ‘소프트웨어 공장’을 만들고 유지하는 쪽으로 넓어졌다고 설명한다. 에이전트가 일을 잘하도록 skills, AGENTS.md, 지식 문서를 제공하고 테스트·린트·타입 검사·평가로 결과를 막아주는 역할이 커졌다는 뜻이다. 그럼에도 저자는 사람이 직접 코드를 쓰면 자연어를 거치지 않고 실행 환경 안에서 생각할 수 있고, 구조의 취약함과 테스트의 빈틈을 더 선명하게 알아차릴 수 있다고 주장한다. 사람은 방향을 시험하고 에이전트는 확인된 패턴을 넓게 적용하는 분업도 제안한다.

왜 우리에게 중요한가

예를 들면 처음 한 번 잘못 고른 저장 방식이 코드에 들어가면 AI 에이전트는 기존 동작을 보존하려고 예외와 우회 코드를 계속 덧붙일 수 있다. 리뷰 화면에서 diff만 승인하면 변경은 빨리 끝나지만, 왜 구조가 복잡해졌는지 몸으로 추적할 기회는 줄어든다. 반대로 사람이 작은 부분을 직접 고치며 반복되는 예외를 발견하면 그 원칙을 테스트와 문서로 바꿔 다음 작업의 기준으로 남길 수 있다. 이 주장은 AI 코딩을 거부하자는 말보다, 생성 속도와 시스템 이해를 서로 다른 지표로 관리하자는 제안에 가깝다.

직접 확인할 점

원문은 한 개발자의 경험과 주장이지 생산성이나 결함률을 비교한 실험 보고서가 아니다. 따라서 ‘사람이 코딩하면 품질이 높다’고 일반화하기보다 같은 규모의 변경을 두 방식으로 진행해 데이터를 남기는 편이 낫다. 확인할 값은 첫 테스트 통과까지 걸린 시간, 수정 요청 횟수, 새로 생긴 예외, 일주일 뒤 다시 읽을 때 걸린 시간이다. 저장소 로그와 이슈 문서에 이 값을 남기면 AI가 맡길 구간과 사람이 손으로 파고들 구간을 감이 아니라 기록으로 조정할 수 있다.

원문 보기

기초상식 · 소프트웨어 개발

오늘의 정처기 문제

가장 나중에 삽입된 자료가 가장 먼저 삭제되는 LIFO 방식의 자료구조는?

1. 1.그래프
2. 2.스택
3. 3.큐
4. 4.트리

정답과 해설 보기

정답 2번 · 스택

해설 스택은 한쪽 끝에서 삽입과 삭제가 이루어지며 마지막에 넣은 자료를 먼저 꺼내는 LIFO 구조입니다.

오늘의 IT · 개발 · 기획 용어

• 프롬프트 인젝션 (Prompt Injection) 보안 외부 입력에 지시문을 섞어 AI가 원래 규칙을 무시하거나 허용되지 않은 행동을 하게 만드는 공격 방식.
• 정적 분석 (Static Analysis) 개발 프로그램을 실제로 실행하지 않고 소스 코드와 데이터 흐름을 검사해 오류나 보안 위험을 찾는 방법.
• 소프트웨어 팩토리 (Software Factory) IT 코드 생성뿐 아니라 테스트, 배포, 규칙, 문서와 자동화를 묶어 소프트웨어 변경을 반복 가능하게 만드는 작업 체계.

AI 결과물을 한눈에 알아보는 만능 단서는 없다. 대신 무엇이 입력됐고, 어떤 경로를 거쳤고, 어디서 사람이 개입했는지를 확인하는 습관은 얼굴·프롬프트·코드 모두에 적용할 수 있다. 도구가 강해질수록 검증은 마지막 단계가 아니라 설계의 일부가 된다.

직접 확인해보려면오늘 자주 쓰는 AI 기능 하나를 골라 입력값, 자동 처리 구간, 사람이 최종 확인할 지점을 세 줄로 적어본다.