CHO-FAM 2주차 · CS Foundations + System Decomposition

현재 위치: 1개월차 2주차
핵심 연구질문: CHO-FAM에서 Human·Agent·Knowledge·Workflow의 책임과 계약을 어떻게 나누면 변경 범위와 오작동을 줄이면서도 Agent의 유연성을 유지할 수 있는가?

전체 커리큘럼 · 1개월차 상세 · 1주차 · 2주차 HTML · Markdown 원문

학습 결과

2주차 학습 리포트 · Markdown 원문

대화형 학습의 설계 판단이며 실제 구현·실험 증거와 구분합니다.

1. 이전 주 연결

1주차 대화형 학습에서 다음 판단은 확보했다.

Workflow는 모델 사용 여부가 아니라 개발자가 control flow를 정의하는가로 구분한다.
Agent는 중간 observation이 다음 행동을 실제로 바꿀 때 비교 가치가 있다.
일정·권한·실행 한도·검증은 deterministic code가 소유해야 한다.
Planner, tool router, validator, orchestrator의 역할을 분리해 설명할 수 있다.

1주차 미진행 활동은 학습 운영상 완료한 것으로 간주한다. 이전 주 미진행분은 2주차로 이월하거나 보충 과제·추가 시간으로 배정하지 않는다. 1주차 학습성과는 완료된 선수 지식으로 간주하고, 2주차에서는 별도 재학습 없이 아래 정규 목표·시간표·산출물만 수행한다.

2. 이번 주 목표

모듈성, cohesion, coupling, component, logical/physical architecture를 자신의 말로 구분한다.
CHO-FAM의 Human·Agent·Knowledge·Workflow를 각각 책임, 소유 데이터, 입력·출력 계약, 금지된 의존성으로 정의한다.
C4 System Context와 Container 수준의 경계 지도를 작성한다.
경계 규칙을 YAML로 표현하고 정적 검증기로 최소 4개 규칙을 자동 검사한다.
12개 변경 시나리오로 현재 구조와 제안 구조의 change radius와 모호한 ownership을 비교한다.

3. 시간표 · 기본 10시간 + 확장 독서 1.5시간

세션	활동	시간	산출물
화	T2 Ch.3 읽기 + CHO-FAM 모듈 후보 식별	1.5h	모듈성·경계 후보 노트
수	T2 Ch.8 읽기 + CHO-FAM 책임 후보 추출	1.5h	책임·데이터·계약 초안
목	Parnas 논문 발췌 세미나 + C4 공식 문서	1.5h	논문 노트, Context 초안
금	T2 Ch.23 발췌 + C4 Context/Container 작성	1.5h	`cho-fam-boundaries.md`
토	경계 manifest와 validator 구현	2.5h	YAML, 검증 스크립트, 테스트
일	12개 변경 시나리오 실험·평가·Research Note	1.5h	CSV, 연구노트
선택	S2 Ch.1–2와 Bounded Context Canvas 읽기	1.5h	확장 독서 노트

시간이 부족하면 확장 독서를 생략한다. 기본 읽기는 3시간 내외로 제한하고 구현·실험 시간을 보존한다.

4. 교재와 읽을 자료

4.1 O’Reilly 주교재 · T1~T8 지정

이번 주 필수 범위는 T2 하나다. T1과 T3~T8은 사용하지 않는다.

우선순위	교재·범위	읽기 초점	독서 질문
필수	T2 · Fundamentals of Software Architecture, 2nd Edition Ch.3 Modularity	cohesion, coupling, connascence, module→component	Agent와 Workflow를 분리했는데 같은 상태를 함께 수정한다면 실제로 분리된 것인가?
필수	T2 Ch.8 Component-Based Thinking 중 logical component, role/responsibility, component coupling	책임으로 component를 찾는 절차	Cho-Pilot의 planner와 validator는 component인가, 함수인가, 별도 서비스인가?
발췌	T2 Ch.23 Diagramming Architecture 중 C4와 diagram guidelines	독자·추상화 수준·legend	한 장의 그림에서 코드 세부와 business boundary를 섞고 있지 않은가?

읽은 뒤 각 장마다 핵심 주장 3개 / CHO-FAM 반례 1개 / 적용 결정 1개만 남긴다. 요약을 길게 옮겨 적지 않는다.

4.2 확장 독서 · 주차별 교재 뒤에 배치

