프로젝트 운영 원칙

리스펙스의 개발 목적, 공개 범위, 안전 약속, 기술적 피드백과 호환성을 다루는 원칙을 설명합니다.

리스펙스는 출판사의 표기 원칙 같은 업무 규칙을 코드로 쓰는 언어입니다. 파일과 네트워크에 손댈 수 없어서 어떤 프로그램에 넣어도 안전합니다.

우리는 규칙을 믿고 맡길 수 있는 언어가 필요해서 리스펙스를 만들었습니다. 토파즈 전체 CLI에는 리스펙스 평가기가 들어 있어서, 토파즈로 만든 앱은 리스펙스로 쓴 규칙을 불러와 안전하게 실행합니다.

1. 실제 규칙에서 출발하기

리스펙스는 실제로 쓰이는 규칙에서 출발합니다. 표기 원칙이나 배송비 계산처럼 입력이 정해지면 답이 하나로 나와야 하는 규칙이 대상입니다.

기능을 더할 때는 같은 입력에 늘 같은 답이 나오는지, 규칙을 읽는 사람이 그 답을 따라갈 수 있는지를 먼저 봅니다. 규칙이 할 일과 규칙을 부른 애플리케이션이 할 일을 나누고, 그 경계를 흐리는 기능은 넣지 않습니다.

2. 공개 범위와 한 팀의 책임

리스펙스는 스튜디오헤이즈가 설계와 개발, 공식 릴리스를 책임지는 프로젝트입니다. 일관된 설계와 장기적인 유지보수를 위해 로드맵과 기술적 결정은 한 팀이 맡습니다.

공개 GitHub 저장소에서 공식 릴리스와 공개 자료를 냅니다. 문서와 다운로드는 이 웹사이트에서 제공합니다. 평가기 소스는 공개하지 않으며, 내부 개발 저장소는 따로 운영합니다.

npm 패키지와 네이티브 실행 파일은 모두 Apache License 2.0으로 배포합니다. 릴리스마다 실행 파일에 들어간 라이브러리의 라이선스를 모은 고지 파일을 함께 올립니다.

3. 안전 약속과 확인할 수 있는 근거

리스펙스 프로그램은 파일을 읽거나 쓰지 못하고 네트워크도 쓰지 못합니다. 규칙은 답을 돌려줄 뿐이고, 그 답으로 무엇을 할지는 규칙을 부른 애플리케이션이 정합니다. 실행에 쓸 수 있는 한도도 애플리케이션이 정합니다.

이 약속을 누구나 직접 확인할 수 있게 하는 것이 다음 목표입니다. 토파즈 5.22에 맞춰 언어 명세와 토파즈가 쓰는 임베딩 규약, 적합성 시험을 공개 저장소에 올립니다.

4. 기술적 피드백

리스펙스를 깊이 살펴보고 결함을 짚어 주는 피드백을 존중합니다. 재현할 수 있는 규칙과 입력이 담긴 버그 제보, 진단 오류, 문서와 실제 동작이 다른 부분에 대한 분석은 품질을 높이는 중요한 근거입니다.

제보는 GitHub 이슈로 받습니다. 문제의 영향과 재현 가능성을 기준으로 검토하고, 기능 제안은 리스펙스의 설계 원칙과 실제 규칙에서의 가치를 바탕으로 판단합니다.

5. 진화와 호환성

X.Y.0은 새 마이너 버전의 첫 릴리스이고, 그 뒤의 패치 버전은 같은 계열에서 호환을 지키는 수리 릴리스입니다. 이미 공개한 버전과 파일은 그대로 보존합니다.

호환성에 영향을 주는 변경은 이유와 이행 방법을 히스토리에 기록합니다. 지금 계획 중인 일은 로드맵에 있습니다.


리스펙스는 우리가 규칙을 맡기는 언어입니다. 다른 개발자에게도 믿고 맡길 수 있는 규칙 언어가 되기를 바랍니다.