보안파트

들어가기 전

한빛 미디어에서 나온 주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 이게 x에서도 핫해서.. 서평단에 되지 않는다면 따로 구매할 생각이 있을 정도로 궁금했던 책이었다..!

이번에는 백엔드 전용으로 나왔다니 두근 두근한 마음이다..!

현재 교보문고 순위에서 출간한지 1달 밖에 안됐는데 컴퓨터/it 부문에서 17위를 할 정도로 사랑을 받고 있는 도서이다.

실무를 진짜로 알려주는 백엔드 책, 이런 흐름으로 배운다!

실무를 진짜로 알려주는 백엔드 책, 이런 흐름으로 배운다! 백엔드 공부하다 보면 늘 이런 생각 들지 않아?

“기능은 만들겠는데, 왜 자꾸 터지지?” “서버는 잘 돌았는데 왜 느리지?” “서비스가 커지니까 내가 만든 코드가 발목 잡네...?”

그럴 때 딱 좋은 책이 있어. 이 책은 단순히 "어떻게 만들까?"가 아니라 "만들었으면, 이제 어떻게 잘 굴러가게 하지?"를 알려줘. 실제 서비스가 돌아가는 흐름을 기준으로 설명하기 때문에, 하나씩 따라가다 보면 성능, 구조, 장애 대응, 보안, 확장성까지 한 번에 잡을 수 있다.

✅ 이 책이 다루는 핵심 내용

이 책은 빠르게 서비스를 만들고, 동시에 확장성과 안정성까지 고려한 시스템을 구축하는 방법을 실제 사례 중심으로 알려준다. 350p. 정도 안에 내용이 꽉꽉 들어 있다.

1️⃣ 빠르게! 끊기지 않게!

성능의 기초를 배워

• 느려진 서비스의 원인이 뭐고, 어디부터 봐야 할지 알려줘

• 처리량, 응답 시간, 병목 지점을 어떻게 찾는지 실제 예제로 설명해

• 커넥션 풀, 캐시, CDN 같은 실전 최적화 기법도 나와

• 진짜 서비스에서 튜닝하는 법을 처음으로 배우게 되는 챕터야

책의 일부 파트로

• 커넥션 풀의 크기가 10이고 대기 시간이 30초

이때 동시에 30개의 요청이 발생했는데 순간적으로 DB서버에 부하가 걸리면서 쿼리 실행시간이 10초으로 늘어났다.

• 요청 10개는 풀에서 커넥션을 확보하여 쿼리 실행을 시작함

• 요청 20개는 풀에서 커넥션을 확보하지 못해 대기 상태로 진입

대기 하는 사람들 중 절반이 기다리지 못하고 5초만에 요청을 취소하고 다시 요청했다고 가정하면 아래와 같이 된다.

10명의 클라이언트가 5초만에 요청을 취소하고 다시 요청을 보내면서 새로운 대기가 시작한다. 클라이언트가 요청을 취소하더라도 서버는 일정 시간 동안 하던 작업을 즉시 중단하지 않기에 대기 중인 요청 수는 30개가 된다. => 서버 부하가 커짐

그렇기에 대기 시간을 짧게 설정하는 것이 중요하다.

2️⃣ 연동과 데이터 흐름, 진짜 설계란 이런 거다

단일 서비스가 아니라, 여러 시스템이 연결될 때 생기는 문제 해결법

• DB 인덱스나 쿼리 성능뿐 아니라, API 연동 타임아웃/재시도/브레이커 패턴까지

• 메시지 큐, 아웃박스, CDC 등 비동기 설계 기법도 나온다

• “그냥 연결하면 되잖아?” 했다가 겪는 장애들을 미리 방지하게 해줘

3️⃣ 동시에 많은 요청이 올 때 어떻게 해야 할까

동시성 제어와 리소스 관리 핵심

• DB 락, 멀티스레드, 동시 요청 처리할 때 생기는 문제들을 짚어줘

• 자원 낭비 줄이고 효율 올리는 구조까지 실전에서 바로 써먹을 수 있어

• 논블로킹 IO, 가상 스레드 같은 최신 트렌드도 소개돼

4️⃣ 보안과 운영, 진짜 실무 감각 생기는 파트

“이건 인프라팀 일이잖아”라고 넘기면 안 되는 내용들

• 인증, 인가, 암호화, HMAC, 시큐어 코딩 등 진짜 보안의 기본