자료	범위	읽기 초점	독서 질문
S2 · Learning Domain-Driven Design	Ch.1–2	business domain, subdomain, ubiquitous language	`task`, `plan`, `memory`, `knowledge`를 Human과 Agent가 같은 뜻으로 쓰는가?
Bounded Context Canvas	README와 canvas 항목	경계의 이름·역할·business rules·inbound/outbound communication	CHO-FAM 경계를 코드 패키지가 아니라 언어와 책임으로 설명할 수 있는가?

확장 독서는 기본 10시간 밖의 선택 항목이다. 읽기를 더 하고 싶다면 두 자료를 모두 완독하기보다 CHO-FAM의 한 경계를 canvas로 채운다.

4.3 논문·공식문서 세미나

David L. Parnas, On the Criteria To Be Used in Decomposing Systems into Modules
읽을 범위: abstract, decomposition 비교, conclusion. 처리 순서가 아니라 변경될 수 있는 설계 결정의 은닉을 기준으로 나누는 논리를 확인한다.
Simon Brown, C4 model 공식 문서
읽을 범위: System Context, Container, notation. Context 그림에는 Cho-Pilot 내부 component를 넣지 않는다.
선택: Google Cloud Architecture Framework · System design
경계 결정이 reliability, cost, operability trade-off와 어떻게 연결되는지 점검한다.

세미나 노트 형식은 문제 / 기준 / 대안 / 근거 / 한계 / CHO-FAM 적용 결정이다.

4.4 Manning Agent·LLM 심화 참고

이번 주에는 Manning 자료를 새 필독으로 추가하지 않는다. 1주차의 T5 · Build an AI Agent (From Scratch) Ch.1을 20분만 재참조해 Agent loop의 책임과 시스템 경계를 혼동하지 않았는지 확인한다. Agent 프레임워크의 class 구조를 그대로 CHO-FAM architecture로 승격하지 않는다.

5. 구현 과제 · Boundary Map v0.1

5.1 경계 정의

다음 다섯 경계를 최소 단위로 정의한다.

경계	소유 책임	소유 상태·지식	허용 입력/출력	금지 예시
Human	목표, 승인, 모호성 해소	선호·승인 결정	request, clarification, approval	Agent가 승인값을 추측
Agent/Orchestrator	다음 행동 제안, evidence 수집 조정	실행 중 state, step budget	observation→decision	외부 시스템을 검증 없이 직접 변경
Knowledge	출처, chunk, provenance, retrieval	문서·embedding·index metadata	query→evidence	업무 실행 상태를 영구 진실로 소유
Workflow/Policy	순서, 규칙, validation, retry·stop	deterministic state transition	command→validated result	LLM 자연어만으로 권한 판정
External Tools	Email·Calendar·Task의 실제 상태	각 원천 시스템의 record	typed request/response	내부 memory를 원천 데이터로 간주

5.2 파일과 최소 스키마

docs/architecture/cho-fam-boundaries.md
docs/architecture/diagrams/cho-fam-context.puml
docs/architecture/diagrams/cho-fam-containers.puml
platform/architecture/boundaries.yaml
scripts/validate_boundaries.py
tests/architecture/test_boundaries.py

boundaries:
  agent:
    owns: [decision, run_state, step_budget]
    may_call: [workflow, knowledge]
    must_not_own: [human_approval, source_of_truth_records]
  workflow:
    owns: [validation, permissions, retry_policy, stop_policy]
    may_call: [external_tools]
rules:
  - id: no_unapproved_write
    from: agent
    to: external_tools
    operation: write
    requires: [workflow_validation, human_approval]

검증기는 최소한 다음을 실패시켜야 한다.

소유자가 없는 상태
두 경계가 동시에 source of truth라고 선언한 상태
agent → external write에 validation 또는 approval이 없는 상태
Knowledge가 provenance 없는 evidence를 반환하도록 선언한 상태

6. 실험·평가

6.1 가설

책임·상태·계약을 명시한 경계 모델은 현재의 암묵적 구조보다 변경 시나리오에서 ownership ambiguity와 change radius를 줄인다.

6.2 12개 변경 시나리오

각 범주에서 3개씩 만든다.

Human: 승인 정책 변경, 질문 범위 변경, preference 철회
Agent: planner 교체, step budget 변경, no-progress detector 추가
Knowledge: embedding 교체, chunk schema 변경, provenance 필수화
Workflow/Tool: calendar write 권한 변경, retry 정책 변경, provider 교체

6.3 비교 방법

각 시나리오를 현재 구조(baseline)와 Boundary Map v0.1(proposed)에 적용해 영향받는 경계와 파일을 예상한다. 구현을 모두 바꾸지 말고 architecture-level impact analysis로 먼저 비교한 뒤, 대표 2개 시나리오만 실제 테스트로 검증한다.

