커뮤니티의 새로운 소식들을 찾아다니다가 호주의 한 소프트웨어 엔지니어의 블로그 포스트에 쓴 글이 매우 공감되어 포스트에 번역하여 옮겨보았습니다. 소프트웨어 비즈니스에서 어떤 이슈를 결정하는데 있어서 개발 기반이 아닌 결정권자들과 흔히 격는 상황에 대해서 솔직하게 이야기하고 있습니다. 그 사이에 매우 보수적인 또는 진보적인 개발자들 간에 리더에게 의사전달을 하는 방식의 차이도 한국의 상황과 크게 다르지 않아 공감이 되는 부분이 많습니다.
원문의 링크도 공유하겠습니다만, 바쁘신 분들은 번역된 내용으로 봐주셔도 좋을것 같습니다.
원문 링크 : https://www.seangoedecke.com/clarity/
스태프 엔지니어로서 나의 가장 중요한 임무는 조직에 기술적 명확성을 제공하는 것입니다. 물론 프로젝트를 진행하고, 코드를 배포하고, PR을 리뷰하는 등 다른 일도 많이 합니다. 하지만 내가 하는 가장 중요한 일, 즉 내가 존재하는 이유는 기술적 명확성을 제공하는 것입니다.
기술적 명확성이란 무엇인가?
조직에서 기술적 명확성이란, 비기술 의사결정자들이 소프트웨어 시스템에 어떤 변경을 가할 수 있는지에 대해 충분히 실용적인 이해를 갖추고 있는 상태를 말합니다.
소프트웨어 조직을 책임지는 사람들은 소프트웨어에 관한 많은 결정을 내려야 합니다. 전체 전략을 수립하지 않더라도, 어떤 종류의 사용자가 어떤 기능을 사용할지, 어떤 업데이트를 가장 먼저 배포할지, 프로젝트를 지연시킬지 서둘러 진행할지 등을 결정해야 합니다.
이들은 과거에 기술직에 종사했을 수도 있고, 지금도 훌륭한 기술적 사고력을 가지고 있을 수 있습니다. 그러나 내가 말하는 의미에서 그들은 여전히 “비기술적”입니다. 왜냐하면 시스템에 대한 정확한 멘탈 모델을 구축할 시간이나 맥락이 부족하기 때문입니다. 대신 그들은 막연한 멘탈 모델에 의존하며, 신뢰하는 엔지니어들의 조언으로 이를 보완합니다.
멘탈모델?
멘탈모델(mental model)은 어떤 개념이나, 아이디어, 사물, 사건, 현상 등에 대해 개인이 가지고 있는 이해의 틀 혹은 모델을 말합니다
그들의 막연한 멘탈 모델이 정확하고 받는 조언이 좋을수록, 즉 기술적 명확성이 높을수록 합리적인 결정을 내릴 수 있습니다. 따라서 여기에 걸린 이해관계는 매우 큽니다. 조직의 기술적 명확성은 기능적인 엔지니어링 그룹과 완전히 비기능적인 그룹의 차이를 만들 수 있습니다.
기술적 명확성이 드문 이유
조직에서 기술적 명확성의 기본 수준은 매우 낮습니다. 다시 말해, 기술 회사의 의사결정자들은 종종 해당 기술에 대해 절망적으로 혼란스러워합니다. 이것은 그들의 능력에 대한 진술이 아닙니다. 소프트웨어는 정말 복잡하며, 심지어 관련 팀의 엔지니어들조차 자신들이 담당하는 시스템에 대해 대부분의 시간을 절망적으로 혼란스러워하며 보냅니다.
내 경험상 이것은 비엔지니어들에게 놀라운 사실입니다. 하지만 사실입니다! 대규모로 확립된 코드베이스의 경우, 매우 시니어한 엔지니어조차도 자신의 시스템이 어떻게 작동하는지에 대한 아주 기본적인 질문에 명확하게 답하지 못하는 것이 완전히 정상입니다. 예를 들어 “X 유형의 사용자가 Y 작업을 수행할 수 있는가?” 또는 “Z 작업을 수행하면 W 유형의 사용자에게 어떻게 보일까?”와 같은 질문입니다. 엔지니어들은 종종 이러한 질문에 “가서 확인해봐야겠습니다”라고 대답합니다.
구체적인 예시
기술 회사의 VP(Vice President)가 기존의 유료 기능을 무료 계층 사용자의 일부에게 제공하려고 한다고 가정해봅시다. 물론 이 프로젝트와 관련된 대부분의 기술적 질문은 VP와 무관합니다. 하지만 그들이 답을 알아야 하는 일련의 기술적 질문이 있습니다:
- 유료 기능을 현재 상태로 무료 사용자에게 안전하게 제공할 수 있는가?
- 기능을 점진적으로 출시할 수 있는가?
- 문제가 발생하면 사용자 계정을 손상시키지 않고 기능을 되돌릴 수 있는가?
- 테스트(및 기타) 목적으로 사용자의 일부에게 조기 액세스 권한을 부여할 수 있는가?
- 용량 문제가 발생할 경우 유료 사용자에게 우선순위를 줄 수 있는가?
이러한 질문에 대한 답을 찾는 것은 복잡한 기술적 과정입니다. 전체 시스템에 대한 깊은 이해가 필요하며, 일반적으로 관련 코드를 주의 깊게 다시 읽어야 합니다. 개발 환경이나 테스트 계정에서 변경 사항을 시험해볼 수는 없습니다. 왜냐하면 엣지 케이스를 놓칠 가능성이 높기 때문입니다. 테스트 계정에서는 작동할 수 있지만 “조직”의 일부인 사용자나 체험판 플랜에 있는 사용자에게는 작동하지 않을 수 있습니다.
때로는 실제로 작업을 수행해야만 답할 수 있는 질문도 있습니다. 소프트웨어 시스템이 성장함에 따라 서로 놀라운 방식으로 상호작용하는 주변적이지만 수익성 있는 기능들을 구축하여, 시스템이 거의 불가능하지만 완전히 불가능하지는 않은 수준으로 이해하기 어려워집니다. 좋은 소프트웨어 설계는 이러한 복잡성을 길들일 수 있지만 완전히 제거할 수는 없습니다. 숙련된 소프트웨어 엔지니어는 항상 프로덕션에서 문제로 변할 수 있는 상호작용을 놓치고 있는 것은 아닌지 의심합니다.
공식 및 비공식 기술 고문
VP나 프로덕트 리더에게 소프트웨어 시스템의 복잡성을 헤쳐 나가는 데 도움을 줄 수 있는 엔지니어와 함께 일하는 것은 엄청난 안도감을 줍니다. 내 경험상 이러한 “기술 고문” 역할은 일반적으로 스태프 엔지니어나 스태프 역할로 빠르게 진행 중인 시니어 엔지니어가 담당합니다. 기술적 명확성을 제공하는 데 능숙한 시니어 엔지니어들은 때로 의도하지 않았는데도 스태프로 승진합니다. 그들이 돕던 비기술 리더들에게 더 유용한 도구가 되기 위해서입니다.
물론 조직에 기술적 명확성을 제공하지 않고도 영향력 있는 엔지니어가 될 수 있습니다. 많은 엔지니어들, 심지어 스태프 엔지니어조차도 프로젝트 배포, 까다로운 버그 식별, 좋은 시스템 설계 등을 통해 가치를 제공합니다. 하지만 그러한 엔지니어들은 기술적 명확성을 제공하는 엔지니어만큼 가치를 인정받지 못할 것입니다. 그 이유는 부분적으로 회사의 시니어 리더십이 누가 자신을 도와주었는지 기억하기 때문이고, 부분적으로 기술적 명확성이 거의 모든 단일 프로젝트보다 훨씬 높은 레버리지를 가지기 때문입니다.
비기술 리더들은 명확하든 그렇지 않든 결정을 내려야 합니다. 따라서 그들은 결정을 내리는 데 도움을 줄 수 있는 엔지니어들의 멘탈 리스트를 유지하고, 그 엔지니어들을 가장 중요한 팀과 프로젝트에 배치하려는 강한 동기를 가지고 있습니다.
비기술 리더들의 관점에서 그러한 엔지니어들은 기술적 복잡성에 대한 추상화입니다. 엔지니어들이 메모리 관리에 신경 쓰지 않기 위해 가비지 컬렉션 언어를 사용하는 것처럼, VP들은 소프트웨어의 세부 사항에 신경 쓰지 않기 위해 엔지니어를 사용합니다.
불확실성 감내하기
하지만 추상화 내부에서는 어떤 느낌일까요? 내부적으로 엔지니어들은 비기술 리더들이 신경 쓰지 않아도 되는 모든 어색한 기술적 세부 사항에 대해 걱정해야 합니다. 내가 “문제없습니다, 안전하게 롤백할 수 있습니다”라고 말할 때, 나는 겉으로 보이는 것만큼 자신감이 있는 것이 아닙니다. 기술적 주제에 대해 의견을 줄 때 나는 최대 95%의 확신을 가집니다. 중요한 것을 놓칠 가능성이 항상 5%는 있으며, 보통은 그보다 낮습니다. 나는 항상 적어도 조금은 걱정합니다.
95% 확신하는데 왜 걱정할까요? 왜냐하면 찾아야 할 것이 무엇인지 모르는 것들에 대해 걱정하기 때문입니다. 내 경력에서 극적으로 틀렸을 때는 일반적으로 예상했던 위험에 관한 것이 아닙니다. 대신 “알려지지 않은 미지수”, 즉 전체 시스템에 대한 내 이해에 빠진 부분이 있어서 생각조차 하지 못했던 위험에 관한 것입니다. 그래서 프로젝트를 배포하려면 완전한 집중이 필요하다고 말하는 것입니다. 기술 프로젝트를 이끌 때 나는 아직 생각하지 못한 것이 무엇인지 궁금해하며 많은 시간을 보냅니다.
즉, 시스템에 대한 이해에 꽤 자신이 있을 때도 여전히 내부적으로 배경 수준의 편집증이 있습니다. 조직에 기술적 명확성을 제공하려면 그 편집증을 나 자신에게 간직해야 합니다. 모든 걱정을 말로 표현하는 것과 너무 자신만만해서 언급했어야 할 위험을 표면화하지 못하는 것 사이에서 신중한 균형을 맞춰야 합니다.
좋은 엔지니어처럼 좋은 VP들도 모든 추상화가 때때로 새는 것을 이해합니다. 그들은 엔지니어가 나머지 시간에 유용한 추상화로서의 의무를 다하는 한, 가끔의 기술적 실수에 대해 비난하지 않습니다. 그들이 기술 고문에게서 용납하지 않는 것은 명확한 의견이 전혀 없는 것입니다. 대부분의 질문에 “글쎄요, 확신할 수 없어요, 말하기 정말 어렵습니다”라고 대답하는 엔지니어는 고문으로서 쓸모가 없습니다. 여전히 코드를 작성하고 프로젝트를 제공할 수 있지만 조직의 기술적 명확성을 높이지는 못할 것입니다.
불확실성을 숨기는 것은 거짓말이 아닌가?
과거에 자신 있게 의사소통하는 것에 대해 글을 썼을 때, 일부 독자들은 내가 엔지니어에게 비윤리적으로 행동하라고 조언하고 있다고 생각했습니다. 그들은 신중하고 기술적으로 건전한 엔지니어가 모든 세부 사항을 포함하여 정확한 진실을 전달해야 하며, 실제보다 더 확신하는 것처럼 보이는 것은 사기꾼의 속임수라고 생각합니다. 물론 확신하는 척하면 리더십은 당신을 정직하게 확신하지 못한다고 말하는 엔지니어보다 더 나은 엔지니어라고 생각할 것입니다. 한 엔지니어가 걱정을 숨기기 시작하면 다른 엔지니어들도 따라가야 하고, 곧 모든 말빠른 허풍쟁이들이 영향력 있는 위치에 있고 정직한 엔지니어들은 단지 프로젝트 작업으로 밀려납니다.
즉, “문제없습니다, 롤백할 수 있습니다”라고 말할 때 무언가를 놓쳤을 수도 있는데, 그것은 거짓말이 아닌가요? 내 확신 수준을 정확하게 전달해야 하지 않을까요? 예를 들어, “안전하게 롤백할 수 있을 것 같지만 확신할 수 없습니다. 시스템에 대한 제 이해가 완벽하지 않기 때문입니다. 온갖 잠재적 버그가 있을 수 있습니다”라고 말할 수 있지 않을까요? 나는 그렇게 생각하지 않습니다.
엔지니어가 최대한의 기술적 정확성을 추구해야 한다고 말하는 것은 명확성이 무엇인지에 대한 오해를 드러냅니다. 이 글의 상단에서 명확성은 비기술 의사결정자들이 시스템에 대해 충분히 좋은 실용적 이해를 가질 때라고 말했습니다. 그것은 필연적으로 단순화된 이해를 의미합니다. 엔지니어가 비기술 리더십과 의사소통할 때 의사소통을 단순화해야 합니다(즉, 이해되기 위해 어느 정도의 부정확성을 허용해야 합니다).
내 걱정의 대부분은 비기술 의사결정자들에게 관련 정보가 아닙니다. “오늘 이것을 제공할 수 있습니까” 또는 “이 기능을 출시하는 것이 안전합니까”라는 질문을 받을 때, 질문하는 사람은 “예” 또는 “아니오”를 찾고 있습니다. 막연한 기술적 주의사항의 흐름을 함께 제공하면, 그들은 내가 “예” 또는 “아니오”를 의미하는지 파악하기 위해 의식적으로 그것을 걸러내야 합니다. 왜 그들이 세부 사항에 신경을 쓸까요? 그들은 내가 그들보다 기술적 위험을 평가하는 데 더 나은 위치에 있다는 것을 알고 있습니다. 그래서 처음에 나에게 묻는 것입니다!
나는 엔지니어가 나쁘거나 받아들일 수 없을 정도로 위험한 결정에도 항상 “예”라고 말하라고 조언하는 것이 아님을 분명히 하고 싶습니다. 때로는 “안전하게 롤백할 수 없으므로 변경에 대해 확신해야 합니다” 또는 “아니요, 아직 이 클래스의 사용자에게 기능을 제공할 수 없습니다”라고 말해야 합니다. 내 요점은 회사의 의사결정자들과 이야기할 때 한 가지 방식으로든 권장 사항에 전념해야 하며, 잠재적 위험이 극단적이거나 가능성이 진정으로 높을 때만 주의사항을 제공해야 한다는 것입니다.
결국, VP는 기술적 세부 사항을 이해하는 데 할애할 정신적 비트가 제한되어 있습니다. 시니어 엔지니어가 VP와 의사소통한다면 가장 중요한 부분, 즉 무엇이 가능하고, 무엇이 불가능하며, 무엇이 위험한지로 그 비트를 채워야 합니다. 그들에게 무관한 기술 정보의 긴 흐름에서 그러한 부분을 분석하게 만들지 마세요.
요약
내가 하는 가장 높은 레버리지의 작업은 조직에 기술적 명확성을 제공하는 것입니다. 비기술 의사결정자들에게 소프트웨어 시스템에 대한 맥락을 제공하기 위해 위로 의사소통하는 것입니다. 이것은 두 가지 이유로 어렵습니다. 첫째, 유능한 엔지니어조차도 대규모 코드베이스에 대한 간단한 질문에 명확하게 답하기 어렵습니다. 둘째, 비기술 의사결정자들은 유능한 엔지니어와 같은 수준의 기술적 뉘앙스를 흡수할 수 없으므로 그들과 의사소통하려면 단순화가 필요합니다.
복잡한 기술적 주제를 효과적으로 단순화하려면 세 가지가 필요합니다:
- 좋은 판단력 – 어떤 위험이나 맥락을 언급하고 어떤 것을 생략할지 아는 것
- 시스템에 대한 깊은 기술적 이해 – 효과적으로 의사소통하려면 코드를 배포하고 프로젝트를 제공해야 합니다. 코드베이스와의 직접적인 접촉을 잃으면 결국 그것에 대해 의사소통하는 능력을 잃게 됩니다
- 상위 관리자에게 단순화된 그림을 제시하는 능력 – 많은 엔지니어들은 80% 또는 90%만 확신하는 주장에 전념하는 것이 부정직하다고 느끼거나 용기가 부족합니다. 내 견해로는 이러한 엔지니어들은 조직이 좋은 기술적 결정을 내리도록 돕는 책임을 포기하고 있습니다.
공감갈만한 내용이어서 담아왔습니다.
커뮤니케이션을 하는 과정에서 일정한 동작을 일상의 예시로 기가막히게 드는 경우의 엔지니어를 만난적이 있는데, 정확한 의사전달과 전략 수립에 방향을 결정하는데 매우 큰 도움을 받았던 기억이 납니다.
조직 내에서 엔지니어로써의 역량에 대해서 매우 중요한 포인트라고 생각되네요.
답글 남기기