PR의 크기를 줄이자

이번 장에서 병합 비용이라는 단어가 눈이 띕니다.

병합 비용이란 PR 후 머지를 위해 투입하는 시간을 의미합니다.

켄트 벡은 병합 비용을 줄이기 위해 PR 의 크기를 줄이라고 당부합니다. 더하여 개발자가 잦은 PR 에 느끼는 피로감도 잘 표현해준 것 같습니다.

그러나 PR의 크기를 줄일수록 PR의 수가 많아지니 서로 반비례 관계로 볼 수 있습니다.

결론적으로 켄트 벡은 PR의 크기를 줄여 충돌이나 은연중 추가 되는 동작 변경의 위험을 줄이라고 말을 하면서 늘어나는 PR의 수는 팀의 신뢰도의 기반하여 구조변경 PR은 리뷰를 하지 않는 방향을 추천 합니다.

팀에 신뢰와 강력한 문화가 있다면 코드 정리 후에는 굳이 검토할 필요가 없습니다. 검토하지 않더라도 코드 정리가 소프트웨어 안정을 해치지 않으면 상호작용의 위험이 줄어듭니다. - p.84

개인적으로 구조변경 PR은 테스트 코드를 기반으로 충분히 신뢰도를 유지할 수 있다고 생각하기 때문에 충분히 납득 가능한 방향성이라고 생각을 합니다.

비용 관리

코드 변경과 통합은 애플리케이션 개발에서 피할 수 없고, 이 과정에서 적지 않은 비용이 발생합니다. 특히 코드 정리에 대한 검토 비용에 대해 생각해 보았습니다. 경우에 따라 다르겠지만, 변경 된 코드를 리뷰하고 통합하는 데 들어가는 시간과 노력은 결코 무시할 수 없습니다. 이러한 비용을 관리하지 못하면 작업 속도는 의미 없이 느려지고, 불필요한 곳에 에너지를 써서 결국 생산성을 떨어뜨립니다.

이 문제를 조금이라도 해소하려면 코드 작업 단위를 작게 나누고, 자동화 도구 도입으로 프로세스를 최적화하는 것이 필요합니다. 작은 작업 단위는 검토 부담을 줄이고 충돌 가능성을 낮추는 데 효과적이고, 자동화 도구는 반복적이지만 실수할 수 있는 작업을 대신 처리함으로 불필요한 에너지 소모를 줄일 수 있습니다. 테스트 코드와 CI/CD 파이프라인 따위를 활용하면, 변경에 대한 코드 검토 작업을 자동으로 처리할 수 있습니다. 책에서는 비용을 줄이기 위한 하나의 방법으로, 신뢰를 전제로 구조 변경에 대한 검토를 생략하는 것을 제안 하고 있지만, 현실적으로 신뢰가 형성되기까지 적지 않은 시간이 필요하다고 생각하기 때문에 이상향적이라는 생각을 지울 수 없었습니다.

신뢰 형성

검토에 대한 비용을 줄이기 위해서는 서로에 대한 신뢰가 필요합니다. 신뢰가 없다면 동료 코드에 대해 리뷰어 스스로 납득할 때까지 검토하게 되고, 이는 어쩌면 불필요할 수 있는 시간과 비용을 투자하는 환경을 만듭니다. 신뢰는 단순히 오랜 시간 함께 한다고 형성되는 것은 아니라고 생각 합니다. 투명한 의사소통, 책임감 있는 태도, 일관된 행동과 같은 기본적인 것들이 맞물려야 비로소 견고한 신뢰가 형성된다고 생각 합니다.

에릭 에릭슨(Erik Erikson)의 심리사회적 발달 이론에 따르면, 신뢰는 반복적이고 안정적인 상호작용에서 비롯된다고 합니다. 예를 들어 어린 아이가 일관성 있는 피드백을 통해 세상에 대한 신뢰를 쌓는 것처럼, 동료 사이에서도 상호 책임감 있는 행동과 협력적인 태도를 반복적으로 경험함으로 신뢰를 쌓을 수 있습니다. 하지만 신뢰 형성에는 시간이 필요하며, 일반적으로 약 3~6개월이 소요된다고 합니다. 신뢰를 형성하는 데 걸리는 이 시간은 단순히 함께 한 시간을 뜻하지 않고, 협업 과정에서 일관된 피드백을 통해 형성 될 수 있습니다.

경험을 통한 예측 가능성

신뢰는 단순히 동료 간의 관계를 넘어, 작업 결과물에 대한 예측 가능성을 제공하는 기반이 될 수 있습니다. 예측 가능성이란, 경험으로 쌓은 피드백을 통해 어떻게 작업 되었을 지 구체적으로 들여다 보지 않아도 알 수 있음을 뜻합니다. 예를 들어, 특정 동료가 언제나 명확하고 안정적인 코드 스타일을 유지하며, 테스트를 철저히 작성하고, 작업 내역을 체계적으로 기록한다면 그의 작업 결과를 신뢰할 수 있습니다. 이러한 예측 가능성은 코드 정리 과정에서 검토를 생략하거나 간소화할 수 있는 근거가 될 수 있습니다.

