마가 끼다…

마가 낀게 틀림없다. (<-- 대부분의 쪼다 프로그래머들이 하는 변명 ㅠㅜ) 올들어 총 37번의 엔진 릴리즈가 있었다. 그림은 그 릴리즈 때마다 태그를 붙여둔 리비전 그래프다. 그런데 우습게도 이 중에 거의 삼분지 일에 해당하는 10번의 릴리즈가 5월 중순부터 5월 말까지 발생했고, 안타깝게도 그 릴리즈에 모두 소소한 문제가 있었다. 물론 지원팀 덕분에 그 파급 효과가 고객에게 미치지는 않았다. 단지 내부적으로 엄청난 피로도가 누적되는 과정이 있었을 뿐이다.

너무 어처구니가 없어서 릴리즈 노트를 보면서 무엇이 이런 참담한 결과를 가져왔나 꼼꼼히 살펴 보았다. 그 복기 과정을 통해서 난 반드시 기억해야 할 아주 중요한 교훈 두 가지를 얻었는데 다음과 같은 것이었다.

1. 버그 수정과 기능 추가를 한 릴리즈에 묶는 행위가 재앙을 만든 일등 공신이었다. 난 항상 별 생각 없이 기능 추가와 버그 수정이 동시에 일어난 빌드를 릴리즈 했는데 이게 말 그대로 헬 게이트를 여는 원인이 돼 버렸다. 이게 잘 될 때는 기능 추가도 되고 버그 수정도 되는 꿀빠는 일이지만 안 될때는 말 그대로 버그 수정을 했는데 신규로 추가된 기능에서 버그가 또 새롭게 잉태돼서 계속 쓰지도 못하는 코드가 릴리즈 돼 버리는 문제가 있었던 것이다. 버그 수정과 기능 추가를 분리해서 빌드 했다면 적어도 중간에 하나씩은 쓸 수 있는 빌드가 생겼을 것이다.

2. 코딩 허세. 코딩 허세. 허세가 문제였다. 10번의 실패한 릴리즈 중에서 8번이 동일한 로직 변경 과정에서 발생했다. 린스타트업과 같은 방식으로 검증을 통해서 차근차근 접근할 수도 있는 부분이었는데 내 허세가 한 번에 완성할 수 있다는 생각을 만든 것이다. 그도 그럴것이 실제로는 아주 간단한 조건을 변경하는 것이었기에 더 쉽게 생각됐다. 하지만 그 사소한 조건의 변화가 미칠 수 있는 파급 효과는 실로 어마어마했다. 내가 무엇을 상상하던 그것보다 훨씬 더 컸다. 그 결과 릴리즈를 8번이나 날려 먹고서야 제대로 만들 수 있었다. 검증 단계를 통해서 접근 했다면 시간은 더 걸리더라도 지원팀에서 검증 작업에 이토록 애를 먹지는 않았을 것이다.

이 과정 중에서도 내가 잘한 일이 하나 있다. 바로 릴리즈에 개입하지 않았다는 점이다. 회사 초기에는 내가 릴리즈를 할 때도 있었고, 지원팀에서 릴리즈를 할 때에도 내가 개입하는 경우가 많았는데 언제부턴가 본능적으로 내가 개입하지 않아야 문제가 덜 발생한다는 사실을 알게 되었다. 그래서 이런 문제점들이 고객들에겐 표출되지 않을 수 있었다.

물론 본질적으로 모든 문제는 내가 집중해서 제대로 일하지 않았기 때문에 발생한 일들이다. 그 모든 잘못의 근본적인 원인의 면면을 살펴보면 결국 내가 제대로 프로그램을 만들었으면 애초에 하나도 발생하지 않았을 일들이다. 그래서 더 가슴 아프다.

자원은 항상 부족하다. 정신 차리고 제대로 일하는 수 밖에는 없다. 작은 업체가 살아남는 방법은 뛰면서 쏘는 방법 밖에는 없으니까 말이다.

덧) 포스의 어두운 면과 밝은 면은 항상 공존하는 것처럼 이런 참담한 결과가 나쁜 점만 있었던 건 아니었다. 테스트 코드가 훨씬 더 많이 필요하다는 인식이 생겼고, 엔진의 릴리즈 현황을 자동으로 추적할 수 있는 훌륭한 백엔드 시스템도 만들어졌다.