▲

스펙 주도 개발(SDD) 이해하기: Kiro, Spec-Kit, Tessl

 (martinfowler.com)
9P by GN⁺ 8시간전 | ★ favorite | 댓글 3개
  • Spec-Driven-Development(SDD) 는 AI 기반 코딩에서 코드 작성 전에 명세서(spec)를 먼저 작성하는 접근 방식으로, 명세서가 개발자와 AI의 진실 공급원(source of truth) 역할을 수행
  • SDD는 세 가지 구현 수준으로 구분되며, spec-first(명세 우선 작성), spec-anchored(유지보수를 위한 명세 보존), spec-as-source(명세를 주요 소스 파일로 사용하며 개발자는 코드 직접 편집 안 함)로 단계적 발전
  • Kiro는 요구사항→설계→작업의 단순한 3단계 워크플로우를 제공하고, spec-kit은 헌법(constitution)이라는 강력한 규칙 기반 워크플로우를 사용하며, Tessl은 명세와 코드를 1:1로 매핑하는 spec-as-source 접근 방식 실험
  • 세 도구 모두 작은 버그 수정에는 과도한 프로세스를 요구하고, 마크다운 파일 리뷰가 코드 리뷰보다 번거로우며, 큰 컨텍스트 윈도우에도 불구하고 AI가 모든 지시사항을 제대로 따르지 못하는 한계 존재
  • SDD는 과거 모델 주도 개발(MDD)의 실패 사례를 상기시키며, 비결정성과 비유연성이라는 양쪽의 단점을 모두 가질 위험이 있어 실제 프로젝트에서의 유용성에 대한 검증 필요

스펙 주도 개발(SDD)의 정의

  • SDD는 코드 작성 전 명세서를 먼저 작성하는 "문서 우선(documentation first)" 접근 방식으로, 명세서가 개발자와 AI 모두에게 단일 진실 소스(single source of truth) 역할 수행
  • GitHub는 "소프트웨어 유지보수는 명세서의 진화를 의미하며, 개발의 공통 언어가 더 높은 수준으로 이동하고 코드는 최종 단계 접근 방식"이라고 정의
  • Tessl은 "명세서가 코드가 아닌 주요 산출물이 되는 개발 접근 방식으로, 명세서는 구조화되고 테스트 가능한 언어로 의도를 설명하며 에이전트가 이에 맞춰 코드 생성"이라고 설명
  • SDD는 세 가지 구현 수준으로 나뉨
    • Spec-first: 잘 구성된 명세서를 먼저 작성하고 AI 지원 개발 워크플로우에 사용
    • Spec-anchored: 작업 완료 후에도 명세서를 유지하여 해당 기능의 진화와 유지보수에 계속 활용
    • Spec-as-source: 명세서가 시간이 지나도 주요 소스 파일로 유지되며, 개발자는 명세서만 편집하고 코드는 직접 건드리지 않음
  • 모든 SDD 접근 방식은 spec-first이지만, 모두가 spec-anchored나 spec-as-source를 지향하는 것은 아니며, 시간 경과에 따른 명세서 유지 전략이 모호하거나 완전히 열려 있는 경우가 많음

명세서(spec)란 무엇인가

  • 명세서는 자연어로 작성된 구조화되고 행동 지향적인 산출물로서 소프트웨어 기능을 표현하고 AI 코딩 에이전트에게 가이드 역할 수행
  • 가장 일관된 정의는 명세서를 제품 요구사항 문서(PRD) 에 비유하는 것
  • 명세서는 코드베이스를 위한 일반적인 컨텍스트 문서와 구분되어야 함
    • 일반 컨텍스트에는 규칙 파일, 제품 및 코드베이스의 고수준 설명이 포함되며, 일부 도구는 이를 메모리 뱅크(memory bank) 라고 부름
    • 메모리 뱅크 파일은 코드베이스의 모든 AI 코딩 세션에서 관련되지만, 명세서는 특정 기능을 생성하거나 변경하는 작업에만 관련됨
  • 각 SDD 변형은 명세서의 구조, 세부 수준, 프로젝트 내 조직 방식에 대한 고유한 접근 방식을 정의

