앱 너머의 설계 — 프레임워크, AI 모델, 프로토콜

how-to-design-a-program-from-scratch|6단계 설계 프로세스는 앱이 아닌 것을 만들 때도 적용되는가. 뼈대는 유지되지만, 각 단계에서 묻는 질문이 달라진다.

변하지 않는 것과 달라지는 것

변하지 않는 것: 요구사항 분석, 도메인 모델링, 구조 결정, 검증은 항상 필요하다.

달라지는 것: "사용자"의 정의, 설계의 반복 빈도, 검증 방법, 추가 고려사항.

| | 앱 | 프레임워크 | AI 모델 | 프로토콜 | |---|---|---|---|---| | 사용자 | 최종 사용자 | 개발자 | 없음 (학습 대상) | 양쪽 구현체 | | 요구사항 | 기능 목록 | API 표면 설계 | 문제 정의 + 메트릭 | 상호운용성 | | 도메인 모델 | 현실 개념 | 추상적 개념 | 수학적 구조 | 통신 + 상태 머신 | | 반복 빈도 | 낮음 | 중간 | 매우 높음 | 낮음 | | 검증 | 기능 테스트 | API 사용성 | 정량 메트릭 | 상호운용성 테스트 |

Framework 설계

요구사항의 차이

앱은 "기능 목록"을 정한다. 프레임워크는 **"가능성의 공간"**을 설계한다:

이 프레임워크를 쓰는 개발자가 뭘 하고 싶어하는가?
어디까지 자유도를 줄 것인가?
어디서 제약을 걸어야 잘못된 사용을 방지하는가?

추가되는 우선순위

API 직관성: 5분 안에 시작할 수 있는가?
확장성: 예상 못한 사용을 허용하는가?
하위 호환성: 업데이트해도 기존 코드가 깨지지 않는가?
에러 메시지 품질: 잘못 쓰면 뭐가 틀렸는지 알려주는가?

도메인 모델의 차이

현실 개념이 아니라 추상적 개념을 모델링한다. Svelte의 경우: Component, Reactive Statement, Store, Transition.

컴포넌트 분해의 차이

기능별이 아니라 개발자가 접하는 계층별로 나눈다: Public API → Internal Core → Compiler/Runtime → Plugin System.

AI Model 설계

과정 자체가 다르다

앱은 "설계 → 구현 → 검증"이 비교적 선형적. AI 모델은 "가설 → 실험 → 측정 → 수정"의 반복이다:

각 단계의 대응

| 앱 설계 | AI 모델 설계 | |---|---| | 요구사항 | 문제 정의 + 성공 메트릭 | | 도메인 모델 | 환경/데이터 설계 (수학적 구조) | | 아키텍처 | 모델 아키텍처 (네트워크 구조, 알고리즘) | | 컴포넌트 분해 | 학습 파이프라인 (architecture-patterns-overview|Pipe & Filter) | | 테스트 | 실험 & 정량 측정 | | 유지보수 | 분석 & 개선 루프 |

뼈대는 대응되지만, AI 모델은 반복 횟수가 압도적으로 많다.

검증의 차이

앱: "기능이 동작하는가?" → 통과/실패
AI:  "성능이 충분한가?" → 정량 메트릭
   + "왜 이렇게 동작하는가?" → 해석 가능성
   + "다른 환경에서도 되는가?" → 일반화 테스트

Protocol 설계

핵심 차이: 사용자가 둘 이상

앱의 사용자는 한쪽(최종 사용자). 프로토콜의 사용자는 양쪽 구현체로, 독립적으로 만들어도 서로 통신할 수 있어야 한다.

상태 머신이 핵심

프로토콜에서는 "어떤 상태에서 어떤 메시지를 받으면 어떤 상태로 전이하는가"를 형식적으로 정의해야 한다. 앱 설계에서는 보통 이 수준의 형식화가 필요 없다.

추가 고려사항

버전 관리: v1 클라이언트가 v2 서버와 통신 가능한가?
확장성: 새 필드 추가 시 기존 구현이 안 깨지는가?
에러 복구: 메시지 유실/순서 변경에도 상태가 일관적인가?
명세의 명확성: 다른 사람이 명세만 읽고 구현할 수 있는가?

정리

6단계의 뼈대는 뭘 만들든 유지된다. 바뀌는 건 각 단계에서 묻는 질문의 종류다: 앱은 "이 기능이 필요한가?", 프레임워크는 "이 API가 직관적인가?", 모델은 "이 가설이 맞는가?", 프로토콜은 "양쪽이 이해할 수 있는가?"