• 리눅스 디스크 확인, 크론 스케줄링, 네트워크 정보 확인 등 내가 만든 서비스가 운영 환경에서 어떻게 살아있는지 직접 체감하게 돼

5️⃣ 마지막은 확장성과 구조 설계

유지보수 가능한 설계는 실력의 차이를 만든다

• MVC, 계층형, MSA, 이벤트 기반, CQRS까지 주요 아키텍처 패턴 정리

• “왜 이렇게 나눴을까?” → “이래서 이렇게 나누는구나!”로 바뀌는 순간

이 책은 단순한 기능 구현 책이 아니야

하나씩 따라가다 보면, 단순히 “잘 돌아가는 코드”를 넘어서 “서비스 전체가 잘 굴러가는 구조”를 이해하게 돼.

기능만 만들던 개발자에서 장애도 대응하고, 구조도 설계하는 개발자로 성장하고 싶다면 이 책, 한 번은 꼭 읽어봐야 해.

뿐만 아니라 이해하기 쉽게 여러 그림들 또한 되어 있어 읽기가 편해!

👀 이런 분들에게 추천해요!

• "기능은 만들 수 있는데, 왜 불안정할까요?" → 백엔드 개발의 ‘기초 체력’을 키우고 싶은 신입 개발자

• "서비스는 돌아가는데, 구조가 복잡해요!" → 프로젝트 구조, 데이터 설계, 운영 환경까지 고민하는 주니어~미들 개발자

• "이제는 서비스 전체 흐름이 궁금해요!" → 클라우드, 모니터링, 운영 환경까지 통합적으로 보고 싶은 개발자

이 책은 단순한 기능 구현서가 아닙니다. 서비스 전체를 바라보는 개발자의 시야를 만들어주는 실전 가이드북입니다. 실무에서 ‘이건 왜 이렇게 하는 걸까?’라는 궁금증이 많은 개발자라면, 반드시 한 번은 읽어야 할 책이다.

컴퓨터 구조 스터디 + 실전 백엔드 책으로 알아보는 진짜 보안

컴퓨터와 구조 책 스터디 또한 보안 파트를 공부해야 하기에 겸사겸사 두 개의 책을 합친 보안 알아보려 한다.

보안의 핵심은 여러분과 여러분의 물건을 여러분이 정의한 안전함safe에 따라 유지하는 것이다.

보안은 기술적인 문제만은 아니다. 보안은 사회적인 문제다.

여러분과 여러분의 물건, 그리고 여러분의 안전에 대한 정의는 모두 다른 사람과 다른 사람의 물건, 그들의 안전에 대한 정의와 균형을 맞춰야 한다.

온라인 뱅킹을 생각해보라. 컴퓨터 하드웨어, 소프트웨어, 은행에서 개인에 이르는 통신 네트워크 등의 다양한 요소가 온라인 뱅킹을 이룬다. 하지만 우리가 패스워드를 포스트잇에 적어서 컴퓨터 모니터에 붙이면, 은행이 아무리 최고의 기술을 써도 전혀 도움이 되지 않는다!

1) 중요한 보안

고객정보가 유출된 K사의 보안 사고 사례를 보자. 해킹을 당한 기능은 요금 정보 페이지였다.

홈페이지에 로그인한 고객은 요금 정보 페이지에 접근해서 개인의 요금 관련 정보를 조회할 수 있었다. 요금 정보를 조회하기 위해 사용한 API는 다음과 유사하게 고객에 해당하는 코드값을 파라미터로 받았다.

https://주소/..?cd=고객 코드

웹 페이지는 고객 코드 값으로 로그인한 사용자의 코드를 사용하도록 구현되어 있었다. 여기서부터 문제가 시작되었다. 서버는 곡객코드가 로그인한 사용자의 고객코드인지 검증하지 않고, 고객코드에 해당하는 고객 정보를 응답했다.

즉, 로그인만 하면 다른 고객의 정보를 조회할 수 있었던 것이다.

2) 보안과 프라이버시

펜더의 블루투스 앰프 사례는 위협 모델 없이 제품을 설계했을 때 발생하는 전형적인 보안 실수이다. 인증이 구현되지 않아 누구나 무대의 앰프에 연결해 소리를 낼 수 있었고, 이는 제품 기능을 완전히 무력화시켰다.

