이력서

Item 79–83 범위를 바탕으로 JS 현대화, @ts-check와 JSDoc, allowJs, 모듈별 마이그레이션, noImplicitAny를 코드 리뷰 관점에서 정리합니다.

ESM live binding, default/named export, circular dependency, dynamic import, CJS와 ESM 차이를 프론트엔드 코드 리뷰 관점에서 정리합니다.

Item 67–73 범위를 바탕으로 public API 타입, TSDoc, this callback, module augmentation, TypeScript 기능 선택, source map을 코드 리뷰 관점에서 정리합니다.

DOM 이벤트의 capture/bubble, delegation, default action, React synthetic event 경계를 프론트엔드 코드 리뷰 관점에서 정리합니다.

Item 60–66 범위를 바탕으로 Object iteration, Record, tuple/rest, XOR, brand, @types 버전 경계를 코드 리뷰에서 다루는 방법을 정리합니다.

프로토타입 조회, class 문법, 인스턴스 필드와 prototype 메서드 차이를 프론트엔드 코드 리뷰 관점에서 정리합니다.

Item 55–59 범위를 바탕으로 type test, 타입 표시, 꼬리 재귀 한계, 코드 생성, never exhaustiveness를 코드 리뷰에서 다루는 방법을 정리합니다.

고차 함수, 순수 함수, 부수 효과, async 함수의 Promise 반환을 코드 리뷰에서 어떻게 읽을지 정리합니다.

Item 49–54 범위를 바탕으로 type coverage, 제네릭, 조건부 타입, 템플릿 리터럴 타입을 코드 리뷰에서 어떻게 판단할지 정리합니다.

this 바인딩을 정의 위치가 아니라 호출 형태, 메서드 분리, arrow function, bind 기준으로 읽는 방법을 코드 리뷰 관점에서 정리합니다.

Item 42–48 범위를 바탕으로 any, unknown, 타입 단언, monkey patching, soundness 함정을 외부 입력 경계와 코드 리뷰 관점에서 정리합니다.

콜 스택, 태스크 큐, 마이크로태스크 큐를 기준으로 Promise와 setTimeout 실행 순서를 코드 리뷰 관점에서 정리합니다.

SEOJing study 발행에서 GitHub Actions 성공과 실제 공개 readback 사이에 backend ingest/readback gate가 필요하다는 것을 정리합니다.

Item 35–41 범위를 바탕으로 string 남용, optional 필드, 특수 값, 도메인 이름 설계를 코드 리뷰 관점에서 정리합니다.

클로저가 값 복사가 아니라 렉시컬 환경 참조라는 점을 stale closure, 루프 콜백, React 이벤트 리뷰 관점에서 정리합니다.

Item 28–34 범위를 바탕으로 추론 위치, 유효 상태 모델링, API 입출력, null 경계, union 설계를 프론트엔드 코드 리뷰 관점에서 확장 정리합니다.

스코프 체인, 렉시컬 환경, var/let/const 호이스팅 차이를 콜백·상태 버그 리뷰 관점에서 다시 정리합니다.

Item 22–27 범위를 바탕으로 narrowing, alias, context inference, evolving type, async/type flow를 프론트엔드 코드 리뷰 관점에서 다시 정리합니다.

객체 참조와 얕은 복사, Object와 Map/Set의 차이, WeakMap/WeakSet이 필요한 메모리 상황을 프론트엔드 코드 리뷰 관점에서 정리합니다.

Effective TypeScript 2판의 Item 16–21을 바탕으로 index signature, 타입 추론 기본, 변수/객체 생성 패턴을 프론트엔드 코드 리뷰 관점에서 정리합니다.

객체 프로퍼티를 key/value가 아니라 descriptor로 읽는 법, getter/setter와 defineProperty, preventExtensions/seal/freeze의 경계를 코드 리뷰 관점에서 정리합니다.

Effective TypeScript 2판의 Item 11–15를 바탕으로 excess property check, 함수식 타입, type vs interface, readonly, 타입 반복 제거를 프론트엔드 코드 리뷰 관점에서 정리합니다.

객체가 원시값으로 바뀌는 ToPrimitive 흐름, + 연산자의 문자열 연결과 숫자 덧셈 분기, Symbol.toPrimitive가 코드 리뷰에서 왜 중요한지 정리합니다.

Effective TypeScript 2판의 Item 6–10을 바탕으로 타입 시스템을 탐색하는 법, 타입을 값의 집합으로 보는 관점, type/value space, 타입 단언의 경계를 코드 리뷰 관점에서 정리합니다.

==, ===, Object.is, SameValueZero가 각각 어떤 비교 알고리즘을 쓰는지 정리하고, includes와 indexOf, Map/Set 키 비교에서 생기는 프론트엔드 리뷰 포인트를 잡습니다.

에이전트 시스템에서 trace를 콘솔 로그나 비용 기록으로만 보면 왜 부족한지, 사용자 요청부터 도구 호출, 산출물, 검증, 다음 실행 개선까지 이어지는 증거 사슬로 어떻게 설계해야 하는지 reverse-engineering합니다.

Effective TypeScript 2판의 Item 1–5를 바탕으로 TypeScript와 JavaScript의 관계, tsconfig, 타입 제거, 구조적 타이핑, any의 위험을 프론트엔드 코드 리뷰 관점에서 정리합니다.

자바스크립트의 Number가 왜 정수처럼 보여도 부동소수점 모델 위에서 움직이는지, NaN과 -0, safe integer, BigInt를 프론트엔드 코드 리뷰 관점에서 다시 정리합니다.

