Test Management and Coordination During the Vera C. Rubin Observatory Commissioning and Early Operations Using Zephyr Scale

베라 C. 루빈 천문대(Vera C. Rubin Observatory)를 칠레의 산 위에 주차된 거대하고 믿을 수 없을 정도로 복잡한 우주선이라고 상상해 보십시오. 이 우주의 임무는 우주의 궁극적인 지도를 만들기 위해 수백만 장의 우주 사진을 찍는 것입니다. 하지만 본격적인 임무를 시작하기 전, 팀은 이 우주선을 "커미셔닝(commissioning)"해야 했습니다. 이는 본질적으로 모든 버튼, 다이얼, 카메라 렌즈가 완벽하게 작동하는지 확인하기 위해 모든 것을 테스트하는 과정을 의미합니다.

이 논문은 50명이 넘는 전문가들이 어떻게 정신을 놓지 않고 수백 개의 테스트를 수행하며 이 작업을 완수했는지, 그리고 원래 소프트웨어 테스트용으로 만들어졌지만 거대 망원경에는 적합하지 않았던 Zephyr Scale이라는 디지털 도구를 어떻게 활용했는지에 대한 이야기를 담고 있습니다.

다음은 이 과정을 간단한 개념별로 정리한 내용입니다.

1. 문제점: 너무 많은 요리사와 너무 많은 레시피

50명의 서로 다른 셰프들이 주방 환경이 계속 변하는 와중에도 무엇을 요리할지, 언제 요리할지, 어떻게 요리할지를 결정하려고 애쓰는 저녁 식사 서비스를 운영한다고 상상해 보십시오.

• 현실: 천문대 팀은 매일 발생하는 변화, 기술적 결함, 새로운 과학적 목표들을 조율해야 했습니다. 그들은 "주방 직원"(관측 전문가)들에게 매일 밤 정확히 무엇을 해야 할지 알려줄 방법이 필요했고, 실제로 음식이 맛있는지 기록할 방법도 필요했습니다.
• 해결책: 그들은 Zephyr Scale을 도입했습니다. 이것을 프로젝트 관리 앱(Jira) 안에 들어 있는 디지털 레시피 북이라고 생각하십시오. 이 도구는 망원경을 위해 설계된 것은 아니었지만, 팀은 이것이 자신들의 혼돈을 정리하는 데 완벽한 도구라는 것을 깨달았습니다.

2. 세 가지 주요 재료

논문은 이 시스템의 세 가지 핵심 부분을 설명하며, 이를 레시피, 일일 메뉴, 요리사의 기록으로 비유합니다.

• 테스트 케이스 (레시피):
  이는 재사용 가능한 단일 지침 세트입니다. "케이크를 굽는 법"에 대한 레시피와 같습니다. 제목, 단계별 목록, 그리고 결과가 어떠해야 하는지를 포함합니다.

  • 비유: 만약 테스트가 "망원경을 별에 맞추고 사진을 찍는다"라면, 테스트 케이스는 "1단계: 모터를 켠다. 2단계: 5초를 기다린다. 3단계: 사진을 찍는다"라고 적힌 서면 레시피입니다.
  • 복잡성: 어떤 레시피는 단순하지만, 어떤 것들은 매우 복잡하여(수백 단계를 포함함) JSON BLOCK 형태로 저장됩니다. 이는 컴퓨터가 사람이 일일이 읽지 않아도 바로 "꽂아서" 실행할 수 있는 사전 포장된 자동화 밀키트와 같습니다.

• 테스트 사이클 (일일 메뉴):
  매일 팀은 새로운 "테스트 사이클"을 생성합니다. 이것은 그날 밤의 메뉴입니다. 그날 저녁에 시도할 구체적인 레시피(테스트 케이스)들을 하나로 묶은 것입니다.

  • 비유: 레스토랑에 "화요일 특선" 메뉴가 있듯이, 천문대에도 "화요일 밤 테스트 계획"이 있습니다.
  • 반전: 그들은 종종 할 수 있는 양보다 더 많은 계획을 세웁니다. 때로는 메뉴에 30개의 레시피를 추가하지만, 실제로 요리할 시간은 23개뿐일 수도 있습니다. 시스템은 무엇이 요리되었고 무엇이 선반에 남겨졌는지를 정확히 추적합니다.

