diff --git a/StuDoc/사업일지-09-광고 0원 헬스 앱의 실험법.html b/StuDoc/사업일지-09-광고 0원 헬스 앱의 실험법.html new file mode 100644 index 0000000..6a6296a --- /dev/null +++ b/StuDoc/사업일지-09-광고 0원 헬스 앱의 실험법.html @@ -0,0 +1,3684 @@ + + + + + + + + + +광고 0원 헬스 앱의 실험법 + + + + + + + + + + + +
+
바이브코딩 케이스 스터디 #9
감 대신 실험으로 +만든 헬스 앱
22살 창업자가 광고비 0원으로 +최근 30일 매출 16만 달러를 낸 방식
출처: AI 사업일지 유튜브(2026.10.14) · Starter Story 「How I Built This $160K/Month Gym App」(2026.09)
+
결론부터
숫자 네 개로 보는 이야기
$160K
최근 30일 매출
iOS·안드로이드 합산, 각종 비용 차감 전
300만
누적 다운로드
출시 약 1년, 스페인어권 중심
~8만
1년간 올린 홍보 영상
유료 광고는 0원
2주
실험 하나의 최소 기간
기능과 화면은 A/B 테스트로 결정
출처: AI 사업일지 영상 설명, Insiderly·Stork.AI 인터뷰 정리 · 숫자는 본인이 인터뷰에서 밝힌 것으로 독립 검증되지 않음
+
레드오션 헬스 앱
운동 기록을 게임처럼 만들었다
창업자 마우로, 22살
헬스장이 삶을 바꿨다
체중 문제를 운동으로 극복. 공동창업자들과 피트니스 유튜브를 하다 앱을 만들었다
근육별 랭크
근육과 운동마다 등급이 붙는다
레벨
기록이 쌓이면 올라간다
연속 기록
빠지지 않고 운동한 날 수
친구 피드
친구의 운동 기록이 올라온다
운동 데이터베이스는 누구나 베낀다. 다시 오게 만드는 장치가 차이를 만든다
출처: AI 사업일지 영상 설명, Insiderly·Stork.AI 인터뷰 정리 · 영상 제목의 ‘대학 중퇴’는 정리 글에서는 확인되지 않음
+
영어 대신 스페인어
같은 앱, 덜 붐비는 언어로
영어권
강자가 넘친다
이미 자리 잡은 운동 기록 앱이 많은 시장
스페인어권
스페인, 멕시코부터
팀이 잘 아는 언어와 문화로 먼저 공략
출시 1년 뒤
스페인 3위
앱스토어 건강·피트니스 무료 부문
우리에게 바꿔 말하면: 한국어 시장, 한국 사용자를 가장 잘 아는 사람은 우리다
출처: AI 사업일지 영상 설명(스페인 3위) · 시장을 고른 구체적 이유는 정리 글에 없어, 첫 두 카드의 설명과 하단 문장은 강의용 해석
+
팬 영상 대신 일반인 영상
팔로워는 출발점일 뿐, 채널이 아니었다
출시 직후
기존 구독자
유튜브 팔로워 덕에 첫 다운로드가 몰렸지만 금방 꺼졌다
시험 1
인플루언서
유명인 홍보를 시험해 봤다
시험 2 · 승자
일반인 영상
평범한 사람이 만든 영상(UGC)이 더 잘 됐다
큰 팔로워는 반복할 수 있는 유입 채널이 아니다
출처: Insiderly 인터뷰 정리 · UGC(User-Generated Content) = 일반 사용자가 만든 콘텐츠
+
일반인 영상 공장
1년에 8만 개, 기능 대신 감정으로
~8만
1년간 올린 영상
500+
운영한 계정
~10억
누적 조회수
~절반
크리에이터 몫의 매출
잘 된 포맷
잠금화면에 이별 문자, 바로 아래 “운동하러 가자” 앱 알림. 기능 설명 없이 감정에 붙인다
운영 방식
포맷과 하위 포맷으로 나눠 성과를 비교. 크리에이터를 싼 노동이 아닌 동업자로 대우
출처: Insiderly 인터뷰 정리(영상 속 본인 발언 기준), AI 사업일지 영상 설명
+
감이 아니라 실험으로
무엇을 만들지 정하는 방식의 3단계
1단계 · “끔찍했다”
우리가 원하는 것
빠르고 재밌지만 시장 검증이 없다
2단계 · “그저 그랬다”
사용자가 요청한 것
요청은 해결책일 뿐, 진짜 문제가 아니다
3단계 · 지금
지표를 움직이는 것
모든 기능은 검증할 가설이다
“다크 모드 넣어 주세요”의 진짜 이유는 눈 피로일 수도, 사생활일 수도, 취향일 수도 있다
출처: Stork.AI·Insiderly 인터뷰 정리 · 단계별 평가(“terrible idea”, “mediocre”)는 마우로 본인의 표현
+
실험 한 번의 구조
문제에서 시작해 기록으로 끝난다
문제 찾기
데이터로 확인
가설·지표
2주 이상 A/B
채택·폐기·기록
성공한 실험
결심 화면 하나 추가
가입 직후 ‘운동하겠다’는 의지를 밝히는 화면 → 리텐션 약 3% 상승
변화 없던 실험
핵심 화면 재설계
운동 계획 화면을 두 번 갈아엎었지만 지표는 그대로. 그곳엔 더 투자 안 한다
실험 장부
Evelyn
문제, 가설, 지표, 기간, 결과, 다음 행동을 모두 기록하는 내부 DB
출처: Insiderly·Stork.AI 인터뷰 정리 · 3%가 상대치인지 %p인지는 정리 글에서 불분명 · 흐름은 8단계 과정을 5단계로 줄인 것
+
도구와 숫자의 신뢰성
질문과 답 사이 거리를 줄이는 도구
도구
쓰임
Claude + MCP
작업을 데이터에 바로 연결해 질문하고 분석
PostHog
사용자 행동 분석과 A/B 테스트
Superwall
결제 화면 실험
Notion · Slack
문서 정리와 팀 소통
Wispr Flow
말로 작업 지시와 글 입력
16만 달러에서 빠지는 것
앱스토어 수수료 + 크리에이터 보상(매출의 절반 가까이) + 운영비. 이익은 공개되지 않았다
출처: Insiderly 인터뷰 정리, AI 사업일지 영상 설명 · 영상은 ‘도구 7개’라고 하나 정리 글에서 확인된 것은 위 목록
+
다음 날 할 일 하나
작게 시작하는 실험 습관 4가지
01
핵심 지표 하나
가입이 아니라 ‘첫 운동 기록’처럼 가치를 느낀 순간을 정한다
02
요청 말고 문제
기능 요청을 받으면 그 뒤의 진짜 이유부터 묻는다
03
기능은 가설로
“이걸 넣으면 X가 Y% 오른다”는 문장으로 쓴다
04
실패도 기록
분석 도구 하나와 실험 장부 하나면 시작할 수 있다
AI는 만드는 속도를 올린다. 무엇을 만들지는 실험이 정한다
출처: Insiderly·Stork.AI 인터뷰 정리의 조언과 AI 사업일지 영상을 강의용 실천 항목으로 정리
+
+ + + diff --git a/StuDoc/사업일지-09-광고 0원 헬스 앱의 실험법.pdf b/StuDoc/사업일지-09-광고 0원 헬스 앱의 실험법.pdf new file mode 100644 index 0000000..9b43006 Binary files /dev/null and b/StuDoc/사업일지-09-광고 0원 헬스 앱의 실험법.pdf differ diff --git a/StuDoc/사업일지-10-그래픽 없는 RPG 하나로.html b/StuDoc/사업일지-10-그래픽 없는 RPG 하나로.html new file mode 100644 index 0000000..129df1a --- /dev/null +++ b/StuDoc/사업일지-10-그래픽 없는 RPG 하나로.html @@ -0,0 +1,3684 @@ + + + + + + + + + +그래픽 없는 RPG 하나로 + + + + + + + + + + + +
+
바이브코딩 케이스 스터디 #10
그래픽 없는 +텍스트 RPG 하나로
4년간 코드를 안 짠 메타 매니저가 퇴근 후 6개월 만에 낸 게임, +월평균 매출 1만 3천 달러
출처: AI 사업일지 유튜브(2026.10.14) · Starter Story 인터뷰(BigGo 요약) · Stork.AI 사례 분석
+
결론부터
숫자 네 개로 보는 이야기
$13K
최근 1년 월평균 매출
최고 월은 약 1만 8천 달러
$150K+
최근 1년 합계
앱스토어 수수료·세금 차감 전
500~600
하루 사용자
대박 게임과는 거리가 먼 규모
×10
글 하나 뒤 월 매출
약 1천 달러에서 1만 달러로
출처: AI 사업일지 영상 설명, Starter Story 인터뷰(BigGo 요약) · 이익은 공개되지 않았으며 수익을 보장하지 않습니다 · 1년 합계는 요약본에 $150K+와 $155K+로 함께 표기
+
주인공
4년 만에 다시 코드를 연 매니저
12년
아마존 → 메타
개발자로 시작해 엔지니어링 매니저로. 코드와는 멀어졌다
2022년
대규모 해고
“아무리 열심히 해도 고용 안정은 보장되지 않는다”
2024년 초
AI 도구로 복귀
연습용 카드 게임을 6주 만에 내며 출시 과정을 익혔다
첫 앱은 돈이 아니라 만들고 내는 법을 배우는 연습이었다
출처: Starter Story 인터뷰(BigGo 요약) · 인용은 강의용 번역
+
잘 아는 분야를 좁게
모두가 아니라 몇백 명의 열성 팬을 위해
누구를 위해
방치형 게임 팬
런스케이프 같은 성장형 게임을 좋아하는 좁은 장르. 켄 자신이 그 팬이었다
무엇을 뺐나
그래픽
3D 모델도 애니메이션도 아트팀도 없다. 글자와 화면 구성만으로 만든다
이미 증명된 장르
멜보 아이들
런스케이프 제작사 Jagex가 퍼블리싱을 맡은 텍스트 방치형 게임
켄의 조언: 내가 이해하는 것을 만들고, 친구나 가족이 아닌 잠재 고객에게 피드백을 받아라
출처: Starter Story 인터뷰(BigGo 요약), Stork.AI 사례 분석, Jagex 공지(영상 설명란 링크) · 멜보 아이들을 ‘증명된 장르’로 연결한 것은 강의용 해석
+
6개월 뒤 무조건 출시
미리 정해 둔 두 개의 규칙
출시 규칙
6개월
준비가 됐든 안 됐든 6개월이 되면 낸다. 2024년 12월 출시
퇴사 규칙
월 $10K
광고 없이 월 1만 달러에 닿으면 그만둔다. 닿은 그 달에 퇴사
“V1, V2, 어쩌면 V5까지 부끄럽지 않다면 충분히 일찍 내지 않은 것이다”
출처: Starter Story 인터뷰(BigGo 요약), AI 사업일지 영상 설명(출시 시점) · 인용은 강의용 번역
+
비판받은 글 하나
욕을 먹었지만, 수천 명이 봤다
STEP 1
방치형 게임 커뮤니티 레딧에 스크린샷과 ‘무료’를 강조한 글
STEP 2
반응은 압도적으로 비판적. 하지만 수천 명의 플레이어 앞에 섰다
STEP 3
거의 하룻밤 사이 월 매출 약 $1K → $10K
이후
홍보는 한 달 한 번 규칙이 많아, 큰 업데이트 때마다 몇 달 간격으로 올린다
비판은 무관심보다 낫다. 다만 커뮤니티 규칙을 지키는 선에서
출처: Starter Story 인터뷰(BigGo 요약), AI 사업일지 영상 설명(2025년 6월 r/incremental_games 게시글) · 하단 문장은 강의용 정리
+
하루 500명, 연 15만 달러
작은 숫자를 깊은 숫자로 읽기
5만+
누적 다운로드 (iOS·안드로이드)
3.5~4천
월간 활성 사용자
500~600
일간 활성 사용자
~6%
결제 전환율 (게임 보통 2~5%)
$3+
활성 사용자 1명당 매출
$0
광고비
많은 사람이 아니라 돈을 내고 오래 머무는 소수가 매출을 만든다. 본인도 “결과가 고르진 않았다”고 말한다
출처: Starter Story 인터뷰(BigGo 요약), AI 사업일지 영상 설명 · 모두 본인이 밝힌 수치
+
돈을 내는 유저
이기려고가 아니라 편하려고 낸다
주로 팔리는 가격대
$4.99~9.99
9.99달러를 넘으면 “결제로 잘 안 넘어온다”
무료 + 선택형 인앱결제
게임은 무료. 프리미엄 기능을 열거나 성장을 빠르게 하는 아이템을 판다
돈으로 이기는 게임이 아니다
편의 기능 중심. 장르 팬이 싫어하는 ‘페이 투 윈’을 피한다
돈보다 잔존이 먼저
초기엔 수익화보다 사람들이 계속 돌아오게 만드는 데 집중했다
출처: Starter Story 인터뷰(BigGo 요약), Stork.AI 사례 분석, AI 사업일지 영상 설명(2~10달러대 인앱결제)
+
사용한 도구와 비용
도구는 적게, 비용은 월 500달러
구분
도구
쓰임
AI 개발
Cursor, ChatGPT
코드 작성, 아이디어 정리, 아이콘 다듬기
앱
React Native
한 코드로 iOS·안드로이드
서버·분석
Firebase, Vercel
백엔드와 분석, 웹 호스팅
그림
Unity 에셋 스토어 등, Fiverr·Upwork
아트 구매, 스크린샷·아이콘·영상 외주
커뮤니티
Discord
팬과 직접 소통
켄: “돈 버는 제품을 만드는 데 엄청나게 많은 도구가 필요하지는 않다”
출처: Starter Story 인터뷰(BigGo 요약) · 월 약 $500은 아트·외주·구독 비용, 본인 시간은 제외
+
우리가 베낄 수 있는 것
작고 깊은 팬층을 만드는 4단계
01
내가 팬인 장르
내가 즐기고 잘 아는 좁은 분야를 고른다
02
비싼 부분을 뺀다
그래픽처럼 혼자 감당 못 할 부분 없이도 재밌는 형태로
03
마감을 먼저 박는다
출시일과 ‘그만둘 숫자’를 시작 전에 정한다
04
팬 커뮤니티에 내민다
비판받을 각오로, 규칙을 지키며 직접 보여 준다
만 명이 스치는 앱보다, 몇백 명이 매일 여는 앱
출처: Starter Story 인터뷰의 켄의 조언, Stork.AI 사례 분석, AI 사업일지 영상을 강의용 실천 항목으로 정리
+
+ + + diff --git a/StuDoc/사업일지-10-그래픽 없는 RPG 하나로.pdf b/StuDoc/사업일지-10-그래픽 없는 RPG 하나로.pdf new file mode 100644 index 0000000..ffb8651 Binary files /dev/null and b/StuDoc/사업일지-10-그래픽 없는 RPG 하나로.pdf differ diff --git a/StuDoc/에이전트시대의_MSA.html b/StuDoc/에이전트시대의_MSA.html new file mode 100644 index 0000000..a32294a --- /dev/null +++ b/StuDoc/에이전트시대의_MSA.html @@ -0,0 +1,492 @@ + +에이전트 시대의 MSA + + +
+

