Jantt 딥다이브
— JSON 일정표가 움직이는 화면이 되기까지

1프로젝트 한줄 요약

Jantt는 JSON으로 표현한 프로젝트 일정을 편집 가능한 간트 차트로 바꾸는 TypeScript 엔진입니다. 이름, 시작일, 종료일, 선행 작업을 입력하면 막대와 연결선을 계산하고, 사용자의 조작을 다시 일정 데이터로 돌려줍니다.

화면을 저장하는 대신 일정 데이터를 저장하면, 같은 계획을 여러 화면과 도구에서 다시 사용할 수 있습니다. 이 원리가 코어 라이브러리, React 래퍼, 일반 웹페이지용 번들, CLI를 하나로 묶습니다.

1-1. 읽을 수 있는 최소 일정

다음은 examples/basic.json의 구조를 줄여 만든 학습용 예시입니다. progress는 0~1 사이의 비율이고, dependsOn은 선행 작업의 ID입니다.

{
  "meta": { "title": "작은 웹사이트", "defaultGapDays": 2 },
  "categories": {
    "web": { "label": "웹 개발", "color": "#3B82F6" }
  },
  "tasks": [
    {
      "id": "design", "label": "화면 설계", "category": "web",
      "start": "2026-10-01", "end": "2026-10-03", "progress": 1
    },
    {
      "id": "build", "label": "화면 구현", "category": "web",
      "start": "2026-10-02", "end": "2026-10-06",
      "dependsOn": "design", "progress": 0.25
    }
  ]
}

이 데이터에는 “설계가 끝나기 전에 구현이 시작된다”는 충돌이 있습니다. resolveSchedule()의 기본 간격 2일을 적용하면 구현 시작일은 10월 5일, 종료일은 10월 9일이 됩니다. 시작일과 종료일의 차이인 4일은 유지됩니다.

1-2. AI가 들어가는 자리는 어디인가

README의 “AI-native”는 모델이 엔진 안에서 추론한다는 뜻이 아닙니다. 외부 AI가 JSON을 만들고, 엔진이 검증·계산·표시를 맡는 사용 방식을 강조합니다. packages/core/src/validator.ts에는 오류 위치와 수정 제안이 있어 재생성 흐름에 활용할 수 있습니다.

2왜 주목받는가

2-1. AI가 만들기 쉬운 입력 형식

TrendShift Weekly #23의 선정 대상이며, 2026년 8월 28일 생성 후 10월 23일 기준 스타 3,571개입니다. 이 수치는 관심의 크기를 보여주지만, 서비스 채택 수나 알고리즘의 정확성을 뜻하지는 않습니다.

주목 요인으로 읽을 수 있는 것은 AI가 일정 내용에 집중할 수 있는 데이터 계약입니다. 모델이 SVG 좌표와 이벤트 처리 코드를 매번 생성하는 대신, 정해진 JSON 필드만 채우게 합니다. 이는 소스 구조와 README의 제품 방향에 근거한 해석이며, 실제 유입 경로를 측정한 결과는 아닙니다.

AI가 만든 계획을 믿는 근거는 그럴듯한 화면이 아니라, 입력 검증과 명시적인 계산 규칙이어야 합니다. Jantt는 이 경계를 코드로 살펴보기에 좋은 규모의 사례입니다.

2-2. 한 데이터에서 여러 사용 방식으로

2-3. 경쟁 도구와 비교할 때 볼 기준

아래 표는 입력 방식과 학습 목적의 비교입니다. 경쟁 제품의 기능·크기·가격을 일괄 평가한 표는 아닙니다. Jantt의 장점은 JSON 계약, 일정 계산, UI 연결을 같은 저장소에서 함께 읽을 수 있다는 점입니다.

입력 방식의 근거: Mermaid 공식 문서, Frappe Gantt 공식 문서, DHTMLX 공식 문서. DHTMLX도 JSON을 받으므로 “기존 도구는 JSON을 못 쓴다”는 비교는 맞지 않습니다.

2-4. README의 강한 표현을 읽는 법

홍보 표현을 걷어내도 학습 가치는 남습니다. 작은 입력 모델을 실제 제품의 여러 경계에 연결하고, 문서와 구현의 차이까지 점검하는 연습을 할 수 있기 때문입니다.

