OkayJing
Planner, reviewer, coder를 늘리지.
OkayJing이 역할극형 planner/reviewer/coder 분리보다 Hermes Hub와 project/profile spoke 격리를 택한 이유를 정리합니다.
Jing Factory를 다시 이야기할 때 처음 떠올린 건 단순했습니다. 진규가 아이디어를 던지면 오케이징이 화면을 만들고, mock data를 채우고, 실제로 눌러볼 수 있는 프로토타입까지 만들어주는 흐름입니다. 말만 들으면 꽤 괜찮습니다. 아이디어가 머릿속에만 있는 것보다, 브라우저에서 만져볼 수 있는 편이 훨씬 빠르기 때문입니다.
그런데 막상 이걸 작업 흐름으로 고정하려고 보니, 그냥 목업 화면을 빨리 만드는 것만으로는 부족했습니다. 화면은 나올 수 있습니다. 하지만 그 화면이 나중에 백엔드와 어떻게 연결될지, 어떤 request와 response가 필요한지, 어떤 데이터가 서버 책임이고 어떤 데이터가 프론트의 view model인지가 남지 않으면 같은 문제가 반복됩니다.
겉으로는 "프로토타입 생성" 문제였지만, 실제로는 "계약을 언제 남길 것인가"의 문제에 가까웠습니다.
프론트 작업에서 mock data는 자주 가볍게 취급됩니다. 아직 API가 없으니 일단 화면에 필요한 필드를 아무렇게나 만들고, 컴포넌트가 예쁘게 보이면 넘어갑니다. 짧은 데모에서는 이 방식도 잘 돌아갑니다. 잠깐은.
문제는 실제 연동 시점에 옵니다. 프론트는 title, scoreLabel,
isHighlighted 같은 값을 기대하는데, 백엔드는 name, matchScore,
priority 같은 DTO를 내려줍니다. 어떤 값은 서버가 계산해야 할 것처럼 보이고,
어떤 값은 프론트에서 포맷팅하면 되는 값처럼 보입니다. 이 기준이 없으면 API
wrapper, mapper, component가 한꺼번에 흔들립니다.
대충 만든 mock data
→ 화면은 빨리 나옴
→ API 계약은 남지 않음
→ 실제 백엔드 연동 때 필드명과 책임이 어긋남
→ mapper/API wrapper/component를 다시 정리함
Post Q&A
Jing Studio는 목업 생성기가 아니다 — 계약을 먼저 남기는 징팩토리 전체를 기준으로 질문과 피드백을 받아요.답을 본 뒤에는 이 내용을 댓글로 달아서 서징에게도 물어볼 수 있어요. 작성자가 직접 볼 수 있어요!
그래서 이번 Jing Studio 변경에서는 mock data를 단순 fixture가 아니라 계약의 초안으로 보기로 했습니다. 더미 데이터를 만들기 전에 요구사항, 도메인 모델, DTO, API contract를 먼저 지나가게 만든 이유가 여기에 있습니다.
이번 변경에서 가장 중요한 기준은 MSW의 위치였습니다. MSW를 "백엔드 없을 때 쓰는 가짜 응답" 정도로 보면 이 흐름의 가치가 작아집니다. Jing Studio에서는 MSW를 API 계약 시뮬레이터로 봅니다.
screen data needs
→ domain model
→ request/response DTOs
→ mock data fixtures
→ MSW handlers
→ API client functions
→ view-model mappers
→ UI blocks/screens
프론트는 처음부터 실제 API를 호출하듯 API client를 호출합니다. 다만 응답을 실제 서버가 아니라 MSW handler가 돌려줄 뿐입니다. 이렇게 하면 나중에 백엔드가 생겼을 때 바꿔야 하는 지점이 줄어듭니다. UI는 그대로 두고, MSW를 끄고, 같은 API client가 실제 base URL을 바라보게 만들 수 있습니다.
중요한 건 handler가 화면 전용 값을 대충 반환하지 않는 것입니다. request DTO, response DTO, status code, validation error, empty/error/auth state를 같이 설계해야 합니다. 그래야 MSW가 단순 mock이 아니라 백엔드와 이야기할 수 있는 계약 초안이 됩니다.
기존 Jing Studio skill은 아이디어를 product brief, reference map, screen inventory, DESIGN.md, block kit, Figma layout, implementation brief로 넘기는 흐름이었습니다. 이 흐름은 화면과 디자인을 잡는 데는 괜찮았습니다. 하지만 백엔드와 이어지는 계약은 약했습니다.
runs/<slug>/
product-brief.md
requirements.md
reference-map.json
domain-model.md
screen-inventory.json
dto-spec.ts
api-contract.md
mock-data-plan.md
msw-handlers-plan.md
DESIGN.md
block-kit.json
figma-layout-brief.md
figma-placement.json
figma-layer-map.json
layout-brief.json
implementation-brief.md
backend-requirements.md
목록만 보면 문서가 너무 많아 보일 수 있습니다. 그런데 역할을 나누면 그렇게
과한 구조는 아닙니다. requirements.md는 무엇을 만들지 정리하고,
domain-model.md는 어떤 명사가 있는지 잡고, dto-spec.ts는 API 입출력을
고정합니다. api-contract.md는 endpoint와 status code를 남기고,
mock-data-plan.md와 msw-handlers-plan.md는 프론트가 실제 API처럼 작업할 수
있게 만듭니다. 마지막으로 backend-requirements.md가 백엔드 구현자에게 넘길
요구사항을 정리합니다.
이번 변경에서 따로 박아둔 기준이 있습니다. UI-only view model을 backend DTO로
착각하지 않는 것입니다. 화면에는 종종 서버가 알 필요 없는 값이 필요합니다.
예를 들어 scoreLabel, subtitle, badgeTone, groupTitle 같은 값은 화면
표현에 가깝습니다.
반대로 서버 DTO는 서버가 책임지는 사실을 내려줘야 합니다. 추천 점수라면
matchScore, 추천 이유라면 matchReasons, 식별자라면 clubId처럼 원본에
가까운 값이 좋습니다. 이 둘을 섞으면 나중에 백엔드가 UI 표현을 끌어안거나,
프론트가 서버 책임을 임의로 흉내 내게 됩니다.
API Response DTO
→ 서버가 책임지는 사실
Frontend ViewModel
→ 화면 표현, 라벨, 포맷팅, grouping, derived flag
Mapper
→ DTO를 ViewModel로 바꾸는 경계
이 경계가 있어야 백엔드 요구사항 분석도 선명해집니다. "이 필드는 서버가 계산해야 하는가?" "프론트에서 포맷팅하면 되는가?" "DB에 저장되는 값인가, 요청마다 계산되는 값인가?" 같은 질문이 자연스럽게 나옵니다.
Jing Studio에는 여전히 Figma MCP 흐름이 있습니다. 오케이징이 회색 블록을 만들고, 진규가 위치와 크기를 조정하고, 다시 layer tree를 읽어 implementation brief로 바꾸는 흐름입니다. 이건 유효합니다. 다만 Figma가 요구사항의 출처가 되면 안 됩니다.
Figma는 배치 협상 화면입니다. 요구사항은 requirements.md에, 데이터는
domain-model.md에, API 계약은 api-contract.md에 있어야 합니다. Figma에서
어떤 카드가 오른쪽에 놓였다고 해서 서버 DTO가 바뀌면 안 됩니다. 반대로 API
계약이 바뀌었다면 그 이유가 문서에 남아야 합니다.
그래서 이번 변경의 핵심은 UI 자동화보다 artifact pipeline에 가깝습니다. 화면은 만들 수 있습니다. 하지만 화면보다 먼저 남아야 하는 것은 계약입니다.
이번 변경으로 Jing Studio는 "아이디어를 목업으로 바꾸는 도구"에서 조금 더 나아갔습니다. 이제 목표는 아이디어를 요구사항, DTO, API contract, MSW mock API, backend requirements까지 연결하는 것입니다.
이게 잘 되면 진규가 아이디어를 던졌을 때 결과물은 단순 화면이 아닙니다. 프론트는 바로 만져볼 수 있는 프로토타입을 얻고, 백엔드는 어떤 API와 DTO를 만들어야 하는지 초안을 얻습니다. 그리고 오케이징은 다음 세션에서도 같은 artifact를 읽고 이어갈 수 있습니다.
결론은 단순합니다. Jing Factory에서 mock data는 장식이 아닙니다. mock data는 계약을 검증하는 재료입니다. MSW는 그 계약을 실제 호출처럼 굴려보는 장치입니다. 그래서 Jing Studio는 목업 생성기가 아니라, 제품 계약을 먼저 남기는 파이프라인이어야 합니다.
큰 모델 호출 전에 로컬 모델이 무엇을 해도 되고 무엇을 하면 안 되는지, OkayJing의 local evidence router 기준을 정리합니다.