SEOJing에서 새 글을 쓸 때 대표 이미지와 본문 이미지를 빼먹지 않도록, 블로그 맵과 글쓰기 파이프라인 안에 시각 판단 단계를 넣은 과정을 정리했다.

SEOJing 글을 소셜용 영상으로 따로 소비시키는 게 아니라, 포스트 상단 요약과 블로그 유입 장치로 연결하기 위해 summaryVideo frontmatter와 Supertonic3 기반 요약 쇼츠 파이프라인을 붙인 과정을 정리했다.

에이전트가 서로 협업하려면 "무엇을 잘한다"는 소개가 아니라 능력, 입력, 산출물, 권한, 실패 모드, 사람 개입 조건을 적은 실행 가능한 경계선이 필요하다는 점을 reverse-engineering합니다.

CLAB Agent Coaching Harness를 다시 정리하면서, 문서와 명령어 중심 구조를 자연어로 트리거되는 repo-local skill pack으로 바꾼 이유를 기록합니다.

OkayJing이 역할극형 planner/reviewer/coder 분리보다 Hermes Hub와 project/profile spoke 격리를 택한 이유를 정리합니다.

큰 모델 호출 전에 로컬 모델이 무엇을 해도 되고 무엇을 하면 안 되는지, OkayJing의 local evidence router 기준을 정리합니다.

OkayJing Local을 단순 ops dashboard가 아니라 desktop, tablet, mobile에서 실제 대화와 작업을 대체하는 표면으로 평가하는 기준을 정리합니다.

OkayJing 서식지가 ticket list 중심 UI를 넘어 worker, session, artifact, verification이 연결된 Pixel Office로 가야 하는 이유를 정리합니다.

DB, Markdown, ticket 같은 원천 리소스 동시성은 API가 맡고, chat/voice/approval은 Hermes gateway 의미를 따라야 한다는 경계를 정리합니다.

OkayJing이 Gemma4 e2b 로컬 라우팅을 감이 아니라 fixture, JSON schema, fallback, raw slice readback으로 평가한 과정을 정리합니다.

OkayJing이 Graphify를 별도 memory layer로 두지 않고 기존 source/index 위의 derived metadata로 붙이기로 한 판단을 정리합니다.

외부 agent skill repository에서 좋은 패턴을 가져오되 OkayJing의 로컬 운영 규칙으로 다시 쓰는 기준을 정리합니다.

외부 skill, MCP/tool package, agent repo를 OkayJing에 들여올 때 왜 supply-chain guardrail이 필요한지 정리합니다.

SEOJing/OkayJing 음성 기능을 public asset pipeline이 아니라 Mac mini local cache, audio API, Range/readback 검증으로 시작한 이유를 정리합니다.

SEOJing 블로그에 대표 이미지를 자동으로 붙이는 실험을 실제로 돌려봤다. 검색 기반 cover 삽입과 Codex CLI 기반 정적 SVG 생성이 같은 frontmatter 경로로 연결됐다.

SEOJing 포스트 목록을 파일 탐색기처럼만 두지 않고, 최신 글부터 실제 사진 기반 리소그래프 배경을 붙이는 실험을 정리합니다. 이미지는 배경만 만들고, 제목과 아이콘은 블로그 UI가 맡는 쪽으로 방향을 바꿨습니다.

MCP 서버를 많이 붙이는 문제가 아니라, 에이전트가 외부 능력을 쓰기 전에 도구 목록, 입력 스키마, 권한, 샘플 호출, 실패 모드를 검문 가능한 계약으로 다루는 법을 reverse-engineering합니다.

NAVER D2의 AI 코드 리뷰 도입기를 CLAB Agent Harness 관점에서 읽고, 자동 리뷰를 팀 작업의 하방 안전망으로 쓰는 방법을 정리합니다.

NAVER D2의 Playwright E2E 테스트 하네스 사례를 CLAB Agent Harness 관점에서 다시 읽고, 하네스가 단순 테스트가 아니라 AI 작업의 실행 환경이라는 점을 정리합니다.

NAVER D2의 프로젝트 자동화 사례를 CLAB Agent Harness 관점에서 읽고, 결정적 자동화와 LLM 판단을 섞는 기준을 정리합니다.

Toss 기술블로그의 Skill 품질 관리 글을 CLAB Agent Harness 관점에서 읽고, 팀 하네스에 필요한 skill 평가 기준과 승격 절차를 정리합니다.

오케이징 포스트를 처음 읽는 사람이 기술 축과 목적별 읽기 순서를 먼저 잡을 수 있도록, gateway·ticket·skill·memory·local LLM·검증·자동화·인터페이스 흐름으로 다시 묶은 상위 지도입니다.

harness를 단순 테스트 환경이나 공유 프롬프트가 아니라 모델, 컨텍스트, 도구, 권한, 작업 원장, 검증, 피드백을 묶어 전문 작업 단위를 찍어내는 팀 아키텍처 공장으로 reverse-engineering합니다.

OkayJing이 플러그인, MCP, gateway, memory 같은 확장점을 기능 추가 지점이 아니라 책임과 권한의 경계면으로 보는 이유를 정리합니다.

에이전트 프레임워크를 직접 설계하거나 고칠 때 확장점을 단순 플러그인 기능이 아니라 책임과 권한이 갈리는 경계면으로 보는 법을 reverse-engineering합니다. 모델, 도구, 기억, 세션, 게이트웨이, 스케줄러, 리뷰 게이트가 어디에서 갈라져야 안전한지 봅니다.

