제가 클로드 코드를 직접 도입한건 한달 조금 넘었습니다 5~6주 되었네요.

그 이전에는 gemini-cli 를 사용했었고요. 그 이전에는 chatgpt 를 사용했습니다. 그 이전에는 github copilot 만 사용했었습니다.

github copilot 이 처음 도입 되었을 당시, 음.. 약 5년 정도 되었죠. 그때만 해도 혁신적이었어요.

자바 dto 객체 만드는게 이렇게 쉽게 된다고.. ??? ㅎㅎ

다들 아시다시피 chatgpt 가 도입 되면서 한번 퀀텀 점프를 했죠. 이 시점에 생산성이 엄청나게 좋아졌고

개발자 앞으로 할거 없음 이론이 개발자 사이에서 퍼지면서 좀 암울하기도 했던...

gemini-cli 로 넘어오고나서 반스텝 더 도약했죠. 프로젝트 전체 컨텍스트를 안다는게 이렇게 편한거구나..

그리고 직접 코드 수정도 하고 커밋 푸시 배포 안 되는게 없었죠.

근데 이 때 까지는 아직도 제가 직접 손으로 코딩하는 부분이 30%는 남아 있었어요.

claude-code 에서는 훨씬 더 커진 컨텍스트로 개발이 편리해졌는데 그러다보니 더 큰 프로젝트를 다루게되고 

여전히 컨텍스트는 모자라게 되더군요. 

제가 얘기하는 컨텍스트는 이런겁니다. A, B, C 를 개발하고 D 를 개발하기 시작하면 아무 관계 없는 A, B 를 건드려서

전체가 이상해지는 그런 그림..

이후 개선하기 위해 많은 고민을 했는데요 그 와중 알게된게 그 옛날 학부시절에 배운 TDD 도입이었습니다.

TDD 도입만으로도 상당히 효과적이었어요. 하지만 이것도 프로젝트가 커지다보니 

테스트가 감당할 수 없게 커지게 되면서 이전과 똑같은 문제가 생기더라구요. 

코드가 9000 라인 정도였는데 테스트가 45000 라인이었습니다 --;;;;;;;

그때 심각함을 깨닫고 새로운 방법을 찾다가 SDD 방법론을 알게 되었어요.

이 역시 개발 오래 하신 분이면 누구나 들어본 얘기죠. spec-driven-development .

명세를 완성하고 명세에 기반한 개발을 진행하는 방법론인데, 이게 현실 환경에서는 참 어려운거란 말이죠.

그런데 이제는 사람보다 훨씬 생산성이 좋은 AI 가 개발을 맡으면서 SDD 이론이 현실적이 되었어요.

https://github.com/github/spec-kit/blob/main/spec-driven.md​

이 문서에서 큰 영향을 받고 제 프로젝트를 완전히 수정했습니다.

rm -rf tests/ 명령어를 시작으로 몇만라인짜리 테스트 수백개는 그냥 완전히 지워버리고

클로드를 통한 역공학 (reverse-engineering) 으로 스펙을 만들었습니다.

프로젝트 전체를 관통하는 헌법 6조를 만들고, 프로젝트의 큰 줄기인 여섯개의 챕터를 만들었습니다.

그 모든 챕터에 spec -> reserch -> contracts -> data-model -> plan 의 핵심 문서를 만들었습니다.

물론 한번에 된건 절대 아니고요... ㅠㅠ 

파인 튜닝 하는데 걸린 시간이 3주 정도 됩니다.... 현재도 완벽하진 않지만 95% 이상 제 의도가 반영 됐어요.

지금은 SDD 에 기반한 다섯가지의 큰 워크플로우 문서를 기반으로 작업합니다.

각 문서는 대략 다음과 같습니다.

1. 신기능 개발 워크플로우

2. 버그 수정 워크플로우

3. 기술 문서 요약 워크플로우

4. 번역 워크플로우 (이건 회사에 다국적 직원이 많아서, 본 프로젝트의 정체성과는 조금 다름)

5. 개발 상황 정리 워크플로우 (git 이력 추적으로 변경 내용 감지 > 문서화 > 커밋 정도의 흐름입니다)

이 SDD 방법론이 정착된 이후로 개발 속도가 훨씬 빨라졌고요, 불필요하게 토큰을 까먹던 행위-

하나를 고치면 다른 둘이 망가지는 --ㅋㅋ 현상이 현저히 줄어들었습니다.

현재 코드베이스는

파이썬 25000 라인

마크다운 80000 라인 (80% 명세, 20% 작업이력)

쉘스크립트 1500 라인 

그외 기타 1000 라인 정도가 되었습니다.

처음에는 위에 소개한 github spec-kit 으로 시작했지만, 현재는 그 기반을 버리고 

완전히 자체적인 SDD 방법론을 만들었습니다.

SDD 방법론에서 가장 중요한 부분은

언제 어떤 상황에서라도 명세가 코드보다 우선한다. 입니다.

시급을 다투는 버그가 있어 수정해야 하더라도 구현을 살피지 않고 명세를 검토합니다.

현재 구현이 파이썬이지만 ts, go, java 등으로 언제든지 바꿀 수 있다고 장담합니다. (rust 는 조금 별도로)

그로 인해 열흘정도 전 부터는 저의 손코딩은 완전히 0%에 도달했습니다.

클로드코드를 사용하는 분들께 도움이 되길 바라며 남깁니다.

조금 더 딥한 내용은 다시한번 아래 링크를 추천합니다. 한번쯤 정독해보시면 삶이 편해질 수 있습니다.

​https://github.com/github/spec-kit/blob/main/spec-driven.md​