🤔 Chapter 9: 실용주의 프로젝트

🍭 Topic 49. 실용주의 팀

우리가 말하는 팀은 작고 보통은 그 자체로 안정적인 존재다. 50명은 팀이 아니다. 큰 무리다. 구성원이 계속 다른 업무에 끌려가고, 아무도 서로를 모르는 팀도 사실 팀이 아니다.

실용주의 팀은 작다. 구성원이 대략 10 ~ 12명 이하여야 하고, 구성원이 추가되거나 빠지는 일은 드물어야 한다. 모두가 서로 잘 알고, 신뢰하며, 의존해야 한다.

Tip 84. 작고 안정적인 팀을 유지하라.

🥕 깨진 창문을 없애라

품질은 팀의 문제다. 아무리 부지런한 개발자라 해도 품질에 무심한 팀에 배치된다면, 자질구레하게 계속되는 문제를 고치는 데 필요한 열정을 유지하긴 어려울 것이다. 개발자가 이런 수정 작업을 하느라 시간을 쏟는 것을 팀이 적극적으로 방해하고 나선다면 문제는 더욱 커진다.

팀 전체가 깨진 창문을 용납하지 않아야 한다. 사소한 결점을 아무도 고치지 않고 놔두어서는 안 되고, 반드시 제품의 품질에 책임을 져야 한다. 몇몇 팀 방법론에는 "품질 관리 담당자"가 있어서 제품의 품질에 대한 책임을 팀에게서 위임받는다. 정말 웃기는 일이다. 품질은 팀원 모두가 제각기 기여할 때만 보장되기 때문이다. 품질은 애초에 제품에 포함된 것이지 나중에 덧붙이는 것이 아니다.

🥕 삶은 개구리

팀은 개인보다 더 삶은 개구리가 되기 쉽다. 사람들은 누군가가 문제를 처리하겠거니 생각하거나, 사용자가 요청한 변경 사항을 팀 리더가 이미 동의했겠거니 하고 여긴다. 제아무리 좋은 뜻을 가진 팀이라도 자기네 프로젝트가 심각하게 변화하는 것에는 둔감할 수도 있다.

이에 맞서야 한다. 모든 사람이 적극적으로 환경 변화를 감시하도록 권장하라. 범위의 확장, 일정 단축, 추가 기능, 새로운 환경 등 무엇이건 간에 애초에 인지하고 있던 것과 다른 것들을 늘 깨어서 의식해야 한다. 새 요구사항에 대한 수치를 관리하라. 이미 일어난 변화를 거부할 필요는 없다. 단지 그런 일이 벌어지고 있다는 것을 파악하고 있으면 된다. 그러지 않으면 여러분이 뜨거운 물 속에서 삶아지는 신세가 될 것이다.

🥕 여러분의 지식 포트폴리오를 계획하라

성공을 원하는 팀이라면 마찬가지로 자신들의 지식과 기술에 투자하는 것을 고려해야 한다.

여러분의 팀이 진정 개선하고 혁신하고 싶다면 계획을 세워야 한다. "시간이 나면 그때" 하겠다는 것은 "영원히 하지 않겠다"는 것이다. 할 일을 백로그로 관리하든 업무 목록이나 업무 흐름 도구를 사용하든 간에 기능 개발로만 몽땅 채우지는 말라. 새로운 기능을 만드는 것 외에도 해야 할 일들이 있다.

구형 시스템 유지 보수

구형 시스템에도 해야 할 유지 보수 없무가 아마 있을 것이다. 우리는 이 일을 구석에 치워 두려고 하는 팀들을 많이 만났다. 팀이 이 임무를 맡고 있다면, 진짜로 수행하라.

프로세스 회고와 개선

지속적인 개선이 일어나려면 주위를 둘러보고 무엇이 잘되고 무엇이 잘되지 않았는지 확인한 다음 변화를 일으킬 시간이 있어야 한다. 너무나 많은 팀이 물을 퍼내기에 급급해서 물이 새는 곳을 고칠 틈이 없다. 계획을 세우고, 고쳐라.

새로운 기술 탐험

새로운 기술이나 프레임워크, 라이브러리를 그저 "다들 쓰니까"라는 이유로, 또는 콘퍼런스에서 본 것이나 인터넷에서 읽은 글을 바탕으로 도입하지 말라. 후보 기술로 프로토타입을 만들어 보고 신중하게 조사하라. 새로운 것을 시도해 보고 결과를 분석하는 업무를 일정표에 추가하라.