OkayJing Local의 worker와 profile-spoke UI를 역할극이 아니라 capability, handoff contract, artifact lifecycle로 설계해야 하는 이유를 정리합니다.

오케이징의 리뷰 루틴이 모든 것을 막는 검문소가 아니라, 위험도와 변경 범위에 맞게 증거를 요구하는 smart reviewer가 되어야 한다는 기준을 정리합니다.

여러 에이전트나 프로필을 붙일 때 사람 역할놀이가 아니라 capability, task, artifact, handoff contract로 연결해야 하는 이유를 reverse-engineering합니다. A2A식 사고와 OkayJing hub-spoke 운영을 바탕으로 안전한 협업 경계를 봅니다.

오케이징이 반복 승인 피로를 줄이면서도 위험한 행동을 자동화하지 않기 위해, 승인을 세션 범위와 위험도 기준으로 나눠야 했던 이유를 정리합니다.

에이전트 실행을 단순한 채팅 답변이 아니라 이벤트, 산출물, 검증, 상태 전이의 흐름으로 설계하는 법을 reverse-engineering합니다. 티켓, 세션, 파일, 로그, 아티팩트가 왜 프레임워크의 중심이 되는지 봅니다.

CLAB Coreteam 프론트엔드 하네스를 만들면서 컨벤션 문서보다 더 크게 보였던 문제, 팀원이 AI에게 일을 맡기는 방식 설계를 정리합니다.

오케이징이 memory에서 발견한 사실을 바로 skill이나 persistent memory에 반영하지 않고, 검증과 review gate를 거치게 한 이유를 정리합니다.

에이전트 프레임워크에서 사람 개입, 승인, 거절, 확인 질문을 예외 처리로 두지 않고 실행 표면으로 설계하는 법을 봅니다. 위험도 기반 autonomy ladder, interrupt, approval gate, 검증 보고를 reverse-engineering합니다.

오케이징 memory에 vector search를 바로 붙이지 않고 FTS, path boost, source discipline을 먼저 안정화하기로 한 이유를 정리합니다.

에이전트 프레임워크에서 반복 가능한 워크플로와 열린 에이전트 판단을 어떻게 분리해야 하는지 봅니다. 모든 것을 자율 에이전트로 만들지 않고, 상태·도구·검증·사람 개입 지점을 나누는 설계 기준을 reverse-engineering합니다.

오케이징 memory에 local LLM worker를 붙일 때, 요약이나 분류 결과를 바로 믿지 않고 작은 평가 기준부터 세우기로 한 이유를 정리합니다.

에이전트 프레임워크에서 로그, trace, 평가, 재현 가능한 증거를 어떻게 설계해야 하는지 봅니다. 단순한 채팅 기록이 아니라 실행을 다시 읽고 고칠 수 있는 관측 가능성 계층을 reverse-engineering합니다.

Discord gateway가 재시작될 때 이전 세션을 자동 resume하려다 빈 응답을 만들던 문제를 막기 위해 startup auto-resume을 기본 비활성화한 이유를 정리합니다.

에이전트 프레임워크에서 컨텍스트를 긴 프롬프트나 자료 모음이 아니라 실행 상태로 설계하는 법을 봅니다. 세션 기록, 작업 상태, 장기 기억, 검색 결과, 산출물, 검증 근거를 분리하고 조립하는 기준을 reverse-engineering합니다.

반복되는 에이전트 작업을 바로 파인튜닝으로 넘기지 않고, source-linked workflow trace와 평가 기준부터 모으기로 한 이유를 정리합니다.

에이전트가 도구를 쓴다는 말을 함수 호출이 아니라 계약 설계로 다시 봅니다. MCP식 tool contract, 입력 스키마, 권한, 결과 해석, 실패 처리, 검증 책임을 기준으로 개인 에이전트 프레임워크의 도구 런타임을 설계합니다.

백엔드 스터디 마지막 날입니다. Spring Boot 세부 문법을 외우는 대신 프론트엔드 개발자가 백엔드와 안전하게 협업하기 위해 알아야 할 요청 흐름, API 계약, 데이터, 인증, 테스트, 운영 대화법을 하나의 지도로 정리합니다.

오케이징 memory에서 오래된 근거를 바로 장기 사실로 승격하지 않고 stale-check와 promotion queue를 거치게 한 이유를 정리합니다.

개인에게 맞는 에이전트 프레임워크를 만들기 전에 먼저 에이전트가 실제로 실행되는 환경을 분해합니다. 모델, 컨텍스트, 도구, 권한, 검증, 로그가 합쳐진 harness를 기준으로 현재 도구들의 한계와 확장 지점을 읽는 첫 번째 글입니다.

Day 1부터 Day 10까지 배운 백엔드 읽기 기준을 하나의 리뷰 체크리스트로 묶습니다. AI가 만든 Spring Boot 백엔드를 기능 단위가 아니라 요청 흐름, 계약, DB, 보안, 테스트, 운영 가능성 기준으로 검토하는 방법을 정리합니다.

오케이징이 작업을 시작할 때 과거 대화만 믿지 않고 hermes-memory의 stale-check, extract, context pack으로 근거를 먼저 모으게 된 이유를 정리합니다.

오케이징 포스트가 루트에 흩어지고 밀리기 시작했을 때, 새 글을 쓰는 문제보다 먼저 글감·폴더·시간순 맥락을 회수해야 했던 이유를 정리합니다.

okayJing 카테고리를 처음 열었을 때 어디서부터 읽으면 좋은지, 주제별 폴더와 시간순 흐름을 같이 잡아주는 상위 가이드입니다.

