들어가기에 앞서...

그 동안 블로그 글을 너무 쓰지 못했다. 일 아니면 휴식모드만 번갈아가면서 하다보니 일 능률은 좋아졌지만 그때 그때 느꼈던 경험들을 문서화 하지 못한게 아쉬웠다. 멋진 깨달음들을 더 잊어버리기 전에 지금이라도 빨리 다시 벨로그를 쓰기 시작해야겠다고 느꼈다!

그 첫번째로 어자일한 개발을 방해했던 야크 쉐이빙 (Yak Shaving)과 카고 컬팅(Cargo Cult)에 대해서 다뤄보겠다! 굉장히 자주 사용하는 용어이며, 그만큼 개발 중 자주 발생하는 상황이다.

📍Yak Shaving

Yak Shaving은 무엇인가??

이 사이트에 야크 쉐이빙의 실제 예시가 잘 나와 있다. 요약해서 설명하자면 아래와 같다:

• 봄이 왔으니 세차를 해야 겠네.
• 이런 호스가 겨우내 터졌네. 새거를 하나 사야겠군.
• 호스를 사러 마트에 가려면 차에 넣을 기름이 필요한데.. 옆 집 우현이한테 빌려야겠다.
• 그런데 아들이 우현이한테서 보이스카웃에 가려고 베개를 빌려갔었는데...
• 우현이는 빌려간 베개를 돌려주기 전까지는 기름을 안 빌려 주겠지?
• 음 그런데 베개에 있는 야크(물소) 털이 많이 빠져서 지금 당장 돌려줄수가 없는네...
• 베개에 넣을 야크 털을 구해서 베개를 고쳐야지!
• 그래! 세차를 하기 위해 동물원에 가서 야크 털을 깎자!

굉장히 우스운 우화다. 위 우화를 바탕으로 야크 쉐이빙을 개인적으로 이렇게 정의 내리고 싶다:

어떤 목적을 달성하기 위해 의식의 흐름에 몸을 맡기다 보면 전혀 생각하지 못한 일을 하게 되는 것

조금만 주의하면 개발할 때 쉽게 피해갈 수 있을 거라고 생각하지만 실제로는 야크 쉐이빙의 경계는 굉장히 모호하기 때문에 참 어려운 문제다. 실제로 겪었거나 겪을 뻔 했던 예시들을 포함해서 몇가지를 보여주고 싶다.

야크 쉐이빙의 예시

1. 프로젝트 방향성 회의

프로젝트를 시작할 땐 괜찮은 아이디어 같아 보였는데 막상 개발을 하다보니까 '이 제품이 소비자들의 문제를 해결해줄 수 있을까?' 라는 질문이 들었다. 그래서 우리 제품의 본질에 대해서 팀원들과 회의를 했다. 회의를 통해 새로운 킥이 필요하다는 결론이 났다. 그래서 새로운 킥을 브레인 스토밍하는 회의를 했고, 이 중에서 어떤 것을 우리 서비스에 적용할지 결정 하는 회의를 했다. 새롭게 바뀐 서비스를 현재 플래닝에 어떻게 적용할 지 다시 한번 회의를 했고, 하다 보니 원래 그렸던 그림과 전혀 다른 그림을 그리고 있었다.

2. 이벤트 핸들링 문제

(실제론 쉽게 해결할 수 있지만 예시를 위해 간단한 상황을 설정했다)
유저가 노트를 작성할 수 있는 메모장 앱을 만든다고 하자. 헌데, 유저가 메모를 작성하지 않은 상태와 유저가 메모에 아무것도 쓰지 않고 저장한 경우를 구분할 수 없는 문제가 생겼다. 팀원들은 이 문제를 해결하기 위해 빈 메모를 확인할 수 있는 로직과 api를 새로 만들고, 테스팅 하고, 앱에 적용했다. 애초에 빈 칸을 받지 않으면 되는데...

결론

나름 잘 예시를 썼다고 생각했는데, 다시 보니까 너무 유치하다... 하지만 실제 필드에서는 잘 일어나는 일이다! 시간과 돈 등 리소스가 여유롭다면 오히려 장기적으로 문제 해결에 도움을 줄 수도 있다.
하지만 그렇게 보이기 때문에 역으로 이 함정에 빠지기 쉬운 것이다!

겉으로 보기엔 프로젝트를 진행하는 데 꼭 필요한 것 같은 요소처럼 보이지만, 막상 하다보면 묘하게 방향성이 점점 틀어지고, 일은 열심히 하는데 성과가 나지 않는다. 일은 열심히 하는 것 같고 힘은 빠지는데 점점 일이 꼬이는 게 야크 쉐이빙의 최악의 특징이다.

이 문제를 돌파하는 것은 의외로 간단하다.