학습 및 기술 갈고 닦기

개인적으로 배우고 역량을 키우는 것은 좋은 시작점이다. 하지만 많은 기술이 팀 전체로 퍼졌을 때 더 효과적이다. 팀원들을 전도할 계획을 세워라. 점심을 먹으며 가볍게 이야기할 수도 있고, 더 형식을 갖추어 스터디 시간을 잡을 수도 있다.

Tip 85. 실현하려면 계획하라.

🥕 팀의 존재를 소통하라

외부 사람들에게 무뚝뚝하고 과묵해 보이는 프로젝트팀이야말로 최악이다. 그런 팀의 회의는 아무런 체계가 없고 침묵만 가득하다. 이메일과 프로젝트 문서는 엉망진창이다. 문서마다 생김새도 제각각이고, 서로 다른 용어를 사용한다.

훌륭한 프로젝트팀은 뚜렷한 특성이 있다. 사람들은 이 팀과의 회의를 기대한다. 모든 사람이 좋아할 만한 잘 준비된 퍼포먼스를 보게 될 걸 알기 때문이다. 이들이 생산해 내는 문서는 깔끔하고 정확하며 일관적이다. 팀은 한 목소리로 이야기한다.

팀이 하나로 의사소통하게 도와주는 간단한 마케팅 비결이 있다. 프로젝트를 시작할 때 이름을 지어 주는 것이다. 유별난 이름이라면 더 좋겠다. 30분 정도 투자해서 괴짜스러운 로고를 만들어 사용하라. 사람들과 대화를 할 때 자신의 팀 이름을 거리낌 없이 사용하라. 바보같이 들리겠지만 팀은 정체성 확립의 기반을 얻을 것이고, 세상은 여러분의 작업과 관련해서 기억할 만한 뭔가를 얻게 될 것이다.

🥕 반복하지 말라

중복된 일은 노력을 무위로 돌릴 뿐 아니라 결국 유지 보수의 악몽으로 만들 수도 있다.

좋은 의사소통이 이런 문제를 피하는 핵심이다. 여기서 "좋은"이란 즉각적이고 매끄러운 것을 말한다.

여러분은 팀 동료에게 질문을 하고 거의 즉각적으로 답을 받을 수 있어야 한다. 팀이 한 사무실에 모여 있다면 칸막이 너머나 통로 저쪽으로 고개를 내밀기만 하면 될 것이다. 원격에서 일하는 팀이라면 메신저 앱이나 다른 전자적인 수단을 활용해야 할 것이다.

만약 질문을 하거나 여러분의 상황을 공유하기 위해 일주일 남은 팀 회의 시간까지 기다려야 한다면 엄청 껄끄러운 커뮤니케이션이다. DRY를 지키려면 서로 관심을 유지하라.

🥕 팀 예광탄

처음에는 작고 제한적일지라도 시스템의 끝에서 끝까지 전체에 걸쳐 있는 단일 기능을 개발할 것을 추천한다. 처음에는 아무리 작고 제한적인 기능밖에 만들지 못하더라도 말이다. 이 말은 작업에 필요한 기술을 팀 안에 모두 갖추어야 한다는 뜻이다. 프론트엔드, UI/UX, 서버, DBA, QA 등이 모두 함께 일하는 것이 편안하고 익숙해야 한다.

예광탄 접근 방법을 사용하면 기능의 아주 조그만 부분을 아주 빠르게 개발할 수 있다. 또한 여러분의 팀이 얼마나 잘 소통하고 결과물을 만들어 내는지 즉각적인 피드백을 받을 수도 있다. 그러면 여러분의 팀, 여러분의 프로세스를 빠르고 쉽게 바꾸고 조율할 수 있는 환경이 만들어진다.

Tip 86. 모든 기능을 깆춘 팀을 조직하라.

코드를 끝에서 끝까지 점진적이고 반복적으로 쌓아 올릴 수 있는 팀을 만들어라.

🥕 자동화

일관성과 정확성을 모두 보장하는 확실한 방법은 팀이 하는 모든 일을 자동화하는 것이다.