3기술 스택 전체 지도

3-1. 프론트엔드: 코어와 데모 앱을 구분하기

코어는 React 컴포넌트 트리가 아니라 TypeScript로 작성한 DOM/SVG 엔진입니다. React는 이를 감싸는 별도 패키지이며, Playground는 그 위에 편집기·노트·클라우드 UI를 얹은 앱입니다.

3-2. 백엔드: 기본 렌더링에는 별도 서버가 필요 없다

데이터베이스를 직접 운영하는 전통적인 API 서버가 중심인 구조는 아닙니다. 코어 렌더링은 브라우저에서 수행하고, 파일 저장·실시간 협업이 필요할 때 각각의 저장 경로를 연결합니다.

3-3. 인프라·빌드·검증 도구

packages/core/tsconfig.json은 target: ES2020, strict: true, moduleResolution: bundler, noEmit: true입니다. 타입 검사와 실제 파일 출력의 책임을 나눠, 번들 출력은 Vite가 맡습니다.

의존성 파일을 읽을 때는 실행용 코드, 개발 도구, 사용 앱이 공급할 패키지를 나눠 봐야 합니다. “코어가 작다”와 “전체 앱이 외부 패키지를 쓰지 않는다”는 서로 다른 주장입니다.

3-4. 배포 설정이 설명하는 제품 형태

• packages/core/vite.config.ts: ES module과 CommonJS를 생성하고 CSS 출력명을 theme.css로 지정합니다.
• packages/react/vite.config.ts: React와 코어를 external로 두어 래퍼 번들에 중복 포함하지 않습니다.
• packages/standalone/vite.config.ts: UMD·IIFE 형식으로 만들며 전역 이름은 Jantt입니다.
• .github/workflows/ci.yml: Node 20.x·22.x에서 설치 → 빌드 → 타입 검사 → 테스트 순서로 구성됩니다.
• .github/workflows/deploy-pages.yml: apps/playground/dist를 GitHub Pages에 배포합니다.
• Dockerfile: node:20-alpine 빌더와 nginx:alpine 정적 서버를 분리합니다.

루트 lint 스크립트는 성공 문구를 출력하는 명령입니다. 실제 정적 분석을 수행하는 린터가 아닙니다. 보안 워크플로의 npm audit도 continue-on-error: true이므로 실패가 배포 차단을 보장하지 않습니다.

4아키텍처 심화 분석

4-1. 전체 시스템의 데이터 흐름

아래에서 검증은 입력을 받는 쪽이 명시적으로 호출하는 경계입니다. renderJantt()가 내부에서 항상 validate()를 호출한다고 가정하면 안 됩니다. 이 함수는 엔진을 만들고 mount()를 호출합니다.

packages/core/src/rendering/jantt-engine.ts의 render()는 먼저 전체 작업의 CPM을 구합니다. 그 다음 표시할 작업을 필터링하고, 계산한 결과를 layout()에 넘깁니다. 검색 때문에 선행 작업이 숨겨져도, 분석의 기준 그래프는 전체 일정으로 유지하려는 설계입니다.

일정을 계산하는 코드와 화면에 보일 작업을 고르는 코드는 서로 다른 책임입니다. 화면에 보이는 데이터만으로 모든 분석을 다시 하면 필터가 계산 결과까지 바꿔 버릴 수 있습니다.

4-2. 설계 패턴 ① 파이프와 필터

packages/core/src/pipeline/schedule-pipeline.ts의 SchedulePipeline.createDefault()는 작업 배열을 단계별 처리기에 통과시킵니다. 각 단계는 IPipelineStage.process(input, context) 계약을 구현합니다.

검증과 보정의 목적은 다릅니다. packages/core/src/validator.ts의 validate()는 문제를 보고하지만, SanitizeStage는 종료일이 시작일보다 빠르면 종료일을 시작일로 바꿉니다. 잘못된 원본을 사용자에게 알릴지, 자동으로 보정할지는 앱의 정책입니다.

