작가 단상 28. 실패를 설계한다
- V4 개발일지에서 배운 것 -
개발을 시작한 지 세 달째였다. 처음엔 단순히 "AI가 코드를 대신 써주면 금방 완성되겠지"라고 생각했다. 그러나 현실은 달랐다. AI는 코드를 써줬지만, 나는 여전히 실행되지 않는 프로그램 앞에서 밤을 새우는 인간이었다.
한 줄의 에러 메시지를 이해하기 위해 세 번 검색하고, 패키지 충돌을 해결하다 하루가 가고, 결국 아무것도 완성하지 못한 채 하루를 닫는 날이 이어졌다.
"AI가 해줄 줄 알았는데, 결국 내가 해야 하는 일이 이렇게 많을 줄이야."
1. V3.0, 한 번에 하려다 한 번에 무너졌다
나는 욕심을 냈다. "이번엔 완벽한 걸 만들어야지." 검색, 생성, 차트, 변환, 다운로드 — 모든 기능을 한 번에 통합하려 했다.
결과는 참혹했다. 코드는 돌아가지 않았고, 어디서 문제가 생겼는지조차 알 수 없었다. 디버깅을 시작하면 꼬리에 꼬리를 물고 또 다른 에러가 나타났다. 모든 걸 한 번에 만들려던 그 구조가, 결국 나를 '한 번에 무너뜨린' 원인이었다.
그때 깨달았다. "코드를 나눈다고 해서 개발이 쉬워지는 게 아니다. 하지만 문제를 나누면, 실패는 작아진다."
2. V4, 실패를 나누는 시스템
그래서 V4는 달랐다. 나는 이번엔 코드를 모듈로 쪼개는 대신, 실패를 모듈로 쪼개기로 했다.
검색은 검색대로, 생성은 생성대로, 변환은 변환대로 — 하나의 기능이 완성될 때마다 멈추고 테스트했다.
"이번엔 잘 되겠지?"
"어디서부터 망가졌는지 알겠어."
문제가 생기면 그 섹션만 다시 고치면 됐다. 전체를 뒤엎을 필요가 없었다. 에러가 줄어든 게 아니라, 에러를 감당할 수 있게 된 것이다.
3. 작은 성공 여섯 개가 큰 실패 하나보다 낫다
나는 이 원칙을 노트 상단에 적었다.
"V4는 문제를 나눈 게 아니라, 리스크를 나눈 것이다."
"V4는 작업을 나눈 게 아니라, 불확실성을 나눈 것이다."
"V4는 시간을 나눈 게 아니라, 공포를 나눈 것이다."
"큰 실패 하나보다, 작은 성공 여섯 개가 낫다."
한 줄 한 줄, 과거의 나에게 보내는 경고이자 약속이었다. 모든 걸 한 번에 하려던 과거의 나는, 결국 모든 걸 잃었다.
하지만 이번엔 달랐다. 작은 기능 하나를 완성할 때마다, 작은 성취감이 쌓였다. 그 감각이 나를 끝까지 이끌었다.
4. AI와 인간의 경계에서
AI는 여전히 놀라운 도구다. 코드를 제안하고, 해결책을 설명하고, 방향을 잡아준다. 하지만 여전히 버튼을 누르는 건 사람이다. AI는 코드를 만들어주지만, "이 코드가 의미 있는가?"를 판단하는 건 결국 인간의 일이다.
AI가 실패를 대신 감당해주진 않는다. 그래서 나는 시스템을 바꿨다. AI에게 모든 걸 맡기는 대신, AI가 다룰 수 있는 단위를 설계했다. 그 단위가 바로 V4의 구조다.
5. 나는 더 이상 완벽을 만들지 않는다
이제 나는 완벽한 코드를 만들려 하지 않는다. 대신 작동하는 코드를 만든다. 완벽은 끝없는 미로고, 작동은 다음 단계로 가는 문이다.
하루의 목표는 단 하나다. "어제보다 덜 무너지는 것." 그게 누적되면, 결국 완성된다.
AI 시대의 개발은 빠르다. 하지만 빠르다고 해서, '사람이 겪어야 하는 시행착오'까지 건너뛸 수는 없다.
다만 그 시행착오를 더 작게, 더 자주, 더 통제 가능하게 만들 수 있을 뿐이다.
6. 실패를 설계하는 사람
이제 나는 실패를 두려워하지 않는다. 실패를 설계하기 때문이다. 리스크를 한 번에 떠안는 대신,
작은 실패 여섯 개를 미리 배치해 둔다. 그 여섯 개 중 다섯 개가 실패해도, 하나는 살아남는다.
그리고 그 하나가 내일의 출발점이 된다.
"V4는 코드를 나눈 게 아니라, 실패를 나눈 것이다."
이 문장은 이제 나의 철학이자, 시스템의 기초가 되었다.
그날 이후 나는 개발을 단순히 "코드를 짜는 일"이라 부르지 않는다.
나는 이제 '실패를 설계하는 사람'이다.
AI가 쓴 코드는 많지만, 그 코드를 돌리는 건 결국 사람이다.
그리고 그 사람이 실패를 어떻게 설계하느냐가, 프로젝트의 성패를 가른다.
