- -

[코드트리 후기] 북마크로 나만의 복습 루틴 만들기

hyeongseop — Mon, 1 Jun 2026 20:54:15 +0900

제가 코딩테스트 준비를 아예 안한건 아닌데요...
사실 예전에도 코드트리를 통해서 코테 준비를 하다가.. 너무 끔찍한 경험을 했습니다.

바로..

문제가 너무 안풀리는거에요..!
코드트리에서 매일 일정 xp를 쌓으면 씨앗이 점점 발아하는 시스템이 있는데
그거 채우려고 매일매일 일정 xp를 채우려고 노력했지만
초반에는 좀 쉬운거 위주로 하다가 점차 더 어려워지더니
대부분 1시간이면 당일 학습은 끝낼 수 있는데
너무 어려운 문제는 2~3시간은 훌쩍 넘겨버리더라구요...! (나 과제도 많은데 ㅠㅠ)

그래서 그런 문제는 북마크를 해뒀다가 다~음에 까마득 할 때 풉니다. (그동안 저는 성장해 있을 테니까요.)
북마크에 둘 때 주석으로 제 나름의 생각한 흔적을 남겨두고 떠나갑니다.

그런데 북마크 해두고 잊어 먹을 때 쯤, 코드트리에서 카톡이 와요.
북마크 해둔거 아직 살아있다고.

그럼 또 쫄래쫄래 코드트리 문제 복습하러 갑니다.
아 그런데 다시 풀어도 모르겠더라구요. 그런 문제는 깔끔하게 해설을 봅니다!
(왜냐하면 못 풀었다고 자존심 부리면 오히려 더 하기 싫어지더라구요. 오히려 A급 풀이를 감상하고, 그걸 벤치마킹해서 제 것으로 만드는게 더 효율적이라고 생각했어요.)

그래서 나만의 복습 루틴은
우선 코드트리의 커리큘럼에 따라서 진행을 하고
풀다가 모르는게 있으면, 한 30분 정도 고민을 하다가.
북마크 해두고 다른 걸 먼저 풉니다.
그러다 까먹고 있다가 다시 북마크를 짚어 들어가면,
어쩔 땐 풀리고, 안풀리면 그냥 답지를 봅니다.
그렇게 해나가니까 진도가 밀리지도 않고, 저도 스트레스 안받고 좋더라구요.

모두 코드트리 하세요!!

https://www.codetree.ai/

Codetree: Master Coding Interviews - Data Structures & Algorithms

Master algorithms, ace tech interviews, and elevate your coding skills with Codetree's systematic curriculum and expert-crafted problem sets.

www.codetree.ai

[공모전] 2026학생철도창의작품전 (은상)

hyeongseop — Mon, 25 May 2026 18:14:07 +0900

2026 학생 철도 창의 작품전 본선 다녀온 후기 (feat. 은상 )

안녕하세요 :)

2026년 5월 21일 목요일, 부산 벡스코에서 열린 '2026 학생 철도 창의 작품전' 본선에 다녀왔고, 운 좋게 은상을 받고 왔습니다. 글 쓰는 지금도 좀 얼떨떨한데, 기억이 휘발되기 전에 처음 지원하게 된 계기부터 부산에서 돌아오기까지를 정리해 두려고요.

학회 행사를 처음 가보는, 디자인/UI/UX 담당으로 참여한 컴공 학부생 입장에서 쓰는 글이라, 비슷한 대회 준비하시는 분들께도 조금이나마 참고가 됐으면 좋겠습니다.

1. 어쩌다 철도 공모전을 나가게 됐을까

시작은 굉장히 우연이었어요.

지난 겨울방학에 i-CAPS라는 글로벌 캡스톤디자인 캠프에 참여했는데, 거기서 같은 방을 쓰던 학교 동생이랑 친해졌습니다. 그 친구가 평소에 철도를 정말 좋아한다는 이야기를 들었던 게 머릿속에 남아있었어요.

방학이 끝날 무렵, 우연히 본 한국철도학회의 학생 창의 작품전 공고문에 그 친구 얼굴이 떠올랐어요. 그래서 "혹시 같이 나가볼래?" 하고 추천을 했고, 그렇게 셋이 팀을 짜서 NEXUS라는 이름으로 출전하게 되었습니다.

같이 한 팀에서 잘 굴러가려면 결국 사람이 맞아야 한다, 라는 걸 다시 한번 느꼈던 출발이었어요.

2. 아이디어 — "도우미 없이도 역에서 길을 찾을 수 있다면"

저희가 잡은 주제는

시각장애인을 위한 대화형 실내 내비게이션 AI : DAVI(다비)

였습니다.

이 주제를 처음 떠올린 건, 제가 사회복무요원으로 지하철역에서 근무했을 때의 경험 때문이었어요. 실제로 역사 안에서 보면 시각장애인 분들이 안내 도우미 없이 혼자 움직이는 게 정말 쉽지 않거든요. 점자블록은 플랫폼 가장자리나 일부 통로에만 깔려있고, 환승 통로나 출구 안내는 대부분 글자 사인이라 정보 자체가 단절돼 있어요. 현장에서 보면, 도우미 없이는 사실상 이동이 막힌다는 느낌이 강했습니다.

생각해보면 이건 시각장애인만의 문제가 아니에요. 저시력 어르신, 노인, 한국어를 잘 못 읽는 외국인 관광객까지 — 사인 의존도가 높은 실내 환경에서 똑같이 어려움을 겪는 사람들이거든요.

조금 무겁게 받쳐주는 숫자 몇 개만 적자면,

국내 등록 시각장애인 약 24만 7천 명 (보건복지부, 2024년 등록장애인 통계 기준 — 전체 등록장애인의 9.4%)
일본 국토교통성 자료로는, 일본 내 플랫폼 추락 사고가 2009년 2,442건 → 2014년 3,673건으로 약 1.5배 증가했고, 그 중 시각장애인 추락 사례도 80건이 보고됨 (Japan Times, 2016)

저희가 만들고 싶었던 건, 실내에서 GPS가 안 잡힐 때 위치를 잡아주고, 음성과 진동으로 길을 안내해주는 앱이었습니다.

3. 예선은 솔직히 잘 모르고 통과한 케이스

예선 제출은 생각보다 단순했어요.

재학증명서
아이디어 요약을 정리한 엑셀 양식
주최측에서 준 PPT 양식에 맞춰 작성한 PDF

이걸 메일로 보내는 방식이었습니다.

솔직히 말하면 저희는 "철도"라는 키워드와 너무 간접적으로 엮인 주제였어서, 본선까지 가리라곤 전혀 기대 안 했어요. 그냥 "한 번 내볼까?" 하는 마음으로 제출한 거였습니다.

그런데 본선 진출 메일이 왔어요. 진짜 화들짝 놀랐습니다.

4. 본선 진출 — 그리고 한 번 부서진 전략

본선 진출 메일을 받은 그 순간부터 갑자기 발등에 불이 떨어졌어요.

어… 우리 이제 진짜 뭔가 만들어가야 하는 거지?

머릿속에 그림은 있었지만, 코드 구현이 진짜 막막했어요. 저는 컴공이지만 솔직히 개발을 잘 못합니다. 디자인하고 화면 설계하는 건 좋아하는데, 실제로 동작하는 시스템을 짜는 건 또 다른 영역이더라고요.

마침 그 학기에 데이터 통신 수업을 듣고 있어서, 담당 교수님께 무작정 찾아갔습니다. 저희 아이디어를 설명드리고 "이거 학부생 수준에서 어디까지 가능할까요?" 하고 여쭤봤어요.

교수님 피드백을 한 줄로 요약하면 이거였습니다.

"실내 측위 기술은 이미 많이 연구되어 왔고, 학부생이 단기간에 제대로 구현하기엔 어렵다."

… 팩트였어요.

저희 아이템의 핵심은 두 가지였거든요.

실내 측위 — 사용자가 역 안 어디 있는지 알아내기
대화형 안내 — 어떻게 길을 안내할지

이 중에 1번을 학부생 셋이 3주 안에 제대로 만들겠다는 건 솔직히 욕심이었어요. 그래서 전략을 다시 짰습니다.

실내 측위는 가능한 선에서 시도하고, 대화형 음성 안내와 시각장애인을 위한 UI/UX에 진짜 힘을 주자.

이 전환이 결과적으로 잘한 결정이었던 것 같아요. 만들 수 없는 걸 붙잡고 끙끙대는 것보다, 우리가 잘할 수 있는 곳에 집중하는 쪽이요.

5. 만들어본 것들 — 그리고 솔직한 실패

남은 1~2주 동안 부랴부랴 개발을 진행했습니다.

실내 측위 테스트 (Wi-Fi 핑거프린팅)

충남대학교 공대 2호관 CAD 도면을 받아서, 건물 안 위치별로 Wi-Fi 신호 세기를 데이터베이스로 수집하고, 그 신호 패턴을 비교해서 사용자가 어디 있는지 추정하는 방식(소위 Wi-Fi 핑거프린팅)으로 테스트를 했어요.

결과는… 신호가 제대로 안 잡혔습니다. 학내 와이파이가 워낙 불안정하다 보니, 같은 자리에서 측정해도 매번 값이 출렁였어요. 시간이 더 있었다면 BLE 비콘처럼 별도 인프라를 깔거나 NFC 태그로 핀포인트 보정을 시도해봤을 텐데, 일정상 거기까진 못 갔습니다.

이 부분은 솔직히 데모에서 가장 약한 지점이었고, 저희도 그걸 알고 있었어요.

음성 인식 (Whisper)

음성 입력 쪽은 OpenAI Whisper 로 STT(음성 → 텍스트)를 처리하는 구성으로 갔습니다. 시각장애인이 화면을 정확히 터치하기 어렵다는 점을 생각하면, 음성이 1차 입력 수단이 되어야 한다고 봤거든요.

UI/UX 디자인

저는 디자인과 UI/UX를 맡았는데, 솔직히 이 부분이 제일 재밌었어요.

저희가 잡은 컨셉은 단순했습니다.

시각에 의존하지 않는 인터페이스
음성으로 안내하고
진동으로 보조 피드백

예를 들어 사용자가 의도와 다른 방향으로 이동하면, 휴대폰이 강한 진동으로 "방향이 틀렸다"는 걸 알리고 동시에 음성으로 다시 안내해주는 식이에요. 시각 정보 없이도 길을 인지할 수 있도록 다중 채널 안내를 설계하는 데 시간을 많이 썼습니다.

아쉽게도, 백엔드와의 연결까지는 끝내지 못했어요. 디자인한 화면이 실제 위치 데이터를 받아서 동작하는 데모까지 갔어야 하는데, 거기에서 시간이 끝났습니다. 이 부분은 진짜 두고두고 아쉬워서, 대회 끝나고도 더 공부해서 꼭 완성해보고 싶다는 생각을 했어요.

6. D-day, 부산 벡스코

포스터 사건 (인쇄비 16만원의 추억)

발표 부스에는 포스터를 세워야 했어요.

그런데 저는 학회 행사가 처음이었거든요. 아무것도 몰랐습니다. 그래서 부스 판넬(가로 2m × 높이 2m)을 거의 다 채우는 포스터를 출력해 갔어요.

인쇄비 16만원.

대회장 가보고 알았어요. 다들 그냥 전지 두 장으로 깔끔하게 끝내셨더라고요. 저는 왜 그 면적을 다 채웠을까요. (현장 가서 옆 부스 보고 머리 한 대 맞은 기분이었습니다.)

다만 — 튀긴 했습니다. 멀리서도 한눈에 보이긴 했어요. 의도하지 않은 마케팅 효과랄까요.

이 인쇄비를 회수하려면 어떻게든 상금을 타야 했고, 대전에서 부산까지 내려간 교통비까지 생각하면 진짜 절박했습니다.

일정 요약 — 본선 가시는 분들을 위해

본선 진출하셔서 이 글을 보고 계신 분들을 위해 그날의 흐름을 간단히 정리해두면,

~11:00 벡스코 컨벤션홀 1층 로비에서 참가 등록 (QR 스캔 → 명찰·식권·자료 수령)
~12:30 발표 부스 이동 후 작품 설치 완료 (2층 201~204호)
11:30~12:30 점심 (식권으로 지정된 장소에서 식사)
12:30~15:00 작품 전시·발표 (심사위원 + 일반 참가자 응대)
15:00~15:30 작품 철수
15:30~16:00 특별강연
16:00~17:00 시상식
17:00~ 폐회 후 전달 사항 안내 — 이거 안 듣고 가시면 상이 취소될 수도 있다고 명시돼 있으니 *꼭 끝까지 남아 계세요.***

저희는 점심 시간을 일찍 시작해서 식권 사용처가 아닌 지하 식당가의 개미집에서 낙곱새를 먹고 왔어요. 시간 여유 있게 잡고 일찍 가시는 거 추천드립니다.

심사 분위기 — 솔직히 기준은 잘 모르겠습니다

심사 시간에는 두 부류가 오세요.

그냥 작품이 궁금해서 들르신 일반 참가자
심사표 종이를 들고 오시는 심사위원

종이 들고 오시는 분이 심사위원입니다.

그런데 솔직히 심사 분위기와 결과는 별 상관이 없어 보였어요. 평가 기준이 명확히 공개된 것도 아니라서, 저희도 끝까지 "잘된 건가?" 싶었습니다.

저희는 발표를 5분 분량으로 준비했는데, 실제로는 거의 2분 내로 질문도 없이 가신 심사위원도 있었고, 8분 가까이 꼼꼼하게 질문하고 가신 분도 있었어요. 옆 팀에서는 웃으면서 발표를 들으시던 분이 저희 부스는 거의 무표정으로 쌩 지나가셔서, 그때는 진심으로 "아 망했다" 싶었습니다. ^^

그런데 — 은상이 떴습니다

이후 16시부터 특강이 시작되고, 시상식이 진행됩니다.

작년에는 본선 진출팀 모두에게 상이 돌아갔다는 얘기를 들었던 터라 올해도 그럴지 긴장하고 있었는데, 다행히 올해도 본선 진출팀들에게는 상이 골고루 돌아간 분위기였어요. 본선까지 진출하셨다면 포스터라도 챙겨서 일단 가시는 걸 강력 추천드립니다.

저희는 놀랍게도 은상을 받았습니다.

이유는 솔직히 아직도 잘 모르겠어요. 백엔드 연결도 못 한 데모였는데… 아마 문제 정의의 사회적 의미나 UI/UX 컨셉을 좋게 봐주신 게 아닐까 추측만 하고 있습니다.

상장은 행정 처리 후에 학교로 보내주신다고 하셨고, 상금은 팀장 메일로 별도 안내가 온다고 해요. 입금되면 글 업데이트하겠습니다.

어쨌든 — 인쇄비 16만원과 부산 왕복 교통비는 회수했습니다. 그거면 충분히 즐거웠어요.

