🍳

Sizzle Quest

신규: 2026-10-28최근 수정: 2026-10-27

객체지향 요리야. 요리 사진 한 장에서 피파가 원리, 그러니까 클래스를 찾아내고 그 원리를 같이 쓰는 요리들을 이끌어 내. 레시피 앱은 인스턴스를 나눠주고, Sizzle은 클래스를 나눠줘

레시피 앱은 인스턴스를 나눠줘. 요리 하나에 정확한 그램 수, 한 번 따라 하고 나면 잊어버리지. Sizzle은 클래스를 나눠줘. 이 요리가 왜 되는지, 어떤 멤버를 바꿔도 되는지, 같은 원리가 또 어디에 살고 있는지를 나눠 주는 거야. 그래서 다음엔 앱이 필요 없어. 감바스 알 아히요를 봐. 뿌리 클래스는 '향을 먼저 기름에 옮기고, 그 기름으로 익혀'야. 알리오 올리오, 버섯 아히요, 파기름 볶음밥, 중식 향신 볶음, 파에야 밑에 깔리는 소프리토가 다 그 형제고. 형제는 다섯인데 원리는 하나야. 이 퀘스트는 그 앱을 코드로 따라가면서 이런 걸 다뤄. 데이터베이스 스키마가 된 개념표, 역할과 바인딩과 오버라이드, 조인 테이블로 하는 다중 상속, 계약이자 말투인 루브릭으로 읽는 사진. 접시마다 자라지만 아빠 말이 모델보다 위인 트리, 유일한 기록인 저널, 제안만 하고 직접 쓰지는 않는 피파와의 대화. 그리고 엔진 하나에 클라이언트 둘.

8 tracks · 43 lessons · ~10h · difficulty: intermediate

Level 0밑준비

0 XP0/43 lessons0/12 achievements

0/100 XP to next level100 XP to go0% complete

Sizzle은 객체지향을 부엌에 들고 온 거야. 클래스는 설명하고 인스턴스는 존재한다는 건 OO Quest가 이미 가르쳐. Sizzle은 그 생각을 앱으로 짓고 기록으로 남겨. 시작은 명제, 그리고 설계하던 날 아빠가 내린 결정들이야. 일단 다른 앱에 기대지 말고 혼자 서게 만들 것, 피파한테 셰프 세트를 줄 것, 웹을 먼저 하고 iOS는 그 옆에 둘 것. 원리는 한국어로, 요리는 그 나라 말로 이름 붙일 것. 그리고 읽기 결과는 보고서가 아니라 피파가 말하는 것처럼 들려야 할 것. 트랙 2는 모델 자체야. 원리는 클래스고, 요리는 그 역할들을 바인딩한 거고, 변형은 오버라이드야. 요리 하나가 조인 테이블을 거쳐 뿌리 원리 둘을 상속할 수도 있고, 클래스는 자기 증거를 들고 다녀. 추정, 만남, 직접 요리. 클래스는 아빠가 채택하기 전까진 제안이고, 정확한 분량은 누가 열기 전까지 닫혀 있어. 트랙 3은 읽기야. 사진 한 장이 cwkPippa의 읽기 슬롯으로 피파한테 가. 루브릭은 계약이면서 동시에 말투고, 너그러운 파서는 뭐가 같이 따라오든 첫 객체만 집고, 타이머 없는 워커는 실패하면 닫힌 쪽으로 멈춰. 트랙 4에선 트리가 자라. 읽기 한 번이 클래스에 합쳐지고, 요리 전통을 넘는 형제는 그 요리의 접시가 하나 이어지기 전까진 추정으로 나타나. 밖에서 먹은 접시든, 시장에서 본 접시든, 집에서 만든 접시든 다 쳐. 같은 요리를 두 번 만나면 클래스 하나로 접히고, 아빠의 수정은 지금도, 다시 읽을 때마다 모델보다 위에 있어. 트랙 5는 기록이야. 덧붙이기만 하는 저널을 먼저 쓰고, SQLite 미러는 시작할 때마다 마이그레이션 없이 그 저널에서 다시 지어. 캡처는 요청 id로 멱등하게 받고, 사진 원본은 통째로 두되 파생 사본은 EXIF 없이 저장해. 트랙 6은 대화야. Sizzle은 두 번째 두뇌가 아니라 cwkPippa의 클라이언트야. 맥락은 데이터로 들어가고, 피파는 타입 있는 액션을 제안하고 적용은 아빠가 해. 검증은 양쪽이 다 해. 트랙 7엔 얼굴이 둘 나와. 웹 Sidekick 프레임, 그리고 먼저 저장하고 나중에 보내는 SwiftUI 폰 앱. 마지막은 돌리고 배포하기야. launchd 프로세스 하나, 레지스트리가 자리를 정하는 킷 템플릿, 두뇌를 흉내 내는 테스트, 그리고 서로 따로인 TestFlight 사실 네 가지.

