애자일 분야의 최고수들이 모인 소트웍스, 과연 그들은 소프트웨어에 대해 무슨 생각을 할까?

21세기 소프트웨어 개발의 최전선에서 그들이 실제 경험하고 적용하여 얻은 지혜와 통찰력이 어떠한 편집과 검열도 없이 자유롭게 표출된 <소트웍스 앤솔러지>는 하나의 주제로 철저한 기획력의 산물인 전형적인 기술서들과는 달리, 소트웍스 사람 하나하나의 마음을 잔잔한 호수처럼 비춰주는 옥색 문장들로 채워져 있다.

자유로움과 다채로움은, 결코 산만하게 서로를 외면하는 대신, 결국은 오늘날 소프트웨어 개발의 고민에 대한 대안 제시에 있어 많은 점을 공유하게 된다. 다양한 스팩트럼 중에 겹치는 ‘더 좋은 소프트웨어 개발 과정과 결과'를 향한 강렬한 열정이 독자의 마음을 비출 것이다.

 

기술적 깊이, 자세한 정도, 그리고 새로운 발상과 연구의 양은 이 책의 수필들 속에서 팔색조처럼 다채롭다. 하지만 이 모두를 관통하는 요소는 실제적으로 모두 긴밀히 연결되어 있다는 것이다. 작가들은 내가 일전에 보지 못했던 무언가-'생각이 도발적인'과 '즉시 적용가능한' 사이의 교묘한 균형-을 이루어냈다. -- 스테판 틸코프(Stefan Tilkov) CEO, innoQ

이 에세이집은 커스텀 소프트웨어는 너무 어렵다거나 너무 비싸다는 IT 산업의 오래된 고정관념에 감히 도전장을 내민 한 회사의 다양한 문제 접근 의 시각을 보여준다. -- W. 제임스 피셔(W. James Fischer) 전 CTO, 엑센츄어

CruiseControl과 같은 고도의 성공적 오픈소스 프로젝트로부터 블로그와 컨퍼런스를 통해 공유된 아이디어에 이르기까지, 아마도 소트웍스가 자신의 프로젝트에 끼친 영향은 많이 느껴왔을 것이다. 밖에 있는 우리에게는 대체 그 안에서 무슨 대화가 오갈지 궁금해 할 따름이지만, 이 책은 커튼을 걷고 토론에 동참하는 드문 기회이며 그를 통해 독자는 개발자로서 진일보할 것이다. -- 나다니엘 T. 슈타(Nathaniel T. Schutta) 작가

소프트웨어는 다방면으로 팀 스포츠와 닿아 있고, 리더가 소프트웨어 문화를 형성한다. 성공적인 조직이 자신의 문서화에 시간을 자주 할애하지 않는 탓에 다른 이들은 그 혜택을 보지 못하고 있다. 이 흥미로운 자전적 에세이 모음은 소트웍스의 문화가 어떤 것인지를 소트웍스의 리더들을 통해 들여다보게 해주고 있다. -- 데이브 토마스(Dave Thomas) 베다라 연구소(Bedarra Research Labs)

소프트웨어 개발에 있어 최고의 통찰력은 실제 고객을 위해 실제 문제를 푸는 사람들로부터 나온다. 산재한 블로그를 구석구석 뒤지는 것은 차치하더라도, 그런 식견을 접하기는 거의 불가능하다. 소트웍스 사람들은 지난 10여년간 많은 실제 문제를 풀어왔고, 그래서 나는 내 손에 그들의 전문 기술에 대한 종합적 단편을 쥐고 있다는 것에 진심으로 기쁘다. -- 그레고르 호페(Gregor Hohpe) Enterprise Integration Patterns 공저자

이 책은 오늘날 까다로운 현업에서의 소프트웨어 개발에 있어 적절한 언어와 툴의 사용에 대해 논하는 뛰어난 에세이집이다. 저자들은 소프트웨어 업계의 명망 높은 베테랑들이다. -- 테렌스 파(Terence Parr) ANTLR 프로젝트 리드, 샌 프란시스코 대학(University of San Francisco)

소트웍스의 유명한 경험과 지혜를 접할 수 있게 해주는 선집을 뽑아낸 환상적인 작품이다. 모든 프로젝트의 책장에 꼽혀, 자주 인용될 책 중의 하나이다. -- 제프 브라운(Jeff Brown) 북미 운영 이사, G2One

