모르는 것을 모르고 있는 것을 발견
Meta는 소셜 연결 목적이든 혹은 비즈니스 참여 목적이든 매일 수십억 명의 사용자가 사용하는 제품들로 구성된 에코시스템을 보유하고 있습니다. 이 수십억 명의 사용자는 우리 제품에 지속적으로, 그리고 더 빠른 속도로 새로운 기능을 제공하고 제품을 개선할 것을 요구합니다. 사용자층 규모가 크므로 우리는 이런 기대에 부응하기 위해 매일 수천 개의 코드 변경 사항을 제공합니다.
이렇게 대규모로 제품 개선 사항을 꾸준히 릴리스하는 동안 앱 상태 회귀가 일어나 사용자 경험이 악화될 가능성이 있습니다. Meta는 문제가 있는 제품 변경 사항이 릴리스되지 않도록 방지하는 도구들이 복잡한 층을 이루고 있습니다. 이런 예방 도구는 다양한 제품 신호를 모니터링하고 앱을 릴리스하기 전에 회귀를 탐지합니다. 신호를 구분하는 세 가지 영역은 크게 성능, 안정성(기능 및 시스템) 및 효율성으로 구성됩니다. 이들을 총칭하여 제품의 'PRE'라고 합니다. 예방은 개발자가 코드를 작성하는 동안 수집되는 여러 가지 관찰 기능 및 분석 추적에서 시작합니다. 또한 관찰 기능과 모니터링 도구는 프로덕션 이전 환경에서 내부적으로 제품을 사용하면서 얻은 데이터를 수집합니다. 수동 및 자동 품질 보증 도구는 이러한 프로덕션 이전 환경에서 제품을 테스트합니다.
이런 메커니즘이 프로덕션에 배포하기 전에 코드 변경 사항의 품질을 평가하여 사용자에게 영향을 미치지 않도록 예방하더라도, 사용자에게 영향을 미치는 변경 사항이 프로덕션에 배포되어 재작업을 통해 다시 배포해야 하는 경우도 생깁니다. Meta는 이슈가 대규모 사용자에게 영향을 미칠 가능성을 완화하기 위해 여러 가지 메커니즘을 활용하여 일반 사용자에게 점진적으로 변경 사항을 릴리스합니다.
사용자가 기대하는 기능과 차이가 발생할 경우, 이를 일컬어 회귀라고 정의합니다. Meta는 이 단어 신호를 통해 사용자가 어떤 기능이 자신의 기대에 부합하지 않음을 알리고 있다는 것을 인지합니다. 데이터 인사이트와 측정 코드를 통해 시스템상에서 가능한 즉시 회기 신호를 수집하며, 수정 사항을 배포하여 사용자에게 미치는 영향을 낮추는 작업을 합니다. 우리 도구로부터 강력한 신호를 받지 못하는 경우, 사용자 신고를 회귀가 일어났다는 신호로 받아들입니다. 이러한 신고는 다양한 메커니즘을 통해 들어옵니다. 예를 들어 사용자는 문제가 발생한 시점에 앱의 어느 위치에 있었는지에 대한 컨텍스트에서 휴대폰을 흔들어 문제를 신고할 수 있습니다.
Meta는 고객의 요구 사항을 최대한 신속하게 (때로는 그날 안에) 충족할 수 있도록 대규모 대응을 지원하는 여러 가지 안정성 프로그램과 시스템에 크게 투자했습니다.
신호는 일반 사용자(개인, 기업, 그룹 등) 또는 내부 사용자에게서 수집됩니다. Meta는 바람직하지 못한 변경 사항이 프로덕션에 배포되지 않도록 내부 사용자로부터 수집한 신호를 신중하게 조사합니다. 신호는 집계된 값입니다. 예를 들어 신호에는 사용자 100만 명당 버그 수가 포함됩니다. 또한 신호는 자동 테스트 도구와 시나리오, 개발 도구(개발자에게 런타임 문제를 발생시키는 변경 사항에 대해 알림), 시스템 로그 및 그 외의 다른 여러 소스에서도 발생합니다. Meta에는 이런 신호를 활용하여 원인을 신속히 알아내고 적절한 수정 사항을 적용하기 위한 도구도 있습니다.
회귀를 찾아내고 나면 재빨리 관련 엔지니어를 찾아서 수정 사항을 적용하고 릴리스합니다. Meta는 회귀의 복잡성에 따라 Meta의 머신 러닝 기술을 활용하는 등 여러 가지 수단으로 적절한 엔지니어를 찾습니다. 머신 러닝의 원리상, Meta에서 새로운 기능을 릴리스하고 끊임없는 변화에 대응하도록 모델을 다시 훈련시키는 것은 지속적으로 이루어지는 과정입니다.
물론, 목표는 있습니다. Meta는 회귀를 탐지하는 데서 시작해서 회귀를 완화 및 방지한 다음, 지속적으로 억제하는 과정으로 진행합니다. 그 과정에서 대응과 투자 수익률, 효율을 극대화합니다.
다음 섹션에서는 우리가 회귀가 발생했음을 확정하는 방법과 이에 대응하는 방법에 대해 자세히 설명하겠습니다.
모르는 것을 아는 것으로 전환 및 수치화
우리가 이야기하는 모르는 것이란 사용자나 시스템이 경험하는 버그를 말합니다. 먼저 서로 다른 다양한 소스에서 발생할 수 있는 버그에 대해 알아보겠습니다.
- 앱의 적절한 기능과 해당 앱 내에서의 특정 제품에 대한 합성 테스트.
- 버그를 찾기 위해 테스트 중인 내부 사용자. 여기에는 전담 테스트 팀이나 Meta 내의 광범위한 사용자 계층을 포함할 수 있습니다.
- 앱 내의 문제 신고 대화 상자를 사용하는 데 이슈를 경험하는 외부 사용자.
이러한 버그는 사용자가 경험하는 인시던트로 플래그되기 전까지는 알 수 없습니다. 이런 버그 신고 수가 특정 임계값에 도달하면 우리는 이를 회귀 이벤트를 나타내는 진짜 문제로 간주합니다. 즉, 코드 변경 사항이 새로운 버그를 만들었고 이를 신속히 완화해야 한다는 것을 의미합니다. 신고에는 크게 두 가지 유형이 있습니다.
- “모르는 것을 알게 되는 상태” - 측정 코드가 회귀를 탐지 및 신고하고 이 신호를 만들어내는 데 도움이 되는 여러 도구가 있을 경우
- “모르는 것을 모르는 상태” - 내부에서 회귀가 포착되지 않고 사용자가 실제로 회귀를 신고하는 것에 의지하는 경우
또한 회귀는 코드 버그, 스팸, 그 외의 콘텐츠 정책 위반 등의 여러 가지 카테고리로 나뉩니다. Meta는 첫 번째 영역에 초점을 맞추고 코드와 관련된 사용자 경험 이슈를 해결하고자 합니다. 사용자가 수천 개의 이슈를 신고하는데 어떻게 대응할 수 있을까요?
신호 및 인사이트 생성
Meta는 대량의 신고를 관리하기 위해 우리에게 이슈를 플래그하는 특정 신호를 생성합니다. 신호의 첫 번째 유형은 적절히 튜닝된 임계값을 통해 인시던트가 발생했는지, 회귀가 발생했는지 알려주는 것입니다. 회귀 유형에 따라 여러 이벤트가 발생했을 수 있습니다. 예를 들어 회귀는 공통적인 코드 베이스로 인해 여러 제품에 영향을 미칠 수 있습니다. 우리는 이런 공통성을 찾고 하나의 인시던트로 다룸으로써 리소스를 최적으로 조정합니다. 아래의 그래프는 회귀를 나타내는 추세선과의 차이를 시각적으로 보는 방법의 예시를 보여줍니다.
그런 다음 추가적 신호를 수집합니다. 그중 일부는 어떤 유형의 회귀가 발생했는지 나타냅니다. 이런 신호는 회귀와 관련된 증상에 대한 인사이트를 제공하고 특정 Meta 제품에 튜닝된 머신 러닝 알고리즘에서 생성됩니다. 이 알고리즘이 사용자 신고를 분석하여 회귀의 원인을 밝히고 어떤 엔지니어링 팀이 코드 수정 사항을 배포하거나 다른 조치를 통해 회귀를 가장 잘 해결할 수 있는지 알려줍니다.
그 외의 다른 여러 신호는 수집된 로그 데이터를 기반으로 생성되기도 합니다. 이런 진단 로그는 사용자의 동의를 받아 원인을 밝히는 데 도움을 얻기 위해 수집한 클라이언트 측 또는 서버 측 로그가 될 수도 있습니다. 앱에는 사용자의 허락에 따라 이러한 유형의 데이터를 수집할 수 있는지 여부를 확인하는 데 적절한 동의 플로가 포함됩니다. 또한 Meta에서는 해당 규정을 준수하기 위해 이러한 데이터의 수명을 고려합니다.
신호를 조합하여 회귀를 찾아내고 적절한 제품 팀에 할당하여 이슈를 신속하게 완화하고 사용자 경험을 사용자의 기대 수준으로 복구할 수 있습니다.
인사이트는 집계 상태로 알아낸 정보에서도 얻습니다. 공통적인 근본 원인을 찾고 회귀가 재발하지 않도록 예방하기 위한 변경 사항이 필요한지 여부를 살피기 위해 데이터를 분석합니다. 이런 과정은 장기적으로 회귀 표면을 최소화하는 데 도움이 되므로 사용자 경험 이슈를 해결하기 위한 확고한 전략을 갖추는 데 핵심적인 부분입니다.
Meta의 모바일 앱은 사용자가 문제를 신고할 수 있는 탐색 경로뿐만 아니라 기기를 흔들어 문제를 신고하는 기능도 제공합니다. 이렇게 하면 컨텍스트 내에서 원격 측정 정보를 수집할 수 있습니다. 이 원격 측정 정보는 앱에서 수집한 블랙박스 신호로 더욱 강화됩니다. 블랙박스는 마치 항공편 녹화기와 같아서, 문제를 더 잘 진단할 수 있도록 버그가 신고되었을 당시에 앱에서 일어난 현상에 대한 특정 로그를 (사용자의 동의를 받아) 자동으로 수집합니다.
이 모든 원격 측정 정보를 한 세트의 타임라인 뷰로 합쳐서 엔지니어링 팀이 이슈의 원인을 밝히도록 합니다. 앱이 짧은 간격으로 릴리스되고 서버 측 앱 구성 요소가 변경되기 때문에 이런 기능 없이 이슈를 찾아내기는 어렵습니다. 이런 원격 측정 정보를 장기적으로 보유하면 회귀에서 패턴을 찾고 향후에 예방하는 데 도움이 됩니다.
더 작은 제품 표면으로 축소하는 과정
Meta는 신호의 정밀도를 높이는 역량을 개선한 결과, 예전에는 탐지하지 못했을 더 많은 회귀 표면을 공략할 수 있게 되었습니다. 표면은 뉴스피드나 릴스와 같이 제품 내의 특정 서비스를 나타냅니다. 제품은 여러 가지 세분화된 기능이 있을 뿐만 아니라 정기적으로 새로운 기능이 도입되기 때문에 이는 문제가 됩니다. 회귀 표면은 크기도 하고 시간이 지날수록 커지기도 합니다. 따라서 Meta의 방어 및 공격 전략을 지속적으로 수정해야 합니다.
확장을 위해서는 다음과 같이 여러 가지 조건을 충족해야 합니다.
- 기존 제품 표면을 정밀하게 커버하고 적절히 분류해야 합니다.
- 기존 제품에 대한 회귀 표면을 낮추어야 합니다(즉, 예방).
- 새로운 제품 표면으로 알고리즘 도달 범위를 확장해야 합니다.
위의 조건을 충족하지 않으면 규모, 복잡성, 부정확성으로 인해 관리할 수 없을 정도로 시스템이 비대해질 위험이 있습니다. Meta는 일상적인 운영을 효율적으로 수행하면서도 이러한 균형을 유지하기 위한 노력을 기울입니다.
버그 수정 이상의 노력
(경계를 놓지 않으면서도) 회귀 표면을 지속적으로 낮추는 동안 다른 중요한 영역, 즉 예방과 사용성에 대한 초점을 강화합니다.
예방은 다음과 관련이 있습니다.
- 이전의 회귀에서 어떻게 교훈을 얻나요?
- 이러한 회귀가 다시 발생하지 않도록 하기 위해 어떤 방어를 구현하나요?
- 장기적으로 회귀 표면이 지속적으로 줄어들게 하려면 어떻게 해야 하나요?
앞서 설명하였듯이, Meta는 이전의 회귀에서 데이터를 집계하여 교훈을 얻습니다. 이렇게 얻은 교훈은 다음과 같습니다.
- 프로덕션 이전 환경에서 코드에 마커를 배치하여 향후 알림을 받을 수 있도록 함으로써 바람직하지 못한 변경 사항이 프로덕션에 배포되지 않도록 예방
- 다양한 수준의 테스트 커버리지를 높여서 이러한 회귀 탐지
- 제품 자체를 변경하여 이슈 해결
예방 조치를 취하면 개발 수명 주기에서 회귀를 왼쪽으로 이동시키고 비용을 지속적으로 낮추는 데 도움이 됩니다. Meta는 이를 위해 코드 작성 및 프로덕션 전 릴리스 주기에서부터 시작해서 개발 프로세스 초기에 충분히 많은 신호를 수집하는 방법을 사용합니다. 이는 사용자 경험을 개선할 뿐만 아니라 개발 비용을 낮추고 리소스를 새로운 제품 개발로 돌리는 데 도움을 줍니다.
더 효율적으로 회귀를 처리하는 능력을 향상하면 사용자의 혼란이나 사용성 이슈에 더욱 집중할 수 있습니다. 제품을 수정하기보다는 개선하는 데 집중하는 방향이기 때문에 이러한 방법을 사용하는 것이 더욱 가치가 높습니다. 시간이 지날수록 회귀 대비 사용성 이슈의 비율이 증가해야 하며, 사용성 이슈와 회귀의 총 개수는 줄어들어야 합니다.
궁극적으로는 기능성과 사용성 측면에서 모두 사용자 경험이 지속적으로 개선됩니다.
이 문서는 Meta 기술 프로그램 관리자인 Bijan Marjan 씨의 협조를 받아 작성하였습니다.
