부트캠프 수료 후 취준

7/31일 크래프톤정글을 수료하고 8월, 9월은 면접일정 때문에 정신없었다. 진행했던 면접들마다 아쉬운 결과를 받으며 약간 고삐를 놓은 느낌이였다. 이후 2026년도에는 다시 개발공부들을 복기하며 사이드프로젝트와 취준까지 병행하며 지내왔다. 취준이 길어지니 공백기간을 가지는게 걱정이 되어 직무를 확장해서 서버, 모니터링, C++까지 면접을 보았고, 합격소식을 들을 수 있었다. 다만 공백기를 없애고자 별로 관심없는 직무에 시간을 쏟는게 맞는지 의문이 생겼다.

개발에 처음 입문하게 된 계기

대학교때 코딩으로 무에서 유를 만들어내는게 흥미로워 개발에 관심을 가지게 되었고 우연히 참여한 교내 창업캠프에서 학우 두명과 돈 좀 벌어보자! 100억으로 엑싯하자는 목표를 가지고 함께 창업동아리를 만들며 창업활동도 하게되었다. 창업학 교수님 산하로 들어가 국가지원사업까지 경험했지만 점점 개발과는 멀어지는 것 같아 졸업반때 창업을 그만두었다. 이후 졸업을 하며 창업활동으로 전공수업을 듣지 못한 것이 아쉬워 졸업 후 바로 크래프톤정글이란 부트캠프에 참여했다. low레벨의 cs개념부터 알고리즘, 개발지(준비생)들과 협업활동까지 정말 나에겐 값진 시간이였고 개발자커리어로 본다면 대학교4년보다 더 의미있었다.

나는 무엇을 하고 싶을까?

창업을 그만두긴 했지만 싫어한 것은 아니였다. 1년반이란 기간동안 창업활동을 하며 비즈니스 구조를 이해하고 아이디어를 수립해 사업계획서를 작성해보며 학생인 내가 스스로 수익구조를 만들어 보는 경험에 빠져들었었다. 나는 내가 개발한 서비스로 많은 돈을 벌어보고싶다. 그리고 많은 사람들이 이용하는 서비스를 운영해보고 싶다. 그렇다면 내가 가야할 길은 1인창업이다..ㅋㅋㅋㅋㅋ 요즘 ai가 잘 되어있어서 정말 가능할 일인것도 같다. 그래도 현재 취업시장에서 어떤 문을 두드릴지 결정해야한다. ai기술로 서비스를 만들거나 사용자트래픽이 많은 서비스에서 개발일을 할 수 있는 직무를 찾아보았고 지원했다. 인턴, 청년일경험, 신입사원등 다양하게 지원을 했고 청년일겸험으로 베스핀글로벌의 GenAI직무에 합류하게 되었다.

개발자 직군 첫 인턴

청년일경험은 정부에서 진행하는 인턴형이면서 근무시간이 3시간이나 적은 5시간이다.(8시간->5시간) 그래도 개발자직무로 인턴을 할 수 있는게 흥미로우면서 기대된다. 앞으로는 내가 하기에 달린 것 같다. 현재 개발시장은 너무 빠르게 앞서나가고 있다. ai가 나보다 코드를 잘 짜는 것 같다. 결국은 이 개발시장의 흐름을 잘 파악하고 ai를 업무나 개발에 잘 다루는 사람이 가치있는 개발자가 될 것 이라고 생각한다. 나의 목표인 사람들에게 가치있는 서비스를 제공하는 개발자가 되어보자. 내일 첫 출근 화이팅.

왜 암호화가 필요한가?

인터넷으로 데이터를 주고받을 때 세 가지 위협이 존재한다.

• 도청(Sniffing) — 전송 중인 데이터를 몰래 엿봄
• 위·변조(Tampering) — 내용을 바꿔치기함
• 도용(Identity Theft) — 다른 사람인 척 속임

정보보안 3요소 (CIA Triad)

+ 인증(Authentication): 권한 있는 사람만 접근 가능하게 함

세 가지 핵심 개념

암호화 방식

양방향 암호화

암호화 + 복호화 모두 가능 → 기밀성 목적

대칭키 방식

• 암호화·복호화에 동일한 키 사용
• 빠르지만, 키를 상대에게 안전하게 전달하는 문제가 있음
• 대표 알고리즘: AES, Twofish, Blowfish, DES, 3DES

비대칭키 방식

• 공개키(Public Key) 와 비공개키(Private Key) 쌍 사용
• 공개키로 암호화 → 비공개키로만 복호화 (반대도 성립)
• 키를 공개해도 안전하게 통신 가능
• 대표 알고리즘: RSA

