(2013년 11월 초판과 동일한 내용의 도서입니다.)
이 책은 소프트웨어의 고객 인도과정에서 발생하는 여러 어려움을 효과적으로 다루기 위한 기술과 사례를 설명한다. 빌드, 기능/성능 테스트, 배포, 출시의 전체 단계를 자동화하는 기술과 소프트웨어 개발에 참여하는 개발자, 기획자, QA, 운영자가 효과적으로 협업할 수 있는 방법을 구체적으로 다룬다. 또한 최적화된 개발 및 배포 프로세스도 소개하므로 독자는 이를 활용해 조직 상황에 적합한 프로세스를 디자인하고 적용한 뒤 발전시켜 나갈 수 있다. 개발자, QA, 운영자, 관리자 모두 반드시 읽고, 익히고, 실천해야 할 필독서다.

■ 소프트웨어 빌드, 통합, 테스트, 배포의 전면 자동화
■ 팀과 조직 단계에서의 배포 파이프라인 구현
■ 개발자, 테스터, 운영자 간의 협업 개선
■ 효과적인 설정 관리 전략 구현
■ 분석부터 구현까지 인수 테스트 자동화
■ 용량과 기타 비기능 요구사항 테스트
■ 지속적 배포와 무정지 출시 구현
■ 인프라, 데이터, 컴포넌트, 의존성 관리
■ 위험 관리, 순응, 감사 다루기

이 책의 주요 목적 중 하나는 소프트웨어 배포의 책임을 갖는 관련자들의 협업을 개선하는 데 있다. 특히 개발자, 테스터, 시스템과 데이터베이스 관리자, 관리자를 염두에 두었다.

전통적인 설정 관리 문제, 소스 코드 관리, 출시 계획, 검수, 규정 준수에서 빌드 자동화, 테스트, 배포 프로세스의 통합까지를 주제로 다룬다. 자동화 인수 테스트, 의존성 관리, 데이터베이스 마이그레이션, 테스트와 실환경 생성과 관리 기술 또한 다룬다.

소프트웨어 개발에 참여하는 많은 사람이 이런 활동을 코드 작성보다 덜 중요하다고 생각한다. 하지만 경험에 따르면 이 작업에 많은 시간과 노력을 들이는 것이 성공적인 소프트웨어 인도의 핵심이다. 이를 둘러싼 위험을 제대로 관리하지 않으면 수많은 비용이 들고, 첫 번째 소프트웨어 구축 때보다 비용이 더 커지는 경우도 많다. 이 책은 이런 위험을 이해하는 데 필요한 정보를 제공하며, 나아가 이를 완화하는 전략을 설명한다.

야심 찬 목표이긴 하나, 한 권의 책에서 모든 주제를 상세히 다룰 수는 없다. 실제로 다음과 같은 독자들이 섭섭해할 수도 있다는 위험을 감수했다. 개발자는 아키텍처와 속성 주도 개발 방법, 상세한 리팩토링 같은 주제를 다루지 않아 서운할 수 있고, 테스터는 탐색적 테스트와 테스트 관리 전략에 충분한 지면을 할애하지 않아서, 운영자는 용량 계획, 데이터베이스 마이그레이션, 실환경 모니터링을 상세히 다루지 않아서 그런 감정이 들 수 있다.

이런 내용을 각각 상세하게 다루는 책은 시중에 나와 있다. 하지만 설정 관리, 자동화 테스트, 지속적 통합과 인도, 데이터 관리, 환경 관리, 출시 관리 같은 모든 활동을 함께 다루는 책이 없었다. 린(lean) 소프트웨어 개발 방법론에서 가르치는 중요한 주제 중 하나는 전체를 최적화하는 것이다. 이렇게 하려면 배포 프로세스와 그에 포함되는 모든 것을 하나로 묶어내는 전체론적인 접근법이 필요하다. 출시에 포함될 모든 변경 내용의 진행을 관리할 수 있어야만 소프트웨어 배포의 품질과 속도를 최적화하고 개선할 수 있다.