AI가 만든 Spring Boot 백엔드를 운영 가능한 코드로 보려면 기능 구현뿐 아니라 문제가 났을 때 어디서 막혔는지 추적할 수 있어야 합니다. Day 10에서는 로그, 요청 ID, 에러 추적, 메트릭, 알림을 낮은 단계부터 읽는 법을 정리합니다.

Dreaming이 새 에이전트 프레임워크와 도구를 발견했을 때, 오케이징이 설치보다 표준 정렬·watch·검증 기준을 먼저 남기기로 한 이유를 정리합니다.

아침브리핑을 단순 알림이 아니라 하루를 시작하기 전에 자동화가 내 상황을 정리해서 넘겨주는 개인 운영 보고서로 사용하게 된 과정을 정리합니다.

Codex goal 정책을 보면서 오케이징의 승인 피로를 줄이는 방향을 다시 잡았다. 핵심은 중간 컨트롤을 늘리는 게 아니라 요구사항, 선택지, 안전 승인 경계를 분리하는 것이었다.

AI가 만든 Spring Boot 백엔드가 실제 팀 작업에 들어갈 수 있는지 보려면 코드만이 아니라 API 문서, README, 변경 이력, 프론트엔드와의 계약 흐름을 읽을 수 있어야 합니다. Day 9에서는 Swagger/OpenAPI, README, 예시 요청, 에러 표, 협업 리뷰 기준을 낮은 단계부터 정리합니다.

음성으로 들어온 가벼운 요청을 오케이징이 티켓, 기존 글 조사, 중복 회피, 포스트 작성과 검증으로 바꾸는 과정을 정리합니다.

AI가 만든 Spring Boot 백엔드가 로컬에서만 돌아가는 코드인지, 실제 서버에서 안전하게 운영될 수 있는 코드인지 판단하려면 배포 구조와 운영 환경을 읽을 수 있어야 합니다. Day 8에서는 Docker, 환경 변수, 프로필, 로그, 헬스체크, CI/CD를 낮은 단계부터 봅니다.

useEffect로 사이드 이펙트를 다루고, 이벤트 처리와 폼 상태 관리까지 — React로 실제 동작하는 앱을 만들기 위한 핵심 기술을 배웁니다.

지금 당장 읽지 않아도 됩니다. React를 배우면서 에러 처리가 필요해지거나 면접 대비가 필요할 때 참고하세요.

Apple Silicon에서 Qwen3-TTS MLX를 검토했지만, 한국어 말끝과 RAM, Discord 실사용성을 기준으로 Supertonic3를 우선 선택한 이유를 정리합니다.

AI가 만든 Spring Boot 백엔드 코드를 검토할 때 테스트는 기능이 실제로 지켜지는지 확인하는 가장 안전한 증거입니다. Day 7에서는 테스트 문법을 외우기보다 Controller, Service, Repository 테스트가 무엇을 보장하는지 읽는 법을 낮은 단계부터 익힙니다.

Supertonic3의 기본 F1/F2/F5 voice style을 조합해 오케이징에 맞는 한국어 여성 음성을 만들려고 했던 custom style JSON 실험을 정리합니다.

AI가 만든 Spring Boot 백엔드 코드를 검토할 때 로그인, 인증, 인가, 토큰, 현재 사용자 흐름은 기능 안전성을 결정합니다. Day 6에서는 auth 코드를 외우는 대신 요청이 누구의 요청인지 확인하고 권한을 적용하는 흐름을 낮은 단계부터 읽습니다.

Edge TTS, Qwen3-TTS MLX, Supertonic3를 비교하면서 오케이징의 TTS 선택 기준이 예쁜 목소리가 아니라 지연, RAM, 말끝, Discord 실사용성의 문제였다는 점을 정리합니다.

AI가 만든 Spring Boot 백엔드 코드를 검토할 때 Service 계층은 Controller, Repository, Entity를 연결하는 핵심 판단 지점입니다. Day 5에서는 Service 메서드, 비즈니스 규칙, 트랜잭션, 읽기/쓰기 경계, 위험 신호를 낮은 단계부터 읽는 법을 다룹니다.

오케이징이 텍스트 채팅을 넘어 Discord voice mode에서 말하기 시작하면서, 답변 방식과 작업 동선이 어떻게 달라졌는지 정리합니다.

Discord voice mode에서 오케이징이 문서형 답변을 그대로 읽으면 왜 어색해지는지, 그리고 음성 인터페이스에서는 답변 정책 자체가 달라져야 한다는 판단을 정리합니다.

AI가 만든 Spring Boot 백엔드 코드를 검토할 때 DB 저장 흐름은 가장 자주 위험해지는 지점입니다. Day 4에서는 Entity, Repository, JPA, ID, 관계, 조회/저장 메서드를 낮은 단계부터 읽고 프론트엔드 기능과 연결해 점검하는 방법을 다룹니다.

오케이징을 위해 Mac mini M4 2TB를 구매하면서 저장공간의 한계를 없애고, 속도와 품질, 토큰 소비, macOS/WSL 운영 분리를 다시 설계하게 된 과정을 정리합니다.

AI가 만든 Spring Boot 백엔드 코드를 검토할 때 입력 검증과 에러 응답은 사용자의 화면 경험을 직접 바꾸는 핵심 지점입니다. Day 3에서는 @Valid, 검증 어노테이션, BindingResult, 전역 예외 처리, 에러 응답 DTO를 낮은 단계부터 읽는 법을 다룹니다.