마이크로서비스 아키텍처 · 2026 개정판

에이전트 시대의
마이크로서비스

+

바이브 코딩과 코딩 에이전트로 다시 쓰는 MSA

이즈잇소프트 채문창 · 2022 원본 → 2026 개정

+ + +
+ 1 +
+
+

2022년 이후, 무엇이 바뀌었나

+
2022 원본
+

사람이 코드를 쓴다

  • 서비스 하나 = 개발팀 하나
  • 병목은 구현 속도와 인력
  • MSA는 큰 조직의 전유물
→
+
2026 지금
+

에이전트가 코드를 쓴다

  • 서비스 하나 = 사람 1명 + 에이전트 N
  • 병목은 명세 · 검증 · 운영
  • 1인 개발자도 MSA를 만들 수 있다
+
MSA의 원칙은 그대로, 바뀐 것은 '누가 · 얼마나 빨리' 만드느냐입니다
+
에이전트 시대의 MSA
2 +
+
+

오늘의 순서

2022 원본의 흐름을 유지하고, 각 장을 에이전트 관점으로 개정했습니다

+
01
+

MSA 다시 보기

모놀리스 · 정의 · 장점 재평가

+
02
+

코딩 에이전트

바이브 코딩과 에이전트의 원리

+
03
+

에이전트로 설계