SDD 도구 평가의 어려움

  • SDD 도구와 접근 방식을 실제 사용에 가깝게 평가하는 것은 매우 시간 소모적
    • 다양한 규모의 문제, 그린필드/브라운필드 프로젝트에서 시도해야 하며, 중간 산출물을 피상적이 아닌 철저히 검토하고 수정하는 시간 필요
  • GitHub의 spec-kit 블로그 포스트는 "중요한 것은 당신의 역할이 단순히 방향을 잡는 것만이 아니라 검증하는 것이며, 각 단계에서 반영하고 개선해야 한다"고 강조
  • 세 도구 중 두 개는 기존 코드베이스에 도입하는 데 더 많은 작업이 필요해 보이며, 브라운필드 코드베이스에 대한 유용성 평가를 더욱 어렵게 만듦
  • 실제 코드베이스에서 일정 기간 동안 사용한 사람들의 사용 보고서를 듣기 전까지는 실제 작동 방식에 대한 많은 미해결 질문 존재

Kiro

  • Kiro는 세 도구 중 가장 단순하고 가벼운 도구로, 대부분 spec-first 접근 방식에 해당
    • 작업이나 사용자 스토리에 사용하는 예시만 발견되었으며, 시간이 지나면서 여러 작업에 걸쳐 spec-anchored 방식으로 요구사항 문서를 사용하는 방법에 대한 언급은 없음
  • 워크플로우: 요구사항 → 설계 → 작업
    • 각 워크플로우 단계는 하나의 마크다운 문서로 표현되며, Kiro는 VS Code 기반 배포판 내에서 이 3단계를 안내

  • Kiro의 주요 구성 요소

    • 요구사항(Requirements)
      • 각 요구사항이 "사용자 스토리"(As a... 형식)를 나타내는 요구사항 목록으로 구조화
      • 수락 기준은 GIVEN... WHEN... THEN... 형식 사용
    • 설계(Design)
      • 구성 요소 아키텍처 다이어그램, 데이터 흐름, 데이터 모델, 오류 처리, 테스트 전략, 구현 접근 방식, 마이그레이션 전략 등의 섹션 포함
      • 작업에 따라 일관된 구조인지 또는 변경되는지 불확실
    • 작업(Tasks)
      • 요구사항 번호로 추적되는 작업 목록
      • 작업을 하나씩 실행하고 작업별 변경 사항을 검토할 수 있는 추가 UI 요소 제공

  • Kiro의 메모리 뱅크

    • Kiro는 메모리 뱅크 개념을 "steering(조종)"이라고 부름
      • 내용이 유연하며, 워크플로우가 특정 파일의 존재에 의존하지 않는 것으로 보임
    • Kiro가 조종 문서 생성을 요청받을 때 생성하는 기본 구조는 product.md, structure.md, tech.md

Spec-kit

  • spec-kit은 GitHub의 SDD 버전으로, 다양한 일반 코딩 어시스턴트를 위한 작업 공간 설정을 생성할 수 있는 CLI로 배포
  • 구조 설정 후 코딩 어시스턴트의 슬래시 커맨드를 통해 spec-kit과 상호작용
  • 모든 산출물이 작업 공간에 직접 배치되므로, 논의된 세 도구 중 가장 커스터마이징 가능

  • Spec-kit의 워크플로우

    • 워크플로우: 헌법(Constitution) → 𝄆 명세화(Specify) → 계획(Plan) → 작업(Tasks) 𝄇
    • spec-kit의 메모리 뱅크 개념은 spec-driven 접근 방식의 전제 조건
      • 이를 헌법(constitution) 이라고 부르며, 모든 변경에 항상 적용되어야 하는 "불변" 고수준 원칙 포함
      • 워크플로우에서 많이 사용되는 매우 강력한 규칙 파일

  • Spec-kit의 작동 방식

    • 각 워크플로우 단계(specify, plan, tasks)에서 bash 스크립트와 템플릿을 사용하여 파일 및 프롬프트 세트를 인스턴스화
    • 워크플로우는 파일 내 체크리스트를 많이 활용하여 필요한 사용자 명확화, 헌법 위반, 연구 작업 등을 추적
      • 각 워크플로우 단계의 "완료 정의(definition of done)" 같은 역할 (AI가 해석하므로 100% 보장은 없음)
    • 하나의 명세서는 여러 파일로 구성됨
      • 예: data-model, plan, tasks, spec, research, api, component 등 8개 파일

  • Spec-kit의 접근 방식

    • GitHub는 처음에는 spec-anchored 접근 방식을 지향하는 것으로 보임
      • "명세서를 정적 문서가 아닌 프로젝트와 함께 진화하는 살아있는 실행 가능한 산출물로 재고하고 있으며, 명세서는 공유된 진실 공급원이 됨"
    • 그러나 spec-kit은 생성되는 모든 명세서에 대해 브랜치를 생성하므로, 명세서를 기능의 수명이 아닌 변경 요청의 수명 동안 살아있는 산출물로 보는 것으로 해석됨
    • 커뮤니티 논의에서도 이 혼란에 대해 이야기하고 있으며, spec-kit은 여전히 spec-first에만 해당하고 시간이 지나도 spec-anchored는 아닌 것으로 보임

