비개발 의사결정자를 위해 기술을 명확하게 설명하는 법

내가 스태프 엔지니어로서 하는 가장 중요한 임무는 조직에 기술 명확성을 제공하는 것이다. 물론 프로젝트를 진행하고, 코드를 배포하며, PR을 리뷰하는 등 다른 업무들도 수행하지만, 내가 하는 일 중 가장 핵심적인 것은 바로 기술 명확성을 제공하는 것이다.

기술 명확성이란 무엇인가?

조직 내에서 기술 명확성이란 비기술적 의사결정자들이 소프트웨어 시스템에 어떤 변화를 줄 수 있는지에 대해 실질적이고 충분한 이해를 가지고 있는 상태를 뜻한다. 소프트웨어 조직을 책임지는 사람들은 많은 소프트웨어 관련 결정을 내려야 한다. 전체 전략을 설정하지 않더라도, 어떤 사용자에게 어떤 기능을 제공할지, 어떤 업데이트를 우선 배포할지, 그리고 프로젝트 일정을 미루거나 앞당길지 등을 결정하는 경우가 많다.

이 사람들은 한때 기술자였거나 지금도 뛰어난 기술적 감각을 가졌을 수도 있지만, 내가 말하는 ‘비기술적’이라는 의미에서는 그들이 시스템에 대한 정확한 정신적 모델을 구축할 시간이나 배경 지식이 없다는 뜻이다. 대신 그들은 모호한 정신적 모델에 의존하며, 신뢰하는 엔지니어들의 조언에 기반해 결정을 내린다.

그 모호한 정신 모델이 얼마나 정확하고, 받은 조언이 얼마나 좋은지에 따라, 즉 기술 명확성이 어느 정도인지를 기준으로 그들은 합리적인 결정을 내리게 된다. 따라서 이 기술 명확성은 매우 중요하며, 조직 내에서 기술 명확성이 있는지 여부가 기능하는 엔지니어링 팀과 전혀 기능하지 못하는 팀을 가르는 중요한 차이가 될 수 있다.

왜 기술 명확성이 드문가

조직 내에서 기본적으로 존재하는 기술 명확성의 양은 매우 적다. 다시 말해, 기술 기업의 의사결정자들은 해당 기술에 대해 종종 완전히 혼란스러워한다. 이는 그들의 능력이 부족해서가 아니다. 소프트웨어는 정말 복잡하며, 심지어 관련 팀의 엔지니어들조차 자신이 맡은 시스템에 대해 많은 시간을 혼란 속에서 보내곤 한다.

내 경험상, 이런 사실은 비기술자들에게는 놀랍다. 그러나 이는 사실이다. 규모가 큰 오래된 코드베이스에서는, 아주 경력 많은 엔지니어조차 자신의 시스템이 어떻게 작동하는지에 대해 매우 기본적인 질문조차 확실히 답하지 못하는 경우가 흔하다. 예를 들어 “X 유형 사용자가 Y 작업을 수행할 수 있는가?”, “Z 작업을 하면 W 유형 사용자의 화면에는 어떻게 나타나는가?” 같은 질문이 그렇다. 엔지니어들은 이런 질문에 대개 “확인해봐야겠다”고 답한다.

예를 들어, 어떤 기술 회사의 부사장(VP)이 기존의 유료 기능을 일부 무료 사용자에게 제공하려고 할 때, 이 프로젝트와 관련된 대부분의 기술적 질문들은 부사장에게는 별로 중요하지 않다. 하지만 부사장이 반드시 알아야 하는 기술적 질문들은 있다.

1. 현재 상태에서 이 유료 기능을 무료 사용자에게 안전하게 제공할 수 있는가?
2. 이 기능을 점진적으로 배포할 수 있는가?
3. 문제가 발생하면 사용자 계정을 손상시키지 않고 기능을 되돌릴 수 있는가?
4. 테스트 및 기타 목적으로 일부 사용자에게 조기 접근 권한을 줄 수 있는가?
5. 용량 문제가 있을 경우 유료 사용자를 우선 처리할 수 있는가?