경계 찾기 · 계약 우선

+
04
+

에이전트로 구현

구현요소 6가지 개정

+
05
+

문제점과 해결책

원본 8가지 + 새 함정

+
06
+

팀 운영

사람 1 + 에이전트 N

+
07
+

실습

주문 시스템 3개 서비스

+
08
+

정리 · 과제

2022 → 2026 한 장 요약

+
에이전트 시대의 MSA
3 +
+
+
01

MSA 다시 보기

변하지 않은 원칙과 달라진 비용

+ 4 +
+
+

모놀리스 vs MSA — 그리고 서비스마다 에이전트

원본의 사용자 · 상품 · 주문 예제를 그대로 가져왔습니다

+
모놀리스 +
UX · 프론트엔드
사용자
상품
주문
+
공유 데이터베이스 1개
+
MSA에이전트
+
API
Gateway
➜
사용자 서비스
사용자 DB
➜
상품 서비스
상품 DB
➜
주문 서비스
주문 DB
+
서비스 경계 = 데이터 소유 경계 = 에이전트 한 세션이 맡는 작업 범위
+
에이전트 시대의 MSA
5 +
+
+

MSA 정의 — 2022 원문과 2026 보완

원칙은 한 줄도 버리지 않았습니다. 에이전트 시대에 맞는 해석만 덧붙였습니다

