[개발읽기 vol.9] 클라우드 아키텍처 진화: 모놀리식에서 MSA까지 완벽 정리

요즘 Yarn Berry랑 pnpm을 공부하다 보니까, 자연스럽게 모노레포(Monorepo)라는 개념을 알게 되었어요.

 

처음에는 단순히 패키지 관리나 프로젝트 구조를 조금 더 효율적으로 만드는 방법 정도로만 생각했는데, 조금 더 깊이 공부해보니 이게 프로젝트 구조뿐만 아니라 전체 아키텍처와도 연결돼 있다는 걸 깨달았죠.

모노레포에서 시작해서 점점 서비스 지향 아키텍처(SOA), 그리고 MSA(마이크로서비스 아키텍처)까지 아키텍처가 진화하는 과정을 보면서, 단순한 코드 관리 이상의 의미가 있다는 걸 알게 되었어요.

 

특히 저희 회사도 이미 MSA 구조를 쓰고 있어서, "MSA가 뭔지 모르고 쓰는 건 안 되겠다"는 생각이 들었습니다.

단순히 백엔드 개발자만 아는 지식이 아니라, 프론트 개발자에게도 꼭 필요한 내용이라는 점이죠.

공부를 이어가면서 서비스별 독립 배포, API 호출 구조, 장애 대응 방식 같은 MSA 요소들을 이해하면, 프론트 개발에서도 훨씬 효율적이고 안정적으로 구현할 수 있다는 걸 깨달았죠.

결국 단순히 패키지를 설치하고 프로젝트를 관리하는 단계에서 시작했지만, 점점 클라우드 아키텍처와 MSA의 중요성을 몸소 체감하게 되었습니다.

 

 

그래서 이번 글에서는 모노레포부터 MSA까지 아키텍처가 어떻게 진화했는지, 그리고 각각의 구조가 갖는 의미와 장단점을 쉽게 정리해보려고 합니다.

읽으시는 분들께도 도움이 되었으면 좋겠어요.

 

 

💡 프론트엔드인데 왜 클라우드 아키텍처를 알아야할까?

 

1️⃣ 배포와 운영 이해

• 프론트엔드도 서버/클라우드 환경에서 돌아가는 경우가 많습니다.
• 정적 파일(HTML, JS, CSS)을 클라우드에 배포할 때, CDN, 서버, 스토리지 구조를 이해하면 문제 해결과 최적화가 쉬워집니다.
• 예: AWS S3 + CloudFront로 빠른 페이지 로딩, 트래픽 폭주 대응

2️⃣ MSA와 API 구조 이해

• 현대 클라우드 환경에서 백엔드는 대부분 MSA로 구성되어 있습니다.
• 프론트엔드는 여러 마이크로서비스 API를 호출하게 되는데,
  • 서비스별 엔드포인트 구조
  • 인증/권한 처리
  • 장애 처리 및 fallback 로직
    이런 것을 이해하면 효율적 프론트 개발이 가능해집니다.

3️⃣ 확장성과 성능 최적화

• 클라우드 아키텍처를 이해하면, 프론트 성능 최적화가 더 쉬워집니다.
• 예:
  • 이미지/동영상 CDN 배포
  • 서버리스 함수와 연동한 프론트 로직
  • Lazy loading, API throttling

4️⃣ DevOps, CI/CD와 연계

• 프론트엔드도 요즘은 자동 빌드/배포(CI/CD) 환경에서 돌아갑니다.
• 클라우드 아키텍처를 이해하면:
  • 배포 파이프라인 설계
  • 환경별 설정 관리(dev/stage/prod)
  • 에러 추적 및 모니터링
    이런 작업을 더 능숙하게 할 수 있습니다.

5️⃣ 비즈니스와 팀 협업 이해

• 클라우드 아키텍처를 이해하면:
  • 백엔드, DevOps, 인프라 팀과 원활한 협업 가능
  • “왜 이 API가 느린지?”, “왜 배포가 오래 걸리는지” 이해 가능
• 결과적으로 프론트엔드 개발자로서 서비스 전체를 이해하는 시야가 생깁니다.

 

💡 프론트엔드 개발자에게 클라우드 아키텍처 지식은 단순히 서버 지식이 아니라,

• API 구조 이해
• 배포와 성능 최적화
• 팀 협업과 서비스 운영 능력

를 높여주는 필수 역량입니다.

 

