해당 아티클 정리는 귀로 들으며 정리하는 포스팅입니다.
구글의 NotebookLM으로 요약한 내용을
라디오처럼 재생해 들으며 공부하고 있습니다.🎧

클린 아키텍처의 원칙과 적용 사례

모든 것의 시작은 “관심사의 분리”이다.

소프트웨어를 여러 레이어로 나누고 서로 미치는 영향을 최소화 하자.

로버트 마틴이 제시한 목표는 다음과 같다.

1. 특정 웹 프레임워크에 종속되지 말자.
2. 비즈니스 로직을 쉽게 테스트할 수 있게 하자.
3. UI가 바뀌어도 핵심 로직은 흔들리면 안된다.
4. 데이터베이스를 바꾸는 걸 제한이 되지 않게 하자.

이 동심원으 클린 아키텍처의 상징이라 한다.

안쪽 원부터 봐보면,

• Entity: 시스템의 심장부. 기업 전체에 적용되는 가장 핵심적인 비즈니스 규칙이다.(ex. 은행 - 계좌, 이체규칙)
• Use Case: 특정 애플리케이션의 비즈니스 규칙. 즉, 사용자가 이 앱으로 무엇을 할 수 있는가를 말한다.(ex. 송금하기, 대출 신청하기)
• Interface Adapter: 중간에서 원활하게 데이터를 주고 받을 수 있도록 하는 중간다리의 역할.
• Framework & Driver: 웹 프레임워크나 데이터베이스 같이 구체적인 기술 및 세부사항

이 구조가 제대로 작동하게 만드는 절대적인 규칙이 있다.

이는 의존성 규칙이다.

의존성 규칙

모든 소스 코드 의존성은 반드시 바깥쪽에서 안쪽으로 향해야 한다. 즉, 안쪽 원은 바깥쪽 원에 대해 아무것도 알 수 없다.

유스케이스는 웹 기술을 몰라야 하고, 엔터티는 데이터베이스 기술을 몰라야 한다.

그렇담 핵심로직을 데이터베이스 데이터로 저장해야 할 땐 어떻게 해야 할까?🤔 데이터베이스는 가장 바깥쪽에 있는데 모르는 상태로 소통이 가능한가?

이러한 문제를 해결하기 위해 의존성 역전 원칙이라는 기술을 활용한다.

카카오페이 사장님플러스 앱 사례에서는 상황에 맞게 위 규칙을 따르기 보다 유연하게 변형해서 사용했다고 한다.

읽기 쉬운 코드와 높은 생산성을 위해 다음과 같은 과정을 거쳤다.

1. 화면을 담당하는 presentation 레이어는 비즈니스 로직이 담긴 domain 레이어(유스케이스)를 통해서만 데이터에 접근해야 한다.
2. 복잡한 비즈니스 로직이 없을 땐 presentation 레이어가 domaion 레이어를 건너 뛰고, 바로 data 레이어에 접근해서 데이터를 가져올 수 있도록 한다.(반면, 여러 데이터를 조합하거나 복잡한 계산이 필요할 때는 원칙대로 domain 레이어의 유스케이스를 거치도록 한다.)

하지만 이 기능이 복잡하다 안복잡하다의 기준이 다르기에 작업 코드가 뒤죽박죽이 될 것이다. 이것에 대한 가이드라인은 없는 걸까?

카카오페이는 두 개 이상의 레포지토리를 사용해야 할 때, 유스케이스를 사용한다. 라는 규칙을 정했다.

의존성 역전 원칙

안쪽 계층이 자신이 필요한 것(인터페이스)을 정해두면, 바깥쪽 계층이 그 약속을 지키는 실제 내용물을 만들어서 제공하는 방식이다.

우아한 형제들은 이 원칙을 업무 도메인 사이에 적용했다고 한다.

배달 도메인과 배달료 도메인이 있다고 해보자. 배달료를 계산하려면 배달 거리 및 시간의 배달 정보가 필요하다. 하지만, 배달 도메인이 배달료의 구체적인 계산 방식까지 알 필요가 없다. 그래서 중간에 배달료를 계산해주는 인터페이스를 둔다. 배달 도메인은 이 인터페이스에만 의존하여 배달료 정책이 바뀌어도 영향을 받지 않는다.