+ +
원칙2022 원문2026 보완
작은 서비스작은 서비스의 결합으로 하나의 앱에이전트 한 세션이 통째로 이해할 크기
독립 배포완전 자동화된 개발 · 배포에이전트 PR을 CI가 자동 검증 후 배포
중앙 관리 최소최소한의 중앙 관리 체계중앙엔 계약(API 스키마)과 규칙 파일만
폴리글랏멀티 언어 · 멀티 저장소언어 장벽은 낮아짐, 리뷰 · 운영 부담은 그대로
독립 데이터서비스별 데이터 저장소변하지 않음 — 가장 중요한 원칙
+
에이전트 시대의 MSA
6 +
+
+

MSA 장점, 에이전트 시대에 다시 매기기

원본 8쪽의 장점 목록을 세 가지로 다시 분류했습니다

+
강화

더 강해진 장점

작은 코드베이스 = 에이전트 정확도 상승.
서비스별로 에이전트를 병렬로 돌려 개발 속도가 배로 늘어남.

+
+
불변

그대로인 비용

네트워크 호출 지연, 분산 데이터 정합성, 배포 · 모니터링 대상 증가.
에이전트가 줄여주지 않음.

+
+
주의

새로 생긴 위험

만들기가 너무 쉬워 서비스를 남발.
10분 만에 '분산 모놀리스'가 완성될 수 있음.

+
+
에이전트 시대의 MSA
7 +
+
+

그래서 처음부터 MSA? — 모놀리스 먼저

에이전트 덕분에 리팩터링 비용이 낮아져 '나중에 쪼개기'가 쉬워졌습니다

+

모듈러 모놀리스

한 저장소 · 한 배포, 폴더로 도메인 분리

➜
+

경계 검증

모듈 간 호출은 공개 인터페이스로만

➜
+

분리 신호 감지

부하 · 배포 주기 · 팀이 달라지는 모듈

➜
+

필요한 것만 분리

에이전트가 모듈을 서비스로 추출

1인 창업 · 초기 서비스는 모듈러 모놀리스로 충분한 경우가 대부분입니다 (Martin Fowler, MonolithFirst)
+
에이전트 시대의 MSA
8 +
+
+

SoA · ESB에서 에이전트 인터페이스까지

원본 10~11쪽의 역사에 한 칸을 더했습니다

+

SOA · ESB

2000년대, 중앙 버스와 분산 트랜잭션 — 무거움

➜
+

API Gateway

2010년대 MSA, 입구 하나 · 서비스는 독립

➜
+

서비스 메시

쿠버네티스 위 사이드카로 통신 · 보안 · 관측

➜
+

MCP 인터페이스

사람뿐 아니라 AI 에이전트가 서비스를 호출

교훈은 같습니다: 똑똑한 중앙(ESB)이 아니라 '똑똑한 끝점, 단순한 파이프'
+
에이전트 시대의 MSA
9 +
+
+
02

코딩 에이전트 이해

노드 안을 들여다보면 단순한 반복 루프

+ 10 +
+
+

바이브 코딩 vs 에이전트 기반 엔지니어링

