로컬 우선 릴리즈 검토

API diff를 한 화면에서 끝내기

이전/신규 OpenAPI 또는 JSON Schema 문서를 붙여넣거나 불러와서 변경을 분류하고, 위험 항목을 검토한 뒤, 서버 업로드 없이 바로 릴리즈 초안을 복사할 수 있습니다.

신뢰 정보

OpenAPI 3.0/3.1 지원 · JSON Schema beta · 브라우저 로컬 처리 · auth/default/required 변경은 검토 큐 유지

워크벤치 열기

비교 워크스페이스

샘플 비교

원본 spec에서 릴리즈 문구까지 한 번에 보지 말고, 차분하게 단계별로 처리할 수 있게 정리했습니다.

브라우저 로컬에서 처리되며 원본 spec은 업로드되지 않습니다.

이전 spec

previous-spec.yaml

두 spec을 모두 넣고 비교를 실행하면 semver 추천, 위험 항목, 복사 가능한 초안이 여기서 정리됩니다.

위험도 요약

구조적 변경이 감지되지 않았습니다.

추천 근거

두 spec을 모두 넣고 비교를 실행하면 semver 추천, 위험 항목, 복사 가능한 초안이 여기서 정리됩니다.

다음 단계

분류된 변경 목록을 빠르게 스캔하세요.

이 route가 먼저 답하는 질문

이 변경이 breaking인지, 어떤 semver 상승이 안전한지, 릴리즈 노트에 무엇을 써야 하는지를 먼저 정리해 줍니다.

  • 이미 이전 spec과 신규 spec 초안이 있는 팀이 빠르게 release 판단을 내릴 때 적합합니다.
  • auth, default, nullable, required, enum 변경은 사람 승인 전까지 review-required로 남깁니다.
  • 복사 가능한 초안은 PM, Tech Writer, SDK, backend 리뷰 루프를 바로 이어갈 수 있게 설계합니다.

워크벤치 사용 순서

  1. 1.이전 spec과 신규 spec 문서를 넣습니다.
  2. 2.비교를 실행하고 severity 요약을 먼저 확인합니다.
  3. 3.위험 항목을 해소한 뒤 audience에 맞는 초안을 복사합니다.

신뢰 포인트

  • 브라우저 로컬에서 실행
  • 원본 spec은 Konviny 서버로 업로드되지 않음
  • 위험 rule 카테고리는 수동 검토 큐로 분리
  • 검토 결과에 따라 semver 추천이 즉시 갱신
운영 주체: Konviny Tools 팀
마지막 업데이트: 2026-03-07

FAQ

지원 정보는 툴 아래에만 남겨 두었습니다.

비교는 정말 브라우저 안에서만 실행되나요?

네. MVP는 local-first workbench로 설계되어 있어서 이전/신규 spec 원문은 브라우저 안에 머문 채 diff report가 생성됩니다.

왜 일부 변경은 breaking/non-breaking이 아니라 needs review로 남나요?

auth, default, nullable, required, enum 변경은 rollout 문맥과 소비자 계약에 따라 영향이 달라질 수 있으므로 수동 검토를 요구합니다.

baseline을 나중에 다시 불러올 수 있나요?

네. 현재 이전 spec을 브라우저 로컬 저장소에 baseline으로 저장하고 나중에 workbench로 다시 불러올 수 있습니다.