tidy first 18장 '코드 정리의 일괄 처리량' 를 읽고

비용 관리

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

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

신뢰 형성

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

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

경험을 통한 예측 가능성

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

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

여유와 배려

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

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