입력 (.proto 스키마)

출력 (포맷된 .proto)

이 도구가 하는 일

들여쓰기가 뒤섞여 있고, 필드 선언이 다닥다닥 붙어 있고, 복붙으로 빈 줄이 마구잡이로 들어간 Protocol Buffers 스키마를, 저장소의 다른 코드처럼 보이게 만들고 싶을 때 쓰는 도구입니다. 이 포매터는 파일을 다시 써서 중괄호 단계마다 두 칸 들여쓰기, = 양쪽에 정확히 한 칸, , 뒤에 한 칸, 블록 사이 연속 빈 줄은 최대 한 줄로 정리합니다. 주석 — // 한 줄 주석과 /* ... */ 블록 주석 모두 — 은 적어 둔 위치 그대로 남습니다.

이 도구는 스키마를 파싱하거나 검증하지 않습니다. 그래서 buf format이나 에디터의 "문서 서식 지정"이 거부할 만한 살짝 깨진 입력에도 동작합니다. .proto 어딘가에 문법 오류가 있어도 그 주변 파일은 그대로 정렬됩니다. 단점도 있습니다: 진짜 파서 기반 포매터처럼 필드를 재정렬하거나, import 순서를 정규화하거나, 사용하지 않는 옵션을 떼어 내는 일은 못 합니다. 그게 필요하면 빌드 파이프라인에서 buf format을 돌리세요.

모든 처리는 브라우저에서 일어납니다 — 업로드도, 속도 제한도, 스키마를 외부로 보내는 일도 없습니다. 스키마에 내부 패키지 이름이나 타입 이름, 외부 API에 보내고 싶지 않은 정보가 들어 있을 때 유용합니다. 브라우저 메모리가 감당하는 크기라면 어떤 파일이든 처리할 수 있고, 수만 줄짜리도 1초 안에 정렬이 끝납니다.

사용 방법

세 단계입니다. 입력을 멈추고 약 300ms 뒤에 출력이 갱신됩니다.

.proto 스키마 붙여 넣기

왼쪽 에디터에 스키마를 떨궈 넣으세요. syntax, package, import 지시문, message 블록, 중첩된 enum, oneof, map<K, V> — 모두 처리됩니다. 섞여 있는 줄바꿈(CRLF)은 출력 시 LF로 정규화됩니다.

포매터는 어떤 것도 재정렬하지 않습니다 — 필드, import, 옵션은 작성한 순서 그대로 유지됩니다. 정규 순서가 필요하다면 이후에 buf format을 실행하세요.

포맷된 출력 확인

오른쪽에 같은 스키마가 { 단계마다 두 칸 들여쓰기로 표시됩니다. }로 시작하는 줄은 출력 전 들여쓰기를 한 단계 줄입니다. 연속된 빈 줄은 한 줄로 줄어듭니다. 줄 끝 공백은 제거됩니다. 주석은 상대 위치까지 포함해 글자 그대로 보존됩니다.

결과 활용

에디터에 다시 복사해 넣거나 formatted.proto로 다운로드하세요. protoc 입장에서 보면 출력은 입력과 바이트 단위로 동등합니다 — 바뀌는 건 공백뿐 — 그래서 와이어 포맷이나 생성 코드 차이를 걱정할 필요 없이 그대로 다시 넣을 수 있습니다. protoc --descriptor_set_out=before.pb input.proto를 입력과 포맷된 출력 양쪽에 돌려 비교해 보면 디스크립터가 일치합니다.

실제로 시간을 아껴 주는 상황

채팅이나 문서에서 붙여 넣은 .proto 정리

동료가 Slack에 스키마 조각을 붙여 놨는데 들여쓰기가 망가져 있고, 이걸 저장소에 넣고 싶다 — 여기에 떨궈 넣고, 포맷된 버전을 복사해 파일에 붙이면 끝입니다. 에디터에서 "전체 선택 → 재탭" 춤을 추는 것보다 빠릅니다.

오래된 저장소의 .proto 표준화

파일마다 들여쓰기가 다른 Protobuf 저장소를 물려받았을 때. 각 파일을 이 포매터에 돌려서 정규화 커밋 하나로 푸시하고, 그 이후로는 CI에서 buf format을 켜서 그 상태를 유지하면 됩니다.

생성된 .proto 빠르게 점검

일부 코드 생성기(JSON Schema → Protobuf, OpenAPI → Protobuf)는 유효하지만 보기 흉한 스키마를 내놓습니다. 출력을 포맷해서 눈으로 확인하고, 생성기를 그대로 쓸지 손으로 다듬을지 결정하세요.

protoc나 buf를 설치할 수 없을 때

잠겨 있는 머신, 게스트 네트워크, 또는 그냥 브라우저로 PR을 리뷰하는 중일 때. 브라우저 전용 포매터는 Protocol Buffers 도구체인을 깔지 않고도 동일하게 읽기 좋은 출력을 줍니다.

자주 묻는 질문

제 스키마가 어딘가로 전송되나요?

아니요. 포매터는 JavaScript로 전적으로 브라우저 안에서 돌아갑니다. 스키마에 관한 어떤 정보 — 메시지 이름, 패키지 경로, 주석 — 도 머신을 떠나지 않습니다. DevTools를 열고 붙여 넣으면서 Network 탭을 보세요. 요청이 0건인 걸 확인할 수 있습니다.

주석은 보존되나요?

네 — // 한 줄 주석과 /* ... */ 블록 주석 모두 적어 둔 위치 그대로 남습니다. 자기 줄에 있는 주석은 상대 위치를 유지하고, 필드 줄 끝의 트레일링 주석은 그 필드에 붙은 채 남습니다. 주석이 원본 그대로 살아남도록 일부러 줄 단위 접근법을 택했습니다.

buf format과 어떻게 다른가요?

buf format은 스키마를 구문 트리로 파싱한 뒤 다시 출력합니다. 옵션의 정규 순서, 일관된 enum 대소문자 등 더 강한 보증을 주지만, 스키마가 깨끗하게 파싱돼야 합니다. 이 포매터는 줄 단위라서 buf가 거부할 만한 살짝 깨진 입력에도 동작하고, 정규 순서를 강제하지 않습니다. 완성된 코드에는 buf format을, 편집 중 스키마나 외부 조각에는 이 도구를 쓰세요.

스키마 의미가 바뀌나요?

아니요 — 바뀌는 건 공백뿐입니다. protoc이 입력과 출력 어느 쪽에서 만들든 같은 FileDescriptorProto가 나옵니다. protoc --descriptor_set_out=before.pb input.proto를 원본과 포맷된 파일 양쪽에 돌려 비교해 보세요. 바이너리 디스크립터는 source-info의 span 변경(리플렉션 메타데이터일 뿐 와이어 포맷이 아님)을 빼면 동일합니다.

들여쓰기 폭은 — 2칸에서 바꿀 수 있나요?

출력은 중괄호 단계마다 2칸으로 고정되어 있고, 이는 Protocol Buffers 공식 스타일 가이드의 관례를 따른 것입니다. 4칸이나 탭이 필요하면 출력을 sed나 에디터의 탭 변환에 통과시키세요. 포매터 출력을 정규형으로 유지하면 팀별 설정 차이가 생기지 않습니다.

CRLF 줄바꿈도 처리되나요?

네 — 입력의 CRLF(\r\n)는 출력 시 LF(\n)로 정규화됩니다. 저장하는 파일에 CRLF가 필요하다면, 에디터가 저장 시 줄바꿈 설정에 따라 다시 인코딩해 줍니다.

Protobuf 포매터