소프트웨어 장인, 산드로 만쿠소

이 책은 소프트웨어 업계에서 일하는 모든 직군의 사람이 읽어볼 만한 책이라고 생각한다. 특히나 일종의 매너리즘에 빠진 것을 느꼈을 때 읽으면 더욱 효과가 있을 것이라고 생각한다. 열정과 진심을 가지고 무언가에 임하는 사람의 이야기를 읽으며 본인의 일을 돌아보거나 본인의 사례를 접목해본다면 독자의 마음에도 다양한 의미의 동기부여가 일어날 것이다.

당장 표시해두었던 부분을 갈무리하는 것만으로도 뭔가 또 해보고 싶은 마음이 드는 책이다.

해가 가면서 '고침’이라는 것이 '일시적’이고 '상대적’임을 알게 되었다. 일시적이라는 이유는 기술이 발전함에 따라 고객이 기존과 다른 형태의 시스템과 기술을 요구할 수 있기 때문이다. (중략) '상대적’이라는 이유는 어떤 기술, 어떤 맥락에서, 누구와 비교해야 하는지 알아야만 고참인지 여부를 결정할 수 있기 때문이다.

애자일은 일하는 방식 자체도 완전히 바꾸어 놓았다. 팀원들의 역할이 계층적, 분업적, 세부적으로 배분되던 과거의 방식은 이제 사라지고 있다. 코드를 잘 작성하는 것이 소프트웨어 프로페셔널이 갖춰야 할 여러 역량 중 에 하나일 뿐이라는 인식이 높아졌다. 그저 계획에 맞춰서 지시받은 일만 하는 것이 아니라, 비즈니스와 고객 가치 창출에 개발자들이 직접 참여하는 것도 매우 중요하다고 주장한다. 소프트웨어 프로젝트의 여러 다른 방면에서도 개발팀의 책임이 있다는 인식이 산업계의 판도를 바꾸고 있다. 소프트웨어 프로페셔널들이 진화하도록 유도하는 것이다. 미리 세운(대부분 잘못 정의된) 계획에 따라 그저 기계적으로 코딩만 하는 것이 아니라, 계획, 일정 및 예산 등의 추산, 요구사항 분석, 팀 구성, 분석, 아키텍처, 제품 릴리즈, 우선순위 조정, 시연 그리고 사용자와 프로젝트 이해 관계자에게 정기적으로 피드백을 받는 단계까지 개발자가 수행하기 시작한 것이다.

애자일을 도입하기 전후의 사무실 풍경을 비교해보면 완전히 다른 사무실 같을 때도 있다. 계획표가 대자보처럼 붙어 있거나 칸막이가 없어지고, 두 명 이상의 개발자가 한 컴퓨터를 쓰기도 하며 여기저기 화이트보드가 배치되어 있다. 벽 전체를 화이트보드로 만들고 색색의 포스트잇으로 도배한 회사도 있다. (중략) 몇 개월 또는 몇 년이 지나 애자일 파티에서 깨어날 즈음 애자일 숙취에 빠져 두통과 어지러움에 시달리는 팀, 혹은 회사가 생기기도 한다.

이러한 변화에도 불구하고 좋은 소프트웨어를 빠르게 공급하지 못하고 있는 것이 현실이다. 많은 기업, 개발팀들이 애자일 전환 전에도 있던 문제들이 전환 후에도 여전하다. 릴리즈된 제품에 수정사항을 적용하는 데도 너무나 오랜 시간이 소요된다. 여전히 과거의 기술적 부채에 허덕인다. (중략) 관리자들은 개발한 지 겨우 몇 년밖에 안 된 애플리케이션인데도 기능 추가/수정 비용이 너무 많이 들고 비즈니스를 어렵게 한다는 이유로 통째로 버리고 새로 만드는 카드를 만지작거린다. (중략) 개발자 입장에서는 절차와 소통 방식이 개선되었지만 실제 기술적인 산출물은 바뀌지 않는다. (중략) 애자일을 도입하여 모든 절차를 뒤바꾸는 궁극적인 목적은 소프트웨어에 대한 투자 대비 이득을 키우기 위해서다. 그 목적을 달성하지 못 하면 이 노력들은 모두 허사다.