---

 

클라우드 아키텍처란?

 

클라우드 아키텍처(Cloud Architecture)는 인터넷 위에서 서비스가 어떻게 작동할지를 설계하는 방법을 말합니다.

쉽게 말하면, 누군가 웹사이트에 접속했을 때 페이지가 잘 뜨고, 버튼을 클릭하면 원하는 기능이 실행되며, 데이터가 저장되거나 불러와지도록 앱이나 서비스를 서버, 저장 공간, 네트워크 등에 배치하고 미리 계획한 전체 구조를 말합니다.

---

핵심 개념

클라우드 운영 방식은 총 2가지로 나뉩니다.

서버리스(Serverless) 방식과 서버 기반(Server-based) 방식 두가지가 있습니다.

 

클라우드 설계의 핵심 특징에는

분산 구조(Distributed) : 여러 서버와 서비스가 서로 통신하며 동작하여 장애가 발생해도 전체 서비스가 멈추지 않도록 설계함

 

확장성(Scalability): 사용자가 늘어나면 자동으로 서버나 리소스를 늘림 → 클라우드의 큰 장점

 

클라우드 설계를 잘해야 사람들이 편리하게 이동하고, 필요할 때 방을 늘리거나 줄일 수 있는 것처럼, 클라우드 아키텍처도 효율적인 서비스 운영을 위해 꼭 필요합니다.

 

 

클라우드 구조 핵심 요소

• 서버(Server) : 실제 애플리케이션을 실행하고 데이터를 처리하는 공간.
• 네트워크(Network) : 서버, 스토리지, 사용자를 연결하여 데이터와 요청을 전달.
• 스토리지(Storage) : 데이터를 저장하고 필요할 때 불러오는 공간.
• 애플리케이션(Application) : 사용자가 실제로 이용하는 기능과 서비스.
• 로드밸런서(Load Balancer) : 여러 서버에 트래픽을 분산하여 과부하를 방지.
• 자동 확장(Auto Scaling) : 사용량 변화에 따라 서버 수를 자동으로 늘리거나 줄임.
• 보안(Security) : 데이터와 서비스 보호, 접근 통제.
• 클라우드 서비스 계층
  • IaaS(인프라): 서버, 스토리지, 네트워크를 직접 구성
  • PaaS(플랫폼): 애플리케이션 실행 환경 제공, 서버 관리 불필요
  • SaaS(서비스): 최종 사용자에게 바로 제공되는 애플리케이션

 

---

 

 

클라우드 아키텍처의 진화: 모놀리식에서 MSA까지

클라우드 환경에서 애플리케이션 아키텍처는 끊임없이 발전해 왔습니다. 오늘은 전통적인 모놀리식(Monolithic) 아키텍처부터, 서비스 지향 아키텍처(SOA), 그리고 최신 마이크로서비스 아키텍처(MSA)까지 그 흐름과 특징을 정리해보겠습니다.

 

 

 

🔹 모놀리식(Monolithic) 아키텍처

모놀리식은 모든 기능을 하나의 애플리케이션에 통합한 구조입니다.

초기 개발이 간단하고 배포가 단일 단위라 관리가 쉽지만, 서비스가 커질수록 유지보수가 어려워집니다.

• 저장소: 일반적으로 하나의 저장소에서 모든 기능 관리 / 작은 프로젝트나 전통적 구조에서는 자연스럽게 하나의 저장소
• 배포: 전체 앱 단위
• 팀 협업: 작은 팀에 적합, 동시에 여러 기능 개발 시 충돌 가능
• 특징: 코드 통합, 배포 단순, 작은 변경에도 전체 배포 필요

[모놀리식 앱]
 ├── 사용자 관리
 ├── 주문 관리
 ├── 결제 관리
 └── 상품 관리
 
프로젝트 구조 (Git 저장소: 1개)
/app
  /login
  /board
  /payment
  /user
server.js

 

1️⃣ 단일 빌드 & 배포

• 프론트엔드가 백엔드와 함께 한 번에 배포됨
  (보통 프론트엔드 코드와 백엔드 코드가 같은 프로젝트/깃 저장소 안에 존재하는 경우가 많음.)
