그 프레임워크 프레임워크

Source: Dev.to

번역할 텍스트가 제공되지 않았습니다. 번역이 필요한 본문을 알려주시면 한국어로 번역해 드리겠습니다.

이번 전사 회의는 분명히 특별할 것이었다

보통의 슬픈 스낵백 대신 케이터링이 제공되었습니다. 일반적인 파워포인트 타이틀 슬라이드 대신 아름답게 렌더링된 그래픽이 나왔습니다. 큰 무언가가 다가오고 있었습니다; 우리 의자가 감당하기 힘들 정도로 몸을 똑바로 펴게 만드는 그런 큰 무언가 말이죠.

회의가 시작되고 발표가 이루어졌습니다: 고위 경영진이 몇 주 동안 머리를 숙이고 우리 새로운 회사 전략 모델을 구축해 왔다고! 이 모델은 우리 각기 다른 우선순위를 시너지 효과로 결합하고, 교차 기능 이니셔티브를 정렬하며, 전체적인 가치 창출을 추진하고, 핵심 학습을 운영화(그게 무슨 뜻이든)하여 우리의 핵심 역량을 활용함으로써 다시 돌아올 수 있게 한다고…

…음, 요점을 이해하셨을 겁니다.

새로운 전략 모델은 정장을 입은 사람들에게 심장 두근거림을 주는 요소들로 가득했지만, 실제 전략은 전혀 없었습니다. 우리는 사고의 틀은 만들었지만, 생각하는 것을 잊어버렸습니다.

템플릿이 사고를 대체할 때

우리는 프레임워크가 똑똑한 일을 하고 있다는 느낌을 주기 때문에 사랑합니다. 설령 우리가 올바른 문제를 해결하고 있지 않더라도 말이죠.

위대한 모놀리식과 마이크로서비스 논쟁을 기억하시나요? Uber와 Netflix 같은 대규모 기업 몇 곳이 전쟁 이야기를 공개했고, 그 순간 두 명의 개발자와 꿈만 가진 모든 스타트업이 코드를 수백 개의 작은 서비스로 나누기 시작했습니다. 우리는 스스로를 현대적이라고 말했지만, 실제로는 대부분 규모를 흉내 내고 있었을 뿐이었습니다.

그리고 이것은 단순히 아키텍처에만 국한된 이야기가 아닙니다… JavaScript 프레임워크를 떠올려 보세요.

새로운 프레임워크가 약 38초마다 하나씩 등장하고, 각각은 프론트엔드 구축 문제를 마침내 해결해줄 것이라고 약속합니다(마치 그 문제가 순수하게 기술적인 것처럼). 각 프레임워크는 우리에게 위안이 되는 환상을 제공합니다: 올바른 도구만 선택하면 소통, 디자인, 타협 같은 복잡한 인간적인 요소들이 사라질 것이라는 것이죠.

하지만 실제로는 그렇지 않습니다. 절대 그렇지 않죠, 문제는 프레임워크가 아니라 그 안에서 구원을 찾으려는 우리 자신의 욕구에 있습니다. 프레임워크가 사려 깊은 사고를 대신하게 되면 우리는 결국…

게다가… 실제로 존재하지 않는 패턴을 보는 것은 약간 음모론자들의 영역처럼 보이지 않나요? 👽😱

프로세스가 목적을 압도할 때

지난 세기 말에, 소프트웨어 엔지니어링 팀들은 프로젝트를 전달하는 방식을 거의 확정했습니다… 생각할 수 있는 모든 질문에 답하는 설계 단계, 제품을 구축하는 코딩 단계, 출시를 준비하는 테스트 단계, 그리고 최종 전달 단계.

하지만 그 규칙들은 변하고 있었습니다; 인터넷의 인기가 높아지면서 소프트웨어 제품은 물리적 세계의 제품과 점점 닮지 않게 되었습니다. 더 이상 상자에 담겨 선반에 놓일 필요가 없었습니다. 그래서 2001년 초, 몇몇 실무자들이 모여 소프트웨어를 더 잘 전달하기 위한 새로운 원칙에 합의했습니다.

일부 프로세스 담당자들은 새로운 아이디어가 “구조가 없고 지속 가능하지 않으며 확장성이 없다”는 등 여러 ‘un-’을 붙여 반발했습니다. 시간이 지나면서 새로운 아이디어가 점차 우세해졌고… 결국 “Agile”이 받아들여지는 사고 방식이 되었습니다.

---

그리고 프로세스가 등장했을 때

시간이 지나면서 사람들은 민첩성을 돕기 위한 프레임워크를 만들기 시작했습니다. 조직들은 운영에 대한 방대한 규칙에 익숙했기 때문에 애자일 실천을 도입하는 것을 주저했고, 애자일을 너무 혼란스럽게 느꼈습니다. SAFe(Scaled Agile For Enterprises)와 같은 것이 등장했습니다.

문제는 민첩성의 원래 원칙들이 이러한 구조와 완전히 정반대였다는 점입니다. 애자일 선언문 자체가 이를 말하고 있습니다:

우리는 소프트웨어를 직접 개발하고 다른 사람도 그렇게 하도록 돕는 과정에서 더 나은 방법을 발견하고 있습니다.
이 작업을 통해 우리는 다음을 가치 있게 여기게 되었습니다:

• 프로세스와 도구보다 개인과 상호작용
• 포괄적인 문서보다 작동하는 소프트웨어
• 계약 협상보다 고객 협업
• 계획을 따르는 것보다 변화에 대응하는 것

즉, 오른쪽에 있는 항목에도 가치가 있지만, 우리는 왼쪽에 있는 항목을 더 중시합니다.

실제로 일어나고 있는 일은 사람들이 구조 안에서 편안함을 느낀다는 것입니다. 우리는 모호함을 좋아하지 않으며, 가능한 한 피하려고 합니다.

하지만 바로 그곳이 창의성과 혁신이 번성하는 곳입니다.

프레임워크에 반항하기: 협업을 장인 정신으로

경력 초기에 저는 The Process를 매우 중시하는 사람 밑에서 일했습니다. 모든 것이 매뉴얼대로 정확히 진행되어야 했고, 저는 (다우글라스 애덤스가 The Hitchhiker’s Guide to the Galaxy에서 유명하게 쓴 것처럼) 다음을 해야만 했습니다:

“…세 번 서명된 주문서, 전송, 회신, 질의, 분실, 발견, 공개 조사 대상, 다시 분실, 그리고 마지막으로 3개월 동안 부드러운 이탄에 묻힌 뒤 라이터용 연료로 재활용.”

제 상사는 이런 방식을 고집할 이유가 있었습니다. 그리고 그 이유는 실제로 나쁘지 않았습니다. 문제는 그의 선택이 가져온 심리적 효과였습니다:

• The Process는 사람들을 느리게 만들도록 설계되었습니다.
• 당신이 시스템에 요청을 입력해야 합니다.
• 당신이 절차를 거쳐야 합니다.
• 당신이 절차를 따라야 합니다.

The Process의 각 단계는 도움을 요청한 사람에게 책임을 다시 돌려놓았습니다.

그 결과, 그와 함께 일하고 싶어 하는 사람은 아무도 없었습니다. 그들은 스스로 해결할 수 없는 일에 대해 우리 팀에 도움을 청했지만… 결국 양식을 작성하거나 다른 사소한 일을 하라는 식으로 돌려보내졌습니다.

그가 회사를 떠나고 제가 팀을 인수했을 때, 우리는 큰 사기 문제를 안고 있음을 알았고, 다소 비정통적인 방법을 택했습니다:

전체 프로세스를 없애버렸습니다.

우리의 도움이 필요하신가요? 그냥 연락해서 물어보세요. 양식을 작성하는 데 걸리는 시간의 절반만에 할 수 있는 일을 양식 작성으로 끌어들이지는 않을 겁니다.

우리의 일?

방금 물어본 것을 생각해 보세요. 제가 어떻게 내 일을 문서화할까요? 누군가에게 문서화를 시키는 것이 아니라! 제가 추적해야 할 것이 있다면, 그 책임은 저에게 있습니다.

이렇게 함으로써 우리에게 도움을 요청한 팀들과의 호감도가 크게 상승했습니다. 우리는 서류 작업을 추적하기 위해 유지해오던 전체 시스템을 없앴습니다. 교과서적인 해결책은 아니었지만, 우리 팀의 평판을 엄청나게 회복시키는 데 성공했습니다.

프레임워크가 적절한 경우

분명히 그들에겐 어느 정도 가치가 있기 때문에 존재하는 거죠, 그렇지 않나요? 그렇다면 언제 프레임워크를 만들고, 언제 약간의 혼돈을 허용해야 할까요?

• 프레임워크는 미지와 어울리지 않는다.
  새로운 기술을 탐색하거나 “보통과는 다른” 시도를 할 때는 프레임워크를 만들 필요가 없습니다. 빠르게 방향을 바꾸고 실험할 때 프레임워크가 방해가 되며, 방향이 바뀔 때마다 프레임워크를 재구축하는 것은 비용이 많이 들고 느립니다.

• 프레임워크는 공장 작업을 위한 것이다.
  같은 종류의 작업을 많이 반복한다면, 프레임워크가 설정의 번거로움을 없애고 결과에 집중하도록 도와줍니다.

• 특수부대 vs. 일반 보병.
  프레임워크를 일반 보병에 비유해 보세요—침공은 특수부대가 주도하고, 그들이 발판을 마련하면 일반 보병이 들어와서 확보합니다. 필요하지만 앞장서서는 안 됩니다.

마무리: 당신의 안락 지대의 비용

앞서 언급했듯이: 인간은 구조를 사랑합니다. 그 안에서 안전함을 느끼고, “미지의 것”으로부터 보호받는다고 생각합니다.

그리고 그것은 괜찮습니다.

우리가 여기서 말하는 것은 모든 형태의 구조를 포기하는 것이 아니라, 식별력을 요구하는 호소입니다. 혼란은 존재할 것이라는 것을 깨닫고, 때때로 그 혼란에 뛰어들 준비가 있어야 합니다.

모든 것을 프레임워크로 만들려는 것을 멈추고, 좋은 작업에 집중하세요. 깊은 템플릿화가 필요한 시기도 있고, 그냥 일을 끝내는 시기도 있습니다.