이 질문에 답을 찾는 것은 복잡한 기술적 프로세스다. 전체 시스템에 대한 깊은 이해가 필요하며, 관련 코드를 꼼꼼히 다시 읽어야 하는 경우가 많다. 단순히 개발 환경이나 테스트 계정에서 시도해보는 것으로는 모든 경계 사례를 놓칠 가능성이 크다. 테스트 계정에서는 잘 동작해도, “조직”에 속한 사용자나 체험판 사용자에게는 동작하지 않을 수 있다.

때때로 이런 질문들은 실제 작업을 수행해보는 것만이 명확한 답을 준다. 나는 왜 이런 일이 일어나는지에 대해 [Wicked features]에서 썼다. 소프트웨어 시스템이 성장하면서 이익이 작지만 수익성 있는 기능들이 서로 예상치 못하게 상호작용하는 경우가 생기고, 이로 인해 시스템은 거의 — 완전히는 아니지만 — 이해하기 불가능한 상태에 가까워진다. 좋은 소프트웨어 설계는 이런 복잡성을 억제할 수 있지만 완전히 없애지는 못한다. 따라서 숙련된 엔지니어들은 항상 자신들이 놓치고 있는 어떤 상호작용이 있어 그것이 실제 운영에서 문제가 될 것이라 의심하는 자세를 가진다.

공식적 및 비공식적 기술 조언자

기술 회사의 부사장이나 제품 책임자에게는 소프트웨어 시스템의 복잡함을 헤쳐 나갈 수 있도록 의지할 수 있는 엔지니어가 있다는 것이 큰 안도감이다. 내 경험으로는 이러한 “기술 조언자” 역할은 주로 스태프 엔지니어나 스태프 직급으로 빠르게 올라가는 시니어 엔지니어가 맡는다. 기술 명확성을 잘 제공하는 시니어 엔지니어는 별다른 노력 없이도 스태프로 승진하는 경우가 많으며, 이는 비기술 리더들에게 더 큰 도움이 되도록 하기 위함이다.

물론, 조직에 기술 명확성을 제공하는 역할을 하지 않더라도 영향력 있는 엔지니어가 될 수 있다. 많은 엔지니어, 심지어 스태프 엔지니어들도 프로젝트를 성공적으로 수행하고, 까다로운 버그를 찾아내며, 뛰어난 시스템 설계를 하는 등으로 가치를 발휘한다. 그러나 조직 내에서 기술 명확성을 제공하는 엔지니어들은 훨씬 더 높은 평가를 받는 경우가 많다. 이는 경영진이 누가 자신들을 도왔는지 기억하고 있기 때문이기도 하며, 무엇보다 기술 명확성이 어느 하나의 프로젝트보다 훨씬 더 큰 영향력을 발휘하기 때문이다.

비기술 리더들은 명확한 결정 여부와 상관없이 결정을 내려야 하며, 그래서 결정을 잘 도와주는 엔지니어 명단을 머릿속에 유지한다. 그리고 그런 엔지니어들을 가장 중요한 팀과 프로젝트에 배치하는 동기를 갖는다.

비기술 리더 입장에서는, 그런 엔지니어들은 기술 복잡성을 추상화한 ‘대리인’과 같다. 마치 엔지니어들이 메모리 관리를 신경 쓰지 않기 위해 가비지 컬렉터가 있는 언어를 쓰는 것처럼, 부사장들은 소프트웨어 세부 사항을 신경 쓰지 않기 위해 신뢰하는 엔지니어들을 활용하는 것이다.

불확실성을 견디기

