결과물이 곧 명세다

이 장을 쓰는 오늘, 저는 위니버시티 요금제 화면을 보다가 AI에게 한 줄을 말했습니다. 어떤 혜택이 어느 요금제의 것인지 카드끼리 맞춰 볼 수가 없으니 항목별로 줄을 맞춰 달라는 말이었습니다. AI가 원인을 찾아 고쳤고, 고친 화면은 오늘 운영에 나가 있습니다. 저는 어느 파일을 고치라고 말하지 않았고, 줄 높이를 몇으로 맞추라고도 말하지 않았습니다. 그 카드를 만들 때 이 요구를 미리 적어 둔 문서도 없었습니다. 화면을 보기 전에는 저도 몰랐으니까요.

저는 이제 가벼운 프로젝트에 요구사항 명세서가 필요하지 않다고 봅니다. 먼저 만들게 하고, 나온 것을 보고 이게 아니었네 하면 바로 바꾸면 됩니다. 구현의 값이 0에 가까워지면서 개발된 것 자체가 요구사항 명세가 됐습니다.

1. 2년 전의 저는 반대로 적었습니다

저희 회사는 원래 요구사항 명세에 가장 많은 공을 들였습니다. 화면마다 무엇이 있고 단추를 누르면 무슨 일이 일어나는지를 수백 장에 걸쳐 썼습니다. 2024년 11월에 『바이브 코딩 에센셜』 첫 원고를 쓸 때도 요구사항 명세서 장을 따로 떼어 책 전체에서 가장 중요한 장일 수 있다고 적었습니다.

그럴 이유가 있었습니다. 그때의 AI는 사람이 적지 않은 곳을 제 마음대로 채웠습니다. 온라인 쇼핑몰을 만들어 달라고 하면 저는 카테고리 네 개를 생각했는데 열두 개가 나오는 식이었습니다. 그래서 빈칸을 사람이 미리 다 채우라고 가르쳤습니다. 사용자 친화적이라고 쓰지 말고 버튼은 최소 44픽셀로, 성능이 좋아야 한다고 쓰지 말고 응답은 200밀리초 안에 쓰라고요. 모델이 좋아지면 코드의 값은 떨어지고 무엇을 만들지 정의하는 문서가 자산이 될 것이라는 예측도 적었습니다.

그 예측은 절반만 맞았습니다. 코드의 값은 정말 떨어졌습니다. 문서의 값은 올라가지 않았습니다. 문서를 쓸 시간에 하나 더 만들어 보는 쪽이 빨라졌기 때문입니다. 2026년 10월에 저는 그 장의 이름을 '요구사항 명세서'에서 '빠르게 만들고 판단하기'로 바꿨습니다. 그 개정 한 번에 그 교재에서 6,429줄을 지우고 3,946줄을 새로 썼습니다.

2. 사흘 동안 제 입에서 나온 요구사항

위룸은 저희가 쓰는 협업 노트입니다. 10월에 이 노트를 공개 홈페이지로 꾸미는 기능을 만들었습니다. 일어난 일을 순서대로 적어 보겠습니다.

10월 15일에 AI가 문서형, 스터디 홈형, 포트폴리오·팀형 세 가지 체험안을 만들었습니다. 이름과 색과 표지를 바꿔 보며 고르는 화면이었습니다. 이틀 뒤에 다시 보고 저는 셋 다 고르지 않았습니다. 템플릿 같고 밋밋했고, 노트와 따로 놀았고, 글씨가 작고 답답했고, 설정 칸을 채워 꾸미는 방식이 마음에 들지 않았습니다. 이 네 가지는 체험안을 보기 전에는 제 머릿속에 없던 말입니다.

10월 17일에 샘플 네 개가 새로 나왔습니다. 스터디 소개, 수업 자료, 개인 포트폴리오, 행사 페이지를 노트에서 홈페이지로 바꾼 모습이었습니다. 이번에는 결과물이 마음에 들었고, 보다 보니 공개하기 전에 미리 볼 단추가 있어야 사용자가 감을 잡겠다는 생각이 났습니다. 그날 밤에 실제 기능이 나왔습니다. 그것을 놓고 보니 편집 화면과 공개 화면이 너무 달라서 공개하는 순간 어색할 것 같았습니다. 흐름 네 가지가 움직이는 모형으로 나왔고, 그중 하나를 골랐습니다.

