최근 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를 처음 사용할 땐 정말 기대감이 컸지만, 실제로는 “동굴에서 로봇을 만드는” 단계까지 필요한 과업을 무리하게 만들고, 단순히 나사를 조이기만 해도 될 일을 과하게 확장시켜서 고치다가 지쳐서 그만두게 되었음, 과도하게 복잡한 워크플로우가 보정할 가치도 느끼지 못할 정도라고 생각함
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’ 개념을 실현하기 위해 고민 중임
SDD가 갑자기 대세가 된 이유는 모르겠지만, 개인적으로는 단순히 명세 파일을 만들어 ‘최종 산출물을 미리 파악’하고, 프로젝트를 잘게 쪼갤 때 진행 상황을 추적하는 데 실용성을 느끼고 있음, 별도의 툴이나 프레임워크는 쓰지 않고 markdown 파일만 활용 중임, 그 이상 복잡한 체계는 딱히 가치를 못 느꼈음
spec-kit를 처음 사용할 땐 정말 기대감이 컸지만, 실제로는 “동굴에서 로봇을 만드는” 단계까지 필요한 과업을 무리하게 만들고, 단순히 나사를 조이기만 해도 될 일을 과하게 확장시켜서 고치다가 지쳐서 그만두게 되었음, 과도하게 복잡한 워크플로우가 보정할 가치도 느끼지 못할 정도라고 생각함