// 사용 예시: CPM 단계는 파이프라인 생성 시 포함한다.
const pipeline = SchedulePipeline.createDefault({ includeCriticalPath: true });
const result = pipeline.execute(plan.tasks, {
  defaultGapDays: 2,
  breakCycles: false
});
// result.tasks, result.diagnostics, result.context를 각각 확인한다.

CycleGuardStage.process()는 Kahn 방식으로 진입 차수가 0인 작업부터 방문합니다. 삭제되지 않은 작업만 대상으로 하며, 방문 수가 대상 작업 수보다 적으면 순환 진단을 남깁니다. 기본값 breakCycles: false는 진단만 남기며, 뒤 단계를 중단하지 않습니다. true일 때는 남은 진입 차수가 양수인 작업의 의존성을 비웁니다.

연쇄 이동과 위상 정렬은 같은 알고리즘이 아니다

packages/core/src/resolver.ts의 resolveSchedule()는 CascadeResolveStage.process()에 위임합니다. 이 단계는 작업을 ID 맵으로 만들고 최대 MAX_PASSES = 24회 훑으며, 바뀐 작업이 없는 회차에서 멈춥니다.

// CascadeResolveStage의 규칙을 요약한 의사 코드
minStart = max(선행작업들의 end + 현재작업의 gapDays)
if (현재작업이 잠겨 있지 않고 start < minStart) {
  duration = end - start
  start = minStart
  end = start + duration
}

작업은 필요할 때 뒤로 밀리며, 선행 작업을 앞당겼다고 자동으로 앞으로 당겨지지는 않습니다. locked: true인 작업도 이동하지 않습니다. 잠금은 날짜 고정 정책이지, 모든 의존성 제약이 충족된다는 보장이 아닙니다.

문서 docs/algorithms.md에는 같은 카테고리 작업의 암묵적 순차 배치가 설명돼 있지만, 현재 연쇄 이동 단계는 명시적 dependsOn을 기준으로 움직입니다. 카테고리가 같다는 이유만으로 자동 순서를 기대하면 안 됩니다.

작업 배열이 의존성의 역순이고 연결이 매우 길면 여러 회차가 필요합니다. 24회 상한에 도달해도 별도 미수렴 진단을 추가하지 않으므로, 긴 연결망은 배열 순서와 제약 충족 여부를 별도로 검토할 대상입니다.

CPM: 앞으로 한 번, 뒤로 한 번

packages/core/src/cpm.ts의 calculateCriticalPath()는 선행·후속 작업 맵과 진입 차수를 만들고 위상 순서를 계산합니다. 앞에서 뒤로 가장 빠른 시작·종료일을, 뒤에서 앞으로 가장 늦게 허용되는 날짜를 구합니다.

// 코드의 계산 의미를 단순화한 식
ES = max(입력 start, 선행 작업의 EF + gap)
EF = ES + duration
LF = min(후속 작업의 LS - 후속 작업의 gap)
LS = LF - duration
TF = LS - ES

TF는 전체 완료 시점을 지키면서 미룰 수 있는 여유입니다. 구현은 tf <= 0 || tf === minTotalFloat를 중요 작업 판정에 사용합니다. 목표일 targetDate를 지정하면 음수 여유도 표현할 수 있습니다. CPM의 프로젝트 기본 간격은 0일로, 연쇄 이동의 기본 2일과 다릅니다. 렌더러도 CPM을 별도 간격 옵션 없이 호출합니다.

순환이 있으면 CPM은 위상 정렬에서 빠진 작업을 뒤에 덧붙여 계속 계산합니다. 이는 오류로 화면이 멈추는 것을 피하는 처리이며, 순환 그래프의 분석값이 올바르다는 뜻은 아닙니다.

4-3. 설계 패턴 ② 제스처 전략과 상태

packages/core/src/controller.ts의 InteractionController는 현재 드래그 상태와 선택된 작업을 관리합니다. 작업 이동·크기 변경·진행률 조절·의존성 연결·분할선 조절·영역 선택·화면 이동을 Map<DragMode, IGestureStrategy>에 등록한 일곱 전략으로 나눕니다.

packages/core/src/controller/contracts.ts는 전략에 onMove()와 onUp()을 요구합니다. MoveGestureStrategy.onMove()는 픽셀 차이를 날짜 차이로 바꾸고, onUp()은 실제 이동이 있었을 때 commitData()를 호출합니다.

