AI를 통한 사양 개발 : 새로운 오픈 소스 툴킷으로 시작
코딩 에이전트가 더욱 강력 해짐에 따라 패턴이 나타났습니다. 목표를 설명하고 코드 블록을 되 찾으십시오. 종종… 제대로 보이지만 작동하지 않습니다. 이 “Vibe-Coding”접근 방식은 빠른 프로토 타입에 적합하지만 심각한 미션 크리티컬 응용 프로그램을 구축하거나 기존 코드베이스 작업을 할 때는 덜 신뢰할 수 있습니다.
때로는 코드가 컴파일되지 않습니다. 때로는 문제의 일부를 해결하지만 실제 의도를 놓치게됩니다. 스택이나 아키텍처는 선택한 것이 아닐 수도 있습니다.
이 문제는 코딩 에이전트의 코딩 능력이 아니라 우리의 접근 방식입니다. 우리는 코딩 에이전트를 검색 엔진과 같은 문자 그대로 생각하는 쌍 프로그래머처럼 취급해야합니다. 그들은 패턴 인식에 탁월하지만 여전히 명백한 지시가 필요합니다.
그렇기 때문에 정적 문서가 아니라 프로젝트와 함께 진화하는 살아있는 실행 가능한 유물로 사양을 다시 생각하고 있습니다. 사양은 공유 된 진실의 원천이됩니다. 무언가가 말이되지 않으면 사양으로 돌아갑니다. 프로젝트가 복잡 해지면 개선합니다. 작업이 너무 커지면 분해합니다.
사양 구동 개발을위한 새로운 오픈 소스 툴킷 인 Spec Kit는 Github Copilot, Claude Code 및 Gemini CLI를 포함한 도구를 사용하여 코딩 에이전트 워크 플로우에 사양 개발을 가져 오는 구조화 된 프로세스를 제공합니다.
사양 키트를 사용한 사양 중심 프로세스는 무엇입니까?
사양 키트는 사양을 엔지니어링 프로세스의 중심으로 만듭니다. 사양을 작성하고 제쳐 놓는 대신 사양은 구현, 체크리스트 및 작업 분석을 유도합니다. 당신의 주요 역할은 조종하는 것입니다. 코딩 에이전트는 대부분의 작문을 수행합니다.
명확한 체크 포인트로 4 단계로 작동합니다. 그러나 주요 통찰력은 다음과 같습니다. 각 단계에는 특정 작업이 있으며 현재 작업이 완전히 검증 될 때까지 다음 단계로 이동하지 않습니다.
프로세스가 분류되는 방법은 다음과 같습니다.
- 지정하십시오: 당신은 당신이 구축하는 것과 그 이유에 대한 높은 수준의 설명을 제공하며 코딩 에이전트는 자세한 사양을 생성합니다. 이것은 기술 스택이나 앱 디자인에 관한 것이 아닙니다. 사용자 여행, 경험 및 성공의 모습에 관한 것입니다. 누가 이것을 사용할 것인가? 그들에게 어떤 문제가 해결됩니까? 그들은 어떻게 상호 작용합니까? 어떤 결과가 중요합니까? 그것을 만들고 싶은 사용자 경험을 매핑하고 코딩 에이전트가 세부 사항을 살리도록하십시오. 결정적으로, 이것은 사용자와 그들의 요구에 대해 더 많이 배울 때 진화하는 살아있는 인공물이됩니다.
- 계획: 이제 기술을 얻습니다. 이 단계에서는 코딩 에이전트에 원하는 스택, 아키텍처 및 제약 조건을 제공하며 코딩 에이전트는 포괄적 인 기술 계획을 생성합니다. 회사가 특정 기술에 대한 표준화되면 여기에서 그렇게 말하는 곳입니다. 레거시 시스템과 통합하거나 규정 준수 요구 사항이 있거나 성능 대상이있는 경우 모든 것이 여기에 있습니다. 여러 가지 계획 변형을 요청하여 다양한 접근 방식을 비교하고 대조 할 수 있습니다. 코딩 에이전트가 내부 문서를 사용할 수있게하는 경우 건축 패턴과 표준을 계획에 직접 통합 할 수 있습니다. 결국, 코딩 에이전트는 게임이 시작되기 전에 게임의 규칙을 이해해야합니다.
- 작업: 코딩 에이전트는 사양과 계획을 가져 와서 실제 작업으로 분류합니다. 그것은 각각의 퍼즐 조각을 해결하는 작고 검토 가능한 덩어리를 생성합니다. 각 작업은 구현하고 분리하여 테스트 할 수있는 것이어야합니다. 코딩 에이전트가 AI 에이전트의 테스트 중심 개발 프로세스와 마찬가지로 코딩 에이전트가 작업을 검증하고 추적하는 방법을 제공하기 때문에 중요합니다. “인증 빌드”대신 “이메일 형식을 검증하는 사용자 등록 엔드 포인트 작성”과 같은 구체적인 작업이 나타납니다.
- 구현하다: 코딩 에이전트는 작업을 하나씩 (또는 해당되는 경우) 하나씩 해결합니다. 그러나 여기에 다른 점이 있습니다. 천선 덤프를 검토하는 대신 개발자, 특정 문제를 해결하는 중심 변경 사항을 검토하십시오. 코딩 에이전트는 사양에 따라 구축해야 할 사항을 알고 있습니다. 계획이 말했기 때문에 그것을 구축하는 방법을 알고 있습니다. 그리고 과제가 말했기 때문에 어떻게 해야할지 정확히 알고 있습니다.
결정적으로, 당신의 역할은 단순히 조종하는 것이 아닙니다. 확인해야합니다. 각 단계에서, 당신은 반영하고 세련됩니다. 사양이 실제로 빌드하려는 것을 캡처합니까? 이 계획은 실제 제약 조건을 설명합니까? AI가 놓친 생략 또는 에지 케이스가 있습니까? 이 프로세스는 앞으로 나아 가기 전에 생성 된 내용, 스팟 간격 및 과정을 비판하기 위해 명시적인 체크 포인트로 구축됩니다. AI는 아티팩트를 생성합니다. 당신은 그들이 옳은지 확인합니다.
에이전트 워크 플로에서 사양 키트를 사용하는 방법
Spec Kit는 Github Copilot, Claude Code 및 Gemini CLI와 같은 코딩 에이전트와 함께 작동합니다. 핵심은 일련의 간단한 명령을 사용하여 코딩 에이전트를 조종 한 다음 인공물을 생성하는 데 어려움을 겪는 것입니다.
설정하는 것은 간단합니다. 먼저 설치하십시오 specify 명령 줄 도구. 이 도구는 프로젝트를 초기화하고 필요한 구조를 설정합니다.
uvx --from git+ specify init 프로젝트가 초기화되면 /specify 명령 고급 프롬프트를 제공하기위한 명령과 코딩 에이전트는 전체 사양을 생성합니다. 기술적 인 세부 사항이 아니라 프로젝트의 “무엇”및 “왜”에 집중하십시오.
다음으로 사용하십시오 /plan 기술 구현 계획을 작성하기 위해 코딩 에이전트를 조정하도록 명령하십시오. 여기서는 높은 수준의 기술 방향을 제공하며 코딩 에이전트는 아키텍처 및 제약을 존중하는 상세한 계획을 생성합니다.
마지막으로 사용하십시오 /tasks 명령 코딩 에이전트가 사양을 세분화하고 실행 가능한 작업 목록으로 계획하도록합니다. 코딩 에이전트는이 목록을 사용하여 프로젝트 요구 사항을 구현합니다.
이 구조화 된 워크 플로우는 모호한 프롬프트를 코딩 에이전트가 안정적으로 실행할 수 있다는 명확한 의도로 바꿉니다.
그러나 모호한 프롬프트가 실패하는 곳 에서이 접근법이 성공한 이유는 무엇입니까?
이것이 작동하는 이유
이 접근법은 언어 모델의 작동 방식에 대한 기본적인 진실로 인해“AI에 대한 프롬프트”가 실패하는 경우에 성공합니다. 패턴 완료에서는 예외적이지만 마음을 읽지 않습니다. “내 앱에 사진 공유 추가”와 같은 모호한 프롬프트는 모델이 잠재적으로 수천 개의 언급되지 않은 요구 사항을 추측하도록 강요합니다. AI는 합리적인 가정을 할 것이며 일부는 틀릴 것입니다 (그리고 구현에 깊이 빠질 때까지 옳지 않은 것을 발견하지 못할 것입니다).
대조적으로, 기술 계획 및 집중 작업과 함께 명확한 사양을 제공하면 코딩 에이전트가 전반적인 효능을 향상시켜 코딩 에이전트에게 더 선명하게 제공됩니다. 귀하의 요구를 추측하는 대신, 무엇을 구축 해야하는지, 구축 방법 및 어떤 시퀀스에서든 알고 있습니다.
이것이 바로 접근 방식이 다른 기술 스택에서 작동하는 이유입니다. 파이썬, JavaScript 또는 Go에 건설하든 근본적인 과제는 동일합니다. 의도를 작업 코드로 변환합니다. 사양은 의도를 명확하게 포착하고, 계획은이를 기술적 결정으로 변환하고, 작업이이를 구현 가능한 부분으로 나누고, AI 코딩 에이전트가 실제 코딩을 처리합니다.
대규모 조직의 경우 이것은 또 다른 중요한 문제를 해결합니다. 보안 정책, 규정 준수 규칙, 설계 시스템 제약 및 통합 요구 사항에 대한 모든 요구 사항을 어디에 두십니까? 종종, 이런 것들은 누군가의 머리 속에 살고, 아무도 읽지 않는 위키에 묻혀 있거나 나중에 찾을 수없는 여유 대화에 흩어져 있습니다.
사양 키트를 사용하면 AI가 실제로 사용할 수있는 사양과 계획에 적용됩니다. 귀하의 보안 요구 사항은 이후에 아닙니다. 그들은 첫날부터 사양에 구워졌습니다. 그리고 당신의 디자인 시스템은 나중에 볼트가 아닙니다. 구현을 안내하는 기술 계획의 일부입니다.
이 접근법의 반복적 특성은 그것을 힘을주는 것입니다. 전통적인 개발이 초기 결정에 빠지면 사양 구동은 코스를 간단하게 만듭니다. 사양을 업데이트하고 계획을 재생하며 코딩 에이전트가 나머지를 처리하도록합니다.
3이 접근법은 실제로 잘 작동합니다
사양 구동 개발은 세 가지 시나리오에서 특히 유용합니다.
- 그린 필드 (제로 대 1): 새 프로젝트를 시작할 때 코딩을 시작하려는 유혹이 있습니다. 그러나 사양과 계획을 만들기위한 소량의 선불 작업은 AI가 일반적인 패턴을 기반으로하는 일반적인 솔루션뿐만 아니라 실제로 의도 한 것을 구축 할 수 있도록합니다.
- 기존 시스템의 기능 작업 (N-to-N+1): 사양 구동 개발이 가장 강력한 곳입니다. 복잡한 기존 코드베이스에 기능을 추가하는 것은 어렵습니다. 새로운 기능에 대한 사양을 만들면 기존 시스템과 상호 작용하는 방법에 대한 명확성을 강요합니다. 그런 다음이 계획은 아키텍처 제약을 인코딩하여 새로운 코드가 볼트가 추가 대신 프로젝트에 기본적으로 느껴지도록합니다. 이로 인해 지속적인 발전이 더 빠르고 안전합니다. 이 작업을 수행하기 위해 고급 컨텍스트 엔지니어링 관행이 필요할 수 있습니다.이를 별도로 다룰 것입니다.
- 레거시 현대화: 레거시 시스템을 재건해야 할 때 원래 의도는 종종 시간에 손실됩니다. 사양 키트에 제공되는 사양 개발 프로세스를 사용하면 현대적인 사양에서 필수 비즈니스 논리를 캡처하고 계획에서 새로운 아키텍처를 설계 한 다음 AI가 상속 된 기술 부채를 전달하지 않고 처음부터 시스템을 재건 할 수 있습니다.
핵심 이점은 안정적인 “What”을 유연한 “방법”과 분리하여 값 비싼 재 작성없이 반복 개발을 가능하게하는 것입니다. 이를 통해 여러 버전을 구축하고 빠르게 실험 할 수 있습니다.
우리가 향한 곳
우리는“코드는 진실의 원천”에서“의도는 진실의 원천”으로 이동합니다. AI를 사용하면 사양이 진실의 원천이되어 구축 된 내용을 결정합니다.
문서가 더 중요해 졌기 때문이 아닙니다. AI가 사양 실행 파일을 만들기 때문입니다. 사양이 자동으로 작동하는 코드로 바뀌면 구축 된 내용이 결정됩니다.
사양 키트는 그 전환을 현실화하는 실험입니다. 이 접근 방식은 하나의 도구 나 회사보다 크기 때문에 공개했습니다. 진정한 혁신은 프로세스입니다. 여기에는 곧 제시 할 수있는 더 많은 것이 있습니다. 특히 사양 구동 개발 관행과 컨텍스트 엔지니어링을 결합하여 AI 툴킷에서보다 고급 기능을 구축 할 수있는 방법이 있습니다.
그리고 우리는 그것이 당신을 위해 어떻게 작동하는지와 우리가 개선 할 수있는 것을 듣고 싶습니다! 사양 중심 패턴으로 구축하는 경우 경험을 공유하십시오. 우리는 특히 궁금합니다.
- 워크 플로우를 더 매력적이고 사용할 수있게합니다: 텍스트의 읽기 벽은 지루할 수 있습니다. 우리는이 과정을 진정으로 즐겁게 만드는 방법은 무엇입니까?
- 가능한 대 코드 통합: 우리는이 워크 플로우를 VS 코드로 직접 가져 오는 방법을 모색하고 있습니다. 당신에게 가장 자연스러운 느낌은 무엇입니까?
- 여러 구현을 비교하고 차단합니다: 구현 간 반복 및 차이는 창의적 가능성을 열어줍니다. 여기에서 가장 가치있는 것은 무엇입니까?
- 조직에서 사양 및 작업 관리: 많은 마크 다운 파일을 관리하는 것이 압도적 일 수 있습니다. 정리하고 집중하는 데 도움이되는 것은 무엇입니까?
우리는 당신이 AI를 활용하여 인간의 창의성을 작업 소프트웨어로 번역하는 더 좋은 방법을 찾게되어 기쁩니다.
SPEC 키트>로 시작하십시오
작성자가 작성했습니다
Post Comment