• 개발자가 서버를 빌드하면 프론트와 백엔드가 동시에 묶여서 배포.
• 예를 들어, Spring Boot 서버 안에 /static 폴더로 프론트 빌드 결과물이 들어가고, 서버를 띄우면 동시에 프론트와 백엔드가 동작하는 구조입니다.
• 장점: 배포가 간단하고 버전 관리 용이
• 단점: 작은 변경에도 전체 애플리케이션을 다시 배포해야 함

2️⃣ 코드 구조

• 프론트엔드와 백엔드 코드가 통합되어 있음
• 장점: 작은 프로젝트에서는 구조가 단순하고 이해하기 쉬움
• 단점: 프로젝트가 커지면 코드 의존성이 많아 유지보수가 어려움

3️⃣ 성능 및 확장

• 특정 페이지만 독립적으로 최적화하거나 확장하기 어려움
• 프론트 성능 최적화(예: lazy loading, CDN 활용) 제한적

4️⃣ 팀 협업

• 동일 코드베이스 공유로 충돌 발생 가능
• 기능 추가 시 전체 시스템 테스트 필요

✅ 요약

• 초기 개발 속도가 빠르고 SSR 같은 전통적 구조와 연동 쉬움
• 코드가 커지면 모듈화 어려움, 배포 주기가 길고 SPA 등 최신 프론트와 결합 시 확장성 제한
• 단일 애플리케이션이므로 한 기능 수정 시 전체를 배포해야 하는 위험도 존재합니다.

 

 

 

🔹 서비스 지향 아키텍처(SOA)

SOA는 기능 단위로 서비스를 나누고, 서비스 간 메시지나 API로 통신하는 구조입니다. 재사용성이 높고 대규모 시스템에 적합하지만, 서비스 간 통신 구조가 복잡해져 유지보수가 쉽지 않습니다. 클라우드 환경에서 SOA는 확장성과 재사용성을 위한 첫 단계로 볼 수 있습니다.

• 저장소: 저장소는 하나로 관리할 수도 있고, 서비스별로 나눌 수도 있음
• 배포: 통합 배포 가능 (전체 서버 기준)
• 팀 협업: 서비스별 개발 가능, 병렬 작업 가능
• 특징: 기능 단위로 분리, 배포는 아직 전체 단위, 서비스 간 의존 존재

SOA는 서비스 단위로 나누지만 배포는 통합될 수 있는 구조.

💡 중요한 건 서비스가 논리적으로 독립적이라는 점이지, Git 저장소 수는 필수 조건이 아님.

[SOA]
 ├── 사용자 서비스 ↔ 주문 서비스
 ├── 결제 서비스 ↔ 상품 서비스
 
프로젝트 구조
/monorepo (Git 저장소 1개 가능)
  /auth-service
  /board-service
  /payment-service
/frontend
server.js (전체 배포)

 

1️⃣ 서비스 단위 호출

• 프론트엔드는 단일 백엔드가 아니라 여러 서비스 API 호출 (서비스 단위 ≠ 서버 단위)

이 서비스는 반드시 서버가 분리된다는 뜻이 아니라, API/모듈 단위로 독립적이라는 의미예요.

예: 사용자 관리, 주문 처리, 결제 기능이 각각 서비스라고 하면,

• 같은 서버 안에서 독립 모듈로 구현할 수도 있고
• 실제로 다른 서버로 나눌 수도 있습니다.
• 장점: 필요한 기능만 호출 가능, 백엔드 변경이 프론트에 덜 영향

** 단일 백엔드란?

모놀리식 구조에서는 보통 프론트엔드가 요청을 보내는 서버가 하나입니다.

예를 들어, 쇼핑몰 앱이 있다고 할 때: 사용자 로그인, 상품 조회, 주문, 결제 기능이 하나의 서버에서 모두 처리됨

그래서 프론트는 항상 이 서버에 요청만 하면 모든 기능을 사용할 수 있습니다.

즉, 단일 백엔드 = 프론트가 호출하는 서버가 한 곳뿐이라는 의미예요.

 

2️⃣ 독립적 개발 가능

• 각 서비스가 독립적이므로 팀이 병렬 개발 가능
• 장점: 기능 추가/수정 시 전체 시스템 영향을 최소화

예시: 쇼핑몰 서비스 개발

1. 서비스 단위 분리
   • 사용자 서비스: 회원가입, 로그인, 프로필 관리
   • 주문 서비스: 상품 주문, 장바구니
   • 결제 서비스: 결제 처리, 결제 내역 확인
