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

[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