# CodeSpeak - 코틀린 창시자의 새 언어: 영어 대신 명세(spec)로 LLM과 대화하기 > Clean Markdown view of GeekNews topic #27476. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27476](https://news.hada.io/topic?id=27476) - GeekNews Markdown: [https://news.hada.io/topic/27476.md](https://news.hada.io/topic/27476.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-14T05:33:40+09:00 - Updated: 2026-03-14T05:33:40+09:00 - Original source: [codespeak.dev](https://codespeak.dev/) - Points: 42 - Comments: 4 ## Summary 코틀린 창시자가 공개한 **LLM 기반 차세대 프로그래밍 언어**로, 개발자가 코드 대신 간결한 **명세(spec)** 를 작성하면 시스템이 자동으로 코드를 생성합니다. 명세 변경 시 코드 차이를 자동 반영하며, 수동 코드와 생성 코드가 공존하는 프로젝트도 지원합니다. 실제 오픈소스 사례에서 코드가 최대 10배 줄고 테스트 통과율이 향상되어, 팀 단위 개발의 유지보수 효율을 높이는 새로운 접근으로 주목받고 있습니다. 사실 언어라기 보다는 **LLM 기반 개발 워크플로우** 같이 느껴지네요. ## Topic Body - LLM을 기반으로 한 **차세대 프로그래밍 언어**로, 코드베이스를 **5~10배 축소**할 수 있음 - 개발자는 코드 대신 **간결한 명세(spec)** 를 작성하고, `codespeak build` 명령으로 코드가 자동 생성됨 - 명세가 변경되면, 시스템이 **명세 차이(diff)** 를 코드 차이로 변환해 반영함 - 수동 작성 코드와 생성 코드가 **혼합된 프로젝트**도 지원하며, 실제 오픈소스 사례에서 **테스트 통과율 향상**이 확인됨 - 복잡한 소프트웨어를 다루는 **팀 단위 엔지니어링**에 초점을 맞추며, 명세 중심 유지보수를 통해 **인간 친화적 개발 환경**을 지향함 --- ### CodeSpeak 개요 - CodeSpeak은 **LLM이 구동하는 차세대 프로그래밍 언어**로, 코드베이스를 5~10배 줄이는 것을 목표로 함 - 사이트 설명에 따르면 “Shrink your codebase 5–10x”라는 문구로 효율성을 강조함 - 이 언어는 **프로덕션급 시스템** 구축을 위한 도구로, 단순한 프로토타입이 아닌 장기 프로젝트용으로 설계됨 - **복잡한 소프트웨어를 개발하는 엔지니어 팀**을 주요 사용자로 상정하며, 개인 개발자 중심의 실험적 코딩이 아닌 **협업 중심 개발**을 지향함 ### 명세 기반 개발 방식 - CodeSpeak의 핵심은 **“Maintain Specs, Not Code”** 라는 철학 - 개발자는 간결한 명세(spec)를 작성하고, `codespeak build` 명령으로 코드가 자동 생성됨 - 명세가 수정되면, 시스템이 **명세의 변경(diff)** 을 **코드 변경(diff)** 으로 자동 변환함 - 이 접근법은 코드보다 명세를 유지·관리하는 것이 **인간에게 더 쉽다**는 점을 강조함 ### 혼합 프로젝트 지원 - CodeSpeak은 **기존 수동 코드와 생성 코드가 공존하는 프로젝트**를 지원함 - 예시로 Microsoft의 **MarkItDown** 저장소를 포크한 사례 소개 - 혼합 프로젝트를 단계별로 다루는 **[튜토리얼 가이드](https://codespeak.dev/blog/mixed-mode-tutorial-20260210)** 제공 ### 코드 → 명세 변환 기능 (예정) - CodeSpeak은 기존 코드를 분석해 **명세로 변환하는 기능**을 준비 중임 - 이를 통해 기존 코드 일부를 **5~10배 더 작은 명세로 대체**할 수 있음 - 명세 유지보수가 코드보다 **인간 친화적**임을 강조함 ### 실제 사례 연구 (Case Studies) - CodeSpeak은 여러 **오픈소스 프로젝트 코드**를 명세로 변환해 테스트함 - **yt-dlp**의 WebVTT 자막 지원: 255 LOC → 38 LOC, 6.7배 축소, 테스트 37개 추가 - **Faker**의 이탈리아 SSN 생성기: 165 LOC → 21 LOC, 7.9배 축소, 테스트 13개 추가 - **beautifulsoup4**의 인코딩 자동 감지: 826 LOC → 141 LOC, 5.9배 축소, 테스트 25개 추가 - **markitdown**의 EML→Markdown 변환기: 139 LOC → 14 LOC, 9.9배 축소, 테스트 27개 추가 - 각 사례에서 **테스트 통과율이 유지되거나 향상**되었으며, 명세 기반 접근의 실효성을 보여줌 ### 요약 - CodeSpeak은 **명세 중심의 AI 프로그래밍 언어**로, 코드 자동 생성과 유지보수 효율성을 결합 - **LLM 기반 코드 생성**, **명세-코드 동기화**, **혼합 프로젝트 지원**이 주요 특징 - 실제 사례에서 코드 축소와 테스트 향상이 입증되어, **팀 단위 소프트웨어 엔지니어링의 생산성 향상** 가능성을 제시 ## Comments ### Comment 53516 - Author: roxie - Created: 2026-03-21T22:20:31+09:00 - Points: 2 이걸 언어라고 부르는게 어그로인건지 그런 시대가 된건지 ### Comment 53013 - Author: brainer - Created: 2026-03-14T16:52:04+09:00 - Points: 2 > Joel Spolsky가 예일대 강연에서 말했듯, ‘명세(spec)로부터 프로그램을 생성’ 하려는 시도는 늘 실패해왔음 > 명세가 프로그램을 완전히 정의할 정도로 상세하다면, 그 명세를 쓰는 일 자체가 프로그램을 짜는 것만큼 어렵다는 이야기임 원칙적으로 동의하면서도 당연한게 애당초 완전은 없다는 궤델의 증명처럼, 완전한 프로덕트가 있을거라는 가정에서 시도를 비판하는거 같네요 ### Comment 52999 - Author: halfenif - Created: 2026-03-14T13:07:36+09:00 - Points: 1 MDD(Model Driven Dev.)를 생각나게 합니다. ### Comment 52985 - Author: neo - Created: 2026-03-14T05:33:40+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47350931) - Joel Spolsky가 예일대 강연에서 말했듯, **‘명세(spec)로부터 프로그램을 생성’** 하려는 시도는 늘 실패해왔음 명세가 프로그램을 완전히 정의할 정도로 상세하다면, 그 명세를 쓰는 일 자체가 프로그램을 짜는 것만큼 어렵다는 이야기임 [원문 강연 링크](https://www.joelonsoftware.com/2007/12/03/talk-at-yale-part-1-of-3/) - 2007년의 ‘명세 기반 코드 생성’과 지금의 의미는 완전히 다름 지금은 **불완전한 프롬프트**로도 프로그램을 생성할 수 있고, 프롬프트를 체계적으로 다루는 연구가 가치 있다고 봄 - 이제는 코드가 점점 **비정형적(amorphous)** 으로 변하고 있음 기능 추가보다 **행동 제약과 구조적 불변성**을 정의하는 쪽으로 확장성이 이동하고 있음 - 회사에서 사람들이 절차적으로 글을 쓰는 걸 자주 봄 “1. 사용자에게 정보를 입력받고, 2. HTTP 요청을 보내고, 3. 에러가 나면 보고한다” 같은 식인데, 그럴 바엔 그냥 **스크립트를 짜는 게 훨씬 빠르고 결정적**이라 생각함 - AI 이전 시대의 Joel이 생각 못 했던 해결책: **‘마음의 수정(crystal)’** 을 만들어 명세를 해석하게 하면 된다는 농담을 던짐 - 이건 새로운 언어가 아니라, **LLM 기반 개발을 위한 워크플로우와 도구**임 코드 대신 Markdown 명세 파일을 유지하고, `codespeak`가 명세 diff를 기반으로 코드를 수정하게 함 장점은 프롬프트가 코드와 함께 버전 관리된다는 점이고, 단점은 명세가 코드의 모든 세부를 반영하지 못한다는 점임 - C 언어도 결국 어셈블리 개발의 **대체 워크플로우**였다는 비유를 덧붙임 - 결국 인간이 코드를 직접 만지지 않아도 되는 세상으로 가겠지만, 아직은 아님 `codespeak takeover`라는 도구로 코드를 명세로 변환하고, **에이전트 세션의 프롬프트**를 반영하도록 실험 중임 단기적 ‘스프린트 모드’에서 장기적 ‘마라톤 모드’로 전환하는 개념이라 설명함 [관련 블로그 링크](https://codespeak.dev/blog/codespeak-takeover-20260223) - 이걸 **비즈니스로 운영**하려는 건 무리라고 봄 아이디어가 단순해 누구나 빠르게 재구현할 수 있고, 오픈소스 버전이 곧 대체할 것이라 예상함 - 사소한 코드 수정(예: off-by-one 버그)을 위해 명세를 바꿔야 한다면 비효율적임 **‘사소한 변경’ 허용 정책**이 필요하다고 제안함 전체적으로는 **점진적 의사코드 컴파일러**라는 개념이 흥미로움 - 너무 형식적이라 느껴짐 5년 뒤에는 이런 식으로 코드를 쓰지 않고, **영어 수준의 기술 명세**면 충분할 것 같음 - 이 접근은 언어라기보다 **명세를 코드로 매핑하는 툴링**임 하지만 모델은 비결정적이라, 같은 명세라도 매번 다른 결과가 나올 수 있음 명세는 본질적으로 **정보 손실이 큰 요약**이라, 대규모 코드베이스에서는 일관성 유지가 어려움 내가 보고 싶은 건 텍스트 명세 → **형식 명세(formal spec)** → 코드로 이어지는 검증 가능한 파이프라인임 - 결과가 항상 **논리적으로 올바르다면**, 코드가 달라도 상관없다는 반론이 있음 중요한 건 코드 자체보다 **행동 결과의 일관성**임 - 하지만 형식 명세도 매번 달라질 수 있음 명세가 코드보다 추상적일수록 다양한 구현이 가능하므로, **결정성**은 여전히 확보되지 않음 - 나는 AGENTS.md, DESIGN.md, TECHNICAL-SPEC.md를 만들어 **비공식 명세 기반 개발**을 함 자동화된 테스트가 진짜 명세 역할을 해야 한다고 생각함 - 모델이 비결정적이라는 주장에 의문을 제기함 **시드(seed)** 를 고정하면 동일 입력에 동일 출력을 얻을 수 있다고 봄 - 나는 **Kiro IDE**를 명세 생성기로 사용함 Cursor나 Antigravity는 인간 중심의 ‘vibe coding’에 최적화되어 있지만, Kiro는 **에이전트 중심의 명세 기반 개발**에 특화되어 있음 EARS, INCOSE 같은 구조화된 형식을 쓰고, **자동 일관성 검사**와 **속성 기반 테스트(PBT)** 를 생성함 명세가 탄탄하면 구현은 거의 자동으로 따라옴 여러 CLI 에이전트를 병렬로 돌려 완성도 높은 결과를 얻고 있음 - **형식적 프롬프트 언어**의 문제는 모호성이 아니라 **모델의 문맥 이해력 부족**임 같은 프롬프트라도 컨텍스트에 따라 결과가 달라짐 프롬프트를 형식화해도 모델이 코드베이스를 잘못 이해하면 소용없음 - 자주 듣는 조언은 두 가지임 1) **정기적으로 컨텍스트를 초기화**할 것 2) 에이전트에게 **유닉스 스타일의 도구**를 제공해, 간단한 의사영어 명령으로 상호작용하게 할 것 모델은 대화형 언어에 최적화되어 있으므로, **형식 언어를 직접 쓰기보단** 필요할 때만 활용하는 게 낫다고 봄 - 단순히 **결정적이고 형식적인 방법**으로 컴퓨터에 의도를 전달할 수 있으면 좋겠다는 바람을 표현함 - 이 개념은 LLM의 내부 구조를 잘못 이해한 전제에서 출발함 최근 연구에 따르면 LLM은 **인코딩과 디코딩 사이에 별도의 처리 단계**가 존재하며, 학습 후에는 언어 자체가 그렇게 중요하지 않을 수도 있음 [관련 연구 링크](https://news.ycombinator.com/item?id=47322887) - CodeSpeak은 LLM을 위한 게 아니라 **인간을 위한 구조화 도구**임 인간이 원하는 걸 명확히 표현할 수 있도록 돕는 게 목적임 - 굳이 이런 도구가 필요한지 모르겠음 그냥 **Markdown 명세를 직접 쓰고**, 에이전트에게 코드를 생성하라고 하면 충분함 - 튜토리얼의 “Prerequisites”에 **Anthropic API 키**가 필요하다고 되어 있음 알파 버전이라 임시 조치일 수도 있지만, 왜 굳이 API를 써야 하는지 궁금함 Claude Code 같은 세션에 직접 프롬프트를 주입해도 될 것 같음 [참고 링크](https://codespeak.dev/blog/greenfield-project-tutorial-20260209) - 이 프로젝트가 내가 진행 중인 **LLM 실행기 언어 스펙**과 매우 유사해서 흥미로움 [내 프로젝트 AIL](https://github.com/AlexChesser/ail)은 YAML 기반으로 프롬프트 체인을 정의하고 실행함 핵심은 **‘프롬프트 정제 엔진’** 을 두어 사용자의 자연어를 구조화된 명령으로 변환하는 것임 예를 들어, 사용자의 의도를 분석해 단계별로 나누고, **현대 프롬프트 엔지니어링 표준**에 맞게 최적화함 이런 인터셉터가 있다면 “내가 방금 한 말을 CodeSpeak 형식으로 바꿔줘” 같은 흐름이 가능할 것임 정말 멋진 아이디어라, 꼭 깊이 탐구해볼 생각임