자동화는 모든 프로젝트 팀에 필수 불가결한 요소다. 도구 제작 역량을 팀 내에 꼭 갖추어서 프로젝트 개발과 서비스 배포를 자동화하는 도구를 만들고 적용하라.

🥕 멈춰야 할 떄를 알라

팀은 개인들로 이루어진다는 사실을 명심하라. 각 팀원이 자신의 방식대로 빛나게 하라. 팀원들을 지원하기에, 그리고 프로젝트가 가치를 만들어 내기에 딱 좋을 만큼의 구조를 제공하라.

🍭 Topic 50. 코코넛만으로는 부족하다

우리가 직접 만나본 팀 하나는 자신들이 스크럼을 사용한다고 주장했다. 하지만 가까이에서 지켜봤더니 그들은 일일 스탠드업 미팅을 일주일에 한 번씩만 하고, 반복 주기는 4주 단위였는데 6주나 8주로 늘어지는 경우가 잦았다. 그런데도 그들은 널리 쓰이는 "애자일" 일정 관리 도구를 사용하니 아무런 문제가 없다고 생각했다. 그들은 피상적인 결과물에만 투자하고 있었다. 심지어는 "스탠드업"이나 "반복 주기"가 마법의 주문이라도 되는 양 그 이름만 그져다 쓰고 있었다. 당연하지만 그들도 진정한 마법을 불러일으키지 못했다.

🥕 맥락의 중요성

스포티파이나 넷플릭스, 스트라이프, 깃랩 등과 같이 성공한 회사의 정책과 프로세스를 다들 앞다투어 도입하고 있다. 각자 나름의 방식으로 소프트웨어를 개발하고 관리한다. 하지만 맥락을 고려해야 한다. 여러분이 동일한 시장과 동일한 제약 조건을 갖고 있고 비슷한 전문성과 조직 크기, 비슷한 경영진, 비슷한 문화를 보유하고 있는가? 사용자층과 요구사항도 비슷한가?

속아 넘어가지 말라. 특정한 결과물, 피상적인 구조나 정책, 프로세스, 방법론만으로는 부족하다.

Tip 87. 유행하는 것이 아니라 실제로 잘 맞는 것을 사용하라.

"잘 맞는 것"을 어떻게 알 수 있을까? 가장 근본적인 실용주의 기법을 적용하면 된다.

한번 해 보라.

작은 팀 하나나 조직 하나에서 아이디어를 시험해 보라. 잘 맞는 것 같은 좋은 부분만 유지하고 나머지는 낭비나 비용일 뿐이므로 버리면 된다. 여러분의 조직이 스포티파이나 넷플릭스와 다르게 운영된다고 해서 깎아내릴 사람은 아무도 없다. 앞으로 수년이 또 지나면 이 회사들이 더 성숙하고, 사업 방향을 선회하고 계속 번성함에 따라 이들 역시 또 다른 방식을 사용하고 있을 것이다.

이것이 이 회사들이 성공한 진짜 비결이다.

🥕 만병통치약은 아무 병도 못 고친다

소프트웨어 개발 방법론의 목표는 사람들이 함꼐 일하는 것을 돕는 것이다.

어떤 특정 방법론에서 가장 좋은 부분만 가져다가 적절히 조정하여 사용해야 한다. 만병통치약은 없고, 현재의 방법론들도 아직 완성되려면 멀었다. 그러니 인기 있는 방법론 하나만 좇지 말고, 다른 것들로도 눈길을 돌려야 한다.

🥕 진짜 목표

진짜 목표는 당연히 "스크럼을 한다"나 "애자일을 한다", "린을 한다" 같은 종류가 아니다. 진짜 목표는 작동하는 소프트웨어를 제공 함으로써 사용자가 즉각적으로 새로운 일을 할 수 있게 되는 것이다. 지금으로부터 몇 주일 후나 몇 달, 몇 년 후가 아니라 지금. 지속적 배포가 이상적이지만 도달 불가능한 목표라고 생각하는 팀이나 조직이 많다. 특히 배포를 몇 달 내지 몇 주에 한 번으로 제한하는 프로세스를 따르고 있다면 더 그럴 것이다.
하지만 모든 목표가 그렇듯 계속 올바른 방향으로 바라보는 것이 중요하다.

