클라우제비츠는 저서 전쟁론에서 마찰을 군사 이론과 현실 사이의 차이로 정의한다:

그러므로 전략에서는 모든 것이 매우 단순하지만, 그렇다고 해서 매우 쉬운 것은 아니다. 전쟁에서는 모든 것이 매우 단순하지만, 가장 단순한 것조차 어렵다. 이러한 어려움들이 쌓여 마찰을 만들어내는데, 전쟁을 직접 보지 못한 사람은 그 마찰을 정확히 상상할 수 없다.

[마찰]의 한 예로 날씨를 들어보자. 여기서는 안개 때문에 적이 제때 발견되지 못하고, 포대가 적절한 순간에 사격하지 못하며, 보고서가 장군에게 도달하지 못한다. 저기서는 비 때문에 대대 하나가 도착하지 못하고, 또 다른 대대는 제시간에 도달하지 못한다. 3시간이면 될 행군이 어쩌면 8시간이 걸렸기 때문이다. 기병은 진창에 깊이 빠져 효과적으로 돌격할 수 없다.

이 글을 읽은 이후로 나는 소프트웨어 개발의 모든 곳에서 “마찰”을 보게 되었다:

• 벤더의 API가 생각했던 대로 동작하지 않거나, 원래는 잘 동작했는데 업체가 바꿔버린다.
• 버그. 보안 경고. 의존성을 업데이트했더니 뭔가가 고장 난다.
• 누군가 아프다. 누군가의 아이가 아프다. 누군가 회사를 떠난다. 누군가 버닝맨에 가려고 떠난다.
• 요구사항이 불분명하거나, 개발 도중에 클라이언트가 원하는 것을 바꾼다. 클라이언트가 원하는 것을 개발이 끝난 후에 바꾸기도 한다.
• 노트북이 고장 나거나 도난당한다. Slack이 하루 종일 먹통이 된다.
• 툴이 고장 난다. Word가 모든 글꼴을 wingdings로 바꿔버린다. (실제로 있는 일이다)

이 목록은 일부에 불과하며, 마찰의 모든 원인을 빠짐없이 정리하는 것은 불가능하다.

마찰의 몇 가지 특성

마찰은 시간 범위가 길고 규모가 클수록 더 중요해진다. 단순히 더 많은 것이 잘못될 수 있기 때문이다.

마찰은 스스로 증폭된다. 두 번의 차질은 한 번의 차질보다 두 배 이상 나쁘다. 대부분의 시스템은 적어도 어느 정도는 회복력이 있어서 한 문제를 둘러가며 적응할 수 있지만, 바로 그 때문에 다음 문제를 처리하기가 더 어려워지기 때문이다.

(이는 논란이 많은 “금요일에는 배포하지 마라”는 원칙과 관련된 요인 중 하나다. 배포 중 실수나 롤백이 필요해지는 상황에서 생기는 마찰은, 주말 동안 사람들이 자리를 비우면서 생기는 마찰 때문에 훨씬 더 심각해진다. 논란은 “그러니 하지 마라”고 말하는 쪽과 프로세스에 대한 시스템적 변화를 주장하는 쪽 사이에 있다. 어느 쪽이든 목표는 마찰이 문제를 일으키지 않도록 하는 것이고, 논쟁은 정확히 어떻게 그렇게 할 것인가에 대한 것이다.)

마찰을 해결하려는 시도가 오히려 다른 마찰을 만들어내기도 한다. 예를 들어 보안 경고를 해결하려고 의존성을 업데이트했는데 새 버전이 미묘하게 하위 호환되지 않는 경우처럼 말이다. 그리고 다른 시간대에 사는 동료와 함께 이걸 고치려고 한다면…

마찰에 대처하기

마찰은 피할 수 없고 완전히 제거하는 것도 불가능하다. 완전히 예측하는 것조차 불가능하다고 생각한다. 하지만 마찰을 줄이기 위해 할 수 있는 일들은 있고, 계획이 마찰에 더 잘 견디도록 만들 수도 있다. 군사 계획자들이 마찰을 어떻게 줄이는지는 잘 모른다. 내가 소프트웨어에서 본 방법들은 다음과 같다:

더 작은 범위와 더 짧은 반복

이것이 “waterfall” 대신 “agile”을 정당화하는 논리다. 타임라인이 짧으면 마찰이 증폭될 여지가 줄어든다. 하는 일이 많고 타임라인이 길수록 불확실성이 커지고 잘못될 수 있는 지점이 많아진다. 다만 작은 스프린트를 연달아 계속한다면 여전히 마찰의 여지는 있다. 그건 그냥 비효율적인 마라톤을 뛰는 셈이다.

더 많은 자율성

