[2편] 이 숫자, 얼마나 믿어야 할까 — 부풀린 것과 빠진 것

1편에서 «9명이 26개월»이라는 숫자를 봤습니다. 웃음이 났지만 그대로 믿을 수는 없었습니다.

그래서 AI에게 다시 물었습니다. «이 숫자, 어디가 부풀려졌고 어디가 빠졌나?»

부풀려진 곳

AI가 쓴 코드는 길다. 숙련된 사람 팀이라면 같은 기능을 더 적은 줄로 만들었을 겁니다. 줄 수로 환산한 공수는 실제보다 크게 나옵니다.
가정에 따라 크게 흔들린다. «하루에 몇 줄»을 어떻게 잡느냐에 따라 공수가 ±50% 달라집니다.
목업 중복은 이미 뺐다. 그래도 화면 설계도를 코드처럼 줄 수로 재는 것 자체가 거친 방법입니다.

그래서 1편의 숫자는 처음부터 깎아서 잡았습니다. 처음 계산은 앱 코드 하루 25줄로 18명이 26개월이었습니다.

이것을 하루 50줄로 넉넉하게 바꾼 것이 9명입니다.

사람 팀에서 가장 비싼 것은 코드를 치는 시간이 아니라 결정하는 시간입니다. 무엇을 만들지, 규칙끼리 부딪치면 어느 쪽을 택할지, 회원에게 어떻게 보여야 할지. 18명이 있으면 이걸 맞추는 회의와 문서 왕복, 오해 바로잡기에 엄청난 시간이 듭니다.

오늘 아침도 그랬습니다. 하이런(한 이닝 최고 득점) 규칙을 하나 바꿨습니다. «4구는 실력 계산값의 30% 이상, 3구는 20% 이상일 때 첫 하이런으로 기록하고, 그 뒤에는 기록을 넘을 때마다 새 하이런».

사람 팀이라면 이렇게 흘러갈 겁니다. 기획서를 고치고, 회의를 열고, 개발자에게 설명하고, 디자이너가 화면을 고치고, 시험 항목을 갱신합니다. 며칠은 걸립니다.

저는 AI에게 말하고, 바뀐 목업을 눈으로 확인하고, «승인» 한마디를 했습니다. 그날 안에 코드, 기획 문서, 시험이 함께 바뀌었습니다.

결정하는 사람과 만드는 손 사이에 소통 비용이 거의 없었다는 것. 기간을 가장 크게 줄인 건 바로 이것이라고 봅니다.

누빌은 아직 출시 전입니다. 실제 회원이 들어오면 새로운 일이 생깁니다. 휴대폰마다 다르게 보이는 문제, 결제 연동, 운영 데이터, 버그 신고 대응 같은 것들입니다. 사람 팀도 출시 후 1년 동안 처음 만든 만큼의 일을 또 하는 경우가 흔합니다.

저도 다르지 않을 겁니다.

정확한 배수는 모릅니다. 그러나 숫자를 아무리 깎아도 «팀 하나가 2년 넘게 붙어야 할 크기»라는 사실은 남습니다.

그리고 그 크기를 혼자 감당할 수 있었던 건 AI가 빨라서만은 아니었습니다. AI는 빠르지만 잊습니다.

어제 정한 규칙을 오늘 다른 화면에서 어기기도 합니다. 38만 줄이 무너지지 않으려면 장치가 필요했습니다.

다음 편에서는 그 장치, 제가 «바이브스킬링»이라고 부르는 방법의 세 기둥을 소개하겠습니다.