Tessl Framework

  • Tessl Framework는 비공개 베타 단계이며, spec-kit처럼 다양한 코딩 어시스턴트를 위한 작업 공간 및 구성 구조를 생성할 수 있는 CLI로 배포
  • CLI 명령은 MCP 서버로도 작동

  • Tessl의 특징

    • 세 도구 중 유일하게 spec-anchored 접근 방식을 명시적으로 지향하며, spec-as-source 수준의 SDD도 탐구 중
    • Tessl 명세서는 유지 관리 및 편집되는 주요 산출물 역할을 할 수 있으며, 코드는 상단에 // GENERATED FROM SPEC - DO NOT EDIT 주석으로 표시
      • 현재는 명세서와 코드 파일 간 1:1 매핑, 즉 하나의 명세서가 코드베이스의 한 파일로 변환
      • 여전히 베타 단계이며 다양한 버전을 실험 중이므로, 하나의 명세서가 여러 파일이 있는 코드 구성 요소로 매핑되는 수준으로도 발전 가능

  • Tessl 명세서 구조

    • @generate나 @test 같은 태그는 Tessl에게 무엇을 생성할지 지시
    • API 섹션은 코드베이스의 다른 부분에 노출되는 최소한의 인터페이스를 명세서에 정의하는 아이디어를 보여주며, 생성된 구성 요소의 중요한 부분이 유지 관리자의 완전한 통제 하에 있도록 보장
    • tessl build를 실행하면 해당 JavaScript 코드 파일 생성

  • Tessl의 추상화 수준

    • spec-as-source를 위한 명세서를 코드 파일당 상당히 낮은 추상화 수준에 배치하면, LLM이 수행해야 하는 단계 및 해석의 양과 따라서 오류 가능성 감소
    • 이렇게 낮은 추상화 수준에서도 동일한 명세서에서 여러 번 코드를 생성할 때 비결정성 관찰
      • 명세서를 반복적으로 작성하고 코드 생성의 반복 가능성을 높이기 위해 점점 더 구체적으로 만드는 과정은 모호하지 않고 완전한 명세 작성의 함정과 과제를 상기시킴