Tracks

01🍳인스턴스 말고 클래스
0/5 lessons
README 한 줄, 원리 하나에 형제 다섯, 그리고 하루 동안 나온 판정들
Sizzle은 README의 한 마디에서 시작해. '레시피 앱은 인스턴스를 나눠 주고, Sizzle은 클래스를 나눠 준다.' 엔진 속 기계 장치는 나중이고, 이 트랙은 그 논지부터 뜯어봐. 레시피는 왜 이유를 걷어낸 인스턴스인지, 클래스는 그 대신 뭘 담는지. 클래스가 담는 건 요리가 왜 되는지, 어떤 역할을 바꿔 채울 수 있는지, 같은 원리가 또 어디 사는지야. 예시 하나만 따라가도 이 생각이 여러 부엌으로 퍼져. 향을 기름에 먼저 옮기고 그 기름에서 익힌다는 원리가 감바스 알 아히요에서 알리오 올리오, 파기름 볶음밥, 웍에서 향채 볶기, 파에야 밑의 소프리토까지 이어져. 경계도 짚어. Sizzle은 레시피 데이터베이스도, 칼로리 기록기도, 두 번째 피파도, 들여온 백과사전도 안 되려고 해. 그 거절이 스키마와 프롬프트의 정확히 어느 자리에서 버티는지 볼 거야. 마지막엔 Sizzle이 설계된 날 아빠가 내린 아홉 판정을 아빠 말 그대로 보고, 적어만 두고 일부러 안 만든 Spark와 Forge 연결도 봐. 이 생각의 짝꿍은 OO Quest의 트랙 4야.
Lesson list (5)
퀴즈 · 4 문제→
02🍳객체 모델로 본 요리
0/6 lessons
객체지향의 말 하나하나가 Sizzle 스키마 어디에 내려앉는지
이 트랙은 도메인 모델을 코드로 봐. Sizzle 아키텍처 문서는 객체지향 용어 여섯 개를 요리 쪽 대상 여섯 개와 짝지어 두는데, 여기선 그 하나하나를 엔진 안까지 따라가. 원리, 요리, 변형은 kind 칸을 둔 classes 테이블 하나를 같이 써. 역할은 원리의 인터페이스고, 요리는 그걸 바인딩으로 채우고, 변형은 오버라이드로 바꿔. 그리고 진짜 접시 하나인 만남이 Sizzle이 붙잡는 유일한 대상이야. 다중 상속은 조인 테이블에 담겨. 원리 둘이라는 상한은 읽기 안의 요리 항목 하나의 몫이고, 간선은 쌓이기만 해. 증거는 읽는 순간 계산해서 inferred, encountered, cooked 중 하나가 돼. 제안은 아빠가 채택하거나, 이름을 바꾸거나, 접시를 이어야 비로소 아빠 것이 되고. 정확한 양은 두 클라이언트 모두 누가 열기 전까지 닫아 둬. 화면에선 가려도 응답엔 그대로 실려 있긴 해. OO Quest의 트랙 4는 이미 맛의 축으로 요리를 읽었어. 이 트랙은 Sizzle이 왜 기법으로 잘랐는지, 그리고 비유가 어디서부터 어긋나는지 보여줘.
Lesson list (6)
퀴즈 · 4 문제→
03📸사진 한 장에서 원리 하나로
0/6 lessons
접시 사진 한 장이 피파 자기 목소리로 된, 검증된 읽기가 되기까지
Sizzle이 사진을 두고 묻는 순간부터 검증된 읽기가 저장되는 순간까지, 이 트랙은 접시 사진 한 장을 따라가. 묻는 말은 루브릭이야. 파이썬 문자열 하나가 누가 읽는지 정하고, 원리와 요리와 형제라는 객체지향 틀을 주고, 내 말투를 정하고, JSON 모양을 그리고, 규칙을 늘어놔. 접시 자체는 데이터로만 따라가고, 절대 지시가 되지 않아. 말투가 왜 스키마처럼 버전을 다는지도 볼 거야. 버전을 단 덕분에, 읽기가 어떻게 들려야 하는지 정한 아빠의 판정이 이미 읽은 접시에까지 닿았어. 답을 받는 쪽엔 세 가지가 있어. 뭐가 따라붙든 첫 JSON 객체만 남기는 파서, 빠진 필드는 봐주고 틀린 타입은 거부하는 pydantic 모델, 흔들리는 단어를 중립값에 내려앉히는 닫힌 어휘. 호출 자체도 따라가. 내 영혼을 앞에 세우고, 읽기 슬롯이 고른 두뇌로, cwkPippa의 유틸리티 레인을 거쳐 가는 길이야. 마지막은 그 모든 걸 돌리는 워커야. 타이머는 없고, 한 번에 둘씩 읽고, 실패하면 닫힌 쪽으로 멈춰. 워커 스스로 하는 재시도도 없어. 실패한 접시는 아빠가 'Read again'(다시 읽기)을 누르거나 그 접시를 고칠 때만 돌아와.
Lesson list (6)
퀴즈 · 4 문제→
04🌳트리 키우기
0/6 lessons
접시 하나가 새 요리를 끌어내는 법, 그리고 누구 말이 이기는지
사진 한 장이 읽기가 되면 그 읽기가 기록에 뭘 하는지, 이 트랙은 그걸 다뤄. 출발점은 integrate야. 피파가 검증한 답을 class.proposed, class.parented, class.linked 이벤트로 바꾸는 평범한 파이썬이지. 원리와 요리는 먼저 id로 찾고, 안 되면 정규화한 이름으로 찾아. 새로 제안하는 건 아무것도 안 맞을 때뿐이야. 이어서 Sizzle을 그냥 먹은 기록 이상으로 만드는 부분을 볼 거야. 형제는 같은 원리를 물려받은 다른 요리권의 요리야. 진짜 클래스로 저장되지만, 그 요리의 접시가 하나 이어지기 전까진 피파의 추정으로 읽혀. 밖에서 먹었든, 시장에서 봤든, 집에서 만들었든 상관없어. 같은 요리를 두 번 먹어도 클래스가 하나로 남는 이유와, 그 맞추기가 멈추는 지점도 다뤄. 새 읽기가 뭘 고쳐 쓸 수 있는지는 주인이 누구냐로 정해져. 피파는 자기 제안만 새로 고쳐. 클래스를 아빠 것으로 만드는 건 아빠의 채택, 이름 바꾸기, 접시 잇기뿐이야. 지금 읽기의 링크만 세는 뷰가 하나 있어서, 다시 읽어도 루브릭 버전을 올려도 접시는 안 바뀌어. 마지막은 아빠의 정정이야. 바로 보이고, 다시 읽을 때마다 같이 실려 가고, 보장이 어디서 끝나는지도 숨기지 않아.
Lesson list (6)
퀴즈 · 4 문제→
05📓저널이 곧 기록
0/5 lessons
덧붙이기만 하는 파일 하나가 진실이고, 데이터베이스는 시작할 때마다 거기서 다시 지어져
Sizzle의 접시, 읽기, 정정, 채택은 전부 덧붙이기만 하는 JSONL 저널에 먼저 한 줄로 들어가. 라우트가 읽는 SQLite 데이터베이스는 미러일 뿐이고, 시작할 때마다 지워졌다가 재생으로 다시 지어져. 이 트랙은 그 뼈대를 코드로 따라가. 먼저 하나뿐인 쓰기 길 Sizzle.record와, 저널이 먼저인 이유를 볼 거야. 이어서 재생이 찢어진 마지막 줄은 봐주고 다른 손상엔 멈추는 방식을 봐. 그 봐주기가 조용히 끝나는 자리는 임시 폴더에서 직접 재 봤어. 그다음은 다시 짓기 자체야. 마이그레이션이 왜 없는지, 코드에서 센 이벤트 타입 17개가 미러에 각각 뭘 하는지 다뤄. 멱등 저장에선 클라이언트가 만든 요청 id를 왜 세 번 확인하는지 봐. 마지막 확인은 네트워크 재시도 하나가 재생 못 하는 저널로 번지는 걸 막아. 끝은 사진이야. 원본은 통째로 지키고, 파생 사본은 EXIF 없이 저장하고, 폰 업로드는 e5d76ff 이후 EXIF를 지켜. 스테이징으로 먼저 올라온 사진을 접시가 차지했다가 풀어 주는 과정도 봐.
Lesson list (5)
퀴즈 · 4 문제→
06💬피파랑 말하되, 쓰게 두진 않기
0/5 lessons
피파한테 맥락은 데이터로 건네고, 피파의 변경은 제안으로 받고, 쓰는 건 아빠 버튼만 하는 cwkPippa 클라이언트
이 트랙은 cwkPippa의 클라이언트인 Sizzle을 봐. 접시마다, 클래스마다 스레드가 하나씩 있고 부엌에도 하나 있어. 스레드 하나는 cwkPippa의 평범한 대화 하나야. 코드는 Sizzle 자기 키에서 클라이언트 id를 끌어내 대화를 묶고, 자격 증명 없이 루프백으로 닿아. 턴은 도구와 셸을 끈 채 보통 채팅 라우트에서 돌고, 시스템 프롬프트에 덧붙이는 글 하나를 싣고 가. 그 글엔 객체지향 틀, 말투, 몸 상태는 아빠가 말할 때만 다룬다는 규칙, 액션 계약이 들어가. 턴마다 새로 지어서 데이터라고 표시한 아빠 트리도 같이 들어가고. 피파는 답 끝에 타입 있는 sizzle-actions를 달 수 있어. 엔진은 피파가 제안할 때 검증해서 통과한 것만 남기고, 아빠가 버튼을 누를 때 한 번 더 검증해. 버튼이 보내는 건 턴 id와 인덱스뿐이야. 부엌에선 집에 있는 재료를 아빠 트리 원리들의 역할 목록에 대 봐. 두뇌 슬롯 셋은 저마다 가족 값 하나를 들고 있어. 재시작에 끊긴 턴은 요청 id로 답을 되찾거나 실패로 남기고, 두 번 보내는 일은 없어.
Lesson list (5)
퀴즈 · 4 문제→
07📱클라이언트 둘, 엔진 하나
0/6 lessons
같은 라우트를 읽는 웹 페이지와 아이폰 앱, 보내기 전에 먼저 저장하는 폰, 아무도 타이핑하지 않는 주소
Sizzle은 얼굴이 둘이고 엔진은 하나야. 웹 클라이언트는 엔진이 직접 내주는 React 페이지고, 아이폰·아이패드 앱은 네이티브 SwiftUI야. 둘 다 같은 라우트를 읽고, 같은 와이어 모양을 각자 옮겨 적고, 피파한테 직접 뭘 묻는 일은 없어. 읽기도 답도 전부 엔진이 가져오고, 엔진은 루프백으로 cwkPippa에 닿아. 폰이 cwkPippa를 직접 부르는 건 딱 하나, 열려 있는 호스트 프로필 문서를 읽을 때야. 거기엔 배치 정보만 있고 두뇌는 없어. 이 트랙은 그 둘 사이의 이음매를 따라가. 라우트 목록과 타입을 가진 클라이언트 두 개를 읽고, 폰에 없는 웹 화면을 숨기지 않고 밝혀 둔 자리도 짚어. 웹이 가족 Sidekick 안에 Sizzle 자기 대화 페이지를 끼워 넣는 방식도 보고, 폰이 네트워크를 부르기 전에 접시를 자기 저장소에 먼저 커밋하는 방식도 봐. 사진이 왜 이제 한 장에 요청 하나씩 올라가고, 바이트를 세며 바뀌는 진행 줄이 왜 붙는지도 봐. 이어서 느린 읽기가 덮어쓸 수 없는 기기 사본, 그걸 지키는 티켓과 세대 번호, 마지막으로 폰이 호스트 이름 대신 가족 레지스트리에서 받아 오는 엔진 주소까지 가. 일반론은 swift-quest랑 sibling-kit-quest가 맡고, 이 트랙은 Sizzle의 구체적인 모양만 다뤄.
Lesson list (6)
퀴즈 · 4 문제→
08🚢돌리고 내보내기
0/4 lessons
서비스 호스트의 프로세스 하나, 설치 스크립트 하나, 두뇌 대역, 그리고 폰을 위한 네 가지 사실
이 트랙은 Sizzle이 어떻게 돌고 어떻게 나가는지 다뤄. 일반론은 다른 퀘스트에 맡기고 Sizzle의 실제 모양만 볼 거야. 먼저 모든 걸 쥔 프로세스 하나야. KeepAlive가 걸린 launchd 작업이 python -m backend.serve를 띄우고, 엔진은 켜질 때마다 저널로 미러를 다시 지어. 그 뒤로 두뇌 슬롯을 선언하고, 읽기 워커를 켜고, 끝나지 않은 대화 턴을 이어받는 순서가 정해져 있어. 두 번째는 설치 스크립트야. 킷 템플릿에서 생성된 파일인데, 엉뚱한 Mac에서는 아예 시작을 안 해. 포트와 주소는 가족 레지스트리한테 묻고, launchd plist는 이 Mac에 맞게 렌더링하고, 예전 작업이 다 내려갈 때까지 기다린 다음, HTTPS 쌍둥이를 열어. 세 번째는 테스트야. FakePippa와 FakeCentral이 두뇌와 가족 두뇌 권한자 자리를 대신하고, 엔진을 다루는 테스트마다 임시 디렉터리 위에서 진짜 엔진이 부팅돼. 벤더링한 파일을 손으로 고치면 드리프트 검사가 스위트를 빨갛게 만들어. 마지막은 폰이야. 앱 안에서 도는 테스트 관문이 있고, 앱의 사실만 설정 파일에 둔 파이프라인이 하나 있어. 빌드는 19번까지 올라갔고, TestFlight 사실 네 개는 따로 세. 보이는 버전은 cwk-product.json에 적힌 하나뿐이야.
Lesson list (4)
퀴즈 · 4 문제→

이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

🔔 답글 알림 (로그인 필요)

로그인 — 댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.

Tracks

01🍳인스턴스 말고 클래스

02🍳객체 모델로 본 요리

03📸사진 한 장에서 원리 하나로

04🌳트리 키우기

05📓저널이 곧 기록

06💬피파랑 말하되, 쓰게 두진 않기

07📱클라이언트 둘, 엔진 하나

08🚢돌리고 내보내기