개발 프로세스 탐험

최근 오마이트립 기술조직은 올바른 소프트웨어를 만들고 안전하고 효율적으로 배포하기 위해 기존의 낡은 개발 방식을 벗어나 우리에게 적합한 개발 프로세스를 정착시키려 다양한 노력을 하고 있습니다. 얼마 전 여름 여행 성수기에 영업조직을 도와줄 작은 기능에 대한 요구가 발생했고 우리는 이 작업에서도 그동안 오마이트립이 경험하지 못한 몇 가지 새로운 방법을 시도했습니다.

분석

프로젝트를 시작하기 전 프로젝트의 범위와 비용, 그리고 진행 여부를 판단하기 위해 관련된 영업조직과 기술조직 인원들이 모여 몇 차례 회의를 했습니다. 우리는 길고 지루하고 개별적으로 수행되는 문서 작업 대신 얼마 전 구입한 이동식 거치대와 화이트보드를 적극적으로 활용했습니다. 한 자리에 모여 아이디어와 고려사항을 보드마커로 즉석에서 표현했습니다.

화이트보드 미팅 1

화이트보드 미팅 2

화이트보드에 표현된 것들은 간단히 휴대전화 카메라로 촬영해 Visual Studio Team Services 작업 항목에 첨부했습니다.

물론 이 내용들이 완벽한 것은 아니었기 때문에 프로젝트를 진행하면서 누락되었거나 서로 이해가 일치하지 않은 이슈가 몇 개 발견되기도 했습니다. 하지만 영업 담당자, 프로그래머, 디자이너 등 관련된 인원들이 함께 도출한 가시적인 정보에 쉽게 접근할 수 있다는 것은 작업 수행에 큰 도움이 되었습니다.

논의를 통해 업무상 필수적이지 않는 작업들은 모두 배제하기로 합의했고 요구사항은 매우 단순했습니다. 시간은 2주(작업일로 10일)를 사용하기로 했습니다. 하지만 여전히 위험요소들은 존재했습니다.

  • 기술조직은 이미 잉여자원이 없었지만 여름 여행 성수기가 목적인 기능을 너무 늦지 않게 배포해야 했습니다. 쥐어짜낸 2주간 가용한 예상 인력 자원은 0.7 * 2명이 고작이었습니다. 하지만 실제로는 그 절반에 가까운 수준으로 훨씬 적었습니다. 불가능한 임무는 아니지만 행여나 잘못된 길로 빠지지 않도록 잘 관리해야 했습니다.

  • 높은 기술 부채(technical debt)를 가진 두 개의 기존 시스템을 다뤄야 했습니다. 그 중 하나는 변경이 불가피한 Python으로 개발된 응용프로그램이었고 작업을 할당받은 2명의 작업자는 Python 경험이 없었습니다. 기존 시스템은 배포 자동화 수준이 매우 낮고 이것을 짧은 기간에 높일 수 있는 상황도 아닙니다.

프로젝트 관리

오마이트립 기술조직은 얼마 전 VSTS(Visual Studio Team Services)를 도입했습니다. VSTS는 소프트웨어 개발에 필요한 다양한 도구를 통합 제공하는 서비스입니다. 이번 프로젝트 역시 작업 관리부터 배포와 테스팅까지 모든 과정에 VSTS를 적극적으로 활용했습니다.

작업 항목 쿼리

가장 먼저, 분석 단계에서 도출된 작업과 이슈들을 작업 항목으로 등록했습니다. 모든 작업 항목에는 프로젝트를 나타내는 태그를 달았고 이 태그를 기반으로 몇 가지 유용한 작업 항목 쿼리를 만들었습니다.

  • 전체 작업 항목 쿼리
  • 완료되지 않은 작업 항목 쿼리
  • 완료되지 않은 Backlog 쿼리
  • 완료되지 않은 Bug 쿼리
  • 완료되지 않은 User Story 쿼리

VSTS 작업 항목 쿼리는 이 문서를 참고하세요.

대시보드

작성된 쿼리들을 이용해 대시보드를 만들었습니다. 이후 빌드를 작성하고 승인 테스트 케이스를 추가하며 대시보드를 강화했습니다.

프로젝트 대시보드

대시보드는 그동안의 프로젝트 추이와 현재 상황을 한눈에 효과적으로 볼 수 있도록 꾸몄습니다. 예를 들어 위 그림의 경우 작업일 10일 중 2.x일을 남긴 상황이고 총 16개의 작업 항목 중 10개가 완료되었다는 것을 보여줍니다. 승인 테스트가 아직 전혀 실행되지 않은 상태까지 고려하면 프로젝트 진행이 위험하다는 신호로 해석할 수 있습니다. 이후 담당 인원들은 프로젝트에 좀 더 많은 자원을 할애했습니다.