[전자서명 흐름]

전자서명: 발신자가 비공개키로 내용에 서명 → 수신자는 공개키로 서명을 복호화해 내용과 대조 → 일치하면 진본·발신자 확인

단방향 암호화 (해시)

복호화 불가 → 무결성 목적

• 입력값이 조금만 달라져도 완전히 다른 해시값 출력
• 비밀번호 저장, 파일 무결성 검증에 사용
• 대표 알고리즘: SHA-256, SHA-512, MD5, SHA-1

실생활 적용

핵심 요약

암호화 방식
├── 양방향 (복호화 가능) — 기밀성
│   ├── 대칭키: 같은 키 사용 → AES, DES
│   └── 비대칭키: 공개키/비공개키 쌍 → RSA, 전자서명
└── 단방향 (복호화 불가) — 무결성
    └── 해시: SHA-256, MD5

참고 영상: 생활코딩 암호학

HTTP vs HTTPS

암호화 계층의 역사

SSL (Secure Sockets Layer)

Netscape가 1990년대에 개발한 최초의 암호화 통신 프로토콜.

TLS (Transport Layer Security)

SSL의 후속 표준. IETF가 관리. 현재 유일하게 사용되는 프로토콜.

타임라인 요약

2021년 RFC 8996으로 TLS 1.0 / 1.1이 공식 폐기됨

핵심 정리

• SSL은 사라진 옛 프로토콜 — SSL 2.0/3.0 모두 사용 금지
• TLS만 현재 유효 — 그중에서도 TLS 1.2 / TLS 1.3만 써야 함
• “SSL 인증서”는 관행적 명칭 — 실제로는 TLS 인증서가 맞는 말

TLS 1.3의 주요 개선점

• 핸드셰이크가 1-RTT로 단순화 → 연결 속도 향상
• Forward Secrecy(FS)가 기본 적용
• 취약한 암호 방식 제거: RSA 키교환, CBC 모드, RC4
• 0-RTT 재개 지원 (단, 재생 공격 주의)

14주차

13주차를 마치고 14주차에는 개인 미니 프로젝트 과제가 주어졌다. CRUD기반의 게시판 서비스를 만들라는 과제였다.

나만무

8주차를 마치면서 이제 PintOS주간에 들어오게 되었다. 여태까지 해왔던 과정들이 PintOS를 위한 것이었고 이번 과정을 통해 많이 얻고자 노력할 것이다.

9주차

이번에는 1주씩 팀이 바뀌는 기존과는 다르게 총 3주동안 할 팀원이 배정되었다.

Anonymous page(익명 페이지)

“태어나서 처음으로 0만 담긴 백지장을 받고, 나중에 필요해지면 스왑장치에 임시로 메모를 남기는 종이”

1. 정의

   • 백업 파일이 없는 사용자 가상 페이지 (어떤 파일에 연결되지 않고, 콘텐츠를 오직 프로세스가 직접 만든다)

2. 주로 쓰이는 곳

   • 힙(Heap) - malloc(), brk()/sbrk()로 확장된 영역

   • 스택(Stack) - 함수 호출 · 지역 변수 · 스택 자동 확장

   • BSS - 초기값이 0인 전역/정적 변수

3. 초기 로딩

   1. 페이지 폴트 발생

   2. 커널이 새 프레임을 할당(palloc 등)

   3. Zero-fill → 프레임 전체를 0으로 채움

   4. PTE(Present = 1…) 갱신

4. 추방(Eviction) & 복원

   • 프레임 부족 시 swap device에 4KB 블록 단위로 기록

   • page->anon.swap_slot에 위치 기록

   • 다시 접근하면 swap 슬롯에서 읽어 프레임 재생성(swap_in)

특징 & 장단점

Anonymous page는 “이 페이지를 원래 복원시켜 줄 파일이 없다”는 뜻이고, 그래서 스왑 장치가 실질적 백업이다.

File-backed page

“이미 원본 파일이 존재하는 종이의 사본. 필요하면 원본을 다시 떼어오면 되고, 수정하면 원본에 덮어쓰거나 폐기”

1. 정의

   • 파일 시스템 블록을 근간(backup store)으로 삼는 가상 페이지 (실행 파일 · 공유 라이브러리 · mmap()한 일반 파일 등)

2. 주로 쓰이는 곳

   • 코드(Text) / 데이터(Data) 세그먼트 - ELF 로더가 LAZY-LOAD

   • 공유 라이브러리 - 여러 프로세스가 같은 read-only 프레임 공유

   • Memory-Mapped File - mmap()으로 매핑해 직접 버퍼처럼 사용

