490. IMAP4 (Internet Message Access Protocol v4) - 서버에 메일 보관 및 다중기기 동기화 (포트 143)

핵심 인사이트 (3줄 요약)

본질: IMAP4(Internet Message Access Protocol)는 메일 수신 서버(MDA)에 메일을 영구적으로 보관한 상태에서, 클라이언트가 서버에 접속해 메일함을 열람, 검색, 관리하도록 지원하는 **서버 중심(Server-centric) 양방향 동기화 프로토콜(포트 143)**이다.

가치: 하나의 이메일 계정을 폰, 태블릿, PC 등 여러 기기에서 동시에 접속해도 똑같은 폴더 구조와 '읽음/안읽음' 상태 플래그(Flag)를 완벽하게 유지해 주는 클라우드 뷰어(Viewer) 역할을 수행한다.

융합: 모바일 환경의 데이터 폭탄을 막기 위해 헤더(Header) 선(先)다운로드 및 본문 부분 추출(Partial Fetch) 메커니즘을 적용하였으며, 배터리 절약을 위해 TCP 연결을 유지한 채 알림을 받는 IMAP IDLE 푸시(Push) 확장 규격이 융합되어 진화했다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: IMAP4는 TCP 143번 포트(보안 통신 시 IMAPS 993번)를 사용하여 이메일 클라이언트(MUA)가 메일 서버(MDA)에 보관된 이메일을 원격으로 제어하고 동기화할 수 있게 해주는 인터넷 표준 프로토콜이다.
필요성: 인터넷 초창기에 쓰던 POP3는 "서버에 있는 편지를 내 컴퓨터로 다운받고, 서버에서는 지워버리는" 원시적인 다운로드 방식이었다. PC가 1대일 때는 문제가 없었지만, 스마트폰 시대가 오며 끔찍한 데이터 파편화가 발생했다. 아침 출근길에 폰으로 메일을 열어버리면(POP3 다운로드), 정작 회사 PC를 켰을 땐 서버에 메일이 지워져 있어 업무 지시를 볼 수 없는 대참사가 일어났다. "편지는 무조건 중앙 서버 우체국에 영원히 보관하고, 내 기기들은 그냥 돋보기로 서버 안을 들여다보며 같이 폴더를 정리(동기화)할 순 없을까?"라는 다중 디바이스 시대의 절박함이 IMAP의 전성시대를 열었다.
💡 비유: POP3가 넷플릭스 영화를 내 하드디스크에 통째로 불법 다운로드받고 서버에서는 지워버려 나 혼자만 볼 수 있는 방식이라면, IMAP4는 넷플릭스 앱을 켜서 스트리밍으로 보면서 "내가 영화의 34분까지 봤다(상태 플래그)"는 북마크 기록을 서버가 똑똑하게 외워두어, 거실 TV로 보든 폰으로 보든 언제나 34분부터 이어 볼 수 있는 완벽한 클라우드 동기화 시스템입니다.
등장 배경:
1. 다중 기기(Multi-Device) 환경의 폭발: 2000년대 후반 랩탑, PDA, 스마트폰이 대중화되며 '어디서든 똑같은 메일함(Single Source of Truth)'에 대한 요구가 빗발쳤다.
2. 모바일 네트워크의 한계: 3G 시절, 100MB짜리 첨부파일 메일 10개가 오면 POP3는 접속 즉시 1GB를 다운받아 폰을 마비시켰다. 제목만 쏙 빼보고 필요할 때만 본문을 받아오는 똑똑한 부분 로딩(Partial Fetch) 기술이 절실했다.
3. 스토리지 비용의 하락: 메일을 사용자가 지울 때까지 서버가 수십 GB를 무한정 보관해 줘야 하는 IMAP의 치명적인 스토리지 비용 문제를 구글(Gmail) 등 클라우드 기업의 규모의 경제가 해결해 버렸다.

