d02 - 14. 과정 리뷰와 확정 전략

14교시 · 과정 리뷰 및 확장 전략

2일차 16:00–17:00 · 이론/토론 선행: 1~13교시 전체

---

🎯 학습 목표

• 2일간 만든 시스템의 전체 흐름을 한눈에 다시 정리한다.
• "손으로 마스터(1~11교시) → AI로 가속·확장(12~13교시)" 라는 학습 설계가 무엇을 해결했는지 회고한다.
• 이 방식을 다른 도메인·현업·교육으로 확장하는 전략을 세운다.

---

📖 0. 이 과정의 두 단계

단계	교시	방식	목적
1단계 — 마스터	1~11교시	손으로 직접 구현	클린 아키텍처·TDD를 몸에 익혀 "판단할 수 있는 사람"이 된다
2단계 — 가속	12~13교시	바이브 코딩으로 재현·확장	craft를 갖춘 위에서 Copilot으로 속도를 끌어올린다

핵심 메시지: AI는 craft를 대체하지 않고 가속한다. 손으로 만들 줄 아는 사람만이 AI의 결과가 맞는지 판단하고 안전하게 위임할 수 있습니다. 그래서 순서가 중요했습니다 — 먼저 원리를, 그다음 도구를.

---

📖 1. 전체 흐름 되짚기

우리가 만든 것을 데이터 흐름(값이 가는 방향)으로 다시 봅니다.

[CSV 업로드]                                  ← app.py (조립 루트, 10교시)
     │
     ▼  파일 경로
[CsvSalesRepository]    어댑터(6교시)           지저분한 데이터 → 깨끗한 도메인 객체
     │
     ▼  list[SalesRecord]
[AnalyzeSalesUseCase]   유스케이스(7교시)        숫자 계산(순수 파이썬)
     │
     ▼  AnalysisResult
[GenerateReportUseCase] 유스케이스(9교시)       아래 둘을 호출해 조립
     ├─▶ [MatplotlibChartRenderer]  어댑터(8교시)  차트 이미지
     └─▶ [OpenAiInsightGateway]     어댑터(9교시)  AI 자연어 해석
     │
     ▼  Report + report.md
[다운로드 / 화면 표시]                          ← app.py (10교시)

 

계층별로 정리한 표입니다.

계층(표준 용어/폴더)	우리가 만든 것	외부 의존	테스트 방식
Entities / domain	SalesRecord, AnalysisResult, Report	없음	값 직접 단위 테스트
Use Cases / usecases	Analyze·GenerateReport, ports	포트(추상)만	Fake 주입
Interface Adapters / adapters	CSV·Chart·LLM	pandas/matplotlib/openai	tmp_path·Fake
Frameworks & Drivers / infra+app.py	app.py, openai_client	streamlit/openai	수동 + 통합 테스트

 

🔍 관찰 포인트 — 이 표 한 장이 클린 아키텍처의 실익을 요약합니다. 숫자가 흐르는 안쪽(domain·usecases)은 외부 의존 없이 테스트했고, 도구를 쓰는 바깥(adapters·infra)은 Fake로 격리했습니다. 그래서 "AI 모델 교체", "화면 프레임워크 교체", "데이터 출처 변경"이 모두 바깥 한 부분만 바꾸는 일이 되었습니다.

---

📖 2. TDD 회고 — 무엇이 좋았나

함께 이야기해 봅니다.

• Red→Green→Refactor를 1~11교시 내내 손으로 돌리며, "테스트가 곧 명세"라는 감각을 얻었는가?
• 12·13교시에서 Copilot이 만든 코드를 테스트로 검증했기에 안심하고 받아들일 수 있었는가? 손으로 먼저 익혔기에 틀린 부분을 짚어낼 수 있었는가?
• 가장 안쪽(SalesRecord)부터 바깥으로 나아간 순서가 도움이 됐는가?

바이브 코딩의 핵심 재정의: 바이브 코딩은 "AI가 코드를 빨리 만드는 것"이 아니라, "사람이 무엇을·왜·어떤 규칙으로 만들지 정하고, 테스트로 신뢰를 확보하는 것" 이다. 속도는 그 결과로 따라온다. 그리고 그 "사람의 판단력"은 손으로 만들어 본 경험에서 나온다.

✏️ 토론 — 안티패턴과 비교

3교시의 "한 파일 스파게티 앱"과 우리 구조를 비교해 보세요.

질문	스파게티(한 파일)	우리 구조(4계층)
LLM을 다른 모델로 교체하려면?	화면 코드까지 수정	llm_gateway 어댑터(또는 주입)만 교체
분석 로직만 테스트하려면?	Streamlit·OpenAI까지 실행	Fake 주입으로 즉시
데이터 출처를 DB로 바꾸려면?	곳곳을 수정	Repository 어댑터 하나 추가
새 팀원이 구조를 파악하려면?	200줄 정독	계층 이름으로 빠르게 파악

---

📖 3. 다른 도메인으로 확장하기

이 아키텍처는 도메인 독립적입니다. "매출"을 다른 주제로 바꿔도 뼈대는 그대로입니다.