7. 끝나고 느낀 것들

이번 대회를 거치면서 제가 얻은 건 의외로 결과보다 방향성이었어요.

백엔드와의 연결을 끝내 못 했다는 게 두고두고 아쉽지만, 덕분에 프론트엔드라는 영역이 어떻게 동작하는지 처음으로 진지하게 들여다볼 수 있었습니다.
그리고 다시 한번 느낀 건, 저는 디자인하는 게 재밌다는 것. UI/UX를 더 공부해서 프론트엔드 쪽으로 가는 진로도 진지하게 생각하게 됐어요.
좀 더 좁히자면, 일반 웹/앱 프론트엔드보다 IoT 디바이스에서의 프론트엔드/인터랙션 설계가 제가 가장 잘할 수 있는 영역이지 않을까 하는 생각이 드네요. 사용자가 직접 손으로 화면을 보지 않고도 정보를 받아야 하는 환경 — 이번 DAVI 같은 — 에 흥미가 많이 생겼습니다.

또 하나 작은 교훈은,

할 수 없는 것을 욕심내기보다, 할 수 있는 것을 단단하게 만드는 게 더 멀리 간다.

실내 측위를 처음부터 끝까지 우리 손으로 구현하겠다고 고집했으면 아마 데모 자체가 안 나왔을 거예요. 교수님 조언대로 전략을 갈아탄 게 결과적으로 본선까지 끌고 간 가장 큰 결정이었던 것 같습니다.

마무리 — 본선 진출자분들께 드리는 팁

혹시 이 글이 내년 본선 참가자분께 닿는다면, 이것만 기억해주세요.

포스터는 너무 욕심내지 마세요. 전지 2장 정도가 적당합니다. (16만원 살리세요.)
점심 시간은 일찍, 부스 설치는 더 일찍. 12:30 마감을 잘 지키셔야 해요.
17시 폐회 후 전달 사항을 꼭 끝까지 듣고 가세요. 안 들으면 상 취소 사유가 됩니다.
본선까지 갔다면 결과는 일단 가서 들어봅시다. 본선 진출 자체가 이미 충분히 의미 있는 자리예요.

저희 팀 NEXUS의 DAVI 프로젝트 코드는 아래 깃헙에 정리해 두고 있습니다. 백엔드 연결까지 천천히 이어갈 예정이에요.

GitHub : https://github.com/eomao/DAVI

긴 글 읽어주셔서 감사합니다.

[코테 공부] 리마인더 알림톡을 무시하면 생기는 일 (feat. 코드트리)

hyeongseop — Mon, 25 May 2026 17:14:47 +0900

코드트리로 파이썬 공부하고자 마음을 먹었는데요, 사실 혼자 공부하다보면 그 마음을 작심삼일조차 지켜내기 어려운 경우가 많습니다.
(저처럼요!^^7)

그래서 코드트리에서는 여러분의 동기를 부여하기 위해! 학습 동기를 부여하는 도구를 제안합니다.
1. 알림톡
2. 깃허브 연동 - 잔디 만들기

알림톡을 보면 정말 하루도 빠짐 없이 꾸준히 저에게 노크를 해준답니다.^^7 (지독한 녀석)
제가 북마크로 저장해뒀던 문제로 알려주고, 친구는 했는데 왜 너는 안하냐는 식으로 알려주기도 하구요.
사실 친구가 했다는 걸 알려주는게 제일 심적으로 동기가 부여되었던거 같아요.
왜냐하면 친구랑 나랑 같이하면 포인트를 더 받을 수 있는데, 내가 안해버리면...^^ 그 친구가 무섭거든요!

여러분도 할 수 있습니다. (무서운 친구과 함께라면)
코드트리 시작해보세요..

https://www.codetree.ai/ko/no-free-lunch-2026

3년 만에 돌아온, 코드트리 청약 통장 챌린지 | 코드트리

매주 학습 납입하고 7주 만기 채우면 코드트리 8월까지 무료. 매주 추첨권을 모아 맥북·에어팟·애플워치 응모까지. 신청 인원에 따라 조기마감될 수 있어요.

www.codetree.ai

그래서 저는 이번주에는 파이썬 출력에 대해서 공부하고 있답니다.
정말 뭐 별거 없었고. 제가 기존에 C, C++ 만 보아왔는데, 파이썬은 조금 더 간결하고 심플하더군요. 진짜 3일 날 잡으면 금방 다 할 수 있을 듯한데, 과제와 대외 활동에 치여서 할 수가 없는게 너무 아쉽습니다..ㅜㅠ
어쩔 수 없죠.

그래도 저는 다시 공부를 시작하는 사람으로서 그렇게 지루하지도 않았습니다.
다른 코딩테스트 프로그램의 경우는 혼자 독학을 진행하는 경우가 많은데, 코드트리는 친구랑 경쟁하는 심리를 이용해서 같이 공부를 할 수 있어서 더 재밌는거 같아요.
(다만, 해야죠..)

모두 파이팅!

[코드트리] 파이썬 왕기초부터 학습 후기

hyeongseop — Sun, 17 May 2026 22:15:26 +0900

저는 이번에 코딩테스트 연습을 위해서 새롭게 파이썬 공부를 시작하려고 하는데요
사실 파이썬은 제대로 배운 적은 없어서 다시 처음 출력부터 공부하려고 합니다.

이게 바로 코드트리만의 커리큘럼 구조의 장점인데요
마치 학습지를 받아서 처음부터 시작하기 좋게 준비되어 있습니다.
프로그래밍 시작, 기초, 연습, 알고리즘~~ 등등의 단계를 선택 할 수 있고
기초 내에서도 기본 연습문제 테스트 문제로 세세히 나뉘어 있어서 개념 놓치는거 없이 공부하기 좋습니다.

사실 아직 출력 부분까지밖에 공부를 안해서 뭘 말하기 너무 부끄러운데요
출력 부분만 확인한다면, 기본에서는 개념 설명을 해주고, 연습 문제에서는 문제 유형별로 어떻게 풀지를 알려줍니다.
마지막 테스트 문제에서는 종합적으로 확인할 수 있는 문제를 풀게해줍니다.
그런데 이제 문제별로 예상 시간과 난이도를 알려주기 때문에 미리 마음 먹기(?) 좋은거 같아요.
그래도 한번에 훅 어려운 문제를 풀기보다는 단계별로 들이닥치기(?) 때문에 준비할 수 있어서 좋습니다.

그런제 제가 저번에 코드트리로 공부할 때는 오히려 커리큘럼이 정해져있으니까
한 문제가 너무 안풀려서 못푸니까 다음 단계로 못넘어가게 되는게 아쉽더라구요.
그럴 땐! 그냥 풀이를 보고 학습해서 다시 풀어보면 됩니다. 그렇다고 멈추지마세요! 여러분은...!

사실 다른 사이트를 많이 활용해보지는 않았지만
이렇게 상세히 설명해주는 코테 사이트도 없었고, 개념이 굉장히 체계화 되어 있어서 처음부터 탄탄히 공부하거나
아님 애매한 개념을 확립하기에 좋은 사이트라고 생각합니다!
예를 들어 이번에 배운 출력문에서는 기존에 " " 만 생각하고 있었다면
""" """ 도 유용하게 사용 가능하고, end = " " 도 이용 가능하고 이런 다양한 방법을 알 수 있어서 좋은 듯 합니다.

저는 코트트리를 통해서 올해 코테를 씹어먹어볼 생각입니다~!

천천히 가더라고~ 꾸준히 하는게 제 목표입니다.
미약하더라고 잘 봐주세용:)

https://www.codetree.ai/ko/trail-info

코드트리에서 같이 청약통장 만들어서 해봐유~

코딩 테스트 학습 안내 | 코드트리

막막한 코딩테스트 준비, 혼자 헤매지 말고 체계적인 코딩 학습과 단계별 가이드로 빠르게 실력을 쌓아 취업에 성공하세요.

www.codetree.ai

[데이터통신] 10주차 강의노트

hyeongseop — Tue, 12 May 2026 13:28:51 +0900

Chapter 9: IoT와 무선통신 — 데이터통신의 킬러 앱

이번 강의 범위: BGP/AS 복습 → 라우팅 테이블 검색 문제 → IoT 응원봉 → 우주 통신 → 마션

Part 1 — BGP 복습 & IoT 응원봉 (week10_01)

1. 지난주 복습 — BGP 라우터와 AS 번호

BGP(Border Gateway Protocol): 인터넷에서 전 세계 모든 통신사의 라우터를 연결하는 라우팅 프로토콜. (자세한 내용은 2학기 컴퓨터네트워크에서 학습)

AS(Autonomous System, 자율 시스템): 기관이 자율적으로 라우팅을 운영하는 단위. 전 세계 기관마다 고유 번호로 식별된다.

교수님 강조: "AS는 Autonomous System의 약자예요. 자율적으로 라우팅을 동작시키는 기관이라는 뜻이에요. 충남대 내부에서는 우리 학교가 마음대로 라우팅 결정을 해도 되는 거예요."

기관	AS 번호
충남대학교	AS 18298
KT	AS 4766
SK 브로드밴드	AS 9318
LG U+	AS 3786
KISTI (학술망)	AS 1237

BGP 라우팅 테이블은 인터넷 공개 원칙에 따라 모두 공개되어 있고, 실시간으로 업데이트된다. telnet route-views.routeviews.org 명령으로 누구나 미국 백본 BGP 라우터에 접속해 볼 수 있다.

교수님 강조: "인터넷 만든 사람들은 원래 다 착한 사람들이라서 70~80년대 만들 때 해킹 같은 건 꿈도 안 꿨어요. 그래서 라우팅 데이터는 다 공개돼 있어요. 읽기만 되고 쓰기 권한은 없습니다."

충남대학교(168.188.0.0/16)까지의 경로는 미국 라우터에서 봤을 때 22개의 경로가 있고, 그 중 best(18번 경로) 가 선택되어 있다. 경로 선택 기준은 최단 hop count가 아니라 비용(cost), 대역폭, 정책 등 다양한 metric 기반이다.

⭐ 시험 포인트

AS = Autonomous System (자율 시스템)
BGP는 기관 간 라우팅 프로토콜 (인터-도메인)
내부 라우팅 (인트라-도메인): OSPF, RIP → 다익스트라, 벨만-포드 사용
BGP의 best 경로 선택: 최단 거리가 아니라 cost/정책/대역폭 등 복합 기준

2. ⭐ 라우팅 테이블 검색 문제 — 자료구조의 실전 적용

교수님 강조: "이게 진짜 실전 문제입니다. 라우터 만드는 회사들이 다 이걸 가지고 특허도 내고 기술 개발도 해요. 코딩 테스트 문제로도 나올 수 있어요."

문제 정의

입력: 목적지 IP 주소 (예: 168.188.129.237)
테이블 크기: 약 100만 개의 IP prefix
성능 조건: 1Gbps 회선 기준, 패킷 1개(512B) 처리 시간 = 4 마이크로초 이내

계산: 1Gbps ÷ (512B × 8bit) = 약 24만 패킷/초 → 1개당 약 4μs

검색 알고리즘 비교

알고리즘	평균 복잡도	최악 복잡도	비고
순차 탐색(Sequential)	O(N)	O(N)	100만 개면 너무 느림
이진 탐색(Binary Search)	O(log N)	O(N)	정렬 필요, 트리 치우치면 최악
균형 트리(B-Tree, AVL, Red-Black)	O(log N)	O(log N)	DB 인덱스에 사용
해시(Hash)	O(1)	O(N)	평균 상수 시간, 최강

교수님 강조: "이진 탐색의 최악이 O(N)인 이유를 설명할 수 있어야 해요. 트리가 한쪽으로 쏠려 있으면 역정렬된 거나 마찬가지라서 전체를 다 뒤져봐야 됩니다. 이 정도는 자료구조 배운 학생이라면 즉석 응답해야 해요."

실제 라우터의 해법: 하드웨어 + 소프트웨어 조합

교수님 강조: "라우터에서는 Longest Prefix Matching + B-Tree + Hash를 조합해서 씁니다. 거기에 HBM 같은 빠른 메모리를 써서 4 마이크로초를 맞춰요. 알고리즘만 개선해도 훌륭하지만, 하드웨어가 빨라지면 게임 체인저가 됩니다."

소프트웨어: B-Tree 계열(항상 log N 보장) + Hash(평균 O(1))
하드웨어: HBM, SRAM 등 초고속 메모리 사용
검색 방식: Longest Prefix Matching (가장 구체적인 주소를 우선 매칭)

⭐ 시험 포인트

라우팅 테이블 검색은 자료구조 실전 문제
이진 탐색 최악: O(N) (트리 편향 시)
B-Tree: 항상 O(log N) 보장 → DB 인덱스에 사용
해시: 평균 O(1), DB/라우터에서 조합하여 사용
1Gbps 라우터 기준 처리 시간: 약 4 마이크로초

3. 데이터통신 시대별 킬러 앱

시대	네트워크 기술	킬러 앱
1960~70s	ARPANET, X.25	Telnet, 원격 터미널
1980s	LAN, Ethernet	이메일(SMTP)
1990s	상업적 인터넷, TCP/IP	웹 브라우저(Mosaic→Netscape)
2000s 초	ADSL, 케이블 모뎀	P2P(Napster), 웹 포털
2000s 후	3G, Wi-Fi	YouTube, Skype, Facebook
2010s	LTE, 클라우드	Netflix, Instagram, Zoom
2020s	5G, Wi-Fi 6, 엣지 컴퓨팅	AI 앱, 스마트홈, IoT

교수님 강조: "IoT가 10년 동안 유행했는데 지금 시장이 활짝 열린 게 자동차입니다. 드론은 전쟁에서도 증명이 됐고, 자동차는 미국은 자율주행이 이미 되고 있어요. 다 IoT예요."

4. IoT 응원봉 — 데이터통신의 실전 사례

4-1. 개요 및 역사

K-POP 콘서트에서 관객 수만 명의 응원봉을 중앙 서버에서 원격 제어해 색깔·패턴을 동기화하는 시스템. 카드 섹션처럼 글자나 그림을 만들어낼 수 있다.

교수님 강조: "최초는 엑소예요. SM 엔터테인먼트가 2016년에 특허를 냈어요. 응원도구를 이용한 공연연출 제어시스템. 이수만 아저씨가 광학 시스템 회사랑 같이 만든 게 최초입니다."

관련 회사: 팬라이트, 비트로, 사운드웨이브
팬라이트 매출: 2018년 140억 → 2023년 275억
엔터테인먼트사: HYBE, SM, JYP 모두 진출

교수님 강조: "콘서트 한 번 하면 2만~3만 명. 2만 명이 5만원짜리 응원봉 하나 사면 10억입니다. 콘서트 10번 하면 100억. 엄청난 수익 모델이에요."