+
바이브 코딩
+

말로 만들고 결과만 본다

  • 자연어로 요청, 실행되면 수락
  • 코드를 다 읽지 않아도 된다
  • 프로토타입 · 1회성 도구에 강함
vs
+
에이전트 엔지니어링
+

명세와 테스트로 지휘한다

  • 계약 · 테스트 · 규칙 파일로 지시
  • 변경 내용(diff)을 사람이 리뷰
  • 운영되는 서비스에 필수
+
MSA를 느낌으로 만들면 분산 모놀리스가 됩니다 — 프로토타입은 바이브로, 서비스는 엔지니어링으로
+
에이전트 시대의 MSA
11 +
+
+

코딩 에이전트 노드 안 들여다보기

에이전트 = LLM + 도구(파일 · 셸 · git) + 끝날 때까지 도는 반복 루프

+

규칙 읽기

요청 + AGENTS.md · 명세

➜
+

코드 탐색

관련 파일을 찾아 읽음

➜
+

계획

수정할 파일과 순서 결정

➜
+

수정 · 실행

코드 변경, 테스트 실행

➜
+

검증 · 반복

실패하면 원인 분석 후 재시도

그래서 테스트가 없으면 에이전트는 '성공'을 판단할 근거가 없습니다 — 테스트가 곧 지시서
+
에이전트 시대의 MSA
12 +
+
+

도구 지형 한눈에

도구 이름은 계속 바뀝니다. 유형으로 기억하세요

+

터미널 에이전트

수업 실습

claude · codex · agy — 저장소에서 직접 읽고, 실행하고, 고침

+
+

IDE 에이전트

편집기

에디터 안에서 자동완성 · 대화 · 다중 파일 편집

+
+

원격 에이전트

비동기

이슈를 맡기면 클라우드에서 작업 후 PR로 돌려줌

+
+

확장 표준

연결

MCP(도구 연결), AGENTS.md · 스킬(규칙과 절차)

+
+
에이전트 시대의 MSA
13 +
+
+

컨텍스트 엔지니어링 — 규칙 파일 배치

    +

  • 루트 AGENTS.md

    전 서비스 공통 규칙 · 금지사항

    • +

  • 서비스별 AGENTS.md

    도메인 · 계약 위치 · 실행 명령

    • +

  • contracts/ 폴더

    OpenAPI · 이벤트 스키마 = 단일 진실

    • +

  • docs/adr/

    결정 이유를 남겨 에이전트도 따름

+ 
shop/
+├─ AGENTS.md            # common rules
+├─ CLAUDE.md            # -> see AGENTS.md
+├─ contracts/
+│  ├─ user.openapi.yaml
+│  ├─ order.openapi.yaml
+│  └─ events.asyncapi.yaml
+├─ docs/adr/0001-db-per-service.md
+└─ services/
+   ├─ user/   AGENTS.md  app/  tests/
+   ├─ product/AGENTS.md  app/  tests/
+   └─ order/  AGENTS.md  app/  tests/
에이전트는 매 세션 기억이 없습니다 — 규칙 파일이 곧 에이전트의 장기 기억입니다
+
에이전트 시대의 MSA
14 +
+
+
03

에이전트와 함께 설계하기

설계는 사람이 결정하고, 에이전트는 초안과 검토를 돕는다

+ 15 +
+
+

서비스 경계 찾기 — 에이전트와 이벤트 스토밍

BOUNDED CONTEXT + 원본 20쪽 개정

같은 '고객'도 영업팀 · 배송팀 · 회계팀이 보는 모습이 다르다

    +
  1. 1

    도메인 이야기 수집

    요구사항 · 인터뷰 메모를 에이전트에게 제공

    2. +
  2. 2

    도메인 이벤트 뽑기

    '주문됨', '결제됨', '재고 부족' 같은 과거형 사건 목록 초안

    3. +
  3. 3

    컨텍스트 맵 초안

    이벤트를 묶어 후보 서비스와 소유 데이터를 제안받음

    4. +
  4. 4

    사람이 결정 · ADR 기록

    경계는 비즈니스 판단 — 결정 이유를 docs/adr 에 남김

+
에이전트 시대의 MSA
16 +
+
+

프롬프트 예시 — 경계 초안 받기

    +

  • 역할과 산출물 형식 지정

    표 · 목록 등 검토하기 쉬운 형태로

    • +

  • 결정은 요청하지 않기

    후보와 장단점만, 선택은 사람이

    • +

  • 반대 의견도 요청

    '모놀리스로 충분한가?'를 꼭 묻기

    • +

  • 결과는 ADR 초안으로

    합의한 내용만 저장소에 커밋

+ 
너는 DDD에 익숙한 아키텍트야.
+docs/requirements.md 를 읽고 다음을 만들어 줘.
+
+1. 도메인 이벤트 목록 (과거형, 발생 주체 포함)
+2. 이벤트를 묶은 바운디드 컨텍스트 후보 2~3안
+3. 각 안의 서비스별 소유 데이터와 동기/비동기 호출
+4. 각 안의 장단점, 그리고
+   '모듈러 모놀리스로 충분한 이유'가 있다면 그것도
+
+코드는 아직 작성하지 마. 표로 정리해.
설계 단계에서 코드 생성을 막아야 에이전트가 '빨리 만들기'로 넘어가지 않습니다
+
에이전트 시대의 MSA
17 +
+
+