또한 위협을 정확히 정의하지 않은 상태에서 보안을 설계하면, 사용자에게는 불편을 주면서도 실질적 보안은 얻지 못하는 결과를 초래할 수 있다.

예를 들어, 복잡한 패스워드 정책은 오히려 사용자가 종이에 메모를 하게 만들어 위험을 증가시킬 수 있다.

따라서 시큐어 코딩, 인증·인가 체계, 비정상 접근 감지, 감사 로그 기록, 최소 권한 접근 제어 등은 정의된 위협 모델에 맞춰 설계되어야 하며, 방화벽이나 데이터 노출 제한 또한 이러한 위협 분석을 기반으로 시행되어야 효과적이다.

출처 : https://brunch.co.kr/@23why/146

컴퓨터를 사용한다면 수없이 많은 서드파티 하드웨어나 소프트웨어에 의존해야 한다. 이들 서드파티 소프트웨어나 하드웨어의 설계도나 소스 코드를 볼 수는 없지만 이들에 의존하는 수밖에 없다. 즉 신뢰할 수 밖에 없다.

3) 🔐 인증과 인가를 이해하기 위한 첫걸음: "보안은 신뢰를 설계하는 일"

1) 왜 ‘신뢰’부터 시작해야 할까?

우리는 매일 수많은 시스템과 사람을 ‘신뢰’한다. 하지만 컴퓨터 보안에서 신뢰는 가장 취약한 고리가 되곤 한다. 예를 들어:

• 펜더 앰프에 블루투스 페어링 없이 연결이 가능해, 관객이 앰프를 장악할 수 있었던 사례

• 소니와 레노버가 사용자의 동의 없이 루트킷, 광고 멀웨어를 심은 사례

• 지멘스, 시스코 등에서 하드코딩된 비밀번호가 보안에 심각한 허점을 만든 사례

이 모든 사례는 다음의 질문을 던지게 한다:

“도대체 무엇을, 누구를 믿을 것인가?”

이 질문이 바로 **위협 모델(Threat Model)**의 시작점이다.

모든 보안은 ‘누구를 신뢰할 수 있는가?’에서 시작된다. 보안 시스템은 신뢰를 기반으로 설계되며, 이 신뢰는 때로 의도적(루트킷, 백도어), 무능(기본 비밀번호, 암호화 누락), 부정직(NIST·NSA 암호 약화)의 형태로 배신당한다.

2) 보안을 위협하는 세 가지 태도

위협 모델 수립은 기술만의 문제가 아니다. 아래 세 가지 태도가 시스템 보안에 큰 영향을 끼친다.

1. 의도적(deliberate) 위협 사용자의 의도와 상관없이 설치되는 멀웨어, 백도어 등 (ex. 루트킷, NSA의 약화된 표준)

2. **무능(incompetent)**에 의한 위협 암호화되지 않은 통신, 기본 비밀번호 방치, 잘못 설계된 장치 등

3. **부정직(disingenuous)**한 표준이나 감시 체계 NSA와 NIST 사례처럼, 믿었던 보안 기관이 오히려 보안을 약화시킨 경우

3) 사물함 비유로 보는 보안 개념 - 보안에서 중요한 개념: 공격 표면(Attack Surface)

학교 사물함은 좋은 보안 시스템의 모델이 될 수 있다.

• 문은 공격 표면 (Attack Surface)

• 번호 자물쇠는 인증 절차

• 열쇠 구멍은 백도어, 즉 관리자가 접근할 수 있는 숨겨진 권한

• ‘누가 열 수 있는가’가 바로 인가(Authorization)

• 관리자의 마스터키는 높은 권한을 가진 존재

이런 구조는 우리 시스템에서도 마찬가지다. 사용자에게는 제한된 권한만 부여하고, 관리자는 더 넓은 접근 권한을 갖는다.

하지만 너무 단순하거나 잘못된 조합을 쓰면 자물쇠가 쉽게 털리듯, 약한 인증 수단이나 공용 비밀번호는 큰 위협이 된다.

4) 인터넷 시대의 새로운 공격들

좋은 보안은 ‘공격자에게는 비싸고, 방어자에게는 싸게’ 설계되어야 한다. 하지만 현실은 그 반대가 되기 쉽다. 예: 인터넷 시대엔 공격은 싸고, 방어는 어렵다. 현대 보안 위협은 눈에 보이지 않으며, 종종 자동화되어 있다.