3. 초기 로딩

   1. 페이지 폴트 발생

   2. 새 프레임 할당

   3. file_read_at()으로 해당 오프셋 데이터 읽어 채움

      • 남는 바이트는 0-fill

   4. PTE 갱신

4. 추방(Eviction) & 복원

특징 & 장단점

File-backed page는 “이미 파일이 백업 스토어로 존재한다”는 뜻이고, OS는 이를 활용해 I/O 횟수를 줄이고, 여러 프로세스가 같은 데이터(코드 등)를 안전하게 공유할 수 있다.

왜 ‘익명’과 ‘파일’로 나눌까?

1. 백업 스토어 차이

   • 익명 : 원본이 없으므로 스왑이 유일한 백업

   • 파일 : 이미 디스크에 존재 → 불필요 I/O 줄이기

2. 보호 및 공유 모델

   • 파일 기반 read-only 코드는 모든 프로세스가 하나의 물리 프레임 공유 → 메모리 절약

   • 익명은 변경이 빈번 · 사적이라 안전하게 분리

3. 성능 최적화

   • Clean file page drop → 페이지 캐시 hit/evict가 빠름

   • 익명은 zero-fill이 간단하고 빠름

즉, “누가 너의 원본을 책임지냐?”에 따라 정책이 갈라진다 “원본 없음 → 익명 + 스왑” “원본 파일 → 파일 + 캐시/write-back”

한 눈에 보는 차이점

먼저 여기서 처음 들어보는 개념이 있다면, Paging글에서 개념을 참고해 본다.

Lazy Loading 이란?

“필요해질 때까지 실제 데이터를 읽어들이지 않고, 최소한의 메타데이터만 준비해 두었다가 첫 접근 시점에 비로소 불러오는 기법” (메모리·스토리지·웹 모두 같은 핵심 아이디어를 공유합니다.)

가상메모리에서의 Lazy Loading = Demand Paging

PintOS Project3에서 구현하는 uninit_new()/vm_try_handle_fault()흐름이 정확히 이 구조다. 실행 파일을 로드할 때에는 lazy_load_segment()를 등록해 두고, 페이지 폴트가 오면 file_read_at()으로 필요한 바이트만 채운 뒤 PTE를 present로 갱신한다.

추가 활용

장점과 단점

장점

• 메모리 footpring ↓, 시작 latency ↓

• I/O를 실제 필요 시점으로 분산해 burst I/O 완화

• COW와 결합하면 fork 성능 개선

단점

• 첫 접근 시 페이지 폴트 오버헤드(context switch + I/O)

• 커널 코드가 더 복잡해지고 동기화 비용 증가

• 예측 불가한 지연이 실시간 워크로드에 영향을 줄 수 있음

정리

Lazy Loading = 데이터 · 코드를 “나중에, 진짜 필요할 때” 불러오자는 철저한 지연 전략이다. 운영체제에서는 demand paging 형태로 구현되어 프로세스 시작 시간을 줄이고 메모리 자원을 절약한다. PintOS Project3의 핵심 과제이므로, 보조 정보 구조체 설계, PTE 플래그 관리, 동기화에 특히 신경 쓰자

무한대처럼 보이는 가상 메모리도 물리적 한계에 부딪히면 희생양(victim)을 골라야 한다. 그 희생양을 고르는 규칙, Page Replacement Policy를 살펴본다.

1. 왜 Page Replacement Policy가 필요한가?

가상 메모리는 프로세스마다 “거의 무한대”처럼 보이는 주소 공간을 제공하지만, 실제 물리 프레임 수는 제한적이다. 그래서 다음 상황이 생긴다.

1. page fault가 발생해 새 페이지를 적재해야 한다
2. 그런데 여유 프레임이 없으면, 커널은 한 프레임을 비워야 한다
3. 어떤 페이지를 희생(victim) 으로 내보낼지 정하는 규칙이 Page Replacement Policy다

목표는 디스크 I/O 횟수(=페이지 폴트율)를 최소화해 전체 성능을 높이는 것이다.

2. 정책 설계 시 고려 요소

3. 대표 알고리즘

LRU 근사 방법

정확한 LRU는 비용이 커서, 실제로는 다음 근사를 쓴다.

• N-비트 Aging: 주기마다 R 비트를 상위로 시프트
• 카운터 기반: 하드웨어가 마지막 접근 시각을 기록 (32/64비트)
• Enhanced Clock / Clock-Pro: 인접 시계 방식

4. Belady’s Anomaly