4-2. 디바이스 구성 요소

하드웨어: LED + 제어 컴퓨터 + 통신 모듈 (RF/ZigBee/BLE)
소프트웨어: 스마트폰 앱 + 중앙 서버

4-3. ⭐ 통신 방식 2가지 — 핵심!

구분	방식	특징	용도
콘서트 모드	RF (2.4GHz 무선, ZigBee)	브로드캐스트, 1:N	카드섹션, 색깔 동기화
개인 모드	BLE (Bluetooth Low Energy)	1:1 페어링	좌석 인식, 펌웨어 업데이트

교수님 강조: "콘서트에서는 블루투스를 쓸 수가 없어요. 왜냐하면 블루투스는 1대1이라서 2만 명을 동시에 제어할 수 없거든요. 그래서 RF 브로드캐스트 방식을 씁니다."

ZigBee: 저전력 무선 통신 프로토콜, 2.4GHz 대역, IoT 기기에 널리 사용
BLE: Bluetooth Low Energy, 스마트폰과 1:1 페어링, 좌표 등록 용도

4-4. 특허 분쟁

교수님 강조: "팬라이트 vs 비트로 특허 소송이 있었어요. 비트로가 1·2심 모두 이겼는데, 핵심 차이가 '그룹 묶어서 제어'냐 '응원봉 각각에 고유정보 부여해서 제어'냐예요. 아이유 콘서트 응원봉 특허 분쟁으로 인터넷에 엄청 이슈가 됐습니다."

2016년: SM 엔터테인먼트 최초 특허 출원 (ZigBee + BLE 조합)
이후: HYBE, 위버스컴퍼니(BTS) 등 유사 특허 출원

4-5. 응원봉 해킹 사례 (디씨인사이드 공개)

교수님 강조: "이 친구가 무선 통신을 뜯어봤어요. 1년을 기다려서 티켓팅을 해서 콘서트 가서 2.4GHz 신호를 캡처했습니다. 나중에 아이유 회사에 들어갔다고 해요. 이런 게 진짜 실력이에요."

해킹 순서:

콘서트장에서 2.4GHz 주파수 캡처 (SDR 장비 사용)
FFT 변환 → 어떤 주파수 쓰는지 확인
FSK(Frequency Shift Keying) 방식으로 0/1 판별
패킷 구조 역분석 (Preamble / Header / R G B / Checksum / Footer / CRC)
아두이노/NodeMCU로 똑같이 재현해 전송 성공

패킷 구조 (역분석 결과):

| Preamble | Header | R | G | B | Checksum | Footer | CRC |

예: Red = 1f 00 00, Blue = 00 07 1f, White = 1f 1f 1f

4-6. 음파 통신 응원봉

교수님 강조: "블랙핑크 응원봉에 쓴 방식이에요. 음파 IoT 칩셋을 심어서 사람이 못 듣는 고주파(20,000Hz 근처)에 데이터를 실어 보내는 방식입니다. 스피커에서 나오는 음악에 데이터를 숨겨서 보내면 끝이에요."

회사: 아이시냅스 (iSynapse) — SoundCast 기술
원리: 공연장 음악 속 비가청 고주파(~20kHz) 에 데이터 임베드
응원봉에 고성능 마이크로폰 센서 탑재 → 음파 수신 → LED 색 변경

4-7. IoT 응원봉이 주는 시사점

교수님 강조: "이게 진짜 핵심이에요. 디지털 기술이 주는 새로운 아날로그 경험입니다. 선이 없어지는 경험, 새로운 시각적 경험. 뭔가 만들 때 UX 관점에서 사용자 경험을 어떻게 넣을지를 항상 고민해야 합니다. 사람은 다 아날로그예요."

통신 + 모바일 앱 + 서버 세 가지가 합쳐진 IoT 시스템
K-POP 덕분에 응원봉 문화가 해외로 수출되는 중
사이드 프로젝트 가능성: 재미를 찾는 덕업일치

⭐ 시험 포인트

응원봉 최초 특허: SM 엔터테인먼트 (2016년)
콘서트 모드: RF/ZigBee (2.4GHz, 브로드캐스트)
개인 모드: BLE (Bluetooth Low Energy, 1:1)
음파 통신: 비가청 고주파(~20kHz)에 데이터 임베드
패킷 구조: Preamble - Header - RGB - Checksum - Footer - CRC

Part 2 — 우주 통신과 마션 (week10_02)

5. 우주 통신 — 보이저 호

5-1. 보이저(Voyager) 1, 2호

교수님 강조: "1977년에 발사됐어요. 지금 태양계를 벗어나서 오르트 구름 영역을 지나고 있습니다. 지금도 나사 홈페이지 가면 위치 파악하고 통신이 되고 있어요."

사양	수치
발사 연도	1977년
CPU	1.6MHz
RAM	4KB
통신 속도	160bps
현재 거리	약 183억 km 이상

교수님 강조: "4KB면 우리 와이어샤크 캡처 패킷 한 개가 1.5KB잖아요. 패킷 3~4개도 못 담는 용량이에요. 근데 77년도에 그걸로 부팅하고 사진 찍고 통신한 겁니다."

5-2. 우주 통신의 특성

전파 지연 시간: 183억 km ÷ 30만 km/s ≈ 편도 약 17시간
왕복 지연: 약 34시간
사진 1장 수신: 몇 달 소요 (저속 통신 + 재조립)

교수님 강조: "우리 숙제할 때 몇 m 안 되는데도 잡음 때문에 잘 안 되잖아요. 우주에서 183억 km 떨어진 데서 보내는 신호를 받으려면 안테나가 어마어마하게 커야 됩니다."

5-3. 딥스페이스 네트워크 (DSN)

지구는 자전하기 때문에 어느 한 곳의 안테나로는 항상 수신이 불가능하다. 그래서 미국, 스페인, 호주 세 곳에 대형 안테나를 설치해 커버리지를 확보한다.

5-4. 오류 정정

교수님 강조: "우주에서는 오류가 많이 생겨요. 그래서 여러분 배운 bit 오류 탐지·복구 코드, 이런 것들이 같이 있어야 됩니다. 기본 원리는 동일해요."

⭐ 시험 포인트

보이저 사양: CPU 1.6MHz, RAM 4KB, 통신속도 160bps (1977년)
딥스페이스 네트워크: 미국, 스페인, 호주 (지구 자전 커버)
우주 통신 핵심 문제: 전파 지연 (편도 17시간), 오류율, 낮은 신호 강도

6. ⭐ 마션 — 통신으로 보는 컴공

교수님 강조: "마션 소설 작가 앤디 위어는 컴공 전공자예요. 이 소설은 데이터 통신과 컴퓨터 공학의 교과서라고 할 수 있어요. 영화 또는 소설 다시 봐야 됩니다."

6-1. 상황 설정

화성에 혼자 남겨진 마크 와트니. 생존하려면 지구와 통신이 첫 번째 조건. 패스파인더(화성 탐사 로버)를 발견하고 통신 수단으로 활용 시도.

6-2. 통신 진화 과정

1단계 — 바이너리 (0/1)

카메라를 돌려서 YES/NO만 전달
문제: 왕복 지연 32분, 전송량 극소

2단계 — 아스키(ASCII) + 16진수

교수님 강조: "알파벳 26자를 360도로 나누면 13도밖에 안 돼요. 각도가 너무 좁아 구별이 안 되니까, 알파벳 26개 대신 16진수(0~F, 16개)로 줄이자 → 이게 아스키 코드예요. 컴공 안 나왔으면 이 발상이 어디서 나오겠어요?"

16진수로 아스키 코드 표현 → 예: 48 = H
카메라로 16진수 숫자 패널 지목 → 지구에서 받아쓰기 → 단어 완성

3단계 — 채팅 (운영체제 업데이트)

20MB 운영체제 업데이트가 필요
문제: 4초에 1B 속도 → 20MB 전송 시 약 3년 소요 → 불가능
해결책: 지구에서 20개의 명령어(16진수 hex edit)로 특정 파일을 수동으로 고쳐서 채팅 기능 활성화

교수님 강조: "리눅스 USR/lib/habcom.so 파일 열어서 16진수로 직접 고치는 장면이 소설에 나와요. 이거 아는 사람이 컴공밖에 없어요. 이런 소설을 쓴 작가가 컴공 개발자라는 거죠."

6-3. 통신 개념 총정리 (마션 관점)

개념	마션에서의 예시
전파 지연 (Propagation Delay)	화성-지구 왕복 32분
전송 속도 (Throughput)	4초에 1B (극도로 낮음)
오류 탐지/복구	우주 전파 환경에서 필수
인코딩	아스키 → 16진수 변환으로 효율화
프로토콜 설계	카메라 각도 = 데이터 전송 채널

교수님 강조: "이 영화 통신 관점에서 다시 보면 왕복 지연시간, 처리율, 오류, 인코딩 개념들이 다 들어가 있어요. 완벽한 인재입니다."

⭐ 시험 포인트

마션 화성-지구 왕복 지연: 32분
통신 속도: 4초에 1B → 20MB OS 업데이트 시 3년 소요
해결 방법: 바이너리 → 16진수(아스키) 카메라 통신 → 운영체제 패치

7. 숙제 안내

교수님 강조: "마션 영화 또는 소설 보고 손글씨로 한 페이지 감상문 작성. 타이핑, 아이패드 펜슬 안 됩니다. 무조건 종이에 손으로 써야 됩니다. 스캔도 이쁘게 해야 돼요."

마감: 월요일
분량: A4 1페이지
형식: 손글씨 (볼펜/연필/붓펜 모두 가능), 스캔 후 제출

참고 — 교수님의 마무리 메시지 (궁즉변 변즉통 통즉구)

교수님 강조: "고흐는 37세에 죽었는데 화가는 27세부터 시작해서 10년 동안 2,100점을 그렸어요. 1년에 200점. 여러분 1년에 코드 200개 짤 수 있어요? 이게 '궁(窮)'입니다. 끝까지 가봐라."

궁즉변 변즉통 통즉구 (窮則變變則通通則久) — 주역

궁(窮): 극에 달하면 (최선을 다하면)
변(變): 변화가 온다
통(通): 길이 뚫린다
구(久): 오래간다

교수님 강조: "고흐처럼 1년에 200개 코드를 완성해 보세요. 그게 궁이에요. 그러면 여러분이 바뀌어요. 양적 축적이 질적 변환이 됩니다. 공부를 못해요, 소질 없어요가 아니고 — 진짜 최선 다 해봤어요?"

이번 강의 핵심 요약

라우팅 테이블 검색: 100만 개 중 4μs 이내 탐색 → B-Tree + Hash + 고속 메모리 조합 (자료구조 실전 적용)
응원봉 통신 2모드: 콘서트(RF/ZigBee 브로드캐스트) vs 개인(BLE 1:1 페어링) — 반드시 구분
응원봉 특허: SM 엔터테인먼트 2016년 최초 출원, 이후 HYBE 등 후발 진입
우주 통신(보이저): 1977년 발사, RAM 4KB, 160bps, 편도 17시간 전파 지연, DSN(미국·스페인·호주)
마션: 화성-지구 왕복 32분 지연 / 바이너리→아스키 16진수→OS 패치로 통신 진화 / 전파 지연·처리율·오류 개념의 실전 예시

[데이터통신] 9주차 강의노트

hyeongseop — Tue, 12 May 2026 13:27:35 +0900

Chapter 8: Switching — 선이 만나면? 교차로

이번 강의 범위: 네트워크 계층 / 회선 교환 vs 패킷 교환 개요

1. 스위칭(Switching)이란?

네트워크에서 "선(링크)이 만나는 교차로" 역할을 하는 장비가 노드(스위치/라우터)다. 도로에서 교차로가 직진·좌회전·우회전 판단을 내리듯, 네트워크 장비도 패킷의 목적지 주소를 보고 어느 방향으로 내보낼지 결정한다.

교수님 강조: "여러분이 학교 올 때 교차로에서 판단하는 거랑 똑같아요. 사거리에서 '충남대학교 가려면 직진'이라는 판단의 근거가 바로 다익스트라(Dijkstra) 알고리즘입니다. 라우터도 동일한 원리로 동작해요."

교환(switching)의 대상은 크게 세 가지다:

전화(Call) → 회선 교환(Circuit Switching)
패킷(Packet) → 패킷 교환(Packet Switching)
메시지(Message) → 메시지 교환

2. 네트워크 구조: 링크와 노드

실제 대학교 캠퍼스 네트워크를 예로 들면:

단말(PC/스마트폰) → 강의실 스위치 → 건물 스위치 → 백본(Backbone) → 외부 인터넷
백본은 주요 거점(서울·대전·대구·부산)을 고속 스위치 + 광케이블로 연결

교수님 강조: "백본을 빼면 나머지는 다 트리(Tree) 구조예요. 그런데 백본은 뭐죠? 모든 노드가 서로 연결된 fully-connected graph = 메시(Mesh)입니다."

왜 백본은 Mesh(Fully-Connected Graph)인가?

교수님 강조: "서울-대전 광케이블에 불이 났어요. 끊겼습니다. 그러면 서울→광주→대전, 서울→대구→대전 같은 우회 경로가 반드시 있어야 해요. 통신망은 고장나도 작동해야 하기 때문에 여러 경로를 만들어 두는 겁니다."

충남대 학교 네트워크는 외부 통신사를 KT, SKT, LG U+ 세 곳 동시에 연결해 한 곳 장애 시 다른 곳으로 우회한다.

⭐ 시험 포인트

백본 네트워크의 그래프 형태: Fully-connected graph (= Mesh 네트워크)
백본 제외 일반 네트워크: 트리(Tree) 구조
여러 통신사를 쓰는 이유: 장애 대응(fault tolerance)

3. 스위치 vs 라우터 용어 정리

용어	의미	계층
스위치(Switch)	교환하다(switching)에서 유래. 전화망부터 쓰던 용어	일반적 용어
라우터(Router)	Route(경로)에서 유래. "길 찾아주는 장비"	TCP/IP 네트워크 계층

교수님 강조: "라우터는 이름 자체가 '경로(route)'에요. 네트워크 계층의 핵심 역할 = 길 찾기 = 최단 경로 알고리즘."

4. 회선 교환(Circuit Switching)

동작 방식

전화망에서 사용하는 방식으로, 통신 시작 전 반드시 연결 설정, 통신 종료 후 반드시 연결 해지한다.

전화 버튼을 누르면 → 출발지~목적지까지 전용 경로(회선)가 물리적으로 예약된다.

교수님 강조: "전화는 왜 번호 누르고 상대방이 받아야 말할 수 있을까? 이게 바로 연결 설정 때문입니다. 그 연결 과정에서 중간 교차로마다 64Kbps 전용 대역폭을 예약하는 거예요. 중간고사에도 나왔고 중요한 개념이에요."

핵심 특징

