빠르게 성장하고 움직이는 대형 테크 회사들은, 자기들이 만든 시스템에 대해서조차 늘 일종의 “전쟁터의 안개(fog of war)” 속에서 일하고 있다. “Y 타입 유저가 기능 X를 쓸 수 있나?”, “이 상황에서 액션 Z를 하면 정확히 어떤 일이 벌어지지?”, “우리는 지금 요금제가 몇 가지나 있지?” 같은 아주 단순해 보이는 질문조차, 조직 안에서 겨우 몇 명만 제대로 답을 할 수 있는 경우가 많다. 심하면 그런 질문에 정확히 답할 수 있는 사람이 단 한 명도 없어서, 누군가를 아예 “연구자처럼 파서 조사하는” 역할로 지정해야 할 때도 있다.
어떻게 이럴 수 있을까? 소프트웨어를 만든 엔지니어들은 자기들이 만든 게 어떻게 동작하는지 알고 있어야 하는 것 아닌가? 이런 내용이 내부 문서에 정리되어 있는 것 아닌가? 더 나아가, 이런 질문들은 사용자용 공개 문서만 봐도 금방 답이 나와야 하는 것 아닌가? 테크 회사에는, 자기 일에 능숙한 고연봉 인재들이 잔뜩 있다. 그런 사람들조차 정작 자기 회사 제품이 정확히 무엇을 하는지 명확하게 말해주지 못하는 이유는 무엇일까?
소프트웨어는 원래 어렵다
큰 소프트웨어 제품은 상상을 초월할 정도로 복잡하다. 이건 예전에 내가 쓴 글 “Wicked Features”에서 길게 다룬 주제인데, 요약하자면 “복잡한 기능을 추가함으로써 얻을 수 있는 비즈니스 가치가 정말 크다”는 것이다. 대표적인 예시는, 코어 제품을 더 많은 사용자에게 열어 주는 종류의 기능들이다. 예를 들면, 사용자가 직접 소프트웨어를 Self-hosting할 수 있게 한다든지, 무료 체험을 제공한다든지, 대규모 조직이 중앙집중식 정책 관리 기능과 함께 쓰게 한다든지, 여러 언어로 로컬라이징해서 제공한다든지, 소프트웨어 운영 방식에 엄격한 규제가 있는 국가에서도 쓸 수 있게 만든다든지, 정부처럼 규제가 심한 고객도 쓸 수 있게 만든다든지 하는 것들이다. 이런 기능들은 (바라건대) 대부분의 일반 사용자에게는 거의 보이지 않는 투명한 존재여야 한다. 하지만 그 기능들이 테크 회사 내부에까지 투명할 수는 없다.
왜 이런 기능들이 그렇게까지 복잡할까? 그 이유는, 이런 것들이 새로 만드는 모든 다른 기능 하나하나에 전부 영향을 미치기 때문이다. 조직(Organization)과 정책(Policy) 제어 기능을 한 번 넣기 시작하면, 새 기능을 만들 때마다 그 기능에 대해 또 하나의 정책 제어를 구현해야 한다. 제품을 여러 언어로 로컬라이즈하기 시작하면, 새로운 기능을 추가할 때마다 그 기능에 대한 번역도 항상 함께 따라가야 한다. 그리고 이런 일들이 계속 반복된다.
어느 순간이 되면, 이런 질문을 마주하게 된다. “EU 리전에 있는, Self-hosting을 쓰는 엔터프라이즈 고객이 이 특정 기능에 접근할 수 있어야 하지 않나?” 그런데 아무도 모른다. 결국 코드를 직접 뒤져보거나, 실제로 여러 가지 실험을 해 보면서, 어떻게 동작하는지 하나하나 밝혀내야 한다.
“애초에 이런 기능들을 아예 안 만들면 되는 것 아닌가?” 라고 물을 수도 있다. 물론 그럴 수는 있다. 하지만 그러면 정말 엄청난 돈을 포기해야 한다. 어쩌면 작은 테크 회사와 큰 테크 회사를 가르는 가장 큰 차이 중 하나가 바로 이것일지도 모른다. 큰 회사일수록, 이렇게 자질구레하고 까다로운 기능들까지 다 포함해서 그 안에 숨은 가치까지 최대한 회수해 갈 수 있도록 설계되어 있다는 점이다.
문서화
“그럼 새 기능을 만들 때마다, 관련된 상호작용을 한 번씩만 꼼꼼하게 문서화해 두면 되는 것 아닌가?”라는 질문이 자연스럽게 떠오른다. 이론상으로는, 굉장히 많은 노력과 강력한 톱다운 지원이 붙는다면 가능할 수도 있다고 본다. 하지만 실제로는 이게 정말, 정말 어려운 일이다.
핵심 문제는, 문서화를 하는 동안에도 시스템이 계속 빠르게 변하고 있다는 것이다. 정적인 복잡한 시스템이라면, 한 사람이라도 충분한 시간을 들여서 차근차근 훑어가며 문서를 만들 수 있다. 하지만 시스템이 변하기 시작하는 순간, 문서를 쓰는 사람은 시스템이 변하는 속도보다 더 빨리 움직여야만 한다.
이게 어느 순간부터는, 말 그대로 말도 안 되는 인력을 쏟아붓지 않는 이상 불가능한 일이 되기도 한다.
더 안 좋은 점은, 시스템의 많은 동작이 애초에 누군가의 명시적인 의도로 만들어진 것조차 아니라는 점이다. 여러 가지 “디폴트 설정”이 겹겹이 쌓여 상호작용하면서, 그 결과로 어쩌다 보니 그렇게 동작하게 된 것도 많다. 그래서 문서를 쓰는 사람들은, 단순히 엔지니어들이 내린 의사결정을 받아 적는 역할을 하는 게 아니다. 실제로는, 이 시스템이 어떻게 돌아가는지 처음부터 새로 탐사해서 발견하고 있는 셈이다.
그래서 답을 아는 사람은 누구인가?
이런 질문들 중 많은 것에 답하려면, 가장 확실한 방법은 코드베이스(codebase)를 직접 들여다보는 것뿐이다. 이게 사실 대형 테크 회사에서 엔지니어들이 조직 내에서 구조적으로 권력을 갖는 근본 이유라고 본다. 물론 엔지니어들은 소프트웨어를 작성하는 사람들이지만, 그보다 더 중요한 건 그들이 소프트웨어에 대해 질문에 답할 수 있는 사람이라는 점이다.
사실, 소프트웨어에 대한 질문에 답하는 능력 자체가 엔지니어링 팀의 핵심 기능 중 하나다. 특정 소프트웨어 조각에 대한 가장 깊은 이해는, 보통 그걸 매일 다루는 엔지니어들의 머릿속에 살아 있다. 건강한 엔지니어링 팀이 코드베이스를 소유하고 있다면, 별도로 누군가 조사할 필요 없이 팀 전체에 물어보면 된다. 그러면 적어도 한 명은 머릿속에 바로 답을 꺼내줄 것이다. 왜냐하면 그 부분 코드를 이미 잘 알기 때문이다.
테크 회사들이 팀을 재편(reorg)할 때, 이런 암묵적 지식(tacit knowledge)이 종종 파괴된다. 특정 소프트웨어에 경험이 있는 팀이 사라지면, 질문에 답하려면 조사(investigation)로 돌아갈 수밖에 없다. 누군가 엔지니어가 직접 파헤쳐야 한다는 거다. 보통은 제품과 직접 상호작용하면서(개발 환경에서 특정 시나리오를 쉽게 세팅해서), 코드베이스를 읽어보거나, 심지어 “탐색적 수술(exploratory surgery)”을 하면서 코드 일부를 바꾸거나 특정 체크를 무조건 true로 강제해서 무슨 일이 일어나는지 확인하는 식으로 이뤄진다. 이건 코드를 작성하는 것과는 별개의 기술 스킬이다(물론 두 스킬은 서로 관련이 있지만).
소프트웨어를 짜는 건 설명하는 것보다 쉽다
내 경험상, 대부분의 엔지니어는 소프트웨어를 작성할 수 있지만, 그 소프트웨어에 대해 신뢰할 수 있게 질문에 답하는 사람은 거의 없다. 왜 그럴까? 새 소프트웨어를 작성하려면 그 소프트웨어에 대한 질문을 답할 줄 알아야 하는 것 아닌가? 그래도 이건 사실이다. 내 가장 그럴듯한 이론은 자신감 문제다. 많은 엔지니어들은 최소한 자기 머신에서 돌아가는 코드에 책임을 지는 건 감수할 수 있지만, 완전히 틀릴 수 있는 답변에 책임을 지는 건 싫어한다.
이 주제는 예전에 쓴 “How I provide technical clarity to non-technical leaders”에서 자세히 다뤘다. 핵심 어려움은, 답변할 때마다 항상 위험을 무릅쓰고 나간다는 점이다. 네가 완전히 틀릴 가능성을 편안하게 받아들여야 하는데, 이는 코드를 작성할 때(작업이 맞다는 걸 증명할 수 있으니까)와는 완전히 다른 마인드셋이다. 코드 작성 때는(특히 테스트 코드에서는) 아무리 장황하게 써도 되지만, 질문에 답할 때는 모든 걸 요약으로 압축해야 한다. 많은 소프트웨어 엔지니어들은 이런 디테일 생략을 정말 싫어한다.
요약
소프트웨어 제품과 함께 일해본 경험이 부족한 비기술직 사람들은, 종종 소프트웨어 시스템이 그걸 만든 엔지니어들에게는 완벽히 이해되어 있을 거라고 믿는다. 이 믿음의 근거는, 시스템이 (대체로) 결정론적(deterministic) 컴포넌트들을 한 줄 한 줄 쌓아 올린 결과물이기 때문에 이해하기 쉽다는 생각이다.
하지만 작은 소프트웨어 조각에서는 이게 맞을 수 있어도, 대형 소프트웨어 시스템에서는 거의 항상 틀린 믿음이다. 대형 소프트웨어 시스템은, 이해할 위치에 있는 가장 가까운 사람들조차도 매우 제대로 이해하지 못한다. 소프트웨어가 정확히 무엇을 하는지에 대한 아주 기본적인 질문조차 답하려면 조사(research)가 필요하다. 게다가 한 번 제대로 된 답을 얻었다 해도 오래가지 않는다. 코드베이스에 변화가 생길 때마다 미묘한 뉘앙스나 예외가 생기기 때문에, 같은 질문을 여러 번 다시 조사해야 하는 경우가 많다.
이 모든 이유로, 대형 소프트웨어 시스템에 대해 정확하게 질문에 답할 수 있는 능력은 극도로 가치 있다.
원문: Nobody knows how large software products work
blog by ash에서 더 알아보기
구독을 신청하면 최신 게시물을 이메일로 받아볼 수 있습니다.
