| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 |
- 혼공컴운
- 포케맛집
- 기술부채
- 호치민 맛집
- 혼공네트
- Redis
- 연어포케
- 니코호텔
- 합정맛집
- cs
- 호치민
- 합정 맛집
- 혼공학습단12기
- 무이네 사막투어
- 합정포케
- 밤리단길 맛집
- 자료구조
- 핑크성당
- 혼공학습단
- 혼공컴운11기
- 호치민 여행
- 한빛미디어
- Docker
- 베트남여행
- 호치민여행
- OS
- 호치민 무이네
- 무이네투어
- 회고
- 양꼬치
- Today
- Total
경험은 나의 것
더이상 MSA를 공부할 필요가 없는 이유 본문
1. 들어가며
MSA를 공부할 필요가 없다는 게 아니라.. 모놀리식의 이점을 말해드리고 싶었습니다.
AI Driven Development가 대세잖아요. 이제는 단순한 AI 어시스턴트 수준을 넘어서, PRD와 기획서를 잘 만들어서 넘겨주면 스스로 계획을 세우고 실행까지 마치는 AI 에이전트의 시대입니다. 심지어 PRD도 같이 만드는데요..
단순히 시키는 코드만 짜주는 게 아니라, 복잡한 목표를 스스로 하위 작업으로 쪼개고 필요한 도구를 골라가며 결과를 만들어내는 얘네들이 개발을 진짜 기가 막히게 하거든요.
물론 MSA는 여전히 중요하다고도 얘기할 수 있을 것 같습니다. 특히 대규모 조직에서는 더욱더요. 백엔드 개발자라면 분산 시스템의 원리를 알아야 합니다.
왜 이렇게 되었는지를 따라오다 보면 분산 시스템의 원리를 찾을 수 있습니다. 등장한 배경을 알게 된다면 '왜 이렇게 할까'라는 의문에 답할 수 있겠습니다.
2. MSA는 왜 등장했는가
MSA는 기술적인 문제점보다 조직, 인간의 한계 때문이었습니다.
서비스가 너무 커지면 개발자 한 명이 이해할 수 있는 코드의 양은 한계가 있어 전체 코드를 이해할 수 없었습니다. 그래서 이해 가능한 단위로 쪼갭니다.
또한 콘웨이의 법칙으로 하나의 코드베이스를 건드리면 커뮤니케이션 비용이 폭증합니다. 그래서 팀 단위로 서비스를 나눕니다.
또한 수많은 개발자가 다양한 기능을 개발하는데, 배포 일정?, QA? 산 넘어 산입니다.
그래서 얻은 게 코드의 복잡성을 대폭 줄일 수 있었다는 겁니다.
하지만 은탄환은 없다는 말처럼 복잡성을 줄이는 대신, 운영과 네트워크의 복잡성을 가지고 왔습니다.
복잡한 트랜잭션 관리, 분산 추적, 보상 트랜잭션, 네트워크 레이턴시 등.. 다양한 사이드 이펙트를 불러왔습니다.
3. 주체가 바뀌었습니다 (사람 -> AI)
그런데 이제 코드를 짜고 읽는 주체가 인간에서 AI로 넘어가고 있기 때문입니다.
AI는 하나의 Repo에서 분석을 하는 걸 잘하지, 쪼개진 10개의 Repo의 dependency를 고려하며 개발을 맡겨도 하나의 Repo에서 개발을 하는 것보다 나은 성과를 내지 못합니다. (이건 제가 못하는 것일 수도 있습니다만..)
인간이 읽을 수 없고 이해할 수 없는 엄청난 Context를 AI는 읽습니다. 이게 가장 다른 점입니다.
예를 들어 MSA 환경에서 주문 로직을 고친다고 합시다.Order Service, Payment Service, Delivery Service, WMS 등등 다양한 Repository를 뒤져야 합니다. API 명세가 달라지면 오류를 뱉겠죠?
이게 Monolithic으로 되어있다고 칩시다. 프로젝트 /init 때립니다. 다 읽어요. 끝. 그냥 끝입니다.
MSA에서는 서비스 간 통신을 위해 REST API, gRPC와 서킷 브레이커, 증분 재시도 등 다양한 방법을 씁니다. 분산 트랜잭션을 일치시키려고 다양한 패턴을 도입합니다. 이러한 모든 건 네트워크를 지나가기 때문에 발생하는 일입니다.
물론 외부 API 요청 및 연계에는 방도가 없겠지만. 내부에서는 통일시키자 이겁니다.
4. 미래의 아키텍처
미래의 아키텍처는 사람이 관리하기 편한 구조가 아니라 AI가 읽기 쉽게, 즉 학습하기 쉽고 생성하기 편한 구조로 돌아간다? 진화할 수 있을지도 모릅니다.
그래서 다시 관리하기 어렵게 돌려라?? 이건 또 아닙니다.
AI가 관리하는 모놀리식은 다릅니다.
실시간 리팩토링, 테스트 커버리지 자동화, 린트 에러. 이 정도는 이제 이렇게만 쓰면 이제 뒤처지는 것 같습니다.
하나의 큰 덩어리에 내부 구조는 완벽하게 모듈화된 형태 (Modular Monolith)로 프로젝트를 배포하는 게 쉬워질 것 같습니다.
5. 결론: MSA 공부보다는...
MSA의 이점이 많기 때문에 사라지지는 않을 거라 생각합니다. 결국 서비스는 사람이 사용하는 것이기 때문이죠. (이것도 언제 바뀔지 모릅니다.)
AI가 잘 이해할 수 있는 구조를 설계하고, 전체 Context를 입력하는 능력, 즉 설계와 기획, 프롬프트 엔지니어라고 하나요? 이게 중요해질 것이라고 생각합니다.
당장 yml 설정 파일을 가지고 고민하는 것보다.. 어떻게 AI를 잘 써먹을까 생각하는 게 뒤처지지 않는 방법이라고 생각합니다.
쪼만한 개발자의 지극히 개인적인 생각입니다. 읽어주셔서 감사합니다.
What is Conway's Law?
What an organization ships externally is a reflection of how it communicates internally. See how this museum puts Conway's Law to the test.
www.atlassian.com
AI Agents vs. AI Assistants | IBM
Explore the differences, similarities, benefits and risks of AI assistants and AI agents.
www.ibm.com
AI 주도 개발 라이프사이클: 소프트웨어 엔지니어링의 재구상 | Amazon Web Services
본 게시글은 AWS DevOps & Developer Productivity Blog에 게시된 AI-Driven Development Life Cycle: Reimagining Software Engineering by Raja SP을 한국어 번역 및 편집하였습니다. 비즈니스 및 기술 리더들은 생산성 향상, 속
aws.amazon.com
'Dev' 카테고리의 다른 글
| Git Push HTTP 400 에러 해결: "unexpected disconnect while reading sideband packet" (0) | 2026.01.03 |
|---|---|
| [Spring] Spring PSA의 편리함과 세션 동시성 문제 (0) | 2026.01.02 |
| 2025년 회고: 정면으로 마주하기 (0) | 2025.12.30 |
| [Spring] Filter의 요청 가로채기 (0) | 2025.12.28 |
| [Spring] Redis의 세션 Store 휩쓸기 (0) | 2025.12.26 |