┌─────────────────────────────────────────────────────────────┐
│          IMAP4 아키텍처: 다중 기기 상태(State) 완벽 동기화         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│       [ 📱 스마트폰 ]               [ 💻 회사 PC ]            │
│         (IMAP 클라이언트)               (IMAP 클라이언트)           │
│             │                           │                   │
│             │ 1. 출근길 폰으로 메일 '읽음' 처리│                   │
│             │ (Flag: \Seen 서버로 전송)  │                   │
│             ▼                           │                   │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │                  [ 🏢 IMAP 메일 서버 ]                    │ │
│ │                                                         │ │
│ │  [ 받은편지함 (INBOX) ]                                   │ │
│ │  ✉️ 메일 1 (어제 온 메일)  [상태: 읽음]                       │ │
│ │  ✉️ 메일 2 (방금 온 메일)  [상태: 안읽음] ➔ 폰 요청에 의해 [읽음] 변환! │
│ └─────────────────────────────────────────────────────────┘ │
│                                         ▲                   │
│                                         │ 2. 회사 출근 후 PC 켬│
│                                         │ (메일함 동기화 요청)  │
│                                                             │
│ 🌟 결과: 회사 PC 화면에 어제 폰으로 읽었던 메일 2번이 똑같이 '읽음(회색)'│
│ 상태로 뜬다. 만약 PC에서 [가족] 폴더를 새로 만들면, 1초 뒤 스마트폰의    │
│ 메일 앱에도 똑같이 [가족] 폴더가 생겨나는 마법의 상태 일치화!          │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] IMAP 시스템의 심장인 '단일 진실의 원천(SSOT, Single Source of Truth)' 사상이다. IMAP 환경에서 스마트폰과 PC의 이메일 앱은 스스로 상태를 결정할 권한이 없는 멍청한 껍데기(Thin Client)에 불과하다. 사용자가 폴더를 만들거나, 메일을 지우거나, 읽음 표시를 하는 모든 행동은 즉시 IMAP STORE 명령어로 번역되어 서버로 날아간다. 서버의 DB(사서함)가 원본 상태를 업데이트하고, 이 변경 사항을 연결된 모든 기기에 쏴준다(동기화). 서버가 절대적인 기준점을 쥐고 있기 때문에 기기 파편화가 절대 발생하지 않는다.

📢 섹션 요약 비유: 통장과 똑같습니다. 폰뱅킹으로 1만 원을 쓰고 나서 나중에 현금지급기(ATM)에 카드를 넣고 조회해 보면 잔고가 똑같이 1만 원 깎여있습니다. 내 폰과 ATM이 각각 돈을 기억하는 게 아니라, 은행 중앙 서버(IMAP 서버)가 원본 장부를 쥐고 있기 때문입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. 상태 동기화의 비밀: IMAP 플래그 (Message Flags)

POP3는 메일에 아무런 꼬리표를 달 수 없었지만, IMAP은 이메일 1통마다 서버 단에서 상태표(Flag) 꼬리표를 관리한다.

\Seen: 읽음 (이 플래그가 없으면 굵은 글씨의 '안 읽은 메일'로 표시됨)
\Answered: 답장 완료
\Flagged: 중요 표시 (별표 ⭐️)
\Deleted: 삭제 대기 (IMAP에서 휴지통을 누르면 파일이 바로 안 지워지고 취소선이 그어진다. 나중에 EXPUNGE 명령을 쳐야 하드디스크에서 진짜로 삭제된다)
\Draft: 임시 보관

이 상태 플래그들 덕분에 내가 폰에서 별표를 친 메일이 회사 PC를 켰을 때도 완벽하게 똑같이 별표가 쳐져 있는 것이다.

2. 대역폭 낭비를 막는 부분 추출 (Partial Fetching)

IMAP이 모바일 네트워크(3G/4G) 시대의 제왕이 된 가장 강력한 기술적 무기다.

헤더 우선 다운로드: 친구가 100MB짜리 동영상을 첨부해서 보냈다. 폰에서 앱을 켜면 IMAP은 영리하게 "편지 봉투의 발신자 이름과 제목(Header)" 단 1KB만 쏙 빼와서 목록 화면을 그려준다.
페이로드 정밀 타격: 사용자가 그 제목을 보고 호기심이 생겨서 클릭하면, 그제야 텍스트 본문(Text Payload)을 스트리밍하듯 당겨온다.
바이트 레인지(Byte Range) 추출: 심지어 첨부파일인 PDF가 너무 크면, "이 파일의 0바이트부터 100KB까지만 먼저 줘볼래?"라고 쪼개어 받아 미리보기(Preview)를 구현할 수 있는 미친 수준의 최적화 통신 능력을 뽐낸다.
📢 섹션 요약 비유: 서점에 가서 1000페이지짜리 무거운 백과사전을 무조건 사서(POP3) 집으로 낑낑거리며 들고 와야 하는 게 아닙니다. 도서관(IMAP 서버)에 선 채로 '목차'만 쭉 훑어보고(헤더 다운로드), 진짜 읽고 싶은 챕터 딱 5쪽만 복사기에 돌려서 가볍게 들고나오는 극강의 효율성입니다.