복잡한 기술적 내용을 추상화한 그 뒤에서는 엔지니어들이 모든 까다로운 기술적 세부 사항에 대해 끊임없이 고민한다. 비기술 리더들은 그렇지 않아도 되지만, 엔지니어들은 그렇지 않다. 내가 “문제없다, 안전하게 롤백할 수 있다”고 말할 때, 실제로는 겉으로 보이는 만큼 자신 있는 것은 아니다. 기술적 의견을 제시할 때 내 자신감은 최대 95% 정도이며, 중요한 것을 놓쳤을 가능성이 5%는 항상 존재한다. 보통은 그보다 자신감이 낮고, 늘 약간의 걱정이 있다.

내가 95% 확신하는데 왜 걱정하냐고? 그것은 내가 찾아야 할 것조차 모르는 ‘모르는 것들’을 걱정하기 때문이다. 내 경력에서 크게 잘못된 판단을 했던 경험들은 보통 예상했던 위험 때문이 아니었다. 오히려 전체 시스템에 대한 이해가 조금 빠져서 고려하지 못한 ‘알지 못하는 위험들(unknown unknowns)’ 때문이다. 이것이 내가 ‘프로젝트를 성공적으로 출시하는 데는 온 정신이 집중되어야 한다’고 말하는 이유다. 기술 프로젝트를 이끌 때, 나는 무엇을 놓쳤을지 계속 고민하며 많은 시간을 보낸다.

즉, 시스템에 대해 꽤 자신 있어도 내면에선 항상 약간의 불안과 경계심이 존재한다. 조직에 기술 명확성을 제공하기 위해 나는 그 불안감을 속으로만 감춰야 한다. 모든 걱정을 다 표현하는 것과 너무 과도한 자신감으로 위험 신호를 숨기는 것 사이에 신중한 균형이 필요하다.

좋은 엔지니어와 좋은 부사장 모두 ‘모든 추상화는 때때로 완벽하지 않다’는 점을 이해한다. 그들은 엔지니어들이 가끔씩 저지르는 기술적 실수를 탓하지 않는다. 엔지니어들이 대부분 시간 동안 유용한 추상화 역할을 한다면 용인한다. 하지만 기술 조언자에게 절대 용납하지 않는 것은 ‘명확한 의견이 없는 것’이다. 대부분의 질문에 “잘 모르겠다, 확실하게 말하기 어렵다”고 답하는 엔지니어는 조언자로서 무용지물이다. 그들은 코드를 작성하고 프로젝트를 수행할 수는 있어도 조직 내 기술 명확성을 높이지는 못한다.

불확실성을 숨기는 것은 거짓말인가?

내가 과거 자신 있게 의사소통하는 법에 대해 쓸 때, 일부 독자들은 내가 엔지니어들에게 비윤리적으로 행동하라고 조언하는 것처럼 오해했다. 그들은 꼼꼼하고 기술적으로 완벽한 엔지니어는 모든 사실을 상세히 정확하게 전달해야 하며, 자신감 있어 보이는 것은 사기꾼의 술책이라고 생각한다. 물론, 만약 누군가 확신하는 척한다면 경영진은 확신하지 않는 솔직한 엔지니어보다 그를 더 뛰어난 엔지니어로 본다. 한 명의 엔지니어가 걱정을 숨기기 시작하면, 다른 엔지니어들도 따라야 하거나 소외당하게 되고, 결국 말 잘하는 사람이 영향력을 가지는 반면, 솔직한 엔지니어들은 단지 프로젝트만 수행하는 데 그친다.

즉, 내가 “문제없다, 안전하게 롤백할 수 있다”고 말할 때, 뭔가 놓친 게 있을지도 모르는데 그게 단순히 거짓말인가? 내가 내 자신감의 정도를 정확히 전달해야 하지 않을까? 예를 들어 “시스템 이해도가 완벽하지 않아 잠재적 버그가 있을 수 있지만 안전하게 롤백할 수 있을 것으로 생각한다”고 말하는 게 더 솔직한 것 아닐까? 나는 그렇게 생각하지 않는다.