2. 팀 구성
   • A팀 → 사용자 서비스 개발
   • B팀 → 주문 서비스 개발
   • C팀 → 결제 서비스 개발

 

3️⃣ 통신 구조 이해 필요

• 프론트는 서비스별 엔드포인트, 인증/권한, 에러 처리를 이해해야 함
• 인증/권한은 모놀리식에서도 필요했지만,
  • SOA에서는 서비스가 분리되면서 각 서비스가 독립적으로 인증/권한을 체크할 수 있음
  • 따라서 프론트는 서비스별로 올바른 토큰·권한 정보를 전달해야 함
  • 인증/권한 처리 로직이 분산되므로 관리가 더 까다로움
• 서비스 간 의존성은 낮지만, 네트워크 지연·장애 상황까지 고려해야 함

4️⃣ 코드 구조

• API 호출 많아짐 → API 관리 모듈, 상태 관리(store/context) 설계 필요
• 장점: 코드 모듈화 가능
• 단점: 서비스 수가 많아지면 관리 부담 증가

 

✅ 장점

• 대규모 시스템에서도 유연한 확장 가능
• API 테스트와 프론트 개발 병행 가능
• MSA 이전, 서비스 단위 사고에 익숙해짐

✅ 단점

• 서비스별 API 호출 증가 → 네트워크 비용 상승
• 서비스 상태 통합 관리 필요
• 초기 설계가 복잡, 러닝 커브 존재

 

🔹마이크로서비스 아키텍처(MSA)

MSA는 작은 단위의 서비스로 애플리케이션을 분리하고, 각 서비스는 독립적으로 배포됩니다. 컨테이너(Docker)와 오케스트레이션(Kubernetes)와 같은 클라우드 기술과 결합하면 빠른 배포와 유연한 확장이 가능합니다.

MSA는 개발 효율성, 안정성, 비용 최적화를 동시에 잡을 수 있지만, 서비스 간 통신과 데이터 관리, 모니터링 체계가 필수적입니다.

• 저장소: 서비스별 독립. 보통 서비스별 저장소를 가지는 경우가 많음
• 배포: 서비스 단위 완전 독립
• 팀 협업: 서비스 단위 담당 → 팀별 배포 가능
• 특징: 독립적 배포, 확장성 뛰어남, 장애 영향 최소화

MSA는 서비스 단위가 완전히 독립적 배포를 전제로 함.

그러나 기술적으로는 하나의 저장소(monorepo)에서도 MSA처럼 독립 서비스 개발 가능 → 단지 배포와 관리가 복잡해짐

[MSA]
 ├── 사용자 서비스 → 독립 컨테이너
 ├── 주문 서비스 → 독립 컨테이너
 ├── 결제 서비스 → 독립 컨테이너
 └── 상품 서비스 → 독립 컨테이너
 
 
프로젝트 구조 (Git 저장소 서비스별 독립)
auth-service/  (Git repo A)
board-service/  (Git repo B)
payment-service/  (Git repo C)
frontend/      (Git repo D)

 

1️⃣ 독립적 배포

• 서비스별 API 호출을 통해 기능 구성
• 특정 서비스 업데이트가 다른 서비스에 영향 없음
• ✅ 작은 변경도 개별 배포 가능 → 배포 주기 단축

2️⃣ API 중심 개발

• 프론트는 서비스별 API 계약(API contract)에 맞춰 개발
• 인증/권한 처리, 에러 핸들링, fallback 로직 고려 필요
• ✅ 서비스 단위 테스트 및 유지보수 효율 ↑

3️⃣ 성능 최적화·확장 용이

• 필요한 서비스만 스케일 업/다운 가능
• CDN, 서버리스 함수, lazy loading 활용 쉬움

4️⃣ 팀 협업·개발 효율

• 프론트/백엔드 팀이 독립 작업 가능
• 소규모 팀 단위 담당 → 개발 속도 ↑
• 장애 발생 시 특정 서비스만 대응 가능

✅ 장점

• 빠른 개발·배포
• 서비스 단위 유지보수·테스트 용이
• 클라우드 환경에서 최적화·확장성 확보

✅ 단점

• 서비스 수 증가 → API 호출·상태 관리 복잡
• 네트워크 지연·장애 처리 로직 필요
• 초기 설계, 모니터링·로깅 체계 구축 필수

💡 핵심 포인트: 저장소 수는 아키텍처를 결정하는 필수 조건이 아니고, 배포 독립성과 서비스 독립성이 핵심이에요.

 

 

 

 