모든 사람이 이 책을 처음부터 끝까지 읽고 싶지는 않을 것이다. 도입부를 읽고 난 뒤 여러 가지 방법으로 공략할 수 있다. 반복적으로 읽는 것도 방법이겠지만, 처음부터 끝까지 읽기로 결심한 독자에게 너무 지루하지 않았으면 하는 바람이다.
이 책은 3개 부로 구성된다. 1부는 1장에서 4장까지로, 출시에 대한 일반적, 반복적, 위험 감소 이론을 다루며 이를 지원하는 실천법을 소개한다. 2부는 5장에서 10장까지로, 배포 파이프라인을 설명한다. 3부가 시작되는 11장부터는 지속적 인도를 지원하는 생태계를 다룬다.
누구든 1장은 읽기를 권한다. 경험 있는 개발자라도 소프트웨어 출시 프로세스가 생소한 경우라면 전문 소프트웨어 개발이 의미하는 바에 대한 다양한 도전과제를 발견할 수 있다. 책의 나머지 부분은 여유가 있거나 혼란스러운 상황일 때 자세히 살펴보면 된다.

1부: 기초
1부는 배포 파이프라인을 이해하는 데 필요한 선행지식을 설명한다. 각 장은 마지막 내용에 기반을 두고 있다.

1장 ‘소프트웨어 인도의 문제점’: 여러 개발 팀에서 공통적으로 관찰되는 안티패턴을 설명하는 것으로 시작해, 목표를 달성하는 방법을 설명하는 부분으로 나아간다. 그리고 이 책의 나머지 부분에서 다루는 소프트웨어 인도의 이론을 정립하면서 마무리한다.

2장 ‘설정 관리’: 소스 코드부터 환경과 애플리케이션 설정 빌드 스크립트에 이르기까지 빌드, 배포, 테스트, 애플리케이션 출시를 관리하는 모든 설정법을 다룬다.

3장 ‘지속적 통합’: 애플리케이션의 모든 변경에 대해 자동화 테스트를 구축하고 수행해 소프트웨어가 언제나 동작하는 상태로 유지되게 하는 실천법을 다룬다.

4장 ‘테스트 전략의 적용’: 모든 프로젝트의 중요 부분인 다양한 종류의 수동 테스트와 자동화 테스트 방법을 소개하고, 각자의 프로젝트에 적합한 전략을 선택하는 방법을 설명한다.

2부: 배포 파이프라인
2부에서는 파이프라인의 각 단계를 구현하는 방법을 포함해 배포 파이프라인을 자세히 다룬다.

5장 ‘배포 파이프라인의 구조’: 이 책의 핵심이라 할 수 있는, 출시에 체크인되는 모든 변경을 관리하는 자동화 프로세스 패턴을 다룬다. 그리고 팀과 조직 수준에서 파이프라인을 적용하는 방법도 설명한다.

6장 ‘빌드와 배포 스크립트 작성’: 자동 빌드와 배포 프로세스에 사용하는 스크립트 기술을 다루며, 이에 최적화된 실천법을 설명한다.

7장, 커밋 단계: 파이프라인의 첫 번째 단계로서 모든 변경사항이 애플리케이션에 적용되면서 수행되는 일련의 자동화 프로세스에 대해 다룬다.

8장 ‘자동화 인수 테스트’: 자동화 인수 테스트에 대한 분석부터 설명한다. 지속적 인도에서 인수 테스트가 중요한 이유를 설명하고, 애플리케이션의 중요 기능을 보호하는 비용 효과적인 인수 테스트 스위트를 만드는 법을 다룬다.

9장 ‘비기능 요구사항 테스트’: 용량 테스트 중심으로 비기능 요구사항을 다룬다. 용량 테스트를 생성하는 방법과 용량 테스트 환경을 구축하는 방법을 설명한다.

10장 ‘애플리케이션 배포와 출시’: 자동화 테스트 이후에 어떤 일이 발생하는지를 다룬다. 출시 후보를 버튼을 눌러 수동 테스트 환경, UAT, 스테이징, 최종 출시 단계로 진출시키는 데 필요한 핵심 주제인 지속적 배포, 롤백, 멈춤 없는 출시에 대해 다룬다.

3부: 제품 인도 생태계
3부에서는 배포 파이프라인을 지원하는 여러 분야를 교차하는 실천법과 기법을 설명한다.

11장, 인프라와 환경 관리: 가상화와 클라우드 컴퓨팅을 포함해 환경의 생성, 관리, 모니터링을 다룬다.

12장 ‘데이터 관리’: 테스트와 실제 데이터를 애플리케이션의 생명주기에 따라 생성하고 변경하는 방법을 보여준다.