• MITM 공격(중간자 공격) : 누가 숙제를 가로채서 바꿔치기할 수도 있음

• DDoS 공격 : 수많은 좀비 컴퓨터가 정당한 요청을 방해

• 사회공학 공격 : 사용자가 스스로 악성코드를 설치하게 유도

‘모호성에 의한 보안’은 위험하다.

• 숨겨두면 안전하다는 생각은 착각

• 오히려 투명성과 개방성이 보안의 강점을 만든다

• 수천 개의 눈 원칙(Thousands of Eyeballs Principle): 많은 이가 보는 시스템이 더 안전하다

이러한 공격을 방지하기 위해선, 누가 진짜인지 증명하고, 누가 어디까지 접근 가능한지를 통제해야 한다.

그렇다면, 우리는 ‘누가 무엇을 할 수 있게 허용할 것인가’를 어떻게 정할까? 바로 그걸 다루는 개념이 인증(Authentication)과 인가(Authorization)이다.

• 인증 : 사용자가 누구인지 확인하는 과정

• 인가 : 사용자에게 자원에 접근할 수 있는 권한을 부여하는 것이다.

이 둘만 지켜도 기본적인 취약점은 막을 수 있다.

인증과 토큰

물론이지! 지금까지 내용들을 한 방에 쏙 이해할 수 있게 정리해줄게. 편하게 읽을 수 있도록 반말로 쓸게. 이건 ‘크립토그래피의 핵심 원리 + 실무 보안 적용’에 대한 내용이라, 앞으로 백엔드 개발할 때 진짜 많이 쓰일 거야.

🔐 암호화, 진짜 중요한 이유는?

1) 암호화가 필요한 이유

예를 들어 친구한테 숙제를 대신 내달라고 부탁한다고 해보자. 근데…

• 그 친구가 진짜 친구인지 어떻게 알아?

• 숙제를 도중에 바꿔치기하지 않을까?

• 아예 잊어버리면 어쩌지?

→ 이걸 인증(authentication), 무결성(integrity), 신뢰(trust) 문제라고 해.

이런 문제의 **해결책이 바로 ‘암호화(cryptography)’**야. **‘나와 상대만 아는 비밀 코드’**를 이용해서 메시지를 주고받으면, 중간에 누가 훔쳐봐도 내용을 알 수 없고, 바꿔치기해도 티가 나게 돼.

2) 가장 위험한 데이터: 비밀번호

비밀번호가 유출되면? 그냥 끝장이야. 왜냐면:

• 로그인하면 모든 기능을 실행할 수 있으니까

• 게다가 다른 사이트에서도 같은 비번 쓰는 경우가 많아서 한 번 뚫리면 줄줄이 터짐

• 내부자(예: DB 엔지니어)가 열람할 수 있어도 위험

→ 그래서 비밀번호는 반드시 암호화해서 저장해야 돼.

암호화된 상태로 저장된 비밀번호는 설령 유출되더라도 원래 값을 알아내기 어렵고 알아내더라도 상당한 시간이 소요된다.

이를 통해 실제 피해가 발생하기 전까지 비밀번호를 변경하는 등 사후 대응할 수 있는 시간을 벌 수 있다.

3) 단방향 암호화 (복호화 불가능)

해시(Hash) 함수란?

비밀번호를 단방향으로 암호화할 땐 해시 함수를 써.

암호화 메서드(digest)란?

자바에서 해시 함수(예: SHA-256)를 쓸 때 이렇게 써:

MessageDigest digest = MessageDigest.getInstance("SHA-256");
byte[] result = digest.digest(입력값);

여기서 핵심은:

• digest(...)라는 함수가 해시를 계산해 주는 함수야.

• 이 함수에 넣을 입력값도 byte[]

• 결과값도 byte[]로 나와

즉,

byte[] 입력값 → digest() → byte[] 결과값

이라는 구조인 거지.

왜 byte[]를 쓰는 걸까?

컴퓨터는 모든 걸 숫자(0과 1)로 처리해. **문자열(String)**도 결국은 **문자 인코딩 방식(UTF-8 등)**에 따라 byte[]로 변환해서 저장하거든.

그래서 해시 함수도 이렇게 동작해:

String input = "password123";
byte[] origin = input.getBytes("UTF-8"); // 문자열 → byte 배열
byte[] hash = digest.digest(origin);     // 해시 계산 → 결과도 byte[]

