Q는 OSS의 안정성 수호자를 뜻합니다 | OSS의 기초
안녕, 너드들! 오픈소스 소프트웨어의 세계를 알파벳 한 글자씩 파헤쳐 보는 '오픈소스의 기초(ABCs of OSS)'에 다시 오신 걸 환영합니다. 저는 테일러입니다. 오늘은 17회 에피소드로 Q를 다루려 합니다... 바로 품질 보증(Quality Assurance)을 뜻하는 Q죠. 아니면 쿨한 애들이 부르는 대로 QA라고도 합니다.
자, 여러분이 무슨 생각을 하는지 알겠어요. "테일러, QA는 지루한 일 같아." 하지만 들어보세요: QA가 있기에 여러분이 좋아하는 오픈소스 도구가 잘못된 버튼을 눌렀을 때 갑자기 불타버리지 않는 거예요. QA는 지나치게 야심 찬 젠가 탑처럼 전체가 무너지지 않도록 버티는 보이지 않는 지지대입니다.
그렇다면 오픈소스 세계에서 QA란 무엇일까? 자동화된 테스트와 린팅부터 사용자의 버그 리포트, "야, 이거 실행이라도 해봤어?" 같은 리뷰 코멘트까지 모든 것을 포함한다. QA란 소프트웨어가 작동하고, 계속 작동하도록 보장하는 과정이다. 심지어 수천 명의 낯선 사람들이 기묘하고도 놀라운 방식으로 이걸 만지작거려도 말이다.
여기서 반전이 있습니다—OSS에는 보통 전담 QA 팀이 없습니다. 아니요. QA는 전체 커뮤니티입니다. 이슈를 열거나, 테스트를 제출하거나, "이건 Safari 9에서 충돌해요"라고 댓글을 단 적이 있다면, 축하합니다: 여러분은 QA 팀의 일원입니다.
이제 도구에 대해 이야기해 보죠. 자동화된 테스트는 정말 중요합니다. Jest, Mocha, Pytest 등 여러분이 사용하는 언어에 맞는 도구를 선택하면 됩니다. 그리고 지속적 통합(CI)도 있습니다—GitHub Actions, GitLab CI, CircleCI 등—이 모든 것들이 여러분의 PR이 자바스크립트 작업장에서 황소처럼 빌드를 망가뜨리지 않도록 보장해 줍니다.
하지만 QA는 단순히 코드에 관한 것이 아닙니다. 신뢰에 관한 것입니다. 프로젝트가 QA를 진지하게 받아들일 때, 기여자들은 더 큰 자신감을 갖게 됩니다. 사용자들은 더 적극적으로 채택할 가능성이 높아집니다. 그리고 관리자들은 설치 스크립트가 누군가의 라즈베리 파이 클러스터를 망가뜨린 이유에 대한 늦은 밤 DM을 덜 받게 됩니다.
물론, 모든 것이 햇살 가득하고 테스트 커버리지만은 않습니다. 테스트 작성은 어렵습니다. 코드 검토에는 시간이 걸립니다. 그리고 가끔 사람들은 QA 단계를 건너뛰고 그냥 YOLO(인생은 한 번뿐) 정신으로 PR을 메인 브랜치에 밀어넣기도 합니다. 그런 일도 생깁니다. 하지만 커뮤니티가 품질 중심 문화를 구축할 때, 마법 같은 일이 일어납니다. 버그가 줄어듭니다. 병합이 빨라집니다. 머리를 쥐어뜯는 일이 줄어듭니다.
다음에 PR이나 테스트 스위트에 녹색 체크 표시가 178개나 되는 어설션을 통과한 걸 본다면? 그게 바로 QA입니다. 조용히 제 역할을 하며 여러분의 소프트웨어를 정상적으로 유지해 주고 있죠.
자, 이제 OSS의 기초를 알파벳 순으로 살펴보는 여정에서 Q를 마쳤습니다. 다음 번에는 R, 즉 저장소(Repositories)를 다룰 예정입니다. 바로 이 화려한 혼돈이 실제로 존재하는 곳이지요. 그때까지 여러분의 어설션은 탄탄하게, 테스트는 날카롭게 유지하세요. 그럼 다음에 봐요!