13장 ‘컴포넌트와 의존성 관리’: 브랜치를 만들지 않고도 애플리케이션을 항상 출시 가능한 상태로 유지하는 방법을 설명하면서 시작한다. 그 다음, 컴포넌트 집합으로 애플리케이션을 구성하는 법과, 이들의 구축과 테스트를 관리하는 방법을 설명한다.

14장 ‘고급 버전 관리’: 유명한 도구들을 소개하고, 버전 관리를 사용하는 다양한 패턴을 상세하게 설명한다.

15장 ‘지속적 제품 인도 관리’: 위험 관리와 규정에 대한 접근법을 설명하고 설정과 출시 관리의 성숙도 모델을 제공한다. 이와 함께 비즈니스에서 지속적인 인도의 중요성과 점진적으로 인도하는 반복적인 프로젝트의 생명주기를 설명한다.

좀 더 자주 소프트웨어를 배포하고 싶다면 이 책은 당신을 위한 것입니다. 지속적 제품 인도를 적용함으로써 위험을 감소하고 지겨운 작업을 제거하고 신뢰감을 향상시킬 수 있습니다. 저는 현재 진행 중인 모든 프로젝트에 이 이론과 실천법을 적용하고 있습니다.
- 켄트 벡(Kent Beck) / 쓰리 리버스 인스티튜트(Three Rivers Institute)

소프트웨어 개발 팀에 소스 코드 관리가 필수적인 것처럼 지속적 통합의 이해 여부와 상관없이 이 책은 필독서입니다. 전체 개발과 배포 프로세스를 한 번에 다루는 유일한 책이며, 기술과 도구뿐만 아니라 철학과 이론을 제공합니다. 저자는 테스트 자동화에서 자동화 배포에 이르기까지 폭넓은 독자를 위한 주제를 다룹니다. 개발 팀에 속한 프로그래머, 테스터, 시스템 관리자, DBA, 관리자 모두가 이 책을 읽어야 합니다.
- 리사 크리스핀(Lisa Crispin) / 『Agile Testing』 공저자

많은 조직에서 지속적 인도는 단순한 배포 방법론이 아니며, 비즈니스를 수행하는 데 필수적인 요소입니다. 여러분의 환경에서 실제로 효과적인 지속적 인도를 구축하는 방법을 책에 소개했습니다.
- 제임스 턴불(James Turnbull) / 『Pulling Strings with Puppet』 저자

명확하고, 정확하게 잘 작성된 책으로 출시 프로세스에 무엇이 필요한지에 대한 아이디어를 독자에게 제공해줍니다. 저자는 소프트웨어 배포의 단계별 기대치와 장애물을 설명합니다. 모든 소프트웨어 엔지니어의 서재에 꼭 꽂혀 있어야 할 책입니다.
- 레이나 코트란(Leyna Cotran) / 캘리포니아 대학교 어바인 캠퍼스 소프트웨어 연구소

무엇이 빠르게 성장하는 웹 애플리케이션을 성공적으로 만드는지를 설명하고 있는 책입니다. 지속적 배포와 제품 인도는 논란거리를 벗어나 필수 요소가 됐으며, 이 책은 그 내용을 훌륭하게 다룹니다. 지속적 배포는 여러 수준에서 개발과 운영의 접점에 있으며, 저자들은 이를 성공적으로 다뤘습니다.
- 존 올스포(John Allspaw) / 잇시닷컴(Etsy.com)의 기술 운영 부사장이자, 『The Art of Capacity Planning』과 『Web Operations』 저자

소프트웨어 기반의 서비스를 구축하고 인도하는 비즈니스를 운영 중이라면 지속적 인도에서 명료하게 설명하는 핵심을 경험할 수 있습니다. 험블과 팔리는 이론을 넘어 제품 인도를 빠르고 신뢰할 수 있도록 변화시킬 멋진 각본을 제공합니다.
- 데이먼 에드워즈(Damon Edwards) / DTO 솔루션 대표이자, dev2ops.org 공동 편집자

소프트웨어 배포와 관련된 업무를 하는 사람이라면 누구나 이 책을 집어들어 아무 장이나 펼쳐 빠르게 가치 있는 정보를 얻을 수 있고, 책을 차근차근 읽어가며 조직에 적합한 배포 프로세스를 구축할 수 있으리라 믿습니다. 이 책은 소프트웨어의 구축, 배포, 테스트, 출시에 꼭 필요한 참고서라고 생각합니다.
- 사라 에드리(Sarah Edrie) / 하버드 비즈니스 스쿨의 품질 공학 관리자