Ⅲ. 융합 비교 및 다각도 분석

비교 1: IMAP4 vs POP3 아키텍처 비교

이메일 수신 생태계를 양분했던 두 거장의 마지막 성적표다.

항목	POP3	IMAP4 (Internet Message Access Protocol)	승자 / 트레이드오프
설계 사상	다운로드 및 삭제 (로컬 PC 중심)	동기화 (서버 중심)	다중 접속 시대 IMAP 압승
메일 보관 위치	로컬 PC의 하드디스크 (`.pst`)	서버의 사서함 (로컬은 캐시 역할만 수행)	스토리지 비용 부담은 IMAP의 단점
부분 다운로드	불가능. 첨부파일까지 통째로 싹 받아야 함	가능. 제목과 헤더만 먼저 받고, 본문은 클릭 시	데이터 요금 절감 IMAP 압승
연결 유지(State)	잠깐 연결해서 다운받고 TCP 소켓 즉시 끊음	변경 알림을 위해 TCP 소켓을 가급적 유지함	서버 커넥션(RAM) 부하는 IMAP이 무거움
최고의 사용처	오프라인 백업용, 저사양 폐쇄망 메일 서버	현대의 모든 스마트폰, 그룹웨어, 다중 기기 환경 (100%)	-

오늘날 글로벌 엔터프라이즈 및 클라우드 IT 환경에서 POP3는 완벽하게 사망 선고를 받았다. 한 사람이 최소 2대 이상의 기기를 쓰는 세상에서 동기화를 지원하지 않는 프로토콜은 살아남을 수 없다.

과목 융합 관점

