올해 초 저는 서버에서 발생하는 NullPointerException를 수정하는 업무를 하게 되었습니다. 로그를 보니 다양한 상황에서 다양한 형태로 NullPointerException이 발생하고 있었습니다. 그런데 업무을 진행하며 문제를 분석하다보니 그동안 어렴풋이 생각하던 부분이 좀더 명확해졌고 저는 이번 글에서 당시 했던 생각을 나눠보고자 합니다.

아래는 오류의 원인을 찾고있는 한 개발자의 가상사례입니다.
'

최근 대중들이 읽는 신문에도 오픈소스라는 말이 심심찮게 등장하고 있습니다. 따라서 IT업계에 종사하지 않더라도 교양 차원에서 오픈소스를 알고 있는 사람이 많아졌습니다. 그만큼 오픈소스가 사회적으로 가치를 인정받고 있다는 뜻일겁니다.

프로그래밍 전문 잡지에서는 오픈소스를 매우 상세하게 다루며, 많은 회사들은 오픈소스 도입을 적극적으로 추진하는 것으로 보입니다. 인터넷 개발자 커뮤니티에서도 오픈소스는 더이상 낯선 용어가 아닙니다. 누구나 오픈소스를 이야기하고 각자의 환경에서 활용하고 있습니다. 그렇지만 너무 오픈소스에 밝은 면만이 너무 강조되어 마땅히 경계해야 할 내용들이 무시되고 있지는 않은가 생각하게 됩니다.

저는 최근의 활발한 오픈소스 도입에 대해 가지고 있는 두려움이 있습니다. 그것은 '통제력 상실에 대한 두려움'입니다. 개발자는 코드집합에 대하여 깊고 넒은 범위에서 가능한 최대의 통제력을 가져야 할 의무가 있다고 생각합니다. 그런데 오픈소스를 도입하는 대개의 경우 통제력이 오히려 약화되는 것으로 보입니다. 이것이 바로 제 마음속에 있는 두려움의 원인입니다.

'코드에 대해 통제력을 갖는다'라는 말은 말 그대로 개발자는 코드를 통제할 수 있는 능력이 있어야 한다는 것입니다. 예를 들자면 코드를 수정할 때 수정되는 코드가 다른 부분에 미칠 영향을 파악할 수 있다면 코드에 대한 통제력이 있다고 얘기할 수 있을 것입니다. 다른 부분에 미칠 영향을 파악할 수 있다는 것은 해당 코드 집합의 전반적인 구조와 각 부분간에 관계를 알고 있다는 것을 뜻합니다.

그런데 위에서 오픈소스를 도입할 때 통제력이 오히려 약화되는 경우가 많다고 했습니다. 그 이유는 무엇입니까? 그것은 오픈소스를 도입하는 저를 비롯한 많은 사람들이 도입 후 오픈소스를 블랙박스 형태로 사용하기 때문입니다. 즉 내부의 전반적인 구조나 각 부분간의 관계를 모르고 그냥 필요한 기능을 호출하여 사용한다는 것입니다. 이것은 평상시에는 생산성이나 재활용 측면에서 매우 합리적인 방안일 수 있겠지만, 예외 상황시에는 얘기가 달라집니다. 예외가 발생하고 그 예외로 인한 문제가 생기면 빠르게 원인을 파악할 가능성이 줄어들기 때문입니다. 여기서 중요한 점은 문제의 원인을 빠르게 못찾음으로써 인해 발생하는 손실은 예상보다 훨씬 클 수 있다는 것입니다.

누군가는 문제가 생긴다 할지라도 오픈소스의 강점이기도 한 빠른 피드백과 누구나 참여 가능한 패치로 해결이 될 수 있다고 주장할지 모르겠습니다. 하지만 이것이 보증수표가 될 수는 없습니다. 내가 겪고 있는 문제가 다른 사람에게도 항상 함께 나타난다고는 볼 수 없기 때문입니다. 어쩌면 전세계에서 이 문제를 겪고 있는 곳은 여기 한 곳일지도 모르는 것입니다.

싸움에 나가는 병사가 나는 더 강한 검으로 싸우겠다며 평소에 쓰던 소검 대신 무거운 대검을 가져나갔습니다. 그런데 결정적인 순간에 대검을 빠르게 휘두르지 못해 적에게 목숨을 잃었습니다.  생명이 달린 그 중요한 순간 평소에 쓰던 소검을 사용했으면 오히려 적을 살상했을텐데 대검이 무거웠고 아직 완벽하게 통제하지 못했기 때문에 목숨을 잃는 안타까운 결과가 발생했습니다.

오픈소스 도입 역시 마찬가지라고 생각합니다. 통제할 수 있느냐와 없느냐는 결정적인 순간에 많은 차이를 낼 수 있습니다. 따라서 오픈소스 도입은 통제력을 갖추며 점진적으로 이루어지는게 좋다고 생각합니다.