지속적 인도는 최신의 모든 소프트웨어 팀에게 지속적 통합의 논리적 다음 단계입니다. 이 책의 야심 찬 목표는 고객에게 지속적으로 가치 있는 소프트웨어를 제공하는 것으로, 명확하고 효과적인 이론과 실천을 통해 이를 성취할 수 있게 만듭니다.
- 롭 산하임(Rob Sanheim) / 렐러번스(Relevance) 주식회사 의장

90년대 후반 켄트 벡과 함께 스위스에서 보험 회사를 위한 작업을 수행했다. 켄트 벡이 프로젝트를 소개할 때 고도로 훈련된 팀이 매일 밤 소프트웨어를 실환경에 배포하는 점이 흥미로웠다. 정기적인 배포는 여러 이점이 있었다. 작성한 소프트웨어를 배포 시까지 기다릴 필요가 없고, 문제와 기회에 빨리 응답할 수 있으며, 빠른 작업 전환 덕에 비즈니스 고객, 최종 고객과 긴밀한 관계를 구축할 수 있었다.

지난 십 년간 소트웍스(ThoughtWorks)에 근무하며 해온 프로젝트의 공통 주제는 아이디어를 사용할 수 있는 소프트웨어로 만드는 데 걸리는 주기를 줄이는 것이었다. 많은 프로젝트를 살펴봤고 거의 대부분 주기를 단축했다. 일반적으로 매일 제품을 배포하진 않지만 팀은 보편적으로 격주 출시를 수행한다.

데이브와 제즈는 이런 변화를 일으키는 일원으로, 신뢰할 수 있는 소프트웨어를 자주 배포하는 문화를 구축하는 프로젝트에 적극 참여했다. 그들은 동료들과 함께 일 년에 한 번 배포하며 문제점을 겪는 상황에서 출시가 일상적인 일이 되도록 조직을 변화시켰다. 적어도 개발 팀에게 이 방법의 기본은 지속적 통합(CI, Continuous Integration)이다. CI는 전체 팀의 동기화를 유지하고 통합 문제로 인한 지연을 제거한다. 몇 년 전 폴 듀발(Paul Duvall)이 이 시리즈의 CI 책을 저술했다. 하지만 CI는 첫 단계다. 소프트웨어가 완전하게 메인라인에 통합됐더라도 실환경에서 수행되지 않고 있다면 소프트웨어라고 말할 수 없다. 데이브와 제즈는 그들의 책에서 ‘최후의 길’을 다루기 위해 CI로부터 이야기를 선택해 통합 코드를 실환경 소프트웨어로 만드는 배포 파이프라인을 어떻게 구축하는지를 설명한다.

이런 식의 배포에 대한 생각은 오랫동안 소프트웨어 개발의 잊혀진 구석이었으며, 개발과 운영 팀 사이의 공간에 놓여 있었다. 그러므로 이 책에서 이런 팀이 함께 작업하는 초기 선구자 역할을 하여 개발과 운영 활동으로 발전하는 기술이 나오는 것은 당연한 일이다. 또한 이 프로세스는 테스터를 포함하며, 테스트는 오류 없는 출시를 보장하는 핵심 요소다. 이런 종류의 모든 고수준의 자동화를 묶어 빠르고 오류 없이 작업을 완료할 수 있다.

이런 모든 작업엔 노력이 필요하지만 효과는 확실하다. 오래 걸리고 높은 집중도가 필요한 출시는 과거의 일이 되었다. 소프트웨어 고객은 아이디어가 매일 사용할 수 있는 동작하는 코드로 변화하는 모습을 목격하게 된다. 가장 중요한 부분은 소프트웨어 개발의 가장 해로운 스트레스 원천을 제거할 수 있다는 점이다. 누구도 월요일 새벽까지 시스템 업그레이드 출시 준비로 주말을 보내고 싶진 않을 테니 말이다.

이 책은 소프트웨어를 자주 일상적인 스트레스 없이 배포하는 방법을 보여주므로 읽기 용이할 것이다. 여러분의 팀을 위해 이에 동의할 수 있기를 바란다.
마틴 파울러