전화 목소리 → PCM 인코딩 → 64Kbps 보장
이동통신은 코덱에 따라 약 16Kbps로 낮아지지만 자원 확보 원리는 동일
대역폭 예약 방식: TDM(Time Division Multiplexing) 슬롯 예약
연결을 만들고 데이터를 안 보내도 자원은 계속 점유 → 자원 낭비 가능성

교수님 강조: "24개 채널이 있는데 어떤 사람이 전화 연결만 해놓고 말을 안 하면? 그 64Kbps는 아무도 못 써요. 자원이 낭비됩니다."

회선 교환기 역사 (교수님 언급)

초창기: 사람(전화교환원)이 직접 선을 꽂아 연결
1902년 전화교환원 등장
1971년 자동식 전화 개통 (백색 전화기)
1987년 전국 자동 교환망 완성

⭐ 시험 포인트

회선 교환은 통신 시작 전 연결 설정 필수 / 종료 후 해지 필수
연결 = 64Kbps 전용 대역폭 예약 = 서비스 품질(QoS) 보장
딜레이가 예측 가능하고 일정하다
자원을 예약하므로 쓰지 않아도 점유됨 → 비효율

5. 패킷 교환(Packet Switching)

동작 방식

연결을 사전에 만들지 않는다. 패킷(Packet) 단위로 데이터를 분할해 네트워크에 던지면, 각 라우터가 목적지 주소를 보고 다음 경로를 결정한다 (= 데이터그램 방식).

교수님 강조: "인터넷은 연결 없어요. 네이버 클릭하면 그냥 패킷 바로 보내요. 연결 만들고 보내는 게 아닙니다. 그래서 여러분 30명이 동시에 써도 '너는 40번째라 못 써' 이런 게 없어요."

각 패킷의 헤더에 목적지 IP 주소가 찍혀 있음
라우터는 목적지 주소 기반으로 라우팅 테이블 조회 → 경로 결정
같은 목적지의 패킷도 경로가 다를 수 있다 (링크 상태 변화 반영)
인터넷 = 패킷 교환망 기반

교수님 강조: "경부고속도로가 막히면 세종시 우회하듯, 라우터도 링크 상태에 따라 경로를 바꿉니다. 링크의 cost/metric 기반으로 최단 경로를 계속 재계산해요."

Store-and-Forward (저장 후 전달)

교수님 강조: "패킷이 라우터에 들어오면 메모리에 저장했다가 헤더를 읽고 목적지 주소를 보고 나서 내보냅니다. 메모리 = 큐(Queue)입니다. 스택이 아니고요, 들어온 순서대로 처리해요."

큐잉 딜레이(Queueing Delay)

패킷 교환의 필연적인 단점이다.

교수님 강조: "라우터는 폰노이만 구조랑 같아요. 메모리에서 패킷 읽어서 처리하니까 패킷이 몰리면 반드시 대기 지연이 발생합니다. 학교 개강 초기에 2만 명이 인터넷 쓰면 느린 이유가 바로 이거예요. 큐잉 딜레이는 없앨 수 없는 구조적 문제입니다."

통신 지연시간의 4가지 종류

종류	설명
전파 시간(Propagation)	신호가 물리적으로 이동하는 시간
전송 시간(Transmission)	패킷을 링크에 싣는 시간
큐잉 시간(Queueing)	라우터 메모리에서 대기하는 시간 (가변적)
처리 시간(Processing)	라우터가 헤더를 분석하는 시간

참고 (PDF 보충): 위 4가지 중 큐잉 딜레이가 가장 가변적이며 예측 불가능하다. 나머지 세 가지는 상대적으로 일정하다.

⭐ 시험 포인트

패킷 교환은 연결 설정 없음, 패킷 단위 전송
라우터 동작 = Store-and-Forward (저장 후 전달)
큐잉 딜레이는 반드시 발생하며 예측 불가
같은 목적지 패킷도 경로가 달라질 수 있음
자원을 예약하지 않으므로 효율적이지만 QoS 미보장

6. 회선 교환 vs 패킷 교환 비교

항목	회선 교환 (Circuit Switching)	패킷 교환 (Packet Switching)
연결 설정	필수 (통신 전)	불필요
연결 해지	필수 (통신 후)	불필요
대역폭	전용 예약 (64Kbps)	공유 (베스트 에포트)
QoS(서비스 품질)	보장됨	보장 안 됨
지연 시간	예측 가능하고 일정	가변적 (큐잉 딜레이)
자원 효율성	낮음 (안 써도 점유)	높음 (필요할 때만 사용)
대표 사례	유선전화, 이동통신	인터넷
핵심 장비	회선 교환기(Crossbar, TSI)	라우터

교수님 강조: "자원을 효율적으로 쓰는 건 패킷 교환, 서비스 품질(QoS)을 보장하는 건 회선 교환. 예측 가능한 딜레이를 보장하는 것도 회선 교환."

7. 라우팅 알고리즘

라우터가 경로를 찾는 핵심 알고리즘 두 가지를 반드시 알아야 한다:

교수님 강조: "이거는 무조건 알아야 돼요. 모르면 간첩입니다. 우리가 매일 쓰는 인터넷 라우터에 이 두 알고리즘이 실제로 구현돼서 동작하고 있어요."

알고리즘	특징	인터넷 프로토콜
다익스트라(Dijkstra)	단일 출발점 최단 경로, 음수 간선 불가	OSPF (내부 라우팅)
벨만-포드(Bellman-Ford)	음수 간선 처리 가능, 분산 방식	BGP, RIP (외부/거리벡터 라우팅)

교수님 강조: "여러분 공유기에 다익스트라랑 벨만-포드가 구현돼 있어요. 라우터가 별거겠어요? 그게 여러분 집 공유기에도 들어가 있습니다."

BGP 라우팅 테이블 규모: 현재 인터넷 전체 약 100만 개 이상의 IP prefix 존재 (지속 증가 중)

8. 패킷 교환기 = 라우터

라우터 역사

1969년 ARPANET 구축 시 사용한 최초 라우터: IMP(Interface Message Processor)
ARPANET은 미국 국방부(DARPA) 프로젝트 → 전쟁 중에도 통신이 유지되는 네트워크가 목적
최초의 상용 라우터 강자: 시스코(Cisco) (90년대 IT 버블 시절 NVIDIA급 위상)
현재 점유율: 시스코 1위, 화웨이 2위

교수님 강조: "GPU 클러스터 연결하는 스위치·라우터 1등 회사가 지금은 NVIDIA예요. GPU가 1억 원이면 스위치는 3~4억 원. GPU 클러스터엔 NVLink 스위치가 필수입니다. AI 시대에 라우터가 다시 핵심이 됐어요."

공유기(Home Router) = 인터넷 라우터

교수님 강조: "공유기가 바로 인터넷 라우터예요. 리눅스로 동작하고, 내부에 다익스트라·벨만-포드 알고리즘이 다 들어가 있어요. 클라우드 VPC 방화벽 설정이랑 공유기 설정이 개념상 동일합니다."

공유기의 구성 요소:

외부 인터넷 회선 (WAN)
내부 유선 LAN / 무선 LAN
VPN
방화벽 (iptables)
NAT / 포트 포워딩

참고 (PDF 보충): traceroute, netstat -rn, ifconfig, iptables 명령어로 라우터 내부 상태 확인 가능. telnet route-views.routeviews.org로 실제 인터넷 백본 BGP 라우터에 접속해 볼 수 있다.

⭐ 시험 포인트

ARPANET 최초 라우터 이름: IMP(Interface Message Processor)
ARPANET 개발 목적: 국방부(전쟁 중에도 동작하는 통신망)
공유기 = 패킷 교환기 = 인터넷 라우터
공유기 내부는 리눅스 기반

이번 강의 핵심 요약

회선 교환: 통신 시작 전 연결 필수 → 64Kbps 전용 대역폭 확보 → QoS 보장, 자원 비효율 (전화망)
패킷 교환: 연결 없이 패킷 단위 전달 → QoS 미보장, 자원 효율적, 큐잉 딜레이 필연 (인터넷)
큐잉 딜레이: 라우터의 Store-and-Forward 구조 때문에 반드시 발생하며 예측 불가
라우팅 알고리즘: 다익스트라 + 벨만-포드 → 인터넷 라우터에 실제 구현됨 (반드시 암기)
백본 네트워크: Fully-connected graph(Mesh) 구조 → 장애 우회 경로 확보 목적

[코드트리] 코딩테스트 준비, 갭체크 후기

hyeongseop — Mon, 11 May 2026 16:07:08 +0900

코드 트리 청약통장 1회차 납입을 위해 갭체크를 실시했다.

갭체크는 나의 현재 코딩테스트 실력을 테스트하는 과정으로 내 실력을 분석 받을 수 있었다.
출력, 조건문, 배열, 탐색, BFS까지의 영역에 대한 전반 영역에서 테스트를 진행할 수 있었다.

나는 사실 코테 공부를 1도 해보전 적이 없었기 때문에 그냥 모르는 문제는 당당하게 넘어갔다!
갭체크의 결과 내가 애매하게 아는 개념과 완전히 모르는 개념을 구분해서 알려주었다.
나는 기본적인 출력과 조건문은 수행할 수 있었지만,
배열과 탐색 부분에서는 조금 애매한 개념이 있는걸 알 수 있었고
완전탐색과 BFS 부분에서는 완전히 모른다는 걸 알 수 있었다.
(역시 학교 수업을 듣는다고 해서 내가 그 개념을 완전히 안다고 할 수가 없다.)

아쉽게도 내가 골똘히 고민한 문제가 없었고
내가 현재 쓸 수 있는 언어가 C 밖에 없고
내가 앞으로 수행할 언어는 파이썬이기 때문에 앞으로 내 학습 기록을 잘 봐주면 좋겠다!

그 이후 추천 학습 코스를 안내 받을 수 있었다.
그럼 오늘부터 시작해 나는 몇 주까지 이 빈틈의 개념을 채워갈 수 있을까?
아무래도 프로그래머스는 기타 문제를 그냥 풀어내는거였지만, 코드트리의 경우는 커리큘럼을 짜줘서 내가 문제를 선택할 시간이 줄어들어 좋은거 같다. (그냥 학원 다니는 느낌.)

[코드트리 바로가기]
https://www.codetree.ai/ko

Codetree: Master Coding Interviews - Data Structures & Algorithms

Master algorithms, ace tech interviews, and elevate your coding skills with Codetree's systematic curriculum and expert-crafted problem sets.

www.codetree.ai

#코드트리 #코딩테스트 #코테공부 #코테준비 #알고리즘공부 #갭체크

[OS] 9주차 강의노트

hyeongseop — Mon, 11 May 2026 11:09:06 +0900

운영체제 8주차 강의노트 — Memory Management (Chapter 7)

0. TL;DR

메모리 관리의 핵심 목표는 multiprogramming을 효과적으로 지원하는 것이다. 프로세스를 메모리에 많이 올릴수록 CPU 활용도가 높아지지만, 프로세스당 할당량이 너무 적으면 page fault가 빈번해져 오히려 성능이 저하된다.
Logical address(프로그램 상의 주소)를 Physical address(실제 메모리 주소)로 변환하는 Address Translation은 execution time에 일어나며, 이 변환이 빠르고 정확하게 이루어져야 한다.
메모리 분할 방식은 크게 segmentation(가변 크기)과 paging(고정 크기)으로 나뉘며, OS는 관리 단순성 때문에 paging을 선호한다.
Paging에서는 Internal Fragmentation만 발생하고 External Fragmentation은 발생하지 않는다. Segmentation 계열(Dynamic Partitioning)에서는 External Fragmentation이 발생하며 Compaction으로 해결한다.
Page Table은 각 프로세스마다 하나씩 존재하며, logical address의 page number를 physical address의 frame number로 변환하는 자료구조다.

1. 개요

이번 챕터부터 주제가 Process 관리에서 Memory 관리로 넘어온다.

학습 목표:

한정된 메모리 공간을 여러 프로세스에게 효율적으로 할당하는 방법을 이해한다.
Logical address와 Physical address의 차이, 그리고 Address Translation 메커니즘을 이해한다.
Fixed/Dynamic Partitioning, Paging, Segmentation 각각의 동작 방식과 장단점을 비교할 수 있다.
Internal/External Fragmentation의 개념과 해결 방법을 설명할 수 있다.
Page Table을 이용한 주소 변환 과정을 단계별로 따라갈 수 있다.

전체 흐름: 메모리 관리의 필요성 → Address Translation 개념 → 메모리 분할 기법들 → Fragmentation 문제 → Paging 상세 → TLB

2. 본문

2.1 메모리 관리의 필요성과 목표

OS에서 메모리 공간은 OS 영역과 user process 영역으로 나뉜다. 메모리 관리의 핵심 목표는 multiprogramming을 잘 지원하는 것이다. Multiprogramming이란 메모리에 다수의 프로세스를 동시에 올려놓아 CPU가 idle 상태가 되지 않도록 하는 방식이다.

프로세스를 더 많이 메모리에 올리기 위해 각 프로세스에 메모리를 조금씩만 할당하면 어떻게 될까? 실행 중 필요한 코드나 데이터가 메모리에 없을 경우 하드디스크에서 가져와야 하는데, 이 대기 시간(page fault) 때문에 컴퓨터가 느려진다. 반대로 각 프로세스에 메모리를 넉넉하게 주면 프로세스 개수가 줄어들고, 모든 프로세스가 I/O 대기 상태에 빠질 경우 CPU 활용도가 낮아질 수 있다.

따라서 프로세스 개수와 프로세스별 메모리 할당량을 적절히 조절하는 것이 메모리 관리의 핵심이다.

Memory Management가 만족해야 할 5가지 요구사항(PPT Table 7.1 + 슬라이드):

요구사항	설명
Relocation	프로세스는 swap in/out 시 다른 메모리 위치로 이동할 수 있어야 한다. 항상 동일한 위치에 올라올 필요가 없다.
Protection	프로세스는 다른 프로세스의 메모리 영역에 허가 없이 접근하면 안 된다. 메모리 참조는 runtime에 검사된다.
Sharing	여러 프로세스가 동일한 코드(예: 한글 프로그램)를 공유할 수 있어야 한다. Protection과 양립 가능하게 구현한다.
Logical Organization	프로그램은 모듈(함수 단위)로 구성된다. Segmentation이 이를 가장 잘 표현한다.
Physical Organization	메모리 관리는 OS가 담당해야 하며, 프로그래머가 직접 처리하면 안 된다(Overlay 시대의 한계).

Overlay (역사적 맥락)

아주 초기에는 메모리 크기가 너무 작아 프로그램 전체를 올릴 수 없었다. 그래서 프로그램을 잘라서 순차적으로 올리고, 앞 부분 실행 결과를 디스크에 저장한 후 다음 부분을 올리는 Overlay 기법을 사용했다. 이는 프로그래머가 직접 메모리 관리를 해야 했던 방식으로, 현재는 사용하지 않는다.