왜 결과도 byte[]로 줄까?

SHA-256 같은 해시 함수는 결과를 고정된 길이의 바이너리 데이터로 만들어. 예를 들어, SHA-256의 결과는 항상 **32바이트(256비트)**야.

이 결과를 그냥 byte[]로 주는 이유는:

• 결과는 사람이 읽을 수 있는 문자열이 아니라서

• 원칙적으로는 네트워크나 파일에 쓸 때 그대로 쓸 수 있게 하려고 그래

• 암호화한 결과를 DB와 같은 저장소에 읽을 수 있는 형태로 저장하려면 바이트 배열을 문자열 로 표현해야 한다.

보통은 16진수 문자열이나 Base64로 바꿔서 사람이 읽기 쉽게 표현하지.

 byte[] origin = input.getBytes("UTF-8");
 MessageDigest digestMessageDigest.getInstance("SHA-256");
 byte[] hash = digest.digest(origin); // byte 배열을 암호화

• 입력이 조금만 달라도 완전히 다른 결과가 나와

• 복호화는 불가능 (즉, 원래 비밀번호를 복원할 수 없어)

📌 대표 해시 알고리즘 SHA-256, SHA-512, MD5, BCrypt 등

값의 비교

단방향 암호화는 해시 함수로 생성한 해시 값이 같다면 두 데이터가 같다고 간주한다.

로그인할 때 비밀번호가 일치하는지 여부도 해시 값을 이용해서 비교한다. 회원 가입할 때 입력한 비밀번호를 암호화한 해시 값을 DB에 저장하고, 로그인 시에는 입력한 비밀번호를 암호화해서 DB에 저장된 값과 비교한다. 두 값이 일치하면 비밀번호를 올바르게 입력한 것으로 판단한다.

단방향 암호화는 원본 데이터로 복호화할 수 없기 때문에, 사용자가 비밀번호를 잊었을 때 기 존 비밀번호를 알려주는 기능은 구현할 수 없다.

해시 충돌(Collision)을 막는 법: Salt

문제: 같은 비밀번호는 항상 같은 해시 결과가 나와 → 이걸 이용하면 ‘레인보우 테이블’로 역추적할 수 있음

참고 : 해커가 다양한 문자열과 해시 값을 미리 계산해서 만든 표를 레인보우 테이블이라고 한다.

해결책: Salt(소금)를 추가해서 해시 결과를 다르게 만들어. 솔트는 임의의 값이며 암호화할 때 솔트를 함께 사용하면 솔트값에 따라 결과 해시 값이 달라진다.

password + salt1 → 해시A  
password + salt2 → 해시B

→ 해시 충돌을 막고, 같은 비번이어도 결과가 달라져

단방향 암호화의 특징

• 복호화 불가능

• 로그인할 땐, 사용자가 입력한 값을 해시해서 DB의 해시값과 비교

• 비밀번호 찾기는 불가 → 대신 임시 비밀번호 발급

4) 양방향 암호화 (복호화 가능)

양방향 암호화는 암호화와 복호화가 모두 가능한 방식이다. 서버에 접속할 때 사용하는 SSH 프로토콜이나 API 호출 시 사용하는 HTTPS처럼 보안이 중요한 데이터 송수신 과정에서 주로 사용된다.

양방향 암호화는 암호화와 복호화할 때 키를 사용한다 같은 알고리즘, 같은 원본 데이터라도 어떤 키를 사용하느냐에 따라 결과는 달라진다.

대칭키 방식 (AES 등)

• 암호화/복호화에 같은 키를 사용

• 키가 유출되면 모든 데이터가 위험함

• 그래서 키 관리가 엄청 중요해

// 1. 키 생성
KeyGenerator keyGen = KeyGenerator.getInstance("AES");
keyGen.init(256); // 256비트 키 생성
SecretKey key = keyGen.generateKey();

// 2. IV 생성
byte[] iv = new byte[16];
new SecureRandom().nextBytes(iv);

// 3. 암호화
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, key, new IvParameterSpec(iv));
byte[] encrypted = cipher.doFinal("HELLO".getBytes("UTF-8"));

// 4. 복호화
cipher.init(Cipher.DECRYPT_MODE, key, new IvParameterSpec(iv));
byte[] decrypted = cipher.doFinal(encrypted);