제품을 몇 년에 한 번꼴로 출리하고 있다면, 주기를 몇 달에 한 번으로 줄리도록 노력해 보라. 몇 달에서 또 몇 주로 줄여 보라. 4주 단위 스프린트를 2주로 줄여 보라. 2주에서 1주로도 줄여 보라. 그리고 하루로, 마지막으로는 필요할 때마다 출시하는 것을 목표하라. 필요할 때마다 출시한다는 것이 끊임 없이 1준에 한 번씩 배포한다는 뜻은 아니다. 사용자가 필요로 할 떄마다, 사업적으로 배포가 의미 있을 때마다 배포하는 것이다.

Tip 88. 사용자에게 필요할 때 제공하라.

이런 지속적 개발을 도입하려면 매우 견고한 기반 구조가 필요하다. 기반 구조가 갖춰지고 나면 작업을 어떻게 진행할지 결정해야 한다. 초심자라면 프로젝트 관리는 스크럼을 시작하고, 익스트림 프로그래밍의 기술 실천 방법을 추가로 도입할 수 있다. 더 경험이 많고 단련된 팀이라면 칸반이나 린 기법을 살펴볼 수 있다. 둘 다 팀 혹은 더 큰 조직 관리 문제를 다루기 좋다.

하지만 우리 말을 곧이곧대로 받아들이지는 말라. 직접 이런 접근 방법들을 조시하고 시도해 보라. 하지만 지나치지 않도록 주의하라. 특정 방법론에 과도하게 투자하면 다른 대안을 보지 못하게 될 수도 있다. 한 가지 방식이 너무 굳어져 버리면 더 이상 빠르게 적응할 수 없게 된다.

🍭 Topic 51. 실용주의 시작 도구

빌드와 릴리즈 과정이건, 테스트나 프로젝트 서류 작업이건, 혹은 프로젝트에서 거듭 발생하는 다른 어떤 작업이건 간에 일상적인 작업은 모두 자동화해야 한다. 그래서 지원되는 모든 컴퓨터에서 반복 수행할 수 있어야 한다.

🥕 버전 관리로 운용하라

프로젝트를 빌드하는데 필요한 모든 것을 버전 관리하에 두어야 한다. 이는 프로젝트 전체의 관점에서 보면 더 중요하다.

프로젝트 차원에서는 버전 관리 시스템이 빌드와 릴리즈 프로세스를 운용한다.

Tip 89. 버전 관리 시스템으로 빌드, 테스트, 릴리즈를 운용하라.

버전 관리 시스템의 커밋이나 푸시로 빌드와 테스트, 배포가 시작된다. 빌드는 클라우드의 컨테이너 위에서 돌아간다. 테스트를 위해 스테이징 서버에 배포할지 실제 서비스에 릴리즈할지는 버전 관리 시스템의 태그를 사용하여 지정한다. 릴리스 절차가 훨씬 더 간단해져서 일상의 일부가 된다. 빌드 장비나 개발자의 장비에 의존하지 않는 진정한 지속적 배포가 가능해진다.

🥕 가차 없고 지속적인 테스트

많은 개발자들이 무의식적으로 코드가 어디에서 꺠지는지 파악하고서는 약한 지점을 피해 다니면서 살살 테스트하려 한다. 실용주의 프로그래머들은 다르다. 우리는 지금 당장 버그를 찾아 나서도록 자신을 몰아세우지만, 덕분에 나중에 다른 사람이 자기 버그를 발견하게 되는 딱한 상황을 피할 수 있다.

Tip 90. 일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라.

코드를 작성하자마자 테스트해야 한다. 우리는 단위 테스트를 작성한다. 아주 많이.

사실, 훌륭한 프로젝트에는 제품 코드보다 테스트 코드가 더 많을 수도 있다. 테스트 코드를 만들기 위해 들이는 시간에는 그 노력만큼의 가치가 있다. 길게 보면 이쪽이 훨씬 더 싸게 먹히며, 결함이 거의 없는 제품을 만드는 꿈이 정말 이루어지기도 한다.

그에 더해서, 테스트를 통과했다는 것은 그 코드가 "완성"되었다는 말에 높은 수준의 확신을 준다.

Tip 91. 모든 테스트가 끝날 때까지는 코딩이 끝난 게 아니다.