// packages/core/src/controller/strategies/move-gesture.ts의 핵심 식
const deltaX = e.clientX - state.startX;
const deltaDays = Math.round(deltaX / ctx.dayWidth);

scheduleRender()는 이미 예약된 requestAnimationFrame이 있으면 추가 예약을 건너뜁니다. 많은 포인터 이벤트를 화면 갱신 시점에 모으는 기법입니다. 다만 날짜 계산·작업 검색 비용까지 사라지는 것은 아닙니다.

4-4. 설계 패턴 ③ React·일반 웹페이지 어댑터

packages/react/src/Jantt.tsx의 React 컴포넌트는 컨테이너와 엔진 인스턴스를 ref에 보관합니다. 첫 effect에서 renderJantt(), 갱신 effect에서 instance.update(), 정리 함수에서 destroy()를 호출합니다.

이벤트 콜백은 callbacksRef.current를 통해 전달합니다. 엔진을 처음 만들 때의 낡은 콜백이 이후에도 호출되는 오래된 클로저 문제를 피하려는 장치입니다. standalone은 같은 엔진을 Jantt.mount()로 노출합니다.

// React 연결 예시: 확정된 변경을 savePlan으로 전달한다.
import { Jantt } from "@jantt/react";
import type { JanttData } from "@jantt/core";
import "@jantt/core/theme.css";

type TimelineProps = {
  plan: JanttData;
  savePlan: (data: JanttData) => void;
};

function Timeline({ plan, savePlan }: TimelineProps) {
  return <Jantt data={plan} onCommit={savePlan} />;
}

코어의 export와 빌드 설정은 위 예시의 CSS 경로를 명시합니다. README 예제의 @jantt/react/dist/index.css는 React 패키지의 명시적 export에 없습니다. 실제 공개 API를 확인하는 습관이 복사한 예제의 실패를 줄입니다.

4-5. 설계 패턴 ④ 기준·로컬·원격의 병합

packages/core/src/reconciliation/plan-reconciler.ts의 reconcilePlans(base, local, remote)는 공통 기준과 두 변경본을 비교합니다. 작업 ID별 맵을 만들고, 필드 시각과 삭제 기록을 고려해 병합 데이터와 충돌 내역을 반환합니다.

packages/core/src/reconciliation/task-merger.ts의 PM_TASK_FIELDS가 병합할 필드 목록을 정합니다. 새 작업 속성을 추가할 때 타입 정의만 바꾸면 끝나지 않는 이유입니다. 저장·검증·병합·공유 경로가 같은 속성을 다루는지 함께 살펴야 합니다.

이 구현의 CRDT·LWW 설명을 “모든 변경을 손실 없이 보존한다”로 확대하면 안 됩니다. 같은 필드에서 한 값을 선택하는 정책은 다른 값을 덮어쓸 수 있으며, 필드별 시각·동률 처리·삭제 후 갱신까지 조건을 맞춰 검토해야 합니다.

5디렉토리 구조 해부

5-1. 초보자에게 권하는 읽기 순서

1. examples/basic.json: 작업 ID와 dependsOn을 종이에 화살표로 그립니다.
2. packages/core/src/types.ts: 필수·선택 속성과 데이터·뷰 옵션의 경계를 읽습니다.
3. packages/core/src/validator.ts, packages/core/src/date-math.ts: 잘못된 데이터가 어떤 오류가 되는지 봅니다.
4. packages/core/src/resolver.ts, packages/core/src/pipeline/stages/cascade-resolve-stage.ts: 날짜 이동 규칙을 추적합니다.
5. packages/core/src/layout.ts, packages/core/src/renderers/task-bars.ts: 숫자 좌표가 DOM으로 바뀌는 경계를 찾습니다.
6. packages/react/src/Jantt.tsx: 엔진의 생성·업데이트·해제 위치를 표시합니다.

apps/playground/src/App.tsx부터 시작하면 화면 옵션과 협업 상태를 동시에 만나기 쉽습니다. 핵심 모델을 먼저 익힌 뒤 앱으로 올라오면 각 hook이 어떤 책임을 받았는지 이해하기 편합니다.

5-2. 코드 규모를 읽는 기준