애자일 분야의 최고수들이 모인 소트웍스, 과연 그들은 소프트웨어에 대해 무슨 생각을 할까?

21세기 소프트웨어 개발의 최전선에서 그들이 실제 경험하고 적용하여 얻은 지혜와 통찰력이 어떠한 편집과 검열도 없이 자유롭게 표출된 『소트웍스 앤솔러지』는 하나의 주제로 철저한 기획력의 산물인 전형적인 기술서들과는 달리, 소트웍스 사람 하나하나의 마음을 잔잔한 호수처럼 비춰주는 옥색 문장들로 채워져 있다.

『소트웍스 앤솔러지』에서 펼쳐지는 자유로움과 다채로움은 산만하게 서로를 외면하기보다는, 결국은 오늘날 소프트웨어 개발의 고민에 대한 대안 제시라는 점에서 더 많이 공감하게 된다. 다양한 스펙트럼 중에서도 큰 흐름을 이어가는 '더 좋은 소프트웨어 개발 과정과 결과'라는 주제를 향한 강렬한 열정이 독자의 마음을 비출 것이다.

마틴 파울러(Martin Fowler)

소트웍스 사의 최고 책임 과학자로 리팩터링이란 개념을 정립하고 널리 퍼뜨리는 데 가장 큰 공헌을 한 사람 가운데 한 명이며 초창기부터 애자일 운동에 참여하여 그 성공에 기여했다. 저서로는 『리팩터링』, 『UML Distilled』, 『엔터프라이즈 애플리케이션 아키텍처 패턴』 등이 있다.

소트웍스 ThoughtWorks

소트웍스는 현재 미국에서 가장 주목받고 있는 시스템 통합 및 컨설팅 회사다. 현재 미국, 캐나다, 일본, 중국, 호주, 유럽 등으로 활동 영역을 넓혀나가고 있으며 우수한 인재 확보와 애자일 방법론 적용 그리고 오픈소스 참여 등을 통해 성공적인 성장을 하고 있다.

이창신 iasandcb@gmail.com, http://iasandcb.pe.kr

티맥스소프트 WAS실과 엔씨소프트 오픈마루 스튜디오를 거쳐 현재 ias(iNDI aPPLICATION sOFTWARE) 대표로 독립 소프트웨어 개발에 매진하고 있다.

강규영 http://jania.pe.kr

다음커뮤니케이션, 애자일 컨설팅을 거쳐 현재 엔씨소프트 오픈마루 스튜디오에서 일하고 있다. <테스트 주도 개발>, <자바 웹 서비스로 통하는 서비스 지향 아키텍쳐> 등을 공역하였으며 블로그 http://alankang.tistory.com 및 개인 위키 http://jania.pe.kr을 운영 중이다.

최재훈 http://kaistizen.net

http://kaistizen.net을 운영하는 SK 아이미디어의 게임 서버 개발자이다. C , C#, C /CLI, MSSQL 같은 윈도 플랫폼을 주로 다루며 한 달에 한 번 마이크로소프트웨어에 칼럼을 쓴다.

정지웅 http://blog.changtheweb.net

