지금까지 모든 것이 순조롭게 진행되고 있습니다.

글: 하산 사이드
ISIS 부국장

A-1 테크놀로지와 함께 진행하는 6주간의 파일럿 프로젝트가 반 정도 끝난 현재 모든 것이 순조롭게 진행되고 있습니다. 이 파일럿 프로젝트에서는 ISIS에서 제안한 ZIMS의 새로운 방법론과 ISIS와 새 벤더의 잠재적 작업 관계를 테스트합니다.

우리 팀은 현재 ZIMS의 기술 프레임워크를 제작하고 있습니다. 그리고 A-1팀에게 뛰어난 품질로 장기간 손쉽게 프로그램을 유지관리/업그레이드할 수 있는 ZIMS 페이지 코드 작성법을 구체적으로 전달하고 있습니다.

A-1은 아직 ZIMS 프로젝트를 함께 진행할 벤더로 선정되지는 않았음을 알려드리며 앞으로 새로운 소식이 있으면 업데이트하겠습니다.

폭포수 모델의 난해한 문제점 및 스크럼 마스터

글 제이미 마이어
ISIS 커뮤니케이션 전문가

일반인에게 소프트웨어 개발 방법을 설명하기란 결코 쉽지 않습니다. 소프트웨어 개발에는 소위 “코드”라 불리는 개발자들만의 비밀 언어가 사용되기 때문입니다. 그래도 이번에는 이러한 비밀 언어에 대해서 잠시 설명해보겠습니다.

소프트웨어 개발에 있어 폭포수 모델은 오래된 접근 법이라 할 수 있습니다. 일반적으로 폭포수 개발은 순서에 따라 모든 작업을 순차적으로 계획해 놓고 전체 어플리케이션을 개발하는 방식입니다. 따라서 일단 작업 시작되면 마치 폭포수가 떨어지는 것처럼 쉬거나 변경되는 일 없이 전체 어플리케이션 개발이 진행됩니다. 그래서 폭포수 모델은 일반적으로 상의하달식 경영 방식과 비교할 수 있습니다. 하지만 폭포수 모델은 난해한 문제, 즉 처음 계획 단계에는 예상하지 못했던 내부 모순적 문제로 인해 프로젝트 전체가 좌초될 수 있습니다. 소프트웨어 개발 과정에서 난해한 문제들이 발생할 가능성은 매우 높고 폭포수 방법에서 고객은 프로젝트가 최종 완료되고 나서야 소프트웨어가 작동하는 모습을 확인할 수 있습니다. 게다가 이 시점에는 이미 난해한 문제들이 치명적인 문제로 성장해서 되돌리기가 힘듭니다. (위 내용은 tucows.com에서 일부 발췌했습니다.)

ZIMS는 이러한 폭포수 방법의 문제점을 보완하고자 약 10년 전에 개발된 애자일 방법을 사용합니다. 폭포수 방법에서는 심도 깊은 사전 계획을 통해 난해한 문제점을 해결하려고 한다면 애자일 방법론에서는 아무리 철저하게 사전에 준비하더라도 작업 중에는 어쩔 수 없이 난해한 문제가 발생한다고 가정합니다. 따라서 애자일 방법에서는 개발자와 고객이 긴밀하게 공조하여 계획을 변경하고 우선 순위를 다시 정하는 등 유연하게 대처합니다. ISIS는 애자일 방법론 중에서도 스크럼 방식을 사용하고 있습니다. 스크럼은 선수들이 얼굴을 맞대고 전술을 대형을 짜는 럭비 경기에서 유래된 말입니다. 럭비 경기에서 스크럼은 몇몇의 선수들이 공을 중심으로 서로 어깨를 맞대고 밀고 당기면서 뭉친 진영을 가리키는 말입니다. 스크럼 방식에서는 단기간 집중적으로 작업해 눈으로 확인 가능한 성과물을 만들어냅니다. 그래서 마치 폭포수가 떨어지는 것처럼 전체 소프트웨어를 한 번에 릴리스하기 보다는 여러 단계로 나눠서 조금씩 릴리스하고 별도의 기능이 필요하면 이후 릴리스에 추가합니다. 전체 소프트웨어는 각 스크럼으로 나눠서 개발되고 매우 구체적인 고객의 요구 사항까지 반영하기 때문에 완전한 고객 승인을 얻을 수 있습니다. 이런 연유로 ZIMS도 여러 단계에 걸쳐 릴리스됩니다. (위 내용은 클레이그 머피의 “스크럼을 이용한 적응적 프로젝트 관리”에서 일부 발췌했습니다.)

스크럼 방식의 기본 요소 중 하나는 매일 수행하는 일일 스크럼 회의입니다. 우리는 중부 표준시 8:00 AM(뉴델리 시간 6:30 PM)에 일일 스크럼 회의를 갖습니다. 그리고 스크럼 방식의 다른 요소들과 마찬가지로 회의도 정확히 정해진 시간 안에서 이뤄집니다. 일일 스크럼 회의는 아래 세 가지 질문에 대해 모든 참석자가 가능한 간단하게 답하는 방식으로 진행되며 회의 시간은 15분을 넘지 않습니다.

어제 어떤 작업을 진행했나?
오늘은 어떤 작업을 진행할 예정인가?
오늘 작업 가운데 예상되는 문제점은 무엇인가?