운영체제 및 스토리지 (Maildir vs Mbox): 메일 서버 데몬(Dovecot 등)이 수만 명의 사용자가 10년 치 쌓아둔 메일(IMAP)을 관리할 때 겪는 파일시스템 딜레마다. 메일함을 1개의 거대한 파일로 묶어서 저장하는 구형 mbox 포맷을 쓰면, 한 명만 메일을 '읽음(\Seen)' 처리해도 거대한 파일 전체에 Lock(락)이 걸려 서버가 뻗는다. IMAP 환경에서는 메일 1통을 리눅스 파일 1개로 쪼개어 저장하고 읽기/쓰기를 분산시키는 Maildir 아키텍처가 강제된다. 파일시스템의 I/O 튜닝 역량이 곧 메일 서버 성능의 99%를 좌우한다.
모바일 융합 (IMAP IDLE 푸시 확장): 스마트폰 배터리를 아끼기 위해 1분마다 서버에 "새 메일 왔어?" 묻는 바보 같은 폴링(Polling)을 버리기 위해 IMAP IDLE (RFC 2177) 확장이 추가되었다. 이는 TCP 소켓을 가늘게 열어둔 채 서버가 먼저 "새 메일 왔어!"라고 비동기적으로 쏴주는 구조로, 현대의 WebSocket이나 모바일 푸시 알림(FCM) 아키텍처 철학과 100% 닿아있는 통신 최적화의 산물이다.
📢 섹션 요약 비유: POP3는 넷플릭스 영화를 불법 다운로드 사이트에서 내 하드디스크에 통째로 다운받고 원본은 잊어버리는 낡은 MP4 파일 방식입니다. IMAP은 넷플릭스 앱을 켜서 스트리밍(부분 다운로드)으로 보며 서버와 완벽하게 씽크(Sync)를 맞추는 최첨단 클라우드 서비스입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 구형 사내 망의 오프라인 접속 한계(Caching)로 인한 데이터 증발: 외근이 잦은 영업사원이 비행기에 탔다. 인터넷이 끊긴 상태에서 스마트폰 메일 앱을 열었더니, 아침에 분명히 읽었던 중요한 계약서 메일의 본문이 하얗게 뜨고 "네트워크에 연결하십시오"라는 에러만 났다.
- 판단: IMAP의 서버 의존성(Server-centric)이 낳은 치명타다. 헤더만 미리 받고 본문은 누를 때 가져오는 극단적 최적화 때문에, 비행기 모드에서는 로컬 캐시에 다운로드되지 않은 본문을 영영 볼 수 없다. 실무 아키텍트는 이런 VIP 유저를 위해 이메일 클라이언트 설정에서 "오프라인용으로 전체 메시지 및 첨부파일 다운로드 유지" 옵션을 강제로 켜주어야 한다. 이는 IMAP의 클라우드 동기화 편의성을 누리면서도 로컬 백업(POP3의 장점)을 챙기는 생존 하이브리드 튜닝이다.
시나리오 — 메일 서버 마이그레이션 (Server-to-Server) 무중단 이관: 회사가 자체 구축한 구형 리눅스 메일 서버에서 마이크로소프트 365(클라우드)로 1만 명의 메일 데이터를 이사 가야 한다. 사용자들의 PC에 있는 낡은 Outlook 백업 파일(.pst)을 하나씩 USB로 뜨는 것은 1년이 걸려도 불가능한 재앙이다.
- 판단: IMAP의 궁극적 위대함인 단일 진실 원천(SSOT) 특성이 폭발하는 순간이다. 모든 사용자의 폴더 트리(Tree) 구조와 편지가 서버에 100% 저장되어 있으므로, 인프라 엔지니어는 imapsync 같은 오픈소스 CLI 툴을 쓴다. 이 툴이 양쪽 메일 서버에 동시에 Admin 계정으로 IMAP 연결을 맺고, A서버의 폴더와 읽음/별표 플래그까지 통째로 빨아들여 B서버로 완벽하게 스냅샷 복제해 버린다. 사용자들은 주말이 지나고 월요일에 출근하면 껍데기(접속 주소)만 바뀌었을 뿐, 내 폴더와 안 읽은 메일 숫자까지 그대로인 무결점 클라우드 마이그레이션의 기적을 체험하게 된다.

  ┌─────────────────────────────────────────────────────────────┐
  │      실무 아키텍처: IMAP 기반 클라우드 메일함 마이그레이션 자동화       │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │ [❌ 구시대 POP3 백업 (데이터 파편화의 비극)]                     │
  │ 김대리 퇴사 시: "내 PC 하드에 있는 Outlook.pst 파일 USB로 떠서 줘!" │
  │ ➔ 파일 깨짐, 다른 직원이 검색 불가능, 회사 지식 자산 완벽히 소실 💥  │
  │                                                             │
  │ [✅ 모던 아키텍처: IMAPSync를 활용한 Server-to-Server 이관]     │
  │                                                             │
  │ (A회사 자체 구형 메일 서버)                 (구글 G-Suite 클라우드)  │
  │  192.168.0.10                          imap.gmail.com       │
  │ [ 받은편지함 1만통 ]          TCP 993      [ 받은편지함 (비어있음) ]  │
  │ [ 프로젝트 폴더 5천통 ]  ────(imapsync)──▶ [ 프로젝트 폴더 복제! ]  │
  │ [ 보낸편지함 3천통 ]       (서버 간 직결)     [ 보낸편지함 복제! ]     │
  │                                                             │
  │ 🌟 판단: 클라이언트 PC를 거치지 않는다! 이관 툴이 양쪽 서버에 동시에    │
  │    연결을 맺고, 왼쪽 서버의 폴더 구조와 읽음(Seen) 플래그 상태까지       │
  │    100% 완벽하게 오른쪽 클라우드 서버로 밀어 넣어버린다.                │
└─────────────────────────────────────────────────────────────┘

