[OSTEP] 스터디 19주차 Part.1 : 분산 시스템

분산 시스템은 전 세계의 구조를 바꿨다. 웹 브라우저가 지구상 어딘가에 있는 웹 서버에 접속하면 클라이언트/서버 분산 시스템이라는 구조에 한 구성원이 된다. Google이나 Facebook의 웹 서비스를 사용한다는 것은 하나의 기계를 사용하는 것이 아니다. 수천대로 이루어진 기계들이 사이트의 특정 서비스를 제공하기 위해서 서로 협력하고 있다.1. 분산 시스템의 등장 배경 (Introduction)분산 시스템은 여러 대의 독립된 컴퓨터가 네트워크로 연결되어, 사용자에게는 마치 하나의 시스템처럼 보이게 하는 소프트웨어 모음이다. 핵심 과제는 '어떻게 하면 신뢰할 수 없는 부품(메시지 손실, 기기 장애 등)을 가지고 신뢰할 수 있는 시스템을 구축할 것인가?'에 있다.분산 시스템의 핵심 사안은 실패와 고장의 극..

• format_list_bulleted Deep Dive/OS
• · 2026. 1. 6.
• textsms

클린아키텍처 2편: ‘안쪽은 바깥을 몰라야 한다’

백엔드 개발에서 변경은 피할 수 없다. 비즈니스가 바뀌면 도메인과 유스케이스가 함께 바뀌는 건 자연스럽다. 문제는 그 반대다. 비즈니스 규칙은 그대로인데, DB/프레임워크/외부 SDK 같은 ‘디테일’ 변화가 핵심 로직까지 밀고 들어오면서 수정 범위가 폭발하는 순간이 있다. 이 글은 그 폭발의 원인을 “레이어”가 아니라 의존성 방향으로 설명하는 원칙, 즉 Dependency Rule(의존성은 안쪽으로만 흐른다) 하나에만 집중한다. 그럼 여기서 말하는 ‘의존성’은 정확히 무엇일까? 자바에서는 특히 import/타입 참조로 이 규칙이 깨지기 쉽다.Dependency Rule이 말하는 ‘의존성’의 정확한 의미클린 아키텍처에서 말하는 “의존성”은 추상적인 분위기 용어가 아니다. 특히 자바에서는 의존성이 꽤 구체적..

• format_list_bulleted Deep Dive/아키텍처
• · 2026. 1. 3.
• textsms

클린아키텍처 1편: 왜 클린 아키텍처가 필요해졌나?

과거 스타트업에서 아무것도 모른 채 기초만 막 떼고 개발을 시작했었다. 그러다 보니 일단 기능 위주로 돌아가게만 구현을 했었는데 나중에 요구사항의 변경으로 기능을 변경하거나 기술 스택이 변경되는 경우 매우 오랜 시간 수정을 하거나 많은 작업을 수행했어야 했다. 그렇기에 아키텍처가 중요하다는 것을 느끼게 되었다. 새로운 딥다이브 주제는 클린아키텍처이다. 단순하게 "어떻게 구현하나?"가 아니라 왜 이런 아키텍처가 등장했는지 어떤 것을 추구하는지 이해하려고 노력하겠다.1. 불편했던 경험담꼭 스프링이 아니더라도 개발을 하면서 경험했던 것이 있다.“Repository는 JPA를 쓰니까 JpaRepository를 상속하면 끝.”그런데 이런 질문을 할 수 있다. DB를 NoSQL로 바꾸면?테스트에서 메모리 저장소로 ..

• format_list_bulleted Deep Dive/아키텍처
• · 2026. 1. 2.
• textsms

[OSTEP] 스터디 18주차 Flash 기반 SSD

아마 2025년 마지막 포스팅이자 OSTEP 스터디 정리가 될 것이다. 2026년에도 계속해서 OSTEP 내용들과 개발 관련 포스팅을 올릴 수 있도록 하겠다.현대 스토리지 기술의 중심인 SSD(Solid State Drive)는 HDD와 달리 기계적 장치가 없으며, 반도체를 이용해 데이터를 저장한다. OSTEP(Operating Systems: Three Easy Pieces)에서 다루는 Flash 기반 SSD의 핵심 구조와 작동 원리, 그리고 운영체제가 직면한 과제들을 정리한다.1. 하드웨어 구조 (NAND Flash Structure)NAND 플래시 메모리는 데이터를 저장하기 위해 계층적인 구조를 가진다.뱅크(Bank) 및 다이(Die): 병렬 처리를 가능하게 하는 상위 단위이다.블록(Block): ..

• format_list_bulleted Deep Dive/OS
• · 2025. 12. 29.
• textsms

[OSTEP] 스터디 17주차 Part.2 Data Integrity and Protection

파일 시스템이 저널링을 통해 크래시 일관성을 완벽하게 보장한다고 해도, 저장 장치(디스크) 자체가 데이터를 망가뜨린다면 아무 소용이 없다. 현대의 파일 시스템과 스토리지 시스템은 이러한 하드웨어 레벨의 데이터 손상을 탐지하고 복구하기 위해 다양한 기법을 사용한다.1. 디스크 실패의 유형 (Disk Failure Models)디스크는 완벽하지 않으며 다양한 방식으로 실패한다. 가장 기본적인 모델은 디스크가 완전히 고장 나는 fail-stop이지만, 실제로는 더 까다로운 부분적 실패가 빈번하다.잠재적 섹터 오류 (Latent Sector Errors, LSEs): 디스크 표면의 물리적 손상이나 헤드 문제 등으로 인해 특정 섹터를 읽거나 쓸 수 없는 상태가 된다. 디스크 컨트롤러가 오류를 감지하고 운영체제에 ..

• format_list_bulleted Deep Dive/OS
• · 2025. 12. 23.
• textsms

[OSTEP] 스터디 17주차 Part.1 Crash Consistency: FSCK and Journaling

파일 시스템은 데이터를 디스크에 영구적으로 저장해야 하지만, 시스템 충돌(Crash)이나 전원 차단은 예고 없이 발생한다. 이 장에서는 파일 시스템이 어떻게 이러한 위기 속에서 데이터의 일관성을 유지하는지 깊이 있게 다룬다.1. 크래시 일관성 문제의 핵심 (The Problem)파일 시스템 업데이트는 단일 작업이 아니다. 책의 예시인 '파일에 하나의 데이터 블록을 추가하는 상황(Append)'을 가정해 본다. 이 작업을 완수하려면 디스크 상의 세 가지 구조체를 수정해야 한다.data bitmap: 새로운 블록이 할당되었음을 표시한다.inode: 파일 크기를 갱신하고 새 블록을 가리키는 포인터를 추가한다.data block (Db): 실제 사용자 데이터를 쓴다.문제는 디스크가 이 세 가지 쓰기 작업을 동시..

• format_list_bulleted Deep Dive/OS
• · 2025. 12. 23.
• textsms