1. 필요한 Feature를 달성하기 위한 가장 간단한 플로우를 만들어서 직접 결과물을 만들어내라!
   그 다음에 평가를 받아라!
2. 회의를 통해서 결론이 날 수 없는 생각들은 모두 제거하고, 일단 움직여라!

호스를 사기위해서 야크 털을 깎지 마라. 애초에 세차를 하고 싶은데 호스가 없으면 양동이로 하고, 양동이도 없으면 호스를 빌려라. 그것도 안되면 버스타고 마트를 가고, 버스까지 안될 때 야크 털을 밀러 가도 늦지 않다.

📍Cargo Cult

Cargo Cult란?

원시 부족이 살던 태평양의 한 섬에 어느 날 비행기가 안착했다. 비행기 안에서 나온 서양인들은 원시 부족에게 생전 본 적 없던 약, 음식, 그리고 신기한 도구들을 나눠줬다. 어느 날 서양인들은 비행기를 타고 다시 돌아갔고, 다시는 약, 음식을 받을 수 없었다. 그 날 부터 원시 부족은 비행기를 닮은 건축물을 나무로 만들고 서양인들과 비슷한 옷을 만들어서 의식을 치루기 시작했다. 그들이 다시 올 그 날을 기다리면서...

원시 부족이 만든 비행기 모양 건축물과 그들의 의식은 실제론 아무런 의미가 없다. 이 것이 바로 화물 신앙, 즉 Cargo Cult다.

즉, 카고 컬트는 보통 아래와 같은 Formal Definition을 가진다.

인과관계를 혼동하여 부차적인 것을 중요한 원인으로 믿는 것

하지만 프로그래머의 관점으로 한가지 말을 더 얹고 싶다.

문제 해결을 위한 본질적인 고민을 하지 않고, 표면 위의 현상만 해결하려는 것

예시

1. 엘리베이터 속도 문제

회사 건물의 엘리베이터가 너무 느린 것 같고 답답하다는 컴플레인을 많이 받은 두 회사가 있었다. 한 회사의 사장은 3000만원과 2달의 엘리베이터 공사를 통해 엘리베이터를 10% 빠르게 만들었고, 다른 한 회사는 모든 층 엘리베이터 문에 거울을 달아서 기다리는 사람들이 자신의 옷매무새와 얼굴을 보게 만들었다. 문제는 엘리베이터의 대기시간이 아니라 엘리베이터를 기다리는 시간에 대한 답답함이었기 때문이다.

2. 벤치 마킹 오류

독서를 도와주는 앱을 만들기 위해서 여러 경쟁 업체들을 조사하다 '트레바리'를 발견했다. 오프라인 독서 모임을 통해서 독서를 장려하는 플랫폼이었고, 너무 좋다고 생각했다! 트레바리를 벤치 마킹해서 여러 기능들을 다듬고 완성본을 보니, '독서'는 안 남고 '모임'만 장려하는 앱이 됐다. ...음?!

결론

야크 쉐이빙과 언뜻 비슷해 보이는 문제다. 둘 다 기저엔 본질이 존재하지 않기에 생기는 문제이기 때문이다. 본질을 인지하고 있다면 가장 빠르고 cheap한 길이 보이지만, 그렇지 않다면 만들려는 상품이 점점 거대해지고 복잡해지기만 한다. '오컴의 면도날'을 적용해보자. 진리라는 것은 뭔가를 더할 수 있는 상태가 아니라 더 이상 뺄 것이 없는 상태이다.

마치며..

프로그래머는 코드를 짜는 사람이 아니라 문제를 해결하는 사람이라는 말을 참 좋아한다. 진정한 프로그래머는 프로그램에 얽매이지 말고 때로는 분위기 조성으로, 때로는 규정으로 문제를 해결해야 한다는 말을 들었다. 옛날 무협지에서 진정한 무림 고수들은 심검합일의 상태를 이뤄서 칼에 얽매이지 않고 맨손으로도 적을 베는 것처럼 뭔가 개쩌는 말 같아서 특히 좋아한다.

"자네.. 벌써 죽어 있지 않은가?"

프로젝트를 시작하는 순간부터 우리는 수많은 유혹과 갈림길을 만난다. 정해진 답은 없기에, 사람마다 야크 쉐이빙과 카고 컬트의 기준은 다르다. 내가 생각하기에 중요한 것과 팀원이 생각하기에 중요한 것이 다르다. 타인의 말을 너무 따르거나 자신의 의견만 고집하면 어느 순간 이상한 곳으로 샐 것이다.

결국 본질을 따라가기 위해선 상호적으로 견제를 하며, 서로가 생각하는 프로젝트의 본질을 부딪히며 정반합을 통해 계속해서 더 나은 길을 향해 나아가야 한다고 생각한다. (물론 젠틀한 방식으로)

모두 즐코~~