YUZI, in Ma Mind

지난 2008년 6월 18일 수요일 오후에 "SW공학 컨퍼런스 2008"에 다녀왔습니다.

SW프로세스 및 품질에 대한 4개의 세션과 1개의 초청강연으로 이루어 졌었는데, 전체적으로는 개괄적인 내용을 많이 담고 있던 관계로 지루한 면이 꽤 있었답니다...(꾸벅꾸벅 졸기를 수없이 반복했죠...)

하지만, 무료세미나 라는 것을 감안하면, 사례와 이론이 적절히 섞인 양질의 컨퍼런스였습니다.

다음은, 초청강연으로 발표된 권기식 오라클 본부장의 "Oracle Asia R&D 센터의 개발 process 및 QA"강연 내용을 정리한 것입니다.

 

1. OARDC(Oracle Asia R&D Center) 코리아 소개

웹을 찾아보니, 오라클 첨단기술 연구소로 되어 있네요. 영어 이름이 Oracle Asia R&D Center인가 봅니다.

  서울 여의도에 자리 잡은 한국오라클 첨단기술연구소(이하 연구소)는 임베디드 소프트웨어, 유비쿼터스 시티, RFID 등 한국이 세계 시장에서 두각을 나타내고 있는 세 가지 분야를 집중적으로 연구개발할 목적으로 오라클이 직접 투자해 설립했다. 연구소는 솔루션 현지화와 한글화 등 소극적인 업무를 뛰어 넘어 대학 등 교육기관과 정부기관, 협력업체 등과 유기적인 관계를 맺고 세계 시장에서 오라클의 표준으로 자리 잡을 진보된 솔루션을 개발하는데 역점을 두고 있다.

 오라클은 연구소 설립 목적이 바래지 않도록 앞서 중국, 일본, 인도, 싱가폴 등에 설립한 각 연구소와 한국에 소재한 연구소를 연계해 국내 IT 산업과 함께 더불어 성장할 곳으로 향후 연구소의 운영방향을 정했다. 이를 위해 다른 아태지역의 연구소와 마찬가지로 본연의 임무인 연구개발 뿐만 아니라 선진 기술 교육, 제품 개발, 현지 업체와의 협력 프로젝트, 솔루션 현지화 등 다양한 업무를 폭넓게 전개할 예정이다.

OARDC Korea는, 임베디드 소프트웨어를 중심으로 U-City, 유비쿼터스 컴퓨팅 연구 및 정부와 대학과의 협업을 하고 있으며, OARDC에는 총 700여명의 연구원들이 근무하고 있다고 합니다.



2. 개발 프로세스 (Development Process)

Oracle의 개발 프로세스는, 완전한 코드 생성 (Deliver high quality bug-free code)를 최종 목표로 하며,

SW개발운영상에 위험을 감소시키고 (Reduce Risk) 고객의 요구사항을 더 잘 이해하며 (Understand Requirements) 팀상호간의 목표 공유등의 커뮤니케이션을 개선 (Improve Communication)함과 동시에 추적 프로그레스 (Track Progress), 변경요구 관리(Manage Change Request)를 수행하도록 함을 추구한다고 합니다.

특정 개발 프로세스나 자신의 개발 프로세스 자체를 맹신하여 일을 그르쳤던 경험이 있었는지, 관련 이야기 및 "완전한 코드 (Bug-free code)"와 "솔루션(Solution)"이 목표지 프로세스는 목표가 될 수 없다는 이야기를 여러번에 걸쳐서 강조하더군요.

개발 프로세스의 접근 방식으로는, Waterfall 모델과 Agile 모델로 구분하여 설명하였는데요. (아래 표 참조)
사실, 전무정도 직위에 있는 분이 초청강연을 하길래 대규모 방법론의 클래식한 이야기만 하다가 갈 줄 알았는데요.
의외로 Agile 프로세스에 대한 이야기에 아주 많은 시간을 할애하며 설명을 했습니다. 신선해 보이더군요.

오라클에서는, Waterfall 모델은 대규모 프로젝트에 사용하고 있다고 합니다. (예를들면 DBMS같은 프로젝트들) 반면에, Agile 모델은 비교적 작은 규모의 프로젝트 또는 솔루션 개발에 사용하고 있다고 합니다.



2.1 Waterfall 모델

70~80년대에 개발된 접근법에 따라서 Waterfall모델을 구동하고 있다고 합니다. Oracle의 주요 제품 개발에는 모두 waterfall 방법론을 적용하고 있다고 합니다.
 위와 같은 waterfall 모델에 대해서 아래의 그림과 같은 역할(role)이 정의되어 있다고 합니다.

그림에서의 DE는 학계의 교수님들 등인것 같고요. FA는 Spec을 만드는 사람이고 SP는 보통 사업부서가 되는 것 같습니다. PM은 보통 FA의 역할을 병행하는 경우가 많고 외부와의 커뮤니케이션과 프로젝트의 스케줄링을 전담하는 사람으로 보이네요. DM은 그 외의 개발에 관련된 관리 문제를 해결하는 사람으로 생각됩니다.

Waterfall이라고 해서 무조건 1번의 Stream으로 프로젝트를 마무리 짓지는 않고, 1번의 Waterfall을 여러번 Iterate하면서 제품을 완성해 나가게 됩니다.

