01 단일 화면을 넘어선 가치: 프랜차이즈 운영 의사결정 서비스로의 확장 기능 수가 아니라 점주·본사 슈퍼바이저·고객의 서로 다른 판단을 연결하는 사용자 흐름으로 제품 범위를 정하는 과정을 이해한다. 프로젝트 문서 · 코드 · 테스트
02 리더십 인계 뒤 '보이지 않던 일'을 드러낸 과정 리더십을 말하는 사람의 직책이 아니라 담당자·기한·현재 상태·완료 조건·결정 이유가 보이는 운영 장치로 이해한다. 프로젝트 문서 · 코드 · 테스트
03 R&R: 영역 이름표에서 '작업 계약'으로 R&R은 영역 이름표가 아니라 수행 가능한 크기의 작업, 필요한 입력, 기대 출력, 검증 가능한 완료 기준까지 포함해야 한다는 점을 이해한다. 프로젝트 문서 · 코드 · 테스트
04 개별 기능 완성을 넘어선 통합적 MVP 판단 MVP 완료를 기능별 실행 여부가 아니라 동일한 계약과 환경에서 사용자 흐름이 끝까지 통과하는지로 판단한다. 프로젝트 문서 · 코드 · 테스트
05 JSON을 넘어선 API 계약: 의미, 시간, 품질, 규칙, 그리고 협의의 기술 서비스 계약은 필드 목록뿐 아니라 값의 의미, 시간 기준, 품질 상태, 중복 저장과 변경 절차까지 포함한다는 점을 이해한다. 프로젝트 문서 · 코드 · 테스트
06 OrderEvent 상태 이력 집계 기준 변경 과정: 정확한 주문 건수 KPI 찾기 상태 변경 이벤트의 수와 비즈니스 개체의 수를 구분하고, 주문 접수 시점과 고유 order_id를 기준으로 기간 KPI를 계산하는 이유를 이해한다. 프로젝트 문서 · 코드 · 테스트
07 읽기 패턴에 따른 다층적 데이터 저장 구조 설계 실시간 조회, 분석용 표본, 장기 집계와 원본 보관은 서로 다른 읽기 패턴과 비용을 가지므로 저장 계층을 분리해야 한다는 점을 이해한다. 프로젝트 문서 · 코드 · 테스트
08 24시간·7일·30일, KPI를 위한 시간 계약의 비밀 조회 구간의 포함 규칙, 표시 시간대와 집계 interval을 API 계약으로 고정해야 서로 다른 기간을 공정하게 비교할 수 있음을 이해한다. 프로젝트 문서 · 코드 · 테스트
09 삭제 매장의 과거 이력은 남기고 본사 운영 집계에서는 제외한 다매장 경계 설계 운영 대상의 활성 여부와 감사·분석용 과거 이력의 보존 여부를 분리해 다매장 집계 경계를 설계하는 방법을 이해한다. 프로젝트 문서 · 코드 · 테스트
10 숫자가 모두 같아 보이지 않게: 데이터 Provenance 설계 데이터가 만들어진 방식과 저장 여부를 source·ID·표시 문구에 남겨 데모 결과를 실제 실적으로 오해하지 않게 하는 provenance 설계를 이해한다. 프로젝트 문서 · 코드 · 테스트
11 YOLO 인원 계수를 카메라별 Precision·Recall·MAE로 다시 읽은 평가 모델 이름이나 단일 정확도 대신 카메라 구도, 유리·밀집·배경 조건과 Precision·Recall·인원 MAE를 함께 보고 측정 가능 범위를 판단한다. 프로젝트 문서 · 코드 · 테스트
12 ROI: 화면 장식에서 운영 인원 측정 정책으로 탐지 결과와 운영 지표 사이에는 업무 목적에 맞는 공간 경계가 필요하며 ROI가 그 측정 정책을 명시한다는 점을 이해한다. 프로젝트 문서 · 코드 · 테스트
13 영상 추적: 파일 경계와 장면 전환 사이의 오해 저장 파일의 경계와 현실 장면의 경계를 구분하고, 시각 변화와 시간 간격을 근거로 tracking continuity를 유지하거나 끊는 방법을 이해한다. 프로젝트 문서 · 코드 · 테스트
14 카메라별 맞춤 규칙으로 직원 판정 정확도 높이기 동일한 업무 개념도 카메라 구도와 가림 양상이 다르면 관측 규칙을 분리하고, 설정 구간과 held-out 검증 구간도 나눠야 함을 이해한다. 프로젝트 문서 · 코드 · 테스트
15 ROI 설정, 왜 저장만으로는 안 될까요? 견고한 데이터 분석 시스템을 위한 라이프사이클 측정 설정은 저장·승인·적용·재분석의 lifecycle을 가지며 결과에는 어떤 설정 버전으로 계산됐는지 남겨야 함을 이해한다. 프로젝트 문서 · 코드 · 테스트
16 대시보드 KPI와 분석 이미지가 서로 다른 프레임을 보여주던 동기화 장애 해결 사례 분산된 최신값 두 개는 같은 사건을 뜻하지 않으며, 공통 프레임 신원과 전송·표시 순서가 있어야 사용자가 수치의 근거를 믿을 수 있음을 이해한다. 프로젝트 문서 · 코드 · 테스트
17 탐지 수치가 좋아도 장기 Tracking 모델을 바로 채택하지 않은 성능 게이트 탐지 정확도, 인원 오차, 추적 ID 연속성, 처리 안정성은 서로 다른 채택 조건이며 서비스 기능별 합격선을 먼저 세워야 함을 이해한다. 프로젝트 문서 · 코드 · 테스트
18 Digital Twin, 눈에 보이는 전부가 아니다: 범위 정의의 기술 시각적 인상보다 센서 범위와 좌표 근거를 기준으로 Digital Twin이 재현하는 대상과 재현하지 못하는 대상을 명시하는 방법을 이해한다. 프로젝트 문서 · 코드 · 테스트
19 2.5D Scene 구성 규칙: CCTV 투영의 한계를 넘어 읽을 수 있는 장면 만들기 카메라 투영 좌표를 화면 배치로 옮길 때 발점, 원근 곡선, anchor와 z-order가 각각 어떤 시각적 오류를 막는지 이해한다. 프로젝트 문서 · 코드 · 테스트
20 AI Scene 초안과 인간 승인 경계 설계 생성된 초안의 존재와 운영 설정으로 채택 가능한 품질을 구분하고, 사람이 수정·승인하는 경계를 설계하는 방법을 이해한다. 프로젝트 문서 · 코드 · 테스트
21 비동기 분산 온보딩 구조의 비밀: 왜 이렇게 복잡해야만 할까? 대용량 업로드, CPU 서비스와 GPU 작업, 긴 처리 시간과 재시작 복구를 서로 다른 책임으로 분리하는 비동기 온보딩 구조를 이해한다. 프로젝트 문서 · 코드 · 테스트
22 Firebase 클레임 기반 다매장 권한 분리: 본사/점주 인증된 신원과 허용된 자원을 구분하고, 토큰 claims와 서버 자원 검사를 함께 사용해 다매장 권한 경계를 세우는 방법을 이해한다. 프로젝트 문서 · 코드 · 테스트
23 인증 경계: 사용자, Worker, 로컬 개발 모드 사람 사용자와 내부 생산자의 신원·수명·배포 위치가 다르므로 별도 인증 수단을 사용하고, 로컬 우회도 운영 설정과 분리해야 함을 이해한다. 프로젝트 문서 · 코드 · 테스트
24 Firebase 계정과 매장 자원: 독립된 생명 주기를 관리하는 법 외부 identity provider와 내부 domain resource가 서로 다른 원본일 때 생성·변경·삭제의 순서와 보존 정책을 명시하는 방법을 이해한다. 프로젝트 문서 · 코드 · 테스트
25 샘플 JSON에서 매장별 운영 데이터로: 시스템 변화의 본질 고객 응답과 주문 생성에 쓰이는 정보는 샘플 콘텐츠가 아니라 매장별 수정 권한·상태·격리를 가진 운영 데이터여야 함을 이해한다. 프로젝트 문서 · 코드 · 테스트
26 모르는 질문에 억지로 답하지 않는 Agent 설계 도구가 제공하는 근거 범위와 질문 의도를 맞추고, 근거가 없는 질문은 명시적으로 거절하는 Agent contract를 이해한다. 프로젝트 문서 · 코드 · 테스트
27 RAG 기반 정책 검색 및 Fallback 구현 질문과 관련된 정책만 근거로 좁히되 검색 계층의 할당량·실패가 고객 답변 전체를 중단하지 않도록 fallback을 설계하는 방법을 이해한다. 프로젝트 문서 · 코드 · 테스트
28 공용 Kakao 채널, 다매장 컨텍스트를 어떻게 라우팅하는가? 채널 배포 단위와 대화의 매장 context를 분리하고, 명시적 링크·사용자 세션·선택 UI의 우선순위로 routing하는 방법을 이해한다. 프로젝트 문서 · 코드 · 테스트
29 챗봇, 대략적인 답변이 아닌 '신뢰'를 말하기까지 자연어 채널도 별도 숫자를 만들지 않고 공통 KPI와 대화 history를 사용하며, 모델 실패 때도 채널 규격 안에서 일관된 안내를 반환해야 함을 이해한다. 프로젝트 문서 · 코드 · 테스트
30 합성 주문 Worker와 What-if Simulator: 목적이 다른 '가짜'의 설계 현재 데모 상태를 공급하는 생산자와 미래 조건을 비교하는 분석기를 목적·lifecycle·저장 정책으로 구분한다. 프로젝트 문서 · 코드 · 테스트
31 평균으로는 알 수 없는 매장 운영의 비밀: 이산사건 시뮬레이션으로 밝히다 대기열·자원 경합·포기·좌석처럼 순서와 상태 변화가 결과를 바꾸는 운영 문제를 event 기반으로 모델링하는 이유를 이해한다. 프로젝트 문서 · 코드 · 테스트
32 직원 수 효과 측정을 위한 시뮬레이션 조건 통제 대안 비교에서는 바꾸려는 변수 외의 수요와 고객 속성을 통제해야 결과 차이를 staffing 효과로 해석할 수 있음을 이해한다. 프로젝트 문서 · 코드 · 테스트
33 운영 목표 달성을 위한 최소 인원 탐색: 고정 비교의 함정을 넘어 비교안 중 승자를 고르는 것과 운영 목표를 만족하는 최소 feasible option을 찾는 것은 다르며, 목표 미달과 사람 승인을 함께 표현해야 함을 이해한다. 프로젝트 문서 · 코드 · 테스트
34 Agent와 서버의 공존: LLM 추천 시스템 아키텍처 이해하기 확률적 모델과 결정론적 도구의 책임을 분리해 LLM이 근거에 없는 숫자를 만들지 못하게 하고, 사람에게 검토 가능한 설명만 제공하는 구조를 이해한다. 프로젝트 문서 · 코드 · 테스트
35 Agent 작업 시각화: 투명성보다 신뢰성 사용자에게 필요한 관측 가능성과 비공개 reasoning을 구분하고, 공개 event schema와 turn limit으로 비용·무한 호출·과장된 trace를 통제하는 방법을 이해한다. 프로젝트 문서 · 코드 · 테스트
36 AI 시스템의 투명한 Fallback 설계 모델 의존 기능과 결정론적으로 계속할 수 있는 계산을 분리하고, fallback 출처를 공개해 장애 중에도 과장 없이 서비스를 유지하는 방법을 이해한다. 프로젝트 문서 · 코드 · 테스트
37 Docker Python 앱 충돌: 런타임 격리와 임포트 네임스페이스의 진실 runtime 격리와 source·test import namespace는 다른 경계이며, 서비스별 package 이름과 Compose DNS를 명시해야 함을 이해한다. 프로젝트 문서 · 코드 · 테스트
38 PostgreSQL을 공개하지 않고 미니PC API만 Tailscale로 공유한 팀 개발 환경 팀 개발에 필요한 surface만 private network에 열고 DB·비밀·통합 branch의 경계를 유지하는 공용 환경 구성을 이해한다. 프로젝트 문서 · 코드 · 테스트
39 Cloudflare 공개 시연 배포 구조 분석 공개 요청 경로, 상태 저장 서비스와 비용이 큰 GPU 작업을 latency·비용·하드웨어 조건에 따라 분리하는 배포 판단을 이해한다. 프로젝트 문서 · 코드 · 테스트
40 브랜치: 코드 이름표를 넘어선 '릴리즈 레일' branch를 코드 이름표가 아니라 대상 환경, 인증 경로, backup·migration·health를 묶은 release rail로 이해한다. 프로젝트 문서 · 코드 · 테스트
41 배포 'green' 신호, 무엇을 믿고 무엇을 의심할 것인가? 배포 인증의 secret 수명, DB revision 적용과 health check의 검증 깊이를 따로 확인하고, green 신호가 증명하지 못하는 범위를 읽는 방법을 이해한다. 프로젝트 문서 · 코드 · 테스트
42 테스트 성공 후 공개 화면 장애 진단 및 최종 QA 관측된 증상에서 소비자·API·저장소·생산자와 배포 version을 역추적하고, 수정 완료와 남은 한계를 구분해 최종 품질 증거를 만드는 방법을 이해한다. 프로젝트 문서 · 코드 · 테스트