계약 우선 — 인터페이스 불일치의 해법

원본 23쪽 문제의 답 — 계약은 사람이 승인하고, 구현은 에이전트가 맡는다

+

명세 작성

OpenAPI · AsyncAPI 초안

➜
+

사람이 승인

필드 · 오류 코드 · 버전 규칙 확정

➜
+

코드 생성

에이전트가 서버 스텁 · 클라이언트 생성

➜
+

계약 테스트

CI에서 계약 위반 시 머지 차단

➜
+

구현 · 배포

서비스별로 독립 진행

규칙: 계약 파일 변경은 반드시 별도 PR + 사람 리뷰. 에이전트가 계약을 '맞춰서' 고치지 못하게
+
에이전트 시대의 MSA
18 +
+
+
04

에이전트로 구현하기

원본 12~18쪽 구현요소 6가지의 2026 개정

+ 19 +
+
+

구현요소 6가지, 2026 실무 선택

왼쪽은 원본 그대로, 오른쪽 두 칸이 개정 내용입니다

+ +
2022 구현요소2026 실무 선택에이전트 활용 포인트
데이터 분산관리서비스별 DB, Outbox, Saga스키마 · 마이그레이션 · Saga 테스트 작성
RESTful / 비동기REST · gRPC + Kafka · NATS · Redis Streams계약에서 클라이언트 · 컨슈머 생성
폴리글랏Python · Go · TypeScript 중 선택언어 장벽 ↓ — 단, 리뷰 가능한 언어로 제한
DevOpsGitOps, CI가 에이전트 PR 검증Dockerfile · 파이프라인 초안 작성
클라우드컨테이너 + k8s / k3s (온프레미스 포함)매니페스트 생성, 리소스 설정 점검
Design for Failure타임아웃 · 재시도 · 서킷브레이커 · 멱등성장애 주입 테스트, 트레이스 분석
+
에이전트 시대의 MSA
20 +
+
+

데이터 분산관리 — 분산 트랜잭션 대신 Saga

원본 13쪽 'Not 분산 트랜잭션'을 구현하는 표준 패턴

+

주문 생성

주문 서비스: 상태 PENDING, 이벤트 발행

➜
+

재고 예약

상품 서비스: 재고 차감, '예약됨' 발행

➜
+

결제

결제 실패 시 '결제 실패' 이벤트 발행

➜
+

보상 트랜잭션

재고 복원 → 주문 CANCELLED

Outbox 패턴: DB 저장과 이벤트 발행을 한 트랜잭션에 묶어 '저장됐는데 이벤트 유실'을 막음
+
에이전트 시대의 MSA
21 +
+
+

비동기 이벤트 — 주문 서비스 예시

    +

  • FastAPI + Redis Streams

    실습 환경에서 가장 가벼운 조합

    • +

  • 이벤트 이름은 과거형

    order.created, stock.reserved

    • +

  • 멱등성 키 필수

    같은 이벤트가 두 번 와도 한 번만 처리

    • +

  • 스키마는 contracts/

    에이전트는 계약을 읽고 구현

+ 
# services/order/app/main.py
+import json, uuid, redis
+from fastapi import FastAPI, Header
+
+app = FastAPI()
+r = redis.Redis(host="redis")
+
+@app.post("/orders")
+def create(body: dict,
+           key: str = Header(alias="Idempotency-Key")):
+    if not r.set(f"idem:{key}", 1, nx=True, ex=86400):
+        return {"status": "duplicate"}
+    oid = str(uuid.uuid4())
+    # save PENDING order + outbox row
+    evt = json.dumps({"id": oid, **body})
+    r.xadd("order.created", {"data": evt})
+    return {"id": oid, "status": "PENDING"}
이 코드도 에이전트가 계약 파일을 읽고 생성한 초안 — 사람은 멱등성 · 오류 처리를 리뷰합니다
+
에이전트 시대의 MSA
22 +
+
+

서비스마다 에이전트 — git worktree 병렬 개발

    +

  • 서비스별 작업 폴더 분리

    에이전트끼리 파일 충돌 없음

    • +

  • tmux 창 하나에 에이전트 하나

    1일차에 구축한 환경 그대로

    • +

  • 각자 브랜치 → PR

    lazygit 으로 diff 리뷰 후 머지

    • +

  • 계약은 main 에서만 변경

    worktree 에서 계약 수정 금지

+ 
# one worktree per service
+$ git worktree add ../shop-user    -b feat/user
+$ git worktree add ../shop-product -b feat/product
+$ git worktree add ../shop-order   -b feat/order
+
+# tmux: 3 panes, 3 agents
+$ tmux new -s msa
+  pane 1) cd ../shop-user    && claude
+  pane 2) cd ../shop-product && codex
+  pane 3) cd ../shop-order   && claude
+
+# review & merge
+$ lazygit
사람의 역할은 '동시에 세 명의 개발자에게 일을 나눠 주고 리뷰하는 팀장'입니다
+
에이전트 시대의 MSA
23 +
+
+

Design for Failure + 관측성

원본 18쪽 — 실패를 전제로 설계하고, 실패를 '보이게' 만든다

+

타임아웃 · 재시도

기본

모든 외부 호출에 타임아웃, 재시도는 지수 백오프로

+
+

서킷 브레이커

차단