[다이어그램 해설] 엔터프라이즈 인프라 담당자가 회사 메일 시스템을 클라우드로 이사 갈 때 쓰는 궁극의 무기다. 시스템의 '상태(State)'를 누가 통제할 것인가에 대한 답이다. 상태를 클라이언트가 쥐고 있던 POP3 시절엔 PC가 망가지면 회사의 정보 자산이 함께 날아갔다. IMAP은 모든 상태를 서버 중앙 집중화(Server-centric)로 끌어올린 덕분에, 클라이언트는 그저 언제든 버리고 갈아 끼울 수 있는 '투명한 껍데기 모니터(Thin Client)'로 전락했다.

도입 체크리스트

기술적: 포트 143(평문 IMAP) 통신은 비밀번호가 스니핑에 그대로 노출되므로, 사내 방화벽 정책에서 143 포트를 원천 차단하고 오직 **포트 993 (IMAPS - SSL/TLS 캡슐화)**로만 접속하도록 메일 서버 라우팅을 강제 통제하고 있는가?
운영·보안적: 해커가 훔쳐낸 사내 계정 아이디/비밀번호로 해외(러시아, 중국)에서 IMAP 프로토콜로 몰래 찔러 들어와, 사내 기밀 메일을 몇 달간 싹 다 다운로드해 가는 끔찍한 APT(지능형 지속 위협) 공격을 막기 위해, 웹메일 로그인뿐만 아니라 IMAP 연동 포트에 대해서도 **IP 지리적 차단(Geo-IP Block)**과 MFA(다중 인증, OAuth 2.0 App Passwords) 통제를 걸어두었는가?

안티패턴

IMAP과 POP3의 하이브리드 혼용 허용: 사내 메일 서버를 열어주면서 "편하신 대로 쓰세요"라며 110번과 143번 포트를 다 열어두는 인프라 관리자의 직무유기. 나이 든 임원이 폰으로는 IMAP을 쓰면서 회사 데스크톱 아웃룩에는 옛날 습관처럼 POP3를 세팅해 둔다. 출근하자마자 PC 아웃룩이 서버의 메일을 싹 다 빨아들여 지워버리고(POP3 다운로드 삭제), 1초 뒤 서버와 거울처럼 동기화된 스마트폰(IMAP)에서도 모든 메일이 실시간으로 공중 증발해 버리는 대재앙이 터진다. 한 조직의 수신 프로토콜은 무조건 100% IMAP으로 통일 강제해야 한다.
📢 섹션 요약 비유: 회사 서류철을 보관할 때 한 명은 서류를 집에 몰래 가져가는 병(POP3)이 있고, 다른 한 명은 서랍장을 같이 예쁘게 정리하는 룰(IMAP)을 쓴다면 그 회사의 서류함은 1주일 만에 텅 비거나 박살이 납니다. 다중 접속 시대에 협업 생태계를 파괴하는 다운로드 방식(POP3)은 절대 IMAP과 한 지붕 아래 공존시켜선 안 됩니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	로컬 다운로드 방식 (POP3)	상태 동기화 클라우드 아키텍처 (IMAP4)	개선 효과
정량	100MB 메일 접속 즉시 강제 다운로드	1KB 헤더 다운로드 후 클릭 시 스트리밍	모바일 환경 이메일 접속 데이터 소모량 90% 극단적 절감
정량	다중 기기 사용 시 데이터 단편화/유실	모든 기기 간 단일 진실 원천(SSOT) 동기화	로컬 PC 고장/분실에 따른 기업 메일 데이터 복구 비용 제로(0)화
정성	메일 백업을 각 직원이 알아서 수동 관리	백업, 검색, 보안 통제를 중앙 서버가 일괄 전담	엔터프라이즈 지식 자산(이메일)의 완벽한 중앙 통제권(Governance) 확보

미래 전망

JMAP(JSON Meta Application Protocol)으로의 바통 터치: IMAP4는 1990년대 스펙이라 복잡한 텍스트 파싱을 요구하고, 모바일 배터리를 죽이는 수많은 TCP 핑퐁(RTT) 핸드셰이크를 발생시킨다. IETF는 이를 타파하기 위해 최신 웹 표준인 REST API와 JSON 덩어리 1방으로 편지 동기화와 검색을 끝내버리는 **JMAP (RFC 8620)**을 표준으로 밀고 있다. IMAP은 수십 년간 제왕이었으나, 이제 웹 친화적인 JSON API에게 서서히 메일 수신 생태계의 왕좌를 넘겨주고 있다.
Exchange ActiveSync / Graph API의 독점: 마이크로소프트와 구글 같은 거인들은 이미 IMAP의 무거운 한계를 깨닫고, 캘린더, 주소록, 메일을 한 방에 완벽히 동기화해 주는 자기들만의 독자적인 프로토콜(ActiveSync, Microsoft Graph)로 자체 모바일 앱 생태계를 도배해 버렸다. IMAP은 서드파티 앱(범용 생태계)을 위한 최후의 레거시 호환성 보루로만 늙어가고 있다.

