TypeSafe Jev 시리즈 10/10 — 코드가 통제하는 AI 워크플로 설계 정리 | DAKER 커뮤니티
시리즈의 마지막 편에서는 TypeSafe의 설계 원칙과 Patterns를 한 번에 묶어 봅니다. 핵심은 단순합니다. AI를 중심에 두는 것이 아니라, 코드를 중심에 두고 모델은 꼭 필요한 판단만 맡기는 방식입니다.
이 관점은 워크플로를 더 예측 가능하게 만들고, 비용과 속도, 신뢰성까지 함께 다루게 해줍니다. 특히 여러 단계를 거치는 자동화에서 어디까지를 코드가 책임지고 어디서 모델을 호출할지 정리하고 싶을 때 지금 읽어둘 만합니다.
세 가지 아키텍처를 어떻게 구분할까
문서에서는 소프트웨어 구조를 세 가지로 나눕니다. 전통 소프트웨어는 단순 프리미티브를 조합한 결정 트리로 움직입니다. 반면 LLM 에이전트는 모델이 다음 단계를 고르는 구조입니다. 사람이 곁에서 감시할 때는 유용할 수 있지만, 루프를 돌수록 이탈 위험이 커집니다.
여기서 TypeSafe가 강조하는 것은 AI-powered software입니다. 제어 흐름과 결정론, 부수효과는 코드가 갖고, 모델은 상식 판단이나 비정형 해석이 필요할 때만 등장합니다.
코드가 워크플로를 소유하고, 모델은 좁고 구조화된 판단만 맡습니다.
System One이 조합 가능한 이유
문서가 드는 특징은 Structured, Parallel, Comparable, Fast, Calibrated confidence, Self-consistent입니다. 요지는 출력이 주어진 옵션 안으로 제약되기 때문에, 결과를 코드에서 다루기 쉬운 형태로 받을 수 있다는 점입니다.
독립적인 질문은 병렬로 다룰 수 있고, 결과끼리 비교하거나 임계값을 둘 수도 있습니다. 대부분 약 100ms라는 속도 특성도 반복 호출이 많은 워크플로에서 중요한 장점이 됩니다. 여기에 confidence를 함께 다루면, 단순한 정답 예측을 넘어 안전한 라우팅 기준까지 세울 수 있습니다.
출력이 구조화되어 있을수록, 모델의 답은 코드 안에서 더 잘 결합됩니다.
설계할 때 먼저 보는 체크리스트
이 시리즈의 결론에 가까운 부분입니다. 할 수 있으면 결정론 규칙으로 먼저 처리하고, state에는 현재 질문에 필요한 맥락만 넣는 것이 좋습니다. 필드를 가리킬 때는 중첩 JSON과 백틱 경로를 쓰고, 넓고 모호한 질문은 원자적 질문으로 나누는 편이 안정적입니다.
instructions나 criteria 자체에 구조가 필요하다면 객체로 표현하고, 서로 독립적인 질문은 한 요청에 많이 담아 보낼 수 있습니다. 그렇게 얻은 답은 코드나 고전 ML에서 결합하면 됩니다. 마지막으로 불확실한 경우에는 사람이나 더 비싼 추론 모델로 라우팅하는 방식이 권장됩니다.
넓은 질문 하나보다, 좁고 독립적인 질문 여러 개가 더 다루기 쉽습니다.
Patterns 네 가지를 한 번에 보기
| 패턴 | 하는 일 | 이점 |
|---|---|---|
| Speculative Fan-Out | 추측 질문 포함 다수를 한 호출에 보내고 코드가 취사선택 | 비용·속도 |
| Confidence-Gated Routing | confidence를 두 번째 축으로 안전한 라우팅 | 신뢰성·안전 |
| Composite Scoring | 여러 차원 Score를 가중 합 | 비용·신뢰성·속도 |
| Intent Routing | 의도를 분류해 핸들러로 라우팅 | 비용·속도 |
이 네 가지 패턴은 서로 다른 문제를 다루지만 공통점이 있습니다. 모델이 모든 결정을 내리게 두지 않고, 구조화된 판단을 여러 개 받아 코드가 최종 선택을 한다는 점입니다. 그래서 비용을 줄이거나 속도를 높이는 데 그치지 않고, 신뢰성과 안전성까지 함께 설계할 수 있습니다.
한 티켓 워크플로에 적용하면
문서의 triage 예시는 이 원칙을 실제 흐름으로 보여줍니다. 닫힌 티켓은 모델 없이 처리하고, 필요한 구조화 context만 state에 넣습니다. 그다음 topic Choice, 여러 Noul, frustration Score를 한 요청에서 함께 평가합니다.
이후에는 spam_risk 가중 합과 confidence 게이트를 이용해 검토, 격리, 팀 라우팅을 나눕니다. 중요한 점은 제어가 전부 코드에 있다는 사실입니다. 모델은 판단 조각을 제공하지만, 워크플로 전체를 움직이는 주체는 아닙니다.
모델은 판단을 제공하고, 워크플로의 최종 제어는 코드가 맡습니다.
마무리
이번 편은 시리즈 1–9의 내용을 하나의 설계 원칙으로 묶어 줍니다. 좋은 AI 워크플로는 모델 호출을 늘리는 쪽이 아니라, 어떤 판단을 구조화해 코드 안에 안전하게 편입할지 정리하는 쪽에 가깝습니다.
시리즈 1–9에서 고른 판단 하나를 Speculative Fan-Out 또는 Confidence-Gated Routing 중 하나로 스케치해 보고, 공식 Patterns 페이지의 하위 문서로 이어 읽어보면 흐름이 더 선명해집니다.
참고 자료
How to build with TypeSafe (.md)
이전: 9/10 확률과 다른 확신 신호 · 시리즈 10/10 (완료)
여러분은 AI 워크플로를 설계할 때 모델이 맡아야 할 판단과 코드가 맡아야 할 제어를 어떻게 나누고 계신가요?