오케이징의 context pack을 단순 요약본이 아니라 git 상태, facts, events, source-linked chunks를 묶은 작업용 증거 묶음으로 설계한 이유를 정리합니다.

AI가 만든 Spring Boot 백엔드 코드를 검토할 때 가장 먼저 맞춰야 하는 것은 문법 암기가 아니라 프론트엔드와 백엔드 사이의 API 계약입니다. Day 2에서는 URL, HTTP Method, 요청 바디, 응답 바디, DTO, 검증 어노테이션, 에러 응답을 낮은 단계부터 읽습니다.

React를 처음 시작합니다. 컴포넌트, JSX, props, useState까지 — React 앱을 만들기 위한 핵심 네 가지를 한 번에 배웁니다.

React를 배우면서 this가 헷갈리거나, 면접 대비가 필요할 때 참고하는 JS 심화 자료입니다. 이 내용을 지금 당장 완벽히 이해하지 않아도 React를 배우는 데 지장이 없습니다.

Honcho나 Mem0 같은 외부 backend를 붙이기 전에, 왜 오케이징의 기억을 SQLite와 source-linked evidence 중심으로 먼저 만들었는지 정리합니다.

직접 백엔드 코드를 다 작성하는 사람이 아니라, AI가 만든 Spring Boot 코드를 이해하고 수정 방향을 판단할 수 있는 사람을 목표로 시작합니다. Day 1에서는 서버가 하는 일, HTTP 요청의 흐름, 스프링 프로젝트 폴더 구조, Controller-Service-Repository의 역할을 아주 낮은 단계부터 잡습니다.

Jing Studio에서 MSW mock API를 단순 목업 도구가 아니라 백엔드 요구사항 분석과 DTO 정리를 위한 실행 가능한 계약으로 다루게 된 과정을 정리합니다.

Jing Factory를 아이디어에서 프로토타입까지 밀어붙이는 흐름으로 다시 보면서, 화면보다 요구사항·DTO·API 계약·MSW mock API를 먼저 남기도록 Jing Studio skill을 바꾼 이유를 정리합니다.

오케이징이 작업 결과를 한국어 Hermes Report 형식으로 남기게 된 이유와, 보고가 단순 요약이 아니라 인수인계 문서가 되는 과정을 정리합니다.

Hermes cron job이 fresh session에서 실행된다는 특성 때문에, 예약 작업 prompt에 모든 조건과 맥락을 넣어야 하는 이유를 정리합니다.

sessions Forum에서 오케이징이 자연어 세션처럼 응답할 수 있게 만든 free-response channel과 channel prompt 구조를 정리합니다.

built-in memory로 충분한지, Honcho나 Mem0 같은 memory backend를 도입할 기준은 무엇인지 오케이징 운영 관점에서 정리합니다.

Next.js가 무엇이고 왜 필요한지 React와 비교해 이해한 뒤, CSR부터 SSR, SSG, ISR, PPR까지 렌더링 전략과 Web Vitals를 정리하며 스터디를 마무리합니다.

다음 주부터 React를 시작합니다. React 코드에서 매 줄 등장하는 map/filter, 구조 분해, 스프레드, 옵셔널 체이닝, 모듈까지 — React 코드를 막힘없이 읽기 위한 JS 문법을 한 번에 정리합니다.

OpenClaw-era Jing Factory와 jing-bridge 실험에서 남길 개념을 고르고, Hermes 단일 체계 안에서 다시 설계한다면 어떤 흐름이 자연스러운지 정리합니다.

Hermes 단일 체계로 넘어온 뒤에도 남아 있던 OpenClaw systemd service와 watchdog 흔적을 추적하며, migration에서 잔재 제거가 왜 중요한지 정리합니다.

사용자가 부르지 않는 시간에 오케이징이 최근 운영 상태를 점검하고, 저위험 개선과 아침 브리핑을 수행하는 구조를 정리합니다.

현재 오케이징 구조에서 다음으로 실험할 만한 영역을 정리합니다. 핵심은 에이전트 수가 아니라 상태 관리와 승인 경계입니다.

오케이징이 장기 기억, 작업 상태, 과거 대화 검색을 서로 다른 저장소로 나눠 쓰는 이유를 정리합니다.

독립 리뷰어처럼 다루던 낫징을 commit, push, PR 전 최종 검문 루틴으로 바꾼 이유를 정리합니다.

과거 별도 계획자처럼 다루던 우로보로스를 Hermes 내부 planning discipline으로 흡수한 이유를 정리합니다.

OpenClaw-era 다중 역할 구조에서 Hermes 단일 체계로 옮기게 된 이유와 남긴 것, 버린 것을 정리합니다.

비동기와 async/await를 배운 뒤, 대면에서는 API를 단순 호출 방법이 아니라 프론트엔드와 백엔드 사이의 계약으로 바라봅니다. HTTP, REST, CORS, 프록시, API 클라이언트 구조, TanStack Query와 파일 배치까지 연결합니다.

JS 비동기 처리의 흐름을 배웁니다. 클로저가 왜 중요한지, 콜백 지옥을 해결한 Promise, 그리고 현대 JS의 표준인 async/await까지 이어지는 흐름을 이해합니다.

오케이징이 일반 대화와 실제 작업 요청을 어떻게 구분하는지, 티켓 생성 판단 기준을 정리합니다.

Discord thread만으로는 부족했던 작업 상태를 로컬 SQLite 티켓 시스템으로 남기게 된 이유를 정리합니다.

오케이징이 Discord에서 자연어 대화 공간과 실제 작업 추적 공간을 분리한 이유를 정리합니다.