관찰 사항 및 질문

  • 하나의 워크플로우로 모든 규모를 다룰 수 있는가?

    • Kiro와 spec-kit은 각각 하나의 독단적인 워크플로우를 제공하지만, 둘 다 대부분의 실제 코딩 문제에 적합하지 않을 가능성이 있음
    • 문제 크기에 맞는 충분한 다양성을 제공하는지 불분명
      • 작은 버그를 Kiro로 수정하려고 했을 때, 워크플로우가 망치로 호두를 깨는 것 같았음
      • 요구사항 문서가 작은 버그를 총 16개 수락 기준이 있는 4개 "사용자 스토리"로 변환
    • spec-kit 사용 시에도 어떤 크기의 문제에 사용해야 할지 불확실
      • 과거 팀에서 3-5 포인트 스토리가 될 기능을 시도했을 때, spec-kit이 취한 단계 수와 생성한 마크다운 파일 양이 문제 크기에 비해 과도하게 느껴짐
      • 동일한 시간에 "일반" AI 지원 코딩으로 기능을 구현할 수 있었을 것이며, 훨씬 더 제어력을 느꼈을 것
    • 효과적인 SDD 도구는 다양한 크기와 유형의 변경을 위해 최소한 몇 가지 다른 핵심 워크플로우에 대한 유연성 제공 필요

  • 코드 리뷰보다 마크다운 리뷰?

    • spec-kit은 검토할 많은 마크다운 파일을 생성
      • 서로 반복적이고 이미 존재하는 코드와도 반복적
      • 일부는 이미 코드를 포함하고 있어 전체적으로 매우 장황하고 검토하기 지루함
    • Kiro에서는 3개 파일만 얻고 "요구사항 > 설계 > 작업"의 멘탈 모델을 이해하기 더 직관적이어서 조금 더 쉬움
      • 하지만 Kiro도 수정을 요청한 작은 버그에 비해 너무 장황함
    • 솔직히 이 모든 마크다운 파일보다 코드를 검토하는 것이 낫다는 생각
    • 효과적인 SDD 도구는 매우 좋은 명세서 검토 경험 제공 필요

  • 잘못된 통제감?

    • 이 모든 파일, 템플릿, 프롬프트, 워크플로우, 체크리스트에도 불구하고 에이전트가 궁극적으로 모든 지시사항을 따르지 않는 경우를 자주 목격
    • 컨텍스트 윈도우가 더 커진 것은 SDD의 활성화 요인 중 하나로 언급되지만, 윈도우가 더 크다고 해서 AI가 그 안의 모든 것을 제대로 파악한다는 의미는 아님
    • 예시
      • spec-kit은 계획 중에 연구 단계가 있고 기존 코드에 대해 많은 연구를 수행했지만, 궁극적으로 에이전트는 이것이 기존 클래스에 대한 설명이라는 점을 무시하고 새로운 명세로 받아들여 모두 다시 생성하여 중복 생성
      • 지시사항을 무시하는 예뿐만 아니라, 지시사항(예: 헌법 조항 중 하나)을 너무 열심히 따르려다 과도하게 수행하는 에이전트도 목격
    • 과거 경험상 우리가 구축하는 것을 통제하는 최선의 방법은 작고 반복적인 단계였으므로, 많은 사전 명세 설계가 좋은 아이디어인지 매우 회의적
    • 효과적인 SDD 도구는 반복적인 접근 방식을 수용해야 하지만, 작은 작업 패키지는 SDD의 아이디어와 거의 상반되는 것처럼 보임

  • 기능적 명세와 기술적 명세를 효과적으로 분리하는 방법?

    • SDD에서 기능적 명세와 기술적 구현 사이의 분리를 의도적으로 하는 것은 일반적인 아이디어
      • 근본적인 열망은 궁극적으로 AI가 모든 솔루션과 세부 사항을 채우고 동일한 명세로 다른 기술 스택으로 전환할 수 있다는 것
    • 실제로 spec-kit을 시도할 때 언제 기능적 수준에 머물러야 하고 언제 기술적 세부 사항을 추가할 때인지 자주 혼란스러웠음
      • 튜토리얼과 문서도 이에 대해 일관성이 없었으며, "순수하게 기능적"이 실제로 무엇을 의미하는지에 대한 다른 해석 존재
    • 요구사항과 구현을 제대로 분리하지 못한 많은 사용자 스토리를 떠올려보면, 우리 직업 전체가 이를 잘 수행한 기록이 좋지 않음

  • 대상 사용자는 누구인가?

    • 많은 spec-driven 개발 도구의 데모와 튜토리얼에는 제품 및 기능 목표 정의 같은 것이 포함되며, "사용자 스토리" 같은 용어도 사용
    • 여기서의 아이디어는 AI를 cross-skilling의 활성화 요인으로 사용하여 개발자가 요구사항 분석에 더 적극적으로 참여하도록 하는 것일 수 있음
      • 또는 개발자가 이 워크플로우에서 작업할 때 제품 담당자와 페어링?
    • 이 중 어느 것도 명시적으로 설명되지 않으며, 개발자가 이 모든 분석을 수행하는 것이 당연한 것처럼 제시됨
    • 그렇다면 SDD는 어떤 문제 크기와 유형을 위한 것인가?
      • 아마도 아직 매우 불명확한 큰 기능에는 적합하지 않을 것이며, 그런 경우 확실히 더 전문적인 제품 및 요구사항 기술과 연구 및 이해관계자 참여 같은 많은 다른 단계 필요

  • Spec-anchored와 spec-as-source: 과거로부터 배우고 있는가?

    • 많은 사람들이 SDD와 TDD 또는 BDD 사이의 유사점을 그리지만, 특히 spec-as-source의 경우 살펴봐야 할 또 다른 중요한 유사점은 MDD(모델 주도 개발)
    • 경력 초기에 MDD를 많이 사용한 몇 가지 프로젝트에서 작업했으며, Tessl Framework를 시도할 때 계속 이것을 상기하게 됨
      • MDD의 모델은 기본적으로 명세서였지만 자연어가 아닌 맞춤형 UML이나 텍스트 DSL로 표현
      • 이러한 명세서를 코드로 변환하기 위해 맞춤형 코드 생성기 구축

  • MDD와 SDD의 비교

    • 궁극적으로 MDD는 비즈니스 애플리케이션에서 성공하지 못했으며, 어색한 추상화 수준에 있고 너무 많은 오버헤드와 제약 생성
    • 그러나 LLM은 MDD의 오버헤드와 제약 중 일부를 제거하므로, 이제 명세 작성에 집중하고 코드를 생성할 수 있다는 새로운 희망 존재
    • LLM을 사용하면 미리 정의되고 파싱 가능한 명세 언어로 제약받지 않으며, 정교한 코드 생성기를 구축할 필요도 없음
      • 그 대가는 물론 LLM의 비결정성
    • 파싱 가능한 구조는 유효하고 완전하며 일관된 명세를 작성하는 데 많은 도구 지원을 명세 작성자에게 제공할 수 있었던 장점도 있었으며, 이제 이를 잃고 있음
    • spec-as-source, 심지어 spec-anchoring도 MDD와 LLM 모두의 단점으로 끝날 수 있음: 비유연성 그리고 비결정성
    • 과거의 spec-from-code 시도를 살펴보고 오늘날 spec-driven을 탐구할 때 이로부터 배워야 함