Waterfall 모델의 단점으로는, 고객의 새로운 요구사항이 즉각 방영되기 어렵다 (요구사항이 불분명 할 수 있음) 개발기간이 충분히 확보되지 못한다. (제품마다 개발기간이 다름 / 자료작성에 많은 시간 소요, 불필요한 자료 제작) 문제발생시 대처하기 어렵다 (각 단계별 대처요령이 다름) 는 것이 있답니다.



2.2 Agile 모델

Agile 방법론은, 특정 방법론을 지칭하는 것이아니라 Agile한 방법론 전체를 포괄하고 있는 단어로써, Oracle의 프로젝트에서도 사용하고 있다고 합니다.

고객의 요구사항에 민첩하게 대응할 수 있는 신속성과 내/외부 환경 변화에 대해 내용 및 일정 변경의 융통성이 있으나, 프로젝트의 Deadline이 명확하지 못하다는 문제점이 있습니다.

설명을 들어보니, 스크럼(Scrum)을 도입하여 사용하고 있으며, 자세한 내용은 여기서 설명하는 것보다, 기존의 스크럼 관련글[링크] 를 참조하시는게 좋겠네요. 특별히 중요한 얘기는 없었으니까요.

강사는 Agile 프로젝트의 성공 요건은 Self-Organizing team (자기조직화)에 있다고 보더군요. 공감합니다.

Oracle에서는 스크럼을 수행하기 위해서 Scrumworks[링크]라는 Tool을 사용중에 있다고 하는데요. basic버전은 무료 오픈소스 이지만, Pro버전은 상용입니다. Oracle에서도 basic을 사용하고 있다니, pro까지는 필요가 없나보네요. 몰랏던 tool을 알게 되었습니다. 매우 큰 수확이네요. ㅎㅎ



3. Quality Assurance Process

SW오류로 인해 막대한 손해를 입은 사례들에 대해서 언급된 뒤, Q/A의 중요성에 대해서 설파하는 일반적인 내용으로 시작하였습니다. 메모리 할당을 잘못하여, 발사된 위성이 추락한 경우 등에 대한 이야기들과, Code상의 Bug 점유율은 전체 대비 7%정도이고, 그것을 수정하는데 들어가는 노력은 전체대비 1%밖에 안된다. 는 설명들 말이죠.

그 뒤에, 정작 궁금했던 OARDC의 품질보증 프로세스의 내용들이 간단히 설명되었습니다.


(1) 요구사항 및 디자인 단계

이 단계에서는, 사전검증 시스템이 준비되어 있다고 하는데요.  준비되고 작성한 것들에 대하여 자세한 review를 거친다고 합니다. 일반적으로 다른 그룹에 속한 사람들이 10~20번정도 리뷰를 해 준다고 하네요.


(2) 개발 프로세스

OCCS (Oracle C/Java/Python Coding Standard)라고 하는 코딩 표준이 있으며, Olint(Oracle Lint)로 Code를 검증한다고 합니다. Olint를 통한 검증이 실패할 경우, Code는 돌려보내진다고 하네요. (참조: 상용이 아닌 Lint 유틸리티로는 Splint와 Clint가 있습니다.)

상세한 코딩 규정 외에, SCS(Secure Coding Standard)라는 것이 있다고 하는데요. 이것은 "제품보안에 위협이 되는 요소를 미연에 방지학 위한 코딩 룰"이라고 합니다. 모든 개발자들은 반드시 SCS교육을 이수하여야 한다고 합니다. (저는 뭔지 잘 모르겠네요.)


(3) 품질보증 프로세스

개발자들은 ADE(Advanced Development Environment)를 통해 개발을 진행합니다. ADE는 CVS 기능이 확장된 시스템으로써, 소스코드를 관리하는 시스템입니다. 이외에, 테스팅에 관련하여서는 일반적인 내용과 같아 보입니다.



3.1 ADE (Advanced Development Environment)

설명에서 특이한 점은, 개발(또는 수정)을 시작하기 전에 ADE에 접속해서 소스코드를 받아오는 것이었습니다. 실제로는 그렇게 진행되기가 힘들거든요. 어제 작업한 소스를 그대로 두고 내일 와서 작업하는게 일반적일 텐데요. 여기에서는 퇴근할때 넣어주고 출근해서 빼내어 쓰는식으로 작업을 하나 봅니다.


3.2 OADRC QA Process

여기 설명에서 특이한 점은, Tester들이 ADE에 접근할 수 없다는 것이었습니다. ADE는 개발자만 접근하는 것 으로써, 다른 부서 사람들은 소스코드에 접근할 수 없다는 의미가 됩니다. 철저한 보안 정책에 의한 것으로 보이는데요. 이렇게 되면 Tester들은 White Box 테스팅에 관여할 수 없고, 개발팀이 단위테스트나 White Box테스팅등에 능숙해야 겠습니다.


여기까지가, SW공학 컨퍼런스 초대강연의 전체 내용이었습니다. SW공학 컨퍼런스 같은, 불특정 다수를 상대로 하는 비교적 큰규모의 강연에서 들었던 사례발표중에는 가장 쓸만했던 것 같습니다. 자사 제품 홍보도 없었고요. 아래는, 초대강사입니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.