자동 빌드가 모든 가용한 테스트를 수행한다. "진짜 상황 테스트"를 목표로 하는 것이 중요하다. 즉, 테스트 환경은 실제 환경과 최대한 비슷해야 한다. 두 환경의 차이에서 버그가 번식한다.

빌드 과정에는 소프트웨어 테스트의 몇 가지 주요 유형이 들어가야 한다. 단위 테스트, 통합 테스트, 유효성 평가 및 검증, 성능 테스트가 그것이다.

하지만 이것만 갖춘다고 절대 완벽한 것은 아니다. 몇몇 특별한 프로젝트에는 이 외에도 다른 종류의 테스트가 필요할 것이다. 하지만 이 목록은 훌륭한 출발점이 된다.

단위 테스트

단위 테스트는 하나의 모듈을 테스트하는 코드다. 부분으로 떼어 놓았을 때 제대로 작동하지 않는다면 합쳤을 때도 역시 제대로 작동하지 않을 것이다. 다음 단계로 넘어가기 전 여러분이 사용하는 모든 모듈의 단위 테스트가 반드시 통과해야 한다. 일단 관련 모듈이 모두 각각의 개별 테스트를 통과하고 나면 다음 단계로 넘어갈 준비가 된 것이다. 모든 모듈이 시스템 전체에 걸쳐 어떻게 사용되고 상호 작용하는지 테스트해야 한다.

통합 테스트

통합 테스트는 프로젝트를 구성하는 주요 서브시스템이 다른 부분과 제대로 작동하는지 보여준다. 계약이 제대로 되어 있고 테스트가 잘 되어 있다면, 어떤 통합 문제든 쉽게 발견할 수 있다.
통합테스트는 앞서 설명한 단위 테스트의 확장에 지나지 않는다. 단지 전체 서브시스템들이 모두 계약을 제대로 지키는지 테스트하는 것뿐이다.

유효성 푱가 및 검증

시스템의 기능적 요구 사항을 충족하는가? 이것 역시 테스트해 봐야 한다.
버그가 없는 시스템일지언정 잘못된 문제를 푼다면 별 쓸모가 없다. 최종 사용자의 접근 방식에 대해, 그리고 그것이 개발자의 테스트 데이터와 어떻게 다른지에 대해 관심을 기울여라.

성능 테스트

소프트웨어가 실세계 조건에서 성능 요구 사항들을 준수하는지 자문해 보라. 예상하는 사용자 수나 접속 수 혹은 초당 트랜잭션 숫자를 염두해 두고 말이다. 감당 가능한가?

테스트를 테스트하기

우리는 완벽한 소프트웨어를 작성할 수 없기 때문에, 완벽한 테스트 소프트웨어 역시 작성할 수 없다. 그렇다면 테스트를 테스트할 필요가 있다.

어떤 버그를 감지해 내는 테스트를 작성한 후에, 그 버그가 의도적으로 생기도록 한 다음 테스트가 경보를 울리는지 확인하라. 이렇게 하면 실제로 버그가 생겼을 때 테스트가 그걸 잡아낼 것이라고 확신할 수 있다.

Tip 92. 버그를 심어 놓고 테스트를 테스트하라.

정말 진지하게 테스트해 보고 싶다면 소스 트리에서 별도의 브랜치를 하나 만든 다음 고의로 버그를 심어 놓고 테스트가 잡아내는지 검증하라. 테스트를 작성할 떈 경보가 필요할 때 정말 울리는지 확인하라.

철저한 테스트

일단 테스트가 올바르다는 확신이 들고 여러분이 만들어 넣은 버그도 찾아냈더라도, 코드 전체를 필요한 만큼 철저하게 테스트했다는 것은 어떻게 알 수 있을까?

한마디로 답하자면 "알 수 없다." 그리고 앞으로도 알 수 없을 것이다. 어쩌면 커버리지 분석 도구를 적용해 볼지도 모르겠다. 커버리지 분석 도구는 테스트 중에 코드를 지켜보면서 코드의 어느 줄이 실행되지 않았는지 알려준다. 이런 도구들 덕에 여러분의 테스트가 얼마나 포괄적인지 대략적인 느낌을 얻을 수 있다. 하지만 100% 커버리지를 기대하지는 말라.