어제 당신의 상관이 시스템의 대단한 신 기능을 고객에게 시연하라 요구했지만 아무것도 보여줄 수 없었을 것이다. 모든 개발자가 신규 기능을 개발하고 있지만 애플리케이션을 당장 실행할 수 있는 사람은 없다. 코드를 컴파일하고 지속적 통합 서버에서 모든 단위 테스트를 통과했지만 외부에서 접근할 수 있는 UAT 환경에 신규 버전을 출시하는 데 며칠이 걸린다. 그처럼 짧은 시간에 알려주고 시연을 요구하는 건 불합리한 일일까?

제품에 심각한 오류가 있다. 매일 비즈니스에서 손실이 발생하고 있다. 무엇을 수정해야 하는지 알고 있다. 세 단계 계층 시스템에서 모두 사용하는 라이브러리 하나와 그에 대응하는 데이터베이스를 수정하면 된다. 하지만 지난번 소프트웨어 신 버전을 실환경에 출시하느라 주말 새벽 3시까지 작업을 해야 했고 그 일 직후 배포를 담당했던 직원이 사직해버렸다. 다음번 출시는 주말을 넘겨 작업하게 되리란 사실을 알고 있으며, 이는 근무 시간에 애플리케이션이 동작하지 않을 것이란 의미다.

모두 공통의 문제이긴 하지만 이 문제들은 소프트웨어 개발 프로세스에서 피할 수 없는 결과가 아니다. 이건 뭔가 잘못되고 있다는 신호다. 소프트웨어 출시는 매우 빠르고 반복 가능한 프로세스여야 한다. 요즘 많은 회사가 하루에 수차례 출시를 수행한다. 심지어 코드 기반이 매우 복잡한 대규모 프로젝트에서도 가능하다. 이 책에서 이를 수행하는 방법을 보여준다.

“당신의 조직은 한 줄의 코드를 수정해 배포하는 데 얼마나 걸립니까? 배포 방법은 반복적이고 신뢰할 수 있습니까?”라고 메리와 톰 포펜딕은 질문한다. 변경하기로 마음 먹는 것에서 실제 적용까지 걸리는 시간을 순환 시간(cycle time)이라 하며, 프로젝트의 중요한 지표다.
많은 조직의 순환 시간을 측정해보면 수 주나 수개월이며 배포 프로세스는 전혀 반복적이지 않거나 신뢰할 수 없다. 수동으로 처리하고 때론 실환경 배포뿐만 아니라 테스트나 스테이징 환경에 소프트웨어를 배포하는 경우에도 한 팀의 사람이 필요하다. 이와 유사한 복잡한 프로젝트 환경에서 시작한 경우라도 집중적인 개량을 통해 중요한 수정사항의 경우 팀의 순환 시간을 수 시간 또는 수 분으로 단축했다. 이것이 가능했던 이유는 빌드, 배포, 테스트, 출시 프로세스의 여러 단계를 변경해 완전히 자동화하고, 반복적이고, 신뢰할 수 있는 프로세스를 구축했기 때문이다. 자동화가 핵심이다. 개발자, 테스터, 운영자가 소프트웨어의 생성과 배포에 관련한 공통 작업을 버튼 하나를 눌러 수행할 수 있다.

이 책은 아이디어에서 비즈니스 가치를 실현하는 순환 시간을 짧고 안전하게 하여 소프트웨어 출시를 혁신화하는 방법을 다룬다. 소프트웨어를 고객에게 인도하지 못하면 수익을 창출하지 못한다. 이것이 명백한 사실임에도 대부분의 조직이 소프트웨어를 실환경에 출시하는 작업을 주로 수동으로, 에러가 발생하기 쉬운 위험한 프로세스로 처리한다. 순환 시간을 측정해보면 수개월인 경우가 보통이며, 이보다 못한 회사도 많다. 출시 주기가 1년보다 긴 경우도 있다. 큰 규모의 회사에서 아이디어를 제품으로 구현하는 데 가장 긴 순환 주기가 아닌 일주일의 지연이라도 발생하면 수백만 불의 기회 비용이 발생한다. 이런 상황임에도 위험도가 낮은 소프트웨어 출시를 가능하게 만드는 프로세스와 메커니즘이 최신의 소프트웨어 개발 프로젝트의 중요한 부분으로 취급받지 못하고 있다. 우리의 목적은 소프트웨어를 개발자로부터 실환경으로 인도하는 배포 과정을 신뢰할 수 있고, 예측 가능하며, 가시화된 그리고 잘 이해된 대규모 자동화 프로세스로 위험을 정량화할 수 있게 만드는 것이다. 이 책에서 설명하는 접근법을 이용하면 수 분 또는 수 시간 안에 아이디어를 동작하는 코드로 만들어 실환경에 배포하는 동시에 배포할 소프트웨어의 품질을 개선할 수 있다.

