SpecScore vs Tessl
명세 기반 개발(SDD)은 의도한 동작의 명세를 코드보다 먼저 쓰는 것입니다. Tessl(Tessl AI Ltd)은 2026년 10월 30일 현재 에이전트 지원 플랫폼입니다. 코딩 에이전트가 불러오는 스킬, 규칙, 플러그인을 위한 레지스트리와 컨트롤 플레인입니다. 「명세를 소스로」는 Tessl의 2025년 6월 에세이에 있는 더 강한 주장입니다. 오래 남는 산출물은 명세이고, 코드는 그로부터 나옵니다. SpecScore는 그 명세를 위한 오픈 소스 파일 형식이며, 명령줄 인터페이스(CLI)가 검사합니다. 지속적 통합(CI), 곧 제안된 변경마다 도는 자동 검사가 이 저장소에서 그 검사를 실행합니다.
공통점.
Tessl이 잘하는 것.
Tessl에는 섞이기 쉬운 두 표면이 있습니다. 아래 메모는 2026년 10월 30일에 읽은 페이지를 바탕으로 둘을 구분해 둡니다.
명세를 소스로 삼는 분명한 논지
Simon Maple의 2025년 6월 27일 에세이는, 제품 요구사항 문서(PRD), 곧 무엇을 만들지 사람을 위해 쓴 산문은 대개 낡고, 코드만이 유일한 기준이 된다고 말합니다. 에세이의 대안은, 바꾸는 대상이 명세이고 LLM이 그로부터 코드, 테스트, 문서를 생성한다는 것입니다. 구호가 아니라 하나의 입장입니다.
에이전트 맥락을 위한 플랫폼
Tessl 문서는 레지스트리, 스킬을 검사하고 점수를 매기는 거버넌스, 평가(evals), 에이전트 전반의 관측 가능성을 설명합니다. 문서는 스킬이 저장소 안의 평범한 산출물이고, 플랫폼이 Claude Code, Cursor, Copilot, Gemini 등과 함께 동작한다고 말합니다. 거기에서의 점수는 스킬의 점수이지, 제품 명세의 점수가 아닙니다.
셸 검사가 있는 공식 명세 주도 타일
tessl-labs/spec-driven-development 타일은 공개 타일 저장소에서 MIT 라이선스입니다. 에이전트에게 인터뷰하고, .spec.md 파일을 쓰고, 승인을 기다린 다음 구현하도록 가르칩니다. 레지스트리 페이지는 scripts/validate-specs.sh와 scripts/check-spec-links.sh를 프론트매터, targets, [@test] 링크를 위해 나열합니다. 같은 페이지는 이 타일이 방향을 잡아 주는 맥락이며, 특별한 명령도 프레임워크도 없다고 말합니다.
기능 비교.
「명세를 소스로」는 Tessl의 에세이입니다. 타일은 오늘의 플랫폼 위에 놓인 스킬 묶음입니다. SpecScore는 버전이 있는 린터를 갖춘 형식입니다.
| 기능 | Tessl | SpecScore |
|---|---|---|
| 주요 역할 | 에이전트 스킬 플랫폼에, 명세 주도 타일과 명세를 소스로 삼는 2025년 에세이가 더해진 것 | 오픈 명세 형식 + CLI |
| 명세란 무엇인가 | 에세이: 오래 남고, 코드가 그로부터 생성되는 소스. 타일: 에이전트가 구현의 기준으로 삼고, 코드는 남겨 두는 .spec.md. | 코드 곁의 계약. Lint는 코드를 다시 생성하지 않습니다. |
| 명세의 형태 | 타일: YAML 프론트매터, targets 글롭, 테스트 파일로의 [@test] 링크 | Markdown + YAML, REQ: slug, Given/When/Then |
| 명세 검사 | 그 타일의 프론트매터와 링크를 위한, 타일에 함께 제공되는 셸 스크립트 | 이 저장소의 CI에서 SpecScore 형식에 대한 specscore spec lint. /score는 수동 AI 채점입니다. |
| 라이선스 | 타일은 MIT입니다. 플랫폼은 제품입니다. 문서는 플랫폼의 소스 코드를 공개하지 않습니다. | CC BY 4.0 형식 · Apache-2.0 CLI |
| 가격 | 2026년 10월 30일에 읽은 Tessl 홈페이지는 무료 등급(워크스페이스 하나에서 월 1,000크레딧)과 유료 엔터프라이즈 요금제를 설명합니다. | 형식과 CLI에는 요금이 없습니다 |
SpecScore가 더하는 것.
공개된 형식이지, 타일 스크립트가 아니다
타일의 셸 스크립트는 그 타일이 에이전트에게 쓰게 한 .spec.md 파일을 검사합니다. SpecScore가 검사하는 것은 이 사이트에 문서화된 형식입니다. dogfood.yml는 고정된 specscore 릴리스를 설치하고 specscore spec lint를 실행합니다. /score는 그 작업이 아닙니다. AI 리뷰어가 문제를 보고하면 0이 아닌 코드로 끝나는 수동 스킬입니다.
$ specscore spec lint features/apply-discount/README.md:0 [error] oq-section: Open Questions section not found features/apply-discount/README.md:0 [error] index-entries: Child directory not listed in index: refunds features/apply-discount/refunds:0 [error] readme-exists: README.md not found 3 violations found (3 errors)
어느 쪽이든 코드는 남는다. 에세이는 더 멀리 간다
2025년 에세이는 코드를 명세에서 다시 생성해야 한다고 말합니다. 2026년 10월 30일에 읽은 페이지의 타일은, 승인된 명세를 기준으로 에이전트가 구현한다고 하며, 소스 트리를 바꾸는 컴파일러는 설명하지 않습니다. SpecScore는 코드를 가져가지 않습니다. 명세는 리뷰되는 계약이고, 코드는 여러분의 것으로 남습니다.
요구사항의 정체성
타일은 요구사항을 targets와 [@test]로 파일에 향하게 합니다. SpecScore는 요구사항을 REQ: slug로 이름 붙이므로, 파일이 옮겨진 뒤에도 계획, 작업, 커밋 트레일러가 그것을 인용할 수 있습니다.
언제 어떤 것을 사용할까.
Tessl을 고르는 때는…
- 여러 에이전트와 저장소에서 공유하는 스킬을 위해 레지스트리, 평가, 거버넌스가 필요할 때.
- 명세를 소스로 삼는 에세이의 흐름을 방향을 잡아 주는 타일로 원할 때. 인터뷰하고, .spec.md를 승인한 다음 구현합니다.
- 이미 Tessl 플랫폼을 결제했거나 시험 중이고, 그 레지스트리의 명세 타일을 원할 때.
SpecScore를 사용하세요…
- Tessl을 설치하지 않는 저장소를 포함해, 명세 형식 자체가 CI에서 유효해야 할 때.
- 요구사항 ID와, 모델을 호출하지 않는 린터가 필요할 때.
- 스킬 플랫폼과 별도로, 크리에이티브 커먼즈 라이선스 아래 형식을 오픈 소스로 두고 싶을 때.
명세를 소스로, 그리고 검사할 수 있는 명세를.
낡은 PRD는 코드에 진다는 Tessl의 에세이는 맞습니다. 명세가 신뢰하는 대상으로 남는 방법이 형식 검사입니다. SpecScore는 명세에서 애플리케이션을 생성하지 않습니다. 구조, 링크, 상태가 잘못되었을 때 명세가 CI에서 실패하게 합니다.
플랫폼과 타일을 원하면 Tessl을. 풀 리퀘스트가 증명해야 하는 것이 git 안의 산출물이면 SpecScore를.
출처.
아래 공개 페이지는 2026년 10월 30일에 읽었습니다. 가격, 요금제 이름, 릴리스 라인은 바뀝니다.
피드백
이 비교는 공개적으로 이용 가능한 문서와 소스 코드를 기반으로 합니다. 잘못되었거나 오래된 정보가 있나요? 수정 issue를 열어주세요. SpecScore를 다른 도구와 비교해 주길 원하시나요? 요청해 주세요.