우연히 코드의 모든 줄이 실행될지라도 그게 전부가 아니다. 정말로 중요한 것은 프로그램이 갖는 상태의 개수다. 상태의 수는 코드 줄 수와 동등하지 않다. 프로그램의 모든 가능한 상태를 확인해야 할 것이다. 불행히도 일반적으로 이것은 정말 어려운 문제다.

Tip 93. 코드 커버리지만 올리지 말고 상태 조합을 테스트하라.

속성 기반 테스트

여러분의 코드가 예상치 못한 상태를 어떻게 다루는지 탐험하기 위해 컴퓨터가 그런 상태들을 생성하도록 하면 좋을 것이다.

테스트하려는 코드의 계약과 불변식에 따라 테스트 데이터를 생성하는 "속성 기반" 테스트 기법을 사용하라.

🥕 그물 조이기

버그가 기존 테스트의 그물을 빠져나갔다면 다음번에는 그걸 잡아낼 수 있도록 새 테스트를 추가해야 한다.

Tip 94. 버그는 한 번만 잡아라.

한번 인간 테스터가 버그를 찾았다면 더는 인간 테스터가 그 버그를 만나서는 안 된다. 그 순간 이후로는 무조건, 매번, 예외 없이, 아무리 사소해도, 개발자가 "그런 상황은 절대 또 일어날 리 없습니다."라고 불평을 하더라도, 해당 버그를 확인할 수 있게 자동화 테스트를 수정해야 한다.

왜냐면 그런 일은 앞으로 다시 일어날 것이기 때문이다. 게다가 우린 자동화 테스트가 우리를 대신해 찾아 줄 수 있는 버그까지 쫓아다릴 시간이 없다. 우리는 새 코드를 작성하는 데 시간을 쏟아야 한다.

🥕 전체 자동화

Tip 95. 수작업 절차를 사용하지 말라.

사람들은 컴퓨터처럼 같은 일을 반복할 수 없을뿐더러 그런 것을 기대해서도 안 된다. 모든 것이 자동화에 의존한다. 빌드 전체가 자동화되어 있지 않다면 임의의 클라우드 서버에서 프로젝트를 빌드할 수 없을 것이다. 수작업 단계가 끼어 있다면 자동 배포를 할 수 없을 것이다. "딱 이거 하나만..."이라는 생각으로 수작업 단계를 넣는다면 아주 커다란 창문을 깨트리는 것이다.

버전 관리, 가차 없는 테스트, 전체 자동화라는 세 기둥이 있다면 여려분의 프로젝트에 필수적인 견고한 기반이 생긴 것이다. 이제 여러분은 어려운 부분에 집중할 수 있다. 바로 사용자를 기쁘게 하는 것이다.

🍭 Topic 52. 사용자를 기쁘게 하라

개발자로서 우리의 목표는 사용자를 기쁘게 하는 것이다. 그래서 우리가 여기 있는 것이다. 사용자의 데이터를 캐내거나, 마케팅에 노출된 고객 수를 세거나, 사용자의 지갑을 탈탈 터는 것은 우리의 목표가 아니니 사악한 목표는 제쳐 두자. 작동하는 소프트웨어를 제때 제공하는 것만으로는 부족하다. 그것만으로는 사용자를 기쁘게 할 수 없다.

여러분의 사용자가 진짜로 원하는 것은 코드가 아니다. 그들에겐 자신의 목적과 예산에 맞추어 풀어야 하는 사업상의 문제가 있다. 그리고 여러분의 팀과 일하면서 문제를 풀어낼 수 있으리라 믿는다.

여러분의 사용자가 기대하는 것은 소프트웨어와 관련이 없다. 여러분에게 주는 명세에 들어 있지도 않다.

그러면 어떻게 사용자들이 기대하는 것을 밝혀낼 수 있을까? 단순한 질문을 던져라.

이 프로젝트가 끝나고 한 달 후에 우리가 성공했는지 어떻게 알 수 있을까요?

대답을 들으면 여러분은 아마 놀랄 것이다. 제품 추천을 개선하는 프로젝트라도 실제로는 고객 잔존율로 성공을 판단할 수 있다. 두 데이터베이스를 통합하는 프로젝트는 데이터의 품질로 판단할 수도 있고, 절감한 비용으로 판단할 수도 있다. 어쨌든 소프트웨어 프로젝트 자체가 아니라 이런 성공 척도가 진짜로 의미 있는 사업 가치다. 소프트웨어는 이런 목적을 달성하기 위한 수단일 뿐이다.

