슬라이드 27 · Chapter 5 — 챕터 질문

청구서는 어떤 모양으로 도착하는가?

30분에 기록된 SaaS가 90일 뒤 무엇으로 변하는가

청구서가 한 장씩 오는 것이 아니라 동시에 도착한다. 5가지 청구서를 분석한다.

---

슬라이드 28 · Chapter 5 — 5종 청구서

① 기술 부채 — 코드 중복 4배

② 보안 — 2.74배 취약. 인증 우회.

③ 데이터 모델 — 나중에 바꾸기 가장 어려운 결정

④ 운영 — 같은 코드, 다른 환경, 다른 결과

⑤ 인간 역량 — 17% 디버깅 저하

다섯 청구서는 한 자리에 동시에 도착한다.

---

슬라이드 29 · Chapter 5 — 기술 부채: 코드 중복 4배

같은 책임을 가진 함수가 서로 다른 파일에서 조금씩 다른 모양으로 4번 정의된다.

AI는 매번 이미 있는 것을 모르는 채 새로 짠다. 함수 이름은 다 다르다. 그러나 결국은 같은 일을 한다.

validate_email()이 4군데에서 다르게 작동한다.

이것이 AI의 잘못이 아니라, 컨텍스트에 어제까지의 결정을 우리가 안 박은 것이다.

---

슬라이드 30 · Chapter 5 — 17% 디버깅 저하

설계 없이 AI에 곧바로 위임한 사용자 그룹과 명세를 먼저 박은 후 위임한 그룹을 비교했다.

후자는 디버깅 능력을 잃지 않았다. 전자는 17% 저하가 측정되었다.

차이를 만든 것은 도구가 아니라 사용 방식이었다.

AI가 능력을 빼앗는 것이 아니라, 우리가 주는 것이다. 이것이 4개 챕터에서 누적된 메시지의 가장 잔혹한 형태.

---

슬라이드 31 · Chapter 5 — 다섯 청구서, 단일 원인

다섯 청구서, 단일 원인. 검증 없는 위임

그리고 산업의 회귀가 시작된다. 다음 장이 그 답: 명세 주도 개발.