모든 마찰이 같은 것은 아니다

Source: Dev.to

Introduction

최근 AI가 코드를 작성하는 데서 마찰을 없애고 개발 속도를 높인다는 내용의 글이 많이 올라옵니다. 하지만 마찰이 항상 나쁜 것일까요?

Friction in Software Development

개인적인 관점에서 로켓이 충돌했을 때 쉼터 벽이 제공하는 마찰은 좋은 마찰이라고 할 수 있습니다. 덜 극적인 예를 들어보겠습니다.

Git이 등장하면서 소스 코드를 관리하는 방식이 바뀌었습니다. 누구나 로컬에서 브랜치를 만들 수 있게 되어 브랜치를 만드는 것이 간단하고 저렴해졌으며, 병합도 쉬워졌습니다. 여러 개발자가 동시에 같은 코드를 작업할 수 있게 되었습니다. 중앙 버전 관리 시스템이 부과하던 많은 마찰이 사라져서 변경 사항이 메인 코드베이스에 도달하는 속도가 빨라졌습니다.

그러한 변경 사항에 대한 가시성과 제어권을 되찾기 위해 우리는 새로운 의도적인 마찰 지점을 도입했습니다: Pull Requests. PR을 통해 변경 사항은 병합되기 전에 보이게 됩니다. 다른 사람이 리뷰를 하고, 토론이 이루어지며, CI 게이트가 실행될 수 있습니다. PR은 최종 단계의 속도를 의도적으로 늦춤으로써 가시성과 제어권을 회복하게 합니다.

Good vs. Bad Friction

• Bad friction은 노력 때문에 우리를 느리게 합니다: 보일러플레이트 코드를 작성하거나, 환경을 설정하거나, 반복 작업을 하는 경우 등. 이러한 마찰을 없애면 속도가 개선됩니다.
• Good friction은 제어, 안전 또는 정확성을 유지하기 위해 의도적으로 도입됩니다. 예시로는 PR, 배포 게이트, 제어된 릴리즈, 피처 플래그, 그리고 타입 체크 등이 있습니다.

흥미로운 점은 “나쁜” 마찰이 사라지고 속도가 빨라지면, 사물이 통제 불능 상태가 되는 것을 방지하기 위해 새로운 “좋은” 마찰을 도입해야 하는 경우가 많다는 것입니다.

AI and the New Friction Landscape

우리는 AI가 코드를 작성하는 마찰을 크게 줄여 개발 속도를 높이는 현상을 목격하고 있습니다. 하지만 위험이 사라지는 것은 아닙니다. 이제 우리는 새로운 속도에 맞추어 가시성과 신뢰성을 회복할 수 있도록 새로운, 그리고 정교한 마찰을 도입하는 방법을 찾아야 합니다.

Conclusion

모든 마찰이 동일한 것은 아닙니다. 어떤 마찰은 진행을 방해하고, 다른 마찰은 필수적인 안전 장치를 제공합니다. 특히 AI와 같은 도구가 발전함에 따라, 불필요한 마찰을 제거하는 동시에 목적 있는 마찰을 도입하여 개발을 빠르고 신뢰할 수 있게 유지하는 균형을 맞춰야 합니다.