결론

  • 개인적으로 AI 지원 코딩을 사용할 때 코딩 에이전트에게 제공할 명세 형태를 신중하게 작성하는 데 시간을 할애하는 경우가 많음
    • 따라서 spec-first의 일반 원칙은 많은 상황에서 확실히 가치 있음
  • 명세 구조화 방법에 대한 다양한 접근 방식은 매우 필요하며, 현재 실무자들로부터 가장 자주 받는 질문 중 하나
    • "메모리 뱅크를 어떻게 구조화하나요?", "AI를 위한 좋은 명세 및 설계 문서를 어떻게 작성하나요?"
  • 그러나 "spec-driven development"라는 용어는 아직 잘 정의되지 않았으며, 이미 의미론적으로 확산됨
    • 최근에는 "spec"을 기본적으로 "상세한 프롬프트"의 동의어로 사용하는 것도 들음

  • 도구에 대한 평가

    • 일부는 기존 워크플로우를 AI 에이전트에게 너무 문자 그대로 제공하려고 시도하여, 궁극적으로 검토 과부하 및 환각 같은 기존 과제를 증폭시킬 수 있음
    • 특히 많은 파일을 생성하는 더 정교한 접근 방식의 경우, 독일어 합성어 "Verschlimmbesserung"(개선하려다 더 나빠지게 만드는 것)을 생각하게 됨
      • 더 좋게 만들려는 시도에서 무언가를 더 나쁘게 만들고 있는 것은 아닌지 의문
▲
jjw9512151 5시간전  [-]

사실 소프트웨어 공학에서 배운걸 마크다운으로 한다고 생각하면 간단하고 실용적입니다. 요구사항명세서만 잘써도되죠.

답변달기
▲
aer0700 6시간전  [-]

이전에 document driven develope 나 readme driven develope 같은 이야기들이랑 비슷해보이네요.
https://news.hada.io/topic?id=15502