OpenClaw 시절부터 Hermes 단일 체계까지, 오케이징 로직이 어떤 방향으로 바뀌었는지 먼저 전체 지도를 그립니다.

헤르메스가 Discord 게이트웨이에 직접 연결됐고, 작업 흐름이 채팅에서 포럼 티켓으로 바뀌었습니다. 오케이징 관점에서 이 두 가지 변화가 뭘 의미하는지를 기록합니다.

Discord 게이트웨이 대신 md 파일 기반 독립 worker 구조로 전환했습니다. 오케이징이 task.md를 만들면 헤르메스가 구현하고 낫징이 리뷰합니다. 채팅을 거치지 않습니다.

멀티 에이전트 시스템에는 여러 조율 패턴이 있습니다. 오케이징 팀이 어떤 구조들을 검토했고 왜 티켓 기반 구조를 선택했는지, 그 장단점을 기록합니다.

텔레그램 단독에서 텔레그램+디스코드 이원화로 전환하면서 겪은 이슈들, 4-페르소나 운영 체계 확립, 그리고 헤르메스 정체성이 어떻게 잡혔는지를 기록합니다.

바닐라 JS의 한계에서 React가 등장한 이유까지, 컴포넌트와 렌더링 방식을 이해하고 프로젝트 구조 감각을 만들어가는 대면입니다.

JS에서 가장 낯선 개념 중 하나인 프로토타입 기반 상속을 다룹니다. const가 왜 불변을 보장하지 않는지, 타입을 런타임에 정확히 확인하는 방법까지 함께 배웁니다.

4월 말부터 5월 초까지 오케이징 시스템에 쌓인 결정들을 정리합니다. 에이전트 팀 구성, 메모리 아키텍처 선택, 보고 라우팅 사고와 수정, 스킬 추가, 모델 분담 전략까지.

OpenClaw를 처음 한 바퀴 돌릴 때 머리에 박아두면 좋은 6개 추상화와, 진규 머신 위에서 실제로 그것이 어떻게 배치되어 있는지의 좌표계를 잡는 글.

오케이징이 진규의 OpenClaw 운영 구조를 한 레이어씩 풀어주는 시리즈 소개. 가이드보다는 "이걸 어떻게 굴리고 있는가"의 기록에 가깝습니다.

Layer 0의 좌표 위에서 가장 무거운 한 점인 gateway를 분해합니다. config·hot-reload·세션 라이프사이클·도구 정책까지, 운영하면서 자주 부딪히는 디테일을 한 번에 정리합니다.

JavaScript에서 거의 모든 것은 객체입니다. 함수가 일급 객체라는 의미, var와 let의 스코프 차이, 그리고 렉시컬 스코프까지 다룹니다.

4~6주차 공백 이후 진행하는 첫 번째 대면입니다. HTML/CSS/JS 핵심을 가볍게 다시 연결하고, 브라우저가 코드를 실제 화면으로 바꾸는 과정을 통해 렌더링 파이프라인과 성능 감각을 잡습니다.

길어진 6주차 대면의 두 번째 차시입니다. AI 시대에 개발자가 실제로 어떻게 일하는지, 그리고 프론트엔드 개발자가 디자이너·백엔드·PM 사이에서 어떤 연결과 리딩 역할을 하는지 다룹니다.

JavaScript를 처음 제대로 배우는 주차입니다. var/let/const의 차이, JS만의 독특한 타입 시스템, 그리고 호이스팅·TDZ까지 다룹니다.

시뮬레이터가 만든 70만 줄짜리 이벤트 로그를 프론트에서 재생 가능한 데이터로 줄이는 과정. SSE 와 prefetch 청크 사이에서 헤맸고, 결국 "이동 명령"만 보내고 보간하는 모델로 갔다. 그리고 콜드스타트 문제는 "지역 특성" 이라는 별도 모드를 줌 아웃에 띄우는 걸로 풀었다.

탭 기반 네비게이션을 버리고 Spot 을 지도 중심 서비스로 피봇한 기록. 왜 Zustand 만으로는 부족했고, 왜 useSearchParams 기반의 URL 상태를 택했는지. 그리고 URL, Zustand, useState, Ref 네 저장소를 어떤 기준으로 갈라 쓰게 됐는지.

한 프로젝트에서 기술 결정은 생각보다 서로 닮아있다. Spot 을 만들면서 반복해서 되돌아간 판단 세 가지 — 상태를 어디에 둘지, 언제 React 를 우회할지, 데이터를 모양으로 묶을지 원인으로 묶을지. 각 판단을 개별 글로 정리했고, 이 글은 그 허브다.

개발 서버를 띄울 때마다 절반의 확률로 지도 타일이 회색으로만 보였다. 원인은 React StrictMode 의 double-invoke 와 async 마운트 함수가 만든 race condition. async useEffect 의 함정과 동기 초기화라는 해법을 정리한다.

탭 기반 서비스를 지도 중심으로 피봇한 로컬 커뮤니티 프로젝트 Spot. 그 과정에서 배운 개념과 기술 선택을 기록으로 남긴다.

맵 위를 움직이는 페르소나 500명 때문에 드래그가 끊겼다. React DevTools Profiler 로 원인을 찾고, ref+pub/sub 패턴과 imperative redraw 로 React 를 우회한 과정. 그리고 왜 setState 도 useSyncExternalStore 도 아닌 이걸 골랐는지.

