어쩔 수 없는 개발자인가봐

개발자라면 누구나 개발하면서 일어날 수 있는 모든 상황에 대해 고려해야 한다. 예를 들면, 어떤 기능을 구현할 때 발생할 수 있는 모든 예외 상황이나 구현 후 배포했을 때 발생할 수 있는 버그 혹은 장애 상황 등이다. 이런 것들은 아주 기초적인 고려사항이고, 개발자로서 레벨이 높아지면 시스템을 아우르는 문제들, 작은 비즈니스 로직 이면에 시스템이 운영되는 모든 아키텍쳐 레벨의 문제를 항상 고려해야 한다. 연계된 모든 컴포넌트에 미칠 수 있는 영향을 수치화 하고 검증하는 과정이 필요하다.

이런 습관은 아마도 개발자로서 불완전한 시스템을 조금 더 완전에 가깝게 만드는 좋은 습관이다. 물론 이런 고민이 너무 깊거나 앞서 나가면 흔히 말하는 오버 엔지니어링으로 가는 길이 된다. 소프트웨어 엔지니어링의 모든 것은 트레이드-오프이므로 이런 모두 고려 또한 적절한 수준에서 멈출줄 아는 것이 높은 레벨의 개발자로서 갖춰야 할 소양일 것이다.

이런 특성은 비단 개발에만 적용할 수 있는 것은 아니다. 일상적인 상황에서도 얼마든지 적용 가능한데, 예를 들어 어떤 약속이 생겼을 때 약속에 갈 수 없는 일이 생길 수 있는 상황, 약속 장소에 가는 경우의 수 등을 고려할 수 있고, 돌아오는 길에 들러 사올 수 있는 야식의 경우의 수 또한 고려할 수 있다. 다만 이 경우에도 오버-고려는 결과의 복잡도만 높일 뿐이므로 적절히 트레이드-오프 하는 것이 중요하다.

나는 이러한 행동(모두 고려하기)을 철저히 엔지니어링 분야에서만 발휘하는 편이다. 일상 생활에서는 절대로 두 가지 이상의 경우의 수를 생각하지 않는다. 목적지에 가는 두 개의 길이 걸리는 시간이 수십 분 이상 차이나더라도 처음 정했던(아마도 전날 자기 전에 찾아둔) 경로를 따라 간다. 왜냐하면 이런 생각의 나래를 펼치고 가능한 모든 경우의 수를 대응하는 일은 그 자체로 피곤하고 정신력이 많이 소모되는 일이기 때문이다. 더욱이 엔지니어링 분야에서 이런 문제는 근본적으로 발본색원 할 수 없는 문제이기 때문에 언제나 구멍이 생기기 마련이고, 이런 구멍을 빠르게 메우는 것 또한 매우 중요한 일이기 때문이다.

다만 최근 아내와 얘기하면서 나도 모르게 이런 모두 고려를 생활에까지 적용하고 있는 것을 발견했다. 게다가 오버-엔지니어링으로 비개발자인 아내는 도저히 이해할 수 없는 고려 사항때문에 이를 이해시키느라 애먹었다. 물론 끝까지 이해시키지는 못했지만, 다시 한 번 모두고려와 트레이드-오프에 대해 생각하는 계기가 되었다. 이런 고려하기 습관이 어떤 상황에서는 유난스럽고 이해되지 않을 수 있다는 사실을 새로 깨닫게 되었다. 다시 한 번 나의 말도 안되는 억지 고려에 당황했을 아내에게 심심한 사과를 보낸다.