Stack Property가 없는 FIFO 계열에서 나타나는 현상이다. 프레임을 늘렸는데 오히려 페이지 폴트가 더 많아질 수 있다 (예: 3프레임보다 4프레임이 더 많은 폴트). 정책 선택 시 주의해야 한다.

5. 실제 OS 사례

6. 성능 분석 방법

1. Trace 재생: 메모리 참조 시퀀스를 돌려 폴트 카운트 비교
2. 실험 변수: 프레임 수, Δ(working-set 윈도), R/Dirty 비트 리셋 주기
3. Thrashing 탐지: 폴트율 급증 + CPU 사용률↓ → 정책·resident set 튜닝 필요

7. 요약

• Page Replacement Policy는 희생 페이지를 고르는 규칙이다
• 이상적인 OPT는 불가능하므로, LRU 근사나 Clock 계열이 실용적이다
• 정책마다 복잡도·메모리 오버헤드·성능·공정성의 trade-off가 있다
• 실제 커널은 다단계 큐 + 참조/더티 비트로 LRU를 근사하고, 백그라운드 데몬(kswapd 등)으로 지속 튜닝한다
• PintOS 같은 교육용 OS에서는 Clock(Second-Chance) 구현이 가장 흔하며, R/Dirty 비트 처리·프레임 테이블 관리·swap I/O 동기화가 핵심이다

페이징(Paging) 기본 개념

페이징은 “가상 주소 ↔ 물리 주소” 사이에 간접층을 삽입해 각 프로세스가 독립적인 주소 공간을 갖도록 만드는 기술이다. 이를 통해 ① 보호(Protection), ② 공유(Sharing), ③ 공간 활용(세그먼트 단편화 제거)이라는 세 가지 핵심 목표를 달성한다.

주소 변환(Translation) 과정

1. 가상 주소(48 bit) : 상위 9 bit씩 네 번 잘라 PML4→PDPT→PD→PT→오프센 순으로 인덱싱(x86-64 4-level 페이징 구조)

2. MMU가 CR3 레지스터에 있는 PML4 물리 주소를 읽어 다단계 테이블을 탐색

3. 최종 PTE(Page Table Entry, PT에 존재)에서 PFN(프레임 번호)와 R/W(read only/writable), U/S(user/supervisor), P(present/not-present) 비트를 읽어

   • 접근 허용이면 물리 주소 = PFN x 4kb + 오프셋

   • 접근 위반 x P비트 = 0이면 Page Fault발생 → OS 개입

TLB가 히트하면 1 ~ 3 단계가 생략되어 수십 ns 이내로 끝납니다.

CR3 레지스터 (아직 이해 못함)

• x86-64 Control Register 3

  • 상위 52비트 : 현재 주소 공간의 PML4 물리 주소

  • 하위 12비트 : PCID(프로세스-TLB 태그) 및 플래그로써 컨텍스트 스위칭 때 CR3를 바꾸면 MMU가 “새 주소 공간으로 바뀌었다”고 간주하며, 대부분의 TLB 엔트리가 자동으로 무효화됨

CR3의 역할 (아직 이해 못함)

1. 주소 공간 식별자

   • 커널이 컨텍스트 스위칭 시 mov %cr3, %rax / mov %rax, %cr3로 새 값 로드

   • PCID ≠ 이전 값이면, TLB 엔트리가 ‘다른 주소 공간’으로 구분되어 대부분 유지 → TLB flush 비용 감소

2. 전역(Global) 페이지

   • PTE에 G 비트를 1로 두면 CR3 변경에도 flush되지 않음 (커널 코드/데이터용)

3. Selective flush

   • 특정 페이지만 무효화할 때 invlpg (addr)사용 → 해당 VPN + PCID 매칭 엔트리만 제거

   • SMP 환경에서 다른 코어도 동일 주소 공간이면, 스스로도 같은 명령을 실행해야 함(IPI 브로드캐스트)

PintOS처럼 PCID를 쓰지 않는 단순 구현도, CR3 재로드로 “전체 TLB flush” 효과를 얻음

PTE의 R-W / U-S / P 비트

CPL(Current Privilege Level)

• CPL은 현재 실행 중인 명령어의 권한 레벨이다.

• CPU 레지스터에 따로 존재하지 않고 CS 세그먼트 하위 2비트가 CPL로 해석됨

• 페이징 권한 검사 :

  • 페이지 엔트리 U/S 비트가 0이면 “Ring 0-2만, 즉 CPL 0~2만 접근 가능”

  • R/W 비트가 0이면, “읽기만 가능, 쓰기는 CPL에 관계없이 금지”