마찰은 모델과 현실 사이의 차이이며, 높은 관점에서는 모델만 볼 수 있다. 사람들에게 현장에서 현명한 판단을 내릴 만큼 충분한 자율성이 있다면, 마찰에서 더 쉽게 회복할 수 있다. 하지만 자율성이 너무 많아 고립되기 시작하면 상황은 훨씬 더 나빠질 수 있다. 나는 자율성이 높은 엔지니어가 “너무 느리다”는 이유로 데이터베이스를 삭제해 버리는 것을 본 적이 있다.

중복성

보관 중인 예비 장비, 높은 bus factor, 일정에 여유를 두는 것 등이 여기에 해당한다. 그러면 뭔가 잘못됐을 때 더 빨리 고칠 수 있어, 다른 문제가 겹쳐 증폭될 여지를 줄인다. 대신 평상시에는 효율성이 떨어진다는 대가가 따르기 때문에, 프로젝트는 자연스럽게 중복성을 줄이는 방향으로 흘러가게 된다.

더 나은 계획

좋은 계획이 마찰의 모든 원인을 찾아내지는 못하지만, 더 많은 원인을 찾아낸다는 것만으로도 큰 이점이 된다. 예를 들어 정형 명세를 작성하면 설계의 문제를 드러내거나 unknown-unknowns를 known-unknowns로 바꿔 (그 다음 더 자세히 연구할 수 있게 된다) 놓을 수 있다. 5가지 일에 불시에 당하는 것과 15가지 일에 불시에 당하는 것의 차이일 수 있다. 그래서 나는 정형 기법에 그토록 낙관적이다.

자동화

이건 양날의 검이다. 한편으로는 프로세스를 자동화하면 사람이 실수할 여지가 줄어든다. 다른 한편으로는 자동화된 프로세스 자체에 버그가 있을 수 있고, 그게 또 다른 마찰을 만든다. 또 자동화가 오래 실행되면 사람들은 그게 어떻게 동작하는지, 정확히 무엇을 하는지 잊어버리게 되고, 결국 고장 났을 때 아무도 제대로 대처하지 못하게 된다. 자동화는 경험의 상실이라는 대가를 치를 수 있다.

경험

더 많은 문제를 겪어볼수록 다가오는 문제를 더 잘 예측할 수 있고, 문제를 복구해본 경험도 더 많아진다. 안타깝게도 이건 대부분 힘들게 배워야 하는 것이다. 하지만 지름길이 하나 있는데, 바로…

게이밍

이와 관련해 흥미로운 책으로 미 해군대학의 Fundamentals of War Gaming이 있다. 이 책에서는 워게이밍의 목적이 두 가지라고 주장한다. 상황이 어떻게 전개될 수 있는지에 대한 정보를 수집하는 것, 그리고 지휘관에게 안전한 환경에서 (어느 정도의) 경험을 제공하는 것이다. 훈련생이 워게임에서 “날씨가 계획을 망칠 수 있다”는 걸 배운다면, 실제 인명을 걸고 그걸 배울 필요가 없다. 마찬가지로, 나는 날려버린 테이블을 필사적으로 복구해야 하는 상황이 아닐 때 데이터베이스 백업을 복구하는 연습을 하고 싶다. 내가 알기로 보안팀과 운영팀 모두 이런 이유로 게이밍을 활용한다.

(동시에, 게임을 실행하고 참여하는 데 시간을 써야 한다는 점에서 중복성을 추가하는 것과 마찬가지로 비효율적이다.)

체크리스트와 런북

특정 문제를 다루는 암묵지를 형식화하는 방법이다.

마찰에 대해 내가 가진 질문들

마찰의 원인을 하위 범주로 나누는 것이 유용한가? 툴링 문제를 “사회적” 마찰이 아닌 “기술적” 마찰이라고 부르는 것이 우리에게 실질적으로 도움이 되는가?

다른 분야는 마찰을 어떻게 다루는가? 건설 업계 사람들에게 마찰에 대해 물어보니 개념 자체는 이해했지만 그걸 가리키는 단어는 없다고 했다. 이벤트 플래너, 간호사, 군 장교는 어떨까?

“X를 하면 마찰의 영향을 줄일 수 있다”와 “당장은 X를 하지 않는 것이 더 효율적이다” 사이에서 올바른 균형을 어떻게 찾을 수 있을까?

마찰은 개인에게도 중요한가? 팀의 다른 누구도 마찰을 생각하지 않더라도, 내가 프로젝트에서 마찰을 고려하는 것만으로 이득을 얻을 수 있는가?

Jimmy Koppel에게 피드백을 주셔서 감사합니다. 이 글이 마음에 들었다면 내 뉴스레터에 가입해 주세요! 매주 새로운 에세이를 올립니다.

나는 기업을 대상으로 정형 기법을 교육해 소프트웨어 개발을 더 빠르고, 더 저렴하고, 더 안전하게 만듭니다. 더 자세한 내용은 여기에서 확인하세요.

업데이트 2024-05-30

이 글에 대해 받은 댓글 중 일부를 여기에 모아 두었습니다.