요즘 흔한 조합

SPA (React/Vue) + 백엔드 MSA + 경우에 따라 Micro Frontend 적용

** Micro Frontends(마이크로 프론트엔드, MFE) 

• 화면을 여러 팀/서비스 단위로 쪼개서 독립 배포
• 예) 쿠팡 메인 페이지의 "배너 영역", "추천 상품", "장바구니"가 각각 다른 팀에서 독립 개발/배포

https://medium.com/@isuruariyarathna2k00/a-deep-dive-into-micro-frontend-architecture-with-react-js-264ca6edca6b

A Deep Dive into Micro Frontend Architecture with React.js

 

 

 

 

 

MSA를 사용하는 기업들

넷플릭스 (Netflix)

넷플릭스는 원래 모놀리식에서 시작했지만, 트래픽 급증과 기능 복잡성 증가로 인해 마이크로서비스 아키텍처로 전환함.

 

• 각 기능(예: 계정관리, 스트리밍, 추천, 사용자 프로필 등)이 독립적 서비스로 분리됨. 
• 장애 격리 (하나의 서비스 장애가 전체 서비스에 미치는 영향 줄임) 
• AWS 같은 클라우드 인프라를 활용해서 수평 확장 및 로드 밸런싱, 콘텐츠 전송망(CDN) 등을 운용함. 
• “Chaos Monkey”라는 장애 테스트 도구 등을 통해 내결함성(resilience) 확보 노하우 있음.

https://newsletter.systemdesign.one/p/netflix-microservices?utm_source=chatgpt.com

Microservices Lessons From Netflix

https://www.techaheadcorp.com/blog/design-of-microservices-architecture-at-netflix/?utm_source=chatgpt.com

 

 

쿠팡

쿠팡은 2013년에 모놀리식 아키텍처로 구성된 서비스를 마이크로서비스 아키텍쳐(Microservices Architecture, MSA)로 전환하는 프로젝트를 진행하였습니다.

아래 링크는 이러한 전환을 위해 쿠팡이 취한 전략이 무엇이고, 그 과정에서 나타난 문제를 어떻게 풀어나갔는지 소개하는 페이지 입니다.

 

https://medium.com/coupang-engineering/how-coupang-built-a-microservice-architecture-fd584fff7f2b

마이크로서비스 아키텍처로의 전환

 

 

토스

토스 역시 Django 기반 모놀리식 프로젝트 안에서 React를 통한 Micro Frontend를 점진적으로 도입하였다고 합니다. 오래된 코드 베이스를 대대적으로 수정하는 것보다 “필요한 부분만 조금씩 분리”하는 방식으로 접근하였다고 합니다.

아래 링크는 이러한 전환을 위해 토스가 취한 전략이 무엇이고, 그 과정을 소개하는 페이지 입니다.

 

https://toss.im/slash-21/sessions/2-5?utm_source=chatgpt.com

Micro-frontend React, 점진적으로 도입하기

 

 

 

🛠 주요 인사이트 (우리 글에 넣으면 좋은 것들)

• 쿠팡은 모놀리식 → MSA 전환 과정에서 한 리포지토리(monorepo 비슷한 구조)였고, 기능별 컴포넌트들을 같은 저장소 안에서 관리했었다는 점. Medium
• 토스는 Micro Frontend를 도입하면서 전체를 한꺼번에 갈아엎기보다는 점진적인 분리를 택했다는 점. 필요 기능만 골라서 현대화/분리함. 토스
• 조직 구조(팀/사일로)도 아키텍처 영향을 많이 준다는 사례. 기능 책임 팀 ≒ 해당 기능의 프론트 + 백이 같이 움직이면 분리/독립이 더 쉬워짐. 토스 Frontend 챕터 글에서 이런 조직 구조가 보고됨. 토스 테크

 

 

📌 프론트엔드 관점에서 본 아키텍처

아키텍처 이야기는 보통 백엔드 개발자나 인프라 팀의 영역이라고 생각하기 쉽지만, 프론트엔드 개발자에게도 큰 영향을 줍니다. 왜냐하면 서비스를 어떻게 나누고, 어떻게 배포하고, 어떤 방식으로 확장하느냐에 따라 프론트 코드도 달라지기 때문이죠.

1️⃣ API 호출 방식의 변화