커밋 77f78de의 텍스트를 확장자별로 센 값이며 빈 줄·주석·설정을 포함합니다. Git 내부 파일과 설치된 패키지는 제외합니다. TS·TSX·JS 합계는 40,376줄이고, 테스트를 다시 더하면 중복 집계가 됩니다. 줄 수는 구현 범위를 가늠하는 지표이며 품질 점수가 아닙니다.

6학습 포인트 (기술별)

6-1. TypeScript와 JSON Schema: 타입은 입력 검증을 대신하지 않는다

packages/core/src/types.ts의 Task는 컴파일할 때 사용하는 약속입니다. 반면 파일이나 네트워크에서 받은 JSON은 실행 중에 들어옵니다. validate(json: unknown)가 unknown을 받는 이유가 여기에 있습니다.

schema/jantt.schema.json은 Draft-07 형식의 별도 명세입니다. 코어 검증기는 이 파일을 범용 검증기로 실행하지 않고, 직접 작성한 조건문으로 데이터를 검사합니다. 따라서 타입·스키마·검증기는 관련돼 있지만 자동으로 완전히 일치하지는 않습니다.

// 외부 입력을 검증하는 사용 예시
const raw: unknown = JSON.parse(text);
const result = validate(raw);
if (!result.valid) {
  for (const error of result.errors) {
    console.log(error.path, error.code, error.suggestion);
  }
}

실습 아이디어: 필수 속성, 잘못된 날짜, 없는 선행 ID를 한 가지씩 넣고 어떤 오류 코드가 나와야 하는지 먼저 표로 작성합니다. “JSON 문법이 맞다”와 “일정 의미가 맞다”를 구분하는 훈련입니다.

6-2. 날짜 연산: 하루 차이와 달력 칸 수

packages/core/src/date-math.ts의 isValidISODate()는 형식 검사 후 Date.UTC()로 만든 연·월·일을 원래 값과 대조합니다. 이 왕복 비교가 2026-02-30처럼 모양만 날짜인 값을 걸러냅니다.

diffDays()와 addDays()는 UTC 기준으로 계산합니다. 다만 “오늘” 표시에 쓰는 getTodayISODate()는 로컬 날짜를 사용하므로, 달력 연산과 사용자에게 보여 줄 현재 날짜를 구분해서 읽어야 합니다.

실습 아이디어: 같은 작업의 계산 기간과 표시 폭을 나란히 적습니다. 하루 차이를 무조건 오류로 판단하기 전에 각 함수가 사용하는 기간 정의를 확인합니다.

6-3. 그래프: 선행 작업을 빠르게 찾는 자료구조

packages/core/src/cpm.ts는 Map으로 작업·선행·후속 관계를 저장하고, Set으로 중요 작업 ID를 관리합니다. 배열을 매번 처음부터 찾는 방식과 ID 기반 조회 방식의 차이를 배울 수 있습니다.

Kahn 알고리즘 자체는 작업 수 V와 연결 수 E에 대해 선형 탐색을 목표로 합니다. 다만 여기서는 큐에 배열의 shift()를 쓰고, 중요 경로를 여러 갈래로 열거하는 코드도 있으므로 전체 함수의 모든 상황을 단순히 O(V + E)라고 단정하면 안 됩니다.

실습 아이디어: A·B가 끝나야 C를 시작하는 그래프에서 C의 진입 차수를 2로 적고, A와 B를 처리할 때 각각 1씩 줄여 봅니다. 이후 C → A를 추가했을 때 어떤 작업이 큐에 못 들어가는지 찾습니다.

6-4. DOM/SVG: 날짜가 픽셀이 되는 수학

packages/core/src/layout.ts의 일반 막대는 시작일까지의 날짜 차이에 dayWidth를 곱해 x를 구합니다. 종료일 칸까지 표시하려고 오른쪽 경계에는 하루를 더합니다. DOM 막대와 SVG 연결선은 계산된 TaskLayout과 DependencyLine을 소비합니다.

// 시작일 ≤ 종료일인 일반 막대의 좌표 관계를 단순화한 식
x = diffDays(chartStart, task.start) * dayWidth
right = (diffDays(chartStart, task.end) + 1) * dayWidth
width = max(right - x, 14)
centerY = rowIndex * rowHeight + rowHeight / 2

