본문 바로가기

왜 명세서를 걷어내는가

이번 장은 3부로 별도 할당했습니다. 앞선 책 바이브 코딩 에센셜 with claude code의 3부는 '요구사항 명세서'였습니다. 전통적인 명세서부터 바이브 코딩용 템플릿까지 과할 정도로 많은 문서를 살펴보는 장이었죠. 이 책의 3부는 그 자리를 다른 것으로 채웁니다. 빠르게 만들고, 실행해 보고, 검토하는 루프입니다. 왜 바꿨는지부터 이야기하겠습니다.

1. 앞선 책이 명세서를 강조한 이유

앞선 책은 이렇게 썼습니다. 모델이 지금 성능의 2~3배가 되어 원하는 결과물을 5분, 10분 만에 만들 수 있는 시대가 오면, 코드의 자산 가치는 떨어지고 무엇을 만들지 정의하는 문서의 가치가 올라갈 것이라고요. 그래서 명세서를 가장 중요한 장으로 두었습니다.

그 예측의 절반은 맞았습니다. 코드의 가치는 정말 떨어졌습니다. 이제 랜딩 페이지 하나를 다시 만드는 데 몇 분이면 됩니다. 그런데 나머지 절반은 예상과 다르게 흘렀습니다. 문서의 가치가 올라간 것이 아니라, 문서를 쓰는 시간에 결과물을 하나 더 만들어 보는 편이 빨라졌습니다.

2. 명세서가 발목을 잡는 순간

부트캠프를 여러 기수 진행하면서 명세서 템플릿을 나눠드렸습니다. 그런데 개발을 모르는 분들에게서 반복되는 장면이 있었습니다.

2.1 어설프게 아는 것을 적는다

템플릿에는 '시스템 아키텍처', '기술 스택', '데이터베이스'라는 칸이 있었습니다. 개발을 모르는 분이 이 칸을 채우려면 검색을 해야 합니다. 검색해서 나온 단어를 적습니다. React, Firebase, MongoDB 같은 단어가 들어갑니다. 그 단어가 자기 프로젝트에 맞는지는 모릅니다. 그런데 명세서에 적혀 있으니 Claude는 그대로 따릅니다. 2장에서 이야기한 부트캠프 2기의 일, 게시판은 Flask로 로그인은 FastAPI로 만들어진 사례가 명세서 없이 생긴 일이었다면, 명세서 때문에 생긴 사례도 있었습니다. 간단한 소개 페이지에 React가 들어가 파일이 수십 개가 되고, 그 뒤로 아무것도 손대지 못하게 된 분이 있었습니다.

어설프게 아는 것을 문서로 적으면, 그 어설픔이 결과물에 그대로 들어갑니다. 모르는 것은 적지 않는 편이 낫습니다. Claude가 고르게 하고, 왜 골랐는지 물어보면 됩니다.

2.2 적는 데 지쳐 만들지 못한다

템플릿을 다 채우는 데 하루가 걸린 분도 있었습니다. 하루를 쓰고 나면 만들기도 전에 지칩니다. 그리고 막상 만들어 보면 명세서의 절반은 '이게 아니었네'가 됩니다. 만들어 보기 전에는 자기가 무엇을 원하는지 정확히 모르기 때문입니다. 이것은 개발을 모르는 분만의 문제가 아닙니다. 개발자도 만들어 봐야 압니다. 다만 개발자는 그것을 알기에 명세서를 가볍게 씁니다.

2.3 명세서가 있다고 검토를 건너뛴다

가장 큰 문제는 이것이었습니다. 명세서를 열심히 쓴 분일수록 결과물을 덜 열어 봤습니다. "명세서대로 만들었겠지"라고 생각하는 것이죠. 그런데 AI는 명세서의 모든 줄을 지키지 않습니다. 3장에서 CLAUDE.md의 규칙도 어길 때가 있다고 했던 것과 같습니다. 명세서가 길수록 어긴 줄을 찾기도 어렵습니다.

3. 이 책의 방식

그래서 이 책은 순서를 바꿉니다.

  1. 한 문단으로 시킵니다. 누가 쓸 것이고, 무엇이 보여야 하고, 무엇은 하지 말아야 하는지. 아는 것만 적습니다. 모르는 것은 Claude에게 고르게 합니다.
  2. 바로 만듭니다. Code 탭에 맡깁니다. 몇 분이면 첫 결과물이 나옵니다.
  3. 검토합니다. 열어 보고, 눌러 보고, 좁혀 보고, 읽어 봅니다. 이 책에서 가장 많은 시간을 쓰는 곳입니다.
  4. 다듬거나 다시 만듭니다. 간단하면 이어서 고치고, 아니면 배운 것을 반영해 한 문단을 다시 씁니다.
  5. 만든 뒤에 명세를 남깁니다. 완성된 것을 보고 Claude가 명세를 씁니다. 다음 버전의 브리프, 다른 사람에게 넘길 때의 문서가 됩니다.

앞선 책에서 명세서에 들어가던 정보가 사라진 것은 아닙니다. 자리를 옮겼을 뿐입니다. '무엇을 만들지'는 브리프로, '어떻게 만들어졌는지'는 역방향 명세로, '지켜야 할 규칙'은 4장의 하네스로 갔습니다. 시간의 무게 중심이 문서 작성에서 검토로 옮겨간 것이 핵심입니다.

그렇다면 명세서는 영영 필요 없을까요? 그렇지 않습니다. 여러 사람이 돈을 걸고 몇 달을 만드는 서비스라면 여전히 명세서가 필요합니다. 다만 그 명세서는 이 책의 방식으로 만든 프로토타입을 보고 쓰는 것이 훨씬 정확합니다. 그리고 그 단계에 이르렀다면 앞선 책의 3부와 개발자의 도움이 필요한 때입니다. 이 책은 그 전까지, 즉 개발 전문가가 아닌 분이 혼자 만들어 보는 단계를 다룹니다.

4. 이 장의 구성

절내용
10.2한 문단 브리프 쓰는 법
10.3검토하는 법
10.4다듬기와 되돌리기
10.5만든 뒤에 명세 남기기
10.6실전, 감귤 주문 접수 페이지

3장부터 실습마다 조금씩 해온 것을 여기서 하나의 방법으로 묶습니다. 9.6에서 처음부터 끝까지 한 번에 따라 해보는 것으로 이 책을 마칩니다.