성공적인 소프트웨어 배포와 관련된 중요 비용은 첫 번째 출시 후 발생한다. 이 비용은 지원, 유지 보수, 신 기능 추가, 오류 수정 비용이다. 특히, 소프트웨어의 첫 번째 출시에선 사용자에게 가치를 제공하는 최소한의 기능만 포함하는 반복적인 프로세스를 이용하는 경우 그렇다. 그러므로 이 책의 원서 제목인 ‘Continuous Delivery’는 애자일 선언의 첫 번째 원칙인 ‘최상위의 목적은 빠르고 지속적으로 가치 있는 소프트웨어를 인도함으로써 고객을 만족시키는 것이다.’ [bibNp0]라는 개념을 대표한다. 성공적인 소프트웨어는 첫 번째 출시가 배포 프로세스의 시작이라는 실제 상황을 반영한다.

이 책에서 다루는 모든 기술은 사용자에게 새로운 버전의 소프트웨어 인도와 관련된 시간과 위험을 줄여준다. 피드백을 증가시키고 제품 인도와 관련된 개발자, 테스터, 운영자 간의 협업을 개선함으로써 이를 달성한다. 이 기술들은 오류 수정이든 신규 기능 인도 상황이든 간에, 애플리케이션 변경 시 내용을 수정한 다음 결과를 배포해 사용하는 데 걸리는 시간을 가능한 한 줄여주고, 발생하는 문제는 수정이 용이한 가능한 한 빠른 시점에 발견해 관련된 위험을 잘 파악할 수 있게 해준다.

제즈 험블(Jez Humble)

11세에 첫 번째 ZX Spectrum을 접한 이래로 컴퓨터와 전자공학에 매료되어 직업전선에 뛰어들기 전까지 수년 동안 6502와 ARM 어셈블러, 베이직을 사용하는 에이콘(Acorn) 장비를 개조하는 일을 즐겨왔다. IT 거품 시기인 2000년에 IT 분야에 입문한 이후 지금까지 개발자, 시스템 관리자, 트레이너, 컨설턴트, 관리자, 발표자로 근무했다. 다양한 비영리 단체, 통신 회사, 금융 서비스, 온라인 소매점 컨설팅과 여러 플랫폼 및 기술을 활용해왔다. 2004년부터 소트웍스와 소트웍스 북경, 방갈로르, 런던, 샌프란시스코 지점을 위해 근무했다. 옥스퍼드에서 물리와 철학 학사를 받았으며 런던 대학의 동양과 아프리카 학부에서 음악인류학 석사를 받았다. 현재 샌프란시스코에서 부인과 딸과 함께 살고 있다.

데이비드 팔리(David Farley)

컴퓨터에 흥미를 느낀 지 약 30년 가까이 되었다. 그 기간 동안 거의 모든 소프트웨어 형식(팜웨어부터 운영체제 및 장치 드라이버 수정, 게임 개발과 모든 규모의 크기와 형식의 상용 애플리케이션까지)을 경험했다. 약 20년 전 대규모의 분산 시스템 업무를 시작했으며, 느슨한 결합과 메시지 기반 시스템(SOA의 선구자인) 연구를 수행했다. 영국과 미국에서 크고 작은 팀과 함께 복잡한 소프트웨어를 개발한 폭넓은 경험을 보유하고 있다. 1990년대 초반부터 애자일 개발 방법인 반복 주기 개발, 지속적 통합, 상용 프로젝트에 상당 수준의 테스트 자동화를 도입한 선구자다. 소트웍스에서 근무하는 4년 반의 기간 동안 애자일 개발 방법론을 연마했으며, 가장 규모가 크고 도전적인 프로젝트의 주요 기술 작업을 진행했다. 현재는 세상에서 가장 고성능의 증권 거래를 구축하기 위해 이 책에서 기술한 모든 주요 기술을 채택한 조직인 LMAX에 근무 중이다.

