336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
최근 진행했던 두 번의 프로젝트는 내게 무척 새로운 프로젝트였습니다. 왜냐하면 프로젝트의 목적이 특정 기능의 개발이 아닌 기존 코드의 리팩토링이었기 때문입니다. 첫 프로젝트를 진행할 때 저의 최초 관심은 '개선'이었습니다. 어떻게 하면 소스를 좀 더 유지보수하기 좋게 만들 수 있을까? 하지만 실제로 프로젝트를 시작하고 전반적인 작업의 진행을 시작하자 저의 관심은 개선에서 점차 '검증'쪽으로 향하게 되었습니다. 왜냐하면 개선을 하며 자연스레 발생하는 영향력이 어마어마하다는 것을 깨달았기 때문입니다. 좋은 예로써 핵심 클래스의 인터페이스를 수정해야 하는 경우가 있었습니다. 그런데 그 수정으로 인해 영향 받는 부분을 살펴보자 영향 받는 하위 프로젝트만도 10개[1]가 넘었습니다. 따라서 개선도 개선이지만 검증을 성공적으로 하는 것이 매우 중요하게 느껴졌습니다.
어떻게 하면 검증을 성공적으로 할 수 있을까? 가장 먼저 생각난 것은 QA(Quality Assurance)였습니다. 제가 일하는 환경에는 능력이 매우 뛰어난 QA부서가 있었고, 사내 표준 프로세스상 배포해야 하는 모든 제품은 반드시 QA를 거쳐야 했습니다. 따라서 열심히 리팩토링을 한 후 QA에게 검증을 요구하는 것은 매우 자연스러운 일이었습니다. 하지만 곰곰이 생각해볼 때 몇 가지 면에서 문제를 느꼈습니다.
첫째는 위에서 얘기했던 것처럼 영향 받는 범위가 매우 크다는 점이었습니다. 제가 일하는 환경의 QA는 보통 블랙박스 관점으로 기능 중심의 검증을 수행했습니다. 따라서 보통의 경우 개발자가 특정 부분을 수정하면 수정한 부분으로 인해 영향 받는 기능을 QA에게 이야기 했습니다. 이 경우 QA는 매우 기본적이며 핵심적인 주요 기능에 대한 검증을 진행하는 것과 더불어 수정으로 인해 영향 받은 기능을 추가적으로 검증했습니다. 하지만 제가 진행했던 리팩토링의 경우 위와 같은 방법으로 수정범위를 얘기하려고 하면 거의 모든 기능을 검증 해달라고 말해야 했습니다. 왜냐하면 위에서 얘기했듯이 영향력이 어마어마했기 때문입니다. 더욱이 당시 QA 자원이 많이 부족한 상태였는데 거의 모든 기능에 대해 검증해달라고 말하는 것은 바람직하지 못해 보였습니다.
둘째는 문제 발견 시점에 따른 비용증가 때문이었습니다. FEDEX에는 1-1-100원칙이 있습니다. 이 원칙은 제품을 출고하기 전에 문제를 발견하면 비용이 1만 필요하지만 출고 후에는 10의 비용이 필요하며 고객에게 항의가 들어오면 100의 비용이 필요하다는 원칙입니다. 이 원칙은 소프트웨어에도 그대로 적용된다고 봅니다. 아래 표는 실제 내가 일하는 환경에서 발생하는 현상을 바탕으로 작성했습니다.
각 환경에 따라 다소 차이는 있겠지만 큰 맥락에서 위 표와 크게 다르지는 않을 것이라 생각합니다. 위 표를 보면 FEDEX 원칙과 유사하게 문제가 늦게 발견되면 될수록 처리하는 데 필요한 관련 자원이 증가함을 볼 수 있습니다. 따라서 특수한 환경이 아니라면 QA 단계에서 문제를 발견하는 것 보다는 개발자가 문제를 발견하는 것이 조직 전체 비용 관점에서는 유리합니다.
마지막으로 QA가 탐지하기 어려운 영향력이 있다는 점 때문입니다. 위에서 잠시 애기했듯이 QA는 블랙박스 관점으로 기능중심의 검증[2]을 수행합니다. 이 경우 화면으로 즉시 보여지는 부분에 대해서는 매우 높은 수준의 검증이 가능합니다. 예를 들어 화면상의 특정 부분이 일그러져 보이거나, 확연히 구분할 수 있게 문자 등으로 오류가 보이는 등의 문제점입니다. 하지만 월말이 되어 통계 화면에서 보여지는 데이터의 입력이 누락되거나 하는 문제는 발견하기 어렵습니다. 이러한 문제는 외부로 즉시 드러나지 않기 때문입니다.
따라서 저는 QA에게 모든 검증을 의존하는 것은 좋지 못한 선택이라고 생각합니다. 그것보다는 개발자가 최전방에서 적극적으로 보다 많은 검증을 수행해야 한다고 봅니다. 물론 QA를 배제할 생각은 없습니다. 다만 일차적으로 개발자가 나름의 방법으로 검증을 먼저 진행한 후 이차로 QA가 검증하는 이중검증이 더 좋은 결과를 만들 것이라 생각합니다. 이중검증은 동일한 문제를 전혀 다른 방법으로 검증하여 검증의 정확도를 더욱 높이는 방법입니다. 일반적으로 개발자와 QA의 시각은 많이 다른 편이기 때문에 각자가 생각하는 최선의 방법으로 이중검증[3]을 하면 분명히 긍정적 효과가 있으리라 봅니다.
참고 설명
어떻게 하면 검증을 성공적으로 할 수 있을까? 가장 먼저 생각난 것은 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]을 하면 분명히 긍정적 효과가 있으리라 봅니다.
참고 설명
[1] 제가 리팩토링을 진행했던 프로젝트는 공통 라이브러리 성격의 프로젝트였습니다.
[2] 제가 일하는 환경에는 QA가 블랙박스 테스트만 하지만, 개발자 출신의 QA가 코드검토와 같은 화이트박스 테스트를 진행하는 곳도 있다고 합니다.
[3] 켄트벡의 익스트림 프로그래밍이라는 책에 보면 재확인(Double Checking) 원칙이 소개됩니다. 이 원칙은 문제를 해결할 때 전혀 다른 방법 두 가지로 각각 문제를 해결한 후에 결과를 비교해 보아 결과의 정확성을 보장하는 방법입니다. 마찬가지로 개발자는 개발자의 관점에서 QA는 QA의 관점에서 각기 다르게 검증을 수행한다면 좀더 정확한 검증을 할 수 있을 것이라 생각합니다.
수정 이력
2010/05/07 : 이 주제가 여러 편에 걸쳐 게시되었기 때문에 내용이 중복되지 않고 읽는이가 부드러운 흐름을 타게하기 위해 내용을 다소 수정합니다.
수정 이력
2010/05/07 : 이 주제가 여러 편에 걸쳐 게시되었기 때문에 내용이 중복되지 않고 읽는이가 부드러운 흐름을 타게하기 위해 내용을 다소 수정합니다.
WRITTEN BY
- 차민창
르세상스 엔지니어가 사회를 이끌어나가는 상상을 하며!
,