계속 실패하는 서비스는 잠시 끊어 장애 전파를 막음

+
+

멱등성

중복 방지

재시도와 중복 이벤트에도 결과가 한 번만 반영되게

+
+

OpenTelemetry

추적

요청 하나의 전 구간 트레이스 — 에이전트에게 보여주면 원인을 함께 찾음

+
+
에이전트 시대의 MSA
24 +
+
+

서비스를 에이전트에게 열기 — MCP

API Gateway가 사람용 입구라면, MCP 서버는 AI 에이전트용 입구입니다

+

AI 에이전트

'어제 취소된 주문 보여줘'

➜
+

MCP 서버

도구: get_orders, get_stock (읽기 전용부터)

➜
+

API Gateway

인증 · 권한 · 호출량 제한

➜
+

주문 · 상품 서비스

기존 API 그대로 응답

쓰기 도구(주문 취소 · 환불)는 사람 승인 단계를 둡니다 — 원본의 '최소 권한' 원칙 그대로
+
에이전트 시대의 MSA
25 +
+
+
05

문제점과 해결책 2026

원본 19~27쪽 8가지 문제의 개정판

+ 26 +
+
+

문제점과 해결책 ① 설계 · 운영

2022년 해결책은 여전히 유효합니다. 에이전트가 실행 비용을 낮춰 줄 뿐입니다

+ +
문제2022 해결책2026 에이전트 활용
서비스 범위 설정Bounded Context, DDD에이전트와 이벤트 스토밍, 결정은 사람이
레거시와 공존SoA 연동, API G/W스트랭글러 피그: 기능 단위 이전 + 회귀 테스트
운영 오버헤드DevOps 배포 자동화서비스 템플릿 + 에이전트가 CI/CD · IaC 생성
인터페이스 불일치팀 간 커뮤니케이션계약 우선 + CI에서 계약 테스트 강제
+
에이전트 시대의 MSA
27 +
+
+

문제점과 해결책 ② 코드 · 데이터 · 테스트

에이전트가 가장 크게 도움이 되는 영역은 '테스트 작성'입니다

+ +
문제2022 해결책2026 에이전트 활용
코드 중복단일 언어 · 프레임워크공통 템플릿 · 스킬로 '같은 방식'의 중복 관리
데이터 중복전체 시스템 관점 고려소유 서비스 명시, 이벤트 · CDC로 동기화
분산 복잡성Actor Model, Reactive이벤트 기반 + 분산 트레이싱을 에이전트가 분석
테스트의 어려움(상호 테스트 어려움)계약 · 통합 테스트를 에이전트가 작성, 시나리오는 사람이
+
에이전트 시대의 MSA
28 +
+
+

새로 생긴 문제 — 바이브 코딩의 함정

2022년에는 없던 위험입니다. 모두 실제로 자주 일어납니다

+

분산 모놀리스 양산

서비스는 많은데 동기 호출로 줄줄이 묶임 → 경계부터 재검토

+

존재하지 않는 API · 패키지

에이전트가 지어낸 이름 → 잠금 파일 · 의존성 검사 필수

+

비밀키 유출

코드 · 로그에 토큰 하드코딩 → 시크릿 스캔을 CI에

+

테스트를 고쳐서 통과

구현 대신 테스트를 수정 → 테스트 파일 변경은 별도 리뷰

+

서비스마다 다른 규칙

세션마다 스타일이 표류 → 공통 AGENTS.md · 린터로 고정

+

리뷰 병목

생성 속도 > 리뷰 속도 → 작은 PR, 자동 검사 먼저

+
에이전트 시대의 MSA
29 +
+
+
06

개발 팀 운영

원본 28~32쪽 — 팀의 정의가 바뀌었다

+ 30 +
+
+

팀 구성의 변화

+
2022 팀
+

사람 5~9명이 한 서비스

  • 피자 두 판 규모의 팀
  • 기획 · 개발 · 테스트 · 운영 분업
  • 사람 수가 곧 개발 속도
→
+
2026 팀
+

사람 1 + 에이전트 N

  • 사람은 설계 · 리뷰 · 운영 책임
  • 에이전트는 구현 · 테스트 · 문서
  • 리뷰 역량이 곧 개발 속도
+
책임은 위임할 수 없습니다 — 에이전트가 쓴 코드도 머지한 사람의 코드입니다
+
에이전트 시대의 MSA
31 +
+
+

원본 팀 운영 원칙 4가지, 2026 버전

지식노동자를 위한 원칙은 에이전트를 다루는 사람에게도 그대로 적용됩니다

+

최적화된 팀 규모

29쪽

작은 팀 → 사람 1~2명이 서비스 하나와 에이전트들을 소유

+
+

독립적인 팀 운영

30쪽

서비스별 AGENTS.md로 자율, 공통 가드레일로 일관성

+
+

아키텍처 선택 자율

31쪽

선택은 자유, 단 ADR로 이유를 남겨 에이전트도 따르게

+
+

상향식 개발

32쪽

명세 주도(spec-driven) + 작은 반복, 큰 계획 일괄 생성 금지

+
+
에이전트 시대의 MSA
32 +
+
+

에이전트 가드레일 — 맡기기 전에 정할 것

권한은 작게 시작해서 신뢰가 쌓이면 넓힙니다

+

샌드박스 · 허용 명령

작업 폴더 밖 접근 금지, 위험 명령은 승인 후 실행