실습 아이디어: dayWidth = 10일 때 3칸짜리 막대 폭을 계산하고, 값을 20으로 바꿨을 때 날짜 데이터는 그대로인데 화면 폭만 두 배가 되는 이유를 설명합니다.

6-5. React와 상태: 변경 중·확정·정리의 경계

onChange는 변경 중 데이터를 전달할 수 있는 API이고, onCommit은 확정 저장 지점으로 사용할 수 있습니다. 실제 발생 시점은 제스처 전략과 호출 경로를 확인해야 합니다. 콜백 이름만으로 자동 저장을 기대하면 안 됩니다.

제스처 코드는 일부 작업 객체를 직접 수정합니다. 앱이 변경 객체를 React 상태로 돌려줄 때는 참조가 그대로라 갱신이 생략되지 않는지 살펴야 합니다. destroy()에서는 이벤트·예약된 프레임 같은 자원을 해제하는지도 읽습니다.

실습 아이디어: 콜백에 전달할 때 최신 함수 ref를 읽는 경우와, 첫 렌더의 함수만 캡처한 경우를 종이에 비교해 봅니다. 데이터 갱신과 엔진 재생성을 혼동하지 않는 것이 목표입니다.

6-6. 직렬화와 비용 지표: 숫자에도 전제가 있다

packages/core/src/share-coder.ts의 compressPlanToUrlPayload()는 정상 압축 경로에서 공유용 정리 → JSON → UTF-8 → DEFLATE → Base64URL 순서로 변환하며 z~ 접두어를 붙입니다. 압축 실패 시에는 접두어 없는 비압축 Base64URL로 대체할 수 있습니다. 압축은 내용을 숨기는 암호화가 아니므로 공유 링크의 접근 범위도 고려해야 합니다.

packages/core/src/evm.ts의 calculateEVM()는 예산·진행률로 계획 가치와 획득 가치를 계산합니다. 실제 비용이 없으면 예산과 진행률로 비용을 추정하고, 분모가 0인 SPI·CPI는 1로 둡니다. 따라서 보기 좋은 지표가 실제 비용 측정의 존재를 보장하지 않습니다.

입력값의 의미와 기본값을 설명할 수 있어야, 계산 결과도 올바르게 해석할 수 있습니다. 학습의 끝은 함수를 호출하는 데 있지 않고, 그 결과를 믿을 수 있는 조건을 말하는 데 있습니다.

7하드웨어 / 시스템 요구사항

공식 최소 CPU·RAM·디스크 수치는 명시돼 있지 않습니다. 학습용으로는 일반적인 노트북과 RAM 8GB 이상을 출발점으로 제안할 수 있지만, 이는 프로젝트가 보장하는 최소 사양이나 성능 측정 결과가 아닙니다.

AI가 JSON을 생성하는 역할을 외부에 두므로 차트 엔진 자체에 GPU나 로컬 모델 가중치가 필요하지 않습니다. 사용하는 AI 도구의 비용·환경 요구사항은 별도로 판단합니다.

7-1. 데이터 크기를 결정하는 것은 작업 수만이 아니다

작업 수, 의존성 수, 표시 기간, 하루 픽셀 폭이 함께 영향을 줍니다. packages/core/src/layout.ts는 전체 기간과 작업에 맞는 좌표를 만들고, 렌더러는 본문 영역을 다시 구성합니다. 대량 데이터에서 항상 일정한 반응 속도를 보장하는 구조로 단정하기 어렵습니다.

성능을 검토할 때는 작업 수와 연결 수, 날짜 범위, 한 번의 조작 비용을 함께 기록해야 합니다. 100개의 독립 작업과 100개의 촘촘한 의존성 그래프는 같은 입력 크기로 취급하기 어렵습니다.

7-2. 저장 기능의 환경 한계

LocalStorageService는 저장 실패 시 메모리 맵으로 우회하도록 작성돼 있습니다. 메모리 저장은 페이지를 닫으면 사라질 수 있으므로, 저장 API 호출 성공과 영구 보존을 같은 의미로 보면 안 됩니다.

