어떤 걸 고를까
| 이런 분이라면 | 추천 |
|---|---|
| 정기 보고서를 만드는 실무자 | E1. 파이프라인 하네스 |
| 여러 부서 데이터를 합치는 일을 하는 분 | E2. 계약 중심 팬아웃 |
| 코드를 다루는 분 | E2 · E3 |
E1은 비전공자도 그대로 할 수 있습니다. E2·E3은 코드가 나오지만, 구조를 보는 것만으로도 배울 것이 있습니다. 읽고 넘어가도 괜찮습니다.
E1. 파이프라인 하네스 — 정책 데이터에서 슬라이드까지
| 난이도 | 비전공자 가능 |
|---|---|
| 모듈 | slide/ |
| 배우는 것 | 수집 → 갱신 → 디자인 생성 → 검수로 이어지는 4단계 파이프라인 |
공개 정책 데이터를 모아 엑셀 현황판을 갱신하고, 정부 표준 디자인 슬라이드를 자동 생성합니다. 2차시가 단일 프롬프트 ETL이었다면, 여기는 여러 단계가 이어지는 파이프라인형 하네스입니다.
관찰 포인트 — 기준일 셀 하나를 바꾸면 전체가 다시 계산되는 "살아 있는 문서" 구조. 수식으로 계산되는 지표와 하드코딩된 값의 차이를 눈으로 확인하세요.
E2. 계약 중심 팬아웃 — 이기종 데이터를 하나로
| 난이도 | 개발 지식 권장 |
|---|---|
| 모듈 | dashboard/ |
| 배우는 것 | 표준 스키마를 먼저 확정해 병렬 개발을 가능하게 하는 구조 |
설비 200대가 제각각의 형식으로 데이터를 보냅니다 — 숫자 상태코드, 영문 약어, 한글 키, CSV 문자열. 같은 사실이 4가지 형식·3가지 단위·2가지 언어로 도착합니다. 2차시의 "분임조 은어 문제" 가 실시간 스트림으로 확장된 셈입니다.
관찰 포인트 — 5차시에서 배운 계약이 여기서 진가를 발휘합니다. 표준 형식을 먼저 정하면 데이터를 보내는 쪽과 받는 쪽을 동시에 만들 수 있습니다.
E3. 코드 유지보수 하네스 — 진단·패치·리뷰·자동화
| 난이도 | 개발 |
|---|---|
| 모듈 | codex-engineering/track-a-engineering/ |
| 배우는 것 | 대화형 진단 → 승인하며 패치 → 교차 리뷰 → 자동 검사 |
숨은 결함이 있는 품질 검사 스크립트로 "테스트 통과 ≠ 정확" 을 체험합니다. 5차시에서 배운 권한 통제(대화형 승인 vs 자동 실행 샌드박스)가 실제 코드 작업에서 어떻게 쓰이는지 보는 트랙입니다.
확장 트랙을 관통하는 것
세 트랙 모두 본 과정에서 배운 원리의 변주입니다. 도메인만 바뀝니다.
| 원리 | 본 과정에서 | 확장 트랙에서 |
|---|---|---|
| 역할 분리 | 4차시 에이전트 팀 | E3 — 진단·패치·리뷰를 각각 다른 담당에게 |
| 지식의 외부화 | 2차시 용어집 | E1 — 템플릿·디자인 표준을 파일로 |
| 계약이 병렬성을 만든다 | 5차시 스펙 | E2 — 스키마를 먼저 정해 동시 개발 |
| 검증자 분리 | 4차시 검증 담당 | E3 — 교차 리뷰와 자동 검사 게이트 |
새 도메인을 만나면 물어보세요. "여기서 지식은 무엇이고, 계약은 무엇이며, 검증자는 누구인가?" 이 세 질문이면 대부분의 하네스를 설계할 수 있습니다.