맵 위의 페르소나들을 묶는 방법에는 두 갈래가 있다. 기하학적으로 "가까이 있으면 묶기" 와, 원인 중심으로 "스팟이 있어서 모였기 때문에 묶기". 처음엔 전자를 짰고, 한참 뒤에 후자로 갈아엎었다. 같은 화면이어도 UX 의미가 다르다는 걸 그때 알았다.

교수님의 피드백 한 통으로 배포 구조를 다시 재설계한 기록. docker-compose와 내부 네트워크, 프론트 Nginx 게이트웨이 구조로 넘어가면서 1차 방식이 남긴 찜찜함을 하나씩 풀어냈다.

배경 이미지를 제어하고, Position으로 요소를 원하는 위치에 배치하며, Flexbox로 유연한 가로·세로 레이아웃을 구성합니다. 요소를 화면 정중앙에 띄우거나, 내비게이션 바처럼 가로로 예쁘게 정렬하는 것이 이번 주 목표입니다.

서브도메인이 막혔다는 교수님 메일 한 통으로 시작된 도커 네트워크 공부. 리버스 프록시, 포트 포워딩, Build-time 환경변수, Multi-stage Build, CORS까지 하나씩 파고들었다.

2025.09 ~ 2026.01. 기획과 디자인이 개발보다 더 길었던 프로젝트.

HLMN 어드민 hero-images, lab, main, news feature 리팩토링. 리팩토링의 의의를 처음으로 실감한 작업이었다.

KGU Developers 합류 후 첫 토이프로젝트. 야구 앱 아이디어 냈다가 디스코드 클론으로 결정됐다.

KGU Developers에 들어온 이유, 그리고 팀장을 맡으면서 원하는 것들.

3주차 박스 모델과 스타일링 복습, 과제 풀이, 4주차 Position과 Flexbox 레이아웃까지 다룬 대면 스터디 정리입니다. 면접에서 자주 나오는 마진 겹침, box-sizing, Flexbox 관련 질문도 함께 준비합니다.

폰트와 색상을 다루고, 인라인과 블록 요소의 차이를 이해하며, 마진·패딩으로 구성되는 박스 모델을 완벽하게 익힙니다. 요소들 사이의 여백을 자유자재로 제어하고 화면이 찌그러지지 않게 박스 크기를 다루는 것이 이번 주 목표입니다.

2주차 폼과 CSS 선택자 복습, 과제 풀이, 3주차 박스 모델과 스타일링까지 다룬 대면 스터디 정리입니다. 면접에서 자주 나오는 GET vs POST, CSS 우선순위, 박스 모델 관련 질문도 함께 준비합니다.

SEO Jing 개발 열두째 날. code-block 테스트 14개 추가로 커버리지 대폭 개선, 모바일 프레젠테이션에서 FullscreenView 방향 전환 문제와 스크롤 멈춤 버그 수정.

useEffect 의존성 배열에 불필요한 값이 포함되면 cleanup과 재실행이 뒤엉켜 DOM 상태가 꼬일 수 있다. 프레젠테이션 모드에서 발생한 모바일 스크롤 고착 버그를 통해 원인과 해결 패턴을 정리한다.

사용자 입력을 받는 폼(Form)을 만들고, CSS를 HTML에 연결하는 방법과 원하는 요소를 정확히 선택하는 CSS 선택자 규칙을 배웁니다. 로그인·회원가입 폼을 직접 만들고, CSS로 원하는 요소를 콕 집어내는 것이 이번 주 목표입니다.

1주차 HTML 핵심 복습과 과제 풀이, 2주차 폼(Form)과 CSS 선택자까지 다룬 대면 스터디 정리입니다. 면접에서 자주 나오는 시맨틱 HTML, img alt 속성 관련 질문도 함께 준비합니다.

SEO Jing 개발 열한째 날. PC 프레젠테이션 확대/축소 컨트롤 추가, 모바일 orientation 판단 로직 개선, FullscreenView를 독립 컴포넌트로 분리 및 PC 대응.

한국어 MDX 블로그를 만들다 vinext 프레임워크의 ByteString 버그를 발견하고, 이슈를 작성하고, PR을 올리기까지의 과정

vinext가 빠른 이유를 이해하기 위해, SSR부터 Hydration, 빌드 도구, Edge Runtime, Web Vitals, RSC, CDN 캐싱, ISR, PPR까지 웹 렌더링 성능의 전체 그림을 정리한다

모바일 Safari에서 100vh가 화면을 넘치는 이유, vh/svh/lvh/dvh의 차이, JavaScript에서 실제 뷰포트를 구하는 방법, 그리고 전체화면 UI를 만들 때 알아야 할 CSS zoom과 모바일 판정 패턴까지 정리한다.

SEO Jing 개발 열째 날. 프레젠테이션 모드의 모바일 UX 문제들을 전면 수정. 퀴즈·코드블록·이미지·포스트목록 처리 개선, 롱프레스 UX 및 하단 바 레이아웃 안정화. 모바일 뷰포트·리스트 분할 문제 수정, 채움 비율 보수적으로 조정, 포스트 탐색기 자연 정렬 적용.

기초 태그 강의에서 한 걸음 더 나아갑니다. 카카오톡 공유 썸네일, 모바일 데이터 절약, 스크린 리더기를 위한 숨은 정보 등 실무에서 마주하게 될 중급 HTML 개념들을 가볍게 훑어봅니다.

SEO Jing 개발 아홉째 날. 프레젠테이션 기능 추가, 퀴즈 구조 변경, 모바일 반응형, 코드블럭 사용성, 테스팅 도입.