• 시스템 콜(예 : syscall, int 0x80)은 게이트를 통해 Ring 3→Ring 0으로 ‘권한 상승’한 뒤, 커널이 iretq로 돌아올 때 Ring 3로 복귀한다.

TLB 히트란?

CPU가 가상주소를 던졌을 때 TLB(주소 변환 캐시) 안에 그 VA→PA 매핑이 이미 들어 있으면 히트(hit)라고 부릅니다. 이 경우 MMU가 페이지 테이블을 전혀 걷지 않아도 되므로 변환이 한두 사이클 안에 끝납니다. 반대로 없으면 미스(miss) → 긴 ‘4-단계 페이지 테이블 워크’가 수행됩니다.

TLB 히트 깊게

• 히트(Hit) → “요청한 가상주소의 상위 n비트(=VPN)가 TLB태그에 이미 존재하여, 물리 프레임 번호(PFN)를 즉시 반환할 수 있었다”는 뜻

• 미스(miss) → MMU가 다단계 페이지 테이블 워크를 수행하면서 메모리를 실제로 읽어야 하므로 수십~수백 ns 추가 지연이 발생

• 멀티코어에서의 일관성 : 같은 물리 페이지를 서로 다른 CPU가 매핑 바꿀 수 있으므로, PTE가 변하면 IPI(Inter-Processor Interrupt)로 다른 코어에 “TLB flush 요청”을 보내 반드시 무효화하게 한다.

체감적으로 L1 TLB 히트는 ≒ 1-3 cycle, STLB 히트는 ≒ 5-10 cycle, 미스는 수십 cycle이기 때문에 “TLB 친화적인(=순차·지역성 높은) 메모리 접근”이 성능에 큰 영향을 줍니다.

운영체제의 역할

TLB Flush

“페이지 테이블을 고쳤으니 캐시에 남은 옛 변환을 버려라”는 명령입니다.

대표 방법 :

• mov %cr3, %rax / mov %rax, %cr3 - CR3를 재로드 해 전체(비-Global) TLB 무효화

• invlpg (addr) - 지정 페이지 하나만 정밀 무효화

둘 다 커널 모드에서만 가능하며, SMP 환경에선 다른 CPU에도 IPI로 flush를 전파해야 함

페이지 교체(Page Replacement)

기존에 올렸던 PintOS Project3에서는 Clock 변형으로 구현하였다.

PintOS 관점 요약

다단계 페이징을 쓰는 이유

1. 공간 절약 - 4KB(2¹²) 페이지 x 2²⁰ → 4GB 주소 공간. 다단계(4-level)면 “사용된 테이블만” 할당

2. 보호 - 각 레벨 테이블을 4KB 페이지로 두고 U/S 비트 = 0으로 하면 커널이 관리

3. 공유 - 부모-자식 fork시 상위 N개 테이블을 copy-on-write 방식으로 공유 가능(메모리 절약)

페이지 크기와 내부 단편화

• 페이지 크기가 크면 → TLB miss 감소(+), 내부 단편화(-), I/O 효율(+)

• 현대 x86-64는 4KB 기본 + 2MB/1GB Huge Page 옵션 제공

정리

페이징은 프로세스마다 독립적/선형적인 주소 공간을 제공하면서, OS가 필요한 때만 물리 메모리/디스크를 할당하고 TLB/다단계 페이지 테이블로 성능과 메모리 사용량을 균형있게 최적화하는 메커니즘입니다. PintOS 프로젝트에서 구현·조정하는 모든 VM 기능들은 이 큰 틀 안에 위치합니다.

스왑 디스크(Swap Disk)의 기본 개념

동작 흐름

1. Page Fault

   • CPU가 PTE의 present 비트를 확인 → 0이면 트랩 → 커널의 page-fault 핸들러 진입

2. 물리 프레임 할당 실패

   • 모든 프레임이 사용 중이면 페이지 교체(page replacement) 정책(LRU/Clock 등)으로 희생 페이지 선정

3. swap-out

   1. 스왑 비트맵(bitmap)에서 빈 슬롯 검색

   2. 페이지 내용을 8 섹터(512B x 8 = 4KB)단위로 block_write()

   3. PTE present = 0, swapped flag · 슬롯 번호 기록

4. swap-in(해당 가상주소 재접근 시)

   1. 새 프레임 확보 후 block_read()로 8섹터 읽음

   2. PTE present = 1, 스왑 메타데이터 초기화, TLB flush

   3. 비트맵 슬롯 free

5. I/O 세부

   • 실제 전송은 디스크 컨트롤러가 DMA로 처리 → 완료 시 인터럽트 발생 → 커널이 잠들어 있던 프로세스 깨움