클린아키텍처 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

[OSTEP] 스터디 16주차 Fast File System (FFS) 와 로그 구조화 파일 시스템 (LFS)

Fast File System (FFS)은 1984년 Berkeley의 Kirk McKusick이 기존 UNIX 파일 시스템(UFS, Old Unix File System)의 성능 문제점을 해결하기 위해 설계한 파일 시스템이다. FFS의 핵심은 디스크의 지역성(Locality)을 활용하여 I/O 효율을 극대화하는 것이다.Fast File System (FFS)1. FFS 탄생 배경: 기존 UNIX FS의 문제점기존 UNIX 파일 시스템(UFS)은 단순하고 깔끔했지만, 다음 두 가지 주요 문제 때문에 성능이 매우 나빴다.작은 블록 크기 (Small Block Size): UFS는 512 바이트의 작은 블록 크기를 사용했다. 이는 하나의 파일을 읽을 때 디스크 I/O 횟수가 많아져 효율성이 떨어지고, 파일 ..

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

[OSTEP] 스터디 15주차 Part.2 파일 시스템 구현

디스크는 그저 거대한 블록(Block)들의 배열일 뿐이다. 파일 시스템의 목표는 이 수많은 블록들을 관리하여 사용자가 편리하게 파일과 디렉터리를 쓸 수 있게 만드는 것이다. 어떻게 맨땅(Raw Disk)에 파일 시스템을 구축하는지, 그 구조부터 살펴보자.1. 디스크 구조 잡기 (On-Disk Structures)먼저 디스크를 블록 단위로 나눈다. OSTEP에서는 블록 크기를 4KB로 가정한다. 총 64개의 블록이 있다고 칠 때, VSFS는 이를 용도별로 구획한다.데이터 영역 (Data Region): 파일의 실제 내용이 저장되는 곳이다. 디스크의 대부분을 차지한다.아이노드 테이블 (Inode Table): 파일들의 메타데이터(크기, 권한, 소유자 등)를 저장하는 아이노드(inode)들이 모여 있는 곳이다..

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