📌 키 + IV를 조합해서 암호화 → 결과가 매번 달라짐 (패턴 방지)

비대칭키 방식 (RSA 등)

• **공개키(Public Key)**로 암호화

• **개인키(Private Key)**로 복호화

// 1. 키 쌍 생성
KeyPairGenerator keyGen = KeyPairGenerator.getInstance("RSA");
keyGen.initialize(2048);
KeyPair pair = keyGen.generateKeyPair();
PublicKey pubKey = pair.getPublic();
PrivateKey priKey = pair.getPrivate();

// 2. 암호화
Cipher cipher = Cipher.getInstance("RSA");
cipher.init(Cipher.ENCRYPT_MODE, pubKey);
byte[] encrypted = cipher.doFinal("HELLO".getBytes("UTF-8"));

// 3. 복호화
cipher.init(Cipher.DECRYPT_MODE, priKey);
byte[] decrypted = cipher.doFinal(encrypted);

• 공개키는 누구나 공유 가능

• 개인키만 있으면 복호화 가능 → 보안에 유리함

• SSH, HTTPS, 전자서명에 주로 사용돼

공개키로 암호화한 데이터는 개인 키로만 복호화할 수 있기 때문에, 공개 키가 유출되더라도 암호 화한 데이터를 복호화할 수 없다. 따라서 같은 키를 공유해야 하는 대칭 키 방식과 비교하면 비대칭키 방식이 보안에 좀 더 안전하다

SSH의 키쌍 인증 과정 (공개키 인증 원리)

1. 클라이언트 → 서버에 공개키 등록

2. 로그인 요청 시, 서버가 임의 숫자를 공개키로 암호화해서 보냄

3. 클라이언트는 개인키로 복호화함

4. 클라이언트는 복호화한 숫자를 해시해서 서버에 보냄

5. 서버가 값 비교 → 일치하면 인증 완료!

공개키는 누구나 가질 수 있고, 개인키만이 진짜 사용자임을 증명함.

📌 단방향 vs 양방향 암호화 비교

항목	단방향 암호화 (해시)	양방향 암호화 (AES, RSA 등)
복호화 가능 여부	❌ 불가능	✅ 가능
사용 예시	로그인 비밀번호 저장	HTTPS, SSH, 민감한 데이터 전송
키 필요 여부	❌ 없음 (알고리즘만 있음)	✅ 키 필요 (대칭/비대칭 키)
보안 수준	해시 알고리즘 + Salt 필요	키 관리가 보안의 핵심

• AES: 빠르고 효율적인 대칭키 암호화. 키 유출 주의!

• RSA: 안전한 비대칭키 암호화, 키 쌍 이용. 인증/서명에 강함!

• SSH/HTTPS/전자서명에는 RSA, 파일/DB 암호화에는 AES!

🔐 실무에서는 보통 RSA로 AES 키를 안전하게 전달하고, AES로 데이터 자체를 암호화하는 방식이 쓰여.

🔐 실제 로그인 인증 흐름 예시

1. 회원가입할 때:

   • 입력한 비밀번호를 SHA-256 + Salt로 해시

   • 그 결과를 DB에 저장

2. 로그인할 때:

   • 사용자가 입력한 비밀번호 → 똑같이 해시해서

   • DB 값과 비교 → 같으면 인증 성공!

이제 로그인 비밀번호는 반드시 해시 + 솔트 조합으로 암호화해야 한다는 거 알았지? 그리고 중요한 데이터는 양방향 암호화로 안전하게 주고받는 게 기본 중의 기본이야.

"암호화는 보안의 끝판왕이 아니라, 신뢰를 위한 최소한의 시작점이다."

📽️ 딥페이크 기술의 동작 원리 완전 정복

현대 기술로 인해 어떤 것이 진본인지를 결정하기가 점점 어려워지고 있다.

1) 서론 – 딥페이크 기술의 등장

인공지능 기술의 급속한 발전으로 등장한 딥페이크(Deepfake)는 실제 존재하지 않는 가짜 영상이나 음성을 매우 사실적으로 만들어내는 기술이다. '딥러닝(Deep Learning)'과 '페이크(Fake)'의 합성어로, 고도의 딥러닝 기법을 이용해 사람의 얼굴, 표정, 음성 등을 조작함으로써 진짜처럼 보이는 가짜 콘텐츠를 생성한다.

