오유 개발과 관련하여 SCV 란 분의 참여로 많은 논란이 있네요..
관련 업계 종사자로 기술적 대안을 한번 적어봅니다.
1. 개발 환경과 운영 환경의 분리
개발자분들은 다 아시는 내용입니다만,
실제 운영되는 오유의 DB 에 접근하면 익명을 포함한 모든 내용에 접근이 가능합니다.
대부분의 서비스 운영사들은 모든 개발자들에게 DB 에 대한 접근을 허용하지 않습니다.
대신에 운영 환경과 동일한 환경으로 개발 환경을 갖추고 있습니다.
개발 환경은 용량은 줄이되 OS 내지 System SW, DB 등을 운영 환경과 동일하게 갖춘 환경을 말합니다.
간단히 구성한다면 개발 환경은 일반 PC 한대만으로도 구성이 가능합니다.
SCV 란 분이 순수하게 개발에만 참여할 수 있도록
개발 환경에 대한 접근으로 제한한다면
큰 문제는 없을 것으로 생각됩니다.
2. 개발 내역에 대한 검증
이 부분은 개발자를 믿고 못믿고의 문제가 아니라
개발된 내역이 실제 운영 시 문제없이 동작하느냐에 대한 문제입니다.
일명 결함이라는 부분은 개발자가 찾지 못하는 경우가 많습니다.
때문에 체계화된 테스트가 이루어져야 운영 환경으로 이관 후에도
문제가 없을 수 있습니다.
이 부분에 대해서는 아래와 같은 3단계 검증을 생각해봅니다.
1차적으로는 테스트 프로그램을 이용해서 기능적 부분을 재귀적으로 검증합니다.
쉽게 말씀드려서 이번에 C 기능을 만들었지만
테스트는 A, B, C 를 모두 확인해야 하기에 이런 부분은 자동화시키곤 합니다.
이 부분은 환경을 공개할 필요도 없고
jwebunit 같은 도구를 사용한다면 오유의 페이지를 열어보면서
자발적 참여자들이 재능기부로 완성해나갈 수 있을 듯 합니다.
2차적으로는 프로그램으로 커버되지 않는 부분이 있기에
사람이 투입되어 테스트 합니다.
오유의 경우에는 개발 환경으로 일부 인가된 사람들이 접근하여
기능을 테스트하면 어떨까 합니다.
이 부분은 기존 회원분들의 자발적 참여도 가능할 듯 합니다.
3차적으로는 혹시모를 악의적 코드 (백도어 등) 내지
보안 문제, 성능 문제 등의 검증을 위해 코드 인스펙션을 합니다.
소스 코드 자체를 눈으로 훑어서 문제가 될 코드가 있는지를 확인하는 방식입니다.
이 부분은 기존 회원분들 중 프로그램이 가능하신 분들의 자발적 참여와
운영자 면접 등을 통해 선발된 분들이 참여하시면 어떨까 합니다.
세줄 요약
-. SCV 를 쓰되 개발 환경에서만 작업하도록 함
-. 자발적 참여를 통해 개발 내역에 대한 테스트를 진행함
-. 선발된 전문가들이 개발 내역을 검증함
