최근 진행했던 두 번의 프로젝트는 내게 무척 새로운 프로젝트였습니다. 왜냐하면 프로젝트의 목적이 특정 기능의 개발이 아닌 기존 코드의 리팩토링이었기 때문입니다. 첫 프로젝트를 진행할 때 저의 최초 관심은 '개선'이었습니다. 어떻게 하면 소스를 좀 더 유지보수하기 좋게 만들 수 있을까? 하지만 실제로 프로젝트를 시작하고 전반적인 작업의 진행을 시작하자 저의 관심은 개선에서 점차 '검증'쪽으로 향하게 되었습니다. 왜냐하면 개선을 하며 자연스레 발생하는 영향력이 어마어마하다는 것을 깨달았기 때문입니다. 좋은 예로써 핵심 클래스의 인터페이스를 수정해야 하는 경우가 있었습니다. 그런데 그 수정으로 인해 영향 받는 부분을 살펴보자 영향 받는 하위 프로젝트만도 10개[1]가 넘었습니다. 따라서 개선도 개선이지만 검증을 성공적으로 하는 것이 매우 중요하게 느껴졌습니다.

어떻게 하면 검증을 성공적으로 할 수 있을까? 가장 먼저 생각난 것은 QA(Quality Assurance)였습니다. 제가 일하는 환경에는 능력이 매우 뛰어난 QA부서가 있었고, 사내 표준 프로세스상 배포해야 하는 모든 제품은 반드시 QA를 거쳐야 했습니다. 따라서 열심히 리팩토링을 한 후 QA에게 검증을 요구하는 것은 매우 자연스러운 일이었습니다. 하지만 곰곰이 생각해볼 때 몇 가지 면에서 문제를 느꼈습니다.

첫째는 위에서 얘기했던 것처럼 영향 받는 범위가 매우 크다는 점이었습니다. 제가 일하는 환경의 QA는 보통 블랙박스 관점으로 기능 중심의 검증을 수행했습니다. 따라서 보통의 경우 개발자가 특정 부분을 수정하면 수정한 부분으로 인해 영향 받는 기능을 QA에게 이야기 했습니다. 이 경우 QA는 매우 기본적이며 핵심적인 주요 기능에 대한 검증을 진행하는 것과 더불어 수정으로 인해 영향 받은 기능을 추가적으로 검증했습니다. 하지만 제가 진행했던 리팩토링의 경우 위와 같은 방법으로 수정범위를 얘기하려고 하면 거의 모든 기능을 검증 해달라고 말해야 했습니다. 왜냐하면 위에서 얘기했듯이 영향력이 어마어마했기 때문입니다. 더욱이 당시 QA 자원이 많이 부족한 상태였는데 거의 모든 기능에 대해 검증해달라고 말하는 것은 바람직하지 못해 보였습니다.

둘째는 문제 발견 시점에 따른 비용증가 때문이었습니다. FEDEX에는 1-1-100원칙이 있습니다. 이 원칙은 제품을 출고하기 전에 문제를 발견하면 비용이 1만 필요하지만 출고 후에는 10의 비용이 필요하며 고객에게 항의가 들어오면 100의 비용이 필요하다는 원칙입니다. 이 원칙은 소프트웨어에도 그대로 적용된다고 봅니다. 아래 표는 실제 내가 일하는 환경에서 발생하는 현상을 바탕으로 작성했습니다.

문제 발견 시점	관련 자원(문제 처리 비용)
개발자가 개발 중	담당 개발자
QA 중	BTS(Bug Tracking System)  외부와 의사소통 담당하는 개발자  담당 개발자
배포 후 서비스 중	고객  문제/장애 알림 시스템  서비스 기획자  서비스 운영 책임 개발자  BTS(Bug Tracking System)  담당 개발자  QA  배포 담당자(재배포가 필요하기 때문에)

각 환경에 따라 다소 차이는 있겠지만 큰 맥락에서 위 표와 크게 다르지는 않을 것이라 생각합니다. 위 표를 보면 FEDEX 원칙과 유사하게 문제가 늦게 발견되면 될수록 처리하는 데 필요한 관련 자원이 증가함을 볼 수 있습니다. 따라서 특수한 환경이 아니라면 QA 단계에서 문제를 발견하는 것 보다는 개발자가 문제를 발견하는 것이 조직 전체 비용 관점에서는 유리합니다.

마지막으로 QA가 탐지하기 어려운 영향력이 있다는 점 때문입니다. 위에서 잠시 애기했듯이 QA는 블랙박스 관점으로 기능중심의 검증[2]을 수행합니다. 이 경우 화면으로 즉시 보여지는 부분에 대해서는 매우 높은 수준의 검증이 가능합니다. 예를 들어 화면상의 특정 부분이 일그러져 보이거나, 확연히 구분할 수 있게 문자 등으로 오류가 보이는 등의 문제점입니다. 하지만 월말이 되어 통계 화면에서 보여지는 데이터의 입력이 누락되거나 하는 문제는 발견하기 어렵습니다. 이러한 문제는 외부로 즉시 드러나지 않기 때문입니다.

따라서 저는 QA에게 모든 검증을 의존하는 것은 좋지 못한 선택이라고 생각합니다. 그것보다는 개발자가 최전방에서 적극적으로 보다 많은 검증을 수행해야 한다고 봅니다. 물론 QA를 배제할 생각은 없습니다. 다만 일차적으로 개발자가 나름의 방법으로 검증을 먼저 진행한 후 이차로 QA가 검증하는 이중검증이 더 좋은 결과를 만들 것이라 생각합니다. 이중검증은 동일한 문제를 전혀 다른 방법으로 검증하여 검증의 정확도를 더욱 높이는 방법입니다. 일반적으로 개발자와 QA의 시각은 많이 다른 편이기 때문에 각자가 생각하는 최선의 방법으로 이중검증[3]을 하면 분명히 긍정적 효과가 있으리라 봅니다.

참고 설명

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

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

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

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

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

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

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

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