이 기술은 긍정적인 활용 가능성과 동시에 심각한 사회적 위협 요소로 주목받고 있다.

2) 딥페이크 기술의 개념 및 동작 원리

🧠 데이터 수집 및 학습: 얼굴을 학습하는 AI

딥페이크 기술은 기본적으로 딥러닝 기반이다. 특히 Autoencoder(오토인코더) 구조를 사용하는 경우가 많다.

오토인코더란?

입력 데이터를 스스로 압축했다가 다시 복원하는 딥러닝 모델

🔷 인코더 (Encoder)

• 아래쪽 파란 부분.

• 입력 데이터를 압축해서 중요한 정보만 담은 **"표현 벡터"**를 만들어.

• 예: 얼굴 사진 → 핵심 특징만 담은 벡터로 축소.

🟠 디코더 (Decoder)

• 위쪽 주황 부분.

• 표현 벡터를 다시 원래 데이터처럼 복원하려고 해.

• 예: 벡터 → 다시 얼굴 사진처럼 보이도록 출력.

1. 입력 데이터 → 인코더 → 압축

2. 표현 벡터 → 디코더 → 압축 해제

3. 출력 ≈ 입력 (완벽하진 않아도 최대한 비슷하게)

✨ 어디에 쓰일까?

• 딥페이크: 사람 얼굴 특징을 벡터로 바꾸고 다시 재구성할 때

• 노이즈 제거, 이상 탐지, 데이터 압축 등에도 쓰여

1.1 학습 데이터 준비

• 얼굴이 잘 나온 대량의 이미지나 영상 데이터를 수집해. 예: 연예인, 정치인의 인터뷰 영상 등.

• 데이터는 다양한 표정, 조명, 각도에서의 얼굴이어야 한다. 이게 많을수록 더 자연스러운 결과가 나와.

1.2 오토인코더(Autoencoder) 기반 학습

• 오토인코더는 입력 이미지(예: A의 얼굴)를 인코딩해서 **특징 벡터(latent vector)**로 만들고,

• 다시 디코더가 이 벡터를 바탕으로 원래 얼굴을 재구성해.

입력 이미지 (A) → Encoder → 잠재 벡터 → Decoder → 재구성된 A

1.3 얼굴 바꾸기용 딥페이크 구조

• A의 얼굴을 B의 얼굴 표정/움직임에 맞춰 재구성하는 식으로 작동해.

• 결국, **B의 얼굴 정보 + A의 스타일(표정 등)**을 혼합하여, A의 얼굴이 마치 B처럼 말하거나 행동하게 만드는 것이죠.

🎭 얼굴 합성 및 생성 단계

학습이 끝나면 실제로 딥페이크 영상이 만들어진다.

2.1 얼굴 탐지 & 정렬 (Alignment)

• 입력된 영상에서 얼굴 영역을 인식하고 정렬해.

• 눈, 코, 입의 위치를 맞추기 위해 **얼굴 랜드마크(facial landmarks)**를 잡는다.

2.2 교체할 얼굴 적용 (Face Swapping)

• 소스 얼굴 A를 타겟 얼굴 B의 움직임에 맞춰 합성해.

• 표정, 입 모양, 머리 기울기 등을 반영하여, 얼굴이 매끄럽게 이어지게 한다.

2.3 포스트 프로세싱 (후처리)

• 경계선이 부자연스러워 보이지 않도록 블렌딩 작업을 한다.

• 피부 톤, 조명 효과 등을 맞추고 영상의 흐름이 자연스럽도록 조정한다.

🔍 딥페이크 탐지 기술 (검출)

딥페이크 영상은 점점 정교해지고 있어서, 탐지 기술도 점점 중요해지고 있어.

3.1 미세한 신호 포착

• AI는 딥페이크 영상의 이상한 점을 찾아낸다:

  • 눈 깜빡임이 비정상적으로 적거나 많음

  • 얼굴 피부의 흔들림, 광원 반사가 실제와 안 맞음

  • 입 모양과 발화 내용이 싱크가 안 맞음

3.2 주로 사용되는 검출 기술

기술명	원리
CNN 기반 모델	얼굴의 픽셀 단위 차이 분석
눈 깜빡임 탐지	딥페이크는 눈 깜빡임이 없거나 일정함
혈류 분석	실제 얼굴은 피부색의 미세 변화 있음
오디오-비디오 싱크 분석	말하는 입 모양과 소리 일치 여부 검사

