기고 | SW 출시 의사결정을 신속하게 ‘3가지 방법’

나는 웃었다. 비록 마이크로소프트에 몇 개월만 있었지만, 그 어느 누구 하나 나의 tkdid(spec)을 승인하는 사람이 없다는 것을 알았다. 내 사양을 읽을 시간을 가진 이도 없었다. 프로그래머들은 더 많은 코드를 작성하기 위해 나에게 매일같이 더 많은 페이지를 찾아오라고 다그쳤다.- 조엘 스폴스키

마이크로소프트의 프로그래머 관리자로 근무했던 스폴스키가 경험한 이 이야기는 권한 이양 이상의 것을 시사하고 있다. 이것은 또한 조건의 유동성에 관한 이야기이기도 하다. 정확한 기능 세트는 시간이 지나면서 바뀔 수 있다. 애자일 매니페스토(Agile Manifesto)는 이런 가치를 반영하면서 "계획에 따르면서 변화에 대응하기"와 "포괄적인 문서에 적용 가능한 작업 소프트웨어"를 강조하고 있다.

이 아이디어를 어디에나 적용할 수 있는 것은 아니다. 많은 의료 및 물리적 장비 기업들에게 제품을 설치할 기회는 단 한 번이다. 그들에게 있어서 사양은 늘 언제나 그 과정의 중요한 일부분이다. 하지만 제공되는 소프트웨어가 증가하면서 공식적으로 승인된 포괄적인 조건문서의 아이디어가 다 낡은 이전 세기의 유물로 비쳐질 수 있다.

오늘날, 조건(requirements)은 종종 유동적이며 승인 결정(sifnoff decision)은 추억이 되어 버렸다. 유동적인 소프트웨어의 다음 단계는 출시/미출시 "승인 과정"을 없애는 것이다. 그리고 지금 이런 일이 벌어지고 있으며, 종종 연속 배치, 팀원들의 동의, 실질적인 감시자 역할을 하는 테스터 등 3가지 중 하나의 방법으로 이루어지고 있다.

1. 연속 배치: 각각의 책임에 따라 코드를 생산한다
애자일(Agile)은 공개 일정을 수 개월에서 수 주로 단축시킬 수 있다. 연속 배치(Continuous deployment)는 "모든 커밋을 이용해 생산을 시작한다면 시간이 얼마나 걸릴까?"라는 질문을 통해 그 기간을 단축시킨다. 플리커(Flickr), 트위터(Twitter), 인뷰(invu), 에스티(Esty) 등의 기업들이 실제로 이런 방법을 사용하고 있다.

연속 배치로의 이행은 단순히 구축시스템을 연결하고 서버의 재부팅 없이 업그레이드하는 방법을 찾는 것 이상을 의미한다. 이는 기술팀이 모든 커밋(Commit)마다 생산이 거의 준비된 코드를 갖고 있어야 함을 의미한다.

지난 해 필자는 브룩클린을 방문하여 에치(Etsy)의 연속 배치에 관해 배웠으며, 그 핵심에 대해 놀랐다.

- 대부분의 코드는 "다크(Dark)" 상태로 공개하고 (미실행) 시간이 지나면서 환경설정 플랙(Flag)을 사용할 때 활성화한다.

- 기업은 문제를 신속히 감지하기 위해 모니터링 및 브랜칭(Branching) 인프라에 크게 투자한다.

- 이 툴 그룹의 상당 부분이 개발자로 구성되어 있으며 신속하게 감지, 수정, 픽스(Fix) 공개를 할 수 있는 상당한 인프라를 보유하고 있다.

- 에치가 PCI 컴플레인트(PCI Complaint)이기 때문에, 코드가 관련된 신용카드, 돈, 고객 데이터 등이 더욱 공식적인 과정을 통과하고 된다.

랙스페이스(Rackspace)의 테스터 티모시 웨스턴은 "다크" 기능의 배치와 관련, 해당 기능의 실제 타이밍 때문에 해당 기능을 언제 활성 할지에 대해 다른 결정을 내리며 그 결과 또는 작동 방식에 대해 지속적으로 논의하는 것을 뜻한다고 말했다.

예를 들어, 팀은 다른 데이터베이스로 이동하며 해당 데이터베이스에 작성만 할 뿐 읽지 않는 코드를 배치하면서 동시에 기존의 코드를 유지할 수 있다. 이를 통해 해당 기업은 운영에 지장을 입지 않으면서 더 낮은 위험부담을 안고 테스트를 진행할 수 있다.

이를 담당하는 엔지니어들은 ‘문지기로서의 테스터’ 대신, 모든 커밋마다 코드를 생산하게 하고자 한다. 이를 위해서는 인프라에 대한 상당한 투자와 함께 원칙을 필요로 한다. 많은 팀들이 실제로 원치 않거나 이행할 수 없는 수준의 원칙이다. 이 때문에 문지기로서의 역할을 하는 테스터들에게 되돌아갈 수 밖에 없지만 테스트 커뮤니티 또한 이런 접근방식을 거부하게 된다.

2. 문지기가 아닌 테스터로서의 소프트웨어 테스터
브렛 페티코드(Bret Pettichord)의 2007 소프트웨어 시험 학교(Schools Of Software Testing)에서는 테스터를 여러 집단으로 나누는 것에 관해 이야기하고 있다. 페티코드에 따르면 "품질"(quality) 학교는, 시험을 마치 제조사가 대규모 점검을 바라보는 시각으로 바라본다고 한다. 너무 비용이 많이 들고 너무 늦은 것이다. 품질학교는 품질관리 대신에 검토와 점검에 치중하여 "요건을 충족시키고", "품질 과정"을 이행하여 우수한 소프트웨어가 제공되도록 하기 위해서다. (참고로 페티코드는 "맥락 주도형"( context-driven) 학교에 집중하고 있다. 이는 테스트를 가치 있으면서도 필수적인 것으로 보는 관점이다.)