엔지니어들이 최대한 기술적으로 정확하게 전달해야 한다고 말하는 것은 ‘명확성’이 무엇인지 제대로 이해하지 못한 것이다. 이 글 서두에서 나는 명확성이란 비기술적 의사결정자들이 시스템을 충분히 이해할 수 있게 하는 것이라고 했다. 이는 반드시 단순화된 이해를 의미한다. 그러므로 엔지니어들이 비기술 리더와 소통할 때는 이해를 돕기 위해 의사소통을 단순화해야 한다(즉, 이해시키는 데 도움이 되는 약간의 부정확성을 허용해야 한다).

내 걱정 중 대부분은 비기술적 의사결정자에게는 중요하지 않은 정보다. “오늘 이걸 배포할 수 있나?”, “이 기능을 안전하게 출시할 수 있나?”라는 질문을 받으면, 묻는 사람은 단지 ‘예’ 아니면 ‘아니오’를 원한다. 만약 내가 모호한 기술적 단서들을 주절주절 늘어놓으면, 그들은 ‘예’인지 ‘아니오’인지 알기 위해 의식적으로 걸러내야 한다. 왜 그들이 세부사항에 신경 쓰겠는가? 그들은 내게 기술적 위험 평가가 더 낫기 때문에 묻는 것이다.

내가 분명히 하고 싶은 것은, 엔지니어가 무조건 ‘예’를 말하라고 조언하는 것이 아니다. 때로는 “안전하게 롤백할 수 없으니 변경을 확실히 해야 한다”거나 “아직 이 사용자 그룹에 기능을 배포할 수 없다”고 말해야 한다. 중요한 점은 회사 의사결정자와 소통할 때는 명확한 추천을 하되, 위험이 극도로 크거나 가능성이 높을 때만 주의사항을 덧붙이라는 것이다.

결국, 부사장은 기술적 세부사항을 이해할 정신적 여유가 제한적이다. 시니어 엔지니어가 부사장과 소통할 때는 그 한정된 여유 공간에 ‘가능한 것’, ‘불가능한 것’, ‘위험한 것’ 세 가지 핵심 정보를 채워 넣어야 한다. 되도록 관련 없는 기술 정보를 길게 나열해 그들이 직접 해석해야 하는 부담을 지우지 말아야 한다.

요약

내가 조직에 제공하는 가장 큰 영향력은 비기술적 의사결정자들과 소통하며 소프트웨어 시스템에 대한 배경과 맥락을 전달하는 기술 명확성을 제공하는 일이다. 이 작업이 어려운 이유는 두 가지다. 첫째, 유능한 엔지니어조차 대규모 코드베이스에 대해 단순한 질문을 명확하게 답하기 어려워한다. 둘째, 비기술 의사결정자들은 유능한 엔지니어만큼 미묘한 기술적 뉘앙스를 모두 받아들이지 못하기 때문에, 그들과 소통하기 위해서는 단순화가 필요하다.

복잡한 기술 주제를 효과적으로 단순화하려면 세 가지가 필요하다.

1. 좋은 감각 – 어떤 위험이나 맥락을 언급하고 어떤 부분을 생략할지 판단하는 능력.
2. 시스템에 대한 깊은 기술적 이해 – 효과적으로 소통하려면 코드를 직접 작성하고 프로젝트를 수행해야 한다. 코드베이스와의 직접적인 접촉을 잃으면, 코드가 변하고 구체적 내용에 대한 기억이 사라짐에 따라 소통 능력이 점차 떨어진다.
3. 관리층에 단순화된 그림을 자신 있게 제시하는 태도 – 많은 엔지니어는 이 일이 부정직하다고 느끼거나 80~90% 자신감만 있어도 확신을 가지고 주장하지 못한다. 내 생각에 이런 엔지니어들은 조직이 좋은 기술적 결정을 내리도록 돕는 책임을 회피하는 것과 같다. 이에 대해서는 Engineers who won’t commit에서 더 많이 다뤘다.

---

원문: How I provide technical clarity to non-technical leaders