3.3 최근엔 ‘딥러닝 vs 딥러닝’ 전쟁

• 딥페이크 생성도 AI, 탐지도 AI

• GAN(생성적 적대 신경망) 구조처럼, 생성 AI와 탐지 AI가 서로 진화하면서 싸우는 구조로 발전 중

🤔 일반인은 어떻게 딥페이크 사기의 대상이 될까?

1) 소셜미디어에 공개한 사진·영상

• 인스타그램, 페이스북, 틱톡, 유튜브 등에 올린 셀카, 영상들로 충분히 학습 가능해.

• 특히 웃거나 말하는 모습이 담긴 영상이 있으면 딥페이크 학습 데이터로 쓰기 좋아.

• 몇 초짜리 짧은 영상 몇 개만 있어도 요즘 모델은 그걸로 얼굴을 합성해.

예: "셀카 영상 3~5개 + 공개된 인터뷰나 브이로그" → 음성까지 덧붙여 사기 영상 생성 가능

2) AI 음성 합성까지 결합

• 전화 통화 한 번, 보이스톡, 유튜브 음성만 있어도 음성 딥페이크가 가능해.

• 실제로 부모나 자식의 목소리를 복제해서 **"납치됐어요, 엄마"**라고 울먹이는 보이스피싱 사례가 있음.

2023년에는 미국·한국 모두 음성 딥페이크 보이스피싱 피해 사례 뉴스로 보도됐어.

💸 딥페이크 사기 수법 예시

사기 방식	설명
보이스피싱	가족·지인 목소리로 전화해서 금전 요구 (송금, 긴급 상황 연기)
지인 사칭 영상	"친구가 투자 얘기하길래 봤더니 영상도 있어!" → 딥페이크 영상
인터뷰 영상 위조	회사를 사칭하거나, 본인 영상 위조해서 신뢰 조작
이력서·면접 사기	AI로 만든 외국인 딥페이크가 실제 화상 면접 응시하기도 함

딥페이크 기술은 분명히 흥미롭고 유용한 가능성을 지니고 있지만, 동시에 심각한 윤리적, 법적, 사회적 문제를 동반한다. 기술의 발전에만 초점을 맞추기보다는 그 사용 범위와 방식에 대한 사회적 합의와 법적 제도 정비가 병행되어야 한다. 우리는 지금 '진짜 같은 가짜'가 현실을 위협하는 시대에 살고 있으며, 진짜를 지켜내기 위한 대응이 절실하다.

🔐 마무리하며

이번 주는 스터디 주제와 딱 맞게, 『한 권으로 읽는 컴퓨터 구조와 프로그래밍』의 보안 개념과 『주니어 백엔드 개발자가 반드시 알아야 할 실무 지식』의 암호화 실습 중심 내용을 함께 정리해보았다.

이론으로는 암호화의 필요성과 구조(대칭/비대칭 키), 인증 흐름, 해시와 솔트 개념을, 실무에서는 AES/RSA 암호화 방식, SHA-256 해시 구현, SSH 인증 흐름 등 실제 코드 기반으로 다뤄보며 실전 감각을 키울 수 있었다.

보안은 단순히 ‘막는 기술’이 아니라, 사용자와 시스템 사이의 신뢰를 만들어가는 과정이다. 코드 한 줄에도 보안적인 사고를 담을 수 있다면, 이미 한 단계 성장한 개발자가 된 것이겠지.

"보안은 끝이 아니라, 개발의 시작이다." 당장의 프로젝트에 꼭 쓰이지 않더라도, 개발자로 오래 일하고 싶다면 꼭 한 번은 정리해봐야 할 영역이 바로 보안이다.

📘 실무 관점에서 보안을 차근차근 다뤄보고 싶다면, 『주니어 백엔드 개발자가 반드시 알아야 할 실무 지식』을 꼭 추천드리고 싶다. 단순한 설명을 넘어서 직접 써볼 수 있는 코드 예제와 실제로 마주할 수 있는 보안 상황들까지 잘 담겨 있어, 실무에 바로 연결되는 인사이트를 얻을 수 있다.

다음에도 이렇게 이론과 실무를 함께 엮은 공부를 해보며, 더욱 탄탄한 개발자로 함께 성장해가자 :)