답변달기
▲
GN⁺ 8시간전  [-]
Hacker News 의견

  • 최근 SDD(명세 주도 개발) 트렌드를 지켜보고 있음, 이 흐름이 합리적이지만 마치 pre-agile 시대의 기능 명세서와 설계문서 시대로 다시 돌아가는 듯한 느낌을 받음, 완전히 Big Design Up Front는 아니지만 점점 ‘동작하는 소프트웨어 == 완벽한 문서화’로 가는 모양새임
    Big Design Up Front 참고, Agile Manifesto 참고

    • 기능 명세서와 설계문서는 결국 자연어로 코딩하는 것과 같음, 예전에는 사람이 이것을 프로그래밍 언어로 다시 코딩해야 했지만 이제는 LLM(대형 언어 모델) 같은 자동화된 컴파일러가 이 작업을 대신하기 시작함, 이 과정에서 한 단계를 건너뛸 수 있게 된 것임(성공률은 다양함)<br /> 반면 애자일은 소프트웨어를 어떤 언어로 만들든 신경 쓰지 않음, 본질은 ‘관리자를 배제’하고 개발자가 관리 업무까지 직접 하는 데 있음, 12가지 원칙에서 관리자가 없을 때 개발자가 해야 할 일에 대해 더 자세히 다룸

    • Behaviour Driven Design은 Test Driven Design처럼 ‘살아있는 명세서’를 만들어낼 수 있음, 도메인 탐색 기준부터 테스트 통과 여부까지 사람이 읽을 수 있는 문서 형태로 남기고, 테스트 하네스와 직접 연결해 현행 기능을 검증할 수 있음, 이렇게 하면 BDD 리포트를 통해 명확하게 검증되고 협업·반복 가능한 명세 문서를 갖게 되며, 초기 불필요한 작업 없이 애자일·JIT·YAGNI까지 모두 챙길 수 있음, 굳이 워터폴로 돌아갈 필요가 없음

    • 소규모 설계부터 시작할 수도 있음, 한두 페이지 명세를 작성하고 LLM으로 코드와 테스트를 생성한 뒤 반복적으로 보완하는 식임, 만약 100% LLM 코딩을 신뢰한다면 사양 입력(영어 프롬프트)을 체계적으로 관리하는 게 논리적임, 프롬프트를 버리지 않고 정리함으로써 향후 재사용하거나 추가적인 제약을 명확하게 줄 수 있음<br /> 하지만 LLM을 중요한 프로덕션 코드에 쓰는 건 불안해서 샌드박스/테스트/데모 목적으로만 실험 중임, 코드 품질이 그렇게까지 중요하지 않은 곳에만 활용함

    • Spec driven development 자체는 좋은 아이디어임, 그러나 현재 구현체들은 구조화되지 않은 markdown 파일을 agent에게 넘겨주고 제대로 결과가 나오지 않아 실제로는 재현성이 전혀 없음, 에이전트가 명세 작성까지 하면 stub 코드·테스트 코드까지 자동 변환 가능한 구조화된 명세가 되어야 함, markdown만으로 버릴 게 아니라 코드 생성기와 연동한다면 훨씬 재현성이 좋아질 것임, 실제로 그렇게 해보면 반복 용 코드 생성에 소요되는 시간을 크게 단축시킬 수 있음

  • SpecKit을 써보면서 정말 흥미롭고 만족스러웠지만, 현실의 복잡한 예시나 활용법을 찾는 데 어려움을 겪었음, 튜토리얼은 대부분 단순 설치 후 ‘투두리스트 앱 만들기’ 수준에 머물러 있음, 기존 레거시 코드베이스를 단계적으로 개선하거나 리팩터링하는 실제 사례나, spec driven development가 처음부터 적용되지 않은 대형 프로젝트에서 어떻게 접근해야 하는지 공유해줬으면 좋겠음

    • 나 역시 BDD 방식과 CLI 기반 코딩을 병행하면서 진짜 코드로 직접 기능을 기록하는 게 길고 장황한 markdown보다 훨씬 효과적임을 실감했음, AI에게 따라오게 할 체크리스트가 필요하다면 agents.md 같은 파일이 있으면 충분함, 한 번 해당 coding 패턴과 비기능 요구사항(NFR)만 기록해두면 에이전트가 명확하게 따르도록 할 수 있음

    • 진짜 활용하려면 template이나 source code를 직접 읽어봐야 실제로 뭐가 돌아가는지 파악할 수 있음, 이런 프로젝트에서는 오히려 당연한 과정이라고 생각함

  • Thoughtworks 출신 AI 기반 딜리버리 전문가 소개에 이어 memory banks 이야기가 나오길래 바로 공감했음, 우리도 ‘AI가 대세’인 현장에서 일했더니 메모리 뱅크가 커지면 오히려 AI가 방향을 잃고 결과물도 뒤죽박죽됨, 결국 제품을 완전히 이해하는 사람이 직접 AI를 리드해야만 현장에 실제 적용 가능함, AI가 얼마나 나를 속였는지 수도 없이 경험했고, 인간이 직접 다시 안내해주면 늘 사과하고 이해는 하지만, 그래서 뭐가 달라지진 않음, AI가 자기들끼리 쓰는 수많은 문서를 다 읽고 검증하는 것도 현실적으로 불가함, 차라리 그 시간에 직접 일하는 게 훨씬 낫겠다는 생각임

    • memory bank란 뭘 의미하는지, 그리고 그 역할에 대해 구체적으로 뭘 말하고 싶은 건지 궁금함

    • 현 시점에서 memory 기능은 오히려 악영향임, 제대로 된 ‘검색/조회’ 전략 없이 사용하면 오히려 좋지 않은 결과만 증폭됨, 대부분 memory 시스템이 단일 채팅 패러다임에 맞춰 설계되어서 다양한 환경에선 문제만 발생함, 진짜 ‘기억’이란 메인 에이전트와 분리된 ‘메타 인지/디폴트 모드 네트워크’를 통해 비동기로 태스크 구조와 문맥을 설계한 뒤, 각 프롬프트마다 이 메타 모델이 방향을 잡아주는 방식, 즉 ‘에이전트 기반 메모리’가 맞음

    • LinkedIn 같은데 ‘thought leader’ 직함 붙여놓은 것도 이해가 안 감, 요즘 그런 타이틀 의미가 뭔지 진짜 알기 어렵다는 생각임

  • 최근 2주간 SpecKit과 Claude Code로 두 가지 신규 프로젝트에서 실험했던 경험을 공유하고 싶음, 혼자서 두 프로젝트 모두 개발했기 때문에 실험해봐도 부담 없었음, 첫 프로젝트는 SpecKit에 그대로 맡겨 진행했는데 10일 걸려 모든 태스크를 끝냈지만 결과물의 테스트 대부분이 실패하고 빌드도 깨짐, 문제를 수정하느라 똑같이 시간을 들여야 했고 Claude가 결국 하나 고치면 또 다른 부분을 깨뜨려서 신뢰도가 엄청 떨어졌음<br /> 두 번째 프로젝트에선 작은 단위로 반복하고자 SpecKit 플래닝 이후 slash 커맨드를 추가해 backlog.md를 만들고, plan-sprint로 스프린트 목표와 작업 상세가 포함된 파일을 생성, implement-sprint로 일괄 처리했음. 하지만 이 과정도 구현 명령을 따르지 않아 몇 번이나 과정을 수정해도 테스트를 안 만들거나, 태스크를 빼먹음<br /> 그래서 세팅을 또 바꿔서, 특정 태스크만 다루는 subagent를 두고, implement-sprint는 오케스트레이터로만 활용하는 형태로 전환함. 이러면 각 스프린트마다 코드 상태를 검토할 수 있어서 훨씬 신뢰도가 높았음. 아직도 테스트가 실패해도 끝냈다고 할 때가 있지만, 직접 전체를 다 봐야 하는 것보다 수월함<br /> 현재 가설은 Claude가 TDD에 취약하다는 점임, 테스트를 먼저 작성하는 단계에서 항상 문제를 겪음, 다음엔 테스트를 구현 끝나고 작성하는 방식 전환을 시도할 계획임, 이상적이진 않지만 이렇게라도 생산성을 높여야 직접 코딩보다 나을 듯함

  • 여러 툴이 대부분 ‘명세 먼저’ 전략에 맞춰져 있고 명세 유지관리 방안은 애매하다는 점이 흥미로웠음, 개인적으로 cofounder와 함께 ‘spec as source’에 올인 중임, 명세를 진짜 소스로 삼는게 가장 흥미로운 활용법이라 생각하고 도전 중이지만, 실제로 자리잡게 하는 건 많이 어려움. 만약 관련 경험이나 피드백 있으면 꼭 듣고 싶음<br /> 우리의 실험 대상인 specific.dev도 혹시 관심 있다면 써보고 알려주길 부탁함

    • 명세가 정말 소스라면 그건 곧 그 명세 자체가 실행 가능한 형식 언어(프로그래밍 언어)가 되어야 함, 그렇지 않으면 명세는 명세일 뿐, 소스코드는 소스코드 자체임, 결국 ‘좋은 코드’가 뭔지 배워야 하는 건 모두 마찬가지임

  • Kiro의 spec-driven workflow를 써봤더니 작업 리스트를 엄청나게 쏟아냄(작업마다 하위작업 4개 이상, 전체 12개 작업 이상), 워크플로우 자체는 괜찮았지만 예측 불가하게 코드를 삭제하고 롤백도 안 해줌, IDE로 만드느라 UI 예외처리에 리소스를 뺏기는 듯, 복잡하게 쪼개는 것보다 간단히 반복하며 개선하는 게 더 쉬움, “호두를 깨기 위해 대형 해머를 쓰는 격”임

  • 커스텀 slash 커맨드로 입력값을 잘 구조화된 프롬프트로 포장하는 방식이 마음에 들었음, agents.md 등에서 쪼개서 나온 부분을 컨텍스트로 함께 주입하는 점도 좋음<br /> 다만, 매듭을 다 풀겠다는 시도가 오히려 해머로 호두를 깨는 느낌이 드는(복잡성을 낳는) 부분은 마음에 안 듦, 하지만 필요할 때만 추가 slash 커맨드(/experiment, /stub 등)로 컨텍스트 관리를 선택적으로 할 수 있으면 더 가벼워질 수 있다고 생각함, 마지막엔 "/wrap-up"처럼 마무리 전용 명령으로 모든 매듭을 한 번에 묶는 식, 수술 끝나고 의사가 전체 점검하는 느낌임

  • SpecKit 사용하며 늘 “언제쯤 이 모든 spec을 단일한 진짜 기준(ground truth)으로 합치지?”하는 의문이 있었음, 그 단계가 아예 없는 것 같아 아쉬웠음<br /> 이제는 인간과 에이전트 사이 커뮤니케이션 명세(spec)가 어떤 모습이어야 할지 정의/설계하는 과제가 남음, Birgitta가 말한 ‘spec anchored’ 개념을 실현하기 위해 고민 중임

    • AI가 등장하면서 이제 이런 표준을 진짜 정의해야 할 시점임을 느낌, 인간이 읽고 관리할 수 있을 정도로 (완전히가 아니라 부분적으로도 LLM 컨텍스트에 들어갈 수 있을 만큼) 명세를 정형화하고, 일부 정보만 ingest해도 핵심 의도와 설계를 유지하며 실질적인 작업이 가능한 형태여야 함<br /> UML·Rational Rose류 시도가 실패한 건, 의도가 구체적으로 들어가지 않고 그림으로만 남아서 문서화·유지·리팩터링 단계에만 썼기 때문이라고 봄, 결과적으로 이미 출시하고 나서야 쓸모가 생겨버려 무의미해졌음<br /> 이제는 C4 모델같은 새로운 방식에 주목하게 됨

  • SDD가 갑자기 대세가 된 이유는 모르겠지만, 개인적으로는 단순히 명세 파일을 만들어 ‘최종 산출물을 미리 파악’하고, 프로젝트를 잘게 쪼갤 때 진행 상황을 추적하는 데 실용성을 느끼고 있음, 별도의 툴이나 프레임워크는 쓰지 않고 markdown 파일만 활용 중임, 그 이상 복잡한 체계는 딱히 가치를 못 느꼈음

  • spec-kit를 처음 사용할 땐 정말 기대감이 컸지만, 실제로는 “동굴에서 로봇을 만드는” 단계까지 필요한 과업을 무리하게 만들고, 단순히 나사를 조이기만 해도 될 일을 과하게 확장시켜서 고치다가 지쳐서 그만두게 되었음, 과도하게 복잡한 워크플로우가 보정할 가치도 느끼지 못할 정도라고 생각함

답변달기