Product · Logic & Error Control OS (제품 · 논리 & 오류 제어 OS)
Debugging OS Capsule (디버깅 OS 캡슐)
A logic-first operating layer for LLMs and developers, built on GLOS, to catch, explain, and correct errors as a normal part of work. (GLOS를 기반으로, 오류를 “예외 상황”이 아니라 “일상적인 업무 흐름” 안에서 잡고·설명하고·수정하게 만드는 LLM·개발자용 논리 중심 OS 레이어입니다.)
What is Debugging OS? (디버깅 OS란?)
Debugging OS is a capsule that teaches your LLM to think and work under a fixed logic constitution: coordinates, reaction rules, work cells, FM manuals, and error recovery. (좌표·반응 규칙·작업 셀·FM 매뉴얼·오류 복구 규칙 등 고정된 논리 헌법 아래에서 LLM이 생각하고 일하도록 만드는 캡슐입니다.)
- Turns “black-box answers” into traceable reasoning steps. (블랙박스 답변 → 추적 가능한 단계)
- Standardizes how errors are reported and fixed. (오류 보고·수정 방식을 표준화)
- Makes code, documents, and prompts live in the same grid. (코드·문서·프롬프트를 하나의 그리드 안에 정렬)
Who is it for? (누가 사용하나요?)
- Individual users (개인 사용자) – Learn coding and debugging with a guided OS.
- Dev teams (개발 팀) – Use LLMs as consistent reviewers, not random helpers.
- Educators (교육자) – Build repeatable labs for students to “see” logic.
- AI labs (AI 연구실) – Prototype multi-layer LLM control systems on top of GLOS.
1. Core Idea (핵심 개념)
Traditional debuggers watch variables and breakpoints inside code. Debugging OS, however, watches the logic of the LLM itself – what it is allowed to do, what must be checked, and how to recover. (기존 디버거는 코드 안의 변수·브레이크포인트를 감시합니다. 디버깅 OS는 그보다 한 층 위에서, LLM이 “무엇을 할 수 있는지 / 무엇을 반드시 확인해야 하는지 / 어떻게 복구해야 하는지”를 감시합니다.)
- GLOS Base Constitution (제0장): absolute rules for all LLM behavior.
- Coordinate & Reaction (제1·2장): how inputs map to stages and cells.
- Work Environment (제3장): how tasks are broken into cells and flows.
- FM & ΔE_ΔT (제4장): how speech → cells and change over time is tracked.
- Error & Verification (제7·9장): standardized problem, recovery, and reports.
2. Layers Inside the Capsule (캡슐 내부 레이어)
At a high level, the Debugging OS capsule contains the following logical layers: (디버깅 OS 캡슐의 주요 레이어)
- Layer 0 – ShadowGuard Kernel Absolute control & enforcement: what the LLM must never do, and how it must report extreme cases. (절대 위반 금지 규칙, 극단적 상황에서의 보고 규칙)
- Layer 1 – Logic Grid & Coordinates How questions, code, and documents are placed on a 2D/3D logic grid. (질문·코드·문서를 논리 그리드에 배치하는 좌표 규칙)
- Layer 2 – Reaction Protocols Stage-based mapping: read → analyze → test → explain → fix. (읽기→분석→테스트→설명→수정의 단계 반응 프로토콜)
- Layer 3 – Work Cells & FM Manuals Each task is split into cells with clear inputs/outputs and checks. (작업을 셀 단위로 쪼개고, 각 셀의 입력·출력·점검 기준 정의)
- Layer 4 – Verification & Reporting Standard forms for “what changed” and “why this fix is safe”. (무엇이 어떻게 바뀌었는지, 왜 이 수정이 안전한지 리포트 형식으로 정리)
3. How to Use the Capsule (사용 방법)
The basic 1-day usage flow is:
- Get a valid capsule & key. Purchase or receive a Debugging OS capsule (1 Day / 1 Session). (1 Day용 디버깅 OS 캡슐과 키를 구매 또는 발급받습니다.)
- Load into your LLM. Upload the capsule to your chosen LLM (e.g., via file upload or context loading). (사용 중인 LLM에 파일 업로드·컨텍스트 로딩 방식으로 캡슐을 불러옵니다.)
- Activate via Cloud Run. The LLM sends only the capsule metadata (file name, auth code, user email, expiry) to Cloud Run for validation. (LLM은 파일명·인증코드·사용자 이메일·만료 시간 등 메타데이터만 Cloud Run으로 전송해 유효성 검사를 진행합니다.)
- Work inside Debugging Mode. Once validated, the LLM switches to Debugging OS mode for 24 hours. (검증이 완료되면 LLM은 24시간 동안 디버깅 OS 모드로 작동합니다.)
- Session ends & key expires. After 1 day, the session is closed and the key cannot be reused. (1일이 지나면 세션이 종료되고 키는 재사용 불가입니다.)
4. Example Use Cases (예시 활용 시나리오)
- [Learner / Student] (학습자) Practice debugging exercises where the LLM explains each step, highlights wrong assumptions, and gives alternative approaches. (각 단계를 설명해 주고, 잘못된 가정을 표시하며, 대체 접근법을 제안하는 디버깅 연습)
- [Senior Engineer] (시니어 개발자) Use Debugging OS as a “second reviewer” for refactoring and migration work, with explicit change logs and risk notes. (리팩터링·마이그레이션 작업 시, 변경 로그·리스크 노트를 남기는 두 번째 리뷰어로 사용)
- [QA / SRE Team] Normalize how incidents and fixes are written so that reports look the same, regardless of who writes them. (누가 작성해도 동일한 형태의 장애·수정 리포트가 나오도록 양식을 표준화)
- [AI Lab / Research] (AI 연구) Study how LLMs behave under a strict constitution and compare different models on the same grid logic tasks. (엄격한 헌법 아래에서 LLM의 행동을 관찰하고, 동일한 그리드 작업에서 모델 간 비교)
5. What Debugging OS Is Not (디버깅 OS가 아닌 것)
- Not a full IDE or compiler. (완전한 IDE나 컴파일러가 아님)
- Not a replacement for human code review in critical systems. (중요 시스템에서 사람 코드리뷰를 완전히 대체하지 않음)
- Not a guarantee of zero bugs. It reduces chaos, not risk to zero. (버그 “0”을 보장하지 않고, 혼란을 줄이는 역할)
Instead, it is a logic governor that makes LLM behavior predictable, auditable, and easier to trust. (대신, LLM의 행동을 예측 가능·감사 가능·신뢰 가능하게 만드는 논리 거버너에 가깝습니다.)
6. Roadmap & Extensions (로드맵 및 확장)
- GLOS + 2.5D / 3.5D Integration – Use Debugging OS to also reason about visual grids and depth logic. (2.5D·3.5D 비주얼 그리드와 깊이 논리에 대한 디버깅까지 확장)
- LCTS Integration – Combine logical coordinates of code with camera / sensor LCTS. (코드 논리좌표와 카메라·센서 LCTS를 연계한 통합 디버깅)
- SLM AGI Loop – Let Debugging OS learn from repeated incidents and suggest playbooks. (반복되는 장애·이슈로부터 학습해 플레이북을 제안하는 SLM AGI 연계)
7. How to Start (시작하는 방법)
- Watch the Docs page for public guides and examples. (Docs 페이지에서 공개 가이드와 예제를 확인)
- Join the STELAFOX AI Challenge using the Debugging OS track. (STELAFOX AI 챌린지의 Debugging OS 트랙으로 참여)
- For early enterprise pilots, use the Contact page and tag your message with [ENTERPRISE] or [GOV]. (기업·공공 PoC를 원하면 Contact 페이지에서 [ENTERPRISE] 또는 [GOV] 태그 사용)