실밸개발자가 제안하는 SDD, 인공지능이 코딩하고 검증까지 맡는 새 개발 패러다임을 제시한다.
TDD(Test-Driven Development)는 버그 수정이나 작은 함수처럼 동작 방식이 명확한 작업에 적합하다.
그러나 새로운 프로젝트나 모호한 도메인에서는 무엇을 만들지조차 불분명해 테스트부터 작성하기 어렵다는 약점이 있다.
Spec-Driven Development(SDD)는 이러한 상황에서 자연어 스펙을 먼저 작성하고, 그 스펙을 기반으로 AI가 코드 생성과 검증을 유도하는 방식을 도입한다.
과거에는 코딩과 테스트가 개발의 주요 병목이었으나, AI 기술의 발전으로 이러한 제약이 해소되었다.
AI는 인간 개발자 100명이 쓰는 코드보다 훨씬 많은 양의 코드를 빠르게 작성할 수 있는 능력을 갖추게 되었다.
이에 따라 한정된 개발자의 시간을 효율적으로 사용하기 위해 코드 작성보다는 스펙 설계에 집중적으로 투입해야 한다.
입력과 출력 데이터, 성공 지표, 응답 속도 등의 제약 사항과 범위, 예외 상황인 엣지 케이스까지 다섯 가지 요소가 좋은 스펙의 근간이다. 첫째, 입력과 출력은 무엇이 시스템에 들어가고 무엇이 나오는지 명확히 정의한다.
둘째, 성공 기준은 왜 이 기능을 만드는지, 그리고 성공 여부를 어떻게 측정할 수 있는지에 대한 지표를 포함한다.
셋째, 제약 사항은 응답 시간 같은 시스템이 지켜야 할 경계를 설정하고, 넷째, 범위 설정은 무엇을 만들고 무엇을 만들지 않을 것인지 분명히 한다. 마지막으로 엣지 케이스는 예외 상황을 어떻게 처리할지 명시한다.
프로젝트가 복잡해지면 스펙을 하나의 문서에 모두 담지 않고 계층형으로 작성해야 한다고 권장한다.
하나의 큰 스펙에 모든 내용을 담으면 AI 컨텍스트 압축 과정에서 중요한 정보가 손실될 가능성이 있기 때문이다.
따라서 마스터 스펙 아래에 MVP(Minimum Viable Product)나 특정 기능별 컴포넌트 스펙을 계층형으로 관리하고, 각 컴포넌트 스펙은 단일 AI 세션 컨텍스트 안에 들어갈 수 있는 크기로 분할하는 것이 효과적이다.
또한, 향후 기능이 추가될 경우 기존 스펙에 이어 붙이는 방식을 통해 효율적인 스펙 관리를 이어나간다.
계층형으로 저희가 스펙을 작성을 하면 됩니다. 프로젝트가 커지면 스펙을 어떻게 작성해야 되냐라고 하는데 하나에 다 넣지 말라고 저희 회사에서는 그렇게 추천을 하고 있거든요.
Architecture Decision Record(ADR)는 개발 결정의 근거와 포기한 대안을 기록하여 AI 에이전트의 운영 효율을 높인다.
개발자가 어떤 결정을 내릴 때 반드시 그 이유가 존재하지만, 이 이유가 코드 내 주석만으로는 에이전트가 문맥을 완전히 파악하기 어려울 수 있다.
따라서 ADR을 통해 에이전트가 결정의 배경을 이해하고 작업을 수행하게 함으로써, 임의로 구조를 변경하는 것을 방지하고 기대하는 효과를 얻을 수 있다.
유튜브 썸네일 생성 서비스를 예시로, 고퀄리티 유입 유도를 목표로 설정한 뒤 이미지와 프롬프트의 입출력 구조를 자연어 프롬프트로 설계한다.
유튜브 썸네일 생성 서비스를 예시로 들면서, 서비스의 목적을 AI를 활용해 고품질 썸네일을 더 쉽고 빠르게 만들어 유튜브 영상의 유입을 늘리는 것으로 설정했다.
이 과정에서 입력은 선택적인 이미지와 필수적인 프롬프트로, 출력은 최종 썸네일 이미지로 정의하고, AI와의 티키타카를 통해 구체적인 스펙을 점차적으로 발전시켜 나간다.
무료인 제미나이 API 대신 GPT-2 이미지 API를 도입한 것은 실무 개발 과정에서 결과물의 품질을 최우선으로 고려한 선택이다.
이 API는 호출할 때마다 요금이 부과되지만, 더 높은 퀄리티의 결과물을 얻기 위해 유료 모델을 선택하는 것이 합리적이라고 판단했다.
만약 비용 부담이 있다면 제미나이 API와 같은 무료 대안을 활용할 수 있다.
SDD의 자동화 프로세스는 AI가 탐색, 의도 파악, 논의, 실행 단계로 구성된 워크플로우를 따른다.
AI 에이전트는 하위 문서들을 읽고 의도를 파악하며, 구체화나 기술적 결정이 필요하면 개발자에게 다시 논의를 요청한다.
각 스텝별 파일은 모두 독립된 세션에서 실행되며, 필요한 정보는 각 스텝의 산출물로 요약되어 다음 스텝의 컨텍스트로 전달되는 '바톤 터치' 방식으로 진행된다.
이전 세션의 상태를 잃지 않기 위해 명시적인 문서화와 상태 기록이 필수적이다.
하네스 설계는 복잡성을 덜어낼수록 가치가 커진다는 철학을 바탕으로 한다.
이는 오버엔지니어링을 지양하고 최소한의 변화로 최대의 아웃풋을 내는 것이 핵심이다.
사용자가 목적을 정확하고 가볍게 달성할 수 있도록 돕는 것이 진정한 하네스의 본질이다.
Claude -P는 AI의 개입 없이 자동화된 환경에서 작업을 수행하는 논-인터랙티브 모드이다.
이 모드는 AI에게 명령을 쪽지처럼 전달하고 결과만을 기다리는 방식으로, 채팅이나 중간 퍼미션 확인 없이 시스템이 알아서 작업을 처리한다.
따라서 매일 밤 코드 검사나 자동 로봇 작업처럼 사람의 개입 없이 루틴하게 돌려야 하는 업무에 특히 적합하다.
클로드(Claude)의 -P 기능이 최근 구독 플랜에서 자유롭게 사용 가능했던 방식에서 과금제로 변경되었다.
클로드-P 사용 시 발생하는 API 비용은 운용 과정에서 사용자가 상시 염두에 두어야 할 변수다.
이에 대한 대안으로 코덱스(CodeX)를 활용하는 방법을 권장한다.
따라서 복사 붙여넣기 방식으로 키를 입력하는 습관을 중단하고, 자동화된 작업 시에도 API 키는 직접 입력하지 않고 안전하게 관리해야 한다.
컴퓨터의 절전 모드와 관계없이 AI 작업을 유지하기 위해 '카피네이트(caffeinate)' 커맨드를 터미널에서 활용할 수 있다.
이 커맨드를 사용하면 컴퓨터가 화면이 꺼져도 각성 상태를 계속 유지하여 내부 프로세스가 지속적으로 돌아가게 된다.
이를 통해 사용자는 원격으로 클로드(Claude) 코드 작업을 계속 진행할 수 있다.
AI 세션 종료 후 작성되는 리플렉티브 리포트는 단순한 기록을 넘어 시스템 개선의 토대가 되어야 한다.
해당 리포트를 시스템 가이드라인 보완에 활용함으로써 전체 인프라를 고도화하는 과정을 거친다.
이러한 지속적인 시스템 개선을 통해 차기 세션의 오류 발생률을 최소화할 수 있다.
AI가 개발한 서비스는 최종 검증 단계에서 전체 빌드(npm run build)를 수행하여 정상 작동 여부를 확인한다.
만약 이 단계에서 실패할 경우, AI가 스스로 재수정 작업을 수행한다.
모든 과정이 완료되면 로컬 서버(npm run dev)를 띄워 서비스 구동을 최종적으로 확인한다.
복잡하고 모호한 프로젝트를 스펙 계층화 방식으로 잘게 나누어 해결하는 SDD는 단시간 내 고도화된 프로토타입을 완성하는 데 강점을 보인다.
개발자의 역할은 더 이상 코드를 직접 구현하는 것이 아니라, AI가 효율적으로 작업할 수 있도록 스펙을 정교하게 다듬는 데 집중한다.
이러한 방식을 통해 약 30분 이내에 복잡한 애플리케이션의 프로토타입을 생성하는 등 개발 시간을 획기적으로 단축할 수 있다.
스펙을 잘 만들어 놓으니까 클로드가 이렇게 멋진 앱을 정말 뭐 한 30분 만에 만들어 냈거든요.
Answers come from the transcript, with the exact spot cited.
Want the next article from 실밸개발자?
When 실밸개발자 publishes, we'll write it up like the one you just read and email it to you.
실밸개발자 published 8 in the last 7 days.