개발자로서 삼성전자와 오픈마루 스튜디오에서 근무했고, 현재는 신규 웹서비스와 창업을 준비 중에 있다. 웹기술과 웹비즈니스에 관한 이야기를 블로그(http://blog.changtheweb.net)에 쓰고 있다. 번역서로 '자바개발자를 위한 레일스' 등이 있다.

안영회 ahnyounghoe@gmail.com

(주)아이티와이즈 컨설팅 SE 그룹에서 컨설턴트로 일하고 있으며, 한국스프링사용자모임(KSUG)의 대표를 맡고 있기도 하다. 본인의 블로그인 Younghoe.info를 통해 현장 경험을 나누고 있다.

이대엽

(주)넷스루에서 근무하고 있으며, 제품 개발 및 유지보수 업무를 담당하고 있다.

 

옮긴이 글

제 마지막 번역서로서 『소트웍스 앤솔러지』는 탁월한 선택이었다고 생각합니다. 공역자로서 책의 모든 내용을 전할 수는 없지만, JRuby를 통해 관심가졌던 다언어 프로그래밍, 수년을 몸담았던 SOA, 그리고 한동안 잊고 있었던 코드의 미학까지, 현장을 누비고 있는 현자들의 목소리를 듣고 우리말로 옮길 수 있게 되어 큰 행복이었습니다.

하지만, 어려움은 그 행복의 크기만큼 따라옵니다. 특히나 원저자의 멋진 문장과 감칠맛나는 호소력을 제대로 소화해내지 못한 것 같아 못내 아쉽습니다. 최근 ‘스튜디오 판타지아'라는 블로그를 통해 번역의 맛을 새롭게 깨달아가긴 하지만, 이제 ‘제대로 번역할 기회'는 이번 제 원고의 검토를 통해 훌륭한 번역의 빛을 보여주신 이대엽님 같은 열정과 고민으로 충만한 분들에게 가기를 소망합니다.

그동안 도와주신 모든 분들께 감사 또 감사드립니다.

-- 이창신

  • 1 들어가는 말
  •  
  • 2 비즈니스 소프트웨어의 '마지막 한 단계' 해결하기
    • 2.1 '마지막 한 단계' 문제의 원인
    • 2.2 문제 이해하기
    • 2.3 '마지막 한 단계' 문제 해결하기
    • 2.4 사람
    • 2.5 자동화
    • 2.6 비기능적 요구사항을 위한 자동화된 테스트 설계하기
    • 2.7 실제 업무 환경에 대한 의존성 제거하기
    • 2.8 버전 없는 소프트웨어
  •  
  • 3 악당 소굴과 20개의 루비 DSL
    • 3.1 악당 소굴 예제
    • 3.2 전역 함수를 사용하는 방법
    • 3.3 객체를 사용하는 방법
      • 클래스 메서드와 메서드 연결하기Method Chaining
      • 표현 빌더Expression Builder
      • 메서드 연결하기에 대해 조금 더
    • 3.4 클로저를 사용하는 방법
    • 3.5 평가 맥락Evaluation Context
    • 3.6 리터럴 컬렉션
      • 가변 인자 메서드
    • 3.7 동적 수신Dynamic Reception
    • 3.8 마무리
  •  
  • 4 프로그래밍 언어의 울창한 숲
    • 4.1 서론
    • 4.2 표본 언어
    • 4.3 다양한 변이들
      • 패러다임
      • 타입 특성
      • 실행 방식
      • 구현 모델
    • 4.4 언어의 생명수
    • 4.5 흥미롭기는 하지만 왜 이런 것을 알아야 하나?
  •  
  • 5 다언어 프로그래밍
    • 5.1 다언어 프로그래밍
    • 5.2 그루비Groovy 방식으로 파일 읽기
    • 5.3 JRuby와 isBlank
    • 5.4 자스켈Jaskell과 함수형 언어
    • 5.5 자바 테스트하기
    • 5.6 다언어 프로그래밍의 미래
  •  
  • 6 객체 미용 체조
    • 6.1 오늘날 더 나은 소프트웨어를 향한 9단계
    • 6.2 훈련
      • 규칙
      • 규칙 1: 메서드당 들여쓰기 한 번
      • 규칙 2: else 예약어 금지
      • 규칙 3: 원시값과 문자열의 포장
      • 규칙 4: 한 줄에 한 점만 사용
      • 규칙 5: 축약 금지
      • 규칙 6: 모든 엔티티를 작게 유지
      • 규칙 7: 2개 이상의 인스턴스 변수를 가진 클래스 사용 금지
      • 규칙 8: 일급 콜렉션 사용
      • 규칙 9: 게터/세터/속성 사용 금지
    • 6.3 결론
  •  
  • 7 반복 관리자란 무엇인가?
    • 7.1 반복 관리자란 무엇인가?
    • 7.2 무엇이 좋은 반복 관리자를 만드는가?
    • 7.3 반복 관리자 역할이 아닌 것
    • 7.4 반복 관리자와 팀
    • 7.5 반복 관리자와 고객
    • 7.6 반복 관리자와 반복
    • 7.7 반복 관리자와 프로젝트
    • 7.8 결론
  •  
  • 8 프로젝트의 활력 징후
    • 8.1 프로젝트 활력징후
    • 8.2 프로젝트의 활력징후 vs 프로젝트의 건강
    • 8.3 프로젝트 활력 징후 vs 정보방열기
    • 8.4 프로젝트 활력 징후 : 범위 소모
      • 범위 소모에 대한 정보방열기의 예
      • 범위 측정의 단위 정의하기
      • 중간 이정표를 사용해서 병목지점을 밝혀내기
      • 범위 소모 차트에 대한 자세한 설명
    • 8.5 프로젝트 활력
      • 품질 정보방열기의 예
      • 버그 집계차트에 대한 상세 설명
    • 8.6 프로젝트 활력징후 : 예산 소모
      • 예산 정보방열기의 예
      • 예산 소모 차트에 대한 보충 설명
    • 8.7 프로젝트 활력징후 : 현재 구현 상태
      • 현재 구현상태에 대한 정보방열기의 예
      • 구현 상태를 정의하기
      • 스토리보드와 스토리카드에 대한 보충 설명
    • 8.8 프로젝트 활력 징후 : 팀 인지
      • 팀 인지에 대한 정보방열기의 예
      • 팀 분위기 차트 상세 설명
  •  
  • 9 소비자 주도 계약: 서비스 진화 패턴
    • 9.1 서비스의 진화: 예제
    • 9.2 스키마 버전 관리
      • 확장점
    • 9.3 문제적 변경
      • 스키마트론
    • 9.4 소비자 주도 계약
      • 제공자 계약
      • 소비자 계약
      • 소비자 주도 계약
      • 계약 특성 요약
      • 구현
      • 이점
      • 소비자 주도 계약과 SLA
      • 의무
      • 결론
  •  
  • 10 도메인 어노테이션
    • 10.1 어노테이션을 만난 도메인 주도 설계
      • 도메인에 특화된 메타데이터
      • 자바 어노테이션과 닷넷 어트리뷰트
      • 도메인 어노테이션
      • 도메인 어노테이션을 사용하는 경우
    • 10.2 사례 연구 : 르로이의 화물차
      • 도메인 모델
      • 데이터 분류
      • 대안들
      • Auditor에서의 사용
      • PermissionChecker에서의 사용 예
      • Loader에서의 사용예
      • 운항 힌트
      • 대안들
      • PermissionChecker 에서의 사용
      • Loader에서의 사용
    • 10.3 정리
  •  
  • 11 Ant 빌드 파일 리팩터링하기
    • 11.1 개론
      • 리팩터링은 무엇인가? 그리고 Ant는 무엇인가?
      • 언제 리팩터링을 해야 하나? 언제 그냥 넘어가야 하나?
      • Build.xml 파일을 리팩터링할 줄 아는가?
    • 11.2 Ant 리팩터링 일람표
      • Macrodef 추출하기
      • 타겟 추출하기
      • 선언 도입하기
      • 호출을 의존성으로 대체하기
      • 프로퍼티를 리터럴로 대체하기
      • filtersfile 도입하기
      • 프로퍼티 파일 도입하기
      • 타겟을 래퍼 빌드 파일로 옮기기
      • 주석Comment 대신 설명Description 쓰기
      • 배포 코드를 임포트하기
      • 엘리먼트를 antlib에 옮기기
      • 커다란 라이브러리 정의 대신 Fileset 쓰기
      • 런타임 프로퍼티 옮기기
      • 엘리먼트를 식별자 별로 재활용하기
      • 프로퍼티를 타겟 밖으로 옮기기
      • Value 애트리뷰트 대신 Location 애트리뷰트 쓰기
      • 래퍼 스크립트를 bulid.xml 파일에 내려놓기
      • taskname 애트리뷰트 넣기
      • 내부 타겟을 강제하기
      • 출력 디렉터리를 부모 디렉터리로 옮기기
      • Exec 대신 Apply 쓰기
      • CI 게시자 사용하기
      • 타겟에 구분하기 쉬운 이름 붙여주기
      • 타겟의 이름을 명사로 다시 고쳐짓기
    • 11.3 요약
    • 11.4 참고 문헌
    • 11.5 리소스
  •  
  • 12 한방에 소프트웨어 출시하기
    • 12.1 지속적인 빌드
    • 12.2 지속적인 빌드를 넘어서
    • 12.3 지속적인 통합의 전체 생명주기
      • 바이너리 관리하기
    • 12.4 체크인 관문
    • 12.5 인수 테스트 관문
    • 12.6 배포 준비하기
    • 12.7 후속 테스트 단계들
    • 12.8 프로세스 자동화하기
    • 12.9 결론
  •  
  • 13 엔터프라이즈 웹 애플리케이션 테스트: 애자일 대 폭포수
    • 13.1 개론
    • 13.2 테스팅 생명 주기
    • 13.3 테스팅의 종류
      • 단위 테스팅
      • 기능 테스팅
      • 탐색적 테스팅
      • 통합 테스팅
      • 데이터 유효성 검증
      • 사용자 인수 테스팅 (UAT)
      • 성능 테스팅
      • 비기능적 테스팅
      • 회귀 테스팅
      • 제품 검증
    • 13.4 테스트 환경
      • 개발 통합 환경
      • 시스템 통합 환경
      • 스테이징 환경
      • 프로덕션 환경
    • 13.5 이슈 관리
    • 13.6 도구들
    • 13.7 보고와 측정
    • 13.8 테스팅 역할들
      • 테스트 분석
      • 테스트 스크립트 작성
      • 테스트 수행
      • 환경 관리
      • 이슈 관리
      • 이슈 분석
    • 13.9 참고자료
  •  
  • 14 실용적인 성능 테스팅
    • 14.1 성능 테스팅이란 무엇인가?
    • 14.2 요구사항 수집
      • 우리가 측정하고 있는 것은 무엇인가?
      • 수치를 어떻게 산정할 것인가?
      • 어떻게 이것을 일반 소프트웨어 개발 프로세스에 접목시키는가?
      • 개발자들도 성능 테스팅의 요구사항을 갖고 있지 않는가?
      • 성능 요구사항에 대한 관련자를 찾을 수 없다면?
      • 고객이 그다지 전문적이지 않고 우리가 불가능하다고
      • 생각하는 것을 원한다면?
      • 업무 분석가들도 이러한 요구사항을 수집하게 하면 어떨까?
      • 요약
    • 14.3 테스트 수행하기
      • 어떤 테스트를 다시 수행할 것인가?
      • 언제 테스트를 수행해야 하는가?
      • 어디에서 테스트를 수행해야 하는가?
      • 어떻게 자그마한 테스트 장비의 테스트 결과를 제품과 연계시키는가?
      • 성능 테스팅에 적합한 데이터베이스 크기는 얼마인가?
      • 써드파티 인터페이스는 어떻게 다룰 것인가?
      • 얼마나 다양한 테스트 케이스가 필요한가?
      • 응답 시간과 처리량에 대해 여러 측정수단을 취하는 이유는 무엇인가?
      • 시스템의 모든 기능을 테스트해야 하는가?
      • 요약
    • 14.4 의사소통
      • 누가 알아야 하는가?
      • 그렇다면 여러분이 해야 할 일은 보고서를 작성하는 것뿐인가?
      • 요약
    • 14.5 프로세스
      • 그럼 어떻게 그것들을 연계하는가?
      • 여러분이 뒤쳐지지 않았는지 어떻게 확인할 것인가?
      • 식별된 문제에 대해 조치가 취해졌는지 어떻게 보장할 것인가?
    • 14.6 요약
  •  
  • 참고 문헌
  • 24쪽 마지막줄

    소형발전기는 전력 11을 사용하고 ---> 소형발전기는 전력 11을 공급하고

  • 33쪽 위에서 4째줄

    클래서 ---> 클래스

  • 73쪽 마지막 문단

    이 메서드는 StringUtils라는 이름의 클래스가 안에 있는데 ---> 이 메서드는 StringUtils라는 클래스 안에 있는데

  • 83~84쪽 걸쳐있는 문장에서

    많은 예제와 모범 사례(심지어 썬의 JDK 코드에까지) 성능이나 ---> 많은 예제와 모범 사례(심지어 썬의 JDK 코드에까지), 성능이나

  • 175쪽 맨 밑줄

    갯수 ---> 개수

  • 189쪽 예제코드 refactoring_after.xml 주석 부분에서

    "copy compiled classes" ---> 컴파일된 클래스를 복사한다

  • 195쪽 두 번째 중제목

    뒤쳐지지 ---> 뒤처지지

  • 238쪽 밑에서 6째 줄

    테스트 주고 개발을 하면 ---> 테스트 주도 개발을 하면

  • 280쪽 6째줄

    뒤쳐지지 ---> 뒤처지지

도서 소개자료

관련 글