+

main 직접 push 금지

모든 변경은 브랜치 → PR → CI → 사람 리뷰

+

비밀은 환경변수로

.env 는 git 제외, 운영 키는 에이전트에게 주지 않음

+

사람 승인 작업

DB 마이그레이션 · 배포 · 데이터 삭제 · 계약 변경

+

비용 한도

API 사용량 · 실행 시간 상한, 무한 루프 방지

+

기록 남기기

에이전트 세션 로그 · PR 설명에 근거를 남김

+
에이전트 시대의 MSA
33 +
+
+
07

실습: 주문 시스템 MSA

사용자 · 상품 · 주문을 에이전트 3개로

+ 34 +
+
+

실습 아키텍처

docker compose 하나로 로컬에서 전부 실행합니다

+

게이트웨이

프록시 · 인증 헤더 검사

➜
+

사용자

user 서비스
회원 · 로그인
users.db

➜
+

상품

product 서비스
상품 · 재고
products.db

➜
+

주문

order 서비스
주문 · Saga
orders.db

➜
+

이벤트 버스

Redis Streams
서비스 간 이벤트 전달

서비스마다 자기 DB(SQLite)를 가지며, 다른 서비스 DB에 직접 접근하면 실습 감점
+
에이전트 시대의 MSA
35 +
+
+

실습 진행 순서

LAB + 진행 방식

1인 팀장이 에이전트 개발자 세 명을 지휘하는 하루

    +
  1. 1

    명세 · 계약 확정 (사람, 40분)

    요구사항 → 이벤트 스토밍 → contracts/ 와 루트 AGENTS.md 작성

    2. +
  2. 2

    병렬 구현 (에이전트, 60분)

    worktree 3개 + tmux, 서비스별 에이전트에게 계약 기반 구현 지시

    3. +
  3. 3

    통합 · 계약 테스트 (40분)

    docker compose up, 주문 → 재고 예약 → 완료 흐름 확인

    4. +
  4. 4

    장애 주입 (20분)

    product 서비스를 멈추고 주문이 보상 처리되는지 확인

+
에이전트 시대의 MSA
36 +
+
+

서비스 에이전트에게 주는 첫 지시

    +

  • 읽을 파일을 명시

    AGENTS.md · 계약 · 요구사항

    • +

  • 테스트 먼저

    실패하는 테스트 → 구현 순서

    • +

  • 범위 제한

    자기 서비스 폴더만 수정

    • +

  • 완료 조건 명시

    pytest 통과 + 실행 방법 보고

+ 
services/order/AGENTS.md 와 contracts/order.openapi.yaml,
+contracts/events.asyncapi.yaml 을 먼저 읽어.
+
+1. 계약의 모든 엔드포인트에 대한 pytest 를 먼저 작성해.
+   재고 부족 · 결제 실패 · 중복 요청 시나리오를 포함해.
+2. 테스트가 실패하는 것을 확인한 뒤 구현해.
+3. services/order/ 밖의 파일과 contracts/ 는 수정하지 마.
+   계약이 이상하면 수정하지 말고 나에게 보고해.
+4. 끝나면 pytest 결과와 실행 방법을 요약해 줘.
좋은 지시 = 읽을 것 + 순서 + 금지 범위 + 완료 조건
+
에이전트 시대의 MSA
37 +
+
+

2022 → 2026 한 장 요약

왼쪽은 원본의 개념, 아래는 2026년의 실천 방법

+

모놀리스 vs MSA

모듈러 모놀리스 먼저

+

서비스 경계

에이전트와 이벤트 스토밍

+

인터페이스

계약 우선 + 계약 테스트

+

분산 데이터

Saga + Outbox

+

DevOps

CI가 에이전트 PR 검증

+

장애 대비

재시도 · 멱등성 · 추적

+

작은 팀

사람 1 + 에이전트 N

+

팀의 지식

AGENTS.md · ADR

+
에이전트 시대의 MSA
38 +
+
+

참고 자료

원본 참고자료에 2026년 기준 자료를 추가했습니다

+ +
자료주소
Martin Fowler — Microservicesmartinfowler.com/articles/microservices.html
Martin Fowler — MonolithFirstmartinfowler.com/bliki/MonolithFirst.html
Chris Richardson — Saga · Outbox 패턴microservices.io
AGENTS.md — 에이전트 규칙 파일agents.md
Model Context Protocol (MCP)modelcontextprotocol.io
OpenTelemetry — 분산 추적opentelemetry.io
(원본 참고) 조대협의 블로그bcho.tistory.com/948
+
에이전트 시대의 MSA
39 +
+
+

과제와 Q&A

실습한 주문 시스템을 저장소에 올리고, 아래 세 가지를 제출하세요

+
  • contracts/ · 루트와 서비스별 AGENTS.md · ADR 1건 이상
  • 장애 주입 결과: product 중지 시 주문이 CANCELLED 되는 로그 또는 트레이스
  • 회고 한 단락: 에이전트에게 맡긴 일과 내가 직접 결정한 일의 구분
+ 40 +
+
+
+ \ No newline at end of file diff --git a/StuDoc/에이전트시대의_MSA.pdf b/StuDoc/에이전트시대의_MSA.pdf new file mode 100644 index 0000000..e924633 Binary files /dev/null and b/StuDoc/에이전트시대의_MSA.pdf differ