스크럼 회의의 목표는 팀원들이 긴밀하게 공조하여 빠르게 작업을 진행하며 공동의 목표에 집중하도록 하는 것입니다. 스크럼 회의는 ISIS가 현재 진행하고 있는 집중 프로세스의 상징이라 할 수 있습니다. 이 프로세스가 제대로 작동하려면 스크럼 마스터라 불리는 강력한 지도자와 감독관이 필요한데 이번 프로젝트에서는 새로운 ZIMS 프로젝트 매니저, 앨빈 스미스가 이 역할을 담당하고 있습니다. 미네소타의 ISIS 사무실에서 근무하는 앨빈은 진행 속도가 빠르고 변경이 가능하며 유연하고 긴밀한 공조가 필요한 애자일 환경에서 공동 목표에 따라 모든 작업이 안정적으로 진행되도록 또한 팀원 중 누구 하나 길을 잃고 헤매지 않도록 관리 감독합니다.

ZIMS에서 가장 근사한 부분을 제작하는 ISIS 기술 팀

글 네이트 플레스니스
ISIS 상임이사

우리는 ZIMS 프로젝트에 애자일 개발이라는 새로운 방법을 선택했습니다.

이 새로운 프로세스에 따라 ISIS는 매일 진행되는 모든 작업을 직접 감독 관리할 것입니다. 보강된 ISIS 기술팀에서는 ZIMS의 “가장 근사한 부분”을 직접 제작하게 되어 책임이 커진 만큼 재미도 늘어났다고 할 수 있겠습니다. 새로운 벤더에서는 일반적인 소프트웨어보다 훨씬 수준 높은 코드를 작성해 달라는 ISIS의 요구에 따라 전체적인 사용자 인터페이스 기능 향상 등과 같이 기술적으로 좀더 포괄적인 부분을 담당할 예정입니다.

ISIS은 가히 최고 수준이라 평가할만한 개발팀을 보유하고 있어 새 벤더를 선정(아래 ZIMS 블로그 참조)하기 전에 이미 내부 팀에서 직접 ZIMS 프로젝트의 중요한 작업을 처리하기도 했습니다. 이들 주요 작업 중 하나는 데이터베이스의 단순화입니다. 이 작업을 구체적으로 설명하기는 힘들지만 원래 데이터베이스의 작동 방식은 지금보다 훨씬 복잡했습니다. 하지만 ISIS 개발팀과 컨설턴트는 기존 데이터베이스를 검토하고 평가한 후 그 복잡도를 반으로 줄였습니다.

이를 보면 왜 동물원과 수족관의 실제 작업 및 이들이 필요로 하는 사항을 잘 알고 있는 전문가가 ZIMS 개발에 참여해야 하는지 그 이유를 분명히 알 수 있습니다. ZIMS에서는 이들 커뮤니티의 영역별 전문가와 ISIS직원이 프로그래머 옆에서 함께 작업을 진행합니다. 그리고 이러한 접근법은 이번 개발 과정에서 이미 큰 차이를 만들어내고 있습니다.

인도에서 전합니다.

글 더그 베두즈코
ZIMS 수석 아키텍트

A-1과 함께 진행하는 파일럿 프로젝트의 6주 과정 중 벌써 한 주가 지났습니다. 이번 파일럿 프로젝트에서는 ISIS에서 제안한 ZIMS의 새로운 방법론과 ISIS와 새 벤더의 작업 관계를 테스트합니다. 우리 내부에서는 ISIS는 일반 고객과 성격이 다르고 ZIMS는 보기 드물 정도로 복잡한 프로젝트라는 사실에 익숙해져 있지만 외부인에게 ZIMS에 어떤 기능이 필요하고 지난 34년 간 ISIS에서 어떤 작업을 수행해 왔는지 설명하면 지금까지 이런 일은 본적이 없다며 깜짝 놀랍니다.

이번 주는 A-1팀에서 ISIS와 동물학, ZIMS 프로젝트, ISIS 팀이 구상한 ZIMS의 기술 아키텍처를 익히는 시간이었습니다. 네이트, 하산, 엘리자베스, 원레이, 크레이그, 리치, 김, 그리고 저까지 총 8명으로 구성된 ISIS 팀은 일주일 동안 오리엔테이션을 열어 A-1 팀에게 되도록 많은 정보를 전달했습니다. A-1팀은 훌륭한 질문을 많이 해주었고 이번 주는 매우 순조롭게 지나갔습니다.

앞으로 몇 주 동안은 A-1팀에서 ZIMS 화면을 직접 작성함으로써 이들이 시간과 노력이 많이 필요한 ZIMS 프로젝트를 수행할 역량을 갖췄는지 평가할 것입니다. 물론 A-1과의 업무가 잘 진행되길 바라지만 ISIS는 이번 작업 관계를 통해 우리의 요구 조건에 맞는지 신중하게 판단할 것입니다.

이번 주에 저희 8명은 미네소타에서 인도 구르가온으로 건너와 매우 바쁜 한 주를 보냈습니다. 실제 프로젝트가 시작하면 전 작업 기간에 걸쳐 ISIS에서 인도로 인력을 파견할 예정이라 이 부분도 이번 파일럿 프로젝트에서 확인해봐야 합니다. ISIS에서는 내부 개발자나 커뮤니티의 영역별 전문가들을 주로 파견할 것입니다. 그래서 앞으로 일년 동안 항공 마일리지가 엄청나게 쌓일 것 같습니다.

저희 팀은 가끔 업무로 인한 두통이나 위장병으로 시달리기도 했으나 이는 커뮤니티에서 원하는 수준의 ZIMS를 개발하기 위한 하나의 과정이 아닐까 싶습니다.