아키텍팅

작업 항목을 도출하고 대시보드를 만든 후 아키텍팅을 했습니다. 간단한 기능이지만 기존 서비스와 연동되는 신규 서비스를 추가하는 과정에 오해가 발생하지 않도록 아키텍팅 과정이 필요했고 분석 작업과 마찬가지로 담당 프로그래머들이 모여 화이트보드를 이용해 진행했습니다.

아키텍팅 1

아키텍팅 2

아키텍팅을 통해 새 서비스가 제공해야 할 API는 어떤 것들이 있는지, 데이터베이스는 어떤 것을 선택하는 것이 좋을지, 기존 서비스를 변경하지 않기 위해 변질방지 계층(Anti-Corruption Layer)은 어디에 배치할지 등을 결정했습니다.

오마이트립 기술조직은 변화와 성장을 함께할 인재를 찾고 있습니다. 관심 있는 분들은 채용 페이지에 방문하세요.

지속 배포(Continuous Deployment)

우리는 프로젝트 막바지에 신규 서비스를 위한 인프라를 구축하고 코드를 배포하고 기능이 잘 동작하는지 급히 확인하기 위해 허둥대고 싶지 않았습니다. 이 모든 것들이 개발 과정에 자연스럽게 녹아들기를 바랬습니다. 그래서 아키텍팅 직후 본격적인 개발 작업을 시작하기 앞서 자동화된 배포 파이프라인을 구축했습니다.

지속 배포에 사용된 도구는 다음과 같습니다.

Azure 리소스 그룹 템플릿

신규 서비스는 Microsoft Azure에 호스팅 하기로 결정했습니다. 아키텍팅으로 도출된 API 응용프로그램, 데이터베이스 인스턴스, 모니터링 도구 등의 구성요소들을 생성하고 연결하는 작업을 자동화 하기 위해 Azure 리소스 그룹 템플릿을 작성했습니다. 이것은 인프라 구축과 변경이 모두 코드로 관리됨을 의미합니다.

신규 데이터베이스에는 Entity Framework Code First를 사용하기로 결정했기 때문에 배포 프로세스에서 스키마 관리 자동화를 위해 별도로 필요한 작업은 없습니다.

VSTS Build

신규 서비스의 코드는 VSTS Git 저장소에 보관되고 master 브랜치에 새 커밋이 추가될 때 마다 VSTS Build가 시작됩니다. Build는 다음 주요 작업을 순차적으로 실행합니다.

  1. 소스코드 컴파일
  2. 단위 테스팅
  3. 개발 리소스 그룹에 Azure 리소스 그룹 템플릿 배포
  4. 개발 리소스 그룹 응용프로그램 바이너리 배포
  5. 빌드 결과물 게시

VSTS Build

바이너리 배포 후 기능 테스팅을 실행하는 것이 좋지만 이번 프로젝트는 기능 테스트 케이스를 작성하지 않았습니다.

VSTS Release

빌드가 성공적으로 완료되면 게시된 빌드 결과물을 대상으로 VSTS Release가 시작됩니다. Release는 Production 하나의 환경으로 구성되고 이 환경은 다음 작업을 순차적으로 실행합니다.

  1. 운영 리소스 그룹에 Azure 리소스 그룹 템플릿 배포
  2. 운영 리소스 그룹 응용프로그램 바이너리 배포

개발 환경에 배포하는 Build와는 달리 Release 과정에 사용되는 데이터베이스 계정 등은 노출되지 않아야 합니다. 따라서 Release는 Variable Group을 사용해 민감한 정보를 숨겼습니다.

VSTS Release

Release 환경은 StagingProduction으로 구성해 Blue-Green Deployment를 적용하고 각 환경마다 기능 테스팅을 실행하는 것이 좋지만 이번 프로젝트는 적용하지 않았습니다.

VSTS는 Variable Group에 한 번 숨겨진 정보를 어떠한 경우에도 다시 노출시키지 않습니다. 보안 수준을 더 높이기 위해 Azure Key Vault 사용을 검토하고 있습니다.

개발

신규 서비스 개발은 TDD(Test-Driven Development)로 진행했습니다. 기존 시스템 데이터베이스에 접근해야 하는 시나리오의 경우 통합 테스트 케이스를 작성했고 그렇지 않은 경우는 단위 테스트 케이스를 작성했습니다.

기존 웹 응용프로그램을 변경하는 작업은 TDD를 적용할 수 없었습니다. 이유는 다음과 같습니다.

  • 기존 응용프로그램은 Python으로 작성되어 있지만 프로젝트 담당 프로그래머는 모두 Python 경험이 없었기 때문에 TDD는 무리가 있었습니다.
  • 기존 응용프로그램은 테스트하기 어렵게 설계되었습니다.