• 모놀리식: 하나의 백엔드 서버에서 API를 제공하므로, 프론트에서는 단일 엔드포인트만 호출하면 됐습니다.
• SOA/ MSA: 서비스가 여러 개로 나뉘면서, 프론트는 다양한 엔드포인트를 호출해야 합니다.
  • 인증/인가 처리가 서비스별로 다를 수 있음
  • 서비스 간 장애 발생 시 fallback 로직 필요
    👉 따라서 프론트 개발자는 단순히 fetch를 넘어서 API Gateway, BFF(Backend for Frontend) 같은 개념을 이해해야 효율적으로 개발할 수 있습니다.

2️⃣ 배포 파이프라인의 변화

• 프론트엔드도 CI/CD 환경에서 자동 빌드 & 자동 배포가 기본이 되었습니다.
• 환경(dev/stage/prod)별 설정 분리, API 주소 변경, feature flag 처리 등을 아키텍처 수준에서 고려해야 합니다.
  👉 클라우드 환경에 맞춘 배포 파이프라인을 이해하면, 백엔드/인프라 팀과 협업이 훨씬 수월해집니다.

3️⃣ 성능 최적화 & 장애 대응

• MSA 환경에서는 네트워크 호출이 많아져서 지연(latency)이 커질 수 있습니다.
• 프론트 차원에서 API 호출 최적화, 캐싱 전략, Lazy loading 같은 패턴이 필요합니다.
• 특정 서비스가 장애가 나더라도 전체 화면이 죽지 않도록 fallback UI를 준비하는 것도 중요합니다.

 

 

📌 Micro Frontend 소개 (확장 개념)

MSA가 백엔드를 쪼갠 것처럼, 프론트엔드도 커지다 보면 독립적으로 나눠야 할 필요가 생깁니다.
이를 Micro Frontend라고 부릅니다.

• 필요성
  • 대규모 SPA에서 빌드/배포 시간이 길어지고, 팀 간 충돌이 생길 때
  • 기능별로 독립 배포가 필요할 때
• 장점
  • 팀 단위로 독립 배포 가능 → 특정 기능만 수정/배포 가능
  • 서비스별로 기술 스택을 다르게 가져갈 수도 있음 (예: 일부 React, 일부 Vue)
• 단점
  • 초기 설정 복잡 (라우팅, 공통 라이브러리 관리)
  • UX 통일성을 맞추기 위한 추가 작업 필요

👉 아직은 모든 회사가 쓰는 건 아니지만, 토스, 쿠팡 같은 대규모 서비스에서 점진적으로 도입하고 있습니다.

 

 

 

📌 클라우드 네이티브와의 관계

아키텍처가 진화하면서 클라우드 환경은 사실상 필수 요소가 되었습니다.

• Docker(컨테이너): 서비스별 독립 실행 환경 제공 → MSA 필수
• Kubernetes(오케스트레이션): 수십~수백 개의 마이크로서비스를 자동으로 배포, 확장, 복구 관리
• Serverless: 특정 이벤트(API 요청, 스케줄링)에 맞춰 코드만 실행 → 프론트에서도 Lambda 같은 서비스 자주 활용

💡 정리하자면:
MSA는 클라우드 없이는 운영이 거의 불가능합니다.
그리고 프론트엔드 개발자도 이런 구조를 이해해야 API 호출, 배포 전략, 장애 대응을 더 깊이 이해할 수 있습니다.

 

 

 

 

프론트엔드 개발은 이제 단순히 화면을 예쁘게 그리는 일이 아닙니다.
서비스가 점점 커지고 복잡해질수록, 아키텍처를 이해하는 프론트엔드 개발자가 더 큰 경쟁력을 갖게 됩니다.

 

저 역시 패키지 매니저 공부에서 출발했지만, 모놀리식 → SOA → MSA → Micro Frontend, 그리고 클라우드 네이티브까지 이어지는 흐름을 배우면서 큰 깨달음을 얻었습니다.

 

내가 배우는 개념이 회사 구조랑 맞닿아 있다는 걸 알게 되는 순간, 개발자로서 한 단계 성장한다는 걸 느꼈습니다.
이 글이 독자분들께도 그런 시야를 넓히는 데 도움이 되었으면 좋겠습니다. 🙌

 

 

참고하시면 좋을 영상 첨부해요~
https://www.youtube.com/watch?v=8d4h7K_Fq-0