배민 마켓 사례에서의 사례도 보자. 기존의 음식 배달 서비스와 서버 인프라는 거의 동일했지만 사용자에게 보여지는 화면이 새로 필요한 상황이었다.(즉, 기존 시스템을 활용한 신규 서비스 런칭 상황이었다.)

클린 아키텍처를 활용하여, 핵심 로직이 담긴 domain 레이어와 데이터 처리를 담당하는 data 레이어는 거의 재사용할 수 있었다. 덕분에 presentation 레이어만 새로 만들어 빠르게 개발할 수 있었다고 한다.

클린 아키텍처의 단점

1. 클래스 파일 수가 많아진다는 점.. 즉, 전체 구조를 파악하는 데 시간이 오래 걸린다는 학습 곡선이 존재한다.
2. DTO를 만들 때, 최대한 나누려고 하자. 상품 등록과 상품 수정 기능과 관련하여 봐보자. 이 때는 하나의 DTO를 쓰는 경우가 많다. 하지만 수정 부분에서 이메일 부분은 수정 못하게 해달라는 요구사항이 들어온다면, 등록 부분까지 영향이 가기 때문에 이런 상황에 대비하여 미리 구분해두는 게 좋다.

_{느낀점: “규칙을 무조건 지키는 것”보다 “사람들이 오래 편하게 개발할 수 있는 구조가 무엇인지 계속 고민하고 만드는 것”이 중요하다는 것을 배울 수 있었다. 상황마다 원칙을 유연하게 조절하는 기업 사례들이 더 현실적으로 와닿았고, 좋은 아키텍처는 미래의 팀을 덜 힘들게 해주는 배려라는 것을 알 수 있었다!}

🔗 https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html?utm_source=chatgpt.com 🔗 https://tech.kakaopay.com/post/ifkakao2024-architecture-migration-for-ceo-app/
🔗 https://techblog.woowahan.com/2647/ 🔗 https://techblog.woowahan.com/2602/

샤딩(Shading)과 파티셔닝(Partitioning)

사진이 많이 올라오는 SNS나 이커머스 사이트 같이 데이터가 쏟아지는 곳은 데이터를 어떻게 감당할 수 있을까?

샤딩과 파티셔닝의 정의와 어디서 활용하는지까지 정리해보자.

모든 샤딩은 파티셔닝이지만, 모든 파티셔닝은 샤딩이 아니다.

파티셔닝(Partitioning)

거대한 도서관이라고 생각하자. 단일 데이터베이스 서버 안에서 책들을 효율적으로 관리하기 위해 역사, 과학 등 코너를 나누는 것과 같다.

파티셔닝의 장점

1. 쿼리가 빨라진다. partition pruning(파티션 가지치기)을 통해 모든 파티션을 보는 게 아닌, 필요한 파티션만 뽑아서 본다.
2. 데이터 생명주기 관리가 편하다.

데이터를 나누는 기준에 따른 3가지 파티셔닝 방식이 있다.

1. 범위 파티셔닝: 날짜나 숫자, 연속적인 값을 기준으로 나눈다.(ex. 2025년 1분기, 2분기)
2. 목록 파티셔닝: 특정 값들의 목록을 기준으로 나눈다.(ex. 국가별)
3. 해쉬 파티셔닝: 사용자 id 같은 키를 해쉬 함수에 넣어서 나오는 결과값으로 데이터를 분산시킨다.(ex.국가별,기간별 데이터가 몰리는 현상 방지) 데이터가 여러 파티션에 균등하게 분배된다는 장점이 있다. 반면, 범위 검색이 거의 안된다는 단점이 있다.

샤딩(Shading)

지역 곳곳에 여러 도서관을 만드는 것. 데이터를 샤드라는 단위로 쪼개서 여러 다른 서버에 분산 저장하는 방식이다.

서버 한 대의 성능을 높이는 수직적 확장이 아닌 수평적 확장 방식이다.