이렇게 숨겨져 있던 프로젝트 배후의 가치에 대해 사용자가 기대하는 바의 일부가 수면 위로 올라 왔다면, 비로소 이런 기대를 어떻게 충족시킬 수 있을지 고민을 시작할 수 있다.

• 모든 팀 구성원이 사용자가 기대하는 바를 완전히 이해해야 한다.
• 결정을 내릴 때면 어떤 선택이 사용자의 기대에 더 가깝게 가는 길인지 생각하라.
• 이런 기대를 염두에 두고 사용자 요구 사항을 비판적으로 분석하라. 요구 사항을 바꾸면 프로젝트가 목표에 더 가까워진다는 것을 보여줄 수 있는가? 그렇다면 주저하지 말고 바꾸자고 제안하라.
• 프로젝트를 진행하면서도 계속 사용자의 기대에 대하여 생각하라.

도메인에 대한 우리의 지식이 늘어남에 따라 근본적인 사업 문제를 해결하기 위해 우리가 맡지 않은 다른 부분에 대해서도 더 좋은 제안을 할 수 있게 된다. 사업의 여러 부분을 함께 엮어낼 방법을 개개의 부서에서는 알아차리기 힘들다. 우리는 조직의 여러 측면을 경험한 개발자가 이런 방법을 더 잘 찾아낼 수 있다고 굳게 믿는다.

Tip 96. 사용자를 기쁘게 하라. 그저 코드만 내놓지 말라.

여러분의 고객을 기쁘게 하고 싶다면 고객이 문제를 풀 때 적극적으로 도와줄 수 있는 관계를 구축하라. 여러분의 직함이 명목상으로는 "소프트웨어 개발자"나 "소프트웨어 엔지니어" 비슷한 이름일지 몰라도 진정한 여러분의 직함은 "문제 해결사"다. 이것이 우리가 하는 일이고, 실용주의 프로그래머의 본질이다.

우리는 문제를 해결한다.

🍭 Topic 53. 오만과 편견

실용주의 프로그래머는 책임을 회피하지 않는다. 그 대신 도전을 수용하고 자신의 전문성이 널리 알려지는 것을 기뻐한다. 설계 혹은 코드만 맡는다면 자신이 보기에 자랑스로운 작품을 만들어 낼 것이다.

Tip 97. 자신의 작품에 서명하라.

어떤 프로젝트에서는 코드 소유권이라는 발상 때문에 협력에 차질이 빚어질 수도 있다. 사람들은 자신의 영도를 지키려 하고, 공통의 기반이 되는 요소에 대해서는 협력을 꺼릴 수 있따. 프로젝트는 서로 담을 쌓은 작은 영토들로 조각나 버릴 수도 있다. 자신의 코드만 좋게 보고 동료들의 코드를 깎아내리는 편견을 갖게 된다.

이는 우리가 원하는 바가 아니다. 경계심 때문에 여러분의 코드를 참견하는 사람으로부터 방어하려고 해서는 안 된다. 같은 맥락에서, 다른 사람의 코드를 존중해야 한다. 이 팁이 효과를 보려면 개발자 사이에 황금률과 상호 존중이라는 기반이 꼭 필요하다.

익명성은 특히 큰 프로젝트에서 적당주의나 실수, 태만, 나쁜 코드의 온상이 될 수 있다. 이렇게 되면 훌륭한 코드를 작성하는 대신 끝없는 상황 보고 속에서 어설픈 변명만 내뱉는 거대한 기계의 부속품으로 전락하게 될 것이다.

코드에는 주인이 있어야 하지만 꼭 개인일 필요는 없다. 실제로 켄트 백의 익스트림 프로그래밍에서는 코드의 공동 소유권을 제안한다.
우리는 소유권에 대한 긍지를 보고 싶다. "내가 이걸 만들었고, 내 작품의 품질을 보증합니다." 여러분의 서명이 품질의 보증 수표로 인식되게 해야 한다. 사람들이 코드에 붙은 여러분의 이름을 보고 그것이 튼튼하고 잘 작성되었으며 제대로 테스트되었을 뿐 아니라 훌륭히 문서화되었을 것이라고 기대하도록 만들자. 전문가가 만든 진정으로 전문가다운 결과물.

실용주의 프로그래머.