10월 18일 새벽에는 큰 것을 뺐습니다. 공개할 때 모양을 고르는 기능이 있었는데, 놓고 보니 사용자가 헷갈릴 것 같았습니다. 모양 고르기를 없애고 쓴 문서를 그대로 보여 주되 표지, 소개, 링크 단추, 하위 페이지 카드 같은 블록을 넣게 바꿨습니다. 표지는 고를 때 위치도 조정할 수 있어야 사람 얼굴이 잘리지 않습니다. 이것도 그때 나온 말입니다. 미리보기의 빈 곳에는 어떻게 채우는지 한 줄과 대신 넣어 주는 단추를 달게 했습니다. 채우는 방법을 모르면 고치지 못할 것 같았기 때문입니다.

그날 새벽에 운영에 올렸습니다. 서버, 편집기, 협업 서버, 서비스 화면, 관리자 화면까지 다섯 곳을 순서대로 고친 기능입니다.

만약 10월 15일에 제가 요구사항 명세서를 썼다면 거기에는 모양 고르기가 들어갔을 것입니다. 세 가지 안을 놓고 시작했으니까요. 얼굴이 잘리는 표지도, 공개하는 순간의 어색함도, 헷갈리는 선택지도 적을 수 없었습니다. 제가 한 요구는 전부 앞선 결과물을 보고 나왔습니다. 모양 고르기는 시험까지 통과한 뒤에 하룻밤 만에 없어졌고, 그 일로 손해 본 것이 없습니다.

말은 이 정도면 됩니다.

네가 가장 그럴듯하다고 보는 모양으로 먼저 만들어서 보여 줘. 나만 답할 수 있는 것만 물어보고, 나머지는 네가 정해. 내가 써 보고 고칠게.

3. 무거운 프로젝트는 기획해 놓고 갑니다

명세가 완전히 필요 없는 시대는 아직 아닙니다. 무거운 프로젝트는 지금도 먼저 기획해 놓고 갑니다. 달라진 것은 누가 쓰느냐입니다.

10월 21일에 저는 스터디 기능을 두고 세 문장쯤을 말했습니다. 강의에는 퀴즈와 시험이 있는데 스터디에는 설문밖에 없다, 처음 만들 때 설문과 시험과 파일 제출을 고를 수 있게 하고, 운영하는 쪽이 함께 보고, 만든 사람이 통계를 볼 수 있게 해 달라는 내용입니다.

이 기능은 위룸 홈페이지처럼 만들고 나서 뒤집기가 어렵습니다. 학생의 점수가 쌓이고, 남의 과제가 누구에게 보이는지가 걸립니다. 시험을 치른 학생이 생긴 다음에 규칙을 바꿀 수는 없습니다. 그래서 먼저 문서를 만들었습니다. 다만 그 문서는 AI가 썼습니다. AI는 기능 전체를 써 내려가면서 저에게 물어야 할 것만 일곱 가지로 추렸고, 질문마다 권장안을 달았습니다. 결과는 누가 보는가. 함께 운영하는 사람은 어디까지 할 수 있는가. 채점은 어떻게 하는가. 시험 규칙은 어떻게 하는가. 과제는 다른 참여자에게도 보이는가. 파일은 얼마나 받을 것인가. 성적표는 어떤 모양인가.

저는 권장안을 보며 골랐습니다. 운영진은 문제와 과제와 채점까지만 맡고 스터디 설정은 만든 사람만 하게 했고, 사이트의 강사 전체에게는 열지 않기로 했습니다. 시험 규칙은 제가 고르지 않았고 권장안대로 들어갔습니다. 그날 저녁에 운영에 올라갔습니다. 강의 영상 재생을 직접 만들 때는 저에게 올라온 결정이 네 건, 상담 기능 때는 열 건이었습니다.

일곱 질문을 다시 보면 누가 보는지, 누구에게 어디까지 맡길지, 얼마나 받을지를 묻고 있습니다. 표를 어떻게 나눌지, 어떤 기술을 쓸지 묻는 질문은 없습니다. 외주 계약처럼 문서가 돈과 책임의 기준이 되는 자리에도 문서는 필요합니다. 그때도 빈 양식을 사람이 채우지는 않습니다. 만들어 본 것을 놓고 AI에게 정리시키면 됩니다.

가볍다는 말의 범위는 날이 갈수록 넓어집니다. 다섯 곳을 고친 위룸 홈페이지를 저는 사흘 동안 명세 없이 만들었습니다. 2년 전이라면 명세부터 썼을 크기입니다. 앞으로는 더 무거운 것도 먼저 만들어 보는 쪽으로 넘어올 것이라고 봅니다. 먼저 정해야 하는 것은 점수와 돈처럼 뒤집을 수 없는 것이고, 나머지는 결과물이 정합니다.