애자일의 모든 절차들에는 기준적 특월함이 전제되어 있다. 관리자들이나 역량이 부족한 애자일 코치들은 기술적 수준이 개선되어야 함을 자주 무시한다. (중략)

도요타가 성공할 수 있었던 중요한 요인은 절차를 개선하는 것뿐만 아니라 자동차의 품질에 이미 충분한 역량 과 그를 뒷받침하는 노력이 있었기 때문이다. (중략) 도요타 자동차를 살 때에는 자동차의 품질을 고려할뿐이지 공장이 어떤 과정으로 돌아가는지는 별 관심이 없다.

모든 단계마다 피드백이 있다는 전제에서만 절차의 개선으로 제품이 나아진다. 피드백 시스템이 동작하려면 자기가 하는 일에 충분히 주의를 기울이고 뭔가 잘못되고 있거나 더 나은 방법이 있다고 느낄 때 자기 목소리를 내는 재능 있고 프로페셔널한 사람들이 있어야 한다.

코드를 잘 작성하는 것은 꽤 중요하지만 프로젝트를 완성시킬 때 필요한 요소들 중 하나일 뿐이다. 고객을 도와 그들의 업무 절차를 개선하고, 좀 더 실현 가능성이 높은 선택지를 제공해야 한다. 불필요한 관료주의를 없애고, 고객의 비즈니스 도메인을 이해하며 그들이 생산하는 가치와 관련된 요구사항에 질문할 수 있어야 한다. 업무 우선순위를 정하고 계획하는 것을 돕는 일 또한 프로젝트의 성공을 위해 코딩만큼 중요한 일이다. 생산적인 동반자 관계는 어떤 순간이든 고객에게 가치를 제공하는 것을 의미한다.

고객이 속한 산업의 본질이 소프트웨어 개발이 아닌 다른 것인 때가 많다. 이때는 소프트웨어 프로젝트가 성공하도록 돕는 것이 전적으로 우리들이 해야 할 일이다. 그것이 우리가 대가를 받는 이유다. 코드와 관련된 일이 아니면 나의 일이 아니라고 생각하는 개발자는 진정한 소프트웨어 장인이라고 할 수 없다.

단위 테스트가 되지 않았다면 그 어떤 작업이건 간에 완료되었다고 말할 수 없다. 작업을 구현과 테스트로 나누어서는 안 된다. 한 시간은 서비스 클래스를 구현하고 다른 한 시간은 테스트를 작성하더라도 둘은 서로 독립된 작업이 아니다. 두 시간 분량의 한 가지 작업일 뿐이다. 서비스 클래스의 구현 작업 하나다. 테스트는 형태에 상관없이 한 코딩 작업의 요소일 뿐 별개의 작업이 아니다.

당장의 합당한 이유 없이 단지 '미래를 대비해야 한다’는 모호한 전제로, 초기부터 추상화를 하면 애플리케이션이 엉망이 된다. 미래에 어느 부분에서 수정이 필요할지 모르기 때문에 모든 부분에서 추상화(복잡도 증대)를 적용해버린다. 애플리케이션이 진화 및 변경할 수 있도록 모든 가능성에 대비하는 것을 똑똑한 대응이라고 생각할 수도 있다. 진실은, 반대로 매우 바보같은 짓이다.

초기부터 추상화를 도입해서 이득을 볼 수 있는 부분이 일부 있을 수 있다. 코드 베이스 전체적으로는 그 추상화때문에 불필요한 고통이 유발된다. 실용적인 접근 방법은 실제로 필요한 상황이 생겼을 때만 추상화를 도입하는 것이다.