GitHub의 spec-kit에 대해 아무리 칭찬해도 부족하네요

저는 한동안 spec-driven 개발에 깊이 빠져 있었고, 새로운 트렌드가 생겨남에 따라 워크플로우를 개선해 왔습니다. spec-driven 개발을 아직 잘 모르신다면, 단순히 프롬프트나 일련의 프롬프트를 던지는 것보다 상세한 문서를 제공할 때 에이전트로부터 더 좋은 결과를 얻을 수 있다는 개념입니다. 제 여정은 다음과 같았습니다:

1년 전: AI와 대화하고 마크다운으로 디자인 문서를 생성한 뒤, 기본적으로 AI에게 "그거 해"라고 시켰습니다. 이건 연속적인 프롬프팅보다는 나았지만, 많은 이탈과 환각 등을 초래했습니다. 저는 종종 에이전트를 다시 문서로 되돌리거나, 요구 사항이나 수락 기준 등이 변경됨에 따라 문서에서 내용을 추가/삭제해야 했습니다.

6개월 전: 대화하고, 디자인 문서를 생성한 뒤, 그 디자인 문서로부터 상세한 로드맵을 생성했습니다. 단순한 디자인 문서보다 더 나은 결과를 얻었고, 에이전트는 진행 상황을 표시하는 일을 꽤 잘했습니다. 하지만 특히 큰 작업을 할 때는 여전히 이탈이나 다른 문제들을 겪었습니다. 때로는 무언가를 건너뛰기도 하고, 때로는 너무 작은 부분에만 집중해서 실질적인 진전 없이 토큰만 낭비하기도 했습니다.

3개월 전: 대화, 디자인 문서, 로드맵, 그리고 로드맵의 각 마일스톤을 작업 단위로 세분화했습니다. 이건 그냥 로드맵만 있을 때보다 훨씬 좋은 결과를 냈지만, 작업을 얻어내기까지 많은 프롬프팅이 필요했고, 작업이 로드맵이나 원래 디자인과 일치한다는 보장도 없었습니다.

1개월 전: spec-kit을 가지고 놀기 시작했는데 모든 게 훨씬 쉬워지고 신뢰할 수 있게 되었습니다. 제가 이미 사용하던 것과 기본적인 과정은 같지만, 에이전트가 작업에 집중하도록 설계된 방식으로 체계화되어 있습니다. spec-driven 개념에 관심이 있고 다음 단계로 나아가고 싶다면, 꼭 확인해보시길 강력히 추천합니다. 몇 가지 팁을 드립니다.

1. 무엇을 만들고 있는지에 대해 AI와 별도의 대화를 나누고, 프롬프트를 만드는 데 도움을 받으세요. 추가적인 맥락을 위해 spec-kit 코드나 웹사이트를 참고하게 하세요.

2. specify(명세화) 후에 항상 clarify(명확화)를 실행하세요. 생각하지 못했거나 포함하지 않았던 아이디어의 빈틈이나 추가적인 기회를 찾는 데 도움이 될 것입니다.

3. 작업 후에 analyze(분석)를 실행하여 작업과 계획을 비교하세요. 아마 많은 것을 찾아낼 겁니다. 게으르다면 그냥 AI에게 수정안을 내놓으라고 하세요.

4. 각 조각(slice) 사이마다 커밋하고, 모든 버킷(bucket)을 PR 하세요(AI 코드 리뷰를 곁들이면 더 좋습니다).

5. constitution(헌법) 프롬프트를 만들 때, 테스트 주도 개발(TDD) 원칙을 따르고, 설명적인 주석을 사용하며, 모든 커밋은 conventional commit 형식을 사용하라는 지침을 포함하세요.