그래서 이 부분은 ATDD(Acceptance Test-Driven Development)로 진행했습니다. 프로젝트 초기에 미리 작성된 수동 승인 테스트 케이스를 하나씩 성공시키는 방식으로 코딩 했습니다.

전체 개발 과정의 90% 정도가 짝 프로그래밍으로 진행되었습니다. 분석과 아키텍팅을 함께 했음에도 불구하고 한 두가지 오해가 있었는데 짝 프로그래밍을 하면서 자연스럽게 드러났습니다. 이로 인해 신규 서비스 프로젝트에 이미 작성된 코드 일부를 수정해야 하는 상황이 발생했고 수정된 코드의 정상적인 동작은 그동안 작성했던 테스트 케이스들이 검증했습니다. 실제로 테스트 케이스가 소프트웨어 회귀(Software Regression) 하나를 발견해 버그를 이른 시점에 고칠 수 있었습니다.

기존 시스템 배포

앞서 언급했 듯 기존 시스템은 배포 과정의 많은 작업이 수동으로 이뤄집니다. 빡빡한 프로젝트 일정에 이것을 손 볼 여유는 없었습니다. 불행하게도 수동 배포에 대한 가이드 문서도 존재하지 않아 배포 과정에 실수가 있었고 웹 프론트엔드 응용프로그램 장애로 이어졌습니다. 장애는 곧바로 발견되어 업무용 메신저를 통해 회사 전체에 공지되었고 코드는 롤백되었습니다. 다행이 어렵지 않게 문제점을 발견해 곧 재배포에 성공했습니다. 이후 수동 배포 가이드와 이번 장애 사례를 위키에 작성했습니다.

테스트

예정대로 마지막 작업일에 요구사항을 발생시킨 영업조직의 승인 테스트가 진행되었습니다. 승인 테스트 케이스 계획은 프로젝트 초기부터 관리되었고 ATDD에 사용되기도 했습니다. 업무적으로는 간단한 기능이라 수동으로 진행하는 승인 테스트 케이스가 많지는 않았습니다. 신규 시스템이 기존 시스템과 연동되며 검증해야 할 것들이 많았지만 이것들은 이미 자동화된 테스트 케이스를 통해 지속적으로 테스트 되었습니다.

VSTS Test Plans

승인 테스트 계획을 영업조직에 전달했고 VSTS Test Runner를 통해 테스트가 진행되었습니다. VSTS Test Runner는 최종 확인자가 계획된 시나리오를 따라 테스트를 진행하고 구체적인 피드백을 남길 수 있도록 도와줍니다. 테스트 실행자는 필요에 따라 개발자에게 전달하기 위해 메시지를 적고 화면을 촬영하고 동영상을 녹화할 수 있습니다. 테스트 실행의 모든 결과물은 휘발되지 않고 고스란히 기록됩니다.

VSTS Test Runner

테스트가 진행되는 동안 프로그래머는 대시보드 등을 통해 상황을 모니터할 수 있습니다. 다음 그림의 오른쪽 아래 위젯은 6개 테스트 중 1개가 통과했고 5개가 진행중 임을 보여줍니다.

테스트 실행 모니터

계획된 시간을 조금 남기고 프로젝트의 최종단계인 승인 테스트를 완료했습니다. 그동안 개발 과정에서 지속적으로 다양한 테스팅이 진행된 덕에 승인 테스트를 성공적으로 마무리했습니다.

정리

이번 프로젝트에서 사용된 개발 프로세스의 특징을 나열하면 다음과 같습니다.

  • 화이트보드와 VSTS를 사용한 프로젝트 전반에 걸친 협업
  • 지속 배포 파이프라인 초기 구축
  • 짝 프로그래밍
  • TDD(63개 테스트 케이스)
  • ATDD(6개 테스트 케이스)

사실 이 프로젝트는 오마이트립 기술조직이 진행하고 있거나 앞으로 진행해야 할 작업들에 비하면 아주 작은 일부입니다. 결코 이 프로젝트의 모습이 현재 오마이트립 기술조직의 모습이라 말할 수는 없습니다. 앞으로 개선해야 할 프로세스와 탕감해야 할 기술 부채, 구축해야 할 시스템이 많습니다.

하지만 우리는 기술조직 혁신을 막 시작했을 뿐입니다. 이번 프로젝트는 오마이트립에 적합한 수준 높은 개발 프로세스를 찾기 위한 탐험의 첫 단계입니다.

오마이트립 기술조직은 변화와 성장을 함께할 인재를 찾고 있습니다. 관심 있는 분들은 채용 페이지에 방문하세요.