요즘 들어 개발하면서
“코드를 잘 짜는 것”보다
“무엇을 왜 짜고 있는지 잃지 않는 것”이 더 중요하다는 생각을 자주 하게 된다.
특히 AI를 적극적으로 활용하면서
이 감각은 더 강해졌다.
코드는 점점 더 빨리 만들어지는데,
그만큼 사고의 맥락은 더 쉽게 사라진다는 느낌을 받았기 때문이다.
그러다 자연스럽게 SDD라는 개념을 접하게 됐다.
SDD(Spec-driven Development)는
아직 완전히 정립된 정의가 있는 개념은 아니다.
다만 공통적으로 이야기되는 핵심은 비교적 명확하다.
코드를 작성하기 전에, 먼저 Spec을 작성한다
Spec-driven Development,
혹은 Documentation First 방식이라고 불러도 크게 어색하지 않다.
최근에는 kiro, spec-kit 같은 도구들이 등장하면서
SDD가 조금 더 구체적인 형태로 논의되고 있다.
이 도구들이 제시하는 기본 흐름은 다음과 같다.
요구사항(Requirements)을 정리하고,
그 위에 설계(Design)를 얹고,
그 다음에 실제 작업(Task, Implementation)을 진행한다.
굉장히 당연해 보이는 이야기지만,
막상 현실에서는 자주 생략되는 단계이기도 하다.
spec-kit을 보면서 가장 인상 깊었던 개념은
Memory Bank였다.
Memory Bank는
작업 흐름 중간중간 참고하는 선택 사항이 아니라,
프로젝트 전반에 걸쳐 무조건 지켜져야 하는 규칙 묶음에 가깝다.
예를 들면 이런 것들이다.
spec-kit에서는
이 Memory Bank를
SDD 접근 방식의 전제 조건처럼 다룬다.
작업 흐름 전체를 관통하는
일종의 헌법 같은 파일인 셈이다.
이 지점이 꽤 마음에 들었다.
다만 kiro나 spec-kit을 그대로 도입할지는
조금 고민이 됐다.
툴이 제공하는 구조 자체는 매력적이었지만,
한편으로는 이런 생각도 들었다.
그래서 결론적으로는
도구는 가져오지 않고, 개념만 가져오자는 쪽으로 정리했다.
지금 내가 시도하고 있는 방식은
꽤 단순하다.
먼저, 프로젝트 전반에 걸쳐
절대적으로 지켜야 할 규칙들을
Memory Bank 형태의 md 파일로 고정해둔다.
여기에는 코딩 컨벤션,
설계 방향,
AI가 따라야 할 기본 원칙들이 들어간다.
그리고 각 기능이나 모듈을 구현할 때마다
“왜 이렇게 구현했는지”를
별도의 md 파일로 남긴다.
중요한 점은
형식을 강제하지 않는 대신, 질문을 고정한다는 것이다.
예를 들면,
이 정도만 남겨도,
나중에 코드를 다시 볼 때
맥락을 복원하는 데 큰 도움이 된다.
SDD 이야기를 하다 보면
AI가 모든 걸 알아서 해주는 미래를 떠올리기 쉽다.
하지만 적어도 지금 시점에서는
완전한 AI 자율주행 개발은 지양하는 게 맞다고 생각한다.
spec-kit을 사용하더라도,
결국 중간중간 검증하는 과정은 필요하고,
단계마다 되돌아보며 수정해야 한다.
SDD는 자동화를 위한 방법론이라기보다는,
사고를 멈추지 않게 만드는 장치에 가깝다고 느낀다.
최근 바이브 코딩을 접하고,
AI를 적극적으로 활용하면서
한 가지 확실해진 게 있다.
구현은 AI에게 맡길 수 있다면,
나는 다른 곳에 더 집중하는 게 맞다
그 다른 곳이란 결국,
이런 영역들이다.
그래서 더더욱
Spec을 먼저 쓰고,
생각을 문서로 남기는 방식이
나에게는 잘 맞는다고 느끼고 있다.
지금 내가 하고 있는 SDD는
교과서적인 방법론도 아니고,
특정 도구에 종속된 방식도 아니다.
다만 분명한 목적은 있다.
SDD는 그걸 도와주는 하나의 프레임이고,
Memory Bank와 md 로그는
그 프레임을 유지하기 위한 최소한의 장치다.
아마 이 방식도
프로젝트를 거듭하면서 계속 바뀔 것이다.
하지만 적어도 지금 시점에서는,
내가 개발하면서 느끼는 고민들에
가장 솔직하게 답하고 있는 방식이라고 생각한다.
다음 글에서는
이 SDD 방식을 실제 프로젝트에서 어떻게 쓰고 있는지,
그리고 AI와의 협업이 어떤 식으로 달라졌는지를
조금 더 구체적으로 정리해볼 생각이다.
천천히, 계속 다듬어보려고 한다.
이런 배경이..!