2.2 Address Translation

주소의 3단계 변환

Source Code        --[컴파일러]--->   Object Code        --[로더/실행]--->   Executable Code
Symbolic Address               Logical/Relative Address                Physical Address
(변수명 A, B 등)                (0번지부터의 상대 주소)                   (실제 메모리 위치)

Symbolic Address: 소스 코드에서 사용하는 변수명. 프로그래머는 메모리 주소를 신경 쓰지 않는다.
Logical (Relative) Address: 컴파일 후 프로그램의 시작을 0으로 기준 삼아 붙여진 상대 주소. 프로그램이 메모리 어디에 올라가든 내부적인 번호는 동일하다.
Physical (Absolute) Address: 실제 메모리(RAM) 상의 주소. 프로세스가 메모리의 어느 위치에 적재되느냐에 따라 달라진다.

예를 들어, 프로세스가 메모리 100번지부터 시작했고 logical address가 101이라면, physical address는 201이다. 같은 프로세스가 메모리 200번지부터 시작하면 physical address는 301이 된다.

Physical Address = Base Address + Logical(Relative) Address

CPU가 메모리에 접근하려면 반드시 physical address가 필요하다. 따라서 logical address → physical address 변환이 빠르게 이루어져야 한다.

Address Translation이 일어나는 시점

세 가지 시점이 가능하다.

Compile time: 컴파일 시점에 physical address를 직접 박아 넣는다. 프로세스가 항상 같은 위치에 올라가야 해서 비현실적이다.
Load time: 메모리에 올라올 때 relative address를 physical address로 일괄 변환한다. 올라온 이후에는 위치가 고정된다.
Execution time (runtime): 실행 중 매 메모리 참조 시점에 CPU 하드웨어(Base Register + Adder)를 통해 변환한다.

OS는 Execution time 방식을 사용한다. 이유는 Relocation 때문이다. 프로세스는 swap in/out 시마다 다른 프레임에 올라올 수 있으므로, 미리 주소를 고정할 수 없다. 페이지 테이블의 프레임 번호를 수정하는 것만으로 re-mapping이 가능하다.

하드웨어 지원(Figure 7.8): Base Register와 Bounds Register를 이용해 relative address를 physical address로 변환하고, 동시에 유효 범위를 벗어나지 않는지 Comparator로 검증한다.

2.3 메모리 분할 기법 개요

메모리를 여러 프로세스에게 나눠주는 방식은 크게 세 가지다.

Segmentation: 모듈(함수) 크기에 맞게 가변 크기로 할당 → 크기가 제각각
Fixed Partitioning: 미리 고정된 크기로 나눔 → 크기가 다양하거나 동일하게 나눔
Simple Paging: 모든 파티션을 동일한 크기로 나눔

OS는 3번 방식(Paging)을 선호한다. 이유는 Address Translation이 단순하고, 관리 overhead가 작기 때문이다.

전체 메모리 관리 기법 비교 (PPT Table 7.2):

기법	설명	장점	단점
Fixed Partitioning	시스템 부팅 시 정적으로 파티션을 나눔	구현 단순, overhead 적음	Internal Fragmentation, 활성 프로세스 수 고정
Dynamic Partitioning	프로세스 크기에 맞게 동적으로 할당	Internal Fragmentation 없음	External Fragmentation → Compaction 필요
Simple Paging	동일 크기 frame으로 나누고, 프로세스도 page로 나눔	External Fragmentation 없음	소량의 Internal Fragmentation
Simple Segmentation	프로세스를 가변 크기 segment로 나눔	Internal Fragmentation 없음	External Fragmentation
Virtual Memory Paging	Simple Paging + 전체 page를 올릴 필요 없음	Multiprogramming 극대화, 큰 virtual address space	복잡한 메모리 관리 overhead
Virtual Memory Segmentation	Simple Segmentation + 전체 segment를 올릴 필요 없음	위와 동일, Protection/Sharing 지원	복잡한 메모리 관리 overhead

2.4 Fixed Partitioning

메모리를 미리 고정된 크기로 나눠놓는 방식이다. Equal-size(모두 같은 크기)와 Unequal-size(2M, 4M, 6M, 8M 등 다양한 크기)가 있다.

[Equal-size]          [Unequal-size]
OS (8M)               OS (8M)
8M                    2M
8M                    4M
8M                    6M
8M                    8M
8M                    8M
8M                    12M
8M                    16M

문제점 (Internal Fragmentation): 프로세스가 파티션보다 작으면 그 차이만큼 메모리가 낭비된다. 예를 들어 8M 파티션에 3M 프로세스가 올라오면 5M은 사용 불가.

프로세스 할당 방식은 파티션별 큐(queue per partition)와 단일 큐(single queue) 두 가지가 있다.

2.5 Dynamic Partitioning

프로세스 크기에 딱 맞게 파티션을 동적으로 생성한다. Internal Fragmentation은 없지만, 시간이 지나면서 External Fragmentation이 발생한다.

(a) 빈 메모리 56M     (b) Process 1 로드(20M)    ...    (e) Process 2 종료 후
OS                     OS                               OS
                       Process 1 (20M)                  Process 1 (20M)
                       빈 공간 (36M)                     빈 공간 (14M)  ← 단편화
                                                         Process 3 (18M)
                                                         빈 공간 (4M)   ← 단편화

여러 작은 빈 공간이 흩어져 있어서, 합치면 충분한 공간인데 연속적으로 할당할 수 없는 상황이 External Fragmentation이다.

해결책: Compaction(조각 모음)

OS가 메모리에 적재된 프로세스들을 한쪽으로 몰아서 빈 공간을 하나로 합친다. 하드디스크의 조각 모음과 같은 원리다. 단, CPU 시간이 많이 소모되는 것이 단점이다.

2.6 Placement Algorithms

Dynamic Partitioning이나 Segmentation에서, 새 프로세스를 어느 빈 공간에 할당할지 결정하는 알고리즘이다.

알고리즘	방식	특징
Best-fit	모든 빈 공간을 탐색하여 요청 크기에 가장 가까운 공간에 할당	공간 낭비 최소화, 탐색 시간 오래 걸림
First-fit	메모리 처음부터 탐색, 충분한 첫 번째 공간에 할당	탐색 시간 짧음
Next-fit	직전 할당 위치부터 탐색 시작, 충분한 다음 공간에 할당	First-fit의 변형
Worst-fit	가장 큰 빈 공간에 할당	할당 후 남은 공간이 커서 다른 프로세스에게 재활용 가능

Worst-fit의 의외성: 가장 큰 공간에 넣으면 할당 후에도 큰 여유 공간이 남아, 이후에 다른 프로세스를 수용하기 좋다. Best-fit은 공간을 너무 딱 맞게 쓰다 보니 나머지 조각이 너무 작아 쓸모없어질 수 있다.

Figure 7.5 예시(16M 블록 할당 시):

[Before]                 [After]
8M (allocated)           8M
12M (free)               12M → First-fit: 여기에 16M 할당 (6M 남음)
22M (free)               6M 잔여
18M (free)               18M → Best-fit: 여기에 16M 할당 (2M 남음)
8M (allocated)           8M
6M (free)                6M
14M (allocated) ←last    14M
36M (free)               20M 잔여 → Next-fit & Worst-fit: 여기에 할당

2.7 Buddy System

Fixed와 Dynamic Partitioning의 절충안이다. 메모리 블록을 2의 지수 크기로만 할당한다.

전체 메모리(예: 1MB)에서 시작하여 요청 크기를 수용할 수 있는 최소 2^k 크기 블록을 찾는다.
블록이 너무 크면 반으로 분할(split)하고, 해제 시 인접한 같은 크기의 "buddy" 블록이 비어있으면 합친다(merge).

1M 전체
└─ Request 100K → 128K 블록 할당 (A)
   └─ Request 240K → 256K 블록 할당 (B)
      └─ Request 64K → 64K 블록 할당 (C)
         └─ Request 256K → 256K 블록 할당 (D)

일반 Segmentation처럼 임의의 크기를 모두 지원하지는 않지만, 2의 지수 단위로 관리하므로 메모리 주소 계산이 기계적으로 쉽다. Linux 커널의 물리 메모리 할당자가 이 방식을 사용한다.

2.8 Fragmentation 정리

종류	발생 상황	해결 방법
Internal Fragmentation	할당된 공간 내에서 프로세스가 다 쓰지 못하는 낭비 (Fixed Partitioning, Paging의 마지막 page)	파티션/페이지 크기를 작게 함 (단, 너무 작으면 관리 overhead 증가)
External Fragmentation	빈 공간의 합은 충분하지만 연속되지 않아 할당 불가 (Dynamic Partitioning, Segmentation)	Compaction

Paging에서는 External Fragmentation이 발생하지 않는다. 동일한 크기의 frame에 어떤 page든 올릴 수 있기 때문이다. Internal Fragmentation은 마지막 page 하나에서만 발생한다.

2.9 Paging 상세

기본 개념

Page: 프로세스(secondary memory)를 동일한 고정 크기로 나눈 조각
Frame: 메인 메모리를 동일한 고정 크기로 나눈 조각 (page와 크기 동일)

프로세스의 각 page는 메모리의 임의의 frame에 올라갈 수 있다. 연속된 frame에 올라갈 필요가 없다.

Process A            Main Memory
Page 0  ──────────→  Frame 0   (A.0)
Page 1  ──────────→  Frame 1   (A.1)
Page 2  ──────────→  Frame 2   (A.2)
Page 3  ──────────→  Frame 3   (A.3)

Process C (다른 위치에 분산)
Page 0  ──────────→  Frame 7
Page 1  ──────────→  Frame 8
Page 2  ──────────→  Frame 9
Page 3  ──────────→  Frame 10

하드디스크에서는 데이터가 연속적으로 위치해야 seek time이 짧아지지만, 메모리에서는 전자적으로 접근하므로 연속성이 성능에 영향을 주지 않는다.

Page Table

Page Table은 OS가 각 프로세스마다 하나씩 생성하는 자료구조로, page number → frame number 매핑 정보를 갖는다. PCB(Process Control Block) 안에 포함된다.

Process C page table
Page 0 → Frame 7
Page 1 → Frame 8
Page 2 → Frame 9
Page 3 → Frame 10

Process B page table (swap out 상태)
Page 0 → (empty, in disk)
Page 1 → (empty, in disk)
Page 2 → (empty, in disk)

중요한 속성:

프로세스의 최대 크기는 page table의 entry 수로 결정된다. (예: entry가 10,000개 → 최대 10,000 pages)
시스템에서 최대 프로세스 개수는 PCB 테이블의 크기로 결정된다.
Swap in 시 반드시 이전과 같은 frame에 올라올 필요가 없다. Page table entry만 갱신하면 된다.

Logical Address → Physical Address 변환 (Figure 7.12a)

Page size = 1K (= 1024 bytes) 인 경우, logical address를 page number와 offset으로 분리한다.

Logical address: 1502 (10비트 이진수: 0000010111011110)
  → 16-bit 중 상위 6-bit = page number = 1
  → 하위 10-bit = offset = 478

(검증: 1 × 1024 + 478 = 1502 ✓)

Page table에서 page 1 → frame 6 (000110) 이라면:

Physical address = frame number (6-bit) || offset (10-bit)
                 = 000110 || 0111011110
                 = 0001100111011110

변환 과정 요약:

Logical Address [page# | offset]
       ↓
Page Table에서 page# 인덱스로 frame# 조회
       ↓
Physical Address = [frame# | offset]

2.10 TLB (Translation Lookaside Buffer)

Page table은 메모리(RAM)에 저장되어 있다. 즉, 메모리 접근 1번에 page table 조회 1번 + 실제 데이터 접근 1번, 총 2번의 메모리 접근이 필요하다. 이를 줄이기 위해 TLB라는 하드웨어 캐시를 사용한다.

TLB (Translation Lookaside Buffer): CPU 내에 위치한 소형 고속 연관 레지스터(associative register). 최근에 사용된 page number → frame number 매핑을 캐싱한다.
TLB hit: 해당 page number가 TLB에 있으면 바로 frame number를 얻음 → 메모리 접근 1번만 필요
TLB miss: TLB에 없으면 page table(메모리)을 조회 후 TLB에 업데이트 → 메모리 접근 2번 필요

2.11 Segmentation

프로그램을 논리적 단위(함수, 모듈)로 자른 가변 크기 조각(segment)을 메모리에 올리는 방식이다.

프로그램의 각 모듈/함수 크기가 다르기 때문에 segment 크기도 제각각이다.
Addressing: [Segment number | Offset] 형태의 2-part 주소를 사용한다.
Segment Table은 각 segment의 Base(시작 주소)와 Length(크기)를 저장한다.

Segmentation Address Translation 과정 (Figure 7.12b):

Logical Address [segment# | offset]
       ↓
Segment Table에서 segment# 인덱스로 (Base, Length) 조회
       ↓
if (offset >= Length) → 주소 오류 (trap)
else
   Physical Address = Base + offset

세그먼트 테이블:
Segment | Length  | Base
   0    | ...     | 0x00001000
   1    | ...     | 0x00100000

Paging과 Segmentation의 차이:

Paging에서는 logical address와 relative address가 동일하다. (page size가 균일하므로)
Segmentation에서는 segment 최대 크기에 맞춰 offset bit 수가 결정되기 때문에, logical address와 relative address가 다를 수 있다.
따라서 Paging의 Address Translation이 Segmentation보다 훨씬 단순하다.

Paged Segmentation

Segmentation과 Paging을 혼합한 기법이다. 각 segment를 다시 page 단위로 나누어 관리한다. Segment 1이 2개의 page를 필요로 하면 2개의 frame을 할당하는 식이다. 현실적으로 가장 발전된 형태지만 구현이 복잡하다.

3. 교수님 강조 포인트

※ Multiprogramming level을 무조건 높이는 게 능사가 아니다. 프로세스당 할당 메모리가 너무 적으면 page fault가 잦아져 컴퓨터가 느려지고, 너무 많이 주면 프로세스 개수가 줄어 CPU 활용도가 오히려 낮아진다. 적절한 균형이 핵심이다.

※ Address Translation은 execution time에 일어난다. Relocation 때문에 프로세스가 swap in될 때마다 다른 frame에 올라올 수 있으므로, 미리 주소를 고정(compile time 또는 load time)하면 안 된다.

※ Figure 7.12 (Logical → Physical Address Translation)를 완전히 이해해야 한다. 이해 못하면 집에서 반드시 다시 볼 것. page number와 offset이 어떻게 분리되고, page table을 통해 frame number를 찾아 physical address를 조합하는 과정이 이 그림 하나에 다 담겨 있다.

※ OS는 세 가지 분할 방식 중 동일 크기(Paging)를 선호한다. 이유는 단순성이다. Segmentation 방식은 모듈 크기가 제각각이어서 주소 관리가 복잡하고 overhead가 크다.

※ External Fragmentation은 Segmentation(Dynamic Partitioning) 계열에서만 발생하고, Paging에서는 발생하지 않는다. 대신 Paging에서는 마지막 page에만 Internal Fragmentation이 생긴다.

※ Swap in/out 시 프로세스는 이전과 다른 frame에 올라와도 된다. Page table의 frame 번호만 업데이트하면 나머지는 하드웨어가 자동으로 처리한다.

※ 프로세스의 최대 크기는 page table 크기로, 시스템의 최대 프로세스 개수는 PCB table 크기로 결정된다.

4. 핵심 용어 정리

용어 (영문)	설명
Frame	메인 메모리를 고정 크기로 나눈 블록
Page	프로세스(secondary memory)를 고정 크기로 나눈 블록. Frame과 크기가 동일
Segment	프로세스를 가변 크기로 나눈 블록 (함수/모듈 단위)
Logical Address	프로그램 내에서 사용하는 주소. 메모리의 실제 위치와 독립적
Relative Address	Logical address의 일종. 프로그램 시작(0)으로부터의 상대적 거리
Physical (Absolute) Address	메인 메모리의 실제 위치를 나타내는 주소
Address Translation	Logical/Relative address를 Physical address로 변환하는 과정
Relocation	프로세스가 swap in 시 다른 메모리 위치에 올라오는 것. 주소 변환이 동적으로 이루어져야 함
Internal Fragmentation	할당된 파티션/페이지 안에서 사용되지 않는 낭비 공간
External Fragmentation	빈 공간의 합은 충분하지만 연속적이지 않아 할당 불가한 상태
Compaction	External fragmentation을 해결하기 위해 OS가 프로세스들을 한쪽으로 몰아 빈 공간을 합치는 작업 (조각 모음)
Fixed Partitioning	메모리를 미리 고정된 크기의 파티션으로 나누는 방식
Dynamic Partitioning	프로세스 요청 크기에 맞게 파티션을 동적으로 생성하는 방식
Paging	메모리와 프로세스를 동일한 고정 크기(page/frame)로 나누어 관리하는 기법
Segmentation	프로세스를 논리적 단위(모듈/함수)의 가변 크기 segment로 나누어 관리하는 기법
Paged Segmentation	Paging과 Segmentation을 혼합한 기법. Segment를 다시 page 단위로 나눔
Page Table	OS가 프로세스마다 관리하는 자료구조. Page number → Frame number 매핑 정보 저장
Segment Table	Segmentation에서 각 segment의 Base(시작 주소)와 Length(크기)를 저장하는 테이블
TLB (Translation Lookaside Buffer)	CPU 내의 고속 하드웨어 캐시. 최근 page-frame 매핑을 저장하여 address translation 속도를 높임
Best-fit	빈 공간 중 요청 크기에 가장 가까운 것을 선택하는 배치 알고리즘
First-fit	처음부터 탐색하여 충분한 첫 번째 빈 공간에 할당하는 알고리즘
Next-fit	직전 할당 위치부터 탐색을 시작하는 First-fit 변형
Worst-fit	가장 큰 빈 공간에 할당하는 알고리즘
Buddy System	2의 지수 크기 블록만 사용하는 하이브리드 메모리 할당 기법
Overlay	초기 컴퓨터에서 메모리 부족 시 프로그램을 잘라서 순차적으로 실행하던 방식
Page Fault	실행하려는 코드/데이터가 메모리에 없고 disk에만 있을 때 발생하는 오류/인터럽트

5. 복습 질문

Multiprogramming level을 높이기 위해 프로세스당 메모리 할당량을 무한정 줄이면 어떤 문제가 발생하는가? 반대로 각 프로세스에 메모리를 매우 많이 할당하면 어떤 문제가 생기는가?
Logical(Relative) Address와 Physical Address의 차이를 설명하고, Address Translation이 왜 Compile time이나 Load time이 아닌 Execution time에 이루어져야 하는지 서술하라.
Internal Fragmentation과 External Fragmentation의 차이를 설명하고, 각각 어떤 메모리 관리 기법에서 발생하며 어떻게 해결할 수 있는지 기술하라.
Paging 기법에서 Logical address가 어떻게 Physical address로 변환되는지, Page Table을 이용한 과정을 단계별로 설명하라. (Page size = 1K, logical address = 2050인 경우를 예로 들어 설명하면 더욱 좋다.)
Best-fit, First-fit, Next-fit, Worst-fit 배치 알고리즘을 비교하고, 각 알고리즘의 trade-off를 설명하라. Worst-fit이 존재하는 이유는 무엇인가?
Paging이 Segmentation보다 OS에서 선호되는 이유를 Address Translation의 복잡성 및 Fragmentation 관점에서 설명하라.
TLB(Translation Lookaside Buffer)가 필요한 이유는 무엇이며, TLB hit와 TLB miss 각각의 경우에 메모리 접근이 몇 번씩 필요한지 설명하라.

[OS] 8주차 강의노트

hyeongseop — Mon, 11 May 2026 11:04:21 +0900

운영체제 8주차 강의노트 — Memory Management (Chapter 7)

0. TL;DR

메모리 관리의 핵심 목표는 multiprogramming을 효과적으로 지원하는 것이다. 프로세스를 메모리에 많이 올릴수록 CPU 활용도가 높아지지만, 프로세스당 할당량이 너무 적으면 page fault가 빈번해져 오히려 성능이 저하된다.
Logical address(프로그램 상의 주소)를 Physical address(실제 메모리 주소)로 변환하는 Address Translation은 execution time에 일어나며, 이 변환이 빠르고 정확하게 이루어져야 한다.
메모리 분할 방식은 크게 segmentation(가변 크기)과 paging(고정 크기)으로 나뉘며, OS는 관리 단순성 때문에 paging을 선호한다.
Paging에서는 Internal Fragmentation만 발생하고 External Fragmentation은 발생하지 않는다. Segmentation 계열(Dynamic Partitioning)에서는 External Fragmentation이 발생하며 Compaction으로 해결한다.
Page Table은 각 프로세스마다 하나씩 존재하며, logical address의 page number를 physical address의 frame number로 변환하는 자료구조다.

1. 개요

이번 챕터부터 주제가 Process 관리에서 Memory 관리로 넘어온다.

학습 목표:

한정된 메모리 공간을 여러 프로세스에게 효율적으로 할당하는 방법을 이해한다.
Logical address와 Physical address의 차이, 그리고 Address Translation 메커니즘을 이해한다.
Fixed/Dynamic Partitioning, Paging, Segmentation 각각의 동작 방식과 장단점을 비교할 수 있다.
Internal/External Fragmentation의 개념과 해결 방법을 설명할 수 있다.
Page Table을 이용한 주소 변환 과정을 단계별로 따라갈 수 있다.

전체 흐름: 메모리 관리의 필요성 → Address Translation 개념 → 메모리 분할 기법들 → Fragmentation 문제 → Paging 상세 → TLB

2. 본문

2.1 메모리 관리의 필요성과 목표

따라서 프로세스 개수와 프로세스별 메모리 할당량을 적절히 조절하는 것이 메모리 관리의 핵심이다.

Memory Management가 만족해야 할 5가지 요구사항(PPT Table 7.1 + 슬라이드):

요구사항	설명
Relocation	프로세스는 swap in/out 시 다른 메모리 위치로 이동할 수 있어야 한다. 항상 동일한 위치에 올라올 필요가 없다.
Protection	프로세스는 다른 프로세스의 메모리 영역에 허가 없이 접근하면 안 된다. 메모리 참조는 runtime에 검사된다.
Sharing	여러 프로세스가 동일한 코드(예: 한글 프로그램)를 공유할 수 있어야 한다. Protection과 양립 가능하게 구현한다.
Logical Organization	프로그램은 모듈(함수 단위)로 구성된다. Segmentation이 이를 가장 잘 표현한다.
Physical Organization	메모리 관리는 OS가 담당해야 하며, 프로그래머가 직접 처리하면 안 된다(Overlay 시대의 한계).

Overlay (역사적 맥락)

2.2 Address Translation

주소의 3단계 변환

Source Code        --[컴파일러]--->   Object Code        --[로더/실행]--->   Executable Code
Symbolic Address               Logical/Relative Address                Physical Address
(변수명 A, B 등)                (0번지부터의 상대 주소)                   (실제 메모리 위치)

Symbolic Address: 소스 코드에서 사용하는 변수명. 프로그래머는 메모리 주소를 신경 쓰지 않는다.
Logical (Relative) Address: 컴파일 후 프로그램의 시작을 0으로 기준 삼아 붙여진 상대 주소. 프로그램이 메모리 어디에 올라가든 내부적인 번호는 동일하다.
Physical (Absolute) Address: 실제 메모리(RAM) 상의 주소. 프로세스가 메모리의 어느 위치에 적재되느냐에 따라 달라진다.

Physical Address = Base Address + Logical(Relative) Address

CPU가 메모리에 접근하려면 반드시 physical address가 필요하다. 따라서 logical address → physical address 변환이 빠르게 이루어져야 한다.

Address Translation이 일어나는 시점

세 가지 시점이 가능하다.

Compile time: 컴파일 시점에 physical address를 직접 박아 넣는다. 프로세스가 항상 같은 위치에 올라가야 해서 비현실적이다.
Load time: 메모리에 올라올 때 relative address를 physical address로 일괄 변환한다. 올라온 이후에는 위치가 고정된다.
Execution time (runtime): 실행 중 매 메모리 참조 시점에 CPU 하드웨어(Base Register + Adder)를 통해 변환한다.

2.3 메모리 분할 기법 개요

메모리를 여러 프로세스에게 나눠주는 방식은 크게 세 가지다.

Segmentation: 모듈(함수) 크기에 맞게 가변 크기로 할당 → 크기가 제각각
Fixed Partitioning: 미리 고정된 크기로 나눔 → 크기가 다양하거나 동일하게 나눔
Simple Paging: 모든 파티션을 동일한 크기로 나눔

OS는 3번 방식(Paging)을 선호한다. 이유는 Address Translation이 단순하고, 관리 overhead가 작기 때문이다.

전체 메모리 관리 기법 비교 (PPT Table 7.2):

기법	설명	장점	단점
Fixed Partitioning	시스템 부팅 시 정적으로 파티션을 나눔	구현 단순, overhead 적음	Internal Fragmentation, 활성 프로세스 수 고정
Dynamic Partitioning	프로세스 크기에 맞게 동적으로 할당	Internal Fragmentation 없음	External Fragmentation → Compaction 필요
Simple Paging	동일 크기 frame으로 나누고, 프로세스도 page로 나눔	External Fragmentation 없음	소량의 Internal Fragmentation
Simple Segmentation	프로세스를 가변 크기 segment로 나눔	Internal Fragmentation 없음	External Fragmentation
Virtual Memory Paging	Simple Paging + 전체 page를 올릴 필요 없음	Multiprogramming 극대화, 큰 virtual address space	복잡한 메모리 관리 overhead
Virtual Memory Segmentation	Simple Segmentation + 전체 segment를 올릴 필요 없음	위와 동일, Protection/Sharing 지원	복잡한 메모리 관리 overhead

2.4 Fixed Partitioning

메모리를 미리 고정된 크기로 나눠놓는 방식이다. Equal-size(모두 같은 크기)와 Unequal-size(2M, 4M, 6M, 8M 등 다양한 크기)가 있다.

[Equal-size]          [Unequal-size]
OS (8M)               OS (8M)
8M                    2M
8M                    4M
8M                    6M
8M                    8M
8M                    8M
8M                    12M
8M                    16M

프로세스 할당 방식은 파티션별 큐(queue per partition)와 단일 큐(single queue) 두 가지가 있다.

2.5 Dynamic Partitioning

프로세스 크기에 딱 맞게 파티션을 동적으로 생성한다. Internal Fragmentation은 없지만, 시간이 지나면서 External Fragmentation이 발생한다.

(a) 빈 메모리 56M     (b) Process 1 로드(20M)    ...    (e) Process 2 종료 후
OS                     OS                               OS
                       Process 1 (20M)                  Process 1 (20M)
                       빈 공간 (36M)                     빈 공간 (14M)  ← 단편화
                                                         Process 3 (18M)
                                                         빈 공간 (4M)   ← 단편화

여러 작은 빈 공간이 흩어져 있어서, 합치면 충분한 공간인데 연속적으로 할당할 수 없는 상황이 External Fragmentation이다.

해결책: Compaction(조각 모음)

2.6 Placement Algorithms

Dynamic Partitioning이나 Segmentation에서, 새 프로세스를 어느 빈 공간에 할당할지 결정하는 알고리즘이다.

알고리즘	방식	특징
Best-fit	모든 빈 공간을 탐색하여 요청 크기에 가장 가까운 공간에 할당	공간 낭비 최소화, 탐색 시간 오래 걸림
First-fit	메모리 처음부터 탐색, 충분한 첫 번째 공간에 할당	탐색 시간 짧음
Next-fit	직전 할당 위치부터 탐색 시작, 충분한 다음 공간에 할당	First-fit의 변형
Worst-fit	가장 큰 빈 공간에 할당	할당 후 남은 공간이 커서 다른 프로세스에게 재활용 가능

Figure 7.5 예시(16M 블록 할당 시):

[Before]                 [After]
8M (allocated)           8M
12M (free)               12M → First-fit: 여기에 16M 할당 (6M 남음)
22M (free)               6M 잔여
18M (free)               18M → Best-fit: 여기에 16M 할당 (2M 남음)
8M (allocated)           8M
6M (free)                6M
14M (allocated) ←last    14M
36M (free)               20M 잔여 → Next-fit & Worst-fit: 여기에 할당

2.7 Buddy System

Fixed와 Dynamic Partitioning의 절충안이다. 메모리 블록을 2의 지수 크기로만 할당한다.

전체 메모리(예: 1MB)에서 시작하여 요청 크기를 수용할 수 있는 최소 2^k 크기 블록을 찾는다.
블록이 너무 크면 반으로 분할(split)하고, 해제 시 인접한 같은 크기의 "buddy" 블록이 비어있으면 합친다(merge).

1M 전체
└─ Request 100K → 128K 블록 할당 (A)
   └─ Request 240K → 256K 블록 할당 (B)
      └─ Request 64K → 64K 블록 할당 (C)
         └─ Request 256K → 256K 블록 할당 (D)

2.8 Fragmentation 정리

종류	발생 상황	해결 방법
Internal Fragmentation	할당된 공간 내에서 프로세스가 다 쓰지 못하는 낭비 (Fixed Partitioning, Paging의 마지막 page)	파티션/페이지 크기를 작게 함 (단, 너무 작으면 관리 overhead 증가)
External Fragmentation	빈 공간의 합은 충분하지만 연속되지 않아 할당 불가 (Dynamic Partitioning, Segmentation)	Compaction

2.9 Paging 상세

기본 개념

Page: 프로세스(secondary memory)를 동일한 고정 크기로 나눈 조각
Frame: 메인 메모리를 동일한 고정 크기로 나눈 조각 (page와 크기 동일)

프로세스의 각 page는 메모리의 임의의 frame에 올라갈 수 있다. 연속된 frame에 올라갈 필요가 없다.

Process A            Main Memory
Page 0  ──────────→  Frame 0   (A.0)
Page 1  ──────────→  Frame 1   (A.1)
Page 2  ──────────→  Frame 2   (A.2)
Page 3  ──────────→  Frame 3   (A.3)

Process C (다른 위치에 분산)
Page 0  ──────────→  Frame 7
Page 1  ──────────→  Frame 8
Page 2  ──────────→  Frame 9
Page 3  ──────────→  Frame 10

하드디스크에서는 데이터가 연속적으로 위치해야 seek time이 짧아지지만, 메모리에서는 전자적으로 접근하므로 연속성이 성능에 영향을 주지 않는다.

Page Table

Page Table은 OS가 각 프로세스마다 하나씩 생성하는 자료구조로, page number → frame number 매핑 정보를 갖는다. PCB(Process Control Block) 안에 포함된다.

Process C page table
Page 0 → Frame 7
Page 1 → Frame 8
Page 2 → Frame 9
Page 3 → Frame 10

Process B page table (swap out 상태)
Page 0 → (empty, in disk)
Page 1 → (empty, in disk)
Page 2 → (empty, in disk)

중요한 속성:

프로세스의 최대 크기는 page table의 entry 수로 결정된다. (예: entry가 10,000개 → 최대 10,000 pages)
시스템에서 최대 프로세스 개수는 PCB 테이블의 크기로 결정된다.
Swap in 시 반드시 이전과 같은 frame에 올라올 필요가 없다. Page table entry만 갱신하면 된다.

Logical Address → Physical Address 변환 (Figure 7.12a)

Page size = 1K (= 1024 bytes) 인 경우, logical address를 page number와 offset으로 분리한다.

Logical address: 1502 (10비트 이진수: 0000010111011110)
  → 16-bit 중 상위 6-bit = page number = 1
  → 하위 10-bit = offset = 478

(검증: 1 × 1024 + 478 = 1502 ✓)

Page table에서 page 1 → frame 6 (000110) 이라면:

Physical address = frame number (6-bit) || offset (10-bit)
                 = 000110 || 0111011110
                 = 0001100111011110

변환 과정 요약:

Logical Address [page# | offset]
       ↓
Page Table에서 page# 인덱스로 frame# 조회
       ↓
Physical Address = [frame# | offset]

2.10 TLB (Translation Lookaside Buffer)

TLB (Translation Lookaside Buffer): CPU 내에 위치한 소형 고속 연관 레지스터(associative register). 최근에 사용된 page number → frame number 매핑을 캐싱한다.
TLB hit: 해당 page number가 TLB에 있으면 바로 frame number를 얻음 → 메모리 접근 1번만 필요
TLB miss: TLB에 없으면 page table(메모리)을 조회 후 TLB에 업데이트 → 메모리 접근 2번 필요

2.11 Segmentation

프로그램을 논리적 단위(함수, 모듈)로 자른 가변 크기 조각(segment)을 메모리에 올리는 방식이다.

프로그램의 각 모듈/함수 크기가 다르기 때문에 segment 크기도 제각각이다.
Addressing: [Segment number | Offset] 형태의 2-part 주소를 사용한다.
Segment Table은 각 segment의 Base(시작 주소)와 Length(크기)를 저장한다.

Segmentation Address Translation 과정 (Figure 7.12b):

Logical Address [segment# | offset]
       ↓
Segment Table에서 segment# 인덱스로 (Base, Length) 조회
       ↓
if (offset >= Length) → 주소 오류 (trap)
else
   Physical Address = Base + offset

세그먼트 테이블:
Segment | Length  | Base
   0    | ...     | 0x00001000
   1    | ...     | 0x00100000

Paging과 Segmentation의 차이:

Paging에서는 logical address와 relative address가 동일하다. (page size가 균일하므로)
Segmentation에서는 segment 최대 크기에 맞춰 offset bit 수가 결정되기 때문에, logical address와 relative address가 다를 수 있다.
따라서 Paging의 Address Translation이 Segmentation보다 훨씬 단순하다.

Paged Segmentation

3. 교수님 강조 포인트

※ Multiprogramming level을 무조건 높이는 게 능사가 아니다. 프로세스당 할당 메모리가 너무 적으면 page fault가 잦아져 컴퓨터가 느려지고, 너무 많이 주면 프로세스 개수가 줄어 CPU 활용도가 오히려 낮아진다. 적절한 균형이 핵심이다.

※ Address Translation은 execution time에 일어난다. Relocation 때문에 프로세스가 swap in될 때마다 다른 frame에 올라올 수 있으므로, 미리 주소를 고정(compile time 또는 load time)하면 안 된다.

※ Figure 7.12 (Logical → Physical Address Translation)를 완전히 이해해야 한다. 이해 못하면 집에서 반드시 다시 볼 것. page number와 offset이 어떻게 분리되고, page table을 통해 frame number를 찾아 physical address를 조합하는 과정이 이 그림 하나에 다 담겨 있다.

※ OS는 세 가지 분할 방식 중 동일 크기(Paging)를 선호한다. 이유는 단순성이다. Segmentation 방식은 모듈 크기가 제각각이어서 주소 관리가 복잡하고 overhead가 크다.

※ External Fragmentation은 Segmentation(Dynamic Partitioning) 계열에서만 발생하고, Paging에서는 발생하지 않는다. 대신 Paging에서는 마지막 page에만 Internal Fragmentation이 생긴다.

※ Swap in/out 시 프로세스는 이전과 다른 frame에 올라와도 된다. Page table의 frame 번호만 업데이트하면 나머지는 하드웨어가 자동으로 처리한다.

※ 프로세스의 최대 크기는 page table 크기로, 시스템의 최대 프로세스 개수는 PCB table 크기로 결정된다.

4. 핵심 용어 정리

용어 (영문)	설명
Frame	메인 메모리를 고정 크기로 나눈 블록
Page	프로세스(secondary memory)를 고정 크기로 나눈 블록. Frame과 크기가 동일
Segment	프로세스를 가변 크기로 나눈 블록 (함수/모듈 단위)
Logical Address	프로그램 내에서 사용하는 주소. 메모리의 실제 위치와 독립적
Relative Address	Logical address의 일종. 프로그램 시작(0)으로부터의 상대적 거리
Physical (Absolute) Address	메인 메모리의 실제 위치를 나타내는 주소
Address Translation	Logical/Relative address를 Physical address로 변환하는 과정
Relocation	프로세스가 swap in 시 다른 메모리 위치에 올라오는 것. 주소 변환이 동적으로 이루어져야 함
Internal Fragmentation	할당된 파티션/페이지 안에서 사용되지 않는 낭비 공간
External Fragmentation	빈 공간의 합은 충분하지만 연속적이지 않아 할당 불가한 상태
Compaction	External fragmentation을 해결하기 위해 OS가 프로세스들을 한쪽으로 몰아 빈 공간을 합치는 작업 (조각 모음)
Fixed Partitioning	메모리를 미리 고정된 크기의 파티션으로 나누는 방식
Dynamic Partitioning	프로세스 요청 크기에 맞게 파티션을 동적으로 생성하는 방식
Paging	메모리와 프로세스를 동일한 고정 크기(page/frame)로 나누어 관리하는 기법
Segmentation	프로세스를 논리적 단위(모듈/함수)의 가변 크기 segment로 나누어 관리하는 기법
Paged Segmentation	Paging과 Segmentation을 혼합한 기법. Segment를 다시 page 단위로 나눔
Page Table	OS가 프로세스마다 관리하는 자료구조. Page number → Frame number 매핑 정보 저장
Segment Table	Segmentation에서 각 segment의 Base(시작 주소)와 Length(크기)를 저장하는 테이블
TLB (Translation Lookaside Buffer)	CPU 내의 고속 하드웨어 캐시. 최근 page-frame 매핑을 저장하여 address translation 속도를 높임
Best-fit	빈 공간 중 요청 크기에 가장 가까운 것을 선택하는 배치 알고리즘
First-fit	처음부터 탐색하여 충분한 첫 번째 빈 공간에 할당하는 알고리즘
Next-fit	직전 할당 위치부터 탐색을 시작하는 First-fit 변형
Worst-fit	가장 큰 빈 공간에 할당하는 알고리즘
Buddy System	2의 지수 크기 블록만 사용하는 하이브리드 메모리 할당 기법
Overlay	초기 컴퓨터에서 메모리 부족 시 프로그램을 잘라서 순차적으로 실행하던 방식
Page Fault	실행하려는 코드/데이터가 메모리에 없고 disk에만 있을 때 발생하는 오류/인터럽트

5. 복습 질문

Multiprogramming level을 높이기 위해 프로세스당 메모리 할당량을 무한정 줄이면 어떤 문제가 발생하는가? 반대로 각 프로세스에 메모리를 매우 많이 할당하면 어떤 문제가 생기는가?
Logical(Relative) Address와 Physical Address의 차이를 설명하고, Address Translation이 왜 Compile time이나 Load time이 아닌 Execution time에 이루어져야 하는지 서술하라.
Internal Fragmentation과 External Fragmentation의 차이를 설명하고, 각각 어떤 메모리 관리 기법에서 발생하며 어떻게 해결할 수 있는지 기술하라.
Paging 기법에서 Logical address가 어떻게 Physical address로 변환되는지, Page Table을 이용한 과정을 단계별로 설명하라. (Page size = 1K, logical address = 2050인 경우를 예로 들어 설명하면 더욱 좋다.)
Best-fit, First-fit, Next-fit, Worst-fit 배치 알고리즘을 비교하고, 각 알고리즘의 trade-off를 설명하라. Worst-fit이 존재하는 이유는 무엇인가?
Paging이 Segmentation보다 OS에서 선호되는 이유를 Address Translation의 복잡성 및 Fragmentation 관점에서 설명하라.
TLB(Translation Lookaside Buffer)가 필요한 이유는 무엇이며, TLB hit와 TLB miss 각각의 경우에 메모리 접근이 몇 번씩 필요한지 설명하라.

[현대암호이론] 10주차 강의노트

hyeongseop — Mon, 11 May 2026 10:52:39 +0900

현대암호이론 및 응용 — 10주차 강의노트

범위: 10장 비대칭키 암호 (Asymmetric Key Cryptography) — 공개키 개념 · RSA · ECC · PQC(양자 내성 암호)

수업 개요

대칭키 vs 비대칭키: 키 개수 문제와 공개키 암호의 등장 배경
공개키 암호의 두 가지 용도: 기밀성(암호화) + 전자서명
RSA 암호 시스템: 키 생성 · 암호화/복호화 · 수학적 증명 · 안전성
ECC (타원곡선 암호): 타원곡선의 정의와 연산
PQC (양자 내성 암호): 쇼어 알고리즘의 위협 · 격자 기반 암호

1. 대칭키 vs 비대칭키 암호 ⭐

1.1 대칭키 암호의 키 개수 문제

사용자 $n$명이 모두 비밀 통신하려면 필요한 키 수:

$$\text{필요 키 수} = \frac{n(n-1)}{2}$$

사용자 수	필요 키 수
2명	1개
3명	3개
4명	6개
5명	10개
100명	4,950개
1,000명	499,500개

→ 사용자가 늘수록 키 수가 $n^2$에 비례하여 기하급수적으로 증가

1970년대까지는 통신 규모가 작아 문제없었으나, 인터넷이 등장하면서 이 문제가 현실화됨.

1.2 공개키 암호의 등장

공개키(비대칭키) 암호에서 필요한 키 수:

$$\text{필요 키 수} = n \text{ 쌍 (사용자당 공개키 + 개인키 1쌍)}$$

100명 → 100쌍, 1,000명 → 1,000쌍
각 사용자는 자신의 공개키/개인키 쌍만 관리
상대방의 공개키 디렉터리(공개 저장소)에서 공개키를 가져와 사용

1.3 용어 정리 ⭐

용어	설명
공개키 (Public Key)	누구에게나 공개하는 키 — 암호화 또는 서명 검증에 사용
개인키 / 비밀키 (Private Key)	자기만 알고 있는 키 — 복호화 또는 서명 생성에 사용
관용 암호 (Conventional)	DES/AES 같은 대칭키 암호의 별칭

⚠️ 혼동 주의: "비밀키"는 문맥에 따라 다름 — 대칭키 암호에서는 양측 공유 키, 공개키 암호에서는 개인키를 의미

2. 공개키 암호의 두 가지 용도 ⭐

2.1 용도 1 — 데이터 기밀성 (Confidentiality)

송신자 B: A의 공개키로 암호화 → 암호문 전송
수신자 A: 자신의 개인키로 복호화

A의 개인키를 아는 사람만 복호화 가능 → 기밀성 보장

2.2 용도 2 — 전자서명 (Digital Signature)

서명자 A: 자신의 개인키로 서명(암호화)
검증자들: A의 공개키로 검증(복호화)

A의 개인키로 서명 → 누구나 A의 공개키로 검증 가능 → "A가 서명했다"는 부인 방지

공개키 암호에서 키 사용 방향:

공개키 암호화 → 개인키 복호화: 기밀성

개인키 암호화(서명) → 공개키 복호화(검증): 인증/부인방지

3. RSA 암호 시스템 ⭐

3.1 역사

개발자: Ronald Rivest, Adi Shamir, Leonard Adleman → 이름 첫 글자 = RSA
발표 연도: 1977년
기반 어려운 문제: 소인수분해 (Integer Factorization)

소인수분해 문제:

두 소수의 곱 $n = p \times q$가 주어졌을 때, $p$와 $q$를 찾는 문제
수가 작으면 쉽지만, 수백 자리 수에서는 계산적으로 불가능에 가깝게 어려움
$n$의 소인수분해 복잡도: $e^{\sqrt[3]{\ln n}}$ 정도 (지수적 복잡도)

3.2 RSA 두 개의 대수 구조

RSA는 두 개의 대수 구조를 동시에 사용:

역할	구조	연산
암호화/복호화	$R = \langle \mathbb{Z}_n, +, \times \rangle$ (Public Ring)	덧셈 + 곱셈 (mod $n$)
키 생성	$G = \langle \mathbb{Z}_{\varphi(n)}^*, \times \rangle$ (Private Group)	곱셈 역원 계산

3.3 키 생성 과정 ⭐

두 개의 큰 홀수 소수 $p$, $q$ 선택
$n = p \times q$ 계산
$\varphi(n) = (p-1)(q-1)$ 계산
공개키 $e$ 선택: 작은 홀수 & $\gcd(e,\ \varphi(n)) = 1$ 만족
개인키 $d$ 계산: $e \times d \equiv 1 \pmod{\varphi(n)}$ → 확장 유클리드 알고리즘 사용

$$\boxed{\text{공개키: } (e,\ n) \quad\quad \text{개인키: } (d,\ p,\ q)}$$

⚠️ $p$, $q$도 개인키처럼 비밀로 유지해야 함. $n$으로부터 $p$, $q$를 모르면 $\varphi(n)$을 계산할 수 없음.

3.4 암호화 / 복호화 ⭐

암호화:
$$C \equiv M^e \pmod{n}$$

복호화:
$$M \equiv C^d \pmod{n}$$

암호화와 복호화 모두 모듈러 지수 연산(Modular Exponentiation) — 계산은 쉬움. 하지만 $d$ 없이 $C$로부터 $M$을 구하는 것은 소인수분해만큼 어려움.

3.5 예제 1 — 소규모 RSA ($p=7$, $q=11$) ⭐

단계	계산	결과
① $n$	$7 \times 11$	$n = 77$
② $\varphi(n)$	$(7-1)(11-1)$	$\varphi(77) = 60$
③ 공개키 $e$ 선택	홀수 & $\gcd(e, 60) = 1$	$e = 37$
④ 개인키 $d$ 계산	$37 \times d \equiv 1 \pmod{60}$	$d = 13$
검증	$37 \times 13 = 481 = 8 \times 60 + 1$	✓

암호화 (평문 M=17):
$$C \equiv 17^{37} \pmod{77} = 52$$

복호화:
$$M \equiv 52^{13} \pmod{77} = 17 \quad \checkmark$$

3.6 예제 2 ($p=101$, $q=113$)

항목	값
$n$	$101 \times 113 = 11413$
$\varphi(n)$	$100 \times 112 = 11200$
공개키 $e$	$3533$ (홀수, $\gcd(3533, 11200) = 1$)
개인키 $d$	$6597$ (확장 유클리드로 계산)
평문 M	$9726$
암호문 C	$9726^{3533} \bmod 11413 = 5761$
복호화	$5761^{6597} \bmod 11413 = 9726$ ✓

3.7 RSA 키 길이

$$\text{RSA 1024비트}: 2^{1024} \approx (2^{10})^{100} \approx (10^3)^{100} = 10^{300}$$

→ 10진수로 약 300자리 수 — 소인수분해가 현실적으로 불가능

3.8 RSA 정확성 증명 (Correctness Proof) ⭐

왜 $M^{ed} \equiv M \pmod{n}$이 성립하는가?

오일러 정리 이용:

$e \times d \equiv 1 \pmod{\varphi(n)}$ 이므로:
$$ed = 1 + k\varphi(n) \quad \text{(어떤 정수 } k \text{에 대해)}$$

오일러 정리: $M^{\varphi(n)} \equiv 1 \pmod{n}$ ($\gcd(M,n)=1$일 때)

따라서:
$$M^{ed} = M^{1+k\varphi(n)} = M \cdot (M^{\varphi(n)})^k \equiv M \cdot 1^k = M \pmod{n}$$

$M$과 $n$이 서로 소가 아닌 경우에도 CRT(중국인 나머지 정리)를 이용하면 증명 가능.

페르마 소정리 이용 (또 다른 증명):

$\text{mod } p$ 관점: $M^{p-1} \equiv 1 \pmod{p}$ → $M^{ed} \equiv M \pmod{p}$
$\text{mod } q$ 관점: $M^{q-1} \equiv 1 \pmod{q}$ → $M^{ed} \equiv M \pmod{q}$
CRT에 의해: $M^{ed} \equiv M \pmod{pq=n}$

3.9 RSA 안전성

다음 4가지가 동등하게 어려운 문제:

RSA 암호문으로부터 평문 복원
공개키 $(e, n)$으로부터 개인키 $d$ 계산
$n$에 대한 $\varphi(n)$ 계산
$n$의 소인수분해 ($n = pq$에서 $p$, $q$ 찾기) ← 핵심

→ RSA 안전성 = 큰 수의 소인수분해가 어렵다는 사실에 기반

4. ECC (Elliptic Curve Cryptography, 타원곡선 암호) ⭐

4.1 등장 배경

1980년대 말 독립적으로 두 연구자가 동시 발표: Koblitz(워싱턴대)와 Miller(IBM)
이산대수 문제의 타원곡선 버전(ECDLP)을 어려운 문제로 활용
RSA 대비 훨씬 짧은 키로 동일한 보안 수준 달성

4.2 타원곡선의 정의

유한체 $\mathbb{F}_p$ (= $\mathbb{Z}_p$) 상에서의 타원곡선:

$$E: y^2 \equiv x^3 + Ax + B \pmod{p}$$

조건: $4A^3 + 27B^2 \not\equiv 0 \pmod{p}$ (특이점 없음 조건)

$A$, $B$는 $\mathbb{Z}_p$의 원소
타원곡선 $E$의 점 = 위 방정식을 만족하는 $(x, y) \in \mathbb{Z}_p \times \mathbb{Z}_p$ + 무한원점 $\mathcal{O}$

예시 ($p=11$, $A=1$, $B=6$):

곡선: $y^2 \equiv x^3 + x + 6 \pmod{11}$
검증: $4(1)^3 + 27(6)^2 \equiv 4 + 972 \equiv 8 \pmod{11} \neq 0$ ✓
점 예시: $(2,4), (2,7), (3,5), (3,6), \ldots$

4.3 타원곡선 덧셈 연산 ⭐

타원곡선에서의 점 덧셈(Point Addition) 정의:

규칙 1: $P + \mathcal{O} = P$ (무한원점 = 항등원)

규칙 2: $(x, y) + (x, -y) = \mathcal{O}$ (덧셈 역원: $y \to -y$)

규칙 3: $P = (x_1, y_1)$, $Q = (x_2, y_2)$일 때 $P + Q = (x_3, y_3)$:

$$\lambda = \begin{cases} \dfrac{y_2 - y_1}{x_2 - x_1} \pmod{p} & \text{($P \neq Q$)} \[6pt] \dfrac{3x_1^2 + A}{2y_1} \pmod{p} & \text{($P = Q$, 즉 2P)} \end{cases}$$

$$x_3 = \lambda^2 - x_1 - x_2 \pmod{p}$$
$$y_3 = \lambda(x_1 - x_3) - y_1 \pmod{p}$$

예시 ($P=(2,4)$, $Q=(3,5)$, $p=11$):

$\lambda = \frac{5-4}{3-2} = 1 \pmod{11}$
$x_3 = 1^2 - 2 - 3 = -4 \equiv 7 \pmod{11}$
$y_3 = 1(2-7) - 4 = -9 \equiv 2 \pmod{11}$
→ $P + Q = (7, 2)$

4.4 ECC 키 구조

베이스 포인트(Base Point) $G$: 공개된 기준점
개인키 $d$: 임의의 정수
공개키 $Q$: $Q = d \cdot G$ (G를 d번 더하기 연산)

ECDLP (타원곡선 이산로그 문제): $Q$와 $G$를 알아도 $d$를 구하는 것은 극히 어려움 → ECC의 보안 기반

5. PQC — 양자 내성 암호 (Post-Quantum Cryptography) ⭐

5.1 양자 컴퓨터의 위협

현재 공개키 암호 시스템이 기반하는 어려운 문제들:

암호	기반 문제
RSA	소인수분해
ElGamal	이산로그 (유한체)
ECC	이산로그 (타원곡선)

→ 이 세 가지 모두 쇼어 알고리즘으로 양자 컴퓨터에서 쉽게 풀림

5.2 쇼어 알고리즘 (Shor's Algorithm, 1994) ⭐

피터 쇼어(Peter Shor)가 1994년 제안한 양자 알고리즘:

핵심 아이디어: 소인수분해 → 주기 찾기 문제로 변환

[쇼어 알고리즘 단계]
1. n보다 작은 난수 a 선택
2. gcd(a, n) 계산
   → gcd ≠ 1이면: gcd(a,n)이 바로 n의 소인수 → 완료
   → gcd = 1이면: 다음 단계
3. a^x mod n의 주기 r 계산 (양자 컴퓨터로 수행)
4. r이 홀수이면 → 1단계로 돌아가기
5. r이 짝수이면:
   → a^(r/2) mod n이 -1인지 확인, -1이면 → 1단계로
   → 그렇지 않으면: gcd(a^(r/2)+1, n)과 gcd(a^(r/2)-1, n) 계산 → n의 소인수!

예시 ($n=15$, $a=7$):

$\gcd(7, 15) = 1$ (서로소)
주기 $r = 4$ (양자 컴퓨터로 계산)
$7^{4/2} = 7^2 = 49 \equiv 4 \pmod{15}$ ($4 \neq -1$이므로 진행)
$\gcd(7^2+1, 15) = \gcd(50, 15) = 5$
$\gcd(7^2-1, 15) = \gcd(48, 15) = 3$
→ $15 = 5 \times 3$ ✓

3단계 "주기 찾기"를 전통 컴퓨터로 하면 지수 시간이 걸리지만, 양자 컴퓨터로 다항 시간에 가능.
현재 양자 컴퓨터로는 수백 비트짜리 RSA만 공격 가능. 1024비트 이상은 아직 안전.

5.3 PQC 정의

PQC (Post-Quantum Cryptography, 양자 내성 암호):

양자 컴퓨터의 공격에도 안전한 암호 시스템
= 양자 내성(Quantum Resistant) = Quantum-Safe = Quantum-Proof

NIST는 PQC 표준화 프로젝트를 진행 중.

5.4 PQC 주요 후보 기법

기반	설명	특징
격자 기반 (Lattice-based)	CVP/SVP 어려움 활용	가장 유망
다변수 다항식 기반	연립 다항식 풀기 어려움
해시 기반	해시 함수의 일방향성	서명 특화
코드 기반	오류 정정 코드의 어려움

5.5 격자 기반 암호 (Lattice-based Cryptography) ⭐

핵심 개념

격자(Lattice): 기저 벡터들의 정수 선형 결합으로 이루어진 점들의 집합

좋은 기저 vs 나쁜 기저:

	좋은 기저 (Good Basis)	나쁜 기저 (Bad Basis)
특징	짧고 거의 수직인 벡터	길고 기울어진 벡터
계산	격자 내 점 찾기 쉬움	격자 내 점 찾기 어려움
역할	개인키	공개키

비유: 좋은 기저 = 잘 정리된 내비게이션(정확한 목적지 찾기 쉬움), 나쁜 기저 = 불완전한 지도(마을 구조는 알지만 정확한 집 위치 찾기 어려움)

CVP/SVP 문제

문제	영어	내용
SVP	Shortest Vector Problem	격자에서 가장 짧은 벡터 찾기
CVP	Closest Vector Problem	임의의 점에서 가장 가까운 격자점 찾기

→ 나쁜 기저(공개키)로는 CVP 풀기 어려움, 좋은 기저(개인키)로는 쉬움 → 암호의 비대칭성 근거

GGH 암호 (Goldreich-Goldwasser-Halevi)

설정 단계: 좋은 기저(개인키)와 나쁜 기저(공개키)가 동일한 격자를 생성하도록 구성
서명: 좋은 기저를 사용 → 메시지(임의 점)에 가장 가까운 격자점을 효율적으로 계산 → 그것이 서명
검증: 나쁜 기저(공개키)를 사용 → 서명이 격자 위의 점인지 확인
고차원(n차원)으로 확장할수록 계산이 극도로 어려워짐

이번 주차 핵심 요약

개념	한 줄 정리
대칭키 키 개수	$n(n-1)/2$ — 사용자 증가 시 기하급수적 증가
공개키 키 개수	$n$쌍 — 사용자 수에 선형 비례
공개키 용도 1	공개키 암호화 → 개인키 복호화 = 기밀성
공개키 용도 2	개인키 서명 → 공개키 검증 = 전자서명
RSA 기반 문제	큰 수의 소인수분해
RSA 공개키	$(e, n)$ — 작은 홀수 $e$, $\gcd(e, \varphi(n))=1$
RSA 개인키	$(d, p, q)$ — $ed \equiv 1 \pmod{\varphi(n)}$
RSA 암호화	$C = M^e \bmod n$
RSA 복호화	$M = C^d \bmod n$
RSA 정확성	오일러 정리: $M^{ed} \equiv M \pmod{n}$
RSA 키 길이	실용: $n \geq$ 512비트, 1024비트 이상 권장
ECC 기반 문제	타원곡선 이산로그 (ECDLP)
ECC 장점	RSA보다 짧은 키로 동일한 보안 수준
쇼어 알고리즘	양자 컴퓨터로 소인수분해·이산로그 해결 → RSA/ECC 위협
PQC	양자 컴퓨터 공격에도 안전한 암호 (양자 내성 암호)
격자 기반 암호	좋은 기저(개인키)/나쁜 기저(공개키), CVP/SVP 어려움 활용

⭐ 시험 대비 강조 포인트

대칭키 vs 공개키 키 개수 공식 — $\frac{n(n-1)}{2}$ vs $n$쌍, 구체적 수치 계산 가능할 것
공개키 암호의 두 가지 용도 — 기밀성(공개키 암호화)과 전자서명(개인키 암호화) 방향 구분
RSA 키 생성 4단계 — $p,q$ 선택 → $n, \varphi(n)$ 계산 → $e$ 선택($\gcd=1$) → $d$ 계산(확장 유클리드)
RSA 암호화/복호화 수식 — $C=M^e \bmod n$, $M=C^d \bmod n$
RSA 예제 직접 계산 — $p=7, q=11$ 예제 손으로 계산해볼 것 (기말고사 출제 예고!)
RSA 정확성 증명 흐름 — $ed = 1 + k\varphi(n)$ → 오일러 정리 적용 → $M^{ed} \equiv M$
RSA 안전성 — 4가지 동등한 문제 (소인수분해 = $\varphi(n)$ 계산 = $d$ 계산 = 복호화)
ECC 덧셈 공식 — $\lambda$ 계산법과 $x_3, y_3$ 공식
쇼어 알고리즘 — 소인수분해를 주기 찾기로 환원, 양자 컴퓨터 사용
격자 기반 암호 — 좋은 기저=개인키, 나쁜 기저=공개키, CVP가 어려운 문제

과제 및 수업 일정

과제: 10장 연습문제 중 지정 문제 1개 선택하여 계시판에 업로드
다음 주 (5월 5일): 어린이날 — 수업 없음
이후 수업 일정: 5/12, 5/19, 5/26, 6/1, 6/9 (암호 관련 진도)
5/12, 5/19 수업: 영상으로만 진행 (예비군 훈련 등 일정 고려)