개발은 빨라졌지만 엔지니어링은 여전히 시간의 문제다

“앱을 만들었다"와 “서비스를 운영한다” 사이에는 생각보다 훨씬 큰 간극이 있다. 나는 이 차이를 배포 후 장애를 맞고 나서야 제대로 이해했다.

로컬에서 잘 돌아가던 기능이 실사용 트래픽, 실패 재시도, 지연 이벤트, 사용자 다양성 앞에서 매우 다른 시스템이 된다.

내 경험: 개발의 성공이 운영의 성공을 보장하지 않았다

바이브 코딩으로 기능 구현 속도는 확실히 빨라졌다. 하지만 배포 이후에는 전혀 다른 문제가 올라왔다.

• 장애를 재현할 수 없는 로그 구조
• 응답 시간은 괜찮은데 사용자 불만은 높은 상태
• 오류율이 낮아도 비즈니스 핵심 흐름이 깨지는 상황

이 시점부터 나는 “개발"과 “엔지니어링"을 분리해서 보기 시작했다.

• 개발: 기능을 만든다.
• 엔지니어링: 시간이 흘러도 기능이 살아남게 만든다.

참고: Martin Fowler 역시 AI 개발 논의에서 “생성 이후의 유지보수 구조화"를 핵심 문제로 다룬다. Spec-Driven Development: Tools

내가 바꾼 기준: 기능 완료가 아니라 운영 가능성

기능이 끝났는지 판단하는 기준을 바꿨다.

1. 재시도/복구 경로가 정의됐는가
2. 실패를 탐지할 지표와 알람이 있는가
3. 장애 시 수동 개입 없이 복구 가능한가
4. 책임 경계(서비스/큐/DB)가 문서화됐는가

이 기준을 통과하지 못하면 기능이 아니라 실험 코드로 분류했다.

참고: Google SRE Workbook은 운영 품질 판단을 SLI/SLO 같은 측정 가능한 경계로 다루라고 제안한다. Implementing SLOs

지금의 결론

AI 덕분에 개발 속도는 빨라졌다. 하지만 엔지니어링은 여전히 느리고, 의도적으로 느려야 한다.

운영은 결국 다음 질문에 답하는 일이다. “이 시스템은 내일도 설명 가능하고 복구 가능한가?”

참고: Fred Brooks의 고전적 경고처럼, 단일 도구만으로 운영 복잡성이 사라지지는 않는다. No Silver Bullet (1986)

나는 이제 기능 데모보다 복구 가능한 구조를 먼저 확인한다. 그게 “만든 코드"와 “내 서비스"를 가르는 기준이었다.