참고 표준

RFC 3501: INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 (현재 전 세계가 쓰는 IMAP4의 코어 바이블 명세서)
RFC 2177: IMAP4 IDLE command (배터리를 아끼며 새 메일 푸시 알림을 받기 위한 실시간 연결 확장 규격)

"상태(State)를 지배하는 자가 생태계를 지배한다." POP3가 사용자에게 데이터를 쿨하게 던져주고 뒤돌아서버린 방관자였다면, IMAP4는 수천만 명의 사용자가 언제 읽었는지, 무슨 폴더에 넣었는지 그 끈적한 상태(Status)를 서버라는 거대한 뇌에 영원히 묶어둔 통제광 아키텍처다. 클라이언트의 짐을 덜어 거대한 중앙 서버로 가져오는 이 '클라우드 컴퓨팅'의 원시적 뼈대는 당시 막대한 인프라 비용을 요구했지만, 다중 기기 시대라는 거대한 파도를 넘기 위한 인류의 유일하고도 가장 위대한 이메일 생존 전략이었다.

📢 섹션 요약 비유: IMAP4는 우리가 쓰는 구글 드라이브나 노션(Notion)의 위대한 조상님입니다. 내 하드디스크에 엑셀 파일을 다운받아 나 혼자 고치는 게 아니라, 전 세계 어디서든 똑같은 화면에 접속해 동기화된 상태를 누리는 '클라우드 동기화'의 마법을 30년 전에 이미 이메일이라는 투박한 텍스트 창에 완성해 낸 시대를 앞서간 천재적인 설계입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
POP3 (Post Office Protocol v3)	IMAP의 전임자이자 영원한 비교 대상. "가져오면 지운다"는 극단적 오프로딩 철학으로 다중 접속 시대에 멸망한 수신 프로토콜이다.
SMTP (Simple Mail Transfer Protocol)	IMAP이 창고에서 편지를 '예쁘게 정리하고 읽는' 수신 프로토콜이라면, 편지를 다른 우체국으로 '발송하고 릴레이'하는 역할은 철저히 SMTP가 분업한다.
IMAPS (포트 993)	IMAP의 평문 텍스트가 와이파이 도청에 털리는 것을 막기 위해, 통신 껍데기를 TLS/SSL 방탄조끼로 완전히 둘러싼 암호화 표준 터널이다.
MTA / MDA	IMAP 서버(Dovecot 등)는 편지를 배달하는 우체부(MDA)가 디스크에 꽂아둔 폴더(Maildir)를 살포시 열어서 클라이언트 화면에 뿌려주는 열람실 사서 역할을 한다.
JMAP (JSON Meta Application Protocol)	낡고 파싱하기 힘든 IMAP의 텍스트 명령어를 박살 내고, 모바일 웹 시대에 맞게 JSON 구조로 상태를 고속 동기화하는 떠오르는 차세대 메일 API 표준이다.

👶 어린이를 위한 3줄 비유 설명

옛날 POP3 방식은 도서관(서버)에서 책(메일)을 아예 대출해서 내 방으로 가져와 버렸어요. 그래서 다음 날 학교 컴퓨터로 접속하면 책이 없어서 못 봤죠.
IMAP4 방식은 책을 도서관에 영원히 묶어두고, 나는 스마트폰이라는 마법의 **거울(뷰어)**로 도서관에 있는 책을 멀리서 들여다보기만 하는 거예요!
내가 거울을 보면서 책 10페이지에 형광펜(읽음 표시)을 칠하면, 도서관 원본 책에도 똑같이 형광펜이 칠해져서 내일 아빠 컴퓨터 거울로 봐도 똑같이 10페이지부터 읽을 수 있답니다!