샤딩의 장점으로는 다음과 같다.

1. 비용 절감 및 성능 향상
2. 결함 허용(서버 한 대가 고장나도 서비스가 멈추지 않는다.)

만약 여러 샤드에 걸친 데이터를 조회하는 쿼리를 실행할 때, 한 샤드가 다운되면 어떻게 될까?

보통 시스템은 하나라도 응답이 없으면 오류를 발생한다. 샤딩은 애플리케이션 단에서 이런 상황에서 어떻게 처리할 지 정교하게 설계해야 한다.

초창기 인스타그램에서는 물리적 서버가 얼마 없었지만 논리적 샤드를 수천 개 만들어놨다고 한다. 서비스가 커지며 서버를 추가할 때마다 논리적 샤드 덩어리들을 새 서버로 옮기며 확장해나갔다고 한다.

모든 샤딩은 파티셔닝이지만, 모든 파티셔닝은 샤딩이 아니다.

이 문장에 대해 알아보자.

파티셔닝은 데이터를 논리적 그룹으로 나누고, 샤딩은 데이터 조각을 여러 다른 서버 인스턴스에 분산시킨다.

즉, 데이터를 나누는 것은 파티셔닝의 범주에 들어가고 나누는 조각들을 여러 서버로 흩어놓는 물리적 분산이 동반될 때 샤딩이라 부른다.

수평 파티션을 다른 데이터베이스 인스턴스로 옮기는 순간 => 샤딩이 된다!

언제 파티셔닝을 쓰고 언제 샤딩으로 넘어가야 할까?

데이터는 계속 늘어나고 단일 서버로 충분히 운영 가능할 때
=> 파티셔닝

단일 서버의 CPU나 메모리가 한계에 도달하거나 디스크 공간 자체가 부족하거나 사용자가 전세계에 퍼져있어 지리적으로 데이터를 분산해야 할 때
=> 샤딩

PostgreSQL과 같은 관계형DB는 버전 10부터 선언적 파티셔닝 기능으로 강력한 파티셔닝 기능을 제공한다. 샤딩은 내장 기능 아니다! 확장 기능이나 로직을 직접 짜야 한다.

NoSQL에서는 샤딩이 아키텍처의 핵심이자 기본 기능이다.

_{느낀점: 파티셔닝과 샤딩은 개념만 보면 비슷해 보이는데, 실제로는 운영 난이도나 장애 대응 방식이 완전히 달라서 꽤 실전적인 고민이 되겠다는 걸 알게 됐다. 특히 인스타그램처럼 초기에 논리 샤드를 미리 만들어두는 전략을 보면서, 대규모 서비스를 준비하는 방식이 생각보다 치밀하다는 점이 인상적이었다.}

🔗 https://www.datacamp.com/blog/sharding-vs-partitioning
🔗 https://stackoverflow.com/questions/20771435/database-sharding-vs-partitioning

대규모 프론트엔드 아키텍처

서비스가 커질수록 기능 하나 추가하는데 배포도 느려지고 자칫 서비스가 마비가 되는 상황이 올 수가 있다.

어떻게 이 서비스를 안전하게 나눌 수 있을까?

MFA(Micro Frontend Architecture)

하나의 UI를 작고 독립적인 여러 조각으로 나누는 아키텍처다. 올리브영에서는 이 MFA를 위해 모듈 페더레이션을 이용했다. 하지만 이 기술을 이용하면서 어떤 어려움을 겪었는지, 또 Nx가 이를 어떻게 해결하였는지 알아보자.

모듈 페더레이션(Module Federation - MF)

MF는 자바스크립트의 분산화를 위한 아키텍처 패턴이다. 간단히 말해, 런타임에 여러 코드와 리소스를 병합하는 기술로 이해하면 된다.

기존 방식: 거대한 레고성 전체를 만들어가는 방식 런타임 통합 방식: 레고성의 각 구조물을 따로 만들어두고 사용자가 볼 때 실시간으로 합쳐서 보여주는 작업

