개발자라면 누구나 한 번쯤 해결할 수 없을 것 같은 버그를 만난 적이 있을 것입니다.
분명히 문제가 있긴 있는데 도저히 왜 발생하는지 모르겠고 어떻게 고치는지 알 수 없는 경우가 있습니다.
대부분의 경우 근성으로 문제를 해결하게 됩니다만... 우리에게 주어진 시간은 한정적이며 해결해야 할 문제는 항상 쌓여 있기 마련입니다.
그래서 때로는 정석이 아닌 해결책을 선택해야 할 순간이 옵니다.
가장 먼저 고려할 수 있는 방법은, 문제가 되는 데이터가 왜곡되었을 때 그 데이터를 바로잡기 위한 별도의 프로그램을 만드는 것입니다.
당장 서비스중인 프로그램인 경우 당장 문제를 해결하지 못하면 안되기 때문입니다.
일단 프로그램을 주기적으로 돌려 문제를 임시로 해결하고, 천천히 버그의 근본 원인을 분석하면 됩니다.
대충 땜빵쳐 놓고 실제로 고치는건 나중에 하는겁니다.
이렇게 시간을 벌면서 문제를 해결하는 과정은, 불가피한 상황에서 유용한 전략이 될 수 있습니다.
때로는 아예 처음부터 다시 만드는 방법도 고려할 수 있습니다.
경험상, 처음부터 다시 만든 프로젝트에서 기존의 버그가 사라지는 경우를 여러 번 겪었습니다.
처음부터 만드는건 매우 번거롭고 오래걸리는 일입니다.
하지만 생각보다 오래 걸리지는 않을겁니다. 처음 만들 때보다는 금방 완성할 수 있습니다.
처음 만들 때보다 시간이 덜 걸리는 이유는, 이미 그 프로젝트의 구조가 머릿속에 자리 잡고 있기 때문입니다.
처음부터 다시 만들기를 두려워하지 말고, 오히려 더 빠르고 효율적인 해결책이 될 수 있다는 점을 염두에 두는 것이 좋습니다.
그러나 버그가 도저히 해결되지 않거나, 해결에 시간이 걸릴 것으로 예상된다면, 공지를 통해 문제의 발생 사실을 알리고 사과문을 올리는 것도 하나의 방법입니다.
문제를 정확하게 알리고 해결 시간을 명시해두면, 사용자와의 신뢰를 지킬 수 있습니다.
기능 자체를 일시적으로 막아두고 버그를 수정한 후 다시 배포하는 것도 고려해볼 만한 방법입니다.
이러한 상황은 개발자로서 자존심이 상할 수 있는 일입니다.
하지만, 실제 서비스에서는 제한된 시간 내에 반드시 결단을 내려야 할 때가 있습니다.
문제가 발생한 범위를 명확하게 규정하고, 더 이상 피해가 확산되지 않도록 선을 긋는 것이 바로 개발자의 중요한 역할 중 하나입니다.
버그가 발생했다면, 가장 먼저 해야 할 일은 그 버그가 어떤 문제를 일으키고 있는지 전파하고, 영향 범위를 명확히 하는 것입니다.
어떤 원인으로 인해 버그가 발생했으며, 그로 인해 어떤 영향을 받았는지, 이를 해결하는 데 얼마나 시간이 걸릴 것인지를 투명하게 소통하는 것은 책임 있는 개발자의 자세입니다.
우리가 돈을 받고 일하는 개발자라면, 이런 책임과 절차를 반드시 지키며 버그 해결에 임해야 합니다.