바꿀 것	그대로 둘것
도메인 엔티티(SalesRecord → 무엇이든)	4계층 구조, 의존성 규칙
분석 유스케이스의 집계 공식	포트/어댑터 패턴, TDD 루프
CSV 스키마, 차트 종류	"숫자는 코드·해석은 LLM" 원칙
LLM 프롬프트 문구	Copilot 규칙서/프롬프트 자산

 

현업 적용 아이디어:

• 고객 문의 로그 → 분류·감정 분석 → 대응 가이드 리포트
• 학습 성취 데이터 → 취약 단원 분석 → 보충 학습 추천
• 설비 센서 로그 → 이상치 탐지 → 점검 우선순위 리포트
• 마케팅 채널 데이터 → 채널별 ROI 분석 → 예산 배분 제안

🔍 관찰 포인트: 위 어떤 경우든 "적재(어댑터) → 계산(유스케이스) → 해석(LLM) → 리포트" 의 골격은 동일합니다. 한 번 익힌 패턴을 평생 재사용하는 셈입니다.

✏️ 미니 실습 — 내 도메인으로 한 줄 설계

본인 현업/관심 주제 하나를 골라 빈칸을 채워 보세요.

도메인 엔티티:   ____________  (예: SupportTicket)
핵심 검증 규칙:   ____________  (예: 우선순위는 1~5만 허용)
분석 유스케이스:  ____________  (무슨 지표를 계산?)
LLM이 만들 해석:  ____________  (어떤 통찰을 글로?)
최종 리포트 형태: ____________

🔒 진행 게이트 (과정 마무리)

• 제출물(기록): 내 도메인을 4계층 후보(엔티티·유스케이스·포트·어댑터)와 "결정적 vs 확률적" 경계로 한 줄씩 분해한 메모.
• 정답·해설(별도 파일): solutions/미니실습정답_14.md (예시 + 자기 점검 질문)

---

📖 4. 교육 현장 적용 전략 (훈련기관 종사자 대상)

이 과정 자체를 여러분의 강의 자산으로 재구성하는 방법입니다.

• 모듈식 재사용: 1일차(설계·환경·TDD)는 거의 모든 AI 개발 과정의 공통 도입부로 활용할 수 있습니다.
• 난이도 조절: 초급반은 포트/Fake 개념을 줄이고 "동작하는 앱"에 집중하고, 중·고급반은 아키텍처 테스트·확장까지 다룹니다.
• 평가 설계: 본 과정(특별교육)엔 평가가 없지만, 정규 과정으로 옮길 땐 "교시별 체크포인트"를 그대로 형성평가 문항으로 전환할 수 있습니다.
• 프롬프트 자산 공유: copilot-instructions.md와 *.prompt.md는 학습자에게 배포하는 재사용 템플릿으로 좋습니다.
• 도구 변화 대응: Copilot·LLM은 자주 바뀝니다. 가르치는 핵심은 도구가 아니라 "규칙·테스트·계층"이라는 잘 바뀌지 않는 원칙임을 강조하세요.

---

📖 5. 다음 학습 로드맵

이 과정 이후 스스로 더 나아갈 길입니다.

1. 영속성 추가 — Repository 어댑터를 SQLite/PostgreSQL 버전으로 추가(기존 분석 로직은 그대로 재사용).
2. 에이전트 고도화 — 단일 요약을 넘어 "도구를 선택해 호출하는" 에이전트 루프(LangGraph 등) 도입. 단, 계산은 여전히 결정적 코드에 둔다.
3. CI 자동화 — GitHub Actions에서 uv run pytest를 PR마다 실행해 회귀를 막는다.
4. 관측성 — 토큰/비용 로깅, 처리 시간 측정을 인프라 계층에 추가.
5. 배포 — Streamlit Cloud/컨테이너로 배포, .env는 비밀 관리 서비스로 분리.

---

✅ 최종 체크포인트 (과정 수료 확인)

• [ ] 4계층과 의존성 규칙을 남에게 설명할 수 있다
• [ ] Red→Green→Refactor 한 사이클을 혼자 돌릴 수 있다
• [ ] 포트/어댑터로 외부 의존을 교체·테스트할 수 있다
• [ ] Copilot을 규칙서로 길들여 일관된 코드를 얻을 수 있다
• [ ] 이 구조를 다른 도메인으로 옮기는 방법을 말할 수 있다
• [ ] uv run pytest -v가 전체 통과하는 완성 프로젝트를 갖고 있다

---

🔑 핵심 정리 (과정 전체)

• 우리는 작은 매출 앱을 만든 게 아니라, 변경·확장·검증에 강한 AI 시스템을 짓는 방법을 익혔다.
• 잘 바뀌지 않는 세 원칙: ① 의존성은 안쪽으로 ② 테스트로 신뢰를 ③ 숫자는 코드·해석은 LLM.
• 도구(uv·Copilot·OpenAI)는 바뀌어도, 이 원칙은 다음 프로젝트에서도 그대로 쓰인다.

---

🎓 수고하셨습니다

이 가이드 묶음과 완성된 sales-insight-agent 프로젝트는, 앞으로 새로운 AI Agent를 설계할 때마다 돌아올 수 있는 여러분의 레퍼런스입니다. 다음 도메인에서 다시 1교시의 리듬으로 시작하세요.