모바일 웹에서 코드 블록을 가로로 넓게 보여주고 싶었다. screen.orientation.lock()은 iOS에서 안 되고, PWA manifest는 브라우저에서 무시된다. 결국 CSS transform으로 가짜 회전을 만들었고, 그 과정에서 엄지 접근성까지 고민하게 됐다.

MDX 파일을 수정하지 않고, 렌더된 DOM을 h2 기준으로 자르고 화면 높이에 맞춰 자동 페이지네이션하는 프레젠테이션 모드를 만들었다. 리스트 높이 측정이 왜 틀리는지 디버깅한 과정과, ul/ol을 li 단위로 분할하는 해결책을 정리한다.

SEO Jing 개발 여덟째 날. 아티클 퀴즈 디자인시스템 구현과 스터디 대면 자료 작성.

MDX 블로그에 퀴즈 컴포넌트를 만들면서, Context 기반 Compound Component로 시작했다가 index 문제에 막혀 React.Children API를 채택하게 된 과정을 정리한다.

SEO Jing 개발 일곱째 날. Front Matter CMS 설치와 관련 게시물 이동 탐색기 구현.

프론트엔드 개발자가 실무에서 하는 일, 2025-2026 기술 스택, 현실적인 연봉과 채용 트렌드를 정리했습니다. 스터디 자료 구조와 앞으로의 방향도 함께 안내합니다.

스터디 커리큘럼 방향을 정하기 위한 세 번째 사전 진단 퀴즈입니다. 자바스크립트의 스코프, 참조 타입의 메모리 할당, DOM 제어와 이벤트 흐름 등 React 실무의 근간이 되는 CS 지식을 점검합니다.

스터디 커리큘럼 방향을 정하기 위한 마지막 사전 진단 퀴즈입니다. React 컴포넌트를 다루기 위해 필수적인 배열 고차 함수(map, filter)와 비동기 통신(async/await) 능력을 점검합니다.

스터디 커리큘럼 방향을 정하기 위한 마지막 사전 진단 퀴즈입니다. 선언적 UI, 상태(State), 단방향 데이터 흐름, 부수 효과(Side Effect) 등 React 생태계 진입을 위한 필수 개념을 점검합니다.

SEO Jing 개발 여섯째 날. 데스크탑 비율 수정과 씨랩 스터디 사전 진단 자료 작성.

스터디 커리큘럼 방향을 정하기 위한 첫 번째 사전 진단 퀴즈입니다. HTML 태그 구조부터 CSS 박스 모델까지, 실무와 React 환경에서 이 기초들이 왜 중요한지 점검합니다.

스터디 커리큘럼 방향을 정하기 위한 두 번째 사전 진단 퀴즈입니다. 시맨틱 마크업, 폼 이벤트 제어, CSS 우선순위, Flexbox 레이아웃 등 실전 활용 능력을 점검합니다.

SEO Jing 개발 다섯째 날. shiki를 rehype-prism-plus로 교체하고, gray-matter 직접 구현, MDX 모듈화, 페이지 내 검색, 테이블 디자인시스템까지.

SEO Jing 개발 넷째 날. lint, codecov, Cloudflare 배포, fs 런타임 이슈.

배포 후 블로그 포스트가 404를 반환하던 문제부터, gray-matter eval 차단, next-mdx-remote eval 차단까지 — 세 겹으로 터진 이슈를 하나씩 해결한 기록

localStorage를 읽는 컴포넌트에서 하이드레이션 불일치가 발생하는 원인과, useState+useEffect가 아닌 useSyncExternalStore가 정답인 이유를 정리한다.

vinext 프로젝트를 GitHub Actions로 Cloudflare Workers에 자동 배포하는 방법과 실제 겪은 트러블슈팅 기록

코드 하이라이팅에 Shiki를 쓰면 왜 RSC에서 WebAssembly.instantiate() 에러가 터지는지, 그리고 빌드 타임 하이라이팅으로 어떻게 해결했는지 정리한다.

CLI 코드 리뷰에서 받은 피드백과 전체 코드 수정 계획을 정리했다.

localStorage만으로 글 읽기 추적, 스크롤 진행률, 댓글 감지를 구현한 과정을 정리했다.

블로그 디테일 페이지에서 MDX를 렌더링하기 위해 검토한 라이브러리들과 최종 선택 과정.

SEO Jing 개발 셋째 날. MDX 라이브러리 이슈, 반응형, 코드블럭, 댓글, 다크모드, 코드 리뷰.

디자인 시스템 구현 시 파일 구조, 디자인 토큰, 유의 사항을 정리했다.

Tailwind v4 환경에서 폰트가 메인 페이지에서만 적용되지 않던 원인과 Hydration Mismatch 이슈를 정리했다.

MDX 파일의 경로 탐색 로직과 콘텐츠 트리 생성 과정을 정리했다.

MDX 파일 구조를 JSON으로 변환하기 위해 Node.js의 fs 모듈을 배워봤다.

SEO Jing 개발 둘째 날. 디자인 시스템 확장, 블로그 스켈레톤, 폰트 이슈 해결.

서진규 | Frontend Developer

SEO Jing 프로젝트의 기술 스택 선정과 전체적인 개발 플로우 정리.

Storybook의 사용법과 디자인 시스템 개발에서의 장점을 정리했다.

MDX의 개념과 블로그에서 활용하는 이유를 정리했다.

SEO Jing 개발 첫째 날. 디자인 컨셉 설정과 디자인 시스템 구축을 시작했다.

SEO Jing을 개발하게 된 이유입니다.

프로젝트가 중단되는 이유에 대한 자기 회고입니다.