Overview
글을 올리지 않는 동안 회사에 꽤 많은 변화가 있었다. 팀 구조가 바뀌었고, 그 변화의 시기에 새로운 개발 프로세스로 SDD(Spec Driven Development)가 도입되었다.
이 글에서는 그 도입 과정에서 내가 어떤 입장이었고, 어떻게 다뤄야 한다고 봤으며, 어떤 부분이 아쉬웠는지를 정리해본다. 결론부터 말하면 아직 정답은 모르겠고, 내가 원하는 SDD의 방향성은 조금 더 선명해졌다.
팀 개편과 SDD 도입
4월쯤이었나. 기존 팀 구조에 개편이 있었다. 각 부서의 일을 좀 더 빠르게 처리하자는 취지로 조직이 스쿼드 단위로 잘게 나뉘었고, 나는 그중 CX팀으로 옮겨가게 됐다.
조직이 바뀌는 시기에 개발 프로세스에도 변화가 생겼다. 이전 글에서 언급했던 Claude Code Max 도입과 함께, SDD를 도입하자는 이야기가 나온 것이다. 도입을 위해 개발팀 안에서도 여러 이야기가 오갔고, 사내 스터디를 하며 각자의 생각과 아이디어를 공유하고 발표하는 시간을 가졌다.
이전 글에서도 적었듯 나는 SDD를 어느 정도 인지하고 있었다. 다만 전면 도입에 완전히 찬성하기보다는, 부분적으로 도입해보고 싶은 입장이었다. 사내 개편이 대대적으로 이루어지는 와중에 개발 방법론까지 새로 들이는 게 조금 위험해 보였기 때문이다. 그래서 나는 spec-kit처럼 이미 시장에 나와 있는 도구로 가볍게 시작해보고자 했다.
다만 그 '가볍게'의 의미를 두고 팀과 결이 조금 달랐다. 나는 사내 도구를 따로 만들지 않고 기존 프레임워크로 시작하자는 쪽이었고, 반대 의견은 외부 프레임워크 자체가 무거우니 사내 워크플로우 툴을 빠르게 만들자는 쪽이었다. 자체 툴은 만드는 순간부터 책임질 게 많아진다고 봤지만, 직접 해보지 않은 상태에서 너무 단정하고 싶지 않아 끝까지 밀어붙이진 않았다. 그렇게 결국은 사내 개발툴을 만드는 쪽으로 흐름이 넘어갔다.
망설이다 놓쳐버린
지금 돌아보면 이 지점이 가장 아쉽다. 당시에도 뻔히 보이는 문제라고 느낀 것들이 있었다.
- 도구를 직접 만드는 부담
- 2주라는 짧은 준비 기간
- 팀 개편과 SDD 도입이 동시에 진행되는 타이밍
- 티켓마다 필요한 스펙의 깊이가 다르다는 점
문제는, 그걸 충분히 구체적인 언어로 말했는지 잘 모르겠다는 거다. 마음속으로 "이건 좀 위험한데"라고 생각하는 것과, 팀이 판단할 수 있는 형태로 정리해서 공유하는 건 완전히 다른 일이었다. 의견을 낼 수 있는 환경임에도 말하지 못했다. 단순히 반대하는 게 아니라, 무엇이 위험하고 어떤 식으로 작게 검증하면 좋을지 더 명확하게 제안했어야 했다. 이 부분은 꽤 반성하게 된다. 신입이슈
내가 챙기고 싶었던 것들
마침 팀 개편 기간에 스프린트에 2주 정도 공백이 생겼고, 그때 개발툴을 만들기 시작했다.
도입 찬반을 이야기할 때 확고하게 주장하지 못했던 것과 달리, 정작 개발 기간에는 의견을 많이 냈던 걸로 기억한다. 스터디에서 얻은 지식을 바탕으로 내가 생각하던 SDD와 에이전틱 코딩의 방향성을 떠올리며 여러 의견을 냈고, 그중 꽤 많은 것들이 채택되어 프로세스에 반영됐다. 개발이 끝난 뒤 유지보수 단계에서도 여러 안건을 냈고, 그중 일부는 지금까지도 쓰이고 있다.
이때 첫 번째로 신경 쓴 것은 자산화였다. 사용한 스펙이 그냥 버려지지 않고 아카이브 형태로 남게 하는 것이다. 스펙은 만들어두고 나면 그저 한 번 쓰고 마는 산출물처럼 느껴질 때가 있다. 당장의 생산성만 보면 그렇게 접근할 수도 있다. 하지만 잘 남겨두면 나중에 왜 그런 결정을 했는지 되짚을 수 있는 기록이 된다고 봤다.
두 번째는 Out of scope였다. 에이전트는 경계가 흐리면 그럴듯한 방향으로 계속 일을 벌이기 쉽다. 사람도 크게 다르지 않다. 티켓의 범위가 흐려지면 작은 작업도 금방 커진다. 그래서 스펙은 개발 전에 한 번 통과하고 끝나는 문서에만 머물면 안 된다고 생각했다. 누가 봐도 지금의 범위와 제약을 이해할 수 있고, 나중에 다시 되짚을 수 있는 협업의 인터페이스에 더 가까워야 한다고 느꼈다.
이 두 가지를 관통하는 건 결국 스펙을 한 번 쓰고 마는 문서로 두지 않으려는 마음이었다. 그래서 나는 스펙을 작성하는 것 자체보다, 그 초안을 어떤 리듬으로 검토하고 어디까지 수정 가능한 상태로 둘지를 더 중요하게 봤다.
그렇게 개발툴은 완성됐고, 지금까지도 스프린트에서 계속 쓰이고 있다. 최근에는 작은 범위의 티켓을 위한 퀵모드를 추가한다거나, 아카이브에 저장되는 자산들을 좀 더 잘 활용할 방안, 그리고 불어나는 스펙을 경량화하면서도 성능은 더 잘 나오게 하는 법을 나름대로 연구 중이다. 퀵모드는 도입 전에 걱정했던 '티켓마다 필요한 스펙의 깊이가 다르다'는 문제가 실제로 나타나면서 생긴 대응이기도 하다.
다시, 처음의 망설임으로
돌이켜보면 도입 이야기가 처음 나왔을 때 나는 가볍게 가고 싶었고, 그래서 자체 툴을 만드는 일이 망설여졌다. 만드는 순간부터 책임질 게 많아지니 더 무거워질 거라고 봤다.
그때 나는 무거움을 도구의 문제로 본 셈이다. 그런데 직접 만들고 굴려보니, 무게를 결정하는 건 도구를 직접 만드느냐 아니냐보다 스펙을 어떻게 다루느냐에 더 가까웠다. 개발 전에 한 번 확정하고 끝내버리면 어떤 도구를 쓰든 코드와 어긋난 문서가 부담으로 남는다. 반대로 작은 초안에서 시작해 계속 고쳐가고, 팀이 같은 방향을 보게 하는 스펙이라면 그 무게를 걱정할 일도 줄었다.
물론 처음에 걱정했던 비용이 사라진 건 아니다. 퀵모드를 붙이고 아카이브를 정리하고 스펙을 경량화하는 일 전부, 자체 툴을 만든 순간부터 따라온 책임이고 지금도 지불하고 있는 비용이다. 비용이 줄었다기보다, 스펙이 코드와 같이 계속 고쳐지는 동안에는 이 비용이 죽은 문서를 떠받치는 일이 아니라 팀이 매 스프린트 쓰는 자산을 손보는 일이라 견딜 만했다는 쪽에 가깝다. 다만 spec-kit으로 시작한 세계는 살아보지 않았으니, 이건 한쪽 길만 걸어본 사람의 결론이라는 한계는 있다.
스펙은 정답지가 아니라 지금 우리가 이해한 지점의 스냅샷이라 생각한다. 그렇게 다룰 수만 있다면, 처음에 내가 무겁다고 느꼈던 건 도구가 아니라 스펙을 대하는 태도였는지도 모른다.
SDD가 우리 팀에 어떻게 자리 잡을지는 여전히 잘 모르겠다. 몇 번의 스프린트만으로 판단하기엔 이르다. 다만 다음 스펙을 시작할 때, 그때의 망설임을 조금은 다르게 마주할 수 있을 것 같다.