예측 가능성이 높은 환경에서는 팀원 간 불필요한 의사소통을 줄이고, 변경에 대한 전반적인 맥락만 공유하면 되므로 생산성이 향상됩니다. 결국, 신뢰를 바탕으로 예측 가능성을 확보하면, 검토 과정에서 발생하는 비용을 줄이고 안정적인 개발 환경을 만들 수 있습니다.

여유와 배려

검토 비용을 포함한 다양한 비용을 줄이려는 이유는 팀에 여유를 제공하기 위함이라는 생각을 했습니다. 여유는 단순히 시간적 여유가 아니라, 코드 작성할 때 배려를 담아낼 수 있는 정신적 여유를 포함합니다. 여유가 없을 때는, 작업자가 퉁명스럽고 불친절한 코드를 작성하기 쉽습니다. 이러한 코드들은 유지보수 단계에서 맥락을 이해하는 데 더 많은 시간을 소모하게 하고, 미래의 작업자에게 “이렇게 변경해도 될까?”라는 불안감을 가져다 줄 수 있습니다. 이는 생산성을 떨어뜨리고, 결과적으로 동료간 신뢰를 넘어 외부에서 바라본 신뢰에도 부정적인 영향을 줄 수 있습니다.

코드에 배려가 담기면, 미래의 동료가 해당 코드를 이해하고 확장하는데 도움이 될 수 있습니다. 이것은 단순히 효율성의 문제가 아니라, 협업 관계에서 인간성을 보존하는 문제라고 생각합니다. 여유가 있는 팀은 더 나은 코드를 작성하며, 그 코드에는 팀원 간의 신뢰와 배려가 녹아 있을 수 있습니다.

할 것인가? 하지 않을 것인가?

켄트 벡은 코드 정리의 일괄 처리량을 비용 측면에서 말하고 있습니다.
동시에 많은 조직에서 코드 검토에 비용을 많이 쓰고 있다고 말합니다.

많은 조직에서 하나의 변경 사항을 검토하고 배포하는 데 드는 고정 비용은 상당히 많습니다.

켄트 벡은 아래와 같이 말을 이어갑니다.

어떤 이들은 이러한 비용 곡선을 개발 세상의 물리 법칙인 양 그저 받아들여야 하는 일로 다룹니다. 하지만 전혀 그렇지 않습니다. 코드 정리 비용을 줄이고자 한다면, 코드 정리 개수를 늘려서 동작 변경에 소용되는 비용을 줄이세요. 그러면 검토 비용을 줄일 수 있습니다.

괴테의 말이 떠오릅니다.

인생은 다음 두가지로 성립된다. '하고 싶지만 할 수 없다' 와 '할 수 있지만 하고 싶지 않다'

켄트 벡은 지난 장(Chapter)들에서 언급했던 것처럼 동료와 신뢰를 쌓아 코드 정리는 굳이 검토할 필요가 없게 만들라고 조언합니다.

여러분과 여러분의 팀은 검토 비용을 제대로 줄일 수 있는 방법을 찾아야 합니다. 팀에 신뢰와 강력한 문화가 있다면 코드 정리 후에는 굳이 검토할 필요가 없습니다. 검토하지 않더라도 코드 정리가 소프트웨어 안정을 해치지 않으면 상호작용의 위험이 줄어듭니다.

그리고 마지막으로 다음과 같이 당부합니다.

코드 정리 검토를 없앨 수준의 안전과 신뢰에 도달하려면, 적어도 몇 달이 걸립니다. 실천하고, 실험하세요. 오류를 팀과 함께 검토하세요.

생각만으로 답을 찾을 수 없습니다. 행동해야 경험적 사고를 할수 있습니다.
시작은 '거울 속의 나'와의 관계 속에서 결심해야 합니다.

할 것인가? 하지 않을 것인가?

한다고 결심했다면
사상을 공유하고 있는 믿을 수 있는 동료를 찾고
공동체를 만들고
함께 실험하여
그 과정에서 시행착오를 통해
우리 만의 "검토 비용을 줄일 수 있는 방법을 찾아야 합니다."

코드 정리는 '얼마만큼' 해야 할까?

제가 권하는 것은 아주 작은 단계로 나누어 코드를 정리하는 방식을 고수하면서 실험해 보는 것입니다. - 17장 일부

최근 10분 제약을 통해 TidyFirst? 를 실천하니
코드 정리가 작아지는 성과를 얻을 수 있었습니다.

작은 코드 정리들을 다음에는 아래와 처럼 질문이 떠올랐습니다.

작은 코드 정리를 언제까지 얼마만큼 해야 하는가?

결국은 코드 정리를 언제 멈춰야 하는지에 대한 질문이었습니다.
켄트 벡은 말합니다.

다음 동작 변경에 도움이 될 만큼만 코드 정리를 하는 것이 좋다.

이제는 동작 변경에 도움이 되는지 스스로에게 매번 물어야겠습니다 :)