Worker는 JANTT_ROOMS 바인딩이 있으면 저장소를 우선 조회하고, 결과가 없으면 메모리 방을 찾습니다. 현재 wrangler.toml에는 그 바인딩 선언이 없습니다. 메모리 방이나 캐시는 서로 다른 인스턴스와 재시작을 넘어 영속성을 보장하지 않습니다.

8직접 해볼 수 있는 실습 과제

아래 과제는 작은 학습용 데이터와 독립된 예제로 진행할 수 있습니다. 네트워크·인증이 필요한 기능은 뒤로 두고, 입력과 기대 결과를 명확히 정의하는 데 집중합니다.

정상 입력과 함께 경계 입력을 설명해 보면 시스템을 더 깊이 이해할 수 있습니다.

9관련 기술 심화 학습 로드맵

주당 3~5시간 정도의 학습 계획입니다. 시간은 학습용 제안이며, 매주 “어떤 입력을 받으며 어떤 출력을 보장하는가”를 자기 말로 설명하는 결과물을 남깁니다.

표의 코어 계산 모듈은 packages/core/src/ 아래에 있습니다. 3주차에서 순환 탐지와 자동 보정의 차이를 설명하기 어렵다면, 작업 수를 줄여 종이 위에서 의존성 화살표를 다시 그리는 것이 좋습니다.

공부 순서는 데이터 계약에서 시작해 계산, 화면, 저장의 경계를 하나씩 넓히는 편이 이해하기 쉽습니다. 같은 기능을 여러 도구로 구현하는 것보다, 한 기능이 경계를 넘을 때 생기는 문제를 기록해 보세요.

9-1. 관심 분야에 따른 다음 갈림길

• 프론트엔드: DOM을 다시 만드는 비용, 포인터 캡처, 키보드 접근성, 가상화가 필요한 조건을 살펴봅니다. jsdom 테스트와 실제 브라우저 동작 검증의 역할도 나눕니다.
• 알고리즘: 반복 완화와 위상 순서 처리를 같은 입력으로 비교하고, 영업일 달력·휴일·여러 의존성 종류를 지원하려면 모델이 어떻게 변해야 할지 설계합니다.
• 백엔드·협업: 파일 저장, Firebase 트랜잭션, Worker 방 API의 일관성 경계를 비교합니다. revision 비교가 있다는 사실만으로 여러 요청의 원자성이 보장되는지 따져 봅니다.
• AI 도구: 생성 → 검증 → 오류 설명 → 재생성의 반복을 설계합니다. 통과 여부뿐 아니라 원래 요청과 일정 내용이 일치하는지도 사람이 판단할 지점을 둡니다.

10핵심 키워드 사전

11참고 링크

11-1. 프로젝트와 코드 근거

• 공식 GitHub 저장소 — 소개와 프로젝트 진입점.
• 분석 기준 커밋의 전체 소스 — 문서의 코드 경로를 확인할 고정 기준.
• 아키텍처 문서 · 알고리즘 문서 — 일부 설명은 현재 구현과 차이가 있음.
• API 문서 · JSON Schema 원본.
• 연쇄 이동 구현 · CPM 구현.
• React 어댑터 · CLI 구현.
• 협업 병합 구현 · 의존성 잠금 파일.
• 공식 Playground — 브라우저 편집 UI.
• TrendShift의 Jantt 페이지 — 트렌딩 맥락 참고.

11-2. 관련 기술의 공식 학습 자료

• TypeScript 기본 타입 — 객체·배열·선택 속성부터 익히기.
• JSON Schema 안내 — 데이터 형식의 계약을 표현하는 방법.
• React useEffect · useRef — 외부 엔진 연결과 정리.
• MDN Pointer Events · requestAnimationFrame — 입력 이벤트와 화면 갱신.
• Vite 라이브러리 모드 — 앱 빌드와 라이브러리 배포의 차이.
• Vitest 안내 — 테스트 파일의 구조를 이해하는 출발점.
• Firebase 데이터 읽기·쓰기 — 트랜잭션과 구독의 공식 설명.
• Cloudflare Workers 문서 — 프록시 실행 환경과 저장 경계.

11-3. 현재 상태 (GitHub 정보는 2026-10-23 기준)