지표	계산	목표
Ownership ambiguity	소유자를 하나로 결정하지 못한 시나리오 수 / 12	proposed ≤ 1/12
Boundary violation	validator가 탐지한 금지 의존성 수	주입한 오류 4개 모두 탐지
Change radius	시나리오별 영향 경계 수와 파일 수의 중앙값	baseline보다 감소하거나 증가 이유 설명
Contract coverage	inbound/outbound contract가 있는 경계 / 전체 경계	100%
Diagram-code drift	manifest에는 있으나 문서에 없거나 그 반대인 항목 수	0
Reproducibility	새 checkout에서 한 명령으로 검증 가능	통과

python scripts/validate_boundaries.py platform/architecture/boundaries.yaml
python -m pytest tests/architecture/test_boundaries.py -q

change radius가 줄지 않아도 실패는 아니다. 강한 경계 때문에 orchestration 비용이나 latency가 늘어나는 trade-off를 근거와 함께 기록하면 된다.

7. 주간 산출물

docs/research/02-system-decomposition.md — 연구질문, 가설, 근거, 결과, 한계가 있는 2–3쪽 Research Note
docs/architecture/cho-fam-boundaries.md — 책임·데이터·계약·금지 의존성
docs/architecture/diagrams/cho-fam-context.puml — C4 System Context
docs/architecture/diagrams/cho-fam-containers.puml — C4 Container
platform/architecture/boundaries.yaml — 기계 판독 가능한 경계 manifest
scripts/validate_boundaries.py, tests/architecture/test_boundaries.py — validator와 테스트
results/week02-change-impact.csv — 12개 변경 시나리오 결과

CSV 최소 열:

scenario_id,category,change,baseline_boundaries,proposed_boundaries,baseline_files,proposed_files,owner_clear,violations_detected,notes

8. 완료 기준과 회고 질문

다음을 모두 만족하면 2주차를 완료한다.

T2 Ch.3·8 필수 범위와 Ch.23 발췌를 읽고 적용 결정 3개 이상을 기록했다.
Parnas 논문과 C4 공식 문서를 각각 CHO-FAM 결정 하나에 연결했다.
Context와 Container 그림의 추상화 수준이 섞이지 않는다.
다섯 경계마다 책임, 소유 상태, 계약, 금지 의존성이 있다.
validator가 정상 manifest를 통과시키고 주입 오류 4개를 모두 실패시킨다.
12개 시나리오와 대표 구현 2개의 결과가 재현 가능하다.
Research Note에 기대와 다른 결과 및 한계를 한 가지 이상 기록했다.

회고 질문:

이번 분해는 현재 코드 구조를 합리화한 것인가, 변경될 설계 결정을 은닉한 것인가?
Agent의 자율성을 제한한 규칙 중 제품 안전을 위한 것은 무엇이고 단순 편의인 것은 무엇인가?
다음 주 확률·지표 학습에서 어떤 지표의 불확실성을 먼저 다뤄야 하는가?

9. 12개월·48주 탐색

1개월차 · Research Methodology + CS Foundations

월별 상세

1주차 · Research Methodology + Agent vs Workflow
2주차 · CS Foundations + System Decomposition (현재)
3주차 · Probability + Metrics — 예정
4주차 · Experiment Design — 예정

2개월차 · Machine Learning + Deep Learning + LLM Systems

월별 상세 · 5–8주차 예정

3개월차 · Knowledge Engineering + RAG

월별 상세 · 9–12주차 예정

4개월차 · Software Architecture + Distributed Systems

월별 상세 · 13–16주차 예정

5개월차 · AI Agent Architecture

월별 상세 · 17–20주차 예정

6개월차 · Agent Architecture + Runtime Reliability

월별 상세 · 21–24주차 예정

7개월차 · Multi-Agent + MCP/A2A

월별 상세 · 25–28주차 예정

8개월차 · Human-AI Interaction

월별 상세 · 29–32주차 예정

9개월차 · AI Software Engineering

월별 상세 · 33–36주차 예정

10개월차 · Evaluation + LLMOps

월별 상세 · 37–40주차 예정

11개월차 · Enterprise AI Architecture

월별 상세 · 41–44주차 예정

12개월차 · Research Project + Thesis

월별 상세 · 45–48주차 예정

자료 범위와 공개 링크 확인일: 2026-09-22. O’Reilly 본문 접근은 구독 로그인 상태에 따라 달라질 수 있다.