• 테스트 실행 (요리사의 기록):
  사람이 실제로 레시피의 한 단계를 수행하면, 시스템에 완료되었다고 표시합니다. 이것이 "테스트 실행"을 만듭니다.

  • 비유: 이것은 셰프가 노트에 "케이크를 구웠다. 잘 부풀었다. 설탕을 더 넣었다"라고 적는 것과 같습니다.
  • 중요한 이유: 나중에 레시피가 변경되더라도, 이 기록은 특정 시점에 고정되어 남습니다. 이는 몇 년 후 과학자들이 특정 사진이 왜 그렇게 찍혔는지 이해하기 위해 과거를 되돌아볼 때 매우 중요합니다.

3. 팀이 협업하는 방식

논문은 마치 잘 짜인 춤처럼 그들의 하루 일과를 구체적으로 설명합니다.

1. 아이디어: 누군가 새로운 테스트 아이디어를 냅니다 (예: "카메라가 열을 잘 견디는지 확인해 보자").
2. 채팅: 그들은 Slack(그룹 채팅 앱)에서 이를 논의합니다.
3. 형식화: 그 채팅 아이디어를 Zephyr 내의 공식적인 테스트 케이스(레시피)로 변환합니다.
4. 검토: 선임 과학자가 레시피가 안전하고 명확한지 검토합니다.
5. 계획: 다음 날 아침, "테스트 플래너"는 일일 메뉴(테스트 사이클)를 살펴보고 승인된 레시피들을 추가합니다.
6. 실행: 실제 망원경 앞에 있는 관측 전문가들이 메뉴를 따르며 단계를 체크합니다.
7. 주간 점검: 일주일에 한 번, 팀 전체가 모여 이번 주의 "주요 맛(flavor of the week)"이 무엇인지 결정합니다. 고장 난 부품을 고치는 데 집중할까요? 아니면 더 많은 사진을 찍는 데 집중할까요? 그들은 무엇이 가장 많은 것을 가르쳐 줄 수 있는지에 따라 우선순위를 정합니다.

4. 좋았던 점, 나빴던 점, 그리고 최악의 점

저자들은 도구의 장단점을 솔직하게 밝히고 있습니다.

좋았던 점:

• 영구적인 기록을 생성합니다: 종이나 화이트보드와 달리, 시스템은 모든 변경 사항을 기억합니다. 레시피가 업데이트되었다면, 시스템은 어떤 날 밤에 어떤 버전이 사용되었는지 정확히 알고 있습니다.
• 연결성을 제공합니다: Jira 내에서 작동하기 때문에, 테스트를 버그 보고서나 엔지니어링 티켓과 직접 연결하여 모두가 왜 이 테스트를 하는지 알 수 있게 합니다.

나빴던 점:

• 다소 투박합니다: 이 도구는 망원경을 위해 만들어진 것이 아니므로 일부 기능이 불편합니다. 예를 들어, 두 버전의 레시피를 나란히 놓고 비교하기가 어렵습니다.
• 오래된 정보: 가끔 한 밤을 위해 작성된 메모가 다음 날의 메뉴로 실수로 복사되어 직원들을 혼란스럽게 합니다. 팀은 매일 이를 수동으로 정리해야 합니다.
• 링크 유실: 레시피의 버전이 변경되면 링크가 끊어져, 나중에 예전 지침을 찾기가 어려워집니다.

5. 핵심 결론

논문은 Zephyr Scale이 거대 망원경을 위한 완벽한 맞춤형 도구는 아니지만, 팀의 규율 덕분에 성공적으로 작동했다고 결론짓습니다.

그들은 소프트웨어를 엄격한 규칙 세트로 다루었습니다:

• 레시피가 "준비 완료(Ready)"로 표시되지 않으면 메뉴에 올리지 않습니다.
• 단계가 체크되지 않았다면, 그것은 일어나지 않은 일입니다.

저자들은 망원경의 "커미셔닝"이 끝나고 원활하게 돌아가기 시작하면 이 도구 사용을 멈출 것이라고 예상했습니다. 하지만 그들은 여전히 이 도구가 필요하다는 것을 깨달았습니다. 왜일까요? 웹사이트의 단순한 체크리스트는 규모를 키울 수 없기 때문입니다. 매일 밤 수백 개의 단계를 체크해야 한다면, 매일 밤 자동으로 새롭고 깨끗한 로그를 생성하여 무엇이 일어났는지 절대 놓치지 않도록 하는 시스템이 필요합니다.

요약하자면: 그들은 소프트웨어 버그를 잡기 위해 설계된 도구를 가져와 거대한 과학 기계를 운영하는 데 사용했으며, 충분한 규율과 좋은 워크플로우가 있다면 "네모난 못을 둥근 구멍에" 성공적으로 끼워 넣을 수 있다는 것을 증명했습니다.