상황 1 "서비스 긴급 배포 좀 해주세요!" "담당자가 휴가라 불가능해요.'

상황 2 "서버 한 대만 설정이 잘못되어 장애가 발생했어요."

상황 3 "소스 코드가 빌드조차 안 되는 상태로 오래 방치되고 있어요."

상황 4 "서비스 장애가 발생했는데 이전 버전으로 복구할 수 있나요?" "불가능해요. 개발자가 서비스 환경에서 디버깅 중이니 기다려주세요."

상황 5 "성능 테스트 결과가 왜 이렇게 안 맞는 건가요?" "테스트 환경과 실 서비스 환경이 달라서 그렇습니다."

소프트웨어 개발에 참여해본 독자라면 위에서 열거한 상황 중 적어도 한 가지 이상은 겪어봤을 것이며, 어쩌면 이 문제들을 모두 겪은 독자는 더 많을 것이다. 좋은 기획 내용을 개발자가 코드로 생산하고 QA가 테스트하고 운영자가 배포하면 소프트웨어 개발이 끝난다고 쉽게 생각할 수 있지만, 이 과정이 원활하게 동작하려면 많은 노력이 필요하다. 특히, 이러한 작업을 개인에게 의지해 수동으로 진행하는 경우라면 문제 발생을 피할 수 없다. 여러 대의 서버를 수동으로 설정하다 실수를 해서 장애가 발생하고, 수동으로 모든 테스트를 수행하느라 오랜 시간이 걸리고, 여러 개발자가 개발한 코드를 통합하는 과정에서 무수한 오류가 쏟아져 나와 많은 비용 낭비와 시간 지연이 발생한다. 나 또한 이러한 문제로 많은 어려움을 겪었으며, 이를 극복하기 위해 오랜 시간 노력해왔다.

소프트웨어 개발에서 뛰어난 아이디어를 구현해 고객이 사용할 수 있게 되는 데까지 걸리는 시간을 순환 시간(cycle time)이라 정의한다. 순환 시간이 짧으면 고객은 최신의 기능을 자주 접할 수 있으며 개발사는 고객의 반응을 살피고 적합한 소프트웨어를 개발할 수 있는 확률이 높아진다. 순환 시간을 줄이려면 소프트웨어를 고객에게 전달하는 데 필요한 개발, 테스트, 빌드, 배포, 출시 등의 단계를 효과적으로 수행해야 하며, 전체 프로세스가 효율적으로 관리돼야 한다.

이 책은 이에 필요한 기술과 사례를 다룬다. 독자는 효과적인 소프트웨어 개발에 필요한 여러 기법과 실천 방법을 배울 수 있으며, 적용 사례를 이용해 각 상황에 적합한 해결책을 도출해낼 수 있다. 그런 의미에서 이 책을 독자에게 소개할 수 있는 기회가 주어진 것에 매우 감사한 마음이다. 이 책을 활용해 효과적인 소프트웨어 개발과 출시를 수행하여 개인의 휴식과 발전을 위한 시간을 할애할 수 있는 분이 많아지길 희망한다.
대표 역자 유석문

유석문

기전공학과 석사 과정 후 LG전자 우면연구소, 인텔리코리아, 핸디소프트에서 소프트웨어 개발자로 근무했다. 이후 NHN(현 NAVER)에서 QA, 지도 서비스 개발, 효과적인 소프트웨어 개발 방법의 연구 및 전파 업무를 수행했으며, 오픈소스 NTAF 개발에 참여했다. 저서로 『소프트웨어 품질 관리: NHN은 이렇게 한다!』(공저), 『프로그래머로 산다는 것』(공저)이 있다.

김은하

테스트 자동화를 위한 오픈소스 개발에 참여했고, 소프트웨어 품질 향상을 위한 연구 활동을 하고 있다. 저서로 『소프트웨어 품질 관리: NHN은 이렇게 한다!』(공저)가 있다.

설현준

부산광역시 출생으로, 중학교 때 도미해 코넬 대학교에서 컴퓨터공학과를 졸업하고, 동 대학교 대학원에서 컴퓨터공학 전공으로 공학석사 학위를 취득했다. 2011년 이후로 Naver에서 소프트웨어 개발과 음성합성/음성인식 연구를 맡아왔다. 현재 Naver Labs의 음성인식개발 랩에서 대리로 근무 중이다.