▲

코틀린 창시자의 새 언어: 영어 대신 명세(spec)로 LLM과 대화하기

 (codespeak.dev)
1P by GN⁺ 2시간전 | ★ favorite | 댓글 1개
  • CodeSpeak은 대규모 언어 모델(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 저장소를 포크한 사례가 제시됨
    • 혼합 프로젝트를 단계별로 다루는 튜토리얼 가이드가 제공됨

코드 → 명세 변환 기능 (예정)

  • 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 기반 코드 생성, 명세-코드 동기화, 혼합 프로젝트 지원이 주요 특징임
  • 실제 사례에서 코드 축소와 테스트 향상이 입증되어, 팀 단위 소프트웨어 엔지니어링의 생산성 향상 가능성을 제시함
▲
GN⁺ 2시간전  [-]
Hacker News 의견들

  • Joel Spolsky가 예일대 강연에서 말했듯, ‘명세(spec)로부터 프로그램을 생성’ 하려는 시도는 늘 실패해왔음
    명세가 프로그램을 완전히 정의할 정도로 상세하다면, 그 명세를 쓰는 일 자체가 프로그램을 짜는 것만큼 어렵다는 이야기임
    원문 강연 링크

    • 2007년의 ‘명세 기반 코드 생성’과 지금의 의미는 완전히 다름
      지금은 불완전한 프롬프트로도 프로그램을 생성할 수 있고, 프롬프트를 체계적으로 다루는 연구가 가치 있다고 봄
    • 이제는 코드가 점점 비정형적(amorphous) 으로 변하고 있음
      기능 추가보다 행동 제약과 구조적 불변성을 정의하는 쪽으로 확장성이 이동하고 있음
    • 회사에서 사람들이 절차적으로 글을 쓰는 걸 자주 봄
      “1. 사용자에게 정보를 입력받고, 2. HTTP 요청을 보내고, 3. 에러가 나면 보고한다” 같은 식인데,
      그럴 바엔 그냥 스크립트를 짜는 게 훨씬 빠르고 결정적이라 생각함
    • AI 이전 시대의 Joel이 생각 못 했던 해결책: ‘마음의 수정(crystal)’ 을 만들어 명세를 해석하게 하면 된다는 농담을 던짐

  • 이건 새로운 언어가 아니라, LLM 기반 개발을 위한 워크플로우와 도구임
    코드 대신 Markdown 명세 파일을 유지하고, codespeak가 명세 diff를 기반으로 코드를 수정하게 함
    장점은 프롬프트가 코드와 함께 버전 관리된다는 점이고, 단점은 명세가 코드의 모든 세부를 반영하지 못한다는 점임

    • C 언어도 결국 어셈블리 개발의 대체 워크플로우였다는 비유를 덧붙임
    • 결국 인간이 코드를 직접 만지지 않아도 되는 세상으로 가겠지만, 아직은 아님
      codespeak takeover라는 도구로 코드를 명세로 변환하고, 에이전트 세션의 프롬프트를 반영하도록 실험 중임
      단기적 ‘스프린트 모드’에서 장기적 ‘마라톤 모드’로 전환하는 개념이라 설명함
      관련 블로그 링크
    • 이걸 비즈니스로 운영하려는 건 무리라고 봄
      아이디어가 단순해 누구나 빠르게 재구현할 수 있고, 오픈소스 버전이 곧 대체할 것이라 예상함
    • 사소한 코드 수정(예: 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은 인코딩과 디코딩 사이에 별도의 처리 단계가 존재하며,
    학습 후에는 언어 자체가 그렇게 중요하지 않을 수도 있음
    관련 연구 링크

    • CodeSpeak은 LLM을 위한 게 아니라 인간을 위한 구조화 도구임
      인간이 원하는 걸 명확히 표현할 수 있도록 돕는 게 목적임

  • 굳이 이런 도구가 필요한지 모르겠음
    그냥 Markdown 명세를 직접 쓰고, 에이전트에게 코드를 생성하라고 하면 충분함

  • 튜토리얼의 “Prerequisites”에 Anthropic API 키가 필요하다고 되어 있음
    알파 버전이라 임시 조치일 수도 있지만, 왜 굳이 API를 써야 하는지 궁금함
    Claude Code 같은 세션에 직접 프롬프트를 주입해도 될 것 같음
    참고 링크

  • 이 프로젝트가 내가 진행 중인 LLM 실행기 언어 스펙과 매우 유사해서 흥미로움
    내 프로젝트 AIL은 YAML 기반으로 프롬프트 체인을 정의하고 실행함
    핵심은 ‘프롬프트 정제 엔진’ 을 두어 사용자의 자연어를 구조화된 명령으로 변환하는 것임
    예를 들어, 사용자의 의도를 분석해 단계별로 나누고, 현대 프롬프트 엔지니어링 표준에 맞게 최적화함
    이런 인터셉터가 있다면 “내가 방금 한 말을 CodeSpeak 형식으로 바꿔줘” 같은 흐름이 가능할 것임
    정말 멋진 아이디어라, 꼭 깊이 탐구해볼 생각임

답변달기