# 단순한 아키텍처를 옹호하며 (2022)

> Clean Markdown view of GeekNews topic #13754. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=13754](https://news.hada.io/topic?id=13754)
- GeekNews Markdown: [https://news.hada.io/topic/13754.md](https://news.hada.io/topic/13754.md)
- Type: news
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2024-03-11T11:04:02+09:00
- Updated: 2024-03-11T11:04:02+09:00
- Original source: [danluu.com](https://danluu.com/simple-architectures/)
- Points: 46
- Comments: 9

## Topic Body

- Wave는 70명의 엔지니어를 보유한 $1.7B(2.3조원) 규모의 회사 (아프리카를 위한 모바일 뱅킹 서비스 제공)  
- Postgres 기반의 Python 모놀리스인 표준 CRUD 앱 아키텍처로 되어있음  
- 단순한 아키텍처를 시작으로 복잡성을 최소화하며 문제를 해결함으로써 사용자에게 가치를 제공하는 작업에 엔지니어가 집중할 수 있었음  
- Stackoverflow는 단일체(monolith)를 확장하여 18억 달러에 인수될 정도로 성공적으로 성장함  
  
### 단순한 아키텍처의 효율성에도 불구하고 대부분의 언론은 복잡한 아키텍처를 좋아함  
  
- 기술 컨퍼런스에서는 복잡한 마이크로서비스 기반 아키텍처에 대한 발표가 많으나 단순한 모논리스에 대한 발표는 없음  
- 많은 기업들이 작은 규모 애플리케이션임에도 불구하고 복잡한 기술을 모방하고 그걸로 컨퍼런스 및 HN에서 인기를 얻음   
- 우리가 사용하는 아키텍처는 너무 단순해서 아키텍처 다이어그램을 작성할 필요도 없음  
  
### 단순함을 유지하는 방법  
  
- Wave는 동기식 Python을 사용하고 있으며, 이는 서버 프로세스가 I/O를 기다리는 동안 차단됨을 의미함  
- Eventlet 같은 비동기 프레임워크를 시도했지만, 버그가 너무 많아서 그 비용이 운영상의 고통을 감당할 가치가 없다고 판단했음   
- 복잡성을 증가시키는 대신, 긴 실행 시간이 필요한 작업은 큐로 분리하여 처리함  
- 데이터 거주 규정을 준수하기 위해 일부 국가에서는 온프레미스 데이터센터를 운영해야 함  
  - 세네갈/코트디부아르는 클라우드였지만, 우간다와 다른 국가들은 규정때문에 온프레미스를 필요로 함  
  - 이럴때 복잡한 아키텍처보다 단순한 아키텍처가 훨씬 간단함  
  
### 구매 대신 구축  
  
- 소수 인원팀이라 초기에는 소프트웨어 구매를 선호했으나, 중대한 버그를 해결할 수 없는 경우에는 자체 도구를 개발함  
- 자체 도구 구축은 우리가 감당하고 싶지 않은 복잡성이지만, 일부 제품 카테고리에서는 상당히 광범위한 조사 후에도 우리에게 적합한 제품을 제공할 수 있는 공급업체를 찾지 못함   
- 핵심 역량 외에도 자체 도구를 개발하고 내부 전문성을 유지하는 것이 때로는 필요함  
  
### 재고 중인 선택들  
  
- RabbitMQ, Celery, SQLAlchemy, Python 등의 기술 선택에 대해 재고 중이며, 이들은 복잡성을 증가시키거나 유지 관리 부담을 높임  
- 새로운 코드베이스를 시작한다면 이러한 기술 선택에 대해 신중하게 고려할 것임  
  
### 만족하는 선택들  
  
- GraphQL, 사용자 정의 트랜스포트 프로토콜, Kubernetes 등의 선택에 만족함  
- GraphQL은 자체 문서화, 코드 생성, GraphiQL 인터랙티브 탐색기 등의 장점이 있음.  
- GraphQL을 사용하면 장점이 단점보다 더 크다고 생각  
  - 장점   
    - 정확한 반환 유형에 대한 자체 문서화  
    - 정확한 반환 유형의 코드 생성으로 인해 클라이언트가 더 안전해짐  
    - GraphiQL 대화형 탐색기로 생산성 향상  
    - 다양한 앱(사용자 앱, 지원 앱, Wave 에이전트 앱 등)이 대부분 하나의 API를 공유할 수 있어 복잡성이 줄어듦  
    - 구성 가능한 쿼리 언어를 사용하면 클라이언트가 특수 목적 엔드포인트를 많이 구축할 필요 없이 단일 패킷 왕복으로 필요한 데이터를 정확하게 가져올 수 있음     
    - RESTful API로 간주되는 항목에 대한 bikeshedding (중요한 안건을 미뤄둔 채 덜 중요한 일에 대해 깊이 의논하고 시간을 보내는 것) 제거  
  - 단점   
    - GraphQL 라이브러리는 GraphQL을 채택했을 당시엔 훌륭하지 않았음   
    - 기본 GQL 인코딩은 중복되며 많은 고객이 낮은 대역폭을 사용하기 때문에 크기 제한에 많은 관심을 기울이고 있음   
- Kubernetes는 국가별 데이터센터 운영 요구 사항을 충족시키기 위해 사용됨  
  
### 결론   
- 애플리케이션 아키텍처를 최대한 단순하게 유지함으로써 비즈니스에 도움이 되는 복잡성이 있는 곳에 복잡성(및 인력) 예산을 지출할 수 있음   
- 복잡함을 더할 강력한 이유가 없는 한 가능한 한 간단하게 일을 처리한다는 생각을 통해 우리는 일반적으로 어려운 사업이라고 여겨지는 아프리카 금융 사업을 운영하고 있음에도 불구하고 엔지니어가 많이 없이도 상당히 큰 사업을 구축할 수 있었음

## Comments



### Comment 23776

- Author: secret3056
- Created: 2024-03-18T08:57:53+09:00
- Points: 1

"구축 대신 구매"는 "구매 대신 구축"이 맞는것 같아요.  
  
> Another area is with software we’ve had to build (instead of buy).

### Comment 23779

- Author: xguru
- Created: 2024-03-18T09:26:12+09:00
- Points: 1
- Parent comment: 23776
- Depth: 1

아 강조 하려다가 제목이 이상해져 버렸네요. 수정했습니다. 고맙습니다.

### Comment 23664

- Author: savvykang
- Created: 2024-03-12T15:49:31+09:00
- Points: 1

경제 사이클에 따라서 유행이 바뀌는걸까요? 유행에 상관없이 모놀리스로 시작하는게 고정비용 절감과 유지보수에 유리합니다

### Comment 23656

- Author: aer0700
- Created: 2024-03-12T10:14:48+09:00
- Points: 1

이해하기 쉬운 아키텍쳐가 유지보수하기도 쉽죠.

### Comment 23647

- Author: mhj5730
- Created: 2024-03-12T08:12:09+09:00
- Points: 1

제 기준 어떤 서비스든간에 모놀리식으로 시작하는게 좋아보입니다. 초기부터 MSA 잡고 들어가면 돈 낭비죵

### Comment 23644

- Author: dhlee0305
- Created: 2024-03-11T18:10:58+09:00
- Points: 1

"복잡도가 올라가면 비용(돈, 사람, 시간...)도 증가한다"  
"심플한 아키텍처로 해결할 수 있는 문제를 복잡한 아키텍처로 해결하려 하지 마라."

### Comment 23632

- Author: xguru
- Created: 2024-03-11T11:05:01+09:00
- Points: 1

#### [Hacker News 의견](https://news.ycombinator.com/item?id=39440179)   
- **마이크로서비스에 대한 엔지니어 조언**  
  - 마이크로서비스는 성능 향상 전략이 아니라, 잠재적인 비용 절감 전략과 엔지니어링 조정 전략임.  
  - 수평적으로 확장 가능한 모놀리식 애플리케이션과 마이크로서비스 간에는 큰 차이가 없음, 특정 기능을 축소하고자 할 때를 제외하고.  
  - 모놀리식 앱에서는 앱의 일부만 축소하는 것이 불가능함.  
  - 비용 절감은 대규모에서 시작되며, 최소 3개의 복제본이 필요함.  
  - 대부분의 회사에서 실제 이점은 엔지니어링 조정에 있음.  
  - 단일 저장소를 가진 모놀리식에서는 한 팀이 소유하고 관리할 수 있지만, 공유 모놀리식에서는 아무도 소유하지 않아 관리가 어려워짐.  
  
- **마이크로서비스에 대한 토크**  
  - 일반 기술 컨퍼런스에서 마이크로서비스 아키텍처의 복잡성과 부작용에 대한 여러 발표가 있었으나, 단순한 모놀리식 구축에 대한 발표는 없었음.  
  - David Schmitz의 마이크로서비스 실패에 대한 팁을 다룬 강연이 인상적이었으며, 그의 유머러스한 발표 방식이 매력적임.  
  
- **인지적 편향과 단순성**  
  - 사람들은 종종 무언가를 추가하는 것에 집중하며, 간단한 해결책을 간과함.  
  - 연구에서는 레고 구조물에 벽돌을 추가하는 대신 제거함으로써 문제를 해결하는 것이 더 나은 해결책임을 보여줌.  
  
- **과도한 엔지니어링과 경험 부족**  
  - 아키텍처는 "충분히 단순하면서 필요한 만큼 복잡해야" 하지만, 이를 달성하는 것은 경험이 필요함.  
  - IT 산업은 경험이 부족한 경향이 있으며, 경험은 시간이 걸림.  
  - 경험이 부족한 엔지니어와 관리자는 종종 불필요한 기술이나 메트릭스를 사용함.  
  
- **일과 삶의 균형을 중시하는 회사**  
  - 제품 개선에 집중하고 나머지 시간을 개인 생활에 할애하고 싶은 회사를 찾고 있음.  
  
- **Dan Luu에 대한 개인적 경험**  
  - Dan Luu는 블로그 팬과의 소통에 관대하며, 소프트웨어와 하드웨어 경계에 대한 전문 지식을 가지고 있음.  
  - 그의 통찰력과 전문성을 공유하는 데 아낌없으며, 그로부터 배우는 것은 매우 즐거운 경험임.  
  
- **단순한 아키텍처의 중요성**  
  - 대부분의 경우 필요한 아키텍처는 SSL 지원 로드 밸런서, 여러 앱 서버, 샤딩된 데이터베이스, 메시지 큐 등 기본적인 구성 요소임.  
  
- **아키텍처와 엔지니어링 팀의 사회적 구조**  
  - 아키텍처는 엔지니어링 팀의 사회적 구조를 반영해야 하며, 이를 고려하지 않으면 혼란과 비효율이 발생할 수 있음.  
  - 대규모 모놀리식 저장소와 단순한 아키텍처는 관리가 어려울 수 있으며, 구글과 메타와 같은 회사들도 내부적으로 많은 툴을 개발함.  
  - 아키텍처는 팀 간 협업을 지원하거나 방해할 수 있으므로, 기술 리더십은 이를 고려해야 함.  
  
- **단순한 아키텍처의 선호**  
  - 단순한 아키텍처와 모놀리식이 대부분 적합하지만, 동기식 IO로 인한 문제가 발생하지 않도록 주의해야 함.  
  - 데이터 무결성 버그는 금융 시스템에서 피해야 할 중요한 문제임.

### Comment 23821

- Author: dangyup
- Created: 2024-03-18T20:27:38+09:00
- Points: 1
- Parent comment: 23632
- Depth: 1

"David Schmitz의 마이크로서비스 실패에 대한 팁을 다룬 강연" 링크를 요청드려도 될까요.

### Comment 23827

- Author: xguru
- Created: 2024-03-19T08:33:15+09:00
- Points: 1
- Parent comment: 23821
- Depth: 2

https://www.youtube.com/watch?v=r8mtXJh3hzM 입니다