• 호스트(Host): 다른 앱들을 로드하여 통합하는 주 애플리케이션. (ex. 레고성의 전체 설계도 및 기반이 되는)
• 리모트(Remote): 자신의 모듈을 다른 앱에서 사용할 수 있도록 하는 독립적인 마이크로 프론트엔드. (ex. 각각의 탑이나 성문 같은 부분 구조물)
• 공유 의존성(Shared Dependecies): 호스트 앱과 여러 리모트 앱 간에 공유할 의존성(라이브러리)이다. MF가 중복 코드를 방지하고 효율적으로 관리하게 해준다.

올리브영이 PoC 과정에서 마주한 문제는 다음과 같다.

1. 끔찍한 설정의 복잡성

새로운 remote 모듈을 추가할 때마다 웹팩이라는 빌드 도구의 설정 파일을 개발자가 직접 수동으로 설정해야 했다.

2. 타입 안정성 문제

호스트 앱에서는 리모트에서 어떤 형태의 코드를 가져오는지 전혀 알 수 없다.(ex. 상품 카드 컴포넌트를 가져오려고 하는데 이 컴포넌트가 어떤 것을 필요로 하는지 알 수 없는 문제) 그렇기에 개발자가 타입 정의 파일을 손으로 일일이 만들어야 하는 번거로움이 생긴다.

3. SSR 환경의 구현 어려움

Nx

모노레포를 관리하는 도구. 대규모 프로젝트에서 여러 앱과 라이브러리를 하나의 저장소에서 체계적으로 관리할 수 있도록 돕는 모노레포 도구이다.

Nx는 두 가지 방식으로 코드를 통합한다.

1. 빌드 타임 통합 : 여러 프로젝트를 따로 개발하더라도 배포할 때는 하나의 애플리케이션으로 합쳐서 내보낸다. (Affected - 수정한 부분과 관련된 부분만 선택적으로 빌드)
2. 런타임 통합: 모듈 페더레이션의 문제점을 해결해주는 해결사. 자동으로 앞서 복잡했던 문제들을 해준다는 것이다.

Nx가 제공하는 편리함을 얻는 대신 Nx가 정한 방식을 따라야 한다는 트레이드 오프가 존재한다.

_{느낀점: 사용자 경험을 지키면서도 각 기능이 독립적으로 움직일 수 있는 프론트엔드 구조가 얼마나 중요한지 다시 느꼈다. 좋은 아키텍처는 기능을 잘게 나누면서도 전체 경험은 하나처럼 보이게 만드는 균형을 찾는 일!!!}

🔗 https://oliveyoung.tech/2025-11-06/what-is-MFE-part2/
🔗 https://oliveyoung.tech/2025-11-10/what-is-MFE-part3/

당근 피드 시스템 표준화: Feed-Entity 구축기

페이스북이나, 안스타 같은 SNS 서비스들은 어떻게 수많은 사용자들에게 지연 없이 실시간으로 그 많은 데이터들을 보여줄 수 있는 걸까?

대규모 뉴스 피드 시스템이 어떤 구조로 돌아가는지 핵심 원리를 알아보자.

피드 발행, 뉴스 피드 구축 이렇게 두 가지로 크게 잡아서 아티클에서 이야기한다.

1. 피드 발행

사용자가 하나의 글을 올렸을 때 시스템은 어떻게 돌아가는걸까? 포스팅 버튼을 누르면 해당 요청이 로드 밸런서를 먼저 통과하고, 해당 요청을 받은 웹 서버가 돌아가게 될 것이다. 여기서 웹 서버가 모두 처리하는 것이 아닌, 잘게 쪼개서 담당 전문가들한테 분업이 된다.

여기서 전문가는 3가지로 나눠서 이야기할 수 있다.

• 포스트 서비스: 텍스트나 사진을 데이터베이스에 저장하는 역할
• 알림 서비스: 친구에게 새 글이 올라왔다는 알림 역할
• 팬 아웃 서비스: 나의 새 게시물을 친구들에게 쫙 전달해주는 역할

2. 뉴스 피드 구축

사용자가 내 피드 보여달라는 요청을 하면 뉴스 피드 서비스로 해당 요청이 가게 된다. 시스템은 각 사용자 별로 뉴스 피드 캐시 라는 개인 전용 창고를 매리 만든어둔다. 뉴스 피드 서비스는 이 창고에서 팬 아웃 서비스가 쌓아둔 게시물 목록에서 꺼내오기만 하면 된다.(속도 향상)

• 팬 아웃 온 wirte: 쓰기 시점에 가져온다. 미리 다 만들어 둘 것인가(push 방식)
• 팬 아웃 온 read: 읽기 시점에 가져온다. 필요할 때마다 즉석에서 만들 것인가(pull 방식)

push 방식의 단점

팔로워가 수백 만명인 유명인이 글을 올리면 어떻게 될까? 게시물 하나를 수백만의 캐시에 일일이 복사해서 넣어주기에 마비가 될 수 있는 위험이 있다.(Hot Key 문제)

pull 방식의 단점 push 방식과 다르게 유명인이 글을 올려도 아무 일도 하지 않기 때문에 위험하지 않지만, 피드를 볼 때마다 로딩이 올래걸리는 점을 감수해야 한다. 매번 로딩만 보고 있어야 할 수도 있다..

대규모 서비스들은 이 둘을 섞은 하이브리드 방식을 이용한다.

일반 사용자들끼리는 push 방식으로,
유명인과 팔로원 사이에는 pull 또는 유명인들은 따로 모아서 사용자들이 피드를 요청할 때 일반 친구들 피드와 유명인 피드를 합쳐서 보여주는 방식으로 한다.

팬 아웃 서비스

1. 그래프 데이터 베이스에서 글을 쓴 사용자의 친구 id를 모두 가져온다.
2. 사용자 캐시나 데이터베이스에서 친구들의 개인 설정을 확인한다.
3. 메시지큐를 이용하여 차근차근 작업을 처리할 수 있도록 한다.

만약 메시지큐에 데이터가 너무 쌓여서 처리하는 속도보다 쌓이는 속도가 빠르다면 어떻게 될까?

이를 위해

4. 여러 대 팬아웃 워커 서버들이 메시지 큐에 쌓인 작업을 경쟁적으로 가져가서 처리한다.
5. 작업을 가져간 워커들이 각 친구의 뉴스 피드 캐시에 user id, post id를 저장한다.

_{느낀점: 겉으로 보기엔 엄청 복잡해 보이는 SNS 피드도, 결국 “발행 → 팬아웃 → 캐시된 피드 읽기”라는 단순한 흐름을 잘게 쪼개서 조합한 거라는 게 인상적이었다. 이런 구조를 알고 나니, 언젠가 내가 만드는 서비스에서도 “피드처럼 보이는 기능”을 설계할 때 훨씬 더 현실적인 선택을 할 수 있을 것 같다!}

🔗 https://thenewstack.io/building-scalable-news-feed-applications-using-redis-and-cassandra/
🔗 https://aws.amazon.com/ko/blogs/architecture/how-karrot-built-a-feature-platform-on-aws-part-1-motivation-and-feature-serving/
🔗 https://bytes.usc.edu/~saty/courses/docs/data/SystemDesignInterview.pdf
🔗 https://caffeinewoo.tistory.com/36
🔗 https://www.youtube.com/watch?v=qYo0R2nv1PQ
🔗 https://about.daangn.com/blog/archive/%EB%8B%B9%EA%B7%BC-%ED%94%BC%EB%93%9C%EC%8B%A4-%EC%B1%84%EC%9A%A9-%ED%99%88%ED%99%94%EB%A9%B4-%EA%B0%9C%EB%B0%9C%EC%9E%90-pm/
🔗 https://about.daangn.com/blog/archive/%EB%8F%99%EB%84%A4-%EC%86%8C%EC%8B%9D-%EC%97%B0%EA%B2%B0%ED%95%98%EB%8A%94-%EC%8A%88%ED%8D%BC-%ED%94%BC%EB%93%9C%EB%A5%BC-%ED%96%A5%ED%95%98%EC%97%AC/
🔗 https://www.samsungsds.com/kr/insights/1239180_4627.html